Network Working Group
`Request for Comments: 2401
`Obsoletes: 1825
`Category: Standards Track
`
`S. Kent
`BBN Corp
`R. Atkinson
`@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
`1.1 Summary of Contents of Document
`1.2 Audience
`1.3 Related Documents
`2. Design Objectives
`2.1 Goals/Objectives/Requirements/Problem Description
`2.2 Caveats and Assumptions
`3. System Overview
`3.1 What IPsec Does
`3.2 How IPsec Works
`3.3 Where IPsec May Be Implemented
`4. Security Associations
`4.1 Definition and Scope
`4.2 Security Association Functionality
`4.3 Combining Security Associations
`4.4 Security Association Databases
`4.4.1 The Security Policy Database (SPD)
`4.4.2 Selectors
`4.4.3 Security Association Database (SAD)
`4.5 Basic Combinations of Security Associations
`4.6 SA and Key Management
`4.6.1 Manual Techniques
`4.6.2 Automated SA and Key Management
`4.6.3 Locating a Security Gateway
`4.7 Security Associations and Multicast
`
`3
`3
`3
`4
`4
`4
`5
`5
`6
`6
`7
`8
`8
`10
`11
`13
`14
`17
`21
`24
`26
`27
`27
`28
`29
`
`Kent & Atkinson
`El
`RFC 2401
`
`Standards Track
`
`[Page 1]
`
`Security Architecture for IP
`
`November 1998
`
`Petitioner Apple Inc. -
`
`Apple v. VirnetX, IPR2015-00866, Petitioner Apple Inc. - Exhibit 1062, p. 1
`
`

`
`RFC 2401
`
`Security Architecture for IP
`
`November 1998
`
`30
`5. IP Traffic Processing
`5.1 Outbound IP Traffic Processing
`30
`30
`5.1.1 Selecting and Using an SA or SA Bundle
`31
`5.1.2 Header Construction for Tunnel Mode
`5.1.2.1 IPv4 -- Header Construction for Tunnel Mode
`31
`32
`5.1.2.2 IPv6 -- Header Construction for Tunnel Mode
`33
`5.2 Processing Inbound IP Traffic
`33
`5.2.1 Selecting and Using an SA or SA Bundle
`5.2.2 Handling of AH and ESP tunnels
`34
`35
`6. ICMP Processing (relevant to IPsec)
`36
`6.1 PMTU/DF Processing
`36
`6.1.1 DF Bit
`6.1.2 Path MTU Discovery (PMTU)
`36
`36
`6.1.2.1 Propagation of PMTU
`37
`6.1.2.2 Calculation of PMTU
`6.1.2.3 Granularity of PMTU Processing
`37
`6.1.2.4 PMTU Aging
`38
`39
`7. Auditing
`39
`8. Use in Systems Supporting Information Flow Security
`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
`65
`Author Information
`Full Copyright Statement
`66
`
`337-TA-858-
`
`Apple v. VirnetX, IPR2015-00866, Petitioner Apple Inc. - Exhibit 1062, p. 2
`
`

`
`RFC 2401
`
`Security Architecture for IP
`
`November 1998
`
`Kent & Atkinson
`El
`RFC 2401
`
`1. Introduction
`
`Standards Track
`
`[Page 2]
`
`Security Architecture for IP
`
`November 1998
`
`1.1 Summary of Contents of Document
`
`Kent & Atkinson
`
`Standards Track
`
`[Page 1124]
`Petitioner Apple Inc. - Ex. 1008, p. 58
`
`Apple v. VirnetX, IPR2015-00866, Petitioner Apple Inc. - Exhibit 1062, p. 3
`
`

`
`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
`
`Kent & Atkinson
`
`Standards Track
`
`[Page 3]
`
`337-TA-858-IETF1125
`
`Apple v. VirnetX, IPR2015-00866, Petitioner Apple Inc. - Exhibit 1062, p. 4
`
`

`
`RFC 2401
`
`El
`RFC 2401
`
`Security Architecture for IP
`
`November 1998
`
`Security Architecture for IP
`
`November 1998
`
`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.
`
`Kent & Atkinson
`
`Standards Track
`
`[Page 1126]
`Petitioner Apple Inc. - Ex. 1008, p. 58
`
`Apple v. VirnetX, IPR2015-00866, Petitioner Apple Inc. - Exhibit 1062, p. 5
`
`

`
`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
`
`337-TA-858-IETF1127
`
`Apple v. VirnetX, IPR2015-00866, Petitioner Apple Inc. - Exhibit 1062, p. 6
`
`

`
`RFC 2401
`
`Security Architecture for IP
`
`November 1998
`
`Kent & Atkinson
`El
`RFC 2401
`
`Standards Track
`
`[Page 4]
`
`Security Architecture for IP
`
`November 1998
`
`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.
`
`Kent & Atkinson
`
`Standards Track
`
`[Page 1128]
`Petitioner Apple Inc. - Ex. 1008, p. 58
`
`Apple v. VirnetX, IPR2015-00866, Petitioner Apple Inc. - Exhibit 1062, p. 7
`
`

