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

-07 published

Browse source
This commit is contained in:
Randy Bush 2022-05-31 21:50:49 -07:00
parent 060edca854
commit 3dc5738af5
1 changed files with 189 additions and 172 deletions
Download patch file Download diff file Expand all files Collapse all files

325
draft-ietf-sidrops-8210bis.xml
View file

@ -10,7 +10,7 @@
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-sidrops-8210bis-06" submissionType="IETF" obsoletes="8210" ipr="trust200902" consensus="yes">
<rfc category="std" docName="draft-ietf-sidrops-8210bis-07" submissionType="IETF" updates="8210" ipr="trust200902" consensus="yes">
<front>
@ -54,7 +54,7 @@
<t>
This document describes version 2 of the RPKI-Router protocol.
RFC 6810 describes version 0, and RFC 8210 describes version 1.
This document obsoletes and replaces RFC 8210.
This document updates and replaces RFC 8210.
</t>
</abstract>
@ -116,17 +116,18 @@
<t>
<list style="symbols">
<t>
A new ASPA PDU type (<xref target="aspa"/>) has added to
support <xref target="I-D.ietf-sidrops-aspa-profile"/>.
A new ASPA (Autonomous System Provider Authorization) PDU
type (<xref target="aspa"/>) has added to support <xref
target="I-D.ietf-sidrops-aspa-profile"/>.
</t>
<t>
A small section, <xref target="races"/>, has been added to
handle two ROA PDU race conditions, Break Before Make and
Shorter Prefix First.
A small <xref target="races"/> has been added to handle
two ROA (Route Origination Authorization) PDU race
conditions, Break Before Make and Shorter Prefix First.
</t>
<t>
The protocol version number incremented from 1 (one) to 2
(two) and the <xref target="version"/> section has been
(two) and <xref target="version"/> has been
updated accordingly.
</t>
</list>
@ -146,15 +147,21 @@
Registries (RIRs), National Internet Registries (NIRs),
and ISPs; see <xref target="RFC6481"/>.
</t>
<t hangText="CA:">
The authoritative data of the RPKI are meant to be published
by a distributed set of Certification Authorities (CAs) at
the IANA, RIRs, NIRs, and ISPs (see <xref
target="RFC6481"/>).
</t>
<t hangText="Cache:">
A cache is a coalesced copy
of the published Global RPKI data, periodically fetched or
refreshed, directly or indirectly, using the
rsync protocol <xref target="RFC5781"/> or some
successor. Relying Party software is used to gather and
validate the distributed data of the RPKI into a cache.
Trusting this cache further is a matter between the
provider of the cache and a Relying Party.
A Cache, AKA Relying Party Cache, is a coalesced copy of the
published Global RPKI data, periodically fetched or
refreshed, directly or indirectly, using the rsync protocol
<xref target="RFC5781"/> or some successor. Relying Party
software is used to gather and validate the distributed data
of the RPKI into a cache. Trusting this cache further is a
matter between the provider of the cache and a Relying
Party.
</t>
<t hangText="Serial Number:">
"Serial Number" is a
@ -218,11 +225,11 @@
<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.
A router establishes and keeps open a transport 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,
@ -279,6 +286,16 @@
which are time dependent, servers' clocks MUST be correct to a
tolerance of approximately an hour.
</t>
<t>
Barring errors, transport connections remain up as long as the
cache and router remain up and the router is not reconfigured to
no longer use the cache.
</t>
<t>
Should a transport connection be lost for unknown reasons, the
router SHOULD try to reestablish one; being careful to not abuse
the cache with twoo many failed requests.
</t>
</section>
<section anchor="pdus" title="Protocol Data Units (PDUs)">
@ -297,7 +314,7 @@
PDUs contain the following data elements:
<list style="hanging">
<t hangText="Protocol Version:">
An 8-bit unsigned integer, currently 1, denoting the
An 8-bit unsigned integer, currently 2, denoting the
version of this protocol.
</t>
<t hangText="PDU Type:">
@ -385,17 +402,14 @@
header which includes the length field.
</t>
<t hangText="Flags:">
The lowest-order bit of the Flags field is 0 for IPv4 and
1 for IPv6.</t>
<t>The next lowest bit is 1 for an announcement and 0 for
a withdrawal. For a Prefix PDU (IPv4 or IPv6), the
announce/withdraw 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). </t>
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 announce/withdraw 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).</t>
<t>Similarly, for a Router Key PDU, the flag indicates
whether this PDU announces a new Router Key or deletes one
@ -403,18 +417,9 @@
Number, subjectKeyIdentifier, and
subjectPublicKeyInfo.</t>
<t>For the ASPA PDU, the announce/withdraw Flag is set to
1 to indicate either the announcement of a new ASPA record
or a replacement for a previously announced record with
the same Customer Autonomous System Number. The
announce/withdraw flag set to 0 indicates removal of the
ASPA record in total. Here, only the customer AS of the
ASPA record MUST be provided, the Provider AS Count as
well as the Provider AS Numbers list MUST BE zero.</t>
<t>
The remaining bits in the Flags field are reserved for
future use. In protocol version 2, they MUST be zero on
transmission and MUST be ignored on receipt.
future use.
</t>
<t hangText="Prefix Length:">
An 8-bit unsigned integer denoting the shortest prefix
@ -438,7 +443,7 @@
</t>
<t hangText="Subject Public Key Info:"> A router key's
subjectPublicKeyInfo value, as described in
<xref target="RFC8208"/>. This is the
<xref target="RFC8608"/>. This is the
full ASN.1 DER encoding of the subjectPublicKeyInfo,
including the ASN.1 tag and length values of the
subjectPublicKeyInfo SEQUENCE.
@ -607,7 +612,7 @@
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
announce/withdraw field in the payload PDUs MUST have the
value 1 (announce).
</t>
<t>
@ -774,27 +779,11 @@
See <xref target="timing"/> for an explanation of the use
and the range of allowed values for these parameters.
</t>
<t>Note that the End of Data PDU changed significantly between
versions 0 and 1. For version 0 compatibility, the following is
the version 0 End of Data PDU.</t>
<figure>
<artwork>
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Cache Nonce |
| 0 | 7 | |
+-------------------------------------------+
| |
| Length=12 |
| |
+-------------------------------------------+
| |
| Serial Number |
| |
`-------------------------------------------'
</artwork>
</figure>
<t>
Note that the End of Data PDU changed significantly between
versions 0 and 1. Version 2 End of Data is the same as
Version 1.
</t>
</section>
<section anchor="cachereset" title="Cache Reset">
@ -954,6 +943,7 @@
</section>
<section anchor="aspa" title="ASPA PDU">
<!-- protocol "Protocol Version 2:8,PDU Type 11:8,zero:16,Length:32,Flags:8,AFI Flag:8,Provider AS Count:16,Customer Autonomous System Number:32,Provider Autonomous System Numbers:32" -->
<figure>
<artwork>
0 8 16 24 31
@ -967,7 +957,7 @@
| |
+-------------------------------------------+
| | | |
| Flags | zero | Provider AS Count |
| Flags | AFI Flags| Provider AS Count |
| | | |
+-------------------------------------------+
| |
@ -975,45 +965,62 @@
| |
+-------------------------------------------+
| |
| Provider Autonomous System Numbers |
~ Provider Autonomous System Numbers ~
| |
~-------------------------------------------~
</artwork>
</figure>
<t>
The ASPA PDU is to support <xref
The ASPA PDU supports <xref
target="I-D.ietf-sidrops-aspa-profile"/>. An ASPA PDU
represents one single customer AS and its provider ASs for a
particular Address Family. Receipt of an ASPA PDU
announcement (Flag.Announce == 1) when the router already has
an ASPA PDU with the same Customer Autonomous System Number
and the same Address Family (see Flags field), replaces the
previous one. This is to avoid a race condition when a BGP
announcement is received between an withdrawn PDU and a new
announced PDU. Therefore, the cache MUST deliver the complete
data of an ASPA record in a single ASPA PDU.
announcement (announce/withdraw flag == 1) when the router
already has an ASPA PDU with the same Customer Autonomous
System Number and the same Address Family (see Flags field),
replaces the previous one. This is to avoid a race condition
when a BGP announcement is received between a withdrawn ASPA
PDU and a newly announced ASPA PDU. Therefore, the cache MUST
deliver the complete data of an ASPA record in a single ASPA
PDU.
</t>
<t>
The router should see at most one ASPA from a cache for a
particular Customer Autonomous System Number active at any
time. As a number of conditions in the global RPKI may
present multiple valid ASPA objects for a single customer to a
particular RP cache, this places a burden on the cache to form
the union of multiple ASPA records it has received from the
global RPKI into one ASPA PDU.
present multiple valid ASPA RPKI records for a single customer
to a particular RP cache, this places a burden on the cache to
form the union of multiple ASPA records it has received from
the global RPKI into one ASPA PDU.
</t>
<t>
The Flags field is defined as follows:</t>
The Flags field is as described in <xref target="pdus"/>.
</t>
<t>
For the ASPA PDU, the announce/withdraw Flag is set to 1 to
indicate either the announcement of a new ASPA record or a
replacement for a previously announced record with the same
Customer Autonomous System Number. The announce/withdraw flag
set to 0 indicates removal of the ASPA record in total. Here,
only the customer AS of the ASPA record MUST be provided, the
Provider AS Count as well as the Provider AS Numbers list MUST
BE zero.
</t>
<t>
The AFI Flags field is defined as follows:
</t>
<figure>
<artwork>
Bit Bit Name
---- -------------------
0 AFI (IPv4 == 0, IPv6 == 1)
1 Announce == 1, Delete == 0
2-7 Reserved, must be zero
1-7 Reserved, MUST be zero
</artwork>
</figure>
@ -1039,8 +1046,8 @@
Receipt of an ASPA PDU with the Flags field indicating Delete
is an explicit withdraw from the router of the entire ASPA
data for that customer AS. While the Provider AS Count and
the Provider AS Numbers MUST BE ignored by the router when the
Flags field indicates a Delete, the cache SHOULD set the
the Provider AS Numbers MUST be ignored by the router when the
Flags field indicates a Delete, the cache MUST set the
Provider AS Count to zero, and have a null Provider AS Numbers
list.
</t>
@ -1076,7 +1083,7 @@
<list style="hanging">
<t hangText="Minimum allowed value:">1 second.</t>
<t hangText="Maximum allowed value:">86400 seconds (1 day).</t>
<t hangText="Recommended default:">7200 seconds (2 hours).</t>
<t hangText="Recommended default:">3600 seconds (2 hours).</t>
</list>
</t>
<t hangText="Retry Interval:">
@ -1124,16 +1131,19 @@
<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.
Reset Query or a Serial Query. This query MUST tell the cache
the highest version of this protocol the router implements.
</t>
<t>
If a cache which supports version N receives a query from a
router which specifies version Q &lt; N, the cache MUST downgrade
to protocol version Q <xref target="RFC6810"/> or <xref
target="RFC8210"/> or send a version 1 Error Report PDU with
Error Code 4 ("Unsupported Protocol Version") and terminate the
connection.
router which specifies its highest supported version Q &lt; N,
the cache MUST downgrade to protocol version Q <xref
target="RFC6810"/> or <xref target="RFC8210"/> or send a version
2 Error Report PDU with Error Code 4 ("Unsupported Protocol
Version") and terminate the connection; in which case the
Arbitrary Text field of the ERROR Report PDU MUST be a list of
one octet binary integers indicating the version numbers the
cache supports.
</t>
<t>
If a router which supports version N sends a query to a cache
@ -1142,8 +1152,9 @@
<list style="numbers">
<t>
The cache may terminate the connection, perhaps with a
version 0 Error Report PDU. In this case, the router MAY
retry the connection using protocol version C.
version 4 Error Report PDU, Unsupported Protocol Version.
In this case, the router MAY retry the connection using
protocol version C.
</t>
<t>
The cache may reply with a version C response. In this
@ -1218,7 +1229,7 @@ Cache Router
| ----- Cache Response -----&gt; | C confirms request
| ------- Payload PDU ------&gt; | C sends zero or more
| ------- Payload PDU ------&gt; | IPv4 Prefix, IPv6 Prefix,
| ------- Payload PDU ------&gt; | or Router Key PDUs
| ------- Payload PDU ------&gt; | ASPA, or Router Key PDUs
| ------- End of Data ------&gt; | C sends End of Data
| | and sends new serial
~ ~
@ -1269,7 +1280,7 @@ Cache Router
| ----- Cache Response -----&gt; | C confirms request
| ------- Payload PDU ------&gt; | C sends zero or more
| ------- Payload PDU ------&gt; | IPv4 Prefix, IPv6 Prefix,
| ------- Payload PDU ------&gt; | or Router Key PDUs
| ------- Payload PDU ------&gt; | ASPA. or Router Key PDUs
| ------- End of Data ------&gt; | C sends End of Data
| | and sends new serial
~ ~
@ -1309,7 +1320,7 @@ Cache Router
| ----- Cache Response -----&gt; | C confirms request
| ------- Payload PDU ------&gt; | C sends zero or more
| ------- Payload PDU ------&gt; | IPv4 Prefix, IPv6 Prefix,
| ------- Payload PDU ------&gt; | or Router Key PDUs
| ------- Payload PDU ------&gt; | ASPA, or Router Key PDUs
| ------- End of Data ------&gt; | C sends End of Data
| | and sends new serial
~ ~
@ -1426,7 +1437,7 @@ Cache Router
</t>
<t>
Caches and routers MAY use TCP MD5 transport
<xref target="RFC2385"/> using the rpki-rtr port. Note that
<xref target="RFC5925"/> using the rpki-rtr port. Note that
TCP MD5 has been obsoleted by TCP-AO
<xref target="RFC5925"/>.
</t>
@ -1436,7 +1447,7 @@ Cache Router
</t>
<t>
Caches and routers MAY use Transport Layer Security (TLS) transport
<xref target="RFC5246"/> using port rpki-rtr-tls (324); see
<xref target="RFC8446"/> using port rpki-rtr-tls (324); see
<xref target="IANA"/>.
</t>
</list></t>
@ -1546,7 +1557,7 @@ Cache Router
<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
<xref target="RFC5925"/>. Implementations MUST also support
hexadecimal sequences of at least 32 characters, i.e.,
128 bits.
</t>
@ -1655,20 +1666,20 @@ Cache Router
<section anchor="races" title="ROA PDU Race Minimization">
<t>
When a cache is sending ROA PDUs to the router, especially during
an initial full load, two undesirable race conditions are
possible:
When a cache is sending ROA PDUs to a router, especially an
initial full load in response to a Reset Query PDU, two
undesirable race conditions are possible:
<list style="hanging">
<t hangText="Break Before Make:">
For some prefix P, an AS may announce two (or more) ROAs
because they are in the process of changing what provider AS
is announcing P. This is is a case of "make before break."
If a cache is feeding a router and sends the one not yet in
service a significant time before sending the one currently
in service, then BGP data could be marked invalid during the
is announcing P. This is a case of "make before break." If a
cache is feeding a router and sends the one not yet in service
a significant time before sending the one currently in
service, then BGP data could be marked invalid during the
interval. To minimize that interval, the cache SHOULD
announce all ROAs for the same prefix as close to
sequentially as possible.
announce all ROAs for the same prefix as close to sequentially
as possible.
</t>
<t hangText="Shorter Prefix First:">
If an AS has issued a ROA for P0, and another AS (likely
@ -1732,12 +1743,10 @@ Cache Router
<section anchor="errorcodes" title="Error Codes">
<t>
This section contains a preliminary list of error codes. The
authors expect additions to the list during development of
the initial implementations. There is an IANA registry where
valid error codes are listed; see <xref target="IANA"/>. Errors
which are considered fatal MUST cause the session to be
dropped.
This section describes the meaning of the error codes. There is
an IANA registry where valid error codes are listed; see <xref
target="iana-err"/>. Errors which are considered fatal MUST cause
the session to be dropped.
<list style="hanging">
<t hangText="0: Corrupt Data (fatal):">
The receiver believes the received PDU to be corrupt in a
@ -1770,16 +1779,18 @@ Cache Router
The PDU Type is not known by the receiver of the PDU.
</t>
<t hangText="6: Withdrawal of Unknown Record (fatal):">
The received PDU has Flag=0, but a matching record
({Prefix, Len, Max-Len, ASN} tuple for an IPvX PDU or
{SKI, ASN, Subject Public Key} tuple for a Router Key PDU)
does not exist in the receiver's database.
The received PDU has Flag=0, but a matching record ({Prefix,
Len, Max-Len, ASN} tuple for an IPvX PDU, or {SKI, ASN,
Subject Public Key} tuple for a Router Key PDU), or Customer
Autonomous System for an ASPA PDU does not exist in the
receiver's database.
</t>
<t hangText="7: Duplicate Announcement Received (fatal):">
The received PDU has Flag=1, but a matching record
({Prefix, Len, Max-Len, ASN} tuple for an IPvX PDU or
{SKI, ASN, Subject Public Key} tuple for a Router Key PDU)
is already active in the router.
The received PDU has Flag=1, but a matching record ({Prefix,
Len, Max-Len, ASN} tuple for an IPvX PDU or {SKI, ASN,
Subject Public Key} tuple for a Router Key PDU), or Customer
Autonomous System for an ASPA 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
@ -1868,26 +1879,24 @@ Cache Router
<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
IANA protocol registries to accommodate version 2 of this
protocol. See <xref target="RFC8210"/> for IANA considerations
from the original (version 0) protocol.
of the previous (version 1) 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.
All of the PDU types in the IANA "rpki-rtr-pdu" registry <xref
target="iana-pdu"/> in protocol versions 0 and 1 are also
allowed in protocol version 2, with the addition of the new ASPA
PDU.
</t>
<t>
The policy for adding to the registry is RFC Required per
<xref target="RFC8126"/>; the document must be either Standards Track or
Experimental.
The policy for adding to the registry is RFC Required per <xref
target="RFC8126"/>; the document must be either Standards Track
or Experimental.
</t>
<t>
The "rpki-rtr-pdu" registry has been updated as follows:
The "rpki-rtr-pdu" registry <xref target="iana-pdu"/> has been
updated as follows:
</t>
<figure>
<artwork>
@ -1911,9 +1920,9 @@ Cache Router
</artwork>
</figure>
<t>
All previous entries in the IANA "rpki-rtr-error" registry
remain valid for all protocol versions. Protocol version 1
added one new error code:
All previous entries in the IANA "rpki-rtr-error" registry <xref
target="iana-err"/> remain valid for all protocol versions.
Protocol version 1 added one new error code:
</t>
<figure>
<artwork>
@ -1930,13 +1939,24 @@ Cache Router
<back>
<references title="Normative References">
<?rfc include="reference.I-D.ietf-sidrops-aspa-profile.xml"?>
<reference anchor="iana-pdu" target="https://www.iana.org/assignments/rpki#rpki-rtr-pdu">
<front>
<title>rpki-rtr-pdu</title>
<author fullname="IANA"></author>
</front>
</reference>
<reference anchor="iana-err" target="https://www.iana.org/assignments/rpki#rpki-rtr-error">
<front>
<title>rpki-rtr-error</title>
<author fullname="IANA"></author>
</front>
</reference>
<?rfc include="reference.RFC.1982.xml"?>
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.2385.xml"?>
<?rfc include="reference.RFC.3629.xml"?>
<?rfc include="reference.RFC.4252.xml"?>
<?rfc include="reference.RFC.4301.xml"?>
<?rfc include="reference.RFC.5246.xml"?>
<?rfc include="reference.RFC.5280.xml"?>
<?rfc include="reference.RFC.5925.xml"?>
<?rfc include="reference.RFC.5926.xml"?>
@ -1946,32 +1966,29 @@ Cache Router
<?rfc include="reference.RFC.6811.xml"?>
<?rfc include="reference.RFC.8126.xml"?>
<?rfc include="reference.RFC.8174.xml"?>
<?rfc include="reference.RFC.8208.xml"?>
<?rfc include="reference.RFC.8210.xml"?>
<?rfc include="reference.I-D.ietf-sidrops-aspa-profile.xml"?>
<?rfc include="reference.RFC.8446.xml"?>
<?rfc include="reference.RFC.8608.xml"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.1996.xml"?>
<?rfc include="reference.RFC.4808.xml"?>
<?rfc include="reference.RFC.5781.xml"?>
<?rfc include="reference.RFC.6480.xml"?>
<?rfc include="reference.RFC.6481.xml"?>
</references>
<section anchor="Acknowledgements" title="Acknowledgements" numbered="no">
<t>
The authors wish to thank Nils Bars, Steve Bellovin, Oliver
Borchert, Tim Bruijnzeels, Rex Fernando, Richard Hansen, Martin
Hoffmann, Paul Hoffman, Fabian Holler, Russ Housley, Pradosh
Mohapatra, Keyur Patel, David Mandelberg, Sandy Murphy, Robert
Raszuk, Andreas Reuter, Thomas Schmidt, John Scudder, Ruediger
Volk, Matthias Waehlisch, and David Ward. Particular thanks go
to Hannes Gredler for showing us the dangers of unnecessary
fields.
Borchert, Mohamed Boucadair, Tim Bruijnzeels, Rex Fernando,
Richard Hansen, Martin Hoffmann, Paul Hoffman, Fabian Holler,
Russ Housley, Pradosh Mohapatra, Keyur Patel, David Mandelberg,
Sandy Murphy, Robert Raszuk, Andreas Reuter, Thomas Schmidt,
John Scudder, Ruediger Volk, Matthias Waehlisch, and David Ward.
Particular thanks go to Hannes Gredler for showing us the
dangers of unnecessary fields.
</t>
<t>
No doubt this list is incomplete. We apologize to any