>> Some argue that we should use WESP for NULL traffic, mandating ESP for >> encrypted traffic...AND ensure that ESP is NEVER used for NULL encryption >> within a given domain / environment. How does an intermediate device know >> that this policy is being enforced? What if ESP is still being used for >> ESP-NULL and encrypted traffic? If this is the case, we are back to where >> we were/are today - no way to tell if ESP payload is encrypted or not.
Thats the whole idea of using WESP with encryption. During the initial phase there will be less number of nodes supporting WESP, and the majority would be using ESP-NULL. However, as time passes, more and more nodes would move to WESP, because load balancers/firewalls/inspection devices will work properly only with WESP traffic. This would provide the end nodes with a motivation to upgrade to WESP. I dont think heuristics have a place here. Manav had sent an excellent detailed mail on the issues with heuristics and why its not as easy to implement as the authors and its proponents claim. Given that heuristics cannot be done, what alternative are we left with for middle boxes to deterministically differentiate between the two classes of traffic? The vision, and its not shared by everyone, is that after some time we will have lot of end nodes moving to WESP, as its only then that their packets can get prioritized, load balanced, etc. All other unrecognized traffic by the middle boxes will not follow the optimized path. > So now my suggestion again. If you're going to specify a new protocol > and require endpoints to implement it then why not just make a new > IPsec protocol that is a NAT-friendly way of doing per-packet integrity > protection? Don't try to "wrap" ESP packets. That way the middlebox knows > that when it sees this new protocol that it is not encrypted and when it > sees ESP it knows it is encrypted (it knows that ESP is not using NULL > encryption because policy has disallowed that). We could even think about > deprecating ESP-NULL in favor of this new protocol. This would be an > architecturally cleaner way of solving the problem you clearly described > above. IKE can negotiate the new protocol, in transport- or tunnel-mode, > negotiate an algorithm to use to provide integrity protection, and > establish an authenticated and shared key to use with the algorithm. So > what's the problem with this suggestion? How different is your new protocol from WESP? Would it work if we were to call this new protocol XXXX instead of WESP. The idea behind this design is that it requires only an incremental implementation effort as its only a wrapper over an existing widely deployed implementation. Once we do away with WESP inside ESP ICV computation its really just a wrapper over ESP. Jack _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
