Skip to content

Commit 6b8a29c

Browse files
klassertklassert
committed
deploy: 5c657b8 
1 parent 86e39e7 commit 6b8a29c

2 files changed

Lines changed: 103 additions & 60 deletions

File tree

‎draft-ietf-ipsecme-eesp-latest.html‎

Lines changed: 69 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -2048,17 +2048,60 @@ <h3 id="name-full-and-optimized-packet-f">
20482048
is no need for a next header field. Additionally, IPv4 and IPv6 also
20492049
have a field describing the overall size of the inner packet, so a
20502050
pad length field is also not needed as it can be derived.
2051-
When transport mode, beet mode or IPTFS is used, it is not possible
2052-
to derive these information, so the full packet format, including
2053-
the '<code>Payload Info Header</code>' MUST be used.
2054-
The two packet formats are shown below. <a href="#eesp-full-packet-format" class="auto internal xref">Figure 5</a>
2051+
When transport mode, BEET mode, or IP-TFS is used, it is not possible
2052+
to derive this information, so the full packet format, including the
2053+
'<code>Payload Info Header</code>' MUST be used.<a href="#section-2.8-1" class="pilcrow"></a></p>
2054+
<p id="section-2.8-2">The selection of the packet format is determined by the encapsulation
2055+
mode and by whether the values carried in the '<code>Payload Info Header</code>'
2056+
can be inferred from the decrypted payload. Table <a href="#eesp-format-by-mode" class="auto internal xref">Table 1</a>
2057+
summarizes which modes use which format. In this table, "Full" means
2058+
that the '<code>Payload Info Header</code>' is present, and "Optimized" means that
2059+
the '<code>Payload Info Header</code>' is absent (elided).<a href="#section-2.8-2" class="pilcrow"></a></p>
2060+
<span id="name-eesp-packet-format-selectio"></span><div id="eesp-format-by-mode">
2061+
<table class="center" id="table-1">
2062+
<caption>
2063+
<a href="#table-1" class="selfRef">Table 1</a>:
2064+
<a href="#name-eesp-packet-format-selectio" class="selfRef">EESP packet format selection by mode</a>
2065+
</caption>
2066+
<thead>
2067+
<tr>
2068+
<th class="text-left" rowspan="1" colspan="1">Mode</th>
2069+
<th class="text-left" rowspan="1" colspan="1">Packet format</th>
2070+
<th class="text-left" rowspan="1" colspan="1">Notes</th>
2071+
</tr>
2072+
</thead>
2073+
<tbody>
2074+
<tr>
2075+
<td class="text-left" rowspan="1" colspan="1">IPv4/IPv6 tunnel mode</td>
2076+
<td class="text-left" rowspan="1" colspan="1">Optimized</td>
2077+
<td class="text-left" rowspan="1" colspan="1">Inner starts with IPv4/IPv6 header.</td>
2078+
</tr>
2079+
<tr>
2080+
<td class="text-left" rowspan="1" colspan="1">Transport mode</td>
2081+
<td class="text-left" rowspan="1" colspan="1">Full</td>
2082+
<td class="text-left" rowspan="1" colspan="1">Next Header/Pad Length cannot be inferred.</td>
2083+
</tr>
2084+
<tr>
2085+
<td class="text-left" rowspan="1" colspan="1">BEET mode</td>
2086+
<td class="text-left" rowspan="1" colspan="1">Full</td>
2087+
<td class="text-left" rowspan="1" colspan="1">Next Header/Pad Length cannot be inferred.</td>
2088+
</tr>
2089+
<tr>
2090+
<td class="text-left" rowspan="1" colspan="1">IP-TFS</td>
2091+
<td class="text-left" rowspan="1" colspan="1">Full</td>
2092+
<td class="text-left" rowspan="1" colspan="1">Payload starts with the IP-TFS header.</td>
2093+
</tr>
2094+
</tbody>
2095+
</table>
2096+
</div>
2097+
<p id="section-2.8-4">The two packet formats are shown below. <a href="#eesp-full-packet-format" class="auto internal xref">Figure 5</a>
20552098
shows the full packet format used as the default for modes of operation.
20562099
<a href="#eesp-optimized-packet-format" class="auto internal xref">Figure 6</a> illustrates the resulting optimized
20572100
packet format for use with IPv4 or IPv6 Tunnel Mode when the
2058-
'<code>Payload Info Header</code>' is elided.<a href="#section-2.8-1" class="pilcrow"></a></p>
2101+
'<code>Payload Info Header</code>' is elided.<a href="#section-2.8-4" class="pilcrow"></a></p>
20592102
<span id="name-full-eesp-packet-format"></span><div id="eesp-full-packet-format">
20602103
<figure id="figure-5">
2061-
<div class="sourcecode" id="section-2.8-2.1">
2104+
<div class="sourcecode" id="section-2.8-5.1">
20622105
<pre>
20632106
0 1 2 3
20642107
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
@@ -2097,7 +2140,7 @@ <h3 id="name-full-and-optimized-packet-f">
20972140
</div>
20982141
<span id="name-optimized-eesp-packet-forma"></span><div id="eesp-optimized-packet-format">
20992142
<figure id="figure-6">
2100-
<div class="sourcecode" id="section-2.8-3.1">
2143+
<div class="sourcecode" id="section-2.8-6.1">
21012144
<pre>
21022145

