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. 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... David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
