idnits 2.17.1 draft-savola-rtgwg-backbone-attacks-00.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 483. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 501. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 507. ** 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 238: '...ed protocol port MUST be sent with TTL...' RFC 2119 keyword, line 241: '... 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 (March 31, 2006) is 6599 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-02 == 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-03 == Outdated reference: A later version (-09) exists of draft-ietf-opsec-filter-caps-00 == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcpsecure-04 Summary: 4 errors (**), 0 flaws (~~), 8 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 March 31, 2006 5 Expires: October 2, 2006 7 Backbone Infrastructure Attacks and Protections 8 draft-savola-rtgwg-backbone-attacks-00.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 October 2, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 A number of protection mechanisms for attacks against service 42 provider backbone network infrastructure have been specified or 43 proposed, each of them usually targeting a subset of the problem 44 space. There has never been a more generic analysis of the actual 45 problems, and which protection techniques are even necessary (and 46 where). This document tries to provide that higher-level view. 48 Table of Contents 50 1. Introduction and Assumptions . . . . . . . . . . . . . . . . . 3 51 2. Attack Vectors . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. Lower-layer Attacks . . . . . . . . . . . . . . . . . . . 3 53 2.2. Generic DoS on the Router . . . . . . . . . . . . . . . . 4 54 2.3. Cryptographic Exhaustion Attacks . . . . . . . . . . . . . 4 55 2.4. Unauthorized Neighbor Attacks . . . . . . . . . . . . . . 4 56 2.5. TCP RST Attacks . . . . . . . . . . . . . . . . . . . . . 5 57 2.6. ICMP Attacks . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Typical Protection Mechanisms . . . . . . . . . . . . . . . . 5 59 3.1. Address Filtering . . . . . . . . . . . . . . . . . . . . 5 60 3.2. GTSM . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.3. TCP-MD5 and Other Custom Authentication . . . . . . . . . 6 62 3.4. IPsec and IKE . . . . . . . . . . . . . . . . . . . . . . 6 63 4. Protocol Analysis . . . . . . . . . . . . . . . . . . . . . . 6 64 4.1. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.2. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.3. BFD . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 4.4. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.5. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 Intellectual Property and Copyright Statements . . . . . . . . . . 12 79 1. Introduction and Assumptions 81 A number of protection mechanisms for attacks against service 82 provider backbone network infrastructure have been specified or 83 proposed, each of them usually targeting a subset of the problem 84 space. There has never been a more generic analysis of the actual 85 problems, and which protection techniques are even necessary (and 86 where). This document tries to provide that higher-level view. 88 We'll assume that the service provider is doing at least some form of 89 address filtering at its border devices, i.e., by ensuring that only 90 the infrastructure nodes can use infrastructure source IP addresses 91 to talk to the other nodes in the infrastructure. So, for example, 92 if a router sees an IP packet coming from a source address assigned 93 to another router in the backbone, it can be sure the packet has been 94 originated inside the backbone (assuming the physical security or 95 nodes in the backbone have not been subverted). 97 This requirement can be satisfied by applying ingress filtering at 98 all your borders [RFC2827][RFC3704], but just filtering 99 infrastructure source IP addresses from the outside is also 100 sufficient. Some may even implement this by blocking access to the 101 infrastructure destination addresses at the border, but we do not 102 describe this approach as that has a number of other issues. 104 Current operational practices are described in 105 [I-D.ietf-opsec-current-practices]; while almost all ISPs are capable 106 of employing data plane filtering at the edges, at least one major 107 ISP is known not do be able to due to legacy hardware limitations. 108 Various diltering capabilities have been discussed at more length in 109 [I-D.ietf-opsec-filter-caps]. 111 If this requirement cannot be satisfied, other approaches are 112 warranted. For example, [I-D.zinin-rtg-dos] suggested an alternative 113 (and in any case, provides good analysis); IPsec-protecting all the 114 control traffic might also be possible if "all bets are off". 116 2. Attack Vectors 118 We'll describe the most obvious attack vectors. 120 2.1. Lower-layer Attacks 122 If an attacker has access to a (physical) link, it can obviously 123 cause downtime for the link. In many cases the downtime is not a 124 critical threat, as it can be quickly noticed, traffic rerouted, and 125 the problem fixed. Some are more concerned about other forms of 126 attacks: insertion of eavesdropping or man-in-the-middle devices. 127 Fortunately, installing such would require downtime and could be 128 noticeable. 130 This is a more generic issue though: if one is concerned about this, 131 one should really provide full integrity protection and even 132 confidentiality to *all* the traffic, not just routing protocols. 133 Hence, we are not concerned of lower-layer attacks as these are not 134 specific to routing protocols. 136 2.2. Generic DoS on the Router 138 A typical attack is to overload a router using various techniques, 139 e.g., by sending traffic exceeding the router's forwarding capacity, 140 sending special transit packets that go through a "slow-path" 141 processing, or by sending some packets directed at the router itself. 143 Many of these techniques can be mitigated using implementation- 144 specific rate-limiting mechanisms, so they are not addressed further 145 in this memo. However, p protocol designers should be advised to 146 avoid any designs which require noticing and processing some special 147 packets from the transit traffic (e.g., messages marked with router 148 alert option). 150 2.3. Cryptographic Exhaustion Attacks 152 A special form of the above are attacks which target a protocol which 153 uses cryptographic mechanisms, for example TCP-MD5 or IPsec. The 154 attacker sends valid protocol messages with cryptographic signatures 155 or other properties to the router, which is forced to perform 156 cryptographic validation of the message. If the cryptographic 157 operations are computationally expensive, the attack might succeed 158 easier than with other generic DoS mechanisms. 160 Some implementation-specific mitigation techniques (rate-limiting 161 etc.) have been deployed, but as this affects the choice of a 162 protection mechanism due to protocol design, we'll keep this attack 163 in scope for this memo. 165 2.4. Unauthorized Neighbor Attacks 167 Unauthorized nodes can obtain a routing protocol adjacency e.g., on 168 links where an IGP has been enabled by misconfiguration, or where 169 authentication is not used. This may result in many different kinds 170 of attacks, for example traffic redirection 171 [I-D.ietf-rpsec-routing-threats]. 173 At least in theory, some protocols can also be attacked in this way 174 from outside the link (e.g., OSPF [I-D.ietf-rpsec-ospf-vuln]). 176 Therefore special care needs to be made to ensure misconfiguration of 177 does not happen. 179 2.5. TCP RST Attacks 181 TCP sessions can be closed by attackers which can send a TCP RST 182 packet with guessed spoofed endpoint identifiers and a sufficiently 183 close sequence number. The attacks and defenses have been described 184 at length in [I-D.ietf-tcpm-tcp-antispoof]. One particular approach 185 is modifying the TCP state machine [I-D.ietf-tcpm-tcpsecure]. 187 2.6. ICMP Attacks 189 A slightly newer attack is employing ICMP by sending an ICMP type 190 which indicates a hard error condition. ICMP errors must be 191 propagated to applications, and most applications heed the errors (as 192 they should) e.g., by closing a connection or session. ICMP attacks 193 and defenses against TCP have been extensively described in 194 [I-D.ietf-tcpm-icmp-attacks]. 196 It is also possible to execute ICMP attacks against other protocols 197 such as UDP or IPsec, but the impact and whether/how these protocols 198 demultiplex received errors have not been extensively studied. IPsec 199 is protected by ICMP attacks through a lot of assumptions (e.g., that 200 only ICMP errors from the end-point are accepted) or manual 201 configuration. 203 3. Typical Protection Mechanisms 205 We'll describe some of the most common protection or mitigation 206 techniques applied today. 208 3.1. Address Filtering 210 As described in the first section, we already assume that the 211 internal infrastructure is secure from spoofed messages that purport 212 to come from inside the infrastructure. More fine-grained, router- 213 specific filters are sometimes deployed as well. 215 A functionally similar technique (where available) it to use a 216 distinct (public) address block for numbering the infrastructure 217 devices, but not advertise it outside your system. Obviously, this 218 requires a separate assignment or fragmenting an aggregate prefix. 219 This does not protect from your customers using a default route. 221 3.2. GTSM 223 GTSM [I-D.ietf-rtgwg-rfc3682bis] is a technique where the sender of a 224 packet sets the TTL/Hop Count to 255 and the receiver verifies it's 225 still 255 (or some other preconfigured value). This is a very useful 226 protection method for control traffic which is inside a single link: 227 any packets coming from outside the link can summarily be discarded. 229 The open issue at the moment is how GTSM handles TCP RSTs. I.e., 230 should it require that RSTs for a GTSM-enabled session should be sent 231 with TTL=255 and verified to come with TTL=255 (or a configured 232 value)? Do implementations already do this? Is there a sensible 233 transition plan or need to make a change if any? Note that this has 234 only limited impact on GTSM's security as other TCP RST mitigation 235 techniques still apply. 237 We suggest that the GTSM spec is amended that TCP RSTs relating to to 238 a GTSM-enabled protocol port MUST be sent with TTL=255. (Note that 239 this will require a kernel modification, and a means to specify to 240 the kernel which ports relate to GTSM.). The recipients behaviour 241 SHOULD be configurable, and it is RECOMMENDED that the default be to 242 discard messages where TTL is not 255 (or 255-TrustRadius). 244 3.3. TCP-MD5 and Other Custom Authentication 246 At least BGP and LDP are able to use the TCP-MD5 signature option to 247 verify the authenticity of control packets. TCP-MD5 uses manually 248 configured static keys, so changing them typically resets the 249 protocol session, so the solution is sub-optimal in cases where the 250 security procedures require that the keys must be easily and often 251 changeable. 253 Using TCP-MD5 and other similar authentication mechanisms (e.g., for 254 IGPs or BFD) also opens an attack vector for cryptographic exhaustion 255 attacks unless implementations have appropriate mechanisms to 256 throttle these. In the case of IGPs, the attack vector is typically 257 smaller though. 259 3.4. IPsec and IKE 261 IPsec and IKE have been proposed as a more comprehensive protection 262 mechanism, but it also requires a lot of heavyweight protocol 263 machinery, lots of configuration, and cryptographic processing. 265 4. Protocol Analysis 267 We'll briefly discuss the protocol-specific attack properties below. 269 ICMP attacks apply to all the IP protocols at least to some degree. 270 There is no reasonable way to appropriately protect from these 271 attacks by operative methods: the vendors should implement 272 countermeasures described in [I-D.ietf-tcpm-icmp-attacks] to mitigate 273 this risk. 275 4.1. OSPF 277 In the past, there has already been some analysis of OSPF attacks 278 [I-D.ietf-rpsec-ospf-vuln]. In this context the most important of 279 them are: (1) preventing misconfiguration and unauthorized neighbors, 280 and (2) ensuring off-path directed attacks as described in Section 281 3.1.2 of [I-D.ietf-rpsec-ospf-vuln]. 283 The former requires configuration change procedures and regular 284 audits of OSPF configuration, and disabling OSPF adjacencies on 285 customer-facing links, or adding authentication when there are 286 multiple routers. The latter requires using OSPF authentication, 287 dropping all OSPF traffic at all the borders, or moving to another, 288 less vulnerable protocol (e.g., IS-IS). 290 OSPF is also used to some degree with provider-provisioned VPNs by 291 the customers. The author is not familiar with this scenario, so 292 these threats are not analyzed. 294 4.2. IS-IS 296 Routing IP with IS-IS has gained popularity in the backbone networks 297 lately. As IS-IS does not use IP, it is sufficient to prevent 298 misconfiguration and unauthorized neighbors. The same techniques 299 apply as to OSPF: configuration change procedures and regular 300 configuration audits and disabling IS-IS adjacencies on customer- 301 facing links, or adding authentication when there are multiple 302 routers. 304 4.3. BFD 306 Bidirectional Forwarding Detection (BFD) detects faults in the 307 forwarding path between two endpoints. As a generic mechanism, it 308 can be applied to a number of protocols, e.g., OSPF, IS-IS, BGP, 309 MPLS, or static routes. 311 When BFD is in use for a single-hop scenario, it uses GTSM to protect 312 from off-link attackers. Authentication can also be used e.g., on 313 untrusted links. 315 XXX: it's a bit cornercase whether to even include BFD here as it's 316 not a routing protocol as such; however, as resetting BFD session 317 could result in losing a protocol adjacency, it seems a relevant 318 enough.. 320 4.4. BGP 322 Internal BGP sessions run between loopback addresses. There is no 323 need to run TCP-MD5 for outsider protection as address filtering will 324 avoid TCP RST attacks. 326 External BGP sessions may run multi-hop between loopback addresses or 327 single-hop between interface addresses. The latter case is much more 328 common and easier to protect and applying GTSM provides first-order 329 resistance to off-link attackers. 331 In any case, assuming address filtering, the session can only be 332 reset by the peer, or by attacks from the direction of the peer's 333 network (e.g., through lack of peer's border filtering). One can 334 therefore question the necessity of further protection as the peer 335 can only shoot itself in the foot by killing the BGP session or 336 allowing the BGP session be killed through negligence. 338 If the link is not trusted (e.g., in some large Ethernet-based 339 Internet Exchange points), it may also be desirable ensure that peers 340 are not able to reset others' sessions, so a mechanism like TCP-MD5 341 may be appropriate. One should note that the security requirements 342 are not necessarily very high as the attacker should already be 343 easily traceable on a single link, and thus re-keying may not be 344 worth the trouble. 346 4.5. LDP 348 TBD -- send text, similar to single-hop BGP? 350 5. Summary 352 IGPs require a great deal of care to ensure that they are not enabled 353 on links where they shouldn't be. Preventing external OSPF attacks 354 also requires OSPF authentication everywhere or filtering OSPF 355 packets at the edges. 357 ICMP attacks are able to cause a great deal of harm to almost all the 358 protocols, including IPsec, and there is little to do to mitigate the 359 risk except to implement enhanced ICMP payload verification/ 360 processing techniques. More study of the impact on connectionless 361 protocols and IPsec should be conducted. 363 With border address filtering in place, internal sessions are 364 reasonably safe. With additional GTSM protection, external private 365 interconnection links are also reasonably safe, as the session can 366 only be reset by the neighbor or due to lack of filtering, someone 367 through the neighbor's network. TCP-MD5 protection is most 368 appropriate for Internet Exchange points with multiple neighbors or 369 multihop eBGP sessions, but it's worth remembering that the security 370 requirements for the solution are not very high as the attackers have 371 very strict topological restrictions. 373 IPsec and IKE are obviously an option for heavy-weight protection, 374 but impractical (yet) due to configuration complexity and processing 375 overhead. Simplifications in configuration, implementation, and 376 cryptographic hardware offloading might help the situation for the 377 cases where the use of heavier protection (e.g., possibly Internet 378 Exchange points) could be warranted. 380 6. IANA Considerations 382 This memo makes no request to IANA. 384 7. Acknowledgements 386 George Jones suggested improvements to the initial version of this 387 draft. 389 8. Security Considerations 391 This document is all about security, but the most important issues 392 that should be noted are its security assumptions: 394 o There is at least certain degree of address filtering at borders, 395 else all bets are off. 397 o Lower-layer attacks are not considered a particular concern for 398 routing protocols. 400 o Generic DoS attacks against routers can be mitigated using 401 implementation-specific measures. 403 9. References 404 9.1. Normative References 406 [I-D.ietf-opsec-current-practices] 407 Kaeo, M., "Operational Security Current Practices", 408 draft-ietf-opsec-current-practices-02 (work in progress), 409 October 2005. 411 [I-D.ietf-rpsec-ospf-vuln] 412 Jones, E. and O. Moigne, "OSPF Security Vulnerabilities 413 Analysis", draft-ietf-rpsec-ospf-vuln-01 (work in 414 progress), December 2004. 416 [I-D.ietf-rpsec-routing-threats] 417 Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 418 Routing Protocols", draft-ietf-rpsec-routing-threats-07 419 (work in progress), October 2004. 421 [I-D.ietf-rtgwg-rfc3682bis] 422 Gill, V., "The Generalized TTL Security Mechanism (GTSM)", 423 draft-ietf-rtgwg-rfc3682bis-05 (work in progress), 424 April 2005. 426 [I-D.ietf-tcpm-icmp-attacks] 427 Gont, F., "ICMP attacks against TCP", 428 draft-ietf-tcpm-icmp-attacks-00 (work in progress), 429 February 2006. 431 [I-D.ietf-tcpm-tcp-antispoof] 432 Touch, J., "Defending TCP Against Spoofing Attacks", 433 draft-ietf-tcpm-tcp-antispoof-03 (work in progress), 434 February 2006. 436 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 437 Defeating Denial of Service Attacks which employ IP Source 438 Address Spoofing", BCP 38, RFC 2827, May 2000. 440 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 441 Networks", BCP 84, RFC 3704, March 2004. 443 9.2. Informative References 445 [I-D.ietf-opsec-filter-caps] 446 Morrow, C., "Filtering Capabilities for IP Network 447 Infrastructure", draft-ietf-opsec-filter-caps-00 (work in 448 progress), October 2005. 450 [I-D.ietf-tcpm-tcpsecure] 451 Stewart, R. and M. Dalal, "Improving TCP's Robustness to 452 Blind In-Window Attacks", draft-ietf-tcpm-tcpsecure-04 453 (work in progress), February 2006. 455 [I-D.zinin-rtg-dos] 456 Zinin, A., "Protecting Internet Routing Infrastructure 457 from Outsider DoS Attacks", draft-zinin-rtg-dos-02 (work 458 in progress), May 2005. 460 Author's Address 462 Pekka Savola 463 CSC/FUNET 464 Espoo 465 Finland 467 Email: psavola@funet.fi 469 Full Copyright Statement 471 Copyright (C) The Internet Society (2006). 473 This document is subject to the rights, licenses and restrictions 474 contained in BCP 78, and except as set forth therein, the authors 475 retain all their rights. 477 This document and the information contained herein are provided on an 478 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 479 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 480 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 481 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 482 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 483 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 485 Intellectual Property 487 The IETF takes no position regarding the validity or scope of any 488 Intellectual Property Rights or other rights that might be claimed to 489 pertain to the implementation or use of the technology described in 490 this document or the extent to which any license under such rights 491 might or might not be available; nor does it represent that it has 492 made any independent effort to identify any such rights. Information 493 on the procedures with respect to rights in RFC documents can be 494 found in BCP 78 and BCP 79. 496 Copies of IPR disclosures made to the IETF Secretariat and any 497 assurances of licenses to be made available, or the result of an 498 attempt made to obtain a general license or permission for the use of 499 such proprietary rights by implementers or users of this 500 specification can be obtained from the IETF on-line IPR repository at 501 http://www.ietf.org/ipr. 503 The IETF invites any interested party to bring to its attention any 504 copyrights, patents or patent applications, or other proprietary 505 rights that may cover technology that may be required to implement 506 this standard. Please address the information to the IETF at 507 ietf-ipr@ietf.org. 509 Acknowledgment 511 Funding for the RFC Editor function is provided by the IETF 512 Administrative Support Activity (IASA).