diff --git a/draft-ietf-sidrops-8210bis.xml b/draft-ietf-sidrops-8210bis.xml index 9840565..d5d0282 100644 --- a/draft-ietf-sidrops-8210bis.xml +++ b/draft-ietf-sidrops-8210bis.xml @@ -8,7 +8,7 @@ - @@ -43,17 +43,18 @@ - In order to verifiably validate the origin Autonomous Systems - and Autonomous System Paths of BGP announcements, routers need - a simple but reliable mechanism to receive Resource Public Key - Infrastructure (RFC 6480) prefix origin data and router keys - from a trusted cache. This document describes a protocol to - deliver them. + In order to validate the origin Autonomous Systems (ASes) and + Autonomous System relationships behind BGP announcements, + routers need a simple but reliable mechanism to receive Resource + Public Key Infrastructure (RFC6480) prefix origin data and + Router Keys from a trusted cache. This document describes a + protocol to deliver them. This document describes version 2 of the RPKI-Router protocol. - RFC 6810 describes version 0, and RFC 8210 describes version 1. - This document is compatible with both. + describes version 0, and describes version 1. This document is + compatible with both. @@ -67,7 +68,7 @@ (ASes) and AS paths of BGP announcements, routers need a simple but reliable mechanism to receive cryptographically validated Resource Public Key Infrastructure (RPKI) prefix origin data and router keys from a + 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. @@ -112,7 +113,7 @@ and only when, they appear in all capitals, as shown here. -
+
This section summarizes the significant changes between and the protocol described in this @@ -128,7 +129,7 @@ A small has been added to handle two possible ROA (Route Origination Authorization) PDU - race conditions, Break Before Make and Shorter Prefix + race conditions, Make Before Break and Shorter Prefix First. @@ -137,8 +138,8 @@ The protocol version number incremented from 1 (one) to 2 - (two) and has been updated - accordingly. + (two) and on Protocol Version + Negotiation has been updated accordingly. @@ -192,7 +193,7 @@ to uniquely identify the instance of the cache and to bind it to the sequence of Serial Numbers that cache instance will generate. This allows the router to restart a - failed session knowing that the Serial Number it is using is + session knowing that the Serial Number it is using is commensurate with that of the cache. @@ -247,20 +248,21 @@ on their caches and the Global RPKI. - A VRP is effective if it is in the fetched set from any of the - currently preferred caches. Therefore, a VRP takes effect on - the router when the first cache serves that VRP, and the VRP is - in effect until the last cache withdraws that VRP. Thus, in a - global sense, the effect of a VRP announcement propagates more - quickly than a withdraw, + A Validated ROA Payload (VRP, see ) is + effective if it is in the fetched set from any of the currently + preferred caches. Therefore, a VRP takes effect on the router + when the first cache serves that VRP, and the VRP is in effect + until the last cache withdraws that VRP. Thus, in a global + sense, the effect of a VRP announcement propagates more quickly + than a withdraw. - 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. + Periodically, the router sends a Serial Query to the cache + specifying the most recent Serial Number for which it has + received data from that cache, i.e., the router's current Serial + Number for that cache, 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. The cache responds to the Serial Query with all data changes @@ -271,16 +273,17 @@ into account; see . - When the router has received all data records from the cache, - it sets its current Serial Number to that of the Serial Number - in the received End of Data PDU. + When the router receives an End of Data PDU, it has received all + current data from the cache. It then sets its current Serial + Number for that cache to that of the Serial Number in the + received End of Data PDU. When the cache updates its database, it sends a Notify PDU to - every currently connected router. This is a hint - that now would be a good time for the router to poll for an - update, but it is only a hint. The protocol requires the router - to poll for updates periodically in any case. + every currently connected router. This is a hint that now would + be a good time for the router to poll for an update, but it is + only a hint. The protocol requires the router to poll for + updates periodically in any case. Strictly speaking, a router could track a cache simply by @@ -299,10 +302,9 @@ provide better service. - As a cache server must evaluate certificates and ROAs (Route - Origin Authorizations; see ), - which are time dependent, servers' clocks MUST be correct to a - tolerance of an hour. + As cache servers must evaluate signed objects (see ) with time dependent validity periods, + servers' clocks MUST be correct within a tolerance of an hour. Barring errors, transport connections remain up as long as the @@ -337,7 +339,7 @@ An 8-bit unsigned integer, denoting the type of the PDU, - e.g., IPv4 Prefix. + e.g., Type 4, IPv4 Prefix. A 32-bit unsigned integer serializing the RPKI cache epoch @@ -364,8 +366,8 @@ Note that sessions are specific to a particular protocol - version. That is, if a cache server supports multiple - versions of this protocol, happens to use the same + version. That is, if a cache server which supports multiple + versions of this protocol happens to use the same Session ID value for multiple protocol versions, and further happens to use the same Serial Number values for two or more sessions using the same Session ID but @@ -384,7 +386,7 @@ router does not realize that the session has changed (old Session ID and new Session ID have the same numeric value), the router may become confused as to the content of the cache. - The time it takes the router to discover that it is confused + The time it takes the router to discover this will depend on whether the Serial Numbers are also reused. If the Serial Numbers in the old and new sessions are different enough, the cache will respond to the router's Serial Query @@ -417,7 +419,7 @@ A 32-bit unsigned integer which has as its value the count - of the bytes in the entire PDU, including the 8 bytes of + of the octets in the entire PDU, including the 8 octets of header which includes the length field. @@ -428,13 +430,18 @@ 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 + and Autonomous System Number (AS). + + + Similarly, for a Router Key PDU, the flag indicates + whether this PDU announces a new Router Key or deletes a previously announced Router Key PDU with the exact same AS - Number, subjectKeyIdentifier, and - subjectPublicKeyInfo. + Number, subjectKeyIdentifier, and subjectPublicKeyInfo. + + + Similarly, for an ASPA PDU, the flag indicates a new or + replacement mapping of the specified Customer AS to a set of + Provider ASes or the removal of the existant mapping. The remaining bits in the Flags field are reserved for @@ -453,15 +460,16 @@ The IPv4 or IPv6 prefix of the ROA. - A 32-bit unsigned integer representing an ASN allowed to - announce a prefix or associated with a router key. + A 32-bit unsigned integer representing an AS allowed to + announce a prefix, associated with a Router Key, or ASPA + Customer or Provider. The 20-octet Subject Key Identifier (SKI) value of a router key, as described in . - A variable length field holding a router key's + A variable length field holding a Router Key's subjectPublicKeyInfo value, as described in . This is the full ASN.1 DER encoding of the subjectPublicKeyInfo, including the ASN.1 tag and @@ -483,8 +491,8 @@ 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 to other ASes. + Autonomous System list to propagate prefixes to other + ASes. The set of 32-bit AS numbers authorized to propagate @@ -495,34 +503,6 @@
- - The cache notifies the router that the cache has new data. - - - The Session ID reassures the router that the Serial Numbers - are commensurate, i.e., the cache session has not been - changed. - - - Upon receipt of a Serial Notify PDU, the router MAY issue an - immediate Serial Query () or - Reset Query () without waiting for - the Refresh Interval timer (see ) - to expire. - - - Serial Notify is the only message that the cache can send - that is not in response to a message from the router. - - - If the router receives a Serial Notify PDU during the - initial startup period where the router and cache are still - negotiating to agree on a protocol version, the router - MUST simply ignore the Serial Notify PDU, even if the - Serial Notify PDU is for an unexpected protocol version. - See for details. - -
0 8 16 24 31 @@ -541,9 +521,55 @@ `-------------------------------------------'
+ + The cache notifies the router that the cache has new data. + + + The Session ID reassures the router that the Serial Numbers + are commensurate, i.e., the cache session has not been + changed. + + + Upon receipt of a Serial Notify PDU, the router MAY issue an + immediate Serial Query () or + Reset Query () without waiting for + the Refresh Interval timer (see ) + to expire. + + + Serial Notify is the only message that the cache MAY send + that is not in response to a message from the router. + + + If the router receives a Serial Notify PDU during the + initial startup period where the router and cache are still + negotiating to agree on a protocol version, the router + MUST simply ignore the Serial Notify PDU, even if the + Serial Notify PDU is for an unexpected protocol version. + See for details. + +
+
+ +0 8 16 24 31 +.-------------------------------------------. +| Protocol | PDU | | +| Version | Type | Session ID | +| 2 | 1 | | ++-------------------------------------------+ +| | +| Length=12 | +| | ++-------------------------------------------+ +| | +| Serial Number | +| | +`-------------------------------------------' + +
The router sends a Serial Query to ask the cache for all announcements and withdrawals which have @@ -560,7 +586,7 @@ When replying to a Serial Query, the cache MUST return the minimum set of changes needed to bring the router into sync - with the cache. That is, if a particular prefix, router key, + with the cache. That is, if a particular prefix, Router Key, or ASPA underwent multiple changes between the Serial Number specified by the router and the cache's current Serial Number, the cache MUST merge those changes to present the simplest @@ -594,34 +620,9 @@ expects to ensure that the Serial Numbers are commensurate, i.e., the cache session has not been changed. -
- -0 8 16 24 31 -.-------------------------------------------. -| Protocol | PDU | | -| Version | Type | Session ID | -| 2 | 1 | | -+-------------------------------------------+ -| | -| Length=12 | -| | -+-------------------------------------------+ -| | -| Serial Number | -| | -`-------------------------------------------' - -
- - The router tells the cache that it wants to - receive the total active, current, non-withdrawn database. - The cache responds with a Cache Response PDU - (), followed by zero or more - payload PDUs and an End of Data PDU (). -
0 8 16 24 31 @@ -636,27 +637,16 @@ `-------------------------------------------'
+ + The router tells the cache that it wants to + receive the total active, current, non-withdrawn database. + The cache responds with a Cache Response PDU + (), followed by zero or more + payload PDUs and an End of Data PDU (). +
- - The cache responds to queries with zero or more payload - PDUs. When replying to a Serial Query - (), the cache sends the set of - announcements and withdrawals that have occurred since the - 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 - announce/withdraw field in the payload PDUs MUST have the - value 1 (announce). - - - In response to a Reset Query, the new value of the Session ID - tells the router the instance of the cache session for future - confirmation. In response to a Serial Query, the Session ID - being the same reassures the router that the Serial Numbers - are commensurate, i.e., the cache session has not been changed. -
0 8 16 24 31 @@ -671,6 +661,25 @@ `-------------------------------------------'
+ + The cache responds to queries with zero or more payload + PDUs. When replying to a Serial Query + (), the cache sends the set of + announcements and withdrawals necessary to bring the router's + state current with all changes that have occurred since the + 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 + announce/withdraw field in the payload PDUs MUST have the + value 1 (announce). + + + In response to a Reset Query, the new value of the Session ID + tells the router the instance of the cache session for future + confirmation. In response to a Serial Query, the Session ID + being the same reassures the router that the Serial Numbers + are commensurate, i.e., the cache session has not been changed. +
@@ -701,35 +710,37 @@ - This PDU carries an Validated ROA - Payload (VRP) for an IPv4 ROA. + This PDU carries a VRP for an IPv4 ROA . The lowest-order bit of the Flags field is 1 for an announcement and 0 for a withdrawal. + - In the RPKI, there is also an actual need for what might - appear to a router as identical IPvX PDUs. - This can occur when an upstream certificate is being reissued - or there is an address ownership transfer up the validation - chain. The ROA would be identical in the router sense, - i.e., have the same {Prefix, Len, Max-Len, ASN}, but it would - have a different validation path in the RPKI. This is - important to the RPKI but not to the router. + In the RPKI, there is an actual need for what might appear to + a router as identical IPvX PDUs. This can occur when an + upstream certificate is being reissued or there is an address + ownership transfer up the validation chain. The ROA would be + identical in the router sense, i.e., have the same {Prefix, + Len, Max-Len, AS}, but it would have a different validation + path in the RPKI. This is important to the RPKI but not to + the router. The cache server MUST ensure that it has told the router client to have one and only one IPvX PDU for a unique {Prefix, - Len, Max-Len, ASN} at any one point in time. Should the + Len, Max-Len, AS} at any one point in time. Should the router client receive an IPvX PDU with a {Prefix, Len, - Max-Len, ASN} identical to one it already has active, it + Max-Len, AS} identical to one it already has active, it SHOULD raise a Duplicate Announcement Received error.
@@ -766,8 +777,8 @@ - This PDU carries an Validated ROA - Payload (VRP) for an IPv6 ROA. + This PDU carries a VRP for an IPv6 ROA . Analogous to the IPv4 Prefix PDU, it has 96 more bits and no @@ -776,14 +787,6 @@
- - The cache tells the router it has no more data for the request. - - - The Session ID and Protocol Version MUST be the same as that of - the corresponding Cache Response which began the (possibly null) - sequence of payload PDUs. -
0 8 16 24 31 @@ -814,6 +817,15 @@ `-------------------------------------------'
+ + A cache sends an End of Data record to tell the router it has + no more data for the request. + + + The Session ID and Protocol Version MUST be the same as that of + the corresponding Cache Response which began the (possibly null) + sequence of payload PDUs. + The Refresh Interval, Retry Interval, and Expire Interval are all 32-bit elapsed times measured in seconds. They express @@ -825,19 +837,12 @@ 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. + versions 0 and 1. The Version 2 End of Data PDU is the same + as that of Version 1.
- - The cache may respond to a Serial Query informing the router - that the cache cannot provide an incremental update - starting from the Serial Number specified by the router. - The router must decide whether to issue a Reset Query or - switch to a different cache. -
0 8 16 24 31 @@ -852,6 +857,13 @@ `-------------------------------------------'
+ + The cache sends a Cache Reset PDU in response to a Serial + Query in order to inform the router that the cache cannot + provide an incremental update starting from the Serial Number + specified by the router. The router must decide whether to + issue a Reset Query or perhaps switch to a different cache. +
@@ -882,14 +894,14 @@ | | +-------------------------------------------+ | | -| Subject Public Key Info | +~ Subject Public Key Info ~ | | `-------------------------------------------' - The Router Key PDU transports an - Router key. + The Router Key PDU transports they payload of a Router Key + . The lowest-order bit of the Flags field is 1 for an @@ -898,17 +910,17 @@ The cache server MUST ensure that it has told the router client to have one and only one Router Key PDU for a unique - {SKI, ASN, Subject Public Key} at any one point in time. + {SKI, AS, Subject Public Key} at any one point in time. Should the router client receive a Router Key PDU with a - {SKI, ASN, Subject Public Key} identical to one it already + {SKI, AS, Subject Public Key} identical to one it already has active, it SHOULD raise a Duplicate Announcement Received error. - Note that a particular ASN may appear in multiple Router Key + Note that a particular AS may appear in multiple Router Key PDUs with different Subject Public Key values, while a particular Subject Public Key value may appear in multiple - Router Key PDUs with different ASNs. In the interest of + Router Key PDUs with different ASes. In the interest of keeping the announcement and withdrawal semantics as simple as possible for the router, this protocol makes no attempt to compress either of these cases. @@ -927,6 +939,38 @@
+
+ +0 8 16 24 31 +.-------------------------------------------. +| Protocol | PDU | | +| Version | Type | Error Code | +| 2 | 10 | | ++-------------------------------------------+ +| | +| Length | +| | ++-------------------------------------------+ +| | +| Length of Encapsulated PDU | +| | ++-------------------------------------------+ +| | +~ Erroneous PDU ~ +| | ++-------------------------------------------+ +| | +| Length of Arbitrary Text | +| | ++-------------------------------------------+ +| | +| Arbitrary Text | +~ of ~ +| Error Diagnostic Message | +| | +`-------------------------------------------' + +
This PDU is used by either party to report an error to the other. @@ -965,38 +1009,6 @@ Text is present, it MUST be a string in UTF-8 encoding (see ) in the Queen's English. -
- -0 8 16 24 31 -.-------------------------------------------. -| Protocol | PDU | | -| Version | Type | Error Code | -| 2 | 10 | | -+-------------------------------------------+ -| | -| Length | -| | -+-------------------------------------------+ -| | -| Length of Encapsulated PDU | -| | -+-------------------------------------------+ -| | -~ Erroneous PDU ~ -| | -+-------------------------------------------+ -| | -| Length of Arbitrary Text | -| | -+-------------------------------------------+ -| | -| Arbitrary Text | -~ of ~ -| Error Diagnostic Message | -| | -`-------------------------------------------' - -
@@ -1020,60 +1032,59 @@ | | ~ Provider Autonomous System Numbers ~ | | -~-------------------------------------------~ +`-------------------------------------------/ - + The ASPA PDU supports . An ASPA PDU - represents one single customer AS and its provider ASes. - 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 replaces the previous one. - The cache MUST deliver the complete data of an ASPA record in - a single ASPA PDU. + target="I-D.ietf-sidrops-aspa-profile"/>. - - - The router MUST 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 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 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. - - - If the announce/withdraw flag is set to 0, it indicates - removal of the entire ASPA record for that Customer AS. Here, - the customer AS of the ASPA record MUST be provided, the - Provider list MUST be null, and the PDU Length MUST be 12. - - The Customer Autonomous System Number is the 32-bit Autonomous System Number of the customer which authenticated the ASPA - RPKI data. There MUST be one and only one ASPA for a Customer - Autonomous System Number active in the router at any time. + RPKI data. - There are zero or more 32-bit Provider Autonomous System Number fields in increasing numeric order. See . + + The Flags field is as described in . + + + The router MUST see at most one ASPA from a particular 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 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. + + + 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 from that cache replaces the + previous one. The cache MUST deliver the complete data of an + ASPA record in a single ASPA PDU. + + + 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 from that cache + with the same Customer Autonomous System Number. For an + announcemnt, the PDU MUST contain at least one Provider + Autonomous System Number or an Error PDU with code 9, ASPA + Provider List Error is returned. + + + If the announce/withdraw flag is set to 0, the entire ASPA + record from that cache for that Customer AS MUST be removed + from the router. The customer AS of the ASPA record MUST be + provided, there MUST be no Provider list, and the PDU Length + MUST be 12. +
@@ -1081,15 +1092,16 @@
- Since the data the cache distributes via the RPKI-Router + Since the data the cache distributed via the RPKI-Router protocol are retrieved from the Global RPKI system at intervals which are only known to the cache, only the cache can really know how frequently it makes sense for the router to poll the cache, or how long the data are likely to remain valid (or, at - least, unchanged). For this reason, as well as to allow the - cache some control over the load placed on it by its client - routers, the End Of Data PDU includes three values that allow - the cache to communicate timing parameters to the router: + least, not significantly changed). For this reason, as well as + to allow the cache some control over the load placed on it by + its client routers, the End Of Data PDU includes three values + that allow the cache to communicate timing parameters to the + router: @@ -1173,11 +1185,11 @@ If a cache which supports version C receives a query with Protocol Version Q < C, and the cache can support version Q, - the cache MUST downgrade to protocol version Q, or , and respond with - a Cache Response () of that - Protocol Version, Q, and the RPKI-Rtr session is considered - open. + the cache MUST establish the session at protocol version Q, + or , and + respond with a Cache Response () + of that Protocol Version, Q, and the RPKI-Rtr session is + considered open. If the the cache which supports C as its highest verion receives @@ -1208,17 +1220,17 @@ The router MUST ignore any Serial Notify PDUs it might receive - from the cache during this initial startup period, regardless - of the Protocol Version field in the Serial Notify PDU. Since - Session ID and Serial Number values are specific to a - particular protocol version, the values in the notification - are not useful to the router. Even if these values were - meaningful, the only effect that processing the notification - would have would be to trigger exactly the same Reset Query or - Serial Query that the router has already sent as part of the - not-yet-complete version negotiation process, so there is - nothing to be gained by processing notifications until version - negotiation completes. + from the cache during this initial startup period, regardless of + the Protocol Version field in the Serial Notify PDU. Since + Session ID and Serial Number values are specific to a particular + protocol version, the values in the notification are not useful + to the router. Even if these values were meaningful, the only + effect that processing the notification would have would be to + trigger exactly the same Reset Query or Serial Query that the + router has already sent as part of the not-yet-complete version + negotiation process, so there is nothing to be gained by + processing Serial Notify PDUs until version negotiation + completes. Caches SHOULD NOT send Serial Notify PDUs before version @@ -1321,7 +1333,7 @@ Cache Router | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, | ------- Payload PDU ------> | ASPA. or Router Key PDUs | ------- End of Data ------> | C sends End of Data - | | and sends new serial + | | containing the new serial ~ ~ @@ -1361,7 +1373,7 @@ Cache Router | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, | ------- Payload PDU ------> | ASPA, or Router Key PDUs | ------- End of Data ------> | C sends End of Data - | | and sends new serial + | | containing the new serial ~ ~ @@ -1372,7 +1384,7 @@ Cache Router router. This might be because the cache has lost state, or because the router has waited too long between polls and the cache has cleaned up old data that it no longer believes it - needs, or because the cache has run out of storage space and + needed, or because the cache has run out of storage space and had to expire some old data early. Regardless of how this state arose, the cache replies with a Cache Reset to tell the router that it cannot honor the request. When a router @@ -1408,7 +1420,7 @@ Cache Router such a state without dropping any of its active sessions, a router is more likely to see this behavior when it initially connects and issues a Reset Query while the cache - is still rebuilding its database. + is still [re]building its database. When a router receives this kind of error, the router @@ -1416,7 +1428,7 @@ Cache Router 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; maybe once a - minute so as not to DoS the cache. + minute or less frequently so as not to DoS the cache.
@@ -1425,7 +1437,7 @@ Cache Router
The transport-layer session between a router and a cache - carries the binary PDUs in a persistent session. + carries the binary PDUs in a persistent reliable session. To prevent cache spoofing and DoS attacks by illegitimate @@ -1443,6 +1455,17 @@ Cache Router caches and routers SHOULD enable keep-alives when available in the chosen transport protocol. + + Should the cache or the router experience a transport stall + (e.g. the peer advertised a TCP RCV.WND + of zero) for longer than three times + the Retry Interval (a la BGP's hold timer being three times the + keepalive interval), the transport session should be terminated. + + + A cache SHOULD NOT use a separate TCP segment for each PDU, but + rather try to pack PDUs efficiently. + It is expected that, when the TCP Authentication Option (TCP-AO) is available on all @@ -1468,22 +1491,22 @@ Cache Router Caches and routers SHOULD use TCP-AO transport - over the rpki-rtr port. + over the rpki-rtr port (323). Caches and routers MAY use Secure Shell version 2 (SSHv2) transport - using the normal SSH port. For an + using the normal SSH port (22). For an example, see . Caches and routers MAY use TCP MD5 transport using the rpki-rtr port if no other protected + target="RFC2385"/> using the rpki-rtr port (323) if no other protected transport is available. Note that TCP MD5 has been obsoleted by TCP-AO . Caches and routers MAY use TCP over IPsec transport - using the rpki-rtr port. + using the rpki-rtr port (323). Caches and routers MAY use Transport Layer Security (TLS) @@ -1524,14 +1547,11 @@ Cache Router out of band by some reasonably secured means. - Cache servers supporting SSH transport MUST accept RSA - authentication and SHOULD accept Elliptic Curve Digital - Signature Algorithm (ECDSA) authentication. User - 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. + User 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.
@@ -1539,7 +1559,7 @@ Cache Router Client routers using TLS transport MUST present client-side certificates to authenticate themselves to the cache in - order to allow the cache to manage the load by rejecting + order to allow the cache to manage their load by rejecting connections from unauthorized routers. In principle, any type of certificate and Certification Authority (CA) may be used; however, in general, cache operators will wish to @@ -1599,7 +1619,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 + of at least 80 printable ASCII octets, per Section 4.5 of . Implementations MUST also support hexadecimal sequences of at least 32 characters, i.e., 128 bits. @@ -1613,7 +1633,7 @@ Cache Router
Implementations MUST support key lengths of at least 80 - printable ASCII bytes. Implementations MUST also support + printable ASCII octets. Implementations MUST also support hexadecimal sequences of at least 32 characters, i.e., 128 bits. Message Authentication Code (MAC) lengths of at least 96 bits MUST be supported, per Section 5.1 of @@ -1685,7 +1705,7 @@ Cache Router from that cache. - The client SHOULD attempt to maintain at least one set of data, + The router SHOULD attempt to maintain at least one set of data, regardless of whether it has chosen a different cache or established a new connection to the previous cache. @@ -1718,29 +1738,39 @@ Cache Router 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: + 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 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. + For some prefix P, an operator may create two or more ROAs + with different ASes because they are in the process of changing + what provider AS may announce 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. - If an AS has issued a ROA for P0, and another AS (likely - their customer) has issued a ROA for P1 which is a + If an operator has created a ROA for P0, and another operator + (likely their customer) has issued a ROA for P1 which is a sub-prefix of P0, a router which receives the ROA for P0 - before that for P1 is likely to mark a BGP prefix P1 - invalid. Therefore, the cache SHOULD announce the + before that for P1 is likely to mark a BGP announcement of + prefix P1 invalid. Therefore, the cache SHOULD announce the sub-prefix P1 before the covering prefix P0. + + In order to further mitigate such race conditions, a router MAY + choose not to make effective the PDUs received in response to a + request until the relevant End of Data PDU is received. + + However, a router MAY choose to apply a time limit for how long + it is willing to wait for the End of Data PDU. + + +