path: root/doc/rfc/rfc5840.txt

Internet Engineering Task Force (IETF)                         K. Grewal
Request for Comments: 5840                             Intel Corporation
Category: Standards Track                                  G. Montenegro
ISSN: 2070-1721                                    Microsoft Corporation
                                                               M. Bhatia
                                                          Alcatel-Lucent
                                                              April 2010


  Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility

Abstract

   This document describes the Wrapped Encapsulating Security Payload
   (WESP) protocol, which builds on the Encapsulating Security Payload
   (ESP) RFC 4303 and is designed to allow intermediate devices to (1)
   ascertain if data confidentiality is being employed within ESP, and
   if not, (2) inspect the IPsec packets for network monitoring and
   access control functions.  Currently, in the IPsec ESP standard,
   there is no deterministic way to differentiate between encrypted and
   unencrypted payloads by simply examining a packet.  This poses
   certain challenges to the intermediate devices that need to deep
   inspect the packet before making a decision on what should be done
   with that packet (Inspect and/or Allow/Drop).  The mechanism
   described in this document can be used to easily disambiguate
   integrity-only ESP from ESP-encrypted packets, without compromising
   on the security provided by ESP.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc5840.










Grewal, et al.               Standards Track                    [Page 1]
^L
RFC 5840               WESP for Traffic Visibility            April 2010


Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1. Introduction ....................................................3
      1.1. Requirements Language ......................................4
      1.2. Applicability Statement ....................................4
   2. Wrapped ESP (WESP) Header Format ................................5
      2.1. UDP Encapsulation ..........................................8
      2.2. Transport and Tunnel Mode Considerations ...................9
           2.2.1. Transport Mode Processing ...........................9
           2.2.2. Tunnel Mode Processing .............................10
      2.3. IKE Considerations ........................................11
   3. Security Considerations ........................................12
   4. IANA Considerations ............................................13
   5. Acknowledgments ................................................13
   6. References .....................................................14
      6.1. Normative References ......................................14
      6.2. Informative References ....................................14







Grewal, et al.               Standards Track                    [Page 2]
^L
RFC 5840               WESP for Traffic Visibility            April 2010


1.  Introduction

   Use of ESP within IPsec [RFC4303] specifies how ESP packet
   encapsulation is performed.  It also specifies that ESP can provide
   data confidentiality and data integrity services.  Data integrity
   without data confidentiality ("integrity-only ESP") is possible via
   the ESP-NULL encryption algorithm [RFC2410] or via combined-mode
   algorithms such as AES-GMAC [RFC4543].  The exact encapsulation and
   algorithms employed are negotiated out of band using, for example,
   Internet Key Exchange Protocol version 2 (IKEv2) [RFC4306] and based
   on policy.

   Enterprise environments typically employ numerous security policies
   (and tools for enforcing them), as related to access control, content
   screening, firewalls, network monitoring functions, deep packet
   inspection, Intrusion Detection and Prevention Systems (IDS and IPS),
   scanning and detection of viruses and worms, etc.  In order to
   enforce these policies, network tools and intermediate devices
   require visibility into packets, ranging from simple packet header
   inspection to deeper payload examination.  Network security protocols
   that encrypt the data in transit prevent these network tools from
   performing the aforementioned functions.

   When employing IPsec within an enterprise environment, it is
   desirable to employ ESP instead of Authentication Header (AH)
   [RFC4302], as AH does not work in NAT environments.  Furthermore, in
   order to preserve the above network monitoring functions, it is
   desirable to use integrity-only ESP.  In a mixed-mode environment,
   some packets containing sensitive data employ a given encryption
   cipher suite, while other packets employ integrity-only ESP.  For an
   intermediate device to unambiguously distinguish which packets are
   using integrity-only ESP requires knowledge of all the policies being
   employed for each protected session.  This is clearly not practical.
   Heuristics-based methods can be employed to parse the packets, but
   these can be very expensive, requiring numerous rules based on each
   different protocol and payload.  Even then, the parsing may not be
   robust in cases where fields within a given encrypted packet happen
   to resemble the fields for a given protocol or heuristic rule.  In
   cases where the packets may be encrypted, it is also wasteful to
   check against heuristics-based rules, when a simple exception policy
   (e.g., allow, drop, or redirect) can be employed to handle the
   encrypted packets.  Because of the non-deterministic nature of
   heuristics-based rules for disambiguating between encrypted and non-
   encrypted data, an alternative method for enabling intermediate
   devices to function in encrypted data environments needs to be
   defined.  Additionally, there are many types and classes of network
   devices employed within a given network and a deterministic approach
   provides a simple solution for all of them.  Enterprise environments



