Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6071

IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap

Pages: 63
Informational
Obsoletes:  2411
Part 3 of 4 – Pages 36 to 49
First   Prev   Next

Top   ToC   RFC6071 - Page 36   prevText

6. IPsec/IKE for Multicast

[RFC4301] describes IPsec processing for unicast and multicast traffic. However, classical IPsec SAs provide point-to-point protection; the security afforded by IPsec's cryptographic algorithms is not applicable when the SA is one-to-many or many-to-many, the case for multicast. The Multicast Security (msec) Working Group has defined alternatives to IKE and extensions to IPsec for use with
Top   ToC   RFC6071 - Page 37
   multicast traffic.  Different multicast groups have differing
   characteristics and requirements: number of senders (one-to-many or
   many-to-many), number of members (few, moderate, very large),
   volatility of membership, real-time delivery, etc.  Their security
   requirements vary as well.  Each solution defined by msec applies to
   a subset of the large variety of possible multicast groups.

6.1. RFC 3740, The Multicast Group Security Architecture (I, March 2004)

[RFC3740] defines the multicast security architecture, which is used to provide security for packets exchanged by large multicast groups. It defines the components of the architectural framework; discusses Group Security Associations (GSAs), key management, data handling, and security policies. Several existing protocols, including Group DOI (GDOI) [RFC3547], Group Secure Association Key Management Protocol (GSAKMP) [RFC4535], and Multimedia Internet KEYing (MIKEY) [RFC3830], satisfy the group key management requirements defined in this document. Both the architecture and the components for Multicast Group Security differ from IPsec.

6.2. RFC 5374, Multicast Extensions to the Security Architecture for the Internet Protocol (S, November 2008)

[RFC5374] extends the security architecture defined in [RFC4301] to apply to multicast traffic. It defines a new class of SAs (GSAs - Group Security Associations) and additional databases used to apply IPsec protection to multicast traffic. It also describes revisions and additions to the processing algorithms in [RFC4301].

6.3. RFC 3547, The Group Domain of Interpretation (S, July 2003)

GDOI [RFC3547] extends IKEv1 so that it can be used to establish SAs to protect multicast traffic. This document defines additional exchanges and payloads to be used for that purpose.

6.4. RFC 4046, Multicast Security (MSEC) Group Key Management Architecture (I, April 2005)

[RFC4046] sets out the general requirements and design principles for protocols that are used for multicast key management. It does not go into the specifics of an individual protocol that can be used for that purpose.
Top   ToC   RFC6071 - Page 38

6.5. RFC 4359, The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH) (S, January 2006)

[RFC4359] describes the use of the RSA digital signature algorithm to provide integrity protection for multicast traffic within ESP and AH. The algorithms used for integrity protection for unicast traffic (e.g., HMAC) are not suitable for this purpose when used with multicast traffic.

7. Outgrowths of IPsec/IKE

Operational experience with IPsec revealed additional capabilities that could make IPsec more useful in real-world scenarios. These include support for IPsec policy mechanisms, IPsec MIBs, payload compression (IPComp), extensions to facilitate additional peer authentication methods (Better-Than-Nothing Security (BTNS), Kerberized Internet Negotiation of Keys (KINK), and IPSECKEY), and additional capabilities for VPN clients (IPSRA).

7.1. IPsec Policy

The IPsec Policy (ipsp) Working Group originally planned an RFC that would allow entities with no common Trust Anchor and no prior knowledge of each other's security policies to establish an IPsec- protected connection. The solutions that were proposed for gateway discovery and security policy negotiation proved to be overly complex and fragile, in the absence of prior knowledge or compatible configuration policies.

7.1.1. RFC 3586, IP Security Policy (IPSP) Requirements (S, August 2003)

[RFC3586] describes the functional requirements of a generalized IPsec policy framework, that could be used to discover, negotiate, and manage IPsec policies.

7.1.2. RFC 3585, IPsec Configuration Policy Information Model (S, August 2003)

