5. IP Traffic Processing

   As mentioned in Section 4.4.1 "The Security Policy Database (SPD)",
   the SPD must be consulted during the processing of all traffic
   (INBOUND and OUTBOUND), including non-IPsec traffic.  If no policy is
   found in the SPD that matches the packet (for either inbound or
   outbound traffic), the packet MUST be discarded.

   NOTE: All of the cryptographic algorithms used in IPsec expect their
   input in canonical network byte order (see Appendix in RFC 791) and
   generate their output in canonical network byte order.  IP packets
   are also transmitted in network byte order.

5.1 Outbound IP Traffic Processing

5.1.1 Selecting and Using an SA or SA Bundle

   In a security gateway or BITW implementation (and in many BITS
   implementations), each outbound packet is compared against the SPD to
   determine what processing is required for the packet.  If the packet
   is to be discarded, this is an auditable event.  If the traffic is
   allowed to bypass IPsec processing, the packet continues through
   "normal" processing for the environment in which the IPsec processing
   is taking place.  If IPsec processing is required, the packet is
   either mapped to an existing SA (or SA bundle), or a new SA (or SA
   bundle) is created for the packet.  Since a packet's selectors might
   match multiple policies or multiple extant SAs and since the SPD is
   ordered, but the SAD is not, IPsec MUST:

           1. Match the packet's selector fields against the outbound
              policies in the SPD to locate the first appropriate
              policy, which will point to zero or more SA bundles in the
              SAD.

           2. Match the packet's selector fields against those in the SA
              bundles found in (1) to locate the first SA bundle that
              matches.  If no SAs were found or none match, create an
              appropriate SA bundle and link the SPD entry to the SAD
              entry.  If no key management entity is found, drop the
              packet.

           3. Use the SA bundle found/created in (2) to do the required
              IPsec processing, e.g., authenticate and encrypt.

   In a host IPsec implementation based on sockets, the SPD will be
   consulted whenever a new socket is created, to determine what, if
   any, IPsec processing will be applied to the traffic that will flow
   on that socket.

   NOTE: A compliant implementation MUST not allow instantiation of an
   ESP SA that employs both a NULL encryption and a NULL authentication
   algorithm.  An attempt to negotiate such an SA is an auditable event.

5.1.2 Header Construction for Tunnel Mode

   This section describes the handling of the inner and outer IP
   headers, extension headers, and options for AH and ESP tunnels.  This
   includes how to construct the encapsulating (outer) IP header, how to
   handle fields in the inner IP header, and what other actions should
   be taken.  The general idea is modeled after the one used in RFC
   2003, "IP Encapsulation with IP":

        o The outer IP header Source Address and Destination Address
          identify the "endpoints" of the tunnel (the encapsulator and
          decapsulator).  The inner IP header Source Address and
          Destination Addresses identify the original sender and
          recipient of the datagram, (from the perspective of this
          tunnel), respectively.  (see footnote 3 after the table in
          5.1.2.1 for more details on the encapsulating source IP
          address.)
        o The inner IP header is not changed except to decrement the TTL
          as noted below, and remains unchanged during its delivery to
          the tunnel exit point.
        o No change to IP options or extension headers in the inner
          header occurs during delivery of the encapsulated datagram
          through the tunnel.
        o If need be, other protocol headers such as the IP
          Authentication header may be inserted between the outer IP
          header and the inner IP header.

   The tables in the following sub-sections show the handling for the
   different header/option fields (constructed = the value in the outer
   field is constructed independently of the value in the inner).

