which will have the port information. [MAY be supported]
The IPsec implementation context determines how selectors are used.
For example, a host implementation integrated into the stack may make
use of a socket interface. When a new connection is established the
SPD can be consulted and an SA (or SA bundle) bound to the socket.
Thus traffic sent via that socket need not result in additional
lookups to the SPD/SAD. In contrast, a BITS, BITW, or security
gateway implementation needs to look at each packet and perform an
SPD/SAD lookup based on the selectors. The allowable values for the
selector fields differ between the traffic flow, the security
association, and the security policy.
The following table summarizes the kinds of entries that one needs to
be able to express in the SPD and SAD. It shows how they relate to
the fields in data traffic being subjected to IPsec screening.
(Note: the "wild" or "wildcard" entry for src and dst addresses
includes a mask, range, etc.)
Field Traffic Value SAD Entry SPD Entry
-------- ------------- ---------------- --------------------
src addr single IP addr single,range,wild single,range,wildcard
dst addr single IP addr single,range,wild single,range,wildcard
xpt protocol* xpt protocol single,wildcard single,wildcard
src port* single src port single,wildcard single,wildcard
dst port* single dst port single,wildcard single,wildcard
user id* single user id single,wildcard single,wildcard
sec. labels single value single,wildcard single,wildcard
* The SAD and SPD entries for these fields could be "OPAQUE"
because the traffic value is encrypted.
NOTE: In principle, one could have selectors and/or selector values
in the SPD which cannot be negotiated for an SA or SA bundle.
Examples might include selector values used to select traffic for
discarding or enumerated lists which cause a separate SA to be
created for each item on the list. For now, this is left for future
versions of this document and the list of required selectors and
selector values is the same for the SPD and the SAD. However, it is
acceptable to have an administrative interface that supports use of
selector values which cannot be negotiated provided that it does not
mislead the user into believing it is creating an SA with these
selector values. For example, the interface may allow the user to
specify an enumerated list of values but would result in the creation
of a separate policy and SA for each item on the list. A vendor
might support such an interface to make it easier for its customers
to specify clear and concise policy specifications.
4.4.3 Security Association Database (SAD)
In each IPsec implementation there is a nominal Security Association
Database, in which each entry defines the parameters associated with
one SA. Each SA has an entry in the SAD. For outbound processing,
entries are pointed to by entries in the SPD. Note that if an SPD
entry does not currently point to an SA that is appropriate for the
packet, the implementation creates an appropriate SA (or SA Bundle)
and links the SPD entry to the SAD entry (see Section 5.1.1). For
inbound processing, each entry in the SAD is indexed by a destination
IP address, IPsec protocol type, and SPI. The following parameters
are associated with each entry in the SAD. This description does not
purport to be a MIB, but only a specification of the minimal data
items required to support an SA in an IPsec implementation.
For inbound processing: The following packet fields are used to look
up the SA in the SAD:
o Outer Header's Destination IP address: the IPv4 or IPv6
Destination address.
[REQUIRED for all implementations]
o IPsec Protocol: AH or ESP, used as an index for SA lookup
in this database. Specifies the IPsec protocol to be
applied to the traffic on this SA.
[REQUIRED for all implementations]
o SPI: the 32-bit value used to distinguish among different
SAs terminating at the same destination and using the same
IPsec protocol.
[REQUIRED for all implementations]
For each of the selectors defined in Section 4.4.2, the SA entry in
the SAD MUST contain the value or values which were negotiated at the
time the SA was created. For the sender, these values are used to
decide whether a given SA is appropriate for use with an outbound
packet. This is part of checking to see if there is an existing SA
that can be used. For the receiver, these values are used to check
that the selector values in an inbound packet match those for the SA
(and thus indirectly those for the matching policy). For the
receiver, this is part of verifying that the SA was appropriate for
this packet. (See Section 6 for rules for ICMP messages.) These
fields can have the form of specific values, ranges, wildcards, or
"OPAQUE" as described in section 4.4.2, "Selectors". Note that for
an ESP SA, the encryption algorithm or the authentication algorithm
could be "NULL". However they MUST not both be "NULL".
The following SAD fields are used in doing IPsec processing:
o Sequence Number Counter: a 32-bit value used to generate the
Sequence Number field in AH or ESP headers.
[REQUIRED for all implementations, but used only for outbound
traffic.]
o Sequence Counter Overflow: a flag indicating whether overflow
of the Sequence Number Counter should generate an auditable
event and prevent transmission of additional packets on the
SA.
[REQUIRED for all implementations, but used only for outbound
traffic.]
o Anti-Replay Window: a 32-bit counter and a bit-map (or
equivalent) used to determine whether an inbound AH or ESP
packet is a replay.
[REQUIRED for all implementations but used only for inbound
traffic. NOTE: If anti-replay has been disabled by the
receiver, e.g., in the case of a manually keyed SA, then the
Anti-Replay Window is not used.]
o AH Authentication algorithm, keys, etc.
[REQUIRED for AH implementations]
o ESP Encryption algorithm, keys, IV mode, IV, etc.
[REQUIRED for ESP implementations]
o ESP authentication algorithm, keys, etc. If the
authentication service is not selected, this field will be
null.
[REQUIRED for ESP implementations]
o Lifetime of this Security Association: a time interval after
which an SA must be replaced with a new SA (and new SPI) or
terminated, plus an indication of which of these actions
should occur. This may be expressed as a time or byte count,
or a simultaneous use of both, the first lifetime to expire
taking precedence. A compliant implementation MUST support
both types of lifetimes, and must support a simultaneous use
of both. If time is employed, and if IKE employs X.509
certificates for SA establishment, the SA lifetime must be
constrained by the validity intervals of the certificates,
and the NextIssueDate of the CRLs used in the IKE exchange
for the SA. Both initiator and responder are responsible for
constraining SA lifetime in this fashion.
[REQUIRED for all implementations]
NOTE: The details of how to handle the refreshing of keys
when SAs expire is a local matter. However, one reasonable
approach is:
(a) If byte count is used, then the implementation
SHOULD count the number of bytes to which the IPsec
algorithm is applied. For ESP, this is the encryption
algorithm (including Null encryption) and for AH,
this is the authentication algorithm. This includes
pad bytes, etc. Note that implementations SHOULD be
able to handle having the counters at the ends of an
SA get out of synch, e.g., because of packet loss or
because the implementations at each end of the SA
aren't doing things the same way.
(b) There SHOULD be two kinds of lifetime -- a soft
lifetime which warns the implementation to initiate
action such as setting up a replacement SA and a
hard lifetime when the current SA ends.
(c) If the entire packet does not get delivered during
the SAs lifetime, the packet SHOULD be discarded.
o IPsec protocol mode: tunnel, transport or wildcard.
Indicates which mode of AH or ESP is applied to traffic on
this SA. Note that if this field is "wildcard" at the
sending end of the SA, then the application has to specify
the mode to the IPsec implementation. This use of wildcard
allows the same SA to be used for either tunnel or transport
mode traffic on a per packet basis, e.g., by different
sockets. The receiver does not need to know the mode in
order to properly process the packet's IPsec headers.
[REQUIRED as follows, unless implicitly defined by context:
- host implementations must support all modes
- gateway implementations must support tunnel mode]
NOTE: The use of wildcard for the protocol mode of an inbound
SA may add complexity to the situation in the receiver (host
only). Since the packets on such an SA could be delivered in
either tunnel or transport mode, the security of an incoming
packet could depend in part on which mode had been used to
deliver it. If, as a result, an application cared about the
SA mode of a given packet, then the application would need a
mechanism to obtain this mode information.
o Path MTU: any observed path MTU and aging variables. See
Section 6.1.2.4
[REQUIRED for all implementations but used only for outbound
traffic]
4.5 Basic Combinations of Security Associations
This section describes four examples of combinations of security
associations that MUST be supported by compliant IPsec hosts or
security gateways. Additional combinations of AH and/or ESP in
tunnel and/or transport modes MAY be supported at the discretion of
the implementor. Compliant implementations MUST be capable of
generating these four combinations and on receipt, of processing
them, but SHOULD be able to receive and process any combination. The
diagrams and text below describe the basic cases. The legend for the
diagrams is:
==== = one or more security associations (AH or ESP, transport
or tunnel)
---- = connectivity (or if so labelled, administrative boundary)
Hx = host x
SGx = security gateway x
X* = X supports IPsec
NOTE: The security associations below can be either AH or ESP. The
mode (tunnel vs transport) is determined by the nature of the
endpoints. For host-to-host SAs, the mode can be either transport or
tunnel.
Case 1. The case of providing end-to-end security between 2 hosts
across the Internet (or an Intranet).
====================================
| |
H1* ------ (Inter/Intranet) ------ H2*
Note that either transport or tunnel mode can be selected by the
hosts. So the headers in a packet between H1 and H2 could look
like any of the following:
Transport Tunnel
----------------- ---------------------
1. [IP1][AH][upper] 4. [IP2][AH][IP1][upper]
2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper]
3. [IP1][AH][ESP][upper]
Note that there is no requirement to support general nesting,
but in transport mode, both AH and ESP can be applied to the
packet. In this event, the SA establishment procedure MUST
ensure that first ESP, then AH are applied to the packet.
Case 2. This case illustrates simple virtual private networks
support.
===========================
| |
---------------------|---- ---|-----------------------
| | | | | |
| H1 -- (Local --- SG1* |--- (Internet) ---| SG2* --- (Local --- H2 |
| Intranet) | | Intranet) |
-------------------------- ---------------------------
admin. boundary admin. boundary
Only tunnel mode is required here. So the headers in a packet
between SG1 and SG2 could look like either of the following:
Tunnel
---------------------
4. [IP2][AH][IP1][upper]
5. [IP2][ESP][IP1][upper]
Case 3. This case combines cases 1 and 2, adding end-to-end security
between the sending and receiving hosts. It imposes no new
requirements on the hosts or security gateways, other than a
requirement for a security gateway to be configurable to pass
IPsec traffic (including ISAKMP traffic) for hosts behind it.
===============================================================
| |
| ========================= |
| | | |
---|-----------------|---- ---|-------------------|---
| | | | | | | |
| H1* -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2* |
| Intranet) | | Intranet) |
-------------------------- ---------------------------
admin. boundary admin. boundary
Case 4. This covers the situation where a remote host (H1) uses the
Internet to reach an organization's firewall (SG2) and to then
gain access to some server or other machine (H2). The remote
host could be a mobile host (H1) dialing up to a local PPP/ARA
server (not shown) on the Internet and then crossing the
Internet to the home organization's firewall (SG2), etc. The
details of support for this case, (how H1 locates SG2,
authenticates it, and verifies its authorization to represent
H2) are discussed in Section 4.6.3, "Locating a Security
Gateway".
======================================================
| |
|============================== |
|| | |
|| ---|----------------------|---
|| | | | |
H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* |
^ | Intranet) |
| ------------------------------
could be dialup admin. boundary (optional)
to PPP/ARA server
Only tunnel mode is required between H1 and SG2. So the choices
for the SA between H1 and SG2 would be one of the ones in case
2. The choices for the SA between H1 and H2 would be one of the
ones in case 1.
Note that in this case, the sender MUST apply the transport
header before the tunnel header. Therefore the management
interface to the IPsec implementation MUST support configuration
of the SPD and SAD to ensure this ordering of IPsec header
application.
As noted above, support for additional combinations of AH and ESP is
optional. Use of other, optional combinations may adversely affect
interoperability.
4.6 SA and Key Management
IPsec mandates support for both manual and automated SA and
cryptographic key management. The IPsec protocols, AH and ESP, are
largely independent of the associated SA management techniques,
although the techniques involved do affect some of the security
services offered by the protocols. For example, the optional anti-
replay services available for AH and ESP require automated SA
management. Moreover, the granularity of key distribution employed
with IPsec determines the granularity of authentication provided.
(See also a discussion of this issue in Section 4.7.) In general,
data origin authentication in AH and ESP is limited by the extent to
which secrets used with the authentication algorithm (or with a key
management protocol that creates such secrets) are shared among
multiple possible sources.
The following text describes the minimum requirements for both types
of SA management.
4.6.1 Manual Techniques
The simplest form of management is manual management, in which a
person manually configures each system with keying material and
security association management data relevant to secure communication
with other systems. Manual techniques are practical in small, static
environments but they do not scale well. For example, a company
could create a Virtual Private Network (VPN) using IPsec in security
gateways at several sites. If the number of sites is small, and
since all the sites come under the purview of a single administrative
domain, this is likely to be a feasible context for manual management
techniques. In this case, the security gateway might selectively
protect traffic to and from other sites within the organization using
a manually configured key, while not protecting traffic for other
destinations. It also might be appropriate when only selected
communications need to be secured. A similar argument might apply to
use of IPsec entirely within an organization for a small number of
hosts and/or gateways. Manual management techniques often employ
statically configured, symmetric keys, though other options also
exist.
4.6.2 Automated SA and Key Management
Widespread deployment and use of IPsec requires an Internet-standard,
scalable, automated, SA management protocol. Such support is
required to facilitate use of the anti-replay features of AH and ESP,
and to accommodate on-demand creation of SAs, e.g., for user- and
session-oriented keying. (Note that the notion of "rekeying" an SA
actually implies creation of a new SA with a new SPI, a process that
generally implies use of an automated SA/key management protocol.)
The default automated key management protocol selected for use with
IPsec is IKE [MSST97, Orm97, HC98] under the IPsec domain of
interpretation [Pip98]. Other automated SA management protocols MAY
be employed.
When an automated SA/key management protocol is employed, the output
from this protocol may be used to generate multiple keys, e.g., for a
single ESP SA. This may arise because:
o the encryption algorithm uses multiple keys (e.g., triple DES)
o the authentication algorithm uses multiple keys
o both encryption and authentication algorithms are employed
The Key Management System may provide a separate string of bits for
each key or it may generate one string of bits from which all of them
are extracted. If a single string of bits is provided, care needs to
be taken to ensure that the parts of the system that map the string
of bits to the required keys do so in the same fashion at both ends
of the SA. To ensure that the IPsec implementations at each end of
the SA use the same bits for the same keys, and irrespective of which
part of the system divides the string of bits into individual keys,
the encryption key(s) MUST be taken from the first (left-most, high-
order) bits and the authentication key(s) MUST be taken from the
remaining bits. The number of bits for each key is defined in the
relevant algorithm specification RFC. In the case of multiple
encryption keys or multiple authentication keys, the specification
for the algorithm must specify the order in which they are to be
selected from a single string of bits provided to the algorithm.
4.6.3 Locating a Security Gateway
This section discusses issues relating to how a host learns about the
existence of relevant security gateways and once a host has contacted
these security gateways, how it knows that these are the correct
security gateways. The details of where the required information is
stored is a local matter.
Consider a situation in which a remote host (H1) is using the
Internet to gain access to a server or other machine (H2) and there
is a security gateway (SG2), e.g., a firewall, through which H1's
traffic must pass. An example of this situation would be a mobile
host (Road Warrior) crossing the Internet to the home organization's
firewall (SG2). (See Case 4 in the section 4.5 Basic Combinations of
Security Associations.) This situation raises several issues:
1. How does H1 know/learn about the existence of the security
gateway SG2?
2. How does it authenticate SG2, and once it has authenticated
SG2, how does it confirm that SG2 has been authorized to
represent H2?
3. How does SG2 authenticate H1 and verify that H1 is authorized
to contact H2?
4. How does H1 know/learn about backup gateways which provide
alternate paths to H2?
To address these problems, a host or security gateway MUST have an
administrative interface that allows the user/administrator to
configure the address of a security gateway for any sets of
destination addresses that require its use. This includes the ability
to configure:
o the requisite information for locating and authenticating the
security gateway and verifying its authorization to represent
the destination host.
o the requisite information for locating and authenticating any
backup gateways and verifying their authorization to represent
the destination host.
It is assumed that the SPD is also configured with policy information
that covers any other IPsec requirements for the path to the security
gateway and the destination host.
This document does not address the issue of how to automate the
discovery/verification of security gateways.
4.7 Security Associations and Multicast
The receiver-orientation of the Security Association implies that, in
the case of unicast traffic, the destination system will normally
select the SPI value. By having the destination select the SPI
value, there is no potential for manually configured Security
Associations to conflict with automatically configured (e.g., via a
key management protocol) Security Associations or for Security
Associations from multiple sources to conflict with each other. For
multicast traffic, there are multiple destination systems per
multicast group. So some system or person will need to coordinate
among all multicast groups to select an SPI or SPIs on behalf of each
multicast group and then communicate the group's IPsec information to
all of the legitimate members of that multicast group via mechanisms
not defined here.
Multiple senders to a multicast group SHOULD use a single Security
Association (and hence Security Parameter Index) for all traffic to
that group when a symmetric key encryption or authentication
algorithm is employed. In such circumstances, the receiver knows only
that the message came from a system possessing the key for that
multicast group. In such circumstances, a receiver generally will
not be able to authenticate which system sent the multicast traffic.
Specifications for other, more general multicast cases are deferred
to later IPsec documents.
At the time this specification was published, automated protocols for
multicast key distribution were not considered adequately mature for
standardization. For multicast groups having relatively few members,
manual key distribution or multiple use of existing unicast key
distribution algorithms such as modified Diffie-Hellman appears
feasible. For very large groups, new scalable techniques will be
needed. An example of current work in this area is the Group Key
Management Protocol (GKMP) [HM97].
5. IP Traffic Processing
As mentioned in Section 4.4.1 "The Security Policy Database (SPD)",
the SPD must be consulted during the processing of all traffic
(INBOUND and OUTBOUND), including non-IPsec traffic. If no policy is
found in the SPD that matches the packet (for either inbound or
outbound traffic), the packet MUST be discarded.
NOTE: All of the cryptographic algorithms used in IPsec expect their
input in canonical network byte order (see Appendix in RFC791) and
generate their output in canonical network byte order. IP packets
are also transmitted in network byte order.
5.1 Outbound IP Traffic Processing
5.1.1 Selecting and Using an SA or SA Bundle
In a security gateway or BITW implementation (and in many BITS
implementations), each outbound packet is compared against the SPD to
determine what processing is required for the packet. If the packet
is to be discarded, this is an auditable event. If the traffic is
allowed to bypass IPsec processing, the packet continues through
"normal" processing for the environment in which the IPsec processing
is taking place. If IPsec processing is required, the packet is
either mapped to an existing SA (or SA bundle), or a new SA (or SA
bundle) is created for the packet. Since a packet's selectors might
match multiple policies or multiple extant SAs and since the SPD is
ordered, but the SAD is not, IPsec MUST:
1. Match the packet's selector fields against the outbound
policies in the SPD to locate the first appropriate
policy, which will point to zero or more SA bundles in the
SAD.
2. Match the packet's selector fields against those in the SA
bundles found in (1) to locate the first SA bundle that
matches. If no SAs were found or none match, create an
appropriate SA bundle and link the SPD entry to the SAD
entry. If no key management entity is found, drop the
packet.
3. Use the SA bundle found/created in (2) to do the required
IPsec processing, e.g., authenticate and encrypt.
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.
NOTE: A compliant implementation MUST not allow instantiation of an
ESP SA that employs both a NULL encryption and a NULL authentication
algorithm. An attempt to negotiate such an SA is an auditable event.
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. This
includes how to construct the encapsulating (outer) IP header, how to
handle fields in the inner IP header, and what other actions should
be taken. The general idea is modeled after the one used in RFC
2003, "IP Encapsulation with IP":
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 to decrement the TTL
as noted below, and 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.
o If need be, other protocol headers such as the IP
Authentication header may be inserted between the outer IP
header and the inner IP header.
The tables in the following sub-sections show the handling for the
different header/option fields (constructed = 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
TOS copied from inner hdr (5) no change
total length constructed no change
ID constructed no change
flags (DF,MF) constructed, DF (4) no change
fragmt offset constructed no change
TTL constructed (2) decrement (2)
protocol AH, ESP, routing hdr no change
checksum constructed constructed (2)
src address constructed (3) no change
dest address constructed (3) no change
Options never copied no change
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 checksum changes when the TTL
changes.)
Note: The decrementing of the TTL is one of the usual actions
that takes place when forwarding a packet. Packets
originating from the same node as the encapsulator do not
have their TTL's decremented, as the sending node is
originating the packet rather than forwarding it.
3. src and dest addresses depend on the SA, which is used to
determine the dest address which in turn determines which src
address (net interface) is used to forward the packet.
NOTE: In principle, the encapsulating IP source address can
be any of the encapsulator's interface addresses or even an
address different from any of the encapsulator's IP
addresses, (e.g., if it's acting as a NAT box) so long as the
address is reachable through the encapsulator from the
environment into which the packet is sent. This does not
cause a problem because IPsec does not currently have any
INBOUND processing requirement that involves the Source
Address of the encapsulating IP header. So while the
receiving tunnel endpoint looks at the Destination Address in
the encapsulating IP header, it only looks at the Source
Address in the inner (encapsulated) IP header.
4. configuration determines whether to copy from the inner
header (IPv4 only), clear or set the DF.
5. If Inner Hdr is IPv4 (Protocol = 4), copy the TOS. If Inner
Hdr is IPv6 (Protocol = 41), map the Class to TOS.
5.1.2.2 IPv6 -- Header Construction for Tunnel Mode
See previous section 5.1.2 for notes 1-5 indicated by (footnote
number).
<-- How Outer Hdr Relates Inner Hdr --->
Outer Hdr at Inner Hdr at
IPv6 Encapsulator Decapsulator
Header fields: -------------------- ------------
version 6 (1) no change
class copied or configured (6) no change
flow id copied or configured no change
len 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 no change
6. If Inner Hdr is IPv6 (Next Header = 41), copy the Class. If
Inner Hdr is IPv4 (Next Header = 4), map the TOS to Class.
5.2 Processing Inbound IP Traffic
Prior to performing AH or ESP processing, any IP fragments are
reassembled. 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 an extension header in
the IPv6 context).
Note: Appendix C contains sample code for a bitmask check for a 32
packet window that can be used for implementing anti-replay service.
5.2.1 Selecting and Using an SA or SA Bundle
Mapping the IP datagram to the appropriate SA is simplified because
of the presence of the SPI in the AH or ESP header. Note that the
selector checks are made on the inner headers not the outer (tunnel)
headers. The steps followed are:
1. Use the packet's destination address (outer IP header),
IPsec protocol, and SPI to look up the SA in the SAD. If
the SA lookup fails, drop the packet and log/report the
error.
2. Use the SA found in (1) to do the IPsec processing, e.g.,
authenticate and decrypt. This step includes matching the
packet's (Inner Header if tunneled) selectors to the
selectors in the SA. Local policy determines the
specificity of the SA selectors (single value, list,
range, wildcard). In general, a packet's source address
MUST match the SA selector value. However, an ICMP packet
received on a tunnel mode SA may have a source address
other than that bound to the SA and thus such packets
should be permitted as exceptions to this check. For an
ICMP packet, the selectors from the enclosed problem
packet (the source and destination addresses and ports
should be swapped) should be checked against the selectors
for the SA. Note that some or all of these selectors may
be inaccessible because of limitations on how many bits of
the problem packet the ICMP packet is allowed to carry or
due to encryption. See Section 6.
Do (1) and (2) for every IPsec header until a Transport
Protocol Header or an IP header that is NOT for this
system is encountered. Keep track of what SAs have been
used and their order of application.
3. Find an incoming policy in the SPD that matches the
packet. This could be done, for example, by use of
backpointers from the SAs to the SPD or by matching the
packet's selectors (Inner Header if tunneled) against
those of the policy entries in the SPD.
4. Check whether the required IPsec processing has been
applied, i.e., verify that the SA's found in (1) and (2)
match the kind and order of SAs required by the policy
found in (3).
NOTE: The correct "matching" policy will not necessarily
be the first inbound policy found. If the check in (4)
fails, steps (3) and (4) are repeated until all policy
entries have been checked or until the check succeeds.
At the end of these steps, pass the resulting packet to the Transport
Layer or forward the packet. Note that any IPsec headers processed
in these steps may have been removed, but that this information,
i.e., what SAs were used and the order of their application, may be
needed for subsequent IPsec or firewall processing.
Note that in the case of a security gateway, if forwarding causes a
packet to exit via an IPsec-enabled interface, then additional IPsec
processing may be applied.
5.2.2 Handling of AH and ESP tunnels
The handling of the inner and outer IP headers, extension headers,
and options for AH and ESP tunnels should be performed as described
in the tables in Section 5.1.
6. ICMP Processing (relevant to IPsec)
The focus of this section is on the handling of ICMP error messages.
Other ICMP traffic, e.g., Echo/Reply, should be treated like other
traffic and can be protected on an end-to-end basis using SAs in the
usual fashion.
An ICMP error message protected by AH or ESP and generated by a
router SHOULD be processed and forwarded in a tunnel mode SA. Local
policy determines whether or not it is subjected to source address
checks by the router at the destination end of the tunnel. Note that
if the router at the originating end of the tunnel is forwarding an
ICMP error message from another router, the source address check
would fail. An ICMP message protected by AH or ESP and generated by
a router MUST NOT be forwarded on a transport mode SA (unless the SA
has been established to the router acting as a host, e.g., a Telnet
connection used to manage a router). An ICMP message generated by a
host SHOULD be checked against the source IP address selectors bound
to the SA in which the message arrives. Note that even if the source
of an ICMP error message is authenticated, the returned IP header
could be invalid. Accordingly, the selector values in the IP header
SHOULD also be checked to be sure that they are consistent with the
selectors for the SA over which the ICMP message was received.
The table in Appendix D characterize ICMP messages as being either
host generated, router generated, both, unknown/unassigned. ICMP
messages falling into the last two categories should be handled as
determined by the receiver's policy.
An ICMP message not protected by AH or ESP is unauthenticated and its
processing and/or forwarding may result in denial of service. This
suggests that, in general, it would be desirable to ignore such
messages. However, it is expected that many routers (vs. security
gateways) will not implement IPsec for transit traffic and thus
strict adherence to this rule would cause many ICMP messages to be
discarded. The result is that some critical IP functions would be
lost, e.g., redirection and PMTU processing. Thus it MUST be
possible to configure an IPsec implementation to accept or reject
(router) ICMP traffic as per local security policy.
The remainder of this section addresses how PMTU processing MUST be
performed at hosts and security gateways. It addresses processing of
both authenticated and unauthenticated ICMP PMTU messages. However,
as noted above, unauthenticated ICMP messages MAY be discarded based
on local policy.
6.1 PMTU/DF Processing
6.1.1 DF Bit
In cases where a system (host or gateway) adds an encapsulating
header (ESP tunnel or AH tunnel), it MUST support the option of
copying the DF bit from the original packet to the encapsulating
header (and processing ICMP PMTU messages). This means that it MUST
be possible to configure the system's treatment of the DF bit (set,
clear, copy from encapsulated header) for each interface. (See
Appendix B for rationale.)
6.1.2 Path MTU Discovery (PMTU)
This section discusses IPsec handling for Path MTU Discovery
messages. ICMP PMTU is used here to refer to an ICMP message for:
IPv4 (RFC792):
- 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 (labelled "unused" in RFC
792), with high-order 16 bits set to zero
IPv6 (RFC1885):
- Type = 2 (Packet Too Big)
- Code = 0 (Fragmentation needed)
- Next-Hop MTU in the 32 bit MTU field of the ICMP6
message
6.1.2.1 Propagation of PMTU
The amount of information returned with the ICMP PMTU message (IPv4
or IPv6) is limited and this affects what selectors are available for
use in further propagating the PMTU information. (See Appendix B for
more detailed discussion of this topic.)
o PMTU message with 64 bits of IPsec header -- If the ICMP PMTU
message contains only 64 bits of the IPsec header (minimum for
IPv4), then a security gateway MUST support the following options
on a per SPI/SA basis:
a. if the originating host can be determined (or the possible
sources narrowed down to a manageable number), send the PM
information to all the possible originating hosts.
b. if the originating host cannot be determined, store the PMTU
with the SA and wait until the next packet(s) arrive from the
originating host for the relevant security association. If
the packet(s) are bigger than the PMTU, drop the packet(s),
and compose ICMP PMTU message(s) with the new packet(s) and
the updated PMTU, and send the ICMP message(s) about the
problem to the originating host. Retain the PMTU information
for any message that might arrive subsequently (see Section
6.1.2.4, "PMTU Aging").
o PMTU message with >64 bits of IPsec header -- If the ICMP message
contains more information from the original packet then there may
be enough non-opaque information to immediately determine to which
host to propagate the ICMP/PMTU message and to provide that system
with the 5 fields (source address, destination address, source
port, destination port, transport protocol) needed to determine
where to store/update the PMTU. Under such circumstances, a
security gateway MUST generate an ICMP PMTU message immediately
upon receipt of an ICMP PMTU from further down the path.
o Distributing the PMTU to the Transport Layer -- The host mechanism
for getting the updated PMTU to the transport layer is unchanged,
as specified in RFC1191 (Path MTU Discovery).
6.1.2.2 Calculation of PMTU
The calculation of PMTU from an ICMP PMTU MUST take into account the
addition of any IPsec header -- AH transport, ESP transport, AH/ESP
transport, ESP tunnel, AH tunnel. (See Appendix B for discussion of
implementation issues.)
Note: In some situations the addition of IPsec headers could result
in an effective PMTU (as seen by the host or application) that is
unacceptably small. To avoid this problem, the implementation may
establish a threshold below which it will not report a reduced PMTU.
In such cases, the implementation would apply IPsec and then fragment
the resulting packet according to the PMTU. This would result in a
more efficient use of the available bandwidth.
6.1.2.3 Granularity of PMTU Processing
In hosts, the granularity with which ICMP PMTU processing can be done
differs depending on the implementation situation. Looking at a
host, there are 3 situations that are of interest with respect to
PMTU issues (See Appendix B for additional details on this topic.):
a. Integration of IPsec into the native IP implementation
b. Bump-in-the-stack implementations, where IPsec is implemented
"underneath" an existing implementation of a TCP/IP protocol
stack, between the native IP and the local network drivers
c. No IPsec implementation -- This case is included because it
is relevant in cases where a security gateway is sending PMTU
information back to a host.
Only in case (a) can the PMTU data be maintained at the same
granularity as communication associations. In (b) and (c), the IP
layer will only be able to maintain PMTU data at the granularity of
source and destination IP addresses (and optionally TOS), as
described in RFC1191. This is an important difference, because more
than one communication association may map to the same source and
destination IP addresses, and each communication association may have
a different amount of IPsec header overhead (e.g., due to use of
different transforms or different algorithms).
Implementation of the calculation of PMTU and support for PMTUs at
the granularity of individual communication associations is a local
matter. However, a socket-based implementation of IPsec in a host
SHOULD maintain the information on a per socket basis. Bump in the
stack systems MUST pass an ICMP PMTU to the host IP implementation,
after adjusting it for any IPsec header overhead added by these
systems. The calculation of the overhead SHOULD be determined by
analysis of the SPI and any other selector information present in a
returned ICMP PMTU message.
6.1.2.4 PMTU Aging
In all systems (host or gateway) implementing IPsec and maintaining
PMTU information, the PMTU associated with a security association
(transport or tunnel) MUST be "aged" and some mechanism put in place
for updating the PMTU in a timely manner, especially for discovering
if the PMTU is smaller than it needs to be. A given PMTU has to
remain in place long enough for a packet to get from the source end
of the security association to the system at the other end of the
security association and propagate back an ICMP error message if the
current PMTU is too big. Note that if there are nested tunnels,
multiple packets and round trip times might be required to get an
ICMP message back to an encapsulator or originating host.
Systems SHOULD use the approach described in the Path MTU Discovery
document (RFC1191, 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.
7. Auditing
Not all systems that implement IPsec will implement auditing. For
the most part, the granularity of auditing is a local matter.
However, several auditable events are identified in the AH and ESP
specifications 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.
8. Use in Systems Supporting Information Flow Security
Information of various sensitivity levels may be carried over a
single network. Information labels (e.g., Unclassified, Company
Proprietary, Secret) [DoD85, DoD87] are often employed to distinguish
such information. The use of labels facilitates segregation of
information, in support of information flow security models, e.g.,
the Bell-LaPadula model [BL73]. Such models, and corresponding
supporting technology, are designed to prevent the unauthorized flow
of sensitive information, even in the face of Trojan Horse attacks.
Conventional, discretionary access control (DAC) mechanisms, e.g.,
based on access control lists, generally are not sufficient to
support such policies, and thus facilities such as the SPD do not
suffice in such environments.
In the military context, technology that supports such models is
often referred to as multi-level security (MLS). Computers and
networks often are designated "multi-level secure" if they support
the separation of labelled data in conjunction with information flow
security policies. Although such technology is more broadly
applicable than just military applications, this document uses the
acronym "MLS" to designate the technology, consistent with much
extant literature.
IPsec mechanisms can easily support MLS networking. MLS networking
requires the use of strong Mandatory Access Controls (MAC), which
unprivileged users or unprivileged processes are incapable of
controlling or violating. This section pertains only to the use of
these IP security mechanisms in MLS (information flow security
policy) environments. Nothing in this section applies to systems not
claiming to provide MLS.
As used in this section, "sensitivity information" might include
implementation-defined hierarchic levels, categories, and/or
releasability information.
AH can be used to provide strong authentication in support of
mandatory access control decisions in MLS environments. If explicit
IP sensitivity information (e.g., IPSO [Ken91]) is used and
confidentiality is not considered necessary within the particular
operational environment, AH can be used to authenticate the binding
between sensitivity labels in the IP header and the IP payload
(including user data). This is a significant improvement over
labeled IPv4 networks where the sensitivity information is trusted
even though there is no authentication or cryptographic binding of
the information to the IP header and user data. IPv4 networks might
or might not use explicit labelling. IPv6 will normally use implicit
sensitivity information that is part of the IPsec Security
Association but not transmitted with each packet instead of using
explicit sensitivity information. All explicit IP sensitivity
information MUST be authenticated using either ESP, AH, or both.
Encryption is useful and can be desirable even when all of the hosts
are within a protected environment, for example, behind a firewall or
disjoint from any external connectivity. ESP can be used, in
conjunction with appropriate key management and encryption
algorithms, in support of both DAC and MAC. (The choice of
encryption and authentication algorithms, and the assurance level of
an IPsec implementation will determine the environments in which an
implementation may be deemed sufficient to satisfy MLS requirements.)
Key management can make use of sensitivity information to provide
MAC. IPsec implementations on systems claiming to provide MLS SHOULD
be capable of using IPsec to provide MAC for IP-based communications.
8.1 Relationship Between Security Associations and Data Sensitivity
Both the Encapsulating Security Payload and the Authentication Header
can be combined with appropriate Security Association policies to
provide multi-level secure networking. In this case each SA (or SA
bundle) is normally used for only a single instance of sensitivity
information. For example, "PROPRIETARY - Internet Engineering" must
be associated with a different SA (or SA bundle) from "PROPRIETARY -
Finance".
8.2 Sensitivity Consistency Checking
An MLS implementation (both host and router) MAY associate
sensitivity information, or a range of sensitivity information with
an interface, or a configured IP address with its associated prefix
(the latter is sometimes referred to as a logical interface, or an
interface alias). If such properties exist, an implementation SHOULD
compare the sensitivity information associated with the packet
against the sensitivity information associated with the interface or
address/prefix from which the packet arrived, or through which the
packet will depart. This check will either verify that the
sensitivities match, or that the packet's sensitivity falls within
the range of the interface or address/prefix.
The checking SHOULD be done on both inbound and outbound processing.
8.3 Additional MLS Attributes for Security Association Databases
Section 4.4 discussed two Security Association databases (the
Security Policy Database (SPD) and the Security Association Database
(SAD)) and the associated policy selectors and SA attributes. MLS