forked from tking/rpki-light
-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-ietf-sidrops-route-server-rpki-light.txt
462 lines (317 loc) · 18.5 KB
/
draft-ietf-sidrops-route-server-rpki-light.txt
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
#
# This is an old and archived version
#
Network Working Group T. King
Internet-Draft D. Kopp
Intended status: Standards Track DE-CIX
Expires: October 12, 2017 A. Lambrianidis
AMS-IX
A. Fenioux
France-IX
April 10, 2017
Signaling Prefix Origin Validation Results from a Route Server to Peers
draft-ietf-sidrops-route-server-rpki-light-02
Abstract
This document defines a new BGP opaque extended community, as well
as its usage, to signal prefix origin validation results from a
route server to its peers. Upon reception of prefix origin
validation results, peers can use this information in their
local routing decision process.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to
be interpreted as described in [RFC2119] only when they appear in all
upper case. They may also appear in lower or mixed case as English
words, without normative meaning.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 12, 2017.
King, et al. Expires October 12, 2017 [Page 1]
Internet-DraSignaling Prefix Origin Validation Results from April 2017
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1
2. EBGP Prefix Origin Validation Extended Community. . . . . . . 2
3. BGP Prefix Origin Validation State Utilized at Route-Servers 3
4. Signaling Prefix Origin Validation Results from a Route
Server to Peers . . . . . . . . . . . . . . . . . . . . . . . 4
5. Operational Recommendations . . . . . . . . . . . . . . . . . 4
5.1. Local Routing Decision Process . . . . . . . . . . . . . 4
5.2. Route Server Receiving the EBGP Prefix Origin Validation
State Extended Community . . . . . . . . . . . . . . . . 4
5.3. Information about Validity of a BGP Prefix Origin Not
Available at a Route-Server . . . . . . . . . . . . . . . 5
5.4. Error Handling at Peers . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
RPKI-based prefix origin validation [RFC6480] can be a significant
operational burden for BGP peers to implement and adopt. In order to
boost acceptance and usage of prefix origin validation and ultimately
increase the security of the Internet routing system, IXPs may
provide RPKI-based prefix origin validation at the route server
[RFC7947]. The result of this prefix origin validation is signaled
to peers by using the EBGP Prefix Origin Validation State
Extended Community as introduced in this document.
Peers receiving the prefix origin validation result from the route
server(s) can use this information in their local routing decision
King, et al. Expires October 12, 2017 [Page 2]
Internet-DraSignaling Prefix Origin Validation Results from April 2017
process for acceptance, rejection, preference, or other traffic
engineering purposes of a particular route.
2. EBGP Prefix Origin Validation Extended Community
The origin validation state extended community is an opaque extended
community [RFC4360] with the following encoding:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x03 | TBD1 | Reserved | Global Admin :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Global Administrator (cont.) |validationstate|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value of the high-order octet of the extended Type field is 0x03,
which indicates it is transitive. The value of the low-order
octet (Sub-Type) of the extended Type field as assigned by IANA is TBD1.
The Reserved field MUST be set to 0 and ignored upon the receipt of this
community. The Global Administrator field MUST be set to the AS number of
the route server conducting the prefix origin validation. The last octet
of the extended community is an unsigned integer that gives the route's
validation state [RFC6811]. It can assume the following values:
+-------+-----------------------------+
| Value | Meaning |
+-------+-----------------------------+
| 0 | Lookup result = "valid" |
| 1 | Lookup result = "not found" |
| 2 | Lookup result = "invalid" |
+-------+-----------------------------+
If the route server is configured to support the extensions defined in
this document, it SHOULD attach the origin validation state extended
community to BGP UPDATE messages sent to EBGP peers by mapping the
computed validation state in the last octet of the extended
King, et al. Expires October 12, 2017 [Page 3]
Internet-DraSignaling Prefix Origin Validation Results from April 2017
community. Similarly, a receiving BGP speaker, in the absence of
validation state set based on local data, SHOULD derive a validation
state from the last octet of the extended community, if present.
An implementation SHOULD NOT send more than one instance of the
origin validation state extended community. However, if more than
one instance is received, an implementation MUST disregard all
instances other than the one with the numerically greatest validation
state value. If the value received is greater than the largest
specified value (2), the implementation MUST apply a strategy similar
to attribute discard [RFC7606] by discarding the erroneous community
and logging the error for further analysis.
3. BGP Prefix Origin Validation State Utilized at Route-Servers
A route server that is aware of a BGP Prefix Origin Validation state
for a certain route can handle this information in one of the
following modes of operation:
Simple Tagging: The prefix origin validation state is tagged to the
route as described in Section 2.
This mode of operation is like the traditional way route servers
work, however, the prefix origin validation state information is
additionally available for peers.
Dropping and Tagging: Routes for which the prefix origin validation
state is "invalid" (according to [RFC6811]) are dropped by the
route server. Routes which show a prefix origin validation state
of "not found" and "valid" (according to [RFC6811]) are tagged
accordingly, as discussed in Section 2.
In this mode of operation, security is rated higher than
questionable reachability of a prefix.
Prioritizing and Tagging: If the route server learned for a
particular prefix more than one route it removes firstly the set
of "invalid" routes and secondly the "not found" routes unless
the set of routes is empty. Based on the set of routes left over
the BGP best path section algorithm is executed. The selected
route is marked accordingly to Section 2.
The BGP best path selection algorithm is changed by this mode of
operation in such a way that "valid" routes are preferred even if
they are unfavorable by the traditional best path selection
algorithm. This puts prefix origin validation on top of the best
path selection.
A route server MUST support the Simple Tagging mode of operation.
Other modes of operation are OPTIONAL. The mode of operation MAY be
configured by the route server operator for a route server instance
or for each BGP session with a peer separately.
Path hiding, as originally discussed in [RFC7947], may impact
end-to-end connectivity for peers receiving prefixes via route servers
if the best path selected contains a prefix with an "invalid" prefix
origin validation state, and subsequently dropped, either at the
peer (Simple Tagging operation mode) or the route server itself
(Dropping and Tagging operation mode).
However, these modes of operation might be used in combination with
[RFC7911] in order to allow a peer to receive all routes and take the
routing decision by itself.
King, et al. Expires October 12, 2017 [Page 4]
Internet-DraSignaling Prefix Origin Validation Results from April 2017
4. Signaling Prefix Origin Validation Results from a Route Server to
Peers
The EBGP Prefix Origin Validation State Community is utilized for
signaling prefix origin validation result from a route server to peers.
This draft proposes an encoding of the prefix origin validation result
[RFC6811] as follows:
+-------+-----------------------------+
| Value | Meaning |
+-------+-----------------------------+
| 0 | Lookup result = "valid" |
| 1 | Lookup result = "not found" |
| 2 | Lookup result = "invalid" |
+-------+-----------------------------+
Table 1
This encoding is re-used. Route servers providing RPKI-based prefix
origin validation set the validation state according to the prefix
origin validation result (see [RFC6811]).
5. Operational Recommendations
5.1. Local Routing Decision Process
A peer receiving prefix origin validation results from the route
server MAY use the information in its own local routing decision
process. The local routing decision process SHOULD apply to the
rules as described in section 5 [RFC6811].
A peer receiving a prefix origin validation result from the route
server MAY redistribute this information within its own AS.
In cases where multiple ASes are being administered by the same
authority, peers MAY also redistribute this information across
EBGP boundaries of the authority in question.
5.2. Route Server Receiving the EBGP Prefix Origin Validation State
Extended Community
An IXP route server receiving routes from its peers containing the
EBGP Prefix Origin Validation State Extended Community MUST remove the
extended community before the route is re-distributed to its peers.
This is required regardless of whether the route server is executing
prefix origin validation or not.
Failure to do so would allow opportunistic peers to advertise routes
tagged with arbitrary prefix origin validation results via a route
King, et al. Expires October 12, 2017 [Page 5]
Internet-DraSignaling Prefix Origin Validation Results from April 2017
server, influencing maliciously the decision process of other route
server peers.
5.3. Information about Validity of a BGP Prefix Origin Not Available at
a Route-Server
In case information about the validity of a BGP prefix origin is not
available at the route server (e.g., error in the ROA cache, CPU
overload) the route server MUST NOT add the EBGP Prefix Origin
Validation State Extended Community to the route.
5.4. Error Handling at Peers
A route sent by a route server SHOULD only contain none or one EBGP
Prefix Origin Validation State Extended Community.
A peer receiving a route from a route server containing more than one
EBGP Prefix Origin Validation State Extended Community SHOULD only
consider the largest value (as described in Table 1) in the
validation result field and disregard the other values. Values
larger than two in the validation result field MUST be disregarded.
6. IANA Considerations
IANA is asked to assign a Transitive BGP Opaque Extended Community
as well as a Transitive Opaque Extended Community Sub-Type for
the purposes of this draft, as defined in Section 4. of RFC 7153.
7. Security Considerations
All security considerations described in RFC 6811 [RFC6811] fully
apply to this document.
Additionally, threat agents polluting ROA cache server(s) run by IXP
operators could cause significant operational impact, since multiple
route server clients could be affected. Peers should be vigilant as
to the integrity and authenticity of the origin validation results,
as they are provided by a third party, namely the IXP operator
hosting both the route server as well as any ROA cache server(s).
Therefore, a route server could be misused to spread malicious prefix
origin validation results. However, peers already trust the route
server for the collection, filtering (e.g. IRR database filtering),
and redistribution of BGP routing information to other peers. So, no
change in the trust level is needed for this proposal.
To facilitate trust and help with peers establishing appropriate
controls in mitigating the risks mentioned above, IXPs SHOULD provide
out-of-band means for peers to ensure that the ROA validation process
has not been compromised or corrupted.
King, et al. Expires October 12, 2017 [Page 6]
Internet-DraSignaling Prefix Origin Validation Results from April 2017
While beeing under DDoS attacks, it is a common practice for peers
connected to an IXP to make use of blackholing services (see
[RFC7999]). Peers are using blackholing to drop traffic, typically
by announcing a more specific prefix, which is under attack. A peer
SHOULD make sure that this prefix is covered by an appropriate ROA.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <http://www.rfc-editor.org/info/rfc4360>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811,
DOI 10.17487/RFC6811, January 2013,
<http://www.rfc-editor.org/info/rfc6811>.
[RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP
Extended Communities", RFC 7153, DOI 10.17487/RFC7153,
March 2014, <http://www.rfc-editor.org/info/rfc7153>.
[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", RFC 7911,
DOI 10.17487/RFC7911, July 2016,
<http://www.rfc-editor.org/info/rfc7911>.
[RFC8097] Mohapatra, P., Patel, K., Scudder, J., Ward, D., and R.
Bush, "BGP Prefix Origin Validation State Extended
Community", RFC 8097, DOI 10.17487/RFC8097, March 2017,
<http://www.rfc-editor.org/info/rfc8097>.
8.2. Informative References
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <http://www.rfc-editor.org/info/rfc6480>.
[RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker,
"Internet Exchange BGP Route Server", RFC 7947,
DOI 10.17487/RFC7947, September 2016,
<http://www.rfc-editor.org/info/rfc7947>.
King, et al. Expires October 12, 2017 [Page 7]
Internet-DraSignaling Prefix Origin Validation Results from April 2017
[RFC7999] King, T., Dietzel, C., Snijders, J., Doering, G., and G.
Hankins, "BLACKHOLE Community", RFC 7999,
DOI 10.17487/RFC7999, October 2016,
<http://www.rfc-editor.org/info/rfc7999>.
Authors' Addresses
Thomas King
DE-CIX Management GmbH
Lichtstrasse 43i
Cologne 50825
DE
Email: [email protected]
Daniel Kopp
DE-CIX Management GmbH
Lichtstrasse 43i
Cologne 50825
DE
Email: [email protected]
Aristidis Lambrianidis
Amsterdam Internet Exchange
Frederiksplein 42
Amsterdam 1017 XN
NL
Email: [email protected]
Arnaud Fenioux
France-IX
88 Avenue Des Ternes
Paris 75017
FR
Email: [email protected]
King, et al. Expires October 12, 2017 [Page 7]