ietf
[Top] [All Lists]

Re: Security of BGP Re: Status of the 16-bit AS Number space

2009-05-12 22:25:49
On Tue, 12 May 2009 15:42:26 -0400
Phillip Hallam-Baker <hallam(_at_)gmail(_dot_)com> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf