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.  Since the path
   can change dynamically (e.g., due to re-routing), this process needs
   to be performed periodically.  Although efficient, the PMTUd approach
   suffers from several limits, mainly because ICMP packets are often
   filtered out by some routers/firewalls along their route to the
   sender.  In that case the sender needs another technique to discover
   the Path MTU.

3.2.  The Packetization Layer PMTUd mechanism

   To overcome these issues, a new Path MTU discovery mechanism has been
   developed, that does not rely on ICMP, the Packetization Layer PMTUd
   (PLPMTUd) [RFC4821].  Instead of using ICMP, it relies on a
   packetization layer protocol with an acknowledgement mechanism, such
   as TCP.  Using TCP, the sender sends probing packets of a specific
   size to the destination.  If the probing packet is acknowledged, the
   sender validates that the PMTU is at least equal to the probing
   packet size, while a time-out indicates that the PMTU is smaller.
   With TCP, any data segment can be used as a probing packet if enough
   data is available to fill in the payload.  Here also, because the
   path may change, the PLPMTUd process needs to be performed
   periodically.

4.  The attacker model

   In this document, we consider that all the attacks are conducted by
   adversaries located on the external unsecure black network.  We
   assume an attacker can both eavesdrop the traffic in the IPsec tunnel
   and inject forged packets.  We also assume an attacker has no way to
   decrypt packets nor encrypt its own packets because the underlying
   IPsec cryptographic building blocks and key exchange protocols are
   considered secure.  The goal of the attacker is to launch a DoS
   against the secure tunnel service provided by IPsec gateways, for
   both kinds of IPsec configurations: host-to-site and site-to-site.
   Note that in a host-to-site configuration, where a nomad host
   remotely connects to its home network through an IPsec tunnel, the
   remote site gateway is the target, not the isolated host.

   A requirement is for the attacker to be on the path followed by the
   IPsec tunnel.  For instance, the attacker can be located on a
   compromised router along the path followed by an IPsec tunnel, in the
   external unsecure black network.  But more simply, the attacker can
   also be attached to the same unsecure WiFi network (e.g., that sends



Roca & Fall              Expires January 7, 2016                [Page 5]


Internet-Draft      The PTB-PTS attack against IPsec           July 2015


   WiFi frames in the clear, without any WPA/WPA2 security) as the
   target user that connects to his home network through an IPsec VPN.

      -- Editor's note: the experiments conducted so far are only
      considering an attacker located on a compromised router along the
      path.  The second configuration, where the attacker takes
      advantage of an unsecure WiFi network, remains to be tested. --

5.  Launching the PTB-PTS attack

5.1.  Test configuration

   +------+      +-------+      +--------+      +-------+      +------+
   |client|----->| IPsec |----->| compr. |----->| IPsec |----->|client|
   +------+      |  gw1  |      | router |      |  gw2  |      +------+
                 +-------+      +--------+      +-------+
      OS           Linux          Linux           Linux           OS
   ssh or ftp     Openswan                       Openswan     ssh or ftp
   initiator                                                 destination

                       Figure 1: Test configuration.

   The results collected in this document have been achieved with the
   configuration depicted in Figure 1.  Five virtual machines are
   created (with VirtualBox).  The compromised router and two IPsec
   gateways use Ubuntu 14.04.2 LTS.  The IPsec gateways use the Openswan
   IPsec implementation [Openswan] with its default configuration.  The
   two clients use either Ubuntu 14.04.2 LTS or Windows 7.  The MTU on
   the various (virtual) links is configured to the usual 1500 byte
   Ethernet value.

   TCP connection is tested either through ssh (that implies the
   transmission of keying material whose size is larger than the MTU) or
   FTP (that implies the transmission of a large file).  With both
   tools, the three-way TCP connection handshake succeeds but problems
   may arise later when dealing with larger TCP segments.

   Windows 7 host configuration is controlled by the EnablePMTUDiscovery
   [EnablePMTUDiscovery] and EnablePMTUBHDetect [EnablePMTUBHDetect]
   ("PMTU Black-Hole Detection") registers.  The default configuration
   corresponds to values (1, 0) respectively.  We only tested
   configuration 1-0 (i.e., EnablePMTUDiscovery set to 1 and
   EnablePMTUBHDetect set to 0).








