Re: someone is using my AS number

[Owen DeLong <owen () delong com>]

> On Jun 15, 2019, at 6:03 AM, Job Snijders <job () 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