One document matched: draft-lee-sidr-rpki-deployment-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 01:54:39 |