A Bound End-to-End Tunnel (BEET) mode for ESP

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 25 April 2024.¶

Copyright Notice

Copyright (c) 2023 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

2. Background

For years, the idea of a minimal IPsec tunnel mode for end-to-end security has sparked discussions and innovation. BEET mode has been in use for over a decade. It hs the potential to improve secure data transmission. Once BEET mode is standardized its potential for enhancing secure communications would increase with interoperablity.¶

3. Use scenarios

In this section we describe a number of possible use scenarios. None of these scenarios are meant to be complete specifications on how exactly to support the functionality. Separate specifications are needed for that. Instead, the purpose of this section is to discuss the overall benefits of BEET mode, and to lay out a road map for possible future documents. This section is informative.¶

4. Protocol Definition

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

    +-----------------------------+
    | inner IP hdr  | TCP | Data  |
    +-----------------------------+

    +--------------------------------------------------+
    | outer IP hdr  |     |     |      |   ESP   | ESP |
    | (any options) | ESP | TCP | Data | Trailer | ICV |
    +--------------------------------------------------+
                          |<---- encryption ---->|
                    |<-------- integrity ------->|

    +------------------------------------------------------+
    | outer    | new ext |     |     |      |  ESP   | ESP |
    | IPv6 hdr | hdrs.   | ESP | TCP | Data | Trailer| ICV |
    +------------------------------------------------------+
                               |<--- encryption ---->|
                         |<------ integrity -------->|

    +----------------------------+
    | inner IP hdr  |     |      |
    |  + options    | TCP | Data |
    +----------------------------+

    +------------------------------------------------------------+
    | outer IP hdr  |     | PH      |     |      |   ESP   | ESP |
    | (any options) | ESP | Options | TCP | Data | Trailer | ICV |
    +------------------------------------------------------------+
                          |<------- encryption ----------->|
                    |<----------- integrity -------------->|
                        PH = BEET mode Pseudo-Header

    +---------------------------------------------------------------+
    | outer  | new ext |     | PH       |     |      |  ESP   | ESP |
    | IP hdr | hdrs.   | ESP | Options  | TCP | Data | Trailer| ICV |
    +---------------------------------------------------------------+
                             |<------ encryption ------------>|
                       |<---------- integrity --------------->|

                               PH = BEET mode Pseudo-Header

    +--------------------------------------+
    |                |  ext   |     |      |
    | inner IPv6 hdr |  hdrs  | TCP | Data |
    +--------------------------------------r+-

    +--------------------------------------------------------------+
    | outer    | new ext |     | ext  |     |      |  ESP    | ESP |
    | IPv6 hdr | hdrs.   | ESP | hdrs | TCP | Data | Trailer | ICV |
    +--------------------------------------------------------------+
                               |<-------- encryption ------------->|
                         |<-------------- integrity -------------->|

    ---------------------------------------------------
    | outer  |     | ext  |     |      |  ESP    | ESP |
    | IP hdr | ESP | hdrs.| TCP | Data | Trailer | ICV |
    ---------------------------------------------------
                   |<------- encryption -------->|
             |<----------- integrity ----------->|

5. Cryptographic processing

The outgoing packets MUST be protected exactly as in ESP transport mode [RFC4303]. That is, the upper layer protocol packet is wrapped into an ESP header, encrypted, and authenticated exactly as if regular transport mode was used. The resulting ESP packet is subject to IP header processing as defined in Section 6 and Section 7. The incoming ESP protected messages are verified and decrypted exactly as if regular transport mode was used. The resulting cleartext packet is subject to IP header processing as defined in Section 6 and Section 8¶

6. IP header processing

The biggest difference between BEET mode and the other two modes lies in the way IP headers are processed. In regular transport mode, the IP header is kept intact. In the regular tunnel mode, an outer IP header is created on output and discarded on input. In BEET mode, the IP header is replaced with another one on both input and output.¶

On the BEET mode output side, the IP processing MUST first ensure that the IP addresses in the original IP header contain the inner addresses as specified in the SA. This MAY be ensured by proper policy processing, and it is possible that no checks are needed at the SA processing time. Once the IP header has been verified to contain the right IP inner addresses, it is discarded. A new IP header is derived, using the discarded inner header as a hint for other fields except the IP addresses, the IPv4 options, the IPv6 optional extensions, and the IPv4 fragmentation offset when the packet is a fragment. The IP addresses in the new header MUST be the outer tunnel addresses.¶

