> 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. > 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
