Internet-Draft WESPv2 June 2024
Klassert & Antony Expires 30 December 2024 [Page]
Workgroup:
IPSECME Working Group
Published:
Intended Status:
Standards Track
Expires:
Authors:
S. Klassert
secunet
A. Antony
secunet

Wrapped ESP Version 2

Abstract

This document describes the Wrapped Encapsulating Security Payload v2 (WESPv2) protocol, which builds on the Encapsulating Security Payload (ESP) [RFC4303]. It is designed to overcome limitations of the ESP protocol to expose inner flow information to the network in a transparent way. To do so, it adapts IPv6 Extension header options to WESPv2 where flow identitiers can be stored. It also defines a Crypt Offset to allow intermediate devices to read some header bytes at the beginning of the inner packet. In particular, this preserves the original use-case of WESP [RFC5840].

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 30 December 2024.

▲

Table of Contents

1. Introduction

WESPv2 is a wrapper for the ESP protocol. Due to the absence of a version number in the ESP protocol, in the packet header, ESP can't be updated in a transparent way. Any updates to ESP must be negotiated by IKEv2 and for that, indiscernible to intermediate devices such as routers and firewalls. In the recent past, several attempts were taken to introduce a Flow Identifier for certain use-cases. Examples are [I-D.ponchon-ipsecme-anti-replay-subspaces] and [I-D.he-ipsecme-vpn-shared-ipsecsa]. Such a Flow Identifier could also be used to perform ECMP based on the inner flows at intermediate devices or endpoints. Additionally to that, there exists a specification of the [PSP] protocol that has the need of a Flow Identifier, called Network Identifier (VNI) there. PSP also defines a Crypto Offset to expose parts of the headers of the inner packet. Showing headers on the inner packet was also the original usecase for the WESP protocol. WESPv2 provides a solution for all the aforementioned use-cases.

The WESPv2 Options introduced by WESPv2 are considered to be opaque to this document. Future documents can define the meaning of these fields for their particular use-case. With this, all existing and potential new use-cases for Flow Identifiers can be covered. For instance it can be used for the case of [I-D.ponchon-ipsecme-anti-replay-subspaces] or [I-D.he-ipsecme-vpn-shared-ipsecsa] etc., or combinations thereof. A detailed discussion about the problems of the ESP protocol can be found in [I-D.mrossberg-ipsecme-multiple-sequence-counters].

Though this document specifies IKEv2 as a negotiation protocol, WESPv2 may use other protocols for negotiation and key derivation. The packet specification is portable to other key protocol use cases, such as [PSP], and offers versioning at the packet level.

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. Terminology

This document uses the following terms defined in IKEv2 [RFC7296]: Child SA, CREATE_CHILD_SA, IKE_AUTH exchange, USE_TRANSPORT_MODE

This document uses the following terms defined in [PSP]: PSP (a recursive acronym for PSP Security Protocol), Network Identifier (VNI), Crypt Offset.

This document uses the following terms defined in [RFC5840]: Wrapped Encapsulating Security Payload (WESP), USE_WESP_MODE.

This document uses the following terms defined in [RFC2992]: Equal-cost multi-path (ECMP)

This document uses the following terms defined in [RFC4303]: Encapsulating Security Payload (ESP).

This document uses the following terms defined in [I-D.mrossberg-ipsecme-multiple-sequence-counters]: Sub-Child SA.

2. Protocol Definition

In this section we define the exact protocol formats and operations. This section is normative.

2.1. WESPv2 header format

The WESPv2 header is split into a 4 byte base header that is always present and an optional part directly following the base header. The base header essentially describes how to treat the packet. The optional part of the header defines Options to store a integrity protected flow identifiers that can be used for flow classification.

The header is constructed in a way that the start of the following next header is aligned on a 4 byte boundary on IPv4 and on a 8 byte boundary on IPv6 respective the start of the IPv4/IPv6 header. Like WESPv1, this extension essentially acts as a wrapper to the existing ESP protocol. The value of the new protocol version used to identify this new header is not changed. Instead, the version number in the Flags field is incremented to identify this new protocol version. 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     |CryptOffset| R | V |  OptLen   |
   +---------------+---------------+-------------------------------+
   |                                                               |
   ~                             Options                           ~
   |                                                               |
   +---------------------------------------------------------------+
   |                   Existing ESP Encapsulation                  |
   ~                                                               ~
   |                                                               |
   +---------------------------------------------------------------+