5.1.2.1 IPv4 -- Header Construction for Tunnel Mode

                        <-- How Outer Hdr Relates to Inner Hdr -->
                        Outer Hdr at                 Inner Hdr at
   IPv4                 Encapsulator                 Decapsulator
     Header fields:     --------------------         ------------
       version          4 (1)                        no change
       header length    constructed                  no change
       TOS              copied from inner hdr (5)    no change
       total length     constructed                  no change
       ID               constructed                  no change
       flags (DF,MF)    constructed, DF (4)          no change
       fragmt offset    constructed                  no change

       TTL              constructed (2)              decrement (2)
       protocol         AH, ESP, routing hdr         no change
       checksum         constructed                  constructed (2)
       src address      constructed (3)              no change
       dest address     constructed (3)              no change
   Options            never copied                 no change

        1. The IP version in the encapsulating header can be different
           from the value in the inner header.

        2. The TTL in the inner header is decremented by the
           encapsulator prior to forwarding and by the decapsulator if
           it forwards the packet.  (The checksum changes when the TTL
           changes.)

           Note: The decrementing of the TTL is one of the usual actions
           that takes place when forwarding a packet.  Packets
           originating from the same node as the encapsulator do not
           have their TTL's decremented, as the sending node is
           originating the packet rather than forwarding it.

        3. src and dest addresses depend on the SA, which is used to
           determine the dest address which in turn determines which src
           address (net interface) is used to forward the packet.

           NOTE: In principle, the encapsulating IP source address can
           be any of the encapsulator's interface addresses or even an
           address different from any of the encapsulator's IP
           addresses, (e.g., if it's acting as a NAT box) so long as the
           address is reachable through the encapsulator from the
           environment into which the packet is sent.  This does not
           cause a problem because IPsec does not currently have any
           INBOUND processing requirement that involves the Source
           Address of the encapsulating IP header.  So while the
           receiving tunnel endpoint looks at the Destination Address in
           the encapsulating IP header, it only looks at the Source
           Address in the inner (encapsulated) IP header.

        4. configuration determines whether to copy from the inner
           header (IPv4 only), clear or set the DF.

        5. If Inner Hdr is IPv4 (Protocol = 4), copy the TOS.  If Inner
           Hdr is IPv6 (Protocol = 41), map the Class to TOS.

5.1.2.2 IPv6 -- Header Construction for Tunnel Mode

   See previous section 5.1.2 for notes 1-5 indicated by (footnote
   number).

                        <-- How Outer Hdr  Relates Inner Hdr --->
                        Outer Hdr at                 Inner Hdr at
   IPv6                 Encapsulator                 Decapsulator
     Header fields:     --------------------         ------------
       version          6 (1)                        no change
       class            copied or configured (6)     no change
       flow id          copied or configured         no change
       len              constructed                  no change
       next header      AH,ESP,routing hdr           no change
       hop limit        constructed (2)              decrement (2)
       src address      constructed (3)              no change
       dest address     constructed (3)              no change
     Extension headers  never copied                 no change

        6. If Inner Hdr is IPv6 (Next Header = 41), copy the Class.  If
           Inner Hdr is IPv4 (Next Header = 4), map the TOS to Class.

5.2 Processing Inbound IP Traffic

   Prior to performing AH or ESP processing, any IP fragments are
   reassembled.  Each inbound IP datagram to which IPsec processing will
   be applied is identified by the appearance of the AH or ESP values in
   the IP Next Protocol field (or of AH or ESP as an extension header in
   the IPv6 context).

   Note: Appendix C contains sample code for a bitmask check for a 32
   packet window that can be used for implementing anti-replay service.

5.2.1 Selecting and Using an SA or SA Bundle

   Mapping the IP datagram to the appropriate SA is simplified because
   of the presence of the SPI in the AH or ESP header.  Note that the
   selector checks are made on the inner headers not the outer (tunnel)
   headers.  The steps followed are:

           1. Use the packet's destination address (outer IP header),
              IPsec protocol, and SPI to look up the SA in the SAD.  If
              the SA lookup fails, drop the packet and log/report the
              error.

           2. Use the SA found in (1) to do the IPsec processing, e.g.,
              authenticate and decrypt.  This step includes matching the
              packet's (Inner Header if tunneled) selectors to the
              selectors in the SA.  Local policy determines the
              specificity of the SA selectors (single value, list,
              range, wildcard).  In general, a packet's source address
              MUST match the SA selector value.  However, an ICMP packet
              received on a tunnel mode SA may have a source address

              other than that bound to the SA and thus such packets
              should be permitted as exceptions to this check.  For an
              ICMP packet, the selectors from the enclosed problem
              packet (the source and destination addresses and ports
              should be swapped) should be checked against the selectors
              for the SA.  Note that some or all of these selectors may
              be inaccessible because of limitations on how many bits of
              the problem packet the ICMP packet is allowed to carry or
              due to encryption.  See Section 6.

              Do (1) and (2) for every IPsec header until a Transport
              Protocol Header or an IP header that is NOT for this
              system is encountered.  Keep track of what SAs have been
              used and their order of application.

           3. Find an incoming policy in the SPD that matches the
              packet.  This could be done, for example, by use of
              backpointers from the SAs to the SPD or by matching the
              packet's selectors (Inner Header if tunneled) against
              those of the policy entries in the SPD.

           4. Check whether the required IPsec processing has been
              applied, i.e., verify that the SA's found in (1) and (2)
              match the kind and order of SAs required by the policy
              found in (3).

              NOTE: The correct "matching" policy will not necessarily
              be the first inbound policy found.  If the check in (4)
              fails, steps (3) and (4) are repeated until all policy
              entries have been checked or until the check succeeds.

   At the end of these steps, pass the resulting packet to the Transport
   Layer or forward the packet.  Note that any IPsec headers processed
   in these steps may have been removed, but that this information,
   i.e., what SAs were used and the order of their application, may be
   needed for subsequent IPsec or firewall processing.

   Note that in the case of a security gateway, if forwarding causes a
   packet to exit via an IPsec-enabled interface, then additional IPsec
   processing may be applied.

5.2.2 Handling of AH and ESP tunnels

   The handling of the inner and outer IP headers, extension headers,
   and options for AH and ESP tunnels should be performed as described
   in the tables in Section 5.1.

6. ICMP Processing (relevant to IPsec)

   The focus of this section is on the handling of ICMP error messages.
   Other ICMP traffic, e.g., Echo/Reply, should be treated like other
   traffic and can be protected on an end-to-end basis using SAs in the
   usual fashion.

   An ICMP error message protected by AH or ESP and generated by a
   router SHOULD be processed and forwarded in a tunnel mode SA.  Local
   policy determines whether or not it is subjected to source address
   checks by the router at the destination end of the tunnel.  Note that
   if the router at the originating end of the tunnel is forwarding an
   ICMP error message from another router, the source address check
   would fail.  An ICMP message protected by AH or ESP and generated by
   a router MUST NOT be forwarded on a transport mode SA (unless the SA
   has been established to the router acting as a host, e.g., a Telnet
   connection used to manage a router).  An ICMP message generated by a
   host SHOULD be checked against the source IP address selectors bound
   to the SA in which the message arrives.  Note that even if the source
   of an ICMP error message is authenticated, the returned IP header
   could be invalid. Accordingly, the selector values in the IP header
   SHOULD also be checked to be sure that they are consistent with the
   selectors for the SA over which the ICMP message was received.

   The table in Appendix D characterize ICMP messages as being either
   host generated, router generated, both, unknown/unassigned.  ICMP
   messages falling into the last two categories should be handled as
   determined by the receiver's policy.

   An ICMP message not protected by AH or ESP is unauthenticated and its
   processing and/or forwarding may result in denial of service.  This
   suggests that, in general, it would be desirable to ignore such
   messages.  However, it is expected that many routers (vs. security
   gateways) will not implement IPsec for transit traffic and thus
   strict adherence to this rule would cause many ICMP messages to be
   discarded.  The result is that some critical IP functions would be
   lost, e.g., redirection and PMTU processing.  Thus it MUST be
   possible to configure an IPsec implementation to accept or reject
   (router) ICMP traffic as per local security policy.

   The remainder of this section addresses how PMTU processing MUST be
   performed at hosts and security gateways.  It addresses processing of
   both authenticated and unauthenticated ICMP PMTU messages.  However,
   as noted above, unauthenticated ICMP messages MAY be discarded based
   on local policy.

6.1 PMTU/DF Processing

6.1.1 DF Bit

   In cases where a system (host or gateway) adds an encapsulating
   header (ESP tunnel or AH tunnel), it MUST support the option of
   copying the DF bit from the original packet to the encapsulating
   header (and processing ICMP PMTU messages).  This means that it MUST
   be possible to configure the system's treatment of the DF bit (set,
   clear, copy from encapsulated header) for each interface.  (See
   Appendix B for rationale.)