On the input side, the received IP header is simply discarded. Since the packet has been decrypted and verified, no further checks are necessary. A new IP header, corresponding to a tunnel mode inner header, is derived, using the discarded outer header as a hint for other fields but the IP addresses, the IPv4 options, the IPv6 optional extensions, and the IPv4 fragmentation offset when the packet is a fragment. The IP addresses in the new header MUST be the inner addresses negotiated.¶

As the outer header fields are used as a hint for creating the inner header, it must be noted that the BEET inner header differs from tunnel mode inner headers. In BEET mode, an inner header will contain the TTL, DF-bit and other option values from the outer header. The TTL, DF-bit and other option values of the inner header MUST be processed by the stack. [AA would we loose the DF value?? if IPsec gateway has different policy? or is possible to restore the same as inner packet?]¶

7. Handling of outgoing packets

The outgoing BEET mode packets are processed as follows:¶

• The system MUST verify that the IP header contains the inner source and destination addresses, exactly as defined in the SA. This verification MAY be explicit, or it MAY be implicit, for example, as a result of prior policy processing. Note that in some implementations there may be no real IP header at this time, but the source and destination addresses may be carried out-of- band. In case the source address is still unassigned, it SHOULD be ensured that the designated inner source address would be selected at a later stage.¶
• The IP payload (the contents of the packet beyond the IP header) is wrapped into an ESP header as defined in [RFC4303] Section 3.3.¶
• A new IP header is constructed, replacing the original one. The new IP header MUST contain the outer source and destination addresses, as defined in the SA. Note that in some implementations there may be no real IP header at this time but the source and destination addresses may be carried out-of-band. In cases where the source address must be left unassigned, it SHOULD be ensured that the right source address is selected at a later stage. Other than the addresses, it is RECOMMENDED that the new IP header copies the fields from the original IP header, unless the packet is a IP fragment.¶
• If there are any IPv4 options in the original packet, they are copied into ESP payload. The IPv4 options are tunneled between the tunnel end-points. The sender MUST encapsulate the options as defined in Section 9.¶
• If the packet is an IPv4 fragment, the flags and the fragment offset field from the inner IP packet MUST NOT be copied. Instead these two fields MUST be encapsulated with a PH header as defined in Section 9.¶

Instead of literally discarding the IP header and constructing a new one, a conforming implementation MAY simply replace the addresses in an existing header. However, if the RECOMMENDED feature of allowing the inner and outer addresses from different address families is used, this simple strategy does not work.¶

8. Handling of incoming packets

The incoming BEET mode packets are processed as follows:¶

1. The system MUST successfully verify and decrypt the incoming packet, as specified in [RFC4303] section 3.4. If the verification or decryption fails, the packet MUST be discarded.¶
2. The original IP header is discarded without further verification since the ESP verification has already confirmed the packet's integrity and source. The packet can be safely assumed to have arrived from the right sender.¶
3. A new IP header is constructed, replacing the original one. The new IP header MUST contain the inner source and destination addresses, as defined in the SA. If the sender has set the ESP next protocol field to 94 and included the Pseudo-Header as described in Section 9, the receiver MUST include the options after the constructed IP header. Note, that in some implementations the real IP header may have already been discarded and the source and destination addresses are carried out-of-band. In such case the out-of-band addresses MUST be the inner addresses. Other than the addresses, it is RECOMMENDED that the new IP header copies the fields from the original IP header. [AA how about ESP in UDP and mapping changes?]¶

Alternatively, a conforming implementation MAY replace the addresses in an existing header rather than discarding it and creating a new one. However, if the RECOMMENDED feature of allowing the inner and outer addresses from different address families is used, this simple strategy does not work.¶

9. IPv4 Pseudo Header

In BEET mode, if IPv4 options or IPv6 optional extensions are transported inside the tunnel, as ESP payload. For IPv4, the sender MUST include a Pseudo Header(PH) after ESP header. The pseudo-headerr indicates the IPv4 packet has options or the fragmentation flags and fragmentation offset is set.¶