Figure 1: WESPv2 header format
  • Next Header - 8 bits: This field MUST be the same as the Next Header field in the ESP trailer whenever the Crypt Offset field is nonzero. When the Crypt Offset field is zero, the Next Header MUST be set to 59, [RFC8200] Section 4.7. The receiver MUST do some sanity checks before the WESPv2 packet is accepted. The receiver MUST ensure that the Next Header field in the WESPv2 header and the Next Header field in the ESP trailer match whenever the Next Header field is nonzero. The packet MUST be dropped if the two do not match. Similarly, the receiver MUST ensure that the Next Header field in the WESPv2 header is an empty field initialized to 59 if the Crypt Offset field is zero.
  • HdrLen - 8 bits: Offset from the beginning of the WESPv2 header to the beginning of the Rest of Payload Data (i.e., past the IV, if present and any other WESPv2 options defined in the future) within the encapsulated ESP header, in octet. 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.
  • Crypt Offset - 6 bits: The offset from the end of the IV to the start of the encrypted portion of the packet, measured in 4 octet units. The resulting value MUST NOT be larger than the size of the inner packet. A zero CryptOffset means that the complete packet is authenticated and encrypted. A positive CryptOffset means that the first 'CryptOffset * 4' octets of the inner packet belong to the AAD but are not encrypted. In this case the Next Header field MUST be the same as the Next Header field in the ESP trailer, so that the Header can be parsed by intermediate devices. (Authors note: This is to preserve the original WESP use-case and because PSP uses this too. In case the Flow Identifier Options can carry enough information about inner flows, we can remove the cryptoffset.)
  • Reserved - 2 bits: Set to zero on transmit, ignored on receive.
  • Version (V) - 2 bits: MUST be sent to 01 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 WESPv2 header require a new version number. In particular, the version of WESPv2 defined in this document does not allow for any extensions. However, old implementations will still be able to find the encapsulated clear-text packet using the HdrLen field from the WESPv2 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).
  • OptLen - 6 bit: Total length of all options included in the WESPv2 header Options, in octets.
  • Options - variable: Authenticated field with additional flow informations and padding.

2.2. Options

WESPv2 options carry a variable number of "options" that are type-length- value (TLV) encoded in the same format as done in [RFC8200] Section 4.2 for IPv6 extension headers. This document defines three different option classes, Padding Options, Flow Identifier Options and Private Options.

Padding Options MUST be used to align the start of the next header to the natural alignment of the protocol, i.e. 4 byte for IPv4 and 8 byte for IPv6. Other padding, like padding for cipher text alignment, is out of the scope of this document. Future documents can define this by using the existing padding options. Additional padding MUST be negotiated by IKEv2 or any other suitable protocol.

Flow Identifier Options MUST carry characteristic information of the inner flow, i.e. MUST NOT change on per packet basis. It MUST be negotiated by IKEv2 or any other suitable protocol. The detailed specification of Flow Identifiers MUST be provided in subsequent documents. These Options are opaque to intermediate devices; however, intermediate routers MAY use it for identifying flows for ECMP or similar purposes. e.g. Sub-Child SAs, in [I-D.mrossberg-ipsecme-multiple-sequence-counters]could be encoded here. Flow Identifiers MUST have the format of Options as defind in Section 2.2.1.

Private Options comming from a reserved Option Type Range and can be used for any purposes that are out of scope for standardization. For example it can be used to encode hardware specific information, such as used encryption/authentication algorithms as done in [PSP].

The only WESPv2 Option Types defined in this document are the Pad1 and PadN options specified in Section 2.2.1.

2.2.1. Adapting IPv6 Extension header options

WESPv2 extension header Options are adapted from IPv6 extension header Options as defined in Section 4.2 of [RFC8200], with the following modifications:

  • References to the IPv6 header are removed.
  • The two highest-order bits of the Option Type MUST be set to 00, if the Option Type comes from the private range.
  • The third-highest-order bit of the Option Type MUST be set to 0.
  • References to the Hop-by-Hop Options header and the Destination Options header are removed.

2.2.2. WESPv2 Extension header options

WESPv2 Options carry a variable number of type-length-value (TLV) encoded "options", of the following format:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
   |  Option Type  |  Opt Data Len |  Option Data
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Figure 2
  • Option Type: 8-bit identifier of the type of option.
  • Opt Data Len: 8-bit unsigned integer. Length of the Option Data field of this option, in octets.
  • Option Data: Variable-length field. Option-Type-specific data.

The sequence of options within a header must be processed strictly in the order they appear in the header; a receiver must not, for example, scan through the header looking for a particular kind of option and process that option prior to processing all preceding ones.

The Option Type identifiers are internally encoded such that their highest-order two bits specify the action that must be taken if the processing node does not recognize the Option Type:

  • 00 - skip over this option and continue processing the header.
  • 01 - discard the packet.
  • 10 - discard the packet and, regardless of whether or not the packet's Destination Address was a multicast address, send an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type.
  • 11 - discard the packet and, only if the packet's Destination Address was not a multicast address, send an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type.

Options from the private range MUST set the two highest-order bit to 00.

