forked from tking/rpki-light
-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-ietf-sidrops-route-server-rpki-light.xml
326 lines (283 loc) · 13.8 KB
/
draft-ietf-sidrops-route-server-rpki-light.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
#
# This is an old an archived version
#
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4360 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4360.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 RFC7999 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7999.xml">
<!ENTITY RFC8097 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8097.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-route-server-rpki-light-01">
<front>
<title>Signaling Prefix Origin Validation Results from a Route Server to 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="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 month="January" year="2017" />
<abstract>
<t>
This document defines the usage of the BGP Prefix Origin Validation State Extended
Community <xref target="RFC8097"/> 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.
</t>
</abstract>
<note title="Requirements Language">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
are to be interpreted as described in
<xref target="RFC2119" />
only when they appear in all upper
case. They may also appear in
lower or mixed case as English
words, without normative meaning.
</t>
</note>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
RPKI-based prefix origin validation <xref target="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 <xref target="RFC7947"/>.
The result of this prefix origin validation is signaled to peers by using the BGP Prefix Origin Validation State
Extended Community as introduced in <xref target="RFC8097"/>.
</t>
<t>
Peers receiving the prefix origin validation result from the route server(s) 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="routeserveroperation" title="BGP Prefix Origin Validation State Utilized at Route-Servers">
<t>
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:
<!-- add use cases here -->
<list style="hanging" hangIndent="4">
<t hangText="Simple Tagging:"> The prefix origin validation state is tagged to the route as described in <xref target="extendedcommunity"/>.
<vspace />
This mode of operation is like the tradional way route servers work, however, the prefix origin validation state information is additionally available for peers.
<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 route server. Routes which show a prefix origin validation state of "not found" and "valid" (according to <xref target="RFC6811"/>) are tagged accordingly to <xref target="extendedcommunity"/>.
<vspace />
Security is higher rated than questionable reachability of a prefix by this mode of operation.
<vspace />
</t>
<t hangText="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 accordinly to <xref target="extendedcommunity"/>.
<vspace />
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.
<vspace />
</t>
</list>
</t>
<t>
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 seperately.
</t>
<t>
<!-- add add-path reference here -->
These mode of operations might be used in combination with <xref target="RFC7911"/> in order to allow a peer to receive all routes and take the routing decision by itself.
</t>
</section>
<section anchor="extendedcommunity" title="Signaling Prefix Origin Validation Results from a Route Server to Peers">
<t>
The BGP Prefix Origin Validation State Extended Community (as defined in <xref target="RFC8097"/>)
is utilized for signaling prefix origin validation result from a route server to peers.
</t>
<t>
<xref target="RFC8097"/> proposes an encoding of the prefix origin validation result
<xref target="RFC6811"/> as follows:
</t>
<texttable anchor="values">
<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. Route servers 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="recommendation" 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="RFC6811">section 5</xref>.
</t>
<t>
A peer receiving a prefix origin validation result from the route server MAY redistribute this information
within its own AS.
</t>
</section>
<section anchor="routeserver" title="Route Server Receiving the BGP Prefix Origin Validation State Extended Community">
<t>
An IXP route server receiving routes from its peers containing the BGP 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.
</t>
<t>
Failure to do so would allow opportunistic peers to advertise routes tagged with arbitrary prefix origin validation
results via a route server, influencing maliciously the decision process of other route server peers.
</t>
</section>
<section anchor="routeservererror" title="Information about Validity of a BGP Prefix Origin Not Available at a Route-Server">
<t>
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 BGP Prefix Origin Validation State Extended Community to the route.
</t>
</section>
<section anchor="morespecific" title="Error Handling at Peers">
<t>
A route sent by a route server SHOULD only contain none or one BGP Prefix Origin
Validation State Extended Community.
</t>
<t>
A peer receiving a route from a route server containing more than one BGP Prefix Origin
Validation State Extended Community SHOULD only consider the largest value (as described in
<xref target="values"/>) 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>
None.
</t>
<!--><t>
The IANA is requested to register the value 0x02 for the low-order octet of the extended type in the
non-transitive range for the concept described in this document.
</t>
<t>
The extended community should be called "Route server RPKI validation result extended community".
</t>-->
</section>
<section anchor="security" title="Security Considerations">
<t>
All security considerations described in <xref target="RFC6811">RFC RFC6811</xref> fully apply to this document.
</t>
<t>
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).
</t>
<t>
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.
</t>
<!--<t>
Similar issues may arise due to inadvertent corruption of the ROA cache database.
</t>-->
<t>
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.
</t>
<t>
While beeing under DDoS attacks, it is a common practice for peers connected to an IXP to make use of
blackholing services (see <xref target="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.
<!--
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;
&RFC4360;
&RFC6811;
&RFC7911;
&RFC8097;
</references>
<references title="Informative References">
&RFC6480;
&RFC7947;
&RFC7999;
</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>