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 20091. 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]
datatracker.ietf.org