Subject: [sidr] AS_SET and AGGREGATOR Stats (was origin AS definition)

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Thu, 15 Jul 2010 18:42:34 -0400

We (at NIST) performed a detailed analysis of statistics related to
AS_SET and AGGREGATOR attributes in BGP updates and RIB entries.
A set of slides summarizing this study can be found at: 

http://www.antd.nist.gov/~ksriram/AS_SET_Aggregator_Stats.pdf 

The main observation we make is as follows:
When an AS_SET is present, then the AGGREGATOR attribute is
(A) Almost always present, and 
(B) For all practical purposes, matches with the ASN in the 
first AS position after (i.e., immediate left of) the AS_SET.
The few cases when the two don't match are predominantly
cases where the AGGREGATOR attribute is a private ASN (64512 - 65535).
There should no ROAs anyway with private ASNs 
(in the context of global eBGP).
These observations have implications for the {prefix, origin} or
ROA validation algorithms as discussed below. 

Geoff's email below (and also draft-ietf-sidr-roa-validation-06)
suggested that when AS_SET is present in an update,
"then the origin AS is taken as the AS component of the 
AGGREGATOR attribute [RFC4271], if present."
This approach does open up a new attack possibility
for prefix hijacking (besides the one where the attacker has to 
insert the legitimate AS in the first (i.e., origin) AS position).
This new attack possibility is described in slide 6.

We feel it is more secure if the origin is taken to be the AS 
in the first AS position after (i.e., immediate left of) the AS_SET
(instead of the approach described above).
We feel that our analysis supports this conclusion/recommendation, 
and the slides have the additional details.

Comments/questions are welcome.

Sriram

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Geoff Huston
> Sent: Friday, April 30, 2010 2:44 PM
> To: Sandra Murphy
> Cc: Chris Morrow; sidr wg
> Subject: [sidr] origin AS definition (was some sns about some political bs)
> 
> 
> On 01/05/2010, at 2:59 AM, Sandra Murphy wrote:
> 
> > The draft-ietf-sidr-roa-validation-05 contains this same specification, in the section John
> Scudder pointed to in his message of 3 Apr (section 2, page 3).
> >
> > The difficulty lies in the fact that the AGGREGATOR attribute is only a "MAY attach" in
> RFC4271.  The paragraph in draft-ietf-sidr-roa-validation-05 also contains a specification of
> what to do if there is no AGGREGATOR attribute available.  As I view the conversation,
> John objected to this second part of the draft's specification, not the first part.
> >
> 
> John suggested the following:
> 
> "Granted this is a corner case, but nonetheless I can't see what the reason would be for
> considering an intermediate AS (albeit the first one contained in an AS_SEQUENCE) to be
> the origin.  I suggest revising as follows: Consider the origin AS to be the contents of the
> AS_SET if it's a singleton set.  Otherwise the origin cannot be determined.
> 
> "Given that it's a corner case, you could also cut right to the chase and just call it
> undetermined if the path starts (or ends, in your parlance) with an AS_SET, period."
> 
> 
> > But the conversation spiraled from there.
> 
> Evidently.
> 
> What do those folk who have opinions on the topic think about the following text as a
> definition:
> 
>       A route's "origin AS" is defined as follows: If the final
>       path segment of the AS_PATH is of type AS_SEQUENCE, the "origin
>       AS" is the first element of the sequence (i.e. the AS in the
>       rightmost position with respect to the position of octets in the
>       protocol message). If the final path segment of the AS_PATH is
>       of type AS_SET, indicating that the route is an aggregate, then
>       the origin AS is taken as the AS component of the AGGREGATOR
>       attribute [RFC4271], if present. Otherwise, the route's origin
>       AS cannot be determined.
> 
> 
> Geoff