Network Working Group                                            S. Kent
Request for Comments: 2401                                      BBN Corp
Obsoletes: 1825                                              R. Atkinson
Category: Standards Track                                  @Home Network
                                                           November 1998


            Security Architecture for the Internet Protocol

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Table of Contents

 1. Introduction.......................................................3
  1.1 Summary of Contents of Document..................................3
  1.2 Audience.........................................................3
  1.3 Related Documents................................................4
 2. Design Objectives..................................................4
  2.1 Goals/Objectives/Requirements/Problem Description................4
  2.2 Caveats and Assumptions..........................................5
 3. System Overview....................................................5
  3.1 What IPsec Does..................................................6
  3.2 How IPsec Works..................................................6
  3.3 Where IPsec May Be Implemented...................................7
 4. Security Associations..............................................8
  4.1 Definition and Scope.............................................8
  4.2 Security Association Functionality..............................10
  4.3 Combining Security Associations.................................11
  4.4 Security Association Databases..................................13
     4.4.1 The Security Policy Database (SPD).........................14
     4.4.2 Selectors..................................................17
     4.4.3 Security Association Database (SAD)........................21
  4.5 Basic Combinations of Security Associations.....................24
  4.6 SA and Key Management...........................................26
     4.6.1 Manual Techniques..........................................27
     4.6.2 Automated SA and Key Management............................27
     4.6.3 Locating a Security Gateway................................28
  4.7 Security Associations and Multicast.............................29

 5. IP Traffic Processing.............................................30
  5.1 Outbound IP Traffic Processing..................................30
     5.1.1 Selecting and Using an SA or SA Bundle.....................30
     5.1.2 Header Construction for Tunnel Mode........................31
        5.1.2.1 IPv4 -- Header Construction for Tunnel Mode...........31
        5.1.2.2 IPv6 -- Header Construction for Tunnel Mode...........32
  5.2 Processing Inbound IP Traffic...................................33
     5.2.1 Selecting and Using an SA or SA Bundle.....................33
     5.2.2 Handling of AH and ESP tunnels.............................34
 6. ICMP Processing (relevant to IPsec)...............................35
  6.1 PMTU/DF Processing..............................................36
     6.1.1 DF Bit.....................................................36
     6.1.2 Path MTU Discovery (PMTU)..................................36
        6.1.2.1 Propagation of PMTU...................................36
        6.1.2.2 Calculation of PMTU...................................37
        6.1.2.3 Granularity of PMTU Processing........................37
        6.1.2.4 PMTU Aging............................................38
 7. Auditing..........................................................39
 8. Use in Systems Supporting Information Flow Security...............39
  8.1 Relationship Between Security Associations and Data Sensitivity.40
  8.2 Sensitivity Consistency Checking................................40
  8.3 Additional MLS Attributes for Security Association Databases....41
  8.4 Additional Inbound Processing Steps for MLS Networking..........41
  8.5 Additional Outbound Processing Steps for MLS Networking.........41
  8.6 Additional MLS Processing for Security Gateways.................42
 9. Performance Issues................................................42
 10. Conformance Requirements.........................................43
 11. Security Considerations..........................................43
 12. Differences from RFC 1825........................................43
 Acknowledgements.....................................................44
 Appendix A -- Glossary...............................................45
 Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues....48
  B.1 DF bit..........................................................48
  B.2 Fragmentation...................................................48
  B.3 Path MTU Discovery..............................................52
     B.3.1 Identifying the Originating Host(s)........................53
     B.3.2 Calculation of PMTU........................................55
     B.3.3 Granularity of Maintaining PMTU Data.......................56
     B.3.4 Per Socket Maintenance of PMTU Data........................57
     B.3.5 Delivery of PMTU Data to the Transport Layer...............57
     B.3.6 Aging of PMTU Data.........................................57
 Appendix C -- Sequence Space Window Code Example.....................58
 Appendix D -- Categorization of ICMP messages........................60
 References...........................................................63
 Disclaimer...........................................................64
 Author Information...................................................65
 Full Copyright Statement.............................................66

1. Introduction

1.1 Summary of Contents of Document

   This memo specifies the base architecture for IPsec compliant
   systems.  The goal of the architecture is to provide various security
   services for traffic at the IP layer, in both the IPv4 and IPv6
   environments.  This document describes the goals of such systems,
   their components and how they fit together with each other and into
   the IP environment.  It also describes the security services offered
   by the IPsec protocols, and how these services can be employed in the
   IP environment.  This document does not address all aspects of IPsec
   architecture.  Subsequent documents will address additional
   architectural details of a more advanced nature, e.g., use of IPsec
   in NAT environments and more complete support for IP multicast.  The
   following fundamental components of the IPsec security architecture
   are discussed in terms of their underlying, required functionality.
   Additional RFCs (see Section 1.3 for pointers to other documents)
   define the protocols in (a), (c), and (d).

        a. Security Protocols -- Authentication Header (AH) and
           Encapsulating Security Payload (ESP)
        b. Security Associations -- what they are and how they work,
           how they are managed, associated processing
        c. Key Management -- manual and automatic (The Internet Key
           Exchange (IKE))
        d. Algorithms for authentication and encryption

   This document is not an overall Security Architecture for the
   Internet; it addresses security only at the IP layer, provided
   through the use of a combination of cryptographic and protocol
   security mechanisms.

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in RFC 2119 [Bra97].

