idnits 2.17.1 draft-jdurand-bgp-security-02.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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 5.1.1. Prefixes that MUST not be routed by definition . . . . 5 5.2. Prefix filtering recommendations in full routing 5.3. Prefix filtering recommendations for leaf networks . . . . 14 11.1. Diffs between draft-jdurand-bgp-security-01 and 11.2. Diffs between draft-jdurand-bgp-security-02 and == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 5.1.1. Prefixes that MUST not be routed by definition 5.1.1.1. IPv4 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: IPv6 registry [26] maintains the list of IPv6 special purpose prefixes. With the exception of the 6to4 2002::/16 prefix in that registry, all other prefixes that are mentioned and more specifics MUST not cross network boundaries and therefore MUST be filtered. The 6to4 prefix 2002::/16 is an exception because the prefix itself can be advertised, but more specifics MUST be filtered according to [4], section 5.2.3. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: At the time of the writing of this document, the list of IPv6 prefixes that MUST not cross network boundaries can be simplified as IANA allocates at the time being prefixes to RIR's only in 2000::/3 prefix [25]. All other prefixes (ULA's, link-local, multicast... are outside of that prefix) and therefore the simplified list becomes: == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o Added 3FFE::/16 prefix forgotten initially in the simplified list of prefixes that MUST not be routed by definition in former section 4.1.1.2 -- The document date (September 21, 2012) is 4234 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 879, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 885, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 888, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 894, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 906, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 909, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 920, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 923, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 929, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 945, but no explicit reference was found in the text == Unused Reference: '29' is defined on line 964, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2385 (ref. '2') (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 2629 (ref. '3') (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 2234 (ref. '11') (Obsoleted by RFC 4234) -- Obsolete informational reference (is this intentional?): RFC 4234 (ref. '15') (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 5156 (ref. '16') (Obsoleted by RFC 6890) -- Obsolete informational reference (is this intentional?): RFC 5735 (ref. '17') (Obsoleted by RFC 6890) Summary: 2 errors (**), 0 flaws (~~), 18 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Durand 3 Internet-Draft CISCO Systems, Inc. 4 Intended status: BCP I. Pepelnjak 5 Expires: March 25, 2013 NIL 6 G. Doering 7 SpaceNet 8 September 21, 2012 10 BGP operations and security 11 draft-jdurand-bgp-security-02.txt 13 Abstract 15 BGP (Border Gateway Protocol) is the protocol almost exclusively used 16 in the Internet to exchange routing information between network 17 domains. Due to this central nature, it's important to understand 18 the security measures that can and should be deployed to prevent 19 accidental or intentional routing disturbances. 21 This document describes measures to protect the BGP sessions itself 22 (like TTL, MD5, control plane filtering) and to better control the 23 flow of routing information, using prefix filtering and 24 automatization of prefix filters, max-prefix filtering, AS path 25 filtering, route flap dampening and BGP community scrubbing. 27 Foreword 29 A placeholder to list general observations about this document. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [1]. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on March 25, 2013. 54 Copyright Notice 56 Copyright (c) 2012 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Protection of BGP router . . . . . . . . . . . . . . . . . . . 4 74 4. Protection of BGP sessions . . . . . . . . . . . . . . . . . . 4 75 4.1. Protection of TCP sessions used by BGP . . . . . . . . . . 4 76 4.2. BGP TTL security . . . . . . . . . . . . . . . . . . . . . 5 77 5. Prefix filtering . . . . . . . . . . . . . . . . . . . . . . . 5 78 5.1. Definition of prefix filters . . . . . . . . . . . . . . . 5 79 5.1.1. Prefixes that MUST not be routed by definition . . . . 5 80 5.1.2. Prefixes not allocated . . . . . . . . . . . . . . . . 6 81 5.1.3. Prefixes too specific . . . . . . . . . . . . . . . . 9 82 5.1.4. Filtering prefixes belonging to local AS . . . . . . . 9 83 5.1.5. Internet exchange point (IXP) LAN prefixes . . . . . . 10 84 5.1.6. Default route . . . . . . . . . . . . . . . . . . . . 11 85 5.2. Prefix filtering recommendations in full routing 86 networks . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 5.2.1. Filters with internet peers . . . . . . . . . . . . . 12 88 5.2.2. Filters with customers . . . . . . . . . . . . . . . . 13 89 5.2.3. Filters with upstream providers . . . . . . . . . . . 14 90 5.3. Prefix filtering recommendations for leaf networks . . . . 14 91 5.3.1. Inbound filtering . . . . . . . . . . . . . . . . . . 14 92 5.3.2. Outbound filtering . . . . . . . . . . . . . . . . . . 15 93 6. BGP route flap dampening . . . . . . . . . . . . . . . . . . . 15 94 7. Maximum prefixes on a peering . . . . . . . . . . . . . . . . 15 95 8. AS-path filtering . . . . . . . . . . . . . . . . . . . . . . 16 96 9. Next-Hop Filtering . . . . . . . . . . . . . . . . . . . . . . 17 97 10. BGP community scrubbing . . . . . . . . . . . . . . . . . . . 17 98 11. Change logs . . . . . . . . . . . . . . . . . . . . . . . . . 18 99 11.1. Diffs between draft-jdurand-bgp-security-01 and 100 draft-jdurand-bgp-security-00 . . . . . . . . . . . . . . 18 101 11.2. Diffs between draft-jdurand-bgp-security-02 and 102 draft-jdurand-bgp-security-01 . . . . . . . . . . . . . . 19 103 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 104 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 105 14. Security Considerations . . . . . . . . . . . . . . . . . . . 20 106 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 107 15.1. Normative References . . . . . . . . . . . . . . . . . . . 20 108 15.2. Informative References . . . . . . . . . . . . . . . . . . 21 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 111 1. Introduction 113 BGP [7] is the protocol used in the internet to exchange routing 114 information between network domains. This protocol does not directly 115 include mechanisms that control that routes exchanged conform to the 116 various rules defined by the Internet community. This document 117 intends to summarize most common existing rules and help network 118 administrators applying simply coherent BGP policies. 120 2. Definitions 122 o BGP peering: any TCP BGP connection on the Internet. 124 3. Protection of BGP router 126 The BGP router needs to be protected from stray packets. This 127 protection should be achieved by an access-list (ACL) which would 128 discard all packets directed to TCP port 179 on the local device and 129 sourced from an address not known to be a BGP neighbor. If 130 supported, an ACL specific to the control-plane of the router should 131 be used (receive-ACL, control-plane policing, etc.), to avoid 132 filtering transit traffic if not needed. If the hardware can not do 133 that, interface ACLs can be used to block packets to the local 134 router. 136 Some routers automatically program such an ACL upon BGP 137 configuration. On other devices this ACL should be configured and 138 maintained manually or using scripts. 140 The filtering of packets destined to the local router is a wider 141 topic than "just for BGP" (if you bring down a router by overloading 142 one of the other protocols from remote, BGP is harmed as well). For 143 a more detailed recommendation, see RFC6192 [19]. 145 4. Protection of BGP sessions 147 4.1. Protection of TCP sessions used by BGP 149 Attacks on TCP sessions used by BGP (ex: sending spoofed TCP 150 RST packets) could bring down the TCP session. Following a 151 successful ARP spoofing attack (or other similar Man-in-the-Middle 152 attack), the attacker might even be able to inject packets into 153 the TCP stream (routing attacks). 155 TCP sessions used by BGP can be secured with a variety of mechanisms. 157 MD5 protection of TCP session header [2] is the most common one, but 158 one could also use IPsec or TCP Authentication Option (TCP-AO, [10]). 160 The drawback of TCP session protection is additional configuration 161 and management overhead for authentication information (ex: MD5 162 password) maintenance. Protection of TCP sessions used by BGP is 163 thus recommended when peerings are established over shared networks 164 where spoofing can be done (like internet exchanges, IXPs). 166 You should block spoofed packets (packets with source IP address 167 belonging to your IP address space) at all edges of your network, 168 making the protection of TCP sessions used by BGP unnecessary on iBGP 169 session or EBGP sessions run over point-to-point links. 171 4.2. BGP TTL security 173 BGP sessions can be made harder to spoof with the TTL security [9]. 174 Instead of sending TCP packets with TTL value = 1, the routers send 175 the TCP packets with TTL value = 255 and the receiver checks that the 176 TTL value equals 255. Since it's impossible to send an IP packet 177 with TTL = 255 to a non-directly-connected IP host, BGP TTL security 178 effectively prevents all spoofing attacks coming from third parties 179 not directly connected to the same subnet as the BGP-speaking 180 routers. 182 Note: Like MD5 protection, TTL security has to be configured on both 183 ends of a BGP session. 185 5. Prefix filtering 187 The main aspect of securing BGP resides in controlling the prefixes 188 that are received/advertised on the BGP peerings. Prefixes exchanged 189 between BGP peers are controlled with inbound and outbound filters 190 that can match on IP prefixes (prefix filters, Section 5), AS paths 191 (as-path filters, Section 8) or any other attributes of a BGP prefix 192 (for example, BGP communities, Section 10). 194 5.1. Definition of prefix filters 196 This section list the most commonly used prefix filters. Following 197 sections will clarify where these filters should be applied. 199 5.1.1. Prefixes that MUST not be routed by definition 200 5.1.1.1. IPv4 202 At the time of the writing of this document, there is no dynamic IPv4 203 registry listing special prefixes and their status on the internet. 204 On the other hand static document RFC5735 [17] clarifies "special" 205 IPv4 prefixes and their status in the Internet. Since publication of 206 that RFC another prefix has been added on the list of the special use 207 prefixes. Following prefixes MUST NOT cross network boundaries (ie. 208 ASN) and therefore MUST be filtered: 210 o Prefixes defined in RFC5735 [17] and more specifics 212 o Shared address space [31] - 100.64.0.0/10 and more specifics 214 5.1.1.2. IPv6 216 IPv6 registry [26] maintains the list of IPv6 special purpose 217 prefixes. With the exception of the 6to4 2002::/16 prefix in that 218 registry, all other prefixes that are mentioned and more specifics 219 MUST not cross network boundaries and therefore MUST be filtered. 220 The 6to4 prefix 2002::/16 is an exception because the prefix itself 221 can be advertised, but more specifics MUST be filtered according to 222 [4], section 5.2.3. 224 At the time of the writing of this document, the list of IPv6 225 prefixes that MUST not cross network boundaries can be simplified as 226 IANA allocates at the time being prefixes to RIR's only in 2000::/3 227 prefix [25]. All other prefixes (ULA's, link-local, multicast... are 228 outside of that prefix) and therefore the simplified list becomes: 230 o 2001:DB8::/32 and more specifics - documentation [13] 232 o Prefixes more specifics than 2002::/16 - 6to4 [4] 234 o 3FFE::/16 and more specifics - was initially used for the 6Bone 235 (worldwide IPv6 test network) and returned to IANA 237 o All prefixes that are outside 2000::/3 prefix 239 5.1.2. Prefixes not allocated 241 IANA allocates prefixes to RIRs which in turn allocate prefixes to 242 LIRs. It is wise not to accept in the routing table prefixes that 243 are not allocated. This could mean allocation made by IANA and/or 244 allocations done by RIRs. This section details the options for 245 building list of allocated prefixes at every level. It is important 246 to understand that filtering prefixes not allocated requires constant 247 updates as IANA and RIRs keep allocating prefixes. Therefore 248 automation of such prefix filters is key for the success of this 249 approach. One should probably not consider solutions described in 250 this section if it is not capable of maintaining updated prefix 251 filters: damage would probably be worse than the intended security 252 policy. 254 5.1.2.1. IANA allocated prefixes filters 256 IANA has allocated all the IPv4 available space. Therefore there is 257 no reason why one would keep checking prefixes are in the IANA 258 allocated address space [24]. No specific filter need to be put in 259 place by administrators who want to make sure that IPv4 prefixes they 260 receive have been allocated by IANA. 262 For IPv6, given the size of the address space, it can be seen as wise 263 accepting only prefixes derived from those allocated by IANA. 264 Administrators can dynamically build this list from the IANA 265 allocated IPv6 space [27]. As IANA keeps allocating prefixes to 266 RIRs, the aforementioned list should be checked regularly against 267 changes and if they occur, prefix filter should be computed and 268 pushed on network devices. As there is delay between the time a RIR 269 receives a new prefix and the moment it starts allocating portions of 270 it to its LIRs, there is no need doing this step quickly and 271 frequently. At least process in place should make sure there is no 272 more than one month between the time the IANA IPv6 allocated prefix 273 list changes and the moment all IPv6 prefix filters have been 274 updated. 276 If process in place (manual or automatic) cannot guarantee that the 277 list is updated regularly then it's better not to configure any 278 filter based on allocated networks. The IPv4 experience has shown 279 that many network operators implemented filters for prefixes not 280 allocated by IANA but did not update them on a regular basis. This 281 created problems for latest allocations and required a extra work for 282 RIR's that had to "de-boggonize" the newly allocated prefixes. 284 5.1.2.2. RIR allocated prefixes filters 286 A more precise check can be performed as one would like to make sure 287 that prefixes they receive are being originated by the autonomous 288 system which actually own the prefix. It has been observed in the 289 past that one could easily advertise someone else's prefix (or more 290 specific prefixes) and create black holes or security threats. To 291 overcome that risk, administrators would need to make sure BGP 292 advertisements correspond to information located in the existing 293 registries. At this stage 2 options can be considered (short and 294 long term options). They are described in the following subsections. 296 5.1.2.3. Prefix filters creation from Internet Routing Registries (IRR) 298 An Internet Routing Registry (IRR) is a database containing internet 299 routing information, described using Routing Policy Specification 300 Language objects [14]. Network engineers are given privileges to 301 describe routing policies of their own networks in the IRR and 302 information is published, usually publicly. Most of Regional 303 Internet Registries do also operate an IRR and can control that 304 registered routes conform to allocations made. 306 It is possible to use IRR information in order to build for a given 307 BGP neighbor a list of prefixes, with corresponding originating 308 autonomous system. This can be done relatively easily using scripts 309 and existing tools capable of retrieving this information in the 310 registries. This approach is exactly the same for both IPv4 and 311 IPv6. 313 The macro-algorithm for the script is described as follows. For the 314 peer that is considered, the distant network administrator has 315 provided the autonomous system and may be able to provide an AS-SET 316 object (aka AS-MACRO). An AS-SET is an object which contains AS 317 numbers or other AS-SET's. An operator may create an AS-SET defining 318 all the AS numbers of its customers. A tier 1 transit provider might 319 create an AS-SET describing the AS-SET of connected operators, which 320 in turn describe the AS numbers of their customers. Using recursion, 321 it is possible to retrieve from an AS-SET the complete list of AS 322 numbers that the peer is susceptible to announce. For each of these 323 AS numbers, it is also easy to check in the corresponding IRR all 324 associated prefixes. With these 2 mechanisms a script can build for 325 a given peer the list of allowed prefixes and the AS number from 326 which they should be originated. 328 As prefixes, AS numbers and AS-SET's may not all be under the same 329 RIR authority, a difficulty resides choosing for each object the 330 appropriate IRR to poll. Some IRR have been created and are not 331 restricted to a given region or authoritative RIR. They allow RIRs 332 to publish information contained in their IRR in a common place. 333 They also make it possible for any subscriber (probably under 334 contract) to publish information too. When doing requests inside 335 such an IRR, it is possible to specify the source of information in 336 order to have the most reliable data. One could check the central 337 registry and only check that the source is one of the 5 RIRs. The 338 probably most famous registry of that kind is the RADB [28] (Routing 339 Assets Database). 341 As objects in IRR's may quickly vary over time, it is important that 342 prefix filters computed using this mechanism are refreshed regularly. 343 A daily basis could even been considered as some routing changes must 344 be done sometimes in a certain emergency and registries may be 345 updated at the very last moment. It has to be noted that this 346 approach significantly increases the complexity of the router 347 configurations as it can quickly add more than ten thousands 348 configuration lines for some important peers. 350 5.1.2.4. SIDR - Secure Inter Domain Routing 352 IETF has created a working group called SIDR (Secure Inter-Domain 353 Routing) in order to create an architecture to secure internet 354 advertisements. At the time this document is written, many document 355 has been published and a framework is proposed so that advertisements 356 can be checked against signed routing objects in RIR routing 357 registries. Implementing mechanisms proposed by this working group 358 is the solution that will solve at a longer term the BGP routing 359 security. But as it may take time objects are signed and deployments 360 are done such a solution will need to be combined at the time being 361 with other mechanisms proposed in this document. The rest of this 362 section assumes the reader understands all technologies associated 363 with SIDR. 365 Each received route on a router should be checked against the RPKI 366 data set: if a corresponding ROA is found and is valid then the 367 prefix should be accepted. It the ROA is found and is INVALID then 368 the prefix should be discarded. If an ROA is not found then the 369 prefix should be accepted but corresponding route should be given a 370 low preference. 372 5.1.3. Prefixes too specific 374 Most ISPs will not accept advertisements beyond a certain level of 375 specificity (and in return do not announce prefixes they consider as 376 too specific). That acceptable specificity is decided for each 377 peering between the 2 BGP peers. Some ISP communities have tried to 378 document acceptable specificity. This document does not make any 379 judgement on what the best approach is, it just recalls that there 380 are existing practices on the internet and recommends the reader to 381 refer to what those are. As an example RIPE community has documented 382 that IPv4 prefixes longer than /24 and IPv6 prefixes longer than /48 383 are generally not announced/accepted in the internet [21] [22]. 385 5.1.4. Filtering prefixes belonging to local AS 387 A network SHOULD filter its own prefixes on peerings with all its 388 peers (inbound direction). This prevents local traffic (from a local 389 source to a local destination) to leak over an external peering in 390 case someone else is announcing the prefix over the Internet. This 391 also protects the infrastructure which may directly suffer in case 392 backbone's prefix is suddenly preferred over the Internet. To an 393 extent, such filters can also be configured on a network for the 394 prefixes of its downstreams in order to protect them too. Such 395 filters must be defined with caution as they can break existing 396 redundancy mechanisms. For example in case an operator has a 397 multihomed customer, it should keep accepting the customer prefix 398 from its peers and upstreams. This will make it possible for the 399 customer to keep accessing its operator network (and other customers) 400 via the internet in case the BGP peering between the customer and the 401 operator is down. 403 5.1.5. Internet exchange point (IXP) LAN prefixes 405 5.1.5.1. Network security 407 When a network is present on an exchange point (IXP) and peers with 408 other IXP members over a common subnet (IXP LAN prefix), it MUST NOT 409 accept more specific prefixes for the IXP LAN prefix from any of all 410 its external BGP peers. Accepting these routes would create a black 411 hole for connectivity to the IXP LAN. 413 If the IXP LAN prefix is accepted as an "exact match", care needs to 414 be taken to avoid other routers in the network sending IXP traffic 415 towards the externally-learned IXP LAN prefix (recursive route lookup 416 pointing into the wrong direction). This can be achieved by 417 preferring IGP routes before eBGP, or by using "BGP next-hop-self" on 418 all routes learned on that IXP. 420 If the IXP LAN prefix is accepted at all, it MUST only be accepted 421 from the ASes that the IXP authorizes to announce it - which will 422 usually be automatically achieved by filtering announcements by IRR 423 DB. 425 5.1.5.2. pMTUd and loose uRPF problem 427 In order to have pMTUd working in the presence of loose uRPF, it is 428 necessary that all the networks that may source traffic that could 429 flow through the IXP (ie. IXP members and their downstreams) have a 430 route for the IXP LAN prefix. This is necessary as "packet too big" 431 ICMP messages sent by IXP members' routers may be sourced using an 432 address of the IXP LAN prefix. In the presence of loose uRPF, this 433 ICMP packet is dropped if there is no route for the IXP LAN prefix or 434 a less specific route covering IXP LAN prefix. 436 In that case, any IXP member SHOULD make sure it has a route for the 437 IXP LAN prefix or a less specific prefix on all its routers and that 438 it announces the IXP LAN prefix or less specific (up to a default 439 route) to its downstreams. The announcements done for this purpose 440 SHOULD pass IRR-generated filters described in Section 5.1.2.3 as 441 well as "prefixes too specific" filters described in Section 5.1.3. 442 The easiest way to implement this is that the IXP itself takes care 443 of the origination of its prefix and advertises it to all IXP members 444 through a BGP peering. Most likely the BGP route servers would be 445 used for this. The IXP would most likely send its entire prefix 446 which would be equal or less specific than the IXP LAN prefix. 448 5.1.5.3. Example 450 Let's take as an example an IXP in RIPE region for IPv4. It would be 451 allocated a /22 by RIPE NCC (X.Y.0.0/22 in our example) and use a /23 452 of this /22 for the IXP LAN (let say X.Y.0.0/23). This IXP LAN 453 prefix is the one used by IXP members to configure eBGP peerings. 454 The IXP could also be allocated an AS number (AS64496 in our 455 example). 457 Any IXP member MUST make sure it filters prefixes more specific than 458 X.Y.0.0/23 from all its eBGP peers. If it received X.Y.0.0/24 or 459 X.Y.1.0/24 this could seriously impact its routing. 461 The IXP SHOULD originate X.Y.0.0/22 and advertise it to its members 462 through its BGP route servers (configured with AS64496). 464 The IXP members SHOULD accept the IXP prefix only if it passes the 465 IRR generated filters (see Section 5.1.2.3) 467 IXP members SHOULD then advertise X.Y.0.0/22 prefix to their 468 downstreams. This announce would pass IRR based filters as it is 469 originated by the IXP. 471 5.1.6. Default route 473 5.1.6.1. IPv4 475 0.0.0.0/0 prefix MUST NOT be announced on the Internet but it is 476 usually exchanged on upstream/customer peerings. 478 5.1.6.2. IPv6 480 ::/0 prefix MUST NOT be announced on the Internet but it is usually 481 exchanged on upstream/customer peerings. 483 5.2. Prefix filtering recommendations in full routing networks 485 For networks that have the full internet BGP table, some policies 486 should be applied on each BGP peer for received and advertised 487 routes. It is recommended that each autonomous system configures 488 rules for advertised and received routes at all its borders as this 489 will protect the network and its peer even in case of 490 misconfiguration. The most commonly used filtering policy is 491 proposed in this section. 493 5.2.1. Filters with internet peers 495 5.2.1.1. Inbound filtering 497 There are basically 2 options, the loose one where no check will be 498 done against RIR allocations and the strict one where it will be 499 verified that announcements strictly conform to what is declared in 500 routing registries. 502 5.2.1.1.1. Inbound filtering loose option 504 In that case, the following prefixes received from a BGP peer will be 505 filtered: 507 o Prefixes not routable (Section 5.1.1) 509 o Prefixes not allocated by IANA (IPv6 only) (Section 5.1.2.1) 511 o Routes too specific (Section 5.1.3) 513 o Prefixes belonging to local AS (Section 5.1.4) 515 o Exchange points LAN prefixes (Section 5.1.5) 517 o Default route (Section 5.1.6) 519 5.2.1.1.2. Inbound filtering strict option 521 In that case, filters are applied to make sure advertisements 522 strictly conform to what is declared in routing registries 523 Section 5.1.2.2. It must be checked that in case of script failure 524 all routes are rejected. 526 In addition to this, one could apply following filters beforehand in 527 case routing registry used as source of information by the script is 528 not fully trusted: 530 o Prefixes not routable (Section 5.1.1) 532 o Routes too specific (Section 5.1.3) 534 o Prefixes belonging to local AS (Section 5.1.4) 535 o Exchange points LAN prefixes (Section 5.1.5) 537 o Default route (Section 5.1.6) 539 5.2.1.2. Outbound filtering 541 Configuration in place will make sure that only appropriate prefixes 542 are sent. These can be for example prefixes belonging to the 543 considered networks and those of its customers. This can be done 544 using BGP communities or many other solution. Whatever scenario 545 considered, it can be desirable that following filters are positioned 546 before to avoid unwanted route announcement due to bad configuration: 548 o Prefixes not routable (Section 5.1.1) 550 o Routes too specific (Section 5.1.3) 552 o Exchange points LAN prefixes (Section 5.1.5) 554 o Default route (Section 5.1.6) 556 In case it is possible to list the prefixes to be advertised, then 557 just configuring the list of allowed prefixes and denying the rest is 558 sufficient. 560 5.2.2. Filters with customers 562 5.2.2.1. Inbound filtering 564 Inbound policy with end customers is pretty straightforward: only 565 customers prefixes must be accepted, all others MUST be discarded. 566 The list of accepted prefixes can be manually specified, after having 567 verified that they are valid. This validation can be done with the 568 appropriate IP address management authorities. 570 Same rules apply in case the customer is also a network connecting 571 other customers (for example a tier 1 transit provider connecting 572 service providers). An exception can be envisaged in case it is 573 known that the customer network applies strict inbound/outbound 574 prefix filtering, and the number of prefixes announced by that 575 network is too large to list them in the router configuration. In 576 that case filters as in Section 5.2.1.1 can be applied. 578 5.2.2.2. Outbound filtering 580 Outbound policy with customers may vary according to the routes 581 customer wants to receive. In the simplest possible scenario, 582 customer wants to receive only the default route, which can be done 583 easily by applying a filter with the default route only. 585 In case the customer wants to receive the full routing (in case it is 586 multihomed or if wants to have a view on the internet table), the 587 following filters can be simply applied on the BGP peering: 589 o Prefixes not routable (Section 5.1.1) 591 o Routes too specific (Section 5.1.3) 593 o Default route (Section 5.1.6) 595 There can be a difference for the default route that can be announced 596 to the customer in addition to the full BGP table. This can be done 597 simply by removing the filter for the default route. As the default 598 route may not be present in the routing table, one may decide to 599 originate it only for peerings where it has to be advertised. 601 5.2.3. Filters with upstream providers 603 5.2.3.1. Inbound filtering 605 In case the full routing table is desired from the upstream, the 606 prefix filtering to apply is more or less the same than the one for 607 peers Section 5.2.1.1. There can be a difference for the default 608 route that can be desired from an upstream provider even if it 609 advertises the full BGP table. In case the upstream provider is 610 supposed to announce only the default route, a simple filter will be 611 applied to accept only the default prefix and nothing else. 613 5.2.3.2. Outbound filtering 615 The filters to be applied should not differ from the ones applied for 616 internet peers (Section 5.2.1.2). 618 5.3. Prefix filtering recommendations for leaf networks 620 5.3.1. Inbound filtering 622 The leaf network will position the filters corresponding to the 623 routes it is requesting from its upstream. In case a default route 624 is requested, simple inbound filter will be applied to accept only 625 that default route (Section 5.1.6). In case the leaf network is not 626 capable of listing the prefix because the amount is too large (for 627 example if it requires the full internet routing table) then it 628 should configure filters to avoid receiving bad announcements from 629 its upstream: 631 o Prefixes not routable (Section 5.1.1) 633 o Routes too specific (Section 5.1.3) 635 o Prefixes belonging to local AS (Section 5.1.4) 637 o Default route (Section 5.1.6) depending if the route is requested 638 or not 640 5.3.2. Outbound filtering 642 A leaf network will most likely have a very straightforward policy: 643 it will only announce its local routes. It can also configure the 644 following prefixes filters described in Section 5.2.1.2 to avoid 645 announcing invalid routes to its upstream provider. 647 6. BGP route flap dampening 649 BGP route flap dampening mechanism makes it possible to give 650 penalties to routes each time they change in the BGP routing table. 651 Initially this mechanism was created to protect the entire internet 652 from multiple events impacting a single network. RIPE community now 653 recommends not using BGP route flap dampening [20]. Author of this 654 document proposes to follow the proposal of the RIPE community. 656 7. Maximum prefixes on a peering 658 It is recommended to configure a limit on the number of routes to be 659 accepted from a peer. Following rules are generally recommended: 661 o From peers, it is recommended to have a limit lower than the 662 number of routes in the internet. This will shut down the BGP 663 peering if the peer suddenly advertises the full table. One can 664 also configure different limits for each peer, according to the 665 number of routes they are supposed to advertise plus some headroom 666 to permit growth. 668 o From upstreams which provide full routing, it is recommended to 669 have a limit much higher than the number of routes in the 670 internet. A limit is still useful in order to protect the network 671 (and in particular the routers' memory) if too many routes are 672 sent by the upstream. The limit should be chosen according to the 673 number of routes that can actually be handled by routers. 675 It is important to regularly review the limits that are configured as 676 the internet can quickly change over time. Some vendors propose 677 mechanisms to have 2 thresholds: while the higher number specified 678 will shutdown the peering, the first threshold will only trigger a 679 log and can be used to passively adjust limits based on observations 680 made on the network. 682 8. AS-path filtering 684 The following rules should be applied on BGP AS-paths: 686 o Do not accept anything other than customer's AS number from the 687 customer. Alternatively, only accept AS-paths with a single AS 688 number (potentially repeated several times) from your customers. 689 The latter option is easier to configure than per-customer AS-path 690 filters: the default BGP logic will make sure in that case that 691 the first AS number in the AS-path is the one of the peer. 693 o Do not accept overly long AS path prepending from the customer. 695 o Do not accept more than two distinct AS path numbers in the AS 696 path if your customer is an ISP with customers. This rule is not 697 adding anything extra in case prefix filters are built from 698 registries as described in Section 5.1.2.3. 700 o Do not advertise prefixes with non-empty AS-path if you're not 701 transit. 703 o Do not advertise prefixes with upstream AS numbers in the AS path 704 to your peering AS. 706 o Do not accept private AS numbers except from customers 708 o Do not advertise private AS numbers. Exception: Customers using 709 BGP without having their own AS number must use private AS numbers 710 to advertise their prefixes to their upstream. The private AS 711 number is usually provided by the upstream. 713 o Do not accept prefixes when the first AS number in the AS-path is 714 not the one of the peer. In case the peering is done toward a BGP 715 route-server [30] (connection on an Internet eXchange Point - IXP) 716 with transparent AS path handling, this verification needs to be 717 de-activated as the first AS number will be the one of an IXP 718 member whereas the peer AS number will be the one of the BGP 719 route-server. 721 9. Next-Hop Filtering 723 If peering on a shared network, like an Exchange-Point, BGP can 724 advertise prefixes with a 3rd-party next-hop, thus directing packets 725 not to the peer announcing the prefix but somewhere else. 727 This is a desirable property for BGP route-server setups [30], where 728 the route-server will relay routing information, but has neither 729 capacity nor desire to receive the actual data packets. So the BGP 730 route-server will announce prefixes with a next-hop setting pointing 731 to the router that originally announced the prefix to the route- 732 server. 734 In direct peerings between ISPs, this is undesirable, as one of the 735 peers could trick the other one to send packets into a black hole 736 (unreachable next-hop) or to an unsuspecting 3rd party who would then 737 have to carry the traffic. Especially for black-holing, the root 738 cause of the problem is hard to see without inspecting BGP prefixes 739 at the receiving router at the IXP. 741 Therefore, the authors recommend to, by default, apply an inbound 742 route policy to IXP peerings which sets the next-hop for accepted 743 prefixes to the BGP peer that sent the prefix (which is what "next- 744 hop-self" would enforce on the sending side, but you can not rely on 745 the other party to always send correct information). 747 This policy MUST NOT be used on route-server peerings, or on peerings 748 where you intentionally permit the other side to send 3rd-party next- 749 hops. 751 10. BGP community scrubbing 753 Optionally we can consider the following rules on BGP AS-paths: 755 o Scrub inbound communities with your AS number in the high-order 756 bits - allow only those communities that customers/peers can use 757 as a signaling mechanism 759 o Do not remove other communities: your customers might need them to 760 communicate with upstream providers. In particular do not 761 (generally) remove the no-export community as it is usually 762 announced by your peer for a certain purpose. 764 11. Change logs 766 11.1. Diffs between draft-jdurand-bgp-security-01 and 767 draft-jdurand-bgp-security-00 769 Following changes have been made since previous document 770 draft-jdurand-bgp-security-00: 772 o "This documents" typo corrected in the former abstract 774 o Add normative reference for RFC5082 in former section 3.2 776 o "Non routable" changed in title of former section 4.1.1 778 o Correction of typo for IPv4 loopback prefix in former section 779 4.1.1.1 781 o Added shared transition space 100.64.0.0/10 in former section 782 4.1.1.1 784 o Clarification that 2002::/16 6to4 prefix can cross network 785 boundaries in former section 4.1.1.2 787 o Rationale of 2000::/3 explained in former section 4.1.1.2 789 o Added 3FFE::/16 prefix forgotten initially in the simplified list 790 of prefixes that MUST not be routed by definition in former 791 section 4.1.1.2 793 o Warn that filters for prefixes not allocated by IANA must only be 794 done if regular refresh is guaranteed, with some words about the 795 IPv4 experience, in former section 4.1.2.1 797 o Replace RIR database with IRR. A definition of IRR is added in 798 former section 4.1.2.2 800 o Remove any reference to anti-spoofing in former section 4.1.4 802 o Clarification for IXP LAN prefix and pMTUd problem in former 803 section 4.1.5 805 o "Autonomous filters" typo (instead of Autonomous systems) 806 corrected in the former section 4.2 808 o Removal of an example for manual address validation in former 809 section 4.2.2.1 811 o RFC5735 obsoletes RFC3300 813 o Ingress/Egress replaced by Inbound/Outbound in all the document 815 11.2. Diffs between draft-jdurand-bgp-security-02 and 816 draft-jdurand-bgp-security-01 818 Following changes have been made since previous document 819 draft-jdurand-bgp-security-01: 821 o 2 documentation prefixes were forgotten due to errata in RFC5735. 822 But all prefixes were removed from that document which now point 823 to other references for sake of not creating a new "registry" that 824 would become outdated sooner or later. 826 o Change MD5 section with global TCP security session and 827 introducing TCP-AO in former section 3.1. Added reference to 828 BCP38 830 o Added new section 3 about BGP router protection with forwarding 831 plane ACL 833 o Change text about prefix acceptable specificity in former section 834 4.1.3 to explain this doc does not try to make recommendations 836 o Refer as much as possible to existing registries to avoid creating 837 a new one in former section 4.1.1.1 and 4.1.1.2 839 o Abstract reworded 841 o 6to4 exception described (only more specifics must be filtered) 843 o More specific -> more specifics 845 o should -> MUST for the prefixes an ISP needs to filter from its 846 customers in former section 4.2.2.1 848 o Added "plus some headroom to permit growth" in former section 7 850 o Added new section on Next-Hop filtering 852 12. Acknowledgements 854 Authors would like to thank the following people for their comments 855 and support: Marc Blanchet, Ron Bonica, Daniel Ginsburg, David 856 Groves, Tim Kleefass, Hagen Paul Pfeifer, Thomas Pinaud, Carlos 857 Pignataro, Matjaz Straus, Tony Tauber, Gunter Van de Velde, Sebastian 858 Wiesinger. 860 13. IANA Considerations 862 This memo includes no request to IANA. 864 14. Security Considerations 866 This document is entirely about BGP operational security. 868 15. References 870 15.1. Normative References 872 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 873 Levels", BCP 14, RFC 2119, March 1997, 874 . 876 [2] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 877 Signature Option", RFC 2385, August 1998. 879 [3] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 880 June 1999. 882 [4] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 883 IPv4 Clouds", RFC 3056, February 2001. 885 [5] Huitema, C. and B. Carpenter, "Deprecating Site Local 886 Addresses", RFC 3879, September 2004. 888 [6] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 889 Addresses", RFC 4193, October 2005. 891 [7] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 892 (BGP-4)", RFC 4271, January 2006. 894 [8] Hinden, R. and S. Deering, "IP Version 6 Addressing 895 Architecture", RFC 4291, February 2006. 897 [9] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, 898 "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, 899 October 2007. 901 [10] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication 902 Option", RFC 5925, June 2010. 904 15.2. Informative References 906 [11] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 907 Specifications: ABNF", RFC 2234, November 1997. 909 [12] Ferguson, P. and D. Senie, "Network Ingress Filtering: 910 Defeating Denial of Service Attacks which employ IP Source 911 Address Spoofing", BCP 38, RFC 2827, May 2000. 913 [13] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 914 Reserved for Documentation", RFC 3849, July 2004. 916 [14] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, "Routing 917 Policy Specification Language next generation (RPSLng)", 918 RFC 4012, March 2005. 920 [15] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 921 Specifications: ABNF", RFC 4234, October 2005. 923 [16] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, 924 April 2008. 926 [17] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 927 BCP 153, RFC 5735, January 2010. 929 [18] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 930 Reserved for Documentation", RFC 5737, January 2010. 932 [19] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the Router 933 Control Plane", RFC 6192, March 2011. 935 [20] Smith, P. and C. Panigl, "RIPE-378 - RIPE Routing Working Group 936 Recommendations On Route-flap Damping", May 2006. 938 [21] Smith, P., Evans, R., and M. Hughes, "RIPE-399 - RIPE Routing 939 Working Group Recommendations on Route Aggregation", 940 December 2006. 942 [22] Smith, P. and R. Evans, "RIPE-532 - RIPE Routing Working Group 943 Recommendations on IPv6 Route Aggregation", November 2011. 945 [23] Doering, G., "IPv6 BGP Filter Recommendations", November 2009, 946 . 948 [24] "IANA IPv4 Address Space Registry", . 951 [25] "IANA IPv6 Address Space", . 954 [26] "IANA IPv6 Special Purpose Registry", . 958 [27] "IANA IPv6 Address Space Registry", . 962 [28] "Routing Assets Database", . 964 [29] "Secure Inter-Domain Routing IETF working group", 965 . 967 [30] "Internet Exchange Route Server", . 970 [31] "IANA Reserved IPv4 Prefix for Shared Address Space", . 974 Authors' Addresses 976 Jerome Durand 977 CISCO Systems, Inc. 978 11 rue Camille Desmoulins 979 Issy-les-Moulineaux 92782 CEDEX 980 FR 982 Email: jerduran@cisco.com 984 Ivan Pepelnjak 985 NIL Data Communications 986 Tivolska 48 987 Ljubljana 1000 988 Slovenia 990 Email: ip@nil.com 991 Gert Doering 992 SpaceNet AG 993 Joseph-Dollinger-Bogen 14 994 Muenchen D-80807 995 Germany 997 Email: gert@space.net