Network Working Group E. Nordmark
Request for Comments: 4218 Sun Microsystems
Category: Informational T. Li
October 2005
Threats Relating to IPv6 Multihoming Solutions
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
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のマルチホーミングの仕事の目標は、グローバルルーティングテーブルに表示サイトの特定のエントリを持たずに、サイトはグローバルなインターネットへの複数の添付ファイルを利用できるようにすることです。具体的には、溶液は、ホストが、並列に複数の添付ファイルを使用する、またはトランスポートおよびアプリケーション層プロトコルに影響を与えることなく、動的に障害が発生した場合、これらのアタッチメントポイントを切り替えることが可能にすべきです。
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.
ネットワークIDとネットワークの場所の分離を中心に設計さマルチホーミングソリューションを考慮しながら、この文書では、この分離は新しい、別の識別子の名前空間の導入を意味するか否か、開発されました。しかし、この分離は、すべての脅威の要件ではありませんので、この分類はまた、他のアプローチにも適用することができます。この文書は、任意の単一提案された解決策を検討するものではありません。むしろ、それは議論と提案されたソリューションの評価への援助を目的としています。既知の脅威をカタログすることにより、我々は、すべての提案が可能な脅威のすべてに対処することを確実にするために役立ちます。
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）スプーフィングを利用することができます。攻撃者は、ワイヤへのアクセス権を持っている場合、同様に、攻撃者は、ブロックへのワイヤ上に装置を配置することができます。その他のパス攻撃は、ルータまたはスイッチ（またはエンドポイントの1つのコントロールを得る）のコントロールを得るものとなり、最も可能性の高いものとウェルのブロッキングが可能になります。
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.
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レイヤのエンドポイントのIPレイヤ識別子（[NSRG]でスタック名）、つまり、一般的に「ホスト」と呼ばれるかもしれない何か。トランスポートエンドポイント名は、トランスポートプロトコルの関数であり、一般的に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.
マルチホーミングソリューションのセキュリティの2つの興味深い側面は、（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.
インターネット、今日では、アプリケーションのいずれかの開始部分は、それがDNSでルックアップする、またはすでにどこかからIPアドレスを持っているFQDNで始まります。 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.
通信今日の応答（非開始）終了時に、私たちは、さまざまなアプリケーションで使用されるセキュリティ構成は、単一のアプリケーションが通信の種類ごとに構成の異なるクラスを使用する場合があり、約5つのクラスに分類されることがわかります。
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送信元アドレスを受信しますが、効果的に、アクセス制御のためのFQDNを使用して、DNSを使用して、いくつかの検証を試みます。 （これは通常、前方参照が続くと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.
セキュリティ構成の第4のクラスは、とや機密性のない相手とデータの整合性のための強力なアイデンティティーの両方を提供するために、暗号化セキュリティ技術を使用しています。このようなシステムはまだマルチホーミングソリューションによって導入することができ、サービス拒否攻撃に対して潜在的に脆弱です。
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 bindings provide a link between the IP-layer identification and the application protocol identification.
最後に、セキュリティ構成の第五のクラスは、暗号化セキュリティ技術を使用するが、（例えば日和見IPsecのような）強いアイデンティティはありません。未知/非認証プリンシパルと通信するときにこのように、機密性の有無にかかわらず、データの整合性が提供されます。ただ、上記の最初のカテゴリのように、このようなアプリケーションは、彼らが相手の身元を知らないので、ネットワーク層の情報に基づいてアクセス制御を実行することはできません。しかし、彼らはアイデンティティのより高いレベルの概念を使用してアクセス制御を行うことがあります。一緒にチャネルバインディングとのIPsec（および類似の溶液）の可用性は、識別の安全で機密性の高いレベルで動作する（それ自体、マン・イン・ザ・ミドル（MITM）攻撃に対して脆弱である、）プロトコルを可能にしますピアの。典型的な例は、日和見IPsecで使用される場合、チャネルバインディングが使用可能な場合、うまく機能し、リモートダイレクトデータプレースメントプロトコル（RDDP）、です。チャネルバインディングは、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-脅威]です。
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 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.
一般的には、上記の攻撃は、攻撃者は、それが攻撃を実行しているときにパス上にある場合にのみ動作します。攻撃者は、攻撃者がパスをオフに移動した後に、少なくともいくつかの時間のままでDoS攻撃を作成するためしかし、いくつかのケースではそれが可能です。この例は、それ自体を挿入するか、ブラックホール（非存在L2アドレス）にパケットを送信するかの経路上ながらARP又はNDスプーフィングを使用する攻撃です。攻撃者は離れて移動した後、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.
今日のインターネットではIPを使用して、このようなTCPやSCTPなどのトランスポート層プロトコル、、、通信のための識別子としてIPアドレスを使用します。イングレスフィルタリングの不在[INGRESS]において、IP層は、送信者が任意のソースアドレスを使用することができ、このようにトランスポートプロトコル及び/又はアプリケーションは、2つの通信ピア間のパケットストリームに偽のパケットを注入悪意のある送信者に対するいくつかの保護を必要とします。この保護は回避することができる場合、攻撃者は必ずしもリターンパケットをリダイレクトすることなく、害を引き起こすため、それが可能です。
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初期シーケンス番号がランダムであれば、それはそれは、ウィンドウに属するとするために十分に近いシーケンス番号を推測するために、オフパス攻撃者にとって非常に困難であり、結果として既存の接続にパケットを注入することができます。どのようにハードこれは、ポート番号も予測可能であるかどうか、可能なウィンドウの大きさに依存し、接続の寿命。 [TCPSECURE]攻撃のこの広範なクラスに対するTCPの保護を強化するための継続的な仕事があることに注意してください。 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.
2つの通信エンティティ間のパス上のデバイスはまた、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は、TCPを使用する場合はBからAへのパスをオーバーロードしようとすることができ、その後、Bと通信している場合たとえば、今日、Aは、それがまだ受信していないことをデータのためのACKパケットを送信することにより、これを行うことができます（それは疑いますBはAのみからのパスに過負荷をかけることで苦しむネットワークの独自の隅になるだろうので、A.このような攻撃は自己破壊的と思われる方にパス上の永続的な渋滞を引き起こすレートで送信することになるように、Bはすでに）送信しました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は、より速い速度（とAとの間の経路に向けてパケットを送信するためにBをだますことができるかもしれないですX）を処理することができます。例えば、TCPが使用されている場合、Xは、TCP ACKパケットがXがAからのパケットを抑制することができるならば、潜在的に、さらにA.に向けた持続的な渋滞を引き起こすのに十分な大きさである輻輳ウィンドウを使用するためにBを引き起こすために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).
このタイプの攻撃の属性は、単にその流れと輻輳制御メカニズムが働いているように見えるしていないので、Bが故障していることを考えるということです。 ACKパケットのレートが比較的低いかもしれないので、ACKパケットのストリームは、AからXでなく、生成されたことを検出することは、挑戦的であるかもしれません。イングレスフィルタリングの存在下で、それは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.
今日のインターネットでは、このようなダイヤルアップ接続など、いくつかのケースで、ホストが異なる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にマルチホームされたときに今日、一般的なセットアップは、単一のIPアドレスのプレフィックスがすべてのISPで使用されていることです。その結果、すべての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アプリケーションは、彼らが長命IPv6アドレスを必要とするか、または使用の改善プライバシーを望むかどうかを制御することを可能にする一時アドレス[RFC3041]を指定します一時アドレス。
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.
攻撃者は、2つの通信当事者間のパス上にある場合、このような攻撃は常に今日可能であり、マルチホーミングソリューションは、その脅威を取り除くことができないことに注意してください。したがって、これらの問題の大部分は、オフパス攻撃者に関連します。
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に割り当てられている場合これを行うことができる前にロケータが属しているかどうかを確認するために使用できるいくつかのメカニズムが必要になります
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だと私はこの場所でよ」。 Bと通信する場合には、後にしようと、Bはそれが本当にあると考えているのだろうか？
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は、Xが通信を開始したので、Bにこれを証明するために失敗します。
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に送信されること）、またはそれ以降Bとの通信に失敗した場合、彼らは（DoS攻撃を引き起こす可能性がありますそれは）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.
これは、潜在的に攻撃者のホストが誤って古いロケータ（セット）は、リナンバリングイベントの後であっても、長い使用すべきであることを信じるように導かれることになるように、ピアのロケータのホストに通知するために使用されたどんなプロトコルメカニズム再生する能力を与えます。これは[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は、Xは、ちょうど直接パケットとCをあふれさせる可能性があるので、これは、最初に無害に見えるかもしれないが、いくつかの第三のノードCにBを意図したパケットを送信するように説得することができるかもしれません、懸念を引き起こし、これらの攻撃のいくつかの側面があります。
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].
第二の懸念は、CにXから直接DoS攻撃では、攻撃者は、攻撃者は、その後、など、他のホストをだますことができるCへのトラフィックをリダイレクトする場合C.向けて独自のパスの帯域幅によって制限される、ということです帯域幅は、Aは、大容量のインターネットサービスであり、Xが遅い（例えば、ダイヤルアップ）接続していれば、この差はかなりの可能性がC.へのからのパスによって制限されています。したがって、実際には、これは[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は直接洪水可能性がありますが、その低帯域幅によって制限されます。 XはBとの通信を確立することができた場合は、それを高速メディアストリームを送信するためにBを頼むそしてXが出て、おそらく偽物Bのために必要な「確認応答/フィードバックは、」フルスピードでパケットを爆破することができます。これまでのところ、これが唯一のXとXとインターネットの間のパスが痛いです。 Xはまた、「私はAのロケータでよ」Bを伝えることができればしかし、その後、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 |
-----
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がする必要があるかもしれないすべては「あなたは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であると主張することができ、およびNO指がいずれかの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.
このように、異なるパス上の2回の攻撃で、リダイレクトが行われた後、サードパーティへのリダイレクトをした人の痕跡がないかもしれません。
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は、それが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.
現在の状態の例は、既存のTCP接続にRSTパケットを注入する能力です。ネットワークにはイングレスフィルタリングがない場合、これは、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は、スプーフィングされたパケットを拒否することです。 （これは、攻撃者が潜在的にDoS攻撃を引き起こす可能性さえのIPsecとリダイレクト攻撃の例とは異なることに注意してください。）
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（S）または異なるネットワーク接続ポイントとの間で移動する同じ（のセット）。マルチホーミングへのソリューションの設計者は、この懸念を認識する必要があります。
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.
例えば、計画的な攻撃は2例で全く異なる影響を与える可能性があります。 IPベースのマルチホーミングソリューションで成功した計画的なリダイレクションが原因攻撃者のサーバに接続し、それが攻撃者から受け取った「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.
輸送粒度のプロパティは、正当なホストによって実行される作業の量は、それぞれ、このような接続は、いくつかのマルチホーミングシグナリングを必要とするので、それは、それがマルチホーム・サポートを使用し作成しトランスポート接続の数に比例することです。そして、同じことが攻撃者にとって真です。これにより、攻撃者は、おそらく（すべてのTCP送信元ポート番号の）サーバBへの接続を65,536を設定し、それらの接続はに向けられるべきだと思うしBを引き起こすことによって、AからBにポート80にすべてのTCP接続のための計画的な攻撃を行う可能性があることを意味し攻撃者は、これらの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.
なお、範囲を検討されているマルチホームソリューションこのような「ドライブバイ」攻撃が原因フォワードDNSの相対的なセキュリティ上の強い結合HIPのような別の識別子、またはによるに依存し、例えば、（不可能です加えて、第一のホストを可能PBKとMASTアプローチは別IDスペースなし例は、WIMPは別IDスペースが例である（第サーブ/先着いるシステム）に、）NOIDでルックアップを逆任意の時間制限なしでそれを主張する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.
ピアが確認されるまで潜在的に1が仕事をしているかの状態を作成しないようにしたいだろうが、検証は、おそらくいくつかの状態とやるべきいくつかの作業が必要になりますので、潜在的な鶏と卵の問題は、ここにあります。すべての作業を避けることが可能に思えませんが、検証が完了するまでは良いプロトコル設計は、多くの場合、状態の作成を遅らせることができます。
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.
ソリューションは、調査可能性のあるアプローチは、2つの異なるホスト（または同じホスト用の2つの異なるロケータ）同じ識別子を使用したいがあるように表示されるまで検証を延期することです。そのような場合には1を偽装して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
- エンドシステムの1
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バンBeijnum、スティーブBellovin氏、ブライアン・カーペンター、マイク・オデル、ショーン・ドーラン、デイブ・カッツ、トニー・リー、エリックNordmarkと、およびペッカ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.
ドキュメントが発展してきたとおり、MULTI6 WG参加者は文書に貢献してきました。特に：正孝太田は、安定した識別子に関連するプライバシーの問題を育てました。 IP粒度対輸送を議論するための提案もヤリArkkoから来た付録B.多くの編集の明確化へのテキストの貢献マルセロBagnulo、によって寄贈されました。
[NSRG] Lear, E. and R. Droms, "What's In A Name: Thoughts from the NSRG", Work in Progress, September 2003.
[NSRG]リア、E.およびR. Droms、「どのような名前ではあります：NSRGからの思考」、進歩、2003年9月の作業。
[MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[MIPv6の]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[AURA02] Aura, T. and J. Arkko, "MIPv6 BU Attacks and Defenses", Work in Progress, March 2002.
[AURA02]オーラ、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.オーラ、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.パクソン、「分散型サービス妨害（DoS）攻撃の反射板を使用しての分析」、コンピュータコミュニケーションレビュー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]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス拒否攻撃を破り"、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]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.、およびV 。パクソン、 "ストリーム制御伝送プロトコル"、RFC 2960、2000年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-脅威]アトキンス、D.とR. Austeinと、RFC 3833 "ドメインネームシステム（DNS）の脅威分析"、2004年8月。
[FYI18] Malkin, G., "Internet Users' Glossary", RFC 1983, August 1996.
[FYI18]マルキン、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.
"IPに明示的輻輳通知の添加（ECN）" [ECN]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、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.
[OWNER] Nikander、P.、「サービス拒否、アドレスの所有権、およびIPv6の世界での早期の認証」、セキュリティプロトコル第9回国際ワークショップ、ケンブリッジ、英国、4月25-27 2001、LNCS 2467、ページ12-26 、スプリンガー、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]スコット・ブラッドナー、アリソンマンキン、ジェフリーシラー、「専用のキーのためのフレームワーク（PBK）」、進歩、2003年6月での作業。
[NOID] Erik Nordmark, "Multihoming without IP Identifiers", Work in Progress, July 2004.
"IP識別子のないマルチホーミング" [NOID]エリックNordmarkと、進捗状況、2004年7月の作業。
[HIP] Pekka Nikander, "Considerations on HIP based IPv6 multi-homing", Work in Progress, July 2004.
[HIP]ペッカNikander、「IPv6のマルチホーミングベースHIP上の考慮事項」、進歩、2004年7月に作業。
[WIMP] Jukka Ylitalo, "Weak Identifier Multihoming Protocol (WIMP)", Work in Progress, June 2004.
[WIMP]ユッカYlitalo、 "弱識別マルチホーミングプロトコル（WIMP）"、進歩、2004年6月での作業。
[CBHI] Iljitsch van Beijnum, "Crypto Based Host Identifiers", Work in Progress, February 2004.
[CBHI] Iljitschバン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:
マルチホーミングソリューションおよび上記の脅威のために作られてきた提案を見ているときに、リダイレクトの脅威を扱う2つの分離側面があるように、それはそうです：
- 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:
これは、識別子の使用の2つの異なるクラスがあるという事実に関係しているようです。 1つの用途はためです。
o Initially establishing communication; looking up an FQDN to find something that is passed to a connect() or sendto() API call.
O最初の通信を確立します。 connect（）やsendto（）APIコールに渡される何かを見つけるために、FQDNを見上げ。
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").
サードパーティ（「紹介」）を参照するために逆方向の将来の通信（「コールバック」）のために、ピアのIDを使用して、または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 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.
既存の通信の防止、不正なリダイレクトはそれそのほかに証明するために通信の開始時にセキュリティ材料のいくつかのフォームを設定し、以降の一端のためにその物質の存在を使用することに基づいているアプローチの多数によって対処することができます同じまま。この例は、目的内蔵キー[PBK]です。一つは、匿名の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]のように、単に新しい識別子の名前空間を導入しないために、代わりに既存の名前空間（S）、信頼できるサードパーティ、および第三者にアクセスするための十分な安全な方法に頼ることです。そのようなアプローチは、基礎として、第三者（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を使用するように切り替えていることを検出することにより、計画的なリダイレクションを回避します。アプリケーションで使用される際に一時的識別子は、はかない識別子を持って終了するために、1の解決策は、新しいを選ぶための堅牢な方法を持っていると仮定すると（計画的な攻撃の周りにスカートことに注意し、原因コールバックや紹介に例えば、問題となるかもしれませんが識別子一方が使用/盗まれています）。
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.
- 指定されたアイデンティティがロケータの特定のセットで到達可能であるため、エンドポイントは、このロケータの1に達したと述べている信頼できるサードパーティは、アイデンティティの所有者です。
- 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.
- 静的は、現在あなたがルーティングシステムは、ロケータの所有者にパケットを配信し、ロケータとIDが1であるため、あなたはサブ製品としてのアイデンティティの所有権を証明することを信頼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.
ソリューションは、両方の計画的かつ継続的な通信のリダイレクションに対する保護を提供する要素を結合する必要があります。これは、いくつかの方法で行うことができ、提案の現在のセットは、すべての有用な組み合わせを含むように表示されません。 WIMPハッシュチェーンは、進行中のリダイレクトを防ぐために使用することができながら、例えば、HIP CBIDプロパティは、計画的な攻撃を防ぐために使用することができます。そして、おそらく他の興味深い組み合わせがあります。
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.
関連し、おそらく別の態様は、溶液がオンパス攻撃とman-in-the-middle攻撃に対する保護を提供するかどうかです。こうした[HIP]や[NOID]はやるが、それはマルチホーミングシグナリングを変更することができるか否かのパス攻撃者が参照およびデータトラフィックを変更することができることを考えると、このレベルの保護が行き過ぎのように思えるようないくつかのスキーム。データトラフィック用のパスMITMに対して保護するなどのIPsec、TLSを使用して個別に行うことができます
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
エリックNordmarkとサン・マイクロシステムズ株式会社17ネットワークサークルマウンテンビュー、CA 94025 USA
Phone: +1 650 786 2921 Fax: +1 650 786 5896 EMail: erik.nordmark@sun.com
電話：+1 650 786 2921ファックス：+1 650 786 5896 Eメール：erik.nordmark@sun.com
Tony Li EMail: 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。