Skip to main content

Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility
RFC 5840

Revision differences

Document history

Date Rev. By Action
2015-10-14
12 (System) Notify list changed from ipsecme-chairs@ietf.org, draft-ietf-ipsecme-traffic-visibility@ietf.org to (None)
2012-08-22
12 (System) post-migration administrative database adjustment to the No Objection position for Jari Arkko
2012-08-22
12 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2012-08-22
12 (System) post-migration administrative database adjustment to the No Objection position for Dan Romascanu
2012-08-22
12 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2010-04-21
12 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2010-04-21
12 Amy Vezza [Note]: 'RFC 5840' added by Amy Vezza
2010-04-20
12 (System) RFC published
2010-02-01
12 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2010-01-28
12 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2010-01-28
12 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-01-27
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-01-27
12 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2010-01-26
12 (System) IANA Action state changed to In Progress
2010-01-26
12 Cindy Morgan IESG state changed to Approved-announcement sent
2010-01-26
12 Cindy Morgan IESG has approved the document
2010-01-26
12 Cindy Morgan Closed "Approve" ballot
2010-01-26
12 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk
2010-01-26
12 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk
2010-01-24
12 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2010-01-22
12 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko
2010-01-20
12 (System) New version available: draft-ietf-ipsecme-traffic-visibility-12.txt
2009-12-20
12 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu
2009-12-18
12 (System) Removed from agenda for telechat - 2009-12-17
2009-12-17
12 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2009-12-17
12 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel
2009-12-17
12 Magnus Westerlund
[Ballot comment]
I am entering an abstain position on this due to that it doesn't appear to be a well enough motivated usage of an …
[Ballot comment]
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.
2009-12-17
12 Magnus Westerlund [Ballot Position Update] New position, Abstain, has been recorded by Magnus Westerlund
2009-12-17
12 Jari Arkko [Ballot comment]
By the way, I agree with Russ' Discuss.
2009-12-17
12 Jari Arkko
[Ballot discuss]
I'm generally supportive of this type of an extension, but I had two
technical problems that I wanted to talk about before recommending …
[Ballot discuss]
I'm generally supportive of this type of an extension, but I had two
technical problems that I wanted to talk about before recommending the
approval of this specification.

The first issue is the design for extensibility. The design is
problematic, as acknowledged by the draft when it says that middleboxes
may have to drop traffic with unrecognized WESP version numbers or that
intermediate nodes dealing with unknown reserved bits are not necessarily
able to correctly parse packets. The design seems suspect, and I'd like
to understand why this design was chosen. Basic requirements for
extensibility in most protocols include the ability to add information
without endangering the ability of protocol participants to parse
existing information. I believe this could actually be achieved with
a different design. In one design you would simply have a flags byte
but no version number. The basic format would always have a pointer
to the offset where the cleartext packet begins, and this would never
be changed by extensions. New flags could define additional information
elsewhere in the packet (between the start of the WESP header and the
offset where the actual packet begins, for instance) and this wouldn't
affect intermediaries that have no need for the additional information.
Another design could use the same rules about the flags but add a version
number if truly incompatible changes have to be made. Then again, the
only truly incompatible change that I can think of is "there is no
cleartext packet", and IMHO, that's not a proper extension of WESP.

The second issue is that Section 2 claims that the WESP version numbers
should be negotiated over a control channel. However, Section 2.3 does
not negotiate WESP version numbers, only the use of WESP.
2009-12-17
12 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko
2009-12-16
12 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks
2009-12-16
12 Russ Housley
[Ballot discuss]
The primary motivation for this work is to allow a middlebox to peek
  into integrity protected (but not encrypted) IPsec packets. Some …
