idnits 2.17.1 draft-ietf-sidr-slurm-03.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. 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: This document describes responses in the JSON [RFC7159] format. JSON members that are not defined here MUST not be used in SLURM Files, however Relying Parties SHOULD ignore such unrecognized JSON members when processing a file. -- The document date (February 11, 2017) is 2630 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) == Unused Reference: 'I-D.ietf-sidr-lta-use-cases' is defined on line 615, but no explicit reference was found in the text == Unused Reference: 'RFC6890' is defined on line 671, but no explicit reference was found in the text == Unused Reference: 'RFC7682' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sidr-bgpsec-algs' is defined on line 692, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sidr-bgpsec-pki-profiles' is defined on line 697, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 708, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-sidr-rpki-rtr-rfc6810-bis-08 -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-18) exists of draft-ietf-sidr-bgpsec-algs-16 == Outdated reference: A later version (-21) exists of draft-ietf-sidr-bgpsec-pki-profiles-18 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDR D. Mandelberg 3 Internet-Draft Unaffiliated 4 Intended status: Standards Track D. Ma 5 Expires: August 15, 2017 ZDNS 6 T. Bruijnzeels 7 RIPE NCC 8 February 11, 2017 10 Simplified Local internet nUmber Resource Management with the RPKI 11 draft-ietf-sidr-slurm-03 13 Abstract 15 The Resource Public Key Infrastructure (RPKI) is a global 16 authorization infrastructure that allows the holder of Internet 17 Number Resources (INRs) to make verifiable statements about those 18 resources. Network operators, e.g., Internet Service Providers 19 (ISPs), can use the RPKI to validate BGP route origination 20 assertions. In the future, ISPs also will be able to use the RPKI to 21 validate the path of a BGP route. However, ISPs may want to 22 establish a local view of the RPKI to control its own network while 23 making use of RPKI data. The mechanisms described in this document 24 provide a simple way to enable INR holders to establish a local, 25 customized view of the RPKI, overriding global RPKI repository data 26 as needed. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 15, 2017. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. RPKI RPs with SLURM . . . . . . . . . . . . . . . . . . . . . 3 65 3. SLURM File and Mechanisms . . . . . . . . . . . . . . . . . . 4 66 3.1. Use of JSON . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.2. SLURM File Overview . . . . . . . . . . . . . . . . . . . 4 68 3.3. SLURM Target . . . . . . . . . . . . . . . . . . . . . . 6 69 3.4. Validation Output Filters . . . . . . . . . . . . . . . . 7 70 3.4.1. Validated ROA Prefix Filters . . . . . . . . . . . . 7 71 3.4.2. BGPsec Assertion Filters . . . . . . . . . . . . . . 8 72 3.5. Locally Added Assertions . . . . . . . . . . . . . . . . 9 73 3.5.1. ROA Prefix Assertions . . . . . . . . . . . . . . . . 9 74 3.5.2. BGPSec Assertions . . . . . . . . . . . . . . . . . . 10 75 3.6. Example of a SLURM File with Filters and Assertions . . . 11 76 4. SLURM File Configuration . . . . . . . . . . . . . . . . . . 12 77 4.1. SLURM File Atomicity . . . . . . . . . . . . . . . . . . 12 78 4.2. Multiple SLURM Files . . . . . . . . . . . . . . . . . . 13 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 6. Security considerations . . . . . . . . . . . . . . . . . . . 14 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 8.1. Informative References . . . . . . . . . . . . . . . . . 14 84 8.2. Normative References . . . . . . . . . . . . . . . . . . 16 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 87 1. Introduction 89 The Resource Public Key Infrastructure (RPKI) is a global 90 authorization infrastructure that allows the holder of Internet 91 Number Resources (INRs) to make verifiable statements about those 92 resources. For example, the holder of a block of IP(v4 or v6) 93 addresses can issue a Route Origination Authorization (ROA) [RFC6482] 94 to authorize an Autonomous System (AS) to originate routes for that 95 block. Internet Service Providers (ISPs) can then use the RPKI to 96 validate BGP routes. (Validation of the origin of a route is 97 described in [RFC6483], and validation of the path of a route is 98 described in [I-D.ietf-sidr-bgpsec-overview].) 100 However, an RPKI relying party may want to override some of the 101 information expressed via putative TAs and the certificates 102 downloaded from the RPKI repository system. For instances, [RFC6491] 103 recommends the creation of ROAs that would invalidate public routes 104 for reserved and unallocated address space, yet some ISPs might like 105 to use BGP and the RPKI with private address space ([RFC1918], 106 [RFC4193], [RFC6598]) or private AS numbers ([RFC1930], [RFC6996]). 107 Local use of private address space and/or AS numbers is consistent 108 with the RFCs cited above, but such use cannot be verified by the 109 global RPKI. This motivates creation of mechanisms that enable a 110 network operator to publish a variant of RPKI hierarchy (for its own 111 use and that of its customers) at its discretion. Additionally, a 112 network operator might wish to make use of a local override 113 capability to protect routes from adverse actions [I-D.ietf-sidr- 114 adverse-actions], until the results of such actions have been 115 addressed. The mechanisms developed to provide this capability to 116 network operators are hereby called Simplified Local internet nUmber 117 Resource Management with the RPKI (SLURM). 119 SLURM allows an operator to create a local view of the global RPKI by 120 generating sets of assertions. For Origin Validation [RFC6483], an 121 assertion is a tuple of {IP prefix, prefix length, maximum length, AS 122 number} as used by rpki-rtr version 0 [RFC6810] and version 1 123 [I-D.ietf-sidr-rpki-rtr-rfc6810-bis]. For BGPsec 124 [I-D.ietf-sidr-bgpsec-overview], an assertion is a tuple of {AS 125 number, subject key identifier, router public key} as used by rpki- 126 rtr version. (For the remainder of this document, these assertions 127 are called Origin Validation assertions and BGPsec assertions, 128 respectively.) 130 1.1. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 2. RPKI RPs with SLURM 138 SLURM provides a simple way to enable INR holders to establish a 139 local, customized view of the RPKI, by overriding RPKI repository 140 data if needed. To that end, an RP with SLURM filters out (removes 141 from consideration for routing decisions) any assertions in the RPKI 142 that are overridden by local Origin Validation assertions and BGPsec 143 assertions. 145 In general, the primary output of an RPKI relying party is the data 146 it sends to routers over the rpki-rtr protocol. The rpki-rtr 147 protocol enables routers to query a relying party for all assertions 148 it knows about (Reset Query) or for an update of only the changes in 149 assertions (Serial Query). The mechanisms specified in this document 150 are to be applied to the result set for a Reset Query, and to both 151 the old and new sets that are compared for a Serial Query. Relying 152 party software MAY modify other forms of output in comparable ways, 153 but that is outside the scope of this document. 155 +--------------+ +---------------------------+ +------------+ 156 | | | | | | 157 | Repositories +--->Local cache of RPKI objects+---> Validation | 158 | | | | | | 159 +--------------+ +---------------------------+ +-----+------+ 160 | 161 +-------------------------------------------------+ 162 | 163 +------v-------+ +------------+ +----------+ +-------------+ 164 | | | | | | | | 165 | SLURM +---> SLURM +---> rpki-rtr +---> BGP Speakers| 166 | Filters | | Assertions | | | | | 167 +--------------+ +------------+ +----------+ +-------------+ 169 Figure 1: SLURM's Position in the Relying Party Stack 171 3. SLURM File and Mechanisms 173 3.1. Use of JSON 175 This document describes responses in the JSON [RFC7159] format. JSON 176 members that are not defined here MUST not be used in SLURM Files, 177 however Relying Parties SHOULD ignore such unrecognized JSON members 178 when processing a file. 180 3.2. SLURM File Overview 182 A SLURM file consists of: 184 o A SLURM Version indication that MUST be 1.0 186 o One or more slurmTarget (Section 3.3) lines: 188 * In this version of SLURM, there are two types of values for the 189 target: ASN or FQDN. If more than one target line is present, 190 all targets must be acceptable to the RP. 192 o Validation Output Filters (Section 3.4), consisting of: 194 * A list of zero or more Prefix Filters, described in 195 Section 3.4.1 197 * A list of zero or more BGPSec Filters, described in 198 Section 3.4.2 200 o Locally Added Assertions (Section 3.5), consisting of: 202 * A list of zero or more Prefix Assertions, described in 203 Section 3.5.1 205 * A list of zero or more BGPSec Assertions, described in 206 Section 3.5.2 208 In the envisioned typical use case, a relying party uses both output 209 filtering and locally added assertions. In this case, the resulting 210 assertions MUST be the same as if output filtering were performed 211 before locally adding assertions. I.e., locally added assertions 212 MUST NOT be removed by output filtering. 214 The following JSON structure with JSON members represents a SLURM 215 file that has no filters or assertions: 217 { 218 "slurmVersion": 1.0, 219 "slurmTarget": [], 220 "validationOutputFilters": { 221 "prefixFilters": [], 222 "bgpsecFilters": [] 223 }, 224 "locallyAddedAsserstions": { 225 "prefixAssertions": [], 226 "bgpsecAssertions": [] 227 } 228 } 230 Empty SLURM File 232 3.3. SLURM Target 234 The header MAY specify a target. If present, the target string 235 identifies the environment in which the SLURM file is intended to be 236 used. The meaning of the target string, if present, is determined by 237 the user. If a target is present, a relying party SHOULD verify that 238 the target is an acceptable value, and reject the SLURM file if the 239 target is not acceptable. If not present, it's up to local policy to 240 determine whether to accept a SLURM file. 242 For instance, a large ISP may want some of its ASes to establish a 243 local view of RPKI while the others not. Accordingly, this ISP needs 244 to make its RPs aware of this distinction for different BGP speakers 245 by adding ASN(s) to SLURM file target, such as a target value of 246 "asn=65536". 248 "slurmTarget": [ 249 { 250 "asn": 65536 251 } 252 ] 254 slurmTarget example 1 256 Also, for instance, an organization may share one trusted third-party 257 SLURM file source. For the local control, or in the case of 258 Emergency Response Team Coordination, the SLURM file source may 259 generate a SLURM file that is to be applied to only one specific RP. 260 This file can take advantage of the "target" element to restrict the 261 ASes that will accept and use the file. Accordingly, the SLURM file 262 source needs to indicate which RP(s) should make use of the file by 263 adding the domain name(s) of the RP(s) to the SLURM file target, 264 e.g., a target value of "hostname=rpki.example.com". 266 "slurmTarget": [ 267 { 268 "hostname": "rpki.example.com" 269 } 270 ] 272 slurmTarget example 2 274 3.4. Validation Output Filters 276 3.4.1. Validated ROA Prefix Filters 278 The RP can configure zero or more Validated ROA Prefix Filters 279 (Prefix Filters in short). Each Prefix Filter can contain either an 280 IPv4 or IPv6 prefix and/or an AS number. It is RECOMMENDED that an 281 explanatory comment is included with each Prefix Filter, so that it 282 can be shown to users of the RP software. 284 Any Validated ROA Prefix (VRP, [RFC6811]) that matches any configured 285 Prefix Filter MUST be removed from the RP's output. 287 A Validated ROA Prefix is considered to match with a Prefix Filter if 288 one of the following cases applies: 290 1. A Prefix Filter contains an IPv4 or IPv6 Prefix only, a VRP is 291 considered to match the filter if the VRP Prefix is equal to or 292 subsumed by the Prefix Filter. 294 2. A Prefix Filter contains an AS number only, a VRP is considered 295 to match the filter if the VRP ASN matches the Prefix Filter ASN. 297 3. A Prefix Filter contains both an IPv4 or IPv6 prefix AND an AS 298 Number, a VRP is considered to match if the VRP Prefix is equal 299 to or subsumed by the Prefix Filter AND the VRP ASN matches the 300 Prefix Filter ASN 302 The following JSON structure represents an array of "prefixFilters" 303 with an element for each use case listed above: 305 "prefixFilters": [ 306 { 307 "prefix": "192.0.2.0/24", 308 "comment": "Filter all VRPs encompassed by prefix" 309 }, 310 { 311 "asn": 64496, 312 "comment": "Filter all VRPs matching ASN" 313 }, 314 { 315 "prefix": "198.51.100.0/24", 316 "asn": 64497, 317 "comment": "Filter all VRPs encompassed by prefix, matching ASN" 318 } 319 ] 321 prefixFilters examples 323 3.4.2. BGPsec Assertion Filters 325 The RP can configure zero or more BGPSec Assertion Filters (BGPSec 326 Filters in short). Each BGPSec Filter can contain an AS number and/ 327 or a Router SKI. 329 The Router SKI is the Base64 [RFC4648] encoding of a router 330 certificate's Subject Key Identifier, as described in [I-D.ietf-sidr- 331 bgpsec-pki-profiles] and [RFC6487]. This is the value of the ASN.1 332 OCTET STRING without the ASN.1 tag or length fields. 334 Furthermore it is RECOMMENDED that an explanatory comment is included 335 with each BGPSec Filter, so that it can be shown to users of the RP 336 software. 338 Any BGPSec Assertion that matches any configured BGPSec Filter MUST 339 be removed from the RPs output. 341 A BGPSec Assertion is considered to match with a BGPSec Filter if one 342 of the following cases applies: 344 1. If the BGPSec Filter contains an AS number only, a BGPSec 345 Assertion is considered to match if the Assertion ASN matches the 346 Filter ASN. 348 2. If the BGPSec Filter contains a Router SKI only, a BGPSec 349 Assertion is considered to match if the Assertion Router SKI 350 matches the Filter Router SKI. 352 3. If the BGPSec Filter contains both an AS number AND a Router SKI, 353 then a BGPSec Assertion is considered to match if both the 354 Assertion ASN matches the Filter ASN and the Assertion Router SKI 355 matches the Filter Router SKI. 357 The following JSON structure represents an array of "bgpsecFilters" 358 with an element for each use case listed above: 360 "bgpsecFilters": [ 361 { 362 "asn": 64496, 363 "comment": "Filter all keys for ASN" 364 }, 365 { 366 "routerSKI": "", 367 "comment": "Filter key matching Router SKI" 368 }, 369 { 370 "asn": 64497, 371 "routerSKI": "", 372 "comment": "Filter key for ASN 64497 matching Router SKI" 373 } 374 ] 376 bgpsecFilters examples 378 3.5. Locally Added Assertions 380 3.5.1. ROA Prefix Assertions 382 Each relying party is locally configured with a (possibly empty) list 383 of ROA Prefix Assertions. This list is added to the RP's output. 385 Each ROA Prefix Assertion MUST contain an IPv4 or IPv6 prefix, an AS 386 number, optionally a MaxLength and optionally a comment that can be 387 shown to users of the RP software. 389 The following JSON structure represents an array of 390 "prefixAssertions" with an element for each use case listed above: 392 "prefixAssertions": [ 393 { 394 "asn": 64496, 395 "prefix": "198.51.100.0/24", 396 "comment": "My other important route" 397 }, 398 { 399 "asn": 64496, 400 "prefix": "2001:DB8::/32", 401 "maxPrefixLength": 48, 402 "comment": "My other important de-aggregated routes" 403 } 404 ] 406 prefixAssertions examples 408 3.5.2. BGPSec Assertions 410 Each relying party is locally configured with a (possibly empty) list 411 of BGPSec Assertions. This list is added to the RP's output. 413 Each BGPSec Assertion MUST contain an AS number, a Router SKI, the 414 Router Public Key, and optionally a comment that can be shown to 415 users of the RP software. 417 The Router SKI is the Base64 [RFC4648] encoding of a router 418 certificate's Subject Key Identifer, as described in [I-D.ietf-sidr- 419 bgpsec-pki-profiles] and [RFC6487]. This is the value of the ASN.1 420 OCTET STRING without the ASN.1 tag or length fields. 422 The Router Public Key is the Base64 [RFC4648] encoding of a router 423 public key's subjectPublicKeyInfo value, as described in [I-D.ietf- 424 sidr-bgpsec-algs]. This is the full ASN.1 DER encoding of the 425 subjectPublicKeyInfo, including the ASN.1 tag and length values of 426 the subjectPublicKeyInfo SEQUENCE. 428 The following JSON structure represents an array of 429 "bgpsecAssertions" with one element as described above: 431 "bgpsecAssertions": [ 432 { 433 "asn": 64496, 434 "comment" : "My known key for my important ASN", 435 "SKI": "", 436 "publicKey": "" 437 } 438 ] 440 prefixAssertions examples 442 3.6. Example of a SLURM File with Filters and Assertions 444 The following JSON structure represents an example of a SLURM file 445 that uses all the elements described in the previous sections: 447 { 448 "slurmVersion": 1.0, 449 "slurmTarget":[ 450 { 451 "asn":65536 452 }, 453 { 454 "hostname":"rpki.example.com" 455 } 456 ], 457 "validationOutputFilters": { 458 "prefixFilters": [ 459 { 460 "prefix": "192.0.2.0/24", 461 "comment": "Filter all VRPs encompassed by prefix" 462 }, 463 { 464 "asn": 64496, 465 "comment": "Filter all VRPs matching ASN" 466 }, 467 { 468 "prefix": "198.51.100.0/24", 469 "asn": 64497, 470 "comment": "Filter all VRPs encompassed by prefix, matching ASN" 471 } 472 ], 473 "bgpsecFilters": [ 474 { 475 "asn": 64496, 476 "comment": "Filter all keys for ASN" 478 }, 479 { 480 "routerSKI": "Zm9v", 481 "comment": "Filter key matching Router SKI" 482 }, 483 { 484 "asn": 64497, 485 "routerSKI": "YmFy", 486 "comment": "Filter key for ASN 64497 matching Router SKI" 487 } 488 ] 489 }, 490 "locallyAddedAsserstions": { 491 "prefixAssertions": [ 492 { 493 "asn": 64496, 494 "prefix": "198.51.100.0/24", 495 "comment": "My other important route" 496 }, 497 { 498 "asn": 64496, 499 "prefix": "2001:DB8::/32", 500 "maxPrefixLength": 48, 501 "comment": "My other important de-aggregated routes" 502 } 503 ], 504 "bgpsecAssertions": [ 505 { 506 "asn": 64496, 507 "comment" : "My known key for my important ASN", 508 "SKI": "", 509 "publicKey": "" 510 } 511 ] 512 } 513 } 515 Full SLURM File 517 4. SLURM File Configuration 519 4.1. SLURM File Atomicity 521 To ensure local consistency, the effect of SLURM MUST be atomic. 522 That is, the output of the relying party must be either the same as 523 if SLURM file were not used, or it must reflect the entire SLURM 524 configuration. For an example of why this is required, consider the 525 case of two local routes for the same prefix but different origin AS 526 numbers. Both routes are configured with Locally Adding Assertions. 527 If neither addition occurs, then both routes could be in the unknown 528 state [RFC6483]. If both additions occur then both routes would be 529 in the valid state. However, if one addition occurs and the other 530 does not, then one could be invalid while the other is valid. 532 4.2. Multiple SLURM Files 534 An implementation MAY support the concurrent use of multiple SLURM 535 files. In this case, the resulting inputs to Validation Output 536 Filtering and Locally Adding Assertions are the respective unions of 537 the inputs from each file. The envisioned typical use case for 538 multiple files is when the files have distinct scopes. For instance, 539 operators of two distinct networks may resort to one RP system to 540 frame routing decisions. As such, they probably deliver SLURM files 541 to this RP respectively. Before an RP configures SLURM files from 542 different source it MUST make sure there is no internal conflict 543 among the INR assertions in these SLURM files. To do so, the RP 544 SHOULD check the entries of SLURM file with regard to overlaps of the 545 INR assertions and report errors to the sources that created these 546 SLURM files in question. 548 If a problem is detected with the INR assertions in these SLURM 549 files, the RP MUST NOT use them, and SHOULD issue a warning as error 550 report in the following cases: 552 1. There may be conflicting changes to Origin Validation 553 assertions if there exists an IP address X and distinct SLURM 554 files Y,Z such that X is contained by any prefix in any 555 or in file Y and X is 556 contained by any prefix in any or 557 in file Z. 559 2. There may be conflicting changes to BGPsec assertions if there 560 exists an AS number X and distinct SLURM files Y,Z such that X 561 is used in any or in file Y and X 562 is used in any or in file Z. 564 5. IANA Considerations 566 None 568 6. Security considerations 570 The mechanisms described in this document provide a network operator 571 with additional ways to control make use of RPKI data while 572 preserving autonomy in address space and ASN management. These 573 mechanisms are applied only locally; they do not influence how other 574 network operators interpret RPKI data. Nonetheless, care should be 575 taken in how these mechanisms are employed. Note that it also is 576 possible to use SLURM to (locally) manipulate assertions about non- 577 private INRs, e.g., allocated address space that is globally routed. 578 For example, a SLURM file may be used to override RPKI data that a 579 network operator believes has been corrupted by an adverse action. 580 Network operators who elect to use SLURM in this fashion should use 581 extreme caution. 583 The goal of the mechanisms described in this document is to enable an 584 RP to create its own view of the RPKI, which is intrinsically a 585 security function. An RP using a SLURM file is trusting the 586 assertions made in that file. Errors in the SLURM file used by an RP 587 can undermine the security offered by the RPKI, to that RP. It could 588 declare as invalid ROAs that would otherwise be valid, and vice 589 versa. As a result, an RP must carefully consider the security 590 implications of the SLURM file being used, especially if the file is 591 provided by a third party. 593 Additionally, each RP using SLURM MUST ensure the authenticity and 594 integrity of any SLURM file that it uses. Initially, the SLURM file 595 may be pre-configured out of band, but if the RP updates its SLURM 596 file over the network, it MUST verify the authenticity and integrity 597 of the updated SLURM file. 599 7. Acknowledgements 601 The authors would like to thank Stephen Kent for his guidance and 602 detailed reviews of this document. Thanks go to Wei Wang for the 603 idea behind the target command, to Richard Hansen for his careful 604 reviews and Hui Zou for her editorial assistance. 606 8. References 608 8.1. Informative References 610 [I-D.ietf-sidr-bgpsec-overview] 611 Lepinski, M. and S. Turner, "An Overview of BGPsec", 612 draft-ietf-sidr-bgpsec-overview-08 (work in progress), 613 June 2016. 615 [I-D.ietf-sidr-lta-use-cases] 616 Bush, R., "Use Cases for Localized Versions of the RPKI", 617 draft-ietf-sidr-lta-use-cases-07 (work in progress), July 618 2016. 620 [I-D.ietf-sidr-rpki-rtr-rfc6810-bis] 621 Bush, R. and R. Austein, "The Resource Public Key 622 Infrastructure (RPKI) to Router Protocol", draft-ietf- 623 sidr-rpki-rtr-rfc6810-bis-08 (work in progress), January 624 2017. 626 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 627 and E. Lear, "Address Allocation for Private Internets", 628 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 629 . 631 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 632 selection, and registration of an Autonomous System (AS)", 633 BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, 634 . 636 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 637 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 638 . 640 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 641 Origin Authorizations (ROAs)", RFC 6482, 642 DOI 10.17487/RFC6482, February 2012, 643 . 645 [RFC6483] Huston, G. and G. Michaelson, "Validation of Route 646 Origination Using the Resource Certificate Public Key 647 Infrastructure (PKI) and Route Origin Authorizations 648 (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012, 649 . 651 [RFC6491] Manderson, T., Vegoda, L., and S. Kent, "Resource Public 652 Key Infrastructure (RPKI) Objects Issued by IANA", 653 RFC 6491, DOI 10.17487/RFC6491, February 2012, 654 . 656 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 657 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 658 Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 659 2012, . 661 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 662 Infrastructure (RPKI) to Router Protocol", RFC 6810, 663 DOI 10.17487/RFC6810, January 2013, 664 . 666 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 667 Austein, "BGP Prefix Origin Validation", RFC 6811, 668 DOI 10.17487/RFC6811, January 2013, 669 . 671 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 672 "Special-Purpose IP Address Registries", BCP 153, 673 RFC 6890, DOI 10.17487/RFC6890, April 2013, 674 . 676 [RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for 677 Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July 678 2013, . 680 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 681 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 682 2014, . 684 [RFC7682] McPherson, D., Amante, S., Osterweil, E., Blunk, L., and 685 D. Mitchell, "Considerations for Internet Routing 686 Registries (IRRs) and Routing Policy Configuration", 687 RFC 7682, DOI 10.17487/RFC7682, December 2015, 688 . 690 8.2. Normative References 692 [I-D.ietf-sidr-bgpsec-algs] 693 Turner, S., "BGPsec Algorithms, Key Formats, & Signature 694 Formats", draft-ietf-sidr-bgpsec-algs-16 (work in 695 progress), November 2016. 697 [I-D.ietf-sidr-bgpsec-pki-profiles] 698 Reynolds, M., Turner, S., and S. Kent, "A Profile for 699 BGPsec Router Certificates, Certificate Revocation Lists, 700 and Certification Requests", draft-ietf-sidr-bgpsec-pki- 701 profiles-18 (work in progress), July 2016. 703 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 704 Requirement Levels", BCP 14, RFC 2119, 705 DOI 10.17487/RFC2119, March 1997, 706 . 708 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 709 Resource Identifier (URI): Generic Syntax", STD 66, 710 RFC 3986, DOI 10.17487/RFC3986, January 2005, 711 . 713 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 714 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 715 . 717 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 718 X.509 PKIX Resource Certificates", RFC 6487, 719 DOI 10.17487/RFC6487, February 2012, 720 . 722 Authors' Addresses 724 David Mandelberg 725 Unaffiliated 727 Email: david@mandelberg.org 729 Di Ma 730 ZDNS 731 4 South 4th St. Zhongguancun 732 Haidian, Beijing 100190 733 China 735 Email: madi@zdns.cn 737 Tim Bruijnzeels 738 RIPE NCC 739 Singel 258 740 Amsterdam 1016 AB 741 Netherlands 743 Email: tim@ripe.net