idnits 2.17.1 draft-ietf-opsec-bgp-security-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 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: 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 [35]. 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 14, 2014) is 3755 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: '2' is defined on line 1113, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1119, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1122, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1128, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1131, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1151, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1157, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 1168, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 1171, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1174, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 1177, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 1186, but no explicit reference was found in the text == Unused Reference: '25' is defined on line 1190, but no explicit reference was found in the text == Unused Reference: '27' is defined on line 1197, but no explicit reference was found in the text == Unused Reference: '28' is defined on line 1201, but no explicit reference was found in the text == Unused Reference: '34' is defined on line 1227, but no explicit reference was found in the text == Unused Reference: '46' is defined on line 1272, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (ref. '2') (Obsoleted by RFC 7749) -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Obsolete informational reference (is this intentional?): RFC 2234 (ref. '13') (Obsoleted by RFC 4234) -- Obsolete informational reference (is this intentional?): RFC 2385 (ref. '14') (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 4234 (ref. '18') (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 5156 (ref. '19') (Obsoleted by RFC 6890) -- Obsolete informational reference (is this intentional?): RFC 5735 (ref. '20') (Obsoleted by RFC 6890) Summary: 1 error (**), 0 flaws (~~), 21 warnings (==), 7 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: July 18, 2014 NIL 6 G. Doering 7 SpaceNet 8 January 14, 2014 10 BGP operations and security 11 draft-ietf-opsec-bgp-security-02.txt 13 Abstract 15 BGP (Border Gateway Protocol) is the protocol almost exclusively used 16 in the Internet to exchange routing information between network 17 domains. Due to this central nature, it 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, 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 18, 2014. 54 Copyright Notice 56 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Definitions and Accronyms . . . . . . . . . . . . . . . . . . 3 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 (GTSM) . . . . . . . . . . . . . . . . . 5 77 5. Prefix filtering . . . . . . . . . . . . . . . . . . . . . . 5 78 5.1. Definition of prefix filters . . . . . . . . . . . . . . 5 79 5.1.1. Special purpose prefixes . . . . . . . . . . . . . . 5 80 5.1.2. Prefixes not allocated . . . . . . . . . . . . . . . 6 81 5.1.3. Prefixes too specific . . . . . . . . . . . . . . . . 10 82 5.1.4. Filtering prefixes belonging to the local AS and 83 downstreams . . . . . . . . . . . . . . . . . . . . . 10 84 5.1.5. IXP LAN prefixes . . . . . . . . . . . . . . . . . . 10 85 5.1.6. The default route . . . . . . . . . . . . . . . . . . 12 86 5.2. Prefix filtering recommendations in full routing networks 12 87 5.2.1. Filters with internet peers . . . . . . . . . . . . . 12 88 5.2.2. Filters with customers . . . . . . . . . . . . . . . 14 89 5.2.3. Filters with upstream providers . . . . . . . . . . . 15 90 5.3. Prefix filtering recommendations for leaf networks . . . 15 91 5.3.1. Inbound filtering . . . . . . . . . . . . . . . . . . 15 92 5.3.2. Outbound filtering . . . . . . . . . . . . . . . . . 16 93 6. BGP route flap dampening . . . . . . . . . . . . . . . . . . 16 94 7. Maximum prefixes on a peering . . . . . . . . . . . . . . . . 16 95 8. AS-path filtering . . . . . . . . . . . . . . . . . . . . . . 17 96 9. Next-Hop Filtering . . . . . . . . . . . . . . . . . . . . . 18 97 10. BGP community scrubbing . . . . . . . . . . . . . . . . . . . 19 98 11. Possible future work . . . . . . . . . . . . . . . . . . . . 19 99 12. Change logs . . . . . . . . . . . . . . . . . . . . . . . . . 19 100 12.1. Diffs between draft-jdurand-bgp-security-01 and draft- 101 jdurand-bgp-security-00 . . . . . . . . . . . . . . . . 19 102 12.2. Diffs between draft-jdurand-bgp-security-02 and draft- 103 jdurand-bgp-security-01 . . . . . . . . . . . . . . . . 20 104 12.3. Diffs between draft-ietf-opsec-bgp-security-00 and 105 draft-jdurand-bgp-security-02 . . . . . . . . . . . . . 21 106 12.4. Diffs between draft-ietf-opsec-bgp-security-01 and 107 draft-ietf-opsec-bgp-security-00 . . . . . . . . . . . . 22 108 12.5. Diffs between draft-ietf-opsec-bgp-security-02 and 109 draft-ietf-opsec-bgp-security-01 . . . . . . . . . . . . 22 110 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 111 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 112 15. Security Considerations . . . . . . . . . . . . . . . . . . . 24 113 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 114 16.1. Normative References . . . . . . . . . . . . . . . . . . 24 115 16.2. Informative References . . . . . . . . . . . . . . . . . 25 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 118 1. Introduction 120 BGP [6] is the protocol used in the internet to exchange routing 121 information between network domains. This protocol does not directly 122 include mechanisms that control that routes exchanged conform to the 123 various rules defined by the Internet community. This document 124 intends to both summarize common existing rules and help network 125 administrators apply coherent BGP policies. 127 2. Definitions and Accronyms 129 o ACL: Access Control List 131 o IRR: Internet Routing Registry 133 o IXP: Internet eXchange Point 135 o LIR: Local Internet Registry 137 o pMTUd: Path MTU Discovery 139 o RIR: regional Internet Registry 141 o Tier 1 transit provider: an IP transit provider which can reach 142 any network on the internet without purchasing transit services 144 o uRPF: Unicast Reverse Path Forwarding 146 3. Protection of the BGP router 148 The BGP router needs to be protected from stray packets. This 149 protection should be achieved by an access control list (ACL) which 150 would discard all packets directed to TCP port 179 on the local 151 device and sourced from an address not known or permitted to become a 152 BGP neighbor. If supported, an ACL specific to the control-plane of 153 the router should be used (receive-ACL, control-plane policing, 154 etc.), to avoid configuration of data-plane filters for packets 155 transiting through the router (and therefore not reaching the control 156 plane). If the hardware can not do that, interface ACLs can be used 157 to block packets to the local router. 159 Some routers automatically program such an ACL upon BGP 160 configuration. On other devices this ACL should be configured and 161 maintained manually or using scripts. 163 The filtering of packets destined to the local router is a wider 164 topic than "just for BGP" (if you bring down a router by overloading 165 one of the other protocols from remote, BGP is harmed as well). For 166 a more detailed recommendation, see RFC6192 [22]. 168 4. Protection of BGP sessions 170 Current issues of TCP-based protocols (therefore including BGP) have 171 been documented in [29]. The following sub-sections recall the major 172 points raised in this RFC and gives best practices for BGP operation. 174 4.1. Protection of TCP sessions used by BGP 176 Attacks on TCP sessions used by BGP (ex: sending spoofed TCP 177 RST packets) could bring down the TCP session. Following a 178 successful ARP spoofing attack (or other similar Man-in-the-Middle 179 attack), the attacker might even be able to inject packets into 180 the TCP stream (routing attacks). 182 TCP sessions used by BGP can be secured with a variety of mechanisms. 183 MD5 protection of TCP session header [14] is the most common one as 184 it was the first mechanism widely implemented on routers. IPsec or 185 TCP Authentication Option (TCP-AO, [10]) offer stronger protection 186 and should now be preferred when available. 188 The drawback of TCP session protection is additional configuration 189 and management overhead for authentication information (ex: MD5 190 password) maintenance. Protection of TCP sessions used by BGP is 191 thus recommended when peerings are established over shared networks 192 where spoofing can be done (like IXPs). 194 You SHOULD block spoofed packets (packets with a source IP address 195 belonging to your IP address space) at all edges of your network, 196 making the protection of TCP sessions used by BGP unnecessary on iBGP 197 or eBGP sessions run over point-to-point links. 199 4.2. BGP TTL security (GTSM) 201 BGP sessions can be made harder to spoof with the Generalized TTL 202 Security Mechanisms (aka TTL security) [9]. Instead of sending TCP 203 packets with TTL value = 1, the routers send the TCP packets with TTL 204 value = 255 and the receiver checks that the TTL value equals 255. 205 Since it's impossible to send an IP packet with TTL = 255 to a non- 206 directly-connected IP host, BGP TTL security effectively prevents all 207 spoofing attacks coming from third parties not directly connected to 208 the same subnet as the BGP-speaking routers. Network administrators 209 SHOULD implement TTL security on directly connected BGP peerings. 211 Note: Like MD5 protection, TTL security has to be configured on both 212 ends of a BGP session. 214 5. Prefix filtering 216 The main aspect of securing BGP resides in controlling the prefixes 217 that are received/advertised on the BGP peerings. Prefixes exchanged 218 between BGP peers are controlled with inbound and outbound filters 219 that can match on IP prefixes (prefix filters, Section 5), AS paths 220 (as-path filters, Section 8) or any other attributes of a BGP prefix 221 (for example, BGP communities, Section 10). 223 5.1. Definition of prefix filters 225 This section list the most commonly used prefix filters. Following 226 sections will clarify where these filters should be applied. 228 5.1.1. Special purpose prefixes 230 5.1.1.1. IPv4 special purpose prefixes 232 IPv4 registry [36] maintains the list of IPv4 special purpose 233 prefixes and their routing scope. Reader will refer to this registry 234 in order to configure prefix filters. Only prefixes with value 235 "False" in column "Global" MUST be discarded on Internet BGP 236 peerings. 238 5.1.1.2. IPv6 special purpose prefixes 240 IPv6 registry [37] maintains the list of IPv6 special purpose 241 prefixes and their routing scope. Reader will refer to this registry 242 in order to configure prefix filters. Only prefixes with value 243 "False" in column "Global" MUST be discarded on Internet BGP 244 peerings. 246 At the time of the writing of this document, the list of IPv6 247 prefixes that MUST not cross network boundaries can be simplified as 248 IANA allocates at the time being prefixes to RIR's only in 2000::/3 249 prefix [35]. All other prefixes (ULA's, link-local, multicast... are 250 outside of that prefix) and therefore the simplified list becomes: 252 o 2001:DB8::/32 and more specifics - documentation [16] 254 o Prefixes more specifics than 2002::/16 - 6to4 [3] 256 o 3FFE::/16 and more specifics - was initially used for the 6Bone 257 (worldwide IPv6 test network) and returned to IANA 259 o All prefixes that are outside 2000::/3 prefix 261 5.1.2. Prefixes not allocated 263 IANA allocates prefixes to RIRs which in turn allocate prefixes to 264 LIRs. It is wise not to accept in the routing table prefixes that 265 are not allocated. This could mean allocation made by IANA and/or 266 allocations done by RIRs. This section details the options for 267 building a list of allocated prefixes at every level. It is 268 important to understand that filtering prefixes not allocated 269 requires constant updates as prefixes are continually allocated. 270 Therefore automation of such prefix filters is key for the success of 271 this approach. One SHOULD probably NOT consider solutions described 272 in this section if they are not capable of maintaining updated prefix 273 filters: the damage would probably be worse than the intended 274 security policy. 276 5.1.2.1. IANA allocated prefix filters 278 IANA has allocated all the IPv4 available space. Therefore there is 279 no reason why one would keep checking prefixes are in the IANA 280 allocated IPv4 address space [38]. No specific filters need to be 281 put in place by administrators who want to make sure that IPv4 282 prefixes they receive in BGP updates have been allocated by IANA. 284 For IPv6, given the size of the address space, it can be seen as wise 285 accepting only prefixes derived from those allocated by IANA. 287 Administrators can dynamically build this list from the IANA 288 allocated IPv6 space [39]. As IANA keeps allocating prefixes to 289 RIRs, the aforementioned list should be checked regularly against 290 changes and if they occur, prefix filters should be computed and 291 pushed on network devices. The list could also be pulled directly by 292 routers when they implement such mechanisms. As there is delay 293 between the time a RIR receives a new prefix and the moment it starts 294 allocating portions of it to its LIRs, there is no need doing this 295 step quickly and frequently. Based on past experience, authors 296 recommend that the process in place makes sure there is no more than 297 one month between the time the IANA IPv6 allocated prefix list 298 changes and the moment all IPv6 prefix filters are updated. 300 If process in place (manual or automatic) cannot guarantee that the 301 list is updated regularly then it's better not to configure any 302 filters based on allocated networks. The IPv4 experience has shown 303 that many network operators implemented filters for prefixes not 304 allocated by IANA but did not update them on a regular basis. This 305 created problems for latest allocations and required a extra work for 306 RIRs that had to "de-bogonize" the newly allocated prefixes. 308 5.1.2.2. RIR allocated prefix filters 310 A more precise check can be performed as one would like to make sure 311 that prefixes they receive are being originated or transited by 312 autonomous systems entitled to do so. It has been observed in the 313 past that one could easily advertise someone else's prefix (or more 314 specific prefixes) and create black holes or security threats. To 315 partially mitigate this risk, administrators would need to make sure 316 BGP advertisements correspond to information located in the existing 317 registries. At this stage 2 options can be considered (short and 318 long term options). They are described in the following subsections. 320 5.1.2.3. Prefix filters creation from Internet Routing Registries (IRR) 322 An Internet Routing Registry (IRR) is a database containing internet 323 routing information, described using Routing Policy Specification 324 Language objects [17]. Network administrators are given privileges 325 to describe routing policies of their own networks in the IRR and 326 information is published, usually publicly. A majority of Regional 327 Internet Registries do also operate an IRR and can control that 328 registered routes conform to prefixes allocated or directly assigned. 330 It is possible to use the IRR information to build, for a given 331 neighbor autonomous system, a list of prefixes originated or 332 transited which one may accept. This can be done relatively easily 333 using scripts and existing tools capable of retrieving this 334 information in the registries. This approach is exactly the same for 335 both IPv4 and IPv6. 337 The macro-algorithm for the script is described as follows. For the 338 peer that is considered, the distant network administrator has 339 provided the autonomous system and may be able to provide an AS-SET 340 object (aka AS-MACRO). An AS-SET is an object which contains AS 341 numbers or other AS-SETs. An operator may create an AS-SET defining 342 all the AS numbers of its customers. A tier 1 transit provider might 343 create an AS-SET describing the AS-SET of connected operators, which 344 in turn describe the AS numbers of their customers. Using recursion, 345 it is possible to retrieve from an AS-SET the complete list of AS 346 numbers that the peer is likely to announce. For each of these AS 347 numbers, it is also easy to check in the corresponding IRR for all 348 associated prefixes. With these two mechanisms a script can build 349 for a given peer the list of allowed prefixes and the AS number from 350 which they should be originated. One could decide not use the origin 351 information and only build monolithic prefix filters from fetched 352 data. 354 As prefixes, AS numbers and AS-SETs may not all be under the same RIR 355 authority, a difficulty resides choosing for each object the 356 appropriate IRR to poll. Some IRRs have been created and are not 357 restricted to a given region or authoritative RIR. They allow RIRs 358 to publish information contained in their IRR in a common place. 359 They also make it possible for any subscriber (probably under 360 contract) to publish information too. When doing requests inside 361 such an IRR, it is possible to specify the source of information in 362 order to have the most reliable data. One could check a popular IRR 363 containing many sources (such as RADB [40], the Routing Assets 364 Database) and only select as sources some desired RIRs and trusted 365 major ISPs. 367 As objects in IRRs may frequently vary over time, it is important 368 that prefix filters computed using this mechanism are refreshed 369 regularly. A daily basis could even be considered as some routing 370 changes must be done sometimes in a certain emergency and registries 371 may be updated at the very last moment. It has to be noted that this 372 approach significantly increases the complexity of the router 373 configurations as it can quickly add tens of thousands configuration 374 lines for some important peers. 376 Last but not least, authors recommend that network administrators 377 publish and maintain their resources properly in IRR database 378 maintained by their RIR, when available. 380 5.1.2.4. SIDR - Secure Inter Domain Routing 382 An infrastructure called SIDR (Secure Inter-Domain Routing) [23] has 383 been designed to secure internet advertisements. At the time this 384 document is written, many documents have been published and a 385 framework with a complete set of protocols is proposed so that 386 advertisements can be checked against signed routing objects in RIR 387 routing registries. There are basically two services that SIDR 388 offers: 390 o Origin validation [11] seeks at making sure that attributes 391 associated with a routes are correct (the major point being the 392 validation of the AS number originating this route). Origin 393 validation is now operational (Internet registries, protocols, 394 implementations on some routers...) and in theory it can be 395 implemented knowing that the proportion of signed resources is 396 still low at the time this document is written. 398 o Path validation provided by BGPsec [42] seeks at making sure that 399 no ones announce fake/wrong BGP paths that would attract trafic 400 for a given destination [43]. BGPsec is still an on-going work 401 item at the time this document is written and therefore cannot be 402 implemented. 404 Implementing SIDR mechanisms is expected to solve many of BGP routing 405 security problems in the long term but it may take time for 406 deployments to be made and objects to become signed. It also has to 407 be pointed that SIDR infrastructure is complementing (not replacing) 408 the security best practices listed in this document. Authors 409 therefore recommend to implement any SIDR proposed mechanism 410 (example: route origin validation) on top of the other existing 411 mechanisms even if they could sometimes appear targeting the same 412 goal. 414 If route origin validation is implemented, authors recommend to refer 415 to rules described in [45]. In short, each external route received 416 on a router SHOULD be checked against the RPKI data set: 418 o If a corresponding ROA is found and is valid then the prefix 419 SHOULD be accepted. 421 o It the ROA is found and is INVALID then the prefix SHOULD be 422 discarded. 424 o If an ROA is not found then the prefix SHOULD be accepted but 425 corresponding route SHOULD be given a low preference. 427 Authors also recommend that network operators sign their routing 428 objects so their routes can be validated by other networks running 429 origin validation. 431 5.1.3. Prefixes too specific 433 Most ISPs will not accept advertisements beyond a certain level of 434 specificity (and in return do not announce prefixes they consider as 435 too specific). That acceptable specificity is decided for each 436 peering between the 2 BGP peers. Some ISP communities have tried to 437 document acceptable specificity. This document does not make any 438 judgement on what the best approach is, it just recalls that there 439 are existing practices on the internet and recommends the reader to 440 refer to what those are. As an example the RIPE community has 441 documented that IPv4 prefixes longer than /24 and IPv6 prefixes 442 longer than /48 are generally not announced/accepted in the internet 443 [31] [32]. 445 5.1.4. Filtering prefixes belonging to the local AS and downstreams 447 A network SHOULD filter its own prefixes on peerings with all its 448 peers (inbound direction). This prevents local traffic (from a local 449 source to a local destination) from leaking over an external peering 450 in case someone else is announcing the prefix over the Internet. 451 This also protects the infrastructure which may directly suffer in 452 case backbone's prefix is suddenly preferred over the Internet. 454 To an extent, such filters can also be configured on a network for 455 the prefixes of its downstreams in order to protect them too. Such 456 filters must be defined with caution as they can break existing 457 redundancy mechanisms. For example in case an operator has a 458 multihomed customer, it should keep accepting the customer prefix 459 from its peers and upstreams. This will make it possible for the 460 customer to keep accessing its operator network (and other customers) 461 via the internet in case the BGP peering between the customer and the 462 operator is down. 464 5.1.5. IXP LAN prefixes 466 5.1.5.1. Network security 468 When a network is present on an IXP and peers with other IXP members 469 over a common subnet (IXP LAN prefix), it MUST NOT accept more 470 specific prefixes for the IXP LAN prefix from any of its external BGP 471 peers. Accepting these routes may create a black hole for 472 connectivity to the IXP LAN. 474 If the IXP LAN prefix is accepted as an "exact match", care needs to 475 be taken to avoid other routers in the network sending IXP traffic 476 towards the externally-learned IXP LAN prefix (recursive route lookup 477 pointing into the wrong direction). This can be achieved by 478 preferring IGP routes before eBGP, or by using "BGP next-hop-self" on 479 all routes learned on that IXP. 481 If the IXP LAN prefix is accepted at all, it MUST only be accepted 482 from the ASes that the IXP authorizes to announce it - which will 483 usually be automatically achieved by filtering announcements by IRR 484 DB. 486 5.1.5.2. pMTUd and the loose uRPF problem 488 In order to have pMTUd working in the presence of loose uRPF, it is 489 necessary that all the networks that may source traffic that could 490 flow through the IXP (ie. IXP members and their downstreams) have a 491 route for the IXP LAN prefix. This is necessary as "packet too big" 492 ICMP messages sent by IXP members' routers may be sourced using an 493 address of the IXP LAN prefix. In the presence of loose uRPF, this 494 ICMP packet is dropped if there is no route for the IXP LAN prefix or 495 a less specific route covering IXP LAN prefix. 497 In that case, any IXP member SHOULD make sure it has a route for the 498 IXP LAN prefix or a less specific prefix on all its routers and that 499 it announces the IXP LAN prefix or less specific (up to a default 500 route) to its downstreams. The announcements done for this purpose 501 SHOULD pass IRR-generated filters described in Section 5.1.2.3 as 502 well as "prefixes too specific" filters described in Section 5.1.3. 503 The easiest way to implement this is that the IXP itself takes care 504 of the origination of its prefix and advertises it to all IXP members 505 through a BGP peering. Most likely the BGP route servers would be 506 used for this. The IXP would most likely send its entire prefix 507 which would be equal or less specific than the IXP LAN prefix. 509 5.1.5.3. Example 511 Let's take as an example an IXP in the RIPE region for IPv4. It 512 would be allocated a /22 by RIPE NCC (X.Y.0.0/22 in our example) and 513 use a /23 of this /22 for the IXP LAN (let say X.Y.0.0/23). This IXP 514 LAN prefix is the one used by IXP members to configure eBGP peerings. 515 The IXP could also be allocated an AS number (AS64496 in our 516 example). 518 Any IXP member MUST make sure it filters prefixes more specific than 519 X.Y.0.0/23 from all its eBGP peers. If it received X.Y.0.0/24 or 520 X.Y.1.0/24 this could seriously impact its routing. 522 The IXP SHOULD originate X.Y.0.0/22 and advertise it to its members 523 through an eBGP peering (most likely from its BGP route servers, 524 configured with AS64496). 526 The IXP members SHOULD accept the IXP prefix only if it passes the 527 IRR generated filters (see Section 5.1.2.3) 529 IXP members SHOULD then advertise X.Y.0.0/22 prefix to their 530 downstreams. This announce would pass IRR based filters as it is 531 originated by the IXP. 533 5.1.6. The default route 535 5.1.6.1. IPv4 537 The 0.0.0.0/0 prefix is likely not intended to be accepted nor 538 advertised other than in specific customer / provider configurations, 539 general filtering outside of these is RECOMMENDED. 541 5.1.6.2. IPv6 543 The ::/0 prefix is likely not intended to be accepted nor advertised 544 other than in specific customer / provider configurations, general 545 filtering outside of these is RECOMMENDED. 547 5.2. Prefix filtering recommendations in full routing networks 549 For networks that have the full internet BGP table, some policies 550 should be applied on each BGP peer for received and advertised 551 routes. It is recommended that each autonomous system configures 552 rules for advertised and received routes at all its borders as this 553 will protect the network and its peer even in case of 554 misconfiguration. The most commonly used filtering policy is 555 proposed in this section and uses prefix filters defined in previous 556 section Section 5.1. 558 5.2.1. Filters with internet peers 560 5.2.1.1. Inbound filtering 562 There are basically 2 options, the loose one where no check will be 563 done against RIR allocations and the strict one where it will be 564 verified that announcements strictly conform to what is declared in 565 routing registries. 567 5.2.1.1.1. Inbound filtering loose option 569 In this case, the following prefixes received from a BGP peer will be 570 filtered: 572 o Prefixes not globally routable (Section 5.1.1) 574 o Prefixes not allocated by IANA (IPv6 only) (Section 5.1.2.1) 576 o Routes too specific (Section 5.1.3) 578 o Prefixes belonging to the local AS (Section 5.1.4) 580 o IXP LAN prefixes (Section 5.1.5) 582 o The default route (Section 5.1.6) 584 5.2.1.1.2. Inbound filtering strict option 586 In this case, filters are applied to make sure advertisements 587 strictly conform to what is declared in routing registries 588 (Section 5.1.2.2). Warn is given as registries are not always 589 accurate (prefixes missing, wrong information...) This varies accross 590 the registries and regions of the Internet. Before applying a strict 591 policy the reader SHOULD check the impact on the filter and make sure 592 solution is not worse than the problem. 594 Also in case of script failure each administrator may decide if all 595 routes are accepted or rejected depending on routing policy. While 596 accepting the routes during that time frame could break the BGP 597 routing security, rejecting them might re-route too much traffic on 598 transit peers, and could cause more harm than what a loose policy 599 would have done. 601 In addition to this, one could apply the following filters beforehand 602 in case the routing registry used as source of information by the 603 script is not fully trusted: 605 o Prefixes not globally routable (Section 5.1.1) 607 o Routes too specific (Section 5.1.3) 609 o Prefixes belonging to the local AS (Section 5.1.4) 611 o IXP LAN prefixes (Section 5.1.5) 613 o The default route (Section 5.1.6) 615 5.2.1.2. Outbound filtering 617 Configuration should be put in place to make sure that only 618 appropriate prefixes are sent. These can be, for example, prefixes 619 belonging to both the network in question and its downstreams. This 620 can be achieved by using a combination of BGP communities, AS-paths 621 or both. It can also be desirable that following filters are 622 positioned before to avoid unwanted route announcement due to bad 623 configuration: 625 o Prefixes not globally routable (Section 5.1.1) 627 o Routes too specific (Section 5.1.3) 629 o IXP LAN prefixes (Section 5.1.5) 631 o The default route (Section 5.1.6) 633 In case it is possible to list the prefixes to be advertised, then 634 just configuring the list of allowed prefixes and denying the rest is 635 sufficient. 637 5.2.2. Filters with customers 639 5.2.2.1. Inbound filtering 641 The inbound policy with end customers is pretty straightforward: only 642 customers prefixes MUST be accepted, all others MUST be discarded. 643 The list of accepted prefixes can be manually specified, after having 644 verified that they are valid. This validation can be done with the 645 appropriate IP address management authorities. 647 The same rules apply in case the customer is also a network 648 connecting other customers (for example a tier 1 transit provider 649 connecting service providers). An exception can be envisaged in case 650 it is known that the customer network applies strict inbound/outbound 651 prefix filtering, and the number of prefixes announced by that 652 network is too large to list them in the router configuration. In 653 that case filters as in Section 5.2.1.1 can be applied. 655 5.2.2.2. Outbound filtering 657 The outbound policy with customers may vary according to the routes 658 customer wants to receive. In the simplest possible scenario, the 659 customer may only want to receive only the default route, which can 660 be done easily by applying a filter with the default route only. 662 In case the customer wants to receive the full routing (in case it is 663 multihomed or if wants to have a view of the internet table), the 664 following filters can be simply applied on the BGP peering: 666 o Prefixes not globally routable (Section 5.1.1) 668 o Routes too specific (Section 5.1.3) 670 o The default route (Section 5.1.6) 672 There can be a difference for the default route that can be announced 673 to the customer in addition to the full BGP table. This can be done 674 simply by removing the filter for the default route. As the default 675 route may not be present in the routing table, one may decide to 676 originate it only for peerings where it has to be advertised. 678 5.2.3. Filters with upstream providers 680 5.2.3.1. Inbound filtering 682 In case the full routing table is desired from the upstream, the 683 prefix filtering to apply is the same as the one for peers 684 Section 5.2.1.1 with the exception of the default route. The default 685 route can be desired from an upstream provider in addition to the 686 full BGP table. In case the upstream provider is supposed to 687 announce only the default route, a simple filter will be applied to 688 accept only the default prefix and nothing else. 690 5.2.3.2. Outbound filtering 692 The filters to be applied would most likely not differ much from the 693 ones applied for internet peers (Section 5.2.1.2). But different 694 policies could be applied in case it is desired that a particular 695 upstream does not provide transit to all the prefixes. 697 5.3. Prefix filtering recommendations for leaf networks 699 5.3.1. Inbound filtering 701 The leaf network will position the filters corresponding to the 702 routes it is requesting from its upstream. In case a default route 703 is requested, a simple inbound filter can be applied to accept only 704 the default route (Section 5.1.6). In case the leaf network is not 705 capable of listing the prefixes because the amount is too large (for 706 example if it requires the full internet routing table) then it 707 should configure filters to avoid receiving bad announcements from 708 its upstream: 710 o Prefixes not routable (Section 5.1.1) 712 o Routes too specific (Section 5.1.3) 714 o Prefixes belonging to local AS (Section 5.1.4) 716 o The default route (Section 5.1.6) depending if the route is 717 requested or not 719 5.3.2. Outbound filtering 721 A leaf network will most likely have a very straightforward policy: 722 it will only announce its local routes. It can also configure the 723 following prefixes filters described in Section 5.2.1.2 to avoid 724 announcing invalid routes to its upstream provider. 726 6. BGP route flap dampening 728 The BGP route flap dampening mechanism makes it possible to give 729 penalties to routes each time they change in the BGP routing table. 730 Initially this mechanism was created to protect the entire internet 731 from multiple events impacting a single network. Studies have shown 732 that implementations of BGP route flap dampening could cause more 733 harm than they solve problems and therefore RIPE community has in the 734 past recommended not using BGP route flap dampening [30]. Works have 735 then been conducted to propose new route flap dampening thresholds in 736 order to make the solution "usable" [41] and RIPE has reviewed its 737 recommendations in [33]. New thresholds have been proposed to make 738 BGP route flap dampening usable. Authors of this document propose to 739 follow RIPE recommendations and only use BGP route flap dampening 740 with adjusted configured thresholds. 742 7. Maximum prefixes on a peering 744 It is recommended to configure a limit on the number of routes to be 745 accepted from a peer. Following rules are generally recommended: 747 o From peers, it is recommended to have a limit lower than the 748 number of routes in the internet. This will shut down the BGP 749 peering if the peer suddenly advertises the full table. One can 750 also configure different limits for each peer, according to the 751 number of routes they are supposed to advertise plus some headroom 752 to permit growth. 754 o From upstreams which provide full routing, it is recommended to 755 have a limit higher than the number of routes in the internet. A 756 limit is still useful in order to protect the network (and in 757 particular the routers' memory) if too many routes are sent by the 758 upstream. The limit should be chosen according to the number of 759 routes that can actually be handled by routers. 761 It is important to regularly review the limits that are configured as 762 the internet can quickly change over time. Some vendors propose 763 mechanisms to have two thresholds: while the higher number specified 764 will shutdown the peering, the first threshold will only trigger a 765 log and can be used to passively adjust limits based on observations 766 made on the network. 768 8. AS-path filtering 770 This section is listing rules that apply to BGP AS-paths (for both 16 771 and 32 bits Autonomous System Numbers): 773 o You SHOULD accept from customers only AS(4)-Paths containing ASNs 774 belonging to (or authorized to transit through) the customer. If 775 you can not build and generate filtering expressions to implement 776 this, consider accepting only path lengths relevant to the type of 777 customer you have (as in, if they are a leaf or have customers of 778 their own), try to discourage excessive prepending in such paths. 780 o You SHOULD NOT advertise prefixes with non-empty AS-path unless 781 you intend to be transit for these prefixes. 783 o You SHOULD NOT advertise prefixes with upstream AS numbers in the 784 AS-path to your peering AS unless you intend to be transit for 785 these prefixes. 787 o You SHOULD NOT accept prefixes with private AS numbers in the AS- 788 path except from customers. Exception: an upstream offering some 789 particular service like black-hole origination based on a private 790 AS number. Customers should be informed by their upstream in 791 order to put in place ad-hoc policy to use such services. 793 o You SHOULD NOT advertise prefixes with private AS numbers in the 794 AS-path unless you are a customer using BGP without your own AS 795 number. In that case you SHOULD use private AS numbers to 796 advertise your prefixes to your upstream. This private AS number 797 is usually provided by the upstream. 799 o You SHOULD NOT accept prefixes when the first AS number in the AS- 800 path is not the one of the peer unless you the peering is done 801 toward a BGP route-server [12] (connection on an IXP) with 802 transparent AS path handling. In that case this verification 803 needs to be de-activated as the first AS number will be the one of 804 an IXP member whereas the peer AS number will be the one of the 805 BGP route-server. 807 o You SHOULD NOT override BGP's default behavior accepting your own 808 AS number in the AS-path. In case an exception to this is 809 required, impacts should be studied carefully as this can create 810 severe impact on routing. 812 AS-path filtering should be further analyzed when ASN renumbering is 813 done. Such operation is common and mechanisms exist to allow smooth 814 ASN migration [44]. The usual migration technique, local to a 815 router, consists in modifying the AS-path so it is presented to a 816 peer as if no renumbering was done. This makes it possible to change 817 ASN of a router without reconfiguring all eBGP peers at the same time 818 (as this operation would require synchronization with all peers 819 attached to that router). During this renumbering operation, rules 820 described above may be adjusted. 822 9. Next-Hop Filtering 824 If peering on a shared network, like an IXP, BGP can advertise 825 prefixes with a 3rd-party next-hop, thus directing packets not to the 826 peer announcing the prefix but somewhere else. 828 This is a desirable property for BGP route-server setups [12], where 829 the route-server will relay routing information, but has neither 830 capacity nor desire to receive the actual data packets. So the BGP 831 route-server will announce prefixes with a next-hop setting pointing 832 to the router that originally announced the prefix to the route- 833 server. 835 In direct peerings between ISPs, this is undesirable, as one of the 836 peers could trick the other one to send packets into a black hole 837 (unreachable next-hop) or to an unsuspecting 3rd party who would then 838 have to carry the traffic. Especially for black-holing, the root 839 cause of the problem is hard to see without inspecting BGP prefixes 840 at the receiving router at the IXP. 842 Therefore, an inbound route policy SHOULD be applied on IXP peerings 843 in order to set the next-hop for accepted prefixes to the BGP peer IP 844 address (belonging to the IXP LAN) that sent the prefix (which is 845 what "next-hop-self" would enforce on the sending side). 847 This policy MUST NOT be used on route-server peerings, or on peerings 848 where you intentionally permit the other side to send 3rd-party next- 849 hops. 851 This policy also MUST be adjusted if Remote Triggered Black Holing 852 best practice (aka RTBH [26]) is implemented. In that case one would 853 apply a well-known BGP next-hop for routes it wants to filter (if an 854 internet threat is observed from/to this route for example). This 855 well known next-hop will be statically routed to a null interface. 856 In combination with unicast RPF check, this will discard traffic from 857 and toward this prefix. Peers can exchange information about black- 858 holes using for example particular BGP communities. One could 859 propagate black-holes information to its peers using agreed BGP 860 community: when receiving a route with that community one could 861 change the next-hop in order to create the black hole. 863 10. BGP community scrubbing 865 Optionally we can consider the following rules on BGP AS-paths: 867 o Scrub inbound communities with your AS number in the high-order 868 bits - allow only those communities that customers/peers can use 869 as a signaling mechanism 871 o Do not remove other communities: your customers might need them to 872 communicate with upstream providers. In particular do not 873 (generally) remove the no-export community as it is usually 874 announced by your peer for a certain purpose. 876 11. Possible future work 878 Following propositions were made and could be added to the document: 880 o Appendix with IRRTOOLSET examples 882 o Improve IRR section and clarify who should do what and 883 recommendations on object management 885 o Change "filters" in "import/export policies" 887 o Give rationale against community scrubbing 889 o Integrate comments of Donald Smith regarding TTL security and MD5/ 890 TCP-AO 892 12. Change logs 894 12.1. Diffs between draft-jdurand-bgp-security-01 and draft-jdurand- 895 bgp-security-00 897 Following changes have been made since previous document draft- 898 jdurand-bgp-security-00: 900 o "This documents" typo corrected in the former abstract 902 o Add normative reference for RFC5082 in former section 3.2 903 o "Non routable" changed in title of former section 4.1.1 905 o Correction of typo for IPv4 loopback prefix in former section 906 4.1.1.1 908 o Added shared transition space 100.64.0.0/10 in former section 909 4.1.1.1 911 o Clarification that 2002::/16 6to4 prefix can cross network 912 boundaries in former section 4.1.1.2 914 o Rationale of 2000::/3 explained in former section 4.1.1.2 916 o Added 3FFE::/16 prefix forgotten initially in the simplified list 917 of prefixes that MUST not be routed by definition in former 918 section 4.1.1.2 920 o Warn that filters for prefixes not allocated by IANA MUST only be 921 done if regular refresh is guaranteed, with some words about the 922 IPv4 experience, in former section 4.1.2.1 924 o Replace RIR database with IRR. A definition of IRR is added in 925 former section 4.1.2.2 927 o Remove any reference to anti-spoofing in former section 4.1.4 929 o Clarification for IXP LAN prefix and pMTUd problem in former 930 section 4.1.5 932 o "Autonomous filters" typo (instead of Autonomous systems) 933 corrected in the former section 4.2 935 o Removal of an example for manual address validation in former 936 section 4.2.2.1 938 o RFC5735 obsoletes RFC3300 940 o Ingress/Egress replaced by Inbound/Outbound in all the document 942 12.2. Diffs between draft-jdurand-bgp-security-02 and draft-jdurand- 943 bgp-security-01 945 Following changes have been made since previous document draft- 946 jdurand-bgp-security-01: 948 o 2 documentation prefixes were forgotten due to errata in RFC5735. 949 But all prefixes were removed from that document which now point 950 to other references for sake of not creating a new "registry" that 951 would become outdated sooner or later 953 o Change MD5 section with global TCP security session and 954 introducing TCP-AO in former section 3.1. Added reference to 955 BCP38 957 o Added new section 3 about BGP router protection with forwarding 958 plane ACL 960 o Change text about prefix acceptable specificity in former section 961 4.1.3 to explain this doc does not try to make recommendations 963 o Refer as much as possible to existing registries to avoid creating 964 a new one in former section 4.1.1.1 and 4.1.1.2 966 o Abstract reworded 968 o 6to4 exception described (only more specifics MUST be filtered) 970 o More specific -> more specifics 972 o should -> MUST for the prefixes an ISP needs to filter from its 973 customers in former section 4.2.2.1 975 o Added "plus some headroom to permit growth" in former section 7 977 o Added new section on Next-Hop filtering 979 12.3. Diffs between draft-ietf-opsec-bgp-security-00 and draft-jdurand- 980 bgp-security-02 982 Following changes have been made since previous document draft- 983 jdurand-bgp-security-02: 985 o Added a subsection for RTBH in next-hop section with reference to 986 RFC6666 988 o Changed last sentence of introduction 990 o Many edits throughout the document 992 o Added definition of tier 1 transit provider 994 o Removed definition of a BGP peering 996 o Removed description of routing policies for IPv6 prefixes in IANA 997 special registry as this now contains a routing scope field 999 o Added reference to RFC6598 and changed the IPv4 prefixes to be 1000 filtered by definition section 1002 o IXP added in accronym/definition section and only term used 1003 throughout the doc now 1005 12.4. Diffs between draft-ietf-opsec-bgp-security-01 and draft-ietf- 1006 opsec-bgp-security-00 1008 Following changes have been made since previous document draft-ietf- 1009 opsec-bgp-security-00: 1011 o Obsolete RFC2385 moved from normative to informative reference 1013 o Clarification of preference of TCP-AO over MD5 in former section 1014 4.1 1016 o Mentioning KARP efforts in TCP session protection section in 1017 former section 4 and adding 3 RFC as informative references: 6518, 1018 6862 and 6952 1020 o Removing reference to SIDR working-group 1022 o Better dissociating origin validation and path validation to 1023 clarify what's potentially available for deployment 1025 o Adding that SIDR mechanisms should be implemented in addition to 1026 the other ones mentioned throughout this document 1028 o Added a paragraph in former section 8 about ASN renumbering 1030 o Change of security considerations section 1032 o Added the newly created IANA IPv4 Special Purpose Address Registry 1033 instead of references to RFCs listing these addresses 1035 12.5. Diffs between draft-ietf-opsec-bgp-security-02 and draft-ietf- 1036 opsec-bgp-security-01 1038 Following changes have been made since previous document draft-ietf- 1039 opsec-bgp-security-01: 1041 o Added a reference to draft-ietf-sidr-origin-ops 1043 o Added a reference to RFC6811 and RFC6907 1045 o Changes "Most of RIR's" to "A majority of RIR's" on IRR 1046 availability 1048 o Various edits 1050 o Added NIST BGP security recommendations document 1052 o Added that it's possible to get info from ISPs from RADB 1054 o Correction of the url for IPv4 special use prefixes repository 1056 o Clarification of the fact only prefixes with Global Scope set to 1057 False MUST be discarded 1059 o IANA list could be pulled directly by routers (not just pushed on 1060 routers). 1062 o Warning added when prefixes are checked against IRR 1064 o Recommend network operators to sign their routing objects 1066 o Recommend network operators to publish their routing objects in 1067 IRR of their IRR when available 1069 o Dissociate rules for local AS and downstreams in former section 1070 5.1.4 1072 13. Acknowledgements 1074 The authors would like to thank the following people for their 1075 comments and support: Marc Blanchet, Ron Bonica, Randy Bush, David 1076 Freedman, Wesley George, Daniel Ginsburg, David Groves, Mike Hugues, 1077 Joel Jaeggli, Tim Kleefass, Warren Kumari, Jacques Latour, Jerome 1078 Nicolle, Hagen Paul Pfeifer, Thomas Pinaud, Carlos Pignataro, Jean 1079 Rebiffe, Donald Smith, Kotikalapudi Sriram, Matjaz Straus, Tony 1080 Tauber, Gunter Van de Velde, Sebastian Wiesinger, Matsuzaki 1081 Yoshinobu. 1083 Authors would like to thank once again Gunter Van de Velde for 1084 presenting the draft at several IETF meetings in various working 1085 groups, indeed helping dissemination of this document and gathering 1086 of precious feedback. 1088 14. IANA Considerations 1090 This memo includes no request to IANA. 1092 15. Security Considerations 1094 This document is entirely about BGP operational security. It depicts 1095 best practices that one should adopt adopt to secure its BGP 1096 infrastructure: protecting BGP router and BGP sessions, adopting 1097 consistent BGP prefix and AS-path filters and configure other options 1098 to secure the BGP network. 1100 On the other hand this document doesn't aim at depicting existing BGP 1101 implementations and their potential vulnerabilities and ways they 1102 handle errors. It will not detail how protection could be enforced 1103 against attack techniques using crafted packets. 1105 16. References 1107 16.1. Normative References 1109 [1] Bradner, S., "Key words for use in RFCs to Indicate 1110 Requirement Levels", BCP 14, RFC 2119, March 1997, 1111 . 1113 [2] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1114 June 1999. 1116 [3] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1117 via IPv4 Clouds", RFC 3056, February 2001. 1119 [4] Huitema, C. and B. Carpenter, "Deprecating Site Local 1120 Addresses", RFC 3879, September 2004. 1122 [5] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1123 Addresses", RFC 4193, October 2005. 1125 [6] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1126 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1128 [7] Hinden, R. and S. Deering, "IP Version 6 Addressing 1129 Architecture", RFC 4291, February 2006. 1131 [8] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1132 Network Address Translations (NATs)", RFC 4380, February 1133 2006. 1135 [9] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 1136 Pignataro, "The Generalized TTL Security Mechanism 1137 (GTSM)", RFC 5082, October 2007. 1139 [10] Touch, J., Mankin, A., and R. Bonica, "The TCP 1140 Authentication Option", RFC 5925, June 2010. 1142 [11] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 1143 Austein, "BGP Prefix Origin Validation", RFC 6811, January 1144 2013. 1146 [12] "Internet Exchange Route Server", . 1149 16.2. Informative References 1151 [13] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1152 Specifications: ABNF", RFC 2234, November 1997. 1154 [14] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1155 Signature Option", RFC 2385, August 1998. 1157 [15] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1158 Defeating Denial of Service Attacks which employ IP Source 1159 Address Spoofing", BCP 38, RFC 2827, May 2000. 1161 [16] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 1162 Reserved for Documentation", RFC 3849, July 2004. 1164 [17] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, 1165 "Routing Policy Specification Language next generation 1166 (RPSLng)", RFC 4012, March 2005. 1168 [18] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1169 Specifications: ABNF", RFC 4234, October 2005. 1171 [19] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, 1172 April 2008. 1174 [20] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 1175 RFC 5735, January 2010. 1177 [21] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 1178 Reserved for Documentation", RFC 5737, January 2010. 1180 [22] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1181 Router Control Plane", RFC 6192, March 2011. 1183 [23] Lepinski, M. and S. Kent, "An Infrastructure to Support 1184 Secure Internet Routing", RFC 6480, February 2012. 1186 [24] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 1187 Routing Protocols (KARP) Design Guidelines", RFC 6518, 1188 February 2012. 1190 [25] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 1191 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 1192 Space", BCP 153, RFC 6598, April 2012. 1194 [26] Hilliard, N. and D. Freedman, "A Discard Prefix for IPv6", 1195 RFC 6666, August 2012. 1197 [27] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and 1198 Authentication for Routing Protocols (KARP) Overview, 1199 Threats, and Requirements", RFC 6862, March 2013. 1201 [28] Manderson, T., Sriram, K., and R. White, "Use Cases and 1202 Interpretations of Resource Public Key Infrastructure 1203 (RPKI) Objects for Issuers and Relying Parties", RFC 6907, 1204 March 2013. 1206 [29] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1207 BGP, LDP, PCEP, and MSDP Issues According to the Keying 1208 and Authentication for Routing Protocols (KARP) Design 1209 Guide", RFC 6952, May 2013. 1211 [30] Smith, P. and C. Panigl, "RIPE-378 - RIPE Routing Working 1212 Group Recommendations On Route-flap Damping", May 2006. 1214 [31] Smith, P., Evans, R., and M. Hughes, "RIPE-399 - RIPE 1215 Routing Working Group Recommendations on Route 1216 Aggregation", December 2006. 1218 [32] Smith, P. and R. Evans, "RIPE-532 - RIPE Routing Working 1219 Group Recommendations on IPv6 Route Aggregation", November 1220 2011. 1222 [33] Smith, P., Bush, R., Kuhne, M., Pelsser, C., Maennel, O., 1223 Patel, K., Mohapatra, P., and R. Evans, "RIPE-580 - RIPE 1224 Routing Working Group Recommendations On Route-flap 1225 Damping", January 2013. 1227 [34] Doering, G., "IPv6 BGP Filter Recommendations", November 1228 2009, . 1230 [35] "IANA IPv6 Address Space", . 1233 [36] "IANA IPv4 Special Purpose Address Registry", 1234 . 1238 [37] "IANA IPv6 Special Purpose Address Registry", 1239 . 1243 [38] "IANA IPv4 Address Space Registry", . 1246 [39] "IANA IPv6 Address Space Registry", . 1250 [40] "Routing Assets Database", . 1252 [41] "Making Route Flap Damping Usable", . 1255 [42] "Security Requirements for BGP Path Validation", 1256 . 1259 [43] "Threat Model for BGP Path Security", 1260 . 1263 [44] "Autonomous System (AS) Migration Features and Their 1264 Effects on the BGP AS_PATH Attribute", 1265 . 1268 [45] "RPKI-Based Origin Validation Operation", 1269 . 1272 [46] , , and , "Border Gateway Protocol Security", 1273 . 1276 Authors' Addresses 1277 Jerome Durand 1278 CISCO Systems, Inc. 1279 11 rue Camille Desmoulins 1280 Issy-les-Moulineaux 92782 CEDEX 1281 FR 1283 Email: jerduran@cisco.com 1285 Ivan Pepelnjak 1286 NIL Data Communications 1287 Tivolska 48 1288 Ljubljana 1000 1289 Slovenia 1291 Email: ip@ipspace.net 1293 Gert Doering 1294 SpaceNet AG 1295 Joseph-Dollinger-Bogen 14 1296 Muenchen D-80807 1297 Germany 1299 Email: gert@space.net