Internet DRAFT - draft-lee-sidr-rpki-deployment
draft-lee-sidr-rpki-deployment
Secure Inter-Domain Routing X. Lee
Internet-Draft X. Liu
Intended status: Informational Z. Yan
Expires: July 30, 2016 G. Geng
Y. Fu
CNNIC
January 27, 2016
RPKI Deployment Considerations: Problem Analysis and Alternative
Solutions
draft-lee-sidr-rpki-deployment-01
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 July 30, 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
Lee, et al. Expires July 30, 2016 [Page 1]
Internet-Draft draft-lee-sidr-pki-deployment-01 January 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. Misoperations . . . . . . . . . . . . . . . . . . . . 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 Accuracy . . . . . . . . . . . . . . . . . 7
4. Alternative Solutions to RPKI Deployment Problems . . . . . . 8
4.1. Solutions to Multiple TAs . . . . . . . . . . . . . . . . 8
4.2. Solutions to Misbehaved CAs . . . . . . . . . . . . . . . 8
4.3. Solutions to Data Synchronization . . . . . . . . . . . . 9
4.4. Solutions to Incomplete Deployment and Low Validation
Accuracy . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10
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 the validation of ROAs (Route Origin
Authorizations) [RFC6482]. ROAs are used to bind IP prefixes to the
Lee, et al. Expires July 30, 2016 [Page 2]
Internet-Draft draft-lee-sidr-pki-deployment-01 January 2016
AS that is permitted to originate routes for these IP prefixes.
Manifests [RFC6486] are also validated by 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) and verify (using rcynic or RPSTIR) the RPKI
objects from these 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 update messages
they receive.
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 January 2016,
the current routing table holds about 628,858 IP prefixes in total,
and the RPKI validation state has been determined for 39584 IP
prefixes, which means that only 6.29% 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 July 30, 2016 [Page 3]
Internet-Draft draft-lee-sidr-pki-deployment-01 January 2016
+---------------+---------+-------+-------+--------+----------+
| RIR | AFRINIC | APNIC | ARIN | LACNIC | RIPE NCC |
+---------------+---------+-------+-------+--------+----------+
| Adoption Rate | 1.65% | 3.1% | 1.02% | 18.37% | 11.35% |
+---------------+---------+-------+-------+--------+----------+
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 18.37%. While the adoption rates in ARIN and AFRINIC
are much lower, which are only 1.02% and 1.65% 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 may appear. In this section, we
attempt to collect and analyze the problems which 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 more than one TA in the RPKI architecture today, for
example, IANA and five RIRs are candidates to be 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 July 30, 2016 [Page 4]
Internet-Draft draft-lee-sidr-pki-deployment-01 January 2016
3.2. Problems of CAs
3.2.1. Misoperations
Considering misconfiguration is inevitable and the significant impact
it may cause, misconfiguration of CAs in RPKI is a potential risk in
actual deployment.
The misconfiguration of CAs in 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,
misconfigurations of an ROA (such as adding a new ROA, whacking an
existing ROA) may cause all routes covered by this ROA to become
invalid.
3.2.2. Unilateral Resource Revocation
In the RPKI architecture, there is a risk that CAs have the power to
unilaterally revoke the INRs which have been allocated to their
descendants, just 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 invalid. 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.
Since a CA in the 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) 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.
Lee, et al. Expires July 30, 2016 [Page 5]
Internet-Draft draft-lee-sidr-pki-deployment-01 January 2016
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 its 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. 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.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 July 30, 2016 [Page 6]
Internet-Draft draft-lee-sidr-pki-deployment-01 January 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|
| |
------
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 [RFC6483], the announcement for
prefix 218.241.106.0/23 will be considered to be invalid.
3.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 five RIRs differs a lot. LACNIC and RIPE NCC have the highest
validation accuracy and both of them are over 90%, while the accuracy
in APNIC is less than 70%. Many reasons may account for the low
validation accuracy, such as misconfigurations, low RPKI adoption
rates, etc.
Lee, et al. Expires July 30, 2016 [Page 7]
Internet-Draft draft-lee-sidr-pki-deployment-01 January 2016
+---------+-------+-------+---------+---------+----------+----------+
| 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 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 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 and thus might
exacerbate the risk of "Unilateral Resource Revocation" (power
imbalance) mentioned in Section 3.2.2.
4.2. Solutions to Misbehaved 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.
Lee, et al. Expires July 30, 2016 [Page 8]
Internet-Draft draft-lee-sidr-pki-deployment-01 January 2016
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.
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 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
offered a NOTIFY method that send NOTIFY message to make some
important RPs to actively fetch the updated RPKI objects in time.
4.4. 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.
5. Security Considerations
TBD
6. IANA Considerations
This draft does not request any IANA action.
Lee, et al. Expires July 30, 2016 [Page 9]
Internet-Draft draft-lee-sidr-pki-deployment-01 January 2016
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>.
[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., Austein, R.,
and D. Mandelberg, "RPKI Repository Delta Protocol",
draft-ietf-sidr-delta-protocol-01 (work in progress),
October 2015.
[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>.
Lee, et al. Expires July 30, 2016 [Page 10]
Internet-Draft draft-lee-sidr-pki-deployment-01 January 2016
[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>.
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
Guanggang Geng
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing, 100190
P.R. China
Email: gengguanggang@cnnic.cn
Lee, et al. Expires July 30, 2016 [Page 11]
Internet-Draft draft-lee-sidr-pki-deployment-01 January 2016
Yu Fu
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing, 100190
P.R. China
Email: fuyu@cnnic.cn
Lee, et al. Expires July 30, 2016 [Page 12]
