BGP Origin Authentication: What Are We Trying to Prove?

There was a long thread on NANOG just a couple of days ago about BGP security –see this message and this message, discussing this article in Slashdot about using DNS to solve the problem of BGP security on the ‘net. Can DNS solve this problem? Well, that’s a pickle of a question. Why? Because it all depends on what you think the question actually means.

To begin, we can break the problem down into two pieces: who should be advertising this destination, and do I have a valid path to reach it? For the moment, we’ll only look at the first problem, because that’s the only one that relates to using DNS within the BGP security context. To put this in BGP parlance, what we want to know is whether or not the origin autonomous system (AS) in the BGP advertisement represents someone who actually owns (or is authorized to use) the address being advertised.

Who authorizes an AS to advertise a particular address, and why should we trust them? Well, we all know the RIRs authorize the use of address space, so we should all just be able to look at the  naming authority’s databases and know, for certain, that certain organizations own certain IP addresses. In security terms, we have a natural single root for all the information, so we can have a single signed root, as well. In fact, the current RPKI work in the SIDR working group presupposes a single root that assigns and signs all IP address allocations.

Great! This should be so simple… Or is it?

How do we know which organization owns which AS number?Are the RIRs really in the business of ensuring people are who they say they are? If I walk into a bank and sign a check for a million dollars, the teller certainly knows it was me who signed the check –but how do they know who I am?

What if one company allows another company to “borrow” address space? What if there is a contract dispute between the RIR and the company –should the company’s routing be shut down  while the dispute is settled? If a bank or a service provider loses the right to use their address space for a month while contract details are being sorted out, there’s no point in even opening the doors again after the month is over.

Okay, so this is more complex than we thought.

What DNS offers is a solid, well designed, and well understood system, including signing capabilities, managed by multiple roots on a global scale. With DNS you’ll need to have enough routing working to reach a DNS server in order to get the security information you need to validate the origins in the BGP table.

What the RPKI proposed by SIDR offers is a new system with a single security and authority root, and theoretical peer to peer data replication (through RSYNC). Using an RPKI, you’ll need to have enough routing working to get to a peering server to replicate the data.

And here we return to the original problem: what does the question mean? Is a single authoritative root an asset, or a liability? Is a group of interlocking communities better, or worse? Is it worse to need routing to reach a DNS server, or an RPKI replication server? Are these even technical questions, or do they fall into the domain of business operations and the philosophy of the ‘net?

What do you think?

About Russ White

Russ White is a Network Architect who's currently looking for a new challenge. He's scribbled a basket of books, penned a plethora of patents, written a raft of RFCs, taught a trencher of classes, and done a lot of other stuff you either already know about, or don't really care about. If you want letters, well... BSIT/MSIT (Capella University), CCIE #2635, CCDE 2007:001, CCAr. So there.

  • http://twitter.com/petrlapu Petr Lapukhov

    I’ve got another question here. Do we even need to route origin validation that badly? The fact is, Internet is a money-making cow to practically every player (even criminal). Their behavior is driven by economic reasoning, which keep situation close to some equilibrium. Stealing a route would not bring too much money, unless it’s done for the purpose of blackmailing ;) Then again, there is a level of indirection (DNS) to protect against that too.

    All these combined, in my opinion, reduces practical use cases of BGP security to either guarding against misconfiguration or a software bug. The latter, however, could probably not be prevented by validation policies. Quite on contrary, adding security checks would increase software complexity and chances of a large-scale outage to happen (e.g. recall recen Junos bug triggered by a BGP announcement)

    • Anonymous User?

      Petr, perhaps chat with vijay some?

      • http://twitter.com/petrlapu Petr Lapukhov

        Sure :) It’s just that whole BGP security story has been going since 90′s AFAIR – and the economy of the things is such that ASP/CSP would “prefer” to have routing security to minimize the risk for themsleves, while ISP’s see little value for their own businesses. And even from ASP perspective, the risk of prefix hijaaking isn’t that serious, with the existence of large CDN’s performing actual request routing. After all, let’s face it, there has been only a few “major” incidents last 15 years, and every time there was more noise around it than actual impact caused :)

    • Russ White

       There are a lot of different questions here, balled into one. :-) Is BGP security worth it? Depends on how much it costs, and what you mena by “BGP security.” If it’s going to cost replacing every router in the ‘net, it’s going to be hard to justify, for instance.

      But let’s try and ask it another way –are there large banks and other organizations willing to pay something for making certain their routes aren’t hijacked? I would think so –though even here you get down to “how much are you willing to pay?”

      Another way to ask this question is –is there some way to introduce security in a way that actually improves convergence across the ‘net? This might be counter-intuitive, but… Maybe it’s possible.

      Security is all about tradeoffs. How much are you willing to pay for how much protection. It often seems, to me, that in the networking world, we treat security as either “it’s perfect,” or “it’s worthless.” This false dichotomy often causes us to do nothing rather than something, because the “something” that’s available isn’t “good enough.”

      Now to really raise your blood pressure –”obscurity is not security” is, I think, often one of those cases where we push ourselves into this false dichotomy. Maybe that’s worth writing a post on…

      • http://twitter.com/petrlapu Petr Lapukhov

        So it all boils down to the economics reasoning still? :) To me, the problem of security in distributed systems is that ALL parties need to cooperate to make it happen. And per the game theory rules some players may find no benefit in forming a coalition :)  Of course, the “non-conformants” may get “bypassed” by using overlays, which brings us to “limited” deployments.

        I would agree that for large “private” BGP routing systems implementing origin/path validation is desirable and feasible from security standpoint. However, for the same systems, there are probably other, much higher risks, than routing system hacking that should be addressed first. E.g. a bank would be probably much more concerned with CC fraud than false route advertisement. So if we sort out the risk rating spectrum, routing hijacking might (?) fall somewhere in the diminishing part.

        Has such risk evaluation ever been done? That’s a question I don’t have answer for… 

  • http://etherealmind.com Etherealmind

    Geoff Huston, for AARNET and potaroo.net, makes to the case for Route Authentication very eloquently in this podcast on Packet Pushers – “Lies and Routing in the Internet” http://packetpushers.net/show-93-lies-routing-internet/

    Geoff explains he security threat and the business impact quite nicely I thought. Basically, ISPs cannot be trusted to protect their customers. 

  • Russ White

     You’ve hit the nail on the head with the game theory likeness… There are three solutions to that problem. The first is declare the problem unsolvable. I actually don’t think that’s an unreasonable solution in some cases –the question us, how do you make that not the default answer to the problem?

    Another is –have someone with authority mandate a that a solution be deployed. This is essentially what the RPKI solution essentially does. The NCCs, as the owners of the address space, get to say how to solve the problem. If you want to play, you’ll play by their rules.

    Another option is for the community to decide to build a system using existing processes and tools, and to use standing within the community as the coercion point.

    The question is not, “should we be doing this?” The question is, “Is this how we want to do this?”

    Which does the commuinity want? Is a single trust anchor the right solution within the context of the Internet? Or is a more distributed model a better fit for the community? Is it the right thing to do to tie routing to legal status? Or should there be some degree of separation between these two?

    These are the questions don’t think we’re doing a good job of answering right now –but that need to be asked, and need to be answered.