Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility
RFC 5840
Yes
No Objection
Abstain
Note: This ballot was opened for revision 12 and is now closed.
Lars Eggert No Objection
(Pasi Eronen; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
(Alexey Melnikov; former steering group member) No Objection
4. IANA Considerations The USE_WESP_MODE notification number is assigned out of the "IKEv2 Notify Message Types - Status Types" registry's 16384- 40959 (Expert Review) range: TBD. I assume the Expert Reviewer Okeyed this registration already?
(Dan Romascanu; former steering group member) (was Discuss) No Objection
(Jari Arkko; former steering group member) (was Discuss) No Objection
By the way, I agree with Russ' Discuss.
(Lisa Dusseault; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
(Tim Polk; former steering group member) (was No Record, Discuss) No Objection
(1) The abstract states "there is no way to differentiate between encrypted and unencrypted payloads", but section 1.2 notes that this differentiation can be achieved using heuristics. This seems to be in conflict. (2) In section 1.2, the text preceding the list states "there are two ways ... to distinguish between encrypted and unencrypted ESP traffic". Something tells me there are other possibilities. (3) section 2, paragraph beginning "Padding Present (P), 1 bit". The following text is about the padding field rather than the flag. I think both are needed, and suggest moving the padding text to follow the discussion of the reserved bits. (4) a description of how the padding field will be used for extensibility, and any limitations on the use of that field, should be documented here. (5) Section 2, next to last paragraph: is it really optional to extend the standard ESP header by 8 octets for IPv6? (6) Security considerations, paragraph 1: s/should be used to in determining/should be used in determining/
(Magnus Westerlund; former steering group member) Abstain
I am entering an abstain position on this due to that it doesn't appear to be a well enough motivated usage of an protocol number. The protocol number space is quite limited and this is basically a duplication of the ESP one. Yes, it attempts to provide some additional functionality. Due to the expressed limited support and lack of implementation I would have no problem if this proposal skipped requesting an protocol ID of itself and instead always relied on the UDP encapsulation. That way it only consume one code point from a IPsec specific range, that also is almost not utilized at all today.