Roca & Fall              Expires January 7, 2016                [Page 6]


Internet-Draft      The PTB-PTS attack against IPsec           July 2015


5.2.  Step 1 (common): Forging an ICMP PTB packet from the untrusted
      network

   The attacker first has to forge an appropriate ICMP PTB packet (a
   single packet is sufficient).  This is done by eavesdropping a valid
   packet from the IPsec tunnel on the untrusted network.  Then the
   attacker forges an ICMP PTB packet, specifying a very small MTU value
   equal or smaller than 576 with IPv4 (resp. 1280 with IPv6).  The
   attacker can use 0 for instance.  This packet spoofs the IP address
   of a router of the untrusted network (in case the source IP address
   is checked), and in order to bypass the IPsec protection mechanism
   against blind attacks, it includes as a payload a part of the outer
   IP packet that has just been eavesdropped.  This is the only packet
   an attacker needs to send.  None of the following steps involve the
   attacker.

5.3.  Step 2 (common): Reset of the PMTU on the gateway

   This ICMP packet is the processed by the IPsec gateway.  As the
   packet appears to belong to an active tunnel, the gateway stores the
   following PMTU value in its SAD: PMTU_SAD = max(MTU_ICMP_PTB, 576) =
   576 bytes.  It is important to note that the gateway does not store a
   proposed value smaller than the minimum guaranteed MTU, 576 (resp.
   1280) bytes.

   At this point, the traffic is not blocked in any way between the
   targeted gateway and the remote end of the tunnel.  Nevertheless the
   throughput is reduced on the IPsec tunnel as any packet exceeding the
   PMTU_SAD size must be fragmented (usually by the end-host).

5.4.  Following steps with Linux, TCP/IPv4 and PMTUd

   The following steps depend on the end-host client Operating System
   (OS), IP version, and MTU discovery protocol.  In case of Linux
   (Ubuntu 14.04.2 LTS is the OS of all the machines, end-hosts and
   IPsec gateway), TCP (i.e., during an ssh connection attempt to the
   remote end-host), IPv4, PMTUd, we observe the following.

   The TCP 3-way handshake performs normally as all TCP segments are of
   tiny size, which enables the attacker to intercept a packet on the
   IPsec tunnel and to perform the above attack (steps 1 and 2).  Then a
   large packet is sent with the IPv4 Don't Fragment (DF) bit turned
   one.

   This packet gets rejected by the IPsec gateway as it exceeds the
   PMTU_SAD value stored in the SAD, and an ICMP PTB error packet is
   sent back with the following MTU indication: MTU = PMTU_SAD -
   IP_IPsec_ESP_encapsulation_size.  Due to the encapsulation header



Roca & Fall              Expires January 7, 2016                [Page 7]


Internet-Draft      The PTB-PTS attack against IPsec           July 2015


   (whose size depends on the chosen ciphering algorithm), the gateway
   restricts the MTU value to 502 bytes.

   Upon receiving this ICMP PTB packet, the large TCP segment is
   fragmented.  Nevertheless, instead of creating 502 byte long packets
   as requested by the gateway, TCP chooses to reduce the MSS to 500
   bytes only as it considers the value advertised by the ICMP PTB is
   below what should be accepted by any link.  More precisely, with
   Linux there is a minimum PMTU configuration parameter (e.g., cat
   /proc/sys/net/ipv4/route/min_pmtu returns 552 on Debian "Squeeze")
   that is preferred to the value advertised by the ICMP PTB message:
   PMTU = max(MTU_ICMP_PTB , PMTU_config).  So, once the TCP/IP headers
   are added, the 500 byte long TCP segment results in a 552 byte long
   packet.

   Since it remains too large, the packet is dropped by the gateway and
   this latter replies with the same ICMP PTB packets, with the same
   result.

   After 2 minutes of failures and a total of 10 re-transmission
   attempts, the ssh server closes the connection (FIN/ACK exchange
   quickly followed by a RST).  The DoS successfully prevented any ssh
   setup.

