idnits 2.17.1 draft-roca-ipsecme-ptb-pts-attack-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 6, 2015) is 3210 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPsec Maintenance and Evolution (IPSECME) V. Roca 3 Internet-Draft S. Fall 4 Intended status: Informational INRIA 5 Expires: January 7, 2016 July 6, 2015 7 Too Big or Too Small? The PTB-PTS ICMP-based Attack against IPsec 8 Gateways 9 draft-roca-ipsecme-ptb-pts-attack-00 11 Abstract 13 This document introduces the "Packet Too Big"-"Packet Too Small" 14 Internet Control Message Protocol (ICMP) based attack against IPsec 15 gateways. We explain how an attacker having eavesdropping and packet 16 injection capabilities, from the unsecure network where he only sees 17 encrypted packets, can force a gateway to reduce the Path Maximum 18 Transmission Unit (PMTU) of an IPsec tunnel to the minimum, which can 19 trigger severe issues for the hosts behind this gateway: with a Linux 20 host, depending on the PMTU discovery algorithm in use (i.e., PMTUd 21 versus PLPMTUd) and protocol (TCP versus UDP), the attack either 22 creates a Denial of Service or major performance penalties. This 23 attack highlights two fundamental problems, namely: (1) the 24 impossibility to distinguish legitimate from illegitimate ICMP 25 packets coming from the untrusted network, and (2) the contradictions 26 in the way Path MTU is managed by some end hosts when this Path MTU 27 is below the minimum packet size any link should support because of 28 the IPsec encapsulation. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 7, 2016. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Notations, Definitions and Abbreviations . . . . . . . . . . 4 66 2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 67 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 68 3. About Path MTU discovery . . . . . . . . . . . . . . . . . . 4 69 3.1. The legacy PMTUd mechanism . . . . . . . . . . . . . . . 4 70 3.2. The Packetization Layer PMTUd mechanism . . . . . . . . . 5 71 4. The attacker model . . . . . . . . . . . . . . . . . . . . . 5 72 5. Launching the PTB-PTS attack . . . . . . . . . . . . . . . . 6 73 5.1. Test configuration . . . . . . . . . . . . . . . . . . . 6 74 5.2. Step 1 (common): Forging an ICMP PTB packet from the 75 untrusted network . . . . . . . . . . . . . . . . . . . . 7 76 5.3. Step 2 (common): Reset of the PMTU on the gateway . . . . 7 77 5.4. Following steps with Linux, TCP/IPv4 and PMTUd . . . . . 7 78 5.5. Following steps with Linux, TCP/IPv4 and PLPMTUd . . . . 8 79 5.6. Following steps with Linux, TCP/IPv6 and PMTUd . . . . . 9 80 5.7. Following steps with Linux, TCP/IPv6 and PLPMTUd . . . . 9 81 5.8. Following steps with Windows 7, TCP/IPv4 and default PMTU 82 discovery . . . . . . . . . . . . . . . . . . . . . . . . 10 83 5.9. Following steps with Windows 7, TCP/IPv6 and default PMTU 84 discovery . . . . . . . . . . . . . . . . . . . . . . . . 11 85 5.10. Other configurations . . . . . . . . . . . . . . . . . . 11 86 6. Summary of the results . . . . . . . . . . . . . . . . . . . 11 87 6.1. Linux end-hosts . . . . . . . . . . . . . . . . . . . . . 11 88 6.2. Windows 7 end-hosts . . . . . . . . . . . . . . . . . . . 12 89 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 7.1. The two core issues . . . . . . . . . . . . . . . . . . . 12 91 7.2. Trivial unsatisfying counter-measures . . . . . . . . . . 13 92 7.3. Potential solutions . . . . . . . . . . . . . . . . . . . 14 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 94 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 95 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 97 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 98 11.2. Informative References . . . . . . . . . . . . . . . . . 15 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 101 1. Introduction 103 IPsec interacts with the Internet Control Message Protocol (ICMP). A 104 first goal of ICMP is to exchange control and error messages, like 105 packet processing error notifications. But ICMP is also involved in 106 several functionalities and in particular the Path Maximum 107 Transmission Unit discovery (PMTUd) mechanism [RFC1191], whose goal 108 is to find the maximum packet size on a path that avoids packet 109 fragmentation. Such a mechanism is essential from a performance 110 point of view: if a packet is too large, its fragmentation and 111 reassembly will negatively impact performance. At the other extreme, 112 if a packet is significantly smaller than the maximum size permitted 113 throughout the path, it will also negatively impact performance. 114 Assessing the correct packet size on a path is therefore essential. 116 But ICMP is also known to be a cause of attacks and therefore there 117 is an incentive for a network administrator to filter out these 118 packets (see [Jacquin12] for a detailed analysis of the situation). 119 A balance is therefore required between these contradictory 120 objectives, and it is recognized that only a subset of ICMP packets 121 should be considered by IPsec gateways. In this document we assume 122 that the target IPsec gateway accepts and processes the ICMP 123 "Destination unreachable"/"Fragmentation needed" (with IPv4) or 124 ICMPv6 "Packet Too Big"/"Fragmentation needed" (with IPv6) packets 125 coming from the unsecure network. For simplification purposes, the 126 term "ICMP PTB" will be used throughout this document to denote 127 either of these ICMP packets. 129 The PTB-PTS attack is carried out from the untrusted network, and 130 through the IPsec gateway, the attack targets hosts in the trusted 131 network, behind the gateway. We assume the attacker can eavesdrop 132 and inject traffic on the untrusted network Section 4, i.e., we 133 assume the attacker is on the path followed by the tunnel (which is 134 trivial in case of an unsecure WiFi network). A single ICMP PTB 135 packet is sufficient for the attack, this ICMP advertising an MTU 136 close or below the minimum MTU any link technology must support: 576 137 in IPv4 and 1280 in IPv6. Because of the IPsec ESP encapsulation, 138 the IPsec gateway then advertises an MTU below this minimum to the 139 local hosts, thereby creating confusion among them. The consequences 140 on the end-hosts can be serious, ranging from performance impacts to 141 Denial of Services (DoS), depending on the exact configuration: 142 operating system (e.g., Linux versus Windows), protocol (e.g., TCP 143 versus UDP or IPv4 versus IPv6), and internal parameters (e.g., PMTUd 144 versus PLPMTUd). 146 The present document details both the attack and its consequences on 147 the end-host, depending on the exact configuration. Note that some 148 parts of the present document are not specific to IPsec and similar 149 attacks could be launched in other situations where a gateway need to 150 encapsulate some traffic in a tunnel. 152 2. Notations, Definitions and Abbreviations 154 2.1. Requirements Notation 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [RFC2119]. 160 2.2. Abbreviations 162 This document uses the following abbreviations. 164 ICMP PTB: 166 Either an ICMP "Destination unreachable"/"Fragmentation needed" 167 packet (IPv4) or ICMPv6 "Packet Too Big"/"Fragmentation needed" 168 (IPv6), depending on the context 170 PTB-PTS: 172 Packet Too Big-Packet Too Small 174 3. About Path MTU discovery 176 Path MTU discovery (PMTUd) is a key mechanism for optimum network 177 performance since it enables a sender to determine the appropriate 178 packet size along a path dynamically (the path may change over time). 179 Two complementary PMTU discovery algorithms are in use: PMTUd and 180 PLPMTUd. 182 3.1. The legacy PMTUd mechanism 184 PMTUd [RFC1191] is the legacy approach. Let us illustrate its 185 behavior in an IPv4 (resp. IPv6) network. A sender sets the IPv4 186 Don't Fragment (DF) bit in a packet (useless in IPv6 as fragmentation 187 is prohibited). If a router cannot transmit this packet because of 188 its size, it must send back to the sender an ICMP "Destination 189 unreachable"/"Fragmentation needed" packet (resp. an ICMPv6 "Packet 190 Too Big"/"Fragmentation needed"), along with the next hop MTU 191 information. In the following we will call these error packets ICMP 192 PTB (Packet Too Big), regardless of whether IPv4 or IPv6 is used. 193 Iteratively, upon receiving such an ICMP PTB packet, the sender 194 decreases the packet size until it reaches the lowest MTU on the path 195 to the destination. The PMTU is then found and will be used by the 196 sender for outgoing packets sent to this destination. Since the path 197 can change dynamically (e.g., due to re-routing), this process needs 198 to be performed periodically. Although efficient, the PMTUd approach 199 suffers from several limits, mainly because ICMP packets are often 200 filtered out by some routers/firewalls along their route to the 201 sender. In that case the sender needs another technique to discover 202 the Path MTU. 204 3.2. The Packetization Layer PMTUd mechanism 206 To overcome these issues, a new Path MTU discovery mechanism has been 207 developed, that does not rely on ICMP, the Packetization Layer PMTUd 208 (PLPMTUd) [RFC4821]. Instead of using ICMP, it relies on a 209 packetization layer protocol with an acknowledgement mechanism, such 210 as TCP. Using TCP, the sender sends probing packets of a specific 211 size to the destination. If the probing packet is acknowledged, the 212 sender validates that the PMTU is at least equal to the probing 213 packet size, while a time-out indicates that the PMTU is smaller. 214 With TCP, any data segment can be used as a probing packet if enough 215 data is available to fill in the payload. Here also, because the 216 path may change, the PLPMTUd process needs to be performed 217 periodically. 219 4. The attacker model 221 In this document, we consider that all the attacks are conducted by 222 adversaries located on the external unsecure black network. We 223 assume an attacker can both eavesdrop the traffic in the IPsec tunnel 224 and inject forged packets. We also assume an attacker has no way to 225 decrypt packets nor encrypt its own packets because the underlying 226 IPsec cryptographic building blocks and key exchange protocols are 227 considered secure. The goal of the attacker is to launch a DoS 228 against the secure tunnel service provided by IPsec gateways, for 229 both kinds of IPsec configurations: host-to-site and site-to-site. 230 Note that in a host-to-site configuration, where a nomad host 231 remotely connects to its home network through an IPsec tunnel, the 232 remote site gateway is the target, not the isolated host. 234 A requirement is for the attacker to be on the path followed by the 235 IPsec tunnel. For instance, the attacker can be located on a 236 compromised router along the path followed by an IPsec tunnel, in the 237 external unsecure black network. But more simply, the attacker can 238 also be attached to the same unsecure WiFi network (e.g., that sends 239 WiFi frames in the clear, without any WPA/WPA2 security) as the 240 target user that connects to his home network through an IPsec VPN. 242 -- Editor's note: the experiments conducted so far are only 243 considering an attacker located on a compromised router along the 244 path. The second configuration, where the attacker takes 245 advantage of an unsecure WiFi network, remains to be tested. -- 247 5. Launching the PTB-PTS attack 249 5.1. Test configuration 251 +------+ +-------+ +--------+ +-------+ +------+ 252 |client|----->| IPsec |----->| compr. |----->| IPsec |----->|client| 253 +------+ | gw1 | | router | | gw2 | +------+ 254 +-------+ +--------+ +-------+ 255 OS Linux Linux Linux OS 256 ssh or ftp Openswan Openswan ssh or ftp 257 initiator destination 259 Figure 1: Test configuration. 261 The results collected in this document have been achieved with the 262 configuration depicted in Figure 1. Five virtual machines are 263 created (with VirtualBox). The compromised router and two IPsec 264 gateways use Ubuntu 14.04.2 LTS. The IPsec gateways use the Openswan 265 IPsec implementation [Openswan] with its default configuration. The 266 two clients use either Ubuntu 14.04.2 LTS or Windows 7. The MTU on 267 the various (virtual) links is configured to the usual 1500 byte 268 Ethernet value. 270 TCP connection is tested either through ssh (that implies the 271 transmission of keying material whose size is larger than the MTU) or 272 FTP (that implies the transmission of a large file). With both 273 tools, the three-way TCP connection handshake succeeds but problems 274 may arise later when dealing with larger TCP segments. 276 Windows 7 host configuration is controlled by the EnablePMTUDiscovery 277 [EnablePMTUDiscovery] and EnablePMTUBHDetect [EnablePMTUBHDetect] 278 ("PMTU Black-Hole Detection") registers. The default configuration 279 corresponds to values (1, 0) respectively. We only tested 280 configuration 1-0 (i.e., EnablePMTUDiscovery set to 1 and 281 EnablePMTUBHDetect set to 0). 283 5.2. Step 1 (common): Forging an ICMP PTB packet from the untrusted 284 network 286 The attacker first has to forge an appropriate ICMP PTB packet (a 287 single packet is sufficient). This is done by eavesdropping a valid 288 packet from the IPsec tunnel on the untrusted network. Then the 289 attacker forges an ICMP PTB packet, specifying a very small MTU value 290 equal or smaller than 576 with IPv4 (resp. 1280 with IPv6). The 291 attacker can use 0 for instance. This packet spoofs the IP address 292 of a router of the untrusted network (in case the source IP address 293 is checked), and in order to bypass the IPsec protection mechanism 294 against blind attacks, it includes as a payload a part of the outer 295 IP packet that has just been eavesdropped. This is the only packet 296 an attacker needs to send. None of the following steps involve the 297 attacker. 299 5.3. Step 2 (common): Reset of the PMTU on the gateway 301 This ICMP packet is the processed by the IPsec gateway. As the 302 packet appears to belong to an active tunnel, the gateway stores the 303 following PMTU value in its SAD: PMTU_SAD = max(MTU_ICMP_PTB, 576) = 304 576 bytes. It is important to note that the gateway does not store a 305 proposed value smaller than the minimum guaranteed MTU, 576 (resp. 306 1280) bytes. 308 At this point, the traffic is not blocked in any way between the 309 targeted gateway and the remote end of the tunnel. Nevertheless the 310 throughput is reduced on the IPsec tunnel as any packet exceeding the 311 PMTU_SAD size must be fragmented (usually by the end-host). 313 5.4. Following steps with Linux, TCP/IPv4 and PMTUd 315 The following steps depend on the end-host client Operating System 316 (OS), IP version, and MTU discovery protocol. In case of Linux 317 (Ubuntu 14.04.2 LTS is the OS of all the machines, end-hosts and 318 IPsec gateway), TCP (i.e., during an ssh connection attempt to the 319 remote end-host), IPv4, PMTUd, we observe the following. 321 The TCP 3-way handshake performs normally as all TCP segments are of 322 tiny size, which enables the attacker to intercept a packet on the 323 IPsec tunnel and to perform the above attack (steps 1 and 2). Then a 324 large packet is sent with the IPv4 Don't Fragment (DF) bit turned 325 one. 327 This packet gets rejected by the IPsec gateway as it exceeds the 328 PMTU_SAD value stored in the SAD, and an ICMP PTB error packet is 329 sent back with the following MTU indication: MTU = PMTU_SAD - 330 IP_IPsec_ESP_encapsulation_size. Due to the encapsulation header 331 (whose size depends on the chosen ciphering algorithm), the gateway 332 restricts the MTU value to 502 bytes. 334 Upon receiving this ICMP PTB packet, the large TCP segment is 335 fragmented. Nevertheless, instead of creating 502 byte long packets 336 as requested by the gateway, TCP chooses to reduce the MSS to 500 337 bytes only as it considers the value advertised by the ICMP PTB is 338 below what should be accepted by any link. More precisely, with 339 Linux there is a minimum PMTU configuration parameter (e.g., cat 340 /proc/sys/net/ipv4/route/min_pmtu returns 552 on Debian "Squeeze") 341 that is preferred to the value advertised by the ICMP PTB message: 342 PMTU = max(MTU_ICMP_PTB , PMTU_config). So, once the TCP/IP headers 343 are added, the 500 byte long TCP segment results in a 552 byte long 344 packet. 346 Since it remains too large, the packet is dropped by the gateway and 347 this latter replies with the same ICMP PTB packets, with the same 348 result. 350 After 2 minutes of failures and a total of 10 re-transmission 351 attempts, the ssh server closes the connection (FIN/ACK exchange 352 quickly followed by a RST). The DoS successfully prevented any ssh 353 setup. 355 5.5. Following steps with Linux, TCP/IPv4 and PLPMTUd 357 In case of TCP/IPv4 and PLPMTUd, we observe the following. 359 The TCP 3-way handshake performs normally. Then a large packet is 360 sent with the IPv4 Don't Fragment (DF) bit turned one. 362 This packet gets rejected by the IPsec gateway and an ICMP PTB is 363 returned to the end-host that restricts the MTU to 502 bytes. 365 Although PLPMTUd is not dependant on ICMP, this error message is 366 immediately taken into account and several TCP segments of maximum 367 size 500 bytes are sent. Once the TCP/IP headers are added, the 500 368 byte long TCP segment results in a 552 byte long packet. 370 Since it remains too large, the packet is dropped by the gateway and 371 this latter replies with the same ICMP PTB packets, with the same 372 result. 374 This pattern happens 5 times, generating a total of 6 ICMP PTB 375 packets including the first one. 377 Then, 6.3 seconds after the TCP connection establishment, the PLPMTUd 378 component decides to drastically reduce the segment size: instead of 379 500 byte TCP segments, it now sends a sequence of alternatively 256 380 byte TCP segment followed by a 244 byte TCP segment. Those segment 381 are typically probes, chosen by PLPMTUd in order to test this value. 383 Since the resulting packets are Small enough (at most 256 + 52 = 308 384 bytes), they reach the other side that acknowledges them. The ssh 385 connection finishes after a few additional segments and a prompt 386 appears in the terminal. 388 To conclude a delay of 6.3s was required for the ssh connection to be 389 setup. Additionally, any packet leaving the host after this initial 390 delay contains at most 256 bytes of TCP payload, which significantly 391 reduces the TCP throughput and consumes more resources in the 392 forwarding nodes. 394 5.6. Following steps with Linux, TCP/IPv6 and PMTUd 396 In case of TCP/IPv6 and PMTUd, we observe the following. 398 The situation is pretty the same as with IPv4. The main difference 399 is the ICMP PTB packet that advertises a MTU of 1198 bytes (i.e., 400 1280 minus the various IPsec encapsulation headers). Upon receiving 401 this ICMP PTB packet, the large TCP segment is fragmented into TCP 402 segments of maximum size 1200 bytes. Once the TCP/IPv6 headers are 403 added, it results into packets of maximum size 1256 bytes, which is 404 too large for the IPsec gateway. 406 After 2 minutes of failures and a total of 10 re-transmission 407 attempts, the ssh server closes the connection (FIN/ACK exchange 408 quickly followed by a RST). The DoS successfully prevented any ssh 409 setup. 411 5.7. Following steps with Linux, TCP/IPv6 and PLPMTUd 413 In case of TCP/IPv6 and PLPMTUd, we observe the following. 415 The situation is pretty the same as with IPv4. However upon 416 receiving the ICMP PTB packet that advertises a MTU of 1198 bytes, 417 the end-host first tries to use TCP MSS=1200 which is too large for 418 the IPsec gateway. A total of 4 re-transmissions happen, generating 419 a total of 5 ICMP PTB packets including the first one. 421 Then, 3.3 seconds after the beginning, the end-host tries with TCP 422 MSS=504. Once the TCP/IPv6 headers are added, it results into 423 packets of maximum size 560 bytes, which is acceptable for the IPsec 424 gateway. The ssh connection finishes after a few additional segments 425 and a prompt appears in the terminal. 427 To conclude a delay of 3.3s was required for the ssh connection to be 428 setup (compared to 6.3 in case of IPv4). Additionally, any packet 429 leaving the host after this initial delay contains at most 504 bytes 430 of TCP payload, far below the 1280 minimum MTU guaranteed by IPv6. 431 This behavior significantly reduces the TCP throughput and consumes 432 more resources in the forwarding nodes. 434 5.8. Following steps with Windows 7, TCP/IPv4 and default PMTU 435 discovery 437 In case of TCP/IPv4 and PMTU-1-0 (default configuration), we observe 438 the following. 440 The TCP 3-way handshake performs normally. Then a large packet is 441 sent with the IPv4 Don't Fragment (DF) bit turned one. This packet 442 gets rejected by the IPsec gateway which returns an ICMP PTB with the 443 MTU value to 502 bytes. 445 Upon receiving this ICMP PTB packet, the Windows 7 end-host sends a 446 smaller TCP segment, of size 556 bytes (instead of 502 bytes). Once 447 the TCP/IP headers are added, this TCP segment results in a 596 byte 448 long packet. 450 This packet is still too large for the IPsec gateway, however the 451 IPv4 DF bit is now turned off, which authorizes the IPsec gateway to 452 perform IP fragmentation. It therefore gets fragmented by IP within 453 the IPsec gateway, then reassembled on the other side of the tunnel, 454 and acknowledged. 456 Upon receiving this TCP acknowledgment, the PLPMTUd mechanism starts 457 (Windows 7 merges PMTUd and PLPMTUd like mechanisms together). The 458 following TCP segment is now of size 1112 (i.e., 1152 with TCP/IPv4 459 headers), here also with the DF bit turned off. This large packet 460 therefore gets fragmented by IP within the IPsec gateway, then 461 reassembled on the other side of the tunnel, and acknowledged by the 462 remote TCP. 464 The process continues, with TCP segment sizes that progressively 465 increase (we observed a maximum value of 63,940 bytes!), always with 466 the DF bit turned off. All of them are IP fragmented into small IP 467 datagrams of size 548 bytes or 120 bytes. The traffic on the IPsec 468 tunnel is therefore composed of a many tiny packets (never more than 469 548 bytes long), which creates a huge performance penalty in case of 470 high rate data flows. 472 5.9. Following steps with Windows 7, TCP/IPv6 and default PMTU 473 discovery 475 In case of TCP/IPv6 and PMTU-1-0 (default configuration), we observe 476 the following. 478 The TCP 3-way handshake performs normally. Then a large packet is 479 sent. This packet gets rejected by the IPsec gateway which returns 480 an ICMP PTB with the MTU value set to 1198 bytes (as in Section 5.6). 482 Upon receiving this ICMP PTB packet, TCP segments have maximum size 483 1212 bytes (1276 bytes with the TCP/IPv6 headers), which is too large 484 for the IPsec gateway. However the end-host, upon receiving the same 485 ICMP PTB packet, keeps on using MSS=1212, resulting in the same 486 problem. 488 After 10 transmission attempts and 21 seconds, the ftp client closes 489 the connection (with a RST). The DoS successfully prevented any ssh 490 setup. 492 5.10. Other configurations 494 Several tcpdump traces, collected when the end-hosts and gateways run 495 a stable "Squeeze" Debian distribution (instead of Ubuntu), can be 496 found in [Jacquin14]. Note there are some differences (e.g., ICMP 497 PTB proposes an MTU of 514 bytes rather than 502). 499 6. Summary of the results 501 The following tables summarize the consequences of a PTB-PTS attack 502 on a host located in the secure network, behind the IPsec gateway. 504 6.1. Linux end-hosts 505 +------------+------------------------------------------------------+ 506 | Conditions | Results of a PTB-PTS attack | 507 +------------+------------------------------------------------------+ 508 | TCP/IPv4, | DoS: no ssh connection setup (TCP close after 2 mn) | 509 | PMTUd | | 510 | TCP/IPv4, | Major performance impacts: initial 6.3 second delay, | 511 | PLPMTUd | then tiny packets (TCP MSS=256) | 512 | UDP/IPv4, | Major performance impacts: tiny packets | 513 | PMTUd | | 514 | TCP/IPv6, | DoS: no ssh connection setup (TCP close after 2 mn) | 515 | PMTUd | | 516 | TCP/IPv6, | Important performance impacts: initial 3.3 second | 517 | PLPMTUd | delay, then small packets (TCP MSS=504) | 518 | UDP/IPv6, | TODO | 519 | PMTUd | | 520 +------------+------------------------------------------------------+ 522 Results of the attack when the hosts run Linux (Ubuntu 14.04.2 LTS) 523 and IPsec gateways run Linux (Ubuntu 14.04.2 LTS) 525 6.2. Windows 7 end-hosts 527 +----------------+--------------------------------------------------+ 528 | Conditions | Results of a PTB-PTS attack | 529 +----------------+--------------------------------------------------+ 530 | TCP/IPv4, | Functional, but performance impacts (548 and 120 | 531 | PMTU-1-0 | byte IP fragments) | 532 | UDP/IPv4 | TODO | 533 | TCP/IPv6, | DoS: no ftp transfer possible (TCP close after | 534 | PMTU-1-0 | 21 sec) | 535 | UDP/IPv6, | TODO | 536 | PMTUd | | 537 +----------------+--------------------------------------------------+ 539 Results of the attack when the hosts run Windows 7 and IPsec gateways 540 run Linux (Ubuntu 14.04.2 LTS) 542 7. Discussion 544 7.1. The two core issues 546 This work highlights two issues: 548 Issue 1: determining the legitimacy of untrusted ICMP PTB packets 550 The two security measures W.R.T. the processing of ICMP/ICMPv6 551 packets in IPsec and in particular the ICMP PTB packets, namely 552 the outer header verification and payload verification, are 553 essential to avoid blind attacks, but not sufficient if the 554 attacker is on the path followed by the IPsec tunnel. This is a 555 fundamental limit of the current IPsec specifications. 557 Issue 2: dealing with minimum Path MTU in presence of a tunnel 559 When the Path MTU advertised to the IPsec gateway approaches the 560 minimum MTU each link technology should support (i.e., 576 bytes 561 or 1280), problems can arise as IPsec tunnelling adds the 562 IP/IPsec/ESP headers. There are two sides to the problem: 564 First of all, at the end-host level, we observe that a Linux host 565 does not accept the Path MTU advertised by the IPsec gateway if it 566 is smaller than the minimum MTU configured locally. Indeed, the 567 local component that takes this decision is not aware that the 568 gateway operates an IPsec tunnel and needs some additional room. 569 With the PMTUd approach, the compliance on the minimum MTU is 570 strict and a DoS results. With the PLPMTUd approach, the end-host 571 pragmatically uses (after some time) a TCP segment size 572 significantly lower than this locally configured minimum MTU and 573 the Path MTU advertised by the IPsec gateway. Communications are 574 feasible, but in a sub-optimal way. 576 The second side of the problem is that the IPsec gateway should 577 not accept from the black network an ICMP PTB asking to reduce the 578 MTU to 576 bytes (resp. 1280 with IPv6). However there is a 579 fundamental contradiction here since 576 bytes (resp. 1280) is a 580 valid MTU value for a link. This is typically a situation where 581 an alarm should be sent to the IPsec gateway administrator, which 582 is not the case today. 584 7.2. Trivial unsatisfying counter-measures 586 A trivial counter measure to mitigate the attack consists in 587 configuring the IPsec gateway so that IPv4 packets are fragmented 588 regardless of the original DF bit setting. This is feasible (and 589 recommended) with Cisco IOS 12.2(11)T and above ([Cisco-DF], "DF Bit 590 Override Functionality with IPsec Tunnels" section). However, as 591 mentioned in [Cisco-DF], "a significant performance impact occurs at 592 high data rate", and ignoring the DF bit cannot be considered as a 593 valid approach. 595 Another trivial counter measure consists in ignoring all ICMP PTB 596 packets coming from the unsecure network. However, this choice 597 compromises PMTUd that the use of PLPMTUd within end-hosts will not 598 totally compensate (e.g., PLPMTUd is only applicable to protocols 599 like TCP relying on acknowledgements, no to UDP). 601 7.3. Potential solutions 603 A more interesting choice consists in refusing to reduce the MTU 604 below 576 (resp. 1280) after subtracting the IP/IPsec/ESP 605 encapsulation headers (e.g., an alarm should be sent to the IPsec 606 gateway administrator if this happens). Doing so, the MTU advertised 607 to end-host in ICMP PTB messages will always be at least equal to the 608 minimum MTU any link should provide, which avoids the initial delays 609 and denial of service discussed in this document within the end- 610 hosts. This is not totally satisfying though, given that the attack 611 succeeds in reducing the PMTU. 613 Therefore, in addition to refusing to reduce the MTU below the 614 minimum MTU, a second complementary approach could be the following: 615 since the legitimacy of an untrusted ICMP packet cannot be 616 determined, the IPsec gateway should to confirm the information with 617 a side mechanism, a PLPMTUd-like probing. It could work as follows. 618 The gateway generates a probing packet of a certain size and that is 619 sent inside the IPsec tunnel. Upon reception, the remote IPsec 620 gateway acknowledges this probe, otherwise a timeout occurs at the 621 gateway that sent the probe. Therefore, if the probing mechanism 622 does not confirm the ICMP PTB information received from the unsecure 623 Internet, this ICMP packet is simply ignored. 625 For this mechanism to be effective, the attacker should not be able 626 to identify in real time the probing packets in the tunnel in order 627 to discard them selectively. However being able to drop selectively 628 some packets goes far beyond the attacker model considered in this 629 document (Section 4). Additionally, an IPsec gateway level probing 630 mechanism, done periodically, cannot be as reactive as the PMTUd 631 approach (assuming ICMP packets are not filtered out) in case of path 632 MTU change, for instance after a change of route. Therefore we 633 believe that both mechanisms could safely work in parallel. 635 8. Security Considerations 637 This I-D is all about security. It identifies a potential attack 638 that leverages on IPsec to attack end-hosts located behind the 639 gateways, in the secure networks. The attack effectiveness depends 640 on the exact end-host configuration: operating system, transport 641 protocol, IP version, MTU discovery mechanism, as detailed in this 642 document. 644 9. IANA Considerations 646 N/A 648 10. Acknowledgments 650 The authors would like to acknowledge Ludovic Jacquin as the main 651 contributor to the first experiments and author of [Jacquin14]. 653 11. References 655 11.1. Normative References 657 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 658 Requirement Levels", BCP 14, RFC 2119, March 1997. 660 11.2. Informative References 662 [Cisco-DF] 663 Cisco Systems, , "IPsec Data Plane Configuration Guide, 664 Cisco IOS Release 15MT", 2012, 665 . 669 [EnablePMTUBHDetect] 670 Microsoft TechNet, , "EnablePMTUBHDetect", 671 . 674 [EnablePMTUDiscovery] 675 Microsoft TechNet, , "EnablePMTUDiscovery", 676 . 679 [Jacquin12] 680 Jacquin, L., Roca, V., Kaafar, M., Schuler, F., and J-L. 681 Roch, "IBTrack: An ICMP Black holes Tracker", IEEE Global 682 Communications Conference (GLOBECOM'12) , December 2012, 683 . 685 [Jacquin14] 686 Jacquin, L., Roca, V., and J-L. Roch, "Too Big or Too 687 Small? The PTB-PTS ICMP-based Attack against IPsec 688 Gateways", IEEE Global Communications Conference 689 (GLOBECOM'14) , December 2014, . 692 [Openswan] 693 "Openswan", . 695 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 696 November 1990. 698 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 699 Discovery", RFC 4821, March 2007. 701 Authors' Addresses 703 Vincent Roca 704 INRIA 705 655, av. de l'Europe 706 Inovallee; Montbonnot 707 ST ISMIER cedex 38334 708 France 710 Email: vincent.roca@inria.fr 711 URI: http://privatics.inrialpes.fr/people/roca/ 713 Saikou Fall 714 INRIA 715 655, av. de l'Europe 716 Inovallee; Montbonnot 717 ST ISMIER cedex 38334 718 France 720 Email: saikou.fall@inria.fr