Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility
Note: This ballot was opened for revision 12 and is now closed.
(Pasi Eronen) Yes
(Jari Arkko) (was Discuss) No Objection
By the way, I agree with Russ' Discuss.
(Ralph Droms) No Objection
(Lisa Dusseault) No Objection
(Lars Eggert) No Objection
(Adrian Farrel) No Objection
(Russ Housley) (was Discuss) No Objection
Alexey Melnikov No Objection
Comment (2009-12-13 for -)
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?
(Tim Polk) (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/
(Dan Romascanu) (was Discuss) No Objection
(Robert Sparks) No Objection
Magnus Westerlund Abstain
Comment (2009-12-17 for -)
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.