|(any options)| TCP | Data |
----------------------------
AFTER APPLYING ESP
-------------------------------------------------
IPv4 |orig IP hdr | ESP | | | ESP | ESP|
|(any options)| Hdr | TCP | Data | Trailer | ICV|
-------------------------------------------------
|<---- encryption ---->|
|<-------- integrity ------->|
In the IPv6 context, ESP is viewed as an end-to-end payload, and thus
should appear after hop-by-hop, routing, and fragmentation extension
headers. Destination options extension header(s) could appear
before, after, or both before and after the ESP header depending on
the semantics desired. However, because ESP protects only fields
after the ESP header, it generally will be desirable to place the
destination options header(s) after the ESP header. The following
diagram illustrates ESP transport mode positioning for a typical IPv6
packet.
BEFORE APPLYING ESP
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
AFTER APPLYING ESP
---------------------------------------------------------
IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP|
|IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV|
---------------------------------------------------------
|<--- encryption ---->|
|<------ integrity ------>|
* = if present, could be before ESP, after ESP, or both
Note that in transport mode, for "bump-in-the-stack" or "bump-in-
the-wire" implementations, as defined in the Security Architecture
document, inbound and outbound IP fragments may require an IPsec
implementation to perform extra IP reassembly/fragmentation in order
to both conform to this specification and provide transparent IPsec
support. Special care is required to perform such operations within
these implementations when multiple interfaces are in use.
3.1.2. Tunnel Mode Processing
In tunnel mode, the "inner" IP header carries the ultimate (IP)
source and destination addresses, while an "outer" IP header contains
the addresses of the IPsec "peers", e.g., addresses of security
gateways. Mixed inner and outer IP versions are allowed, i.e., IPv6
over IPv4 and IPv4 over IPv6. In tunnel mode, ESP protects the
entire inner IP packet, including the entire inner IP header. The
position of ESP in tunnel mode, relative to the outer IP header, is
the same as for ESP in transport mode. The following diagram
illustrates ESP tunnel mode positioning for typical IPv4 and IPv6
packets.
BEFORE APPLYING ESP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING ESP
-----------------------------------------------------------
IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP|
|(any options)| ESP | (any options) |TCP|Data|Trailer| ICV|
-----------------------------------------------------------
|<--------- encryption --------->|
|<------------- integrity ------------>|
BEFORE APPLYING ESP
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
AFTER APPLYING ESP
------------------------------------------------------------
IPv6 | new* |new ext | | orig*|orig ext | | | ESP | ESP|
|IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV|
------------------------------------------------------------
|<--------- encryption ---------->|
|<------------ integrity ------------>|
* = if present, construction of outer IP hdr/extensions and
modification of inner IP hdr/extensions is discussed in
the Security Architecture document.
3.2. Algorithms
The mandatory-to-implement algorithms for use with ESP are described
in a separate RFC, to facilitate updating the algorithm requirements
independently from the protocol per se. Additional algorithms,
beyond those mandated for ESP, MAY be supported. Note that although
both confidentiality and integrity are optional, at least one of
these services MUST be selected, hence both algorithms MUST NOT be
simultaneously NULL.
3.2.1. Encryption Algorithms
The encryption algorithm employed to protect an ESP packet is
specified by the SA via which the packet is transmitted/received.
Because IP packets may arrive out of order, and not all packets may
arrive (packet loss), each packet must carry any data required to
allow the receiver to establish cryptographic synchronization for
decryption. This data may be carried explicitly in the payload
field, e.g., as an IV (as described above), or the data may be
derived from the plaintext portions of the (outer IP or ESP) packet
header. (Note that if plaintext header information is used to derive
an IV, that information may become security critical and thus the
protection boundary associated with the encryption process may grow.
For example, if one were to use the ESP Sequence Number to derive an
IV, the Sequence Number generation logic (hardware or software) would
have to be evaluated as part of the encryption algorithm
implementation. In the case of FIPS 140-2 [NIST01], this could
significantly extend the scope of a cryptographic module evaluation.)
Because ESP makes provision for padding of the plaintext, encryption
algorithms employed with ESP may exhibit either block or stream mode
characteristics. Note that because encryption (confidentiality) MAY
be an optional service (e.g., integrity-only ESP), this algorithm MAY
be "NULL" [Ken-Arch].
To allow an ESP implementation to compute the encryption padding
required by a block mode encryption algorithm, and to determine the
MTU impact of the algorithm, the RFC for each encryption algorithm
used with ESP must specify the padding modulus for the algorithm.
3.2.2. Integrity Algorithms
The integrity algorithm employed for the ICV computation is specified
by the SA via which the packet is transmitted/received. As was the
case for encryption algorithms, any integrity algorithm employed with
ESP must make provisions to permit processing of packets that arrive
out of order and to accommodate packet loss. The same admonition
noted above applies to use of any plaintext data to facilitate
receiver synchronization of integrity algorithms. Note that because
the integrity service MAY be optional, this algorithm may be "NULL".
To allow an ESP implementation to compute any implicit integrity
algorithm padding required, the RFC for each algorithm used with ESP
must specify the padding modulus for the algorithm.
3.2.3. Combined Mode Algorithms
If a combined mode algorithm is employed, both confidentiality and
integrity services are provided. As was the case for encryption
algorithms, a combined mode algorithm must make provisions for per-
packet cryptographic synchronization, to permit decryption of packets
that arrive out of order and to accommodate packet loss. The means
by which a combined mode algorithm provides integrity for the
payload, and for the SPI and (Extended) Sequence Number fields, may
vary for different algorithm choices. In order to provide a uniform,
algorithm-independent approach to invocation of combined mode
algorithms, no payload substructure is defined. For example, the SPI
and Sequence Number fields might be replicated within the ciphertext
envelope and an ICV may be appended to the ESP trailer. None of
these details should be observable externally.
To allow an ESP implementation to determine the MTU impact of a
combined mode algorithm, the RFC for each algorithm used with ESP
must specify a (simple) formula that yields encrypted payload size,
as a function of the plaintext payload and sequence number sizes.
3.3. Outbound Packet Processing
In transport mode, the sender encapsulates the next layer protocol
information between the ESP header and the ESP trailer fields, and
retains the specified IP header (and any IP extension headers in the
IPv6 context). In tunnel mode, the outer and inner IP
header/extensions can be interrelated in a variety of ways. The
construction of the outer IP header/extensions during the
encapsulation process is described in the Security Architecture
document.
3.3.1. Security Association Lookup
ESP is applied to an outbound packet only after an IPsec
implementation determines that the packet is associated with an SA
that calls for ESP processing. The process of determining what, if
any, IPsec processing is applied to outbound traffic is described in
the Security Architecture document.
3.3.2. Packet Encryption and Integrity Check Value (ICV) Calculation
In this section, we speak in terms of encryption always being applied
because of the formatting implications. This is done with the
understanding that "no confidentiality" is offered by using the NULL
encryption algorithm (RFC 2410). There are several algorithmic
options.
3.3.2.1. Separate Confidentiality and Integrity Algorithms
If separate confidentiality and integrity algorithms are employed,
the Sender proceeds as follows:
1. Encapsulate (into the ESP Payload field):
- for transport mode -- just the original next layer
protocol information.
- for tunnel mode -- the entire original IP datagram.
2. Add any necessary padding -- Optional TFC padding and
(encryption) Padding
3. Encrypt the result using the key, encryption algorithm,
and algorithm mode specified for the SA and using any
required cryptographic synchronization data.
- If explicit cryptographic synchronization data,
e.g., an IV, is indicated, it is input to the
encryption algorithm per the algorithm specification
and placed in the Payload field.
- If implicit cryptographic synchronization data is
employed, it is constructed and input to the
encryption algorithm as per the algorithm
specification.
- If integrity is selected, encryption is performed
first, before the integrity algorithm is applied, and
the encryption does not encompass the ICV field.
This order of processing facilitates rapid detection
and rejection of replayed or bogus packets by the
receiver, prior to decrypting the packet, hence
potentially reducing the impact of denial of service
(DoS) attacks. It also allows for the possibility of
parallel processing of packets at the receiver, i.e.,
decryption can take place in parallel with integrity
checking. Note that because the ICV is not protected
by encryption, a keyed integrity algorithm must be
employed to compute the ICV.
4. Compute the ICV over the ESP packet minus the ICV field.
Thus, the ICV computation encompasses the SPI, Sequence
Number, Payload Data, Padding (if present), Pad Length, and
Next Header. (Note that the last 4 fields will be in
ciphertext form, because encryption is performed first.) If
the ESN option is enabled for the SA, the high-order 32
bits of the sequence number are appended after the Next
Header field for purposes of this computation, but are not
transmitted.
For some integrity algorithms, the byte string over which the ICV
computation is performed must be a multiple of a block size specified
by the algorithm. If the length of ESP packet (as described above)
does not match the block size requirements for the algorithm,
implicit padding MUST be appended to the end of the ESP packet.
(This padding is added after the Next Header field, or after the
high-order 32 bits of the sequence number, if ESN is selected.) The
block size (and hence the length of the padding) is specified by the
integrity algorithm specification. This padding is not transmitted
with the packet. The document that defines an integrity algorithm
MUST be consulted to determine if implicit padding is required as
described above. If the document does not specify an answer to this
question, then the default is to assume that implicit padding is
required (as needed to match the packet length to the algorithm’s
block size.) If padding bytes are needed but the algorithm does not
specify the padding contents, then the padding octets MUST have a
value of zero.
3.3.2.2. Combined Confidentiality and Integrity Algorithms
If a combined confidentiality/integrity algorithm is employed, the
Sender proceeds as follows:
1. Encapsulate into the ESP Payload Data field:
- for transport mode -- just the original next layer
protocol information.
- for tunnel mode -- the entire original IP datagram.
2. Add any necessary padding -- includes optional TFC padding
and (encryption) Padding.
3. Encrypt and integrity protect the result using the key
and combined mode algorithm specified for the SA and using
any required cryptographic synchronization data.
- If explicit cryptographic synchronization data,
e.g., an IV, is indicated, it is input to the
combined mode algorithm per the algorithm
specification and placed in the Payload field.
- If implicit cryptographic synchronization data is
employed, it is constructed and input to the
encryption algorithm as per the algorithm
specification.
- The Sequence Number (or Extended Sequence Number, as
appropriate) and the SPI are inputs to the
algorithm, as they must be included in the integrity
check computation. The means by which these values
are included in this computation are a function of
the combined mode algorithm employed and thus not
specified in this standard.
- The (explicit) ICV field MAY be a part of the ESP
packet format when a combined mode algorithm is
employed. If one is not used, an analogous field
usually will be a part of the ciphertext payload.
The location of any integrity fields, and the means
by which the Sequence Number and SPI are included in
the integrity computation, MUST be defined in an RFC
that defines the use of the combined mode algorithm
with ESP.
3.3.3. Sequence Number Generation
The sender’s counter is initialized to 0 when an SA is established.
The sender increments the sequence number (or ESN) counter for this
SA and inserts the low-order 32 bits of the value into the Sequence
Number field. Thus, the first packet sent using a given SA will
contain a sequence number of 1.
If anti-replay is enabled (the default), the sender checks to ensure
that the counter has not cycled before inserting the new value in the
Sequence Number field. In other words, the sender MUST NOT send a
packet on an SA if doing so would cause the sequence number to cycle.
An attempt to transmit a packet that would result in sequence number
overflow is an auditable event. The audit log entry for this event
SHOULD include the SPI value, current date/time, Source Address,
Destination Address, and (in IPv6) the cleartext Flow ID.
The sender assumes anti-replay is enabled as a default, unless
otherwise notified by the receiver (see Section 3.4.3). Thus,
typical behavior of an ESP implementation calls for the sender to
establish a new SA when the Sequence Number (or ESN) cycles, or in
anticipation of this value cycling.
If the key used to compute an ICV is manually distributed, a
compliant implementation SHOULD NOT provide anti-replay service. If
a user chooses to employ anti-replay in conjunction with SAs that are
manually keyed, the sequence number counter at the sender MUST be
correctly maintained across local reboots, etc., until the key is
replaced. (See Section 5.)
If anti-replay is disabled (as noted above), the sender does not need
to monitor or reset the counter. However, the sender still
increments the counter and when it reaches the maximum value, the
counter rolls over back to zero. (This behavior is recommended for
multi-sender, multicast SAs, unless anti-replay mechanisms outside
the scope of this standard are negotiated between the sender and
receiver.)
If ESN (see Appendix) is selected, only the low-order 32 bits of the
sequence number are transmitted in the Sequence Number field,
although both sender and receiver maintain full 64-bit ESN counters.
The high order 32 bits are included in the integrity check in an
algorithm/mode-specific fashion, e.g., the high-order 32 bits may be
appended after the Next Header field when a separate integrity
algorithm is employed.
Note: If a receiver chooses to not enable anti-replay for an SA, then
the receiver SHOULD NOT negotiate ESN in an SA management protocol.
Use of ESN creates a need for the receiver to manage the anti-replay
window (in order to determine the correct value for the high-order
bits of the ESN, which are employed in the ICV computation), which is
generally contrary to the notion of disabling anti-replay for an SA.
3.3.4. Fragmentation
If necessary, fragmentation is performed after ESP processing within
an IPsec implementation. Thus, transport mode ESP is applied only to
whole IP datagrams (not to IP fragments). An IP packet to which ESP
has been applied may itself be fragmented by routers en route, and
such fragments must be reassembled prior to ESP processing at a
receiver. In tunnel mode, ESP is applied to an IP packet, which may
be a fragment of an IP datagram. For example, a security gateway or
a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation (as
defined in the Security Architecture document) may apply tunnel mode
ESP to such fragments.
NOTE: For transport mode -- As mentioned at the end of Section 3.1.1,
bump-in-the-stack and bump-in-the-wire implementations may have to
first reassemble a packet fragmented by the local IP layer, then
apply IPsec, and then fragment the resulting packet.
NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire
implementations, it will be necessary to examine all the extension
headers to determine if there is a fragmentation header and hence
that the packet needs reassembling prior to IPsec processing.
Fragmentation, whether performed by an IPsec implementation or by
routers along the path between IPsec peers, significantly reduces
performance. Moreover, the requirement for an ESP receiver to accept
fragments for reassembly creates denial of service vulnerabilities.
Thus, an ESP implementation MAY choose to not support fragmentation
and may mark transmitted packets with the DF bit, to facilitate Path
MTU (PMTU) discovery. In any case, an ESP implementation MUST
support generation of ICMP PMTU messages (or equivalent internal
signaling for native host implementations) to minimize the likelihood
of fragmentation. Details of the support required for MTU management
are contained in the Security Architecture document.
3.4. Inbound Packet Processing
3.4.1. Reassembly
If required, reassembly is performed prior to ESP processing. If a
packet offered to ESP for processing appears to be an IP fragment,
i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set,
the receiver MUST discard the packet; this is an auditable event.
The audit log entry for this event SHOULD include the SPI value,
date/time received, Source Address, Destination Address, Sequence
Number, and (in IPv6) the Flow ID.
NOTE: For packet reassembly, the current IPv4 spec does NOT require
either the zeroing of the OFFSET field or the clearing of the MORE
FRAGMENTS flag. In order for a reassembled packet to be processed by
IPsec (as opposed to discarded as an apparent fragment), the IP code
must do these two things after it reassembles a packet.
3.4.2. Security Association Lookup
Upon receipt of a packet containing an ESP Header, the receiver
determines the appropriate (unidirectional) SA via lookup in the SAD.
For a unicast SA, this determination is based on the SPI or the SPI
plus protocol field, as described in Section 2.1. If an
implementation supports multicast traffic, the destination address is
also employed in the lookup (in addition to the SPI), and the sender
address also may be employed, as described in Section 2.1. (This
process is described in more detail in the Security Architecture