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

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

----- 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: Tuesday, 11 February 2014 6:26 AM
> Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers
> 
> On 02/07/2014 09:06 PM, Mark ZZZ Smith wrote:
>>> 
>>>  If, say, tomorrow you come up with this shiny cool new Dst 
>>>  Opt-based extension for clients, then, from starters, you would 
>>>  have to think of a back-up plan, because in more than 40% cases 
>>>  your packets would get dropped just because of that extension. -- 
>>>  that's where we are right now.
>>> 
>> 
>>  End-to-end crypto might the backup plan.
> 
> 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.


> 
> 
>>  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 there is a lot of effort involved, it would be wasted if that sort of event happened.

> 
> 
>>  I also think multipathing, to take advantage of smartphone/tablet's
>>  multi-homing to the network will also mean middle boxes become less
>>  effective/in-effective. IOS 7 is already using MPTCP for Siri for
>>  example+.
> 
> This is a comment from the URL you posted:
> 
>>  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."

;-)


> 
> Cheers,
> -- 
> Fernando Gont
> e-mail: [e-mail] || [e-mail]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>