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