The sender MUST set the next protocol field on the ESP header as 94. The resulting pseudo header including the IPv4 options, MUST be padded to 8 octet boundary. The padding length is expressed in octets, valid padding lengths are 0 or 4 octets as the original IPv4 options are already padded to 4 octet boundary. The padding MUST be filled with NOP options as defined in Internet Protocol [RFC791] section 3.1 Internet header format. The padding is added in front of the original options to ensure that the receiver is able to reconstruct the original IPv4 datagram. The Header Length field contains the length of the IPv4 options, and padding in 8 octets units.¶

    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  |   Header Len  |    Pad Len    |F = 2| Reserved|
   +---------------+---------------+-------------------------------+
   | IHF = 3 |Fragment offset (opt.) = 13 | PH padding             |
   +-----------------------------------------+---------------------+
   |                     IPv4 options (opt.) | Opt Padding         |
   +---------------------------------------------------------------+

• Next Header - Identifies the data following this header.¶

• Header Len - 8-bit unsigned integer. Length of the pseudo header in 8-octet units, including IHF and Fragment offset, IPv4 options, when present, not including the first 8 octets.¶

• Pad Len - 8-bits unsigned integer. Length of padding in octets, valid padding lengths are:¶

  • 0, 4 : no IPv4 fragment and options are present [AA Note : old case]¶

  • 2, 6 : IPv4 fragment and no IPv4 options.¶

  • 2, 6 : IPv4 fragment and options.¶

• F - 2 bits Flags. 00 IP options, 01 Fragment, 10 IP options and Fragment, 11 Reserved¶

• Reserved - Lower 6-bits, set to zero¶

• IHF - Flags from the inner IP header (optional) when F = 01 or 10¶

• Fragment offset 13 bits - Fragment offset from the inner IP header (optional) when F = 01 or 10¶

• Padding - 0, 2 or 4 octets of zeros, depending on the fragment flag.¶

• IPv4 options - IPv4 options from the inner IP header with optional padding. Alligned to 32 bits.¶

The receiver MUST remove this pseudo-header and padding as a part of BEET processing, in order to reconstruct the original IPv4 datagram. The IPv4 options included in the pseudo-header MUST be added after the reconstructed IPv4 (inner) header on the receiving side. Also copy the flags and Fragment offset when the PH flags is 01, 10.¶

Note: when the IPv4 options are present, the outer header's IHL would be different from the inner header IHL.¶

The receiver MUST remove this pseudo-header and padding as a part of BEET processing, in order reconstruct the original IPv4 datagram. The IPv4 options included into the pseudo-header MUST be added after the reconstructed IPv4 (inner) header on the receiving side.¶

Note: When the pseudo-header is present due to the presence of IPv4 options in the inner IP header, the outer header's IHL (Internet Header Length) would be different from the inner IP header IHL.¶

10. IPv4 Inner Fragments

When the inner IPv4 datagram is a fragment (as specified by the "more-fragments" flag being set to one [RFC791]), this flag MUST NOT be copied to the outer ESP datagram header. Additionally, for any non-first fragment with a "more-fragments" flag or "fragment offset field," these two fields MUST NOT be copied to the outer IPv4 header of the ESP datagram.¶

Here are a few possible ways to deal with these IPv4 fragments.¶

1. Re-assemble the IPv4 fragments, send to ESP, and ESP datagram may be fragmented as required.¶
2. Drop the IPv4 fragments, i.e., BEET mode IPv4 support for fragments is optional.¶
3. Copy the fragment flag and offset length from the inner IPv4 header to BEET pseudo-header Section 9.¶
4. Explore other solutions? [TBD?]¶

TBD Discuss/Decide which of the above options make sense.¶

11. IPv6 inner Fragments

It's crucial to highlight that IPv6 uses fragmentation information in a distinct manner than IPv4 [RFC8200] Section 4.5. Specifically, an IPv6 fragment uses IPv6 optional extensions for fragments. BEET mode treats the IPv6 optional extensions as ESP payload and move from inner header to ESP payload.¶

12. Mixed family IPv4 inside and IPv6 outside

The inner datagram's IP version MUST be independent of the outer IP version. The inner address family and address are taken from the negotiated Traffic Selectors. When the inner datagram contains IPv4 with fragments or IPv4 options, use Section 9.¶

13. Mixed family IPv6 inside and IPv4 outside

When the inner datagram is an IPv6 datagram with IPv6 optional extensions, copy it into ESP payload Section 11.¶

14. Policy Considerations

In this section we describe how BEET mode affects on IPsec policy processing. This section is normative.¶

A BEET Security Association SHOULD NOT be used with NULL authentication.¶

On the output side, the IPsec policy processing mechanism SHOULD take care that only packets with IP addresses matching the inner addresses of a Security Association are passed on to that Security Association. If the policy mechanism does not provide full assurance on this point, the SA processing MUST check the addresses. Further policy distinction may be specified based on IP version, upper layer protocol, and ports. If such restrictions are defined, they MUST be enforced.¶

