Joy, Yes, your understanding is correct - WESP with the encryption flag allows intermediaries to determine if the payload is encrypted or NULL-encrypted and act accordingly.
Thanks, - Ken >-----Original Message----- >From: Joy Latten [mailto:lat...@austin.ibm.com] >Sent: Wednesday, January 06, 2010 4:16 PM >To: Grewal, Ken >Cc: ipsec@ietf.org >Subject: Re: [IPsec] Traffic visibility - consensus call > >On Wed, 2010-01-06 at 15:42 -0700, Grewal, Ken wrote: >> 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. >> >Ok. Thanks, for the clarity. I had read the latest draft and had been >following the thread but wasn't clear on the justification of needing >the encryption flag in WESP. > >So for my own understanding... the use of the "USE_WESP_MODE" for IKEv2 >as indicated in the draft guarantees that WESP-capable nodes only use >ESP for encryption and WESP for ESP-NULL. My thinking is, the SA created >will somehow indicate this "USE-WESP-MODE" and thus guarantee that the >packets on the SA enforce this policy, right? However, this is on the >end node, not the intermediate device. And it is the intermediate device >we want to give the guarantee to... especially in a mixed-environment... >And the WESP header, with an encryption flag indicating encrypted or >not, supplies this guarantee to the device. Am I understanding this >correctly or missing something or not even in the ballpark? > >If I have understood correctly, then in reference to Yaron's email, I >vote: > >>>- The current draft >>>(http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) >>>defines the ESP trailer's ICV calculation to include the WESP header. >>>This has been done to counter certain attacks, but it means that WESP >>>is no longer a simple wrapper around ESP - ESP itself is modified. Do >>>you support this design decision? > >No. Go back to WESP as a wrapper for ESP. > >>>- The current draft allows WESP to be applied to encrypted ESP flows, >>>in addition to the originally specified ESP-null. This was intended so >>>that encrypted flows can benefit from the future extensibility offered >>>by WESP. But arguably, it positions WESP as an alternative to ESP. Do >>>you support this design decision? > >Yes. > >regards, >Joy > > >> 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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
