Grewal, Ken writes: > The 'bait and switch' attack where a connection uses ESP-NULL and > then at a later stage uses ESP-Encrypted may also be possible > unintentionally. E.g. Connection to a server (cluster / farm) to > gain access to a 'normal' service uses ESP-NULL and then at a later > stage, where the previous connection was torn down and a new one > built, the connection is obtaining some sensitive data and is now > using ESP-Encrypted. On the outside, the connection attributes look > the same (same server IP, same client IP (but may be different > client due to NAT), same SPI - SPIs can be reused for new > connections to preserve fast lookups algorithms at recipients), but > underneath the connection is to access a different resource (may be > using a different port or service above the IP layer). If the > intermediate device has a cached rule (based on the previous > connection) indicating the traffic is clear, it will lead to falsely > inferring the contents of the payload and undesirable results.
This was covered in the draft section 7, where it said that if deep inspection engine suddenly starts getting lots of garbage then it should rerun the heuristics. > I agree with Yoav that this attack may also be possible > intentionally between two colluding parties, where the policy > indicates all traffic is ESP-NULL. It is much easier to use ESP-NULL wrapped TLS, or SSH in those cases. If both ends want to use encryption then the middle boxes cannot really prevent it very easily. If TLS and SSH and blocked then use IP(sec) over DNS, or IP(sec) over HTTP, and if even those fail then use IP(sec) over mail :-) -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
