1. Ken Grewal Gabriel Montenegro Manav Bhatia
IPsec Wrapped ESP (WESP) for Traffic Visibility 75 IETF IPSECME WG 27-Jul-09
Ken Grewal
Gabriel Montenegro
Manav Bhatia

2. Current Status All tickets closed
WG Last Call issued on rev 5 from 4-18 July.
Tickets closed before May interim (and reviewed during the interim):
#85 Clarify the units for WESP header
Added length of fields in bits & units
#88 UDP Encapsulation diagram is wrong
#89 Version field in the flags
Set version to 0, added text to enforce checking
#91 Next Header should not be optional in ESP-NULL
27-Jul-09
75 IETF IPSECME WG

3. Closed after May interim (1/2)
#84 Scope of WESP
Leverage WESP ‘Next Header’ value to differentiate between ESP-NULL and encryption
If Zero, then encrypted data, else ESP-NULL
Note: Alternative was to add a bit in the flags
more on this later
#90 Shorter WESP negotiation
along the lines of the USE_TRANSPORT_MODE (tunnel mode) of rfc4306
Added text for WESP notification
27-Jul-09
75 IETF IPSECME WG

4. Closed after May interim (2/2)
#92 Specify clearly how to treat bits in flags
Added text including Integrity protection of WESP header
#93 Next header field to specify value of tunneled payload
Dan McDonald (during the interim) et al: just say “IP” as ESP does… No change to existing usage.
#104 Handling malformed fields in WESP header
Added integrity check over WESP header, which enforces recipient validation of fields
(no number) Revert WESP fields to original order:
- Flags as the last field
- Next Header as the first field
27-Jul-09
75 IETF IPSECME WG

5. WG LC issues (1)
HdrLen is an offset to the payload, but we don’t say where from
submitted by Yaron (thanks!), solution below ok by him
OLD:
HdrLen, 8 bits: Offset to the beginning of the Payload Data in octets.
NEW:
HdrLen, 8 bits: Offset from the beginning of the WESP header to the beginning of the Rest of Payload Data (i.e., past the IV, if present) within the encapsulated ESP header, in octets.
27-Jul-09
75 IETF IPSECME WG

6. WG LC issues (2)
Conflict between Next Header values due to overloading of this field (submitted by Qiu Ying, thanks!)
0 can mean both (“encryption being used”) as well as “IPv6 Hop-by-Hop option”
alternatives:
assign a protocol value to use as “encryption being used” in Next Header
Pros: simple change to the draft
Cons: field overloading, consumes another protocol number
use existing value for ESP when using encryption
Cons: field overloading, more overloading, can we guarantee this is not a valid usage?
Use 0xFF instead
Cons: field overloading, this field is reserved by IANA
bring back the “Encryption bit” in the flags
Pros: no overloading, clean
Cons: more delta in the draft (but we had this text before anyways), potential mismatch with usage of encryption vs ESP NULL
What to set the Next Header field to? 0? 0xFF?
If 0xFF, then why not alternative #3?
27-Jul-09
75 IETF IPSECME WG

7. Next Steps Issue revision per WG LC comments Advance to the IESG
27-Jul-09
75 IETF IPSECME WG