idnits 2.17.1 draft-ietf-opsec-bgp-security-07.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 -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document date (December 2, 2014) is 3426 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) -- Obsolete informational reference (is this intentional?): RFC 2385 (ref. '7') (Obsoleted by RFC 5925) == Outdated reference: A later version (-12) exists of draft-ietf-idr-ix-bgp-route-server-05 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: Best Current Practice I. Pepelnjak 5 Expires: June 2, 2015 NIL 6 G. Doering 7 SpaceNet 8 December 2, 2014 10 BGP operations and security 11 draft-ietf-opsec-bgp-security-07.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 is 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, TCP-AO, 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 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [1]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 29, 2015. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Scope of the document . . . . . . . . . . . . . . . . . . . . 3 69 3. Definitions and Accronyms . . . . . . . . . . . . . . . . . . 4 70 4. Protection of the BGP speaker . . . . . . . . . . . . . . . . 4 71 5. Protection of BGP sessions . . . . . . . . . . . . . . . . . 5 72 5.1. Protection of TCP sessions used by BGP . . . . . . . . . 5 73 5.2. BGP TTL security (GTSM) . . . . . . . . . . . . . . . . . 6 74 6. Prefix filtering . . . . . . . . . . . . . . . . . . . . . . 6 75 6.1. Definition of prefix filters . . . . . . . . . . . . . . 6 76 6.1.1. Special purpose prefixes . . . . . . . . . . . . . . 6 77 6.1.2. Prefixes not allocated . . . . . . . . . . . . . . . 7 78 6.1.3. Prefixes too specific . . . . . . . . . . . . . . . . 11 79 6.1.4. Filtering prefixes belonging to the local AS and 80 downstreams . . . . . . . . . . . . . . . . . . . . . 11 81 6.1.5. IXP LAN prefixes . . . . . . . . . . . . . . . . . . 11 82 6.1.6. The default route . . . . . . . . . . . . . . . . . . 12 83 6.2. Prefix filtering recommendations in full routing networks 13 84 6.2.1. Filters with Internet peers . . . . . . . . . . . . . 13 85 6.2.2. Filters with customers . . . . . . . . . . . . . . . 15 86 6.2.3. Filters with upstream providers . . . . . . . . . . . 15 87 6.3. Prefix filtering recommendations for leaf networks . . . 16 88 6.3.1. Inbound filtering . . . . . . . . . . . . . . . . . . 16 89 6.3.2. Outbound filtering . . . . . . . . . . . . . . . . . 16 90 7. BGP route flap dampening . . . . . . . . . . . . . . . . . . 17 91 8. Maximum prefixes on a peering . . . . . . . . . . . . . . . . 17 92 9. AS-path filtering . . . . . . . . . . . . . . . . . . . . . . 17 93 10. Next-Hop Filtering . . . . . . . . . . . . . . . . . . . . . 19 94 11. BGP community scrubbing . . . . . . . . . . . . . . . . . . . 20 95 12. Change logs . . . . . . . . . . . . . . . . . . . . . . . . . 20 96 12.1. Diffs between draft-jdurand-bgp-security-01 and draft- 97 jdurand-bgp-security-00 . . . . . . . . . . . . . . . . 20 99 12.2. Diffs between draft-jdurand-bgp-security-02 and draft- 100 jdurand-bgp-security-01 . . . . . . . . . . . . . . . . 21 101 12.3. Diffs between draft-ietf-opsec-bgp-security-00 and 102 draft-jdurand-bgp-security-02 . . . . . . . . . . . . . 22 103 12.4. Diffs between draft-ietf-opsec-bgp-security-01 and 104 draft-ietf-opsec-bgp-security-00 . . . . . . . . . . . . 22 105 12.5. Diffs between draft-ietf-opsec-bgp-security-02 and 106 draft-ietf-opsec-bgp-security-01 . . . . . . . . . . . . 23 107 12.6. Diffs between draft-ietf-opsec-bgp-security-03 and 108 draft-ietf-opsec-bgp-security-02 . . . . . . . . . . . . 24 109 12.7. Diffs between draft-ietf-opsec-bgp-security-04 and 110 draft-ietf-opsec-bgp-security-03 . . . . . . . . . . . . 25 111 12.8. Diffs between draft-ietf-opsec-bgp-security-05 and 112 draft-ietf-opsec-bgp-security-04 . . . . . . . . . . . . 25 113 12.9. Diffs between draft-ietf-opsec-bgp-security-06 and 114 draft-ietf-opsec-bgp-security-05 . . . . . . . . . . . . 25 115 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 116 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 117 15. Security Considerations . . . . . . . . . . . . . . . . . . . 26 118 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 119 16.1. Normative References . . . . . . . . . . . . . . . . . . 27 120 16.2. Informative References . . . . . . . . . . . . . . . . . 27 121 Appendix A. IXP LAN prefix filtering - example . . . . . . . . . 29 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 124 1. Introduction 126 BGP (Border Gateway Protocol - RFC 4271 [2]) is the protocol used in 127 the Internet to exchange routing information between network domains. 128 BGP does not directly include mechanisms that control that routes 129 exchanged conform to the various guidelines defined by the Internet 130 community. This document intends to both summarize common existing 131 guidelines and help network administrators apply coherent BGP 132 policies. 134 2. Scope of the document 136 The guidelines defined in this document are intended for generic 137 Internet BGP peerings. The nature of the Internet is such that 138 Autonomous Systems can always agree on exceptions to a common 139 framework for relevant local needs, and therefore configure a BGP 140 session in a manner that may differ from the recommendations provided 141 in this document. While this is perfectly acceptable, every 142 configured exception might have an impact on the entire inter-domain 143 routing environment and network administrators SHOULD carefully 144 appraise this impact before implementation. 146 3. Definitions and Accronyms 148 o ACL: Access Control List 150 o ASN: Autonomous System Number 152 o IRR: Internet Routing Registry 154 o IXP: Internet eXchange Point 156 o LIR: Local Internet Registry 158 o pMTUd: Path MTU Discovery 160 o RIR: Regional Internet Registry 162 o Tier 1 transit provider: an IP transit provider which can reach 163 any network on the Internet without purchasing transit services 165 o uRPF: Unicast Reverse Path Forwarding 167 4. Protection of the BGP speaker 169 The BGP speaker needs to be protected from attempts to subvert the 170 BGP session. This protection SHOULD be achieved by an Access Control 171 List (ACL) which would discard all packets directed to TCP port 179 172 on the local device and sourced from an address not known or 173 permitted to become a BGP neighbor. Experience has shown that 174 natural protection TCP should offer is not always sufficient as it is 175 sometimes run in control-plane software: in the absence of ACLs it is 176 possible to attack a BGP speaker by simply sending a high volume of 177 connection requests to it. 179 If supported, an ACL specific to the control-plane of the router 180 SHOULD be used (receive-ACL, control-plane policing, etc.), to avoid 181 configuration of data-plane filters for packets transiting through 182 the router (and therefore not reaching the control plane). If the 183 hardware can not do that, interface ACLs can be used to block packets 184 addressed to the local router. 186 Some routers automatically program such an ACL upon BGP 187 configuration. On other devices this ACL should be configured and 188 maintained manually or using scripts. 190 In addition to strict filtering, rate-limiting MAY be configured for 191 accepted BGP traffic. Rate-limiting BGP traffic consists in 192 permitting only a certain quantity of bits per second (or packets per 193 second) of BGP traffic to the control plane. This protects the BGP 194 router control plane in case the amount of BGP traffic overcomes 195 platform capabilities. 197 Filtering and rate-limiting of control-plane traffic is a wider topic 198 than "just for BGP" (if network administrator brings down a router by 199 overloading one of the other protocols from remote, BGP is harmed as 200 well). For a more detailed recommendation on how to protect the 201 router's control plane, see RFC 6192 [11]. 203 5. Protection of BGP sessions 205 Current security issues of TCP-based protocols (therefore including 206 BGP) have been documented in RFC 6952 [14]. The following sub- 207 sections list the major points raised in this RFC and give best 208 practices related to TCP session protection for BGP operation. 210 5.1. Protection of TCP sessions used by BGP 212 Attacks on TCP sessions used by BGP (aka BGP sessions), for example 213 sending spoofed TCP RST packets, could bring down a BGP peering. 214 Following a successful ARP spoofing attack (or other similar Man-in- 215 the-Middle attack), the attacker might even be able to inject packets 216 into the TCP stream (routing attacks). 218 BGP sessions can be secured with a variety of mechanisms. MD5 219 protection of TCP session header, described in RFC 2385 [7], was the 220 first such mechanism. It is now deprecated by TCP Authentication 221 Option (TCP-AO, RFC 5925 [4]) which offers stronger protection. 222 While MD5 is still the most used mechanism due to its availability in 223 vendor's equipment, TCP-AO SHOULD be preferred when implemented. 225 IPsec could also be used for session protection. At the time this 226 document is published, there is not enough experience on impacts of 227 the use of IPsec for BGP peerings and further analysis is required to 228 define guidelines. 230 The drawback of TCP session protection is additional configuration 231 and management overhead for authentication information (ex: MD5 232 password) maintenance. Protection of TCP sessions used by BGP is 233 thus NOT REQUIRED even when peerings are established over shared 234 networks where spoofing can be done (like IXPs), but operators are 235 RECOMMENDED to consider the trade-offs and to apply TCP session 236 protection where appropriate. 238 Network administrators SHOULD block spoofed packets (packets with a 239 source IP address belonging to their IP address space) at all edges 240 of their network (see RFC 2827 [8] and RFC 3704 [9]). This protects 241 the TCP session used by iBGP from attackers outside the Autonomous 242 System. 244 5.2. BGP TTL security (GTSM) 246 BGP sessions can be made harder to spoof with the Generalized TTL 247 Security Mechanisms (GTSM, aka TTL security), defined in RFC 5082 248 [3]. Instead of sending TCP packets with TTL value of 1, the BGP 249 speakers send the TCP packets with TTL value of 255 and the receiver 250 checks that the TTL value equals 255. Since it's impossible to send 251 an IP packet with TTL of 255 to a non-directly-connected IP host, BGP 252 TTL security effectively prevents all spoofing attacks coming from 253 third parties not directly connected to the same subnet as the BGP- 254 speaking routers. Network administrators SHOULD implement TTL 255 security on directly connected BGP peerings. 257 GTSM could also be applied to multi-hop BGP peering as well. To 258 achieve this TTL needs to be configured with proper value depending 259 on the distance between BGP speakers (using principle described 260 above). Nevertheless it is not as effective as anyone inside the TTL 261 diameter could spoof the TTL. 263 Like MD5 protection, TTL security has to be configured on both ends 264 of a BGP session. 266 6. Prefix filtering 268 The main aspect of securing BGP resides in controlling the prefixes 269 that are received/advertised on the BGP peerings. Prefixes exchanged 270 between BGP peers are controlled with inbound and outbound filters 271 that can match on IP prefixes (prefix filters, Section 6), AS paths 272 (as-path filters, Section 9) or any other attributes of a BGP prefix 273 (for example, BGP communities, Section 11). 275 6.1. Definition of prefix filters 277 This section list the most commonly used prefix filters. Following 278 sections will clarify where these filters should be applied. 280 6.1.1. Special purpose prefixes 282 6.1.1.1. IPv4 special purpose prefixes 284 IANA IPv4 Special-Purpose Address Registry [22] maintains the list of 285 IPv4 special purpose prefixes and their routing scope, and SHOULD be 286 used for prefix filters configuration. Prefixes with value "False" 287 in column "Global" SHOULD be discarded on Internet BGP peerings. 289 6.1.1.2. IPv6 special purpose prefixes 291 IANA IPv6 Special-Purpose Address Registry [23] maintains the list of 292 IPv6 special purpose prefixes and their routing scope, and SHOULD be 293 used for prefix filters configuration. Only prefixes with value 294 "False" in column "Global" SHOULD be discarded on Internet BGP 295 peerings. 297 6.1.2. Prefixes not allocated 299 IANA allocates prefixes to RIRs which in turn allocate prefixes to 300 LIRs (Local Internet Registries). It is wise not to accept routing 301 table prefixes that are not allocated by IANA and/or RIRs. This 302 section details the options for building a list of allocated prefixes 303 at every level. It is important to understand that filtering 304 prefixes not allocated requires constant updates as prefixes are 305 continually allocated. Therefore automation of such prefix filters 306 is key for the success of this approach. Network administrators 307 SHOULD NOT consider solutions described in this section if they are 308 not capable of maintaining updated prefix filters: the damage would 309 probably be worse than the intended security policy. 311 6.1.2.1. IANA allocated prefix filters 313 IANA has allocated all the IPv4 available space. Therefore there is 314 no reason why network administrators would keep checking that 315 prefixes they receive from BGP peers are in the IANA allocated IPv4 316 address space [24]. No specific filters need to be put in place by 317 administrators who want to make sure that IPv4 prefixes they receive 318 in BGP updates have been allocated by IANA. 320 For IPv6, given the size of the address space, it can be seen as wise 321 accepting only prefixes derived from those allocated by IANA. 322 Administrators can dynamically build this list from the IANA 323 allocated IPv6 space [25]. As IANA keeps allocating prefixes to 324 RIRs, the aforementioned list should be checked regularly against 325 changes and if they occur, prefix filters should be computed and 326 pushed on network devices. The list could also be pulled directly by 327 routers when they implement such mechanisms. As there is delay 328 between the time a RIR receives a new prefix and the moment it starts 329 allocating portions of it to its LIRs, there is no need for doing 330 this step quickly and frequently. However, network administrators 331 SHOULD ensure that all IPv6 prefix filters are updated within maximum 332 one month after any change in the list of IPv6 prefix allocated by 333 IANA. 335 If process in place (manual or automatic) cannot guarantee that the 336 list is updated regularly then it's better not to configure any 337 filters based on allocated networks. The IPv4 experience has shown 338 that many network operators implemented filters for prefixes not 339 allocated by IANA but did not update them on a regular basis. This 340 created problems for latest allocations and required a extra work for 341 RIRs that had to "de-bogonize" the newly allocated prefixes. 343 6.1.2.2. RIR allocated prefix filters 345 A more precise check can be performed when one would like to make 346 sure that prefixes they receive are being originated or transited by 347 autonomous systems entitled to do so. It has been observed in the 348 past that an AS (Autonomous System) could easily advertise someone 349 else's prefix (or more specific prefixes) and create black holes or 350 security threats. To partially mitigate this risk, administrators 351 would need to make sure BGP advertisements correspond to information 352 located in the existing registries. At this stage 2 options can be 353 considered (short and long term options). They are described in the 354 following subsections. 356 6.1.2.2.1. Prefix filters creation from Internet Routing Registries 357 (IRR) 359 An Internet Routing Registry (IRR) is a database containing Internet 360 routing information, described using Routing Policy Specification 361 Language objects - RFC 4012 [10]. Network administrators are given 362 privileges to describe routing policies of their own networks in the 363 IRR and information is published, usually publicly. A majority of 364 Regional Internet Registries do also operate an IRR and can control 365 that registered routes conform to prefixes allocated or directly 366 assigned.However, it should be noted that the list of such prefixes 367 is not necessarily a complete list, and as such the list of routes in 368 an IRR is not the same as the set of RIR allocated prefixes. 370 It is possible to use the IRR information to build, for a given 371 neighbor autonomous system, a list of prefixes originated or 372 transited which one may accept. This can be done relatively easily 373 using scripts and existing tools capable of retrieving this 374 information in the registries. This approach is exactly the same for 375 both IPv4 and IPv6. 377 The macro-algorithm for the script is described as follows. For the 378 peer that is considered, the distant network administrator has 379 provided the autonomous system and may be able to provide an AS-SET 380 object (aka AS-MACRO). An AS-SET is an object which contains AS 381 numbers or other AS-SETs. An operator may create an AS-SET defining 382 all the AS numbers of its customers. A tier 1 transit provider might 383 create an AS-SET describing the AS-SET of connected operators, which 384 in turn describe the AS numbers of their customers. Using recursion, 385 it is possible to retrieve from an AS-SET the complete list of AS 386 numbers that the peer is likely to announce. For each of these AS 387 numbers, it is also easy to check in the corresponding IRR for all 388 associated prefixes. With these two mechanisms a script can build 389 for a given peer the list of allowed prefixes and the AS number from 390 which they should be originated. One could decide not use the origin 391 information and only build monolithic prefix filters from fetched 392 data. 394 As prefixes, AS numbers and AS-SETs may not all be under the same RIR 395 authority, a difficulty resides choosing for each object the 396 appropriate IRR to poll. Some IRRs have been created and are not 397 restricted to a given region or authoritative RIR. They allow RIRs 398 to publish information contained in their IRR in a common place. 399 They also make it possible for any subscriber (probably under 400 contract) to publish information too. When doing requests inside 401 such an IRR, it is possible to specify the source of information in 402 order to have the most reliable data. One could check a popular IRR 403 containing many sources (such as RADB [26], the Routing Assets 404 Database) and only select as sources some desired RIRs and trusted 405 major ISPs (Internet Service Providers). 407 As objects in IRRs may frequently vary over time, it is important 408 that prefix filters computed using this mechanism are refreshed 409 regularly. A daily basis could even be considered as some routing 410 changes must be done sometimes in a certain emergency and registries 411 may be updated at the very last moment. It has to be noted that this 412 approach significantly increases the complexity of the router 413 configurations as it can quickly add tens of thousands configuration 414 lines for some important peers. To manage this complexity, network 415 adminstrators could for example use IRRToolSet [29], a set of tools 416 making it possible to simplify the creation of automated filters 417 configuration from policies stored in IRR. 419 Last but not least, network administrators SHOULD publish and 420 maintain their resources properly in IRR database maintained by their 421 RIR, when available. 423 6.1.2.2.2. SIDR - Secure Inter Domain Routing 425 An infrastructure called SIDR (Secure Inter-Domain Routing), 426 described in RFC 6480 [12] has been designed to secure Internet 427 advertisements. At the time this document is written, many documents 428 have been published and a framework with a complete set of protocols 429 is proposed so that advertisements can be checked against signed 430 routing objects in RIR routing registries. There are basically two 431 services that SIDR offers: 433 o Origin validation, described in RFC 6811 [5], seeks at making sure 434 that attributes associated with a routes are correct (the major 435 point being the validation of the AS number originating this 436 route). Origin validation is now operational (Internet 437 registries, protocols, implementations on some routers...) and in 438 theory it can be implemented knowing that the proportion of signed 439 resources is still low at the time this document is written. 441 o Path validation provided by BGPsec [27] seeks at making sure that 442 no ones announce fake/wrong BGP paths that would attract trafic 443 for a given destination, see RFC 7132 [16]. BGPsec is still an 444 on-going work item at the time this document is written and 445 therefore cannot be implemented. 447 Implementing SIDR mechanisms is expected to solve many of BGP routing 448 security problems in the long term but it may take time for 449 deployments to be made and objects to become signed. It also has to 450 be pointed that SIDR infrastructure is complementing (not replacing) 451 the security best practices listed in this document. Network 452 administrators SHOULD therefore implement any SIDR proposed mechanism 453 (example: route origin validation) on top of the other existing 454 mechanisms even if they could sometimes appear targeting the same 455 goal. 457 If route origin validation is implemented, reader SHOULD refer to 458 rules described in RFC 7115 [15]. In short, each external route 459 received on a router SHOULD be checked against the RPKI data set: 461 o If a corresponding ROA (Route Origin Authorization) is found and 462 is valid then the prefix SHOULD be accepted. 464 o It the ROA is found and is INVALID then the prefix SHOULD be 465 discarded. 467 o If an ROA is not found then the prefix SHOULD be accepted but 468 corresponding route SHOULD be given a low preference. 470 In addition to this, network administrators SHOULD sign their routing 471 objects so their routes can be validated by other networks running 472 origin validation. 474 One should understand that the RPKI model brings new interesting 475 challenges. The paper On the Risk of Misbehaving RPKI Authorities 476 [30] explains how RPKI model can impact the Internet if authorities 477 don't behave as they are supposed to do. Further analysis is 478 certainly required on RPKI, which carries part of BGP security. 480 6.1.3. Prefixes too specific 482 Most ISPs will not accept advertisements beyond a certain level of 483 specificity (and in return do not announce prefixes they consider as 484 too specific). That acceptable specificity is decided for each 485 peering between the 2 BGP peers. Some ISP communities have tried to 486 document acceptable specificity. This document does not make any 487 judgement on what the best approach is, it just recalls that there 488 are existing practices on the Internet and recommends the reader to 489 refer to what those are. As an example the RIPE community has 490 documented that as of the time of writing of this document, IPv4 491 prefixes longer than /24 and IPv6 prefixes longer than /48 are 492 generally not announced/accepted in the Internet [19] [20]. These 493 values may change in the future. 495 6.1.4. Filtering prefixes belonging to the local AS and downstreams 497 A network SHOULD filter its own prefixes on peerings with all its 498 peers (inbound direction). This prevents local traffic (from a local 499 source to a local destination) from leaking over an external peering 500 in case someone else is announcing the prefix over the Internet. 501 This also protects the infrastructure which may directly suffer in 502 case backbone's prefix is suddenly preferred over the Internet. 504 In some cases, for example in multi-homing scenarios, such filters 505 SHOULD NOT be applied as this would break the desired redundancy. 507 To an extent, such filters can also be configured on a network for 508 the prefixes of its downstreams in order to protect them too. Such 509 filters must be defined with caution as they can break existing 510 redundancy mechanisms. For example in case an operator has a 511 multihomed customer, it should keep accepting the customer prefix 512 from its peers and upstreams. This will make it possible for the 513 customer to keep accessing its operator network (and other customers) 514 via the Internet in case the BGP peering between the customer and the 515 operator is down. 517 6.1.5. IXP LAN prefixes 519 6.1.5.1. Network security 521 When a network is present on an IXP and peers with other IXP members 522 over a common subnet (IXP LAN prefix), it SHOULD NOT accept more 523 specific prefixes for the IXP LAN prefix from any of its external BGP 524 peers. Accepting these routes may create a black hole for 525 connectivity to the IXP LAN. 527 If the IXP LAN prefix is accepted as an "exact match", care needs to 528 be taken to avoid other routers in the network sending IXP traffic 529 towards the externally-learned IXP LAN prefix (recursive route lookup 530 pointing into the wrong direction). This can be achieved by 531 preferring IGP routes before eBGP, or by using "BGP next-hop-self" on 532 all routes learned on that IXP. 534 If the IXP LAN prefix is accepted at all, it SHOULD only be accepted 535 from the ASes that the IXP authorizes to announce it - which will 536 usually be automatically achieved by filtering announcements by IRR 537 DB. 539 6.1.5.2. pMTUd and the loose uRPF problem 541 In order to have pMTUd working in the presence of loose uRPF, it is 542 necessary that all the networks that may source traffic that could 543 flow through the IXP (ie. IXP members and their downstreams) have a 544 route for the IXP LAN prefix. This is necessary as "packet too big" 545 ICMP messages sent by IXP members' routers may be sourced using an 546 address of the IXP LAN prefix. In the presence of loose uRPF, this 547 ICMP packet is dropped if there is no route for the IXP LAN prefix or 548 a less specific route covering IXP LAN prefix. 550 In that case, any IXP member SHOULD make sure it has a route for the 551 IXP LAN prefix or a less specific prefix on all its routers and that 552 it announces the IXP LAN prefix or less specific (up to a default 553 route) to its downstreams. The announcements done for this purpose 554 SHOULD pass IRR-generated filters described in Section 6.1.2.2.1 as 555 well as "prefixes too specific" filters described in Section 6.1.3. 556 The easiest way to implement this is that the IXP itself takes care 557 of the origination of its prefix and advertises it to all IXP members 558 through a BGP peering. Most likely the BGP route servers would be 559 used for this. The IXP would most likely send its entire prefix 560 which would be equal or less specific than the IXP LAN prefix. 562 Appendix Appendix A gives an example of guidelines regarding IXP LAN 563 prefix. 565 6.1.6. The default route 567 6.1.6.1. IPv4 569 The 0.0.0.0/0 prefix is likely not intended to be accepted nor 570 advertised other than in specific customer / provider configurations, 571 general filtering outside of these is RECOMMENDED. 573 6.1.6.2. IPv6 575 The ::/0 prefix is likely not intended to be accepted nor advertised 576 other than in specific customer / provider configurations, general 577 filtering outside of these is RECOMMENDED. 579 6.2. Prefix filtering recommendations in full routing networks 581 For networks that have the full Internet BGP table, some policies 582 should be applied on each BGP peer for received and advertised 583 routes. It is RECOMMENDED that each autonomous system configures 584 rules for advertised and received routes at all its borders as this 585 will protect the network and its peer even in case of 586 misconfiguration. The most commonly used filtering policy is 587 proposed in this section and uses prefix filters defined in previous 588 section Section 6.1. 590 6.2.1. Filters with Internet peers 592 6.2.1.1. Inbound filtering 594 There are basically 2 options, the loose one where no check will be 595 done against RIR allocations and the strict one where it will be 596 verified that announcements strictly conform to what is declared in 597 routing registries. 599 6.2.1.1.1. Inbound filtering loose option 601 In this case, the following prefixes received from a BGP peer will be 602 filtered: 604 o Prefixes not globally routable (Section 6.1.1) 606 o Prefixes not allocated by IANA (IPv6 only) (Section 6.1.2.1) 608 o Routes too specific (Section 6.1.3) 610 o Prefixes belonging to the local AS (Section 6.1.4) 612 o IXP LAN prefixes (Section 6.1.5) 614 o The default route (Section 6.1.6) 616 6.2.1.1.2. Inbound filtering strict option 618 In this case, filters are applied to make sure advertisements 619 strictly conform to what is declared in routing registries 620 (Section 6.1.2.2). Warning is given as registries are not always 621 accurate (prefixes missing, wrong information...) This varies across 622 the registries and regions of the Internet. Before applying a strict 623 policy the reader SHOULD check the impact on the filter and make sure 624 solution is not worse than the problem. 626 Also in case of script failure each administrator may decide if all 627 routes are accepted or rejected depending on routing policy. While 628 accepting the routes during that time frame could break the BGP 629 routing security, rejecting them might re-route too much traffic on 630 transit peers, and could cause more harm than what a loose policy 631 would have done. 633 In addition to this, network administrators could apply the following 634 filters beforehand in case the routing registry used as source of 635 information by the script is not fully trusted: 637 o Prefixes not globally routable (Section 6.1.1) 639 o Routes too specific (Section 6.1.3) 641 o Prefixes belonging to the local AS (Section 6.1.4) 643 o IXP LAN prefixes (Section 6.1.5) 645 o The default route (Section 6.1.6) 647 6.2.1.2. Outbound filtering 649 Configuration should be put in place to make sure that only 650 appropriate prefixes are sent. These can be, for example, prefixes 651 belonging to both the network in question and its downstreams. This 652 can be achieved by using a combination of BGP communities, AS-paths 653 or both. It can also be desirable that following filters are 654 positioned before to avoid unwanted route announcement due to bad 655 configuration: 657 o Prefixes not globally routable (Section 6.1.1) 659 o Routes too specific (Section 6.1.3) 661 o IXP LAN prefixes (Section 6.1.5) 663 o The default route (Section 6.1.6) 665 In case it is possible to list the prefixes to be advertised, then 666 just configuring the list of allowed prefixes and denying the rest is 667 sufficient. 669 6.2.2. Filters with customers 671 6.2.2.1. Inbound filtering 673 The inbound policy with end customers is pretty straightforward: only 674 customers prefixes SHOULD be accepted, all others SHOULD be 675 discarded. The list of accepted prefixes can be manually specified, 676 after having verified that they are valid. This validation can be 677 done with the appropriate IP address management authorities. 679 The same rules apply in case the customer is also a network 680 connecting other customers (for example a tier 1 transit provider 681 connecting service providers). An exception can be envisaged in case 682 it is known that the customer network applies strict inbound/outbound 683 prefix filtering, and the number of prefixes announced by that 684 network is too large to list them in the router configuration. In 685 that case filters as in Section 6.2.1.1 can be applied. 687 6.2.2.2. Outbound filtering 689 The outbound policy with customers may vary according to the routes 690 customer wants to receive. In the simplest possible scenario, the 691 customer may only want to receive only the default route, which can 692 be done easily by applying a filter with the default route only. 694 In case the customer wants to receive the full routing (in case it is 695 multihomed or if wants to have a view of the Internet table), the 696 following filters can be simply applied on the BGP peering: 698 o Prefixes not globally routable (Section 6.1.1) 700 o Routes too specific (Section 6.1.3) 702 o The default route (Section 6.1.6) 704 There can be a difference for the default route that can be announced 705 to the customer in addition to the full BGP table. This can be done 706 simply by removing the filter for the default route. As the default 707 route may not be present in the routing table, network administrators 708 may decide to originate it only for peerings where it has to be 709 advertised. 711 6.2.3. Filters with upstream providers 712 6.2.3.1. Inbound filtering 714 In case the full routing table is desired from the upstream, the 715 prefix filtering to apply is the same as the one for peers 716 Section 6.2.1.1 with the exception of the default route. The default 717 route can be desired from an upstream provider in addition to the 718 full BGP table. In case the upstream provider is supposed to 719 announce only the default route, a simple filter will be applied to 720 accept only the default prefix and nothing else. 722 6.2.3.2. Outbound filtering 724 The filters to be applied would most likely not differ much from the 725 ones applied for Internet peers (Section 6.2.1.2). But different 726 policies could be applied in case it is desired that a particular 727 upstream does not provide transit to all the prefixes. 729 6.3. Prefix filtering recommendations for leaf networks 731 6.3.1. Inbound filtering 733 The leaf network will deploy the filters corresponding to the routes 734 it is requesting from its upstream. In case a default route is 735 requested, a simple inbound filter can be applied to accept only the 736 default route (Section 6.1.6). In case the leaf network is not 737 capable of listing the prefixes because the amount is too large (for 738 example if it requires the full Internet routing table) then it 739 should configure filters to avoid receiving bad announcements from 740 its upstream: 742 o Prefixes not routable (Section 6.1.1) 744 o Routes too specific (Section 6.1.3) 746 o Prefixes belonging to local AS (Section 6.1.4) 748 o The default route (Section 6.1.6) depending if the route is 749 requested or not 751 6.3.2. Outbound filtering 753 A leaf network will most likely have a very straightforward policy: 754 it will only announce its local routes. It can also configure the 755 following prefixes filters described in Section 6.2.1.2 to avoid 756 announcing invalid routes to its upstream provider. 758 7. BGP route flap dampening 760 The BGP route flap dampening mechanism makes it possible to give 761 penalties to routes each time they change in the BGP routing table. 762 Initially this mechanism was created to protect the entire Internet 763 from multiple events impacting a single network. Studies have shown 764 that implementations of BGP route flap dampening could cause more 765 harm than they solve problems and therefore RIPE community has in the 766 past recommended not using BGP route flap dampening [18]. Studies 767 have then been conducted to propose new route flap dampening 768 thresholds in order to make the solution "usable", see RFC 7196 [6] 769 and RIPE has reviewed its recommendations in [21]. This document 770 RECOMMENDS following IETF and RIPE recommendations and only use BGP 771 route flap dampening with the adjusted configured thresholds. 773 8. Maximum prefixes on a peering 775 It is RECOMMENDED to configure a limit on the number of routes to be 776 accepted from a peer. Following rules are generally RECOMMENDED: 778 o From peers, it is RECOMMENDED to have a limit lower than the 779 number of routes in the Internet. This will shut down the BGP 780 peering if the peer suddenly advertises the full table. Network 781 admistrators can also configure different limits for each peer, 782 according to the number of routes they are supposed to advertise 783 plus some headroom to permit growth. 785 o From upstreams which provide full routing, it is RECOMMENDED to 786 have a limit higher than the number of routes in the Internet. A 787 limit is still useful in order to protect the network (and in 788 particular the routers' memory) if too many routes are sent by the 789 upstream. The limit should be chosen according to the number of 790 routes that can actually be handled by routers. 792 It is important to regularly review the limits that are configured as 793 the Internet can quickly change over time. Some vendors propose 794 mechanisms to have two thresholds: while the higher number specified 795 will shutdown the peering, the first threshold will only trigger a 796 log and can be used to passively adjust limits based on observations 797 made on the network. 799 9. AS-path filtering 801 This section lists the RECOMMENDED practices when processing BGP AS- 802 paths: 804 o Network administrators SHOULD accept from customers only AS(4)- 805 Paths containing ASNs belonging to (or authorized to transit 806 through) the customer. If network administrators can not build 807 and generate filtering expressions to implement this, they SHOULD 808 consider accepting only path lengths relevant to the type of 809 customer they have (as in, if these customers are a leaf or have 810 customers of their own), and try to discourage excessive 811 prepending in such paths. This loose policy could be combined 812 with filters for specific AS(4)-Paths that must not be accepted if 813 advertised by the customer, such as upstream transit provider or 814 peer ASNs. 816 o Network administrators SHOULD NOT accept prefixes with private AS 817 numbers in the AS-path except from customers. Exception: an 818 upstream offering some particular service like black-hole 819 origination based on a private AS number. Customers should be 820 informed by their upstream in order to put in place ad-hoc policy 821 to use such services. 823 o Network administrators SHOULD NOT accept prefixes when the first 824 AS number in the AS-path is not the one of the peer unless the 825 peering is done toward a BGP route-server [17] (for example on an 826 IXP) with transparent AS path handling. In that case this 827 verification needs to be de-activated as the first AS number will 828 be the one of an IXP member whereas the peer AS number will be the 829 one of the BGP route-server. 831 o Network administrators SHOULD NOT advertise prefixes with non- 832 empty AS-path unless they intend to be transit for these prefixes. 834 o Network administrators SHOULD NOT advertise prefixes with upstream 835 AS numbers in the AS-path to their peering AS unless they intend 836 to be transit for these prefixes. 838 o Private AS numbers are conventionally used in contexts that are 839 "private" and SHOULD NOT be used in advertisements to BGP peers 840 that are not party to such private arrangements, and should be 841 stripped when received from BGP peers that are not party to such 842 private arrangements. 844 o Network administrators SHOULD NOT override BGP's default behavior 845 accepting their own AS number in the AS-path. In case an 846 exception to this is required, impacts should be studied carefully 847 as this can create severe impact on routing. 849 AS-path filtering should be further analyzed when ASN renumbering is 850 done. Such operation is common and mechanisms exist to allow smooth 851 ASN migration [28]. The usual migration technique, local to a 852 router, consists in modifying the AS-path so it is presented to a 853 peer with the previous ASN, as if no renumbering was done. This 854 makes it possible to change ASN of a router without reconfiguring all 855 eBGP peers at the same time (as this operation would require 856 synchronization with all peers attached to that router). During this 857 renumbering operation, rules described above may be adjusted. 859 10. Next-Hop Filtering 861 If peering on a shared network, like an IXP, BGP can advertise 862 prefixes with a 3rd-party next-hop, thus directing packets not to the 863 peer announcing the prefix but somewhere else. 865 This is a desirable property for BGP route-server setups [17], where 866 the route-server will relay routing information, but has neither 867 capacity nor desire to receive the actual data packets. So the BGP 868 route-server will announce prefixes with a next-hop setting pointing 869 to the router that originally announced the prefix to the route- 870 server. 872 In direct peerings between ISPs, this is undesirable, as one of the 873 peers could trick the other one to send packets into a black hole 874 (unreachable next-hop) or to an unsuspecting 3rd party who would then 875 have to carry the traffic. Especially for black-holing, the root 876 cause of the problem is hard to see without inspecting BGP prefixes 877 at the receiving router at the IXP. 879 Therefore, an inbound route policy SHOULD be applied on IXP peerings 880 in order to set the next-hop for accepted prefixes to the BGP peer IP 881 address (belonging to the IXP LAN) that sent the prefix (which is 882 what "next-hop-self" would enforce on the sending side). 884 This policy SHOULD NOT be used on route-server peerings, or on 885 peerings where network administrators intentionally permit the other 886 side to send 3rd-party next-hops. 888 This policy also SHOULD be adjusted if Remote Triggered Black Holing 889 best practice (aka RTBH - RFC 6666 [13]) is implemented. In that 890 case network administrators would apply a well-known BGP next-hop for 891 routes they want to filter (if an Internet threat is observed from/to 892 this route for example). This well known next-hop will be statically 893 routed to a null interface. In combination with unicast RPF check, 894 this will discard traffic from and toward this prefix. Peers can 895 exchange information about black-holes using for example particular 896 BGP communities. Network administrators could propagate black-holes 897 information to their peers using agreed BGP community: when receiving 898 a route with that community a configured policy could change the 899 next-hop in order to create the black hole. 901 11. BGP community scrubbing 903 Optionally we can consider the following rules on BGP AS-paths: 905 o Network administrators SHOULD scrub inbound communities with their 906 number in the high-order bits, and allow only those communities 907 that customers/peers can use as a signaling mechanism 909 o Networks administrators SHOULD NOT remove other communities 910 applied on received routes (communities not removed after 911 application of previous statement). In particular they SHOULD 912 keep original communities when they apply a community. Customers 913 might need them to communicate with upstream providers. In 914 particular network administrators SHOULD NOT (generally) remove 915 the no-export community as it is usually announced by their peer 916 for a certain purpose. 918 12. Change logs 920 !!! NOTE TO THE RFC EDITOR: THIS SECTION WAS ADDED TO TRACK CHANGES 921 AND FACILITATE WORKING GROUP COLLABORATION. IT MUST BE DELETED 922 BEFORE PUBLICATION !!! 924 12.1. Diffs between draft-jdurand-bgp-security-01 and draft-jdurand- 925 bgp-security-00 927 Following changes have been made since previous document draft- 928 jdurand-bgp-security-00: 930 o "This documents" typo corrected in the former abstract 932 o Add normative reference for RFC5082 in former section 3.2 934 o "Non routable" changed in title of former section 4.1.1 936 o Correction of typo for IPv4 loopback prefix in former section 937 4.1.1.1 939 o Added shared transition space 100.64.0.0/10 in former section 940 4.1.1.1 942 o Clarification that 2002::/16 6to4 prefix can cross network 943 boundaries in former section 4.1.1.2 945 o Rationale of 2000::/3 explained in former section 4.1.1.2 946 o Added 3FFE::/16 prefix forgotten initially in the simplified list 947 of prefixes that must not be routed by definition in former 948 section 4.1.1.2 950 o Warn that filters for prefixes not allocated by IANA MUST only be 951 done if regular refresh is guaranteed, with some words about the 952 IPv4 experience, in former section 4.1.2.1 954 o Replace RIR database with IRR. A definition of IRR is added in 955 former section 4.1.2.2 957 o Remove any reference to anti-spoofing in former section 4.1.4 959 o Clarification for IXP LAN prefix and pMTUd problem in former 960 section 4.1.5 962 o "Autonomous filters" typo (instead of Autonomous systems) 963 corrected in the former section 4.2 965 o Removal of an example for manual address validation in former 966 section 4.2.2.1 968 o RFC5735 obsoletes RFC3300 970 o Ingress/Egress replaced by Inbound/Outbound in all the document 972 12.2. Diffs between draft-jdurand-bgp-security-02 and draft-jdurand- 973 bgp-security-01 975 Following changes have been made since previous document draft- 976 jdurand-bgp-security-01: 978 o 2 documentation prefixes were forgotten due to errata in RFC5735. 979 But all prefixes were removed from that document which now point 980 to other references for sake of not creating a new "registry" that 981 would become outdated sooner or later 983 o Change MD5 section with global TCP security session and 984 introducing TCP-AO in former section 3.1. Added reference to 985 BCP38 987 o Added new section 3 about BGP router protection with forwarding 988 plane ACL 990 o Change text about prefix acceptable specificity in former section 991 4.1.3 to explain this doc does not try to make recommendations 993 o Refer as much as possible to existing registries to avoid creating 994 a new one in former section 4.1.1.1 and 4.1.1.2 996 o Abstract reworded 998 o 6to4 exception described (only more specifics MUST be filtered) 1000 o More specific -> more specifics 1002 o should -> MUST for the prefixes an ISP needs to filter from its 1003 customers in former section 4.2.2.1 1005 o Added "plus some headroom to permit growth" in former section 7 1007 o Added new section on Next-Hop filtering 1009 12.3. Diffs between draft-ietf-opsec-bgp-security-00 and draft-jdurand- 1010 bgp-security-02 1012 Following changes have been made since previous document draft- 1013 jdurand-bgp-security-02: 1015 o Added a subsection for RTBH in next-hop section with reference to 1016 RFC6666 1018 o Changed last sentence of introduction 1020 o Many edits throughout the document 1022 o Added definition of tier 1 transit provider 1024 o Removed definition of a BGP peering 1026 o Removed description of routing policies for IPv6 prefixes in IANA 1027 special registry as this now contains a routing scope field 1029 o Added reference to RFC6598 and changed the IPv4 prefixes to be 1030 filtered by definition section 1032 o IXP added in accronym/definition section and only term used 1033 throughout the doc now 1035 12.4. Diffs between draft-ietf-opsec-bgp-security-01 and draft-ietf- 1036 opsec-bgp-security-00 1038 Following changes have been made since previous document draft-ietf- 1039 opsec-bgp-security-00: 1041 o Obsolete RFC2385 moved from normative to informative reference 1043 o Clarification of preference of TCP-AO over MD5 in former section 1044 4.1 1046 o Mentioning KARP efforts in TCP session protection section in 1047 former section 4 and adding 3 RFC as informative references: 6518, 1048 6862 and 6952 1050 o Removing reference to SIDR working-group 1052 o Better dissociating origin validation and path validation to 1053 clarify what's potentially available for deployment 1055 o Adding that SIDR mechanisms should be implemented in addition to 1056 the other ones mentioned throughout this document 1058 o Added a paragraph in former section 8 about ASN renumbering 1060 o Change of security considerations section 1062 o Added the newly created IANA IPv4 Special Purpose Address Registry 1063 instead of references to RFCs listing these addresses 1065 12.5. Diffs between draft-ietf-opsec-bgp-security-02 and draft-ietf- 1066 opsec-bgp-security-01 1068 Following changes have been made since previous document draft-ietf- 1069 opsec-bgp-security-01: 1071 o Added a reference to draft-ietf-sidr-origin-ops 1073 o Added a reference to RFC6811 and RFC6907 1075 o Changes "Most of RIR's" to "A majority of RIR's" on IRR 1076 availability 1078 o Various edits 1080 o Added NIST BGP security recommendations document 1082 o Added that it's possible to get info from ISPs from RADB 1084 o Correction of the url for IPv4 special use prefixes repository 1086 o Clarification of the fact only prefixes with Global Scope set to 1087 False MUST be discarded 1089 o IANA list could be pulled directly by routers (not just pushed on 1090 routers). 1092 o Warning added when prefixes are checked against IRR 1094 o Recommend network operators to sign their routing objects 1096 o Recommend network operators to publish their routing objects in 1097 IRR of their IRR when available 1099 o Dissociate rules for local AS and downstreams in former section 1100 5.1.4 1102 12.6. Diffs between draft-ietf-opsec-bgp-security-03 and draft-ietf- 1103 opsec-bgp-security-02 1105 Following changes have been made since previous document draft-ietf- 1106 opsec-bgp-security-02: 1108 o Added a note on TCP-AO to be preferred over MD5 1110 o Mention that loose AS filtering with customers can be combined 1111 with precise filters for important ASNs (example those of 1112 transits) that are must not be received on theses peers in former 1113 section 8. 1115 o MD5 removed from abstract 1117 o recommended -> RECOMMENDED where appropriate 1119 o Reference to BCP38 and BCP84 in former section 4.1 1121 o Added a note to RFC Editor to remove change section before 1122 publication 1124 o Removal of "future work" section 1126 o Added rate-limiting in addition to filtering in former section 3 1128 o Reference to IRRToolSet in former section 5.1.2.3 1130 o Removed "foreword" section 1132 12.7. Diffs between draft-ietf-opsec-bgp-security-04 and draft-ietf- 1133 opsec-bgp-security-03 1135 Following changes have been made since previous document draft-ietf- 1136 opsec-bgp-security-03: 1138 o RFC6890 updates RFC5735 1140 o RFC6890 updates RFC5156 1142 o Removed reference RFC2234 and RFC 4234 1144 o Moved route-server draft into informative reference section 1146 12.8. Diffs between draft-ietf-opsec-bgp-security-05 and draft-ietf- 1147 opsec-bgp-security-04 1149 Following changes have been made since previous document draft-ietf- 1150 opsec-bgp-security-04: 1152 o RFC7196 updates draft-ietf-idr-rfd-usable 1154 o RFC7115 updates draft-ietf-sidr-origin-ops 1156 o draft-ietf-idr-ix-bgp-route-server-05 updates ietf-idr-ix-bgp- 1157 route-server-00 1159 12.9. Diffs between draft-ietf-opsec-bgp-security-06 and draft-ietf- 1160 opsec-bgp-security-05 1162 Following changes have been made since previous document draft-ietf- 1163 opsec-bgp-security-05: 1165 o Wording improvements 1167 o Introduction improved 1169 o References are expanded (not just reference numbers are displayed 1170 but also the title of the document 1172 o First occurence of accronyms expanded 1174 o GTSM for multi-hop peerings 1176 o Remove eBGP as protected by BCP38 1178 o Add a caveat for IPsec for session protection 1179 o Changed MUST for SHOULD everywhere 1181 o Small changes in communities section 1183 o Removed simplified IPv6 prefix list 1185 o Removed note in section 9 about 32 bits ASN 1187 o IXP LAN prefix example in appendix 1189 o Make sure all references are in the text. Most of them were 1190 removed as they were initially here for previous version when IANA 1191 registries with routing scopes did not exist 1193 13. Acknowledgements 1195 The authors would like to thank the following people for their 1196 comments and support: Marc Blanchet, Ron Bonica, Randy Bush, David 1197 Freedman, Wesley George, Daniel Ginsburg, David Groves, Mike Hugues, 1198 Joel Jaeggli, Tim Kleefass, Warren Kumari, Jacques Latour, Lionel 1199 Morand, Jerome Nicolle, Hagen Paul Pfeifer, Thomas Pinaud, Carlos 1200 Pignataro, Jean Rebiffe, Donald Smith, Kotikalapudi Sriram, Matjaz 1201 Straus, Tony Tauber, Gunter Van de Velde, Sebastian Wiesinger, 1202 Matsuzaki Yoshinobu. 1204 Authors would like to thank once again Gunter Van de Velde for 1205 presenting the draft at several IETF meetings in various working 1206 groups, indeed helping dissemination of this document and gathering 1207 of precious feedback. 1209 14. IANA Considerations 1211 This memo includes no request to IANA. 1213 15. Security Considerations 1215 This document is entirely about BGP operational security. It depicts 1216 best practices that one should adopt to secure its BGP 1217 infrastructure: protecting BGP router and BGP sessions, adopting 1218 consistent BGP prefix and AS-path filters and configure other options 1219 to secure the BGP network. 1221 On the other hand this document doesn't aim at depicting existing BGP 1222 implementations and their potential vulnerabilities and ways they 1223 handle errors. It does not detail how protection could be enforced 1224 against attack techniques using crafted packets. 1226 16. References 1228 16.1. Normative References 1230 [1] Bradner, S., "Key words for use in RFCs to Indicate 1231 Requirement Levels", BCP 14, RFC 2119, March 1997, 1232 . 1234 [2] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1235 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1237 [3] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 1238 Pignataro, "The Generalized TTL Security Mechanism 1239 (GTSM)", RFC 5082, October 2007. 1241 [4] Touch, J., Mankin, A., and R. Bonica, "The TCP 1242 Authentication Option", RFC 5925, June 2010. 1244 [5] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 1245 Austein, "BGP Prefix Origin Validation", RFC 6811, January 1246 2013. 1248 [6] Pelsser, C., Bush, R., Patel, K., Mohapatra, P., and O. 1249 Maennel, "Making Route Flap Damping Usable", RFC 7196, May 1250 2014. 1252 16.2. Informative References 1254 [7] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1255 Signature Option", RFC 2385, August 1998. 1257 [8] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1258 Defeating Denial of Service Attacks which employ IP Source 1259 Address Spoofing", BCP 38, RFC 2827, May 2000. 1261 [9] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1262 Networks", BCP 84, RFC 3704, March 2004. 1264 [10] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, 1265 "Routing Policy Specification Language next generation 1266 (RPSLng)", RFC 4012, March 2005. 1268 [11] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1269 Router Control Plane", RFC 6192, March 2011. 1271 [12] Lepinski, M. and S. Kent, "An Infrastructure to Support 1272 Secure Internet Routing", RFC 6480, February 2012. 1274 [13] Hilliard, N. and D. Freedman, "A Discard Prefix for IPv6", 1275 RFC 6666, August 2012. 1277 [14] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1278 BGP, LDP, PCEP, and MSDP Issues According to the Keying 1279 and Authentication for Routing Protocols (KARP) Design 1280 Guide", RFC 6952, May 2013. 1282 [15] Bush, R., "Origin Validation Operation Based on the 1283 Resource Public Key Infrastructure (RPKI)", BCP 185, RFC 1284 7115, January 2014. 1286 [16] Kent, S. and A. Chi, "Threat Model for BGP Path Security", 1287 RFC 7132, February 2014. 1289 [17] "Internet Exchange Route Server", 1290 . 1293 [18] Smith, P. and C. Panigl, "RIPE-378 - RIPE Routing Working 1294 Group Recommendations On Route-flap Damping", May 2006. 1296 [19] Smith, P., Evans, R., and M. Hughes, "RIPE-399 - RIPE 1297 Routing Working Group Recommendations on Route 1298 Aggregation", December 2006. 1300 [20] Smith, P. and R. Evans, "RIPE-532 - RIPE Routing Working 1301 Group Recommendations on IPv6 Route Aggregation", November 1302 2011. 1304 [21] Smith, P., Bush, R., Kuhne, M., Pelsser, C., Maennel, O., 1305 Patel, K., Mohapatra, P., and R. Evans, "RIPE-580 - RIPE 1306 Routing Working Group Recommendations On Route-flap 1307 Damping", January 2013. 1309 [22] "IANA IPv4 Special Purpose Address Registry", 1310 . 1313 [23] "IANA IPv6 Special Purpose Address Registry", 1314 . 1317 [24] "IANA IPv4 Address Space Registry", 1318 . 1321 [25] "IANA IPv6 Address Space Registry", 1322 . 1325 [26] "Routing Assets Database", . 1327 [27] "Security Requirements for BGP Path Validation", 1328 . 1331 [28] "Autonomous System (AS) Migration Features and Their 1332 Effects on the BGP AS_PATH Attribute", 1333 . 1336 [29] "IRRToolSet project page", . 1338 [30] Cooper, D., Heilman, E., Brogle, K., Reyzin, L., and S. 1339 Goldberg, "On the Risk of Misbehaving RPKI Authorities", 1340 . 1342 Appendix A. IXP LAN prefix filtering - example 1344 An IXP in the RIPE region is allocated an IPv4 /22 prefix by RIPE NCC 1345 (X.Y.0.0/22 in this example) and uses a /23 of this /22 for the IXP 1346 LAN (let say X.Y.0.0/23). This IXP LAN prefix is the one used by IXP 1347 members to configure eBGP peerings. The IXP could also be allocated 1348 an AS number (AS64496 in our example). 1350 Any IXP member SHOULD make sure it filters prefixes more specific 1351 than X.Y.0.0/23 from all its eBGP peers. If it received X.Y.0.0/24 1352 or X.Y.1.0/24 this could seriously impact its routing. 1354 The IXP SHOULD originate X.Y.0.0/22 and advertise it to its members 1355 through an eBGP peering (most likely from its BGP route servers, 1356 configured with AS64496). 1358 The IXP members SHOULD accept the IXP prefix only if it passes the 1359 IRR generated filters (see Section 6.1.2.2.1) 1361 IXP members SHOULD then advertise X.Y.0.0/22 prefix to their 1362 downstreams. This announce would pass IRR based filters as it is 1363 originated by the IXP. 1365 Authors' Addresses 1367 Jerome Durand 1368 CISCO Systems, Inc. 1369 11 rue Camille Desmoulins 1370 Issy-les-Moulineaux 92782 CEDEX 1371 FR 1373 Email: jerduran@cisco.com 1375 Ivan Pepelnjak 1376 NIL Data Communications 1377 Tivolska 48 1378 Ljubljana 1000 1379 Slovenia 1381 Email: ip@ipspace.net 1383 Gert Doering 1384 SpaceNet AG 1385 Joseph-Dollinger-Bogen 14 1386 Muenchen D-80807 1387 Germany 1389 Email: gert@space.net