Network Working Group T. Henderson
Request for Comments: 5338 The Boeing Company
Category: Informational P. Nikander
Ericsson Research NomadicLab
M. Komu
Helsinki Institute for Information Technology
September 2008
Network Working Group T. Henderson
Request for Comments: 5338 The Boeing Company
Category: Informational P. Nikander
Ericsson Research NomadicLab
M. Komu
Helsinki Institute for Information Technology
September 2008
Using the Host Identity Protocol with Legacy Applications
对遗留应用程序使用主机标识协议
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.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
This document is an informative overview of how legacy applications can be made to work with the Host Identity Protocol (HIP). HIP proposes to add a cryptographic name space for network stack names. From an application viewpoint, HIP-enabled systems support a new address family of host identifiers, but it may be a long time until such HIP-aware applications are widely deployed even if host systems are upgraded. This informational document discusses implementation and Application Programming Interface (API) issues relating to using HIP in situations in which the system is HIP-aware but the applications are not, and is intended to aid implementors and early adopters in thinking about and locally solving systems issues regarding the incremental deployment of HIP.
本文档是关于如何使遗留应用程序与主机标识协议（HIP）配合使用的信息性概述。HIP建议为网络堆栈名称添加加密名称空间。从应用程序的角度来看，支持HIP的系统支持主机标识符的新地址系列，但即使主机系统升级，也可能需要很长时间才能广泛部署此类支持HIP的应用程序。本信息性文档讨论了与在系统具有HIP意识但应用程序不具备HIP意识的情况下使用HIP相关的实施和应用程序编程接口（API）问题，并旨在帮助实施者和早期采用者思考和本地解决与HIP增量部署相关的系统问题。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Enabling HIP Transparently within the System ....................4
3.1. Applying HIP to Cases in Which IP Addresses Are Used .......4
3.2. Interposing a HIP-Aware Agent in the DNS Resolution ........6
3.3. Discussion .................................................7
4. Users Invoking HIP with a Legacy Application ....................8
4.1. Connecting to a HIT or LSI .................................8
4.2. Using a Modified DNS Name ..................................9
4.3. Other Techniques ...........................................9
5. Local Address Management ........................................9
6. Security Considerations ........................................11
7. Acknowledgments ................................................12
8. Informative References .........................................12
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Enabling HIP Transparently within the System ....................4
3.1. Applying HIP to Cases in Which IP Addresses Are Used .......4
3.2. Interposing a HIP-Aware Agent in the DNS Resolution ........6
3.3. Discussion .................................................7
4. Users Invoking HIP with a Legacy Application ....................8
4.1. Connecting to a HIT or LSI .................................8
4.2. Using a Modified DNS Name ..................................9
4.3. Other Techniques ...........................................9
5. Local Address Management ........................................9
6. Security Considerations ........................................11
7. Acknowledgments ................................................12
8. Informative References .........................................12
The Host Identity Protocol (HIP) [RFC5201] is an experimental effort in the IETF and IRTF to study a new public-key-based name space for use as host identifiers in Internet protocols. Fully deployed, the HIP architecture would permit applications and users to explicitly request the system to send packets to another host by expressing a location-independent unique name of a peer host when the system call to connect or send packets is performed. However, there will be a transition period during which systems become HIP-enabled but applications are not. This informational document does not propose normative specification or even suggest that different HIP implementations use more uniform methods for legacy application support, but is intended instead to aid implementors and early adopters in thinking about and solving systems issues regarding the incremental deployment of HIP.
主机标识协议（HIP）[RFC5201]是IETF和IRTF中的一项实验性工作，旨在研究一种新的基于公钥的名称空间，用作Internet协议中的主机标识符。完全部署的HIP体系结构允许应用程序和用户在执行连接或发送数据包的系统调用时，通过表示对等主机的位置独立唯一名称，明确请求系统向另一主机发送数据包。但是，将有一个过渡期，在此期间，系统将启用HIP，但应用程序不会启用。本信息性文档未提出规范性规范，甚至未建议不同的HIP实施使用更统一的方法来支持遗留应用程序，而是旨在帮助实施者和早期采用者思考和解决与HIP增量部署相关的系统问题。
When applications and systems are both HIP-aware, the coordination between the application and the system can be straightforward. For example, using the terminology of the widely used sockets Application Programming Interface (API), the application can issue a system call to send packets to another host by naming it explicitly, and the system can perform the necessary name-to-address mapping to assign appropriate routable addresses to the packets. To enable this, a new address family for hosts could be defined, and additional API extensions could be defined (such as allowing IP addresses to be passed in the system call, along with the host name, as hints of where to initially try to reach the host).
当应用程序和系统都是HIP感知的时，应用程序和系统之间的协调可以很简单。例如，使用广泛使用的sockets应用程序编程接口（API）的术语，应用程序可以发出系统调用，通过显式命名将数据包发送到另一台主机，并且系统可以执行必要的名称到地址映射，以便为数据包分配适当的可路由地址。为了实现这一点，可以为主机定义一个新的地址族，并定义额外的API扩展（例如允许在系统调用中传递IP地址以及主机名，作为初始尝试到达主机的位置的提示）。
This document does not define a native HIP API such as described above. Rather, this document is concerned with the scenario in which the application is not HIP-aware and a traditional IP-address-based API is used by the application.
本文档未定义如上所述的本机HIP API。相反，本文档关注的是应用程序不支持HIP，并且应用程序使用传统的基于IP地址的API的场景。
The discussion so far assumes that applications are written directly to a sockets API. However, many applications are built on top of middleware that exports a higher-level API to the application. In this case, for the purpose of this document, we refer to the combination of the middleware and the middleware-based application as an overall application, or client of the sockets API.
到目前为止的讨论假设应用程序直接写入套接字API。然而，许多应用程序是在中间件之上构建的，中间件向应用程序导出更高级别的API。在本例中，出于本文档的目的，我们将中间件和基于中间件的应用程序的组合称为一个整体应用程序，或socketsapi的客户端。
When HIP is enabled on a system, but the applications are not HIP-aware, there are a few basic possibilities to use HIP, each of which may or may not be supported by a given HIP implementation. We report here on techniques that have been used or considered by experimental HIP implementations. We organize the discussion around the policy chosen to use or expose HIP to the applications. The first option is that users are completely unaware of HIP, or are unable to control whether or not HIP is invoked, but rather the system chooses to enable HIP for some or all sessions based on policy. The second option is that the user makes a decision to try to use HIP by conveying this information somehow within the constraints of the unmodified application. We discuss both of these use cases in detail below.
当在系统上启用HIP，但应用程序不支持HIP时，有几种使用HIP的基本可能性，其中每种可能都由给定的HIP实现支持，也可能不支持。我们在此报告已经被实验性HIP实现使用或考虑的技术。我们围绕选择使用HIP或向应用程序公开HIP的策略组织讨论。第一种选择是，用户完全不知道HIP，或者无法控制是否调用HIP，但是系统选择基于策略为部分或所有会话启用HIP。第二种选择是，用户通过在未修改的应用程序的约束范围内以某种方式传递此信息来决定尝试使用HIP。下面我们将详细讨论这两个用例。
HIP was designed to work with unmodified applications, to ease incremental deployment. For instance, the HIT is the same size as the IPv6 address, and the design thinking was that, during initial experiments and transition periods, the HITs could substitute in data structures where IPv6 addresses were expected. However, to a varying degree depending on the mechanism employed, such use of HIP can alter the semantics of what is considered to be an IP address by applications. Applications use IP addresses as short-lived local handles, long-lived application associations, callbacks, referrals, and identity comparisons [APP-REF]. The transition techniques described below have implications on these different uses of IP addresses by legacy applications, and we will try to clarify these implications in the below discussions.
HIP设计用于处理未修改的应用程序，以简化增量部署。例如，HIT的大小与IPv6地址相同，设计思路是，在初始实验和过渡期，HIT可以替代预期IPv6地址的数据结构。然而，根据所采用的机制，HIP的这种使用在不同程度上可以改变应用程序认为是IP地址的语义。应用程序使用IP地址作为短期本地句柄、长期应用程序关联、回调、引用和身份比较[APP-REF]。下面描述的转换技术对遗留应用程序对IP地址的不同使用有影响，我们将在下面的讨论中尝试澄清这些影响。
Callback: The application at one end retrieves the IP address of the peer and uses that to later communicate "back" to the peer. An example is the FTP PORT command.
回调：一端的应用程序检索对等方的IP地址，并使用该地址稍后与对等方“返回”通信。FTP端口命令就是一个例子。
Host Identity: An abstract concept applied to a computing platform.
主机标识：应用于计算平台的抽象概念。
Host Identifier (HI): A public key of an asymmetric key pair used as a name for a Host Identity. More details are available in [RFC5201].
主机标识符（HI）：非对称密钥对的公钥，用作主机标识的名称。更多详细信息请参见[RFC5201]。
Host Identity Tag (HIT): A 128-bit quantity composed with the hash of a Host Identity. More details are available in [RFC4843] and [RFC5201].
主机标识标记（HIT）：由主机标识哈希组成的128位数量。更多详细信息请参见[RFC4843]和[RFC5201]。
Local Scope Identifier (LSI): A 32- or 128-bit quantity locally representing the Host Identity at the IPv4 or IPv6 API.
本地作用域标识符（LSI）：本地表示IPv4或IPv6 API上主机标识的32位或128位数量。
Long-lived application associations: The IP address is retained by the application for several instances of communication.
长寿命应用程序关联：IP地址由应用程序保留用于多个通信实例。
Referral: In an application with more than two parties, party B takes the IP address of party A and passes that to party C. After this, party C uses the IP address to communicate with A.
转介：在一个有两方以上的应用程序中，乙方获取甲方的IP地址并将其传递给丙方。此后，丙方使用该IP地址与A进行通信。
Resolver: The system function used by applications to resolve domain names to IP addresses.
解析程序：应用程序用于将域名解析为IP地址的系统功能。
Short-lived local handle: The IP addresses is never retained by the application. The only usage is for the application to pass it from the DNS APIs (e.g., getaddrinfo()) and the API to the protocol stack (e.g., connect() or sendto()).
短期本地句柄：应用程序从不保留IP地址。唯一的用法是应用程序将其从DNS API（例如getaddrinfo（）和API）传递到协议堆栈（例如connect（）或sendto（））。
When both users and applications are unaware of HIP, but the host administrator chooses to use HIP between hosts, a few options are possible. The first basic option is to perform a mapping of the application-provided IP address to a host identifier within the stack. The second option, if DNS is used, is to interpose a local agent in the DNS resolution process and to return to the application a HIT or a locally scoped handle, formatted like an IP address.
当用户和应用程序都不知道HIP，但主机管理员选择在主机之间使用HIP时，有几个选项是可能的。第一个基本选项是将应用程序提供的IP地址映射到堆栈中的主机标识符。如果使用DNS，第二个选项是在DNS解析过程中插入本地代理，并向应用程序返回HIT或本地作用域句柄，格式类似于IP地址。
Consider the case in which an application issues a "connect(ip)" system call to set the default destination to a system named by address "ip", but for which the host administrator would like to enable HIP to protect the communications. The user or application intends for the system to communicate with the host reachable at that IP address. The decision to invoke HIP must be done on the basis of host policy. For example, when an IPsec-based implementation of HIP is being used, a policy may be entered into the security policy database that mandates to use or to try HIP based on a match on the source or destination IP address, port numbers, or other factors.
考虑应用程序发出“连接（IP）”系统调用的情况，将默认目的地设置为由地址“IP”命名的系统，但主机管理员希望启用HIP来保护通信。用户或应用程序希望系统与可在该IP地址访问的主机通信。调用HIP的决定必须基于主机策略。例如，当使用基于IPsec的HIP实现时，可以将策略输入到安全策略数据库中，该安全策略数据库根据源或目标IP地址、端口号或其他因素的匹配要求使用或尝试HIP。
The mapping of IP address to host identifier may be implemented by modifying the host operating system or by wrapping the existing sockets API, such as in the TESLA approach [TESLA].
IP地址到主机标识符的映射可以通过修改主机操作系统或包装现有套接字API来实现，如特斯拉方法[TESLA]。
There are a number of ways that HIP could be configured by the host administrator in such a scenario.
在这种情况下，主机管理员可以通过多种方式配置HIP。
Manual configuration:
手动配置：
Pre-existing Security Associations (SAs) may be available due to previous administrative action, or a binding between an IP address and a HIT could be stored in a configuration file or database.
先前存在的安全关联（SA）可能由于以前的管理操作而可用，或者IP地址和HIT之间的绑定可能存储在配置文件或数据库中。
Opportunistically:
机会主义地：
The system could send an I1 to the Responder with an empty value for Responder HIT.
系统可以向响应者发送I1，其中响应者命中的值为空。
Using DNS to map IP addresses to HIs:
使用DNS将IP地址映射到HIs：
If the Responder has host identifiers registered in the forward DNS zone and has a PTR record in the reverse zone, the Initiator could perform a reverse+forward lookup to learn the HIT associated with the address. Although the approach should work under normal circumstances, it has not been tested to verify that there are no recursion or bootstrapping issues, particularly if HIP is used to secure the connection to the DNS servers. Discussion of the security implications of the use or absence of DNS Security (DNSSEC) is deferred to the Security Considerations section.
如果响应程序在正向DNS区域中注册了主机标识符，并且在反向区域中有PTR记录，则发起程序可以执行反向+正向查找以了解与地址关联的命中。尽管该方法在正常情况下应该可以工作，但尚未对其进行测试以验证是否存在递归或引导问题，特别是在使用HIP保护与DNS服务器的连接时。有关使用或不使用DNS安全性（DNSSEC）的安全影响的讨论将推迟到安全注意事项部分。
Using HIP in the above fashion can cause additional setup delays compared to using plain IP. For opportunistic mode, a host must wait to learn whether the peer is HIP-capable, although the delays may be mitigated in some implementations by sending initial packets (e.g., TCP SYN) in parallel to the HIP I1 packet and waiting some time to receive a HIP R1 before processing a TCP SYN/ACK. Note that there presently does not exist specification for how to invoke such connections in parallel. Resolution latencies may also be incurred when using DNS in the above fashion.
与使用普通IP相比，以上述方式使用HIP可能会导致额外的设置延迟。对于机会主义模式，主机必须等待以了解对等方是否具有HIP能力，尽管在一些实现中可以通过与HIP I1分组并行发送初始分组（例如，TCP SYN）并在处理TCP SYN/ACK之前等待一段时间以接收HIP R1来缓解延迟。请注意，目前还没有关于如何并行调用此类连接的规范。以上述方式使用DNS时，也可能产生解析延迟。
A possible way to reduce the above-noted latencies, in the case that the application uses DNS, would be for the system to opportunistically query for HIP records in parallel to other DNS resource records, and to temporarily cache the HITs returned with a DNS lookup, indexed by the IP addresses returned in the same entry, and pass the IP addresses up to the application as usual. If an application connects to one of those IP addresses within a short time after the lookup, the host should initiate a base exchange using the
在应用程序使用DNS的情况下，减少上述延迟的一种可能方法是，系统机会主义地查询与其他DNS资源记录并行的HIP记录，并临时缓存通过DNS查找返回的命中，由相同条目中返回的IP地址索引，并像往常一样将IP地址传递给应用程序。如果应用程序在查找后的短时间内连接到其中一个IP地址，则主机应使用
cached HITs. The benefit is that this removes the uncertainty/delay associated with opportunistic HIP, because the DNS record suggests that the peer is HIP-capable.
缓存的命中率。好处是，这消除了与机会主义HIP相关的不确定性/延迟，因为DNS记录表明对等方具有HIP能力。
In the previous section, it was noted that a HIP-unaware application might typically use the DNS to fetch IP addresses prior to invoking socket calls. A HIP-enabled system might make use of DNS to transparently fetch host identifiers for such domain names prior to the onset of communication.
在上一节中，注意到HIP-Unknowledge应用程序通常会在调用套接字调用之前使用DNS获取IP地址。启用HIP的系统可以在通信开始之前使用DNS透明地获取此类域名的主机标识符。
A system with a local DNS agent could alternately return a Local Scope Identifier (LSI) or HIT rather than an IP address, if HIP information is available in the DNS or other directory that binds a particular domain name to a host identifier, and otherwise to return an IP address as usual. The system can then maintain a mapping between LSI and host identifier and perform the appropriate conversion at the system call interface or below. The application uses the LSI or HIT as it would an IP address. This technique has been used in overlay networking experiments such as the Internet Indirection Infrastructure (i3) and by at least one HIP implementation.
如果DNS或将特定域名绑定到主机标识符的其他目录中有HIP信息，则具有本地DNS代理的系统可以交替返回本地作用域标识符（LSI）或HIT而不是IP地址，或者像往常一样返回IP地址。然后，系统可以维护LSI和主机标识符之间的映射，并在系统调用接口或以下位置执行适当的转换。应用程序使用LSI或HIT作为IP地址。该技术已被用于覆盖网络实验，如Internet间接寻址基础设施（i3）和至少一个HIP实现。
In the case when resolvers can return multiple destination identifiers for an application, it may be configured that some of the identifiers can be HIP-based identifiers, and the rest can be IPv4 or IPv6 addresses. The system resolver may return HIP-based identifiers in front of the list of identifiers when the underlying system and policies support HIP. An application processing the identifiers sequentially will then first try a HIP-based connection and only then other non-HIP based connections. However, certain applications may launch the connections in parallel. In such a case, the non-HIP connections may succeed before HIP connections. Based on local system policies, a system may disallow such behavior and return only HIP-based identifiers when they are found from DNS.
在解析器可以为应用返回多个目的地标识符的情况下，可以配置一些标识符可以是基于HIP的标识符，其余的可以是IPv4或IPv6地址。当基础系统和策略支持HIP时，系统解析器可以在标识符列表前面返回基于HIP的标识符。依次处理标识符的应用程序将首先尝试基于HIP的连接，然后才尝试其他非基于HIP的连接。但是，某些应用程序可能会并行启动连接。在这种情况下，非髋关节连接可能在髋关节连接之前成功。基于本地系统策略，系统可能不允许此类行为，并且当从DNS中找到基于HIP的标识符时，系统可能只返回这些标识符。
If the application obtains LSIs or HITs that it treats as IP addresses, a few potential hazards arise. First, applications that perform referrals may pass the LSI to another system that has no system context to resolve the LSI back to a host identifier or an IP address. Note that these are the same type of applications that will likely break if used over certain types of network address translators (NATs). Second, applications may cache the results of DNS queries for a long time, and it may be hard for a HIP system to determine when to perform garbage collection on the LSI bindings. However, when using HITs, the security of using the HITs for identity comparison may be stronger than in the case of using IP addresses.
如果应用程序获得其视为IP地址的LSI或HIT，则会出现一些潜在危险。首先，执行转介的应用程序可能会将LSI传递给另一个没有系统上下文的系统，以将LSI解析回主机标识符或IP地址。请注意，如果通过某些类型的网络地址转换器（NAT）使用，这些应用程序可能会中断。其次，应用程序可能会长时间缓存DNS查询的结果，HIP系统可能很难确定何时对LSI绑定执行垃圾收集。然而，当使用HITs时，使用HITs进行身份比较的安全性可能比使用IP地址的情况更强。
Finally, applications may generate log files, and administrators or other consumers of these log files may become confused to find LSIs or HITs instead of IP addresses. Therefore, it is recommended that the HIP software logs the HITs, LSIs (if applicable), corresponding IP addresses, and Fully Qualified Domain Name (FQDN)-related information so that administrators can correlate other logs with HIP identifiers.
最后，应用程序可能会生成日志文件，这些日志文件的管理员或其他使用者可能会感到困惑，无法找到LSI或HIT而不是IP地址。因此，建议HIP软件记录HITs、LSI（如果适用）、相应的IP地址和完全限定域名（FQDN）相关信息，以便管理员可以将其他日志与HIP标识符关联起来。
It may be possible for an LSI or HIT to be routable or resolvable, either directly or through an overlay, in which case it would be preferable for applications to handle such names instead of IP addresses. However, such networks are out of scope of this document.
LSI或HIT可以直接或通过覆盖层路由或解析，在这种情况下，应用程序最好处理此类名称而不是IP地址。但是，此类网络不在本文件的范围内。
Solutions preserving the use of IP addresses in the applications have the benefit of better support for applications that use IP addresses for long-lived application associations, callbacks, and referrals, although it should be noted that applications are discouraged from using IP addresses in this manner due to the frequent presence of NATs [RFC1958]. However, they have weaker security properties than the approaches outlined in Section 3.2 and Section 4, because the binding between host identifier and address is weak and not visible to the application or user. In fact, the semantics of the application's "connect(ip)" call may be interpreted as "connect me to the system reachable at IP address ip" but perhaps no stronger semantics than that. HIP can be used in this case to provide perfect forward secrecy and authentication, but not to strongly authenticate the peer at the onset of communications.
在应用程序中保留IP地址使用的解决方案有利于更好地支持将IP地址用于长期应用程序关联、回调和引用的应用程序，但应注意，由于频繁存在NAT，不鼓励应用程序以这种方式使用IP地址[RFC1958]。但是，与第3.2节和第4节中概述的方法相比，它们的安全属性较弱，因为主机标识符和地址之间的绑定较弱，并且对应用程序或用户不可见。事实上，应用程序的“连接（ip）”调用的语义可以解释为“将我连接到可在IP地址访问的系统”，但可能没有比这更强大的语义。在这种情况下，HIP可用于提供完美的前向保密和身份验证，但不能在通信开始时对对等方进行强身份验证。
Using IP addresses at the application layer may not provide the full potential benefits of HIP mobility support. It allows for mobility if the system is able to readdress long-lived, connected sockets upon a HIP readdress event. However, as in current systems, mobility will break in the connectionless case, when an application caches the IP address and repeatedly calls sendto(), or in the case of TCP when the system later opens additional sockets to the same destination.
在应用层使用IP地址可能无法提供髋关节活动支持的全部潜在好处。如果系统能够在HIP重新安装事件中重新安装长寿命、连接的插座，则它允许移动。但是，与当前系统一样，在无连接的情况下，当应用程序缓存IP地址并重复调用sendto（）时，或者在TCP的情况下，当系统稍后向同一目标打开其他套接字时，移动性将中断。
Section 4.1.6 of the base HIP protocol specification [RFC5201] states that implementations that learn of HIT-to-IP address bindings through the use of HIP opportunistic mode must not enforce those bindings on later communications sessions. This implies that when IP addresses are used by the applications, systems that attempt to opportunistically set up HIP must not assume that later sessions to the same address will communicate with the same host.
基本HIP协议规范[RFC5201]第4.1.6节规定，通过使用HIP机会主义模式学习命中到IP地址绑定的实现不得在以后的通信会话上强制执行这些绑定。这意味着，当应用程序使用IP地址时，尝试机会主义地设置HIP的系统不得假设到同一地址的后续会话将与同一主机通信。
The legacy application is unaware of HIP and therefore cannot notify the user when the application uses HIP. However, the operating system can notify the user of the usage of HIP through a user agent. Further, it is possible for the user agent to name the network application that caused a HIP-related event. This way, the user is aware when he or she is using HIP even though the legacy network application is not. Based on usability tests from initial deployments, displaying the HITs and LSIs should be avoided in user interfaces. Instead, traditional security measures (lock pictures, colored address bars) should be used where possible.
遗留应用程序不知道HIP，因此无法在应用程序使用HIP时通知用户。但是，操作系统可以通过用户代理通知用户HIP的使用情况。此外，用户代理可以命名导致HIP相关事件的网络应用程序。这样，即使传统网络应用程序没有使用HIP，用户也能意识到自己正在使用HIP。根据初始部署的可用性测试，应避免在用户界面中显示HIT和LSI。相反，应尽可能使用传统的安全措施（锁定图片、彩色地址栏）。
One drawback to spoofing the DNS resolution is that some applications, or selected instances of an application, actually may want to fetch IP addresses (e.g., diagnostic applications such as ping). One way to provide finer granularity on whether the resolver returns an IP address or an LSI is to have the user form a modified domain name when he or she wants to invoke HIP. This leads us to consider, in the next section, use cases for which the end user explicitly and selectively chooses to enable HIP.
欺骗DNS解析的一个缺点是，某些应用程序或应用程序的选定实例实际上可能想要获取IP地址（例如，诊断应用程序，如ping）。在解析程序返回IP地址还是LSI方面提供更精细粒度的一种方法是，当用户想要调用HIP时，让用户形成修改后的域名。这使我们在下一节中考虑终端用户明确地和有选择地选择启用HIP的用例。
The previous section described approaches for configuring HIP for legacy applications that did not necessarily involve the user. However, there may be cases in which a legacy application user wants to use HIP for a given application instance by signaling to the HIP-enabled system in some way. If the application user interface or configuration file accepts IP addresses, there may be an opportunity to provide a HIT or an LSI in its place. Furthermore, if the application uses DNS, a user may provide a specially crafted domain name to signal to the resolver to fetch HIP records and to signal to the system to use HIP. We describe both of these approaches below.
上一节描述了为不一定涉及用户的遗留应用程序配置HIP的方法。然而，在某些情况下，遗留应用程序用户可能希望通过以某种方式向支持HIP的系统发送信号来为给定应用程序实例使用HIP。如果应用程序用户界面或配置文件接受IP地址，则可能有机会在其位置提供HIT或LSI。此外，如果应用程序使用DNS，则用户可以提供精心编制的域名，以向解析程序发送信号以获取HIP记录，并向系统发送信号以使用HIP。我们将在下面描述这两种方法。
Section 3.2 above describes the use of HITs or LSIs as spoofed return values of the DNS resolution process. A similar approach that is more explicit is to configure the application to connect directly to a HIT (e.g., "connect(HIT)" as a socket call). This scenario has stronger security semantics, because the application is asking the system to send packets specifically to the named peer system. HITs have been defined as Overlay Routable Cryptographic Hash Identifiers (ORCHIDs) such that they cannot be confused with routable IP addresses; see [RFC4843].
上面第3.2节描述了使用HITs或LSI作为DNS解析过程的伪造返回值。更明确的类似方法是将应用程序配置为直接连接到HIT（例如，“连接（HIT）”作为套接字调用）。此场景具有更强的安全语义，因为应用程序要求系统专门向指定的对等系统发送数据包。点击被定义为覆盖可路由加密散列标识符（RAYT），这样它们就不会与可路由IP地址混淆；见[RFC4843]。
This approach also has a few challenges. Using HITs can be more cumbersome for human users (due to the flat HIT name space) than using either IPv6 addresses or domain names. Another challenge with
这种方法也有一些挑战。对于人类用户来说，使用HITs可能比使用IPv6地址或域名更麻烦（因为HIT的名称空间是扁平的）。另一个挑战是
this approach is in actually finding the IP addresses to use, based on the HIT. Some type of HIT resolution service would be needed in this case. A third challenge of this approach is in supporting callbacks and referrals to possibly non-HIP-aware hosts. However, since most communications in this case would likely be to other HIP-aware hosts (else the initial HIP associations would fail to establish), the resulting referral problem may be that the peer host supports HIP but is not able to perform HIT resolution for some reason.
这种方法实际上是根据HIT查找要使用的IP地址。在这种情况下，需要某种类型的命中解析服务。这种方法的第三个挑战是支持回调和转介到可能不了解HIP的主机。但是，由于在这种情况下，大多数通信可能是与其他HIP感知主机进行的（否则初始HIP关联将无法建立），因此产生的转诊问题可能是对等主机支持HIP，但由于某种原因无法执行HIT解析。
Specifically, if the application requests to resolve "HIP-www.example.com" (or some similar prefix string), then the system returns an LSI, while if the application requests to resolve "www.example.com", IP address(es) are returned as usual. The use of a prefix rather than suffix is recommended, and the use of a string delimiter that is not a dot (".") is also recommended, to reduce the likelihood that such modified DNS names are mistakenly treated as names rooted at a new top-level domain. Limits of domain name length or label length (255 or 63, respectively) should be considered when prepending any prefixes.
具体而言，如果应用程序请求解析“HIP-www.example.com”（或一些类似的前缀字符串），则系统返回一个LSI，而如果应用程序请求解析“www.example.com”，则像往常一样返回IP地址。建议使用前缀而不是后缀，并且还建议使用非点（“.”）的字符串分隔符，以减少此类修改后的DNS名称被错误地视为源于新顶级域的名称的可能性。在前置任何前缀时，应考虑域名长度或标签长度的限制（分别为255或63）。
Alternatives to using a modified DNS name that have been experimented with include the following. Command-line tools or tools with a graphical user interface (GUI) can be provided by the system to allow a user to set the policy on which applications use HIP. Another common technique, for dynamically linked applications, is to dynamically link the application to a modified library that wraps the system calls and interposes HIP layer communications on them; this can be invoked by the user by running commands through a special shell, for example.
使用经过试验的修改后的DNS名称的替代方案包括以下内容。系统可以提供命令行工具或具有图形用户界面（GUI）的工具，以允许用户设置应用程序使用HIP的策略。对于动态链接的应用程序，另一种常用技术是将应用程序动态链接到修改过的库，该库封装系统调用并在其上插入HIP层通信；例如，用户可以通过一个特殊的shell运行命令来调用它。
The previous two sections focused mainly on controlling client behavior (HIP initiator). We must also consider the behavior for servers. Typically, a server binds to a wildcard IP address and well-known port. In the case of HIP use with legacy server implementations, there are again a few options. The system may be configured manually to always, optionally (depending on the client behavior), or never use HIP with a particular service, as a matter of policy, when the server specifies a wildcard (IP) address.
前两部分主要关注控制客户端行为（HIP启动器）。我们还必须考虑服务器的行为。通常，服务器绑定到通配符IP地址和已知端口。在使用HIP与传统服务器实现的情况下，还有一些选项。根据策略，当服务器指定通配符（IP）地址时，系统可以手动配置为始终（可选）（取决于客户端行为）或从不对特定服务使用HIP。
When a system API call such as getaddrinfo [RFC3493] is used for resolving local addresses, it may also return HITs or LSIs, if the system has assigned HITs or LSIs to internal virtual interfaces (common in many HIP implementations). The application may use such identifiers as addresses in subsequent socket calls.
当系统API调用（如getaddrinfo[RFC3493]）用于解析本地地址时，如果系统已将HITs或LSI分配给内部虚拟接口（在许多HIP实现中常见），则它还可能返回HITs或LSI。应用程序可以在随后的套接字调用中使用这样的标识符作为地址。
Some applications may try to bind a socket to a specific local address, or may implement server-side access control lists based on socket calls such as getsockname() and getpeername() in the C-based socket APIs. If the local address specified is an IP address, again, the underlying system may be configured to still use HIP. If the local address specified is a HIT (Section 4), the system should enforce that connections to the local application can only arrive to the specified HIT. If a system has many HIs, an application that binds to a single HIT cannot accept connections to the other HIs but the one corresponding to the specified HIT.
一些应用程序可能会尝试将套接字绑定到特定的本地地址，或者可能会基于套接字调用实现服务器端访问控制列表，例如基于C的套接字API中的getsockname（）和getpeername（）。如果指定的本地地址是IP地址，那么底层系统也可以配置为仍然使用HIP。如果指定的本地地址是HIT（第4节），则系统应强制要求与本地应用程序的连接只能到达指定的HIT。如果一个系统有多个HI，绑定到一个HIT的应用程序不能接受到另一个HIs的连接，但与指定HIT对应的HIs除外。
When a host has multiple HIs and the socket behavior does not prescribe the use of any particular HI as a local identifier, it is a matter of local policy as to how to select a HI to serve as a local identifier. However, systems that bind to a wildcard may face problems when multiple HITs or LSIs are defined. These problems are not specific to HIP per se, but are also encountered in non-HIP multihoming scenarios with applications not designed for multihoming.
当主机有多个HI且套接字行为未规定使用任何特定HI作为本地标识符时，如何选择HI作为本地标识符是本地策略的问题。然而，当定义多个命中或LSI时，绑定到通配符的系统可能会面临问题。这些问题并非特定于HIP本身，但在非HIP多宿场景中也会遇到，应用程序不是为多宿设计的。
As an example, consider a client application that sends a UDP datagram to a server that is bound to a wildcard. The server application receives the packet using recvfrom() and sends a response using sendto(). The problem here is that sendto() may actually use a different server HIT than the client assumes. The client will drop the response packet when the client implements access control on the UDP socket (e.g., using connect()).
举个例子，考虑一个客户端应用程序，它将UDP数据报发送到绑定到通配符的服务器。服务器应用程序使用recvfrom（）接收数据包，并使用sendto（）发送响应。这里的问题是sendto（）实际使用的服务器命中率可能与客户端假定的不同。当客户端在UDP套接字上实现访问控制时（例如，使用connect（）），客户端将丢弃响应数据包。
Reimplementing the server application using the sendmsg() and recvmsg() to support multihoming (particularly considering the ancillary data) would be the ultimate solution to this problem, but with legacy applications is not an option. As a workaround, we make suggestion for servers providing UDP-based services with non-multihoming-capable services. Such servers should announce only the HIT or public key that matches to the default outgoing HIT of the host to avoid such problems.
使用sendmsg（）和recvmsg（）重新实现服务器应用程序以支持多宿主（特别是考虑辅助数据）将是解决此问题的最终解决方案，但使用遗留应用程序不是一个选项。作为一种解决方法，我们建议服务器提供基于UDP的服务和不支持多宿主的服务。这样的服务器应该只公布与主机的默认传出HIT匹配的HIT或公钥，以避免此类问题。
Finally, some applications may create a connection to a local HIT. In such a case, the local system may use NULL encryption to avoid unnecessary encryption overhead, and may be otherwise more permissive than usual such as excluding authentication, Diffie-Hellman exchange, and puzzle.
最后，一些应用程序可能会创建到本地HIT的连接。在这种情况下，本地系统可以使用空加密来避免不必要的加密开销，并且可以比通常更为允许，例如排除认证、Diffie-Hellman交换和谜题。
In this section, we discuss the security of the system in general terms, outlining some of the security properties. However, this section is not intended to provide a complete risk analysis. Such an analysis would, in any case, be dependent on the actual application using HIP, and is therefore considered out of scope.
在本节中，我们将从总体上讨论系统的安全性，概述一些安全属性。但是，本节不打算提供完整的风险分析。无论如何，这种分析将取决于使用HIP的实际应用，因此被认为超出范围。
The scenarios outlined above differ considerably in their security properties. When the DNS is used, there are further differences related to whether or not DNSSEC [RFC4033] is used, and whether the DNS zones are considered trustworthy enough. Here we mean that there should exist a delegation chain to whatever trust anchors are available in the respective trees, and the DNS zone administrators in charge of the netblock should be trusted to put in the right information.
上述场景在安全属性上有很大的不同。当使用DNS时，与是否使用DNSSEC[RFC4033]以及DNS区域是否被认为足够可靠相关的进一步差异。在这里，我们的意思是应该存在一个委托链，指向各个树中可用的任何信任锚点，并且应该信任负责netblock的DNS区域管理员来输入正确的信息。
When IP addresses are used by applications to name the peer system, the security properties depend on the configuration method. With manual configuration, the security of the system is comparable to a non-HIP system with similar IPsec policies. The security semantics of an initial opportunistic key exchange are roughly equal to non-secured IP; the exchange is vulnerable to man-in-the-middle attacks. However, the system is less vulnerable to connection hijacking attacks. If the DNS is used, if both zones are secured (or the HITs are stored in the reverse DNS record) and the client trusts the DNSSEC signatures, the system may provide a fairly high security level. However, much depends on the details of the implementation, the security and administrative practices used when signing the DNS zones, and other factors.
当应用程序使用IP地址命名对等系统时，安全属性取决于配置方法。通过手动配置，系统的安全性可与具有类似IPsec策略的非HIP系统相媲美。初始机会密钥交换的安全语义大致等同于非安全IP；交易所容易受到中间人攻击。但是，系统不太容易受到连接劫持攻击。如果使用DNS，如果两个区域都是安全的（或者点击存储在反向DNS记录中），并且客户端信任DNSSEC签名，则系统可以提供相当高的安全级别。然而，这在很大程度上取决于实现的细节、签署DNS区域时使用的安全和管理实践以及其他因素。
Using the forward DNS to map a domain name into an LSI is a case that is closest to the most typical use scenarios today. If DNSSEC is used, the result is fairly similar to the current use of certificates with Transport Layer Security (TLS). If DNSSEC is not used, the result is fairly similar to the current use of plain IP, with the additional protection of data integrity, confidentiality, and prevention of connection hijacking that opportunistic HIP provides. If DNSSEC is used, data integrity and data origin authentication services are added to the normal DNS query protocol, thereby providing more certainty that the desired host is being contacted, if the DNS records themselves are trustworthy.
使用前向DNS将域名映射到LSI是目前最典型的使用场景。如果使用DNSSEC，结果与当前使用的具有传输层安全性（TLS）的证书非常相似。如果不使用DNSSEC，结果与当前使用的普通IP非常相似，具有额外的数据完整性保护、机密性保护和机会主义HIP提供的连接劫持预防。如果使用DNSSEC，数据完整性和数据源身份验证服务将添加到正常DNS查询协议中，从而在DNS记录本身可信的情况下，提供所需主机被联系的更确定性。
If the application is basing its operations on HITs, the connections become automatically secured due to the implicit channel bindings in HIP. That is, when the application makes a connect(HIT) system call, either the resulting packets will be sent to a node possessing the corresponding private key or the security association will fail to be established.
如果应用程序的操作基于HITs，则由于HIP中的隐式通道绑定，连接将自动得到保护。也就是说，当应用程序进行连接（HIT）系统调用时，生成的数据包将被发送到拥有相应私钥的节点，或者安全关联将无法建立。
When the system provides (spoofs) LSIs or HITs instead of IP addresses as the result of name resolution, the resultant fields may inadvertently show up in user interfaces and system logs, which may cause operational concerns for some network administrators. Therefore, it is recommended that the HIP software logs the HITs, LSIs (if applicable), corresponding IP addresses, and FQDN-related information so that administrators can correlate other logs with HIP identifiers.
当系统提供（欺骗）LSI或HITs而不是IP地址作为名称解析的结果时，结果字段可能会无意中显示在用户界面和系统日志中，这可能会引起一些网络管理员的操作问题。因此，建议HIP软件记录HITs、LSI（如果适用）、相应的IP地址和FQDN相关信息，以便管理员可以将其他日志与HIP标识符关联起来。
Jeff Ahrenholz, Gonzalo Camarillo, Alberto Garcia, Teemu Koponen, Julien Laganier, and Jukka Ylitalo have provided comments on different versions of this document. The document received substantial and useful comments during the review phase from David Black, Lars Eggert, Peter Koch, Thomas Narten, and Pekka Savola.
Jeff Ahrenholz、Gonzalo Camarillo、Alberto Garcia、Teemu Koponen、Julien Laganier和Jukka Ylitalo对本文件的不同版本发表了评论。该文件在审查阶段收到了来自David Black、Lars Eggert、Peter Koch、Thomas Narten和Pekka Savola的大量有用的评论。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201]Moskowitz，R.，Nikander，P.，Jokela，P.，Ed.，和T.Henderson，“主机身份协议”，RFC 52012008年4月。
[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April 2007.
[RFC4843]Nikander，P.，Laganier，J.，和F.Dupont，“覆盖可路由加密哈希标识符（RAYD）的IPv6前缀”，RFC 4843，2007年4月。
[TESLA] Salz, J., Balakrishnan, H., and A. Snoeren, "TESLA: A Transparent, Extensible Session-Layer Architecture for End-to-end Network Services", Proceedings of USENIX Symposium on Internet Technologies and Systems (USITS), pages 211-224, March 2003.
[TESLA]Salz，J.，Balakrishnan，H.，和A.Snoren，“TESLA：端到端网络服务的透明、可扩展会话层架构”，USENIX互联网技术和系统研讨会论文集，第211-224页，2003年3月。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]Carpenter，B.，Ed.“互联网的架构原则”，RFC19581996年6月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[RFC3493]Gilligan，R.，Thomson，S.，Bound，J.，McCann，J.，和W.Stevens，“IPv6的基本套接字接口扩展”，RFC 3493，2003年2月。
[APP_REF] Nordmark, E., "Shim6 Application Referral Issues", Work in Progress, July 2005.
[APP_REF]Nordmark，E.，“Shim6应用程序转介问题”，正在进行的工作，2005年7月。
Authors' Addresses
作者地址
Thomas Henderson The Boeing Company P.O. Box 3707 Seattle, WA USA
托马斯·亨德森波音公司美国华盛顿州西雅图3707号邮政信箱
EMail: thomas.r.henderson@boeing.com
EMail: thomas.r.henderson@boeing.com
Pekka Nikander Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND
佩卡·尼坎德·爱立信研究实验室JORVAS FIN-02420芬兰
Phone: +358 9 299 1
EMail: pekka.nikander@nomadiclab.com
Phone: +358 9 299 1
EMail: pekka.nikander@nomadiclab.com
Miika Komu Helsinki Institute for Information Technology Metsaenneidonkuja 4 Helsinki FIN-02420 FINLAND
Miika Komu赫尔辛基信息技术研究所Metsaenneidonkuja 4芬兰赫尔辛基FIN-02420
Phone: +358503841531
EMail: miika@iki.fi
Phone: +358503841531
EMail: miika@iki.fi
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见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.