I see your point, although it seems to me that the underlying problem might be more general than RPKI. The RIRs have also been operating business CAs for some time and I dare say they (we?) are up to the task of correctly managing cryptographic material
This does not mean breaches can´t occur, but rather that I believe they will be handled appropriately. That said, I believe documenting best practices is always a good idea. Do you think a new, different document is needed or that practices you want documented can be included in the CPS documents ? regards Carlos On Sun, Apr 3, 2011 at 9:17 PM, George, Wes E [NTK] <[email protected]> wrote: > I had a conversation with a couple of folks while at IETF that they thought I > should bring to the list for discussion. > > While we have an operational considerations document that covers origin > validation, it focuses mainly on policy and implementation > details of the validation machinery. We don't have anything that covers the > back-end of implementing a proper RPKI (from the cache > upward, rather than downward towards the router). > > Put another way, a lot of the folks involved in this protocol's design and > implementation are already intimately familiar with how > to manage things like ROAs to ensure that the underlying trust of the system > is not compromised. > I (and I assume other operators and likely the RIR staff) on the other hand. > not so much. Keep in mind that while we might consult > with our security folks on implementation details, that doesn't necessarily > mean that we'll do it right, since the level of > knowledge of the considerations here by the security folks may be limited. > Since ultimately origin validation's trust level is only > as good as the trust level associated with management of the validation keys, > I'm quite certain that additional rigor is necessary > in both the way that RIRs manage their POC records and authority to request, > invalidate, and reissue keys, as well as how ISPs do > the same for their downstream customers, especially since these are likely to > be managed through some form of automated back-office > system or customer portal. > > So I think that there is a need for a document that covers things like > identity and authority management, minimum levels of security > for key management, etc. > > Basically, if you had to explain to someone how to ensure that the ROAs that > are being delegated are: > 1) Delegated to the right person (right company, and person authorized > to make the changes within the company) > 2) Have a reasonable assumption that they will not be compromised once > delegated (proper key management) > 3) Methods for managing breaches, either due to failures in #1 > (disgruntled/former employee) or failures in #2 > How would you do it? Are there existing documents we can use as a baseline > and just fill in some of the specific details in the form > of a few different use cases, such as RIR to primary resource holder, > resource holder to delegate, etc? > An example to illustrate the reason for this - we have a subsidiary that we > bought that had their own address space. Somewhere along > the way, a former employee changed the whois and POC info in ARIN's database > to point to a new company, and said new company started > threatening to announce "their" address space that we were squatting on. > Obviously a quick contact to ARIN sorted this out, but > under less amiable circumstances, they could have invalidated our existing > ROA, issued their own, and created a serious problem for > us. While the solution is primarily that companies need to stay on top of > their POC records now, we need to make that clear as a > part of the documentation that we're providing on how to implement this > system and we need to try to give ideas on how best to > improve the level of trust. > > I'm happy to help play the part of RPKI n00b to ensure that a draft written > to cover this answers the right questions, but for the > same reason, I cannot help much with actually writing it, and am hoping that > there are folks interested in picking up this work. > > Thanks, > Wes George > > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr > > -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
