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

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

A BEET mode Security Association contains the same data as a regular tunnel mode Security Association, with the exception that the inner selectors must be single addresses and cannot be subnets. The data includes the following:

A pair of inner IP addresses.
A pair of outer IP addresses.
Cryptographic keys and other data as defined in .

A conforming implementation MAY store the data in a way similar to a regular tunnel mode Security Association. Note that in a conforming implementation, the inner and outer addresses MAY belong to different address families. All implementations that support both IPv4 and IPv6 SHOULD support both IPv4-over-IPv6 and IPv6-over-IPv4 tunneling.

The wire packet format is identical to the ESP transport mode wire format as defined in Section 3.1.1 of . However, the resulting packet contains outer IP addresses instead of the inner IP addresses received from the upper layer. The construction of the outer headers is defined in . The following diagram illustrates ESP BEET mode positioning for typical IPv4 and IPv6 packets.

IPv4 INNER DATAGRAM BEFORE APPLYING ESP

AFTER APPLYING ESP, OUTER v4 ADDRESSES | |<-------- integrity ------->| ]]>

AFTER APPLYING ESP, OUTER v6 ADDRESSES | |<------ integrity -------->| ]]>

IPv4 INNER DATAGRAM with IP options BEFORE APPLYING ESP

IPv4 AFTER APPLYING ESP, OUTER v4 ADDRESSES INNER IPv4 OPTIONS | |<----------- integrity --------->| PH = BEET mode Pseudo-Header ]]>

IPv4 + OPTIONS AFTER APPLYING ESP, OUTER IPv6 ADDRESSES | |<---------- integrity --------------->| PH = BEET mode Pseudo-Header ]]>

IPv6 DATAGRAM BEFORE APPLYING ESP

IPv6 DATAGRAM AFTER APPLYING ESP, OUTER IPv6 ADDRESSES | |<-------------- integrity -------------->| ]]>

IPv6 DATAGRAM AFTER APPLYING ESP, OUTER IPv4 ADDRESSES | |<----------- integrity ----------->| ]]>

The outgoing packets MUST be protected exactly as in ESP transport mode . 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 and . 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 and

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.

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

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.

The incoming BEET mode packets are processed as follows:

The system MUST verify and decrypt the incoming packet successfully, as defined in . If the verification or decryption fails, the packet MUST be discarded.
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.
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 , 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?]

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

BEET mode pseudo header format

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???]

When the inner IPv4 datagram is a fragment (as specified by the "more-fragments" flag being set to one ), 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.

Re-assemble the IPv4 fragments, send to ESP, and ESP datagram may be fragmented as required.
Drop the IPv4 fragments, i.e., BEET mode IPv4 support for fragments is optional.
Copy the fragment flag and offset length from the inner IPv4 header to BEET pseudo-header, .

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

BEET mode pseudo header format

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.

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

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 .

Mixed family IPv6 inside and IPv4 outside. When the inner datagram is an IPv6 datagram with IPv6 optional extension headers, copy it into ESP payload