RFC5210 日本語訳
5210 A Source Address Validation Architecture (SAVA) Testbed andDeployment Experience. J. Wu, J. Bi, X. Li, G. Ren, K. Xu, M.Williams. June 2008. (Format: TXT=58363 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
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
コメントを求めるワーキンググループJ.ウー要求をネットワークでつないでください: 5210年のJ.の両性愛者のカテゴリ: Tsinghua大学M.ウィリアムズ杜松が2008年6月にネットワークでつなぐ実験的なX.李G.Ren K.シュー
A Source Address Validation Architecture (SAVA) Testbed
and Deployment Experience
ソースアドレス合法化アーキテクチャ(サーバ川)テストベッドと展開経験
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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
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.
受信者IPアドレスに応じてインターネットがパケットを進めるので、パケット推進はソースアドレスの点検なしで通常行われます、そして、悪意ある攻撃はソースアドレスであると偽造された進水する使用です。 IPソースアドレス合法化でインターネットを高める取り組みでは、IP Source Address Validation Architecture(サーバ川)のプロトタイプ実装は作成されました、そして、評価がIPv6ネットワークで行われました。 このドキュメントはプロトタイプ実装と試験の成績に関して報告します、実験から獲得されたレッスンと洞察と同様に。
Wu, et al. Experimental [Page 1] RFC 5210 SAVA Testbed June 2008
ウー、他 [1ページ]実験的なRFC5210サーバ川テストベッド2008年6月
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 プロトタイプサーバ川実装. . . . . . . . . . . . . . . 4 2.1。 ソリューション概要. . . . . . . . . . . . . . . . . . . . 4 2.2。 アクセスネットワーク. . . . 6 2.3におけるIPソースアドレス合法化。 IPがアドレス合法化の出典を明示する、イントラ、-、/イングレスポイント. . 9 2.4 中のIPソースアドレス合法化、相互、ケース(隣接している).92.5 中のIPソースアドレス合法化、相互、(非隣接する)の.123をケースに入れてください。 サーバ川テストベッド. . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1。 CNGI-CERNET2. . . . . . . . . . . . . . . . . . . . . . . 15 3.2。 CNGI-CERNET2インフラストラクチャ. . . . . . . 16 4のサーバ川テストベッド。 経験と結果. . . . . . . . . . . . . . . . . 17 4.1をテストしてください。 シナリオ. . . . . . . . . . . . . . . . . . . . . . 17 4.2をテストしてください。 結果. . . . . . . . . . . . . . . . . . . . . . . 18 5をテストしてください。 制限と問題. . . . . . . . . . . . . . . . . . . . 18 5.1。 一般答弁. . . . . . . . . . . . . . . . . . . . . . 18 5.2。 セキュリティは.205.3を発行します。 詳細. . . . . . . . . . . . . . . . . . . . . 20 6について議定書の中で述べてください。 結論. . . . . . . . . . . . . . . . . . . . . . . . . . 21 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 22 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 22 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 23 9.1。 引用規格. . . . . . . . . . . . . . . . . . . 23 9.2。 有益な参照. . . . . . . . . . . . . . . . . . 23
Wu, et al. Experimental [Page 2] RFC 5210 SAVA Testbed June 2008
ウー、他 [2ページ]実験的なRFC5210サーバ川テストベッド2008年6月
1. Introduction
1. 序論
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.
故意に、インターネットは唯一送付先IPアドレスに基づくデータ・パケットを進めます。 多くの場合、ソースIPアドレスは推進プロセスの間、チェックされません。 これで、悪意があるホストがIPパケットのソースアドレスを偽造するのが簡単になります。 私たちは、進められるすべてのパケットのためのソースIPアドレスの正当性を実施するのが役に立つと信じています。
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.
Source Address Validation Architecture(サーバ川)を開発することにおける取り組みの一部として、私たちはサーバ川プロトタイプを実装しました、そして、中国Next Generationインターネット(CNGI)の一部としての操作上のネットワークにおける12ASesのプロトタイプであると配布されて、[Wu07]を映し出してください。 私たちは評価実験を行いました。 本書では、私たちは、最初に、プロトタイプソリューションについて説明して、次に、実験結果を報告します。 このドキュメントが対象に興味を持っているものに役に立つ洞察を提供できて、初期の入力としてこの領域で将来の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.
近年、多くの研究とIPソースアドレス合法化メカニズムを設計するための技術的努力がありました、[RFC2827]や、[Park01]や、[Li02]や、[Brem05]や、[Snoe01]などのように。 私たちのサーバ川プロトタイプ実装は体系のいくつかによって提案されたか既存のソリューションから奮い立たせられました。
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で議論するように実験的なアプローチであり、多くの制限を持っています。
Wu, et al. Experimental [Page 3] RFC 5210 SAVA Testbed June 2008
ウー、他 [3ページ]実験的なRFC5210サーバ川テストベッド2008年6月
2. A Prototype SAVA Implementation
2. プロトタイプサーバ川実装
2.1. Solution Overview
2.1. ソリューション概要
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ソースアドレス合法化メカニズムも一般にサポートされると予想するのが非現実的であるということです。 異なったオペレータとベンダーは、異なった場所でネットワークで問題を解決するために同じ終わりに達成して、異なったメカニズムになるようにそこで必要とする異なったメカニズムを配布するか、または開発するのを選ぶかもしれません。 その上、実装バグか構成誤りが潜在的に実装を効力がなくするかもしれません。 したがって、私たちのプロトタイプサーバ川実装は複数の共存と協力メカニズムの組み合わせです。3つのレベルで、より明確に、私たちは、ソースIPアドレスが合法化であると実装します: ネットワークソースアドレス合法化にアクセスしてください。 イントラ-ASソースアドレス合法化。 そして、相互ASソースは図1に示されるように合法化を扱います。 [Wu07]でシステムの詳細を見つけることができます。
Wu, et al. Experimental [Page 4] RFC 5210 SAVA Testbed June 2008
ウー、他 [4ページ]実験的なRFC5210サーバ川テストベッド2008年6月
__ ____ __ ____
.-'' `': .-'' `':
| | | |
| +-+----+ | Inter-AS SAV | +-+----+ |
| |Router+--+------------------+---|Router+ +
| +--.---+ | | +--.---+ |
Intra-AS | | \ Intra-AS | | |
SAV | +--+---+ \ SAV | +--+---+ |
| |Router| \ | |Router| |
| +--.---+ \ '_ +-----+ _
| | \ `'-------'''
/ | \
/ | \
| +---------------------+\
----+---------. Router | \
| ++-------\------------+ \
| | | \ | | |
__ ____ __ ____ .-'' `': .-'' `': | | | | | +-+----+ | 相互、SAV| +-+----+ | | |ルータ+--+------------------+---|ルータ++| +--.---+ | | +--.---+ | イントラ、-| | \、イントラ、-| | | SAV| +--+---+ \SAV| +--+---+ | | |ルータ| \ | |ルータ| | | +--.---+ \ '_ +-----+ _ | | \ `'-------''' / | \ / | \ | +---------------------+\ ----+---------. ルータ| \ | ++-------\------------+ \ | | | \ | | |
| | +------+|+------++----+|Intra-AS
| | |Switch|||Switch||Host||SAV
| | +------+|+------++----+|イントラ、-| | |スイッチ|||スイッチ||ホスト||SAV
| | +------+|+------++----+|
| | +------+|+------++----+|
| | | | | \ |
| | | | | \ |
|+-+--++----+|+----++----+ |
|+-+--++----+|+----++----+ |
||Host||Host|||Host||Host| |
`+----++----+|+----++----+ /
||ホスト||ホスト|||ホスト||ホスト| | `+----++----+|+----++----+ /
`--. | _.-'
`------|------+''
Access |
Network |
SAV
`--. | _.-' `------|------「+」 アクセス| ネットワーク| SAV
Key: SAV - Source Address Validation
キー: SAV--ソースアドレス合法化
Figure 1: Solution Overview
図1: ソリューション概要
This document divides source address validation into three different classes of solutions:
このドキュメントはソースアドレス合法化を3つの異なったクラスのソリューションに分割します:
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. ネットワークにアクセスしてください。 これによって、ネットワークのホストは同じネットワークセグメントで別のホストのアドレスを偽造することができません。 Intra-AS防止と比べて、これは保護のホスト粒状を可能にします。 詳細に関してセクション2.2を見てください。
Wu, et al. Experimental [Page 5] RFC 5210 SAVA Testbed June 2008
ウー、他 [5ページ]実験的なRFC5210サーバ川テストベッド2008年6月
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. イントラ、- アクセスネットワークの縁のルータがソースアドレス合法化(例えば、[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. 相互 パケットソースを実施するメカニズムがAS境界における正当性を扱います。 世界的なインターネットにはメッシュトポロジーがあって、異なったネットワークが異なった職務権限に属すので、Inter-ASレベルにおけるIPソースアドレス合法化が、よりやりがいがあります。 それにもかかわらず、私たちは、この第3レベルの保護が偽造しているソースアドレスがあるパケットを検出するのに必要であると信じています、ソースアドレス合法化の最初の2つのレベルがなくなるか、または効力がないときに。
In the following sections, we describe the specific mechanisms implemented at each of the three levels in detail.
以下のセクションで、私たちはそれぞれの3つのレベルで詳細に実装された特定のメカニズムについて説明します。
2.2. IP Source Address Validation in the Access Network
2.2. アクセスネットワークにおけるIPソースアドレス合法化
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.
アクセスネットワークレベルでは、ソリューションは、アクセスネットワークにおけるホストが別のホストのソースアドレスを使用できないのを確実にします。 ホスト・アドレスは静的かダイナミックにホストに割り当てられた有効なアドレスであるべきです。 実験で実現されたソリューションはそのような機能をイーサネットネットワークに提供します。 アクセスネットワーク(デバイスはCustomer Premises Equipment(CPE)ルータか別々のデバイスの中の機能であるかもしれない)のための層-3ソースアドレス合法化アーキテクチャデバイス(サーバ川Device)はアクセスネットワークの出口で配布されます。 ソースアドレス合法化アーキテクチャエージェント(サーバ川のエージェント)はアクセスネットワークの中で配布されます。 (事実上、これらのエージェントはホストに接続された最初のホップルータ/スイッチの中の機能であるかもしれません。) 1セットのプロトコルはホストと、サーバ川のエージェントと、サーバ川Deviceとのコミュニケーションのために設計されました。 その特定のソースアドレスが割り当てられたホストから発するパケットだけがサーバ川のエージェントとサーバ川Deviceを通り抜けるかもしれません。
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.
2つの可能な展開異形が存在しています。 私たちは、それらをVariant AとVariant B.In Variant Aと呼ぶつもりです、そして、エージェントは義務的です、そして、各ホストは専用物理的なポートの上のエージェントに愛着しています。 Variant Bでは、ホストは、ネットワークアクセス認証を実行して、各パケットを保護するのに必要である主要な材料を生成しなければなりません。 この異形では、エージェントは任意です。
Wu, et al. Experimental [Page 6] RFC 5210 SAVA Testbed June 2008
ウー、他 [6ページ]実験的なRFC5210サーバ川テストベッド2008年6月
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.
Variant Aの主要な機能は、スイッチポートと有効なソースIPアドレスの間でダイナミックな結合を作成するか、またはメディアAccess Control(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:
Variant Aに、3人の主な関係者がいます: ホスト(スイッチの上のSource Address Validation Proxy(SAVP))とSource Address Management Server(サムズ)の上のAddress Request Client(SARC)の出典を明示してください。. 図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. 終わりのホストの上のSARCはIPアドレス要求を送ります。 スイッチの上のSAVPはサムズ、MACが扱う記録、および入って来るポートにこの要求をリレーします。 アドレスが終わりのホストによって既に予定されたなら、終わりのホストは、まだサムズによる検証への要求メッセージにそのアドレスを入れる必要があります。
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. 次に、サムズがIPアドレス要求を受け取った後にアドレス配分に基づくそのSARCのためのソースアドレスとアクセスネットワークの経営政策を割り当てて、それは、tracebackのためにサムズ歴史データベースにおける、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. アクセススイッチは終わりのホストから送られたパケットをフィルターにかけ始めます。 tuple(IPアドレス、Switch Port)に従わないパケットは捨てられます。
Wu, et al. Experimental [Page 7] RFC 5210 SAVA Testbed June 2008
ウー、他 [7ページ]実験的なRFC5210サーバ川テストベッド2008年6月
----------------
| SERVER |
| ------- |
| | SAMS | |
| -------- |
-----------------
|
|
----------------
| SWITCH |
| ------- |
| | SAVP | |
| -------- |
-----------------
|
|
----------------
| END HOST |
| ------- |
| | SARC | |
| -------- |
-----------------
---------------- | サーバ| | ------- | | | サムズ| | | -------- | ----------------- | | ---------------- | スイッチ| | ------- | | | SAVP| | | -------- | ----------------- | | ---------------- | 終わりのホスト| | ------- | | | SARC| | | -------- | -----------------
Key: SARC - Source Address Request Client
SAVP - Source Address Validation Proxy
SAMS - Source Address Management Sever
キー: SARC--ソースアドレス要求クライアントSAVP--ソースアドレス合法化プロキシサムズ--ソースアドレス管理は切れます。
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:
Variant 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. ネットワークアクセスデバイスはサーバ川のエージェント(しばしば共同見つけられている)にセッションキーS.を提供します。Thisキーはさらにサーバ川Deviceに分配されます。 サーバ川DeviceはセッションキーとホストのIPアドレスを縛ります。
Wu, et al. Experimental [Page 8] RFC 5210 SAVA Testbed June 2008
ウー、他 [8ページ]実験的なRFC5210サーバ川テストベッド2008年6月
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. ホストがアクセスネットワークの外では、ホストかサーバ川のエージェントのどちらかがそれぞれキーSとパケットM.Inを使用するためのメッセージ確認コードがプロトタイプであると生成する必要があるところにパケットMを送るとき、メッセージ確認コードは実験的なIPv6拡張ヘッダーで運ばれます。
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. サーバ川Deviceはソースアドレスを有効にすることができるようにパケットで運ばれた署名を認証するために主要なセッションを使用します。
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.
テストベッドでは、私たちは、両方のソリューションを実現して、テストしました。 スイッチベースのソリューションには、より良い性能がありますが、アクセスネットワークにおけるスイッチは、アップグレードする必要があるでしょう(通常、アクセスネットワークにおける、スイッチの数は大きいです)。 ホストと出口ルータの間で署名ベースのソリューションを配布することができましたが、それは署名を挿入して、有効にする際に何らかの追加費用を持っています。
2.3. IP Source Address Validation at Intra-AS/Ingress Point
2.3. IPがアドレス合法化の出典を明示する、イントラ、-、/イングレスポイント
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パケットのソースアドレス合法化のソリューションを採用しました。 後者がイングレスポイントでのソースアドレス合法化について説明する、マルチ、家へ帰り、ネットワークにアクセスしてください。
2.4. IP Source Address Validation in the Inter-AS Case (Neighboring AS)
2.4. 中の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 Source Address Validationのための私たちのデザインは以下の特性を含んでいました: それは異なったASesの中で異なった職務権限と異なった関心に協力するべきです。 それは高生産性をサポートして、推進効率に影響を及ぼさないほど軽量であるべきです。
The inter-AS level of SAVA can be classified into two sub-cases:
サーバ川の相互ASレベルを2つのサブケースに分類できます:
o Two SAVA-compliant ASes exchanging traffic are directly connected;
o トラフィックを交換する2サーバ川対応することのASesが直接接続されます。
o Two SAVA-compliant ASes are separated by one or more intervening,
non-SAVA-compliant providers.
o 2サーバ川対応することのASesが1時までに切り離されるか、または、より介入している、非サーバ川対応する、プロバイダー。
Wu, et al. Experimental [Page 9] RFC 5210 SAVA Testbed June 2008
ウー、他 [9ページ]実験的なRFC5210サーバ川テストベッド2008年6月
---------
| 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| |
| ----- | | ------ |
--------------- -------------
--------- | 目的| ------|- | -------------- -----------|----- | 4|-------- --------| 1| |------- グローバル| ------ |ASBR、VE|、-、>|ASBR、VE| ------|- |ASBR、VE|--->IPv6| |VRGE| |-------- --------| | VRGE| |------- ネットワーク| ------ | | -------- | --------------- ----- ----------------- |ASBR、VE| |ASBR、VE| --------- --------- / | / | / | / | ---------- -------- |ASBR、VE| |ASBR、VE| --------------- ------------- | 2| | 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--Engine VR--合法化Rule VRGE--合法化Rule Generating Engineを有効にするAS-IPv6接頭語Mapping Server ASBR(AS Border Router VE)
Figure 3: Inter-ISP (Neighboring AS) Solution
図3: 相互ISP(隣接している)ソリューション
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.
トラフィックを交換する2ASesが顧客からプロバイダー、プロバイダー兄弟からピアツーピア、または兄弟への顧客の関係を持っています。 プロバイダーから顧客からプロバイダーか顧客への関係では、顧客はインターネットの残りへのアクセスのために、より大きい管理ドメインを支払うより小さい管理ドメインに通常属します。 プロバイダーは、より大きい管理ドメインに属すASです。 ピアツーピア関係では、2人の同輩が、匹敵するサイズの管理ドメインに通常属して、彼らのそれぞれの顧客の間でトラフィックを交換するのが互いに有利であることがわかります。 2ASesには、彼らが同じ管理ドメイン、または、互いのトランジット協定を持っている管理ドメインに属するなら、兄弟から兄弟への関係があります。
Wu, et al. Experimental [Page 10] RFC 5210 SAVA Testbed June 2008
ウー、他 [10ページ]実験的なRFC5210サーバ川テストベッド2008年6月
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.
AS関係ベースのメカニズムは隣接しているサーバ川対応することのASesに使用されます。 このAS関係ベースのメカニズムの基本的な考え方は以下の通りです。 それは、1セットの有効なソースあて先ブロックにルータのそれぞれの入って来るインタフェースを関連づける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つの機能モジュールに切り離されます: Validation Rule Generating Engine(VRGE)、Validation Engine(VE)、およびAS-IPv6はMapping Server(AIMS)を前に置きます。 IPv6が接頭語を扱うとき、VRGEによって生成される合法化規則は表されます。
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 | ----------------------------------------------------------------------
VRGEは、合法化がTable1に従って引き出される規則であると生成します、そして、各ASには、VRGEがあります。 合法化規則がパケットをフィルターにかけるためにVRGEで生成したVE荷重はASes(AS-1への隣接しているASesからの図3の場合における)の間で終わりました。 サーバ川テストベッドでは、VEはシミュレートされた層-2デバイスとしてまさしく隣接しているASに面しているそれぞれのASBRインタフェースの外のデータ経路に挿入されたリナックスベースのマシンの上で実装されます。 本当の世界実装では、パケットフィルタリングがASBRにセットしたので、それはたぶん実装されるでしょう。 AS-IPv6接頭語マッピングサーバは、また、リナックスマシンの上で実装されて、IPv6接頭語とその接頭語のAS番号の間でマッピングを引き出します。 ---------------------------------------------------------------------- | \輸出| 自己| 顧客のもの| 兄弟のもの| プロバイダーのもの| 同輩のもの| |\に| アドレス| アドレス| アドレス| アドレス| アドレス| |-----\--------------------------------------------------------------| | プロバイダー| Y| Y| Y| | | |--------------------------------------------------------------------| | 顧客| Y| Y| Y| Y| Y| |--------------------------------------------------------------------| | 同輩| Y| Y| Y| | | |--------------------------------------------------------------------| | 兄弟| Y| Y| Y| Y| Y| ----------------------------------------------------------------------
Table 1: AS-Relation-Based Inter-AS Filtering
テーブル1: 関係ベース、相互、フィルタリング
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でASベースの関係Export Rulesを使用することでVR情報を交換して、伝えます。 Table1に従って、ASは、有効な接頭語としてアドレスがそれ自体の接頭語と、顧客と、プロバイダーと、兄弟と、その同輩であるとその顧客と兄弟にエクスポートします、有効な接頭語としてアドレスがそれ自体の接頭語と、顧客と、その兄弟であるとそのプロバイダーと同輩にエクスポートするだけですが。 AS-IPv6接頭語マッピングサーバのサポートで、有効なアドレス接頭語のAS番号だけをASesの間に移します、そして、VRGEで接頭語を扱うためにAS番号を写像します。
Wu, et al. Experimental [Page 11] RFC 5210 SAVA Testbed June 2008
ウー、他 [11ページ]実験的なRFC5210サーバ川テストベッド2008年6月
Only changes of AS relation and changes of IP address prefixes belonging to an AS require the generation of VR updates.
ASに属す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は関係を樹立しました。いつ、初期化されています、それは、隣接しているサーバ川対応することのASテーブルを読み込んで、それ自身のASのすべての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. VRGEはVR更新を開始します。 輸出テーブルに従って、それはそれ自身の溯源されたVRを隣接しているASesのVRGEsに送ります。 このプロセスでは、VRsはAS番号として急送されます。
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を受け入れるべきであるか否かに関係なく、それがそうするべきであるか否かに関係なく、他の隣接しているASesにVRを再輸出するように決めるのにそれ自身の輸出テーブルを使用します。
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を受け入れるなら、それは、IPv6への言い表されたVRが接頭語で急送したAS VRを変えるのにAIMSを使用します。
5. The VRGE pushes the VR to all the VEs in its AS.
5. VRGEはASのすべてのVEsにVRを押します。
The VEs use these prefix-based VRs to validate the source IP addresses of incoming packets.
VEsは、入って来るパケットのソースIPアドレスを有効にするのにこれらの接頭語ベースのVRsを使用します。
2.5. IP Source Address Validation in the Inter-AS Case
(Non-Neighboring AS)
2.5. 中のIPソースアドレス合法化、相互、ケース(非隣接する)です。
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].
2ASesが直接パケットを交換しない場合では、前項で説明されたそのようなソリューションを配布するのは可能ではありません。 しかしながら、非隣接しているISPが1ASを残すパケットがもう片方によって認識されるように信頼同盟を形成して、最初のASを残すとき彼らが持っていた合法化状態を引き継ぐことができるのは、非常に望ましいです。 これをする1つ以上の方法があります。 日付を入れるサーバ川の実験のために、認証タグメソッドは使用されました。 このソリューションは[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
この軽量の認証タグベースのメカニズムの主要な原理は以下の通りです: 各組のサーバ川対応することのASesのために、1組のユニークな一時的な認証タグがあります。 一緒にすべてのサーバ川対応することのASesがサーバ川AS Allianceを形成します。 パケットがそれ自身のASを残しているとき、送付先IPアドレスがサーバ川AS AllianceでASに属すなら、このASの縁のルータは、キーとして目的地AS番号を使用することで認証タグを見上げて、認証タグをパケットに加えます。 パケットが到着する時
Wu, et al. Experimental [Page 12] RFC 5210 SAVA Testbed June 2008
ウー、他 [12ページ]実験的なRFC5210サーバ川テストベッド2008年6月
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.
目的地AS、パケットのソースアドレスがサーバ川AS AllianceでASに属すなら、目的地ASの縁のルータが認証タグのためにキーとしてソースAS番号を使用することでテーブルを捜して、パケットで運ばれた認証タグについて、確かめて、取り除きます。 名前によって示されるように、この特定のメソッドは軽量の認証タグを使用します。 進められたあらゆるパケットに関しては、ホップごとの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.
単に、ローカルアドレス合法化(RFC2827などの)をつけると比較されたこの体系の利益は以下の通りです: ローカルアドレス合法化がネットワークのグループの中で使われるとき、それらのネットワークが偽造しているパケットを送らないことが保証されます。 しかし、他のネットワークはまだこれをしているかもしれません。 しかしながら、上の体系で、この能力は根絶されます。 同盟の外におけるだれかが同盟の中でだれかからのソースアドレスを使用することでパケットを偽造するなら、同盟のメンバーは、そのようなパケットを受け入れるのを拒否します。
+-----+
.-----------------+ REG |-----------------.
| +-----+ |
| |
,-----+-------- ,------+-------
,' `| `. ,' ` | `.
/ | \ / | \
/ | \ / | \
; +--'--+ +----+ +----+ +-----+ ;
| | ASC +------+ASBR| |ASBR+-----+ ASC | |
: +--.--+ +----+` +----+ +--+--+ :
\ |__________________________________________| /
\ / \ /
`. ,' `. ,'
'-------------' '-------------'
AS-1 AS-2
+-----+ .-----------------+ レッジ|-----------------. | +-----+ | | | ,-----+-------- ,------+------- ,' `| `. ,' ` | `. / | \ / | \ / | \ / | \ ; +--'--+ +----+ +----+ +-----+ ; | | ASC+------+ ASBR| |ASBR+-----+ ASC| | : +--.--+ +----+` +----+ +--+--+ : \ |__________________________________________| / \ / \ / `. ,' `. ,' '-------------' '-------------'、1、2、'
Key: REG - Registration Server
ASC - AS Control Server
ASBR - AS Border Router
キー: REG--コントロールサーバASBR、境界ルータとした登録サーバASC
Figure 4: Inter-AS (Non-Neighboring AS) Solution
図4: 相互、(非隣接する)のソリューション
There are three major components in the system: the Registration Server (REG), the AS Control Server (ASC), and the AS Border Router (ASBR).
システムには3個の主要コンポーネントがあります: そして、登録サーバ(REG)、制御サーバ(ASC)として境界ルータ(ASBR)として。
Wu, et al. Experimental [Page 13] RFC 5210 SAVA Testbed June 2008
ウー、他 [13ページ]実験的なRFC5210サーバ川テストベッド2008年6月
The Registration Server is the "center" of the trust alliance (TA). It maintains a member list for the TA. It performs two major functions:
Registration Serverは信頼同盟(TA)の「センター」です。 それはTAのためのメンバーリストを維持します。 それは2つの主要な機能を実行します:
o Processes requests from the AS Control Server, to get the member
list for the TA.
o TAのためのメンバーリストを得るためにAS Control Serverから要求を処理します。
o Notifies each AS Control Server when the member list is changed.
o メンバーリストを変えるとき、各AS Control Serverに通知します。
Each AS deploying the method has an AS Control Server. The AS Control Server has three major functions:
メソッドを配布する各ASがAS Control Serverを持っています。AS Control Serverには、3つの主要な機能があります:
o Communicates with the Registration Server, to get the up-to-date
member list of TA.
o TAの最新のメンバーリストを得るためにRegistration Serverとコミュニケートします。
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の他のメンバーASesでAS Control Serverとコミュニケートします。
o Communicates with all AS Border Routers of the local AS, to
configure the processing component on the AS Border Routers.
o AS Border Routersで処理コンポーネントを構成するために地方のASのすべてのAS Border Routersとコミュニケートします。
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.
AS Border Routerは発信しているASでの認証タグをパケットに加える仕事、および目的地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で負担を減少させるために、コントロールトラフィックの大部分はASCsの間で起こります。
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)よりむしろ1ASの観点からの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
認証タグがホップごとのIPv6拡張ヘッダーに入れられるので、MTU問題は考えられるべきです。 現在の、私たちはこの問題に2つのソリューションを持っています。 しかし、ソリューションのどちらも完全ではありません。
Wu, et al. Experimental [Page 14] RFC 5210 SAVA Testbed June 2008
ウー、他 [14ページ]実験的なRFC5210サーバ川テストベッド2008年6月
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.
それらはともに可能です。 1つの可能な方法はASBRのMTUに1280バイトであるように設定することです。(バイトはIPv6のための最小のMTUです)。 その結果、ICMPが全くあるはずがない、「パケット、大き過ぎる、」 メッセージは川下のゲートウェイから受信されました。 このソリューションの不都合は有効に利用可能なMTUを利用しないということです。 もう片方の可能な道が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.
認証タグがあて先ホストではなく、目的地ASの境界ルータで有効にされるので、目的地オプションヘッダーは認証タグを運ぶために選ばれていません。
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ポイントに焦点を合わせました: タグ交渉とタグはリフレッシュします。 タグ交渉はサーバ川AS Allianceの1組のASesのASCsの間で起こります。 同期の問題とサーバ川を可能にする誘因を考える場合、受信機駆動のタグ交渉は示されます。 それは送付者ASよりむしろ受信機ASにさらに多くの決定権限を与えます。 受信機駆動の体系で、受信機ASはタグ管理の方針を決めることができます。 古い認証タグでタグ付けをされたパケットを無期限に許容するべきではありません。 むしろ、期間の後に新しいタグを交渉した後に、古いタグが無効であるように設定されるべきです。 この期間の長さは有効であることを割り当てられた後に古いタグがどれくらい長い間なるか制御するパラメタです。 実験では、私たちは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.
信頼同盟によってダイナミックに設立されることを意図しましたが(接合してください、そして、やめてください)、このテストベッドでは、私たちは、同盟の一員の中で初期の信頼をオフラインで確認する必要がありました。
3. SAVA Testbed
3. サーバ川テストベッド
3.1. CNGI-CERNET2
3.1. CNGI-CERNET2
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.
サーバ川への私たちのソリューションのプロトタイプは、CNGI-CERNET2で実装されて、テストされます。 CNGI-CERNET2は中国EducationとResearch Network(CERNET)によって操作された中国Next Generationインターネット(CNGI)バックボーンの1つです。 CNGI-CERNET2は中国の20の都市で2.5-10 Gb/sの速度で配布された25のコアノードを接続します。 CNGI-CERNET2バックボーンは複雑なIPv4/IPv6インフラストラクチャであるよりむしろIPv6だけネットワークです。 いくつかだけのCustomer Premises Networks(CPNs)が二元的に積み重ねられます。 CNGI-CERNET2バックボーン、CNGI-CERNET2 CPNs、およびCNGI-6IXには、グローバルにユニークなAS番号がすべてあります。 したがって、マルチASテストベッド環境を提供します。
Wu, et al. Experimental [Page 15] RFC 5210 SAVA Testbed June 2008
ウー、他 [15ページ]実験的なRFC5210サーバ川テストベッド2008年6月
3.2. SAVA Testbed on CNGI-CERNET2 Infrastructure
3.2. CNGI-CERNET2インフラストラクチャのサーバ川テストベッド
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 | | | |
\ +---------+.' \ .'
\ ,' \ |
`. ,' \ /
``---' -_,'
結局サーバ川テストベッドが直接CNGI-CERNET2バックボーンで実装されることを意図しますが、初期段階に、テストベッドはCNGI-CERNET2に接続された12の大学の向こう側に実装されました。 まず最初にこれがアルゴリズムのいくつかが、テストベッドルータ自体で実装される必要があるからであるこれまで、それらは、CNGI-CERNET2バックボーンを形成しながら、商業ルータのいずれでも実装されていません。 2番目に、どんな新しいプロトコルとネットワークのテクニックも、CNGI-CERNET2が操作上のバックボーンであるので、非破壊的な方法でテストされる必要があります。 __ ,' \ _,...._ ,' \____---------------'北京'+、/、\| 相互、SAV|-----| Univ| +---------------+ | | +---------------+ `-._____,' | 相互、SAV+-----| | +------.--------+ | CNGI| _,...._ | | CERNET2|__---------------'+、東北'。| | | |相互、SAV|-----| Univ| Tsinghua|大学| バックボーン| +---------------+ `-._____,' ,,-|-._ | | ,' | `. | | ,'+---------+\ | | | |イントラ、-| | | | ... | | SAV| | | | | +---------+ | | | | | | | | _,...._ | +---------+ | | |__---------------'+、重慶'。| | アクセス| | | | |相互、SAV|-----|Univ| | | ネットワーク| | | | +---------------+ `-._____,' | | SAV| | | | \ +---------+.' \ .' \ ,' \ | `. ,' \ / ``---' -_,'
Key: SAV - Source Address Validation
キー: SAV--ソースアドレス合法化
Figure 5: CNGI-CERNET2 SAVA Testbed
図5: CNGI-CERNET2サーバ川テストベッド
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
どのような場合でも、テストベッドはソリューションについてサーバ川のすべての地域において完全にテストできます機能的な。 これは、アクセスネットワークにおける、IPv6ソースアドレスの正当性を確実にするのがないかどうか手順をテストするのを含んでいます、アクセスネットワークからIPv6サービスプロバイダーに送られたパケットで、あるサービスプロバイダーのネットワークの中で送られたパケットで、コネ
Wu, et al. Experimental [Page 16] RFC 5210 SAVA Testbed June 2008
ウー、他 [16ページ]実験的なRFC5210サーバ川テストベッド2008年6月
packets sent between neighboring service providers, and in packets sent between service providers separated by an intervening transit network.
パケットは隣接しているサービスプロバイダーの間と、そして、介入しているトランジットネットワークによって切り離されたサービスプロバイダーの間に送られたパケットで発信しました。
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.
それぞれの大学施設はテスト結果ディスプレイのために1セットの相互AS Source Address Validationプロトタイプ設備とトラフィックモニタリング設備を通して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.
各大学は1ASを配布しました。 6つの大学は、ソリューションのすべての部品を配布して、あります、したがって、相互AS、イントラ-AS、およびアクセスにおける合法化で完全に特集されたネットワークはテストできる状態ですべてを平らにします。 さらに、スプーフィング攻撃を受けることがあるかもしれないか、またはスプーフィング攻撃を行うために打倒できるひとそろいのアプリケーションはさまざまなサーバにインストールされました。 アクセスネットワークのための2つのソリューションが配布されました。
4. Test Experience and Results
4. テスト経験と結果
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で説明されたテストベッドの上で実現されました。 すべてのソリューションのうまくいっているテストはそうでした。以下のセクションで詳しく述べられるように、行われます。
4.1. Test Scenarios
4.1. テストシナリオ
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)にサーバ川のソリューションテストをみなして、私たちはテストケースを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つのケースがあります: 有効なソースアドレスで認証タグTest、Removing認証タグTest、およびForwardingパケットを加えます。
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. ダイナミックなクラスのために、4つのケースがあります: ASesの間の認証タグ、新たに接合されたメンバーAS、Addingアドレス空間、およびDeletingアドレス空間のための保護をアップデートします。
3. For anti-spoofing class, there is one case: Filtering of packets
with forged IP addresses.
3. 反スプーフィングのクラスのために、1つのケースがあります: 偽造IPアドレスがあるパケットのフィルタリング。
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
そのままで、私たちには、図5に示されて、私たちのサーバ川テストベッドへの「複数のフェンス」デザインがあります。 ソースアドレス合法化がアクセスネットワークで配布されるなら、私たちはホスト粒状合法化を得ることができます。 アドレスの出典を明示してくださいなら
Wu, et al. Experimental [Page 17] RFC 5210 SAVA Testbed June 2008
ウー、他 [17ページ]実験的なRFC5210サーバ川テストベッド2008年6月
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.
合法化はイントラ-ASレベルで配布されて、私たちは、このポイントから送られたパケットが正しいIP接頭語を持っているのを保証できます。 ソースアドレス合法化が相互ASレベルで配布されるなら、私たちは、このポイントから送られたパケットが正しいASから来ているのを保証できます。
4.2. Test Results
4.2. 試験の成績
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. 試験の成績は予想されたものと一致しています。 相互AS、イントラ-AS、およびアクセスネットワークレベルにおける合法化による完全に特集されたサーバ川の展開を持っているASに関しては、認証されたソースアドレスを保持しないパケットがネットワークで進められないでしょう。 その結果、偽造しているソースアドレスでネットワーク攻撃に着手するのは可能ではありません。 そのうえ、正確にネットワークにおけるトラフィックをたどって戻すことができます。
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)サーバ川ソリューションのために、ソースアドレス合法化には、認証タグアップデートの期間、古いタグと新しい認証タグはともに有効です。 したがって、パケット損失が全くありません。
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. Inter-AS(非隣接しているAS)サーバ川ソリューションにおいて、合法化機能はデバイス実行リナックスでソフトウェアで実装されます。(それは、ルータインタフェースのソースアドレス合法化機能をシミュレートします)。 ルータインタフェースに透明であることが必要であるので、それは層-2デバイスです。 デバイスが直接接続されたときのテストの間、通常のライン料率推進は達成されました。 デバイスが別のベンダーからルータに接続されたとき、非常に限られた推進速度だけが達成されました。 理由は認証タグがホップごとのIPv6オプションヘッダーの上に加えられるということです、そして、多くの現在のルータが単に限られた速度でホップごとのオプションを扱うことができます。
5. Limitations and Issues
5. 制限と問題
There are several issues both within this overall problem area and with the particular approach taken in the experiment.
特定のアプローチにはこの全体的な問題領域以内と実験で取るいくつかの問題があります。
5.1. General Issues
5.1. 一般答弁
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
ソースアドレス合法化の普遍的な展開の不足が技術的解決法を必要とする専門的な問題であるかどうかかそれとも既存のツール(RFC2827などの)のさらなる単なる展開が状況を改善するより費用効率がよい方法であるだろうかどうかの長年の討論があります。 このツールの取り組みが遅いと立証したさらなる展開、しかしながら. この実験でprototypedされたソリューションのいくつかで、ネットワーク・オペレータのグループは普遍的な展開を待っている間、彼らのネットワークのための追加保護を持つことができます。
Wu, et al. Experimental [Page 18] RFC 5210 SAVA Testbed June 2008
ウー、他 [18ページ]実験的なRFC5210サーバ川テストベッド2008年6月
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.
インターネットの残りにおける、より簡単なツールについて。 これで、彼らは、簡単なツールだけが防ぐことができないだろう攻撃を偽造するのを防ぐことができます、グループの中で既に配布されても。
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.
同様に、より良いソースアドレス確認技法の同等の普遍的な展開は、botnetクライアントのものである正統の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.
また、アドレス合法化のための新技術は多くの展開バリアに面しているでしょう。 例えば、局所的に独自にすべての現在の技術を適用できます。 グローバルなオペレーション(Inter-AS合法化メカニズムなどの)を必要とするシステムは重要なコーディネート、展開同期、構成、主要なセットアップ、および他の問題を必要とするでしょう、ASesの数を考えて。
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.
また、多大な費用がこれらのソリューションのいくつかにかかわったなら、あるかもしれません。 例えば、認証を使って、通常、アクセスネットワーク認証は必要でない環境で、ベースのアクセスネットワーク・アドレス合法化がすべてのデバイスのための資格証明書分配と同様にこの認証ができる設備の展開を必要とするでしょう。 そのような仕事はかかわったコストと利益の慎重な評価の後に通常開始されるだけです。
Wu, et al. Experimental [Page 19] RFC 5210 SAVA Testbed June 2008
ウー、他 [19ページ]実験的なRFC5210サーバ川テストベッド2008年6月
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.
最終的に、すべての提示されたソリューションには、同じ単一のインタフェースを通していつもホスト接続の単純モデルをネットワークに越える状況における問題があります。 移動性かワイヤレスソリューションのマルチホーミング、フェイルオーバー、およびいくつかのフォームがソースアドレス合法化の要件と衝突するかもしれません。 一般に、ホストの付属とルーティングインフラストラクチャのトポロジーへのダイナミックな変化は実稼動環境で扱われなければならない何かです。
5.2. Security Issues
5.2. 安全保障問題
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(非隣接しているAS)サーバ川ソリューションにおける認証タグのスケーラビリティは難しい見返りを提示します。 [Brem05]で2人のASメンバーの間の認証タグを推測するという困難に関する何らかの分析について議論しました。 それは「認証タグ」として乱数を使用さえしても比較的難しいです。 認証タグの長さを増強することによって、推測するという困難を増強できます。
In any case, the random number approach is definitely vulnerable to attackers who are on the path between the two ASes.
どのような場合でも、2ASesの間の経路にいる攻撃者には、乱数アプローチは確実に被害を受け易いです。
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.
他方では、パケットで実際の暗号のハッシュを使用すると、パケットを進めるのに必要である取り組みの量のかなりの増加は引き起こされるでしょう。 一般に、オプションの追加と認証タグの計算は推進経路に関する貴重なリソースを消費します。 このリソース用法は現代のルータがライン・スピードを増強するようにする必要がある他の何もかも上で来ます。 コストは利益の価値があるのが、全く明確ではありません。
5.3. Protocol Details
5.3. プロトコルの詳細
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,
Inter-AS(隣接しているAS)サーバ川ソリューションはAS関係に基づいています。 したがって、それほど急速にルート変化の力学に連動しないかもしれません、そして、無病誤診を引き起こすかもしれません。 現在
Wu, et al. Experimental [Page 20] RFC 5210 SAVA Testbed June 2008
ウー、他 [20ページ]実験的なRFC5210サーバ川テストベッド2008年6月
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.
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などの)の向こう側のイーサネット技術の使用を考えて、重要性を増しています。 どのような場合でも、prototyped解決策には、多くの制限があります、新しいアドレス構成プロトコルを使用するという決定を含んでいて。 実稼動環境では、すべてのIPv6アドレス割当機構に適した解決策が必要でしょう。
6. Conclusion
6. 結論
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.
また、実験はスイッチベースの地方のサブネット合法化に概念の証拠を提供して、ネットワーク認証は合法化、フィルタベースのInter-AS合法化、および認証のタグベースのInter-AS合法化メカニズムを基礎づけました。クライアントホストとネットワーク装置は、変更される必要があります、そして、いくつかの新しいサーバが配備されるべきです。
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.
それにもかかわらず、前項で議論するように、多くの制限、問題、および質問が原型デザインと総合的なソースアドレス合法化スペースにあります。
Wu, et al. Experimental [Page 21] RFC 5210 SAVA Testbed June 2008
ウー、他 [21ページ]実験的なRFC5210サーバ川テストベッド2008年6月
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 スケーラビリティ質問と1パケットあたりの操作。
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 Deployability問題、例えば、スイッチ、ホストなどの修正可能性
7. Security Considerations
7. セキュリティ問題
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.
ドキュメントの目的は実験結果を報告することです。 テストベッドの解決策メカニズムのいくつかのセキュリティ問題は、ドキュメントで言及されますが、本書では説明されるべき主な問題ではありません。
8. Acknowledgements
8. 承認
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の大学の中で行われました--すなわち、南京、広州のTechnologyの南部中国大学、瀋陽、西安Jiaotong大学における東北大学、済南の山東大学、中国のElectronic ScienceとTechnologyの大学における成都、および重慶大学におけるTsinghua大学と北京大学とポスト北京大学とTelecommunicationsと上海Jiaotong大学とScienceのHuazhong大学と武漢、東南大学におけるTechnology。 作者はこれらの大学でこの努力にかかわる皆に感謝したがっています。
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.
このドキュメントの上に彼らの詳細なレビューコメントについてヤリArkko、Lixiaチャン、およびペッカSavolaに感謝します、そして、作者は解決策開発とテストベッド実現のときに彼らの有益な助言についてポールファーガソンとロンBonicaに感謝したがっています。
Wu, et al. Experimental [Page 22] RFC 5210 SAVA Testbed June 2008
ウー、他 [22ページ]実験的なRFC5210サーバ川テストベッド2008年6月
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827] ファーガソン、P.、およびD.Senieは「以下をフィルターにかけるイングレスをネットワークでつなぎます」。 「IP Source Address Spoofingを使うサービス妨害Attacksを破ります」、BCP38、RFC2827、2000年5月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F.とP.Savola、「Multihomedのためにネットワークをフィルターにかけるイングレス」BCP84、2004年3月のRFC3704。
9.2. Informative References
9.2. 有益な参照
[Brem05] Bremler-Barr, A. and H. Levy, "Spoofing Prevention
Method", INFOCOM 2005.
[Brem05]Bremler-バール、A.、およびH.は「防止方法をだます」INFOCOM2005を徴収します。
[Li02] Li,, J., Mirkovic, J., Wang, M., Reiher, P., and L.
Zhang, "SAVE: Source Address Validity Enforcement
Protocol", INFOCOM 2002.
[Li02]李、J.、Mirkovic、J.、ワング、M.、Reiher、P.、およびL.チャンは「以下を救います」。 「ソースアドレス正当性実施プロトコル」、INFOCOM2002。
[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] 公園、K.、およびH.リーは「分配されたDoSのためのルートベースのパケットフィルタリングの有効性で指数法則インターネットにおける防止を攻撃します」、SIGCOMM2001。
[Snoe01] Snoeren, A., Partridge, C., Sanchez, L., and C. Jones, "A
Hash-based IP traceback", SIGCOMM 2001.
[Snoe01]Snoeren、A.、Partridge、C.、サンチェス、L.、およびC・ジョーンズ、「HashベースのIP traceback」SIGCOMM2001。
[Wu07] Wu, J., Ren, G., and X. Li, "Source Address Validation:
Architecture and Protocol Design", ICNP 2007.
[Wu07] ウー、J.、Ren、G.、およびX.李、「ソースは合法化を記述します」。 「構造とプロトコルデザイン」、ICNP2007
[XBW07] Xie, L., Bi, J., and J. Wu, "An Authentication based
Source Address Spoofing Prevention Method Deployed in IPv6
Edge Network", ICCS 2007.
[XBW07]シェ(L.とBi、J.とJ.ウー、「IPv6 Edge NetworkのAuthenticationのベースのSource Address Spoofing Prevention Method Deployed」ICCS2007)。
Wu, et al. Experimental [Page 23] RFC 5210 SAVA Testbed June 2008
ウー、他 [23ページ]実験的なRFC5210サーバ川テストベッド2008年6月
Authors' Addresses
作者のアドレス
Jianping Wu Tsinghua University Computer Science, Tsinghua University Beijing 100084 China EMail: jianping@cernet.edu.cn
ウーTsinghua大学コンピュータサイエンスをJianpingするTsinghua大学北京100084中国メール: jianping@cernet.edu.cn
Jun Bi Tsinghua University Network Research Center, Tsinghua University Beijing 100084 China EMail: junbi@cernet.edu.cn
6月の両性愛者のTsinghua大学ネットワークリサーチセンター、Tsinghua大学北京100084中国メール: junbi@cernet.edu.cn
Xing Li Tsinghua University Electronic Engineering, Tsinghua University Beijing 100084 China EMail: xing@cernet.edu.cn
Xing李Tsinghua大学Electronic Engineering、Tsinghua大学北京100084中国メール: xing@cernet.edu.cn
Gang Ren Tsinghua University Computer Science, Tsinghua University Beijing 100084 China EMail: rg03@mails.tsinghua.edu.cn
Ren Tsinghua大学コンピュータサイエンス、Tsinghua大学北京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シューTsinghua大学コンピュータサイエンス、Tsinghua大学北京100084中国メール: 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つの東Chang'An Aveドングチェン地区、北京100738中国メール: miw@juniper.net
Wu, et al. Experimental [Page 24] RFC 5210 SAVA Testbed June 2008
ウー、他 [24ページ]実験的なRFC5210サーバ川テストベッド2008年6月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Wu, et al. Experimental [Page 25]
ウー、他 実験的[25ページ]
一覧
スポンサーリンク
