The Resource Public Key Infrastructure (RPKI) to Router Protocol
Internet Initiative Japan5147 Crystal SpringsBainbridge IslandWashington98110US+1 206 780 0431 x1randy@psg.comDragon Research Labssra@hactrn.net
In order to verifiably validate the origin Autonomous Systems of BGP
announcements, routers need a simple but reliable mechanism to
receive Resource Public Key Infrastructure (RFC 6480) prefix origin
data from a trusted cache. This document describes a protocol to
deliver validated prefix origin data to routers.
In order to verifiably validate the origin Autonomous Systems
(ASes) of BGP announcements, routers need a simple but
reliable mechanism to receive Resource Public Key
Infrastructure (RPKI)
cryptographically validated prefix origin data from a trusted
cache. This document describes a protocol to deliver
validated prefix origin data to routers. The design is
intentionally constrained to be usable on much of the current
generation of ISP router platforms.
describes the deployment structure, and
then presents an operational overview.
The binary payloads of the protocol are formally described in
, and the expected PDU sequences are
described in . The transport protocol
options are described in .
details how routers and caches are
configured to connect and authenticate.
describes likely deployment
scenarios. The traditional security and IANA considerations end
the document.
The protocol is extensible in order to support new PDUs with
new semantics, if deployment experience indicates they are
needed. PDUs are versioned should deployment experience call
for change.
For an implementation (not interoperability) report, see
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
RFC 2119 only when they appear
in all upper case. They may also appear in lower or mixed
case as English words, without special meaning.
The following terms are used with special meaning.
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 .
A coalesced copy of the RPKI, which is periodically
fetched/refreshed directly or indirectly from the Global RPKI
using the protocol/tools. 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.
A 32-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. As a
cache is receiving, 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 caches, nor need it be maintained across resets of the
cache server. See on DNS Serial
Number Arithmetic for too much detail on the topic.
When a cache server is started, it generates a session
identifier 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.
Deployment of the RPKI to reach routers has a three-level
structure as follows:
The authoritative data of the RPKI are published in a
distributed set of servers, RPKI publication repositories,
e.g., the IANA, RIRs, NIRs, and ISPs, see
.
A local set of one or more collected and verified caches. A
relying party, e.g., router or other client, MUST have a trust
relationship with, and a trusted transport channel to, any
authoritative cache(s) it uses.
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.
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.
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.
Periodically, the router sends to the cache the Serial Number
of the highest numbered data it has received from that cache,
i.e., the router's current Serial Number. When a router
establishes a new connection to a cache, or wishes to reset a
current relationship, it sends a Reset Query.
The Cache responds with all data records which have Serial
Numbers greater than that in the router's query. This may be
the null set, in which case the End of Data PDU is still sent.
Note that 'greater' must take wrap-around into account,
see .
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 End of Data PDU.
When the cache updates its database, it sends a Notify
message 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 is only a hint. The protocol requires the router
to poll for updates periodically in any case.
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 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.
As a cache server must evaluate certificates and ROAs (Route
Origin Attestations; see ),
which are time dependent, servers' clocks MUST be correct to a
tolerance of approximately an hour.
The exchanges between the cache and the router are sequences of
exchanges of the following PDUs according to the rules described
in .
Fields with unspecified content MUST be zero on transmission
and MAY be ignored on receipt.
PDUs contain the following data elements:
An eight-bit unsigned integer, currently 1, denoting the
version of this protocol.
An eight-bit unsigned integer, denoting the type of the PDU,
e.g., IPv4 Prefix, etc.
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.
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, either the router or the cache finds the value
of the session identifier is not the same as the
other's, they MUST completely drop the session and the
router MUST flush all data learned from that cache.
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 same numeric value), the
router may become confused as to the content of the cache.
The time it takes the router to discover 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.
Using persistent storage for the session identifier or a
clock-based scheme for generating session identifiers should
avoid the risk of session identifier collisions.
The Session ID might be a pseudo-random value, a strictly
increasing value if the cache has reliable storage, etc.
A 32-bit unsigned integer which has as its value the count
of the bytes in the entire PDU, including the eight bytes of
header which end with the length field.
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 Numbers,
subjectKeyIdentifier, and subjectPublicKeyInfo.
An 8-bit unsigned integer denoting the shortest prefix
allowed for the prefix.
An 8-bit unsigned integer denoting the longest prefix
allowed by the prefix. This MUST NOT be less than the
Prefix Length element.
The IPv4 or IPv6 prefix of the ROA.
ASN allowed to announce this prefix, a 32-bit unsigned
integer.
Fields shown as zero or reserved MUST be zero. The value of
such a field MUST be ignored on receipt.
The cache notifies the router that the cache has new
data.
The Session ID reassures the router that the Serial Numbers
are commensurate, i.e., the cache session has not been
changed.
Upon receipt of a Serial Notify PDU, the router MAY issue an
immediate Serial Query or Reset Query without waiting for
the Refresh Interval timer to expire.
Serial Notify is the only message that the cache can send
that is not in response to a message from the router.
Serial Query: The router sends Serial Query to ask the cache
for all payload PDUs which have Serial Numbers higher than the
Serial Number in the Serial Query.
The cache replies to this query with a Cache Response PDU
() if the cache has a, possibly
null, record of the changes since the Serial Number specified
by the router. If there have been no changes since the router
last queried, the cache sends an End Of Data PDU.
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 ().
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.
Reset Query: 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
().
Cache Response: The cache responds with zero or more payload
PDUs. When replying to a Serial Query request
(), the cache sends the set of all
data records it has with Serial Numbers greater than that sent
by the client router. When replying to a Reset Query, 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).
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 changed.
The lowest order bit of the Flags field is 1 for an
announcement and 0 for a withdrawal.
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.
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 a
different validation path in the RPKI. This is important to
the RPKI, but not to the router.
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.
Analogous to the IPv4 Prefix PDU, it has 96 more bits and no magic.
End of Data: The cache tells the router it has no more data for the
request.
The Session ID MUST be the same as that of the corresponding
Cache Response which began the, possibly null, sequence of
data PDUs.
The Refresh Interval, Retry Interval, and Expire Interval
are all 32-bit elapsed times measured in seconds, and
express the timing parameters that the cache expects the
router to use to decide when next to send the cache another
Serial Query or Update Query PDU. See
for an explanation of the use and
the range of allowed values for these parameters.
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.
In addition to the normal boilerplate fields of an
RPKI-Router PDU, the Router Key PDU has the following
fields.
contains one or more (32-bit)
Autonomous System Numbers. The number of ASNs is
specified in the AS Count field.
is the 20-octet
subjectKeyIdentifier (SKI) value for the Router Key, as
described in .
is the Router Key's
subjectPublicKeyInfo as described in
. This is the
full ASN.1 DER encoding of the subjectPublicKeyInfo,
including the ASN.1 tag and length values of the
subjectPublicKeyInfo SEQUENCE.
This PDU is used by either party to report an error to the
other.
Error reports are only sent as responses to other PDUs.
The Error Code is described in
.
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.
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.
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.
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
).
Since the data the cache distributes via the rpki-rtr 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 router to communicate timing parameters to the router.
This parameter tells the router how long to wait before
next attempting to poll the cache, using a Serial Query or
Reset Query PDU. Note that receipt of a Serial Notify PDU
overrides this interval and allows the router to 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.
120 seconds (two minutes).86400 seconds (one day).3600 seconds (one hour).
This parameter tells the router how long to wait before
retrying a failed Serial Query or Reset Query. Countdown
for this timer starts upon failure of the query, and
restarts after each subsequent failure until a query
succeeds.
120 seconds (two minutes).7200 seconds (two hours).600 seconds (ten minutes).
This parameter tells the router how long it can continue
to use the current version of the data while unable to
perform a sucessful query. Countdown for this timer
starts upon receipt of the containing End Of Data PDU.
600 seconds (ten minutes).172800 seconds (two days).7200 seconds (two hours).
If the router has never issued a succesful query against a
particular cache, it retry periodically using the default
Retry Interval, above.
The sequences of PDU transmissions fall into three
conversations as follows:
When a transport session is first established, the router
MAY send a Reset Query and the cache responds with a data
sequence of all data it contains.
Alternatively, if the router has significant unexpired data
from a broken session with the same cache, it MAY start with a
Serial Query containing the Session ID from the previous
session to ensure the Serial Numbers are commensurate.
This 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.
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 for details on the required
polling frequency.
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 . The cache MUST rate limit
Serial Notifies to no more frequently than one per minute.
When the transport layer is up and either a timer has gone
off in the router, or the cache has sent a Notify, 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.
To limit the length of time a cache must keep old withdraws, a
router MUST send either a Serial Query or a Reset Query
periodially. See for details on the
required polling frequency.
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.
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.
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.
The transport-layer session between a router and a cache
carries the binary PDUs in a persistent session.
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.
To reduce exposure to dropped but non-terminated sessions, both
caches and routers SHOULD enable keep-alives when available in
the chosen transport protocol.
It is expected that, when the TCP Authentication Option
(TCP-AO) is available on all
platforms deployed by operators, it will become the
mandatory-to-implement transport.
Caches and routers MUST implement unprotected transport over
TCP using a port, rpki-rtr (323); see
. Operators SHOULD use procedural means,
e.g., access control lists (ACLs), to reduce the exposure to
authentication issues.
Caches and routers SHOULD use TCP-AO, SSHv2, TCP MD5, or IPsec
transport.
If unprotected TCP is the transport, the cache and routers MUST be
on the same trusted and controlled network.
If available to the operator, caches and routers MUST use one
of the following more protected protocols.
Caches and routers SHOULD use TCP-AO transport
over the rpki-rtr port.
Caches and routers MAY use SSHv2 transport
using a the normal SSH port. For an
example, see .
Caches and routers MAY use TCP MD5 transport
using the rpki-rtr port. Note that
TCP MD5 has been obsoleted by TCP-AO
.
Caches and routers MAY use IPsec transport
using the rpki-rtr port.
Caches and routers MAY use TLS transport
using a port, rpki-rtr-tls (324); see
.
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 .
Once the application has been successfully
authenticated, the client invokes the "ssh-connection"
service, also known as the SSH connection protocol.
After the ssh-connection service is established, the client
opens a channel of type "session", which results in an SSH
session.
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 SSH version 2
(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 start-up.
It is assumed that the router and cache have exchanged keys
out of band by some reasonably secured means.
Cache servers supporting SSH transport MUST accept RSA and
Digital Signature Algorithm (DSA) 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
monkey-in-the-middle attacks.
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 certificate 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.
Certificates used to authenticate client routers in this
protocol MUST include a subjectAltName extension [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.
Routers MUST also verify the cache's TLS server certificate,
using subjectAltName dNSName identities as described in
[RFC6125], to avoid monkey-in-the-middle attacks. The rules
and guidelines defined in [RFC6125] apply here, with the
following considerations:
Support for 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.
DNS names in rpki-rtr server certificates SHOULD NOT
contain the wildcard character "*".
rpki-rtr implementations which use TLS MUST NOT use 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
.
The client router MUST set its "reference identifier" to
the DNS name of the rpki-rtr cache.
If TCP MD5 is used, implementations MUST support key lengths
of at least 80 printable ASCII bytes, per Section 4.5 of
. Implementations MUST also support
hexadecimal sequences of at least 32 characters, i.e., 128
bits.
Key rollover with TCP MD5 is problematic. Cache servers
SHOULD support .
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
.
The cryptographic algorithms and associcated parameters described in
MUST be supported.
A cache has the public authentication data for each router it
is configured to support.
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, etc. 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:
An unsigned integer denoting the router's preference to
connect to that cache; the lower the value, the more
preferred.
The IP address or fully qualified domain name of the cache.
Any needed public key of the cache.
Any needed private key or certificate of this client.
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.
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
.
If data from multiple caches are held, implementations MUST NOT
distinguish between data sources when performing validation.
When a more preferred cache becomes available, if resources
allow, it would be prudent for the client to start fetching
from that cache.
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.
A client MAY drop the data from a particular cache when it is
fully in sync with one or more other caches.
A client SHOULD delete the data from a cache when it has been
unable to refresh from that cache for a configurable timer
value. The default for that value is twice the polling period
for that cache.
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.
For illustration, we present three likely deployment
scenarios.
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.
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 fall-back peerings to upstream ISP caches.
A large ISP would likely have one or more redundant caches
in each major pointer 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.
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.
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.
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.
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 . Errors
which are considered fatal SHOULD cause the session to be
dropped.
The receiver believes the received PDU to be corrupt in a
manner not specified by other error codes.
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).
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).
The cache server believes the client's request to be
invalid.
The Protocol Version is not known by the receiver of the
PDU.
The PDU Type is not known by the receiver of the PDU.
The received PDU has Flag=0 but a record for the {Prefix,
Len, Max-Len, ASN} tuple does not exist in the receiver's
database.
The received PDU has an identical {Prefix, Len, Max-Len, ASN}
tuple as a PDU which is still active in the router.
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.
In order for a collection of caches as described in
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.
The router initiates a transport session 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.
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.
But, 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.
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.
While we cannot say the cache must be on the same LAN, if
only due to the issue of an enterprise wanting to off-load 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.
The identity of the cache server SHOULD be verified and
authenticated by the router client, and vice versa, before any
data are exchanged.
Transports which cannot provide the necessary authentication
and integrity (see ) must rely on
network design and operational controls to provide protection
against spoofing/corruption attacks. As pointed out in
, 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.
IANA has assigned "well-known" TCP Port
Numbers to the RPKI-Router Protocol for the following, see
:
IANA has created a registry for tuples of Protocol Version /
PDU Type, each of which may range from 0 to 255. The name of
the registry is "rpki-rtr-pdu". The policy for adding to the
registry is RFC Required per , either
Standards Track or Experimental. The initial entries are as
follows:
IANA has created a registry for Error Codes 0 to 255. The
name of the registry is "rpki-rtr-error". The policy for
adding to the registry is Expert Review per
, where the responsible IESG Area
Director should appoint the Expert Reviewer. The initial
entries are as follows:
IANA has added an SSH Connection Protocol Subsystem Name, as
defined in , of "rpki-rtr".
The authors wish to thank Steve Bellovin, Rex Fernando, Paul
Hoffman, Russ Housley, Pradosh Mohapatra, Keyur Patel, Sandy
Murphy, Robert Raszuk, John Scudder, Ruediger Volk, and David
Ward. Particular thanks go to Hannes Gredler for showing us the
dangers of unnecessary fields.
Serial Number ArithmeticSNAdomainnamesystemDNSThe DNS has long relied upon serial number arithmetic, a concept which has never really been defined, certainly not in an IETF document, though which has been widely understood. This memo supplies the missing definition. It is intended to update RFC1034 and RFC1035. [STANDARDS-TRACK]Key words for use in RFCs to Indicate Requirement LevelsStandardsTrackDocumentsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Protection of BGP Sessions via the TCP MD5 Signature OptionbordergatewayprotocoltransmissioncontrolmessagedigestalgorithmThis memo describes a TCP extension to enhance security for BGP. [STANDARDS-TRACK]Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documentsdefinitionsoperationThis document provides general guidelines to assist the authors of Reliable Multicast Transport (RMT) building block and protocol instantiation definitions. The purpose of these guidelines is to ensure that any building block and protocol instantiation definitions produced contain sufficient information to fully explain their operation and use. In addition these guidelines provide directions to specify modular and clearly defined RMT building blocks and protocol instantiations that can be refined and augmented to safely create new protocols for use in new scenarios for which any existing protocols were not designed. This memo provides information for the Internet community.The Secure Shell (SSH) Protocol Assigned Numbersremote loginThis document defines the instructions to the IANA and the initial state of the IANA assigned numbers for the Secure Shell (SSH) protocol. It is intended only for the initialization of the IANA registries referenced in the set of SSH documents. [STANDARDS-TRACK]The Secure Shell (SSH) Authentication Protocolremote loginpublic keypasswordhost-based client authenticationThe Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK]Security Architecture for the Internet ProtocolIPSECipsecauthenticationencapsulationIPIPv4IPv6IP-layerip authentication headerip securityIPsecconfidentialityauthentication integrityanti-replayahespencapsulating security payloadikeinternet key exchangeikev2esnextended sequence numberThis document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK]Guidelines for Writing an IANA Considerations Section in RFCsinternet assigned numbers authorityvaluesimplementationscode pointprotocol constantprotocol parameterMany protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA). In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA. This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.The Transport Layer Security (TLS) Protocol Version 1.2ideainternational data algorithmsymmetrictransport protocol layerauthenticationprivacyThis document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]The TCP Authentication Optiontransmission control protocolbordergatewayprotocoltransmission control messagedigestalgorithmThis document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK]Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)transmission control protocolThe TCP Authentication Option (TCP-AO) relies on security algorithms to provide authentication between two end-points. There are many such algorithms available, and two TCP-AO systems cannot interoperate unless they are using the same algorithms. This document specifies the algorithms and attributes that can be used in TCP-AO's current manual keying mechanism and provides the interface for future message authentication codes (MACs). [STANDARDS-TRACK]Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions. [STANDARDS-TRACK]A Profile for X.509 PKIX Resource CertificatesrpkiResource Public Key InfrastructureInternet Number ResourcesINRThis document defines a standard profile for X.509 certificates for the purpose of supporting validation of assertions of "right-of-use" of Internet Number Resources (INRs). The certificates issued under this profile are used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI). This document also specifies profiles for the format of certificate requests and specifies the Relying Party RPKI certificate path validation procedure. [STANDARDS-TRACK]BGP Prefix Origin ValidationSIDRsecurityTo help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination Autonomous System (AS) of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. [STANDARDS-TRACK]BGP Algorithms, Key Formats, & Signature FormatsThe rsync URI SchemersyncuriThis document specifies the rsync Uniform Resource Identifier (URI) scheme. This document is not an Internet Standards Track specification; it is published for informational purposes.RPKI Router Implementation ReportAn Infrastructure to Support Secure Internet RoutingRPKIBGPROAThis document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes.A Profile for Resource Certificate Repository StructurerpkiResource Public Key InfrastructureThis document defines a profile for the structure of the Resource Public Key Infrastructure (RPKI) distributed repository. Each individual repository publication point is a directory that contains files that correspond to X.509/PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile defines the object (file) naming scheme, the contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and to facilitate certification path construction. [STANDARDS-TRACK]A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)DNS-NOTIFYDomainNameSystemThis memo describes the NOTIFY opcode for DNS, by which a master server advises a set of slave servers that the master's data has been changed and that a query should be initiated to discover the new data. [STANDARDS-TRACK]Key Change Strategies for TCP-MD5bgpborder gateway protocolThe TCP-MD5 option is most commonly used to secure BGP sessions between routers. However, changing the long-term key is difficult, since the change needs to be synchronized between different organizations. We describe single-ended strategies that will permit (mostly) unsynchronized key changes. This memo provides information for the Internet community.