Internet-Draft WESPv2 May 2024
Klassert & Antony Expires 29 November 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 flow information to the network in a transparent way and to align the cipher text to the needs of the sender and receiver. To do so, it defines an optional Flow Identifier where flow specific information 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]. Optional padding can be added for cipher text alignment.

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 29 November 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 64 bit Flow Identifier field introduced by WESPv2 is considered to be opaque to this document. Future documents can define the meaning of this field for their particular use-case. With this, all existing and potential new use-cases for a Flow Identifier 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 if fit into the 64 bit field. 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 ensure proper alignment of the ESP cipher text. It also has an option to store an integrity protected flow identifier that can be used for flow classification.

The header is constructed in a way that the start of the cipher-text is aligned on a 8 byte boundary respective the start of the IPv4/IPv6 header. Any IPv4 options and optional IPv6 extension Headers are not taken into account here. If the sender has different alignment requirements, optional padding can be used to align the cipher-text. The chosen padding size SHOULD NOT change for a given Child SA. (Authors note: Should the padding size be negotiated?) 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 |     Flags     |
   +---------------+---------------+-------------------------------+
   |                        Padding (optional)                     |
   +---------------------------------------------------------------+
   |                         FID (optional)                        |
   |                                                               |
   +---------------------------------------------------------------+
   |                   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. If the Crypt Offset field is zero, the Next Header MUST be set to zero too. 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 zero 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 can carry enough information about inner flows, we can remove the cryptoffset.)
  • Reserved - 2 bits: Set to zero on transmit, ignored on receive.
  • 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|F|  R  |
      +-+-+-+-+-+-+-+-+
Figure 2: Flags Format
  • Version (V) - 2 bits: MUST be sent to 1 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).
  • Encrypted Payload (E) - 1 bit: Has no meaning in WESPv2 as the CryptOffset declares which parts of the payload is protected with encryption. (FIXME: should it be set to 1 to align with WESPv1?)
  • Padding header (P) - 1 bit: If set (value 1), the padding is present. If not set (value 0), the padding is absent.
  • FID (F) - 1 bit: If set (value 1), the FID is present behind the WESPv2 trader. If not set (value 0), the FID is absent.
  • R - 3 bits: Reserved for future versions, MUST be set to 0, and ignored by the receiver.
  • Padding - optional: Used to ensure proper alignment of the cipher-text. Implementations can choose alignment based on their needs. If padding is present, it SHOULD align the cipher-text by a minimum of 16 bytes relative to the start of the IP/IPv6 header.
  • Flow Identifier (FID) - optional: Authenticated field with additional flow informations. If present, this field MUST carry characteristic information of the inner flow, i.e. it SHOULD NOT change on per packet basis. The detailed specification of the FID field MUST be provided in subsequent documents. This field is 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. If present, MUST be 8 byte.,

2.2. UDP Encapsulation

UDP Encapsulation is done as in [RFC5840].

2.3. 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 optional padding and Flow Identifier (FID) MUST be included into the integrity protected part of the packet.

2.4. IPv4 Datagram 


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

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

2.5. IPv6 Datagram 


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

                      |<- WESPv2 Hdr ->|
        -------------------------------------------------------
        |  outer |ext.|WESP| PAD | FID |ESP| Pyld |  ESP  |ESP|
        |IPv6 Hdr|Hdrs|BHdr|(opt)|(opt)|Hdr| Data |Trailer|ICV|
        -------------------------------------------------------
                                           |<-encryption->|
                      |<----------- integrity ----------->|
Figure 6: 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 7
  • 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 8

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

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