Network Working Group J. Touch
Request for Comments: 5387 USC/ISI
Category: Informational D. Black
EMC
Y. Wang
Microsoft
November 2008
Network Working Group J. Touch
Request for Comments: 5387 USC/ISI
Category: Informational D. Black
EMC
Y. Wang
Microsoft
November 2008
Problem and Applicability Statement for Better-Than-Nothing Security (BTNS)
优于无安全性（BTNS）的问题和适用性声明
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2008 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. 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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
The Internet network security protocol suite, IPsec, requires authentication, usually of network-layer entities, to enable access control and provide security services. This authentication can be based on mechanisms such as pre-shared symmetric keys, certificates with associated asymmetric keys, or the use of Kerberos (via Kerberized Internet Negotiation of Keys (KINK)). The need to deploy authentication information and its associated identities can be a significant obstacle to the use of IPsec.
Internet网络安全协议套件IPsec需要身份验证，通常是网络层实体的身份验证，以启用访问控制并提供安全服务。这种身份验证可以基于诸如预共享对称密钥、具有相关非对称密钥的证书或Kerberos（通过Kerberized Internet密钥协商（KINK））的使用等机制。需要部署身份验证信息及其相关标识可能是使用IPsec的一个重大障碍。
This document explains the rationale for extending the Internet network security protocol suite to enable use of IPsec security services without authentication. These extensions are intended to protect communication, providing "better-than-nothing security" (BTNS). The extensions may be used on their own (this use is called Stand-Alone BTNS, or SAB) or may be used to provide network-layer security that can be authenticated by higher layers in the protocol
本文档解释了扩展Internet网络安全协议套件的基本原理，以便在不进行身份验证的情况下使用IPsec安全服务。这些扩展旨在保护通信，提供“比没有更好的安全性”（BTN）。扩展可以单独使用（这种使用称为独立BTN或SAB），或者可以用于提供网络层安全性，该网络层安全性可以由协议中的更高层进行身份验证
stack (this use is called Channel-Bound BTNS, or CBB). The document also explains situations for which use of SAB and/or CBB extensions are applicable.
堆栈（这种用法称为信道绑定BTN或CBB）。本文件还解释了使用SAB和/或CBB扩展适用的情况。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Authentication .............................................3
1.2. IPsec Channels and Channel Binding .........................4
1.3. BTNS Methods ...............................................6
1.4. BTNS Scope .................................................6
1.5. Structure of This Document .................................7
2. Problem Statement ...............................................7
2.1. Network Layer ..............................................8
2.1.1. Authentication Identities ...........................8
2.1.2. Authentication Methods ..............................8
2.1.3. Current IPsec Limits on Unauthenticated Peers .......9
2.2. Higher Layer Issues ........................................9
2.2.1. Transport Protection from Packet Spoofing ...........9
2.2.2. Authentication at Multiple Layers ..................10
3. BTNS Overview and Threat Models ................................12
3.1. BTNS Overview .............................................12
3.2. BTNS and IPsec Security Services ..........................13
3.3. BTNS and IPsec Modes ......................................14
4. Applicability Statement ........................................15
4.1. Benefits ..................................................16
4.2. Vulnerabilities ...........................................16
4.3. Stand-Alone BTNS (SAB) ....................................17
4.3.1. Symmetric SAB ......................................17
4.3.2. Asymmetric SAB .....................................18
4.4. Channel-Bound BTNS (CBB) ..................................18
4.5. Summary of Uses, Vulnerabilities, and Benefits ............19
5. Security Considerations ........................................20
5.1. Threat Models and Evaluation ..............................20
5.2. Interaction with Other Security Services ..................20
5.3. MITM and Masquerader Attacks ..............................21
5.4. Denial of Service (DoS) Attacks and Resource
Consumptions ..............................................22
5.5. Exposure to Anonymous Access ..............................22
5.6. ICMP Attacks ..............................................22
5.7. Leap of Faith .............................................22
5.8. Connection Hijacking through Rekeying .....................24
5.9. Configuration Errors ......................................25
6. Related Efforts ................................................25
7. Acknowledgments ................................................25
8. Informative References .........................................26
1. Introduction ....................................................3
1.1. Authentication .............................................3
1.2. IPsec Channels and Channel Binding .........................4
1.3. BTNS Methods ...............................................6
1.4. BTNS Scope .................................................6
1.5. Structure of This Document .................................7
2. Problem Statement ...............................................7
2.1. Network Layer ..............................................8
2.1.1. Authentication Identities ...........................8
2.1.2. Authentication Methods ..............................8
2.1.3. Current IPsec Limits on Unauthenticated Peers .......9
2.2. Higher Layer Issues ........................................9
2.2.1. Transport Protection from Packet Spoofing ...........9
2.2.2. Authentication at Multiple Layers ..................10
3. BTNS Overview and Threat Models ................................12
3.1. BTNS Overview .............................................12
3.2. BTNS and IPsec Security Services ..........................13
3.3. BTNS and IPsec Modes ......................................14
4. Applicability Statement ........................................15
4.1. Benefits ..................................................16
4.2. Vulnerabilities ...........................................16
4.3. Stand-Alone BTNS (SAB) ....................................17
4.3.1. Symmetric SAB ......................................17
4.3.2. Asymmetric SAB .....................................18
4.4. Channel-Bound BTNS (CBB) ..................................18
4.5. Summary of Uses, Vulnerabilities, and Benefits ............19
5. Security Considerations ........................................20
5.1. Threat Models and Evaluation ..............................20
5.2. Interaction with Other Security Services ..................20
5.3. MITM and Masquerader Attacks ..............................21
5.4. Denial of Service (DoS) Attacks and Resource
Consumptions ..............................................22
5.5. Exposure to Anonymous Access ..............................22
5.6. ICMP Attacks ..............................................22
5.7. Leap of Faith .............................................22
5.8. Connection Hijacking through Rekeying .....................24
5.9. Configuration Errors ......................................25
6. Related Efforts ................................................25
7. Acknowledgments ................................................25
8. Informative References .........................................26
Network security is provided by a variety of protocols at different layers in the stack. At the network layer, the IPsec protocol suite (consisting of IKE (Internet Key Exchange protocol), ESP (Encapsulating Security Payload), and AH (Authentication Header)) is used to secure IP traffic. IPsec, including IKE, offers high levels of security that provide protection from a wide array of possible threats, but authentication is required [5][7][8]. In turn, authentication requires deployment of authentication identities and credentials, which can be an obstacle to IPsec usage. This document discusses this dependency and introduces "Better-Than-Nothing Security" (BTNS) as one solution, whose goal is to provide a generally useful means of applying IPsec security services without requiring network-layer authentication.
网络安全由堆栈中不同层的各种协议提供。在网络层，IPsec协议套件（由IKE（Internet密钥交换协议）、ESP（封装安全负载）和AH（身份验证头）组成）用于保护IP通信。IPsec（包括IKE）提供了高级别的安全性，可防止各种可能的威胁，但需要身份验证[5][7][8]。反过来，身份验证需要部署身份验证标识和凭据，这可能是IPsec使用的障碍。本文档讨论了这种依赖关系，并将“比没有更好的安全性”（BTNS）作为一种解决方案介绍，其目标是提供一种应用IPsec安全服务的通用方法，而无需网络层身份验证。
There are two primary architectural approaches to authentication: employing out-of-band communications and using pre-deployed information. Out-of-band authentication can be done via a trusted third party, via a separate communication channel to the peer, or via the same channel as the communications to be secured but at a higher layer. Out-of-band authentication requires mechanisms and interfaces to bind the authenticated identities to the secure communication channels, and is out of scope for this document (although it may be possible to extend the channel binding mode of BTNS to work with such mechanisms). Pre-deployed information includes identities, pre-shared secrets, and credentials that have been authenticated by trusted authorities (e.g., a certificate and its corresponding private key).
认证有两种主要的体系结构方法：使用带外通信和使用预先部署的信息。带外认证可以通过受信任的第三方、通过到对等方的单独通信信道、或通过与要保护的通信相同的信道（但在更高层）来完成。带外身份验证需要机制和接口将经过身份验证的身份绑定到安全通信信道，这超出了本文档的范围（尽管可以扩展BTN的信道绑定模式以使用此类机制）。预部署的信息包括身份、预共享机密和已由受信任机构验证的凭据（例如，证书及其相应的私钥）。
This form of authentication often requires manual deployment and coordination among communicating peers. Furthermore, obtaining and deploying credentials such as certificates signed by certification authorities (CA) involves additional protocol and administrative actions that may incur significant time and effort to perform.
这种形式的身份验证通常需要在通信对等方之间手动部署和协调。此外，获取和部署证书（如证书颁发机构（CA）签署的证书）涉及额外的协议和管理操作，这些操作可能需要花费大量时间和精力来执行。
These factors increase the work required to use IKE with IPsec for peer authentication. Consequently, some users and applications do not use IPsec to protect traffic at the network layer, but rely instead on higher-layer security protocols (e.g., TLS [4]) or operate without any security. As Section 2.2.1 describes, higher-layer security protocols may not be enough to protect against some network-layer attacks.
这些因素增加了将IKE与IPsec一起用于对等身份验证所需的工作。因此，一些用户和应用程序不使用IPsec来保护网络层的流量，而是依赖于更高层的安全协议（例如TLS[4]），或者在没有任何安全性的情况下运行。正如第2.2.1节所述，高层安全协议可能不足以抵御某些网络层攻击。
To improve the situation, one could either reduce the hurdles to obtain and configure authentication information or remove the requirement for authentication in IPsec. The latter approach is the core idea of BTNS, which provides anonymous (unauthenticated) keying for IPsec to create security associations (SAs) with peers that do not possess requisite authentication credentials. This requires extensions to the IPsec architecture. As the new BTNS modes for IPsec relax the authentication requirement, the impacts, tradeoffs, and risks must be thoroughly understood before applying BTNS to any communications. More specifically, this document addresses the issues of whether and when network-layer authentication can be omitted, the risks of using BTNS, and finally, the impacts to the existing IPsec architecture.
为了改善这种情况，可以减少获取和配置身份验证信息的障碍，或者取消IPsec中的身份验证要求。后一种方法是BTN的核心思想，它为IPsec提供匿名（未经身份验证）密钥，以便与不具备必要身份验证凭据的对等方创建安全关联（SA）。这需要对IPsec体系结构进行扩展。由于IPsec的新BTN模式放宽了认证要求，在将BTN应用于任何通信之前，必须彻底了解其影响、权衡和风险。更具体地说，本文档讨论了是否以及何时可以省略网络层身份验证、使用BTN的风险以及对现有IPsec体系结构的影响等问题。
BTNS employs a weaker notion of authenticated identity by comparison to most authentication protocols; this weaker notion is bootstrapped from the security association itself. This notion, called "continuity of association", doesn't mean "Bill Smith" or "owner of shared secret X2YQ", but means "the entity with which I have been communicating on connection #23". Continuity of association is only invariant within a single SA; it is not invariant across SAs, and hence can only be used to provide protection during the lifetime of an SA. This is a core notion used by BTNS, particularly in the absence of higher-layer authentication. Continuity of association can be viewed as a form of authentication in which an identity is not authenticated across separate associations or out-of-band, but does not change during the lifetime of the SA.
与大多数认证协议相比，基站采用了较弱的认证身份概念；这个较弱的概念是从安全协会本身引导出来的。这个被称为“关联的连续性”的概念，并不是指“比尔·史密斯”或“共享秘密X2YQ的所有者”，而是指“我通过连接与之通信的实体”。关联的连续性仅在单个SA内不变；它在整个SA中不是不变的，因此只能用于在SA的生命周期内提供保护。这是BTN使用的一个核心概念，尤其是在缺乏更高层身份验证的情况下。关联的连续性可以被视为身份验证的一种形式，在这种形式中，身份不会跨单独的关联或带外进行身份验证，但在SA的生命周期内不会改变。
When IPsec security services are used by higher-layer protocols, it is important to bind those services to higher-layer protocol sessions in order to ensure that the security services are consistently applied to the higher-layer traffic involved. The result of this binding is an "IPsec channel", and the act of creating an IPsec channel is an instance of channel binding. Channel binding is discussed in RFC 5056 [27] and in an associated connection latching document [26]. This subsection summarizes the portions of these documents that are essential to understanding certain aspects of BTNS.
当较高层协议使用IPsec安全服务时，必须将这些服务绑定到较高层协议会话，以确保安全服务始终应用于所涉及的较高层流量。此绑定的结果是“IPsec通道”，创建IPsec通道的行为是通道绑定的一个实例。RFC 5056[27]和相关的连接锁存文档[26]中讨论了通道绑定。本小节总结了这些文件中对理解BTN的某些方面至关重要的部分。
A secure channel is a packet, datagram, octet stream connection, or sequence of connections between two endpoints that affords cryptographic integrity and, optionally, confidentiality to data exchanged over it [27]. Applying this concept to IPsec, an "IPsec channel" is a packet flow associated with a higher-layer protocol session, such as a TCP connection, where all the packets are protected by IPsec SAs such that:
安全通道是两个端点之间的数据包、数据报、八位组流连接或连接序列，可提供加密完整性，并可选择性地为通过其交换的数据保密[27]。将此概念应用于IPsec，“IPsec通道”是与更高层协议会话（如TCP连接）相关联的数据包流，其中所有数据包均受IPsec SAs保护，以便：
o the peer's identity is the same for the lifetime of the packet flow, and
o 对等方的身份在数据包流的生命周期内是相同的，并且
o the quality of IPsec protection used for the packet flow's individual packets is the same for all of them for the lifetime of the packet flow [26].
o 在数据包流的生命周期内，用于数据包流各个数据包的IPsec保护质量对于所有数据包都是相同的[26]。
The endpoints of an IPsec channel are the higher-layer protocol endpoints, which are beyond the endpoints of the IPsec SAs involved. This creates a need to bind each IPsec SA to the higher-layer protocol session and its endpoints. Failure to do this binding creates vulnerabilities to man-in-the-middle (MITM) attacks, where what appears to be a single IPsec SA for the higher-layer protocol traffic is actually two separate SAs concatenated by the attacker acting as a traffic-forwarding proxy.
IPsec通道的端点是高层协议端点，它们超出了所涉及IPsec SAs的端点。这就需要将每个IPsec SA绑定到更高层协议会话及其端点。未能执行此绑定会造成中间人（MITM）攻击的漏洞，在这种情况下，更高层协议流量的单个IPsec SA实际上是由攻击者作为流量转发代理连接的两个单独的SA。
The combination of connection latching [26] with channel binding [27] creates IPsec channels and binds IPsec SAs to higher-layer protocols. Connection latching creates an IPsec channel by associating IPsec SAs to higher-layer protocol sessions, and channel binding enables a higher-layer protocol to bind its authentication to the IPsec SAs. Caching of this "latch" across higher-layer protocol sessions is necessary to counter inter-session spoofing attacks, and the channel binding authentication should be performed on each higher-layer protocol session. Connection latching and channel binding are useful not only for BTNS but also for IPsec SAs whose peers are fully authenticated by IKE during creation of the SA.
连接锁存[26]与通道绑定[27]的组合创建IPsec通道，并将IPsec SAs绑定到更高层协议。连接锁存通过将IPsec SAs与高层协议会话关联来创建IPsec通道，通道绑定使高层协议能够将其身份验证绑定到IPsec SAs。跨更高层协议会话缓存此“锁存”是对抗会话间欺骗攻击所必需的，并且应在每个更高层协议会话上执行通道绑定身份验证。连接锁存和通道绑定不仅对BTN有用，而且对IPsec SA也有用，在创建SA期间，IPsec SA的对等方由IKE完全认证。
Channel binding for IPsec is based on information obtained from the SA creation process that uniquely identifies an SA pair. Channel binding can be accomplished by adding this identifying information to higher-layer authentication mechanisms based on one-way hashes, key exchanges, or (public key) cryptographic signatures; in all three cases, the resulting higher-layer authentication resists man-in-the-middle attacks on SA creation. When each IKE peer uses a public-private key pair for IKE authentication to create an SA pair, the pair of public keys used (one for each peer) suffices for channel binding; strong incorporation of this information into higher-layer authentication causes that higher-layer authentication to fail when an MITM attacker has concatenated separate SAs by acting as a traffic-forwarding proxy.
IPsec的通道绑定基于从唯一标识SA对的SA创建过程中获得的信息。通道绑定可以通过将该标识信息添加到基于单向散列、密钥交换或（公钥）加密签名的更高层身份验证机制来实现；在所有这三种情况下，生成的高层身份验证都可以抵抗对SA创建的中间人攻击。当每个IKE对等方使用用于IKE认证的公钥-私钥对来创建SA对时，所使用的公钥对（每个对等方一个）足以进行信道绑定；当MITM攻击者通过充当流量转发代理连接单独的SA时，将此信息强合并到高层身份验证中会导致高层身份验证失败。
There are two classes of scenarios in which BTNS may be used to apply IPsec services without network-layer authentication:
BTN可用于在无网络层身份验证的情况下应用IPsec服务的情况有两类：
1. Protection of traffic for a higher-layer protocol that does not use authentication. The resulting protection is "better than nothing" because once an unauthenticated SA is successfully created without an MITM, that SA's IPsec security services resist subsequent MITM attacks even though the absence of authentication allows the initial creation of the BTNS-based security association (SA) to be subverted by an MITM. This method of using BTNS is called Stand-Alone BTNS (SAB) because it does not rely on any security services outside of IPsec.
1. 保护不使用身份验证的更高层协议的通信量。由此产生的保护“总比没有好”，因为一旦未经身份验证的SA在没有MITM的情况下成功创建，SA的IPsec安全服务将抵抗后续的MITM攻击，即使没有身份验证允许初始创建的基于BTNS的安全关联（SA）被MITM破坏。这种使用BTN的方法称为独立BTN（SAB），因为它不依赖IPsec之外的任何安全服务。
2. Protection of traffic generated by a higher-layer protocol that uses authentication. The "better-than-nothing" protection in this case relies on the strength of the higher-layer protocol's authentication and the channel binding of that authentication with the BTNS-based SAs. The level of protection may be comparable to the level afforded by the use of network-layer IKE authentication when the higher-layer protocol uses strong authentication and strong channel binding is employed to associate the BTNS-based SA with that higher-layer authentication. This method of using BTNS is called Channel-Bound BTNS (CBB) when the combination of the higher-layer authentication and channel binding is sufficient to detect an MITM attack on creation of a BTNS-based SA.
2. 保护由使用身份验证的更高层协议生成的通信量。在这种情况下，“比没有更好”的保护依赖于更高层协议的身份验证的强度以及该身份验证与基于BTN的SAs的通道绑定。当更高层协议使用强认证并且使用强信道绑定将基于btn的SA与该更高层认证相关联时，保护级别可与使用网络层IKE认证所提供的级别相比较。当高层认证和信道绑定的组合足以在创建基于btn的SA时检测MITM攻击时，这种使用btn的方法称为信道绑定btn（CBB）。
It is possible to combine IKE authentication for one end of an SA pair with BTNS's absence of network-layer authentication for the other end. The resulting asymmetric authentication creates asymmetric modes of BTNS that are discussed further in Section 3.2 below.
可以将SA对一端的IKE身份验证与另一端的BTN没有网络层身份验证相结合。由此产生的非对称身份验证创建了BTN的非对称模式，下文第3.2节将对此进行进一步讨论。
The scope of BTNS is to provide a generally useful means of applying IPsec security services that does not require network-level authentication credentials. The following areas are outside this scope of BTNS and hence are not discussed further in this document:
BTN的作用范围是提供一种应用IPsec安全服务的常用方法，该服务不需要网络级身份验证凭据。以下领域不在本BTN范围内，因此本文件不作进一步讨论：
1. Use of security frameworks other than IPsec to provide security services for higher-layer protocols. There are a variety of security service frameworks other than IPsec, such as TLS [4], Simple Authentication and Security Layer (SASL) [11], and Generic Security Service Application Program Interface (GSS-API) [10], as well as a variety of non-IPsec security mechanisms, such as TCP
1. 使用IPsec以外的安全框架为高层协议提供安全服务。除了IPsec之外，还有各种安全服务框架，如TLS[4]、简单身份验证和安全层（SASL）[11]和通用安全服务应用程序接口（GSS-API）[10]，以及各种非IPsec安全机制，如TCP
MD5 [6], that are described in other documents. BTNS is based on IPsec by design; it will not always be the most appropriate solution.
MD5[6]，在其他文档中描述。基站设计基于IPsec；它并不总是最合适的解决方案。
2. Use of the Extensible Authentication Protocol (EAP) for IKE authentication. Section 1.3 of RFC 3748 clearly restricts EAP's applicability to network access protocols [1]:
2. 使用可扩展身份验证协议（EAP）进行IKE身份验证。RFC 3748第1.3节明确限制了EAP对网络接入协议的适用性[1]：
"EAP was designed for use in network access authentication, where IP layer connectivity may not be available. Use of EAP for other purposes, such as bulk data transport, is NOT RECOMMENDED."
EAP设计用于IP层连接可能不可用的网络访问身份验证。不建议将EAP用于其他目的，如批量数据传输
Hence, EAP authentication for IKE is only applicable to situations where IKE is being used to establish network access (e.g., create a Virtual Private Network (VPN) connection). In contrast, the BTNS goal of general applicability encompasses many areas other than network access and specifically includes protocols that transfer large amounts of data, such as iSCSI [19] and NFSv4 [21].
因此，IKE的EAP身份验证仅适用于IKE用于建立网络访问的情况（例如，创建虚拟专用网络（VPN）连接）。相比之下，BTNS的普遍适用性目标包括网络访问以外的许多领域，特别是包括传输大量数据的协议，如iSCSI[19]和NFSv4[21]。
3. Manual keying is not considered for BTNS because manual keying is unsafe for protocols that transfer large amounts of data (e.g., RFC 3723 forbids use of manual keying with the IP Storage protocols, including iSCSI, for this reason [2]).
3. BTN不考虑手动键控，因为手动键控对于传输大量数据的协议是不安全的（例如，出于这个原因，RFC 3723禁止在IP存储协议（包括iSCSI）中使用手动键控[2]）。
The next section discusses the motivations for BTNS, primarily based on the implications of IKE's requirements for network-layer authentication. Section 3 provides a high level overview of BTNS, both SAB and CBB. Section 3 also includes descriptions of the security services offered and the BTNS modes of operation (based on combinations of SAB, CBB, and/or IKE authentication). Section 4 explores the applicability of all of the modes of BTNS. This is followed by a discussion of the risks and other security considerations in Section 5. Section 6 briefly describes other related efforts.
下一节讨论BTN的动机，主要基于IKE对网络层身份验证的要求。第3节提供了基站的高层次概述，包括SAB和CBB。第3节还包括对提供的安全服务和BTN操作模式的描述（基于SAB、CBB和/或IKE认证的组合）。第4节探讨了BTN所有模式的适用性。随后在第5节中讨论了风险和其他安全注意事项。第6节简要介绍了其他相关工作。
This section describes the problems that motivated the development of BTNS. The primary concern is that IPsec is not widely utilized despite rigorous development effort and emphasis on network security by users and organizations. There are also differing viewpoints on which layer is best for securing network communications and how security protocols at different layers should interact. The following discussion roughly categorizes these issues by layers: network layer and higher layers.
本节描述了推动BTN发展的问题。主要的问题是，尽管用户和组织进行了严格的开发工作并强调网络安全，但IPsec并没有得到广泛的利用。对于哪一层最适合保护网络通信以及不同层的安全协议应该如何交互，也存在不同的观点。下面的讨论按层对这些问题进行了大致分类：网络层和更高的层。
At the network layer, one of the hurdles is to satisfy the authentication requirements of IPsec and IKE. This section discusses some drawbacks of network-layer authentication and the results of these requirements.
在网络层，障碍之一是满足IPsec和IKE的身份验证要求。本节讨论网络层身份验证的一些缺点以及这些要求的结果。
Current IPsec authentication supports several types of identities in the Peer Authorization Database (PAD): IPv4 addresses, IPv6 addresses, DNS names, Distinguished Names, RFC 822 email addresses, and Key IDs [8]. All require either certificates or pre-shared secrets to authenticate. The identities supported by the PAD can be roughly categorized as network-layer identifiers or other identifiers.
当前IPsec身份验证支持对等授权数据库（PAD）中的几种类型的身份：IPv4地址、IPv6地址、DNS名称、可分辨名称、RFC 822电子邮件地址和密钥ID[8]。所有这些都需要证书或预共享机密来进行身份验证。PAD支持的标识可以大致分类为网络层标识符或其他标识符。
The first three types of identifiers -- IPv4 addresses, IPv6 addresses and DNS names -- are network-layer identifiers. The main deficiency of IP addresses as identifiers is that they often do not consistently represent the same physical systems due to the increasing use of dynamic address assignments (DHCP) and system mobility. The use of DNS names is also affected because the name to address mapping is not always up to date as a result. Stale mapping information can cause inconsistencies between the IP address recorded in the DNS for a named system and the actual IP address of that system, leading to problems if the DNS is used to cross-check the IP address from which a DNS name was presented as an identifier. DNS names are also not always under the control of the endpoint owner.
前三种标识符（IPv4地址、IPv6地址和DNS名称）是网络层标识符。IP地址作为标识符的主要缺陷是，由于越来越多地使用动态地址分配（DHCP）和系统移动性，它们通常不一致地表示相同的物理系统。DNS名称的使用也会受到影响，因为名称到地址的映射并不总是最新的。过时的映射信息可能会导致DNS中记录的指定系统的IP地址与该系统的实际IP地址不一致，如果DNS用于交叉检查DNS名称作为标识符显示的IP地址，则会导致问题。DNS名称也不总是受端点所有者的控制。
There are two main drawbacks with the other, non-network-layer identifiers defined for the PAD. The PAD functionality can be overly restrictive because there are other forms of identifiers not covered by the PAD specification (EAP does not loosen these restrictions in general; see Section 1.4). Use of any non-network-layer identifiers for IPsec authentication may result in multiple authentications for the same or different identifiers at different layers, creating a need to associate authentications and new error cases (e.g., one of two authentications for the same identifier fails). These issues are also related to channel binding and are further discussed later in this document.
另一个主要缺点是为焊盘定义的非网络层标识符。PAD功能可能过于严格，因为PAD规范未涵盖其他形式的标识符（EAP通常不会放松这些限制；请参见第1.4节）。使用任何非网络层标识符进行IPsec身份验证可能会导致在不同层对相同或不同标识符进行多次身份验证，从而需要关联身份验证和新的错误情况（例如，对相同标识符的两次身份验证中的一次失败）。这些问题也与通道绑定有关，本文档稍后将进一步讨论。
As described earlier, certificates and pre-shared secrets are the only methods of authentication accepted by current IPsec and IKE specifications. Pre-shared secrets require manual configuration and out-of-band communications. The verification process for
如前所述，证书和预共享机密是当前IPsec和IKE规范所接受的唯一身份验证方法。预共享机密需要手动配置和带外通信。核查程序
certificates is cumbersome, plus there are administrative and potential monetary costs in obtaining certificates. These factors are among the possible reasons why IPsec is not widely used outside of environments with the highest security requirements.
证书很麻烦，再加上获取证书的行政和潜在的金钱成本。这些因素是IPsec没有在具有最高安全要求的环境之外广泛使用的可能原因之一。
Pre-configuration of Security Policy Database (SPD) "bypass" entries to enable communication with unauthenticated peers only works if the peer IP addresses are known in advance. The lack of unauthenticated IPsec modes often prevents secure communications at the network layer with unauthenticated or unknown peers, even when they are subsequently authenticated in a higher-layer protocol or application. The lack of a channel binding API between IPsec and higher-layer protocols may further force such communications to completely bypass IPsec, leaving the network layer of such communications unprotected.
预配置安全策略数据库（SPD）“旁路”条目以启用与未经身份验证的对等方的通信，只有在事先知道对等方IP地址的情况下才起作用。缺少未经验证的IPsec模式通常会阻止在网络层与未经验证或未知的对等方进行安全通信，即使这些对等方随后在更高层的协议或应用程序中进行了验证。IPsec和更高层协议之间缺乏通道绑定API可能进一步迫使此类通信完全绕过IPsec，从而使此类通信的网络层不受保护。
For higher layers, the next subsection focuses on whether IPsec is necessary if transport layer security is already in use. The use of IPsec in the presence of transport security provides further motivation for reducing the administrative burdens of using IPsec. This is followed by a discussion of the implications of using authentication at both the network layer and a higher layer for the same connection.
对于更高的层，下一小节将重点讨论在传输层安全性已在使用的情况下是否需要IPsec。在存在传输安全的情况下使用IPsec为减少使用IPsec的管理负担提供了进一步的动力。接下来讨论了在网络层和更高层对同一连接使用身份验证的含义。
Consider the case of transport protocols. Increases in network performance and the use of long-lived connections have resulted in increased vulnerability of connection-oriented transport protocols to certain forms of attacks. TCP, like many other protocols, is susceptible to off-path third-party attacks, such as injection of a TCP RST [24]. The Internet lacks comprehensive ingress filtering to discard such spoofed traffic before it can cause damage. These attacks can affect BGP sessions between core Internet routers, and are thus of significant concern [3][12]. As a result, a number of proposed solutions have been developed, most of which are at the transport layer.
考虑传输协议的情况。网络性能的提高和长寿命连接的使用导致面向连接的传输协议更容易受到某些形式的攻击。与许多其他协议一样，TCP容易受到非路径第三方攻击，例如TCP RST的注入[24]。互联网缺乏全面的入口过滤，无法在造成损害之前丢弃此类伪造流量。这些攻击可能会影响核心互联网路由器之间的BGP会话，因此备受关注[3][12]。因此，提出了许多解决方案，其中大多数是在传输层。
Some of these solutions augment the transport protocol by improving its own security, e.g., TCP MD5 [6]. Others modify the core TCP processing rules to make it harder for off-path attackers to inject meaningful packets either during the initial handshake (e.g., SYN cookies) or after a connection is established (e.g., TCPsecure) [15][23]. Some of these approaches are new to TCP, but have already
其中一些解决方案通过提高传输协议自身的安全性来增强传输协议，例如TCP MD5[6]。其他人修改核心TCP处理规则，使非路径攻击者在初始握手期间（例如，SYN cookies）或建立连接后（例如，TCPsecure）[15][23]更难注入有意义的数据包。其中一些方法对TCP来说是新的，但已经存在
been incorporated into other transport protocols (e.g., Stream Control Transmission Protocol (SCTP) [22]) or intermediate (so-called layer 3.5) protocols (e.g., Host Identity Protocol (HIP) [14]).
已并入其他传输协议（例如，流控制传输协议（SCTP）[22]）或中间（所谓的第3.5层）协议（例如，主机标识协议（HIP）[14]）。
TCP MD5 and its potential successor, TCP Auth [25], are based on authentication; TCP-specific modifications that lack authentication are, at best, temporary patches to the ubiquitous vulnerability to spoofing attacks. The obvious solution to spoofing is end-to-end validation of the traffic, either at the transport layer or the network layer. The IPsec suite already provides authentication of a network-layer packet and its contents, but the costs of an authentication infrastructure required for the use of IPsec can be prohibitive. Similarly, TCP MD5 requires pre-shared keys, which can likewise be prohibitive. TCP Auth is currently under development, and may include a BTNS-like mode.
TCP MD5及其潜在继承者TCP Auth[25]基于身份验证；缺少身份验证的TCP特定修改充其量只是针对普遍存在的欺骗攻击漏洞的临时补丁。欺骗的明显解决方案是在传输层或网络层对流量进行端到端验证。IPsec套件已经提供了对网络层数据包及其内容的身份验证，但是使用IPsec所需的身份验证基础设施的成本可能过高。类似地，TCP MD5需要预共享密钥，这同样是禁止的。TCP身份验证目前正在开发中，可能包括类似BTNS的模式。
Protecting systems from spoofed packets is ultimately an issue of authentication, ensuring that a receiver's interpretation of the source of a packet is accurate. Authentication validates the identity of the source of the packet. The current IPsec suite assumes that identity is validated either by a trusted third party -- e.g., a certification authority -- or by a pre-deployed shared secret. Such an identity is unique and invariant across associations (pair-wise security configuration), and can be used to reject packets that are not authentic.
保护系统不受伪造数据包的影响最终是一个身份验证问题，以确保接收方对数据包源的解释是准确的。身份验证验证验证数据包源的标识。当前的IPsec套件假定身份由受信任的第三方（例如，证书颁发机构）或预部署的共享机密进行验证。这样的身份在关联中是唯一的和不变的（成对安全配置），并且可以用于拒绝不真实的数据包。
With regard to BGP in particular, it has been understood that the use of appropriate network- or transport-layer authentication is the preferred protection from TCP spoofing attacks [3]. Authentication at one router by itself does not provide overall BGP security because that router remains at the mercy of all routers it peers with, since it depends on them to also support authentication [25]. The reality is that few Internet routers are configured to support authentication at all, and the result is the use of unsecured TCP for sending BGP packets. BTNS allows an individual router to relax the need for authentication in order to enable the use of protected sessions that are not authenticated. The latter is "better than nothing" in cases where "nothing" is the alternative. Although the routing community has chosen solutions other than BTNS for protection of BGP's TCP connections (e.g., TCP MD5), the discussion of BGP remains in this document because it was a motivation for the development of BTNS.
特别是关于BGP，可以理解，使用适当的网络或传输层身份验证是防止TCP欺骗攻击的首选保护[3]。一个路由器上的身份验证本身并不能提供全面的BGP安全性，因为该路由器仍然受其对等的所有路由器的支配，因为它也依赖于它们来支持身份验证[25]。事实上，很少有互联网路由器被配置为支持身份验证，其结果是使用不安全的TCP发送BGP数据包。BTN允许单个路由器放松对身份验证的需求，以便能够使用未经身份验证的受保护会话。在“没有”是替代方案的情况下，后者“总比没有好”。尽管路由社区选择了BTN以外的解决方案来保护BGP的TCP连接（如TCP MD5），但本文档中仍对BGP进行了讨论，因为这是BTN发展的动力。
Some existing protocols used on the Internet provide authentication above the network and transport layers but rely on the IPsec suite for packet-by-packet cryptographic integrity and confidentiality services. Examples of such protocols include iSCSI [19] and the
Internet上使用的一些现有协议在网络和传输层之上提供身份验证，但依靠IPsec套件实现逐包加密完整性和机密性服务。此类协议的示例包括iSCSI[19]和
remote direct data placement (RDDP) protocols [16][20]. With the current IPsec suite, the result is two authentication operations: one at the IPsec layer using an identity for IKE and an associated secret or key, and another by the higher-layer protocol using a higher-layer identity and secret or key. With the current IPsec specifications, this redundant authentication is necessary because the identity and key formats differ between IPsec and the higher-layer protocol and/or because there is no standard interface to pass authentication results from IPsec up to the higher layer. End-node software is then responsible for ensuring that the identities used for these two authentication operations are consistent in some fashion; determining whether these identities are consistent is an authorization policy decision.
远程直接数据放置（RDDP）协议[16][20]。对于当前的IPsec套件，结果是两个身份验证操作：一个在IPsec层使用IKE的标识和关联的密钥或密钥，另一个由更高层协议使用更高层的标识和密钥或密钥。对于当前的IPsec规范，这种冗余身份验证是必要的，因为IPsec和更高层协议之间的身份和密钥格式不同，和/或因为没有标准接口将身份验证结果从IPsec传递到更高层。然后，终端节点软件负责确保用于这两个身份验证操作的标识以某种方式保持一致；确定这些标识是否一致是授权策略决策。
Failure of the end-node software to enforce appropriate consistency across authentication operations at different layers creates man-in-the-middle attack opportunities at the network layer. An attacker may exploit this omission by interposing as a proxy; rather than impersonate the attacked endpoints, the attacker need only authenticate with identities that are acceptable to the attacked endpoints. The resulting success enables the attacker to obtain full access to the higher-layer traffic by passing the higher-layer authentication operation through without modification. In the complete absence of consistency checks on the identities used at different layers, higher-layer traffic may be accessible to any entity that can successfully authenticate at the network layer.
Failure of the end-node software to enforce appropriate consistency across authentication operations at different layers creates man-in-the-middle attack opportunities at the network layer. An attacker may exploit this omission by interposing as a proxy; rather than impersonate the attacked endpoints, the attacker need only authenticate with identities that are acceptable to the attacked endpoints. The resulting success enables the attacker to obtain full access to the higher-layer traffic by passing the higher-layer authentication operation through without modification. In the complete absence of consistency checks on the identities used at different layers, higher-layer traffic may be accessible to any entity that can successfully authenticate at the network layer.translate error, please retry
In principle, a single authentication operation should suffice to protect the higher-layer traffic, removing the need for:
原则上，单个身份验证操作应足以保护更高层的通信量，无需：
o the second authentication operation,
o 第二个身份验证操作，
o configuration and management of the identities and secrets or keys for the second authentication (even if the identities and secrets or keys are the same, the two authentication operations may employ different repositories for identities, secrets, and keys), and
o 配置和管理用于第二次身份验证的身份和秘密或密钥（即使身份和秘密或密钥相同，两次身份验证操作也可能使用不同的身份、秘密和密钥存储库），以及
o determining in some fashion that the two authenticated identities are consistent. As noted above, there are significant potential MITM vulnerabilities if this is not done.
o 以某种方式确定两个经过身份验证的标识是一致的。如上所述，如果不这样做，则存在重大的潜在MITM漏洞。
IPsec may not always be present for these higher-layer protocols, and even when present, may not always be used. Hence, if there is a choice, the higher-layer protocol authentication is preferable as it will always be available for use, independent of IPsec.
对于这些高层协议，IPsec可能并不总是存在，即使存在，也可能不总是使用。因此，如果有选择，则更高层协议认证更可取，因为它将始终可供使用，独立于IPsec。
A "better-than-nothing" security approach to IPsec can address this problem by setting up an IPsec security association without an authentication, and then using an extended form of the higher-layer authentication to establish that the higher-layer protocol session is protected by a single IPsec SA. This counters man-in-the-middle (MITM) attacks on BTNS IPsec session establishment by terminating the higher-layer session via an authentication failure when such an attack occurs. The result is that a single authentication operation validates not only the higher-layer peer's identity but also continuity of the security association to that peer. This higher-layer check for a single IPsec SA is referred in this document as "channel binding", thus the name Channel-Bound BTNS (CBB) [27].
IPsec的“总比没有好”安全方法可以解决此问题，方法是在不进行身份验证的情况下建立IPsec安全关联，然后使用扩展形式的高层身份验证来确定高层协议会话由单个IPsec SA保护。当发生中间人（MITM）攻击时，通过身份验证失败终止高层会话，从而对抗对BTNS IPsec会话建立的攻击。其结果是，单个身份验证操作不仅验证高层对等方的身份，而且验证与该对等方的安全关联的连续性。对于单个IPsec SA的这种更高层检查在本文档中称为“信道绑定”，因此称为信道绑定BTN（CBB）[27]。
This section provides an overview of BTNS and the IPsec security services that are offered when BTNS is used. It also describes the multiple operating modes of BTNS.
本节概述了使用BTN时提供的BTN和IPsec安全服务。它还描述了BTN的多种工作模式。
This is an overview of what is needed in IPsec to enable BTNS. The detailed specifications of the extensions are addressed by the relevant protocol specifications.
这是IPsec中启用BTN所需内容的概述。扩展的详细规范由相关协议规范解决。
The main update to IPsec is adding extensions to security policy that permit secure communications with unauthenticated peers. These extensions are necessary for both IPsec and IKE. For IPsec, the first extension applies to the PAD, which specifies the forms of authentication allowed for each IKE peer. In addition to existing forms of authentication, such as X.509 certificates and pre-shared secrets, the extension adds an unauthenticated category in which the public key presented by the peer serves as its identity (and is authenticated by the peer demonstrating knowledge of the corresponding private key) [28]. The second extension is that a flag is added to each SPD entry to indicate whether BTNS lack of authentication is acceptable for that SPD entry.
IPsec的主要更新是向安全策略添加扩展，允许与未经身份验证的对等方进行安全通信。这些扩展对于IPsec和IKE都是必需的。对于IPsec，第一个扩展应用于PAD，它指定每个IKE对等方允许的身份验证形式。除了现有的身份验证形式（如X.509证书和预共享机密）外，该扩展还添加了一个未经身份验证的类别，其中对等方提供的公钥作为其身份（并由对等方进行身份验证，证明其了解相应的私钥）[28]。第二个扩展是在每个SPD条目中添加一个标志，以指示该SPD条目是否可以接受缺少身份验证的BTN。
The changes to enable channel binding between IPsec and higher-layer protocols or applications are more complex than the policy extensions above. They require specifying APIs and interactions between IPsec and higher-layer protocols. This document assumes such provisions will be developed, but does not address their details.
在IPsec和更高层协议或应用程序之间启用通道绑定的更改比上面的策略扩展更复杂。它们需要指定IPsec和更高层协议之间的API和交互。本文件假定将制定此类规定，但未说明其细节。
The changes and extensions of BTNS primarily affect IPsec policy as described above. Other parts of IPsec and IKE specifications are unchanged. BTNS does not require a separate IPsec implementation, as BTNS can be integrated with any IPsec implementation in a system. The scope of BTNS functionality applies only to the SAs matching the policies that explicitly specify or enable BTNS modes in the PAD and for which the corresponding SPD entries allow BTNS. All other non-BTNS policy entries, including entries in the SPD and the PAD, and non-BTNS SAs are not affected by BTNS.
如上所述，BTN的更改和扩展主要影响IPsec策略。IPsec和IKE规范的其他部分不变。BTN不需要单独的IPsec实现，因为BTN可以与系统中的任何IPsec实现集成。BTN功能的范围仅适用于与在PAD中明确指定或启用BTN模式且相应SPD条目允许BTN的策略相匹配的SA。所有其他非BTN策略条目，包括SPD和PAD中的条目，以及非BTN SA不受BTN影响。
In principle, the result of removing the requirement that all SAs be authenticated is that BTNS can establish secure IPsec connections in a fashion similar to fully authenticated IKE, but BTNS cannot verify or authenticate the peer identities of these SAs. The following is a list of security services offered by the IPsec protocol suite with notes that address the differences created by the addition of BTNS.
原则上，取消对所有SA进行身份验证的要求的结果是，BTN可以以类似于完全身份验证IKE的方式建立安全的IPsec连接，但BTN无法验证或验证这些SA的对等身份。以下是IPsec协议套件提供的安全服务列表，以及解决添加BTN造成的差异的注释。
1. Access Control
1. 访问控制
BTNS extends IPsec's access control services to allow unauthenticated connections. These extensions are integrated with the IPsec PAD and SPD in a fashion that does not affect the access controls associated with entries that do not use the BTNS extensions. For Channel-Bound BTNS, the authentication that applies to the SA is performed at a higher layer in a fashion that links higher-layer access control policy to IPsec's network-layer access control mechanisms.
BTN扩展了IPsec的访问控制服务，允许未经验证的连接。这些扩展与IPsec PAD和SPD的集成方式不会影响与不使用BTN扩展的条目相关联的访问控制。对于信道绑定的BTN，应用于SA的认证在更高层执行，其方式是将更高层访问控制策略链接到IPsec的网络层访问控制机制。
2. Data Origin Authentication
2. 数据源身份验证
Stand-Alone BTNS weakens data origin authentication to continuity of association, namely the assurance that traffic on an SA continues to originate from the same unauthenticated source.
独立BTN削弱了数据源身份验证与关联的连续性，即SA上的流量继续来自同一未经身份验证的源的保证。
Channel-Bound BTNS relies on higher-layer authentication to provide data origin authentication of protected network traffic.
信道绑定的BTN依赖于更高层的身份验证来提供受保护网络流量的数据源身份验证。
3. Connectionless Integrity
3. 无连接完整性
4. Anti-Replay Protection
4. 防重放保护
5. Confidentiality
5. 保密性
6. (Limited) Traffic Flow Confidentiality
6. （有限）交通流保密
For the security services offered by IPsec that are listed in items 3 through 6, it is possible to establish secure IPsec connections with rogue peers via BTNS because authentication is not required. On the other hand, once a secure connection is established, the communication is protected by these security services in the same fashion as a connection established by conventional IPsec means.
对于项目3至6中列出的IPsec提供的安全服务，可以通过BTN与恶意对等方建立安全的IPsec连接，因为不需要身份验证。另一方面，一旦建立了安全连接，这些安全服务以与通过传统IPsec手段建立的连接相同的方式保护通信。
The previous sections have described two ways of using BTNS: Stand-Alone (SAB) and Channel-Bound (CBB). Both of these can also be used either symmetrically, where neither party authenticates at the network layer, or asymmetrically, where only one party does not authenticate at the network layer. There are a number of cases to consider, based on combinations of the endpoint security capabilities of SAB, CBB, and conventional IKE authentication of an identity (denoted as AUTH below). The following tables show all of the combinations based on the capabilities of the two security endpoints:
前面的章节描述了使用BTN的两种方式：独立（SAB）和信道绑定（CBB）。这两种方法也可以对称使用，其中任何一方都不在网络层进行身份验证，或者不对称使用，其中只有一方不在网络层进行身份验证。基于SAB、CBB的端点安全能力和身份的传统IKE认证（以下称为AUTH），有许多情况需要考虑。下表显示了基于两个安全端点功能的所有组合：
| AUTH | SAB | | CB-AUTH | CBB |
-----+-------+-------+ -------+---------+---------+
| | | | | |
AUTH | AUTH | A-SAB | CB-AUTH| CB-AUTH | A-CBB |
| | | | | |
-----+-------+-------+ -------+---------+---------+
| | | | | |
SAB | A-SAB | S-SAB | CBB | A-CBB | S-CBB |
| | | | | |
-----+-------+-------+ -------+---------+---------+
| AUTH | SAB | | CB-AUTH | CBB |
-----+-------+-------+ -------+---------+---------+
| | | | | |
AUTH | AUTH | A-SAB | CB-AUTH| CB-AUTH | A-CBB |
| | | | | |
-----+-------+-------+ -------+---------+---------+
| | | | | |
SAB | A-SAB | S-SAB | CBB | A-CBB | S-CBB |
| | | | | |
-----+-------+-------+ -------+---------+---------+
No Channel Binding With Channel Binding
没有通道绑定与通道绑定
There are six operating modes that result from the combinations. The first three modes consist of network-layer authentication schemes used without channel binding to higher-layer authentication:
组合产生六种操作模式。前三种模式包括使用的网络层身份验证方案，无需将通道绑定到更高层身份验证：
1. AUTH: both parties provide and authenticate conventional, IKE-supported identities.
1. AUTH：双方提供并验证传统的、IKE支持的身份。
2. Symmetric SAB (S-SAB): neither party authenticates with a conventional, IKE-supported identity.
2. 对称SAB（S-SAB）：双方均不使用传统的、IKE支持的身份进行身份验证。
3. Asymmetric SAB (A-SAB): one party does not authenticate with a conventional, IKE-supported identity, but the other side does authenticate with such an identity.
3. 非对称SAB（A-SAB）：一方不使用传统的、IKE支持的身份进行身份验证，但另一方使用此类身份进行身份验证。
The following three modes combine the network-layer behaviors with channel binding to higher-layer authentication credentials:
以下三种模式将网络层行为与通道绑定结合到更高层的身份验证凭据：
4. CB-AUTH: channel binding is used and both parties authenticate with conventional, IKE-supported identities.
4. CB-AUTH：使用通道绑定，双方使用传统的、IKE支持的身份进行身份验证。
5. Symmetric CBB (S-CBB): neither party authenticates with a conventional, IKE-supported identity, but channel binding is used to bind the SAs to higher-layer authentication operations.
5. 对称CBB（S-CBB）：双方都不使用传统的、IKE支持的身份进行身份验证，但通道绑定用于将SAs绑定到更高层的身份验证操作。
6. Asymmetric CBB (A-CBB): asymmetric SAB (A-SAB) used with channel binding; at the network layer, one party does not authenticate with a conventional, IKE-supported identity, but the other party does authenticate with such an identity. Channel binding is used to bind the SA to higher-layer authentication operations.
6. 不对称CBB（A-CBB）：与通道结合使用的不对称SAB（A-SAB）；在网络层，一方不使用传统的、IKE支持的身份进行身份验证，但另一方使用这种身份进行身份验证。通道绑定用于将SA绑定到更高层的身份验证操作。
There are three security mechanisms involved in BTNS with channel binding:
具有通道绑定的BTN涉及三种安全机制：
1. BTNS and IPsec at the network layer,
1. 网络层的BTN和IPsec，
2. higher-layer authentication, and
2. 更高层的身份验证，以及
3. the connection latching plus channel binding mechanisms that bind the higher-layer authentication credentials with the secure IPsec channel.
3. 连接锁存加通道绑定机制，用于将高层身份验证凭据与安全IPsec通道绑定。
Authentication at both the network and higher layers can be either bidirectional (both peers are authenticated) or unidirectional (one of the two peers does not authenticate). In contrast, when channel binding is used, it must be applied at both ends of the communication to prevent MITM attacks. Existing channel binding mechanisms and APIs for this purpose (e.g., as defined in GSS-API [10]) mandate the exchange and verification of the channel binding values at both ends to ensure that correct, non-spoofed channel characteristics are bound to the higher-layer authentication.
网络和更高层的身份验证可以是双向的（两个对等方都经过身份验证）或单向的（两个对等方中的一个不进行身份验证）。相反，当使用通道绑定时，它必须应用于通信的两端以防止MITM攻击。用于此目的的现有信道绑定机制和API（如GSS-API[10]中定义的）要求在两端交换和验证信道绑定值，以确保将正确、非欺骗的信道特性绑定到更高层的身份验证。
Note: When any Stand-Alone BTNS (SAB) or Channel-Bound BTNS (CBB) is used without being qualified as symmetric or asymmetric, the symmetric mode is the intended default meaning.
注：当使用任何独立BTN（SAB）或信道绑定BTN（CBB）而未被限定为对称或非对称时，对称模式是预期的默认含义。
BTNS is intended for services open to the public but for which protected associations are desired, and for services that can be authenticated at higher layers in the protocol stack. BTNS can also provide some level of protection for private services when the alternative BTNS is no protection at all.
BTN适用于对公众开放但需要受保护关联的服务，以及可在协议栈的更高层进行身份验证的服务。当备用BTN完全没有保护时，BTN还可以为私人服务提供某种程度的保护。
BTNS uses the IPsec protocol suite, and therefore should not be used in situations where IPsec and specifically IKE are unsuitable. IPsec and IKE incur additional computation overhead, and IKE further requires message exchanges that incur round-trip latency to setup security associations. These may be undesirable in environments with limited computational resources and/or high communication latencies.
BTN使用IPsec协议套件，因此不应在IPsec和IKE不合适的情况下使用。IPsec和IKE会产生额外的计算开销，IKE还需要产生往返延迟的消息交换来建立安全关联。在计算资源有限和/或通信延迟高的环境中，这些可能是不可取的。
This section provides an overview of the types of applications suitable for various modes of BTNS. The next two sections describe the overall benefits and vulnerabilities, followed by the applicability analysis for each BTNS mode. The applicability statement covers only the four BTNS-specific modes; the AUTH and CB-AUTH modes are out of scope for this discussion.
本节概述了适用于各种BTN模式的应用类型。接下来的两个部分描述了总体优势和漏洞，然后是每个BTN模式的适用性分析。适用性声明仅涵盖四种BTN特定模式；AUTH和CB-AUTH模式超出了本讨论的范围。
BTNS protects security associations after they are established by reducing vulnerability to attacks from parties that are not participants in the association. BTNS-based SAs protect network and transport layers without requiring network-layer authentication. BTNS can be deployed without pre-deployment of authentication material for IPsec or pre-shared information and can protect all transport layer protocols using a common mechanism.
BTN通过降低不参与安全关联的各方攻击的脆弱性，在安全关联建立后保护安全关联。基于BTN的SAs保护网络和传输层，无需网络层身份验证。BTN可以在不预先部署IPsec认证材料或预先共享信息的情况下进行部署，并且可以使用公共机制保护所有传输层协议。
BTNS also helps protect systems from low-effort attacks on higher-layer sessions or connections that disrupt valuable services or resources. BTNS raises the level of effort for many types of network- and transport-layer attacks. Simple transport layer packet attacks are rejected because the malicious packet or packets are not part of an IPsec SA. The attacker is instead forced to establish an unauthenticated IPsec SA and a transport connection for SAB, requiring the attacker to perform as much work as a host engaging in the higher-layer communication. SAB thus raises the effort for a DDoS (Distributed Denial of Service) attack to that of emulating a flash crowd. For open services, there may be no way to distinguish such a DDoS attack from an actual flash crowd.
BTN还有助于保护系统免受破坏宝贵服务或资源的高层会话或连接的低强度攻击。BTN提高了许多类型的网络和传输层攻击的工作级别。简单传输层数据包攻击被拒绝，因为恶意数据包不是IPsec SA的一部分。相反，攻击者被迫为SAB建立未经身份验证的IPsec SA和传输连接，这要求攻击者执行与参与更高层通信的主机相同的工作。因此，SAB将DDoS（分布式拒绝服务）攻击提高到模拟flash群组的程度。对于开放服务，可能无法将此类DDoS攻击与实际的闪存群区分开来。
BTNS also allows individual security associations to be established for protection of higher-layer traffic without requiring pre-deployed authentication credentials.
BTN还允许建立单独的安全关联，以保护更高层的流量，而无需预先部署身份验证凭据。
BTNS removes the requirement that every IPsec SA be authenticated. Hosts connecting to BTNS hosts are vulnerable to communicating with a masquerader throughout the association for SAB, or until higher layers provide additional authentication for CBB. As a result, authentication data (e.g., passwords) sent to a masquerading peer
BTNS取消了对每个IPsec SA进行身份验证的要求。连接到BTN主机的主机容易在整个SAB关联过程中与伪装器通信，或者直到更高的层为CBB提供额外的身份验证。因此，身份验证数据（例如密码）被发送到伪装对等方
could be disclosed to an attacker. This is a deliberate design tradeoff; in BTNS, network- and transport-layer access is no longer controlled by the identity presented by the other host, opening hosts to potential masquerading and flash crowd attacks. Conversely, BTNS can secure connections to hosts that are unable to authenticate at the network layer, so the network and transport layers are more protected than can be achieved via higher-layer authentication alone.
可能会泄露给攻击者。这是一个深思熟虑的设计权衡；在BTN中，网络和传输层访问不再由另一台主机提供的身份控制，从而使主机面临潜在的伪装和闪存群攻击。相反，BTN可以保护到无法在网络层进行身份验证的主机的连接，因此网络和传输层比仅通过更高层的身份验证更受保护。
Lacking network-layer authentication information, other means must be used to provide access control for local resources. Traffic selectors for the BTNS SPD entries can be used to limit which interfaces, address ranges, and port ranges can access BTNS-enabled services. Rate limiting can further restrict resource usage. For SAB, these protections need to be considered throughout associations, whereas for CBB they need be present only until higher-layer protocols provide the missing authentication. CBB also relies on the effectiveness of the binding of higher-layer authentication to the BTNS network association.
由于缺乏网络层身份验证信息，必须使用其他方法来提供对本地资源的访问控制。BTNS SPD条目的流量选择器可用于限制哪些接口、地址范围和端口范围可以访问支持BTNS的服务。速率限制可以进一步限制资源使用。对于SAB，需要在整个关联中考虑这些保护，而对于CBB，只有在高层协议提供缺少的身份验证之前，这些保护才需要存在。CBB还依赖于更高层认证与BTNS网络关联绑定的有效性。
SAB is intended for applications that are unable to use IKE-compatible authentication credentials and do not employ higher-layer authentication or other security protection. SAB is also suitable when the identities of either party are not important or are deliberately omitted, but IPsec security services are desired (see Section 3.2). SAB is particularly applicable to long-lived connections or sessions for which assurance that the entity at the other end of the connection has not changed may be a good enough substitute for the lack of authentication. This section discusses symmetric and asymmetric SAB.
SAB适用于无法使用与IKE兼容的身份验证凭据且不采用更高层身份验证或其他安全保护的应用程序。当任何一方的身份不重要或故意省略，但需要IPsec安全服务时，SAB也适用（见第3.2节）。SAB特别适用于长期存在的连接或会话，对于这些连接或会话，确保连接另一端的实体未发生更改可能足以替代缺少身份验证。本节讨论对称和非对称SAB。
Symmetric SAB (S-SAB) is applicable when both parties lack network-layer authentication information and that authentication is not available from higher-layer protocols. S-SAB can still provide some forms of protection for network and transport protocols, but does not provide authentication beyond continuity of association. S-SAB is useful in situations where transfer of large files or use of other long-lived connections would benefit from not being interrupted by attacks on the transport connection (e.g., via a false TCP RST), but the particular endpoint identities are not important.
对称SAB（S-SAB）适用于双方缺乏网络层身份验证信息且无法从更高层协议获得身份验证的情况。S-SAB仍然可以为网络和传输协议提供某种形式的保护，但不提供超出关联连续性的身份验证。S-SAB在大文件传输或其他长期连接的使用不会因传输连接上的攻击（例如，通过错误的TCP RST）而中断而受益的情况下非常有用，但特定的端点标识并不重要。
Open services, such as web servers, and peer-to-peer networks could utilize S-SAB when their identities need not be authenticated but their communication would benefit from protection. Such services might provide files that are either not validated or validated by
当开放服务（如web服务器）和对等网络的身份不需要验证但其通信将受益于保护时，它们可以利用S-SAB。此类服务可能提供未经验证或未经验证的文件
other means (e.g., published hashes). These transmissions present a target for off-path attacks that could be mitigated by S-SAB. S-SAB may also be useful for protecting voice-over-IP (VoIP) traffic between peers, such as direct calls between VoIP clients.
其他方式（例如，已发布的哈希）。这些传输为S-SAB可以缓解的非路径攻击提供了目标。S-SAB还可用于保护对等方之间的IP语音（VoIP）通信，例如VoIP客户端之间的直接呼叫。
S-SAB is also useful in protecting any transport protocol when the endpoints do not deploy authentication, for whatever reason. This is the case for BGP TCP connections between core routers, where the protection afforded by S-SAB is better than no protection at all, even though BGP is not intended as an open service.
无论出于何种原因，当端点不部署身份验证时，S-SAB在保护任何传输协议方面也很有用。核心路由器之间的BGP TCP连接就是这种情况，在这种情况下，S-SAB提供的保护比根本没有保护要好，即使BGP不打算作为开放服务。
S-SAB can also serve as an intermediate step towards S-CBB. S-SAB is the effective result when an IPsec channel is used (via connection latching), but the higher-layer authentication is not bound to the IPsec SAs within the channel.
S-SAB也可以作为走向S-CBB的中间步骤。当使用IPsec通道（通过连接锁存）时，S-SAB是有效的结果，但更高层身份验证未绑定到通道内的IPsec SAs。
Asymmetric SAB (A-SAB) allows one party lacking network-layer authentication information to establish associations with another party that possesses authentication credentials for any applicable IKE authentication mechanism.
非对称SAB（A-SAB）允许缺少网络层身份验证信息的一方与拥有任何适用IKE身份验证机制的身份验证凭据的另一方建立关联。
Asymmetric SAB is useful for protecting transport connections for open services on the Internet, e.g., commercial web servers, etc. In these cases, the server is typically authenticated by a widely known CA, as is done with TLS at the application layer, but the clients need not be authenticated [4]. Although this may result in IPsec and TLS being used on the same connection, this duplication of security services at different layers is necessary when protection is required from the sorts of spoofing attacks described in Section 2 (e.g., TLS cannot prevent a spoofed TCP RST, as the RST is processed by TCP rather than being passed to TLS).
非对称SAB有助于保护互联网上开放服务的传输连接，例如商业web服务器等。在这些情况下，服务器通常由广为人知的CA进行身份验证，就像应用层的TLS一样，但不需要对客户端进行身份验证[4]。尽管这可能会导致IPsec和TLS在同一连接上使用，但当需要防止第2节所述的各种欺骗攻击时（例如，TLS无法防止欺骗的TCP RST，因为RST由TCP处理，而不是传递给TLS），不同层的安全服务复制是必要的。
A-SAB can also secure transport for streaming media such as would be used by webcasts for remote education and entertainment.
A-SAB还可以确保流媒体的传输安全，例如网络广播用于远程教育和娱乐。
CBB allows hosts without network-layer authentication information to cryptographically bind BTNS-based IPsec SAs to authentication at higher layers. CBB is intended for applications that employ higher-layer authentication but that also benefit from additional network-layer security. CBB provides network-layer security services without requiring authentication at the network layer. This enables IPsec security services for applications that have IKE-incompatible authentication credentials. CBB allows IPsec to be used with
CBB允许没有网络层身份验证信息的主机以加密方式将基于BTN的IPsec SA绑定到更高层的身份验证。CBB适用于采用更高层身份验证但也受益于额外网络层安全的应用程序。CBB提供网络层安全服务，无需在网络层进行身份验证。这将为具有IKE不兼容身份验证凭据的应用程序启用IPsec安全服务。CBB允许IPsec与
authentication mechanisms not supported by IKE and frees higher-layer applications and protocols from duplicating security services already available in IPsec.
IKE不支持的身份验证机制，使高层应用程序和协议不必复制IPsec中已有的安全服务。
Symmetric CBB integrates channel binding with S-SAB, as does asymmetric CBB with A-SAB. In both cases, the target applications have similar characteristics at the network layer to their non-channel-binding counterparts. The only significant difference is the binding of authentication credentials at a higher layer to the resulting IPsec channels.
对称CBB集成了通道绑定和S-SAB，非对称CBB集成了A-SAB。在这两种情况下，目标应用程序在网络层与非通道绑定的应用程序具有相似的特性。唯一显著的区别是将更高层的身份验证凭据绑定到生成的IPsec通道。
Although the modes of CBB refer to the authentication at the network layer, higher-layer authentication can also be either asymmetric (one-way) or symmetric (two-way). Asymmetric CBB can be used to complement one-way authentication at a higher layer by providing one-way authentication of the opposite direction at the network layer. Consider an application with one-way, client-only authentication. The client can utilize A-CBB where the server must present IKE-authenticated credentials at the network layer. This form of A-CBB achieves mutual authentication, albeit at separate layers. Many remote file system protocols, such as iSCSI and NFS, fit into this category and can benefit from channel binding with IPsec for better network-layer protection, including prevention of MITM attacks.
尽管CBB的模式指的是网络层的身份验证，但更高层的身份验证也可以是非对称（单向）或对称（双向）。非对称CBB可用于通过在网络层提供相反方向的单向认证来补充更高层的单向认证。考虑单向的、仅由客户端验证的应用程序。客户端可以利用A-CBB，其中服务器必须在网络层提供IKE身份验证凭据。这种形式的A-CBB实现了相互认证，尽管是在不同的层上。许多远程文件系统协议（如iSCSI和NFS）都属于这一类，并且可以从与IPsec的通道绑定中获益，以实现更好的网络层保护，包括防止MITM攻击。
Mechanisms and interfaces for BTNS channel binding with IPsec are discussed in further detail in [26].
[26]中进一步详细讨论了BTNS与IPsec信道绑定的机制和接口。
The following is a summary of the properties of each type of BTNS, based on the previous subsections:
以下是基于前面小节的每种类型BTN的属性摘要：
SAB CBB
--------------------------------------------------------------
Uses Open services Same as SAB but with
Peer-to-peer higher-layer auth.,
Zero-config Infrastructure e.g., iSCSI [19], NFSv4 [21]
SAB CBB
--------------------------------------------------------------
Uses Open services Same as SAB but with
Peer-to-peer higher-layer auth.,
Zero-config Infrastructure e.g., iSCSI [19], NFSv4 [21]
Vuln. Masqueraders Masqueraders until bound Needs data rate limit Needs data rate limit Load on IPsec Load on IPsec Exposure to open access
沃恩。伪装器伪装器绑定前需要数据速率限制需要IPsec上的数据速率限制加载IPsec上的加载公开访问的IPsec公开
Benefit Protects L3 & L4 Protects L3 & L4 Avoids all auth. keys Avoids L3 auth. keys Full auth. once bound
福利保护L3和L4保护L3和L4避免所有身份验证。密钥避免L3身份验证。密钥完全授权。一旦绑定
Most of the potential vulnerabilities in the above table have been discussed in previous sections of this document; some of the more general issues, such as the increased load on IPsec processing, are addressed in the Security Considerations section of this document.
上表中的大多数潜在漏洞已在本文件前几节中讨论过；本文档的“安全注意事项”部分讨论了一些更一般的问题，例如IPsec处理负载的增加。
This section describes the threat models for BTNS and discusses other security issues based on the threat models for different modes of BTNS. Some of the issues were mentioned previously in the document but are listed again for completeness.
本节介绍了BTN的威胁模型，并根据不同模式BTN的威胁模型讨论了其他安全问题。其中一些问题在本文件前面已经提到，但为了完整起见，再次列出。
BTNS is intended to protect sessions from a variety of threats, including on-path, man-in-the-middle attacks after key exchange, and off-path attacks. It is intended to protect the contents of a session once established, but does not protect session establishment itself. This protection has value because it forces the attacker to target connection establishment as opposed to waiting for a more convenient time; this is of particular value for long-lived sessions.
BTN旨在保护会话免受各种威胁，包括路径上、密钥交换后的中间人攻击和非路径攻击。它旨在保护会话建立后的内容，但不保护会话建立本身。这种保护具有价值，因为它迫使攻击者以建立连接为目标，而不是等待更方便的时间；这对于长期会话特别有价值。
BTNS is not intended to protect the key exchange itself, so this presents an opportunity for a man-in-the-middle attack or a well-timed attack from other sources. Furthermore, Stand-Alone BTNS is not intended to protect the endpoint from nodes masquerading as legitimate clients of a higher-layer protocol or service. Channel-Bound BTNS can protect from such masquerading, though at a later point after the security association is established, as a masquerade attack causes a client authentication failure at a higher layer.
BTN不打算保护密钥交换本身，因此这为中间人攻击或来自其他来源的适时攻击提供了机会。此外，独立BTN不打算保护端点不受伪装成更高层协议或服务的合法客户端的节点的影响。信道绑定的BTN可以防止此类伪装，尽管在建立安全关联后的稍后时间，因为伪装攻击会导致更高层的客户端身份验证失败。
BTNS is also not intended to protect from DoS (Denial of Service) attacks that seek to overload a CPU performing authentication or other security computations, nor is BTNS intended to provide protection from configuration mistakes. These latter two threat assumptions are also the case for IPsec.
BTN也不是为了防止DoS（拒绝服务）攻击，这些攻击试图使CPU过载，从而执行身份验证或其他安全计算，BTN也不是为了防止配置错误。后两种威胁假设也适用于IPsec。
The following sections discuss the implications of the threat models in more details.
以下各节将更详细地讨论威胁模型的含义。
As with any aspect of network security, the use of BTNS must not interfere with other security services. Within IPsec, the scope of BTNS is limited to the SPD and PAD entries that explicitly specify BTNS and to the resulting SAD entries. It is incumbent on system administrators to deploy BTNS only where safe, preferably as an alternative to the use of "bypass" SPD entries that exempt specified
与网络安全的任何方面一样，BTN的使用不得干扰其他安全服务。在IPsec中，BTN的范围仅限于显式指定BTN的SPD和PAD条目以及由此产生的SAD条目。系统管理员有责任仅在安全的情况下部署BTN，最好是作为使用豁免指定的“旁路”SPD条目的替代方案
traffic from IPsec cryptographic protection. In other words, BTNS should be used only as a substitute for no security, rather than as a substitute for stronger security. When the higher-layer authentication required for CBB is not available, other methods, such as IP address filtering, can help reduce the vulnerability of SAB to exposure to anonymous access.
来自IPsec加密保护的流量。换言之，BTN只能作为无安全性的替代品，而不能作为更高安全性的替代品。当CBB所需的更高层身份验证不可用时，其他方法（如IP地址过滤）可以帮助减少SAB暴露于匿名访问的漏洞。
Previous sections have described how CBB can counter MITM and masquerader attacks, even though BTNS does not protect key exchange and does not authenticate peer identities at the network layer. Nonetheless, there are some security issues regarding CBB that must be carefully evaluated before deploying BTNS.
前面的章节描述了CBB如何对抗MITM和伪装攻击，即使BTN不保护密钥交换，也不在网络层验证对等身份。尽管如此，在部署BTN之前，必须仔细评估CBB的一些安全问题。
For regular IPsec/IKE, a man in the middle cannot subvert IKE authentication, and hence an attempt to attack an IPsec SA via use of two SAs concatenated by the attacker acting as a traffic-forwarding proxy will cause an IKE authentication failure. On the other hand, a man-in-the-middle attack on IPsec with CBB is discovered later. With CBB, the IKE protocol will succeed because it is unauthenticated, and the security associations will be set up. The man in the middle will not be discovered until the higher-layer authentication fails. There are two security concerns with this approach: possible exposure of sensitive authentication information to the attackers, and resource consumption before attacks are detected.
对于常规IPSEC/IKE，中间人不能颠覆IKE身份验证，因此试图通过使用攻击者作为业务转发代理级联的两个SAS来攻击IPSec SA将导致IKE认证失败。另一方面，后来发现了一个使用CBB的中间人攻击IPsec。使用CBB，IKE协议将成功，因为它未经身份验证，并且将建立安全关联。中间层的人直到高层认证失败才被发现。这种方法存在两个安全问题：敏感身份验证信息可能暴露给攻击者，以及检测到攻击之前的资源消耗。
The exposure of information depends on the higher-layer authentication protocols used in applications. If the higher-layer authentication requires exchange of sensitive information (e.g., passwords or password-derived materials) that are directly useful or can be attacked offline, an attacker can gain such information even though the attack can be detected. Therefore, CBB must not be used with higher-layer protocols that may expose sensitive information during authentication exchange. For example, Kerberos V AP exchanges would leak little other than the target's krb5 principal name, while Kerberos V AS exchanges using PA-ENC-TIMESTAMP pre-authentication would leak material that can then be attacked offline. The latter should not be used with BTNS, even with Channel Binding. Further, the ways in which BTNS is integrated with the higher-layer protocol must take into consideration vulnerabilities that could be introduced in the APIs between these two systems or in the information that they share.
信息的公开取决于应用程序中使用的高层身份验证协议。如果高层身份验证需要交换直接有用或可在脱机状态下受到攻击的敏感信息（例如密码或密码衍生材料），则即使可以检测到攻击，攻击者也可以获得此类信息。因此，CBB不得与可能在身份验证交换期间暴露敏感信息的高层协议一起使用。例如，Kerberos V AP交换只会泄漏目标的krb5主体名称，而使用PA-ENC-TIMESTAMP预身份验证的Kerberos V AS交换则会泄漏可以脱机攻击的内容。后者不应与BTN一起使用，即使与信道绑定一起使用也是如此。此外，BTN与高层协议集成的方式必须考虑到这两个系统之间的API或它们共享的信息中可能引入的漏洞。
The resource consumption issue is addressed in the next section on DoS attacks.
下一节将讨论DoS攻击的资源消耗问题。
A consequence of BTNS deployment is that more traffic requires cryptographic operations; these operations increase the computation required in IPsec implementations that receive protected traffic and/or verify incoming traffic. That additional computation raises vulnerability to overloading, which may be the result of legitimate flash crowds or a DoS or DDoS attack. Although this may itself present a substantial impediment to deployment, it is an issue for all cryptographically protected communication systems. This document does not address the impact BTNS has on such increases in required computation.
BTN部署的结果是，更多的流量需要加密操作；这些操作增加了接收受保护流量和/或验证传入流量的IPsec实现中所需的计算量。这种额外的计算增加了过载的脆弱性，过载可能是合法的flash群组或DoS或DDoS攻击的结果。尽管这本身可能会对部署造成重大障碍，但对于所有受密码保护的通信系统来说都是一个问题。本文件并未说明BTN对所需计算量增加的影响。
The effects of the increased resource consumption are twofold. The consumption raises the level of effort for attacks such as MITM, but also consumes more resources to detect such attacks and to reject spoofed traffic. At the network layer, proper limits and access controls for resources should be set up for all BTNS SAs. CBB SAs may be granted increased resource access after the higher-layer authentications succeed. The same principles apply to the higher-layer protocols that use CBB SAs. Special care must be taken to avoid excessive resource usage before authentication is established in these applications.
资源消耗增加的影响是双重的。这种消耗提高了攻击（如MITM）的工作水平，但也消耗了更多的资源来检测此类攻击和拒绝伪造流量。在网络层，应为所有BTN SA设置适当的资源限制和访问控制。在高层身份验证成功后，可以向CBB SA授予增加的资源访问权限。同样的原则也适用于使用CBB SAs的高层协议。在这些应用程序中建立身份验证之前，必须特别注意避免过度使用资源。
The use of SAB by a service implies that the service is being offered for open access, since network-layer authentication is not performed. SAB should not be used with services that are not intended to be openly available.
服务使用SAB意味着该服务是为开放访问提供的，因为不执行网络层身份验证。SAB不应与不打算公开提供的服务一起使用。
This document does not consider ICMP attacks because the use of BTNS does not change the existing IPsec guidelines on ICMP traffic handling [8]. BTNS focuses on the authentication part of establishing security associations. BTNS does not alter the IPsec traffic processing model and protection boundary. As a result, the entire IPsec packet processing guidelines, including ICMP processing, remain applicable when BTNS is added to IPsec.
该文件不考虑ICMP攻击，因为使用BTNS不改变现有的IPSec关于ICMP业务处理的准则[8 ]。BTN侧重于建立安全关联的身份验证部分。BTN不会改变IPsec流量处理模型和保护边界。因此，当BTN添加到IPsec时，整个IPsec数据包处理指南（包括ICMP处理）仍然适用。
BTNS allows systems to accept and establish security associations with peers without authenticating their identities. This can enable functionality similar to "Leap of Faith" authentication utilized in other security protocols and applications such as the Secure Shell Protocol (SSH) [29].
BTN允许系统接受并与对等方建立安全关联，而无需验证其身份。这可以实现类似于其他安全协议和应用程序（如安全外壳协议（SSH）[29]中使用的“信任飞跃”身份验证的功能。
SSH implementations are allowed to accept unknown peer credentials (host public keys) without authentication, and these unauthenticated credentials may be cached in local databases for future authentication of the same peers. Similar to BTNS, such measures are allowed due to the lack of "widely deployed key infrastructure" [29] and to improve ease of use and end-user acceptance.
SSH实现允许在不进行身份验证的情况下接受未知的对等凭据（主机公钥），并且这些未经身份验证的凭据可以缓存在本地数据库中，以便将来对相同的对等进行身份验证。与BTN类似，由于缺乏“广泛部署的关键基础设施”[29]，并且为了提高易用性和最终用户接受度，允许采取此类措施。
There are subtle differences between SSH and BTNS regarding Leap of Faith, as shown in the following table:
SSH和BTN在信仰飞跃方面存在细微差异，如下表所示：
| SSH | BTNS |
-------------------------------+---------+---------+
Accept unauthenticated | Allowed | Allowed |
credentials | | |
-------------------------------+---------+---------+
Options/Warnings to reject | Yes | No |
unauthenticated credentials | | |
-------------------------------+---------+---------+
Cache unauthenticated |Required | Allowed |
credential for future refs | | |
-------------------------------+---------+---------+
| SSH | BTNS |
-------------------------------+---------+---------+
Accept unauthenticated | Allowed | Allowed |
credentials | | |
-------------------------------+---------+---------+
Options/Warnings to reject | Yes | No |
unauthenticated credentials | | |
-------------------------------+---------+---------+
Cache unauthenticated |Required | Allowed |
credential for future refs | | |
-------------------------------+---------+---------+
SSH requires proper warnings and options in applications to reject unauthenticated credentials, while BTNS accepts such credentials automatically when they match the corresponding policy entries. Once SSH accepts a credential for the first time, that credential should be cached and can be reused automatically without further warnings. BTNS credentials can be cached for future use, but there is no security advantage to doing so, as a new unauthenticated credential that is allowed by the policy entries will be automatically accepted.
SSH需要在应用程序中提供适当的警告和选项，以拒绝未经验证的凭据，而BTN在匹配相应的策略条目时自动接受此类凭据。一旦SSH第一次接受凭证，该凭证应该被缓存，并且可以在没有进一步警告的情况下自动重用。BTNS凭据可以缓存以供将来使用，但这样做没有安全优势，因为策略条目允许的新未经验证的凭据将被自动接受。
In addition, BTNS does not require IPsec to reuse credentials in a manner similar to SSH. When IPsec does reuse unauthenticated credentials, there may be implementation advantages to caching them.
此外，BTN不需要IPsec以类似于SSH的方式重用凭据。当IPsec确实重用未经身份验证的凭据时，缓存它们可能有实现优势。
SSH-style credential caching for reuse with SAB could be addressed by future extension(s) to BTNS; such extension(s) would need to provide warnings about unauthenticated credentials and a mechanism for user acceptance or rejection of them in order to establish a level of authentication assurance comparable to SSH's "Leap of Faith". Such extension(s) would also need to deal with issues caused by the absence of identities in BTNS. At best, a cached BTNS credential reauthenticates the network-layer source of traffic when the credential is reused -- in contrast, SSH credential reuse reauthenticates an identity.
用于与SAB重用的SSH风格的凭证缓存可以通过未来的BTN扩展来解决；此类扩展需要提供有关未经验证的凭据的警告以及用户接受或拒绝凭据的机制，以便建立与SSH的“信任飞跃”相当的认证保证级别。这种扩展还需要处理由于BTN中缺少身份而导致的问题。充其量，当凭证被重用时，缓存的BTNS凭证会重新验证网络层流量源——相反，SSH凭证重用会重新验证身份。
Network-layer reauthentication for SAB is further complicated by:
SAB的网络层重新验证由于以下原因而变得更加复杂：
o the ability of NATs to cause multiple independent network-layer sources of traffic to appear to be one source (potentially requiring acceptance and caching of multiple BTNS credentials),
o NAT能够使多个独立的网络层流量源看起来是一个源（可能需要接受和缓存多个BTN凭据），
o the ability of multihoming to cause one network-layer source of traffic to appear to be multiple sources (potentially triggering unexpected warnings and requiring re-acceptance of the same BTNS credential), and
o 多归属使一个网络层流量源看起来是多个源的能力（可能触发意外警告并要求重新接受相同的BTN凭据），以及
o interactions with both mobility and address ownership changes (potentially requiring controlled BTNS credential reassignment and/or invalidation).
o 与移动性和地址所有权更改的交互（可能需要受控BTN凭据重新分配和/或失效）。
These issues are left to be addressed by possible future work on the addition of "Leap of Faith" functionality to BTNS.
这些问题有待于将来可能在BTN中增加“信仰飞跃”功能的工作来解决。
In contrast, for CBB, credential caching and verification are usually done at the higher-layer protocols or applications. Caching credentials for CBB at the BTNS level is not as important because the channel binding will bind whatever credentials are presented (new or cached) to the higher-layer protocol identity.
相反，对于CBB，凭据缓存和验证通常在更高层的协议或应用程序中完成。在BTNS级别缓存CBB的凭据没有那么重要，因为通道绑定会将提供的任何凭据（新的或缓存的）绑定到更高层的协议标识。
Each IPsec SA has a limited lifetime (defined as a time and/or byte count) and must be rekeyed or terminated when the lifetime expires. Rekeying an SA provides a small window of opportunity where an on-path attacker can step in and hijack the new SA created by rekeying by spoofing the victim during rekeying. BTNS, and particularly SAB, simplify this attack by removing the need for the attacker to authenticate as the victim or via the same non-BTNS PAD entry that was used by the victim for the original SA. CBB, on the other hand, can detect such attacks by detecting the changes in the secure channel properties.
每个IPsec SA都有一个有限的生存期（定义为时间和/或字节计数），并且必须在生存期到期时重新设置密钥或终止。为SA重新设置密钥提供了一个很小的机会窗口，路径上的攻击者可以通过在重新设置密钥期间欺骗受害者，介入并劫持通过重新设置密钥创建的新SA。BTN，尤其是SAB，通过消除攻击者作为受害者进行身份验证的需要，或通过受害者为原始SA使用的相同非BTN PAD条目，简化了此攻击。另一方面，CBB可以通过检测安全信道属性的变化来检测此类攻击。
This vulnerability is caused by the lack of inter-session binding or latching of IKE SAs with the corresponding credentials of the two peers. Connection latching, together with channel binding, enables such binding but requires higher-layer protocols or applications to verify consistency of identities and authentication across the two SAs.
此漏洞是由于缺少会话间绑定或IKE SA与两个对等方的相应凭据的锁定造成的。连接锁存和通道绑定支持此类绑定，但需要更高层的协议或应用程序来验证两个SA之间身份和身份验证的一致性。
BTNS does not address errors of configuration that could result in increased vulnerability; such vulnerability is already possible using "bypass" SPD entries. SPD entries that allow BTNS must be explicitly flagged, and hence can be kept separate from SPD entries that do not allow BTNS, just as "bypass" SPD entries are separate from entries that create SAs with more conventional, stronger security.
BTN不解决可能导致漏洞增加的配置错误；使用“绕过”SPD条目已经可能存在此类漏洞。允许BTN的SPD条目必须明确标记，因此可以与不允许BTN的SPD条目分开，就像“旁路”SPD条目与创建具有更传统、更强安全性的SA的条目分开一样。
There have been a number of related efforts in the IETF and elsewhere to reduce the configuration effort of deploying the Internet security suite.
IETF和其他地方已经进行了大量相关工作，以减少部署Internet安全套件的配置工作。
The IETF PKI4IPsec effort focused on providing an automatic infrastructure for the configuration of Internet security services, e.g., to assist in deploying signed certificates and CA information [9]. The IETF KINK effort focused on adapting Kerberos [13] for IKE, enabling IKE to utilize the Kerberos key distribution infrastructure rather than requiring certificates or shared private keys [18]. KINK takes advantage of an existing architecture for automatic key management in Kerberos. Opportunistic Encryption (OE) is a system for automatic discovery of hosts willing to do a BTNS-like encryption, with authentication being exchanged by leveraging existing use of the DNS [17]. BTNS differs from all three in that BTNS is intended to avoid the need for such infrastructure altogether, rather than to automate it.
IETF PKI4IPsec的工作重点是为Internet安全服务的配置提供自动基础设施，例如，帮助部署签名证书和CA信息[9]。IETF的扭结工作集中在为IKE调整Kerberos[13]，使IKE能够利用Kerberos密钥分发基础设施，而不需要证书或共享私钥[18]。KINK利用现有的体系结构实现Kerberos中的自动密钥管理。机会主义加密（OE）是一种自动发现愿意进行BTN加密的主机的系统，通过利用DNS的现有使用来交换身份验证[17]。BTN与所有三种不同之处在于，BTN旨在完全避免对此类基础设施的需求，而不是使其自动化。
This document was inspired by discussions on the IETF TCPM WG about the spoofed RST attacks on BGP routers and various solutions, as well as discussions in the NFSv4 and IPS WGs about how to better integrate with IPsec. The concept of BTNS was the result of these discussions as well as discussions with USC/ISI's T. Faber, A. Falk, and B. Tung, and discussions on the IETF SAAG (Security Area open meeting) mailing list and IPsec mailing list. The authors would like to thank the members of those WGs and lists, as well as the IETF BTNS BOFs and WG and its associated ANONsec mailing list (http://www.postel.org/anonsec) for their feedback -- in particular, Steve Kent, Sam Hartman, Nicolas Williams, and Pekka Savola.
本文档的灵感来源于IETF TCPM工作组关于BGP路由器上的欺骗RST攻击和各种解决方案的讨论，以及NFSv4和IPS工作组关于如何更好地与IPsec集成的讨论。BTN的概念是这些讨论以及与USC/ISI的T.Faber、A.Falk和B.Tung讨论的结果，并讨论了IETF SAAG（安全区域公开会议）邮件列表和IPsec邮件列表。作者要感谢这些工作组和列表的成员，以及IETF BTNS BOF和工作组及其相关的ANONsec邮件列表(http://www.postel.org/anonsec)感谢他们的反馈——特别是史蒂夫·肯特、山姆·哈特曼、尼古拉斯·威廉姆斯和佩卡·萨沃拉。
This document was prepared using 2-Word-v2.0.template.dot.
本文件使用2-Word-v2.0.template.dot编制。
[1] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[1] Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，Ed.，“可扩展认证协议（EAP）”，RFC 37482004年6月。
[2] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
[2] Aboba，B.，Tseng，J.，Walker，J.，Rangan，V.，和F.Travostino，“通过IP保护块存储协议”，RFC 37232004年4月。
[3] CERT Vulnerability Note VU#415294, "The Border Gateway Protocol relies on persistent TCP sessions without specifying authentication requirements", 4/20/2004.
[3] CERT漏洞注意事项VU#415294，“边界网关协议依赖于持久TCP会话而不指定身份验证要求”，2004年4月20日。
[4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[4] Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[5] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[5] Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[6] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[6] Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[7] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[7] Kaufman，C.，编辑，“因特网密钥交换（IKEv2）协议”，RFC 4306，2005年12月。
[8] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[8] Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[9] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007.
[9] Korver，B.，“IKEv1/ISAKMP、IKEv2和PKIX的互联网IP安全PKI配置文件”，RFC 49452007年8月。
[10] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[10] 林恩，J.，“通用安全服务应用程序接口版本2，更新1”，RFC 2743，2000年1月。
[11] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[11] Melnikov，A.，Ed.，和K.Zeilenga，Ed.，“简单身份验证和安全层（SASL）”，RFC 4422，2006年6月。
[12] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006.
[12] Murphy，S.，“BGP安全漏洞分析”，RFC 4272，2006年1月。
[13] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[13] Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，RFC41202005年7月。
[14] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[14] Moskowitz，R.，Nikander，P.，Jokela，P.，Ed.，和T.Henderson，“主机身份协议”，RFC 5201，2008年4月。
[15] Ramaiah, A., R Stewart, M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", Work in Progress, January 2008.
[15] Ramaiah，A.，R Stewart，M.Dalal，“提高TCP对窗口盲攻击的鲁棒性”，正在进行的工作，2008年1月。
[16] Recio, R., Metzler, B., Culley, P., Hilland, J., and D. Garcia, "A Remote Direct Memory Access Protocol Specification", RFC 5040, October 2007.
[16] Recio，R.，Metzler，B.，Culley，P.，Hilland，J.，和D.Garcia，“远程直接内存访问协议规范”，RFC 50402007年10月。
[17] Richardson, M. and D. Redelmeier, "Opportunistic Encryption using the Internet Key Exchange (IKE)", RFC 4322, December 2005.
[17] Richardson，M.和D.Redelmeier，“使用互联网密钥交换（IKE）的机会主义加密”，RFC 4322，2005年12月。
[18] Sakane, S., Kamada, K., Thomas, M., and J. Vilhuber, "Kerberized Internet Negotiation of Keys (KINK)", RFC 4430, March 2006.
[18] Sakane，S.，Kamada，K.，Thomas，M.，和J.Vilhuber，“密钥的Kerberized Internet协商（扭结）”，RFC 4430，2006年3月。
[19] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
[19] Satran，J.，Meth，K.，Sapuntzakis，C.，Chadalapaka，M.，和E.Zeidner，“互联网小型计算机系统接口（iSCSI）”，RFC 3720，2004年4月。
[20] Shah, H., Pinkerton, J., Recio, R., and P. Culley, "Direct Data Placement over Reliable Transports", RFC 5041, October 2007.
[20] Shah，H.，Pinkerton，J.，Recio，R.，和P.Culley，“可靠传输上的直接数据放置”，RFC 50412007年10月。
[21] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003.
[21] Shepler，S.，Callaghan，B.，Robinson，D.，Thurlow，R.，Beame，C.，Eisler，M.，和D.Noveck，“网络文件系统（NFS）版本4协议”，RFC 3530，2003年4月。
[22] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[22] Stewart，R.，编辑，“流控制传输协议”，RFC 4960，2007年9月。
[23] TCP SYN-cookies, http://cr.yp.to/syncookies.html
[23] TCP SYN-cookies, http://cr.yp.to/syncookies.html
[24] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007.
[24] Touch，J.，“保护TCP免受欺骗攻击”，RFC 4953，2007年7月。
[25] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication Option", Work in Progress, November 2007.
[25] Touch，J.，A.Mankin，R.Bonica，“TCP认证选项”，正在进行的工作，2007年11月。
[26] Williams, N., "IPsec Channels: Connection Latching", Work in Progress, April 2008.
[26] Williams，N.，“IPsec通道：连接锁存”，正在进行的工作，2008年4月。
[27] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
[27] Williams，N.，“关于使用通道绑定保护通道”，RFC 5056，2007年11月。
[28] Williams, N. and M. Richardson, "Better-Than-Nothing Security: An Unauthenticated Mode of IPsec", RFC 5386, November 2008.
[28] Williams，N.和M.Richardson，“比没有更好的安全性：未经验证的IPsec模式”，RFC 5386，2008年11月。
[29] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[29] Ylonen，T.和C.Lonvick，Ed.，“安全外壳（SSH）协议架构”，RFC 4251，2006年1月。
Authors' Addresses
作者地址
Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 U.S.A.
Joe Touch USC/ISI 4676美国加利福尼亚州玛丽娜·德雷海军部路90292-6695号。
Phone: +1 (310) 448-9151
EMail: touch@isi.edu
Phone: +1 (310) 448-9151
EMail: touch@isi.edu
David L. Black EMC Corporation 176 South Street Hopkinton, MA 01748 USA
David L.Black EMC Corporation美国马萨诸塞州霍普金顿南街176号01748
Phone: +1 (508) 293-7953
EMail: black_david@emc.com
Phone: +1 (508) 293-7953
EMail: black_david@emc.com
Yu-Shun Wang Microsoft One Microsoft Way Redmond, WA 98052 U.S.A.
王宇顺微软美国华盛顿州雷德蒙微软一路98052。
Phone: +1 (425) 722-6980
EMail: yu-shun.wang@microsoft.com
Phone: +1 (425) 722-6980
EMail: yu-shun.wang@microsoft.com