RPKI Multiple "All Resources" Trust Anchors Applicability Statement
draft-rir-rpki-allres-ta-app-statement-00

Abstract

This document provides an applicability statement for the use of multiple, overclaiming 'all resources' (0/0) RPKI root certificates operated by the Regional Internet Registry community to help mitigate the risk of massive downstream invalidation in the case of transient registry inconsistencies.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 22, 2016.

Copyright Notice

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Requirements Language
• 2. Introduction
• 3. Applicability to reduce overclaiming possibilities
• 4. Normative References
• Authors' Addresses

1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

2. Introduction

RPKI is a hierarchical cryptologic system that uses certificates to match and validate holdership of IP addresses as it moves down the allocation change from IANA to a RIR to ISPs and ending up at end users who uses the address block. Since these allocations can be cryptographically validated, one could then tie assertions made by the holder of that IP address space. As an improvement of this system, RPKI was improved to add origin routing announcements via ROAs to this system. These ROAs then can be independently validated via cryptologic means by third parties to assure themselves that the origin of the announcement can be checked via what is in the actual routing system.

Since this system is envisioned to be used by ISPs to determine their routing decisions, there is a goal to be 100% correct 100% of the time. This goal could be achieved if it was to be contained in a static environment where there is little to no movement of holdership changes from one organization to another for IP addresses. Unfortunately, this state can not be achieved as there is now movement of IP addresses from organization to organization based on IPv4 runout.

Unfortunately, this state is infeasible in a model where separate entities are operating independently, yet rely critically on each others' perfect synchronisation at all times.

Because the current validation mechanism is all-or-nothing, any inconsistency at all at a high apex CA invalidates a large number of additional INRs. The higher the apex, and the larger the total set of INRs maintained by the CA, the greater the impact of even a small inconsistency.

As resources change at high apex CAs for a variety of reasons, the likelihood of a small inconsistency is non-zero, and the likelihood of a transitional inconsistency is moderate. Due to the distributed nature of the RPKI repository mechanism, even if all CAs were able to operate in perfect synchronicity, there is a reasonable likelihood that a given client may witness a temporarily inconsistent state of the system as a whole. A risk of wide-spread invalidity therefore exists as a very high impact and moderate likelihood event.

This brittleness in the RPKI validation rules has been identified and presented by the current RPKI TA operators to the IETF. A solution has also been proposed (insert ref to validation reconsidered), a solution that would allow for accidental over-claiming only to invalidate the resource that is incorrectly listed and allow the remaining to continue to be valid. This draft has had little forward progress in the IETF to date.

3. Applicability to reduce overclaiming possibilities

The consequences to a RIR over-claiming are grave given that every ISP within their certificate would be invalidated. If routing was to be reliant on RPKI at this point, all routes by those ISPs by the affected RIR certificate would no longer work.

To mitigate risk and alleviate this threat, each RIR will move from a Trust Anchor that reflects their current holdings to one that reflects all holdings (e.g. 0/0) so that over-claiming can not occur at a RIR level when dealing with transfers from one RIR to another. RPKI validators will not see the five Trust anchors from the RIRs as over-claiming and validation can proceed normally.

For those who want to audit the RIRs to ensure that RIRs are not allocating the same IP addresses in separate regions, they can audit the RIRs by matching the inventories of each RIR (**extended stats reference here) that is provided on a daily basis to the certificates issued by the RIRs within RPKI. Note that there will be a minor change from time to time to account for movements from IP address holdings that is in flight from one RIR to another.

4. Normative References

Authors' Addresses