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
|
---
title: SLURM
description: "Use SLURM to modify the RPKI assertions validated and published by an RTR server"
---
# {{ page.title }}
## Introduction
There are reasons why you might legitimately want to modify the RPKI assertions validated and published by an RTR server:
- To assert the validity of private IP addresses and/or AS numbers for local use. (Since they are outside of the scope of the global RPKI.)
- To override temporarily incorrect or outdated global RPKI data.
The "Simplified Local Internet Number Resource Management with the RPKI" (SLURM) is a [standard](https://tools.ietf.org/html/rfc8416) means to accomplish this. In a nutshell, it's just a bunch of JSON files with which you can filter out or append arbitrary ROAs to FORT validator's RTR payload.
Note that, with the exception of the following section, most of this document is just a summary of [RFC 8416](https://tools.ietf.org/html/rfc8416). You can find more details there.
## Handling of SLURM Files
The SLURM files are defined by the [`--slurm`](usage.html#--slurm) flag. If the flag points to a file, the configuration is extracted from that single file. If it points to a directory, the configuration is the aggregation of the contents of its contained `.slurm` files.
None of the entries of the SLURM configuration are allowed to collide with each other. If there is a collision, the overall SLURM configuration is invalidated.
FORT validator reloads the SLURM files during every validation cycle. If the new configuration is invalid (due to either a syntax or content error) the validator will fall back to the previous valid SLURM configuration, and will log a message to indicate this action.
## File Definition
### Root
Each SLURM file is a JSON-formatted collection of filters and/or additions. Each of the members shown is mandatory:
```
{
"slurmVersion": 1,
"validationOutputFilters": {
"prefixFilters": [ <Removed ROAs> ],
"bgpsecFilters": [ <Removed Router Keys> ]
},
"locallyAddedAssertions": {
"prefixAssertions": [ <Added ROAs> ],
"bgpsecAssertions": [ <Added Router Keys> ]
}
}
```
The root object contains a `slurmVersion` field (which, for now, must be set to 1), a listing of filters called `validationOutputFilters`, and a listing of additions called `locallyAddedAssertions`.
### `prefixFilters`
`<Removed ROAs>` expands to a sequence of (zero or more) JSON objects, each of which follows this pattern:
```
{
"prefix": <IP prefix>,
"asn": <AS number>,
"comment": <Explanatory comment>
}
```
Any ROAs that match `prefix` and `asn` will be invalidated. A ROA matches `prefix` by having an equal or more specific IP prefix, and `asn` by having the same AS number.
One of `prefix` and `asn` can be absent. On absence, any prefix matches `prefix`, and any AS number matches `asn`.
`comment` is always optional.
### `bgpsecFilters`
`<Removed Router Keys>` expands to a sequence of (zero or more) JSON objects, each of which follows this pattern:
```
{
"asn": <AS number>,
"SKI": <Base64 of some SKI>,
"comment": <Explanatory comment>
}
```
Any Router Keys that match `asn` and `SKI` will be invalidated. A Router Key matches `asn` by having the same AS number and `SKI` by having the same decoded Subject Key Identifier.
One of `asn` and `SKI` can be absent. On absence, any AS number matches `asn`, and any Subject Key Identifier matches `SKI`.
`comment` is always optional.
### `prefixAssertions`
`<Added ROAs>` expands to a sequence of (zero or more) JSON objects, each of which follows this pattern:
```
{
"prefix": <IP prefix>,
"asn": <AS number>,
"maxPrefixLength": <Prefix length>
"comment": <Explanatory comment>
}
```
Will force the validator into believing that the [`prefix`, `asn`, `maxPrefixLength`] ROA validated successfully.
`prefix` and `asn` are mandatory, `maxPrefixLength` and `comment` are not. `maxPrefixLength` defaults to `prefix`'s length.
### `bgpsecAssertions`
`<Added Router Keys>` expands to a sequence of (zero or more) JSON objects, each of which follows this pattern:
```
{
"asn": <AS number>,
"SKI": <Base64 of some SKI>,
"routerPublicKey": <Base64 of some public key>,
"comment": <Explanatory comment>
}
```
Will force the validator into believing that the [`asn`, `SKI`, `routerPublicKey`] Router Key validated successfully.
Only `comment` isn't mandatory, the rest [`asn`, `SKI`, `routerPublicKey`] are mandatory.
## File Example
```
{
"slurmVersion": 1,
"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": "Q8KMeBsCto1PJ6EuhowleIGNL7A",
"comment": "Key matching Router SKI"
}, {
"asn": 64497,
"SKI": "g5RQYCnkMpDqEbt9WazTeB19nZs",
"comment": "Key for ASN 64497 matching Router SKI"
}
]
},
"locallyAddedAssertions": {
"prefixAssertions": [
{
"asn": 64496,
"prefix": "198.51.100.0/24",
"comment": "My important route"
}, {
"asn": 64496,
"prefix": "2001:DB8::/32",
"maxPrefixLength": 48,
"comment": "My important de-aggregated routes"
}
],
"bgpsecAssertions": [
{
"asn": 64496,
"SKI", "Dulqji-sUM5sX5M-3mqngKaFDjE",
"routerPublicKey": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE-rkSLXlPpL_m-L7CfCfKrv1FHrM55FsIc8fMlnjHE6Y5nTuCn3UgWfCV6sYuGUZzPZ0Ey6AvezmfcELUB87eBA",
"comment": "My known key for my important ASN"
}
]
}
}
```
|
