Guidelines for Specifying the Use of IPsec Version 2
RFC 5406
Document | Type |
RFC - Best Current Practice
(February 2009; No errata)
Also known as BCP 146
Was draft-bellovin-useipsec (individual in sec area)
|
|
---|---|---|---|
Author | Steven Bellovin | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5406 (Best Current Practice) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Tim Polk | ||
Send notices to | smb@cs.columbia.edu |
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; thoughShow full document text