Secure Inter-Domain Routing X. Lee Internet-Draft X. Liu Intended status: Informational Z. Yan Expires: January 29, 2016 Y. Fu CNNIC July 28, 2015 RPKI Deployment Considerations: Problem Analysis and Alternative Solutions draft-lee-sidr-rpki-deployment-00 Abstract With the global deployment of RPKI, a lot of concerns from technical, economic and political aspects have and will be raised. In this draft, we collect and analyze the problems have been appeared or will appear during the RPKI deployment, and give the alternative 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 29, 2016. Copyright Notice Copyright (c) 2015 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 Lee, et al. Expires January 29, 2016 [Page 1] Internet-Draft draft-lee-sidr-rpki-deployment-00 July 2015 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. Technical Problems . . . . . . . . . . . . . . . . . . . 4 3.1.1. More than One TA . . . . . . . . . . . . . . . . . . 4 3.1.2. Problems of CAs . . . . . . . . . . . . . . . . . . . 5 3.1.3. Global Inconsistency . . . . . . . . . . . . . . . . 5 3.1.4. Data Synchronization . . . . . . . . . . . . . . . . 5 3.1.5. Problems of Staged and Incomplete Deployment . . . . 6 3.1.6. Low Validation Accuracy . . . . . . . . . . . . . . . 7 3.2. Economic Problems . . . . . . . . . . . . . . . . . . . . 8 3.3. Political Problems . . . . . . . . . . . . . . . . . . . 8 4. Alternative Solutions to RPKI Deployment Risks . . . . . . . 9 4.1. Solutions to Technical Problems . . . . . . . . . . . . . 9 4.1.1. Solutions to Multiple TAs . . . . . . . . . . . . . . 9 4.1.2. Solutions to Misbehaved CAs . . . . . . . . . . . . . 9 4.1.3. Solutions to Global Inconsistency . . . . . . . . . . 10 4.1.4. Solutions to Data Synchronization . . . . . . . . . . 10 4.1.5. Solutions to Incomplete Deployment and Low Validation Accuracy . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Strategy to Resolve Economic Problems . . . . . . . . . . 11 4.3. Solutions to Mitigate Political Problems . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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, including IP prefixes and AS numbers) allocation hierarchy. Each INR allocation requires corresponding resource certificates to attest to it. Two important resource certificates [RFC6480] are needed during this allocation process, and they are CA Lee, et al. Expires January 29, 2016 [Page 2] Internet-Draft draft-lee-sidr-rpki-deployment-00 July 2015 certificates and EE (End-entity) certificates: CA certificates attest to the INR holdings; EE certificates are primarily used for the validation of ROAs (Route Origin Authorizations) [RFC6482] which is used to verify whether an AS is permitted to originate routes to specific IP prefixes. Besides, Manifest [RFC6486] is used to ensure the integrity of the repository. The process of using RPKI to verify the route origin is as follows. 1. CAs, including IANA (Internet Assigned Numbers Authority), 5 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 the their repositories. 2. RPs (Relying Parties) all over the world collect (with the rsync protocol for example) and verify (using a validation tool, such as rcynic) the PRKI objects from the distributed repositories, and provide the results of verification to BGP border routers. 3. Finally, BGP border routers can make use of these results to verify the route origin information in the BGP messages they have received. 1.2. Status of RPKI Deployment The 5 RIRs have finished the deployment of RPKI, and are now offering RPKI services to their members. A number of countries (Ecuador, Japan, Bangladesh, etc.) have also started to test and deploy RPKI interiorly. And in order to further promote the deployment of RPKI, ICANN (Internet Corporation for Assigned Names and Numbers), the 5 RIRs and many NIRs and companies have been 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, the current routing table holds about 595817 IP prefixes in total, and the RPKI validation state has been determined for 38398 IP prefixes, which means that only 6.44% of the prefixes in the routing table can be validated. And Table 1 offers a more intuitive display of the RPKI "adoption rate" (the percentage of members deployed RPKI) in the 5 RIRs. Lee, et al. Expires January 29, 2016 [Page 3] Internet-Draft draft-lee-sidr-rpki-deployment-00 July 2015 +---------------+---------+-------+-------+--------+----------+ | RIR | AFRINIC | APNIC | ARIN | LACNIC | RIPE NCC | +---------------+---------+-------+-------+--------+----------+ | Adoption Rate | 0.98% | 1.96% | 0.83% | 24.04% | 10.3% | +---------------+---------+-------+-------+--------+----------+ 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 24.04%. While the adoption rates in ARIN and AFRINIC are much lower, which are only 0.83% and 0.98% 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 will get 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, a lot of technical, economic and political problems have appeared and may appear. In this section, we attempt to collect and analyze the problems which are most critical among them. 3.1. Technical Problems 3.1.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 acts as an authority to verify digital signatures. And the associated data describes the types of information and actions for which the TA is authoritative. There are more than one TA in the RPKI architecture today, for example, IANA and 5 RIRs are candidates to be default TAs. With more than one TA, there are problems that two or more organizations may accidentally or maliciously issue certificates for the allocation of the same INRs. Then it may lead to inconsistent and conflicting assertion 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 29, 2016 [Page 4] Internet-Draft draft-lee-sidr-rpki-deployment-00 July 2015 3.1.2. Problems of CAs 3.1.2.1. Misconfigurations Considering misconfiguration is inevitable and the significant impact it may cause, misconfiguration of CAs in RPKI is a potential problem in actual deployment. The misconfiguration of CAs in RPKI will lead to serious consequences similar to those caused by malicious attacks (black-hole routes, traffic interception, and denial-of-service attacks). For example, misconfigurations of an ROA (such as adding a new ROA, whacking an existing ROA) will cause all routes covered by this ROA to become invalid. 3.1.2.2. Unilateral Resource Revocation In the RPKI architecture, there is a problem that CAs have the power to unilaterally and abusively revoke the INRs which have been allocated to their descendents, just by revoking the corresponding CA certificates [RFC6480]. Since revocation of certificates usually leads to taking the resource holder offline, the risk of unilateral resource revocation is rather serious. 3.1.3. Global Inconsistency The problem of global inconsistency may also be called "mirror world attacks". In mirror world attacks, a malicious CA presents one view of the RPKI repository to some RPs, and a different view to others. Since a CA in RPKI can control everything in its own repository, there are possibilities that a malicious CA may perform these attacks easily. 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 ROA deliberately) to the others. When these deceived RPs offer their validation results to BGP routers, the routers may abandon the legitimate routes which are considered to be invalid according to the validation results they have received. 3.1.4. Data Synchronization It is required in [RFC6480] that all repositories must be accessible via rsync protocol which is used for RPs to get the RPKI objects in the global distributed repositories. However, the rsync protocol is considered to be controversial with its following disadvantages: Lee, et al. Expires January 29, 2016 [Page 5] Internet-Draft draft-lee-sidr-rpki-deployment-00 July 2015 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. Not good enough in efficiency, scalability and security: Rsync is efficient when it is used between one client and one server. However, in RPKI a large number of clients may regularly connect to the repository server at the same time. Rsync is not efficient and scalable enough to deal with this concurrent case. Moreover, rsync itself provides little security (no content encryption and weak authentication especially in old versions) while transferring data. 3. 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. And in order to rectify this inconsistency, extra overhead costs (such as performing the synchronization once more) are required. 3.1.5. Problems of Staged and Incomplete Deployment Since the global deployment of RPKI is an incremental and staged process, a lot of unexpected issues 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 have not yet. 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 29, 2016 [Page 6] Internet-Draft draft-lee-sidr-rpki-deployment-00 July 2015 ------- -------------- |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 origination 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 [RFC6487], the announcement for prefix 218.241.106.0/23 will be considered to be invalid. 3.1.6. Low Validation Accuracy The route origin validation accuracy refers to the percentage of valid routes. i.e., Accuracy = number_of_valid_routes / (number_of_valid_routes + number_of_invalid_routes). As we can see from Table 2, the accuracy of route origin validation in the 5 RIRs differs a lot. LACNIC and RIPE NCC have the highest validation accuracy and both of them are over 90%, while the accuracy in AFRINIC is less than 70%. Many reasons may account for the low validation accuracy, such as misconfigurations, low adoption rates, etc. Lee, et al. Expires January 29, 2016 [Page 7] Internet-Draft draft-lee-sidr-rpki-deployment-00 July 2015 +---------+-------+-------+---------+---------+----------+----------+ | RIR | Total | Valid | Invalid | Unknown | Accuracy | Adoption | | | | | | | | Rate | +---------+-------+-------+---------+---------+----------+----------+ | AFRI- | 14426 | 96 | 45 | 14285 | 68.09% | 0.98% | | NIC | | | | | | | | APNIC | 14475 | 2130 | 712 | 141913 | 74.95% | 1.96% | | | 5 | | | | | | | ARIN | 21019 | 1409 | 344 | 208441 | 80.38% | 0.83% | | | 4 | | | | | | | LACNIC | 75267 | 17352 | 744 | 57171 | 95.89% | 24.04% | | RIPE | 15115 | 14544 | 1022 | 135590 | 93.43% | 10.3% | | NCC | 6 | | | | | | +---------+-------+-------+---------+---------+----------+----------+ Table 2. Route Origin Validation Accuracy in 5 RIRs When comparing the last two columns in Table 2, it can be found that a higher RPKI adoption rate tends to result in a higher validation accuracy. And this tendency can be explained by the example we present in section 3.1.5. 3.2. Economic Problems To adopt RPKI, ISPs may need to deploy and maintain servers running as RPs, which means that ISPs have to take on more costs, including more responsibilities, more time and more money. Besides, the route origin validation in RPKI has been designed to be adopted on current BGP routers. In order to realize the validation, the border routers need to be upgraded to accommodate some additions, such as the "Route Validation Database", which means that with the deployment of RPKI, there are additional costs to upgrade the network equipments. 3.3. Political Problems RPKI provides a hierarchical architecture to improve the inter-domain routing security, however, it also induces power imbalance. The most obvious example of power imbalance is Unilateral Resource Revocations which we have introduced in section 3.1.2.2. And this revocation may be driven by business disputes and political disagreements. Lee, et al. Expires January 29, 2016 [Page 8] Internet-Draft draft-lee-sidr-rpki-deployment-00 July 2015 4. Alternative Solutions to RPKI Deployment Risks In this section, we give and analyze the related alternative solutions and strategies to solve or mitigate the problems mentioned in Section 3. 4.1. Solutions to Technical Problems 4.1.1. Solutions to Multiple TAs RIRs are trying to continually evolve RPKI, including the migration to a single GTA (Global Trust Anchor) as the root of the RPKI hierarchical structure. ICANN and RIRs have developed and deployed 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 on the Internet could be reduced a lot. However, this solution entitles more power to ICANN and exacerbates the risk of "power imbalance" mentioned in section 3.3. 4.1.2. Solutions to Misbehaved CAs 1) "Consent" Solution To resolve the problems of unilateral resource revocation, Heilman et al. proposed a mechanism to improve the transparency of RPKI. They also offer some tools which can detect changes to the RPKI, for example, the CA revokes a resource certificate. The main idea of this mechanism is that any revocation of INRs requires consent from all impacted parties. And the consent comes in the form of a ".dead" object which is constructed recursively to ensure that every entities impacted could be notified. This mechanism balances the power between the CAs in the RPKI hierarchical architecture to resolve the problem of unilateral resource revocation. 2) "Suspenders" Solution S. Kent et al. also put forward a collection of mechanisms named "Suspenders". "Suspenders" are designed to address the adverse effects on INR holders which were caused by CAs' accidental or deliberate misbehavior. 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 Lee, et al. Expires January 29, 2016 [Page 9] Internet-Draft draft-lee-sidr-rpki-deployment-00 July 2015 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. Both "Consent" solution and "Suspenders" solution are considered to be effective to protect RPKI against misconfigurations and malicious actions by authorities who abuse their power. 4.1.3. Solutions to Global Inconsistency The mechanism provided by Heilman et al. is also effective to protect RPs against mirror world attacks. It allows RPs to raise an alarm whenever they found their views of RPKI repositories inconsistent with the others'. Hristo Stoyanov also provides a mechanism to resolve the problem of global inconsistency. This mechanism constructs a k-connected spanning graph, and performs 2-party audits for all edges in the graph. This mechanism manages to ensure that every network device shares consistent information about the ownership of IP addresses to avoid mirror world attacks. 4.1.4. 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 to eliminate a number of consistency related issues, help to reduce the load on publication servers, and have higher scalability. 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 Lee, et al. Expires January 29, 2016 [Page 10] Internet-Draft draft-lee-sidr-rpki-deployment-00 July 2015 offered a NOTIFY method that send NOTIFY message to make some key RPs to actively fetch the updated RPKI objects in time. 4.1.5. Solutions to Incomplete Deployment and Low Validation Accuracy 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. 4.2. Strategy to Resolve Economic Problems Since what ISPs care about most is profit instead of security, it is essential to make ISPs aware of the economic interests behind the deployment. RPKI is the base of BGPsec [I-D.ietf-sidr-bgpsec-protocol] which can affect the route selection, and routers in a more secure AS which deployed with RPKI and BGPsec deserve a higher priority. With this strategy, an ISP who has deployed RPKI and BGPsec can attract more traffic, and then more revenue. In terms of RPKI-capable border routers, a lot of network equipment manufacturers including Cisco, Juniper and Alcatel Lucent have put RPKI as an important feature in their new products. And this fact could motivate more network equipment manufacturers to provide support for RPKI in order to keep pace with these pioneers. 4.3. Solutions to Mitigate Political Problems Obviously, the "power imbalance" is both a technical and political problem. As mentioned in section 4.1.2, "Consent" mechanism and "Suspenders" mechanism are presented to address the unilateral resource revocation problem. And both of the two mechanisms have taken the political problems (such as government mandate and law enforcement actions) into consideration. So we think that the two mechanisms would be effective to mitigate the power imbalance problem. 5. Security Considerations TBD. 6. IANA Considerations This draft does not request any IANA action. Lee, et al. Expires January 29, 2016 [Page 11] Internet-Draft draft-lee-sidr-rpki-deployment-00 July 2015 7. Acknowledgements The authors would like to thanks the valuable comments made by XXX and other members of XX 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, March 1997. [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012. [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012. [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, February 2012. [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012. 8.2. Informative References [I-D.ietf-sidr-bgpsec-protocol] Lepinski, M., "BGPsec Protocol Specification", draft-ietf- sidr-bgpsec-protocol-13 (work in progress), July 2015. [I-D.ietf-sidr-delta-protocol] Bruijnzeels, T., Muravskiy, O., Weber, B., Austein, R., and D. Mandelberg, "RPKI Repository Delta Protocol", draft-ietf-sidr-delta-protocol-00 (work in progress), February 2015. Lee, et al. Expires January 29, 2016 [Page 12] Internet-Draft draft-lee-sidr-rpki-deployment-00 July 2015 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Format", RFC 5914, June 2010. 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 Zhiwei Yan CNNIC No.4 South 4th Street, Zhongguancun Beijing, 100190 P.R. China Email: yanzhiwei@cnnic.cn Yu Fu CNNIC No.4 South 4th Street, Zhongguancun Hai-Dian District, Beijing, 100190 P.R. China Email: fuyu@cnnic.cn Lee, et al. Expires January 29, 2016 [Page 13]