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]
`
`Ex. 1007
`Apple v. MPH Techs. Oy
`IPR2019-00821
`
`

`

`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]
`
`

`

`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]
`
`

`

`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]
`
`

`

`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]
`
`

`

`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]
`
`

`

`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]
`
`

`

`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]
`
`

`

`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]
`
`

`

`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 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
`
`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
` 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 --- 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]
`
`

`

`RFC 2401 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)--------------
`
` 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)---- |
` |