Re: [tsvwg] Please tell us of any topics you would like to see discussed by TSVWG at the Montreal IETF

Vincent Roca <vincent.roca@inria.fr> Fri, 08 June 2018 12:17 UTC

Return-Path: <vincent.roca@inria.fr>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70299130DFF; Fri, 8 Jun 2018 05:17:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dOyokpy3FQQ; Fri, 8 Jun 2018 05:17:08 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29FFA12785F; Fri, 8 Jun 2018 05:17:07 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.49,490,1520895600"; d="scan'208,217";a="268157072"
Received: from ral023r.vpn.inria.fr ([128.93.178.23]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jun 2018 14:17:04 +0200
From: Vincent Roca <vincent.roca@inria.fr>
Message-Id: <C558C089-AE9F-4117-8768-321A52D52900@inria.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7D6573DE-FF78-4501-941A-C1D817DCC6C5"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Date: Fri, 08 Jun 2018 14:17:03 +0200
In-Reply-To: <alpine.DEB.2.20.1806080837460.17103@uplift.swm.pp.se>
Cc: Vincent Roca <vincent.roca@inria.fr>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
References: <5B1904BF.1050608@erg.abdn.ac.uk> <alpine.DEB.2.20.1806071240420.17103@uplift.swm.pp.se> <0067B490-7398-4FD0-87E6-3E5B1229E0FE@strayalpha.com> <alpine.DEB.2.20.1806071628250.17103@uplift.swm.pp.se> <015AAF63-3DF7-47BC-A728-9B98AD178213@strayalpha.com> <alpine.DEB.2.20.1806080611090.17103@uplift.swm.pp.se> <3F8735BD-E579-4B24-BBB8-9FF7E812337D@strayalpha.com> <alpine.DEB.2.20.1806080745550.17103@uplift.swm.pp.se> <9C14655B-9823-40BD-9B3A-EBB14D4F0D1C@strayalpha.com> <alpine.DEB.2.20.1806080837460.17103@uplift.swm.pp.se>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/XieMk3J_ApyAOI5apbtiyrvir6E>
Subject: Re: [tsvwg] Please tell us of any topics you would like to see discussed by TSVWG at the Montreal IETF
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jun 2018 12:17:11 -0000

Hi Gorry et al.,

I suggest topic that is closely related to what Joe/Mikael exchange: about the minimum guaranteed MTU on a link (i.e., the 576 or 1280 limit).
This is a discussion I wanted to bring, especially as it has connections to the UDP PLPMTU I-D, but haven’t found time till now...

The question is what happens if, for a good or bad reason (e.g., an attack), a router that is a tunnel entry point, is already limited to this 576 or 1280 size on its outgoing link?
How will a client whose packets need to go through this tunnel behave after receiving PTB ICMP error messages with a suggested MTU lower than 576/1280?
The quick answer is: « a big mess », with either a DoS, or major performance issues, sometimes after a long freeze period (we measured up to 7 min).

Of course the detailed behaviour depends on the use of TCP vs. UDP, PMTUd vs. PLPMTU, IPv4 vs. IPv6, Ubuntu vs. W7.
We tried to explore all of this through an exploit. The two articles below exhibit an IPsec and IP-in-IP attack that relies on this principle, but the underlying problem
is of course independent of the tunnel nature.

- The initial work:
L. Jaqcuin, V. Roca, 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. http://hal.inria.fr/hal-01052994/en/ <http://hal.inria.fr/hal-01052994/en/>, (slides, PDF) <http://www.inrialpes.fr/planete/people/roca/doc/slides_globecom14_ptb_pts_attack_interactive_session.pdf>.

- An update with many additional configurations tested (you can look at these slides for a good introduction to the problem):
V. Roca, L. Jacquin, S. Fall, J-L. Roch, ``New Results for the PTB-PTS Attack on Tunnelling Gateways'', GreHack 2015, November 2015. https://hal.inria.fr/hal-01245629/en/ <https://hal.inria.fr/hal-01245629/en/>, (slides, PDF) <http://www.inrialpes.fr/planete/people/roca/doc/GreHack15_ptb_pts_attack_VR.pdf>.

- We tried to discuss it at IPSECME a few years ago but didn’t find any echo:
V. Roca, S. Fall, ``Too Big or Too Small? The PTB-PTS ICMP-based Attack against IPsec Gateways'', IETF IP Security Maintenance and Extensions (IPSECME) Working Group, work in progress, July 2015. 
https://datatracker.ietf.org/doc/draft-roca-ipsecme-ptb-pts-attack/ <https://datatracker.ietf.org/doc/draft-roca-ipsecme-ptb-pts-attack/>

If the group considers it’s a topic of interest, I can update the I-D (perhaps focussing more on the min guaranteed MTU and strange situations it can create than on
the attack itself) and discuss it during next IETF meeting.

Cheers,

  Vincent