As stated in [RFC3585]: This document presents an object-oriented information model of IP Security (IPsec) policy designed to facilitate agreement about the content and semantics of IPsec policy, and enable derivations of task-specific representations of IPsec policy such as storage schema, distribution representations, and policy specification languages used to configure IPsec-enabled endpoints.
Top   ToC   RFC6071 - Page 39
   This RFC has not been widely adopted.

7.2. IPsec MIBs

Over the years, several MIB-related Internet Drafts were proposed for IPsec and IKE, but only one progressed to RFC status.

7.2.1. RFC 4807, IPsec Security Policy Database Configuration MIB (S, March 2007)

[RFC4807] defines a MIB module that can be used to configure the SPD of an IPsec device. This RFC has not been widely adopted.

7.3. IPComp (Compression)

The IP Payload Compression Protocol (IPComp) is a protocol that provides lossless compression for IP datagrams. Although IKE can be used to negotiate the use of IPComp in conjunction with IPsec, IPComp can also be used when IPsec is not applied. The IPComp protocol allows the compression of IP datagrams by supporting different compression algorithms. Three of these algorithms are: DEFLATE [RFC2394], LZS [RFC2395], and the ITU-T V.44 Packet Method [RFC3051], which is based on the LZJH algorithm.

7.3.1. RFC 3173, IP Payload Compression Protocol (IPComp) (S, September 2001)

IP payload compression is especially useful when IPsec-based encryption is applied to IP datagrams. Encrypting the IP datagram causes the data to be random in nature, rendering compression at lower protocol layers ineffective. If IKE is used to negotiate compression in conjunction with IPsec, compression can be performed prior to encryption. [RFC3173] defines the payload compression protocol, the IPComp packet structure, the IPComp Association (IPCA), and several methods to negotiate the IPCA.

7.4. Better-Than-Nothing Security (BTNS)

One of the major obstacles to widespread implementation of IPsec is the lack of pre-existing credentials that can be used for peer authentication. Better-Than-Nothing Security (BTNS) is an attempt to sidestep this problem by allowing IKE to negotiate unauthenticated (anonymous) IPsec SAs, using credentials such as self-signed certificates or "bare" public keys (public keys that are not connected to a public key certificate) for peer authentication. This ensures that subsequent traffic protected by the SA is conducted with
Top   ToC   RFC6071 - Page 40
   the same peer, and protects the communications from passive attack.
   These SAs can then be cryptographically bound to a higher-level
   application protocol, which performs its own peer authentication.

7.4.1. RFC 5660, IPsec Channels: Connection Latching (S, October 2009)

[RFC5660] specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create channels by latching connections (packet flows) to certain IPsec Security Association (SA) parameters for the lifetime of the connections. Connection latching is layered on top of IPsec and does not modify the underlying IPsec architecture.

7.4.2. RFC 5386, Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec (S, November 2008)

[RFC5386] specifies how to use IKEv2 to set up unauthenticated security associations (SAs) for use with the IPsec Encapsulating Security Payload (ESP) and the IPsec Authentication Header (AH). This document does not require any changes to the bits on the wire, but specifies extensions to the Peer Authorization Database (PAD) and Security Policy Database (SPD).

7.4.3. RFC 5387, Problem and Applicability Statement for Better-Than- Nothing Security (BTNS) (I, November 2008)

[RFC5387] considers that the need to deploy authentication information and its associated identities is a significant obstacle to the use of IPsec. This document explains the rationale for extending the Internet network security protocol suite to enable use of IPsec security services without authentication.

7.5. Kerberized Internet Negotiation of Keys (KINK)

Kerberized Internet Negotiation of Keys (KINK) is an attempt to provide an alternative to IKE for IPsec peer authentication. It uses Kerberos, instead of IKE, to establish IPsec SAs. For enterprises that already deploy the Kerberos centralized key management system, IPsec can then be implemented without the need for additional peer credentials. Some vendors have implemented proprietary extensions for using Kerberos in IKEv1, as an alternative to the use of KINK. These extensions, as well as the KINK protocol, apply only to IKEv1, and not to IKEv2.
Top   ToC   RFC6071 - Page 41

7.5.1. RFC 3129, Requirements for Kerberized Internet Negotiation of Keys (I, June 2001)

