Joe Touch writes: > First, I'm assuming we still want to support TCPINC via NAT traversal, > which excludes: > - TCP/IP SYN source IP (IP in that direction) > - TCP/IP SYN source port
You do assume that the server is never behind NAT. This is not true. It is actually very common to have servers also behind static NATs, i.e. mapping external address + port to some internal address + port in the DMZ. > All other fields except those that depend on these *can* be protected > (i.e., the only one that can't is the checksum). > > IP options MUST NOT be protected (even if they're IPv6 destination > options, they're not part of the TCP connection). Only the IP > pseudoheader should be protected, and only the portion that can't change > via a NAT (given NAT traversal). > > So, IMO, the fields we CAN protect are > IP SYN dest IP > TCP dest port So if we want to work through NATs I think we cannot protect the IP dest IP nor the TCP dest port. > TCP flags and pointers > TCP seq nos > TCP options ... > As a result, and because this WG is focused on a TCP solution, I'm in > favor of protecting ALL of these. If we try to get into the business of > deciding how to support middleboxes that play with these fields, then > we'll easily end up with TCP-in-TCP, at which point we ought to just use > BTNS IPsec and go home. So can you answer the questions I asked. For each service provided by each of the fields listed above, why it should be integrity protected, and what kind of attacks are possible if we do not protect it, and what should we do if we detect that someone has messed up with it. It does not really help saying I want to do everything. If you want to protect everything then you should really be just using IPsec... As we discussed in the meeting and on the mailing list protecting those fields will limit as when we try to go through certain kind of middleboxes, so if we protect everything, we will not work through certain middleboxes, which means tcpinc will be disabled quite often, which means we do not get the maximal protection against the pervasive monitoring. So the trade off is provide as wide protection against pervasive monitoring as possible, or provide protection against certain active attacks, while not protecting against pervasive monitoring that well. For almost every single field in the TCP header I think we can find some middlebox that will mess up with it, thus cause tcpinc to be disabled if we protect against it. Or even worse just cause connection to hang when the feature is first time used. I.e. if we decide to protect urgent field, and decide we drop the segment if someone messes up with the field, and if there is middlebox in the middle that will zero out the urgent field every single time, then first time we try to use urgent data, the connection will hang. The connection will not fall back to cleartext, and will not be disconnected. So protecting urgent field would most likely require us to use policy where we ignore the result of failures in the it, thus there is no point of protecting it... -- [email protected] _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
