[要約] RFC 6959は、Source Address Validation Improvement（SAVI）の脅威範囲に関する要約と目的を提供しています。SAVIは、ネットワーク上の不正な送信元アドレスを検出し、防止するための技術です。
Internet Engineering Task Force (IETF) D. McPherson
Request for Comments: 6959 VeriSign, Inc.
Category: Informational F. Baker
ISSN: 2070-1721 Cisco Systems
J. Halpern
Ericsson
May 2013
Source Address Validation Improvement (SAVI) Threat Scope
Source Address Validation Improvement（SAVI）脅威の範囲
Abstract
概要
The Source Address Validation Improvement (SAVI) effort aims to complement ingress filtering with finer-grained, standardized IP source address validation. This document describes threats enabled by IP source address spoofing both in the global and finer-grained context, describes currently available solutions and challenges, and provides a starting point analysis for finer-grained (host granularity) anti-spoofing work.
Source Address Validation Improvement（SAVI）の取り組みは、入力フィルタリングをよりきめ細かく標準化されたIP送信元アドレス検証で補完することを目的としています。このドキュメントでは、グローバルなコンテキストとよりきめ細かいコンテキストの両方でIP送信元アドレスのスプーフィングによって可能になる脅威について説明し、現在利用可能なソリューションと課題について説明し、きめ細かい（ホストの粒度）スプーフィング対策の開始点分析を提供します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6959.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6959で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Overview ........................................................3
2. Glossary of Terms ...............................................5
3. Spoof-Based Attack Vectors ......................................6
3.1. Blind Attacks ..............................................6
3.1.1. Single-Packet Attacks ...............................6
3.1.2. Flood-Based DoS .....................................7
3.1.3. Poisoning Attacks ...................................8
3.1.4. Spoof-Based Worm/Malware Propagation ................8
3.1.5. Reflective Attacks ..................................8
3.1.6. Accounting Subversion ...............................9
3.1.7. Other Blind Spoofing Attacks ........................9
3.2. Non-blind Attacks ..........................................9
3.2.1. Man in the Middle (MITM) ............................9
3.2.2. Third-Party Recon ..................................10
3.2.3. Other Non-blind Spoofing Attacks ...................10
4. Current Anti-spoofing Solutions ................................11
4.1. Topological Locations for Enforcement .....................13
4.1.1. Host to Link-Layer Neighbor via Switch .............13
4.1.2. Upstream Switches ..................................13
4.1.3. Upstream Routers ...................................14
4.1.4. ISP Edge PE Router .................................14
4.1.5. ISP NNI Router to ISP NNI Router ...................15
4.1.6. Cable Modem Subscriber Access ......................15
4.1.7. DSL Subscriber Access ..............................15
4.2. Currently Available Tools .................................16
4.2.1. BCP 38 .............................................16
4.2.2. Unicast RPF ........................................16
4.2.3. Port-Based Address Binding .........................16
4.2.4. Cryptographic Techniques ...........................17
4.2.5. Residual Attacks ...................................18
5. Topological Challenges Facing SAVI .............................18
5.1. Address Provisioning Mechanisms ...........................18
5.2. LAN Devices with Multiple Addresses .......................18
5.2.1. Routers ............................................18
5.2.2. NATs ...............................................19
5.2.3. Multi-instance Hosts ...............................19
5.2.4. Multi-LAN Hosts ....................................20
5.2.5. Firewalls ..........................................20
5.2.6. Mobile IP ..........................................20
5.2.7. Other Topologies ...................................21
5.3. IPv6 Considerations .......................................21
6. Analysis of Host Granularity Anti-spoofing .....................21
7. Security Considerations ........................................22
7.1. Privacy Considerations ....................................23
8. Acknowledgments ................................................24
9. References .....................................................24
9.1. Normative References ......................................24
9.2. Informative References ....................................24
The Internet Protocol, specifically IPv4 [RFC0791] and IPv6 [RFC2460], employs a connectionless hop-by-hop packet forwarding paradigm. A host connected to an IP network that wishes to communicate with another host on the network generates an IP packet with source and destination IP addressing information, among other options.
インターネットプロトコル、特にIPv4 [RFC0791]とIPv6 [RFC2460]は、コネクションレス型のホップバイホップパケット転送パラダイムを採用しています。ネットワーク上の別のホストと通信したいIPネットワークに接続されたホストは、送信元と宛先のIPアドレス情報などのオプションを含むIPパケットを生成します。
At the IP network layer, or Internet layer, there is typically no required transactional state when communicating with other hosts on the network. In particular, the network does not track any state about the hosts using the network. This is normally a benefit. However, as a consequence of this, hosts generating packets for transmission have the opportunity to spoof (forge) the source address of packets that they transmit, as the network does not have any way to tell that some of the information is false.
IPネットワーク層またはインターネット層では、ネットワーク上の他のホストと通信するときに、通常、必要なトランザクション状態はありません。特に、ネットワークは、ネットワークを使用するホストに関する状態を追跡しません。これは通常はメリットです。ただし、この結果として、送信用のパケットを生成するホストには、送信するパケットの送信元アドレスを偽装（偽造）する機会があります。これは、ネットワークに情報の一部が誤っていることを伝える方法がないためです。
Source address validation is necessary in order to detect and reject spoofed IP packets in the network, and contributes to the overall security of IP networks. This document deals with the subset of such validation done by the network based on observed traffic and policy. Such source address validation techniques enable detection and rejection of many spoofed packets, and also implicitly provide some assurances that the source address in an IP packet is legitimately assigned to the system that generated the packet.
送信元アドレスの検証は、ネットワーク内のスプーフィングされたIPパケットを検出して拒否するために必要であり、IPネットワークの全体的なセキュリティに貢献します。このドキュメントでは、監視されたトラフィックとポリシーに基づいてネットワークによって行われるそのような検証のサブセットを扱います。このような送信元アドレス検証技術は、多くの偽装パケットの検出と拒否を可能にし、IPパケットの送信元アドレスがパケットを生成したシステムに合法的に割り当てられていることを暗黙的に保証します。
Solutions such as those described in BCP 38 [RFC2827] provide guidelines for one such technique for network ingress filtering. However, if these techniques are not implemented at the ingress point of the IP network, then the validity of the source address cannot be positively ascertained. Furthermore, BCP 38 only implies source address validation at the Internet layer and is most often implemented on IP subnetwork address boundaries. One of the difficulties in encouraging the deployment of BCP 38 is that there is relatively little benefit until it is very widely deployed, which is not yet the case.
BCP 38 [RFC2827]で説明されているようなソリューションは、ネットワーク入力フィルタリングのためのそのような1つの手法のガイドラインを提供します。ただし、これらの手法がIPネットワークの入力ポイントに実装されていない場合、送信元アドレスの有効性を確実に確認できません。さらに、BCP 38はインターネット層でのソースアドレス検証のみを意味し、ほとんどの場合、IPサブネットワークアドレス境界に実装されます。 BCP 38の展開を推奨することの難しさの1つは、BCP 38が非常に広く展開されるまでは、ほとんどメリットがないことですが、これはまだ当てはまりません。
Hence, in order to try to get better behavior, it is helpful to look for an application like that described in BCP 38, but one that can be applied locally and give locally beneficial results. The local benefit would provide a reason for the site to deploy, while moving the Internet as a whole towards an environment where BCP 38 is widely effected. SAVI is aimed at providing more specific protection locally, with the benefit of better local behavior and, in conjunction with appropriate logging, better local traceability, while also providing better compliance with the cases dealt with by BCP 38.
したがって、より良い動作を得るために、BCP 38で説明されているようなアプリケーションを探すと役立ちますが、ローカルに適用でき、ローカルで有益な結果が得られるアプリケーションです。地域の利益は、サイトを展開する理由を提供すると同時に、BCP 38が広く影響を受ける環境に向けてインターネット全体を動かします。 SAVIは、ローカルでより具体的な保護を提供することを目的としています。ローカルの動作が向上し、適切なロギングと組み合わせてローカルのトレーサビリティが向上するとともに、BCP 38が扱うケースへのコンプライアンスが向上します。
It should be noted that while BCP 38 directs providers to provide protection from spoofed prefixes, it is clearly desirable for enterprise operators to provide that protection more locally, and with better traceability. This allows the enterprise to be a better Internet participant and to quickly detect and remedy problems when they occur. For example, when an enterprise receives a report of an attack originating within that enterprise, the operational staff desires to be able to track from the IP address sourcing the attack to the particular machine within the enterprise that is the source. This is typically simpler and more reliable than other techniques, such as trying to find the attack in ongoing outbound traffic. To do this, the enterprise needs usable address assignment and usage information (appropriate logging), as well as accurate information (SAVI), to determine that no other machine could have been using that address.
BCP 38はプロバイダーにスプーフィングされたプレフィックスからの保護を提供するように指示しますが、企業オペレーターがその保護をよりローカルに、より優れたトレーサビリティで提供することが明らかに望ましいことに注意してください。これにより、企業はより優れたインターネット参加者となり、問題が発生した場合に迅速に検出して修正することができます。たとえば、企業がその企業内で発生した攻撃のレポートを受け取った場合、運用スタッフは、IPアドレスから攻撃元の企業内の特定のマシンへの攻撃を追跡できるようにしたいと考えています。これは通常、進行中の発信トラフィックで攻撃を見つけようとするなど、他の手法よりも単純で信頼性が高くなります。これを行うには、企業は使用可能なアドレスの割り当てと使用状況の情報（適切なログ）、および正確な情報（SAVI）を必要とし、他のマシンがそのアドレスを使用していなかったと判断します。
Also, there is a possibility that in a LAN environment where multiple hosts share a single LAN or IP port on a switch or router, one of those hosts may spoof the source addresses of other hosts within the local subnet. Understanding these threats and the relevant topologies in which they're introduced is critical when assessing the threats that exist with source address spoofing.
また、複数のホストがスイッチまたはルーターの単一のLANまたはIPポートを共有するLAN環境では、それらのホストの1つがローカルサブネット内の他のホストのソースアドレスを偽装する可能性があります。送信元アドレスのスプーフィングで存在する脅威を評価する場合、これらの脅威とそれらが導入される関連トポロジを理解することが重要です。
This document provides additional details regarding spoof-based threat vectors and discusses implications of various network topologies.
このドキュメントでは、スプーフィングベースの脅威ベクトルに関する追加の詳細を提供し、さまざまなネットワークトポロジの影響について説明します。
The following acronyms and terms are used throughout this memo.
このメモでは、次の頭字語と用語が使用されています。
Binding Anchor: The relationship used by a device performing source address enforcement to perform the validation and enforcement. Examples in different situations include Layer 2 addresses or physical ports.
バインディングアンカー：検証と実施を実行するためにソースアドレス実施を実行するデバイスによって使用される関係。さまざまな状況での例には、レイヤー2アドレスまたは物理ポートが含まれます。
BGP: The Border Gateway Protocol, used to manage routing policy between large networks.
BGP：大規模ネットワーク間のルーティングポリシーの管理に使用されるボーダーゲートウェイプロトコル。
CPE Router: Customer Premises Equipment router. The router on the customer premises, whether owned by the customer or the provider. Also called the Customer Edge, or CE, router.
CPEルーター：顧客宅内機器ルーター。顧客が所有しているかプロバイダーが所有しているかにかかわらず、顧客構内のルーター。カスタマーエッジ（CE）ルーターとも呼ばれます。
IP Address: An Internet Protocol address, whether IPv4 or IPv6.
IPアドレス：IPv4でもIPv6でも、インターネットプロトコルアドレス。
ISP: Internet Service Provider. Any person or company that delivers Internet service to another.
ISP：Internet Service Provider。別の人にインターネットサービスを提供する人または会社。
MAC Address: An Ethernet address or comparable IEEE 802 series address.
MACアドレス：イーサネットアドレスまたは同等のIEEE 802シリーズアドレス。
NNI Router: Network-to-Network Interface router. This router interface faces a similar system operated by another ISP or other large network.
NNIルーター：ネットワーク間インターフェースルーター。このルーターインターフェイスは、別のISPまたは他の大規模ネットワークで運用されている同様のシステムに直面しています。
PE Router: Provider Edge router. This router faces a customer of an ISP.
PEルーター：プロバイダーエッジルーター。このルーターはISPの顧客に面しています。
Spoofing: The act of sending a datagram header whose contents at the link layer or network layer do not match the network policies and activities on address assignment or claiming. Generally, this corresponds to sending messages with source network or link-layer information that is assigned to or currently properly claimed by some other devices in the network.
スプーフィング：リンク層またはネットワーク層の内容がネットワークポリシーと一致しないデータグラムヘッダーを送信する行為、およびアドレス割り当てまたは要求に関するアクティビティ。通常、これは、ネットワーク内の他のデバイスに割り当てられているか、現在適切に要求されているソースネットワークまたはリンク層情報を含むメッセージを送信することに対応します。
TCP: The Transmission Control Protocol, used on end systems to manage data exchange.
TCP：データ交換を管理するためにエンドシステムで使用される伝送制御プロトコル。
uRPF: Unicast Reverse Path Forwarding. A procedure in which the route table, which is usually used to look up destination addresses and route towards them, is used to look up the source address and ensure that one is routing away from it. When this test fails, the event may be logged, and the traffic is commonly dropped.
uRPF：ユニキャストリバースパス転送。宛先アドレスの検索とそれらへのルーティングに通常使用されるルートテーブルを使用して、送信元アドレスを検索し、そこからルーティングされるようにする手順。このテストが失敗すると、イベントがログに記録され、トラフィックは通常ドロップされます。
Spoofing is employed on the Internet for a number of reasons, most of which are in some manner associated with malicious or otherwise nefarious activities. In general, two classes of spoof-based attack vectors exist: blind attacks and non-blind attacks. The following sections provide some information on blind and non-blind attacks; these sections also include information on attacks where the spoofing is primarily intended to interfere with tracing the attacks, as well as attacks where spoofing the source address is a necessary component to the damage or interference.
なりすましは、インターネット上でさまざまな理由で使用されています。そのほとんどは、何らかの方法で悪意のある活動または悪質な活動に関連しています。一般に、スプーフィングベースの攻撃ベクトルには、ブラインド攻撃と非ブラインド攻撃の2つのクラスがあります。次のセクションでは、ブラインド攻撃と非ブラインド攻撃に関するいくつかの情報を提供します。これらのセクションには、スプーフィングが攻撃の追跡を妨害することを主な目的とする攻撃、および送信元アドレスのスプーフィングが損傷または干渉に必要なコンポーネントである攻撃に関する情報も含まれています。
Blind attacks typically occur when an attacker isn't on the same local area network as a source or target, or when an attacker has no access to the data path between the attack source(s) and the target systems. In this situation, the attacker has no access to the source and target systems.
ブラインド攻撃は通常、攻撃者がソースまたはターゲットと同じローカルエリアネットワーク上にない場合、または攻撃者が攻撃ソースとターゲットシステム間のデータパスにアクセスできない場合に発生します。この状況では、攻撃者はソースシステムとターゲットシステムにアクセスできません。
One type of blind attacks, which we'll refer to here as "single-packet DoS (Denial of Service) attacks", involves an attacking system injecting spoofed information into the network, which either results in a complete crash of the target system, or in some manner poisons some network configuration or other information on a target system so as to impact network or other services.
ここでは「シングルパケットDoS（Denial of Service）攻撃」と呼ぶブラインド攻撃の1つのタイプは、ネットワークにスプーフィングされた情報を注入する攻撃システムを含み、ターゲットシステムの完全なクラッシュを引き起こします。または、何らかの方法で、ネットワークまたは他のサービスに影響を与えるために、ターゲットシステム上のいくつかのネットワーク構成または他の情報を汚染します。
An example of an attack that can cause a receiving system to crash is what is called a LAND (Local Area Network Denial) attack. A LAND attack would consist of an attacking system sending a packet (e.g., TCP SYN) to a target system that contains both a source and destination address of that target system. The packet would also contain a single value for the port number, used as both the source and destination port number. Certain target systems will then "lock up" when creating connection state associated with the packet or would get stuck in a state where a target system continuously replies to itself. As this is an attack that relies on bugs in the target, it is possible, but by no means certain, that this threat is no longer viable.
受信側システムをクラッシュさせる可能性のある攻撃の例は、いわゆるLAND（ローカルエリアネットワーク拒否）攻撃です。 LAND攻撃は、攻撃システムが、ターゲットシステムの送信元アドレスと宛先アドレスの両方を含むターゲットシステムにパケット（TCP SYNなど）を送信することで構成されます。パケットには、送信元と宛先の両方のポート番号として使用されるポート番号の単一の値も含まれます。その後、特定のターゲットシステムは、パケットに関連付けられた接続状態を作成するときに「ロックアップ」するか、ターゲットシステムが継続的に自身に応答する状態でスタックします。これはターゲット内のバグに依存する攻撃であるため、この脅威が存在しなくなる可能性はありますが、決して確実ではありません。
Another form of blind attack is a RST (reset) probe ([RFC4953], Section 2.3). The attacker sends a series of packets to a destination that is engaged in a long-lived TCP session. The packets are RST packets, and the attacker uses the known source and destination addresses and port numbers, along with guesses at the sequence number. If he can send a packet close enough to the right value, in theory he can terminate the TCP connection. While there are various steps that have been developed to ameliorate this attack, preventing the spoofing of source addresses completely prevents the attack from occurring.
ブラインド攻撃のもう1つの形式は、RST（リセット）プローブ（[RFC4953]、セクション2.3）です。攻撃者は、長期間のTCPセッションに従事している宛先に一連のパケットを送信します。パケットはRSTパケットであり、攻撃者は既知の送信元および宛先のアドレスとポート番号を、シーケンス番号での推測とともに使用します。正しい値に十分近いパケットを送信できる場合、理論的にはTCP接続を終了できます。この攻撃を改善するために開発されたさまざまな手順がありますが、送信元アドレスのスプーフィングを防止することで、攻撃は完全に防止されます。
Flood-based DoS attack vectors are particularly effective attacks on the Internet today. They usually entail flooding a large number of packets towards a target system, with the hopes of either exhausting connection state on the target system, consuming all packet processing capabilities of the target or intermediate systems, or consuming a great deal of bandwidth available to the target system such that they are essentially inaccessible.
洪水ベースのDoS攻撃ベクトルは、今日のインターネットに対する特に効果的な攻撃です。それらは通常、ターゲットシステムへの大量のパケットのフラッディングを伴い、ターゲットシステムの接続状態を使い果たすか、ターゲットシステムまたは中間システムのすべてのパケット処理機能を消費するか、またはターゲットで利用可能な大量の帯域幅を消費します。それらが本質的にアクセスできないようなシステム。
Because these attacks require no reply from the target system and require no legitimate transaction state, attackers often attempt to obfuscate the identity of the systems that are generating the attack traffic by spoofing the source IP address of the attacking traffic flows. Because ingress filtering isn't applied ubiquitously on the Internet today, spoof-based flooding attack vectors are typically very difficult to trace back. In particular, there may be one or more attacking sources beyond a network's border, and the attacking sources may or may not be legitimate sources; it's difficult to determine if the sources are not directly connected to the local routing system. These attacks might be seen as primarily needing to be addressed by BCP 38 deployment, which is not in scope for this document. However, as noted earlier, deployment of SAVI can help remediate lack of BCP 38 deployment, and even when BCP 38 is deployed, SAVI can help provide useful information for responding to such attacks.
これらの攻撃はターゲットシステムからの応答や正当なトランザクション状態を必要としないため、攻撃者は、攻撃トラフィックフローの送信元IPアドレスを偽装して、攻撃トラフィックを生成しているシステムのIDを難読化しようとすることがよくあります。イングレスフィルタリングは今日のインターネットでユビキタスに適用されていないため、スプーフィングベースのフラッディング攻撃ベクトルは通常、追跡するのが非常に困難です。特に、ネットワークの境界を越えて1つ以上の攻撃元が存在する可能性があり、攻撃元は正当な送信元である場合とそうでない場合があります。ソースがローカルルーティングシステムに直接接続されていないかどうかを判断するのは困難です。これらの攻撃は、主にBCP 38の展開で対処する必要があると見なされている可能性がありますが、このドキュメントでは扱いません。ただし、前述のように、SAVIの展開はBCP 38の展開不足を修正するのに役立ち、BCP 38が展開されている場合でも、SAVIはそのような攻撃への対応に役立つ情報を提供できます。
Common flood-based DoS attack vectors today include SYN floods, ICMP floods, and IP fragmentation attacks. Attackers may use a single legitimate or spoofed fixed attacking source address, although frequently they cycle through large swaths of address space. As a result, mitigating these attacks on the receiving end with source-based policies is extremely difficult.
今日の一般的なフラッドベースのDoS攻撃ベクトルには、SYNフラッド、ICMPフラッド、およびIPフラグメンテーション攻撃が含まれます。攻撃者は、単一の正当なまたは偽装された固定攻撃送信元アドレスを使用する可能性がありますが、頻繁に大量のアドレス空間を循環します。その結果、ソースベースのポリシーで受信側のこれらの攻撃を緩和することは非常に困難です。
If an attacker can inject messages for a protocol that requires control-plane activity, it may be possible to deny network control services at a much lower attack level. While there are various forms of protection deployed against this, they are by no means complete. Attacks that are harder to trace (such as with spoofed addresses) are of course of more concern.
攻撃者がコントロールプレーンアクティビティを必要とするプロトコルにメッセージを挿入できる場合、はるかに低い攻撃レベルでネットワーク制御サービスを拒否することが可能になる可能性があります。これに対して展開される保護にはさまざまな形式がありますが、完全なものではありません。追跡が困難な攻撃（スプーフィングされたアドレスなど）はもちろん、より懸念されます。
Furthermore, the motivator for spoof-based DoS attacks may actually be to encourage the target to filter explicitly on a given set of source addresses, in order to disrupt access to the target system by legitimate owner(s).
さらに、なりすましベースのDoS攻撃の動機は、正当な所有者によるターゲットシステムへのアクセスを妨害するために、ターゲットが特定のソースアドレスセットで明示的にフィルタリングすることを実際に促すことです。
While poisoning attacks can often be done with single packets, it is also true that a stream of packets can be used to find a window where the target will accept the incorrect information. In general, this can be used to perform broadly the same kinds of poisonings as above, with more versatility.
多くの場合、ポイズニング攻撃は単一のパケットで行われますが、パケットのストリームを使用して、ターゲットが不正な情報を受け入れるウィンドウを見つけることもできます。一般に、これは上記と同じ種類の中毒をより汎用的に実行するために使用できます。
One important class of poisoning attacks are attacks aimed at poisoning network or DNS cache information, perhaps to simply break a given host's connection or to enable MITM (Man in the Middle) or other attacks. Network-level attacks that could involve single-packet DoS include Address Resolution Protocol (ARP) cache poisoning and ICMP redirects. The most obvious example, which depends upon falsifying an IP source address, is an on-link attacker poisoning a router's ARP or Neighbor Discovery (ND) cache. The ability to forge a source address can also be helpful in causing a DNS cache to accept and use incorrect information.
ポイズニング攻撃の1つの重要なクラスは、ネットワークまたはDNSキャッシュ情報をポイズニングすることを目的とした攻撃です。これは、特定のホストの接続を単に破壊するか、MITM（Man in the Middle）またはその他の攻撃を有効にするためです。単一パケットのDoSを伴う可能性のあるネットワークレベルの攻撃には、アドレス解決プロトコル（ARP）キャッシュポイズニングとICMPリダイレクトが含まれます。 IP送信元アドレスの改ざんに依存する最も明白な例は、リンク上の攻撃者がルーターのARPまたはNeighbor Discovery（ND）キャッシュをポイズニングすることです。送信元アドレスを偽造する機能は、DNSキャッシュに不正な情報を受け入れて使用させるのにも役立ちます。
Self-propagating malware has been observed that spoofs its source address when attempting to propagate to other systems. Presumably, this was done to obfuscate the actual source address of the infected system. This attack is important both in terms of an attack vector that SAVI may help prevent and as a problem that SAVI can help solve by tracing back to find infected systems.
自己増殖型マルウェアが他のシステムに増殖しようとすると、その送信元アドレスを偽装することが確認されています。これはおそらく、感染したシステムの実際の送信元アドレスを難読化するために行われたと考えられます。この攻撃は、SAVIが防ぐのに役立つ可能性のある攻撃ベクトルと、SAVIがトレースして感染システムを見つけることで解決できる問題の両方の点で重要です。
Reflective amplification attacks -- wherein a sender sends a single packet to an intermediary, resulting in the intermediary sending a large number of packets, or much larger packets, to the target -- are a particularly potent DoS attack vector on the Internet today. Many of these attacks rely on using a false source address, so that the amplifier attacks the target by responding to the messages.
反射増幅攻撃-送信者が単一のパケットを中間者に送信し、中間者が多数のパケット、またははるかに大きなパケットをターゲットに送信する-は、今日のインターネットで特に強力なDoS攻撃ベクトルです。これらの攻撃の多くは、偽の送信元アドレスの使用に依存しているため、アンプはメッセージに応答してターゲットを攻撃します。
DNS is one of the common targets of such attacks. The amplification factor observed for attacks targeting DNS root and other top-level domain name infrastructures in early 2006 was on the order of 72:1 [VRSN-REPORT]. The result was that just 27 attacking sources with 512 kbps of upstream attack bandwidth could generate 1 Gbps of response attack traffic towards a target system.
DNSは、このような攻撃の一般的なターゲットの1つです。 2006年初頭にDNSルートおよびその他のトップレベルドメイン名インフラストラクチャを標的とした攻撃で観測された増幅率は、72：1のオーダーでした[VRSN-REPORT]。その結果、512 kbpsのアップストリーム攻撃帯域幅を持つ27の攻撃元が、ターゲットシステムに向けて1 Gbpsの応答攻撃トラフィックを生成する可能性がありました。
Smurf attacks employ a similar reflective amplification attack vector, exploiting traditional default IP-subnet-directed broadcast address behaviors that would result in all the active hosts on a given subnet responding to a (spoofed) ICMP echo request from an attacker and generating a large amount of ICMP echo response traffic directed towards a target system. These attacks have been particularly effective in large campus LAN environments where 50K or more hosts might reside on a single subnet.
Smurf攻撃は、同様の反射増幅攻撃ベクトルを採用し、攻撃者からの（スプーフィングされた）ICMPエコー要求に応答して特定のサブネット上のすべてのアクティブホストが応答し、大量を生成する従来のデフォルトのIPサブネット向けのブロードキャストアドレス動作を利用します。ターゲットシステムに向けられたICMPエコー応答トラフィックの数。これらの攻撃は、50K以上のホストが単一のサブネットに存在する可能性がある大規模なキャンパスLAN環境で特に効果的です。
If an attacker wishes to distribute content or other material in a manner that employs protocols that require only unidirectional flooding and generate no end-to-end transactional state, they may desire to spoof the source IP address of that content in order to avoid detection or accounting functions enabled at the IP layer. While this particular attack has not been observed, it is included here to reflect the range of power that spoofed addresses may have, even without the ability to receive responses.
攻撃者が、一方向のフラッディングのみを必要とし、エンドツーエンドのトランザクション状態を生成しないプロトコルを使用する方法でコンテンツまたはその他の素材を配布したい場合、検出を回避するために、そのコンテンツの送信元IPアドレスを偽装したい場合があります。 IP層で有効なアカウンティング機能。この特定の攻撃は確認されていませんが、応答を受信する能力がなくても、なりすましアドレスが持つ可能性のあるパワーの範囲を反映するためにここに含まれています。
Other blind spoofing attacks might include spoofing in order to exploit source routing or other policy-based routing implemented in a network. It may also be possible in some environments to use spoofing techniques to perform blind or non-blind attacks on the routers in a site or in the Internet. There are many techniques to mitigate these attacks, but it is well known that there are vulnerabilities in this area.
その他のブラインドスプーフィング攻撃には、ソースルーティングまたはネットワークに実装されているその他のポリシーベースのルーティングを悪用するためのスプーフィングが含まれる可能性があります。一部の環境では、スプーフィング技術を使用して、サイト内またはインターネット内のルーターにブラインド攻撃または非ブラインド攻撃を実行することもできます。これらの攻撃を軽減するためのテクニックはたくさんありますが、この領域に脆弱性があることはよく知られています。
Non-blind attacks often involve mechanisms such as eavesdropping on connections, resetting state so that new connections may be hijacked, and an array of other attack vectors. Perhaps the most common of these attack vectors are known as man-in-the-middle attacks. In this case, we are concerned not with an attacker who can modify a stream, but rather with one who has access to information from the stream and uses that information to launch his own attacks.
非ブラインド攻撃には、多くの場合、接続の盗聴、新しい接続が乗っ取られるように状態をリセットするなどのメカニズム、およびその他の一連の攻撃ベクトルが含まれます。おそらく、最も一般的なこれらの攻撃ベクトルは、中間者攻撃として知られています。この場合、私たちはストリームを変更できる攻撃者ではなく、ストリームからの情報にアクセスでき、その情報を使用して自分の攻撃を開始する攻撃者に関係しています。
Connection hijacking is one of the more common man-in-the-middle attack vectors. In order to hijack a connection, an attacker usually needs to be in the forwarding path and oftentimes employs TCP RST or other attacks in order to reset a transaction. The attacker may have already compromised a system that's in the forwarding path, or they may wish to insert themselves in the forwarding path.
接続ハイジャックは、より一般的なman-in-the-middle攻撃ベクトルの1つです。接続をハイジャックするには、通常、攻撃者は転送パスにいる必要があり、多くの場合、トランザクションをリセットするためにTCP RSTまたは他の攻撃を利用します。攻撃者は、転送パスにあるシステムをすでに危険にさらしている可能性があります。または、攻撃者は転送パスに自分自身を挿入しようとする可能性があります。
For example, an attacker with access to a host on a LAN segment may wish to redirect all the traffic on the local segment destined for a default gateway address (or all addresses) to itself in order to perform man-in-the-middle attacks. In order to accomplish this in IPv4, the attacker might transmit gratuitous ARP [RFC0826] messages or ARP replies to the Ethernet broadcast address ff:ff:ff:ff:ff:ff, notifying all the hosts on the segment that the IP address(es) of the target(s) now maps to its own Layer 2 address. The source IP address in this case is spoofed. Similar vulnerabilities exist in the IPv6 ND protocol [RFC4861], although the multicast requirements of the IPv6 ND protocol make this harder to perform with the same generality.
たとえば、LANセグメント上のホストにアクセスできる攻撃者は、中間者攻撃を実行するために、デフォルトゲートウェイアドレス（またはすべてのアドレス）を宛先とするローカルセグメント上のすべてのトラフィックを自分自身にリダイレクトしたい場合があります。 。これをIPv4で実現するために、攻撃者は不必要なARP [RFC0826]メッセージを送信するか、ARP応答をイーサネットブロードキャストアドレスff：ff：ff：ff：ff：ffに送信し、セグメント上のすべてのホストにIPアドレス（ es）ターゲットの独自のレイヤ2アドレスにマッピングされるようになりました。この場合の送信元IPアドレスは偽装されています。 IPv6 NDプロトコル[RFC4861]にも同様の脆弱性が存在しますが、IPv6 NDプロトコルのマルチキャスト要件により、同じ一般性でこれを実行することが難しくなっています。
Another example of a non-blind attack is third-party reconnaissance. The use of spoofed addresses, while not necessary for this, can often provide additional information and helps mask the traceability of the activity. The attack involves sending packets towards a given target system and observing either target or intermediate system responses. For example, if an attacker were to source spoof TCP SYN packets towards a target system from a large set of source addresses and observe responses from that target system or some intermediate firewall or other middlebox, they would be able to identify what IP-layer filtering policies may be in place to protect that system.
非ブラインド攻撃のもう1つの例は、サードパーティの偵察です。スプーフィングされたアドレスの使用は、これには必要ありませんが、多くの場合、追加情報を提供し、アクティビティの追跡可能性を隠すのに役立ちます。攻撃には、特定のターゲットシステムに向けてパケットを送信し、ターゲットまたは中間システムの応答を監視することが含まれます。たとえば、攻撃者が大量のソースアドレスのセットからスプーフTCP SYNパケットをターゲットシステムに送信し、そのターゲットシステムまたは中間ファイアウォールまたはその他のミドルボックスからの応答を観察した場合、攻撃者はどのIPレイヤーフィルタリングを特定できるでしょう。そのシステムを保護するためのポリシーが設定されている場合があります。
There are presumably many other attacks that can be performed based on the ability to spoof source addresses while seeing the target. Among other attacks, if there are multiple routers on-link with hosts, a host may be able to cause problems for the routing system by replaying modified or unmodified routing packets as if they came from another router.
標的を見ながら送信元アドレスを偽装する機能に基づいて実行できる他の多くの攻撃があると考えられます。他の攻撃の中でも、ホストとリンクしているルーターが複数ある場合、ホストは、変更されたまたは変更されていないルーティングパケットを別のルーターから送信されたかのように再生することにより、ルーティングシステムに問題を引き起こす可能性があります。
The goal of this work is to reduce datagrams with spoofed IP addresses from the Internet. This can be aided by identifying and dropping datagrams whose source address binding is incompatible with the Internet topology and learned information. This can be done at sites where the relationship between the source address and topology and binding information can be checked. For example, with these bindings, in many networks Internet devices can confirm that:
この作業の目標は、インターネットからのなりすましIPアドレスを使用してデータグラムを減らすことです。これは、送信元アドレスバインディングがインターネットトポロジおよび学習した情報と互換性がないデータグラムを識別して削除することで支援できます。これは、送信元アドレスとトポロジの関係、およびバインディング情報を確認できるサイトで実行できます。たとえば、これらのバインディングを使用すると、多くのネットワークでインターネットデバイスは次のことを確認できます。
o The IP source address is appropriate for the lower-layer address (they both identify the same system).
o IP送信元アドレスは下位層アドレスに適しています（どちらも同じシステムを識別します）。
o The IP source address is explicitly identified as appropriate for the physical topology; for example, the source address is appropriate for the Layer 2 switch port through which the datagram was received.
o IP送信元アドレスは、物理トポロジに適切であると明示的に識別されます。たとえば、送信元アドレスは、データグラムが受信されたレイヤ2スイッチポートに適しています。
o The prefix to which the IP source address belongs is appropriate for the part of the network topology from which the IP datagram was received (while the individual system may be unknown, it is reasonable to believe that the system is located in that part of the network).
o IP送信元アドレスが属するプレフィックスは、IPデータグラムを受信したネットワークトポロジの一部に適切です（個々のシステムは不明である可能性がありますが、システムがネットワークのその部分にあると考えるのは妥当です） ）。
In general, this involves two kinds of inspection. The primary action is checking the source IP address in the IP header of IP packets. In order to support such checking, the claimed or assigned IP addresses in messages concerned with such claims or assignments (IP ARP Requests and Responses, DHCP Replies, IPv6 ND Duplicate Address Detection (DAD) messages, etc.) must also be examined and, where appropriate, verified. SAVI is not concerned with verifying IP addresses in the contents of arbitrary higher-level protocol messages.
一般に、これには2種類の検査が含まれます。主なアクションは、IPパケットのIPヘッダーの送信元IPアドレスをチェックすることです。そのようなチェックをサポートするために、そのようなクレームまたは割り当て（IP ARP要求および応答、DHCP応答、IPv6 ND重複アドレス検出（DAD）メッセージなど）に関連するメッセージで要求または割り当てられたIPアドレスも調査する必要があります。必要に応じて、検証済み。 SAVIは、任意の上位レベルのプロトコルメッセージの内容に含まれるIPアドレスの検証には関与しません。
Filtering points farther away from the source of the datagram can make decreasingly authoritative assertions about the validity of the source address in the datagram. Nonetheless, there is value in dropping traffic that is clearly inappropriate and in maintaining knowledge of the level of trust one can place in an address.
データグラムの送信元から遠く離れたポイントをフィルタリングすると、データグラムの送信元アドレスの有効性に関する信頼性が低下します。それでも、明らかに不適切なトラフィックをドロップすること、およびアドレスに与えることができる信頼レベルの知識を維持することに価値があります。
Edge Network 1 CPE-ISP _.------------.
_.----------------. Ingress/ ISP A `--.
,--'' `---. ,' `.
,' +----+ +------+ +------+ `. / +------+ +------+ \\
( |Host+--+Switch+--+ CPE +---)-(---+ PE +- - - -+ NNI | )
`. +----+ +------+ |Router| ,' \\ |Router| |Router| /
`---. Host-neighbor +------+' `.+------+ +--+---+,'
`----------------'' '--. |_.-'
`------------'|
|
Edge Network 2 ISP-ISP Ingress |
_.----------------. _.----------.|
,--'' `---. ,-'' |--.
,' +----+ +------+ +------+ `. ,+------+ +--+---+.
( |Host+--+Switch+--+ CPE +---)---+-+ PE +- - - -+ NNI | \\
`. +----+ +------+ |Router| ,' ( |Router| |Router| )
`---. +------+' \\+------+ +------+ /
`----------------'' `. ,'
'--. ISP B _.-'
`----------''
Figure 1: Points Where an Address Can Be Validated
図1：住所を検証できるポイント
Figure 1 illustrates five related paths where a source address can be validated:
図1は、送信元アドレスを検証できる5つの関連パスを示しています。
o Host to switch, including host to host via the switch
o スイッチを介してホストからホストを含む、スイッチからホスト
o Host to enterprise CPE router
o ホストからエンタープライズCPEルーター
o Enterprise CPE router to ISP edge PE router, and the reverse
o エンタープライズCPEルーターからISPエッジPEルーターへ、およびその逆
o ISP NNI router to ISP NNI router
o ISP NNIルーターからISP NNIルーター
In general, datagrams with spoofed IP addresses can be detected and discarded by devices that have an authoritative mapping between IP addresses and the network topology. For example, a device that has an authoritative table between link-layer and IP addresses on a link can discard any datagrams in which the IP address is not associated with the link-layer address in the datagram. The degree of confidence in the source address depends on where the spoofing detection is performed, as well as the prefix aggregation in place between the spoofing detection and the source of the datagram.
一般に、IPアドレスが偽装されたデータグラムは、IPアドレスとネットワークトポロジとの間に信頼できるマッピングがあるデバイスによって検出および破棄できます。たとえば、リンク上のリンク層とIPアドレスの間に信頼できるテーブルがあるデバイスは、IPアドレスがデータグラムのリンク層アドレスに関連付けられていないデータグラムを破棄できます。送信元アドレスの信頼度は、スプーフィング検出が実行される場所と、スプーフィング検出とデータグラムの送信元との間で行われるプレフィックス集約に依存します。
There are a number of kinds of places, which one might call topological locations, where solutions may or should be deployed. As can be seen in the details below, as the point of enforcement moves away from a single cable attached directly to the host being validated, additional complications arise. It is likely that fully addressing many of these cases may require additional coordination mechanisms across the device that covers the disparate paths.
ソリューションを展開できる、または展開する必要がある場所には、トポロジー上の場所と呼ばれるさまざまな種類の場所があります。以下の詳細に示されているように、検証の対象が検証対象のホストに直接接続されている1本のケーブルから離れると、さらに複雑な問題が発生します。これらのケースの多くに完全に対処するには、異なるパスをカバーするデバイス全体で追加の調整メカニズムが必要になる場合があります。
The first point at which a datagram with a spoofed address can be detected is on the link to which the source of the datagram is connected. At this point in the network, the source link-layer and IP addresses are both available and can be validated against each other, and potentially against the physical port being used. A datagram in which the IP source address does not match the corresponding link-layer address can be discarded. Of course, the trust in the filtering depends on the trust in the method through which the mappings are developed. This mechanism can be applied by a first-hop router, or switch on the link. The first-hop switch has the most precise information for this.
スプーフィングされたアドレスを持つデータグラムを検出できる最初のポイントは、データグラムのソースが接続されているリンク上です。ネットワークのこの時点で、ソースリンク層とIPアドレスの両方が使用可能であり、相互に、場合によっては使用されている物理ポートに対して検証できます。 IP送信元アドレスが対応するリンク層アドレスと一致しないデータグラムは破棄できます。もちろん、フィルタリングへの信頼は、マッピングが作成される方法への信頼に依存します。このメカニズムは、ファーストホップルーターまたはリンク上のスイッチによって適用できます。ファーストホップスイッチには、このための最も正確な情報があります。
On a truly shared medium link, such as classic Ethernet, the best that can be done is to validate the link-layer and IP addresses against the mappings. When the link is not shared, such as when the hosts are connected through a switch, the source host can be identified precisely based on the port through which the datagram is received or the Layer 2 address if it is known to the switch. Port identification prevents transmission of malicious datagrams whose link-layer and IP addresses are both spoofed to mimic another host.
クラシックイーサネットなどの真に共有されているメディアリンクで実行できる最善の方法は、マッピングに対してリンク層とIPアドレスを検証することです。ホストがスイッチを介して接続されている場合など、リンクが共有されていない場合、送信元ホストは、データグラムの受信に使用したポート、またはスイッチが認識している場合はレイヤ2アドレスに基づいて正確に識別できます。ポートの識別により、リンク層とIPアドレスの両方が別のホストを模倣するように偽装された悪意のあるデータグラムの送信が防止されます。
Other kinds of links may fall at different places in this spectrum, with some wireless links having easier ways of identifying individual devices than others, for example.
他の種類のリンクは、このスペクトルのさまざまな場所に分類される可能性があります。たとえば、一部のワイヤレスリンクでは、個々のデバイスを他のデバイスより簡単に識別する方法があります。
In many topologies, there can be additional switches between the host-attached switch and the first router in the network. In these cases, additional issues can arise that affect SAVI operations. If the bridging topologies that connect the switches change, or if the Link Aggregation Control Protocol (LACP) [IEEE802.1AX], the Virtual Router Redundancy Protocol (VRRP), or link management operations change the links that are used to deliver traffic, the switch may need to move the SAVI state to a different port, or the state may need to be moved or reestablished on a different switch.
多くのトポロジでは、ホスト接続スイッチとネットワークの最初のルーターの間に追加のスイッチが存在する可能性があります。これらの場合、SAVI操作に影響する追加の問題が発生する可能性があります。スイッチを接続するブリッジトポロジが変更された場合、またはリンク集約制御プロトコル（LACP）[IEEE802.1AX]、仮想ルーター冗長プロトコル（VRRP）、またはリンク管理操作により、トラフィックの配信に使用されるリンクが変更された場合、スイッチはSAVI状態を別のポートに移動する必要がある場合があります。または、状態を別のスイッチで移動または再確立する必要がある場合があります。
Beyond the first-hop router, subsequent routers may additionally filter traffic from downstream networks. Because these routers do not have access to the link-layer address of the device from which the datagram was sent, they are limited to confirming that the source IP address is within a prefix that is appropriate for a downstream router from which the datagram was received.
ファーストホップルーターを超えて、後続のルーターはダウンストリームネットワークからのトラフィックをさらにフィルタリングできます。これらのルーターは、データグラムの送信元であるデバイスのリンク層アドレスにアクセスできないため、送信元IPアドレスが、データグラムの送信元のダウンストリームルーターに適したプレフィックス内にあることの確認に限定されます。 。
Options include the use of simple access lists or the use of Unicast Reverse Path Forwarding (uRPF). Access lists are generally appropriate only for the simplest cases, as management can be difficult. Strict uRPF accepts the source address on a datagram if and only if it comes from a direction that would be rational to send a datagram directed to the address, which means that the filter is derived from routing information. These filtering procedures are discussed in more detail in [RFC3704].
オプションには、単純なアクセスリストの使用またはユニキャストリバースパス転送（uRPF）の使用が含まれます。管理が困難な場合があるため、アクセスリストは通常、最も単純なケースにのみ適しています。厳格なuRPFは、アドレスにデータグラムを送信することが合理的である方向からのものである場合にのみ、データグラムの送信元アドレスを受け入れます。つまり、フィルターはルーティング情報から取得されます。これらのフィルタリング手順は、[RFC3704]でより詳細に説明されています。
In many cases, this router has access to information about what IP prefixes are to be used on a given subnet. This might be because it delegated that prefix through DHCP or monitored such a delegation. It may have advertised that prefix in IPv6 Neighbor Discovery Router Advertisement messages, or monitored such an advertisement. These can be seen as generalizations of the access lists above. When the topology permits, the router can enforce that these prefixes are used by the hosts.
多くの場合、このルーターは、特定のサブネットで使用されるIPプレフィックスに関する情報にアクセスできます。 DHCPを介してそのプレフィックスを委任したか、そのような委任を監視したことが原因である可能性があります。 IPv6近隣探索ルーターアドバタイズメッセージのそのプレフィックスをアドバタイズしたか、そのようなアドバタイズを監視した可能性があります。これらは、上記のアクセスリストの一般化と見なすことができます。トポロジーが許可すると、ルーターはこれらのプレフィックスがホストによって使用されるように強制できます。
An obvious special case of the discussion is with an ISP PE router, where it provides its customer with access. BCP 38 specifically encourages ISPs to use ingress filtering to limit the incidence of spoofed addresses in the network.
議論の明らかな特殊なケースは、顧客にアクセスを提供するISP PEルーターです。 BCP 38は、ISPがイングレスフィルタリングを使用して、ネットワーク内のなりすましアドレスの発生を制限することを特に推奨しています。
The question that the ISP must answer for itself is the degree to which it trusts its downstream network. A contract might be written between an ISP and its customer requiring that the customer apply the procedures of network ingress filtering to the customer's own network, although there's no way upstream networks would be able to validate this.
ISPが自ら答えなければならない問題は、ダウンストリームネットワークを信頼する度合いです。 ISPと顧客の間で契約が作成される場合があります。顧客自身のネットワークにネットワーク進入フィルタリングの手順を適用する必要がありますが、上流のネットワークでこれを検証することはできません。
Conversely, if the provider has assigned a single IP address to the customer (for example, with IPv4 NAT in the CPE), PE enforcement of BCP 38 can be on the full address, simplifying many issues.
逆に、プロバイダーが単一のIPアドレスを顧客に割り当てた場合（たとえば、CPEでIPv4 NATを使用）、BCP 38のPE実施を完全なアドレスに適用できるため、多くの問題が簡素化されます。
The considerations explicitly related to customer networks can also be applied to neighboring ISPs. An interconnection agreement might be written between two companies requiring that network ingress filtering policy be implemented on all customer connections. ISPs might, for example, mark datagrams from neighboring ISPs that do not sign such a contract or demonstrably do not behave in accordance with it as 'untrusted'. Alternatively, the ISP might place untrusted prefixes into a separate BGP community [RFC4271] and use that to advertise the level of trust to its BGP peers.
顧客ネットワークに明示的に関連する考慮事項は、近隣のISPにも適用できます。 2つの企業間で相互接続合意が作成され、すべての顧客接続にネットワーク進入フィルタリングポリシーを実装する必要がある場合があります。 ISPは、たとえば、そのような契約に署名しない、または明らかにそれに従って「信頼できない」として動作しない近隣ISPからのデータグラムにマークを付ける場合があります。あるいは、ISPは信頼できないプレフィックスを別のBGPコミュニティ[RFC4271]に配置し、それを使用して信頼レベルをBGPピアに通知することもできます。
In this case, uRPF is less effective as a validation tool, due to asymmetric routing. However, when it can be shown that spoofed addresses are present, the procedure can be applied.
この場合、非対称ルーティングのため、uRPFは検証ツールとしての効果が低くなります。ただし、スプーフィングされたアドレスが存在することが示される場合は、この手順を適用できます。
Part of the complication here is that in the abstract, it is very difficult to know what addresses should appear in packets sent from one ISP to another. Hence, packet-level filtering and enforcement are very difficult at this point in the network. Whether one views this as specific to the NNI, or a general property of the Internet, it is still a major factor that needs to be taken into account.
ここでの複雑さの一部は、抽象的には、あるISPから別のISPに送信されるパケットにどのアドレスが現れるべきかを知るのが非常に難しいことです。したがって、ネットワーク内のこの時点では、パケットレベルのフィルタリングと適用は非常に困難です。これをNNIに固有のものと見なす場合でも、インターネットの一般的な特性と見なす場合でも、考慮する必要のある主要な要素です。
Cable Modem Termination Systems (CMTS) employ Data Over Cable Service Interface Specification (DOCSIS) Media Access Control (MAC) domains. These share some properties with general switched networks, as described above in Section 4.1.1, and some properties with DSL access networks, as described below in Section 4.1.7. They also often have their own provisioning and monitoring tools that may address some of the issues described here.
ケーブルモデムターミネーションシステム（CMTS）は、Data over Cable Service Interface Specification（DOCSIS）Media Access Control（MAC）ドメインを採用しています。これらは、セクション4.1.1で説明したように、一般的なスイッチドネットワークといくつかのプロパティを共有し、セクション4.1.7で説明するように、DSLアクセスネットワークといくつかのプロパティを共有します。また、多くの場合、ここで説明する問題のいくつかに対処できる独自のプロビジョニングおよび監視ツールを備えています。
While DSL subscriber access can be bridged or routed, as seen by the service provider's device, it is generally the case that the protocols carry enough information to validate which subscriber is sending packets. Thus, for ensuring that one DSL subscriber does not spoof another, enforcement can generally be done at the aggregation router. This is true even when there is a bridged infrastructure among the subscribers, as DSL access generally requires all subscriber traffic to go through the access aggregation router.
DSLサブスクライバーアクセスは、サービスプロバイダーのデバイスからわかるように、ブリッジまたはルーティングできますが、通常、プロトコルは、どのサブスクライバーがパケットを送信しているかを検証するのに十分な情報を伝送します。したがって、1つのDSL加入者が別のDSL加入者を偽装しないことを保証するために、強制は通常、集約ルータで行うことができます。 DSLアクセスでは一般にすべてのサブスクライバートラフィックがアクセス集約ルーターを経由する必要があるため、サブスクライバー間にブリッジインフラストラクチャがある場合でも、これは当てはまります。
If it is desirable to provide spoofing protection among the devices within a residence, that would need to be provided by the CPE device, as the ISP's router does not have enough visibility to do that. It is not clear at this time that this problem is seen as a relevant threat.
住宅内のデバイス間でスプーフィング保護を提供することが望ましい場合は、ISPのルーターがそれを行うのに十分な可視性を持っていないため、CPEデバイスによって提供される必要があります。現時点では、この問題が関連する脅威と見なされているかどうかは不明です。
There are a number of tools that have been developed, and have seen some deployment, for addressing these attacks.
これらの攻撃に対処するために開発され、いくつかの展開が見られた多数のツールがあります。
If BCP 38 [RFC2827] is implemented in LAN segments, it is typically done so on subnetwork boundaries and traditionally relates only to network-layer ingress filtering policies. The result is that hosts within the segment cannot spoof packets from address space outside of the local segment itself; however, they may still spoof packets using sources' addresses that exist within the local network segment.
BCP 38 [RFC2827]がLANセグメントに実装されている場合、通常はサブネットワーク境界で実装され、従来はネットワーク層の入力フィルタリングポリシーのみに関係しています。その結果、セグメント内のホストは、ローカルセグメント自体の外部のアドレス空間からのパケットを偽装できません。ただし、ローカルネットワークセグメント内に存在する送信元のアドレスを使用してパケットを偽装する可能性があります。
Unicast RPF is a crude mechanism to automate definition of BCP 38 style filters based on routing table information. Its applicability parallels that of BCP 38, although deployment caveats exist, as outlined in [RFC3704].
ユニキャストRPFは、ルーティングテーブル情報に基づいてBCP 38スタイルフィルターの定義を自動化するための大まかなメカニズムです。 [RFC3704]で概説されているように、展開の警告が存在しますが、その適用性はBCP 38のそれと類似しています。
Much of the work of SAVI is initially targeted at minimizing source address spoofing in the LAN. In particular, if mechanisms can be defined to accommodate configuration of port binding information for IP, either to a port, to an unchangeable or authenticated MAC address, or to other credentials in the packet such that an impostor cannot create the needed values, a large portion of the spoofing threat space in the LAN can be marginalized.
SAVIの作業の多くは、当初、LANでの送信元アドレスのなりすましを最小限に抑えることを目的としています。特に、IP、ポート、変更不可または認証済みのMACアドレス、またはパケット内の他の資格情報のいずれかに、IPのポートバインディング情報の構成に対応するメカニズムを定義して、詐欺師が必要な値を作成できない場合、大きなLAN内のスプーフィング脅威スペースの一部は、取り残される可能性があります。
However, establishing this binding is not trivial and varies across both topology types and address allocation mechanisms.
ただし、このバインディングの確立は簡単ではなく、トポロジタイプとアドレス割り当てメカニズムの両方で異なります。
Binding of a single link-layer and network-layer address to a port may initially seem trivial. However, two primary areas exist that can complicate such techniques. In particular, these areas involve topologies where more than a single IP-layer address may be associated with a MAC address on a given port, or where multiple hosts are connected via a single physical port. Furthermore, if one or more dynamic address allocation mechanisms such as DHCP are employed, then some mechanism must exist to associate those IP-layer addresses with the appropriate link-layer ports as addresses are allocated or reclaimed.
単一のリンク層とネットワーク層のアドレスをポートにバインドすることは、最初は簡単に思えるかもしれません。ただし、このような手法を複雑にする可能性のある2つの主要な領域が存在します。特に、これらの領域には、特定のポートのMACアドレスに複数のIPレイヤーアドレスが関連付けられているトポロジ、または複数のホストが単一の物理ポートを介して接続されているトポロジが含まれます。さらに、DHCPなどの1つ以上の動的アドレス割り当てメカニズムが採用されている場合、アドレスが割り当てられたり再利用されたりするときに、それらのIPレイヤーアドレスを適切なリンクレイヤーポートに関連付けるためのメカニズムが必要です。
For IPv4, the primary and very widely used automated address assignment technique is DHCP-based address assignment. This can be coupled with filtering policies that control which hosts can originate DHCP replies. Under such circumstances, SAVI switches can treat DHCP replies as authoritative sources of IP address binding information. By eavesdropping on the DHCP exchanges, the SAVI switch can create the bindings needed for address usage enforcement.
IPv4の場合、主要で非常に広く使用されている自動アドレス割り当て手法は、DHCPベースのアドレス割り当てです。これは、どのホストがDHCP応答を発信できるかを制御するフィルタリングポリシーと組み合わせることができます。このような状況では、SAVIスイッチはDHCP応答をIPアドレスバインディング情報の信頼できるソースとして扱うことができます。 DHCP交換を盗聴することにより、SAVIスイッチはアドレス使用の強制に必要なバインディングを作成できます。
For IPv6, there are two common automated address assignment techniques. While there are many variations and details, for purposes of understanding the threats and basic responses, these are Stateless Address Autoconfiguration (SLAAC) and DHCP-based IPv6 address assignment. For DHCP-based IPv6 address assignment, the techniques above are applicable and suitable.
IPv6の場合、2つの一般的な自動アドレス割り当て手法があります。多くのバリエーションと詳細がありますが、脅威と基本的な応答を理解するために、ステートレスアドレス自動構成（SLAAC）とDHCPベースのIPv6アドレス割り当てがあります。 DHCPベースのIPv6アドレス割り当ての場合、上記の手法が適用可能で適切です。
When SLAAC is used for IPv6 address assignment, the switches can observe the duplicate address detection messages and use those to create the enforcement bindings. This enables the switches to ensure that only properly claimed IP addresses are used for data traffic. It does not enforce that these addresses are assigned to the hosts, since SLAAC does not have a notion of address assignment.
SLAACがIPv6アドレス割り当てに使用される場合、スイッチは重複アドレス検出メッセージを監視し、それらを使用して施行バインディングを作成できます。これにより、スイッチは、適切に要求されたIPアドレスのみがデータトラフィックに使用されるようにすることができます。 SLAACにはアドレス割り当ての概念がないため、これらのアドレスがホストに割り当てられることは強制されません。
IEEE 802.1x is an authentication protocol that permits a network to determine the identity of a user seeking to join it and apply authorization rules to permit or deny the action. In and of themselves, such tools confirm only that the user is authorized to use the network, but they do not enforce what IP address the user is allowed to use. It is worth noting that elements of 802.1x may well be useful as binding anchors for SAVI solutions.
IEEE 802.1xは、ネットワークがネットワークに参加しようとしているユーザーのIDを決定し、アクションを許可または拒否するための承認規則を適用できるようにする認証プロトコルです。このようなツール自体は、ユーザーがネットワークの使用を許可されていることのみを確認しますが、ユーザーが使用できるIPアドレスを強制しません。 802.1xの要素がSAVIソリューションのバインディングアンカーとして役立つ可能性があることは注目に値します。
MITM and replay attacks can typically be mitigated with cryptographic techniques. However, many of the applications today either don't or can't employ cryptographic authentication and protection mechanisms. ARP for IPv4 does not use such protection. While Secure Neighbor Discovery (SEND) provides such protection for the IPv6 ND protocol, SEND is not widely used to date. Usage of such techniques is outside the scope of this document.
MITMおよびリプレイ攻撃は、通常、暗号化技術で軽減できます。ただし、今日のアプリケーションの多くは、暗号化認証および保護メカニズムを採用していないか、採用できません。 ARP for IPv4はそのような保護を使用しません。 Secure Neighbor Discovery（SEND）はIPv6 NDプロトコルにそのような保護を提供しますが、SENDは今日まで広く使用されていません。このようなテクニックの使用は、このドキュメントの範囲外です。
While DNSSEC will significantly help protect DNS from the effects of spoof-based poisoning attacks, such protection does not help protect the rest of the network from spoofed attacks.
DNSSECは、なりすましベースのポイズニング攻撃の影響からDNSを保護するのに大きく役立ちますが、そのような保護は、ネットワークの残りの部分をなりすまし攻撃から保護するのに役立ちません。
It should be understood that not all combinations of network, service, and enforcement choices will result in a protectable network. For example, if one uses conventional SLAAC in a switched network, but tries to only provide address enforcement on the routers on the network, then the ability to provide protection is severely limited.
ネットワーク、サービス、施行の選択のすべての組み合わせが保護可能なネットワークをもたらすとは限らないことを理解する必要があります。たとえば、スイッチドネットワークで従来のSLAACを使用しているが、ネットワーク上のルーターにのみアドレス強制を提供しようとすると、保護を提供する機能が大幅に制限されます。
As noted previously, topological components and address allocation mechanisms have significant implications on what is feasible with regard to link-layer address and IP address port bindings. The following sections discuss some of the various topologies and address allocation mechanisms that proposed SAVI solutions should attempt to address.
前述のように、トポロジコンポーネントとアドレス割り当てメカニズムは、リンク層アドレスとIPアドレスポートバインディングに関して何が可能かについて重要な意味があります。次のセクションでは、提案されたSAVIソリューションが対処する必要があるさまざまなトポロジとアドレス割り当てメカニズムのいくつかについて説明します。
In a strictly static environment, configuration management for access filters that map link-layer and network-layer addresses on a specific switch port might be a viable option. However, most networks, certainly those that accommodate actual human users, are much more dynamic in nature. As such, mechanisms that provide port-MAC-IP bindings need to accommodate dynamic address allocation schemes enabled by protocols such as DHCP, DHCPv6 for address allocation, and IPv6 Stateless Address Autoconfiguration.
厳密に静的な環境では、特定のスイッチポートでリンク層アドレスとネットワーク層アドレスをマップするアクセスフィルターの構成管理が実行可能なオプションになる場合があります。ただし、ほとんどのネットワークは、確かに実際のユーザーに対応するものであり、本質的にははるかに動的です。そのため、ポートMAC-IPバインディングを提供するメカニズムは、DHCP、アドレス割り当て用のDHCPv6、IPv6ステートレスアドレス自動構成などのプロトコルによって有効にされる動的アドレス割り当てスキームに対応する必要があります。
From the perspective of network topology, consider hosts connected to switch ports that may have one or more IP addresses, and devices that forward packets from other network segments. It is much harder to enforce port-MAC-IP bindings on traffic from such hosts and devices than for traffic from more simply connected devices.
ネットワークトポロジの観点から、1つ以上のIPアドレスを持つ可能性のあるスイッチポートに接続されたホスト、および他のネットワークセグメントからパケットを転送するデバイスを検討してください。より単純に接続されたデバイスからのトラフィックよりも、そのようなホストおよびデバイスからのトラフィックにポートMAC-IPバインディングを適用することははるかに困難です。
Routers are the most obvious examples of devices for which it is problematic to implement port-MAC-IP bindings. Routers not only originate packets themselves and often have multiple interfaces, but also forward packets from other network segments. As a result, it's difficult for port-MAC-IP binding rules to be established a priori, because it's likely that many addresses and IP subnets should be associated with the port-MAC in question.
ルーターは、ポートMAC MACバインディングを実装することが問題となるデバイスの最も明白な例です。ルーターはパケット自体を発信するだけでなく、多くの場合複数のインターフェイスを備えているだけでなく、他のネットワークセグメントからのパケットも転送します。その結果、多くのアドレスとIPサブネットを問題のポートMACに関連付ける必要がある可能性が高いため、ポートMAC-IPバインディングルールをアプリオリに確立することは困難です。
Validating traffic from prefix-based and multi-address NATs is also problematic, for the same reasons as for routers. Because they may forward traffic from an array of addresses, validation requires advance knowledge of the IPs that should be associated with a given port-MAC pair.
プレフィックスベースおよびマルチアドレスNATからのトラフィックの検証も、ルーターと同じ理由で問題があります。アドレスの配列からトラフィックを転送する可能性があるため、検証には、特定のポートとMACのペアに関連付ける必要があるIPの事前知識が必要です。
Another example that introduces complexities is that of multi-instance hosts attached to a switch port. These are single physical devices that internally run multiple physical or logical hosts. When the device is a blade server, e.g., with internal blades each hosting a physical machine, there is essentially a physical switch inside the blade server. While feasible, this creates some complexity for determining where enforcement logic can or should live.
複雑さを導入する別の例は、スイッチポートに接続されたマルチインスタンスホストの例です。これらは、複数の物理ホストまたは論理ホストを内部で実行する単一の物理デバイスです。デバイスがブレードサーバーである場合、たとえば、内部ブレードがそれぞれ物理マシンをホストしている場合、ブレードサーバー内には基本的に物理スイッチがあります。これは実行可能ですが、施行ロジックがどこにあるべきか、またはどこにあるべきかを決定するためにいくらかの複雑さを生み出します。
Logically distinct hosts, such as are provided by many varieties of virtualization logic, result in a single physical host and connect to a single port on the Ethernet switch in the topology, actually having multiple internal virtual machines. Each virtual machine may have its own IP and MAC addresses. These are connected by what is essentially (or sometimes literally) an internal LAN switch. While this internal switch may be a SAVI enforcement point to help control threats among the virtual hosts, or between virtual hosts and other parts of the network, such enforcement cannot be counted on in all implementations. If the virtual machines are interconnected by the internal switch, then that logical device is the first switch for the purposes of this analysis.
多くの種類の仮想化ロジックによって提供されるような論理的に異なるホストは、単一の物理ホストになり、トポロジ内のイーサネットスイッチの単一のポートに接続し、実際には複数の内部仮想マシンを持ちます。各仮想マシンは、独自のIPアドレスとMACアドレスを持つことができます。これらは、本質的に（場合によっては文字通り）内部LANスイッチで接続されます。この内部スイッチは、仮想ホスト間、または仮想ホストとネットワークの他の部分の間の脅威を制御するのに役立つSAVI実施ポイントである場合がありますが、そのような実施はすべての実装に当てはまるわけではありません。仮想マシンが内部スイッチによって相互接続されている場合、その論理デバイスは、この分析の目的で最初のスイッチです。
A further complication with multi-instance hosts is that in many environments, these hosts may move while retaining their IP addresses. This can be an actual relocation of the running software, or a backup instance taking over the functions of the software. In both cases, the IP address will appear at a new topological location. Depending upon the protocols used, it may have the same MAC address or a different one, and the system may or may not issue a gratuitous ARP request after relocation. When such a move is done without changing the MAC address, the SAVI switches will need to update their state. While ARP may be helpful, traffic detection, switch-based neighbor solicitation, interaction with an orchestration system, or other means may be used.
マルチインスタンスホストのさらなる複雑さは、多くの環境で、これらのホストがIPアドレスを保持したまま移動する可能性があることです。これは、実行中のソフトウェアの実際の再配置、またはソフトウェアの機能を引き継ぐバックアップインスタンスにすることができます。どちらの場合も、IPアドレスは新しいトポロジーの場所に表示されます。使用するプロトコルに応じて、MACアドレスは同じでも異なるものでもよく、再配置後にシステムが無償のARP要求を発行する場合と発行しない場合があります。 MACアドレスを変更せずにそのような移動を行う場合、SAVIスイッチはその状態を更新する必要があります。 ARPは役立つかもしれませんが、トラフィック検出、スイッチベースのネイバー請求、オーケストレーションシステムとの相互作用、または他の手段が使用される場合があります。
Multi-interface hosts, in particular those that are multihomed and may forward packets from any of a number of source addresses, can be problematic as well. In particular, if a port-MAC-IP binding is made on each of the interfaces, and then either a loopback IP or the address of a third interface is used as the source address of a packet forwarded through an interface for which the port-MAC-IP binding doesn't map, the traffic may be discarded. Static configuration of port-MAC-IP bindings may accommodate this scenario, although some a priori knowledge of address assignment and topology is required.
マルチインターフェイスホスト、特にマルチホームであり、多数の送信元アドレスのいずれかからパケットを転送する可能性のあるホストも、問題が発生する可能性があります。特に、各インターフェイスでポートMAC-IPバインディングが行われ、ループバックIPまたは3番目のインターフェイスのアドレスが、ポートが接続されているインターフェイスを介して転送されるパケットのソースアドレスとして使用される場合MAC-IPバインディングはマッピングされず、トラフィックが破棄される場合があります。アドレスMACとIPバインディングの静的構成はこのシナリオに対応できますが、アドレスの割り当てとトポロジに関するある程度の事前知識が必要です。
While it is rare to use loopback addressing or to send packets out of one interface with the source address of another, these rarities do legitimately occur. Some servers, particularly ones that have underlying virtualization, use loopback techniques for management.
ループバックアドレッシングを使用したり、あるインターフェイスから別の送信元アドレスでパケットを送信したりすることはまれですが、これらのまれなことが発生します。一部のサーバー、特に基盤となる仮想化を持つサーバーは、管理にループバック技術を使用します。
Firewalls that forward packets from other network segments, or serve as a source for locally originated packets, suffer from the same issues as routers.
他のネットワークセグメントからのパケットを転送するファイアウォール、またはローカルで発信されたパケットのソースとして機能するファイアウォールには、ルーターと同じ問題があります。
Mobile IP hosts in both IPv4 and IPv6 are proper members of the site where they are currently located. Their care-of address is a properly assigned address that is on the link they are using, and their packets are sent and received using that address. Thus, they do not introduce any additional complications. (There was at one time consideration of allowing mobile hosts to use their home address when away from home. This was not done, precisely to ensure that mobile hosts comply with source address validity requirements.) Mobile hosts with multiple physical interfaces fall into the cases above.
IPv4とIPv6の両方のモバイルIPホストは、それらが現在配置されているサイトの適切なメンバーです。それらの気付アドレスは、使用しているリンク上にある適切に割り当てられたアドレスであり、そのパケットはそのアドレスを使用して送受信されます。したがって、追加の合併症は発生しません。 （かつては、モバイルホストが自宅から離れているときにホームアドレスを使用できるようにすることを検討していました。これは、モバイルホストが送信元アドレスの有効性要件に準拠していることを確実にするために行われていませんでした。）上記。
Mobile IP Home Agents (HAs) are somewhat more interesting. Although they are (typically) fixed devices, they are required to send and receive packets addressed from or to any currently properly registered mobile node. From an analysis point of view, even though the packets that an HA handles are actually addressed to or from the link the HA is on, it is probably best to think of them as routers, with a virtual interface to the actual hosts they are serving. Thus, if the Mobile IP HA is trusted, it can itself perform IP source address checking on the packets it forwards on behalf of mobile nodes. This would utilize bindings established by the Mobile IP registration mechanisms.
モバイルIPホームエージェント（HA）は、もう少し興味深いものです。それらは（通常）固定デバイスですが、現在適切に登録されているモバイルノードとの間でアドレス指定されたパケットを送受信するために必要です。分析の観点から、HAが処理するパケットが実際にアドレス指定されている、またはHAが存在するリンクからパケットが送信されている場合でも、それらをルーターと見なし、実際のホストへの仮想インターフェースを備えたものと考えるのがおそらく最良です。 。したがって、モバイルIP HAが信頼できる場合、モバイルIP HA自体が、モバイルノードに代わって転送するパケットに対してIP送信元アドレスチェックを実行できます。これは、モバイルIP登録メカニズムによって確立されたバインディングを利用します。
Any topology that results in the possibility that a device connected to a switch port may forward packets with more than a single source address for a packet that it originated may be problematic. Additionally, address allocation schemas introduce additional considerations when examining a given SAVI solutions space.
スイッチポートに接続されたデバイスが、送信元のパケットに複数の送信元アドレスを持つパケットを転送する可能性があるトポロジでは、問題が発生する可能性があります。さらに、アドレス割り当てスキーマは、特定のSAVIソリューションスペースを調べるときに追加の考慮事項を導入します。
IPv6 introduces additional capabilities that indirectly complicate the spoofing analysis. IPv6 introduces and recommends the use of SLAAC [RFC4862]. This allows hosts to determine their IP prefix, select an Interface Identifier (IID), and then start communicating. While there are many advantages to this, the absence of control interactions complicates the process of behavioral enforcement.
IPv6は、スプーフィング分析を間接的に複雑にする追加機能を導入します。 IPv6はSLAAC [RFC4862]の使用を導入および推奨しています。これにより、ホストはIPプレフィックスを決定し、インターフェイス識別子（IID）を選択して、通信を開始できます。これには多くの利点がありますが、制御の相互作用がないため、行動の強制のプロセスが複雑になります。
An additional complication is the very large IID space. Again, this 64-bit IID space provided by IPv6 has many advantages. It provides the opportunity for many useful behaviors. However, it also means that in the absence of controls, hosts can mint anonymous addresses as often as they like, modulo the idiosyncrasies of the duplicate address procedure. Like many behaviors, this is a feature for some purposes and a problem for others. For example, without claiming the entire IID space, an on-link attacker may be able to generate enough IP addresses to fill the Neighbor Discovery table space of the other Layer 3 (L3) devices on the link, including switches that are monitoring L3 behavior. This could seriously interfere with the ability of other devices on the link to function.
さらに複雑なのは、非常に大きなIIDスペースです。この場合も、IPv6によって提供されるこの64ビットIIDスペースには多くの利点があります。それは多くの有用な行動の機会を提供します。ただし、これは、制御がない場合、ホストは、重複アドレス手順の特異性を法として、好きなだけ匿名アドレスを作成できることも意味します。多くの動作と同様に、これはいくつかの目的のための機能であり、他の問題です。たとえば、IIDスペース全体を要求することなく、リンク上の攻撃者は、L3の動作を監視しているスイッチを含む、リンク上の他のレイヤー3（L3）デバイスの近隣探索テーブルスペースを満たすのに十分なIPアドレスを生成できる可能性があります。 。これは、リンク上の他のデバイスが機能する能力に深刻な干渉を与える可能性があります。
Applying anti-spoofing techniques at the host level enables a site to achieve several valuable objectives. While it is likely the case that for many site topologies and policies full source spoofing protection is not possible, it is also true that for many sites there are steps that can be taken that provide benefit.
ホストレベルでスプーフィング対策技術を適用すると、サイトはいくつかの価値ある目的を達成できます。多くのサイトトポロジとポリシーでは完全なソーススプーフィング保護が不可能である可能性が高いですが、多くのサイトでは、利益をもたらすために実行できる手順があることも事実です。
One important class of benefit is masquerade prevention. Security threats involving one machine masquerading as another, for example, in order to hijack an apparently secure session, can occur within a site with significant impact. Having mechanisms such that host-facing devices prevent this is a significant intra-site security improvement. Given that security experts report that most security breaches are internal, this can be valuable. One example of this is that such techniques should mitigate internal attacks on the site routing system.
利益の重要なクラスの1つは、なりすまし防止です。たとえば、明らかに安全なセッションを乗っ取るために、1台のマシンが別のマシンになりすましたセキュリティ上の脅威は、サイト内で発生し、大きな影響を与える可能性があります。ホストに面したデバイスがこれを防止するようなメカニズムを持つことは、サイト内のセキュリティを大幅に改善することです。セキュリティの専門家が、ほとんどのセキュリティ違反は内部的なものであると報告していることを考えると、これは価値があります。この1つの例は、そのような手法がサイトルーティングシステムに対する内部攻撃を軽減することです。
A second class of benefit is related to the traceability described above. When a security incident is detected, either within a site or externally (and traced to the site), it can be critical to determine the actual source of the incident. If address usage can be tied to the kinds of anchors described earlier, this can help in responding to security incidents.
2番目のクラスの利点は、上記のトレーサビリティに関連しています。サイト内または外部で（およびサイトにトレースされて）セキュリティインシデントが検出された場合、インシデントの実際のソースを特定することが重要になる場合があります。アドレスの使用が前述の種類のアンカーに関連付けられる場合、これはセキュリティインシデントへの対応に役立ちます。
In addition to these local observable benefits, there can be more global benefits. For example, if address usage is tied to anchors, it may be possible to prevent or control the use of large numbers of anonymous IPv6 addresses for attacks, or at least to trace even those attacks back to their source.
これらのローカルで観察可能なメリットに加えて、よりグローバルなメリットがあります。たとえば、アドレスの使用がアンカーに関連付けられている場合、攻撃に対する大量の匿名IPv6アドレスの使用を防止または制御したり、少なくともそれらの攻撃をソースまで追跡することが可能になる場合があります。
As described below in the security considerations, these operational behaviors need to be evaluated in the context of the reduction in user privacy implied if one logs traffic bindings. In particular, in addition to the architectural trade-offs, the network administrator must plan for the proper handling of this relevant privacy information about his users.
下記のセキュリティの考慮事項で説明するように、これらの運用上の動作は、トラフィックバインディングをログに記録する場合に暗示されるユーザーのプライバシーの低下という状況で評価する必要があります。特に、ネットワークの管理者は、アーキテクチャ上のトレードオフに加えて、ユーザーに関するこの関連するプライバシー情報の適切な処理を計画する必要があります。
This document provides limited discussion of some security threats that source address validation improvements will help to mitigate. It is not meant to be all-inclusive, either from a threat analysis perspective or from the source address validation application side.
このドキュメントでは、送信元アドレスの検証の改善が軽減に役立ついくつかのセキュリティの脅威についての限定的な説明を提供します。脅威分析の観点からも、送信元アドレス検証アプリケーション側からも、すべてを網羅することを意図したものではありません。
It is seductive to think of SAVI solutions as providing the ability to use this technology to trace a datagram to the person, or at least end system, that originated it. For several reasons, the technology can be used to derive circumstantial evidence, but does not actually solve that problem.
SAVIソリューションは、このテクノロジーを使用して、データグラムを作成した人または少なくともエンドシステムまでデータグラムを追跡する機能を提供するものと考えるのは魅力的です。いくつかの理由から、この技術は状況証拠を引き出すために使用できますが、実際にはその問題を解決しません。
In the Internet layer, the source address of a datagram should be the address of the system that originated it and to which any reply is expected to come. But systems fall into several broad categories. Many are single-user systems, such as laptops and PDAs. Multi-user systems are commonly used in industry, and a wide variety of middleware systems and application servers have no users at all, but by design relay messages or perform services on behalf of users of other systems (e.g., SMTP and peer-to-peer file sharing).
インターネット層では、データグラムの送信元アドレスは、データグラムの発信元であり、応答が返されることが予想されるシステムのアドレスである必要があります。しかし、システムはいくつかの広いカテゴリーに分類されます。多くは、ラップトップやPDAなどのシングルユーザーシステムです。マルチユーザーシステムは業界で一般的に使用されており、さまざまなミドルウェアシステムとアプリケーションサーバーにはユーザーがいませんが、リレーメッセージを設計したり、他のシステムのユーザーに代わってサービスを実行したりします（SMTPやピアツーピアなど）。ピアファイル共有）。
Even if every Internet-connected network implements source address validation at the ultimate network ingress, and assurances exist that intermediate devices are to never modify datagram source addresses, source addresses cannot be used as an authentication mechanism. The only techniques for unquestionably validating source addresses of a received datagram are cryptographic authentication mechanisms such as IPsec.
すべてのインターネット接続ネットワークが最終的なネットワーク入力で送信元アドレス検証を実装し、中間デバイスがデータグラム送信元アドレスを変更しないことが保証されている場合でも、送信元アドレスは認証メカニズムとして使用できません。受信したデータグラムの送信元アドレスを確実に検証する唯一の手法は、IPsecなどの暗号化認証メカニズムです。
It must be presumed that there will be some failure modes in any SAVI deployment, given the history of technical security mechanisms. A possible attack to be considered by network administrators is an inside attack probing the network for modes of spoofing that can be accomplished. If the probes are conducted at a level below alarm thresholds, this might allow an internal attacker to safely determine what spoof modes he can use. Thus, the use of these techniques must be managed in such a way as to avoid giving a false sense of security to the network administrator.
技術的なセキュリティメカニズムの履歴を考えると、SAVIの展開にはいくつかの障害モードが存在すると想定する必要があります。ネットワーク管理者が考慮する可能性のある攻撃は、実行可能なスプーフィングのモードについてネットワークを調査する内部攻撃です。プローブがアラームしきい値を下回るレベルで実施されている場合、これにより、内部の攻撃者が自分が使用できるスプーフィングモードを安全に決定できる可能性があります。したがって、これらの技術の使用は、ネットワーク管理者に誤ったセキュリティ感覚を与えないように管理する必要があります。
It should be understood that enforcing and recording IP address bindings have privacy implications. In some circumstances, this binding data may be considered to be personally identifying information. In general, collecting private information about users brings ethical and legal responsibilities to the network administrator.
IPアドレスバインディングの適用と記録はプライバシーに影響することを理解しておく必要があります。状況によっては、この拘束力のあるデータは個人を特定する情報と見なされる場合があります。一般に、ユーザーに関する個人情報を収集すると、ネットワーク管理者に倫理的および法的責任が生じます。
For this reason, collection and retention of logged binding information need to be considered carefully. Prevention of spoofing does not in itself require such retention. Analysis of immediate events may rely on having logs of current bindings. Thus, privacy issues can be ameliorated by removing binding logs after the binding lifetimes expire. Logs of apparent spoof attempts are a separate matter and may require longer retention to detect patterns of deliberate or accidental abuse.
このため、ログに記録されたバインディング情報の収集と保持は慎重に検討する必要があります。なりすましの防止自体は、そのような保持を必要としません。即時イベントの分析は、現在のバインディングのログがあることに依存している場合があります。したがって、バインディングの有効期限が切れた後にバインディングログを削除することにより、プライバシーの問題を改善できます。明らかななりすましの試みのログは別の問題であり、故意または偶発的な乱用のパターンを検出するには、より長い保持が必要になる場合があります。
With operations of the type described here, the network administrator is collecting information about where on his network the user is active. In addition, the recorded bindings supplement address usage information about users that is available from DHCP logs. For example, if IPv6 SLAAC is being used, and IP to Layer 2 address bindings are being logged, the administrator will have access to information associating users with their IP addresses even if IPv6 privacy addresses are used.
ここで説明するタイプの操作により、ネットワーク管理者は、ユーザーがネットワーク上のどこでアクティブであるかに関する情報を収集しています。さらに、記録されたバインディングは、DHCPログから入手できるユーザーに関するアドレス使用情報を補足します。たとえば、IPv6 SLAACが使用されていて、IPからレイヤー2へのアドレスバインディングがログに記録されている場合、IPv6プライバシーアドレスが使用されていても、管理者はユーザーをIPアドレスに関連付ける情報にアクセスできます。
In addition to this, care must be taken in attributing actions to users on the basis of this sort of information. Whatever the theoretical strength of the tools, administrators should always allow for such information being wrong and should be careful about any actions taken on the basis of apparent attribution. These techniques do nothing about address spoofing from other sites, so any evaluation of attribution also needs to allow for such cases.
これに加えて、この種の情報に基づいてアクションをユーザーに帰することに注意が必要です。ツールの理論的な強みが何であれ、管理者は常にそのような情報が間違っていることを許可し、明らかな帰属に基づいて実行されるアクションに注意する必要があります。これらの手法は、他のサイトからのアドレスのなりすましについては何もしないので、帰属の評価もそのような場合を考慮に入れる必要があります。
A portion of the primer text in this document came directly from [SAVA], authored by Fred Baker and Ralph Droms. Many thanks to Christian Vogt, Suresh Bhogavilli, and Pekka Savola for contributing text and a careful review of this document.
このドキュメントの入門テキストの一部は、Fred BakerとRalph Dromsによって作成された[SAVA]から直接引用されました。テキストを提供し、このドキュメントを注意深くレビューしてくれたChristian Vogt、Suresh Bhogavilli、Pekka Savolaに感謝します。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[IEEE802.1AX] IEEE, "IEEE Standard for Local and metropolitan area networks - Link Aggregation", IEEE 802.1AX, 2008.
[IEEE802.1AX] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Link Aggregation」、IEEE 802.1AX、2008。
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[RFC0826] Plummer、D。、「イーサネットアドレス解決プロトコル：またはネットワークプロトコルアドレスを48ビットのイーサネットアドレスに変換してイーサネットハードウェアで送信する」、STD 37、RFC 826、1982年11月。
[RFC2827] 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.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IP送信元アドレスのスプーフィングを採用するサービス拒否攻撃の打破」、BCP 38、RFC 2827、2000年5月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F。、およびP.サボラ、「マルチホームネットワークの入力フィルタリング」、BCP 84、RFC 3704、2004年3月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、Li、T。、およびS. Hares、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007.
[RFC4953] Touch、J。、「なりすまし攻撃に対するTCPの防御」、RFC 4953、2007年7月。
[SAVA] Baker, F. and R. Droms, "IPv4/IPv6 Source Address Verification", Work in Progress, June 2007.
[SAVA]ベイカー、F。およびR.ドロムス、「IPv4 / IPv6送信元アドレスの検証」、2007年6月、作業中。
[VRSN-REPORT] Silva, K., Scalzo, F., and P. Barber, "Anatomy of Recent DNS Reflector Attacks from the Victim and Reflector Point of View", VeriSign White Paper, April 2006.
[VRSN-REPORT] Silva、K.、Scalzo、F。、およびP. Barber、「被害者およびリフレクターの観点からの最近のDNSリフレクター攻撃の分析」、VeriSignホワイトペーパー、2006年4月。
Authors' Addresses
著者のアドレス
Danny McPherson VeriSign, Inc.
Danny McPherson VeriSign、Inc.
EMail: dmcpherson@verisign.com
Fred Baker Cisco Systems
フレッドベイカーシスコシステムズ
EMail: fred@cisco.com
Joel M. Halpern Ericsson
ジョエル・M・ハルパーン・エリクソン
EMail: joel.halpern@ericsson.com