[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
Secure Inter-Domain Routing                                       X. Lee
Internet-Draft                                                    X. Liu
Intended status: Informational                                    Z. Yan
Expires: January 9, 2017                                         G. Geng
                                                                   Y. Fu
                                                                   CNNIC
                                                            July 8, 2016


    RPKI Deployment Considerations: Problem Analysis and Alternative
                               Solutions
                   draft-lee-sidr-rpki-deployment-02

Abstract

   With the global deployment of RPKI, a lot of concerns about technical
   problems have been and will be raised.  In this draft, we collect and
   analyze the problems that have appeared or that seem likely to appear
   during the process of RPKI deployment, and suggest some solutions to
   address or mitigate these problems.

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 January 9, 2017.

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



Lee, et al.              Expires January 9, 2017                [Page 1]


Internet-Draft      draft-lee-sidr-pki-deployment-02           July 2016


   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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  RPKI Architecture . . . . . . . . . . . . . . . . . . . .   2
     1.2.  Status of RPKI Deployment . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Considerations of RPKI Deployment . . . . . . . . . . . . . .   4
     3.1.  More than One TA  . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Problems of CAs . . . . . . . . . . . . . . . . . . . . .   5
       3.2.1.  Operational Errors  . . . . . . . . . . . . . . . . .   5
       3.2.2.  Unilateral Resource Revocation  . . . . . . . . . . .   5
     3.3.  Mirror World Attacks  . . . . . . . . . . . . . . . . . .   5
     3.4.  Data Synchronization  . . . . . . . . . . . . . . . . . .   6
     3.5.  Problems of Staged and Incomplete Deployment  . . . . . .   6
     3.6.  Low Validation Coverage . . . . . . . . . . . . . . . . .   7
   4.  Alternative Solutions to RPKI Deployment Problems . . . . . .   8
     4.1.  Solutions to Multiple TAs . . . . . . . . . . . . . . . .   8
     4.2.  Solutions to Misbehaving CAs  . . . . . . . . . . . . . .   9
     4.3.  Solutions to Data Synchronization . . . . . . . . . . . .   9
     4.4.  Solutions to Incomplete Deployment and Low Validation
           Coverage  . . . . . . . . . . . . . . . . . . . . . . . .  10
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

1.1.  RPKI Architecture

   In RPKI, CAs (Certification Authorities) are organized in a
   hierarchical structure which is aligned to the existing INR (Internet
   Number Resources) allocation hierarchy (including IP prefixes and AS
   numbers).  Each INR allocation requires corresponding resource
   certificates to attest to it, for security.  In RPKI, two types of
   resource certificates [RFC6480] are generated as adjuncts to this
   allocation process: CA certificates and EE (End-entity) certificates.
   CA certificates attest to the INR holdings; EE certificates are
   primarily used for ROAs (Route Origin Authorizations) [RFC6482] and
   Router Certificates.  ROAs are used to bind IP prefixes to the ASes



Lee, et al.              Expires January 9, 2017                [Page 2]


Internet-Draft      draft-lee-sidr-pki-deployment-02           July 2016


   that is permitted to originate routes for these IP prefixes.
   Manifests [RFC6486] are also validated using EE certificates.
   Manifests are used to ensure the integrity of the RPKI repository
   system.

   The process of using the RPKI to verify the origin of a route is as
   follows.

   1.  CAs, including IANA (Internet Assigned Numbers Authority), five
       RIRs (Regional Internet Registries), NIRs (National Internet
       Registries) and ISPs (Internet Service Providers), publish
       authoritative objects (including resource certificates, ROAs,
       Manifest and so on) into their repositories.

   2.  RPs (Relying Parties) all over the world collect (using rsync or
       RRDP protocol [I-D.ietf-sidr-delta-protocol]) and verify (using
       rcynic or RPSTIR) the RPKI objects from these repositories, and
       provide the results of verification to BGP border routers or
       other routing practices such as RPSL-based.

   3.  Finally, BGP border routers can make use of these results to
       verify the route origin information in the BGP update messages
       they receive.  This may be done by generating route filters from
       the validated RPKI data, or by using the RPKI-to-router protocol
       [RFC6810].

1.2.  Status of RPKI Deployment

   Each of the five RIRs has initiated the deployment of RPKI, and each
   now offers RPKI services to its members.  A number of countries
   (Ecuador, Japan, Bangladesh, etc.) have also started to test and
   deploy RPKI internally.  In order to promote the deployment of RPKI,
   ICANN (Internet Corporation for Assigned Names and Numbers), the five
   RIRs, many NIRs and companies have making continuous efforts to solve
   the existing problems and improve the corresponding policies and
   technical standards.

   However, RPKI is still in its early stages of global deployment.
   According to the data provided by RPKI Dashboard as of July 2016, the
   current routing table holds about 659,271 IP prefixes in total, and
   the RPKI validation state has been determined for 44983 IP prefixes,
   which means that only 6.82% of the prefixes in the routing table can
   be validated using the RPKI.  Table 1 details of the RPKI "adoption
   rate" (the percentage of members deployed RPKI) in each of the RIRs.







Lee, et al.              Expires January 9, 2017                [Page 3]


Internet-Draft      draft-lee-sidr-pki-deployment-02           July 2016


      +---------------+---------+-------+-------+--------+----------+
      | RIR           | AFRINIC | APNIC | ARIN  | LACNIC | RIPE NCC |
      +---------------+---------+-------+-------+--------+----------+
      | Adoption Rate | 0%      | 3.44% | 1.22% | 20.66% | 12.14%   |
      +---------------+---------+-------+-------+--------+----------+

                  Table 1.Adoption rate of RPKI in 5 RIRs

   As we can see from Table 1, LACNIC has the highest adoption rate,
   which is about 20.66%. While the adoption rates in ARIN and AFRINIC
   are much lower, which are only 1.22% and 0% respectively.

   RIPE NCC provides some statistics regarding the number of resource
   certificates and ROAs in each RIR.  From these statistics we find a
   good sign that the global deployment status of RPKI rises gradually,
   and with its further evolution, the global adoption rate of RPKI
   should achieve a faster growth.

2.  Terminology

   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 [RFC2119].

3.  Considerations of RPKI Deployment

   During the process of incremental deployment of RPKI, several
   technical problems have appeared and others may appear.  In this
   section, we attempt to collect and analyze the problems that seem
   most critical.

3.1.  More than One TA

   A TA (Trust Anchor) is an authoritative entity represented by a
   public key and its associated data [RFC5914].  The public key is used
   to verify digital signatures and the associated data describes the
   types of information and actions for which the TA is authoritative.
   There are multiple TAs in the RPKI architecture today, for example,
   the five RIRs are generally viewed as default TAs.

   With more than one TA, there is no technical mechanism to prevent two
   or more TAs from asserting control over the same set of INRs
   accidentally or maliciously, which means that certificates might be
   issued for allocations of the overlapping INRs.  This, in turn, may
   lead to inconsistent and conflicting assertions about to whom the
   specific INRs have been allocated.  This kind of problem obviously
   may cause resource conflicts on the Internet.




Lee, et al.              Expires January 9, 2017                [Page 4]


Internet-Draft      draft-lee-sidr-pki-deployment-02           July 2016


3.2.  Problems of CAs

3.2.1.  Operational Errors

   Operatioanl errors by CAs are inevitable and may cause significant
   impact on Internet routing.  Thus such errors by CAs in RPKI
   constitute a risk to widespread deployment.

   Operatioanl errors by CAs in the RPKI may lead to serious
   consequences similar to those caused by malicious attacks (black-hole
   routes, traffic interception, and denial-of-service attacks).  For
   example, an error in using a ROA (such as adding a new erroneous ROA
   or whacking an existing ROA) may cause all routes covered by the
   (original) ROA to become invalid (or to assume an "unknown" security
   status [RFC6483]).  Note that, if the old validating ROA still
   matches (not just covers) the announce prefix, the announcement will
   still be marked as valid.

3.2.2.  Unilateral Resource Revocation

   In the RPKI architecture, there is a risk that CAs have the power to
   unilaterally revoke the INRs that have been allocated to their
   descendants, e.g., by revoking corresponding CA certificates
   [RFC6480].

   This is a natural aspect of PKIs and it is a necessary capability for
   CAs as they manage re-allocation of resources within their domains.
   However, if revocation occurs accidentally, or because the CA has
   been compelled by authorities, the results can be significant.
   Specifically, all RPs will view the origin assertions by the CA (and
   its descendants) to be not found.  This may cause ISPs to
   depreference routes to the affected prefixes.

3.3.  Mirror World Attacks

   In mirror world attacks, a malicious CA presents one view of the RPKI
   repository (that it manages) to some RPs, and a different view to
   others.  (Because repository data may be cached by ISPs, it may not
   be possible for a malicious CA to provide erroneous results to a
   narrowly targeted set of RPs.)

   Since a CA in the RPKI controls everything in its own repository, it
   may be easy for a malicious CA to perform such a attack.  For
   example, a malicious CA presents the correct view of its repository
   to some RPs, but a forged view (e.g., the CA adds a specific,
   erroneous ROA) to the others.  When these deceived RPs offer their
   validation results to BGP routers, the routers may abandon the




Lee, et al.              Expires January 9, 2017                [Page 5]


Internet-Draft      draft-lee-sidr-pki-deployment-02           July 2016


   legitimate routes that are considered to be invalid according to the
   (erroneous) validation results they have received.

3.4.  Data Synchronization

   It is required in [RFC6480] that all repositories must be accessible
   via rsync protocol which is used by RPs to get the RPKI objects in
   the global distributed repositories.  However, the rsync protocol is
   considered to be controversial with respect to the following
   disadvantages:

   1.  Lack of standards and non-modular implementation: Although rsync
       is widely adopted in backup, restore, and file transfer, it has
       not been standardized by IETF.  And the rsync implementation is
       non-modular, making it difficult to use its source code.

   2.  Underlying overhead caused by repository updates during active
       data transmissions: During data transmissions between RPs and the
       repository, a new update to the repository may cause data
       inconsistency between them.  In order to rectify this
       inconsistency, extra overhead costs (such as performing the
       synchronization once more) are required.

   3.  This is being solved by the new RRDP protocol, now in deployment.

3.5.  Problems of Staged and Incomplete Deployment

   Since the global deployment of RPKI is an incremental and staged
   process, unexpected problems may appear during this process.  Let's
   take an example to explain why the incomplete deployment of RPKI may
   cause legitimate routes to be misclassified into invalid.  In Fig.1,
   we make the following assumptions:

   1.  CNNIC, ISP1 and ISP2 have deployed the RPKI, but ISP3 has not
       yet.  ISP1 and ISP2 received allocations form CNNIC, and ISP3
       received its allocation from ISP1.

   2.  CNNIC allocated IP prefix 218.241.104.0/22 to ISP1 and
       218.241.108.0/22 to ISP2.

   3.  Three ROAs (ROA1, ROA2, ROA3) are issued respectively by CNNIC,
       ISP1 and ISP2.









Lee, et al.              Expires January 9, 2017                [Page 6]


Internet-Draft      draft-lee-sidr-pki-deployment-02           July 2016


                            -------         --------------
                            |APNIC|         |  Resource  |
                            -------         |Certificates|
                               |            --------------
                               |            ..............
        .................   -------         .    ROA     .
        .    ROA1:      .   |     |         ..............
        .218.241.96.0/20.<--|CNNIC|
        .     AS1       .   |     |
        .................   -------
                            /    \
                           /      \
   ..................   ------   ------   ..................
   .     ROA2:      .   |    |   |    |   .     ROA3:      .
   .218.241.104.0/22.<--|ISP1|   |ISP2|-->.218.241.108.0/22.
   .      AS2       .   |    |   |    |   .      AS3       .
   ..................   ------   ------   ..................
                           |
                           |
                        ------
                        |    |
                        |ISP3|
                        |    |
                        ------


                Fig.1: An example of incomplete deployment

   Now ISP3 announces to be the origin of 218.241.106.0/23.  When other
   entities receive this announcement, they can validate it with ROAs
   information.  Since prefix 218.241.104.0/22 described in ROA2
   encompasses prefix 218.241.106.0/23 and no matching ROA describes
   218.241.106.0/23 could be found [RFC6483], the announcement for
   prefix 218.241.106.0/23 will be considered to be invalid.  This
   example illustrates why careful coordination is needed when (non-
   leaf) ISPs incrementally deploy the RPKI.  This example illustrates
   why careful coordination is needed when (non-leaf) ISPs incrementally
   deploy the RPKI.

   Therefore, if an ISP knows its customer is not creating a ROA, it is
   the ISP's responsibility to create that ROA, just as it is that ISP's
   responsibility to do 42 other things for their 'customer'.

3.6.  Low Validation Coverage

   The route origin validation coverage refers to the percentage of
   valid routes attested to by the RPKI. i.e., Coverage =




Lee, et al.              Expires January 9, 2017                [Page 7]


Internet-Draft      draft-lee-sidr-pki-deployment-02           July 2016


   number_of_valid_routes / (number_of_valid_routes +
   number_of_invalid_routes).

   As we can see from Table 2, the coverage of route origin validation
   in the five RIRs differs a lot.  LACNIC and RIPE NCC have the highest
   validation coverage and both of them are over 90%, while the coverage
   in APNIC is less than 70%. Many reasons may account for the low
   validation coverage, such as misconfigurations, low RPKI adoption
   rates, etc.

   +---------+-------+-------+---------+---------+----------+----------+
   | RIR     | Total | Valid | Invalid | Unknown | Accuracy | Adoption |
   |         |       |       |         |         |          | Rate     |
   +---------+-------+-------+---------+---------+----------+----------+
   | AFRI-   | 14948 | 242   | 5       | 14701   | 97.98%   | 1.65%    |
   | NIC     |       |       |         |         |          |          |
   | APNIC   | 15802 | 3332  | 1564    | 153124  | 68.06%   | 3.1%     |
   |         | 0     |       |         |         |          |          |
   | ARIN    | 21977 | 1911  | 337     | 217531  | 85.01%   | 1.02%    |
   |         | 9     |       |         |         |          |          |
   | LACNIC  | 76841 | 13379 | 736     | 62726   | 94.79%   | 18.37%   |
   | RIPE    | 15925 | 16771 | 1307    | 141178  | 92.77%   | 11.35%   |
   | NCC     | 6     |       |         |         |          |          |
   +---------+-------+-------+---------+---------+----------+----------+

           Table 2.  Route Origin Validation Accuracy in 5 RIRs

4.  Alternative Solutions to RPKI Deployment Problems

   In this section, we propose and analyze the alternative solutions and
   strategies to solve or mitigate the problems mentioned in Section 3.

4.1.  Solutions to Multiple TAs

   The RIRs say they are trying to continually evolve RPKI.  ICANN
   (IANA) and RIRs have developed a technical testbed with an RPKI GTA.
   It's assumed that there must be a single root trust anchor
   eventually.  With this single root trust anchor deployed, the risks
   of resource conflicts (at the level of RIR certificates) could be
   significantly reduced.

   However, this solution cedes more power to ICANN (IANA) and thus
   might exacerbate the risk of "Unilateral Resource Revocation" (power
   imbalance) mentioned in Section 3.2.2.







Lee, et al.              Expires January 9, 2017                [Page 8]


Internet-Draft      draft-lee-sidr-pki-deployment-02           July 2016


4.2.  Solutions to Misbehaving CAs

   S.  Kent et al. put forward a collection of mechanisms named
   "Suspenders".  "Suspenders" is designed to address the adverse
   effects on INR holders which were caused by CAs' accidental or
   deliberate misbehavior or attacks on CAs and repositories.  This
   mechanism imports two new objects: an INRD (Internet Number Resource
   Declaration) file and a LOCK object.  The INRD file is external to
   the RPKI repository, and it contains the most recent changes that
   were made by the INR holder.  The LOCK object is published in the INR
   holder's repository.  It contains a URL which points to the INRD
   file, and a public key used to verify the signature of INRD file.
   Whenever the RPs detect the inconsistencies between the actual
   changes and the INRD file, they can determine individually whether to
   accept these changes or not.  (This proposal is being revised to
   address operational concerns, but it is anticipated that a subsequent
   version of Suspenders will preserve the primary features noted
   above.)

4.3.  Solutions to Data Synchronization

   A number of alternative protocols have been presented to take the
   place of "rsync" protocol due to its shortcomings mentioned above.

   1) RRDP

   T.  Bruijnzeels et al. have proposed an alternative protocol (RRDP,
   RPKI Repository Delta Protocol) for RPs to keep their local caches in
   sync with the repository system [I-D.ietf-sidr-delta-protocol].  This
   new protocol is based on notification, snapshot and delta files.
   When RPs query a repository for updates, they will use delta files
   (and snapshot files as needed) to keep their local caches updated.
   Moreover, RRDP protocol can work with the existing rsync URIs.

   Compared with rsync protocol, RRDP is considered to be effective as a
   way to eliminate a number of consistency related issues, help to
   reduce the load on publication servers, and have improved
   scalability.

   RRDP is in current RIPE and DRL software.

   2) Improved Rsync Protocol

   CNNIC also proposed an improved rsync mechanism which transfers the
   work of checksums calculation to RPs in order to reduce the
   computation load on the rsync server side.  The mechanism also
   offered a NOTIFY method that send NOTIFY message to make some
   important RPs to actively fetch the updated RPKI objects in time.



