Cryptographic Suites for IPsec
RFC 4308

Document Type RFC - Proposed Standard (December 2005; Errata)
Author Paul Hoffman 
Last updated 2020-01-21
Stream Internet Engineering Task Force (IETF)
Formats plain text html pdf htmlized (tools) htmlized with errata bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 4308 (Proposed Standard)
Action Holders
Consensus Boilerplate Unknown
Telechat date
Responsible AD Russ Housley
Send notices to (None)
Network Working Group                                         P. Hoffman
Request for Comments: 4308                                VPN Consortium
Category: Standards Track                                  December 2005

                     Cryptographic Suites for IPsec

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 (2005).


   The IPsec, Internet Key Exchange (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 IKEv1
   or with IKEv2.

1.  Introduction

   This document is a companion to IPsec [RFC2401] and its two key
   exchange protocols, IKE [RFC2409] and IKEv2 [IKEv2].  Like most
   security protocols, IPsec, IKE, and IKEv2 allow users to chose which
   cryptographic algorithms they want to use to meet their security

   Implementation experience with IPsec in manual key mode and with IKE
   has shown that there are so many choices for typical system
   administrators to make that it is difficult to achieve
   interoperability without careful pre-agreement.  Because of this, the
   IPsec Working Group agreed that there should be a small number of
   named suites that cover typical security policies.  These suites may
   be presented in the administrative interface of the IPsec system.
   These suites, often called "UI suites" ("user interface suites"), are
   optional and do not prevent implementers from allowing individual
   selection of the security algorithms.

Hoffman                     Standards Track                     [Page 1]
RFC 4308             Cryptographic Suites for IPsec        December 2005

   Although the UI suites listed here are optional to implement, this
   document is on the standards track because implementers who call
   particular suites by the names used here have to conform to the
   suites listed in this document.  These suites should not be
   considered extensions to IPsec, IKE, and IKEv2, but instead
   administrative methods for describing sets of configurations.

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
   in this document are to be interpreted as described in [RFC2119].

2.  UI Suites

   This section lists optional, non-mandatory suites that may be
   presented to system administrators to ease the burden of choosing
   among the many options in IPsec systems.  These suites cannot cover
   all of the options that an administrator needs to select.  Instead,
   they give values for a subset of the options.

   Note that these UI suites are simply collections of values for some
   options in IPsec.  Use of UI suites does not change the IPsec, IKE,
   or IKEv2 protocols in any way.  Specifically, the transform
   substructure in IKE and IKEv2 must be used to give the value for each
   specified option regardless of whether or not UI suites are used.

   Implementations that use UI suites SHOULD also provide a management
   interface for specifying values for individual cryptographic options.
   That is, it is unlikely that UI suites are a complete solution for
   matching the security policies of many IPsec users, and therefore an
   interface that gives a more complete set of options should be used as

   IPsec implementations that use these UI suites SHOULD use the suite
   names listed here.  IPsec implementations SHOULD NOT use names
   different than those listed here for the suites that are described,
   and MUST NOT use the names listed here for suites that do not match
   these values.  These requirements are necessary for interoperability.

   Note that the suites listed here are for use of IPsec in virtual
   private networks.  Other uses of IPsec will probably want to define
   their own suites and give them different names.

   Additional suites can be defined by RFCs.  The strings used to
   identify UI suites are registered by IANA.

Hoffman                     Standards Track                     [Page 2]
RFC 4308             Cryptographic Suites for IPsec        December 2005

2.1.  Suite "VPN-A"

   This suite matches the commonly used corporate VPN security used in
   IKEv1 at the time of this document's publication.

   Protocol               Encapsulating Security Payload (ESP) [RFC2406]
   ESP encryption         TripleDES in CBC mode [RFC2451]
Show full document text