(Sorry in advance - long post ahead. Please read, however, when you have
time, everyone. There's some valuable operator input here.)
Matt Lepinski wrote:
> 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.)
I think I understand what you're saying.
However, I am trying to reconcile several things, and am having
difficulty in figuring out what EE/ROA things need to be issued, by
whom, and what the validation methodology is.
I'm specifically considering the BGP default-free zone, and prefixes
seen globally.
Here's how filters can be built today:
* IP allocations are done
o either entire PA blocks to ISPs for reassignment to their
customers, and aggregation to the whole block before global
announcement (at least in theory)
o or PI blocks to end sites who are multi-homed
* IRR registration is made by the originating AS (the ISP or
multi-homed entity, using its own ASN as Origin: attribute for
Route: objects, plus its Aut-num: object)
* IRR registration is made for as-sets (hierarchically, too, to
arbitrary depth) reflecting customer/transit relationships
* IRR registration of peering announcements (who announces what to
whom, in RPSL) is done
* Expansion of IRR contents on a per-peer or per-customer basis is
done, expanding into permitted AS_PATH and PREFIX lists (not
necessarily tied together, unfortunately, and not necessarily as
complete as we would like)
In the "-roa-" drafts, the term "originate" is used consistently, but I
am unclear if that maps 1:1 with "Origin:" in the IRR. Does it mean,
strictly, originate, or does it also mean "announce to a peer", where
the announcer heard it from some third party, i.e. the announcer has the
prefix with a non-empty as-path?
I can see how the first recipient of such an announcement could validate
the prefix based on ROA.
How does someone more than one AS away validate using ROAs, if he/she is
not able to know for certain that the sender is also authorized to send
all prefixes for the remote AS (the alleged originator)?
And/or, presumably, there is the ability to authorize an upstream AS to
announce all of one's AS, and that that is a transitive property.
Is the ROA used for this, or is there some other "thing" that is used
for signing/validating?
Now, for a use case:
There are classes of allocations which are made in a very particular
method, which I believe the RIRs would like to have means for
restricting their use.
These are "critical infrastructure" assignments, typically /24's to be
used in a PI fashion, which may be assigned en mass, e.g. from larger
ranges of contiguous space (perhaps by coincidence, but contiguous
nonetheless).
These could show up as a sequence of /23,/22,/23,/24 (for a set of 9
prefixes).
Operators of DNS infrastructure, among others, are critically dependent
on the availability and use of these, and having the ability to trust
routing announcements of these prefixes is of first-order importance to
SIDR, IMNSHO.
In these cases, I believe the RIR would want to issue the ROA itself,
and do so in such a way as to only permit /24's to be announced, and
only by a specific ASN originator. I do not believe the RIR would want
to cede control of the larger blocks, only (at best) the individual /24's.
And, in particular, the RIR would not want the recipient ASN to be able
to "glue together" the contiguous pieces, and certainly not to be able
to assign the glued bits to some third party, especially for money.
If it were technically feasible for a large chunk of "critical
infrastructure" space to be (a) aggregated, and (b) sold on the black
market, it would be bad all-around, for operators of critical
infrastructure, for the RIR, and for the processes involved.
That is one use case. However unlikely the scenarios described, they are
of enough concern for me to document. That at a minimum, I would hope,
is sufficient for the WG to give consideration to the security
considerations involved, and to view the minLength issue from that
perspective.
>
> 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).
What about BGP MPLS VPNs? If an ISP gives a chunk of space to a customer
to use on the customer's VPN, and wants to run BGP to the customer for
PE-CE routing, and wants to ensure that the customer only announces
prefixes it is supposed to, and to do the filtering per site, the ISP
would ideally want to issue an ROA, with a longer minLength than the
block itself, but not announce the more-specific to the world. The ISP
would not want to have the customer announce any other prefixes. The ISP
would also want to enforce BCP 38, and would want to filter *packets*
based on RPKI (sidr). How else, other than ROA(s) is this possible?
And what if the customer is so big, that they are the only recipient of
an ROA from a large CIDR block? (Hint - think about large global
organizations like IATA, or various DOD departments).
>
> 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.
Not to be too pedantic, but:
The IETF policy is that the mailing list is where things get decided.
Meetings are for useful discussions, and for getting "the sense of the
room".
However, the absence of voices of concern, at a meeting, is not
sufficient reason to discount discussion on technical issues and merits,
on the mailing list.
There are *definitely* cases where advertising the aggregate prefix can
and will do harm.
Consider Bill Manning's /16 for ep.net (exchange point allocations).
Each of those is used as a /24 (or /23 or /22 for big exchanges).
Announcing the aggregate, or any portion thereof, would likely cause
harm, and at a minimum facilitate wide-scale abuse, like pointing
default at peers on an exchange.
It's one example, but far from the only example.
I'd suggest that however unlikely, the presence of a single extra field,
may save someone's bacon somewhere down the road.
I wouldn't want to be counted among those opposing its inclusion, if not
having it caused someone a real operational problem, just because we
couldn't come up with a big enough example at the time.
I'd rather have it included and never get used, than exclude it and
cause a headache for someone.
It's analogous to free speech. I may disagree vehemently with you, but I
will always fight for your ability to express those insipid comments :-)
Brian
>
> - 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
