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

[Stephen Kent <[e-mail]>]

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.

>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.

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.
>
>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?

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.

>   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?

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.

>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.

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
_______________________________________________
sidr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sidr