Grewal, et al.               Standards Track                    [Page 3]
^L
RFC 5840               WESP for Traffic Visibility            April 2010


   typically use both stateful and stateless packet inspection
   mechanisms.  The previous considerations weigh particularly heavy on
   stateless mechanisms such as router Access Control Lists (ACLs) and
   NetFlow exporters.  Nevertheless, a deterministic approach provides a
   simple solution for the myriad types of devices employed within a
   network, regardless of their stateful or stateless nature.

   This document defines a mechanism to provide additional information
   in relevant IPsec packets so intermediate devices can efficiently
   differentiate between encrypted and integrity-only packets.
   Additionally, and in the interest of consistency, this extended
   format can also be used to carry encrypted packets without loss in
   disambiguation.

   This document is consistent with the operation of ESP in NAT
   environments [RFC3947].

   The design principles for this protocol are the following:

   o  Allow easy identification and parsing of integrity-only IPsec
      traffic

   o  Leverage the existing hardware IPsec parsing engines as much as
      possible to minimize additional hardware design costs

   o  Minimize the packet overhead in the common case

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

1.2.  Applicability Statement

   The document is applicable only to the wrapped ESP header defined
   below, and does not describe any changes to either ESP [RFC4303] or
   the IP Authentication Header (AH) [RFC4302].

   There are two well-accepted ways to enable intermediate security
   devices to distinguish between encrypted and unencrypted ESP traffic:

   - The heuristics approach [Heuristics] has the intermediate node
     inspect the unchanged ESP traffic, to determine with extremely high
     probability whether or not the traffic stream is encrypted.






Grewal, et al.               Standards Track                    [Page 4]
^L
RFC 5840               WESP for Traffic Visibility            April 2010


   - The Wrapped ESP (WESP) approach, described in this document, in
     contrast, requires the ESP endpoints to be modified to support the
     new protocol.  WESP allows the intermediate node to distinguish
     encrypted and unencrypted traffic deterministically, using a
     simpler implementation for the intermediate node.

   Both approaches are being documented simultaneously by the IP
   Security Maintenance and Extensions (IPsecME) Working Group, with
   WESP (this document) as a Standards Track RFC while the heuristics
   approach is expected to be published as an Informational RFC.  While
   endpoints are being modified to adopt WESP, we expect both approaches
   to coexist for years because the heuristic approach is needed to
   inspect traffic where at least one of the endpoints has not been
   modified.  In other words, intermediate nodes are expected to support
   both approaches in order to achieve good security and performance
   during the transition period.

2.  Wrapped ESP (WESP) Header Format

   Wrapped ESP (WESP) encapsulation uses protocol number 141.
   Accordingly, the (outer) protocol header (IPv4, IPv6, or Extension)
   that immediately precedes the WESP header SHALL contain the value
   (141) in its Protocol (IPv4) or Next Header (IPv6, Extension) field.
   WESP provides additional attributes in each packet to assist in
   differentiating between encrypted and non-encrypted data, and to aid
   in parsing of the packet.  WESP follows RFC 4303 for all IPv6 and
   IPv4 considerations (e.g., alignment considerations).

   This extension essentially acts as a wrapper to the existing ESP
   protocol and provides an additional 4 octets at the front of the
   existing ESP packet for IPv4.  For IPv6, additional padding may be
   required and this is described below.

   The packet format may be depicted as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Wrapped ESP Header                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Existing ESP Encapsulation               |
      ~                                                               ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 1: WESP Packet Format