`
`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
`
`Kent & Atkinson
`
`Standards Track
`
`[Page 5]
`
`337-TA-858-IETF1129
`
`Apple v. VirnetX, IPR2015-00866, Petitioner Apple Inc. - Exhibit 1062, p. 8
`
`

`
`RFC 2401
`
`El
`RFC 2401
`
`Security Architecture for IP
`
`November 1998
`
`Security Architecture for IP
`
`November 1998
`
`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
`
`Kent & Atkinson
`
`Standards Track
`
`[Page 1130]
`Petitioner Apple Inc. - Ex. 1008, p. 58
`
`Apple v. VirnetX, IPR2015-00866, Petitioner Apple Inc. - Exhibit 1062, p. 9
`
`

`
`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
`
`337-TA-858-IETF1131
`
`Apple v. VirnetX, IPR2015-00866, Petitioner Apple Inc. - Exhibit 1062, p. 10
`
`

`
`RFC 2401
`
`Security Architecture for IP
`
`November 1998
`
`Kent & Atkinson
`El
`RFC 2401
`
`Standards Track
`
`[Page 6]
`
`Security Architecture for IP
`
`November 1998
`
`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
`
`Kent & Atkinson
`
`Standards Track
`
`[Page 1132]
`Petitioner Apple Inc. - Ex. 1008, p. 58
`
`Apple v. VirnetX, IPR2015-00866, Petitioner Apple Inc. - Exhibit 1062, p. 11
`
`

`
`across these gateways. IPsec management must incorporate facilities
`for specifying:
`
`which security services to use and in what combinations
`o
`o the granularity at which a given security protection should
`be applied
`the algorithms used to effect cryptographic-based security
`
`o
`
`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.
`
`Kent & Atkinson
`
`Standards Track
`
`[Page 7]
`
`337-TA-858-IETF1133
`
`Apple v. VirnetX, IPR2015-00866, Petitioner Apple Inc. - Exhibit 1062, p. 12
`
`