On the output side, the policy rules SHOULD prevent any packets containing the pair of inner IP addresses from escaping to the wire in cleartext.¶

On the input side,no policy processing is necessary for encrypted packets. The SA is deduced from the SPI and destination address. A single SA MAY be associated with several outter destination addresses. Since the outer IPsec addresses are discarded, and since the packet authenticity and integrity are protected by ESP, there is no need to check the outer addresses. Since the inner addresses are fixed and restored from the SA, there is no need to check them. There MAY be further policy rules specifying allowed upper layer protocols and ports. If such restrictions are defined, they MUST be enforced.¶

On the input side, there SHOULD be a policy rule that filters out cleartext packets that contain the inner addresses.¶

15. Security Considerations

In this section we discuss the security properties of the BEET mode, discussing some and point out some of its limitations [RFC3552].¶

There are no known new vulnerabilities that the introduction of the BEET mode would create.¶

It is currently possible to implement the equivalent of BEET mode by using transport mode ESP and explicit network address translation at the end-hosts themselves. However, such an implementation is more complex, less flexible, and potentially more vulnerable to security problems that are caused by misconfigurations; see Section 9.¶

The main security benefit is an operational one. To implement the same functionality without BEET mode typically requires configuring three different, unrelated components in the hosts.¶

• The transport mode ESP SAs must be configured.¶
• A host-based NAT function must be configured to properly translate between the inner and outer addresses.¶
• A host firewall must be configured to properly filter out packets so that inner addresses do not leak in or out.¶

While it may be possible to configure these components to achieve the same functionality, such a configuration is error prone, increasing the probability of security vulnerabilities. An integrated BEET mode implementation is less prone to configuration mistakes. Furthermore, it would be fairly hard to implement portable key management protocols that would be able to configure all of the required components at the same time. On the other hand, it would be easy to provide a portable key management protocol implementation that would be able to configure BEET mode SAs through the specified PF_KEY extensions.¶

Since the BEET security associations have the semantics of a fixed, point-to-point tunnel between two IP addresses, it is possible to place one or both of the tunnel end0points into other nodes but those that actually "possess" the inner IP addresses, i.e., to implement a BEET mode proxy. However, since such usage defeats the security benefits of combined ESP and hostNAT processing, as discussed above, the implementations SHOULD NOT support such usage.¶

Because in BEET mode the outer header source address is not checked at the time of input handling, there is a potential for a DoS attack where the attacker would send random packets that match the SPI of some BEET-mode SA. This kind of attack would cause the victim to perform unnecessary integrity checks that would result in a failure. However, if this kind of behavior is detected, the node may request rekeying using IKEv2 rekey, and after rekeying. If the attacker was not on the path, the new SPI value would not be known by the attacker.¶

16. IKEv2 Negotiation

When negotiating a Child SA using using IKEv2, the initiator may use the new "USE_BEET_MODE" Notify Message to request a Child SA pair with BEET mode support. The method used is similar to how USE_TRANSPORT_MODE is negotiated, as described in [RFC7296]¶

To request a BEET-mode SA on the Child SA pair, the initiator MUST include the USE_BEET_MODE Notify Message when requesting a new Child SA, either during the IKE_AUTH or CREATE_CHILD_SA exchanges. If the request is accepted, the response MUST also include a USE_BEET_MODE notification. If the responder declines and does not include the USE_BEET_MODE notification in the response, the child SA will be established without BEET mode enabled. If this is unacceptable to the initiator, the initiator MUST delete the child SA.¶

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      !
+---------------+---------------+-------------------------------+

17. 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_BEET_MODE                      [this document]

18. 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].¶

19. Acknowledgments

We sincerely thank the previous authors and contributors whose work laid the foundation for this document. Their insights and dedication have greatly influenced our work, also their contributions to the BEET mode implementation many years ago.¶

Special thanks to Peka Nikander for generously granting permission to use their previous work [I-D.nikander-esp-beet-mode].¶

We appreciate the guidance and support from Tero Kivinen in reaching out to previous authors during the document's development.¶

Our gratitude also goes to all those who provided feedback, guidance, and support throughout this document's development and operational experience. Your contributions were vital in making this work possible.¶

Appendix A. Additional Stuff

This becomes an Appendix.¶

Authors' Addresses