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

[Mark ZZZ Smith <[e-mail]>]

Hi Fernando,


----- Original Message -----
> From: Fernando Gont <[e-mail]>
> To: Mark ZZZ Smith <[e-mail]>; Fernando Gont <[e-mail]>; Ole Troan <[e-mail]>
> Cc: Thomas Narten <[e-mail]>; C. M. Heard <[e-mail]>; Tim Chown <[e-mail]>; "[e-mail]" <[e-mail]>; Suresh Krishnan <[e-mail]>
> 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" 
>>  http://tools.ietf.org/html/draft-cheshire-tcp-over-udp-00
>> 
>>  "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.

Regards,
Mark.