Re: [IPsec] Traffic visibility - consensus call

[Joy Latten <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf
> >Of Paul Koning
> >Sent: Wednesday, January 06, 2010 1:43 PM
> >To: Stephen Kent
> >Cc: [e-mail]
> >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
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/ipsec
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec