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

[Fernando Gont <[e-mail]>]

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?



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


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