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

[Fernando Gont <[e-mail]>]

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

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492