Hi,
Thanks to the IESG feedback, we have had a long and enlightening discussion on
the list. But we have not reached consensus on either of the two questions. As
a result, Paul and I are proposing the following resolution, which appears to
be acceptable both to the draft's editors and to the IESG members. Unless there
are strong objections from multiple WG participants, we will ask the editors to
rev the draft in the next few days according to this proposal.
Motivation: retain deterministic traffic visibility for middleboxes with a
smooth migration path, while ensuring that WESP does not change ESP, and is not
(nor seen as) ESPv4.
- Return ICV to its former ESP-only definition.
- Maintain the Encrypted bit, as per the latest version of the draft.
- Make the padding field have the minimal possible length, possibly 0.
Eliminate the Padding Length field (the first octet). [Essentially roll back to
version -10].
- WESPv1 will not accept extensions. Any extensions will need a WESPv2,
including some integrity protection for the new data.
- Clarify the text about Version/HdrLen as proposed in the thread related to
Jari's discuss - so even if we add extensions later, and bump the version
number, HdrLen/TrailerLen will be in the same place, and middleboxes can still
find where the actual packet starts/ends
Thanks,
Yaron
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