6.1.2 Path MTU Discovery (PMTU)

   This section discusses IPsec handling for Path MTU Discovery
   messages.  ICMP PMTU is used here to refer to an ICMP message for:

           IPv4 (RFC 792):
                   - 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)
                   - Next-Hop MTU in the 32 bit MTU field of the ICMP6
                     message

6.1.2.1 Propagation of PMTU

   The amount of information returned with the ICMP PMTU message (IPv4
   or IPv6) is limited and this affects what selectors are available for
   use in further propagating the PMTU information.  (See Appendix B for
   more detailed discussion of this topic.)

   o PMTU message with 64 bits of IPsec header -- If the ICMP PMTU
     message contains only 64 bits of the IPsec header (minimum for
     IPv4), then a security gateway MUST support the following options
     on a per SPI/SA basis:

        a. if the originating host can be determined (or the possible
           sources narrowed down to a manageable number), send the PM
           information to all the possible originating hosts.
        b. if the originating host cannot be determined, store the PMTU
           with the SA and wait until the next packet(s) arrive from the
           originating host for the relevant security association.  If

           the packet(s) are bigger than the PMTU, drop the packet(s),
           and compose ICMP PMTU message(s) with the new packet(s) and
           the updated PMTU, and send the ICMP message(s) about the
           problem to the originating host. Retain the PMTU information
           for any message that might arrive subsequently (see Section
           6.1.2.4, "PMTU Aging").

   o PMTU message with >64 bits of IPsec header -- If the ICMP message
     contains more information from the original packet then there may
     be enough non-opaque information to immediately determine to which
     host to propagate the ICMP/PMTU message and to provide that system
     with the 5 fields (source address, destination address, source
     port, destination port, transport protocol) needed to determine
     where to store/update the PMTU.  Under such circumstances, a
     security gateway MUST generate an ICMP PMTU message immediately
     upon receipt of an ICMP PMTU from further down the path.

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

