Subject: [sidr] Comment about aggregators and AS_SETs

From: Jeffrey Haas <[email-masked]>
Date: Wed, 28 Jul 2010 13:14:13 +0000

Specifically with regard to the presentation on Measurement Data on AS_SET
and AGGREGATOR: Implications for {Prefix, Origin} Validation Algorithms:

When an AS_SET is present in a BGP Update, it isn't required that it is the
right-most segment type.  While this is certainly the most typical scenario
and supported by most implementations, it's not mandated by the spec.  

See RFC 4271, Sec F.6.

I somewhat suspect that as RPKI becomes more widely deployed that there will
be somewhat greater motivation to support more complex aggregation.
(Or at least as much pressure customers announcing 0.07% of the internet's
prefixes are willing to assert with their pocket books.)

John S. seemed to have slightly different thoughts and he will probably
follow-up.

-- Jeff

---

From: Randy Bush <[email-masked]>
Date: Wed, 28 Jul 2010 16:22:50 +0200

want knob to just not bother with aggs.  they are a teensie weensie bit
of the routes, often bizarre (have only self, have three copies of self,
private asns, ...), why should i pay with complexity (== fragility) to
accommodate them?

randy

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 28 Jul 2010 10:54:46 -0400

On a serious note(s):
o  what harm does it due to just not accept these routes (globally)
and force folks to actually do the proper thing with their routers?

o how would that change if these routes could not be validated and
just lived on in the 'unknown' state?

(regular-joe-hat)
-Chris

On Wed, Jul 28, 2010 at 10:22 AM, Randy Bush <[email-masked]> wrote:
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Danny McPherson <[email-masked]>
Date: Wed, 28 Jul 2010 09:04:26 -0600

> private asns, ...), why should i pay with complexity (== fragility) to

Because from an operational perspective the connectivity of those teensie 
weensie's is reliant upon RFC 4271 behavior from standards track compliant 
implementations.  If this path is selected by SIDR then 4271 should be 
updated by IDR.

-danny

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 28 Jul 2010 17:09:27 +0200

> implementations.  If this path is selected by SIDR then 4271 should be 

Exactly.  If someone would like to propose deprecating AS_SET, I invite them to write an Internet Draft and discuss it at IDR.

--John

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 28 Jul 2010 11:54:38 -0400 (Eastern Daylight Time)

The problem is the possibility that not accommodating legitimate BGP 
updates might result in opportunities for bad guys to get around 
protections.

So we need to have some statement of what to do with this legitimate 
BGP update format.  And we need some certainty that we aren't introducing 
opportuntities to circumvent the protections of ordinary updates.

Protecting the AS_SETs etc is out of scope.

--Sandy

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 28 Jul 2010 16:18:16 +0000

On Wed, Jul 28, 2010 at 11:54:38AM -0400, Sandra Murphy wrote:
> So we need to have some statement of what to do with this legitimate BGP 
> update format.  And we need some certainty that we aren't introducing  

Sorry, I had hoped my comment at the microphone may have covered this:
If the right-most AS path segment is a sequence, use the right-most AS as
the origin.
If the right-most AS path segment is a set, use the aggregator AS as per the
presentation.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 28 Jul 2010 16:52:19 +0000

> private asns, ...), why should i pay with complexity (== fragility) to

For the record, I don't think SIDR should be jumping through any hoops for
aggregates at all.  This was primarily a response to the proposal and the
BGP correct thing to do for the scenario covered.  Shoot the messenger
who brought the message, not the one who noted the message had a typo. :-)

-- Jeff

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Thu, 29 Jul 2010 03:41:19 -0400

>If the right-most AS path segment is a set, use the aggregator AS as per the

In the presentation, we noted (slide 7) that there is a new attack possibility
if the AGGREGATOR is used as the origin.
We recommended (John Scudder and others supported) that
the AS immediately to the left of the AS_SET should be used as the origin.
The analysis we presented showed that the ASN in the AGGREGATOR attribute is 
no different from the ASN of the AS immediately to the left of the AS_SET 
(wherever it matters from a validation algorithm point of view).
So we recommend using the AS immediately to the left of the AS_SET as origin
and basically disregard the AGGREGATOR attribute in the validation algorithm.
This approach is compliant with RFC 4271 and also keep the algorithm simpler.

Regarding your other point earlier about AS_SET location in the AS path,
the data analysis (2 million updates and 11 million RIB entries) shows
that whenever AS_SET is present in an update, 100% of the time the AS_SET appears
in the right-most position.
Also from a practical point of view, it is not possible to have the AS_SET
in the middle of the AS path because the AGGREGATOR does not know 
which preceding ASs originated which subprefixes. It can aggregate
only by including all preceding ASs in one AS_SET that then goes in the right most
position.

Sriram

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Jeffrey Haas [[email-masked]]
Sent: Wednesday, July 28, 2010 12:18 PM
To: Sandra Murphy
Cc: [email-masked]
Subject: Re: [sidr] Comment about aggregators and AS_SETs

-- Jeff

---

From: Robert Kisteleki <[email-masked]>
Date: Thu, 29 Jul 2010 10:14:48 +0200

On 2010.07.28. 17:54, Sandra Murphy wrote:
> The problem is the possibility that not accommodating legitimate BGP updates
> might result in opportunities for bad guys to get around protections.

IMO that's not the problem. The problem is that we don't want to have 
special mechanisms for cases that occur 0.0007% (or is 0.02%?) of the time.

It's like creating a special shampoo product line for albinos. No offense to 
albinos, but it's not really a good idea. It'll fail.

[0] http://en.wikipedia.org/wiki/Albinism

> opportuntities to circumvent the protections of ordinary updates.

Agree. My suggestion: these announcements are not in scope for SIDR.

Robert

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Thu, 29 Jul 2010 04:14:46 -0400

The point of my presentation was that we can treat updates with AS_SETs
duly and in accordance with RFC 4271.
No protocol modification is required.
We need not look inside the AS_SET, and also we would require no ROAs for the AS_SET. 
Simply take the AS to the immediate left of the AS_SET to be the origin.
The update/RIB data establish clearly that the ASN in that AS position indeed
matches the AGGREGATOR ASN (wherever it matters for the validation algorithm).
However, the algorithm should not take the AGGREGATOR to be the origin
(in order not to open the door for a new attack possibility -- see slide 7).
Simply taking the AS to the immediate left of the AS_SET to be the origin is just as good. 
This approach has simplicity and it avoids the new attack possibility.
(My slides have the details and further explanation.)

Sriram
 
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Randy Bush [[email-masked]]
Sent: Wednesday, July 28, 2010 10:22 AM
To: Jeffrey Haas
Cc: [email-masked]
Subject: Re: [sidr] Comment about aggregators and AS_SETs

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 29 Jul 2010 10:33:30 +0200

> special mechanisms for cases that occur 0.0007% (or is 0.02%?) of the

bingo!

> It's like creating a special shampoo product line for albinos.

no.  it is like changing your main product line.

randy

---

From: Andrei Robachevsky <[email-masked]>
Date: Thu, 29 Jul 2010 10:42:25 +0200

> (My slides have the details and further explanation.)

This is very clear and I support this approach. Also, as I commented
previously, in reality the AS in question is the holder of the covering
address space and, therefore, in position to issue a ROA.

Andrei

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 29 Jul 2010 09:19:08 +0000

Sriram,

> However, the algorithm should not take the AGGREGATOR to be the origin

Part of my suggestion is that the first non-sequence AS should only be used
*if and only if* the aggregator AS matches.

This would be in addition to only considering the AS left of an AS_SET when
there are no sequences as the right-most segment type.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 29 Jul 2010 09:27:02 +0000

> no.  it is like changing your main product line.

Speaking as one of the guys that would have to add the few dozen lines of
code to figure out the origin AS when sets are present, this is *not* a big
deal.  While I'm not hung up over trying to cover sets for validation
purposes, I think the presentation shows there's a nice heuristic we could
use that covers current operational practices.

You are quite welcome to feel righteously indignant about being completist
if you like though. :-)

-- Jeff

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Thu, 29 Jul 2010 05:41:01 -0400

Thanks, Jeff.
One more clarification request:
What do you mean when you say  "first non-sequence AS"?
Example:
AS path :  ASN3 ASN2 ASN1 [ASN25, ASN26]  AGGREGATOR: AS1
Here [ASN25, ASN26] is the AS_SET.
I this example, what is the first non-sequence AS?
You may use a different example if needed.

Sriram
________________________________________
From: Jeffrey Haas [[email-masked]]
Sent: Thursday, July 29, 2010 5:19 AM
To: Sriram, Kotikalapudi
Cc: Randy Bush; Jeffrey Haas; [email-masked]
Subject: Re: [sidr] Comment about aggregators and AS_SETs

Sriram,

-- Jeff

---

From: Randy Bush <[email-masked]>
Date: Thu, 29 Jul 2010 11:59:54 +0200

