Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt

From: Stephen Kent <[email-masked]>
Date: Mon, 1 Dec 2008 11:31:58 -0500

Given Geoff's examples of how to use BOAs, I think the only vase that 
cannot be handled by the ROA use convention I proposed is the 
negative assertion about As numbers.

Geoff, do you agree?

Steve
_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Geoff Huston <[email-masked]>
Date: Tue, 2 Dec 2008 06:59:29 +1100

WG Hair hat OFF

Hi Steve,

What I _think_ you describes as the "ROA use convention" is the use of  
a ROA with an AS of 0 to act as an explicit denial in terms of saying  
"these prefixes are bogons". I could be wrong in my understanding of  
course.

I must admit that right now I don't think I understand your proposed  
"ROA use convention" clearly enough to agree with your assertion

The BOA Approach:

The BOA document is coupled with the ROA validation document so that  
the ROA interpretation and the BOA interpretation are explicitly  
described. in this context the ROA does NOT act with a double meaning  
- it is an explicit authority without any implicit negation  
connotations. The presence of a ROA does not act as a form of negation  
of any other form of route origination. The BOA has no max length  
attribute - any more specific of any prefix described in the BOA is  
encompassed in the BOA.

The "ROA use convention":

This "ROA use convention" has me confused. In particular my confusion  
lies in the following areas:

   1. Does a 'convention ROA' has any implicit denial associated with  
it, or is it a simple positive assertion as described above?

   2. How should a ROA with a AS value of 0 and a maxlength attribute  
be interpreted.
       Does a ROA for prefix=10.0.0.0/8 maxlength=8, AS=0 say anything  
at all about 10.0.0.0/9?

So if you don't mind I'll reserve judgement on your question and  
observe that while the BOA adds a further object to the repertoire of  
'recognised' RPKI signed objects, it does so in a manner that makes  
negation explicit, does not rely on variable interpretation of ROAs,  
does not stretch the ROA semantics beyond the simple positive  
authority to as AS to originate a route and allows for incremental  
piecemeal deployment in the network.

Regards,

    Geoff

On 02/12/2008, at 3:31 AM, Stephen Kent wrote:

> Given Geoff's examples of how to use BOAs, I think the only vase  
> that cannot be handled by the ROA use convention I proposed is the

---

From: Stephen Kent <[email-masked]>
Date: Tue, 2 Dec 2008 19:24:12 -0500

At 6:59 AM +1100 12/2/08, Geoff Huston wrote:
>WG Hair hat OFF
>
>Hi Steve,
>
>What I _think_ you describes as the "ROA use convention" is the use 
>of a ROA with an AS of 0 to act as an explicit denial in terms of 
>saying "these prefixes are bogons". I could be wrong in my 
>understanding of course.

I would not use the term "bogons" right now, given the debate about 
the meaning. The intent of the AS 0 ROA convention is to make an 
assertion that can be verified within the RPKI and which gives a 
relying party a basis for rejecting unverified assertions about 
routes for the prefix(es) in question.

>described. in this context the ROA does NOT act with a double 
>meaning - it is an explicit authority without any implicit negation 
>connotations.

While it is fair to say that issuing an AS 0 ROA is intended to 
convey a special meaning, the processing of such a ROA is exactly the 
same as for any other ROA. So I hesitate to use the phrase "double 
meaning" even though I am sympathetic with your use of that term.

>The presence of a ROA does not act as a form of negation of any 
>other form of route origination. The BOA has no max length attribute 
>- any more specific of any prefix described in the BOA is 
>encompassed in the BOA.
>
>This "ROA use convention" has me confused. In particular my 
>confusion lies in the following areas:
>

An AS 0 ROA is a positive assertion about the prefixes expressed in 
it, as far as RP software is concerned. The "feature" of this 
assertion is that, any unauthenticated assertions about the prefixes 
should be rejected in favor of this verifiable ROA (assuming that the 
ROA was signed by an entity that holds the prefixes in question). In 
saying that I am making some assumptions about how ROs use ROAs, and 
Danny has argued that we need to be more precise about such 
assumptions.

I see the AS 0 ROA as a valuable tool to deal with unallocated and 
reserved address space, during the very long period when relying 
parties will see a mix of verifiable and unverifiable assertions 
about route origination. I have not thought so much about the utility 
of this capability in a fully deployed system. I also did not 
consider assertions about AS numbers, a feature of BOAs.