[RFC3129] considers that peer-to-peer authentication and keying mechanisms have inherent drawbacks such as computational complexity and difficulty in enforcing security policies. This document specifies the requirements for using basic features of Kerberos and uses them to its advantage to create a protocol that can establish and maintain IPsec security associations ([RFC2401]).

7.5.2. RFC 4430, Kerberized Internet Negotiation of Keys (KINK) (S, March 2006)

[RFC4430] defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to establish and maintain security associations using the Kerberos authentication system. This document reuses the Quick Mode payloads of IKEv1 in order to foster substantial reuse of IKEv1 implementations. This RFC has not been widely adopted.

7.6. IPsec Secure Remote Access (IPSRA)

IPsec Secure Remote Access (IPSRA) was an attempt to extend IPsec protection to "road warriors", allowing IKE to authenticate not only the user's device but also the user, without changing IKEv1. The working group defined generic requirements of different IPsec remote access scenarios. An attempt was made to define an IKE-like protocol that would use legacy authentication mechanisms to create a temporary or short-lived user credential that could be used for peer authentication within IKE. This protocol proved to be more cumbersome than standard Public Key protocols, and was abandoned. This led to the development of IKEv2, which incorporates the use of EAP for user authentication.

7.6.1. RFC 3457, Requirements for IPsec Remote Access Scenarios (I, January 2003)

[RFC3457] explores and enumerates the requirements of various IPsec remote access scenarios, without suggesting particular solutions for them.

7.6.2. RFC 3456, Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode (S, January 2003)

[RFC3456] explores the requirements for host configuration in IPsec tunnel mode, and describes how the Dynamic Host Configuration Protocol (DHCPv4) may be used for providing such configuration information. This RFC has not been widely adopted.
Top   ToC   RFC6071 - Page 42

7.7. IPsec Keying Information Resource Record (IPSECKEY)

The IPsec Keying Information Resource Record (IPSECKEY) enables the storage of public keys and other information that can be used to facilitate opportunistic IPsec in a new type of DNS resource record.

7.7.1. RFC 4025, A method for storing IPsec keying material in DNS (S, February 2005)

[RFC4025] describes a method of storing IPsec keying material in the DNS using a new type of resource record. This document describes how to store the public key of the target node in this resource record. This RFC has not been widely adopted.

8. Other Protocols That Use IPsec/IKE

IPsec and IKE were designed to provide IP-layer security protection to other Internet protocols' traffic as well as generic communications. Since IPsec is a general-purpose protocol, in some cases, its features do not provide the granularity or distinctive features required by another protocol; in some cases, its overhead or prerequisites do not match another protocol's requirements. However, a number of other protocols do use IKE and/or IPsec to protect some or all of their communications.

8.1. Mobile IP (MIPv4 and MIPv6)

8.1.1. RFC 4093, Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways (I, August 2005)

[RFC4093] describes the issues with deploying Mobile IPv4 across virtual private networks (VPNs). IPsec is one of the VPN technologies covered by this document. It identifies and describes practical deployment scenarios for Mobile IPv4 running alongside IPsec in enterprise and operator environments. It also specifies a set of framework guidelines to evaluate proposed solutions for supporting multi-vendor seamless IPv4 mobility across IPsec-based VPN gateways.

8.1.2. RFC 5265, Mobile IPv4 Traversal across IPsec-Based VPN Gateways (S, June 2008)

[RFC5265] describes a basic solution that uses Mobile IPv4 and IPsec to provide session mobility between enterprise intranets and external networks. The proposed solution minimizes changes to existing firewall/VPN/DMZ deployments and does not require any changes to IPsec or key exchange protocols. It also proposes a mechanism to minimize IPsec renegotiation when the mobile node moves.
Top   ToC   RFC6071 - Page 43

8.1.3. RFC 3776, Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents (S, June 2004)

This document specifies the use of IPsec in securing Mobile IPv6 traffic between mobile nodes and home agents. It specifies the required wire formats for the protected packets and illustrates examples of Security Policy Database and Security Association Database entries that can be used to protect Mobile IPv6 signaling messages. It also describes how to configure either manually keyed IPsec security associations or IKEv1 to establish the SAs automatically. Mobile IPv6 requires considering the home address destination option and Routing Header in IPsec processing. Also, IPsec and IKE security association addresses can be updated by Mobile IPv6 signaling messages.

