idnits 2.17.1 draft-ietf-sidr-rpki-rtr-rfc6810-bis-08.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 (January 7, 2017) is 2665 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 (-18) exists of draft-ietf-sidr-bgpsec-algs-16 ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) 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 Internet Initiative Japan 4 Intended status: Standards Track R. Austein 5 Expires: July 11, 2017 Dragon Research Labs 6 January 7, 2017 8 The Resource Public Key Infrastructure (RPKI) to Router Protocol 9 draft-ietf-sidr-rpki-rtr-rfc6810-bis-08 11 Abstract 13 In order to verifiably validate the origin Autonomous Systems and 14 Autonomous System Paths of BGP announcements, routers need a simple 15 but reliable mechanism to receive Resource Public Key Infrastructure 16 (RFC 6480) prefix origin data and router keys from a trusted cache. 17 This document describes a protocol to deliver them. 19 This document describes version 1 of the rpki-rtr protocol. RFC 6810 20 describes version 0. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 11, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 1.2. Changes from RFC 6810 . . . . . . . . . . . . . . . . . . 3 59 2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Deployment Structure . . . . . . . . . . . . . . . . . . . . 4 61 4. Operational Overview . . . . . . . . . . . . . . . . . . . . 5 62 5. Protocol Data Units (PDUs) . . . . . . . . . . . . . . . . . 6 63 5.1. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 6 64 5.2. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 9 65 5.3. Serial Query . . . . . . . . . . . . . . . . . . . . . . 9 66 5.4. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 10 67 5.5. Cache Response . . . . . . . . . . . . . . . . . . . . . 11 68 5.6. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 11 69 5.7. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 13 70 5.8. End of Data . . . . . . . . . . . . . . . . . . . . . . . 13 71 5.9. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 14 72 5.10. Router Key . . . . . . . . . . . . . . . . . . . . . . . 15 73 5.11. Error Report . . . . . . . . . . . . . . . . . . . . . . 16 74 6. Protocol Timing Parameters . . . . . . . . . . . . . . . . . 17 75 7. Protocol Version Negotiation . . . . . . . . . . . . . . . . 18 76 8. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . 20 77 8.1. Start or Restart . . . . . . . . . . . . . . . . . . . . 20 78 8.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . 21 79 8.3. No Incremental Update Available . . . . . . . . . . . . . 21 80 8.4. Cache Has No Data Available . . . . . . . . . . . . . . . 22 81 9. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 22 82 9.1. SSH Transport . . . . . . . . . . . . . . . . . . . . . . 24 83 9.2. TLS Transport . . . . . . . . . . . . . . . . . . . . . . 24 84 9.3. TCP MD5 Transport . . . . . . . . . . . . . . . . . . . . 25 85 9.4. TCP-AO Transport . . . . . . . . . . . . . . . . . . . . 25 86 10. Router-Cache Setup . . . . . . . . . . . . . . . . . . . . . 26 87 11. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 27 88 12. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 28 89 13. Security Considerations . . . . . . . . . . . . . . . . . . . 29 90 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 91 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 92 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 93 16.1. Normative References . . . . . . . . . . . . . . . . . . 31 94 16.2. Informative References . . . . . . . . . . . . . . . . . 32 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 97 1. Introduction 99 In order to verifiably validate the origin Autonomous Systems (ASes) 100 and AS paths of BGP announcements, routers need a simple but reliable 101 mechanism to receive cryptographically validated Resource Public Key 102 Infrastructure (RPKI) [RFC6480] prefix origin data and router keys 103 from a trusted cache. This document describes a protocol to deliver 104 them. The design is intentionally constrained to be usable on much 105 of the current generation of ISP router platforms. 107 Section 3 describes the deployment structure, and Section 4 then 108 presents an operational overview. The binary payloads of the 109 protocol are formally described in Section 5, and the expected 110 Protocol Data Unit (PDU) sequences are described in Section 8. The 111 transport protocol options are described in Section 9. Section 10 112 details how routers and caches are configured to connect and 113 authenticate. Section 11 describes likely deployment scenarios. The 114 traditional security and IANA considerations end the document. 116 The protocol is extensible in order to support new PDUs with new 117 semantics, if deployment experience indicates they are needed. PDUs 118 are versioned should deployment experience call for change. 120 1.1. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119] 125 only when they appear in all upper case. They may also appear in 126 lower or mixed case as English words, without special meaning. 128 1.2. Changes from RFC 6810 130 This section summarizes the significant changes between [RFC6810] and 131 the protocol described in this document. 133 o New Router Key PDU type (Section 5.10) added. 135 o Explicit timing parameters (Section 5.8, Section 6) added. 137 o Protocol version number incremented from zero to one. 139 o Protocol version number negotiation (Section 7) added. 141 2. Glossary 143 The following terms are used with special meaning. 145 Global RPKI: The authoritative data of the RPKI are published in a 146 distributed set of servers at the IANA, Regional Internet 147 Registries (RIRs), National Internet Registries (NIRs), and ISPs; 148 see [RFC6481]. 150 Cache: A coalesced copy of the published Global RPKI data, 151 periodically fetched or refreshed, directly or indirectly, using 152 the [RFC5781] protocol or some successor. Relying party software 153 is used to gather and validate the distributed data of the RPKI 154 into a cache. Trusting this cache further is a matter between the 155 provider of the cache and a relying party. 157 Serial Number: A 32-bit strictly increasing unsigned integer which 158 wraps from 2^32-1 to 0. It denotes the logical version of a 159 cache. A cache increments the value when it successfully updates 160 its data from a parent cache or from primary RPKI data. While a 161 cache is receiving updates, new incoming data and implicit deletes 162 are associated with the new serial but MUST NOT be sent until the 163 fetch is complete. A Serial Number is not commensurate between 164 different caches or different protocol versions, nor need it be 165 maintained across resets of the cache server. See [RFC1982] on 166 DNS Serial Number Arithmetic for too much detail on the topic. 168 Session ID: When a cache server is started, it generates a Session 169 ID to uniquely identify the instance of the cache and to bind it 170 to the sequence of Serial Numbers that cache instance will 171 generate. This allows the router to restart a failed session 172 knowing that the Serial Number it is using is commensurate with 173 that of the cache. 175 Payload PDU: A protocol message which contains data for use by the 176 router, as opposed to a PDU which conveys the control mechanisms 177 of this protocol. Prefixes and Router Keys are examples of 178 payload PDUs. 180 3. Deployment Structure 182 Deployment of the RPKI to reach routers has a three-level structure 183 as follows: 185 Global RPKI: The authoritative data of the RPKI are published in a 186 distributed set of servers, RPKI publication repositories, e.g., 187 by the IANA, RIRs, NIRs, and ISPs (see [RFC6481]). 189 Local Caches: A local set of one or more collected and verified 190 caches of RPKI data. A relying party, e.g., router or other 191 client, MUST have a trust relationship with, and a trusted 192 transport channel to, any cache(s) it uses. 194 Routers: A router fetches data from a local cache using the protocol 195 described in this document. It is said to be a client of the 196 cache. There MAY be mechanisms for the router to assure itself of 197 the authenticity of the cache and to authenticate itself to the 198 cache (see Section 9). 200 4. Operational Overview 202 A router establishes and keeps open a connection to one or more 203 caches with which it has client/server relationships. It is 204 configured with a semi-ordered list of caches, and establishes a 205 connection to the most preferred cache, or set of caches, which 206 accept the connections. 208 The router MUST choose the most preferred, by configuration, cache or 209 set of caches so that the operator may control load on their caches 210 and the Global RPKI. 212 Periodically, the router sends to the cache the most recent Serial 213 Number for which it has has received data from that cache, i.e., the 214 router's current Serial Number, in the form of a Serial Query. When 215 a router establishes a new session with a cache, or wishes to reset a 216 current relationship, it sends a Reset Query. 218 The cache responds to the Serial Query with all data changes which 219 took place since the given Serial Number. This may be the null set, 220 in which case the End of Data PDU is still sent. Note that the 221 Serial Number comparison used to determine "since the given Serial 222 Number" MUST take wrap-around into account, see [RFC1982]. 224 When the router has received all data records from the cache, it sets 225 its current Serial Number to that of the Serial Number in the 226 received End of Data PDU. 228 When the cache updates its database, it sends a Notify message to 229 every currently connected router. This is a hint that now would be a 230 good time for the router to poll for an update, but is only a hint. 231 The protocol requires the router to poll for updates periodically in 232 any case. 234 Strictly speaking, a router could track a cache simply by asking for 235 a complete data set every time it updates, but this would be very 236 inefficient. The Serial Number based incremental update mechanism 237 allows an efficient transfer of just the data records which have 238 changed since last update. As with any update protocol based on 239 incremental transfers, the router must be prepared to fall back to a 240 full transfer if for any reason the cache is unable to provide the 241 necessary incremental data. Unlike some incremental transfer 242 protocols, this protocol requires the router to make an explicit 243 request to start the fallback process; this is deliberate, as the 244 cache has no way of knowing whether the router has also established 245 sessions with other caches that may be able to provide better 246 service. 248 As a cache server must evaluate certificates and ROAs (Route Origin 249 Attestations; see [RFC6480]), which are time dependent, servers' 250 clocks MUST be correct to a tolerance of approximately an hour. 252 5. Protocol Data Units (PDUs) 254 The exchanges between the cache and the router are sequences of 255 exchanges of the following PDUs according to the rules described in 256 Section 8. 258 Reserved fields (marked "zero" in PDU diagrams) MUST be zero on 259 transmission, and SHOULD be ignored on receipt. 261 5.1. Fields of a PDU 263 PDUs contain the following data elements: 265 Protocol Version: An eight-bit unsigned integer, currently 1, 266 denoting the version of this protocol. 268 PDU Type: An eight-bit unsigned integer, denoting the type of the 269 PDU, e.g., IPv4 Prefix, etc. 271 Serial Number: The Serial Number of the RPKI Cache when this set of 272 PDUs was received from an upstream cache server or gathered from 273 the Global RPKI. A cache increments its Serial Number when 274 completing a rigorously validated update from a parent cache or 275 the Global RPKI. 277 Session ID: A 16-bit unsigned integer. When a cache server is 278 started, it generates a Session ID to identify the instance of the 279 cache and to bind it to the sequence of Serial Numbers that cache 280 instance will generate. This allows the router to restart a 281 failed session knowing that the Serial Number it is using is 282 commensurate with that of the cache. If, at any time after the 283 protocol version has been negotiated (Section 7), either the 284 router or the cache finds the value of the Session ID is not the 285 same as the other's, the party which detects the mismatch MUST 286 immediately terminate the session with an Error Report PDU with 287 code 0 ("Corrupt Data"), and the router MUST flush all data 288 learned from that cache. 290 Note that sessions are specific to a particular protocol version. 291 That is: if a cache server supports multiple versions of this 292 protocol, happens to use the same Session ID value for multiple 293 protocol versions, and further happens to use the same Serial 294 Number values for two or more sessions using the same Session ID 295 but different Protocol Version values, the serial numbers are not 296 commensurate. The full test for whether serial numbers are 297 commensurate requires comparing Protocol Version, Session ID, and 298 Serial Number. To reduce the risk of confusion, cache servers 299 SHOULD NOT use the same Session ID across multiple protocol 300 versions, but even if they do, routers MUST treat sessions with 301 different Protocol Version fields as separate sessions even if 302 they do happen to have the same Session ID. 304 Should a cache erroneously reuse a Session ID so that a router 305 does not realize that the session has changed (old Session ID and 306 new Session ID have same numeric value), the router may become 307 confused as to the content of the cache. The time it takes the 308 router to discover it is confused will depend on whether the 309 Serial Numbers are also reused. If the Serial Numbers in the old 310 and new sessions are different enough, the cache will respond to 311 the router's Serial Query with a Cache Reset, which will solve the 312 problem. If, however, the Serial Numbers are close, the cache may 313 respond with a Cache Response, which may not be enough to bring 314 the router into sync. In such cases, it's likely but not certain 315 that the router will detect some discrepancy between the state 316 that the cache expects and its own state. For example, the Cache 317 Response may tell the router to drop a record which the router 318 does not hold, or may tell the router to add a record which the 319 router already has. In such cases, a router will detect the error 320 and reset the session. The one case in which the router may stay 321 out of sync is when nothing in the Cache Response contradicts any 322 data currently held by the router. 324 Using persistent storage for the Session ID or a clock-based 325 scheme for generating Session IDs should avoid the risk of Session 326 ID collisions. 328 The Session ID might be a pseudo-random value, a strictly 329 increasing value if the cache has reliable storage, et cetera. A 330 seconds-since-epoch timestamp value such as the POSIX time() 331 function makes a good Session ID value. 333 Length: A 32-bit unsigned integer which has as its value the count 334 of the bytes in the entire PDU, including the eight bytes of 335 header which includes the length field. 337 Flags: The lowest order bit of the Flags field is 1 for an 338 announcement and 0 for a withdrawal. For a Prefix PDU (IPv4 or 339 IPv6), the flag indicates whether this PDU announces a new right 340 to announce the prefix or withdraws a previously announced right; 341 a withdraw effectively deletes one previously announced Prefix PDU 342 with the exact same Prefix, Length, Max-Len, and Autonomous System 343 Number (ASN). Similarly, for a Router Key PDU, the flag indicates 344 whether this PDU announces a new Router Key or deletes one 345 previously announced Router Key PDU with the exact same AS Number, 346 subjectKeyIdentifier, and subjectPublicKeyInfo. 348 The remaining bits in the flags field are reserved for future use. 349 In protocol version 1, they MUST be 0 on transmission and SHOULD 350 be ignored on receipt. 352 Prefix Length: An 8-bit unsigned integer denoting the shortest 353 prefix allowed for the Prefix element. 355 Max Length: An 8-bit unsigned integer denoting the longest prefix 356 allowed by the Prefix element. This MUST NOT be less than the 357 Prefix Length element. 359 Prefix: The IPv4 or IPv6 prefix of the ROA. 361 Autonomous System Number: A 32-bit unsigned integer representing an 362 ASN allowed to announce a prefix or associated with a router key. 364 Subject Key Identifier: 20-octet Subject Key Identifier (SKI) value 365 of a router key, as described in [RFC6487]. 367 Subject Public Key Info: a router key's subjectPublicKeyInfo value, 368 as described in [I-D.ietf-sidr-bgpsec-algs]. This is the full 369 ASN.1 DER encoding of the subjectPublicKeyInfo, including the 370 ASN.1 tag and length values of the subjectPublicKeyInfo SEQUENCE. 372 Refresh Interval: Interval between normal cache polls. See 373 Section 6 375 Retry Interval: Interval between cache poll retries after a failed 376 cache poll. See Section 6 378 Expire Interval: Interval during which data fetched from a cache 379 remains valid in the absence of a successful subsequent cache 380 poll. See Section 6 382 5.2. Serial Notify 384 The cache notifies the router that the cache has new data. 386 The Session ID reassures the router that the Serial Numbers are 387 commensurate, i.e., the cache session has not been changed. 389 Upon receipt of a Serial Notify PDU, the router MAY issue an 390 immediate Serial Query (Section 5.3) or Reset Query (Section 5.4) 391 without waiting for the Refresh Interval timer (see Section 6) to 392 expire. 394 Serial Notify is the only message that the cache can send that is not 395 in response to a message from the router. 397 If the router receives a Serial Notify PDU during the initial start- 398 up period where the router and cache are still negotiating to agree 399 on a protocol version, the router MUST simply ignore the Serial 400 Notify PDU, even if the Serial Notify PDU is for an unexpected 401 protocol version. See Section 7 for details. 403 0 8 16 24 31 404 .-------------------------------------------. 405 | Protocol | PDU | | 406 | Version | Type | Session ID | 407 | 1 | 0 | | 408 +-------------------------------------------+ 409 | | 410 | Length=12 | 411 | | 412 +-------------------------------------------+ 413 | | 414 | Serial Number | 415 | | 416 `-------------------------------------------' 418 5.3. Serial Query 420 The router sends Serial Query to ask the cache for all announcements 421 and withdrawals which have occurred since the Serial Number specified 422 in the Serial Query. 424 The cache replies to this query with a Cache Response PDU 425 (Section 5.5) if the cache has a, possibly null, record of the 426 changes since the Serial Number specified by the router, followed by 427 zero or more payload PDUs and an End Of Data PDU (Section 5.8). 429 When replying to a Serial Query, the cache MUST return the minimum 430 set of changes needed to bring the router into sync with the cache. 431 That is, if a particular prefix or router key underwent multiple 432 changes between the Serial Number specified by the router and the 433 cache's current Serial Number, the cache MUST merge those changes to 434 present the simplest possible view of those changes to the router. 435 In general, this means that, for any particular prefix or router key, 436 the data stream will include at most one withdrawal followed by at 437 most one announcement, and if all of the changes cancel out, the data 438 stream will not mention the prefix or router key at all. 440 The rationale for this approach is that the entire purpose of the 441 rpki-rtr protocol is to offload work from the router to the cache, 442 and it should therefore be the cache's job to simplify the change 443 set, thus reducing work for the router. 445 If the cache does not have the data needed to update the router, 446 perhaps because its records do not go back to the Serial Number in 447 the Serial Query, then it responds with a Cache Reset PDU 448 (Section 5.9). 450 The Session ID tells the cache what instance the router expects to 451 ensure that the Serial Numbers are commensurate, i.e., the cache 452 session has not been changed. 454 0 8 16 24 31 455 .-------------------------------------------. 456 | Protocol | PDU | | 457 | Version | Type | Session ID | 458 | 1 | 1 | | 459 +-------------------------------------------+ 460 | | 461 | Length=12 | 462 | | 463 +-------------------------------------------+ 464 | | 465 | Serial Number | 466 | | 467 `-------------------------------------------' 469 5.4. Reset Query 471 The router tells the cache that it wants to receive the total active, 472 current, non-withdrawn database. The cache responds with a Cache 473 Response PDU (Section 5.5), followed by zero or more payload PDUs and 474 an End of Data PDU (Section 5.8). 476 0 8 16 24 31 477 .-------------------------------------------. 478 | Protocol | PDU | | 479 | Version | Type | zero | 480 | 1 | 2 | | 481 +-------------------------------------------+ 482 | | 483 | Length=8 | 484 | | 485 `-------------------------------------------' 487 5.5. Cache Response 489 The cache responds to queries with zero or more payload PDUs. When 490 replying to a Serial Query (Section 5.3), the cache sends the set of 491 announcements and withdrawals that have occurred since the Serial 492 Number sent by the client router. When replying to a Reset Query 493 (Section 5.4), the cache sends the set of all data records it has; in 494 this case, the withdraw/announce field in the payload PDUs MUST have 495 the value 1 (announce). 497 In response to a Reset Query, the new value of the Session ID tells 498 the router the instance of the cache session for future confirmation. 499 In response to a Serial Query, the Session ID being the same 500 reassures the router that the Serial Numbers are commensurate, i.e., 501 the cache session has not changed. 503 0 8 16 24 31 504 .-------------------------------------------. 505 | Protocol | PDU | | 506 | Version | Type | Session ID | 507 | 1 | 3 | | 508 +-------------------------------------------+ 509 | | 510 | Length=8 | 511 | | 512 `-------------------------------------------' 514 5.6. IPv4 Prefix 515 0 8 16 24 31 516 .-------------------------------------------. 517 | Protocol | PDU | | 518 | Version | Type | zero | 519 | 1 | 4 | | 520 +-------------------------------------------+ 521 | | 522 | Length=20 | 523 | | 524 +-------------------------------------------+ 525 | | Prefix | Max | | 526 | Flags | Length | Length | zero | 527 | | 0..32 | 0..32 | | 528 +-------------------------------------------+ 529 | | 530 | IPv4 Prefix | 531 | | 532 +-------------------------------------------+ 533 | | 534 | Autonomous System Number | 535 | | 536 `-------------------------------------------' 538 The lowest order bit of the Flags field is 1 for an announcement and 539 0 for a withdrawal. 541 In the RPKI, nothing prevents a signing certificate from issuing two 542 identical ROAs. In this case, there would be no semantic difference 543 between the objects, merely a process redundancy. 545 In the RPKI, there is also an actual need for what might appear to a 546 router as identical IPvX PDUs. This can occur when an upstream 547 certificate is being reissued or there is an address ownership 548 transfer up the validation chain. The ROA would be identical in the 549 router sense, i.e., have the same {Prefix, Len, Max-Len, ASN}, but a 550 different validation path in the RPKI. This is important to the 551 RPKI, but not to the router. 553 The cache server MUST ensure that it has told the router client to 554 have one and only one IPvX PDU for a unique {Prefix, Len, Max-Len, 555 ASN} at any one point in time. Should the router client receive an 556 IPvX PDU with a {Prefix, Len, Max-Len, ASN} identical to one it 557 already has active, it SHOULD raise a Duplicate Announcement Received 558 error. 560 5.7. IPv6 Prefix 562 0 8 16 24 31 563 .-------------------------------------------. 564 | Protocol | PDU | | 565 | Version | Type | zero | 566 | 1 | 6 | | 567 +-------------------------------------------+ 568 | | 569 | Length=32 | 570 | | 571 +-------------------------------------------+ 572 | | Prefix | Max | | 573 | Flags | Length | Length | zero | 574 | | 0..128 | 0..128 | | 575 +-------------------------------------------+ 576 | | 577 +--- ---+ 578 | | 579 +--- IPv6 Prefix ---+ 580 | | 581 +--- ---+ 582 | | 583 +-------------------------------------------+ 584 | | 585 | Autonomous System Number | 586 | | 587 `-------------------------------------------' 589 Analogous to the IPv4 Prefix PDU, it has 96 more bits and no magic. 591 5.8. End of Data 593 The cache tells the router it has no more data for the request. 595 The Session ID and Protocol Version MUST be the same as that of the 596 corresponding Cache Response which began the, possibly null, sequence 597 of payload PDUs. 599 0 8 16 24 31 600 .-------------------------------------------. 601 | Protocol | PDU | | 602 | Version | Type | Session ID | 603 | 1 | 7 | | 604 +-------------------------------------------+ 605 | | 606 | Length=24 | 607 | | 608 +-------------------------------------------+ 609 | | 610 | Serial Number | 611 | | 612 +-------------------------------------------+ 613 | | 614 | Refresh Interval | 615 | | 616 +-------------------------------------------+ 617 | | 618 | Retry Interval | 619 | | 620 +-------------------------------------------+ 621 | | 622 | Expire Interval | 623 | | 624 `-------------------------------------------' 626 The Refresh Interval, Retry Interval, and Expire Interval are all 627 32-bit elapsed times measured in seconds, and express the timing 628 parameters which the cache expects the router to use in deciding when 629 to send subsequent Serial Query or Reset Query PDUs to the cache. 630 See Section 6 for an explanation of the use and the range of allowed 631 values for these parameters. 633 5.9. Cache Reset 635 The cache may respond to a Serial Query informing the router that the 636 cache cannot provide an incremental update starting from the Serial 637 Number specified by the router. The router must decide whether to 638 issue a Reset Query or switch to a different cache. 640 0 8 16 24 31 641 .-------------------------------------------. 642 | Protocol | PDU | | 643 | Version | Type | zero | 644 | 1 | 8 | | 645 +-------------------------------------------+ 646 | | 647 | Length=8 | 648 | | 649 `-------------------------------------------' 651 5.10. Router Key 653 0 8 16 24 31 654 .-------------------------------------------. 655 | Protocol | PDU | | | 656 | Version | Type | Flags | zero | 657 | 1 | 9 | | | 658 +-------------------------------------------+ 659 | | 660 | Length | 661 | | 662 +-------------------------------------------+ 663 | | 664 +--- ---+ 665 | Subject Key Identifier | 666 +--- ---+ 667 | | 668 +--- ---+ 669 | (20 octets) | 670 +--- ---+ 671 | | 672 +-------------------------------------------+ 673 | | 674 | AS Number | 675 | | 676 +-------------------------------------------+ 677 | | 678 | Subject Public Key Info | 679 | | 680 `-------------------------------------------' 682 The lowest order bit of the Flags field is 1 for an announcement and 683 0 for a withdrawal. 685 The cache server MUST ensure that it has told the router client to 686 have one and only one Router Key PDU for a unique {SKI, ASN, Subject 687 Public Key} at any one point in time. Should the router client 688 receive a Router Key PDU with a {SKI, ASN, Subject Public Key} 689 identical to one it already has active, it SHOULD raise a Duplicate 690 Announcement Received error. 692 Note that a particular ASN may appear in multiple Router Key PDUs 693 with different Subject Public Key values, while a particular Subject 694 Public Key value may appear in multiple Router Key PDUs with 695 different ASNs. In the interest of keeping the announcement and 696 withdrawal semantics as simple as possible for the router, this 697 protocol makes no attempt to compress either of these cases. 699 Also note that it is possible, albeit very unlikely, for multiple 700 distinct Subject Public Key values to hash to the same SKI. For this 701 reason, implementations MUST compare Subject Public Key values as 702 well as SKIs when detecting duplicate PDUs. 704 5.11. Error Report 706 This PDU is used by either party to report an error to the other. 708 Error reports are only sent as responses to other PDUs, not to report 709 errors in Error Report PDUS. 711 The Error Code is described in Section 12. 713 If the error is generic (e.g., "Internal Error") and not associated 714 with the PDU to which it is responding, the Erroneous PDU field MUST 715 be empty and the Length of Encapsulated PDU field MUST be zero. 717 An Error Report PDU MUST NOT be sent for an Error Report PDU. If an 718 erroneous Error Report PDU is received, the session SHOULD be 719 dropped. 721 If the error is associated with a PDU of excessive length, i.e., too 722 long to be any legal PDU other than another Error Report, or a 723 possibly corrupt length, the Erroneous PDU field MAY be truncated. 725 The diagnostic text is optional; if not present, the Length of Error 726 Text field MUST be zero. If error text is present, it MUST be a 727 string in UTF-8 encoding (see [RFC3629]). 729 0 8 16 24 31 730 .-------------------------------------------. 731 | Protocol | PDU | | 732 | Version | Type | Error Code | 733 | 1 | 10 | | 734 +-------------------------------------------+ 735 | | 736 | Length | 737 | | 738 +-------------------------------------------+ 739 | | 740 | Length of Encapsulated PDU | 741 | | 742 +-------------------------------------------+ 743 | | 744 ~ Copy of Erroneous PDU ~ 745 | | 746 +-------------------------------------------+ 747 | | 748 | Length of Error Text | 749 | | 750 +-------------------------------------------+ 751 | | 752 | Arbitrary Text | 753 | of | 754 ~ Error Diagnostic Message ~ 755 | | 756 `-------------------------------------------' 758 6. Protocol Timing Parameters 760 Since the data the cache distributes via the rpki-rtr protocol are 761 retrieved from the Global RPKI system at intervals which are only 762 known to the cache, only the cache can really know how frequently it 763 makes sense for the router to poll the cache, or how long the data 764 are likely to remain valid (or, at least, unchanged). For this 765 reason, as well as to allow the cache some control over the load 766 placed on it by its client routers, the End Of Data PDU includes 767 three values that allow the cache to communicate timing parameters to 768 the router. 770 Refresh Interval: This parameter tells the router how long to wait 771 before next attempting to poll the cache and between subsequent 772 attempts, using a Serial Query or Reset Query PDU. The router 773 SHOULD NOT poll the cache sooner than indicated by this parameter. 774 Note that receipt of a Serial Notify PDU overrides this interval 775 and suggests that the router issue an immediate query without 776 waiting for the Refresh Interval to expire. Countdown for this 777 timer starts upon receipt of the containing End Of Data PDU. 779 Minimum allowed value: 1 second. 781 Maximum allowed value: 86400 seconds (one day). 783 Recommended default: 3600 seconds (one hour). 785 Retry Interval: This parameter tells the router how long to wait 786 before retrying a failed Serial Query or Reset Query. The router 787 SHOULD NOT retry sooner than indicated by this parameter. Note 788 that a protocol version mismatch overrides this interval: if the 789 router needs to downgrade to a lower protocol version number, it 790 MAY send the first Serial Query or Reset Query immediately. 791 Countdown for this timer starts upon failure of the query, and 792 restarts after each subsequent failure until a query succeeds. 794 Minimum allowed value: 1 second. 796 Maximum allowed value: 7200 seconds (two hours). 798 Recommended default: 600 seconds (ten minutes). 800 Expire Interval: This parameter tells the router how long it can 801 continue to use the current version of the data while unable to 802 perform a successful subsequent query. The router MUST NOT retain 803 the data past the time indicated by this parameter. Countdown for 804 this timer starts upon receipt of the containing End Of Data PDU. 806 Minimum allowed value: 600 seconds (ten minutes). 808 Maximum allowed value: 172800 seconds (two days). 810 Recommended default: 7200 seconds (two hours). 812 If the router has never issued a successful query against a 813 particular cache, it SHOULD retry periodically using the default 814 Retry Interval, above. 816 7. Protocol Version Negotiation 818 A router MUST start each transport connection by issuing either a 819 Reset Query or a Serial Query. This query will tell the cache which 820 version of this protocol the router implements. 822 If a cache which supports version 1 receives a query from a router 823 which specifies version 0, the cache MUST downgrade to protocol 824 version 0 [RFC6810] or send a version 1 Error Report PDU with Error 825 Code 4 ("Unsupported Protocol Version") and terminate the connection. 827 If a router which supports version 1 sends a query to a cache which 828 only supports version 0, one of two things will happen. 830 1. The cache may terminate the connection, perhaps with a version 0 831 Error Report PDU. In this case the router MAY retry the 832 connection using protocol version 0. 834 2. The cache may reply with a version 0 response. In this case the 835 router MUST either downgrade to version 0 or terminate the 836 connection. 838 In any of the downgraded combinations above, the new features of 839 version 1 will not be available, and all PDUs will have 0 in their 840 version fields. 842 If either party receives a PDU containing an unrecognized Protocol 843 Version (neither 0 nor 1) during this negotiation, it MUST either 844 downgrade to a known version or terminate the connection, with an 845 Error Report PDU unless the received PDU is itself an Error Report 846 PDU. 848 The router MUST ignore any Serial Notify PDUs it might receive from 849 the cache during this initial start-up period, regardless of the 850 Protocol Version field in the Serial Notify PDU. Since Session ID 851 and Serial Number values are specific to a particular protocol 852 version, the values in the notification are not useful to the router. 853 Even if these values were meaningful, the only effect that processing 854 the notification would have would be to trigger exactly the same 855 Reset Query or Serial Query that the router has already sent as part 856 of the not-yet-complete version negotiation process, so there is 857 nothing to be gained by processing notifications until version 858 negotiation completes. 860 Caches SHOULD NOT send Serial Notify PDUs before version negotiation 861 completes. Routers, however, MUST handle such notifications (by 862 ignoring them) for backwards compatibility with caches serving 863 protocol version 0. 865 Once the cache and router have agreed upon a Protocol Version via the 866 negotiation process above, that version is stable for the life of the 867 session. See Section 5.1 for a discussion of the interaction between 868 Protocol Version and Session ID. 870 If either party receives a PDU for a different Protocol Version once 871 the above negotiation completes, that party MUST drop the session; 872 unless the PDU containing the unexpected Protocol Version was itself 873 an Error Report PDU, the party dropping the session SHOULD send an 874 Error Report with an error code of 8 ("Unexpected Protocol Version"). 876 8. Protocol Sequences 878 The sequences of PDU transmissions fall into three conversations as 879 follows: 881 8.1. Start or Restart 883 Cache Router 884 ~ ~ 885 | <----- Reset Query -------- | R requests data (or Serial Query) 886 | | 887 | ----- Cache Response -----> | C confirms request 888 | ------- Payload PDU ------> | C sends zero or more 889 | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, 890 | ------- Payload PDU ------> | or Router Key PDUs 891 | ------- End of Data ------> | C sends End of Data 892 | | and sends new serial 893 ~ ~ 895 When a transport connection is first established, the router MUST 896 send either a Reset Query or a Serial Query. A Serial Query would be 897 appropriate if the router has significant unexpired data from a 898 broken session with the same cache and remembers the Session ID of 899 that session, in which case a Serial Query containing the Session ID 900 from the previous session will allow the router to bring itself up to 901 date while ensuring that the Serial Numbers are commensurate and that 902 the router and cache are speaking compatible versions of the 903 protocol. In all other cases, the router lacks the necessary data 904 for fast re-synchronization and therefore MUST fall back to a Reset 905 Query. 907 The Reset Query sequence is also used when the router receives a 908 Cache Reset, chooses a new cache, or fears that it has otherwise lost 909 its way. 911 See Section 7 for details on version negotiation. 913 To limit the length of time a cache must keep the data necessary to 914 generate incremental updates, a router MUST send either a Serial 915 Query or a Reset Query periodically. This also acts as a keep-alive 916 at the application layer. See Section 6 for details on the required 917 polling frequency. 919 8.2. Typical Exchange 921 Cache Router 922 ~ ~ 923 | -------- Notify ----------> | (optional) 924 | | 925 | <----- Serial Query ------- | R requests data 926 | | 927 | ----- Cache Response -----> | C confirms request 928 | ------- Payload PDU ------> | C sends zero or more 929 | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, 930 | ------- Payload PDU ------> | or Router Key PDUs 931 | ------- End of Data ------> | C sends End of Data 932 | | and sends new serial 933 ~ ~ 935 The cache server SHOULD send a notify PDU with its current Serial 936 Number when the cache's serial changes, with the expectation that the 937 router MAY then issue a Serial Query earlier than it otherwise might. 938 This is analogous to DNS NOTIFY in [RFC1996]. The cache MUST rate 939 limit Serial Notifies to no more frequently than one per minute. 941 When the transport layer is up and either a timer has gone off in the 942 router, or the cache has sent a Notify, the router queries for new 943 data by sending a Serial Query, and the cache sends all data newer 944 than the serial in the Serial Query. 946 To limit the length of time a cache must keep old withdraws, a router 947 MUST send either a Serial Query or a Reset Query periodically. See 948 Section 6 for details on the required polling frequency. 950 8.3. No Incremental Update Available 952 Cache Router 953 ~ ~ 954 | <----- Serial Query ------ | R requests data 955 | ------- Cache Reset ------> | C cannot supply update 956 | | from specified serial 957 | <------ Reset Query ------- | R requests new data 958 | ----- Cache Response -----> | C confirms request 959 | ------- Payload PDU ------> | C sends zero or more 960 | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, 961 | ------- Payload PDU ------> | or Router Key PDUs 962 | ------- End of Data ------> | C sends End of Data 963 | | and sends new serial 964 ~ ~ 966 The cache may respond to a Serial Query with a Cache Reset, informing 967 the router that the cache cannot supply an incremental update from 968 the Serial Number specified by the router. This might be because the 969 cache has lost state, or because the router has waited too long 970 between polls and the cache has cleaned up old data that it no longer 971 believes it needs, or because the cache has run out of storage space 972 and had to expire some old data early. Regardless of how this state 973 arose, the cache replies with a Cache Reset to tell the router that 974 it cannot honor the request. When a router receives this, the router 975 SHOULD attempt to connect to any more preferred caches in its cache 976 list. If there are no more preferred caches, it MUST issue a Reset 977 Query and get an entire new load from the cache. 979 8.4. Cache Has No Data Available 981 Cache Router 982 ~ ~ 983 | <----- Serial Query ------ | R requests data 984 | ---- Error Report PDU ----> | C No Data Available 985 ~ ~ 987 Cache Router 988 ~ ~ 989 | <----- Reset Query ------- | R requests data 990 | ---- Error Report PDU ----> | C No Data Available 991 ~ ~ 993 The cache may respond to either a Serial Query or a Reset Query 994 informing the router that the cache cannot supply any update at all. 995 The most likely cause is that the cache has lost state, perhaps due 996 to a restart, and has not yet recovered. While it is possible that a 997 cache might go into such a state without dropping any of its active 998 sessions, a router is more likely to see this behavior when it 999 initially connects and issues a Reset Query while the cache is still 1000 rebuilding its database. 1002 When a router receives this kind of error, the router SHOULD attempt 1003 to connect to any other caches in its cache list, in preference 1004 order. If no other caches are available, the router MUST issue 1005 periodic Reset Queries until it gets a new usable load from the 1006 cache. 1008 9. Transport 1010 The transport-layer session between a router and a cache carries the 1011 binary PDUs in a persistent session. 1013 To prevent cache spoofing and DoS attacks by illegitimate routers, it 1014 is highly desirable that the router and the cache be authenticated to 1015 each other. Integrity protection for payloads is also desirable to 1016 protect against monkey-in-the-middle (MITM) attacks. Unfortunately, 1017 there is no protocol to do so on all currently used platforms. 1018 Therefore, as of the writing of this document, there is no mandatory- 1019 to-implement transport which provides authentication and integrity 1020 protection. 1022 To reduce exposure to dropped but non-terminated sessions, both 1023 caches and routers SHOULD enable keep-alives when available in the 1024 chosen transport protocol. 1026 It is expected that, when the TCP Authentication Option (TCP-AO) 1027 [RFC5925] is available on all platforms deployed by operators, it 1028 will become the mandatory-to-implement transport. 1030 Caches and routers MUST implement unprotected transport over TCP 1031 using a port, rpki-rtr (323); see Section 14. Operators SHOULD use 1032 procedural means, e.g., access control lists (ACLs), to reduce the 1033 exposure to authentication issues. 1035 If unprotected TCP is the transport, the cache and routers MUST be on 1036 the same trusted and controlled network. 1038 If available to the operator, caches and routers MUST use one of the 1039 following more protected protocols. 1041 Caches and routers SHOULD use TCP-AO transport [RFC5925] over the 1042 rpki-rtr port. 1044 Caches and routers MAY use SSHv2 transport [RFC4252] using the normal 1045 SSH port. For an example, see Section 9.1. 1047 Caches and routers MAY use TCP MD5 transport [RFC2385] using the 1048 rpki-rtr port. Note that TCP MD5 has been obsoleted by TCP-AO 1049 [RFC5925]. 1051 Caches and routers MAY use TCP over IPsec transport [RFC4301] using 1052 the rpki-rtr port. 1054 Caches and routers MAY use TLS transport [RFC5246] using port rpki- 1055 rtr-tls (324); see Section 14. 1057 9.1. SSH Transport 1059 To run over SSH, the client router first establishes an SSH transport 1060 connection using the SSHv2 transport protocol, and the client and 1061 server exchange keys for message integrity and encryption. The 1062 client then invokes the "ssh-userauth" service to authenticate the 1063 application, as described in the SSH authentication protocol 1064 [RFC4252]. Once the application has been successfully authenticated, 1065 the client invokes the "ssh-connection" service, also known as the 1066 SSH connection protocol. 1068 After the ssh-connection service is established, the client opens a 1069 channel of type "session", which results in an SSH session. 1071 Once the SSH session has been established, the application invokes 1072 the application transport as an SSH subsystem called "rpki-rtr". 1073 Subsystem support is a feature of SSH version 2 (SSHv2) and is not 1074 included in SSHv1. Running this protocol as an SSH subsystem avoids 1075 the need for the application to recognize shell prompts or skip over 1076 extraneous information, such as a system message that is sent at 1077 shell start-up. 1079 It is assumed that the router and cache have exchanged keys out of 1080 band by some reasonably secured means. 1082 Cache servers supporting SSH transport MUST accept RSA authentication 1083 and SHOULD accept Elliptic Curve Digital Signature Algorithm (ECDSA) 1084 authentication. User authentication MUST be supported; host 1085 authentication MAY be supported. Implementations MAY support 1086 password authentication. Client routers SHOULD verify the public key 1087 of the cache to avoid monkey-in-the-middle attacks. 1089 9.2. TLS Transport 1091 Client routers using TLS transport MUST present client-side 1092 certificates to authenticate themselves to the cache in order to 1093 allow the cache to manage the load by rejecting connections from 1094 unauthorized routers. In principle, any type of certificate and 1095 certificate authority (CA) may be used; however, in general, cache 1096 operators will wish to create their own small-scale CA and issue 1097 certificates to each authorized router. This simplifies credential 1098 rollover; any unrevoked, unexpired certificate from the proper CA may 1099 be used. 1101 Certificates used to authenticate client routers in this protocol 1102 MUST include a subjectAltName extension [RFC5280] containing one or 1103 more iPAddress identities; when authenticating the router's 1104 certificate, the cache MUST check the IP address of the TLS 1105 connection against these iPAddress identities and SHOULD reject the 1106 connection if none of the iPAddress identities match the connection. 1108 Routers MUST also verify the cache's TLS server certificate, using 1109 subjectAltName dNSName identities as described in [RFC6125], to avoid 1110 monkey-in-the-middle attacks. The rules and guidelines defined in 1111 [RFC6125] apply here, with the following considerations: 1113 Support for DNS-ID identifier type (that is, the dNSName identity 1114 in the subjectAltName extension) is REQUIRED in rpki-rtr server 1115 and client implementations which use TLS. Certification 1116 authorities which issue rpki-rtr server certificates MUST support 1117 the DNS-ID identifier type, and the DNS-ID identifier type MUST be 1118 present in rpki-rtr server certificates. 1120 DNS names in rpki-rtr server certificates SHOULD NOT contain the 1121 wildcard character "*". 1123 rpki-rtr implementations which use TLS MUST NOT use CN-ID 1124 identifiers; a CN field may be present in the server certificate's 1125 subject name, but MUST NOT be used for authentication within the 1126 rules described in [RFC6125]. 1128 The client router MUST set its "reference identifier" to the DNS 1129 name of the rpki-rtr cache. 1131 9.3. TCP MD5 Transport 1133 If TCP MD5 is used, implementations MUST support key lengths of at 1134 least 80 printable ASCII bytes, per Section 4.5 of [RFC2385]. 1135 Implementations MUST also support hexadecimal sequences of at least 1136 32 characters, i.e., 128 bits. 1138 Key rollover with TCP MD5 is problematic. Cache servers SHOULD 1139 support [RFC4808]. 1141 9.4. TCP-AO Transport 1143 Implementations MUST support key lengths of at least 80 printable 1144 ASCII bytes. Implementations MUST also support hexadecimal sequences 1145 of at least 32 characters, i.e., 128 bits. Message Authentication 1146 Code (MAC) lengths of at least 96 bits MUST be supported, per 1147 Section 5.1 of [RFC5925]. 1149 The cryptographic algorithms and associated parameters described in 1150 [RFC5926] MUST be supported. 1152 10. Router-Cache Setup 1154 A cache has the public authentication data for each router it is 1155 configured to support. 1157 A router may be configured to peer with a selection of caches, and a 1158 cache may be configured to support a selection of routers. Each must 1159 have the name of, and authentication data for, each peer. In 1160 addition, in a router, this list has a non-unique preference value 1161 for each server. This preference merely denotes proximity, not 1162 trust, preferred belief, etc. The client router attempts to 1163 establish a session with each potential serving cache in preference 1164 order, and then starts to load data from the most preferred cache to 1165 which it can connect and authenticate. The router's list of caches 1166 has the following elements: 1168 Preference: An unsigned integer denoting the router's preference to 1169 connect to that cache; the lower the value, the more preferred. 1171 Name: The IP address or fully qualified domain name of the cache. 1173 Cache Credential(s): Any credential (such as a public key) needed to 1174 authenticate the cache's identity to the router. 1176 Router Credential(s): Any credential (such as a private key or 1177 certificate) needed to authenticate the router's identity to the 1178 cache. 1180 Due to the distributed nature of the RPKI, caches simply cannot be 1181 rigorously synchronous. A client may hold data from multiple caches 1182 but MUST keep the data marked as to source, as later updates MUST 1183 affect the correct data. 1185 Just as there may be more than one covering ROA from a single cache, 1186 there may be multiple covering ROAs from multiple caches. The 1187 results are as described in [RFC6811]. 1189 If data from multiple caches are held, implementations MUST NOT 1190 distinguish between data sources when performing validation of BGP 1191 announcements. 1193 When a more preferred cache becomes available, if resources allow, it 1194 would be prudent for the client to start fetching from that cache. 1196 The client SHOULD attempt to maintain at least one set of data, 1197 regardless of whether it has chosen a different cache or established 1198 a new connection to the previous cache. 1200 A client MAY drop the data from a particular cache when it is fully 1201 in sync with one or more other caches. 1203 See Section 6 for details on what to do when the client is not able 1204 to refresh from a particular cache. 1206 If a client loses connectivity to a cache it is using, or otherwise 1207 decides to switch to a new cache, it SHOULD retain the data from the 1208 previous cache until it has a full set of data from one or more other 1209 caches. Note that this may already be true at the point of 1210 connection loss if the client has connections to more than one cache. 1212 11. Deployment Scenarios 1214 For illustration, we present three likely deployment scenarios. 1216 Small End Site: The small multihomed end site may wish to outsource 1217 the RPKI cache to one or more of their upstream ISPs. They would 1218 exchange authentication material with the ISP using some out-of- 1219 band mechanism, and their router(s) would connect to the cache(s) 1220 of one or more upstream ISPs. The ISPs would likely deploy caches 1221 intended for customer use separately from the caches with which 1222 their own BGP speakers peer. 1224 Large End Site: A larger multihomed end site might run one or more 1225 caches, arranging them in a hierarchy of client caches, each 1226 fetching from a serving cache which is closer to the Global RPKI. 1227 They might configure fall-back peerings to upstream ISP caches. 1229 ISP Backbone: A large ISP would likely have one or more redundant 1230 caches in each major point of presence (PoP), and these caches 1231 would fetch from each other in an ISP-dependent topology so as not 1232 to place undue load on the Global RPKI. 1234 Experience with large DNS cache deployments has shown that complex 1235 topologies are ill-advised as it is easy to make errors in the graph, 1236 e.g., not maintain a loop-free condition. 1238 Of course, these are illustrations and there are other possible 1239 deployment strategies. It is expected that minimizing load on the 1240 Global RPKI servers will be a major consideration. 1242 To keep load on Global RPKI services from unnecessary peaks, it is 1243 recommended that primary caches which load from the distributed 1244 Global RPKI not do so all at the same times, e.g., on the hour. 1245 Choose a random time, perhaps the ISP's AS number modulo 60 and 1246 jitter the inter-fetch timing. 1248 12. Error Codes 1250 This section contains a preliminary list of error codes. The authors 1251 expect additions to the list during development of the initial 1252 implementations. There is an IANA registry where valid error codes 1253 are listed; see Section 14. Errors which are considered fatal MUST 1254 cause the session to be dropped. 1256 0: Corrupt Data (fatal): The receiver believes the received PDU to 1257 be corrupt in a manner not specified by another error code. 1259 1: Internal Error (fatal): The party reporting the error experienced 1260 some kind of internal error unrelated to protocol operation (ran 1261 out of memory, a coding assertion failed, et cetera). 1263 2: No Data Available: The cache believes itself to be in good 1264 working order, but is unable to answer either a Serial Query or a 1265 Reset Query because it has no useful data available at this time. 1266 This is likely to be a temporary error, and most likely indicates 1267 that the cache has not yet completed pulling down an initial 1268 current data set from the Global RPKI system after some kind of 1269 event that invalidated whatever data it might have previously held 1270 (reboot, network partition, et cetera). 1272 3: Invalid Request (fatal): The cache server believes the client's 1273 request to be invalid. 1275 4: Unsupported Protocol Version (fatal): The Protocol Version is not 1276 known by the receiver of the PDU. 1278 5: Unsupported PDU Type (fatal): The PDU Type is not known by the 1279 receiver of the PDU. 1281 6: Withdrawal of Unknown Record (fatal): The received PDU has Flag=0 1282 but a matching record ({Prefix, Len, Max-Len, ASN} tuple for an 1283 IPvX PDU, or {SKI, ASN, Subject Public Key} tuple for a Router Key 1284 PDU) does not exist in the receiver's database. 1286 7: Duplicate Announcement Received (fatal): The received PDU has 1287 Flag=1 but a matching record ({Prefix, Len, Max-Len, ASN} tuple 1288 for an IPvX PDU, or {SKI, ASN, Subject Public Key} tuple for a 1289 Router Key PDU) is already active in the router. 1291 8: Unexpected Protocol Version (fatal): The received PDU has a 1292 Protocol Version field that differs from the protocol version 1293 negotiated in Section 7. 1295 13. Security Considerations 1297 As this document describes a security protocol, many aspects of 1298 security interest are described in the relevant sections. This 1299 section points out issues which may not be obvious in other sections. 1301 Cache Validation: In order for a collection of caches as described 1302 in Section 11 to guarantee a consistent view, they need to be 1303 given consistent trust anchors to use in their internal validation 1304 process. Distribution of a consistent trust anchor is assumed to 1305 be out of band. 1307 Cache Peer Identification: The router initiates a transport 1308 connection to a cache, which it identifies by either IP address or 1309 fully qualified domain name. Be aware that a DNS or address 1310 spoofing attack could make the correct cache unreachable. No 1311 session would be established, as the authorization keys would not 1312 match. 1314 Transport Security: The RPKI relies on object, not server or 1315 transport, trust. That is, the IANA root trust anchor is 1316 distributed to all caches through some out-of-band means, and can 1317 then be used by each cache to validate certificates and ROAs all 1318 the way down the tree. The inter-cache relationships are based on 1319 this object security model; hence, the inter-cache transport can 1320 be lightly protected. 1322 However, this protocol document assumes that the routers cannot do 1323 the validation cryptography. Hence, the last link, from cache to 1324 router, is secured by server authentication and transport-level 1325 security. This is dangerous, as server authentication and 1326 transport have very different threat models than object security. 1328 So the strength of the trust relationship and the transport 1329 between the router(s) and the cache(s) are critical. You're 1330 betting your routing on this. 1332 While we cannot say the cache must be on the same LAN, if only due 1333 to the issue of an enterprise wanting to off-load the cache task 1334 to their upstream ISP(s), locality, trust, and control are very 1335 critical issues here. The cache(s) really SHOULD be as close, in 1336 the sense of controlled and protected (against DDoS, MITM) 1337 transport, to the router(s) as possible. It also SHOULD be 1338 topologically close so that a minimum of validated routing data 1339 are needed to bootstrap a router's access to a cache. 1341 The identity of the cache server SHOULD be verified and 1342 authenticated by the router client, and vice versa, before any 1343 data are exchanged. 1345 Transports which cannot provide the necessary authentication and 1346 integrity (see Section 9) must rely on network design and 1347 operational controls to provide protection against spoofing/ 1348 corruption attacks. As pointed out in Section 9, TCP-AO is the 1349 long-term plan. Protocols which provide integrity and 1350 authenticity SHOULD be used, and if they cannot, i.e., TCP is used 1351 as the transport, the router and cache MUST be on the same 1352 trusted, controlled network. 1354 14. IANA Considerations 1356 This section only discusses updates required in the existing IANA 1357 protocol registries to accommodate version 1 of this protocol. See 1358 [RFC6810] for IANA Considerations from the original (version 0) 1359 protocol. 1361 All existing entries in the IANA "rpki-rtr-pdu" registry remain valid 1362 for protocol version 0. All of the PDU types allowed in protocol 1363 version 0 are also allowed in protocol version 1, with the addition 1364 of the new Router Key PDU. To reduce the likelihood of confusion, 1365 the PDU number used by the Router Key PDU in protocol version 1 is 1366 hereby registered as reserved (and unused) in protocol version 0. 1368 The policy for adding to the registry is RFC Required per [RFC5226], 1369 either Standards Track or Experimental. 1371 Assuming that the registry allows range notation in the Protocol 1372 Version field, the updated "rpki-rtr-pdu" registry will be: 1374 Protocol PDU 1375 Version Type Description 1376 -------- ---- --------------- 1377 0-1 0 Serial Notify 1378 0-1 1 Serial Query 1379 0-1 2 Reset Query 1380 0-1 3 Cache Response 1381 0-1 4 IPv4 Prefix 1382 0-1 6 IPv6 Prefix 1383 0-1 7 End of Data 1384 0-1 8 Cache Reset 1385 0 9 Reserved 1386 1 9 Router Key 1387 0-1 10 Error Report 1388 0-1 255 Reserved 1390 All existing entries in the IANA "rpki-rtr-error" registry remain 1391 valid for all protocol versions. Protocol version 1 adds one new 1392 error code: 1394 Error 1395 Code Description 1396 ----- ---------------- 1397 8 Unexpected Protocol Version 1399 15. Acknowledgments 1401 The authors wish to thank Nils Bars, Steve Bellovin, Tim Bruijnzeels, 1402 Rex Fernando, Richard Hansen, Paul Hoffman, Fabian Holler, Russ 1403 Housley, Pradosh Mohapatra, Keyur Patel, David Mandelberg, Sandy 1404 Murphy, Robert Raszuk, Andreas Reuter, Thomas C. Schmidt, John 1405 Scudder, Ruediger Volk, Matthias Waehlisch, and David Ward. 1406 Particular thanks go to Hannes Gredler for showing us the dangers of 1407 unnecessary fields. 1409 No doubt this list is incomplete. We apologize to any contributor 1410 whose name we missed. 1412 16. References 1414 16.1. Normative References 1416 [I-D.ietf-sidr-bgpsec-algs] 1417 Turner, S., "BGPsec Algorithms, Key Formats, & Signature 1418 Formats", draft-ietf-sidr-bgpsec-algs-16 (work in 1419 progress), November 2016. 1421 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 1422 August 1996. 1424 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1425 Requirement Levels", RFC 2119, BCP 14, March 1997. 1427 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1428 Signature Option", RFC 2385, August 1998. 1430 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1431 10646", RFC 3629, STD 63, November 2003. 1433 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1434 Authentication Protocol", RFC 4252, January 2006. 1436 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1437 Internet Protocol", RFC 4301, December 2005. 1439 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1440 IANA Considerations Section in RFCs", RFC 5226, BCP 26, 1441 May 2008. 1443 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1444 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1446 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1447 Housley, R., and W. Polk, "Internet X.509 Public Key 1448 Infrastructure Certificate and Certificate Revocation List 1449 (CRL) Profile", RFC 5280, May 2008. 1451 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1452 Authentication Option", RFC 5925, June 2010. 1454 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 1455 for the TCP Authentication Option (TCP-AO)", RFC 5926, 1456 June 2010. 1458 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1459 Verification of Domain-Based Application Service Identity 1460 within Internet Public Key Infrastructure Using X.509 1461 (PKIX) Certificates in the Context of Transport Layer 1462 Security (TLS)", RFC 6125, March 2011. 1464 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 1465 X.509 PKIX Resource Certificates", RFC 6487, February 1466 2012. 1468 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 1469 Infrastructure (RPKI) to Router Protocol", RFC 6810, 1470 January 2013. 1472 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 1473 Austein, "BGP Prefix Origin Validation", RFC 6811, January 1474 2013. 1476 16.2. Informative References 1478 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 1479 Changes (DNS NOTIFY)", RFC 1996, August 1996. 1481 [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", 1482 RFC 4808, March 2007. 1484 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI 1485 Scheme", RFC 5781, February 2010. 1487 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 1488 Secure Internet Routing", RFC 6480, February 2012. 1490 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 1491 Resource Certificate Repository Structure", RFC 6481, 1492 February 2012. 1494 Authors' Addresses 1496 Randy Bush 1497 Internet Initiative Japan 1498 5147 Crystal Springs 1499 Bainbridge Island, Washington 98110 1500 US 1502 Email: randy@psg.com 1504 Rob Austein 1505 Dragon Research Labs 1507 Email: sra@hactrn.net