`
`RNET PROTOCOL
`RFC 2401: SECURITY ARCHITECTURE FOR THE
`ADER
`RFC 2402: IP AUTHENTICATION
`RFC 2406: IP ENCAPSULATING SECURITY AYLOAD SP
`
`
`
`
`
`
`
`I, Sandy Ginoza, hereby declare that all statements made herein are of my own
`
`knowledge and are true and that all statements made on information and belief are believed to be
`
`true; and further that these statements were made with the knowledge that willful false
`
`statements and the like so made are punishable by fine or imprisonment, or both, under Section
`
`1001 of Title 18 of the United States Code:
`
`1.
`
`I am an employee of Association Management Solutions, LLC (AMS), which
`
`acts under contract to the IETF Administration LLC (IETF) as the operator of the RFC
`
`Production Center. The RFC Production Center is part of the "RFC Editor" function, which
`
`prepares documents for publication and places files in an online repository for the
`
`authoritative Request for Comments (RFC) series of documents (RFC Series), and preserves
`
`records relating to these documents. The RFC Series includes, among other things, the series
`
`of Internet standards developed by the IETF. I hold the position of Director of the RFC
`
`Production Center. I began employment with AMS in this capacity on 6 January 2010.
`
`2.
`
`Among my responsibilities as Director of the RFC Production Center, I act as
`
`the custodian of records relating to the RFC Series, and I am familiar with the record keeping
`
`practices relating to the RFC Series, including the creation and maintenance of such records.
`
`
`
`
`
`0001
`
`Ex. 1007
`
`Apple V. MPH Techs. Oy
`IPR2019-00822
`
`Ex. 1007
`Apple v. MPH Techs. Oy
`IPR2019-00822
`
`0001
`
`
`
`3.
`
`From June 1999 to 5 January 2010, I was an employee of the Information
`
`Sciences Institute at University of Southern California (ISI). I held various position titles with
`
`the RFC Editor project at ISI, ending with Senior Editor.
`
`4.
`
`The RFC Editor function was conducted by ISI under contract to the United
`
`States government prior to 1998. In 1998, ISOC, in furtherance of its IETF activity, entered into
`
`the first in a series of contracts with ISI providing for ISI's performance of the RFC Editor
`
`function. Beginning in 2010, certain aspects ofthe RFC Editor function were assumed by the
`
`RFC Production Center operation of AMS under contract to ISOC (acting through its IETF
`function and, in particular, the IETF Administrative Oversight] Committee (now the IETF
`
`Administration LLC (IETF)). The business records of the RFC Editor function as it was
`
`conducted by ISI are currently housed on the computer systems of AMS, as contractor to the
`
`IETF .
`
`5.
`
`I make this declaration based on my personal knowledge and information
`
`
`
`contained in the business records of the RFC Editor as they are currently housed at AMS, or
`
`confirmation with other responsible RFC Editor personnel with such knowledge.
`
`6.
`
`Prior to 1998, the RFC Editor's regular practice was to publish RFCs, making
`
`them available from a repository via FTP. When a new RFC was published, an announcement
`
`of its publication, with information on how to access the RFC, would be typically sent out
`
`within 24 hours of the publication.
`
`7.
`
`Since 1998, the RFC Editor’s regular practice was to publish RFCs, making
`
`them available on the RFC Editor website or via FTP. When a new RFC was published, an
`
`announcement of its publication, with information on how to access the RFC, would be
`
`typically sent out within 24 hours of the publication.
`
`0002
`
`0002
`
`
`
`8.
`
`Beginning in 1998, any RFC published on the RFC Editor website or via FTP
`
`was reasonably accessible to the public and was disseminated or otherwise available to the extent
`
`that persons interested and ordinarily skilled in the subject matter or art exercising reasonable
`
`diligence could have located it. In particular, the RFCs were indexed and placed in a public
`
`repository.
`
`9.
`
`The RFCs are kept in an online repository in the course of the RFC Editor's
`
`
`
`regularly conducted activity and ordinary course of business. The records are made pursuant to
`
`established procedures and are relied upon by the RFC Editor in the performance of its functions.
`
`10.
`
`1 1.
`
`It is the regular practice of the RFC Editor to make and keep the RFC records.
`
`Based on the business records for the RFC Editor and the RFC Editor’s course
`
`of conduct in publishing RFCs, I have determined that the publication date of RFC 2401, RFC
`
`2402, RFC 2406, RFC 2408 and RFC 2409 was no later than November 1998, at which time
`
`they were reasonably accessible to the public either on the RFC Editor web site or via FTP from a
`
`repository. Copies of these RFCs are attached to this declaration as exhibits
`
`12.
`
`Based on the business records for the RFC Editor and the RFC Editor’s course of
`
`conduct in publishing RFCs, I have determined that the publication date of RFC 3102, RFC
`
`3103, and RFC 3104 was no later than October 2001, at which time they were reasonably
`
`accessible to the public either on the RFC Editor website or Via FTP from a repository. Copies
`
`of these RFCs are attached to this declaration as exhibits.
`
`Pursuant to Section 1746 of Title 28 of United States Code, I declare under penalty of
`
`perjury under the laws of the United States of America that the foregoing is true and correct
`
`and that the foregoing is based upon personal knowledge and information and is believed to be
`
`true.
`
`U)
`
`0003
`
`0003
`
`
`
`Date:
`
`483100¢¥68622
`
`7" VMYOH $0M
`
`
`
`0004
`
`0004
`
`
`
`
`
`
`
`ATTACHMENT A
`
`ATTACHMENT A
`
`0005
`
`
`
`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
`
`Kent & Atkinson Standards Track [Page 1]
`
`0006
`
`
`
`RFC 2401 Security Architecture for IP November 1998
`
`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
`
`Kent & Atkinson Standards Track [Page 2]
`
`0007
`
`
`
`RFC 2401 Security Architecture for IP November 1998
`
`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
`
`Kent & Atkinson Standards Track [Page 3]
`
`0008
`
`
`
`RFC 2401 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.
` 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
`
`Kent & Atkinson Standards Track [Page 4]
`
`0009
`
`
`
`RFC 2401 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.
`
`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]
`
`0010
`
`
`
`RFC 2401 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
` 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
`
`Kent & Atkinson Standards Track [Page 6]
`
`0011
`
`
`
`RFC 2401 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
` 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.
`
`Kent & Atkinson Standards Track [Page 7]
`
`0012
`
`
`
`RFC 2401 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
` 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
`
`Kent & Atkinson Standards Track [Page 8]
`
`0013
`
`
`
`RFC 2401 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
` 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]
`
`0014
`
`
`
`RFC 2401 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 i