Network Working Group S. Bellovin
Request for Comments: 5406 Columbia University
BCP: 146 February 2009
Category: Best Current Practice
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
指定使用IPsec版本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.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
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.
许多互联网草案的安全注意事项部分实际上说，“只需使用IPsec”。虽然这有时是正确的，但更多情况下，它会让用户没有真正的、可互操作的安全机制。本备忘录提供了一些关于何时应该和不应该指定IPsec版本2的指导。
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.
许多互联网草案的安全注意事项部分实际上说，“只需使用IPsec”。虽然使用IPsec有时是正确的安全解决方案，但需要更多信息来提供可互操作的安全解决方案。在某些情况下，IPsec在可能的端点中不可用。如果IPsec对特定协议环境中的大多数用户不可用（因此也不可用），那么IPsec的规范就相当于在这个社区中说“关闭安全性”。此外，当IPsec可用时，实现可能无法提供适当的保护粒度。最后，如果IPsec可用且合适，则强制使用IPsec的文档需要指定如何使用它。
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.
本文档的目标是在IPsec是适当的安全机制时，为协议设计人员提供IPsec规范方面的指导。协议规范有望提供现实的、可互操作的安全性。因此，通常需要对各种IPsec数据库（如安全策略数据库（SPD））的配置提供指导。
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].
本文档描述了如何指定IPsec版本2[RFC2401]的使用，包括ESPv2（封装安全有效负载版本2）[RFC2406]、AHv2（身份验证头版本2）[RFC2402]和IKEv1（互联网密钥交换版本1）[RFC2409]。另一份文档将描述IPsec版本3套件[RFC4301][RFC4302][RFC4303][RFC4306]。
For further guidance on security considerations (including discussion of IPsec), see [RFC3552].
有关安全注意事项的进一步指导（包括IPsec的讨论），请参阅[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.
注意：下面的许多参数与IPsec当前实现的功能有关。这些可能会随着时间的推移而改变；本建议基于出版时IETF可获得的知识。
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.
安全协议的设计是一门微妙而困难的艺术。此处关于指定IPsec使用的注意事项不应被视为意味着您应该为每个新应用程序发明自己的新安全协议。如果IPsec是一个错误的选择，那么使用另一个标准化的、易于理解的安全协议几乎总能为实现和部署提供最佳结果。安全协议很难设计；推出一个新的系统将需要大量的理论和实践工作来确认其安全性，并且会带来延迟和不确定性。
IPsec is composed of a number of different pieces. These can be used to provide confidentiality, integrity, and replay protection; though some of these can be configured manually, generally a key management component is used. Additionally, the decision about whether and how to use IPsec is controlled by a policy database of some sort.
IPsec由许多不同的部分组成。这些可用于提供机密性、完整性和重播保护；尽管其中一些可以手动配置，但通常使用密钥管理组件。此外，关于是否以及如何使用IPsec的决定由某种策略数据库控制。
The Authentication Header (AH) [RFC2402] and the Encapsulating Security Payload (ESP) [RFC2406] are the over-the-wire security protocols. Both provide (optional) replay protection. ESP typically is used to provide confidentiality (encryption), integrity, and authentication for traffic. ESP also can provide integrity and authentication without confidentiality, which makes it a good alternative to AH in most cases where confidentiality is not a required or desired service. Finally, ESP can be used to provide confidentiality alone, although this is not recommended [Bell96].
认证报头（AH）[RFC2402]和封装安全有效负载（ESP）[RFC2406]是无线安全协议。两者都提供（可选）重播保护。ESP通常用于为流量提供机密性（加密）、完整性和身份验证。ESP还可以提供完整性和身份验证，而无需保密，这使得它在大多数情况下成为AH的一个很好的替代方案，因为在这种情况下，保密性不是必需的或期望的服务。最后，ESP可单独用于保密，但不建议这样做[96]。
The difference in integrity protection offered by AH is that AH protects portions of the preceding IP header, including the source and destination address. However, if ESP is used in tunnel mode (see Section 3.2) and integrity/authentication is enabled, the IP header seen by the source and destination hosts is completely protected anyway.
AH提供的完整性保护的不同之处在于，AH保护前面IP报头的部分，包括源地址和目标地址。但是，如果在隧道模式下使用ESP（请参见第3.2节），并且启用了完整性/身份验证，则源主机和目标主机看到的IP头无论如何都会受到完全保护。
AH can also protect those IP options that need to be seen by intermediate routers, but must be intact and authentic when delivered to the receiving system. At this time, use (and existence) of such IP options is extremely rare.
AH还可以保护那些中间路由器需要看到的IP选项，但在交付到接收系统时必须完整且真实。目前，此类IP选项的使用（和存在）极为罕见。
If an application requires such protection, and if the information to be protected cannot be inferred from the key management process, AH must be used. (ESP is generally regarded as easier to implement; however, virtually all IPsec packages support both.) If confidentiality is required, ESP must be used. It is possible to use AH in conjunction with ESP, but this combination is rarely required.
如果应用程序需要此类保护，并且如果无法从密钥管理过程推断出要保护的信息，则必须使用AH。（ESP通常被认为更容易实现；但是，实际上所有IPsec包都支持这两种方式。）如果需要保密性，则必须使用ESP。AH可以与ESP结合使用，但很少需要这种组合。
All variants of IPsec have problems with NAT boxes -- see [RFC3715] for details -- but AH is considerably more troublesome. In environments where there is substantial likelihood that the two endpoints will be separated by a NAT box -- this includes almost all services involving user-to-server traffic, as opposed to server-to-server traffic -- NAT traversal [RFC3948] should be mandated and AH should be avoided. (Note that [RFC3948] is for ESP only, and cannot be used for AH.)
IPsec的所有变体都有NAT盒的问题——有关详细信息，请参见[RFC3715]——但AH要麻烦得多。在两个端点极有可能被NAT盒分隔的环境中——这包括几乎所有涉及用户到服务器流量的服务，而不是服务器到服务器流量——应强制执行NAT遍历[RFC3948]，并应避免AH。（注意，[RFC3948]仅用于ESP，不能用于AH。）
AH and ESP can both be used in either transport mode or tunnel mode. In tunnel mode, the IPsec header is followed by an inner IP header. This is the normal usage for Virtual Private Networks (VPN) and is generally required whenever either end of the IPsec-protected path is not the ultimate IP destination, e.g., when IPsec is implemented in a firewall, router, etc.
AH和ESP均可在运输模式或隧道模式下使用。在隧道模式下，IPsec头后面跟着一个内部IP头。这是虚拟专用网络（VPN）的正常用法，通常在IPsec保护路径的任一端不是最终IP目的地时需要，例如，在防火墙、路由器等中实施IPsec时。
Transport mode is preferred for point-to-point communication, though tunnel mode can also be used for this purpose.
传输模式是点对点通信的首选模式，尽管隧道模式也可用于此目的。
Any cryptographic system requires key management. IPsec provides for both manual and automatic key management schemes. Manual key management is easy; however, it doesn't scale very well. Also, IPsec's replay protection mechanisms are not available if manual key management is used. The need for automatic key exchange is discussed in more detail in [RFC4107].
任何加密系统都需要密钥管理。IPsec提供手动和自动密钥管理方案。手动密钥管理容易；然而，它的伸缩性不是很好。此外，如果使用手动密钥管理，则IPsec的重播保护机制不可用。[RFC4107]中更详细地讨论了自动密钥交换的需要。
The primary automated key exchange mechanism for IPsec is the Internet Key Exchange (IKE) [RFC2409]. A new, simpler version of IKE has been approved [RFC4306], but many existing systems still use IKEv1. This document does not discuss IKEv2 and IPsecv3. A second mechanism, Kerberized Internet Negotiation of Keys (KINK) [RFC4430], has been defined. It, of course, uses Kerberos and is suitable if and only if a Kerberos infrastructure is available.
IPsec的主要自动密钥交换机制是Internet密钥交换（IKE）[RFC2409]。一个新的、更简单的IKE版本已经获得批准[RFC4306]，但许多现有系统仍然使用IKEv1。本文件不讨论IKEv2和IPsecv3。定义了第二种机制，Kerberized Internet密钥协商（KINK）[RFC4430]。当然，它使用Kerberos，并且仅当Kerberos基础结构可用时才适用。
If a decision to use IKE is made, the precise mode of operation must be specified as well. IKE can be used in main mode or aggressive mode; both support digital signatures, two different ways of using public key encryption, and shared secrets for authentication.
如果决定使用IKE，还必须指定精确的操作模式。IKE可用于主模式或攻击模式；两者都支持数字签名、使用公钥加密的两种不同方式以及用于身份验证的共享秘密。
Shared secret authentication is simpler; however, it doesn't scale as well in many-to-many communication scenarios since each endpoint must share a unique secret with every peer with which it can communicate. Note, though, that using shared secrets in IKE is far preferable to manual keying.
共享秘密认证更简单；然而，它在多对多通信场景中的伸缩性不好，因为每个端点必须与它可以通信的每个对等方共享一个唯一的秘密。不过请注意，在IKE中使用共享机密远比手动键控更可取。
In most real-world situations where public key modes of IKE are used, locally issued certificates are employed. That is, the administrator of the system or network concerned will issue certificates to all authorized users. These certificates are useful only for IPsec.
在使用IKE公钥模式的大多数实际情况下，使用本地颁发的证书。也就是说，有关系统或网络的管理员将向所有授权用户颁发证书。这些证书仅对IPsec有用。
It is sometimes possible to use certificates [RFC5280] from an existing Public Key Infrastructure (PKI) with IKE. In practice, this is rare. Furthermore, not only is there no global PKI covering most
有时可以将现有公钥基础设施（PKI）中的证书[RFC5280]与IKE一起使用。在实践中，这是罕见的。此外，不仅没有覆盖大多数客户的全球PKI
Internet endpoints, there probably never will be. Designing a structure that assumes such a PKI is a mistake. In particular, assuming that an arbitrary node will have an "authentic" certificate, issued by a mutually trusted third party and vouching for that node's identity, is wrong. Again, such a PKI does not and probably will not exist. Public key IKE is generally a good idea, but should almost always be used with locally issued certificates as opposed to certificates from an existing PKI.
互联网端点，可能永远不会有。设计一个假定有这样一个PKI的结构是错误的。特别是，假设任意节点将拥有由相互信任的第三方颁发的“真实”证书并为该节点的身份提供担保，这是错误的。同样，这样的PKI不存在，也可能不存在。公钥IKE通常是一个好主意，但几乎应该始终与本地颁发的证书一起使用，而不是使用现有PKI的证书。
Note that public key schemes require a substantial amount of computation. Protocol designers should consider whether or not such computations are feasible on devices of interest to their clientele. Using certificates roughly doubles the number of large exponentiations that must be performed, compared with shared secret versions of IKE.
请注意，公钥方案需要大量计算。协议设计者应该考虑这样的计算是否对他们的客户感兴趣的设备是可行的。与IKE的共享秘密版本相比，使用证书可以使必须执行的大指数运算的数量大约增加一倍。
Today, even low-powered devices can generally perform enough computation to set up a limited number of security associations. Concentration points, such as firewalls or VoIP servers, may require hardware assists, especially if many peers are expected to create security associations at about the same time.
今天，即使是低功耗的设备通常也能执行足够的计算，以建立有限数量的安全关联。集中点，如防火墙或VoIP服务器，可能需要硬件协助，尤其是当许多对等方预计将在大约同一时间创建安全关联时。
Using any automated key management mechanism can be difficult when trying to protect low-level protocols. For example, even though [RFC2461] specified the use of IPsec to protect IPv6 Neighbor Discovery, it was impossible to do key management: nodes couldn't use IKE because it required IP-level communication, and that isn't possible before Neighbor Discovery associations are set up.
当试图保护低级协议时，使用任何自动密钥管理机制都可能很困难。例如，即使[RFC2461]指定使用IPsec来保护IPv6邻居发现，也不可能进行密钥管理：节点无法使用IKE，因为它需要IP级别的通信，而在建立邻居发现关联之前，这是不可能的。
It is, in some sense, a misnomer to speak of the API as a part of IPsec since this piece is missing on many systems. To the extent that APIs exist, they aren't standardized. The problem is simple: there is no portable way (and often no way at all) for an application to request IPsec protection, or to tell if it was used for given inbound packets or connections.
从某种意义上讲，将API称为IPsec的一部分是一种用词不当的说法，因为许多系统都缺少这一部分。就API存在的程度而言，它们没有标准化。问题很简单：应用程序没有可移植的方法（通常根本没有方法）来请求IPsec保护，或者判断它是否用于给定的入站数据包或连接。
There are additional problems:
还有其他问题：
o Applications rarely have access to such APIs. Rather, IPsec is usually configured by a system or network administrator.
o 应用程序很少能够访问此类API。相反，IPsec通常由系统或网络管理员配置。
o Applications are unable to verify that IPsec services are being used underneath.
o 应用程序无法验证是否正在下面使用IPsec服务。
o Applications are unaware of the specific identities and properties of the protected channel provided by IPsec. For instance, the IPsec key management mechanisms may be aware of the identity and authorization of the peer, but this information cannot be used by the application nor linked to application-level decisions, such as access to resources reserved to the entity identified by this identity.
o 应用程序不知道IPsec提供的受保护通道的特定标识和属性。例如，IPsec密钥管理机制可能知道对等方的身份和授权，但该信息不能被应用程序使用，也不能链接到应用程序级决策，例如访问由该身份标识的实体保留的资源。
Router- or firewall-based IPsec implementations pose even greater problems since there is no standardized over-the-wire protocol for communicating this information from outboard encryptors to hosts.
基于路由器或防火墙的IPsec实现带来了更大的问题，因为没有标准化的无线协议将这些信息从外部加密机传输到主机。
By contrast, higher-layer security services, such as TLS, are able to provide the necessary control and assurance.
相比之下，更高层的安全服务，如TLS，能够提供必要的控制和保证。
Although IPsec is now widely implemented and is available for current releases of most host operating systems, it is less available for embedded systems. Few hubs, network address translators, etc., implement it, especially at the low end. It is generally inappropriate to rely on IPsec when many of the endpoints are in this category.
尽管IPsec现在已被广泛实施，并且可用于大多数主机操作系统的当前版本，但它在嵌入式系统中的可用性较差。很少有集线器、网络地址转换器等实现它，尤其是在低端。当许多端点属于此类别时，通常不适合依赖IPsec。
Even for host-to-host use, IPsec availability (and experience and ease of use) has generally been for VPNs. Hosts that support IPsec for VPN use frequently do not support it on a point-to-point basis, especially via a stable, well-defined API or user interface.
即使对于主机到主机的使用，IPsec可用性（以及使用体验和易用性）通常也适用于VPN。支持IPsec for VPN使用的主机通常不支持点到点，特别是通过稳定、定义良好的API或用户界面。
Finally, few implementations support multiple layers of IPsec. If a telecommuter is using IPsec in VPN mode to access an organizational network, he or she may not be able to employ a second level of IPsec to protect an application connection to a host within the organization. (We note that such support is, in fact, mandated by Case 4 of Section 4.5 of [RFC2401]. Nevertheless, it is not widely available.) The likelihood of such deployment scenarios should be taken into account when deciding whether or not to mandate IPsec.
最后，很少有实现支持IPsec的多层。如果远程工作者在VPN模式下使用IPsec访问组织网络，他或她可能无法使用第二级IPsec来保护与组织内主机的应用程序连接。（我们注意到，事实上，[RFC2401]第4.5节案例4规定了此类支持。然而，此类支持并未广泛提供。）在决定是否授权IPsec时，应考虑此类部署场景的可能性。
[RFC2401] describes many different forms of endpoint identifier. These include source addresses (both IPv4 and IPv6), host names (possibly as embedded in X.500 certificates), and user IDs (again, possibly as embedded in a certificate). Not all forms of identifier are available on all implementations; in particular, user-granularity identification is not common. This is especially a concern for multi-user systems, where it may not be possible to use different certificates to distinguish between traffic from two different users.
[RFC2401]描述了端点标识符的多种不同形式。其中包括源地址（IPv4和IPv6）、主机名（可能嵌入到X.500证书中）和用户ID（同样，可能嵌入到证书中）。并非所有形式的标识符都可用于所有实现；特别是，用户粒度标识并不常见。这对于多用户系统尤其令人担忧，因为在多用户系统中，可能无法使用不同的证书来区分来自两个不同用户的流量。
Again, we note that the ability to provide fine-grained protection, such as keying each connection separately and with per-user credentials, was one of the original design goals of IPsec. Nevertheless, only a few platforms support it. Indeed, some implementations do not even support using port numbers when deciding whether or not to apply IPsec protection.
我们再次注意到，提供细粒度保护的能力，例如分别为每个连接设置密钥并使用每个用户的凭据，是IPsec最初的设计目标之一。然而，只有少数平台支持它。实际上，有些实现甚至不支持在决定是否应用IPsec保护时使用端口号。
Section 4.4 of [RFC2401] describes the Security Policy Database (SPD) and "selectors" used to decide what traffic should be protected by IPsec. Choices include source and destination addresses (or address ranges), protocol numbers (i.e., 6 for TCP and 17 for UDP), and port numbers for TCP and UDP. Protocols whose protection requirements cannot be described in such terms are poorer candidates for IPsec; in particular, it becomes impossible to apply protection at any finer grain than "destination host". Thus, traffic embedded in a Layer 2 Tunneling Protocol (L2TP) [RFC2661] session cannot be protected selectively by IPsec above the L2TP layer, because IPsec has no selectors defined that let it peer into the L2TP packet to find the TCP port numbers. Similarly, the Stream Control Transmission Protocol (SCTP) [RFC4960] did not exist when [RFC2401] was written; thus, protecting individual SCTP applications on the basis of port number could not be done until a new document was written [RFC3554] that defined new selectors for IPsec, and implementations appeared.
[RFC2401]的第4.4节描述了安全策略数据库（SPD）和“选择器”，用于决定IPsec应保护哪些流量。选择包括源地址和目标地址（或地址范围）、协议号（即TCP为6，UDP为17）以及TCP和UDP的端口号。保护要求无法用此类术语描述的协议是IPsec的较差候选协议；特别是，不可能在比“目标主机”更细的粒度上应用保护。因此，嵌入在第2层隧道协议（L2TP）[RFC2661]会话中的通信量不能由L2TP层之上的IPsec有选择地保护，因为IPsec没有定义选择器，使其能够窥视L2TP数据包以查找TCP端口号。类似地，当写入[RFC2401]时，流控制传输协议（SCTP）[RFC4960]不存在；因此，在编写新文档[RFC3554]并定义新的IPsec选择器和实现之前，无法根据端口号保护单个SCTP应用程序。
Furthermore, in a world that runs to a large extent on dynamically assigned addresses and often uses dynamically assigned port numbers as well, an all-or-nothing policy for VPNs can work well; other policies, however, can be difficult to create in any usable form.
此外，在一个很大程度上依赖于动态分配的地址并经常使用动态分配的端口号的世界中，VPN的全有或全无策略可以很好地工作；但是，其他策略可能很难以任何可用的形式创建。
The granularity of protection available may have side effects. If certain traffic between a pair of machines is protected by IPsec, does the implementation permit other traffic to be unprotected or protected by different policies? Alternatively, if the implementation is such that it is only capable of protecting all traffic or none, does the device have sufficient CPU capacity to encrypt everything? Note that some low-end devices may have limited secure storage capacity for keys, etc.
可用保护的粒度可能有副作用。如果一对机器之间的某些流量受IPsec保护，那么实现是否允许其他流量不受保护或受不同策略保护？或者，如果实现仅能够保护所有通信量或不保护任何通信量，那么设备是否具有足够的CPU容量来加密所有内容？请注意，某些低端设备的密钥等安全存储容量可能有限。
Implementation issues are also a concern here. As before, too many vendors have not implemented the full specification; too many IPsec implementations are not capable of using port numbers in their selectors. Protection of traffic between two hosts is thus on an all-or-nothing basis when these non-compliant implementations are employed.
执行问题也是一个令人关注的问题。和以前一样，太多的供应商没有实施完整的规范；太多IPsec实现无法在其选择器中使用端口号。因此，当采用这些不兼容的实现时，两台主机之间的流量保护是基于全有或全无的基础。
Although the designers of IPsec tried to leave room for protection of multicast traffic, a complete design wasn't finished until much later. As such, many IPsec implementations do not support multicast. [RFC5374] describes extensions to IPsec to support it. Other relevant documents include [RFC3830], [RFC3547], and [RFC4535].
尽管IPsec的设计者试图为多播通信量的保护留出空间，但完整的设计直到很久以后才完成。因此，许多IPsec实现不支持多播。[RFC5374]描述了支持IPsec的扩展。其他相关文件包括[RFC3830]、[RFC3547]和[RFC4535]。
Because of the delay, protocol designers who use multicast should consider the availability of these extensions in target platforms of interest.
由于延迟，使用多播的协议设计者应该考虑这些扩展在感兴趣的目标平台中的可用性。
Despite all of the caveats given above, it may still be appropriate to use IPsec in particular situations. The range of choices makes it mandatory to define precisely how IPsec is to be used. Authors of standards documents that rely on IPsec must specify the following:
尽管上面给出了所有警告，但在特定情况下使用IPsec可能仍然是合适的。选择的范围使得必须精确定义如何使用IPsec。依赖IPsec的标准文档的作者必须指定以下内容：
a. What selectors should the initiator of the conversation (the client, in client-server architectures) use? What addresses, port numbers, etc., are to be used?
a. 对话的发起人（客户机，在客户机-服务器体系结构中）应该使用什么选择器？要使用什么地址、端口号等？
b. What IPsec protocol is to be used: AH or ESP? What mode is to be employed: transport mode or tunnel mode?
b. 要使用什么IPsec协议：AH还是ESP？采用哪种方式：运输方式还是隧道方式？
c. What form of key management is appropriate?
c. 什么形式的密钥管理是合适的？
d. What form of identification should be used? Choices include IP address, DNS name with or without a user name, and X.500 distinguished name.
d. 应该使用什么形式的身份证明？选项包括IP地址、带或不带用户名的DNS名称以及X.500可分辨名称。
e. If the application server will switch user IDs (i.e., it is a login service of some sort) and user name identification is used, is a new security association negotiated that utilizes a user-granularity certificate? If so, when?
e. 如果应用服务器将切换用户ID（即，它是某种登录服务）并使用用户名标识，是否协商使用用户粒度证书的新安全关联？如果是，什么时候？
f. What form of authentication should be used? Choices include pre-shared secrets and certificates.
f. 应该使用什么形式的身份验证？选择包括预先共享的机密和证书。
g. How are the participants authorized to perform the operations that they request? For instance, are all devices with a certificate from a particular source allowed to use any application with IPsec or access any resource? (This problem can appear with any security service, of course.)
g. 如何授权参与者执行其要求的操作？例如，是否允许所有具有特定来源证书的设备使用任何具有IPsec的应用程序或访问任何资源？（当然，任何安全服务都可能出现此问题。）
h. Which of the many variants of IKE must be supported? Main mode? Aggressive mode?
h. IKE的众多变体中必须支持哪一个？主模式？攻击模式？
Note that there are two different versions of IKE: IKE and IKEv2. IKEv2 is simpler and cleaner, but is not yet widely available. You must specify which version of IKE you require.
请注意，IKE有两个不同的版本：IKE和IKEv2。IKEv2更简单、更清洁，但尚未广泛提供。必须指定所需的IKE版本。
i. Is suitable IPsec support available in likely configurations of the products that would have to employ IPsec?
i. 在必须采用IPsec的产品的可能配置中是否有合适的IPsec支持？
Let us now work through an example based on these guidelines. We will use the Border Gateway Protocol (BGP) [RFC4271] to show how to evaluate and specify the use of IPsec for transmission security, rather than the mechanism described in [RFC2385]. Note carefully that we are not saying that IPsec is an appropriate choice here. Rather, we are demonstrating the necessary examination and specification process. Also note that the deeper security issues raised by BGP are not addressed by IPsec or any other transmission security mechanism; see [Kent00a] and [Kent00b] for more details.
现在，让我们通过基于这些指导原则的一个示例进行操作。我们将使用边界网关协议（BGP）[RFC4271]来说明如何评估和指定IPsec用于传输安全，而不是[RFC2385]中描述的机制。请注意，我们并不是说IPsec是一个合适的选择。相反，我们正在演示必要的检查和规范过程。还请注意，BGP提出的更深层次的安全问题没有通过IPsec或任何其他传输安全机制解决；有关更多详细信息，请参见[Kent00a]和[Kent00b]。
Selectors BGP runs between manually configured pairs of hosts on TCP port 179. The appropriate selector would be the pair of BGP speakers, for that port only. Note that the router's "loopback address" is almost certainly the address to use.
选择器BGP在TCP端口179上手动配置的主机对之间运行。合适的选择器将是一对BGP扬声器，仅用于该端口。请注意，路由器的“环回地址”几乎肯定是要使用的地址。
Mode Transport mode would be the proper choice if IPsec were used. The information being communicated is generally not confidential, so encryption need not be used. Either AH or ESP can be used; if ESP is used, the sender's IP address would need to be checked against the IP address asserted in the key management exchange. (This check is mandated by [RFC2401].) For the sake of interoperability, either AH or ESP would need to be specified as mandatory to implement.
如果使用IPsec，模式传输模式将是正确的选择。所传递的信息通常不保密，因此不需要使用加密。可以使用AH或ESP；如果使用ESP，则需要对照密钥管理交换中声明的IP地址检查发送方的IP地址。（该检查由[RFC2401]强制执行。）为了实现互操作性，需要将AH或ESP指定为强制执行。
Key Management To permit replay detection, an automated key management system should be used, most likely IKE. Again, the RFC author should pick one.
密钥管理为了允许重播检测，应该使用自动密钥管理系统，很可能是IKE。同样，RFC作者应该选择一个。
Security Policy Connections should be accepted only from the designated peer. (Note that this restriction applies only to BGP. If the router -- or any IPsec host -- runs multiple services with different security needs, each such service requires its own security policy.)
安全策略连接只能从指定的对等方接受。（请注意，此限制仅适用于BGP。如果路由器（或任何IPsec主机）运行具有不同安全需求的多个服务，则每个此类服务都需要自己的安全策略。）
Authentication Given the number of BGP-speaking routers used internally by large ISPs, it is likely that shared key mechanisms are inadequate. Consequently, certificate-based IKE must be supported. However, shared secret mode is reasonable on peering links or (perhaps) on links between ISPs and customers. Whatever scheme is used, it must tie back to a source IP address or Autonomous System (AS) number in some fashion, since other BGP policies are expressed in these terms. If certificates are used, would they use IP addresses or AS numbers? Which?
认证考虑到大型ISP内部使用的讲BGP的路由器数量，共享密钥机制可能不充分。因此，必须支持基于证书的IKE。然而，共享秘密模式在对等链路上或（可能）在ISP和客户之间的链路上是合理的。无论使用什么方案，它都必须以某种方式与源IP地址或自治系统（AS）号绑定，因为其他BGP策略都用这些术语表示。如果使用证书，它们会使用IP地址还是作为数字？哪一个
Availability For this scenario, availability is the crucial question. Do likely BGP speakers -- both backbone routers and access routers -- support the profile of IPsec described above? Will use of IPsec, with its attendant expensive cryptographic operations, raise the issue of new denial-of-service attacks? The working group and the IESG must make these determinations before deciding to use IPsec to protect BGP.
在这种情况下，可用性是关键问题。BGP扬声器（主干路由器和接入路由器）是否支持上述IPsec配置文件？使用IPsec及其伴随而来的昂贵的加密操作会引发新的拒绝服务攻击问题吗？工作组和IESG必须在决定使用IPsec保护BGP之前做出这些决定。
IPsec provides transmission security and simple access control only. There are many other dimensions to protocol security that are beyond the scope of this memo, including most notably availability. For example, using IPsec does little to defend against denial-of-service attacks; in some situations, i.e., on CPU-limited systems, it may contribute to the attacks. Within its scope, the security of any resulting protocol depends heavily on the accuracy of the analysis that resulted in a decision to use IPsec.
IPsec仅提供传输安全性和简单的访问控制。协议安全性还有许多其他方面超出了本备忘录的范围，其中包括最显著的可用性。例如，使用IPsec在防御拒绝服务攻击方面做得很少；在某些情况下，即在CPU有限的系统上，它可能导致攻击。在其范围内，任何产生的协议的安全性在很大程度上取决于导致决定使用IPsec的分析的准确性。
Ran Atkinson, Lakshminath Dondeti, Barbara Fraser, Paul Hoffman, Russ Housley, Stephen Kent, Eric Fleischman, assorted members of the IESG, and a plethora of others have made many useful suggestions.
Ran Atkinson、Lakshminath Dondeti、Barbara Fraser、Paul Hoffman、Russ Housley、Stephen Kent、Eric Fleischman、IESG的各种成员以及其他许多人都提出了许多有用的建议。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R. Stewart, "On the Use of Stream Control Transmission Protocol (SCTP) with IPsec", RFC 3554, July 2003.
[RFC3554]Bellovin，S.，Ioannidis，J.，Keromytis，A.，和R.Stewart，“关于流控制传输协议（SCTP）与IPsec的使用”，RFC 3554，2003年7月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948]Huttunen，A.，Swander，B.，Volpe，V.，DiBurro，L.，和M.Stenberg，“IPsec ESP数据包的UDP封装”，RFC 3948，2005年1月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107]Bellovin，S.和R.Housley，“加密密钥管理指南”，BCP 107，RFC 4107，2005年6月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, November 2008.
[RFC5374]Weis，B.，Gross，G.和D.Ignjatic，“互联网协议安全架构的多播扩展”，RFC 5374，2008年11月。
[Bell96] Bellovin, S., "Problem Areas for the IP Security Protocols", Proc. Sixth Usenix Security Symposium, pp. 205-214, 1996.
[Bell96]Bellovin，S.，“IP安全协议的问题领域”，Proc。第六届Usenix安全研讨会，第205-214页，1996年。
[Kent00a] Kent, S., Lynn, C., and K. Seo, "Secure Border Gateway Protocol (Secure-BGP)", IEEE Journal on Selected Areas in Communications, 18:4, pp. 582-592, 2000.
[Kent00a]Kent，S.，Lynn，C.，和K.Seo，“安全边界网关协议（安全BGP）”，IEEE通信选定领域杂志，18:4，第582-5922000页。
[Kent00b] Kent, S., Lynn, C., Mikkelson, J., and K. Seo, "Secure Border Gateway Protocol (Secure-BGP) -- Real World Performance and Deployment Issues", Proc. Network and Distributed System Security Symposium (NDSS), 2000.
[Kent00b]Kent，S.，Lynn，C.，Mikkelson，J.，和K.Seo，“安全边界网关协议（安全BGP）——现实世界的性能和部署问题”，Proc。网络和分布式系统安全研讨会（NDSS），2000年。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385]Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461]Narten，T.，Nordmark，E.，和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC2461，1998年12月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2661]汤斯利，W.，瓦伦西亚，A.，鲁本斯，A.，帕尔，G.，佐恩，G.，和B.帕尔特，“第二层隧道协议“L2TP”，RFC 26611999年8月。
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3547]Baugher，M.，Weis，B.，Hardjono，T.，和H.Harney，“解释的集团领域”，RFC 3547，2003年7月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552]Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，2003年7月。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715]Aboba，B.和W.Dixon，“IPsec网络地址转换（NAT）兼容性要求”，RFC 3715，2004年3月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830]Arkko，J.，Carrara，E.，Lindholm，F.，Naslund，M.，和K.Norrman，“米奇：多媒体互联网键控”，RFC 3830，2004年8月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年12月。
[RFC4430] Sakane, S., Kamada, K., Thomas, M., and J. Vilhuber, "Kerberized Internet Negotiation of Keys (KINK)", RFC 4430, March 2006.
[RFC4430]Sakane，S.，Kamada，K.，Thomas，M.，和J.Vilhuber，“密钥的Kerberized Internet协商（扭结）”，RFC 4430，2006年3月。
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006.
[RFC4535]Harney，H.，Meth，U.，Colegrove，A.，和G.Gross，“GSAKMP：组安全关联密钥管理协议”，RFC 45352006年6月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年9月。
Author's Address
作者地址
Steven M. Bellovin Columbia University 1214 Amsterdam Avenue MC 0401 New York, NY 10027 US
Steven M.Bellovin哥伦比亚大学阿姆斯特丹大道1214号MC 0401美国纽约州纽约市10027
Phone: +1 212 939 7149
EMail: bellovin@acm.org
Phone: +1 212 939 7149
EMail: bellovin@acm.org