idnits 2.17.1 draft-ietf-sidrops-8210bis-10.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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (16 June 2022) is 679 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) == Outdated reference: A later version (-17) exists of draft-ietf-sidrops-aspa-profile-07 ** 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 (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Bush 3 Internet-Draft IIJ, Arrcus, & DRL 4 Intended status: Standards Track R. Austein 5 Expires: 18 December 2022 Dragon Research Labs 6 16 June 2022 8 The Resource Public Key Infrastructure (RPKI) to Router Protocol, 9 Version 2 10 draft-ietf-sidrops-8210bis-10 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 18 December 2022. 41 Copyright Notice 43 Copyright (c) 2022 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) . . . . . . . . . . . . . . . . . 6 64 5.1. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 7 65 5.2. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 10 66 5.3. Serial Query . . . . . . . . . . . . . . . . . . . . . . 10 67 5.4. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 11 68 5.5. Cache Response . . . . . . . . . . . . . . . . . . . . . 12 69 5.6. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 12 70 5.7. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 14 71 5.8. End of Data . . . . . . . . . . . . . . . . . . . . . . . 14 72 5.9. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 15 73 5.10. Router Key . . . . . . . . . . . . . . . . . . . . . . . 16 74 5.11. Error Report . . . . . . . . . . . . . . . . . . . . . . 17 75 5.12. ASPA PDU . . . . . . . . . . . . . . . . . . . . . . . . 18 76 6. Protocol Timing Parameters . . . . . . . . . . . . . . . . . 20 77 7. Protocol Version Negotiation . . . . . . . . . . . . . . . . 21 78 8. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . 23 79 8.1. Start or Restart . . . . . . . . . . . . . . . . . . . . 23 80 8.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . 24 81 8.3. No Incremental Update Available . . . . . . . . . . . . . 24 82 8.4. Cache Has No Data Available . . . . . . . . . . . . . . . 25 83 9. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 25 84 9.1. SSH Transport . . . . . . . . . . . . . . . . . . . . . . 27 85 9.2. TLS Transport . . . . . . . . . . . . . . . . . . . . . . 27 86 9.3. TCP MD5 Transport . . . . . . . . . . . . . . . . . . . . 28 87 9.4. TCP-AO Transport . . . . . . . . . . . . . . . . . . . . 28 88 10. Router-Cache Setup . . . . . . . . . . . . . . . . . . . . . 29 89 11. ROA PDU Race Minimization . . . . . . . . . . . . . . . . . . 30 90 12. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 30 91 13. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 31 92 14. Security Considerations . . . . . . . . . . . . . . . . . . . 32 93 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 94 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 95 16.1. Normative References . . . . . . . . . . . . . . . . . . 34 96 16.2. Informative References . . . . . . . . . . . . . . . . . 37 98 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 37 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 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 * The protocol version number incremented from 1 (one) to 2 (two) 153 and Section 7 has been updated accordingly. 155 2. Glossary 157 The following terms are used with special meaning. 159 Global RPKI: The authoritative data of the RPKI are published in a 160 distributed set of servers at the IANA, Regional Internet 161 Registries (RIRs), National Internet Registries (NIRs), and ISPs; 162 see [RFC6481]. 164 CA: The authoritative data of the RPKI are meant to be published by 165 a distributed set of Certification Authorities (CAs) at the IANA, 166 RIRs, NIRs, and ISPs (see [RFC6481]). 168 Cache: A Cache, AKA Relying Party Cache, is a coalesced copy of the 169 published Global RPKI data, periodically fetched or refreshed, 170 directly or indirectly, using the rsync protocol [RFC5781] or some 171 successor. Relying Party software is used to gather and validate 172 the distributed data of the RPKI into a cache. Trusting this 173 cache further is a matter between the provider of the cache and a 174 Relying Party. 176 Serial Number: "Serial Number" is a 32-bit strictly increasing 177 unsigned integer which wraps from 2^32-1 to 0. It denotes the 178 logical version of a cache. A cache increments the value when it 179 successfully updates its data from a parent cache or from primary 180 RPKI data. While a cache is receiving updates, new incoming data 181 and implicit deletes are associated with the new Serial Number but 182 MUST NOT be sent until the fetch is complete. A Serial Number is 183 not commensurate between different caches or different protocol 184 versions, nor need it be maintained across resets of the cache 185 server. See [RFC1982] on DNS Serial Number Arithmetic for too 186 much detail on the topic. 188 Session ID: When a cache server is started, it generates a Session 189 ID to uniquely identify the instance of the cache and to bind it 190 to the sequence of Serial Numbers that cache instance will 191 generate. This allows the router to restart a failed session 192 knowing that the Serial Number it is using is commensurate with 193 that of the cache. 195 Payload PDU: A payload PDU is a protocol message which contains data 196 for use by the router, as opposed to a PDU which conveys the 197 control mechanisms of this protocol. Prefixes and Router Keys are 198 examples of payload PDUs. 200 3. Deployment Structure 202 Deployment of the RPKI to reach routers has a three-level structure 203 as follows: 205 Global RPKI: The authoritative data of the RPKI are published in a 206 distributed set of servers at the IANA, RIRs, NIRs, and ISPs (see 207 [RFC6481]). 209 Local Caches: Local caches are a local set of one or more collected 210 and verified caches of RPKI data. A Relying Party, e.g., router 211 or other client, MUST have a trust relationship with, and a 212 trusted transport channel to, any cache(s) it uses. 214 Routers: A router fetches data from a local cache using the protocol 215 described in this document. It is said to be a client of the 216 cache. There MAY be mechanisms for the router to assure itself of 217 the authenticity of the cache and to authenticate itself to the 218 cache (see Section 9). 220 4. Operational Overview 222 A router establishes and keeps open a transport connection to one or 223 more caches with which it has client/server relationships. It is 224 configured with a semi-ordered list of caches and establishes a 225 connection to the most preferred cache, or set of caches, which 226 accept the connections. 228 The router MUST choose the most preferred, by configuration, cache or 229 set of caches so that the operator may control load on their caches 230 and the Global RPKI. 232 Periodically, the router sends a Serial Query to the cache the most 233 recent Serial Number for which it has received data from that cache, 234 i.e., the router's current Serial Number, in the form of a Serial 235 Query. When a router establishes a new session with a cache or 236 wishes to reset a current relationship, it sends a Reset Query. 238 The cache responds to the Serial Query with all data changes which 239 took place since the given Serial Number. This may be the null set, 240 in which case the End of Data PDU (Section 5.8) is still sent. Note 241 that the Serial Number comparison used to determine "since the given 242 Serial Number" MUST take wrap-around into account; see [RFC1982]. 244 When the router has received all data records from the cache, it sets 245 its current Serial Number to that of the Serial Number in the 246 received End of Data PDU. 248 When the cache updates its database, it sends a Notify PDU to every 249 currently connected router. This is a hint that now would be a good 250 time for the router to poll for an update, but it is only a hint. 251 The protocol requires the router to poll for updates periodically in 252 any case. 254 Strictly speaking, a router could track a cache simply by asking for 255 a complete data set every time it updates, but this would be very 256 inefficient. The Serial-Number-based incremental update mechanism 257 allows an efficient transfer of just the data records which have 258 changed since the last update. As with any update protocol based on 259 incremental transfers, the router must be prepared to fall back to a 260 full transfer if for any reason the cache is unable to provide the 261 necessary incremental data. Unlike some incremental transfer 262 protocols, this protocol requires the router to make an explicit 263 request to start the fallback process; this is deliberate, as the 264 cache has no way of knowing whether the router has also established 265 sessions with other caches that may be able to provide better 266 service. 268 As a cache server must evaluate certificates and ROAs (Route Origin 269 Authorizations; see [RFC6480]), which are time dependent, servers' 270 clocks MUST be correct to a tolerance of an hour. 272 Barring errors, transport connections remain up as long as the cache 273 and router remain up and the router is not reconfigured to no longer 274 use the cache. 276 Should a transport connection be lost for unknown reasons, the router 277 SHOULD try to reestablish one; being careful to not abuse the cache 278 with two many failed requests. 280 5. Protocol Data Units (PDUs) 282 The exchanges between the cache and the router are sequences of 283 exchanges of the following PDUs according to the rules described in 284 Section 8. 286 Reserved fields (marked "zero" in PDU diagrams) MUST be zero on 287 transmission and MUST be ignored on receipt. 289 5.1. Fields of a PDU 291 PDUs contain the following data elements: 293 Protocol Version: An 8-bit unsigned integer, currently 2, denoting 294 the version of this protocol. 296 PDU Type: An 8-bit unsigned integer, denoting the type of the PDU, 297 e.g., IPv4 Prefix. 299 Serial Number: A 32-bit unsigned integer serializing the RPKI cache 300 epoch when this set of PDUs was received from an upstream cache 301 server or gathered from the Global RPKI. A cache increments its 302 Serial Number when completing a validated update from a parent 303 cache or the Global RPKI. 305 Session ID: A 16-bit unsigned integer. When a cache server is 306 started, it generates a Session ID to identify the instance of the 307 cache and to bind it to the sequence of Serial Numbers that cache 308 instance will generate. This allows the router to restart a 309 failed session knowing that the Serial Number it is using is 310 commensurate with that of the cache. If, at any time after the 311 protocol version has been negotiated (Section 7), either the 312 router or the cache finds that the value of the Session ID is not 313 the same as the other's, the party which detects the mismatch MUST 314 immediately terminate the session with an Error Report PDU with 315 code 0 ("Corrupt Data"), and the router MUST flush all data 316 learned from that cache. 318 Note that sessions are specific to a particular protocol version. 319 That is, if a cache server supports multiple versions of this 320 protocol, happens to use the same Session ID value for multiple 321 protocol versions, and further happens to use the same Serial 322 Number values for two or more sessions using the same Session ID 323 but different Protocol Version values, the Serial Numbers are not 324 commensurate. The full test for whether Serial Numbers are 325 commensurate requires comparing Protocol Version, Session ID, and 326 Serial Number. To reduce the risk of confusion, cache servers 327 SHOULD NOT use the same Session ID across multiple protocol 328 versions, but even if they do, routers MUST treat sessions with 329 different Protocol Version fields as separate sessions even if 330 they do happen to have the same Session ID. 332 Should a cache erroneously reuse a Session ID so that a router 333 does not realize that the session has changed (old Session ID and 334 new Session ID have the same numeric value), the router may become 335 confused as to the content of the cache. The time it takes the 336 router to discover that it is confused will depend on whether the 337 Serial Numbers are also reused. If the Serial Numbers in the old 338 and new sessions are different enough, the cache will respond to 339 the router's Serial Query with a Cache Reset, which will solve the 340 problem. If, however, the Serial Numbers are close, the cache may 341 respond with a Cache Response, which may not be enough to bring 342 the router into sync. In such cases, it's likely but not certain 343 that the router will detect some discrepancy between the state 344 that the cache expects and its own state. For example, the Cache 345 Response may tell the router to drop a record which the router 346 does not hold or may tell the router to add a record which the 347 router already has. In such cases, a router will detect the error 348 and reset the session. The one case in which the router may stay 349 out of sync is when nothing in the Cache Response contradicts any 350 data currently held by the router. 352 Using persistent storage for the Session ID or a clock-based 353 scheme for generating Session IDs should avoid the risk of Session 354 ID collisions. 356 The Session ID might be a pseudorandom value, a strictly 357 increasing value if the cache has reliable storage, et cetera. A 358 seconds-since-epoch timestamp value such as the low order 16 bits 359 of unsigned integer seconds since 1970-01-01T00:00:00Z ignoring 360 leap seconds might make a good Session ID value. 362 Length: A 32-bit unsigned integer which has as its value the count 363 of the bytes in the entire PDU, including the 8 bytes of header 364 which includes the length field. 366 Flags: An 8-bit binary field, with the lowest-order bit being 1 for 367 an announcement and 0 for a withdrawal. For a Prefix PDU (IPv4 or 368 IPv6), the announce/withdraw flag indicates whether this PDU 369 announces a new right to announce the prefix or withdraws a 370 previously announced right; a withdraw effectively deletes one 371 previously announced Prefix PDU with the exact same Prefix, 372 Length, Max-Len, and Autonomous System Number (ASN). 374 Similarly, for a Router Key PDU, the flag indicates whether this 375 PDU announces a new Router Key or deletes one previously announced 376 Router Key PDU with the exact same AS Number, 377 subjectKeyIdentifier, and subjectPublicKeyInfo. 379 The remaining bits in the Flags field are reserved for future use. 381 Prefix Length: An 8-bit unsigned integer denoting the shortest 382 prefix allowed by the Prefix element. 384 Max Length: An 8-bit unsigned integer denoting the longest prefix 385 allowed by the Prefix element. This MUST NOT be less than the 386 Prefix Length element. 388 Prefix: The IPv4 or IPv6 prefix of the ROA. 390 Autonomous System Number: A 32-bit unsigned integer representing an 391 ASN allowed to announce a prefix or associated with a router key. 393 Subject Key Identifier: The 20-octet Subject Key Identifier (SKI) 394 value of a router key, as described in [RFC6487]. 396 Subject Public Key Info: A variable length field holding a router 397 key's subjectPublicKeyInfo value, as described in [RFC8608]. This 398 is the full ASN.1 DER encoding of the subjectPublicKeyInfo, 399 including the ASN.1 tag and length values of the 400 subjectPublicKeyInfo SEQUENCE. 402 Refresh Interval: A 32-bit interval in seconds between normal cache 403 polls. See Section 6. 405 Retry Interval: A 32-bit interval in seconds between cache poll 406 retries after a failed cache poll. See Section 6. 408 Expire Interval: A 32-bit interval in seconds during which data 409 fetched from a cache remains valid in the absence of a successful 410 subsequent cache poll. See Section 6. 412 AFI Flags: An 8-bit field of the ASPA PDU where the low order bit 413 denotes whether the AS relationships are for IPv4 (0) or IPv6 (1) 414 AFI. 416 Provider AS Count: A 16-bit count of Provider Autonomous System 417 Numbers in the PDU. 419 Customer Autonomous System Number: The 32-bit AS number of the 420 Autonomous System that authorizes the upstream providers listed in 421 the Provider Autonomous System list to propagate prefixes of the 422 specified address family to other ASes. 424 Provider Autonomous System Numbers: The set of 32-bit AS numbers 425 authorized to propagate prefixes of the specified AFI which were 426 received from the customer AS. 428 5.2. Serial Notify 430 The cache notifies the router that the cache has new data. 432 The Session ID reassures the router that the Serial Numbers are 433 commensurate, i.e., the cache session has not been changed. 435 Upon receipt of a Serial Notify PDU, the router MAY issue an 436 immediate Serial Query (Section 5.3) or Reset Query (Section 5.4) 437 without waiting for the Refresh Interval timer (see Section 6) to 438 expire. 440 Serial Notify is the only message that the cache can send that is not 441 in response to a message from the router. 443 If the router receives a Serial Notify PDU during the initial startup 444 period where the router and cache are still negotiating to agree on a 445 protocol version, the router MUST simply ignore the Serial Notify 446 PDU, even if the Serial Notify PDU is for an unexpected protocol 447 version. See Section 7 for details. 449 0 8 16 24 31 450 .-------------------------------------------. 451 | Protocol | PDU | | 452 | Version | Type | Session ID | 453 | 2 | 0 | | 454 +-------------------------------------------+ 455 | | 456 | Length=12 | 457 | | 458 +-------------------------------------------+ 459 | | 460 | Serial Number | 461 | | 462 `-------------------------------------------' 464 5.3. Serial Query 466 The router sends a Serial Query to ask the cache for all 467 announcements and withdrawals which have occurred since the Serial 468 Number specified in the Serial Query. 470 The cache replies to this query with a Cache Response PDU 471 (Section 5.5) if the cache has a (possibly null) record of the 472 changes since the Serial Number specified by the router, followed by 473 zero or more payload PDUs and an End Of Data PDU (Section 5.8). 475 When replying to a Serial Query, the cache MUST return the minimum 476 set of changes needed to bring the router into sync with the cache. 477 That is, if a particular prefix or router key underwent multiple 478 changes between the Serial Number specified by the router and the 479 cache's current Serial Number, the cache MUST merge those changes to 480 present the simplest possible view of those changes to the router. 481 In general, this means that, for any particular prefix or router key, 482 the data stream will include at most one withdrawal followed by at 483 most one announcement, and if all of the changes cancel out, the data 484 stream will not mention the prefix or router key at all. 486 The rationale for this approach is that the entire purpose of the 487 RPKI-Router protocol is to offload work from the router to the cache, 488 and it should therefore be the cache's job to simplify the change 489 set, thus reducing work for the router. 491 If the cache does not have the data needed to update the router, 492 perhaps because its records do not go back to the Serial Number in 493 the Serial Query, then it responds with a Cache Reset PDU 494 (Section 5.9). 496 The Session ID tells the cache what instance the router expects to 497 ensure that the Serial Numbers are commensurate, i.e., the cache 498 session has not been changed. 500 0 8 16 24 31 501 .-------------------------------------------. 502 | Protocol | PDU | | 503 | Version | Type | Session ID | 504 | 2 | 1 | | 505 +-------------------------------------------+ 506 | | 507 | Length=12 | 508 | | 509 +-------------------------------------------+ 510 | | 511 | Serial Number | 512 | | 513 `-------------------------------------------' 515 5.4. Reset Query 517 The router tells the cache that it wants to receive the total active, 518 current, non-withdrawn database. The cache responds with a Cache 519 Response PDU (Section 5.5), followed by zero or more payload PDUs and 520 an End of Data PDU (Section 5.8). 522 0 8 16 24 31 523 .-------------------------------------------. 524 | Protocol | PDU | | 525 | Version | Type | zero | 526 | 2 | 2 | | 527 +-------------------------------------------+ 528 | | 529 | Length=8 | 530 | | 531 `-------------------------------------------' 533 5.5. Cache Response 535 The cache responds to queries with zero or more payload PDUs. When 536 replying to a Serial Query (Section 5.3), the cache sends the set of 537 announcements and withdrawals that have occurred since the Serial 538 Number sent by the client router. When replying to a Reset Query 539 (Section 5.4), the cache sends the set of all data records it has; in 540 this case, the announce/withdraw field in the payload PDUs MUST have 541 the value 1 (announce). 543 In response to a Reset Query, the new value of the Session ID tells 544 the router the instance of the cache session for future confirmation. 545 In response to a Serial Query, the Session ID being the same 546 reassures the router that the Serial Numbers are commensurate, i.e., 547 the cache session has not been changed. 549 0 8 16 24 31 550 .-------------------------------------------. 551 | Protocol | PDU | | 552 | Version | Type | Session ID | 553 | 2 | 3 | | 554 +-------------------------------------------+ 555 | | 556 | Length=8 | 557 | | 558 `-------------------------------------------' 560 5.6. IPv4 Prefix 561 0 8 16 24 31 562 .-------------------------------------------. 563 | Protocol | PDU | | 564 | Version | Type | zero | 565 | 2 | 4 | | 566 +-------------------------------------------+ 567 | | 568 | Length=20 | 569 | | 570 +-------------------------------------------+ 571 | | Prefix | Max | | 572 | Flags | Length | Length | zero | 573 | | 0..32 | 0..32 | | 574 +-------------------------------------------+ 575 | | 576 | IPv4 Prefix | 577 | | 578 +-------------------------------------------+ 579 | | 580 | Autonomous System Number | 581 | | 582 `-------------------------------------------' 584 This PDU carries an [RFC6811] Validated ROA Payload (VRP) for an IPv4 585 ROA. 587 The lowest-order bit of the Flags field is 1 for an announcement and 588 0 for a withdrawal. 590 In the RPKI, nothing prevents a signing certificate from issuing two 591 identical ROAs. In this case, there would be no semantic difference 592 between the objects, merely a process redundancy. 594 In the RPKI, there is also an actual need for what might appear to a 595 router as identical IPvX PDUs. This can occur when an upstream 596 certificate is being reissued or there is an address ownership 597 transfer up the validation chain. The ROA would be identical in the 598 router sense, i.e., have the same {Prefix, Len, Max-Len, ASN}, but it 599 would have a different validation path in the RPKI. This is 600 important to the RPKI but not to the router. 602 The cache server MUST ensure that it has told the router client to 603 have one and only one IPvX PDU for a unique {Prefix, Len, Max-Len, 604 ASN} at any one point in time. Should the router client receive an 605 IPvX PDU with a {Prefix, Len, Max-Len, ASN} identical to one it 606 already has active, it SHOULD raise a Duplicate Announcement Received 607 error. 609 5.7. IPv6 Prefix 611 0 8 16 24 31 612 .-------------------------------------------. 613 | Protocol | PDU | | 614 | Version | Type | zero | 615 | 2 | 6 | | 616 +-------------------------------------------+ 617 | | 618 | Length=32 | 619 | | 620 +-------------------------------------------+ 621 | | Prefix | Max | | 622 | Flags | Length | Length | zero | 623 | | 0..128 | 0..128 | | 624 +-------------------------------------------+ 625 | | 626 +--- ---+ 627 | | 628 +--- IPv6 Prefix ---+ 629 | | 630 +--- ---+ 631 | | 632 +-------------------------------------------+ 633 | | 634 | Autonomous System Number | 635 | | 636 `-------------------------------------------' 638 This PDU carries an [RFC6811] Validated ROA Payload (VRP) for an IPv6 639 ROA. 641 Analogous to the IPv4 Prefix PDU, it has 96 more bits and no magic. 643 5.8. End of Data 645 The cache tells the router it has no more data for the request. 647 The Session ID and Protocol Version MUST be the same as that of the 648 corresponding Cache Response which began the (possibly null) sequence 649 of payload PDUs. 651 0 8 16 24 31 652 .-------------------------------------------. 653 | Protocol | PDU | | 654 | Version | Type | Session ID | 655 | 2 | 7 | | 656 +-------------------------------------------+ 657 | | 658 | Length=24 | 659 | | 660 +-------------------------------------------+ 661 | | 662 | Serial Number | 663 | | 664 +-------------------------------------------+ 665 | | 666 | Refresh Interval | 667 | | 668 +-------------------------------------------+ 669 | | 670 | Retry Interval | 671 | | 672 +-------------------------------------------+ 673 | | 674 | Expire Interval | 675 | | 676 `-------------------------------------------' 678 The Refresh Interval, Retry Interval, and Expire Interval are all 679 32-bit elapsed times measured in seconds. They express the timing 680 parameters which the cache expects the router to use in deciding when 681 to send subsequent Serial Query or Reset Query PDUs to the cache. 682 See Section 6 for an explanation of the use and the range of allowed 683 values for these parameters. 685 Note that the End of Data PDU changed significantly between versions 686 0 and 1. Version 2 End of Data is the same as Version 1. 688 5.9. Cache Reset 690 The cache may respond to a Serial Query informing the router that the 691 cache cannot provide an incremental update starting from the Serial 692 Number specified by the router. The router must decide whether to 693 issue a Reset Query or switch to a different cache. 695 0 8 16 24 31 696 .-------------------------------------------. 697 | Protocol | PDU | | 698 | Version | Type | zero | 699 | 2 | 8 | | 700 +-------------------------------------------+ 701 | | 702 | Length=8 | 703 | | 704 `-------------------------------------------' 706 5.10. Router Key 708 0 8 16 24 31 709 .-------------------------------------------. 710 | Protocol | PDU | | | 711 | Version | Type | Flags | zero | 712 | 2 | 9 | | | 713 +-------------------------------------------+ 714 | | 715 | Length | 716 | | 717 +-------------------------------------------+ 718 | | 719 +--- ---+ 720 | Subject Key Identifier | 721 +--- ---+ 722 | | 723 +--- ---+ 724 | (20 octets) | 725 +--- ---+ 726 | | 727 +-------------------------------------------+ 728 | | 729 | AS Number | 730 | | 731 +-------------------------------------------+ 732 | | 733 | Subject Public Key Info | 734 | | 735 `-------------------------------------------' 737 The Router Key PDU transports an [RFC8635] Router key. 739 The lowest-order bit of the Flags field is 1 for an announcement and 740 0 for a withdrawal. 742 The cache server MUST ensure that it has told the router client to 743 have one and only one Router Key PDU for a unique {SKI, ASN, Subject 744 Public Key} at any one point in time. Should the router client 745 receive a Router Key PDU with a {SKI, ASN, Subject Public Key} 746 identical to one it already has active, it SHOULD raise a Duplicate 747 Announcement Received error. 749 Note that a particular ASN may appear in multiple Router Key PDUs 750 with different Subject Public Key values, while a particular Subject 751 Public Key value may appear in multiple Router Key PDUs with 752 different ASNs. In the interest of keeping the announcement and 753 withdrawal semantics as simple as possible for the router, this 754 protocol makes no attempt to compress either of these cases. 756 Also note that it is possible, albeit very unlikely, for multiple 757 distinct Subject Public Key values to hash to the same SKI. For this 758 reason, implementations MUST compare Subject Public Key values as 759 well as SKIs when detecting duplicate PDUs. 761 As the Subject Public Key Info is a variable length field, it must be 762 decoded to determine where the PDU terminates. 764 5.11. Error Report 766 This PDU is used by either party to report an error to the other. 768 Error reports are only sent as responses to other PDUs, not to report 769 errors in Error Report PDUs. 771 Error codes are described in Section 13. 773 The Erroneous PDU field is a binary copy of the PDU causing the error 774 condition, including all fields. 776 If the error is generic (e.g., "Internal Error") and not associated 777 with the PDU to which it is responding, the Erroneous PDU field MUST 778 be empty and the Length of Encapsulated PDU field MUST be zero. 780 An Error Report PDU MUST NOT be sent for an Error Report PDU. If an 781 erroneous Error Report PDU is received, the session SHOULD be 782 dropped. 784 If the error is associated with a PDU of excessive length, i.e., too 785 long to be any legal PDU other than another Error Report, or a 786 possibly corrupt length, the Erroneous PDU field MAY be truncated. 788 The Arbitrary Text field is optional; if not present, the Length of 789 Arbitrary text field MUST be zero. If Arbitrary Text is present, it 790 MUST be a string in UTF-8 encoding (see [RFC3629]) in the Queen's 791 English. 793 0 8 16 24 31 794 .-------------------------------------------. 795 | Protocol | PDU | | 796 | Version | Type | Error Code | 797 | 2 | 10 | | 798 +-------------------------------------------+ 799 | | 800 | Length | 801 | | 802 +-------------------------------------------+ 803 | | 804 | Length of Encapsulated PDU | 805 | | 806 +-------------------------------------------+ 807 | | 808 ~ Erroneous PDU ~ 809 | | 810 +-------------------------------------------+ 811 | | 812 | Length of Arbitrary Text | 813 | | 814 +-------------------------------------------+ 815 | | 816 | Arbitrary Text | 817 ~ of ~ 818 | Error Diagnostic Message | 819 | | 820 `-------------------------------------------' 822 5.12. ASPA PDU 823 0 8 16 24 31 824 .-------------------------------------------. 825 | Protocol | PDU | | 826 | Version | Type | zero | 827 | 2 | 11 | | 828 +-------------------------------------------+ 829 | | 830 | Length | 831 | | 832 +-------------------------------------------+ 833 | | | | 834 | Flags | AFI Flags| Provider AS Count | 835 | | | | 836 +-------------------------------------------+ 837 | | 838 | Customer Autonomous System Number | 839 | | 840 +-------------------------------------------+ 841 | | 842 ~ Provider Autonomous System Numbers ~ 843 | | 844 ~-------------------------------------------~ 846 The ASPA PDU supports [I-D.ietf-sidrops-aspa-profile]. An ASPA PDU 847 represents one single customer AS and its provider ASes for a 848 particular Address Family. Receipt of an ASPA PDU announcement 849 (announce/withdraw flag == 1) when the router already has an ASPA PDU 850 with the same Customer Autonomous System Number and the same Address 851 Family (see AFI Flags field), replaces the previous one. The cache 852 MUST deliver the complete data of an ASPA record in a single ASPA 853 PDU. 855 The router MUST see at most one ASPA for a given AFI from a cache for 856 a particular Customer Autonomous System Number active at any time. 857 As a number of conditions in the global RPKI may present multiple 858 valid ASPA RPKI records for a single customer to a particular RP 859 cache, this places a burden on the cache to form the union of 860 multiple ASPA records it has received from the global RPKI into one 861 ASPA PDU. 863 The Flags field is as described in Section 5. 865 For the ASPA PDU, the announce/withdraw Flag is set to 1 to indicate 866 either the announcement of a new ASPA record or a replacement for a 867 previously announced record with the same Customer Autonomous System 868 Number and AFI. 870 If the announce/withdraw flag is set to 0, it indicates removal of 871 the entire ASPA record for the specified AFI and Customer AS. Here, 872 the AFI and the customer AS of the ASPA record MUST be provided, the 873 Provider AS Count must be zero, the Provider AS Numbers list MUST be 874 null, and these last two fields MUST be ignored by the router. 876 The AFI Flags field is defined in Section 15. 878 The Provider AS Count is the number of 32-bit Provider Autonomous 879 System Numbers in the PDU. 881 The Customer Autonomous System Number is the 32-bit Autonomous System 882 Number of the customer which authenticated the ASPA RPKI data. For a 883 given AFI, there MUST be one and only one ASPA for a Customer 884 Autonomous System Number active in the router at any time. 886 There are zero or more 32-bit Provider Autonomous System Number 887 fields as indicated in the Provider AS Count; see 888 [I-D.ietf-sidrops-aspa-profile]. 890 6. Protocol Timing Parameters 892 Since the data the cache distributes via the RPKI-Router protocol are 893 retrieved from the Global RPKI system at intervals which are only 894 known to the cache, only the cache can really know how frequently it 895 makes sense for the router to poll the cache, or how long the data 896 are likely to remain valid (or, at least, unchanged). For this 897 reason, as well as to allow the cache some control over the load 898 placed on it by its client routers, the End Of Data PDU includes 899 three values that allow the cache to communicate timing parameters to 900 the router: 902 Refresh Interval: This parameter tells the router how long to wait 903 before next attempting to poll the cache and between subsequent 904 attempts, using a Serial Query or Reset Query PDU. The router 905 SHOULD NOT poll the cache sooner than indicated by this parameter. 906 Note that receipt of a Serial Notify PDU overrides this interval 907 and suggests that the router issue an immediate query without 908 waiting for the Refresh Interval to expire. Countdown for this 909 timer starts upon receipt of the containing End Of Data PDU. 911 Minimum allowed value: 1 second. 913 Maximum allowed value: 86400 seconds (1 day). 915 Recommended default: 3600 seconds (1 hour). 917 Retry Interval: This parameter tells the router how long to wait 918 before retrying a failed Serial Query or Reset Query. The router 919 SHOULD NOT retry sooner than indicated by this parameter. Note 920 that a protocol version mismatch overrides this interval: if the 921 router needs to downgrade to a lower protocol version number, it 922 MAY send the first Serial Query or Reset Query immediately. 923 Countdown for this timer starts upon failure of the query and 924 restarts after each subsequent failure until a query succeeds. 926 Minimum allowed value: 1 second. 928 Maximum allowed value: 7200 seconds (2 hours). 930 Recommended default: 600 seconds (10 minutes). 932 Expire Interval: This parameter tells the router how long it can 933 continue to use the current version of the data while unable to 934 perform a successful subsequent query. The router MUST NOT retain 935 the data past the time indicated by this parameter. Countdown for 936 this timer starts upon receipt of the containing End Of Data PDU. 938 Minimum allowed value: 600 seconds (10 minutes). 940 Maximum allowed value: 172800 seconds (2 days). 942 Recommended default: 7200 seconds (2 hours). 944 If the router has never issued a successful query against a 945 particular cache, it SHOULD retry periodically using the default 946 Retry Interval, above. 948 Caches MUST set Expire Interval to a value larger than both the 949 Refresh Interval and the Retry Interval. 951 7. Protocol Version Negotiation 953 A router MUST start each transport connection by issuing either a 954 Reset Query or a Serial Query. This query MUST tell the cache the 955 highest version of this protocol the router implements. 957 If a cache which supports version N receives a Reset Query with 958 Version Q < N, the cache MUST downgrade to protocol version Q 959 [RFC6810] or [RFC8210]. If the router's Reset Request was Q > N, the 960 cache MUST send a version 2 Error Report PDU with Error Code 4 961 ("Unsupported Protocol Version"), and the router MUST send another 962 Reset Query with a lower Version Q. Yjis MAY repeat. If the router 963 requests Q == 0 and it still fails, then the router MUST abort the 964 session, sending a version 2 Error Report PDU with Error Code 4 965 ("Unsupported Protocol Version"). 967 If a router which supports version N sends a query to a cache which 968 only supports version C < N, one of two things will happen: 970 1. The cache may terminate the connection, perhaps with a version 2 971 Error Report PDU with Error Code 4 ("Unsupported Protocol 972 Version"). In this case, the router MAY retry the connection 973 using protocol version C. 975 2. The cache may reply with a version C response. In this case, the 976 router MUST either downgrade to version C or terminate the 977 connection. 979 In any of the downgraded combinations above, the new features of the 980 higher version will not be available, and all PDUs MUST have the 981 negotiated lower version number in their version fields. 983 If either party receives a PDU containing an unrecognized Protocol 984 Version (neither 0, 1, nor 2) during this negotiation, it MUST either 985 downgrade to a known version or terminate the connection, with an 986 Error Report PDU unless the received PDU is itself an Error Report 987 PDU. 989 The router MUST ignore any Serial Notify PDUs it might receive from 990 the cache during this initial startup period, regardless of the 991 Protocol Version field in the Serial Notify PDU. Since Session ID 992 and Serial Number values are specific to a particular protocol 993 version, the values in the notification are not useful to the router. 994 Even if these values were meaningful, the only effect that processing 995 the notification would have would be to trigger exactly the same 996 Reset Query or Serial Query that the router has already sent as part 997 of the not-yet-complete version negotiation process, so there is 998 nothing to be gained by processing notifications until version 999 negotiation completes. 1001 Caches SHOULD NOT send Serial Notify PDUs before version negotiation 1002 completes. Routers, however, MUST handle such notifications (by 1003 ignoring them) for backwards compatibility with caches serving 1004 protocol version 0. 1006 Once the cache and router have agreed upon a Protocol Version via the 1007 negotiation process above, that version is stable for the life of the 1008 session. See Section 5.1 for a discussion of the interaction between 1009 Protocol Version and Session ID. 1011 If either party receives a PDU for a different Protocol Version once 1012 the above negotiation completes, that party MUST drop the session; 1013 unless the PDU containing the unexpected Protocol Version was itself 1014 an Error Report PDU, the party dropping the session SHOULD send an 1015 Error Report with an error code of 8 ("Unexpected Protocol Version"). 1017 8. Protocol Sequences 1019 The sequences of PDU transmissions fall into four conversations as 1020 follows: 1022 8.1. Start or Restart 1024 Cache Router 1025 ~ ~ 1026 | <----- Reset Query -------- | R requests data (or Serial Query) 1027 | | 1028 | ----- Cache Response -----> | C confirms request 1029 | ------- Payload PDU ------> | C sends zero or more 1030 | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, 1031 | ------- Payload PDU ------> | ASPA, or Router Key PDUs 1032 | ------- End of Data ------> | C sends End of Data 1033 | | and sends new serial 1034 ~ ~ 1036 When a transport connection is first established, the router MUST 1037 send either a Reset Query or a Serial Query. A Serial Query would be 1038 appropriate if the router has unexpired data from a broken session 1039 with the same cache and remembers the Session ID of that session, in 1040 which case a Serial Query containing the Session ID from the previous 1041 session will allow the router to bring itself up to date while 1042 ensuring that the Serial Numbers are commensurate and that the router 1043 and cache are speaking compatible versions of the protocol. In all 1044 other cases, the router lacks the necessary data for fast 1045 resynchronization and therefore MUST fall back to a Reset Query. 1047 The Reset Query sequence is also used when the router receives a 1048 Cache Reset, chooses a new cache, or fears that it has otherwise lost 1049 its way. 1051 See Section 7 for details on version negotiation. 1053 To limit the length of time a cache must keep the data necessary to 1054 generate incremental updates, a router MUST send either a Serial 1055 Query or a Reset Query periodically. This also acts as a keep-alive 1056 at the application layer. See Section 6 for details on the required 1057 polling frequency. 1059 8.2. Typical Exchange 1061 Cache Router 1062 ~ ~ 1063 | -------- Notify ----------> | (optional) 1064 | | 1065 | <----- Serial Query ------- | R requests data 1066 | | 1067 | ----- Cache Response -----> | C confirms request 1068 | ------- Payload PDU ------> | C sends zero or more 1069 | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, 1070 | ------- Payload PDU ------> | ASPA. or Router Key PDUs 1071 | ------- End of Data ------> | C sends End of Data 1072 | | and sends new serial 1073 ~ ~ 1075 The cache server SHOULD send a Notify PDU with its current Serial 1076 Number when the cache's serial changes, with the expectation that the 1077 router MAY then issue a Serial Query earlier than it otherwise might. 1078 This is analogous to DNS NOTIFY in [RFC1996]. The cache MUST rate- 1079 limit Serial Notifies to no more frequently than one per minute. 1081 When the transport layer is up and either a timer has gone off in the 1082 router or the cache has sent a Notify PDU, the router queries for new 1083 data by sending a Serial Query, and the cache sends all data newer 1084 than the serial in the Serial Query. 1086 To limit the length of time a cache must keep old withdraws, a router 1087 MUST send either a Serial Query or a Reset Query periodically. See 1088 Section 6 for details on the required polling frequency. 1090 8.3. No Incremental Update Available 1092 Cache Router 1093 ~ ~ 1094 | <------ Serial Query ------ | R requests data 1095 | ------- Cache Reset ------> | C cannot supply update 1096 | | from specified serial 1097 | <------ Reset Query ------- | R requests new data 1098 | ----- Cache Response -----> | C confirms request 1099 | ------- Payload PDU ------> | C sends zero or more 1100 | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, 1101 | ------- Payload PDU ------> | ASPA, or Router Key PDUs 1102 | ------- End of Data ------> | C sends End of Data 1103 | | and sends new serial 1104 ~ ~ 1106 The cache may respond to a Serial Query with a Cache Reset, informing 1107 the router that the cache cannot supply an incremental update from 1108 the Serial Number specified by the router. This might be because the 1109 cache has lost state, or because the router has waited too long 1110 between polls and the cache has cleaned up old data that it no longer 1111 believes it needs, or because the cache has run out of storage space 1112 and had to expire some old data early. Regardless of how this state 1113 arose, the cache replies with a Cache Reset to tell the router that 1114 it cannot honor the request. When a router receives this, the router 1115 SHOULD attempt to connect to any more-preferred caches in its cache 1116 list. If there are no more-preferred caches, it MUST issue a Reset 1117 Query and get an entire new load from the cache. 1119 8.4. Cache Has No Data Available 1121 Cache Router 1122 ~ ~ 1123 | <------ Serial Query ------ | R requests data 1124 | ---- Error Report PDU ----> | C No Data Available 1125 ~ ~ 1127 Cache Router 1128 ~ ~ 1129 | <------ Reset Query ------- | R requests data 1130 | ---- Error Report PDU ----> | C No Data Available 1131 ~ ~ 1133 The cache may respond to either a Serial Query or a Reset Query 1134 informing the router that the cache cannot supply any update at all. 1135 The most likely cause is that the cache has lost state, perhaps due 1136 to a restart, and has not yet recovered. While it is possible that a 1137 cache might go into such a state without dropping any of its active 1138 sessions, a router is more likely to see this behavior when it 1139 initially connects and issues a Reset Query while the cache is still 1140 rebuilding its database. 1142 When a router receives this kind of error, the router SHOULD attempt 1143 to connect to any other caches in its cache list, in preference 1144 order. If no other caches are available, the router MUST issue 1145 periodic Reset Queries until it gets a new usable load from the 1146 cache; maybe once a minute so as not to DoS the cache. 1148 9. Transport 1150 The transport-layer session between a router and a cache carries the 1151 binary PDUs in a persistent session. 1153 To prevent cache spoofing and DoS attacks by illegitimate routers, it 1154 is highly desirable that the router and the cache be authenticated to 1155 each other. Integrity protection for payloads is also desirable to 1156 protect against monkey-in-the-middle (MITM) attacks. Unfortunately, 1157 there is no protocol to do so on all currently used platforms. 1158 Therefore, as of the writing of this document, there is no mandatory- 1159 to-implement transport which provides authentication and integrity 1160 protection. 1162 To reduce exposure to dropped but non-terminated sessions, both 1163 caches and routers SHOULD enable keep-alives when available in the 1164 chosen transport protocol. 1166 It is expected that, when the TCP Authentication Option (TCP-AO) 1167 [RFC5925] is available on all platforms deployed by operators, it 1168 will become the mandatory-to-implement transport. 1170 Caches and routers MUST implement unprotected transport over TCP 1171 using a port, rpki-rtr (323); see Section 15. Operators SHOULD use 1172 procedural means, e.g., access control lists (ACLs), to reduce the 1173 exposure to authentication issues. 1175 If unprotected TCP is the transport, the cache and routers MUST be on 1176 the same trusted and controlled network. 1178 If available to the operator, caches and routers MUST use one of the 1179 following more protected protocols: 1181 * Caches and routers SHOULD use TCP-AO transport [RFC5925] over the 1182 rpki-rtr port. 1184 * Caches and routers MAY use Secure Shell version 2 (SSHv2) 1185 transport [RFC4252] using the normal SSH port. For an example, 1186 see Section 9.1. 1188 * Caches and routers MAY use TCP MD5 transport [RFC2385] using the 1189 rpki-rtr port if no other protected transport is available. Note 1190 that TCP MD5 has been obsoleted by TCP-AO [RFC5925]. 1192 * Caches and routers MAY use TCP over IPsec transport [RFC4301] 1193 using the rpki-rtr port. 1195 * Caches and routers MAY use Transport Layer Security (TLS) 1196 transport [RFC8446] using port rpki-rtr-tls (324); see Section 15. 1197 Conformance to [RFC7525] modern cipher suites is REQUIRED. 1199 9.1. SSH Transport 1201 To run over SSH, the client router first establishes an SSH transport 1202 connection using the SSHv2 transport protocol, and the client and 1203 server exchange keys for message integrity and encryption. The 1204 client then invokes the "ssh-userauth" service to authenticate the 1205 application, as described in the SSH authentication protocol 1206 [RFC4252]. Once the application has been successfully authenticated, 1207 the client invokes the "ssh-connection" service, also known as the 1208 SSH connection protocol. 1210 After the ssh-connection service is established, the client opens a 1211 channel of type "session", which results in an SSH session. 1213 Once the SSH session has been established, the application invokes 1214 the application transport as an SSH subsystem called "rpki-rtr". 1215 Subsystem support is a feature of SSHv2 and is not included in SSHv1. 1216 Running this protocol as an SSH subsystem avoids the need for the 1217 application to recognize shell prompts or skip over extraneous 1218 information, such as a system message that is sent at shell startup. 1220 It is assumed that the router and cache have exchanged keys out of 1221 band by some reasonably secured means. 1223 Cache servers supporting SSH transport MUST accept RSA authentication 1224 and SHOULD accept Elliptic Curve Digital Signature Algorithm (ECDSA) 1225 authentication. User authentication "publickey") MUST be supported; 1226 host authentication "hostbased") MAY be supported. Implementations 1227 MAY support password authentication "password"). "None" 1228 authentication MUST NOT be used. Client routers SHOULD verify the 1229 public key of the cache to avoid MITM attacks. 1231 9.2. TLS Transport 1233 Client routers using TLS transport MUST present client-side 1234 certificates to authenticate themselves to the cache in order to 1235 allow the cache to manage the load by rejecting connections from 1236 unauthorized routers. In principle, any type of certificate and 1237 Certification Authority (CA) may be used; however, in general, cache 1238 operators will wish to create their own small-scale CA and issue 1239 certificates to each authorized router. This simplifies credential 1240 rollover; any unrevoked, unexpired certificate from the proper CA may 1241 be used. 1243 Certificates used to authenticate client routers in this protocol 1244 MUST include a subjectAltName extension [RFC5280] containing one or 1245 more iPAddress identities; when authenticating the router's 1246 certificate, the cache MUST check the IP address of the TLS 1247 connection against these iPAddress identities and SHOULD reject the 1248 connection if none of the iPAddress identities match the connection. 1250 Routers MUST also verify the cache's TLS server certificate, using 1251 subjectAltName dNSName identities as described in [RFC6125], to avoid 1252 MITM attacks. The rules and guidelines defined in [RFC6125] apply 1253 here, with the following considerations: 1255 * Support for the DNS-ID identifier type (that is, the dNSName 1256 identity in the subjectAltName extension) is REQUIRED in rpki-rtr 1257 server and client implementations which use TLS. Certification 1258 authorities which issue rpki-rtr server certificates MUST support 1259 the DNS-ID identifier type, and the DNS-ID identifier type MUST be 1260 present in rpki-rtr server certificates. 1262 * DNS names in rpki-rtr server certificates SHOULD NOT contain the 1263 wildcard character "*". 1265 * rpki-rtr implementations which use TLS MUST NOT use Common Name 1266 (CN-ID) identifiers; a CN field may be present in the server 1267 certificate's subject name but MUST NOT be used for authentication 1268 within the rules described in [RFC6125]. 1270 * The client router MUST set its "reference identifier" (see 1271 Section 6.2 of [RFC6125]) to the DNS name of the rpki-rtr cache. 1273 9.3. TCP MD5 Transport 1275 If TCP MD5 is used, implementations MUST support key lengths of at 1276 least 80 printable ASCII bytes, per Section 4.5 of [RFC2385]. 1277 Implementations MUST also support hexadecimal sequences of at least 1278 32 characters, i.e., 128 bits. 1280 Key rollover with TCP MD5 is problematic. Cache servers SHOULD 1281 support [RFC4808]. 1283 9.4. TCP-AO Transport 1285 Implementations MUST support key lengths of at least 80 printable 1286 ASCII bytes. Implementations MUST also support hexadecimal sequences 1287 of at least 32 characters, i.e., 128 bits. Message Authentication 1288 Code (MAC) lengths of at least 96 bits MUST be supported, per 1289 Section 5.1 of [RFC5925]. 1291 The cryptographic algorithms and associated parameters described in 1292 [RFC5926] MUST be supported. 1294 10. Router-Cache Setup 1296 A cache has the public authentication data for each router it is 1297 configured to support. 1299 A router may be configured to peer with a selection of caches, and a 1300 cache may be configured to support a selection of routers. Each must 1301 have the name of, and authentication data for, each peer. In 1302 addition, in a router, this list has a non-unique preference value 1303 for each cache. This preference is intended to be based on 1304 proximity, a la RTT, not trust, preferred belief, et cetera. The 1305 client router attempts to establish a session with each potential 1306 serving cache in preference order and then starts to load data from 1307 the most preferred cache to which it can connect and authenticate. 1308 The router's list of caches has the following elements: 1310 Preference: An unsigned integer denoting the router's preference to 1311 connect to that cache; the lower the value, the more preferred. 1313 Name: The IP address or fully qualified domain name of the cache. 1315 Cache Credential(s): Any credential (such as a public key) needed to 1316 authenticate the cache's identity to the router. 1318 Router Credential(s): Any credential (such as a private key or 1319 certificate) needed to authenticate the router's identity to the 1320 cache. 1322 Due to the distributed nature of the RPKI, caches simply cannot be 1323 rigorously synchronous. A client may hold data from multiple caches 1324 but MUST keep the data marked as to source, as later updates MUST 1325 affect the correct data. 1327 Just as there may be more than one covering ROA from a single cache, 1328 there may be multiple covering ROAs from multiple caches. The 1329 results are as described in [RFC6811]. 1331 If data from multiple caches are held, implementations MUST NOT 1332 distinguish between data sources when performing validation of BGP 1333 announcements. 1335 When a more-preferred cache becomes available, if resources allow, it 1336 would be prudent for the client to start fetching from that cache. 1338 The client SHOULD attempt to maintain at least one set of data, 1339 regardless of whether it has chosen a different cache or established 1340 a new connection to the previous cache. 1342 A client MAY drop the data from a particular cache when it is fully 1343 in sync with one or more other caches. 1345 See Section 6 for details on what to do when the client is not able 1346 to refresh from a particular cache. 1348 If a client loses connectivity to a cache it is using or otherwise 1349 decides to switch to a new cache, it SHOULD retain the data from the 1350 previous cache until it has a full set of data from one or more other 1351 caches. Note that this may already be true at the point of 1352 connection loss if the client has connections to more than one cache. 1354 11. ROA PDU Race Minimization 1356 When a cache is sending ROA (IPv4 or IPv6) PDUs to a router, 1357 especially an initial full load in response to a Reset Query PDU, two 1358 undesirable race conditions are possible: 1360 Break Before Make: For some prefix P, an AS may announce two (or 1361 more) ROAs because they are in the process of changing what 1362 provider AS is announcing P. This is a case of "make before 1363 break." If a cache is feeding a router and sends the one not yet 1364 in service a significant time before sending the one currently in 1365 service, then BGP data could be marked invalid during the 1366 interval. To minimize that interval, the cache SHOULD announce 1367 all ROAs for the same prefix as close to sequentially as possible. 1369 Shorter Prefix First: If an AS has issued a ROA for P0, and another 1370 AS (likely their customer) has issued a ROA for P1 which is a sub- 1371 prefix of P0, a router which receives the ROA for P0 before that 1372 for P1 is likely to mark a BGP prefix P1 invalid. Therefore, the 1373 cache SHOULD announce the sub-prefix P1 before the covering prefix 1374 P0. 1376 12. Deployment Scenarios 1378 For illustration, we present three likely deployment scenarios: 1380 Small End Site: The small multihomed end site may wish to outsource 1381 the RPKI cache to one or more of their upstream ISPs. They would 1382 exchange authentication material with the ISP using some out-of- 1383 band mechanism, and their router(s) would connect to the cache(s) 1384 of one or more upstream ISPs. The ISPs would likely deploy caches 1385 intended for customer use separately from the caches with which 1386 their own BGP speakers peer. 1388 Large End Site: A larger multihomed end site might run one or more 1389 caches, arranging them in a hierarchy of client caches, each 1390 fetching from a serving cache which is closer to the Global RPKI. 1391 They might configure fallback peerings to upstream ISP caches. 1393 ISP Backbone: A large ISP would likely have one or more redundant 1394 caches in each major point of presence (PoP), and these caches 1395 would fetch from each other in an ISP-dependent topology so as not 1396 to place undue load on the Global RPKI. 1398 Experience with large DNS cache deployments has shown that complex 1399 topologies are ill-advised, as it is easy to make errors in the 1400 graph, e.g., not maintain a loop-free condition. 1402 Of course, these are illustrations, and there are other possible 1403 deployment strategies. It is expected that minimizing load on the 1404 Global RPKI servers will be a major consideration. 1406 To keep load on Global RPKI services from unnecessary peaks, it is 1407 recommended that caches which fetch from the Global RPKI not do so 1408 all at the same times, e.g., on the hour. Choose a random time, 1409 perhaps the ISP's AS number modulo 60, and jitter the inter-fetch 1410 timing. 1412 13. Error Codes 1414 This section describes the meaning of the error codes. There is an 1415 IANA registry where valid error codes are listed; see [iana-err]. 1416 Errors which are considered fatal MUST cause the session to be 1417 dropped. 1419 0: Corrupt Data (fatal): The receiver believes the received PDU to 1420 be corrupt in a manner not specified by another error code. 1422 1: Internal Error (fatal): The party reporting the error experienced 1423 some kind of internal error unrelated to protocol operation (ran 1424 out of memory, a coding assertion failed, et cetera). 1426 2: No Data Available: The cache believes itself to be in good 1427 working order but is unable to answer either a Serial Query or a 1428 Reset Query because it has no useful data available at this time. 1429 This is likely to be a temporary error and most likely indicates 1430 that the cache has not yet completed pulling down an initial 1431 current data set from the Global RPKI system after some kind of 1432 event that invalidated whatever data it might have previously held 1433 (reboot, network partition, et cetera). 1435 3: Invalid Request (fatal): The cache server believes the client's 1436 request to be invalid. 1438 4: Unsupported Protocol Version (fatal): The Protocol Version is not 1439 known by the receiver of the PDU. 1441 5: Unsupported PDU Type (fatal): The PDU Type is not known by the 1442 receiver of the PDU. 1444 6: Withdrawal of Unknown Record (fatal): The received PDU has 1445 Flag=0, but a matching record ({Prefix, Len, Max-Len, ASN} tuple 1446 for an IPvX PDU, or {SKI, ASN, Subject Public Key} tuple for a 1447 Router Key PDU), or Customer Autonomous System for an ASPA PDU 1448 does not exist in the receiver's database. 1450 7: Duplicate Announcement Received (fatal): The received PDU has 1451 Flag=1, but a matching record ({Prefix, Len, Max-Len, ASN} tuple 1452 for an IPvX PDU or {SKI, ASN, Subject Public Key} tuple for a 1453 Router Key PDU), or Customer Autonomous System for an ASPA PDU is 1454 already active in the router. 1456 8: Unexpected Protocol Version (fatal): The received PDU has a 1457 Protocol Version field that differs from the protocol version 1458 negotiated in Section 7. 1460 14. Security Considerations 1462 As this document describes a security protocol, many aspects of 1463 security interest are described in the relevant sections. This 1464 section points out issues which may not be obvious in other sections. 1466 Cache Validation: In order for a collection of caches as described 1467 in Section 12 to provide a consistent view, they need to be given 1468 consistent trust anchors of the Certification Authorities to use 1469 in their internal validation process. Distribution of a 1470 consistent trust anchor set to validating caches is assumed to be 1471 out of band. 1473 Cache Peer Identification: The router initiates a transport 1474 connection to a cache, which it identifies by either IP address or 1475 fully qualified domain name. Be aware that a DNS or address 1476 spoofing attack could make the correct cache unreachable. No 1477 session would be established, as the authorization keys would not 1478 match. 1480 Transport Security: The RPKI relies on object, not server or 1481 transport, trust. That is, the IANA root trust anchor is 1482 distributed to all caches through some out-of-band means and can 1483 then be used by each cache to validate certificates and ROAs all 1484 the way down the tree. The inter-cache relationships are based on 1485 this object security model; hence, the inter-cache transport can 1486 be lightly protected. 1488 However, this protocol document assumes that the routers cannot do 1489 the validation cryptography. Hence, the last link, from cache to 1490 router, SHOULD be secured by server authentication and transport- 1491 level security to prevent monkey in the middle attacks; though it 1492 might not be. Not using transport security is dangerous, as 1493 server authentication and transport have very different threat 1494 models than object security. 1496 So the strength of the trust relationship and the transport 1497 between the router(s) and the cache(s) are critical. You're 1498 betting your routing on this. 1500 While we cannot say the cache must be on the same LAN, if only due 1501 to the issue of an enterprise wanting to offload the cache task to 1502 their upstream ISP(s), locality, trust, and control are very 1503 critical issues here. The cache(s) really SHOULD be as close, in 1504 the sense of controlled and protected (against DDoS, MITM) 1505 transport, to the router(s) as possible. It also SHOULD be 1506 topologically close so that a minimum of validated routing data 1507 are needed to bootstrap a router's access to a cache. 1509 Authenticating transport protocols (i.e. not raw TCP) will 1510 authenticate the identity of the cache server to the router 1511 client, and vice versa, before any data are exchanged. 1513 Transports which cannot provide the necessary authentication and 1514 integrity (see Section 9) must rely on network design and 1515 operational controls to provide protection against spoofing/ 1516 corruption attacks. As pointed out in Section 9, TCP-AO is the 1517 long-term plan. Protocols which provide integrity and 1518 authenticity SHOULD be used, and if they cannot, i.e., TCP is used 1519 as the transport, the router and cache MUST be on the same 1520 trusted, controlled network. 1522 15. IANA Considerations 1524 This section only discusses updates required in the existing IANA 1525 protocol registries to accommodate version 2 of this protocol. See 1526 [RFC8210] for IANA considerations of the previous (version 1) 1527 protocol. 1529 All of the PDU types in the IANA "rpki-rtr-pdu" registry [iana-pdu] 1530 in protocol versions 0 and 1 are also allowed in protocol version 2, 1531 with the addition of the new ASPA PDU. 1533 The "rpki-rtr-pdu" registry [iana-pdu] has been updated as follows: 1535 Protocol PDU 1536 Version Type Description 1537 -------- ---- --------------- 1538 0-2 0 Serial Notify 1539 0-2 1 Serial Query 1540 0-2 2 Reset Query 1541 0-2 3 Cache Response 1542 0-2 4 IPv4 Prefix 1543 0-2 6 IPv6 Prefix 1544 0-2 7 End of Data 1545 0-2 8 Cache Reset 1546 0 9 Reserved 1547 1-2 9 Router Key 1548 0-2 10 Error Report 1549 0-1 11 Reserved 1550 2 11 ASPA 1551 0-2 255 Reserved 1553 This document requests the IANA to create a registry for ASPA AFI 1554 Flags 0 to 7. The name of the registry should be rpki-rtr-afi. The 1555 policy for adding to the registry is Expert Review per [RFC8126], 1556 where the responsible IESG area director should appoint the Expert 1557 Reviewer. The initial entries should be as follows: 1559 Bit Bit Name 1560 ---- ------------------- 1561 0 AFI (IPv4 == 0, IPv6 == 1) 1562 1-7 Reserved, MUST be zero 1564 16. References 1566 16.1. Normative References 1568 [I-D.ietf-sidrops-aspa-profile] 1569 Azimov, A., Uskov, E., Bush, R., Patel, K., Snijders, J., 1570 and R. Housley, "A Profile for Autonomous System Provider 1571 Authorization", Work in Progress, Internet-Draft, draft- 1572 ietf-sidrops-aspa-profile-07, 31 January 2022, 1573 . 1576 [iana-err] IANA, "rpki-rtr-error", 1577 . 1579 [iana-pdu] IANA, "rpki-rtr-pdu", 1580 . 1582 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 1583 DOI 10.17487/RFC1982, August 1996, 1584 . 1586 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1587 Requirement Levels", BCP 14, RFC 2119, 1588 DOI 10.17487/RFC2119, March 1997, 1589 . 1591 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1592 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 1593 1998, . 1595 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1596 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1597 2003, . 1599 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 1600 Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, 1601 January 2006, . 1603 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1604 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1605 December 2005, . 1607 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1608 Housley, R., and W. Polk, "Internet X.509 Public Key 1609 Infrastructure Certificate and Certificate Revocation List 1610 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1611 . 1613 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1614 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1615 June 2010, . 1617 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 1618 for the TCP Authentication Option (TCP-AO)", RFC 5926, 1619 DOI 10.17487/RFC5926, June 2010, 1620 . 1622 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1623 Verification of Domain-Based Application Service Identity 1624 within Internet Public Key Infrastructure Using X.509 1625 (PKIX) Certificates in the Context of Transport Layer 1626 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1627 2011, . 1629 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 1630 X.509 PKIX Resource Certificates", RFC 6487, 1631 DOI 10.17487/RFC6487, February 2012, 1632 . 1634 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 1635 Infrastructure (RPKI) to Router Protocol", RFC 6810, 1636 DOI 10.17487/RFC6810, January 2013, 1637 . 1639 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 1640 Austein, "BGP Prefix Origin Validation", RFC 6811, 1641 DOI 10.17487/RFC6811, January 2013, 1642 . 1644 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1645 "Recommendations for Secure Use of Transport Layer 1646 Security (TLS) and Datagram Transport Layer Security 1647 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1648 2015, . 1650 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1651 Writing an IANA Considerations Section in RFCs", BCP 26, 1652 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1653 . 1655 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1656 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1657 May 2017, . 1659 [RFC8210] Bush, R. and R. Austein, "The Resource Public Key 1660 Infrastructure (RPKI) to Router Protocol, Version 1", 1661 RFC 8210, DOI 10.17487/RFC8210, September 2017, 1662 . 1664 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1665 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1666 . 1668 [RFC8608] Turner, S. and O. Borchert, "BGPsec Algorithms, Key 1669 Formats, and Signature Formats", RFC 8608, 1670 DOI 10.17487/RFC8608, June 2019, 1671 . 1673 [RFC8635] Bush, R., Turner, S., and K. Patel, "Router Keying for 1674 BGPsec", RFC 8635, DOI 10.17487/RFC8635, August 2019, 1675 . 1677 16.2. Informative References 1679 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 1680 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 1681 August 1996, . 1683 [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", 1684 RFC 4808, DOI 10.17487/RFC4808, March 2007, 1685 . 1687 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 1688 Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, 1689 . 1691 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 1692 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 1693 February 2012, . 1695 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 1696 Resource Certificate Repository Structure", RFC 6481, 1697 DOI 10.17487/RFC6481, February 2012, 1698 . 1700 Acknowledgements 1702 The authors wish to thank Nils Bars, Steve Bellovin, Oliver Borchert, 1703 Mohamed Boucadair, Tim Bruijnzeels, Roman Danyliw, Rex Fernando, 1704 Richard Hansen, Martin Hoffmann, Paul Hoffman, Fabian Holler, Russ 1705 Housley, Pradosh Mohapatra, Keyur Patel, David Mandelberg, Sandy 1706 Murphy, Robert Raszuk, Andreas Reuter, Thomas Schmidt, John Scudder, 1707 Ruediger Volk, Matthias Waehlisch, and David Ward. Particular thanks 1708 go to Hannes Gredler for showing us the dangers of unnecessary 1709 fields. 1711 No doubt this list is incomplete. We apologize to any contributor 1712 whose name we missed. 1714 Authors' Addresses 1716 Randy Bush 1717 IIJ, Arrcus, & DRL 1718 5147 Crystal Springs 1719 Bainbridge Island, Washington 98110 1720 United States of America 1721 Email: randy@psg.com 1723 Rob Austein 1724 Dragon Research Labs 1725 Email: sra@hactrn.net