Grewal, et al.               Standards Track                    [Page 5]
^L
RFC 5840               WESP for Traffic Visibility            April 2010


   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 value of the new protocol used to
   identify this new header is 141.  Further details are shown below:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Next Header  |   HdrLen      |  TrailerLen   |     Flags     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Padding (optional)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Existing ESP Encapsulation               |
      ~                                                               ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 2: Detailed WESP Packet Format

   Where:

   Next Header, 8 bits: This field MUST be the same as the Next Header
   field in the ESP trailer when using ESP in the Integrity-only mode.
   When using ESP with encryption, the "Next Header" field looses this
   name and semantics and becomes an empty field that MUST be
   initialized to all zeros.  The receiver MUST do some sanity checks
   before the WESP packet is accepted.  The receiver MUST ensure that
   the Next Header field in the WESP header and the Next Header field in
   the ESP trailer match when using ESP in the Integrity-only mode.  The
   packet MUST be dropped if the two do not match.  Similarly, the
   receiver MUST ensure that the Next Header field in the WESP header is
   an empty field initialized to zero if using WESP with encryption.
   The WESP flags dictate if the packet is encrypted.

   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
   and any other WESP options defined in the future) within the
   encapsulated ESP header, in octets.  HdrLen MUST be set to zero when
   using ESP with encryption.  When using integrity-only ESP, the
   following HdrLen values are invalid: any value less than 12; any
   value that is not a multiple of 4; any value that is not a multiple
   of 8 when using IPv6.  The receiver MUST ensure that this field
   matches with the header offset computed from using the negotiated
   Security Association (SA) and MUST drop the packet in case it does
   not match.






Grewal, et al.               Standards Track                    [Page 6]
^L
RFC 5840               WESP for Traffic Visibility            April 2010


   TrailerLen, 8 bits: TrailerLen contains the size of the Integrity
   Check Value (ICV) being used by the negotiated algorithms within the
   IPsec SA, in octets.  TrailerLen MUST be set to zero when using ESP
   with encryption.  The receiver MUST only accept the packet if this
   field matches with the value computed from using the negotiated SA.
   This ensures that sender is not deliberately setting this value to
   obfuscate a part of the payload from examination by a trusted
   intermediary device.

   Flags, 8 bits: The bits are defined most-significant-bit (MSB) first,
   so bit 0 is the most significant bit of the flags octet.

       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |V V|E|P| Rsvd  |
      +-+-+-+-+-+-+-+-+

      Figure 3: Flags Format

   Version (V), 2 bits: MUST be sent as 0 and checked by the receiver.
   If the version is different than an expected version number (e.g.,
   negotiated via the control channel), then the packet MUST be dropped
   by the receiver.  Future modifications to the WESP header require a
   new version number.  In particular, the version of WESP defined in
   this document does not allow for any extensions.  However, old
   implementations will still be able to find the encapsulated cleartext
   packet using the HdrLen field from the WESP header, when the 'E' bit
   is not set.  Intermediate nodes dealing with unknown versions are not
   necessarily able to parse the packet correctly.  Intermediate
   treatment of such packets is policy dependent (e.g., it may dictate
   dropping such packets).

   Encrypted Payload (E), 1 bit: Setting the Encrypted Payload bit to 1
   indicates that the WESP (and therefore ESP) payload is protected with
   encryption.  If this bit is set to 0, then the payload is using
   integrity-only ESP.  Setting or clearing this bit also impacts the
   value in the WESP Next Header field, as described above.  The
   recipient MUST ensure consistency of this flag with the negotiated
   policy and MUST drop the incoming packet otherwise.

   Padding header (P), 1 bit: If set (value 1), the 4-octet padding is
   present.  If not set (value 0), the 4-octet padding is absent.  This
   padding MUST be used with IPv6 in order to preserve IPv6 8-octet
   alignment.  If WESP is being used with UDP encapsulation (see Section
   2.1 below) and IPv6, the Protocol Identifier (0x00000002) occupies 4
   octets so the IPv6 padding is not needed, as the header is already on
   an 8-octet boundary.  This padding MUST NOT be used with IPv4, as it
   is not needed to guarantee 4-octet IPv4 alignment.



Grewal, et al.               Standards Track                    [Page 7]
^L
RFC 5840               WESP for Traffic Visibility            April 2010


   Rsvd, 4 bits: Reserved for future use.  The reserved bits MUST be
   sent as 0, and ignored by the receiver.  Future documents defining
   any of these bits MUST NOT affect the distinction between encrypted
   and unencrypted packets or the semantics of HdrLen.  In other words,
   even if new bits are defined, old implementations will be able to
   find the encapsulated packet correctly.  Intermediate nodes dealing
   with unknown reserved bits are not necessarily able to parse the
   packet correctly.  Intermediate treatment of such packets is policy
   dependent (e.g., it may dictate dropping such packets).

   Future versions of this protocol may change the version number and/or
   the reserved bits sent, possibly by negotiating them over the control
   channel.

   As can be seen, the WESP format extends the standard ESP header by
   the first 4 octets for IPv4 and optionally (see above) by 8 octets
   for IPv6.

