Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 2401

Security Architecture for the Internet Protocol

Pages: 66
Obsoletes:  1825
Obsoleted by:  4301
Updated by:  3168
Part 4 of 4 – Pages 45 to 66
First   Prev   None

ToP   noToC   RFC2401 - Page 45   prevText
Appendix A -- Glossary

   This section provides definitions for several key terms that are
   employed in this document.  Other documents provide additional
   definitions and background information relevant to this technology,
   e.g., [VK83, HA94].  Included in this glossary are generic security
   service and security mechanism terms, plus IPsec-specific terms.

     Access Control
        Access control is a security service that prevents unauthorized
        use of a resource, including the prevention of use of a resource
        in an unauthorized manner.  In the IPsec context, the resource
        to which access is being controlled is often:
                o for a host, computing cycles or data
                o for a security gateway, a network behind the gateway
                  bandwidth on that network.

        [See "Integrity" below]

        This term is used informally to refer to the combination of two
        nominally distinct security services, data origin authentication
        and connectionless integrity.  See the definitions below for
        each of these services.

        Availability, when viewed as a security service, addresses the
        security concerns engendered by attacks against networks that
        deny or degrade service.  For example, in the IPsec context, the
        use of anti-replay mechanisms in AH and ESP support

        Confidentiality is the security service that protects data from
        unauthorized disclosure.  The primary confidentiality concern in
        most instances is unauthorized disclosure of application level
        data, but disclosure of the external characteristics of
        communication also can be a concern in some circumstances.
        Traffic flow confidentiality is the service that addresses this
        latter concern by concealing source and destination addresses,
        message length, or frequency of communication.  In the IPsec
        context, using ESP in tunnel mode, especially at a security
        gateway, can provide some level of traffic flow confidentiality.
        (See also traffic analysis, below.)
ToP   noToC   RFC2401 - Page 46
        Encryption is a security mechanism used to transform data from
        an intelligible form (plaintext) into an unintelligible form
        (ciphertext), to provide confidentiality.  The inverse
        transformation process is designated "decryption".  Oftimes the
        term "encryption" is used to generically refer to both

     Data Origin Authentication
        Data origin authentication is a security service that verifies
        the identity of the claimed source of data.  This service is
        usually bundled with connectionless integrity service.

        Integrity is a security service that ensures that modifications
        to data are detectable.  Integrity comes in various flavors to
        match application requirements.  IPsec supports two forms of
        integrity: connectionless and a form of partial sequence
        integrity.  Connectionless integrity is a service that detects
        modification of an individual IP datagram, without regard to the
        ordering of the datagram in a stream of traffic.  The form of
        partial sequence integrity offered in IPsec is referred to as
        anti-replay integrity, and it detects arrival of duplicate IP
        datagrams (within a constrained window).  This is in contrast to
        connection-oriented integrity, which imposes more stringent
        sequencing requirements on traffic, e.g., to be able to detect
        lost or re-ordered messages.  Although authentication and
        integrity services often are cited separately, in practice they
        are intimately connected and almost always offered in tandem.

     Security Association (SA)
        A simplex (uni-directional) logical connection, created for
        security purposes.  All traffic traversing an SA is provided the
        same security processing.  In IPsec, an SA is an internet layer
        abstraction implemented through the use of AH or ESP.

     Security Gateway
        A security gateway is an intermediate system that acts as the
        communications interface between two networks.  The set of hosts
        (and networks) on the external side of the security gateway is
        viewed as untrusted (or less trusted), while the networks and
        hosts and on the internal side are viewed as trusted (or more
        trusted).  The internal subnets and hosts served by a security
        gateway are presumed to be trusted by virtue of sharing a
        common, local, security administration.  (See "Trusted
        Subnetwork" below.) In the IPsec context, a security gateway is
        a point at which AH and/or ESP is implemented in order to serve
ToP   noToC   RFC2401 - Page 47
        a set of internal hosts, providing security services for these
        hosts when they communicate with external hosts also employing
        IPsec (either directly or via another security gateway).

        Acronym for "Security Parameters Index".  The combination of a
        destination address, a security protocol, and an SPI uniquely
        identifies a security association (SA, see above).  The SPI is
        carried in AH and ESP protocols to enable the receiving system
        to select the SA under which a received packet will be
        processed.  An SPI has only local significance, as defined by
        the creator of the SA (usually the receiver of the packet
        carrying the SPI); thus an SPI is generally viewed as an opaque
        bit string.  However, the creator of an SA may choose to
        interpret the bits in an SPI to facilitate local processing.

     Traffic Analysis
        The analysis of network traffic flow for the purpose of deducing
        information that is useful to an adversary.  Examples of such
        information are frequency of transmission, the identities of the
        conversing parties, sizes of packets, flow identifiers, etc.

     Trusted Subnetwork
        A subnetwork containing hosts and routers that trust each other
        not to engage in active or passive attacks.  There also is an
        assumption that the underlying communications channel (e.g., a
        LAN or CAN) isn't being attacked by other means.
ToP   noToC   RFC2401 - Page 48
Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues

B.1 DF bit

   In cases where a system (host or gateway) adds an encapsulating
   header (e.g., ESP tunnel), should/must the DF bit in the original
   packet be copied to the encapsulating header?

   Fragmenting seems correct for some situations, e.g., it might be
   appropriate to fragment packets over a network with a very small MTU,
   e.g., a packet radio network, or a cellular phone hop to mobile node,
   rather than propagate back a very small PMTU for use over the rest of
   the path.  In other situations, it might be appropriate to set the DF
   bit in order to get feedback from later routers about PMTU
   constraints which require fragmentation.  The existence of both of
   these situations argues for enabling a system to decide whether or
   not to fragment over a particular network "link", i.e., for requiring
   an implementation to be able to copy the DF bit (and to process ICMP
   PMTU messages), but making it an option to be selected on a per
   interface basis.  In other words, an administrator should be able to
   configure the router's treatment of the DF bit (set, clear, copy from
   encapsulated header) for each interface.

   Note: If a bump-in-the-stack implementation of IPsec attempts to
   apply different IPsec algorithms based on source/destination ports,
   it will be difficult to apply Path MTU adjustments.

