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 2 February 2026.¶

Copyright Notice

Copyright (c) 2025 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. Terms and Definitions

5. IP Header Processing

The biggest difference between BEET mode and the other two modes is in IP header processing. In the 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 header 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 time of SA processing. Once the IP header has been verified to contain the right IP inner addresses, it is discarded. A new IP header is created, using the fields of the discarded inner header (except the IP addresses) to populate the fields of the new outer header. 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 BEET mode inner header is created, using the fields of the discarded outer header (except the IP addresses) to populate the fields of the new inner header. The IP addresses in the new header MUST be the inner addresses.¶

As the outer header fields are used as a hint for creating the inner header, it must be noted that the inner header differs as compared to a tunnel mode inner header. In BEET mode, the inner header will have the Time to Live (TTL), Don't Fragment (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.¶

6. Handling of Outgoing Packets

The outgoing BEET mode packets are processed as follows:¶

1. 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. If the source address is still unassigned, it SHOULD be ensured that the designated inner source address would be selected at a later stage.¶
2. The IP payload (the contents of the packet beyond the IP header) is wrapped into an ESP header as defined in Section 3.3 of [RFC4303].¶
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 the case 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.¶
4. If there are any IPv4 options in the original packet, it is RECOMMENDED that they are discarded. If the inner header contains one or more options that need to be transported between the tunnel endpoints, the sender MUST encapsulate the options as defined Section 8.¶

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

7. Handling of Incoming Packets

The incoming BEET mode packets are processed as follows:¶

1. The system MUST verify and decrypt the incoming packet successfully, as defined in Section 3.4 of [RFC4303]. If the verification or decryption fails, the packet MUST be discarded.¶
2. The original IP header is simply discarded, without any checks. Since the ESP verification succeeded, 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 Header field to 94 and included the pseudo header as described in Section 8, 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 a 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?]¶

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 IPv4 Options

In BEET mode, if IPv4 options are transported inside the tunnel, the sender MUST include a pseudo header after the ESP header. The pseudo header indicates that IPv4 options from the original packet are to be applied to the packet on the input side or the IPv4 fragmentation flags and fragmentation offset is set.¶

The sender MUST set the Next Header field in the ESP header to 94. The resulting pseudo header, including the IPv4 options, MUST be padded to an 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 a 4-octet boundary. The padding MUST be filled with No Operation (NOP) options as defined in (Internet Header Format) Section 3.1 of [RFC791] (Internet Protocol). 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-octet 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    |       Reserved|
+---------------+---------------+-------------------------------+
|              Padding (if needed)                              |
+-----------------------------------------+---------------------+
|                     IPv4 options ...                          |
|                                                               |
+---------------------------------------------------------------+

Next Header

identifies the data following this header.¶

Length in octets

8-bit unsigned integer. Length of the pseudo header in 8-octet units, not including the first 8 octets.¶

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

[AA NOTE: Note: when the IPv4 options are present, the outer header's IHL would be different from the inner header IHL NEXT paragraph is extra???]¶

9. Handling of Inner IP Fragment

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

10. IPsec Specific Policy Considerations

In this section we describe how BEET mode affects 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.¶

Authors' Addresses