Forgot your password?
typodupeerror
The Internet Security Technology

Engineers Ponder Easier Fix To Internet Problem 75

Posted by Soulskill
from the have-you-tried-turning-it-off-and-then-on-again dept.
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."
This discussion has been archived. No new comments can be posted.

Engineers Ponder Easier Fix To Internet Problem

Comments Filter:
  • Well???? (Score:3, Funny)

    by Anonymous Coward on Friday April 27, 2012 @05:19PM (#39826619)

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

    Please tell us so we can get to 4.

    • by Anonymous Coward

      3. Start a laundry service that goes to network admins' offices and cleans their soiled underwear onsite?

      After all, if their entire company is knocked off line, you know they'll shit their pants.

    • by Dwonis (52652)
      3. Fake virus attack.

      How do you think I lasted 30 years in IT?

  • Problem (Score:5, Insightful)

    by girlintraining (1395911) on Friday April 27, 2012 @05:20PM (#39826635)

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

  • ....so why read TFA?

    • by billstewart (78916) on Saturday April 28, 2012 @01:15PM (#39832539) Journal

      TFA wasn't very detailed either, but it mentions that the new protocol is called Rover. Project website is here. [secure64.com] 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.

  • by jeffasselin (566598) <cormacolinde@gmail . c om> on Friday April 27, 2012 @05:21PM (#39826653) Journal

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

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

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

    • by msauve (701917)
      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.

  • ...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!

    • by Belial6 (794905)
      Do you really not know the answer to your question?
    • by PPH (736903)
      Don't worry. We've just demoted itwbennett to the IT department. In charge of maintaining the routing tables.
  • The big fix... (Score:4, Interesting)

    by icebike (68054) * on Friday April 27, 2012 @05:23PM (#39826693)

    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?

    • by zAPPzAPP (1207370)

      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.

      • by the_B0fh (208483)

        Seriously? Go look up how DNSSEC works. You understand DNSSEC also covers subdomains right? And the DNS server that covers apple.com may not cover *.security.apple.com

        How the hell are you upvoted, I have no clue.

        • by Trahloc (842734)
          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
          • by the_B0fh (208483)

            I think it's me explaining it poorly. I was trying to point out you can send more shit along than just what's behind the current router.

          • Rover [secure64.com] 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

      • Re:The big fix... (Score:4, Interesting)

        by jd (1658) <imipak&yahoo,com> on Friday April 27, 2012 @06:28PM (#39827429) Homepage Journal

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

    • by Anaerin (905998)
      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)
      • by Urza9814 (883915)

        I'm no network engineer, but if it's a malicious attack, wouldn't you have to assume that the attacker has at least some level of control over the router in question? And if so, if they're trying to force connections to a certain IP through that router, couldn't they just route those probe packets to themselves and spoof a response? Even if you encode information giving it a new route to go through in order to verify, couldn't the attacker just direct their response through that route as well (while maybe a

        • by Anaerin (905998)
          Yes, they could. But adding in those extra hops would delay packets sent through, making connections via the malicious route slower and thus less preferable. If the router in question is your only option then you're screwed, but if you're multi-homed, this will give you some way of verifying that differing available routes lead to the same range. If it's a malicious spoofing then you won't be able to get a response from the real site from the malicious router.
      • by the_B0fh (208483)

        You understand that BGP is used to manage routes right? Someone like Google would have tons of peers. That means they advertise their network to those peers.

        That means Comcast gets those route advertisements.

        So do TimeWarner

        So do Verizon.

        And so on and so forth.

        Now, you're in some dumbfucktown, but you're cool and hip and have redundant links to a couple of local ISPs. Guess where those ISPs get their links from? Time Warner, Verizon, etc. All of whom have a bunch of peering points...

        Following how the r

        • by Anaerin (905998)

          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 co

          • by karnal (22275)

            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

          • by sjames (1099)

            Nobody allows source routing anymore. You CAN'T ping with a set return route. The reply will come back through whatever route the far end and it's upstreams choose.

          • by wwbbs (60205)

            Your mixing up the different layers of networking. BGP operates at a much lower level than PING and/or Trace Route. Such that your statement is more misleading than informative.

      • 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 no

    • Re:The big fix... (Score:4, Informative)

      by Vancorps (746090) on Friday April 27, 2012 @05:51PM (#39827021)

      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.

    • BGP is at a layer higher than ip, so whether you are using IPv4 or IPv6 (or any other protocol), it does not matter.

      (And yes, i realize that the implementations of BGP often involve sending TCP/IP and UDP/IP packets around, but the point is that switching to IPv6 is not going to change your BGP configuration or BGP tables.)

    • Re:The big fix... (Score:5, Informative)

      by jd (1658) <imipak&yahoo,com> on Friday April 27, 2012 @06:12PM (#39827255) Homepage Journal

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

      • by Lennie (16154)

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

        The hierarchical addressing scheme for IPv6 never happend in practice. IPv6 is routed the same way as IPv4.

        But less prefixes are needed, because with IPv4 much smaller networks are allocated to providers. With IPv6 every provider network basically just needs only a few prefixes b

        • by jd (1658)

          *SIGH*

          *Beats ISPs over the head with a wet herring*

          Ok, correction noted, though it's good to see that at least fewer prefixes are needed so I'm at least half-right.

          *Beats IPSs over the head with a smoked herring, then lets the cats loose*

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

        I don't think this will play out. Yes there will be some aggregation thanks to generous allocation policies but it won't do anything about proliferation of shit routes by every dinky little corporation in the world and rich tech geeks who insists on being multi-homed. I would be very surprised to see the situation change much with IPv6.

      • by unixisc (2429386)
        Isn't IPSec still mandatory under IPv6? If it ain't, what made the IETF drop that requirement?
      • by dissy (172727)

        Further, the lack of NAT is something that has held back IPv6.

        Whaa? Why?

        Instead of using a private IP block behind a NAT box, just use a real IP block and a stateful firewall box.
        Identical effect as NAT would have, with the bonus that you are guaranteed no other machine on the internet will be on a private network with the same IPs you use so VPN tunnels won't break.

        You also gain the bonus feature that with a single config line change, you can put one of your private "NATed" machines out in your DMZ and don't have to reconfigure anything else but one entry on the fir

        • by TheLink (130905)

          You also gain the bonus feature that with a single config line change, you can put one of your private "NATed" machines out in your DMZ and don't have to reconfigure anything else but one entry on the firewall

          To people who care about security and know their stuff that is a bug not a feature. Think about what happens if one day someone fat-fingers the firewall config. The DMZ servers would be hardened so they might survive the exposure. The other machines on your private network are unlikely to be safe when accidentally exposed to the world. In many real world corporations there are usually servers that can't be locked down that tightly.

          IPv6 proponents using such "features" as arguments for adopting IPv6 gives me

          • by Tacvek (948259)

            You also gain the bonus feature that with a single config line change, you can put one of your private "NATed" machines out in your DMZ and don't have to reconfigure anything else but one entry on the firewall

            To people who care about security and know their stuff that is a bug not a feature. Think about what happens if one day someone fat-fingers the firewall config. The DMZ servers would be hardened so they might survive the exposure. The other machines on your private network are unlikely to be safe when accidentally exposed to the world. In many real world corporations there are usually servers that can't be locked down that tightly.

            Really? That's your argument?

            If you are using a many-to-many NAT setup (as many reasonably sized companies would require), you are able to place up to one machine in the DMZ per external IP. So the mistake in question is already possible without

            Furthermore many large companies have never used NAT, and they don't have these problems. They have only ever used public IP addresses, and a stateful firewall. They avoid issues like you are talking about by being careful, and having security in depth. For example

          • 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 b

      • 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 ad

        • by jd (1658)

          It would not eliminate accidental corruption, but attacks would be out of the question.

          That deals with your comments about erroneous advertisements. If you don't read my posts, don't expect me to bother with more of a reply than what I've already said.

          router-level IP mobility (the routers automatically redirected packets if you moved between networks)

          That deals with your comments about multi-home. Transient IP addressing assumed everyone could be multi-homed. Again, it really helps if you read what you're r

          • Sorry, didn't see your reply until today.

            > > It would not eliminate accidental corruption, but attacks would be out of the question.
            > That deals with your comments about erroneous advertisements. If you don't read my posts, don't expect me to bother with more of a reply than what I've already said.

            I read it. I contradicted it, and explained why you were wrong. IPSEC and its equivalents protect you from an attacker forging the network-layer origin of a message. They don't protect you from an att

    • 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?

      The issue here is that trying to solve any problem using PKI leaves you with two problems. What's new in this case is that it doesn't require successfully deploying a PKI, which means it's not predestined to failure.

      Another issue in this case is that a large percentage of BGP issues are due to glitches caused by legitimate ASes (misconfiguration, that sort of thing). Authenticating an erroneous mesage from a legit AS isn't going to help the problem.

  • by Anonymous Coward

    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

  • by ComputerInsultant (722520) on Friday April 27, 2012 @05:51PM (#39827025)
    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.
  • by 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 w

    • by Lennie (16154)

      Actually there is a lot of incentive, but the problems for BGPSec are:
      - you need to change the software on the router
      - the vendor has to add it
      - it will use a lot more CPU on your router, which can cause more problems than it solves
      - DNSSEC and BGPSec are brittle, many mistakes have been made, just look up

      and so on.

    • 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 wh

  • by Anonymous Coward

    "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

  • "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!"

  • by thepacketmaster (574632) on Friday April 27, 2012 @08:31PM (#39828651) Homepage Journal
    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.
  • 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
  • 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 repo

  • by Anonymous Coward

    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 [ripe.net]

If a listener nods his head when you're explaining your program, wake him up.

Working...