Guidelines for Specifying the Use of IPsec Version 2
RFC 5406

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 10

Network Working Group                                        S. Bellovin
Request for Comments: 5406                           Columbia University
BCP: 146                                                   February 2009
Category: Best Current Practice

          Guidelines for Specifying the Use of IPsec Version 2

Status of This Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Abstract

   The Security Considerations sections of many Internet Drafts say, in
   effect, "just use IPsec".  While this is sometimes correct, more
   often it will leave users without real, interoperable security
   mechanisms.  This memo offers some guidance on when IPsec Version 2
   should and should not be specified.

Bellovin                 Best Current Practice                  [Page 1]
RFC 5406                      IPsec Usage                  February 2009

1.  Introduction

   The Security Considerations sections of many Internet Drafts say, in
   effect, "just use IPsec".  While the use of IPsec is sometimes the
   correct security solution, more information is needed to provide
   interoperable security solutions.  In some cases, IPsec is
   unavailable in the likely endpoints.  If IPsec is unavailable to --
   and hence unusable by -- a majority of the users in a particular
   protocol environment, then the specification of IPsec is tantamount
   to saying "turn off security" within this community.  Further, when
   IPsec is available, the implementation may not provide the proper
   granularity of protection.  Finally, if IPsec is available and
   appropriate, the document mandating the use of IPsec needs to specify
   just how it is to be used.

   The goal of this document is to provide guidance to protocol
   designers on the specification of IPsec when it is the appropriate
   security mechanism.  The protocol specification is expected to
   provide realistic, interoperable security.  Therefore, guidance on
   the configuration of the various IPsec databases, such as the
   Security Policy Database (SPD), is often required.

   This document describes how to specify the use of IPsec Version 2
   [RFC2401] including the ESPv2 (Encapsulating Security Payload version
   2) [RFC2406], AHv2 (Authentication Header version 2) [RFC2402], and
   IKEv1 (Internet Key Exchange version 1) [RFC2409].  A separate
   document will describe the IPsec Version 3 suite [RFC4301] [RFC4302]
   [RFC4303] [RFC4306].

   For further guidance on security considerations (including discussion
   of IPsec), see [RFC3552].

   NOTE: Many of the arguments below relate to the capabilities of
   current implementations of IPsec.  These may change over time; this
   advice is based on the knowledge available to the IETF at publication
   time.

2.  WARNING

   The design of security protocols is a subtle and difficult art.  The
   cautions here about specifying the use of IPsec should NOT be taken
   to mean that you should invent your own new security protocol for
   each new application.  If IPsec is a bad choice, using another
   standardized, well-understood security protocol will almost always
   give the best results for both implementation and deployment.
   Security protocols are very hard to design; rolling out a new one
   will require extensive theoretical and practical work to confirm its
   security properties and will incur both delay and uncertainty.

Bellovin                 Best Current Practice                  [Page 2]
RFC 5406                      IPsec Usage                  February 2009

3.  The Pieces of IPsec

   IPsec is composed of a number of different pieces.  These can be used
   to provide confidentiality, integrity, and replay protection; though