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