>       Does a ROA for prefix=10.0.0.0/8 maxlength=8, AS=0 say 
>anything at all about 10.0.0.0/9?

To prevent unauthenticated assertions about all more specific 
prefixes from being accepted, the max length would have to be 32. 
Otherwise, an unauthenticated assertion about a longer prefix would 
not be "trumped" by the AS 0 ROA.

>observe that while the BOA adds a further object to the repertoire 
>of 'recognised' RPKI signed objects, it does so in a manner that 
>makes negation explicit, does not rely on variable interpretation of 
>ROAs, does not stretch the ROA semantics beyond the simple positive 

I admit that the AS 0 convention is a way of expressing a negative 
assertion about resources under the control of the ROA signer. 
However, I think the fact that this mechanism does not create a new 
type of sighed object, and requires no new processing, makes it 
worthwhile to consider.

Steve

---

From: Andrew Newton <[email-masked]>
Date: Wed, 10 Dec 2008 09:27:43 -0500

On Dec 2, 2008, at 7:24 PM, Stephen Kent wrote:

> should be rejected in favor of this verifiable ROA (assuming that  
> the ROA was signed by an entity that holds the prefixes in  
> question). In saying that I am making some assumptions about how ROs  
> use ROAs, and Danny has argued that we need to be more precise about  
> such assumptions.
>
> about route origination. I have not thought so much about the  
> utility of this capability in a fully deployed system. I also did  
> not consider assertions about AS numbers, a feature of BOAs.

Steve,

Sorry for the late reply on this subject, but I was rereading the  
archives and it brought to my recollection a statement you made at the  
microphone in Minneapolis regarding AS 0 ROAs.  I didn't readily grasp  
the meaning of what you said, so I'm seeking clarification.

As I recall, you stated that a registry wishing to use a BOA to cover  
its space could just as well use AS 0 ROAs with a different practice.   
Whenever that registry allocated space, it would have to reissue the  
AS 0 ROAs so the newly allocated space is not covered.  At least I  
think that was the gist of what you described.

Is this correct, or can you explain again the scenario you mentioned?

-andy

---

From: Stephen Kent <[email-masked]>
Date: Fri, 12 Dec 2008 10:52:28 -0500

At 9:27 AM -0500 12/10/08, Andrew Newton wrote:
>>assertion is that, any unauthenticated assertions about the 
>>prefixes should be rejected in favor of this verifiable ROA 
>>(assuming that the ROA was signed by an entity that holds the 
>>prefixes in question). In saying that I am making some assumptions 
>>about how ROs use ROAs, and Danny has argued that we need to be 
>>more precise about such assumptions.
>>
>archives and it brought to my recollection a statement you made at 
>the microphone in Minneapolis regarding AS 0 ROAs.  I didn't readily 
>grasp the meaning of what you said, so I'm seeking clarification.
>
>As I recall, you stated that a registry wishing to use a BOA to 
>cover its space could just as well use AS 0 ROAs with a different 
>practice.  

Andy,

Your characterization is good paraphrase of my comments at the mic. 
In fairness to Geoff's BOA proposal, my ROA As 0 convention is not as 
powerful, in that it has no provisions for making a negative 
assertion about AS numbers.

If I were a registry (or an ISP) making use of the AS 0 ROA approach, 
I would issue one EE cert and one associated ROA )covering all of the 
unallocated space that I hold). The EE cert would have a lifetime 
consistent with the time I take to respond to allocation requests, 
maybe on 1-day lifetime. That way I would not have to put the EE cert 
on a CRL when a new AS 0 ROA was issued; I'd just be issuing one new 
cert and one new ROA every day. Since it is probably good practice to 
issue a CRL every day, the set of objects published by the 
registry/ISP would have to change that frequently anyway, so this is 
not much of a new burden, (e.g., the manifest has to change whenever 
a new CRL is issued).

I also note that even if we don't adopt AS 0 ROAs as a recognized way 
to make this sort of assertion, any ROA issuer can use it anyway, 
either explicitly or via analogous means :-).

Steve

---

From: Andrew Newton <[email-masked]>
Date: Fri, 12 Dec 2008 14:31:10 -0500

On Dec 12, 2008, at 10:52 AM, Stephen Kent wrote:

