IP Encapsulating Security Payload (ESP)
RFC 2406
Document | Type |
RFC - Proposed Standard
(November 1998; No errata)
Obsoletes RFC 1827
|
|
---|---|---|---|
Authors | Stephen Kent , Randall Atkinson | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 2406 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group S. Kent Request for Comments: 2406 BBN Corp Obsoletes: 1827 R. Atkinson Category: Standards Track @Home Network November 1998 IP Encapsulating Security Payload (ESP) 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..................................................2 2. Encapsulating Security Payload Packet Format..................3 2.1 Security Parameters Index................................4 2.2 Sequence Number .........................................4 2.3 Payload Data.............................................5 2.4 Padding (for Encryption).................................5 2.5 Pad Length...............................................7 2.6 Next Header..............................................7 2.7 Authentication Data......................................7 3. Encapsulating Security Protocol Processing....................7 3.1 ESP Header Location......................................7 3.2 Algorithms..............................................10 3.2.1 Encryption Algorithms..............................10 3.2.2 Authentication Algorithms..........................10 3.3 Outbound Packet Processing..............................10 3.3.1 Security Association Lookup........................11 3.3.2 Packet Encryption..................................11 3.3.3 Sequence Number Generation.........................12 3.3.4 Integrity Check Value Calculation..................12 3.3.5 Fragmentation......................................13 3.4 Inbound Packet Processing...............................13 3.4.1 Reassembly.........................................13 3.4.2 Security Association Lookup........................13 3.4.3 Sequence Number Verification.......................14 3.4.4 Integrity Check Value Verification.................15 Kent & Atkinson Standards Track [Page 1] RFC 2406 IP Encapsulating Security Payload November 1998 3.4.5 Packet Decryption..................................16 4. Auditing.....................................................17 5. Conformance Requirements.....................................18 6. Security Considerations......................................18 7. Differences from RFC 1827....................................18 Acknowledgements................................................19 References......................................................19 Disclaimer......................................................20 Author Information..............................................21 Full Copyright Statement........................................22 1. Introduction The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. ESP may be applied alone, in combination with the IP Authentication Header (AH) [KA97b], or in a nested fashion, e.g., through the use of tunnel mode (see "Security Architecture for the Internet Protocol" [KA97a], hereafter referred to as the Security Architecture document). Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. For more details on how to use ESP and AH in various network environments, see the Security Architecture document [KA97a]. The ESP header is inserted after the IP header and before the upper layer protocol header (transport mode) or before an encapsulated IP header (tunnel mode). These modes are described in more detail below. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. The set of services provided depends on options selected at the time of Security Association establishment and on the placement of the implementation. Confidentiality may be selected independent of all other services. However, use of confidentiality without integrity/authentication (either in ESP or separately in AH) mayShow full document text