idnits 2.17.1 draft-ietf-sidrops-8210bis-03.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 (15 August 2021) is 979 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-06 ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 8208 (Obsoleted by RFC 8608) Summary: 4 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 Updates: 8210 (if approved) R. Austein 5 Intended status: Standards Track Dragon Research Labs 6 Expires: 16 February 2022 15 August 2021 8 The Resource Public Key Infrastructure (RPKI) to Router Protocol, 9 Version 2 10 draft-ietf-sidrops-8210bis-03 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 updates RFC 8210. 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 16 February 2022. 41 Copyright Notice 43 Copyright (c) 2021 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 Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified 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 . . . . . . . . . . . . . . . . . . . . 4 62 4. Operational Overview . . . . . . . . . . . . . . . . . . . . 5 63 5. Protocol Data Units (PDUs) . . . . . . . . . . . . . . . . . 6 64 5.1. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 6 65 5.2. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 9 66 5.3. Serial Query . . . . . . . . . . . . . . . . . . . . . . 9 67 5.4. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 11 68 5.5. Cache Response . . . . . . . . . . . . . . . . . . . . . 11 69 5.6. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 11 70 5.7. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 12 71 5.8. End of Data . . . . . . . . . . . . . . . . . . . . . . . 13 72 5.9. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 15 73 5.10. Router Key . . . . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . 22 79 8.1. Start or Restart . . . . . . . . . . . . . . . . . . . . 22 80 8.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . . . . . . 33 94 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 95 16.1. Normative References . . . . . . . . . . . . . . . . . . 34 96 16.2. Informative References . . . . . . . . . . . . . . . . . 36 98 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 37 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 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 document updates [RFC8210]. 113 Section 3 describes the deployment structure, and Section 4 then 114 presents an operational overview. The binary payloads of the 115 protocol are formally described in Section 5, and the expected 116 Protocol Data Unit (PDU) sequences are described in Section 8. The 117 transport protocol options are described in Section 9. Section 10 118 details how routers and caches are configured to connect and 119 authenticate. Section 12 describes likely deployment scenarios. The 120 traditional security and IANA considerations end the document. 122 The protocol is extensible in order to support new PDUs with new 123 semantics, if deployment experience indicates that they are needed. 124 PDUs are versioned should deployment experience call for change. 126 1.1. Requirements Language 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in BCP 131 14 [RFC2119] [RFC8174] when, and only when, they appear in all 132 capitals, as shown here. 134 1.2. Changes from RFC 8210 136 This section summarizes the significant changes between [RFC8210] and 137 the protocol described in this document. 139 * A new ASPA PDU type (Section 5.12) has added to support 140 [I-D.ietf-sidrops-aspa-profile]. 142 * A small section, Section 11, has been added to handle two ROA PDU 143 race conditions, Break Before Make and Shorter Prefix First. 145 * The protocol version number incremented from 1 (one) to 2 (two) 146 and the Section 7 section has been updated accordingly. 148 2. Glossary 150 The following terms are used with special meaning. 152 Global RPKI: The authoritative data of the RPKI are published in a 153 distributed set of servers at the IANA, Regional Internet 154 Registries (RIRs), National Internet Registries (NIRs), and ISPs; 155 see [RFC6481]. 157 Cache: A cache is a coalesced copy of the published Global RPKI 158 data, periodically fetched or refreshed, directly or indirectly, 159 using the rsync protocol [RFC5781] or some successor. Relying 160 Party software is used to gather and validate the distributed data 161 of the RPKI into a cache. Trusting this cache further is a matter 162 between the provider of the cache and a Relying Party. 164 Serial Number: "Serial Number" is a 32-bit strictly increasing 165 unsigned integer which wraps from 2^32-1 to 0. It denotes the 166 logical version of a cache. A cache increments the value when it 167 successfully updates its data from a parent cache or from primary 168 RPKI data. While a cache is receiving updates, new incoming data 169 and implicit deletes are associated with the new serial but MUST 170 NOT be sent until the fetch is complete. A Serial Number is not 171 commensurate between different caches or different protocol 172 versions, nor need it be maintained across resets of the cache 173 server. See [RFC1982] on DNS Serial Number Arithmetic for too 174 much detail on the topic. 176 Session ID: When a cache server is started, it generates a Session 177 ID to uniquely identify the instance of the cache and to bind it 178 to the sequence of Serial Numbers that cache instance will 179 generate. This allows the router to restart a failed session 180 knowing that the Serial Number it is using is commensurate with 181 that of the cache. 183 Payload PDU: A payload PDU is a protocol message which contains data 184 for use by the router, as opposed to a PDU which conveys the 185 control mechanisms of this protocol. Prefixes and Router Keys are 186 examples of payload PDUs. 188 3. Deployment Structure 190 Deployment of the RPKI to reach routers has a three-level structure 191 as follows: 193 Global RPKI: The authoritative data of the RPKI are published in a 194 distributed set of servers at the IANA, RIRs, NIRs, and ISPs (see 195 [RFC6481]). 197 Local Caches: Local caches are a local set of one or more collected 198 and verified caches of RPKI data. A Relying Party, e.g., router 199 or other client, MUST have a trust relationship with, and a 200 trusted transport channel to, any cache(s) it uses. 202 Routers: A router fetches data from a local cache using the protocol 203 described in this document. It is said to be a client of the 204 cache. There MAY be mechanisms for the router to assure itself of 205 the authenticity of the cache and to authenticate itself to the 206 cache (see Section 9). 208 4. Operational Overview 210 A router establishes and keeps open a connection to one or more 211 caches with which it has client/server relationships. It is 212 configured with a semi-ordered list of caches and establishes a 213 connection to the most preferred cache, or set of caches, which 214 accept the connections. 216 The router MUST choose the most preferred, by configuration, cache or 217 set of caches so that the operator may control load on their caches 218 and the Global RPKI. 220 Periodically, the router sends to the cache the most recent Serial 221 Number for which it has received data from that cache, i.e., the 222 router's current Serial Number, in the form of a Serial Query. When 223 a router establishes a new session with a cache or wishes to reset a 224 current relationship, it sends a Reset Query. 226 The cache responds to the Serial Query with all data changes which 227 took place since the given Serial Number. This may be the null set, 228 in which case the End of Data PDU (Section 5.8) is still sent. Note 229 that the Serial Number comparison used to determine "since the given 230 Serial Number" MUST take wrap-around into account; see [RFC1982]. 232 When the router has received all data records from the cache, it sets 233 its current Serial Number to that of the Serial Number in the 234 received End of Data PDU. 236 When the cache updates its database, it sends a Notify PDU to every 237 currently connected router. This is a hint that now would be a good 238 time for the router to poll for an update, but it is only a hint. 239 The protocol requires the router to poll for updates periodically in 240 any case. 242 Strictly speaking, a router could track a cache simply by asking for 243 a complete data set every time it updates, but this would be very 244 inefficient. The Serial-Number-based incremental update mechanism 245 allows an efficient transfer of just the data records which have 246 changed since the last update. As with any update protocol based on 247 incremental transfers, the router must be prepared to fall back to a 248 full transfer if for any reason the cache is unable to provide the 249 necessary incremental data. Unlike some incremental transfer 250 protocols, this protocol requires the router to make an explicit 251 request to start the fallback process; this is deliberate, as the 252 cache has no way of knowing whether the router has also established 253 sessions with other caches that may be able to provide better 254 service. 256 As a cache server must evaluate certificates and ROAs (Route Origin 257 Authorizations; see [RFC6480]), which are time dependent, servers' 258 clocks MUST be correct to a tolerance of approximately an hour. 260 5. Protocol Data Units (PDUs) 262 The exchanges between the cache and the router are sequences of 263 exchanges of the following PDUs according to the rules described in 264 Section 8. 266 Reserved fields (marked "zero" in PDU diagrams) MUST be zero on 267 transmission and MUST be ignored on receipt. 269 5.1. Fields of a PDU 271 PDUs contain the following data elements: 273 Protocol Version: An 8-bit unsigned integer, currently 1, denoting 274 the version of this protocol. 276 PDU Type: An 8-bit unsigned integer, denoting the type of the PDU, 277 e.g., IPv4 Prefix. 279 Serial Number: The Serial Number of the RPKI cache when this set of 280 PDUs was received from an upstream cache server or gathered from 281 the Global RPKI. A cache increments its Serial Number when 282 completing a rigorously validated update from a parent cache or 283 the Global RPKI. 285 Session ID: A 16-bit unsigned integer. When a cache server is 286 started, it generates a Session ID to identify the instance of the 287 cache and to bind it to the sequence of Serial Numbers that cache 288 instance will generate. This allows the router to restart a 289 failed session knowing that the Serial Number it is using is 290 commensurate with that of the cache. If, at any time after the 291 protocol version has been negotiated (Section 7), either the 292 router or the cache finds that the value of the Session ID is not 293 the same as the other's, the party which detects the mismatch MUST 294 immediately terminate the session with an Error Report PDU with 295 code 0 ("Corrupt Data"), and the router MUST flush all data 296 learned from that cache. 298 Note that sessions are specific to a particular protocol version. 299 That is, if a cache server supports multiple versions of this 300 protocol, happens to use the same Session ID value for multiple 301 protocol versions, and further happens to use the same Serial 302 Number values for two or more sessions using the same Session ID 303 but different Protocol Version values, the Serial Numbers are not 304 commensurate. The full test for whether Serial Numbers are 305 commensurate requires comparing Protocol Version, Session ID, and 306 Serial Number. To reduce the risk of confusion, cache servers 307 SHOULD NOT use the same Session ID across multiple protocol 308 versions, but even if they do, routers MUST treat sessions with 309 different Protocol Version fields as separate sessions even if 310 they do happen to have the same Session ID. 312 Should a cache erroneously reuse a Session ID so that a router 313 does not realize that the session has changed (old Session ID and 314 new Session ID have the same numeric value), the router may become 315 confused as to the content of the cache. The time it takes the 316 router to discover that it is confused will depend on whether the 317 Serial Numbers are also reused. If the Serial Numbers in the old 318 and new sessions are different enough, the cache will respond to 319 the router's Serial Query with a Cache Reset, which will solve the 320 problem. If, however, the Serial Numbers are close, the cache may 321 respond with a Cache Response, which may not be enough to bring 322 the router into sync. In such cases, it's likely but not certain 323 that the router will detect some discrepancy between the state 324 that the cache expects and its own state. For example, the Cache 325 Response may tell the router to drop a record which the router 326 does not hold or may tell the router to add a record which the 327 router already has. In such cases, a router will detect the error 328 and reset the session. The one case in which the router may stay 329 out of sync is when nothing in the Cache Response contradicts any 330 data currently held by the router. 332 Using persistent storage for the Session ID or a clock-based 333 scheme for generating Session IDs should avoid the risk of Session 334 ID collisions. 336 The Session ID might be a pseudorandom value, a strictly 337 increasing value if the cache has reliable storage, et cetera. A 338 seconds-since-epoch timestamp value such as the POSIX time() 339 function makes a good Session ID value. 341 Length: A 32-bit unsigned integer which has as its value the count 342 of the bytes in the entire PDU, including the 8 bytes of header 343 which includes the length field. 345 Flags: The lowest-order bit of the Flags field is 1 for an 346 announcement and 0 for a withdrawal. For a Prefix PDU (IPv4 or 347 IPv6), the flag indicates whether this PDU announces a new right 348 to announce the prefix or withdraws a previously announced right; 349 a withdraw effectively deletes one previously announced Prefix PDU 350 with the exact same Prefix, Length, Max-Len, and Autonomous System 351 Number (ASN). Similarly, for a Router Key PDU, the flag indicates 352 whether this PDU announces a new Router Key or deletes one 353 previously announced Router Key PDU with the exact same AS Number, 354 subjectKeyIdentifier, and subjectPublicKeyInfo. 356 The remaining bits in the Flags field are reserved for future use. 357 In protocol version 1, they MUST be zero on transmission and MUST 358 be ignored on receipt. 360 Prefix Length: An 8-bit unsigned integer denoting the shortest 361 prefix allowed by the Prefix element. 363 Max Length: An 8-bit unsigned integer denoting the longest prefix 364 allowed by the Prefix element. This MUST NOT be less than the 365 Prefix Length element. 367 Prefix: The IPv4 or IPv6 prefix of the ROA. 369 Autonomous System Number: A 32-bit unsigned integer representing an 370 ASN allowed to announce a prefix or associated with a router key. 372 Subject Key Identifier: 20-octet Subject Key Identifier (SKI) value 373 of a router key, as described in [RFC6487]. 375 Subject Public Key Info: A router key's subjectPublicKeyInfo value, 376 as described in [RFC8208]. This is the full ASN.1 DER encoding of 377 the subjectPublicKeyInfo, including the ASN.1 tag and length 378 values of the subjectPublicKeyInfo SEQUENCE. 380 Refresh Interval: Interval between normal cache polls. See 381 Section 6. 383 Retry Interval: Interval between cache poll retries after a failed 384 cache poll. See Section 6. 386 Expire Interval: Interval during which data fetched from a cache 387 remains valid in the absence of a successful subsequent cache 388 poll. See Section 6. 390 5.2. Serial Notify 392 The cache notifies the router that the cache has new data. 394 The Session ID reassures the router that the Serial Numbers are 395 commensurate, i.e., the cache session has not been changed. 397 Upon receipt of a Serial Notify PDU, the router MAY issue an 398 immediate Serial Query (Section 5.3) or Reset Query (Section 5.4) 399 without waiting for the Refresh Interval timer (see Section 6) to 400 expire. 402 Serial Notify is the only message that the cache can send that is not 403 in response to a message from the router. 405 If the router receives a Serial Notify PDU during the initial startup 406 period where the router and cache are still negotiating to agree on a 407 protocol version, the router MUST simply ignore the Serial Notify 408 PDU, even if the Serial Notify PDU is for an unexpected protocol 409 version. See Section 7 for details. 411 0 8 16 24 31 412 .-------------------------------------------. 413 | Protocol | PDU | | 414 | Version | Type | Session ID | 415 | 2 | 0 | | 416 +-------------------------------------------+ 417 | | 418 | Length=12 | 419 | | 420 +-------------------------------------------+ 421 | | 422 | Serial Number | 423 | | 424 `-------------------------------------------' 426 5.3. Serial Query 428 The router sends a Serial Query to ask the cache for all 429 announcements and withdrawals which have occurred since the Serial 430 Number specified in the Serial Query. 432 The cache replies to this query with a Cache Response PDU 433 (Section 5.5) if the cache has a (possibly null) record of the 434 changes since the Serial Number specified by the router, followed by 435 zero or more payload PDUs and an End Of Data PDU (Section 5.8). 437 When replying to a Serial Query, the cache MUST return the minimum 438 set of changes needed to bring the router into sync with the cache. 439 That is, if a particular prefix or router key underwent multiple 440 changes between the Serial Number specified by the router and the 441 cache's current Serial Number, the cache MUST merge those changes to 442 present the simplest possible view of those changes to the router. 443 In general, this means that, for any particular prefix or router key, 444 the data stream will include at most one withdrawal followed by at 445 most one announcement, and if all of the changes cancel out, the data 446 stream will not mention the prefix or router key at all. 448 The rationale for this approach is that the entire purpose of the 449 RPKI-Router protocol is to offload work from the router to the cache, 450 and it should therefor be the cache's job to simplify the change set, 451 thus reducing work for the router. 453 If the cache does not have the data needed to update the router, 454 perhaps because its records do not go back to the Serial Number in 455 the Serial Query, then it responds with a Cache Reset PDU 456 (Section 5.9). 458 The Session ID tells the cache what instance the router expects to 459 ensure that the Serial Numbers are commensurate, i.e., the cache 460 session has not been changed. 462 0 8 16 24 31 463 .-------------------------------------------. 464 | Protocol | PDU | | 465 | Version | Type | Session ID | 466 | 2 | 1 | | 467 +-------------------------------------------+ 468 | | 469 | Length=12 | 470 | | 471 +-------------------------------------------+ 472 | | 473 | Serial Number | 474 | | 475 `-------------------------------------------' 477 5.4. Reset Query 479 The router tells the cache that it wants to receive the total active, 480 current, non-withdrawn database. The cache responds with a Cache 481 Response PDU (Section 5.5), followed by zero or more payload PDUs and 482 an End of Data PDU (Section 5.8). 484 0 8 16 24 31 485 .-------------------------------------------. 486 | Protocol | PDU | | 487 | Version | Type | zero | 488 | 2 | 2 | | 489 +-------------------------------------------+ 490 | | 491 | Length=8 | 492 | | 493 `-------------------------------------------' 495 5.5. Cache Response 497 The cache responds to queries with zero or more payload PDUs. When 498 replying to a Serial Query (Section 5.3), the cache sends the set of 499 announcements and withdrawals that have occurred since the Serial 500 Number sent by the client router. When replying to a Reset Query 501 (Section 5.4), the cache sends the set of all data records it has; in 502 this case, the withdraw/announce field in the payload PDUs MUST have 503 the value 1 (announce). 505 In response to a Reset Query, the new value of the Session ID tells 506 the router the instance of the cache session for future confirmation. 507 In response to a Serial Query, the Session ID being the same 508 reassures the router that the Serial Numbers are commensurate, i.e., 509 the cache session has not been changed. 511 0 8 16 24 31 512 .-------------------------------------------. 513 | Protocol | PDU | | 514 | Version | Type | Session ID | 515 | 2 | 3 | | 516 +-------------------------------------------+ 517 | | 518 | Length=8 | 519 | | 520 `-------------------------------------------' 522 5.6. IPv4 Prefix 523 0 8 16 24 31 524 .-------------------------------------------. 525 | Protocol | PDU | | 526 | Version | Type | zero | 527 | 2 | 4 | | 528 +-------------------------------------------+ 529 | | 530 | Length=20 | 531 | | 532 +-------------------------------------------+ 533 | | Prefix | Max | | 534 | Flags | Length | Length | zero | 535 | | 0..32 | 0..32 | | 536 +-------------------------------------------+ 537 | | 538 | IPv4 Prefix | 539 | | 540 +-------------------------------------------+ 541 | | 542 | Autonomous System Number | 543 | | 544 `-------------------------------------------' 546 The lowest-order bit of the Flags field is 1 for an announcement and 547 0 for a withdrawal. 549 In the RPKI, nothing prevents a signing certificate from issuing two 550 identical ROAs. In this case, there would be no semantic difference 551 between the objects, merely a process redundancy. 553 In the RPKI, there is also an actual need for what might appear to a 554 router as identical IPvX PDUs. This can occur when an upstream 555 certificate is being reissued or there is an address ownership 556 transfer up the validation chain. The ROA would be identical in the 557 router sense, i.e., have the same {Prefix, Len, Max-Len, ASN}, but it 558 would have a different validation path in the RPKI. This is 559 important to the RPKI but not to the router. 561 The cache server MUST ensure that it has told the router client to 562 have one and only one IPvX PDU for a unique {Prefix, Len, Max-Len, 563 ASN} at any one point in time. Should the router client receive an 564 IPvX PDU with a {Prefix, Len, Max-Len, ASN} identical to one it 565 already has active, it SHOULD raise a Duplicate Announcement Received 566 error. 568 5.7. IPv6 Prefix 569 0 8 16 24 31 570 .-------------------------------------------. 571 | Protocol | PDU | | 572 | Version | Type | zero | 573 | 2 | 6 | | 574 +-------------------------------------------+ 575 | | 576 | Length=32 | 577 | | 578 +-------------------------------------------+ 579 | | Prefix | Max | | 580 | Flags | Length | Length | zero | 581 | | 0..128 | 0..128 | | 582 +-------------------------------------------+ 583 | | 584 +--- ---+ 585 | | 586 +--- IPv6 Prefix ---+ 587 | | 588 +--- ---+ 589 | | 590 +-------------------------------------------+ 591 | | 592 | Autonomous System Number | 593 | | 594 `-------------------------------------------' 596 Analogous to the IPv4 Prefix PDU, it has 96 more bits and no magic. 598 5.8. End of Data 600 The cache tells the router it has no more data for the request. 602 The Session ID and Protocol Version MUST be the same as that of the 603 corresponding Cache Response which began the (possibly null) sequence 604 of payload PDUs. 606 0 8 16 24 31 607 .-------------------------------------------. 608 | Protocol | PDU | | 609 | Version | Type | Session ID | 610 | 2 | 7 | | 611 +-------------------------------------------+ 612 | | 613 | Length=24 | 614 | | 615 +-------------------------------------------+ 616 | | 617 | Serial Number | 618 | | 619 +-------------------------------------------+ 620 | | 621 | Refresh Interval | 622 | | 623 +-------------------------------------------+ 624 | | 625 | Retry Interval | 626 | | 627 +-------------------------------------------+ 628 | | 629 | Expire Interval | 630 | | 631 `-------------------------------------------' 633 The Refresh Interval, Retry Interval, and Expire Interval are all 634 32-bit elapsed times measured in seconds. They express the timing 635 parameters which the cache expects the router to use in deciding when 636 to send subsequent Serial Query or Reset Query PDUs to the cache. 637 See Section 6 for an explanation of the use and the range of allowed 638 values for these parameters. 640 Note that the End of Data PDU changed significantly between versions 641 0 and 1. For version 0 compatibility, the following is the version 0 642 End of Data PDU. 644 0 8 16 24 31 645 .-------------------------------------------. 646 | Protocol | PDU | | 647 | Version | Type | Cache Nonce | 648 | 0 | 7 | | 649 +-------------------------------------------+ 650 | | 651 | Length=12 | 652 | | 653 +-------------------------------------------+ 654 | | 655 | Serial Number | 656 | | 657 `-------------------------------------------' 659 5.9. Cache Reset 661 The cache may respond to a Serial Query informing the router that the 662 cache cannot provide an incremental update starting from the Serial 663 Number specified by the router. The router must decide whether to 664 issue a Reset Query or switch to a different cache. 666 0 8 16 24 31 667 .-------------------------------------------. 668 | Protocol | PDU | | 669 | Version | Type | zero | 670 | 2 | 8 | | 671 +-------------------------------------------+ 672 | | 673 | Length=8 | 674 | | 675 `-------------------------------------------' 677 5.10. Router Key 678 0 8 16 24 31 679 .-------------------------------------------. 680 | Protocol | PDU | | | 681 | Version | Type | Flags | zero | 682 | 2 | 9 | | | 683 +-------------------------------------------+ 684 | | 685 | Length | 686 | | 687 +-------------------------------------------+ 688 | | 689 +--- ---+ 690 | Subject Key Identifier | 691 +--- ---+ 692 | | 693 +--- ---+ 694 | (20 octets) | 695 +--- ---+ 696 | | 697 +-------------------------------------------+ 698 | | 699 | AS Number | 700 | | 701 +-------------------------------------------+ 702 | | 703 | Subject Public Key Info | 704 | | 705 `-------------------------------------------' 707 The lowest-order bit of the Flags field is 1 for an announcement and 708 0 for a withdrawal. 710 The cache server MUST ensure that it has told the router client to 711 have one and only one Router Key PDU for a unique {SKI, ASN, Subject 712 Public Key} at any one point in time. Should the router client 713 receive a Router Key PDU with a {SKI, ASN, Subject Public Key} 714 identical to one it already has active, it SHOULD raise a Duplicate 715 Announcement Received error. 717 Note that a particular ASN may appear in multiple Router Key PDUs 718 with different Subject Public Key values, while a particular Subject 719 Public Key value may appear in multiple Router Key PDUs with 720 different ASNs. In the interest of keeping the announcement and 721 withdrawal semantics as simple as possible for the router, this 722 protocol makes no attempt to compress either of these cases. 724 Also note that it is possible, albeit very unlikely, for multiple 725 distinct Subject Public Key values to hash to the same SKI. For this 726 reason, implementations MUST compare Subject Public Key values as 727 well as SKIs when detecting duplicate PDUs. 729 5.11. Error Report 731 This PDU is used by either party to report an error to the other. 733 Error reports are only sent as responses to other PDUs, not to report 734 errors in Error Report PDUs. 736 Error codes are described in Section 13. 738 If the error is generic (e.g., "Internal Error") and not associated 739 with the PDU to which it is responding, the Erroneous PDU field MUST 740 be empty and the Length of Encapsulated PDU field MUST be zero. 742 An Error Report PDU MUST NOT be sent for an Error Report PDU. If an 743 erroneous Error Report PDU is received, the session SHOULD be 744 dropped. 746 If the error is associated with a PDU of excessive length, i.e., too 747 long to be any legal PDU other than another Error Report, or a 748 possibly corrupt length, the Erroneous PDU field MAY be truncated. 750 The diagnostic text is optional; if not present, the Length of Error 751 Text field MUST be zero. If error text is present, it MUST be a 752 string in UTF-8 encoding (see [RFC3629]). 754 0 8 16 24 31 755 .-------------------------------------------. 756 | Protocol | PDU | | 757 | Version | Type | Error Code | 758 | 2 | 10 | | 759 +-------------------------------------------+ 760 | | 761 | Length | 762 | | 763 +-------------------------------------------+ 764 | | 765 | Length of Encapsulated PDU | 766 | | 767 +-------------------------------------------+ 768 | | 769 ~ Erroneous PDU ~ 770 | | 771 +-------------------------------------------+ 772 | | 773 | Length of Error Text | 774 | | 775 +-------------------------------------------+ 776 | | 777 | Arbitrary Text | 778 | of | 779 ~ Error Diagnostic Message ~ 780 | | 781 `-------------------------------------------' 783 5.12. ASPA PDU 784 0 8 16 24 31 785 .-------------------------------------------. 786 | Protocol | PDU | | 787 | Version | Type | zero | 788 | 2 | 11 | | 789 +-------------------------------------------+ 790 | | 791 | Length | 792 | | 793 +-------------------------------------------+ 794 | | | | 795 | Flags | zero | Provider AS Count | 796 | | | | 797 +-------------------------------------------+ 798 | | 799 | Customer Autonomous System Number | 800 | | 801 +-------------------------------------------+ 802 | | 803 | Provider Autonomous System Numbers | 804 | | 805 ~-------------------------------------------~ 807 The ASPA PDU is to support [I-D.ietf-sidrops-aspa-profile]. An ASPA 808 PDU represents one single customer AS and one or more provider ASs 809 for a particular Address Family. Receipt of an ASPA PDU announcement 810 when the router already has an ASPA PDU with the same Customer 811 Autonomous System Number and the same Address Family (see Flags 812 field), replaces the previous one. This is to avoid a race condition 813 when a BGP announcement is received between an withdrawn PDU and a 814 new announced PDU. Therefor, the cache MUST deliver entire data of 815 an ASPA record in a single ASPA PDU. 817 The router should only see one ASPA for a particular Customer 818 Autonomous System Number active at any time. This may place a burden 819 on the cache to merge multiple ASPA records it has received from the 820 global RPKI into one ASPA PDU. 822 The Flags field is defined as follows: 824 Bit Bit Name 825 ---- ------------------- 826 0 Announce/Withdraw (ann == 1, with == 0) 827 1 AFI (IPv4 == 0, IPv6 == 1) 828 2-7 Reserved, must be zero 830 The Provider AS Count is the number of Provider Autonomous System 831 Number(s) at the end of the PDU, and MUST be one or more. 833 The Customer Autonomous System Number is the 32-bit Autonomous System 834 Number of the customer which signed the PDU. There MUST be one and 835 only one ASPA for a Customer Autonomous System Number active in the 836 router at any time. 838 The Provider AS Count is the number of 32-bit Provider Autonomous 839 System Numbers in the PDU. It MUST be one or greater. 841 There are one or more 32-bit Provider Autonomous System Number 842 fields; see [I-D.ietf-sidrops-aspa-profile]. 844 6. Protocol Timing Parameters 846 Since the data the cache distributes via the RPKI-Router protocol are 847 retrieved from the Global RPKI system at intervals which are only 848 known to the cache, only the cache can really know how frequently it 849 makes sense for the router to poll the cache, or how long the data 850 are likely to remain valid (or, at least, unchanged). For this 851 reason, as well as to allow the cache some control over the load 852 placed on it by its client routers, the End Of Data PDU includes 853 three values that allow the cache to communicate timing parameters to 854 the router: 856 Refresh Interval: This parameter tells the router how long to wait 857 before next attempting to poll the cache and between subsequent 858 attempts, using a Serial Query or Reset Query PDU. The router 859 SHOULD NOT poll the cache sooner than indicated by this parameter. 860 Note that receipt of a Serial Notify PDU overrides this interval 861 and suggests that the router issue an immediate query without 862 waiting for the Refresh Interval to expire. Countdown for this 863 timer starts upon receipt of the containing End Of Data PDU. 865 Minimum allowed value: 1 second. 867 Maximum allowed value: 86400 seconds (1 day). 869 Recommended default: 3600 seconds (1 hour). 871 Retry Interval: This parameter tells the router how long to wait 872 before retrying a failed Serial Query or Reset Query. The router 873 SHOULD NOT retry sooner than indicated by this parameter. Note 874 that a protocol version mismatch overrides this interval: if the 875 router needs to downgrade to a lower protocol version number, it 876 MAY send the first Serial Query or Reset Query immediately. 877 Countdown for this timer starts upon failure of the query and 878 restarts after each subsequent failure until a query succeeds. 880 Minimum allowed value: 1 second. 882 Maximum allowed value: 7200 seconds (2 hours). 884 Recommended default: 600 seconds (10 minutes). 886 Expire Interval: This parameter tells the router how long it can 887 continue to use the current version of the data while unable to 888 perform a successful subsequent query. The router MUST NOT retain 889 the data past the time indicated by this parameter. Countdown for 890 this timer starts upon receipt of the containing End Of Data PDU. 892 Minimum allowed value: 600 seconds (10 minutes). 894 Maximum allowed value: 172800 seconds (2 days). 896 Recommended default: 3600 seconds (1 hour). 898 If the router has never issued a successful query against a 899 particular cache, it SHOULD retry periodically using the default 900 Retry Interval, above. 902 Caches MUST set Expire Interval to a value larger than either Refresh 903 Interval or Retry Interval. 905 7. Protocol Version Negotiation 907 A router MUST start each transport connection by issuing either a 908 Reset Query or a Serial Query. This query will tell the cache which 909 version of this protocol the router implements. 911 If a cache which supports version N receives a query from a router 912 which specifies version Q < N, the cache MUST downgrade to protocol 913 version Q [RFC6810] or [RFC8210] or send a version 1 Error Report PDU 914 with Error Code 4 ("Unsupported Protocol Version") and terminate the 915 connection. 917 If a router which supports version N sends a query to a cache which 918 only supports version C < N, one of two things will happen: 920 1. The cache may terminate the connection, perhaps with a version 0 921 Error Report PDU. In this case, the router MAY retry the 922 connection using protocol version C. 924 2. The cache may reply with a version C response. In this case, the 925 router MUST either downgrade to version C or terminate the 926 connection. 928 In any of the downgraded combinations above, the new features of the 929 hogher version will not be available, and all PDUs will have the 930 negotiated lower version number in their version fields. 932 If either party receives a PDU containing an unrecognized Protocol 933 Version (neither 0, 1, nor 2) during this negotiation, it MUST either 934 downgrade to a known version or terminate the connection, with an 935 Error Report PDU unless the received PDU is itself an Error Report 936 PDU. 938 The router MUST ignore any Serial Notify PDUs it might receive from 939 the cache during this initial startup period, regardless of the 940 Protocol Version field in the Serial Notify PDU. Since Session ID 941 and Serial Number values are specific to a particular protocol 942 version, the values in the notification are not useful to the router. 943 Even if these values were meaningful, the only effect that processing 944 the notification would have would be to trigger exactly the same 945 Reset Query or Serial Query that the router has already sent as part 946 of the not-yet-complete version negotiation process, so there is 947 nothing to be gained by processing notifications until version 948 negotiation completes. 950 Caches SHOULD NOT send Serial Notify PDUs before version negotiation 951 completes. Routers, however, MUST handle such notifications (by 952 ignoring them) for backwards compatibility with caches serving 953 protocol version 0. 955 Once the cache and router have agreed upon a Protocol Version via the 956 negotiation process above, that version is stable for the life of the 957 session. See Section 5.1 for a discussion of the interaction between 958 Protocol Version and Session ID. 960 If either party receives a PDU for a different Protocol Version once 961 the above negotiation completes, that party MUST drop the session; 962 unless the PDU containing the unexpected Protocol Version was itself 963 an Error Report PDU, the party dropping the session SHOULD send an 964 Error Report with an error code of 8 ("Unexpected Protocol Version"). 966 8. Protocol Sequences 968 The sequences of PDU transmissions fall into four conversations as 969 follows: 971 8.1. Start or Restart 972 Cache Router 973 ~ ~ 974 | <----- Reset Query -------- | R requests data (or Serial Query) 975 | | 976 | ----- Cache Response -----> | C confirms request 977 | ------- Payload PDU ------> | C sends zero or more 978 | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, 979 | ------- Payload PDU ------> | or Router Key PDUs 980 | ------- End of Data ------> | C sends End of Data 981 | | and sends new serial 982 ~ ~ 984 When a transport connection is first established, the router MUST 985 send either a Reset Query or a Serial Query. A Serial Query would be 986 appropriate if the router has significant unexpired data from a 987 broken session with the same cache and remembers the Session ID of 988 that session, in which case a Serial Query containing the Session ID 989 from the previous session will allow the router to bring itself up to 990 date while ensuring that the Serial Numbers are commensurate and that 991 the router and cache are speaking compatible versions of the 992 protocol. In all other cases, the router lacks the necessary data 993 for fast resynchronization and therefore MUST fall back to a Reset 994 Query. 996 The Reset Query sequence is also used when the router receives a 997 Cache Reset, chooses a new cache, or fears that it has otherwise lost 998 its way. 1000 See Section 7 for details on version negotiation. 1002 To limit the length of time a cache must keep the data necessary to 1003 generate incremental updates, a router MUST send either a Serial 1004 Query or a Reset Query periodically. This also acts as a keep-alive 1005 at the application layer. See Section 6 for details on the required 1006 polling frequency. 1008 8.2. Typical Exchange 1009 Cache Router 1010 ~ ~ 1011 | -------- Notify ----------> | (optional) 1012 | | 1013 | <----- Serial Query ------- | R requests data 1014 | | 1015 | ----- Cache Response -----> | C confirms request 1016 | ------- Payload PDU ------> | C sends zero or more 1017 | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, 1018 | ------- Payload PDU ------> | or Router Key PDUs 1019 | ------- End of Data ------> | C sends End of Data 1020 | | and sends new serial 1021 ~ ~ 1023 The cache server SHOULD send a Notify PDU with its current Serial 1024 Number when the cache's serial changes, with the expectation that the 1025 router MAY then issue a Serial Query earlier than it otherwise might. 1026 This is analogous to DNS NOTIFY in [RFC1996]. The cache MUST 1027 rate-limit Serial Notifies to no more frequently than one per minute. 1029 When the transport layer is up and either a timer has gone off in the 1030 router or the cache has sent a Notify PDU, the router queries for new 1031 data by sending a Serial Query, and the cache sends all data newer 1032 than the serial in the Serial Query. 1034 To limit the length of time a cache must keep old withdraws, a router 1035 MUST send either a Serial Query or a Reset Query periodically. See 1036 Section 6 for details on the required polling frequency. 1038 8.3. No Incremental Update Available 1040 Cache Router 1041 ~ ~ 1042 | <------ Serial Query ------ | R requests data 1043 | ------- Cache Reset ------> | C cannot supply update 1044 | | from specified serial 1045 | <------ Reset Query ------- | R requests new data 1046 | ----- Cache Response -----> | C confirms request 1047 | ------- Payload PDU ------> | C sends zero or more 1048 | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, 1049 | ------- Payload PDU ------> | or Router Key PDUs 1050 | ------- End of Data ------> | C sends End of Data 1051 | | and sends new serial 1052 ~ ~ 1054 The cache may respond to a Serial Query with a Cache Reset, informing 1055 the router that the cache cannot supply an incremental update from 1056 the Serial Number specified by the router. This might be because the 1057 cache has lost state, or because the router has waited too long 1058 between polls and the cache has cleaned up old data that it no longer 1059 believes it needs, or because the cache has run out of storage space 1060 and had to expire some old data early. Regardless of how this state 1061 arose, the cache replies with a Cache Reset to tell the router that 1062 it cannot honor the request. When a router receives this, the router 1063 SHOULD attempt to connect to any more-preferred caches in its cache 1064 list. If there are no more-preferred caches, it MUST issue a Reset 1065 Query and get an entire new load from the cache. 1067 8.4. Cache Has No Data Available 1069 Cache Router 1070 ~ ~ 1071 | <------ Serial Query ------ | R requests data 1072 | ---- Error Report PDU ----> | C No Data Available 1073 ~ ~ 1075 Cache Router 1076 ~ ~ 1077 | <------ Reset Query ------- | R requests data 1078 | ---- Error Report PDU ----> | C No Data Available 1079 ~ ~ 1081 The cache may respond to either a Serial Query or a Reset Query 1082 informing the router that the cache cannot supply any update at all. 1083 The most likely cause is that the cache has lost state, perhaps due 1084 to a restart, and has not yet recovered. While it is possible that a 1085 cache might go into such a state without dropping any of its active 1086 sessions, a router is more likely to see this behavior when it 1087 initially connects and issues a Reset Query while the cache is still 1088 rebuilding its database. 1090 When a router receives this kind of error, the router SHOULD attempt 1091 to connect to any other caches in its cache list, in preference 1092 order. If no other caches are available, the router MUST issue 1093 periodic Reset Queries until it gets a new usable load from the 1094 cache. 1096 9. Transport 1098 The transport-layer session between a router and a cache carries the 1099 binary PDUs in a persistent session. 1101 To prevent cache spoofing and DoS attacks by illegitimate routers, it 1102 is highly desirable that the router and the cache be authenticated to 1103 each other. Integrity protection for payloads is also desirable to 1104 protect against monkey-in-the-middle (MITM) attacks. Unfortunately, 1105 there is no protocol to do so on all currently used platforms. 1106 Therefore, as of the writing of this document, there is no mandatory- 1107 to-implement transport which provides authentication and integrity 1108 protection. 1110 To reduce exposure to dropped but non-terminated sessions, both 1111 caches and routers SHOULD enable keep-alives when available in the 1112 chosen transport protocol. 1114 It is expected that, when the TCP Authentication Option (TCP-AO) 1115 [RFC5925] is available on all platforms deployed by operators, it 1116 will become the mandatory-to-implement transport. 1118 Caches and routers MUST implement unprotected transport over TCP 1119 using a port, rpki-rtr (323); see Section 15. Operators SHOULD use 1120 procedural means, e.g., access control lists (ACLs), to reduce the 1121 exposure to authentication issues. 1123 If unprotected TCP is the transport, the cache and routers MUST be on 1124 the same trusted and controlled network. 1126 If available to the operator, caches and routers MUST use one of the 1127 following more protected protocols: 1129 * Caches and routers SHOULD use TCP-AO transport [RFC5925] over the 1130 rpki-rtr port. 1132 * Caches and routers MAY use Secure Shell version 2 (SSHv2) 1133 transport [RFC4252] using the normal SSH port. For an example, 1134 see Section 9.1. 1136 * Caches and routers MAY use TCP MD5 transport [RFC2385] using the 1137 rpki-rtr port. Note that TCP MD5 has been obsoleted by TCP-AO 1138 [RFC5925]. 1140 * Caches and routers MAY use TCP over IPsec transport [RFC4301] 1141 using the rpki-rtr port. 1143 * Caches and routers MAY use Transport Layer Security (TLS) 1144 transport [RFC5246] using port rpki-rtr-tls (324); see Section 15. 1146 9.1. SSH Transport 1148 To run over SSH, the client router first establishes an SSH transport 1149 connection using the SSHv2 transport protocol, and the client and 1150 server exchange keys for message integrity and encryption. The 1151 client then invokes the "ssh-userauth" service to authenticate the 1152 application, as described in the SSH authentication protocol 1153 [RFC4252]. Once the application has been successfully authenticated, 1154 the client invokes the "ssh-connection" service, also known as the 1155 SSH connection protocol. 1157 After the ssh-connection service is established, the client opens a 1158 channel of type "session", which results in an SSH session. 1160 Once the SSH session has been established, the application invokes 1161 the application transport as an SSH subsystem called "rpki-rtr". 1162 Subsystem support is a feature of SSHv2 and is not included in SSHv1. 1163 Running this protocol as an SSH subsystem avoids the need for the 1164 application to recognize shell prompts or skip over extraneous 1165 information, such as a system message that is sent at shell startup. 1167 It is assumed that the router and cache have exchanged keys out of 1168 band by some reasonably secured means. 1170 Cache servers supporting SSH transport MUST accept RSA authentication 1171 and SHOULD accept Elliptic Curve Digital Signature Algorithm (ECDSA) 1172 authentication. User authentication MUST be supported; host 1173 authentication MAY be supported. Implementations MAY support 1174 password authentication. Client routers SHOULD verify the public key 1175 of the cache to avoid MITM attacks. 1177 9.2. TLS Transport 1179 Client routers using TLS transport MUST present client-side 1180 certificates to authenticate themselves to the cache in order to 1181 allow the cache to manage the load by rejecting connections from 1182 unauthorized routers. In principle, any type of certificate and 1183 Certification Authority (CA) may be used; however, in general, cache 1184 operators will wish to create their own small-scale CA and issue 1185 certificates to each authorized router. This simplifies credential 1186 rollover; any unrevoked, unexpired certificate from the proper CA may 1187 be used. 1189 Certificates used to authenticate client routers in this protocol 1190 MUST include a subjectAltName extension [RFC5280] containing one or 1191 more iPAddress identities; when authenticating the router's 1192 certificate, the cache MUST check the IP address of the TLS 1193 connection against these iPAddress identities and SHOULD reject the 1194 connection if none of the iPAddress identities match the connection. 1196 Routers MUST also verify the cache's TLS server certificate, using 1197 subjectAltName dNSName identities as described in [RFC6125], to avoid 1198 MITM attacks. The rules and guidelines defined in [RFC6125] apply 1199 here, with the following considerations: 1201 * Support for the DNS-ID identifier type (that is, the dNSName 1202 identity in the subjectAltName extension) is REQUIRED in rpki-rtr 1203 server and client implementations which use TLS. Certification 1204 authorities which issue rpki-rtr server certificates MUST support 1205 the DNS-ID identifier type, and the DNS-ID identifier type MUST be 1206 present in rpki-rtr server certificates. 1208 * DNS names in rpki-rtr server certificates SHOULD NOT contain the 1209 wildcard character "*". 1211 * rpki-rtr implementations which use TLS MUST NOT use Common Name 1212 (CN-ID) identifiers; a CN field may be present in the server 1213 certificate's subject name but MUST NOT be used for authentication 1214 within the rules described in [RFC6125]. 1216 * The client router MUST set its "reference identifier" to the DNS 1217 name of the rpki-rtr cache. 1219 9.3. TCP MD5 Transport 1221 If TCP MD5 is used, implementations MUST support key lengths of at 1222 least 80 printable ASCII bytes, per Section 4.5 of [RFC2385]. 1223 Implementations MUST also support hexadecimal sequences of at least 1224 32 characters, i.e., 128 bits. 1226 Key rollover with TCP MD5 is problematic. Cache servers SHOULD 1227 support [RFC4808]. 1229 9.4. TCP-AO Transport 1231 Implementations MUST support key lengths of at least 80 printable 1232 ASCII bytes. Implementations MUST also support hexadecimal sequences 1233 of at least 32 characters, i.e., 128 bits. Message Authentication 1234 Code (MAC) lengths of at least 96 bits MUST be supported, per 1235 Section 5.1 of [RFC5925]. 1237 The cryptographic algorithms and associated parameters described in 1238 [RFC5926] MUST be supported. 1240 10. Router-Cache Setup 1242 A cache has the public authentication data for each router it is 1243 configured to support. 1245 A router may be configured to peer with a selection of caches, and a 1246 cache may be configured to support a selection of routers. Each must 1247 have the name of, and authentication data for, each peer. In 1248 addition, in a router, this list has a non-unique preference value 1249 for each server. This preference merely denotes proximity, not 1250 trust, preferred belief, et cetera. The client router attempts to 1251 establish a session with each potential serving cache in preference 1252 order and then starts to load data from the most preferred cache to 1253 which it can connect and authenticate. The router's list of caches 1254 has the following elements: 1256 Preference: An unsigned integer denoting the router's preference to 1257 connect to that cache; the lower the value, the more preferred. 1259 Name: The IP address or fully qualified domain name of the cache. 1261 Cache Credential(s): Any credential (such as a public key) needed to 1262 authenticate the cache's identity to the router. 1264 Router Credential(s): Any credential (such as a private key or 1265 certificate) needed to authenticate the router's identity to the 1266 cache. 1268 Due to the distributed nature of the RPKI, caches simply cannot be 1269 rigorously synchronous. A client may hold data from multiple caches 1270 but MUST keep the data marked as to source, as later updates MUST 1271 affect the correct data. 1273 Just as there may be more than one covering ROA from a single cache, 1274 there may be multiple covering ROAs from multiple caches. The 1275 results are as described in [RFC6811]. 1277 If data from multiple caches are held, implementations MUST NOT 1278 distinguish between data sources when performing validation of BGP 1279 announcements. 1281 When a more-preferred cache becomes available, if resources allow, it 1282 would be prudent for the client to start fetching from that cache. 1284 The client SHOULD attempt to maintain at least one set of data, 1285 regardless of whether it has chosen a different cache or established 1286 a new connection to the previous cache. 1288 A client MAY drop the data from a particular cache when it is fully 1289 in sync with one or more other caches. 1291 See Section 6 for details on what to do when the client is not able 1292 to refresh from a particular cache. 1294 If a client loses connectivity to a cache it is using or otherwise 1295 decides to switch to a new cache, it SHOULD retain the data from the 1296 previous cache until it has a full set of data from one or more other 1297 caches. Note that this may already be true at the point of 1298 connection loss if the client has connections to more than one cache. 1300 11. ROA PDU Race Minimization 1302 When a cache is sending ROA PDUs to the router, especially during an 1303 initial full load, two undesirable race conditions are possible: 1305 Break Before Make: For some prefix P, an AS may announce two (or 1306 more) ROAs because they are in the process of changing what 1307 provider AS is announcing P. This is is a case of "make before 1308 break." If a cache is feeding a router and sends the one not yet 1309 in service a significant time before sending the one currently in 1310 service, then BGP data could be marked invalid during the 1311 interval. To minimize that interval, the cache SHOULD announce 1312 all ROAs for the same prefix as close to sequentially as possible. 1314 Shorter Prefix First: If an AS has issued a ROA for P0, and another 1315 AS (likely their customer) has issued a ROA for P1 which is a sub- 1316 prefix of P0, a router which receives the ROA for P0 before that 1317 for P1 is likely to mark a BGP prefix P1 invalid. Therefore, the 1318 cache SHOULD announce the sub-prefix P1 before the covering prefix 1319 P0. 1321 12. Deployment Scenarios 1323 For illustration, we present three likely deployment scenarios: 1325 Small End Site: The small multihomed end site may wish to outsource 1326 the RPKI cache to one or more of their upstream ISPs. They would 1327 exchange authentication material with the ISP using some out-of- 1328 band mechanism, and their router(s) would connect to the cache(s) 1329 of one or more upstream ISPs. The ISPs would likely deploy caches 1330 intended for customer use separately from the caches with which 1331 their own BGP speakers peer. 1333 Large End Site: A larger multihomed end site might run one or more 1334 caches, arranging them in a hierarchy of client caches, each 1335 fetching from a serving cache which is closer to the Global RPKI. 1336 They might configure fallback peerings to upstream ISP caches. 1338 ISP Backbone: A large ISP would likely have one or more redundant 1339 caches in each major point of presence (PoP), and these caches 1340 would fetch from each other in an ISP-dependent topology so as not 1341 to place undue load on the Global RPKI. 1343 Experience with large DNS cache deployments has shown that complex 1344 topologies are ill-advised, as it is easy to make errors in the 1345 graph, e.g., not maintain a loop-free condition. 1347 Of course, these are illustrations, and there are other possible 1348 deployment strategies. It is expected that minimizing load on the 1349 Global RPKI servers will be a major consideration. 1351 To keep load on Global RPKI services from unnecessary peaks, it is 1352 recommended that primary caches which load from the distributed 1353 Global RPKI not do so all at the same times, e.g., on the hour. 1354 Choose a random time, perhaps the ISP's AS number modulo 60, and 1355 jitter the inter-fetch timing. 1357 13. Error Codes 1359 This section contains a preliminary list of error codes. The authors 1360 expect additions to the list during development of the initial 1361 implementations. There is an IANA registry where valid error codes 1362 are listed; see Section 15. Errors which are considered fatal MUST 1363 cause the session to be dropped. 1365 0: Corrupt Data (fatal): The receiver believes the received PDU to 1366 be corrupt in a manner not specified by another error code. 1368 1: Internal Error (fatal): The party reporting the error experienced 1369 some kind of internal error unrelated to protocol operation (ran 1370 out of memory, a coding assertion failed, et cetera). 1372 2: No Data Available: The cache believes itself to be in good 1373 working order but is unable to answer either a Serial Query or a 1374 Reset Query because it has no useful data available at this time. 1375 This is likely to be a temporary error and most likely indicates 1376 that the cache has not yet completed pulling down an initial 1377 current data set from the Global RPKI system after some kind of 1378 event that invalidated whatever data it might have previously held 1379 (reboot, network partition, et cetera). 1381 3: Invalid Request (fatal): The cache server believes the client's 1382 request to be invalid. 1384 4: Unsupported Protocol Version (fatal): The Protocol Version is not 1385 known by the receiver of the PDU. 1387 5: Unsupported PDU Type (fatal): The PDU Type is not known by the 1388 receiver of the PDU. 1390 6: Withdrawal of Unknown Record (fatal): The received PDU has 1391 Flag=0, but a matching record ({Prefix, Len, Max-Len, ASN} tuple 1392 for an IPvX PDU or {SKI, ASN, Subject Public Key} tuple for a 1393 Router Key PDU) does not exist in the receiver's database. 1395 7: Duplicate Announcement Received (fatal): The received PDU has 1396 Flag=1, but a matching record ({Prefix, Len, Max-Len, ASN} tuple 1397 for an IPvX PDU or {SKI, ASN, Subject Public Key} tuple for a 1398 Router Key PDU) is already active in the router. 1400 8: Unexpected Protocol Version (fatal): The received PDU has a 1401 Protocol Version field that differs from the protocol version 1402 negotiated in Section 7. 1404 14. Security Considerations 1406 As this document describes a security protocol, many aspects of 1407 security interest are described in the relevant sections. This 1408 section points out issues which may not be obvious in other sections. 1410 Cache Validation: In order for a collection of caches as described 1411 in Section 12 to guarantee a consistent view, they need to be 1412 given consistent trust anchors to use in their internal validation 1413 process. Distribution of a consistent trust anchor is assumed to 1414 be out of band. 1416 Cache Peer Identification: The router initiates a transport 1417 connection to a cache, which it identifies by either IP address or 1418 fully qualified domain name. Be aware that a DNS or address 1419 spoofing attack could make the correct cache unreachable. No 1420 session would be established, as the authorization keys would not 1421 match. 1423 Transport Security: The RPKI relies on object, not server or 1424 transport, trust. That is, the IANA root trust anchor is 1425 distributed to all caches through some out-of-band means and can 1426 then be used by each cache to validate certificates and ROAs all 1427 the way down the tree. The inter-cache relationships are based on 1428 this object security model; hence, the inter-cache transport can 1429 be lightly protected. 1431 However, this protocol document assumes that the routers cannot do 1432 the validation cryptography. Hence, the last link, from cache to 1433 router, is secured by server authentication and transport-level 1434 security. This is dangerous, as server authentication and 1435 transport have very different threat models than object security. 1437 So the strength of the trust relationship and the transport 1438 between the router(s) and the cache(s) are critical. You're 1439 betting your routing on this. 1441 While we cannot say the cache must be on the same LAN, if only due 1442 to the issue of an enterprise wanting to offload the cache task to 1443 their upstream ISP(s), locality, trust, and control are very 1444 critical issues here. The cache(s) really SHOULD be as close, in 1445 the sense of controlled and protected (against DDoS, MITM) 1446 transport, to the router(s) as possible. It also SHOULD be 1447 topologically close so that a minimum of validated routing data 1448 are needed to bootstrap a router's access to a cache. 1450 The identity of the cache server SHOULD be verified and 1451 authenticated by the router client, and vice versa, before any 1452 data are exchanged. 1454 Transports which cannot provide the necessary authentication and 1455 integrity (see Section 9) must rely on network design and 1456 operational controls to provide protection against spoofing/ 1457 corruption attacks. As pointed out in Section 9, TCP-AO is the 1458 long-term plan. Protocols which provide integrity and 1459 authenticity SHOULD be used, and if they cannot, i.e., TCP is used 1460 as the transport, the router and cache MUST be on the same 1461 trusted, controlled network. 1463 15. IANA Considerations 1465 This section only discusses updates required in the existing IANA 1466 protocol registries to accommodate version 1 of this protocol. See 1467 [RFC8210] for IANA considerations from the original (version 0) 1468 protocol. 1470 All existing entries in the IANA "rpki-rtr-pdu" registry remain valid 1471 for protocol version 0. All of the PDU types allowed in protocol 1472 version 0 are also allowed in protocol version 1, with the addition 1473 of the new Router Key PDU. To reduce the likelihood of confusion, 1474 the PDU number used by the Router Key PDU in protocol version 1 is 1475 hereby registered as reserved (and unused) in protocol version 0. 1477 The policy for adding to the registry is RFC Required per [RFC8126]; 1478 the document must be either Standards Track or Experimental. 1480 The "rpki-rtr-pdu" registry has been updated as follows: 1482 Protocol PDU 1483 Version Type Description 1484 -------- ---- --------------- 1485 0-2 0 Serial Notify 1486 0-2 1 Serial Query 1487 0-2 2 Reset Query 1488 0-2 3 Cache Response 1489 0-2 4 IPv4 Prefix 1490 0-2 6 IPv6 Prefix 1491 0-2 7 End of Data 1492 0-2 8 Cache Reset 1493 0 9 Reserved 1494 1-2 9 Router Key 1495 0-2 10 Error Report 1496 0-1 11 Reserved 1497 2 11 ASPA 1498 0-2 255 Reserved 1500 All previous entries in the IANA "rpki-rtr-error" registry remain 1501 valid for all protocol versions. Protocol version 1 added one new 1502 error code: 1504 Error 1505 Code Description 1506 ----- --------------------------- 1507 8 Unexpected Protocol Version 1509 16. References 1511 16.1. Normative References 1513 [I-D.ietf-sidrops-aspa-profile] 1514 Azimov, A., Uskov, E., Bush, R., Patel, K., Snijders, J., 1515 and R. Housley, "A Profile for Autonomous System Provider 1516 Authorization", Work in Progress, Internet-Draft, draft- 1517 ietf-sidrops-aspa-profile-06, 30 July 2021, 1518 . 1521 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 1522 DOI 10.17487/RFC1982, August 1996, 1523 . 1525 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1526 Requirement Levels", BCP 14, RFC 2119, 1527 DOI 10.17487/RFC2119, March 1997, 1528 . 1530 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1531 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 1532 1998, . 1534 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1535 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1536 2003, . 1538 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 1539 Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, 1540 January 2006, . 1542 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1543 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1544 December 2005, . 1546 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1547 (TLS) Protocol Version 1.2", RFC 5246, 1548 DOI 10.17487/RFC5246, August 2008, 1549 . 1551 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1552 Housley, R., and W. Polk, "Internet X.509 Public Key 1553 Infrastructure Certificate and Certificate Revocation List 1554 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1555 . 1557 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1558 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1559 June 2010, . 1561 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 1562 for the TCP Authentication Option (TCP-AO)", RFC 5926, 1563 DOI 10.17487/RFC5926, June 2010, 1564 . 1566 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1567 Verification of Domain-Based Application Service Identity 1568 within Internet Public Key Infrastructure Using X.509 1569 (PKIX) Certificates in the Context of Transport Layer 1570 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1571 2011, . 1573 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 1574 X.509 PKIX Resource Certificates", RFC 6487, 1575 DOI 10.17487/RFC6487, February 2012, 1576 . 1578 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 1579 Infrastructure (RPKI) to Router Protocol", RFC 6810, 1580 DOI 10.17487/RFC6810, January 2013, 1581 . 1583 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 1584 Austein, "BGP Prefix Origin Validation", RFC 6811, 1585 DOI 10.17487/RFC6811, January 2013, 1586 . 1588 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1589 Writing an IANA Considerations Section in RFCs", BCP 26, 1590 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1591 . 1593 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1594 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1595 May 2017, . 1597 [RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key 1598 Formats, and Signature Formats", RFC 8208, 1599 DOI 10.17487/RFC8208, September 2017, 1600 . 1602 [RFC8210] Bush, R. and R. Austein, "The Resource Public Key 1603 Infrastructure (RPKI) to Router Protocol, Version 1", 1604 RFC 8210, DOI 10.17487/RFC8210, September 2017, 1605 . 1607 16.2. Informative References 1609 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 1610 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 1611 August 1996, . 1613 [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", 1614 RFC 4808, DOI 10.17487/RFC4808, March 2007, 1615 . 1617 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 1618 Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, 1619 . 1621 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 1622 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 1623 February 2012, . 1625 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 1626 Resource Certificate Repository Structure", RFC 6481, 1627 DOI 10.17487/RFC6481, February 2012, 1628 . 1630 Acknowledgements 1632 The authors wish to thank Nils Bars, Steve Bellovin, Oliver Borchert, 1633 Tim Bruijnzeels, Rex Fernando, Richard Hansen, Martin Hoffmann, Paul 1634 Hoffman, Fabian Holler, Russ Housley, Pradosh Mohapatra, Keyur Patel, 1635 David Mandelberg, Sandy Murphy, Robert Raszuk, Andreas Reuter, Thomas 1636 Schmidt, John Scudder, Ruediger Volk, Matthias Waehlisch, and David 1637 Ward. Particular thanks go to Hannes Gredler for showing us the 1638 dangers of unnecessary fields. 1640 No doubt this list is incomplete. We apologize to any contributor 1641 whose name we missed. 1643 Authors' Addresses 1645 Randy Bush 1646 IIJ, Arrcus, & DRL 1647 5147 Crystal Springs 1648 Bainbridge Island, Washington 98110 1649 United States of America 1651 Email: randy@psg.com 1653 Rob Austein 1654 Dragon Research Labs 1655 Email: sra@hactrn.net