[要約] RFC 7039は、Source Address Validation Improvement（SAVI）フレームワークに関するものであり、送信元アドレスの検証を改善することを目的としています。
Internet Engineering Task Force (IETF) J. Wu
Request for Comments: 7039 J. Bi
Category: Informational Tsinghua Univ.
ISSN: 2070-1721 M. Bagnulo
UC3M
F. Baker
Cisco
C. Vogt, Ed.
October 2013
Source Address Validation Improvement (SAVI) Framework
Source Address Validation Improvement（SAVI）Framework
Abstract
概要
Source Address Validation Improvement (SAVI) methods were developed to prevent nodes attached to the same IP link from spoofing each other's IP addresses, so as to complement ingress filtering with finer-grained, standardized IP source address validation. This document is a framework document that describes and motivates the design of the SAVI methods. Particular SAVI methods are described in other documents.
送信元アドレス検証改善（SAVI）メソッドは、同じIPリンクに接続されたノードが互いのIPアドレスをスプーフィングしないように開発され、入力フィルタリングをよりきめ細かく標準化されたIP送信元アドレス検証で補完します。このドキュメントは、SAVIメソッドの設計を説明し、動機付けるフレームワークドキュメントです。特定のSAVIメソッドは他のドキュメントで説明されています。
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/rfc7039.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7039で入手できます。
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に記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。 IETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Deployment Options . . . . . . . . . . . . . . . . . . . . . 5
3.1. IP Address Assignment Methods . . . . . . . . . . . . . . 6
3.2. Binding Anchors . . . . . . . . . . . . . . . . . . . . . 6
4. Scalability Optimizations . . . . . . . . . . . . . . . . . . 7
5. Reliability Optimizations . . . . . . . . . . . . . . . . . . 9
6. Scenario with Multiple Assignment Methods . . . . . . . . . . 10
7. Prefix Configuration . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Since IP source addresses are used by hosts and network entities to determine the origin of a packet and as a destination for return data, spoofing of IP source addresses can enable impersonation, concealment, and malicious traffic redirection. Unfortunately, the Internet architecture does not prevent IP source address spoofing [RFC6959]. Since the IP source address of a packet generally takes no role in forwarding the packet, it can be selected arbitrarily by the sending host without jeopardizing packet delivery. Extra methods are necessary for IP source address validation to augment packet forwarding with an explicit check of whether a given packet's IP source address is legitimate.
ホストとネットワークエンティティはIP送信元アドレスを使用して、パケットの発信元を判別し、戻りデータの宛先として使用するため、IP送信元アドレスのスプーフィングにより、なりすまし、隠蔽、および悪意のあるトラフィックのリダイレクトが可能になります。残念ながら、インターネットアーキテクチャはIP送信元アドレスのスプーフィングを防止しません[RFC6959]。パケットのIP送信元アドレスは通常、パケットの転送に関与しないため、パケットの配信を危険にさらすことなく、送信元ホストが任意に選択できます。特定のパケットのIP送信元アドレスが正当であるかどうかを明示的にチェックしてパケット転送を強化するには、IP送信元アドレスの検証に追加のメソッドが必要です。
IP source address validation can happen at different granularity. Ingress filtering [BCP38] [BCP84], a widely deployed standard for IP source address validation, functions at the coarse granularity of networks. It verifies that the prefix of an IP source address routes to the network from which the packet was received. An advantage of ingress filtering is simplicity: the decision of whether to accept or to reject an IP source address can be made solely based on the information available from routing protocols. However, the simplicity comes at the cost of not being able to validate IP source addresses at a finer granularity, due to the aggregated nature of the information available from routing protocols. Finer-grained IP source address validation would ensure that source address information is accurate, reduce the ability to launch denial-of-service attacks, and help with localizing hosts and identifying misbehaving hosts. Partial solutions [BA2007] exist for finer-grained IP source address validation but are proprietary and hence often unsuitable for corporate procurement.
IP送信元アドレスの検証は、さまざまな粒度で行われる可能性があります。イングレスフィルタリング[BCP38] [BCP84]は、IPソースアドレス検証のために広く展開されている標準であり、ネットワークの粗い粒度で機能します。 IP送信元アドレスのプレフィックスが、パケットの受信元のネットワークにルーティングされることを確認します。入力フィルタリングの利点は単純さです。IP送信元アドレスを受け入れるか拒否するかの決定は、ルーティングプロトコルから入手できる情報にのみ基づいて行うことができます。ただし、ルーティングプロトコルから得られる情報の集約された性質により、IP送信元アドレスをより細かい精度で検証できないという犠牲を伴いますが、単純さは犠牲になります。より詳細なIP送信元アドレスの検証により、送信元アドレス情報が正確であり、サービス拒否攻撃を開始する能力が低下し、ホストのローカライズと誤動作しているホストの特定に役立ちます。部分的なソリューション[BA2007]は、より詳細なIP送信元アドレス検証のために存在しますが、独自仕様であるため、企業の調達には不適切です。
The Source Address Validation Improvement (SAVI) method was developed to complement ingress filtering with standardized IP source address validation at the maximally fine granularity of individual IP addresses. It prevents hosts attached to the same link from spoofing each other's IP addresses. To facilitate deployment in networks of various kinds, the SAVI method was designed to be modular and extensible. This document describes and motivates the design of the SAVI method.
送信元アドレス検証改善（SAVI）方式は、個々のIPアドレスの細かい粒度で、標準化されたIP送信元アドレス検証でイングレスフィルタリングを補完するために開発されました。同じリンクに接続されたホストが互いのIPアドレスを偽装するのを防ぎます。さまざまな種類のネットワークへの導入を容易にするために、SAVIメソッドはモジュール式で拡張可能になるように設計されています。このドキュメントでは、SAVIメソッドの設計について説明し、その動機を説明します。
Note that SAVI raises a number of important privacy considerations that are discussed more fully in [RFC6959]. SAVI implementers must take those privacy considerations into account when designing solutions that match this framework and follow the recommendations given in [RFC6959].
SAVIは、[RFC6959]でより完全に説明されている多くの重要なプライバシーの考慮事項を提起していることに注意してください。 SAVIの実装者は、このフレームワークに一致するソリューションを設計するときにこれらのプライバシーの考慮事項を考慮に入れ、[RFC6959]で提供されている推奨事項に従う必要があります。
To enable network operators to deploy fine-grained IP source address validation without a dependency on supportive functionality on hosts, the SAVI method was designed to be purely network based. A SAVI instance enforces the hosts' use of legitimate IP source addresses according to the following three-step model:
ネットワークオペレーターがホストのサポート機能に依存することなく、きめの細かいIPソースアドレス検証を展開できるように、SAVIメソッドは純粋にネットワークベースになるように設計されました。 SAVIインスタンスは、次の3ステップモデルに従って、ホストによる正当なIP送信元アドレスの使用を強制します。
1. Identify which IP source addresses are legitimate for a host, based on monitoring packets exchanged by the host.
1. ホストによって交換されるパケットの監視に基づいて、ホストにとって正当なIP送信元アドレスを特定します。
2. Bind a legitimate IP address to a link-layer property of the host's network attachment. This property, called a "binding anchor", must be verifiable in every packet that the host sends and harder to spoof than the host's IP source address itself.
2. 正当なIPアドレスをホストのネットワークアタッチメントのリンク層プロパティにバインドします。 「バインディングアンカー」と呼ばれるこのプロパティは、ホストが送信するすべてのパケットで検証可能であり、ホストのIP送信元アドレス自体よりもスプーフィングが困難である必要があります。
3. Enforce that the IP source addresses in packets match the binding anchors to which they were bound.
3. パケットのIP送信元アドレスが、それらがバインドされているバインディングアンカーと一致するように強制します。
This model allows SAVI functionality (a SAVI instance) to be located anywhere on the link to which the hosts attach, hence enabling different locations for a SAVI instance. One way to locate a SAVI instance is in the hosts' default router. IP source addresses are then validated in packets traversing the default router, yet the IP source addresses in packets exchanged locally on the link may bypass validation. Another way to locate a SAVI instance is in a switch between the hosts and their default router. Thus, packets may undergo IP source address validation even if exchanged locally on the link.
このモデルでは、SAVI機能（SAVIインスタンス）を、ホストが接続するリンク上の任意の場所に配置できるため、SAVIインスタンスのさまざまな場所を使用できます。 SAVIインスタンスを見つける1つの方法は、ホストのデフォルトルーターにあります。次に、デフォルトのルーターを通過するパケットのIP送信元アドレスが検証されますが、リンク上でローカルに交換されたパケットのIP送信元アドレスは検証をバイパスする場合があります。 SAVIインスタンスを見つけるもう1つの方法は、ホストとそのデフォルトルーター間のスイッチです。したがって、リンク上でローカルに交換された場合でも、パケットはIP送信元アドレス検証を受ける可能性があります。
The closer a SAVI instance is located to the host, the more effective the SAVI method is. This is because each of the three steps of the SAVI model can best be accomplished in a position close to the host:
SAVIインスタンスがホストに近いほど、SAVIメソッドの効果は高くなります。これは、SAVIモデルの3つのステップのそれぞれが、ホストに近い位置で実行できるためです。
o Identifying a host's legitimate IP source addresses is most efficient close to the host because the likelihood that the host's packets bypass a SAVI instance, and hence cannot be monitored, increases with the topological distance between the SAVI instance and the host.
o ホストのパケットがSAVIインスタンスをバイパスし、したがって監視できない可能性がSAVIインスタンスとホストの間のトポロジー距離とともに増加するため、ホストの正当なIP送信元アドレスを特定することは、ホストの近くで最も効率的です。
o Selecting a binding anchor for a host's IP source address is easiest close to the host because many link-layer properties are unique for a given host only on a link segment directly attached to the host.
o ホストに直接接続されているリンクセグメント上でのみ多くのリンクレイヤープロパティが特定のホストに対して一意であるため、ホストのIP送信元アドレスのバインディングアンカーを選択することは、ホストに最も簡単です。
o Enforcing a host's use of a legitimate IP source address is most reliable when pursued close to the host because the likelihood that the host's packets bypass a SAVI instance, and hence do not undergo IP source address validation, increases with the topological distance between the SAVI instance and the host.
o ホストのパケットがSAVIインスタンスをバイパスするため、IPソースアドレス検証を受けない可能性がSAVIインスタンス間のトポロジー距離とともに増加するため、ホストの正当なIPソースアドレスの使用を強制することは、ホストの近くで追跡される場合に最も信頼できます。とホスト。
The preferred location of SAVI instances is therefore close to hosts, such as in switches that directly attach to the hosts whose IP source addresses are being validated.
したがって、SAVIインスタンスの推奨される場所は、IPソースアドレスが検証されているホストに直接接続されているスイッチなどのホストに近い場所です。
Nevertheless, it is useful for SAVI mechanisms to be able to handle situations where hosts are not directly attached to the SAVI-capable device. For instance, deployments with both SAVI-capable and legacy switches could be supported. In general, a SAVI solution needs to specify how it deals with a number of deployment scenarios and exceptional situations, including interaction with legacy devices, hosts moving between wireless attachment points, network partitions, and so on.
それでも、ホストがSAVI対応デバイスに直接接続されていない状況をSAVIメカニズムが処理できると便利です。たとえば、SAVI対応スイッチとレガシースイッチの両方を使用した展開がサポートされます。一般に、SAVIソリューションは、レガシーデバイスとのやり取り、ワイヤレス接続ポイント間を移動するホスト、ネットワークパーティションなど、多くの展開シナリオと例外的な状況に対処する方法を指定する必要があります。
Besides, in the case of legacy switches, the security level is lower, as there is no full protection for the hosts connected to the legacy server.
また、レガシースイッチの場合、レガシーサーバーに接続されているホストを完全に保護することはできないため、セキュリティレベルは低くなります。
The model of the SAVI method, as explained in Section 2, is deployment specific in two ways:
セクション2で説明したSAVIメソッドのモデルは、次の2つの点で展開固有です。
o The identification of legitimate IP source addresses is dependent on the IP address assignment method in use on a link, since it is through assignment that a host becomes the legitimate user of an IP source address.
o 正当なIP送信元アドレスの識別は、ホストがIP送信元アドレスの正当なユーザーになるのは割り当てによるため、リンクで使用されているIPアドレスの割り当て方法に依存します。
o Binding anchors are dependent on the technology used to build the link on which they are used, as binding anchors are link-layer properties of a host's network attachment.
o バインディングアンカーはホストのネットワークアタッチメントのリンク層プロパティであるため、バインディングアンカーは、それらが使用されるリンクを構築するために使用されるテクノロジーに依存しています。
To facilitate the deployment of the SAVI method in networks of various kinds, the SAVI method is designed to support different IP address assignment methods and to function with different binding anchors. Naturally, both the IP address assignment methods in use on a link and the available binding anchors have an impact on the functioning and the strength of IP source address validation. The following two subsections explain this impact and describe how the SAVI method accommodates this.
さまざまな種類のネットワークでのSAVIメソッドの導入を容易にするために、SAVIメソッドは、さまざまなIPアドレス割り当てメソッドをサポートし、さまざまなバインディングアンカーで機能するように設計されています。当然、リンクで使用されているIPアドレス割り当て方法と使用可能なバインディングアンカーの両方が、IPソースアドレス検証の機能と強度に影響を与えます。次の2つのサブセクションでは、この影響について説明し、SAVIメソッドがこれにどのように対応するかについて説明します。
Since the SAVI method traces IP address assignment packets, it necessarily needs to incorporate logic that is specific to particular IP address assignment methods. However, developing SAVI method variants for each IP address assignment method is alone not sufficient since multiple IP address assignment methods may coexist on a given link. The SAVI method hence comes in multiple variants, e.g., for links with DHCP [RFC2131] [RFC3315], Stateless Address Autoconfiguration (SLAAC) [RFC4862] with or without Secure Neighbor Discovery (SEND) [RFC3971], Internet Key Exchange Protocol Version 2 (IKEv2) [RFC5996] [RFC5739] [RFC5026], and combinations thereof.
SAVIメソッドはIPアドレス割り当てパケットをトレースするため、特定のIPアドレス割り当てメソッドに固有のロジックを組み込む必要があります。ただし、特定のリンク上で複数のIPアドレス割り当てメソッドが共存する可能性があるため、IPアドレス割り当てメソッドごとにSAVIメソッドバリアントを開発するだけでは不十分です。したがって、SAVIメソッドには複数のバリエーションがあります。たとえば、DHCP [RFC2131] [RFC3315]、ステートレスアドレス自動構成（SLAAC）[RFC4862]、セキュアネイバーディスカバリ（SEND）[RFC3971]、インターネットキーエクスチェンジプロトコルバージョン2 （IKEv2）[RFC5996] [RFC5739] [RFC5026]、およびそれらの組み合わせ。
The reason to develop SAVI method variants for each single IP address configuration method, in addition to the variant that handles all IP address assignment methods, is to minimize the complexity of the common case. Many link deployments today either are constrained to a single IP address assignment method or, equivalently from the perspective of the SAVI method, use different IP address assignment methods within different IP address prefixes. The SAVI method for such links can be simpler than the SAVI method for links with multiple IP address assignment methods per IP address prefix.
すべてのIPアドレス割り当てメソッドを処理するバリアントに加えて、単一のIPアドレス構成メソッドごとにSAVIメソッドバリアントを開発する理由は、一般的なケースの複雑さを最小限に抑えるためです。今日の多くのリンク配置は、単一のIPアドレス割り当て方式に制限されているか、同等にSAVI方式の観点から、異なるIPアドレスプレフィックス内で異なるIPアドレス割り当て方式を使用しています。このようなリンクのSAVIメソッドは、IPアドレスプレフィックスごとに複数のIPアドレス割り当てメソッドを持つリンクのSAVIメソッドよりも簡単です。
The SAVI method supports a range of binding anchors:
SAVIメソッドは、さまざまなバインディングアンカーをサポートしています。
o The IEEE extended unique identifier, EUI-48 or EUI-64, of a host's interface.
o ホストのインターフェイスのIEEE拡張一意識別子、EUI-48またはEUI-64。
o The port on an Ethernet switch to which a host attaches.
o ホストが接続するイーサネットスイッチのポート。
o The security association between a host and the base station on wireless links.
o ワイヤレスリンク上のホストとベースステーション間のセキュリティアソシエーション。
o The combination of a host interface's link-layer address and a customer relationship in cable modem networks.
o ホストインターフェースのリンク層アドレスとケーブルモデムネットワークにおける顧客関係の組み合わせ。
o An ATM virtual channel, a PPP session identifier, or a Layer 2 Tunneling Protocol (L2TP) session identifier in a DSL network.
o DSLネットワークのATM仮想チャネル、PPPセッション識別子、またはレイヤ2トンネリングプロトコル（L2TP）セッション識別子。
o A tunnel that connects to a single host, such as an IP-in-IP tunnel, a Generic Routing Encapsulation (GRE) tunnel, or an MPLS label-switched path.
o IP-in-IPトンネル、Generic Routing Encapsulation（GRE）トンネル、MPLSラベルスイッチドパスなど、単一のホストに接続するトンネル。
The various binding anchors differ significantly in the security they provide. IEEE extended unique identifiers, for example, fail to render a secure binding anchor because they can be spoofed with little effort. Switch ports alone may be insufficient because they may connect to more than a single host, such as in the case of concatenated switches.
さまざまなバインディングアンカーは、提供するセキュリティが大幅に異なります。たとえば、IEEE拡張一意識別子は、ほとんど手間をかけずにスプーフィングできるため、安全なバインディングアンカーをレンダリングできません。連結スイッチの場合など、複数のホストに接続する可能性があるため、スイッチポートだけでは不十分な場合があります。
Given this diversity in the security provided, one could define a set of possible binding anchors and leave it up to the administrator to choose one or more of them. Such a selection of binding anchors would, of course, have to be accompanied by an explanation of the pros and cons of the different binding anchors. In addition, SAVI devices may have a default binding anchor depending on the lower layers. Such a default could be to use switch ports when available and MAC addresses otherwise or to use MAC addresses and switch ports in addition if available.
提供されるセキュリティのこの多様性を考慮して、可能なバインディングアンカーのセットを定義し、それらの1つ以上を選択するのは管理者に任せることができます。もちろん、このようなバインディングアンカーの選択には、さまざまなバインディングアンカーの長所と短所の説明が必要です。さらに、SAVIデバイスは、下位層に応じてデフォルトのバインディングアンカーを持つ場合があります。このようなデフォルトでは、使用可能な場合はスイッチポートとMACアドレスを使用し、そうでない場合はMACアドレスとスイッチポートを使用します。
The preference to locate a SAVI instance close to hosts implies that multiple SAVI instances must be able to coexist in order to support large links. Although the model of the SAVI method is independent of the number of SAVI instances per link, coexistence of multiple SAVI instances without further measures can lead to higher-than-necessary memory requirements. Since a SAVI instance creates bindings for the IP source addresses of all hosts on a link, bindings are replicated if multiple SAVI instances coexist on the link. High memory requirements, in turn, increase the cost of a SAVI instance. This is problematic in particular for SAVI instances that are located on a switch since it may significantly increase the cost of such a switch.
ホストの近くにSAVIインスタンスを配置する設定は、大きなリンクをサポートするために複数のSAVIインスタンスが共存できなければならないことを意味します。 SAVIメソッドのモデルは、リンクごとのSAVIインスタンスの数とは無関係ですが、追加の対策なしに複数のSAVIインスタンスを共存させると、必要以上のメモリ要件が発生する可能性があります。 SAVIインスタンスはリンク上のすべてのホストのIP送信元アドレスのバインディングを作成するため、リンク上に複数のSAVIインスタンスが共存している場合、バインディングが複製されます。高いメモリ要件は、SAVIインスタンスのコストを増加させます。このようなスイッチのコストが大幅に増加する可能性があるため、スイッチに配置されているSAVIインスタンスの場合は特に問題があります。
To reduce memory requirements for SAVI instances that are located on a switch, the SAVI method enables the suppression of binding replication on links with multiple SAVI instances. This requires manual disabling of IP source address validation on switch ports that connect to other switches running a SAVI instance. Each SAVI instance is then responsible for validating IP source addresses only on those ports to which hosts attach either directly or via switches without a SAVI instance. On ports towards other switches running a SAVI instance, IP source addresses are not validated. The switches running SAVI instances thus form a "protection perimeter". The IP source addresses in packets passing the protection perimeter are validated by the ingress SAVI instance, but no further validation takes place as long as the packets remain within or leave the protection perimeter.
スイッチにあるSAVIインスタンスのメモリ要件を減らすために、SAVIメソッドは、複数のSAVIインスタンスとのリンクでのバインディングレプリケーションの抑制を有効にします。これには、SAVIインスタンスを実行している他のスイッチに接続するスイッチポートのIPソースアドレス検証を手動で無効にする必要があります。各SAVIインスタンスは、ホストが直接またはSAVIインスタンスなしのスイッチを介して接続するポートでのみIP送信元アドレスを検証します。 SAVIインスタンスを実行している他のスイッチへのポートでは、IP送信元アドレスは検証されません。したがって、SAVIインスタンスを実行するスイッチは、「保護境界」を形成します。保護境界を通過するパケットのIP送信元アドレスは、入力SAVIインスタンスによって検証されますが、パケットが保護境界内にとどまるか、保護境界を離れている限り、それ以上の検証は行われません。
..............
protection perimeter --> : +--------+ :
+---+ +---+ : | SAVI | :
| A | | B | <-- hosts : | switch | :
+---+ +---+ : +--------+ :
...|......|.............................: | :
: +--------+ +--------+ +--------+ :
: | SAVI |----------| legacy | | SAVI | :
: | switch | | switch |----------| switch | :
: +--------+ +--------+ +--------+ :
: | ...............................|........:
: +--------+ : +--------+
: | SAVI | : | legacy |
: | switch | : | switch |
: +--------+ : +--------+
:............: | |
+---+ +---+
hosts --> | C | | D |
+---+ +---+
Figure 1: Protection Perimeter Concept
図1：保護境界の概念
Figure 1 illustrates the concept of the protection perimeter. The figure shows a link with six switches, of which four, denoted "SAVI switch", run a SAVI instance. The protection perimeter created by the four SAVI instances is shown as a dotted line in the figure. IP source address validation is enabled on all switch ports on the protection perimeter, and it is disabled on all other switch ports. Four hosts, denoted A through D in the figure, attach to the protection perimeter.
図1は、保護境界の概念を示しています。この図は、6つのスイッチを持つリンクを示しています。そのうちの4つは「SAVIスイッチ」と呼ばれ、SAVIインスタンスを実行します。図では、4つのSAVIインスタンスによって作成された保護境界が点線で示されています。 IPソースアドレスの検証は、保護境界のすべてのスイッチポートで有効になり、他のすべてのスイッチポートでは無効になります。図ではA〜Dで示されている4つのホストが保護境界に接続されています。
In the example in Figure 1, the protection perimeter encompasses one of the legacy switches, located in the middle of the depicted link topology. This enables a single, unpartitioned protection perimeter. A single protection perimeter minimizes memory requirements for the SAVI instances because every binding is kept only once, namely, by the SAVI instance that attaches to the host being validated. Excluding the legacy switch from the protection perimeter would result in two smaller protection perimeters to the left and to the right of the depicted link topology. The memory requirements for the SAVI instances would then be higher: since IP source address validation would be activated on the two ports connecting to the legacy switch, the SAVI instances adjacent to the legacy switch would replicate all bindings from the other protection perimeter, respectively. The reason why it is possible to include the legacy switch in the protection perimeter is because the depicted link topology guarantees that packets cannot enter the protection perimeter via this legacy switch. Without this guarantee, the legacy switch would have to be excluded from the protection perimeter in order to ensure that packets entering the protection perimeter undergo IP source address validation.
図1の例では、保護境界は、描かれたリンクトポロジの中央にあるレガシースイッチの1つを囲んでいます。これにより、パーティション化されていない単一の保護境界が可能になります。単一の保護境界は、検証されるホストに接続するSAVIインスタンスによってすべてのバインディングが1回だけ保持されるため、SAVIインスタンスのメモリ要件を最小限に抑えます。レガシースイッチを保護境界から除外すると、図のリンクトポロジの左側と右側に2つの小さな保護境界ができます。その場合、SAVIインスタンスのメモリ要件は高くなります。レガシースイッチに接続する2つのポートでIPソースアドレス検証がアクティブになるため、レガシースイッチに隣接するSAVIインスタンスは、他の保護境界からのすべてのバインディングをそれぞれ複製します。レガシースイッチを保護境界に含めることができる理由は、図のリンクトポロジが、パケットがこのレガシースイッチを介して保護境界に入ることができないことを保証するためです。この保証がない場合、保護境界に入るパケットが確実にIP送信元アドレス検証を受けるようにするために、レガシースイッチを保護境界から除外する必要があります。
Note that if such configuration is used, care must be taken as any hosts on subnets attached to non-enforcing ports will be able to use spoofed source addresses.
このような構成を使用する場合、非強制ポートに接続されたサブネット上のすべてのホストがスプーフィングされた送信元アドレスを使用できるようになるので注意が必要です。
The explicit storage of legitimate IP addresses in the form of bindings implies that failure to create a binding, or the premature removal of bindings, can lead to loss of legitimate packets. There are three situations in which this can happen:
バインディングの形式での正当なIPアドレスの明示的な格納は、バインディングの作成の失敗、またはバインディングの早期の削除により、正当なパケットが失われる可能性があることを意味します。これが発生する可能性のある状況は3つあります。
o Legitimate IP address configuration packets, which should trigger the creation of a binding in a SAVI instance, are lost before reaching the SAVI instance.
o SAVIインスタンスでのバインディングの作成をトリガーする正当なIPアドレス構成パケットは、SAVIインスタンスに到達する前に失われます。
o A SAVI instance loses a binding, for example, due to a restart.
o たとえば、再起動により、SAVIインスタンスはバインディングを失います。
o The link topology changes, resulting in hosts to communicate through SAVI instances that do not have a binding for those hosts' IP addresses.
o リンクトポロジが変更されると、ホストは、それらのホストのIPアドレスにバインドされていないSAVIインスタンスを介して通信します。
To limit the disruption that missing bindings for legitimate IP addresses can have, the SAVI method includes a mechanism for reactive binding creation based on regular packets. This mechanism supplements the proactive binding creation based on IP address configuration packets. Reactive binding creation occurs when a SAVI instance recognizes excessive drops of regular packets originating from the same IP address. The SAVI instance then verifies whether said IP address is unique on the link. How the verification is carried out depends on the IP address configuration method that the SAVI instance supports. The SAVI method variant for Stateless Address Autoconfiguration and for Secure Neighbor Discovery verifies an IP address through the Duplicate Address Detection procedure. The SAVI method variant for DHCP verifies an IP address through a DHCP Lease Query message exchange with the DHCP server. If verification indicates that the IP address is unique on the link, the SAVI instance creates a binding for the IP address. Otherwise, no binding is created, and packets sent from the IP address continue to be dropped. These reliability issues should be addressed in all the SAVI protocols describing particular SAVI methods.
正当なIPアドレスの欠落しているバインディングによる混乱を制限するために、SAVIメソッドには、通常のパケットに基づいてリアクティブバインディングを作成するためのメカニズムが含まれています。このメカニズムは、IPアドレス構成パケットに基づく事前バインディングの作成を補足します。リアクティブバインディングの作成は、SAVIインスタンスが同じIPアドレスから発信された通常のパケットの過度のドロップを認識すると発生します。次に、SAVIインスタンスは、そのIPアドレスがリンク上で一意であるかどうかを確認します。検証の実行方法は、SAVIインスタンスがサポートするIPアドレス構成方法によって異なります。ステートレスアドレス自動設定およびセキュアネイバーディスカバリ用のSAVIメソッドバリアントは、重複アドレス検出手順を通じてIPアドレスを検証します。 DHCPのSAVIメソッドバリアントは、DHCPサーバーとのDHCP Lease Queryメッセージ交換を通じてIPアドレスを確認します。検証でIPアドレスがリンク上で一意であることが示された場合、SAVIインスタンスはIPアドレスのバインディングを作成します。それ以外の場合、バインディングは作成されず、IPアドレスから送信されたパケットは引き続きドロップされます。これらの信頼性の問題は、特定のSAVIメソッドを説明するすべてのSAVIプロトコルで対処する必要があります。
While multiple assignment methods can be used on the same link, the SAVI device may have to deal with a mix of binding discovery methods. If the address prefix used for each assignment method is different, the "mix scenario" behaves the same as with the scenario with only one assignment method. If different address assignment methods are used to assign addresses from the same prefix, additional considerations are needed because one binding mechanism may create a binding violating an existing binding from another binding mechanism, e.g., binding from First-Come, First-Served (FCFS) SAVI [RFC6620] may violate a binding from SAVI-DHCP [SAVI-DHCP]. Thus, the collision between different SAVI mechanisms in the mix scenario must be handled in case more than one address assignment method is used to assign addresses from the same prefix.
同じリンクで複数の割り当て方法を使用できますが、SAVIデバイスはバインディング検出方法の組み合わせを処理する必要がある場合があります。各割り当て方法に使用されるアドレスプレフィックスが異なる場合、「混合シナリオ」は、割り当て方法が1つだけのシナリオと同じように動作します。同じプレフィックスからアドレスを割り当てるために異なるアドレス割り当て方法が使用される場合、1つのバインディングメカニズムが別のバインディングメカニズムからの既存のバインディングに違反するバインディングを作成する可能性があるため、追加の考慮事項が必要です（たとえば、先着順（FCFS）からのバインディング）。 SAVI [RFC6620]は、SAVI-DHCP [SAVI-DHCP]からのバインディングに違反する可能性があります。したがって、複数のアドレス割り当て方法を使用して同じプレフィックスからアドレスを割り当てる場合、混合シナリオでの異なるSAVIメカニズム間の衝突を処理する必要があります。
The prioritization of relationships between different address assignment methods is used as the basis to solve possible collisions. Current standard documents of address assignment methods (DHCP [RFC2131], DHCPv6 [RFC3315], SLAAC [RFC4862], and SEND [RFC3971]) have implied the prioritization relationship in general cases. However, in some scenarios, the default prioritization level may not be quite suitable. A configurable prioritization level should be supported in the SAVI solution for the mix scenario [SAVI-MIX].
異なるアドレス割り当て方法間の関係の優先順位付けは、起こり得る衝突を解決するための基礎として使用されます。アドレス割り当て方法の現在の標準ドキュメント（DHCP [RFC2131]、DHCPv6 [RFC3315]、SLAAC [RFC4862]、およびSEND [RFC3971]）は、一般的な場合の優先順位関係を示唆しています。ただし、一部のシナリオでは、デフォルトの優先度レベルがあまり適切でない場合があります。構成シナリオの優先順位付けレベルは、混合シナリオ[SAVI-MIX]のSAVIソリューションでサポートされている必要があります。
Before setting up a host-level granularity binding, it is important to configure correct prefixes on the SAVI device. This document suggests a set of 3 prefix configuration mechanisms at a SAVI device:
ホストレベルの粒度のバインディングを設定する前に、SAVIデバイスに正しいプレフィックスを構成することが重要です。このドキュメントでは、SAVIデバイスでの3つのプレフィックス構成メカニズムのセットを提案しています。
o Manual Prefix Configuration: The allowed prefix scope of IPv4 addresses, IPv6 static addresses, IPv6 addresses assigned by Stateless Address Autoconfiguration (SLAAC), and IPv6 addresses assigned by DHCPv6 can be set manually at the SAVI device. FE80::/64 is always a feasible prefix in IPv6.
o 手動プレフィックス構成：IPv4アドレス、IPv6静的アドレス、ステートレスアドレス自動構成（SLAAC）によって割り当てられたIPv6アドレス、およびDHCPv6によって割り当てられたIPv6アドレスの許可されたプレフィックススコープは、SAVIデバイスで手動で設定できます。 FE80 :: / 64は、IPv6では常に実行可能なプレフィックスです。
o Prefix Configuration by Router Advertisement (RA) Snooping: The allowed prefix scope of IPv6 static addresses and IPv6 addresses assigned by SLAAC can be set at the SAVI device through snooping an RA message at the SAVI device.
o ルーターアドバタイズ（RA）スヌーピングによるプレフィックス構成：SLAACによって割り当てられたIPv6静的アドレスおよびIPv6アドレスの許可されたプレフィックススコープは、SAVIデバイスでRAメッセージをスヌーピングすることにより、SAVIデバイスで設定できます。
o Prefix Configuration by DHCP Prefix Delegation (DHCP-PD) Snooping: The allowed prefix scope of IPv6 static addresses, IPv6 addresses assigned by SLAAC, and IPv6 addresses assigned by DHCPv6 can be set through snooping a DHCP-PD message at the SAVI device.
o DHCPプレフィックス委任（DHCP-PD）スヌーピングによるプレフィックス構成：IPv6静的アドレス、SLAACによって割り当てられたIPv6アドレス、およびDHCPv6によって割り当てられたIPv6アドレスの許可されたプレフィックススコープは、SAVIデバイスでDHCP-PDメッセージをスヌーピングすることによって設定できます。
If some of the prefix scopes are set to have no prefix, the implication is that the corresponding address assignment method is not allowed in the network.
一部のプレフィックススコープがプレフィックスを持たないように設定されている場合、対応するアドレス割り当て方法がネットワークで許可されないことを意味します。
There is no need to explicitly present these prefix scopes, but these restrictions should be used as the premier check in binding setup.
これらのプレフィックススコープを明示的に提示する必要はありませんが、これらの制限はバインディング設定のプレミアチェックとして使用する必要があります。
When SAVI is partially deployed, binding may fail as RA messages and DHCP-PD can be spoofed. So, it is recommended that Manual Prefix Configuration be used unless SAVI gets fully deployed.
SAVIが部分的に展開されている場合、RAメッセージとDHCP-PDが偽装される可能性があるため、バインドが失敗する可能性があります。したがって、SAVIが完全に展開されない限り、手動プレフィックス設定を使用することをお勧めします。
The authors would like to thank the SAVI working group for a thorough technical discussion on the design and the framework of the SAVI method as captured in this document, in particular Erik Nordmark, Guang Yao, Eric Levy-Abegnoli, and Alberto Garcia. Thanks also to Torben Melsen for reviewing this document.
このドキュメントで取り上げたSAVIメソッドの設計とフレームワークに関する徹底的な技術的な議論、特にErik Nordmark、Guang Yao、Eric Levy-Abegnoli、およびAlberto Garciaについて、SAVIワーキンググループに感謝します。このドキュメントをレビューしてくれたTorben Melsenにも感謝します。
This document only discusses the possible methods to mitigate the usage of forged IP addresses. Some such methods may rely on cryptographic methods, but not all do. As a result, it is generally not possible to prove address ownership in any strong sense. If a binding anchor is not exclusive for each IP address, or is without strong security, addresses can still be forged. Besides, the binding may not accord with the address management requirement, which can be more specified for each client. However, given no new protocol is introduced, the improvements are still acceptable. If strong security is required when using IP addresses, then cryptographic-based authentication must be used as it is the only way to provide strong security.
このドキュメントでは、偽造IPアドレスの使用を軽減するための可能な方法についてのみ説明します。このような方法の中には、暗号化方法に依存しているものもありますが、すべてに依存しているわけではありません。その結果、一般的に、強い意味でのアドレスの所有権を証明することはできません。バインディングアンカーがIPアドレスごとに排他的でない場合、または強力なセキュリティがない場合でも、アドレスが偽造される可能性があります。さらに、バインディングはアドレス管理要件と一致しない可能性があり、クライアントごとに詳細に指定できます。ただし、新しいプロトコルが導入されていないため、改善はまだ許容範囲です。 IPアドレスの使用時に強力なセキュリティが必要な場合は、強力なセキュリティを提供する唯一の方法であるため、暗号化ベースの認証を使用する必要があります。
Section 2 explains how the preferred location of SAVI instances is close to hosts. However, in some cases, this makes the SAVI instances themselves vulnerable and may defeat the purpose of deploying a SAVI solution. For instance, deployments should not place SAVI functionality in devices that are physically exposed. Even if the device correctly monitors the source address usage of hosts, an attacker could replace the device with one that does not check or hook up to a trusted interface from the device to the rest of the network. Similarly, deployments where SAVI instances are distributed across administrative boundaries are not recommended. For instance, in most cases, it would be undesirable to deploy a distributed SAVI solution on both sides of a customer-provider interface if the solution required trusting the correct operation of the SAVI devices on the other side of the interface.
セクション2では、SAVIインスタンスの望ましい場所がホストにどのように近いかを説明します。ただし、場合によっては、これによりSAVIインスタンス自体が脆弱になり、SAVIソリューションを展開する目的に反する可能性があります。たとえば、展開では、物理的に公開されているデバイスにSAVI機能を配置しないでください。デバイスがホストのソースアドレスの使用状況を正しく監視している場合でも、攻撃者はデバイスを、デバイスからネットワークの残りの部分への信頼できるインターフェイスをチェックまたはフックしないデバイスに置き換える可能性があります。同様に、SAVIインスタンスが管理の境界を越えて分散される配置は推奨されません。たとえば、ほとんどの場合、ソリューションがインターフェイスの反対側のSAVIデバイスの正しい動作を信頼する必要がある場合、カスタマープロバイダーインターフェイスの両側に分散SAVIソリューションを展開することは望ましくありません。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、1997年3月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315、July 2003 。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、Kempf、J.、Zill、B。、およびP. Nikander、「SEcure Neighbor Discovery（SEND）」、RFC 3971、2005年3月。
[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月。
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5026]ジャレッタ、G。、ケンプ、J。、およびV.デバラパリ、「スプリットシナリオでのモバイルIPv6ブートストラップ」、RFC 5026、2007年10月。
[RFC5739] Eronen, P., Laganier, J., and C. Madson, "IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5739, February 2010.
[RFC5739] Eronen、P.、Laganier、J。、およびC. Madson、「IPv6 Configuration in Internet Key Exchange Protocol Version 2（IKEv2）」、RFC 5739、2010年2月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）」、RFC 5996、2010年9月。
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses", RFC 6620, May 2012.
[RFC6620] Nordmark、E.、Bagnulo、M。、およびE. Levy-Abegnoli、「FCFS SAVI：First-Come、First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses」、RFC 6620、2012年5月。
[RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address Validation Improvement (SAVI) Threat Scope", RFC 6959, May 2013.
[RFC6959]マクファーソン、D。、ベイカー、F。、およびJ.ハルパーン、「Source Address Validation Improvement（SAVI）Threat Scope」、RFC 6959、2013年5月。
[BA2007] Baker, F., "Cisco IP Version 4 Source Guard", Work in Progress, November 2007.
[BA2007]ベイカー、F。、「Cisco IP Version 4 Source Guard」、Work in Progress、2007年11月。
[BCP38] 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.
[BCP38]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IP送信元アドレススプーフィングを採用するサービス拒否攻撃を阻止する」、BCP 38、RFC 2827、2000年5月。
[BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[BCP84]ベイカー、F。およびP.サボラ、「マルチホームネットワーク用のイングレスフィルタリング」、BCP 84、RFC 3704、2004年3月。
[SAVI-DHCP] Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for DHCP", Work in Progress, June 2013.
[SAVI-DHCP] Bi、J.、Wu、J.、Yao、G.、F。ベイカー、「SAVI Solution for DHCP」、Work in Progress、2013年6月。
[SAVI-MIX] Bi, J., Yao, G., Halpern, J., and E. Levy-Abegnoli, "SAVI for Mixed Address Assignment Methods Scenario", Work in Progress, May 2013.
[SAVI-MIX] Bi、J.、Yao、G.、Halpern、J。、およびE. Levy-Abegnoli、「SAVI for Mixed Address Assignment Methods Scenario」、Work in Progress、2013年5月。
Authors' Addresses
著者のアドレス
Jianping Wu Tsinghua University Computer Science, Tsinghua University Beijing 100084 China
J Ianping W UT sing Talks University Computer Science、TS inghua University Beijing 100084 China
EMail: jianping@cernet.edu.cn
Jun Bi Tsinghua University Network Research Center, Tsinghua University Beijing 100084 China
Jun Bi清華大学ネットワーク研究センター、清華大学北京100084中国
EMail: junbi@tsinghua.edu.cn
Marcelo Bagnulo Universidad Carlos III de Madrid Avenida de la Universidad 30 Leganes, Madrid 28911 Spain
Marcelo Bagnulo Carlos IIIマドリード大学アベニーダデラウニベルシダード30 Leganes、マドリード28911スペイン
EMail: marcelo@it.uc3m.es
Fred Baker Cisco Systems Santa Barbara, CA 93117 United States
Fred Baker Cisco Systems Santa Barbara、CA 93117アメリカ合衆国
EMail: fred@cisco.com
Christian Vogt (editor) 3507 Palmilla Drive San Jose, CA 95134 United States
Christian Vogt（編集者）3507 Palmilla Driveサンノゼ、CA 95134アメリカ合衆国
EMail: mail@christianvogt.net