randy/draft-8210bis
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
draft-8210bis/draft-ietf-sidrops-8210bis.xml

1971 lines
85 KiB
XML
Raw Blame History

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc sortrefs="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-sidrops-8210bis-05" obsoletes="8210" ipr="trust200902" consensus="yes">
<front>
<title abbrev="RPKI-Router Protocol">
The Resource Public Key Infrastructure (RPKI) to Router
Protocol, Version 2
</title>
<author fullname="Randy Bush" initials="R." surname="Bush">
<organization>IIJ, Arrcus, &amp; DRL</organization>
<address>
<postal>
<street>5147 Crystal Springs</street>
<city>Bainbridge Island</city>
<region>Washington</region>
<code>98110</code>
<country>United States of America</country>
</postal>
<email>randy@psg.com</email>
</address>
</author>
<author initials="R." surname="Austein" fullname="Rob Austein">
<organization>Dragon Research Labs</organization>
<address>
<email>sra@hactrn.net</email>
</address>
</author>
<date />
<abstract>
<t>
In order to verifiably validate the origin Autonomous Systems
and Autonomous System Paths of BGP announcements, routers need
a simple but reliable mechanism to receive Resource Public Key
Infrastructure (RFC 6480) prefix origin data and router keys
from a trusted cache. This document describes a protocol to
deliver them.
</t>
<t>
This document describes version 2 of the RPKI-Router protocol.
RFC 6810 describes version 0, and RFC 8210 describes version 1.
This document updates RFC 8210.
</t>
</abstract>
</front>
<middle>
<section anchor="Intro" title="Introduction">
<t>
In order to verifiably validate the origin Autonomous Systems
(ASs) and AS paths of BGP announcements, routers need a
simple but reliable mechanism to receive cryptographically
validated Resource Public Key Infrastructure (RPKI)
<xref target="RFC6480"/> prefix origin data and router keys
from a trusted cache. This document describes a protocol to
deliver them. The design is intentionally constrained to be
usable on much of the current generation of ISP router
platforms.
</t>
<t>This document updates <xref target="RFC8210"/>.</t>
<t>
<xref target="Struct"/> describes the deployment structure, and
<xref target="OpOvr"/> then presents an operational overview.
The binary payloads of the protocol are formally described in
<xref target="pdus"/>, and the expected Protocol Data Unit
(PDU) sequences are described in <xref target="protocol"/>.
The transport protocol options are described in
<xref target="Transport"/>. <xref target="Setup"/> details
how routers and caches are configured to connect and authenticate.
<xref target="Scenarios"/> describes likely deployment
scenarios. The traditional security and IANA considerations end
the document.
</t>
<t>
The protocol is extensible in order to support new PDUs with
new semantics, if deployment experience indicates that they are
needed. PDUs are versioned should deployment experience call
for change.
</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in BCP 14
<xref format="default" pageno="false" target="RFC2119"/>
<xref format="default" pageno="false" target="RFC8174"/> when,
and only when, they appear in all capitals, as shown here.</t>
</section>
<section title="Changes from RFC 8210">
<t>
This section summarizes the significant changes between
<xref target="RFC8210"/> and the protocol described in this
document.
</t>
<t>
<list style="symbols">
<t>
A new ASPA PDU type (<xref target="aspa"/>) has added to
support <xref target="I-D.ietf-sidrops-aspa-profile"/>.
</t>
<t>
A small section, <xref target="races"/>, has been added to
handle two ROA PDU race conditions, Break Before Make and
Shorter Prefix First.
</t>
<t>
The protocol version number incremented from 1 (one) to 2
(two) and the <xref target="version"/> section has been
updated accordingly.
</t>
</list>
</t>
</section>
</section>
<section anchor="Glossary" title="Glossary">
<t>
The following terms are used with special meaning.
<list style="hanging">
<t hangText="Global RPKI:">
The authoritative data of the RPKI are published in a
distributed set of servers at the IANA, Regional Internet
Registries (RIRs), National Internet Registries (NIRs),
and ISPs; see <xref target="RFC6481"/>.
</t>
<t hangText="Cache:">
A cache is a coalesced copy
of the published Global RPKI data, periodically fetched or
refreshed, directly or indirectly, using the
rsync protocol <xref target="RFC5781"/> or some
successor. Relying Party software is used to gather and
validate the distributed data of the RPKI into a cache.
Trusting this cache further is a matter between the
provider of the cache and a Relying Party.
</t>
<t hangText="Serial Number:">
"Serial Number" is a
32&nbhy;bit strictly increasing unsigned integer which wraps
from 2^32-1 to 0. It denotes the logical version of a
cache. A cache increments the value when it successfully
updates its data from a parent cache or from primary RPKI
data. While a cache is receiving updates, new incoming
data and implicit deletes are associated with the new
serial but MUST NOT be sent until the fetch is complete.
A Serial Number is not commensurate between different
caches or different protocol versions, nor need it be
maintained across resets of the cache server. See
<xref target="RFC1982"/> on DNS Serial Number Arithmetic
for too much detail on the topic.
</t>
<t hangText="Session ID:">
When a cache server is started, it generates a Session ID
to uniquely identify the instance of the cache and
to bind it to the sequence of Serial Numbers that cache
instance will generate. This allows the router to restart a
failed session knowing that the Serial Number it is using is
commensurate with that of the cache.
</t>
<t hangText="Payload PDU:">
A payload PDU is a protocol message which contains data for
use by the router, as opposed to a PDU which conveys the control
mechanisms of this protocol. Prefixes and Router Keys are
examples of payload PDUs.
</t>
</list>
</t>
</section>
<section anchor="Struct" title="Deployment Structure">
<t>
Deployment of the RPKI to reach routers has a three-level
structure as follows:
<list style="hanging">
<t hangText="Global RPKI:">
The authoritative data of the RPKI are published in a
distributed set of servers at the IANA, RIRs, NIRs, and
ISPs (see <xref target="RFC6481"/>).
</t>
<t hangText="Local Caches:">
Local caches are a local set of one or more collected and
verified caches of RPKI data. A Relying Party, e.g., router
or other client, MUST have a trust relationship with, and a
trusted transport channel to, any cache(s) it uses.
</t>
<t hangText="Routers:">
A router fetches data from a local cache using the protocol
described in this document. It is said to be a client of the
cache. There MAY be mechanisms for the router to assure
itself of the authenticity of the cache and to authenticate
itself to the cache (see <xref target="Transport"/>).
</t>
</list>
</t>
</section>
<section anchor="OpOvr" title="Operational Overview">
<t>
A router establishes and keeps open a connection to one or more
caches with which it has client/server relationships. It is
configured with a semi-ordered list of caches and establishes a
connection to the most preferred cache, or set of caches, which
accept the connections.
</t>
<t>
The router MUST choose the most preferred, by configuration,
cache or set of caches so that the operator may control load
on their caches and the Global RPKI.
</t>
<t>
Periodically, the router sends to the cache the most recent
Serial Number for which it has received data from that
cache, i.e., the router's current Serial Number, in the form of a
Serial Query. When a router establishes a new session with a
cache or wishes to reset a current relationship, it sends a
Reset Query.
</t>
<t>
The cache responds to the Serial Query with all data changes
which took place since the given Serial Number. This may be the
null set, in which case the End of Data PDU (<xref target="eod"/>)
is still sent. Note that the Serial Number comparison used to
determine "since the given Serial Number" MUST take wrap-around
into account; see <xref target="RFC1982"/>.
</t>
<t>
When the router has received all data records from the cache,
it sets its current Serial Number to that of the Serial Number
in the received End of Data PDU.
</t>
<t>
When the cache updates its database, it sends a Notify PDU to
every currently connected router. This is a hint
that now would be a good time for the router to poll for an
update, but it is only a hint. The protocol requires the router
to poll for updates periodically in any case.
</t>
<t>
Strictly speaking, a router could track a cache simply by
asking for a complete data set every time it updates, but this
would be very inefficient. The Serial-Number-based
incremental update mechanism allows an efficient transfer of
just the data records which have changed since the last update.
As with any update protocol based on incremental transfers,
the router must be prepared to fall back to a full transfer if
for any reason the cache is unable to provide the necessary
incremental data. Unlike some incremental transfer protocols,
this protocol requires the router to make an explicit request
to start the fallback process; this is deliberate, as the
cache has no way of knowing whether the router has also
established sessions with other caches that may be able to
provide better service.
</t>
<t>
As a cache server must evaluate certificates and ROAs (Route
Origin Authorizations; see <xref target="RFC6480"/>),
which are time dependent, servers' clocks MUST be correct to a
tolerance of approximately an hour.
</t>
</section>
<section anchor="pdus" title="Protocol Data Units (PDUs)">
<t>
The exchanges between the cache and the router are sequences of
exchanges of the following PDUs according to the rules described
in <xref target="protocol"/>.
</t>
<t>
Reserved fields (marked "zero" in PDU diagrams) MUST be zero
on transmission and MUST be ignored on receipt.
</t>
<section anchor="fields" title="Fields of a PDU">
<t>
PDUs contain the following data elements:
<list style="hanging">
<t hangText="Protocol Version:">
An 8-bit unsigned integer, currently 1, denoting the
version of this protocol.
</t>
<t hangText="PDU Type:">
An 8-bit unsigned integer, denoting the type of the PDU,
e.g., IPv4 Prefix.
</t>
<t hangText="Serial Number:">
The Serial Number of the RPKI cache when this set of PDUs
was received from an upstream cache server or gathered from
the Global RPKI. A cache increments its Serial Number when
completing a rigorously validated update from a parent cache
or the Global RPKI.
</t>
<t hangText="Session ID:">
A 16-bit unsigned integer.
When a cache server is started, it generates a Session
ID to identify the instance of the cache and to bind it
to the sequence of Serial Numbers that cache instance
will generate. This allows the router to restart a
failed session knowing that the Serial Number it is
using is commensurate with that of the cache. If, at
any time after the protocol version has been negotiated
(<xref target="version"/>), either the router or the
cache finds that the value of the Session ID is not the
same as the other's, the party which detects the mismatch
MUST immediately terminate the session with an Error
Report PDU with code 0 ("Corrupt Data"),
and the router MUST flush all data learned from that cache.
</t>
<t>
Note that sessions are specific to a particular protocol
version. That is, if a cache server supports multiple
versions of this protocol, happens to use the same
Session ID value for multiple protocol versions, and
further happens to use the same Serial Number values for
two or more sessions using the same Session ID but
different Protocol Version values, the Serial Numbers
are not commensurate. The full test for whether Serial
Numbers are commensurate requires comparing Protocol
Version, Session ID, and Serial Number. To reduce the
risk of confusion, cache servers SHOULD NOT use the same
Session ID across multiple protocol versions, but even
if they do, routers MUST treat sessions with different
Protocol Version fields as separate sessions even if
they do happen to have the same Session ID.
</t>
<t>
Should a cache erroneously reuse a Session ID so that a
router does not realize that the session has changed (old
Session ID and new Session ID have the same numeric value),
the router may become confused as to the content of the cache.
The time it takes the router to discover that it is confused
will depend on whether the Serial Numbers are also reused. If
the Serial Numbers in the old and new sessions are different
enough, the cache will respond to the router's Serial Query
with a Cache Reset, which will solve the problem. If,
however, the Serial Numbers are close, the cache may respond
with a Cache Response, which may not be enough to bring the
router into sync. In such cases, it's likely but not
certain that the router will detect some discrepancy between
the state that the cache expects and its own state. For
example, the Cache Response may tell the router to drop a
record which the router does not hold or may tell the
router to add a record which the router already has. In
such cases, a router will detect the error and reset the
session. The one case in which the router may stay out of
sync is when nothing in the Cache Response contradicts any
data currently held by the router.
</t>
<t>
Using persistent storage for the Session ID or a
clock-based scheme for generating Session IDs should
avoid the risk of Session ID collisions.
</t>
<t>
The Session ID might be a pseudorandom value, a
strictly increasing value if the cache has reliable
storage, et cetera. A seconds-since-epoch timestamp
value such as the POSIX time() function makes a good
Session ID value.
</t>
<t hangText="Length:">
A 32-bit unsigned integer which has as its value the count
of the bytes in the entire PDU, including the 8 bytes of
header which includes the length field.
</t>
<t hangText="Flags:">
The lowest-order bit of the Flags field is 1 for an
announcement and 0 for a withdrawal. For a Prefix PDU
(IPv4 or IPv6), the flag indicates whether this PDU
announces a new right to announce the prefix or
withdraws a previously announced right; a withdraw
effectively deletes one previously announced Prefix PDU
with the exact same Prefix, Length, Max-Len, and
Autonomous System Number (ASN). Similarly, for a Router
Key PDU, the flag indicates whether this PDU announces a
new Router Key or deletes one previously announced
Router Key PDU with the exact same AS Number,
subjectKeyIdentifier, and subjectPublicKeyInfo.
</t>
<t>
The remaining bits in the Flags field are reserved for
future use. In protocol version 1, they MUST be zero on
transmission and MUST be ignored on receipt.
</t>
<t hangText="Prefix Length:">
An 8-bit unsigned integer denoting the shortest prefix
allowed by the Prefix element.
</t>
<t hangText="Max Length:">
An 8-bit unsigned integer denoting the longest prefix
allowed by the Prefix element. This MUST NOT be less
than the Prefix Length element.
</t>
<t hangText="Prefix:">
The IPv4 or IPv6 prefix of the ROA.
</t>
<t hangText="Autonomous System Number:">
A 32-bit unsigned integer representing an ASN allowed to
announce a prefix or associated with a router key.
</t>
<t hangText="Subject Key Identifier:"> 20-octet
Subject Key Identifier (SKI) value of a router key, as
described in <xref target="RFC6487"/>.
</t>
<t hangText="Subject Public Key Info:"> A router key's
subjectPublicKeyInfo value, as described in
<xref target="RFC8208"/>. This is the
full ASN.1 DER encoding of the subjectPublicKeyInfo,
including the ASN.1 tag and length values of the
subjectPublicKeyInfo SEQUENCE.
</t>
<t hangText="Refresh Interval:">
Interval between normal cache polls.
See <xref target="timing"/>.
</t>
<t hangText="Retry Interval:">
Interval between cache poll retries after a failed cache poll.
See <xref target="timing"/>.
</t>
<t hangText="Expire Interval:">
Interval during which data fetched from a cache remains
valid in the absence of a successful subsequent cache poll.
See <xref target="timing"/>.
</t>
</list>
</t>
</section>
<section anchor="notify" title="Serial Notify">
<t>
The cache notifies the router that the cache has new data.
</t>
<t>
The Session ID reassures the router that the Serial Numbers
are commensurate, i.e., the cache session has not been
changed.
</t>
<t>
Upon receipt of a Serial Notify PDU, the router MAY issue an
immediate Serial Query (<xref target="serialquery"/>) or
Reset Query (<xref target="resetquery"/>) without waiting for
the Refresh Interval timer (see <xref target="timing"/>)
to expire.
</t>
<t>
Serial Notify is the only message that the cache can send
that is not in response to a message from the router.
</t>
<t>
If the router receives a Serial Notify PDU during the
initial startup period where the router and cache are still
negotiating to agree on a protocol version, the router
MUST simply ignore the Serial Notify PDU, even if the
Serial Notify PDU is for an unexpected protocol version.
See <xref target="version"/> for details.
</t>
<figure>
<artwork>
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 2 | 0 | |
+-------------------------------------------+
| |
| Length=12 |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
`-------------------------------------------'
</artwork>
</figure>
</section>
<section anchor="serialquery" title="Serial Query">
<t>
The router sends a Serial Query to ask the cache
for all announcements and withdrawals which have
occurred since the Serial Number specified in the Serial
Query.
</t>
<t>
The cache replies to this query with a Cache Response PDU
(<xref target="cacheresponse"/>) if the cache has a
(possibly null) record of the changes since the Serial Number
specified by the router, followed by zero or more payload
PDUs and an End Of Data PDU (<xref target="eod"/>).
</t>
<t>
When replying to a Serial Query, the cache MUST return the
minimum set of changes needed to bring the router into sync
with the cache. That is, if a particular prefix or router
key underwent multiple changes between the Serial Number
specified by the router and the cache's current Serial
Number, the cache MUST merge those changes to present the
simplest possible view of those changes to the router. In
general, this means that, for any particular prefix or
router key, the data stream will include at most one
withdrawal followed by at most one announcement, and if all
of the changes cancel out, the data stream will not mention
the prefix or router key at all.
</t>
<t>
The rationale for this approach is that the entire purpose of
the RPKI&nbhy;Router protocol is to offload work from the router
to the cache, and it should therefore be the cache's job to
simplify the change set, thus reducing work for the router.
</t>
<t>
If the cache does not have the data needed to update the
router, perhaps because its records do not go back to the
Serial Number in the Serial Query, then it responds with a
Cache Reset PDU (<xref target="cachereset"/>).
</t>
<t>
The Session ID tells the cache what instance the router
expects to ensure that the Serial Numbers are commensurate,
i.e., the cache session has not been changed.
</t>
<figure>
<artwork>
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 2 | 1 | |
+-------------------------------------------+
| |
| Length=12 |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
`-------------------------------------------'
</artwork>
</figure>
</section>
<section anchor="resetquery" title="Reset Query">
<t>
The router tells the cache that it wants to
receive the total active, current, non-withdrawn database.
The cache responds with a Cache Response PDU
(<xref target="cacheresponse"/>), followed by zero or more
payload PDUs and an End of Data PDU (<xref target="eod"/>).
</t>
<figure>
<artwork>
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | zero |
| 2 | 2 | |
+-------------------------------------------+
| |
| Length=8 |
| |
`-------------------------------------------'
</artwork>
</figure>
</section>
<section anchor="cacheresponse" title="Cache Response">
<t>
The cache responds to queries with zero or more payload
PDUs. When replying to a Serial Query
(<xref target="serialquery"/>), the cache sends the set of
announcements and withdrawals that have occurred since the
Serial Number sent by the client router. When replying to a
Reset Query (<xref target="resetquery"/>), the cache sends
the set of all data records it has; in this case, the
withdraw/announce field in the payload PDUs MUST have the
value 1 (announce).
</t>
<t>
In response to a Reset Query, the new value of the Session ID
tells the router the instance of the cache session for future
confirmation. In response to a Serial Query, the Session ID
being the same reassures the router that the Serial Numbers
are commensurate, i.e., the cache session has not been changed.
</t>
<figure>
<artwork>
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 2 | 3 | |
+-------------------------------------------+
| |
| Length=8 |
| |
`-------------------------------------------'
</artwork>
</figure>
</section>
<section anchor="ipv4" title="IPv4 Prefix">
<figure>
<artwork>
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | zero |
| 2 | 4 | |
+-------------------------------------------+
| |
| Length=20 |
| |
+-------------------------------------------+
| | Prefix | Max | |
| Flags | Length | Length | zero |
| | 0..32 | 0..32 | |
+-------------------------------------------+
| |
| IPv4 Prefix |
| |
+-------------------------------------------+
| |
| Autonomous System Number |
| |
`-------------------------------------------'
</artwork>
</figure>
<t>
The lowest-order bit of the Flags field is 1 for an
announcement and 0 for a withdrawal.
</t>
<t>
In the RPKI, nothing prevents a signing certificate from
issuing two identical ROAs. In this case, there would be no
semantic difference between the objects, merely a process
redundancy.
</t>
<t>
In the RPKI, there is also an actual need for what might
appear to a router as identical IPvX PDUs.
This can occur when an upstream certificate is being reissued
or there is an address ownership transfer up the validation
chain. The ROA would be identical in the router sense,
i.e., have the same {Prefix, Len, Max-Len, ASN}, but it would
have a different validation path in the RPKI. This is
important to the RPKI but not to the router.
</t>
<t>
The cache server MUST ensure that it has told the router
client to have one and only one IPvX PDU for a unique {Prefix,
Len, Max-Len, ASN} at any one point in time. Should the
router client receive an IPvX PDU with a {Prefix, Len,
Max-Len, ASN} identical to one it already has active, it
SHOULD raise a Duplicate Announcement Received error.
</t>
</section>
<section anchor="ipv6" title="IPv6 Prefix">
<figure>
<artwork>
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | zero |
| 2 | 6 | |
+-------------------------------------------+
| |
| Length=32 |
| |
+-------------------------------------------+
| | Prefix | Max | |
| Flags | Length | Length | zero |
| | 0..128 | 0..128 | |
+-------------------------------------------+
| |
+--- ---+
| |
+--- IPv6 Prefix ---+
| |
+--- ---+
| |
+-------------------------------------------+
| |
| Autonomous System Number |
| |
`-------------------------------------------'
</artwork>
</figure>
<t>
Analogous to the IPv4 Prefix PDU, it has 96 more bits and no magic.
</t>
</section>
<section anchor="eod" title="End of Data">
<t>
The cache tells the router it has no more data for the request.
</t>
<t>
The Session ID and Protocol Version MUST be the same as that of
the corresponding Cache Response which began the (possibly null)
sequence of payload PDUs.
</t>
<figure>
<artwork>
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 2 | 7 | |
+-------------------------------------------+
| |
| Length=24 |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
+-------------------------------------------+
| |
| Refresh Interval |
| |
+-------------------------------------------+
| |
| Retry Interval |
| |
+-------------------------------------------+
| |
| Expire Interval |
| |
`-------------------------------------------'
</artwork>
</figure>
<t>
The Refresh Interval, Retry Interval, and Expire Interval
are all 32-bit elapsed times measured in seconds. They express
the timing parameters which the cache expects the router to
use in deciding when to send subsequent Serial Query or
Reset Query PDUs to the cache.
See <xref target="timing"/> for an explanation of the use
and the range of allowed values for these parameters.
</t>
<t>Note that the End of Data PDU changed significantly between
versions 0 and 1. For version 0 compatibility, the following is
the version 0 End of Data PDU.</t>
<figure>
<artwork>
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Cache Nonce |
| 0 | 7 | |
+-------------------------------------------+
| |
| Length=12 |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
`-------------------------------------------'
</artwork>
</figure>
</section>
<section anchor="cachereset" title="Cache Reset">
<t>
The cache may respond to a Serial Query informing the router
that the cache cannot provide an incremental update
starting from the Serial Number specified by the router.
The router must decide whether to issue a Reset Query or
switch to a different cache.
</t>
<figure>
<artwork>
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | zero |
| 2 | 8 | |
+-------------------------------------------+
| |
| Length=8 |
| |
`-------------------------------------------'
</artwork>
</figure>
</section>
<section anchor="routerkey" title="Router Key">
<figure>
<artwork>
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | | |
| Version | Type | Flags | zero |
| 2 | 9 | | |
+-------------------------------------------+
| |
| Length |
| |
+-------------------------------------------+
| |
+--- ---+
| Subject Key Identifier |
+--- ---+
| |
+--- ---+
| (20 octets) |
+--- ---+
| |
+-------------------------------------------+
| |
| AS Number |
| |
+-------------------------------------------+
| |
| Subject Public Key Info |
| |
`-------------------------------------------'
</artwork>
</figure>
<t>
The lowest-order bit of the Flags field is 1 for an
announcement and 0 for a withdrawal.
</t>
<t>
The cache server MUST ensure that it has told the router
client to have one and only one Router Key PDU for a unique
{SKI, ASN, Subject Public Key} at any one point in time.
Should the router client receive a Router Key PDU with a
{SKI, ASN, Subject Public Key} identical to one it already
has active, it SHOULD raise a Duplicate Announcement
Received error.
</t>
<t>
Note that a particular ASN may appear in multiple Router Key
PDUs with different Subject Public Key values, while a
particular Subject Public Key value may appear in multiple
Router Key PDUs with different ASNs. In the interest of
keeping the announcement and withdrawal semantics as simple
as possible for the router, this protocol makes no attempt
to compress either of these cases.
</t>
<t>
Also note that it is possible, albeit very unlikely, for
multiple distinct Subject Public Key values to hash to the
same SKI. For this reason, implementations MUST compare
Subject Public Key values as well as SKIs when detecting
duplicate PDUs.
</t>
</section>
<section anchor="error" title="Error Report">
<t>
This PDU is used by either party to report an error to the
other.
</t>
<t>
Error reports are only sent as responses to other PDUs, not
to report errors in Error Report PDUs.
</t>
<t>
Error codes are described in <xref target="errorcodes"/>.
</t>
<t>
If the error is generic (e.g., "Internal Error") and not
associated with the PDU to which it is responding, the
Erroneous PDU field MUST be empty and the Length of
Encapsulated PDU field MUST be zero.
</t>
<t>
An Error Report PDU MUST NOT be sent for an Error Report PDU.
If an erroneous Error Report PDU is received, the session
SHOULD be dropped.
</t>
<t>
If the error is associated with a PDU of excessive length,
i.e., too long to be any legal PDU other than another Error
Report, or a possibly corrupt length, the Erroneous PDU field
MAY be truncated.
</t>
<t>
The diagnostic text is optional; if not present, the Length of
Error Text field MUST be zero. If error text is present, it
MUST be a string in UTF-8 encoding (see <xref target="RFC3629"/>).
</t>
<figure>
<artwork>
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Error Code |
| 2 | 10 | |
+-------------------------------------------+
| |
| Length |
| |
+-------------------------------------------+
| |
| Length of Encapsulated PDU |
| |
+-------------------------------------------+
| |
~ Erroneous PDU ~
| |
+-------------------------------------------+
| |
| Length of Error Text |
| |
+-------------------------------------------+
| |
| Arbitrary Text |
| of |
~ Error Diagnostic Message ~
| |
`-------------------------------------------'
</artwork>
</figure>
</section>
<section anchor="aspa" title="ASPA PDU">
<figure>
<artwork>
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | zero |
| 2 | 11 | |
+-------------------------------------------+
| |
| Length |
| |
+-------------------------------------------+
| | | |
| Flags | zero | Provider AS Count |
| | | |
+-------------------------------------------+
| |
| Customer Autonomous System Number |
| |
+-------------------------------------------+
| |
| Provider Autonomous System Numbers |
| |
~-------------------------------------------~
</artwork>
</figure>
<t>
The ASPA PDU is to support <xref
target="I-D.ietf-sidrops-aspa-profile"/>. An ASPA PDU
represents one single customer AS and its provider ASs for a
particular Address Family. Receipt of an ASPA PDU
announcement (Flag.Announce == 1) when the router already has
an ASPA PDU with the same Customer Autonomous System Number
and the same Address Family (see Flags field), replaces the
previous one. This is to avoid a race condition when a BGP
announcement is received between an withdrawn PDU and a new
announced PDU. Therefore, the cache MUST deliver the complete
data of an ASPA record in a single ASPA PDU.
</t>
<t>
The router should see at most one ASPA from a cache for a
particular Customer Autonomous System Number active at any
time. As a number of conditions in the global RPKI may
present multiple valid ASPA objects for a single customer to a
particular RP cache, this places a burden on the cache to form
the union of multiple ASPA records it has received from the
global RPKI into one ASPA PDU.
</t>
<t>
The Flags field is defined as follows:</t>
<figure>
<artwork>
Bit Bit Name
---- -------------------
0 AFI (IPv4 == 0, IPv6 == 1)
1 Announce == 1, Delete == 0
2-7 Reserved, must be zero
</artwork>
</figure>
<t>
The Provider AS Count is the number of 32-bit Provider
Autonomous System Numbers in the PDU.
</t>
<t>
The Customer Autonomous System Number is the 32-bit Autonomous
System Number of the customer which authenticated the PDU.
There MUST be one and only one ASPA for a Customer Autonomous
System Number active in the router at any time.
</t>
<t>
There are zero or more 32-bit Provider Autonomous System
Number fields as indicated in the Provider AS Count; see <xref
target="I-D.ietf-sidrops-aspa-profile"/>.
</t>
<t>
Receipt of an ASPA PDU with the Flags field indicating Delete
is an explicit withdraw from the router of the entire ASPA
data for that customer AS. While the Provider AS Count and
the Provider AS Numbers MUST BE ignored by the router when the
Flags field indicates a Delete, the cache SHOULD set the
Provider AS Count to zero, and have a null Provider AS Numbers
list.
</t>
</section>
</section>
<section anchor="timing" title="Protocol Timing Parameters">
<t>
Since the data the cache distributes via the RPKI-Router
protocol are retrieved from the Global RPKI system at intervals
which are only known to the cache, only the cache can really
know how frequently it makes sense for the router to poll the
cache, or how long the data are likely to remain valid (or, at
least, unchanged). For this reason, as well as to allow the
cache some control over the load placed on it by its client
routers, the End Of Data PDU includes three values that allow
the cache to communicate timing parameters to the router:
</t>
<t>
<list style="hanging">
<t hangText="Refresh Interval:">
This parameter tells the router how long to wait before
next attempting to poll the cache and between subsequent
attempts, using a Serial Query or Reset Query PDU. The
router SHOULD NOT poll the cache sooner than indicated by
this parameter. Note that receipt of a Serial Notify PDU
overrides this interval and suggests that the router issue
an immediate query without waiting for the Refresh
Interval to expire. Countdown for this timer starts upon
receipt of the containing End Of Data PDU.
<list style="hanging">
<t hangText="Minimum allowed value:">1 second.</t>
<t hangText="Maximum allowed value:">86400 seconds (1 day).</t>
<t hangText="Recommended default:">3600 seconds (1 hour).</t>
</list>
</t>
<t hangText="Retry Interval:">
This parameter tells the router how long to wait before
retrying a failed Serial Query or Reset Query. The router
SHOULD NOT retry sooner than indicated by this parameter.
Note that a protocol version mismatch overrides this
interval: if the router needs to downgrade to a lower
protocol version number, it MAY send the first Serial
Query or Reset Query immediately. Countdown for this
timer starts upon failure of the query and restarts after
each subsequent failure until a query succeeds.
<list style="hanging">
<t hangText="Minimum allowed value:">1 second.</t>
<t hangText="Maximum allowed value:">7200 seconds (2 hours).</t>
<t hangText="Recommended default:">600 seconds (10 minutes).</t>
</list>
</t>
<t hangText="Expire Interval:">
This parameter tells the router how long it can continue
to use the current version of the data while unable to
perform a successful subsequent query. The router MUST
NOT retain the data past the time indicated by this
parameter. Countdown for this timer starts upon receipt
of the containing End Of Data PDU.
<list style="hanging">
<t hangText="Minimum allowed value:">600 seconds (10 minutes).</t>
<t hangText="Maximum allowed value:">172800 seconds (2 days).</t>
<t hangText="Recommended default:">3600 seconds (1 hour).</t>
</list>
</t>
</list>
</t>
<t>
If the router has never issued a successful query against a
particular cache, it SHOULD retry periodically using the default
Retry Interval, above.
</t>
<t>
Caches MUST set Expire Interval to a value larger than
either Refresh Interval or Retry Interval.
</t>
</section>
<section anchor="version" title="Protocol Version Negotiation">
<t>
A router MUST start each transport connection by issuing either a
Reset Query or a Serial Query. This query will tell the cache
which version of this protocol the router implements.
</t>
<t>
If a cache which supports version N receives a query from a
router which specifies version Q &lt; N, the cache MUST downgrade
to protocol version Q <xref target="RFC6810"/> or <xref
target="RFC8210"/> or send a version 1 Error Report PDU with
Error Code 4 ("Unsupported Protocol Version") and terminate the
connection.
</t>
<t>
If a router which supports version N sends a query to a cache
which only supports version C &lt; N, one of two things will
happen:
<list style="numbers">
<t>
The cache may terminate the connection, perhaps with a
version 0 Error Report PDU. In this case, the router MAY
retry the connection using protocol version C.
</t>
<t>
The cache may reply with a version C response. In this
case, the router MUST either downgrade to version C or
terminate the connection.
</t>
</list>
</t>
<t>
In any of the downgraded combinations above, the new features of
the higher version will not be available, and all PDUs will have
the negotiated lower version number in their version fields.
</t>
<t>
If either party receives a PDU containing an unrecognized
Protocol Version (neither 0, 1, nor 2) during this negotiation,
it MUST either downgrade to a known version or terminate the
connection, with an Error Report PDU unless the received PDU is
itself an Error Report PDU.
</t>
<t>
The router MUST ignore any Serial Notify PDUs it might receive
from the cache during this initial startup period, regardless
of the Protocol Version field in the Serial Notify PDU. Since
Session ID and Serial Number values are specific to a
particular protocol version, the values in the notification
are not useful to the router. Even if these values were
meaningful, the only effect that processing the notification
would have would be to trigger exactly the same Reset Query or
Serial Query that the router has already sent as part of the
not-yet-complete version negotiation process, so there is
nothing to be gained by processing notifications until version
negotiation completes.
</t>
<t>
Caches SHOULD NOT send Serial Notify PDUs before version
negotiation completes. Routers, however, MUST handle such
notifications (by ignoring them) for backwards compatibility
with caches serving protocol version 0.
</t>
<t>
Once the cache and router have agreed upon a Protocol Version
via the negotiation process above, that version is stable for
the life of the session. See <xref target="fields"/> for a
discussion of the interaction between Protocol Version and
Session ID.
</t>
<t>
If either party receives a PDU for a different Protocol
Version once the above negotiation completes, that party MUST
drop the session; unless the PDU containing the unexpected
Protocol Version was itself an Error Report PDU, the party
dropping the session SHOULD send an Error Report with an error
code of 8 ("Unexpected Protocol Version").
</t>
</section>
<section anchor="protocol" title="Protocol Sequences">
<t>
The sequences of PDU transmissions fall into four
conversations as follows:
</t>
<section anchor="start" title="Start or Restart">
<figure>
<artwork>
Cache Router
~ ~
| &lt;----- Reset Query -------- | R requests data (or Serial Query)
| |
| ----- Cache Response -----&gt; | C confirms request
| ------- Payload PDU ------&gt; | C sends zero or more
| ------- Payload PDU ------&gt; | IPv4 Prefix, IPv6 Prefix,
| ------- Payload PDU ------&gt; | or Router Key PDUs
| ------- End of Data ------&gt; | C sends End of Data
| | and sends new serial
~ ~
</artwork>
</figure>
<t>
When a transport connection is first established, the router
MUST send either a Reset Query or a Serial Query. A Serial
Query would be appropriate if the router has significant
unexpired data from a broken session with the same cache and
remembers the Session ID of that session, in which case a
Serial Query containing the Session ID from the previous
session will allow the router to bring itself up to date
while ensuring that the Serial Numbers are commensurate and
that the router and cache are speaking compatible versions
of the protocol. In all other cases, the router lacks the
necessary data for fast resynchronization and therefore
MUST fall back to a Reset Query.
</t>
<t>
The Reset Query sequence is also used when the router
receives a Cache Reset, chooses a new cache, or fears that
it has otherwise lost its way.
</t>
<t>
See <xref target="version"/> for details on version
negotiation.
</t>
<t>
To limit the length of time a cache must keep the data
necessary to generate incremental updates, a router MUST
send either a Serial Query or a Reset Query periodically.
This also acts as a keep-alive at the application layer.
See <xref target="timing"/> for details on the required
polling frequency.
</t>
</section>
<section anchor="query" title="Typical Exchange">
<figure>
<artwork>
Cache Router
~ ~
| -------- Notify ----------&gt; | (optional)
| |
| &lt;----- Serial Query ------- | R requests data
| |
| ----- Cache Response -----&gt; | C confirms request
| ------- Payload PDU ------&gt; | C sends zero or more
| ------- Payload PDU ------&gt; | IPv4 Prefix, IPv6 Prefix,
| ------- Payload PDU ------&gt; | or Router Key PDUs
| ------- End of Data ------&gt; | C sends End of Data
| | and sends new serial
~ ~
</artwork>
</figure>
<t>
The cache server SHOULD send a Notify PDU with its current
Serial Number when the cache's serial changes, with the
expectation that the router MAY then issue a Serial Query
earlier than it otherwise might. This is analogous to DNS
NOTIFY in <xref target="RFC1996"/>. The cache MUST rate&nbhy;limit
Serial Notifies to no more frequently than one per minute.
</t>
<t>
When the transport layer is up and either a timer has gone
off in the router or the cache has sent a Notify PDU, the router
queries for new data by sending a Serial Query, and the cache
sends all data newer than the serial in the Serial Query.
</t>
<t>
To limit the length of time a cache must keep old withdraws,
a router MUST send either a Serial Query or a Reset Query
periodically. See <xref target="timing"/> for details on the
required polling frequency.
</t>
</section>
<section anchor="nodiff" title="No Incremental Update Available ">
<figure>
<artwork>
Cache Router
~ ~
| &lt;------ Serial Query ------ | R requests data
| ------- Cache Reset ------&gt; | C cannot supply update
| | from specified serial
| &lt;------ Reset Query ------- | R requests new data
| ----- Cache Response -----&gt; | C confirms request
| ------- Payload PDU ------&gt; | C sends zero or more
| ------- Payload PDU ------&gt; | IPv4 Prefix, IPv6 Prefix,
| ------- Payload PDU ------&gt; | or Router Key PDUs
| ------- End of Data ------&gt; | C sends End of Data
| | and sends new serial
~ ~
</artwork>
</figure>
<t>
The cache may respond to a Serial Query with a Cache Reset,
informing the router that the cache cannot supply an
incremental update from the Serial Number specified by the
router. This might be because the cache has lost state, or
because the router has waited too long between polls and the
cache has cleaned up old data that it no longer believes it
needs, or because the cache has run out of storage space and
had to expire some old data early. Regardless of how this
state arose, the cache replies with a Cache Reset to tell
the router that it cannot honor the request. When a router
receives this, the router SHOULD attempt to connect to any
more-preferred caches in its cache list. If there are
no more-preferred caches, it MUST issue a Reset Query and
get an entire new load from the cache.
</t>
</section>
<section anchor="nodata" title="Cache Has No Data Available">
<figure>
<artwork>
Cache Router
~ ~
| &lt;------ Serial Query ------ | R requests data
| ---- Error Report PDU ----&gt; | C No Data Available
~ ~
Cache Router
~ ~
| &lt;------ Reset Query ------- | R requests data
| ---- Error Report PDU ----&gt; | C No Data Available
~ ~
</artwork>
</figure>
<t>
The cache may respond to either a Serial Query or a Reset
Query informing the router that the cache cannot supply any
update at all. The most likely cause is that the cache has
lost state, perhaps due to a restart, and has not yet
recovered. While it is possible that a cache might go into
such a state without dropping any of its active sessions,
a router is more likely to see this behavior when it
initially connects and issues a Reset Query while the cache
is still rebuilding its database.
</t>
<t>
When a router receives this kind of error, the router
SHOULD attempt to connect to any other caches in its cache
list, in preference order. If no other caches are
available, the router MUST issue periodic Reset Queries
until it gets a new usable load from the cache.
</t>
</section>
</section>
<section anchor="Transport" title="Transport">
<t>
The transport-layer session between a router and a cache
carries the binary PDUs in a persistent session.
</t>
<t>
To prevent cache spoofing and DoS attacks by illegitimate
routers, it is highly desirable that the router and the cache
be authenticated to each other. Integrity protection for
payloads is also desirable to protect against
monkey-in-the-middle (MITM) attacks. Unfortunately, there is
no protocol to do so on all currently used platforms.
Therefore, as of the writing of this document, there is no
mandatory-to-implement transport which provides authentication
and integrity protection.
</t>
<t>
To reduce exposure to dropped but non-terminated sessions, both
caches and routers SHOULD enable keep-alives when available in
the chosen transport protocol.
</t>
<t>
It is expected that, when the TCP Authentication Option
(TCP-AO) <xref target="RFC5925"/> is available on all
platforms deployed by operators, it will become the
mandatory-to-implement transport.
</t>
<t>
Caches and routers MUST implement unprotected transport over
TCP using a port, rpki-rtr (323); see
<xref target="IANA"/>. Operators SHOULD use procedural means,
e.g., access control lists (ACLs), to reduce the exposure to
authentication issues.
</t>
<t>
If unprotected TCP is the transport, the cache and routers MUST be
on the same trusted and controlled network.
</t>
<t>
If available to the operator, caches and routers MUST use one
of the following more protected protocols:
</t>
<t><list style="symbols">
<t>
Caches and routers SHOULD use TCP-AO transport
<xref target="RFC5925"/> over the rpki-rtr port.
</t>
<t>
Caches and routers MAY use Secure Shell version 2 (SSHv2) transport
<xref target="RFC4252"/> using the normal SSH port. For an
example, see <xref target="SSH"/>.
</t>
<t>
Caches and routers MAY use TCP MD5 transport
<xref target="RFC2385"/> using the rpki-rtr port. Note that
TCP MD5 has been obsoleted by TCP-AO
<xref target="RFC5925"/>.
</t>
<t>
Caches and routers MAY use TCP over IPsec transport
<xref target="RFC4301"/> using the rpki-rtr port.
</t>
<t>
Caches and routers MAY use Transport Layer Security (TLS) transport
<xref target="RFC5246"/> using port rpki-rtr-tls (324); see
<xref target="IANA"/>.
</t>
</list></t>
<section anchor="SSH" title="SSH Transport">
<t>
To run over SSH, the client router first establishes an SSH
transport connection using the SSHv2 transport protocol, and
the client and server exchange keys for message integrity and
encryption. The client then invokes the "ssh-userauth"
service to authenticate the application, as described in the
SSH authentication protocol <xref target="RFC4252"/>.
Once the application has been successfully
authenticated, the client invokes the "ssh-connection"
service, also known as the SSH connection protocol.
</t>
<t>
After the ssh-connection service is established, the client
opens a channel of type "session", which results in an SSH
session.
</t>
<t>
Once the SSH session has been established, the application
invokes the application transport as an SSH subsystem called
"rpki-rtr". Subsystem support is a feature of SSHv2 and is not
included in SSHv1. Running this protocol as an SSH subsystem
avoids the need for the application to recognize shell prompts
or skip over extraneous information, such as a system message
that is sent at shell startup.
</t>
<t>
It is assumed that the router and cache have exchanged keys
out of band by some reasonably secured means.
</t>
<t>
Cache servers supporting SSH transport MUST accept RSA
authentication and SHOULD accept Elliptic Curve Digital
Signature Algorithm (ECDSA) authentication. User
authentication MUST be supported; host authentication MAY be
supported. Implementations MAY support password
authentication. Client routers SHOULD verify the public key
of the cache to avoid MITM attacks.
</t>
</section>
<section title="TLS Transport">
<t>
Client routers using TLS transport MUST present client-side
certificates to authenticate themselves to the cache in
order to allow the cache to manage the load by rejecting
connections from unauthorized routers. In principle, any
type of certificate and Certification Authority (CA) may be
used; however, in general, cache operators will wish to
create their own small-scale CA and issue certificates to
each authorized router. This simplifies credential
rollover; any unrevoked, unexpired certificate from the
proper CA may be used.
</t>
<t>
Certificates used to authenticate client routers in this
protocol MUST include a subjectAltName extension
<xref target="RFC5280"/>
containing one or more iPAddress identities; when
authenticating the router's certificate, the cache MUST check
the IP address of the TLS connection against these iPAddress
identities and SHOULD reject the connection if none of the
iPAddress identities match the connection.
</t>
<t>
Routers MUST also verify the cache's TLS server certificate,
using subjectAltName dNSName identities as described in
<xref target="RFC6125"/>, to avoid MITM attacks. The rules
and guidelines defined in <xref target="RFC6125"/> apply here,
with the following considerations:
</t>
<t>
<list style="symbols">
<t>
Support for the DNS-ID identifier type (that is, the dNSName
identity in the subjectAltName extension) is REQUIRED in
rpki-rtr server and client implementations which use TLS.
Certification authorities which issue rpki-rtr server
certificates MUST support the DNS-ID identifier type, and
the DNS-ID identifier type MUST be present in rpki-rtr
server certificates.
</t>
<t>
DNS names in rpki-rtr server certificates SHOULD NOT
contain the wildcard character "*".
</t>
<t>
rpki-rtr implementations which use TLS MUST NOT use
Common Name (CN-ID) identifiers; a CN field may be present
in the server certificate's subject name but MUST NOT be
used for authentication within the rules described in
<xref target="RFC6125"/>.
</t>
<t>
The client router MUST set its "reference identifier" to
the DNS name of the rpki-rtr cache.
</t>
</list>
</t>
</section>
<section title="TCP MD5 Transport">
<t>
If TCP MD5 is used, implementations MUST support key lengths
of at least 80 printable ASCII bytes, per Section 4.5 of
<xref target="RFC2385"/>. Implementations MUST also support
hexadecimal sequences of at least 32 characters, i.e.,
128 bits.
</t>
<t>
Key rollover with TCP MD5 is problematic. Cache servers
SHOULD support <xref target="RFC4808"/>.
</t>
</section>
<section title="TCP-AO Transport">
<t>
Implementations MUST support key lengths of at least 80
printable ASCII bytes. Implementations MUST also support
hexadecimal sequences of at least 32 characters, i.e., 128
bits. Message Authentication Code (MAC) lengths of at least
96 bits MUST be supported, per Section 5.1 of
<xref target="RFC5925"/>.
</t>
<t>
The cryptographic algorithms and associated parameters described in
<xref target="RFC5926"/> MUST be supported.
</t>
</section>
</section>
<section anchor="Setup" title="Router-Cache Setup">
<t>
A cache has the public authentication data for each router it
is configured to support.
</t>
<t>
A router may be configured to peer with a selection of caches,
and a cache may be configured to support a selection of routers.
Each must have the name of, and authentication data for, each
peer. In addition, in a router, this list has a non-unique
preference value for each server. This
preference merely denotes proximity, not trust, preferred
belief, et cetera. The client router attempts to establish
a session with each potential serving cache in preference order
and then starts to load data from the most preferred cache to which
it can connect and authenticate. The router's list of caches has
the following elements:
<list style="hanging">
<t hangText="Preference:">
An unsigned integer denoting the router's preference to
connect to that cache; the lower the value, the more preferred.
</t>
<t hangText="Name:">
The IP address or fully qualified domain name of the cache.
</t>
<t hangText="Cache Credential(s):">
Any credential (such as a public key) needed to
authenticate the cache's identity to the router.
</t>
<t hangText="Router Credential(s):">
Any credential (such as a private key or certificate)
needed to authenticate the router's identity to the cache.
</t>
</list>
</t>
<t>
Due to the distributed nature of the RPKI, caches simply
cannot be rigorously synchronous. A client may hold data from
multiple caches but MUST keep the data marked as to source, as
later updates MUST affect the correct data.
</t>
<t>
Just as there may be more than one covering ROA from a single
cache, there may be multiple covering ROAs from multiple caches.
The results are as described in
<xref target="RFC6811"/>.
</t>
<t>
If data from multiple caches are held, implementations MUST NOT
distinguish between data sources when performing validation of
BGP announcements.
</t>
<t>
When a more-preferred cache becomes available, if resources
allow, it would be prudent for the client to start fetching
from that cache.
</t>
<t>
The client SHOULD attempt to maintain at least one set of data,
regardless of whether it has chosen a different cache or
established a new connection to the previous cache.
</t>
<t>
A client MAY drop the data from a particular cache when it is
fully in sync with one or more other caches.
</t>
<t>
See <xref target="timing"/> for details on what to do when the
client is not able to refresh from a particular cache.
</t>
<t>
If a client loses connectivity to a cache it is using or
otherwise decides to switch to a new cache, it SHOULD retain the
data from the previous cache until it has a full set of data
from one or more other caches. Note that this may already be
true at the point of connection loss if the client has
connections to more than one cache.
</t>
</section>
<section anchor="races" title="ROA PDU Race Minimization">
<t>
When a cache is sending ROA PDUs to the router, especially during
an initial full load, two undesirable race conditions are
possible:
<list style="hanging">
<t hangText="Break Before Make:">
For some prefix P, an AS may announce two (or more) ROAs
because they are in the process of changing what provider AS
is announcing P. This is is a case of "make before break."
If a cache is feeding a router and sends the one not yet in
service a significant time before sending the one currently
in service, then BGP data could be marked invalid during the
interval. To minimize that interval, the cache SHOULD
announce all ROAs for the same prefix as close to
sequentially as possible.
</t>
<t hangText="Shorter Prefix First:">
If an AS has issued a ROA for P0, and another AS (likely
their customer) has issued a ROA for P1 which is a
sub-prefix of P0, a router which receives the ROA for P0
before that for P1 is likely to mark a BGP prefix P1
invalid. Therefore, the cache SHOULD announce the
sub-prefix P1 before the covering prefix P0.
</t>
</list>
</t>
</section>
<section anchor="Scenarios" title="Deployment Scenarios">
<t>
For illustration, we present three likely deployment
scenarios:
<list style="hanging">
<t hangText="Small End Site:">
The small multihomed end site may wish to outsource the
RPKI cache to one or more of their upstream ISPs. They
would exchange authentication material with the ISP using
some out-of-band mechanism, and their router(s) would
connect to the cache(s) of one or more upstream ISPs. The
ISPs would likely deploy caches intended for customer use
separately from the caches with which their own BGP
speakers peer.
</t>
<t hangText="Large End Site:">
A larger multihomed end site might run one or more caches,
arranging them in a hierarchy of client caches, each fetching
from a serving cache which is closer to the Global RPKI. They
might configure fallback peerings to upstream ISP caches.
</t>
<t hangText="ISP Backbone:">
A large ISP would likely have one or more redundant caches
in each major point of presence (PoP), and these caches
would fetch from each other in an ISP-dependent topology
so as not to place undue load on the Global RPKI.
</t>
</list>
</t>
<t>
Experience with large DNS cache deployments has shown that
complex topologies are ill-advised, as it is easy to make errors
in the graph, e.g., not maintain a loop-free condition.
</t>
<t>
Of course, these are illustrations, and there are other possible
deployment strategies. It is expected that minimizing load on
the Global RPKI servers will be a major consideration.
</t>
<t>
To keep load on Global RPKI services from unnecessary peaks, it
is recommended that primary caches which load from the
distributed Global RPKI not do so all at the same times, e.g., on
the hour. Choose a random time, perhaps the ISP's AS number
modulo 60, and jitter the inter-fetch timing.
</t>
</section>
<section anchor="errorcodes" title="Error Codes">
<t>
This section contains a preliminary list of error codes. The
authors expect additions to the list during development of
the initial implementations. There is an IANA registry where
valid error codes are listed; see <xref target="IANA"/>. Errors
which are considered fatal MUST cause the session to be
dropped.
<list style="hanging">
<t hangText="0: Corrupt Data (fatal):">
The receiver believes the received PDU to be corrupt in a
manner not specified by another error code.
</t>
<t hangText="1: Internal Error (fatal):">
The party reporting the error experienced some kind of
internal error unrelated to protocol operation (ran out of
memory, a coding assertion failed, et cetera).
</t>
<t hangText="2: No Data Available:">
The cache believes itself to be in good working order but
is unable to answer either a Serial Query or a Reset Query
because it has no useful data available at this time. This
is likely to be a temporary error and most likely indicates
that the cache has not yet completed pulling down an initial
current data set from the Global RPKI system after some kind
of event that invalidated whatever data it might have
previously held (reboot, network partition, et cetera).
</t>
<t hangText="3: Invalid Request (fatal):">
The cache server believes the client's request to be
invalid.
</t>
<t hangText="4: Unsupported Protocol Version (fatal):">
The Protocol Version is not known by the receiver of the
PDU.
</t>
<t hangText="5: Unsupported PDU Type (fatal):">
The PDU Type is not known by the receiver of the PDU.
</t>
<t hangText="6: Withdrawal of Unknown Record (fatal):">
The received PDU has Flag=0, but a matching record
({Prefix, Len, Max-Len, ASN} tuple for an IPvX PDU or
{SKI, ASN, Subject Public Key} tuple for a Router Key PDU)
does not exist in the receiver's database.
</t>
<t hangText="7: Duplicate Announcement Received (fatal):">
The received PDU has Flag=1, but a matching record
({Prefix, Len, Max-Len, ASN} tuple for an IPvX PDU or
{SKI, ASN, Subject Public Key} tuple for a Router Key PDU)
is already active in the router.
</t>
<t hangText="8: Unexpected Protocol Version (fatal):">
The received PDU has a Protocol Version field that differs
from the protocol version negotiated in
<xref target="version"/>.
</t>
</list>
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
As this document describes a security protocol, many aspects of
security interest are described in the relevant sections. This
section points out issues which may not be obvious in other
sections.
<list style="hanging">
<t hangText="Cache Validation:">
In order for a collection of caches as described in
<xref target="Scenarios"/> to guarantee a consistent view,
they need to be given consistent trust anchors to use in their
internal validation process. Distribution of a consistent
trust anchor is assumed to be out of band.
</t>
<t hangText="Cache Peer Identification:">
The router initiates a transport connection to a cache, which it
identifies by either IP address or fully qualified domain
name. Be aware that a DNS or address spoofing attack could
make the correct cache unreachable. No session would be
established, as the authorization keys would not match.
</t>
<t hangText="Transport Security:">
The RPKI relies on object, not server or transport, trust.
That is, the IANA root trust anchor is distributed to all
caches through some out-of-band means and can then be
used by each cache to validate certificates and ROAs all
the way down the tree. The inter-cache relationships are
based on this object security model; hence, the
inter-cache transport can be lightly protected.
</t>
<t>
However, this protocol document assumes that the routers cannot
do the validation cryptography. Hence, the last link, from
cache to router, is secured by server authentication and
transport-level security. This is dangerous, as server
authentication and transport have very different threat models
than object security.
</t>
<t>
So the strength of the trust relationship and the transport
between the router(s) and the cache(s) are critical. You're
betting your routing on this.
</t>
<t>
While we cannot say the cache must be on the same LAN, if
only due to the issue of an enterprise wanting to offload the
cache task to their upstream ISP(s), locality, trust, and
control are very critical issues here. The cache(s) really
SHOULD be as close, in the sense of controlled and protected
(against DDoS, MITM) transport, to the router(s) as possible.
It also SHOULD be topologically close so that a minimum of
validated routing data are needed to bootstrap a router's access
to a cache.
</t>
<t>
The identity of the cache server SHOULD be verified and
authenticated by the router client, and vice versa, before any
data are exchanged.
</t>
<t>
Transports which cannot provide the necessary authentication
and integrity (see <xref target="Transport"/>) must rely on
network design and operational controls to provide protection
against spoofing/corruption attacks. As pointed out in
<xref target="Transport"/>, TCP-AO is the long-term plan.
Protocols which provide integrity and authenticity SHOULD be
used, and if they cannot, i.e., TCP is used as the transport,
the router and cache MUST be on the same trusted, controlled
network.
</t>
</list>
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
This section only discusses updates required in the existing
IANA protocol registries to accommodate version 1 of this
protocol. See <xref target="RFC8210"/> for IANA considerations
from the original (version 0) protocol.
</t>
<t>
All existing entries in the IANA "rpki-rtr-pdu" registry
remain valid for protocol version 0. All of the PDU types
allowed in protocol version 0 are also allowed in protocol
version 1, with the addition of the new Router Key PDU. To
reduce the likelihood of confusion, the PDU number used by the
Router Key PDU in protocol version 1 is hereby registered as
reserved (and unused) in protocol version 0.
</t>
<t>
The policy for adding to the registry is RFC Required per
<xref target="RFC8126"/>; the document must be either Standards Track or
Experimental.
</t>
<t>
The "rpki-rtr-pdu" registry has been updated as follows:
</t>
<figure>
<artwork>
Protocol PDU
Version Type Description
-------- ---- ---------------
0-2 0 Serial Notify
0-2 1 Serial Query
0-2 2 Reset Query
0-2 3 Cache Response
0-2 4 IPv4 Prefix
0-2 6 IPv6 Prefix
0-2 7 End of Data
0-2 8 Cache Reset
0 9 Reserved
1-2 9 Router Key
0-2 10 Error Report
0-1 11 Reserved
2 11 ASPA
0-2 255 Reserved
</artwork>
</figure>
<t>
All previous entries in the IANA "rpki-rtr-error" registry
remain valid for all protocol versions. Protocol version 1
added one new error code:
</t>
<figure>
<artwork>
Error
Code Description
----- ---------------------------
8 Unexpected Protocol Version
</artwork>
</figure>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.1982.xml"?>
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.2385.xml"?>
<?rfc include="reference.RFC.3629.xml"?>
<?rfc include="reference.RFC.4252.xml"?>
<?rfc include="reference.RFC.4301.xml"?>
<?rfc include="reference.RFC.5246.xml"?>
<?rfc include="reference.RFC.5280.xml"?>
<?rfc include="reference.RFC.5925.xml"?>
<?rfc include="reference.RFC.5926.xml"?>
<?rfc include="reference.RFC.6125.xml"?>
<?rfc include="reference.RFC.6487.xml"?>
<?rfc include="reference.RFC.6810.xml"?>
<?rfc include="reference.RFC.6811.xml"?>
<?rfc include="reference.RFC.8126.xml"?>
<?rfc include="reference.RFC.8174.xml"?>
<?rfc include="reference.RFC.8208.xml"?>
<?rfc include="reference.RFC.8210.xml"?>
<?rfc include="reference.I-D.ietf-sidrops-aspa-profile.xml"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.1996.xml"?>
<?rfc include="reference.RFC.4808.xml"?>
<?rfc include="reference.RFC.5781.xml"?>
<?rfc include="reference.RFC.6480.xml"?>
<?rfc include="reference.RFC.6481.xml"?>
</references>
<section anchor="Acknowledgements" title="Acknowledgements" numbered="no">
<t>
The authors wish to thank Nils Bars, Steve Bellovin, Oliver
Borchert, Tim Bruijnzeels, Rex Fernando, Richard Hansen, Martin
Hoffmann, Paul Hoffman, Fabian Holler, Russ Housley, Pradosh
Mohapatra, Keyur Patel, David Mandelberg, Sandy Murphy, Robert
Raszuk, Andreas Reuter, Thomas Schmidt, John Scudder, Ruediger
Volk, Matthias Waehlisch, and David Ward. Particular thanks go
to Hannes Gredler for showing us the dangers of unnecessary
fields.
</t>
<t>
No doubt this list is incomplete. We apologize to any
contributor whose name we missed.
</t>
</section>
</back>
</rfc>
Reference in a new issue View git blame Copy permalink