Re: someone is using my AS number

[Owen DeLong <owen () delong com>]

> On Jun 13, 2019, at 7:06 AM, Job Snijders <job () instituut net> wrote:
>
> Hi Joe,
>
> On Thu, Jun 13, 2019 at 9:59 Joe Abley <jabley () hopcount ca <mailto:jabley () hopcount ca>> wrote:
> Hey Joe,
>
> On 12 Jun 2019, at 12:37, Joe Provo <nanog-post () rsuc gweep net <mailto:nanog-post () rsuc gweep net>> wrote:
>
> > On Wed, Jun 12, 2019 at 04:10:00PM +0000, David Guo via NANOG wrote:
> > > Send abuse complaint to the upstreams
> >
> > ...and then name & shame publicly. AS-path forgery "for TE" was
> > never a good idea. Sharing the affected prefix[es]/path[s] would
> > be good.
>
> I realise lots of people dislike AS_PATH stuffing with other peoples' AS numbers and treat it as a form of hijacking.
>
> However, there's an argument that AS_PATH is really just a loop-avoidance mechanism, not some kind of AS-granular 
> traceroute for prefix propagation. In that sense, stuffing 9327 into a prefix as a mechanism to stop that prefix 
> being accepted by AS 9327 seems almost reasonable. (I assume this is the kind of TE you are talking about.)
>
> What is the principal harm of doing this? Honest question. I'm not advocating for anything, just curious.
>
>
> Excellent question.
>
> 1/ We can’t really expect on the loop detection to work that way at the “jacked” side. So if this is innocent traffic 
> engineering, it is unreliable at best.

Why not? It’s certainly supposed to work that way according to the RFCs. Yes, I know there are knobs for people that 
are too lazy/conservative/otherwise misguided to get multiple ASNs for their sites with distanct routing policies so 
that they’ll accept their announcements from their remote sites even though their own ASN is in the path (thus breaking 
BGP loop detection for their particular AS).

However, it’s very likely (and certainly hopeful) that no transit ASN would operate this way.

Since this TE method is unlikely to be used to control propagation to/through a stub ASN, it ought to be pretty 
reliable for the intended purpose.

> 2/ Attribution. The moment you stuff AS 2914 anywhere in the path, we may get blamed for anything that happens 
> through the IP addresses for that route. In a way the ASNs in the AS_PATH attribute an an inter-organizational 
> escalation flowchart.

I would think that expecting this to hold true is far less reliable than the expectation you just claimed was invalid 
in 1/ above.

I don’t doubt that it might lead to misguided phone calls to 2914 (or other provider) as a result, but I’m not sure I 
would blame the misguided interpretation of the AS Path by the caller on the person who put the ASN in the path.

Owen