2.1.  UDP Encapsulation

   This section describes a mechanism for running the new packet format
   over the existing UDP encapsulation of ESP as defined in RFC 3948.
   This allows leveraging the existing IKE negotiation of the UDP port
   for Network Address Translation Traversal (NAT-T) discovery and usage
   [RFC3947] [RFC4306], as well as preserving the existing UDP ports for
   ESP (port 4500).  With UDP encapsulation, the packet format can be
   depicted as follows.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Src Port (4500)        | Dest Port (4500)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Length            |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Protocol Identifier (value = 0x00000002)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Next Header  |   HdrLen      |  TrailerLen   |    Flags      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Existing ESP Encapsulation               |
      ~                                                               ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 4: UDP-Encapsulated WESP Header






Grewal, et al.               Standards Track                    [Page 8]
^L
RFC 5840               WESP for Traffic Visibility            April 2010


   Where:

   Source/Destination port (4500) and checksum: describes the UDP
   encapsulation header, per RFC 3948.

   Protocol Identifier: new field to demultiplex between UDP
   encapsulation of IKE, UDP encapsulation of ESP per RFC 3948, and the
   UDP encapsulation in this specification.

   According to RFC 3948, Section 2.2, a 4-octet value of zero (0)
   immediately following the UDP header indicates a Non-ESP marker,
   which can be used to assume that the data following that value is an
   IKE packet.  Similarly, a value greater then 255 indicates that the
   packet is an ESP packet and the 4-octet value can be treated as the
   ESP Security Parameter Index (SPI).  However, RFC 4303, Section 2.1
   indicates that the values 1-255 are reserved and cannot be used as
   the SPI.  We leverage that knowledge and use one of these reserved
   values to indicate that the UDP encapsulated ESP header contains this
   new packet format for ESP encapsulation.

   The remaining fields in the packet have the same meaning as per
   Section 2 above.

2.2.  Transport and Tunnel Mode Considerations

   This extension is equally applicable to transport and tunnel mode
   where the ESP Next Header field is used to differentiate between
   these modes, as per the existing IPsec specifications.

2.2.1.  Transport Mode Processing

   In transport mode, ESP is inserted after the IP header and before a
   next layer protocol, e.g., TCP, UDP, ICMP, etc.  The following
   diagrams illustrate how WESP is applied to the ESP transport mode for
   a typical packet, on a "before and after" basis.
















Grewal, et al.               Standards Track                    [Page 9]
^L
RFC 5840               WESP for Traffic Visibility            April 2010


      BEFORE APPLYING WESP -IPv4
            -------------------------------------------------
            |orig IP hdr  | ESP |     |      |   ESP   | ESP|
            |(any options)| Hdr | TCP | Data | Trailer | ICV|
            -------------------------------------------------
                                |<---- encryption ---->|
                          |<------- integrity -------->|


      AFTER APPLYING WESP - IPv4
            --------------------------------------------------------
            |orig IP hdr  | WESP | ESP |     |      |   ESP   | ESP|
            |(any options)| Hdr  | Hdr | TCP | Data | Trailer | ICV|
            --------------------------------------------------------
                                       |<---- encryption ---->|
                                 |<------- integrity -------->|


      BEFORE APPLYING WESP - IPv6
          --------------------------------------------------------------
          | orig |hop-by-hop,dest*,|   |dest|   |    | ESP   | ESP|
          |IP hdr|routing,fragment |ESP|opt*|TCP|Data|Trailer| ICV|
          --------------------------------------------------------------
                                       |<---- encryption --->|
                                   |<----- integrity ------->|


      AFTER APPLYING WESP - IPv6
          --------------------------------------------------------------
          | orig |hop-by-hop,dest*,|    |   |dest|   |    | ESP   | ESP|
          |IP hdr|routing,fragment |WESP|ESP|opt*|TCP|Data|Trailer| ICV|
          --------------------------------------------------------------
                                            |<---- encryption --->|
                                        |<----- integrity ------->|

          * = if present, could be before WESP, after ESP, or both

    All other considerations are as per RFC 4303.

