-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft-maditimbru-sidrops-rfc8416-bis-01.xml
799 lines (746 loc) · 35.7 KB
/
draft-maditimbru-sidrops-rfc8416-bis-01.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
<?xml version="1.0" encoding="utf-8"?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.miek.nl" -->
<rfc version="3" ipr="trust200902" docName="draft-maditimbru-rfc8416-bis-01" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude" obsoletes="8416" indexInclude="false" consensus="true">
<front>
<title abbrev="SLURM v2">Simplified Local Internet Number Resource Management with the RPKI (SLURM)</title><seriesInfo value="draft-maditimbru-rfc8416-bis-01" status="standard" name="Internet-Draft"></seriesInfo>
<author initials="D." surname="Ma" fullname="Di Ma"><organization>ZDNS</organization><address><postal><street></street>
</postal><email>[email protected]</email>
</address></author><author initials="T." surname="Bruijnzeels" fullname="Tim Bruijnzeels"><organization>NLnet Labs</organization><address><postal><street></street>
</postal><email>[email protected]</email>
<uri>https://www.nlnetlabs.nl/</uri>
</address></author><date/>
<area>Internet</area>
<workgroup></workgroup>
<abstract>
<t>The Resource Public Key Infrastructure (RPKI) is a global
authorization infrastructure that allows the holder of Internet
Number Resources (INRs) to make verifiable statements about those
resources. Network operators, e.g., Internet Service Providers
(ISPs), can use the RPKI to validate BGP route origin assertions.
ISPs can also use the RPKI to validate the path of a BGP route.
However, ISPs may want to establish a local view of exceptions to the
RPKI data in the form of local filters and additions. The mechanisms
described in this document provide a simple way to enable INR holders
to establish a local, customized view of the RPKI, overriding global
RPKI repository data as needed.</t>
</abstract>
</front>
<middle>
<section anchor="requirements-notation"><name>Requirements notation</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in BCP 14 <xref target="RFC2119"></xref>
<xref target="RFC8174"></xref> when, and only when, they appear in all capitals, as shown here.</t>
</section>
<section anchor="introduction"><name>Introduction</name>
<t>The Resource Public Key Infrastructure (RPKI) is a global
authorization infrastructure that allows the holder of Internet
Number Resources (INRs) to make verifiable statements about those
resources. For example, the holder of a block of IP(v4 or v6)
addresses can issue a Route Origin Authorization (ROA) <xref target="RFC6482"></xref> to
authorize an Autonomous System (AS) to originate routes for that
block. Internet Service Providers (ISPs) can then use the RPKI to
validate BGP routes. (Validation of the origin of a route is
described in <xref target="RFC6811"></xref>, BGPSec validation of the path of a route
is described in <xref target="RFC8205"></xref>, and ASPA based verification of the path
is decsribed in <xref target="I-D.ietf-sidrops-aspa-verification"></xref>.</t>
<t>However, an RPKI Relying Party (RP) may want to override some of the
information expressed via configured Trust Anchors (TAs) and the
certificates downloaded from the RPKI repository system. For
instance, <xref target="RFC6491"></xref> recommends the creation of ROAs that would
invalidate public routes for reserved and unallocated address space,
yet some ISPs might like to use BGP and the RPKI with private address
space (see <xref target="RFC1918"></xref>, <xref target="RFC4193"></xref>, and <xref target="RFC6598"></xref>) or private AS numbers
(see <xref target="RFC1930"></xref> and <xref target="RFC6996"></xref>). Local use of private address space
and/or AS numbers is consistent with the RFCs cited above, but such
use cannot be verified by the global RPKI. This motivates creation
of mechanisms that enable a network operator to publish, at its
discretion, an exception to the RPKI in the form of filters and
additions (for its own use and that of its customers). Additionally,
a network operator might wish to make use of a local override
capability to protect routes from adverse actions <xref target="RFC8211"></xref>, until
the results of such actions have been addressed. The mechanisms
developed to provide this capability to network operators are hereby
called "Simplified Local Internet Number Resource Management with the
RPKI (SLURM)".</t>
</section>
<section anchor="rp-with-slurm"><name>RP with SLURM</name>
<t>SLURM provides a simple way to enable an RP to establish a local,
customized view of the RPKI, overriding RPKI repository data if
needed. To that end, an RP with SLURM can filter out (i.e., removes
from consideration for routing decisions) ROA Prefix, ASPA and BGPSec
assertions in the RPKI, and can add local assertions instead or in
addition to the ones found in the RPKI.</t>
<t>In general, the primary output of an RP is the data it sends to
routers over the RPKI-Router protocol <xref target="RFC8210"></xref>. The RPKI-Router
protocol enables routers to query an RP for all assertions it knows
about (Reset Query) or for an update of only the changes in
assertions (Serial Query). The mechanisms specified in this document
are to be applied to the result set for a Reset Query and to both the
old and new sets that are compared for a Serial Query. RP software
may modify other forms of output in comparable ways, but that is
outside the scope of this document.</t>
<figure><name>SLURM's Position in the RP Stack
</name>
<sourcecode type="ascii-art">+--------------+ +---------------------------+ +------------+
| | | | | |
| Repositories +--->Local cache of RPKI objects+---> Validation |
| | | | | |
+--------------+ +---------------------------+ +-----+------+
|
+-------------------------------------------------+
|
+------v-------+ +------------+ +-----------+ +-------------+
| | | | | | | |
| SLURM +---> SLURM +--->RPKI-Router+---> BGP Speakers|
| Filters | | Assertions | | Protocol | | |
+--------------+ +------------+ +-----------+ +-------------+
</sourcecode>
</figure>
</section>
<section anchor="slurm-files-and-mechanisms"><name>SLURM Files and Mechanisms</name>
<section anchor="use-of-json"><name>Use of JSON</name>
<t>SLURM filters and assertions are specified in JSON format <xref target="RFC8259"></xref>.
JSON members that are not defined here MUST NOT be used in SLURM
files. An RP MUST consider any deviations from the specifications to
be errors. Future additions to the specifications in this document
MUST use an incremented value for the "slurmVersion" member.</t>
</section>
<section anchor="slurm-file-overview"><name>SLURM File Overview</name>
<t>A SLURM file consists of a single JSON object containing following members:</t>
<ul>
<li>A "slurmVersion" member that MUST be set to 2, encoded as a number</li>
<li><t>A "validationOutputFilters" member (Section 4.3), whose value is
an object. The object MUST contain exactly three members:</t>
<ul>
<li>A "prefixFilters" member, whose value is described in
Section 4.3.1.</li>
<li>A "bgpsecFilters" member, whose value is described in
Section 4.3.2.</li>
<li>A "aspaFilters" member, whose value is described in
Section 4.3.3.</li>
</ul></li>
<li><t>A "locallyAddedAssertions" member (Section 3.4), whose value is an
object. The object MUST contain exactly three members:</t>
<ul>
<li>A "prefixAssertions" member, whose value is described in
Section 4.4.1.</li>
<li>A "bgpsecAssertions" member, whose value is described in
Section 4.4.2.</li>
<li>A "aspaAssertions" member, whose value is described in
Section 4.4.3.</li>
</ul></li>
</ul>
<t>In the envisioned typical use case, an RP uses both Validation Output
Filters and Locally Added Assertions. In this case, the resulting
assertions MUST be the same as if output filtering were performed
before locally adding assertions; that is, Locally Added Assertions
MUST NOT be removed by output filtering.</t>
<t>The following JSON structure with JSON members represents a SLURM
file that has no filters or assertions:</t>
<figure><name>Empty SLURM File
</name>
<sourcecode type="ascii-art">{
"slurmVersion": 2,
"validationOutputFilters": {
"prefixFilters": [],
"bgpsecFilters": [],
"aspaFilters": []
},
"locallyAddedAssertions": {
"prefixAssertions": [],
"bgpsecAssertions": [],
"aspaAssertions": []
}
}
</sourcecode>
</figure>
</section>
<section anchor="validation-output-filters"><name>Validation Output Filters</name>
<section anchor="validated-roa-prefix-filters"><name>Validated ROA Prefix Filters</name>
<t>The RP can configure zero or more Validated ROA Prefix Filters
("Prefix Filters" for short). Each Prefix Filter can contain either
an IPv4 or IPv6 prefix and/or an ASN. It is RECOMMENDED that an
explanatory comment is included with each Prefix Filter so that it
can be shown to users of the RP software.</t>
<t>The above is expressed as a value of the "prefixFilters" member, as
an array of zero or more objects. Each object MUST contain either 1)
one of the following members or 2) one of each of the following
members.</t>
<ul>
<li><t>A "prefix" member, whose value is a string representing either an
IPv4 prefix <xref target="RFC4632"></xref> or an IPv6 prefix (<xref target="RFC5952"></xref>).</t>
</li>
<li><t>An "asn" member, whose value is a number.</t>
</li>
</ul>
<t>In addition, each object MAY contain one optional "comment" member,
whose value is a string.</t>
<t>The following example JSON structure represents a "prefixFilters"
member with an array of example objects for each use case listed
above:</t>
<figure><name>"prefixFilters" Examples
</name>
<sourcecode type="ascii-art">"prefixFilters": [
{
"prefix": "192.0.2.0/24",
"comment": "All VRPs encompassed by prefix"
},
{
"asn": 64496,
"comment": "All VRPs matching ASN"
},
{
"prefix": "198.51.100.0/24",
"asn": 64497,
"comment": "All VRPs encompassed by prefix, matching ASN"
}
]
</sourcecode>
</figure>
<t>Any Validated ROA Payload (VRP) [RFC6811] that matches any configured
Prefix Filter MUST be removed from the RP's output.</t>
<t>A VRP is considered to match with a Prefix Filter if one of the
following cases applies:</t>
<ol>
<li><t>If the Prefix Filter only contains an IPv4 or IPv6 prefix, the
VRP is considered to match the filter if the VRP prefix is equal
to or covered by the Prefix Filter prefix.</t>
</li>
<li><t>If the Prefix Filter only contains an ASN, the VRP is considered
to match the filter if the VRP ASN matches the Prefix Filter ASN.</t>
</li>
<li><t>If the Prefix Filter contains both an IPv4 or IPv6 prefix and an
ASN, the VRP is considered to match if the VRP prefix is equal to
or covered by the Prefix Filter prefix and the VRP ASN matches
the Prefix Filter ASN.</t>
</li>
</ol>
</section>
<section anchor="bgpsec-assertion-filters"><name>BGPsec Assertion Filters</name>
<t>The RP can configure zero or more BGPsec Assertion Filters ("BGPsec
Filters" for short). Each BGPsec Filter can contain an ASN and/or
the Base64 <xref target="RFC4648"></xref> encoding of a Router Subject Key Identifier
(SKI), as described in <xref target="RFC8209"></xref> and <xref target="RFC6487"></xref>. It is RECOMMENDED
that an explanatory comment is also included with each BGPsec Filter,
so that it can be shown to users of the RP software.</t>
<t>The above is expressed as a value of the "bgpsecFilters" member, as
an array of zero or more objects. Each object MUST contain one of
either, or one each of both following members:</t>
<ul>
<li><t>An "asn" member, whose value is a number</t>
</li>
<li><t>An "SKI" member, whose value is the Base64 encoding without
trailing '=' (Section 5 of <xref target="RFC4648"></xref>) of the certificate's Subject
Key Identifier as described in Section 4.8.2 of <xref target="RFC6487"></xref>. (This
is the value of the ASN.1 OCTET STRING without the ASN.1 tag or
length fields.)</t>
</li>
</ul>
<t>In addition, each object MAY contain one optional "comment" member,
whose value is a string.</t>
<t>The following example JSON structure represents a "bgpsecFilters"
member with an array of example objects for each use case listed
above:</t>
<figure><name>"bgpsecFilters" Examples
</name>
<sourcecode type="ascii-art">"bgpsecFilters": [
{
"asn": 64496,
"comment": "All keys for ASN"
},
{
"SKI": "<Base 64 of some SKI>",
"comment": "Key matching Router SKI"
},
{
"asn": 64497,
"SKI": "<Base 64 of some SKI>",
"comment": "Key for ASN 64497 matching Router SKI"
}
]
</sourcecode>
</figure>
<t>Any BGPsec Assertion that matches any configured BGPsec Filter MUST
be removed from the RP's output. A BGPsec Assertion is considered to
match with a BGPsec Filter if one of the following cases applies:</t>
<ol>
<li><t>If the BGPsec Filter only contains an ASN, a BGPsec Assertion is
considered to match if the Assertion ASN matches the Filter ASN.</t>
</li>
<li><t>If the BGPsec Filter only contains an SKI, a BGPsec Assertion is
considered to match if the Assertion Router SKI matches the Filter
SKI.</t>
</li>
<li><t>If the BGPsec Filter contains both an ASN and a Router SKI, then
a BGPsec Assertion is considered to match if both the Assertion
ASN matches the Filter ASN and the Assertion Router SKI matches
the Filter SKI.</t>
</li>
</ol>
</section>
<section anchor="aspa-filters"><name>ASPA Filters</name>
<t>The RP can configure zero or more ASPA Filters. Each ASPA Filter can
contain a customer ASN and/or a list of providers ASNs. It is RECOMMENDED
that an explanatory comment is included with each ASPA Filter so that it
can be shown to users of the RP software.</t>
<t>The above is expressed as a value of the "aspaFilters" member, as an array
of zero or more objects. Each object MUST contain at least one of the
following members:</t>
<ul>
<li>A "customerAsid" member, whose value is a number representing an ASPA
Customer Autonomous System as described in section 3.2 of
<xref target="I-D.ietf-sidrops-aspa-profile"></xref>.</li>
<li>A "providers" member, whose value is an array of 1 or more numbers
representing ASPA provider ASes as described in section 3.3 of
<xref target="I-D.ietf-sidrops-aspa-profile"></xref>.</li>
</ul>
<t>In addition, each object MAY contain one optional "comment" member,
whose value is a string.</t>
<t>The following example JSON structure represents a "aspaFilters" member
with an array of example objects for each use case listed above:</t>
<figure><name>"aspaFilters" Examples
</name>
<sourcecode type="ascii-art">{
"aspaFilters": [
{
"customerAsid": 64496,
"comment": "Filter out all VAPs that have 64496 as Customer ASID"
},
{
"customerAsid": 64497,
"providers": [ 64498, 64499],
"comment": "Filter some providers with 64497 as Customer ASID"
},
{
"providers": [ 65003 ],
"comment": "Never accept 65003 as a valid provider."
}
]
}
</sourcecode>
</figure>
<section anchor="aspa-unions-and-filters"><name>ASPA Unions and Filters</name>
<t>Before applying any ASPA filter an RP MUST first obtain a set of
validated ASPA objects, extract the Validated ASPA Payload (VAP) for
each object, and then make unions of all VAPs pertaining to the same
customer ASN. A unified VAP for a customer ASN will contain the union
of all provider ASes that are contained in any of the source VAPs.</t>
<t>Example using human readable ASPA notation <xref target="I-D.timbru-sidrops-aspa-notation"></xref>:</t>
<figure><name>VAP Customer Only Filter Example
</name>
<sourcecode type="ascii-art">Given VAPs from ASPA Objects:
AS65000 => AS65001, AS65002, AS65003,
AS65000 => AS65002, AS65003, AS65004
Unified VAP:
AS65000 => AS65001, AS65002, AS65003, AS65004
</sourcecode>
</figure>
<section anchor="customer-as-only-filter"><name>Customer AS Only Filter</name>
<t>If an ASPA filter specifies a "customerAsid" only, then the unified VAP
matching the Customer Autonomous System MUST be removed entirely.</t>
<t>Example using human readable ASPA notation:</t>
<figure><name>VAP Customer Only Filter Example
</name>
<sourcecode type="ascii-art">Given VAP:
AS65000 => AS65001, AS65002
Filter:
"customerAsid": AS65000
Result:
VAP is removed completely
</sourcecode>
</figure>
</section>
<section anchor="providers-only-filter"><name>Providers Only Filter</name>
<t>If an ASPA filter specifies a "providers" array only, then matching
provider AS statements MUST be removed from any unified VAP, i.e.
regardless of the "customerAsid" used.</t>
<t>Example using human readable ASPA notation:</t>
<figure><name>VAP Provider Only Filter Example
</name>
<sourcecode type="ascii-art">Given VAPs:
AS65000 => AS65001, AS65002, AS65003, AS65004
AS65005 => AS65001, AS65002, AS65003, AS65004
Filter:
"providers": [ 65001, 65002, 65003]
Result:
AS65000 => AS65001, AS65004
AS65005 => AS65001, AS65004
</sourcecode>
</figure>
</section>
<section anchor="customer-as-and-providers-filter"><name>Customer AS and Providers Filter</name>
<t>If a filter specifies both "customerAsid" and "providers", then the
provider filter is applied only to the unified VAP that matches the
Customer Autonomous System.</t>
<t>Example using human readable ASPA notation:</t>
<figure><name>VAP Customer and Provider Filter Example
</name>
<sourcecode type="ascii-art">Given VAPs:
AS65000 => AS65001, AS65002, AS65003, AS65004
AS65005 => AS65001, AS65002, AS65003, AS65004
Filter:
"customerAsid": 65000,
"providers": [ 65002, 65003, 65004 ]
Result:
AS65000 => AS65001
AS65005 => AS65001, AS65002, AS65003, AS65004
</sourcecode>
</figure>
</section>
<section anchor="aspa-filter-considerations"><name>ASPA Filter Considerations</name>
<t>It should be noted that while this standard allows for fine-grained ASPA
filters to be specified, no specific way to filter is recommended here.
In other words, this document aims to give operators set logic oriented
tools to manipulate the VAPs that would be communicated to their routers,
but it does not make any assumptions about use cases and best practices.</t>
<t>This design choice is based on the conviction that not all possible use
cases can be known at this time, and that more deployment experience is
needed before best practices can be formulated. It is however encouraged
that this discussion takes place, and that, if needed, a follow-up document
that describes use cases and best practices is made in future.</t>
</section>
</section>
</section>
</section>
<section anchor="locally-added-assertions"><name>Locally Added Assertions</name>
<section anchor="roa-prefix-assertions"><name>ROA Prefix Assertions</name>
<t>Each RP is locally configured with a (possibly empty) array of ROA
Prefix Assertions ("Prefix Assertions" for short). Each ROA Prefix
Assertion MUST contain an IPv4 or IPv6 prefix and an ASN. It MAY
include a value for the maximum length. It is RECOMMENDED that an
explanatory comment is also included with each so that it can be
shown to users of the RP software.</t>
<t>The above is expressed as a value of the "prefixAssertions" member,
as an array of zero or more objects. Each object MUST contain one of
each of the following members:</t>
<ul>
<li><t>A "prefix" member, whose value is a string representing either an
IPv4 prefix (see Section 3.1 of <xref target="RFC4632"></xref>) or an IPv6 prefix (see
<xref target="RFC5952"></xref>).</t>
</li>
<li><t>An "asn" member, whose value is a number.</t>
</li>
</ul>
<t>In addition, each object MAY contain one of each of the following
members:</t>
<ul>
<li><t>A "maxPrefixLength" member, whose value is a number.</t>
</li>
<li><t>A "comment" member, whose value is a string.</t>
</li>
</ul>
<t>The following example JSON structure represents a "prefixAssertions"
member with an array of example objects for each use case listed
above:</t>
<figure><name>"prefixAssertions" Examples
</name>
<sourcecode type="ascii-art">"prefixAssertions": [
{
"asn": 64496,
"prefix": "198.51.100.0/24",
"comment": "My other important route"
},
{
"asn": 64496,
"prefix": "2001:DB8::/32",
"maxPrefixLength": 48,
"comment": "My other important de-aggregated routes"
}
]
</sourcecode>
</figure>
<t>Note that the combination of the prefix, ASN, and optional maximum
length describes a VRP as described in <xref target="RFC6811"></xref>. The RP MUST add
all Prefix Assertions found this way to the VRP found through RPKI
validation and ensure that it sends the complete set of Protocol Data
Units (PDUs), excluding duplicates when using the RPKI-Router
protocol (see Sections 5.6 and 5.7 of <xref target="RFC8210"></xref>).</t>
</section>
<section anchor="bgpsec-assertions"><name>BGPsec Assertions</name>
<t>Each RP is locally configured with a (possibly empty) array of BGPsec
Assertions. Each BGPsec Assertion MUST contain an AS number, a
Router SKI, and the router public key. It is RECOMMENDED that an
explanatory comment is also included so that it can be shown to users
of the RP software.</t>
<t>The above is expressed as a value of the "bgpsecAssertions" member,
as an array of zero or more objects. Each object MUST contain one
each of all of the following members:</t>
<ul>
<li><t>An "asn" member, whose value is a number.</t>
</li>
<li><t>An "SKI" member, whose value is the Base64 encoding without
trailing '=' (Section 5 of <xref target="RFC4648"></xref>) of the certificate's Subject
Key Identifier as described in Section 4.8.2 of <xref target="RFC6487"></xref> (This is
the value of the ASN.1 OCTET STRING without the ASN.1 tag or
length fields.)</t>
</li>
<li><t>A "routerPublicKey" member, whose value is the Base64 encoding
without trailing '=' (Section 5 of <xref target="RFC4648"></xref>) of the equivalent to
the subjectPublicKeyInfo value of the router certificate's public
key, as described in <xref target="RFC8208"></xref>. This is the full ASN.1 DER
encoding of the subjectPublicKeyInfo, including the ASN.1 tag and
length values of the subjectPublicKeyInfo SEQUENCE.</t>
</li>
<li><t>An optional "comment" member, whose value is a string.</t>
</li>
</ul>
<t>The following example JSON structure represents a "bgpsecAssertions"
member with one object as described above:</t>
<figure><name>"bgpsecAssertions" Examples
</name>
<sourcecode type="ascii-art">"bgpsecAssertions": [
{
"asn": 64496,
"SKI": "<some base64 SKI>",
"routerPublicKey": "<some base64 public key>",
"comment": "My known key for my important ASN"
}
]
</sourcecode>
</figure>
<t>Note that a "bgpsecAssertions" member matches the syntax of the
Router Key PDU described in Section 5.10 of <xref target="RFC8210"></xref>. Relying
Parties MUST add any "bgpsecAssertions" member thus found to the set
of Router Key PDUs, excluding duplicates, when using the RPKI-Router
protocol <xref target="RFC8210"></xref>.</t>
</section>
<section anchor="aspa-assertions"><name>ASPA Assertions</name>
<t>Each RP is locally configured with a (possibly empty) array of ASPA
assertions. It is RECOMMENDED that an explanatory comment is also included
so that it can be shown to users of the RP software.</t>
<t>The above is expressed as a value of the "aspaAssertions" member, as an
array of zero or more objects. The object structure is similar to the
ASPA filter structure, except that in this case both a "customerAsid"
member and a "providers" member containing at at least one provider ASN
MUST be specified.</t>
<figure><name>"aspaAssertions" Example
</name>
<sourcecode type="ascii-art">"aspaAssertions": [
{
"customerAsid": 64496,
"providers": [ 64498, 64499, 64500 ],
"comment": "Authorize additional providers for customer AS 64496"
}
]
</sourcecode>
</figure>
<t>Assertions are applied after the RP obtained unified VAPs and applied
any configured filters. If there is an existing unified and potentially
partially filtered VAP for the assertion customer ASN, then the
additional authorizations are merged into this in the same way as VAPs
are merged (see section 4.3.3.1).</t>
<t>Note that the presence of an ASPA assertion does not imply any filtering.
If the intent is to replace all existing authorized providers then an
ASPA filter for the customer ASN only (i.e. without listing providers)
should be used in addition as this would ensure that the original
unified VAP is removed before the assertion is applied.</t>
</section>
</section>
<section anchor="example-of-a-slurm-file-with-filters-and-assertions"><name>Example of a SLURM File with Filters and Assertions</name>
<t>The following JSON structure represents an example of a SLURM file
that uses all the elements described in the previous sections:</t>
<figure><name>Example of Full SLURM File
</name>
<sourcecode type="ascii-art">{
"slurmVersion": 2,
"validationOutputFilters": {
"prefixFilters": [
{
"prefix": "192.0.2.0/24",
"comment": "All VRPs encompassed by prefix"
},
{
"asn": 64496,
"comment": "All VRPs matching ASN"
},
{
"prefix": "198.51.100.0/24",
"asn": 64497,
"comment": "All VRPs encompassed by prefix, matching ASN"
}
],
"bgpsecFilters": [
{
"asn": 64496,
"comment": "All keys for ASN"
},
{
"SKI": "Zm9v",
"comment": "Key matching Router SKI"
},
{
"asn": 64497,
"SKI": "YmFy",
"comment": "Key for ASN 64497 matching Router SKI"
}
],
"aspaFilters": [
{
"customerAsid": 64496,
"comment": "Filter out all VAPs for customer AS 64496"
},
{
"customerAsid": 64497,
"providers": [ 64498, 64499, 64500 ],
"comment": "Filter some providers for customer AS 64497"
},
{
"providers": [ 65001 ],
"comment": "Never accept 65001 as a valid provider."
}
]
},
"locallyAddedAssertions": {
"prefixAssertions": [
{
"asn": 64496,
"prefix": "198.51.100.0/24",
"comment": "My other important route"
},
{
"asn": 64496,
"prefix": "2001:DB8::/32",
"maxPrefixLength": 48,
"comment": "My other important de-aggregated routes"
}
],
"bgpsecAssertions": [
{
"asn": 64496,
"comment" : "My known key for my important ASN",
"SKI": "<some base64 SKI>",
"routerPublicKey": "<some base64 public key>"
}
],
"aspaAssertions": [
{
"customerAsid": 64496,
"providers": [ 64498, 64499, 64500 ],
"comment": "Authorize additional providers for AS 64496"
}
]
}
}
</sourcecode>
</figure>
</section>
</section>
<section anchor="slurm-file-configuration"><name>SLURM File Configuration</name>
<section anchor="slurm-file-atomicity"><name>SLURM File Atomicity</name>
<t>To ensure local consistency, the effect of SLURM MUST be atomic.
That is, the output of the RP either MUST be the same as if a SLURM
file were not used or MUST reflect the entire SLURM configuration.
For an example of why this is required, consider the case of two
local routes for the same prefix but different origin ASNs. Both
routes are configured with Locally Added Assertions. If neither
addition occurs, then both routes could be in the NotFound state
<xref target="RFC6811"></xref>. If both additions occur, then both routes would be in the
Valid state. However, if one addition occurs and the other does not,
then one could be Invalid while the other is Valid.</t>
</section>
<section anchor="multiple-slurm-files"><name>Multiple SLURM Files</name>
<t>An implementation MAY support the concurrent use of multiple SLURM
files. In this case, the resulting inputs to Validation Output
Filters and Locally Added Assertions are the respective unions of the
inputs from each file. The envisioned typical use case for multiple
files is when the files have distinct scopes. For instance,
operators of two distinct networks may resort to one RP system to
frame routing decisions. As such, they probably deliver SLURM files
to this RP independently. Before an RP configures SLURM files from
different sources, it MUST make sure there is no internal conflict
among the INR assertions in these SLURM files. To do so, the RP
SHOULD check the entries of each SLURM file with regard to overlaps
of the INR assertions and report errors to the sources that created
the SLURM files in question. The RP gets multiple SLURM files as a
set, and the whole set MUST be rejected in case of any overlaps among
the SLURM files.</t>
<t>If a problem is detected with the INR assertions in these SLURM
files, the RP MUST NOT use them and SHOULD issue a warning as error
report in the following cases:</t>
<ol>
<li><t>There may be conflicting changes to ROA Prefix Assertions if an
IP address X and distinct SLURM files Y and Z exist such that X
is contained by any prefix in any "prefixAssertions" or
"prefixFilters" in file Y and X is contained by any prefix in any
"prefixAssertions" or "prefixFilters" in file Z.</t>
</li>
<li><t>There may be conflicting changes to BGPsec Assertions if an ASN X
and distinct SLURM files Y and Z exist such that X is used in any
"bgpsecAssertions" or "bgpsecFilters" in file Y and X is used in
any "bgpsecAssertions" or "bgpsecFilters" in file Z.</t>
</li>
</ol>
</section>
</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
<section anchor="security-considerations"><name>Security Considerations</name>
<t>The mechanisms described in this document provide a network operator
with additional ways to control use of RPKI data while preserving
autonomy in address space and ASN management. These mechanisms are
only applied locally; they do not influence how other network
operators interpret RPKI data. Nonetheless, care should be taken in
how these mechanisms are employed. Note that it also is possible to
use SLURM to (locally) manipulate assertions about non-private INRs,
e.g., allocated address space that is globally routed. For example,
a SLURM file may be used to override RPKI data that a network
operator believes has been corrupted by an adverse action. Network
operators who elect to use SLURM in this fashion should use extreme
caution.</t>
<t>The goal of the mechanisms described in this document is to enable an
RP to create its own view of the RPKI, which is intrinsically a
security function. An RP using a SLURM file is trusting the
assertions made in that file. Errors in the SLURM file used by an RP
can undermine the security offered to that RP by the RPKI. A SLURM
file could declare as invalid ROAs that would otherwise be valid, and
vice versa. As a result, an RP MUST carefully consider the security
implications of the SLURM file being used, especially if the file is
provided by a third party.</t>
<t>Additionally, each RP using SLURM MUST ensure the authenticity and
integrity of any SLURM file that it uses. Initially, the SLURM file
may be preconfigured out of band, but if the RP updates its SLURM
file over the network, it MUST verify the authenticity and integrity
of the updated SLURM file. The mechanism to update the SLURM file to
guarantee authenticity and integrity is out of the scope of this
document.</t>
</section>
<section anchor="acknowledgements"><name>Acknowledgements</name>
<t>The authors would like to thank David Mandelberg for co-authoring
<xref target="RFC8416"></xref> which this document replaces. The authors would also like
to thank Stephen Kent, Richard Hansen, Hui Zou and Chunlin An for their
contributions to <xref target="RFC8416"></xref>.</t>
</section>
</middle>
<back>
<references><name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-sidrops-aspa-profile.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-sidrops-aspa-verification.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.timbru-sidrops-aspa-notation.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4632.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5952.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6487.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6811.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8205.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8208.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8209.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8210.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8416.xml"/>
</references>
<references><name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1918.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1930.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4193.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6482.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6491.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6598.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6996.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8211.xml"/>
</references>
</back>
</rfc>