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

From: "Susan Hares" <[email-masked]>
Date: Wed, 6 Nov 2002 18:38:51 -0500

Charlie:

How does SBGP handle Aggregation or 
proxy aggregation?

Sue Hares

-----Original Message-----
From: Charles Lynn [mailto:[email-masked]]
Sent: Wednesday, November 06, 2002 4:21 PM
To: [email-masked]
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec
_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 7 Nov 2002 09:20:59 +0100 (CET)

> How does SBGP handle Aggregation or

Isn't aggregation anywhere else than at the source of the announcement a
relic from the BGP3 transition? Ie do people still use it?

Iljitsch

---

From: Charles Lynn <[email-masked]>
Date: Thu, 7 Nov 2002 10:58:14 -0500 (EST)

Hi Sue,

> How does SBGP handle Aggregation or proxy aggregation?

The basic model is that the BGP implementation combines some set of
routes into an aggregate.  The S-BGP mechanisms then insert into the
attestation path attribute (used to carry the signatures, etc.) enough
information to be able to verify all the pieces that were aggregated.

The number of Adj-RIB-In entries (and the FIB entries derived from it)
in speakers that receive the aggregate is thus unchanged by the S-BGP
mechanisms (provided that the content of the aggregate passes the
security checks).  However the size of the Adj-RIB-In entry for the
S-BGP protected aggregate is obviously larger than it would be for
the non-S-BGP case.

In cases where the aggregator claims to be the originator for the
aggregate, the organizations with the right to use the prefixes being
aggregated (which might happen to be/include the aggregator) need to
authorize the aggregating AS to do so, using the usual "address
attestation".

Iljitsch commented...

> Isn't aggregation anywhere else than at the source of the announcement
> a relic from the BGP3 transition? Ie do people still use it?

Last time I looked (viewpoints of routing UPDATEs vary), about 0.2 %
of advertised routes contained AS Sets (one form of aggregation).

To be clear, "aggregation ... at the source of the announcement" could
be interpreted as, e.g., by an ISP that aggregates routes from
customers that are using portions of the ISP's address space, or
alternatively as an ISP that aggregates routes from several sources
and claims to be the originator (removing information about the
aggregated routes to the NLRI in the process).  S-BGP handles either
form, but the latter produces a larger UPDATE message.

(In the cases we looked at, the aggregated UPDATE received by the AS
 that peered with an aggregating AS was larger than would have been the
 case if the aggregation had not been performed, but the aggregated
 UPDATE message was smaller than the sum of the non-aggregated UPDATEs
 for ASes two or more AS-hops away from the aggregator.  Additional live
 data from ASes doing aggregation -- the UPDATEs being aggregated and
 the aggregated UPDATE -- would be helpful for additional analysis.)

Charlie