8.1.4. RFC 4877, Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture (S, April 2007)

This document updates [RFC3776] in order to work with the revised IPsec architecture [RFC4301]. Since the revised IPsec architecture expands the list of selectors to include the Mobility Header message type, it becomes much easier to differentiate between different mobility header messages. Since the ICMP message type and code are also newly added as selectors, this document uses them to protect Mobile Prefix Discovery messages. This document also specifies the use of IKEv2 configuration payloads for dynamic home address configuration. Finally, this document describes the use of IKEv2 in order to set up the SAs for Mobile IPv6.

8.1.5. RFC 5026, Mobile IPv6 Bootstrapping in Split Scenario (S, October 2007)

[RFC5026] extends [RFC4877] to support dynamic discovery of home agents and the home network prefix; for the latter purpose, it specifies a new IKEv2 configuration attribute and notification. It describes how a Mobile IPv6 node can obtain the address of its home agent, its home address, and create IPsec security associations with its home agent using DNS lookups and security credentials preconfigured on the Mobile Node. It defines how a mobile node (MN) can request its home address and home prefixes through the Configuration Payload in the IKE_AUTH exchange and what attributes need to be present in the CFG_REQUEST messages in order to do this. It also specifies how the home agent can authorize the credentials used for IKEv2 exchange.
Top   ToC   RFC6071 - Page 44

8.1.6. RFC 5213, Proxy Mobile IPv6 (S, August 2008)

[RFC5213] describes a network-based mobility management protocol that is used to provide mobility services to hosts without requiring their participation in any mobility-related signaling. It uses IPsec to protect the mobility signaling messages between the two network entities called the mobile access gateway (MAG) and the local mobility anchor (LMA). It also uses IKEv2 in order to set up the security associations between the MAG and the LMA.

8.1.7. RFC 5568, Mobile IPv6 Fast Handovers (S, July 2009)

When Mobile IPv6 is used for a handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. [RFC5568] specifies a protocol between the Previous Access Router (PAR) and the New Access Router (NAR) to improve handover latency due to Mobile IPv6 procedures. It uses IPsec ESP in transport mode with integrity protection for protecting the signaling messages between the PAR and the NAR. It also describes the SPD entries and the PAD entries when IKEv2 is used for setting up the required SAs.

8.1.8. RFC 5380, Hierarchical Mobile IPv6 (HMIPv6) Mobility Management (S, October 2008)

[RFC5380] describes extensions to Mobile IPv6 and IPv6 Neighbor Discovery to allow for local mobility handling in order to reduce the amount of signaling between the mobile node, its correspondent nodes, and its home agent. It also improves handover speed of Mobile IPv6. It uses IPsec for protecting the signaling between the mobile node and a local mobility management entity called the Mobility Anchor Point (MAP). The MAP also uses IPsec Peer Authorization Database (PAD) entries and configuration payloads described in [RFC4877] in order to allocate a Regional Care-of Address (RCoA) for mobile nodes.

8.2. Open Shortest Path First (OSPF)

8.2.1. RFC 4552, Authentication/Confidentiality for OSPFv3 (S, June 2006)

OSPF is a link-state routing protocol that is designed to be run inside a single Autonomous System. OSPFv2 provided its own authentication mechanisms using the AuType and Authentication protocol header fields but OSPFv3 removed these fields and uses IPsec instead. [RFC4552] describes how to use IPsec ESP and AH in order to protect OSPFv3 signaling between two routers. It also enumerates the IPsec capabilities the routers require in order to support this specification. Finally, it also describes the operation of OSPFv3
Top   ToC   RFC6071 - Page 45
   with IPsec over virtual links where the other endpoint is not known
   at configuration time.  Since OSPFv3 exchanges multicast packets as
   well as unicast ones, the use of IKE within OSPFv3 is not
   appropriate.  Therefore, this document mandates the use of manual
   keys.

