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

Current Status All tickets closed WG Last Call issued on rev 5 from 4-18 July. http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-05. 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

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

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

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

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

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