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
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
