Re: someone is using my AS number

[Filip Hruska <fhr () fhrnet eu>]

On 15 June 2019 2:32:21 pm GMT+02:00, Owen DeLong <owen () delong com> wrote:
> > On Jun 13, 2019, at 7:06 AM, Job Snijders <job () instituut net> wrote:
> >
> > Hi Joe,
> >
> > On Thu, Jun 13, 2019 at 9:59 Joe Abley <jabley () hopcount ca
> <mailto:jabley () hopcount ca>> wrote:
> > Hey Joe,
> >
> > On 12 Jun 2019, at 12:37, Joe Provo <nanog-post () rsuc gweep net
> <mailto:nanog-post () 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