Yaron,
I hate to admit it, but I lost track of the details of WESP as it
progressed through WG discussions and briefings at IETF meetings.
When I read the I-D in detail, I was very surprised to see that it
was no longer a neatly-layered wrapper, as originally proposed. The
fact that it now calls for the ESP ICV to be computed in a new
fashion means that it really is replacing ESP, when used to mark
ESP-NULL packets.
From a protocol design perspective, the current version makes no
sense to me. Why keep the ESP header when ESP processing is now
changed in a significant way. The WESP header cannot be processed
(completely) by itself, because of the dependence on the ESP ICV. So
it makes little or no sense to retain the ESP header in this context.
I see no strong backward compatibility motivation for this format,
given that ESP processing must change to accommodate WESP (as
defined).
The issue of using WESP for marking encrypted traffic is a separate
topic. I believe the rationale you cited was to enable WESP
extensions, but I may have missed other arguments put forth for this.
Since most of the WESP extension proposals discussed so far have
proven to be questionable, I am not enthusiastic about that
rationale. Others have noted that using WESP with encrypted traffic
is not consistent with the scope of the WG charter item that
authorized work on WESP. Unless Pasi approves a WESP extension WG
item as part of re-chartering, I think it is inappropriate to have a
flag to mark a WESP payload as encrypted.
Steve
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
