On 15 June 2019 2:32:21 pm GMT+02:00, Owen DeLong <o...@delong.com> wrote: > > >> On Jun 13, 2019, at 7:06 AM, Job Snijders <j...@instituut.net> wrote: >> >> Hi Joe, >> >> On Thu, Jun 13, 2019 at 9:59 Joe Abley <jab...@hopcount.ca ><mailto:jab...@hopcount.ca>> wrote: >> Hey Joe, >> >> On 12 Jun 2019, at 12:37, Joe Provo <nanog-p...@rsuc.gweep.net ><mailto:nanog-p...@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. >
In other words, if I have an upstream that uses 6939 for transit, I'm free to permanently prepend 6939 to stop propagation to that network? Isn't using a community that says "do not export to 6939" a better and much cleaner solution? >> 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. > You will have to explain that to SpamHaus and other organizations who are in the business (literally) of blacklisting all upstreams of "rogue" networks. Kind Regards, Filip
