idnits 2.17.1 draft-savola-rtgwg-backbone-attacks-01.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 658. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 669. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 676. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 682. ** 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 354: '...ed protocol port MUST be sent with TTL...' RFC 2119 keyword, line 357: '... SHOULD be configurable, and it is R...' 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 (June 13, 2006) is 6526 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-03 == Outdated reference: A later version (-02) exists of draft-ietf-rpsec-ospf-vuln-01 == 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 (-12) exists of draft-ietf-mboned-routingarch-03 == 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-04 == Outdated reference: A later version (-02) exists of draft-savola-pim-lasthop-threats-01 Summary: 4 errors (**), 0 flaws (~~), 10 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 June 13, 2006 5 Expires: December 15, 2006 7 Backbone Infrastructure Attacks and Protections 8 draft-savola-rtgwg-backbone-attacks-01.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 December 15, 2006. 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 . . . . . . . . . . . . . . . . . . 5 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. Address Filtering . . . . . . . . . . . . . . . . . . . . 7 64 3.2. Route Filtering . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.2. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 4.3. BFD . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 4.4. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 4.5. Multicast Protocols (PIM, MSDP) . . . . . . . . . . . . . 11 74 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 80 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 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 This requirement can be satisfied by applying ingress filtering at 140 all the ISP borders [RFC2827][RFC3704], but just filtering 141 infrastructure source IP addresses from the outside is also 142 sufficient. Some may even implement this by blocking access to the 143 infrastructure destination addresses at the border, but this document 144 doesn't describe this approach as that has a number of other issues. 146 Current operational practices are described in 147 [I-D.ietf-opsec-current-practices]; while almost all ISPs are capable 148 of employing data plane filtering at the edges, at least one major 149 ISP is known not do be able to due to legacy hardware limitations. 150 Various filtering capabilities have been discussed at more length in 151 [I-D.ietf-opsec-filter-caps]. 153 If this requirement cannot be satisfied, other approaches are 154 warranted. For example, [I-D.zinin-rtg-dos] suggested an alternative 155 (and in any case, provides good analysis); IPsec-protecting all the 156 control traffic may be an option if "all bets are off". 158 1.3. Threat Model 160 In the context of this document, threats are assumed to come from 161 external sources, either from customers or other networks. The 162 typical attacks are either meant to cause some form of denial of 163 service or to hijack or gain access to a service, such as: 165 o DoS attacks directed at infrastructure (e.g., TCP RSTs, ICMP 166 attacks), 168 o DoS attacks directed at someone else but cause harm (e.g., too 169 much traffic exceeds forwarding or control processor capacity), or 171 o Hijacking attacks (e.g., unauthorized routing advertisement, 172 access control attempt with a spoofed address). 174 Other possible attack vectors include inside attacks (e.g., 175 compromised personnel or inadequately protected infrastructure 176 device) and lower-layer attacks as described in Section 2.1. While 177 the insider attack could be devastating, it can be mitigated by 178 access controls and automatic configuration audits. As such the 179 first order priority problems typically come from external sources. 181 2. Attack Vectors 183 This Section describes the most obvious attack vectors. 185 2.1. Lower-layer Attacks 187 If an attacker has access to a (physical) link, it can obviously 188 cause downtime for the link. In many cases the downtime is not a 189 critical threat, as it can be quickly noticed, traffic rerouted, and 190 the problem fixed. Some ISPs are more concerned about other forms of 191 attacks: insertion of eavesdropping or man-in-the-middle devices. 192 Fortunately, installing such would require downtime, and insertion 193 could be noticeable, e.g., as an unscheduled issue gets fixed on its 194 own. 196 However, a lower-layer attack is not specific to routing protocols. 197 An attacker could just violate integrity or confidentiality of 198 regular packets, instead of tampering with routing. As such, if a 199 lower-layer attack is deemed a concern, full protection for all the 200 traffic should be provided and therefore this threat is not addressed 201 in this document. 203 2.2. Generic DoS on the Router 205 A typical attack is to overload a router using various techniques, 206 e.g., by sending traffic exceeding the router's forwarding capacity, 207 sending special transit packets that go through a "slow-path" 208 processing (such functions may also come with problems of their own 209 [BLOCKED]), or by sending some packets directed at the router itself. 211 Many of these techniques can be mitigated using implementation- 212 specific rate-limiting mechanisms, so they are not addressed further 213 in this memo. However, protocol designers should be advised to avoid 214 any designs that require noticing and processing any special packets 215 from the transit traffic (e.g., messages marked with router alert 216 option). 218 2.3. Generic DoS on a Link 220 Overloading the capacity of a link is often more difficult to prevent 221 than a router DoS. Traffic is typically not automatically rerouted 222 and even if it did, doing so could make the issue worse unless there 223 is ample spare capacity. 225 Mitigation methods include monitoring the usage status of links, 226 prioritizing or deprioritizing certain kinds of traffic using DSCPs, 227 or devising some form of rate-limiters. 229 2.4. Cryptographic Exhaustion Attacks 231 A special form of DoS are attacks which target a protocol that uses 232 cryptographic mechanisms, for example TCP-MD5 or IPsec. The attacker 233 sends valid protocol messages with cryptographic signatures or other 234 properties to the router, which is forced to perform cryptographic 235 validation of the message. If the cryptographic operations are 236 computationally expensive, the attack might succeed easier than with 237 other generic DoS mechanisms. Cryptographic protocols employing 238 primitives such as stateless cookies, puzzles or return routability 239 are typically more resistant to this kind of attacks. 241 Some implementation-specific mitigation techniques (rate-limiting 242 etc.) have been deployed, but as this affects the choice of a 243 countermeasure due to protocol design. 245 2.5. Unauthorized Neighbor or Routing Attacks 247 Unauthorized nodes can obtain a routing protocol adjacency on links 248 where an IGP has been enabled by misconfiguration, or where 249 authentication is not used. This may result in many different kinds 250 of attacks, for example traffic redirection 251 [I-D.ietf-rpsec-routing-threats]. 253 At least in theory, while it may not be possible to establish an 254 adjacency from outside the link, it may be possible to inject packets 255 as if the adjacency had been established (e.g., OSPF in Section 3.1.2 256 of [I-D.ietf-rpsec-ospf-vuln]). 258 Protocols such as BGP and MSDP that process routing information from 259 untrusted, external sources may also be attacked, for example by an 260 unauthorized advertisement of a prefix. 262 Special care needs to be made to ensure that unauthorized neighbors 263 are prevented (e.g., by regular configuration audits and OSPF 264 protocol filtering at borders). On the other hand, routing attack 265 threats from valid neighbors can be minimized via appropriate route 266 filtering. 268 2.6. TCP RST Attacks 270 TCP sessions can be closed by attackers that can send a TCP RST 271 packet with guessed spoofed endpoint identifiers and a sufficiently 272 close sequence number. The attacks and defenses have been described 273 at length in [I-D.ietf-tcpm-tcp-antispoof]. One particular approach 274 is modifying the TCP state machine [I-D.ietf-tcpm-tcpsecure]. 276 2.7. ICMP Attacks 278 A slightly newer attack is employing ICMP by sending an ICMP type 279 that indicates a hard error condition. ICMP errors must be 280 propagated to applications, and most applications heed the errors as 281 they should by closing a connection or session. ICMP attacks and 282 defenses against TCP have been extensively described in 283 [I-D.ietf-tcpm-icmp-attacks]. 285 It is also possible to execute ICMP attacks against other protocols 286 such as UDP or IPsec, but the impact and whether/how these protocols 287 demultiplex received errors have not been extensively studied. IPsec 288 is protected by ICMP attacks through a lot of assumptions (e.g., that 289 only ICMP errors from the end-point are accepted) or manual 290 configuration. 292 3. Typical Countermeasures 294 This Section describes some of the most common countermeasures 295 applied today. This just introduces the techniques; the afforded 296 protection is analyzed in Section 4 in the context of each protocol. 298 3.1. Address Filtering 300 As described in the first section, this document assumes that the 301 internal infrastructure is secure from spoofed messages that purport 302 to come from inside the infrastructure. More fine-grained, router- 303 specific filters are sometimes deployed as well. 305 It is possible to hide the infrastructure by using private or non- 306 advertised addressing, but this has numerous drawbacks such as 307 breaking address filtering and traceroute, not protecting from the 308 ISP's customers that use a default route, etc. so this document 309 doesn't recommand doing so. 311 3.2. Route Filtering 313 Similar principles as used in address filtering can be used to 314 mitigate routing attacks. Specifically, reject any equal or more 315 specific incoming routing advertisements to the ISP's address space 316 unless explicitly authorized. Further, monitor the filtered prefixes 317 and use public services (such as RIPE's MyASN [MYASN]) to monitor the 318 correctness of advertisements globally. 320 In addition, especially in regions where the operational practice is 321 to keep Internet Routing Registry (IRR) in sync, it may be possible 322 to restrict the prefixes accepted from a peer or a customer to an 323 automatically generated list. In any case, many operators define a 324 maximum prefix limit per peer (which typically resets the session if 325 exceeded) to prevent misconfiguration or overload attacks. 327 As with address filtering, such routing advertisements might still be 328 processed by other networks, but at least these steps prevent 329 hijacking inside the ISP's own network and allow monitoring of most 330 unauthorized attempts. 332 3.3. GTSM 334 GTSM [I-D.ietf-rtgwg-rfc3682bis] is a technique where the sender of a 335 packet sets the TTL/Hop Count to 255 and the receiver verifies it's 336 still 255 (or some other preconfigured value). GTSM can be used to 337 protect from off-link attacks (especially spoofing). This applies 338 when GTSM-enabled control traffic is inside a single link: any 339 packets coming from outside the link can summarily be discarded as 340 they have a TTL/Hop Count smaller than 255. 342 The open issue at the moment is how GTSM handles TCP RSTs. I.e., 343 should it require that RSTs for a GTSM-enabled session should be sent 344 with TTL=255 and verified to come with TTL=255 (or a configured 345 value)? Do implementations already do this? Is there a sensible 346 transition plan or need to make a change if any? Note that this has 347 only limited impact on GTSM's security as other TCP RST mitigation 348 techniques still apply. 350 NOTE IN DRAFT: the following paragraph should be removed in a future 351 revision, to be placed to the GTSMbis draft. 353 We suggest that the GTSM spec is amended so that TCP RSTs relating to 354 a GTSM-enabled protocol port MUST be sent with TTL=255. (Note that 355 this will require a kernel modification, and a means to specify to 356 the kernel which ports relate to GTSM.). The recipient's behaviour 357 SHOULD be configurable, and it is RECOMMENDED that the default be to 358 discard messages where TTL is not 255 (or 255-TrustRadius). 360 3.4. TCP-MD5 and Other Custom Authentication 362 At least BGP, MSDP, and LDP are able to use the TCP-MD5 signature 363 option to verify the authenticity of control packets. TCP-MD5 uses 364 manually configured static keys, so changing them typically resets 365 the protocol session, so the solution is sub-optimal in cases where 366 the security procedures require (e.g., after an employee leaves the 367 organization) that the keys must be easily and often changeable. 369 Using TCP-MD5 and other similar authentication mechanisms (e.g., for 370 IGPs or BFD) also opens an attack vector for cryptographic exhaustion 371 attacks unless implementations have appropriate mechanisms to 372 throttle or otherwise manage heavy cryptographic operations. 374 3.5. IPsec and IKE 376 IPsec and IKE have been proposed as a more comprehensive 377 countermeasure, but these protocols also require a lot of heavyweight 378 protocol machinery, lots of configuration, and cryptographic 379 processing. Vendors have also expressed difficulty in applying IPsec 380 to control traffic protection. 382 4. Protocol Analysis 384 This Section briefly discusses the protocol-specific attack 385 properties below. 387 ICMP attacks apply to all the IP protocols at least to some degree. 388 There is no reasonable way to appropriately protect from these 389 attacks by operative methods: the vendors should implement 390 countermeasures described in [I-D.ietf-tcpm-icmp-attacks] to mitigate 391 these attacks. 393 4.1. OSPF 395 OSPF attacks have already been analyzed [I-D.ietf-rpsec-ospf-vuln]. 396 In this context the most important of them are: (1) preventing 397 misconfiguration and unauthorized neighbors, and (2) ensuring off- 398 path directed attacks as described in Section 3.1.2 of 399 [I-D.ietf-rpsec-ospf-vuln]. 401 The former requires configuration change procedures and regular 402 audits of OSPF configuration, and disabling OSPF adjacencies on 403 customer-facing links, or adding authentication when there are 404 multiple routers. The latter requires using OSPF authentication, 405 dropping all OSPF traffic at all the borders, or moving to another, 406 less vulnerable protocol (e.g., IS-IS). 408 OSPF is also used to some degree with provider-provisioned VPNs by 409 the customers. In such scenarios, strict route filtering needs to be 410 applied to ensure only the valid prefixes are accepted. 412 4.2. IS-IS 414 Routing IP with IS-IS has gained popularity in the backbone networks 415 lately. As IS-IS does not use IP, it is sufficient to prevent 416 misconfiguration and unauthorized neighbors. Thus most of the 417 attacks and countermeasures of OSPF apply to IS-IS as well: 418 configuration change procedures and regular configuration audits and 419 disabling IS-IS adjacencies on customer-facing links, or adding 420 authentication when there are multiple routers. 422 4.3. BFD 424 Bidirectional Forwarding Detection (BFD) detects faults in the 425 forwarding path between two endpoints. As a generic mechanism, it 426 can be applied to a number of protocols (e.g., OSPF, IS-IS, BGP, 427 MPLS, or static routes). 429 When BFD is in use for a single-hop scenario, it uses GTSM to protect 430 from off-link attackers. Authentication can also be used for example 431 on untrusted links. 433 4.4. BGP 435 Internal BGP sessions run between loopback addresses. There is no 436 need to run TCP-MD5 for outsider protection as address filtering will 437 avoid TCP RST attacks. 439 External BGP sessions may run multi-hop between loopback addresses or 440 single-hop between interface addresses. The latter case is much more 441 common and easier to protect and applying GTSM provides first-order 442 resistance to off-link attackers. 444 In any case, assuming address filtering, the session can only be 445 reset by the peer, or by attacks from the direction of the peer's 446 network (e.g., through lack of peer's border filtering). One can 447 therefore question the necessity of further protection as the peer 448 can only shoot itself in the foot by killing the BGP session or 449 allowing the BGP session be killed through negligence. 451 If the link is not trusted (e.g., in some large Ethernet-based 452 Internet Exchange points), it may also be desirable to ensure that 453 peers are not able to reset others' sessions, so a mechanism like 454 TCP-MD5 may be appropriate. One should note that the security 455 requirements are not necessarily very high as the attacker should 456 already be easily traceable on a single link, and thus re-keying may 457 not be worth the trouble. 459 As BGP processes data heard from external sources, the routing data 460 can be modified in numerous ways, e.g., to create arbitrarily complex 461 advertisements using path attributes to crash naive BGP 462 implementations. These and many other BGP attacks are described in 463 [RFC4272]. Techniques described in Section 3.2 can mitigate the 464 attack vectors to some degree, but a more comprehensive solution to 465 securing routing data is needed. 467 4.5. Multicast Protocols (PIM, MSDP) 469 Multicast routing is typically achieved by PIM-SM 470 [I-D.ietf-mboned-routingarch]. MSDP is used for IPv4 source 471 discovery. Multicast routing protocol threats have been analyzed 472 separately in [I-D.ietf-mboned-mroutesec] (backbone perspective) and 473 [I-D.savola-pim-lasthop-threats] (last-hop perspective). 475 In summary, most of the multicast threats pertain to overloading 476 control processors via too much state. Implementation-specific rate- 477 limiters can help in mitigating the risk. If resetting MSDP sessions 478 is a concern, TCP-MD5 option similar to BGP can be used. Address 479 filtering can be applied in particular in PIM Unicast-Register 480 message decapsulation; other messages use multicast and already 481 employ reverse path forwarding checks. 483 5. Summary 485 IGPs require a great deal of care to ensure that they are not enabled 486 on links where they shouldn't be. Preventing external OSPF attacks 487 also requires OSPF authentication everywhere or filtering OSPF 488 packets at the edges. 490 ICMP attacks are able to cause a great deal of harm to almost all the 491 protocols, including IPsec, and there is little to do to mitigate the 492 risk except to implement enhanced ICMP payload verification/ 493 processing techniques. More study of the impact on connectionless 494 protocols and IPsec should be conducted. 496 With border address filtering in place, internal sessions are 497 reasonably safe. With additional GTSM protection, external private 498 interconnection links are also reasonably safe, as the session can 499 only be reset by the neighbor or due to lack of filtering, someone 500 through the neighbor's network. TCP-MD5 protection is most 501 appropriate for Internet Exchange points with multiple neighbors or 502 multihop eBGP sessions, but it's worth remembering that the security 503 requirements for the solution are not very high as the attackers have 504 very strict topological restrictions. 506 IPsec and IKE are obviously an option for heavy-weight protection, 507 but impractical (yet) due to configuration complexity and processing 508 overhead. Simplifications in configuration, implementation, and 509 cryptographic hardware offloading might help the situation for the 510 cases where the use of heavier protection (e.g., possibly Internet 511 Exchange points) could be warranted. 513 6. IANA Considerations 515 This memo makes no request to IANA. 517 7. Acknowledgements 519 George Jones suggested improvements to the initial version of this 520 draft. Further feedback was received from Sean P. Turner, Seo Boon 521 NG, Warren Kumari, Hank Nussbacher, and Jonathan Trostle. 523 8. Security Considerations 525 This document does not define a protocol but rather describes and 526 analyzes the security properties and countermeasures in existing 527 service provider backbone network infrastructures. 529 The most important issues that should be noted are its security 530 assumptions: 532 o The main concern is an external attack (from customers or some 533 other network); lower-layer attacks are not considered a 534 particular concern for routing protocols. 536 o We require at least certain degree of address filtering at 537 borders, or else all bets are off. 539 o Generic DoS attacks against routers can be mitigated using 540 implementation-specific measures. 542 There are a number of activities network operators have to do in 543 order to protect the network (e.g., filtering OSPF packets at the 544 edges or auditing IGP configurations). There are also lessons to be 545 learned for protocol designers (e.g., OSPF external attacks, ICMP 546 attacks against non-TCP, use of GTSM). Many of the issues listed 547 also depend on vendors to implement effective, vendor-specific rate- 548 limiting techniques. 550 9. References 552 9.1. Normative References 554 [I-D.ietf-mboned-mroutesec] 555 Savola, P., Lehtonen, R., and D. Meyer, "PIM-SM Multicast 556 Routing Security Issues and Enhancements", 557 draft-ietf-mboned-mroutesec-04 (work in progress), 558 October 2004. 560 [I-D.ietf-opsec-current-practices] 561 Kaeo, M., "Operational Security Current Practices", 562 draft-ietf-opsec-current-practices-03 (work in progress), 563 May 2006. 565 [I-D.ietf-rpsec-ospf-vuln] 566 Jones, E. and O. Moigne, "OSPF Security Vulnerabilities 567 Analysis", draft-ietf-rpsec-ospf-vuln-01 (work in 568 progress), December 2004. 570 [I-D.ietf-rpsec-routing-threats] 571 Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 572 Routing Protocols", draft-ietf-rpsec-routing-threats-07 573 (work in progress), October 2004. 575 [I-D.ietf-rtgwg-rfc3682bis] 576 Gill, V., "The Generalized TTL Security Mechanism (GTSM)", 577 draft-ietf-rtgwg-rfc3682bis-05 (work in progress), 578 April 2005. 580 [I-D.ietf-tcpm-icmp-attacks] 581 Gont, F., "ICMP attacks against TCP", 582 draft-ietf-tcpm-icmp-attacks-00 (work in progress), 583 February 2006. 585 [I-D.ietf-tcpm-tcp-antispoof] 586 Touch, J., "Defending TCP Against Spoofing Attacks", 587 draft-ietf-tcpm-tcp-antispoof-04 (work in progress), 588 May 2006. 590 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 591 Defeating Denial of Service Attacks which employ IP Source 592 Address Spoofing", BCP 38, RFC 2827, May 2000. 594 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 595 Networks", BCP 84, RFC 3704, March 2004. 597 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 598 RFC 4272, January 2006. 600 9.2. Informative References 602 [BLOCKED] Cisco Systems, "Cisco Security Advisory: Cisco IOS 603 Interface Blocked by IPv4 Packets", 2004, . 607 [I-D.ietf-mboned-routingarch] 608 Savola, P., "Overview of the Internet Multicast Routing 609 Architecture", draft-ietf-mboned-routingarch-03 (work in 610 progress), March 2006. 612 [I-D.ietf-opsec-filter-caps] 613 Morrow, C., "Filtering Capabilities for IP Network 614 Infrastructure", draft-ietf-opsec-filter-caps-01 (work in 615 progress), May 2006. 617 [I-D.ietf-tcpm-tcpsecure] 618 Stewart, R. and M. Dalal, "Improving TCP's Robustness to 619 Blind In-Window Attacks", draft-ietf-tcpm-tcpsecure-04 620 (work in progress), February 2006. 622 [I-D.savola-pim-lasthop-threats] 623 Savola, P., "Last-hop Threats to Protocol Independent 624 Multicast (PIM)", draft-savola-pim-lasthop-threats-01 625 (work in progress), January 2005. 627 [I-D.zinin-rtg-dos] 628 Zinin, A., "Protecting Internet Routing Infrastructure 629 from Outsider DoS Attacks", draft-zinin-rtg-dos-02 (work 630 in progress), May 2005. 632 [MYASN] RIPE NCC, "MyASn System", 633 . 635 Author's Address 637 Pekka Savola 638 CSC/FUNET 639 Espoo 640 Finland 642 Email: psavola@funet.fi 644 Full Copyright Statement 646 Copyright (C) The Internet Society (2006). 648 This document is subject to the rights, licenses and restrictions 649 contained in BCP 78, and except as set forth therein, the authors 650 retain all their rights. 652 This document and the information contained herein are provided on an 653 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 654 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 655 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 656 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 657 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 658 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 660 Intellectual Property 662 The IETF takes no position regarding the validity or scope of any 663 Intellectual Property Rights or other rights that might be claimed to 664 pertain to the implementation or use of the technology described in 665 this document or the extent to which any license under such rights 666 might or might not be available; nor does it represent that it has 667 made any independent effort to identify any such rights. Information 668 on the procedures with respect to rights in RFC documents can be 669 found in BCP 78 and BCP 79. 671 Copies of IPR disclosures made to the IETF Secretariat and any 672 assurances of licenses to be made available, or the result of an 673 attempt made to obtain a general license or permission for the use of 674 such proprietary rights by implementers or users of this 675 specification can be obtained from the IETF on-line IPR repository at 676 http://www.ietf.org/ipr. 678 The IETF invites any interested party to bring to its attention any 679 copyrights, patents or patent applications, or other proprietary 680 rights that may cover technology that may be required to implement 681 this standard. Please address the information to the IETF at 682 ietf-ipr@ietf.org. 684 Acknowledgment 686 Funding for the RFC Editor function is provided by the IETF 687 Administrative Support Activity (IASA).