The third-highest-order bit of the Option Type specifies whether or not the Option Data of that option can change en-route to the packet's final destination. That bit is left in to be compliant with IPv6 extenstion header options. WESPv2 options are authenticated, therefore this bit MUST be set to 0.

  • 0 - Option Data does not change en-route
  • 1 - Option Data may change en-route

The three high-order bits described above are to be treated as part of the Option Type, not independent of the Option Type. That is, a particular option is identified by a full 8-bit Option Type, not just the low-order 5 bits of an Option Type.

Individual options may have specific alignment requirements, to ensure that multi-octet values within Option Data fields fall on natural boundaries. The alignment requirement of an option is specified using the notation xn+y, meaning the Option Type must appear at an integer multiple of x octets from the start of the header, plus y octets. For example:

  • 2n means any 2-octet offset from the start of the header.
  • 8n+2 means any 8-octet offset from the start of the header, plus 2 octets.

There are two padding options which are used when necessary to align subsequent options and to pad out the containing header to a multiple of 8 octets in length. These padding options must be recognized by all implementations:

Pad1 option (alignment requirement: none)

   +-+-+-+-+-+-+-+-+
   |       0       |
   +-+-+-+-+-+-+-+-+
Figure 3

Note! the format of the Pad1 option is a special case -- it does not have length and value fields.

The Pad1 option is used to insert one octet of padding into the Options area of a header. If more than one octet of padding is required, the PadN option, described next, should be used, rather than multiple Pad1 options.

PadN option (alignment requirement: none)

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
   |       1       |  Opt Data Len |  Option Data
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Figure 4

The PadN option is used to insert two or more octets of padding into the Options area of a header. For N octets of padding, the Opt Data Len field contains the value N-2, and the Option Data consists of N-2 zero-valued octets.

Appendix A of [RFC8200] contains applicable formatting guidelines for designing new options.

2.3. UDP Encapsulation

UDP Encapsulation is done as in [RFC5840].

2.4. Packet format

The following section defines the resulting packet format. Tunnel and Transport Modes are handled exactly the same way as in WESP [RFC5840]. The WESPv2 headers are inserted between the outer IPv4/IPv6 header and the ESP header. The WESPv2 header MUST be inserted before the cryptographic operations. After inserting the WESPv2 header, the crypto operations are performed. The full WESPv2 header, including all header Options MUST be included into the integrity protected part of the packet.

2.5. IPv4 Datagram 


            ---------------------------------------------------
            | outer IP hdr  | ESP | ESP Payload |   ESP   |ESP|
            | (any options) | Hdr |    Data     | Trailer |ICV|
            ---------------------------------------------------
Figure 5: IPv4 DATAGRAM BEFORE APPLYING WESP 

                      |<-WESPv2 Hdr->|
        -------------------------------------------------------
        |outer IP hdr | WESP |  OPT  | ESP | Pyld |  ESP  |ESP|
        |(any options)| BHdr | (var) | Hdr | Data |Trailer|ICV|
        -------------------------------------------------------
                                           |<-encryption->|
                      |<----------- integrity ----------->|
Figure 6: IPv4 DATAGRAM AFTER APPLYING WESP

2.6. IPv6 Datagram 


            -----------------------------------------------------
            |  outer   | ext. | ESP | ESP Payload |   ESP   |ESP|
            | IPv6 Hdr | Hdrs | Hdr |    Data     | Trailer |ICV|
            -----------------------------------------------------
Figure 7: IPv6 DATAGRAM BEFORE APPLYING WESP 

                      |<-WESPv2 Hdr->|
        -------------------------------------------------------
        |  outer |ext.| WESP |  OPT  | ESP | Pyld |  ESP  |ESP|
        |IPv6 Hdr|Hdrs| BHdr | (var) | Hdr | Data |Trailer|ICV|
        -------------------------------------------------------
                                           |<-encryption->|
                      |<----------- integrity ----------->|
Figure 8: IPv6 DATAGRAM AFTER APPLYING WESP

3. IKEv2 Negotiation

The IKEv2 negotiation follows exactly the way it is done in WESP [RFC5840], with the difference that a new notification USE_WESPv2_MODE is used.

This document assumes that WESPv2 negotiation is performed using IKEv2. In order to negotiate the new format of ESP encapsulation via IKEv2 [RFC7296], 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 [RFC7296].

When negotiating a WESPv2 Child SA, USE_WESPv2_MODE MUST be included in a either in an IKE_AUTH exchange or CREATE_CHILD_SA. and the rest of SA payload necessary for a Child SA using ESP. It signals that the sender supports the WESPv2 version defined in the current document and requests that the Child SA use WESPv2 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 should be established using ESP, as per [RFC7296]. If this is unacceptable to the initiator, the initiator MUST delete the Child SA.

Note: Except when using the options to negotiate WESPv1 or WESPv2 mode, all CHILD_SAs will use standard ESP.