6.1.2.2 Calculation of PMTU

   The calculation of PMTU from an ICMP PMTU MUST take into account the
   addition of any IPsec header -- AH transport, ESP transport, AH/ESP
   transport, ESP tunnel, AH tunnel.  (See Appendix B for discussion of
   implementation issues.)

   Note: In some situations the addition of IPsec headers could result
   in an effective PMTU (as seen by the host or application) that is
   unacceptably small.  To avoid this problem, the implementation may
   establish a threshold below which it will not report a reduced PMTU.
   In such cases, the implementation would apply IPsec and then fragment
   the resulting packet according to the PMTU.  This would result in a
   more efficient use of the available bandwidth.

6.1.2.3 Granularity of PMTU Processing

   In hosts, the granularity with which ICMP PMTU processing can be done
   differs depending on the implementation situation.  Looking at a
   host, there are 3 situations that are of interest with respect to
   PMTU issues (See Appendix B for additional details on this topic.):

        a. Integration of IPsec into the native IP implementation
        b. Bump-in-the-stack implementations, where IPsec is implemented
           "underneath" an existing implementation of a TCP/IP protocol
           stack, between the native IP and the local network drivers

        c. No IPsec implementation -- This case is included because it
           is relevant in cases where a security gateway is sending PMTU
           information back to a host.

   Only in case (a) can the PMTU data be maintained at the same
   granularity as communication associations.  In (b) and (c), the IP
   layer will only be able to maintain PMTU data at the granularity of
   source and destination IP addresses (and optionally TOS), as
   described in 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).

   Implementation of the calculation of PMTU and support for PMTUs at
   the granularity of individual communication associations is a local
   matter.  However, a socket-based implementation of IPsec in a host
   SHOULD maintain the information on a per socket basis.  Bump in the
   stack systems MUST pass an ICMP PMTU to the host IP implementation,
   after adjusting it for any IPsec header overhead added by these
   systems.  The calculation of the overhead SHOULD be determined by
   analysis of the SPI and any other selector information present in a
   returned ICMP PMTU message.