2.2.2.  Tunnel Mode Processing

   In tunnel mode, ESP is inserted after the new IP header and before
   the original IP header, as per RFC 4303.  The following diagram
   illustrates how WESP is applied to the ESP tunnel mode for a typical
   packet, on a "before-and-after" basis.






Grewal, et al.               Standards Track                   [Page 10]
^L
RFC 5840               WESP for Traffic Visibility            April 2010


      BEFORE APPLYING WESP - IPv4
          ---------------------------------------------------------
          |new IP hdr*  |   | orig IP hdr*  |   |    | ESP   | ESP|
          |(any options)|ESP| (any options) |TCP|Data|Trailer| ICV|
          ---------------------------------------------------------
                            |<--------- encryption --------->|
                        |<----------- integrity ------------>|


      AFTER APPLYING WESP - IPv4
          --------------------------------------------------------------
          |new IP hdr*  |    |   | orig IP hdr*  |   |    | ESP   | ESP|
          |(any options)|WESP|ESP| (any options) |TCP|Data|Trailer| ICV|
          --------------------------------------------------------------
                                 |<--------- encryption --------->|
                             |<----------- integrity ------------>|


      BEFORE APPLYING WESP - IPv6
      -----------------------------------------------------------------
      |new IP|new ext |   |orig IP|orig ext|   |    | ESP   | ESP|
      | hdr* | hdrs*  |ESP|  hdr* | hdrs * |TCP|Data|Trailer| ICV|
      -----------------------------------------------------------------
                          |<--------- encryption ---------->|
                      |<------------- integrity ----------->|

      AFTER APPLYING WESP - IPv6
      -----------------------------------------------------------------
      |new IP|new ext |    |   |orig IP|orig ext|   |    | ESP   | ESP|
      | hdr* | hdrs*  |WESP|ESP|  hdr* | hdrs * |TCP|Data|Trailer| ICV|
      -----------------------------------------------------------------
                               |<--------- encryption ---------->|
                           |<------------- integrity ----------->|

          * = if present, construction of outer IP hdr/extensions and
              modification of inner IP hdr/extensions is discussed in
              the Security Architecture document.

   All other considerations are as per RFC 4303.

2.3.  IKE Considerations

   This document assumes that WESP negotiation is performed using IKEv2.
   In order to negotiate the new format of ESP encapsulation via IKEv2
   [RFC4306], both parties need to agree to use the new packet format.
   This can be achieved using a notification method similar to
   USE_TRANSPORT_MODE, defined in RFC 4306.




Grewal, et al.               Standards Track                   [Page 11]
^L
RFC 5840               WESP for Traffic Visibility            April 2010


   The notification, USE_WESP_MODE (value 16415) MUST be included in a
   request message that also includes an SA payload requesting a
   CHILD_SA using ESP.  It signals that the sender supports the WESP
   version defined in the current document and requests that the
   CHILD_SA use WESP mode rather than ESP for the SA created.  If the
   request is accepted, the response MUST also include a notification of
   type USE_WESP_MODE.  If the responder declines the request, the
   CHILD_SA will be established using ESP, as per RFC 4303.  If this is
   unacceptable to the initiator, the initiator MUST delete the SA.

   Note: Except when using this option to negotiate WESP mode, all
   CHILD_SAs will use standard ESP.

   Negotiation of WESP in this manner preserves all other negotiation
   parameters, including NAT-T [RFC3948].  NAT-T is wholly compatible
   with this wrapped format and can be used as-is, without any
   modifications, in environments where NAT is present and needs to be
   taken into account.

   WESP version negotiation is not introduced as part of this
   specification.  If the WESP version is updated in a future
   specification, then that document MUST specify how the WESP version
   is negotiated.

3.  Security Considerations

   As this document augments the existing ESP encapsulation format, UDP
   encapsulation definitions specified in RFC 3948 and IKE negotiation
   of the new encapsulation, the security observations made in those
   documents also apply here.  In addition, as this document allows
   intermediate device visibility into IPsec ESP encapsulated frames for
   the purposes of network monitoring functions, care should be taken
   not to send sensitive data over connections using definitions from
   this document, based on network domain/administrative policy.  A
   strong key agreement protocol, such as IKEv2, together with a strong
   policy engine should be used in determining appropriate security
   policy for the given traffic streams and data over which it is being
   employed.

   ESP is end-to-end and it will be impossible for the intermediate
   devices to verify that all the fields in the WESP header are correct.
   It is thus possible to modify the WESP header so that the packet
   sneaks past a firewall if the fields in the WESP header are set to
   something that the firewall will allow.  The endpoint thus must
   verify the sanity of the WESP header before accepting the packet.  In
   an extreme case, someone colluding with the attacker, could change





