Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation

From: Geoff Huston <[email-masked]>
Date: Thu, 30 Jul 2009 20:59:32 +1000

WG Chair hat off

I posted the note below to the SIDR WG on the 27th May, and there was  
just two followups from the WG, one in favour of the proposed revision  
and one opposed, which really was not enough of a response to figure  
out what represented some approximation of a general view of WG members.

It is my impression from the WG discussion at IETF 75 on the  
interpretation of a ROA that there is a common view that a ROA acts as  
an implicit "denial" for those route objects that have address  
prefixes that are more specific than the set of prefixes specified in  
the ROA, and for those route objects which have originating AS numbers  
other than those listed in valid ROAs that span the address prefix  
listed in the route object.

I therefore propose to the WG that I will resubmit draft-huston-sidr- 
roa-validation-01.txt as draft-ietf-sidr-roa-validation-02.txt on the  
basis that this appears to be consistent with the discussion I have  
just heard in the WG meeting this morning.

thanks,.

Geoff

On 27/05/2009, at 6:39 AM, Geoff Huston wrote:

> Hi Sandy,
>
> WG co-chair hat OFF.
>
> Following the WG discussion on the topic of ROA validation at IETF  
> 74 the draft's authors gained the impression that the rough  
> consensus position from the last SIDR WG meeting was to drop to drop  
> the concept of BOAs and use only ROAs. The authors have prepared a  
> revision to the WG document that reflects that understanding.  
> However, the authors would like to confirm that impression with  
> yourself as the relevant co-chair and with the WG, via this note,  
> before submitting this document as draft-ietf-sidr-roa- 
> validation-02.txt. You, and WG members of course, can review the  
> proposed revisions to the WG document that reflect what the authors  
> believe is the WG's rough consensus position on this topic at draft- 
> huston-sidr-roa-validation-01.txt
>
> thanks,
>
> Geoff Huston & George Michaelson
>
>
>
>
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Rob Austein <[email-masked]>
Date: Fri, 31 Jul 2009 00:42:44 +0200

> listed in the route object.

I'd phrase it differently, but if I understand what Geoff is saying, I
agree.  Testing by paraphrase:

1) The prefix/len-maxlen ROA syntax is just a terse abbreviation for
   the set of all possible prefixes that start with the specified
   prefix value and have length between len and maxlen, inclusive.
   Prefixes with length greater than maxlen are -not- included in the
   set.

2) If any ROAs exist that cover a particular prefix, the ASNs
   specified in those ROAs, and -only- the ASNs specified in those
   ROAs, are authorized to originate that prefix.

I think this amounts to the same thing as what Geoff said.

---

From: Geoff Huston <[email-masked]>
Date: Fri, 31 Jul 2009 19:55:12 +1000

> I think this amounts to the same thing as what Geoff said.

thanks Rob.

I believe that we agree  - My phrase "more specific than the set of  
prefixes specified in the ROA" is intended to mean a prefix whose  
length is greater than maxlen (i.e. more specific than what is  
specified by the maxlen parameter of the ROA.)

thanks

   Geoff

---

From: Terry Manderson <[email-masked]>
Date: Fri, 31 Jul 2009 07:57:56 -0700

> specified by the maxlen parameter of the ROA.)

May I ask for clarification on two items, just to be sure I have it clear?

1) The ROA ends with an implicit deny for any more specific prefix not
encapsulated by maxLength. (ie stop more specific hijack)? (yes/no)

2) The SIDR-WG is following the paradigm of 'make before break'? (yes/no)

Cheers
Terry

---

From: Geoff Huston <[email-masked]>
Date: Sat, 1 Aug 2009 08:36:39 +1000

WG chair hat off

> encapsulated by maxLength. (ie stop more specific hijack)? (yes/no)

"ends"?

perhaps an example may help here

A ROA is issued for 203.0.113.0/24, maxlength 25, oroginating AS 65534

using only this ROA, and nothing else, the revised draft would  
generate the following outcomes:

203.0.113.0/24, originated by AS 65534 -> "valid"
203.0.113.128/25, originated by AS 65534 -> "valid"

203.0.113.0/26, originated by AS 65534 -> "invalid" (more specific  
than max length permits)

203.0.113.0/24, originated by AS 1 -> "invalid" (no AS match)
203.0.113.128/25, originated by AS 1 -> "invalid" (no AS match)

203.0.113.0/26, originated by AS 1 -> "invalid" (no AS match and more  
specific than max length permits)

203.0.0.0/8, originated by AS 65534 -> "unknown"
202.0.0.0/8, originated by AS 65534 -> "unknown"

> 2) The SIDR-WG is following the paradigm of 'make before break'?  

WG co-chair hat off - still.

Do IETF WGs "follow" paradigms? How are such paradigm's "adopted" to  
follow in the first place? Are such "paradigms" intended to act as  
strictly applied technical constraints? Where are the paradigm police  
to enforce that such paradigms are obeyed?

Personally I don't think that I understand that question in the  
context of an individual IETF WG.  Perhaps others may be more  
confident in exploring the implications of such an assertion that WGs  
are constrained to follow "paradigms." From my experience with the  
IETF I would guess that you may have a more substantive discussion on  
that topic  in an IETF Plenary or on the IETF mailing list.

Geoff