Subject: [tcpinc] TCPINC deployabilty

From: Jana Iyengar <[email-masked]>
Date: Wed, 25 Mar 2015 19:19:04 -0500

I think I'd want to support TCPCrypt, for the ecosystem point that Stephen
made earlier. That said, I am concerned about its deployability. Some
thoughts, FWIW.

Especially after the TCPM discussion on extending TCP options this week, it
seems to me that for any chance of successful deployment, Crypt ought to be
as divorced from the TCP header as possible, because of middlebox and, much
more importantly, GRO/GSO/TSO interactions. Given that now TCP headers are
not to be protected anyways, the MAC option could be included in the TCP
payload. You'd probably need some framing --- TLV will probably do --- to
make this work in the face of coalescing/fragmenting middleboxes. I think
you'll also need implicit byte sequence numbers instead of TCP sequence
numbers for the ASM-Encrypt counter.

There are two major deployability benefits for this: (i) middleboxes don't
have to understand/forward new TCP options outside of the SYN, and (ii)
most of the work can be done in userspace. (You would probably still need a
sockopt for initial signaling from TCP up to the Crypt shim in userspace
about success of negotiation.)

For negotiating use of Crypt (or TLS for that matter), there is an
additional option to using TCP SYN options -- you could leave it to the app
to negotiate its use. This could be implicitly negotiated by apps, or
explicitly and out-of-band. This allows for Crypt to get deployment without
*requiring* kernel changes and without dealing with middleboxes that don't
care for unknown options, and that's immensely useful.

- jana