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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
