On Wed, Sep 12, 2012 at 7:16 PM, Robert Loomans <[email protected]> wrote:
> On 13/09/2012, at 03:24, 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. > > There are related scenarios regarding operational changes even without > transfers. > > Currently APNIC, for example, only provides a hosted environment for RPKI > for our members. They have a web interface from which they can ask for ROAs > to be created and published, and we run all of the machinery for them and > publish the results in our repositories. > I'm not familiar with what APNIC does currently. Is it "repository" or "repositories" (plural)? Do members have their own (hosted) repositories and CAs, or is there just one CA and a flat repository with ROAs but no CAs? > > In the future we may allow our members to run their own RPKI installation, > connecting to our RPKI service using the provisioning protocol. > > I suspect they would prefer to be able to run their new RPKI installation > and the hosted service simultaneously for some time, allowing relying > parties to pick up the new objects, before switching off the hosted service. > I suspect the fundamental problem is how the RPKI was "engineered" from a specification standpoint, where the "loosely coupled" aspect was inserted (rather than intrinsic to all possible RPKI designs), probably as a consequence of not specifying that the notion of "time" had to be accurate at an RP to within some specific delta of global GPS/UTC time. For instance, prepublishing objects with validity start/end times, would in theory be sufficient to trigger RPs to pick up objects before the start time, and specifying (in the protocol docs) an overlap window maximum, would achieve adequate support for transitions (of any particular purpose and/or duration, modulo "rules" for relevant use cases). And in particular, the transition use-case sequence would be: "pre-publish" -> (long time) -> "enable new" -> (short window controlled by end/start datetime in objects) -> "disable old" -> (long time) -> "unpublish old" > > Similarly, when someone wants to wholesale replace their RPKI > infrastructure with a new implementation they may choose to run old and new > side-by-side. > > Architecturally limiting duplicates to dual-CAs at the same publication point, would support this without weakening the global RPKI security model. All the other ways duplicates are supported, implicitly, weakens the security model. Brian > Rob > > > -- > Robert Loomans email: [email protected] > Senior Software Engineer, APNIC sip: [email protected] > http://www.apnic.net/ phone: +61 7 3858 3100 > >
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
