Subject: Re: [IPsec] Traffic visibility - proposed way forward

From: Yaron Sheffer <[email-masked]>
Date: Thu, 14 Jan 2010 10:39:54 +0200

Hi,

We posted the proposed resolution 2 days ago, and have heard no objections on the list. So I'd like to ask the editors of the Traffic Visibility draft to revise the draft in light of this resolution, and close all other issues that were raised by the IESG (there were quite a few: https://datatracker.ietf.org/idtracker/draft-ietf-ipsecme-traffic-visibility/). Given the number of changes, we will ensure that the WG has a chance to review the draft before it is returned to the IESG for consideration, and hopefully approval.

Thanks,
	Yaron

-----Original Message-----
From: Yaron Sheffer 
Sent: Tuesday, January 12, 2010 13:37
To: [email-masked]'
Subject: Traffic visibility - proposed way forward

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