Dear Terry, all, Terry thank you for very much for reviewing.
I have two comments to your remaining concerns: > On 22 Jan 2018, at 02:27, Terry Manderson <terry.mander...@icann.org> wrote: > > Terry Manderson has entered the following ballot position for > draft-ietf-sidr-rpki-validation-reconsidered-10: No Objection > > 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/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for adding text into the document that placates my DISCUSS concerns > until others look to implement (and use in anger) this in the wild. > > I'm going to leave a part of my original thoughts on this document here for > future reflection: "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?” As I mentioned in this message: https://www.ietf.org/mail-archive/web/sidr/current/msg08596.html The RIPE NCC RPKI Validator has been using the new algorithm since version 2.17, released 3 July 2014. With one difference: in the RIPE NCC validator the decision to accept the intersection of validated resources, rather than reject, is a global configuration setting, rather than a per CA certificate decision. Changing this code is trivial though once we know which OID to use to drive the if statement. In terms of analysis: we have done interop testing between our validator (with the setting turned on) and the other validators and we find no differences that can be traced back to this. First of all because we have not yet caught any persistent overclaims in the wild, and secondly the algorithm we use where we track “Validated Resource Sets” is not semantically different in cases where no actual overclaims are found. The experiment we have NOT done is to create an actual in-the-wild over-claiming parent certificate and compare validation notes. This is not trivial for us because our CA implementation has built-in checks to prevent this kind of thing. Thanks to your insisting, the document now describes better what will happen in this case. But in a nutshell: I am happy to invest time in doing this experiment when we get to the point of discussing the deployment of validation-reconsidered. > And further add that the RPKI is starting to appear, in my eyes, exceptionally > fragile when faced with operational realities and also quasi-political issues > surrounding trust anchors. Without doubt the underpinnings of routing security > and integrity is hard, no surprise that this effort (as one of many that has > preceded it) also struggles. This document addresses potential operational issues, that we haven’t actually seen in the wild. Similarly we invested time and effort to develop the delta protocol (RRDP) to prevent big issues with rsync scaling (before they actually become problematic). And recently I have been asking for the adoption of a working group item (Signed TALs) to address the issue of TA key rolls - before they become problematic. So, in my opinion, the RPKI standards did not get everything right from the start, but we can (and do) fix things. In that regard I am also very happy to see that the SIDROPS WG has an explicit mandate to look at the operational side of the RPKI and apply lessons learned. Kind regards, Tim _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