Lee, et al.              Expires January 9, 2017                [Page 9]


Internet-Draft      draft-lee-sidr-pki-deployment-02           July 2016


4.4.  Solutions to Incomplete Deployment and Low Validation Coverage

   Both of the two problems (incomplete deployment and low validation
   accuracy) are caused by the partial deployment of RPKI.  With the
   widely deployment of RPKI in the near future, these two problems
   ought to be mitigated.

5.  Security Considerations

   TBD

6.  IANA Considerations

   This draft does not request any IANA action.

7.  Acknowledgements

   The authors would like to thanks the valuable comments made by
   Stephen Kent and other members of sidr WG.

   This document was produced using the xml2rfc tool [RFC2629].

8.  References

8.1.  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>.

   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
              Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
              February 2012, <http://www.rfc-editor.org/info/rfc6480>.

   [RFC6482]  Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
              Origin Authorizations (ROAs)", RFC 6482,
              DOI 10.17487/RFC6482, February 2012,
              <http://www.rfc-editor.org/info/rfc6482>.

   [RFC6483]  Huston, G. and G. Michaelson, "Validation of Route
              Origination Using the Resource Certificate Public Key
              Infrastructure (PKI) and Route Origin Authorizations
              (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012,
              <http://www.rfc-editor.org/info/rfc6483>.






Lee, et al.              Expires January 9, 2017               [Page 10]


Internet-Draft      draft-lee-sidr-pki-deployment-02           July 2016


   [RFC6486]  Austein, R., Huston, G., Kent, S., and M. Lepinski,
              "Manifests for the Resource Public Key Infrastructure
              (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012,
              <http://www.rfc-editor.org/info/rfc6486>.

8.2.  Informative References

   [I-D.ietf-sidr-delta-protocol]
              Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
              "RPKI Repository Delta Protocol", draft-ietf-sidr-delta-
              protocol-03 (work in progress), July 2016.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              DOI 10.17487/RFC2629, June 1999,
              <http://www.rfc-editor.org/info/rfc2629>.

   [RFC5914]  Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor
              Format", RFC 5914, DOI 10.17487/RFC5914, June 2010,
              <http://www.rfc-editor.org/info/rfc5914>.

   [RFC6810]  Bush, R. and R. Austein, "The Resource Public Key
              Infrastructure (RPKI) to Router Protocol", RFC 6810,
              DOI 10.17487/RFC6810, January 2013,
              <http://www.rfc-editor.org/info/rfc6810>.

Authors' Addresses

   Xiaodong Lee
   CNNIC
   No.4 South 4th Street, Zhongguancun
   Beijing, 100190
   P.R. China

   Email: xl@cnnic.cn


   Xiaowei Liu
   CNNIC
   No.4 South 4th Street, Zhongguancun
   Beijing, 100190
   P.R. China

   Email: liuxiaowei@cnnic.cn








Lee, et al.              Expires January 9, 2017               [Page 11]


Internet-Draft      draft-lee-sidr-pki-deployment-02           July 2016


   Zhiwei Yan
   CNNIC
   No.4 South 4th Street, Zhongguancun
   Beijing, 100190
   P.R. China

   Email: yanzhiwei@cnnic.cn


   Guanggang Geng
   CNNIC
   No.4 South 4th Street, Zhongguancun
   Beijing, 100190
   P.R. China

   Email: gengguanggang@cnnic.cn


   Yu Fu
   CNNIC
   No.4 South 4th Street, Zhongguancun
   Beijing, 100190
   P.R. China

   Email: fuyu@cnnic.cn


























Lee, et al.              Expires January 9, 2017               [Page 12]