8.3. Host Identity Protocol (HIP)

8.3.1. RFC 5201, Host Identity Protocol (E, April 2008)

IP addresses perform two distinct functions: host identifier and locator. This document specifies a protocol that allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses. This enables continuity of communications across IP address (locator) changes. It uses public key identifiers from a new Host Identity (HI) namespace for peer authentication. It uses the HMAC-SHA-1-96 and the AES-CBC algorithms with IPsec ESP and AH for protecting its signaling messages.

8.3.2. RFC 5202, Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) (E, April 2008)

The HIP base exchange specification [RFC5201] does not describe any transport formats or methods for describing how ESP is used to protect user data to be used during the actual communication. [RFC5202] specifies a set of HIP extensions for creating a pair of ESP Security Associations (SAs) between the hosts during the base exchange. After the HIP association and required ESP SAs have been established between the hosts, the user data communication is protected using ESP. In addition, this document specifies how the ESP Security Parameter Index (SPI) is used to indicate the right host context (host identity) and methods to update an existing ESP Security Association.

8.3.3. RFC 5206, End-Host Mobility and Multihoming with the Host Identity (E, April 2008)

When a host uses HIP, the overlying protocol sublayers (e.g., transport layer sockets) and Encapsulating Security Payload (ESP) Security Associations (SAs) are bound to representations of these host identities, and the IP addresses are only used for packet forwarding. [RFC5206] defines a generalized LOCATOR parameter for use in HIP messages that allows a HIP host to notify a peer about alternate addresses at which it is reachable. It also specifies how a host can change its IP address and continue to send packets to its peers without necessarily rekeying.
Top   ToC   RFC6071 - Page 46

8.3.4. RFC 5207, NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) (I, April 2008)

[RFC5207] discusses the problems associated with HIP communication across network paths that include network address translators and firewalls. It analyzes the impact of NATs and firewalls on the HIP base exchange and the ESP data exchange. It discusses possible changes to HIP that attempt to improve NAT and firewall traversal and proposes a rendezvous point for letting HIP nodes behind a NAT be reachable. It also suggests mechanisms for NATs to be more aware of the HIP messages.

8.4. Stream Control Transmission Protocol (SCTP)

8.4.1. RFC 3554, On the Use of Stream Control Transmission Protocol (SCTP) with IPsec (S, July 2003)

The Stream Control Transmission Protocol (SCTP) is a reliable transport protocol operating on top of a connection-less packet network such as IP. [RFC3554] describes functional requirements for IPsec and IKE to be used in securing SCTP traffic. It adds support for SCTP in the form of a new ID type in IKE [RFC2409] and implementation choices in the IPsec processing to account for the multiple source and destination addresses associated with a single SCTP association. This document applies only to IKEv1 and IPsec-v2; it does not apply to IKEv2 AND IPsec-v3.

8.5. Robust Header Compression (ROHC)

8.5.1. RFC 3095, RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed (S, July 2001)

ROHC is a framework for header compression, intended to be used in resource-constrained environments. [RFC3095] applies this framework to four protocols, including ESP.

8.5.2. RFC 5225, RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP, and UDP-Lite (S, April 2008)

[RFC5225] defines an updated ESP/IP profile for use with ROHC version 2. It analyzes the ESP header and classifies the fields into several classes like static, well-known, irregular, etc., in order to efficiently compress the headers.
Top   ToC   RFC6071 - Page 47

8.5.3. RFC 5856, Integration of Robust Header Compression over IPsec Security Associations (I, May 2010)

[RFC5856] describes a mechanism to compress inner IP headers at the ingress point of IPsec tunnels and to decompress them at the egress point. Since the Robust Header Compression (ROHC) specifications only describe operations on a per-hop basis, this document also specifies extensions to enable ROHC over multiple hops. This document applies only to tunnel mode SAs and does not support transport mode SAs.

8.5.4. RFC 5857, IKEv2 Extensions to Support Robust Header Compression over IPsec (S, May 2010)

