David Mazieres <dm-list-tcpcr...@scs.stanford.edu>: > Bodo Moeller <bmoel...@acm.org> writes: >
> > Specifically, can we get some more clarity regarding the attack model -- > > what do you expect attackers to do, and what do you expect to achieve by > > your defenses? > > The attack is off-path RST injection: An attacker knows there is a TCP > connection between two IP addresses and also knows at least one of the > two port numbers. The attacker cannot drop packets between the two > hosts, but can inject packets with forged IP addresses. Hence, by > injecting RST segments, the attacker disrupts communication between the > two hosts. > The attacker would have to guess an acceptable sequence number too (if the recipient does SEQ validation as by RFC 793), but indeed the attack is easier than sending a bad ACK. Thanks. To seed the discussion, in addition to the RST and FIN bits, here are > some other things people might or might not care about: > > - Either protecting the urgent pointer and bit or specifying that > tcpinc is not compatible with urgent data (since socket APIs can be > coaxed into unexpected behavior by manipulating the urgent pointer). > I had mentioned urgent data -- I think it's sane to simply forbid the use of urgent data with TCPINC (unless it happens to be protected, in which case it will be useless as usual but at least not exploitable by attackers). - Protecting the sequence number. For example, the TCP-Minion group > is very keen on being able to decrypt and use TCP packets out of > order. Protecting the sequence number is one way for them to > achieve that goal. > Payload protection already implies that byte position in the plaintext octet stream will be protected, so protecting the TCP sequence number should not be necessary. However, allowing out-of-order processing is a reasonable (new) requirements. I think this is a new requirement in that it doesn't follow from the charter. (Regardless of whether we protect the sequence number as such, it would be easy to come up with a design that prevents out-of-order processing.) - Protecting the acknowledgment number (and SACK option). The ability > to inject false acknowledgments facilitates off-path DoS attacks, > though not quite as simple as RST injection. Separately, the > ability to forge acknowledgments allows an attacker to preserve the > lifetime of encryption keys in a host's memory. (Can be addressed > with higher-layer acks or heartbeats, too.) Hm, it would be nice to protect against these things, but I fear it may be impractical given that middleboxes may combine and split TCP packets and so one (so the authentication input used by the sender may not be available to the recipient) -- unless we use the less efficient approach that I mentioned in an earlier message, and always include an explicit copy of the authenticated header information in the plaintext that the sender encrypts, allowing the recipient to ignore middlebox-induced tampering. Bodo
_______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
