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: <1202f4bd-ef27-8143-8067-2bba56b7355c@stressinduktion.org>
Date:	Fri, 17 Jun 2016 01:15:41 +0200
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Tom Herbert <tom@...bertland.com>, davem@...emloft.net,
	netdev@...r.kernel.org
Cc:	kernel-team@...com
Subject: Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

On 16.06.2016 19:51, Tom Herbert wrote:
> Transports over UDP is intended to encapsulate TCP and other transport
> protocols directly and securely in UDP.
> 
> The goal of this work is twofold:
> 
> 1) Allow applications to run their own transport layer stack (i.e.from
>    userspace). This eliminates dependencies on the OS (e.g. solves a
>    major dependency issue for Facebook on clients).
> 
> 2) Make transport layer headers (all of L4) invisible to the network
>    so that they can't do intrusive actions at L4. This will be enforced
>    with DTLS in use.
> 
> Note that #1 is really about running a transport stack in userspace
> applications in clients, not necessarily servers. For servers we
> intend to modified the kernel stack in order to leverage existing
> implementation for building scalable serves (hence these patches).
> 
> This is described in more detail in the Internet Draft:
> https://tools.ietf.org/html/draft-herbert-transports-over-udp-00
> 
> In Part I we implement a straightforward encapsulation of TCP in GUE.
> The implements the basic mechanics of TOU encapsulation for TCP,
> however does not yet implement the IP addressing interactions so
> therefore so this is not robust to use in the presence of NAT.
> TOU is enabled per socket with a new socket option. This
> implementation includes GSO, GRO, and RCO support.
> 
> These patches also establish the baseline performance of TOU
> and isolate the performance cost of UDP encapsulation. Performance
> results are below.
> 
> Tested: Various cases of TOU with IPv4, IPv6 using TCP_STREAM and
> TCP_RR. Also, tested IPIP for comparing TOU encapsulation to IP
> tunneling.

Thinking about middleboxes again:

E.g. https://tools.ietf.org/html/rfc6347#section-4.2.3 states that DTLS
packets are not allowed to be fragmented. Because of this and
furthermore because of the impossibility of clamp-mss-to-pmtu to work
anymore, do you have any idea on how reliable this can work?

Or is your plan to use a smaller MSS on all paths by default?

Thanks,
Hannes