5.5.  Following steps with Linux, TCP/IPv4 and PLPMTUd

   In case of TCP/IPv4 and PLPMTUd, we observe the following.

   The TCP 3-way handshake performs normally.  Then a large packet is
   sent with the IPv4 Don't Fragment (DF) bit turned one.

   This packet gets rejected by the IPsec gateway and an ICMP PTB is
   returned to the end-host that restricts the MTU to 502 bytes.

   Although PLPMTUd is not dependant on ICMP, this error message is
   immediately taken into account and several TCP segments of maximum
   size 500 bytes are sent.  Once the TCP/IP headers are added, the 500
   byte long TCP segment results in a 552 byte long packet.

   Since it remains too large, the packet is dropped by the gateway and
   this latter replies with the same ICMP PTB packets, with the same
   result.

   This pattern happens 5 times, generating a total of 6 ICMP PTB
   packets including the first one.

   Then, 6.3 seconds after the TCP connection establishment, the PLPMTUd
   component decides to drastically reduce the segment size: instead of



Roca & Fall              Expires January 7, 2016                [Page 8]


Internet-Draft      The PTB-PTS attack against IPsec           July 2015


   500 byte TCP segments, it now sends a sequence of alternatively 256
   byte TCP segment followed by a 244 byte TCP segment.  Those segment
   are typically probes, chosen by PLPMTUd in order to test this value.

   Since the resulting packets are Small enough (at most 256 + 52 = 308
   bytes), they reach the other side that acknowledges them.  The ssh
   connection finishes after a few additional segments and a prompt
   appears in the terminal.

   To conclude a delay of 6.3s was required for the ssh connection to be
   setup.  Additionally, any packet leaving the host after this initial
   delay contains at most 256 bytes of TCP payload, which significantly
   reduces the TCP throughput and consumes more resources in the
   forwarding nodes.

5.6.  Following steps with Linux, TCP/IPv6 and PMTUd

   In case of TCP/IPv6 and PMTUd, we observe the following.

   The situation is pretty the same as with IPv4.  The main difference
   is the ICMP PTB packet that advertises a MTU of 1198 bytes (i.e.,
   1280 minus the various IPsec encapsulation headers).  Upon receiving
   this ICMP PTB packet, the large TCP segment is fragmented into TCP
   segments of maximum size 1200 bytes.  Once the TCP/IPv6 headers are
   added, it results into packets of maximum size 1256 bytes, which is
   too large for the IPsec gateway.

   After 2 minutes of failures and a total of 10 re-transmission
   attempts, the ssh server closes the connection (FIN/ACK exchange
   quickly followed by a RST).  The DoS successfully prevented any ssh
   setup.

5.7.  Following steps with Linux, TCP/IPv6 and PLPMTUd

   In case of TCP/IPv6 and PLPMTUd, we observe the following.

   The situation is pretty the same as with IPv4.  However upon
   receiving the ICMP PTB packet that advertises a MTU of 1198 bytes,
   the end-host first tries to use TCP MSS=1200 which is too large for
   the IPsec gateway.  A total of 4 re-transmissions happen, generating
   a total of 5 ICMP PTB packets including the first one.

   Then, 3.3 seconds after the beginning, the end-host tries with TCP
   MSS=504.  Once the TCP/IPv6 headers are added, it results into
   packets of maximum size 560 bytes, which is acceptable for the IPsec
   gateway.  The ssh connection finishes after a few additional segments
   and a prompt appears in the terminal.




Roca & Fall              Expires January 7, 2016                [Page 9]


Internet-Draft      The PTB-PTS attack against IPsec           July 2015


   To conclude a delay of 3.3s was required for the ssh connection to be
   setup (compared to 6.3 in case of IPv4).  Additionally, any packet
   leaving the host after this initial delay contains at most 504 bytes
   of TCP payload, far below the 1280 minimum MTU guaranteed by IPv6.
   This behavior significantly reduces the TCP throughput and consumes
   more resources in the forwarding nodes.

