someone is using my AS number

Thu Jun 13 16:31:58 UTC 2019

On Thu, Jun 13, 2019 at 11:37 AM Jared Mauch <jared at puck.nether.net> wrote:
>
> You also may not know who allows their own ASN inbound as well. It certainly is a mixed bag.
>
> I do consider poisoning at best horrible hygiene and at worst evidence of malicious intent.

Yes, I fully agree it it bletcherous -- which is why I'm looking for
something less ugly...

>
> Good filtering isn’t just prefix or AS path based it’s both.
>
> Best filtering is pinning the prefix to a specific ASN.
>
> Sent from my iCar
>
> On Jun 13, 2019, at 11:24 AM, Job Snijders <job at instituut.net> wrote:
>
> On Thu, Jun 13, 2019 at 11:18 Warren Kumari <warren at kumari.net> wrote:
>>
>> On Thu, Jun 13, 2019 at 9:59 AM Joe Abley <jabley at hopcount.ca> wrote:
>> >
>> > Hey Joe,
>> >
>> > On 12 Jun 2019, at 12:37, Joe Provo <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.
>> >
>>
>> Actually, I've been meaning to start a thread on this for a while.
>>
>> I have an anycast prefix - at one location I'm a customer of a
>> customer of ISP_X &  ISP_Y & ISP_Z. Because ISP_X prefers customer
>> routes, any time a packet touches ISP_X, it goes to this location,
>> even though it is (severely) suboptimal -- things would be better if
>> ISP_X didn't accept this route in this location.
>>
>> Now, the obvious answer of "well, just ask your provider in this
>> location to not announce it to ISP_X. That's what communities / the
>> telephone were invented for!" doesn't work for various (entirely
>> non-technical) reasons...
>>
>> Other than doing path-poisoning can anyone think of a way to
>> accomplish what I want? (modulo the "just become a direct customer
>> instead of being a customer of a customer" or "disable that site", or
>> "convince the AS upstream of you to deploy communities / filters").
>> While icky, sometimes stuffing other people's AS in the path seems to
>> be the only solution...
>
>
>
> Given the prevalence of peerlock-style filters at the transit-free club, poisoning the path may result in a large outage for your prefix rather than a clever optimization.

Er, let me think about this -- if I have 3 locations, A, B, and C, and
at location A (the problematic one) I announce prefix 192.0.2.0/24
with ISP_X in the path, and at locations B and C I just prepend my AS#
(to keep path lengths roughly the same), even if ISP_X, ISP_Y, ISP_Z
(and others) enable peerlock, AFAICT, it will only be location A which
might get filtered, yes?

> Poisoning paths is bad for all parties involved.

Not disagreeing - I'd love to tag my routes with community
1234:<dont_announce_to_X>, or 1233:<set_localpref_to_42>, but without
useful levers, what do I pull? Unlike normally, I'm not arguing just
for the sake of arguing, I'm a lookin' for suggestions...
W

>
> Kind regards,
>
> Job

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf