Subject: Re: [sidr] draft-ymbk-rpki-rtr-protocol-05.txt

From: Warren Kumari <[email-masked]>
Date: Mon, 26 Apr 2010 20:51:54 -0400

While going through back mail I noticed this and that there seems to  
be no followups.

I support this as a WG doc.

W

On Mar 27, 2010, at 12:58 PM, Randy Bush wrote:

> we would like to sumbit draft-ymbk-rpki-rtr-protocol-05.txt as a  
> sidr wg
> draft on standards track.  it needs to be standards track as it is a
> normative reference from draft-pmohapat-sidr-pfx-validate-04.txt.
>
> randy
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 27 Apr 2010 14:16:30 -0400 (Eastern Daylight Time)

On Mon, 26 Apr 2010, Warren Kumari wrote:

> While going through back mail I noticed this and that there seems to be no 
> followups.

That's because there's been no official call for adoption.

And that is because the request is motivated by a reference in another 
document that is not itself a working group document.  And because I've 
heard that there are changes afoot in the other document. It appeared to 
me therefore that it was premature to announce a call for adoption of this 
draft.

Perhaps I misunderstood.  Randy, could you confirm that you would like to 
see this adopted by the working group without respect to the status of the 
other document?

--Sandy

>> we would like to sumbit draft-ymbk-rpki-rtr-protocol-05.txt as a sidr wg

---

From: Randy Bush <[email-masked]>
Date: Tue, 27 Apr 2010 11:58:25 -0700

> Randy, could you confirm that you would like to see this adopted by
> the working group without respect to the status of the other document?

i confirm that we submitted draft-ymbk-rpki-rtr-protocol as a wg
document irrespective of the status of draft-pmohapat-sidr-pfx-validate
(which should be out in -07 shortly).

i merely meant to note that there was a normative reference to it from
draft-pmohapat-sidr-pfx-validate, and hence draft-ymbk-rpki-rtr-protocol
was forced to come out of the closet of running code.

randy

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 27 Apr 2010 15:17:12 -0400 (Eastern Daylight Time)

My apologies.  I'll get right on this.

--Sandy

---

From: Geoff Huston <[email-masked]>
Date: Wed, 28 Apr 2010 15:04:44 +1000

three weeks ago I asked:

> 
> It seems to me that the essential requirements for securing proxy aggregation are missing at this stage, which makes it somewhat difficult for SIDR to work on mechanisms without some re-spinning of the SIDR WG Charter (or some other WG) that would permit the preliminary work on security requirements relating to proxy aggregation to come first.
> 
> So my question to the WG Co-chairs is: is work on securing  Proxy Aggregation within the current SIDR charter? If so, on what basis?

I would hope that by now the WGchairs have had sufficient time to consider this question, so I'd like to ask once more: Is work on securing  Proxy Aggregation within the current SIDR Charter? If so, on what basis?

regards,
 
Geoff

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 28 Apr 2010 13:16:14 -0400 (Eastern Daylight Time)

I have said that it was the consensus even before sidr was officially a wg 
that proxy aggregation would not be part of our work.  And I pointed to 
the email archive for that discussion.

You have said that you do not believe that it is possible at this point, 
so I don't think that you are unhappy with that statement.

So I am confused as to what further statement I could make that would help 
at this point.

Can you point me to where you still see a problem?

--Sandy

---

From: Geoff Huston <[email-masked]>
Date: Thu, 29 Apr 2010 04:11:13 +1000

Thank you for this response. As I had noted earlier, if you had made it clearer in which role you were posting in these discussions it would be easier for others, or at least myself, to understand when you were making pronouncements as WG chair and when you were asking questions and airing opinions as an individual participant. 

If proxy aggregation is "not part of our work" then the outcome of such actions, namely AS Sets in the AS_PATH is likewise "not part of our work." I will edit the roa validation draft accordingly.

On 29/04/2010, at 3:16 AM, Sandra Murphy wrote:

