RPKI Router Report: Resource Public Key Infrastructure (RPKI) Router Implementation Report
A survey of how different vendors implement the RPKI Router protocol.
Bush, R., Austein, R., Patel, K., Gredler, H., and M. Waehlisch, "Resource Public Key Infrastructure (RPKI) Router Implementation Report", RFC 7128, DOI 10.17487/RFC7128, February 2014, <https://www.rfc-editor.org/info/rfc7128>.
@misc{rfc7128,
series = {Request for Comments},
number = 7128,
howpublished = {RFC 7128},
publisher = {RFC Editor},
doi = {10.17487/RFC7128},
url = {https://www.rfc-editor.org/info/rfc7128},
author = {R. Bush and R. Austein and K. Patel and H. Gredler and M. Waehlisch},
title = {{Resource Public Key Infrastructure (RPKI) Router Implementation Report}},
pagetotal = 11,
year = 2014,
month = feb,
} RFC text
Contents
Internet Engineering Task Force (IETF) R. Bush
Request for Comments: 7128 Internet Initiative Japan
Category: Informational R. Austein
ISSN: 2070-1721 Dragon Research Labs
K. Patel
Cisco Systems
H. Gredler
Juniper Networks, Inc.
M. Waehlisch
FU Berlin
February 2014
Resource Public Key Infrastructure (RPKI) Router Implementation Report
Abstract
This document is an implementation report for the Resource Public Key
Infrastructure (RPKI) Router protocol as defined in RFC 6810. The
authors did not verify the accuracy of the information provided by
respondents. The respondents are experts with the implementations
they reported on, and their responses are considered authoritative
for the implementations for which their responses represent. The
respondents were asked to only use the "YES" answer if the feature
had at least been tested in the lab.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7128.
Copyright Notice
Copyright (c) 2014 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
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
2. Implementation Forms . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Data Units . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 6
5. Protocol Transport . . . . . . . . . . . . . . . . . . . . . 7
6. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Incremental Updates Support . . . . . . . . . . . . . . . . . 8
8. Session ID Support . . . . . . . . . . . . . . . . . . . . . 8
9. Incremental Session Startup Support . . . . . . . . . . . . . 8
10. Interoperable Implementations . . . . . . . . . . . . . . . . 9
10.1. Cisco Implementation . . . . . . . . . . . . . . . . . . 9
10.2. Juniper Implementation . . . . . . . . . . . . . . . . . 9
10.3. rpki.net Implementation . . . . . . . . . . . . . . . . 9
10.4. RIPE NCC Implementation . . . . . . . . . . . . . . . . 9
10.5. RTRlib Implementation . . . . . . . . . . . . . . . . . 9
10.6. BBN RPSTIR Implementation . . . . . . . . . . . . . . . 9
11. Security Considerations . . . . . . . . . . . . . . . . . . . 9
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
13. Normative References . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
In order to formally validate the origin Autonomous Systems (ASes) of
BGP announcements, routers need a simple but reliable mechanism to
receive Resource Public Key Infrastructure (RPKI) [RFC6810] prefix
origin data from a trusted cache. The RPKI Router protocol defined
in [RFC6810] provides a mechanism to deliver validated prefix origin
data to routers.
This document provides an implementation report for the RPKI Router
protocol as defined in RFC 6810 [RFC6810].
The authors did not verify the accuracy of the information provided
by respondents or by any alternative means. The respondents are
experts with the implementations they reported on, and their
responses are considered authoritative for the implementations for
which their responses represent. Respondents were asked to only use
the "YES" answer if the feature had at least been tested in the lab.
2. Implementation Forms
Contact and implementation information for person filling out this
form:
IOS
Name: Keyur Patel
Email: keyupate@cisco.com
Vendor: Cisco Systems, Inc.
Release: IOS
Protocol Role: Client
XR
Name: Forhad Ahmed
Email:foahmed@cisco.com
Vendor: Cisco Systems, Inc.
Release: IOS-XR
Protocol Role: Client
JUNOS
Name: Hannes Gredler
Email: hannes@juniper.net
Vendor: Juniper Networks, Inc.
Release: JUNOS
Protocol Role: Client
rpki.net
Name: Rob Austein
Email: sra@hactrn.net
Vendor: rpki.net project
Release: <http://subvert-rpki.hactrn.net/trunk/>
Protocol Role: Client, Server
NCC
Name: Tim Bruijnzeels
Email: tim@ripe.net
Vendor: RIPE NCC
Release: RIPE NCC validator-app 2.0.0 <https://github.com/RIPE-NCC
/rpki-validator>
Protocol Role: Server
RTRlib
Name: Fabian Holler, Matthias Waehlisch
Email: waehlisch@ieee.org
Vendor: HAW Hamburg, FU Berlin, RTRlib project
Release: RTRlib 0.2 <http://rpki.realmv6.org/>
Protocol Role: Client
BBN
Name: David Mandelberg, Andrew Chi
Email: dmandelb@bbn.com
Vendor: Raytheon/BBN Technologies
Release: RPSTIR 0.2 <http://sourceforge.net/projects/rpstir/>
Protocol Role: Server
3. Protocol Data Units
Does the implementation support Protocol Data Units (PDUs) as
described in Section 5 of [RFC6810]?
P0: Serial Notify
P1: Serial Query
P2: Reset Query
P3: Cache Response
P4: IPv4 Prefix
P6: IPv6 Prefix
P7: End of Data
P8: Cache Reset
P10: Error Report
+---------+-----+-----+-------+--------+---------+-----+------+-----+
| | IOS | XR | JUNOS | rpki | rpki | NCC | RTR- | BBN |
| | | | | .net | .net | | lib | |
| | | | | clnt | srvr | | | |
+---------+-----+-----+-------+--------+---------+-----+------+-----+
| Rcv.P0 | YES | YES | YES | YES | --- | --- | YES | --- |
| Snd.P0 | --- | --- | --- | --- | YES | YES | --- | YES |
| Rcv.P1 | --- | --- | --- | --- | YES | YES | --- | YES |
| Snd.P1 | YES | YES | YES | YES | --- | --- | YES | --- |
| Rcv.P2 | --- | --- | --- | --- | YES | YES | --- | YES |
| Snd.P2 | YES | YES | YES | YES | --- | --- | YES | --- |
| Rcv.P3 | YES | YES | YES | YES | --- | --- | YES | --- |
| Snd.P3 | --- | --- | --- | --- | YES | YES | --- | YES |
| Rcv.P4 | YES | YES | YES | YES | --- | --- | YES | --- |
| Snd.P4 | --- | --- | --- | --- | YES | YES | --- | YES |
| Rcv.P6 | YES | YES | YES | YES | --- | --- | YES | --- |
| Snd.P6 | --- | --- | --- | --- | YES | YES | --- | YES |
| Rcv.P7 | YES | YES | YES | YES | --- | --- | YES | --- |
| Snd.P7 | --- | --- | --- | --- | YES | YES | --- | YES |
| Rcv.P8 | YES | YES | YES | YES | --- | --- | YES | --- |
| Snd.P8 | --- | --- | --- | --- | YES | YES | --- | YES |
| Rcv.P10 | YES | YES | NO~1 | YES | YES | YES | YES | YES |
| Snd.P10 | YES | NO | NO | YES | YES | YES | YES | YES |
+---------+-----+-----+-------+--------+---------+-----+------+-----+
Note 1: No, Error PDU gets silently ignored.
4. Protocol Sequence
Does the RPKI Router protocol implementation follow the four protocol
sequences as outlined in Section 6 of [RFC6810]?
S1: Start or Restart
S2: Typical Exchange
S3: No Incremental Update Available
S4: Cache Has No Data Available
+----+-----+-----+-------+--------+---------+------+--------+-------+
| | IOS | XR | JUNOS | rpki | rpki | NCC | RTRlib | BBN |
| | | | | .net | .net | | | |
| | | | | clnt | srvr | | | |
+----+-----+-----+-------+--------+---------+------+--------+-------+
| S1 | YES | YES | YES | YES | YES | YES | YES | YES |
| S2 | YES | YES | YES | YES | YES | NO~1 | YES | YES |
| S3 | YES | YES | YES | YES | YES | YES | YES | YES |
| S4 | YES | YES | YES | YES | YES | YES | YES | YES~2 |
+----+-----+-----+-------+--------+---------+------+--------+-------+
Note 1: Does not implement Serial Query, thus Incremental Update is
never available, so responds to Serial Query with Cache
Reset as described in Section 6.3 of [RFC6810]
Note 2: Sends Cache Reset in response to Serial Query when no data;
sends Error Report PDU in response to Reset Query when no
data.
5. Protocol Transport
Does the RPKI Router protocol implementation support the different
protocol transport mechanisms outlined in Section 7 of [RFC6810]?
+---------+-----+-----+-------+-------+--------+-----+--------+-----+
| | IOS | XR | JUNOS | rpki | rpki | NCC | RTRlib | BBN |
| | | | | .net | .net | | | |
| | | | | clnt | srvr | | | |
+---------+-----+-----+-------+-------+--------+-----+--------+-----+
| SSH | NO | YES | NO | YES | YES | NO | YES | YES |
| TLS | NO | NO | NO | NO | NO | NO | NO | NO |
| TCP | YES | YES | YES | YES | YES | YES | YES | YES |
| TCP-MD5 | NO | NO | NO | NO | NO | NO | NO | NO |
| TCP-AO | NO | NO | NO | NO | NO | NO | NO | NO |
| IPsec | NO | NO | NO | NO | NO | NO | NO | NO |
+---------+-----+-----+-------+-------+--------+-----+--------+-----+
6. Error Codes
Does the RPKI Router protocol implementation support the different
protocol error codes outlined in Section 10 of [RFC6810]?
+-------+-----+-----+-------+-------+--------+-------+--------+-----+
| | IOS | XR | JUNOS | rpki | rpki | NCC | RTRlib | BBN |
| | | | | .net | .net | | | |
| | | | | clnt | srvr | | | |
+-------+-----+-----+-------+-------+--------+-------+--------+-----+
| Rcv.0 | YES | YES | NO | YES | YES | YES | YES | YES |
| Snd.0 | YES | YES | NO | YES | YES | YES | YES | YES |
| Rcv.1 | YES | YES | NO | YES | YES | YES | YES | YES |
| Snd.1 | YES | YES | NO | YES | YES | YES | YES | YES |
| Rcv.2 | YES | YES | NO | YES | --- | --- | YES | --- |
| Snd.2 | --- | --- | --- | --- | YES | YES | --- | YES |
| Rcv.3 | YES | YES | NO | YES | --- | --- | YES | --- |
| Snd.3 | --- | --- | --- | --- | YES | YES | --- | YES |
| Rcv.4 | YES | YES | NO | YES | YES | YES | YES | YES |
| Snd.4 | YES | YES | NO | YES | YES | YES | YES | YES |
| Rcv.5 | YES | YES | NO | YES | YES | YES | YES | YES |
| Snd.5 | YES | YES | NO | YES | YES | YES | YES | YES |
| Rcv.6 | --- | --- | --- | --- | YES | YES~1 | --- | YES |
| Snd.6 | YES | YES | NO | NO | --- | --- | YES | --- |
| Rcv.7 | --- | --- | --- | --- | YES | YES~1 | --- | YES |
| Snd.7 | YES | YES | NO | NO | --- | --- | YES | --- |
+-------+-----+-----+-------+-------+--------+-------+--------+-----+
Note 1: YES, but... fatal, so connection is dropped, but cache does
not conclude it's inconsistent.
7. Incremental Updates Support
Does the RPKI Router implementation support Incremental Updates as
defined in Section 4 of [RFC6810]?
+-----+----+-------+-------------+-------------+-----+--------+-----+
| IOS | XR | JUNOS | rpki.net | rpki.net | NCC | RTRlib | BBN |
| | | | clnt | srvr | | | |
+-----+----+-------+-------------+-------------+-----+--------+-----+
| NO | NO | YES | YES | YES | NO | YES | YES |
+-----+----+-------+-------------+-------------+-----+--------+-----+
8. Session ID Support
Session ID is used to indicate that the cache server may have
restarted and that the incremental restart may not be possible.
Does the RPKI Router protocol implementation support the Session ID
procedures outlined in Section 5.1 of [RFC6810]?
+-----+-----+-------+------------+------------+------+--------+-----+
| IOS | XR | JUNOS | rpki.net | rpki.net | NCC | RTRlib | BBN |
| | | | clnt | srvr | | | |
+-----+-----+-------+------------+------------+------+--------+-----+
| YES | YES | YES | YES | YES | NO~1 | YES | YES |
+-----+-----+-------+------------+------------+------+--------+-----+
Note 1: NO, using random, but will FIX
9. Incremental Session Startup Support
Does the RPKI Router protocol implementation support Incremental
session startups with Serial Number and Session ID as defined in
Section 5.3 of [RFC6810]?
+-----+-----+-------+------------+-------------+-----+--------+-----+
| IOS | XR | JUNOS | rpki.net | rpki.net | NCC | RTRlib | BBN |
| | | | clnt | srvr | | | |
+-----+-----+-------+------------+-------------+-----+--------+-----+
| YES | YES | YES | YES | YES | NO | YES | YES |
+-----+-----+-------+------------+-------------+-----+--------+-----+
10. Interoperable Implementations
List other implementations with which you have tested the
interoperability of the RPKI Router implementation.
10.1. Cisco Implementation
Cisco: The Cisco IOS and IOS-XR implementation should be
interoperable with other vendor RPKI Router Protocol implementations.
In particular, we have tested our interoperability with rpki.net's
RPKI Router implementation.
10.2. Juniper Implementation
Juniper: The Juniper Networks, Inc. JUNOS implementation should be
interoperable with other vendor RPKI Router Protocol implementations.
In particular, we have tested our interoperability with rpki.net's
and NCC's RPKI Router Cache implementation.
10.3. rpki.net Implementation
rpki.net: The rpki.net implementation should operate with other rpki-
rtr implementations. In particular, we have tested our rpki-rtr
server's interoperability with Cisco IOS, Cisco IOS-XR, and Juniper.
10.4. RIPE NCC Implementation
RIPE NCC: The RIPE NCC validator has been tested by us with other
rpki-rtr implementations. In particular, we have tested with RTRlib
and CISCO IOS. We received positive feedback from close contacts who
tested our validator with JUNOS and Quagga.
10.5. RTRlib Implementation
RTRlib: The RTRlib has been tested by us with other rpki-rtr
implementations. In particular, we have tested with rtr-origin from
rpki.net and RIPE NCC Validator.
10.6. BBN RPSTIR Implementation
BBN RPSTIR: We have not yet tested with any other implementations.
11. Security Considerations
No new security issues are introduced to the RPKI Router protocol
defined in [RFC6810].
12. Acknowledgements
The authors would like to thank Andrew Chi, David Mandelberg, Fabian
Holler, Forhad Ahmed, and Tim Bruijnzeels for their contributions to
this document.
13. Normative References
[RFC6810] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol", RFC 6810,
January 2013.
Authors' Addresses
Randy Bush
Internet Initiative Japan
5147 Crystal Springs
Bainbridge Island, Washington 98110
US
EMail: randy@psg.com
Rob Austein
Dragon Research Labs
EMail: sra@hactrn.net
Keyur Patel
Cisco Systems
170 West Tasman Drive
San Jose, California 95134
US
EMail: keyupate@cisco.com
Hannes Gredler
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, California 94089
US
EMail: hannes@juniper.net
Matthias Waehlisch
FU Berlin
Takustr. 9
Berlin 14195
Germany
EMail: waehlisch@ieee.org
URI: http://www.inf.fu-berlin.de/~waehl
AI ELI5
On this page
§1Why This Report Matters
The RPKI Router protocol (defined in RFC 6810) is how routers get trusted information about which Autonomous Systems (ASes) are allowed to announce which IP prefixes. Before this report, vendors had built implementations, but there was no public documentation of how complete or compatible they were.
This report is an implementation survey: the authors asked representatives from six major vendors and projects (Cisco IOS, Cisco IOS-XR, Juniper JUNOS, rpki.net, RIPE NCC, and RTRlib) to fill out a form describing what parts of the protocol they had built. The authors did not independently verify the answers, but the respondents are experts in their own implementations and their responses are authoritative for those products.
The authors asked six companies: do you have the RPKI Router feature? How much of it? Can you talk to other vendors' systems? They trusted the experts at those companies to answer honestly.
§2Implementation Forms
RPKI Router implementations come in two flavors: client (a router that fetches prefix origin data) and server (a cache that stores and serves that data). Cisco's IOS and IOS-XR are routers, so they are clients. The RIPE NCC validator and BBN RPSTIR are servers that provide data to clients. Some projects like rpki.net built both: a client library and a server.
The respondents are experts on routers and cache software from the time the survey was conducted (early 2014). Their implementations had been tested in the lab by their authors before being reported as working, so 'YES' means at least lab-tested, not necessarily production-deployed.
Some systems are routers (they ask for the data) and some are caches (they give the data). This report lists which ones were ready for testing at the time.
§3Protocol Messages and Data Units
The RPKI Router protocol uses 11 types of message, called Protocol Data Units (PDUs). The main ones are Serial Notify (to say 'data changed'), Serial Query (to ask for changes), Reset Query (to ask for a full reload), and the answer messages: Cache Response (here is the zone serial), IPv4 and IPv6 Prefix (a prefix origin rule), and End of Data (that is all). An Error Report PDU lets either side report a problem.
The table shows that all major implementations support the most important ones: clients can receive IPv4 and IPv6 prefixes, serial notify and end of data. All client implementations support Serial Query and Reset Query. Only rpki.net and RIPE NCC as servers can originate (send) Serial Notify. The one anomaly is JUNOS, which does not receive or send the Error PDU; when it encounters an error it just disconnects.
The protocol has eleven message types. The table shows whether each router and cache can send and receive each type. Most vendors support most messages, with a few exceptions for error handling.
§4How Implementations Handle Key Features
The protocol defines four typical message sequences: Start or Restart, Typical Exchange (incremental updates), No Incremental Update Available, and Cache Has No Data. All implementations handle all four sequences correctly, with one exception: the RIPE NCC validator does not implement the Serial Query request, so it always responds by resetting (sending all data again) when asked for incremental updates.
A critical feature is support for incremental updates. When the cache's data changes, a client can ask only for what changed rather than reloading everything. Clients from Cisco do not support this; Juniper and rpki.net do. On the transport side, TCP is universal, but SSH is only in rpki.net, some Cisco IOS-XR deployments, RTRlib, and BBN RPSTIR. No implementation supports TLS, TCP-MD5, TCP-AO, or IPsec for the router-to-cache connection.
The different implementations handle updates in different ways. Most let routers ask for just what changed, but Cisco does not. All use plain TCP, and only a few support SSH encryption.
§5Interoperability
The report documents interoperability testing that vendors carried out. Cisco IOS and IOS-XR have been tested with rpki.net. Juniper JUNOS has been tested with both rpki.net and RIPE NCC cache servers. The rpki.net implementation has been tested with Cisco clients from both vendors. RIPE NCC tested with RTRlib and Cisco IOS; they also received positive feedback from contacts who tested with JUNOS and Quagga. RTRlib (from Hamburg University) tested with rpki.net and RIPE NCC.
One implementation, BBN RPSTIR, had not been tested with other vendors' products at the time of the report. The overall picture shows that the major vendor implementations can interoperate, giving operators confidence that they can mix and match cache software with router products from different vendors.
The vendors tested their routers with different caches to make sure they work together. Most combinations worked. This means network operators can choose any router and any cache and they should work.