One document matched: draft-ietf-sidr-rpki-rtr-rfc6810-bis-05.xml
<?xml version="1.0"?>
<?rfc comments="yes"?><?rfc compact="yes"?><?rfc inline="yes"?><?rfc sortrefs="yes"?><?rfc subcompact="no"?><?rfc symrefs="yes"?><?rfc toc="yes"?><?rfc tocdepth="3"?><?rfc tocindent="yes"?><?rfc tocompact="yes"?><rfc category="std" docName="draft-ietf-sidr-rpki-rtr-rfc6810-bis-05" ipr="trust200902" updates="6810">
<front>
<title abbrev="RPKI-Router Protocol">
The Resource Public Key Infrastructure (RPKI) to Router Protocol
</title>
<author fullname="Randy Bush" initials="R." surname="Bush">
<organization>Internet Initiative Japan</organization>
<address>
<postal>
<street>5147 Crystal Springs</street>
<city>Bainbridge Island</city>
<region>Washington</region>
<code>98110</code>
<country>US</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 validated prefix origin data and router keys to
routers.
</t>
<t>
This document describes version 1 of the rpki-rtr protocol.
</t>
</abstract>
</front>
<middle>
<section anchor="Intro" title="Introduction">
<t>
In order to verifiably validate the origin Autonomous Systems
(ASes) 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 validated prefix origin data and router keys to
routers. The design is intentionally constrained to be usable
on much of the current generation of ISP router platforms.
</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 they are
needed. PDUs are versioned should deployment experience call
for change.
</t>
<t>
For an implementation (not interoperability) report on the use of
this protocol with prefix origin data, see
<xref target="RFC7128"/>.
</t>
<section title="Requirements Language">
<t>
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
<xref target="RFC2119">RFC 2119</xref> only when they appear
in all upper case. They may also appear in lower or mixed
case as English words, without special meaning.
</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 coalesced copy of the published Global RPKI data,
periodically fetched or refreshed, directly or indirectly,
using the <xref target="RFC5781"/> protocol or some
successor protocol. 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:">
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. 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 protocol message which contains data for use by the
router, as opposed to a PDU which just conveys the
semantics 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, RPKI publication repositories,
e.g., by the IANA, RIRs, NIRs, and ISPs (see
<xref target="RFC6481"/>).
</t>
<t hangText="Local Caches:">
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
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.
</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 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 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 End of Data PDU.
</t>
<t>
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.
</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 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 Attestations; 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 SHOULD 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 eight-bit unsigned integer, currently 1, denoting the
version of this protocol.
</t>
<t hangText="PDU Type:">
An eight-bit unsigned integer, denoting the type of the PDU,
e.g., IPv4 Prefix, etc.
</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 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"),
<!--
Should this become a new error code, "Unexpected
Session ID" ?
-->
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 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.
</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 pseudo-random value, a strictly
increasing value if the cache has reliable storage, etc.
</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 eight bytes of
header which end with 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 0 on
transmission and SHOULD be ignored on receipt.
</t>
<t hangText="Prefix Length:">
An 8-bit unsigned integer denoting the shortest prefix
allowed for the prefix.
</t>
<t hangText="Max Length:">
An 8-bit unsigned integer denoting the longest prefix
allowed by the prefix. 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="I-D.ietf-sidr-bgpsec-algs"/>. 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="Zero:">
Fields shown as zero MUST be zero on transmission. The
value of such a field SHOULD be ignored on receipt.
</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 start-up period where the router and cache are still
negotiating to agree on a protocol version, the router
SHOULD 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 |
| 1 | 0 | |
+-------------------------------------------+
| |
| Length=12 |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
`-------------------------------------------'
</artwork>
</figure>
</section>
<section anchor="serialquery" title="Serial Query">
<t>
The router sends 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-rtr 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 |
| 1 | 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 |
| 1 | 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 changed.
</t>
<figure>
<artwork>
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Session ID |
| 1 | 3 | |
+-------------------------------------------+
| |
| Length=8 |
| |
`-------------------------------------------'
</artwork>
</figure>
</section>
<section anchor="ipv4" title="IPv4 Prefix">
<figure>
<artwork>
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | zero |
| 1 | 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 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 |
| 1 | 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 |
| 1 | 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, 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 Reset Query PDU. See
<xref target="timing"/> for an explanation of the use and
the range of allowed values for these parameters.
</t>
</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 |
| 1 | 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 |
| 1 | 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.
</t>
<t>
The Error Code is 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="RFC3269"/>).
</t>
<figure>
<artwork>
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Error Code |
| 1 | 10 | |
+-------------------------------------------+
| |
| Length |
| |
+-------------------------------------------+
| |
| Length of Encapsulated PDU |
| |
+-------------------------------------------+
| |
~ Copy of Erroneous PDU ~
| |
+-------------------------------------------+
| |
| Length of Error Text |
| |
+-------------------------------------------+
| |
| Arbitrary Text |
| of |
~ Error Diagnostic Message ~
| |
`-------------------------------------------'
</artwork>
</figure>
</section>
</section>
<section anchor="timing" title="Protocol Timing Parameters">
<t>
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 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, 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
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.
<list style="hanging">
<t hangText="Minimum allowed value:">1 second.</t>
<t hangText="Maximum allowed value:">86400 seconds (one day).</t>
<t hangText="Recommended default:">3600 seconds (one 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 (two hours).</t>
<t hangText="Recommended default:">600 seconds (ten 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 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 (ten minutes).</t>
<t hangText="Maximum allowed value:">172800 seconds (two days).</t>
<t hangText="Recommended default:">7200 seconds (two hours).</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>
</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 1 receives a query from a
router which specifies version 0, the cache MUST downgrade to
protocol version 0 <xref target="RFC6810"/> 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 1 sends a query to a cache
which only supports version 0, 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 0.
</t>
<t>
The cache may reply with a version 0 response. In this
case the router MUST either downgrade to version 0 or
terminate the connection.
</t>
</list>
</t>
<t>
In any of the downgraded combinations above, the new features of
version 1 will not be available.
</t>
<t>
If either party receives a PDU containing an unrecognized
Protocol Version (neither 0 nor 1) 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 start-up 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. Note, however, that routers 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 three
conversations as follows:
</t>
<section anchor="start" title="Start or Restart">
<figure>
<artwork>
Cache Router
~ ~
| <----- Reset Query -------- | R requests data (or Serial Query)
| |
| ----- Cache Response -----> | C confirms request
| ------- Payload PDU ------> | C sends zero or more
| ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix,
| ------- Payload PDU ------> | or Router Key PDUs
| ------- End of Data ------> | C sends End of Data
| | and sends new serial
~ ~
</artwork>
</figure>
<t>
When a transport connection is first established, the router
MAY send a Reset Query and the cache responds with a data
sequence of all data it contains.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
The router MUST send either a Reset Query or a Serial Query
when starting a transport connection, in order to confirm that
router and cache are speaking compatible versions of the
protocol. 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 ----------> | (optional)
| |
| <----- Serial Query ------- | R requests data
| |
| ----- Cache Response -----> | C confirms request
| ------- Payload PDU ------> | C sends zero or more
| ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix,
| ------- Payload PDU ------> | or Router Key PDUs
| ------- End of Data ------> | 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 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, 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
~ ~
| <----- Serial Query ------ | R requests data
| ------- Cache Reset ------> | C cannot supply update
| | from specified serial
| <------ Reset Query ------- | R requests new data
| ----- Cache Response -----> | C confirms request
| ------- Payload PDU ------> | C sends zero or more
| ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix,
| ------- Payload PDU ------> | or Router Key PDUs
| ------- End of Data ------> | 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
~ ~
| <----- Serial Query ------ | R requests data
| ---- Error Report PDU ----> | C No Data Available
~ ~
Cache Router
~ ~
| <----- Reset Query ------- | R requests data
| ---- Error Report PDU ----> | 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>
Caches and routers SHOULD use TCP-AO, SSHv2, TCP MD5, or IPsec
transport.
</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>
Caches and routers SHOULD use TCP-AO transport
<xref target="RFC5925"/> over the rpki-rtr port.
</t>
<t>
Caches and routers MAY use 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 TLS transport
<xref target="RFC5246"/> using a port, rpki-rtr-tls (324); see
<xref target="IANA"/>.
</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 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.
</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 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.
</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 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.
</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
[RFC6125], to avoid monkey-in-the-middle attacks. The rules
and guidelines defined in [RFC6125] apply here, with the
following considerations:
</t>
<t>
<list style="empty">
<t>
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.
</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 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, 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:
<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="Key:">
Any needed public key of the cache.
</t>
<t hangText="MyKey:">
Any needed private key or certificate of this client.
</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.
</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="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 fall-back 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 SHOULD 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, {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, {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 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.
</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="RFC6810"/> 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="RFC5226"/>, either Standards Track or
Experimental.
</t>
<t>
Assuming that the registry allows range notation in the
Protocol Version field, the updated "rpki-rtr-pdu" registry
will be:
</t>
<figure>
<artwork>
Protocol PDU
Version Type Description
-------- ---- ---------------
0-1 0 Serial Notify
0-1 1 Serial Query
0-1 2 Reset Query
0-1 3 Cache Response
0-1 4 IPv4 Prefix
0-1 6 IPv6 Prefix
0-1 7 End of Data
0-1 8 Cache Reset
0 9 Reserved
1 9 Router Key
0-1 10 Error Report
0-1 255 Reserved
</artwork>
</figure>
<t>
All existing entries in the IANA "rpki-rtr-error" registry
remain valid for all protocol versions. Protocol version 1
adds one new error code:
</t>
<figure>
<artwork>
Error
Code Description
----- ----------------
8 Unexpected Protocol Version
</artwork>
</figure>
</section>
<section anchor="Acknowledgments" title="Acknowledgments">
<t>
The authors wish to thank
Nils Bars,
Steve Bellovin,
Tim Bruijnzeels,
Rex Fernando,
Richard Hansen,
Paul Hoffman,
Fabian Holler,
Russ Housley,
Pradosh Mohapatra,
Keyur Patel,
David Mandelberg,
Sandy Murphy,
Robert Raszuk,
Andreas Reuter,
Thomas C. 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>
</middle>
<back>
<references title="Normative References">
<!-- Begin inclusion: reference.RFC.1982.xml --><reference anchor="RFC1982">
<front>
<title>Serial Number Arithmetic</title>
<author fullname="R. Elz" initials="R." surname="Elz">
<organization/>
</author>
<author fullname="R. Bush" initials="R." surname="Bush">
<organization/>
</author>
<date month="August" year="1996"/>
<keyword>SNA</keyword>
<keyword>domain</keyword>
<keyword>name</keyword>
<keyword>system</keyword>
<keyword>DNS</keyword>
<abstract>
<t>The 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]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="1982"/>
<format type="TXT" octets="14440" target="http://www.rfc-editor.org/rfc/rfc1982.txt"/>
<!-- updates RFC1034 RFC1035 -->
<!-- current-status PROPOSED STANDARD -->
<!-- publication-status PROPOSED STANDARD -->
</reference><!-- End inclusion: reference.RFC.1982.xml -->
<!-- Begin inclusion: reference.RFC.2119.xml --><reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="S. Bradner" initials="S." surname="Bradner">
<organization/>
</author>
<date month="March" year="1997"/>
<keyword>Standards</keyword>
<keyword>Track</keyword>
<keyword>Documents</keyword>
<abstract>
<t>In 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.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="BCP" value="14"/>
<format type="TXT" octets="4723" target="http://www.rfc-editor.org/rfc/rfc2119.txt"/>
<!-- current-status BEST CURRENT PRACTICE -->
<!-- publication-status BEST CURRENT PRACTICE -->
</reference><!-- End inclusion: reference.RFC.2119.xml -->
<!-- Begin inclusion: reference.RFC.2385.xml --><reference anchor="RFC2385">
<front>
<title>Protection of BGP Sessions via the TCP MD5 Signature Option</title>
<author fullname="A. Heffernan" initials="A." surname="Heffernan">
<organization/>
</author>
<date month="August" year="1998"/>
<keyword>border</keyword>
<keyword>gateway</keyword>
<keyword>protocol</keyword>
<keyword>transmission</keyword>
<keyword>control</keyword>
<keyword>message</keyword>
<keyword>digest</keyword>
<keyword>algorithm</keyword>
<abstract>
<t>This memo describes a TCP extension to enhance security for BGP. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2385"/>
<format type="TXT" octets="12315" target="http://www.rfc-editor.org/rfc/rfc2385.txt"/>
<!-- obsoleted-by RFC5925 -->
<!-- updated-by RFC6691 -->
<!-- current-status PROPOSED STANDARD -->
<!-- publication-status PROPOSED STANDARD -->
</reference><!-- End inclusion: reference.RFC.2385.xml -->
<!-- Begin inclusion: reference.RFC.3269.xml --><reference anchor="RFC3269">
<front>
<title>Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents</title>
<author fullname="R. Kermode" initials="R." surname="Kermode">
<organization/>
</author>
<author fullname="L. Vicisano" initials="L." surname="Vicisano">
<organization/>
</author>
<date month="April" year="2002"/>
<keyword>definitions</keyword>
<keyword>operation</keyword>
<abstract>
<t>This 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.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3269"/>
<format type="TXT" octets="25258" target="http://www.rfc-editor.org/rfc/rfc3269.txt"/>
<!-- current-status INFORMATIONAL -->
<!-- publication-status INFORMATIONAL -->
</reference><!-- End inclusion: reference.RFC.3269.xml -->
<!-- Begin inclusion: reference.RFC.4252.xml --><reference anchor="RFC4252">
<front>
<title>The Secure Shell (SSH) Authentication Protocol</title>
<author fullname="T. Ylonen" initials="T." surname="Ylonen">
<organization/>
</author>
<author fullname="C. Lonvick" initials="C." surname="Lonvick">
<organization/>
</author>
<date month="January" year="2006"/>
<keyword>remote login</keyword>
<keyword>public key</keyword>
<keyword>password</keyword>
<keyword>host-based client authentication</keyword>
<abstract>
<t>The 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]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4252"/>
<format type="TXT" octets="34268" target="http://www.rfc-editor.org/rfc/rfc4252.txt"/>
<!-- current-status PROPOSED STANDARD -->
<!-- publication-status PROPOSED STANDARD -->
</reference><!-- End inclusion: reference.RFC.4252.xml -->
<!-- Begin inclusion: reference.RFC.4301.xml --><reference anchor="RFC4301">
<front>
<title>Security Architecture for the Internet Protocol</title>
<author fullname="S. Kent" initials="S." surname="Kent">
<organization/>
</author>
<author fullname="K. Seo" initials="K." surname="Seo">
<organization/>
</author>
<date month="December" year="2005"/>
<keyword>IPSEC</keyword>
<keyword>ipsec</keyword>
<keyword>authentication</keyword>
<keyword>encapsulation</keyword>
<keyword>IP</keyword>
<keyword>IPv4</keyword>
<keyword>IPv6</keyword>
<keyword>IP-layer</keyword>
<keyword>ip authentication header</keyword>
<keyword>ip security</keyword>
<keyword>IPsec</keyword>
<keyword>confidentiality</keyword>
<keyword>authentication integrity</keyword>
<keyword>anti-replay</keyword>
<keyword>ah</keyword>
<keyword>esp</keyword>
<keyword>encapsulating security payload</keyword>
<keyword>ike</keyword>
<keyword>internet key exchange</keyword>
<keyword>ikev2</keyword>
<keyword>esn</keyword>
<keyword>extended sequence number</keyword>
<abstract>
<t>This 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]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4301"/>
<format type="TXT" octets="262123" target="http://www.rfc-editor.org/rfc/rfc4301.txt"/>
<!-- obsoletes RFC2401 -->
<!-- updates RFC3168 -->
<!-- updated-by RFC6040 -->
<!-- current-status PROPOSED STANDARD -->
<!-- publication-status PROPOSED STANDARD -->
</reference><!-- End inclusion: reference.RFC.4301.xml -->
<!-- Begin inclusion: reference.RFC.5226.xml --><reference anchor="RFC5226">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author fullname="T. Narten" initials="T." surname="Narten">
<organization/>
</author>
<author fullname="H. Alvestrand" initials="H." surname="Alvestrand">
<organization/>
</author>
<date month="May" year="2008"/>
<keyword>internet assigned numbers authority</keyword>
<keyword>values</keyword>
<keyword>implementations</keyword>
<keyword>code point</keyword>
<keyword>protocol constant</keyword>
<keyword>protocol parameter</keyword>
<abstract>
<t>Many 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.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5226"/>
<seriesInfo name="BCP" value="26"/>
<format type="TXT" octets="66160" target="http://www.rfc-editor.org/rfc/rfc5226.txt"/>
<!-- obsoletes RFC2434 -->
<!-- current-status BEST CURRENT PRACTICE -->
<!-- publication-status BEST CURRENT PRACTICE -->
</reference><!-- End inclusion: reference.RFC.5226.xml -->
<!-- Begin inclusion: reference.RFC.5246.xml --><reference anchor="RFC5246">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author fullname="T. Dierks" initials="T." surname="Dierks">
<organization/>
</author>
<author fullname="E. Rescorla" initials="E." surname="Rescorla">
<organization/>
</author>
<date month="August" year="2008"/>
<keyword>idea</keyword>
<keyword>international data algorithm</keyword>
<keyword>symmetric</keyword>
<keyword>transport protocol layer</keyword>
<keyword>authentication</keyword>
<keyword>privacy</keyword>
<abstract>
<t>This 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]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5246"/>
<format type="TXT" octets="222395" target="http://www.rfc-editor.org/rfc/rfc5246.txt"/>
<!-- obsoletes RFC3268 RFC4346 RFC4366 -->
<!-- updates RFC4492 -->
<!-- updated-by RFC5746 RFC5878 RFC6176 RFC7465 RFC7507 RFC7568 -->
<!-- current-status PROPOSED STANDARD -->
<!-- publication-status PROPOSED STANDARD -->
</reference><!-- End inclusion: reference.RFC.5246.xml -->
<!-- Begin inclusion: reference.RFC.5280.xml --><reference anchor="RFC5280">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author fullname="D. Cooper" initials="D." surname="Cooper">
<organization/>
</author>
<author fullname="S. Santesson" initials="S." surname="Santesson">
<organization/>
</author>
<author fullname="S. Farrell" initials="S." surname="Farrell">
<organization/>
</author>
<author fullname="S. Boeyen" initials="S." surname="Boeyen">
<organization/>
</author>
<author fullname="R. Housley" initials="R." surname="Housley">
<organization/>
</author>
<author fullname="W. Polk" initials="W." surname="Polk">
<organization/>
</author>
<date month="May" year="2008"/>
<keyword>X.509 v3</keyword>
<keyword>X.509 v2</keyword>
<keyword>certificate extensions</keyword>
<abstract>
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5280"/>
<format type="TXT" octets="352580" target="http://www.rfc-editor.org/rfc/rfc5280.txt"/>
<!-- obsoletes RFC3280 RFC4325 RFC4630 -->
<!-- updated-by RFC6818 -->
<!-- current-status PROPOSED STANDARD -->
<!-- publication-status PROPOSED STANDARD -->
</reference><!-- End inclusion: reference.RFC.5280.xml -->
<!-- Begin inclusion: reference.RFC.5925.xml --><reference anchor="RFC5925">
<front>
<title>The TCP Authentication Option</title>
<author fullname="J. Touch" initials="J." surname="Touch">
<organization/>
</author>
<author fullname="A. Mankin" initials="A." surname="Mankin">
<organization/>
</author>
<author fullname="R. Bonica" initials="R." surname="Bonica">
<organization/>
</author>
<date month="June" year="2010"/>
<keyword>transmission control protocol</keyword>
<keyword>border</keyword>
<keyword>gateway</keyword>
<keyword>protocol</keyword>
<keyword>transmission control message</keyword>
<keyword>digest</keyword>
<keyword>algorithm</keyword>
<abstract>
<t>This 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]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5925"/>
<format type="TXT" octets="106174" target="http://www.rfc-editor.org/rfc/rfc5925.txt"/>
<!-- obsoletes RFC2385 -->
<!-- current-status PROPOSED STANDARD -->
<!-- publication-status PROPOSED STANDARD -->
</reference><!-- End inclusion: reference.RFC.5925.xml -->
<!-- Begin inclusion: reference.RFC.5926.xml --><reference anchor="RFC5926">
<front>
<title>Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)</title>
<author fullname="G. Lebovitz" initials="G." surname="Lebovitz">
<organization/>
</author>
<author fullname="E. Rescorla" initials="E." surname="Rescorla">
<organization/>
</author>
<date month="June" year="2010"/>
<keyword>transmission control protocol</keyword>
<abstract>
<t>The 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]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5926"/>
<format type="TXT" octets="31010" target="http://www.rfc-editor.org/rfc/rfc5926.txt"/>
<!-- current-status PROPOSED STANDARD -->
<!-- publication-status PROPOSED STANDARD -->
</reference><!-- End inclusion: reference.RFC.5926.xml -->
<!-- Begin inclusion: reference.RFC.6125.xml --><reference anchor="RFC6125">
<front>
<title>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)</title>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre">
<organization/>
</author>
<author fullname="J. Hodges" initials="J." surname="Hodges">
<organization/>
</author>
<date month="March" year="2011"/>
<abstract>
<t>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]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6125"/>
<format type="TXT" octets="136507" target="http://www.rfc-editor.org/rfc/rfc6125.txt"/>
<!-- current-status PROPOSED STANDARD -->
<!-- publication-status PROPOSED STANDARD -->
</reference><!-- End inclusion: reference.RFC.6125.xml -->
<!-- Begin inclusion: reference.RFC.6487.xml --><reference anchor="RFC6487">
<front>
<title>A Profile for X.509 PKIX Resource Certificates</title>
<author fullname="G. Huston" initials="G." surname="Huston">
<organization/>
</author>
<author fullname="G. Michaelson" initials="G." surname="Michaelson">
<organization/>
</author>
<author fullname="R. Loomans" initials="R." surname="Loomans">
<organization/>
</author>
<date month="February" year="2012"/>
<keyword>rpki</keyword>
<keyword>Resource Public Key Infrastructure</keyword>
<keyword>Internet Number Resources</keyword>
<keyword>INR</keyword>
<abstract>
<t>This 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]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6487"/>
<format type="TXT" octets="69150" target="http://www.rfc-editor.org/rfc/rfc6487.txt"/>
<!-- updated-by RFC7318 -->
<!-- current-status PROPOSED STANDARD -->
<!-- publication-status PROPOSED STANDARD -->
</reference><!-- End inclusion: reference.RFC.6487.xml -->
<!-- Begin inclusion: reference.RFC.6810.xml --><reference anchor="RFC6810">
<front>
<title>The Resource Public Key Infrastructure (RPKI) to Router Protocol</title>
<author fullname="R. Bush" initials="R." surname="Bush">
<organization/>
</author>
<author fullname="R. Austein" initials="R." surname="Austein">
<organization/>
</author>
<date month="January" year="2013"/>
<abstract>
<t>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. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6810"/>
<format type="TXT" octets="59714" target="http://www.rfc-editor.org/rfc/rfc6810.txt"/>
<!-- current-status PROPOSED STANDARD -->
<!-- publication-status PROPOSED STANDARD -->
</reference><!-- End inclusion: reference.RFC.6810.xml -->
<!-- Begin inclusion: reference.RFC.6811.xml --><reference anchor="RFC6811">
<front>
<title>BGP Prefix Origin Validation</title>
<author fullname="P. Mohapatra" initials="P." surname="Mohapatra">
<organization/>
</author>
<author fullname="J. Scudder" initials="J." surname="Scudder">
<organization/>
</author>
<author fullname="D. Ward" initials="D." surname="Ward">
<organization/>
</author>
<author fullname="R. Bush" initials="R." surname="Bush">
<organization/>
</author>
<author fullname="R. Austein" initials="R." surname="Austein">
<organization/>
</author>
<date month="January" year="2013"/>
<keyword>SIDR</keyword>
<keyword>security</keyword>
<abstract>
<t>To 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]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6811"/>
<format type="TXT" octets="20082" target="http://www.rfc-editor.org/rfc/rfc6811.txt"/>
<!-- current-status PROPOSED STANDARD -->
<!-- publication-status PROPOSED STANDARD -->
</reference><!-- End inclusion: reference.RFC.6811.xml -->
<!-- Begin inclusion: reference.I-D.ietf-sidr-bgpsec-algs.xml --><!-- Automatically generated, do not edit. --><reference anchor="I-D.ietf-sidr-bgpsec-algs">
<front>
<title>BGPsec Algorithms, Key Formats, & Signature Formats</title>
<author initials="S.P." surname="Turner" fullname="Sean P. Turner"><organization/></author>
<date day="20" month="July" year="2015"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-sidr-bgpsec-algs-10"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-algs-10.txt"/>
</reference><!-- End inclusion: reference.I-D.ietf-sidr-bgpsec-algs.xml -->
</references>
<references title="Informative References">
<!-- Begin inclusion: reference.RFC.5781.xml --><reference anchor="RFC5781">
<front>
<title>The rsync URI Scheme</title>
<author fullname="S. Weiler" initials="S." surname="Weiler">
<organization/>
</author>
<author fullname="D. Ward" initials="D." surname="Ward">
<organization/>
</author>
<author fullname="R. Housley" initials="R." surname="Housley">
<organization/>
</author>
<date month="February" year="2010"/>
<keyword>rsyncuri</keyword>
<abstract>
<t>This document specifies the rsync Uniform Resource Identifier (URI) scheme. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5781"/>
<format type="TXT" octets="6704" target="http://www.rfc-editor.org/rfc/rfc5781.txt"/>
<!-- current-status INFORMATIONAL -->
<!-- publication-status INFORMATIONAL -->
</reference><!-- End inclusion: reference.RFC.5781.xml -->
<!-- Begin inclusion: reference.RFC.7128.xml --><reference anchor="RFC7128">
<front>
<title>Resource Public Key Infrastructure (RPKI) Router Implementation Report</title>
<author fullname="R. Bush" initials="R." surname="Bush">
<organization/>
</author>
<author fullname="R. Austein" initials="R." surname="Austein">
<organization/>
</author>
<author fullname="K. Patel" initials="K." surname="Patel">
<organization/>
</author>
<author fullname="H. Gredler" initials="H." surname="Gredler">
<organization/>
</author>
<author fullname="M. Waehlisch" initials="M." surname="Waehlisch">
<organization/>
</author>
<date month="February" year="2014"/>
<keyword>routing</keyword>
<keyword>security</keyword>
<abstract>
<t>This document is an implementation report for the Resource Public Key Infrastructure (RPKI) Router protocol as defined in RFC 6810. The authors did not verify the accuracy of the information provided by respondents. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. The respondents were asked to only use the "YES" answer if the feature had at least been tested in the lab.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7128"/>
<format type="TXT" octets="19348" target="http://www.rfc-editor.org/rfc/rfc7128.txt"/>
<!-- current-status INFORMATIONAL -->
<!-- publication-status INFORMATIONAL -->
</reference><!-- End inclusion: reference.RFC.7128.xml -->
<!-- Begin inclusion: reference.RFC.6480.xml --><reference anchor="RFC6480">
<front>
<title>An Infrastructure to Support Secure Internet Routing</title>
<author fullname="M. Lepinski" initials="M." surname="Lepinski">
<organization/>
</author>
<author fullname="S. Kent" initials="S." surname="Kent">
<organization/>
</author>
<date month="February" year="2012"/>
<keyword>RPKI</keyword>
<keyword>BGP</keyword>
<keyword>ROA</keyword>
<abstract>
<t>This 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.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6480"/>
<format type="TXT" octets="62127" target="http://www.rfc-editor.org/rfc/rfc6480.txt"/>
<!-- current-status INFORMATIONAL -->
<!-- publication-status INFORMATIONAL -->
</reference><!-- End inclusion: reference.RFC.6480.xml -->
<!-- Begin inclusion: reference.RFC.6481.xml --><reference anchor="RFC6481">
<front>
<title>A Profile for Resource Certificate Repository Structure</title>
<author fullname="G. Huston" initials="G." surname="Huston">
<organization/>
</author>
<author fullname="R. Loomans" initials="R." surname="Loomans">
<organization/>
</author>
<author fullname="G. Michaelson" initials="G." surname="Michaelson">
<organization/>
</author>
<date month="February" year="2012"/>
<keyword>rpki</keyword>
<keyword>Resource Public Key Infrastructure</keyword>
<abstract>
<t>This 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]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6481"/>
<format type="TXT" octets="36117" target="http://www.rfc-editor.org/rfc/rfc6481.txt"/>
<!-- current-status PROPOSED STANDARD -->
<!-- publication-status PROPOSED STANDARD -->
</reference><!-- End inclusion: reference.RFC.6481.xml -->
<!-- Begin inclusion: reference.RFC.1996.xml --><reference anchor="RFC1996">
<front>
<title>A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)</title>
<author fullname="P. Vixie" initials="P." surname="Vixie">
<organization/>
</author>
<date month="August" year="1996"/>
<keyword>DNS-NOTIFY</keyword>
<keyword>Domain</keyword>
<keyword>Name</keyword>
<keyword>System</keyword>
<abstract>
<t>This 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]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="1996"/>
<format type="TXT" octets="15247" target="http://www.rfc-editor.org/rfc/rfc1996.txt"/>
<!-- updates RFC1035 -->
<!-- current-status PROPOSED STANDARD -->
<!-- publication-status PROPOSED STANDARD -->
</reference><!-- End inclusion: reference.RFC.1996.xml -->
<!-- Begin inclusion: reference.RFC.4808.xml --><reference anchor="RFC4808">
<front>
<title>Key Change Strategies for TCP-MD5</title>
<author fullname="S. Bellovin" initials="S." surname="Bellovin">
<organization/>
</author>
<date month="March" year="2007"/>
<keyword>bgp</keyword>
<keyword>border gateway protocol</keyword>
<abstract>
<t>The 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.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4808"/>
<format type="TXT" octets="14939" target="http://www.rfc-editor.org/rfc/rfc4808.txt"/>
<!-- current-status INFORMATIONAL -->
<!-- publication-status INFORMATIONAL -->
</reference><!-- End inclusion: reference.RFC.4808.xml -->
</references>
</back>
</rfc><!--
- Local Variables:
- mode:sgml
- indent-tabs-mode: nil
- End:
-->
| PAFTECH AB 2003-2026 | 2026-04-23 01:13:28 |