"IP Encapsulating Security Payload (ESP)", Stephen Kent, 10-Mar-05. (117985 bytes)
This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. 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. This document obsoletes RFC 2406 (November 1998).
"Internet Key Exchange (IKEv2) Protocol", Charlie Kaufman, 4-Oct-04. (268610 bytes)
This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs).
"IP Authentication Header", Stephen Kent, 21-Mar-05. (83453 bytes)
This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document obsoletes RFC 2402 (November 1998).
"Extended Sequence Number Addendum to IPsec DOI for ISAKMP", Stephen Kent, 16-Feb-04. (10195 bytes)
The IP Security Authentication Header (AH) and Encapsulating Security Payload (ESP) protocols use a sequence number to detect replay. This document describes extensions to the Internet IP Security Domain of Interpretation (DOI) for the Internet Security Association and Key Management Protocol(ISAKMP). These extensions support negotiation of the use of traditional 32-bit sequence numbers or extended 64-bit sequence numbers for a particular AH or ESP security association.
"Using AES CCM Mode With IPsec ESP", Russ Housley, 20-Nov-03. (28558 bytes)
This document describes the use of AES CCM Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality, data origin authentication, connectionless integrity.
"Cryptographic Algorithms for use in the Internet Key Exchange Version 2", Jeffrey Schiller, 21-Apr-04. (13007 bytes)
The IPSec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE [RFC2409] and IKEv2 [IKEv2]) provide a mechanism to negotiate which algorithms should be used in any even association. However to ensure interoperability between disparate implementations it is necessary to specify a set of mandatory to implement algorithms to ensure at least one algorithm that all implementations will have available. This document defines the current set of mandatory to implement algorithms for use of IKEv2 as well as specifying algorithms that should be implemented because they made be promoted to mandatory at some future time.
"Cryptographic Suites for IPsec", Paul Hoffman, 14-Apr-04. (9093 bytes)
The IPsec, IKE, and IKEv2 protocols rely on security algorithms to provide privacy and authentication between the initiator and responder. There are many such algorithms available, and two IPsec systems cannot interoperate unless they are using the same algorithms. This document specifies optional suites of algorithms and attributes that can be used to simplify the administration of IPsec when used in manual keying mode, with IKE version 1, or with IKEv2.
"Security Architecture for the Internet Protocol", Stephen Kent, Karen Seo, 1-Apr-05. (260520 bytes)
This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). Comments should be sent to Stephen Kent (kent@bbn.com). [RFC Editor: Please remove this line prior to publication as an RFC.]
"Cryptographic Algorithm Implementation Requirements For ESP And AH", Donald Eastlake 3rd, 23-Aug-04. (17133 bytes)
The IPSEC series of protocols makes use of various cryptographic algorithms in order to provide security services. The Encapsulating Security Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPSEC Security Association (SA). To ensure interoperability between disparate implementations it is necessary to specify a set of mandatory to implement algorithms to ensure at least one algorithm that all implementations will have available. This document defines the current set of mandatory to implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time.

IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.

Return to Internet-Draft directory.

Return to IETF home page.