[Docs] [txt|pdf|xml] [Tracker] [Email] [Nits]

Versions: 00 draft-rir-rpki-allres-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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/