Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4301

Security Architecture for the Internet Protocol

Pages: 101
Proposed Standard
Errata
Obsoletes:  2401
Updates:  3168
Updated by:  60407619
Part 3 of 4 – Pages 50 to 75
First   Prev   Next

Top   ToC   RFC4301 - Page 50   prevText

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
Top   ToC   RFC4301 - Page 51
   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.
Top   ToC   RFC4301 - Page 52

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.
Top   ToC   RFC4301 - Page 53
   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
Top   ToC   RFC4301 - Page 54
       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
Top   ToC   RFC4301 - Page 55
       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.
Top   ToC   RFC4301 - Page 56
      (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
Top   ToC   RFC4301 - Page 57
      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.)
Top   ToC   RFC4301 - Page 58
          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.
Top   ToC   RFC4301 - Page 59
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
Top   ToC   RFC4301 - Page 60
   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
Top   ToC   RFC4301 - Page 61
                       (*) = 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
Top   ToC   RFC4301 - Page 62
       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.
Top   ToC   RFC4301 - Page 63
   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.
Top   ToC   RFC4301 - Page 64
   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
Top   ToC   RFC4301 - Page 65
   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
Top   ToC   RFC4301 - Page 66
   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
Top   ToC   RFC4301 - Page 67
   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
Top   ToC   RFC4301 - Page 68
   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
Top   ToC   RFC4301 - Page 69
   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.
Top   ToC   RFC4301 - Page 70

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 message

8.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.
Top   ToC   RFC4301 - Page 71
       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.
Top   ToC   RFC4301 - Page 72

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
Top   ToC   RFC4301 - Page 73
     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.
Top   ToC   RFC4301 - Page 74
   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.
Top   ToC   RFC4301 - Page 75
   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.