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
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
