Network Working Group M. Richardson
Request for Comments: 4025 SSW
Category: Standards Track February 2005
Network Working Group M. Richardson
Request for Comments: 4025 SSW
Category: Standards Track February 2005
A Method for Storing IPsec Keying Material in DNS
一种在DNS中存储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) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document describes a new resource record for the Domain Name System (DNS). This record may be used to store public keys for use in IP security (IPsec) systems. The record also includes provisions for indicating what system should be contacted when an IPsec tunnel is established with the entity in question.
本文档描述了域名系统（DNS）的新资源记录。此记录可用于存储在IP安全（IPsec）系统中使用的公钥。该记录还包括指示在与相关实体建立IPsec隧道时应联系的系统的规定。
This record replaces the functionality of the sub-type #4 of the KEY Resource Record, which has been obsoleted by RFC 3445.
该记录取代了关键资源记录的子类型#4的功能，该记录已被RFC 3445淘汰。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Use of DNS Address-to-Name Maps (IN-ADDR.ARPA and
IP6.ARPA) . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Usage Criteria . . . . . . . . . . . . . . . . . . . . . 3
2. Storage Formats . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. IPSECKEY RDATA Format . . . . . . . . . . . . . . . . . 3
2.2. RDATA Format - Precedence . . . . . . . . . . . . . . . 4
2.3. RDATA Format - Gateway Type . . . . . . . . . . . . . . 4
2.4. RDATA Format - Algorithm Type . . . . . . . . . . . . . 4
2.5. RDATA Format - Gateway . . . . . . . . . . . . . . . . . 5
2.6. RDATA Format - Public Keys . . . . . . . . . . . . . . . 5
3. Presentation Formats . . . . . . . . . . . . . . . . . . . . . 6
3.1. Representation of IPSECKEY RRs . . . . . . . . . . . . . 6
3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Use of DNS Address-to-Name Maps (IN-ADDR.ARPA and
IP6.ARPA) . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Usage Criteria . . . . . . . . . . . . . . . . . . . . . 3
2. Storage Formats . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. IPSECKEY RDATA Format . . . . . . . . . . . . . . . . . 3
2.2. RDATA Format - Precedence . . . . . . . . . . . . . . . 4
2.3. RDATA Format - Gateway Type . . . . . . . . . . . . . . 4
2.4. RDATA Format - Algorithm Type . . . . . . . . . . . . . 4
2.5. RDATA Format - Gateway . . . . . . . . . . . . . . . . . 5
2.6. RDATA Format - Public Keys . . . . . . . . . . . . . . . 5
3. Presentation Formats . . . . . . . . . . . . . . . . . . . . . 6
3.1. Representation of IPSECKEY RRs . . . . . . . . . . . . . 6
3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
4.1. Active Attacks Against Unsecured IPSECKEY Resource
Records . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Active Attacks Against IPSECKEY Keying
Materials. . . . . . . . . . . . . . . . . . . . 8
4.1.2. Active Attacks Against IPSECKEY Gateway
Material. . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 12
4.1. Active Attacks Against Unsecured IPSECKEY Resource
Records . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Active Attacks Against IPSECKEY Keying
Materials. . . . . . . . . . . . . . . . . . . . 8
4.1.2. Active Attacks Against IPSECKEY Gateway
Material. . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 12
Suppose a host wishes (or is required by policy) to establish an IPsec tunnel with some remote entity on the network prior to allowing normal communication to take place. In many cases, this end system will be able to determine the DNS name for the remote entity (either by having the DNS name given explicitly, by performing a DNS PTR query for a particular IP address, or through some other means, e.g., by extracting the DNS portion of a "user@FQDN" name for a remote entity). In these cases, the host will need to obtain a public key to authenticate the remote entity, and may also need some guidance about whether it should contact the entity directly or use another node as a gateway to the target entity. The IPSECKEY RR provides a mechanism for storing such information.
假设主机希望（或策略要求）在允许正常通信发生之前，与网络上的某个远程实体建立IPsec隧道。在许多情况下，该终端系统将能够确定远程实体的DNS名称（通过明确给出DNS名称，通过对特定IP地址执行DNS PTR查询，或通过一些其他方式，例如通过提取user@FQDN“远程实体的名称）。在这些情况下，主机将需要获得公钥来认证远程实体，并且可能还需要一些关于它应该直接联系实体还是使用另一个节点作为到目标实体的网关的指导。IPSECKEY RR提供了一种存储此类信息的机制。
The type number for the IPSECKEY RR is 45.
IPSECKEY RR的类型号为45。
This record replaces the functionality of the sub-type #4 of the KEY Resource Record, which has been obsoleted by RFC 3445 [11].
该记录取代了关键资源记录的子类型#4的功能，该记录已被RFC 3445淘汰[11]。
The IPSECKEY resource record (RR) is used to publish a public key that is to be associated with a Domain Name System (DNS) [1] name for use with the IPsec protocol suite. This can be the public key of a host, network, or application (in the case of per-port keying).
IPSECKEY资源记录（RR）用于发布与域名系统（DNS）[1]名称关联的公钥，以用于IPsec协议套件。这可以是主机、网络或应用程序的公钥（对于每端口密钥）。
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 RFC 2119 [3].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[3]中所述进行解释。
Often a security gateway will only have access to the IP address of the node with which communication is desired and will not know any other name for the target node. Because of this, frequently the best way of looking up IPSECKEY RRs will be by using the IP address as an index into one of the reverse mapping trees (IN-ADDR.ARPA for IPv4 or IP6.ARPA for IPv6).
通常，安全网关只能访问需要通信的节点的IP地址，而不知道目标节点的任何其他名称。因此，查找IPSECKEY RRs的最佳方法通常是使用IP地址作为反向映射树之一的索引（IPv4为IN-ADDR.ARPA，IPv6为IP6.ARPA）。
The lookup is done in the fashion usual for PTR records. The IP address' octets (IPv4) or nibbles (IPv6) are reversed and looked up with the appropriate suffix. Any CNAMEs or DNAMEs found MUST be followed.
查找是以PTR记录通常的方式完成的。IP地址的八位字节（IPv4）或半字节（IPv6）是反向的，并使用适当的后缀进行查找。必须遵守发现的任何CNAMEs或DNAMEs。
Note: even when the IPsec function is contained in the end-host, often only the application will know the forward name used. Although the case where the application knows the forward name is common, the user could easily have typed in a literal IP address. This storage mechanism does not preclude using the forward name when it is available but does not require it.
注意：即使IPsec功能包含在终端主机中，通常只有应用程序才知道所使用的转发名称。虽然应用程序知道转发名称的情况很常见，但用户可以很容易地键入一个文本IP地址。此存储机制不排除在转发名称可用但不需要时使用转发名称。
An IPSECKEY resource record SHOULD be used in combination with DNSSEC [8] unless some other means of authenticating the IPSECKEY resource record is available.
IPSECKEY资源记录应与DNSSEC[8]结合使用，除非有其他方法可以验证IPSECKEY资源记录。
It is expected that there will often be multiple IPSECKEY resource records at the same name. This will be due to the presence of multiple gateways and a need to roll over keys.
预计通常会有多个同名的IPSECKEY资源记录。这将是由于存在多个网关以及需要翻滚密钥。
This resource record is class independent.
此资源记录与类无关。
The RDATA for an IPSECKEY RR consists of a precedence value, a gateway type, a public key, algorithm type, and an optional gateway address.
IPSECKEY RR的RDATA由优先级值、网关类型、公钥、算法类型和可选网关地址组成。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| precedence | gateway type | algorithm | gateway |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ +
~ gateway ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ public key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| precedence | gateway type | algorithm | gateway |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ +
~ gateway ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ public key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
This is an 8-bit precedence for this record. It is interpreted in the same way as the PREFERENCE field described in section 3.3.9 of RFC 1035 [2].
这是此记录的8位优先级。其解释方式与RFC 1035[2]第3.3.9节中描述的首选字段相同。
Gateways listed in IPSECKEY records with lower precedence are to be attempted first. Where there is a tie in precedence, the order should be non-deterministic.
首先尝试IPSECKEY记录中列出的优先级较低的网关。如果优先顺序是并列的，则顺序应该是不确定的。
The gateway type field indicates the format of the information that is stored in the gateway field.
网关类型字段指示存储在网关字段中的信息格式。
The following values are defined: 0 No gateway is present. 1 A 4-byte IPv4 address is present. 2 A 16-byte IPv6 address is present. 3 A wire-encoded domain name is present. The wire-encoded format is self-describing, so the length is implicit. The domain name MUST NOT be compressed. (See Section 3.3 of RFC 1035 [2].)
定义了以下值：0不存在网关。1存在一个4字节的IPv4地址。2存在一个16字节的IPv6地址。3存在有线编码的域名。导线编码格式是自描述的，因此长度是隐式的。不得压缩域名。（见RFC 1035[2]第3.3节）
The algorithm type field identifies the public key's cryptographic algorithm and determines the format of the public key field.
算法类型字段标识公钥的加密算法，并确定公钥字段的格式。
A value of 0 indicates that no key is present.
值为0表示不存在任何键。
The following values are defined: 1 A DSA key is present, in the format defined in RFC 2536 [9]. 2 A RSA key is present, in the format defined in RFC 3110 [10].
定义了以下值：1以RFC 2536[9]中定义的格式存在DSA密钥。2 RSA密钥以RFC 3110[10]中定义的格式存在。
The gateway field indicates a gateway to which an IPsec tunnel may be created in order to reach the entity named by this resource record.
gateway字段表示可以创建IPsec隧道以到达此资源记录命名的实体的网关。
There are three formats:
有三种格式：
A 32-bit IPv4 address is present in the gateway field. The data portion is an IPv4 address as described in section 3.4.1 of RFC 1035 [2]. This is a 32-bit number in network byte order.
网关字段中存在32位IPv4地址。数据部分是RFC 1035[2]第3.4.1节所述的IPv4地址。这是一个网络字节顺序的32位数字。
A 128-bit IPv6 address is present in the gateway field. The data portion is an IPv6 address as described in section 2.2 of RFC 3596 [12]. This is a 128-bit number in network byte order.
网关字段中存在128位IPv6地址。数据部分是RFC 3596[12]第2.2节所述的IPv6地址。这是网络字节顺序的128位数字。
The gateway field is a normal wire-encoded domain name, as described in section 3.3 of RFC 1035 [2]. Compression MUST NOT be used.
网关字段是一个普通的有线编码域名，如RFC 1035[2]第3.3节所述。不得使用压缩。
Both the public key types defined in this document (RSA and DSA) inherit their public key formats from the corresponding KEY RR formats. Specifically, the public key field contains the algorithm-specific portion of the KEY RR RDATA, which is all the KEY RR DATA after the first four octets. This is the same portion of the KEY RR that must be specified by documents that define a DNSSEC algorithm. Those documents also specify a message digest to be used for generation of SIG RRs; that specification is not relevant for IPSECKEY RRs.
本文档中定义的公钥类型（RSA和DSA）都从相应的密钥RR格式继承其公钥格式。具体地说，公钥字段包含key RR RDATA的算法特定部分，它是前四个八位组之后的所有key RR数据。这是密钥RR的相同部分，必须由定义DNSSEC算法的文档指定。这些文件还规定了用于生成SIG RRs的消息摘要；该规范与IPSECKEY RRs无关。
Future algorithms, if they are to be used by both DNSSEC (in the KEY RR) and IPSECKEY, are likely to use the same public key encodings in both records. Unless otherwise specified, the IPSECKEY public key field will contain the algorithm-specific portion of the KEY RR RDATA for the corresponding algorithm. The algorithm must still be designated for use by IPSECKEY, and an IPSECKEY algorithm type number (which might be different from the DNSSEC algorithm number) must be assigned to it.
如果DNSSEC（在密钥RR中）和IPSECKEY都使用未来的算法，则它们可能在两个记录中使用相同的公钥编码。除非另有规定，IPSECKEY公钥字段将包含相应算法的密钥RR RDATA的算法特定部分。算法仍必须指定由IPSECKEY使用，并且必须为其分配IPSECKEY算法类型编号（可能不同于DNSSEC算法编号）。
The DSA key format is defined in RFC 2536 [9]
DSA密钥格式在RFC 2536[9]中定义
The RSA key format is defined in RFC 3110 [10], with the following changes:
RSA密钥格式在RFC 3110[10]中定义，但有以下更改：
The earlier definition of RSA/MD5 in RFC 2065 [4] limited the exponent and modulus to 2552 bits in length. RFC 3110 extended that limit to 4096 bits for RSA/SHA1 keys. The IPSECKEY RR imposes no length limit on RSA public keys, other than the 65535 octet limit
RFC 2065[4]中RSA/MD5的早期定义将指数和模的长度限制为2552位。RFC3110将RSA/SHA1密钥的限制扩展到4096位。IPSECKEY RR对RSA公钥没有长度限制，只有65535八位字节限制
imposed by the two-octet length encoding. This length extension is applicable only to IPSECKEY; it is not applicable to KEY RRs.
由两个八位组长度编码施加。此长度扩展仅适用于IPSECKEY；它不适用于关键RRs。
IPSECKEY RRs may appear in a zone data master file. The precedence, gateway type, algorithm, and gateway fields are REQUIRED. The base64 encoded public key block is OPTIONAL; if it is not present, the public key field of the resource record MUST be construed to be zero octets in length.
IPSECKEY RRs可能出现在区域数据主文件中。优先级、网关类型、算法和网关字段是必需的。base64编码公钥块是可选的；如果不存在，则必须将资源记录的公钥字段解释为长度为零个八位字节。
The algorithm field is an unsigned integer. No mnemonics are defined.
“算法”字段是无符号整数。没有定义助记符。
If no gateway is to be indicated, then the gateway type field MUST be zero, and the gateway field MUST be "."
如果未指示网关，则网关类型字段必须为零，网关字段必须为“”
The Public Key field is represented as a Base64 encoding of the Public Key. Whitespace is allowed within the Base64 text. For a definition of Base64 encoding, see RFC 3548 [6], Section 5.2.
公钥字段表示为公钥的Base64编码。Base64文本中允许空白。有关Base64编码的定义，请参见RFC 3548[6]，第5.2节。
The general presentation for the record is as follows:
记录的一般介绍如下：
IN IPSECKEY ( precedence gateway-type algorithm gateway base64-encoded-public-key )
在IPSECKEY中（优先网关类型算法网关base64编码公钥）
An example of a node, 192.0.2.38, that will accept IPsec tunnels on its own behalf.
节点192.0.2.38的一个示例，它将代表自己接受IPsec隧道。
38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 192.0.2.38 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
38.2.0.192.in-addr.arpa。IPSECKEY中的7200（10 1 2 192.0.2.38 AQNRU3MG7TVTO 2BKR47USNTB102UFJTUGBO6BSGVGQT4AQ==）
An example of a node, 192.0.2.38, that has published its key only.
节点192.0.2.38的示例，该节点仅发布了其密钥。
38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 0 2 . AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
38.2.0.192.in-addr.arpa。IPSECKEY中的7200（10 0 2.AQNRU3MG7TVTO 2BKR47USNTB102UFJTUGBO6BSGVGQT4AQ==）
An example of a node, 192.0.2.38, that has delegated authority to the node 192.0.2.3.
节点192.0.2.38的示例，该节点已将权限委托给节点192.0.2.3。
38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 192.0.2.3 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
38.2.0.192.in-addr.arpa。IPSECKEY中的7200（10 1 2 192.0.2.3 AQNRU3MG7TVTO 2BKR47USNTB102UFJTUGBO6BSGVGQT4AQ==）
An example of a node, 192.0.1.38 that has delegated authority to the node with the identity "mygateway.example.com".
节点192.0.1.38的一个示例，该节点已将权限委托给标识为“mygateway.example.com”的节点。
38.1.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 3 2 mygateway.example.com. AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
38.1.0.192.in-addr.arpa。IPSECKEY中的7200（10 3 2 mygateway.example.com.aqnru3mg7tvto2bkr47usntb102ufjtugbo6bsgggqt4aq==）
An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0, that has
delegated authority to the node 2001:0DB8:c000:0200:2::1
An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0, that has
delegated authority to the node 2001:0DB8:c000:0200:2::1
$ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.arpa.
0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN IPSECKEY ( 10 2 2
2001:0DB8:0:8002::2000:1
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
$ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.arpa.
0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN IPSECKEY ( 10 2 2
2001:0DB8:0:8002::2000:1
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
This entire memo pertains to the provision of public keying material for use by key management protocols such as ISAKMP/IKE (RFC 2407) [7].
整个备忘录与密钥管理协议（如ISAKMP/IKE（RFC 2407）[7]使用的公钥材料的提供有关。
The IPSECKEY resource record contains information that SHOULD be communicated to the end client in an integral fashion; i.e., free from modification. The form of this channel is up to the consumer of the data; there must be a trust relationship between the end consumer of this resource record and the server. This relationship may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to another secure source, a secure local channel on the host, or some combination of the above.
IPSECKEY资源记录包含应以整体方式传达给终端客户的信息；i、 无需修改。该通道的形式取决于数据的消费者；此资源记录的最终使用者与服务器之间必须存在信任关系。此关系可以是端到端DNSSEC验证、到另一个安全源的TSIG或SIG（0）通道、主机上的安全本地通道，或上述的一些组合。
The keying material provided by the IPSECKEY resource record is not sensitive to passive attacks. The keying material may be freely disclosed to any party without any impact on the security properties of the resulting IPsec session. IPsec and IKE provide defense against both active and passive attacks.
IPSECKEY资源记录提供的密钥材料对被动攻击不敏感。密钥材料可以自由地披露给任何一方，而不会对产生的IPsec会话的安全属性产生任何影响。IPsec和IKE提供了对主动和被动攻击的防御。
Any derivative specification that makes use of this resource record MUST carefully document its trust model and why the trust model of DNSSEC is appropriate, if that is the secure channel used.
使用此资源记录的任何衍生规范都必须仔细记录其信任模型，以及DNSSEC的信任模型适用的原因（如果使用的是安全通道）。
An active attack on the DNS that caused the wrong IP address to be retrieved (via forged address), and therefore the wrong QNAME to be queried, would also result in a man-in-the-middle attack. This situation is independent of whether the IPSECKEY RR is used.
对DNS的主动攻击导致检索错误的IP地址（通过伪造地址），从而查询错误的QNAME，也会导致中间人攻击。这种情况与是否使用IPSECKEY RR无关。
This section deals with active attacks against the DNS. These attacks require that DNS requests and responses be intercepted and changed. DNSSEC is designed to defend against attacks of this kind. This section deals with the situation in which DNSSEC is not available. This is not the recommended deployment scenario.
本节介绍针对DNS的主动攻击。这些攻击要求拦截和更改DNS请求和响应。DNSSEC旨在防御此类攻击。本节讨论DNSSEC不可用的情况。这不是推荐的部署方案。
The first kind of active attack is when the attacker replaces the keying material with either a key under its control or with garbage.
第一种主动攻击是攻击者用其控制的密钥或垃圾替换密钥材料。
The gateway field is either untouched or is null. The IKE negotiation will therefore occur with the original end-system. For this attack to succeed, the attacker must perform a man-in-the-middle attack on the IKE negotiation. This attack requires that the attacker be able to intercept and modify packets on the forwarding path for the IKE and data packets.
网关字段未触及或为空。因此，IKE协商将与原始终端系统进行。要使此攻击成功，攻击者必须对IKE协商执行中间人攻击。此攻击要求攻击者能够拦截和修改IKE和数据包转发路径上的数据包。
If the attacker is not able to perform this man-in-the-middle attack on the IKE negotiation, then a denial of service will result, as the IKE negotiation will fail.
如果攻击者无法对IKE协商执行中间人攻击，则会导致拒绝服务，因为IKE协商将失败。
If the attacker is not only able to mount active attacks against DNS but also in a position to perform a man-in-the-middle attack on IKE and IPsec negotiations, then the attacker will be able to compromise the resulting IPsec channel. Note that an attacker must be able to perform active DNS attacks on both sides of the IKE negotiation for this to succeed.
如果攻击者不仅能够对DNS发起主动攻击，而且能够对IKE和IPsec协商执行中间人攻击，则攻击者将能够破坏生成的IPsec通道。请注意，攻击者必须能够在IKE协商的两侧执行主动DNS攻击才能成功。
The second kind of active attack is one in which the attacker replaces the gateway address to point to a node under the attacker's control. The attacker then either replaces the public key or removes it. If the public key were removed, then the attacker could provide an accurate public key of its own in a second record.
第二种主动攻击是攻击者替换网关地址以指向攻击者控制下的节点的攻击。然后，攻击者替换或删除公钥。如果删除了公钥，则攻击者可以在第二条记录中提供自己的准确公钥。
This second form creates a simple man-in-the-middle attacks since the attacker can then create a second tunnel to the real destination. Note that, as before, this requires that the attacker also mount an active attack against the responder.
第二种形式创建了一个简单的中间人攻击，因为攻击者随后可以创建第二条通往真正目的地的隧道。请注意，与前面一样，这要求攻击者也对响应者发起主动攻击。
Note that the man-in-the-middle cannot just forward cleartext packets to the original destination. While the destination may be willing to speak in the clear, replying to the original sender, the sender will already have created a policy expecting ciphertext. Thus, the attacker will need to intercept traffic in both directions. In some cases, the attacker may be able to accomplish the full intercept by use of Network Address/Port Translation (NAT/NAPT) technology.
请注意，中间的人不能只将明文包转发到原始目的地。虽然目的地可能愿意清楚地回答原始发件人，但发件人已经创建了一个需要密文的策略。因此，攻击者需要拦截两个方向的流量。在某些情况下，攻击者可以通过使用网络地址/端口转换（NAT/NAPT）技术完成完全拦截。
This attack is easier than the first one because the attacker does NOT need to be on the end-to-end forwarding path. The attacker need only be able to modify DNS replies. This can be done by packet modification, by various kinds of race attacks, or through methods that pollute DNS caches.
此攻击比第一次更容易，因为攻击者不需要位于端到端转发路径上。攻击者只需能够修改DNS回复。这可以通过数据包修改、各种竞争攻击或污染DNS缓存的方法来实现。
If the end-to-end integrity of the IPSECKEY RR is suspect, the end client MUST restrict its use of the IPSECKEY RR to cases where the RR owner name matches the content of the gateway field. As the RR owner name is assumed when the gateway field is null, a null gateway field is considered a match.
如果怀疑IPSECKEY RR的端到端完整性，则终端客户端必须将其对IPSECKEY RR的使用限制在RR所有者名称与网关字段内容匹配的情况下。当网关字段为空时，假定RR所有者名称，因此空网关字段被视为匹配项。
Thus, any records obtained under unverified conditions (e.g., no DNSSEC or trusted path to source) that have a non-null gateway field MUST be ignored.
因此，必须忽略在未经验证的条件下（例如，没有DNSSEC或到源的可信路径）获得的具有非空网关字段的任何记录。
This restriction eliminates attacks against the gateway field, which are considered much easier, as the attack does not need to be on the forwarding path.
此限制消除了对网关字段的攻击，因为攻击不需要位于转发路径上，因此认为这更容易。
In the case of an IPSECKEY RR with a value of three in its gateway type field, the gateway field contains a domain name. The subsequent query required to translate that name into an IP address or IPSECKEY RR will also be subject to man-in-the-middle attacks. If the end-to-end integrity of this second query is suspect, then the provisions above also apply. The IPSECKEY RR MUST be ignored whenever the resulting gateway does not match the QNAME of the original IPSECKEY RR query.
对于网关类型字段中值为3的IPSECKEY RR，网关字段包含域名。将该名称转换为IP地址或IPSECKEY RR所需的后续查询也将受到中间人攻击。如果怀疑第二个查询的端到端完整性，则上述规定也适用。只要生成的网关与原始IPSECKEY RR查询的QNAME不匹配，就必须忽略IPSECKEY RR。
This document updates the IANA Registry for DNS Resource Record Types by assigning type 45 to the IPSECKEY record.
本文档通过将类型45分配给IPSECKEY记录来更新DNS资源记录类型的IANA注册表。
This document creates two new IANA registries, both specific to the IPSECKEY Resource Record:
本文档创建了两个新的IANA注册表，这两个注册表都特定于IPSECKEY资源记录：
This document creates an IANA registry for the algorithm type field.
本文档为算法类型字段创建IANA注册表。
Values 0, 1, and 2 are defined in Section 2.4. Algorithm numbers 3 through 255 can be assigned by IETF Consensus (see RFC 2434 [5]).
第2.4节定义了值0、1和2。算法编号3到255可由IETF协商一致分配（见RFC 2434[5]）。
This document creates an IANA registry for the gateway type field.
本文档为网关类型字段创建IANA注册表。
Values 0, 1, 2, and 3 are defined in Section 2.3. Gateway type numbers 4 through 255 can be assigned by Standards Action (see RFC 2434 [5]).
第2.3节定义了值0、1、2和3。网关类型编号4至255可通过标准行动进行分配（见RFC 2434[5]）。
My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob Austein, and Olafur Gudmundsson, who reviewed this document carefully. Additional thanks to Olafur Gurmundsson for a reference implementation.
我要感谢保罗·霍夫曼、萨姆·韦勒、让·雅克·普伊格、罗伯·奥斯汀和奥拉弗尔·古德蒙德森，他们仔细审阅了这份文件。还要感谢Olafur Gurmundsson提供的参考实现。
[1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[1] Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[2] Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Eastlake 3rd, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997.
[4] Eastlake 3rd，D.和C.Kaufman，“域名系统安全扩展”，RFC 20651997年1月。
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003.
[6] Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC3548，2003年7月。
[7] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[7] Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[8] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[8] Eastlake 3rd，D.，“域名系统安全扩展”，RFC 25351999年3月。
[9] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, March 1999.
[9] Eastlake 3rd，D.，“域名系统（DNS）中的DSA密钥和SIG”，RFC 25361999年3月。
[10] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, May 2001.
[10] Eastlake 3rd，D.，“域名系统（DNS）中的RSA/SHA-1 SIGs和RSA密钥”，RFC 3110，2001年5月。
[11] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource Record (RR)", RFC 3445, December 2002.
[11] Massey，D.和S.Rose，“限制关键资源记录（RR）的范围”，RFC 34452002年12月。
[12] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[12] Thomson，S.，Huitema，C.，Ksinant，V.，和M.Souissi，“支持IP版本6的DNS扩展”，RFC 3596，2003年10月。
Author's Address
作者地址
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/
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。