[Ballot discuss]
The primary motivation for this work is to allow a middlebox to peek
  into integrity protected (but not encrypted) IPsec packets. Some
  integrity-check algorithms use an IV, a middlebox cannot alway know
  where the payload starts.  Unlike the IPsec peer that negotiated the
  algorithm in the IKE exchange, the middlebox does not know which
  integrity-check algorithm is in use, and thus doe s not know if an IV
  is present or how long it might be.

  The document allows the encapsulation of encrypted IPsec traffic.
  Why?  I cannot see the justification for the use if WESP at all if
  the IPsec traffic is encrypted.

  The document says:
  >
  > ... by preserving the body of the existing ESP packet format, a
  > compliant implementation can simply add in the new header, without
  > needing to change the body of the packet.
  >
  The figures in Section 2.2.1 and 2.2.2 show otherwise.  The ESP ICV is
  replaced by a WESP ICV.  ESP processing is changed, and I cannot see
  the justification for it.  This is explained by:
  >
  > In the diagrams below, "WESP ICV" refers to the ICV computation as
  > modified by this specification. Namely, the ESP ICV computation is
  > augmented to include the four octets that constitute the WESP header.
  > Otherwise, the ICV computation is as specified by ESP [RFC4303].
  >
  So, in fact, WESP is not an optional encapsulation of ESP.  It is an
  alternative to ESP with some duplicated fields (such as Next Header)
  and pointers into the actual integrity-protected payload.

  When talking about IKEv2 negotiation, the document says:
  >
  > The notification, USE_WESP_MODE (value TBD) MAY be included in a
  > request message that also includes an SA payload requesting a
  > CHILD_SA using ESP.
  >
  USE_WESP_MODE MUST be included if one wants to use WESP, right?  The
  use of MAY here leads me to think that there are other ways to select
  the use of WESP in the IKEv2 exchange.
2009-12-16
12 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2009-12-16
12 Tim Polk
[Ballot comment]
(1) The abstract states "there is no way to differentiate between encrypted and unencrypted
payloads", but section 1.2 notes that this differentiation can …
[Ballot comment]
(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/
2009-12-16
12 Tim Polk
[Ballot discuss]
This is a discuss-discuss.

I was surprised to see that the IANA rules for the four reserved bits are "Specification Required".
Given the …
[Ballot discuss]
This is a discuss-discuss.

I was surprised to see that the IANA rules for the four reserved bits are "Specification Required".
Given the small number of bits and the unlimited imagination of the IPsec community, aren't
we in danger of using the bits up rather quickly?  I think that IETF consensus would be less
risky.
2009-12-16
12 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2009-12-16
12 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms
2009-12-16
12 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2009-12-15
12 Dan Romascanu
[Ballot discuss]
I plan to clear this DISCUSS after the IESG debates the question I am raising:

The approval write-up includes the following:

>  We …
[Ballot discuss]
I plan to clear this DISCUSS after the IESG debates the question I am raising:

The approval write-up includes the following:

>  We are not aware of any implementations. Neither do we know of any
  concrete vendor plans to implement this specification.

One ma wonder - whys is a document discussed and approved on standards track of there are no known implementations and no known plans for implementation
2009-12-15
12 Dan Romascanu [Ballot discuss]
I plan to clear this DISCUSS after the IESG debates the question I am raising:

The approval write-up includes the following:
2009-12-15
12 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu
2009-12-14
12 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2009-12-13
12 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov
2009-12-13
12 Alexey Melnikov
[Ballot comment]
4. IANA Considerations

  The USE_WESP_MODE notification number is assigned out of the
  "IKEv2 Notify Message Types - Status Types" registry's 16384- …
[Ballot comment]
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?
2009-12-09
12 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Sean Turner.
2009-12-01
12 Pasi Eronen State Changes to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup by Pasi Eronen
2009-12-01
12 Pasi Eronen Placed on agenda for telechat - 2009-12-17 by Pasi Eronen
2009-12-01
12 Pasi Eronen [Ballot Position Update] New position, Yes, has been recorded for Pasi Eronen
2009-12-01
12 Pasi Eronen Ballot has been issued by Pasi Eronen
2009-12-01
12 Pasi Eronen Created "Approve" ballot
2009-11-30
12 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-11-30
11 (System) New version available: draft-ietf-ipsecme-traffic-visibility-11.txt
2009-11-27
12 Pasi Eronen State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead::AD Followup by Pasi Eronen
2009-11-09
12 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-11-09
10 (System) New version available: draft-ietf-ipsecme-traffic-visibility-10.txt
2009-10-30
12 Pasi Eronen State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Pasi Eronen
2009-10-30
12 Pasi Eronen
Last Call Summary

According to my notes, the following comments were received:

- My remaining AD review comments:
http://www.ietf.org/mail-archive/web/ipsec/current/msg04921.html

- IANA's review (all OK):
https://datatracker.ietf.org/idtracker/draft-ietf-ipsecme-traffic-visibility/comment/103976/ …
Last Call Summary

According to my notes, the following comments were received:

- My remaining AD review comments:
http://www.ietf.org/mail-archive/web/ipsec/current/msg04921.html

- IANA's review (all OK):
https://datatracker.ietf.org/idtracker/draft-ietf-ipsecme-traffic-visibility/comment/103976/

- Pete McCann's Gen-ART review:
http://www.ietf.org/mail-archive/web/gen-art/current/msg04703.html

It looks like Pete's review needs at least a reply (and possibly some
changes), and my comments needs some small changes. Authors, can you
take a lead in replying to Pete, and proposing changes?

