idnits 2.17.1 draft-ietf-opsec-bgp-security-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 : ---------------------------------------------------------------------------- == There are 3 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 . . . . 6 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 11.3. Diffs between draft-ietf-opsec-bgp-security-00 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 == 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 [30]. 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 (January 18, 2013) is 4116 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 937, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 943, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 946, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 952, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 955, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 970, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 973, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 984, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 987, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 993, but no explicit reference was found in the text == Unused Reference: '28' is defined on line 1021, but no explicit reference was found in the text == Unused Reference: '34' is defined on line 1040, 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) == Outdated reference: A later version (-12) exists of draft-ietf-idr-ix-bgp-route-server-00 -- Obsolete informational reference (is this intentional?): RFC 2234 (ref. '13') (Obsoleted by RFC 4234) -- Obsolete informational reference (is this intentional?): RFC 4234 (ref. '17') (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 5156 (ref. '18') (Obsoleted by RFC 6890) -- Obsolete informational reference (is this intentional?): RFC 5735 (ref. '19') (Obsoleted by RFC 6890) Summary: 2 errors (**), 0 flaws (~~), 19 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: July 22, 2013 NIL 6 G. Doering 7 SpaceNet 8 January 18, 2013 10 BGP operations and security 11 draft-ietf-opsec-bgp-security-00.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 July 22, 2013. 54 Copyright Notice 56 Copyright (c) 2013 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 and Accronyms . . . . . . . . . . . . . . . . . . 4 73 3. Protection of the 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 . . . . 6 80 5.1.2. Prefixes not allocated . . . . . . . . . . . . . . . . 6 81 5.1.3. Prefixes too specific . . . . . . . . . . . . . . . . 9 82 5.1.4. Filtering prefixes belonging to the local AS . . . . . 9 83 5.1.5. IXP LAN prefixes . . . . . . . . . . . . . . . . . . . 10 84 5.1.6. The 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 . . . . . . . . . . . . . . . . . . . 18 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 11.3. Diffs between draft-ietf-opsec-bgp-security-00 and 104 draft-jdurand-bgp-security-02 . . . . . . . . . . . . . . 20 105 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 106 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 107 14. Security Considerations . . . . . . . . . . . . . . . . . . . 21 108 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 109 15.1. Normative References . . . . . . . . . . . . . . . . . . . 21 110 15.2. Informative References . . . . . . . . . . . . . . . . . . 22 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 113 1. Introduction 115 BGP [7] is the protocol used in the internet to exchange routing 116 information between network domains. This protocol does not directly 117 include mechanisms that control that routes exchanged conform to the 118 various rules defined by the Internet community. This document 119 intends to both summarize common existing rules and help network 120 administrators apply coherent BGP policies. 122 2. Definitions and Accronyms 124 o Tier 1 transit provider: an IP transit provider which can reach 125 any network on the internet without purchasing transit services 127 o IXP: Internet eXchange Point 129 3. Protection of the BGP router 131 The BGP router needs to be protected from stray packets. This 132 protection should be achieved by an access-list (ACL) which would 133 discard all packets directed to TCP port 179 on the local device and 134 sourced from an address not known or permitted to become a BGP 135 neighbor. If supported, an ACL specific to the control-plane of the 136 router should be used (receive-ACL, control-plane policing, etc.), to 137 avoid filtering transit traffic if not needed. If the hardware can 138 not do that, interface ACLs can be used to block packets to the local 139 router. 141 Some routers automatically program such an ACL upon BGP 142 configuration. On other devices this ACL should be configured and 143 maintained manually or using scripts. 145 The filtering of packets destined to the local router is a wider 146 topic than "just for BGP" (if you bring down a router by overloading 147 one of the other protocols from remote, BGP is harmed as well). For 148 a more detailed recommendation, see RFC6192 [21]. 150 4. Protection of BGP sessions 152 4.1. Protection of TCP sessions used by BGP 154 Attacks on TCP sessions used by BGP (ex: sending spoofed TCP 155 RST packets) could bring down the TCP session. Following a 156 successful ARP spoofing attack (or other similar Man-in-the-Middle 157 attack), the attacker might even be able to inject packets into 158 the TCP stream (routing attacks). 160 TCP sessions used by BGP can be secured with a variety of mechanisms. 161 MD5 protection of TCP session header [2] is the most common one, but 162 one could also use IPsec or TCP Authentication Option (TCP-AO, [11]). 164 The drawback of TCP session protection is additional configuration 165 and management overhead for authentication information (ex: MD5 166 password) maintenance. Protection of TCP sessions used by BGP is 167 thus recommended when peerings are established over shared networks 168 where spoofing can be done (like IXPs). 170 You SHOULD block spoofed packets (packets with a source IP address 171 belonging to your IP address space) at all edges of your network, 172 making the protection of TCP sessions used by BGP unnecessary on iBGP 173 or eBGP sessions run over point-to-point links. 175 4.2. BGP TTL security 177 BGP sessions can be made harder to spoof with the TTL security [10]. 178 Instead of sending TCP packets with TTL value = 1, the routers send 179 the TCP packets with TTL value = 255 and the receiver checks that the 180 TTL value equals 255. Since it's impossible to send an IP packet 181 with TTL = 255 to a non-directly-connected IP host, BGP TTL security 182 effectively prevents all spoofing attacks coming from third parties 183 not directly connected to the same subnet as the BGP-speaking 184 routers. Network administrators SHOULD implement TTL security on 185 directly connected BGP peerings. 187 Note: Like MD5 protection, TTL security has to be configured on both 188 ends of a BGP session. 190 5. Prefix filtering 192 The main aspect of securing BGP resides in controlling the prefixes 193 that are received/advertised on the BGP peerings. Prefixes exchanged 194 between BGP peers are controlled with inbound and outbound filters 195 that can match on IP prefixes (prefix filters, Section 5), AS paths 196 (as-path filters, Section 8) or any other attributes of a BGP prefix 197 (for example, BGP communities, Section 10). 199 5.1. Definition of prefix filters 201 This section list the most commonly used prefix filters. Following 202 sections will clarify where these filters should be applied. 204 5.1.1. Prefixes that MUST not be routed by definition 206 5.1.1.1. IPv4 208 At the time of the writing of this document, there is no dynamic IPv4 209 registry listing special prefixes and their status on the internet. 210 On the other hand static document RFC5735 [19] clarifies "special" 211 IPv4 prefixes and their status in the Internet. One should note that 212 RFC5735 [19] has been updated by RFC6598 [22] which adds a new prefix 213 to the ones that MUST NOT be routed across network boundaries. 215 5.1.1.2. IPv6 217 IPv6 registry [31] maintains the list of IPv6 special purpose 218 prefixes and their routing scope. Reader will refer to this registry 219 in order to configure prefix filters. 221 At the time of the writing of this document, the list of IPv6 222 prefixes that MUST not cross network boundaries can be simplified as 223 IANA allocates at the time being prefixes to RIR's only in 2000::/3 224 prefix [30]. All other prefixes (ULA's, link-local, multicast... are 225 outside of that prefix) and therefore the simplified list becomes: 227 o 2001:DB8::/32 and more specifics - documentation [15] 229 o Prefixes more specifics than 2002::/16 - 6to4 [4] 231 o 3FFE::/16 and more specifics - was initially used for the 6Bone 232 (worldwide IPv6 test network) and returned to IANA 234 o All prefixes that are outside 2000::/3 prefix 236 5.1.2. Prefixes not allocated 238 IANA allocates prefixes to RIRs which in turn allocate prefixes to 239 LIRs. It is wise not to accept in the routing table prefixes that 240 are not allocated. This could mean allocation made by IANA and/or 241 allocations done by RIRs. This section details the options for 242 building a list of allocated prefixes at every level. It is 243 important to understand that filtering prefixes not allocated 244 requires constant updates as prefixes are continually allocated. 245 Therefore automation of such prefix filters is key for the success of 246 this approach. One should probably not consider solutions described 247 in this section if it is not capable of maintaining updated prefix 248 filters: the damage would probably be worse than the intended 249 security policy. 251 5.1.2.1. IANA allocated prefix filters 253 IANA has allocated all the IPv4 available space. Therefore there is 254 no reason why one would keep checking prefixes are in the IANA 255 allocated address space [29]. No specific filters need to be put in 256 place by administrators who want to make sure that IPv4 prefixes they 257 receive have been allocated by IANA. 259 For IPv6, given the size of the address space, it can be seen as wise 260 accepting only prefixes derived from those allocated by IANA. 261 Administrators can dynamically build this list from the IANA 262 allocated IPv6 space [32]. As IANA keeps allocating prefixes to 263 RIRs, the aforementioned list should be checked regularly against 264 changes and if they occur, prefix filters should be computed and 265 pushed on network devices. As there is delay between the time a RIR 266 receives a new prefix and the moment it starts allocating portions of 267 it to its LIRs, there is no need doing this step quickly and 268 frequently. Based on past experience, authors recommend that the 269 process in place makes sure there is no more than one month between 270 the time the IANA IPv6 allocated prefix list changes and the moment 271 all IPv6 prefix filters are updated. 273 If process in place (manual or automatic) cannot guarantee that the 274 list is updated regularly then it's better not to configure any 275 filters based on allocated networks. The IPv4 experience has shown 276 that many network operators implemented filters for prefixes not 277 allocated by IANA but did not update them on a regular basis. This 278 created problems for latest allocations and required a extra work for 279 RIRs that had to "de-bogonize" the newly allocated prefixes. 281 5.1.2.2. RIR allocated prefix filters 283 A more precise check can be performed as one would like to make sure 284 that prefixes they receive are being originated or transited by 285 autonomous systems entitled to do so. It has been observed in the 286 past that one could easily advertise someone else's prefix (or more 287 specific prefixes) and create black holes or security threats. To 288 overcome that risk, administrators would need to make sure BGP 289 advertisements correspond to information located in the existing 290 registries. At this stage 2 options can be considered (short and 291 long term options). They are described in the following subsections. 293 5.1.2.3. Prefix filters creation from Internet Routing Registries (IRR) 295 An Internet Routing Registry (IRR) is a database containing internet 296 routing information, described using Routing Policy Specification 297 Language objects [16]. Network administrators are given privileges 298 to describe routing policies of their own networks in the IRR and 299 information is published, usually publicly. Most of Regional 300 Internet Registries do also operate an IRR and can control that 301 registered routes conform to prefixes allocated or directly assigned. 303 It is possible to use the IRR information to build, for a given 304 neighbor autonomous system, a list of prefixes originated or 305 transited which one may accept. This can be done relatively easily 306 using scripts and existing tools capable of retrieving this 307 information in the registries. This approach is exactly the same for 308 both IPv4 and IPv6. 310 The macro-algorithm for the script is described as follows. For the 311 peer that is considered, the distant network administrator has 312 provided the autonomous system and may be able to provide an AS-SET 313 object (aka AS-MACRO). An AS-SET is an object which contains AS 314 numbers or other AS-SETs. An operator may create an AS-SET defining 315 all the AS numbers of its customers. A tier 1 transit provider might 316 create an AS-SET describing the AS-SET of connected operators, which 317 in turn describe the AS numbers of their customers. Using recursion, 318 it is possible to retrieve from an AS-SET the complete list of AS 319 numbers that the peer is likely to announce. For each of these AS 320 numbers, it is also easy to check in the corresponding IRR for all 321 associated prefixes. With these two mechanisms a script can build 322 for a given peer the list of allowed prefixes and the AS number from 323 which they should be originated. One could decide not use the origin 324 information and only build monolithic prefix filters from fetched 325 data. 327 As prefixes, AS numbers and AS-SETs may not all be under the same RIR 328 authority, a difficulty resides choosing for each object the 329 appropriate IRR to poll. Some IRRs have been created and are not 330 restricted to a given region or authoritative RIR. They allow RIRs 331 to publish information contained in their IRR in a common place. 332 They also make it possible for any subscriber (probably under 333 contract) to publish information too. When doing requests inside 334 such an IRR, it is possible to specify the source of information in 335 order to have the most reliable data. One could check a popular IRR 336 containing many sources (such as RADB [33], the Routing Assets 337 Database) and only use information from sources representing the five 338 current RIRs. 340 As objects in IRRs may quickly vary over time, it is important that 341 prefix filters computed using this mechanism are refreshed regularly. 342 A daily basis could even been considered as some routing changes must 343 be done sometimes in a certain emergency and registries may be 344 updated at the very last moment. It has to be noted that this 345 approach significantly increases the complexity of the router 346 configurations as it can quickly add tens of thousands configuration 347 lines for some important peers. 349 5.1.2.4. SIDR - Secure Inter Domain Routing 351 IETF has created a working group called SIDR (Secure Inter-Domain 352 Routing) in order to create an architecture to secure internet 353 advertisements. At the time this document is written, many documents 354 have been published and a framework is proposed so that 355 advertisements can be checked against signed routing objects in RIR 356 routing registries. Implementing mechanisms proposed by this working 357 group is expected to solve many of these BGP routing security 358 problems in the long term. But as it may take time for deployments 359 to be made and objects to become signed, such a solution will need to 360 be combined with the other mechanisms detailed in this document. The 361 rest of this section assumes the reader is familiar with SIDR 362 technologies. 364 Each received route on a router SHOULD be checked against the RPKI 365 data set: if a corresponding ROA is found and is valid then the 366 prefix SHOULD be accepted. It the ROA is found and is INVALID then 367 the prefix SHOULD be discarded. If an ROA is not found then the 368 prefix SHOULD be accepted but corresponding route SHOULD be given a 369 low preference. 371 5.1.3. Prefixes too specific 373 Most ISPs will not accept advertisements beyond a certain level of 374 specificity (and in return do not announce prefixes they consider as 375 too specific). That acceptable specificity is decided for each 376 peering between the 2 BGP peers. Some ISP communities have tried to 377 document acceptable specificity. This document does not make any 378 judgement on what the best approach is, it just recalls that there 379 are existing practices on the internet and recommends the reader to 380 refer to what those are. As an example the RIPE community has 381 documented that IPv4 prefixes longer than /24 and IPv6 prefixes 382 longer than /48 are generally not announced/accepted in the internet 383 [25] [26]. 385 5.1.4. Filtering prefixes belonging to the 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) from leaking over an external peering 390 in case someone else is announcing the prefix over the Internet. 391 This also protects the infrastructure which may directly suffer in 392 case backbone's prefix is suddenly preferred over the Internet. To 393 an 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. IXP LAN prefixes 405 5.1.5.1. Network security 407 When a network is present on an IXP and peers with other IXP members 408 over a common subnet (IXP LAN prefix), it MUST NOT accept more 409 specific prefixes for the IXP LAN prefix from any of its external BGP 410 peers. Accepting these routes may create a black hole for 411 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 the 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 the RIPE region for IPv4. It 451 would be allocated a /22 by RIPE NCC (X.Y.0.0/22 in our example) and 452 use a /23 of this /22 for the IXP LAN (let say X.Y.0.0/23). This IXP 453 LAN 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 an eBGP peering (most likely from its BGP route servers, 463 configured with AS64496). 465 The IXP members SHOULD accept the IXP prefix only if it passes the 466 IRR generated filters (see Section 5.1.2.3) 468 IXP members SHOULD then advertise X.Y.0.0/22 prefix to their 469 downstreams. This announce would pass IRR based filters as it is 470 originated by the IXP. 472 5.1.6. The default route 474 5.1.6.1. IPv4 476 The 0.0.0.0/0 prefix is likely not intended to be accepted nor 477 advertised other than in specific customer / provider configurations, 478 general filtering outside of these is RECOMMENDED. 480 5.1.6.2. IPv6 482 The ::/0 prefix is likely not intended to be accepted nor advertised 483 other than in specific customer / provider configurations, general 484 filtering outside of these is RECOMMENDED. 486 5.2. Prefix filtering recommendations in full routing networks 488 For networks that have the full internet BGP table, some policies 489 should be applied on each BGP peer for received and advertised 490 routes. It is recommended that each autonomous system configures 491 rules for advertised and received routes at all its borders as this 492 will protect the network and its peer even in case of 493 misconfiguration. The most commonly used filtering policy is 494 proposed in this section. 496 5.2.1. Filters with internet peers 498 5.2.1.1. Inbound filtering 500 There are basically 2 options, the loose one where no check will be 501 done against RIR allocations and the strict one where it will be 502 verified that announcements strictly conform to what is declared in 503 routing registries. 505 5.2.1.1.1. Inbound filtering loose option 507 In this case, the following prefixes received from a BGP peer will be 508 filtered: 510 o Prefixes not routable (Section 5.1.1) 512 o Prefixes not allocated by IANA (IPv6 only) (Section 5.1.2.1) 514 o Routes too specific (Section 5.1.3) 516 o Prefixes belonging to the local AS (Section 5.1.4) 518 o IXP LAN prefixes (Section 5.1.5) 520 o The default route (Section 5.1.6) 522 5.2.1.1.2. Inbound filtering strict option 524 In this case, filters are applied to make sure advertisements 525 strictly conform to what is declared in routing registries 526 (Section 5.1.2.2). In case of script failure each administrator may 527 decide if all routes are accepted or rejected depending on routing 528 policy. While accepting the routes during that time frame could 529 break the BGP routing security, rejecting them might re-route too 530 much traffic on transit peers, and could cause more harm than what a 531 loose policy would have done. 533 In addition to this, one could apply the following filters beforehand 534 in case the routing registry used as source of information by the 535 script is not fully trusted: 537 o Prefixes not routable (Section 5.1.1) 538 o Routes too specific (Section 5.1.3) 540 o Prefixes belonging to the local AS (Section 5.1.4) 542 o IXP LAN prefixes (Section 5.1.5) 544 o The default route (Section 5.1.6) 546 5.2.1.2. Outbound filtering 548 Configuration should be put in place to make sure that only 549 appropriate prefixes are sent. These can be, for example, prefixes 550 belonging to both the network in question and its downstreams. This 551 can be achieved by using a combination of BGP communities, AS-paths 552 or both. It can also be desirable that following filters are 553 positioned before to avoid unwanted route announcement due to bad 554 configuration: 556 o Prefixes not routable (Section 5.1.1) 558 o Routes too specific (Section 5.1.3) 560 o IXP LAN prefixes (Section 5.1.5) 562 o The default route (Section 5.1.6) 564 In case it is possible to list the prefixes to be advertised, then 565 just configuring the list of allowed prefixes and denying the rest is 566 sufficient. 568 5.2.2. Filters with customers 570 5.2.2.1. Inbound filtering 572 The inbound policy with end customers is pretty straightforward: only 573 customers prefixes must be accepted, all others MUST be discarded. 574 The list of accepted prefixes can be manually specified, after having 575 verified that they are valid. This validation can be done with the 576 appropriate IP address management authorities. 578 The same rules apply in case the customer is also a network 579 connecting other customers (for example a tier 1 transit provider 580 connecting service providers). An exception can be envisaged in case 581 it is known that the customer network applies strict inbound/outbound 582 prefix filtering, and the number of prefixes announced by that 583 network is too large to list them in the router configuration. In 584 that case filters as in Section 5.2.1.1 can be applied. 586 5.2.2.2. Outbound filtering 588 The outbound policy with customers may vary according to the routes 589 customer wants to receive. In the simplest possible scenario, the 590 customer may only want to receive only the default route, which can 591 be done easily by applying a filter with the default route only. 593 In case the customer wants to receive the full routing (in case it is 594 multihomed or if wants to have a view of the internet table), the 595 following filters can be simply applied on the BGP peering: 597 o Prefixes not routable (Section 5.1.1) 599 o Routes too specific (Section 5.1.3) 601 o The default route (Section 5.1.6) 603 There can be a difference for the default route that can be announced 604 to the customer in addition to the full BGP table. This can be done 605 simply by removing the filter for the default route. As the default 606 route may not be present in the routing table, one may decide to 607 originate it only for peerings where it has to be advertised. 609 5.2.3. Filters with upstream providers 611 5.2.3.1. Inbound filtering 613 In case the full routing table is desired from the upstream, the 614 prefix filtering to apply is the same than the one for peers 615 Section 5.2.1.1 with the exception of the default route. The default 616 route can be desired from an upstream provider in addition to the 617 full BGP table. In case the upstream provider is supposed to 618 announce only the default route, a simple filter will be applied to 619 accept only the default prefix and nothing else. 621 5.2.3.2. Outbound filtering 623 The filters to be applied would most likely not differ much from the 624 ones applied for internet peers (Section 5.2.1.2). But different 625 policies could be applied in case it is desired that a particular 626 upstream does not provide transit to all the prefixes. 628 5.3. Prefix filtering recommendations for leaf networks 630 5.3.1. Inbound filtering 632 The leaf network will position the filters corresponding to the 633 routes it is requesting from its upstream. In case a default route 634 is requested, a simple inbound filter can be applied to accept only 635 the default route (Section 5.1.6). In case the leaf network is not 636 capable of listing the prefixes because the amount is too large (for 637 example if it requires the full internet routing table) then it 638 should configure filters to avoid receiving bad announcements from 639 its upstream: 641 o Prefixes not routable (Section 5.1.1) 643 o Routes too specific (Section 5.1.3) 645 o Prefixes belonging to local AS (Section 5.1.4) 647 o The default route (Section 5.1.6) depending if the route is 648 requested or not 650 5.3.2. Outbound filtering 652 A leaf network will most likely have a very straightforward policy: 653 it will only announce its local routes. It can also configure the 654 following prefixes filters described in Section 5.2.1.2 to avoid 655 announcing invalid routes to its upstream provider. 657 6. BGP route flap dampening 659 The BGP route flap dampening mechanism makes it possible to give 660 penalties to routes each time they change in the BGP routing table. 661 Initially this mechanism was created to protect the entire internet 662 from multiple events impacting a single network. Studies have shown 663 that implementations of BGP route flap dampening could cause more 664 harm than they solve problems and therefore RIPE community has in the 665 past recommended not using BGP route flap dampening [24]. Works have 666 then been conducted to propose new route flap dampening thresholds in 667 order to make the solution "usable" [35] and RIPE has reviewed its 668 recommendations in [27]. New thresholds have been proposed to make 669 BGP route flap dampening usable. Authors of this document propose to 670 follow RIPE recommendations and only use BGP route flap dampening 671 with adjusted configured thresholds. 673 7. Maximum prefixes on a peering 675 It is recommended to configure a limit on the number of routes to be 676 accepted from a peer. Following rules are generally recommended: 678 o From peers, it is recommended to have a limit lower than the 679 number of routes in the internet. This will shut down the BGP 680 peering if the peer suddenly advertises the full table. One can 681 also configure different limits for each peer, according to the 682 number of routes they are supposed to advertise plus some headroom 683 to permit growth. 685 o From upstreams which provide full routing, it is recommended to 686 have a limit higher than the number of routes in the internet. A 687 limit is still useful in order to protect the network (and in 688 particular the routers' memory) if too many routes are sent by the 689 upstream. The limit should be chosen according to the number of 690 routes that can actually be handled by routers. 692 It is important to regularly review the limits that are configured as 693 the internet can quickly change over time. Some vendors propose 694 mechanisms to have two thresholds: while the higher number specified 695 will shutdown the peering, the first threshold will only trigger a 696 log and can be used to passively adjust limits based on observations 697 made on the network. 699 8. AS-path filtering 701 The following rules SHOULD be applied on BGP AS-paths (for both 16 702 and 32 bits Autonomous System Numbers): 704 o From customers, try to accept only AS(4)-Paths containing ASNs 705 belonging to (or authorized to transit through) the customer. If 706 you can not build and generate filtering expressions to implement 707 this, consider accepting only path lengths relevant to the type of 708 customer you have (as in, if they are a leaf or have customers of 709 their own), try to discourage excessive prepending in such paths. 711 o Do not advertise prefixes with non-empty AS-path if you do not 712 intend to be transit for these prefixes. 714 o Do not advertise prefixes with upstream AS numbers in the AS-path 715 to your peering AS if you do not intend to be transit for these 716 prefixes. 718 o Do not accept prefixes with private AS numbers in the AS-path 719 except from customers. Exception: an upstream offering some 720 particular service like black-hole origination based on a private 721 AS number. Customers should be informed by their upstream in 722 order to put in place ad-hoc policy to use such services. 724 o Do not advertise prefixes with private AS numbers in the AS-path. 725 Exception: customers using BGP without having their own AS number 726 must use private AS numbers to advertise their prefixes to their 727 upstream. The private AS number is usually provided by the 728 upstream. 730 o Do not accept prefixes when the first AS number in the AS-path is 731 not the one of the peer. In case the peering is done toward a BGP 732 route-server [12] (connection on an IXP) with transparent AS path 733 handling, this verification needs to be de-activated as the first 734 AS number will be the one of an IXP member whereas the peer AS 735 number will be the one of the BGP route-server. 737 o Don't override BGP's default behavior accepting your own AS number 738 in the AS-path. In case an exception to this is required, impacts 739 should be studied carefully as this can create severe impact on 740 routing. 742 9. Next-Hop Filtering 744 If peering on a shared network, like an IXP, BGP can advertise 745 prefixes with a 3rd-party next-hop, thus directing packets not to the 746 peer announcing the prefix but somewhere else. 748 This is a desirable property for BGP route-server setups [12], where 749 the route-server will relay routing information, but has neither 750 capacity nor desire to receive the actual data packets. So the BGP 751 route-server will announce prefixes with a next-hop setting pointing 752 to the router that originally announced the prefix to the route- 753 server. 755 In direct peerings between ISPs, this is undesirable, as one of the 756 peers could trick the other one to send packets into a black hole 757 (unreachable next-hop) or to an unsuspecting 3rd party who would then 758 have to carry the traffic. Especially for black-holing, the root 759 cause of the problem is hard to see without inspecting BGP prefixes 760 at the receiving router at the IXP. 762 Therefore, an inbound route policy SHOULD be applied on IXP peerings 763 in order to set the next-hop for accepted prefixes to the BGP peer IP 764 address (belonging to the IXP LAN) that sent the prefix (which is 765 what "next-hop-self" would enforce on the sending side). 767 This policy MUST NOT be used on route-server peerings, or on peerings 768 where you intentionally permit the other side to send 3rd-party next- 769 hops. 771 This policy also MUST be adjusted if Remote Triggered Black Holing 772 best practice (aka RTBH [23]) is implemented. In that case one would 773 apply a well-known BGP next-hop for routes it wants to filter (if an 774 internet threat is observed from/to this route for example). This 775 well known next-hop will be statically routed to a null interface. 776 In combination with unicast RPF check, this will discard traffic from 777 and toward this prefix. Peers can exchange information about black- 778 holes using for example particular BGP communities. One could 779 propagate black-holes information to its peers using agreed BGP 780 community: when receiving a route with that community one could 781 change the next-hop in order to create the black hole. 783 10. BGP community scrubbing 785 Optionally we can consider the following rules on BGP AS-paths: 787 o Scrub inbound communities with your AS number in the high-order 788 bits - allow only those communities that customers/peers can use 789 as a signaling mechanism 791 o Do not remove other communities: your customers might need them to 792 communicate with upstream providers. In particular do not 793 (generally) remove the no-export community as it is usually 794 announced by your peer for a certain purpose. 796 11. Change logs 798 11.1. Diffs between draft-jdurand-bgp-security-01 and 799 draft-jdurand-bgp-security-00 801 Following changes have been made since previous document 802 draft-jdurand-bgp-security-00: 804 o "This documents" typo corrected in the former abstract 806 o Add normative reference for RFC5082 in former section 3.2 808 o "Non routable" changed in title of former section 4.1.1 810 o Correction of typo for IPv4 loopback prefix in former section 811 4.1.1.1 813 o Added shared transition space 100.64.0.0/10 in former section 814 4.1.1.1 816 o Clarification that 2002::/16 6to4 prefix can cross network 817 boundaries in former section 4.1.1.2 819 o Rationale of 2000::/3 explained in former section 4.1.1.2 821 o Added 3FFE::/16 prefix forgotten initially in the simplified list 822 of prefixes that MUST not be routed by definition in former 823 section 4.1.1.2 825 o Warn that filters for prefixes not allocated by IANA must only be 826 done if regular refresh is guaranteed, with some words about the 827 IPv4 experience, in former section 4.1.2.1 829 o Replace RIR database with IRR. A definition of IRR is added in 830 former section 4.1.2.2 832 o Remove any reference to anti-spoofing in former section 4.1.4 834 o Clarification for IXP LAN prefix and pMTUd problem in former 835 section 4.1.5 837 o "Autonomous filters" typo (instead of Autonomous systems) 838 corrected in the former section 4.2 840 o Removal of an example for manual address validation in former 841 section 4.2.2.1 843 o RFC5735 obsoletes RFC3300 845 o Ingress/Egress replaced by Inbound/Outbound in all the document 847 11.2. Diffs between draft-jdurand-bgp-security-02 and 848 draft-jdurand-bgp-security-01 850 Following changes have been made since previous document 851 draft-jdurand-bgp-security-01: 853 o 2 documentation prefixes were forgotten due to errata in RFC5735. 854 But all prefixes were removed from that document which now point 855 to other references for sake of not creating a new "registry" that 856 would become outdated sooner or later 858 o Change MD5 section with global TCP security session and 859 introducing TCP-AO in former section 3.1. Added reference to 860 BCP38 862 o Added new section 3 about BGP router protection with forwarding 863 plane ACL 865 o Change text about prefix acceptable specificity in former section 866 4.1.3 to explain this doc does not try to make recommendations 868 o Refer as much as possible to existing registries to avoid creating 869 a new one in former section 4.1.1.1 and 4.1.1.2 871 o Abstract reworded 873 o 6to4 exception described (only more specifics must be filtered) 875 o More specific -> more specifics 877 o should -> MUST for the prefixes an ISP needs to filter from its 878 customers in former section 4.2.2.1 880 o Added "plus some headroom to permit growth" in former section 7 882 o Added new section on Next-Hop filtering 884 11.3. Diffs between draft-ietf-opsec-bgp-security-00 and 885 draft-jdurand-bgp-security-02 887 Following changes have been made since previous document 888 draft-jdurand-bgp-security-02: 890 o Added a subsection for RTBH in next-hop section with reference to 891 RFC6666 893 o Changed last sentence of introduction 895 o Many edits throughout the document 897 o Added definition of tier 1 transit provider 899 o Removed definition of a BGP peering 901 o Removed description of routing policies for IPv6 prefixes in IANA 902 special registry as this now contains a routing scope field 904 o Added reference to RFC6598 and changed the IPv4 prefixes to be 905 filtered by definition section 907 o IXP added in accronym/definition section and only term used 908 throughout the doc now 910 12. Acknowledgements 912 The authors would like to thank the following people for their 913 comments and support: Marc Blanchet, Ron Bonica, David Freedman, 914 Daniel Ginsburg, David Groves, Mike Hugues, Tim Kleefass, Hagen Paul 915 Pfeifer, Thomas Pinaud, Carlos Pignataro, Matjaz Straus, Tony Tauber, 916 Gunter Van de Velde, Sebastian Wiesinger. 918 13. IANA Considerations 920 This memo includes no request to IANA. 922 14. Security Considerations 924 This document is entirely about BGP operational security. 926 15. References 928 15.1. Normative References 930 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 931 Levels", BCP 14, RFC 2119, March 1997, 932 . 934 [2] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 935 Signature Option", RFC 2385, August 1998. 937 [3] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 938 June 1999. 940 [4] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 941 IPv4 Clouds", RFC 3056, February 2001. 943 [5] Huitema, C. and B. Carpenter, "Deprecating Site Local 944 Addresses", RFC 3879, September 2004. 946 [6] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 947 Addresses", RFC 4193, October 2005. 949 [7] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 950 (BGP-4)", RFC 4271, January 2006. 952 [8] Hinden, R. and S. Deering, "IP Version 6 Addressing 953 Architecture", RFC 4291, February 2006. 955 [9] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network 956 Address Translations (NATs)", RFC 4380, February 2006. 958 [10] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, 959 "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, 960 October 2007. 962 [11] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication 963 Option", RFC 5925, June 2010. 965 [12] "Internet Exchange Route Server", . 968 15.2. Informative References 970 [13] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 971 Specifications: ABNF", RFC 2234, November 1997. 973 [14] Ferguson, P. and D. Senie, "Network Ingress Filtering: 974 Defeating Denial of Service Attacks which employ IP Source 975 Address Spoofing", BCP 38, RFC 2827, May 2000. 977 [15] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 978 Reserved for Documentation", RFC 3849, July 2004. 980 [16] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, "Routing 981 Policy Specification Language next generation (RPSLng)", 982 RFC 4012, March 2005. 984 [17] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 985 Specifications: ABNF", RFC 4234, October 2005. 987 [18] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, 988 April 2008. 990 [19] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 991 BCP 153, RFC 5735, January 2010. 993 [20] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 994 Reserved for Documentation", RFC 5737, January 2010. 996 [21] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the Router 997 Control Plane", RFC 6192, March 2011. 999 [22] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. 1000 Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", 1001 BCP 153, RFC 6598, April 2012. 1003 [23] Hilliard, N. and D. Freedman, "A Discard Prefix for IPv6", 1004 RFC 6666, August 2012. 1006 [24] Smith, P. and C. Panigl, "RIPE-378 - RIPE Routing Working Group 1007 Recommendations On Route-flap Damping", May 2006. 1009 [25] Smith, P., Evans, R., and M. Hughes, "RIPE-399 - RIPE Routing 1010 Working Group Recommendations on Route Aggregation", 1011 December 2006. 1013 [26] Smith, P. and R. Evans, "RIPE-532 - RIPE Routing Working Group 1014 Recommendations on IPv6 Route Aggregation", November 2011. 1016 [27] Smith, P., Bush, R., Kuhne, M., Pelsser, C., Maennel, O., 1017 Patel, K., Mohapatra, P., and R. Evans, "RIPE-580 - RIPE 1018 Routing Working Group Recommendations On Route-flap Damping", 1019 January 2013. 1021 [28] Doering, G., "IPv6 BGP Filter Recommendations", November 2009, 1022 . 1024 [29] "IANA IPv4 Address Space Registry", . 1027 [30] "IANA IPv6 Address Space", . 1030 [31] "IANA IPv6 Special Purpose Registry", . 1034 [32] "IANA IPv6 Address Space Registry", . 1038 [33] "Routing Assets Database", . 1040 [34] "Secure Inter-Domain Routing IETF working group", 1041 . 1043 [35] "Making Route Flap Damping Usable", 1044 . 1046 Authors' Addresses 1048 Jerome Durand 1049 CISCO Systems, Inc. 1050 11 rue Camille Desmoulins 1051 Issy-les-Moulineaux 92782 CEDEX 1052 FR 1054 Email: jerduran@cisco.com 1055 Ivan Pepelnjak 1056 NIL Data Communications 1057 Tivolska 48 1058 Ljubljana 1000 1059 Slovenia 1061 Email: ip@nil.com 1063 Gert Doering 1064 SpaceNet AG 1065 Joseph-Dollinger-Bogen 14 1066 Muenchen D-80807 1067 Germany 1069 Email: gert@space.net