1.2 Audience

   The target audience for this document includes implementers of this
   IP security technology and others interested in gaining a general
   background understanding of this system.  In particular, prospective
   users of this technology (end users or system administrators) are
   part of the target audience.  A glossary is provided as an appendix

   to help fill in gaps in background/vocabulary.  This document assumes
   that the reader is familiar with the Internet Protocol, related
   networking technology, and general security terms and concepts.

1.3 Related Documents

   As mentioned above, other documents provide detailed definitions of
   some of the components of IPsec and of their inter-relationship.
   They include RFCs on the following topics:

        a. "IP Security Document Roadmap" [TDG97] -- a document
           providing guidelines for specifications describing encryption
           and authentication algorithms used in this system.
        b. security protocols -- RFCs describing the Authentication
           Header (AH) [KA98a] and Encapsulating Security Payload (ESP)
           [KA98b] protocols.
        c. algorithms for authentication and encryption -- a separate
           RFC for each algorithm.
        d. automatic key management -- RFCs on "The Internet Key
           Exchange (IKE)" [HC98], "Internet Security Association and
           Key Management Protocol (ISAKMP)" [MSST97],"The OAKLEY Key
           Determination Protocol" [Orm97], and "The Internet IP
           Security Domain of Interpretation for ISAKMP" [Pip98].

2. Design Objectives

2.1 Goals/Objectives/Requirements/Problem Description

   IPsec is designed to provide interoperable, high quality,
   cryptographically-based security for IPv4 and IPv6.  The set of
   security services offered includes access control, connectionless
   integrity, data origin authentication, protection against replays (a
   form of partial sequence integrity), confidentiality (encryption),
   and limited traffic flow confidentiality.  These services are
   provided at the IP layer, offering protection for IP and/or upper
   layer protocols.

   These objectives are met through the use of two traffic security
   protocols, the Authentication Header (AH) and the Encapsulating
   Security Payload (ESP), and through the use of cryptographic key
   management procedures and protocols.  The set of IPsec protocols
   employed in any context, and the ways in which they are employed,
   will be determined by the security and system requirements of users,
   applications, and/or sites/organizations.

   When these mechanisms are correctly implemented and deployed, they
   ought not to adversely affect users, hosts, and other Internet
   components that do not employ these security mechanisms for

   protection of their traffic.  These mechanisms also are designed to
   be algorithm-independent.  This modularity permits selection of
   different sets of algorithms without affecting the other parts of the
   implementation.  For example, different user communities may select
   different sets of algorithms (creating cliques) if required.

   A standard set of default algorithms is specified to facilitate
   interoperability in the global Internet.  The use of these
   algorithms, in conjunction with IPsec traffic protection and key
   management protocols, is intended to permit system and application
   developers to deploy high quality, Internet layer, cryptographic
   security technology.

2.2 Caveats and Assumptions

   The suite of IPsec protocols and associated default algorithms are
   designed to provide high quality security for Internet traffic.
   However, the security offered by use of these protocols ultimately
   depends on the quality of the their implementation, which is outside
   the scope of this set of standards.  Moreover, the security of a
   computer system or network is a function of many factors, including
   personnel, physical, procedural, compromising emanations, and
   computer security practices.  Thus IPsec is only one part of an
   overall system security architecture.

   Finally, the security afforded by the use of IPsec is critically
   dependent on many aspects of the operating environment in which the
   IPsec implementation executes.  For example, defects in OS security,
   poor quality of random number sources, sloppy system management
   protocols and practices, etc. can all degrade the security provided
   by IPsec.  As above, none of these environmental attributes are
   within the scope of this or other IPsec standards.

3. System Overview

   This section provides a high level description of how IPsec works,
   the components of the system, and how they fit together to provide
   the security services noted above.  The goal of this description is
   to enable the reader to "picture" the overall process/system, see how
   it fits into the IP environment, and to provide context for later
   sections of this document, which describe each of the components in
   more detail.

   An IPsec implementation operates in a host or a security gateway
   environment, affording protection to IP traffic.  The protection
   offered is based on requirements defined by a Security Policy
   Database (SPD) established and maintained by a user or system
   administrator, or by an application operating within constraints

   established by either of the above.  In general, packets are selected
   for one of three processing modes based on IP and transport layer
   header information (Selectors, Section 4.4.2) matched against entries
   in the database (SPD).  Each packet is either afforded IPsec security
   services, discarded, or allowed to bypass IPsec, based on the
   applicable database policies identified by the Selectors.