5.8.  Following steps with Windows 7, TCP/IPv4 and default PMTU
      discovery

   In case of TCP/IPv4 and PMTU-1-0 (default configuration), we observe
   the following.

   The TCP 3-way handshake performs normally.  Then a large packet is
   sent with the IPv4 Don't Fragment (DF) bit turned one.  This packet
   gets rejected by the IPsec gateway which returns an ICMP PTB with the
   MTU value to 502 bytes.

   Upon receiving this ICMP PTB packet, the Windows 7 end-host sends a
   smaller TCP segment, of size 556 bytes (instead of 502 bytes).  Once
   the TCP/IP headers are added, this TCP segment results in a 596 byte
   long packet.

   This packet is still too large for the IPsec gateway, however the
   IPv4 DF bit is now turned off, which authorizes the IPsec gateway to
   perform IP fragmentation.  It therefore gets fragmented by IP within
   the IPsec gateway, then reassembled on the other side of the tunnel,
   and acknowledged.

   Upon receiving this TCP acknowledgment, the PLPMTUd mechanism starts
   (Windows 7 merges PMTUd and PLPMTUd like mechanisms together).  The
   following TCP segment is now of size 1112 (i.e., 1152 with TCP/IPv4
   headers), here also with the DF bit turned off.  This large packet
   therefore gets fragmented by IP within the IPsec gateway, then
   reassembled on the other side of the tunnel, and acknowledged by the
   remote TCP.

   The process continues, with TCP segment sizes that progressively
   increase (we observed a maximum value of 63,940 bytes!), always with
   the DF bit turned off.  All of them are IP fragmented into small IP
   datagrams of size 548 bytes or 120 bytes.  The traffic on the IPsec
   tunnel is therefore composed of a many tiny packets (never more than
   548 bytes long), which creates a huge performance penalty in case of
   high rate data flows.







Roca & Fall              Expires January 7, 2016               [Page 10]


Internet-Draft      The PTB-PTS attack against IPsec           July 2015


5.9.  Following steps with Windows 7, TCP/IPv6 and default PMTU
      discovery

   In case of TCP/IPv6 and PMTU-1-0 (default configuration), we observe
   the following.

   The TCP 3-way handshake performs normally.  Then a large packet is
   sent.  This packet gets rejected by the IPsec gateway which returns
   an ICMP PTB with the MTU value set to 1198 bytes (as in Section 5.6).

   Upon receiving this ICMP PTB packet, TCP segments have maximum size
   1212 bytes (1276 bytes with the TCP/IPv6 headers), which is too large
   for the IPsec gateway.  However the end-host, upon receiving the same
   ICMP PTB packet, keeps on using MSS=1212, resulting in the same
   problem.

   After 10 transmission attempts and 21 seconds, the ftp client closes
   the connection (with a RST).  The DoS successfully prevented any ssh
   setup.

5.10.  Other configurations

   Several tcpdump traces, collected when the end-hosts and gateways run
   a stable "Squeeze" Debian distribution (instead of Ubuntu), can be
   found in [Jacquin14].  Note there are some differences (e.g., ICMP
   PTB proposes an MTU of 514 bytes rather than 502).

6.  Summary of the results

   The following tables summarize the consequences of a PTB-PTS attack
   on a host located in the secure network, behind the IPsec gateway.

6.1.  Linux end-hosts


















Roca & Fall              Expires January 7, 2016               [Page 11]


Internet-Draft      The PTB-PTS attack against IPsec           July 2015


   +------------+------------------------------------------------------+
   | Conditions | Results of a PTB-PTS attack                          |
   +------------+------------------------------------------------------+
   | TCP/IPv4,  | DoS: no ssh connection setup (TCP close after 2 mn)  |
   | PMTUd      |                                                      |
   | TCP/IPv4,  | Major performance impacts: initial 6.3 second delay, |
   | PLPMTUd    | then tiny packets (TCP MSS=256)                      |
   | UDP/IPv4,  | Major performance impacts: tiny packets              |
   | PMTUd      |                                                      |
   | TCP/IPv6,  | DoS: no ssh connection setup (TCP close after 2 mn)  |
   | PMTUd      |                                                      |
   | TCP/IPv6,  | Important performance impacts: initial 3.3 second    |
   | PLPMTUd    | delay, then small packets (TCP MSS=504)              |
   | UDP/IPv6,  | TODO                                                 |
   | PMTUd      |                                                      |
   +------------+------------------------------------------------------+

    Results of the attack when the hosts run Linux (Ubuntu 14.04.2 LTS)
             and IPsec gateways run Linux (Ubuntu 14.04.2 LTS)

