Internet2 Network Security SIG

I was fortunate to be able to attend the ARIN 43 Public Policy and Members Meeting in Barbados last week. The hottest topic was ARIN's legal agreement requirement (Relying Party Agreement) for users of its RPKI origin validation database.

This subject can be a bit complex. Let me first say that creating ROAs (the records created using ARIN's online system to associate a network with its origin AS) only require that the organization have signed the standard Registry Service Agreement (RSA). So there SHOULD BE NO BARRIER to creating ROAs. The Relying Party Agreement is ONLY required to download and use ARIN's database of ROAs.

If you haven't created ROAs for your network prefixes, and you'd like some assistance, send me an e-mail and I can walk you through the process.

To operate an RPKI validator (i.e., software that uses ROA databases maintained by the RIRs such as ARIN, RIPE, APNIC, etc., to verify the routes you're receiving contain a valid origin AS) with ARIN's ROA database, your organization must agree to the terms of ARIN's Relying Part Agreement (RPA found here: https://www.arin.net/resources/manage/rpki/rpa.pdf). The RPA contains language that gives lawyers pause, and for good reason.

Other RIRs have no offending RPA, and using their ROA databases to validate routes is less of a hurdle. Further, popular open source validator software includes links to the other ROA databases by default, so to include ARIN's requires additional configuration. The end result is that RPKI deployment (both the creation of ROAs and the use of validators) has been much stronger outside of ARIN's territory.

Some have said that having IP network registered with ARIN makes the network more likely to be the target of hijack attack since far fewer backbone networks are using ARIN's ROA database. There's even a policy proposal to permit IPv6 network resources holders to transfer their IPv6 networks to other RIRs such as RIPE (IPv4 prefixes can be transferred under the current policy)

ARIN is acutely aware of the pain being caused by the RPA. During the ARIN 43 meeting their CEO John Curran described in detail why it's felt that the RPA's language is required to protect ARIN, as well as options they are investigating to reduce the barrier to using the ROA information. They're investigating, among other approaches, mitigating the risk via insurance, establishing a sperate organization for the purpose of publishing the ROA data, tightening the existing RSA, etc.

My advice: create ROAs for your networks now, wait and see how ARIN addresses the issues with the RPA.

A good legal analysis of the legal barriers created by ARIN’s RPA can be found here:

https://scholarship.law.upenn.edu/faculty_scholarship/2035/?utm_source=scholarship.law.upenn.edu%2Ffaculty_scholarship%2F2035&utm_medium=PDF&utm_campaign=PDFCoverPages

Steve wallace

Attachment: smime.p7s
Description: S/MIME cryptographic signature