idnits 2.17.1 draft-ietf-sidrops-8210bis-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The configured transport security, the negotiated RPKI-Rtr version, etc. MAY NOT be changed once a session has been established. If one side or the other wishes to try a different transport, protocol version, etc. they MUST terminate the transport and restart the entire transport and version negotiation process. -- The document date (4 March 2024) is 59 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Bush 3 Internet-Draft IIJ Research, Arrcus, & DRL 4 Intended status: Standards Track R. Austein 5 Expires: 5 September 2024 Dragon Research Labs 6 4 March 2024 8 The Resource Public Key Infrastructure (RPKI) to Router Protocol, 9 Version 2 10 draft-ietf-sidrops-8210bis-12 12 Abstract 14 In order to verifiably validate the origin Autonomous Systems and 15 Autonomous System Paths of BGP announcements, routers need a simple 16 but reliable mechanism to receive Resource Public Key Infrastructure 17 (RFC 6480) prefix origin data and router keys from a trusted cache. 18 This document describes a protocol to deliver them. 20 This document describes version 2 of the RPKI-Router protocol. RFC 21 6810 describes version 0, and RFC 8210 describes version 1. This 22 document is compatible with both. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 5 September 2024. 41 Copyright Notice 43 Copyright (c) 2024 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 1.2. Changes from RFC 8210 . . . . . . . . . . . . . . . . . . 3 60 2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Deployment Structure . . . . . . . . . . . . . . . . . . . . 5 62 4. Operational Overview . . . . . . . . . . . . . . . . . . . . 5 63 5. Protocol Data Units (PDUs) . . . . . . . . . . . . . . . . . 7 64 5.1. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 7 65 5.2. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 10 66 5.3. Serial Query . . . . . . . . . . . . . . . . . . . . . . 11 67 5.4. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 12 68 5.5. Cache Response . . . . . . . . . . . . . . . . . . . . . 12 69 5.6. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 13 70 5.7. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 14 71 5.8. End of Data . . . . . . . . . . . . . . . . . . . . . . . 15 72 5.9. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 16 73 5.10. Router Key . . . . . . . . . . . . . . . . . . . . . . . 16 74 5.11. Error Report . . . . . . . . . . . . . . . . . . . . . . 18 75 5.12. ASPA PDU . . . . . . . . . . . . . . . . . . . . . . . . 19 76 6. Protocol Timing Parameters . . . . . . . . . . . . . . . . . 21 77 7. Protocol Version Negotiation . . . . . . . . . . . . . . . . 22 78 8. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . 24 79 8.1. Start or Restart . . . . . . . . . . . . . . . . . . . . 24 80 8.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . 25 81 8.3. No Incremental Update Available . . . . . . . . . . . . . 26 82 8.4. Cache Has No Data Available . . . . . . . . . . . . . . . 26 83 9. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 27 84 9.1. SSH Transport . . . . . . . . . . . . . . . . . . . . . . 28 85 9.2. TLS Transport . . . . . . . . . . . . . . . . . . . . . . 29 86 9.3. TCP MD5 Transport . . . . . . . . . . . . . . . . . . . . 29 87 9.4. TCP-AO Transport . . . . . . . . . . . . . . . . . . . . 30 88 10. Router-Cache Setup . . . . . . . . . . . . . . . . . . . . . 30 89 11. ROA PDU Race Minimization . . . . . . . . . . . . . . . . . . 31 90 12. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 32 91 13. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 32 92 14. Security Considerations . . . . . . . . . . . . . . . . . . . 33 93 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 94 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 95 16.1. Normative References . . . . . . . . . . . . . . . . . . 36 96 16.2. Informative References . . . . . . . . . . . . . . . . . 38 98 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 39 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 101 1. Introduction 103 In order to verifiably validate the origin Autonomous Systems (ASes) 104 and AS paths of BGP announcements, routers need a simple but reliable 105 mechanism to receive cryptographically validated Resource Public Key 106 Infrastructure (RPKI) [RFC6480] prefix origin data and router keys 107 from a trusted cache. This document describes a protocol to deliver 108 them. The design is intentionally constrained to be usable on much 109 of the current generation of ISP router platforms. 111 This specification documents version 2 of the RPKI-RTR protocol. 112 Earlier versions are documented in [RFC6810] and [RFC8210]. Though 113 this version is, of course, preferred, the earlier versions are 114 expected to continue to be productively deployed indefinitely, and 115 Section 7 details how to downgrade from this version to earlier 116 versions as needed in order to interoperate. 118 Section 3 describes the deployment structure, and Section 4 then 119 presents an operational overview. The binary payloads of the 120 protocol are formally described in Section 5, and the expected 121 Protocol Data Unit (PDU) sequences are described in Section 8. The 122 transport protocol options are described in Section 9. Section 10 123 details how routers and caches are configured to connect and 124 authenticate. Section 12 describes likely deployment scenarios. The 125 traditional security and IANA considerations end the document. 127 The protocol is extensible in order to support new PDUs with new 128 semantics, if deployment experience indicates that they are needed. 129 PDUs are versioned should deployment experience call for change. 131 1.1. Requirements Language 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in BCP 136 14 [RFC2119] [RFC8174] when, and only when, they appear in all 137 capitals, as shown here. 139 1.2. Changes from RFC 8210 141 This section summarizes the significant changes between [RFC8210] and 142 the protocol described in this document. 144 * A new ASPA (Autonomous System Provider Authorization) PDU type 145 (Section 5.12) has been added to support 146 [I-D.ietf-sidrops-aspa-profile]. 148 * A small Section 11 has been added to handle two possible ROA 149 (Route Origination Authorization) PDU race conditions, Break 150 Before Make and Shorter Prefix First. 152 * Language was clarified when multiple caches are configured, and an 153 interesting affect is noted. 155 * The protocol version number incremented from 1 (one) to 2 (two) 156 and Section 7 has been updated accordingly. 158 2. Glossary 160 The following terms are used with special meaning. 162 Global RPKI: The authoritative data of the RPKI are published in a 163 distributed set of servers at the IANA, Regional Internet 164 Registries (RIRs), National Internet Registries (NIRs), and ISPs; 165 see [RFC6481]. 167 CA: The authoritative data of the RPKI are meant to be published by 168 a distributed set of Certification Authorities (CAs) at the IANA, 169 RIRs, NIRs, and ISPs (see [RFC6481]). 171 Cache: A Cache, AKA Relying Party Cache, is a coalesced copy of the 172 published Global RPKI data, periodically fetched or refreshed, 173 directly or indirectly, using the rsync protocol [RFC5781] or some 174 successor. Relying Party software is used to gather and validate 175 the distributed data of the RPKI into a cache. Trusting this 176 cache further is a matter between the provider of the cache and a 177 Relying Party. 179 Serial Number: "Serial Number" is a 32-bit strictly increasing 180 unsigned integer which wraps from 2^32-1 to 0. It denotes the 181 logical version of a cache. A cache increments the value when it 182 successfully updates its data from a parent cache or from primary 183 RPKI data. While a cache is receiving updates, new incoming data 184 and implicit deletes are associated with the new Serial Number but 185 MUST NOT be sent until the fetch is complete. A Serial Number is 186 not commensurate between different caches or different protocol 187 versions, nor need it be maintained across resets of the cache 188 server. See [RFC1982] on DNS Serial Number Arithmetic for too 189 much detail on the topic. 191 Session ID: When a cache server is started, it generates a Session 192 ID to uniquely identify the instance of the cache and to bind it 193 to the sequence of Serial Numbers that cache instance will 194 generate. This allows the router to restart a failed session 195 knowing that the Serial Number it is using is commensurate with 196 that of the cache. 198 Payload PDU: A payload PDU is a protocol message which contains data 199 for use by the router, as opposed to a PDU which conveys the 200 control mechanisms of this protocol. Prefixes and Router Keys are 201 examples of payload PDUs. 203 3. Deployment Structure 205 Deployment of the RPKI to reach routers has a three-level structure 206 as follows: 208 Global RPKI: The authoritative data of the RPKI are published in a 209 distributed set of servers at the IANA, RIRs, NIRs, and ISPs (see 210 [RFC6481]). 212 Local Caches: Local caches are a local set of one or more collected 213 and verified caches of RPKI data. A Relying Party, e.g., router 214 or other client, MUST have a trust relationship with, and a 215 trusted transport channel to, any cache(s) it uses. 217 Routers: A router fetches data from a local cache using the protocol 218 described in this document. It is said to be a client of the 219 cache. There MAY be mechanisms for the router to assure itself of 220 the authenticity of the cache and to authenticate itself to the 221 cache (see Section 9). 223 4. Operational Overview 225 A router establishes and keeps open a transport connection to one or 226 more caches with which it has client/server relationships. It is 227 configured with a semi-ordered list of caches and establishes a 228 connection to the most preferred cache, or set of caches with that 229 same priority, which accept the connections. 231 The router MUST choose the most preferred, by configuration, cache or 232 set of caches so that the operator may control load on their caches 233 and the Global RPKI. 235 A VRP is effective if it is in the fetched set from any of the 236 currently preferred caches. Therefore, a VRP takes effect on the 237 router when the first cache serves that VRP, and the VRP is in effect 238 until the last cache withdraws that VRP. Thus, in a global sense, 239 the effect of a VRP announcement propagates more quickly than a 240 withdraw, 242 Periodically, the router sends a Serial Query to the cache the most 243 recent Serial Number for which it has received data from that cache, 244 i.e., the router's current Serial Number, in the form of a Serial 245 Query. When a router establishes a new session with a cache or 246 wishes to reset a current relationship, it sends a Reset Query. 248 The cache responds to the Serial Query with all data changes which 249 took place since the given Serial Number. This may be the null set, 250 in which case the End of Data PDU (Section 5.8) is still sent. Note 251 that the Serial Number comparison used to determine "since the given 252 Serial Number" MUST take wrap-around into account; see [RFC1982]. 254 When the router has received all data records from the cache, it sets 255 its current Serial Number to that of the Serial Number in the 256 received End of Data PDU. 258 When the cache updates its database, it sends a Notify PDU to every 259 currently connected router. This is a hint that now would be a good 260 time for the router to poll for an update, but it is only a hint. 261 The protocol requires the router to poll for updates periodically in 262 any case. 264 Strictly speaking, a router could track a cache simply by asking for 265 a complete data set every time it updates, but this would be very 266 inefficient. The Serial-Number-based incremental update mechanism 267 allows an efficient transfer of just the data records which have 268 changed since the last update. As with any update protocol based on 269 incremental transfers, the router must be prepared to fall back to a 270 full transfer if for any reason the cache is unable to provide the 271 necessary incremental data. Unlike some incremental transfer 272 protocols, this protocol requires the router to make an explicit 273 request to start the fallback process; this is deliberate, as the 274 cache has no way of knowing whether the router has also established 275 sessions with other caches that may be able to provide better 276 service. 278 As a cache server must evaluate certificates and ROAs (Route Origin 279 Authorizations; see [RFC6480]), which are time dependent, servers' 280 clocks MUST be correct to a tolerance of an hour. 282 Barring errors, transport connections remain up as long as the cache 283 and router remain up and the router is not reconfigured to no longer 284 use the cache. 286 Should a transport connection be lost for unknown reasons, the router 287 SHOULD try to reestablish one; being careful to not abuse the cache 288 with two many failed requests. 290 5. Protocol Data Units (PDUs) 292 The exchanges between the cache and the router are sequences of 293 exchanges of the following PDUs according to the rules described in 294 Section 8. 296 Reserved fields (marked "zero" in PDU diagrams) MUST be zero on 297 transmission and MUST be ignored on receipt. 299 5.1. Fields of a PDU 301 PDUs contain the following data elements: 303 Protocol Version: An 8-bit unsigned integer, currently 2, denoting 304 the version of this protocol. 306 PDU Type: An 8-bit unsigned integer, denoting the type of the PDU, 307 e.g., IPv4 Prefix. 309 Serial Number: A 32-bit unsigned integer serializing the RPKI cache 310 epoch when this set of PDUs was received from an upstream cache 311 server or gathered from the Global RPKI. A cache increments its 312 Serial Number when completing a validated update from a parent 313 cache or the Global RPKI. 315 Session ID: A 16-bit unsigned integer. When a cache server is 316 started, it generates a Session ID to identify the instance of the 317 cache and to bind it to the sequence of Serial Numbers that cache 318 instance will generate. This allows the router to restart a 319 failed session knowing that the Serial Number it is using is 320 commensurate with that of the cache. If, at any time after the 321 protocol version has been negotiated (Section 7), either the 322 router or the cache finds that the value of the Session ID is not 323 the same as the other's, the party which detects the mismatch MUST 324 immediately terminate the session with an Error Report PDU with 325 code 0 ("Corrupt Data"), and the router MUST flush all data 326 learned from that cache. 328 Note that sessions are specific to a particular protocol version. 330 That is, if a cache server supports multiple versions of this 331 protocol, happens to use the same Session ID value for multiple 332 protocol versions, and further happens to use the same Serial 333 Number values for two or more sessions using the same Session ID 334 but different Protocol Version values, the Serial Numbers are not 335 commensurate. The full test for whether Serial Numbers are 336 commensurate requires comparing Protocol Version, Session ID, and 337 Serial Number. To reduce the risk of confusion, cache servers 338 SHOULD NOT use the same Session ID across multiple protocol 339 versions, but even if they do, routers MUST treat sessions with 340 different Protocol Version fields as separate sessions even if 341 they do happen to have the same Session ID. 343 Should a cache erroneously reuse a Session ID so that a router 344 does not realize that the session has changed (old Session ID and 345 new Session ID have the same numeric value), the router may become 346 confused as to the content of the cache. The time it takes the 347 router to discover that it is confused will depend on whether the 348 Serial Numbers are also reused. If the Serial Numbers in the old 349 and new sessions are different enough, the cache will respond to 350 the router's Serial Query with a Cache Reset, which will solve the 351 problem. If, however, the Serial Numbers are close, the cache may 352 respond with a Cache Response, which may not be enough to bring 353 the router into sync. In such cases, it's likely but not certain 354 that the router will detect some discrepancy between the state 355 that the cache expects and its own state. For example, the Cache 356 Response may tell the router to drop a record which the router 357 does not hold or may tell the router to add a record which the 358 router already has. In such cases, a router will detect the error 359 and reset the session. The one case in which the router may stay 360 out of sync is when nothing in the Cache Response contradicts any 361 data currently held by the router. 363 Using persistent storage for the Session ID or a clock-based 364 scheme for generating Session IDs should avoid the risk of Session 365 ID collisions. 367 The Session ID might be a pseudorandom value, a strictly 368 increasing value if the cache has reliable storage, et cetera. A 369 seconds-since-epoch timestamp value such as the low order 16 bits 370 of unsigned integer seconds since 1970-01-01T00:00:00Z ignoring 371 leap seconds might make a good Session ID value. 373 Length: A 32-bit unsigned integer which has as its value the count 374 of the bytes in the entire PDU, including the 8 bytes of header 375 which includes the length field. 377 Flags: An 8-bit binary field, with the lowest-order bit being 1 for 378 an announcement and 0 for a withdrawal. For a Prefix PDU (IPv4 or 379 IPv6), the announce/withdraw flag indicates whether this PDU 380 announces a new right to announce the prefix or withdraws a 381 previously announced right; a withdraw effectively deletes one 382 previously announced Prefix PDU with the exact same Prefix, 383 Length, Max-Len, and Autonomous System Number (ASN). 385 Similarly, for a Router Key PDU, the flag indicates whether this 386 PDU announces a new Router Key or deletes one previously announced 387 Router Key PDU with the exact same AS Number, 388 subjectKeyIdentifier, and subjectPublicKeyInfo. 390 The remaining bits in the Flags field are reserved for future use. 392 Prefix Length: An 8-bit unsigned integer denoting the shortest 393 prefix allowed by the Prefix element. 395 Max Length: An 8-bit unsigned integer denoting the longest prefix 396 allowed by the Prefix element. This MUST NOT be less than the 397 Prefix Length element. 399 Prefix: The IPv4 or IPv6 prefix of the ROA. 401 Autonomous System Number: A 32-bit unsigned integer representing an 402 ASN allowed to announce a prefix or associated with a router key. 404 Subject Key Identifier: The 20-octet Subject Key Identifier (SKI) 405 value of a router key, as described in [RFC6487]. 407 Subject Public Key Info: A variable length field holding a router 408 key's subjectPublicKeyInfo value, as described in [RFC8608]. This 409 is the full ASN.1 DER encoding of the subjectPublicKeyInfo, 410 including the ASN.1 tag and length values of the 411 subjectPublicKeyInfo SEQUENCE. 413 Refresh Interval: A 32-bit interval in seconds between normal cache 414 polls. See Section 6. 416 Retry Interval: A 32-bit interval in seconds between cache poll 417 retries after a failed cache poll. See Section 6. 419 Expire Interval: A 32-bit interval in seconds during which data 420 fetched from a cache remains valid in the absence of a successful 421 subsequent cache poll. See Section 6. 423 AFI Flags: An 8-bit field of the ASPA PDU where the low order bit is 424 set if the AS relationships are for IPv4 (AFI 1), and the second 425 lowest bit is set for IPv6 (AFI 2). Currently, both bits MUST be 426 set. This field may be removed soon. 428 Provider AS Count: A 16-bit count of Provider Autonomous System 429 Numbers in the PDU. 431 Customer Autonomous System Number: The 32-bit AS number of the 432 Autonomous System that authorizes the upstream providers listed in 433 the Provider Autonomous System list to propagate prefixes of the 434 specified address family to other ASes. 436 Provider Autonomous System Numbers: The set of 32-bit AS numbers 437 authorized to propagate prefixes which were received from the 438 customer AS. 440 5.2. Serial Notify 442 The cache notifies the router that the cache has new data. 444 The Session ID reassures the router that the Serial Numbers are 445 commensurate, i.e., the cache session has not been changed. 447 Upon receipt of a Serial Notify PDU, the router MAY issue an 448 immediate Serial Query (Section 5.3) or Reset Query (Section 5.4) 449 without waiting for the Refresh Interval timer (see Section 6) to 450 expire. 452 Serial Notify is the only message that the cache can send that is not 453 in response to a message from the router. 455 If the router receives a Serial Notify PDU during the initial startup 456 period where the router and cache are still negotiating to agree on a 457 protocol version, the router MUST simply ignore the Serial Notify 458 PDU, even if the Serial Notify PDU is for an unexpected protocol 459 version. See Section 7 for details. 461 0 8 16 24 31 462 .-------------------------------------------. 463 | Protocol | PDU | | 464 | Version | Type | Session ID | 465 | 2 | 0 | | 466 +-------------------------------------------+ 467 | | 468 | Length=12 | 469 | | 470 +-------------------------------------------+ 471 | | 472 | Serial Number | 473 | | 474 `-------------------------------------------' 476 5.3. Serial Query 478 The router sends a Serial Query to ask the cache for all 479 announcements and withdrawals which have occurred since the Serial 480 Number specified in the Serial Query. 482 The cache replies to this query with a Cache Response PDU 483 (Section 5.5) if the cache has a (possibly null) record of the 484 changes since the Serial Number specified by the router, followed by 485 zero or more payload PDUs and an End Of Data PDU (Section 5.8). 487 When replying to a Serial Query, the cache MUST return the minimum 488 set of changes needed to bring the router into sync with the cache. 489 That is, if a particular prefix or router key underwent multiple 490 changes between the Serial Number specified by the router and the 491 cache's current Serial Number, the cache MUST merge those changes to 492 present the simplest possible view of those changes to the router. 493 In general, this means that, for any particular prefix or router key, 494 the data stream will include at most one withdrawal followed by at 495 most one announcement, and if all of the changes cancel out, the data 496 stream will not mention the prefix or router key at all. 498 The rationale for this approach is that the entire purpose of the 499 RPKI-Router protocol is to offload work from the router to the cache, 500 and it should therefore be the cache's job to simplify the change 501 set, thus reducing work for the router. 503 If the cache does not have the data needed to update the router, 504 perhaps because its records do not go back to the Serial Number in 505 the Serial Query, then it responds with a Cache Reset PDU 506 (Section 5.9). 508 The Session ID tells the cache what instance the router expects to 509 ensure that the Serial Numbers are commensurate, i.e., the cache 510 session has not been changed. 512 0 8 16 24 31 513 .-------------------------------------------. 514 | Protocol | PDU | | 515 | Version | Type | Session ID | 516 | 2 | 1 | | 517 +-------------------------------------------+ 518 | | 519 | Length=12 | 520 | | 521 +-------------------------------------------+ 522 | | 523 | Serial Number | 524 | | 525 `-------------------------------------------' 527 5.4. Reset Query 529 The router tells the cache that it wants to receive the total active, 530 current, non-withdrawn database. The cache responds with a Cache 531 Response PDU (Section 5.5), followed by zero or more payload PDUs and 532 an End of Data PDU (Section 5.8). 534 0 8 16 24 31 535 .-------------------------------------------. 536 | Protocol | PDU | | 537 | Version | Type | zero | 538 | 2 | 2 | | 539 +-------------------------------------------+ 540 | | 541 | Length=8 | 542 | | 543 `-------------------------------------------' 545 5.5. Cache Response 547 The cache responds to queries with zero or more payload PDUs. When 548 replying to a Serial Query (Section 5.3), the cache sends the set of 549 announcements and withdrawals that have occurred since the Serial 550 Number sent by the client router. When replying to a Reset Query 551 (Section 5.4), the cache sends the set of all data records it has; in 552 this case, the announce/withdraw field in the payload PDUs MUST have 553 the value 1 (announce). 555 In response to a Reset Query, the new value of the Session ID tells 556 the router the instance of the cache session for future confirmation. 557 In response to a Serial Query, the Session ID being the same 558 reassures the router that the Serial Numbers are commensurate, i.e., 559 the cache session has not been changed. 561 0 8 16 24 31 562 .-------------------------------------------. 563 | Protocol | PDU | | 564 | Version | Type | Session ID | 565 | 2 | 3 | | 566 +-------------------------------------------+ 567 | | 568 | Length=8 | 569 | | 570 `-------------------------------------------' 572 5.6. IPv4 Prefix 574 0 8 16 24 31 575 .-------------------------------------------. 576 | Protocol | PDU | | 577 | Version | Type | zero | 578 | 2 | 4 | | 579 +-------------------------------------------+ 580 | | 581 | Length=20 | 582 | | 583 +-------------------------------------------+ 584 | | Prefix | Max | | 585 | Flags | Length | Length | zero | 586 | | 0..32 | 0..32 | | 587 +-------------------------------------------+ 588 | | 589 | IPv4 Prefix | 590 | | 591 +-------------------------------------------+ 592 | | 593 | Autonomous System Number | 594 | | 595 `-------------------------------------------' 597 This PDU carries an [RFC6811] Validated ROA Payload (VRP) for an IPv4 598 ROA. 600 The lowest-order bit of the Flags field is 1 for an announcement and 601 0 for a withdrawal. 603 In the RPKI, nothing prevents a signing certificate from issuing two 604 identical ROAs. In this case, there would be no semantic difference 605 between the objects, merely a process redundancy. 607 In the RPKI, there is also an actual need for what might appear to a 608 router as identical IPvX PDUs. This can occur when an upstream 609 certificate is being reissued or there is an address ownership 610 transfer up the validation chain. The ROA would be identical in the 611 router sense, i.e., have the same {Prefix, Len, Max-Len, ASN}, but it 612 would have a different validation path in the RPKI. This is 613 important to the RPKI but not to the router. 615 The cache server MUST ensure that it has told the router client to 616 have one and only one IPvX PDU for a unique {Prefix, Len, Max-Len, 617 ASN} at any one point in time. Should the router client receive an 618 IPvX PDU with a {Prefix, Len, Max-Len, ASN} identical to one it 619 already has active, it SHOULD raise a Duplicate Announcement Received 620 error. 622 5.7. IPv6 Prefix 624 0 8 16 24 31 625 .-------------------------------------------. 626 | Protocol | PDU | | 627 | Version | Type | zero | 628 | 2 | 6 | | 629 +-------------------------------------------+ 630 | | 631 | Length=32 | 632 | | 633 +-------------------------------------------+ 634 | | Prefix | Max | | 635 | Flags | Length | Length | zero | 636 | | 0..128 | 0..128 | | 637 +-------------------------------------------+ 638 | | 639 +--- ---+ 640 | | 641 +--- IPv6 Prefix ---+ 642 | | 643 +--- ---+ 644 | | 645 +-------------------------------------------+ 646 | | 647 | Autonomous System Number | 648 | | 649 `-------------------------------------------' 650 This PDU carries an [RFC6811] Validated ROA Payload (VRP) for an IPv6 651 ROA. 653 Analogous to the IPv4 Prefix PDU, it has 96 more bits and no magic. 655 5.8. End of Data 657 The cache tells the router it has no more data for the request. 659 The Session ID and Protocol Version MUST be the same as that of the 660 corresponding Cache Response which began the (possibly null) sequence 661 of payload PDUs. 663 0 8 16 24 31 664 .-------------------------------------------. 665 | Protocol | PDU | | 666 | Version | Type | Session ID | 667 | 2 | 7 | | 668 +-------------------------------------------+ 669 | | 670 | Length=24 | 671 | | 672 +-------------------------------------------+ 673 | | 674 | Serial Number | 675 | | 676 +-------------------------------------------+ 677 | | 678 | Refresh Interval | 679 | | 680 +-------------------------------------------+ 681 | | 682 | Retry Interval | 683 | | 684 +-------------------------------------------+ 685 | | 686 | Expire Interval | 687 | | 688 `-------------------------------------------' 690 The Refresh Interval, Retry Interval, and Expire Interval are all 691 32-bit elapsed times measured in seconds. They express the timing 692 parameters which the cache expects the router to use in deciding when 693 to send subsequent Serial Query or Reset Query PDUs to the cache. 694 See Section 6 for an explanation of the use and the range of allowed 695 values for these parameters. 697 Note that the End of Data PDU changed significantly between versions 698 0 and 1. Version 2 End of Data is the same as Version 1. 700 5.9. Cache Reset 702 The cache may respond to a Serial Query informing the router that the 703 cache cannot provide an incremental update starting from the Serial 704 Number specified by the router. The router must decide whether to 705 issue a Reset Query or switch to a different cache. 707 0 8 16 24 31 708 .-------------------------------------------. 709 | Protocol | PDU | | 710 | Version | Type | zero | 711 | 2 | 8 | | 712 +-------------------------------------------+ 713 | | 714 | Length=8 | 715 | | 716 `-------------------------------------------' 718 5.10. Router Key 719 0 8 16 24 31 720 .-------------------------------------------. 721 | Protocol | PDU | | | 722 | Version | Type | Flags | zero | 723 | 2 | 9 | | | 724 +-------------------------------------------+ 725 | | 726 | Length | 727 | | 728 +-------------------------------------------+ 729 | | 730 +--- ---+ 731 | Subject Key Identifier | 732 +--- ---+ 733 | | 734 +--- ---+ 735 | (20 octets) | 736 +--- ---+ 737 | | 738 +-------------------------------------------+ 739 | | 740 | AS Number | 741 | | 742 +-------------------------------------------+ 743 | | 744 | Subject Public Key Info | 745 | | 746 `-------------------------------------------' 748 The Router Key PDU transports an [RFC8635] Router key. 750 The lowest-order bit of the Flags field is 1 for an announcement and 751 0 for a withdrawal. 753 The cache server MUST ensure that it has told the router client to 754 have one and only one Router Key PDU for a unique {SKI, ASN, Subject 755 Public Key} at any one point in time. Should the router client 756 receive a Router Key PDU with a {SKI, ASN, Subject Public Key} 757 identical to one it already has active, it SHOULD raise a Duplicate 758 Announcement Received error. 760 Note that a particular ASN may appear in multiple Router Key PDUs 761 with different Subject Public Key values, while a particular Subject 762 Public Key value may appear in multiple Router Key PDUs with 763 different ASNs. In the interest of keeping the announcement and 764 withdrawal semantics as simple as possible for the router, this 765 protocol makes no attempt to compress either of these cases. 767 Also note that it is possible, albeit very unlikely, for multiple 768 distinct Subject Public Key values to hash to the same SKI. For this 769 reason, implementations MUST compare Subject Public Key values as 770 well as SKIs when detecting duplicate PDUs. 772 As the Subject Public Key Info is a variable length field, it must be 773 decoded to determine where the PDU terminates. 775 5.11. Error Report 777 This PDU is used by either party to report an error to the other. 779 Error reports are only sent as responses to other PDUs, not to report 780 errors in Error Report PDUs. 782 Error codes are described in Section 13. 784 The Erroneous PDU field is a binary copy of the PDU causing the error 785 condition, including all fields. 787 If the error is generic (e.g., "Internal Error") and not associated 788 with the PDU to which it is responding, the Erroneous PDU field MUST 789 be empty and the Length of Encapsulated PDU field MUST be zero. 791 An Error Report PDU MUST NOT be sent for an Error Report PDU. If an 792 erroneous Error Report PDU is received, the session SHOULD be 793 dropped. 795 If the error is associated with a PDU of excessive length, i.e., too 796 long to be any legal PDU other than another Error Report, or a 797 possibly corrupt length, the Erroneous PDU field MAY be truncated. 799 The Arbitrary Text field is optional; if not present, the Length of 800 Arbitrary text field MUST be zero. If Arbitrary Text is present, it 801 MUST be a string in UTF-8 encoding (see [RFC3629]) in the Queen's 802 English. 804 0 8 16 24 31 805 .-------------------------------------------. 806 | Protocol | PDU | | 807 | Version | Type | Error Code | 808 | 2 | 10 | | 809 +-------------------------------------------+ 810 | | 811 | Length | 812 | | 813 +-------------------------------------------+ 814 | | 815 | Length of Encapsulated PDU | 816 | | 817 +-------------------------------------------+ 818 | | 819 ~ Erroneous PDU ~ 820 | | 821 +-------------------------------------------+ 822 | | 823 | Length of Arbitrary Text | 824 | | 825 +-------------------------------------------+ 826 | | 827 | Arbitrary Text | 828 ~ of ~ 829 | Error Diagnostic Message | 830 | | 831 `-------------------------------------------' 833 5.12. ASPA PDU 834 0 8 16 24 31 835 .-------------------------------------------. 836 | Protocol | PDU | | 837 | Version | Type | zero | 838 | 2 | 11 | | 839 +-------------------------------------------+ 840 | | 841 | Length | 842 | | 843 +-------------------------------------------+ 844 | | | | 845 | Flags | AFI Flags| Provider AS Count | 846 | | | | 847 +-------------------------------------------+ 848 | | 849 | Customer Autonomous System Number | 850 | | 851 +-------------------------------------------+ 852 | | 853 ~ Provider Autonomous System Numbers ~ 854 | | 855 ~-------------------------------------------~ 857 The ASPA PDU supports [I-D.ietf-sidrops-aspa-profile]. An ASPA PDU 858 represents one single customer AS and its provider ASes. Receipt of 859 an ASPA PDU announcement (announce/withdraw flag == 1) when the 860 router already has an ASPA PDU with the same Customer Autonomous 861 System Number replaces the previous one. The cache MUST deliver the 862 complete data of an ASPA record in a single ASPA PDU. 864 The router MUST see at most one ASPA from a cache for a particular 865 Customer Autonomous System Number active at any time. As a number of 866 conditions in the global RPKI may present multiple valid ASPA RPKI 867 records for a single customer to a particular RP cache, this places a 868 burden on the cache to form the union of multiple ASPA records it has 869 received from the global RPKI into one ASPA PDU. 871 The Flags field is as described in Section 5. 873 For the ASPA PDU, the announce/withdraw Flag is set to 1 to indicate 874 either the announcement of a new ASPA record or a replacement for a 875 previously announced record with the same Customer Autonomous System 876 Number. 878 If the announce/withdraw flag is set to 0, it indicates removal of 879 the entire ASPA record for that Customer AS. Here, the customer AS 880 of the ASPA record MUST be provided, the Provider AS Count must be 881 zero, the Provider AS Numbers list MUST be null, and these last two 882 fields MUST be ignored by the router. 884 The AFI Flags field is defined in Section 15 Currently, the two low 885 order bits MUST always be set, i.e. 1, and the rest unset, i.e. 0. 886 This allows the router to prepare for less change should the AFIs be 887 separated in a future version. This field is likely to be removed 888 before publication. 890 The Provider AS Count is the number of 32-bit Provider Autonomous 891 System Numbers in the PDU. 893 The Customer Autonomous System Number is the 32-bit Autonomous System 894 Number of the customer which authenticated the ASPA RPKI data. There 895 MUST be one and only one ASPA for a Customer Autonomous System Number 896 active in the router at any time. 898 There are zero or more 32-bit Provider Autonomous System Number 899 fields as indicated in the Provider AS Count; see 900 [I-D.ietf-sidrops-aspa-profile]. 902 6. Protocol Timing Parameters 904 Since the data the cache distributes via the RPKI-Router protocol are 905 retrieved from the Global RPKI system at intervals which are only 906 known to the cache, only the cache can really know how frequently it 907 makes sense for the router to poll the cache, or how long the data 908 are likely to remain valid (or, at least, unchanged). For this 909 reason, as well as to allow the cache some control over the load 910 placed on it by its client routers, the End Of Data PDU includes 911 three values that allow the cache to communicate timing parameters to 912 the router: 914 Refresh Interval: This parameter tells the router how long to wait 915 before next attempting to poll the cache and between subsequent 916 attempts, using a Serial Query or Reset Query PDU. The router 917 SHOULD NOT poll the cache sooner than indicated by this parameter. 918 Note that receipt of a Serial Notify PDU overrides this interval 919 and suggests that the router issue an immediate query without 920 waiting for the Refresh Interval to expire. Countdown for this 921 timer starts upon receipt of the containing End Of Data PDU. 923 Minimum allowed value: 1 second. 925 Maximum allowed value: 86400 seconds (1 day). 927 Recommended default: 3600 seconds (1 hour). 929 Retry Interval: This parameter tells the router how long to wait 930 before retrying a failed Serial Query or Reset Query. The router 931 SHOULD NOT retry sooner than indicated by this parameter. Note 932 that a protocol version mismatch overrides this interval: if the 933 router needs to downgrade to a lower protocol version number, it 934 MAY send the first Serial Query or Reset Query immediately. 935 Countdown for this timer starts upon failure of the query and 936 restarts after each subsequent failure until a query succeeds. 938 Minimum allowed value: 1 second. 940 Maximum allowed value: 7200 seconds (2 hours). 942 Recommended default: 600 seconds (10 minutes). 944 Expire Interval: This parameter tells the router how long it can 945 continue to use the current version of the data while unable to 946 perform a successful subsequent query. The router MUST NOT retain 947 the data past the time indicated by this parameter. Countdown for 948 this timer starts upon receipt of the containing End Of Data PDU. 950 Minimum allowed value: 600 seconds (10 minutes). 952 Maximum allowed value: 172800 seconds (2 days). 954 Recommended default: 7200 seconds (2 hours). 956 If the router has never issued a successful query against a 957 particular cache, it SHOULD retry periodically using the default 958 Retry Interval, above. 960 Caches MUST set Expire Interval to a value larger than both the 961 Refresh Interval and the Retry Interval. 963 7. Protocol Version Negotiation 965 Once a router has established a transport connection to a cache, it 966 MUST attempt to open a RPKI-Router 'session' by issuing either a 967 Reset Query Section 5.4) or a Serial Query (Section 5.3) with the 968 highest version of this protocol the router implements in the 969 Protocol Version field. If the cache supports that version, it 970 responds with a Cache Response (Section 5.5) of that version and the 971 session is considered open. 973 If a cache which supports version C receives a query with Protocol 974 Version Q < C, and the cache does not support versions <= Q, the 975 cache MUST send an Error Report (Section 5.11) with Protocol Version 976 C and Error Code 4 ("Unsupported Protocol Version") and disconnect 977 the transport, as negotiation is hopeless. 979 If a cache which supports version C receives a query with Protocol 980 Version Q < C, and the ache can support version Q, the cache MUST 981 downgrade to protocol version Q, [RFC6810] or [RFC8210], and respond 982 with a Cache Response (Section 5.5) of that Protocol Version, Q, and 983 the RPKI-Rtr session is considered open. 985 If the the cache which supports C as its highest verion receives a 986 query of version Q > C, the cache MUST send an Error Report with 987 Protocol Version C and Error Code 4. The router SHOULD send another 988 query with a Protocol Version Q with Q == the version C in the Error 989 Report; unless it has already failed at that version, which indicates 990 a fatal error in programming of the cache which SHOULD result in 991 transport termination. 993 If the router requests Q == 0 and it still fails with the cache 994 responding with an Error Report with Error Code 4, then the router 995 MUST abort the transport connection, as negotiation is hopeless. 997 In any of the downgraded combinations above, the new features of the 998 higher version will not be available, and all PDUs MUST have the 999 negotiated lower version number in their version fields. 1001 If either party receives a PDU containing an unrecognized Protocol 1002 Version (neither 0, 1, nor 2) during this negotiation, it MUST either 1003 downgrade to a known version or terminate the connection, with an 1004 Error Report PDU unless the received PDU is itself an Error Report 1005 PDU. 1007 The router MUST ignore any Serial Notify PDUs it might receive from 1008 the cache during this initial startup period, regardless of the 1009 Protocol Version field in the Serial Notify PDU. Since Session ID 1010 and Serial Number values are specific to a particular protocol 1011 version, the values in the notification are not useful to the router. 1012 Even if these values were meaningful, the only effect that processing 1013 the notification would have would be to trigger exactly the same 1014 Reset Query or Serial Query that the router has already sent as part 1015 of the not-yet-complete version negotiation process, so there is 1016 nothing to be gained by processing notifications until version 1017 negotiation completes. 1019 Caches SHOULD NOT send Serial Notify PDUs before version negotiation 1020 completes. Routers, however, MUST handle such notifications (by 1021 ignoring them) for backwards compatibility with caches serving 1022 protocol version 0. 1024 Once the cache and router have agreed upon a Protocol Version via the 1025 negotiation process above, that version is fixed for the life of the 1026 session. See Section 5.1 for a discussion of the interaction between 1027 Protocol Version and Session ID. 1029 The configured transport security, the negotiated RPKI-Rtr version, 1030 etc. MAY NOT be changed once a session has been established. If one 1031 side or the other wishes to try a different transport, protocol 1032 version, etc. they MUST terminate the transport and restart the 1033 entire transport and version negotiation process. 1035 If either party receives a PDU for a different Protocol Version once 1036 the above negotiation completes, that party MUST drop the session; 1037 unless the PDU containing the unexpected Protocol Version was itself 1038 an Error Report PDU, the party dropping the session SHOULD send an 1039 Error Report with an error code of 8 ("Unexpected Protocol Version"). 1041 8. Protocol Sequences 1043 The sequences of PDU transmissions fall into four conversations as 1044 follows: 1046 8.1. Start or Restart 1048 Cache Router 1049 ~ ~ 1050 | <----- Reset Query -------- | R requests data (or Serial Query) 1051 | | 1052 | ----- Cache Response -----> | C confirms request 1053 | ------- Payload PDU ------> | C sends zero or more 1054 | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, 1055 | ------- Payload PDU ------> | ASPA, or Router Key PDUs 1056 | ------- End of Data ------> | C sends End of Data 1057 | | and sends new serial 1058 ~ ~ 1060 When a transport connection is first established, the router MUST 1061 send either a Reset Query or a Serial Query. A Serial Query would be 1062 appropriate if the router has unexpired data from a broken session 1063 with the same cache and remembers the Session ID of that session, in 1064 which case a Serial Query containing the Session ID from the previous 1065 session will allow the router to bring itself up to date while 1066 ensuring that the Serial Numbers are commensurate and that the router 1067 and cache are speaking compatible versions of the protocol. In all 1068 other cases, the router lacks the necessary data for fast 1069 resynchronization and therefore MUST fall back to a Reset Query. 1071 The Reset Query sequence is also used when the router receives a 1072 Cache Reset, chooses a new cache, or fears that it has otherwise lost 1073 its way. 1075 See Section 7 for details on version negotiation. 1077 To limit the length of time a cache must keep the data necessary to 1078 generate incremental updates, a router MUST send either a Serial 1079 Query or a Reset Query periodically. This also acts as a keep-alive 1080 at the application layer. See Section 6 for details on the required 1081 polling frequency. 1083 8.2. Typical Exchange 1085 Cache Router 1086 ~ ~ 1087 | -------- Notify ----------> | (optional) 1088 | | 1089 | <----- Serial Query ------- | R requests data 1090 | | 1091 | ----- Cache Response -----> | C confirms request 1092 | ------- Payload PDU ------> | C sends zero or more 1093 | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, 1094 | ------- Payload PDU ------> | ASPA. or Router Key PDUs 1095 | ------- End of Data ------> | C sends End of Data 1096 | | and sends new serial 1097 ~ ~ 1099 The cache server SHOULD send a Notify PDU with its current Serial 1100 Number when the cache's serial changes, with the expectation that the 1101 router MAY then issue a Serial Query earlier than it otherwise might. 1102 This is analogous to DNS NOTIFY in [RFC1996]. The cache MUST rate- 1103 limit Serial Notifies to no more frequently than one per minute. 1105 When the transport layer is up and either a timer has gone off in the 1106 router or the cache has sent a Notify PDU, the router queries for new 1107 data by sending a Serial Query, and the cache sends all data newer 1108 than the serial in the Serial Query. 1110 To limit the length of time a cache must keep old withdraws, a router 1111 MUST send either a Serial Query or a Reset Query periodically. See 1112 Section 6 for details on the required polling frequency. 1114 8.3. No Incremental Update Available 1116 Cache Router 1117 ~ ~ 1118 | <------ Serial Query ------ | R requests data 1119 | ------- Cache Reset ------> | C cannot supply update 1120 | | from specified serial 1121 | <------ Reset Query ------- | R requests new data 1122 | ----- Cache Response -----> | C confirms request 1123 | ------- Payload PDU ------> | C sends zero or more 1124 | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, 1125 | ------- Payload PDU ------> | ASPA, or Router Key PDUs 1126 | ------- End of Data ------> | C sends End of Data 1127 | | and sends new serial 1128 ~ ~ 1130 The cache may respond to a Serial Query with a Cache Reset, informing 1131 the router that the cache cannot supply an incremental update from 1132 the Serial Number specified by the router. This might be because the 1133 cache has lost state, or because the router has waited too long 1134 between polls and the cache has cleaned up old data that it no longer 1135 believes it needs, or because the cache has run out of storage space 1136 and had to expire some old data early. Regardless of how this state 1137 arose, the cache replies with a Cache Reset to tell the router that 1138 it cannot honor the request. When a router receives this, the router 1139 SHOULD attempt to connect to any more-preferred caches in its cache 1140 list. If there are no more-preferred caches, it MUST issue a Reset 1141 Query and get an entire new load from the cache. 1143 8.4. Cache Has No Data Available 1145 Cache Router 1146 ~ ~ 1147 | <------ Serial Query ------ | R requests data 1148 | ---- Error Report PDU ----> | C No Data Available 1149 ~ ~ 1151 Cache Router 1152 ~ ~ 1153 | <------ Reset Query ------- | R requests data 1154 | ---- Error Report PDU ----> | C No Data Available 1155 ~ ~ 1157 The cache may respond to either a Serial Query or a Reset Query 1158 informing the router that the cache cannot supply any update at all. 1159 The most likely cause is that the cache has lost state, perhaps due 1160 to a restart, and has not yet recovered. While it is possible that a 1161 cache might go into such a state without dropping any of its active 1162 sessions, a router is more likely to see this behavior when it 1163 initially connects and issues a Reset Query while the cache is still 1164 rebuilding its database. 1166 When a router receives this kind of error, the router SHOULD attempt 1167 to connect to any other caches in its cache list, in preference 1168 order. If no other caches are available, the router MUST issue 1169 periodic Reset Queries until it gets a new usable load from the 1170 cache; maybe once a minute so as not to DoS the cache. 1172 9. Transport 1174 The transport-layer session between a router and a cache carries the 1175 binary PDUs in a persistent session. 1177 To prevent cache spoofing and DoS attacks by illegitimate routers, it 1178 is highly desirable that the router and the cache be authenticated to 1179 each other. Integrity protection for payloads is also desirable to 1180 protect against monkey-in-the-middle (MITM) attacks. Unfortunately, 1181 there is no protocol to do so on all currently used platforms. 1182 Therefore, as of the writing of this document, there is no mandatory- 1183 to-implement transport which provides authentication and integrity 1184 protection. 1186 To reduce exposure to dropped but non-terminated sessions, both 1187 caches and routers SHOULD enable keep-alives when available in the 1188 chosen transport protocol. 1190 It is expected that, when the TCP Authentication Option (TCP-AO) 1191 [RFC5925] is available on all platforms deployed by operators, it 1192 will become the mandatory-to-implement transport. 1194 Caches and routers MUST implement unprotected transport over TCP 1195 using a port, rpki-rtr (323); see Section 15. Operators SHOULD use 1196 procedural means, e.g., access control lists (ACLs), to reduce the 1197 exposure to authentication issues. 1199 If unprotected TCP is the transport, the cache and routers MUST be on 1200 the same trusted and controlled network. 1202 If available to the operator, caches and routers MUST use one of the 1203 following more protected protocols: 1205 * Caches and routers SHOULD use TCP-AO transport [RFC5925] over the 1206 rpki-rtr port. 1208 * Caches and routers MAY use Secure Shell version 2 (SSHv2) 1209 transport [RFC4252] using the normal SSH port. For an example, 1210 see Section 9.1. 1212 * Caches and routers MAY use TCP MD5 transport [RFC2385] using the 1213 rpki-rtr port if no other protected transport is available. Note 1214 that TCP MD5 has been obsoleted by TCP-AO [RFC5925]. 1216 * Caches and routers MAY use TCP over IPsec transport [RFC4301] 1217 using the rpki-rtr port. 1219 * Caches and routers MAY use Transport Layer Security (TLS) 1220 transport [RFC8446] using port rpki-rtr-tls (324); see Section 15. 1221 Conformance to [RFC7525] modern cipher suites is REQUIRED. 1223 9.1. SSH Transport 1225 To run over SSH, the client router first establishes an SSH transport 1226 connection using the SSHv2 transport protocol, and the client and 1227 server exchange keys for message integrity and encryption. The 1228 client then invokes the "ssh-userauth" service to authenticate the 1229 application, as described in the SSH authentication protocol 1230 [RFC4252]. Once the application has been successfully authenticated, 1231 the client invokes the "ssh-connection" service, also known as the 1232 SSH connection protocol. 1234 After the ssh-connection service is established, the client opens a 1235 channel of type "session", which results in an SSH session. 1237 Once the SSH session has been established, the application invokes 1238 the application transport as an SSH subsystem called "rpki-rtr". 1239 Subsystem support is a feature of SSHv2 and is not included in SSHv1. 1240 Running this protocol as an SSH subsystem avoids the need for the 1241 application to recognize shell prompts or skip over extraneous 1242 information, such as a system message that is sent at shell startup. 1244 It is assumed that the router and cache have exchanged keys out of 1245 band by some reasonably secured means. 1247 Cache servers supporting SSH transport MUST accept RSA authentication 1248 and SHOULD accept Elliptic Curve Digital Signature Algorithm (ECDSA) 1249 authentication. User authentication "publickey") MUST be supported; 1250 host authentication "hostbased") MAY be supported. Implementations 1251 MAY support password authentication "password"). "None" 1252 authentication MUST NOT be used. Client routers SHOULD verify the 1253 public key of the cache to avoid MITM attacks. 1255 9.2. TLS Transport 1257 Client routers using TLS transport MUST present client-side 1258 certificates to authenticate themselves to the cache in order to 1259 allow the cache to manage the load by rejecting connections from 1260 unauthorized routers. In principle, any type of certificate and 1261 Certification Authority (CA) may be used; however, in general, cache 1262 operators will wish to create their own small-scale CA and issue 1263 certificates to each authorized router. This simplifies credential 1264 rollover; any unrevoked, unexpired certificate from the proper CA may 1265 be used. 1267 Certificates used to authenticate client routers in this protocol 1268 MUST include a subjectAltName extension [RFC5280] containing one or 1269 more iPAddress identities; when authenticating the router's 1270 certificate, the cache MUST check the IP address of the TLS 1271 connection against these iPAddress identities and SHOULD reject the 1272 connection if none of the iPAddress identities match the connection. 1274 Routers MUST also verify the cache's TLS server certificate, using 1275 subjectAltName dNSName identities as described in [RFC6125], to avoid 1276 MITM attacks. The rules and guidelines defined in [RFC6125] apply 1277 here, with the following considerations: 1279 * Support for the DNS-ID identifier type (that is, the dNSName 1280 identity in the subjectAltName extension) is REQUIRED in rpki-rtr 1281 server and client implementations which use TLS. Certification 1282 authorities which issue rpki-rtr server certificates MUST support 1283 the DNS-ID identifier type, and the DNS-ID identifier type MUST be 1284 present in rpki-rtr server certificates. 1286 * DNS names in rpki-rtr server certificates SHOULD NOT contain the 1287 wildcard character "*". 1289 * rpki-rtr implementations which use TLS MUST NOT use Common Name 1290 (CN-ID) identifiers; a CN field may be present in the server 1291 certificate's subject name but MUST NOT be used for authentication 1292 within the rules described in [RFC6125]. 1294 * The client router MUST set its "reference identifier" (see 1295 Section 6.2 of [RFC6125]) to the DNS name of the rpki-rtr cache. 1297 9.3. TCP MD5 Transport 1299 If TCP MD5 is used, implementations MUST support key lengths of at 1300 least 80 printable ASCII bytes, per Section 4.5 of [RFC2385]. 1301 Implementations MUST also support hexadecimal sequences of at least 1302 32 characters, i.e., 128 bits. 1304 Key rollover with TCP MD5 is problematic. Cache servers SHOULD 1305 support [RFC4808]. 1307 9.4. TCP-AO Transport 1309 Implementations MUST support key lengths of at least 80 printable 1310 ASCII bytes. Implementations MUST also support hexadecimal sequences 1311 of at least 32 characters, i.e., 128 bits. Message Authentication 1312 Code (MAC) lengths of at least 96 bits MUST be supported, per 1313 Section 5.1 of [RFC5925]. 1315 The cryptographic algorithms and associated parameters described in 1316 [RFC5926] MUST be supported. 1318 10. Router-Cache Setup 1320 A cache has the public authentication data for each router it is 1321 configured to support. 1323 A router may be configured to peer with a selection of caches, and a 1324 cache may be configured to support a selection of routers. Each must 1325 have the name of, and authentication data for, each peer. In 1326 addition, in a router, this list has a non-unique preference value 1327 for each cache. This preference is intended to be based on 1328 proximity, a la RTT, not trust, preferred belief, et cetera. The 1329 client router attempts to establish a session with each potential 1330 serving cache in preference order and then starts to load data from 1331 the most preferred cache to which it can connect and authenticate. 1332 The router's list of caches has the following elements: 1334 Preference: An unsigned integer denoting the router's preference to 1335 connect to that cache; the lower the value, the more preferred. 1337 Name: The IP address or fully qualified domain name of the cache. 1339 Cache Credential(s): Any credential (such as a public key) needed to 1340 authenticate the cache's identity to the router. 1342 Router Credential(s): Any credential (such as a private key or 1343 certificate) needed to authenticate the router's identity to the 1344 cache. 1346 Due to the distributed nature of the RPKI, caches simply cannot be 1347 rigorously synchronous. A client may hold data from multiple caches 1348 but MUST keep the data marked as to source, as later updates MUST 1349 affect the correct data. 1351 Just as there may be more than one covering ROA from a single cache, 1352 there may be multiple covering ROAs from multiple caches. The 1353 results are as described in [RFC6811]. 1355 If data from multiple caches are held, implementations MUST NOT 1356 distinguish between data sources when performing validation of BGP 1357 announcements. 1359 When a more-preferred cache becomes available, if resources allow, it 1360 would be prudent for the client to start fetching from that cache. 1362 The client SHOULD attempt to maintain at least one set of data, 1363 regardless of whether it has chosen a different cache or established 1364 a new connection to the previous cache. 1366 A client MAY drop the data from a particular cache when it is fully 1367 in sync with one or more other caches. 1369 See Section 6 for details on what to do when the client is not able 1370 to refresh from a particular cache. 1372 If a client loses connectivity to a cache it is using or otherwise 1373 decides to switch to a new cache, it SHOULD retain the data from the 1374 previous cache until it has a full set of data from one or more other 1375 caches. Note that this may already be true at the point of 1376 connection loss if the client has connections to more than one cache. 1378 11. ROA PDU Race Minimization 1380 When a cache is sending ROA (IPv4 or IPv6) PDUs to a router, 1381 especially an initial full load in response to a Reset Query PDU, two 1382 undesirable race conditions are possible: 1384 Break Before Make: For some prefix P, an AS may announce two (or 1385 more) ROAs because they are in the process of changing what 1386 provider AS is announcing P. This is a case of "make before 1387 break." If a cache is feeding a router and sends the one not yet 1388 in service a significant time before sending the one currently in 1389 service, then BGP data could be marked invalid during the 1390 interval. To minimize that interval, the cache SHOULD announce 1391 all ROAs for the same prefix as close to sequentially as possible. 1393 Shorter Prefix First: If an AS has issued a ROA for P0, and another 1394 AS (likely their customer) has issued a ROA for P1 which is a sub- 1395 prefix of P0, a router which receives the ROA for P0 before that 1396 for P1 is likely to mark a BGP prefix P1 invalid. Therefore, the 1397 cache SHOULD announce the sub-prefix P1 before the covering prefix 1398 P0. 1400 12. Deployment Scenarios 1402 For illustration, we present three likely deployment scenarios: 1404 Small End Site: The small multihomed end site may wish to outsource 1405 the RPKI cache to one or more of their upstream ISPs. They would 1406 exchange authentication material with the ISP using some out-of- 1407 band mechanism, and their router(s) would connect to the cache(s) 1408 of one or more upstream ISPs. The ISPs would likely deploy caches 1409 intended for customer use separately from the caches with which 1410 their own BGP speakers peer. 1412 Large End Site: A larger multihomed end site might run one or more 1413 caches, arranging them in a hierarchy of client caches, each 1414 fetching from a serving cache which is closer to the Global RPKI. 1415 They might configure fallback peerings to upstream ISP caches. 1417 ISP Backbone: A large ISP would likely have one or more redundant 1418 caches in each major point of presence (PoP), and these caches 1419 would fetch from each other in an ISP-dependent topology so as not 1420 to place undue load on the Global RPKI. 1422 Experience with large DNS cache deployments has shown that complex 1423 topologies are ill-advised, as it is easy to make errors in the 1424 graph, e.g., not maintain a loop-free condition. 1426 Of course, these are illustrations, and there are other possible 1427 deployment strategies. It is expected that minimizing load on the 1428 Global RPKI servers will be a major consideration. 1430 To keep load on Global RPKI services from unnecessary peaks, it is 1431 recommended that caches which fetch from the Global RPKI not do so 1432 all at the same times, e.g., on the hour. Choose a random time, 1433 perhaps the ISP's AS number modulo 60, and jitter the inter-fetch 1434 timing. 1436 13. Error Codes 1438 This section describes the meaning of the error codes. There is an 1439 IANA registry where valid error codes are listed; see [iana-err]. 1440 Errors which are considered fatal MUST cause the session to be 1441 dropped, and the router MUST flush all data learned from that cache. 1443 0: Corrupt Data (fatal): The receiver believes the received PDU to 1444 be corrupt in a manner not specified by another error code. 1446 1: Internal Error (fatal): The party reporting the error experienced 1447 some kind of internal error unrelated to protocol operation (ran 1448 out of memory, a coding assertion failed, et cetera). 1450 2: No Data Available: The cache believes itself to be in good 1451 working order but is unable to answer either a Serial Query or a 1452 Reset Query because it has no useful data available at this time. 1453 This is likely to be a temporary error and most likely indicates 1454 that the cache has not yet completed pulling down an initial 1455 current data set from the Global RPKI system after some kind of 1456 event that invalidated whatever data it might have previously held 1457 (reboot, network partition, et cetera). 1459 3: Invalid Request (fatal): The cache server believes the client's 1460 request to be invalid. 1462 4: Unsupported Protocol Version (non-fatal): The Protocol Version is 1463 not known by the receiver of the PDU. A session is not 1464 [re-]established, but data learned need not be deleted. 1466 5: Unsupported PDU Type (fatal): The PDU Type is not known by the 1467 receiver of the PDU. 1469 6: Withdrawal of Unknown Record (fatal): The received PDU has 1470 Flag=0, but a matching record ({Prefix, Len, Max-Len, ASN} tuple 1471 for an IPvX PDU, or {SKI, ASN, Subject Public Key} tuple for a 1472 Router Key PDU), or Customer Autonomous System for an ASPA PDU 1473 does not exist in the receiver's database. 1475 7: Duplicate Announcement Received (fatal): The received PDU has 1476 Flag=1, but a matching record ({Prefix, Len, Max-Len, ASN} tuple 1477 for an IPvX PDU or {SKI, ASN, Subject Public Key} tuple for a 1478 Router Key PDU), or Customer Autonomous System for an ASPA PDU is 1479 already active in the router. 1481 8: Unexpected Protocol Version (fatal): The received PDU has a 1482 Protocol Version field that differs from the protocol version 1483 negotiated in Section 7. 1485 14. Security Considerations 1487 As this document describes a security protocol, many aspects of 1488 security interest are described in the relevant sections. This 1489 section points out issues which may not be obvious in other sections. 1491 Cache Validation: In order for a collection of caches as described 1492 in Section 12 to provide a consistent view, they need to be given 1493 consistent trust anchors of the Certification Authorities to use 1494 in their internal validation process. Distribution of a 1495 consistent trust anchor set to validating caches is assumed to be 1496 out of band. 1498 Cache Peer Identification: The router initiates a transport 1499 connection to a cache, which it identifies by either IP address or 1500 fully qualified domain name. Be aware that a DNS or address 1501 spoofing attack could make the correct cache unreachable. No 1502 session would be established, as the authorization keys would not 1503 match. 1505 Transport Security: The RPKI relies on object, not server or 1506 transport, trust. That is, the IANA root trust anchor is 1507 distributed to all caches through some out-of-band means and can 1508 then be used by each cache to validate certificates and ROAs all 1509 the way down the tree. The inter-cache relationships are based on 1510 this object security model; hence, the inter-cache transport can 1511 be lightly protected. 1513 However, this protocol document assumes that the routers cannot do 1514 the validation cryptography. Hence, the last link, from cache to 1515 router, SHOULD be secured by server authentication and transport- 1516 level security to prevent monkey in the middle attacks; though it 1517 might not be. Not using transport security is dangerous, as 1518 server authentication and transport have very different threat 1519 models than object security. 1521 So the strength of the trust relationship and the transport 1522 between the router(s) and the cache(s) are critical. You're 1523 betting your routing on this. 1525 While we cannot say the cache must be on the same LAN, if only due 1526 to the issue of an enterprise wanting to offload the cache task to 1527 their upstream ISP(s), locality, trust, and control are very 1528 critical issues here. The cache(s) really SHOULD be as close, in 1529 the sense of controlled and protected (against DDoS, MITM) 1530 transport, to the router(s) as possible. It also SHOULD be 1531 topologically close so that a minimum of validated routing data 1532 are needed to bootstrap a router's access to a cache. 1534 Authenticating transport protocols (i.e. not raw TCP) will 1535 authenticate the identity of the cache server to the router 1536 client, and vice versa, before any data are exchanged. 1538 Transports which cannot provide the necessary authentication and 1539 integrity (see Section 9) must rely on network design and 1540 operational controls to provide protection against spoofing/ 1541 corruption attacks. As pointed out in Section 9, TCP-AO is the 1542 long-term plan. Protocols which provide integrity and 1543 authenticity SHOULD be used, and if they cannot, i.e., TCP is used 1544 as the transport, the router and cache MUST be on the same 1545 trusted, controlled network. 1547 15. IANA Considerations 1549 This section only discusses updates required in the existing IANA 1550 protocol registries to accommodate version 2 of this protocol. See 1551 [RFC8210] for IANA considerations of the previous (version 1) 1552 protocol. 1554 All of the PDU types in the IANA "rpki-rtr-pdu" registry [iana-pdu] 1555 in protocol versions 0 and 1 are also allowed in protocol version 2, 1556 with the addition of the new ASPA PDU. 1558 The "rpki-rtr-pdu" registry [iana-pdu] has been updated as follows: 1560 Protocol PDU 1561 Version Type Description 1562 -------- ---- --------------- 1563 0-2 0 Serial Notify 1564 0-2 1 Serial Query 1565 0-2 2 Reset Query 1566 0-2 3 Cache Response 1567 0-2 4 IPv4 Prefix 1568 0-2 6 IPv6 Prefix 1569 0-2 7 End of Data 1570 0-2 8 Cache Reset 1571 0 9 Reserved 1572 1-2 9 Router Key 1573 0-2 10 Error Report 1574 0-1 11 Reserved 1575 2 11 ASPA 1576 0-2 255 Reserved 1578 This document requests the IANA to create a registry for ASPA AFI 1579 Flags 0 to 7. The name of the registry should be rpki-rtr-afi. The 1580 policy for adding to the registry is Expert Review per [RFC8126], 1581 where the responsible IESG area director should appoint the Expert 1582 Reviewer. The initial entries should be as follows: 1584 Bit Bit Name 1585 ---- ------------------- 1586 0 IPv4 AFI 1, currently MUST be set 1587 1 IPv6 AFI 2, currently MUST be set 1588 2-7 Reserved, MUST be zero 1590 16. References 1592 16.1. Normative References 1594 [I-D.ietf-sidrops-aspa-profile] 1595 Azimov, A., Uskov, E., Bush, R., Snijders, J., Housley, 1596 R., and B. Maddison, "A Profile for Autonomous System 1597 Provider Authorization", Work in Progress, Internet-Draft, 1598 draft-ietf-sidrops-aspa-profile-17, 7 November 2023, 1599 . 1602 [iana-err] IANA, "rpki-rtr-error", 1603 . 1605 [iana-pdu] IANA, "rpki-rtr-pdu", 1606 . 1608 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 1609 DOI 10.17487/RFC1982, August 1996, 1610 . 1612 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1613 Requirement Levels", BCP 14, RFC 2119, 1614 DOI 10.17487/RFC2119, March 1997, 1615 . 1617 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1618 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 1619 1998, . 1621 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1622 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1623 2003, . 1625 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 1626 Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, 1627 January 2006, . 1629 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1630 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1631 December 2005, . 1633 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1634 Housley, R., and W. Polk, "Internet X.509 Public Key 1635 Infrastructure Certificate and Certificate Revocation List 1636 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1637 . 1639 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1640 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1641 June 2010, . 1643 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 1644 for the TCP Authentication Option (TCP-AO)", RFC 5926, 1645 DOI 10.17487/RFC5926, June 2010, 1646 . 1648 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1649 Verification of Domain-Based Application Service Identity 1650 within Internet Public Key Infrastructure Using X.509 1651 (PKIX) Certificates in the Context of Transport Layer 1652 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1653 2011, . 1655 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 1656 X.509 PKIX Resource Certificates", RFC 6487, 1657 DOI 10.17487/RFC6487, February 2012, 1658 . 1660 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 1661 Infrastructure (RPKI) to Router Protocol", RFC 6810, 1662 DOI 10.17487/RFC6810, January 2013, 1663 . 1665 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 1666 Austein, "BGP Prefix Origin Validation", RFC 6811, 1667 DOI 10.17487/RFC6811, January 2013, 1668 . 1670 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1671 "Recommendations for Secure Use of Transport Layer 1672 Security (TLS) and Datagram Transport Layer Security 1673 (DTLS)", RFC 7525, DOI 10.17487/RFC7525, May 2015, 1674 . 1676 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1677 Writing an IANA Considerations Section in RFCs", BCP 26, 1678 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1679 . 1681 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1682 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1683 May 2017, . 1685 [RFC8210] Bush, R. and R. Austein, "The Resource Public Key 1686 Infrastructure (RPKI) to Router Protocol, Version 1", 1687 RFC 8210, DOI 10.17487/RFC8210, September 2017, 1688 . 1690 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1691 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1692 . 1694 [RFC8608] Turner, S. and O. Borchert, "BGPsec Algorithms, Key 1695 Formats, and Signature Formats", RFC 8608, 1696 DOI 10.17487/RFC8608, June 2019, 1697 . 1699 [RFC8635] Bush, R., Turner, S., and K. Patel, "Router Keying for 1700 BGPsec", RFC 8635, DOI 10.17487/RFC8635, August 2019, 1701 . 1703 16.2. Informative References 1705 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 1706 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 1707 August 1996, . 1709 [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", 1710 RFC 4808, DOI 10.17487/RFC4808, March 2007, 1711 . 1713 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 1714 Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, 1715 . 1717 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 1718 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 1719 February 2012, . 1721 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 1722 Resource Certificate Repository Structure", RFC 6481, 1723 DOI 10.17487/RFC6481, February 2012, 1724 . 1726 Acknowledgements 1728 The authors wish to thank Nils Bars, Steve Bellovin, Oliver Borchert, 1729 Mohamed Boucadair, Tim Bruijnzeels, Roman Danyliw, Rex Fernando, 1730 Richard Hansen, Martin Hoffmann, Paul Hoffman, Fabian Holler, Russ 1731 Housley, Pradosh Mohapatra, Keyur Patel, David Mandelberg, Sandy 1732 Murphy, Robert Raszuk, Andreas Reuter, Thomas Schmidt, John Scudder, 1733 Ruediger Volk, Matthias Waehlisch, and David Ward. Particular thanks 1734 go to Hannes Gredler for showing us the dangers of unnecessary 1735 fields. 1737 No doubt this list is incomplete. We apologize to any contributor 1738 whose name we missed. 1740 Authors' Addresses 1742 Randy Bush 1743 IIJ Research, Arrcus, & DRL 1744 5147 Crystal Springs 1745 Bainbridge Island, Washington 98110 1746 United States of America 1747 Email: randy@psg.com 1749 Rob Austein 1750 Dragon Research Labs 1751 Email: sra@hactrn.net