`
`RFC 2401
`
`El
`RFC 2401
`
`Security Architecture for IP
`
`November 1998
`
`Security Architecture for IP
`
`November 1998
`
`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.
`
`4. Security Associations
`
`This section defines Security Association management requirements for
`all IPv6 implementations and for those IPv4 implementations that
`implement AH, ESP, or both. The concept of a "Security Association"
`(SA) is fundamental to IPsec. Both AH and ESP make use of SAs and a
`
`Kent & Atkinson
`
`Standards Track
`
`[Page 1134]
`Petitioner Apple Inc. - Ex. 1008, p. 58
`
`Apple v. VirnetX, IPR2015-00866, Petitioner Apple Inc. - Exhibit 1062, p. 13
`
`

`
`major function of IKE is the establishment and maintenance of
`Security Associations. All implementations of AH or ESP MUST support
`the concept of a Security Association as described below. The
`remainder of this section describes various aspects of Security
`Association management, defining required characteristics for SA
`policy management, traffic processing, and SA management techniques.
`
`4.1 Definition and Scope
`
`A Security Association (SA) is a simplex "connection" that affords
`security services to the traffic carried by it. Security services are
`afforded to an SA by the use of AH, or ESP, but not both. If both AH
`and ESP protection is applied to a traffic stream, then two (or more)
`SAs are created to afford protection to the traffic stream. To secure
`typical, bi-directional communication between two hosts, or between
`two security gateways, two Security Associations (one in each
`direction) are required.
`
`A security association is uniquely identified by a triple consisting
`of a Security Parameter Index (SPI), an IP Destination Address, and a
`security protocol (AH or ESP) identifier. In principle, the
`Destination Address may be a unicast address, an IP broadcast
`address, or a multicast group address. However, IPsec SA management
`mechanisms currently are defined only for unicast SAs. Hence, in the
`
`337-TA-858-IETF1135
`
`Apple v. VirnetX, IPR2015-00866, Petitioner Apple Inc. - Exhibit 1062, p. 14
`
`

`
`RFC 2401
`
`Security Architecture for IP
`
`November 1998
`
`Kent & Atkinson
`El
`RFC 2401
`
`Standards Track
`
`[Page 8]
`
`Security Architecture for IP
`
`November 1998
`
`discussions that follow, SAs will be described in the context of
`point-to-point communication, even though the concept is applicable
`in the point-to-multipoint case as well.
`
`As noted above, two types of SAs are defined: transport mode and
`tunnel mode. A transport mode SA is a security association between
`two hosts. In IPv4, a transport mode security protocol header appears
`immediately after the IP header and any options, and before any
`higher layer protocols (e.g., TCP or UDP). In IPv6, the security
`protocol header appears after the base IP header and extensions, but
`may appear before or after destination options, and before higher
`layer protocols. In the case of ESP, a transport mode SA provides
`security services only for these higher layer protocols, not for the
`IP header or any extension headers preceding the ESP header. In the
`case of AH, the protection is also extended to selected portions of
`the IP header, selected portions of extension headers, and selected
`options (contained in the IPv4 header, IPv6 Hop-by-Hop extension
`header, or IPv6 Destination extension headers). For more details on
`the coverage afforded by AH, see the AH specification [KA98a].
`
`A tunnel mode SA is essentially an SA applied to an IP tunnel.
`Whenever either end of a security association is a security gateway,
`the SA MUST be tunnel mode. Thus an SA between two security gateways
`is always a tunnel mode SA, as is an SA between a host and a security
`gateway. Note that for the case where traffic is destined for a
`security gateway, e.g., SNMP commands, the security gateway is acting
`as a host and transport mode is allowed. But in that case, the
`security gateway is not acting as a gateway, i.e., not transiting
`
`Kent & Atkinson
`
`Standards Track
`
`[Page 1136]
`Petitioner Apple Inc. - Ex. 1008, p. 58
`
`Apple v. VirnetX, IPR2015-00866, Petitioner Apple Inc. - Exhibit 1062, p. 15
`
`

`
`traffic. Two hosts MAY establish a tunnel mode SA between themselves.
`The requirement for any (transit traffic) SA involving a security
`gateway to be a tunnel SA arises due to the need to avoid potential
`problems with regard to fragmentation and reassembly of IPsec
`packets, and in circumstances where multiple paths (e.g., via
`different security gateways) exist to the same destination behind the
`security gateways.
`
`For a tunnel mode SA, there is an "outer" IP header that specifies
`the IPsec processing destination, plus an "inner" IP header that
`specifies the (apparently) ultimate destination for the packet. The
`security protocol header appears after the outer IP header, and
`before the inner IP header. If AH is employed in tunnel mode,
`portions of the outer IP header are afforded protection (as above),
`as well as all of the tunneled IP packet (i.e., all of the inner IP
`header is protected, as well as higher layer protocols). If ESP is
`employed, the protection is afforded only to the tunneled packet, not
`to the outer header.
`
`Kent & Atkinson
`
`Standards Track
`
`[Page 9]
`
`337-TA-858-IETF1137
`
`Apple v. VirnetX, IPR2015-00866, Petitioner Apple Inc. - Exhibit 1062, p. 16
`
`

`
`RFC 2401
`
`El
`RFC 2401
`
`Security Architecture for IP
`
`November 1998
`
`Security Architecture for IP
`
`November 1998
`
`In summary,
`a) A host MUST support both transport and tunnel mode.
`b) A security gateway is required to support only tunnel
`mode. If it supports transport mode, that should be used
`only when the security gateway is acting as a host, e.g.,
`for network management.
`
`4.2 Security Association Functionality
`
`The set of security services offered by an SA depends on the security
`protocol selected, the SA mode, the endpoints of the SA, and on the
`election of optional services within the protocol. For example, AH
`provides data origin authentication and connectionless integrity for
`IP datagrams (hereafter referred to as just "authentication"). The
`"precision" of the authentication service is a function of the
`granularity of the security association with which AH is employed, as
`discussed in Section 4.4.2, "Selectors".
`
`AH also offers an anti-replay (partial sequence integrity) service at
`the discretion of the receiver, to help counter denial of service
`attacks. AH is an appropriate protocol to employ when confidentiality
`is not required (or is not permitted, e.g , due to government
`restrictions on use of encryption). AH also provides authentication
`for selected portions of the IP header, which may be necessary in
`some contexts. For example, if the integrity of an IPv4 option or
`IPv6 extension header must be protected en route between sender and
`receiver, AH can provide this service (except for the non-predictable
`but mutable parts of the IP header.)
`
`ESP optionally provides confidentiality for traffic. (The strength
`of the confidentiality service depends in part, on the encryption
`algorithm employed.) ESP also may optionally provide authentication
`
`Kent & Atkinson
`
`Standards Track
`
`[Page 1138]
`Petitioner Apple Inc. - Ex. 1008, p. 58
`
`Apple v. VirnetX, IPR2015-00866, Petitioner Apple Inc. - Exhibit 1062, p. 17
`
`

`
`(as defined above). If authentication is negotiated for an ESP SA,
`the receiver also may elect to enforce an anti-replay service with
`the same features as the AH anti-replay service. The scope of the
`authentication offered by ESP is narrower than for AH, i.e., the IP
`header(s) "outside" the ESP header is(are) not protected. If only
`the upper layer protocols need to be authenticated, then ESP
`authentication is an appropriate choice and is more space efficient
`than use of AH encapsulating ESP. Note that although both
`confidentiality and authentication are optional, they cannot both
`be omitted. At least one of them MUST be selected.
`
`If confidentiality service is selected, then an ESP (tunnel mode)
`SA between two security gateways can offer partial traffic flow
`confidentiality. The use of tunnel mode allows the inner IP headers
`to be encrypted, concealing the identities of the (ultimate)
`traffic source and destination. Moreover, ESP payload padding also
`can be
`
`337-TA-858-IETF1139
`
`Apple v. VirnetX, IPR2015-00866, Petitioner Apple Inc. - Exhibit 1062, p. 18
`
`

`
`RFC 2401
`
`Security Architecture for IP
`
`November 1998
`
`Kent & Atkinson
`El
`RFC 2401
`
`Standards Track
`
`[Page 10]
`
`Security Architecture for IP
`
`November 1998
`
`invoked to hide the size of the packets, further concealing the
`external characteristics of the traffic. Similar traffic flow
`confidentiality services may be offered when a mobile user is
`assigned a dynamic IP address in a dialup context, and establishes a
`(tunnel mode) ESP SA to a corporate firewall (acting as a security
`gateway). Note that fine granularity SAs generally are more
`vulnerable to traffic analysis than coarse granularity ones which are
`carrying traffic from many subscribers.
`
`4.3 Combining Security Associations
`
`The IP datagrams transmitted over an individual SA are afforded
`protection by exactly one security protocol, either AH or ESP, but
`not both. Sometimes a security policy may call for a combination of
`services for a particular traffic flow that is not achievable with a
`single SA. In such instances it will be necessary to employ multiple
`SAs to implement the required security policy. The term "security
`association bundle" or "SA bundle" is applied to a sequence of SAs
`through which traffic must be processed to satisfy a security policy.
`The order of the sequence is defined by the policy. (Note that the
`SAs that comprise a bundle may terminate at different endpoints. For
`example, one SA may extend between a mobile host and a security
`gateway and a second, nested SA may extend to a host behind the
`gateway.)
`
`Security associations may be combined into bundles in two ways:
`transport adjacency and iterated tunneling.
`
`o Transport adjacency refers to applying more than one
`security protocol to the same IP datagram, without invoking
`tunneling. This approach to combining AH and ESP allows for
`only one level of combination; further nesting yields no
`added benefit (assuming use of adequately strong algorithms
`in each protocol) since the processing is performed at one
`IPsec instance at the (ultimate) destination.
`
`Host
`| |
`| |
`|
`
`|
`
`1 --- Security ---- Internet -- Security ---
`Gwy 1
`Gwy 2
`
`Security Association 1 (ESP transport)
`
`Security Association 2 (AH transport)
`
`Host
`|
`|
`
`2
`|
`|
`|
`|
`
`Kent & Atkinson
`
`Standards Track
`
`[Page 1140]
`Petitioner Apple Inc. - Ex. 1008, p. 58
`
`Apple v. VirnetX, IPR2015-00866, Petitioner Apple Inc. - Exhibit 1062, p. 19
`
`

`
`Host 1 --- Security ---- Internet -- Security --- Host 2
`| |
`Gwy 1
`Gwy 2
`| |
`| |
`| |
`|
` |
`
`Security Association 1 (ESP transport)
`| |
`Security Association 2 (AH transport)
`
`o Iterated tunneling refers to the application of multiple
`layers of security protocols effected through IP tunneling.
`This approach allows for multiple levels of nesting, since
`each tunnel can originate or terminate at a different IPsec
`
`Kent & Atkinson Standards Track
`
`[Page 11]
`
`337-TA-858-IETF1141
`
`Apple v. VirnetX, IPR2015-00866, Petitioner Apple Inc. - Exhibit 1062, p. 20
`
`

`
`RFC 2401
`
`El
`RFC 2401
`
`Security Architecture for IP
`
`November 1998
`
`Security Architecture for IP
`
`November 1998
`
`site along the path. No special treatment is expected for
`ISAKMP traffic at intermediate security gateways other than
`what can be specified through appropriate SPD entries (See
`Case 3 in Section 4.5)
`
`There are 3 basic cases of iterated tunneling -- support is
`required only for cases 2 and 3.:
`
`1. both endpoints for the SAs are the same -- The inner and
`outer tunnels could each be either AH or ESP, though it
`is unlikely that Host 1 would specify both to be the
`same, i.e., AH inside of AH or ESP inside of ESP.
`
`Host 1 --- Security ---- Internet -- Security --- Host 2
`| |
`Gwy 1
`Gwy
`2
`|
`| |
`|
`|
`|
`|
`
`Security Association 1 (tunnel)
`
`|
`|
`|
`|
`
`| |
`| |
`|
`|
`
`Security Association 2 (tunnel)
`Gwy 1
`Gwy 2
`
`Security Association 1 (tunnel)
`
`Security Association 2 (tunnel)
`
`| |
`| |
` | |
`|
`
`2. one endpoint of the SAs is the same -- The inner and
`uter tunnels could each be either AH or ESP.
`
`Host 1 --- Security ---- Internet -- Security --- Host 2
`| |
`Gwy 1
`Gwy 2
`|
`| |
`|
`|
`| ----Security Association 1 (tunnel)----
`|
`
`|
`
`Security Association 2 (tunnel)
`
`|
`
`3. neither endpoint is the same -- The inner and outer
`tunnels could each be either AH or ESP.
`
`Host 1 --- Security ---- Internet -- Security --- Host 2
`|
`Gwy 1
`Gwy 2
`|
`|
`|
`|
`|
`|
`--Security Assoc 1 (tunnel)-
`|
`
`|
`
`|
`
`Security Association 2 (tunnel)
`
`Kent & Atkinson
`
`Standards Track
`
`[Page 1142]
`Petitioner Apple Inc. - Ex. 1008, p. 58
`
`Apple v. VirnetX, IPR2015-00866, Petitioner Apple Inc. - Exhibit 1062, p. 21
`
`

`
`These two approaches also can be combined, e.g., an SA bundle could
`be constructed from one tunnel mode SA and one or two transport
`mode SAs, applied in sequence. (See Section 4.5 "Basic Combinations
`of Security Associations.") Note that nested tunnels can also occur
`where neither the source nor the destination endpoints of any of
`the tunnels are the same. In that case, there would be no host or
`security gateway with a bundle corresponding to the nested tunnels.
`
`337-TA-858-IETF1143
`
`Apple v. VirnetX, IPR2015-00866, Petitioner Apple Inc. - Exhibit 1062, p. 22
`
`

`
`RFC 2401
`
`Security Architecture for IP
`
`November 1998
`
`Kent & Atkinson
`El
`RFC 2401
`
`Standards Track
`
`[Page 12]
`
`Security Architecture for IP
`
`November 1998
`
`For transport mode SAs, only one ordering of security protocols seems
`appropriate. AH is applied to both the upper layer protocols and
`(parts of) the IP header. Thus if AH is used in a transport mode, in
`conjunction with ESP, AH SHOULD appear as the first header after IP,
`prior to the appearance of ESP. In that context, AH is applied to the
`ciphertext output of ESP. In contrast, for tunnel mode SAs, one can
`imagine uses for various orderings of AH and ESP. The required set of
`SA bundle types that MUST be supported by a compliant IPsec
`implementation is described in Section 4.5.
`
`4.4 Security Association Databases
`
`Many of the details associated with processing IP traffic in an IPsec
`implementation are largely a local matter, not subject to
`standardization. However, some external aspects of the processing
`must be standardized, to ensure interoperability and to provide a
`minimum management capability that is essential for productive use of
`IPsec. This section describes a general model for processing IP
`traffic relative to security associations, in support of these
`interoperability and functionality goals. The model described below
`is nominal; compliant