Network Working Group E. Nordmark
Request for Comments: 4218 Sun Microsystems
Category: Informational T. Li
October 2005
Network Working Group E. Nordmark
Request for Comments: 4218 Sun Microsystems
Category: Informational T. Li
October 2005
Threats Relating to IPv6 Multihoming Solutions
与IPv6多宿主解决方案相关的威胁
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document lists security threats related to IPv6 multihoming. Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses.
本文档列出了与IPv6多宿主相关的安全威胁。多宿可以引入新的机会，将数据包重定向到不同的、非预期的IP地址。
The intent is to look at how IPv6 multihoming solutions might make the Internet less secure; we examine threats that are inherent to all IPv6 multihoming solutions rather than study any specific proposed solution. The threats in this document build upon the threats discovered and discussed as part of the Mobile IPv6 work.
目的是研究IPv6多宿主解决方案如何降低互联网的安全性；我们研究所有IPv6多宿主解决方案固有的威胁，而不是研究任何特定的建议解决方案。本文档中的威胁基于移动IPv6工作中发现和讨论的威胁。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Assumptions ................................................3
1.2. Authentication, Authorization, and Identifier Ownership ....4
2. Terminology .....................................................5
3. Today's Assumptions and Attacks .................................6
3.1. Application Assumptions ....................................6
3.2. Redirection Attacks Today ..................................8
3.3. Packet Injection Attacks Today .............................9
3.4. Flooding Attacks Today ....................................10
3.5. Address Privacy Today .....................................11
4. Potential New Attacks ..........................................13
4.1. Cause Packets to Be Sent to the Attacker ..................13
4.1.1. Once Packets Are Flowing ...........................13
4.1.2. Time-Shifting Attack ...............................14
4.1.3. Premeditated Redirection ...........................14
4.1.4. Using Replay Attacks ...............................15
1. Introduction ....................................................2
1.1. Assumptions ................................................3
1.2. Authentication, Authorization, and Identifier Ownership ....4
2. Terminology .....................................................5
3. Today's Assumptions and Attacks .................................6
3.1. Application Assumptions ....................................6
3.2. Redirection Attacks Today ..................................8
3.3. Packet Injection Attacks Today .............................9
3.4. Flooding Attacks Today ....................................10
3.5. Address Privacy Today .....................................11
4. Potential New Attacks ..........................................13
4.1. Cause Packets to Be Sent to the Attacker ..................13
4.1.1. Once Packets Are Flowing ...........................13
4.1.2. Time-Shifting Attack ...............................14
4.1.3. Premeditated Redirection ...........................14
4.1.4. Using Replay Attacks ...............................15
4.2. Cause Packets to Be Sent to a Black Hole ..................15
4.3. Third Party Denial-of-Service Attacks .....................16
4.3.1. Basic Third Party DoS ..............................17
4.3.2. Third Party DoS with On-Path Help ..................18
4.4. Accepting Packets from Unknown Locators ...................19
4.5. New Privacy Considerations ................................20
5. Granularity of Redirection .....................................20
6. Movement Implications? .........................................22
7. Other Security Concerns ........................................23
8. Security Considerations ........................................24
9. Acknowledgements ...............................................24
10. Informative References ........................................25
Appendix A: Some Security Analysis ................................27
4.2. Cause Packets to Be Sent to a Black Hole ..................15
4.3. Third Party Denial-of-Service Attacks .....................16
4.3.1. Basic Third Party DoS ..............................17
4.3.2. Third Party DoS with On-Path Help ..................18
4.4. Accepting Packets from Unknown Locators ...................19
4.5. New Privacy Considerations ................................20
5. Granularity of Redirection .....................................20
6. Movement Implications? .........................................22
7. Other Security Concerns ........................................23
8. Security Considerations ........................................24
9. Acknowledgements ...............................................24
10. Informative References ........................................25
Appendix A: Some Security Analysis ................................27
The goal of the IPv6 multihoming work is to allow a site to take advantage of multiple attachments to the global Internet, without having a specific entry for the site visible in the global routing table. Specifically, a solution should allow hosts to use multiple attachments in parallel, or to switch between these attachment points dynamically in the case of failures, without an impact on the transport and application layer protocols.
IPv6多宿主工作的目标是允许站点利用到全局Internet的多个附件，而不必在全局路由表中看到站点的特定条目。具体而言，解决方案应允许主机并行使用多个附件，或在发生故障时在这些附件点之间动态切换，而不会影响传输层和应用层协议。
At the highest level, the concerns about allowing such "rehoming" of packet flows can be called "redirection attacks"; the ability to cause packets to be sent to a place that isn't tied to the transport and/or application layer protocol's notion of the peer. These attacks pose threats against confidentiality, integrity, and availability. That is, an attacker might learn the contents of a particular flow by redirecting it to a location where the attacker has a packet recorder. If, instead of a recorder, the attacker changes the packets and then forwards them to the ultimate destination, the integrity of the data stream would be compromised. Finally, the attacker can simply use the redirection of a flow as a denial of service attack.
在最高级别上，关于允许分组流的这种“重新配置”的担忧可以称为“重定向攻击”；使数据包发送到与传输和/或应用层协议的对等概念无关的位置的能力。这些攻击对机密性、完整性和可用性构成威胁。也就是说，攻击者可以通过将特定流重定向到攻击者拥有数据包记录器的位置来了解该流的内容。如果攻击者更改数据包而不是记录器，然后将其转发到最终目的地，则数据流的完整性将受到损害。最后，攻击者可以简单地将流重定向用作拒绝服务攻击。
This document has been developed while considering multihoming solutions architected around a separation of network identity and network location, whether or not this separation implies the introduction of a new and separate identifier name space. However, this separation is not a requirement for all threats, so this taxonomy may also apply to other approaches. This document is not intended to examine any single proposed solution. Rather, it is intended as an aid to discussion and evaluation of proposed solutions. By cataloging known threats, we can help to ensure that all proposals deal with all of the available threats.
本文档是在考虑围绕网络标识和网络位置分离而构建的多归属解决方案的同时开发的，无论这种分离是否意味着引入新的和单独的标识符名称空间。然而，这种分离并不是所有威胁的要求，因此这种分类法也可能适用于其他方法。本文件不打算审查任何单一的建议解决方案。相反，它旨在帮助讨论和评估拟议的解决方案。通过对已知威胁进行编目，我们可以帮助确保所有提案都能应对所有可用的威胁。
As a result of not analyzing a particular solution, this document is inherently incomplete. An actual solution would need to be analyzed as part of its own threat analysis, especially in the following areas:
由于没有分析特定的解决方案，本文档本质上是不完整的。实际解决方案需要作为其自身威胁分析的一部分进行分析，特别是在以下领域：
1) If the solution makes the split between locators and identifiers, then most application security mechanisms should be tied to the identifier, not to the locator. Therefore, work would be needed to understand how attacks on the identifier mechanism affect security, especially attacks on the mechanism that would bind locators to identifiers.
1) 如果解决方案在定位器和标识符之间进行拆分，那么大多数应用程序安全机制应该绑定到标识符，而不是定位器。因此，需要了解对标识符机制的攻击如何影响安全性，特别是对将定位器绑定到标识符的机制的攻击。
2) How does the solution apply multihoming to IP multicast? Depending on how this is done, there might be specific threats relating to multicast that need to be understood. This document does not discuss any multicast-specific threats.
2) 该解决方案如何将多宿主应用于IP多播？根据这一操作的方式，可能存在与多播相关的特定威胁，需要了解这些威胁。本文档不讨论任何特定于多播的威胁。
3) Connection-less transport protocols probably need more attention. They are already difficult to secure, even without a locator/identifier split.
3) 无连接传输协议可能需要更多的关注。即使没有定位器/标识符拆分，它们也很难安全。
This threat analysis doesn't assume that security has been applied to other security relevant parts of the Internet, such as DNS and routing protocols; but it does assume that, at some point in time, at least parts of the Internet will be operating with security for such key infrastructure. With that assumption, it then becomes important that a multihoming solution would not, at that point in time, become the weakest link. This is the case even if, for instance, insecure DNS might be the weakest link today.
这种威胁分析并不认为安全性已经应用于互联网的其他安全相关部分，如DNS和路由协议；但它确实假设，在某个时间点，至少部分互联网将在这样的关键基础设施安全的情况下运行。有了这一假设，多宿解决方案在当时不会成为最薄弱的环节就变得很重要了。即使不安全的DNS可能是当今最薄弱的环节，情况也是如此。
This document doesn't assume that the application protocols are protected by strong security today or in the future. However, it is still useful to assume that the application protocols that care about integrity and/or confidentiality apply the relevant end-to-end security measures, such as IPsec, TLS, and/or application layer security.
本文档并不假设应用程序协议在今天或将来受到强大安全性的保护。然而，假设关心完整性和/或机密性的应用程序协议应用相关的端到端安全措施（例如IPsec、TLS和/或应用程序层安全）仍然是有用的。
For simplicity, this document assumes that an on-path attacker can see packets, modify packets and send them out, and block packets from being delivered. This is a simplification because there might exist ways (for instance, monitoring capability in switches) that allow authenticated and authorized users to observe packets without being able to send or block the packets.
为简单起见，本文档假设路径上的攻击者可以看到数据包、修改数据包并将其发送出去，以及阻止数据包的传递。这是一种简化，因为可能存在允许经过身份验证和授权的用户观察数据包而不能够发送或阻止数据包的方法（例如，交换机中的监控功能）。
In some cases it might make sense to make a distinction between on-path attackers, which can monitor packets and perhaps also inject packets, without being able to block packets from passing through.
在某些情况下，区分路径上的攻击者可能是有意义的，它们可以监视数据包，也可能注入数据包，但无法阻止数据包通过。
On-path attackers that only need to monitor might be lucky and find a non-switched Ethernet in the path, or use capacitive or inductive coupling to listen on a copper wire. But if the attacker is on an Ethernet that is on the path, whether switched or not, the attacker can also employ Address Resolution Protocol/Neighbor Discovery (ARP/ND) spoofing to get access to the packet flow which allows blocking as well. Similarly, if the attacker has access to the wire, the attacker can also place a device on the wire to block. Other on-path attacks would be those that gain control of a router or a switch (or gain control of one of the endpoints), and most likely those would allow blocking as well.
只需要监视的路径上攻击者可能很幸运，可以在路径中找到非交换以太网，或者使用电容或电感耦合来监听铜线。但是，如果攻击者位于路径上的以太网上，无论是否交换，攻击者也可以利用地址解析协议/邻居发现（ARP/ND）欺骗来访问数据包流，这也允许阻塞。类似地，如果攻击者可以访问导线，则攻击者还可以在导线上放置设备以阻止。其他路径攻击可能是那些获得路由器或交换机控制权（或获得其中一个端点的控制权）的攻击，最有可能的攻击也会允许阻塞。
So the strongest currently known case where monitoring is easier than blocking, is when switches and routers have monitoring capabilities (for network management or for lawful intercept) where an attacker might be able to bypass the authentication and authorization checks for those capabilities. However, this document makes the simplifying assumption treat all on-path attackers the same by assuming that such an attacker can monitor, inject, and block packets. A security analysis of a particular proposal can benefit from not making this assumption, and look at how on-path attackers with different capabilities can generate different attacks perhaps not present in today's Internet.
因此，目前已知的监控比阻塞更容易的最强情况是，当交换机和路由器具有监控功能（用于网络管理或合法拦截）时，攻击者可能能够绕过这些功能的身份验证和授权检查。但是，本文档通过假设所有路径上的攻击者都可以监视、注入和阻止数据包，从而简化了假设。对特定方案的安全性分析可以从不做此假设中获益，并了解具有不同能力的路径上攻击者如何产生不同的攻击，这些攻击可能在当今的互联网中并不存在。
The document assumes that an off-path attacker can neither see packets between the peers (for which it is not on the path) nor block them from being delivered. Off-path attackers can, in general, send packets with arbitrary IP source addresses and content, but such packets might be blocked if ingress filtering [INGRESS] is applied. Thus, it is important to look at the multihoming impact on security both in the presence and absence of ingress filtering.
文档假定非路径攻击者既看不到对等方之间的数据包（不在路径上），也无法阻止数据包的传递。通常，非路径攻击者可以发送具有任意IP源地址和内容的数据包，但如果应用了入口过滤[ingress]，这些数据包可能会被阻止。因此，在存在和不存在入口过滤的情况下，观察多宿主对安全性的影响是很重要的。
The overall problem domain can be described using different terminology.
整个问题域可以使用不同的术语来描述。
One way to describe it is that it is necessary to first authenticate the peer and then verify that the peer is authorized to control the locators used for a particular identifier. While this is correct, it might place too much emphasis on the authorization aspect. In this case, the authorization is conceptually very simple; each host (each identifier) is authorized to control which locators are used for itself.
描述它的一种方法是，必须首先对对等方进行身份验证，然后验证对等方是否有权控制用于特定标识符的定位器。虽然这是正确的，但它可能过于强调授权方面。在这种情况下，授权在概念上非常简单；每个主机（每个标识符）都有权控制自己使用的定位器。
Hence, there is a different way to describe the same thing. If the peer can somehow prove that it is the owner of the identifier, and the communication is bound to the identifier (and not the locator), then the peer is allowed to control the locators that are used with the identifier. This way to describe the problem is used in [OWNER].
因此，有一种不同的方式来描述同一件事。如果对等方能够以某种方式证明它是标识符的所有者，并且通信绑定到标识符（而不是定位器），则允许对等方控制与标识符一起使用的定位器。[OWNER]中使用了这种描述问题的方法。
Both ways to look at the problem, hence both sets of terminology, are useful when trying to understand the problem space and the threats.
在试图理解问题空间和威胁时，两种看待问题的方法，以及两套术语都是有用的。
link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IPv6. Examples are Ethernets (simple or bridged); PPP links; X.25, Frame Relay, or ATM networks; and Internet (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 itself.
链路—一种通信设施或介质，节点可通过该通信设施或介质在链路层（即IPv6下的一层）进行通信。例如以太网络（简单或桥接）；PPP链接；X.25、帧中继或ATM网络；互联网（或更高）层的“隧道”，如IPv4或IPv6本身上的隧道。
interface - a node's attachment to a link.
接口-节点与链接的附件。
address - an IP layer name that has both topological significance (i.e., a locator) and identifies an interface. There may be multiple addresses per interface. Normally an address uniquely identifies an interface, but there are exceptions: the same unicast address can be assigned to multiple interfaces on the same node, and an anycast address can be assigned to different interfaces on different nodes.
地址-具有拓扑意义（即定位器）和标识接口的IP层名称。每个接口可能有多个地址。通常一个地址唯一地标识一个接口，但也有例外：同一个单播地址可以分配给同一节点上的多个接口，而选播地址可以分配给不同节点上的不同接口。
locator - an IP layer topological name for an interface or a set of interfaces. There may be multiple locators per interface.
定位器-一个接口或一组接口的IP层拓扑名称。每个接口可能有多个定位器。
identifier - an IP layer identifier for an IP layer endpoint (stack name in [NSRG]), that is, something that might be commonly referred to as a "host". The transport endpoint name is a function of the transport protocol and would typically include the IP identifier plus a port number. There might be use for having multiple identifiers per stack/per host.
标识符—IP层端点（在[NSRG]中为堆栈名）的IP层标识符，也就是通常称为“主机”的内容。传输端点名称是传输协议的函数，通常包括IP标识符和端口号。每个堆栈/每个主机可能有多个标识符。
An identifier continues to function regardless of the state of any one interface.
无论任何一个接口的状态如何，标识符都会继续工作。
address field - the source and destination address fields in the IPv6 header. As IPv6 is currently specified, these fields carry "addresses". If identifiers and locators are separated, these fields will contain locators.
地址字段—IPv6标头中的源和目标地址字段。由于当前指定了IPv6，这些字段带有“地址”。如果标识符和定位器分开，这些字段将包含定位器。
FQDN - Fully Qualified Domain Name [FYI18]
FQDN-完全限定域名[FYI18]
The two interesting aspects of security for multihoming solutions are (1) the assumptions made by the transport layer and application layer protocols about the identifiers that they see, and (2) the existing abilities to perform various attacks that are related to the identity/location relationship.
多宿主解决方案的安全性有两个有趣的方面：（1）传输层和应用层协议对它们看到的标识符所做的假设，以及（2）执行与身份/位置关系相关的各种攻击的现有能力。
In the Internet today, the initiating part of applications either starts with a FQDN, which it looks up in the DNS, or already has an IP address from somewhere. For the FQDN to perform IP address lookup, the application effectively places trust in the DNS. Once it has the IP address, the application places trust in the routing system delivering packets to that address. Applications that use security mechanisms, such as IPSEC or TLS, have the ability to bind an address or FQDN to cryptographic keying material. Compromising the DNS and/or routing system can result in packets being dropped or delivered to an attacker in such cases, but since the attacker does not possess the keying material, the application will not trust the attacker, and the attacker cannot decrypt what it receives.
在今天的互联网上，应用程序的启动部分要么以FQDN开始，它在DNS中查找FQDN，要么已经从某处拥有IP地址。为了让FQDN执行IP地址查找，应用程序有效地信任DNS。一旦有了IP地址，应用程序就会信任向该地址发送数据包的路由系统。使用安全机制（如IPSEC或TLS）的应用程序能够将地址或FQDN绑定到加密密钥材料。在这种情况下，破坏DNS和/或路由系统可能会导致数据包被丢弃或交付给攻击者，但由于攻击者不拥有密钥材料，应用程序将不信任攻击者，并且攻击者无法解密其接收到的内容。
At the responding (non-initiating) end of communication today, we find that the security configurations used by different applications fall into approximately five classes, where a single application might use different classes of configurations for different types of communication.
在今天通信的响应（非启动）端，我们发现不同应用程序使用的安全配置分为大约五类，其中单个应用程序可能会对不同类型的通信使用不同的配置。
The first class is the set of public content servers. These systems provide data to any and all systems and are not particularly concerned with confidentiality, as they make their content available to all. However, they are interested in data integrity and denial of service attacks. Having someone manipulate the results of a search engine, for example, or prevent certain systems from reaching a search engine would be a serious security issue.
第一类是公共内容服务器集。这些系统向任何和所有系统提供数据，并不特别关心保密性，因为它们使所有人都能获得其内容。然而，他们对数据完整性和拒绝服务攻击感兴趣。例如，让某人操纵搜索引擎的结果或阻止某些系统访问搜索引擎将是一个严重的安全问题。
The second class of security configurations uses existing IP source addresses from outside of their immediate local site as a means of authentication without any form of verification. Today, with source IP address spoofing and TCP sequence number guessing as rampant attacks [RFC1948], such applications are effectively opening themselves for public connectivity and are reliant on other systems, such as firewalls, for overall security. We do not consider this class of configurations in this document because they are in any case fully open to all forms of network layer spoofing.
第二类安全配置使用直接本地站点外部的现有IP源地址作为身份验证手段，而无需任何形式的验证。如今，源IP地址欺骗和TCP序列号猜测是猖獗的攻击[RFC1948]，这类应用程序实际上是为了实现公共连接而开放的，并依赖其他系统（如防火墙）实现总体安全。在这个文档中，我们不考虑这类配置，因为它们在任何情况下都完全开放于所有形式的网络层欺骗。
The third class of security configurations receives existing IP source addresses, but attempt some verification using the DNS, effectively using the FQDN for access control. (This is typically done by performing a reverse lookup from the IP address, followed by a forward lookup and verifying that the IP address matches one of the addresses returned from the forward lookup.) These applications are already subject to a number of attacks using techniques like source address spoofing and TCP sequence number guessing since an attacker, knowing this is the case, can simply create a DoS attack using a forged source address that has authentic DNS records. In general this class of security configurations is strongly discouraged, but it is probably important that a multihoming solution doesn't introduce any new and easier ways to perform such attacks. However, we note that some people think we should treat this class the same as the second class of security configurations.
第三类安全配置接收现有的IP源地址，但尝试使用DNS进行一些验证，有效地使用FQDN进行访问控制。（这通常是通过从IP地址执行反向查找，然后执行正向查找，并验证IP地址是否与正向查找返回的地址之一匹配来完成的。）这些应用程序已经受到许多使用源地址欺骗和TCP序列号猜测等技术的攻击，因为攻击者知道这种情况，可以使用具有真实DNS记录的伪造源地址简单地创建DoS攻击。一般来说，强烈反对此类安全配置，但多宿主解决方案不引入任何新的更简单的方法来执行此类攻击可能很重要。但是，我们注意到，有些人认为我们应该将此类视为第二类安全配置。
The fourth class of security configurations uses cryptographic security techniques to provide both a strong identity for the peer and data integrity with or without confidentiality. Such systems are still potentially vulnerable to denial of service attacks that could be introduced by a multihoming solution.
第四类安全配置使用加密安全技术为对等方提供强身份和数据完整性，无论是否保密。此类系统仍然可能容易受到多主机解决方案可能引入的拒绝服务攻击的攻击。
Finally, the fifth class of security configurations uses cryptographic security techniques, but without strong identity (such as opportunistic IPsec). Thus, data integrity with or without confidentiality is provided when communicating with an unknown/unauthenticated principal. Just like the first category above, such applications can't perform access control based on network layer information since they do not know the identity of the peer. However, they might perform access control using higher-level notions of identity. The availability of IPsec (and similar solutions) together with channel bindings allows protocols (which, in themselves, are vulnerable to man-in-the-middle (MITM) attacks) to operate with a high level of confidentiality in the security of the identification of the peer. A typical example is the Remote Direct Data Placement Protocol (RDDP), which, when used with opportunistic IPsec, works well if channel bindings are available. Channel
最后，第五类安全配置使用加密安全技术，但没有强身份（如机会主义IPsec）。因此，当与未知/未经验证的主体通信时，可提供具有或不具有机密性的数据完整性。与上述第一类一样，此类应用程序无法基于网络层信息执行访问控制，因为它们不知道对等方的身份。然而，他们可能使用更高级别的身份概念来执行访问控制。IPsec（和类似解决方案）以及通道绑定的可用性允许协议（其本身容易受到中间人（MITM）攻击）在对等方标识的安全性方面以高度机密性运行。一个典型的例子是远程直接数据放置协议（RDDP），当与机会主义IPsec一起使用时，如果通道绑定可用，该协议可以很好地工作。频道
bindings provide a link between the IP-layer identification and the application protocol identification.
绑定提供了IP层标识和应用程序协议标识之间的链接。
A variant of the fifth class are those that use "leap-of-faith" during some initial communication. They do not provide strong identities except where subsequent communication is bound to the initial communication, providing strong assurance that the peer is the same as during the initial communication.
第五类的一个变体是在最初的交流中使用“信仰的飞跃”。它们不提供强身份，除非后续通信绑定到初始通信，提供了对等方与初始通信期间相同的强保证。
The fifth class is important and its security properties must be preserved by a multihoming solution.
第五类很重要，它的安全属性必须通过多宿主解决方案来保持。
The requirement for a multihoming solution is that security be no worse than it is today in all situations. Thus, mechanisms that provide confidentiality, integrity, or authentication today should continue to provide these properties in a multihomed environment.
多宿主解决方案的要求是，在所有情况下，安全性都不会比现在差。因此，今天提供机密性、完整性或身份验证的机制应该继续在多宿主环境中提供这些属性。
This section enumerates some of the redirection attacks that are possible in today's Internet.
本节列举了当今互联网上可能发生的一些重定向攻击。
If routing can be compromised, packets for any destination can be redirected to any location. This can be done by injecting a long prefix into global routing, thereby causing the longest match algorithm to deliver packets to the attacker.
如果路由可能被破坏，任何目的地的数据包都可以重定向到任何位置。这可以通过向全局路由中注入长前缀来实现，从而导致最长匹配算法将数据包传递给攻击者。
Similarly, if DNS can be compromised, and a change can be made to an advertised resource record to advertise a different IP address for a hostname, effectively taking over that hostname. More detailed information about threats relating to DNS are in [DNS-THREATS].
类似地，如果DNS可能被破坏，并且可以对公布的资源记录进行更改，以公布主机名的不同IP地址，从而有效地接管该主机名。有关DNS威胁的更多详细信息，请参阅[DNS-threats]。
Any system that is along the path from the source to the destination host can be compromised and used to redirect traffic. Systems may be added to the best path to accomplish this. Further, even systems that are on multi-access links that do not provide security can also be used to redirect traffic off of the normal path. For example, ARP and ND spoofing can be used to attract all traffic for the legitimate next hop across an Ethernet. And since the vast majority of applications rely on DNS lookups, if DNSsec is not deployed, then attackers that are on the path between the host and the DNS servers can also cause redirection by modifying the responses from the DNS servers.
从源主机到目标主机的路径上的任何系统都可能受到破坏，并用于重定向流量。可以将系统添加到最佳路径以实现这一点。此外，即使是在不提供安全性的多址链路上的系统也可以用于将流量重定向到正常路径之外。例如，可以使用ARP和ND欺骗来吸引以太网上合法下一跳的所有流量。由于绝大多数应用程序依赖DNS查找，如果未部署DNSsec，那么位于主机和DNS服务器之间路径上的攻击者也可以通过修改DNS服务器的响应来引起重定向。
In general, the above attacks work only when the attacker is on the path at the time it is performing the attack. However, in some cases it is possible for an attacker to create a DoS attack that remains at least some time after the attacker has moved off the path. An
通常，上述攻击仅在攻击者执行攻击时位于路径上时有效。但是，在某些情况下，攻击者可能会创建DoS攻击，该攻击在攻击者离开路径后至少保留一段时间。一
example of this is an attacker that uses ARP or ND spoofing while on path to either insert itself or send packets to a black hole (a non-existent L2 address). After the attacker moves away, the ARP/ND entries will remain in the caches in the neighboring nodes for some amount of time (a minute or so in the case of ARP). This will result in packets continuing to be black-holed until ARP entry is flushed.
例如，攻击者在路径上使用ARP或ND欺骗来插入自身或将数据包发送到黑洞（不存在的L2地址）。攻击者离开后，ARP/ND条目将在相邻节点的缓存中保留一段时间（对于ARP，大约一分钟）。这将导致数据包继续被黑洞，直到刷新ARP条目。
Finally, the hosts themselves that terminate the connection can also be compromised and can perform functions that were not intended by the end user.
最后，终止连接的主机本身也可能受到损害，并可能执行最终用户不希望执行的功能。
All of the above protocol attacks are the subject of ongoing work to secure them (DNSsec, security for BGP, Secure ND) and are not considered further within this document. The goal for a multihoming solution is not to solve these attacks. Rather, it is to avoid adding to this list of attacks.
上述所有协议攻击都是正在进行的安全工作的主题（DNSsec、BGP安全、安全ND），本文档不作进一步考虑。多宿主解决方案的目标不是解决这些攻击。相反，这是为了避免添加到该攻击列表中。
In today's Internet the transport layer protocols, such as TCP and SCTP, which use IP, use the IP addresses as the identifiers for the communication. In the absence of ingress filtering [INGRESS], the IP layer allows the sender to use an arbitrary source address, thus the transport protocols and/or applications need some protection against malicious senders injecting bogus packets into the packet stream between two communicating peers. If this protection can be circumvented, then it is possible for an attacker to cause harm without necessarily needing to redirect the return packets.
在今天的互联网上，传输层协议，如TCP和SCTP，使用IP，使用IP地址作为通信的标识符。在没有入口过滤[ingress]的情况下，IP层允许发送方使用任意源地址，因此传输协议和/或应用程序需要一些保护，以防止恶意发送方将虚假数据包注入两个通信对等方之间的数据包流。如果可以绕过此保护，则攻击者有可能造成伤害，而无需重定向返回数据包。
There are various levels of protection in different transport protocols. For instance, in general TCP packets have to contain a sequence that falls in the receiver's window to be accepted. If the TCP initial sequence numbers are random, then it is very hard for an off-path attacker to guess the sequence number close enough for it to belong to the window, and as a result be able to inject a packet into an existing connection. How hard this is depends on the size of the available window, whether the port numbers are also predictable, and the lifetime of the connection. Note that there is ongoing work to strengthen TCP's protection against this broad class of attacks [TCPSECURE]. SCTP provides a stronger mechanism with the verification tag; an off-path attacker would need to guess this random 32-bit number. Of course, IPsec provides cryptographically strong mechanisms that prevent attackers, on or off path, from injecting packets once the security associations have been established.
在不同的传输协议中有不同级别的保护。例如，一般来说，TCP数据包必须包含一个序列，该序列落在要接受的接收方窗口中。如果TCP初始序列号是随机的，则非路径攻击者很难猜到足够接近的序列号，使其属于窗口，从而能够将数据包注入现有连接。这有多困难取决于可用窗口的大小、端口号是否也是可预测的，以及连接的生存期。请注意，目前正在开展工作，以加强TCP对此类攻击的保护[TCPSECURE]。SCTP为验证标签提供了更强的机制；非路径攻击者需要猜测此随机32位数字。当然，IPsec提供了强大的加密机制，可防止攻击者在建立安全关联后，在路径上或路径外注入数据包。
When ingress filtering is deployed between the potential attacker and the path between the communicating peers, it can prevent the attacker from using the peer's IP address as source. In that case, the packet injection will fail in today's Internet.
当在潜在攻击者和通信对等方之间的路径之间部署入口过滤时，它可以防止攻击者使用对等方的IP地址作为源。在这种情况下，数据包注入将在今天的互联网上失败。
We don't expect a multihoming solution to improve the existing degree of prevention against packet injection. However, it is necessary to look carefully at whether a multihoming solution makes it easier for attackers to inject packets because the desire to have the peer present at multiple locators, and perhaps at a dynamic set of locators, can potentially result in solutions that, even in the presence of ingress filtering, make packet injection easier.
我们并不期望多宿主解决方案能够提高现有的防止数据包注入的程度。然而，有必要仔细研究多宿主解决方案是否会使攻击者更容易注入数据包，因为希望对等方出现在多个定位器上，或者出现在一组动态定位器上，可能会导致解决方案，即使存在入口过滤，也会使数据包注入更容易。
In the Internet today there are several ways for an attacker to use a redirection mechanism to launch DoS attacks that cannot easily be traced to the attacker. An example of this is to use protocols that cause reflection with or without amplification [PAXSON01].
在当今的互联网上，攻击者可以通过多种方式使用重定向机制发起DoS攻击，而这些攻击不容易追踪到攻击者。这方面的一个例子是使用导致反射的协议（有放大或无放大）[PAXSON01]。
Reflection without amplification can be accomplished by an attacker sending a TCP SYN packet to a well-known server with a spoofed source address; the resulting TCP SYN ACK packet will be sent to the spoofed source address.
攻击者通过向具有伪造源地址的知名服务器发送TCP SYN数据包，可以实现无放大的反射；生成的TCP SYN ACK数据包将被发送到伪造的源地址。
Devices on the path between two communicating entities can also launch DoS attacks. While such attacks might not be interesting today, it is necessary to understand them better in order to determine whether a multihoming solution might enable new types of DoS attacks.
两个通信实体之间路径上的设备也可以发起DoS攻击。虽然这种攻击在今天可能并不有趣，但有必要更好地了解它们，以便确定多宿主解决方案是否可能支持新类型的DoS攻击。
For example, today, if A is communicating with B, then A can try to overload the path from B to A. If TCP is used, A could do this by sending ACK packets for data that it has not yet received (but it suspects B has already sent) so that B would send at a rate that would cause persistent congestion on the path towards A. Such an attack would seem self-destructive since A would only make its own corner of the network suffer by overloading the path from the Internet towards A.
例如，今天，如果A正在与B通信，那么A可以尝试重载从B到A的路径。如果使用TCP，A可以通过发送ACK数据包来实现这一点，该数据包是它尚未接收到的（但它怀疑B已经发送了）因此，B的发送速率将导致通往a的路径持续拥塞。这种攻击似乎是自毁性的，因为a只会通过使从Internet通往a的路径过载而使其自己的网络角落遭受损失。
A more interesting case is if A is communicating with B and X is on the path between A and B, then X might be able to fool B to send packets towards A at a rate that is faster than A (and the path between A and X) can handle. For instance, if TCP is used, then X can craft TCP ACK packets claiming to come from A to cause B to use a congestion window that is large enough to potentially cause persistent congestion towards A. Furthermore, if X can suppress the packets from A to B, it can also prevent A from sending any explicit
更有趣的情况是，如果A与B通信，而X位于A与B之间的路径上，那么X可能会欺骗B以比A（以及A与X之间的路径）能够处理的速度更快的速率向A发送数据包。例如，如果使用TCP，则X可以制作声称来自A的TCP ACK数据包，以使B使用一个足够大的拥塞窗口，可能导致对A的持久拥塞。此外，如果X可以抑制从A到B的数据包，则还可以阻止A发送任何显式消息
"slow down" packets to B; that is, X can disable any flow or congestion control mechanism such as Explicit Congestion Notification [ECN]. Similar attacks can presumably be launched using protocols that carry streaming media by forging such a protocol's notion of acknowledgement and feedback.
将数据包“减速”到B；也就是说，X可以禁用任何流或拥塞控制机制，例如显式拥塞通知[ECN]。类似的攻击可能是通过使用通过伪造此类协议的确认和反馈概念来承载流媒体的协议发起的。
An attribute of this type of attack is that A will simply think that B is faulty since its flow and congestion control mechanisms don't seem to be working. Detecting that the stream of ACK packets is generated from X and not from A might be challenging, since the rate of ACK packets might be relatively low. This type of attack might not be common today because, in the presence of ingress filtering, it requires that X remain on the path in order to sustain the DoS attack. And in the absence of ingress filtering an attacker would need either to be present on the path initially and then move away, or to be able to perform the setup of the communication "blind", i.e., without seeing the return traffic (which, in the case of TCP, implies guessing the initial sequence number).
这种攻击的一个特点是，A会简单地认为B有故障，因为它的流量和拥塞控制机制似乎不起作用。检测ACK分组的流是从X而不是从A生成的可能是具有挑战性的，因为ACK分组的速率可能相对较低。这种类型的攻击在今天可能并不常见，因为在存在入口过滤的情况下，它要求X保持在路径上，以维持DoS攻击。在没有入口过滤的情况下，攻击者需要首先出现在路径上，然后离开，或者能够执行通信“盲”设置，即不看到返回流量（在TCP的情况下，这意味着猜测初始序列号）。
The danger is that the addition of multihoming redirection mechanisms might potentially remove the constraint that the attacker remain on the path. And with the current, no-multihoming support, using end-to-end strong security at a protocol level at (or below) this "ACK" processing would prevent this type of attack. But if a multihoming solution is provided underneath IPsec that prevention mechanism would potentially not exist.
危险在于，添加多主重定向机制可能会消除攻击者留在路径上的约束。在当前没有多宿主支持的情况下，在协议级别（或低于协议级别）使用端到端的强安全性，这种“ACK”处理将防止这种类型的攻击。但是，如果在IPsec下提供多宿主解决方案，则该预防机制可能不存在。
Thus, the challenge for multihoming solutions is to not create additional types of attacks in this area, or make existing types of attacks significantly easier.
因此，多宿主解决方案面临的挑战是不在该区域创建其他类型的攻击，或使现有类型的攻击更容易。
In today's Internet there is limited ability to track a host as it uses the Internet because in some cases, such as dialup connectivity, the host will acquire different IPv4 addresses each time it connects. However, with increasing use of broadband connectivity, such as DSL or cable, it is becoming more likely that the host will maintain the same IPv4 over time. Should a host move around in today's Internet, for instance, by visiting WiFi hotspots, it will be configured with a different IPv4 address at each location.
在今天的Internet中，在主机使用Internet时跟踪主机的能力有限，因为在某些情况下，例如拨号连接，主机每次连接时将获得不同的IPv4地址。然而，随着宽带连接（如DSL或电缆）的使用越来越多，随着时间的推移，主机越来越可能保持相同的IPv4。如果主机在今天的互联网上移动，例如访问WiFi热点，它将在每个位置配置不同的IPv4地址。
We also observe that a common practice in IPv4 today is to use some form of address translation, whether the site is multihomed or not. This effectively hides the identity of the specific host within a site; only the site can be identified based on the IP address.
我们还注意到，目前IPv4中的一种常见做法是使用某种形式的地址转换，无论站点是否为多址站点。这有效地隐藏了站点中特定主机的身份；只能根据IP地址识别站点。
In the cases where it is desirable to maintain connectivity as a host moves around, whether using layer 2 technology or Mobile IPv4, the IPv4 address will remain constant during the movement (otherwise the connections would break). Thus, there is somewhat of a choice today between seamless connectivity during movement and increased address privacy.
在希望在主机移动时保持连接的情况下，无论是使用第2层技术还是移动IPv4，IPv4地址都将在移动期间保持不变（否则连接将中断）。因此，在移动过程中的无缝连接和增加地址隐私之间，今天有一些选择。
Today when a site is multihomed to multiple ISPs, the common setup is that a single IP address prefix is used with all the ISPs. As a result it is possible to track that it is the same host that is communication via all ISPs.
今天，当一个站点被多个ISP多址连接时，常见的设置是所有ISP都使用一个IP地址前缀。因此，可以跟踪通过所有ISP进行通信的主机是否相同。
However, when a host (and not a site) is multi-homed to several ISPs (e.g., through a General Packet Radio Service (GPRS) connection and a wireless hot spot), the host is provided with different IP addresses on each interface. While the focus of the multihoming work is on site multihoming, should the solution also be applicable to host multihoming, the privacy impact needs to be considered for this case as well.
但是，当主机（而不是站点）与多个ISP（例如，通过通用分组无线服务（GPRS）连接和无线热点）进行多址连接时，主机在每个接口上都有不同的IP地址。虽然多宿主工作的重点是现场多宿主，但如果该解决方案也适用于主机多宿主，则在这种情况下也需要考虑隐私影响。
IPv6 stateless address auto-configuration facilitates IP address management, but raises some concerns since the Ethernet address is encoded in the low-order 64 bits of the IPv6 address. This could potentially be used to track a host as it moves around the network, using different ISPs, etc. IPv6 specifies temporary addresses [RFC3041], which allow applications to control whether they need long-lived IPv6 addresses or desire the improved privacy of using temporary addresses.
IPv6无状态地址自动配置有助于IP地址管理，但会引起一些问题，因为以太网地址是以IPv6地址的低位64位编码的。这可能用于跟踪主机在网络中的移动，使用不同的ISP等。IPv6指定临时地址[RFC3041]，允许应用程序控制是否需要长寿命的IPv6地址或希望改善使用临时地址的隐私。
Given that there is no address privacy in site multihoming setups today, the primary concerns for the "do no harm" criteria are to ensure that hosts that move around still have the same ability as in today's Internet to choose between seamless connectivity and improved address privacy, and also that the introduction of multihoming support should still provide the same ability as we have in IPv6 with temporary addresses.
鉴于目前的站点多宿主设置中没有地址隐私，“无害”标准的主要关注点是确保移动的主机仍然具有与当今互联网中相同的能力，可以在无缝连接和改进的地址隐私之间进行选择，此外，引入多主支持应该仍然能够提供与IPv6中使用临时地址时相同的功能。
When considering privacy threats, it makes sense to distinguish between attacks made by on-path entities observing the packets flying by, and attacks by the communicating peer. It is probably feasible to prevent on-path entities from correlating the multiple IP addresses of the host; but the fact that the peer needs to be told multiple IP addresses in order to be able to switch to using different addresses, when communication fails, limits the ability of the host to prevent correlating its multiple addresses. However, using multiple pseudonyms for a host should be able address this case.
在考虑隐私威胁时，有必要区分观察数据包飞过的路径实体发起的攻击和通信对等方发起的攻击。防止路径实体关联主机的多个IP地址可能是可行的；但是，当通信失败时，需要告知对等方多个IP地址，以便能够切换到使用不同的地址，这一事实限制了主机防止其多个地址关联的能力。但是，为主机使用多个假名应该能够解决这种情况。
This section documents the additional attacks that have been discovered that result from an architecture where hosts can change their topological connection to the network in the middle of a transport session without interruption. This discussion is again framed in the context where the topological locators may be independent of the host identifiers used by the transport and application layer protocols. Some of these attacks may not be applicable if traditional addresses are used. This section assumes that each host has multiple locators and that there is some mechanism for determining the locators for a correspondent host. We do not assume anything about the properties of these mechanisms. Instead, this list will serve to help us derive the properties of these mechanisms that will be necessary to prevent these redirection attacks.
本节描述了由一个体系结构导致的附加攻击，其中主机可以在没有中断的传输会话中间改变其拓扑连接到网络。本讨论再次在拓扑定位器可能独立于传输和应用层协议所使用的主机标识符的上下文中进行。如果使用传统地址，其中一些攻击可能不适用。本节假设每个主机都有多个定位器，并且存在某种机制来确定对应主机的定位器。我们对这些机制的性质不作任何假设。相反，此列表将帮助我们导出这些机制的属性，这些属性对于防止这些重定向攻击是必要的。
Depending on the purpose of the redirection attack, we separate the attacks into several different types.
根据重定向攻击的目的，我们将攻击分为几种不同的类型。
An attacker might want to receive the flow of packets, for instance to be able to inspect and/or modify the payload or to be able to apply cryptographic analysis to cryptographically protected payload, using redirection attacks.
攻击者可能希望接收数据包流，例如能够检查和/或修改有效负载，或者能够使用重定向攻击对受密码保护的有效负载应用密码分析。
Note that such attacks are always possible today if an attacker is on the path between two communicating parties, and a multihoming solution can't remove that threat. Hence, the bulk of these concerns relate to off-path attackers.
请注意，如果攻击者位于两个通信方之间的路径上，并且多宿主解决方案无法消除该威胁，则此类攻击在今天始终是可能的。因此，这些问题大多与路径外攻击者有关。
This might be viewed as the "classic" redirection attack.
这可能被视为“经典”重定向攻击。
While A and B are communicating X might send packets to B and claim: "Hi, I'm A, send my packets to my new location." where the location is really X's location.
当A和B进行通信时，X可能会向B发送数据包并声明：“嗨，我是A，将我的数据包发送到我的新位置。”其中位置实际上是X的位置。
"Standard" solutions to this include requiring that the host requesting redirection somehow be verified to be the same host as the initial host that established communication. However, the burdens of such verification must not be onerous, or the redirection requests themselves can be used as a DoS attack.
对此的“标准”解决方案包括要求以某种方式验证请求重定向的主机是否与建立通信的初始主机相同。但是，这种验证的负担不能太重，否则重定向请求本身就可以被用作DoS攻击。
To prevent this type of attack, a solution would need some mechanism that B can use to verify whether a locator belongs to A before B starts using that locator, and be able to do this when multiple locators are assigned to A.
为了防止这种类型的攻击，解决方案需要一些机制，B可以使用这些机制在B开始使用定位器之前验证定位器是否属于a，并且在为a分配多个定位器时能够做到这一点。
The term "time-shifting attack" is used to describe an attacker's ability to perform an attack after no longer being on the path. Thus, the attacker would have been on the path at some point in time, snooping and/or modifying packets; and later, when the attacker is no longer on the path, it launches the attack.
术语“时移攻击”用于描述攻击者在不再在路径上后执行攻击的能力。因此，攻击者可能在某个时间点处于路径上，窥探和/或修改数据包；然后，当攻击者不再在路径上时，它会发起攻击。
In the current Internet, it is not possible to perform such attacks to redirect packets. But for some time after moving away, the attacker can cause a DoS attack, e.g., by leaving a bogus ARP entry in the nodes on the path, or by forging TCP Reset packets based on having seen the TCP Initial Sequence Numbers when it was on the path.
在当前的互联网上，不可能执行此类攻击来重定向数据包。但在离开后的一段时间内，攻击者可能会导致DoS攻击，例如，在路径上的节点中留下虚假的ARP条目，或者根据在路径上看到的TCP初始序列号伪造TCP重置数据包。
It would be reasonable to require that a multihoming solution limit the ability to redirect and/or DoS traffic to a few minutes after the attacker has moved off the path.
要求多宿主解决方案将重定向和/或DoS流量的能力限制在攻击者离开路径后几分钟内是合理的。
This is a variant of the above where the attacker "installs" itself before communication starts.
这是上面的一个变体，攻击者在通信开始之前“安装”自己。
For example, if the attacker X can predict that A and B will communicate in the (near) future, then the attacker can tell B: "Hi, I'm A and I'm at this location". When A later tries to communicate with B, will B believe it is really A?
例如，如果攻击者X可以预测A和B将在（不久的）将来通信，那么攻击者可以告诉B：“嗨，我是A，我在这个位置”。当A后来试图与B沟通时，B会相信它真的是A吗？
If the solution to the classic redirection attack is based on "prove you are the same as initially", then A will fail to prove this to B because X initiated communication.
如果经典重定向攻击的解决方案基于“证明您与最初相同”，那么A将无法向B证明这一点，因为X发起了通信。
Depending on details that would be specific to a proposed solution, this type of attack could either cause redirection (so that the packets intended for A will be sent to X) or they could cause DoS (where A would fail to communicate with B since it can't prove it is the same host as X).
根据特定于建议的解决方案的详细信息，这种类型的攻击可能会导致重定向（以便用于a的数据包将被发送到X）或导致拒绝服务（其中a将无法与B通信，因为它无法证明它与X是同一主机）。
To prevent this attack, the verification of whether a locator belongs to the peer cannot simply be based on the first peer that made contact.
为了防止这种攻击，定位器是否属于对等方的验证不能简单地基于进行联系的第一个对等方。
While the multihoming problem doesn't inherently imply any topological movement, it is useful to also consider the impact of site renumbering in combination with multihoming. In that case, the set of locators for a host will change each time its site renumbers, and, at some point in time after a renumbering event, the old locator prefix might be reassigned to some other site.
虽然多归属问题本身并不意味着任何拓扑运动，但也有助于考虑站点重新编号与多宿主相结合的影响。在这种情况下，主机的定位器集将在其站点每次重新编号时更改，并且在重新编号事件之后的某个时间点，旧的定位器前缀可能会重新分配给其他站点。
This potentially give an attacker the ability to replay whatever protocol mechanism was used to inform a host of a peer's locators so that the host would incorrectly be led to believe that the old locator (set) should be used even long after a renumbering event. This is similar to the risk of replay of Binding Updates in [MIPv6], but the time constant is quite different; Mobile IPv6 might see movements every second while site renumbering, followed by reassignment of the site locator prefix, might be a matter of weeks or months.
这可能使攻击者能够重播用于通知主机对等方定位器的任何协议机制，从而使主机错误地认为即使在重新编号事件发生很久之后也应该使用旧定位器（set）。这类似于[MIPv6]中的绑定更新重播风险，但时间常数却大不相同；移动IPv6可能每秒都会出现移动，而站点重新编号，然后重新分配站点定位器前缀可能需要几周或几个月的时间。
To prevent such replay attacks, the protocol used to verify which locators can be used with a particular identifier needs some replay protection mechanism.
为了防止此类重播攻击，用于验证哪些定位器可以与特定标识符一起使用的协议需要某种重播保护机制。
Also, in this space one needs to be concerned about potential interaction between such replay protection and the administrative act of reassignment of a locator. If the identifier and locator relationship is distributed across the network, one would need to make sure that the old information has been completely purged from the network before any reassignment. Note that this does not require an explicit mechanism. This can instead be implemented by locator reuse policy and careful timeouts of locator information.
此外，在这方面，还需要关注此类重播保护与重新分配定位器的行政行为之间的潜在交互作用。如果标识符和定位器关系分布在网络中，则需要确保在任何重新分配之前，旧信息已从网络中完全清除。请注意，这不需要明确的机制。这可以通过定位器重用策略和定位器信息的仔细超时来实现。
This is also a variant of the classic redirection attack. The difference is that the new location is a locator that is nonexistent or unreachable. Thus, the effect is that sending packets to the new locator causes the packets to be dropped by the network somewhere.
这也是经典重定向攻击的一种变体。不同之处在于，新位置是一个不存在或无法访问的定位器。因此，其效果是向新定位器发送分组导致网络在某处丢弃分组。
One would expect that solutions that prevent the previous redirection attacks would prevent this attack as a side effect, but it makes sense to include this attack here for completeness. Mechanisms that prevented a redirection attack to the attacker should also prevent redirection to a black hole.
可以预期，防止以前的重定向攻击的解决方案将防止此攻击作为副作用，但为了完整性，在此处包含此攻击是有意义的。防止攻击者重定向攻击的机制也应防止重定向到黑洞。
An attacker can use the ability to perform redirection to cause overload on an unrelated third party. For instance, if A and B are communicating, then the attacker X might be able to convince A to send the packets intended for B to some third node C. While this might seem harmless at first, since X could just flood C with packets directly, there are a few aspects of these attacks that cause concern.
攻击者可以利用执行重定向的功能在不相关的第三方上造成过载。例如，如果A和B正在通信，那么攻击者X可能会说服A将针对B的数据包发送到某个第三节点C。虽然这在一开始似乎是无害的，但由于X可能会直接向C发送数据包，因此这些攻击的一些方面会引起关注。
The first is that the attacker might be able to completely hide its identity and location. It might suffice for X to send and receive a few packets to A in order to perform the redirection, and A might not retain any state on who asked for the redirection to C's location. Even if A had retained such state, that state would probably not be easily available to C, thus C can't determine who the attacker was once C has become the victim of a DoS attack.
首先，攻击者可能完全隐藏其身份和位置。X向a发送和接收一些数据包以执行重定向可能就足够了，而a可能不会保留请求重定向到C位置的人的任何状态。即使A保留了这样的状态，C也很可能无法轻松获得该状态，因此，一旦C成为DoS攻击的受害者，C也无法确定攻击者是谁。
The second concern is that, with a direct DoS attack from X to C, the attacker is limited by the bandwidth of its own path towards C. If the attacker can fool another host, such as A, to redirect its traffic to C, then the bandwidth is limited by the path from A towards C. If A is a high-capacity Internet service and X has slow (e.g., dialup) connectivity, this difference could be substantial. Thus, in effect, this could be similar to packet amplifying reflectors in [PAXSON01].
第二个问题是，对于从X到C的直接DoS攻击，攻击者受到其自身通向C的路径带宽的限制。如果攻击者可以欺骗另一台主机（如a）将其流量重定向到C，则带宽受到从a到C的路径的限制。如果a是高容量Internet服务，且X速度较慢（例如拨号）连接，这种差异可能是巨大的。因此，实际上，这可能类似于[PAXSON01]中的包放大反射器。
The third, and final concern, is that if an attacker only need a few packets to convince one host to flood a third party, then it wouldn't be hard for the attacker to convince lots of hosts to flood the same third party. Thus, this could be used for Distributed Denial-of-Service attacks.
第三个也是最后一个问题是，如果攻击者只需要几个数据包就可以说服一台主机向第三方发送洪水，那么攻击者就不难说服许多主机向同一第三方发送洪水。因此，这可用于分布式拒绝服务攻击。
A third party DoS attack might be against the resources of a particular host (i.e., C in the example above), or it might be against the network infrastructure towards a particular IP address prefix, by overloading the routers or links even though there is no host at the address being targeted.
第三方DoS攻击可能是针对特定主机的资源（即，上述示例中的C），也可能是针对特定IP地址前缀的网络基础设施，通过使路由器或链路过载，即使目标地址没有主机。
In today's Internet, the ability to perform this type of attack is quite limited. In order for the attacker to initiate communication, it will in most cases need to be able to receive some packets from the peer (the potential exception being techniques that combine this with TCP-sequence-number-guessing techniques). Furthermore, to the extent that parts of the Internet uses ingress filtering [INGRESS], even if the communication could be initiated, it wouldn't be possible to sustain it by sending ACK packets with spoofed source addresses from an off-path attacker.
在今天的互联网上，执行此类攻击的能力非常有限。为了让攻击者发起通信，在大多数情况下，攻击者需要能够从对等方接收一些数据包（潜在的例外是将此技术与TCP序列号猜测技术相结合的技术）。此外，由于部分互联网使用入口过滤[ingress]，即使可以启动通信，也不可能通过从非路径攻击者发送带有伪造源地址的ACK数据包来维持通信。
If this type of attack can't be prevented, there might be mitigation techniques that can be employed. For instance, in the case of TCP a partial defense can be constructed by having TCP slow-start be triggered when the destination locator changes. (Folks might argue that, separately from security, this would be the correct action for congestion control since TCP might not have any congestion-relation information about the new path implied by the new locator.) Presumably the same approach can be applied to other transport protocols that perform different forms of (TCP-friendly) congestion control, even though some of them might not adapt as rapidly as TCP. But since all congestion-controlled protocols probably need to have some reaction to the path change implied by a locator change, it makes sense to think about 3rd party DoS attacks when designing how the specific transport protocols should react to a locator change. However, this would only be a partial solution since it would probably take several packets and roundtrips before the transport protocol would stop transmitting; thus, an attacker could still use this as a reflector with packet amplification. Thus, the multihoming mechanism probably needs some form of defense against third party DoS attacks, in addition to the help we can get from the transport protocols.
如果无法阻止这种类型的攻击，可能会采用缓解技术。例如，在TCP的情况下，可以通过在目标定位器更改时触发TCP慢速启动来构建部分防御。（人们可能会认为，与安全性不同，这将是拥塞控制的正确操作，因为TCP可能没有关于新定位器暗示的新路径的任何拥塞关系信息。）大概相同的方法可以应用于执行不同形式（TCP友好）的其他传输协议拥塞控制，即使其中一些可能无法像TCP那样快速适应。但是，由于所有拥塞控制协议可能都需要对定位器更改所隐含的路径更改做出某种反应，因此在设计特定传输协议如何应对定位器更改时，考虑第三方DoS攻击是有意义的。然而，这只是一个部分解决方案，因为在传输协议停止传输之前，可能需要几个数据包和往返；因此，攻击者仍然可以将其用作数据包放大的反射器。因此，除了可以从传输协议中获得帮助外，多宿主机制可能还需要某种形式的防御措施来抵御第三方DoS攻击。
Assume that X is on a slow link anywhere in the Internet. B is on a fast link (gigabits; e.g., a media server) and A is the victim.
假设X在互联网的任何地方都处于慢速链接上。B在快速链路上（千兆位；例如媒体服务器），a是受害者。
X could flood A directly but is limited by its low bandwidth. If X can establish communication with B, ask B to send it a high-speed media stream, then X can presumably fake out the "acknowledgements/feedback" needed for B to blast out packets at full speed. So far, this only hurts X and the path between X and the Internet. But if X could also tell B "I'm at A's locator", then X has effectively used this redirection capability in multihoming to amplify its DoS capability, which would be a source of concern.
X可以直接淹没A，但受到其低带宽的限制。如果X可以与B建立通信，要求B向其发送高速媒体流，那么X可能会伪造B全速发送数据包所需的“确认/反馈”。到目前为止，这只会伤害X和X与Internet之间的路径。但如果X也能告诉B“我在A的定位器上”，那么X在多宿定位中有效地利用了这种重定向功能来增强其DoS功能，这将是一个令人担忧的问题。
One could envision rather simple techniques to prevent such attacks. For instance, before sending to a new peer locator, perform a clear text exchange with the claimed new locator of the form "Are you X?" resulting in "Yes, I'm X.". This would suffice for the simplest of attacks. However, as we will see below, more sophisticated attacks are possible.
人们可以设想一些相当简单的技术来防止这种攻击。例如，在发送到新的对等定位器之前，与声明的新定位器进行明文交换，交换形式为“你是X吗？”导致“是，我是X”。这对于最简单的攻击就足够了。然而，正如我们将在下面看到的，更复杂的攻击是可能的。
The scenario is as above, but, in addition, the attacker X has a friend Y on the path between A and B:
场景如上所述，但另外，攻击者X在a和B之间的路径上有一个朋友Y：
----- ----- -----
| A |--------| Y |--------| B |
----- ----- -----
/
/
/
/
/
/
-----
| X |
-----
----- ----- -----
| A |--------| Y |--------| B |
----- ----- -----
/
/
/
/
/
/
-----
| X |
-----
With the simple solution suggested in the previous section, all Y might need to do is fake a response to the "Are you X?" packet, and after that point in time Y might not be needed; X could potentially sustain the data flow towards A by generating the ACK packets. Thus, it would be even harder to detect the existence of Y.
使用上一节中建议的简单解决方案，Y可能需要做的就是伪造对“AreYou X？”数据包的响应，在该时间点之后，Y可能不再需要；X可以通过生成ACK分组来潜在地维持朝向A的数据流。因此，检测Y的存在将更加困难。
Furthermore, if X is not the actual end system but an attacker between some node C and B, then X can claim to be C, and no finger can be pointed at X either:
此外，如果X不是实际的终端系统，而是某个节点C和B之间的攻击者，则X可以声称是C，并且也不能将手指指向X：
----- ----- -----
| A |--------| Y |--------| B |
----- ----- -----
/
/
/
/
/
/
----- -----
| C |-------| X |
----- -----
----- ----- -----
| A |--------| Y |--------| B |
----- ----- -----
/
/
/
/
/
/
----- -----
| C |-------| X |
----- -----
Thus, with two attackers on different paths, there might be no trace of who did the redirection to the 3rd party once the redirection has taken place.
因此，如果两个攻击者位于不同的路径上，则在重定向发生后，可能不存在谁重定向到第三方的痕迹。
A specific case of this is when X=Y, and X is located on the same LAN as B.
这种情况的一种特殊情况是X=Y，并且X与B位于同一LAN上。
A potential way to make such attacks harder would be to use the last received (and verified) source locator as the destination locator. That way, when X sends the ACK packets (whether it claims to be X or C) the result would be that the packet flow from B would switch back towards X/C, which would result in an attack similar to what can be performed in today's Internet.
使此类攻击更加困难的一种潜在方法是使用最后接收（并验证）的源定位器作为目标定位器。这样，当X发送ACK数据包（无论它声称是X还是C）时，结果将是来自B的数据包流将切换回X/C，这将导致类似于当今互联网上可以执行的攻击。
Another way to make such attacks harder would be to perform periodic verifications that the peer is available at the locator, instead of just one when the new locator is received.
另一种使此类攻击更加困难的方法是定期验证对等方在定位器处是否可用，而不是在接收到新定位器时仅验证一次。
A third way that a multihoming solution might address this is to ensure that B will only accept locators that can be authenticated to be synonymous with the original correspondent. It must be possible to securely ensure that these locators form an equivalence class. So in the first example, not only does X need to assert that it is A, but A needs to assert that it is X.
多宿主解决方案可能解决此问题的第三种方法是确保B只接受可以验证为与原始通信者同义的定位器。必须能够安全地确保这些定位器形成一个等价类。所以在第一个例子中，不仅X需要声明它是A，而且A需要声明它是X。
The multihoming solution space does not only affect the destination of packets; it also raises the question from which sources packets should be accepted. It is possible to build a multihoming solution that allows traffic to be recognized as coming from the same peer even if there is a previously unknown locator present in the source address field. The question is whether we want to allow packets from unverified sources to be passed on to transport and application layer protocols.
多归属解空间不仅影响数据包的目的地；它还提出了一个问题，即应该从哪些来源接受数据包。可以构建一个多归属解决方案，该解决方案允许将流量识别为来自同一对等方，即使源地址字段中存在以前未知的定位器。问题是我们是否希望允许来自未经验证来源的数据包传递到传输层和应用层协议。
In the current Internet, an attacker can't inject packets with arbitrary source addresses into a session if there is ingress filtering present, so allowing packets with unverified sources in a multihoming solution would fail our "no worse than what we have now" litmus test. However, given that ingress filtering deployment is far from universal and ingress filtering typically wouldn't prevent spoofing of addresses in the same subnet, requiring rejecting packets from unverified locators might be too stringent.
在当前的互联网中，如果存在入口过滤，攻击者无法将具有任意源地址的数据包注入会话，因此在多主解决方案中允许具有未验证源的数据包将失败我们的“不比现在更糟”石蕊测试。然而，由于入口过滤部署远不是通用的，并且入口过滤通常不会防止对同一子网中的地址进行欺骗，因此要求拒绝来自未经验证的定位器的数据包可能过于严格。
An example of the current state are the ability to inject RST packets into existing TCP connections. When there is no ingress filtering in the network, this is something that the TCP endpoints need to sort out themselves. However, deploying ingress filtering helps in today's Internet since an attacker is limited in the set of source addresses it can use.
当前状态的一个示例是将RST数据包注入现有TCP连接的能力。当网络中没有入口过滤时，TCP端点需要自行解决这一问题。然而，在当今的互联网上，部署入口过滤有助于解决问题，因为攻击者只能使用有限的源地址集。
A factor to take into account to determine the "requirement level" for this is that when IPsec is used on top of the multihoming solution, then IPsec will reject such spoofed packets. (Note that this is different than in the redirection attack cases where even with IPsec an attacker could potentially cause a DoS attack.)
确定“需求级别”时需要考虑的一个因素是，当在多主解决方案上使用IPsec时，IPsec将拒绝此类伪造数据包。（请注意，这与重定向攻击情况不同，在重定向攻击情况下，即使使用IPsec，攻击者也可能导致DoS攻击。）
There might also be a middle ground where arbitrary attackers are prevented from injecting packets by using the SCTP verification tag type of approach [SCTP]. (This is a clear-text tag which is sent to the peer which the peer is expected to include in each subsequent packet.) Such an approach doesn't prevent packet injection from on-path attackers (since they can observe the verification tag), but neither does ingress filtering.
还可能存在一个中间地带，通过使用SCTP验证标记类型的方法[SCTP]，防止任意攻击者注入数据包。（这是一个明文标记，发送给对等方，该对等方希望在每个后续数据包中包含该标记。）这种方法不能阻止路径上攻击者的数据包注入（因为他们可以观察验证标记），但入口过滤也不能。
While introducing identifiers can be helpful by providing ways to identify hosts across events when its IP address(es) might change, there is a risk that such mechanisms can be abused to track the identity of the host over long periods of time, whether using the same (set of) ISP(s) or moving between different network attachment points. Designers of solutions to multihoming need to be aware of this concern.
当主机的IP地址可能发生变化时，通过提供跨事件识别主机的方法，引入标识符可能会有所帮助，但这样的机制可能被滥用，以便长时间跟踪主机的身份，无论是使用相同（一组）ISP还是在不同的网络连接点之间移动。多宿主解决方案的设计者需要意识到这一点。
Introducing the multihoming capability inherently implies that the communicating peers need to know multiple locators for each other in order to be resilient to failures of some paths/locators. In addition, if the multihoming signaling protocol doesn't provide privacy, it might be possible for 3rd parties on the path to discover many or all the locators assigned to a host, which would increase the privacy exposure compared to a multihomed host today.
引入多主功能本质上意味着通信对等方需要相互了解多个定位器，以便能够适应某些路径/定位器的故障。此外，如果多宿信令协议不提供隐私，则路径上的第三方可能会发现分配给主机的许多或所有定位器，这将比目前的多宿主机增加隐私暴露。
For instance, a solution could address this by allowing each host to have multiple identifiers at the same time and perhaps even changing the set of identifiers that are used over time. Such an approach could be analogous to what is done for IPv6 addresses in [RFC3041].
例如，解决方案可以通过允许每个主机同时具有多个标识符，甚至可能随着时间的推移更改所使用的标识符集来解决这一问题。这种方法可以类似于[RFC3041]中对IPv6地址所做的操作。
Different multihoming solutions might approach the problem at different layers in the protocol stack. For instance, there have been proposals for a shim layer inside IP, as well as transport layer approaches. The former would have the capability to redirect an IP address while the latter might be constrained to only redirect a single transport connection. This difference might be important when it comes to understanding the security impact.
不同的多宿主解决方案可能会在协议栈的不同层处理该问题。例如，有人建议在IP内部使用垫片层，也有人建议使用传输层方法。前者能够重定向IP地址，而后者可能仅限于重定向单个传输连接。在理解安全影响时，这种差异可能很重要。
For instance, premeditated attacks might have quite different impact in the two cases. In an IP-based multihoming solution a successful premeditated redirection could be due to the attacker connecting to a server and claiming to be 'A', which would result in the server retaining some state about 'A', which it received from the attacker. Later, when the real 'A' tries to connect to the server, the existence of this state might mean that 'A' fails to communicate, or that its packets are sent to the attacker. But if the same scenario is applied to a transport-layer approach, then the state created due to the attacker would perhaps be limited to the existing transport connection. Thus, while this might prevent the real 'A' from connecting to the server while the attacker is connected (if they happen to use the same transport port number), most likely it would not affect 'A's ability to connect after the attacker has disconnected.
例如，在这两种情况下，有预谋的袭击可能会产生完全不同的影响。在基于IP的多宿主解决方案中，成功的有预谋的重定向可能是由于攻击者连接到服务器并声称为“a”，这将导致服务器保留从攻击者处收到的关于“a”的某些状态。稍后，当真实的“A”尝试连接到服务器时，此状态的存在可能意味着“A”无法通信，或者其数据包被发送给攻击者。但是，如果将相同的场景应用于传输层方法，则由于攻击者创建的状态可能仅限于现有的传输连接。因此，虽然这可能会阻止真正的“A”在攻击者连接时连接到服务器（如果它们碰巧使用相同的传输端口号），但很可能不会影响“A”在攻击者断开连接后的连接能力。
A particular aspect of the granularity question is the direction question: will the created state be used for communication in the reverse direction of the direction when it was created? For instance, if the attacker 'X' suspects that 'A' will connect to 'B' in the near future, can X connect to A and claim to be B, and then have that later make A connect to the attacker instead of to the real B?
粒度问题的一个特殊方面是方向问题：创建的状态是否将用于与创建时方向相反的通信？例如，如果攻击者“X”怀疑“A”将在不久的将来连接到“B”，那么X是否可以连接到A并声称是B，然后让后者稍后连接到攻击者而不是真正的B？
Note that transport layer approaches are limited to the set of "transport" protocols that the implementation makes aware of multihoming. In many cases there would be "transport" protocols that are unknown to the multihoming capability of the system, such as applications built on top of UDP. To understand the impact of the granularity question on the security, one would also need to understand how such applications/protocols would be handled.
请注意，传输层方法仅限于一组“传输”协议，这些协议是实现中意识到的多宿主协议。在许多情况下，系统的多主功能不知道“传输”协议，例如构建在UDP之上的应用程序。要了解粒度问题对安全性的影响，还需要了解如何处理此类应用程序/协议。
A property of transport granularity is that the amount of work performed by a legitimate host is proportional to the number of transport connections it creates that uses the multihoming support, since each such connection would require some multihoming signaling. And the same is true for the attacker. This means that an attacker could presumably do a premeditated attack for all TCP connections to port 80 from A to B, by setting up 65,536 (for all TCP source port numbers) connections to server B and causing B to think those connections should be directed to the attacker and keeping those TCP connections open. Any attempt to make legitimate communication more efficient (e.g., by being able to signal for multiple transport connections at a time) would provide as much relative benefit for an attacker as the legitimate hosts.
传输粒度的一个特性是，合法主机执行的工作量与它创建的使用多归属支持的传输连接的数量成正比，因为每个这样的连接都需要一些多归属信令。攻击者也是如此。这意味着攻击者可能会对从a到B的端口80的所有TCP连接进行有预谋的攻击，方法是设置到服务器B的65536（所有TCP源端口号）连接，使B认为这些连接应该指向攻击者，并保持这些TCP连接打开。任何使合法通信更高效的尝试（例如，通过一次能够为多个传输连接发送信号）都将为攻击者提供与合法主机同等的相对好处。
The issue isn't only about the space (granularity), but also about the lifetime component in the results of a multihoming request. In a transport-layer approach, the multihoming state would presumably be destroyed when the transport state is deleted as part of closing the connection. But an IP-layer approach would have to rely on some timeout or garbage collection mechanisms, perhaps combined with some new explicit signaling, to remove the multihoming state. The coupling between the connection state and multihoming state in the transport-layer approach might make it more expensive for the attacker, since it needs to keep the connections open.
问题不仅与空间（粒度）有关，还与多宿主请求结果中的生存期组件有关。在传输层方法中，当作为关闭连接的一部分删除传输状态时，多主状态可能会被破坏。但是IP层方法必须依赖于一些超时或垃圾收集机制，可能与一些新的显式信令相结合，以消除多宿主状态。传输层方法中连接状态和多宿主状态之间的耦合可能会使攻击者付出更高的代价，因为它需要保持连接打开。
In summary, there are issues we don't yet understand well about granularity and reuse of the multihoming state.
总之，关于多宿主状态的粒度和重用，我们还没有很好地理解一些问题。
In the case when nothing moves around, we have a reasonable understanding of the security requirements. Something that is on the path can be a MITM in today's Internet, and a multihoming solution doesn't need to make that aspect any more secure.
在没有任何移动的情况下，我们对安全要求有一个合理的理解。在今天的互联网上，正在发展的东西可能是一个MITM，而多主解决方案不需要使这方面更加安全。
But it is more difficult to understand the requirements when hosts are moving around. For instance, a host might be on the path for a short moment in time by driving by an 802.11 hotspot. Would we or would we not be concerned if such a drive-by (which many call a "time-shifting" attack) would result in the temporarily on-path host being able to act as a MITM for future communication? Depending on the solution, this might be possible if the attacker causes a multihoming state to be created in various peer hosts while the attacker was on the path, and that state remained in the peers for some time.
但当主机四处移动时，更难理解需求。例如，主机可能通过802.11热点在路径上停留了很短时间。我们是否会担心这种路过（许多人称之为“时间转移”攻击）是否会导致临时路径主机能够充当未来通信的MITM？根据解决方案的不同，如果攻击者在路径上时导致在多个对等主机中创建多宿主状态，并且该状态在对等主机中保留一段时间，则可能会出现这种情况。
The answer to this question doesn't seem to be obvious even in the absence of any new multihoming support. We don't have much experience with hosts moving around that are able to attack things as they move. In Mobile IPv6 [MIPv6] a conservative approach was taken that limits the effect of such drive-by attacks to the maximum lifetime of the binding, which is set to a few minutes.
即使在没有任何新的多宿支持的情况下，这个问题的答案似乎也不明显。我们没有太多的经验，主机在移动时能够攻击东西。在移动IPv6[MIPv6]中，采取了一种保守的方法，将这种驱动攻击的影响限制在绑定的最长生存期内（设置为几分钟）。
With multihoming support the issue gets a bit more complicated because we explicitly want to allow a host to be present at multiple locators at the same time. Thus, there might be a need to distinguish between the host moving between different locators, and the host sending packets with different source locators because it is present at multiple locators without any topological movement.
有了多宿主支持，问题就变得更复杂了，因为我们明确地希望允许主机同时出现在多个定位器上。因此，可能需要区分在不同定位器之间移动的主机和发送具有不同源定位器的分组的主机，因为它存在于多个定位器上而没有任何拓扑移动。
Note that the multihoming solutions that have been discussed range from such "drive-by" attacks being impossible (for instance, due to a strong binding to a separate identifier as in HIP, or due to reliance on the relative security of the DNS for forward plus reverse lookups in NOID), to systems that are first-come/first-serve (WIMP being an example with a separate ID space, a MAST approach with a PBK being an example without a separate ID space) that allow the first host that uses an ID/address to claim it without any time limit.
请注意，已经讨论过的多主解决方案的范围从不可能的“驱动”攻击（例如，由于与HIP中的单独标识符的强绑定，或由于在NOID中依赖DNS的相对安全性进行前向和反向查找）到先到先服务的系统（WIMP是一个具有单独ID空间的示例，而PBK是一个没有单独ID空间的示例）允许使用ID/地址的第一台主机在没有任何时间限制的情况下声明它。
The protocol mechanisms added as part of a multihoming solution shouldn't introduce any new DoS in the mechanisms themselves. In particular, care must be taken not to:
作为多宿主解决方案的一部分添加的协议机制本身不应引入任何新的DoS。特别是，必须注意不要：
- create state on the first packet in an exchange, since that could result in state consumption attacks similar to the TCP SYN flooding attack.
- 在交换中的第一个数据包上创建状态，因为这可能导致类似于TCP SYN洪泛攻击的状态消耗攻击。
- perform much work on the first packet in an exchange (such as expensive verification)
- 对交换中的第一个数据包执行大量工作（例如昂贵的验证）
There is a potential chicken-and-egg problem here, because potentially one would want to avoid doing work or creating state until the peer has been verified, but verification will probably need some state and some work to be done. Avoiding any work does not seem possible, but good protocol design can often delay state creation until verification has been completed.
这里有一个潜在的鸡和蛋的问题，因为在对对等方进行验证之前，可能希望避免执行工作或创建状态，但是验证可能需要一些状态和一些工作来完成。避免任何工作似乎是不可能的，但好的协议设计通常可以延迟状态创建，直到验证完成。
A possible approach that solutions might investigate is to defer verification until there appears to be two different hosts (or two different locators for the same host) that want to use the same identifier. In such a case one would need to investigate whether a combination of impersonation and DoS attack can be used to prevent the discovery of the impersonation.
解决方案可能研究的一种可能方法是推迟验证，直到有两个不同的主机（或同一主机的两个不同定位器）想要使用相同的标识符。在这种情况下，需要调查是否可以使用模拟和DoS攻击的组合来防止发现模拟。
Another possible approach is to first establish communications, and then perform verification in parallel with normal data transfers. Redirection would only be permitted after verification was complete, but prior to that event, data could transfer in a normal, non-multihomed manner.
另一种可能的方法是首先建立通信，然后与正常数据传输并行执行验证。只有在验证完成后才允许重定向，但在此事件之前，数据可以以正常的非多址方式传输。
Finally, the new protocol mechanisms should be protected against spoofed packets, at least from off-path sources, and replayed packets.
最后，新的协议机制应该受到保护，以防止伪造的数据包，至少是来自非路径源的数据包和重播的数据包。
In section 3, the document presented existing protocol-based redirection attacks. But there are also non-protocol redirection attacks. An attacker that can gain physical access to one of
在第3节中，该文档介绍了现有的基于协议的重定向攻击。但也存在非协议重定向攻击。可以物理访问以下内容之一的攻击者：
- the copper/fiber somewhere in the path,
- 路径中某处的铜/光纤，
- a router or L2 device in the path, or
- 路径中的路由器或L2设备，或
- one of the end systems
- 终端系统之一
can also redirect packets. This could be possible, for instance, by physical break-ins or by bribing staff that have access to the physical infrastructure. Such attacks are out of scope of this discussion, but are worth keeping in mind when looking at the cost for an attacker to exploit any protocol-based attacks against multihoming solutions; making protocol-based attacks much more expensive to launch than break-ins/bribery type of attacks might be overkill.
还可以重定向数据包。这可能是可能的，例如，通过物理入侵或贿赂有权访问物理基础设施的员工。此类攻击超出了本文讨论的范围，但在考虑攻击者利用任何基于协议的攻击攻击多宿主解决方案的成本时，值得记住；使基于协议的攻击比入室盗窃/贿赂类型的攻击更昂贵可能是杀伤力过大。
This document was originally produced by a MULTI6 design team consisting of (in alphabetical order): Iljitsch van Beijnum, Steve Bellovin, Brian Carpenter, Mike O'Dell, Sean Doran, Dave Katz, Tony Li, Erik Nordmark, and Pekka Savola.
本文档最初由一个MULTI6设计团队制作，该团队由以下人员组成（按字母顺序排列）：Iljitsch van Beijnum、Steve Bellovin、Brian Carpenter、Mike O’Dell、Sean Doran、Dave Katz、Tony Li、Erik Nordmark和Pekka Savola。
Much of the awareness of these threats come from the work on Mobile IPv6 [MIPv6, NIKANDER03, AURA02].
对这些威胁的大部分认识来自移动IPv6的工作[MIPv6，NIKANDER03，AURA02]。
As the document has evolved, the MULTI6 WG participants have contributed to the document. In particular: Masataka Ohta brought up privacy concerns related to stable identifiers. The suggestion to discuss transport versus IP granularity was contributed by Marcelo Bagnulo, who also contributed text to Appendix B. Many editorial clarifications came from Jari Arkko.
随着文件的发展，6个工作组的参与者为文件做出了贡献。特别是：Masataka Ohta提出了与稳定标识符相关的隐私问题。讨论传输与IP粒度的建议由Marcelo Bagnulo提出，他也为附录B提供了文本。许多编辑澄清来自Jari Arkko。
[NSRG] Lear, E. and R. Droms, "What's In A Name: Thoughts from the NSRG", Work in Progress, September 2003.
[NSRG]Lear，E.和R.Droms，“名称的含义：来自NSRG的想法”，正在进行的工作，2003年9月。
[MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[MIPv6]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[AURA02] Aura, T. and J. Arkko, "MIPv6 BU Attacks and Defenses", Work in Progress, March 2002.
[Aura，T.和J.Arkko，“MIPv6 BU攻击和防御”，正在进行的工作，2002年3月。
[NIKANDER03] Nikander, P., T. Aura, J. Arkko, G. Montenegro, and E. Nordmark, "Mobile IP version 6 Route Optimization Security Design Background", Work in Progress, December 2003.
[NIKANDER03]Nikander，P.，T.Aura，J.Arkko，G.黑山和E.Nordmark，“移动IP版本6路由优化安全设计背景”，正在进行的工作，2003年12月。
[PAXSON01] V. Paxson, "An Analysis of Using Reflectors for Distributed Denial-of-Service Attacks", Computer Communication Review 31(3), July 2001.
[PAXSON01]V.Paxson，“使用反射器进行分布式拒绝服务攻击的分析”，《计算机通信评论》31（3），2001年7月。
[INGRESS] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[INGRESS]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[SCTP] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[SCTP]Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.，和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041]Narten，T.和R.Draves，“IPv6中无状态地址自动配置的隐私扩展”，RFC 3041，2001年1月。
[DNS-THREATS] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[DNS-THREATS]Atkins，D.和R.Austein，“域名系统（DNS）的威胁分析”，RFC 3833，2004年8月。
[FYI18] Malkin, G., "Internet Users' Glossary", RFC 1983, August 1996.
[FYI18]Malkin，G.“互联网用户词汇表”，RFC 1983年，1996年8月。
[ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[ECN]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[OWNER] Nikander, P., "Denial-of-Service, Address Ownership, and Early Authentication in the IPv6 World", Security Protocols 9th International Workshop, Cambridge, UK, April 25-27 2001, LNCS 2467, pages 12-26, Springer, 2002.
[所有者]Nikander，P.，“IPv6世界中的拒绝服务、地址所有权和早期身份验证”，安全协议第9届国际研讨会，英国剑桥，2001年4月25日至27日，LNCS 2467，第12-26页，Springer，2002年。
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996.
[RFC1948]Bellovin，S.，“防御序列号攻击”，RFC 1948，1996年5月。
[PBK] Scott Bradner, Allison Mankin, Jeffrey Schiller, "A Framework for Purpose-Built Keys (PBK)", Work in Progress, June 2003.
[PBK]Scott Bradner，Allison Mankin，Jeffrey Schiller，“专用密钥框架（PBK）”，正在进行的工作，2003年6月。
[NOID] Erik Nordmark, "Multihoming without IP Identifiers", Work in Progress, July 2004.
[NOID]Erik Nordmark，“无IP标识符的多宿”，正在进行的工作，2004年7月。
[HIP] Pekka Nikander, "Considerations on HIP based IPv6 multi-homing", Work in Progress, July 2004.
[HIP]Pekka Nikander，“关于基于HIP的IPv6多宿主的考虑”，正在进行的工作，2004年7月。
[WIMP] Jukka Ylitalo, "Weak Identifier Multihoming Protocol (WIMP)", Work in Progress, June 2004.
[WIMP]Jukka Ylitalo，“弱标识符多宿主协议（WIMP）”，正在进行的工作，2004年6月。
[CBHI] Iljitsch van Beijnum, "Crypto Based Host Identifiers", Work in Progress, February 2004.
[CBHI]Iljitsch van Beijnum，“基于加密的主机标识符”，正在进行的工作，2004年2月。
[TCPSECURE] M. Dalal (ed), "Transmission Control Protocol security considerations", Work in Progress, November 2004.
[TCPSECURE]M.Dalal（编辑），“传输控制协议安全考虑”，正在进行的工作，2004年11月。
Appendix A: Some Security Analysis
附录A：一些安全分析
When looking at the proposals that have been made for multihoming solutions and the above threats, it seems like there are two separable aspects of handling the redirection threats:
当查看针对多宿解决方案和上述威胁提出的建议时，似乎有两个可分离的方面来处理重定向威胁：
- Redirection of existing communication
- 现有通信的重定向
- Redirection of an identity before any communication
- 在任何通信之前重新定向标识
This seems to be related to the fact that there are two different classes of use of identifiers. One use is for:
这似乎与标识符有两种不同的使用类别有关。一种用途是：
o Initially establishing communication; looking up an FQDN to find something that is passed to a connect() or sendto() API call.
o 初步建立沟通；查找FQDN以查找传递给connect（）或sendto（）API调用的内容。
o Comparing whether a peer entity is the same peer entity as in some previous communication.
o 比较对等实体是否与以前的某个通信中的对等实体相同。
o Using the identity of the peer for future communication ("callbacks") in the reverse direction, or to refer to a 3rd party ("referrals").
o 使用对等方的身份进行反向通信（“回调”），或参考第三方（“转介”）。
The other use of identifiers is as part of being able to redirect existing communication to use a different locator.
标识符的另一个用途是作为能够重定向现有通信以使用不同定位器的一部分。
The first class of use seems to be related to something about the ownership of the identifier; proving the "ownership" of the identifier should be sufficient in order to be authorized to control which locators are used to reach the identifier.
第一类使用似乎与标识符的所有权有关；证明标识符的“所有权”应足以授权控制使用哪些定位器到达标识符。
The second class of use seems to be related to something more ephemeral. In order to redirect the existing communication to some other locator, it seems to be sufficient to prove that the entity is the same as the one that initiated the communication. One can view this as proving the ownership of some context, where the context is established around the time when the communication is initiated.
第二类用法似乎与更短暂的事物有关。为了将现有通信重定向到某个其他定位器，似乎足以证明该实体与发起通信的实体相同。可以将此视为证明某些上下文的所有权，其中上下文是在通信启动时建立的。
Preventing unauthorized redirection of existing communication can be addressed by a large number of approaches that are based on setting up some form of security material at the beginning of communication, and later using the existence of that material for one end to prove to the other that it remains the same. An example of this is Purpose Built Keys [PBK]. One can envision different approaches for such schemes with different complexity, performance, and resulting
防止现有通信的未经授权的重定向可以通过大量的方法来解决，这些方法的基础是在通信开始时设置某种形式的安全材料，然后在一端使用该材料的存在向另一端证明其保持不变。这方面的一个例子是专门构建的密钥[PBK]。人们可以为这些方案设想不同的方法，具有不同的复杂性、性能和结果
security such as anonymous Diffie-Hellman exchange, the reverse hash chains presented in [WIMP], or even a clear-text token exchanged at the initial communication.
安全性，例如匿名Diffie-Hellman交换、[WIMP]中提供的反向哈希链，甚至在初始通信时交换的明文令牌。
However, the mechanisms for preventing unauthorized use of an identifier can be quite different. One way to prevent premeditated redirection is to simply not introduce a new identifier name space, and instead to rely on existing name space(s), a trusted third party, and a sufficiently secure way to access the third party, as in [NOID]. Such an approach relies on the third party (DNS in the case of NOID) as the foundation. In terms of multihoming state creation, in this case premeditated redirection is as easy or as hard as redirecting an IP address today. Essentially, this relies on the return-routability check associated with a roundtrip of communication, which verifies that the routing system delivers packets to the IP address in question.
但是，防止未经授权使用标识符的机制可能会有很大不同。防止有预谋的重定向的一种方法是不引入新的标识符名称空间，而是依赖现有名称空间、受信任的第三方和足够安全的方式来访问第三方，如[NOID]。这样的方法依赖于第三方（以NOID的情况下的DNS）为基础。就多主状态创建而言，在这种情况下，有预谋的重定向与今天重定向IP地址一样容易或一样困难。本质上，这依赖于与通信往返相关联的返回可路由性检查，该检查验证路由系统是否将数据包发送到所讨论的IP地址。
Alternatively, one can use the crypto-based identifiers such as in [HIP] or crypto-generated addresses as in [CBHI], which both rely on public-key crypto, to prevent premeditated attacks. In some cases it is also possible to avoid the problem by having one end of the communication use ephemeral identifiers as the initiator does in [WIMP]. This avoids premeditated redirection by detecting that some other entity is using the same identifier at the peer and switching to use another ephemeral ID. While the ephemeral identifiers might be problematic when used by applications, for instance due to callbacks or referrals, note that for the end that has the ephemeral identifier, one can skirt around the premeditated attacks (assuming the solution has a robust way to pick a new identifier when one is in use/stolen).
或者，可以使用基于密码的标识符，例如[HIP]中的标识符或[CBHI]中的加密生成地址，它们都依赖于公钥密码，以防止有预谋的攻击。在某些情况下，也可以通过让通信的一端使用临时标识符来避免问题，就像在[WIMP]中启动器所做的那样。这通过检测到其他实体在对等端使用相同的标识符并切换到使用另一个临时ID来避免有预谋的重定向。虽然临时标识符在被应用程序使用时可能会出现问题，例如由于回调或引用，请注意，对于具有临时标识符的端，可以绕过有预谋的攻击（假设解决方案在使用/被盗时有一种可靠的方法来选择新的标识符）。
Assuming the problem can't be skirted by using ephemeral identifiers, there seem to be 3 types of approaches that can be used to establish some form of identity ownership:
假设这个问题不能通过使用临时标识符来解决，那么似乎有3种方法可以用来建立某种形式的身份所有权：
- A trusted third party, which states that a given identity is reachable at a given set of locators, so the endpoint reached at one of this locators is the owner of the identity.
- 一种受信任的第三方，它声明给定的身份可以在给定的一组定位器上访问，因此在该定位器上到达的端点是该身份的所有者。
- Crypto-based identifiers or crypto-generated addresses where the public/private key pair can be used to prove that the identifier was generated by the node knowing the private key (or by another node whose public key hashes to the same value)
- 基于加密的标识符或加密生成的地址，其中公钥/私钥对可用于证明标识符是由知道私钥的节点（或由公钥散列为相同值的另一节点）生成的
- A static binding, as currently defined in IP, where you trust that the routing system will deliver the packets to the owner of the locator, and since the locator and the identity are one, you prove identity ownership as a sub-product.
- 静态绑定，如当前在IP中定义的，您相信路由系统会将数据包传递给定位器的所有者，并且由于定位器和标识是一个，因此您可以证明标识作为子产品的所有权。
A solution would need to combine elements that provide protection against both premeditated and ongoing communication redirection. This can be done in several ways, and the current set of proposals do not appear to contain all useful combinations. For instance, the HIP CBID property could be used to prevent premeditated attacks, while the WIMP hash chains could be used to prevent on-going redirection. And there are probably other interesting combinations.
解决方案需要结合各种元素，以防止有预谋的和正在进行的通信重定向。这可以通过几种方式实现，而当前的提案集似乎并不包含所有有用的组合。例如，HIP CBID属性可用于防止有预谋的攻击，而WIMP哈希链可用于防止正在进行的重定向。可能还有其他有趣的组合。
A related, but perhaps separate aspect, is whether the solution provides for protection against man-in-the-middle attacks with on-path attackers. Some schemes, such as [HIP] and [NOID] do, but given that an on-path attacker can see and modify the data traffic whether or not it can modify the multihoming signaling, this level of protection seems like overkill. Protecting against on-path MITM for the data traffic can be done separately using IPsec, TLS, etc.
一个相关但可能是独立的方面是，该解决方案是否提供了针对路径上攻击者的中间人攻击的保护。一些方案，如[HIP]和[NOID]确实如此，但考虑到路径上的攻击者可以看到并修改数据流量，无论它是否可以修改多主信令，这种保护级别似乎有些过分。可以使用IPsec、TLS等单独保护数据通信的路径上MITM。
Finally, preventing third party DoS attacks is conceptually simpler; it would suffice to somehow verify that the peer is indeed reachable at the new locator before sending a large number of packets to that locator.
最后，防止第三方DoS攻击在概念上更简单；在向新定位器发送大量数据包之前，以某种方式验证对等点确实可以在该定位器处到达就足够了。
Just as the redirection attacks are conceptually prevented by proving at some level the ownership of the identifier or the ownership of the communication context, third party DoS attacks are conceptually prevented by showing that the endpoint is authorized to use a given locator.
正如重定向攻击在概念上是通过在某种程度上证明标识符的所有权或通信上下文的所有权来防止的，第三方DoS攻击在概念上是通过显示端点被授权使用给定的定位器来防止的。
The currently known approaches for showing such authorization are:
目前已知的显示此类授权的方法有：
- Return routability. That is, if an endpoint is capable of receiving packets at a given locator, it is because he is authorized to do so. This relies on routing being reasonably hard to subvert to deliver packets to the wrong place. While this might be the case when routing protocols are used with reasonable security mechanisms and practices, it isn't the case on a single link where ARP and Neighbor Discovery can be easily spoofed.
- 返回路由性。也就是说，如果端点能够在给定的定位器处接收数据包，那是因为他被授权这样做。这依赖于路由很难被破坏，从而将数据包传送到错误的位置。当路由协议使用合理的安全机制和实践时，可能会出现这种情况，但在单个链路上，ARP和邻居发现并不容易被欺骗。
- Trusted third party. A third party establishes that a given identity is authorized to use a given set of locators (for instance the DNS).
- 受信任的第三方。第三方确定给定的身份被授权使用给定的定位器集（例如DNS）。
Authors' Addresses
作者地址
Erik Nordmark Sun Microsystems, Inc. 17 Network Circle Mountain View, CA 94025 USA
Erik Nordmark Sun Microsystems，Inc.美国加利福尼亚州山景城网络圈17号，邮编94025
Phone: +1 650 786 2921
Fax: +1 650 786 5896
EMail: erik.nordmark@sun.com
Phone: +1 650 786 2921
Fax: +1 650 786 5896
EMail: erik.nordmark@sun.com
Tony Li EMail: Tony.Li@tony.li
Tony Li电子邮件：Tony。Li@tony.li
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 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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。