idnits 2.17.1
draft-sriram-idr-route-leak-detection-mitigation-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The abstract seems to contain references
([I-D.ietf-sidr-bgpsec-protocol], [RFC6811],
[I-D.ietf-grow-route-leak-problem-definition]), which it shouldn't.
Please replace those with straight textual mentions of the documents in
question.
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 205: '...AS1 in Figure 1) SHOULD NOT have forwa...'
RFC 2119 keyword, line 233: '... RLP field value SHOULD be set to one ...'
RFC 2119 keyword, line 239: '...he prefix-update SHOULD NOT be forward...'
RFC 2119 keyword, line 242: '...arios when a sending AS SHOULD set the...'
RFC 2119 keyword, line 247: '...bsequent AS path SHOULD NOT forward th...'
(5 more instances...)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (March 9, 2015) is 3336 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Missing Reference: 'RFC 6811' is mentioned on line 16, but not defined
== Unused Reference: 'Cowie2010' is defined on line 498, but no explicit
reference was found in the text
== Unused Reference: 'Cowie2013' is defined on line 504, but no explicit
reference was found in the text
== Unused Reference: 'Gao' is defined on line 510, but no explicit
reference was found in the text
== Unused Reference: 'Gill' is defined on line 515, but no explicit
reference was found in the text
== Unused Reference: 'Giotsas' is defined on line 520, but no explicit
reference was found in the text
== Unused Reference: 'Hiran' is defined on line 526, but no explicit
reference was found in the text
== Unused Reference: 'Huston2012' is defined on line 532, but no explicit
reference was found in the text
== Unused Reference: 'Huston2014' is defined on line 536, but no explicit
reference was found in the text
== Unused Reference: 'Kapela-Pilosov' is defined on line 550, but no
explicit reference was found in the text
== Unused Reference: 'Khare' is defined on line 557, but no explicit
reference was found in the text
== Unused Reference: 'LRL' is defined on line 562, but no explicit
reference was found in the text
== Unused Reference: 'Labovitz' is defined on line 567, but no explicit
reference was found in the text
== Unused Reference: 'Luckie' is defined on line 574, but no explicit
reference was found in the text
== Unused Reference: 'Madory' is defined on line 579, but no explicit
reference was found in the text
== Unused Reference: 'Mauch' is defined on line 584, but no explicit
reference was found in the text
== Unused Reference: 'Mauch-nanog' is defined on line 588, but no explicit
reference was found in the text
== Unused Reference: 'Paseka' is defined on line 594, but no explicit
reference was found in the text
== Unused Reference: 'Toonk' is defined on line 603, but no explicit
reference was found in the text
== Unused Reference: 'Wijchers' is defined on line 607, but no explicit
reference was found in the text
== Unused Reference: 'Zmijewski' is defined on line 613, but no explicit
reference was found in the text
== Outdated reference: A later version (-06) exists of
draft-ietf-grow-route-leak-problem-definition-00
== Outdated reference: A later version (-23) exists of
draft-ietf-sidr-bgpsec-protocol-11
Summary: 2 errors (**), 0 flaws (~~), 24 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 IDR and SIDR K. Sriram
3 Internet-Draft D. Montgomery
4 Intended status: Informational US NIST
5 Expires: September 10, 2015 March 9, 2015
7 Methods for Detection and Mitigation of BGP Route Leaks
8 draft-sriram-idr-route-leak-detection-mitigation-00
10 Abstract
12 In [I-D.ietf-grow-route-leak-problem-definition], the authors have
13 provided a definition of the route leak problem, and also enumerated
14 several types of route leaks. In this document, we first examine
15 which of those route-leak types are detected and mitigated by the
16 existing origin validation [RFC 6811] and BGPSEC path validation [I-
17 D.ietf-sidr-bgpsec-protocol]. Where the current BGPSEC protocol
18 doesn't offer a solution, this document suggests an enhancement that
19 would extend the route-leak detection and mitigation capability of
20 BGPSEC. The solution can be implemented in BGP without necessarily
21 tying it to BGPSEC. Incorporating the solution in BGPSEC is one way
22 of implementing it in a secure way. We do not claim to have provided
23 a solution for all possible types of route leaks, but the solution
24 covers several, especially considering some significant route-leak
25 attacks or occurrences that have been observed in recent years. The
26 document also includes a stopgap method for detection and mitigation
27 of route leaks for the phase when BGPSEC (path validation) is not yet
28 deployed but only origin validation is deployed.
30 Status of This Memo
32 This Internet-Draft is submitted in full conformance with the
33 provisions of BCP 78 and BCP 79.
35 Internet-Drafts are working documents of the Internet Engineering
36 Task Force (IETF). Note that other groups may also distribute
37 working documents as Internet-Drafts. The list of current Internet-
38 Drafts is at http://datatracker.ietf.org/drafts/current/.
40 Internet-Drafts are draft documents valid for a maximum of six months
41 and may be updated, replaced, or obsoleted by other documents at any
42 time. It is inappropriate to use Internet-Drafts as reference
43 material or to cite them other than as "work in progress."
45 This Internet-Draft will expire on September 10, 2015.
47 Copyright Notice
49 Copyright (c) 2015 IETF Trust and the persons identified as the
50 document authors. All rights reserved.
52 This document is subject to BCP 78 and the IETF Trust's Legal
53 Provisions Relating to IETF Documents
54 (http://trustee.ietf.org/license-info) in effect on the date of
55 publication of this document. Please review these documents
56 carefully, as they describe your rights and restrictions with respect
57 to this document. Code Components extracted from this document must
58 include Simplified BSD License text as described in Section 4.e of
59 the Trust Legal Provisions and are provided without warranty as
60 described in the Simplified BSD License.
62 Table of Contents
64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
65 2. Mechanisms for Detection and Mitigation of Route Leaks . . . 3
66 2.1. Route Leak Protection (RLP) Field Encoding by Sending
67 Router . . . . . . . . . . . . . . . . . . . . . . . . . 5
68 2.2. Recommended Actions at a Receiving Router . . . . . . . . 7
69 2.3. Detection and Mitigation of Route Leaks of Type 5 and
70 Type 6 . . . . . . . . . . . . . . . . . . . . . . . . . 8
71 3. Stopgap Solution when Only Origin Validation is Deployed . . 9
72 4. Design Rationale and Discussion . . . . . . . . . . . . . . . 10
73 4.1. Downside of 'Up (Towards Provider AS)' Indication in the
74 RLP Field . . . . . . . . . . . . . . . . . . . . . . . . 10
75 4.2. Possibility of Abuse of '01' (i.e. 'Do not Propagate Up')
76 Indication in the RLP Field . . . . . . . . . . . . . . . 10
77 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
82 9.1. Normative References . . . . . . . . . . . . . . . . . . 11
83 9.2. Informative References . . . . . . . . . . . . . . . . . 12
84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
86 1. Introduction
88 In [I-D.ietf-grow-route-leak-problem-definition], the authors have
89 provided a definition of the route leak problem, and also enumerated
90 several types of route leaks. In this document, we first examine
91 which of those route-leak types are detected and mitigated by the
92 existing Origin Validation (OV) [RFC6811] and BGPSEC path validation
93 [I-D.ietf-sidr-bgpsec-protocol]. For the rest of this document, we
94 use the term BGPSEC as synonymous with path validation. The BGPSEC
95 protocol provides cryptographic protection for some aspects of BGP
96 update messages. OV and BGPSEC together offer mechanisms to protect
97 against mis-originations and hijacks of IP prefixes as well as man-
98 in-the-middle (MITM) AS path modifications. Route leaks (see
99 [I-D.ietf-grow-route-leak-problem-definition] and references cited at
100 the back) are another type of vulnerability in the global BGP routing
101 system against which BGPSEC so far offers only partial protection.
103 For the types of route leaks enumerated in
104 [I-D.ietf-grow-route-leak-problem-definition], where the current
105 BGPSEC protocol doesn't offer a solution, this document suggests an
106 enhancement that would extend the detection and mitigation capability
107 of BGPSEC. The solution can be implemented in BGP without
108 necessarily tying it to BGPSEC. Incorporating the solution in BGPSEC
109 is one way of implementing it in a secure way. We do not claim to
110 provide a solution for all possible types of route leaks, but the
111 solution covers several relevant types, especially considering some
112 significant route-leak occurrences that have been observed frequently
113 in recent years. The document also includes (in Section 3) a stopgap
114 method for detection and mitigation of route leaks for the phase when
115 BGPSEC (path validation) is not yet deployed but only origin
116 validation is deployed.
118 2. Mechanisms for Detection and Mitigation of Route Leaks
120 Referring to the enumeration of route leaks discussed in
121 [I-D.ietf-grow-route-leak-problem-definition], Table 1 summarizes the
122 route-leak detection capability offered by OV and BGPSEC for
123 different types of route leaks. (Note: Route filtering is not
124 considered here in this table. Please see Section 3.)
126 A detailed explanation of the contents of Table 1 is as follows. It
127 is readily observed that route leaks of Types 1, 5, 6, and 7 are not
128 detected by OV or even by BGPSEC. Type 2 route leak involves
129 changing a prefix to a subprefix (i.e. more specific); such a
130 modified update will fail BGPSEC checks. Clearly, Type 3 route leak
131 involves hijacking and hence can be detected by OV. In the case of
132 Type 3 route leak, there would be no existing ROAs to validate a re-
133 originated prefix or subprefix, and hence the update will be
134 considered Invalid by OV.
136 +---------------------------------+---------------------------------+
137 | Type of Route Leak | Detection Coverage and Comments |
138 +---------------------------------+---------------------------------+
139 | Type 1: U-Turn with Full Prefix | Neither OV nor BGPSEC (in its |
140 | | current form) detects Type 1. |
141 | ------------------------------- | ------------------------------- |
142 | Type 2: U-Turn with More | In OV, the ROA maxLength may |
143 | Specific Prefix | offer detection of Type 2 in |
144 | | some cases; BGPSEC (in its |
145 | | current form) always detects |
146 | | Type 2. |
147 | ------------------------------- | ------------------------------- |
148 | Type 3: Prefix Hijack with Data | OV by itself detects Type 3; |
149 | Path to Legitimate Origin | BGPSEC does not detect Type 3. |
150 | ------------------------------- | ------------------------------- |
151 | Type 4: Leak of Internal | For internal prefixes never |
152 | Prefixes and Accidental | meant to be seen (i.e. routed) |
153 | Deaggregation | on the Internet, OV helps |
154 | | detect their leak; they might |
155 | | either have no covering ROA or |
156 | | have a ROA-AS0 to always filter |
157 | | them. In the case of accidental |
158 | | deaggregation, OV may offer |
159 | | some detection due to ROA |
160 | | maxLength. BGPSEC does not |
161 | | catch Type 4. |
162 | ------------------------------- | ------------------------------- |
163 | Type 5: Lateral ISP-ISP-ISP | Neither OV nor BGPSEC (in its |
164 | Leak | current form) detects Type 5. |
165 | ------------------------------- | ------------------------------- |
166 | Type 6: Leak of Provider | Neither OV nor BGPSEC (in its |
167 | Prefixes to Peer | current form) detects Type 6. |
168 | ------------------------------- | ------------------------------- |
169 | Type 7: Leak of Peer Prefixes | Neither OV nor BGPSEC (in its |
170 | to Provider | current form) detects Type 7. |
171 +---------------------------------+---------------------------------+
173 Table 1: Examination of Route-Leak Detection Capability of Origin
174 Validation and Current BGPSEC Path Validation
176 In the case of Type 4 leaks involving internal prefixes that are not
177 meant to be routed in the Internet, they are likely to be detected by
178 OV. That is because such prefixes might either have no covering ROA
179 or have a ROA-AS0 to always filter them. In the case of Type 4 leaks
180 that are due to accidental deaggregation, they may be detected due to
181 violation of ROA maxLength. BGPSEC does not catch Type 4. However,
182 route leaks of Type 4 are least problematic due to the following
183 reasons. In the case of accidental deaggregation, the offending AS
184 is itself the legitimate destination of the leaked more-specific
185 prefixes. Hence, in most cases of this type, the data traffic is
186 neither misrouted not denied service. Also, leaked announcements of
187 Type 4 are short-lived and typically withdrawn quickly following the
188 announcements. Further, the MaxPrefix limit may kick in in some
189 receiving routers and that helps limit the propagation of sometimes
190 large number of leaked routes of Type 4.
192 From the above, it is evident that in our proposed solution method,
193 we need to focus primarily on route leaks of Types 1, 5, 6, and 7.
194 In Section 2.1 and Section 2.2, we describe a simple addition to
195 BGPSEC that facilitates cryptographically-enabled detection of route
196 leaks of Types 1 and 7. Then in Section 2.3, we will explain how the
197 same method as described in Section 2.1 can be utilized between ISPs
198 (or ASes) to detect and mitigate route leaks of Types 5 and 6.
200 2.1. Route Leak Protection (RLP) Field Encoding by Sending Router
202 The key principle is that, in the event of a route leak, a receiving
203 router in a provider AS (e.g. referring to Figure 1, ISP2 (AS3)
204 router) should be able to detect from the prefix-update that its
205 customer AS (e.g. AS1 in Figure 1) SHOULD NOT have forwarded the
206 update (towards the provider AS). This means that at least one of
207 the ASes in the AS path of the update has indicated that it sent the
208 update to its customer or peer AS, but forbade any subsequent 'Up'
209 forwarding (i.e. from a customer AS to its provider AS). For this
210 purpose, a Route Leak Protection (RLP) field to be set by a sending
211 router is proposed to be used for each AS hop.
213 /\ /\
214 \ route-leak(P)/
215 \ propagated /
216 \ /
217 +------------+ peer +------------+
218 ______| ISP1 (AS2) |----------->| ISP2 (AS3)|---------->
219 / ------------+ prefix(P) +------------+ route-leak(P)
220 | prefix | \ update /\ \ propagated
221 \ (P) / \ / \
222 ------- prefix(P) \ / \
223 update \ / \
224 \ /route-leak(P) \/
225 \/ /
226 +---------------+
227 | customer(AS1) |
228 +---------------+
230 Figure 1: Illustration of the basic notion of a route leak.
232 For the purpose of route leak detection and mitigation proposed in
233 this document, the RLP field value SHOULD be set to one of two values
234 as follows:
236 o 00: This is the default value (i.e. "nothing specified"),
238 o 01: This is the 'Do not Propagate Up' indication; sender
239 indicating that the prefix-update SHOULD NOT be forwarded 'Up'
240 towards a provider AS.
242 There are two different scenarios when a sending AS SHOULD set the
243 '01' indication in a prefix-update: (1) when sending the prefix-
244 update to a customer AS, and (2) to let a peer AS know not to forward
245 the prefix-update 'Up' towards a provide AS. In essence, in both
246 scenarios, the intent of '01' indication is that any receiving AS
247 along the subsequent AS path SHOULD NOT forward the prefix-update
248 'Up' towards its (receiving AS's) provider AS.
250 One may argue for an RLP field value (e.g. '10') to be used to
251 specify 'Up' (i.e. towards provider AS) directionality. But in the
252 interest of keeping the methodology simple, the choice of two RLP
253 field values as defined above (00 - default, and 01 - 'Do not
254 Propagate Up') is all that is needed. This two-state specification
255 in the RLP field can be shown to work for detection and mitigation of
256 route leaks of Types 1 and 7 readily (and also Types 5 and 6; see
257 Section 2.3), which are the focus here. (Please see Section 4 for
258 further discussion about the downside using 'Up' indication.)
259 In general, the proposed RLP encoding can be carried in BGP-4
260 [RFC4271] updates in any possible way, e.g., in a transitive
261 community attribute. We consider BGPSEC as an example, where the RLP
262 encoding can be accommodated in the existing Flags field and thereby
263 secured using the existing BGPSEC path signatures. The Flags field
264 is part of the Secure_Path Segment in BPGSEC updates
265 [I-D.ietf-sidr-bgpsec-protocol]. It is one octet long, and one Flags
266 field is available for each AS hop, and currently only the first bit
267 is used in BGPSEC. So there are 7 bits that are currently unused in
268 the Flags field. Two (or more if needed) of these bits can be
269 designated for the RLP field. Since the BGPSEC protocol
270 specification requires a sending AS to include the Flags field in the
271 data that are signed over, the RLP field for each hop (assuming it
272 would be part of the Flags field) will be protected under the sending
273 AS's signature.
275 2.2. Recommended Actions at a Receiving Router
277 We provide here an example set of receiver actions that work to
278 detect and mitigate route leaks of Types 1 and 7 (in particular).
279 This example algorithm serves as a proof of concept. However, other
280 receiver algorithms or procedures can be designed (based on the same
281 sender specification as in Section 2.1) and may perform with greater
282 efficacy, and are by no means excluded.
284 A recommended receiver algorithm for detecting a route leak is as
285 follows:
287 A receiving BGPSEC router SHOULD mark an update as a Route-Leak if
288 ALL of the following conditions hold true:
290 1. The update is received from a customer AS.
292 2. It is Valid in accordance with the BGPSEC protocol.
294 3. The update has the RLP field set to '01' (i.e. 'Do not Propagate
295 Up') indication for one or more hops (excluding the most recent)
296 in the AS path.
298 The reason for stating "excluding the most recent" in the above
299 algorithm is as follows. The provider AS already knows that most
300 recent hop in the update is from its customer AS to itself, and hence
301 it does not need to rely on the RLP field value set by the customer
302 for detection of route leaks. (See further discussion in
303 Section 4.1.)
305 After applying the above detection algorithm, a receiving router may
306 use any policy-based algorithm of its own choosing to mitigate any
307 detected route leaks. An example receiver algorithm for mitigating a
308 route leak is as follows:
310 o If an update from a customer AS is marked as a Route-Leak, then
311 the receiving router SHOULD prefer a Valid signed update from a
312 peer or an upstream provider over the customer's update.
314 The basic principle here is that the presence of '01' value in the
315 RLP field corresponding to one or more AS hops in the AS path of an
316 update coming from a customer AS informs a receiving router in a
317 provider AS that a route leak is likely occurring. The provider AS
318 then overrides the "prefer customer route" policy, and instead
319 prefers a route learned from a peer or another upstream provider over
320 the customer's route.
322 A receiving router expects the RLP field value for any hop in the AS
323 path to be either 00 or 01. However, if a different value (say, 10
324 or 11) is found in the RLP field, then an error condition will get
325 flagged, and any further action is TBD.
327 2.3. Detection and Mitigation of Route Leaks of Type 5 and Type 6
329 The sender and receiver actions described in Section 2.1 and
330 Section 2.2 clearly help detect and mitigate route leaks of Types 1
331 and 7. With a slightly modified interpretation of the RLP encoding
332 on the receiver side, they can be extended to detect lateral ISP-ISP-
333 ISP route leaks (Type 5) as well as leaks of provider prefixes to
334 peer (Type 6). A sending ISP router would set RLP field value to
335 '01' indication towards a peer AS or a customer AS, following the
336 same sender principles as described in Section 2.1.
338 A recommended receiver algorithm for an ISP to detect a route leak of
339 either Type 5 or Type 6 is as follows:
341 A receiving BGPSEC router SHOULD mark an update as a Route-Leak if
342 ALL of the following conditions hold true:
344 1. The update is received from a lateral ISP peer or a customer AS.
346 2. It is Valid in accordance with the BGPSEC protocol.
348 3. The update has the RLP field set to '01' indication for one or
349 more hops (excluding the most recent) in the AS path.
351 In the above algorithm, the receiving AS interprets the '01'
352 indication slightly strongly (i.e. stronger than in Section 2.2) to
353 mean "the update SHOULD NOT have been propagated laterally to a peer
354 ISP like me either". The rationale here is based on the fact that
355 settlement-free ISP peers accept only customer prefix-routes from
356 each other. The receiving AS applies the logic that if a preceding
357 AS (excluding the most recent) set '01' indication, it means that the
358 update was sent to a peer or a customer by the (preceding) AS, and
359 the update should not be traversing a lateral peer-to-peer link
360 subsequently.
362 The receiver algorithm for mitigation is up to the discretion of the
363 ISP. It may simply prefer another unmarked (i.e. not route-leak)
364 update from a different peer or an upstream ISP over a marked update.
366 3. Stopgap Solution when Only Origin Validation is Deployed
368 During a phase when BGPSEC path validation has not yet been deployed
369 but only origin validation has been deployed, it would be good have a
370 stopgap solution for route leaks. The stopgap solution can be in the
371 form of construction of a prefix filter list from ROAs. A suggested
372 procedure for constructing such a list comprises of the following
373 steps:
375 o ISP makes a list of all the ASes (Cust_AS_List) that are in its
376 customer cone (ISP's own AS is also included in the list). (Some
377 of the ASes in Cust_AS_List may be multi-homed to another ISP and
378 that is OK.)
380 o ISP downloads from the RPKI repositories a complete list
381 (Cust_ROA_List) of valid ROAs that contain any of the ASes in
382 Cust_AS_List.
384 o ISP creates a list of all the prefixes (Cust_Prfx_List) that are
385 contained in any of the ROAs in Cust_ROA_List.
387 o Cust_Prfx_List is the allowed list of prefixes that is permitted
388 by the ISP's AS, and will be forwarded by the ISP to upstream
389 ISPs, customers, and peers.
391 o Any prefix not in Cust_Prfx_List but announced by any of the ISP's
392 customers is marked as a potential route leak. Then the ISP's
393 router SHOULD prefer a Valid (i.e. valid according to origin
394 validation) and 'not marked' update from a peer or an upstream
395 provider over the customer's marked update for that prefix.
397 Special considerations with regard to the above procedure may be
398 needed for DDoS mitigation service providers. They typically
399 originate or announce a DDoS victim's prefix to their own ISP on a
400 short notice during a DDoS emergency. Some provisions would need to
401 be made for such cases, and they can be determined with the help of
402 inputs from DDoS mitigation service providers.
404 4. Design Rationale and Discussion
406 In this section, we will try to provide design justifications for the
407 methodology specified in Section 2, and also answer some anticipated
408 questions.
410 4.1. Downside of 'Up (Towards Provider AS)' Indication in the RLP Field
412 As we have shown in Section 2, route leak detection and mitigation
413 can be performed without the use of 'Up' (i.e. from customer AS to
414 provider AS) indication in the RLP field. The detection and
415 mitigation action should primarily occur at a provider AS's router
416 just as soon as a leaked update is received from a customer AS. At
417 that point, a provider AS can be fooled if it merely looks to see if
418 an offending customer AS has set an 'Up' indication in the RLP field.
419 This is so since a customer AS intent on leaking a route can
420 deliberately set "Not Specified (00)" indication in order to misguide
421 its provider AS. So it seems better that a provider AS figures out
422 that the update is moving in the 'Up' direction based only on its own
423 (configuration-based) knowledge that the update is coming from one of
424 its customer ASes. An 'Up' indication (if it were allowed) can be
425 also potentially misused. For example, an AS in the middle can
426 determine that a '01' (i.e. 'Do not Propagate Up') value already
427 exists on one of the preceding AS hops in a received update's AS
428 path. Then, said AS in the middle can deliberately set its own RLP
429 field to signal 'Up', in which case the update may be erroneously
430 marked as a route leak by a subsequent AS if it concludes that there
431 was a valley in the AS path of the update. So there appears to be
432 some possibility of misuse of 'Up' indication, and hence we proposed
433 not including it in the RLP specification in Section 2. However,
434 other proposals, if any, that aim to beneficially use an 'Up'
435 indication in the RLP field would be worth discussing.
437 4.2. Possibility of Abuse of '01' (i.e. 'Do not Propagate Up')
438 Indication in the RLP Field
440 In reality, there appears to be no gain or incentive for an AS to
441 falsely set its own RLP field to '01' (i.e. 'Do not Propagate Up')
442 indication in an update that it originates or forwards. The purpose
443 of a deliberate route leak by an AS is to attract traffic towards
444 itself, but if the AS were to falsely set its own RLP field to '01'
445 value, it would be effectively repelling some or all traffic away
446 from itself for the prefix in question (see receiver algorithms in
447 Section 2.2 and Section 2.3).
449 5. Summary
451 It should be emphasized once again that the proposed route-leak
452 detection method using the RLP encoding is not intended to cover all
453 forms of route leaks. However, we feel that the solution covers
454 several important types of route leaks, especially considering some
455 significant route-leak attacks or occurrences that have been
456 frequently observed in recent years. The solution can be implemented
457 in BGP without necessarily tying it to BGPSEC. Carrying the proposed
458 RLP encoding in a transitive community attribute in BGP is another
459 way, but in order to prevent abuse, the community attribute would
460 require cryptographic protection. Incorporating the RLP encoding in
461 the BGPSEC Flags field is one way of implementing it securely using
462 an already existing protection mechanism provided in BGPSEC path
463 signatures.
465 6. Security Considerations
467 The proposed Route Leak Protection (RLP) field requires cryptographic
468 protection. Since it is proposed that the RLP field be included in
469 the Flags field in the Secure_Path Segment in BPGSEC updates, the
470 cryptographic security mechanisms in BGPSEC are expected to also
471 apply to the RLP field. The reader is therefore directed to the
472 security considerations provided in [I-D.ietf-sidr-bgpsec-protocol].
474 7. IANA Considerations
476 No updates to the registries are suggested by this document.
478 8. Acknowledgements
480 The authors wish to thank Danny McPherson and Eric Osterweil for
481 discussions related to this work. Also, thanks are due to Jared
482 Mauch, Jeff Haas, Warren Kumari, Brian Dickson, Amogh Dhamdhere,
483 Jakob Heitz, Geoff Huston, Randy Bush, Ruediger Volk, Andrei
484 Robachevsky, Chris Morrow, and Sandy Murphy for comments,
485 suggestions, and critique. The authors are also thankful to Padma
486 Krishnaswamy, Oliver Borchert, and Okhee Kim for their comments and
487 review.
489 9. References
491 9.1. Normative References
493 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
494 Protocol 4 (BGP-4)", RFC 4271, January 2006.
496 9.2. Informative References
498 [Cowie2010]
499 Cowie, J., "China's 18 Minute Mystery", Dyn Research/
500 Renesys Blog, November 2010,
501 .
504 [Cowie2013]
505 Cowie, J., "The New Threat: Targeted Internet Traffic
506 Misdirection", Dyn Research/Renesys Blog, November 2013,
507 .
510 [Gao] Gao, L. and J. Rexford, "Stable Internet routing without
511 global coordination", IEEE/ACM Transactions on Networking,
512 December 2001, .
515 [Gill] Gill, P., Schapira, M., and S. Goldberg, "A Survey of
516 Interdomain Routing Policies", ACM SIGCOMM Computer
517 Communication Review, January 2014,
518 .
520 [Giotsas] Giotsas, V. and S. Zhou, "Valley-free violation in
521 Internet routing - Analysis based on BGP Community data",
522 IEEE ICC 2012, June 2012,
523 .
526 [Hiran] Hiran, R., Carlsson, N., and P. Gill, "Characterizing
527 Large-scale Routing Anomalies: A Case Study of the China
528 Telecom Incident", PAM 2013, March 2013,
529 .
532 [Huston2012]
533 Huston, G., "Leaking Routes", March 2012,
534 .
536 [Huston2014]
537 Huston, G., "What's so special about 512?", September
538 2014, .
540 [I-D.ietf-grow-route-leak-problem-definition]
541 Sriram, K., Montgomery, D., McPherson, D., and E.
542 Osterweil, "Problem Definition and Classification of BGP
543 Route Leaks", draft-ietf-grow-route-leak-problem-
544 definition-00 (work in progress), February 2015.
546 [I-D.ietf-sidr-bgpsec-protocol]
547 Lepinski, M., "BGPsec Protocol Specification", draft-ietf-
548 sidr-bgpsec-protocol-11 (work in progress), January 2015.
550 [Kapela-Pilosov]
551 Pilosov, A. and T. Kapela, "Stealing the Internet: An
552 Internet-Scale Man in the Middle Attack", DEFCON-16 Las
553 Vegas, NV, USA, August 2008,
554 .
557 [Khare] Khare, V., Ju, Q., and B. Zhang, "Concurrent Prefix
558 Hijacks: Occurrence and Impacts", IMC 2012, Boston, MA,
559 November 2012, .
562 [LRL] Khare, V., Ju, Q., and B. Zhang, "Large Route Leaks",
563 Project web page, 2012,
564 .
567 [Labovitz]
568 Labovitz, C., "Additional Discussion of the April China
569 BGP Hijack Inciden", Arbor Networks IT Security Blog,
570 November 2010,
571 .
574 [Luckie] Luckie, M., Huffaker, B., Dhamdhere, A., Giotsas, V., and
575 kc. claffy, "AS Relationships, Customer Cones, and
576 Validation", IMC 2013, October 2013,
577 .
579 [Madory] Madory, D., "Why Far-Flung Parts of the Internet Broke
580 Today", Dyn Research/Renesys Blog, September 2014,
581 .
584 [Mauch] Mauch, J., "BGP Routing Leak Detection System", Project
585 web page, 2014,
586 .
588 [Mauch-nanog]
589 Mauch, J., "Detecting Routing Leaks by Counting", NANOG-41
590 Albuquerque, NM, USA, October 2007,
591 .
594 [Paseka] Paseka, T., "Why Google Went Offline Today and a Bit about
595 How the Internet Works", CloudFare Blog, November 2012,
596 .
599 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
600 Austein, "BGP Prefix Origin Validation", RFC 6811, January
601 2013.
603 [Toonk] Toonk, A., "What Caused Today's Internet Hiccup", August
604 2014, .
607 [Wijchers]
608 Wijchers, B. and B. Overeinder, "Quantitative Analysis of
609 BGP Route Leaks", RIPE-69, November 2014,
610 .
613 [Zmijewski]
614 Zmijewski, E., "Indonesia Hijacks the World", Dyn
615 Research/Renesys Blog, April 2014,
616 .
619 Authors' Addresses
621 Kotikalapudi Sriram
622 US NIST
624 Email: ksriram@nist.gov
626 Doug Montgomery
627 US NIST
629 Email: dougm@nist.gov