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."

Comments

Well????

[Anonymous Coward]

1. Tell everyone routing is broken.
2. Break it.
3. ???
4. Profit.

Please tell us so we can get to 4.

Re:Well????

[dgatwood]

Or crawl through the barrage of bullets muttering something about uptime (obligatory xkcd).

Problem

[girlintraining]

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."

Bad summary

[jeffasselin]

", but routers don't verify that the route 'announcements.'" what?

Please fix this sentence, it hurts when I try to read it :-(

Re:Bad summary

[fahrbot-bot]

It's a partial direct quote from TFA:

But the routers do not verify that the route "announcements," as they are called, are correct. Mistakes in entering the information -- or worse yet, a malicious attack -- can cause a network to become unavailable.

Re:Bad summary

[msauve]

Bad summary - there are two links, both with text which describes problems with the current system, and neither of which would seem to point to this "Easier Fix" mentioned in the headline. Why not link some text which at least makes minimal sense, like "...experts have found an easier way."?

", but routers don't verify that [sic] the route 'announcements.'"

It's easy to understand your confusion - you're not reading what was written.

The big fix...

[icebike]

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?

Re:The big fix...

[zAPPzAPP]

So what if the IP does not belong to the router, but to another router behind this one, which is where the info originated?

This is a network after all.

If the internet was only 2 routers head-to-head, the problem would be trivial.

Re:The big fix...

[Anaerin]

Wouldn't an easier way be to attempt a trace to the advertised destination through the router that advertised it? Then if Router A says "You can get to 192.x through me!", and probes sent to the 192.x range through that router fail, it's obvious that Router A is sending false/misleading advertisements. Then it doesn't matter at all who owns the group, just that packets go through correctly. It will also let the network self-manage optimal routes, as it can measure the return speed for the (newly discovered) route, and compare it with it's existing route - If the newer route is faster, it becomes the preferred route, if not it gets filed in a list in order of speed, with fastest first. When the current route fails, the router can go back through it's list to get the "next fastest route" and try that instead. To verify that it really is the correct route, and that it leads to the same servers, the router gets it's packets to return though it's existing route, thus verifying that the packet travelled to the same machines on the same range, even if they did go through the new route.

Re:The big fix...

[Vancorps]

Problem is the same size. If I have two or more routes to the same network then multiple routers are responsible for a given ip block. Its not really an attack vector because your create peering agreements with your providers and they are each responsible for holding up their own end of the deal. As disruptive as BGP errors whether malicious or through fat fingering are, it's not really that big of a deal to fix once the problem is identified.

I would think a DNSSec like infrastructure could help remove the possibility of malicious route modifications but in the end, if it's state sponsored then any system can be broken by even the proposed solution.

Re:The big fix...

[jd]

BGP for IPv6 is essentially the same as BGP for IPv4, so if the protocol has a security hole then it will appear on both. However, because IPv6 is designed from the outset to be a hierarchical addressing scheme, address tables should end up being much smaller (even though each entry is longer) which in turn means that accidents should be less common. If it's easier to see the consequences of your actions, you (in theory) should be less likely to make mistakes.

Back in the days when IPv6 mandated IPSec, the problem of malicious router table poisoning simply wouldn't have existed -- all router protocol traffic would be encrypted and every link would be encrypted distinctly, where the keys used for encryption are securely exchanged in an encrypted form via IKE or IKE2 and where the key exchange encryption key is either a shared secret or a public/private key pair. It would not eliminate accidental corruption, but attacks would be out of the question.

Also back then, automatic address assignment, router and service discovery (via anycasting) and router-level IP mobility (the routers automatically redirected packets if you moved between networks) meant that manual router configuration was almost unnecessary. Virtually everything could be discovered - including MTU - and so nothing really needed to be configured. This would have eliminated manual errors. In fact, that was the whole point of all these automated mechanisms. There would be no manual entry and therefore there would be no manual errors.

Telebit added a nice touch, creating a routing protocol that permitted segments of the network to be transparent (essentially the same as NAT, only far more fine-grained and flexible), although it seems they made the grievous error of not making their protocol public. Certainly I've seen nobody attempt to use it and there has been no reference to it since Telebit went under. Further, the lack of NAT is something that has held back IPv6. Given that Telebit had a working NAT equivalent in 1996, this is incredibly annoying. (Apologies if they did make it public, but it is still true that it's not used and that complaints about a lack of NAT have been a serious issue - made all the more serious precisely because the problem was solved and the solution deployed very very early on.)

