Slashdot Mirror
Engineers Ponder Easier Fix To Internet Problem
itwbennett writes "The problem: Border Gateway Protocol (BGP) enables routers to communicate about the best path to other networks, but routers don't verify the route 'announcements.' When routing problems erupt, 'it's very difficult to tell if this is fat fingering on a router or malicious,' said Joe Gersch, chief operating officer for Secure64, a company that makes Domain Name System (DNS) server software. In a well-known incident, Pakistan Telecom made an error with BGP after Pakistan's government ordered in 2008 that ISPs block YouTube, which ended up knocking Google's service offline. A solution exists, but it's complex, and deployment has been slow. Now experts have found an easier way."
1. Tell everyone routing is broken.
2. Break it.
3. ???
4. Profit.
Please tell us so we can get to 4.
So they've finally solved the problem of repressive governments disconnecting citizens from the internet, preventing the free flow of information, being co-opted by large corporations, and a litany of jurisdictional issues that have caused many people's lives to be ruined?
"No, they just made it so this can only be done by those people, and not your people. Our people are, of course, better than your people, being authoritative, responsible, and all of that."
#fuckbeta #iamslashdot #dicemustdie
....so why read TFA?
", but routers don't verify that the route 'announcements.'" what?
Please fix this sentence, it hurts when I try to read it :-(
If he explores all forms and substances Straight homeward to their symbol-essences; He shall not die.
...but routers don't verify that the route 'announcements.'
Verify that the announcements what? Are legit, make toast, or perhaps fart in their sleep?
My spelling and grammar are not good, but come on, edit those submissions and look professional!
Silence is a state of mime.
The solution is to have routers verify that the IP address blocks announced by others routers actually belong to their networks. One method, Resource Public Key Infrastructure (RPKI), uses a system of cryptographic certificates that verify an IP address block indeed belongs to a certain network.
Well duh! You would have thought this was the case already. Why are we worrying about state sponsored cyber attacks if we leave a hole this big wide open?
Can any network gurus out there tell me if this problem still hangs around after ipv6? Does it get bigger?
Sig Battery depleted. Reverting to safe mode.
WUT?! =O
FTFA - "The specifications are currently in "internet daft" status before the Internet Engineering Task Force."
But will it make the Internet Harder, Faster, and Stronger?
-AC
Do these engineers have approval from the US government to make these changes? Changes like this could break the ability to break the Internet. Can't have that.
engineers are all basically high-functioning autistics who have no idea how normal people do stuff
Their suggest solution "stores the legitimate route information within the DNS". They think a centralized DB is better than BGPSec!? How stupid.
With the current situation there is at least a trust relationship where if a router consistently provides bad origins you can remove them from your list of routers to listen to announcements from. With storing the routing data in DNS you will be giving the core internet routing technology all the problems DNS has (more government control (SOPA, PIPA anyone)) and will be eliminating much of the benefit of a distributed trust network.
No, the right way to do this is to make the ISPs bite the bullet and implement BGPSec. Unfortunately there is little incentive for ISPs to implement this.
It's just like domainkeys and other systems that use DNS as a distributed database. And like DNSSEC prevents untrusted DNS caches from interfering with DNS information, this prevents untrusted routers interfering with routes.
It's all rather simple if you think about it and keep saying 'distributed database' plus 'signed route relationships'.
"Any sufficiently advanced incompetence is indistinguishable from malice."
This does not really seem to solve much of anything. It just makes detecting and chasing down potential routing problems much easier.
What good does querying a DNS server do if the routes have been hijacked and the hijackers took the extra step of making DNS inaccessable? Is a router really going to pull a route if they can't access a DNS server? If they even think about it good luck beating down complex failures.
I think combination of sane filtering practices and centrally managed but globally duplicated authoritative routing data is a better approach if your goal is to actually solve the problem rather than making it easier to detect and mitigate after the fact.
"Gee, hardly nobody is using the new, super-duper complicated system to securely verify this stuff. Oh wait, we already have a secure way to do this in place. Let's use that!"
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
The existing BGP protocol definitely has some security issues that need to be fixed and a PKI solution sounds great. However, is it wise to use a technology to verify route announcements when that technology relies on proper routing to be in place so it can communicate with DNS servers? On the surface this seems like a catch-22 or chicken/egg situation. I haven't had a chance to read the draft yet but hopefully this has been taken into account. Perhaps the article just didn't explain it well enough.
--
Luck is just skill you didn't know you had.
The advantages with ROVER are that no changes need to be made to existing routers, and it can work alongside RPKI. "The whole infrastructure of securing the answer [of whether the route is legitimate] already exists," said Gersch, who has authored two specifications for how to name a route and the type of record that could be inserted into the DNS.
I read statements like this from an engineering perspective and all I can think is, this sound to good to be true. We should use this because we won't need to do anything to make it work. I suddenly feel like I'm talking to someone in sales and marketing. It may be a bad transcription from the article's author, but it sounds like someone trying to sell me something.
The first statement is wrong on the face of it. Changes will have to be made to routers in order to make decisions based on the new data, magic doesn't just make it work.
The second statement is partially true. But it would be more accurate to say, a distributed database (DNS) already exists in which we can try to store this data. The way it is stored and the software for pulling the data, however, doesn't already exist. So, parts of the infrastructure exist, but the implied whole infrastructure certainly does not. At a minimum software changes, and possibly hardware changes, will have to be in place throughout the internet for these changes to work. I'm not sure how that is any different than any solution to this problem.
I think the paragraph that says RPKI is complex and deployment has been slow is a lie, quite frankly. The five Regional Internet Registries (RIRs) have been heavily involved in the RPKI system, because they are the authoritative source on who the legitimate holder of a certain IP address block is. They launched a service to facilitate RPKI on January 1st, 2011 and adoption has been incredibly good for such a cutting edge technology (for example compared to IPv6 and DNSSEC). Since the launch, more than 1500 ISPs and large organizations world-wide have opted-in to the system and requested a resource certificate. The service that the RIRs offer, along with several open source packages by third parties for management, ensure that network operators only have to worry about entering data and not any of the crypto, making it robust and easy to use. With their certificate, an ISP can make a validatable claim – known as a Route Origin Authorisation (ROA) – about their prefixes, stating "As the holder of these IP prefixes, I authorize this Autonomous System to originate them". There are over 800 ROAs in the global system, describing more than 2000 prefixes ranging from /24s to /10s, totaling to almost 80 million IPv4 addresses. All in all, RPKI has really good traction and with native router support in Cisco, Juniper and Quagga, this is only getting better.
Global deployment statistics can be found here: http://certification-stats.ripe.net/
One thing ISP experts are pretty skeptical about current plans of securing BGP (apart from the fact that it has to be used wide-spread to actually make it work) is that they use some central key for signing the routes - which means that governmental agencies could easily shut down whole parts of the internet by revoking a signed key, effectively removing a prefix/route from the global routing table ... therefore, any technically sound protocol (and safe from "the powers that be") would need some public repository that can not be controlled ...
I saw ROVER presented a couple weeks ago at an Internet conference (RIPE-64) and I hope any engineer that actually looks at the protocol realizes it's hacks upon hacks and doesn't solve anything.
It's really not worth a news article, so I'm just trying to warn anybody before they get their hopes up. I'll just leave you with the slides if you want to check for yourself:
https://ripe64.ripe.net/presentations/57-ROVER_RIPE_Apr_2012.pdf
I don't see anyone here mentioning the fact that there are already policy tools at BGP level. Hell there is even a routing policy database where you can find which routes belong to which AS and group of ASNs and filter the received announcements as is. The Pakistan route injection was NOT a BGP fault but was only a fault caused by a relaxed routing policy at some Tier 1 ISPs. So I only see RPKI as another way of making money out of suckers than a real solution. End of story, nothing to see here move along.
If DNS fails, ROVER fails too. This is a very bad idea!!! We have already seen the problems of DNSSEC caused by law enforcement. RPKI is a nightmare for managing a network. Both solutions are prone to cause more trouble than without them. The best way to gain some protection is to use prefix filterlists generated based on the routing objects in the whois databases of the RIRs. Also set prefix limits. Have some kind of sign-off for larger changes in routing objects.
The problem is not the lack of security solutions, it's the lack of using the available solutions. A lot of ISPs still don't use prefix filterlists. Shame on them! Do you believe those ISPs will implement RPKI or ROVER? It's too complex for them.
And don't forget that the routers have to handle the choosen security solution for 400k+ routes. It's not hard to overload a routers CPU by a lot of routing changes. If you add complex security solutions it will be easier than ever before, by mistake ;-)
TFA wasn't very detailed either, but it mentions that the new protocol is called Rover. Project website is here. The short summary is that you can use Reverse DNS to advertise the BGP Autonomous System Number (ASN) that's authoritative for your block of address space, and use DNSSEC to protect the Reverse DNS tree. If somebody else starts advertising that they've got a route to your address block, routers (or route servers sitting next to the routers, because your standard router doesn't actually know how to do this) can verify whether that's correct.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Rover uses the Reverse DNS tree to advertise records that say that some address block [e.g. 0.192.in-addr.arpa] belongs to some ASN [e.g. 65535]. And you can use DNSSEC to verify that the rDNS advertisement for the address block is valid. This lets your routers (or at least the router-server you've got sitting next to your routers) validate whether a BGP announcement they receive is plausible.
And BGP's not at all anarchistic - the ASN assignments and IP address block assignments are both owned by IANA or its delegates (ARIN, RIPE, etc.), which is why it's meaningful to discuss whether a route advertisement is legitimate. The problem this is trying to solve is that people have been announcing routes they don't legitimately own, whether it's the kind of fat-fingers classful addressing autosummarization mistake that takes your two Class C subnets and announces the Class A that contains them, or whether it's Pakistan's PTT advertising YouTube's address blocks to keep Pakistanis (and the rest of the world) from watching politically incorrect videos on YouTube. (The fat-finger version happens more often, which is why you'll see ISPs that own a /8 advertising it as two /9s, so they can use longest-match to protect their space.)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
IPv4 and IPv6 address space assignment is already hierarchical. IANA owns the whole space, and delegates it to the regional registries (ARIN, RIPE, etc.) which hand out blocks to customers, whether it's an IPv4 /8 to a big ISP (which hands out /24s, /29s, etc. to its customers) or an IPv6 /48 to an end user company (which assigns subnets to different buildings and LAN segments.)
And the Reverse DNS tree maps those hierarchies.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
First of all, IPSEC or its IPv6 equivalents don't help you here. The main problem is some router advertising "I've got a great route to ASN12345" or "My ASN 67890 owns 12.0.0.0/8" when that's not true, and some other router it's connected to believing those bogus advertisements and passing them along. If BGP were wrapped in IPSEC, that would mean that nobody could eavesdrop on the bogus advertisements, but the problem isn't protecting the transport layer for the bogus advertisements, it's verifying the advertisements themselves. IPSEC might be able to protect you against forged BGP messages on trusted connections, but that's a much less important attack. IPv6 itself does eliminate the "classful route autosummarization" version of fat-fingering that lets your antique Cisco router decide that since it sees two /24 subnets from a Class A /8 block, it should be efficient and advertise the Class A block to its upstream, which has resulted in things like MAE-East's traffic all pointing at one little incompetent ISP's T1 line or a small ISP in South America grabbing any connections from the rest of South America to AT&T (which is why most ISPs that do have a /8 block will also advertise a pair of /9s.)
The "everybody's going to happily use hierarchical addressing" concept never played out, because it didn't address business reality or other end user needs. Businesses need their incoming connections to be dual-homed for reliability, and even if they don't have their own Provider-Independent address space, they still need to advertise their PA space from ISP A on their ISP B connection and vice-versa, so the route tables are going to be almost as large from subnet advertisements even without PI space. Reliability was critical even before the whole world moved onto the Internet, and even though ISPs have become much more reliable than they were in 1995, IPv6 support was pretty much experimental and spotty until, well, yesterday or maybe tomorrow, so you still can't be sure that your connection to ISP A will reach everybody in the world when your connection to ISP B is down. Businesses had three main reasons for wanting to own their own IPv4 address space - dual-homing for reliability, convenience when switching ISPs for business/pricing/etc. reasons, and being sure they could get enough address space if they switched ISPs. IPv6 doesn't help the dual-homing issue, though it does fix the getting-enough-space problems, and makes renumbering easier (though RFC1918, NAT, and DNS have eliminated 99% of that problem.) Switching ISPs happens on a timescale of months or at least weeks, so you can deal with the time it takes for DNS caches to expire and browser sessions to close, and IPv6 lets you use multiple IP addresses on the same interface, so maybe a coordinated early effort by the big ISPs, ICANN, IANA, and IETF could have helped the politics, but the ISPs and ICANN were dragging their heels for decades, Jon Postel was dead, and Cisco was way late in supporting IPv6. So that didn't happen.
Eventually some people realized that dual-homing really really was important, and that no amount if "But IPv6 was meant to be used hierarchically" would get people to give up their PI space or route advertisements, and tried to do something about it, giving us the appallingly ugly breakage called shim6, and don't hold your breath waiting for every piece of software in the world to adopt it before anybody can give up dual-homing. Meanwhile, the equipment that's been most stubborn about renumbering is IPSEC tunnel servers and clients, which tend to have hard-coded addresses instead of using DNS or other servers to find out who to talk to - I'm not convinced that IPv6 gear of the same vintage wouldn't have had the same problems.
IPv6 didn't eliminate manual router configuration, though it theoretically lets you move some functions from routers onto other servers. Autoconfiguration meant that you didn't have to assign IP addresses
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Harrumph. SLAAC wasn't a poor reimplementation of DHCP, kid. DHCP was that new stuff defined in 1993, though it was based on BOOTP and RARP (from 1984-1985, which let a workstation look up the IP address that was manually assigned to its MAC address.) SLAAC was based on the autoconfiguration capabilities in IPX and XNS, which were also around in the early 80s. If your office equipment didn't need to talk to anybody else, you could just plug everything in and it would Just Work. If you needed to talk between multiple subnets, either because you had multiple offices or distance limitations, you'd announce the subnet blocks, and everything would still Just Work. Compared to typing MAC addresses into RARP/BOOTP server tables, which is what we had to do for diskless workstations, or even compared to typing IP addresses into individual client PCs or diskful workstations, Autoconfiguration was really cool!
And NAT wasn't around until the mid-90s either, and took a while before it only broke lots of things instead of everything, and people stopped doing lots of the cool things that it broke.
That's not to say that SLAAC doesn't have its problems, such as protecting against bogus router advertisements, but bogus DHCP servers are also theoretically a threat.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
You're misunderstanding how this works. It's not using DNS for routing. It's using the Reverse DNS tree to hang ASN ownership records onto IP address blocks, so you've got a mechanism for validating announcements about ASNs owning those blocks, and that ownership is already hierarchical, which is why there's a concept of "legitimate" here at all. The Reverse DNS tree has records about names such as 2.0.192.in-addr.arpa, which are about IP addresses 192.0.2.*, and is maintained (or not:-) by the people who actually own that address space. And ISPs do need to bite the bullet and administer their rDNS and DNSSEC already.
The problem we're trying to solve is that a "distributed trust network" makes it too easy to trust any random advertisement that comes down the wire, which breaks things if that advertisement is bogus. For instance, if some router says they've got a route to 192.0.2.0/24, you're going to look at it, see if it's better or worse than the route you've been using, and pass it along. But if they're lying, and they've got a better metric than your alternative routes, and you trust them, suddenly all your traffic for example.com is going into their black-hole or go to their man-in-the-middle server or whatever. This gives you a way to check whether their advertisement is plausible, and reject it if it's not. Every couple of years this happens with a big chunk of IP address space and some big ISP loses connectivity to South America or MAE-East or whatever, but it's probably happening on a small scale all the time.
This doesn't affect what governments and their henchpersons can do to the net. While we'd all like to believe that IP/IPv6 address space comes from the Internet Gods, in fact IANA, ARIN, RIPE, etc. are subject to interference by governments, though IP addresses and the corresponding rDNS names like 2.0.192.in-addr.arpa aren't very interesting to the Trademark Mafiaas and usually get left alone. But if they do decide to have a trademark lawsuit about who owns 31.3.3.7, or IPv6 2001:face:booc::/48, it's going to affect the IP address block, not just the DNS names 7.3.3.31.in-addr.arpa or c.0.0.b.e.c.a.f.ip6.arpa.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
First of all, the destinations aren't individual addresses, they're blocks of addresses, so you don't necessarily know a working address in the block. And even if you do know an address of a machine in that block, you don't know if it's willing to answer pings from you. (Both of which are really annoying, when you're trying to debug by hand :-)
And as Urza9814 points out below, if it's a malicious attack, the Bad Guy can be sure to answer (e.g. the Pakistan PTT probably put up a web page saying "You're not allowed to watch YouTube in Pakistan!", even though their route advertisement went to the whole world.) On the other hand, the random misconfigured router that's advertising a route to a whole /8 probably didn't do that, even before all the traffic for that /8 melted its T1 or E1 line.
And ping/traceroute response times aren't very predictable, especially on routers which make those low priority processes, so if a router takes an extra 10ms to answer because its CPU is busy with more important work, that doesn't mean it's 1000 miles farther away.
And routing isn't symmetric, it's often asymmetric, especially if you're messing around with testing routes to see if they're valid - if Router Z's best route to you goes through Router B, and you sent your test ping out Router C, you're still going to get the answer on Router B if you get it at all.
BGP has lots of metrics - raw speed isn't the only one, and often it's not the best one. Maybe your T1 line is the shortest-ping-time route to YouTube, but you want to use your 100 Mbps Ethernet for YouTube traffic anyway because the T1 doesn't have enough capacity, or maybe you want to use the cheap DSL line for web browsing traffic and save the T1 for database queries. Using raw speed as a routing metric is highly likely to lead to route instability and congestion collapse, as well as routers spending all their time calculating route changes (and thus being slower to respond to pings), chaos, anarchy, dogs and cats living together...
There are boxes out there which actually do track packet response times and reliability and use that to do routing, most commonly in hosting environments, and some people really like them. But they're a game for multi-homed end-users, not Internet backbones.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks