[要約] このRFCは、Source Address Validation Architecture（SAVA）のテストベッドと展開の経験について報告しています。目的は、SAVAの実装と展開に関する情報を提供し、インターネットのセキュリティと信頼性を向上させることです。
Network Working Group J. Wu
Request for Comments: 5210 J. Bi
Category: Experimental X. Li
G. Ren
K. Xu
Tsinghua University
M. Williams
Juniper Networks
June 2008
A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience
ソースアドレス検証アーキテクチャ（SAVA）テストベッドおよび展開エクスペリエンス
Status of This Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Abstract
概要
Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. In an effort to enhance the Internet with IP source address validation, a prototype implementation of the IP Source Address Validation Architecture (SAVA) was created and an evaluation was conducted on an IPv6 network. This document reports on the prototype implementation and the test results, as well as the lessons and insights gained from experimentation.
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. A Prototype SAVA Implementation . . . . . . . . . . . . . . . 4
2.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 4
2.2. IP Source Address Validation in the Access Network . . . . 6
2.3. IP Source Address Validation at Intra-AS/Ingress Point . . 9
2.4. IP Source Address Validation in the Inter-AS Case
(Neighboring AS) . . . . . . . . . . . . . . . . . . . . . 9
2.5. IP Source Address Validation in the Inter-AS Case
(Non-Neighboring AS) . . . . . . . . . . . . . . . . . . . 12
3. SAVA Testbed . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1. CNGI-CERNET2 . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. SAVA Testbed on CNGI-CERNET2 Infrastructure . . . . . . . 16
4. Test Experience and Results . . . . . . . . . . . . . . . . . 17
4.1. Test Scenarios . . . . . . . . . . . . . . . . . . . . . . 17
4.2. Test Results . . . . . . . . . . . . . . . . . . . . . . . 18
5. Limitations and Issues . . . . . . . . . . . . . . . . . . . . 18
5.1. General Issues . . . . . . . . . . . . . . . . . . . . . . 18
5.2. Security Issues . . . . . . . . . . . . . . . . . . . . . 20
5.3. Protocol Details . . . . . . . . . . . . . . . . . . . . . 20
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 23
By design, the Internet forwards data packets solely based on the destination IP address. The source IP address is not checked during the forwarding process in most cases. This makes it easy for malicious hosts to spoof the source address of the IP packet. We believe that it would be useful to enforce the validity of the source IP address for all the packets being forwarded.
Enforcing the source IP address validity would help us achieve the following goals:
ソースIPアドレスの妥当性を実施することは、次の目標を達成するのに役立ちます。
o Since packets which carry spoofed source addresses would not be forwarded, it would be impossible to launch network attacks that are enabled by using spoofed source addresses and more difficult to successfully carry out attacks enhanced or strengthened by the use of spoofed source addresses.
o スプーフィングされたソースアドレスを運ぶパケットは転送されないため、スプーフィングされたソースアドレスを使用することで有効になっているネットワーク攻撃を起動することは不可能であり、スプーフィングされたソースアドレスの使用によって強化または強化された攻撃を正常に実行することがより困難です。
o Being able to assume that all packet source addresses are correct would allow traceback to be accomplished accurately and with confidence. This would benefit network diagnosis, management, accounting, and applications.
o すべてのパケットソースアドレスが正しいと仮定できると、Tracebackを正確かつ自信を持って達成することができます。これは、ネットワークの診断、管理、会計、およびアプリケーションに利益をもたらすでしょう。
As part of the effort in developing a Source Address Validation Architecture (SAVA), we implemented a SAVA prototype and deployed the prototype in 12 ASes in an operational network as part of China Next Generation Internet (CNGI) Project [Wu07]. We conducted evaluation experiments. In this document, we first describe the prototype solutions and then report experimental results. We hope that this document can provide useful insights to those interested in the subject, and can serve as an initial input to future IETF effort in this area.
ソースアドレス検証アーキテクチャ（SAVA）の開発の一環として、SAVAプロトタイプを実装し、中国の次世代インターネット（CNGI）プロジェクト[WU07]の一部として運用ネットワークで12 ASEでプロトタイプを展開しました。評価実験を実施しました。このドキュメントでは、最初にプロトタイプソリューションについて説明し、実験結果を報告します。このドキュメントが、このテーマに興味のある人に有用な洞察を提供し、この分野での将来のIETFの取り組みへの最初の入力として役立つことを願っています。
In recent years, there have been a number of research and engineering efforts to design IP source address validation mechanisms, such as [RFC2827], [Park01], [Li02], [Brem05], and [Snoe01]. Our SAVA prototype implementation was inspired by some of the schemes from the proposed or existing solutions.
近年、[RFC2827]、[PARK01]、[Li02]、[BREM05]、[SNOE01]などのIPソースアドレス検証メカニズムを設計するための多くの研究と工学の取り組みがあります。当社のSAVAプロトタイプ実装は、提案されたソリューションまたは既存のソリューションのスキームの一部に触発されました。
The prototype implementation and experimental results presented in this report serve only as an input, and by no means preempt any solution development that may be carried out by future IETF effort. Indeed, the presented solutions are experimental approaches and have a number of limitations as discussed in Sections 5 and 6.
このレポートで提示されたプロトタイプの実装と実験結果は、入力としてのみ機能し、将来のIETFの取り組みによって実行される可能性のあるソリューション開発を先取りすることは決してありません。実際、提示されたソリューションは実験的なアプローチであり、セクション5および6で説明したように多くの制限があります。
A multiple-fence solution is proposed in this document. That is, there are multiple points in the network at which the validity of a packet's source address can be checked. This is because in the current single-fence model where source address validity is essentially checked only at ingress to the network, deployment has been inadequate to the point that there is always sufficient opportunity to mount attacks based on spoofed source addresses, and it seems likely that this condition will continue in the foreseeable future. A multiple-fence solution will allow "holes" in deployment to be covered and validity of the source address to be evaluated with increased confidence across the whole Internet. The assumption here is that when validity checking is not universal, it is still worthwhile to increase the confidence in the validity of source addresses and to reduce the opportunities to mount a source address spoofing attack.
Furthermore, the architecture allows for multiple independent and loosely-coupled checking mechanisms. The motivation for this is that in the Internet at large, it is unrealistic to expect any single IP source address validation mechanism to be universally supported. Different operators and vendors may choose to deploy/develop different mechanisms to achieve the same end, and there need to be different mechanisms to solve the problem at different places in the network. Furthermore, implementation bugs or configuration errors could potentially render an implementation ineffective. Therefore, our prototype SAVA implementation is a combination of multiple coexisting and cooperating mechanisms. More specifically, we implement source IP address validation at three levels: access network source address validation; intra-AS source address validation; and inter-AS source address validation, as shown in Figure 1. The system details can be found in [Wu07].
さらに、このアーキテクチャにより、複数の独立した、ゆるく結合されたチェックメカニズムが可能になります。これの動機は、インターネット全体で、単一のIPソースアドレス検証メカニズムが普遍的にサポートされることを期待することは非現実的であるということです。異なるオペレーターとベンダーは、同じ目的を達成するために異なるメカニズムを展開/開発することを選択する場合があり、ネットワーク内のさまざまな場所で問題を解決するために異なるメカニズムが必要です。さらに、実装のバグまたは構成エラーは、実装を効果的ではない可能性があります。したがって、当社のプロトタイプSAVA実装は、複数の共存と協力メカニズムの組み合わせです。より具体的には、3つのレベルでソースIPアドレスの検証を実装します。アクセスネットワークソースアドレス検証。ソースアドレスの検証としてのイントラ。図1に示すように、ソースアドレスの検証間では、システムの詳細は[WU07]にあります。
__ ____ __ ____
.-'' `': .-'' `':
| | | |
| +-+----+ | Inter-AS SAV | +-+----+ |
| |Router+--+------------------+---|Router+ +
| +--.---+ | | +--.---+ |
Intra-AS | | \ Intra-AS | | |
SAV | +--+---+ \ SAV | +--+---+ |
| |Router| \ | |Router| |
| +--.---+ \ '_ +-----+ _
| | \ `'-------'''
/ | \
/ | \
| +---------------------+\
----+---------. Router | \
| ++-------\------------+ \
| | | \ | | |
| | +------+|+------++----+|Intra-AS
| | |Switch|||Switch||Host||SAV
| | +------+|+------++----+|
| | | | | \ |
|+-+--++----+|+----++----+ |
||Host||Host|||Host||Host| |
`+----++----+|+----++----+ /
`--. | _.-'
`------|------+''
Access |
Network |
SAV
Key: SAV - Source Address Validation
キー：SAV-ソースアドレスの検証
Figure 1: Solution Overview
図1：解決策の概要
This document divides source address validation into three different classes of solutions:
1. Access network. This prevents a host in a network from spoofing the address of another host in the same network segment. This enables host-granularity of protection compared to Intra-AS prevention. See Section 2.2 for details.
1. アクセスネットワーク。これにより、ネットワーク内のホストが同じネットワークセグメント内の別のホストのアドレスを引き起こすことを防ぎます。これにより、AS Intra-AS予防と比較して、宿主の保護粒度が可能になります。詳細については、セクション2.2を参照してください。
2. Intra-AS. When the edge router of an access network performs source address validation (e.g., using [RFC2827] and [RFC3704]), hosts are prevented from spoofing an arbitrary address, but unless access network SAV is employed, they may be able to spoof an address of a host in the same network segment. In a degenerate case, when a router connects a single host, the host can't spoof any address.
2. Intra-as。アクセスネットワークのエッジルーターがソースアドレスの検証を実行すると（例：[RFC2827]および[RFC3704]）、ホストは任意のアドレスをスプーフィングすることができませんが、アクセスネットワークSAVが採用されない限り、アドレスを呼び出すことができます。同じネットワークセグメントのホストの。縮退した場合、ルーターが単一のホストを接続すると、ホストはどのアドレスを押し付けることができません。
3. Inter-AS. Mechanisms that enforce packet source address correctness at AS boundaries. Because the global Internet has a mesh topology, and because different networks belong to different administrative authorities, IP source address validation at the Inter-AS level is more challenging. Nevertheless, we believe this third level of protection is necessary to detect packets with spoofed source addresses, when the first two levels of source address validation are missing or ineffective.
3. Inter-as。境界でパケットソースアドレスの正しさを強制するメカニズム。グローバルインターネットにはメッシュトポロジがあり、異なるネットワークが異なる管理当局に属しているため、INTER-ASレベルでのIPソースアドレスの検証はより困難です。それにもかかわらず、ソースアドレスの最初のレベルの検証が欠落または効果がない場合、スプーフィングされたソースアドレスでパケットを検出するには、この第3レベルの保護が必要であると考えています。
In the following sections, we describe the specific mechanisms implemented at each of the three levels in detail.
次のセクションでは、3つのレベルのそれぞれに実装された特定のメカニズムについて詳細に説明します。
At the access network level, the solution ensures the host inside the access network cannot use the source address of another host. The host address should be a valid address assigned to the host statically or dynamically. The solution implemented in the experiment provides such a function for Ethernet networks. A layer-3 source address validation architecture device (SAVA Device) for the access network (the device can be a function inside the Customer Premises Equipment (CPE) router or a separate device) is deployed at the exit of the access network. Source address validation architecture agents (SAVA Agents) are deployed inside the access network. (In fact, these agents could be a function inside the first hop router/switch connected to the hosts.) A set of protocols was designed for communication between the host, SAVA Agent, and SAVA Device. Only a packet originating from the host that was assigned that particular source address may pass through the SAVA Agent and SAVA Device.
アクセスネットワークレベルでは、ソリューションにより、アクセスネットワーク内のホストが別のホストのソースアドレスを使用できないようにします。ホストアドレスは、静的または動的にホストに割り当てられた有効なアドレスである必要があります。実験で実装されたソリューションは、イーサネットネットワークにこのような関数を提供します。アクセスネットワーク用のレイヤー-3ソースアドレス検証アーキテクチャデバイス（SAVAデバイス）（デバイスは、アクセスネットワークの出口に展開されます。ソースアドレス検証アーキテクチャエージェント（SAVAエージェント）は、アクセスネットワーク内に展開されます。（実際、これらのエージェントは、ホストに接続された最初のホップルーター/スイッチ内の関数になる可能性があります。）一連のプロトコルは、ホスト、SAVAエージェント、およびSAVAデバイス間の通信用に設計されました。特定のソースアドレスがSAVAエージェントとSAVAデバイスを通過できると割り当てられたホストから発信されるパケットのみ。
Two possible deployment variants exist; we will call them Variant A and Variant B. In Variant A, an agent is mandatory and each host is attached to the agent on a dedicated physical port. In Variant B, hosts are required to perform network access authentication and generate key material needed to protect each packet. In this variant, the agent is optional.
The key function of Variant A is to create a dynamic binding between a switch port and valid source IP address, or a binding between Media Access Control (MAC) address, source IP address, and switch port. In the prototype, this is established by having hosts employ a new address configuration protocol that the switch is capable of tracking.
バリアントAの重要な機能は、スイッチポートと有効なソースIPアドレス間の動的バインディング、またはメディアアクセスコントロール（MAC）アドレス、ソースIPアドレス、スイッチポート間のバインディングを作成することです。プロトタイプでは、これは、スイッチが追跡できる新しいアドレス構成プロトコルをホストに使用させることによって確立されます。
Note: In a production environment, the approach in the prototype would not be sufficient due to reasons discussed in Section 5.
注：生産環境では、セクション5で説明した理由により、プロトタイプのアプローチは十分ではありません。
In Variant A, there are three main participants: Source Address Request Client (SARC) on the host, Source Address Validation Proxy (SAVP) on the switch, and Source Address Management Server (SAMS). as shown in Figure 2. The solution follows the basic steps below:
バリアントAには、3人の主な参加者がいます。ホスト上のソースアドレスリクエストクライアント（SARC）、スイッチのソースアドレス検証プロキシ（SAVP）、およびソースアドレス管理サーバー（SAMS）。図2に示すように、ソリューションは以下の基本的な手順に従います。
1. The SARC on the end host sends an IP address request. The SAVP on the switch relays this request to the SAMS and records the MAC address and incoming port. If the address has already been predetermined by the end host, the end host still needs to put that address in the request message for verification by SAMS.
1. End HostのSARCは、IPアドレスリクエストを送信します。スイッチのSAVPは、この要求をSAMSにリレーし、MACアドレスと着信ポートを記録します。アドレスがすでにエンドホストによって事前に決定されている場合、EndホストはまだそのアドレスをSAMSによる検証の要求メッセージに配置する必要があります。
2. After the SAMS receives the IP address request, it then allocates a source address for that SARC based on the address allocation and management policy of the access network, it stores the allocation of the IP address in the SAMS history database for traceback, then sends response message containing the allocated address to the SARC.
2. SAMSがIPアドレスリクエストを受信した後、アクセスネットワークのアドレス割り当てと管理ポリシーに基づいてそのSARCのソースアドレスを割り当て、TracebackのSAMS履歴データベースにIPアドレスの割り当てを保存し、応答を送信しますSARCへの割り当てられたアドレスを含むメッセージ。
3. After the SAVP on the access switch receives the response, it binds the IP address and the former stored MAC address of the request message with the switch port on the binding table. Then, it forwards the issued address to SARC on the end host.
3. アクセススイッチのSAVPが応答を受信した後、IPアドレスと、バインディングテーブルのスイッチポートを使用して、リクエストメッセージの以前の保存されたMACアドレスをバインドします。次に、発行されたアドレスを最後のホストでSARCに転送します。
4. The access switch begins to filter packets sent from the end host. Packets which do not conform to the tuple (IP address, Switch Port) are discarded.
4. アクセススイッチは、エンドホストから送信されたパケットをフィルタリングし始めます。タプル（IPアドレス、スイッチポート）に適合しないパケットが破棄されます。
----------------
| SERVER |
| ------- |
| | SAMS | |
| -------- |
-----------------
|
|
----------------
| SWITCH |
| ------- |
| | SAVP | |
| -------- |
-----------------
|
|
----------------
| END HOST |
| ------- |
| | SARC | |
| -------- |
-----------------
Key: SARC - Source Address Request Client SAVP - Source Address Validation Proxy SAMS - Source Address Management Sever
キー：SARC-ソースアドレスリクエストクライアントSAVP-ソースアドレス検証プロキシSAMS-ソースアドレス管理SEVER
Figure 2: Binding-Based IP Source Address Validation in the Access Network
図2：アクセスネットワークでのバインディングベースのIPソースアドレス検証
The main idea of Variant B is to employ key material from network access authentication for some additional validation process. A session key is derived for each host connecting to the network, and each packet sent by the host has cryptographic protection that employs this session key. After establishing which host the packet comes from, it again becomes possible to track whether the addresses allocated to the host match those used by the host. The mechanism details can be found in [XBW07], but the process follows these basic steps:
バリアントBの主なアイデアは、いくつかの追加の検証プロセスのために、ネットワークアクセス認証から重要な資料を使用することです。ネットワークに接続するホストごとにセッションキーが導出され、ホストが送信した各パケットには、このセッションキーを使用する暗号化保護があります。どのホストが由来するかを確立した後、ホストに割り当てられたアドレスがホストが使用しているものと一致するかどうかを追跡することが再び可能になります。メカニズムの詳細は[xbw07]にありますが、プロセスはこれらの基本的な手順に従います。
1. When a host wants to establish connectivity, it needs to perform network access authentication.
1. ホストが接続を確立したい場合、ネットワークアクセス認証を実行する必要があります。
2. The network access devices provide the SAVA Agent (often co-located) a session key S. This key is further distributed to the SAVA Device. The SAVA Device binds the session key and the host's IP address.
2. ネットワークアクセスデバイスは、SAVAエージェント（多くの場合、共同住宅）をセッションキーSに提供します。このキーは、SAVAデバイスにさらに配布されます。SAVAデバイスは、セッションキーとホストのIPアドレスにバインドします。
3. When the host sends packet M to somewhere outside the access network, either the host or the SAVA Agent needs to generate a message authentication code for each using key S and packet M. In the prototype, the message authentication code is carried in an experimental IPv6 extension header.
3. ホストがアクセスネットワークの外側のどこかにパケットMを送信する場合、ホストまたはSAVAエージェントは、キーsとパケットMを使用して各プロトタイプでメッセージ認証コードを生成する必要があります。拡張ヘッダー。
4. The SAVA Device uses the session key to authenticate the signature carried in the packet so that it can validate the source address.
4. SAVAデバイスは、セッションキーを使用して、パケットにある署名を認証して、ソースアドレスを検証できるようにします。
In our testbed, we implemented and tested both solutions. The switch-based solution has better performance, but the switches in the access network would need to be upgraded (usually the number of switches in an access network is large). The signature-based solution could be deployed between the host and the exit router, but it has some extra cost in inserting and validating the signature.
テストベッドでは、両方のソリューションを実装およびテストしました。スイッチベースのソリューションはパフォーマンスが向上しますが、アクセスネットワークのスイッチをアップグレードする必要があります（通常、アクセスネットワーク内のスイッチの数は大きいです）。署名ベースのソリューションは、ホストとExitルーターの間に展開できますが、署名の挿入と検証には追加のコストがあります。
We adopted the solution of the source address validation of IP packets at ingress points described in [RFC2827] and [RFC3704]; the latter describes source address validation at the ingress points of multi-homed access networks.
[RFC2827]および[RFC3704]に記載されているイングレスポイントで、IPパケットのソースアドレス検証のソリューションを採用しました。後者は、マルチホームアクセスネットワークの入り口でのソースアドレスの検証について説明しています。
Our design for the Inter-AS Source Address Validation included the following characteristics: It should cooperate among different ASes with different administrative authorities and different interests. It should be lightweight enough to support high throughput and not to influence forwarding efficiency.
Inter-As-As Sourceアドレスの検証のための私たちの設計には、次の特性が含まれていました。異なる管理当局とさまざまな関心を持つさまざまなASの間で協力する必要があります。高度なスループットをサポートし、転送効率に影響を与えないほど軽量でなければなりません。
The inter-AS level of SAVA can be classified into two sub-cases:
SAVAのレベルASレベルは、2つのサブケースに分類できます。
o Two SAVA-compliant ASes exchanging traffic are directly connected;
o トラフィックを交換する2つのSAVA準拠のASESが直接接続されています。
o Two SAVA-compliant ASes are separated by one or more intervening, non-SAVA-compliant providers.
o 2つのサバに準拠したASは、1つまたは複数の介在した非サバに準拠したプロバイダーによって分離されています。
---------
| AIMS |
------|-
|
-------------- -----------|-----
| AS-4 |-------- --------| AS-1 | |------- Global
| ------ |ASBR,VE|->|ASBR,VE| ------|- |ASBR,VE|--->IPv6
| |VRGE| |-------- --------| | VRGE | |------- Network
| ------ | | -------- |
--------------- ----- -----------------
|ASBR,VE| |ASBR,VE|
--------- ---------
/ |
/ |
/ |
/ |
---------- --------
|ASBR, VE| |ASBR,VE|
--------------- -------------
| AS-2 | | AS-3 |
| ----- | | ----- |
| |VRGE| | | |VRGE| |
| ----- | | ------ |
--------------- -------------
Key: AIMS - AS-IPv6 prefix Mapping Server ASBR - AS Border Router VE - Validating Engine VR - Validation Rule VRGE - Validation Rule Generating Engine
キー：AIMS -AS -IPV6プレフィックスマッピングサーバーASBR-ボーダールーターとして - エンジンVRの検証 - 検証ルールVRGE-検証ルール生成エンジン
Figure 3: Inter-ISP (Neighboring AS) Solution
図3：ISP間（隣接するAS）ソリューション
Two ASes that exchange traffic have a customer-to-provider, provider-to-customer, peer-to-peer, or sibling-to-sibling relationship. In a customer-to-provider or provider-to-customer relationship, the customer typically belongs to a smaller administrative domain that pays a larger administrative domain for access to the rest of Internet. The provider is an AS that belongs to the larger administrative domain. In a peer-to-peer relationship, the two peers typically belong to administrative domains of comparable size and find it mutually advantageous to exchange traffic between their respective customers. Two ASes have a sibling-to-sibling relationship if they belong to the same administrative domain or to administrative domains that have a mutual-transit agreement.
交換トラフィックには、顧客からプロバイダー、プロバイダーからカスタマー、ピアツーピア、または兄弟と兄弟の関係があります。顧客とプロバイダーまたはプロバイダーとカスタマーの関係では、顧客は通常、インターネットの他の部分にアクセスするためにより大きな管理領域を支払う小さな管理領域に属します。プロバイダーは、より大きな管理ドメインに属するASです。ピアツーピアの関係では、2人のピアは通常、同等のサイズの管理ドメインに属し、それぞれの顧客間でトラフィックを交換することが相互に有利であることがわかります。2人のASは、同じ管理領域または相互輸送契約を結んでいる管理ドメインに属している場合、兄弟と兄弟の関係を持っています。
An AS-relation-based mechanism is used for neighboring SAVA-compliant ASes. The basic ideas of this AS-relation-based mechanism are as follows. It builds a VR table that associates each incoming interface of a router with a set of valid source address blocks, and then uses it to filter spoofed packets.
隣接するサバに準拠したASEには、関係ベースのメカニズムが使用されます。この関連するメカニズムの基本的なアイデアは次のとおりです。ルーターの各着信インターフェイスを有効なソースアドレスブロックのセットに関連付けるVRテーブルを構築し、それを使用してスプーフィングされたパケットをフィルタリングします。
In the solution implemented on the testbed, the solution for the validation of IPv6 prefixes is separated into three functional modules: The Validation Rule Generating Engine (VRGE), the Validation Engine (VE), and the AS-IPv6 prefix Mapping Server (AIMS). Validation rules that are generated by the VRGE are expressed as IPv6 address prefixes.
テストベッドに実装されたソリューションでは、IPv6プレフィックスを検証するためのソリューションが3つの機能モジュールに分離されます：検証ルール生成エンジン（VRGE）、検証エンジン（VE）、およびAS-IPV6プレフィックスマッピングサーバー（AIMS）。VRGEによって生成される検証ルールは、IPv6アドレスプレフィックスとして表されます。
The VRGE generates validation rules that are derived according to
Table 1, and each AS has a VRGE. The VE loads validation rules
generated by VRGE to filter packets passed between ASes (in the case
of Figure 3, from neighboring ASes into AS-1). In the SAVA testbed,
the VE is implemented as a simulated layer-2 device on a Linux-based
machine inserted into the data path just outside each ASBR interface
that faces a neighboring AS. In a real-world implementation, it
would probably be implemented as a packet-filtering set on the ASBR.
The AS-IPv6 prefix mapping server is also implemented on a Linux
machine and derives a mapping between an IPv6 prefix and the AS
number of that prefix.
----------------------------------------------------------------------
| \Export| Own | Customer's| Sibling's | Provider's | Peer's |
|To \ | Address | Address | Address | Address | Address |
|-----\--------------------------------------------------------------|
| Provider | Y | Y | Y | | |
|--------------------------------------------------------------------|
| Customer | Y | Y | Y | Y | Y |
|--------------------------------------------------------------------|
| Peer | Y | Y | Y | | |
|--------------------------------------------------------------------|
| Sibling | Y | Y | Y | Y | Y |
----------------------------------------------------------------------
Table 1: AS-Relation-Based Inter-AS Filtering
表1：ASにベースのAS Inter-ASフィルタリング
Different ASes exchange and transmit VR information using the AS-Relation-Based Export Rules in the VRGE. As per Table 1, an AS exports the address prefixes of itself, its customers, its providers, its siblings, and its peers to its customers and siblings as valid prefixes, while it only exports the address prefixes of itself, its customers, and its siblings to its providers and peers as valid prefixes. With the support of the AS-IPv6 prefix mapping server, only AS numbers of valid address prefixes are transferred between ASes, and the AS number is mapped to address prefixes at the VRGE.
さまざまなASESを交換およびVRGEベースのエクスポートルールを使用してVR情報を交換および送信します。表1によると、Aはそれ自体、顧客、そのプロバイダー、その兄弟、その仲間のアドレスのプレフィックスを有効なプレフィックスとして顧客と兄弟にエクスポートしますが、それ自体、顧客、およびその顧客のアドレスのプレフィックスをエクスポートするだけです。有効な接頭辞としてプロバイダーとピアへの兄弟。AS-IPV6プレフィックスマッピングサーバーのサポートにより、有効なアドレスプレフィックスの数がASEの間に転送され、AS番号がVRGEのプレフィックスアドレスにマッピングされます。
Only changes of AS relation and changes of IP address prefixes belonging to an AS require the generation of VR updates.
ASに属するIPアドレスプレフィックスの関係と変更の変更のみが、VRの更新の生成が必要です。
The procedure's principal steps are as follows (starting from AS-1 in Figure 3):
手順の主要な手順は次のとおりです（図3のAS-1から始まります）：
1. When the VRGE has initialized, it reads its neighboring SAVA-compliant AS table and establishes connections to all the VEs in its own AS.
1. VRGEが初期化されたとき、隣接するSava準拠をテーブルとして読み取り、すべてのVESとの接続を確立します。
2. The VRGE initiates a VR renewal. According to its export table, it sends its own originated VR to VRGEs of neighboring ASes. In this process, VRs are expressed as AS numbers.
2.
3. When a VRGE receives a new VR from its neighbor, it uses its own export table to decide whether it should accept the VR and, if it accepts a VR, whether or not it should re-export the VR to other neighboring ASes.
3. VRGEが隣人から新しいVRを受信すると、独自のエクスポートテーブルを使用して、VRを受け入れるべきかどうか、およびVRを受け入れるかどうか、VRを他の隣接ASに再輸出するかどうかを決定します。
4. If the VRGE accepts a VR, it uses the AIMS to transform the AS-expressed VR into an IPv6 prefix-expressed VR.
4. VRGEがVRを受け入れる場合、ASが発現したVRをIPv6プレフィックス発現VRに変換する目的を使用します。
5. The VRGE pushes the VR to all the VEs in its AS.
5. VRGEは、VRをASのすべてのVEにプッシュします。
The VEs use these prefix-based VRs to validate the source IP addresses of incoming packets.
VEは、これらのプレフィックスベースのVRSを使用して、着信パケットのソースIPアドレスを検証します。
2.5. IP Source Address Validation in the Inter-AS Case (Non-Neighboring AS)
2.5. IPソースアドレスの検証間、ASの場合（AS以外）
In the case where two ASes do not exchange packets directly, it is not possible to deploy a solution like that described in the previous section. However, it is highly desirable for non-neighboring ISPs to be able to form a trust alliance such that packets leaving one AS will be recognized by the other and inherit the validation status they possessed on leaving the first AS. There is more than one way to do this. For the SAVA experiments to date, an authentication tag method has been used. This solution is inspired by the work of [Brem05].
2つのASEがパケットを直接交換しない場合、前のセクションで説明したようなソリューションを展開することはできません。ただし、非相続ISPが信頼同盟を形成できるようにすることは非常に望ましいことです。これにより、パケットは他の人によって認識され、最初のASを離れることで持っている検証ステータスを継承します。これを行う方法は複数あります。これまでのSAVA実験では、認証タグ法が使用されています。このソリューションは、[BREM05]の作品に触発されています。
The key elements of this lightweight authentication tag based mechanism are as follows: For each pair of SAVA-compliant ASes, there is a pair of unique temporary authentication tags. All SAVA-compliant ASes together form a SAVA AS Alliance. When a packet is leaving its own AS, if the destination IP address belongs to an AS in the SAVA AS Alliance, the edge router of this AS looks up the authentication tag using the destination AS number as the key, and adds an authentication tag to the packet. When a packet arrives at the destination AS, if the source address of the packet belongs to an AS in the SAVA AS Alliance, the edge router of the destination AS searches its table for the authentication tag using the source AS number as the key, and the authentication tag carried in the packet is verified and removed. As suggested by its name, this particular method uses a lightweight authentication tag. For every packet forwarded, the authentication tag can be put in an IPv6 hop-by-hop extension header. It is reasonable to use a 128-bit shared random number as the authentication tag to save the processing overhead brought by using a cryptographic method to generate the authentication tag.
この軽量認証タグベースのメカニズムの重要な要素は次のとおりです。SAVA準拠のASEのペアごとに、一本の一時的な認証タグがあります。すべてのサバに準拠したASEは一緒になって、同盟としてサバを形成します。パケットが独自のままにしている場合、宛先IPアドレスがAssa as AllianceとしてAsに属している場合、宛先をキーとして宛先を使用して認証タグを検索し、認証タグを追加し、認証タグを追加します。パケット。パケットが宛先に到着すると、パケットのソースアドレスがAs as as as a sava as Allianceに属している場合、宛先のエッジルーターは、ソースをキーとして使用して認証タグのテーブルを検索します。パケットに掲載された認証タグが検証され、削除されます。その名前で示唆されているように、この特定の方法は軽量認証タグを使用しています。転送されたすべてのパケットについて、認証タグはIPv6ホップバイホップエクステンションヘッダーに配置できます。128ビットの共有乱数を認証タグとして使用して、暗号化方法を使用して認証タグを生成してもたらされた処理オーバーヘッドを保存することが合理的です。
The benefit of this scheme compared to merely turning on local address validation (such as RFC 2827) is as follows: when local address validation is employed within a group of networks, it is assured that their networks do not send spoofed packets. But other networks may still do this. With the above scheme, however, this capability is eliminated. If someone outside the alliance spoofs a packet using a source address from someone within the alliance, the members of the alliance refuse to accept such a packet.
このスキームの利点は、単にローカルアドレスの検証（RFC 2827など）をオンにすることと比較して次のとおりです。ローカルアドレスの検証がネットワークのグループ内で採用されている場合、ネットワークはスプーフィングされたパケットを送信しないことが保証されています。しかし、他のネットワークはまだこれを行う場合があります。ただし、上記のスキームでは、この機能は排除されます。アライアンスの外の誰かがアライアンス内の誰かからのソースアドレスを使用してパケットをふさぎたい場合、同盟のメンバーはそのようなパケットを受け入れることを拒否します。
+-----+
.-----------------+ REG |-----------------.
| +-----+ |
| |
,-----+-------- ,------+-------
,' `| `. ,' ` | `.
/ | \ / | \
/ | \ / | \
; +--'--+ +----+ +----+ +-----+ ;
| | ASC +------+ASBR| |ASBR+-----+ ASC | |
: +--.--+ +----+` +----+ +--+--+ :
\ |__________________________________________| /
\ / \ /
`. ,' `. ,'
'-------------' '-------------'
AS-1 AS-2
Key: REG - Registration Server ASC - AS Control Server ASBR - AS Border Router
キー：Reg-登録サーバーASC-コントロールサーバーASBR-ボーダールーターとして
Figure 4: Inter-AS (Non-Neighboring AS) Solution
図4：AS間（非依存性AS）ソリューション
There are three major components in the system: the Registration Server (REG), the AS Control Server (ASC), and the AS Border Router (ASBR).
システムには、登録サーバー（REG）、As Control Server（ASC）、およびAS Border Router（ASBR）の3つの主要なコンポーネントがあります。
The Registration Server is the "center" of the trust alliance (TA). It maintains a member list for the TA. It performs two major functions:
登録サーバーは、Trust Alliance（TA）の「センター」です。TAのメンバーリストを維持しています。2つの主要な機能を実行します。
o Processes requests from the AS Control Server, to get the member list for the TA.
o プロセスAS Control Serverからリクエストを使用して、TAのメンバーリストを取得します。
o Notifies each AS Control Server when the member list is changed.
o メンバーリストが変更されたときに、それぞれにコントロールサーバーとして通知します。
Each AS deploying the method has an AS Control Server. The AS Control Server has three major functions:
メソッドを展開することはそれぞれ、ASコントロールサーバーを持っています。ASコントロールサーバーには3つの主要な機能があります。
o Communicates with the Registration Server, to get the up-to-date member list of TA.
o 登録サーバーと通信して、TAの最新のメンバーリストを取得します。
o Communicates with the AS Control Server in other member ASes in the TA, to exchange updates of prefix ownership information and to exchange authentication tags.
o TAの他のメンバーASEのASコントロールサーバーと通信し、プレフィックスの所有権情報の更新を交換し、認証タグを交換します。
o Communicates with all AS Border Routers of the local AS, to configure the processing component on the AS Border Routers.
o As AsのAs As As As Border Rutersと通信して、As Border Routerで処理コンポーネントを構成します。
The AS Border Router does the work of adding the authentication tag to the packet at the sending AS, and the work of verifying and removing the authentication tag at the destination AS.
In the design of this system, in order to decrease the burden on the REG, most of the control traffic happens between ASCs.
このシステムの設計では、REGの負担を減らすために、ほとんどの制御トラフィックはASC間で発生します。
The authentication tag needs to be changed periodically. Although the overhead of maintaining and exchanging authentication tags between AS pairs is O(N) from the point of view of one AS, rather than O(N^2), the traffic and processing overhead do increase as the number of ASes increases. Therefore, an automatic authentication tag refresh mechanism is utilized in this solution. In this mechanism, each peer runs the same algorithm to automatically generate an authentication tag sequence. Then the authentication tag in packets can be changed automatically with high frequency. To enhance the security, a seed is used for the algorithm to generate an authentication tag sequence robust against guessing. Thus, the peers need only to negotiate and change the seed at very low frequency. This lowers the overhead associated with frequently negotiating and changing the authentication tag while maintaining acceptable security.
認証タグは定期的に変更する必要があります。ASペア間の認証タグの維持と交換のオーバーヘッドは、O（n^2）ではなく、ASの観点からO（n）ですが、ASESの数が増えるにつれてトラフィックと処理のオーバーヘッドが増加します。したがって、このソリューションでは、自動認証タグ更新メカニズムが利用されています。このメカニズムでは、各ピアが同じアルゴリズムを実行して、認証タグシーケンスを自動的に生成します。パケットの認証タグは、高周波で自動的に変更できます。セキュリティを強化するために、アルゴリズムにシードが使用され、推測に対して堅牢な認証タグシーケンスを生成します。したがって、ピアは非常に低い頻度で種子を交渉して変更するだけで済みます。これにより、許容可能なセキュリティを維持しながら、認証タグを頻繁に交渉および変更することに関連するオーバーヘッドが低下します。
Since the authentication tag is put in an IPv6 hop-by-hop extension header, the MTU issues should be considered. Currently we have two solutions to this problem. Neither of the solutions is perfect, but they are both feasible. One possible way is to set the MTU at the ASBR to be 1280 bytes, which is the minimum MTU for the IPv6. Thus, there should be no ICMP "Packet Too Big" message received from the downstream gateways. The disadvantage of this solution is that it doesn't make good use of the available MTU. The other possible way is to let the ASBR catch all incoming ICMP "Packet Too Big" messages, and decrease the value in the MTU field before forwarding it into the AS. The advantage of this solution is that it can make good use of the available MTU. But such processing of ICMP packets at the ASBR may create a target for a denial-of-service (DoS) attack.
認証タグはIPv6ホップバイホップ拡張ヘッダーに配置されるため、MTUの問題を考慮する必要があります。現在、この問題に対する2つの解決策があります。どちらも完璧ではありませんが、どちらも実行可能です。可能な方法の1つは、ASBRでMTUを1280バイトに設定することです。これはIPv6の最小MTUです。したがって、下流のゲートウェイから受信したICMP「パケットが大きすぎる」メッセージはないはずです。このソリューションの欠点は、利用可能なMTUをうまく利用しないことです。もう1つの可能な方法は、ASBRがすべての着信ICMP「パケットが大きすぎる」メッセージをキャッチさせ、ASに転送する前にMTUフィールドの値を減らすことです。このソリューションの利点は、利用可能なMTUをうまく利用できることです。しかし、ASBRでのICMPパケットのこのような処理は、サービス拒否（DOS）攻撃のターゲットを作成する場合があります。
Because the authentication tag is validated at the border router of the destination AS, not the destination host, the destination options header is not chosen to carry the authentication tag.
認証タグは、宛先ホストではなく、宛先オプションヘッダーが認証タグを携帯するために選択されていないため、宛先の境界ルーターで検証されているためです。
Authentication tag management is a critical issue. Our work focused on two points: tag negotiation and tag refresh. The tag negotiation happens between the ASCs of a pair of ASes in the SAVA AS Alliance. Considering the issue of synchronization and the incentive of enabling SAVA, receiver-driven tag negotiation is suggested. It gives more decision power to the receiver AS rather than the sender AS. With a receiver-driven scheme, the receiver AS can decide the policies of tag management. The packets tagged with old authentication tags should not be allowed indefinitely. Rather, after having negotiated a new tag, the old tag should be set to be invalid after a period of time. The length of this period is a parameter that will control how long the old tag will be valid after the new tag has been assigned. In the experiment, we used five seconds.
認証タグ管理は重大な問題です。私たちの仕事は、タグネゴシエーションとタグリフレッシュの2つのポイントに焦点を当てています。タグの交渉は、同盟としてのSAVAのASEのペアのASCの間で行われます。同期の問題とSavaを有効にするインセンティブを考慮すると、受信者駆動型のタグ交渉が提案されています。送信者としてではなく、受信機により多くの決定力を与えます。受信者駆動型スキームを使用すると、受信者はタグ管理のポリシーを決定できます。古い認証タグでタグ付けされたパケットは、無期限に許可されるべきではありません。むしろ、新しいタグを交渉した後、古いタグを一定期間後に無効にするように設定する必要があります。この期間の長さは、新しいタグが割り当てられた後に古いタグが有効になる期間を制御するパラメーターです。実験では、5秒を使用しました。
The trust alliance is intended to be established dynamically (join and quit), but in this testbed we needed to confirm off-line the initial trust among alliance members.
Trust Allianceは動的に確立されることを目的としています（参加して終了）が、このテストベッドでは、Allianceメンバー間の最初の信頼をオフラインで確認する必要がありました。
The prototypes of our solutions for SAVA are implemented and tested on CNGI-CERNET2. CNGI-CERNET2 is one of the China Next Generation Internet (CNGI) backbones, operated by the China Education and Research Network (CERNET). CNGI-CERNET2 connects 25 core nodes distributed in 20 cities in China at speeds of 2.5-10 Gb/s. The CNGI-CERNET2 backbones are IPv6-only networks rather than being a mixed IPv4/IPv6 infrastructure. Only some Customer Premises Networks (CPNs) are dual-stacked. The CNGI-CERNET2 backbones, CNGI-CERNET2 CPNs, and CNGI-6IX all have globally unique AS numbers. Thus a multi-AS testbed environment is provided.
It is intended that eventually the SAVA testbed will be implemented
directly on the CNGI-CERNET2 backbone, but in the early stages the
testbed has been implemented across 12 universities connected to
CNGI-CERNET2. First, this is because some of the algorithms need to
be implemented in the testbed routers themselves, and to date they
have not been implemented on any of the commercial routers forming
the CNGI-CERNET2 backbone. Second, since CNGI-CERNET2 is an
operational backbone, any new protocols and networking techniques
need to be tested in a non-disruptive way.
__
,' \ _,...._
,' \____---------------+ ,'Beijing`.
/ \ | Inter-AS SAV |-----| Univ |
+---------------+ | | +---------------+ `-._____,'
| Inter-AS SAV +-----| |
+------.--------+ | CNGI- | _,...._
| | CERNET2 |__---------------+ ,Northeast`.
| | | |Inter-AS SAV |-----| Univ |
Tsinghua|University | Backbone| +---------------+ `-._____,'
,,-|-._ | |
,' | `. | |
,'+---------+\ | |
| |Intra-AS | | | | ...
| | SAV | | | |
| +---------+ | | |
| | | | | _,...._
| +---------+ | | |__---------------+ ,Chongqing`.
| | Access | | | | |Inter-AS SAV |-----|Univ |
| | Network | | | | +---------------+ `-._____,'
| | SAV | | | |
\ +---------+.' \ .'
\ ,' \ |
`. ,' \ /
``---' -_,'
Key: SAV - Source Address Validation
Figure 5: CNGI-CERNET2 SAVA Testbed
図5：CNGI-CERNET2 SAVAテストベッド
In any case, the testbed is fully capable of functional testing of solutions for all parts of SAVA. This includes testing procedures for ensuring the validity of IPv6 source addresses in the access network, in packets sent from the access network to an IPv6 service provider, in packets sent within one service provider's network, in packets sent between neighboring service providers, and in packets sent between service providers separated by an intervening transit network.
いずれにせよ、テストベッドは、SAVAのすべての部分のソリューションの機能的テストを完全にテストできます。これには、アクセスネットワーク内のIPv6ソースアドレスの有効性、アクセスネットワークからIPv6サービスプロバイダーに送信されたパケット、1つのサービスプロバイダーのネットワーク内で送信されるパケット、近隣のサービスプロバイダー間で送信されるパケット、およびパケット内のテスト手順が含まれます。介在するトランジットネットワークによって区切られたサービスプロバイダー間で送信されます。
The testbed is distributed across 12 universities connected to CNGI-CERNET2.
テストベッドは、CNGI-Cernet2に接続された12の大学に配布されています。
Each of the university installations is connected to the CNGI-CERNET2 backbone through a set of inter-AS Source Address Validation prototype equipment and traffic monitoring equipment for test result display.
各大学のインストールは、テスト結果表示用のソースアドレス間検証プロトタイプ機器とトラフィック監視機器のセットを介して、CNGI-Cernet2バックボーンに接続されています。
Each university deployed one AS. Six universities deployed all parts of the solution and are hence fully-featured, with validation at the inter-AS, intra-AS, and access network levels all able to be tested. In addition, a suite of applications that could be subject to spoofing attacks or that can be subverted to carry out spoofing attacks were installed on a variety of servers. Two solutions for the access network were deployed.
各大学はASを展開しました。6つの大学がソリューションのすべての部分を展開したため、完全に機能し、AS、ASインター、およびアクセスネットワークレベルで検証してテストできます。さらに、スプーフィング攻撃の対象となる可能性のある一連のアプリケーション、またはスプーフィング攻撃を実行するために破壊する可能性のあるスイートが、さまざまなサーバーにインストールされました。アクセスネットワークの2つのソリューションが展開されました。
The solutions outlined in section 2 were implemented on the testbed described in section 3. Successful testing of all solutions was been carried out, as detailed in the following sections.
セクション2で概説されているソリューションは、セクション3で説明されているテストベッドに実装されました。すべてのソリューションのテストの成功は、以下のセクションで詳述されているように実施されました。
For each of the test scenarios, we tested many cases. Taking the Inter-AS (non-neighboring AS) SAVA solution test as an example, we classified the test cases into three classes: normal class, dynamic class, and anti-spoofing class.
各テストシナリオについて、多くのケースをテストしました。Inter-AS（非依存性AS）Savaソリューションテストを例として、テストケースを3つのクラス、通常のクラス、動的クラス、およびスプーフィングアンチスプーフィングクラスに分類しました。
1. For normal class, there are three cases: Adding authentication tag Test, Removing authentication tag Test, and Forwarding packets with valid source address.
1. 通常のクラスの場合、認証タグテストの追加、認証タグテストの削除、有効なソースアドレスを使用してパケットを転送する3つのケースがあります。
2. For dynamic class, there are four cases: Updating the authentication tag between ASes, The protection for a newly joined member AS, Adding address space, and Deleting address space.
2. 動的クラスの場合、ASE間の認証タグの更新、新しく参加したメンバーとしての保護、アドレススペースの追加、アドレススペースの削除の4つのケースがあります。
3. For anti-spoofing class, there is one case: Filtering of packets with forged IP addresses.
3. スプーフィングアンチスポーフィングクラスには、1つのケースがあります。ForgedIPアドレスを使用したパケットのフィルタリングです。
As is shown in Figure 5, we have "multiple-fence" design for our SAVA testbed. If source address validation is deployed in the access network, we can get a host granularity validation. If source address validation is deployed at the intra-AS level, we can guarantee that the packets sent from this point have a correct IP prefix. If source address validation is deployed at the inter-AS level, we can guarantee that the packets sent from this point are from the correct AS.
図5に示すように、SAVAテストベッドには「複数フェンス」デザインがあります。ソースアドレスの検証がアクセスネットワークに展開されている場合、ホストの粒度検証を取得できます。ソースアドレスの検証がASレベル内で展開されている場合、この時点から送信されたパケットに正しいIPプレフィックスがあることを保証できます。Sourceアドレスの検証がInter-ASレベルで展開されている場合、この時点から送信されたパケットが正しいASからであることを保証できます。
1. The test results are consistent with the expected ones. For an AS that has fully-featured SAVA deployment with validation at the inter-AS, intra-AS, and access network levels, packets that do not hold an authenticated source address will not be forwarded in the network. As a result, it is not possible to launch network attacks with spoofed source addresses. Moreover, the traffic in the network can be traced back accurately.
1.
2. For the Inter-AS (non-neighboring AS) SAVA solution, during the period of authentication tag update, the old and the new authentication tags are both valid for source address validation; thus, there is no packet loss.
2. Inter-AS（非依存性AS）SAVAソリューションの場合、認証タグの更新期間中、古い認証タグと新しい認証タグはどちらもソースアドレスの検証に有効です。したがって、パケットの損失はありません。
3. For the Inter-AS (non-neighboring AS) SAVA solution, the validation function is implemented in software on a device running Linux, which simulates the source address validation functions of a router interface. It is a layer-2 device because it needs to be transparent to the router interface. During the test, when the devices were connected directly, normal line-rate forwarding was achieved. When the devices were connected with routers from another vendor, only a very limited forwarding speed was achieved. The reason is that the authentication tags are added on the IPv6 hop-by-hop option header, and many current routers can handle the hop-by-hop options only at a limited rate.
3.
There are several issues both within this overall problem area and with the particular approach taken in the experiment.
この全体的な問題領域内と実験で取られた特定のアプローチの両方にいくつかの問題があります。
There is a long-standing debate about whether the lack of universal deployment of source address validation is a technical issue that needs a technical solution, or if mere further deployment of existing tools (such as RFC 2827) would be a more cost effective way to improve the situation. Further deployment efforts of this tool have proved to be slow, however. Some of the solutions prototyped in this experiment allow a group of network operators to have additional protection for their networks while waiting for universal deployment of simpler tools in the rest of the Internet. This allows them to prevent spoofing attacks that the simple tools alone would not be able to prevent, even if already deployed within the group.
ソースアドレス検証の普遍的な展開の欠如が技術的なソリューションを必要とする技術的な問題であるかどうか、または既存のツールのさらなる展開（RFC 2827など）がより費用対効果の高い方法であるかどうかについて、長年の議論があります。状況を改善します。ただし、このツールのさらなる展開努力は遅いことが証明されています。この実験でプロトタイプ化されたソリューションの一部により、ネットワークオペレーターのグループは、他のインターネットでよりシンプルなツールの普遍的な展開を待っている間、ネットワークをさらに保護することができます。これにより、グループ内に既に展開されていても、単純なツールだけが防ぐことができないというスプーフィング攻撃を防ぐことができます。
Similarly, since a large fraction of current denial-of-service attacks can be launched by employing legitimate IP addresses belonging to botnet clients, even universal deployment of better source address validation techniques would be unable to prevent these attacks. However, tracing these attacks would be easier given that there would be more reliance on the validity of source address.
同様に、ボットネットのクライアントに属する正当なIPアドレスを採用することにより、現在のサービス拒否攻撃の大部分が起動できるため、より良いソースアドレス検証技術のユニバーサル展開でさえ、これらの攻撃を防ぐことができません。ただし、ソースアドレスの有効性により多くの依存があることを考えると、これらの攻撃を追跡する方が簡単です。
There is also a question about the optimal placement of the source address validation checks. The simplest model is placing the checks on the border of a network. Such RFC 2827-style checks are more widely deployed than full checks ensuring that all addresses within the network are correct. It can be argued that it is sufficient to provide such coarse granularity checks, because this makes it at least possible to find the responsible network administrators. However, depending on the type of network in question, those administrators may or may not find it easy to track the specific offending machines or users. It is obviously required that the administrators have a way to trace offending equipment or users -- even if the network does not block spoofed packets in real-time.
ソースアドレス検証チェックの最適な配置についての質問もあります。最も単純なモデルは、ネットワークの境界にチェックを配置することです。このようなRFC 2827スタイルのチェックは、完全なチェックよりも広く展開されており、ネットワーク内のすべてのアドレスが正しいことを保証します。このような粗い粒度チェックを提供するだけで十分であると主張することができます。これにより、責任あるネットワーク管理者を見つけることが少なくとも可能になるからです。ただし、問題のネットワークの種類によっては、これらの管理者は、特定の問題のあるマシンまたはユーザーを追跡するのが簡単だと思われる場合とそうでない場合があります。ネットワークがスプーフィングされたパケットをリアルタイムでブロックしていなくても、管理者が問題のある機器またはユーザーを追跡する方法を持っていることは明らかです。
New technology for address validation would also face a number of deployment barriers. For instance, all current technology can be locally and independently applied. A system that requires global operation (such as the Inter-AS validation mechanism) would require significant coordination, deployment synchronization, configuration, key setup, and other issues, given the number of ASes.
アドレス検証のための新しいテクノロジーは、多くの展開障壁にも直面します。たとえば、すべての現在のテクノロジーは、ローカルおよび独立して適用できます。ASEの数を考慮して、グローバルな動作（AS Inter-AS検証メカニズムなど）が必要なシステムには、重要な調整、展開同期、構成、キーセットアップ、およびその他の問題が必要です。
Similarly, deploying host-based access network address validation mechanisms requires host changes, and can generally be done only when the network owners are in control of all hosts. Even then, the changing availability of the host for all types of products and platforms would likely prevent universal deployment even within a single network.
同様に、ホストベースのアクセスネットワークアドレス検証メカニズムを展開するには、ホストの変更が必要であり、通常、ネットワーク所有者がすべてのホストを制御している場合にのみ実行できます。それでも、あらゆる種類の製品やプラットフォームのホストの可用性の変化は、単一のネットワーク内であってもユニバーサルの展開を防ぐ可能性があります。
There may be also be significant costs involved in some of these solutions. For instance, in an environment where access network authentication is normally not required, employing an authentication-based access network address validation would require deployment of equipment capable of this authentication as well as credentials distribution for all devices. Such undertaking is typically only initiated after careful evaluation of the costs and benefits involved.
Finally, all the presented solutions have issues in situations that go beyond a simple model of a host connecting to a network via the same single interface at all times. Multihoming, failover, and some forms of mobility or wireless solutions may collide with the requirements of source address validation. In general, dynamic changes to the attachment of hosts and topology of the routing infrastructure are something that would have to be handled in a production environment.
最後に、提示されたすべてのソリューションには、常に同じ単一のインターフェイスを介してネットワークに接続するホストの単純なモデルを超えた状況で問題があります。マルチホーム、フェイルオーバー、およびいくつかの形式のモビリティまたはワイヤレスソリューションは、ソースアドレスの検証の要件と衝突する可能性があります。一般に、ホストの付着に対する動的な変化とルーティングインフラストラクチャのトポロジーは、生産環境で処理する必要があるものです。
The security vs. scalability of the authentication tags in the Inter-AS (non-neighboring AS) SAVA solution presents a difficult tradeoff. Some analysis about the difficulty of guessing the authentication tag between two AS members was discussed in [Brem05]. It is relatively difficult, even with using a random number as an "authentication tag". The difficulty of guessing can be increased by increasing the length of the authentication tag.
Inter-as（非相続）Savaソリューションの認証タグのセキュリティ対スケーラビリティは、難しいトレードオフを提示します。[BREM05]で議論されたASメンバーとしての2つの間の認証タグを推測することの難しさに関するいくつかの分析。乱数を「認証タグ」として使用しても、比較的困難です。認証タグの長さを増やすことで、推測の難しさを増やすことができます。
In any case, the random number approach is definitely vulnerable to attackers who are on the path between the two ASes.
On the other hand, using an actual cryptographic hash in the packets will cause a significant increase in the amount of effort needed to forward a packet. In general, addition of the option and the calculation of the authentication tag consume valuable resources on the forwarding path. This resource usage comes on top of everything else that modern routers need to do at ever increasing line speeds. It is far from clear that the costs are worth the benefits.
一方、パケットに実際の暗号化ハッシュを使用すると、パケットを転送するのに必要な労力が大幅に増加します。一般に、オプションの追加と認証タグの計算により、転送パスで貴重なリソースが消費されます。このリソースの使用は、最新のルーターがより増加するライン速度で行う必要がある他のすべての上にあります。コストが利益に値することは明らかではありません。
In the current CNGI-CERNET2 SAVA testbed, a 128-bit authentication tag is placed in an IPv6 hop-by-hop option header. The size of the packets increases with the authentication tags. This by itself is expected to be acceptable, if the network administrator feels that the additional protection is needed. The size increases may result in an MTU issue, and we found a way to resolve it in the testbed. Since an IPv6 hop-by-hop option header was chosen, the option header has to be examined by all intervening routers. While in theory this should pose no concern, the test results show that many current routers handle hop-by-hop options with a much reduced throughput compared to normal traffic.
現在のCNGI-CERNET2 SAVAテストベッドでは、128ビット認証タグがIPv6ホップバイホップオプションヘッダーに配置されます。パケットのサイズは、認証タグとともに増加します。ネットワーク管理者が追加の保護が必要であると感じている場合、これ自体が受け入れられると予想されます。サイズの増加はMTU発行につながる可能性があり、テストベッドでそれを解決する方法を見つけました。IPv6ホップバイホップオプションヘッダーが選択されたため、オプションヘッダーはすべての介在するルーターで調べる必要があります。理論的にはこれは懸念をもたらさないはずですが、テスト結果は、現在の多くのルーターが通常のトラフィックと比較してはるかに減少したスループットを大幅に減らしてホップバイホップオプションを処理することを示しています。
The Inter-AS (neighboring AS) SAVA solution is based on the AS relation; thus, it may not synchronize with the dynamics of route changes very quickly and it may cause false positives. Currently, CNGI-CERNET2 is a relatively stable network, and this method works well in the testbed. We will further study the impact of false positives in an unstable network.
Inter-AS（隣接する）Savaソリューションは、AS関係に基づいています。したがって、ルートの変化のダイナミクスと非常に迅速に同期しない場合があり、誤検知を引き起こす可能性があります。現在、CNGI-Cernet2は比較的安定したネットワークであり、この方法はテストベッドでうまく機能します。不安定なネットワークでの誤検知の影響をさらに研究します。
The access network address validation solution is merely one option among many. Solutions appear to depend highly on the chosen link technology and network architecture. For instance, source address validation on point-to-point links is easy and has generally been supported by implementations for years. Validation in shared networks has been more problematic, but is increasing in importance given the use of Ethernet technology across administrative boundaries (such as in DSL). In any case, the prototyped solution has a number of limitations, including the decision to use a new address configuration protocol. In a production environment, a solution that is suitable for all IPv6 address assignment mechanisms would be needed.
アクセスネットワークアドレス検証ソリューションは、多くの人の中で1つのオプションにすぎません。ソリューションは、選択したリンクテクノロジーとネットワークアーキテクチャに大きく依存しているようです。たとえば、ポイントツーポイントリンクでのソースアドレスの検証は簡単で、一般的に何年もの間実装によってサポートされてきました。共有ネットワークの検証はより問題がありますが、管理境界（DSLなど）にわたるイーサネットテクノロジーの使用を考えると重要性が高まっています。いずれにせよ、プロトタイプのソリューションには、新しいアドレス構成プロトコルを使用する決定など、多くの制限があります。生産環境では、すべてのIPv6アドレスの割り当てメカニズムに適したソリューションが必要になります。
Several conclusions can be drawn from the experiment.
実験からいくつかの結論を引き出すことができます。
First, the experiment is a proof that a prototype can be built that is deployable on loosely-coupled domains of test networks in a limited scale and "multiple-fence" design for source address validation. The solution allows different validation granularities, and also allows different providers to use different solutions. The coupling of components at different levels of granularity can be loose enough to allow component substitution.
Incremental deployment is another design principle that was used in the experiment. The tests have demonstrated that benefit is derived even when deployment is incomplete, thus giving providers an incentive to be early adopters.
増分展開は、実験で使用された別の設計原則です。テストは、展開が不完全である場合でも利益が得られることを実証しているため、プロバイダーは早期採用者になるインセンティブを提供します。
The experiment also provided a proof of concept for the switch-based local subnet validation, network authentication based validation, filter-based Inter-AS validation, and authentication tag-based Inter-AS validation mechanisms. The client host and network equipment need to be modified and some new servers should be deployed.
この実験は、スイッチベースのローカルサブネット検証、ネットワーク認証ベースの検証、フィルターベースの検証、および認証タグベースの検証メカニズムの概念の証明も提供しました。クライアントホストとネットワーク機器を変更する必要があり、一部の新しいサーバーを展開する必要があります。
Nevertheless, as discussed in the previous section, there are a number of limitations, issues, and questions in the prototype designs and the overall source address validation space.
それにもかかわらず、前のセクションで説明したように、プロトタイプ設計とソースアドレスの検証スペース全体に、多くの制限、問題、質問があります。
It is our hope that some of the experiences will help vendors and the Internet standards community in these efforts. Future work in this space should attempt to answer some of the issues raised in Section 5. Some of the key issues going forward include:
これらの取り組みにおいて、いくつかの経験がベンダーとインターネット標準コミュニティを支援することが私たちの希望です。この分野での将来の作業は、セクション5で提起された問題のいくつかに答えようとする必要があります。今後の重要な問題のいくつかは次のとおりです。
o Scalability questions and per-packet operations.
o スケーラビリティの質問とパケットごとの操作。
o Protocol design issues, such as integration to existing address allocation mechanisms, use of hop-by-hop headers, etc.
o 既存のアドレス割り当てメカニズムへの統合、ホップバイホップヘッダーの使用など、プロトコル設計の問題。
o Cost vs. benefit questions. These may be ultimately answered only by actually employing some of these technologies in production networks.
o
o Trust establishment issue and study of false positives.
o 確立の問題と誤った肯定的な研究を信頼します。
o Deployability considerations, e.g. modifiability of switches, hosts, etc.
o 展開性の考慮事項、例えばスイッチ、ホストなどの修正可能性
The purpose of the document is to report experimental results. Some security considerations of the solution mechanisms of the testbed are mentioned in the document, but are not the main problem to be described in this document.
ドキュメントの目的は、実験結果を報告することです。テストベッドのソリューションメカニズムのいくつかのセキュリティ上の考慮事項は、ドキュメントに記載されていますが、このドキュメントで説明する主な問題ではありません。
This experiment was conducted among 12 universities -- namely, Tsinghua University, Beijing University, Beijing University of Post and Telecommunications, Shanghai Jiaotong University, Huazhong University of Science and Technology in Wuhan, Southeast University in Nanjing, South China University of Technology in Guangzhou, Northeast University in Shenyang, Xi'an Jiaotong University, Shandong University in Jinan, University of Electronic Science and Technology of China in Chengdu, and Chongqing University. The authors would like to thank everyone involved in this effort in these universities.
この実験は、12の大学の間で実施されました。つまり、北京大学、北京郵便通信大学、北京科学大学、南東科学技術、南東大学広東科学工科大学科学技術科学大学、郵便通信大学の12大学の中で実施されました。北東大学、Xi'an Jiaotong University、Jinanの山東大学、Chengduの中国電子科学技術大学、Chongqing University。著者は、これらの大学でこの取り組みに関与しているすべての人に感謝したいと思います。
The authors would like to thank Jari Arkko, Lixia Zhang, and Pekka Savola for their detailed review comments on this document, and thank Paul Ferguson and Ron Bonica for their valuable advice on the solution development and the testbed implementation.
著者は、この文書に関する詳細なレビューコメントをしてくれたJari Arkko、Lixia Zhang、およびPekka Savolaに感謝し、ソリューション開発とテストベッドの実装に関する貴重なアドバイスをしてくれたPaul FergusonとRon Bonicaに感謝します。
[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] Ferguson、P。およびD. Senie、「ネットワークイングレスフィルタリング：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] Baker、F。およびP. Savola、「マルチホームネットワークのイングレスフィルタリング」、BCP 84、RFC 3704、2004年3月。
[Brem05] Bremler-Barr, A. and H. Levy, "Spoofing Prevention Method", INFOCOM 2005.
[Brem05] Bremler-Barr、A。およびH. Levy、「Spoofing Prevention Method」、Infocom 2005。
[Li02] Li,, J., Mirkovic, J., Wang, M., Reiher, P., and L. Zhang, "SAVE: Source Address Validity Enforcement Protocol", INFOCOM 2002.
[Li02] Li ,, J.、Mirkovic、J.、Wang、M.、Reiher、P。、およびL. Zhang、「Save：Source Addressの妥当性執行プロトコル」、Infocom 2002。
[Park01] Park, K. and H. Lee, "On the effectiveness of route-based packet filtering for distributed DoS attack prevention in power-law internets", SIGCOMM 2001.
[Park01] Park、K。およびH. Lee、「パワーローのインターネットにおける分散DOS攻撃防止のためのルートベースのパケットフィルタリングの有効性に関する」、Sigcomm 2001。
[Snoe01] Snoeren, A., Partridge, C., Sanchez, L., and C. Jones, "A Hash-based IP traceback", SIGCOMM 2001.
[Snoe01] Snoeren、A.、Partridge、C.、Sanchez、L。、およびC. Jones、「ハッシュベースのIPトレースバック」、Sigcomm 2001。
[Wu07] Wu, J., Ren, G., and X. Li, "Source Address Validation: Architecture and Protocol Design", ICNP 2007.
[Wu07] Wu、J.、Ren、G。、およびX. Li、「ソースアドレスの検証：アーキテクチャとプロトコル設計」、ICNP 2007。
[XBW07] Xie, L., Bi, J., and J. Wu, "An Authentication based Source Address Spoofing Prevention Method Deployed in IPv6 Edge Network", ICCS 2007.
[XBW07] Xie、L.、Bi、J。、およびJ. Wu、「IPv6 Edgeネットワークに展開された認証ベースのソースアドレススプーフィング予防方法」、ICCS 2007。
Authors' Addresses
Jianping Wu Tsinghua University Computer Science, Tsinghua University Beijing 100084 China EMail: jianping@cernet.edu.cn
Jianping Wu Tsinghua University Computer Science、Tsinghua University Beijing 100084 China Email：jianping@cernet.edu.cn
Jun Bi Tsinghua University Network Research Center, Tsinghua University Beijing 100084 China EMail: junbi@cernet.edu.cn
Jun Bi Tsinghua University Network Research Center、Tsinghua University Beijing 100084 China Email：junbi@cernet.edu.cn
Xing Li Tsinghua University Electronic Engineering, Tsinghua University Beijing 100084 China EMail: xing@cernet.edu.cn
Xing Li Tsinghua University Electronic Engineering、Tsinghua University Beijing 100084 China Email：xing@cernet.edu.cn
Gang Ren Tsinghua University Computer Science, Tsinghua University Beijing 100084 China EMail: rg03@mails.tsinghua.edu.cn
ギャングレンチンフア大学コンピューターサイエンス、ツインフア大学北京100084中国メール：rg03@mails.tsinghua.edu.cn
Ke Xu Tsinghua University Computer Science, Tsinghua University Beijing 100084 China EMail: xuke@csnet1.cs.tsinghua.edu.cn
Ke Xu Tsinghua University Computer Science、Tsinghua University Beijing 100084 China Email：xuke@csnet1.cs.tsinghua.edu.cn
Mark I. Williams Juniper Networks Suite 1508, W3 Tower, Oriental Plaza, 1 East Chang'An Ave Dong Cheng District, Beijing 100738 China EMail: miw@juniper.net
マークI.ウィリアムズジュニパーネットワークスイート1508、W3タワー、オリエンタルプラザ、1 East Chang'an Ave Dong Cheng District、Beijing 100738 China：miw@juniper.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。