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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