B.2 Fragmentation

   If required, IP fragmentation occurs after IPsec processing within an
   IPsec implementation.  Thus, transport mode AH or ESP is applied only
   to whole IP datagrams (not to IP fragments).  An IP packet to which
   AH or ESP has been applied may itself be fragmented by routers en
   route, and such fragments MUST be reassembled prior to IPsec
   processing at a receiver.  In tunnel mode, AH or ESP is applied to an
   IP packet, the payload of which may be a fragmented IP packet.  For
   example, a security gateway, "bump-in-the-stack" (BITS), or "bump-
   in-the-wire" (BITW) IPsec implementation may apply tunnel mode AH to
   such fragments.  Note that BITS or BITW implementations are examples
   of where a host IPsec implementation might receive fragments to which
   tunnel mode is to be applied.  However, if transport mode is to be
   applied, then these implementations MUST reassemble the fragments
   prior to applying IPsec.
ToP   noToC   RFC2401 - Page 49
   NOTE: IPsec always has to figure out what the encapsulating IP header
   fields are.  This is independent of where you insert IPsec and is
   intrinsic to the definition of IPsec.  Therefore any IPsec
   implementation that is not integrated into an IP implementation must
   include code to construct the necessary IP headers (e.g., IP2):

        o AH-tunnel --> IP2-AH-IP1-Transport-Data
        o ESP-tunnel -->  IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer


   Overall, the fragmentation/reassembly approach described above works
   for all cases examined.

                              AH Xport   AH Tunnel  ESP Xport  ESP Tunnel
 Implementation approach      IPv4 IPv6  IPv4 IPv6  IPv4 IPv6  IPv4 IPv6
 -----------------------      ---- ----  ---- ----  ---- ----  ---- ----
 Hosts (integr w/ IP stack)     Y    Y     Y    Y     Y    Y     Y    Y
 Hosts (betw/ IP and drivers)   Y    Y     Y    Y     Y    Y     Y    Y
 S. Gwy (integr w/ IP stack)               Y    Y                Y    Y
 Outboard crypto processor *

        * If the crypto processor system has its own IP address, then it
          is covered by the security gateway case.  This box receives
          the packet from the host and performs IPsec processing.  It
          has to be able to handle the same AH, ESP, and related
          IPv4/IPv6 tunnel processing that a security gateway would have
          to handle.  If it doesn't have it's own address, then it is
          similar to the bump-in-the stack implementation between IP and
          the network drivers.

   The following analysis assumes that:

        1. There is only one IPsec module in a given system's stack.
           There isn't an IPsec module A (adding ESP/encryption and
           thus) hiding the transport protocol, SRC port, and DEST port
           from IPsec module B.
        2. There are several places where IPsec could be implemented (as
           shown in the table above).
                a. Hosts with integration of IPsec into the native IP
                   implementation.  Implementer has access to the source
                   for the stack.
                b. Hosts with bump-in-the-stack implementations, where
                   IPsec is implemented between IP and the local network
                   drivers.  Source access for stack is not available;
                   but there are well-defined interfaces that allows the
                   IPsec code to be incorporated into the system.
ToP   noToC   RFC2401 - Page 50
                c. Security gateways and outboard crypto processors with
                   integration of IPsec into the stack.
        3. Not all of the above approaches are feasible in all hosts.
           But it was assumed that for each approach, there are some
           hosts for whom the approach is feasible.

   For each of the above 3 categories, there are IPv4 and IPv6, AH
   transport and tunnel modes, and ESP transport and tunnel modes -- for
   a total of 24 cases (3 x 2 x 4).

   Some header fields and interface fields are listed here for ease of
   reference -- they're not in the header order, but instead listed to
   allow comparison between the columns.  (* = not covered by AH
   authentication.  ESP authentication doesn't cover any headers that
   precede it.)

                                             IP/Transport Interface
             IPv4            IPv6            (RFC 1122 -- Sec 3.4)
             ----            ----            ----------------------
             Version = 4     Version = 6
             Header Len
             *TOS            Class,Flow Lbl  TOS
             Packet Len      Payload Len     Len
             ID                              ID (optional)
             *Flags                          DF
             *TTL            *Hop Limit      TTL
             Protocol        Next Header
             Src Address     Src Address     Src Address
             Dst Address     Dst Address     Dst Address
             Options?        Options?        Opt

             ? = AH covers Option-Type and Option-Length, but
                 might not cover Option-Data.

   The results for each of the 20 cases is shown below ("works" = will
   work if system fragments after outbound IPsec processing, reassembles
   before inbound IPsec processing).  Notes indicate implementation

    a. Hosts (integrated into IP stack)
          o AH-transport  --> (IP1-AH-Transport-Data)
                    - IPv4 -- works
                    - IPv6 -- works
          o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
                    - IPv4 -- works
                    - IPv6 -- works
ToP   noToC   RFC2401 - Page 51
          o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer)
                    - IPv4 -- works
                    - IPv6 -- works
          o ESP-tunnel -->  (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer)
                    - IPv4 -- works
                    - IPv6 -- works

    b. Hosts (Bump-in-the-stack) -- put IPsec between IP layer and
       network drivers.  In this case, the IPsec module would have to do
       something like one of the following for fragmentation and
            - do the fragmentation/reassembly work itself and
              send/receive the packet directly to/from the network
              layer.  In AH or ESP transport mode, this is fine.  In AH
              or ESP tunnel mode where the tunnel end is at the ultimate
              destination, this is fine.  But in AH or ESP tunnel modes
              where the tunnel end is different from the ultimate
              destination and where the source host is multi-homed, this
              approach could result in sub-optimal routing because the
              IPsec module may be unable to obtain the information
              needed (LAN interface and next-hop gateway) to direct the
              packet to the appropriate network interface.  This is not
              a problem if the interface and next-hop gateway are the
              same for the ultimate destination and for the tunnel end.
              But if they are different, then IPsec would need to know
              the LAN interface and the next-hop gateway for the tunnel
              end.  (Note: The tunnel end (security gateway) is highly
              likely to be on the regular path to the ultimate
              destination.  But there could also be more than one path
              to the destination, e.g., the host could be at an
              organization with 2 firewalls.  And the path being used
              could involve the less commonly chosen firewall.)  OR
            - pass the IPsec'd packet back to the IP layer where an
              extra IP header would end up being pre-pended and the
              IPsec module would have to check and let IPsec'd fragments
              go by.
            - pass the packet contents to the IP layer in a form such
              that the IP layer recreates an appropriate IP header

       At the network layer, the IPsec module will have access to the
       following selectors from the packet -- SRC address, DST address,
       Next Protocol, and if there's a transport layer header --> SRC
       port and DST port.  One cannot assume IPsec has access to the
       Name.  It is assumed that the available selector information is
       sufficient to figure out the relevant Security Policy entry and
       Security Association(s).
ToP   noToC   RFC2401 - Page 52
          o AH-transport  --> (IP1-AH-Transport-Data)
                    - IPv4 -- works
                    - IPv6 -- works
          o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
                    - IPv4 -- works
                    - IPv6 -- works
          o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer)
                    - IPv4 -- works
                    - IPv6 -- works
          o ESP-tunnel -->  (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer)
                    - IPv4 -- works
                    - IPv6 -- works

    c. Security gateways -- integrate IPsec into the IP stack

       NOTE: The IPsec module will have access to the following
       selectors from the packet -- SRC address, DST address, Next
       Protocol, and if there's a transport layer header --> SRC port
       and DST port.  It won't have access to the User ID (only Hosts
       have access to User ID information.)  Unlike some Bump-in-the-
       stack implementations, security gateways may be able to look up
       the Source Address in the DNS to provide a System Name, e.g., in
       situations involving use of dynamically assigned IP addresses in
       conjunction with dynamically updated DNS entries.  It also won't
       have access to the transport layer information if there is an ESP
       header, or if it's not the first fragment of a fragmented
       message.  It is assumed that the available selector information
       is sufficient to figure out the relevant Security Policy entry
       and Security Association(s).

          o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
                    - IPv4 -- works
                    - IPv6 -- works
          o ESP-tunnel -->  (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer)
                    - IPv4 -- works
                    - IPv6 -- works


B.3 Path MTU Discovery

   As mentioned earlier, "ICMP PMTU" refers to an ICMP message used for
   Path MTU Discovery.

   The legend for the diagrams below in B.3.1 and B.3.3 (but not B.3.2)

        ==== = security association (AH or ESP, transport or tunnel)
ToP   noToC   RFC2401 - Page 53
        ---- = connectivity (or if so labelled, administrative boundary)
        .... = ICMP message (hereafter referred to as ICMP PMTU) for

                - 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 (RFC 1885):
                - Type = 2 (Packet Too Big)
                - Code = 0 (Fragmentation needed and DF set)
                - Next-Hop MTU in the 32 bit MTU field of the ICMP6

        Hx   = host x
        Rx   = router x
        SGx  = security gateway x
        X*   = X supports IPsec

B.3.1 Identifying the Originating Host(s)

The amount of information returned with the ICMP message is limited
and this affects what selectors are available to identify security
associations, originating hosts, etc. for use in further propagating
the PMTU information.

In brief...  An ICMP message must contain the following information
from the "offending" packet:
        - IPv4 (RFC 792) --  IP header plus a minimum of 64 bits

Accordingly, in the IPv4 context, an ICMP PMTU may identify only the
first (outermost) security association.  This is because the ICMP
PMTU may contain only 64 bits of the "offending" packet beyond the IP
header, which would capture only the first SPI from AH or ESP.  In
the IPv6 context, an ICMP PMTU will probably provide all the SPIs and
the selectors in the IP header, but maybe not the SRC/DST ports (in
the transport header) or the encapsulated (TCP, UDP, etc.) protocol.
Moreover, if ESP is used, the transport ports and protocol selectors
may be encrypted.

