idnits 2.17.1 draft-gont-opsec-icmp-ingress-filtering-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2017) is 2488 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-04) exists of draft-gont-v6ops-ipv6-ehs-packet-drops-03 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 opsec F. Gont 3 Internet-Draft UTN-FRH / SI6 Networks 4 Intended status: Best Current Practice R. Hunter 5 Expires: January 4, 2018 Globis Consulting BV 6 J. Massar 7 Massar Networking 8 W. Liu 9 Huawei Technologies 10 July 3, 2017 12 Defeating Attacks which employ Forged ICMPv4/ICMPv6 Error Messages 13 draft-gont-opsec-icmp-ingress-filtering-03.txt 15 Abstract 17 Over the years, a number of attack vectors that employ forged ICMPv4/ 18 ICMPv6 error messages have been disclosed and exploited in the wild. 19 The aforementioned attack vectors do not require that the source 20 address of the packets be forged, but do require that the addresses 21 of the IPv4/IPv6 packet embedded in the ICMPv4/ICMPv6 payload be 22 forged. This document discusses a simple, effective, and 23 straightforward method for using ingress traffic filtering to 24 mitigate attacks that use forged addresses in the IPv4/IPv6 packet 25 embedded in an ICMPv4/ICMPv6 payload. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 4, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 64 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4.1. Generation of ICMP Error Messages in Legitimate Scenarios 4 66 4.2. Attack Scenario . . . . . . . . . . . . . . . . . . . . . 5 67 5. ICMPv4/ICMPv6 Network Ingress Filtering . . . . . . . . . . . 7 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 9.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 Over the years, a number of attack vectors that employ forged ICMPv4/ 79 ICMPv6 error messages have been disclosed and exploited in the wild. 80 The effects of these attack vectors have ranged from Denial of 81 Service (DoS) to performance degradation [US-CERT] [RFC5927] 82 [I-D.gont-v6ops-ipv6-ehs-packet-drops]. 84 The aforementioned attack vectors do not require that the Source 85 Address of the ICMP [RFC0792] or ICMPv6 [RFC4443] attack packets to 86 be forged, but do require that the Destination Address of the IPv4 87 [RFC0791] (in the case of ICMPv4) or IPv6 (in the case of ICMPv6) 88 packet embedded in the ICMPv4/ICMPv6 payload be forged. Thus, 89 performing ingress filtering (ala BCP38 [RFC2827]) on the Destination 90 Address of the embedded IPv4/IPv6 packet results in a simple, 91 effective, and straightforward mitigation for any attack vectors 92 based on ICMPv4/ICMPv6 error messages. 94 Section 4 provides an overview of how ICMP/ICMPv6 error messages are 95 generated, and how packets are crafted to perform attacks based on 96 ICMPv4/ICMPv6 error messages. Section 5 specifies network ingress 97 filtering based on the ICMP/ICMPv6 payload. 99 2. Terminology 101 Throughout this document the term "IP" is employed to refer to both 102 the IPv4 [RFC0791] and IPv6 [RFC2460] protocols. That is, the term 103 "IP" is employed when we do not mean to make a distinction between 104 both versions of the protocol. In a similar vein, the term "ICMP" is 105 employed to refer to both the ICMPv4 [RFC0792] and ICMPv6 [RFC4443] 106 protocols. That is, the term "ICMP" is employed when we do not mean 107 to make a distinction between both versions of the protocol. 109 For obvious reasons, ICMPv4 will only be employed in conjunction with 110 IPv4, and ICMPv6 will always be employed in conjunction with IPv6. 111 That is, the phrase "the IP packet embedded in the ICMP payload" 112 means "the IPv4 packet embedded in the ICMPv4 payload" payload or 113 "the IPv6 packet embedded in the ICMPv6 payload" (but NOT e.g. "the 114 IPv4 packet embedded in the ICMPv6 payload"). 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 3. Applicability Statement 122 The filtering policy specified in this document could be enforced at 123 the border firewall of a non-multihomed network or at a CPE router, 124 such that users of that network are prevented from performing ICMP- 125 based attacks against other parties. 127 The filtering policy specified in this document SHOULD NOT be 128 enforced in multihoming scenarios, or other scenarios where this 129 policy could lead to false positives and therefore incorrect packet 130 drops. 132 4. Overview 134 Attack vectors based on ICMP error messages have been known for a 135 long time, and have been described in detail in [RFC5927]. The 136 following subsections provide an overview of how ICMP error messages 137 are generated in legitimate scenarios, and how an attacker would 138 forge an ICMP error message in order to perform an attack based on 139 ICMP error messages. 141 4.1. Generation of ICMP Error Messages in Legitimate Scenarios 143 The following figure illustrates a very simple network scenario in 144 which two hosts (H1 and H2) are connected to each other by means of 145 the router R1: 147 2001:db8:1::/64 2001:db8:2::/64 148 network network 150 2001:db8:1::1 2001:db8:2::1 151 +----+ +----+ +----+ 152 | H1 |-------------------| R1 |-------------------| H2 | 153 +----+ +----+ +----+ 154 2001:db8:1::100 2001:db8:2::100 156 Figure 1: Sample Scenario for ICMP/ICMPv6 Error Generation 158 The aforementioned figure illustrates the IPv6 addresses assigned to 159 each of the involved network interfaces. For simplicity sake, this 160 figure employs only IPv6 addresses, but the same logic applies to the 161 IPv4 case. 163 Let us assume that H1 sends a packet towards H2, and that R1 164 encounters an error condition while processing such a packet. 165 Typically, the error condition will be reported to H1 by means of an 166 ICMPv6 error message. The error message will have the following 167 structure: 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | | Original ICMP Payload | 171 + + +-+-+-+-+packet-+-+-+-+-+-+-+-+-+-+-+ + 172 | IP | | IP | IP | Optional | | 173 + + + + + + + 174 | Header | | Header | Payload | Ext. Obj | | 175 + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 176 | | | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 Figure 2: Structure of ICMPv4/ICMPv6 Error Messages 181 NOTES: 182 For completeness-sake, the figure above depicts the structure of 183 ICMP error messages including ICMP extension objects (see 184 [RFC4884]. Use of such extension objects does not affect the 185 discussion in this document. 187 In the IPv6 case, the "IP header" corresponds to the entire IPv6 188 header chain. Additionally, in the IPv4 scenarios in which 189 Network Address Translation (NAT) is in place, the NAT device 190 could fail to translate the IPv4 addresses of the embedded packet. 192 where the ICMPv6 error message embeds the whole (or part of) the 193 original packet that elicited the error message. 195 In our scenario, the relevant header fields would have the following 196 values: 198 o Source Address: 2001:db8:1::1 200 o Destination Address: 2001:db8:1::100 202 o Source Address (embedded packet): 2001:db8:1::100 204 o Destination Address (embedded packet): 2001:db8:2::100 206 It should be clear that the Source Address of the packet could be 207 virtually any address (since it corresponds to the IP address of a 208 router reporting the error), while the Destination Address of the 209 packet will be that of the target/destination of the ICMP error 210 message. On the other hand, the IP addresses of the embedded packet 211 will be those of the packet that elicited the ICMP error message. 213 The embedded IP packet is typically employed by the receiving system 214 to demultiplex the ICMP error message. 216 4.2. Attack Scenario 218 The following figure illustrates a very simple attack scenario in 219 which an attacker (H3) tries to perform an attack against H1, while 220 H1 is communicating with H2: 222 2001:db8:1::/64 2001:db8:2::/64 223 network network 225 2001:db8:1::1 2001:db8:2::1 226 +----+ +----+ +----+ 227 | H1 |-------------------| R1 |-------------------| H2 | 228 +----+ +----+ +----+ 229 2001:db8:1::100 | 2001:db8:2::100 230 | 231 ___--^--/--__ 232 / \ 233 < Internet > 234 \_ _| 235 \_________/ 236 | 237 | 238 +----+ 239 | R2 | 240 +----+ 241 2001:db8:3::1 | 242 | 2001:db8:3::/64 network 243 | 244 | 2001:db8:3::100 245 +----+ 246 | H3 | 247 +----+ 249 Figure 3: Hypothetical Attack Scenario 251 In our scenario, the attack packet sent by the attacker would have 252 the same structure as that of Figure 2, with the following values: 254 o Source Address: 2001:db8:3::100 (or forged address) 256 o Destination Address: 2001:db8:1::100 258 o Source Address (embedded packet): 2001:db8:1::100 260 o Destination Address (embedded packet): 2001:db8:2::100 262 The Source Address of the packet is rather irrelevant and need not be 263 forged. The Destination Address of the packet will be that of the 264 attack target (H1 in our case). The Source Address of the embedded 265 packet will be that of the attack target (H1 in our case). Finally, 266 the Destination Address of the embedded packet will be that of the 267 peer with which the attack target is communicating (H2 in our case). 269 If router R2 were to inspect the payload of the ICMP attack packet, 270 it would conclude that the attack packet cannot be possibly valid, 271 since packets destined to 2001:db8:2::100 would never be forwarded to 272 the network from which the error message is originating. In a 273 similar vein, if R1 were to examine the payload of the aforementioned 274 ICMP error message, it would also conclude that the ICMP error 275 message cannot be possibly valid, for the same reason stated before. 276 Thus, filtering ICMP messages based on the ICMP payload could be 277 employed as a countermeasure for attacks based on ICMP error 278 messages. 280 5. ICMPv4/ICMPv6 Network Ingress Filtering 282 A node (e.g. firewall) meaning to enforce the filtering policy 283 specified in this document SHOULD check: 285 IF embedded packet's Destination Address is from within my network 286 THEN forward as appropriate 288 IF embedded packet's Destination Address is anything else 289 THEN drop packet 291 NOTE: The destination match is due to a learned route (which 292 assumes some minimal level of path or routing symmetry which 293 firewalls tend to require anyway); or an access list. 295 We note, however, that the techniques described in [RFC3704] should 296 be evaluated when the aforementioned network ingress filtering is to 297 be implemented in more complex network scenarios, such as that of a 298 multihomed networks. In multihomed scenarios, this filtering policy 299 tends to be undesirable since it is likely to lead to false 300 positives. 302 Finally, we note that packet drops SHOULD be logged, since this then 303 provides a basis for monitoring any suspicious activity. 305 6. IANA Considerations 307 This document has no actions for IANA. 309 7. Security Considerations 311 This document provides advice on performing network ingress filtering 312 on ICMPv4 and ICMPv6 error messages, such that attacks based on such 313 messages can be mitigated by means of network packet filtering. 314 Implementation of this filtering technique may depend on the ability 315 of the filtering device to inspect the payload of ICMP messages. 317 We note that a given platform may or may not be able to filter ICMP 318 error messages based on the ICMP payload. Thus, the aforementioned 319 filter SHOULD only be performed where applicable. Additionally, 320 enforcing the aforementioned filtering method might impact the 321 performance of the filtering device (see e.g., 322 [I-D.gont-v6ops-ipv6-ehs-packet-drops] and [Zack-FW-Benchmark] for a 323 discussion of the IPv6 case). This should be considered before 324 enabling the aforementioned filtering method. 326 8. Acknowledgements 328 The authors of this document would like to thank (in alphabetical 329 order) Ron Bonica, Igor Gashinsky, Joel Jaeggli, Merike Kaeo, Jen 330 Linkova, Vic Liu, Carlos Pignataro, and Eric Vyncke, for providing 331 valuable comments on earlier versions of this document. 333 9. References 335 9.1. Normative References 337 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 338 DOI 10.17487/RFC0791, September 1981, 339 . 341 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 342 RFC 792, DOI 10.17487/RFC0792, September 1981, 343 . 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, 347 DOI 10.17487/RFC2119, March 1997, 348 . 350 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 351 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 352 December 1998, . 354 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 355 Control Message Protocol (ICMPv6) for the Internet 356 Protocol Version 6 (IPv6) Specification", RFC 4443, 357 DOI 10.17487/RFC4443, March 2006, 358 . 360 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 361 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 362 DOI 10.17487/RFC4884, April 2007, 363 . 365 9.2. Informative References 367 [I-D.gont-v6ops-ipv6-ehs-packet-drops] 368 Gont, F., Hilliard, N., Doering, G., (Will), S., and W. 369 Kumari, "Operational Implications of IPv6 Packets with 370 Extension Headers", draft-gont-v6ops-ipv6-ehs-packet- 371 drops-03 (work in progress), March 2016. 373 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 374 Defeating Denial of Service Attacks which employ IP Source 375 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 376 May 2000, . 378 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 379 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 380 2004, . 382 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, 383 DOI 10.17487/RFC5927, July 2010, 384 . 386 [US-CERT] US-CERT, "US-CERT Vulnerability Note VU#222750: TCP/IP 387 Implementations do not adequately validate ICMP error 388 messages", http://www.kb.cert.org/vuls/id/222750, 2005. 390 [Zack-FW-Benchmark] 391 Zack, E., "Firewall Security Assessment and Benchmarking 392 IPv6 Firewall Load Tests", IPv6 Hackers Meeting #1, 393 Berlin, Germany. June 30, 2013, 394 . 398 Authors' Addresses 400 Fernando Gont 401 UTN-FRH / SI6 Networks 402 Evaristo Carriego 2644 403 Haedo, Provincia de Buenos Aires 1706 404 Argentina 406 Phone: +54 11 4650 8472 407 Email: fgont@si6networks.com 408 URI: https://www.si6networks.com 409 Ray Hunter 410 Globis Consulting BV 411 Weegschaalstraat 3 412 Eindhoven 5632CW 413 NL 415 Email: v6ops@globis.net 417 Jeroen Massar 418 Massar Networking 419 Swiss Post Box 101811 420 Zuercherstrasse 161 421 Zuerich CH-8010 422 CH 424 Email: jeroen@massar.ch 425 URI: http://jeroen.massar.ch 427 Will(Shucheng) Liu 428 Huawei Technologies 429 Bantian, Longgang District 430 Shenzhen 518129 431 P.R. China 433 Email: liushucheng@huawei.com