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.
</t>
<t hangText="Serial Number:">
"Serial Number" is 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.
"Serial Number" is 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 Number 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
@ -284,7 +283,7 @@
As a cache server must evaluate certificates and ROAs (Route
Origin Authorizations; see <xref target="RFC6480"/>),
which are time dependent, servers' clocks MUST be correct to a
tolerance of approximately an hour.
tolerance of an hour.
</t>
<t>
Barring errors, transport connections remain up as long as the
@ -322,11 +321,11 @@
e.g., IPv4 Prefix.
</t>
<t hangText="Serial Number:">
The Serial Number of the RPKI cache when this set of PDUs
was received from an upstream cache server or gathered from
the Global RPKI. A cache increments its Serial Number when
completing a rigorously validated update from a parent cache
or the Global RPKI.
A 32-bit unsigned integer serializing the RPKI cache epoc
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 validated
update from a parent cache or the Global RPKI.
</t>
<t hangText="Session ID:">
A 16-bit unsigned integer.
@ -390,11 +389,12 @@
avoid the risk of Session ID collisions.
</t>
<t>
The Session ID might be a pseudorandom value, a
strictly increasing value if the cache has reliable
storage, et cetera. A seconds-since-epoch timestamp
value such as the POSIX time() function makes a good
Session ID value.
The Session ID might be a pseudorandom value, a strictly
increasing value if the cache has reliable storage, et
cetera. A seconds-since-epoch timestamp value such as the
low order 16 bits of unsigned integer seconds since
1970-01-01T00:00:00Z ignoring leap seconds might make a
good Session ID value.
</t>
<t hangText="Length:">
A 32-bit unsigned integer which has as its value the count
@ -402,9 +402,9 @@
header which includes the length field.
</t>
<t hangText="Flags:">
The lowest-order bit of the Flags field is 1 for an
announcement and 0 for a withdrawal. For a Prefix PDU
(IPv4 or IPv6), the announce/withdraw flag indicates
An 8-bit binary field, with the lowest-order bit being 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
@ -437,49 +437,49 @@
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 hangText="Subject Key Identifier:">
The 20-bit 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="RFC8608"/>. This is the
full ASN.1 DER encoding of the subjectPublicKeyInfo,
including the ASN.1 tag and length values of the
subjectPublicKeyInfo SEQUENCE.
<t hangText="Subject Public Key Info:">
A variable length field holding a router key's
subjectPublicKeyInfo value, as described in <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.
</t>
<t hangText="Refresh Interval:">
Interval between normal cache polls. See <xref
target="timing"/>.
A 32-bit interval in seconds between normal cache polls.
See <xref target="timing"/>.
</t>
<t hangText="Retry Interval:">
Interval between cache poll retries after a failed cache poll.
See <xref target="timing"/>.
A 32-bit interval in seconds between cache poll retries
after a failed cache poll. See <xref target="timing"/>.
</t>
<t hangText="Expire Interval:">
Interval during which data fetched from a cache remains
valid in the absence of a successful subsequent cache poll.
See <xref target="timing"/>.
A 32-bit interval in seconds during which data fetched
from a cache remains valid in the absence of a successful
subsequent cache poll. See <xref target="timing"/>.
</t>
<t hangText="AFI Flags:">
A field of the ASPA PDU where the low order bit denotes
whether the AS relationships are for IPv4 (0) or IPv6 (1)
AFI.
An 8-bit field of the ASPA PDU where the low order bit
denotes whether the AS relationships are for IPv4 (0) or
IPv6 (1) AFI.
</t>
<t hangText="Provider AS Count:">
The number of Provider Autonomous System Numbers in the
PDU.
A 16-bit count of Provider Autonomous System Numbers in
the PDU.
</t>
<t hangText="Customer Autonomous System Number:">
The AS number of the Autonomous System that authorizes the
upstream providers listed in the Provider Autonomous
System list to propagate prefixes of the specified address
family other ASes.
The 32-bit AS number of the Autonomous System that
authorizes the upstream providers listed in the Provider
Autonomous System list to propagate prefixes of the
specified address family other ASes.
</t>
<t hangText="Provider Autonomous System Numbers:">
The set of AS numbers authorized to propagate prefixes of
the spacified AFI which were received from the customer
AS.
The set of 32-bit AS numbers authorized to propagate
prefixes of the specified AFI which were received from the
customer AS.
</t>
</list>
</t>
@ -685,6 +685,10 @@
`-------------------------------------------'
</artwork>
</figure>
<t>
This PDU carries an <xref target="RFC6811"/> Vidated ROA
Payload (VRP) for an IPv4 ROA.
</t>
<t>
The lowest-order bit of the Flags field is 1 for an
announcement and 0 for a withdrawal.
@ -746,8 +750,13 @@
`-------------------------------------------'
</artwork>
</figure>
<t>
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.
Analogous to the IPv4 Prefix PDU, it has 96 more bits and no
magic.
</t>
</section>
@ -863,6 +872,10 @@
`-------------------------------------------'
</artwork>
</figure>
<t>
The Router Key PDU transports an <xref target="RFC8635"/>
Router key.
</t>
<t>
The lowest-order bit of the Flags field is 1 for an
announcement and 0 for a withdrawal.
@ -892,6 +905,10 @@
Subject Public Key values as well as SKIs when detecting
duplicate PDUs.
</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 anchor="error" title="Error Report">
@ -906,6 +923,10 @@
<t>
Error codes are described in <xref target="errorcodes"/>.
</t>
<t>
The Erroneous PDU field is a binary copy of the PDU causing
the error condition, including all fields.
</t>
<t>
If the error is generic (e.g., "Internal Error") and not
associated with the PDU to which it is responding, the
@ -924,9 +945,9 @@
MAY be truncated.
</t>
<t>
The diagnostic text is optional; if not present, the Length of
Error Text field MUST be zero. If error text is present, it
MUST be a string in UTF-8 encoding (see <xref target="RFC3629"/>).
The Arbitrary Bytes field is optional; if not present, the
Length of Arbitrary Bytes field MUST be zero. If Arbitrary
Bytes are present, they are, as named, arbitrary values.
</t>
<figure>
<artwork>
@ -949,13 +970,13 @@
| |
+-------------------------------------------+
| |
| Length of Error Text |
| Length of Arbitrary Bytes |
| |
+-------------------------------------------+
| |
| Arbitrary Text |
| Arbitrary Bytes |
| of |
~ Error Diagnostic Message ~
~ Error Diagnostic ~
| |
`-------------------------------------------'
</artwork>
@ -1162,7 +1183,7 @@
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
Arbitrary Bytes field of the ERROR Report PDU MUST be a list of
one octet binary integers indicating the version numbers the
cache supports. The router MUST choose the highest mutally
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
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.
until it gets a new usable load from the cache; maybe once a
minute so as not to DoS the cache.
</t>
</section>
@ -1460,19 +1482,20 @@ Cache Router
example, see <xref target="SSH"/>.
</t>
<t>
Caches and routers MAY use TCP MD5 transport
<xref target="RFC5925"/> using the rpki-rtr port. Note that
TCP MD5 has been obsoleted by TCP-AO
<xref target="RFC5925"/>.
Caches and routers MAY use TCP MD5 transport <xref
target="RFC2385"/> using the rpki-rtr port if no other protected
transport is available. Note that TCP MD5 has been obsoleted by
TCP-AO <xref target="RFC5925"/>.
</t>
<t>
Caches and routers MAY use TCP over IPsec transport
<xref target="RFC4301"/> using the rpki-rtr port.
</t>
<t>
Caches and routers MAY use Transport Layer Security (TLS) transport
<xref target="RFC8446"/> using port rpki-rtr-tls (324); see
<xref target="IANA"/>.
Caches and routers MAY use Transport Layer Security (TLS)
transport <xref target="RFC8446"/> using port rpki-rtr-tls
(324); see <xref target="IANA"/>. Conformance to <xref
target="RFC7525"/> modern cipher suites is REQUIRED.
</t>
</list></t>
@ -1510,10 +1533,11 @@ Cache Router
Cache servers supporting SSH transport MUST accept RSA
authentication and SHOULD accept Elliptic Curve Digital
Signature Algorithm (ECDSA) authentication. User
authentication MUST be supported; host authentication MAY be
supported. Implementations MAY support password
authentication. Client routers SHOULD verify the public key
of the cache to avoid MITM attacks.
authentication "publickey") MUST be supported; host
authentication "hostbased") MAY be supported. Implementations
MAY support password authentication "password"). "None"
authentication MUST NOT be used. Client routers SHOULD verify
the public key of the cache to avoid MITM attacks.
</t>
</section>
@ -1581,7 +1605,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="RFC5925"/>. Implementations MUST also support
<xref target="RFC2385"/>. Implementations MUST also support
hexadecimal sequences of at least 32 characters, i.e.,
128 bits.
</t>
@ -1618,12 +1642,12 @@ Cache Router
and a cache may be configured to support a selection of routers.
Each must have the name of, and authentication data for, each
peer. In addition, in a router, this list has a non-unique
preference value for each server. This
preference merely denotes proximity, not trust, preferred
belief, et cetera. The client router attempts to establish
a session with each potential serving cache in preference order
and then starts to load data from the most preferred cache to which
it can connect and authenticate. The router's list of caches has
preference value for each server. This preference is intended
to be based on proximity, a la RTT, not trust, preferred belief,
et cetera. The client router attempts to establish a session
with each potential serving cache in preference order and then
starts to load data from the most preferred cache to which it
can connect and authenticate. The router's list of caches has
the following elements:
<list style="hanging">
<t hangText="Preference:">
@ -1690,9 +1714,9 @@ Cache Router
<section anchor="races" title="ROA PDU Race Minimization">
<t>
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:
When a cache is sending ROA (IPv4 or IPv6) 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
@ -1758,10 +1782,10 @@ Cache Router
</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.
is recommended that caches which fetch from the 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>
@ -1834,11 +1858,12 @@ Cache Router
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.
In order for a collection of caches as described in <xref
target="Scenarios"/> to provide a consistent view, they need
to be given consistent trust anchors of the Certification
Authorities to use in their internal validation process.
Distribution of a consistent trust anchor set to validating
caches is assumed to be out of band.
</t>
<t hangText="Cache Peer Identification:">
The router initiates a transport connection to a cache, which it
@ -1857,12 +1882,14 @@ Cache Router
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.
However, this protocol document assumes that the routers
cannot do the validation cryptography. Hence, the last
link, from cache to router, SHOULD be secured by server
authentication and transport-level security to prevent
monkey in the middle attacks; though it might not be. Not
using transport security 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
@ -1881,9 +1908,9 @@ Cache Router
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.
Reliable transport protocols (i.e. not raw TCP) will
authenticate the identity of the cache server to the router
client, and vice versa, before any data are exchanged.
</t>
<t>
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
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.
</t>
<t>
The "rpki-rtr-pdu" registry <xref target="iana-pdu"/> has been
updated as follows:
@ -1943,19 +1965,6 @@ Cache Router
0-2 255 Reserved
</artwork>
</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>
</middle>
@ -1978,7 +1987,7 @@ Cache Router
</reference>
<?rfc include="reference.RFC.1982.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.4301.xml"?>
<?rfc include="reference.RFC.5280.xml"?>
@ -1988,11 +1997,13 @@ Cache Router
<?rfc include="reference.RFC.6487.xml"?>
<?rfc include="reference.RFC.6810.xml"?>
<?rfc include="reference.RFC.6811.xml"?>
<?rfc include="reference.RFC.7525.xml"?>
<?rfc include="reference.RFC.8126.xml"?>
<?rfc include="reference.RFC.8174.xml"?>
<?rfc include="reference.RFC.8210.xml"?>
<?rfc include="reference.RFC.8446.xml"?>
<?rfc include="reference.RFC.8608.xml"?>
<?rfc include="reference.RFC.8635.xml"?>
</references>
<references title="Informative References">