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

Mark ZZZ Smith <> Sun, 16 February 2014 19:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BC8641A0265 for <>; Sun, 16 Feb 2014 11:42:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.001
X-Spam-Level: *
X-Spam-Status: No, score=1.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eVVHUGJuhoc1 for <>; Sun, 16 Feb 2014 11:42:49 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9F21C1A022A for <>; Sun, 16 Feb 2014 11:42:48 -0800 (PST)
Received: from [] by with NNFMP; 16 Feb 2014 19:42:46 -0000
Received: from [] by with NNFMP; 16 Feb 2014 19:39:50 -0000
Received: from [] by with NNFMP; 16 Feb 2014 19:39:50 -0000
Received: from [] by with NNFMP; 16 Feb 2014 19:39:50 -0000
Received: from [] by with NNFMP; 16 Feb 2014 19:39:50 -0000
X-Yahoo-Newman-Property: ymail-4
Received: (qmail 94027 invoked by uid 60001); 16 Feb 2014 19:39:50 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1392579590; bh=EHIJziCxUdyXBPANlOOmDn4Krw8s9t4okw+Aeg18uj4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ne/vnlVQYoAsmNLSqoEqpLunKTB92vWORPQDeByfmUg7LSEfj2Nz3w/hE3FPo127DoCj6poNonqZplyG3pPhPONXYSqC+yMlbOiQ6vJYfvhGen+v1kR3hTXqw+tCCXtSGBxffvhEcpQf6pz1BvfwP9FYbkOzLnD8EbyW0AGcHaU=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xnI7FsRDurUKF5ji+bbiid+kK11MGBKwAy684Ziv/LgJkZIrfhkem78g6cGpc0Ry69yRTTq/3DG8z+/t+U9Xintc64UITVrS7WO2igars7ryAfMbFHa5OZQZkpkWJm9/gTvhsbdTo/lqG0ViG+WpqIi7JqpXTc4fUolcoNOYGoQ=;
X-YMail-OSG: m.VJmrsVM1lQgicSWItl0yRgc8zu9k4tkBZIkEuGzAlqTMW 1AmeYcVlhfBs3nySRy8d5nepYok8OQj2i1_4biaRSpFIjh50JUwiP4bnZLLk YdPE3CfuVsB1F25yLKmFjnwDsW2P7G3Xx3ZOGp4Sfrr2IDaIfY5cHtWeidHj 06_K.kmZD5R4jKShssU14BvZpA_W.B_WORdEWTeNjb04Wn84ihLH0W3FdV7A YuEvI4vI3pKgoEbYdXSoO2008dz0CCiW6hp943aSvo_jKSedJQ3qmXDmIpW7 pj9y5.dcoKzgA0ElZrKMzxkb6FCLeW1RtANIxHLaJ6mUumSpfRlhBRSBn9sI uax0QPIYgEBzZIT53o9sx4xMJGVhow7sRhU.HY63kIGnMkotAkhrXyZw8Aic W2BHI06hPWK2N8ExYGJuo3uW0Ft92D92cgjKTO4nisg2KDXXL_iv9o0Y.eAa HgWq805jtPTNPUj41Ju4dzyFB4tGOo3AorQ4M_.yhG6kZoJ6KItvMB3FVQcr _DG6MnB7PmZXAqoWM3MsEpkjNi.Sn4dHTICbTczT2AoVGcka4JD5vacm3aEm LsXDs9whQU76oxfEGMwtzOQCUXacduMn9oFYc
Received: from [] by via HTTP; Sun, 16 Feb 2014 11:39:50 PST
X-Rocket-MIMEInfo: 002.001, CkhpIEZlcm5hbmRvLAoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBGZXJuYW5kbyBHb250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20.Cj4gVG86IE1hcmsgWlpaIFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1PjsgRmVybmFuZG8gR29udCA8ZmVybmFuZG9AZ29udC5jb20uYXI.OyBPbGUgVHJvYW4gPG90cm9hbkBlbXBsb3llZXMub3JnPgo.IENjOiBUaG9tYXMgTmFydGVuIDxuYXJ0ZW5AdXMuaWJtLmNvbT47IEMuIE0uIEhlYXJkIDxoZWFyZEBwb2JveC5jb20.OyBUaW0gQ2gBMAEBAQE-
X-Mailer: YahooMailWebService/
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Message-ID: <>
Date: Sun, 16 Feb 2014 11:39:50 -0800
From: Mark ZZZ Smith <>
Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers
To: Fernando Gont <>, Fernando Gont <>, Ole Troan <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Thomas Narten <>, "C. M. Heard" <>, Tim Chown <>, "" <>, Suresh Krishnan <>
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Mark ZZZ Smith <>
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 16 Feb 2014 19:42:51 -0000

Hi Fernando,

----- Original Message -----
> From: Fernando Gont <>
> To: Mark ZZZ Smith <>; Fernando Gont <>; Ole Troan <>
> Cc: Thomas Narten <>; C. M. Heard <>; Tim Chown <>; "" <>; Suresh Krishnan <>
> Sent: Friday, 14 February 2014 7:55 PM
> Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers
> 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.  :-(

Given recent revelations, it is probably better to assume we already have been.

I think security is relative, not absolute. BTNS mode of IPsec protecting traffic would be much better than nothing protecting traffic. Even if you are MITM'd, at least the costs of uncovering the traffic go up, creating more of a disincentive to MITM unless they have to.

>>>>  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".

I think that as it is dropping unknown TCP options, rather than forwarding them, it indicates it is fundamentally intentional. A middle box "in the customers interests" would default to forwarding when it encounters unknown options, field values etc., allowing MPTCP to work.

In this specific case, it could be that as Siri uses 3G as a backup path for MPTCP for Wifi, Italy's 3G carriers might be blocking the MPTCP options to prevent Wifi offload via MPTCP, forcing customers to use and therefore pay for 3G bandwidth use even when they don't have to.

Customers certainly won't like that if they discover it, however the customers won't necessarily realise that it is the carrier that they're paying that is causing them to have a less reliable and more costly service. However, the people who provide Siri to those customers would be capable of finding out where the problem is, and may then develop and deploy work-arounds to the problem of TCP options being dropped. I don't know if you noticed, but the authors of that draft are from Apple, who have a very strong incentive for Siri to work well for their customers.

> 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-* :-)

I agree it will be an arms race, and I'm confident that the host/application people will eventually win. I think their fundamental desire is network transparency so that they can spend time and effort on better application features, rather than on work around methods to get the data they want between the application end-points. The harder the network makes it for the host/application developers to add new and useful features, the harder the host/application developers will push back, with obfuscation being their weapon.