> On Jun 15, 2019, at 6:03 AM, Job Snijders <j...@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
