RFC 4301
Security Architecture for the Internet Protocol
Pages: 101
Proposed Standard
→ Errata
Obsoletes: 2401
Updates: 3168
Updated by: 6040 7619
Proposed Standard
→ Errata
Obsoletes: 2401
Updates: 3168
Updated by: 6040 7619
Part 3 of 4 – Pages 50 to 75
5. IP Traffic Processing
As mentioned in Section 4.4.1, "The Security Policy Database (SPD)", the SPD (or associated caches) MUST be consulted during the processing of all traffic that crosses the IPsec protection boundary, including IPsec management traffic. If no policy is found in the SPD that matches a packet (for either inbound or outbound traffic), the packet MUST be discarded. To simplify processing, and to allow for very fast SA lookups (for SG/BITS/BITW), this document introduces the
notion of an SPD cache for all outbound traffic (SPD-O plus SPD-S), and a cache for inbound, non-IPsec-protected traffic (SPD-I). (As mentioned earlier, the SAD acts as a cache for checking the selectors of inbound IPsec-protected traffic arriving on SAs.) There is nominally one cache per SPD. For the purposes of this specification, it is assumed that each cached entry will map to exactly one SA. Note, however, exceptions arise when one uses multiple SAs to carry traffic of different priorities (e.g., as indicated by distinct DSCP values) but the same selectors. Note also, that there are a couple of situations in which the SAD can have entries for SAs that do not have corresponding entries in the SPD. Since this document does not mandate that the SAD be selectively cleared when the SPD is changed, SAD entries can remain when the SPD entries that created them are changed or deleted. Also, if a manually keyed SA is created, there could be an SAD entry for this SA that does not correspond to any SPD entry. Since SPD entries may overlap, one cannot safely cache these entries in general. Simple caching might result in a match against a cache entry, whereas an ordered search of the SPD would have resulted in a match against a different entry. But, if the SPD entries are first decorrelated, then the resulting entries can safely be cached. Each cached entry will indicate that matching traffic should be bypassed or discarded, appropriately. (Note: The original SPD entry might result in multiple SAs, e.g., because of PFP.) Unless otherwise noted, all references below to the "SPD" or "SPD cache" or "cache" are to a decorrelated SPD (SPD-I, SPD-O, SPD-S) or the SPD cache containing entries from the decorrelated SPD. Note: In a host IPsec implementation based on sockets, the SPD will be consulted whenever a new socket is created to determine what, if any, IPsec processing will be applied to the traffic that will flow on that socket. This provides an implicit caching mechanism, and the portions of the preceding discussion that address caching can be ignored in such implementations. Note: It is assumed that one starts with a correlated SPD because that is how users and administrators are accustomed to managing these sorts of access control lists or firewall filter rules. Then the decorrelation algorithm is applied to build a list of cache-able SPD entries. The decorrelation is invisible at the management interface. For inbound IPsec traffic, the SAD entry selected by the SPI serves as the cache for the selectors to be matched against arriving IPsec packets, after AH or ESP processing has been performed.
5.1. Outbound IP Traffic Processing (protected-to-unprotected)
First consider the path for traffic entering the implementation via a protected interface and exiting via an unprotected interface. Unprotected Interface ^ | (nested SAs) +----------+ -------------------|Forwarding|<-----+ | +----------+ | | ^ | | | BYPASS | V +-----+ | +-------+ | SPD | +--------+ ...| SPD-I |.................|Cache|.....|PROCESS |...IPsec | (*) | | (*) |---->|(AH/ESP)| boundary +-------+ +-----+ +--------+ | +-------+ / ^ | |DISCARD| <--/ | | +-------+ | | | | +-------------+ |---------------->|SPD Selection| +-------------+ ^ | +------+ | -->| ICMP | | / +------+ |/ | | Protected Interface Figure 2. Processing Model for Outbound Traffic (*) = The SPD caches are shown here. If there is a cache miss, then the SPD is checked. There is no requirement that an implementation buffer the packet if there is a cache miss.
IPsec MUST perform the following steps when processing outbound
packets:
1. When a packet arrives from the subscriber (protected) interface,
invoke the SPD selection function to obtain the SPD-ID needed to
choose the appropriate SPD. (If the implementation uses only one
SPD, this step is a no-op.)
2. Match the packet headers against the cache for the SPD specified
by the SPD-ID from step 1. Note that this cache contains entries
from SPD-O and SPD-S.
3a. If there is a match, then process the packet as specified by the
matching cache entry, i.e., BYPASS, DISCARD, or PROTECT using AH
or ESP. If IPsec processing is applied, there is a link from the
SPD cache entry to the relevant SAD entry (specifying the mode,
cryptographic algorithms, keys, SPI, PMTU, etc.). IPsec
processing is as previously defined, for tunnel or transport
modes and for AH or ESP, as specified in their respective RFCs
[Ken05b, Ken05a]. Note that the SA PMTU value, plus the value of
the stateful fragment checking flag (and the DF bit in the IP
header of the outbound packet) determine whether the packet can
(must) be fragmented prior to or after IPsec processing, or if it
must be discarded and an ICMP PMTU message is sent.
3b. If no match is found in the cache, search the SPD (SPD-S and
SPD-O parts) specified by SPD-ID. If the SPD entry calls for
BYPASS or DISCARD, create one or more new outbound SPD cache
entries and if BYPASS, create one or more new inbound SPD cache
entries. (More than one cache entry may be created since a
decorrelated SPD entry may be linked to other such entries that
were created as a side effect of the decorrelation process.) If
the SPD entry calls for PROTECT, i.e., creation of an SA, the key
management mechanism (e.g., IKEv2) is invoked to create the SA.
If SA creation succeeds, a new outbound (SPD-S) cache entry is
created, along with outbound and inbound SAD entries, otherwise
the packet is discarded. (A packet that triggers an SPD lookup
MAY be discarded by the implementation, or it MAY be processed
against the newly created cache entry, if one is created.) Since
SAs are created in pairs, an SAD entry for the corresponding
inbound SA also is created, and it contains the selector values
derived from the SPD entry (and packet, if any PFP flags were
"true") used to create the inbound SA, for use in checking
inbound traffic delivered via the SA.
4. The packet is passed to the outbound forwarding function
(operating outside of the IPsec implementation), to select the
interface to which the packet will be directed. This function
may cause the packet to be passed back across the IPsec boundary,
for additional IPsec processing, e.g., in support of nested SAs.
If so, there MUST be an entry in SPD-I database that permits
inbound bypassing of the packet, otherwise the packet will be
discarded. If necessary, i.e., if there is more than one SPD-I,
the traffic being looped back MAY be tagged as coming from this
internal interface. This would allow the use of a different
SPD-I for "real" external traffic vs. looped traffic, if needed.
Note: With the exception of IPv4 and IPv6 transport mode, an SG,
BITS, or BITW implementation MAY fragment packets before applying
IPsec. (This applies only to IPv4. For IPv6 packets, only the
originator is allowed to fragment them.) The device SHOULD have a
configuration setting to disable this. The resulting fragments are
evaluated against the SPD in the normal manner. Thus, fragments not
containing port numbers (or ICMP message type and code, or Mobility
Header type) will only match rules having port (or ICMP message type
and code, or MH type) selectors of OPAQUE or ANY. (See Section 7 for
more details.)
Note: With regard to determining and enforcing the PMTU of an SA, the
IPsec system MUST follow the steps described in Section 8.2.
5.1.1. Handling an Outbound Packet That Must Be Discarded
If an IPsec system receives an outbound packet that it finds it must
discard, it SHOULD be capable of generating and sending an ICMP
message to indicate to the sender of the outbound packet that the
packet was discarded. The type and code of the ICMP message will
depend on the reason for discarding the packet, as specified below.
The reason SHOULD be recorded in the audit log. The audit log entry
for this event SHOULD include the reason, current date/time, and the
selector values from the packet.
a. The selectors of the packet matched an SPD entry requiring the
packet to be discarded.
IPv4 Type = 3 (destination unreachable) Code = 13
(Communication Administratively Prohibited)
IPv6 Type = 1 (destination unreachable) Code = 1
(Communication with destination administratively
prohibited)
b1. The IPsec system successfully reached the remote peer but was
unable to negotiate the SA required by the SPD entry matching the
packet because, for example, the remote peer is administratively
prohibited from communicating with the initiator, the initiating
peer was unable to authenticate itself to the remote peer, the
remote peer was unable to authenticate itself to the initiating
peer, or the SPD at the remote peer did not have a suitable
entry.
IPv4 Type = 3 (destination unreachable) Code = 13
(Communication Administratively Prohibited)
IPv6 Type = 1 (destination unreachable) Code = 1
(Communication with destination administratively
prohibited)
b2. The IPsec system was unable to set up the SA required by the SPD
entry matching the packet because the IPsec peer at the other end
of the exchange could not be contacted.
IPv4 Type = 3 (destination unreachable) Code = 1 (host
unreachable)
IPv6 Type = 1 (destination unreachable) Code = 3 (address
unreachable)
Note that an attacker behind a security gateway could send packets
with a spoofed source address, W.X.Y.Z, to an IPsec entity causing it
to send ICMP messages to W.X.Y.Z. This creates an opportunity for a
denial of service (DoS) attack among hosts behind a security gateway.
To address this, a security gateway SHOULD include a management
control to allow an administrator to configure an IPsec
implementation to send or not send the ICMP messages under these
circumstances, and if this facility is selected, to rate limit the
transmission of such ICMP responses.
5.1.2. Header Construction for Tunnel Mode
This section describes the handling of the inner and outer IP
headers, extension headers, and options for AH and ESP tunnels, with
regard to outbound traffic processing. This includes how to
construct the encapsulating (outer) IP header, how to process fields
in the inner IP header, and what other actions should be taken for
outbound, tunnel mode traffic. The general processing described here
is modeled after RFC 2003, "IP Encapsulation within IP" [Per96]:
o The outer IP header Source Address and Destination Address
identify the "endpoints" of the tunnel (the encapsulator and
decapsulator). The inner IP header Source Address and Destination
Addresses identify the original sender and recipient of the
datagram (from the perspective of this tunnel), respectively.
(See footnote 3 after the table in 5.1.2.1 for more details on the
encapsulating source IP address.)
o The inner IP header is not changed except as noted below for TTL
(or Hop Limit) and the DS/ECN Fields. The inner IP header
otherwise remains unchanged during its delivery to the tunnel exit
point.
o No change to IP options or extension headers in the inner header
occurs during delivery of the encapsulated datagram through the
tunnel.
Note: IPsec tunnel mode is different from IP-in-IP tunneling (RFC
2003 [Per96]) in several ways:
o IPsec offers certain controls to a security administrator to
manage covert channels (which would not normally be a concern for
tunneling) and to ensure that the receiver examines the right
portions of the received packet with respect to application of
access controls. An IPsec implementation MAY be configurable with
regard to how it processes the outer DS field for tunnel mode for
transmitted packets. For outbound traffic, one configuration
setting for the outer DS field will operate as described in the
following sections on IPv4 and IPv6 header processing for IPsec
tunnels. Another will allow the outer DS field to be mapped to a
fixed value, which MAY be configured on a per-SA basis. (The value
might really be fixed for all traffic outbound from a device, but
per-SA granularity allows that as well.) This configuration option
allows a local administrator to decide whether the covert channel
provided by copying these bits outweighs the benefits of copying.
o IPsec describes how to handle ECN or DS and provides the ability
to control propagation of changes in these fields between
unprotected and protected domains. In general, propagation from a
protected to an unprotected domain is a covert channel and thus
controls are provided to manage the bandwidth of this channel.
Propagation of ECN values in the other direction are controlled so
that only legitimate ECN changes (indicating occurrence of
congestion between the tunnel endpoints) are propagated. By
default, DS propagation from an unprotected domain to a protected
domain is not permitted. However, if the sender and receiver do
not share the same DS code space, and the receiver has no way of
learning how to map between the two spaces, then it may be
appropriate to deviate from the default. Specifically, an IPsec
implementation MAY be configurable in terms of how it processes
the outer DS field for tunnel mode for received packets. It may
be configured to either discard the outer DS value (the default)
OR to overwrite the inner DS field with the outer DS field. If
offered, the discard vs. overwrite behavior MAY be configured on a
per-SA basis. This configuration option allows a local
administrator to decide whether the vulnerabilities created by
copying these bits outweigh the benefits of copying. See
[RFC2983] for further information on when each of these behaviors
may be useful, and also for the possible need for diffserv traffic
conditioning prior or subsequent to IPsec processing (including
tunnel decapsulation).
o IPsec allows the IP version of the encapsulating header to be
different from that of the inner header.
The tables in the following sub-sections show the handling for the
different header/option fields ("constructed" means that the value in
the outer field is constructed independently of the value in the
inner).
5.1.2.1. IPv4: Header Construction for Tunnel Mode
<-- How Outer Hdr Relates to Inner Hdr -->
Outer Hdr at Inner Hdr at
IPv4 Encapsulator Decapsulator
Header fields: -------------------- ------------
version 4 (1) no change
header length constructed no change
DS Field copied from inner hdr (5) no change
ECN Field copied from inner hdr constructed (6)
total length constructed no change
ID constructed no change
flags (DF,MF) constructed, DF (4) no change
fragment offset constructed no change
TTL constructed (2) decrement (2)
protocol AH, ESP no change
checksum constructed constructed (2)(6)
src address constructed (3) no change
dest address constructed (3) no change
Options never copied no change
Notes:
(1) The IP version in the encapsulating header can be different
from the value in the inner header.
(2) The TTL in the inner header is decremented by the encapsulator
prior to forwarding and by the decapsulator if it forwards the
packet. (The IPv4 checksum changes when the TTL changes.)
Note: Decrementing the TTL value is a normal part of
forwarding a packet. Thus, a packet originating from the same
node as the encapsulator does not have its TTL decremented,
since the sending node is originating the packet rather than
forwarding it. This applies to BITS and native IPsec
implementations in hosts and routers. However, the IPsec
processing model includes an external forwarding capability.
TTL processing can be used to prevent looping of packets,
e.g., due to configuration errors, within the context of this
processing model.
(3) Local and Remote addresses depend on the SA, which is used to
determine the Remote address, which in turn determines which
Local address (net interface) is used to forward the packet.
Note: For multicast traffic, the destination address, or
source and destination addresses, may be required for
demuxing. In that case, it is important to ensure consistency
over the lifetime of the SA by ensuring that the source
address that appears in the encapsulating tunnel header is the
same as the one that was negotiated during the SA
establishment process. There is an exception to this general
rule, i.e., a mobile IPsec implementation will update its
source address as it moves.
(4) Configuration determines whether to copy from the inner header
(IPv4 only), clear, or set the DF.
(5) If the packet will immediately enter a domain for which the
DSCP value in the outer header is not appropriate, that value
MUST be mapped to an appropriate value for the domain
[NiBlBaBL98]. See RFC 2475 [BBCDWW98] for further
information.
(6) If the ECN field in the inner header is set to ECT(0) or
ECT(1), where ECT is ECN-Capable Transport (ECT), and if the
ECN field in the outer header is set to Congestion Experienced
(CE), then set the ECN field in the inner header to CE;
otherwise, make no change to the ECN field in the inner
header. (The IPv4 checksum changes when the ECN changes.)
Note: IPsec does not copy the options from the inner header into the
outer header, nor does IPsec construct the options in the outer
header. However, post-IPsec code MAY insert/construct options for
the outer header.
5.1.2.2. IPv6: Header Construction for Tunnel Mode
<-- How Outer Hdr Relates Inner Hdr ---> Outer Hdr at Inner Hdr at IPv6 Encapsulator Decapsulator Header fields: -------------------- ------------ version 6 (1) no change DS Field copied from inner hdr (5) no change (9) ECN Field copied from inner hdr constructed (6) flow label copied or configured (8) no change payload length constructed no change next header AH,ESP,routing hdr no change hop limit constructed (2) decrement (2) src address constructed (3) no change dest address constructed (3) no change Extension headers never copied (7) no change Notes: (1) - (6) See Section 5.1.2.1. (7) IPsec does not copy the extension headers from the inner packet into outer headers, nor does IPsec construct extension headers in the outer header. However, post-IPsec code MAY insert/construct extension headers for the outer header. (8) See [RaCoCaDe04]. Copying is acceptable only for end systems, not SGs. If an SG copied flow labels from the inner header to the outer header, collisions might result. (9) An implementation MAY choose to provide a facility to pass the DS value from the outer header to the inner header, on a per- SA basis, for received tunnel mode packets. The motivation for providing this feature is to accommodate situations in which the DS code space at the receiver is different from that of the sender and the receiver has no way of knowing how to translate from the sender's space. There is a danger in copying this value from the outer header to the inner header, since it enables an attacker to modify the outer DSCP value in a fashion that may adversely affect other traffic at the receiver. Hence the default behavior for IPsec implementations is NOT to permit such copying.5.2. Processing Inbound IP Traffic (unprotected-to-protected)
Inbound processing is somewhat different from outbound processing, because of the use of SPIs to map IPsec-protected traffic to SAs. The inbound SPD cache (SPD-I) is applied only to bypassed or
discarded traffic. If an arriving packet appears to be an IPsec fragment from an unprotected interface, reassembly is performed prior to IPsec processing. The intent for any SPD cache is that a packet that fails to match any entry is then referred to the corresponding SPD. Every SPD SHOULD have a nominal, final entry that catches anything that is otherwise unmatched, and discards it. This ensures that non-IPsec-protected traffic that arrives and does not match any SPD-I entry will be discarded. Unprotected Interface | V +-----+ IPsec protected ------------------->|Demux|-------------------+ | +-----+ | | | | | Not IPsec | | | | | | V | | +-------+ +---------+ | | |DISCARD|<---|SPD-I (*)| | | +-------+ +---------+ | | | | | |-----+ | | | | | | | V | | | +------+ | | | | ICMP | | | | +------+ | | | V +---------+ | +-----------+ ....|SPD-O (*)|............|...................|PROCESS(**)|...IPsec +---------+ | | (AH/ESP) | Boundary ^ | +-----------+ | | +---+ | | BYPASS | +-->|IKE| | | | | +---+ | | V | V | +----------+ +---------+ +----+ |--------<------|Forwarding|<---------|SAD Check|-->|ICMP| nested SAs +----------+ | (***) | +----+ | +---------+ V Protected Interface Figure 3. Processing Model for Inbound Traffic
(*) = The caches are shown here. If there is
a cache miss, then the SPD is checked.
There is no requirement that an
implementation buffer the packet if
there is a cache miss.
(**) = This processing includes using the
packet's SPI, etc., to look up the SA
in the SAD, which forms a cache of the
SPD for inbound packets (except for
cases noted in Sections 4.4.2 and 5).
See step 3a below.
(***) = This SAD check refers to step 4 below.
Prior to performing AH or ESP processing, any IP fragments that
arrive via the unprotected interface are reassembled (by IP). Each
inbound IP datagram to which IPsec processing will be applied is
identified by the appearance of the AH or ESP values in the IP Next
Protocol field (or of AH or ESP as a next layer protocol in the IPv6
context).
IPsec MUST perform the following steps:
1. When a packet arrives, it may be tagged with the ID of the
interface (physical or virtual) via which it arrived, if
necessary, to support multiple SPDs and associated SPD-I caches.
(The interface ID is mapped to a corresponding SPD-ID.)
2. The packet is examined and demuxed into one of two categories:
- If the packet appears to be IPsec protected and it is addressed
to this device, an attempt is made to map it to an active SA
via the SAD. Note that the device may have multiple IP
addresses that may be used in the SAD lookup, e.g., in the case
of protocols such as SCTP.
- Traffic not addressed to this device, or addressed to this
device and not AH or ESP, is directed to SPD-I lookup. (This
implies that IKE traffic MUST have an explicit BYPASS entry in
the SPD.) If multiple SPDs are employed, the tag assigned to
the packet in step 1 is used to select the appropriate SPD-I
(and cache) to search. SPD-I lookup determines whether the
action is DISCARD or BYPASS.
3a. If the packet is addressed to the IPsec device and AH or ESP is
specified as the protocol, the packet is looked up in the SAD.
For unicast traffic, use only the SPI (or SPI plus protocol).
For multicast traffic, use the SPI plus the destination or SPI
plus destination and source addresses, as specified in Section
4.1. In either case (unicast or multicast), if there is no match,
discard the traffic. This is an auditable event. The audit log
entry for this event SHOULD include the current date/time, SPI,
source and destination of the packet, IPsec protocol, and any
other selector values of the packet that are available. If the
packet is found in the SAD, process it accordingly (see step 4).
3b. If the packet is not addressed to the device or is addressed to
this device and is not AH or ESP, look up the packet header in
the (appropriate) SPD-I cache. If there is a match and the
packet is to be discarded or bypassed, do so. If there is no
cache match, look up the packet in the corresponding SPD-I and
create a cache entry as appropriate. (No SAs are created in
response to receipt of a packet that requires IPsec protection;
only BYPASS or DISCARD cache entries can be created this way.) If
there is no match, discard the traffic. This is an auditable
event. The audit log entry for this event SHOULD include the
current date/time, SPI if available, IPsec protocol if available,
source and destination of the packet, and any other selector
values of the packet that are available.
3c. Processing of ICMP messages is assumed to take place on the
unprotected side of the IPsec boundary. Unprotected ICMP
messages are examined and local policy is applied to determine
whether to accept or reject these messages and, if accepted, what
action to take as a result. For example, if an ICMP unreachable
message is received, the implementation must decide whether to
act on it, reject it, or act on it with constraints. (See Section
6.)
4. Apply AH or ESP processing as specified, using the SAD entry
selected in step 3a above. Then match the packet against the
inbound selectors identified by the SAD entry to verify that the
received packet is appropriate for the SA via which it was
received.
5. If an IPsec system receives an inbound packet on an SA and the
packet's header fields are not consistent with the selectors for
the SA, it MUST discard the packet. This is an auditable event.
The audit log entry for this event SHOULD include the current
date/time, SPI, IPsec protocol(s), source and destination of the
packet, any other selector values of the packet that are
available, and the selector values from the relevant SAD entry.
The system SHOULD also be capable of generating and sending an
IKE notification of INVALID_SELECTORS to the sender (IPsec peer),
indicating that the received packet was discarded because of
failure to pass selector checks.
To minimize the impact of a DoS attack, or a mis-configured peer, the IPsec system SHOULD include a management control to allow an administrator to configure the IPsec implementation to send or not send this IKE notification, and if this facility is selected, to rate limit the transmission of such notifications. After traffic is bypassed or processed through IPsec, it is handed to the inbound forwarding function for disposition. This function may cause the packet to be sent (outbound) across the IPsec boundary for additional inbound IPsec processing, e.g., in support of nested SAs. If so, then as with ALL outbound traffic that is to be bypassed, the packet MUST be matched against an SPD-O entry. Ultimately, the packet should be forwarded to the destination host or process for disposition.6. ICMP Processing
This section describes IPsec handling of ICMP traffic. There are two categories of ICMP traffic: error messages (e.g., type = destination unreachable) and non-error messages (e.g., type = echo). This section applies exclusively to error messages. Disposition of non-error, ICMP messages (that are not addressed to the IPsec implementation itself) MUST be explicitly accounted for using SPD entries. The discussion in this section applies to ICMPv6 as well as to ICMPv4. Also, a mechanism SHOULD be provided to allow an administrator to cause ICMP error messages (selected, all, or none) to be logged as an aid to problem diagnosis.6.1. Processing ICMP Error Messages Directed to an IPsec Implementation
6.1.1. ICMP Error Messages Received on the Unprotected Side of the Boundary
Figure 3 in Section 5.2 shows a distinct ICMP processing module on the unprotected side of the IPsec boundary, for processing ICMP messages (error or otherwise) that are addressed to the IPsec device and that are not protected via AH or ESP. An ICMP message of this sort is unauthenticated, and its processing may result in denial or degradation of service. This suggests that, in general, it would be desirable to ignore such messages. However, many ICMP messages will be received by hosts or security gateways from unauthenticated sources, e.g., routers in the public Internet. Ignoring these ICMP messages can degrade service, e.g., because of a failure to process PMTU message and redirection messages. Thus, there is also a motivation for accepting and acting upon unauthenticated ICMP messages.
To accommodate both ends of this spectrum, a compliant IPsec implementation MUST permit a local administrator to configure an IPsec implementation to accept or reject unauthenticated ICMP traffic. This control MUST be at the granularity of ICMP type and MAY be at the granularity of ICMP type and code. Additionally, an implementation SHOULD incorporate mechanisms and parameters for dealing with such traffic. For example, there could be the ability to establish a minimum PMTU for traffic (on a per destination basis), to prevent receipt of an unauthenticated ICMP from setting the PMTU to a trivial size. If an ICMP PMTU message passes the checks above and the system is configured to accept it, then there are two possibilities. If the implementation applies fragmentation on the ciphertext side of the boundary, then the accepted PMTU information is passed to the forwarding module (outside of the IPsec implementation), which uses it to manage outbound packet fragmentation. If the implementation is configured to effect plaintext side fragmentation, then the PMTU information is passed to the plaintext side and processed as described in Section 8.2.6.1.2. ICMP Error Messages Received on the Protected Side of the Boundary
These ICMP messages are not authenticated, but they do come from sources on the protected side of the IPsec boundary. Thus, these messages generally are viewed as more "trustworthy" than their counterparts arriving from sources on the unprotected side of the boundary. The major security concern here is that a compromised host or router might emit erroneous ICMP error messages that could degrade service for other devices "behind" the security gateway, or that could even result in violations of confidentiality. For example, if a bogus ICMP redirect were consumed by a security gateway, it could cause the forwarding table on the protected side of the boundary to be modified so as to deliver traffic to an inappropriate destination "behind" the gateway. Thus, implementers MUST provide controls to allow local administrators to constrain the processing of ICMP error messages received on the protected side of the boundary, and directed to the IPsec implementation. These controls are of the same type as those employed on the unprotected side, described above in Section 6.1.1.6.2. Processing Protected, Transit ICMP Error Messages
When an ICMP error message is transmitted via an SA to a device "behind" an IPsec implementation, both the payload and the header of the ICMP message require checking from an access control perspective. If one of these messages is forwarded to a host behind a security
gateway, the receiving host IP implementation will make decisions based on the payload, i.e., the header of the packet that purportedly triggered the error response. Thus, an IPsec implementation MUST be configurable to check that this payload header information is consistent with the SA via which it arrives. (This means that the payload header, with source and destination address and port fields reversed, matches the traffic selectors for the SA.) If this sort of check is not performed, then, for example, anyone with whom the receiving IPsec system (A) has an active SA could send an ICMP Destination Unreachable message that refers to any host/net with which A is currently communicating, and thus effect a highly efficient DoS attack regarding communication with other peers of A. Normal IPsec receiver processing of traffic is not sufficient to protect against such attacks. However, not all contexts may require such checks, so it is also necessary to allow a local administrator to configure an implementation to NOT perform such checks. To accommodate both policies, the following convention is adopted. If an administrator wants to allow ICMP error messages to be carried by an SA without inspection of the payload, then configure an SPD entry that explicitly allows for carriage of such traffic. If an administrator wants IPsec to check the payload of ICMP error messages for consistency, then do not create any SPD entries that accommodate carriage of such traffic based on the ICMP packet header. This convention motivates the following processing description. IPsec senders and receivers MUST support the following processing for ICMP error messages that are sent and received via SAs. If an SA exists that accommodates an outbound ICMP error message, then the message is mapped to the SA and only the IP and ICMP headers are checked upon receipt, just as would be the case for other traffic. If no SA exists that matches the traffic selectors associated with an ICMP error message, then the SPD is searched to determine if such an SA can be created. If so, the SA is created and the ICMP error message is transmitted via that SA. Upon receipt, this message is subject to the usual traffic selector checks at the receiver. This processing is exactly what would happen for traffic in general, and thus does not represent any special processing for ICMP error messages. If no SA exists that would carry the outbound ICMP message in question, and if no SPD entry would allow carriage of this outbound ICMP error message, then an IPsec implementation MUST map the message to the SA that would carry the return traffic associated with the packet that triggered the ICMP error message. This requires an IPsec implementation to detect outbound ICMP error messages that map to no extant SA or SPD entry, and treat them specially with regard to SA
creation and lookup. The implementation extracts the header for the packet that triggered the error (from the ICMP message payload), reverses the source and destination IP address fields, extracts the protocol field, and reverses the port fields (if accessible). It then uses this extracted information to locate an appropriate, active outbound SA, and transmits the error message via this SA. If no such SA exists, no SA will be created, and this is an auditable event. If an IPsec implementation receives an inbound ICMP error message on an SA, and the IP and ICMP headers of the message do not match the traffic selectors for the SA, the receiver MUST process the received message in a special fashion. Specifically, the receiver must extract the header of the triggering packet from the ICMP payload, and reverse fields as described above to determine if the packet is consistent with the selectors for the SA via which the ICMP error message was received. If the packet fails this check, the IPsec implementation MUST NOT forwarded the ICMP message to the destination. This is an auditable event.7. Handling Fragments (on the protected side of the IPsec boundary)
Earlier sections of this document describe mechanisms for (a) fragmenting an outbound packet after IPsec processing has been applied and reassembling it at the receiver before IPsec processing and (b) handling inbound fragments received from the unprotected side of the IPsec boundary. This section describes how an implementation should handle the processing of outbound plaintext fragments on the protected side of the IPsec boundary. (See Appendix D, "Fragment Handling Rationale".) In particular, it addresses: o mapping an outbound non-initial fragment to the right SA (or finding the right SPD entry) o verifying that a received non-initial fragment is authorized for the SA via which it was received o mapping outbound and inbound non-initial fragments to the right SPD-O/SPD-I entry or the relevant cache entry, for BYPASS/DISCARD traffic Note: In Section 4.1, transport mode SAs have been defined to not carry fragments (IPv4 or IPv6). Note also that in Section 4.4.1, two special values, ANY and OPAQUE, were defined for selectors and that ANY includes OPAQUE. The term "non-trivial" is used to mean that the selector has a value other than OPAQUE or ANY. Note: The term "non-initial fragment" is used here to indicate a fragment that does not contain all the selector values that may be needed for access control. As observed in Section 4.4.1, depending on the Next Layer Protocol, in addition to Ports, the ICMP message
type/code or Mobility Header type could be missing from non-initial
fragments. Also, for IPv6, even the first fragment might NOT contain
the Next Layer Protocol or Ports (or ICMP message type/code, or
Mobility Header type) depending on the kind and number of extension
headers present. If a non-initial fragment contains the Port (or
ICMP type and code or Mobility Header type) but not the Next Layer
Protocol, then unless there is an SPD entry for the relevant
Local/Remote addresses with ANY for Next Layer Protocol and Port (or
ICMP type and code or Mobility Header type), the fragment would not
contain all the selector information needed for access control.
To address the above issues, three approaches have been defined:
o Tunnel mode SAs that carry initial and non-initial fragments
(See Section 7.1.)
o Separate tunnel mode SAs for non-initial fragments (See
Section 7.2.)
o Stateful fragment checking (See Section 7.3.)
7.1. Tunnel Mode SAs that Carry Initial and Non-Initial Fragments
All implementations MUST support tunnel mode SAs that are configured
to pass traffic without regard to port field (or ICMP type/code or
Mobility Header type) values. If the SA will carry traffic for
specified protocols, the selector set for the SA MUST specify the
port fields (or ICMP type/code or Mobility Header type) as ANY. An
SA defined in this fashion will carry all traffic including initial
and non-initial fragments for the indicated Local/Remote addresses
and specified Next Layer protocol(s). If the SA will carry traffic
without regard to a specific protocol value (i.e., ANY is specified
as the (Next Layer) protocol selector value), then the port field
values are undefined and MUST be set to ANY as well. (As noted in
4.4.1, ANY includes OPAQUE as well as all specific values.)
7.2. Separate Tunnel Mode SAs for Non-Initial Fragments
An implementation MAY support tunnel mode SAs that will carry only
non-initial fragments, separate from non-fragmented packets and
initial fragments. The OPAQUE value will be used to specify port (or
ICMP type/code or Mobility Header type) field selectors for an SA to
carry such fragments. Receivers MUST perform a minimum offset check
on IPv4 (non-initial) fragments to protect against overlapping
fragment attacks when SAs of this type are employed. Because such
checks cannot be performed on IPv6 non-initial fragments, users and
administrators are advised that carriage of such fragments may be
dangerous, and implementers may choose to NOT support such SAs for
IPv6 traffic. Also, an SA of this sort will carry all non-initial
fragments that match a specified Local/Remote address pair and
protocol value, i.e., the fragments carried on this SA belong to packets that if not fragmented, might have gone on separate SAs of differing security. Therefore, users and administrators are advised to protect such traffic using ESP (with integrity) and the "strongest" integrity and encryption algorithms in use between both peers. (Determination of the "strongest" algorithms requires imposing an ordering of the available algorithms, a local determination at the discretion of the initiator of the SA.) Specific port (or ICMP type/code or Mobility Header type) selector values will be used to define SAs to carry initial fragments and non-fragmented packets. This approach can be used if a user or administrator wants to create one or more tunnel mode SAs between the same Local/Remote addresses that discriminate based on port (or ICMP type/code or Mobility Header type) fields. These SAs MUST have non-trivial protocol selector values, otherwise approach #1 above MUST be used. Note: In general, for the approach described in this section, one needs only a single SA between two implementations to carry all non-initial fragments. However, if one chooses to have multiple SAs between the two implementations for QoS differentiation, then one might also want multiple SAs to carry fragments-without-ports, one for each supported QoS class. Since support for QoS via distinct SAs is a local matter, not mandated by this document, the choice to have multiple SAs to carry non-initial fragments should also be local.7.3. Stateful Fragment Checking
An implementation MAY support some form of stateful fragment checking for a tunnel mode SA with non-trivial port (or ICMP type/code or MH type) field values (not ANY or OPAQUE). Implementations that will transmit non-initial fragments on a tunnel mode SA that makes use of non-trivial port (or ICMP type/code or MH type) selectors MUST notify a peer via the IKE NOTIFY NON_FIRST_FRAGMENTS_ALSO payload. The peer MUST reject this proposal if it will not accept non-initial fragments in this context. If an implementation does not successfully negotiate transmission of non-initial fragments for such an SA, it MUST NOT send such fragments over the SA. This standard does not specify how peers will deal with such fragments, e.g., via reassembly or other means, at either sender or receiver. However, a receiver MUST discard non-initial fragments that arrive on an SA with non-trivial port (or ICMP type/code or MH type) selector values unless this feature has been negotiated. Also, the receiver MUST discard non-initial fragments that do not comply with the security policy applied to the overall packet. Discarding such packets is an auditable event. Note that in network configurations where fragments
of a packet might be sent or received via different security gateways or BITW implementations, stateful strategies for tracking fragments may fail.7.4. BYPASS/DISCARD Traffic
All implementations MUST support DISCARDing of fragments using the normal SPD packet classification mechanisms. All implementations MUST support stateful fragment checking to accommodate BYPASS traffic for which a non-trivial port range is specified. The concern is that BYPASS of a cleartext, non-initial fragment arriving at an IPsec implementation could undermine the security afforded IPsec-protected traffic directed to the same destination. For example, consider an IPsec implementation configured with an SPD entry that calls for IPsec protection of traffic between a specific source/destination address pair, and for a specific protocol and destination port, e.g., TCP traffic on port 23 (Telnet). Assume that the implementation also allows BYPASS of traffic from the same source/destination address pair and protocol, but for a different destination port, e.g., port 119 (NNTP). An attacker could send a non-initial fragment (with a forged source address) that, if bypassed, could overlap with IPsec-protected traffic from the same source and thus violate the integrity of the IPsec-protected traffic. Requiring stateful fragment checking for BYPASS entries with non-trivial port ranges prevents attacks of this sort. As noted above, in network configurations where fragments of a packet might be sent or received via different security gateways or BITW implementations, stateful strategies for tracking fragments may fail.8. Path MTU/DF Processing
The application of AH or ESP to an outbound packet increases the size of a packet and thus may cause a packet to exceed the PMTU for the SA via which the packet will travel. An IPsec implementation also may receive an unprotected ICMP PMTU message and, if it chooses to act upon the message, the result will affect outbound traffic processing. This section describes the processing required of an IPsec implementation to deal with these two PMTU issues.8.1. DF Bit
All IPsec implementations MUST support the option of copying the DF bit from an outbound packet to the tunnel mode header that it emits, when traffic is carried via a tunnel mode SA. This means that it MUST be possible to configure the implementation's treatment of the DF bit (set, clear, copy from inner header) for each SA. This applies to SAs where both inner and outer headers are IPv4.
8.2. Path MTU (PMTU) Discovery
This section discusses IPsec handling for unprotected Path MTU Discovery messages. ICMP PMTU is used here to refer to an ICMP message for: IPv4 (RFC 792 [Pos81b]): - Type = 3 (Destination Unreachable) - Code = 4 (Fragmentation needed and DF set) - Next-Hop MTU in the low-order 16 bits of the second word of the ICMP header (labeled "unused" in RFC 792), with high-order 16 bits set to zero) IPv6 (RFC 2463 [CD98]): - Type = 2 (Packet Too Big) - Code = 0 (Fragmentation needed) - Next-Hop MTU in the 32-bit MTU field of the ICMP6 message8.2.1. Propagation of PMTU
When an IPsec implementation receives an unauthenticated PMTU message, and it is configured to process (vs. ignore) such messages, it maps the message to the SA to which it corresponds. This mapping is effected by extracting the header information from the payload of the PMTU message and applying the procedure described in Section 5.2. The PMTU determined by this message is used to update the SAD PMTU field, taking into account the size of the AH or ESP header that will be applied, any crypto synchronization data, and the overhead imposed by an additional IP header, in the case of a tunnel mode SA. In a native host implementation, it is possible to maintain PMTU data at the same granularity as for unprotected communication, so there is no loss of functionality. Signaling of the PMTU information is internal to the host. For all other IPsec implementation options, the PMTU data must be propagated via a synthesized ICMP PMTU. In these cases, the IPsec implementation SHOULD wait for outbound traffic to be mapped to the SAD entry. When such traffic arrives, if the traffic would exceed the updated PMTU value the traffic MUST be handled as follows: Case 1: Original (cleartext) packet is IPv4 and has the DF bit set. The implementation SHOULD discard the packet and send a PMTU ICMP message.
Case 2: Original (cleartext) packet is IPv4 and has the DF
bit clear. The implementation SHOULD fragment (before or
after encryption per its configuration) and then forward
the fragments. It SHOULD NOT send a PMTU ICMP message.
Case 3: Original (cleartext) packet is IPv6. The implementation
SHOULD discard the packet and send a PMTU ICMP message.
8.2.2. PMTU Aging
In all IPsec implementations, the PMTU associated with an SA MUST be
"aged" and some mechanism is required to update the PMTU in a timely
manner, especially for discovering if the PMTU is smaller than
required by current network conditions. A given PMTU has to remain
in place long enough for a packet to get from the source of the SA to
the peer, and to propagate an ICMP error message if the current PMTU
is too big.
Implementations SHOULD use the approach described in the Path MTU
Discovery document (RFC 1191 [MD90], Section 6.3), which suggests
periodically resetting the PMTU to the first-hop data-link MTU and
then letting the normal PMTU Discovery processes update the PMTU as
necessary. The period SHOULD be configurable.
9. Auditing
IPsec implementations are not required to support auditing. For the
most part, the granularity of auditing is a local matter. However,
several auditable events are identified in this document, and for
each of these events a minimum set of information that SHOULD be
included in an audit log is defined. Additional information also MAY
be included in the audit log for each of these events, and additional
events, not explicitly called out in this specification, also MAY
result in audit log entries. There is no requirement for the
receiver to transmit any message to the purported transmitter in
response to the detection of an auditable event, because of the
potential to induce denial of service via such action.
10. Conformance Requirements
All IPv4 IPsec implementations MUST comply with all requirements of
this document. All IPv6 implementations MUST comply with all
requirements of this document.
11. Security Considerations
The focus of this document is security; hence security considerations permeate this specification. IPsec imposes stringent constraints on bypass of IP header data in both directions, across the IPsec barrier, especially when tunnel mode SAs are employed. Some constraints are absolute, while others are subject to local administrative controls, often on a per-SA basis. For outbound traffic, these constraints are designed to limit covert channel bandwidth. For inbound traffic, the constraints are designed to prevent an adversary who has the ability to tamper with one data stream (on the unprotected side of the IPsec barrier) from adversely affecting other data streams (on the protected side of the barrier). The discussion in Section 5 dealing with processing DSCP values for tunnel mode SAs illustrates this concern. If an IPsec implementation is configured to pass ICMP error messages over SAs based on the ICMP header values, without checking the header information from the ICMP message payload, serious vulnerabilities may arise. Consider a scenario in which several sites (A, B, and C) are connected to one another via ESP-protected tunnels: A-B, A-C, and B-C. Also assume that the traffic selectors for each tunnel specify ANY for protocol and port fields and IP source/destination address ranges that encompass the address range for the systems behind the security gateways serving each site. This would allow a host at site B to send an ICMP Destination Unreachable message to any host at site A, that declares all hosts on the net at site C to be unreachable. This is a very efficient DoS attack that could have been prevented if the ICMP error messages were subjected to the checks that IPsec provides, if the SPD is suitably configured, as described in Section 6.2.12. IANA Considerations
The IANA has assigned the value (3) for the asn1-modules registry and has assigned the object identifier 1.3.6.1.5.8.3.1 for the SPD module. See Appendix C, "ASN.1 for an SPD Entry".13. Differences from RFC 2401
This architecture document differs substantially from RFC 2401 [RFC2401] in detail and in organization, but the fundamental notions are unchanged. o The processing model has been revised to address new IPsec scenarios, improve performance, and simplify implementation. This includes a separation between forwarding (routing) and SPD
selection, several SPD changes, and the addition of an outbound SPD
cache and an inbound SPD cache for bypassed or discarded traffic.
There is also a new database, the Peer Authorization Database
(PAD). This provides a link between an SA management protocol
(such as IKE) and the SPD.
o There is no longer a requirement to support nested SAs or "SA
bundles". Instead this functionality can be achieved through SPD
and forwarding table configuration. An example of a configuration
has been added in Appendix E.
o SPD entries were redefined to provide more flexibility. Each SPD
entry now consists of 1 to N sets of selectors, where each selector
set contains one protocol and a "list of ranges" can now be
specified for the Local IP address, Remote IP address, and whatever
fields (if any) are associated with the Next Layer Protocol (Local
Port, Remote Port, ICMP message type and code, and Mobility Header
type). An individual value for a selector is represented via a
trivial range and ANY is represented via a range than spans all
values for the selector. An example of an ASN.1 description is
included in Appendix C.
o TOS (IPv4) and Traffic Class (IPv6) have been replaced by DSCP and
ECN. The tunnel section has been updated to explain how to handle
DSCP and ECN bits.
o For tunnel mode SAs, an SG, BITS, or BITW implementation is now
allowed to fragment packets before applying IPsec. This applies
only to IPv4. For IPv6 packets, only the originator is allowed to
fragment them.
o When security is desired between two intermediate systems along a
path or between an intermediate system and an end system, transport
mode may now be used between security gateways and between a
security gateway and a host.
o This document clarifies that for all traffic that crosses the IPsec
boundary, including IPsec management traffic, the SPD or associated
caches must be consulted.
o This document defines how to handle the situation of a security
gateway with multiple subscribers requiring separate IPsec
contexts.
o A definition of reserved SPIs has been added.
o Text has been added explaining why ALL IP packets must be checked
-- IPsec includes minimal firewall functionality to support access
control at the IP layer.
o The tunnel section has been updated to clarify how to handle the IP
options field and IPv6 extension headers when constructing the
outer header.
o SA mapping for inbound traffic has been updated to be consistent
with the changes made in AH and ESP for support of unicast and
multicast SAs.
o Guidance has been added regarding how to handle the covert channel
created in tunnel mode by copying the DSCP value to outer header.
o Support for AH in both IPv4 and IPv6 is no longer required.
o PMTU handling has been updated. The appendix on
PMTU/DF/Fragmentation has been deleted.
o Three approaches have been added for handling plaintext fragments
on the protected side of the IPsec boundary. Appendix D documents
the rationale behind them.
o Added revised text describing how to derive selector values for SAs
(from the SPD entry or from the packet, etc.)
o Added a new table describing the relationship between selector
values in an SPD entry, the PFP flag, and resulting selector values
in the corresponding SAD entry.
o Added Appendix B to describe decorrelation.
o Added text describing how to handle an outbound packet that must be
discarded.
o Added text describing how to handle a DISCARDED inbound packet,
i.e., one that does not match the SA upon which it arrived.
o IPv6 mobility header has been added as a possible Next Layer
Protocol. IPv6 Mobility Header message type has been added as a
selector.
o ICMP message type and code have been added as selectors.
o The selector "data sensitivity level" has been removed to simplify
things.
o Updated text describing handling ICMP error messages. The appendix
on "Categorization of ICMP Messages" has been deleted.
o The text for the selector name has been updated and clarified.
o The "Next Layer Protocol" has been further explained and a default
list of protocols to skip when looking for the Next Layer Protocol
has been added.
o The text has been amended to say that this document assumes use of
IKEv2 or an SA management protocol with comparable features.
o Text has been added clarifying the algorithm for mapping inbound
IPsec datagrams to SAs in the presence of multicast SAs.
o The appendix "Sequence Space Window Code Example" has been removed.
o With respect to IP addresses and ports, the terms "Local" and
"Remote" are used for policy rules (replacing source and
destination). "Local" refers to the entity being protected by an
IPsec implementation, i.e., the "source" address/port of outbound
packets or the "destination" address/port of inbound packets.
"Remote" refers to a peer entity or peer entities. The terms
"source" and "destination" are still used for packet header fields.
14. Acknowledgements
The authors would like to acknowledge the contributions of Ran
Atkinson, who played a critical role in initial IPsec activities, and
who authored the first series of IPsec standards: RFCs 1825-1827; and
Charlie Lynn, who made significant contributions to the second series
of IPsec standards (RFCs 2401, 2402, and 2406) and to the current
versions, especially with regard to IPv6 issues. The authors also
would like to thank the members of the IPsec and MSEC working groups
who have contributed to the development of this protocol
specification.