Brian,
Two comments:
1) In your first example, the use of the term "registration" indicates
that we might have some confusion on the semantics of a ROA. We envision
that certificates will be issued in conjunction with the registration of
IP resources (e.g. The RIR issues a certicate to the LIR when the LIR
obtains resources from the RIR). ROAs are not intended to reflect
registration but are merely a statement by the holder of IP resources
(i.e. the party to whom the resources are registered) that a particular
AS is permitted to originate routes to particular IP prefixes. If this
was not your understanding, then I'd like your help in finding places in
the ROA document where wording can changed to make these semantics
clear. (If this was your understanding, then I apologize for
mis-understanding your example.)
In any case, I personally believe that the SIDR Resource PKI is an
inefficient way for the RIRs to enforce policy upon the LIRs. So I'm
personally not inclined to make changes in an attempt to make the R-PKI
suitable for that purpose. With regards to your second example, if the
LIR wants to prohibit a an end-user from announcing prefixes through
another provider (hole punching), then I think the right answer is for
the LIR NOT to issue a certificate to the end-user (this prevents the
end-user from issuing ROAs that grant permissions to other providers)
and instead to issue an appropriate ROA for the aggregate prefix (which
persumably names the LIR's own AS number).
2) With regards to format, there was discussion in March in Philidelphia
which led to the addition of the max-length field. At that time, the
question was raised as to whether there should also be a min-length
field and at the time there seemed to be no operator requirement for
such a field. In particular, to justify a min-length field one would
need a use-case where a registered holder of IP resources wishes to give
an AS permission to advertise many long prefixes, but expressly forbid
the AS from advertising the aggregate prefix. Such a use-case seems
unlikely because in most cases advertising the aggregate prefix does no
harm (and indeed will be ignored in the presence of advertisements for
longer prefixes) although I could be missing something.
- Matt Lepinski
Brian Dickson wrote:
Geoff Huston wrote:
WG Chair hat _OFF_
On 07/10/2008, at 10:41 AM, Brian Dickson wrote:
Rather than having:
IP_address / length le maxLength (length <= maxLength <=
address-family-max-length)
this would be
IP_address / length ge minLength le maxLength (length <= minLength
<= maxLength <= address-family-max-length)
Its isomorphic in one sense isn't it? The described representation
lists the prefixes in the maximally permitted aggregate format and by
the optional MaxLength parameter which specifies the finest level of
more specifics that could be originated from this ROA. Your suggested
representation allows a number of aggregatable prefixes to be
aggregated as a described prefix, as long as they share a common
minLength value.
_personally_ I'm unsure that this alternate representation would offer
any superior flexibility in the representation of ROAs.
I'm not sure if any or all of these kinds of use cases are appropriate,
but if any of them are, they may serve to demonstrate the compactness
achievable with this representation.
Examples:
RIR->LIR, RIR has certain specific policies it wishes to enforce
regarding LIR assignments to end-users -- anything bigger than /X
requires justification (i.e. approval) and registration (i.e. ROA).
Either RIR has to create a large swath of ROAs, each of size /X, or it
can create one ROA with minLength=X. (In this example, maxLength is
irrelevant and presumed identical.)
Exceptions are needed, of course, for /Y (Y < X), but each of these can
be done with separate ROAs.
Even as a worst case scenario, no *more* ROAs are needed than in the
original case.
In a best case scenario, many orders of magnitude quantity of ROAs need
never be created, and RIR's policies are enforced directly via ROAs.
LIR->PA customers, LIR wants to aggregate but also wants to ensure no
customers are able to punch holes in the PA space.
LIR restricts the minLength to something not globally routable (e.g. /25
in IPv4, /49 in IPv6).
This ties the customer to the LIR, by preventing PA blocks being
announced via third parties (hole punching).
One ROA can be assigned, whether the amount of space is small or large.
Internal aggregation by the PA customer is limited, of course, but that
is the intention of the LIR.
There may be other cases that I'm missing, but which others may see,
based on the above examples.
Things related to IPv6 nibble boundaries (for ip6.arpa reasons) but
where the current use is only a portion of the larger (reserved) block;
ROAs with differing minLength can be created as the customer grows,
providing a viable path with no "flag day" needed.
It is certainly no worse than the previous representation, as it is
strictly a superset.
The main question, IMHO, is, does it add sufficient value to justify
making the change?
(I think it's the only question, actually.)
Brian
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
