On 27 April 2016 at 16:50, Mirja Kühlewind <[email protected]> wrote: > I briefly brought this up in the last meeting and would like to start the > discussion on the mailing list now. The working group decided that tcpinc > will not encrypt the TCP header for good reasons. However, it would still be > possible to encrypt TCP options. This could help keeping confidentiality and > would avoid that a middle could alter information in a option or strip it. > Not sure if there is a case where some options should be encrypted and some > not but I guess that would be possible as well. Any thoughts?
Why not encrypt on an ad-hoc basis? You could have new options encrypted, and define encrypted variants of existing options. It's a little tricky to get this stuff right though. See for example https://tools.ietf.org/html/rfc6904 _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
