netdev - Re: [PATCH net-next 0/8] tou: Transports over UDP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sat, 25 Jun 2016 09:22:51 -0700
From:	Tom Herbert <tom@...bertland.com>
To:	Rick Jones <rick.jones2@....com>
Cc:	Richard Weinberger <richard@....at>,
	David Miller <davem@...emloft.net>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Kernel Team <kernel-team@...com>
Subject: Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On Fri, Jun 24, 2016 at 5:01 PM, Rick Jones <rick.jones2@....com> wrote:
> On 06/24/2016 04:43 PM, Tom Herbert wrote:
>>
>> Here's Christoph's slides on TFO in the wild which presents a good
>> summary of the middlebox problem. There is one significant difference
>> in that ECN needs network support whereas TFO didn't. Given that
>> experience, I'm doubtful other new features at L4 could ever be
>> productively use (like EDO or maybe TCP-ENO).
>>
>> https://www.ietf.org/proceedings/94/slides/slides-94-tcpm-13.pdf
>
>
> Perhaps I am being overly optimistic, but my takeaway from those slides is
> Apple were able to come-up with ways to deal with the middleboxes and so
> could indeed productively use TCP FastOpen.
>
They do it by detecting that TFO packets are being dropped and so
fallback to not using TFO. Clients behind such a middlebox can't use
the feature.

> "Overall, very good success-rate"
> though tempered by
> "But... middleboxes were a big issue in some ISPs..."
>
> Though it doesn't get into how big (some connections, many, most, all?) and
> how many ISPs.
>
Note that this not just about TCP. TCP was never ordained to be the
one an only transport protocol on the Internet, in fact the intent of
the Internet architecture and a layered protocol stack was to
encourage innovation in protocol design not to ossify to just one in
perpetuity. SCTP for instance has some very interesting features like
sub streams to avoid HOL block, reliable messages model. But we can't
even consider the possibility of deploying it for our applications,
firewalls and NAT boxes will likely drop; not all major client OSes
(e.g. WIndows) even provide support for it.

ECN, TFO, and SCTP issues are just anecdotes of problems that have the
same root cause: middleboxes are invasive in transport protocols in
non-standard ways so that extending or changing transport protocols
difficult or infeasible to deploy. This is protocol ossification, and
IMO the solution is to eliminate middleboxes have visibility of L4.

Tom