Internet DRAFT - draft-nro-rpki-ta-app-statement
draft-nro-rpki-ta-app-statement
Internet Engineering Task Force A. Newton, Ed.
Internet-Draft ARIN
Intended status: Informational C. Martinez-Cagnazzo, Ed.
Expires: September 22, 2016 LACNIC
D. Shaw
AfriNIC
T. Bruijnzeels
RIPE NCC
B. Ellacott
APNIC
March 21, 2016
RPKI Multiple "All Resources" Trust Anchors Applicability Statement
draft-nro-rpki-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
Newton, et al. Expires September 22, 2016 [Page 1]
Internet-Draft RPKI 0/0 TA Applicability Statement March 2016
(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
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Applicability to reduce overclaiming possibilities . . . . . 3
4. Normative References . . . . . . . . . . . . . . . . . . . . 4
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4
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.
Newton, et al. Expires September 22, 2016 [Page 2]
Internet-Draft RPKI 0/0 TA Applicability Statement March 2016
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.
Newton, et al. Expires September 22, 2016 [Page 3]
Internet-Draft RPKI 0/0 TA Applicability Statement March 2016
4. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
Authors' Addresses
Andrew Newton (editor)
ARIN
Chantilly VA
United States
Email: andy@arin.net
Carlos Martinez-Cagnazzo (editor)
LACNIC
Montevideo
Uruguay
Email: carlos@lacnic.net
Daniel Shaw
AfriNIC
Cybercity Ebene
Republic of Mauritius
Email: daniel@afrinic.net
Tim Bruijnzeels
RIPE NCC
Amsterdam
Netherlands
Email: tim@ripe.net
Byron Ellacott
APNIC
Brisbane
Australia
Email: bje@apnic.net
Newton, et al. Expires September 22, 2016 [Page 4]