6.1.2.4 PMTU Aging

   In all systems (host or gateway) implementing IPsec and maintaining
   PMTU information, the PMTU associated with a security association
   (transport or tunnel) MUST be "aged" and some mechanism put in place
   for updating the PMTU in a timely manner, especially for discovering
   if the PMTU is smaller than it needs to be.  A given PMTU has to
   remain in place long enough for a packet to get from the source end
   of the security association to the system at the other end of the
   security association and propagate back an ICMP error message if the
   current PMTU is too big.  Note that if there are nested tunnels,
   multiple packets and round trip times might be required to get an
   ICMP message back to an encapsulator or originating host.

   Systems SHOULD use the approach described in the Path MTU Discovery
   document (RFC 1191, Section 6.3), which suggests periodically
   resetting the PMTU to the first-hop data-link MTU and then letting
   the normal PMTU Discovery processes update the PMTU as necessary.
   The period SHOULD be configurable.

7. Auditing

   Not all systems that implement IPsec will implement auditing.  For
   the most part, the granularity of auditing is a local matter.
   However, several auditable events are identified in the AH and ESP
   specifications and for each of these events a minimum set of
   information that SHOULD be included in an audit log is defined.
   Additional information also MAY be included in the audit log for each
   of these events, and additional events, not explicitly called out in
   this specification, also MAY result in audit log entries.  There is
   no requirement for the receiver to transmit any message to the
   purported transmitter in response to the detection of an auditable
   event, because of the potential to induce denial of service via such
   action.

8. Use in Systems Supporting Information Flow Security

   Information of various sensitivity levels may be carried over a
   single network.  Information labels (e.g., Unclassified, Company
   Proprietary, Secret) [DoD85, DoD87] are often employed to distinguish
   such information.  The use of labels facilitates segregation of
   information, in support of information flow security models, e.g.,
   the Bell-LaPadula model [BL73].  Such models, and corresponding
   supporting technology, are designed to prevent the unauthorized flow
   of sensitive information, even in the face of Trojan Horse attacks.
   Conventional, discretionary access control (DAC) mechanisms, e.g.,
   based on access control lists, generally are not sufficient to
   support such policies, and thus facilities such as the SPD do not
   suffice in such environments.

   In the military context, technology that supports such models is
   often referred to as multi-level security (MLS).  Computers and
   networks often are designated "multi-level secure" if they support
   the separation of labelled data in conjunction with information flow
   security policies.  Although such technology is more broadly
   applicable than just military applications, this document uses the
   acronym "MLS" to designate the technology, consistent with much
   extant literature.

   IPsec mechanisms can easily support MLS networking.  MLS networking
   requires the use of strong Mandatory Access Controls (MAC), which
   unprivileged users or unprivileged processes are incapable of
   controlling or violating.  This section pertains only to the use of
   these IP security mechanisms in MLS (information flow security
   policy) environments.  Nothing in this section applies to systems not
   claiming to provide MLS.

   As used in this section, "sensitivity information" might include
   implementation-defined hierarchic levels, categories, and/or
   releasability information.

   AH can be used to provide strong authentication in support of
   mandatory access control decisions in MLS environments.  If explicit
   IP sensitivity information (e.g., IPSO [Ken91]) is used and
   confidentiality is not considered necessary within the particular
   operational environment, AH can be used to authenticate the binding
   between sensitivity labels in the IP header and the IP payload
   (including user data).  This is a significant improvement over
   labeled IPv4 networks where the sensitivity information is trusted
   even though there is no authentication or cryptographic binding of
   the information to the IP header and user data.  IPv4 networks might
   or might not use explicit labelling.  IPv6 will normally use implicit
   sensitivity information that is part of the IPsec Security
   Association but not transmitted with each packet instead of using
   explicit sensitivity information.  All explicit IP sensitivity
   information MUST be authenticated using either ESP, AH, or both.

   Encryption is useful and can be desirable even when all of the hosts
   are within a protected environment, for example, behind a firewall or
   disjoint from any external connectivity.  ESP can be used, in
   conjunction with appropriate key management and encryption
   algorithms, in support of both DAC and MAC.  (The choice of
   encryption and authentication algorithms, and the assurance level of
   an IPsec implementation will determine the environments in which an
   implementation may be deemed sufficient to satisfy MLS requirements.)
   Key management can make use of sensitivity information to provide
   MAC.  IPsec implementations on systems claiming to provide MLS SHOULD
   be capable of using IPsec to provide MAC for IP-based communications.

