Re: [sidr] allocation consistency

[Stephen Kent <[e-mail]>]

Brian,

I've consolidated my reply to your 3 messages.

First, the "live" transfer case _is_ the one that motivated the 
discussion of certificates with overlapping allocations and validity 
intervals. Your messages suggests that you believe this to be a corner 
case and that doesn't warrant allowing overlapping allocation 
certificates. The operators with whom this was discussed during the 
design phase (e.g., Randy Bush, Chris Morrow, and Warren Kumari) feel it 
is a critical case to support. In response to your messages I asked them 
about this and they not have changed their minds on this topic, i.e., 
they still see it as a critical capability to support.

That still leaves open the question of how long the certificates in 
question should overlap in validity. I polled these operators and there 
was a sense that it might be as short as a 17 days, but the overlap 
might last much, much longer. It was noted that, ultimately the ISPs 
engaging in the transfer will decide how long the overlap will be. So, 
it's not clear that it makes sense to posit a max overlap interval in RFCs.


Your third message went into a lot of details about time sync by ISPs. 
The bulk of this discussion was not germane to the issue that motivated 
the discussion, but maybe I posed the question poorly. The fact that 
Tier 1 ISPs usually have access to very accurate time sources is 
somewhat relevant, but not probative. The issue is whether ISPs manage 
to coordinate procedures across AS boundaries in a fashion consistent 
with precise timekeeping.My operator cadre advised me that, in their 
experience, smaller ISPs often do not. (Also, the discussion of line 
synch between routers on specific links is largely irrelevant to the 
RPKI synch discussion.)

When you alluded to time sync in PKIs, I had to chuckle.I have seen a 
lot of very sloppy PKI management when it comes to time sync, e.g., 
failure to issue certificates with overlapping validity intervals, 
failure to issue CRLs at the next update time, etc. I don't expect ISPs 
to be a lot better at this than folks who claim to be in the PKI 
business, which is why some of the RPKI documents suggest that RPs be 
tolerant of stale CRLs, etc.


On the positive side, we do agree that when the transfer does not 
involve addresses that are in use by subscribers/customers, there is no 
need for the certificates associated with the transfer to have 
overlapping allocations in certificates that are valid simultaneously.


With respect to punching holes in allocations when "non-live" transfers 
take place, I understand your concern. Unless the transferred addresses 
are at the edges of an allocation, they will create holes in the address 
ranges expressed in certificates. In turn, this will preclude secure 
origin advertisements for encompassing prefixes, as the ROAs will not 
match the advertisement. (Such an advertisement would not be "invalid" 
since there is no competing advertisement for the encompassing prefix 
that is valid under the RPKI. The status of the advertisement would be 
"unknown" which is likely to be a common status for some time as the 
RPKI is incrementally deployed.)


Deployment of the RPKI has the potential to reduce a lot of the 
de-aggregation that currently arises as ISPs try to counter prefix 
hijacking. Sandy Murphy recently suggested that table size increases 
attributed to transfers that punch holes in allocations also might be 
offset by ISPs revising the prefixes they advertise, as a result of 
figuring out how to specify ROAs. In any case, it is not clear that 
transfers that punch holes in allocations will have a substantial net 
impact on routing table size, given other factors that affect table size.


I note that there is a possible security concern if the ISP that 
transfers a prefix (and creates the hole in its allocation) continues to 
advertise the encompassing prefix. If the more specific prefix (that was 
transferred) becomes unavailable at some ASes, then traffic could flow 
to the encompassing prefix, if it is still being advertised. I've been 
told that this is not an uncommon occurrence, today, but it's not a 
great security outcome. If we had to allow advertising the encompassing 
prefix under the RPKI, your suggestion would require a number of changes:

-re-engineer 3779 to allow negative statements about address ranges

-define a new path validation algorithm to accommodate the redefined 
3779 extension

-change the ROA specification to accommodate the new 3779 extension

-change the origin validation specification to accommodate the new ROA 
specification and 3779 extension

Since there are some adverse security implications associated with the 
strategy you propose, it's hard to support the changes that would have 
to be made.There might be another way to address this issue (which Sandy 
mentioned), that would require fewer changes. We could retain the 3779 
syntax and the path validation algorithm, and create a new signed object 
to deal with the specific case created by holes. We could call the new 
object a joint ROA (JROA). The JROA could represent (joint) 
authorization to advertise a prefix, when no single entity holds all of 
the address space in question. A set of resource holders could sign a 
JROA, authorizing an AS to advertise to aggregated prefix. This would 
not require changes to all of the specs listed above; it would require a 
new signed object specification, and a revised origin validation 
specification, to accommodate both ROAs and JROAs. That said, I don't 
advocate the added complexity incurred by this strategy either.


Steve