someone is using my AS number

Thu Jun 13 16:03:19 UTC 2019

I don't think the number of networks with disabled loop prevention is that small.

For example, let's say you're a hosting provider who has 3 locations... no reason to do cold potato routing and you don't have dedicated links between sites, yet you still want ranges announced at DC A to be reachable from DC B and C.

Kind Regards,
Filip

On 13 June 2019 5:56:16 pm GMT+02:00, Jon Lewis <jlewis at lewis.org> wrote:
>I've used it in the distant past for TE purposes.  Assuming you're 
>poisoning one ASN via one transit it's not exactly rocket science to 
>figure out if "it worked" or not.  As Warren mentioned, sometimes your 
>transits just don't provide all the knobs you need.
>
>I suspect the number of networks that have intentionally disabled loop 
>prevention is relatively small, and those more likely "end user'ish" 
>networks that are less likely to be the target of as-path poisoning 
>TE...says the guy who just disabled loop prevention on a bunch of
>routers. 
>:)
>
>On Thu, 13 Jun 2019, Jared Mauch 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. 
>> 
>> 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. Poisoning paths is bad for all parties
>involved.
>> 
>> Kind regards,
>> 
>> Job
>> 
>> 
>>
>
>----------------------------------------------------------------------
>  Jon Lewis, MCP :)           |  I route
>                              |  therefore you are
>_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190613/1bebc91b/attachment.html>