8.1 Relationship Between Security Associations and Data Sensitivity

   Both the Encapsulating Security Payload and the Authentication Header
   can be combined with appropriate Security Association policies to
   provide multi-level secure networking.  In this case each SA (or SA
   bundle) is normally used for only a single instance of sensitivity
   information.  For example, "PROPRIETARY - Internet Engineering" must
   be associated with a different SA (or SA bundle) from "PROPRIETARY -
   Finance".

8.2 Sensitivity Consistency Checking

   An MLS implementation (both host and router) MAY associate
   sensitivity information, or a range of sensitivity information with
   an interface, or a configured IP address with its associated prefix
   (the latter is sometimes referred to as a logical interface, or an

   interface alias).  If such properties exist, an implementation SHOULD
   compare the sensitivity information associated with the packet
   against the sensitivity information associated with the interface or
   address/prefix from which the packet arrived, or through which the
   packet will depart.  This check will either verify that the
   sensitivities match, or that the packet's sensitivity falls within
   the range of the interface or address/prefix.

   The checking SHOULD be done on both inbound and outbound processing.

8.3 Additional MLS Attributes for Security Association Databases

   Section 4.4 discussed two Security Association databases (the
   Security Policy Database (SPD) and the Security Association Database
   (SAD)) and the associated policy selectors and SA attributes.  MLS
   networking introduces an additional selector/attribute:

           - Sensitivity information.

   The Sensitivity information aids in selecting the appropriate
   algorithms and key strength, so that the traffic gets a level of
   protection appropriate to its importance or sensitivity as described
   in section 8.1.  The exact syntax of the sensitivity information is
   implementation defined.

8.4 Additional Inbound Processing Steps for MLS Networking

   After an inbound packet has passed through IPsec processing, an MLS
   implementation SHOULD first check the packet's sensitivity (as
   defined by the SA (or SA bundle) used for the packet) with the
   interface or address/prefix as described in section 8.2 before
   delivering the datagram to an upper-layer protocol or forwarding it.

   The MLS system MUST retain the binding between the data received in
   an IPsec protected packet and the sensitivity information in the SA
   or SAs used for processing, so appropriate policy decisions can be
   made when delivering the datagram to an application or forwarding
   engine.  The means for maintaining this binding are implementation
   specific.

8.5 Additional Outbound Processing Steps for MLS Networking

   An MLS implementation of IPsec MUST perform two additional checks
   besides the normal steps detailed in section 5.1.1.  When consulting
   the SPD or the SAD to find an outbound security association, the MLS
   implementation MUST use the sensitivity of the data to select an

   appropriate outbound SA or SA bundle.  The second check comes before
   forwarding the packet out to its destination, and is the sensitivity
   consistency checking described in section 8.2.

8.6 Additional MLS Processing for Security Gateways

   An MLS security gateway MUST follow the previously mentioned inbound
   and outbound processing rules as well as perform some additional
   processing specific to the intermediate protection of packets in an
   MLS environment.

   A security gateway MAY act as an outbound proxy, creating SAs for MLS
   systems that originate packets forwarded by the gateway.  These MLS
   systems may explicitly label the packets to be forwarded, or the
   whole originating network may have sensitivity characteristics
   associated with it.  The security gateway MUST create and use
   appropriate SAs for AH, ESP, or both, to protect such traffic it
   forwards.

   Similarly such a gateway SHOULD accept and process inbound AH and/or
   ESP packets and forward appropriately, using explicit packet
   labeling, or relying on the sensitivity characteristics of the
   destination network.

