idnits 2.17.1
draft-ietf-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 249: '...AS3 in Figure 1) SHOULD NOT have forwa...'
RFC 2119 keyword, line 277: '... RLP field value SHOULD be set to one ...'
RFC 2119 keyword, line 283: '...he prefix-update SHOULD NOT be forward...'
RFC 2119 keyword, line 286: '...arios when a sending AS SHOULD set the...'
RFC 2119 keyword, line 291: '...bsequent AS path SHOULD NOT forward th...'
(8 more instances...)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (July 22, 2015) is 3200 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'RFC 6811' is mentioned on line 18, but not defined
== Unused Reference: 'Cowie2010' is defined on line 576, but no explicit
reference was found in the text
== Unused Reference: 'Cowie2013' is defined on line 582, but no explicit
reference was found in the text
== Unused Reference: 'Gao' is defined on line 606, but no explicit
reference was found in the text
== Unused Reference: 'Gill' is defined on line 612, but no explicit
reference was found in the text
== Unused Reference: 'Giotsas' is defined on line 617, but no explicit
reference was found in the text
== Unused Reference: 'Hiran' is defined on line 623, but no explicit
reference was found in the text
== Unused Reference: 'Huston2012' is defined on line 629, but no explicit
reference was found in the text
== Unused Reference: 'Huston2014' is defined on line 633, but no explicit
reference was found in the text
== Unused Reference: 'Kapela-Pilosov' is defined on line 647, but no
explicit reference was found in the text
== Unused Reference: 'Khare' is defined on line 654, but no explicit
reference was found in the text
== Unused Reference: 'Labovitz' is defined on line 659, but no explicit
reference was found in the text
== Unused Reference: 'LRL' is defined on line 666, but no explicit
reference was found in the text
== Unused Reference: 'Luckie' is defined on line 671, but no explicit
reference was found in the text
== Unused Reference: 'Madory' is defined on line 676, but no explicit
reference was found in the text
== Unused Reference: 'Mauch' is defined on line 681, but no explicit
reference was found in the text
== Unused Reference: 'Mauch-nanog' is defined on line 685, but no explicit
reference was found in the text
== Unused Reference: 'Paseka' is defined on line 697, but no explicit
reference was found in the text
== Unused Reference: 'Toonk' is defined on line 721, but no explicit
reference was found in the text
== Unused Reference: 'Wijchers' is defined on line 725, but no explicit
reference was found in the text
== Unused Reference: 'Zmijewski' is defined on line 731, but no explicit
reference was found in the text
== Outdated reference: A later version (-06) exists of
draft-ietf-grow-route-leak-problem-definition-02
== Outdated reference: A later version (-23) exists of
draft-ietf-sidr-bgpsec-protocol-13
-- Obsolete informational reference (is this intentional?): RFC 1105
(Obsoleted by RFC 1163)
Summary: 2 errors (**), 0 flaws (~~), 24 warnings (==), 2 comments (--).
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: Standards Track US NIST
5 Expires: January 23, 2016 B. Dickson
6 Twitter, Inc.
7 July 22, 2015
9 Methods for Detection and Mitigation of BGP Route Leaks
10 draft-ietf-idr-route-leak-detection-mitigation-00
12 Abstract
14 In [I-D.ietf-grow-route-leak-problem-definition], the authors have
15 provided a definition of the route leak problem, and also enumerated
16 several types of route leaks. In this document, we first examine
17 which of those route-leak types are detected and mitigated by the
18 existing origin validation (OV) [RFC 6811] and BGPSEC path validation
19 [I-D.ietf-sidr-bgpsec-protocol]. Where the current OV and BGPSEC
20 protocols don't offer a solution, this document suggests an
21 enhancement that would extend the route-leak detection and mitigation
22 capability of BGPSEC. The solution can be implemented in BGP without
23 necessarily tying it to BGPSEC. Incorporating the solution in BGPSEC
24 is one way of implementing it in a secure way. We do not claim to
25 have provided a solution for all possible types of route leaks, but
26 the solution covers several, especially considering some significant
27 route-leak attacks or occurrences that have been observed in recent
28 years. The document also includes a stopgap method for detection and
29 mitigation of route leaks for the phase when BGPSEC (path validation)
30 is not yet deployed but only origin validation is deployed.
32 Status of This Memo
34 This Internet-Draft is submitted in full conformance with the
35 provisions of BCP 78 and BCP 79.
37 Internet-Drafts are working documents of the Internet Engineering
38 Task Force (IETF). Note that other groups may also distribute
39 working documents as Internet-Drafts. The list of current Internet-
40 Drafts is at http://datatracker.ietf.org/drafts/current/.
42 Internet-Drafts are draft documents valid for a maximum of six months
43 and may be updated, replaced, or obsoleted by other documents at any
44 time. It is inappropriate to use Internet-Drafts as reference
45 material or to cite them other than as "work in progress."
47 This Internet-Draft will expire on January 23, 2016.
49 Copyright Notice
51 Copyright (c) 2015 IETF Trust and the persons identified as the
52 document authors. All rights reserved.
54 This document is subject to BCP 78 and the IETF Trust's Legal
55 Provisions Relating to IETF Documents
56 (http://trustee.ietf.org/license-info) in effect on the date of
57 publication of this document. Please review these documents
58 carefully, as they describe your rights and restrictions with respect
59 to this document. Code Components extracted from this document must
60 include Simplified BSD License text as described in Section 4.e of
61 the Trust Legal Provisions and are provided without warranty as
62 described in the Simplified BSD License.
64 Table of Contents
66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
67 2. Related Prior Work . . . . . . . . . . . . . . . . . . . . . 3
68 3. Mechanisms for Detection and Mitigation of Route Leaks . . . 4
69 3.1. Route Leak Protection (RLP) Field Encoding by Sending
70 Router . . . . . . . . . . . . . . . . . . . . . . . . . 6
71 3.2. Recommended Actions at a Receiving Router for Detection
72 of Route Leaks . . . . . . . . . . . . . . . . . . . . . 8
73 3.2.1. Recommended Actions at a Receiving Router when the
74 Sender is a Customer . . . . . . . . . . . . . . . . 8
75 3.2.2. Recommended Actions at a Receiving Router when the
76 Sender is a Peer . . . . . . . . . . . . . . . . . . 9
77 3.3. Possible Actions at a Receiving Router for Mitigation . . 10
78 4. Stopgap Solution when Only Origin Validation is Deployed . . 10
79 5. Design Rationale and Discussion . . . . . . . . . . . . . . . 11
80 5.1. Is route-leak solution without BGPSEC a serious attack
81 vector? . . . . . . . . . . . . . . . . . . . . . . . . . 11
82 5.2. Comparison with other methods, routing security BCP . . . 12
83 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
86 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
88 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
89 10.2. Informative References . . . . . . . . . . . . . . . . . 13
90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
92 1. Introduction
94 In [I-D.ietf-grow-route-leak-problem-definition], the authors have
95 provided a definition of the route leak problem, and also enumerated
96 several types of route leaks. In this document, we first examine
97 which of those route-leak types are detected and mitigated by the
98 existing Origin Validation (OV) [RFC6811] and BGPSEC path validation
99 [I-D.ietf-sidr-bgpsec-protocol]. For the rest of this document, we
100 use the term BGPSEC as synonymous with path validation. The BGPSEC
101 protocol provides cryptographic protection for some aspects of BGP
102 update messages. OV and BGPSEC together offer mechanisms to protect
103 against mis-originations and hijacks of IP prefixes as well as man-
104 in-the-middle (MITM) AS path modifications. Route leaks (see
105 [I-D.ietf-grow-route-leak-problem-definition] and references cited at
106 the back) are another type of vulnerability in the global BGP routing
107 system against which OV and BGPSEC so far offer only partial
108 protection.
110 For the types of route leaks enumerated in
111 [I-D.ietf-grow-route-leak-problem-definition], where the current OV
112 and BGPSEC protocols don't offer a solution, this document suggests
113 an enhancement that would extend the detection and mitigation
114 capability of BGPSEC. The solution can be implemented in BGP without
115 necessarily tying it to BGPSEC. Incorporating the solution in BGPSEC
116 is one way of implementing it in a secure way. We do not claim to
117 provide a solution for all possible types of route leaks, but the
118 solution covers several relevant types, especially considering some
119 significant route-leak occurrences that have been observed frequently
120 in recent years. The document also includes (in Section 4) a stopgap
121 method for detection and mitigation of route leaks for the phase when
122 BGPSEC (path validation) is not yet deployed but only origin
123 validation is deployed.
125 2. Related Prior Work
127 The basic idea and mechanism embodied in the proposed solution is
128 based on setting an attribute in BGP route announcement to manage the
129 transmission/receipt of the announcement based on the type of
130 neighbor (e.g. customer, provider, etc.). Documented prior work
131 related to said basic idea and mechanism dates back to at least the
132 1980's. Some examples of prior work are: (1) Information flow rules
133 described in [proceedings-sixth-ietf] (see pp. 195-196); (2) Link
134 Type described in [RFC1105-obsolete] (see pp. 4-5); (3) Hierarchical
135 Recording described in [draft-kunzinger-idrp-ISO10747-01] (see
136 Section 6.3.1.12). The problem of route leaks and possible solution
137 mechanisms based on encoding peering-link type information (e.g. p2c,
138 c2p, p2p, etc.) in BGPSEC updates and protecting the same under
139 BGPSEC path signatures have been discussed in IETF SIDR WG at least
140 since 2011. Dickson developed the initial Internet draft of these
141 mechanisms in a BGPSEC context; see
142 [draft-dickson-sidr-route-leak-solns]. The draft expired in 2012.
143 [draft-dickson-sidr-route-leak-solns] defined neighbor relationships
144 on a per link basis, but in the current draft the relationship in
145 encoded per prefix, as prefixes with different business models are
146 often sent over the same link. Also
147 [draft-dickson-sidr-route-leak-solns] proposed a second signature
148 block for the link type encoding, separate from the path signature
149 block in BGPSEC. By contrast, in the current draft when BGPSEC-based
150 solution is considered, cryptographic protection is provided for
151 Route Leak Protection (RLP) encoding using the same signature block
152 as that for path signatures (see Section 3.1).
154 3. Mechanisms for Detection and Mitigation of Route Leaks
156 Referring to the enumeration of route leaks discussed in
157 [I-D.ietf-grow-route-leak-problem-definition], Table 1 summarizes the
158 route-leak detection capability offered by OV and BGPSEC for
159 different types of route leaks. (Note: Prefix filtering is not
160 considered here in this table. Please see Section 4.)
162 A detailed explanation of the contents of Table 1 is as follows. It
163 is readily observed that route leaks of Types 1, 5, 6, and 7 are not
164 detected by OV or even by BGPSEC. Type 2 route leak involves
165 changing a prefix to a subprefix (i.e. more specific); such a
166 modified update will fail BGPSEC checks. Clearly, Type 3 route leak
167 involves mis-origination or hijacking, and hence can be detected by
168 OV. In the case of Type 3 route leak, there would be no existing
169 ROAs to validate a re-originated prefix or subprefix, but instead a
170 covering ROA would normally exist with the legitimate AS, and hence
171 the update will be considered Invalid by OV.
173 +---------------------------------+---------------------------------+
174 | Type of Route Leak | Detection Coverage and Comments |
175 +---------------------------------+---------------------------------+
176 | Type 1: U-Turn with Full Prefix | Neither OV nor BGPSEC (in its |
177 | | current form) detects Type 1. |
178 | ------------------------------- | ------------------------------- |
179 | Type 2: U-Turn with More | In OV, the ROA maxLength may |
180 | Specific Prefix | offer detection of Type 2 in |
181 | | some cases; BGPSEC (in its |
182 | | current form) always detects |
183 | | Type 2. |
184 | ------------------------------- | ------------------------------- |
185 | Type 3: Prefix Mis-Origination | OV by itself detects Type 3; |
186 | with Data Path to Legitimate | BGPSEC does not detect Type 3. |
187 | Origin | |
188 | ------------------------------- | ------------------------------- |
189 | Type 4: Leak of Internal | For internal prefixes never |
190 | Prefixes and Accidental | meant to be seen (i.e. routed) |
191 | Deaggregation | on the Internet, OV helps |
192 | | detect their leak; they might |
193 | | either have no covering ROA or |
194 | | have an AS0-ROA to always |
195 | | filter them. In the case of |
196 | | accidental deaggregation, OV |
197 | | may offer some detection due to |
198 | | ROA maxLength. BGPSEC does not |
199 | | catch Type 4. |
200 | ------------------------------- | ------------------------------- |
201 | Type 5: Lateral ISP-ISP-ISP | Neither OV nor BGPSEC (in its |
202 | Leak | current form) detects Type 5. |
203 | ------------------------------- | ------------------------------- |
204 | Type 6: Leak of Provider | Neither OV nor BGPSEC (in its |
205 | Prefixes to Peer | current form) detects Type 6. |
206 | ------------------------------- | ------------------------------- |
207 | Type 7: Leak of Peer Prefixes | Neither OV nor BGPSEC (in its |
208 | to Provider | current form) detects Type 7. |
209 +---------------------------------+---------------------------------+
211 Table 1: Examination of Route-Leak Detection Capability of Origin
212 Validation and Current BGPSEC Path Validation
214 In the case of Type 4 leaks involving internal prefixes that are not
215 meant to be routed in the Internet, they are likely to be detected by
216 OV. That is because such prefixes might either have no covering ROA
217 or have an AS0-ROA to always filter them. In the case of Type 4
218 leaks that are due to accidental deaggregation, they may be detected
219 due to violation of ROA maxLength. BGPSEC does not catch Type 4.
220 However, route leaks of Type 4 are least problematic due to the
221 following reasons. In the case of accidental deaggregation, the
222 offending AS is itself the legitimate destination of the leaked more-
223 specific prefixes. Hence, in most cases of this type, the data
224 traffic is neither misrouted not denied service. Also, leaked
225 announcements of Type 4 are short-lived and typically withdrawn
226 quickly following the announcements. Further, the MaxPrefix limit
227 may kick-in in some receiving routers and that helps limit the
228 propagation of sometimes large number of leaked routes of Type 4.
230 Realistically, BGPSEC may take a much longer time being deployed than
231 OV. Hence solution proposals for route leaks should consider both
232 scenarios: (A) OV only (without BGPSEC) and (B) OV plus BGPSEC.
233 Assuming an initial scenario A, and based on the above discussion and
234 Table 1, it is evident that in our proposed solution method, we need
235 to focus primarily on route leaks of Types 1, 2, 5, 6, and 7. In
236 Section 3.1 and Section 3.2, we describe a simple addition to BGP
237 that facilitates detection of route leaks of Types 1, 2, 5, 6, and 7.
238 The simple addition involves a Route Leak Protection (RLP) field,
239 which is carried in an optional transitive path attribute in BGP.
240 When BGPSEC is deployed, the RLP field will be accommodated in the
241 existing Flags field (see [I-D.ietf-sidr-bgpsec-protocol]) which is
242 cryptographically protected under path signatures.
244 3.1. Route Leak Protection (RLP) Field Encoding by Sending Router
246 The key principle is that, in the event of a route leak, a receiving
247 router in a provider AS (e.g. referring to Figure 1, ISP2 (AS2)
248 router) should be able to detect from the prefix-update that its
249 customer AS (e.g. AS3 in Figure 1) SHOULD NOT have forwarded the
250 update (towards the provider AS). This means that at least one of
251 the ASes in the AS path of the update has indicated that it sent the
252 update to its customer or peer AS, but forbade any subsequent 'Up'
253 forwarding (i.e. from a customer AS to its provider AS). For this
254 purpose, a Route Leak Protection (RLP) field to be set by a sending
255 router is proposed to be used for each AS hop.
257 /\ /\
258 \ route-leak(P)/
259 \ propagated /
260 \ /
261 +------------+ peer +------------+
262 ______| ISP1 (AS1) |----------->| ISP2 (AS2)|---------->
263 / ------------+ prefix(P) +------------+ route-leak(P)
264 | prefix | \ update /\ \ propagated
265 \ (P) / \ / \
266 ------- prefix(P) \ / \
267 update \ / \
268 \ /route-leak(P) \/
269 \/ /
270 +---------------+
271 | customer(AS3) |
272 +---------------+
274 Figure 1: Illustration of the basic notion of a route leak.
276 For the purpose of route leak detection and mitigation proposed in
277 this document, the RLP field value SHOULD be set to one of two values
278 as follows:
280 o 00: This is the default value (i.e. "nothing specified"),
282 o 01: This is the 'Do not Propagate Up' indication; sender
283 indicating that the prefix-update SHOULD NOT be forwarded 'Up'
284 towards a provider AS.
286 There are two different scenarios when a sending AS SHOULD set the
287 '01' indication in a prefix-update: (1) when sending the prefix-
288 update to a customer AS, and (2) to let a peer AS know not to forward
289 the prefix-update 'Up' towards a provide AS. In essence, in both
290 scenarios, the intent of '01' indication is that any receiving AS
291 along the subsequent AS path SHOULD NOT forward the prefix-update
292 'Up' towards its (receiving AS's) provider AS.
294 One may argue for additional RLP indications: for example, '10' to
295 specify 'Propagate to Customers Only', and possibly '11' to signal
296 'Do Not Propagate' (i.e. NO_EXPORT). But in the interest of keeping
297 the methodology simple, the choice of two RLP field values as defined
298 above (00 - default, and 01 - 'Do not Propagate Up') is all that is
299 needed. This two-state specification in the RLP field can be shown
300 to work for detection and mitigation of route leaks of Types 1, 2, 5,
301 6, and 7, which are the focus here (see Section 3.2 and Section 3.3).
303 The proposed RLP encoding SHOULD be carried in BGP-4 [RFC4271]
304 updates in an optional transitive path attribute. In BGPSEC enabled
305 routers, the RLP encoding SHOULD be accommodated in the existing
306 Flags field in BGPSEC updates. The Flags field is part of the
307 Secure_Path Segment in BPGSEC updates
308 [I-D.ietf-sidr-bgpsec-protocol]. It is one octet long, and one Flags
309 field is available for each AS hop, and currently only the first bit
310 is used in BGPSEC. So there are 7 bits that are currently unused in
311 the Flags field. Two (or more if needed) of these bits can be
312 designated for the RLP field. Since the BGPSEC protocol
313 specification requires a sending AS to include the Flags field in the
314 data that are signed over, the RLP field for each hop (assuming it
315 would be part of the Flags field) will be protected under the sending
316 AS's signature.
318 3.2. Recommended Actions at a Receiving Router for Detection of Route
319 Leaks
321 The recommended receiver actions differ slightly depending on whether
322 the update is received from a customer or a peer. When detecting
323 route leaks of Type 1, 2, and 7, the receiving router is dealing with
324 a customer as the sender. When detecting route leaks of Type 5 and
325 6, the receiving router is dealing with a peer as the sender.
327 3.2.1. Recommended Actions at a Receiving Router when the Sender is a
328 Customer
330 We provide here an example set of receiver actions that work to
331 detect and mitigate route leaks of Types 1, 2, and 7. This example
332 algorithm serves as a proof of concept. However, other receiver
333 algorithms or procedures can be designed (based on the same sender
334 specification as in Section 3.1) and may perform with greater
335 efficacy, and are by no means excluded.
337 A recommended receiver algorithm for detecting a route leak is as
338 follows:
340 A receiving router SHOULD mark an update as a Route-Leak if ALL of
341 the following conditions hold true:
343 1. The update is received from a customer AS.
345 2. It is Valid in accordance with the Origin Validation (OV) and
346 BGPSEC protocols. (Note: BGPSEC validation is not applicable if
347 update is not signed).
349 3. The update has the RLP field set to '01' (i.e. 'Do not Propagate
350 Up') indication for one or more hops (excluding the most recent)
351 in the AS path.
353 The reason for stating "excluding the most recent" in the above
354 algorithm is as follows. The provider AS already knows that the most
355 recent hop in the update is from its customer AS to itself, and it
356 does not need to rely on the RLP field value set by the customer for
357 detection of route leaks.
359 A receiving router expects the RLP field value for any hop in the AS
360 path to be either 00 or 01. However, if a different value (say, 10
361 or 11) is found in the RLP field, then an error condition will get
362 flagged, and any further action is TBD.
364 3.2.2. Recommended Actions at a Receiving Router when the Sender is a
365 Peer
367 The sender and receiver actions described in Section 3.1 and
368 Section 3.2.1 clearly help detect and mitigate route leaks of Types
369 1, 2, and 7. With a slightly modified interpretation of the RLP
370 encoding on the receiver side, they can be extended to detect lateral
371 ISP-ISP-ISP route leaks (Type 5) as well as leaks of provider
372 prefixes to peer (Type 6). (Note: RLP encoding procedure by sending
373 routers remains the same as described in Section 3.1.)
375 A recommended receiver algorithm for an ISP to detect a route leak of
376 either Type 5 or Type 6 is as follows:
378 A receiving BGPSEC router SHOULD mark an update as a Route-Leak if
379 ALL of the following conditions hold true:
381 1. The update is received from a lateral ISP peer.
383 2. It is Valid in accordance with the Origin Validation (OV) and
384 BGPSEC protocols. (Note: BGPSEC validation is not applicable if
385 update is not signed).
387 3. The update has the RLP field set to '01' indication for one or
388 more hops (excluding the most recent) in the AS path.
390 In the above algorithm, the receiving AS interprets the '01'
391 indication slightly strongly (i.e. stronger than in Section 3.2.1) to
392 mean "the update SHOULD NOT have been propagated laterally to a peer
393 ISP like me either". The rationale here is based on the fact that
394 settlement-free ISP peers accept only customer prefix-routes from
395 each other. The receiving AS applies the logic that if a preceding
396 AS (excluding the most recent) set '01' indication, it means that the
397 update was sent to a peer or a customer by the (preceding) AS, and
398 the update should not be traversing a lateral peer-to-peer link
399 subsequently.
401 3.3. Possible Actions at a Receiving Router for Mitigation
403 After applying the above detection algorithm, a receiving router may
404 use any policy-based algorithm of its own choosing to mitigate any
405 detected route leaks. An example receiver algorithm for mitigating a
406 route leak is as follows:
408 o If an update from a customer AS is marked as a Route-Leak, then
409 the receiving router SHOULD prefer a Valid signed update from a
410 peer or an upstream provider over the customer's update.
412 A basic principle here is that the presence of '01' value in the RLP
413 field corresponding to one or more AS hops in the AS path of an
414 update coming from a customer AS informs a receiving router in a
415 provider AS that a route leak is likely occurring. The provider AS
416 then overrides the "prefer customer route" policy, and instead
417 prefers a route learned from a peer or another upstream provider over
418 the customer's route.
420 4. Stopgap Solution when Only Origin Validation is Deployed
422 During a phase when BGPSEC path validation has not yet been deployed
423 but only origin validation has been deployed, it would be good have a
424 stopgap solution for route leaks. The stopgap solution can be in the
425 form of construction of a prefix filter list from ROAs. A suggested
426 procedure for constructing such a list comprises of the following
427 steps:
429 o ISP makes a list of all the ASes (Cust_AS_List) that are in its
430 customer cone (ISP's own AS is also included in the list). (Some
431 of the ASes in Cust_AS_List may be multi-homed to another ISP and
432 that is OK.)
434 o ISP downloads from the RPKI repositories a complete list
435 (Cust_ROA_List) of valid ROAs that contain any of the ASes in
436 Cust_AS_List.
438 o ISP creates a list of all the prefixes (Cust_Prfx_List) that are
439 contained in any of the ROAs in Cust_ROA_List.
441 o Cust_Prfx_List is the allowed list of prefixes that is permitted
442 by the ISP's AS, and will be forwarded by the ISP to upstream
443 ISPs, customers, and peers.
445 o Any prefix not in Cust_Prfx_List but announced by any of the ISP's
446 customers is marked as a potential route leak. Then the ISP's
447 router SHOULD prefer a Valid (i.e. valid according to origin
448 validation) and 'not marked' update from a peer or an upstream
449 provider over the customer's marked update for that prefix.
451 Special considerations with regard to the above procedure may be
452 needed for DDoS mitigation service providers. They typically
453 originate or announce a DDoS victim's prefix to their own ISP on a
454 short notice during a DDoS emergency. Some provisions would need to
455 be made for such cases, and they can be determined with the help of
456 inputs from DDoS mitigation service providers.
458 For developing a list of all the ASes (Cust_AS_List) that are in the
459 customer cone of an ISP, the AS path based Outbound Route Filter
460 (ORF) technique [draft-ietf-idr-aspath-orf] can be helpful (see
461 discussion in Section 5.2).
463 5. Design Rationale and Discussion
465 In this section, we will try to provide design justifications for the
466 methodology specified in Section 3, and also answer some anticipated
467 questions.
469 5.1. Is route-leak solution without BGPSEC a serious attack vector?
471 It has been asked if a route-leak solution without BGPSEC, i.e. when
472 RLP bits are not protected, can turn into a serious new attack
473 vector. That answer seems to be: not really! Even the NLRI and
474 AS_PATH in BGP updates are attack vectors, and RPKI/OV/BGPSEC seek to
475 fix that. Consider the following. Say, if 99% of route leaks are
476 accidental and 1% are malicious, and if route-leak solution without
477 BGPSEC eliminates the 99%, then perhaps it is worth it (step in the
478 right direction). When BGPSEC comes into deployment, the route leak
479 protection (RLP) bits can be mapped into BGPSEC (using the Flags
480 field) and then necessary security will be in place as well (within
481 each BGPSEC island as and when they emerge).
483 Further, let us consider the worst-case damage that can be caused by
484 maliciously manipulating the RLP bits in an implementation without
485 BGPSEC. An AS that wants to intentionally leak a route would alter
486 the RLP encodings for the preceding hops from '01' (i.e. 'Do not
487 Propagate Up') to '00' (default) wherever applicable. It is true
488 that in that case a receiving router would not be able to detect the
489 leak for the specific prefix-route by the RLP mechanism described
490 here. However, the receiving router may still detect and mitigate it
491 in some cases by applying other means such as prefix filters
492 [RFC7454] and AS path filters [draft-ietf-idr-aspath-orf]. If some
493 malicious leaks go undetected (for RLP without BGPSEC) that is
494 possibly a small price to pay for the ability to detect the bulk of
495 route leaks that are accidental.
497 5.2. Comparison with other methods, routing security BCP
499 It is reasonable to ask if techniques considered in BCPs such
500 as[RFC7454] (BGP Operations and Security) and [NIST-800-54] may be
501 adequate to address route leaks. The prefix filtering
502 recommendations in the BCPs may be complementary but not adequate.
503 The difficulty is in ISPs' ability to construct prefix filters that
504 represent their customer cones (CC) accurately, especially when there
505 are many levels in the hierarchy within the CC. In the RLP-encoding
506 based solution described here, AS operators signal for each prefix-
507 route propagated, if it SHOULD NOT be subsequently propagated to a
508 provider/peer.
510 AS path based Outbound Route Filter (ORF) described in
511 [draft-ietf-idr-aspath-orf] is also an interesting complementary
512 technique. It can be used as an automated collaborative messaging
513 system (implemented in BGP) for ISPs to try to develop a complete
514 view of the ASes and AS paths in their CCs. Once an ISP has that
515 view, then AS path filters can be possibly used to detect route
516 leaks. One limitation of this technique is that it cannot duly take
517 into account the fact that prefixes with different business models
518 are often sent over the same link between ASes. Also, the success of
519 it depends on ASes at all levels of the hierarchy in a CC participate
520 and provide accurate information (in the ORF messages) about the AS
521 paths they expect to have in their BGP updates to their provider
522 ISP(s).
524 6. Summary
526 It should be emphasized once again that the proposed route-leak
527 detection method using the RLP encoding is not intended to cover all
528 forms of route leaks. However, we feel that the solution covers
529 several important types of route leaks, especially considering some
530 significant route-leak attacks or occurrences that have been
531 frequently observed in recent years. The solution can be implemented
532 in BGP without necessarily tying it to BGPSEC. The proposed solution
533 without BGPSEC can detect and mitigate accidental route leaks, and
534 the same with BGPSEC can detect and mitigate malicious route leaks as
535 well. Carrying the proposed RLP encoding in an optional transitive
536 path attribute in BGP is proposed, but in order to prevent abuse, the
537 RLP encoding would require cryptographic protection. Incorporating
538 the RLP encoding in the BGPSEC Flags field is one way of implementing
539 it securely using an already existing protection mechanism provided
540 in BGPSEC path signatures.
542 7. Security Considerations
544 The proposed Route Leak Protection (RLP) field requires cryptographic
545 protection in order to prevent malicious route leaks. Since it is
546 proposed that the RLP field be included in the Flags field in the
547 Secure_Path Segment in BPGSEC updates, the cryptographic security
548 mechanisms in BGPSEC are expected to also apply to the RLP field.
549 The reader is therefore directed to the security considerations
550 provided in [I-D.ietf-sidr-bgpsec-protocol].
552 8. IANA Considerations
554 No updates to the registries are suggested by this document.
556 9. Acknowledgements
558 The authors wish to thank Danny McPherson and Eric Osterweil for
559 discussions related to this work. Also, thanks are due to Jared
560 Mauch, Jeff Haas, Warren Kumari, Amogh Dhamdhere, Jakob Heitz, Geoff
561 Huston, Randy Bush, Ruediger Volk, Andrei Robachevsky, Sue Hares,
562 Keyur Patel, Wes George, Chris Morrow, and Sandy Murphy for comments,
563 suggestions, and critique. The authors are also thankful to Padma
564 Krishnaswamy, Oliver Borchert, and Okhee Kim for their comments and
565 review.
567 10. References
569 10.1. Normative References
571 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
572 Protocol 4 (BGP-4)", RFC 4271, January 2006.
574 10.2. Informative References
576 [Cowie2010]
577 Cowie, J., "China's 18 Minute Mystery", Dyn
578 Research/Renesys Blog, November 2010,
579 .
582 [Cowie2013]
583 Cowie, J., "The New Threat: Targeted Internet Traffic
584 Misdirection", Dyn Research/Renesys Blog, November 2013,
585 .
588 [draft-dickson-sidr-route-leak-solns]
589 Dickson, B., "Route Leaks -- Proposed Solutions", IETF
590 Internet Draft (expired), March 2012,
591 .
594 [draft-ietf-idr-aspath-orf]
595 Patel, K. and S. Hares, "AS path Based Outbound Route
596 Filter for BGP-4", IETF Internet Draft (expired), August
597 2007, .
600 [draft-kunzinger-idrp-ISO10747-01]
601 Kunzinger, C., "Inter-Domain Routing Protocol (IDRP)",
602 IETF Internet Draft (expired), November 1994,
603 .
606 [Gao] Gao, L. and J. Rexford, "Stable Internet routing without
607 global coordination", IEEE/ACM Transactions on
608 Networking, December 2001,
609 .
612 [Gill] Gill, P., Schapira, M., and S. Goldberg, "A Survey of
613 Interdomain Routing Policies", ACM SIGCOMM Computer
614 Communication Review, January 2014,
615 .
617 [Giotsas] Giotsas, V. and S. Zhou, "Valley-free violation in
618 Internet routing - Analysis based on BGP Community data",
619 IEEE ICC 2012, June 2012,
620 .
623 [Hiran] Hiran, R., Carlsson, N., and P. Gill, "Characterizing
624 Large-scale Routing Anomalies: A Case Study of the China
625 Telecom Incident", PAM 2013, March 2013,
626 .
629 [Huston2012]
630 Huston, G., "Leaking Routes", March 2012,
631 .
633 [Huston2014]
634 Huston, G., "What's so special about 512?", September
635 2014, .
637 [I-D.ietf-grow-route-leak-problem-definition]
638 Sriram, K., Montgomery, D., McPherson, D., Osterweil, E.,
639 and B. Dickson, "Problem Definition and Classification of
640 BGP Route Leaks", draft-ietf-grow-route-leak-problem-
641 definition-02 (work in progress), July 2015.
643 [I-D.ietf-sidr-bgpsec-protocol]
644 Lepinski, M., "BGPsec Protocol Specification", draft-ietf-
645 sidr-bgpsec-protocol-13 (work in progress), July 2015.
647 [Kapela-Pilosov]
648 Pilosov, A. and T. Kapela, "Stealing the Internet: An
649 Internet-Scale Man in the Middle Attack", DEFCON-16 Las
650 Vegas, NV, USA, August 2008,
651 .
654 [Khare] Khare, V., Ju, Q., and B. Zhang, "Concurrent Prefix
655 Hijacks: Occurrence and Impacts", IMC 2012, Boston, MA,
656 November 2012, .
659 [Labovitz]
660 Labovitz, C., "Additional Discussion of the April China
661 BGP Hijack Incident", Arbor Networks IT Security Blog,
662 November 2010,
663 .
666 [LRL] Khare, V., Ju, Q., and B. Zhang, "Large Route Leaks",
667 Project web page, 2012,
668 .
671 [Luckie] Luckie, M., Huffaker, B., Dhamdhere, A., Giotsas, V., and
672 kc. claffy, "AS Relationships, Customer Cones, and
673 Validation", IMC 2013, October 2013,
674 .
676 [Madory] Madory, D., "Why Far-Flung Parts of the Internet Broke
677 Today", Dyn Research/Renesys Blog, September 2014,
678 .
681 [Mauch] Mauch, J., "BGP Routing Leak Detection System", Project
682 web page, 2014,
683 .
685 [Mauch-nanog]
686 Mauch, J., "Detecting Routing Leaks by Counting",
687 NANOG-41 Albuquerque, NM, USA, October 2007,
688 .
691 [NIST-800-54]
692 Kuhn, D., Sriram, K., and D. Montgomery, "Border Gateway
693 Protocol Security", NIST Special Publication 800-54, July
694 2007, .
697 [Paseka] Paseka, T., "Why Google Went Offline Today and a Bit about
698 How the Internet Works", CloudFare Blog, November 2012,
699 .
702 [proceedings-sixth-ietf]
703 Gross, P., "Proceedings of the April 22-24, 1987 Internet
704 Engineering Task Force", April 1987,
705 .
707 [RFC1105-obsolete]
708 Lougheed, K. and Y. Rekhter, "A Border Gateway Protocol
709 (BGP)", IETF RFC (obsolete), June 1989,
710 .
712 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
713 Austein, "BGP Prefix Origin Validation", RFC 6811,
714 DOI 10.17487/RFC6811, January 2013,
715 .
717 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations
718 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,
719 February 2015, .
721 [Toonk] Toonk, A., "What Caused Today's Internet Hiccup", August
722 2014, .
725 [Wijchers]
726 Wijchers, B. and B. Overeinder, "Quantitative Analysis of
727 BGP Route Leaks", RIPE-69, November 2014,
728 .
731 [Zmijewski]
732 Zmijewski, E., "Indonesia Hijacks the World", Dyn
733 Research/Renesys Blog, April 2014,
734 .
737 Authors' Addresses
739 Kotikalapudi Sriram
740 US NIST
742 Email: ksriram@nist.gov
744 Doug Montgomery
745 US NIST
747 Email: dougm@nist.gov
749 Brian Dickson
750 Twitter, Inc.
752 Email: bdickson@twitter.com