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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CALx6S37+o2=Lqzxu_U4QiSvqnq8CjEq5uSpbKVfFfo8r5qD+6g@mail.gmail.com>
Date:	Mon, 20 Jun 2016 08:13:48 -0700
From:	Tom Herbert <tom@...bertland.com>
To:	David Miller <davem@...emloft.net>
Cc:	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 Sun, Jun 19, 2016 at 8:07 PM, David Miller <davem@...emloft.net> wrote:
> From: Tom Herbert <tom@...bertland.com>
> Date: Fri, 17 Jun 2016 20:52:55 -0700
>
>> For instance, TFO was put in the Linux several years ago, but it
>> still hasn't been enabled in Android and only fairly recently
>> enabled in iOS.
>
> "Android decided to get locked into a really old kernel for 6+ years"
> is not really a good argument, sorry.
>
> We've already been hurt badly by the poor decisions the Android folks
> have made wrt. the handling of their kernel.
>
The problem is not just with Android. We are also very much dependent
on Windows, IOS, and whole bunch of network device vendors and network
operators to run applications over Internet. At least with Android we
have a path to get changes into the kernel pending the "next rebase".
Windows and IOS are black boxes, the only way we can get changes in is
to deal with their engineering directly (both have solid kernel
engineering, but they still set their own agendas). The situation is
worse with middleboxes. They all over the place on what they are doing
and many take a great deal of liberty with choosing which parts of the
standards to implement-- we have no way to directly influence them.

> Let's not make it worse by also making userland TCP stacks ubiquitous
> as a side effect.
>
> I've been assured several times that the Android situation will at
> the very least improve.
>
> And if it does improve and features do propagate more quickly, we'll
> have all of this risk and gambling unnecessarily.
>
> Let's not route around the Android problem, but rather get them to
> address it properly.

Routing around the problem is already being done. From
draft-tsvwg-quic-protocol-02:

"QUIC operates entirely in userspace, and is currently shipped to
users as a part of the Chromium browser, enabling rapid deployment and
experimentation.  As a userspace transport atop UDP, QUIC allows
innovations which have proven difficult to deploy with existing
protocols as they are hampered by legacy clients and middleboxes, or
by prolonged Operating System development and deployment cycles."

We can't ignore this. We can't just dismiss this as being a impending
failure because it conflicts with our idea of what the architecture of
the Internet should be. We would be remiss if we don't consider
solutions like QUIC or developing competitive alternatives like we're
doing in TOU.

Tom