Too Big or Too Small? The PTB-PTS ICMP-based Attack against IPsec Gateways Vincent Roca, Saikou Fall To cite this version: Vincent Roca, Saikou Fall. Too Big or Too Small? The PTB-PTS ICMP-based Attack against IPsec Gateways. 2016, pp.16. hal-01178390 HAL Id: hal-01178390 https://hal.inria.fr/hal-01178390 Submitted on 19 Jul 2015 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. IPsec Maintenance and Evolution (IPSECME) V. Roca Internet-Draft S. Fall Intended status: Informational INRIA Expires: January 7, 2016 July 6, 2015 Too Big or Too Small? The PTB-PTS ICMP-based Attack against IPsec Gateways draft-roca-ipsecme-ptb-pts-attack-00 Abstract This document introduces the "Packet Too Big"-"Packet Too Small" Internet Control Message Protocol (ICMP) based attack against IPsec gateways. We explain how an attacker having eavesdropping and packet injection capabilities, from the unsecure network where he only sees encrypted packets, can force a gateway to reduce the Path Maximum Transmission Unit (PMTU) of an IPsec tunnel to the minimum, which can trigger severe issues for the hosts behind this gateway: with a Linux host, depending on the PMTU discovery algorithm in use (i.e., PMTUd versus PLPMTUd) and protocol (TCP versus UDP), the attack either creates a Denial of Service or major performance penalties. This attack highlights two fundamental problems, namely: (1) the impossibility to distinguish legitimate from illegitimate ICMP packets coming from the untrusted network, and (2) the contradictions in the way Path MTU is managed by some end hosts when this Path MTU is below the minimum packet size any link should support because of the IPsec encapsulation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 7, 2016. Roca & Fall Expires January 7, 2016 [Page 1] Internet-Draft The PTB-PTS attack against IPsec July 2015 Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . 3 2. Notations, Definitions and Abbreviations . 4 2.1. Requirements Notation . 4 2.2. Abbreviations . 4 3. About Path MTU discovery . 4 3.1. The legacy PMTUd mechanism . 4 3.2. The Packetization Layer PMTUd mechanism . 5 4. The attacker model . 5 5. Launching the PTB-PTS attack . 6 5.1. Test configuration . 6 5.2. Step 1 (common): Forging an ICMP PTB packet from the untrusted network . 7 5.3. Step 2 (common): Reset of the PMTU on the gateway . 7 5.4. Following steps with Linux, TCP/IPv4 and PMTUd . 7 5.5. Following steps with Linux, TCP/IPv4 and PLPMTUd . 8 5.6. Following steps with Linux, TCP/IPv6 and PMTUd . 9 5.7. Following steps with Linux, TCP/IPv6 and PLPMTUd . 9 5.8. Following steps with Windows 7, TCP/IPv4 and default PMTU discovery . 10 5.9. Following steps with Windows 7, TCP/IPv6 and default PMTU discovery . 11 5.10. Other configurations . 11 6. Summary of the results . 11 6.1. Linux end-hosts . 11 6.2. Windows 7 end-hosts . 12 7. Discussion . 12 7.1. The two core issues . 12 7.2. Trivial unsatisfying counter-measures . 13 7.3. Potential solutions . 14 8. Security Considerations . 14 9. IANA Considerations . 14 Roca & Fall Expires January 7, 2016 [Page 2] Internet-Draft The PTB-PTS attack against IPsec July 2015 10. Acknowledgments . 15 11. References . 15 11.1. Normative References . 15 11.2. Informative References . 15 Authors’ Addresses . 16 1. Introduction IPsec interacts with the Internet Control Message Protocol (ICMP). A first goal of ICMP is to exchange control and error messages, like packet processing error notifications. But ICMP is also involved in several functionalities and in particular the Path Maximum Transmission Unit discovery (PMTUd) mechanism [RFC1191], whose goal is to find the maximum packet size on a path that avoids packet fragmentation. Such a mechanism is essential from a performance point of view: if a packet is too large, its fragmentation and reassembly will negatively impact performance. At the other extreme, if a packet is significantly smaller than the maximum size permitted throughout the path, it will also negatively impact performance. Assessing the correct packet size on a path is therefore essential. But ICMP is also known to be a cause of attacks and therefore there is an incentive for a network administrator to filter out these packets (see [Jacquin12] for a detailed analysis of the situation). A balance is therefore required between these contradictory objectives, and it is recognized that only a subset of ICMP packets should be considered by IPsec gateways. In this document we assume that the target IPsec gateway accepts and processes the ICMP "Destination unreachable"/"Fragmentation needed" (with IPv4) or ICMPv6 "Packet Too Big"/"Fragmentation needed" (with IPv6) packets coming from the unsecure network. For simplification purposes, the term "ICMP PTB" will be used throughout this document to denote either of these ICMP packets. The PTB-PTS attack is carried out from the untrusted network, and through the IPsec gateway, the attack targets hosts in the trusted network, behind the gateway. We assume the attacker can eavesdrop and inject traffic on the untrusted network Section 4, i.e., we assume the attacker is on the path followed by the tunnel (which is trivial in case of an unsecure WiFi network). A single ICMP PTB packet is sufficient for the attack, this ICMP advertising an MTU close or below the minimum MTU any link technology must support: 576 in IPv4 and 1280 in IPv6. Because of the IPsec ESP encapsulation, the IPsec gateway then advertises an MTU below this minimum to the local hosts, thereby creating confusion among them. The consequences on the end-hosts can be serious, ranging from performance impacts to Denial of Services (DoS), depending on the exact configuration: operating system (e.g., Linux versus Windows), protocol (e.g., TCP Roca & Fall Expires January 7, 2016 [Page 3] Internet-Draft The PTB-PTS attack against IPsec July 2015 versus UDP or IPv4 versus IPv6), and internal parameters (e.g., PMTUd versus PLPMTUd). The present document details both the attack and its consequences on the end-host, depending on the exact configuration. Note that some parts of the present document are not specific to IPsec and similar attacks could be launched in other situations where a gateway need to encapsulate some traffic in a tunnel. 2. Notations, Definitions and Abbreviations 2.1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2.2. Abbreviations This document uses the following abbreviations. ICMP PTB: Either an ICMP "Destination unreachable"/"Fragmentation needed" packet (IPv4) or ICMPv6 "Packet Too Big"/"Fragmentation needed" (IPv6), depending on the context PTB-PTS: Packet Too Big-Packet Too Small 3. About Path MTU discovery Path MTU discovery (PMTUd) is a key mechanism for optimum network performance since it enables a sender to determine the appropriate packet size along a path dynamically (the path may change over time). Two complementary PMTU discovery algorithms are in use: PMTUd and PLPMTUd. 3.1. The legacy PMTUd mechanism PMTUd [RFC1191] is the legacy approach. Let us illustrate its behavior in an IPv4 (resp. IPv6) network. A sender sets the IPv4 Don’t Fragment (DF) bit in a packet (useless in IPv6 as fragmentation is prohibited). If a router cannot transmit this packet because of its size, it must send back to the sender an ICMP "Destination unreachable"/"Fragmentation needed" packet (resp. an ICMPv6 "Packet Too Big"/"Fragmentation needed"), along with the next hop MTU Roca & Fall Expires January 7, 2016 [Page 4] Internet-Draft The PTB-PTS attack against IPsec July 2015 information. In the following we will call these error packets ICMP PTB (Packet Too Big), regardless of whether IPv4 or IPv6 is used. Iteratively, upon receiving such an ICMP PTB packet, the sender decreases the packet size until it reaches the lowest MTU on the path to the destination. The PMTU is then found and will be used by the sender for outgoing packets sent to this destination.