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

-09 published after romain review

Browse source
This commit is contained in:
Randy Bush 2022-06-14 17:48:12 -07:00
parent e7539c739d
commit 2664fb37e5
1 changed files with 133 additions and 122 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -164,19 +164,18 @@
Party. Party.
</t> </t>
<t hangText="Serial Number:"> <t hangText="Serial Number:">
"Serial Number" is a "Serial Number" is a 32-bit strictly increasing unsigned
32-bit strictly increasing unsigned integer which wraps integer which wraps from 2^32-1 to 0. It denotes the
from 2^32-1 to 0. It denotes the logical version of a logical version of a cache. A cache increments the value
cache. A cache increments the value when it successfully when it successfully updates its data from a parent cache or
updates its data from a parent cache or from primary RPKI from primary RPKI data. While a cache is receiving updates,
data. While a cache is receiving updates, new incoming new incoming data and implicit deletes are associated with
data and implicit deletes are associated with the new the new Serial Number but MUST NOT be sent until the fetch
serial but MUST NOT be sent until the fetch is complete. is complete. A Serial Number is not commensurate between
A Serial Number is not commensurate between different different caches or different protocol versions, nor need it
caches or different protocol versions, nor need it be be maintained across resets of the cache server. See <xref
maintained across resets of the cache server. See target="RFC1982"/> on DNS Serial Number Arithmetic for too
<xref target="RFC1982"/> on DNS Serial Number Arithmetic much detail on the topic.
for too much detail on the topic.
</t> </t>
<t hangText="Session ID:"> <t hangText="Session ID:">
When a cache server is started, it generates a Session ID When a cache server is started, it generates a Session ID
@ -284,7 +283,7 @@
As a cache server must evaluate certificates and ROAs (Route As a cache server must evaluate certificates and ROAs (Route
Origin Authorizations; see <xref target="RFC6480"/>), Origin Authorizations; see <xref target="RFC6480"/>),
which are time dependent, servers' clocks MUST be correct to a which are time dependent, servers' clocks MUST be correct to a
tolerance of approximately an hour. tolerance of an hour.
</t> </t>
<t> <t>
Barring errors, transport connections remain up as long as the Barring errors, transport connections remain up as long as the
@ -322,11 +321,11 @@
e.g., IPv4 Prefix. e.g., IPv4 Prefix.
</t> </t>
<t hangText="Serial Number:"> <t hangText="Serial Number:">
The Serial Number of the RPKI cache when this set of PDUs A 32-bit unsigned integer serializing the RPKI cache epoc
was received from an upstream cache server or gathered from when this set of PDUs was received from an upstream cache
the Global RPKI. A cache increments its Serial Number when server or gathered from the Global RPKI. A cache
completing a rigorously validated update from a parent cache increments its Serial Number when completing a validated
or the Global RPKI. update from a parent cache or the Global RPKI.
</t> </t>
<t hangText="Session ID:"> <t hangText="Session ID:">
A 16-bit unsigned integer. A 16-bit unsigned integer.
@ -390,11 +389,12 @@
avoid the risk of Session ID collisions. avoid the risk of Session ID collisions.
</t> </t>
<t> <t>
The Session ID might be a pseudorandom value, a The Session ID might be a pseudorandom value, a strictly
strictly increasing value if the cache has reliable increasing value if the cache has reliable storage, et
storage, et cetera. A seconds-since-epoch timestamp cetera. A seconds-since-epoch timestamp value such as the
value such as the POSIX time() function makes a good low order 16 bits of unsigned integer seconds since
Session ID value. 1970-01-01T00:00:00Z ignoring leap seconds might make a
good Session ID value.
</t> </t>
<t hangText="Length:"> <t hangText="Length:">
A 32-bit unsigned integer which has as its value the count A 32-bit unsigned integer which has as its value the count
@ -402,9 +402,9 @@
header which includes the length field. header which includes the length field.
</t> </t>
<t hangText="Flags:"> <t hangText="Flags:">
The lowest-order bit of the Flags field is 1 for an An 8-bit binary field, with the lowest-order bit being 1
announcement and 0 for a withdrawal. For a Prefix PDU for an announcement and 0 for a withdrawal. For a Prefix
(IPv4 or IPv6), the announce/withdraw flag indicates PDU (IPv4 or IPv6), the announce/withdraw flag indicates
whether this PDU announces a new right to announce the whether this PDU announces a new right to announce the
prefix or withdraws a previously announced right; a prefix or withdraws a previously announced right; a
withdraw effectively deletes one previously announced withdraw effectively deletes one previously announced
@ -437,49 +437,49 @@
A 32-bit unsigned integer representing an ASN allowed to A 32-bit unsigned integer representing an ASN allowed to
announce a prefix or associated with a router key. announce a prefix or associated with a router key.
</t> </t>
<t hangText="Subject Key Identifier:"> 20-octet <t hangText="Subject Key Identifier:">
Subject Key Identifier (SKI) value of a router key, as The 20-bit Subject Key Identifier (SKI) value of a router
described in <xref target="RFC6487"/>. key, as described in <xref target="RFC6487"/>.
</t> </t>
<t hangText="Subject Public Key Info:"> A router key's <t hangText="Subject Public Key Info:">
subjectPublicKeyInfo value, as described in A variable length field holding a router key's
<xref target="RFC8608"/>. This is the subjectPublicKeyInfo value, as described in <xref
full ASN.1 DER encoding of the subjectPublicKeyInfo, target="RFC8608"/>. This is the full ASN.1 DER encoding
including the ASN.1 tag and length values of the of the subjectPublicKeyInfo, including the ASN.1 tag and
subjectPublicKeyInfo SEQUENCE. length values of the subjectPublicKeyInfo SEQUENCE.
</t> </t>
<t hangText="Refresh Interval:"> <t hangText="Refresh Interval:">
Interval between normal cache polls. See <xref A 32-bit interval in seconds between normal cache polls.
target="timing"/>. See <xref target="timing"/>.
</t> </t>
<t hangText="Retry Interval:"> <t hangText="Retry Interval:">
Interval between cache poll retries after a failed cache poll. A 32-bit interval in seconds between cache poll retries
See <xref target="timing"/>. after a failed cache poll. See <xref target="timing"/>.
</t> </t>
<t hangText="Expire Interval:"> <t hangText="Expire Interval:">
Interval during which data fetched from a cache remains A 32-bit interval in seconds during which data fetched
valid in the absence of a successful subsequent cache poll. from a cache remains valid in the absence of a successful
See <xref target="timing"/>. subsequent cache poll. See <xref target="timing"/>.
</t> </t>
<t hangText="AFI Flags:"> <t hangText="AFI Flags:">
A field of the ASPA PDU where the low order bit denotes An 8-bit field of the ASPA PDU where the low order bit
whether the AS relationships are for IPv4 (0) or IPv6 (1) denotes whether the AS relationships are for IPv4 (0) or
AFI. IPv6 (1) AFI.
</t> </t>
<t hangText="Provider AS Count:"> <t hangText="Provider AS Count:">
The number of Provider Autonomous System Numbers in the A 16-bit count of Provider Autonomous System Numbers in
PDU. the PDU.
</t> </t>
<t hangText="Customer Autonomous System Number:"> <t hangText="Customer Autonomous System Number:">
The AS number of the Autonomous System that authorizes the The 32-bit AS number of the Autonomous System that
upstream providers listed in the Provider Autonomous authorizes the upstream providers listed in the Provider
System list to propagate prefixes of the specified address Autonomous System list to propagate prefixes of the
family other ASes. specified address family other ASes.
</t> </t>
<t hangText="Provider Autonomous System Numbers:"> <t hangText="Provider Autonomous System Numbers:">
The set of AS numbers authorized to propagate prefixes of The set of 32-bit AS numbers authorized to propagate
the spacified AFI which were received from the customer prefixes of the specified AFI which were received from the
AS. customer AS.
</t> </t>
</list> </list>
</t> </t>
@ -685,6 +685,10 @@
`-------------------------------------------' `-------------------------------------------'
</artwork> </artwork>
</figure> </figure>
<t>
This PDU carries an <xref target="RFC6811"/> Vidated ROA
Payload (VRP) for an IPv4 ROA.
</t>
<t> <t>
The lowest-order bit of the Flags field is 1 for an The lowest-order bit of the Flags field is 1 for an
announcement and 0 for a withdrawal. announcement and 0 for a withdrawal.
@ -747,7 +751,12 @@
</artwork> </artwork>
</figure> </figure>
<t> <t>
Analogous to the IPv4 Prefix PDU, it has 96 more bits and no magic. This PDU carries an <xref target="RFC6811"/> Vidated ROA
Payload (VRP) for an IPv6 ROA.
</t>
<t>
Analogous to the IPv4 Prefix PDU, it has 96 more bits and no
magic.
</t> </t>
</section> </section>
@ -863,6 +872,10 @@
`-------------------------------------------' `-------------------------------------------'
</artwork> </artwork>
</figure> </figure>
<t>
The Router Key PDU transports an <xref target="RFC8635"/>
Router key.
</t>
<t> <t>
The lowest-order bit of the Flags field is 1 for an The lowest-order bit of the Flags field is 1 for an
announcement and 0 for a withdrawal. announcement and 0 for a withdrawal.
@ -892,6 +905,10 @@
Subject Public Key values as well as SKIs when detecting Subject Public Key values as well as SKIs when detecting
duplicate PDUs. duplicate PDUs.
</t> </t>
<t>
As the Subject Public Key Info is a variable length field, it
must be decoded to determine where the PDU terminates.
</t>
</section> </section>
<section anchor="error" title="Error Report"> <section anchor="error" title="Error Report">
@ -906,6 +923,10 @@
<t> <t>
Error codes are described in <xref target="errorcodes"/>. Error codes are described in <xref target="errorcodes"/>.
</t> </t>
<t>
The Erroneous PDU field is a binary copy of the PDU causing
the error condition, including all fields.
</t>
<t> <t>
If the error is generic (e.g., "Internal Error") and not If the error is generic (e.g., "Internal Error") and not
associated with the PDU to which it is responding, the associated with the PDU to which it is responding, the
@ -924,9 +945,9 @@
MAY be truncated. MAY be truncated.
</t> </t>
<t> <t>
The diagnostic text is optional; if not present, the Length of The Arbitrary Bytes field is optional; if not present, the
Error Text field MUST be zero. If error text is present, it Length of Arbitrary Bytes field MUST be zero. If Arbitrary
MUST be a string in UTF-8 encoding (see <xref target="RFC3629"/>). Bytes are present, they are, as named, arbitrary values.
</t> </t>
<figure> <figure>
<artwork> <artwork>
@ -949,13 +970,13 @@
| | | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Length of Error Text | | Length of Arbitrary Bytes |
| | | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Arbitrary Text | | Arbitrary Bytes |
| of | | of |
~ Error Diagnostic Message ~ ~ Error Diagnostic ~
| | | |
`-------------------------------------------' `-------------------------------------------'
</artwork> </artwork>
@ -1162,7 +1183,7 @@
target="RFC6810"/> or <xref target="RFC8210"/> or send a version target="RFC6810"/> or <xref target="RFC8210"/> or send a version
2 Error Report PDU with Error Code 4 ("Unsupported Protocol 2 Error Report PDU with Error Code 4 ("Unsupported Protocol
Version") and terminate the connection; in which case the Version") and terminate the connection; in which case the
Arbitrary Text field of the ERROR Report PDU MUST be a list of Arbitrary Bytes field of the ERROR Report PDU MUST be a list of
one octet binary integers indicating the version numbers the one octet binary integers indicating the version numbers the
cache supports. The router MUST choose the highest mutally cache supports. The router MUST choose the highest mutally
supported version. If there are none, the router MUST abort the supported version. If there are none, the router MUST abort the
@ -1400,7 +1421,8 @@ Cache Router
SHOULD attempt to connect to any other caches in its cache SHOULD attempt to connect to any other caches in its cache
list, in preference order. If no other caches are list, in preference order. If no other caches are
available, the router MUST issue periodic Reset Queries available, the router MUST issue periodic Reset Queries
until it gets a new usable load from the cache. until it gets a new usable load from the cache; maybe once a
minute so as not to DoS the cache.
</t> </t>
</section> </section>
@ -1460,19 +1482,20 @@ Cache Router
example, see <xref target="SSH"/>. example, see <xref target="SSH"/>.
</t> </t>
<t> <t>
Caches and routers MAY use TCP MD5 transport Caches and routers MAY use TCP MD5 transport <xref
<xref target="RFC5925"/> using the rpki-rtr port. Note that target="RFC2385"/> using the rpki-rtr port if no other protected
TCP MD5 has been obsoleted by TCP-AO transport is available. Note that TCP MD5 has been obsoleted by
<xref target="RFC5925"/>. TCP-AO <xref target="RFC5925"/>.
</t> </t>
<t> <t>
Caches and routers MAY use TCP over IPsec transport Caches and routers MAY use TCP over IPsec transport
<xref target="RFC4301"/> using the rpki-rtr port. <xref target="RFC4301"/> using the rpki-rtr port.
</t> </t>
<t> <t>
Caches and routers MAY use Transport Layer Security (TLS) transport Caches and routers MAY use Transport Layer Security (TLS)
<xref target="RFC8446"/> using port rpki-rtr-tls (324); see transport <xref target="RFC8446"/> using port rpki-rtr-tls
<xref target="IANA"/>. (324); see <xref target="IANA"/>. Conformance to <xref
target="RFC7525"/> modern cipher suites is REQUIRED.
</t> </t>
</list></t> </list></t>
@ -1510,10 +1533,11 @@ Cache Router
Cache servers supporting SSH transport MUST accept RSA Cache servers supporting SSH transport MUST accept RSA
authentication and SHOULD accept Elliptic Curve Digital authentication and SHOULD accept Elliptic Curve Digital
Signature Algorithm (ECDSA) authentication. User Signature Algorithm (ECDSA) authentication. User
authentication MUST be supported; host authentication MAY be authentication "publickey") MUST be supported; host
supported. Implementations MAY support password authentication "hostbased") MAY be supported. Implementations
authentication. Client routers SHOULD verify the public key MAY support password authentication "password"). "None"
of the cache to avoid MITM attacks. authentication MUST NOT be used. Client routers SHOULD verify
the public key of the cache to avoid MITM attacks.
</t> </t>
</section> </section>
@ -1581,7 +1605,7 @@ Cache Router
<t> <t>
If TCP MD5 is used, implementations MUST support key lengths If TCP MD5 is used, implementations MUST support key lengths
of at least 80 printable ASCII bytes, per Section 4.5 of of at least 80 printable ASCII bytes, per Section 4.5 of
<xref target="RFC5925"/>. Implementations MUST also support <xref target="RFC2385"/>. Implementations MUST also support
hexadecimal sequences of at least 32 characters, i.e., hexadecimal sequences of at least 32 characters, i.e.,
128 bits. 128 bits.
</t> </t>
@ -1618,12 +1642,12 @@ Cache Router
and a cache may be configured to support a selection of routers. and a cache may be configured to support a selection of routers.
Each must have the name of, and authentication data for, each Each must have the name of, and authentication data for, each
peer. In addition, in a router, this list has a non-unique peer. In addition, in a router, this list has a non-unique
preference value for each server. This preference value for each server. This preference is intended
preference merely denotes proximity, not trust, preferred to be based on proximity, a la RTT, not trust, preferred belief,
belief, et cetera. The client router attempts to establish et cetera. The client router attempts to establish a session
a session with each potential serving cache in preference order with each potential serving cache in preference order and then
and then starts to load data from the most preferred cache to which starts to load data from the most preferred cache to which it
it can connect and authenticate. The router's list of caches has can connect and authenticate. The router's list of caches has
the following elements: the following elements:
<list style="hanging"> <list style="hanging">
<t hangText="Preference:"> <t hangText="Preference:">
@ -1690,9 +1714,9 @@ Cache Router
<section anchor="races" title="ROA PDU Race Minimization"> <section anchor="races" title="ROA PDU Race Minimization">
<t> <t>
When a cache is sending ROA PDUs to a router, especially an When a cache is sending ROA (IPv4 or IPv6) PDUs to a router,
initial full load in response to a Reset Query PDU, two especially an initial full load in response to a Reset Query PDU,
undesirable race conditions are possible: two undesirable race conditions are possible:
<list style="hanging"> <list style="hanging">
<t hangText="Break Before Make:"> <t hangText="Break Before Make:">
For some prefix P, an AS may announce two (or more) ROAs For some prefix P, an AS may announce two (or more) ROAs
@ -1758,10 +1782,10 @@ Cache Router
</t> </t>
<t> <t>
To keep load on Global RPKI services from unnecessary peaks, it To keep load on Global RPKI services from unnecessary peaks, it
is recommended that primary caches which load from the is recommended that caches which fetch from the Global RPKI not
distributed Global RPKI not do so all at the same times, e.g., on do so all at the same times, e.g., on the hour. Choose a random
the hour. Choose a random time, perhaps the ISP's AS number time, perhaps the ISP's AS number modulo 60, and jitter the
modulo 60, and jitter the inter-fetch timing. inter-fetch timing.
</t> </t>
</section> </section>
@ -1834,11 +1858,12 @@ Cache Router
sections. sections.
<list style="hanging"> <list style="hanging">
<t hangText="Cache Validation:"> <t hangText="Cache Validation:">
In order for a collection of caches as described in In order for a collection of caches as described in <xref
<xref target="Scenarios"/> to guarantee a consistent view, target="Scenarios"/> to provide a consistent view, they need
they need to be given consistent trust anchors to use in their to be given consistent trust anchors of the Certification
internal validation process. Distribution of a consistent Authorities to use in their internal validation process.
trust anchor is assumed to be out of band. Distribution of a consistent trust anchor set to validating
caches is assumed to be out of band.
</t> </t>
<t hangText="Cache Peer Identification:"> <t hangText="Cache Peer Identification:">
The router initiates a transport connection to a cache, which it The router initiates a transport connection to a cache, which it
@ -1857,12 +1882,14 @@ Cache Router
inter-cache transport can be lightly protected. inter-cache transport can be lightly protected.
</t> </t>
<t> <t>
However, this protocol document assumes that the routers cannot However, this protocol document assumes that the routers
do the validation cryptography. Hence, the last link, from cannot do the validation cryptography. Hence, the last
cache to router, is secured by server authentication and link, from cache to router, SHOULD be secured by server
transport-level security. This is dangerous, as server authentication and transport-level security to prevent
authentication and transport have very different threat models monkey in the middle attacks; though it might not be. Not
than object security. using transport security is dangerous, as server
authentication and transport have very different threat
models than object security.
</t> </t>
<t> <t>
So the strength of the trust relationship and the transport So the strength of the trust relationship and the transport
@ -1881,9 +1908,9 @@ Cache Router
to a cache. to a cache.
</t> </t>
<t> <t>
The identity of the cache server SHOULD be verified and Reliable transport protocols (i.e. not raw TCP) will
authenticated by the router client, and vice versa, before any authenticate the identity of the cache server to the router
data are exchanged. client, and vice versa, before any data are exchanged.
</t> </t>
<t> <t>
Transports which cannot provide the necessary authentication Transports which cannot provide the necessary authentication
@ -1913,11 +1940,6 @@ Cache Router
allowed in protocol version 2, with the addition of the new ASPA allowed in protocol version 2, with the addition of the new ASPA
PDU. PDU.
</t> </t>
<t>
The policy for adding to the registry is RFC Required per <xref
target="RFC8126"/>; the document must be either Standards Track
or Experimental.
</t>
<t> <t>
The "rpki-rtr-pdu" registry <xref target="iana-pdu"/> has been The "rpki-rtr-pdu" registry <xref target="iana-pdu"/> has been
updated as follows: updated as follows:
@ -1943,19 +1965,6 @@ Cache Router
0-2 255 Reserved 0-2 255 Reserved
</artwork> </artwork>
</figure> </figure>
<t>
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>
Error
Code Description
----- ---------------------------
8 Unexpected Protocol Version
</artwork>
</figure>
</section> </section>
</middle> </middle>
@ -1978,7 +1987,7 @@ Cache Router
</reference> </reference>
<?rfc include="reference.RFC.1982.xml"?> <?rfc include="reference.RFC.1982.xml"?>
<?rfc include="reference.RFC.2119.xml"?> <?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.3629.xml"?> <?rfc include="reference.RFC.2385.xml"?>
<?rfc include="reference.RFC.4252.xml"?> <?rfc include="reference.RFC.4252.xml"?>
<?rfc include="reference.RFC.4301.xml"?> <?rfc include="reference.RFC.4301.xml"?>
<?rfc include="reference.RFC.5280.xml"?> <?rfc include="reference.RFC.5280.xml"?>
@ -1988,11 +1997,13 @@ Cache Router
<?rfc include="reference.RFC.6487.xml"?> <?rfc include="reference.RFC.6487.xml"?>
<?rfc include="reference.RFC.6810.xml"?> <?rfc include="reference.RFC.6810.xml"?>
<?rfc include="reference.RFC.6811.xml"?> <?rfc include="reference.RFC.6811.xml"?>
<?rfc include="reference.RFC.7525.xml"?>
<?rfc include="reference.RFC.8126.xml"?> <?rfc include="reference.RFC.8126.xml"?>
<?rfc include="reference.RFC.8174.xml"?> <?rfc include="reference.RFC.8174.xml"?>
<?rfc include="reference.RFC.8210.xml"?> <?rfc include="reference.RFC.8210.xml"?>
<?rfc include="reference.RFC.8446.xml"?> <?rfc include="reference.RFC.8446.xml"?>
<?rfc include="reference.RFC.8608.xml"?> <?rfc include="reference.RFC.8608.xml"?>
<?rfc include="reference.RFC.8635.xml"?>
</references> </references>
<references title="Informative References"> <references title="Informative References">