I think the protection against eavesdropping is key and is what we want to get deployed as much as possible. If the TCP header is protected and, thus, blocks what the middlebox is trying to do, then the middlebox vendors will be motivated to block the capability altogether. On the other hand, if only the payload is protected, the middlebox vendor has less reason to block it and might even have reason to encourage its use.
For cases where TCP headers need to be protected... IPsec is hard to deploy. Opportunistic IPsec might not be. John -----Original Message----- From: Tcpinc [mailto:[email protected]] On Behalf Of marcelo bagnulo braun Sent: Tuesday, July 29, 2014 3:17 AM To: Eggert, Lars Cc: [email protected] Subject: Re: [tcpinc] Protect or not the TCP header Agreed, and this is what we are trying to do in this thread. I dont think we are quite there yet though.. El 29/07/14 09:14, Eggert, Lars escribió: > On 2014-7-29, at 8:58, marcelo bagnulo braun <[email protected]> wrote: >> the charter reads: >> >> - must always provide integrity protection of the payload data (it is >> open for discussion for the WG if the TCP header should or should not >> be protected). >> >> So, I dont think we can clarify this, since it is up to the WG to figure it >> out. > So we do still need to figure it out :-) > > My personal take is that the main goal of tcpinc is to make the widespread > eavesdropping on plaintext connections harder. So focus the focus should be > on the payload, and interoperability should trump protection against other > attacks. > > I fully understand that there are different opinions on this, and they are > equally valid. But we need to figure out where the consensus of the WG on > this lies. > > Lars _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