9. Performance Issues

   The use of IPsec imposes computational performance costs on the hosts
   or security gateways that implement these protocols.  These costs are
   associated with the memory needed for IPsec code and data structures,
   and the computation of integrity check values, encryption and
   decryption, and added per-packet handling.  The per-packet
   computational costs will be manifested by increased latency and,
   possibly, reduced throughout.  Use of SA/key management protocols,
   especially ones that employ public key cryptography, also adds
   computational performance costs to use of IPsec.  These per-
   association computational costs will be manifested in terms of
   increased latency in association establishment.  For many hosts, it
   is anticipated that software-based cryptography will not appreciably
   reduce throughput, but hardware may be required for security gateways
   (since they represent aggregation points), and for some hosts.

   The use of IPsec also imposes bandwidth utilization costs on
   transmission, switching, and routing components of the Internet
   infrastructure, components not implementing IPsec.  This is due to
   the increase in the packet size resulting from the addition of AH
   and/or ESP headers, AH and ESP tunneling (which adds a second IP
   header), and the increased packet traffic associated with key
   management protocols.  It is anticipated that, in most instances,

   this increased bandwidth demand will not noticeably affect the
   Internet infrastructure.  However, in some instances, the effects may
   be significant, e.g., transmission of ESP encrypted traffic over a
   dialup link that otherwise would have compressed the traffic.

   Note: The initial SA establishment overhead will be felt in the first
   packet.  This delay could impact the transport layer and application.
   For example, it could cause TCP to retransmit the SYN before the
   ISAKMP exchange is done.  The effect of the delay would be different
   on UDP than TCP because TCP shouldn't transmit anything other than
   the SYN until the connection is set up whereas UDP will go ahead and
   transmit data beyond the first packet.

   Note: As discussed earlier, compression can still be employed at
   layers above IP.  There is an IETF working group (IP Payload
   Compression Protocol (ippcp)) working on "protocol specifications
   that make it possible to perform lossless compression on individual
   payloads before the payload is processed by a protocol that encrypts
   it. These specifications will allow for compression operations to be
   performed prior to the encryption of a payload by IPsec protocols."

10. Conformance Requirements

   All IPv4 systems that claim to implement IPsec MUST comply with all
   requirements of the Security Architecture document.  All IPv6 systems
   MUST comply with all requirements of the Security Architecture
   document.

11. Security Considerations

   The focus of this document is security; hence security considerations
   permeate this specification.

12. Differences from RFC 1825

   This architecture document differs substantially from RFC 1825 in
   detail and in organization, but the fundamental notions are
   unchanged.  This document provides considerable additional detail in
   terms of compliance specifications.  It introduces the SPD and SAD,
   and the notion of SA selectors.  It is aligned with the new versions
   of AH and ESP, which also differ from their predecessors.  Specific
   requirements for supported combinations of AH and ESP are newly
   added, as are details of PMTU management.

Acknowledgements

   Many of the concepts embodied in this specification were derived from
   or influenced by the US Government's SP3 security protocol, ISO/IEC's
   NLSP, the proposed swIPe security protocol [SDNS, ISO, IB93, IBK93],
   and the work done for SNMP Security and SNMPv2 Security.

   For over 3 years (although it sometimes seems *much* longer), this
   document has evolved through multiple versions and iterations.
   During this time, many people have contributed significant ideas and
   energy to the process and the documents themselves.  The authors
   would like to thank Karen Seo for providing extensive help in the
   review, editing, background research, and coordination for this
   version of the specification.  The authors would also like to thank
   the members of the IPsec and IPng working groups, with special
   mention of the efforts of (in alphabetic order): Steve Bellovin,
   Steve Deering, James Hughes, Phil Karn, Frank Kastenholz, Perry
   Metzger, David Mihelcic, Hilarie Orman, Norman Shulman, William
   Simpson, Harry Varnis, and Nina Yuan.