> I have said that it was the consensus even before sidr was officially a wg that proxy aggregation would not be part of our work.  And I pointed to the email archive for that discussion.
> 
> You have said that you do not believe that it is possible at this point, so I don't think that you are unhappy with that statement.
> 
> So I am confused as to what further statement I could make that would help at this point.
>

---

From: Chris Morrow <[email-masked]>
Date: Wed, 28 Apr 2010 14:33:15 -0400

Geoff Huston wrote:
> three weeks ago I asked:
> 
>> It seems to me that the essential requirements for securing proxy
>> aggregation are missing at this stage, which makes it somewhat
>> difficult for SIDR to work on mechanisms without some re-spinning
>> of the SIDR WG Charter (or some other WG) that would permit the
>> preliminary work on security requirements relating to proxy
>> aggregation to come first.
>> 
>> So my question to the WG Co-chairs is: is work on securing  Proxy
>> Aggregation within the current SIDR charter? If so, on what basis?
> 
> I would hope that by now the WGchairs have had sufficient time to
> consider this question, so I'd like to ask once more: Is work on
> securing  Proxy Aggregation within the current SIDR Charter? If so,
> on what basis?

(Apologies, this got lost (the original question) in other issues.)

Sandy did respond (phew!) but as a person in the group:

My (personal) feeling is that looking at the use of Proxy Aggregation in
the DFZ today shows a very small number of routes (less than 1% by
[email-masked]'s measurements) and almost all of these looked like
misconfig/mistake issues.

I think trying to decide how to authenticate proxy-aggregated routes is
a more difficult task than we should try to tackle. Is this route signed
by the original as-owner or the aggregator as an origin signing, or some
set? how do you determine what set? ugh...

If at all possible we should avoid this, it will open up issues and add
complication for something that is not in common/proper use today.

-chris

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 28 Apr 2010 14:37:32 -0400 (Eastern Daylight Time)

> If proxy aggregation is "not part of our work" then the outcome of such actions, namely AS Sets in the AS_PATH is likewise "not part of our work." I will edit the roa validation draft accordingly.

Actually, no, that is not the case.

When I say that proxy aggregation is not part of our work, I mean that 
sidr does not promise to protect BGP announcements formed by proxy 
aggregation.

While it is true that AS_SETS are principally generated in BGP updates by 
an AS that is doing proxy aggregation, AS_SETS are still part of the BGP 
protocol and might appear in a received AS_PATH.

Until and unless the idr working group decides to eliminate that feature 
from the BGP protocol, the sidr route validation must still make a 
statement about what happens when the AS_PATH origin is an AS_SET.

That is necessary for completeness.  Furthermore, without such a 
statement, implementers could make different decisions as to how to handle 
such cases and attack paths could result.

The sidr wg is not now considering anything but origin authorization, so 
an AS_PATH segment that is an AS_SET but is not the origin is not of our 
concern at all.

--Sandy

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 28 Apr 2010 14:46:43 -0400 (Eastern Daylight Time)

On Wed, 28 Apr 2010, Sandra Murphy wrote:

>> Thank you for this response. As I had noted earlier, if you had made it 
>> clearer in which role you were posting in these discussions it would be 
>> easier for others, or at least myself, to understand when you were making 
>> pronouncements as WG chair and when you were asking questions and airing 
>> opinions as an individual participant.
>> 
>> If proxy aggregation is "not part of our work" then the outcome of such 
>> actions, namely AS Sets in the AS_PATH is likewise "not part of our work." 
>> I will edit the roa validation draft accordingly.
>
> When I say that proxy aggregation is not part of our work, I mean that sidr 
> does not promise to protect BGP announcements formed by proxy aggregation.
>
> While it is true that AS_SETS are principally generated in BGP updates by an 
> AS that is doing proxy aggregation, AS_SETS are still part of the BGP 
> Until and unless the idr working group decides to eliminate that feature from 
> the BGP protocol, the sidr route validation must still make a statement about 
> what happens when the AS_PATH origin is an AS_SET.
>
> That is necessary for completeness.  Furthermore, without such a statement, 
> implementers could make different decisions as to how to handle such cases 
> and attack paths could result.
>
> The sidr wg is not now considering anything but origin authorization, so an 
> AS_PATH segment that is an AS_SET but is not the origin is not of our concern 
> at all.
>
>
> --Sandy

Whoops!

I meant:

--Sandy, still conversing as wg chair

>>>>> aggregation are missing at this stage, which makes it somewhat difficult 
>>>>> for SIDR to work on mechanisms without some re-spinning of the SIDR WG 
>>>>> Charter (or some other WG) that would permit the preliminary work on 
>>>>> security requirements relating to proxy aggregation to come first.
>>>>> 
>>>> consider this question, so I'd like to ask once more: Is work on securing 
>>>> Proxy Aggregation within the current SIDR Charter? If so, on what basis?
>>>> 
>>>> 
>>>> regards,
>>>> 
>>>> Geoff
>>>> 
>>>> 
>> 
>> 
>

---

From: Warren Kumari <[email-masked]>
Date: Wed, 28 Apr 2010 14:58:53 -0400

On Apr 28, 2010, at 2:37 PM, Sandra Murphy wrote:

>> Thank you for this response. As I had noted earlier, if you had  
>> made it clearer in which role you were posting in these discussions  
>> it would be easier for others, or at least myself, to understand  
>> when you were making pronouncements as WG chair and when you were  
>> asking questions and airing opinions as an individual participant.
>>
>> If proxy aggregation is "not part of our work" then the outcome of  
>> such actions, namely AS Sets in the AS_PATH is likewise "not part  
>> of our work." I will edit the roa validation draft accordingly.
>
> When I say that proxy aggregation is not part of our work, I mean  
> that sidr does not promise to protect BGP announcements formed by  
> proxy aggregation.
>
> While it is true that AS_SETS are principally generated in BGP  
> updates by an AS that is doing proxy aggregation, AS_SETS are still  
> part of the BGP protocol and might appear in a received AS_PATH.
>
> Until and unless the idr working group decides to eliminate that  
> feature from the BGP protocol, the sidr route validation must still  
> make a statement about what happens when the AS_PATH origin is an  
> AS_SET.
>
> statement, implementers could make different decisions as to how to  
> handle such cases and attack paths could result.
>
> The sidr wg is not now considering anything but origin  
> authorization, so an AS_PATH segment that is an AS_SET but is not  
> the origin is not of our concern at all.

Just for giggles I decided to see how how widely AS Sets were being  
used by having a quick look at route views data (yes, which I realize  
is incomplete, etc).

I used an as-path regexp to only get AS paths that included an AS_SET  
and then did some grep, sed and awk hackery to get a handle on the data.

I see zero AS_PATHs where the AS_SET is not the origin (i.e, where the  
AS_SET segment is not followed by i (internal), e (external) or ?  
(unknown):

wkumari@colon:~/tmp$ cat assets | grep '} [^ie\?]'

I see 39 unique paths where the "AS_SET" is only a single AS:
wkumari@colon:~/tmp$ cat assets | egrep "^\*" | sed 's/.*{\(.*\)}.*/ 
\1/' | sort | uniq | grep -v ',' | wc -l
39

and 21 unique paths where the AS_SET contains multiple ASs:
wkumari@colon:~/tmp$ cat assets | egrep "^\*" | sed 's/.*{\(.*\)}.*/ 
\1/' | sort | uniq | grep ','
11060,12262
1239,17079,27773
17746,64512
209,25729
21135,49476
25019,41426
25912,65427
31812,65473
33363,65129,65188
3356,8928,22351
3491,15412,19710
35821,35821,35821,35821
45514,45514,45514
45514,45514,45514,65081
4558,30994,33770
46124,46136
50693,64601,64604,64607,64608,64609,64610,65505
64520,64521
7470,24128,38865,45199
8002,15412
8508,24748,35434

Of these, only:
11060,12262
1239,17079,27773
209,25729
21135,49476
25019,41426
3356,8928,22351
3491,15412,19710
35821,35821,35821,35821
45514,45514,45514
4558,30994,33770
46124,46136
7470,24128,38865,45199
8002,15412
8508,24748,35434

do not contain private AS numbers. Some of the above contain only a  
single AS repeated multiple times (like 35821).

I don't want this to devolve into a discussion on the merits of  
aggregation, if AS_SETs should be deprecated or anything similar, this  
was just because I wanted know for my own sake what the numbers were  
and figured others might be interested too....

W

>>> I have said that it was the consensus even before sidr was  
>>> officially a wg that proxy aggregation would not be part of our  
>>> work.  And I pointed to the email archive for that discussion.
>>>
>>> You have said that you do not believe that it is possible at this  
>>> point, so I don't think that you are unhappy with that statement.
>>>
>>>>> It seems to me that the essential requirements for securing  
>>>>> proxy aggregation are missing at this stage, which makes it  
>>>>> somewhat difficult for SIDR to work on mechanisms without some  
>>>>> re-spinning of the SIDR WG Charter (or some other WG) that would  
>>>>> permit the preliminary work on security requirements relating to  
>>>>> proxy aggregation to come first.
>>>>>
>>>>> So my question to the WG Co-chairs is: is work on securing   
>>>>> Proxy Aggregation within the current SIDR charter? If so, on  
>>>>> what basis?
>>>>
>>>> securing  Proxy Aggregation within the current SIDR Charter? If  
>>>> so, on what basis?
>>>>
>>>>
>>>> regards,
>>>>
>>>> Geoff
>>>>
>>>>
>>
>>

-- 
Eagles soar but a weasel will never get sucked into a jet engine

---

From: Geoff Huston <[email-masked]>
Date: Thu, 29 Apr 2010 05:01:36 +1000

On 29/04/2010, at 4:46 AM, Sandra Murphy wrote:

>> When I say that proxy aggregation is not part of our work, I mean that sidr does not promise to protect BGP announcements formed by proxy aggregation.
>> 
>> While it is true that AS_SETS are principally generated in BGP updates by an AS that is doing proxy aggregation, AS_SETS are still part of the BGP protocol and might appear in a received AS_PATH.
>> 
>> Until and unless the idr working group decides to eliminate that feature from the BGP protocol, the sidr route validation must still make a statement about what happens when the AS_PATH origin is an AS_SET.
>> 
>> That is necessary for completeness.  Furthermore, without such a statement, implementers could make different decisions as to how to handle such cases and attack paths could result.
>> 
>> The sidr wg is not now considering anything but origin authorization, so an AS_PATH segment that is an AS_SET but is not the origin is not of our concern at all.
>> 
>> 
>> --Sandy
> 
> 
> Whoops!
> 
> I meant:
> 

thank you.

So I'm confused with this additional statement of yours in the role of WG chair.

To explain my confusion, when I grep AS_SET in RFC4271 I see it exclusively described with reference to aggregation  - for example: "AS_SETs are used in the route aggregation algorithm described in Section 9.2.2.2" 

So __with particular reference to the definition of an originating AS__ (which is where this particular particular strand started), where and why do AS_SETs have any relevance to the WG consideration of Origination Authorization? i.e. to phrase it in a more practical manner, what  precisely is the problem with applying the edit proposed by John Scudder to the roa validation draft? 

Again, I'm asking the WG chairs here for further clarification because the above exchange has managed to confused me.

 Geoff

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 28 Apr 2010 15:10:49 -0400 (Eastern Daylight Time)

The relative frequency of use of AS_SETs is interesting, but not really 
germane to the point here.

If we were trying to develop a protection for AS_SETs then we might want 
to ask the engineering question of where and how often they were used.

But for the purpose of validating received updates, we need a rule for 
what is done with AS_SETs that appear in the AS_PATH origin.  Lack of 
rules leaves opportunities for deliberate or accidental mischief.

AS_SETs might not be used very often, but that doesn't stop someone from 
using AS_SETs deliberately with malicious intent.

--Sandy, making a technical point as wg member and a document completeness 
point as wg chair.

On Wed, 28 Apr 2010, Warren Kumari wrote:

>> AS_PATH segment that is an AS_SET but is not the origin is not of our 
>> concern at all.
>
> Just for giggles I decided to see how how widely AS Sets were being used by 
> having a quick look at route views data (yes, which I realize is incomplete, 
> etc).
>
> I used an as-path regexp to only get AS paths that included an AS_SET and 
> then did some grep, sed and awk hackery to get a handle on the data.
>
>
> I see zero AS_PATHs where the AS_SET is not the origin (i.e, where the AS_SET 
> segment is not followed by i (internal), e (external) or ? (unknown):
>
> wkumari@colon:~/tmp$ cat assets | egrep "^\*" | sed 's/.*{\(.*\)}.*/\1/' | 
> sort | uniq | grep -v ',' | wc -l
> 39
>
> wkumari@colon:~/tmp$ cat assets | egrep "^\*" | sed 's/.*{\(.*\)}.*/\1/' | 
> sort | uniq | grep ','
> 11060,12262
> 1239,17079,27773
> 17746,64512
> 209,25729
> 21135,49476
> 25019,41426
> 25912,65427
> 31812,65473
> 33363,65129,65188
> 3356,8928,22351
> 3491,15412,19710
> 35821,35821,35821,35821
> 45514,45514,45514
> 45514,45514,45514,65081
> 4558,30994,33770
> 46124,46136
> do not contain private AS numbers. Some of the above contain only a single AS 
> repeated multiple times (like 35821).
>
> I don't want this to devolve into a discussion on the merits of aggregation, 
> if AS_SETs should be deprecated or anything similar, this was just because I 
> wanted know for my own sake what the numbers were and figured others might be 
> interested too....
>
> W
>
>
>
>> 
>> 
>> 
>> --Sandy
>> 
>> 
>> 
>>> 
>>> 
>>>> I have said that it was the consensus even before sidr was officially a 
>>>> wg that proxy aggregation would not be part of our work.  And I pointed 
>>>> to the email archive for that discussion.
>>>> 
>>>>>> difficult for SIDR to work on mechanisms without some re-spinning of 
>>>>>> the SIDR WG Charter (or some other WG) that would permit the 
>>>>>> preliminary work on security requirements relating to proxy aggregation 
>>>>>> to come first.
>>>>>> 
>>>>> securing  Proxy Aggregation within the current SIDR Charter? If so, on 
>>>>> what basis?
>>>>> 
>>>>> 
>>>>> regards,
>>>>> 
>>>>> Geoff
>>>>> 
>>>>> 
>>> 
>>>

---

From: Chris Morrow <[email-masked]>
Date: Wed, 28 Apr 2010 15:24:52 -0400

> using AS_SETs deliberately with malicious intent.

right so as a starting point:
"AS_SET in an origin is unvalidatable."

how about that? (I think this is fine since:
1) they aren't used in production very much anymore
2) where used, they seem to be mis-used
3) the rules for how you do verification/validation of an AS_SET are at
best murky.

-chris
(regular user)

> --Sandy, making a technical point as wg member and a document
> completeness point as wg chair.
> 
>>>> Thank you for this response. As I had noted earlier, if you had made
>>>> it clearer in which role you were posting in these discussions it
>>>> would be easier for others, or at least myself, to understand when
>>>> you were making pronouncements as WG chair and when you were asking
>>>> questions and airing opinions as an individual participant.
>>>>
>>>> such actions, namely AS Sets in the AS_PATH is likewise "not part of
>>>> our work." I will edit the roa validation draft accordingly.
>>>
>>> The sidr wg is not now considering anything but origin authorization,
>>> so an AS_PATH segment that is an AS_SET but is not the origin is not
>>> of our concern at all.
>>
>> wkumari@colon:~/tmp$ cat assets | egrep "^\*" | sed
>> 's/.*{\(.*\)}.*/\1/' | sort | uniq | grep -v ',' | wc -l
>> 39
>>
>> wkumari@colon:~/tmp$ cat assets | egrep "^\*" | sed
>> 's/.*{\(.*\)}.*/\1/' | sort | uniq | grep ','
>> 11060,12262
>> 1239,17079,27773
>> 17746,64512
>> 209,25729
>> 21135,49476
>> 25019,41426
>> 25912,65427
>> 31812,65473
>> 33363,65129,65188
>> 3356,8928,22351
>> 3491,15412,19710
>> 35821,35821,35821,35821
>> 45514,45514,45514
>> 45514,45514,45514,65081
>> 4558,30994,33770
>> 46124,46136

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 28 Apr 2010 16:10:28 -0400 (Eastern Daylight Time)

> To explain my confusion, when I grep AS_SET in RFC4271 I see it exclusively described with reference to aggregation  - for example: "AS_SETs are used in the route aggregation algorithm described in…

Section 9.2 is describing the "Update-Send Process."

My statements about the AS_SET concern what happens in the Update receipt 
process, when the route validation is performed.

> So __with particular reference to the definition of an originating AS__ (which is where this particular particular strand started), where and why do AS_SETs have any relevance to the WG considerati…

The algorithm in 9.2.2.2 that is referenced above can result in an AS_SET 
as the first segment in an AS_PATH.  Also, RFC4271 has plenty of 
references to AS_SETs occurring as the first segment in an AS_PATH (i.e., 
the originating AS).  So an originating AS of type AS_SET is a legal part 
of BGP and will not be rejected by current implementations.

An originating AS in the AS_PATH of type AS_SET is therefore part of our 
work because it will occur in inputs that the route validation must judge.

I as wg chair am correcting your statement 'the outcome of such 
actions, namely AS Sets in the AS_PATH is likewise "not part of our 
work."'

When you say "what precisely is the problem with applying the edit 
proposed by John Scudder to the roa validation draft?", I presume that you 
are referring to John's message of 3 Apr, in which he says:

   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.

I am not saying that there is anything wrong with John's edit.

I am not judging consensus that this would be the best way of dealing with 
an originating AS of type AS_SET.

I am saying that we must have SOME rule of what happens when validating a 
route that contains an originating AS of type AS_SET, for document and 
implementation completeness.

--Sandy, as wg chair

---

From: Geoff Huston <[email-masked]>
Date: Thu, 29 Apr 2010 16:06:24 +1000

> 3) the rules for how you do verification/validation of an AS_SET are at

You ask: "how about that?"

That still works for me. Ironically (or any other adjective that matches - I can think of quite a few more extreme ones that I could substitute) this is _precisely_ where all this started when I proposed using the following definition of an "origin AS" (in my note from 4 April):

"A route's "origin AS" is the final element of the route object's
 AS_PATH attribute.  If the final AS_PATH element is an AS Set,
 indicating that the route is an aggregate, then the origin AS
 cannot be determined."

  Geoff

---

From: Chris Morrow <[email-masked]>
Date: Thu, 29 Apr 2010 11:29:40 -0400

>> "AS_SET in an origin is unvalidatable."

("on reciept" i forgot to add)

>  indicating that the route is an aggregate, then the origin AS

cool, so I actually only did half the problem (reciept), on send as well
we'd have to say: "If you are sending an update (announce or withdrawal)
and that update's origin is an AS_SET, you can not sign the update."

I think that makes sense because you can't determine which AS in the
AS_SET should do the signing?

-chris
(again as a regular user)

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Thu, 29 Apr 2010 11:42:18 -0400

When you said "you can not sign the update",
did you mean "you cannot register a ROA for your prefix with the AS set"?

Sriram

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Morrow
> Sent: Thursday, April 29, 2010 11:30 AM
> To: Geoff Huston
> Cc: Sandra Murphy; sidr wg
> Subject: Re: [sidr] SIDR Charter Question
> 
> 
> 
> Geoff Huston wrote:
> > That still works for me. Ironically (or any other adjective that matches - I can think of
> quite a few more extreme ones that I could substitute) this is _precisely_ where all this
> started when I proposed using the following definition of an "origin AS" (in my note from 4
> April):
> >

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 29 Apr 2010 12:11:26 -0400 (Eastern Daylight Time)

> indicating that the route is an aggregate, then the origin AS

Ironically, this also works to satisfy the requirement I stated that 
there needed to be some statement of what to do with AS_SETs.

(Presuming that you intend that "cannot be determined" will lead to one of 
the defined validation conditions (e.g., "unknown", but that's not my 
call), not be left to some arbitrary action devised by the implementer.)

Just to be clear, even the current language in 
draft-ietf-sidr-roa-validation-05 satisfies the requirement.  I am not 
making a consensus statement about which statement should be chosen.

--Sandy, speaking as wg chair

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Thu, 29 Apr 2010 12:16:08 -0400

May be we could include a BCP statement or warning within the
algorithm document for the (very few) users of AS sets.
If they use, for example, [AS42] or [AS42, AS42] type of AS set
for whatever reason (i.e., with singleton AS in the AS set
or the same ASN repeated multiple times) and also register a ROA for their
prefix with that ASN (AS42 in the example) --
the BCP statement would warn them that
their ROA would thwart a potential hijacker of their prefix but
they should not expect to receive a positive ("Valid") assertion for their
own update which contains that AS set as origin.
Also, the same applies for cases when they actually do a genuine proxy
aggregation such as using an AS set [AS42, AS43, AS44] for example
and  register three ROAs for their aggregate prefix for each
of the  three ASNs. Again, they should not expect a positive ("Valid")
assertion for their own update which contains that AS set as origin.

