idnits 2.17.1 draft-ietf-sidrops-8210bis-05.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC8210, but the abstract doesn't seem to directly say this. It does mention RFC8210 though, so this could be OK. -- The abstract seems to indicate that this document updates RFC8210, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (22 December 2021) is 853 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 (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Bush 3 Internet-Draft IIJ, Arrcus, & DRL 4 Obsoletes: 8210 (if approved) R. Austein 5 Intended status: Standards Track Dragon Research Labs 6 Expires: 25 June 2022 22 December 2021 8 The Resource Public Key Infrastructure (RPKI) to Router Protocol, 9 Version 2 10 draft-ietf-sidrops-8210bis-05 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 25 June 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 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 . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 23 79 8.1. Start or Restart . . . . . . . . . . . . . . . . . . . . 23 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 (ASs) 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 therefore be the cache's job to simplify the change 451 set, 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 its provider ASs for a 809 particular Address Family. Receipt of an ASPA PDU announcement 810 (Flag.Announce == 1) when the router already has an ASPA PDU with the 811 same Customer Autonomous System Number and the same Address Family 812 (see Flags field), replaces the previous one. This is to avoid a 813 race condition when a BGP announcement is received between an 814 withdrawn PDU and a new announced PDU. Therefore, the cache MUST 815 deliver the complete data of an ASPA record in a single ASPA PDU. 817 The router should see at most one ASPA from a cache for a particular 818 Customer Autonomous System Number active at any time. As a number of 819 conditions in the global RPKI may present multiple valid ASPA objects 820 for a single customer to a particular RP cache, this places a burden 821 on the cache to form the union of multiple ASPA records it has 822 received from the global RPKI into one ASPA PDU. 824 The Flags field is defined as follows: 826 Bit Bit Name 827 ---- ------------------- 828 0 AFI (IPv4 == 0, IPv6 == 1) 829 1 Announce == 1, Delete == 0 830 2-7 Reserved, must be zero 832 The Provider AS Count is the number of 32-bit Provider Autonomous 833 System Numbers in the PDU. 835 The Customer Autonomous System Number is the 32-bit Autonomous System 836 Number of the customer which authenticated the PDU. There MUST be 837 one and only one ASPA for a Customer Autonomous System Number active 838 in the router at any time. 840 There are zero or more 32-bit Provider Autonomous System Number 841 fields as indicated in the Provider AS Count; see 842 [I-D.ietf-sidrops-aspa-profile]. 844 Receipt of an ASPA PDU with the Flags field indicating Delete is an 845 explicit withdraw from the router of the entire ASPA data for that 846 customer AS. While the Provider AS Count and the Provider AS Numbers 847 MUST BE ignored by the router when the Flags field indicates a 848 Delete, the cache SHOULD set the Provider AS Count to zero, and have 849 a null Provider AS Numbers list. 851 6. Protocol Timing Parameters 853 Since the data the cache distributes via the RPKI-Router protocol are 854 retrieved from the Global RPKI system at intervals which are only 855 known to the cache, only the cache can really know how frequently it 856 makes sense for the router to poll the cache, or how long the data 857 are likely to remain valid (or, at least, unchanged). For this 858 reason, as well as to allow the cache some control over the load 859 placed on it by its client routers, the End Of Data PDU includes 860 three values that allow the cache to communicate timing parameters to 861 the router: 863 Refresh Interval: This parameter tells the router how long to wait 864 before next attempting to poll the cache and between subsequent 865 attempts, using a Serial Query or Reset Query PDU. The router 866 SHOULD NOT poll the cache sooner than indicated by this parameter. 867 Note that receipt of a Serial Notify PDU overrides this interval 868 and suggests that the router issue an immediate query without 869 waiting for the Refresh Interval to expire. Countdown for this 870 timer starts upon receipt of the containing End Of Data PDU. 872 Minimum allowed value: 1 second. 874 Maximum allowed value: 86400 seconds (1 day). 876 Recommended default: 3600 seconds (1 hour). 878 Retry Interval: This parameter tells the router how long to wait 879 before retrying a failed Serial Query or Reset Query. The router 880 SHOULD NOT retry sooner than indicated by this parameter. Note 881 that a protocol version mismatch overrides this interval: if the 882 router needs to downgrade to a lower protocol version number, it 883 MAY send the first Serial Query or Reset Query immediately. 884 Countdown for this timer starts upon failure of the query and 885 restarts after each subsequent failure until a query succeeds. 887 Minimum allowed value: 1 second. 889 Maximum allowed value: 7200 seconds (2 hours). 891 Recommended default: 600 seconds (10 minutes). 893 Expire Interval: This parameter tells the router how long it can 894 continue to use the current version of the data while unable to 895 perform a successful subsequent query. The router MUST NOT retain 896 the data past the time indicated by this parameter. Countdown for 897 this timer starts upon receipt of the containing End Of Data PDU. 899 Minimum allowed value: 600 seconds (10 minutes). 901 Maximum allowed value: 172800 seconds (2 days). 903 Recommended default: 3600 seconds (1 hour). 905 If the router has never issued a successful query against a 906 particular cache, it SHOULD retry periodically using the default 907 Retry Interval, above. 909 Caches MUST set Expire Interval to a value larger than either Refresh 910 Interval or Retry Interval. 912 7. Protocol Version Negotiation 914 A router MUST start each transport connection by issuing either a 915 Reset Query or a Serial Query. This query will tell the cache which 916 version of this protocol the router implements. 918 If a cache which supports version N receives a query from a router 919 which specifies version Q < N, the cache MUST downgrade to protocol 920 version Q [RFC6810] or [RFC8210] or send a version 1 Error Report PDU 921 with Error Code 4 ("Unsupported Protocol Version") and terminate the 922 connection. 924 If a router which supports version N sends a query to a cache which 925 only supports version C < N, one of two things will happen: 927 1. The cache may terminate the connection, perhaps with a version 0 928 Error Report PDU. In this case, the router MAY retry the 929 connection using protocol version C. 931 2. The cache may reply with a version C response. In this case, the 932 router MUST either downgrade to version C or terminate the 933 connection. 935 In any of the downgraded combinations above, the new features of the 936 higher version will not be available, and all PDUs will have the 937 negotiated lower version number in their version fields. 939 If either party receives a PDU containing an unrecognized Protocol 940 Version (neither 0, 1, nor 2) during this negotiation, it MUST either 941 downgrade to a known version or terminate the connection, with an 942 Error Report PDU unless the received PDU is itself an Error Report 943 PDU. 945 The router MUST ignore any Serial Notify PDUs it might receive from 946 the cache during this initial startup period, regardless of the 947 Protocol Version field in the Serial Notify PDU. Since Session ID 948 and Serial Number values are specific to a particular protocol 949 version, the values in the notification are not useful to the router. 950 Even if these values were meaningful, the only effect that processing 951 the notification would have would be to trigger exactly the same 952 Reset Query or Serial Query that the router has already sent as part 953 of the not-yet-complete version negotiation process, so there is 954 nothing to be gained by processing notifications until version 955 negotiation completes. 957 Caches SHOULD NOT send Serial Notify PDUs before version negotiation 958 completes. Routers, however, MUST handle such notifications (by 959 ignoring them) for backwards compatibility with caches serving 960 protocol version 0. 962 Once the cache and router have agreed upon a Protocol Version via the 963 negotiation process above, that version is stable for the life of the 964 session. See Section 5.1 for a discussion of the interaction between 965 Protocol Version and Session ID. 967 If either party receives a PDU for a different Protocol Version once 968 the above negotiation completes, that party MUST drop the session; 969 unless the PDU containing the unexpected Protocol Version was itself 970 an Error Report PDU, the party dropping the session SHOULD send an 971 Error Report with an error code of 8 ("Unexpected Protocol Version"). 973 8. Protocol Sequences 975 The sequences of PDU transmissions fall into four conversations as 976 follows: 978 8.1. Start or Restart 980 Cache Router 981 ~ ~ 982 | <----- Reset Query -------- | R requests data (or Serial Query) 983 | | 984 | ----- Cache Response -----> | C confirms request 985 | ------- Payload PDU ------> | C sends zero or more 986 | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, 987 | ------- Payload PDU ------> | or Router Key PDUs 988 | ------- End of Data ------> | C sends End of Data 989 | | and sends new serial 990 ~ ~ 992 When a transport connection is first established, the router MUST 993 send either a Reset Query or a Serial Query. A Serial Query would be 994 appropriate if the router has significant unexpired data from a 995 broken session with the same cache and remembers the Session ID of 996 that session, in which case a Serial Query containing the Session ID 997 from the previous session will allow the router to bring itself up to 998 date while ensuring that the Serial Numbers are commensurate and that 999 the router and cache are speaking compatible versions of the 1000 protocol. In all other cases, the router lacks the necessary data 1001 for fast resynchronization and therefore MUST fall back to a Reset 1002 Query. 1004 The Reset Query sequence is also used when the router receives a 1005 Cache Reset, chooses a new cache, or fears that it has otherwise lost 1006 its way. 1008 See Section 7 for details on version negotiation. 1010 To limit the length of time a cache must keep the data necessary to 1011 generate incremental updates, a router MUST send either a Serial 1012 Query or a Reset Query periodically. This also acts as a keep-alive 1013 at the application layer. See Section 6 for details on the required 1014 polling frequency. 1016 8.2. Typical Exchange 1017 Cache Router 1018 ~ ~ 1019 | -------- Notify ----------> | (optional) 1020 | | 1021 | <----- Serial Query ------- | R requests data 1022 | | 1023 | ----- Cache Response -----> | C confirms request 1024 | ------- Payload PDU ------> | C sends zero or more 1025 | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, 1026 | ------- Payload PDU ------> | or Router Key PDUs 1027 | ------- End of Data ------> | C sends End of Data 1028 | | and sends new serial 1029 ~ ~ 1031 The cache server SHOULD send a Notify PDU with its current Serial 1032 Number when the cache's serial changes, with the expectation that the 1033 router MAY then issue a Serial Query earlier than it otherwise might. 1034 This is analogous to DNS NOTIFY in [RFC1996]. The cache MUST 1035 rate-limit Serial Notifies to no more frequently than one per minute. 1037 When the transport layer is up and either a timer has gone off in the 1038 router or the cache has sent a Notify PDU, the router queries for new 1039 data by sending a Serial Query, and the cache sends all data newer 1040 than the serial in the Serial Query. 1042 To limit the length of time a cache must keep old withdraws, a router 1043 MUST send either a Serial Query or a Reset Query periodically. See 1044 Section 6 for details on the required polling frequency. 1046 8.3. No Incremental Update Available 1048 Cache Router 1049 ~ ~ 1050 | <------ Serial Query ------ | R requests data 1051 | ------- Cache Reset ------> | C cannot supply update 1052 | | from specified serial 1053 | <------ Reset Query ------- | R requests new data 1054 | ----- Cache Response -----> | C confirms request 1055 | ------- Payload PDU ------> | C sends zero or more 1056 | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, 1057 | ------- Payload PDU ------> | or Router Key PDUs 1058 | ------- End of Data ------> | C sends End of Data 1059 | | and sends new serial 1060 ~ ~ 1062 The cache may respond to a Serial Query with a Cache Reset, informing 1063 the router that the cache cannot supply an incremental update from 1064 the Serial Number specified by the router. This might be because the 1065 cache has lost state, or because the router has waited too long 1066 between polls and the cache has cleaned up old data that it no longer 1067 believes it needs, or because the cache has run out of storage space 1068 and had to expire some old data early. Regardless of how this state 1069 arose, the cache replies with a Cache Reset to tell the router that 1070 it cannot honor the request. When a router receives this, the router 1071 SHOULD attempt to connect to any more-preferred caches in its cache 1072 list. If there are no more-preferred caches, it MUST issue a Reset 1073 Query and get an entire new load from the cache. 1075 8.4. Cache Has No Data Available 1077 Cache Router 1078 ~ ~ 1079 | <------ Serial Query ------ | R requests data 1080 | ---- Error Report PDU ----> | C No Data Available 1081 ~ ~ 1083 Cache Router 1084 ~ ~ 1085 | <------ Reset Query ------- | R requests data 1086 | ---- Error Report PDU ----> | C No Data Available 1087 ~ ~ 1089 The cache may respond to either a Serial Query or a Reset Query 1090 informing the router that the cache cannot supply any update at all. 1091 The most likely cause is that the cache has lost state, perhaps due 1092 to a restart, and has not yet recovered. While it is possible that a 1093 cache might go into such a state without dropping any of its active 1094 sessions, a router is more likely to see this behavior when it 1095 initially connects and issues a Reset Query while the cache is still 1096 rebuilding its database. 1098 When a router receives this kind of error, the router SHOULD attempt 1099 to connect to any other caches in its cache list, in preference 1100 order. If no other caches are available, the router MUST issue 1101 periodic Reset Queries until it gets a new usable load from the 1102 cache. 1104 9. Transport 1106 The transport-layer session between a router and a cache carries the 1107 binary PDUs in a persistent session. 1109 To prevent cache spoofing and DoS attacks by illegitimate routers, it 1110 is highly desirable that the router and the cache be authenticated to 1111 each other. Integrity protection for payloads is also desirable to 1112 protect against monkey-in-the-middle (MITM) attacks. Unfortunately, 1113 there is no protocol to do so on all currently used platforms. 1114 Therefore, as of the writing of this document, there is no mandatory- 1115 to-implement transport which provides authentication and integrity 1116 protection. 1118 To reduce exposure to dropped but non-terminated sessions, both 1119 caches and routers SHOULD enable keep-alives when available in the 1120 chosen transport protocol. 1122 It is expected that, when the TCP Authentication Option (TCP-AO) 1123 [RFC5925] is available on all platforms deployed by operators, it 1124 will become the mandatory-to-implement transport. 1126 Caches and routers MUST implement unprotected transport over TCP 1127 using a port, rpki-rtr (323); see Section 15. Operators SHOULD use 1128 procedural means, e.g., access control lists (ACLs), to reduce the 1129 exposure to authentication issues. 1131 If unprotected TCP is the transport, the cache and routers MUST be on 1132 the same trusted and controlled network. 1134 If available to the operator, caches and routers MUST use one of the 1135 following more protected protocols: 1137 * Caches and routers SHOULD use TCP-AO transport [RFC5925] over the 1138 rpki-rtr port. 1140 * Caches and routers MAY use Secure Shell version 2 (SSHv2) 1141 transport [RFC4252] using the normal SSH port. For an example, 1142 see Section 9.1. 1144 * Caches and routers MAY use TCP MD5 transport [RFC2385] using the 1145 rpki-rtr port. Note that TCP MD5 has been obsoleted by TCP-AO 1146 [RFC5925]. 1148 * Caches and routers MAY use TCP over IPsec transport [RFC4301] 1149 using the rpki-rtr port. 1151 * Caches and routers MAY use Transport Layer Security (TLS) 1152 transport [RFC5246] using port rpki-rtr-tls (324); see Section 15. 1154 9.1. SSH Transport 1156 To run over SSH, the client router first establishes an SSH transport 1157 connection using the SSHv2 transport protocol, and the client and 1158 server exchange keys for message integrity and encryption. The 1159 client then invokes the "ssh-userauth" service to authenticate the 1160 application, as described in the SSH authentication protocol 1161 [RFC4252]. Once the application has been successfully authenticated, 1162 the client invokes the "ssh-connection" service, also known as the 1163 SSH connection protocol. 1165 After the ssh-connection service is established, the client opens a 1166 channel of type "session", which results in an SSH session. 1168 Once the SSH session has been established, the application invokes 1169 the application transport as an SSH subsystem called "rpki-rtr". 1170 Subsystem support is a feature of SSHv2 and is not included in SSHv1. 1171 Running this protocol as an SSH subsystem avoids the need for the 1172 application to recognize shell prompts or skip over extraneous 1173 information, such as a system message that is sent at shell startup. 1175 It is assumed that the router and cache have exchanged keys out of 1176 band by some reasonably secured means. 1178 Cache servers supporting SSH transport MUST accept RSA authentication 1179 and SHOULD accept Elliptic Curve Digital Signature Algorithm (ECDSA) 1180 authentication. User authentication MUST be supported; host 1181 authentication MAY be supported. Implementations MAY support 1182 password authentication. Client routers SHOULD verify the public key 1183 of the cache to avoid MITM attacks. 1185 9.2. TLS Transport 1187 Client routers using TLS transport MUST present client-side 1188 certificates to authenticate themselves to the cache in order to 1189 allow the cache to manage the load by rejecting connections from 1190 unauthorized routers. In principle, any type of certificate and 1191 Certification Authority (CA) may be used; however, in general, cache 1192 operators will wish to create their own small-scale CA and issue 1193 certificates to each authorized router. This simplifies credential 1194 rollover; any unrevoked, unexpired certificate from the proper CA may 1195 be used. 1197 Certificates used to authenticate client routers in this protocol 1198 MUST include a subjectAltName extension [RFC5280] containing one or 1199 more iPAddress identities; when authenticating the router's 1200 certificate, the cache MUST check the IP address of the TLS 1201 connection against these iPAddress identities and SHOULD reject the 1202 connection if none of the iPAddress identities match the connection. 1204 Routers MUST also verify the cache's TLS server certificate, using 1205 subjectAltName dNSName identities as described in [RFC6125], to avoid 1206 MITM attacks. The rules and guidelines defined in [RFC6125] apply 1207 here, with the following considerations: 1209 * Support for the DNS-ID identifier type (that is, the dNSName 1210 identity in the subjectAltName extension) is REQUIRED in rpki-rtr 1211 server and client implementations which use TLS. Certification 1212 authorities which issue rpki-rtr server certificates MUST support 1213 the DNS-ID identifier type, and the DNS-ID identifier type MUST be 1214 present in rpki-rtr server certificates. 1216 * DNS names in rpki-rtr server certificates SHOULD NOT contain the 1217 wildcard character "*". 1219 * rpki-rtr implementations which use TLS MUST NOT use Common Name 1220 (CN-ID) identifiers; a CN field may be present in the server 1221 certificate's subject name but MUST NOT be used for authentication 1222 within the rules described in [RFC6125]. 1224 * The client router MUST set its "reference identifier" to the DNS 1225 name of the rpki-rtr cache. 1227 9.3. TCP MD5 Transport 1229 If TCP MD5 is used, implementations MUST support key lengths of at 1230 least 80 printable ASCII bytes, per Section 4.5 of [RFC2385]. 1231 Implementations MUST also support hexadecimal sequences of at least 1232 32 characters, i.e., 128 bits. 1234 Key rollover with TCP MD5 is problematic. Cache servers SHOULD 1235 support [RFC4808]. 1237 9.4. TCP-AO Transport 1239 Implementations MUST support key lengths of at least 80 printable 1240 ASCII bytes. Implementations MUST also support hexadecimal sequences 1241 of at least 32 characters, i.e., 128 bits. Message Authentication 1242 Code (MAC) lengths of at least 96 bits MUST be supported, per 1243 Section 5.1 of [RFC5925]. 1245 The cryptographic algorithms and associated parameters described in 1246 [RFC5926] MUST be supported. 1248 10. Router-Cache Setup 1250 A cache has the public authentication data for each router it is 1251 configured to support. 1253 A router may be configured to peer with a selection of caches, and a 1254 cache may be configured to support a selection of routers. Each must 1255 have the name of, and authentication data for, each peer. In 1256 addition, in a router, this list has a non-unique preference value 1257 for each server. This preference merely denotes proximity, not 1258 trust, preferred belief, et cetera. The client router attempts to 1259 establish a session with each potential serving cache in preference 1260 order and then starts to load data from the most preferred cache to 1261 which it can connect and authenticate. The router's list of caches 1262 has the following elements: 1264 Preference: An unsigned integer denoting the router's preference to 1265 connect to that cache; the lower the value, the more preferred. 1267 Name: The IP address or fully qualified domain name of the cache. 1269 Cache Credential(s): Any credential (such as a public key) needed to 1270 authenticate the cache's identity to the router. 1272 Router Credential(s): Any credential (such as a private key or 1273 certificate) needed to authenticate the router's identity to the 1274 cache. 1276 Due to the distributed nature of the RPKI, caches simply cannot be 1277 rigorously synchronous. A client may hold data from multiple caches 1278 but MUST keep the data marked as to source, as later updates MUST 1279 affect the correct data. 1281 Just as there may be more than one covering ROA from a single cache, 1282 there may be multiple covering ROAs from multiple caches. The 1283 results are as described in [RFC6811]. 1285 If data from multiple caches are held, implementations MUST NOT 1286 distinguish between data sources when performing validation of BGP 1287 announcements. 1289 When a more-preferred cache becomes available, if resources allow, it 1290 would be prudent for the client to start fetching from that cache. 1292 The client SHOULD attempt to maintain at least one set of data, 1293 regardless of whether it has chosen a different cache or established 1294 a new connection to the previous cache. 1296 A client MAY drop the data from a particular cache when it is fully 1297 in sync with one or more other caches. 1299 See Section 6 for details on what to do when the client is not able 1300 to refresh from a particular cache. 1302 If a client loses connectivity to a cache it is using or otherwise 1303 decides to switch to a new cache, it SHOULD retain the data from the 1304 previous cache until it has a full set of data from one or more other 1305 caches. Note that this may already be true at the point of 1306 connection loss if the client has connections to more than one cache. 1308 11. ROA PDU Race Minimization 1310 When a cache is sending ROA PDUs to the router, especially during an 1311 initial full load, two undesirable race conditions are possible: 1313 Break Before Make: For some prefix P, an AS may announce two (or 1314 more) ROAs because they are in the process of changing what 1315 provider AS is announcing P. This is is a case of "make before 1316 break." If a cache is feeding a router and sends the one not yet 1317 in service a significant time before sending the one currently in 1318 service, then BGP data could be marked invalid during the 1319 interval. To minimize that interval, the cache SHOULD announce 1320 all ROAs for the same prefix as close to sequentially as possible. 1322 Shorter Prefix First: If an AS has issued a ROA for P0, and another 1323 AS (likely their customer) has issued a ROA for P1 which is a sub- 1324 prefix of P0, a router which receives the ROA for P0 before that 1325 for P1 is likely to mark a BGP prefix P1 invalid. Therefore, the 1326 cache SHOULD announce the sub-prefix P1 before the covering prefix 1327 P0. 1329 12. Deployment Scenarios 1331 For illustration, we present three likely deployment scenarios: 1333 Small End Site: The small multihomed end site may wish to outsource 1334 the RPKI cache to one or more of their upstream ISPs. They would 1335 exchange authentication material with the ISP using some out-of- 1336 band mechanism, and their router(s) would connect to the cache(s) 1337 of one or more upstream ISPs. The ISPs would likely deploy caches 1338 intended for customer use separately from the caches with which 1339 their own BGP speakers peer. 1341 Large End Site: A larger multihomed end site might run one or more 1342 caches, arranging them in a hierarchy of client caches, each 1343 fetching from a serving cache which is closer to the Global RPKI. 1344 They might configure fallback peerings to upstream ISP caches. 1346 ISP Backbone: A large ISP would likely have one or more redundant 1347 caches in each major point of presence (PoP), and these caches 1348 would fetch from each other in an ISP-dependent topology so as not 1349 to place undue load on the Global RPKI. 1351 Experience with large DNS cache deployments has shown that complex 1352 topologies are ill-advised, as it is easy to make errors in the 1353 graph, e.g., not maintain a loop-free condition. 1355 Of course, these are illustrations, and there are other possible 1356 deployment strategies. It is expected that minimizing load on the 1357 Global RPKI servers will be a major consideration. 1359 To keep load on Global RPKI services from unnecessary peaks, it is 1360 recommended that primary caches which load from the distributed 1361 Global RPKI not do so all at the same times, e.g., on the hour. 1362 Choose a random time, perhaps the ISP's AS number modulo 60, and 1363 jitter the inter-fetch timing. 1365 13. Error Codes 1367 This section contains a preliminary list of error codes. The authors 1368 expect additions to the list during development of the initial 1369 implementations. There is an IANA registry where valid error codes 1370 are listed; see Section 15. Errors which are considered fatal MUST 1371 cause the session to be dropped. 1373 0: Corrupt Data (fatal): The receiver believes the received PDU to 1374 be corrupt in a manner not specified by another error code. 1376 1: Internal Error (fatal): The party reporting the error experienced 1377 some kind of internal error unrelated to protocol operation (ran 1378 out of memory, a coding assertion failed, et cetera). 1380 2: No Data Available: The cache believes itself to be in good 1381 working order but is unable to answer either a Serial Query or a 1382 Reset Query because it has no useful data available at this time. 1383 This is likely to be a temporary error and most likely indicates 1384 that the cache has not yet completed pulling down an initial 1385 current data set from the Global RPKI system after some kind of 1386 event that invalidated whatever data it might have previously held 1387 (reboot, network partition, et cetera). 1389 3: Invalid Request (fatal): The cache server believes the client's 1390 request to be invalid. 1392 4: Unsupported Protocol Version (fatal): The Protocol Version is not 1393 known by the receiver of the PDU. 1395 5: Unsupported PDU Type (fatal): The PDU Type is not known by the 1396 receiver of the PDU. 1398 6: Withdrawal of Unknown Record (fatal): The received PDU has 1399 Flag=0, but a matching record ({Prefix, Len, Max-Len, ASN} tuple 1400 for an IPvX PDU or {SKI, ASN, Subject Public Key} tuple for a 1401 Router Key PDU) does not exist in the receiver's database. 1403 7: Duplicate Announcement Received (fatal): The received PDU has 1404 Flag=1, but a matching record ({Prefix, Len, Max-Len, ASN} tuple 1405 for an IPvX PDU or {SKI, ASN, Subject Public Key} tuple for a 1406 Router Key PDU) is already active in the router. 1408 8: Unexpected Protocol Version (fatal): The received PDU has a 1409 Protocol Version field that differs from the protocol version 1410 negotiated in Section 7. 1412 14. Security Considerations 1414 As this document describes a security protocol, many aspects of 1415 security interest are described in the relevant sections. This 1416 section points out issues which may not be obvious in other sections. 1418 Cache Validation: In order for a collection of caches as described 1419 in Section 12 to guarantee a consistent view, they need to be 1420 given consistent trust anchors to use in their internal validation 1421 process. Distribution of a consistent trust anchor is assumed to 1422 be out of band. 1424 Cache Peer Identification: The router initiates a transport 1425 connection to a cache, which it identifies by either IP address or 1426 fully qualified domain name. Be aware that a DNS or address 1427 spoofing attack could make the correct cache unreachable. No 1428 session would be established, as the authorization keys would not 1429 match. 1431 Transport Security: The RPKI relies on object, not server or 1432 transport, trust. That is, the IANA root trust anchor is 1433 distributed to all caches through some out-of-band means and can 1434 then be used by each cache to validate certificates and ROAs all 1435 the way down the tree. The inter-cache relationships are based on 1436 this object security model; hence, the inter-cache transport can 1437 be lightly protected. 1439 However, this protocol document assumes that the routers cannot do 1440 the validation cryptography. Hence, the last link, from cache to 1441 router, is secured by server authentication and transport-level 1442 security. This is dangerous, as server authentication and 1443 transport have very different threat models than object security. 1445 So the strength of the trust relationship and the transport 1446 between the router(s) and the cache(s) are critical. You're 1447 betting your routing on this. 1449 While we cannot say the cache must be on the same LAN, if only due 1450 to the issue of an enterprise wanting to offload the cache task to 1451 their upstream ISP(s), locality, trust, and control are very 1452 critical issues here. The cache(s) really SHOULD be as close, in 1453 the sense of controlled and protected (against DDoS, MITM) 1454 transport, to the router(s) as possible. It also SHOULD be 1455 topologically close so that a minimum of validated routing data 1456 are needed to bootstrap a router's access to a cache. 1458 The identity of the cache server SHOULD be verified and 1459 authenticated by the router client, and vice versa, before any 1460 data are exchanged. 1462 Transports which cannot provide the necessary authentication and 1463 integrity (see Section 9) must rely on network design and 1464 operational controls to provide protection against spoofing/ 1465 corruption attacks. As pointed out in Section 9, TCP-AO is the 1466 long-term plan. Protocols which provide integrity and 1467 authenticity SHOULD be used, and if they cannot, i.e., TCP is used 1468 as the transport, the router and cache MUST be on the same 1469 trusted, controlled network. 1471 15. IANA Considerations 1473 This section only discusses updates required in the existing IANA 1474 protocol registries to accommodate version 1 of this protocol. See 1475 [RFC8210] for IANA considerations from the original (version 0) 1476 protocol. 1478 All existing entries in the IANA "rpki-rtr-pdu" registry remain valid 1479 for protocol version 0. All of the PDU types allowed in protocol 1480 version 0 are also allowed in protocol version 1, with the addition 1481 of the new Router Key PDU. To reduce the likelihood of confusion, 1482 the PDU number used by the Router Key PDU in protocol version 1 is 1483 hereby registered as reserved (and unused) in protocol version 0. 1485 The policy for adding to the registry is RFC Required per [RFC8126]; 1486 the document must be either Standards Track or Experimental. 1488 The "rpki-rtr-pdu" registry has been updated as follows: 1490 Protocol PDU 1491 Version Type Description 1492 -------- ---- --------------- 1493 0-2 0 Serial Notify 1494 0-2 1 Serial Query 1495 0-2 2 Reset Query 1496 0-2 3 Cache Response 1497 0-2 4 IPv4 Prefix 1498 0-2 6 IPv6 Prefix 1499 0-2 7 End of Data 1500 0-2 8 Cache Reset 1501 0 9 Reserved 1502 1-2 9 Router Key 1503 0-2 10 Error Report 1504 0-1 11 Reserved 1505 2 11 ASPA 1506 0-2 255 Reserved 1508 All previous entries in the IANA "rpki-rtr-error" registry remain 1509 valid for all protocol versions. Protocol version 1 added one new 1510 error code: 1512 Error 1513 Code Description 1514 ----- --------------------------- 1515 8 Unexpected Protocol Version 1517 16. References 1519 16.1. Normative References 1521 [I-D.ietf-sidrops-aspa-profile] 1522 Azimov, A., Uskov, E., Bush, R., Patel, K., Snijders, J., 1523 and R. Housley, "A Profile for Autonomous System Provider 1524 Authorization", Work in Progress, Internet-Draft, draft- 1525 ietf-sidrops-aspa-profile-06, 30 July 2021, 1526 . 1529 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 1530 DOI 10.17487/RFC1982, August 1996, 1531 . 1533 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1534 Requirement Levels", BCP 14, RFC 2119, 1535 DOI 10.17487/RFC2119, March 1997, 1536 . 1538 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1539 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 1540 1998, . 1542 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1543 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1544 2003, . 1546 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 1547 Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, 1548 January 2006, . 1550 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1551 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1552 December 2005, . 1554 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1555 (TLS) Protocol Version 1.2", RFC 5246, 1556 DOI 10.17487/RFC5246, August 2008, 1557 . 1559 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1560 Housley, R., and W. Polk, "Internet X.509 Public Key 1561 Infrastructure Certificate and Certificate Revocation List 1562 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1563 . 1565 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1566 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1567 June 2010, . 1569 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 1570 for the TCP Authentication Option (TCP-AO)", RFC 5926, 1571 DOI 10.17487/RFC5926, June 2010, 1572 . 1574 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1575 Verification of Domain-Based Application Service Identity 1576 within Internet Public Key Infrastructure Using X.509 1577 (PKIX) Certificates in the Context of Transport Layer 1578 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1579 2011, . 1581 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 1582 X.509 PKIX Resource Certificates", RFC 6487, 1583 DOI 10.17487/RFC6487, February 2012, 1584 . 1586 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 1587 Infrastructure (RPKI) to Router Protocol", RFC 6810, 1588 DOI 10.17487/RFC6810, January 2013, 1589 . 1591 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 1592 Austein, "BGP Prefix Origin Validation", RFC 6811, 1593 DOI 10.17487/RFC6811, January 2013, 1594 . 1596 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1597 Writing an IANA Considerations Section in RFCs", BCP 26, 1598 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1599 . 1601 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1602 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1603 May 2017, . 1605 [RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key 1606 Formats, and Signature Formats", RFC 8208, 1607 DOI 10.17487/RFC8208, September 2017, 1608 . 1610 [RFC8210] Bush, R. and R. Austein, "The Resource Public Key 1611 Infrastructure (RPKI) to Router Protocol, Version 1", 1612 RFC 8210, DOI 10.17487/RFC8210, September 2017, 1613 . 1615 16.2. Informative References 1617 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 1618 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 1619 August 1996, . 1621 [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", 1622 RFC 4808, DOI 10.17487/RFC4808, March 2007, 1623 . 1625 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 1626 Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, 1627 . 1629 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 1630 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 1631 February 2012, . 1633 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 1634 Resource Certificate Repository Structure", RFC 6481, 1635 DOI 10.17487/RFC6481, February 2012, 1636 . 1638 Acknowledgements 1640 The authors wish to thank Nils Bars, Steve Bellovin, Oliver Borchert, 1641 Tim Bruijnzeels, Rex Fernando, Richard Hansen, Martin Hoffmann, Paul 1642 Hoffman, Fabian Holler, Russ Housley, Pradosh Mohapatra, Keyur Patel, 1643 David Mandelberg, Sandy Murphy, Robert Raszuk, Andreas Reuter, Thomas 1644 Schmidt, John Scudder, Ruediger Volk, Matthias Waehlisch, and David 1645 Ward. Particular thanks go to Hannes Gredler for showing us the 1646 dangers of unnecessary fields. 1648 No doubt this list is incomplete. We apologize to any contributor 1649 whose name we missed. 1651 Authors' Addresses 1653 Randy Bush 1654 IIJ, Arrcus, & DRL 1655 5147 Crystal Springs 1656 Bainbridge Island, Washington 98110 1657 United States of America 1659 Email: randy@psg.com 1661 Rob Austein 1662 Dragon Research Labs 1663 Email: sra@hactrn.net