forked from tking/rpki-light
-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-ietf-sidrops-validating-bgp-speaker-02.xml
410 lines (377 loc) · 17.2 KB
/
draft-ietf-sidrops-validating-bgp-speaker-02.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
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC6811 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6811.xml">
<!ENTITY RFC6480 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6480.xml">
<!ENTITY RFC7911 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7911.xml">
<!ENTITY RFC7947 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7947.xml">
<!ENTITY RFC7606 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7606.xml">
<!ENTITY RFC5668 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5668.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC7153 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7153.xml">
]>
<?rfc comments="yes"?>
<?rfc compact="yes"?>
<?rfc inline="yes"?>
<?rfc sortrefs="yes"?>
<?rfc subcompact="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?>
<rfc category="std" docName="draft-ietf-sidrops-validating-bgp-speaker-02">
<front>
<title>Signaling Prefix Origin Validation Results from an RPKI Origin Validating BGP Speaker to BGP Peers</title>
<author fullname="Thomas King" initials="T." surname="King">
<organization abbrev="DE-CIX">DE-CIX Management GmbH</organization>
<address>
<postal>
<street>Lichtstrasse 43i</street>
<city>Cologne</city>
<code>50825</code>
<country>DE</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Christoph Dietzel" initials="C." surname="Dietzel">
<organization abbrev="DE-CIX">DE-CIX Management GmbH</organization>
<address>
<postal>
<street>Lichtstrasse 43i</street>
<city>Cologne</city>
<code>50825</code>
<country>DE</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Daniel Kopp" initials="D." surname="Kopp">
<organization abbrev="DE-CIX">DE-CIX Management GmbH</organization>
<address>
<postal>
<street>Lichtstrasse 43i</street>
<city>Cologne</city>
<code>50825</code>
<country>DE</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Aristidis Lambrianidis" initials="A." surname="Lambrianidis">
<organization abbrev="AMS-IX">Amsterdam Internet Exchange</organization>
<address>
<postal>
<street>Frederiksplein 42</street>
<code>1017 XN</code>
<city>Amsterdam</city>
<country>NL</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Arnaud Fenioux" initials="A." surname="Fenioux">
<organization>France-IX</organization>
<address>
<postal>
<street>88 Avenue Des Ternes</street>
<city>Paris</city>
<code>75017</code>
<country>FR</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date day="08" month="February" year="2018" />
<abstract>
<t>
This document defines a new BGP transitive extended community,
as well as its usage, to signal prefix origin validation results from
an RPKI Origin validating BGP speaker to other BGP peers.
Upon reception of prefix origin validation results, peers can use
this information in their local routing decision process.
</t>
</abstract>
<note title="Requirements Language">
<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 target="RFC8174" /> when,
and only when, they appear in all capitals, as shown here.
</t>
</note>
</front>
<middle>
<section anchor="intro_1" title="Introduction">
<t>
RPKI-based prefix origin validation <xref target="RFC6480"/> can be a significant
operational burden for BGP peers to implement and adopt. To
facilitate acceptance and usage of prefix origin validation and ultimately
increase the security of the Internet routing system, Autonomous
Systems may provide RPKI-based prefix origin validation at certain
vantage points. 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.
</t>
<t>
Peers receiving a prefix origin validation result from the validating
EBGP peer can use this information in their local routing decision process for acceptance, rejection, preference, or other traffic engineering purposes of a particular route.
</t>
</section>
<section anchor="ebgp_prefix_origin_2" title="EBGP Prefix Origin Validation Extended Community">
<t>
The origin validation state extended community is a transitive
Four-octet AS Specific Extended Community <xref target="RFC5668"/> with the
following encoding:
</t>
<figure anchor="table_example" align="center">
<artwork>
<![CDATA[ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x02 |TBD1 (Sub-Type)| Global Administrator :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Global Administrator (cont.) | Validation State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>
The value of the high-order octet of the extended Type field is 0x02,
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 receipt
of this community. The Global Administrator field MUST be set to the
AS number of the validating BGP speaker conducting the prefix origin
validation. The last octets of the extended community is an unsigned
integer that gives the route's validation state as described in <xref target="signal_prefix_4"/>.
</t>
<t>
If the validating BGP speaker 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 community. A receiving BGP speaker, in the absence of a local
validation state, SHOULD derive a validation
state from the last octet of the received extended community, if present.
</t>
<t>
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 <xref target="RFC7606"/> by discarding the erroneous community
and logging the error for further analysis.
<!-- add add-path reference here -->
</t>
</section>
<section anchor="bgp_prefix_3" title="BGP Prefix Origin Validation State Utilized at Validating Peers">
<t>
A validating BGP speaker that is aware of a BGP Prefix Origin
Validation state (see <xref target="signal_prefix_4"/>) for a certain
route can handle this information in one of the following modes of operation,
attaching validation state to routes as discussed in <xref target="ebgp_prefix_origin_2"/>:
<list style="hanging" hangIndent="4">
<t hangText="Simple Tagging:">
In this mode of operation, the BGP best path
selection algorithm is executed. The prefix origin validation state
is tagged accordingly.
<vspace />
</t>
<t hangText="Dropping and Tagging:">
Routes for which the prefix origin validation
state is "invalid" (according to <xref target="RFC6811"/>) are dropped by the
validating BGP speaker. Based on the remaining set of routes,
the BGP best path selection algorithm is executed. The
prefix origin validation state of "not found" or "valid"
(according to <xref target="RFC6811"/>) is tagged accordingly.
<vspace />
</t>
<t hangText="Strict Dropping and Tagging:">
Routes for which the prefix origin validation
state is "invalid" or "not found" (according to <xref target="RFC6811"/>)
are dropped by the validating BGP speaker. Based on the remaining set of
routes, the BGP best path selection algorithm is executed.
The prefix origin validation state of "valid" is tagged to the advertised
route.
</t>
</list>
</t>
<t>
A validating BGP speaker MUST support the Simple Tagging operation
mode. Other modes of operation are OPTIONAL. The mode of operation
MAY be configured by the validating BGP speaker operator for all
connected peers, or for each BGP session with a peer separately.
</t>
<t>
Path hiding, as originally discussed in <xref target="RFC7947"/>, may impact
end-to-end connectivity for peers receiving prefixes via validating
BGP speakers, if the best path selected contains a prefix with a
prefix origin validation state which is subsequently dropped.
</t>
<t>
However, these modes of operation might be used in combination with
any options discussed in Section 2.3.2 of <xref target="RFC7947"/>
in order to allow a peer to receive one or more routes and take the
routing decision by itself, or with implementations who support sending
the next best available path.
</t>
</section>
<section anchor="signal_prefix_4" title="Signaling Prefix Origin Validation Results from a Validating Peer to Peers">
<t>
The EBGP Prefix Origin Validation State Community is utilized for
signaling prefix origin validation result from a validating BGP
speaker to other peers.
</t>
<t>
This draft proposes an encoding of the prefix origin validation
result <xref target="RFC6811"/> as follows:
</t>
<texttable anchor="table_1">
<ttcol align='center'>Value</ttcol>
<ttcol align='left'>Meaning</ttcol>
<c>0</c><c>Lookup result = "valid"</c>
<c>1</c><c>Lookup result = "not found"</c>
<c>2</c><c>Lookup result = "invalid"</c>
</texttable>
<t>
This encoding is re-used. Validating peers providing RPKI-based
prefix origin validation set the validation state according to the
prefix origin validation result (see <xref target="RFC6811"/>).
</t>
</section>
<section anchor="op_recommendations_5" title="Operational Recommendations">
<section anchor="local" title="Local Routing Decision Process">
<t>
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 <xref target="op_recommendations_5"/> <xref target="RFC6811"/>.
</t>
<t>
A peer receiving a prefix origin validation result from the route
server MAY redistribute this information within its own AS.
</t>
<t>
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.
</t>
</section>
<section anchor="validating_peers" title="Validating Peers Receiving the EBGP Prefix Origin Validation State Extended Community">
<t>
A validating BGP speaker receiving routes from 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 validating BGP
speaker is executing prefix origin validation or not.
</t>
<t>
Failure to do so would allow opportunistic peers to advertise routes
tagged with arbitrary prefix origin validation results via validating peers, influencing maliciously the decision process of other,
non-validating BGP speakers.
</t>
</section>
<section anchor="info_validity" title="Information about Validity of a BGP Prefix Origin Not Available at a Validating Peer">
<t>
In case information about the validity of a BGP prefix origin is not
available at the validating BGP speaker (e.g., error in the ROA
cache, CPU overload) the validating BGP speaker MUST NOT add the
EBGP Prefix Origin Validation State Extended Community to the route.
</t>
</section>
<section anchor="error_handling" title="Error Handling at Peers">
<t>
A route sent by a validating BGP speaker SHOULD only contain none or
one EBGP Prefix Origin Validation State Extended Community.
</t>
<t>
A peer receiving a route from a validating BGP speaker containing
more than one EBGP Prefix Origin Validation State Extended Community
SHOULD only consider the largest value (as described in <xref target="table_1"/>) in
the validation result field and disregard the other values. Values
larger than two in the validation result field MUST be disregarded.
</t>
</section>
</section>
<section anchor="iana" title="IANA Considerations">
<t>
IANA is asked to assign a transitive Four-octet AS Specific Extended Community
Sub-Type as defined in Section 5.2.4 of <xref target="RFC7153"/>.
</t>
</section>
<section anchor="security" title="Security Considerations">
<t>
All security considerations described in <xref target="RFC6811">RFC6811</xref> fully
apply to this document.
</t>
<t>
Additionally, threat agents polluting ROA cache server(s) run by AS
operators could cause significant operational impact, since multiple
validating BGP speaker 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 AS operator hosting both the validating BGP speaker as well as
any ROA cache server(s).
</t>
<t>
Therefore, a validating BGP speaker could be misused to spread
malicious prefix origin validation results. However, in the case of
IXPs, peers already trust the route server for the
collection, filtering (e.g., IRR database filtering), and
redistribution of BGP routing information to other peers.
</t>
<!--<t>
Similar issues may arise due to inadvertent corruption of the ROA cache database.
</t>-->
<t>
To facilitate trust and support with peers establishing appropriate
controls in mitigating the risks mentioned above, AS operators SHOULD
provide out-of-band means for peers to ensure that the ROA
validation process has not been compromised or corrupted.
</t>
<t>
While being under DDoS attacks, it is a common practice for peers
connected to other Autonomous Systems and make use of blackholing
services. 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.
<!--
If no ROA entry exists for the more specific prefix, its
validation status would be "Invalid". This might be undesirable,
in which case it would be recommended for targeted peers
to either create the appropriate ROA entry as necessary,
of modify the MaxLength value of the existing ROA in order to match the new prefix announced for blackholing.
It is not necessary to create and announce a new classification for such more specific prefixes on the route server as is may result in a non-coherent solution, therefore it is to the peer annoucing this new more specific prefix to create appropriate ROA.
-->
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC6811;
&RFC7606;
&RFC5668;
&RFC8174;
&RFC7153;
</references>
<references title="Informative References">
&RFC6480;
&RFC7947;
</references>
<!--<section anchor="acknowledgements" title="Acknowledgements">
<t>The authors gratefully acknowledges the contributions of:
<list style='symbols'>
<t>Petr Jiran, NIX.CZ, Milesovska 1136/5, Praha 130 00, Czech Republic, Email: [email protected]</t>
<t>Yordan Kritski, NetIX Ltd., 3 Grigorii Gorbatenko Str., Sofia 1784, Bulgaria, Email:
<t>Christian Seitz, STRATO AG, Pascalstr. 10, Berlin 10587, Germany, Email: [email protected]</t>
</list>
</t>
</section>-->
</back>
</rfc>