Which means that, by advertising routes more specific than the ones they
are poisoning, it may well be possible to restore universal connectivity
to YouTube.
Well, if you can get them in there.... Youtube tried that, to restore service
to the rest of the world, and the announcements didn't propogate.
Simon
I figured as much, but it was worth a try.
Which touches on the earlier discussion of the null routing of /32s
advertised by a special AS (as a means of black-holing DDOS traffic).
It seems to me that a more immediately germane matter regarding BGP
route propagation is prevention of hijacking of critical routes.
Perhaps certain ASes that are considered "high priority", like Google,
YouTube, Yahoo, MS (at least their update servers), can be trusted to
propagate routes that are not aggregated/filtered, so as to give them
control over their reachability and immunity to longer-prefix hijacking
(especially problematic with things like MS update sites).
Not if the hijackers have advertised a /24. Anything you advertise more
specific than /24 will be lost on many networks' filters.
> Which means that, by advertising routes more specific than the ones they
> are poisoning, it may well be possible to restore universal connectivity
> to YouTube.Well, if you can get them in there.... Youtube tried that, to restore service
to the rest of the world, and the announcements didn't propogate.
Some of us block prefixes longer than /24 at our borders (even if our
transit providers don't).
Steinar Haug, Nethelp consulting, sthaug@nethelp.no
Tomas L. Byrnes wrote:
Perhaps certain ASes that are considered "high priority", like Google,
YouTube, Yahoo, MS (at least their update servers), can be trusted to
propagate routes that are not aggregated/filtered, so as to give them
control over their reachability and immunity to longer-prefix hijacking
(especially problematic with things like MS update sites).
Not to stir up a huge debate here, but if I were a day trader, I could live
without YouTube for a day, but not e*trade or Ameritrade as it would be my
livelihood. If I were an eBay seller, why would I care about YouTube? You
get the idea. What makes Google, YouTube, Yahoo, MS, etc more important?
More importantly, why is PCCW not prefix filtering their downstreams?
Certainly AS17557 cannot be trusted without a filter.
Randy
I'm sure we can all find a list of "critical infrastructure" ASes that
could be trusted to peer via the "high priority" AS. I'd say that the
criteria should be:
1: Hosted at a Tier 1 provider.
2: Within a jurisdiction where North American operators have a good
chance of having the law on their side in case of any network outage
caused by the entity.
3: Considered highly competent technically.
4: With state of the art security and operations.
OTOH: I would say that, until today, those who advocate not engaging in
any kind of ethnic or political profiling would have considered 17557,
as a national telco, a trusted route source.
I'm sure we can all find a list of "critical infrastructure" ASes that
could be trusted to peer via the "high priority" AS. I'd say that the
criteria should be:1: Hosted at a Tier 1 provider.
That is a silly requirement.
(I am sorry, I tried hard to find a nicer way to say this, but I really feel strongly about this.)
2: Within a jurisdiction where North American operators have a good
chance of having the law on their side in case of any network outage
caused by the entity.
This is also a bit strange. Do your users never attach to a host outside the USofA?
3: Considered highly competent technically.
Here we agree.
4: With state of the art security and operations.
I think we agree, but I wouldn't have said it like that.
This candidate list of requirements is for route sources that North
American Operators should trust to propagate long prefix routes, nothing
more, nothing less. In that context, some of your comments don't really
make sense.
Perhaps you might like to propose criteria you would find useful in
setting a level of trust, or some alternative method to avoid a
recurrence of a site that is widely visited being black holed through
another ISP advertising a more specific route?
Specifically:
In place of item 1, what criteria would you propose for the route
source?
Item 2: in this context, is specific to the needs of North American
Network Operators accepting long prefix routes. I am not advocating not
accepting routes from the ROW, just not very specific ones. It's
entirely possible for North American Operators to rely on law
enforcement in say, the EU and Australia.
Item 3: Glad we agree on something.
Item 4: How would you have said it?
I think it would be better to propose some constructive ideas as to how
we can avoid what happened today from recurring, and also deal with the
issue of hijacked IP space in general.
I figured as much, but it was worth a try.
Which touches on the earlier discussion of the null routing of /32s
advertised by a special AS (as a means of black-holing DDOS traffic).It seems to me that a more immediately germane matter regarding BGP
route propagation is prevention of hijacking of critical routes.Perhaps certain ASes that are considered "high priority", like Google,
YouTube, Yahoo, MS (at least their update servers), can be trusted to
propagate routes that are not aggregated/filtered, so as to give them
control over their reachability and immunity to longer-prefix hijacking
(especially problematic with things like MS update sites).
That's just inviting the injection of forged AS routes to commit
abuse.
Owen
Not if only trusted peers are allowed to advertise to that AS. It's the
same mechanism proposed for blackholing on destination to dampen DOS a
while back, except it is to prevent hijacking, and therefore doesn't run
afoul of the AT&T patent (and now the prior art for this is in the
public domain).
It's also something that can be built using the existing infrastructure,
and rough consensus.
How about state-of-the-art routing security?
Seriously -- a number of us have been warning that this could happen.
More precisely, we've been warning that this could happen *again*; we
all know about many older incidents, from the barely noticed to the very
noisy. (AS 7007, anyone?) Something like S-BGP will stop this cold.
Yes, I know there are serious deployment and operational issues. The
question is this: when is the pain from routing incidents great enough
that we're forced to act? It would have been nice to have done
something before this, since now all the world's script kiddies have
seen what can be done.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
Seriously -- a number of us have been warning that this could happen.
More precisely, we've been warning that this could happen *again*; we
all know about many older incidents, from the barely noticed to the very
noisy. (AS 7007, anyone?) Something like S-BGP will stop this cold.
As much as I love to make fun of Avi + Vinny, as7007 was not really the problem, Sprint running custom cisco code which wouldn't let go of prefixes after the router announcing them had been turned off for more than an hour was. Plus, problems which happened over 10 years ago is a bit far back in Internet time. 
Yes, I know there are serious deployment and operational issues. The
question is this: when is the pain from routing incidents great enough
that we're forced to act? It would have been nice to have done
something before this, since now all the world's script kiddies have
seen what can be done.
I would argue the answer to your question is "not yet", as we haven't done anything yet.
We can argue whether that is the "right" answer, but it is still THE answer.
It does sort of shed light on a sobering fact that some of the PCCW’s of the world are not using proper filtering, and with a coordinated effort, someone could inject a large number of routes into the global routing table through them effectively taking offline much of the Internet.
Anything more specific than a /24 would get blocked by many filters, so some of the “high target” sites may want to announce their mission critical IP space as /24 and avoid using prepends.
If the PCCW’s of the world are not going to sanity check inbound announcements from some of their peers, they should at least be prepending them to help fight abuse of this nature (accidental or not).
Also, IANAL, but there seems to be a misconception of what AT&T’s DDoS patent (application 20060031575) covers. The patent is not simply about blackholing an IP address, it claims “Such a selective black-holing scheme can be used to allow some traffic to continue in route to the IP address under attack, while other traffic is diverted.”
So simply blackholing everything destined to an IP address does not seem to conflict with the patent.
As a side note, it will be interesting to see how the youtube posters respond to this.
If Pakistan thought the site was offensive before, I doubt they will be amused at the backlash that will probably occur as the result of this.
I have a feeling youtubers will be trying to 1up each other for most offensive video.
> 2: Within a jurisdiction where North American operators have a good
> chance of having the law on their side in case of any network outage
> caused by the entity.This is also a bit strange. Do your users never attach to a host
outside the USofA?
m.root-servers.net
i.root-servers.net
www.ripe.net
www.apnic.net
oops!
> 3: Considered highly competent technically.
Here we agree.
except that even the 'good guys' make mistakes. Belt + suspenders
please... is it really that hard for a network service provider to
have a prefix-list on their customer bgp sessions?? L3 does it, ATT
does it, Sprint does it, as do UUNET/vzb, NTT, GlobalCrossing ...
seriously, it's not that hard.
> OTOH: I would say that, until today, those who advocate not engaging
> in
> any kind of ethnic or political profiling would have considered 17557,
> as a national telco, a trusted route source.
no, unless they had some recourse (SFP agreement?) for such
behaviours... clearly said agreement wasn't in place so the PCCW folks
REALLY should have had some belt+suspenders approach in place.
As an aside, I'm against the 'golden prefixes' idea, because it
quickly devolves into a pay-for-play game where in the end everyone
pays a disproportionate amount 
-Chris
The problem is what is the actual trust model?
Are you trusting some authority to not be malicious or never make a mistake?
There are several answers to the malicious problem.
There are fewer answers to never making a mistake problem.
The state of the art routing security proposals let the "trusted" securely make mistakes. At one time or another, I think every router vendor, every
ASN operator, every RIR, and so on has made a mistake at some time.
Yeah, I know some of those mistakes may have actually been malicious, but
so far the mistakes have outnumbered the malicious.
If someone comes up with the anti-mistake routing protocol ...
Why?
- Lack of clue
- Couldn't care less
- No revenue
Take your pick - or add your own reason. PCCW is not alone. They just happen to be the latest in a long line of ISPs that follow the same rules - their own.
-Hank
"we've been warning that this could happen *again*" - this is happening every day - just look to:
http://cs.unm.edu/~karlinjf/IAR/prefix.php?filter=most
http://cs.unm.edu/~karlinjf/IAR/subprefix.php?filter=most
for samples. Thing is - these prefix hijacks are not big ticket sites like Youtube or Microsoft or Cisco or even whitehouse.gov - but rather just sites that never make it onto the NANOG radar.
-Hank
Right. Everyone makes mistakes, but not everyone is malicious. And
the RIRs and the big ISPs are *generally* more clueful than the little
guys and the newcomers. Note also that secured BGP limits the kinds
of mistakes people can make. If I have a certificate from my RIR for
192.0.2.0/24, I can't neither announce 10.0.0.0/8 nor delegate it to
you, no matter how badly I type. Secured BGP still strikes me as a net
win.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
All good, er, bad reasons. Fixing the "filter your downstreams" problem is very important. It would also solve 90-something percent of the problems mentioned in this thread. E.g. as7007. 