>
> 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?
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.
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.
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?
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.
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.
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.)