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:12 PM -0600 11/24/08, George Michaelson wrote:
>Some people now appear to want an *implicit* meaning of 'if not in 
>ROA, then excluded' -but, they also somehow want this to be 
>conditional.

I an incremental deployment context, a context with which we will 
have to deal for several (many?) years, we can't reject all 
assertions that are not verifiable via use of ROAs.

>Secondly, there is a semantic difference between 'all which is not 
>explicitly permitted is forbidden' and 'this is explicitly 
>forbidden'.

ibid.

>We have tried to make an explicit semantic around the word NOT:
>
>	NOT prefix <x>/<y>
>
>ie do NOT accept <x>/<y> as a valid route. Thats what a BOA says. 
>its explicit what prefixes are being knocked out.
>
>Others seem to want an *implicit* NOT. But, it appears to be a 
>conditionally implicit NOT: how can you decide when it does, or does 
>not apply?
>
>This is of course two different problems:
>
>1) how do you conditionally flag it does or doesn't apply? The ROA 
>has no syntax for this
>2) what is the scope of the "NOT" logic?
>
>in an explicit (BOA) world, the scope can be any prefix(s) you like: 
>its an explicit statement of intent around the NOT word.

a BOA cannot make assertions about prefixes the issues does not 
control, so the statement above is not quite true.

>in a world of ROA only, the only NOT you can have is "anything else" 
>so its demonstrably semantically weaker.

I proposed issuing a ROA with an AS of 1, so that it would explicitly 
"trump" any non-authenticated assertions about the prefix(es) in 
question. That is a counter to the generally less-powerful ROA 
semantics, yet it requires no new processing by relying parties. 
That's why I prefer a ROA-based approach to a BOA-based approach.

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