ROHC requires initial configuration at the compressor and decompressor ends. Since ROHC usually operates on a per-hop basis, this configuration information is carried over link-layer protocols such as PPP. Since [RFC5856] operates over multiple hops, a different signaling mechanism is required. [RFC5857] describes how to use IKEv2 in order to dynamically communicate the configuration parameters between the compressor and decompressor.

8.5.5. RFC 5858, IPsec Extensions to Support Robust Header Compression over IPsec (S, May 2010)

[RFC5856] describes how to use ROHC with IPsec. This is not possible without extensions to IPsec. [RFC5858] describes the extensions needed to IPsec in order to support ROHC. Specifically, it describes extensions needed to the IPsec SPD, SAD, and IPsec processing including ICV computation and integrity verification.

8.6. Border Gateway Protocol (BGP)

8.6.1. RFC 5566, BGP IPsec Tunnel Encapsulation Attribute (S, June 2009)

[RFC5566] adds an additional BGP Encapsulation Subsequent Address Family Identifier (SAFI), allowing the use of IPsec and, optionally, IKE to protect BGP tunnels. It defines the use of AH and ESP in tunnel mode and the use of AH and ESP in transport mode to protect IP in IP and MPLS-in-IP tunnels. It also defines how public key fingerprints (hashes) are distributed via BGP and used later to authenticate IKEv2 exchange between the tunnel endpoints.

8.7. IPsec Benchmarking

The Benchmarking Methodology WG in the IETF is working on documents that relate to benchmarking IPsec [BMWG-1] [BMWG-2].
Top   ToC   RFC6071 - Page 48

8.7.1. Methodology for Benchmarking IPsec Devices (Work in Progress)

[BMWG-1] defines a set of tests that can be used to measure and report the performance characteristics of IPsec devices. It extends the methodology defined for benchmarking network interconnecting devices to include IPsec gateways and adds further tests that can be used to measure IPsec performance of end-hosts. The document focuses on establishing a performance testing methodology for IPsec devices that support manual keying and IKEv1, but does not cover IKEv2.

8.7.2. Terminology for Benchmarking IPsec Devices (Work in Progress)

[BMWG-2] defines the standardized performance testing terminology for IPsec devices that support manual keying and IKEv1. It also describes the benchmark tests that would be used to test the performance of the IPsec devices.

8.8. Network Address Translators (NAT)

8.8.1. RFC 2709, Security Model with Tunnel-mode IPsec for NAT domains (I, October 1999)

NAT devices provide transparent routing to end-hosts trying to communicate from disparate address realms, by modifying IP and transport headers en route. This makes it difficult for applications to pursue end-to-end application-level security. [RFC2709] describes a security model by which tunnel mode IPsec security can be architected on NAT devices. It defines how NATs administer security policies and SA attributes based on private realm addressing. It also specifies how to operate IKE in such scenarios by specifying an IKE-ALG (Application Level Gateway) that translates policies from private realm addressing into public addressing. Although the model presented here uses terminology from IKEv1, it can be deployed within IKEv1, IKEv2, IPsec-v2, and IPsec-v3. This security model has not been widely adopted

8.9. Session Initiation Protocol (SIP)

8.9.1. RFC 3329, Security Mechanism Agreement for the Session Initiation Protocol (SIP) (S, January 2003)

[RFC3329] describes how a SIP client can select one of the various available SIP security mechanisms. In particular, the method allows secure negotiation to prevent bidding down attacks. It also describes a security mechanism called ipsec-3gpp and its associated parameters (algorithms, protocols, mode, SPIs and ports) as they are used in the 3GPP IP Multimedia Subsystem.
Top   ToC   RFC6071 - Page 49

8.10. Explicit Packet Sensitivity Labels

8.10.1. RFC 5570, Common Architecture Label IPv6 Security Option (CALIPSO) (I, July 2009)

[RFC5570] describes a mechanism used to encode explicit packet Sensitivity Labels on IPv6 packets in Multi-Level Secure (MLS) networks. The method is implemented using an IPv6 hop-by-hop option. This document uses the IPsec Authentication Header (AH) in order to detect any malicious modification of the Sensitivity Label in a packet.


(page 49 continued on part 4)

Next Section