~WILEY
`
`Making Security
`Work on VPN
`Intranets,
`and Extran
`
`Elizabeth Ka
`Andrew Ne
`
`Petitioner Apple Inc. - Exhibit 1072, Cover
`
`

`
`lmplementing;,~~~~~t;
`Making SecuritJJe~~,[~~
`on VPNs, lnt~,~~~!i~'
`and Ext~111111,1;.
`.. ;:
`;····"············ ............. ;;;
`Elizabeth K.ati.triaa~:
`Andrew N6~~~'f
`
`:
`
`':/::~-:::- /: ,,',,',,'
`
`,': /;''(
`
`Wiley co .. piJ(•~;;~blis~i;i
`i/ •... "~·~·.·········./;
`.... · ......
`{;
`. /·. ~:··<
`
`John Wii~J't~$()rlsilri~~·
`NEW YORK • CHICHESTER • WEINHEIM • BRISBANE • SINGAPORE • TORONTO
`
`Petitioner Apple Inc. - Exhibit 1072, Cover-2
`
`

`
`Publisher: Robert Ipsen
`Editor: Carol Long
`Assistant Editor: Margaret Hendrey
`Managing Editor: Frank Grazioli
`Text Design & Composition: Bendunark Productions, Inc.
`
`Designations used by companies to distinguish their products are often claimed as trade(cid:173)
`marks. In all instances where John Wiley & Sons, Inc., is aware of a claim, the product
`names appear in initial capital or ALL CAPITAL LETTERS. Readers, however, should contact
`the appropriate companies for more complete information regarding trademarks and reg(cid:173)
`istration.
`This book is printed on acid-free paper. e
`Copyright© 1999 by Elizabeth Kaufman and Andrew Newman. All rights reserved.
`
`Published by John Wiley & Sons, Inc.
`
`Published simultaneously in Canada.
`
`No part of this publication may be reproduced, stored in a retrieval system or transmitted
`in any form or by any means, electronic, mechanical, photocopying, recording, scanning
`or otherwise, except as pennitted under Sections 107 or 108 of the 1976 United States
`Copyright Act, without either the prior written permission of the Publisher, or authoriza(cid:173)
`tion through payment of the appropriate per-copy fee to the Copyright Clearance Center,
`222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4744. Requests to
`the Publisher for pennission should be addressed to the Permissions Department, John
`Wiley & Sons, Inc., 605 Third Avenue, New York, NY 10158-0012, (212) 850-6011, fax (212)
`850-6008, E-Mail: PERMREQ@ WILEY. COM.
`
`This publication is designed to provide accurate and authoritative information in regard
`to the subject matter covered. It is sold with the understanding that the publisher is not
`engaged in professional services. If professional advice or other expert assistance is
`required, the services of a competent professional person should be sought.
`
`Authors' Disclaimer: Neither of our employers (Cisco Systems, Inc. and Yale University)
`had anything to do with this book or its contents. The opinions expressed are our own.
`
`Library of Congress Cataloging-in-Publicatiotf Data:
`
`ISBN 0-471-34467-2
`
`Printed in the United States of America.
`
`10 9 8 7 6 5 4 3 2 1
`
`Petitioner Apple Inc. - Exhibit 1072, Copyright
`
`

`
`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 ........................................................ 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
`
`173
`
`Petitioner Apple Inc. - Exhibit 1072, p. 173
`
`

`
`17 4
`
`Implementing IPsec
`
`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 S.ecurity Policy Database (SPD) ......................... 14
`4. 4. 2 Selectors .................................................. 1 7
`4.4.3 Security Association Database (SAD) ........................ 21
`4.5 Basic Combinations of Security Associations ..................... 24
`4. 6 SA and Key Management ........................................... 2 6
`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
`
`Petitioner Apple Inc. - Exhibit 1072, p. 174
`
`

`
`Appendix 1 7 5
`
`Kent & Atkinson
`
`Standards Track
`
`[Page 1)
`
`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 ................................... 3 7
`6.1.2.3 Granularity of PMTU Processing ........................ 37
`6 . 1 . 2 . 4 PMTU Aging ............................................ 3 8
`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
`
`Petitioner Apple Inc. - Exhibit 1072, p. 175
`
`

`
`176
`
`Implementing IPse(
`
`Kent & Atkinson
`
`Standards Track
`
`[Page 2]
`
`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
`followi~g 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
`
`Petitioner Apple Inc. - Exhibit 1072, p. 176
`
`

`
`Appendix 1 77
`
`Kent & Atkinson
`
`Standards Track
`
`[Page 3]
`
`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:
`
`[TDG97] -- a document
`a. "IP Security Document Roadmap"
`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
`
`Petitioner Apple Inc. - Exhibit 1072, p. 177
`
`

`
`178
`
`Implementing IPsec
`
`Kent & Atkinson
`
`Standards Track
`
`[Page 4]
`
`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 sui,te 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
`
`Petitioner Apple Inc. - Exhibit 1072, p. 178
`
`

`
`Appendix 179
`
`Kent & Atkinson
`
`Standards Track
`
`[Page 5]
`
`RFC 2401
`
`Security Architecture for IP
`
`November 1998
`
`In general, packets are selected
`established by either of the above.
`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 -(cid:173)
`Authentication Header (AH} and Encapsulating Security Payload (ESP}.
`Both protocols are described in more detail in their respective RFCs
`[KA98a, KA98b].
`
`[KA98a] provides
`o The IP Authentication Header (AH}
`connectionless integrity, data origin authentication, and an
`optional anti-replay service.
`o The Encapsulating Security Payload (ESP} protocol [KA98bl may
`provide confidentiality (encryption}, and limited traffic flow
`confidentiality. It also may provide connectionless
`
`Petitioner Apple Inc. - Exhibit 1072, p. 179
`
`

`
`180
`
`Implementing IPsec
`
`Kent & Atkinson
`
`Standards Track
`
`[Page 6]
`
`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 qllows 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.
`
`Petitioner Apple Inc. - Exhibit 1072, p. 180
`
`

`
`Appendix 181
`
`Kent & Atkinson
`
`Standards Track
`
`[Page 7)
`
`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
`
`Petitioner Apple Inc. - Exhibit 1072, p. 181
`
`

`
`182
`
`Implementing IPsec
`
`Kent & Atkinson
`
`Standards Track
`
`[Page 8]
`
`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 h~ader, 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.
`
`Petitioner Apple Inc. - Exhibit 1072, p. 182
`
`

`
`Appendix 183
`
`Kent & Atkinson
`
`Standards Track
`
`[Page 9]
`
`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.)
`
`(The strength
`ESP optionally provides confidentiality for traffic.
`of the confidentiality service depends in part, on the encryption
`algorithm employed.) ESP also may optionally provide authentication
`(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
`
`Petitioner Apple Inc. - Exhibit 1072, p. 183
`
`

`
`184
`
`Implementing IPsec
`
`Kent & Atkinson
`
`Standards Track
`
`[Page 10)
`
`RFC 2401
`
`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
`vulnerabll: 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. f
`
`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
`
`Host 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
`
`Petitioner Apple Inc. - Exhibit 1072, p. 184
`
`

`
`Kent & Atkinson
`
`Standards Track
`
`[Page 11]
`
`R