Re: [IPsec] Traffic visibility - consensus call

[Min Huang <[e-mail]>]

YES  to both.

The WESP header provides a kind of rapid *deterministic* detection method
for ESP_NULL packet. The heuristics method is too complex and it calls for
more computing resource and computing time. I doubt the middle box whether
will support the heuristics method  for ESP_NULL detection. Although
including the WESP header into ESP ICV calculation seems modifying ESP, it
is necessary to check the WESP header integrity for counter certain attacks.
The explicit  WESP integrity calculation is OK for me, too. 

I support WESP for encrypted ESP flow.  WESP has the capacity to provide
more functions by future extensibility than just traffic visibility for
ESP_NULL. Nowadays ESP is used much more widely for encrypted flow than
ESP_NULL flow. It is meaningful for middle detection machines to have the
ability to detecting encrypted traffic.  And then WESP could provide this
kind of traffic visibility for both encrypted flow and unencrypted flow in
future.  

regards,
Min


-----Original Message-----
From: [e-mail] [mailto:[e-mail]
<javascript:main.compose('new', 't=[e-mail]')> ] On Behalf Of
Yaron Sheffer
Sent: Tuesday, January 05, 2010 6:27 AM
To: [e-mail]
Subject: [IPsec] Traffic visibility - consensus call

Hi,

We have had a few "discusses" during the IESG review of the WESP draft. To
help resolve them, we would like to reopen the following two questions to WG
discussion. Well reasoned answers are certainly appreciated. But plain "yes"
or "no" would also be useful in judging the group's consensus.

- The current draft
(http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11)
<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?

- 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?

Thanks,
     Yaron
_______________________________________________
IPsec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ipsec
<https://www.ietf.org/mailman/listinfo/ipsec>