21032146
0 1 2 3
@@ -2137,23 +2180,23 @@ <h3 id="name-full-and-optimized-packet-f">
21372180
<a href="#name-optimized-eesp-packet-forma" class="selfRef">Optimized EESP packet format</a>
21382181
</figcaption></figure>
21392182
</div>
2140-
<p id="section-2.8-4">[*] If included, cryptographic synchronization data, e.g., an
2183+
<p id="section-2.8-7">[*] If included, cryptographic synchronization data, e.g., an
21412184
'<code>Initialization Vector</code>' (IV), usually is not encrypted per se, although
21422185
it often is referred to as being part of the cipher-text. Unlike ESP,
2143-
the IV is not considered to be a part of the payload data in EESP.<a href="#section-2.8-4" class="pilcrow"></a></p>
2144-
<p id="section-2.8-5">The explicit IV shown in <a href="#eesp-packet-separate-algos" class="auto internal xref">Table 1</a> depends on the
2186+
the IV is not considered to be a part of the payload data in EESP.<a href="#section-2.8-7" class="pilcrow"></a></p>
2187+
<p id="section-2.8-8">The explicit IV shown in <a href="#eesp-packet-separate-algos" class="auto internal xref">Table 2</a> depends on the
21452188
used algorithm and may be omitted. Because algorithms,
21462189
modes and options are fixed when an SA is established, the detailed
21472190
format of EESP packets for a given SA (including the '<code>Payload Data</code>'
2148-
substructure) is fixed for all traffic on the SA.<a href="#section-2.8-5" class="pilcrow"></a></p>
2149-
<p id="section-2.8-6">The table below refers to the fields in the preceding figures and
2191+
substructure) is fixed for all traffic on the SA.<a href="#section-2.8-8" class="pilcrow"></a></p>
2192+
<p id="section-2.8-9">The table below refers to the fields in the preceding figures and
21502193
illustrate how several categories of algorithmic options, each with a
21512194
different processing model, affect the fields noted above. The
2152-
processing details are described in later sections.<a href="#section-2.8-6" class="pilcrow"></a></p>
2195+
processing details are described in later sections.<a href="#section-2.8-9" class="pilcrow"></a></p>
21532196
<span id="name-high-level-layout-for-field"></span><div id="eesp-packet-separate-algos">
2154-
<table class="center" id="table-1">
2197+
<table class="center" id="table-2">
21552198
<caption>
2156-
<a href="#table-1" class="selfRef">Table 1</a>:
2199+
<a href="#table-2" class="selfRef">Table 2</a>:
21572200
<a href="#name-high-level-layout-for-field" class="selfRef">High level layout for fields of an EESP packet</a>
21582201
</caption>
21592202
<thead>
@@ -2235,29 +2278,29 @@ <h3 id="name-full-and-optimized-packet-f">
22352278
</table>
22362279
</div>
22372280
<ul class="compact">
2238-
<li class="compact" id="section-2.8-8.1">
2239-
<p id="section-2.8-8.1.1">[1] M = mandatory; O = optional<a href="#section-2.8-8.1.1" class="pilcrow"></a></p>
2281+
<li class="compact" id="section-2.8-11.1">
2282+
<p id="section-2.8-11.1.1">[1] M = mandatory; O = optional<a href="#section-2.8-11.1.1" class="pilcrow"></a></p>
22402283
</li>
2241-
<li class="compact" id="section-2.8-8.2">
2242-
<p id="section-2.8-8.2.1">[2] If tunnel mode -&gt; IP datagram. If BEET mode -&gt; IP datagram. If
2284+
<li class="compact" id="section-2.8-11.2">
2285+
<p id="section-2.8-11.2.1">[2] If tunnel mode -&gt; IP datagram. If BEET mode -&gt; IP datagram. If
22432286
transport mode -&gt; next header and data. If IP-TFS, IP-TFS header
2244-
and payload.<a href="#section-2.8-8.2.1" class="pilcrow"></a></p>
2287+
and payload.<a href="#section-2.8-11.2.1" class="pilcrow"></a></p>
22452288
</li>
2246-
<li class="compact" id="section-2.8-8.3">
2247-
<p id="section-2.8-8.3.1">[3] Ciphertext if encryption has been selected.<a href="#section-2.8-8.3.1" class="pilcrow"></a></p>
2289+
<li class="compact" id="section-2.8-11.3">
2290+
<p id="section-2.8-11.3.1">[3] Ciphertext if encryption has been selected.<a href="#section-2.8-11.3.1" class="pilcrow"></a></p>
22482291
</li>
2249-
<li class="compact" id="section-2.8-8.4">
2250-
<p id="section-2.8-8.4.1">[4] Not present in the Optimized Packet Format, otherwise mandatory.<a href="#section-2.8-8.4.1" class="pilcrow"></a></p>
2292+
<li class="compact" id="section-2.8-11.4">
2293+
<p id="section-2.8-11.4.1">[4] Not present in the Optimized Packet Format, otherwise mandatory.<a href="#section-2.8-11.4.1" class="pilcrow"></a></p>
22512294
</li>
22522295
</ul>
2253-
<p id="section-2.8-9">In the table "optional" means that the field is omitted if the option is not
2296+
<p id="section-2.8-12">In the table "optional" means that the field is omitted if the option is not
22542297
selected, i.e., it is not present in the packet as transmitted
22552298
or as formatted for computation of an ICV. Whether or not an option
22562299
is selected depends on the used mode (Payload Info Header),
22572300
or is determined as part of Security Association (SA)
22582301
establishment. Thus, the format of EESP packets for a given SA is
22592302
fixed for the duration of the SA. In contrast, "mandatory" fields
2260-
are always present in the EESP packet format for all SAs.<a href="#section-2.8-9" class="pilcrow"></a></p>
2303+
are always present in the EESP packet format for all SAs.<a href="#section-2.8-12" class="pilcrow"></a></p>
22612304
</section>
22622305
</div>
22632306
<div id="sec-session-id-as-sub-sa-id">