Looking at the diagram below of a security gateway tunnel (as
mentioned elsewhere, security gateways do not use transport mode)...
ToP   noToC   RFC2401 - Page 54
     H1   ===================           H3
       \  |                 |          /
   H0 -- SG1* ---- R1 ---- SG2* ---- R2 -- H5
       /  ^        |                   \
     H2   |........|                    H4

   Suppose that the security policy for SG1 is to use a single SA to SG2
   for all the traffic between hosts H0, H1, and H2 and hosts H3, H4,
   and H5.  And suppose H0 sends a data packet to H5 which causes R1 to
   send an ICMP PMTU message to SG1.  If the PMTU message has only the
   SPI, SG1 will be able to look up the SA and find the list of possible
   hosts (H0, H1, H2, wildcard); but SG1 will have no way to figure out
   that H0 sent the traffic that triggered the ICMP PMTU message.

      original        after IPsec     ICMP
      packet          processing      packet
      --------        -----------     ------
                                      IP-3 header (S = R1, D = SG1)
                                      ICMP header (includes PMTU)
                      IP-2 header     IP-2 header (S = SG1, D = SG2)
                      ESP header      minimum of 64 bits of ESP hdr (*)
      IP-1 header     IP-1 header
      TCP header      TCP header
      TCP data        TCP data
                      ESP trailer

      (*) The 64 bits will include enough of the ESP (or AH) header to
          include the SPI.
              - ESP -- SPI (32 bits), Seq number (32 bits)
              - AH -- Next header (8 bits), Payload Len (8 bits),
                Reserved (16 bits), SPI (32 bits)

   This limitation on the amount of information returned with an ICMP
   message creates a problem in identifying the originating hosts for
   the packet (so as to know where to further propagate the ICMP PMTU
   information).  If the ICMP message contains only 64 bits of the IPsec
   header (minimum for IPv4), then the IPsec selectors (e.g., Source and
   Destination addresses, Next Protocol, Source and Destination ports,
   etc.) will have been lost.  But the ICMP error message will still
   provide SG1 with the SPI, the PMTU information and the source and
   destination gateways for the relevant security association.

   The destination security gateway and SPI uniquely define a security
   association which in turn defines a set of possible originating
   hosts.  At this point, SG1 could:
ToP   noToC   RFC2401 - Page 55
   a. send the PMTU information to all the possible originating hosts.
      This would not work well if the host list is a wild card or if
      many/most of the hosts weren't sending to SG1; but it might work
      if the SPI/destination/etc mapped to just one or a small number of
   b. store the PMTU with the SPI/etc and wait until the next packet(s)
      arrive from the originating host(s) for the relevant security
      association.  If it/they 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 originating host(s) the ICMP
      message(s) about the problem.  This involves a delay in notifying
      the originating host(s), but avoids the problems of (a).

   Since only the latter approach is feasible in all instances, a
   security gateway MUST provide such support, as an option.  However,
   if the ICMP message contains more information from the original
   packet, then there may be enough 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, and 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.  NOTE: The Next Protocol
   field may not be contained in the ICMP message and the use of ESP
   encryption may hide the selector fields that have been encrypted.

B.3.2 Calculation of PMTU

   The calculation of PMTU from an ICMP PMTU has to take into account
   the addition of any IPsec header by H1 -- AH and/or ESP transport, or
   ESP or AH tunnel.  Within a single host, multiple applications may
   share an SPI and nesting of security associations may occur.  (See
   Section 4.5 Basic Combinations of Security Associations for
   description of the combinations that MUST be supported).  The diagram
   below illustrates an example of security associations between a pair
   of hosts (as viewed from the perspective of one of the hosts.)  (ESPx
   or AHx = transport mode)

           Socket 1 -------------------------|
           Socket 2 (ESPx/SPI-A) ---------- AHx (SPI-B) -- Internet

   In order to figure out the PMTU for each socket that maps to SPI-B,
   it will be necessary to have backpointers from SPI-B to each of the 2
   paths that lead to it -- Socket 1 and Socket 2/SPI-A.
ToP   noToC   RFC2401 - Page 56
B.3.3 Granularity of Maintaining PMTU Data

   In hosts, the granularity with which PMTU ICMP processing can be done
   differs depending on the implementation situation.  Looking at a
   host, there are three situations that are of interest with respect to
   PMTU issues:

   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 the other cases, the
   IP layer will maintain PMTU data at the granularity of Source and
   Destination IP addresses (and optionally TOS/Class), as described in
   RFC 1191.  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).  The examples below illustrate

   In cases (a) and (b)...  Suppose you have the following situation.
   H1 is sending to H2 and the packet to be sent from R1 to R2 exceeds
   the PMTU of the network hop between them.

                 |                                |
                H1* --- R1 ----- R2 ---- R3 ---- H2*
                 ^       |

   If R1 is configured to not fragment subscriber traffic, then R1 sends
   an ICMP PMTU message with the appropriate PMTU to H1.  H1's
   processing would vary with the nature of the implementation.  In case
   (a) (native IP), the security services are bound to sockets or the
   equivalent.  Here the IP/IPsec implementation in H1 can store/update
   the PMTU for the associated socket.  In case (b), the IP layer in H1
   can store/update the PMTU but only at the granularity of Source and
   Destination addresses and possibly TOS/Class, as noted above.  So the
   result may be sub-optimal, since the PMTU for a given
   SRC/DST/TOS/Class will be the subtraction of the largest amount of
   IPsec header used for any communication association between a given
   source and destination.
