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

[Tero Kivinen <[e-mail]>]

Yaron Sheffer writes:
> I agree with you regarding some of the proposals that have been
> floating around re: exposing bits and pieces of encrypted data.

I am really concerned about some of those late proposals for WESP
extensions, and if someone would have mentioned any of those earlier
when we were discussing whether WESP should allow encrypted ESP also,
I would have been even more against allowing encrypted WESP. 

> I disagree though that WESP should not be used for encrypted data:
> 
> - It is simpler for implementations and architecturally cleaner for
>   WESP to support both flavors.

It does make more complexity for the middle boxes as they need to cope
with both encrypted WESP and ESP-NULL WESP, thus they still cannot use
just the WESP protocol number to indicate this packet is clear text.
Now they also need to check the bit in the header, and if we add more
extensions to WESP, they need to start doing even more processing etc,
and quite soon WESP is more complex than what AH is now.

> - WESP provides for (secure) extensibility, which unfortunately we
>   have not had with ESP. Indeed we should be wise about picking such
>   extensions.

ESP is extensible, but it just requires out of band communication to
negotiate those extensions. We currently already have ESP extesions
like extended sequence numbers (ESN), Explicit Congestion Notification
(ECN), Traffic Flow Confidentiality (TFC), and Combined mode
algorithms.

Those were added after initial ESP was created, and they are
negotiated using IKEv2 (or some other method).

ESP does not offer extensibility that can be done without out of band
communication, and as that out of band communication is normally
encrypted (inside IKEv2) that means middle boxes cannot process it.

I do not think WESP should be used as generic extensible ESP. That was
not what the ipsecme wg was chartered to do. We were chartered to do:

- 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.
-- 
[e-mail]