‎draft-ietf-ipsecme-eesp-latest.txt‎

Lines changed: 34 additions & 34 deletions
Original file line numberDiff line numberDiff line change
@@ -689,39 +689,39 @@ Internet-Draft EESP February 2026
689689
for a next header field. Additionally, IPv4 and IPv6 also have a
690690
field describing the overall size of the inner packet, so a pad
691691
length field is also not needed as it can be derived. When transport
692-
mode, beet mode or IPTFS is used, it is not possible to derive these
692+
mode, BEET mode, or IP-TFS is used, it is not possible to derive this
693693
information, so the full packet format, including the 'Payload Info
694-
Header' MUST be used. The two packet formats are shown below.
695-
Figure 5 shows the full packet format used as the default for modes
696-
of operation. Figure 6 illustrates the resulting optimized packet
697-
format for use with IPv4 or IPv6 Tunnel Mode when the 'Payload Info
698-
Header' is elided.
699-
700-
701-
702-
703-
704-
705-
706-
707-
708-
709-
710-
711-
712-
713-
714-
715-
716-
717-
718-
719-
720-
721-
722-
723-
724-
694+
Header' MUST be used.
695+
696+
The selection of the packet format is determined by the encapsulation
697+
mode and by whether the values carried in the 'Payload Info Header'
698+
can be inferred from the decrypted payload. Table Table 1 summarizes
699+
which modes use which format. In this table, "Full" means that the
700+
'Payload Info Header' is present, and "Optimized" means that the
701+
'Payload Info Header' is absent (elided).
702+
703+
+=======================+===============+========================+
704+
| Mode | Packet format | Notes |
705+
+=======================+===============+========================+
706+
| IPv4/IPv6 tunnel mode | Optimized | Inner starts with |
707+
| | | IPv4/IPv6 header. |
708+
+-----------------------+---------------+------------------------+
709+
| Transport mode | Full | Next Header/Pad Length |
710+
| | | cannot be inferred. |
711+
+-----------------------+---------------+------------------------+
712+
| BEET mode | Full | Next Header/Pad Length |
713+
| | | cannot be inferred. |
714+
+-----------------------+---------------+------------------------+
715+
| IP-TFS | Full | Payload starts with |
716+
| | | the IP-TFS header. |
717+
+-----------------------+---------------+------------------------+
718+
719+
Table 1: EESP packet format selection by mode
720+
721+
The two packet formats are shown below. Figure 5 shows the full
722+
packet format used as the default for modes of operation. Figure 6
723+
illustrates the resulting optimized packet format for use with IPv4
724+
or IPv6 Tunnel Mode when the 'Payload Info Header' is elided.
725725

726726

727727

@@ -826,7 +826,7 @@ Internet-Draft EESP February 2026
826826
Unlike ESP, the IV is not considered to be a part of the payload data
827827
in EESP.
828828

829-
The explicit IV shown in Table 1 depends on the used algorithm and
829+
The explicit IV shown in Table 2 depends on the used algorithm and
830830
may be omitted. Because algorithms, modes and options are fixed when
831831
an SA is established, the detailed format of EESP packets for a given
832832
SA (including the 'Payload Data' substructure) is fixed for all
@@ -872,7 +872,7 @@ Internet-Draft EESP February 2026
872872
| ICV | variable | M | | | plain |
873873
+-------------+------------+-----------+---------+--------+--------+
874874

875-
Table 1: High level layout for fields of an EESP packet
875+
Table 2: High level layout for fields of an EESP packet
876876

877877
* [1] M = mandatory; O = optional
878878
* [2] If tunnel mode -> IP datagram. If BEET mode -> IP datagram.

0 commit comments

Comments
 (0)