Subject: [sidr] draft-ietf-sidr-roa-validation-07 submitted

From: Geoff Huston <[email-masked]>
Date: Sun, 10 Oct 2010 21:48:20 +1100

Hi,

The draft's authors have reviewed the WG discussion and have decided to use, with acknowledgement in the draft, and an expression of thanks here, the terminology in a related WG draft, draft-ietf-sidr-pfx-validate. The revised terminology does not refer to a route as being "valid", "invalid" or "unknown", but refers to an attribute of the route, namely its "validity state", and this attribute has the values of "valid", "invalid" or "unknown", and notes that "not found" is synonymous to "unknown" in this context. The authors trust that this distinction addresses the issues WG members had over the terminology in the previous version of this draft, that used such state attributions directly on the route itself, rather than on a nominated attribute of the route.

The announcement of the submission of this revised draft is below.

regards,

   Geoff

A new version of I-D, draft-ietf-sidr-roa-validation-07.txt has been successfully submitted by Geoff Huston and posted to the IETF repository.

Filename:	 draft-ietf-sidr-roa-validation
Revision:	 07
Title:		 Validation of Route Origination using the Resource Certificate PKI and ROAs
Creation_date:	 2010-10-10
WG ID:		 sidr
Number_of_pages: 10

Abstract:
This document defines the semantics of a Route Origin Authorization
(ROA) in terms of the context of an application of the Resource
Public Key Infrastructure to validate the origination of routes
advertised in the Border Gateway Protocol.

On 08/06/2010, at 11:01 PM, Sandra Murphy wrote:

