Hi, My apologies for the delay - I am just back from a late summer holiday.
> On 31 Aug 2017, at 05:29, Terry Manderson <terry.mander...@icann.org> wrote: > > Terry Manderson has entered the following ballot position for > draft-ietf-sidr-rpki-validation-reconsidered-08: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for considering the stability of the internet's routing system > during > administrative changes to resources. > > One thing isn't quite clear to me, so I'm balloting this as a DISCUSS with the > plan that a small amount discussion will resolve it. > > With the definition of the new validation OID (a idea that I like BTW), at any > stage of the certificate issuance can the validation OID be switched? That is > a > TA has a particular OID and down the tree an issued certificate has a > different > OID? If that can't happen (and please make that clear in the document) is > there > plan to migrate the set of all issued certificates to the new OID? and > deprecate the old OID? As mentioned in the response to Ben Campbell’s discuss, this is theoretically possible. It was agreed, in my understanding, that deployment would be discussed in sidrops separate from this document, and the choice whether a mix OID deployment is acceptable should be addressed in that discussion. > > Logically speaking a trust anchor cannot be thought of as over-claiming. (eg > you trust where the self signed cert came from, and its contents) However the > new validation constructs suggest that a TA can over-claim, but it seems like > there won't be any warning (as the example in S4.3) to highlight this > possible > eventuality when (in the model where all RIRs issue a TA) a resource is > transferred from one RIR to another for the clients use. Is that > interpretation > correct? OR does this new model espouse the belief that all RIRs each issue a > TA that covers 0/0 and ::/0 in perpetuity? In that construct does this mean > that RFC6491 should be updated or made historic? No, the first bullet point under item #7 in section 4.2.2.4 covers TA certificate. If ‘x=1’, this is the first certificate in the tree and its resources are accepted as they appear. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I get the sense that many of the ramifications for this validation change are > yet to be discovered. It worries me that from the shepherd writeup "The > existing CA/RP code implementations will support this once published." What > experiments have been done to identify any gaps and assumptions? The RIPE NCC RPKI Validator has supported this algorithm since version 2.17 - 3 July 2014 - as a global configuration setting. In our case the code changes for this were trivial - in supporting the ‘inherit’ case we were already keeping track of resources per certificate in the tree - adding logic to accept the intersection of resources and warn for over-claims instead of reject was therefore very simple. Changing the behaviour to look at the OID of the certificate under inspection instead will be trivial. The difficulty is in accepting the new OIDs in the first place - again trivial from the code perspective but from a deployment perspective demands that users upgrade their software after we release a version with support for it. > > > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
