On 11/20/2014 6:50 AM, Tero Kivinen wrote: > 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.
I realize that. It's a trade-off, and it prevents one box from spoofing a server to another - in this case, it prevents the host behind the NAT from spoofing as if it were the NAT itself. However, this might be something that can be relaxed, either per-connection or in general. >> 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. If you want to allow servers behind NATs, yes. But, IMO, that's a particular kind of identity attack that I don't think we necessarily need to support - or at least all the time. >> 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, TCP. Those bits and fields are there for a reason. If you aren't protecting them, you aren't protecting TCP and we'd all be better off using existing TLS in the conventional manner. > and what kind of attacks are possible if we do not protect it, and All the currently known ones and all the future ones we don't yet know about. Gaming what's protected and what isn't just opens TCP up to attacks. > what should we do if we detect that someone has messed up with it. Silently drop the packet, and perhaps log at most one such event per connection for use by other attack analysis. > 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... IPsec does not establish per-connection protection, as noted in RFC5925. IMO, a TCP-level solution ought to protect TCP. As you note, protections at other levels are already handled by other protocols. > 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, Yes. And they should. You can't differentiate between cooperative middleboxes and malicious ones merely by the fields they modify. > 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. "maximal" protection means minimal use. Protection, by its nature, means restricted use. Security means having to say NO. Joe _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
