Hi Jack, My suggestion in not just a semantic one. The protocol would be different because it would not wrap an existing, ESP-encapsulated packet. There would be no "additional attributes", no "next header" duplication, no processing overhead to check whether data is the same in two places, and none of the issues currently being discussed here, like the encrypted data bit.
It would be just like AH but NAT-friendly. It would be simple to implement and more clean architecturally. You could probably even cut-and-paste large portions of AH to make a draft too. I am somewhat sympathetic to your point about the implementation effort but hacks always _appear_ easier than doing it right (which is why they're done in the first place) and this seems alot like a hack. Heck, if implementation simplicity is a concern you could probably cut-and-paste large portions of your AH implementation to do this type of a protocol and in that sense it might actually even be easier than an ESP wrapper. Dan. On Wed, January 6, 2010 4:42 pm, Jack Kohn wrote: >>> 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 > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
