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(_at_)cs(_dot_)columbia(_dot_)edu> wrote:
On Tue, 12 May 2009 09:25:07 -0400
Phillip Hallam-Baker <hallam(_at_)gmail(_dot_)com> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf