idnits 2.17.1 draft-ymbk-rpki-rtr-protocol-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-sidr-arch]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Serial Number: A 32-bit monotonically increasing, cardinal which wraps from 2^32-1 to 0. It denotes the logical version of a cache. A cache increments the value by one when it successfully updates its data from a parent cache or from primary RPKI data. As a cache is rcynicing, new incoming data, and implicit deletes, are marked with the new serial but MUST not be sent until the fetch is complete. A serial number is not commensurate between caches, nor need it be maintained across resets of the cache server. See [RFC1982] on DNS Serial Number Arithmetic for too much detail on serial number arithmetic. -- The document date (March 6, 2009) is 5523 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 (-13) exists of draft-ietf-sidr-arch-04 == Outdated reference: A later version (-09) exists of draft-ietf-sidr-repos-struct-01 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). 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, Inc. 4 Intended status: Standards Track March 6, 2009 5 Expires: September 7, 2009 7 The RPKI/Router Protocol 8 draft-ymbk-rpki-rtr-protocol-01 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may not be modified, 14 and derivative works of it may not be created, and it may not be 15 published except as an Internet-Draft. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 7, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 In order to formally validate the origin ASes of BGP announcements, 49 routers need a simple but reliable mechanism to receive RPKI 50 [I-D.ietf-sidr-arch] or analogous prefix origin data from a trusted 51 cache. This document describes a protocol to deliver validated 52 prefix origin data to routers over ssh. 54 Requirements Language 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC 2119 [RFC2119]. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Deployment Structure . . . . . . . . . . . . . . . . . . . . . 3 64 3. Operational Overview . . . . . . . . . . . . . . . . . . . . . 3 65 4. Protocol Data Units (PDUs) . . . . . . . . . . . . . . . . . . 4 66 4.1. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 4 67 4.2. Serial Query . . . . . . . . . . . . . . . . . . . . . . . 4 68 4.3. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 5 69 4.4. Cache Response . . . . . . . . . . . . . . . . . . . . . . 5 70 4.5. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.6. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 7 72 4.7. End of Data . . . . . . . . . . . . . . . . . . . . . . . 7 73 4.8. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 8 74 4.9. Error Report . . . . . . . . . . . . . . . . . . . . . . . 8 75 4.10. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 9 76 5. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . . 10 77 5.1. Start or Restart . . . . . . . . . . . . . . . . . . . . . 10 78 5.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . . 10 79 5.3. Cache has Reset . . . . . . . . . . . . . . . . . . . . . 11 80 6. SSH Transport . . . . . . . . . . . . . . . . . . . . . . . . 11 81 7. Router-Cache Set-Up . . . . . . . . . . . . . . . . . . . . . 12 82 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 13 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 84 10. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 86 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 87 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 13.1. Normative References . . . . . . . . . . . . . . . . . . . 15 89 13.2. Informative References . . . . . . . . . . . . . . . . . . 16 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 1. Introduction 94 In order to formally validate the origin ASes of BGP announcements, 95 routers need a simple but reliable mechanism to receive RPKI 96 [I-D.ietf-sidr-arch] or analogous formally validated prefix origin 97 data from a trusted cache. This document describes a protocol to 98 deliver validated prefix origin data to routers over ssh. 100 Section 2 describes the deployment structure and Section 3 then 101 presents an operational overview. The binary payloads of the 102 protocol are formally described in Section 4, and the expected PDU 103 sequences are described in Section 5. And the transport protocol is 104 described in Section 6. Section 7 details how routers and caches are 105 configured to connect and authenticate. Section 8 describes likely 106 deployment scenarios. The traditional security and IANA 107 considerations end the document. 109 2. Deployment Structure 111 Deployment of the RPKI to reach routers has a three level structure 112 as follows: 114 Global RPKI: The authoritative data of the RPKI are published in a 115 distributed set of servers, RPKI publication repositories, e.g. 116 the IANA, RIRs, NIRs, and ISPs, see [I-D.ietf-sidr-repos-struct]. 118 Local Caches: A local set of one or more collected and verified non- 119 authoritative caches. A relying party, e.g. router or other 120 client, MUST have a formally authenticated trust relationship 121 with, and a secure transport channel to, any non-authoritative 122 cache(s) it uses. 124 Routers: A router fetches data from a local cache using the protocol 125 described in this document. It is said to be a client of the 126 cache. There are mechanisms for the router to assure itself of 127 the authenticity of the cache and to authenticate itself to the 128 cache. 130 3. Operational Overview 132 A router establishes and keeps open an authenticated connection to a 133 cache with which it has an client/server relationship. It is 134 configured with a semi-ordered list of caches, and establishes a 135 connection to the highest preference cache that accepts one. 137 Periodically, the router sends to the cache the serial number of the 138 highest numbered data record it has received from that cache, i.e. 139 the router's current serial number. When a router establishes a new 140 connection to a cache, or wishes to reset a current relationship, it 141 sends a Reset Query. 143 The Cache responds with all data records which have serial numbers 144 greater than that in the router's query. This may be the null set, 145 in which case the End of Data PDU is still sent. Note that 'greater' 146 must take wrap-around into account, see [RFC1982]. 148 When the router has received all data records from the cache, it sets 149 its current serial number to that of the serial number in the End of 150 Data PDU. 152 4. Protocol Data Units (PDUs) 154 The exchanges between the cache and the router are sequences of 155 exchanges of the following PDUs according to the rules described in 156 Section 5. 158 4.1. Serial Notify 160 The cache notifies the router that the cache has new data. 162 0 8 16 24 31 163 .-------------------------------------------. 164 | Protocol | PDU | | 165 | Version | Type | reserved = zero | 166 | 0 | 0 | | 167 +-------------------------------------------+ 168 | | 169 | Sequence Number | 170 | | 171 +-------------------------------------------+ 172 | | 173 | Serial Number | 174 | | 175 `-------------------------------------------' 177 4.2. Serial Query 179 Serial Query: The router sends Serial Query to ask the cache for all 180 payload PDUs which have serial numbers higher than the serial number 181 in the Serial Query. 183 0 8 16 24 31 184 .-------------------------------------------. 185 | Protocol | PDU | | 186 | Version | Type | reserved = zero | 187 | 0 | 1 | | 188 +-------------------------------------------+ 189 | | 190 | Sequence Number | 191 | | 192 +-------------------------------------------+ 193 | | 194 | Serial Number | 195 | | 196 `-------------------------------------------' 198 4.3. Reset Query 200 Reset Query: The router tells the cache that it wants to receive the 201 total active, current, non-withdrawn, database. 203 0 8 16 24 31 204 .-------------------------------------------. 205 | Protocol | PDU | | 206 | Version | Type | reserved = zero | 207 | 0 | 2 | | 208 +-------------------------------------------+ 209 | | 210 | Sequence Number | 211 | | 212 `-------------------------------------------' 214 4.4. Cache Response 216 The cache responds with zero or more payload PDUs, the set of all 217 data records it has with serial numbers greater than that sent by the 218 client router, or all data records if the cache received a Reset 219 Query. 221 0 8 16 24 31 222 .-------------------------------------------. 223 | Protocol | PDU | | 224 | Version | Type | reserved = zero | 225 | 0 | 3 | | 226 +-------------------------------------------+ 227 | | 228 | Sequence Number | 229 | | 230 `-------------------------------------------' 232 4.5. IPv4 Prefix 234 0 8 16 24 31 235 .-------------------------------------------. 236 | Protocol | PDU | | 237 | Version | Type | Color | 238 | 0 | 4 | | 239 +-------------------------------------------+ 240 | | 241 | Sequence Number | 242 | | 243 +-------------------------------------------+ 244 | Announce | Prefix | Max | Data | 245 | Withdraw | Length | Length | Source | 246 | 0/1 | 0..32 | 0..32 | RPKI/IRR | 247 +-------------------------------------------+ 248 | | 249 | IPv4 prefix | 250 | | 251 +-------------------------------------------+ 252 | | 253 | Autonomous System Number | 254 | | 255 `-------------------------------------------' 257 Due to the nature of the RPKI and the IRR, there can be multiple 258 identical IPvX PDUs. Hence the router will likely keep an internal 259 ref-count on each IPvX PDU. 261 In the RPKI, nothing prevents a signing certificate from issuing two 262 identical ROAs, and nothing prohibits the existence of two identical 263 route: or route6: objects in the IRR. In this case there would be no 264 semantic difference between the objects, merely a process redundancy. 266 In the RPKI, there is also an actual need for what will appear to the 267 router as identical IPvX PDUs. This occurs when an upstream 268 certificate is being reissued or a site is changing providers, often 269 a 'make and break' situation. The ROA is identical in the router 270 sense, i.e. has the same {prefix, len, max-len, asn}, but has a 271 different validation path in the RPKI. This is important to the 272 RPKI, but not to the router. 274 It is this possibility of duplication that creates the need for a 275 nonce, the Sequence Number, in the IPvX PDUs, so that an Error Report 276 PDU can uniquely identify the erroneous PDU. 278 4.6. IPv6 Prefix 280 0 8 16 24 31 281 .-------------------------------------------. 282 | Protocol | PDU | | 283 | Version | Type | Color | 284 | 0 | 6 | | 285 +-------------------------------------------+ 286 | | 287 | Sequence Number | 288 | | 289 +-------------------------------------------+ 290 | Announce | Prefix | Max | Data | 291 | Withdraw | Length | Length | Source | 292 | 0/1 | 0..128 | 0..128 | RPKI/IRR | 293 +-------------------------------------------+ 294 | | 295 +--- ---+ 296 | | 297 +--- IPv6 prefix ---+ 298 | | 299 +--- ---+ 300 | | 301 +-------------------------------------------+ 302 | | 303 | Autonomous System Number | 304 | | 305 `-------------------------------------------' 307 4.7. End of Data 309 End of Data: Cache tells router it has no more data for the request. 311 0 8 16 24 31 312 .-------------------------------------------. 313 | Protocol | PDU | | 314 | Version | Type | reserved = zero | 315 | 0 | 7 | | 316 +-------------------------------------------+ 317 | | 318 | Sequence Number | 319 | | 320 +-------------------------------------------+ 321 | | 322 | Serial Number | 323 | | 324 `-------------------------------------------' 326 4.8. Cache Reset 328 The cache may respond to a Serial Query informing the router that the 329 cache's serial number is no longer commensurate with that of the 330 router. 332 0 8 16 24 31 333 .-------------------------------------------. 334 | Protocol | PDU | | 335 | Version | Type | reserved = zero | 336 | 0 | 8 | | 337 +-------------------------------------------+ 338 | | 339 | Sequence Number | 340 | | 341 `-------------------------------------------' 343 4.9. Error Report 345 This PDU is used by either party to report an error to the other. 347 0 8 16 24 31 348 .-------------------------------------------. 349 | Protocol | PDU | | 350 | Version | Type | Error Number | 351 | 0 | 10 | | 352 +-------------------------------------------+ 353 | | 354 | Sequence Number | 355 | | 356 +-------------------------------------------+ 357 | | 358 ~ Copy of Erroneous PDU ~ 359 | | 360 +-------------------------------------------+ 361 | Length | | 362 | of | Arbitrary Text | 363 | Text | | 364 +----------' of | 365 | | 366 ~ Error Diagnostic Message ~ 367 | | 368 `-------------------------------------------' 370 4.10. Fields of a PDU 372 PDUs contain the following data elements: 374 Protocol Version: A cardinal, currently 0, denoting the version of 375 this protocol. 377 Sequence Number: A 32-bit cardinal nonce, not to be confused with a 378 Serial Number, constructed by the PDU sender to allow the sender 379 to uniquely identify which PDU the receiver is reporting in an 380 Error Report PDU. As the only part of the protocol which is 381 asynchronous is the streaming of IPvX PDUs, they are the only PDUs 382 needing differentiation using a Sequence Number. But all PDUs 383 include one for simplicity and homogeneity, the additional 384 transport cost is negligible. 386 Serial Number: The serial number of the RPKI Cache when this ROA was 387 received from the cache's up-stream cache server or gathered from 388 the global RPKI. A cache increments its serial number when 389 completing an rcynic from a parent cache. See [RFC1982] on DNS 390 Serial Number Arithmetic for too much detail on serial number 391 arithmetic. 393 Color: An arbitrary 16 bit field that might be used in some way. 395 Announce/Withdraw: Whether this PDU announces a new right to 396 announce the prefix or withdraws a previously announced right. 397 The allowed values are 0 for withdraw and 1 for announce. A 398 withdraw effectively deletes all previously announced IPvX Prefix 399 PDUs with the exact same Prefix, Length, Max-Len, ASN, Data 400 Source, and Color. 402 Prefix Length: A cardinal denoting the shortest prefix allowed for 403 the prefix. 405 Max Length: A cardinal denoting the longest prefix allowed by the 406 prefix. This MUST NOT be less than the Prefix Length element. 408 Data Source: A cardinal denoting the source of the data, e.g. for 409 RPKI data, it is 0, for IRR data it is 1. 411 Prefix: The IPv4 or IPv6 prefix of the ROA. 413 Autonomous System Number: ASN allowed to announce this prefix, a 32 414 bit cardinal. 416 5. Protocol Sequences 418 The sequences of PDU transmissions fall into three conversations as 419 follows: 421 5.1. Start or Restart 423 Cache Router 424 ~ ~ 425 | <----- Reset Query -------- | R requests data 426 | | 427 | ----- Cache Response -----> | C tells R C's serial 428 | ------- IPvX Prefix ------> | C sends zero or more 429 | ------- IPvX Prefix ------> | IPv4 and IPv6 Prefix 430 | ------- IPvX Prefix ------> | Payload PDUs 431 | ------ End of Data ------> | C sends End of Data 432 ~ ~ 434 When a transport session is first established, the router sends a 435 Reset Query and the cache responds with a data sequence of all data 436 it contains. 438 This Reset Query sequence is also used in response to the cache 439 sending a Cache Reset, the router choosing a new cache, or the router 440 fearing it has otherwise lost its way. 442 To limit the length of time a cache must keep withdraws, a router 443 MUST send either a Serial Query or a Reset Query no less frequently 444 than once an hour. This also acts as a keep alive at the application 445 layer. 447 5.2. Typical Exchange 449 Cache Router 450 ~ ~ 451 | -------- Notify ----------> | (optional) 452 | | 453 | <----- Serial Query ------- | R requests data 454 | | 455 | ----- Cache Response -----> | C tells R C's serial 456 | ------- IPvX Prefix ------> | C sends zero or more 457 | ------- IPvX Prefix ------> | IPv4 and IPv6 Prefix 458 | ------- IPvX Prefix ------> | Payload PDUs 459 | ------ End of Data ------> | C sends End of Data 461 The cache server SHOULD send a notify PDU with its current serial 462 number when the cache's serial changes, with the expectation that the 463 router MAY then issue a serial query earlier than it otherwise might. 465 This is analogous to DNS NOTIFY in [RFC1996]. The cache SHOULD rate 466 limit Serial Notifies to no more frequently than one per minute. 468 When the transport layer is up and either a timer has gone off in the 469 router, or the cache has sent a Notify, the router queries for new 470 data by sending a Serial Query, and the router sends all data newer 471 than the serial in the Serial Query. 473 To limit the length of time a cache must keep old withdraws, a router 474 MUST send either a Serial Query or a Reset Query no less frequently 475 than once an hour. 477 5.3. Cache has Reset 479 Cache Router 480 ~ ~ 481 | <----- Serial Query ------ | R requests data 482 | ------- Cache Reset ------> | C has lost serial 483 | | 484 | <------ Reset Query ------- | R requests new data 485 | | 486 | ----- Cache Response -----> | C tells R C's serial 487 | ------- IPvX Prefix ------> | C sends zero or more 488 | ------- IPvX Prefix ------> | IPv4 and IPv6 Prefix 489 | ------- IPvX Prefix ------> | Payload PDUs 490 | ------ End of Data ------> | C sends End of Data 491 ~ ~ 493 The cache may respond to a Serial Query informing the router that the 494 cache's serial number is no longer commensurate with that of the 495 router. The most likely cause is that the cache was completely 496 restarted when or since the transport session to the router was down. 497 When a router receives this, the router SHOULD attempt to connect to 498 any more preferred caches in its cache list. If there are no more 499 preferred caches it MUST issue a Reset Query and get an entire new 500 load from the cache 502 6. SSH Transport 504 The transport layer session between a router and a cache carries the 505 binary Protocol Data Units (PDUs) in a persistent SSH session. 507 To run over SSH, the client router first establishes an SSH transport 508 connection using the SSH transport protocol, and the client and 509 server exchange keys for message integrity and encryption. The 510 client then invokes the "ssh-userauth" service to authenticate the 511 application, as described in the SSH authentication protocol RFC 4252 513 [RFC4252]. Once the application has been successfully authenticated, 514 the client invokes the "ssh-connection" service, also known as the 515 SSH connection protocol. 517 After the ssh-connection service is established, the client opens a 518 channel of type "session", which results in an SSH session. 520 Once the SSH session has been established, the application invokes 521 the application transport as an SSH subsystem called "rpki-rtr". 522 Subsystem support is a feature of SSH version 2 (SSHv2) and is not 523 included in SSHv1. Running this protocol as an SSH subsystem avoids 524 the need for the application to recognize shell prompts or skip over 525 extraneous information, such as a system message that is sent at 526 shell start-up. 528 It is assumed that the router and cache have exchanged keys out of 529 band by some reasonably secured means. 531 7. Router-Cache Set-Up 533 A cache has the public authentication data for each router it is 534 configured to support. 536 A router may be configured to peer with a selection of caches, and a 537 cache may be configured to support a selection of routers. So each 538 must have the name of each peer and authentication data for each. In 539 addition, in a router, this list has a non-unique preference value 540 for each server in order of preference. The client router attempts 541 to establish a session with each potential serving cache in 542 preference order, and then starts to load data from the highest 543 preference cache to which it can connect and authenticate. The 544 router's list of caches has the following elements: 546 Preference: A cardinal denoting the router's preference to use that 547 cache, the lower the value the more preferred. 549 Name: The IP Address or fully qualified domain name of the cache. 551 Key: The public ssh key of the cache. 553 MyKey: The private ssh key of this client. 555 As caches can not be rigorously synchronous, a client which changes 556 servers can not combine data from different parent caches. 557 Therefore, when a lower preference cache becomes available, if 558 resources allow, it would be prudent for the client to start a new 559 buffer for that cache's data, and only switch to those data when that 560 buffer is fully up to date. 562 8. Deployment Scenarios 564 For illustration, we present three likely deployment scenarios. 566 Small End Site: The small multi-homed end site may wish to outsource 567 the RPKI cache to one or more of their upstream ISPs. They would 568 exchange authentication material with the ISP using some out of 569 band mechanism, and their router(s) would connect to one or more 570 up-streams' caches. The ISPs would likely deploy caches intended 571 for customer use separately from the caches with which their own 572 BGP speakers peer. 574 Large End Site: A larger multi-homed end site might run one or more 575 caches, arranging them in a hierarchy of client caches, each 576 fetching from a serving cache which is closer to the global RPKI. 577 They might configure fall-back peerings to up-stream ISP caches. 579 ISP Backbone: A large ISP would likely have one or more redundant 580 caches in each major PoP, and these caches would fetch from each 581 other in an ISP-dependent topology so as not to place undue load 582 on the global RPKI publication infrastructure. 584 Experience with large DNS cache deployments has shown that complex 585 topologies are ill-advised as it is easy to make errors in the graph, 586 e.g. not maintaining a loop-free condition. 588 Of course, these are illustrations and there are other possible 589 deployment strategies. It is expected that minimizing load on the 590 global RPKI servers will be a major consideration. 592 To keep load on global RPKI services from unnecessary peaks, it is 593 recommended that primary caches which load from the distributed 594 global RPKI not do so all at the same times, e.g. on the hour. 595 Choose a random time, perhaps the ISP's AS number modulo 60 and 596 jitter the inter-fetch timing. 598 9. Security Considerations 600 As this document describes a security protocol, many aspects of 601 security interest are described in the relevant sections. This 602 section points out issues which may not be obvious in other sections. 604 Cache Validation: In order for a collection of caches as described 605 in Section 8 to guarantee a consistent view, they need to be given 606 consistent trust anchors to use in their internal validation 607 process. Distribution of a consistent trust anchor is assumed to 608 be out of band. 610 Cache Peer Identification: As the router initiates an ssh transport 611 session to a cache which it identifies by either IP address or 612 fully qualified domain name, a DNS or address spoofing attack 613 could make the correct cache unreachable. No session would be 614 established, as the authorization keys would not match. 616 Transport Security: The RPKI relies on object, not server or 617 transport, trust. I.e. the IANA root trust anchor is distributed 618 to all caches through some out of band means, and can then be used 619 by each cache to validate certificates and ROAs all the way down 620 the tree. The inter-cache relationships are based on this object 621 security model, hence the inter-cache transport can be lightly 622 protected. 624 But this protocol document assumes that the routers can not do the 625 validation cryptography. Hence the last link, from cache to 626 router, is secured by server authentication and transport level 627 security. This is dangerous, as server authentication and 628 transport have very different threat models than object security. 630 So the strength of the trust relationship and the transport 631 between the router(s) and the cache(s) are critical. You're 632 betting your routing on this. 634 While we can not say the cache must be on the same LAN, if only 635 due to the issue of an enterprise wanting to off-load the cache 636 task to their upstream ISP(s), locality, trust, and control are 637 very critical issues here. The cache(s) really SHOULD be as 638 close, in the sense of controlled and protected (against DDoS, 639 MITM) transport, to the router(s) as possible. It also SHOULD be 640 topologically close so that a minimum of validated routing data 641 are needed to bootstrap a router's access to a cache. 643 10. Glossary 645 The following terms are used with special meaning: 647 Global RPKI: The authoritative data of the RPKI are published in a 648 distributed set of servers at the IANA, RIRs, NIRs, and ISPs, see 649 [I-D.ietf-sidr-repos-struct]. 651 Non-authorative Cache: A coalesced copy of the RPKI which is 652 periodically fetched/refreshed directly or indirectly from the 653 global RPKI using the [rcynic] protocol/tools 655 Cache: The rcynic system is used to gather the distributed data of 656 the RPKI into a validated cache. Trusting this cache further is a 657 matter between the provider of the cache and a relying party. 659 Serial Number: A 32-bit monotonically increasing, cardinal which 660 wraps from 2^32-1 to 0. It denotes the logical version of a 661 cache. A cache increments the value by one when it successfully 662 updates its data from a parent cache or from primary RPKI data. 663 As a cache is rcynicing, new incoming data, and implicit deletes, 664 are marked with the new serial but MUST not be sent until the 665 fetch is complete. A serial number is not commensurate between 666 caches, nor need it be maintained across resets of the cache 667 server. See [RFC1982] on DNS Serial Number Arithmetic for too 668 much detail on serial number arithmetic. 670 11. IANA Considerations 672 This document requests the IANA to create a registry for PDU types. 674 This document requests the IANA to create a registry for Error Codes. 676 In addition, a registry for Version Numbers would be needed if new 677 Version Number is defined in a new RFC. 679 Note to RFC Editor: this section may be replaced on publication as an 680 RFC. 682 12. Acknowledgments 684 The author wishes to thank Rob Austein, Steve Bellovin, Rex Fernando, 685 Russ Housley, Pradosh Mohapatra, Sandy Murphy, Megumi Ninomiya, 686 Robert Raszuk, John Scudder, Ruediger Volk, David Ward, and Bert 687 Wijnen. 689 13. References 691 13.1. Normative References 693 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 694 August 1996. 696 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 697 Requirement Levels", BCP 14, RFC 2119, March 1997. 699 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 700 Authentication Protocol", RFC 4252, January 2006. 702 [rcynic] Austein, R., "rcynic protocol", 703 . 705 13.2. Informative References 707 [I-D.ietf-sidr-arch] 708 Lepinski, M. and S. Kent, "An Infrastructure to Support 709 Secure Internet Routing", draft-ietf-sidr-arch-04 (work in 710 progress), November 2008. 712 [I-D.ietf-sidr-repos-struct] 713 Huston, G., Loomans, R., and G. Michaelson, "A Profile for 714 Resource Certificate Repository Structure", 715 draft-ietf-sidr-repos-struct-01 (work in progress), 716 October 2008. 718 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 719 Changes (DNS NOTIFY)", RFC 1996, August 1996. 721 Author's Address 723 Randy Bush 724 Internet Initiative Japan, Inc. 725 5147 Crystal Springs 726 Bainbridge Island, Washington 98110 727 US 729 Phone: +1 206 780 0431 x1 730 Email: randy@psg.com