Network Working Group N. Williams
Request for Comments: 5386 Sun
Category: Standards Track M. Richardson
SSW
November 2008
Network Working Group N. Williams
Request for Comments: 5386 Sun
Category: Standards Track M. Richardson
SSW
November 2008
Better-Than-Nothing Security: An Unauthenticated Mode of IPsec
比没有更好的安全性：未经验证的IPsec模式
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
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
摘要
This document specifies how to use the Internet Key Exchange (IKE) protocols, such as IKEv1 and IKEv2, to setup "unauthenticated" security associations (SAs) for use with the IPsec Encapsulating Security Payload (ESP) and the IPsec Authentication Header (AH). No changes to IKEv2 bits-on-the-wire are required, but Peer Authorization Database (PAD) and Security Policy Database (SPD) extensions are specified. Unauthenticated IPsec is herein referred to by its popular acronym, "BTNS" (Better-Than-Nothing Security).
本文档指定了如何使用Internet密钥交换（IKE）协议（如IKEv1和IKEv2）来设置“未经验证”的安全关联（SA），以便与IPsec封装安全负载（ESP）和IPsec身份验证头（AH）一起使用。不需要更改线路上的IKEv2位，但指定了对等授权数据库（PAD）和安全策略数据库（SPD）扩展。未经认证的IPsec在本文中使用其流行的首字母缩写“BTN”（总比没有安全性好）。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 2
2. BTNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Example #1: A Security Gateway . . . . . . . . . . . . . . 5
3.2. Example #2: A Mixed End-System . . . . . . . . . . . . . . 7
3.3. Example #3: A BTNS-Only System . . . . . . . . . . . . . . 8
3.4. Miscellaneous Comments . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
4.1. Connection Latching and Channel Binding . . . . . . . . . 9
4.2. Leap-of-Faith (LoF) for BTNS . . . . . . . . . . . . . . . 10
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 2
2. BTNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Example #1: A Security Gateway . . . . . . . . . . . . . . 5
3.2. Example #2: A Mixed End-System . . . . . . . . . . . . . . 7
3.3. Example #3: A BTNS-Only System . . . . . . . . . . . . . . 8
3.4. Miscellaneous Comments . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
4.1. Connection Latching and Channel Binding . . . . . . . . . 9
4.2. Leap-of-Faith (LoF) for BTNS . . . . . . . . . . . . . . . 10
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . . 10
Here we describe how to establish unauthenticated IPsec SAs using IKEv2 [RFC4306] and unauthenticated public keys. No new on-the-wire protocol elements are added to IKEv2.
这里我们描述如何使用IKEv2[RFC4306]和未经验证的公钥建立未经验证的IPsec SA。IKEv2中未添加新的在线协议元素。
The [RFC4301] processing model is assumed.
假设[RFC4301]处理模型。
This document does not define an opportunistic BTNS mode of IPsec whereby nodes may fall back to unprotected IP when their peers do not support IKEv2, nor does it describe "leap-of-faith" modes or "connection latching".
本文档未定义IPsec的机会BTNS模式，即当节点的对等方不支持IKEv2时，节点可能会退回到未受保护的IP，也未描述“信任跳跃”模式或“连接锁定”。
See [RFC5387] for the applicability and uses of BTNS and definitions of these terms.
有关BTN的适用性和用途以及这些术语的定义，请参见[RFC5387]。
This document describes BTNS in terms of IKEv2 and [RFC4301]'s concepts. There is no reason why the same methods cannot be used with IKEv1 [RFC2408], [RFC2409], and [RFC2401]; however, those specifications do not include the PAD concepts, and therefore it may not be possible to implement BTNS on all compliant RFC2401 implementations.
本文档根据IKEv2和[RFC4301]的概念描述了BTN。没有理由不能将相同的方法用于IKEv1[RFC2408]、[RFC2409]和[RFC2401]；然而，这些规范不包括PAD概念，因此不可能在所有符合RFC2401的实现上实现BTN。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The IPsec processing model is hereby modified as follows:
IPsec处理模型特此修改如下：
o A new ID type is added: 'PUBLICKEY'. IDs of this type have public keys as values. This ID type is not used on the wire.
o 添加了一个新的ID类型：“公钥”。此类型的ID将公钥作为值。此ID类型未在导线上使用。
o PAD entries that match on PUBLICKEY IDs are referred to as "BTNS PAD entries". All other PAD entries are referred to as "non-BTNS PAD entries".
o 与公钥ID匹配的PAD条目称为“BTNS PAD条目”。所有其他PAD条目称为“非BTNS PAD条目”。
o BTNS PAD entries may match on specific peer PUBLICKEY IDs (or public key fingerprints) or on all peer public keys. The latter is referred to as the "wildcard BTNS PAD entry".
o BTN PAD条目可能与特定对等公钥ID（或公钥指纹）或所有对等公钥匹配。后者被称为“通配符BTN PAD条目”。
o BTNS PAD entries MUST logically (see below) follow all other PAD entries (the PAD being an ordered list).
o BTN PAD条目必须逻辑（见下文）跟随所有其他PAD条目（PAD是一个有序列表）。
o At most one wildcard BTNS PAD entry may appear in the PAD, and, if present, MUST be the last entry in the PAD (see below).
o PAD中最多可以出现一个通配符BTN PAD条目，如果存在，则必须是PAD中的最后一个条目（见下文）。
o Any peer that uses an IKEv2 AUTH method involving a digital signature (made with a private key to a public key cryptosystem) may match a BTNS PAD entry, provided that it matches no non-BTNS PAD entries. Suitable AUTH methods as of August 2007 are: RSA Digital Signature (method #1) and DSS Digital Signature (method #3); see [RFC4306], Section 3.8.
o 任何使用涉及数字签名（使用公钥密码系统的私钥制作）的IKEv2身份验证方法的对等方都可以匹配BTNS PAD条目，前提是它不匹配非BTNS PAD条目。截至2007年8月，合适的身份验证方法有：RSA数字签名（方法1）和DSS数字签名（方法3）；见[RFC4306]，第3.8节。
o A BTNS-capable implementation of IPsec will first search the PAD for non-BTNS entries matching a peer's ID. If no matching non-BTNS PAD entries are found, then the peer's ID MUST be coerced to be of 'PUBLICKEY' type with the peer's public key as its value. The PAD is then searched again for matching BTNS PAD entries. This ensures that BTNS PAD entries logically follow non-BTNS PAD entries. A single PAD search that preserves these semantics is allowed.
o 支持BTNS的IPsec实现将首先在PAD中搜索与对等方ID匹配的非BTNS条目。如果未找到匹配的非BTNS PAD条目，则必须强制对等方的ID为“公钥”类型，并将对等方的公钥作为其值。然后再次搜索PAD以查找匹配的BTN PAD条目。这确保了BTNS PAD条目在逻辑上遵循非BTNS PAD条目。允许使用保留这些语义的单键盘搜索。
o A peer that matches a BTNS PAD entry is referred to as a "BTNS peer". Such a peer is "authenticated" by verifying the signature in its IKEv2 AUTH payload with the public key from the peer's CERT payload.
o 与BTNS PAD条目匹配的对等方称为“BTNS对等方”。通过使用对等方证书有效载荷中的公钥验证其IKEv2 AUTH有效载荷中的签名，可以对此类对等方进行“身份验证”。
o Of course, if no matching PAD entry is found, then the IKE SA is rejected as usual.
o 当然，如果没有找到匹配的PAD条目，那么像往常一样拒绝IKE SA。
o A new flag for SPD entries: 'BTNS_OK'. Traffic to/from peers that match the BTNS PAD entry will match only SPD entries that have the BTNS_OK flag set. The SPD may be searched by address or by ID (of type PUBLICKEY for BTNS peers), as per the IPsec processing model [RFC4301]. Searching by ID in this case requires creation of SPD entries that are bound to public key values. This could be used to build "leap-of-faith" [RFC5387] behavior (see Section 4.2), for example.
o SPD条目的新标志：“BTNS_OK”。与BTNS PAD条目匹配的对等方之间的通信量将仅与设置了BTNS_OK标志的SPD条目匹配。根据IPsec处理模型[RFC4301]，可以通过地址或ID（BTN对等方的公钥类型）搜索SPD。在这种情况下，按ID搜索需要创建绑定到公钥值的SPD条目。例如，这可以用来建立“信仰的飞跃”[RFC5387]行为（参见第4.2节）。
Nodes MUST reject IKE_SA proposals from peers that match non-BTNS PAD entries but fail to authenticate properly.
节点必须拒绝来自匹配非BTN PAD条目但无法正确验证的对等方的IKE_SA建议。
Nodes wishing to be treated as BTNS nodes by their peers MUST include bare public key CERT payloads. Currently only bare RSA public key CERT payloads are defined, which means that BTNS works only with RSA public keys at this time (see "Raw RSA Key" in Section 3.6 of [RFC4306]). Nodes MAY also include any number of certificates that bind the same public key. These certificates do not need to be pre-shared with their peers (e.g., because ephemeral, self-signed). RSA keys for use in BTNS may be generated at any time, but connection latching [ConnLatch] requires that they remain constant between IKEv2 exchanges that are used to establish SAs for latched connections.
希望被其对等方视为BTN节点的节点必须包括裸公钥证书有效载荷。目前只定义了裸RSA公钥证书有效载荷，这意味着BTN此时只能使用RSA公钥（请参阅[RFC4306]第3.6节中的“原始RSA密钥”）。节点还可以包括绑定相同公钥的任意数量的证书。这些证书不需要预先与其对等方共享（例如，因为是短暂的、自签名的）。BTN中使用的RSA密钥可以随时生成，但连接锁存[ConnLatch]要求它们在用于为锁存连接建立SAs的IKEv2交换机之间保持恒定。
To preserve standard IPsec access control semantics:
要保留标准IPsec访问控制语义，请执行以下操作：
o BTNS PAD entries MUST logically follow all non-BTNS PAD entries,
o BTN PAD条目必须在逻辑上遵循所有非BTN PAD条目，
o the wildcard BTNS PAD entry MUST be the last entry in the PAD, logically, and
o 通配符BTNS PAD条目必须是PAD中的最后一个条目，逻辑上为，并且
o the wildcard BTNS PAD entry MUST have ID constraints that do not logically overlap those of other PAD entries.
o 通配符BTNS PAD条目必须具有在逻辑上不与其他PAD条目重叠的ID约束。
As described above, the logical PAD ordering requirements can easily be implemented by searching the PAD twice at peer authentication time: once using the peer-asserted ID, and if that fails, once using the peer's public key as a PUBLICKEY ID. A single pass implementation that meets this requirement is permitted.
如上所述，通过在对等身份验证时搜索PAD两次，可以轻松实现逻辑PAD排序要求：一次使用对等断言ID，如果失败，一次使用对等的公钥作为公钥ID。允许满足此要求的单次通过实现。
The BTNS entry ID constraint non-overlap requirement can easily be implemented by searching the PAD twice: once when BTNS peers authenticate, and again when BTNS peers negotiate child SAs. In the first pass, the PAD is searched for a matching PAD entry as described above. In the second, it is searched to make sure that BTNS peers' asserted child SA traffic selectors do not conflict with non-BTNS PAD entries. Single pass implementations that preserve these semantics are feasible.
BTNS入口ID约束非重叠要求可以通过搜索PAD两次轻松实现：一次是在BTNS对等方进行身份验证时，另一次是在BTNS对等方协商子SA时。在第一个过程中，如上所述，在焊盘上搜索匹配的焊盘条目。在第二种情况下，搜索它以确保BTNS对等方断言的子SA流量选择器不会与非BTNS PAD条目冲突。保持这些语义的单次传递实现是可行的。
In order to explain the above rules, a number of scenarios will be examined. The goal here is to persuade the reader that the above rules are both sufficient and necessary.
为了解释上述规则，我们将研究一些场景。这里的目的是说服读者上述规则是充分和必要的。
This section is informative only.
本节仅供参考。
To explain the scenarios, a reference diagram describing an example network will be used. It is as follows:
为了解释这些场景，将使用描述示例网络的参考图。详情如下:
[Q] [R]
AS1 . . AS2
[A]----+----[SG-A].......+....+.......[SG-B]-------[B]
...... \
..PI.. ----[btns-B]
......
[btns-C].....+....+.......[btns-D]
[Q] [R]
AS1 . . AS2
[A]----+----[SG-A].......+....+.......[SG-B]-------[B]
...... \
..PI.. ----[btns-B]
......
[btns-C].....+....+.......[btns-D]
Figure 1: Reference Network Diagram
图1：参考网络图
In this diagram, there are eight systems. Six systems are end-nodes (A, B, C, D, Q, and R). Two are security gateways (SG-A, SG-B) protecting networks on which [A] and [B] reside. Node [Q] is IPsec and BTNS capable. Node [R] is a simple node, with no IPsec or BTNS capability. Nodes [C] and [D] are BTNS capable.
在这个图中，有八个系统。六个系统是终端节点（A、B、C、D、Q和R）。两个是安全网关（SG-A、SG-B），用于保护[A]和[B]所在的网络。节点[Q]支持IPsec和BTN。节点[R]是一个简单的节点，没有IPsec或BTN功能。节点[C]和[D]支持BTN。
Nodes [C] and [Q] have fixed addresses. Node [D] has a non-fixed address.
节点[C]和[Q]具有固定地址。节点[D]具有非固定地址。
We will examine how these various nodes communicate with node [SG-A] and/or how [SG-A] rejects communications with some such nodes. In the first example, we examine [SG-A]'s point of view. In the second example, we look at [Q]'s point of view. In the third example, we look at [C]'s point of view.
我们将研究这些不同的节点如何与节点[SG-A]通信和/或[SG-A]如何拒绝与一些这样的节点通信。在第一个例子中，我们检查[SG-A]的观点。在第二个例子中，我们看[Q]的观点。在第三个例子中，我们看[C]的观点。
PI is the Public Internet ("The Wild").
PI是公共互联网（“野生”）。
The machine that we will focus on in this example is [SG-A], a firewall device of some kind that we wish to configure to respond to BTNS connections from [C].
本例中我们将重点关注的机器是[SG-A]，这是一种防火墙设备，我们希望将其配置为响应来自[C]的BTN连接。
[SG-A] has the following PAD and SPD entries:
[SG-A]具有以下PAD和SPD条目：
Child SA
Rule Remote ID IDs allowed SPD Search by
---- --------- ----------- -------------
1 <B's ID> <B's network> by-IP
2 <Q's ID> <Q's host> by-IP
3 PUBLICKEY:any ANY by-IP
Child SA
Rule Remote ID IDs allowed SPD Search by
---- --------- ----------- -------------
1 <B's ID> <B's network> by-IP
2 <Q's ID> <Q's host> by-IP
3 PUBLICKEY:any ANY by-IP
The last entry is the BTNS entry.
最后一个条目是BTNS条目。
Figure 2: [SG-A] PAD Table
图2:[SG-A]焊盘表
Note that [SG-A]'s PAD entry has one and only one wildcard PAD entry: the BTNS catch-all PAD entry as the last entry, as described in Section 2.
请注意，[SG-A]的PAD条目只有一个通配符PAD条目：BTN将所有PAD条目作为最后一个条目捕获，如第2节所述。
<Child SA IDs allowed> and <SPD Search by> are from [RFC4301], Section 4.4.3.
<Child SA ID allowed>和<SPD Search by>来自[RFC4301]，第4.4.3节。
Rule Local Remote Next Layer BTNS Action
addr addr Protocol ok
---- ----- ------ ---------- ---- -----------------------
1 [A] [R] ANY N/A BYPASS
2 [A] [Q] ANY no PROTECT(ESP,tunnel,AES,
SHA256)
3 [A] B-net ANY no PROTECT(ESP,tunnel,AES,
SHA256)
4 [A] ANY ANY yes PROTECT(ESP,transport,
integr+conf)
Rule Local Remote Next Layer BTNS Action
addr addr Protocol ok
---- ----- ------ ---------- ---- -----------------------
1 [A] [R] ANY N/A BYPASS
2 [A] [Q] ANY no PROTECT(ESP,tunnel,AES,
SHA256)
3 [A] B-net ANY no PROTECT(ESP,tunnel,AES,
SHA256)
4 [A] ANY ANY yes PROTECT(ESP,transport,
integr+conf)
Figure 3: [SG-A] SPD Table
图3:[SG-A]SPD表
The processing by [SG-A] of SA establishment attempts by various peers is as follows:
[SG-A]对不同对等方SA建立尝试的处理如下：
o [Q] does not match PAD entry #1 but does match PAD entry #2. PAD processing stops, then the SPD is searched by [Q]'s ID to find entry #2. CHILD SAs are then allowed that have [SG-A]'s and [Q]'s addresses as the end-point addresses.
o [Q] 与便笺簿条目#1不匹配，但与便笺簿条目#2匹配。PAD处理停止，然后通过[Q]的ID搜索SPD以查找条目#2。然后允许将[SG-A]和[Q]的地址作为端点地址的子SA。
o [SG-B] matches PAD entry #1. PAD processing stops, then the SPD is searched by [SG-B]'s ID to find SPD entry #3. CHILD SAs are then allowed that have [SG-A]'s address and any addresses from B's network as the end-point addresses.
o [SG-B]与键盘输入#1匹配。PAD处理停止，然后通过[SG-B]的ID搜索SPD以查找SPD条目#3。然后允许将[SG-A]的地址和B网络中的任何地址作为端点地址的子SA。
o [R] does not initiate any IKE SAs; its traffic to [A] is bypassed by SPD entry #1.
o [R] 不启动任何IKE SA；到[A]的流量由SPD入口1绕过。
o [C] does not match PAD entries #1 or #2 but does match entry #3, the BTNS wildcard PAD entry. The SPD is searched by [C]'s address, and SPD entry #4 is matched. CHILD SAs are then allowed that have [SG-A]'s address and [C]'s address as the end-point addresses, provided that [C]'s address is neither [Q]'s nor any of [B]'s (see Section 2). See the last bullet item below.
o [C] 不匹配PAD条目#1或#2，但匹配条目#3，即BTNS通配符PAD条目。通过[C]的地址搜索SPD，并匹配SPD条目#4。然后，允许将[SG-A]的地址和[C]的地址作为端点地址的子SA，前提是[C]的地址既不是[Q]也不是[B]中的任何一个（参见第2节）。请参阅下面最后一个项目符号。
o A rogue BTNS node attempting to assert [Q]'s or [B]'s addresses will either match the PAD entries for [Q] or [B] and fail to authenticate as [Q] or [B], in which case they are rejected, or they will match PAD entry #3 but will not be allowed to create CHILD SAs with [Q]'s or [B]'s addresses as traffic selectors.
o 试图断言[Q]或[B]地址的恶意BTN节点将与[Q]或[B]的PAD条目匹配，并且无法作为[Q]或[B]进行身份验证，在这种情况下，它们将被拒绝，或者它们将与PAD条目#3匹配，但不允许创建将[Q]或[B]地址作为流量选择器的子SA。
o A rogue BTNS node attempting to establish an SA whereby the rogue node asserts [C]'s address will succeed at establishing such an SA. Protection for [C] requires additional bindings of [C]'s specific BTNS ID (that is, its public key) to its traffic flows through connection latching and channel binding or through leap-of-faith, none of which are described here.
o 试图建立SA的恶意BTNS节点，通过该节点断言[C]的地址将成功建立这样的SA。对[C]的保护要求[C]的特定BTN ID（即其公钥）通过连接锁存和通道绑定或通过信仰的飞跃附加绑定到其流量，此处未描述任何绑定。
[Q] is an NFSv4 server.
[Q] 是一个NFSv4服务器。
[Q] is a native IPsec implementation, and its NFSv4 implementation is IPsec-aware.
[Q] 是本机IPsec实现，其NFSv4实现支持IPsec。
[Q] wants to protect all traffic with [A]. [Q] also wants to protect NFSv4 traffic with all peers. Its PAD and SPD are configured as follows:
[Q] 希望使用[A]保护所有流量。[Q] 还希望保护所有对等方的NFSv4流量。其PAD和SPD配置如下：
Child SA
Rule Remote ID IDs allowed SPD Search by
---- --------- ----------- -------------
1 <[A]'s ID> <[A]'s address> by-IP
2 PUBLICKEY:any ANY by-IP
Child SA
Rule Remote ID IDs allowed SPD Search by
---- --------- ----------- -------------
1 <[A]'s ID> <[A]'s address> by-IP
2 PUBLICKEY:any ANY by-IP
The last entry is the BTNS entry.
最后一个条目是BTNS条目。
Figure 4: [Q] PAD Table
图4:[Q]焊盘表
Rule Local Remote Next Layer BTNS Action
addr addr Protocol ok
---- ----- ------ ---------- ---- -----------------------
1 [Q] [A] ANY no PROTECT(ESP,tunnel,AES,
SHA256)
2 [Q] ANY ANY yes PROTECT(ESP,transport,
with integr+conf)
port 2049
Rule Local Remote Next Layer BTNS Action
addr addr Protocol ok
---- ----- ------ ---------- ---- -----------------------
1 [Q] [A] ANY no PROTECT(ESP,tunnel,AES,
SHA256)
2 [Q] ANY ANY yes PROTECT(ESP,transport,
with integr+conf)
port 2049
Figure 5: [Q] SPD Table
图5:[Q]SPD表
The same analysis shown above in Section 3.1 applies here with respect to [SG-A], [C], and rogue peers. The second SPD entry permits any BTNS-capable node to negotiate a port-specific SA to port 2049, the port on which NFSv4 runs. Additionally, [SG-B] is treated as a BTNS peer as it is not known to [Q], and therefore any host behind [SG-B] can access the NFSv4 service on [Q]. As [Q] has no formal relationship with [SG-B], rogues can impersonate [B] (i.e., assert [B]'s addresses).
上文第3.1节中所示的相同分析适用于[SG-A]、[C]和流氓对等方。第二个SPD条目允许任何支持BTNS的节点将特定于端口的SA协商到端口2049，即运行NFSv4的端口。此外，[SG-B]被视为BTNS对等，因为[Q]不知道它，因此[SG-B]后面的任何主机都可以访问[Q]上的NFSv4服务。由于[Q]与[SG-B]没有正式关系，流氓可以冒充[B]（即断言[B]的地址）。
[C] supports only BTNS and wants to use BTNS to protect NFSv4 traffic. Its PAD and SPD are configured as follows:
[C] 仅支持BTN，并希望使用BTN来保护NFSv4流量。其PAD和SPD配置如下：
Child SA
Rule Remote ID IDs allowed SPD Search by
---- --------- ----------- -------------
1 PUBLICKEY:any ANY by-IP
Child SA
Rule Remote ID IDs allowed SPD Search by
---- --------- ----------- -------------
1 PUBLICKEY:any ANY by-IP
The last (and only) entry is the BTNS entry.
最后一个（也是唯一一个）条目是BTNS条目。
Figure 6: [Q] PAD Table
图6:[Q]焊盘表
Rule Local Remote Next Layer BTNS Action
addr addr Protocol ok
---- ----- ------ ---------- ---- -----------------------
1 [C] ANY ANY yes PROTECT(ESP,transport,
with integr+conf)
port
2049
Rule Local Remote Next Layer BTNS Action
addr addr Protocol ok
---- ----- ------ ---------- ---- -----------------------
1 [C] ANY ANY yes PROTECT(ESP,transport,
with integr+conf)
port
2049
2 [C] ANY ANY N/A BYPASS
2[C]任何不适用旁路
Figure 7: [SG-A] SPD Table
图7:[SG-A]SPD表
The analysis from Section 3.1 applies as follows:
第3.1节的分析适用如下：
o Communication with [Q] on port 2049 matches SPD entry number 1. This causes [C] to initiate an IKEv2 exchange with [Q]. The PAD entry on [C] causes it to not care what identity [Q] asserts. Further authentication (and channel binding) could occur within the NFSv4 protocol.
o 端口2049上与[Q]的通信与SPD条目号1匹配。这导致[C]启动与[Q]的IKEv2交换。[C]上的PAD条目导致它不关心标识[Q]断言的内容。进一步的身份验证（和通道绑定）可能发生在NFSv4协议中。
o Communication with [A], [B], or any other internet machine (including [Q]), occurs in the clear, so long as it is not on port 2049.
o 与[A]、[B]或任何其他互联网机器（包括[Q]）的通信发生在clear中，只要它不在端口2049上。
o All analysis about rogue BTNS nodes applies, but they can only assert SAs for port 2049.
o 所有关于恶意BTN节点的分析都适用，但它们只能断言端口2049的SAs。
If [SG-A] were not BTNS capable, then it would not have PAD and SPD entries #3 and #4, respectively, in example #1. Then [C] would be rejected as usual under the standard IPsec model [RFC4301].
如果[SG-A]不支持BTN，则在示例1中，它将分别没有PAD和SPD条目#3和#4。然后，在标准IPsec模型[RFC4301]下，将一如既往地拒绝[C]。
Similarly, if [Q] were not BTNS capable, then it would not have PAD and SPD entries #2 in example #2. Then [C] would be rejected as usual under the standard IPsec model [RFC4301].
类似地，如果[Q]不支持BTN，那么它就不会有PAD和SPD条目（在示例2中为2）。然后，在标准IPsec模型[RFC4301]下，将一如既往地拒绝[C]。
Unauthenticated security association negotiation is subject to man-in-the-middle (MITM) attacks and should be used with care. Where security infrastructures are lacking, this may indeed be better than nothing.
未经验证的安全关联协商会受到中间人（MITM）攻击，应谨慎使用。在缺乏安全基础设施的地方，这可能确实比什么都没有要好。
Use with applications that bind authentication at higher network layers to secure channels at lower layers may provide one secure way to use unauthenticated IPsec, but this is not specified herein.
与将较高网络层的身份验证绑定到较低层的安全通道的应用程序一起使用可能会提供一种使用未经身份验证的IPsec的安全方法，但本文未对此进行规定。
The BTNS PAD entry must be last and its child SA ID constraints must be non-overlapping with any other PAD entry, as described in Section 2. This will ensure that no BTNS peer can impersonate another IPsec non-BTNS peer.
BTNS PAD条目必须是最后一个条目，其子SA ID约束必须与任何其他PAD条目不重叠，如第2节所述。这将确保没有BTNS对等方可以模拟另一个IPsec非BTNS对等方。
BTNS is subject to MITM attacks. One way to protect against MITM attacks subsequent to initial communications is to use "connection latching" [ConnLatch]. In connection latching, upper layer protocols (ULPs) cooperate with IPsec to bind discrete packet flows to
BTN受到MITM攻击。防止初始通信后的MITM攻击的一种方法是使用“连接锁存”[ConnLatch]。在连接锁存中，上层协议（ULP）与IPsec合作，将离散数据包流绑定到
sequences of similar SAs. Connection latching requires native IPsec implementations.
相似SAs的序列。连接锁存需要本机IPsec实现。
MITMs can be detected by using application-layer authentication frameworks and/or mechanisms, such as the GSS-API [RFC2743], with channel binding [RFC5056]. IPsec "channels" are nothing other than latched connections.
可以通过使用应用层身份验证框架和/或机制（如GSS-API[RFC2743]和通道绑定[RFC5056]）来检测MITM。IPsec“通道”只是锁定连接。
"Leap of faith" is the term generally used when a user accepts the assertion that a given key identifies a peer on the first communication (despite a lack of strong evidence for that assertion), and then remembers this association for future communications. Specifically this is a common mode of operation for Secure Shell [RFC4251] clients. When a server is encountered for the first time, the Secure Shell client may ask the user whether to accept the server's public key. If so, the client records the server's name (as given by the user) and public key in a database.
“信念的飞跃”是一个术语，通常用于用户接受一个断言，即给定的密钥在第一次通信中标识了一个对等方（尽管该断言缺乏有力的证据），然后记住该关联以用于将来的通信。具体而言，这是Secure Shell[RFC4251]客户端的常见操作模式。当第一次遇到服务器时，Secure Shell客户端可能会询问用户是否接受服务器的公钥。如果是这样，客户机会在数据库中记录服务器的名称（由用户提供）和公钥。
Leap of faith can work in a similar way for BTNS nodes, but it is currently still being designed and specified by the IETF BTNS WG.
Leap of faith可以以类似的方式为BTN节点工作，但目前仍由IETF BTN工作组设计和指定。
Thanks to the following reviewer: Stephen Kent.
感谢以下评论员：斯蒂芬·肯特。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[ConnLatch] Williams, N., "IPsec Channels: Connection Latching", Work in Progress, April 2008.
[ConnLatch]Williams，N.，“IPsec通道：连接锁存”，正在进行的工作，2008年4月。
[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月。
[RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[RFC2408]Maughan，D.，Schneider，M.和M.Schertler，“互联网安全协会和密钥管理协议（ISAKMP）”，RFC 2408，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月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743]Linn，J.，“通用安全服务应用程序接口版本2，更新1”，RFC 2743，2000年1月。
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4251]Ylonen，T.和C.Lonvick，“安全外壳（SSH）协议架构”，RFC 4251，2006年1月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年12月。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
[RFC5056]Williams，N.，“关于使用通道绑定保护通道”，RFC 5056，2007年11月。
[RFC5387] Touch, J., Black, D., and Y. Wang, "Problem and Applicability Statement for Better-Than-Nothing Security (BTNS)", RFC 5387, November 2008.
[RFC5387]Touch，J.，Black，D.，和Y.Wang，“比没有更好的安全性（BTNS）的问题和适用性声明”，RFC 5387，2008年11月。
Authors' Addresses
作者地址
Nicolas Williams Sun Microsystems 5300 Riata Trace Ct Austin, TX 78727 US
Nicolas Williams Sun Microsystems 5300 Riata Trace Ct德克萨斯州奥斯汀78727美国
EMail: Nicolas.Williams@sun.com
EMail: Nicolas.Williams@sun.com
Michael C. Richardson Sandelman Software Works 470 Dawson Avenue Ottawa, ON K1Z 5V7 CA
Michael C.Richardson Sandelman软件公司位于加利福尼亚州K1Z 5V7的渥太华道森大道470号
EMail: mcr@sandelman.ottawa.on.ca
URI: http://www.sandelman.ottawa.on.ca/
EMail: mcr@sandelman.ottawa.on.ca
URI: http://www.sandelman.ottawa.on.ca/