Paul, <Firstly, Thanks for the blank slate to respond...way too many messages on this topic! :-)>
My 2 cents... Some people have jumped to conclusions that because we want to differentiate between encrypted and non-encrypted traffic by explicitly signaling in the packet, that WESP is now a replacement for ESP. THIS IS NOT THE CASE AND IT WAS NEVER THE INTENT! One item that may have led to this conclusion was the expanded ICV over WESP, but this was introduced as a mitigation for certain threats highlighted in the WG. Subsequent discussions have determined that it would be better to mitigate these treats in an alternative manner, so we can fall back to WESP being a wrapper for ESP, without the expanded ICV. Wrapped ESP provides a wrapper for ESP! The other item for discussion is whether WESP needs to explicitly differentiate between the payload being encrypted or NULL - I think this is a valid point to discuss. Numerous threads have talked about policy based deployments, mixed mode environments, migration paths, using/not using heuristics, etc... 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. I think we all agree that the traffic patterns will not fall into one single category (NULL OR Encrypted) within an Enterprise environment. i.e. There will be some traffic that is encrypted and some using NULL encryption. 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. Having the encrypted flag within WESP allows clear and explicit distinction that certain traffic is encrypted whereas other traffic is not. This preserves the network based services we rely on and also allows other access control policies to be enforced. E.g. I want to ensure that my finance data flowing in the network is encrypted and NOT using ESP-NULL. If I rely on ESP for encrypted data and it can still use NULL encryption, I cannot enforce such a policy from an access control tool. Bottom line is that having this 'encryption' flag in WESP provides the capability to deterministically provide and preserve critical network services in IPsec environments, as well as apply access control policies. Without it, we are back to half-baked solutions. As others have quoted the charter, here it is again... "A standards-track mechanism that allows an intermediary device, such as a firewall or intrusion detection system, to easily and reliably determine whether an ESP packet is encrypted with the NULL cipher; and if it is, determine the location of the actual payload data inside the packet." If we say that WESP is ONLY used to carry ESP-NULL (and ESP is used to carry encrypted traffic, but based on the ESP spec and legacy, it may also carry ESP-NULL), then we have not completed what we set out to do, as we have failed to *reliably* determine if the ESP traffic is encrypted or not! Again, WESP does not replace ESP. It offers what it set out to do - an easy and reliable way to tell if an IPsec packet has a NULL payload or if it is encrypted. Thanks, - Ken >-----Original Message----- >From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf >Of Paul Koning >Sent: Wednesday, January 06, 2010 1:43 PM >To: Stephen Kent >Cc: ipsec@ietf.org >Subject: Re: [IPsec] Traffic visibility - consensus call > >I've been watching a long stream of messages about WESP flying by and I >must admit to being rather confused. What follows is based on my best >understanding of what's going on, so please apply grains of salt as >needed. > >It's likely that I'm in the same corner as Tero. > >It sounds to me like WESP was chartered to do something very specific, >having to do with ESP-NULL and intermediate systems looking at traffic. >And now we have discussions about ESP-nonNULL with WESP, and maybe WESP >as an alternative to ESP, or a replacement to ESP. > >How is this possible? It's nice to talk about the benefits of greater >generality and all that, but it isn't proper to have a WG chartered to >do a narrow thing and then end up doing something much bigger. > >Why not? > >Answer: the purpose of a charter is (a) to tell the WG what it should be >doing, (b) to tell observers whether the work of the WG is something >they need to track -- or do NOT need to track. > >If a WG goes well outside its charter, that's not fair to those who >would have participated if the charter had said this, but ended up not >participating because the charter told them they did not need to. From >what I understand from Tero's comments, that situation applies to him, >and I think it applies to me as well. > >It may well be a good idea to expand or modify or generalize or replace >ESP, but if such a project is to be done, it should be done by a WG >chartered for that purpose, so that all interested parties are on notice >that this work is about to happen. > >Meanwhile, as to the consensus call: if this is out of charter as it >appears to be, then, independent of its technical merit, my vote is NO. > > paul koning >_______________________________________________ >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
