On 4/28/2016 2:10 AM, Mirja Kühlewind wrote: > Hi Joe, > > On 27.04.2016 19:50, Joe Touch wrote: >> Hi, all, >> >> TCPINC decided not to include any protection for the TCP header. >> >> TCP options are part of the TCP header. >> >> Sorry, but I have absolutely no idea why they would be asking now for a >> way to protect part of the TCP header when they've already so clearly >> decided otherwise. > > To my understanding the reason to not encrypt the header
Encrypt yes; include in the encryption pass, which would have protected it against modification, no. > was that some of the header information is need to pass middleboxes, > such as for sure the ports but also some of the flags and maybe even > the seq#. However, I think options or at least some of the options are > less critical. I guarantee someone will show us a middlebox that NEEDS to modify every option we currently have and every option we will ever create. However, regardless, the logic for the middlebox and the base TCP header are exactly the same. I prefer to protect both, but if you're not protecting the base it is nonsense to protect the options. > >> >> If you're not protecting things like IP addresses, ports, or - more to >> the point -the TCP header length field, I have no idea what it even >> means to claim you're protecting options. > > The main reason is to avoid (easy) leakage of privacy-sensitive > information that could be used to identify different connections or > different IP addresses that belong to the same host. All of that logic applies to the contents of the base TCP header as well. The only option that would really need to be protected by encryption this way would be a host-identity option - but that would need to be inherently protected anyway and would not need TCPINC to do that for it. > > Mirja > >> >> Joe >> >> On 4/26/2016 11:50 PM, Mirja Kühlewind wrote: >>> Hi all, >>> >>> 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? >>> >>> Mirja >>> _______________________________________________ >>> Tcpinc mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/tcpinc >> >> _______________________________________________ >> Tcpinc mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/tcpinc >> _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
