It is weird that we even need to state here that we the five RIRs are not going to break things intentionally, but, yeah, LACNIC will not break things intentionally either.
Engineering for resiliency is as much a necessity as engineering for security. If the damage caused by the failures of the solution itself becomes worse than the damage caused by the problem, well, no one is going to deploy the solution. regards, -Carlos On Fri, Jul 25, 2014 at 1:19 PM, Tim Bruijnzeels <t...@ripe.net> wrote: > Hi, > > On Jul 25, 2014, at 9:09 AM, Byron Ellacott <b...@apnic.net> wrote: > > Hi, > > From: Stephen Kent <k...@bbn.com> > Date: Thursday, 24 July 2014 5:20 pm > To: Tim Bruijnzeels <t...@ripe.net> > Cc: "sidr@ietf.org" <sidr@ietf.org> > Subject: Re: [sidr] I-D Action: > draft-ietf-sidr-rpki-validation-reconsidered-00.txt > > Tim, > > I think I was not clear in requesting clarification for your tests. I > didn't mean to > ask what your RP code does. I was asking what your CA code does to detect > and reject > over-claiming, and what it will do under relaxed validation rules. I ask > because it > may be harder to perform such checks when there is an explicit intent to > issue a CA cert > that contains INRs not present in the parent cert. > > > I can't speak for RIPE, but at APNIC when a child requests a certificate > for us, we intersect it with our registry data, and our own CA certificate. > > > Same here. > > In addition: we include all resources explicitly in our certificate sign > requests from our *online* CA to the offline TA that we manage. This TA > will re-issue the TA certificate itself if needed, to include all requested > resources. I need to double check our code but I am pretty certain that our > online CA also shrinks its own understanding of which resources it has as > soon as it issues a request - i.e. it does not wait to receive the shrunk > certificate before we stop issuing these resources to child certificates, > but we *do* wait until we received the certificate before we issue from > *new* resources. Any modifications to the TA certificate and online > certificates are printed to the console and the operator needs to confirm > before the certificate is cut. We require 3 out of 10 senior RIPE NCC staff > to agree to the transaction (they have a smart card and need to enter their > passphrase). > > What we cannot do is confirm that our own parent hasn't in the meantime > published a new certificate for us with some resource removed: we can only > detect that after it has happened, and it would be preferable that > detection leads to correction without an intermediate step of total > invalidation of a region. > > > We will not intentionally break things obviously. And so-far our track > record has been flawless on this. > > But there are various reasons why, despite our best efforts, our online CA > may still be out of sync. A bug can be introduced in our code, or there > could be problem in publication and yesterday's TA certificate is not > updated but the CA certificate is, and if we would receive a certificate > from an upstream that is not managed by us then we have no assurance. And > as Byron points out we can only find this out after the fact. We do > regularly validate our repository, we don't actively monitor the exact > resources on our certificate, but we do monitor for sudden drops in valid > objects. By that time damage has been done though. > > The same problems apply on a smaller scale to any of our members that run > a non-hosted CA. We currently don't support this yet in our production > environment, but it's coming. > > As I said before I think that invalidating *ALL* resources in this case is > disproportionate. I would be much more comfortable with minimising the > impact. And still monitor for any overclaiming-warnings, and still deal > with them ASAP. > > > In a perfect world, of course, no process would ever lead to a parent > shrinking their child's certificate without adequate communication and > preparation, but if we were in a perfect world, a large part of the use > case for SIDR would be gone, because no router operator would ever make an > erroneous BGP announcement. > > > +1 > > Tim > > > Byron > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > > -- -- ========================= Carlos M. Martinez-Cagnazzo h <http://cagnazzo.name>ttp://cagnazzo.me =========================
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
