Operators Penalized? (was Re: Kenyan Route Hijack)
Usually unintentional. See Pakistan Telecom for recent example.
Pakistan's blackhole was semi-unintentional, kind of like you tried to shoot your spouse but the bullet went through the wall and "unintentionally" hit a neighbor.
Do ISPs (PTA, AboveNet, etc) that "unintentionally" hijack someone else IP address space, ever get penalized in *any* form? Depending upon whom and what they hijack, and who all get affected, it sure can get them lot of (undesired) publicity - news, articles, nanog discussions/presentations, ietf discussions, blogs - but, it doesnt really hurt them much, does it? AboveNet, unlike PTA, got a lot less publicity for their achievement, primarily because they didnt put millions off, from watching imbecilic videos of cats jumping the cars, and people slipping in snow - a simple google test corroborates this. While you get pages and pages of sites that talk about "PTA Youtube", you only get a handful when you do "Abovenet Africa Online". So, is there anything that can be done to discourage such mishaps? What do we do if an ISP, again accidentally, hijacks another address block or blackholes them? Would it pain them if their announcements were suppressed, or reachability (more specifically origination information) is damped for some time? I understand, this is opening up a pandora's box, because this ISP could be providing transit services to other ISPs, and this might inadvertently affect them. So, i am not suggesting a solution - i am seeking suggestions on what can be done about this? And before this, if there is anything that we as a community want to do about this? Affably, Glen
On Mon, Mar 17, 2008 at 3:48 PM, Glen Kent <glen.kent@gmail.com> wrote:
Do ISPs (PTA, AboveNet, etc) that "unintentionally" hijack someone else IP address space, ever get penalized in *any* form? Depending upon whom and what they hijack, and who all get affected, it sure can
PTA's ASN actually did get disconnected for several hours by PCCW (which was leaking the youtube prefixes that PTA announced, and which shut off all of PTA's ASN rather than just filtering out the bogus announcements) Though, I am not too convinced that wasnt simply laziness at PCCW rather than a desire to punish PTA Nobody's blackholed abovenet yet that I know of. And if they did do that, they'd feel the effects real soon. --srs
On Mon, Mar 17, 2008 at 03:48:07PM +0530, Glen Kent wrote:
Do ISPs (PTA, AboveNet, etc) that "unintentionally" hijack someone else IP address space, ever get penalized in *any* form?
Not usually. I remember an incident (while working at AboveNet, ironically) back in 98/99 where 701 "accidentally" announced some of our address space. The reason in that case was that a customer who had left 701 under questionable circumstances signed up for service with us... and 701 wanted to punish them. It got at least as far as threats of legal action before they stopped. Not sure if anyone who has more details still reads this list... rs, ser, or dlr might remember more; I don't know who was involved on the uu side of things.
So, is there anything that can be done to discourage such mishaps?
Capture data and sue for damages seems to be about the only recourse now. Of course, that can be extremely difficult when you're talking about organizations on opposite sides of the planet, different jurisdictions, etc. IMHO a better use of our time would be to solve the underlying technical issue(s). Whether it's soBGP, sBGP, or something else, we need to figure out how to make one of these proposals work and get it implemented. --Jeff
On Mon, Mar 17, 2008 at 6:38 PM, Jeff Aitken <jaitken@aitken.com> wrote:
IMHO a better use of our time would be to solve the underlying technical issue(s). Whether it's soBGP, sBGP, or something else, we need to figure out how to make one of these proposals work and get it implemented.
Start with "implement RFC 2827 yourself, and start pushing other SPs to implement it" maybe? srs -- Suresh Ramasubramanian (ops.lists@gmail.com)
Suresh Ramasubramanian wrote:
On Mon, Mar 17, 2008 at 6:38 PM, Jeff Aitken <jaitken@aitken.com> wrote:
IMHO a better use of our time would be to solve the underlying technical issue(s). Whether it's soBGP, sBGP, or something else, we need to figure out how to make one of these proposals work and get it implemented.
Start with "implement RFC 2827 yourself, and start pushing other SPs to implement it" maybe?
srs
RFC2827 is about source address filtering which is not really the same as BGP route announcement filtering. Unfortunately, I have not come across any RFC's with a thorough discussion of route filtering. It is mentioned briefly in RFC 3013, but section 4.5 only suggests filtering routes for private address space. RFC 4778 also mentions it, but again, there is no in depth discussion. Perhaps it is time for an RFC dedicated to route filtering practices? -Larry Blunk Merit
On Mon, Mar 17, 2008 at 8:48 PM, Larry J. Blunk <ljb@merit.edu> wrote:
RFC2827 is about source address filtering which is not really the same as BGP route announcement filtering. Unfortunately, I have not come across
Yup, radb etc for that. Not fully awake when I wrote that, and hit send too soon. The PTCL thing was deliberate origination of a bogus prefix, meant for consumption by Pakistani ISPs . Abovenet too - they surely intended SOMETHING (no idea what) - announcements dont come tagged with communities (and communities with maybe 130 odd prefixes out of the huge number that abovenet advertises) simply by accident. Leaking that prefix out might be accidental - or it was not leaked at all, abovenet is massive, lots of transit customers. PTCL leaking youtube prefixes out to the world rather than pakistani ISPs was an accident. And their upstream PCCW not filtering weird and wonderful route advertisements from downstream customers was .. well, a decision that PCCW took (or rather, chose not to take) That wasnt the first bogus announcement PTCL made .. about a day or so after l'affaire youtube, I looked up PTCL's AS17557 on cidr-report, which also lists allocations announced and withdrawn in the past week. One interesting allocation .. 22.22.22.0/24 22.0.0.0/8 Prefixes added and withdrawn by this origin AS in the past 7 days. - 22.22.22.0/24 Withdrawn That's nic.mil IP space - and that sounds a lot like someone with enable at PTCL probably meant 202 or something similar, but is in the habit of typing new routes directly into production routers, rather than pasting it into a text editor and doing some syntax checking first, using cvs or svn for routes etc. There are enough calls for sBGP and such - but a lot can be accomplished before then simply by doing all the mom and apple pie best practice stuff (and by carrot-and-sticking other SPs into doing them, more importantly - especially any that fit the "large carrier upstream of multiple smaller ISPs with less than clued admins" type places. http://www.apnic.net/meetings/22/docs/tut-routing-pres-bgp-bcp.pdf for example. srs
On Mon, 17 Mar 2008, Larry J. Blunk wrote:
RFC2827 is about source address filtering which is not really the same as BGP route announcement filtering. Unfortunately, I have not come across any RFC's with a thorough discussion of route filtering. It is mentioned briefly in RFC 3013, but section 4.5 only suggests filtering routes for private address space. RFC 4778 also mentions it, but again, there is no in depth discussion. Perhaps it is time for an RFC dedicated to route filtering practices?
This provides half a page summary of what can be done without sweating too much: http://tools.ietf.org/html/draft-savola-rtgwg-backbone-attacks-03#section-3.... Applying a (secure) IRR database to build filters for peers and transits has not (AFAIK) been very well documented anywhere. But on the other hand, not too many people are using it either. Unless a better place or a new document is found for that, I can add some verbiage to the abovementioned draft. (Currently, however, it is not obvious to me if that draft is going to progress, and if so which IETF WG or similar forum would be the right place to develop it.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Glen Kent wrote:
Do ISPs (PTA, AboveNet, etc) that "unintentionally" hijack someone else IP address space, ever get penalized in *any* form?
The net only functions as a single entity because sp's intentionally DONT hijack space and the mutual trust in other sp's rational behavior. Since the sp behavior is financialy driven by user's desires, this is actually fairly easy to predict. The entire stability of the net is due to Nash Equilibrium/MAD Principle. This is an ecosystem which functions because it is in everybodies best _practical_ interest to keep it so. Punitive actions will most likely be viewed as impractical, dampened and staunched as quickly as practically possible +- human tendencies such as ego and similar. Actions that disturb equilibrium must be punitive in and of themselves, either by direct consequence or by predictable side effect and chain reaction. So yes, the penalties must already exist in sufficient form, otherwise this mailing list wouldnt. The jitter in the system is caused by the imperfections in the system, that would be the human element. The system functions because of the imperfections, not in spite of them. I cant see how any imposition of authority could ever change the dynamic, seeing as how it requires the buy in of all, in other words it would function simply as an inefficient version of what already exists. I think its worth consideration that possibly what we have now is the best it will ever be.
participants (6)
-
Glen Kent -
Jeff Aitken -
Joe Maimon -
Larry J. Blunk -
Pekka Savola -
Suresh Ramasubramanian