Re: A problem with RFC 6465's Uniform Format for Extension Headers

Fernando Gont <> Fri, 14 February 2014 09:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 872061A0179 for <>; Fri, 14 Feb 2014 01:11:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QYg3enGwt-FB for <>; Fri, 14 Feb 2014 01:11:51 -0800 (PST)
Received: from ( [IPv6:2a00:d10:2000:e::3]) by (Postfix) with ESMTP id CB3191A00DC for <>; Fri, 14 Feb 2014 01:11:50 -0800 (PST)
Received: from [2001:5c0:1000:a::fab] by with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from <>) id 1WEEnL-0002Pu-CX; Fri, 14 Feb 2014 10:10:51 +0100
Message-ID: <>
Date: Fri, 14 Feb 2014 05:55:55 -0300
From: Fernando Gont <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Mark ZZZ Smith <>, Fernando Gont <>, Ole Troan <>
Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Thomas Narten <>, "C. M. Heard" <>, Tim Chown <>, "" <>, Suresh Krishnan <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Feb 2014 09:11:53 -0000

Hi, Mark,

On 02/12/2014 05:28 AM, Mark ZZZ Smith wrote:
>> Depends on what you mean by end-to-end crypto, and in what
>> context.
>> SSL/TLS for say, web servers and mailservers, fine.
>> IPsec for the general case...mmm.. unlikely.
>> Is there any plan for solving the authentication of nodes? Is
>> everyone expected to get/buy a certificate?
> Any or all of them. In the latter case, BTNS mode of IPsec (RFC5386)
> would probably be better than NSA can have everything(tm) IP because
> it shrinks their window to be a MITM.

Which my result in "placebo" security: you never know if you've been
MITM'ed.  :-(

>>> I think it might be worth remembering that as per the IETF88
>>> Plenary, end-to-end encryption is the general direction, and that
>>> middle boxes less effective/in-effective because of it. So
>>> putting a lot of time and effort into facilitating them might be
>>> wasted effort.
>> It's a 1-page to 5-page document (and that's including
>> bolierplates).
> I'm not saying to no do it, just that if e.g., somebody like Google,
> Apple or Microsoft roll out an update that enables crypto on a very
> popular service (similar to how within days, millions of iPhones and
> iPads used MPTCP for Siri), the traffic that these middleboxes are
> inspecting might "go dark" or become hidden "overnight".

If e.g. TLS is enabled, the TCP header information is still in the clear
(unless you're *tunneling* over TLS).

> If there is
> a lot of effort involved, it would be wasted if that sort of event
> happened.

This shouldn't be "a lot of effort".

>>> Yes, it works! Thanks Kristian. However here in Italy 3G carriers
>>> filter out TCP options.. so SIRI gives up and stops trying to use
>>> mptcp in the long run.
> "Encapsulation of TCP and other Transport Protocols over UDP" 
> "In fact, TCP options are expected to work more reliably with
> TCP-over-UDP, because middleboxes will be less able to easily
> interfere with such options, modifying them, stripping them, or
> dropping packets containing TCP options, as they often dotoday with
> native TCP                     packets.  In particular, Multipath
> TCP-over-UDP is expected to work more reliably than native Multipath
> TCP [RFC6824], because middleboxes that interfere with use of those
> TCP options will be less able to do that when the packets are
> encapsulated inside UDP."
> ;-)

Well, how good this is probably depends on whether one assumes the
aforementioned middle-box behavior is intentional or not. If it is, then
this is "middle-box unfriendly". If it's not, this is "middle-box
friendly". FWIW, one would expect this to be an arms race. If this is
*intended middle-box behavior", then you'd expect middle-boxes to become
smarter, and eventually we'll have TCP-over-UDP-over-* :-)

Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492