Hi, As you may have noticed my name was added to the author list, so it will come as no surprise that I read this document and agree with its content.
I believe that all RIRs share both operational concerns outlined in section 3: (1) Operational fragility, and (2) resource transfers. One thing to note about the second case is that we don't have this problem right now because we only offer a hosted service where our members cannot create delegated certificates. However, this will change when we enable the provisioning (up-down) system and support non-hosted CAs that may delegate further. Section 4 describes, in very general terms, two alternative approaches to counter these concerns. The first approach has my strong preference. I believe it's simple to explain and implement, effective against both concerns, and I do not see any security issues with it. The change boils down to this: when doing top-down validation, just accept the *intersection* of resources listed on a certificate, and its parent. The idea of keeping track of resources explicitly is not new: we already have this when using 'inherit'. We have running code in our validator for this. It took us a day to implement this. The feature is off by default of course, but it's enabled without problems on a public instance that we're running: http://localcert.ripe.net:8088/ The second approach in section 4 was presented at the last IETF (draft-barnes-sidr-tao). Essentially it allows for transfer signalling through an up-down like protocol. Technically this approach can help to deal with transfer issues (2). The 'happy case' scenarios assume though that all involved parties play nice - and keep playing nice. There are many moving parts here, and it's not clear to me what happens when one party walks away (e.g. goes offline permanently). Additionally the timing of certificate shrinking in case of a cancel is not clear to me and introduces complexity: live transfer or not?, who signals the transfer?, when is it canceled, before or after shrinking and/or swinging? Can a cancel be canceled? But, more importantly, this approach offers no protection against the operational fragility case (1). Furthermore it adds a lot of complexity and this has huge costs in development (many months) and maintenance and introduces more operational fragility and potential interop issues between implementations. Tim On Jul 2, 2014, at 3:27 AM, [email protected] wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Secure Inter-Domain Routing Working Group of > the IETF. > > Title : RPKI Validation Reconsidered > Authors : Geoff Huston > George Michaelson > Carlos M. Martinez > Tim Bruijnzeels > Andrew Lee Newton > Alain Aina > Filename : draft-ietf-sidr-rpki-validation-reconsidered-00.txt > Pages : 10 > Date : 2014-07-01 > > Abstract: > This document reviews the certificate validation procedure specified > in RFC6487 and highlights aspects of potentially acute operational > fragility in the management of certificates in the RPKI in response > to the movement of resources across registries, and the associated > actions of Certification Authorities to maintain continuity of > validation of certification of resources during this movement. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sidr-rpki-validation-reconsidered-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