Grewal, et al.               Standards Track                   [Page 12]
^L
RFC 5840               WESP for Traffic Visibility            April 2010


   the WESP fields back to the original values so that the attack goes
   unnoticed.  However, this is not a new problem and it already exists
   IPsec.

4.  IANA Considerations

   The WESP protocol number assigned by IANA out of the IP Protocol
   Number space is 141.

   The USE_WESP_MODE notification number assigned out of the "IKEv2
   Notify Message Types - Status Types" registry's 16384-40959 (Expert
   Review) range is 16415.

   The SPI value of 2 has been assigned by IANA out of the reserved SPI
   range from the SPI values registry to indicate use of the WESP
   protocol within a UDP-encapsulated, NAT-T environment.

   IANA has created a new registry for "WESP Flags" to be managed as
   follows:

   The first 2 bits are the WESP Version Number.  The value 0 is
   assigned to the version defined in this specification.  Further
   assignments of the WESP Version Number are to be managed via the IANA
   Policy of "Standards Action" [RFC5226].  For WESP version numbers,
   the unassigned values are 1, 2, and 3.  The Encrypted Payload bit is
   used to indicate if the payload is encrypted or using integrity-only
   ESP.  The Padding Present bit is used to signal the presence of
   padding.  The remaining 4 bits of the WESP Flags are undefined and
   future assignment is to be managed via the IANA Policy of "IETF
   Review" [RFC5226].

5.  Acknowledgments

   The authors would like to acknowledge the following people for their
   feedback on updating the definitions in this document:

   David McGrew, Brian Weis, Philippe Joubert, Brian Swander, Yaron
   Sheffer, Pasi Eronen, Men Long, David Durham, Prashant Dewan, Marc
   Millier, Russ Housley, and Jari Arkko, among others.

   Manav Bhatia would also like to acknowledge Swati and Maitri for
   their continued support.









Grewal, et al.               Standards Track                   [Page 13]
^L
RFC 5840               WESP for Traffic Visibility            April 2010


6.  References

6.1.  Normative References

   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2410]    Glenn, R. and S. Kent, "The NULL Encryption Algorithm
                and Its Use With IPsec", RFC 2410, November 1998.

   [RFC3948]    Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and
                M. Stenberg, "UDP Encapsulation of IPsec ESP Packets",
                RFC 3948, January 2005.

   [RFC4303]    Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
                4303, December 2005.

   [RFC4543]    McGrew, D. and J. Viega, "The Use of Galois Message
                Authentication Code (GMAC) in IPsec ESP and AH", RFC
                4543, May 2006.

   [RFC5226]    Narten, T. and H. Alvestrand, "Guidelines for Writing an
                IANA Considerations Section in RFCs", BCP 26, RFC 5226,
                May 2008.

6.2. Informative References

   [RFC3947]    Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
                "Negotiation of NAT-Traversal in the IKE", RFC 3947,
                January 2005.

   [RFC4302]    Kent, S., "IP Authentication Header", RFC 4302, December
                2005.

   [RFC4306]    Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
                Protocol", RFC 4306, December 2005.

   [Heuristics] Kivinen, T. and D. McDonald, "Heuristics for Detecting
                ESP-NULL packets", Work in Progress, March 2010.












Grewal, et al.               Standards Track                   [Page 14]
^L
RFC 5840               WESP for Traffic Visibility            April 2010


Authors' Addresses

   Ken Grewal
   Intel Corporation
   2111 NE 25th Avenue, JF3-232
   Hillsboro, OR  97124
   USA

   EMail: ken.grewal@intel.com


   Gabriel Montenegro
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   USA

   EMail: gabriel.montenegro@microsoft.com


   Manav Bhatia
   Alcatel-Lucent
   Manyata Embassy
   Nagawara Bangalore
   India

   EMail: manav.bhatia@alcatel-lucent.com
























Grewal, et al.               Standards Track                   [Page 15]
^L