someone is using my AS number

Owen DeLong owen at delong.com
Sat Jun 15 14:51:34 UTC 2019



> On Jun 15, 2019, at 6:03 AM, Job Snijders <job at instituut.net> wrote:
> 
> On Sat, Jun 15, 2019 at 05:32:21AM -0700, Owen DeLong wrote:
>>> 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? 
> 
> There is no signal from the remote ASN (the one that receive the route
> announcement) to the Originator ASN about the remote ASN's loop
> detection policies. Therefor, since you can't know what the remote side
> will do ahead of time. The only recourse left at that point is active
> probing (trial & error). Trial and error, where the 'error' state may be
> an hard outage, means that the method is unreliable.

That’s absurd…

There’s a pre-defined loop detection behavior that is documented in the RFCs. It’s reasonable to expect the remote ASN to abide by it. Yes, I should understand that there’s a possibility they don’t follow that and will leak the route in despite the poisoning. However, that’s relatively easy to test and has a low probability of changing over time.

Even moreso when you consider that the likely places where such poisoning would be useful would almost certainly be transit ASNs while it’s highly unlikely that deactivating loop detection would be used outside of a stub ASN.

> 
>> 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.
> 
> To all other people - AS_PATH poisoning, as a method to perform traffic
> engineering, is *not* reliable and can lead to hard outages.

The only place it will lead to a hard outage is if the route gets rejected from somewhere other than the intended target of the poisoning due to tripping a peer-lock filter (unlikely if done carefully). It shouldn’t cause any issues with RPKI filtering or most other filtering currently in common use. In the future if we ever get full path validation, then there’s a real issue. However, I’m betting we’ve standardized the replacement for IPv6 before that actually happens.

Owen




More information about the NANOG mailing list