Sriram

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Geoff Huston
> Sent: Thursday, April 29, 2010 2:06 AM
> To: Chris Morrow
> That still works for me. Ironically (or any other adjective that matches - I can think of quite
> a few more extreme ones that I could substitute) this is _precisely_ where all this started
> when I proposed using the following definition of an "origin AS" (in my note from 4 April):
>

---

From: Chris Morrow <[email-masked]>
Date: Thu, 29 Apr 2010 12:46:01 -0400

> did you mean "you cannot register a ROA for your prefix with the AS set"?

yes, three folks now have corrected me. (I got ahead of myself)

-chris

---

From: Warren Kumari <[email-masked]>
Date: Thu, 29 Apr 2010 12:55:56 -0400

> own update which contains that AS set as origin.

I am not following you here -- can you please explain what you mean by  
"should not expect to receive a positive ("Valid") assertion for their  
own update which contains that AS set as origin."?

> > >> germane to the point here.

Well, I sort of think it is -- if 95% of routes contained AS_SETs in  
the origin then saying that you just cannot validate routes with  
AS_SETs in the origin is a non-starter.

> > >> rules leaves opportunities for deliberate or accidental mischief.

Yes -- because their occurrence is not huge, we can make the call that  
these routs just do not get the win...

W

--
"Build a man a fire, and he'll be warm for a day. Set a man on fire,  
and he'll be warm for the rest of his life." -- Terry Pratchett

---

From: Randy Bush <[email-masked]>
Date: Thu, 29 Apr 2010 13:46:49 -0700

as i said last week, though a bit more tersely :)

would folk please look at rfc 4271 section 5.1.7.  this specifies the
optional attribute AGGREGATOR, which should be the as number of the
aggregating as.  you will see that this is the asn used to validate
against the roa in draft-pmohapat-sidr-pfx-validate-07.txt.

could you point out the harm in this simple seeming approach?

randy

---

From: Sandra Murphy <[email-masked]>
Date: Fri, 30 Apr 2010 12:59:46 -0400 (Eastern Daylight Time)

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.

But the conversation spiraled from there.

---

From: Geoff Huston <[email-masked]>
Date: Sat, 1 May 2010 04:44:21 +1000

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