On Tue, 12 May 2009 15:42:26 -0400 Phillip Hallam-Baker <hallam@xxxxxxxxx> wrote: > We can all agree on the fact there is a problem. That does nothing. > What matters to me is if we plan to do something about it before > crunch time comes. > > As for adding IPSEC to BGP, I would not want to comment on the > competence of the person involved. I will merely note that maybe the > proposal suffers from an over enthusiasm for a protocol they are > heavily invested in and an under-appreciation of the issues involved. > > > Before agreeing that the problem is 'hard', I would like to see > someone set out the security requirements with respect to a credible > operations model. > > In particular I find it utterly unbelievable that large backbone > corporation A is going to configure its border routers to simply > accept routing information from large backboe corporation B. If I was > responsible for large corporation A then every piece of external > routing data would be funnelled into a control center and the edge > routers would only respond to control instructions from the control > center. No matter what specifications and standards might opine, that > is how I would run my network. When you do run an ISP, let me know how well that actually works. > > We thus have two BGP security problems, an internal security problem > that can be solve adequately with existing infrastructure and an > inter-network BGP security problem that has some very difficult trust > issues to manage but certainly does not need to involve the > cryptographic capabilities of router hardware. I would not generate my > routing tables on a router. > > > The inter-network BGP security problem can then in turn be broken down > into the problem of binding an IP address block to an AS number and > securing the anouncement of routs for an AS number. The first is > relatively straightforward as the bindings are global. They can be > generated by the IP address block holder using a signature key > advertised through reverse DNS. The second is hard as routing data > requires us to consider a transitive trust problem. Yes -- we all know that. The devil is in the details. > > I don't think we can prevent an attacker from inserting a bogus route. > We can however deploy mechanisms that provide for accountability so > that parties who do introduce bogus routes are detected and face > consequences. And depending on the resources we are prepared to apply > we can make the deployment window really short. > I think the cost function goes up very rapidly as deployment time gets shorter. But let's do some arithmetic. First -- there are no fully-specified protocols on the table today that (in my opinion) are acceptable. What we have are a variety of research prototypes that are not adequate for production use on today's Internet. But let's suppose that someone has one in his or her back pocket and will post the I-D tomorrow. Then what? Do we want the IETF's imprimatur? Even if nothing is changed (and experience suggests that that's unlikely), the process will take about a year, if only to give people enough time to actually look at it in Stockholm, Hiroshima, etc. Next, Cisco and Juniper have to go off and design, code, and test. Meanwhile, other parties -- ISPs, RIRs, perhaps IANA, perhaps end-sites that speak BGP -- need to develop their own software and databases to manage the certificates that are required. Design of processes -- how does an AS get a certificate? What about sites with their own AS# but who do not wish to generate a key pair? -- takes time as well. Perhaps that will overlap the router code development. I don't know for sure how long all this will take, but my guess is 1.5-2 years. Remember that this is touching BGP; major ISPs do *not* like to run lightly-tested code trains, especially when BGP is involved. Only at this point can we get to deployment (and figuring out how to pay for it). Here, perhaps, more money can speed things up, though it's rather unclear to me where this extra money will come from. I don't know how long it will take to get the new code deployed throughout enough of the Internet to make a difference, but if hardware accelerators are required (and some past proposals, such as SBGP, would likely require them) it will take noticeably longer. Throwing money at this problem would help, but I don't know where that money would come from. Phil, I agree that securing routing is a big problem. It's the issue that got me interested in Internet security in the first place, >20 years ago! But simply asserting that people don't take it seriously isn't going to solve it. --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf