Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility

[Russ Housley <[e-mail]>]

Ken:

>[Ken] I think this is the whole point. All the work on ESP/IPsec 
>this far has been considering a two party interaction (outside the 
>multicast context!). Now there is a third party - the middle box, 
>which would like to gain some additional information in order to 
>provide valuable network services. The end boxes already know what 
>is being negotiated, so just making changes to IKE to add additional 
>capability is insufficient in certain scenarios (while perfectly 
>sufficient in others). We need to provide additional information in 
>the data path, hence the need for WESP.

I do not agree with your assessment of the situation.  I agree with 
Tero's thoughts.

The IPsecME charter includes this work item:

   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. The starting points for this work item are
   draft-grewal-ipsec-traffic-visibility and draft-hoffman-esp-null-protocol.

Nothing in this description prepared me for WESP processing of ESP 
packets with a non-NULL-cipher.  It suggests making it easy for the 
middlebox to gain access to data that is already plaintext.  It does 
not suggest making information available to the middlebox that was 
previously unavailable to it.

Further, based on the discussion that has happened since I posted my 
DISCUSS position, other IPsecME WG participants are uncomfortable 
with the direction that WESP has taken.  As the discussion 
progresses, if I can see that these people and myself are in the 
rough, then I will clear.  So far, that does not seem to be the case.

Russ