So the answer is "if IPv6 is deployed as close to originally intended as possible, the problem simply doesn't exist - in any form; but that if IPv6 is deployed as it is currently used, the hole will hang around although it will be a little smaller".

Re:The big fix...

[jd]

Poisoned router tables will indeed "infect" other routers, radiating out until the correct route has a preferred weighting to the toxic route.

A wonderful example of this occurred in 1995 in England, when Manchester University's computer centre decided that it WAS America. (Now, I know they tend to have an ego problem there, but this was impressive.) Because redirecting traffic to Manchester required fewer hops and utilized greater bandwidth to any other route to America, you can guess what happened next. It took quite some time for the engineers to clean up the mess, because the newly discovered Northwest Corridor^wWormhole had been discovered by so many routers and the information was being gossiped around. Just as with humans, once gossip starts it is very hard to stop - even when the source admits it was false.

There's not a lot you can do in a case like that. Once an authenticated router starts having delusions due to buggy software/hardware, there's not much any other router can do to determine that it truly is a delusion. Multipath helps (if you support dividing traffic between multiple routes, according to viability, you'll only lose a percentage of traffic, not all of it) but you'd need active path monitoring to go any further. Which would reduce bandwidth (which is already excessively limited) and increase complexity (the primary cause of hallucinating hardware).

Re:The big fix...

[Anaerin]

Okay, so you run dumbfucktown.net, and you have connections through comcast and vzw.

vzw starts advertising that they can get to thisnet.com faster with an announcement.

Your router:

• Sends a traceroute to thisnet.com through vzw
• Sends a traceroute to thisnet.com through comcast
• Compares the two results, to see which completes, and which is faster.
• Pings thisnet.com through vzw, with a comcast return route
• Pings thisnet.com through comcast, with a vzw return route

If any of these fail, the new route is rejected completely. If they succeed, the route is classified and entered into the preference list based on it's performance.

If a route starts failing/returning errors, the requests are retried on the next available route in the list, continuing down the list until it is exhausted.

All dumbfucktown.net cares about is if the packets get there, and how fast. It doesn't care who owns the route, how new or old it is, or anything else.

This isn't foolproof, but it would work, I believe.

Disclaimer: IANANE

Re:The big fix...

[karnal]

One of the issues with this is that you don't get a choice in the network that packets return on. For instance, let's say I have a comcast circuit and a tw circuit. Let's also say I start a conversation with someone.tw.com. In my limited experience, someone on the tw network will always send their packets back to me using my tw circuit - regardless of which circuit I use to initiate the traffic on.

There are ways to fix this issue - one way is to make sure the device that issued the traffic out to someone.tw.com is only advertised out of your comcast circuit and not your tw circuit. Usually when having multiple circuits I've not seen this - unless you do something like nat the outgoing traffic on the egress router. That has it's own sort of issues depending on what you're trying to accomplish.

Re:The big fix...

[Trahloc]

Did you just poorly explain your analogy or have you never actually worked with BGP? You can announce your ips over one uplink, switch it to another uplink, then move them to a third all in a few minutes if you feel like it. You could tunnel your traffic across the internet and announce them from japan if you're bored enough. DNSSEC and BGP have nothing to do with each other and should never be compared to one another. BGP is proof positive that anarchistic systems DO work and trying to make it fall in line with some sort of structure is worse than the occasional screw up that can happen by some fat fingers.

Congressional Approval

[ComputerInsultant]

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.

Piggy backing on DNS is not a good idea.

[Anonymous Coward]

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.

Re:Playing grammar nazi today

[Belial6]

Do you really not know the answer to your question?

What if...?

[thepacketmaster]

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.

There's a working solution out there: RPKI

[8-Track]

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/

Solution is called Rover, Uses Reverse DNS

[billstewart]

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.