> Speaking as one of the guys that would have to add the few dozen lines
> of code to figure out the origin AS when sets are present, this is
> *not* a big deal.

that is one small part of the job.  glad you find it easy.

---

From: "Murphy, Sandra" <[email-masked]>
Date: Thu, 29 Jul 2010 06:17:29 -0400

(VPN to home is not working so using web mail interface which timed out while I was composing the first answer to this message without saving the draft - maybe the repeat will make this more succinct.)

So suppose we say "AS_SETs are not in scope for this wg"

So suppose a BGP route produced by AttackerBob arrives with an origin that is an AS_SET.  The validation scheme does ... what?

If the validation scheme says anything better than "invalid" then the attacker has a way to circumvent the origin protections.

We already know that the attacker has a way to continue to produce bogus BGP routes by putting a valid origin on the end of a bogus path.  In that case, the origin protections work just fine, to the limit of their abilities.  It is path validation that fails.

But with no way to deal with an origin that is an AS_SET, the origin protection themselves fail.

In my opinion that is an important difference and therefore the issue is in the scope of the working group.

The reasoning that we need not deal with AS_SETs because they are so rare is good reasoning if we were protecting AS_SET origins, i.e., we are trying to judge good valid AS_SETs from bad bogus AS_SETs.  "Why protect this feature since it is so rare" is a valid statement.  "Why deal with this rare input" is not a valid statement, when producing the rare input is under the control of the attacker and is an attack vector.

Please note that I'm not saying we need to deal with the AS_SETs in any careful way.  "DROP" is a nice simple statement about what to do with BGP routes that have AS_SET origins.  That might be a bit draconian, and it would mean that some potentially valid routes might get dropped.  I would say that such an outcome would be acceptable, precisely because of the rarity.  The schemes some are suggesting for more care in the decision are fine too.

What I see as in scope is:

(a) AS_SET is a feature that is a valid input so we can't ignore it
(b) whatever we do with AS_SET origins can not allow circumvention of the origin protections

--Sandy, speaking as co-chair but without coordination with my co-chair

-----Original Message-----
From: [email-masked] on behalf of Robert Kisteleki
Sent: Thu 7/29/2010 4:14 AM
To: [email-masked]
Subject: Re: [sidr] Comment about aggregators and AS_SETs

Robert

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 29 Jul 2010 08:20:55 -0400

On Thu, Jul 29, 2010 at 4:14 AM, Robert Kisteleki <[email-masked]> wrote:
>> updates

pls define 'not in scope', what behavior is expected when a 'sidr
compliant' router sees an update with an AS_SET in the path? (drop
update? mark as invalid? mark as unknown? mark as valid? something
else?)

<normal-joe-hat)
-Chris

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 29 Jul 2010 08:24:02 -0400

> Simply taking the AS to the immediate left of the AS_SET to be the origin is just as good.

I think with the privso that the ROA assigned/checked is for the exact
prefix aggregate + 'immediate left of the AS_SET AS'.

-chris
<normal-joe-hat>

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 29 Jul 2010 08:27:49 -0400

> Here [ASN25, ASN26] is the AS_SET.

<asking dumb question>
so, a the mic I thought Jeff also said that ASN25, ASN26 was
explicitly unordered in the spec. If this is the case than the check
for the first in the sequence isn't reliable/repeatable.
</asking dumb question>

-chris
<regular-joe-hat>

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Thu, 29 Jul 2010 08:42:47 -0400

>prefix aggregate + 'immediate left of the AS_SET AS'.

Yes, Chris. I agree.
Andrei expressed the similar thoughts as well. 

>>Andrei Robachevsky wrote:

Sriram

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Christopher Morrow [[email-masked]]
Sent: Thursday, July 29, 2010 8:24 AM
To: Sriram, Kotikalapudi
Cc: Randy Bush; Jeffrey Haas; [email-masked]
Subject: Re: [sidr] Comment about aggregators and AS_SETs

-chris
<normal-joe-hat>

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 29 Jul 2010 13:50:23 +0000

> What do you mean when you say  "first non-sequence AS"?

I mean I had a typo.  That should have read first non-set AS.

Just to be clear, consider the following cases:

1 2 3 4 5

1 2 [3 4 5] Aggregator 1

1 2 [3 4 5] Aggregator 2

1 2 [3 4] 5

In the first and fourth cases have 5 being the origin.

The second case, 2 shouldn't be an origin and the path should be considered
ineligible for ROA validation.

The third case, 2 could be considered as the origin for ROA validation per
your draft.

Sorry for the confusion.

-- Jeff