What is the procedure to have another party to cease and desist in using my AS number? Thx
Send abuse complaint to the upstreams Get Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: NANOG <nanog-bounces@nanog.org> on behalf of Philip Lavine via NANOG <nanog@nanog.org> Sent: Thursday, June 13, 2019 12:05:58 AM To: NANOG List Subject: someone is using my AS number What is the procedure to have another party to cease and desist in using my AS number? Thx
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. -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling
Hey Joe, On 12 Jun 2019, at 12:37, Joe Provo <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. Joe
Hi Joe, On Thu, Jun 13, 2019 at 9:59 Joe Abley <jabley@hopcount.ca> wrote:
Hey Joe,
On 12 Jun 2019, at 12:37, Joe Provo <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. 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. Kind regards, Job
On 13 Jun 2019, at 10:06, Job Snijders <job@instituut.net> wrote:
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.
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.
Good answer! Somebody should write that down. :-) Joe
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.
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. Owen
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
On Sat, 15 Jun 2019, Filip Hruska wrote:
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?
Sure, unless/until that doesn't work. In the case I recall where I used as-path poisoning, we were multihomed to two NSPs. For TE purposes, we'd been advertising a couple of more specifics to NSP1 with community strings to limit propagation. One day, NSP2 went from being a peer of NSP1 to a customer of NSP1. Generally, if a network even has customer usable propagation limiting community support, it's only applicable to their peers, not customers. So, when the peering relationship between NSP1 & NSP2 changed, our TE became less effective because NSP2 started receiving the more specifics from NSP1. The fix was to add NSP2's AS to the more specifics sent to NSP1...and to eventually get another transit provider.
You will have to explain that to SpamHaus and other organizations who are in the business (literally) of blacklisting all upstreams of "rogue" networks.
I think they have enough clue to notice "screwy as-paths". ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Sat, Jun 15, 2019 at 05:32:21AM -0700, Owen DeLong wrote:
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?
There is no signal from the remote ASN (the one that receive the route announcement) to the Originator ASN about the remote ASN's loop detection policies. Therefor, since you can't know what the remote side will do ahead of time. The only recourse left at that point is active probing (trial & error). Trial and error, where the 'error' state may be an hard outage, means that the method is unreliable.
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.
To all other people - AS_PATH poisoning, as a method to perform traffic engineering, is *not* reliable and can lead to hard outages. Regards, Job
On Sat, 15 Jun 2019, Job Snijders wrote:
There is no signal from the remote ASN (the one that receive the route announcement) to the Originator ASN about the remote ASN's loop detection policies. Therefor, since you can't know what the remote side will do ahead of time. The only recourse left at that point is active probing (trial & error). Trial and error, where the 'error' state may be an hard outage, means that the method is unreliable.
How does as-path poisoning failing (i.e. the AS you wanted to ignore a route accepts it) cause a hard outage? When used for TE, a failure just means a route/path you wanted some remote network to ignore is not ignored and might be used. i.e. Your TE may not work as desired, but the packets will still get to you, just not necessarily via the path you wanted them to take. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Sat, Jun 15, 2019 at 09:31:03AM -0400, Jon Lewis wrote:
On Sat, 15 Jun 2019, Job Snijders wrote:
There is no signal from the remote ASN (the one that receive the route announcement) to the Originator ASN about the remote ASN's loop detection policies. Therefor, since you can't know what the remote side will do ahead of time. The only recourse left at that point is active probing (trial & error). Trial and error, where the 'error' state may be an hard outage, means that the method is unreliable.
How does as-path poisoning failing (i.e. the AS you wanted to ignore a route accepts it) cause a hard outage?
Formatting warning, what follows is an ASCII art diagram: | "the rest" | +---------------+ | | +------+ +------+ | | | | +--+ 2914 +--------+ 7018 | | | | | | | +--+---+ +---+--+ | | | | | +-----+ | | | | | | | +----+ NSP +-----+ | | | | +---+-+ | | | +---+---+ | | | +----------+ ISP A | | | +-------+ In the above the ISP called "ISP A" is multihomed to "NTT" and an entity called "NSP", the NSP is multi-homed to both NTT and AT&T. I attempted to make this a realistic scenario. In the above situation the ISP A entity might want to force certain traffic over the NTT link, and instead of using BGP communities they use BGP AS_PATH poisoning. The moment they mangle the AS_PATH on their announcement and insert 2914 in their announcement towards NSP, the following can happen: When ISP A would want to poison the path, ISP A may expect the following paths to be visible from the ATT and NTT routes: AS_PATH | footnotes 7018_NSP_ISPA_2914_ISPA | 1 2914_7018_NSP_ISPA_2914_ISPA | 1 7018_2914_NSP_ISPA_2914_ISPA | 2 2914_NSP_ISPA_2914_ISPA | 2 NSP_ISPA_2914_ISPA | 3 7018_2914_ISPA | 4 2914_ISPA | 4 footnotes: 1) rejected on AT&T routers due to peerlock (2914 is seen in the AS_PATH) 2) rejected by NTT routers due to as-path loop detection, thus never propagated to AT&T. Neither NTT or AT&T will ever use this path. 3) potentially rejected by NSP due to presence of an upstream ASN in AS_PATH, thus neither NTT or AT&T will ever this path. 4) accepted by both AT&T and NTT. note that this effectively is ISP A single homing In both scenarios it was ISP A's goal to receive less traffic over the NSP-ISP A link, and the moment they deployed this policy, they'll think it was successful, because traffic comes in via the NTT-ISP A link. Now imagine (weeks after doing the AS_PATH poisoning), the link between 2914-ISP A is taken down (maintenance, outage, or whatever) - at that moment ISP A will discover that their AS_PATH mangling resulted in a hard outage. There was not switching to the paths via NSP. In fact, the NSP may not even have accepted the routes in the first place because many NSPs reject their upstream's ASNs when seen in routes received from their downstreams. In this thread, there is some hints of anecdata about when this trick works 'as intended', but what I'm trying to point out no shortage of examples where it leads to a problematic situation. In this thread we seem to have some unclarity about what 'reliable' or 'unreliable' means. AT&T will never proactively notify ISP A about changes to their AS_PATH filters, so what works today may be entirely broken tomorrow. I'm not disputing that AS_PATH poisoning can't be used to accomplish traffic engineering objectives, but it is similar to relying on linux operating system 0-days to obtain root access on a server. Sure, sometimes it may work, but I hope we can agree that for business purposes it is not a reliable or recommend way to achieve your goals via exploits.
When used for TE, a failure just means a route/path you wanted some remote network to ignore is not ignored and might be used. i.e. Your TE may not work as desired, but the packets will still get to you, just not necessarily via the path you wanted them to take.
It depends! Keep in mind that traffic engineering based on AS_PATH mangling is exploiting a property of the default as-path loop detection behaviour in BGP implementations. This means we're relying on a second order effect. The loop detection exists to stop the propagation of loops. This means that such paths won't be considered at even a lower priority, but are just rejected. The moment paths are rejected at any point anywhere in the BGP graph, you risk unreachablity. I hope this helped clarify a bit. Kind regards, Job
On Sat, 15 Jun 2019, Job Snijders wrote:
The moment they mangle the AS_PATH on their announcement and insert 2914 in their announcement towards NSP, the following can happen:
When ISP A would want to poison the path, ISP A may expect the following paths to be visible from the ATT and NTT routes:
AS_PATH | footnotes 7018_NSP_ISPA_2914_ISPA | 1 2914_7018_NSP_ISPA_2914_ISPA | 1 7018_2914_NSP_ISPA_2914_ISPA | 2 2914_NSP_ISPA_2914_ISPA | 2 NSP_ISPA_2914_ISPA | 3 7018_2914_ISPA | 4 2914_ISPA | 4
footnotes: 1) rejected on AT&T routers due to peerlock (2914 is seen in the AS_PATH) 2) rejected by NTT routers due to as-path loop detection, thus never propagated to AT&T. Neither NTT or AT&T will ever use this path. 3) potentially rejected by NSP due to presence of an upstream ASN in AS_PATH, thus neither NTT or AT&T will ever this path. 4) accepted by both AT&T and NTT. note that this effectively is ISP A single homing
I'll conceed that all of the above could happen, and has probably gotten more likely over time as networks get more "careful" about what paths they'll accept from who (too many BGP oops's over the years?). My last use of as-path poisoning for TE was a couple of jobs ago and quite possibly ~10 years ago. I was trying to keep an ISP (Level3) from sending our "TE more specifics" to a customer (TW Telecom), and at least back at that time, Level3 would accept routes from one customer (us) with another customer's (TW Telecom / 4323) ASN in the as-path. Also, since in my case, the as-path poisoning was limited to more specifics that we advertised to one upstream utilizing their supported propagation limiting strings, poor propagation was the goal...and any network that didn't get those routes (i.e. the vast majority of the Internet) would presumably receive the natural as-path aggregate route(s). So, again, if there were propagation problems with the poisoned paths after they were accepted by the one upstream they were advertised to, A) that was the goal, B) you still have an aggregate route path. If ISP1 stopped accepting them, the TE would just stop working entirely, and everyone would use the aggregates. Presumably, anyone using as-path poisoning would have non-poisoned covering aggregates, that "everyone" would use in the cases of rejection or failures causing no non-poisoned route to be available. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Jun 15, 2019, at 6:03 AM, Job Snijders <job@instituut.net> wrote:
On Sat, Jun 15, 2019 at 05:32:21AM -0700, Owen DeLong wrote:
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?
There is no signal from the remote ASN (the one that receive the route announcement) to the Originator ASN about the remote ASN's loop detection policies. Therefor, since you can't know what the remote side will do ahead of time. The only recourse left at that point is active probing (trial & error). Trial and error, where the 'error' state may be an hard outage, means that the method is unreliable.
That’s absurd… There’s a pre-defined loop detection behavior that is documented in the RFCs. It’s reasonable to expect the remote ASN to abide by it. Yes, I should understand that there’s a possibility they don’t follow that and will leak the route in despite the poisoning. However, that’s relatively easy to test and has a low probability of changing over time. Even moreso when you consider that the likely places where such poisoning would be useful would almost certainly be transit ASNs while it’s highly unlikely that deactivating loop detection would be used outside of a stub ASN.
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.
To all other people - AS_PATH poisoning, as a method to perform traffic engineering, is *not* reliable and can lead to hard outages.
The only place it will lead to a hard outage is if the route gets rejected from somewhere other than the intended target of the poisoning due to tripping a peer-lock filter (unlikely if done carefully). It shouldn’t cause any issues with RPKI filtering or most other filtering currently in common use. In the future if we ever get full path validation, then there’s a real issue. However, I’m betting we’ve standardized the replacement for IPv6 before that actually happens. Owen
On Thu, Jun 13, 2019 at 9:59 AM Joe Abley <jabley@hopcount.ca> wrote:
Hey Joe,
On 12 Jun 2019, at 12:37, Joe Provo <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.
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... W
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.
Joe
-- 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
On Thu, Jun 13, 2019 at 11:18 Warren Kumari <warren@kumari.net> wrote:
On Thu, Jun 13, 2019 at 9:59 AM Joe Abley <jabley@hopcount.ca> wrote:
Hey Joe,
On 12 Jun 2019, at 12:37, Joe Provo <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.
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
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@instituut.net> wrote:
On Thu, Jun 13, 2019 at 11:18 Warren Kumari <warren@kumari.net> wrote:
On Thu, Jun 13, 2019 at 9:59 AM Joe Abley <jabley@hopcount.ca> wrote:
Hey Joe,
On 12 Jun 2019, at 12:37, Joe Provo <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.
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
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@instituut.net> wrote:
On Thu, Jun 13, 2019 at 11:18 Warren Kumari <warren@kumari.net> wrote: On Thu, Jun 13, 2019 at 9:59 AM Joe Abley <jabley@hopcount.ca> wrote: > > Hey Joe, > > On 12 Jun 2019, at 12:37, Joe Provo <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. >
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_________
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@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@instituut.net> wrote:
On Thu, Jun 13, 2019 at 11:18 Warren Kumari <warren@kumari.net> wrote: On Thu, Jun 13, 2019 at 9:59 AM Joe Abley <jabley@hopcount.ca> wrote: > > Hey Joe, > > On 12 Jun 2019, at 12:37, Joe Provo <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. >
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.
On Thu, Jun 13, 2019 at 11:37 AM Jared Mauch <jared@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@instituut.net> wrote:
On Thu, Jun 13, 2019 at 11:18 Warren Kumari <warren@kumari.net> wrote:
On Thu, Jun 13, 2019 at 9:59 AM Joe Abley <jabley@hopcount.ca> wrote:
Hey Joe,
On 12 Jun 2019, at 12:37, Joe Provo <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.
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
On Jun 13, 2019, at 8:24 AM, Job Snijders <job@instituut.net> wrote:
On Thu, Jun 13, 2019 at 11:18 Warren Kumari <warren@kumari.net <mailto:warren@kumari.net>> wrote: On Thu, Jun 13, 2019 at 9:59 AM 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.
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
Job, Permit me to apply some reflective listening to your statement: What I heard you say is: “I’m not going to offer a solution to your problem, but you shouldn’t use the one you have that currently works because some things my friends and I are doing react poorly to it and you may suffer some consequences as a result.” Owen
On Sat, Jun 15, 2019 at 2:38 PM Owen DeLong <owen@delong.com> wrote:
Job,
Permit me to apply some reflective listening to your statement:
What I heard you say is: “I’m not going to offer a solution to your problem, but you shouldn’t use the one you have that currently works because some things my friends and I are doing react poorly to it and you may suffer some consequences as a result.”
I have no idea how you would arrive at such a contrived convoluted interpretation. I'm sorry I can't help further your understanding of how modern day Internet routing works. Kind regards, Job
On Jun 15, 2019, at 5:43 AM, Job Snijders <job@instituut.net> wrote:
On Sat, Jun 15, 2019 at 2:38 PM Owen DeLong <owen@delong.com> wrote:
Job,
Permit me to apply some reflective listening to your statement:
What I heard you say is: “I’m not going to offer a solution to your problem, but you shouldn’t use the one you have that currently works because some things my friends and I are doing react poorly to it and you may suffer some consequences as a result.”
I have no idea how you would arrive at such a contrived convoluted interpretation. I'm sorry I can't help further your understanding of how modern day Internet routing works.
Kind regards,
Job
It’s neither contrived, nor convoluted. It’s pretty much exactly what you said. I have a pretty good understanding of how modern internet routing works and I wasn’t asking you to clarify that. I was pointing out that while you told the guy not to use a tool that’s been working for him, you didn’t actually answer his question, nor did you offer any useful alternative. Owen
On Sat, Jun 15, 2019 at 4:45 PM Owen DeLong <owen@delong.com> wrote:
On Jun 15, 2019, at 5:43 AM, Job Snijders <job@instituut.net> wrote:
On Sat, Jun 15, 2019 at 2:38 PM Owen DeLong <owen@delong.com> wrote:
owen> >> What I heard you say is: “I’m not going to offer a solution to your problem, but you shouldn’t use the one you have that currently works because some things my friends and I are doing react poorly to it and you may suffer some consequences as a result.”
job> > I have no idea how you would arrive at such a contrived convoluted job> > interpretation. I'm sorry I can't help further your understanding of job> > how modern day Internet routing works.
owen> I was pointing out that while you told the guy not to use a tool that’s been working for him, you didn’t actually answer his question, nor did you offer any useful alternative. Your summary of this thread is somewhat incomplete. I'll try myself: OP started with - "help, my ASN was used without my permission, what do I do?" - to which NANOG answered "let us know your ASN and we'll use our rolodex". Awesome, the community tried to help Philip Lavine. Then in a follow-up (general context) question from Joe Abley: "what actually can go wrong when the AS_PATH is modified for traffic engineering purposes?", to which three factually correct answers were provided: 1/ it may not help you achieve your traffic engineering goal (you can't know if as-path loop avoidance is enabled or not) 2/ it makes security incident attribution processes harder because poisoned AS_PATH contain fabricated information 3/ it can lead to hard outages because of interaction with EBGP routing security filters (such as peer-lock) Again a productive mail exchange, Joe Abley asked a good question and the resulting public discussion hopefully helped others learn something. Next up: Warren offered in a separate subthread "sometimes it seems AS_PATH poisoning is the only solution for traffic-engineering, what else can we do". To which I add: "we should keep in mind that this 'only solution' may result in hard outages", (I assume hard outages are considered worse than the state of things without traffic engineering). If BGP communities and telephone requests are not available, and AS_PATH poisoning seems to be the "only solution", well, then that is the only "solution" (but poisoning caveats still apply). There probably is no answer to Warren's question, at least I couldn't provide one because communities & phone were taken away. So, you turned something I intended as a simple addition to Warren's message (a point that hadden't yet been mentioned), into a vague statement about "Job and his friends". EBGP AS_PATH filters ("peerlock-style") have existed in many forms, since long before I even had a job in this sector. It is absolutely unclear to me what you are trying to achieve. Kind regards, Job
On Sat, 15 Jun 2019 05:38:23 -0700, Owen DeLong said:
What I heard you say is: “I’m not going to offer a solution to your problem, but you shouldn’t use the one you have that currently works because some things my friends and I are doing react poorly to it and you may suffer some consequences as a result.”
Umm.. Owen? If "you may suffer some consequences as a result" is true, then your claim the solution "currently works" is just a tad suspect, isn't it? (Personally, I read Job's note as saying "Beware that this may not actually do what you think it should do, and in fact may do the opposite...")
other than the possibility of the stuffed AS being associated with behavior, no harm if nothing malicious is happening. if something malicious is happening, we probably have bigger problems. have used path poisoning for a notable research experiment; where we credit the first major poisoner, lorenzo's thesis. randy
On Thu, Jun 13, 2019 at 09:58:20AM -0400, Joe Abley wrote:
Hey Joe,
On 12 Jun 2019, at 12:37, Joe Provo <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.
There is no way at a distance to tell the difference between: - legitimate AS forwarding - ham-fistedly attempting "innocent" TE away from the forged AS - maliciously hiding traffic from the forged AS - an error with the forged AS IME, when you can NOT look like an error or an attack, that's a Good Thing. The last "major" provider who failed to provide BGP community-based TE was 3549, and with their absorbtion into 3356 no one should have any tolerance for this garbage, IMNSHO. Cheers, joe -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling
HE doesn't provide any community based TE and I would say they're a pretty major network. Filip On 14 June 2019 2:17:43 am GMT+02:00, Joe Provo <nanog-post@rsuc.gweep.net> wrote:
On Thu, Jun 13, 2019 at 09:58:20AM -0400, Joe Abley wrote:
Hey Joe,
On 12 Jun 2019, at 12:37, Joe Provo <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.
There is no way at a distance to tell the difference between: - legitimate AS forwarding - ham-fistedly attempting "innocent" TE away from the forged AS - maliciously hiding traffic from the forged AS - an error with the forged AS
IME, when you can NOT look like an error or an attack, that's a Good Thing.
The last "major" provider who failed to provide BGP community-based TE was 3549, and with their absorbtion into 3356 no one should have any tolerance for this garbage, IMNSHO.
Cheers,
joe
-- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Jun 14, 2019, at 4:02 AM, Filip Hruska <fhr@fhrnet.eu> wrote:
HE doesn't provide any community based TE and I would say they're a pretty major network.
With all respect to my friends at HE, this is a major gap for a network in 2019. I know this has lost them business over time with customers leaving due to the lack of TE communities. I know it takes time/effort to design and roll-out, so hopefully it’s coming for them soon. - Jared
On Jun 14, 2019, at 4:22 AM, Jared Mauch <jared@puck.nether.net> wrote:
On Jun 14, 2019, at 4:02 AM, Filip Hruska <fhr@fhrnet.eu> wrote:
HE doesn't provide any community based TE and I would say they're a pretty major network.
With all respect to my friends at HE, this is a major gap for a network in 2019. I know this has lost them business over time with customers leaving due to the lack of TE communities. I know it takes time/effort to design and roll-out, so hopefully it’s coming for them soon.
- Jared
It’s unlikely. IMHO, it has to do with the mentality of Mike Leber and Mike Tindle. Owen
On Thu, Jun 13, 2019 at 5:18 PM Joe Provo <nanog-post@rsuc.gweep.net> wrote:
The last "major" provider who failed to provide BGP community-based TE was 3549, and with their absorbtion into 3356 no one should have any tolerance for this garbage, IMNSHO.
as near as I can tell, you can't get per-neighbor or other TE options on he.net, for instance, so not all folk support this :( (reference: https://onestep.net/communities/ has no he.net details. Checking for 6939 details on their site also came up blank for me)
On Wed, Jun 12, 2019 at 11:46 AM Carsten Bormann <cabo@tzi.org> wrote:
On Jun 12, 2019, at 18:10, David Guo via NANOG <nanog@nanog.org> wrote:
Send abuse complaint to the upstreams
Get Outlook for iOS
Yes, but which of these is more effective?
With some upstreams, I wonder if getting Outlook for iOS might not be just as effective as contacting them...
Contact the offending upstreams. Filip On 12 June 2019 6:05:58 pm GMT+02:00, Philip Lavine via NANOG <nanog@nanog.org> wrote:
What is the procedure to have another party to cease and desist in using my AS number? Thx
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
yeah I did they are some MSP in India. No help. On Wednesday, June 12, 2019, 9:15:51 AM PDT, Filip Hruska <fhr@fhrnet.eu> wrote: Contact the offending upstreams. Filip On 12 June 2019 6:05:58 pm GMT+02:00, Philip Lavine via NANOG <nanog@nanog.org> wrote: What is the procedure to have another party to cease and desist in using my AS number? Thx -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
I would contact upstreams of the upstream then. This is quite a serious offence and they should help you. Regards, Filip On 12 June 2019 6:20:42 pm GMT+02:00, Philip Lavine <source_route@yahoo.com> wrote:
yeah I did they are some MSP in India. No help.
On Wednesday, June 12, 2019, 9:15:51 AM PDT, Filip Hruska <fhr@fhrnet.eu> wrote:
Contact the offending upstreams.
Filip
On 12 June 2019 6:05:58 pm GMT+02:00, Philip Lavine via NANOG <nanog@nanog.org> wrote: What is the procedure to have another party to cease and desist in using my AS number? Thx
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Can you share more details? Perhaps we can put the human social network to good use. Other than that this is annoying - are right now operationally impacted? Kind regards, Job On Wed, Jun 12, 2019 at 12:24 Filip Hruska <fhr@fhrnet.eu> wrote:
I would contact upstreams of the upstream then. This is quite a serious offence and they should help you.
Regards, Filip
On 12 June 2019 6:20:42 pm GMT+02:00, Philip Lavine < source_route@yahoo.com> wrote:
yeah I did they are some MSP in India. No help.
On Wednesday, June 12, 2019, 9:15:51 AM PDT, Filip Hruska <fhr@fhrnet.eu> wrote:
Contact the offending upstreams.
Filip
On 12 June 2019 6:05:58 pm GMT+02:00, Philip Lavine via NANOG < nanog@nanog.org> wrote:
What is the procedure to have another party to cease and desist in using my AS number?
Thx
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Here is what I got from BGPMon- MY AS is 15053 Detected new prefix: 134.37.2.0/23 Update time: 2019-06-11 17:58 (UTC) Detected by #peers: 70 Announced by: AS15053 (ROLL-GLOBAL-LLC - Roll Global LLC, US) Upstream AS: AS15001 (ITCONVERGENCE-COM - IT Convergence Inc., US) ASpath: 394256 174 702 25213 25213 25213 15001 15053 I tried contacting the upstream provider and they were no help :Contact - IT Convergence | | | | | | | | | | | Contact - IT Convergence Contact us today to learn more about how your business can benefit by partnering with IT Convergence. | | | On Wednesday, June 12, 2019, 9:34:16 AM PDT, Job Snijders <job@ntt.net> wrote: Can you share more details? Perhaps we can put the human social network to good use. Other than that this is annoying - are right now operationally impacted? Kind regards, Job On Wed, Jun 12, 2019 at 12:24 Filip Hruska <fhr@fhrnet.eu> wrote: I would contact upstreams of the upstream then. This is quite a serious offence and they should help you. Regards, Filip On 12 June 2019 6:20:42 pm GMT+02:00, Philip Lavine <source_route@yahoo.com> wrote: yeah I did they are some MSP in India. No help. On Wednesday, June 12, 2019, 9:15:51 AM PDT, Filip Hruska <fhr@fhrnet.eu> wrote: Contact the offending upstreams. Filip On 12 June 2019 6:05:58 pm GMT+02:00, Philip Lavine via NANOG <nanog@nanog.org> wrote: What is the procedure to have another party to cease and desist in using my AS number? Thx -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Our records show this happened yesterday and lasted before 2019-06-11 20:24:00, for 2.5 hours total. Maybe that was just by accident. I'm sort of confused why you're speaking of some ISPs in India. The incident was more or less local to Finland, wasn't it? -- Töma
Indeed, I do not see this in the our current version of the Default-Free Zone, so there may not be a problem for us to solve at this moment. I think your reaching out to NANOG or other operator forums is the correct action. Someone is bound to know someone who knows someone who can help. Kind regards, Job On Wed, Jun 12, 2019 at 6:06 PM Töma Gavrichenkov <ximaera@gmail.com> wrote:
Our records show this happened yesterday and lasted before 2019-06-11 20:24:00, for 2.5 hours total. Maybe that was just by accident.
I'm sort of confused why you're speaking of some ISPs in India. The incident was more or less local to Finland, wasn't it?
-- Töma
I talked to the upstream provider on AS 1500. I called the telephone number on the abuse record on ARIN and it went to a MSP in India. On Wednesday, June 12, 2019, 11:06:13 AM PDT, Töma Gavrichenkov <ximaera@gmail.com> wrote: Our records show this happened yesterday and lasted before 2019-06-11 20:24:00, for 2.5 hours total. Maybe that was just by accident. I'm sort of confused why you're speaking of some ISPs in India. The incident was more or less local to Finland, wasn't it? -- Töma
AS15001 ? (IT Convergence Inc.) MSP in India: did they have any slightest idea about the issue? :-) Cheers, Carlos On Wed, 12 Jun 2019, Philip Lavine via NANOG wrote:
I talked to the upstream provider on AS 1500. I called the telephone number on the abuse record on ARIN and it went to a MSP in India.
On Wednesday, June 12, 2019, 11:06:13 AM PDT, Töma Gavrichenkov <ximaera@gmail.com> wrote:
Our records show this happened yesterday and lasted before 2019-06-11 20:24:00, for 2.5 hours total. Maybe that was just by accident.
I'm sort of confused why you're speaking of some ISPs in India. The incident was more or less local to Finland, wasn't it?
-- Töma
Seems the issue was on AS25213 side. They don't provide transit to AS15001 at all. Regards, Filip On 12 June 2019 7:57:52 pm GMT+02:00, Philip Lavine <source_route@yahoo.com> wrote:
Here is what I got from BGPMon- MY AS is 15053
Detected new prefix: 134.37.2.0/23 Update time: 2019-06-11 17:58 (UTC) Detected by #peers: 70 Announced by: AS15053 (ROLL-GLOBAL-LLC - Roll Global LLC, US) Upstream AS: AS15001 (ITCONVERGENCE-COM - IT Convergence Inc., US) ASpath: 394256 174 702 25213 25213 25213 15001 15053
I tried contacting the upstream provider and they were no help :Contact - IT Convergence
| | | | | |
|
| | | | Contact - IT Convergence
Contact us today to learn more about how your business can benefit by partnering with IT Convergence. |
|
|
On Wednesday, June 12, 2019, 9:34:16 AM PDT, Job Snijders <job@ntt.net> wrote:
Can you share more details? Perhaps we can put the human social network to good use. Other than that this is annoying - are right now operationally impacted? Kind regards, Job On Wed, Jun 12, 2019 at 12:24 Filip Hruska <fhr@fhrnet.eu> wrote:
I would contact upstreams of the upstream then. This is quite a serious offence and they should help you.
Regards, Filip
On 12 June 2019 6:20:42 pm GMT+02:00, Philip Lavine <source_route@yahoo.com> wrote: yeah I did they are some MSP in India. No help.
On Wednesday, June 12, 2019, 9:15:51 AM PDT, Filip Hruska <fhr@fhrnet.eu> wrote:
Contact the offending upstreams.
Filip
On 12 June 2019 6:05:58 pm GMT+02:00, Philip Lavine via NANOG <nanog@nanog.org> wrote: What is the procedure to have another party to cease and desist in using my AS number? Thx
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Maybe try contacting the RIR? On Wed, Jun 12, 2019, 12:23 PM Philip Lavine via NANOG <nanog@nanog.org> wrote:
yeah I did they are some MSP in India. No help.
On Wednesday, June 12, 2019, 9:15:51 AM PDT, Filip Hruska <fhr@fhrnet.eu> wrote:
Contact the offending upstreams.
Filip
On 12 June 2019 6:05:58 pm GMT+02:00, Philip Lavine via NANOG < nanog@nanog.org> wrote:
What is the procedure to have another party to cease and desist in using my AS number?
Thx
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
details help here, and perhaps folk who peer with the upstreams can just reject routes with your as in them... if, you know, we knew what that was :) On Wed, Jun 12, 2019 at 9:21 AM Philip Lavine via NANOG <nanog@nanog.org> wrote:
yeah I did they are some MSP in India. No help.
On Wednesday, June 12, 2019, 9:15:51 AM PDT, Filip Hruska <fhr@fhrnet.eu> wrote:
Contact the offending upstreams.
Filip
On 12 June 2019 6:05:58 pm GMT+02:00, Philip Lavine via NANOG <nanog@nanog.org> wrote:
What is the procedure to have another party to cease and desist in using my AS number?
Thx
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Proper filtering from the upstream providers. .as On Wed, Jun 12, 2019 at 9:25 PM Alejandro Acosta < alejandroacostaalamo@gmail.com> wrote:
Unfortunately RPKI is not useful in this case.
Question: What else could be done to prevent this?
Alejandro,
On 6/12/19 12:05 PM, Philip Lavine via NANOG wrote:
What is the procedure to have another party to cease and desist in using my AS number?
Thx
participants (22)
-
Alejandro Acosta -
Arturo Servin -
Carlos Friaças -
Carsten Bormann -
Christopher Morrow -
David Guo -
Filip Hruska -
Jared Mauch -
Job Snijders -
Job Snijders -
Joe Abley -
Joe Provo -
Jon Lewis -
Matt Harris -
Mehmet Akcin -
Owen DeLong -
Philip Lavine -
Randy Bush -
Ross Tajvar -
Töma Gavrichenkov -
Valdis Klētnieks -
Warren Kumari