3.1 What IPsec Does

   IPsec provides security services at the IP layer by enabling a system
   to select required security protocols, determine the algorithm(s) to
   use for the service(s), and put in place any cryptographic keys
   required to provide the requested services.  IPsec can be used to
   protect one or more "paths" between a pair of hosts, between a pair
   of security gateways, or between a security gateway and a host.  (The
   term "security gateway" is used throughout the IPsec documents to
   refer to an intermediate system that implements IPsec protocols.  For
   example, a router or a firewall implementing IPsec is a security
   gateway.)

   The set of security services that IPsec can provide includes access
   control, connectionless integrity, data origin authentication,
   rejection of replayed packets (a form of partial sequence integrity),
   confidentiality (encryption), and limited traffic flow
   confidentiality.  Because these services are provided at the IP
   layer, they can be used by any higher layer protocol, e.g., TCP, UDP,
   ICMP, BGP, etc.

   The IPsec DOI also supports negotiation of IP compression [SMPT98],
   motivated in part by the observation that when encryption is employed
   within IPsec, it prevents effective compression by lower protocol
   layers.

3.2 How IPsec Works

   IPsec uses two protocols to provide traffic security --
   Authentication Header (AH) and Encapsulating Security Payload (ESP).
   Both protocols are described in more detail in their respective RFCs
   [KA98a, KA98b].

        o The IP Authentication Header (AH) [KA98a] provides
          connectionless integrity, data origin authentication, and an
          optional anti-replay service.
        o The Encapsulating Security Payload (ESP) protocol [KA98b] may
          provide confidentiality (encryption), and limited traffic flow
          confidentiality.  It also may provide connectionless

          integrity, data origin authentication, and an anti-replay
          service.  (One or the other set of these security services
          must be applied whenever ESP is invoked.)
        o Both AH and ESP are vehicles for access control, based on the
          distribution of cryptographic keys and the management of
          traffic flows relative to these security protocols.

   These protocols may be applied alone or in combination with each
   other to provide a desired set of security services in IPv4 and IPv6.
   Each protocol supports two modes of use: transport mode and tunnel
   mode.  In transport mode the protocols provide protection primarily
   for upper layer protocols; in tunnel mode, the protocols are applied
   to tunneled IP packets.  The differences between the two modes are
   discussed in Section 4.

   IPsec allows the user (or system administrator) to control the
   granularity at which a security service is offered.  For example, one
   can create a single encrypted tunnel to carry all the traffic between
   two security gateways or a separate encrypted tunnel can be created
   for each TCP connection between each pair of hosts communicating
   across these gateways.  IPsec management must incorporate facilities
   for specifying:

        o which security services to use and in what combinations
        o the granularity at which a given security protection should be
          applied
        o the algorithms used to effect cryptographic-based security

   Because these security services use shared secret values
   (cryptographic keys), IPsec relies on a separate set of mechanisms
   for putting these keys in place. (The keys are used for
   authentication/integrity and encryption services.)  This document
   requires support for both manual and automatic distribution of keys.
   It specifies a specific public-key based approach (IKE -- [MSST97,
   Orm97, HC98]) for automatic key management, but other automated key
   distribution techniques MAY be used.  For example, KDC-based systems
   such as Kerberos and other public-key systems such as SKIP could be
   employed.

3.3 Where IPsec May Be Implemented

   There are several ways in which IPsec may be implemented in a host or
   in conjunction with a router or firewall (to create a security
   gateway).  Several common examples are provided below:

        a. Integration of IPsec into the native IP implementation.  This
           requires access to the IP source code and is applicable to
           both hosts and security gateways.

        b. "Bump-in-the-stack" (BITS) implementations, where IPsec is
           implemented "underneath" an existing implementation of an IP
           protocol stack, between the native IP and the local network
           drivers.  Source code access for the IP stack is not required
           in this context, making this implementation approach
           appropriate for use with legacy systems.  This approach, when
           it is adopted, is usually employed in hosts.

        c. The use of an outboard crypto processor is a common design
           feature of network security systems used by the military, and
           of some commercial systems as well.  It is sometimes referred
           to as a "Bump-in-the-wire" (BITW) implementation.  Such
           implementations may be designed to serve either a host or a
           gateway (or both).  Usually the BITW device is IP
           addressable.  When supporting a single host, it may be quite
           analogous to a BITS implementation, but in supporting a
           router or firewall, it must operate like a security gateway.