6.2.  Windows 7 end-hosts

   +----------------+--------------------------------------------------+
   | Conditions     | Results of a PTB-PTS attack                      |
   +----------------+--------------------------------------------------+
   | TCP/IPv4,      | Functional, but performance impacts (548 and 120 |
   | PMTU-1-0       | byte IP fragments)                               |
   | UDP/IPv4       | TODO                                             |
   | TCP/IPv6,      | DoS: no ftp transfer possible (TCP close after   |
   | PMTU-1-0       | 21 sec)                                          |
   | UDP/IPv6,      | TODO                                             |
   | PMTUd          |                                                  |
   +----------------+--------------------------------------------------+

   Results of the attack when the hosts run Windows 7 and IPsec gateways
                      run Linux (Ubuntu 14.04.2 LTS)

7.  Discussion

7.1.  The two core issues

   This work highlights two issues:

   Issue 1: determining the legitimacy of untrusted ICMP PTB packets

      The two security measures W.R.T. the processing of ICMP/ICMPv6
      packets in IPsec and in particular the ICMP PTB packets, namely
      the outer header verification and payload verification, are



Roca & Fall              Expires January 7, 2016               [Page 12]


Internet-Draft      The PTB-PTS attack against IPsec           July 2015


      essential to avoid blind attacks, but not sufficient if the
      attacker is on the path followed by the IPsec tunnel.  This is a
      fundamental limit of the current IPsec specifications.

   Issue 2: dealing with minimum Path MTU in presence of a tunnel

      When the Path MTU advertised to the IPsec gateway approaches the
      minimum MTU each link technology should support (i.e., 576 bytes
      or 1280), problems can arise as IPsec tunnelling adds the
      IP/IPsec/ESP headers.  There are two sides to the problem:

      First of all, at the end-host level, we observe that a Linux host
      does not accept the Path MTU advertised by the IPsec gateway if it
      is smaller than the minimum MTU configured locally.  Indeed, the
      local component that takes this decision is not aware that the
      gateway operates an IPsec tunnel and needs some additional room.
      With the PMTUd approach, the compliance on the minimum MTU is
      strict and a DoS results.  With the PLPMTUd approach, the end-host
      pragmatically uses (after some time) a TCP segment size
      significantly lower than this locally configured minimum MTU and
      the Path MTU advertised by the IPsec gateway.  Communications are
      feasible, but in a sub-optimal way.

      The second side of the problem is that the IPsec gateway should
      not accept from the black network an ICMP PTB asking to reduce the
      MTU to 576 bytes (resp. 1280 with IPv6).  However there is a
      fundamental contradiction here since 576 bytes (resp. 1280) is a
      valid MTU value for a link.  This is typically a situation where
      an alarm should be sent to the IPsec gateway administrator, which
      is not the case today.