ToP   noToC   RFC2401 - Page 57
   In case (c), there has to be a security gateway to have any IPsec
   processing.  So suppose you have the following situation.  H1 is
   sending to H2 and the packet to be sent from SG1 to R exceeds the
   PMTU of the network hop between them.

                         |              |
                H1 ---- SG1* --- R --- SG2* ---- H2
                 ^       |

   As described above for case (b), the IP layer in H1 can store/update
   the PMTU but only at the granularity of Source and Destination
   addresses, and possibly TOS/Class.  So the result may be sub-optimal,
   since the PMTU for a given SRC/DST/TOS/Class will be the subtraction
   of the largest amount of IPsec header used for any communication
   association between a given source and destination.

B.3.4 Per Socket Maintenance of PMTU Data

   Implementation of the calculation of PMTU (Section B.3.2) and support
   for PMTUs at the granularity of individual "communication
   associations" (Section B.3.3) 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
   determination of the overhead SHOULD be determined by analysis of the
   SPI and any other selector information present in a returned ICMP
   PMTU message.

B.3.5 Delivery of PMTU Data to the Transport Layer

   The host mechanism for getting the updated PMTU to the transport
   layer is unchanged, as specified in RFC 1191 (Path MTU Discovery).

B.3.6 Aging of PMTU Data

   This topic is covered in Section
