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. 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. 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. On Tue, May 12, 2009 at 12:44 PM, Steven M. Bellovin <smb@xxxxxxxxxxxxxxx> wrote: > On Tue, 12 May 2009 09:25:07 -0400 > Phillip Hallam-Baker <hallam@xxxxxxxxx> wrote: > >> Looks to me that we have an obscurity based 'security' system going >> on there. > > Everyone in the business understands that there is a routing security > problem. There is some disagreement about the magnitude of the threat, > and hence about how much one should spend on defense (as opposed to > cleaning up afterwards), but there is no disagreement that there is a > problem. > > On the other hand, none of the previous proposals solves it properly; > all of the proposed solutions have their own serious flaws. > >> >> At RSA there was a presentation on security holes in IPSEC and SSH. In >> the IPSEC case the response 'from the IETF' (i.e. from a well known >> individual speaking on his own behalf) was that the security issues >> with using IPSEC without authentication were well known and that this >> is not new. To which the reply came, well why did you continue to make >> support for encryption only mandatory? > > Your writing here is unclear. I assume you mean that current IPsec > standards support encryption-only without authentication. I agree -- > that was a bad decision by the WG. It was not done blindly, or in > ignorance of the attacks. The case was made that there are some > situations (video over IP with per-connection keying, for example), when > the attacks are inapplicable and the costs are high. The WG was > persuaded that this need overrode the potential for misuse. As I said, > I did and do disagree. > >> >> There is unfortunately a naive view that we can solve the BGP security >> issue by simply sprinkling some IPSEC pixie dust on it. > > I've been working on routing security for >20 years. I've never heard > *anyone* competent suggest IPsec for this problem. Next straw man, > please? > >> I think that >> view is based on a profound misunderstanding of what is possible with >> a packet layer security protocol. Key agreement and crypto-packaging >> are trivial problems that can be solved by a moderately competent grad >> student. The hard part is the problem that IPSEC never solved, how to >> establish the trust context. And once you look at that problem you >> soon realize that IPSEC is the wrong tool entirely as the routing >> problem requires you to take an accountability approach which in turn >> requires you to work at the message level. >> > `May the day not be too long delayed,' said Boromir. 'For > though I do not ask for aid, we need it. It would comfort us to > know that others fought also with all the means that they > have.' > > `Then be comforted,' said Elrond. `For there are other > powers and realms that you know not, and they are hidden from > you. Anduin the Great flows past many shores, ere it comes to > Argonath and the Gates of Gondor.' > > Tolkien, "Lord of the Rings" > > There are many people still trying to figure out how to solve this > one. It's a hard problem. > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf