diff --git a/draft-ietf-sidrops-8210bis.xml b/draft-ietf-sidrops-8210bis.xml index 782cb50..a2085f4 100644 --- a/draft-ietf-sidrops-8210bis.xml +++ b/draft-ietf-sidrops-8210bis.xml @@ -10,7 +10,7 @@ - + @@ -54,7 +54,7 @@ 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. @@ -116,17 +116,18 @@ - A new ASPA PDU type () has added to - support . + A new ASPA (Autonomous System Provider Authorization) PDU + type () has added to support . - A small section, , has been added to - handle two ROA PDU race conditions, Break Before Make and - Shorter Prefix First. + A small has been added to handle + two ROA (Route Origination Authorization) PDU race + conditions, Break Before Make and Shorter Prefix First. The protocol version number incremented from 1 (one) to 2 - (two) and the section has been + (two) and has been updated accordingly. @@ -146,15 +147,21 @@ Registries (RIRs), National Internet Registries (NIRs), and ISPs; see . + + 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 ). + - A cache is a coalesced copy - of the published Global RPKI data, periodically fetched or - refreshed, directly or indirectly, using the - rsync protocol 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 + 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. "Serial Number" is a @@ -218,11 +225,11 @@
- 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. 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. + + 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. + + + 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. +
@@ -297,7 +314,7 @@ PDUs contain the following data elements: - An 8-bit unsigned integer, currently 1, denoting the + An 8-bit unsigned integer, currently 2, denoting the version of this protocol. @@ -385,17 +402,14 @@ header which includes the length field. - The lowest-order bit of the Flags field is 0 for IPv4 and - 1 for IPv6. - - 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). + 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). 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. - 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. 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. An 8-bit unsigned integer denoting the shortest prefix @@ -438,7 +443,7 @@ A router key's subjectPublicKeyInfo value, as described in - . This is the + . 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 (), 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). @@ -774,27 +779,11 @@ See for an explanation of the use and the range of allowed values for these parameters. - 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. -
- -0 8 16 24 31 -.-------------------------------------------. -| Protocol | PDU | | -| Version | Type | Cache Nonce | -| 0 | 7 | | -+-------------------------------------------+ -| | -| Length=12 | -| | -+-------------------------------------------+ -| | -| Serial Number | -| | -`-------------------------------------------' - -
+ + 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. +
@@ -954,6 +943,7 @@
+
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 ~ | | ~-------------------------------------------~
- The ASPA PDU is to support . 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. 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. - The Flags field is defined as follows: + The Flags field is as described in . + + + + 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. + + + + The AFI Flags field is defined as follows: + +
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
@@ -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. @@ -1076,7 +1083,7 @@ 1 second. 86400 seconds (1 day). - 7200 seconds (2 hours). + 3600 seconds (2 hours). @@ -1124,16 +1131,19 @@
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. If a cache which supports version N receives a query from a - router which specifies version Q < N, the cache MUST downgrade - to protocol version Q or 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 < N, + the cache MUST downgrade to protocol version Q or 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. If a router which supports version N sends a query to a cache @@ -1142,8 +1152,9 @@ 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. The cache may reply with a version C response. In this @@ -1218,7 +1229,7 @@ Cache Router | ----- Cache Response -----> | C confirms request | ------- Payload PDU ------> | C sends zero or more | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, - | ------- Payload PDU ------> | or Router Key PDUs + | ------- Payload PDU ------> | ASPA, or Router Key PDUs | ------- End of Data ------> | C sends End of Data | | and sends new serial ~ ~ @@ -1269,7 +1280,7 @@ Cache Router | ----- Cache Response -----> | C confirms request | ------- Payload PDU ------> | C sends zero or more | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, - | ------- Payload PDU ------> | or Router Key PDUs + | ------- Payload PDU ------> | ASPA. or Router Key PDUs | ------- End of Data ------> | C sends End of Data | | and sends new serial ~ ~ @@ -1309,7 +1320,7 @@ Cache Router | ----- Cache Response -----> | C confirms request | ------- Payload PDU ------> | C sends zero or more | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, - | ------- Payload PDU ------> | or Router Key PDUs + | ------- Payload PDU ------> | ASPA, or Router Key PDUs | ------- End of Data ------> | C sends End of Data | | and sends new serial ~ ~ @@ -1426,7 +1437,7 @@ Cache Router Caches and routers MAY use TCP MD5 transport - using the rpki-rtr port. Note that + using the rpki-rtr port. Note that TCP MD5 has been obsoleted by TCP-AO . @@ -1436,7 +1447,7 @@ Cache Router Caches and routers MAY use Transport Layer Security (TLS) transport - using port rpki-rtr-tls (324); see + using port rpki-rtr-tls (324); see . @@ -1546,7 +1557,7 @@ Cache Router If TCP MD5 is used, implementations MUST support key lengths of at least 80 printable ASCII bytes, per Section 4.5 of - . Implementations MUST also support + . Implementations MUST also support hexadecimal sequences of at least 32 characters, i.e., 128 bits. @@ -1655,20 +1666,20 @@ Cache Router
- 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: 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. If an AS has issued a ROA for P0, and another AS (likely @@ -1732,12 +1743,10 @@ Cache Router
- 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 . 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 . Errors which are considered fatal MUST cause + the session to be dropped. 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. - 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. - 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. The received PDU has a Protocol Version field that differs @@ -1868,26 +1879,24 @@ Cache Router
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 for IANA considerations - from the original (version 0) protocol. + of the previous (version 1) protocol. - 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 in protocol versions 0 and 1 are also + allowed in protocol version 2, with the addition of the new ASPA + PDU. - The policy for adding to the registry is RFC Required per - ; the document must be either Standards Track or - Experimental. + The policy for adding to the registry is RFC Required per ; the document must be either Standards Track + or Experimental. - The "rpki-rtr-pdu" registry has been updated as follows: + The "rpki-rtr-pdu" registry has been + updated as follows:
@@ -1911,9 +1920,9 @@ Cache Router
- 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 remain valid for all protocol versions. + Protocol version 1 added one new error code:
@@ -1930,48 +1939,56 @@ Cache Router - - - - - - - - - - - - - - - - - - - - - - - + + + + rpki-rtr-pdu + + + + + + rpki-rtr-error + + + + + + + + + + + + + + + + + + + + + + - - +
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. No doubt this list is incomplete. We apologize to any