Negotiation of WESPv2 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.

WESPv2 version negotiation is not specified here. If the WESP version is updated in a future specification, then that document MUST specify how the WESP version is negotiated.

3.1. USE_WESPv2_MODE Payload Format

All multi-octet fields representing integers are laid out in big endian order (also known as "most significant byte first", or "network byte order").


                    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 Payload  !C!  RESERVED   !         Payload Length        !
+---------------+---------------+-------------------------------+
!  Protocol ID  !   SPI Size    !      Notify Message Type      !
+---------------+---------------+-------------------------------+
!0|F|CryptOffset!                                               !
+-------------------------------+-------------------------------+
Figure 9
  • Protocol ID (1 octet) - MUST be 0. MUST be ignored if not 0.
  • SPI Size (1 octet) - MUST be 0. MUST be ignored if not 0.
  • Notify Status Message Type value (2 octets) - set to [TBD].
  • Notify Payload: bit 0 reserved. bit 1 Flow ID supported. Bits 2-7 Crypt Offset len in 4 octets

4. IANA Considerations

This document defines a new IKEv2 Notify Message Type payloads for the IANA "IKEv2 Notify Message Types - Status Types" registry.


      Value   Notify Type Messages - Status Types    Reference
      -----   ------------------------------    ---------------
      [TBD1]   USE_WESPv2_MODE                  [this document]
Figure 10

This document requests IANA to create a registry called "WESP_OPTIONS Type Registry" under a new category named "WESP_OPTIONS Parameters". This initial content for this registry is as follows:


      Value   WESP Header Options Types          Reference
      -----   ------------------------------    ---------------
          0   Pad1                              [this document]
          1   PadN                              [this document]
      27-31   Private                           [this document]
Figure 11

5. Implementation Status

[Note to RFC Editor: Please remove this section and the reference to [RFC6982]before publication.]

This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.

According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

Authors are requested to add a note to the RFC Editor at the top of this section, advising the Editor to remove the entire section before publication, as well as the reference to [RFC7942].

6. Security Considerations

In this section we discuss the security properties of WESPv2: TBD

7. Acknowledgments

TBD

8. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC2992]
Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, DOI 10.17487/RFC2992, , <https://www.rfc-editor.org/info/rfc2992>.
[RFC3948]
Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, DOI 10.17487/RFC3948, , <https://www.rfc-editor.org/info/rfc3948>.
[RFC4303]
Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, , <https://www.rfc-editor.org/info/rfc4303>.
[RFC5840]
Grewal, K., Montenegro, G., and M. Bhatia, "Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility", RFC 5840, DOI 10.17487/RFC5840, , <https://www.rfc-editor.org/info/rfc5840>.
[RFC7296]
Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, , <https://www.rfc-editor.org/info/rfc7296>.
[RFC8200]
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, , <https://www.rfc-editor.org/info/rfc8200>.

9. Informative References

[I-D.he-ipsecme-vpn-shared-ipsecsa]
He, Q., Pan, W., Chen, X., and B. Ding, "Shared Use of IPsec Tunnel in a Multi-VPN Environment", Work in Progress, Internet-Draft, draft-he-ipsecme-vpn-shared-ipsecsa-00, , <https://datatracker.ietf.org/doc/html/draft-he-ipsecme-vpn-shared-ipsecsa-00>.
[I-D.mrossberg-ipsecme-multiple-sequence-counters]
Rossberg, M., Klassert, S., and M. Pfeiffer, "Broadening the Scope of Encapsulating Security Payload (ESP) Protocol", Work in Progress, Internet-Draft, draft-mrossberg-ipsecme-multiple-sequence-counters-02, , <https://datatracker.ietf.org/doc/html/draft-mrossberg-ipsecme-multiple-sequence-counters-02>.
[I-D.ponchon-ipsecme-anti-replay-subspaces]
Ponchon, P., Shaikh, M., Dernaika, H., Pfister, P., and G. Solignac, "IPsec and IKE anti-replay sequence number subspaces for traffic-engineered paths and multi-core processing", Work in Progress, Internet-Draft, draft-ponchon-ipsecme-anti-replay-subspaces-03, , <https://datatracker.ietf.org/doc/html/draft-ponchon-ipsecme-anti-replay-subspaces-03>.
[PSP]
Google, "PSP Architecture Specification", <https://github.com/google/psp/blob/main/doc/PSP_Arch_Spec.pdf>.
[RFC6982]
Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", RFC 6982, DOI 10.17487/RFC6982, , <https://www.rfc-editor.org/info/rfc6982>.
[RFC7942]
Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, , <https://www.rfc-editor.org/info/rfc7942>.

Appendix A. Additional Stuff

TBD

Authors' Addresses

Steffen Klassert
secunet Security Networks AG
Antony Antony
secunet Security Networks AG