David Mazieres <[email protected]>: > Bodo Moeller <[email protected]> writes: > > > 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. > > One big question is how middleboxes handle options in coalesced packets. > For example, if middleboxes tend to combine options (at least up to 40 > bytes), then this suggests one approach. If middleboxes discard all but > the first (or last) set of options, this suggests a different approach. > And do middleboxes just coalesce segments, or are there cases where TCP > resegmentation is used as an alternative to IP fragmentation? If anyone > on this list has any real data on deployed middleboxes (not just > speculation), it would make a useful contribution to the discussion. >
I found this paper (originally published at the Internet Measurement Conference 2011) very useful: http://nrg.cs.ucl.ac.uk/mjh/tmp/mboxes.pdf However, no amount of data gathering is a *full* substitute for some old-fashioned speculation here, because a middlebox that's misbehaving worse than previously expected could completely break the opportunistic-approach design we're aiming for. During the three-way handshake, you can't yet see whether the middlebox will tamper with TCP features only used later (and then the end-to-end effect of resegmentation and the like isn't deterministic in the first place). > Authenticating the TCP header from the payload opens a big can of worms. > In particular, we don't want to consume sequence numbers to authenticate > the acknowledgment number, especially in ACK-only packets. Otherwise to > stay TCP we'd have to acknowledge and/or retransmit ACK-only packets... True, but I don't agree that this opens a big can of worms. All that follows is that you can't authenticate empty segments. (All that *really* follows is that you can't authenticate *all* empty segments: you probably shouldn't authenticate an ACK-only packet acknowledging a packet that *would* have been an ACK-only packet if it wasn't for that authentication overhead ... but you can authenticate ACKs for packets carrying a non-empty actual payload. So authenticating ACK is nontrivial, but possible.) Note that this problem isn't specific to having TCP header information replicated in the encrypted payload. You have the exact same issue if you use the TCP data channel to carry authentication tags (e.g., draft-thomson-tcpinc-dtls-00). You don't have it if you put authentication tags in a TCP option instead, but of course that doesn't necessarily work in practice. Bodo
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
