[要約] RFC 4218は、IPv6マルチホーミングソリューションに関連する脅威についての要約を提供しています。このRFCの目的は、IPv6マルチホーミングのセキュリティ上の課題を識別し、対策を提案することです。
Network Working Group E. Nordmark
Request for Comments: 4218 Sun Microsystems
Category: Informational T. Li
October 2005
Threats Relating to IPv6 Multihoming Solutions
IPv6マルチホームソリューションに関連する脅威
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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マルチホームに関連するセキュリティの脅威がリストされています。Multihomingは、異なる意図しない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.
このドキュメントは、ネットワークのアイデンティティとネットワークの位置の分離を中心にアーキネートされたマルチホミングソリューションを検討しながら開発されました。ただし、この分離はすべての脅威の要件ではないため、この分類法は他のアプローチにも適用される場合があります。このドキュメントは、単一の提案されたソリューションを調べることを意図したものではありません。むしろ、提案されたソリューションの議論と評価の援助として意図されています。既知の脅威をカタログ化することにより、すべての提案が利用可能なすべての脅威に対処するようにすることができます。
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ソースアドレスとコンテンツを含むパケットを送信できますが、イングレスフィルタリング[イングレス]が適用されると、そのようなパケットがブロックされる場合があります。したがって、侵入フィルタリングの存在下と不在の両方で、セキュリティへのマルチホームの影響を見ることが重要です。
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.
それを説明する1つの方法は、最初にピアを認証し、次にピアが特定の識別子に使用されるロケーターを制御することを許可されていることを確認する必要があることです。これは正しいですが、承認の側面にあまりにも重点を置く可能性があります。この場合、承認は概念的に非常に単純です。各ホスト（各識別子）は、それ自体に使用されるロケーターを制御する権限があります。
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].
したがって、同じことを説明する別の方法があります。ピアがそれが識別子の所有者であることを何らかの形で証明できる場合、通信が識別子（およびロケーターではなく）に縛られている場合、ピアは識別子で使用されるロケーターを制御することが許可されます。この方法で問題を説明するためのこの方法は、[所有者]で使用されています。
Both ways to look at the problem, hence both sets of terminology, are useful when trying to understand the problem space and the threats.
問題を見るための両方の方法、したがって両方の用語のセットは、問題の空間と脅威を理解しようとするときに役立ちます。
link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IPv6. Examples are Ethernets (simple or bridged); PPP links; X.25, Frame Relay, or ATM networks; and Internet (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 itself.
リンク - ノードがリンクレイヤー、つまりIPv6のすぐ下のレイヤーで通信できる通信機能または媒体。例は、イーサネット（シンプルまたはブリッジ）です。PPPリンク;X.25、フレームリレー、またはATMネットワーク。IPv4またはIPv6自体のトンネルなど、インターネット（またはそれ以上）レイヤー「トンネル」。
interface - a node's attachment to a link.
インターフェイス - リンクへのノードの添付ファイル。
address - an IP layer name that has both topological significance (i.e., a locator) and identifies an interface. There may be multiple addresses per interface. Normally an address uniquely identifies an interface, but there are exceptions: the same unicast address can be assigned to multiple interfaces on the same node, and an anycast address can be assigned to different interfaces on different nodes.
アドレス - トポロジーの重要性（つまり、ロケーター）の両方を持ち、インターフェイスを識別するIPレイヤー名。インターフェイスごとに複数のアドレスがある場合があります。通常、アドレスはインターフェイスを一意に識別しますが、例外があります。同じノード上の複数のインターフェイスに同じユニキャストアドレスを割り当てることができ、異なるノード上の異なるインターフェイスにAnyCastアドレスを割り当てることができます。
locator - an IP layer topological name for an interface or a set of interfaces. There may be multiple locators per interface.
ロケーター - インターフェイスまたはインターフェイスのセットのIPレイヤートポロジ名。インターフェイスごとに複数のロケーターがある場合があります。
identifier - an IP layer identifier for an IP layer endpoint (stack name in [NSRG]), that is, something that might be commonly referred to as a "host". The transport endpoint name is a function of the transport protocol and would typically include the IP identifier plus a port number. There might be use for having multiple identifiers per stack/per host.
識別子 - IPレイヤーエンドポイント（[NSRG]のスタック名）のIPレイヤー識別子、つまり、一般的に「ホスト」と呼ばれる可能性のあるものです。トランスポートエンドポイント名はトランスポートプロトコルの関数であり、通常、IP識別子とポート番号が含まれます。スタック/ホストごとの複数の識別子を持つことに使用される場合があります。
An identifier continues to function regardless of the state of any one interface.
識別子は、1つのインターフェイスの状態に関係なく機能し続けます。
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.
今日のインターネットでは、アプリケーションの開始部分はFQDNで始まり、DNSで見上げられるか、すでにどこかからIPアドレスを持っています。FQDNがIPアドレスルックアップを実行するために、アプリケーションはDNSに効果的に信頼を置きます。IPアドレスがあると、アプリケーションはそのアドレスにパケットを配信するルーティングシステムに信頼を置きます。IPSECやTLSなどのセキュリティメカニズムを使用するアプリケーションには、アドレスまたはFQDNを暗号化キーイン素材にバインドする機能があります。DNSおよび/またはルーティングシステムを侵害すると、そのような場合にはパケットが攻撃者にドロップまたは配信される可能性がありますが、攻撃者はキーイング素材を所有していないため、アプリケーションは攻撃者を信頼しません。。
At the responding (non-initiating) end of communication today, we find that the security configurations used by different applications fall into approximately five classes, where a single application might use different classes of configurations for different types of communication.
今日の通信の応答（目立たない）端で、さまざまなアプリケーションで使用されるセキュリティ構成が約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.
セキュリティ構成の2番目のクラスでは、確認の形態のない認証手段として、既存のIPソースアドレスを、現地サイトの外側からの既存の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.
セキュリティ構成の3番目のクラスでは、既存のIPソースアドレスを受信しますが、DNSを使用して検証を試み、アクセス制御にFQDNを効果的に使用します。（これは通常、IPアドレスから逆ルックアップを実行し、その後にフォワードルックアップを実行し、IPアドレスがフォワードルックアップから返されるアドレスの1つと一致することを確認することで行われます。）これらのアプリケーションは、手法を使用した多くの攻撃の対象となります。攻撃者がそうであることを知っているので、ソースアドレスのスプーフィングやTCPシーケンス番号の推測は、本物のDNSレコードを持つ偽造ソースアドレスを使用してDOS攻撃を作成するだけです。一般に、このクラスのセキュリティ構成は強く落胆していますが、おそらく、マルチホームのソリューションでは、このような攻撃を実行するための新しい簡単な方法を導入しないことが重要です。ただし、一部の人々は、このクラスをセキュリティ構成の2番目のクラスと同じように扱う必要があると考えていることに注意してください。
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.
最後に、セキュリティ構成の5番目のクラスでは、暗号化セキュリティ手法を使用しますが、強いアイデンティティ（日和見的なIPSECなど）がありません。したがって、不明/認証されていないプリンシパルと通信する場合、機密性の有無にかかわらずデータの整合性が提供されます。上記の最初のカテゴリと同様に、このようなアプリケーションは、ピアの身元を知らないため、ネットワークレイヤー情報に基づいてアクセス制御を実行できません。ただし、アイデンティティの高レベルの概念を使用してアクセス制御を実行する場合があります。IPSec（および同様のソリューション）とチャネルバインディングとともに可用性により、プロトコル（それ自体が中程度のマン（MITM）攻撃に対して脆弱である）が、識別のセキュリティにおいて高レベルの機密性で動作することができます。ピアの。典型的な例は、リモートダイレクトデータプレースメントプロトコル（RDDP）です。これは、日和見的なIPSECで使用すると、チャネルバインディングが利用可能な場合にうまく機能します。チャネルバインディングは、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.
5番目のクラスのバリアントは、最初のコミュニケーション中に「信仰の飛躍」を使用するものです。後続のコミュニケーションが最初のコミュニケーションに縛られている場合を除き、彼らは強力なアイデンティティを提供し、ピアが最初のコミュニケーション中と同じであるという強い保証を提供します。
The fifth class is important and its security properties must be preserved by a multihoming solution.
5番目のクラスは重要であり、そのセキュリティプロパティはマルチホームソリューションによって保存する必要があります。
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攻撃を作成することが可能です。この例は、ARPまたはndスプーフィングを使用してパス中に自体を挿入するか、ブラックホール（存在しないL2アドレス）にパケットを送信する攻撃者です。攻撃者が移動した後、ARP/ndエントリは、隣接するノードのキャッシュにある程度の時間（ARPの場合は1分ほど）のままになります。これにより、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アドレスを通信の識別子として使用します。イングレスフィルタリング[イングレス]がない場合、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の初期シーケンス番号がランダムな場合、オフパス攻撃者がウィンドウに属するのに十分近いシーケンス番号を推測するのは非常に困難であり、その結果、既存の接続にパケットを注入することができます。これがどれほど難しいかは、使用可能なウィンドウのサイズ、ポート番号も予測可能かどうか、および接続の寿命に依存します。この広範なクラスの攻撃に対するTCPの保護を強化するための継続的な作業があることに注意してください[TCPSECURE]。SCTPは、検証タグを使用してより強力なメカニズムを提供します。オフパスの攻撃者は、このランダムな32ビット数を推測する必要があります。もちろん、IPSECは、セキュリティ関連が確立されたら、攻撃者がパスの内外でパスを注入するのを防ぐ暗号化的に強力なメカニズムを提供します。
When ingress filtering is deployed between the potential attacker and the path between the communicating peers, it can prevent the attacker from using the peer's IP address as source. In that case, the packet injection will fail in today's Internet.
潜在的な攻撃者と通信ピア間のパスの間にイングレスフィルタリングが展開されると、攻撃者がピアのIPアドレスをソースとして使用することを防ぐことができます。その場合、今日のインターネットではパケットインジェクションが失敗します。
We don't expect a multihoming solution to improve the existing degree of prevention against packet injection. However, it is necessary to look carefully at whether a multihoming solution makes it easier for attackers to inject packets because the desire to have the peer present at multiple locators, and perhaps at a dynamic set of locators, can potentially result in solutions that, even in the presence of ingress filtering, make packet injection easier.
マルチホームソリューションがパケット注入に対する既存の予防度を改善することを期待していません。ただし、複数のロケーターにピアを存在させたいという欲求があり、おそらくロケーターの動的なセットにピアを入れたいという欲求が、潜在的にソリューションをもたらす可能性があるため、マルチホームソリューションが攻撃者がパケットを注入しやすくするかどうかを注意深く見る必要があります。イングレスフィルタリングの存在下で、パケットインジェクションを簡単にします。
In the Internet today there are several ways for an attacker to use a redirection mechanism to launch DoS attacks that cannot easily be traced to the attacker. An example of this is to use protocols that cause reflection with or without amplification [PAXSON01].
今日のインターネットでは、攻撃者がリダイレクトメカニズムを使用して、攻撃者に簡単に追跡できないDOS攻撃を開始する方法がいくつかあります。この例は、増幅の有無にかかわらず反射を引き起こすプロトコルを使用することです[Paxson01]。
Reflection without amplification can be accomplished by an attacker sending a TCP SYN packet to a well-known server with a spoofed source address; the resulting TCP SYN ACK packet will be sent to the spoofed source address.
増幅なしの反射は、スプーフィングされたソースアドレスを持つよく知られているサーバーにTCP synパケットを送信する攻撃者によって実現できます。結果のTCP Syn ACKパケットは、スプーフィングされたソースアドレスに送信されます。
Devices on the path between two communicating entities can also launch DoS attacks. While such attacks might not be interesting today, it is necessary to understand them better in order to determine whether a multihoming solution might enable new types of DoS attacks.
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がBと通信している場合、AはBからAにパスをオーバーロードしようとすることができます。TCPが使用されている場合、Aはまだ受信していないデータにACKパケットを送信することでこれを行うことができます（ただし、疑わしいですBはすでに送信されています）。Bは、Aへのパスに永続的な輻輳を引き起こすレートで送信されます。Aは、Aがネットワークのコーナーをオーバーロードすることによって単独での独自のコーナーを苦しめるだけなので、自己破壊的に思えます。Aに向かってインターネット
A more interesting case is if A is communicating with B and X is on the path between A and B, then X might be able to fool B to send packets towards A at a rate that is faster than A (and the path between A and X) can handle. For instance, if TCP is used, then X can craft TCP ACK packets claiming to come from A to cause B to use a congestion window that is large enough to potentially cause persistent congestion towards A. Furthermore, if X can suppress the packets from A to B, it can also prevent A from sending any explicit
より興味深いケースは、AがBと通信し、XがAとBの間のパス上にある場合、XはBをだましてAよりも速いレートでAにパケットを送信できる可能性があります（およびAとAの間のパスはx）処理できます。たとえば、TCPを使用する場合、XはAから来ると主張するTCP ACKパケットを作成します。BがAに向かって持続的な輻輳を引き起こす可能性のある渋滞ウィンドウを使用するためにBを使用することができます。さらに、XがパケットをAから抑制できる場合Bには、Aが明示的なものを送信するのを防ぐこともできます
"slow down" packets to B; that is, X can disable any flow or congestion control mechanism such as Explicit Congestion Notification [ECN]. Similar attacks can presumably be launched using protocols that carry streaming media by forging such a protocol's notion of acknowledgement and feedback.
パケットをBに「スローダウン」します。つまり、Xは、明示的な輻輳通知[ECN]などのフローまたは輻輳制御メカニズムを無効にすることができます。同様の攻撃は、このようなプロトコルの承認とフィードバックの概念を偽造することにより、ストリーミングメディアを運ぶプロトコルを使用して、おそらく同様の攻撃を開始できます。
An attribute of this type of attack is that A will simply think that B is faulty since its flow and congestion control mechanisms don't seem to be working. Detecting that the stream of ACK packets is generated from X and not from A might be challenging, since the rate of ACK packets might be relatively low. This type of attack might not be common today because, in the presence of ingress filtering, it requires that X remain on the path in order to sustain the DoS attack. And in the absence of ingress filtering an attacker would need either to be present on the path initially and then move away, or to be able to perform the setup of the communication "blind", i.e., without seeing the return traffic (which, in the case of TCP, implies guessing the initial sequence number).
このタイプの攻撃の属性は、Aが流れと輻輳制御メカニズムが機能していないように見えるため、Bが故障していると単純に考えることです。ACKパケットの速度は比較的低いため、ACKパケットのストリームがXから生成され、Aからではなく困難な場合があることを検出します。このタイプの攻撃は、イングレスフィルタリングが存在する場合、DOS攻撃を維持するためにxがパスにとどまる必要があるため、今日は一般的ではないかもしれません。そして、攻撃者のフィルタリングが攻撃のフィルタリングがない場合、攻撃者は最初にパスに存在してから離れて移動するか、「ブラインド」、つまり戻りトラフィックを見ずに「ブラインド」のセットアップを実行できるようにする必要があります（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.
今日のインターネットでは、Dialup Connectivityなどの場合によっては、接続するたびに異なるIPv4アドレスを取得するため、インターネットを使用するため、ホストを追跡する能力が限られています。ただし、DSLやケーブルなどのブロードバンド接続の使用が増加すると、ホストが時間の経過とともに同じIPv4を維持する可能性が高くなります。ホストが今日のインターネットで移動した場合、たとえば、WiFiホットスポットにアクセスして、各場所で異なるIPv4アドレスで構成されます。
We also observe that a common practice in IPv4 today is to use some form of address translation, whether the site is multihomed or not. This effectively hides the identity of the specific host within a site; only the site can be identified based on the IP address.
また、今日のIPv4での一般的な慣行は、サイトがマルチホームであるかどうかにかかわらず、何らかのアドレス変換を使用することであることを観察します。これは、サイト内の特定のホストの身元を効果的に隠します。IPアドレスに基づいてサイトのみを識別できます。
In the cases where it is desirable to maintain connectivity as a host moves around, whether using layer 2 technology or Mobile IPv4, the IPv4 address will remain constant during the movement (otherwise the connections would break). Thus, there is somewhat of a choice today between seamless connectivity during movement and increased address privacy.
レイヤー2テクノロジーまたはモバイルIPv4を使用するかどうかにかかわらず、ホストが移動するにつれて接続性を維持することが望ましい場合、IPv4アドレスは動き中に一定のままです（そうでなければ、接続は破損します）。したがって、移動中のシームレスな接続性とアドレスのプライバシーの増加との間に、今日はやや選択があります。
Today when a site is multihomed to multiple ISPs, the common setup is that a single IP address prefix is used with all the ISPs. As a result it is possible to track that it is the same host that is communication via all ISPs.
今日、サイトが複数のISPにマルチホームされている場合、一般的なセットアップは、すべてのISPで単一のIPアドレスプレフィックスが使用されることです。その結果、すべてのISPを介して通信であるのは同じホストであることを追跡することが可能です。
However, when a host (and not a site) is multi-homed to several ISPs (e.g., through a General Packet Radio Service (GPRS) connection and a wireless hot spot), the host is provided with different IP addresses on each interface. While the focus of the multihoming work is on site multihoming, should the solution also be applicable to host multihoming, the privacy impact needs to be considered for this case as well.
ただし、ホスト（サイトではない）が複数のISPにマルチホームされている場合（たとえば、一般的なパケットラジオサービス（GPRS）接続とワイヤレスホットスポットを介して）、各インターフェイスに異なるIPアドレスが提供されます。マルチホミング作業の焦点はサイトマルチホームにありますが、ソリューションがホストマルチホミングにも適用できれば、このケースでもプライバシーへの影響を考慮する必要があります。
IPv6 stateless address auto-configuration facilitates IP address management, but raises some concerns since the Ethernet address is encoded in the low-order 64 bits of the IPv6 address. This could potentially be used to track a host as it moves around the network, using different ISPs, etc. IPv6 specifies temporary addresses [RFC3041], which allow applications to control whether they need long-lived IPv6 addresses or desire the improved privacy of using temporary addresses.
IPv6ステートレスアドレス自動構成はIPアドレス管理を促進しますが、イーサネットアドレスがIPv6アドレスの低次64ビットでエンコードされているため、いくつかの懸念を引き起こします。これは、さまざまなISPなどを使用してネットワーク周辺を移動するときにホストを追跡するために使用できます。IPv6は、一時的なアドレスを指定します[RFC3041]を指定します。一時的なアドレス。
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がAの前にそのロケーターの使用を開始する前にロケーターがAに属するかどうかを確認するために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.
現在のインターネットでは、このような攻撃を実行してパケットをリダイレクトすることはできません。しかし、離れた後しばらくの間、攻撃者は、たとえば、パス上のノードに偽のARPエントリを残すか、TCPの初期シーケンス番号を見たときにTCPリセットパケットを偽造することにより、DOS攻撃を引き起こす可能性があります。パス。
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：「こんにちは、私はこの場所にいます」と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.
古典的なリダイレクト攻撃の解決策が「最初と同じであることを証明する」に基づいている場合、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に送信される）か、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.
マルチホームの問題は本質的にトポロジカルな動きを暗示するものではありませんが、マルチホミングと組み合わせてサイトの変更の影響を考慮することも有用です。その場合、ホスト用のロケーターのセットは、サイトのRenumbersのたびに変更されます。また、変更イベントの後のある時点で、古いロケータープレフィックスが他のサイトに再割り当てされる場合があります。
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は、サイトの名前を変更しながら、サイトロケータープレフィックスの再割り当てが数週間または数か月になる間、毎秒1秒ごとに動きが見られる場合があります。
To prevent such replay attacks, the protocol used to verify which locators can be used with a particular identifier needs some replay protection mechanism.
このようなリプレイ攻撃を防ぐために、特定の識別子で使用できるロケーターを検証するために使用されるプロトコルは、リプレイ保護メカニズムが必要です。
Also, in this space one needs to be concerned about potential interaction between such replay protection and the administrative act of reassignment of a locator. If the identifier and locator relationship is distributed across the network, one would need to make sure that the old information has been completely purged from the network before any reassignment. Note that this does not require an explicit mechanism. This can instead be implemented by locator reuse policy and careful timeouts of locator information.
また、この分野では、このようなリプレイ保護とロケーターの再割り当ての行政行為との潜在的な相互作用を懸念する必要があります。識別子とロケーターの関係がネットワーク全体に分散されている場合、再割り当ての前に古い情報がネットワークから完全に削除されていることを確認する必要があります。これには明示的なメカニズムは必要ないことに注意してください。代わりに、ロケーターの再利用ポリシーとロケーター情報の慎重なタイムアウトによって実装できます。
This is also a variant of the classic redirection attack. The difference is that the new location is a locator that is nonexistent or unreachable. Thus, the effect is that sending packets to the new locator causes the packets to be dropped by the network somewhere.
これは、古典的なリダイレクト攻撃のバリアントでもあります。違いは、新しい場所が存在しない、または到達不可能なロケーターであることです。したがって、効果は、新しいロケーターにパケットを送信すると、パケットがどこかでネットワークによってドロップされるようになるということです。
One would expect that solutions that prevent the previous redirection attacks would prevent this attack as a side effect, but it makes sense to include this attack here for completeness. Mechanisms that prevented a redirection attack to the attacker should also prevent redirection to a black hole.
以前のリダイレクト攻撃を防ぐソリューションは、この攻撃が副作用としてこの攻撃を防ぐことを期待するでしょうが、完全性のためにこの攻撃をここに含めることは理にかなっています。攻撃者へのリダイレクト攻撃を妨げたメカニズムは、ブラックホールのリダイレクトを防ぐ必要があります。
An attacker can use the ability to perform redirection to cause overload on an unrelated third party. For instance, if A and B are communicating, then the attacker X might be able to convince A to send the packets intended for B to some third node C. While this might seem harmless at first, since X could just flood C with packets directly, there are a few aspects of these attacks that cause concern.
攻撃者は、リダイレクトを実行して、無関係なサードパーティで過負荷を引き起こす機能を使用できます。たとえば、AとBが通信している場合、攻撃者XはAを説得して、B用のパケットを3番目のノードCに送信するように説得することができますが、これは最初は無害に見えるかもしれません。、懸念を引き起こすこれらの攻撃にはいくつかの側面があります。
The first is that the attacker might be able to completely hide its identity and location. It might suffice for X to send and receive a few packets to A in order to perform the redirection, and A might not retain any state on who asked for the redirection to C's location. Even if A had retained such state, that state would probably not be easily available to C, thus C can't determine who the attacker was once C has become the victim of a DoS attack.
1つ目は、攻撃者がそのアイデンティティと場所を完全に隠すことができる可能性があることです。Xがリダイレクトを実行するためにいくつかのパケットをAに送信して受信するだけで十分であり、AはCの位置へのリダイレクトを要求した人に関する状態を保持しない場合があります。Aがそのような状態を保持していたとしても、その状態はおそらくCが簡単に利用できないでしょう。したがって、Cは攻撃者がかつてCがDOS攻撃の犠牲者になったかを判断できません。
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].
2番目の懸念は、XからCへの直接的なDOS攻撃により、攻撃者はCへの独自の経路の帯域幅によって制限されることです。攻撃者がAなどの別のホストを欺くことができれば、トラフィックをCにリダイレクトできる場合、帯域幅は、AからCへのパスによって制限されます。Aが大容量のインターネットサービスであり、Xが遅い（ダイヤルアップ）接続が遅い場合、この違いはかなりのものです。したがって、実際には、これは[Paxson01]のリフレクターを増幅するパケットを増幅することに似ている可能性があります。
The third, and final concern, is that if an attacker only need a few packets to convince one host to flood a third party, then it wouldn't be hard for the attacker to convince lots of hosts to flood the same third party. Thus, this could be used for Distributed Denial-of-Service attacks.
3番目の最終的な懸念は、攻撃者が1人のホストに第三者に浸水するよう説得するためにいくつかのパケットを必要とする場合、攻撃者が多くのホストに同じ第三者に浸水させるよう説得することは難しくないということです。したがって、これは分散されたサービス拒否攻撃に使用できます。
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シーケンス番号投与技術と組み合わせた手法です）。さらに、インターネットの一部がイングレスフィルタリング[イングレス]を使用する限り、通信が開始されたとしても、Pathオフパスの攻撃者からのスプーフィングされたソースアドレスを含むACKパケットを送信することでそれを維持することはできません。
If this type of attack can't be prevented, there might be mitigation techniques that can be employed. For instance, in the case of TCP a partial defense can be constructed by having TCP slow-start be triggered when the destination locator changes. (Folks might argue that, separately from security, this would be the correct action for congestion control since TCP might not have any congestion-relation information about the new path implied by the new locator.) Presumably the same approach can be applied to other transport protocols that perform different forms of (TCP-friendly) congestion control, even though some of them might not adapt as rapidly as TCP. But since all congestion-controlled protocols probably need to have some reaction to the path change implied by a locator change, it makes sense to think about 3rd party DoS attacks when designing how the specific transport protocols should react to a locator change. However, this would only be a partial solution since it would probably take several packets and roundtrips before the transport protocol would stop transmitting; thus, an attacker could still use this as a reflector with packet amplification. Thus, the multihoming mechanism probably needs some form of defense against third party DoS attacks, in addition to the help we can get from the transport protocols.
このタイプの攻撃を防ぐことができない場合、採用できる緩和技術があるかもしれません。たとえば、TCPの場合、宛先ロケーターが変更されたときにTCPスロースタートをトリガーすることにより、部分的な防御を構築できます。（人々は、セキュリティとは別に、TCPが新しいロケーターによって暗示される新しいパスに関する混雑関連情報がない可能性があるため、これは渋滞制御の正しいアクションになると主張するかもしれません。）おそらく、同じアプローチを他の輸送に適用できると思われます。TCPほど迅速に適応しない場合でも、さまざまな形式の（TCPフレンドリーな）混雑制御を実行するプロトコル。しかし、すべての輻輳制御プロトコルは、おそらくロケーターの変更によって暗示されるパスの変更に対する反応をする必要があるため、特定の輸送プロトコルがロケーターの変更にどのように反応するかを設計する際に、サードパーティのDOS攻撃について考えることは理にかなっています。ただし、これは、輸送プロトコルが送信を停止する前に、おそらくいくつかのパケットと往復を取るため、部分的なソリューションにすぎません。したがって、攻撃者はこれをパケット増幅を備えたリフレクターとして使用できます。したがって、マルチホームのメカニズムは、輸送プロトコルから得られる助けに加えて、おそらくサードパーティのDOS攻撃に対する何らかの形の防御を必要とするでしょう。
Assume that X is on a slow link anywhere in the Internet. B is on a fast link (gigabits; e.g., a media server) and A is the victim.
Xがインターネット内のどこでも遅いリンク上にあると仮定します。Bは高速リンク（ギガビット、メディアサーバーなど）にあり、Aは被害者です。
X could flood A directly but is limited by its low bandwidth. If X can establish communication with B, ask B to send it a high-speed media stream, then X can presumably fake out the "acknowledgements/feedback" needed for B to blast out packets at full speed. So far, this only hurts X and the path between X and the Internet. But if X could also tell B "I'm at A's locator", then X has effectively used this redirection capability in multihoming to amplify its DoS capability, which would be a source of concern.
XはAを直接浸水させる可能性がありますが、低帯域幅によって制限されます。XがBとの通信を確立できる場合は、Bに高速メディアストリームを送信するように依頼すると、Bがフルスピードでパケットを爆破するために必要な「承認/フィードバック」を偽造できます。これまでのところ、これはXとXとインターネットの間のパスのみを傷つけます。しかし、Xが「私はAのロケーターにいる」とも伝えることができた場合、Xはマルチホミングでこのリダイレクト機能を効果的に使用してDOS機能を増幅しました。これは懸念の源です。
One could envision rather simple techniques to prevent such attacks. For instance, before sending to a new peer locator, perform a clear text exchange with the claimed new locator of the form "Are you X?" resulting in "Yes, I'm X.". This would suffice for the simplest of attacks. However, as we will see below, more sophisticated attacks are possible.
そのような攻撃を防ぐためのかなり簡単なテクニックを想像することができます。たとえば、新しいピアロケーターに送信する前に、フォーム「Are You 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の間のパスに友人がいます。
----- ----- -----
| 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が行う必要があるかもしれないことは、「You xですか？」パケット、そしてその時点でyは必要ないかもしれません。Xは、ACKパケットを生成することにより、データフローをAに向けて潜在的に維持する可能性があります。したがって、Yの存在を検出することはさらに難しいでしょう。
Furthermore, if X is not the actual end system but an attacker between some node C and B, then X can claim to be C, and no finger can be pointed at X either:
さらに、xが実際のエンドシステムではなく、ノードCとBの間の攻撃者である場合、xはcであると主張することができ、xに指を指すこともできません。
----- ----- -----
| A |--------| Y |--------| B |
----- ----- -----
/
/
/
/
/
/
----- -----
| C |-------| X |
----- -----
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.
このような攻撃をより難しくする別の方法は、新しいロケーターを受信したときに1つだけでなく、ロケーターでピアが利用できる定期的な検証を実行することです。
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.
マルチホームソリューションがこれに対処する3番目の方法は、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）と同じ（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」がサーバーに接続するのを防ぐ可能性がありますが（たまたま同じトランスポートポート番号を使用している場合）、攻撃者が切断された後に接続する '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'が近い将来に「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.
輸送の特性は、合法的なホストによって実行される作業の量は、それぞれの接続がマルチホームシグナル伝達を必要とするため、マルチホームサポートを使用する輸送接続の数に比例していることです。そして、同じことが攻撃者にも当てはまります。これは、攻撃者が、65,536（すべてのTCPソースポート番号に対して）接続をサーバーBに設定し、Bにそれらの接続を検討することにより、AからBへのポート80へのポート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の相対的なセキュリティに依存しているため、さらに、noidの逆ルックアップ）、ファーストコーム/ファーストサーブのシステム（WIMPは別のIDスペースを持つ例、PBKが別のIDスペースのない例であるマストアプローチ）を最初のホストに許可します。ID/アドレスを使用して、時間制限なしで請求します。
The protocol mechanisms added as part of a multihoming solution shouldn't introduce any new DoS in the mechanisms themselves. In particular, care must be taken not to:
マルチホームソリューションの一部として追加されたプロトコルメカニズムは、メカニズム自体に新しいDOSを導入するものではありません。特に、次のように注意する必要があります。
- create state on the first packet in an exchange, since that could result in state consumption attacks similar to the TCP SYN flooding attack.
- TCP Syn洪水攻撃と同様の状態消費攻撃をもたらす可能性があるため、交換で最初のパケットに状態を作成します。
- perform much work on the first packet in an exchange (such as expensive verification)
- 交換で最初のパケットで多くの作業を実行する（高価な検証など）
There is a potential chicken-and-egg problem here, because potentially one would want to avoid doing work or creating state until the peer has been verified, but verification will probably need some state and some work to be done. Avoiding any work does not seem possible, but good protocol design can often delay state creation until verification has been completed.
潜在的な鶏肉と卵の問題がここにあります。なぜなら、ピアが検証されるまで、仕事や状態の作成を避けたい可能性があるからです。作業を避けることは不可能と思われますが、優れたプロトコル設計は、検証が完了するまで状態の作成を遅らせることがよくあります。
A possible approach that solutions might investigate is to defer verification until there appears to be two different hosts (or two different locators for the same host) that want to use the same identifier. In such a case one would need to investigate whether a combination of impersonation and DoS attack can be used to prevent the discovery of the impersonation.
ソリューションが調査する可能性のあるアプローチは、同じ識別子を使用したい2つの異なるホスト（または同じホストの2つの異なるロケーター）があるように見えるまで、検証を延期することです。そのような場合、なりすましと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では、ドキュメントは既存のプロトコルベースのリダイレクト攻撃を提示しました。しかし、非プロトコルリダイレクト攻撃もあります。の1つに物理的なアクセスを得ることができる攻撃者
- 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.
パケットをリダイレクトすることもできます。これは、たとえば、物理的な侵入によって、または物理的なインフラストラクチャにアクセスできるスタッフを賄briすることによって可能になる可能性があります。このような攻撃はこの議論の範囲外ですが、攻撃者がマルチホーミングソリューションに対するプロトコルベースの攻撃を悪用するための犠牲を払うとき、留意する価値があります。プロトコルベースの攻撃を、侵入/贈収賄タイプの攻撃よりもはるかに高価にするのはやり過ぎです。
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設計チームによって作成されました。IljitschVanBeijnum、Steve Bellovin、Brian Carpenter、Mike O'Dell、Sean Doran、Dave Katz、Tony Li、Erik Nordmark、Pekka Savola。
Much of the awareness of these threats come from the work on Mobile IPv6 [MIPv6, NIKANDER03, AURA02].
これらの脅威に対する認識の多くは、モバイルIPv6 [Mipv6、Nikander03、Aura02]の研究から得られます。
As the document has evolved, the MULTI6 WG participants have contributed to the document. In particular: Masataka Ohta brought up privacy concerns related to stable identifiers. The suggestion to discuss transport versus IP granularity was contributed by Marcelo Bagnulo, who also contributed text to Appendix B. Many editorial clarifications came from Jari Arkko.
ドキュメントが進化するにつれて、Multi6 WGの参加者がドキュメントに貢献しました。特に：Masataka Ohtaは、安定した識別子に関連するプライバシーの懸念を引き起こしました。輸送とIPの粒度を議論するための提案は、マルセロ・バグヌロによって提供されました。マルセロ・バグヌロは、付録Bにもテキストを提供しました。
[NSRG] Lear, E. and R. Droms, "What's In A Name: Thoughts from the NSRG", Work in Progress, September 2003.
[NSRG] Lear、E。およびR. Droms、「名前の中にあるもの：NSRGからの考え」、2003年9月、進行中の作業。
[MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[Mipv6] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[AURA02] Aura, T. and J. Arkko, "MIPv6 BU Attacks and Defenses", Work in Progress, March 2002.
[Aura02] Aura、T。およびJ. Arkko、「Mipv6 BU攻撃と防御」、2002年3月、進行中の作業。
[NIKANDER03] Nikander, P., T. Aura, J. Arkko, G. Montenegro, and E. Nordmark, "Mobile IP version 6 Route Optimization Security Design Background", Work in Progress, December 2003.
[Nikander03] Nikander、P.、T。Aura、J。Arkko、G。Montenegro、およびE. Nordmark、「モバイルIPバージョン6ルート最適化セキュリティデザインの背景」、2003年12月の進行中。
[PAXSON01] V. Paxson, "An Analysis of Using Reflectors for Distributed Denial-of-Service Attacks", Computer Communication Review 31(3), July 2001.
[Paxson01] V. Paxson、「分散型サービス拒否攻撃にリフレクターを使用することの分析」、コンピューターコミュニケーションレビュー31（3）、2001年7月。
[INGRESS] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[Ingress] Ferguson、P。and D. Senie、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、BCP 38、RFC 2827、2000年5月。
[SCTP] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[SCTP] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。、およびV。Paxson、「Stream Control Transmission Protocol」、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のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 3041、2001年1月。
[DNS-THREATS] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[DNS-Threats] Atkins、D。およびR. Austein、「ドメイン名システムの脅威分析（DNS）」、RFC 3833、2004年8月。
[FYI18] Malkin, G., "Internet Users' Glossary", RFC 1983, August 1996.
[FYI18] Malkin、G。、「インターネットユーザー用語集」、RFC 1983、1996年8月。
[ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[ECN] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[OWNER] Nikander, P., "Denial-of-Service, Address Ownership, and Early Authentication in the IPv6 World", Security Protocols 9th International Workshop, Cambridge, UK, April 25-27 2001, LNCS 2467, pages 12-26, Springer, 2002.
[所有者] Nikander、P。、「IPv6 Worldにおけるサービス拒否、住所所有権、および早期認証」、セキュリティプロトコル9番目の国際ワークショップ、ケンブリッジ、英国、2001年4月25〜27日、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] Scott Bradner、Allison Mankin、Jeffrey Schiller、「専用キー（PBK）のフレームワーク」、2003年6月、進行中の作業。
[NOID] Erik Nordmark, "Multihoming without IP Identifiers", Work in Progress, July 2004.
[NOID] Erik Nordmark、「IP識別子なしのマルチホーム」、2004年7月、進行中の作業。
[HIP] Pekka Nikander, "Considerations on HIP based IPv6 multi-homing", Work in Progress, July 2004.
[HIP] Pekka Nikander、「股関節ベースのIPv6マルチホミングに関する考慮事項」、2004年7月の作業。
[WIMP] Jukka Ylitalo, "Weak Identifier Multihoming Protocol (WIMP)", Work in Progress, June 2004.
[wimp] Jukka ylitalo、「弱い識別子マルチホームプロトコル（WIMP）」、2004年6月の作業。
[CBHI] Iljitsch van Beijnum, "Crypto Based Host Identifiers", Work in Progress, February 2004.
[cbhi] iljitsch van beijnum、「暗号ベースのホスト識別子」、2004年2月に進行中の作業。
[TCPSECURE] M. Dalal (ed), "Transmission Control Protocol security considerations", Work in Progress, November 2004.
[TCPSECURE] M. DALAL（ed）、「トランスミッションコントロールプロトコルセキュリティに関する考慮事項」、2004年11月、Work in Progress。
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 最初はコミュニケーションを確立します。fqdnを検索して、connect（）またはsendto（）api呼び出しに渡されるものを見つけます。
o Comparing whether a peer entity is the same peer entity as in some previous communication.
o ピアエンティティが以前のコミュニケーションと同じピアエンティティであるかどうかを比較します。
o Using the identity of the peer for future communication ("callbacks") in the reverse direction, or to refer to a 3rd party ("referrals").
o 将来のコミュニケーション（「コールバック」）のためにピアのアイデンティティを逆方向に使用するか、サードパーティ（「紹介」）を参照します。
The other use of identifiers is as part of being able to redirect existing communication to use a different locator.
識別子の他の使用は、既存の通信をリダイレクトして異なるロケーターを使用できることの一部としてです。
The first class of use seems to be related to something about the ownership of the identifier; proving the "ownership" of the identifier should be sufficient in order to be authorized to control which locators are used to reach the identifier.
使用の最初のクラスは、識別子の所有権に関する何かに関連しているようです。識別子の「所有権」を証明することは、識別子に到達するために使用されるロケーターを制御することを許可するために十分でなければなりません。
The second class of use seems to be related to something more ephemeral. In order to redirect the existing communication to some other locator, it seems to be sufficient to prove that the entity is the same as the one that initiated the communication. One can view this as proving the ownership of some context, where the context is established around the time when the communication is initiated.
使用の2番目のクラスは、よりはかないものに関連しているようです。既存の通信を他のロケーターにリダイレクトするために、エンティティがコミュニケーションを開始したエンティティと同じであることを証明するだけで十分であると思われます。これは、コミュニケーションが開始された頃にコンテキストが確立されるコンテキストの所有権を証明するものとして見ることができます。
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 Exchange、[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.
ただし、識別子の不正使用を防ぐためのメカニズムはまったく異なる場合があります。計画的なリダイレクトを防ぐ1つの方法は、単に新しい識別子名スペースを導入せず、代わりに[noid]のように、サードパーティにアクセスするための既存の名前スペース、信頼できるサードパーティ、および十分に安全な方法に依存することです。。このようなアプローチは、基礎としてサードパーティ（NOIDの場合のDNS）に依存しています。マルチホミング国家の創造に関しては、この場合、計画されたリダイレクトは、今日のIPアドレスをリダイレクトするのと同じくらい簡単または硬いです。基本的に、これは通信の往復に関連付けられたリターンリュタビリティチェックに依存しています。これは、ルーティングシステムが問題のIPアドレスにパケットを配信することを確認します。
Alternatively, one can use the crypto-based identifiers such as in [HIP] or crypto-generated addresses as in [CBHI], which both rely on public-key crypto, to prevent premeditated attacks. In some cases it is also possible to avoid the problem by having one end of the communication use ephemeral identifiers as the initiator does in [WIMP]. This avoids premeditated redirection by detecting that some other entity is using the same identifier at the peer and switching to use another ephemeral ID. While the ephemeral identifiers might be problematic when used by applications, for instance due to callbacks or referrals, note that for the end that has the ephemeral identifier, one can skirt around the premeditated attacks (assuming the solution has a robust way to pick a new identifier when one is in use/stolen).
あるいは、[hip]や暗号化されたアドレスなどの暗号ベースの識別子を使用して、どちらも公共の鍵の暗号に依存しているように、計画的な攻撃を防ぐことができます。場合によっては、[wimp]で開始者が行うように、通信の一方の端を使用して短命識別子を使用することにより、問題を回避することもできます。これにより、他のエンティティがピアで同じ識別子を使用していることを検出し、別の一時的なIDを使用するために切り替えることにより、計画的リダイレクトを回避します。たとえば、コールバックや紹介のために、アプリケーションで使用される場合は短命識別子に問題がある場合がありますが、はかない識別子を持つ最終的には、計画された攻撃の周りにスカートできることに注意してください（ソリューションには新しいものを選択する堅牢な方法があると仮定します。識別子が使用/盗まれている場合）。
Assuming the problem can't be skirted by using ephemeral identifiers, there seem to be 3 types of approaches that can be used to establish some form of identity ownership:
一時的な識別子を使用して問題をスカートにすることができないと仮定すると、何らかの形のアイデンティティの所有権を確立するために使用できる3種類のアプローチがあるようです。
- A trusted third party, which states that a given identity is reachable at a given set of locators, so the endpoint reached at one of this locators is the owner of the identity.
- 信頼できる第三者は、特定のアイデンティティが特定のロケーターのセットで到達可能であると述べているため、このロケーターの1つでエンドポイントに到達したことは、IDの所有者です。
- Crypto-based identifiers or crypto-generated addresses where the public/private key pair can be used to prove that the identifier was generated by the node knowing the private key (or by another node whose public key hashes to the same value)
- 暗号ベースの識別子または暗号化されたアドレスは、パブリック/秘密キーペアを使用して、識別子が秘密キーを知っているノード（または公開キーが同じ値に及ぶ別のノードによって生成されたことを証明できることを証明できます。
- A static binding, as currently defined in IP, where you trust that the routing system will deliver the packets to the owner of the locator, and since the locator and the identity are one, you prove identity ownership as a sub-product.
- 現在IPで定義されている静的バインディングは、ルーティングシステムがロケーターの所有者にパケットを配信することを信頼しており、ロケーターとアイデンティティは1つであるため、アイデンティティの所有権をサブプロダクトとして証明します。
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.
ソリューションは、計画的および継続的な通信リダイレクトの両方に対して保護を提供する要素を組み合わせる必要があります。これはいくつかの方法で実行でき、現在の一連の提案には、すべての有用な組み合わせが含まれているようには見えません。たとえば、股関節CBIDプロパティを使用して、計画的な攻撃を防ぐことができますが、WIMPハッシュチェーンを使用して、継続的なリダイレクトを防ぐことができます。そして、おそらく他の興味深い組み合わせがあります。
A related, but perhaps separate aspect, is whether the solution provides for protection against man-in-the-middle attacks with on-path attackers. Some schemes, such as [HIP] and [NOID] do, but given that an on-path attacker can see and modify the data traffic whether or not it can modify the multihoming signaling, this level of protection seems like overkill. Protecting against on-path MITM for the data traffic can be done separately using IPsec, TLS, etc.
関連するが、おそらく別々の側面は、ソリューションがパス中の攻撃者との中間の攻撃に対する保護を提供するかどうかです。[hip]や[noid]などのいくつかのスキームは、パス上の攻撃者がマルチホームシグナルを変更できるかどうかを確認して変更できることを考えると、このレベルの保護が過剰に思えるようです。データトラフィックのためにオンパス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
Erik Nordmark Sun Microsystems、Inc。17 Network Circle Mountain View、CA 94025 USA
Phone: +1 650 786 2921
Fax: +1 650 786 5896
EMail: erik.nordmark@sun.com
Tony Li EMail: Tony.Li@tony.li
Tony Li Email：tony.li@tony.li
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。