idnits 2.17.1 draft-ietf-sidrops-8210bis-00.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 (March 30, 2020) is 1487 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-02 ** 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 4 Updates: 8210 (if approved) R. Austein 5 Intended status: Standards Track Dragon Research Labs 6 Expires: October 1, 2020 March 30, 2020 8 The Resource Public Key Infrastructure (RPKI) to Router Protocol, 9 Version 2 10 draft-ietf-sidrops-8210bis-00 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 October 1, 2020. 41 Copyright Notice 43 Copyright (c) 2020 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 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 1.2. Changes from RFC 8210 . . . . . . . . . . . . . . . . . . 3 61 2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Deployment Structure . . . . . . . . . . . . . . . . . . . . 4 63 4. Operational Overview . . . . . . . . . . . . . . . . . . . . 5 64 5. Protocol Data Units (PDUs) . . . . . . . . . . . . . . . . . 6 65 5.1. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 6 66 5.2. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 9 67 5.3. Serial Query . . . . . . . . . . . . . . . . . . . . . . 9 68 5.4. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 10 69 5.5. Cache Response . . . . . . . . . . . . . . . . . . . . . 11 70 5.6. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 11 71 5.7. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 13 72 5.8. End of Data . . . . . . . . . . . . . . . . . . . . . . . 13 73 5.9. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 15 74 5.10. Router Key . . . . . . . . . . . . . . . . . . . . . . . 15 75 5.11. Error Report . . . . . . . . . . . . . . . . . . . . . . 17 76 5.12. ASPA PDU . . . . . . . . . . . . . . . . . . . . . . . . 18 77 6. Protocol Timing Parameters . . . . . . . . . . . . . . . . . 20 78 7. Protocol Version Negotiation . . . . . . . . . . . . . . . . 21 79 8. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . 22 80 8.1. Start or Restart . . . . . . . . . . . . . . . . . . . . 22 81 8.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . 23 82 8.3. No Incremental Update Available . . . . . . . . . . . . . 24 83 8.4. Cache Has No Data Available . . . . . . . . . . . . . . . 25 84 9. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 25 85 9.1. SSH Transport . . . . . . . . . . . . . . . . . . . . . . 26 86 9.2. TLS Transport . . . . . . . . . . . . . . . . . . . . . . 27 87 9.3. TCP MD5 Transport . . . . . . . . . . . . . . . . . . . . 28 88 9.4. TCP-AO Transport . . . . . . . . . . . . . . . . . . . . 28 89 10. Router-Cache Setup . . . . . . . . . . . . . . . . . . . . . 28 90 11. ROA PDU Race Minimization . . . . . . . . . . . . . . . . . . 30 91 12. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 30 92 13. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 31 93 14. Security Considerations . . . . . . . . . . . . . . . . . . . 32 94 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 95 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 96 16.1. Normative References . . . . . . . . . . . . . . . . . . 34 97 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 [RFC6810]. 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 [RFC6810] and 137 the protocol described in this document. 139 o New ASPA PDU type (Section 5.12) added to support 140 [I-D.ietf-sidrops-aspa-profile]. 142 o A small section, Section 11, has been added to handle two ROA PDU 143 race conditions, Break Before Make and Shorter Prefix First. 145 o Protocol version number incremented from 1 (one) to 2 (two). 147 2. Glossary 149 The following terms are used with special meaning. 151 Global RPKI: The authoritative data of the RPKI are published in a 152 distributed set of servers at the IANA, Regional Internet 153 Registries (RIRs), National Internet Registries (NIRs), and ISPs; 154 see [RFC6481]. 156 Cache: A cache is a coalesced copy of the published Global RPKI 157 data, periodically fetched or refreshed, directly or indirectly, 158 using the rsync protocol [RFC5781] or some successor. Relying 159 Party software is used to gather and validate the distributed data 160 of the RPKI into a cache. Trusting this cache further is a matter 161 between the provider of the cache and a Relying Party. 163 Serial Number: "Serial Number" is a 32-bit strictly increasing 164 unsigned integer which wraps from 2^32-1 to 0. It denotes the 165 logical version of a cache. A cache increments the value when it 166 successfully updates its data from a parent cache or from primary 167 RPKI data. While a cache is receiving updates, new incoming data 168 and implicit deletes are associated with the new serial but MUST 169 NOT be sent until the fetch is complete. A Serial Number is not 170 commensurate between different caches or different protocol 171 versions, nor need it be maintained across resets of the cache 172 server. See [RFC1982] on DNS Serial Number Arithmetic for too 173 much detail on the topic. 175 Session ID: When a cache server is started, it generates a Session 176 ID to uniquely identify the instance of the cache and to bind it 177 to the sequence of Serial Numbers that cache instance will 178 generate. This allows the router to restart a failed session 179 knowing that the Serial Number it is using is commensurate with 180 that of the cache. 182 Payload PDU: A payload PDU is a protocol message which contains data 183 for use by the router, as opposed to a PDU which conveys the 184 control mechanisms of this protocol. Prefixes and Router Keys are 185 examples of payload PDUs. 187 3. Deployment Structure 189 Deployment of the RPKI to reach routers has a three-level structure 190 as follows: 192 Global RPKI: The authoritative data of the RPKI are published in a 193 distributed set of servers at the IANA, RIRs, NIRs, and ISPs (see 194 [RFC6481]). 196 Local Caches: Local caches are a local set of one or more collected 197 and verified caches of RPKI data. A Relying Party, e.g., router 198 or other client, MUST have a trust relationship with, and a 199 trusted transport channel to, any cache(s) it uses. 201 Routers: A router fetches data from a local cache using the protocol 202 described in this document. It is said to be a client of the 203 cache. There MAY be mechanisms for the router to assure itself of 204 the authenticity of the cache and to authenticate itself to the 205 cache (see Section 9). 207 4. Operational Overview 209 A router establishes and keeps open a connection to one or more 210 caches with which it has client/server relationships. It is 211 configured with a semi-ordered list of caches and establishes a 212 connection to the most preferred cache, or set of caches, which 213 accept the connections. 215 The router MUST choose the most preferred, by configuration, cache or 216 set of caches so that the operator may control load on their caches 217 and the Global RPKI. 219 Periodically, the router sends to the cache the most recent Serial 220 Number for which it has received data from that cache, i.e., the 221 router's current Serial Number, in the form of a Serial Query. When 222 a router establishes a new session with a cache or wishes to reset a 223 current relationship, it sends a Reset Query. 225 The cache responds to the Serial Query with all data changes which 226 took place since the given Serial Number. This may be the null set, 227 in which case the End of Data PDU (Section 5.8) is still sent. Note 228 that the Serial Number comparison used to determine "since the given 229 Serial Number" MUST take wrap-around into account; see [RFC1982]. 231 When the router has received all data records from the cache, it sets 232 its current Serial Number to that of the Serial Number in the 233 received End of Data PDU. 235 When the cache updates its database, it sends a Notify PDU to every 236 currently connected router. This is a hint that now would be a good 237 time for the router to poll for an update, but it is only a hint. 238 The protocol requires the router to poll for updates periodically in 239 any case. 241 Strictly speaking, a router could track a cache simply by asking for 242 a complete data set every time it updates, but this would be very 243 inefficient. The Serial-Number-based incremental update mechanism 244 allows an efficient transfer of just the data records which have 245 changed since the last update. As with any update protocol based on 246 incremental transfers, the router must be prepared to fall back to a 247 full transfer if for any reason the cache is unable to provide the 248 necessary incremental data. Unlike some incremental transfer 249 protocols, this protocol requires the router to make an explicit 250 request to start the fallback process; this is deliberate, as the 251 cache has no way of knowing whether the router has also established 252 sessions with other caches that may be able to provide better 253 service. 255 As a cache server must evaluate certificates and ROAs (Route Origin 256 Authorizations; see [RFC6480]), which are time dependent, servers' 257 clocks MUST be correct to a tolerance of approximately an hour. 259 5. Protocol Data Units (PDUs) 261 The exchanges between the cache and the router are sequences of 262 exchanges of the following PDUs according to the rules described in 263 Section 8. 265 Reserved fields (marked "zero" in PDU diagrams) MUST be zero on 266 transmission and MUST be ignored on receipt. 268 5.1. Fields of a PDU 270 PDUs contain the following data elements: 272 Protocol Version: An 8-bit unsigned integer, currently 1, denoting 273 the version of this protocol. 275 PDU Type: An 8-bit unsigned integer, denoting the type of the PDU, 276 e.g., IPv4 Prefix. 278 Serial Number: The Serial Number of the RPKI cache when this set of 279 PDUs was received from an upstream cache server or gathered from 280 the Global RPKI. A cache increments its Serial Number when 281 completing a rigorously validated update from a parent cache or 282 the Global RPKI. 284 Session ID: A 16-bit unsigned integer. When a cache server is 285 started, it generates a Session ID to identify the instance of the 286 cache and to bind it to the sequence of Serial Numbers that cache 287 instance will generate. This allows the router to restart a 288 failed session knowing that the Serial Number it is using is 289 commensurate with that of the cache. If, at any time after the 290 protocol version has been negotiated (Section 7), either the 291 router or the cache finds that the value of the Session ID is not 292 the same as the other's, the party which detects the mismatch MUST 293 immediately terminate the session with an Error Report PDU with 294 code 0 ("Corrupt Data"), and the router MUST flush all data 295 learned from that cache. 297 Note that sessions are specific to a particular protocol version. 298 That is, if a cache server supports multiple versions of this 299 protocol, happens to use the same Session ID value for multiple 300 protocol versions, and further happens to use the same Serial 301 Number values for two or more sessions using the same Session ID 302 but different Protocol Version values, the Serial Numbers are not 303 commensurate. The full test for whether Serial Numbers are 304 commensurate requires comparing Protocol Version, Session ID, and 305 Serial Number. To reduce the risk of confusion, cache servers 306 SHOULD NOT use the same Session ID across multiple protocol 307 versions, but even if they do, routers MUST treat sessions with 308 different Protocol Version fields as separate sessions even if 309 they do happen to have the same Session ID. 311 Should a cache erroneously reuse a Session ID so that a router 312 does not realize that the session has changed (old Session ID and 313 new Session ID have the same numeric value), the router may become 314 confused as to the content of the cache. The time it takes the 315 router to discover that it is confused will depend on whether the 316 Serial Numbers are also reused. If the Serial Numbers in the old 317 and new sessions are different enough, the cache will respond to 318 the router's Serial Query with a Cache Reset, which will solve the 319 problem. If, however, the Serial Numbers are close, the cache may 320 respond with a Cache Response, which may not be enough to bring 321 the router into sync. In such cases, it's likely but not certain 322 that the router will detect some discrepancy between the state 323 that the cache expects and its own state. For example, the Cache 324 Response may tell the router to drop a record which the router 325 does not hold or may tell the router to add a record which the 326 router already has. In such cases, a router will detect the error 327 and reset the session. The one case in which the router may stay 328 out of sync is when nothing in the Cache Response contradicts any 329 data currently held by the router. 331 Using persistent storage for the Session ID or a clock-based 332 scheme for generating Session IDs should avoid the risk of Session 333 ID collisions. 335 The Session ID might be a pseudorandom value, a strictly 336 increasing value if the cache has reliable storage, et cetera. A 337 seconds-since-epoch timestamp value such as the POSIX time() 338 function makes a good Session ID value. 340 Length: A 32-bit unsigned integer which has as its value the count 341 of the bytes in the entire PDU, including the 8 bytes of header 342 which includes the length field. 344 Flags: The lowest-order bit of the Flags field is 1 for an 345 announcement and 0 for a withdrawal. For a Prefix PDU (IPv4 or 346 IPv6), the flag indicates whether this PDU announces a new right 347 to announce the prefix or withdraws a previously announced right; 348 a withdraw effectively deletes one previously announced Prefix PDU 349 with the exact same Prefix, Length, Max-Len, and Autonomous System 350 Number (ASN). Similarly, for a Router Key PDU, the flag indicates 351 whether this PDU announces a new Router Key or deletes one 352 previously announced Router Key PDU with the exact same AS Number, 353 subjectKeyIdentifier, and subjectPublicKeyInfo. 355 The remaining bits in the Flags field are reserved for future use. 356 In protocol version 1, they MUST be zero on transmission and MUST 357 be ignored on receipt. 359 Prefix Length: An 8-bit unsigned integer denoting the shortest 360 prefix allowed by the Prefix element. 362 Max Length: An 8-bit unsigned integer denoting the longest prefix 363 allowed by the Prefix element. This MUST NOT be less than the 364 Prefix Length element. 366 Prefix: The IPv4 or IPv6 prefix of the ROA. 368 Autonomous System Number: A 32-bit unsigned integer representing an 369 ASN allowed to announce a prefix or associated with a router key. 371 Subject Key Identifier: 20-octet Subject Key Identifier (SKI) value 372 of a router key, as described in [RFC6487]. 374 Subject Public Key Info: A router key's subjectPublicKeyInfo value, 375 as described in [RFC8208]. This is the full ASN.1 DER encoding of 376 the subjectPublicKeyInfo, including the ASN.1 tag and length 377 values of the subjectPublicKeyInfo SEQUENCE. 379 Refresh Interval: Interval between normal cache polls. See 380 Section 6. 382 Retry Interval: Interval between cache poll retries after a failed 383 cache poll. See Section 6. 385 Expire Interval: Interval during which data fetched from a cache 386 remains valid in the absence of a successful subsequent cache 387 poll. See Section 6. 389 5.2. Serial Notify 391 The cache notifies the router that the cache has new data. 393 The Session ID reassures the router that the Serial Numbers are 394 commensurate, i.e., the cache session has not been changed. 396 Upon receipt of a Serial Notify PDU, the router MAY issue an 397 immediate Serial Query (Section 5.3) or Reset Query (Section 5.4) 398 without waiting for the Refresh Interval timer (see Section 6) to 399 expire. 401 Serial Notify is the only message that the cache can send that is not 402 in response to a message from the router. 404 If the router receives a Serial Notify PDU during the initial startup 405 period where the router and cache are still negotiating to agree on a 406 protocol version, the router MUST simply ignore the Serial Notify 407 PDU, even if the Serial Notify PDU is for an unexpected protocol 408 version. See Section 7 for details. 410 0 8 16 24 31 411 .-------------------------------------------. 412 | Protocol | PDU | | 413 | Version | Type | Session ID | 414 | 2 | 0 | | 415 +-------------------------------------------+ 416 | | 417 | Length=12 | 418 | | 419 +-------------------------------------------+ 420 | | 421 | Serial Number | 422 | | 423 `-------------------------------------------' 425 5.3. Serial Query 427 The router sends a Serial Query to ask the cache for all 428 announcements and withdrawals which have occurred since the Serial 429 Number specified in the Serial Query. 431 The cache replies to this query with a Cache Response PDU 432 (Section 5.5) if the cache has a (possibly null) record of the 433 changes since the Serial Number specified by the router, followed by 434 zero or more payload PDUs and an End Of Data PDU (Section 5.8). 436 When replying to a Serial Query, the cache MUST return the minimum 437 set of changes needed to bring the router into sync with the cache. 438 That is, if a particular prefix or router key underwent multiple 439 changes between the Serial Number specified by the router and the 440 cache's current Serial Number, the cache MUST merge those changes to 441 present the simplest possible view of those changes to the router. 442 In general, this means that, for any particular prefix or router key, 443 the data stream will include at most one withdrawal followed by at 444 most one announcement, and if all of the changes cancel out, the data 445 stream will not mention the prefix or router key at all. 447 The rationale for this approach is that the entire purpose of the 448 RPKI-Router protocol is to offload work from the router to the cache, 449 and it should therefore be the cache's job to simplify the change 450 set, thus reducing work for the router. 452 If the cache does not have the data needed to update the router, 453 perhaps because its records do not go back to the Serial Number in 454 the Serial Query, then it responds with a Cache Reset PDU 455 (Section 5.9). 457 The Session ID tells the cache what instance the router expects to 458 ensure that the Serial Numbers are commensurate, i.e., the cache 459 session has not been changed. 461 0 8 16 24 31 462 .-------------------------------------------. 463 | Protocol | PDU | | 464 | Version | Type | Session ID | 465 | 2 | 1 | | 466 +-------------------------------------------+ 467 | | 468 | Length=12 | 469 | | 470 +-------------------------------------------+ 471 | | 472 | Serial Number | 473 | | 474 `-------------------------------------------' 476 5.4. Reset Query 478 The router tells the cache that it wants to receive the total active, 479 current, non-withdrawn database. The cache responds with a Cache 480 Response PDU (Section 5.5), followed by zero or more payload PDUs and 481 an End of Data PDU (Section 5.8). 483 0 8 16 24 31 484 .-------------------------------------------. 485 | Protocol | PDU | | 486 | Version | Type | zero | 487 | 2 | 2 | | 488 +-------------------------------------------+ 489 | | 490 | Length=8 | 491 | | 492 `-------------------------------------------' 494 5.5. Cache Response 496 The cache responds to queries with zero or more payload PDUs. When 497 replying to a Serial Query (Section 5.3), the cache sends the set of 498 announcements and withdrawals that have occurred since the Serial 499 Number sent by the client router. When replying to a Reset Query 500 (Section 5.4), the cache sends the set of all data records it has; in 501 this case, the withdraw/announce field in the payload PDUs MUST have 502 the value 1 (announce). 504 In response to a Reset Query, the new value of the Session ID tells 505 the router the instance of the cache session for future confirmation. 506 In response to a Serial Query, the Session ID being the same 507 reassures the router that the Serial Numbers are commensurate, i.e., 508 the cache session has not been changed. 510 0 8 16 24 31 511 .-------------------------------------------. 512 | Protocol | PDU | | 513 | Version | Type | Session ID | 514 | 2 | 3 | | 515 +-------------------------------------------+ 516 | | 517 | Length=8 | 518 | | 519 `-------------------------------------------' 521 5.6. IPv4 Prefix 522 0 8 16 24 31 523 .-------------------------------------------. 524 | Protocol | PDU | | 525 | Version | Type | zero | 526 | 2 | 4 | | 527 +-------------------------------------------+ 528 | | 529 | Length=20 | 530 | | 531 +-------------------------------------------+ 532 | | Prefix | Max | | 533 | Flags | Length | Length | zero | 534 | | 0..32 | 0..32 | | 535 +-------------------------------------------+ 536 | | 537 | IPv4 Prefix | 538 | | 539 +-------------------------------------------+ 540 | | 541 | Autonomous System Number | 542 | | 543 `-------------------------------------------' 545 The lowest-order bit of the Flags field is 1 for an announcement and 546 0 for a withdrawal. 548 In the RPKI, nothing prevents a signing certificate from issuing two 549 identical ROAs. In this case, there would be no semantic difference 550 between the objects, merely a process redundancy. 552 In the RPKI, there is also an actual need for what might appear to a 553 router as identical IPvX PDUs. This can occur when an upstream 554 certificate is being reissued or there is an address ownership 555 transfer up the validation chain. The ROA would be identical in the 556 router sense, i.e., have the same {Prefix, Len, Max-Len, ASN}, but it 557 would have a different validation path in the RPKI. This is 558 important to the RPKI but not to the router. 560 The cache server MUST ensure that it has told the router client to 561 have one and only one IPvX PDU for a unique {Prefix, Len, Max-Len, 562 ASN} at any one point in time. Should the router client receive an 563 IPvX PDU with a {Prefix, Len, Max-Len, ASN} identical to one it 564 already has active, it SHOULD raise a Duplicate Announcement Received 565 error. 567 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 Number(s) | 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 zero 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. Therfore, the cache SHOULD deliver entire data of 815 an ASPA record in a single ASPA PDU. 817 The Flags field is defined as follows: 819 Bit Bit Name 820 ---- ------------------- 821 0 Announce/Withdraw (ann == 0, with == 1) 822 1 AFI (IPv4 == 0, IPv6 == 1) 823 3-7 Reserved, must be zero 825 The Provider AS Count is the number of Provider Autonomous System 826 Number(s) at the end of the PDU, and may be zero or more. 828 The Customer Autonomous System Number is the 32-bit Autonomous System 829 Number of the customer which signed the PDU. There may be only one 830 ASPA for a Customer Autonomous System Number active at any time. 832 The Provider AS Count is the number of 32-bit Provider Autonomous 833 System Numbers in the PDU. There may be none. 835 There are zero or more 32-bit Provider Autonomous System Number 836 fields; see [I-D.ietf-sidrops-aspa-profile]. 838 6. Protocol Timing Parameters 840 Since the data the cache distributes via the RPKI-Router protocol are 841 retrieved from the Global RPKI system at intervals which are only 842 known to the cache, only the cache can really know how frequently it 843 makes sense for the router to poll the cache, or how long the data 844 are likely to remain valid (or, at least, unchanged). For this 845 reason, as well as to allow the cache some control over the load 846 placed on it by its client routers, the End Of Data PDU includes 847 three values that allow the cache to communicate timing parameters to 848 the router: 850 Refresh Interval: This parameter tells the router how long to wait 851 before next attempting to poll the cache and between subsequent 852 attempts, using a Serial Query or Reset Query PDU. The router 853 SHOULD NOT poll the cache sooner than indicated by this parameter. 854 Note that receipt of a Serial Notify PDU overrides this interval 855 and suggests that the router issue an immediate query without 856 waiting for the Refresh Interval to expire. Countdown for this 857 timer starts upon receipt of the containing End Of Data PDU. 859 Minimum allowed value: 1 second. 861 Maximum allowed value: 86400 seconds (1 day). 863 Recommended default: 3600 seconds (1 hour). 865 Retry Interval: This parameter tells the router how long to wait 866 before retrying a failed Serial Query or Reset Query. The router 867 SHOULD NOT retry sooner than indicated by this parameter. Note 868 that a protocol version mismatch overrides this interval: if the 869 router needs to downgrade to a lower protocol version number, it 870 MAY send the first Serial Query or Reset Query immediately. 871 Countdown for this timer starts upon failure of the query and 872 restarts after each subsequent failure until a query succeeds. 874 Minimum allowed value: 1 second. 876 Maximum allowed value: 7200 seconds (2 hours). 878 Recommended default: 600 seconds (10 minutes). 880 Expire Interval: This parameter tells the router how long it can 881 continue to use the current version of the data while unable to 882 perform a successful subsequent query. The router MUST NOT retain 883 the data past the time indicated by this parameter. Countdown for 884 this timer starts upon receipt of the containing End Of Data PDU. 886 Minimum allowed value: 600 seconds (10 minutes). 888 Maximum allowed value: 172800 seconds (2 days). 890 Recommended default: 7200 seconds (2 hours). 892 If the router has never issued a successful query against a 893 particular cache, it SHOULD retry periodically using the default 894 Retry Interval, above. 896 Caches MUST set Expire Interval to a value larger than either Refresh 897 Interval or Retry Interval. 899 7. Protocol Version Negotiation 901 A router MUST start each transport connection by issuing either a 902 Reset Query or a Serial Query. This query will tell the cache which 903 version of this protocol the router implements. 905 If a cache which supports version 1 receives a query from a router 906 which specifies version 0, the cache MUST downgrade to protocol 907 version 0 [RFC6810] or send a version 1 Error Report PDU with Error 908 Code 4 ("Unsupported Protocol Version") and terminate the connection. 910 If a router which supports version 1 sends a query to a cache which 911 only supports version 0, one of two things will happen: 913 1. The cache may terminate the connection, perhaps with a version 0 914 Error Report PDU. In this case, the router MAY retry the 915 connection using protocol version 0. 917 2. The cache may reply with a version 0 response. In this case, the 918 router MUST either downgrade to version 0 or terminate the 919 connection. 921 In any of the downgraded combinations above, the new features of 922 version 1 will not be available, and all PDUs will have 0 in their 923 version fields. 925 If either party receives a PDU containing an unrecognized Protocol 926 Version (neither 0 nor 1) during this negotiation, it MUST either 927 downgrade to a known version or terminate the connection, with an 928 Error Report PDU unless the received PDU is itself an Error Report 929 PDU. 931 The router MUST ignore any Serial Notify PDUs it might receive from 932 the cache during this initial startup period, regardless of the 933 Protocol Version field in the Serial Notify PDU. Since Session ID 934 and Serial Number values are specific to a particular protocol 935 version, the values in the notification are not useful to the router. 936 Even if these values were meaningful, the only effect that processing 937 the notification would have would be to trigger exactly the same 938 Reset Query or Serial Query that the router has already sent as part 939 of the not-yet-complete version negotiation process, so there is 940 nothing to be gained by processing notifications until version 941 negotiation completes. 943 Caches SHOULD NOT send Serial Notify PDUs before version negotiation 944 completes. Routers, however, MUST handle such notifications (by 945 ignoring them) for backwards compatibility with caches serving 946 protocol version 0. 948 Once the cache and router have agreed upon a Protocol Version via the 949 negotiation process above, that version is stable for the life of the 950 session. See Section 5.1 for a discussion of the interaction between 951 Protocol Version and Session ID. 953 If either party receives a PDU for a different Protocol Version once 954 the above negotiation completes, that party MUST drop the session; 955 unless the PDU containing the unexpected Protocol Version was itself 956 an Error Report PDU, the party dropping the session SHOULD send an 957 Error Report with an error code of 8 ("Unexpected Protocol Version"). 959 8. Protocol Sequences 961 The sequences of PDU transmissions fall into four conversations as 962 follows: 964 8.1. Start or Restart 965 Cache Router 966 ~ ~ 967 | <----- Reset Query -------- | R requests data (or Serial Query) 968 | | 969 | ----- Cache Response -----> | C confirms request 970 | ------- Payload PDU ------> | C sends zero or more 971 | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, 972 | ------- Payload PDU ------> | or Router Key PDUs 973 | ------- End of Data ------> | C sends End of Data 974 | | and sends new serial 975 ~ ~ 977 When a transport connection is first established, the router MUST 978 send either a Reset Query or a Serial Query. A Serial Query would be 979 appropriate if the router has significant unexpired data from a 980 broken session with the same cache and remembers the Session ID of 981 that session, in which case a Serial Query containing the Session ID 982 from the previous session will allow the router to bring itself up to 983 date while ensuring that the Serial Numbers are commensurate and that 984 the router and cache are speaking compatible versions of the 985 protocol. In all other cases, the router lacks the necessary data 986 for fast resynchronization and therefore MUST fall back to a Reset 987 Query. 989 The Reset Query sequence is also used when the router receives a 990 Cache Reset, chooses a new cache, or fears that it has otherwise lost 991 its way. 993 See Section 7 for details on version negotiation. 995 To limit the length of time a cache must keep the data necessary to 996 generate incremental updates, a router MUST send either a Serial 997 Query or a Reset Query periodically. This also acts as a keep-alive 998 at the application layer. See Section 6 for details on the required 999 polling frequency. 1001 8.2. Typical Exchange 1002 Cache Router 1003 ~ ~ 1004 | -------- Notify ----------> | (optional) 1005 | | 1006 | <----- Serial Query ------- | R requests data 1007 | | 1008 | ----- Cache Response -----> | C confirms request 1009 | ------- Payload PDU ------> | C sends zero or more 1010 | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, 1011 | ------- Payload PDU ------> | or Router Key PDUs 1012 | ------- End of Data ------> | C sends End of Data 1013 | | and sends new serial 1014 ~ ~ 1016 The cache server SHOULD send a Notify PDU with its current Serial 1017 Number when the cache's serial changes, with the expectation that the 1018 router MAY then issue a Serial Query earlier than it otherwise might. 1019 This is analogous to DNS NOTIFY in [RFC1996]. The cache MUST 1020 rate-limit Serial Notifies to no more frequently than one per minute. 1022 When the transport layer is up and either a timer has gone off in the 1023 router or the cache has sent a Notify PDU, the router queries for new 1024 data by sending a Serial Query, and the cache sends all data newer 1025 than the serial in the Serial Query. 1027 To limit the length of time a cache must keep old withdraws, a router 1028 MUST send either a Serial Query or a Reset Query periodically. See 1029 Section 6 for details on the required polling frequency. 1031 8.3. No Incremental Update Available 1033 Cache Router 1034 ~ ~ 1035 | <------ Serial Query ------ | R requests data 1036 | ------- Cache Reset ------> | C cannot supply update 1037 | | from specified serial 1038 | <------ Reset Query ------- | R requests new data 1039 | ----- Cache Response -----> | C confirms request 1040 | ------- Payload PDU ------> | C sends zero or more 1041 | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, 1042 | ------- Payload PDU ------> | or Router Key PDUs 1043 | ------- End of Data ------> | C sends End of Data 1044 | | and sends new serial 1045 ~ ~ 1047 The cache may respond to a Serial Query with a Cache Reset, informing 1048 the router that the cache cannot supply an incremental update from 1049 the Serial Number specified by the router. This might be because the 1050 cache has lost state, or because the router has waited too long 1051 between polls and the cache has cleaned up old data that it no longer 1052 believes it needs, or because the cache has run out of storage space 1053 and had to expire some old data early. Regardless of how this state 1054 arose, the cache replies with a Cache Reset to tell the router that 1055 it cannot honor the request. When a router receives this, the router 1056 SHOULD attempt to connect to any more-preferred caches in its cache 1057 list. If there are no more-preferred caches, it MUST issue a Reset 1058 Query and get an entire new load from the cache. 1060 8.4. Cache Has No Data Available 1062 Cache Router 1063 ~ ~ 1064 | <------ Serial Query ------ | R requests data 1065 | ---- Error Report PDU ----> | C No Data Available 1066 ~ ~ 1068 Cache Router 1069 ~ ~ 1070 | <------ Reset Query ------- | R requests data 1071 | ---- Error Report PDU ----> | C No Data Available 1072 ~ ~ 1074 The cache may respond to either a Serial Query or a Reset Query 1075 informing the router that the cache cannot supply any update at all. 1076 The most likely cause is that the cache has lost state, perhaps due 1077 to a restart, and has not yet recovered. While it is possible that a 1078 cache might go into such a state without dropping any of its active 1079 sessions, a router is more likely to see this behavior when it 1080 initially connects and issues a Reset Query while the cache is still 1081 rebuilding its database. 1083 When a router receives this kind of error, the router SHOULD attempt 1084 to connect to any other caches in its cache list, in preference 1085 order. If no other caches are available, the router MUST issue 1086 periodic Reset Queries until it gets a new usable load from the 1087 cache. 1089 9. Transport 1091 The transport-layer session between a router and a cache carries the 1092 binary PDUs in a persistent session. 1094 To prevent cache spoofing and DoS attacks by illegitimate routers, it 1095 is highly desirable that the router and the cache be authenticated to 1096 each other. Integrity protection for payloads is also desirable to 1097 protect against monkey-in-the-middle (MITM) attacks. Unfortunately, 1098 there is no protocol to do so on all currently used platforms. 1099 Therefore, as of the writing of this document, there is no mandatory- 1100 to-implement transport which provides authentication and integrity 1101 protection. 1103 To reduce exposure to dropped but non-terminated sessions, both 1104 caches and routers SHOULD enable keep-alives when available in the 1105 chosen transport protocol. 1107 It is expected that, when the TCP Authentication Option (TCP-AO) 1108 [RFC5925] is available on all platforms deployed by operators, it 1109 will become the mandatory-to-implement transport. 1111 Caches and routers MUST implement unprotected transport over TCP 1112 using a port, rpki-rtr (323); see Section 15. Operators SHOULD use 1113 procedural means, e.g., access control lists (ACLs), to reduce the 1114 exposure to authentication issues. 1116 If unprotected TCP is the transport, the cache and routers MUST be on 1117 the same trusted and controlled network. 1119 If available to the operator, caches and routers MUST use one of the 1120 following more protected protocols: 1122 o Caches and routers SHOULD use TCP-AO transport [RFC5925] over the 1123 rpki-rtr port. 1125 o Caches and routers MAY use Secure Shell version 2 (SSHv2) 1126 transport [RFC4252] using the normal SSH port. For an example, 1127 see Section 9.1. 1129 o Caches and routers MAY use TCP MD5 transport [RFC2385] using the 1130 rpki-rtr port. Note that TCP MD5 has been obsoleted by TCP-AO 1131 [RFC5925]. 1133 o Caches and routers MAY use TCP over IPsec transport [RFC4301] 1134 using the rpki-rtr port. 1136 o Caches and routers MAY use Transport Layer Security (TLS) 1137 transport [RFC5246] using port rpki-rtr-tls (324); see Section 15. 1139 9.1. SSH Transport 1141 To run over SSH, the client router first establishes an SSH transport 1142 connection using the SSHv2 transport protocol, and the client and 1143 server exchange keys for message integrity and encryption. The 1144 client then invokes the "ssh-userauth" service to authenticate the 1145 application, as described in the SSH authentication protocol 1147 [RFC4252]. Once the application has been successfully authenticated, 1148 the client invokes the "ssh-connection" service, also known as the 1149 SSH connection protocol. 1151 After the ssh-connection service is established, the client opens a 1152 channel of type "session", which results in an SSH session. 1154 Once the SSH session has been established, the application invokes 1155 the application transport as an SSH subsystem called "rpki-rtr". 1156 Subsystem support is a feature of SSHv2 and is not included in SSHv1. 1157 Running this protocol as an SSH subsystem avoids the need for the 1158 application to recognize shell prompts or skip over extraneous 1159 information, such as a system message that is sent at shell startup. 1161 It is assumed that the router and cache have exchanged keys out of 1162 band by some reasonably secured means. 1164 Cache servers supporting SSH transport MUST accept RSA authentication 1165 and SHOULD accept Elliptic Curve Digital Signature Algorithm (ECDSA) 1166 authentication. User authentication MUST be supported; host 1167 authentication MAY be supported. Implementations MAY support 1168 password authentication. Client routers SHOULD verify the public key 1169 of the cache to avoid MITM attacks. 1171 9.2. TLS Transport 1173 Client routers using TLS transport MUST present client-side 1174 certificates to authenticate themselves to the cache in order to 1175 allow the cache to manage the load by rejecting connections from 1176 unauthorized routers. In principle, any type of certificate and 1177 Certification Authority (CA) may be used; however, in general, cache 1178 operators will wish to create their own small-scale CA and issue 1179 certificates to each authorized router. This simplifies credential 1180 rollover; any unrevoked, unexpired certificate from the proper CA may 1181 be used. 1183 Certificates used to authenticate client routers in this protocol 1184 MUST include a subjectAltName extension [RFC5280] containing one or 1185 more iPAddress identities; when authenticating the router's 1186 certificate, the cache MUST check the IP address of the TLS 1187 connection against these iPAddress identities and SHOULD reject the 1188 connection if none of the iPAddress identities match the connection. 1190 Routers MUST also verify the cache's TLS server certificate, using 1191 subjectAltName dNSName identities as described in [RFC6125], to avoid 1192 MITM attacks. The rules and guidelines defined in [RFC6125] apply 1193 here, with the following considerations: 1195 o Support for the DNS-ID identifier type (that is, the dNSName 1196 identity in the subjectAltName extension) is REQUIRED in rpki-rtr 1197 server and client implementations which use TLS. Certification 1198 authorities which issue rpki-rtr server certificates MUST support 1199 the DNS-ID identifier type, and the DNS-ID identifier type MUST be 1200 present in rpki-rtr server certificates. 1202 o DNS names in rpki-rtr server certificates SHOULD NOT contain the 1203 wildcard character "*". 1205 o rpki-rtr implementations which use TLS MUST NOT use Common Name 1206 (CN-ID) identifiers; a CN field may be present in the server 1207 certificate's subject name but MUST NOT be used for authentication 1208 within the rules described in [RFC6125]. 1210 o The client router MUST set its "reference identifier" to the DNS 1211 name of the rpki-rtr cache. 1213 9.3. TCP MD5 Transport 1215 If TCP MD5 is used, implementations MUST support key lengths of at 1216 least 80 printable ASCII bytes, per Section 4.5 of [RFC2385]. 1217 Implementations MUST also support hexadecimal sequences of at least 1218 32 characters, i.e., 128 bits. 1220 Key rollover with TCP MD5 is problematic. Cache servers SHOULD 1221 support [RFC4808]. 1223 9.4. TCP-AO Transport 1225 Implementations MUST support key lengths of at least 80 printable 1226 ASCII bytes. Implementations MUST also support hexadecimal sequences 1227 of at least 32 characters, i.e., 128 bits. Message Authentication 1228 Code (MAC) lengths of at least 96 bits MUST be supported, per 1229 Section 5.1 of [RFC5925]. 1231 The cryptographic algorithms and associated parameters described in 1232 [RFC5926] MUST be supported. 1234 10. Router-Cache Setup 1236 A cache has the public authentication data for each router it is 1237 configured to support. 1239 A router may be configured to peer with a selection of caches, and a 1240 cache may be configured to support a selection of routers. Each must 1241 have the name of, and authentication data for, each peer. In 1242 addition, in a router, this list has a non-unique preference value 1243 for each server. This preference merely denotes proximity, not 1244 trust, preferred belief, et cetera. The client router attempts to 1245 establish a session with each potential serving cache in preference 1246 order and then starts to load data from the most preferred cache to 1247 which it can connect and authenticate. The router's list of caches 1248 has the following elements: 1250 Preference: An unsigned integer denoting the router's preference to 1251 connect to that cache; the lower the value, the more preferred. 1253 Name: The IP address or fully qualified domain name of the cache. 1255 Cache Credential(s): Any credential (such as a public key) needed to 1256 authenticate the cache's identity to the router. 1258 Router Credential(s): Any credential (such as a private key or 1259 certificate) needed to authenticate the router's identity to the 1260 cache. 1262 Due to the distributed nature of the RPKI, caches simply cannot be 1263 rigorously synchronous. A client may hold data from multiple caches 1264 but MUST keep the data marked as to source, as later updates MUST 1265 affect the correct data. 1267 Just as there may be more than one covering ROA from a single cache, 1268 there may be multiple covering ROAs from multiple caches. The 1269 results are as described in [RFC6811]. 1271 If data from multiple caches are held, implementations MUST NOT 1272 distinguish between data sources when performing validation of BGP 1273 announcements. 1275 When a more-preferred cache becomes available, if resources allow, it 1276 would be prudent for the client to start fetching from that cache. 1278 The client SHOULD attempt to maintain at least one set of data, 1279 regardless of whether it has chosen a different cache or established 1280 a new connection to the previous cache. 1282 A client MAY drop the data from a particular cache when it is fully 1283 in sync with one or more other caches. 1285 See Section 6 for details on what to do when the client is not able 1286 to refresh from a particular cache. 1288 If a client loses connectivity to a cache it is using or otherwise 1289 decides to switch to a new cache, it SHOULD retain the data from the 1290 previous cache until it has a full set of data from one or more other 1291 caches. Note that this may already be true at the point of 1292 connection loss if the client has connections to more than one cache. 1294 11. ROA PDU Race Minimization 1296 When a cache is sending ROA PDUs to the router, especially during an 1297 initial full load, two undesirable race conditions are possible: 1299 Break Before Make: For some prefix P, an AS may announce two (or 1300 more) ROAs because they are in the process of changing what 1301 provider AS is announcing P. This is is a case of "make before 1302 break." If a cache is feeding a router and sends the one not yet 1303 in service a significant time before sending the one currently in 1304 service, then BGP data could be marked invalid during the 1305 interval. To minimize that interval, the cache SHOULD announce 1306 all ROAs for the same prefix as close to sequentially as possible. 1308 Shorter Prefix First: If an AS has issued a ROA for P0, and another 1309 AS (likely their customer) has issued a ROA for P1 which is a sub- 1310 prefix of P0, a router which receives the ROA for P0 before that 1311 for P1 is likely to mark a BGP prefix P1 invalid. Therefore, the 1312 cache SHOULD announce the sub-prefix P1 before the covering prefix 1313 P0. 1315 12. Deployment Scenarios 1317 For illustration, we present three likely deployment scenarios: 1319 Small End Site: The small multihomed end site may wish to outsource 1320 the RPKI cache to one or more of their upstream ISPs. They would 1321 exchange authentication material with the ISP using some out-of- 1322 band mechanism, and their router(s) would connect to the cache(s) 1323 of one or more upstream ISPs. The ISPs would likely deploy caches 1324 intended for customer use separately from the caches with which 1325 their own BGP speakers peer. 1327 Large End Site: A larger multihomed end site might run one or more 1328 caches, arranging them in a hierarchy of client caches, each 1329 fetching from a serving cache which is closer to the Global RPKI. 1330 They might configure fallback peerings to upstream ISP caches. 1332 ISP Backbone: A large ISP would likely have one or more redundant 1333 caches in each major point of presence (PoP), and these caches 1334 would fetch from each other in an ISP-dependent topology so as not 1335 to place undue load on the Global RPKI. 1337 Experience with large DNS cache deployments has shown that complex 1338 topologies are ill-advised, as it is easy to make errors in the 1339 graph, e.g., not maintain a loop-free condition. 1341 Of course, these are illustrations, and there are other possible 1342 deployment strategies. It is expected that minimizing load on the 1343 Global RPKI servers will be a major consideration. 1345 To keep load on Global RPKI services from unnecessary peaks, it is 1346 recommended that primary caches which load from the distributed 1347 Global RPKI not do so all at the same times, e.g., on the hour. 1348 Choose a random time, perhaps the ISP's AS number modulo 60, and 1349 jitter the inter-fetch timing. 1351 13. Error Codes 1353 This section contains a preliminary list of error codes. The authors 1354 expect additions to the list during development of the initial 1355 implementations. There is an IANA registry where valid error codes 1356 are listed; see Section 15. Errors which are considered fatal MUST 1357 cause the session to be dropped. 1359 0: Corrupt Data (fatal): The receiver believes the received PDU to 1360 be corrupt in a manner not specified by another error code. 1362 1: Internal Error (fatal): The party reporting the error experienced 1363 some kind of internal error unrelated to protocol operation (ran 1364 out of memory, a coding assertion failed, et cetera). 1366 2: No Data Available: The cache believes itself to be in good 1367 working order but is unable to answer either a Serial Query or a 1368 Reset Query because it has no useful data available at this time. 1369 This is likely to be a temporary error and most likely indicates 1370 that the cache has not yet completed pulling down an initial 1371 current data set from the Global RPKI system after some kind of 1372 event that invalidated whatever data it might have previously held 1373 (reboot, network partition, et cetera). 1375 3: Invalid Request (fatal): The cache server believes the client's 1376 request to be invalid. 1378 4: Unsupported Protocol Version (fatal): The Protocol Version is not 1379 known by the receiver of the PDU. 1381 5: Unsupported PDU Type (fatal): The PDU Type is not known by the 1382 receiver of the PDU. 1384 6: Withdrawal of Unknown Record (fatal): The received PDU has 1385 Flag=0, but a matching record ({Prefix, Len, Max-Len, ASN} tuple 1386 for an IPvX PDU or {SKI, ASN, Subject Public Key} tuple for a 1387 Router Key PDU) does not exist in the receiver's database. 1389 7: Duplicate Announcement Received (fatal): The received PDU has 1390 Flag=1, but a matching record ({Prefix, Len, Max-Len, ASN} tuple 1391 for an IPvX PDU or {SKI, ASN, Subject Public Key} tuple for a 1392 Router Key PDU) is already active in the router. 1394 8: Unexpected Protocol Version (fatal): The received PDU has a 1395 Protocol Version field that differs from the protocol version 1396 negotiated in Section 7. 1398 14. Security Considerations 1400 As this document describes a security protocol, many aspects of 1401 security interest are described in the relevant sections. This 1402 section points out issues which may not be obvious in other sections. 1404 Cache Validation: In order for a collection of caches as described 1405 in Section 12 to guarantee a consistent view, they need to be 1406 given consistent trust anchors to use in their internal validation 1407 process. Distribution of a consistent trust anchor is assumed to 1408 be out of band. 1410 Cache Peer Identification: The router initiates a transport 1411 connection to a cache, which it identifies by either IP address or 1412 fully qualified domain name. Be aware that a DNS or address 1413 spoofing attack could make the correct cache unreachable. No 1414 session would be established, as the authorization keys would not 1415 match. 1417 Transport Security: The RPKI relies on object, not server or 1418 transport, trust. That is, the IANA root trust anchor is 1419 distributed to all caches through some out-of-band means and can 1420 then be used by each cache to validate certificates and ROAs all 1421 the way down the tree. The inter-cache relationships are based on 1422 this object security model; hence, the inter-cache transport can 1423 be lightly protected. 1425 However, this protocol document assumes that the routers cannot do 1426 the validation cryptography. Hence, the last link, from cache to 1427 router, is secured by server authentication and transport-level 1428 security. This is dangerous, as server authentication and 1429 transport have very different threat models than object security. 1431 So the strength of the trust relationship and the transport 1432 between the router(s) and the cache(s) are critical. You're 1433 betting your routing on this. 1435 While we cannot say the cache must be on the same LAN, if only due 1436 to the issue of an enterprise wanting to offload the cache task to 1437 their upstream ISP(s), locality, trust, and control are very 1438 critical issues here. The cache(s) really SHOULD be as close, in 1439 the sense of controlled and protected (against DDoS, MITM) 1440 transport, to the router(s) as possible. It also SHOULD be 1441 topologically close so that a minimum of validated routing data 1442 are needed to bootstrap a router's access to a cache. 1444 The identity of the cache server SHOULD be verified and 1445 authenticated by the router client, and vice versa, before any 1446 data are exchanged. 1448 Transports which cannot provide the necessary authentication and 1449 integrity (see Section 9) must rely on network design and 1450 operational controls to provide protection against spoofing/ 1451 corruption attacks. As pointed out in Section 9, TCP-AO is the 1452 long-term plan. Protocols which provide integrity and 1453 authenticity SHOULD be used, and if they cannot, i.e., TCP is used 1454 as the transport, the router and cache MUST be on the same 1455 trusted, controlled network. 1457 15. IANA Considerations 1459 This section only discusses updates required in the existing IANA 1460 protocol registries to accommodate version 1 of this protocol. See 1461 [RFC6810] for IANA considerations from the original (version 0) 1462 protocol. 1464 All existing entries in the IANA "rpki-rtr-pdu" registry remain valid 1465 for protocol version 0. All of the PDU types allowed in protocol 1466 version 0 are also allowed in protocol version 1, with the addition 1467 of the new Router Key PDU. To reduce the likelihood of confusion, 1468 the PDU number used by the Router Key PDU in protocol version 1 is 1469 hereby registered as reserved (and unused) in protocol version 0. 1471 The policy for adding to the registry is RFC Required per [RFC8126]; 1472 the document must be either Standards Track or Experimental. 1474 The "rpki-rtr-pdu" registry has been updated as follows: 1476 Protocol PDU 1477 Version Type Description 1478 -------- ---- --------------- 1479 0-2 0 Serial Notify 1480 0-2 1 Serial Query 1481 0-2 2 Reset Query 1482 0-2 3 Cache Response 1483 0-2 4 IPv4 Prefix 1484 0-2 6 IPv6 Prefix 1485 0-2 7 End of Data 1486 0-2 8 Cache Reset 1487 0 9 Reserved 1488 1-2 9 Router Key 1489 0-2 10 Error Report 1490 0-1 11 Reserved 1491 2 11 ASPA 1492 0-2 255 Reserved 1494 All previous entries in the IANA "rpki-rtr-error" registry remain 1495 valid for all protocol versions. Protocol version 1 added one new 1496 error code: 1498 Error 1499 Code Description 1500 ----- --------------------------- 1501 8 Unexpected Protocol Version 1503 16. References 1505 16.1. Normative References 1507 [I-D.ietf-sidrops-aspa-profile] 1508 Azimov, A., Uskov, E., Bush, R., Patel, K., Snijders, J., 1509 and R. Housley, "A Profile for Autonomous System Provider 1510 Authorization", draft-ietf-sidrops-aspa-profile-02 (work 1511 in progress), March 2020. 1513 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 1514 DOI 10.17487/RFC1982, August 1996, 1515 . 1517 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1518 Requirement Levels", BCP 14, RFC 2119, 1519 DOI 10.17487/RFC2119, March 1997, 1520 . 1522 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1523 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 1524 1998, . 1526 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1527 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1528 2003, . 1530 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 1531 Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, 1532 January 2006, . 1534 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1535 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1536 December 2005, . 1538 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1539 (TLS) Protocol Version 1.2", RFC 5246, 1540 DOI 10.17487/RFC5246, August 2008, 1541 . 1543 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1544 Housley, R., and W. Polk, "Internet X.509 Public Key 1545 Infrastructure Certificate and Certificate Revocation List 1546 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1547 . 1549 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1550 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1551 June 2010, . 1553 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 1554 for the TCP Authentication Option (TCP-AO)", RFC 5926, 1555 DOI 10.17487/RFC5926, June 2010, 1556 . 1558 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1559 Verification of Domain-Based Application Service Identity 1560 within Internet Public Key Infrastructure Using X.509 1561 (PKIX) Certificates in the Context of Transport Layer 1562 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1563 2011, . 1565 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 1566 X.509 PKIX Resource Certificates", RFC 6487, 1567 DOI 10.17487/RFC6487, February 2012, 1568 . 1570 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 1571 Infrastructure (RPKI) to Router Protocol", RFC 6810, 1572 DOI 10.17487/RFC6810, January 2013, 1573 . 1575 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 1576 Austein, "BGP Prefix Origin Validation", RFC 6811, 1577 DOI 10.17487/RFC6811, January 2013, 1578 . 1580 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1581 Writing an IANA Considerations Section in RFCs", BCP 26, 1582 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1583 . 1585 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1586 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1587 May 2017, . 1589 [RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key 1590 Formats, and Signature Formats", RFC 8208, 1591 DOI 10.17487/RFC8208, September 2017, 1592 . 1594 16.2. Informative References 1596 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 1597 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 1598 August 1996, . 1600 [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", 1601 RFC 4808, DOI 10.17487/RFC4808, March 2007, 1602 . 1604 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 1605 Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, 1606 . 1608 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 1609 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 1610 February 2012, . 1612 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 1613 Resource Certificate Repository Structure", RFC 6481, 1614 DOI 10.17487/RFC6481, February 2012, 1615 . 1617 Acknowledgements 1619 The authors wish to thank Nils Bars, Steve Bellovin, Tim Bruijnzeels, 1620 Rex Fernando, Richard Hansen, Martin Hoffmann, Paul Hoffman, Fabian 1621 Holler, Russ Housley, Pradosh Mohapatra, Keyur Patel, David 1622 Mandelberg, Sandy Murphy, Robert Raszuk, Andreas Reuter, Thomas C. 1623 Schmidt, John Scudder, Ruediger Volk, Matthias Waehlisch, and David 1624 Ward. Particular thanks go to Hannes Gredler for showing us the 1625 dangers of unnecessary fields. 1627 No doubt this list is incomplete. We apologize to any contributor 1628 whose name we missed. 1630 Authors' Addresses 1632 Randy Bush 1633 IIJ & Arrcus 1634 5147 Crystal Springs 1635 Bainbridge Island, Washington 98110 1636 United States of America 1638 Email: randy@psg.com 1640 Rob Austein 1641 Dragon Research Labs 1643 Email: sra@hactrn.net