someone is using my AS number

Filip Hruska fhr at fhrnet.eu
Sat Jun 15 12:53:10 UTC 2019


On 15 June 2019 2:32:21 pm GMT+02:00, Owen DeLong <owen at delong.com> wrote:
>
>
>> On Jun 13, 2019, at 7:06 AM, Job Snijders <job at instituut.net> wrote:
>> 
>> Hi Joe,
>> 
>> On Thu, Jun 13, 2019 at 9:59 Joe Abley <jabley at hopcount.ca
><mailto:jabley at hopcount.ca>> wrote:
>> Hey Joe,
>> 
>> On 12 Jun 2019, at 12:37, Joe Provo <nanog-post at rsuc.gweep.net
><mailto:nanog-post at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190615/f98278fb/attachment.html>


More information about the NANOG mailing list