idnits 2.17.1 draft-ietf-sidrops-8210bis-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (15 February 2022) is 800 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-17) exists of draft-ietf-sidrops-aspa-profile-07 ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 8208 (Obsoleted by RFC 8608) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Bush 3 Internet-Draft IIJ, Arrcus, & DRL 4 Obsoletes: 8210 (if approved) R. Austein 5 Intended status: Standards Track Dragon Research Labs 6 Expires: 19 August 2022 15 February 2022 8 The Resource Public Key Infrastructure (RPKI) to Router Protocol, 9 Version 2 10 draft-ietf-sidrops-8210bis-06 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 obsoletes and replaces 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 19 August 2022. 41 Copyright Notice 43 Copyright (c) 2022 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 1.2. Changes from RFC 8210 . . . . . . . . . . . . . . . . . . 3 60 2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Deployment Structure . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 10 67 5.4. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 11 68 5.5. Cache Response . . . . . . . . . . . . . . . . . . . . . 11 69 5.6. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 12 70 5.7. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 13 71 5.8. End of Data . . . . . . . . . . . . . . . . . . . . . . . 14 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 0 for IPv4 and 1 346 for IPv6. 348 The next lowest bit is 1 for an announcement and 0 for a 349 withdrawal. For a Prefix PDU (IPv4 or IPv6), the announce/ 350 withdraw flag indicates whether this PDU announces a new right to 351 announce the prefix or withdraws a previously announced right; a 352 withdraw effectively deletes one previously announced Prefix PDU 353 with the exact same Prefix, Length, Max-Len, and Autonomous System 354 Number (ASN). 356 Similarly, for a Router Key PDU, the flag indicates whether this 357 PDU announces a new Router Key or deletes one previously announced 358 Router Key PDU with the exact same AS Number, 359 subjectKeyIdentifier, and subjectPublicKeyInfo. 361 For the ASPA PDU, the announce/withdraw Flag is set to 1 to 362 indicate either the announcement of a new ASPA record or a 363 replacement for a previously announced record with the same 364 Customer Autonomous System Number. The announce/withdraw flag set 365 to 0 indicates removal of the ASPA record in total. Here, only 366 the customer AS of the ASPA record MUST be provided, the Provider 367 AS Count as well as the Provider AS Numbers list MUST BE zero. 369 The remaining bits in the Flags field are reserved for future use. 370 In protocol version 2, they MUST be zero on transmission and MUST 371 be ignored on receipt. 373 Prefix Length: An 8-bit unsigned integer denoting the shortest 374 prefix allowed by the Prefix element. 376 Max Length: An 8-bit unsigned integer denoting the longest prefix 377 allowed by the Prefix element. This MUST NOT be less than the 378 Prefix Length element. 380 Prefix: The IPv4 or IPv6 prefix of the ROA. 382 Autonomous System Number: A 32-bit unsigned integer representing an 383 ASN allowed to announce a prefix or associated with a router key. 385 Subject Key Identifier: 20-octet Subject Key Identifier (SKI) value 386 of a router key, as described in [RFC6487]. 388 Subject Public Key Info: A router key's subjectPublicKeyInfo value, 389 as described in [RFC8208]. This is the full ASN.1 DER encoding of 390 the subjectPublicKeyInfo, including the ASN.1 tag and length 391 values of the subjectPublicKeyInfo SEQUENCE. 393 Refresh Interval: Interval between normal cache polls. See 394 Section 6. 396 Retry Interval: Interval between cache poll retries after a failed 397 cache poll. See Section 6. 399 Expire Interval: Interval during which data fetched from a cache 400 remains valid in the absence of a successful subsequent cache 401 poll. See Section 6. 403 5.2. Serial Notify 405 The cache notifies the router that the cache has new data. 407 The Session ID reassures the router that the Serial Numbers are 408 commensurate, i.e., the cache session has not been changed. 410 Upon receipt of a Serial Notify PDU, the router MAY issue an 411 immediate Serial Query (Section 5.3) or Reset Query (Section 5.4) 412 without waiting for the Refresh Interval timer (see Section 6) to 413 expire. 415 Serial Notify is the only message that the cache can send that is not 416 in response to a message from the router. 418 If the router receives a Serial Notify PDU during the initial startup 419 period where the router and cache are still negotiating to agree on a 420 protocol version, the router MUST simply ignore the Serial Notify 421 PDU, even if the Serial Notify PDU is for an unexpected protocol 422 version. See Section 7 for details. 424 0 8 16 24 31 425 .-------------------------------------------. 426 | Protocol | PDU | | 427 | Version | Type | Session ID | 428 | 2 | 0 | | 429 +-------------------------------------------+ 430 | | 431 | Length=12 | 432 | | 433 +-------------------------------------------+ 434 | | 435 | Serial Number | 436 | | 437 `-------------------------------------------' 439 5.3. Serial Query 441 The router sends a Serial Query to ask the cache for all 442 announcements and withdrawals which have occurred since the Serial 443 Number specified in the Serial Query. 445 The cache replies to this query with a Cache Response PDU 446 (Section 5.5) if the cache has a (possibly null) record of the 447 changes since the Serial Number specified by the router, followed by 448 zero or more payload PDUs and an End Of Data PDU (Section 5.8). 450 When replying to a Serial Query, the cache MUST return the minimum 451 set of changes needed to bring the router into sync with the cache. 452 That is, if a particular prefix or router key underwent multiple 453 changes between the Serial Number specified by the router and the 454 cache's current Serial Number, the cache MUST merge those changes to 455 present the simplest possible view of those changes to the router. 456 In general, this means that, for any particular prefix or router key, 457 the data stream will include at most one withdrawal followed by at 458 most one announcement, and if all of the changes cancel out, the data 459 stream will not mention the prefix or router key at all. 461 The rationale for this approach is that the entire purpose of the 462 RPKI-Router protocol is to offload work from the router to the cache, 463 and it should therefore be the cache's job to simplify the change 464 set, thus reducing work for the router. 466 If the cache does not have the data needed to update the router, 467 perhaps because its records do not go back to the Serial Number in 468 the Serial Query, then it responds with a Cache Reset PDU 469 (Section 5.9). 471 The Session ID tells the cache what instance the router expects to 472 ensure that the Serial Numbers are commensurate, i.e., the cache 473 session has not been changed. 475 0 8 16 24 31 476 .-------------------------------------------. 477 | Protocol | PDU | | 478 | Version | Type | Session ID | 479 | 2 | 1 | | 480 +-------------------------------------------+ 481 | | 482 | Length=12 | 483 | | 484 +-------------------------------------------+ 485 | | 486 | Serial Number | 487 | | 488 `-------------------------------------------' 490 5.4. Reset Query 492 The router tells the cache that it wants to receive the total active, 493 current, non-withdrawn database. The cache responds with a Cache 494 Response PDU (Section 5.5), followed by zero or more payload PDUs and 495 an End of Data PDU (Section 5.8). 497 0 8 16 24 31 498 .-------------------------------------------. 499 | Protocol | PDU | | 500 | Version | Type | zero | 501 | 2 | 2 | | 502 +-------------------------------------------+ 503 | | 504 | Length=8 | 505 | | 506 `-------------------------------------------' 508 5.5. Cache Response 510 The cache responds to queries with zero or more payload PDUs. When 511 replying to a Serial Query (Section 5.3), the cache sends the set of 512 announcements and withdrawals that have occurred since the Serial 513 Number sent by the client router. When replying to a Reset Query 514 (Section 5.4), the cache sends the set of all data records it has; in 515 this case, the withdraw/announce field in the payload PDUs MUST have 516 the value 1 (announce). 518 In response to a Reset Query, the new value of the Session ID tells 519 the router the instance of the cache session for future confirmation. 520 In response to a Serial Query, the Session ID being the same 521 reassures the router that the Serial Numbers are commensurate, i.e., 522 the cache session has not been changed. 524 0 8 16 24 31 525 .-------------------------------------------. 526 | Protocol | PDU | | 527 | Version | Type | Session ID | 528 | 2 | 3 | | 529 +-------------------------------------------+ 530 | | 531 | Length=8 | 532 | | 533 `-------------------------------------------' 535 5.6. IPv4 Prefix 537 0 8 16 24 31 538 .-------------------------------------------. 539 | Protocol | PDU | | 540 | Version | Type | zero | 541 | 2 | 4 | | 542 +-------------------------------------------+ 543 | | 544 | Length=20 | 545 | | 546 +-------------------------------------------+ 547 | | Prefix | Max | | 548 | Flags | Length | Length | zero | 549 | | 0..32 | 0..32 | | 550 +-------------------------------------------+ 551 | | 552 | IPv4 Prefix | 553 | | 554 +-------------------------------------------+ 555 | | 556 | Autonomous System Number | 557 | | 558 `-------------------------------------------' 560 The lowest-order bit of the Flags field is 1 for an announcement and 561 0 for a withdrawal. 563 In the RPKI, nothing prevents a signing certificate from issuing two 564 identical ROAs. In this case, there would be no semantic difference 565 between the objects, merely a process redundancy. 567 In the RPKI, there is also an actual need for what might appear to a 568 router as identical IPvX PDUs. This can occur when an upstream 569 certificate is being reissued or there is an address ownership 570 transfer up the validation chain. The ROA would be identical in the 571 router sense, i.e., have the same {Prefix, Len, Max-Len, ASN}, but it 572 would have a different validation path in the RPKI. This is 573 important to the RPKI but not to the router. 575 The cache server MUST ensure that it has told the router client to 576 have one and only one IPvX PDU for a unique {Prefix, Len, Max-Len, 577 ASN} at any one point in time. Should the router client receive an 578 IPvX PDU with a {Prefix, Len, Max-Len, ASN} identical to one it 579 already has active, it SHOULD raise a Duplicate Announcement Received 580 error. 582 5.7. IPv6 Prefix 584 0 8 16 24 31 585 .-------------------------------------------. 586 | Protocol | PDU | | 587 | Version | Type | zero | 588 | 2 | 6 | | 589 +-------------------------------------------+ 590 | | 591 | Length=32 | 592 | | 593 +-------------------------------------------+ 594 | | Prefix | Max | | 595 | Flags | Length | Length | zero | 596 | | 0..128 | 0..128 | | 597 +-------------------------------------------+ 598 | | 599 +--- ---+ 600 | | 601 +--- IPv6 Prefix ---+ 602 | | 603 +--- ---+ 604 | | 605 +-------------------------------------------+ 606 | | 607 | Autonomous System Number | 608 | | 609 `-------------------------------------------' 611 Analogous to the IPv4 Prefix PDU, it has 96 more bits and no magic. 613 5.8. End of Data 615 The cache tells the router it has no more data for the request. 617 The Session ID and Protocol Version MUST be the same as that of the 618 corresponding Cache Response which began the (possibly null) sequence 619 of payload PDUs. 621 0 8 16 24 31 622 .-------------------------------------------. 623 | Protocol | PDU | | 624 | Version | Type | Session ID | 625 | 2 | 7 | | 626 +-------------------------------------------+ 627 | | 628 | Length=24 | 629 | | 630 +-------------------------------------------+ 631 | | 632 | Serial Number | 633 | | 634 +-------------------------------------------+ 635 | | 636 | Refresh Interval | 637 | | 638 +-------------------------------------------+ 639 | | 640 | Retry Interval | 641 | | 642 +-------------------------------------------+ 643 | | 644 | Expire Interval | 645 | | 646 `-------------------------------------------' 648 The Refresh Interval, Retry Interval, and Expire Interval are all 649 32-bit elapsed times measured in seconds. They express the timing 650 parameters which the cache expects the router to use in deciding when 651 to send subsequent Serial Query or Reset Query PDUs to the cache. 652 See Section 6 for an explanation of the use and the range of allowed 653 values for these parameters. 655 Note that the End of Data PDU changed significantly between versions 656 0 and 1. For version 0 compatibility, the following is the version 0 657 End of Data PDU. 659 0 8 16 24 31 660 .-------------------------------------------. 661 | Protocol | PDU | | 662 | Version | Type | Cache Nonce | 663 | 0 | 7 | | 664 +-------------------------------------------+ 665 | | 666 | Length=12 | 667 | | 668 +-------------------------------------------+ 669 | | 670 | Serial Number | 671 | | 672 `-------------------------------------------' 674 5.9. Cache Reset 676 The cache may respond to a Serial Query informing the router that the 677 cache cannot provide an incremental update starting from the Serial 678 Number specified by the router. The router must decide whether to 679 issue a Reset Query or switch to a different cache. 681 0 8 16 24 31 682 .-------------------------------------------. 683 | Protocol | PDU | | 684 | Version | Type | zero | 685 | 2 | 8 | | 686 +-------------------------------------------+ 687 | | 688 | Length=8 | 689 | | 690 `-------------------------------------------' 692 5.10. Router Key 693 0 8 16 24 31 694 .-------------------------------------------. 695 | Protocol | PDU | | | 696 | Version | Type | Flags | zero | 697 | 2 | 9 | | | 698 +-------------------------------------------+ 699 | | 700 | Length | 701 | | 702 +-------------------------------------------+ 703 | | 704 +--- ---+ 705 | Subject Key Identifier | 706 +--- ---+ 707 | | 708 +--- ---+ 709 | (20 octets) | 710 +--- ---+ 711 | | 712 +-------------------------------------------+ 713 | | 714 | AS Number | 715 | | 716 +-------------------------------------------+ 717 | | 718 | Subject Public Key Info | 719 | | 720 `-------------------------------------------' 722 The lowest-order bit of the Flags field is 1 for an announcement and 723 0 for a withdrawal. 725 The cache server MUST ensure that it has told the router client to 726 have one and only one Router Key PDU for a unique {SKI, ASN, Subject 727 Public Key} at any one point in time. Should the router client 728 receive a Router Key PDU with a {SKI, ASN, Subject Public Key} 729 identical to one it already has active, it SHOULD raise a Duplicate 730 Announcement Received error. 732 Note that a particular ASN may appear in multiple Router Key PDUs 733 with different Subject Public Key values, while a particular Subject 734 Public Key value may appear in multiple Router Key PDUs with 735 different ASNs. In the interest of keeping the announcement and 736 withdrawal semantics as simple as possible for the router, this 737 protocol makes no attempt to compress either of these cases. 739 Also note that it is possible, albeit very unlikely, for multiple 740 distinct Subject Public Key values to hash to the same SKI. For this 741 reason, implementations MUST compare Subject Public Key values as 742 well as SKIs when detecting duplicate PDUs. 744 5.11. Error Report 746 This PDU is used by either party to report an error to the other. 748 Error reports are only sent as responses to other PDUs, not to report 749 errors in Error Report PDUs. 751 Error codes are described in Section 13. 753 If the error is generic (e.g., "Internal Error") and not associated 754 with the PDU to which it is responding, the Erroneous PDU field MUST 755 be empty and the Length of Encapsulated PDU field MUST be zero. 757 An Error Report PDU MUST NOT be sent for an Error Report PDU. If an 758 erroneous Error Report PDU is received, the session SHOULD be 759 dropped. 761 If the error is associated with a PDU of excessive length, i.e., too 762 long to be any legal PDU other than another Error Report, or a 763 possibly corrupt length, the Erroneous PDU field MAY be truncated. 765 The diagnostic text is optional; if not present, the Length of Error 766 Text field MUST be zero. If error text is present, it MUST be a 767 string in UTF-8 encoding (see [RFC3629]). 769 0 8 16 24 31 770 .-------------------------------------------. 771 | Protocol | PDU | | 772 | Version | Type | Error Code | 773 | 2 | 10 | | 774 +-------------------------------------------+ 775 | | 776 | Length | 777 | | 778 +-------------------------------------------+ 779 | | 780 | Length of Encapsulated PDU | 781 | | 782 +-------------------------------------------+ 783 | | 784 ~ Erroneous PDU ~ 785 | | 786 +-------------------------------------------+ 787 | | 788 | Length of Error Text | 789 | | 790 +-------------------------------------------+ 791 | | 792 | Arbitrary Text | 793 | of | 794 ~ Error Diagnostic Message ~ 795 | | 796 `-------------------------------------------' 798 5.12. ASPA PDU 799 0 8 16 24 31 800 .-------------------------------------------. 801 | Protocol | PDU | | 802 | Version | Type | zero | 803 | 2 | 11 | | 804 +-------------------------------------------+ 805 | | 806 | Length | 807 | | 808 +-------------------------------------------+ 809 | | | | 810 | Flags | zero | Provider AS Count | 811 | | | | 812 +-------------------------------------------+ 813 | | 814 | Customer Autonomous System Number | 815 | | 816 +-------------------------------------------+ 817 | | 818 | Provider Autonomous System Numbers | 819 | | 820 ~-------------------------------------------~ 822 The ASPA PDU is to support [I-D.ietf-sidrops-aspa-profile]. An ASPA 823 PDU represents one single customer AS and its provider ASs for a 824 particular Address Family. Receipt of an ASPA PDU announcement 825 (Flag.Announce == 1) when the router already has an ASPA PDU with the 826 same Customer Autonomous System Number and the same Address Family 827 (see Flags field), replaces the previous one. This is to avoid a 828 race condition when a BGP announcement is received between an 829 withdrawn PDU and a new announced PDU. Therefore, the cache MUST 830 deliver the complete data of an ASPA record in a single ASPA PDU. 832 The router should see at most one ASPA from a cache for a particular 833 Customer Autonomous System Number active at any time. As a number of 834 conditions in the global RPKI may present multiple valid ASPA objects 835 for a single customer to a particular RP cache, this places a burden 836 on the cache to form the union of multiple ASPA records it has 837 received from the global RPKI into one ASPA PDU. 839 The Flags field is defined as follows: 841 Bit Bit Name 842 ---- ------------------- 843 0 AFI (IPv4 == 0, IPv6 == 1) 844 1 Announce == 1, Delete == 0 845 2-7 Reserved, must be zero 847 The Provider AS Count is the number of 32-bit Provider Autonomous 848 System Numbers in the PDU. 850 The Customer Autonomous System Number is the 32-bit Autonomous System 851 Number of the customer which authenticated the PDU. There MUST be 852 one and only one ASPA for a Customer Autonomous System Number active 853 in the router at any time. 855 There are zero or more 32-bit Provider Autonomous System Number 856 fields as indicated in the Provider AS Count; see 857 [I-D.ietf-sidrops-aspa-profile]. 859 Receipt of an ASPA PDU with the Flags field indicating Delete is an 860 explicit withdraw from the router of the entire ASPA data for that 861 customer AS. While the Provider AS Count and the Provider AS Numbers 862 MUST BE ignored by the router when the Flags field indicates a 863 Delete, the cache SHOULD set the Provider AS Count to zero, and have 864 a null Provider AS Numbers list. 866 6. Protocol Timing Parameters 868 Since the data the cache distributes via the RPKI-Router protocol are 869 retrieved from the Global RPKI system at intervals which are only 870 known to the cache, only the cache can really know how frequently it 871 makes sense for the router to poll the cache, or how long the data 872 are likely to remain valid (or, at least, unchanged). For this 873 reason, as well as to allow the cache some control over the load 874 placed on it by its client routers, the End Of Data PDU includes 875 three values that allow the cache to communicate timing parameters to 876 the router: 878 Refresh Interval: This parameter tells the router how long to wait 879 before next attempting to poll the cache and between subsequent 880 attempts, using a Serial Query or Reset Query PDU. The router 881 SHOULD NOT poll the cache sooner than indicated by this parameter. 882 Note that receipt of a Serial Notify PDU overrides this interval 883 and suggests that the router issue an immediate query without 884 waiting for the Refresh Interval to expire. Countdown for this 885 timer starts upon receipt of the containing End Of Data PDU. 887 Minimum allowed value: 1 second. 889 Maximum allowed value: 86400 seconds (1 day). 891 Recommended default: 7200 seconds (2 hours). 893 Retry Interval: This parameter tells the router how long to wait 894 before retrying a failed Serial Query or Reset Query. The router 895 SHOULD NOT retry sooner than indicated by this parameter. Note 896 that a protocol version mismatch overrides this interval: if the 897 router needs to downgrade to a lower protocol version number, it 898 MAY send the first Serial Query or Reset Query immediately. 899 Countdown for this timer starts upon failure of the query and 900 restarts after each subsequent failure until a query succeeds. 902 Minimum allowed value: 1 second. 904 Maximum allowed value: 7200 seconds (2 hours). 906 Recommended default: 600 seconds (10 minutes). 908 Expire Interval: This parameter tells the router how long it can 909 continue to use the current version of the data while unable to 910 perform a successful subsequent query. The router MUST NOT retain 911 the data past the time indicated by this parameter. Countdown for 912 this timer starts upon receipt of the containing End Of Data PDU. 914 Minimum allowed value: 600 seconds (10 minutes). 916 Maximum allowed value: 172800 seconds (2 days). 918 Recommended default: 3600 seconds (1 hour). 920 If the router has never issued a successful query against a 921 particular cache, it SHOULD retry periodically using the default 922 Retry Interval, above. 924 Caches MUST set Expire Interval to a value larger than either Refresh 925 Interval or Retry Interval. 927 7. Protocol Version Negotiation 929 A router MUST start each transport connection by issuing either a 930 Reset Query or a Serial Query. This query will tell the cache which 931 version of this protocol the router implements. 933 If a cache which supports version N receives a query from a router 934 which specifies version Q < N, the cache MUST downgrade to protocol 935 version Q [RFC6810] or [RFC8210] or send a version 1 Error Report PDU 936 with Error Code 4 ("Unsupported Protocol Version") and terminate the 937 connection. 939 If a router which supports version N sends a query to a cache which 940 only supports version C < N, one of two things will happen: 942 1. The cache may terminate the connection, perhaps with a version 0 943 Error Report PDU. In this case, the router MAY retry the 944 connection using protocol version C. 946 2. The cache may reply with a version C response. In this case, the 947 router MUST either downgrade to version C or terminate the 948 connection. 950 In any of the downgraded combinations above, the new features of the 951 higher version will not be available, and all PDUs will have the 952 negotiated lower version number in their version fields. 954 If either party receives a PDU containing an unrecognized Protocol 955 Version (neither 0, 1, nor 2) during this negotiation, it MUST either 956 downgrade to a known version or terminate the connection, with an 957 Error Report PDU unless the received PDU is itself an Error Report 958 PDU. 960 The router MUST ignore any Serial Notify PDUs it might receive from 961 the cache during this initial startup period, regardless of the 962 Protocol Version field in the Serial Notify PDU. Since Session ID 963 and Serial Number values are specific to a particular protocol 964 version, the values in the notification are not useful to the router. 965 Even if these values were meaningful, the only effect that processing 966 the notification would have would be to trigger exactly the same 967 Reset Query or Serial Query that the router has already sent as part 968 of the not-yet-complete version negotiation process, so there is 969 nothing to be gained by processing notifications until version 970 negotiation completes. 972 Caches SHOULD NOT send Serial Notify PDUs before version negotiation 973 completes. Routers, however, MUST handle such notifications (by 974 ignoring them) for backwards compatibility with caches serving 975 protocol version 0. 977 Once the cache and router have agreed upon a Protocol Version via the 978 negotiation process above, that version is stable for the life of the 979 session. See Section 5.1 for a discussion of the interaction between 980 Protocol Version and Session ID. 982 If either party receives a PDU for a different Protocol Version once 983 the above negotiation completes, that party MUST drop the session; 984 unless the PDU containing the unexpected Protocol Version was itself 985 an Error Report PDU, the party dropping the session SHOULD send an 986 Error Report with an error code of 8 ("Unexpected Protocol Version"). 988 8. Protocol Sequences 990 The sequences of PDU transmissions fall into four conversations as 991 follows: 993 8.1. Start or Restart 995 Cache Router 996 ~ ~ 997 | <----- Reset Query -------- | R requests data (or Serial Query) 998 | | 999 | ----- Cache Response -----> | C confirms request 1000 | ------- Payload PDU ------> | C sends zero or more 1001 | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, 1002 | ------- Payload PDU ------> | or Router Key PDUs 1003 | ------- End of Data ------> | C sends End of Data 1004 | | and sends new serial 1005 ~ ~ 1007 When a transport connection is first established, the router MUST 1008 send either a Reset Query or a Serial Query. A Serial Query would be 1009 appropriate if the router has significant unexpired data from a 1010 broken session with the same cache and remembers the Session ID of 1011 that session, in which case a Serial Query containing the Session ID 1012 from the previous session will allow the router to bring itself up to 1013 date while ensuring that the Serial Numbers are commensurate and that 1014 the router and cache are speaking compatible versions of the 1015 protocol. In all other cases, the router lacks the necessary data 1016 for fast resynchronization and therefore MUST fall back to a Reset 1017 Query. 1019 The Reset Query sequence is also used when the router receives a 1020 Cache Reset, chooses a new cache, or fears that it has otherwise lost 1021 its way. 1023 See Section 7 for details on version negotiation. 1025 To limit the length of time a cache must keep the data necessary to 1026 generate incremental updates, a router MUST send either a Serial 1027 Query or a Reset Query periodically. This also acts as a keep-alive 1028 at the application layer. See Section 6 for details on the required 1029 polling frequency. 1031 8.2. Typical Exchange 1032 Cache Router 1033 ~ ~ 1034 | -------- Notify ----------> | (optional) 1035 | | 1036 | <----- Serial Query ------- | R requests data 1037 | | 1038 | ----- Cache Response -----> | C confirms request 1039 | ------- Payload PDU ------> | C sends zero or more 1040 | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, 1041 | ------- Payload PDU ------> | or Router Key PDUs 1042 | ------- End of Data ------> | C sends End of Data 1043 | | and sends new serial 1044 ~ ~ 1046 The cache server SHOULD send a Notify PDU with its current Serial 1047 Number when the cache's serial changes, with the expectation that the 1048 router MAY then issue a Serial Query earlier than it otherwise might. 1049 This is analogous to DNS NOTIFY in [RFC1996]. The cache MUST rate- 1050 limit Serial Notifies to no more frequently than one per minute. 1052 When the transport layer is up and either a timer has gone off in the 1053 router or the cache has sent a Notify PDU, the router queries for new 1054 data by sending a Serial Query, and the cache sends all data newer 1055 than the serial in the Serial Query. 1057 To limit the length of time a cache must keep old withdraws, a router 1058 MUST send either a Serial Query or a Reset Query periodically. See 1059 Section 6 for details on the required polling frequency. 1061 8.3. No Incremental Update Available 1063 Cache Router 1064 ~ ~ 1065 | <------ Serial Query ------ | R requests data 1066 | ------- Cache Reset ------> | C cannot supply update 1067 | | from specified serial 1068 | <------ Reset Query ------- | R requests new data 1069 | ----- Cache Response -----> | C confirms request 1070 | ------- Payload PDU ------> | C sends zero or more 1071 | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, 1072 | ------- Payload PDU ------> | or Router Key PDUs 1073 | ------- End of Data ------> | C sends End of Data 1074 | | and sends new serial 1075 ~ ~ 1077 The cache may respond to a Serial Query with a Cache Reset, informing 1078 the router that the cache cannot supply an incremental update from 1079 the Serial Number specified by the router. This might be because the 1080 cache has lost state, or because the router has waited too long 1081 between polls and the cache has cleaned up old data that it no longer 1082 believes it needs, or because the cache has run out of storage space 1083 and had to expire some old data early. Regardless of how this state 1084 arose, the cache replies with a Cache Reset to tell the router that 1085 it cannot honor the request. When a router receives this, the router 1086 SHOULD attempt to connect to any more-preferred caches in its cache 1087 list. If there are no more-preferred caches, it MUST issue a Reset 1088 Query and get an entire new load from the cache. 1090 8.4. Cache Has No Data Available 1092 Cache Router 1093 ~ ~ 1094 | <------ Serial Query ------ | R requests data 1095 | ---- Error Report PDU ----> | C No Data Available 1096 ~ ~ 1098 Cache Router 1099 ~ ~ 1100 | <------ Reset Query ------- | R requests data 1101 | ---- Error Report PDU ----> | C No Data Available 1102 ~ ~ 1104 The cache may respond to either a Serial Query or a Reset Query 1105 informing the router that the cache cannot supply any update at all. 1106 The most likely cause is that the cache has lost state, perhaps due 1107 to a restart, and has not yet recovered. While it is possible that a 1108 cache might go into such a state without dropping any of its active 1109 sessions, a router is more likely to see this behavior when it 1110 initially connects and issues a Reset Query while the cache is still 1111 rebuilding its database. 1113 When a router receives this kind of error, the router SHOULD attempt 1114 to connect to any other caches in its cache list, in preference 1115 order. If no other caches are available, the router MUST issue 1116 periodic Reset Queries until it gets a new usable load from the 1117 cache. 1119 9. Transport 1121 The transport-layer session between a router and a cache carries the 1122 binary PDUs in a persistent session. 1124 To prevent cache spoofing and DoS attacks by illegitimate routers, it 1125 is highly desirable that the router and the cache be authenticated to 1126 each other. Integrity protection for payloads is also desirable to 1127 protect against monkey-in-the-middle (MITM) attacks. Unfortunately, 1128 there is no protocol to do so on all currently used platforms. 1129 Therefore, as of the writing of this document, there is no mandatory- 1130 to-implement transport which provides authentication and integrity 1131 protection. 1133 To reduce exposure to dropped but non-terminated sessions, both 1134 caches and routers SHOULD enable keep-alives when available in the 1135 chosen transport protocol. 1137 It is expected that, when the TCP Authentication Option (TCP-AO) 1138 [RFC5925] is available on all platforms deployed by operators, it 1139 will become the mandatory-to-implement transport. 1141 Caches and routers MUST implement unprotected transport over TCP 1142 using a port, rpki-rtr (323); see Section 15. Operators SHOULD use 1143 procedural means, e.g., access control lists (ACLs), to reduce the 1144 exposure to authentication issues. 1146 If unprotected TCP is the transport, the cache and routers MUST be on 1147 the same trusted and controlled network. 1149 If available to the operator, caches and routers MUST use one of the 1150 following more protected protocols: 1152 * Caches and routers SHOULD use TCP-AO transport [RFC5925] over the 1153 rpki-rtr port. 1155 * Caches and routers MAY use Secure Shell version 2 (SSHv2) 1156 transport [RFC4252] using the normal SSH port. For an example, 1157 see Section 9.1. 1159 * Caches and routers MAY use TCP MD5 transport [RFC2385] using the 1160 rpki-rtr port. Note that TCP MD5 has been obsoleted by TCP-AO 1161 [RFC5925]. 1163 * Caches and routers MAY use TCP over IPsec transport [RFC4301] 1164 using the rpki-rtr port. 1166 * Caches and routers MAY use Transport Layer Security (TLS) 1167 transport [RFC5246] using port rpki-rtr-tls (324); see Section 15. 1169 9.1. SSH Transport 1171 To run over SSH, the client router first establishes an SSH transport 1172 connection using the SSHv2 transport protocol, and the client and 1173 server exchange keys for message integrity and encryption. The 1174 client then invokes the "ssh-userauth" service to authenticate the 1175 application, as described in the SSH authentication protocol 1176 [RFC4252]. Once the application has been successfully authenticated, 1177 the client invokes the "ssh-connection" service, also known as the 1178 SSH connection protocol. 1180 After the ssh-connection service is established, the client opens a 1181 channel of type "session", which results in an SSH session. 1183 Once the SSH session has been established, the application invokes 1184 the application transport as an SSH subsystem called "rpki-rtr". 1185 Subsystem support is a feature of SSHv2 and is not included in SSHv1. 1186 Running this protocol as an SSH subsystem avoids the need for the 1187 application to recognize shell prompts or skip over extraneous 1188 information, such as a system message that is sent at shell startup. 1190 It is assumed that the router and cache have exchanged keys out of 1191 band by some reasonably secured means. 1193 Cache servers supporting SSH transport MUST accept RSA authentication 1194 and SHOULD accept Elliptic Curve Digital Signature Algorithm (ECDSA) 1195 authentication. User authentication MUST be supported; host 1196 authentication MAY be supported. Implementations MAY support 1197 password authentication. Client routers SHOULD verify the public key 1198 of the cache to avoid MITM attacks. 1200 9.2. TLS Transport 1202 Client routers using TLS transport MUST present client-side 1203 certificates to authenticate themselves to the cache in order to 1204 allow the cache to manage the load by rejecting connections from 1205 unauthorized routers. In principle, any type of certificate and 1206 Certification Authority (CA) may be used; however, in general, cache 1207 operators will wish to create their own small-scale CA and issue 1208 certificates to each authorized router. This simplifies credential 1209 rollover; any unrevoked, unexpired certificate from the proper CA may 1210 be used. 1212 Certificates used to authenticate client routers in this protocol 1213 MUST include a subjectAltName extension [RFC5280] containing one or 1214 more iPAddress identities; when authenticating the router's 1215 certificate, the cache MUST check the IP address of the TLS 1216 connection against these iPAddress identities and SHOULD reject the 1217 connection if none of the iPAddress identities match the connection. 1219 Routers MUST also verify the cache's TLS server certificate, using 1220 subjectAltName dNSName identities as described in [RFC6125], to avoid 1221 MITM attacks. The rules and guidelines defined in [RFC6125] apply 1222 here, with the following considerations: 1224 * Support for the DNS-ID identifier type (that is, the dNSName 1225 identity in the subjectAltName extension) is REQUIRED in rpki-rtr 1226 server and client implementations which use TLS. Certification 1227 authorities which issue rpki-rtr server certificates MUST support 1228 the DNS-ID identifier type, and the DNS-ID identifier type MUST be 1229 present in rpki-rtr server certificates. 1231 * DNS names in rpki-rtr server certificates SHOULD NOT contain the 1232 wildcard character "*". 1234 * rpki-rtr implementations which use TLS MUST NOT use Common Name 1235 (CN-ID) identifiers; a CN field may be present in the server 1236 certificate's subject name but MUST NOT be used for authentication 1237 within the rules described in [RFC6125]. 1239 * The client router MUST set its "reference identifier" to the DNS 1240 name of the rpki-rtr cache. 1242 9.3. TCP MD5 Transport 1244 If TCP MD5 is used, implementations MUST support key lengths of at 1245 least 80 printable ASCII bytes, per Section 4.5 of [RFC2385]. 1246 Implementations MUST also support hexadecimal sequences of at least 1247 32 characters, i.e., 128 bits. 1249 Key rollover with TCP MD5 is problematic. Cache servers SHOULD 1250 support [RFC4808]. 1252 9.4. TCP-AO Transport 1254 Implementations MUST support key lengths of at least 80 printable 1255 ASCII bytes. Implementations MUST also support hexadecimal sequences 1256 of at least 32 characters, i.e., 128 bits. Message Authentication 1257 Code (MAC) lengths of at least 96 bits MUST be supported, per 1258 Section 5.1 of [RFC5925]. 1260 The cryptographic algorithms and associated parameters described in 1261 [RFC5926] MUST be supported. 1263 10. Router-Cache Setup 1265 A cache has the public authentication data for each router it is 1266 configured to support. 1268 A router may be configured to peer with a selection of caches, and a 1269 cache may be configured to support a selection of routers. Each must 1270 have the name of, and authentication data for, each peer. In 1271 addition, in a router, this list has a non-unique preference value 1272 for each server. This preference merely denotes proximity, not 1273 trust, preferred belief, et cetera. The client router attempts to 1274 establish a session with each potential serving cache in preference 1275 order and then starts to load data from the most preferred cache to 1276 which it can connect and authenticate. The router's list of caches 1277 has the following elements: 1279 Preference: An unsigned integer denoting the router's preference to 1280 connect to that cache; the lower the value, the more preferred. 1282 Name: The IP address or fully qualified domain name of the cache. 1284 Cache Credential(s): Any credential (such as a public key) needed to 1285 authenticate the cache's identity to the router. 1287 Router Credential(s): Any credential (such as a private key or 1288 certificate) needed to authenticate the router's identity to the 1289 cache. 1291 Due to the distributed nature of the RPKI, caches simply cannot be 1292 rigorously synchronous. A client may hold data from multiple caches 1293 but MUST keep the data marked as to source, as later updates MUST 1294 affect the correct data. 1296 Just as there may be more than one covering ROA from a single cache, 1297 there may be multiple covering ROAs from multiple caches. The 1298 results are as described in [RFC6811]. 1300 If data from multiple caches are held, implementations MUST NOT 1301 distinguish between data sources when performing validation of BGP 1302 announcements. 1304 When a more-preferred cache becomes available, if resources allow, it 1305 would be prudent for the client to start fetching from that cache. 1307 The client SHOULD attempt to maintain at least one set of data, 1308 regardless of whether it has chosen a different cache or established 1309 a new connection to the previous cache. 1311 A client MAY drop the data from a particular cache when it is fully 1312 in sync with one or more other caches. 1314 See Section 6 for details on what to do when the client is not able 1315 to refresh from a particular cache. 1317 If a client loses connectivity to a cache it is using or otherwise 1318 decides to switch to a new cache, it SHOULD retain the data from the 1319 previous cache until it has a full set of data from one or more other 1320 caches. Note that this may already be true at the point of 1321 connection loss if the client has connections to more than one cache. 1323 11. ROA PDU Race Minimization 1325 When a cache is sending ROA PDUs to the router, especially during an 1326 initial full load, two undesirable race conditions are possible: 1328 Break Before Make: For some prefix P, an AS may announce two (or 1329 more) ROAs because they are in the process of changing what 1330 provider AS is announcing P. This is is a case of "make before 1331 break." If a cache is feeding a router and sends the one not yet 1332 in service a significant time before sending the one currently in 1333 service, then BGP data could be marked invalid during the 1334 interval. To minimize that interval, the cache SHOULD announce 1335 all ROAs for the same prefix as close to sequentially as possible. 1337 Shorter Prefix First: If an AS has issued a ROA for P0, and another 1338 AS (likely their customer) has issued a ROA for P1 which is a sub- 1339 prefix of P0, a router which receives the ROA for P0 before that 1340 for P1 is likely to mark a BGP prefix P1 invalid. Therefore, the 1341 cache SHOULD announce the sub-prefix P1 before the covering prefix 1342 P0. 1344 12. Deployment Scenarios 1346 For illustration, we present three likely deployment scenarios: 1348 Small End Site: The small multihomed end site may wish to outsource 1349 the RPKI cache to one or more of their upstream ISPs. They would 1350 exchange authentication material with the ISP using some out-of- 1351 band mechanism, and their router(s) would connect to the cache(s) 1352 of one or more upstream ISPs. The ISPs would likely deploy caches 1353 intended for customer use separately from the caches with which 1354 their own BGP speakers peer. 1356 Large End Site: A larger multihomed end site might run one or more 1357 caches, arranging them in a hierarchy of client caches, each 1358 fetching from a serving cache which is closer to the Global RPKI. 1359 They might configure fallback peerings to upstream ISP caches. 1361 ISP Backbone: A large ISP would likely have one or more redundant 1362 caches in each major point of presence (PoP), and these caches 1363 would fetch from each other in an ISP-dependent topology so as not 1364 to place undue load on the Global RPKI. 1366 Experience with large DNS cache deployments has shown that complex 1367 topologies are ill-advised, as it is easy to make errors in the 1368 graph, e.g., not maintain a loop-free condition. 1370 Of course, these are illustrations, and there are other possible 1371 deployment strategies. It is expected that minimizing load on the 1372 Global RPKI servers will be a major consideration. 1374 To keep load on Global RPKI services from unnecessary peaks, it is 1375 recommended that primary caches which load from the distributed 1376 Global RPKI not do so all at the same times, e.g., on the hour. 1377 Choose a random time, perhaps the ISP's AS number modulo 60, and 1378 jitter the inter-fetch timing. 1380 13. Error Codes 1382 This section contains a preliminary list of error codes. The authors 1383 expect additions to the list during development of the initial 1384 implementations. There is an IANA registry where valid error codes 1385 are listed; see Section 15. Errors which are considered fatal MUST 1386 cause the session to be dropped. 1388 0: Corrupt Data (fatal): The receiver believes the received PDU to 1389 be corrupt in a manner not specified by another error code. 1391 1: Internal Error (fatal): The party reporting the error experienced 1392 some kind of internal error unrelated to protocol operation (ran 1393 out of memory, a coding assertion failed, et cetera). 1395 2: No Data Available: The cache believes itself to be in good 1396 working order but is unable to answer either a Serial Query or a 1397 Reset Query because it has no useful data available at this time. 1398 This is likely to be a temporary error and most likely indicates 1399 that the cache has not yet completed pulling down an initial 1400 current data set from the Global RPKI system after some kind of 1401 event that invalidated whatever data it might have previously held 1402 (reboot, network partition, et cetera). 1404 3: Invalid Request (fatal): The cache server believes the client's 1405 request to be invalid. 1407 4: Unsupported Protocol Version (fatal): The Protocol Version is not 1408 known by the receiver of the PDU. 1410 5: Unsupported PDU Type (fatal): The PDU Type is not known by the 1411 receiver of the PDU. 1413 6: Withdrawal of Unknown Record (fatal): The received PDU has 1414 Flag=0, but a matching record ({Prefix, Len, Max-Len, ASN} tuple 1415 for an IPvX PDU or {SKI, ASN, Subject Public Key} tuple for a 1416 Router Key PDU) does not exist in the receiver's database. 1418 7: Duplicate Announcement Received (fatal): The received PDU has 1419 Flag=1, but a matching record ({Prefix, Len, Max-Len, ASN} tuple 1420 for an IPvX PDU or {SKI, ASN, Subject Public Key} tuple for a 1421 Router Key PDU) is already active in the router. 1423 8: Unexpected Protocol Version (fatal): The received PDU has a 1424 Protocol Version field that differs from the protocol version 1425 negotiated in Section 7. 1427 14. Security Considerations 1429 As this document describes a security protocol, many aspects of 1430 security interest are described in the relevant sections. This 1431 section points out issues which may not be obvious in other sections. 1433 Cache Validation: In order for a collection of caches as described 1434 in Section 12 to guarantee a consistent view, they need to be 1435 given consistent trust anchors to use in their internal validation 1436 process. Distribution of a consistent trust anchor is assumed to 1437 be out of band. 1439 Cache Peer Identification: The router initiates a transport 1440 connection to a cache, which it identifies by either IP address or 1441 fully qualified domain name. Be aware that a DNS or address 1442 spoofing attack could make the correct cache unreachable. No 1443 session would be established, as the authorization keys would not 1444 match. 1446 Transport Security: The RPKI relies on object, not server or 1447 transport, trust. That is, the IANA root trust anchor is 1448 distributed to all caches through some out-of-band means and can 1449 then be used by each cache to validate certificates and ROAs all 1450 the way down the tree. The inter-cache relationships are based on 1451 this object security model; hence, the inter-cache transport can 1452 be lightly protected. 1454 However, this protocol document assumes that the routers cannot do 1455 the validation cryptography. Hence, the last link, from cache to 1456 router, is secured by server authentication and transport-level 1457 security. This is dangerous, as server authentication and 1458 transport have very different threat models than object security. 1460 So the strength of the trust relationship and the transport 1461 between the router(s) and the cache(s) are critical. You're 1462 betting your routing on this. 1464 While we cannot say the cache must be on the same LAN, if only due 1465 to the issue of an enterprise wanting to offload the cache task to 1466 their upstream ISP(s), locality, trust, and control are very 1467 critical issues here. The cache(s) really SHOULD be as close, in 1468 the sense of controlled and protected (against DDoS, MITM) 1469 transport, to the router(s) as possible. It also SHOULD be 1470 topologically close so that a minimum of validated routing data 1471 are needed to bootstrap a router's access to a cache. 1473 The identity of the cache server SHOULD be verified and 1474 authenticated by the router client, and vice versa, before any 1475 data are exchanged. 1477 Transports which cannot provide the necessary authentication and 1478 integrity (see Section 9) must rely on network design and 1479 operational controls to provide protection against spoofing/ 1480 corruption attacks. As pointed out in Section 9, TCP-AO is the 1481 long-term plan. Protocols which provide integrity and 1482 authenticity SHOULD be used, and if they cannot, i.e., TCP is used 1483 as the transport, the router and cache MUST be on the same 1484 trusted, controlled network. 1486 15. IANA Considerations 1488 This section only discusses updates required in the existing IANA 1489 protocol registries to accommodate version 1 of this protocol. See 1490 [RFC8210] for IANA considerations from the original (version 0) 1491 protocol. 1493 All existing entries in the IANA "rpki-rtr-pdu" registry remain valid 1494 for protocol version 0. All of the PDU types allowed in protocol 1495 version 0 are also allowed in protocol version 1, with the addition 1496 of the new Router Key PDU. To reduce the likelihood of confusion, 1497 the PDU number used by the Router Key PDU in protocol version 1 is 1498 hereby registered as reserved (and unused) in protocol version 0. 1500 The policy for adding to the registry is RFC Required per [RFC8126]; 1501 the document must be either Standards Track or Experimental. 1503 The "rpki-rtr-pdu" registry has been updated as follows: 1505 Protocol PDU 1506 Version Type Description 1507 -------- ---- --------------- 1508 0-2 0 Serial Notify 1509 0-2 1 Serial Query 1510 0-2 2 Reset Query 1511 0-2 3 Cache Response 1512 0-2 4 IPv4 Prefix 1513 0-2 6 IPv6 Prefix 1514 0-2 7 End of Data 1515 0-2 8 Cache Reset 1516 0 9 Reserved 1517 1-2 9 Router Key 1518 0-2 10 Error Report 1519 0-1 11 Reserved 1520 2 11 ASPA 1521 0-2 255 Reserved 1523 All previous entries in the IANA "rpki-rtr-error" registry remain 1524 valid for all protocol versions. Protocol version 1 added one new 1525 error code: 1527 Error 1528 Code Description 1529 ----- --------------------------- 1530 8 Unexpected Protocol Version 1532 16. References 1534 16.1. Normative References 1536 [I-D.ietf-sidrops-aspa-profile] 1537 Azimov, A., Uskov, E., Bush, R., Patel, K., Snijders, J., 1538 and R. Housley, "A Profile for Autonomous System Provider 1539 Authorization", Work in Progress, Internet-Draft, draft- 1540 ietf-sidrops-aspa-profile-07, 31 January 2022, 1541 . 1544 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 1545 DOI 10.17487/RFC1982, August 1996, 1546 . 1548 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1549 Requirement Levels", BCP 14, RFC 2119, 1550 DOI 10.17487/RFC2119, March 1997, 1551 . 1553 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1554 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 1555 1998, . 1557 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1558 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1559 2003, . 1561 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 1562 Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, 1563 January 2006, . 1565 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1566 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1567 December 2005, . 1569 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1570 (TLS) Protocol Version 1.2", RFC 5246, 1571 DOI 10.17487/RFC5246, August 2008, 1572 . 1574 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1575 Housley, R., and W. Polk, "Internet X.509 Public Key 1576 Infrastructure Certificate and Certificate Revocation List 1577 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1578 . 1580 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1581 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1582 June 2010, . 1584 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 1585 for the TCP Authentication Option (TCP-AO)", RFC 5926, 1586 DOI 10.17487/RFC5926, June 2010, 1587 . 1589 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1590 Verification of Domain-Based Application Service Identity 1591 within Internet Public Key Infrastructure Using X.509 1592 (PKIX) Certificates in the Context of Transport Layer 1593 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1594 2011, . 1596 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 1597 X.509 PKIX Resource Certificates", RFC 6487, 1598 DOI 10.17487/RFC6487, February 2012, 1599 . 1601 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 1602 Infrastructure (RPKI) to Router Protocol", RFC 6810, 1603 DOI 10.17487/RFC6810, January 2013, 1604 . 1606 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 1607 Austein, "BGP Prefix Origin Validation", RFC 6811, 1608 DOI 10.17487/RFC6811, January 2013, 1609 . 1611 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1612 Writing an IANA Considerations Section in RFCs", BCP 26, 1613 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1614 . 1616 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1617 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1618 May 2017, . 1620 [RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key 1621 Formats, and Signature Formats", RFC 8208, 1622 DOI 10.17487/RFC8208, September 2017, 1623 . 1625 [RFC8210] Bush, R. and R. Austein, "The Resource Public Key 1626 Infrastructure (RPKI) to Router Protocol, Version 1", 1627 RFC 8210, DOI 10.17487/RFC8210, September 2017, 1628 . 1630 16.2. Informative References 1632 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 1633 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 1634 August 1996, . 1636 [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", 1637 RFC 4808, DOI 10.17487/RFC4808, March 2007, 1638 . 1640 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 1641 Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, 1642 . 1644 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 1645 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 1646 February 2012, . 1648 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 1649 Resource Certificate Repository Structure", RFC 6481, 1650 DOI 10.17487/RFC6481, February 2012, 1651 . 1653 Acknowledgements 1655 The authors wish to thank Nils Bars, Steve Bellovin, Oliver Borchert, 1656 Tim Bruijnzeels, Rex Fernando, Richard Hansen, Martin Hoffmann, Paul 1657 Hoffman, Fabian Holler, Russ Housley, Pradosh Mohapatra, Keyur Patel, 1658 David Mandelberg, Sandy Murphy, Robert Raszuk, Andreas Reuter, Thomas 1659 Schmidt, John Scudder, Ruediger Volk, Matthias Waehlisch, and David 1660 Ward. Particular thanks go to Hannes Gredler for showing us the 1661 dangers of unnecessary fields. 1663 No doubt this list is incomplete. We apologize to any contributor 1664 whose name we missed. 1666 Authors' Addresses 1668 Randy Bush 1669 IIJ, Arrcus, & DRL 1670 5147 Crystal Springs 1671 Bainbridge Island, Washington 98110 1672 United States of America 1674 Email: randy@psg.com 1676 Rob Austein 1677 Dragon Research Labs 1678 Email: sra@hactrn.net