Re: [RPSEC] Re: draft-convery-bgpattack-00

[Charles Lynn <[e-mail]>]

Iljitsch,
				   
> There are other things that aren't explored well enough in S-BGP. One
> thing that bothers me a lot is the fact that a routing update must be
> generated for each neighbor individually.

This statement is incorrect.  S-BGP MAY sign a single update, that
includes the AS number(s) of each of the ASes to which the update will
be sent.  The current S-BGP code base supports this.

> I'm not convinced that having some kind of destination
> identifier in an update is necessary, but if it is it should still be
> possible to somehow group neighbors so the optimization remains intact.

The optimization remains intact.

> Did you calculate the extra memory needed for full S-BGP deployment
> throughout the internet?

The reference

http://www.ir.bbn.com/projects/s-bgp/NDSS00.S-BGP.ps

gives the numbers that were estimated at the time it was presented
(Feb 00).  The net has grown since then, of course, and the numbers
were based primarily on ARIN data.  Note that an initial deployment
would not need memory for a "full deployment throughout the internet"
as I think it is very unlikely that any security mechanisms will see
"full deployment", say within a year or so.  However I agree that the
numbers for a full deployment (of any security mechanism) need to be
examined so the, e.g., the router vendors can work the capacity
requirements into their product lines.  (I think that I've heard the
lament that "routers don't have enough memory for the current size of
the routing tables" for a couple decades. :-)

> And I think a solution where the routers themselves do all the
> authenticating is inherently problematic because of performance and
> security issues.

I'm not an ISP operator, but I would think (please correct me if my
view is off-base) that having to contact an external server to do the
processing whenever a router receives an update - as has been
suggested in some documents I have read - would be much worse, from
the reachability standpoint and the "high value target" perspective.
Do you think otherwise?

The above reference showed that "all the authenticating" is not that
much of a load for a router with a modern processor.  Since the time
the work was presented, crypto chips that can do thousands of
operations per second have become available.  I've heard of designs
for systems that can perform IPsec on 10 GBit links.  Note however
that some high-speed crypto peripherals could not meet their
advertised rate in the S-BGP context due to their way of handling the
switching of public keys.  (It turned out that software crypto was
actually faster than the hardware!)  I'm sure that the hardware folk
can design the chips to satisfy the requirements, if currently available
chip sets are found to be inadequate.  The VPN market should make the
hardware competitive.

> A flimsy lock on a colo rack isn't enough to protect your secret keys.

If someone can get to your hardware, you likely have more to be
concerned about than the secret key.  If the secret key (DSA private
key for S-BGP) is in a well designed piece of crypto hardware, getting
it out without someone noticing would be, I think, a very low
probability event.

> Well, we can use S-BGP as an example of what we should require.  :-)

Yes, please do.  It is an example of what can be done (an existence
proof if you will) that tries to consider the whole system and the
supporting pieces.  Drawing packet layouts and specifying a protocol
are the easy parts.

> However, I wonder if there isn't a less heavy-weight way to detect
> this situation than do public key crypto on each update.

There may be.  We need to consider the alternatives and especially the
requirements.  We should not dismiss options because someone thinks they
are too hard or take too much time or space or whatever.  Once we have
requirements, we can do the detailed engineering to see what solutions
we can collectively find, and what they "cost".

> One optimization would be to only check updates that would
> install a new better path towards a destination.

(The current S-BGP implementation can be configured to do this.)

> Also, AS paths are
> often very similar across a somewhat large number of routes, so there is
> probably a way to check the path once and accept many updates rather
> than do it for each update individually.

Yes.  But the S-BGP experience has been that the data structures (the
S-BGP team thought were) needed to do this took more processing time
and memory than not trying to use that optimization.  Maybe other
implementors, if we turn them loose on the problem, will find otherwise.


> It's a bit longer ago. Here it is again, with slight modifications:
<snip>

> AS2 trusts AS3 

What does it mean to "trust an AS"?  That you "trust" all the
employees of the organization that operates the AS?  That seems to
still be vulnerable to the historic "attacks" where an employee
mis-types something.

Maybe one reason that you have reached the conclusion that only the
first couple hops need protection is because the average AS path
length is very short -- the routing tables that can be found around
the net showed an average length something like 3.5 hops.  Thus the
notion of only needing to protect the first couple hops is "close" to
actually protecting the whole path.  Would you reach the same
conclusion if the average AS path length were, say, six or seven hops?

The notion of signing a list of possible paths seems, to me, more like
an authenticated topology than how packets should be routed at a given
point in time.  Do you have any estimates for how much space it would
take for a full deployment of such a mechanism?

Sandy commented...

> The signature scheme might be expandable so that you sign a set of
> neighbor identities into the update, rather than just one.  This would
> be useful if you had lots and lots of neighbors that you could break
> into a lot of groups of lots of neighbors, where the advertised routes
> to each neighbor in one group would be the same - then you would still
> get some optimization.  Would such situations be common?

Note that the "grouping" is unlikely to be "free".  It will take space
to record, processing cycles to implement, and management cycles to
maintain, for each or the posited hundreds or routers in an ISP.

And Iljitsch commented ...

> Yes, except maybe for the "lots of groups" part. A lot of traffic is
> exchanged at internet exchanges. Typically, all peer routers share the
> same settings for outbound updates. For instance, I manage a router with
> 103 peers in 4 groups, with the largest group having some 40 neighbors.

(I've been told that many ISPs are moving to private peering
arrangements.)  We certainly need to consider the case you have
described.  We need to get a list of all the topologies that need to
be supported into the requirements list.  Are there any others
(besides private peerings and internet exchanges) that are significant?

Charlie
_______________________________________________
RPSEC mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rpsec