Made it to Slashdot too -
http://tech.slashdot.org/story/10/05/10/0056228/The-Status-of-Routing-Reform-mdash-How-Fragile-is-the-Internet
As usual I wouldn't recommend reading the comments unless you want your eyes
to bleed...
Scott.
same article as the one bellovin linked yesterday. but this version has
author attribution. thanks.
randy
I go back a step or two--I try very hard not to read AP.
Which pretty much takes me out of reading anything but the comics in the
"news"papers.
And a lot of the comics have become so politicized that I don't read
many of them any more.
a couple choice quotes:
"Spokesmen at AT&T Inc. and Verizon Communications Inc., two of the
largest, world-spanning carriers of Internet traffic, said they were
unable to find anyone at their companies who could discuss the issue
of routing reform."
guess they didn't find rexford's successor @7018 or schiller @701? oh,
well actually these folks don't do telephone networking so I guess it
makes perfect sense 
"Pieter Poll, the chief technology officer at Qwest Communications
International Inc., says that he would support some simple mechanisms
to validate data routes, but he argues that fundamental reform isn't
necessary. Hijackings are typically corrected quickly enough that they
don't pose a major threat, he argues."
qwest customers may want to take note here..."quickly enough" is how
much of your business lost exactly?
-chris
Christopher Morrow wrote:
"Pieter Poll, the chief technology officer at Qwest Communications
International Inc., says that he would support some simple mechanisms
to validate data routes, but he argues that fundamental reform isn't
necessary. Hijackings are typically corrected quickly enough that they
don't pose a major threat, he argues."qwest customers may want to take note here..."quickly enough" is how
much of your business lost exactly?
They filter my routes. Not sure what he's talking about.
Jack
just guessing but they probably don't filter 'peer' (SFP) routes, so
if say 2914 accepted a route from their customer ConEdison that
included a subnet of yours... boom goes your reachability
this is a matter of risk analysis. No secure routing means we'll continue
to see the occasional high profile outage which is dealt with very quickly.
Secure routing is going to introduce significant complexities into the
inter-domain routing system. Complexities lead to greater pilot error, and
pilot error leads to outages.
So while we may have fixed the 2 hour youtube externally derived problem
which we get once every couple of years, it's probably going to come at the
cost of having N hours worth of outages per year per ASN, because someone's
mucked up their configuration, or has let their cert expire, or whatever.
My gut instinct tells me that secure routing and the rpki venture well into
the realm of negative returns. But I would be really interested to see
some proper risk analysis in this area done by someone with clue.
Nick
my gut says things would do well to begin with simply making an effort
at maintaining usable irr data and automagically generating sane
filters. why don't people do that again? I hope I'm not naively
misunderstanding a primary use of irr data in front of 10,000 of my
closest friends...
APNIC allows you to put your BGP data in the whois, so like this you have a third party verification tool on who is peering with who.
There are a lot of problems associated with using IRRDB filters for inbound
prefix filtering.
- some clients announce lots of prefixes. This can make inbound prefix
filtering difficult in some situations.
pixiedust:/home/nick> grep '>' pakistani-telecom.bgpdump.txt | wc -l
967
- there are some endemic data reliability problems with the IRRDBs,
exacerbated by the fact that on most of the widely-used IRRDBs, there is no
link between the RIR and the IRRDB, which means that anyone can register
any address space. whois.ripe.net doesn't allow this, but lots of other
IRRDBs do.
- the ripe whois server software does not support server-side as-set
expansion. This is a really serious problem if you're expanding large ASNs.
- there is very little client software. At least irrtoolset compiles these
days, but its front-end is very primitive. rpsltool provides some really
nice templating functionality, but doesn't implement large sections of the
rpsl standards.
Nick
All of the major providers I have worked with have required proof of 'ownership' of address space or an LoA from the registered holder of that space before they would allow advertisements from me, which are then filtered. Is this not the norm? I can understand if they are talking about an operator making a mistake, but the article seems to imply that anyone running BGP can bring down the Internet... I think any competent provider can easily eliminate this threat from customers. Are there any types of penalties if an ISP is found to not be taking adequate precautions, other than the possible threat of losing business?
my gut says things would do well to begin with simply making an effort
at maintaining usable irr data and automagically generating sane
filters. why don't people do that again? I hope I'm not naively
misunderstanding a primary use of irr data in front of 10,000 of my
closest friends...There are a lot of problems associated with using IRRDB filters for inbound
prefix filtering.- some clients announce lots of prefixes. This can make inbound prefix
filtering difficult in some situations.pixiedust:/home/nick> grep '>' pakistani-telecom.bgpdump.txt | wc -l
967
There are certainly issues around what a customer may have as their primary path and what they are backup for. These issues make for very long prefix-lists.
- there are some endemic data reliability problems with the IRRDBs,
exacerbated by the fact that on most of the widely-used IRRDBs, there is no
link between the RIR and the IRRDB, which means that anyone can register
any address space. whois.ripe.net doesn't allow this, but lots of other
IRRDBs do.
Certainly this is a function that you can petition your local RIR to do, have you made a proposal to them?
- the ripe whois server software does not support server-side as-set
expansion. This is a really serious problem if you're expanding large ASNs.
Have you asked them to include this?
- there is very little client software. At least irrtoolset compiles these
days, but its front-end is very primitive. rpsltool provides some really
nice templating functionality, but doesn't implement large sections of the
rpsl standards.
I certainly agree the tools here are suboptimal, but is that the the reason to throw the baby out with the bathwater?
We're faced with a challenge here, where I surely agree with Peters argument that things won't get better here in the next ~7 years.
Who is going to be the provider that turns away business because their customer is unwilling to register their routes in a klunky-toolset? What improvements to the toolset should go back to the community to improve filtering? If there is no RIR <-> IRR link, will people be willing/able to get a certificate when RPKI becomes more readily available?
Will you accept a network outage because your certificate expires (vs a warning, ala SSL certs expired)?
There are many questions here that require engagement by community members to provide viable solutions. Challenges certainly arise when you have nation-state telecom operators/incumbents involved as well that are unaccustomed to being told they MUST do something they may be unwilling to.
- Jared
- there are some endemic data reliability problems with the IRRDBs,
exacerbated by the fact that on most of the widely-used IRRDBs, there is no
link between the RIR and the IRRDB, which means that anyone can register
any address space. whois.ripe.net doesn't allow this, but lots of other
IRRDBs do.Certainly this is a function that you can petition your local RIR to do,
have you made a proposal to them?
RIPE does this automatically. But I have no idea how this sort of thing
would be implemented between an RIR like ARIN and an IRRDB like whois.radb.net.
- the ripe whois server software does not support server-side as-set
expansion. This is a really serious problem if you're expanding large ASNs.Have you asked them to include this?
I've enquired informally and was left with the impression that it would be
difficult; the RIPE DB code is troublesome, and there are line protocol
differences between the ripe server and the merit server which would make
parsing an interesting proposition.
I certainly agree the tools here are suboptimal, but is that the the
reason to throw the baby out with the bathwater?
Not at all - I use prefix filtering in anger, and it works very well in its
place.
Who is going to be the provider that turns away business because their
customer is unwilling to register their routes in a klunky-toolset?
Lots. They'll certainly take on the business, but I know of several
well-known names who provide service in Dublin and who won't accept your
prefixes unless they are registered in an IRRDB.
What improvements to the toolset should go back to the community to
improve filtering?
If you're offering to hack code, great - email me offline 
Nick
What we need (as operators) is to get better at ensuring that advertisements
are coming from the valid owner of said address space. What we don't need is
a separate governance model which I worry this article is trying to imply. I
still use RADB but I hear not every peer/provider checks there anymore? This
is hearsay so interested in other opinions.
As far as the mistakes pointed out in this article one can be assured that
these things are bound to happen. The youtube situation could have been
prevented if the peer opening a filter (and responsible for announcing out)
had reach to a system where the other peer's advertisement can be verified.
I don't think leaning on competency is a good way to go about solving this
problem, we need a system or model in place to ensure we have a trust and
verification system.
Zaid
The RIPE db doesn't allow that for routes corresponding to address space assigned by the RIPE NCC. For other routes, you can register whatever you want (so long as nobody else got there first).
I'm not complaining about this (I routinely recommend that people use the RIPE db for their non-RIPE address space because as far as I can tell it's about the best-maintained option, and it avoids all kinds of headaches trying to peer in Europe and send routes whose addresses were assigned elsewhere) but in the global context the idea that *everything* in the RIPE db has been subject to strong correlation with assignment/allocation data is false.
Joe
inetnum: 0.0.0.0 - 255.255.255.255
netname: IANA-BLK
descr: The whole IPv4 address space
country: EU # Country is really world wide
org: ORG-IANA1-RIPE
admin-c: IANA1-RIPE
tech-c: IANA1-RIPE
status: ALLOCATED UNSPECIFIED
remarks: The country is really worldwide.
remarks: This address space is assigned at various other places in
remarks: the world and might therefore not be in the RIPE database.
mnt-by: RIPE-NCC-HM-MNT
mnt-lower: RIPE-NCC-HM-MNT
mnt-routes: RIPE-NCC-RPSL-MNT
source: RIPE # Filtered
inet6num: 0::/0
netname: ROOT
descr: Root inet6num object
country: EU
org: ORG-IANA1-RIPE
admin-c: IANA1-RIPE
tech-c: CREW-RIPE
tech-c: OPS4-RIPE
mnt-by: RIPE-NCC-HM-MNT
mnt-lower: RIPE-NCC-HM-MNT
mnt-routes: RIPE-NCC-RPSL-MNT
status: ALLOCATED-BY-RIR
remarks: This network in not allocated.
This object is here for Database
consistency and to allow hierarchical
authorisation checks.
source: RIPE # Filtered
mntner: RIPE-NCC-RPSL-MNT
descr: This maintainer may be used to create objects to represent
descr: routing policy in the RIPE Database for number resources not
descr: allocated or assigned from the RIPE NCC.
admin-c: RD132-RIPE
auth: MD5-PW $1$ScJSM7nN$Xw3aAduCRZx4QUEq8QjR5/
remarks: *******************************************************
remarks: * The password for this object is 'RPSL', without the *
remarks: * quotes. Do NOT use this maintainer as 'mnt-by'. *
remarks: *******************************************************
mnt-by: RIPE-DBM-MNT
referral-by: RIPE-DBM-MNT
source: RIPE # Filtered
this is a matter of risk analysis. No secure routing means we'll
continue to see the occasional high profile outage which is dealt with
very quickly.
how soon we forget 7007, 128/8, ... over a day each, and global, and
very big netowrks.
if something like those happen again, we are gonna be spending a lot of
time explaining our selves to people who wear funny clothes, and telling
them why it is not going to happen again if they let us keep our jobs.
randy
ROTFLMAO. Competent provider? Penalties? Threats? You made my day.
-Hank
"Just how fragile is the internet?"
Rhetoric, much?
Interestingly, the article misses interception and other non-outage potentials due to (sub) prefix hijacking.
-Tk
At the risk of seeming to be a conspiracy theorist, I am worried that
with "Central Authority" we might not have "hijacking" but "rerouting
for inspection and correction".