Aggregation in S-BGP was RE: [RPSEC] Re: draft-convery-bgpattack-00

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