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

clean up to be neither obsoletes nor updates :)

Browse source
This commit is contained in:
Randy Bush 2022-06-16 17:36:35 -07:00
parent b3fb05aef0
commit ee0f023856
1 changed files with 97 additions and 82 deletions
Download patch file Download diff file Expand all files Collapse all files

179
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-09" submissionType="IETF" updates="8210" ipr="trust200902" consensus="yes">
<rfc category="std" docName="draft-ietf-sidrops-8210bis-10" submissionType="IETF" 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 updates and replaces RFC 8210.
This document is compatible with both.
</t>
</abstract>
@ -65,17 +65,24 @@
<section anchor="Intro" title="Introduction">
<t>
In order to verifiably validate the origin Autonomous Systems
(ASs) 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 them. The design is intentionally constrained to be
usable on much of the current generation of ISP router
platforms.
(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
them. The design is intentionally constrained to be usable on
much of the current generation of ISP router platforms.
</t>
<t>This document updates <xref target="RFC8210"/>.</t>
<t>
This specification documents version 2 of the RPKI-RTR protocol.
Earlier versions are documented in <xref target="RFC6810"/> and
<xref target="RFC8210"/>. Though this version is, of course,
preferred, the earlier versions are expected to continue to be
productively deployed indefinitely, and <xref target="version"/>
details how to downgrade from this version to earlier versions
as needed in order to interoperate.
</t>
<t>
<xref target="Struct"/> describes the deployment structure, and
@ -122,13 +129,14 @@
</t>
<t>
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.
two possible 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 <xref target="version"/> has been
updated accordingly.
(two) and <xref target="version"/> has been updated
accordingly.
</t>
</list>
</t>
@ -236,12 +244,12 @@
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 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.
Periodically, the router sends a Serial Query to the cache the
most recent Serial Number for which it 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
@ -293,7 +301,7 @@
<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.
the cache with two many failed requests.
</t>
</section>
@ -321,7 +329,7 @@
e.g., IPv4 Prefix.
</t>
<t hangText="Serial Number:">
A 32-bit unsigned integer serializing the RPKI cache epoc
A 32-bit unsigned integer serializing the RPKI cache epoch
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
@ -438,7 +446,7 @@
announce a prefix or associated with a router key.
</t>
<t hangText="Subject Key Identifier:">
The 20-bit Subject Key Identifier (SKI) value of a router
The 20-octet Subject Key Identifier (SKI) value of a router
key, as described in <xref target="RFC6487"/>.
</t>
<t hangText="Subject Public Key Info:">
@ -474,7 +482,7 @@
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.
specified address family to other ASes.
</t>
<t hangText="Provider Autonomous System Numbers:">
The set of 32-bit AS numbers authorized to propagate
@ -686,7 +694,7 @@
</artwork>
</figure>
<t>
This PDU carries an <xref target="RFC6811"/> Vidated ROA
This PDU carries an <xref target="RFC6811"/> Validated ROA
Payload (VRP) for an IPv4 ROA.
</t>
<t>
@ -751,7 +759,7 @@
</artwork>
</figure>
<t>
This PDU carries an <xref target="RFC6811"/> Vidated ROA
This PDU carries an <xref target="RFC6811"/> Validated ROA
Payload (VRP) for an IPv6 ROA.
</t>
<t>
@ -945,9 +953,10 @@
MAY be truncated.
</t>
<t>
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.
The Arbitrary Text field is optional; if not present, the
Length of Arbitrary text field MUST be zero. If Arbitrary
Text is present, it MUST be a string in UTF-8 encoding (see
<xref target="RFC3629"/>) in the Queen's English.
</t>
<figure>
<artwork>
@ -970,13 +979,13 @@
| |
+-------------------------------------------+
| |
| Length of Arbitrary Bytes |
| Length of Arbitrary Text |
| |
+-------------------------------------------+
| |
| Arbitrary Bytes |
| of |
~ Error Diagnostic ~
| Arbitrary Text |
~ of ~
| Error Diagnostic Message |
| |
`-------------------------------------------'
</artwork>
@ -1015,20 +1024,17 @@
<t>
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
represents one single customer AS and its provider ASes for a
particular Address Family. Receipt of an 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 AFI 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.
field), replaces the previous one. 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 for a given AFI from a
The router MUST see at most one ASPA for a given AFI 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 RPKI records for a single
@ -1057,18 +1063,9 @@
</t>
<t>
The AFI Flags field is defined as follows:
The AFI Flags field is defined in <xref target="IANA"/>.
</t>
<figure>
<artwork>
Bit Bit Name
---- -------------------
0 AFI (IPv4 == 0, IPv6 == 1)
1-7 Reserved, MUST be zero
</artwork>
</figure>
<t>
The Provider AS Count is the number of 32-bit Provider
Autonomous System Numbers in the PDU.
@ -1076,10 +1073,10 @@
<t>
The Customer Autonomous System Number is the 32-bit Autonomous
System Number of the customer which authenticated the PDU.
For a given AFI, there MUST be one and only one ASPA for a
Customer Autonomous System Number active in the router at any
time.
System Number of the customer which authenticated the ASPA
RPKI data. For a given AFI, there MUST be one and only one
ASPA for a Customer Autonomous System Number active in the
router at any time.
</t>
<t>
@ -1171,18 +1168,16 @@
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 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 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
session, sending a version 2 Error Report PDU with Error Code 4
("Unsupported Protocol Version").
If a cache which supports version N receives a Reset Query with
Version Q &lt; N, the cache MUST downgrade to protocol version Q
<xref target="RFC6810"/> or <xref target="RFC8210"/>. If the
router's Reset Request was Q &gt; N, the cache MUST send a
version 2 Error Report PDU with Error Code 4 ("Unsupported
Protocol Version"), and the router MUST send another Reset Query
with a lower Version Q. Yjis MAY repeat. If the router
requests Q == 0 and it still fails, then the router MUST abort
the session, sending a version 2 Error Report PDU with Error
Code 4 ("Unsupported Protocol Version").
</t>
<t>
If a router which supports version N sends a query to a cache
@ -1204,7 +1199,7 @@
</t>
<t>
In any of the downgraded combinations above, the new features of
the higher version will not be available, and all PDUs will have
the higher version will not be available, and all PDUs MUST have
the negotiated lower version number in their version fields.
</t>
<t>
@ -1277,16 +1272,16 @@ Cache Router
<t>
When a transport connection is first established, the router
MUST send either a Reset Query or a Serial Query. A Serial
Query would be appropriate if the router has significant
unexpired data from a broken session with the same cache and
remembers the Session ID of that session, in which case a
Serial Query containing the Session ID from the previous
session will allow the router to bring itself up to date
while ensuring that the Serial Numbers are commensurate and
that the router and cache are speaking compatible versions
of the protocol. In all other cases, the router lacks the
necessary data for fast resynchronization and therefore
MUST fall back to a Reset Query.
Query would be appropriate if the router has unexpired data
from a broken session with the same cache and remembers the
Session ID of that session, in which case a Serial Query
containing the Session ID from the previous session will allow
the router to bring itself up to date while ensuring that the
Serial Numbers are commensurate and that the router and cache
are speaking compatible versions of the protocol. In all
other cases, the router lacks the necessary data for fast
resynchronization and therefore MUST fall back to a Reset
Query.
</t>
<t>
The Reset Query sequence is also used when the router
@ -1588,8 +1583,9 @@ Cache Router
<xref target="RFC6125"/>.
</t>
<t>
The client router MUST set its "reference identifier" to
the DNS name of the rpki-rtr cache.
The client router MUST set its "reference identifier" (see
Section 6.2 of <xref target="RFC6125"/>) to the DNS name
of the rpki-rtr cache.
</t>
</list>
</t>
@ -1636,7 +1632,7 @@ 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 is intended
preference value for each cache. 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
@ -1902,7 +1898,7 @@ Cache Router
to a cache.
</t>
<t>
Reliable transport protocols (i.e. not raw TCP) will
Authenticating 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>
@ -1959,6 +1955,24 @@ Cache Router
0-2 255 Reserved
</artwork>
</figure>
<t>
This document requests the IANA to create a registry for ASPA
AFI Flags 0 to 7. The name of the registry should be
rpki-rtr-afi. The policy for adding to the registry is Expert
Review per <xref target="RFC8126"/>, where the responsible IESG
area director should appoint the Expert Reviewer. The initial
entries should be as follows:
<figure>
<artwork>
Bit Bit Name
---- -------------------
0 AFI (IPv4 == 0, IPv6 == 1)
1-7 Reserved, MUST be zero
</artwork>
</figure>
</t>
</section>
</middle>
@ -1982,6 +1996,7 @@ Cache Router
<?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.5280.xml"?>