I'm not sure which operators you talked to, but I think you may have conflated two different issues that are both relevant, but which have different requirements (or semantics, if you will).
One issue is, the transfer of *live* networks. I'm not sure there is a strong requirement to support this per se, and/or whether limited support for this (with limited overlapping validity periods) would suffice. If you recall, BGP is stateful, so if the origin ASN of the INR does not change, the RP cache latency vs "refresh" BGPSEC instances, would be the primary risk. (Network events are a secondary risk.) However, IMHO, live networks might change their AS path, but have no reason to change their location in the INR allocation tree. On the other hand, non-live transfers are the norm, and do need to be accounted for. And this is where, IMHO, the current RPKI design is GROSSLY flawed. Sorry to be the bearer of bad news. Here is the typical INR policy on transfered or returned blocks: - Put the returned/transfered block in the "free" pool. - If previously used, put a "time-out" on the block to prevent it being allocated for some non-trivial period. (e.g. 3-6 WEEKS) - Once time-out expires (if there is any timeout), make available for allocation - Allocate per normal allocation mechanisms/policies. So, not only is there no live transfer, there is an explicit gap in the period of usage. This means that any old caches can be purged of the INR references (via CA or EE+ROA). And subsequent to that, an INR allocation of previously used space, is no different from INR allocation from a never-before-used space. While the details (e.g. time frames) belong in an ops document, the exclusivity requirement does need to be handled within the RPKI & RP architectures. Currently it is not. Brian On Wed, Sep 12, 2012 at 1:24 PM, Stephen Kent <[email protected]> wrote: > Brian, > > Sorry I didn't reply sooner. > > I found it very difficult to follow the details of your example, but I > think there is a higher > level consideration that makes moot a detailed analysis of optimization > the you suggest. > > In the early days of RPKI design I raised the same question that you did > re allocation uniqueness, > and suggested that we include RP checks for overlapping allocations in RP > software. I was told (by operators) that the old INR holder and the new INR > holder would each need to have certs (and ROas) that are valid, and that > encompass the INRs being moved, and that persist for some time. That is a > fundamental reason that the RPKI does not specify that the allocations are > "unique." The term "unique" used to appear in the text of several of the > docs, but was removed to accommodate INR transfers. > > I think the primary concern is that one cannot be confident how quickly > all RPs will acquire all RPKI data. > Thus it seems prudent to allow for the old and new INR holders to have > certs that contain the INRs being transferred, for these certs overlap in > validity, and for both certs to be available via the repository system at > the same time, for some overlap period. This enables old and new ROAs, > which may point to the same ASN, to exist, avoiding the need for a flag day. > > Steve > >
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