7.2.  Trivial unsatisfying counter-measures

   A trivial counter measure to mitigate the attack consists in
   configuring the IPsec gateway so that IPv4 packets are fragmented
   regardless of the original DF bit setting.  This is feasible (and
   recommended) with Cisco IOS 12.2(11)T and above ([Cisco-DF], "DF Bit
   Override Functionality with IPsec Tunnels" section).  However, as
   mentioned in [Cisco-DF], "a significant performance impact occurs at
   high data rate", and ignoring the DF bit cannot be considered as a
   valid approach.

   Another trivial counter measure consists in ignoring all ICMP PTB
   packets coming from the unsecure network.  However, this choice
   compromises PMTUd that the use of PLPMTUd within end-hosts will not
   totally compensate (e.g., PLPMTUd is only applicable to protocols
   like TCP relying on acknowledgements, no to UDP).




Roca & Fall              Expires January 7, 2016               [Page 13]


Internet-Draft      The PTB-PTS attack against IPsec           July 2015


7.3.  Potential solutions

   A more interesting choice consists in refusing to reduce the MTU
   below 576 (resp. 1280) after subtracting the IP/IPsec/ESP
   encapsulation headers (e.g., an alarm should be sent to the IPsec
   gateway administrator if this happens).  Doing so, the MTU advertised
   to end-host in ICMP PTB messages will always be at least equal to the
   minimum MTU any link should provide, which avoids the initial delays
   and denial of service discussed in this document within the end-
   hosts.  This is not totally satisfying though, given that the attack
   succeeds in reducing the PMTU.

   Therefore, in addition to refusing to reduce the MTU below the
   minimum MTU, a second complementary approach could be the following:
   since the legitimacy of an untrusted ICMP packet cannot be
   determined, the IPsec gateway should to confirm the information with
   a side mechanism, a PLPMTUd-like probing.  It could work as follows.
   The gateway generates a probing packet of a certain size and that is
   sent inside the IPsec tunnel.  Upon reception, the remote IPsec
   gateway acknowledges this probe, otherwise a timeout occurs at the
   gateway that sent the probe.  Therefore, if the probing mechanism
   does not confirm the ICMP PTB information received from the unsecure
   Internet, this ICMP packet is simply ignored.

   For this mechanism to be effective, the attacker should not be able
   to identify in real time the probing packets in the tunnel in order
   to discard them selectively.  However being able to drop selectively
   some packets goes far beyond the attacker model considered in this
   document (Section 4).  Additionally, an IPsec gateway level probing
   mechanism, done periodically, cannot be as reactive as the PMTUd
   approach (assuming ICMP packets are not filtered out) in case of path
   MTU change, for instance after a change of route.  Therefore we
   believe that both mechanisms could safely work in parallel.

8.  Security Considerations

   This I-D is all about security.  It identifies a potential attack
   that leverages on IPsec to attack end-hosts located behind the
   gateways, in the secure networks.  The attack effectiveness depends
   on the exact end-host configuration: operating system, transport
   protocol, IP version, MTU discovery mechanism, as detailed in this
   document.

9.  IANA Considerations

   N/A





Roca & Fall              Expires January 7, 2016               [Page 14]


Internet-Draft      The PTB-PTS attack against IPsec           July 2015


10.  Acknowledgments

   The authors would like to acknowledge Ludovic Jacquin as the main
   contributor to the first experiments and author of [Jacquin14].

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

11.2.  Informative References

   [Cisco-DF]
              Cisco Systems, , "IPsec Data Plane Configuration Guide,
              Cisco IOS Release 15MT", 2012,
              <http://www.cisco.com/c/en/us/td/docs/ios-
              xml/ios/sec_conn_dplane/configuration/15-mt/
              sec-ipsec-data-plane-15-mt-book.pdf>.

   [EnablePMTUBHDetect]
              Microsoft TechNet, , "EnablePMTUBHDetect",
              <https://technet.microsoft.com/en-us/library/
              cc960465.aspx>.

   [EnablePMTUDiscovery]
              Microsoft TechNet, , "EnablePMTUDiscovery",
              <https://technet.microsoft.com/en-us/library/
              cc957539.aspx>.

   [Jacquin12]
              Jacquin, L., Roca, V., Kaafar, M., Schuler, F., and J-L.
              Roch, "IBTrack: An ICMP Black holes Tracker", IEEE Global
              Communications Conference (GLOBECOM'12) , December 2012,
              <https://hal.inria.fr/hal-00695746/en/>.

   [Jacquin14]
              Jacquin, L., Roca, V., and J-L. Roch, "Too Big or Too
              Small? The PTB-PTS ICMP-based Attack against IPsec
              Gateways", IEEE Global Communications Conference
              (GLOBECOM'14) , December 2014, <https://hal.inria.fr/hal-
              01052994/en/>.

   [Openswan]
              "Openswan", <https://www.openswan.org/>.





Roca & Fall              Expires January 7, 2016               [Page 15]


Internet-Draft      The PTB-PTS attack against IPsec           July 2015


   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              November 1990.

   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
              Discovery", RFC 4821, March 2007.

Authors' Addresses

   Vincent Roca
   INRIA
   655, av. de l'Europe
   Inovallee; Montbonnot
   ST ISMIER cedex  38334
   France

   Email: vincent.roca@inria.fr
   URI:   http://privatics.inrialpes.fr/people/roca/


   Saikou Fall
   INRIA
   655, av. de l'Europe
   Inovallee; Montbonnot
   ST ISMIER cedex  38334
   France

   Email: saikou.fall@inria.fr
























Roca & Fall              Expires January 7, 2016               [Page 16]