> In fairness to Geoff's BOA proposal, my ROA As 0 convention is not  
> as powerful, in that it has no provisions for making a negative  
> If I were a registry (or an ISP) making use of the AS 0 ROA  
> approach, I would issue one EE cert and one associated ROA )covering  
> all of the unallocated space that I hold). The EE cert would have a  
> lifetime consistent with the time I take to respond to allocation  
> requests, maybe on 1-day lifetime. That way I would not have to put  
> the EE cert on a CRL when a new AS 0 ROA was issued; I'd just be  
> issuing one new cert and one new ROA every day. Since it is probably  
> good practice to issue a CRL every day, the set of objects published  
> by the registry/ISP would have to change that frequently anyway, so  
> this is not much of a new burden, (e.g., the manifest has to change  
> whenever a new CRL is issued).
>
> I also note that even if we don't adopt AS 0 ROAs as a recognized  
> way to make this sort of assertion, any ROA issuer can use it  
> anyway, either explicitly or via analogous means :-).
>
> Steve

Steve,

Thanks for the information.  That was very helpful.

As to the use of a negative attestation (be it BOA or AS 0 ROA) by a  
registry, that will most likely be decided by policy in my opinion.   
But I do believe there are operational differences between the two  
approaches.

A 1 day lifetime is reasonable during the working week, but weekends  
and holidays are a different story.  And often times those weekends  
are used for maintenance windows.  Additionally, there are exception  
cases were allocations need to be updated urgently and then there are  
trouble shooting events... in both these situations an AS 0 ROA acts  
like an another moving part that needs to be double checked whereas a  
BOA requires less care and maintenance.  From my perspective, a BOA  
seems less error prone should negative attestations be desired.

I think there is also another angle to the adoption issue that needs  
consideration.  As I stated, I do not know if negative attestations  
will be immediately adopted and at what level.  But let's hypothesize  
about a community that adopts RPKI and does not use them.  And then, 5  
years after adoption they determine that such a thing is needed.  To  
get them, there would be a need to cycle back through the standards  
track and software adoption curve.  It seems better to have BOAs in  
the standard now and have them ignored then to have to iterate through  
another standards & software adoption process.

-andy

---

From: Stephen Kent <[email-masked]>
Date: Fri, 12 Dec 2008 16:46:25 -0500

At 2:31 PM -0500 12/12/08, Andrew Newton wrote:
>...
>But I do believe there are operational differences between the two approaches.
>
>cases were allocations need to be updated urgently and then there 
>are trouble shooting events... in both these situations an AS 0 ROA 
>acts like an another moving part that needs to be double checked 
>whereas a BOA requires less care and maintenance.  From my 
>perspective, a BOA seems less error prone should negative 
>attestations be desired.

First, recall that each CRL says when the next CRL will be issued, so 
if one decides to not issue CRLs on weekend and holidays, that 
distinction is easy to express in the CRL NextUpdate field. 
Similarly, if the intent is to not make new allocations and enable 
then during such periods, the AS 0 ROA can be given a longer lifetime 
for those days.

Separately, I don't think I understand the operational difference. A 
BOA, as a signed object, would need to be revoked just as an AS 0 ROA 
would, and it would have the same lifetime management requirements. 
Which aspect of BOAs vs. AA 0 ROAs, do you believe make the former 
easier to deal with in these contexts?

>will be immediately adopted and at what level.  But let's 
>hypothesize about a community that adopts RPKI and does not use 
>them.  And then, 5 years after adoption they determine that such a 
>thing is needed.  To get them, there would be a need to cycle back 
>through the standards track and software adoption curve.  It seems 
>better to have BOAs in the standard now and have them ignored then 
>to have to iterate through another standards & software adoption 
>process.

I think there are several, separable issues here. One issue is 
whether we need to make provisions for negative assertions. If so, 
then I agree that making provisions for such assertions sooner is 
better.  A second issue is the scope of such assertions (just address 
space or address space and AS numbers).  Then  we can ask what form 
such assertions should take, e.g., BOAs vs. ROAs, vs. ?

I observe that if the scope of such assertions is just address space, 
and not AS numbers I believe we can do this via ROAs, and thus we 
already have the necessary mechanism available. It then becomes a 
matter of policy whether to make such assertions ort not.

Steve