On 15 June 2019 2:32:21 pm GMT+02:00, Owen DeLong <owen@delong.com> wrote:<br>><br>><br>>> On Jun 13, 2019, at 7:06 AM, Job Snijders <job@instituut.net> wrote:<br>>> <br>>> Hi Joe,<br>>> <br>>> On Thu, Jun 13, 2019 at 9:59 Joe Abley <jabley@hopcount.ca<br>><mailto:jabley@hopcount.ca>> wrote:<br>>> Hey Joe,<br>>> <br>>> On 12 Jun 2019, at 12:37, Joe Provo <nanog-post@rsuc.gweep.net<br>><mailto:nanog-post@rsuc.gweep.net>> wrote:<br>>> <br>>> > On Wed, Jun 12, 2019 at 04:10:00PM +0000, David Guo via NANOG<br>>wrote:<br>>> >> Send abuse complaint to the upstreams<br>>> > <br>>> > ...and then name & shame publicly. AS-path forgery "for TE" was<br>>> > never a good idea. Sharing the affected prefix[es]/path[s] would<br>>> > be good.<br>>> <br>>> I realise lots of people dislike AS_PATH stuffing with other peoples'<br>>AS numbers and treat it as a form of hijacking.<br>>> <br>>> However, there's an argument that AS_PATH is really just a<br>>loop-avoidance mechanism, not some kind of AS-granular traceroute for<br>>prefix propagation. In that sense, stuffing 9327 into a prefix as a<br>>mechanism to stop that prefix being accepted by AS 9327 seems almost<br>>reasonable. (I assume this is the kind of TE you are talking about.)<br>>> <br>>> What is the principal harm of doing this? Honest question. I'm not<br>>advocating for anything, just curious.<br>>> <br>>> <br>>> Excellent question.<br>>> <br>>> 1/ We can’t really expect on the loop detection to work that way at<br>>the “jacked” side. So if this is innocent traffic engineering, it is<br>>unreliable at best.<br>><br>>Why not? It’s certainly supposed to work that way according to the<br>>RFCs. Yes, I know there are knobs for people that are too<br>>lazy/conservative/otherwise misguided to get multiple ASNs for their<br>>sites with distanct routing policies so that they’ll accept their<br>>announcements from their remote sites even though their own ASN is in<br>>the path (thus breaking BGP loop detection for their particular AS).<br>><br>>However, it’s very likely (and certainly hopeful) that no transit ASN<br>>would operate this way.<br>><br>>Since this TE method is unlikely to be used to control propagation<br>>to/through a stub ASN, it ought to be pretty reliable for the intended<br>>purpose.<br>><br><br>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? <br><br>>> 2/ Attribution. The moment you stuff AS 2914 anywhere in the path, we<br>>may get blamed for anything that happens through the IP addresses for<br>>that route. In a way the ASNs in the AS_PATH attribute an an<br>>inter-organizational escalation flowchart.<br>><br>>I would think that expecting this to hold true is far less reliable<br>>than the expectation you just claimed was invalid in 1/ above.<br>><br>>I don’t doubt that it might lead to misguided phone calls to 2914 (or<br>>other provider) as a result, but I’m not sure I would blame the<br>>misguided interpretation of the AS Path by the caller on the person who<br>>put the ASN in the path.<br>><br><br>You will have to explain that to SpamHaus and other organizations who are in the business (literally) of blacklisting all upstreams of "rogue" networks. <br><br>Kind Regards,<br>Filip