(And I've changed the state to "::Revised ID Needed")
2009-10-28
12 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2009-10-26
12 Amanda Baber
IANA comments:

Upon approval of this document, IANA will perform the following actions:

ACTION 1:

make the following assignments in the "Protocol Numbers" registry at …
IANA comments:

Upon approval of this document, IANA will perform the following actions:

ACTION 1:

make the following assignments in the "Protocol Numbers" registry at
http://iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

Decimal Keyword Protocol Reference
------- ------- -------- ---------
TBD WESP Wrapped Encapsulating Security Payload
[RFC-ipsecme-traffic-visibility-09]


ACTION 2:

make the following assignments in the "IKEv2 Notify Message Types -
Status Types" registry at
http://www.iana.org/assignments/ikev2-parameters

Value NOTIFY MESSAGES - STATUS TYPES Reference
----- -------------------------------- ---------
TBD USE_WESP_MODE [RFC-ipsecme-traffic-visibility-09]


ACTION 3:

make the following assignments in the
"Security Parameters Index (SPI) Parameters" registry located at
http://www.iana.org/assignments/spi-numbers

Number Description Reference
-------- --------------- ---------
2 WESP [RFC-ipsecme-traffic-visibility-09]


ACTION 4:

create the following registry and sub-registry at
http://www.iana.org/assignments/TBD

Registry Name: WESP Flags
Registration Procedures: Specification Required

Value range = 8bits

Bit Description Reference
----- ------------------- ---------
0-1 WESP Version [RFC-ipsecme-traffic-visibility-09]
2 Encrypted Payload [RFC-ipsecme-traffic-visibility-09]
3 Extended header [RFC-ipsecme-traffic-visibility-09]
4-7 Reserved [RFC-ipsecme-traffic-visibility-09]


Registry Name: Version Number
Registration Procedures: Standard Action

Value range = 2bits unsigned integer

Value Description Reference
----- ----------- ---------
0 [RFC-ipsecme-traffic-visibility-09]
1-3 Unassigned
2009-10-22
12 Samuel Weiler Request for Last Call review by SECDIR is assigned to Sean Turner
2009-10-22
12 Samuel Weiler Request for Last Call review by SECDIR is assigned to Sean Turner
2009-10-16
12 Samuel Weiler Assignment of request for Last Call review by SECDIR to Yaron Sheffer was rejected
2009-10-16
12 Samuel Weiler Request for Last Call review by SECDIR is assigned to Yaron Sheffer
2009-10-16
12 Samuel Weiler Request for Last Call review by SECDIR is assigned to Yaron Sheffer
2009-10-14
12 Amy Vezza Last call sent
2009-10-14
12 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2009-10-14
12 Pasi Eronen Last Call was requested by Pasi Eronen
2009-10-14
12 (System) Ballot writeup text was added
2009-10-14
12 (System) Last call text was added
2009-10-14
12 (System) Ballot approval text was added
2009-10-14
12 Pasi Eronen State Changes to Last Call Requested from AD Evaluation::AD Followup by Pasi Eronen
2009-10-07
12 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-10-07
09 (System) New version available: draft-ietf-ipsecme-traffic-visibility-09.txt
2009-09-17
12 Pasi Eronen State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Pasi Eronen
2009-09-15
12 Pasi Eronen State Changes to AD Evaluation from Publication Requested by Pasi Eronen
2009-09-15
12 Pasi Eronen [Note]: 'Yaron Sheffer (yaronf@checkpoint.com) is the document shepherd.' added by Pasi Eronen
2009-09-03
12 Amy Vezza
Document name: Wrapped ESP for Traffic Visibility,
draft-ietf-ipsecme-traffic-visibility-08.txt

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version …
Document name: Wrapped ESP for Traffic Visibility,
draft-ietf-ipsecme-traffic-visibility-08.txt

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

The document shepherd is Yaron Sheffer, co-chair of the ipsecme WG. I have
reviewed it and believe it is ready for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has had in-depth review within the ipsecme WG. I am not aware
of any non-WG reviews. I do not have any concerns about these reviews.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No concerns, the document lies fully within the ipsecme WG's area of
expertise.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

I have no such concerns. There have been no IPR disclosures.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is wide WG consensus.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No, there were no such conflicts.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes, I have personally verified that. No formal review criteria are
applicable.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

No issues identified.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The document defines a new IP Protocol Number. In addition, it defines a new
IKEv2 notification, and one new IANA registry. There are no issues with any
of them. I expect the Responsible AD to request the existing IKE/IPsec IANA
expert to extend his services to the current draft.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

There are no such sections.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

This document describes the Wrapped Encapsulating Security Payload (WESP)
protocol, which is based on the Encapsulating Security Payload (ESP)
protocol and is designed to allow intermediate devices to ascertain if ESP
with null encryption is being employed and if so, inspect the IPsec packets
for network monitoring and access control functions. The mechanism described
in this document can be used to easily disambiguate ESP-NULL from encrypted
ESP packets, without compromising on the security provided by ESP.

Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

Early on there was prolonged WG discussion about the relative merits of the
Wrapped ESP solution for identifying ESP-null traffic, compared to heuristic
methods for traffic inspection. Eventually the WG reached consensus on the
usefulness of having both solutions published, with the heuristics solution
targeted for the interim period until WESP is widely deployed. This
consensus is documented in both protocol documents.

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

We are not aware of any implementations. Neither do we know of any concrete
vendor plans to implement this specification.
2009-09-03
12 Amy Vezza Draft Added by Amy Vezza in state Publication Requested
2009-09-03
12 Amy Vezza [Note]: 'Yaron Sheffer (yaronf@checkpoint.com) is the document shepherd.' added by Amy Vezza
2009-09-01
08 (System) New version available: draft-ietf-ipsecme-traffic-visibility-08.txt
2009-08-10
07 (System) New version available: draft-ietf-ipsecme-traffic-visibility-07.txt
2009-08-06
06 (System) New version available: draft-ietf-ipsecme-traffic-visibility-06.txt
2009-06-24
05 (System) New version available: draft-ietf-ipsecme-traffic-visibility-05.txt
2009-06-05
04 (System) New version available: draft-ietf-ipsecme-traffic-visibility-04.txt
2009-06-01
03 (System) New version available: draft-ietf-ipsecme-traffic-visibility-03.txt
2009-04-30
02 (System) New version available: draft-ietf-ipsecme-traffic-visibility-02.txt
2009-03-09
01 (System) New version available: draft-ietf-ipsecme-traffic-visibility-01.txt
2008-10-27
00 (System) New version available: draft-ietf-ipsecme-traffic-visibility-00.txt