> The WG LC has ended.
> 
> There were no responses to this LC.  None.  Zip. Zero.
> 
> This draft has gone through many changes through the years as it has been discussed in IETF meetings.
> 
> So the silence must be regarded as proof that the wg had no further comments to make.
> 
> I do note that the discussion of terminology (valid/unknown/invalid) in the draft-pmohapat-sidr-pfx-validate-07 draft apply equally to this draft and that an author of this draft had alternative terms to suggest in that discussion.
> 
> I believe that that energetic discussion is indication that the wg would prefer different terminology be used in this draft as well.
> 
> I invite the authors to continue that discussion to come to consensus of what terms best capture the desired semantics.
> 
> Any final last call on this draft would be very short indeed.
> 
> --Sandy, speaking as wg chair
> 
> On Tue, 18 May 2010, Sandra Murphy wrote:
> 
>> The presentation "ROA Validation Update" (http://www.ietf.org/proceedings/77/slides/sidr-8.pdf) at IETF 77 requested a WG LC for draft "Validation of Route Origination using the Resource Certificate PKI and ROAs".
>> 
>> The document (and the draft version history) is at available at
>> http://tools.ietf.org/html/draft-ietf-sidr-roa-validation-06.
>> 
>> The Last Call will end on Wednesday 2 June 2010.
>> 
>> As usual, please address all comments to the WG mailing list, and please be clear in your comments to this last call if you are supporting the document's submission to the IESG or if you are opposed.  If you are opposed, please indicate why.
>> 
>> --Sandy
>> 
>> 
>> _______________________________________________
>> sidr mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sidr
>> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

--

Geoff Huston
Chief Scientist, APNIC

+61 7 3858 3100
[email-masked]

---

From: Geoff Huston <[email-masked]>
Date: Sun, 10 Oct 2010 21:50:11 +1100

Hi,

The draft's authors believe that the document draft-ietf-sidr-roa-validation-07 is ready for WG Last Call, and in this note we are requesting the WG Chairs to conduct such a WG Last Call.

thanks,

   Geoff

--

Geoff Huston
Chief Scientist, APNIC

+61 7 3858 3100
[email-masked]

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Mon, 11 Oct 2010 10:14:11 -0400

Geoff:

I have a concern about the way the origin is determined
when AS_SET is present in an update.
Quoting from draft-ietf-sidr-roa-validation-07:
"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."

At the Maastricht SIDR WG meeting, I gave a presentation in which
I highlighted a new attack vector that is possible due to the
above quoted way of determining the origin AS.
Please see slide 7 of said presentation:
http://www.ietf.org/proceedings/78/slides/sidr-4.pdf
http://www.antd.nist.gov/~ksriram/AS_SET_Aggregator_Stats.pdf
(The second link has slightly revised slides with corrections.) 

In the presentation, I also pointed out a simple method for
avoiding the new type of attack (also on slide 7).
This method (or remedy) draws support from the 
data that I presented in the preceding slides (slide 2-4).

After my presentation, there was significant interest in this topic
and some good discussions followed on the list; links to some of which are:
http://www.ietf.org/mail-archive/web/sidr/current/msg01780.html
http://www.ietf.org/mail-archive/web/sidr/current/msg01794.html
http://www.ietf.org/mail-archive/web/sidr/current/msg01791.html

Of course, a different take on all this is to deprecate the AS_SET.
http://www.ietf.org/mail-archive/web/sidr/current/msg01772.html
Warren Kumari has submitted a draft to IDR to try to accomplish that.
Until that is accomplished, if we think we have to be compliant with
RFC 4271, then I think my suggested solution makes sense.

You may also factor in some comments/augmentation that Jeff Hass
and Pradosh have made to my proposal:
http://www.ietf.org/mail-archive/web/sidr/current/msg01791.html
http://www.ietf.org/mail-archive/web/sidr/current/msg01794.html

Regards,
Sriram
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Geoff Huston [[email-masked]]
Sent: Sunday, October 10, 2010 6:48 AM
To: [email-masked] wg
Subject: [sidr] draft-ietf-sidr-roa-validation-07 submitted

Hi,

regards,

   Geoff

Abstract:

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 13 Oct 2010 15:52:02 -0400

Hi Geoff:

I just wanted to provide you some more comments for clarity.
For updates with AS_SET, the algorithm in your draft 
only checks the ASN in the AGGREGATOR field 
to see if it matches with the ASN in the ROA. 
This approach allows tools for a would be attacker to 
hijack a prefix in one of these two ways:
1.  Artificially inserts an AS_SET (possibly an empty AS_SET or
with just his ASN in the AS_SET), places a matching ASN from the covering 
ROA for the prefix being hijacked into the AGGREGATOR field, 
and places his own ASN as the first AS after the AS_SET to attract traffic toward him. 
2. Takes any legitimate update he sees with an AS_SET in it; 
leaves the AS_SET and AGGREGATOR field unmodified; places his
own ASN immediately next to the AS_SET and propagates the update.
(He doesn't need to insert the true origin before his own ASN!).

There is a rather simple modification to your algorithm
which mitigates these types attacks.
Looking at the update/RIB data analysis in my presentation,
it is clear for all practical purposes, that the ASN in the AGGREGATOR field
is the same as the "first AS after the AS_SET" with very high probability
(when they do not match, it is because the update is evidently flaky 
involving private ASNs, etc.).
So the obvious remedy seems to be as follows:
Check if the ASN in the AGGREGATOR field matches the 
the "first AS after the AS_SET".
If true, then call that ASN the origin. 
Else, consider the origin indeterminable.

If you take look at the data analysis in my slides (slides 2-4), 
the above approach seems quite well supported for determining 
the origin and at the same time mitigating the type of attacks noted above.

Please let me know if this seems reasonable. Thanks.

Regards,
Sriram

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Sriram,
> Kotikalapudi
> Sent: Monday, October 11, 2010 10:14 AM
> To: Geoff Huston; [email-masked] wg
> Subject: Re: [sidr] draft-ietf-sidr-roa-validation-07 submitted
> 
> Geoff:
> 
> The draft's authors have reviewed the WG discussion and have decided to use, with
> acknowledgement in the draft, and an expression of thanks here, the terminology in a
> related WG draft, draft-ietf-sidr-pfx-validate. The revised terminology does not refer to a
> route as being "valid", "invalid" or "unknown", but refers to an attribute of the route,
> namely its "validity state", and this attribute has the values of "valid", "invalid" or
> "unknown", and notes that "not found" is synonymous to "unknown" in this context. The
> authors trust that this distinction addresses the issues WG members had over the
> terminology in the previous version of this draft, that used such state attributions directly on
> the route itself, rather than on a nominated attribute of the route.
>

---

From: Geoff Huston <[email-masked]>
Date: Thu, 14 Oct 2010 10:03:08 +1100

> I just wanted to provide you some more comments for clarity.

Unfortunately, I'm not sure that this note had your intended effect.

> and places his own ASN as the first AS after the AS_SET to attract traffic toward him. 

But surely this can work for ANY prefix - i.e. replace the received AS path with a bogus AS path and leave only the (valid) Origin AS. If one is going to lie about the Path than politely asking the liar to only lie in ways that this particular framework can detect is surely a little far-fetched isn't it?

> (He doesn't need to insert the true origin before his own ASN!).

But surely if the check is on the AGGREGATOR field then this would not alter anything. I'm not sure what your point is here in this second case.

> which mitigates these types attacks.

I honestly don't think so.

> Please let me know if this seems reasonable. Thanks.

Its as reasonable as any other mechanism for origin validation that leaves the AS PATH untouched. i.e. its a wafer thin veneer of potential plausibility masking a rather large and gaping hole of vulnerability. :-)

Presumably if one were to introduce some form of path validation to replace that gaping hole with something a little more substantial one would also add a mechanism that would validate the aggregator as well. In which case, if the aggregator and path are validated then why would the origin AS definition require this double-barrelled approach of having both match?

So I'm at a loss to understand why adding a further constraint (that the AGGREGATOR matches the "first AS after the AS_SET") helps in any way. Why do you think that this additional constraint in the definition of an origin AS is a net improvement?

I'm also unsure as to your approach ere - surely the appropriate analysis here is to ensure that the definition encompasses valid (as per the BGP spec) actions by BGP speakers. i.e. if a BGP speaker acts in accordance with RFC4271, and generates ROAs as appropriate, then shouldn;t we be worried here is there are cases where acting within the spec produces outcomes that are judged to be not valid.

So rather than "mitigating attack" lets look at this from the other perspective - does this definition fail to encompass legitimate actions on the part of BGP speakers?

Back to basics - in the current BGP definition (you know, the one that still allows silly stuff to happen with proxy aggregation and AS Sets), isn't the Aggregator path attribute meant to denote the AS identity of the BGP speaker who performed the more recent proxy aggregation that formed this particular aggregate prefix? And its thats the case then surely that AS is the origin of the aggregated route? Yes?

As far as I can tell your case would be stronger if you proposed "use Aggregator, if present, otherwise use the AS that follows (where "follows" is defined as "to the left of" in a Right to Left sequence ordering of the path from origin to local) the AS Set. If there are multiple instances of AS Set in the path and no aggregator, then abandon all hope and surrender to the gods with an unknown origin AS" as this would align wioth the text of the BGP spec that makes AGGREGATOR optional. But requiring a match is going one step further than the BGP spec, surely.

So I'd like to propose the following text in section 3,. which adds a sentence immediately before the final sentence in the paragraph:
 
   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. If the
   AGGREGATOR attribute is missing, then the origin AS is the first AS
   element of the last path segment of type AS_SEQUENCE (i.e. the AS in
   the rightmost position immediately preceding the final AS_SET path
   segment in the protocol message. Otherwise the route's origin AS 
   cannot be determined."

It does not attempt to impose a greater constraint on the definition than that of the BGP standard itself, which notes that AGGREGATOR is an optional transitive attribute containing the last AS number that formed the aggregate route. So either its there and therefore its the most recent aggregator or its not there in which case look at AS the immediately precedes the AS Set.

(Frankly, deprecating AS-Sets is a far better answer to this particular definitional problem you have noted, and having some form of mechanism that validates path is about the only way I know how to detect folk who lie about the path. You can't substitute an origin validation technique for path validation. Square pegs, round holes, etc.)

regards,

  Geoff

--

Geoff Huston
Chief Scientist, APNIC

+61 7 3858 3100
[email-masked]

---

From: Geoff Huston <[email-masked]>
Date: Fri, 15 Oct 2010 16:38:47 +1100

Let me try that once again!

The authors have revised the text relating to the definition of the origin AS to be conformant to the current BGP specification, namely that if the AGGREGATOR path attribute is present it "contains the last AS number that formed the aggregate route" [RFC4271]. If this path attribute is not present the draft defines the origin AS as the AS preceding the AS_SET, which is a definition that has been drawn from the earlier WG mail thread on this topic

The intention here is not to impose criteria that differ from RFC4271, and define the origin AS in an manner that if an AS undertakes proxy aggregation in conformance with RFC4271 then this definition of origin AS will correctly identify the aggregator AS as the origin AS. This is slightly different from the various suggestions seen so far on the WG mailing list, but it is believed that this refines those suggestions in the light of a careful reading of the relevant sections of RFC 4271.

The authors do not plan any further revisions of this document, and, accordingly, would like once more to request a WG Last Call of the -08 rev of the document.

thanks,

   Geoff

--

Geoff Huston
Chief Scientist, APNIC

+61 7 3858 3100
[email-masked]

---

From: Christopher Morrow <[email-masked]>
Date: Sat, 16 Oct 2010 16:57:46 -0400

This was sent along (the requested LC message) to the list today...
see you in 2 weeks (at decision time)

-chris
(wg-co-chair-cycling-shoes == on)

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Sun, 17 Oct 2010 15:03:49 -0400

Geoff:

I feel this still needs more careful consideration and more work
(in the part of the algorithm that deals with AS_SETs).
My responses to your comments inline.

Sriram

>From: Geoff Huston [[email-masked]]
>Sent: Wednesday, October 13, 2010 7:03 PM
>To: Sriram, Kotikalapudi
>Cc: [email-masked] wg

I think you misunderstood the attack vector that I described
which I feel is made possible by the AS_SET-related portion
of the algorithm described in your draft.
It undermines ROA-based origin validation for any and all prefixes,
not just those with aggregation using AS_SET.
Please see examples below.

>But surely this can work for ANY prefix - i.e. replace the
>received AS path with a bogus AS path and leave only the (valid) Origin AS.
>If one is going to lie about the Path than politely asking the liar to
>only lie in ways that this particular framework can detect is surely a little far-fetched isn't it?

I feel you may have misunderstood the attack vector
(sorry if I failed to word it carefully the first time).
Please consider the example:

Valid ROA exists: {10.1.1.0/24, Origin = AS1}
Hijacker owns AS2 and propagates an update as follows:
AS2 [AS2], AGGEGATOR = AS1, 10.1.1.0/24,
where [AS2] is an AS_SET that the hijacker has inserted to
take advantage of your algorithm.
Note that he did not even insert the true origin before his ASN!
Your algorithm treats this update as one with AS_SET and AGGREGATOR present,
and it would assign status “Valid” to this the update from the hijacker.
That is because you take the AGGREGATOR ASN, i.e., AS1 to be the origin
and the ROA check passes. But in reality the hijack succeeds (to the extent
BGP shortest path algorithm works in favor of the hijacker) and the
traffic in part goes to AS2 (the hijacker). Am I right?
In my view this is not path modification; it is simply origin manipulation.

A straight forward heuristic that is derived from empirical evidence
fixes this problem (makes the hijack infeasible).
If you had a chance to look into my slides,
http://www.antd.nist.gov/~ksriram/AS_SET_Aggregator_Stats.pdf
what we have empirically established there is that
the ASN in the AGGREGATOR attribute is practically identical to the
first AS element of the last path segment of type AS_SEQUENCE (i.e. the AS in
the rightmost position immediately preceding the final AS_SET path
segment in the protocol message).
For simplicity, we have called this “first AS element  ...” the
“First AS after AS_SET.”
Please see slides 2, 3 and 4.
The above stated empirical observation is true for
97% BGP updates with AS_SET and 98.5% in RIB entries with AS_SET
(based analysis of extensive Routeviews data) – please see slides 3 and 4.
The residual 3% in updates or 1.5% in RIB (where the
AGGREGATOR ASN does not match the first AS element of
the last path segment of type AS_SEQUENCE) are because the
AGGREGATOR fields contains private ASN – that does not seem
RFC 4271 compliant. So we need not care about these residual cases.
Now based on the above evidence, to identify the origin AS when AS_SET is present,
we need NOT look at the AGGREGATOR; instead we look at the AS that “follows” the AS Set
(where "follows" is defined as "to the left of" in a Right to Left sequence
ordering of the path from origin to local).
Based on the above set of observations, a simple heuristic for the
algorithm is as follows:

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 the AS that
“follows” the AS Set
(where "follows" is defined as "to the left of" in a Right to Left sequence
ordering of the path from origin to local).
 (Does not matter if AGGREGATOR attribute is present or absent).

(Note: We looked hard at lots of update/RIB data and found ZERO
BGP updates and RIB entries which have more than one AS_SET.
Thus, when an AS_SET is found in an update, there is one and only one.
Also, the AS_SET always -- in 100% of updates with AS_SET and 100% of
RIB entries with AS_SET -- appeared in the right most position in the AS path.)

With the above approach to the algorithm, the hijack vector talked about
above goes away. The hijacker now has to insert the true origin AS (per ROA)
prior to his ASN to have a chance at success – that is the minimum we expect with
ROA-based origin validation.
He can no longer get away with substituting his ASN in place of the
AS that “follows” the AS Set (with my suggested heuristic algorithm).
We are in no way requiring BGP router to do anything non-compliant with RFC 4721.
We simply have a heuristic based on a solid empirical fact that works,
and preserves the fundamental premise of RPKI ROA, namely, the first AS
of the right most AS_SEQUENCE must be that of the valid originator.
>But surely if the check is on the AGGREGATOR field then this
>would not alter anything. I'm not sure what your point is here in this second case.
>

I am arguing that check on the AGGREGATOR attribute alone leads to
this attack vector as already explained above.
>Its as reasonable as any other mechanism for origin validation that leaves the AS PATH
>untouched. i.e. its a wafer thin veneer of potential plausibility masking
>a rather large and gaping hole of vulnerability. :-)

The new attack vector I am concerned about is not about path modification;
it is still origin modification that the attacker seems to get away with
as explained above.

>
>Presumably if one were to introduce some form of path validation
>to replace that gaping hole with something a little more substantial
>one would also add a mechanism that would validate the aggregator as well.
>In which case, if the aggregator and path are validated then why
>would the origin AS definition require this double-barrelled approach of having both match?
>
>So I'm at a loss to understand why adding a further constraint
>(that the AGGREGATOR matches the "first AS after the AS_SET")
>helps in any way. Why do you think that this additional constraint
>in the definition of an origin AS is a net improvement?

As stated above, the problem (new attack vector) goes away
if the origin AS is taken the AS that “follows” the AS Set
(where "follows" is defined as "to the left of" in a Right to Left sequence
ordering of the path from origin to local).
Basically, it is not advisable to go by the AGGREGATOR attribute to
define the origin AS.
>
>I'm also unsure as to your approach ere - surely the appropriate
>analysis here is to ensure that the definition encompasses valid
>(as per the BGP spec) actions by BGP speakers. i.e. if a BGP speaker
>acts in accordance with RFC4271, and generates ROAs as appropriate,
>then shouldn;t we be worried here is there are cases where acting
>within the spec produces outcomes that are judged to be not valid.
>
>So rather than "mitigating attack" lets look at this from the other
>perspective - does this definition fail to encompass legitimate
>actions on the part of BGP speakers?
>
>Back to basics - in the current BGP definition (you know, the one
>that still allows silly stuff to happen with proxy aggregation and AS Sets),
>isn't the Aggregator path attribute meant to denote the AS identity of
>the BGP speaker who performed the more recent proxy aggregation
>that formed this particular aggregate prefix? And its thats the case
>then surely that AS is the origin of the aggregated route? Yes?

I feel this is where the mistake is that makes possible the new attack vector.
Empirically, the AS that “follows” the AS Set matches with
the ASN in the Aggregator path attribute. That is catch.
Therefore, always take the first AS of the rightmost AS_SEQUENCE
to be the origin – for all updates, regardless of presence of AS_SET or not.
This eliminates the attack vector.
>
>As far as I can tell your case would be stronger if you proposed "use Aggregator,
>if present, otherwise use the AS that follows (where "follows" is defined as
>"to the left of" in a Right to Left sequence ordering of the path from
>origin to local) the AS Set. If there are multiple instances of AS Set in
>the path and no aggregator, then abandon all hope and surrender to
>the gods with an unknown origin AS" as this would align wioth
>the text of the BGP spec that makes AGGREGATOR optional.
>But requiring a match is going one step further than the BGP spec, surely.

We are not requiring anything like that from BGP speaker.
Our observation is purely empirical that leads to a more robust
approach in the algorithm for validating updates with AS_SETs
without compromising the normal updates.
>
>
>So I'd like to propose the following text in section 3,. which adds a
>sentence immediately before the final sentence in the paragraph:
>
>If the final path segment of the AS_PATH is of type AS_SET, indicating

This still does not resolve the issue we are discussing.

Sriram
------------

 Geoff

---

From: Geoff Huston <[email-masked]>
Date: Mon, 18 Oct 2010 08:01:53 +1100

At the risk of repeating myself, let me offer three thoughts as simply as I can, and one not so simply:

Origination validation does not stop folk lying in the AS_PATH, and, by implication lying in the AGGREGATOR path attribute as well. I do not understand what can be gained by believing otherwise. You can't substitute an origin validation technique for path validation. Square pegs, round holes, etc.

If folk act within the constraints of the specification of BGP as defined by the current BGP spec, then any additional constraints applied in this draft should not invalidate an otherwise conforming BGP update message.

The text I've proposed in -08 of the draft attempts to meet the above two objectives, without heading off into extraneous or diversionary areas.

After reading Appendix F.6. of RFC4271 again I'm even less convinced that "the AS immediately preceding the final AS_SET in the AS_PATH" means anything at all in the context of which AS performed the AS_PATH aggregation. The "AS before the last AS_SET" assumes that the aggregation algorithm is "bung all the AS's in the AS_PATHS of the routes being aggregated into a bucket, pull out duplicates and put it into a AS_SET". But that's not what is described in Appendix F.6. The algorithm provided in that section of the draft allows for the construction of multiple AS_SET path elements in the AS_PATH and also allows for the aggregated path constructed by this algorithm to start with an AS_SEQUENCE, not an AS_SET. In this case the task of identifying the AS that performed the aggregation is actually quite fuzzy if no AGGREGATOR is present. I suspect that if one were to quibble with the "AS before the last AS_SET" as being what you do when no AGGREGATOR is present, then this section of RFC4271 leads me to say that the best you can say when no AGGREGATOR is present is that the origin AS is one of the AS's in the initial AS_SEQUENCE path element, but it is, strictly speaking, indeterminate as to which one it is. This leads to the alternative interpretation that the text in the -07 version was actually a "better" approach, namely that if no AGGREGATOR is present then its not possible to tell definitively which AS actually undertook the proxy aggregation action, and hence which AS should be deemed to be the origin AS. i.e. taking a conforming route that has not been altered in any malicious way and erring to a validation state determination  of "unknown" is perhaps better in such circumstances than taking the same conforming route and erring to a validation state conclusion of "invalid". In such a context of a strict interpretation of the BGP spec as it relates to proxy aggregation, the AGGREGATOR AS, if present, should be listed somewhere in the initial (left-most) path element, and this path element must be an AS_SEQUENCE path element, and the AGGREGATOR performed the most recent proxy aggregation to form this route. If the AGGREGATOR attribute is missing, then the path aggregation algorithm as presented in the BGP spec leads me to conclude that it is not possible to definitively identify the AS that performed the proxy aggregation in all circumstances. 

At the risk of repeating myself again, the sooner the IDR WG deprecates AS_SETs in the BGP spec, the better!

---

From: Christopher Morrow <[email-masked]>
Date: Sun, 17 Oct 2010 23:03:32 -0400

> At the risk of repeating myself again, the sooner the IDR WG deprecates AS_SETs in the BGP spec, the better!

So... without my co-chair items of clothes on (for sidr at least, and
grow) ... there isn't a reliable and simple method I can see to dance
around the AS-SET problem, aside from 'AS-SETs don't count and can't
be in the validation decision'.

So, I support SIDR folks taking a virtual walk to IDR and saying same.

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Mon, 18 Oct 2010 08:19:58 -0400

Geoff:

You seem to agree about the feasibility of the new attack vector.
While I was calling it origin manipulation, you see it as AS path modification.
Let us go with AS path modification (yes, I agree you are right
because an artificial AS_SET is inserted by the attacker into the AS path!).
However, your comment about square pegs, rounds holes does not seem relevant here.
Until now, for a normal prefix update (i.e., one without proxy aggregation, without AS_SET),
we have always felt certain that RPKI ROA-based validation
provided full assurance that the origin would to be valid if it matched with 
the AS in the covering ROA, even if the rest of the AS_PATH was altered in some way.
Now (with the algorithm in the draft in its current form) we seem to have lost that assurance.
For a normal prefix update (i.e., one without proxy aggregation, without AS_SET),
now there can be false origination and this false update would be
evaluated as “valid” by the algorithm, only because the hijacker manipulated 
the AS path cleverly enough to take advantage of
what I think of as a loophole in the algorithm.
Since we decided that the origin AS occurs in a particular position in the AS_PATH
for normal prefix updates, the algorithm cannot take its eyes off of that spot
for any other type of prefix updates (e.g., with AS_SET) when validating origin.

Although I like my empirical/heuristics-based proposal for a modification of 
the algorithm; I would let others speak up if anyone likes it and sees some merit.
(Jeff Hass and Pradosh and few others did express support 
soon after Maastricht SIDR; no surprise if they would think differently now  – 
the AS_SET issue seems inherently complicated.)

In any case, you have cited complications also due to Appendix F.6 in RFC 4271
(another matter that Appendix F.6 seems so surreal).
I fully agree with you and Chris Morrow that deprecating AS_SETs seems 
the best (and may be the only) way out.
I also feel that at present the document should defer statement on validation 
of updates with AS_SET to a future time, pending outcome of the IDR action.

Regards,
Sriram
________________________________________
From: Geoff Huston [[email-masked]]
Sent: Sunday, October 17, 2010 5:01 PM
To: Sriram, Kotikalapudi
Cc: [email-masked] wg
Subject: Re: [sidr] draft-ietf-sidr-roa-validation-07 submitted

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Mon, 18 Oct 2010 12:03:29 -0400

I realized my wording of sentences was a bit misleading in a few places. 
These corrections shown below (with [CORRECTION: ... ]).
Sorry for the repeat.

Sriram

----- Message showing the Corrections -----

Geoff:

You seem to agree about the feasibility of the new attack vector.
While I was calling it origin manipulation, you see it as AS path modification.
Let us go with AS path modification (yes, I agree you are right
because an artificial AS_SET is inserted by the attacker into the AS path!).
However, your comment about square pegs, rounds holes does not seem relevant here.
Until now, for a normal prefix update (i.e., one without proxy aggregation, 
without AS_SET), we have always felt certain that RPKI ROA-based validation
provided full assurance that the origin would to be valid [CORRECTION: valid (invalid)] 
if it matched [CORRECTION: matched (didn't match)] the AS in the covering ROA, 
even if the rest of the AS_PATH was altered in some way.
Now (with the algorithm in the draft in its current form) we seem to have lost that assurance.
For a normal prefix update (i.e., one without proxy aggregation, without AS_SET),
now there can be false origination and this false update would be
evaluated as "valid" by the algorithm, only because the hijacker manipulated
the AS path cleverly enough to take advantage of
what I think of as a loophole in the algorithm.
Since we decided that the origin AS occurs in a particular position in the AS_PATH
for normal prefix updates, the algorithm [CORRECTION: any proposed algorithm] 
cannot [CORRECTION: must not] take its eyes off of that spot
for any other type of prefix updates (e.g., with AS_SET) when validating origin.
 
soon after Maastricht SIDR; no surprise if they would think differently now  -

Regards,
Sriram
> Origination validation does not stop folk lying in the AS_PATH, and, by implication lying
> in the AGGREGATOR path attribute as well. I do not understand what can be gained by
> believing otherwise. You can't substitute an origin validation technique for path validation.
> Square pegs, round holes, etc.
> 
> If folk act within the constraints of the specification of BGP as defined by the current BGP
> spec, then any additional constraints applied in this draft should not invalidate an otherwise
> conforming BGP update message.
> 
> The text I've proposed in -08 of the draft attempts to meet the above two objectives, without
> heading off into extraneous or diversionary areas.
> 
> After reading Appendix F.6. of RFC4271 again I'm even less convinced that "the AS
> immediately preceding the final AS_SET in the AS_PATH" means anything at all in the
> context of which AS performed the AS_PATH aggregation. The "AS before the last
> AS_SET" assumes that the aggregation algorithm is "bung all the AS's in the AS_PATHS
> of the routes being aggregated into a bucket, pull out duplicates and put it into a AS_SET".
> But that's not what is described in Appendix F.6. The algorithm provided in that section of
> the draft allows for the construction of multiple AS_SET path elements in the AS_PATH
> and also allows for the aggregated path constructed by this algorithm to start with an
> AS_SEQUENCE, not an AS_SET. In this case the task of identifying the AS that performed
> the aggregation is actually quite fuzzy if no AGGREGATOR is present. I suspect that if one
> were to quibble with the "AS before the last AS_SET" as being what you do when no
> AGGREGATOR is present, then this section of RFC4271 leads me to say that the best you
> can say when no AGGREGATOR is present is that the origin AS is one of the AS's in the
> initial AS_SEQUENCE path element, but it is, strictly speaking, indeterminate as to which
> one it is. This leads to the alternative interpretation that the text in the -07 version was
> actually a "better" approach, namely that if no AGGREGATOR is present then its not
> possible to tell definitively which AS actually undertook the proxy aggregation action, and
> hence which AS should be deemed to be the origin AS. i.e. taking a conforming route that
> has not been altered in any malicious way and erring to a validation state determination  of
> "unknown" is perhaps better in such circumstances than taking the same conforming route
> and erring to a validation state conclusion of "invalid". In such a context of a strict
> interpretation of the BGP spec as it relates to proxy aggregation, the AGGREGATOR AS, if
> present, should be listed somewhere in the initial (left-most) path element, and this path
> element must be an AS_SEQUENCE path element, and the AGGREGATOR performed the
> most recent proxy aggregation to form this route. If the AGGREGATOR attribute is
> missing, then the path aggregation algorithm as presented in the BGP spec leads me to
> conclude that it is not possible to definitively identify the AS that performed the proxy
> aggregation in all circumstances.
>

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Thu, 28 Oct 2010 12:03:34 -0400

http://www.ietf.org/mail-archive/web/sidr/current/msg02020.html
http://www.ietf.org/mail-archive/web/sidr/current/msg02017.html

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Christopher
> Morrow
> Sent: Saturday, October 16, 2010 4:58 PM
> To: Geoff Huston
> Cc: Sandra Murphy; [email-masked] wg
> Subject: Re: [sidr] WG LC request for draft-ietf-sidr-roa-validation-08.txt
> 
> > The authors have revised the text relating to the definition of the origin AS to be
> conformant to the current BGP specification, namely that if the AGGREGATOR path
> attribute is present it "contains the last AS number that formed the aggregate route"
> [RFC4271]. If this path attribute is not present the draft defines the origin AS as the AS
> preceding the AS_SET, which is a definition that has been drawn from the earlier WG mail
> thread on this topic
> >
> > The intention here is not to impose criteria that differ from RFC4271, and define the
> origin AS in an manner that if an AS undertakes proxy aggregation in conformance with
> RFC4271 then this definition of origin AS will correctly identify the aggregator AS as the
> origin AS. This is slightly different from the various suggestions seen so far on the WG
> mailing list, but it is believed that this refines those suggestions in the light of a careful
> reading of the relevant sections of RFC 4271.
> >
> > The authors do not plan any further revisions of this document, and, accordingly, would
> like once more to request a WG Last Call of the -08 rev of the document.
> >
> >
> > thanks,
> >
> >   Geoff

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Thu, 28 Oct 2010 12:34:22 -0400

Geoff:

Sorry about the previous email with an incomplete message.
I hit some key accidentally and off it went :(

As you know, the following email messages between you, Chris and 
myself are relevant to your 08-rev as well.

http://www.ietf.org/mail-archive/web/sidr/current/msg02020.html
http://www.ietf.org/mail-archive/web/sidr/current/msg02017.html
http://www.ietf.org/mail-archive/web/sidr/current/msg02015.html

Consistent with the above messages,
I would like to suggest removing the algorithmic aspects 
of how to handle updates with AS_SET.
Instead wording along the lines (you may fine tune the wording)
should be included:
It is recognized that in a very small percentage of updates,
proxy aggregation with inclusion AS_SET attribute is found.
There is a proposal under consideration in the IDR WG
to deprecate AS_SETs. Description of the part of the algorithm
that deals with origin validation of updates with AS_SET is deferred 
pending outcome of the IDR WG action on this issue.

Sriram

---

From: Geoff Huston <[email-masked]>
Date: Fri, 29 Oct 2010 06:52:17 +1100

Hi Srinam,

I don't believe that wording is appropriate for an RFC. The wording that is consistent with the current BGP spec is actually in the -07 version.

regards,

  Geoff

--

Geoff Huston
Chief Scientist, APNIC

+61 7 3858 3100
[email-masked]

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Fri, 29 Oct 2010 10:47:37 -0400

Geoff:

The following wording is in both -07 and -08 versions:
"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."

In light of all our discussions, why not replace the above wording with:
"If the final path segment of the AS_PATH is of type 
AS_SET, indicating that the route is an aggregate, 
then the route's origin AS cannot be determined."

That would clearly avoid the new attack vector
on normal prefixes that I have explained before.
There is no point in allowing an additional new type of
attack possibility on 300K or more normal prefixes 
(i.e., those originated without AS_SET and proxy aggregation)
in order to somehow cater to miniscule prefix-updates with AS_SET.

Sriram

> From: Geoff Huston [mailto:[email-masked]]
> Sent: Thursday, October 28, 2010 3:52 PM
> To: Sriram, Kotikalapudi
> Cc: Christopher Morrow; Sandra Murphy; [email-masked] wg
> I don't believe that wording is appropriate for an RFC. The wording that is consistent with
> the current BGP spec is actually in the -07 version.
> 
> regards,
> 
>   Geoff
>