Hi Ken, No one responded to my suggestion so I'll suggest it again below.
On Wed, January 6, 2010 2:42 pm, Grewal, Ken wrote: [snip] > The bottom line is that in order for a network appliance (Trusted > Intermediary) to offer critical network services (IDS/IPS/DPI/Access > Control) in IPsec environments, it needs to know if a given IPsec packet > is encrypted or not in a deterministic manner and this is within scope. > WESP is offering this determination on a per packet basis. That is a clear definition of the problem: a TI must be able to determine whether a given IPsec packet is encrypted or not. [snip] > 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. The intermediate device knows this because it is under the same policy domain as the endpoints that have agreed to do WESP. If he's not in the same policy domain then he has no assurance that the endpoints will do WESP anyway. Maybe they'll do ESP and maybe even use the NULL cipher, so this box in the cloud is out-of-luck again and WESP doesn't help. Unless, of course, WESP is really a trojan horse to deprecate ESP and force everyone to use WESP always but you have said that's not the case. 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? regards, Dan. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