ToP   noToC   RFC2401 - Page 58
Appendix C -- Sequence Space Window Code Example

   This appendix contains a routine that implements a bitmask check for
   a 32 packet window.  It was provided by James Hughes
   ( and Harry Varnis (
   and is intended as an implementation example.  Note that this code
   both checks for a replay and updates the window.  Thus the algorithm,
   as shown, should only be called AFTER the packet has been
   authenticated.  Implementers might wish to consider splitting the
   code to do the check for replays before computing the ICV.  If the
   packet is not a replay, the code would then compute the ICV, (discard
   any bad packets), and if the packet is OK, update the window.

#include <stdio.h>
#include <stdlib.h>
typedef unsigned long u_long;

enum {
    ReplayWindowSize = 32

u_long bitmap = 0;                 /* session state - must be 32 bits */
u_long lastSeq = 0;                     /* session state */

/* Returns 0 if packet disallowed, 1 if packet permitted */
int ChkReplayWindow(u_long seq);

int ChkReplayWindow(u_long seq) {
    u_long diff;

    if (seq == 0) return 0;             /* first == 0 or wrapped */
    if (seq > lastSeq) {                /* new larger sequence number */
        diff = seq - lastSeq;
        if (diff < ReplayWindowSize) {  /* In window */
            bitmap <<= diff;
            bitmap |= 1;                /* set bit for this packet */
        } else bitmap = 1;          /* This packet has a "way larger" */
        lastSeq = seq;
        return 1;                       /* larger is good */
    diff = lastSeq - seq;
    if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */
    if (bitmap & ((u_long)1 << diff)) return 0; /* already seen */
    bitmap |= ((u_long)1 << diff);              /* mark as seen */
    return 1;                           /* out of order but good */

char string_buffer[512];
ToP   noToC   RFC2401 - Page 59
#define STRING_BUFFER_SIZE sizeof(string_buffer)

int main() {
    int result;
    u_long last, current, bits;

    printf("Input initial state (bits in hex, last msgnum):\n");
    if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0);
    sscanf(string_buffer, "%lx %lu", &bits, &last);
    if (last != 0)
    bits |= 1;
    bitmap = bits;
    lastSeq = last;
    printf("bits:%08lx last:%lu\n", bitmap, lastSeq);
    printf("Input value to test (current):\n");

    while (1) {
        if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break;
        sscanf(string_buffer, "%lu", &current);
        result = ChkReplayWindow(current);
        printf("%-3s", result ? "OK" : "BAD");
        printf(" bits:%08lx last:%lu\n", bitmap, lastSeq);
    return 0;
ToP   noToC   RFC2401 - Page 60
Appendix D -- Categorization of ICMP messages

The tables below characterize ICMP messages as being either host
generated, router generated, both, unassigned/unknown.  The first set
are IPv4.  The second set are IPv6.


Type    Name/Codes                                             Reference
  3     Destination Unreachable
         2  Protocol Unreachable                               [RFC792]
         3  Port Unreachable                                   [RFC792]
         8  Source Host Isolated                               [RFC792]
        14  Host Precedence Violation                          [RFC1812]
 10     Router Selection                                       [RFC1256]

Type    Name/Codes                                             Reference
  3     Destination Unreachable
         0  Net Unreachable                                    [RFC792]
         4  Fragmentation Needed, Don't Fragment was Set       [RFC792]
         5  Source Route Failed                                [RFC792]
         6  Destination Network Unknown                        [RFC792]
         7  Destination Host Unknown                           [RFC792]
         9  Comm. w/Dest. Net. is Administratively Prohibited  [RFC792]
        11  Destination Network Unreachable for Type of Service[RFC792]
  5     Redirect
         0  Redirect Datagram for the Network (or subnet)      [RFC792]
         2  Redirect Datagram for the Type of Service & Network[RFC792]
  9     Router Advertisement                                   [RFC1256]
 18     Address Mask Reply                                     [RFC950]
ToP   noToC   RFC2401 - Page 61
Type    Name/Codes                                             Reference
  0     Echo Reply                                             [RFC792]
  3     Destination Unreachable
         1  Host Unreachable                                   [RFC792]
        10  Comm. w/Dest. Host is Administratively Prohibited  [RFC792]
        12  Destination Host Unreachable for Type of Service   [RFC792]
        13  Communication Administratively Prohibited          [RFC1812]
        15  Precedence cutoff in effect                        [RFC1812]
  4     Source Quench                                          [RFC792]
  5     Redirect
         1  Redirect Datagram for the Host                     [RFC792]
         3  Redirect Datagram for the Type of Service and Host [RFC792]
  6     Alternate Host Address                                 [JBP]
  8     Echo                                                   [RFC792]
 11     Time Exceeded                                          [RFC792]
 12     Parameter Problem                              [RFC792,RFC1108]
 13     Timestamp                                              [RFC792]
 14     Timestamp Reply                                        [RFC792]
 15     Information Request                                    [RFC792]
 16     Information Reply                                      [RFC792]
 17     Address Mask Request                                   [RFC950]
 30     Traceroute                                             [RFC1393]
 31     Datagram Conversion Error                              [RFC1475]
 32     Mobile Host Redirect                                   [Johnson]
 39     SKIP                                                   [Markson]
 40     Photuris                                               [Simpson]

Type    Name/Codes                                             Reference
  1     Unassigned                                             [JBP]
  2     Unassigned                                             [JBP]
  7     Unassigned                                             [JBP]
 19     Reserved (for Security)                                [Solo]
 20-29  Reserved (for Robustness Experiment)                   [ZSu]
 33     IPv6 Where-Are-You                                     [Simpson]
 34     IPv6 I-Am-Here                                         [Simpson]
 35     Mobile Registration Request                            [Simpson]
 36     Mobile Registration Reply                              [Simpson]
 37     Domain Name Request                                    [Simpson]
 38     Domain Name Reply                                      [Simpson]
 41-255 Reserved                                               [JBP]
ToP   noToC   RFC2401 - Page 62

Type    Name/Codes                                             Reference
  1     Destination Unreachable                                [RFC 1885]
         4  Port Unreachable

Type    Name/Codes                                             Reference
  1     Destination Unreachable                                [RFC1885]
         0  No Route to Destination
         1  Comm. w/Destination is Administratively Prohibited
         2  Not a Neighbor
         3  Address Unreachable
  2     Packet Too Big                                         [RFC1885]
  3     Time Exceeded                                          [RFC1885]
         0  Hop Limit Exceeded in Transit
         1  Fragment reassembly time exceeded

Type    Name/Codes                                             Reference
  4     Parameter Problem                                      [RFC1885]
         0  Erroneous Header Field Encountered
         1  Unrecognized Next Header Type Encountered
         2  Unrecognized IPv6 Option Encountered
ToP   noToC   RFC2401 - Page 63

   [BL73]    Bell, D.E. & LaPadula, L.J., "Secure Computer Systems:
             Mathematical Foundations and Model", Technical Report M74-
             244, The MITRE Corporation, Bedford, MA, May 1973.

   [Bra97]   Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Level", BCP 14, RFC 2119, March 1997.

   [DoD85]   US National Computer Security Center, "Department of
             Defense Trusted Computer System Evaluation Criteria", DoD
             5200.28-STD, US Department of Defense, Ft. Meade, MD.,
             December 1985.

   [DoD87]   US National Computer Security Center, "Trusted Network
             Interpretation of the Trusted Computer System Evaluation
             Criteria", NCSC-TG-005, Version 1, US Department of
             Defense, Ft. Meade, MD., 31 July 1987.

   [HA94]    Haller, N., and R. Atkinson, "On Internet Authentication",
             RFC 1704, October 1994.

   [HC98]    Harkins, D., and D. Carrel, "The Internet Key Exchange
             (IKE)", RFC 2409, November 1998.

   [HM97]    Harney, H., and C.  Muckenhirn, "Group Key Management
             Protocol (GKMP) Architecture", RFC 2094, July 1997.

   [ISO]     ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC
             DIS 11577, International Standards Organisation, Geneva,
             Switzerland, 29 November 1992.

   [IB93]    John Ioannidis and Matt Blaze, "Architecture and
             Implementation of Network-layer Security Under Unix",
             Proceedings of USENIX Security Symposium, Santa Clara, CA,
             October 1993.

   [IBK93]   John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-
             Layer Security for IP", presentation at the Spring 1993
             IETF Meeting, Columbus, Ohio

   [KA98a]   Kent, S., and R. Atkinson, "IP Authentication Header", RFC
             2402, November 1998.

   [KA98b]   Kent, S., and R. Atkinson, "IP Encapsulating Security
             Payload (ESP)", RFC 2406, November 1998.
ToP   noToC   RFC2401 - Page 64
   [Ken91]   Kent, S., "US DoD Security Options for the Internet
             Protocol", RFC 1108, November 1991.

   [MSST97]  Maughan, D., Schertler, M., Schneider, M., and J. Turner,
             "Internet Security Association and Key Management Protocol
             (ISAKMP)", RFC 2408, November 1998.

   [Orm97]   Orman, H., "The OAKLEY Key Determination Protocol", RFC
             2412, November 1998.

   [Pip98]   Piper, D., "The Internet IP Security Domain of
             Interpretation for ISAKMP", RFC 2407, November 1998.

   [Sch94]   Bruce Schneier, Applied Cryptography, Section 8.6, John
             Wiley & Sons, New York, NY, 1994.

   [SDNS]    SDNS Secure Data Network System, Security Protocol 3, SP3,
             Document SDN.301, Revision 1.5, 15 May 1989, published in
             NIST Publication NIST-IR-90-4250, February 1990.

   [SMPT98]  Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP
             Payload Compression Protocol (IPComp)", RFC 2393, August

   [TDG97]   Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
             Document Roadmap", RFC 2411, November 1998.

   [VK83]    V.L. Voydock & S.T. Kent, "Security Mechanisms in High-
             level Networks", ACM Computing Surveys, Vol. 15, No. 2,
             June 1983.


   The views and specification expressed in this document are those of
   the authors and are not necessarily those of their employers.  The
   authors and their employers specifically disclaim responsibility for
   any problems arising from correct or incorrect implementation or use
   of this design.
ToP   noToC   RFC2401 - Page 65
Author Information

   Stephen Kent
   BBN Corporation
   70 Fawcett Street
   Cambridge, MA  02140

   Phone: +1 (617) 873-3988

   Randall Atkinson
   @Home Network
   425 Broadway
   Redwood City, CA 94063

   Phone: +1 (415) 569-5000
ToP   noToC   RFC2401 - Page 66
Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an