idnits 2.17.1 draft-savola-rtgwg-backbone-attacks-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 709. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 720. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 727. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 733. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 384: '...ed protocol port MUST be sent with TTL...' RFC 2119 keyword, line 385: '...ient's behaviour SHOULD be configurabl...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 12, 2006) is 6469 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-opsec-current-practices-05 == Outdated reference: A later version (-10) exists of draft-ietf-rtgwg-rfc3682bis-05 == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-00 == Outdated reference: A later version (-06) exists of draft-ietf-tcpm-tcp-antispoof-04 == Outdated reference: A later version (-05) exists of draft-iab-dos-04 == Outdated reference: A later version (-12) exists of draft-ietf-mboned-routingarch-04 == Outdated reference: A later version (-09) exists of draft-ietf-opsec-filter-caps-01 == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcpsecure-05 Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Area WG P. Savola 3 Internet-Draft CSC/FUNET 4 Intended status: Informational July 12, 2006 5 Expires: January 13, 2007 7 Backbone Infrastructure Attacks and Protections 8 draft-savola-rtgwg-backbone-attacks-02.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 13, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 A number of countermeasures for attacks against service provider 42 backbone network infrastructure have been specified or proposed, each 43 of them usually targeting a subset of the problem space. There has 44 never been a more generic analysis of the actual problems, and which 45 countermeasures are even necessary (and where). This document tries 46 to provide that higher-level view. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 52 1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4 53 1.3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Attack Vectors . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2.1. Lower-layer Attacks . . . . . . . . . . . . . . . . . . . 5 56 2.2. Generic DoS on the Router . . . . . . . . . . . . . . . . 5 57 2.3. Generic DoS on a Link . . . . . . . . . . . . . . . . . . 6 58 2.4. Cryptographic Exhaustion Attacks . . . . . . . . . . . . . 6 59 2.5. Unauthorized Neighbor or Routing Attacks . . . . . . . . . 6 60 2.6. TCP RST Attacks . . . . . . . . . . . . . . . . . . . . . 7 61 2.7. ICMP Attacks . . . . . . . . . . . . . . . . . . . . . . . 7 62 3. Typical Countermeasures . . . . . . . . . . . . . . . . . . . 7 63 3.1. Filtering Addresses in Packets . . . . . . . . . . . . . . 7 64 3.2. Filtering Addresses in Routing Updates . . . . . . . . . . 8 65 3.3. GTSM . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 3.4. TCP-MD5 and Other Custom Authentication . . . . . . . . . 9 67 3.5. IPsec and IKE . . . . . . . . . . . . . . . . . . . . . . 9 68 4. Protocol Analysis . . . . . . . . . . . . . . . . . . . . . . 9 69 4.1. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 4.2. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 4.3. BFD . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 4.4. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 4.5. Multicast Protocols (PIM, MSDP) . . . . . . . . . . . . . 11 74 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 80 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 Intellectual Property and Copyright Statements . . . . . . . . . . 16 84 1. Introduction 86 A number of countermeasures for attacks against service provider 87 backbone network infrastructure have been specified or proposed, each 88 of them usually targeting a subset of the problem space. There has 89 never been a more generic analysis of the actual problems, and which 90 countermeasures are even necessary (and where). This document tries 91 to provide that higher-level view. 93 The scope of this document are backbone infrastructures and the 94 critical protocols that are required to function for legitimate 95 traffic to be correctly forwarded through the network. As such, 96 other important services or applications required by infrastructure 97 elements such as RADIUS, NTP, remote access, syslog, SNMP, and DNS 98 are out of scope. All such components should be adequately protected 99 through appropriate measures, the most important of which are proper 100 address and route filtering and restricting authorized access. 102 Additionally, the network might run additional routing protocols that 103 are not described in this memo, such as (G)MPLS, RSVP-TE or LDP. 105 1.1. Abbreviations 107 We exclude the common abbreviations such as TCP, ICMP and DNS. 109 BGP Border Gateway Protocol 110 BFD Bidirectional Forwarding Detection 111 DoS Denial of Service 112 DSCP DiffServ Code Point 113 GTSM Generalized TTL Security Mechanism 114 IGP Interior Gateway Protocol 115 IKE Internet Key Exchange 116 IRR Internet Routing Registry 117 IS-IS Integrated System - Integrated System (routing protocol) 118 LDP Label Distribution Protocol 119 (G)MPLS (Generalized) Multi-Protocol Label Switching 120 MSDP Multicast Source Discovery Protocol 121 NTP Network Time Protocol 122 OSPF Open Shortest Path First 123 PIM Protocol Independent Multicast 124 RADIUS Remote Authentication Dial-In User Service 125 RSVP-TE Resource Reservation Protocol - Traffic Engineering 126 SNMP Simple Network Management Protocol 128 1.2. Assumptions 130 This document assumes that the service provider is doing at least 131 some form of address filtering at its border devices, i.e., by 132 ensuring that only the infrastructure nodes can use infrastructure 133 source IP addresses to talk to the other nodes in the infrastructure. 134 So, for example, if a router sees an IP packet coming from a source 135 address assigned to another router in the backbone, it can be sure 136 the packet has been originated inside the backbone (assuming the 137 physical security or nodes in the backbone have not been subverted). 139 NOTE: many SP networks do not fulfill this assumption, often due to 140 (1) legacy equipment which is not capable of line-rate filtering, 141 and/or (2) very large network with hundreds or even thousands of 142 devices is considered just too big to guard at the borders (and 143 sometimes can't be broken down to several smaller ones). Analysis of 144 this document does not and will not intend to cover these networks as 145 the problem space is substantially different and other approaches are 146 warranted. For example, [I-D.zinin-rtg-dos] suggested an alternative 147 and provides good analysis; cryptographic protection of all the 148 control traffic may be an option if "all bets are off". 150 This requirement can be satisfied by applying ingress filtering at 151 all the ISP borders [RFC2827][RFC3704] for example, using feasible 152 path strict uRPF towards customers and ingress access lists towards 153 peers and upstreams. However, just filtering the infrastructure IP 154 addresses used as source addresses from the outside is also 155 sufficient. Some may even implement this by blocking access to the 156 infrastructure destination addresses at the border, but this document 157 doesn't describe this approach as that has a number of other issues. 159 Current operational practices are described in 160 [I-D.ietf-opsec-current-practices]. Various filtering capabilities 161 have been discussed at more length in [I-D.ietf-opsec-filter-caps]. 163 1.3. Threat Model 165 In the context of this document, threats are assumed to come from 166 external sources, either from customers or other networks. The 167 typical attacks are either meant to cause some form of denial of 168 service or simply cause collateral damage, such as: 170 o DoS attacks directed at infrastructure (e.g., TCP RSTs, ICMP 171 attacks), 173 o Collateral damage from DoS and other attacks directed at someone 174 else but causing harm to infrastructure or service (e.g., too much 175 traffic exceeds forwarding or control processor capacity), or 177 o Hijacking attacks (e.g., unauthorized routing advertisement, 178 access control attempt with a spoofed address). 180 Other possible attack vectors but which are considered out of scope 181 include: 183 o ISP's systems being compromised through unauthorized access, 184 system vulnerability, etc., 186 o Inside attacks (e.g., compromised personnel), 188 o Lower-layer attacks as described in Section 2.1. 190 While not perfect solutions, these can all be mitigated to some 191 degree by controls and automatic configuration audits. As such the 192 first order priority problems typically come from external sources. 194 2. Attack Vectors 196 This Section describes the most obvious attack vectors. Many of 197 these are also described in [I-D.iab-dos]. 199 2.1. Lower-layer Attacks 201 If an attacker has access to a (physical) link, it can obviously 202 cause downtime for the link. In many cases the downtime is not a 203 critical threat, as it can be quickly noticed, traffic rerouted, and 204 the problem fixed. Some ISPs are more concerned about other forms of 205 attacks: insertion of eavesdropping or man-in-the-middle devices. 206 Fortunately, installing such would require downtime, and insertion 207 could be noticeable, e.g., as an unscheduled issue gets fixed on its 208 own. 210 However, a lower-layer attack is not specific to routing protocols. 211 An attacker could just violate integrity or confidentiality of 212 regular packets, instead of tampering with routing. As such, if a 213 lower-layer attack is deemed a concern, full protection for all the 214 traffic should be provided and therefore this threat is not addressed 215 in this document. 217 2.2. Generic DoS on the Router 219 A typical attack is to overload a router using various techniques, 220 e.g., by sending traffic exceeding the router's forwarding capacity, 221 sending special transit packets that go through a "slow-path" 222 processing (such functions may also come with problems of their own 223 [BLOCKED]), or by sending some packets directed at the router itself 224 (e.g., to exceed the input queue for CPU processing). 226 Many of these techniques can be mitigated using implementation- 227 specific rate-limiting mechanisms, so they are not addressed further 228 in this memo. However, protocol designers should be advised to avoid 229 any designs that require noticing and processing any special packets 230 from the transit traffic (e.g., messages marked with router alert 231 option). 233 2.3. Generic DoS on a Link 235 Overloading the capacity of a link is often more difficult to prevent 236 than a router DoS. Traffic is typically not automatically rerouted 237 and even if it was, doing so could make the issue worse unless there 238 is ample spare capacity. 240 Mitigation methods include monitoring the usage status of links, 241 prioritizing or deprioritizing certain kinds of traffic using DSCPs, 242 or devising some form of rate-limiters. 244 2.4. Cryptographic Exhaustion Attacks 246 A special form of DoS are attacks which target a protocol that uses 247 cryptographic mechanisms, for example TCP-MD5 or IPsec. The attacker 248 sends valid protocol messages with cryptographic signatures or other 249 properties to the router, which is forced to perform cryptographic 250 validation of the message. If the cryptographic operations are 251 computationally expensive, the attack might succeed easier than with 252 other generic DoS mechanisms. Cryptographic protocols employing 253 primitives such as stateless cookies, puzzles or return routability 254 are typically more resistant to this kind of attacks. 256 Some implementation-specific mitigation techniques (rate-limiting 257 etc.) have been deployed. Protocol design should take these attacks 258 into account. 260 2.5. Unauthorized Neighbor or Routing Attacks 262 Unauthorized nodes can obtain a routing protocol adjacency on links 263 where an IGP has been enabled by misconfiguration, or where 264 authentication is not used. This may result in many different kinds 265 of attacks, for example traffic redirection 266 [I-D.ietf-rpsec-routing-threats]. 268 At least in theory, while it may not be possible to establish an 269 adjacency from outside the link, it may be possible to inject packets 270 as if the adjacency had been established (e.g., OSPF in Section 4.1.2 271 of [I-D.ietf-rpsec-ospf-vuln]). 273 Protocols such as BGP and MSDP that process routing information from 274 untrusted, external sources may also be attacked, for example by an 275 unauthorized advertisement of a prefix. 277 Special care needs to be made to ensure that unauthorized neighbors 278 are prevented (e.g., by regular configuration audits and OSPF 279 protocol filtering at borders). On the other hand, routing attack 280 threats from valid neighbors can be slightly mitigated via 281 appropriate route filtering. 283 2.6. TCP RST Attacks 285 TCP sessions can be closed by attackers that can send a TCP RST 286 packet with guessed spoofed endpoint identifiers and a sufficiently 287 close sequence number. The attacks and defenses have been described 288 at length in [I-D.ietf-tcpm-tcp-antispoof]. One particular approach 289 is modifying the TCP state machine [I-D.ietf-tcpm-tcpsecure]. 291 2.7. ICMP Attacks 293 A slightly newer attack is employing ICMP by sending an ICMP type 294 that indicates a hard error condition. ICMP errors must be 295 propagated to the upper layer, and most applications heed the errors 296 as they should by closing a connection or session. ICMP attacks and 297 defenses against TCP have been extensively described in 298 [I-D.ietf-tcpm-icmp-attacks]. Most TCP stacks have since then been 299 fixed [CVE]. 301 It is also possible to execute ICMP attacks against other protocols 302 such as UDP or IPsec, but the impact and whether/how these protocols 303 demultiplex received errors have not been extensively studied. IPsec 304 is protected by ICMP attacks through a number of assumptions (e.g., 305 that only ICMP errors from the end-point are accepted) or manual 306 configuration. 308 3. Typical Countermeasures 310 This Section describes some of the most common countermeasures 311 applied today. This just introduces the techniques; the afforded 312 protection is analyzed in Section 4 in the context of each protocol. 314 3.1. Filtering Addresses in Packets 316 As described in the first section, this document assumes that the 317 internal infrastructure is secure from spoofed messages that purport 318 to come from inside the infrastructure. More fine-grained, router- 319 specific filters are sometimes deployed as well. 321 It is possible to hide the infrastructure by using private or non- 322 advertised addressing, but this has numerous drawbacks such as 323 breaking address filtering and traceroute, not protecting from the 324 ISP's customers that use a default route, etc. so this document 325 doesn't recommand doing so. 327 In addition, it may also make sense to ensure that egress packets 328 have the ISP's own source addresses and/or that ingress packets 329 arrive with either multicast/broadcast or ISP's own destination 330 addresses. These ensure that in case your own filtering fails, no 331 bad traffic leaks out and prevent certain classes of abuse from peers 332 (e.g., stealing transit by static routing). 334 3.2. Filtering Addresses in Routing Updates 336 Similar principles as used in address filtering can be used to 337 mitigate routing attacks. Specifically, reject any equal or more 338 specific incoming routing advertisements to the ISP's address space 339 unless explicitly authorized. Further, monitor the filtered prefixes 340 and use public services (such as RIPE's MyASN [MYASN]) to monitor the 341 correctness of advertisements globally. 343 As with address filtering, such routing advertisements might still be 344 processed by other networks, but at least these steps prevent 345 hijacking inside the ISP's own network and allow monitoring of most 346 unauthorized attempts. 348 It may also make sense to filter out in a similar fashion the 349 advertisements or more specifics of IX peering blocks where the ISP 350 connects to. These could be advertised by an attacker to mess up 351 forwarding next-hops. 353 In addition, especially in regions where the operational practice is 354 to keep Internet Routing Registry (IRR) in sync, it may be possible 355 to restrict the prefixes accepted from a peer or a customer to an 356 automatically generated list. In any case, many operators define a 357 maximum prefix limit per peer (which typically resets the session if 358 exceeded) to prevent misconfiguration (e.g., unintentional 359 deaggregation) or overload attacks. 361 3.3. GTSM 363 GTSM [I-D.ietf-rtgwg-rfc3682bis] is a technique where the sender of a 364 packet sets the TTL/Hop Count to 255 and the receiver verifies it's 365 still 255 (or some other preconfigured value). GTSM can be used to 366 protect from off-link attacks (especially spoofing). This applies 367 when GTSM-enabled control traffic is inside a single link: any 368 packets coming from outside the link can summarily be discarded as 369 they have a TTL/Hop Count smaller than 255. 371 The open issue at the moment is how GTSM handles TCP RSTs. I.e., 372 should it require that RSTs for a GTSM-enabled session should be sent 373 with TTL=255 and verified to come with TTL=255 (or a configured 374 value)? Some implementations already send out all packets with 375 TTL=255, but receipt verification is not performed. Is there a 376 sensible transition plan or need to make a change if any? Note that 377 this has only limited impact on GTSM's security as other TCP RST 378 mitigation techniques still apply. 380 NOTE IN DRAFT: the following paragraph should be removed in a future 381 revision, to be placed to the GTSMbis draft. 383 We suggest that the GTSM spec is amended so that TCP RSTs relating to 384 a GTSM-enabled protocol port MUST be sent with TTL=255. The 385 recipient's behaviour SHOULD be configurable, and it is RECOMMENDED 386 that the default be to discard messages where TTL is not 255 (or 255- 387 TrustRadius). 389 3.4. TCP-MD5 and Other Custom Authentication 391 At least BGP, MSDP, and LDP are able to use the TCP-MD5 signature 392 option to verify the authenticity of control packets. TCP-MD5 uses 393 manually configured static keys, and changing them must be a 394 coordinated event to prevent session reset. Due to the operational 395 cost of re-keying, the solution is sub-optimal in cases where (rather 396 paranoid) security procedures require (e.g., after an employee leaves 397 the organization) that the keys must be easily and often changeable. 399 Using TCP-MD5 and other similar authentication mechanisms (e.g., for 400 IGPs or BFD) also opens an attack vector for cryptographic exhaustion 401 attacks unless implementations have appropriate mechanisms to 402 throttle or otherwise manage heavy cryptographic operations. 404 3.5. IPsec and IKE 406 IPsec and IKE have been proposed as a more comprehensive 407 countermeasure, but these protocols also require a lot of heavyweight 408 protocol machinery, lots of configuration, and cryptographic 409 processing. Vendors have also expressed difficulty in applying IPsec 410 to control traffic protection. 412 4. Protocol Analysis 414 This Section briefly discusses the protocol-specific attack 415 properties below. 417 ICMP attacks apply to all the IP protocols at least to some degree. 418 There is no reasonable way to appropriately protect from these 419 attacks by operative methods such as filtering: the vendors should 420 implement countermeasures described in [I-D.ietf-tcpm-icmp-attacks] 421 to mitigate these attacks. 423 4.1. OSPF 425 OSPF attacks have already been analyzed [I-D.ietf-rpsec-ospf-vuln]. 426 In this context the most important of them are preventing (1) 427 misconfiguration and unauthorized neighbors, and (2) off-path 428 directed attacks as described in Section 4.1.2 of 429 [I-D.ietf-rpsec-ospf-vuln]. 431 The former requires configuration change procedures and regular 432 audits of OSPF configuration, and disabling OSPF adjacencies on 433 customer-facing links, or adding authentication when there are 434 multiple routers. The latter requires using OSPF authentication, 435 dropping all OSPF traffic at all the borders, or moving to another, 436 less vulnerable protocol (e.g., IS-IS). 438 OSPF is also used to some degree with provider-provisioned VPNs by 439 the customers. In such scenarios, strict route filtering needs to be 440 applied to ensure only the valid prefixes are accepted. 442 4.2. IS-IS 444 Routing IP with IS-IS has gained popularity in the backbone networks 445 lately. As IS-IS does not use IP as its control protocol, external 446 attackers cannot attack IS-IS in the same way as they can attack 447 OSPF. Hence it is sufficient to prevent misconfiguration and 448 unauthorized neighbors, using similar countermeasures as with OSPF: 449 configuration change procedures and regular configuration audits and 450 disabling IS-IS adjacencies on customer-facing links, or adding 451 authentication when there are multiple routers. 453 4.3. BFD 455 Bidirectional Forwarding Detection (BFD) detects faults in the 456 forwarding path between two endpoints. As a generic mechanism, it 457 can be applied to a number of protocols (e.g., OSPF, IS-IS, BGP, 458 MPLS, or static routes). 460 When BFD is in use for a single-hop scenario, it uses GTSM to protect 461 from off-link attackers. Authentication can also be used for example 462 on untrusted links. 464 4.4. BGP 466 Internal BGP sessions run between loopback addresses. There is no 467 need to run TCP-MD5 for outsider protection as address filtering will 468 avoid TCP RST attacks. 470 External BGP sessions may run multi-hop between loopback addresses or 471 single-hop between interface addresses. The latter case is much more 472 common and easier to protect and applying GTSM provides first-order 473 resistance to off-link attackers. 475 In any case, assuming address filtering, the session can only be 476 reset by the peer, or by attacks from the direction of the peer's 477 network (e.g., through lack of peer's border filtering). One can 478 therefore question the necessity of further protection as the peer 479 can only shoot itself in the foot by killing the BGP session or 480 allowing the BGP session be killed through negligence. 482 There is one exception to the above: if the customer is multihomed 483 through multiple ISPs and the addresses used for the peering session 484 are from the customer's address block. In such scenarios, using each 485 ISP's respective addresses for the peering link might be the simplest 486 approach. 488 If the link is not trusted (e.g., in some large Ethernet-based 489 Internet Exchange points), it may also be desirable to ensure that 490 peers are not able to reset others' sessions, so a mechanism like 491 TCP-MD5 may be appropriate. One should note that the security 492 requirements are not necessarily very high as the attacker should 493 already be easily traceable on a single link, and thus re-keying may 494 not be worth the trouble. 496 As BGP processes data heard from external sources, the routing data 497 can be modified in numerous ways, e.g., to create arbitrarily complex 498 advertisements using path attributes to crash naive BGP 499 implementations. These and many other BGP attacks are described in 500 [RFC4272]. Techniques described in Section 3.2 can mitigate the 501 attack vectors to some degree, but a more comprehensive solution to 502 securing routing data is needed. 504 4.5. Multicast Protocols (PIM, MSDP) 506 Multicast routing is typically achieved by PIM-SM 507 [I-D.ietf-mboned-routingarch]. MSDP is used for IPv4 source 508 discovery. Multicast routing protocol threats have been analyzed 509 separately in [I-D.ietf-mboned-mroutesec] (backbone perspective) and 510 [I-D.savola-pim-lasthop-threats] (last-hop perspective). 512 In summary, most of the multicast threats pertain to overloading 513 control processors via too much state. Implementation-specific rate- 514 limiters can help in mitigating the risk. If resetting MSDP sessions 515 is a concern, TCP-MD5 option similar to BGP can be used. Address 516 filtering can be applied in particular in PIM Unicast-Register 517 message decapsulation; other messages use multicast and already 518 employ reverse path forwarding checks. 520 5. Summary 522 IGPs require a great deal of care to ensure that they are not enabled 523 on links where they shouldn't be. Preventing external OSPF attacks 524 also requires OSPF authentication everywhere or filtering OSPF 525 packets at the edges. 527 ICMP attacks are able to cause a great deal of harm to almost all the 528 protocols, including IPsec, and there is little to do to mitigate the 529 risk except to implement enhanced ICMP payload verification/ 530 processing techniques. More study of the impact on connectionless 531 protocols and IPsec should be conducted. 533 With border address filtering in place, internal sessions are 534 reasonably safe. With additional GTSM protection, external private 535 interconnection links are also reasonably safe, as the session can 536 only be reset by the neighbor or due to lack of filtering, someone 537 through the neighbor's network. TCP-MD5 protection is most 538 appropriate for Internet Exchange points with multiple neighbors or 539 multihop eBGP sessions, but it's worth remembering that the security 540 requirements for the solution are not very high as the attackers have 541 very strict topological restrictions. 543 IPsec and IKE are obviously an option for heavy-weight protection, 544 but impractical (yet) due to configuration complexity and processing 545 overhead. Simplifications in configuration, implementation, and 546 cryptographic hardware offloading might help the situation for the 547 cases where the use of heavier protection (e.g., possibly Internet 548 Exchange points) could be warranted. 550 6. IANA Considerations 552 This memo makes no request to IANA. 554 7. Acknowledgements 556 George Jones suggested improvements to the initial version of this 557 draft. Further feedback was received from Sean P. Turner, Seo Boon 558 NG, Warren Kumari, Hank Nussbacher, Jonathan Trostle, Iljitsch van 559 Beijnum, and Barry Greene. 561 8. Security Considerations 563 This document does not define a protocol but rather describes and 564 analyzes the security properties and countermeasures in existing 565 service provider backbone network infrastructures. 567 The most important issues that should be noted are its security 568 assumptions: 570 o We require at least certain degree of address filtering at 571 borders, or else all bets are off. This assumption is notably NOT 572 satisfied by a number of networks. 574 o The main concern is an external attack (from customers or some 575 other network); lower-layer attacks are not considered a 576 particular concern for routing protocols. 578 o Generic DoS attacks against routers can be mitigated using 579 implementation-specific measures. 581 There are a number of actions for network operators in order to 582 protect the network (e.g., filtering OSPF packets at the edges or 583 auditing IGP configurations). There are also lessons to be learned 584 for protocol designers (e.g., OSPF external attacks, ICMP attacks 585 against non-TCP, use of GTSM). Many of the issues listed also depend 586 on vendors to implement effective, vendor-specific rate-limiting 587 techniques. 589 9. References 591 9.1. Normative References 593 [I-D.ietf-mboned-mroutesec] 594 Savola, P., Lehtonen, R., and D. Meyer, "PIM-SM Multicast 595 Routing Security Issues and Enhancements", 596 draft-ietf-mboned-mroutesec-04 (work in progress), 597 October 2004. 599 [I-D.ietf-opsec-current-practices] 600 Kaeo, M., "Operational Security Current Practices", 601 draft-ietf-opsec-current-practices-05 (work in progress), 602 July 2006. 604 [I-D.ietf-rpsec-ospf-vuln] 605 Jones, E. and O. Moigne, "OSPF Security Vulnerabilities 606 Analysis", draft-ietf-rpsec-ospf-vuln-02 (work in 607 progress), June 2006. 609 [I-D.ietf-rpsec-routing-threats] 610 Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 611 Routing Protocols", draft-ietf-rpsec-routing-threats-07 612 (work in progress), October 2004. 614 [I-D.ietf-rtgwg-rfc3682bis] 615 Gill, V., "The Generalized TTL Security Mechanism (GTSM)", 616 draft-ietf-rtgwg-rfc3682bis-05 (work in progress), 617 April 2005. 619 [I-D.ietf-tcpm-icmp-attacks] 620 Gont, F., "ICMP attacks against TCP", 621 draft-ietf-tcpm-icmp-attacks-00 (work in progress), 622 February 2006. 624 [I-D.ietf-tcpm-tcp-antispoof] 625 Touch, J., "Defending TCP Against Spoofing Attacks", 626 draft-ietf-tcpm-tcp-antispoof-04 (work in progress), 627 May 2006. 629 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 630 Defeating Denial of Service Attacks which employ IP Source 631 Address Spoofing", BCP 38, RFC 2827, May 2000. 633 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 634 Networks", BCP 84, RFC 3704, March 2004. 636 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 637 RFC 4272, January 2006. 639 9.2. Informative References 641 [BLOCKED] Cisco Systems, "Cisco Security Advisory: Cisco IOS 642 Interface Blocked by IPv4 Packets", 2004, . 646 [CVE] CVE-2004-0790, "Multiple TCP/IP and ICMP implementations 647 allow remote attackers to cause a denial of service (reset 648 TCP connections) via spoofed ICMP error messages, aka the 649 "blind connection-reset attack."", 2004, . 652 [I-D.iab-dos] 653 Rescorla, E. and M. Handley, "Internet Denial of Service 654 Considerations", draft-iab-dos-04 (work in progress), 655 June 2006. 657 [I-D.ietf-mboned-routingarch] 658 Savola, P., "Overview of the Internet Multicast Routing 659 Architecture", draft-ietf-mboned-routingarch-04 (work in 660 progress), June 2006. 662 [I-D.ietf-opsec-filter-caps] 663 Morrow, C., "Filtering Capabilities for IP Network 664 Infrastructure", draft-ietf-opsec-filter-caps-01 (work in 665 progress), May 2006. 667 [I-D.ietf-tcpm-tcpsecure] 668 Stewart, R. and M. Dalal, "Improving TCP's Robustness to 669 Blind In-Window Attacks", draft-ietf-tcpm-tcpsecure-05 670 (work in progress), June 2006. 672 [I-D.savola-pim-lasthop-threats] 673 Lingard, J. and P. Savola, "Last-hop Threats to Protocol 674 Independent Multicast (PIM)", 675 draft-savola-pim-lasthop-threats-02 (work in progress), 676 June 2006. 678 [I-D.zinin-rtg-dos] 679 Zinin, A., "Protecting Internet Routing Infrastructure 680 from Outsider DoS Attacks", draft-zinin-rtg-dos-02 (work 681 in progress), May 2005. 683 [MYASN] RIPE NCC, "MyASn System", 684 . 686 Author's Address 688 Pekka Savola 689 CSC/FUNET 690 Espoo 691 Finland 693 Email: psavola@funet.fi 695 Full Copyright Statement 697 Copyright (C) The Internet Society (2006). 699 This document is subject to the rights, licenses and restrictions 700 contained in BCP 78, and except as set forth therein, the authors 701 retain all their rights. 703 This document and the information contained herein are provided on an 704 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 705 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 706 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 707 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 708 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 709 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 711 Intellectual Property 713 The IETF takes no position regarding the validity or scope of any 714 Intellectual Property Rights or other rights that might be claimed to 715 pertain to the implementation or use of the technology described in 716 this document or the extent to which any license under such rights 717 might or might not be available; nor does it represent that it has 718 made any independent effort to identify any such rights. Information 719 on the procedures with respect to rights in RFC documents can be 720 found in BCP 78 and BCP 79. 722 Copies of IPR disclosures made to the IETF Secretariat and any 723 assurances of licenses to be made available, or the result of an 724 attempt made to obtain a general license or permission for the use of 725 such proprietary rights by implementers or users of this 726 specification can be obtained from the IETF on-line IPR repository at 727 http://www.ietf.org/ipr. 729 The IETF invites any interested party to bring to its attention any 730 copyrights, patents or patent applications, or other proprietary 731 rights that may cover technology that may be required to implement 732 this standard. Please address the information to the IETF at 733 ietf-ipr@ietf.org. 735 Acknowledgment 737 Funding for the RFC Editor function is provided by the IETF 738 Administrative Support Activity (IASA).