[要約] RFC 3964は、6to4プロトコルのセキュリティに関する考慮事項をまとめたものです。その目的は、6to4ネットワークのセキュリティ上のリスクを理解し、適切な対策を講じるためのガイドラインを提供することです。
Network Working Group P. Savola
Request for Comments: 3964 CSC/FUNET
Category: Informational C. Patel
All Play, No Work
December 2004
Security Considerations for 6to4
6to4 のセキュリティに関する考慮事項
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネット コミュニティに情報を提供します。いかなる種類のインターネット標準も指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権 (C) インターネット協会 (2004)。
Abstract
概要
The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The architecture includes 6to4 routers and 6to4 relay routers, which accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from any node in the IPv4 internet. This characteristic enables a number of security threats, mainly Denial of Service. It also makes it easier for nodes to spoof IPv6 addresses. This document discusses these issues in more detail and suggests enhancements to alleviate the problems.
IPv6 暫定メカニズム 6to4 (RFC3056) は、自動 IPv6-over-IPv4 トンネリングを使用して IPv6 ネットワークを相互接続します。このアーキテクチャには、IPv4 インターネット内の任意のノードからの IPv4 プロトコル 41 (「IPv6-in-IPv4」) トラフィックを受け入れてカプセル化解除する 6to4 ルーターと 6to4 リレー ルーターが含まれています。この特性により、主にサービス妨害など、多くのセキュリティ上の脅威が可能になります。また、ノードが IPv6 アドレスを偽装することも容易になります。このドキュメントでは、これらの問題についてさらに詳しく説明し、問題を軽減するための機能強化を提案します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Different 6to4 Forwarding Scenarios . . . . . . . . . . . . . 4
2.1. From 6to4 to 6to4 . . . . . . . . . . . . . . . . . . . 4
2.2. From Native to 6to4 . . . . . . . . . . . . . . . . . . 5
2.3. From 6to4 to Native . . . . . . . . . . . . . . . . . . 5
2.4. Other Models . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1. BGP between 6to4 Routers and Relays . . . . . . 6
2.4.2. 6to4 as an Optimization Method . . . . . . . . . 7
2.4.3. 6to4 as Tunnel End-Point Addressing Mechanism . . 8
3. Functionalities of 6to4 Network Components . . . . . . . . . . 9
3.1. 6to4 Routers . . . . . . . . . . . . . . . . . . . . . . 9
3.2. 6to4 Relay Routers . . . . . . . . . . . . . . . . . . . 10
4. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Attacks on 6to4 Networks . . . . . . . . . . . . . . . . 12
4.1.1. Attacks with ND Messages . . . . . . . . . . . . 13
4.1.2. Spoofing Traffic to 6to4 Nodes . . . . . . . . . 14
4.1.3. Reflecting Traffic to 6to4 Nodes . . . . . . . . 17
4.1.4. Local IPv4 Broadcast Attack . . . . . . . . . . 19
4.2. Attacks on Native IPv6 Internet . . . . . . . . . . . . 20
4.2.1. Attacks with ND Messages . . . . . . . . . . . . 21
4.2.2. Spoofing Traffic to Native IPv6 Nodes. . . . . . 21
4.2.3. Reflecting Traffic to Native IPv6 Nodes . . . . 23
4.2.4. Local IPv4 Broadcast Attack . . . . . . . . . . 24
4.2.5. Theft of Service . . . . . . . . . . . . . . . . 25
4.2.6. Relay Operators Seen as Source of Abuse . . . . 26
4.3. Attacks on IPv4 Internet . . . . . . . . . . . . . . . . 28
4.4. Summary of the Attacks . . . . . . . . . . . . . . . . . 28
5. Implementing Proper Security Checks in 6to4 . . . . . . . . . 30
5.1. Encapsulating IPv6 into IPv4 . . . . . . . . . . . . . . 31
5.2. Decapsulating IPv4 into IPv6 . . . . . . . . . . . . . . 31
5.3. IPv4 and IPv6 Sanity Checks . . . . . . . . . . . . . . 32
5.3.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . 32
5.3.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . 33
5.3.3. Optional Ingress Filtering . . . . . . . . . . . 33
5.3.4. Notes about the Checks . . . . . . . . . . . . . 33
6. Issues in 6to4 Implementation and Use . . . . . . . . . . . . 34
6.1. Implementation Considerations with Automatic Tunnels . . 34
6.2. A Different Model for 6to4 Deployment . . . . . . . . . 35
7. Security Considerations . . . . . . . . . . . . . . . . . . . 36
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A. Some Trivial Attack Scenarios Outlined . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 41
The IPv6 interim mechanism "6to4" [1] specifies automatic IPv6-over-IPv4 tunneling to interconnect isolated IPv6 clouds by embedding the tunnel IPv4 address in the IPv6 6to4 prefix.
IPv6 暫定メカニズム「6to4」[1] は、トンネル IPv4 アドレスを IPv6 6to4 プレフィックスに埋め込むことで、分離された IPv6 クラウドを相互接続する自動 IPv6-over-IPv4 トンネリングを指定します。
Two characteristics of the 6to4 mechanism introduce most of the security considerations:
6to4 メカニズムの 2 つの特性により、セキュリティに関する考慮事項のほとんどが考慮されます。
1. All 6to4 routers must accept and decapsulate IPv4 packets from every other 6to4 router, and from 6to4 relays.
1. すべての 6to4 ルーターは、他のすべての 6to4 ルーターおよび 6to4 リレーからの IPv4 パケットを受け入れ、カプセル化を解除する必要があります。
2. 6to4 relay routers must accept traffic from any native IPv6 node.
2. 6to4 リレー ルーターは、ネイティブ IPv6 ノードからのトラフィックを受け入れる必要があります。
As the 6to4 router must accept traffic from any other 6to4 router or relay, a certain requirement for trust is implied, and there are no strict constraints on what the IPv6 packet may contain. Thus, addresses within the IPv4 and IPv6 headers may be spoofed, and this leads to various types of threats, including different flavors of Denial of Service attacks.
6to4 ルーターは他の 6to4 ルーターまたはリレーからのトラフィックを受け入れる必要があるため、信頼に対する特定の要件が暗黙に示されており、IPv6 パケットに含まれる内容については厳密な制限はありません。したがって、IPv4 および IPv6 ヘッダー内のアドレスがスプーフィングされる可能性があり、これがさまざまな種類のサービス拒否攻撃を含むさまざまな種類の脅威につながります。
The 6to4 specification outlined a few security considerations and rules but was ambiguous as to their exact requirement level. Moreover, the description of the considerations was rather short, and some of them have proven difficult to understand or impossible to implement.
6to4 仕様には、いくつかのセキュリティ上の考慮事項とルールが概説されていますが、正確な要件レベルについては曖昧でした。さらに、考慮事項の説明はかなり短く、理解が難しいものや実装が不可能なものもありました。
This document analyzes the 6to4 security issues in more detail and outlines some enhancements and caveats.
この文書では、6to4 のセキュリティ問題をより詳細に分析し、いくつかの機能強化と注意点について概説します。
Sections 2 and 3 are more or less introductory, rehashing how 6to4 is used today based on the 6to4 specification, so that it is easier to understand how security could be affected. Section 4 provides a threat analysis for implementations that already implement most of the security checks. Section 5 describes the optimal decapsulation/encapsulation rules for 6to4 implementations, and Section 6 provides further discussion on a few issues that have proven difficult to implement. Appendix A outlines a few possible trivial attack scenarios in which very little or no security has been implemented.
セクション 2 と 3 は多かれ少なかれ入門的なもので、セキュリティがどのように影響を受けるかを理解しやすくするために、6to4 仕様に基づいて 6to4 が今日どのように使用されているかを再確認します。セクション 4 では、ほとんどのセキュリティ チェックがすでに実装されている実装の脅威分析を提供します。セクション 5 では、6to4 実装に最適なカプセル化解除/カプセル化ルールについて説明し、セクション 6 では、実装が困難であることが判明したいくつかの問題についてさらに詳しく説明します。付録 A では、セキュリティがほとんど、またはまったく実装されていない、考えられるいくつかの簡単な攻撃シナリオの概要を説明します。
For the sake of simplicity, in this document, the native Internet is assumed to encompass IPv6 networks formed by using other transition mechanisms (e.g., RFC 2893 [4]), as these mechanisms cannot talk directly to the 6to4 network.
簡単にするために、この文書では、ネイティブ インターネットは、他の移行メカニズム (RFC 2893 [4] など) を使用して形成された IPv6 ネットワークを包含すると仮定します。これらのメカニズムは 6to4 ネットワークと直接通信できないためです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].
この文書のキーワード「しなければならない」、「してはならない」、「必須」、「しなければならない」、「してはならない」、「すべきである」、「すべきではない」、「推奨」、「してもよい」、「任意」は次のとおりです。BCP 14、RFC 2119 [2] に記載されているように解釈されます。
Throughout this memo, IPv4 addresses from blocks 7.0.0.0/24, 8.0.0.0/24, and 9.0.0.0/24 are used for demonstrative purposes, to represent global IPv4 addresses that have no relation to each other. This approach was chosen instead of just using addresses from 192.0.2.0/24 [5] for two reasons: to use addresses whose 6to4 mapping is glaringly obvious, and to make it obvious that the IPv4 addresses of different 6to4 gateways need not have any relation to each other.
このメモ全体を通じて、ブロック 7.0.0.0/24、8.0.0.0/24、および 9.0.0.0/24 の IPv4 アドレスは、相互に関係のないグローバル IPv4 アドレスを表すために、説明の目的で使用されています。このアプローチは、192.0.2.0/24 [5] のアドレスを単に使用する代わりに選択されました。その理由は 2 つあります。1 つは 6to4 マッピングが明らかなアドレスを使用するため、もう 1 つは、異なる 6to4 ゲートウェイの IPv4 アドレスに関係がある必要がないことを明確にするためです。お互いに。
Note that when one communicates between 6to4 and native domains, the 6to4 relays that will be used in the two directions are very likely different; routing is highly asymmetric. Because of this, it is not feasible to limit relays from which 6to4 routers may accept traffic.
6to4 ドメインとネイティブ ドメイン間で通信する場合、双方向で使用される 6to4 リレーは異なる可能性が高いことに注意してください。ルーティングは非常に非対称的です。このため、6to4 ルーターがトラフィックを受け入れるリレーを制限することは現実的ではありません。
The first three subsections introduce the most common forms of 6to4 operation. Other models are presented in the fourth subsection.
最初の 3 つのサブセクションでは、6to4 操作の最も一般的な形式を紹介します。他のモデルについては 4 番目のサブセクションで説明します。
6to4 domains always exchange 6to4 traffic directly via IPv4 tunneling; the endpoint address V4ADDR is derived from 6to4 prefix 2002:V4ADDR::/48 of the destination.
6to4 ドメインは常に IPv4 トンネリング経由で 6to4 トラフィックを直接交換します。エンドポイント アドレス V4ADDR は、宛先の 6to4 プレフィックス 2002:V4ADDR::/48 から導出されます。
.--------. _----_ .--------.
| 6to4 | _( IPv4 )_ | 6to4 |
| router | <====> ( Internet ) <===> | router |
'--------' (_ _) '--------'
^ '----' ^
| Direct tunneling over IPv4 |
V V
.--------. .-------.
| 6to4 | | 6to4 |
| host | | host |
'--------' '--------'
Figure 1
図1
It is required that every 6to4 router consider every other 6to4 router it wants to talk to be "on-link" (with IPv4 as the link-layer).
すべての 6to4 ルーターは、通信したい他のすべての 6to4 ルーターを (リンク層として IPv4 を使用して) 「オンリンク」であるとみなす必要があります。
When native domains send traffic to 6to4 prefix 2002:V4ADDR::/48, it will be routed to the topologically nearest advertising 6to4 relay (advertising route to 2002::/16). The 6to4 relay will tunnel the traffic over IPv4 to the corresponding IPv4 address V4ADDR.
ネイティブ ドメインが 6to4 プレフィックス 2002:V4ADDR::/48 にトラフィックを送信すると、トポロジー的に最も近いアドバタイズ 6to4 リレー (2002::/16 へのアドバタイズ ルート) にルーティングされます。6to4 リレーは、トラフィックを IPv4 経由で対応する IPv4 アドレス V4ADDR にトンネリングします。
Note that IPv4 address 9.0.0.1 here is just an example of a global IPv4 address, and it is assigned to the 6to4 router's pseudo-interface.
ここでの IPv4 アドレス 9.0.0.1 はグローバル IPv4 アドレスの一例にすぎず、6to4 ルーターの擬似インターフェイスに割り当てられることに注意してください。
Closest to
"Native IPv6 node"
.--------. _----_ .------------. .--------.
| Native | _( IPv6 )_ | 6to4 relay | Tunneled | 6to4 |
| IPv6 | -> ( Internet ) --> | router | =========> | router |
| node | (_ _) '------------' 9.0.0.1 '--------'
'--------' '----' dst_v6=2002:0900:0001::1 |
V
.-------.
| 6to4 |
| host |
'--------'
Figure 2
図2
6to4 domains send traffic to native domains by tunneling it over IPv4 to their configured 6to4 relay router, or the closest one found by using 6to4 IPv4 Anycast [3]. The relay will decapsulate the packet and forward it to native IPv6 Internet, as would any other IPv6 packet.
6to4 ドメインは、設定された 6to4 リレー ルーター、または 6to4 IPv4 エニーキャスト [3] を使用して見つかった最も近いルーターに IPv4 経由でトラフィックをトンネリングすることにより、トラフィックをネイティブ ドメインに送信します。リレーは、他の IPv6 パケットと同様に、パケットのカプセル化を解除し、ネイティブ IPv6 インターネットに転送します。
Note that the destination IPv6 address in the packet is a non-6to4 address and is assumed to be 2001:db8::1 in the example.
パケット内の宛先 IPv6 アドレスは 6to4 以外のアドレスであり、この例では 2001:db8::1 であると想定されていることに注意してください。
Configured
-or-
found by IPv4 Anycast
.--------. _----_ .------------. .--------.
| Native | _( IPv6 )_ | 6to4 relay | Tunneled | 6to4 |
| Client | <- ( Internet ) <-- | router | <========= | router |
'--------' (_ _) '------------' 192.88.99.1'--------'
2001:db8::1 '----' (or configured) ^
|
.-------.
| 6to4 |
| client |
'--------'
Figure 3
図3
These are more or less special cases of 6to4 operations. In later chapters, unless otherwise stated, only the most generally used models (above) will be considered.
これらは多かれ少なかれ、6to4 操作の特殊なケースです。以降の章では、特に明記されていない限り、最も一般的に使用されるモデル (上記) のみを考慮します。
Section 5.2.2.2 in [1] presents a model where, instead of static configuration, BGP [6] is used between 6to4 relay routers and 6to4 routers (for outgoing relay selection only).
[1] のセクション 5.2.2.2 では、静的設定の代わりに、6to4 リレー ルーターと 6to4 ルーターの間で BGP [6] が使用されるモデルが示されています (発信リレーの選択のみ)。
Going further than [1], if the 6to4 router established a BGP session between all the possible 6to4 relays and advertised its /48 prefix to them, the traffic from non-6to4 sites would always come from a "known" relay. Alternatively, the 6to4 relays might advertise the more specific 6to4 routes between 6to4 relays.
[1] よりさらに進んで、6to4 ルーターが考えられるすべての 6to4 リレー間で BGP セッションを確立し、その /48 プレフィックスをそれらにアドバタイズした場合、非 6to4 サイトからのトラフィックは常に「既知の」リレーから来ます。あるいは、6to4 リレーは、6to4 リレー間のより具体的な 6to4 ルートをアドバタイズする可能性があります。
Both of these approaches are obviously infeasible due to scalability issues.
これらのアプローチは両方とも、スケーラビリティの問題により明らかに実行不可能です。
Neither of these models are known to be used at the time of writing; this is probably because parties that need 6to4 are not able to run BGP, and because setting up these sessions would be much more work for relay operators.
これらのモデルはいずれも、この記事の執筆時点では使用されていないことが知られています。これはおそらく、6to4 を必要とする当事者が BGP を実行できないこと、および中継オペレータにとってこれらのセッションのセットアップがはるかに手間がかかるためであると考えられます。
Some sites seem to use 6to4 as an IPv6 connectivity "optimization method"; that is, they also have non-6to4 addresses on their nodes and border routers but also employ 6to4 to reach 6to4 sites.
一部のサイトでは、IPv6 接続の「最適化方法」として 6to4 を使用しているようです。つまり、ノードや境界ルーターにも 6to4 以外のアドレスがありますが、6to4 サイトに到達するために 6to4 も使用されます。
This is typically done to be able to reach 6to4 destinations by direct tunneling without using relays at all.
これは通常、リレーをまったく使用せずに直接トンネリングによって 6to4 の宛先に到達できるようにするために行われます。
These sites also publish both 6to4 and non-6to4 addresses in DNS to affect inbound connections. If the source host's default address selection [7] works properly, 6to4 sources will use 6to4 addresses to reach the site and non-6to4 nodes use non-6to4 addresses. If this behavior of foreign nodes can be assumed, the security threats to such sites can be significantly simplified.
これらのサイトは、受信接続に影響を与えるために、DNS で 6to4 アドレスと非 6to4 アドレスの両方を公開します。送信元ホストのデフォルトのアドレス選択 [7] が適切に機能する場合、6to4 送信元は 6to4 アドレスを使用してサイトに到達し、非 6to4 ノードは非 6to4 アドレスを使用します。外部ノードのこの動作を想定できれば、そのようなサイトに対するセキュリティの脅威を大幅に軽減できます。
6to4 addresses can also be used only as an IPv6-in-IPv4 tunnel endpoint addressing and routing mechanism.
6to4 アドレスは、IPv6-in-IPv4 トンネル エンドポイントのアドレス指定およびルーティング メカニズムとしてのみ使用することもできます。
An example of this is interconnecting 10 branch offices where nodes use non-6to4 addresses. Only the offices' border routers need to be aware of 6to4, and use 6to4 addresses solely for addressing the tunnels between different branch offices. An example is provided in the figure below.
この例としては、ノードが 6to4 以外のアドレスを使用する 10 のブランチ オフィスを相互接続することが挙げられます。オフィスの境界ルータのみが 6to4 を認識する必要があり、異なるブランチ オフィス間のトンネルのアドレス指定のみに 6to4 アドレスを使用します。以下の図に例を示します。
2001:db8:0:10::/60 2001:db8:0:20::/60
.--------. .--------.
( Branch 1 ) ( Branch 2 )
'--------' '--------'
| |
.--------. _----_ .--------.
| 6to4 | _( IPv4 )_ | 6to4 |
| router | <====> ( Internet ) <===> | router |
'--------' (_ _) '--------'
9.0.0.1 '----' 8.0.0.2
^^
||
vv
.--------.
| 6to4 | 7.0.0.3
| router |
'--------'
| 2001:db8::/48
.-----------.
( Main Office )
'-----------'
^
|
v
_----_
_( IPv6 )_
( Internet )
(_ _)
'----'
Figure 4
図4
In the figure, the main office sets up two routes:
この図では、本社は 2 つのルートを設定します。
2001:db8:0:10::/60 -> 2002:0900:0001::1
2001:db8:0:20::/60 -> 2002:0800:0002::1
And a branch office sets up two routes as well:
また、支店も 2 つのルートを設定します。
2001:db8:0:20::/60 -> 2002:0800:0002::1
default -> 2002:0700:0003::1
Thus, the IPv4 Internet is treated as an NBMA link-layer for interconnecting 6to4-enabled sites; with explicit routes, 6to4 addressing need not be used in routers other than the 6to4 edge routers. However, note that if a branch office sends a packet to any 6to4 destination, it will not go through the main office, as the 6to4 2002::/16 route overrides the default route.
したがって、IPv4 インターネットは、6to4 対応サイトを相互接続するための NBMA リンク層として扱われます。明示的ルートの場合、6to4 エッジ ルーター以外のルーターで 6to4 アドレッシングを使用する必要はありません。ただし、支社が 6to4 宛先にパケットを送信する場合、6to4 2002::/16 ルートがデフォルト ルートをオーバーライドするため、パケットは本社を経由しないことに注意してください。
This approach may make addressing and routing slightly easier in some circumstances.
このアプローチにより、状況によってはアドレス指定と配線が若干容易になる場合があります。
This section summarizes the main functionalities of the 6to4 network components (6to4 routers, and 6to4 relays) and the security checks they must do. The pseudo-code for the security checks is provided in Section 5.
このセクションでは、6to4 ネットワーク コンポーネント (6to4 ルーターおよび 6to4 リレー) の主な機能と、それらが実行する必要があるセキュリティ チェックについて概要を説明します。セキュリティチェックの疑似コードはセクション 5 で提供されます。
This section summarizes the main functions of the various components of a 6to4 network: 6to4 relay routers and 6to4 routers. Refer to Section 1.1 of RFC 3056 [1] for 6to4-related definitions.
このセクションでは、6to4 ネットワークのさまざまなコンポーネント (6to4 リレー ルーターと 6to4 ルーター) の主な機能を要約します。6to4 関連の定義については、RFC 3056 [1] のセクション 1.1 を参照してください。
The 6to4 routers act as the border routers of a 6to4 domain. It does not have a native global IPv6 address except in certain special cases. Since the specification [1] uses the term "6to4 router", this memo does the same; however, note that in this definition, we also include a single host with a 6to4 pseudo-interface, which doesn't otherwise act as a router. The main functions of the 6to4 router are as follows:
6to4 ルーターは、6to4 ドメインの境界ルーターとして機能します。特定の特殊な場合を除いて、ネイティブのグローバル IPv6 アドレスはありません。仕様 [1] では「6to4 ルーター」という用語が使用されているため、このメモでも同様です。ただし、この定義には、ルーターとして機能しない 6to4 擬似インターフェイスを持つ単一のホストも含まれることに注意してください。6to4 ルーターの主な機能は次のとおりです。
o Provide IPv6 connectivity to local clients and routers.
o ローカル クライアントとルーターに IPv6 接続を提供します。
o Tunnel packets sent to foreign 6to4 addresses to the destination 6to4 router using IPv4.
o IPv4 を使用して、外部 6to4 アドレスに送信されたパケットを宛先 6to4 ルーターにトンネルします。
o Forward packets sent to locally configured 6to4 addresses to the 6to4 network.
o ローカルに設定された 6to4 アドレスに送信されたパケットを 6to4 ネットワークに転送します。
o Tunnel packets sent to non-6to4 addresses to the configured/ closest-by-anycast 6to4 relay router.
o 非 6to4 アドレスに送信されたパケットを、設定済み/エニーキャストで最も近い 6to4 リレー ルーターにトンネルします。
o Decapsulate directly received IPv4 packets from foreign 6to4 addresses.
o 外部 6to4 アドレスから直接受信した IPv4 パケットのカプセル化を解除します。
o Decapsulate IPv4 packets received via the relay closest to the native IPv6 sources. Note that it is not easily distinguishable whether the packet was received from a 6to4 relay router or from a spoofing third party.
o ネイティブ IPv6 ソースに最も近いリレー経由で受信した IPv4 パケットのカプセル化を解除します。パケットが 6to4 リレー ルーターから受信されたのか、なりすましの第三者から受信されたのかを簡単に区別できないことに注意してください。
The 6to4 router should also perform security checks on traffic that it receives from other 6to4 relays, or 6to4 routers, or from within the 6to4 site. These checks include the following:
6to4 ルーターは、他の 6to4 リレー、6to4 ルーター、または 6to4 サイト内から受信するトラフィックのセキュリティ チェックも実行する必要があります。これらのチェックには次のものが含まれます。
o Disallow traffic that has private, broadcast or certain specific reserved IPv4 addresses (see Section 5.3.1 for details) in tunnels, or the matching 6to4 prefixes.
o トンネル内のプライベート、ブロードキャスト、または特定の予約済み IPv4 アドレス (詳細についてはセクション 5.3.1 を参照)、または一致する 6to4 プレフィックスを持つトラフィックを禁止します。
o Disallow traffic from 6to4 routers in which the IPv4 tunnel source address does not match the 6to4 prefix. (Note that the pseudo-interface must pick the IPv4 address corresponding to the prefix when encapsulating, or problems may ensue, e.g., on multi-interface routers.)
o IPv4 トンネル送信元アドレスが 6to4 プレフィックスと一致しない 6to4 ルーターからのトラフィックを禁止します。(擬似インターフェイスは、カプセル化するときにプレフィックスに対応する IPv4 アドレスを選択する必要があることに注意してください。そうしないと、マルチインターフェイス ルーターなどで問題が発生する可能性があります。)
o Disallow traffic in which the destination IPv6 address is not a global address; in particular, link-local addresses, mapped addresses, and such should not be used.
o 宛先 IPv6 アドレスがグローバル アドレスではないトラフィックを禁止します。特に、リンクローカル アドレス、マップされたアドレスなどは使用しないでください。
o Disallow traffic transmission to other 6to4 domains through 6to4 relay router or via some third party 6to4 router. (To avoid transmission to the relay router, the pseudo-interface prefix length must be configured correctly to /16. Further, to avoid the traffic being discarded, 6to4 source addresses must always correspond to the IPv4 address encapsulating the traffic.)
o 6to4 リレー ルーターまたはサードパーティの 6to4 ルーターを介した他の 6to4 ドメインへのトラフィック送信を禁止します。(リレー ルータへの送信を回避するには、擬似インターフェイスのプレフィックス長を /16 に正しく設定する必要があります。さらに、トラフィックの破棄を回避するには、6to4 送信元アドレスが、トラフィックをカプセル化する IPv4 アドレスに常に対応している必要があります。)
o Discard traffic received from other 6to4 domains via a 6to4 relay router.
o 6to4 リレー ルーター経由で他の 6to4 ドメインから受信したトラフィックを破棄します。
o Discard traffic received for prefixes other than one's own 6to4 prefix(es).
o 自分自身の 6to4 プレフィックス以外のプレフィックスに対して受信したトラフィックを破棄します。
The 6to4 relay router acts as a relay between all 6to4 domains and native IPv6 networks; more specifically, it
6to4 リレー ルーターは、すべての 6to4 ドメインとネイティブ IPv6 ネットワーク間のリレーとして機能します。より具体的には、それは
o advertises the reachability of the 2002::/16 prefix to native IPv6 routing, thus receiving traffic to all 6to4 addresses from the closest native IPv6 nodes,
o 2002::/16 プレフィックスの到達可能性をネイティブ IPv6 ルーティングにアドバタイズし、最も近いネイティブ IPv6 ノードからすべての 6to4 アドレスへのトラフィックを受信します。
o advertises (if RFC 3068 [3] is implemented) the reachability of IPv4 "6to4 relay anycast prefix" (192.88.99.0/24) to IPv4 routing, thus receiving some tunneled traffic to native IPv6 nodes from 6to4 routers.
o (RFC 3068 [3] が実装されている場合) IPv4「6to4 リレー エニーキャスト プレフィックス」(192.88.99.0/24) の IPv4 ルーティングへの到達可能性をアドバタイズし、6to4 ルーターからネイティブ IPv6 ノードへのトンネリングされたトラフィックを受信します。
o decapsulates and forwards packets received from 6to4 addresses through tunneling, by using normal IPv6 routing, and
o 通常の IPv6 ルーティングを使用して、トンネリングを通じて 6to4 アドレスから受信したパケットをカプセル化解除して転送します。
o tunnels packets received through normal IPv6 routing from native addresses that are destined for 2002::/16 to the corresponding 6to4 router.
o 通常の IPv6 ルーティングを通じて受信した 2002::/16 宛てのネイティブ アドレスからのパケットを、対応する 6to4 ルーターにトンネルします。
The 6to4 relay should also perform security checks on traffic that it receives from 6to4 routers, or from native IPv6 nodes. These checks are as follows:
6to4 リレーは、6to4 ルーターまたはネイティブ IPv6 ノードから受信するトラフィックのセキュリティ チェックも実行する必要があります。これらのチェックは次のとおりです。
o Disallow traffic that has private, broadcast, or certain specific reserved IPv4 addresses in tunnels, or in the matching 6to4 prefixes.
o トンネル内、または一致する 6to4 プレフィックス内に、プライベート、ブロードキャスト、または特定の予約済み IPv4 アドレスを持つトラフィックを禁止します。
o Disallow traffic from 6to4 routers in which the IPv4 tunnel source address does not match the 6to4 prefix. (Note that the pseudo-interface must pick the IPv4 address corresponding to the prefix when encapsulating, or problems may ensue, e.g., on multi-interface routers.)
o IPv4 トンネル送信元アドレスが 6to4 プレフィックスと一致しない 6to4 ルーターからのトラフィックを禁止します。(擬似インターフェイスは、カプセル化するときにプレフィックスに対応する IPv4 アドレスを選択する必要があることに注意してください。そうしないと、マルチインターフェイス ルーターなどで問題が発生する可能性があります。)
o Disallow traffic in which the destination IPv6 address is not a global address; in particular, link-local addresses, mapped addresses, and such should not be used.
o 宛先 IPv6 アドレスがグローバル アドレスではないトラフィックを禁止します。特に、リンクローカル アドレス、マップされたアドレスなどは使用しないでください。
o Discard traffic received from 6to4 routers with the destination as a 6to4 prefix.
o 宛先が 6to4 プレフィックスである 6to4 ルーターから受信したトラフィックを破棄します。
This section discusses attacks against the 6to4 network or attacks caused by the 6to4 network. The threats are discussed in light of the 6to4 deployment models defined in Section 2.
このセクションでは、6to4 ネットワークに対する攻撃、または 6to4 ネットワークによって引き起こされる攻撃について説明します。脅威については、セクション 2 で定義された 6to4 導入モデルを考慮して説明します。
There are three general types of threats:
脅威には一般的に 3 つのタイプがあります。
1. Denial-of-Service (DoS) attacks, in which a malicious node prevents communication between the node under attack and other nodes.
1. サービス拒否 (DoS) 攻撃。悪意のあるノードが攻撃対象のノードと他のノード間の通信を妨害します。
2. Reflection Denial-of-Service (DoS) attacks, in which a malicious node reflects the traffic off unsuspecting nodes to a particular node (node under attack) in order to prevent communication between the node under attack and other nodes.
2. リフレクションサービス拒否 (DoS) 攻撃。攻撃対象のノードと他のノード間の通信を防ぐために、悪意のあるノードが無防備なノードからのトラフィックを特定のノード (攻撃対象のノード) に反射します。
3. Service theft, in which a malicious node/site/operator may make unauthorized use of service.
3. サービスの盗難。悪意のあるノード/サイト/オペレーターがサービスを不正に使用する可能性があります。
6to4 also provides a means for a "meta-threat", traffic laundering, in which some other attack is channeled through the third parties to make tracing the real origin of the attack more difficult. This is used in conjunction with other threats, whether specific to 6to4 or not.
6to4 はまた、「メタ脅威」であるトラフィック ロンダリングの手段も提供します。トラフィック ロンダリングでは、他の攻撃がサード パーティを通じて行われ、攻撃の本当の発信元の追跡がより困難になります。これは、6to4 に固有かどうかに関係なく、他の脅威と組み合わせて使用されます。
At this point it is important to reiterate that the attacks are possible because
この時点で、攻撃が可能であることを繰り返し強調することが重要です。
1. 6to4 routers have to consider all 6to4 relays, and other 6to4 routers, as "on-link",
1. 6to4 ルーターは、すべての 6to4 リレーと他の 6to4 ルーターを「オンリンク」と見なす必要があります。
2. 6to4 relays have to consider all 6to4 routers as "on-link", and
2. 6to4 リレーは、すべての 6to4 ルーターを「オンリンク」と見なす必要があります。
3. it has been discovered that at least a couple of major 6to4 implementations do not implement all the security checks.
3. 少なくともいくつかの主要な 6to4 実装では、すべてのセキュリティ チェックが実装されていないことが判明しました。
The attacks' descriptions are classified based on the target of the attack:
攻撃の説明は、攻撃のターゲットに基づいて分類されています。
1. Attacks on 6to4 networks.
1. 6to4 ネットワークに対する攻撃。
2. Attacks on IPv6 networks.
2. IPv6 ネットワークに対する攻撃。
3. Attacks on IPv4 networks.
3. IPv4 ネットワークに対する攻撃。
Note that one of the mitigation methods listed for various attacks is based on the premise that 6to4 relays could have a feature limiting traffic to/from specific 6to4 sites. At the time of this writing, this feature is speculative, and more work needs to be done to determine the logistics.
さまざまな攻撃に対してリストされている緩和方法の 1 つは、6to4 リレーが特定の 6to4 サイトとの間のトラフィックを制限する機能を備えている可能性があるという前提に基づいていることに注意してください。この記事の執筆時点では、この機能は推測的なものであり、ロジスティクスを決定するにはさらに多くの作業を行う必要があります。
This section describes attacks against 6to4 networks. Attacks that leverage 6to4 networks, but for which the ultimate victim is elsewhere (e.g., a native IPv6 user, an IPv4 user), are described later in the memo.
このセクションでは、6to4 ネットワークに対する攻撃について説明します。6to4 ネットワークを利用するが、最終的な被害者が別の場所 (ネイティブ IPv6 ユーザー、IPv4 ユーザーなど) にある攻撃については、このメモの後半で説明します。
6to4 relays and routers are IPv4 nodes, and there is no way for any 6to4 router to confirm the identity of the IPv4 node from which it receives traffic -- whether from a legitimate 6to4 relay or some other node. A 6to4 router has to process traffic from all IPv4 nodes. Malicious IPv4 nodes can exploit this property and attack nodes within the 6to4 network.
6to4 リレーとルーターは IPv4 ノードであり、正規の 6to4 リレーまたは他のノードからのトラフィックの受信元である IPv4 ノードの ID を 6to4 ルーターが確認する方法はありません。6to4 ルーターは、すべての IPv4 ノードからのトラフィックを処理する必要があります。悪意のある IPv4 ノードはこの特性を悪用し、6to4 ネットワーク内のノードを攻撃する可能性があります。
It is possible to conduct a variety of attacks on the 6to4 nodes. These attacks are as follows:
6to4 ノードに対してさまざまな攻撃を行うことが可能です。これらの攻撃は次のとおりです。
1. Attacks with Neighbor Discovery (ND) Messages
1. 近隣探索 (ND) メッセージによる攻撃
2. Spoofing traffic to 6to4 nodes
2. 6to4 ノードへのトラフィックのなりすまし
3. Reflecting traffic from 6to4 nodes
3. 6to4 ノードからのトラフィックを反映する
4. Local IPv4 broadcast attack
4. ローカルIPv4ブロードキャスト攻撃
ATTACK DESCRIPTION
攻撃の説明
Since the 6to4 router assumes that all the other 6to4 routers and 6to4 relays are "on-link", it is possible to attack the 6to4 router by using ND messages from any node in the IPv4 network, unless a prior trust relationship has been established.
6to4 ルーターは、他のすべての 6to4 ルーターおよび 6to4 リレーが「オンリンク」であると想定しているため、事前に信頼関係が確立されていない限り、IPv4 ネットワーク内の任意のノードからの ND メッセージを使用して 6to4 ルーターを攻撃することが可能です。
The attacks target the 6to4 pseudo-interface. As long as the 6to4 addresses are not used in the source or destination address, the security checks specified by 6to4 take no stance on these packets. Typically they use link-local addresses.
この攻撃は 6to4 擬似インターフェイスをターゲットとしています。6to4 アドレスが送信元アドレスまたは宛先アドレスで使用されていない限り、6to4 で指定されたセキュリティ チェックはこれらのパケットに対して影響を及ぼしません。通常、リンクローカル アドレスを使用します。
For example, an attack could be a Route Advertisement or Neighbor Advertisement message crafted specifically to cause havoc; the addresses in such a packet could resemble to the following:
たとえば、攻撃は、大混乱を引き起こすために特別に作成されたルート アドバタイズメント メッセージまたはネイバー アドバタイズメント メッセージである可能性があります。このようなパケット内のアドレスは次のようになります。
src_v6 = fe80::2 (forged address)
dst_v6 = fe80::1 (valid or invalid address)
src_v4 = 8.0.0.1 (valid or forged address)
dst_v4 = 9.0.0.2 (valid address, matches dst_v6)
These attacks are exacerbated if the implementation supports more tunneling mechanisms than 6to4 (or configured tunneling) because it is impossible to disambiguate such mechanisms, making it difficult to enable strict security checks (see Section 6.1).
実装が 6to4 (または構成されたトンネリング) よりも多くのトンネリング メカニズムをサポートしている場合、これらの攻撃はさらに悪化します。これは、そのようなメカニズムを明確にすることが不可能であり、厳密なセキュリティ チェックを有効にすることが困難になるためです (セクション 6.1 を参照)。
The Neighbor Discovery threats (Redirect DoS, or DoS) are described in [8]. Note that all attacks may not be applicable, as the 6to4 pseudo-interface is assumed not to have a link-layer address (Section 3.8 RFC 2893 [4]). However, note that the 6to4 router can be either a router or host from the Neighbor Discovery perspective.
Neighbor Discovery の脅威 (リダイレクト DoS、または DoS) については、[8] で説明されています。6to4 擬似インターフェイスにはリンク層アドレスがないと想定されているため、すべての攻撃が適用できるわけではないことに注意してください (セクション 3.8 RFC 2893 [4])。ただし、近隣探索の観点からは、6to4 ルーターはルーターまたはホストのいずれかであることに注意してください。
THREAT ANALYSIS AND MITIGATION METHODS
脅威の分析と軽減方法
The attacks can be mitigated by using any of the following methods:
この攻撃は、次のいずれかの方法を使用して軽減できます。
o The usage of ND messages could be prohibited. This implies that all packets using addresses of scope link-local will be silently discarded. Section 3.1 of RFC 3056 [1] leaves scope for future uses of link-local address. This method has its pitfalls: It would prohibit any sort of ND message and thus close the doors on development and use of other ND options. Whether this is a significant problem is another thing.
o ND メッセージの使用は禁止される可能性があります。これは、スコープ リンクローカルのアドレスを使用するすべてのパケットがサイレントに破棄されることを意味します。RFC 3056 [1] のセクション 3.1 では、リンクローカル アドレスの将来の使用の余地を残しています。この方法には落とし穴があります。あらゆる種類の ND メッセージが禁止されるため、他の ND オプションの開発や使用への扉が閉ざされてしまいます。これが重大な問題かどうかは別の話です。
o The 6to4 pseudo-interface could be insulated from the other interfaces, particularly the other tunnel interfaces (if any), for example by using a separate neighbor cache.
o 6to4 擬似インターフェイスは、たとえば別個の近隣キャッシュを使用することによって、他のインターフェイス、特に他のトンネル インターフェイス (存在する場合) から隔離することができます。
o If ND messages are needed, either IPsec [4] or an extension of SEND could be used [9] to secure packet exchange using the link-local address; vanilla SEND would not work, as the link-layer does not have an address -- and IPsec would be rather complex.
o ND メッセージが必要な場合は、IPsec [4] または SEND の拡張 [9] を使用して、リンクローカル アドレスを使用したパケット交換を保護できます。リンク層にはアドレスがないため、通常の SEND は機能しません。また、IPsec はかなり複雑になります。
COMPARISON TO SITUATION WITHOUT 6to4
6to4のない状況との比較
Even though rather simply fixed, this attack is not new as such; the same is possible by using automatic tunneling [4] or configured tunneling (if one is able to spoof source IPv4 address to that of the tunnel end-point).
単純に修正されたとはいえ、この攻撃自体は新しいものではありません。自動トンネリング [4] または設定されたトンネリング (送信元 IPv4 アドレスをトンネル エンドポイントのアドレスにスプーフィングできる場合) を使用しても、同じことが可能です。
However, as 6to4 provides open decapsulation, and automatic tunneling is being deprecated [10], 6to4 provides an easy means, which would not exist without it.
ただし、6to4 はオープンなカプセル化解除を提供しており、自動トンネリングは非推奨になっている [10] ため、6to4 はそれなしでは存在しなかった簡単な手段を提供します。
ATTACK DESCRIPTION
攻撃の説明
The attacker - a malicious IPv4 or IPv6 node - can send packets that are difficult to trace (e.g., due to spoofing or going through a relay) to a 6to4 node. This can be used e.g., to accomplish a DoS attack.
攻撃者 (悪意のある IPv4 または IPv6 ノード) は、(スプーフィングやリレー経由などにより) 追跡が困難なパケットを 6to4 ノードに送信する可能性があります。これは、たとえば DoS 攻撃を実行するために使用できます。
The IPv6 and IPv4 addresses of the packets will be similar to the
following:
src_v6 = 2001:db8::1 (forged address)
dst_v6 = 2002:0900:0002::1 (valid address)
src_v4 = 8.0.0.1 (valid or forged address)
dst_v4 = 9.0.0.2 (valid address, matches dst_v6)
For attacks launched from a native IPv6 node, the src_v4 will be the address of the relay through which the traffic will reach the 6to4 node. From IPv4 nodes, src_v4 can be either a spoofed source address or the real one.
ネイティブ IPv6 ノードから開始される攻撃の場合、src_v4 はトラフィックが 6to4 ノードに到達するリレーのアドレスになります。IPv4 ノードから見ると、src_v4 は偽装された送信元アドレスまたは実際の送信元アドレスのいずれかになります。
The 6to4 router receives these packets from 8.0.0.1, decapsulates them, discards the IPv4 header containing the source address 8.0.0.1, and processes them as normal (the attacker has guessed or obtained "dst_v6" by using one of a number of techniques).
6to4 ルーターは、これらのパケットを 8.0.0.1 から受信し、カプセル化を解除し、送信元アドレス 8.0.0.1 を含む IPv4 ヘッダーを破棄し、通常どおり処理します (攻撃者は、多数の手法の 1 つを使用して「dst_v6」を推測または取得しました)。。
This is a DoS attack on 6to4 nodes.
これは 6to4 ノードに対する DoS 攻撃です。
This attack is similar to those shown in [11].
この攻撃は、[11] に示されているものと似ています。
EXTENSIONS
拡張機能
Replies to the traffic will be directed to the src_v6 address, resulting in 6to4 nodes participating in a reflection DoS. This attack is described in more detail in Section 4.2.3. The replies (e.g., TCP SYN ACK, TCP RST, ICMPv6 Echo Reply, input sent to UDP echo service, ICMPv6 Destination Unreachable) are sent to the victim (src_v6), above. All the traces from the original attacker (src_v4) have been discarded. These return packets will go through a relay.
トラフィックへの応答は src_v6 アドレスに送信され、その結果 6to4 のノードがリフレクション DoS に参加することになります。この攻撃についてはセクション 4.2.3 で詳しく説明します。応答 (例: TCP SYN ACK、TCP RST、ICMPv6 エコー応答、UDP エコー サービスに送信された入力、ICMPv6 宛先到達不能) は、上記の被害者 (src_v6) に送信されます。元の攻撃者 (src_v4) からのすべてのトレースは破棄されました。これらの返信パケットはリレーを通過します。
Certain 6to4 networks may have a trivial ACL (Access Control List) based firewall that allows traffic to pass through if it comes from particular source(s). Such a firewalling mechanism can be bypassed by address spoofing. This attack can therefore be used for trivial ACL avoidance as well. These attacks might be hampered because the replies from the 6to4 node to the spoofed address will be lost.
特定の 6to4 ネットワークには、特定の送信元からのトラフィックの通過を許可する簡単な ACL (アクセス コントロール リスト) ベースのファイアウォールがある場合があります。このようなファイアウォール メカニズムは、アドレス スプーフィングによってバイパスされる可能性があります。したがって、この攻撃は単純な ACL 回避にも使用できます。6to4 ノードからスプーフィングされたアドレスへの応答が失われるため、これらの攻撃は阻止される可能性があります。
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
脅威の分析と解決策/軽減方法
The Denial-of-Service attack based on traffic spoofing is not new; the only twists come from the fact that traces of an attack are more easily lost, and that spoofing the IPv6 address is possible even to those who are unable to do so in their current networks. The 6to4 router typically does not log IPv4 addresses (as they would be treated as L2 addresses), and thus the source of the attack (if launched from an IPv4 node) is lost. Because traces to the src_v4 address are easily lost, these attacks can also be launched from IPv4 nodes whose connections are ingress-filtered.
トラフィック スプーフィングに基づくサービス拒否攻撃は新しいものではありません。唯一のひねりは、攻撃の痕跡が失われやすいという事実と、現在のネットワークではそれができない人でも IPv6 アドレスのなりすましが可能であるという事実から来ています。6to4 ルーターは通常、IPv4 アドレスを (L2 アドレスとして扱われるため) ログに記録しないため、攻撃の発信元 (IPv4 ノードから開始された場合) が失われます。src_v4 アドレスへのトレースは簡単に失われるため、これらの攻撃は、接続がイングレス フィルタリングされている IPv4 ノードからも開始される可能性があります。
However, often this is not a real factor, as usually the attackers are just zombies and real attackers may not even care whether the unspoofed source address is discovered.
ただし、通常、攻撃者は単なるゾンビであり、本物の攻撃者は偽装されていない送信元アドレスが発見されるかどうかさえ気にしない可能性があるため、これは実際の要因ではありません。
Malicious native IPv6 nodes could be caught easily if ingress filtering was enabled everywhere in the IPv6 Internet.
IPv6 インターネットのあらゆる場所でイングレス フィルタリングが有効になっている場合、悪意のあるネイティブ IPv6 ノードは簡単に捕らえられる可能性があります。
These attacks are easy to perform, but the extent of harm is limited:
これらの攻撃は簡単に実行できますが、被害の範囲は限られています。
o For every packet sent, at most one reply packet is generated: there is no amplification factor.
o 送信されるパケットごとに、最大 1 つの応答パケットが生成されます。増幅率はありません。
o Attack packets, if initiated from an IPv6 node, will pass through choke point(s), namely a 6to4 relay; in addition to physical limitations, these could implement some form of 6to4-site-specific traffic limiting.
o 攻撃パケットが IPv6 ノードから開始された場合、チョーク ポイント、つまり 6to4 リレーを通過します。物理的な制限に加えて、これらにより、何らかの形式の 6to4 サイト固有のトラフィック制限が実装される可能性があります。
On the other hand, a variety of factors can make the attacks serious:
一方で、さまざまな要因により攻撃が深刻になる可能性があります。
o The attacker may have the ability to choose the relay, and he might employ the ones best suited for the attacks. Also, many relays use 192.88.99.1 [3] as the source address, making tracing even more difficult (also see Section 4.2.6).
o 攻撃者はリレーを選択することができ、攻撃に最も適したリレーを採用する可能性があります。また、多くのリレーは送信元アドレスとして 192.88.99.1 [3] を使用するため、追跡がさらに困難になります (セクション 4.2.6 も参照)。
o The relay's IPv4 address may be used as a source address for these attacks, potentially causing a lot of complaints or other actions, as the relay might seem to be the source of the attack (see Section 4.2.6 for more).
o リレーの IPv4 アドレスは、これらの攻撃の送信元アドレスとして使用される可能性があり、リレーが攻撃の発信元であると思われるため、多くの苦情やその他のアクションを引き起こす可能性があります (詳細についてはセクション 4.2.6 を参照)。
Some of the mitigation methods for such attacks are as follows:
このような攻撃に対する軽減方法のいくつかは次のとおりです。
1. Ingress filtering in the native IPv6 networks to prevent packets with spoofed IPv6 sources from being transmitted. This would, thus, make it easy to identify the source of the attack. Unfortunately, it would depend on significant (or even complete) ingress filtering everywhere in other networks; while this is highly desirable, it may not be feasible.
1. ネイティブ IPv6 ネットワークでのイングレス フィルタリングにより、スプーフィングされた IPv6 ソースを持つパケットの送信を防止します。したがって、これにより、攻撃の発信元を簡単に特定できるようになります。残念ながら、これは他のネットワークのあらゆる場所での重要な (または完全な) イングレス フィルタリングに依存することになります。これは非常に望ましいことですが、実現不可能な場合もあります。
2. Security checks in the 6to4 relay. The 6to4 relay must drop traffic (from the IPv6 Internet) that has 6to4 addresses as source address; see Section 5 for more detail. This has very little cost.
2. 6to4 リレーのセキュリティ チェック。6to4 リレーは、送信元アドレスとして 6to4 アドレスを持つ (IPv6 インターネットからの) トラフィックをドロップする必要があります。詳細についてはセクション 5 を参照してください。これにはコストがほとんどかかりません。
However, these mitigation methods do not address the case of an IPv4 node sending encapsulated IPv6 packets.
ただし、これらの緩和方法は、カプセル化された IPv6 パケットを送信する IPv4 ノードのケースには対応していません。
No simple way to prevent such attacks exists, and longer-term solutions, such as ingress filtering [12] or itrace [13], would have to be deployed in both IPv6 and IPv4 networks to help identify the source of the attacks. A total penetration is likely impossible. (Note that itrace work has been discontinued, as of this writing in July 2004.)
このような攻撃を防ぐ簡単な方法は存在せず、攻撃のソースを特定するには、イングレス フィルタリング [12] や itrace [13] などの長期的なソリューションを IPv6 ネットワークと IPv4 ネットワークの両方に導入する必要があります。完全な浸透はおそらく不可能です。(この記事を書いている 2004 年 7 月の時点で、itrace の作業は中止されていることに注意してください。)
COMPARISON TO SITUATION WITHOUT 6to4
6to4のない状況との比較
Traffic spoofing is not a new phenomenon in IPv4 or IPv6. 6to4 just makes it easier: Anyone can, regardless of ingress filtering, spoof a native IPv6 address to a 6to4 node, even if "maximal security" would be implemented and deployed. Losing trails is also easier.
トラフィック スプーフィングは、IPv4 または IPv6 において新しい現象ではありません。6to4 を使用すると、それが簡単になります。たとえ「最大限のセキュリティ」が実装および展開されていたとしても、イングレス フィルタリングに関係なく、誰でもネイティブ IPv6 アドレスを 6to4 ノードにスプーフィングできます。道を見失いやすくなります。
Therefore, depending on how much one assumes ingress filtering is deployed for IPv4 and IPv6, this could be considered either a very serious issue or close to irrelevant compared to the IP spoofing capabilities without 6to4.
したがって、イングレス フィルタリングが IPv4 および IPv6 に展開されているとどの程度想定しているかによって、これは、6to4 を使用しない IP スプーフィング機能と比較して、非常に深刻な問題であるか、無関係に近いかのいずれかであると考えられます。
ATTACK DESCRIPTION
攻撃の説明
Spoofed traffic (as described in Section 4.2.2) may be sent to native IPv6 nodes to perform a reflection attack against 6to4 nodes.
スプーフィングされたトラフィック (セクション 4.2.2 で説明) がネイティブ IPv6 ノードに送信され、6to4 ノードに対してリフレクション攻撃が実行される可能性があります。
The spoofed traffic is sent to a native IPv6 node, either from an IPv4 node (through a 6to4 relay) or from a native IPv6 node (unless ingress filtering has been deployed). With the former, the sent packets would resemble the following:
スプーフィングされたトラフィックは、IPv4 ノード (6to4 リレー経由) またはネイティブ IPv6 ノード (イングレス フィルタリングが展開されていない場合) からネイティブ IPv6 ノードに送信されます。前者の場合、送信されるパケットは次のようになります。
src_v6 = 2002:1234:1234::1 (forged address of the target 6to4 node)
dst_v6 = 2002:0900:0002::1 (valid address)
src_v4 = 8.0.0.1 (valid or invalid address)
dst_v4 = 9.0.0.2 (valid address, matches dst_v6)
Note that an attack through the relay is prevented if the relay implements proper decapsulation security checks (see Section 5 for details) unless the IPv4 node can spoof the source address to match src_v6. Similarly, the attack from native IPv6 nodes could be prevented by global ingress filtering deployment.
IPv4 ノードが送信元アドレスを偽装して src_v6 と一致しない限り、リレーが適切なカプセル化解除セキュリティ チェックを実装していれば、リレーを介した攻撃は防止されることに注意してください (詳細についてはセクション 5 を参照)。同様に、ネイティブ IPv6 ノードからの攻撃は、グローバルなイングレス フィルタリングの展開によって防止できます。
These attacks can be initiated by native IPv6, IPv4, or 6to4 nodes.
これらの攻撃は、ネイティブ IPv6、IPv4、または 6to4 ノードによって開始される可能性があります。
EXTENSIONS
拡張機能
A distributed Reflection DoS can be performed if a large number of nodes are involved in sending spoofed traffic with the same src_v6.
多数のノードが同じ src_v6 でスプーフィングされたトラフィックの送信に関与している場合、分散リフレクション DoS を実行できます。
Malicious 6to4 nodes can also (try to) initiate this attack by bouncing traffic off 6to4 nodes in other 6to4 sites. However, this attack may not be possible, as the 6to4 router (in the site from which the attack is launched) will filter packets with forged source addresses (with security checks mentioned in Section 5).
悪意のある 6to4 ノードは、他の 6to4 サイトの 6to4 ノードからトラフィックをバウンスすることによって、この攻撃を開始する (試みる) こともできます。ただし、6to4 ルーター (攻撃が開始されるサイト内) が (セクション 5 で説明したセキュリティ チェックを使用して) 偽造された送信元アドレスを持つパケットをフィルタリングするため、この攻撃は不可能である可能性があります。
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
脅威の分析と解決策/軽減方法
In this case, the reverse traffic comprises replies to the messages received by the 6to4 nodes. The attacker has less control on the packet type, and this would inhibit certain types of attacks. For example, flooding a 6to4 node with TCP SYN packets will not be possible (but e.g., a SYN-ACK or RST would be).
この場合、逆方向トラフィックは、6to4 ノードが受信したメッセージへの応答で構成されます。攻撃者はパケットの種類をあまり制御できないため、特定の種類の攻撃が阻止されます。たとえば、6to4 ノードに TCP SYN パケットをフラッディングすることはできません (ただし、SYN-ACK や RST などは可能です)。
These attacks may be mitigated in various ways:
これらの攻撃は、次のようなさまざまな方法で軽減できます。
o Implementation of ingress filtering by the IPv4 service providers. This would prevent forging of the src_v4 address and help in closing down on the culprit IPv4 nodes. Note that it will be difficult to shut down the attack if a large number of IPv4 nodes are involved.
o IPv4 サービス プロバイダーによるイングレス フィルタリングの実装。これにより、src_v4 アドレスの偽造が防止され、原因となっている IPv4 ノードを閉鎖するのに役立ちます。多数の IPv4 ノードが関与している場合、攻撃をシャットダウンすることが困難になることに注意してください。
These attacks may be also be stopped at the 6to4 sites if the culprit src_v4 address is identified, and if it is constant, by filtering traffic from this address. Note that it would be difficult to implement this method if appropriate logging were not done by the 6to4 router or if a large number of 6to4 nodes, and/or a large number of IPv4 nodes were participating in the attack.
原因となる src_v4 アドレスが特定され、それが一定である場合は、このアドレスからのトラフィックをフィルタリングすることで、これらの攻撃を 6to4 サイトで阻止することもできます。6to4 ルーターによって適切なロギングが行われていない場合、または多数の 6to4 ノードや多数の IPv4 ノードが攻撃に参加している場合、この方法を実装するのは困難であることに注意してください。
Unfortunately, because many IPv4 service providers don't implement ingress filtering, for whatever reasons, this may not be a satisfactory solution.
残念ながら、多くの IPv4 サービス プロバイダーは何らかの理由でイングレス フィルタリングを実装していないため、これは満足のいく解決策ではない可能性があります。
o Implementation of ingress filtering by all IPv6 service providers would eliminate this attack, because src_v6 could not be spoofed as a 6to4 address. However, expecting this to happen may not be practical.
o すべての IPv6 サービス プロバイダーがイングレス フィルタリングを実装すると、src_v6 を 6to4 アドレスとして偽装することができないため、この攻撃は排除されます。ただし、これが起こることを期待するのは現実的ではないかもしれません。
o Proper implementation of security checks (see Section 5) both at the 6to4 relays and routers would eliminate an attack launched from an IPv4 node, except when the IPv4 source address was also spoofed -- but then the attacker would have been able to attack the ultimate destination directly.
o 6to4 リレーとルーターの両方でセキュリティ チェック (セクション 5 を参照) を適切に実装すれば、IPv4 ソース アドレスもスプーフィングされている場合を除いて、IPv4 ノードから開始される攻撃は排除されます。しかし、その場合、攻撃者は究極の攻撃を行うことができます。直接目的地へ。
o Rate limiting traffic at the 6to4 relays. In a scenario where most of the traffic is passing through few 6to4 relays, these relays can implement traffic rate-limiting features and rate-limit the traffic from 6to4 sites.
o 6to4 リレーでのトラフィックのレート制限。ほとんどのトラフィックが少数の 6to4 リレーを通過するシナリオでは、これらのリレーはトラフィック レート制限機能を実装し、6to4 サイトからのトラフィックをレート制限できます。
COMPARISON TO SITUATION WITHOUT 6to4
6to4のない状況との比較
This particular attack can be mitigated by proper implementation of security checks (which is quite straightforward) and ingress filtering; when ingress filtering is not implemented, it is typically easier to attack directly than through reflection -- unless "traffic laundering" is an explicit goal of the attack. Therefore, this attack does not seem very serious.
この特定の攻撃は、セキュリティ チェック (これは非常に簡単です) とイングレス フィルタリングを適切に実装することで軽減できます。イングレス フィルタリングが実装されていない場合、「トラフィック ロンダリング」が攻撃の明示的な目的でない限り、通常はリフレクションを介して攻撃するよりも直接攻撃する方が簡単です。したがって、この攻撃はそれほど深刻なものではないようです。
ATTACK DESCRIPTION
攻撃の説明
This threat is applicable if the 6to4 router does not check whether the IPv4 address to which it tries to send encapsulated IPv6 packets is a local broadcast address or a multicast address.
この脅威は、6to4 ルーターが、カプセル化された IPv6 パケットの送信先の IPv4 アドレスがローカル ブロードキャスト アドレスであるかマルチキャスト アドレスであるかを確認しない場合に適用されます。
This threat is described in the specification [1], and implementing the checks eliminates this threat. However, as checks have not been widely implemented, the threat is included here for completeness.
この脅威は仕様 [1] で説明されており、チェックを実装することでこの脅威は排除されます。ただし、チェックは広く実装されていないため、完全を期すためにここに脅威が含まれています。
There practically two kinds of attacks: when a local 6to4 user tries to send packets to the address corresponding to the broadcast address, and when someone is able to do so remotely.
実際には 2 種類の攻撃があります。ローカル 6to4 ユーザーがブロードキャスト アドレスに対応するアドレスにパケットを送信しようとする場合と、誰かがリモートから送信できる場合です。
In the first option, assume that 9.0.0.255 is the 6to4 router's broadcast address. After receiving the packet with a destination address like "2002:0900:00ff::bbbb" from a local 6to4 node, if the router doesn't check the destination address for subnet broadcast, it would send the encapsulated protocol-41 packet to 9.0.0.255. This would be received by all nodes in the subnet, and the responses would be directed to the 6to4 router.
最初のオプションでは、9.0.0.255 が 6to4 ルーターのブロードキャスト アドレスであると仮定します。ローカル 6to4 ノードから「2002:0900:00ff::bbbb」のような宛先アドレスを持つパケットを受信した後、ルーターがサブネット ブロードキャストの宛先アドレスをチェックしない場合、カプセル化されたプロトコル 41 パケットが 9.0 に送信されます。.0.255。これはサブネット内のすべてのノードによって受信され、応答は 6to4 ルーターに送信されます。
Malicious sites may also embed forged 6to4 addresses in the DNS, use of which by a 6to4 node would result in a local broadcast by the 6to4 router. One way to perform this attack would be to send an HTML mail containing a link to an invalid URL (for example, http://[2002:0900:00ff::bbbb]/index.html) to all users in a 6to4 technology based network. Opening of the mail simultaneously would result in a broadcast storm.
悪意のあるサイトは、偽造した 6to4 アドレスを DNS に埋め込むこともあります。これを 6to4 ノードが使用すると、6to4 ルーターによるローカル ブロードキャストが発生します。この攻撃を実行する 1 つの方法は、無効な URL (例: http://[2002:0900:00ff::bbbb]/index.html) へのリンクを含む HTML メールを 6to4 テクノロジーのすべてのユーザーに送信することです。ベースのネットワーク。メールを同時に開くとブロードキャスト ストームが発生します。
The second kind of attack is more complex: The attack can be
initiated by IPv4 nodes not belonging to the local network as long as
they can send traffic with invalid (for example 2002:0900:00ff::bbbb)
source address. The 6to4 router has to respond to the traffic by
sending ICMPv6 packets back to the source, (e.g., Hop Limit Exceeded
or Destination Unreachable). The packet would be as follows:
src_v6 = 2002:0800:00ff::bbbb (broadcast address of the router)
dst_v6 = 2002:0800:0001::0001 (valid non-existent address)
This is a DoS attack.
これは DoS 攻撃です。
EXTENSIONS
拡張機能
The attacks could also be directed at non-local broadcast addresses, but these would be so-called "IPv4 directed broadcasts", which have (luckily enough) already been extensively blocked in the Internet.
攻撃はローカル以外のブロードキャスト アドレスに向けられる可能性もありますが、これらはいわゆる「IPv4 向けブロードキャスト」となり、（幸いなことに）すでにインターネットで広範囲にブロックされています。
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
脅威の分析と解決策/軽減方法
The attack is based on the premise that the 6to4 router has to send a packet that embeds an invalid IPv4 address to an IPv6 address. Such an attack is easily thwarted by ensuring that the 6to4 router does not transmit packets to invalid IPv4 addresses. Specifically, traffic should not be sent to broadcast or multicast IPv4 addresses.
この攻撃は、6to4 ルーターが無効な IPv4 アドレスを埋め込んだパケットを IPv6 アドレスに送信する必要があるという前提に基づいています。このような攻撃は、6to4 ルーターが無効な IPv4 アドレスにパケットを送信しないようにすることで簡単に阻止できます。具体的には、トラフィックをブロードキャストまたはマルチキャスト IPv4 アドレスに送信しないでください。
COMPARISON TO SITUATION WITHOUT 6to4
6to4のない状況との比較
The first threat is similar to what is already possible with IPv4, but IPv6 does not have broadcast addresses.
最初の脅威は、IPv4 ですでに可能になっているものと似ていますが、IPv6 にはブロードキャスト アドレスがありません。
The second, a more complex threat, is, similarly, also available in IPv4.
2 番目のより複雑な脅威も、同様に IPv4 で利用可能です。
In consequence, the security does not seem to be significantly worse than with IPv4, and even that is restricted to the site(s) with 6to4 implementations that haven't been secured as described in Section 5.
その結果、セキュリティは IPv4 よりも大幅に劣るようには見えませんが、それは、セクション 5 で説明したようにセキュリティが確保されていない 6to4 実装を備えたサイトに限定されます。
This section describes attacks against native IPv6 Internet that somehow leverage 6to4 architecture. Attacks against 6to4 nodes were described in the previous section.
このセクションでは、何らかの方法で 6to4 アーキテクチャを利用したネイティブ IPv6 インターネットに対する攻撃について説明します。6to4 ノードに対する攻撃については、前のセクションで説明しました。
6to4 and IPv4 nodes can access native IPv6 nodes through the 6to4 relay routers. Thus, the 6to4 relays play a crucial role in any attack on native IPv6 nodes by IPv4 nodes or 6to4 nodes.
6to4 および IPv4 ノードは、6to4 リレー ルーターを通じてネイティブ IPv6 ノードにアクセスできます。したがって、6to4 リレーは、IPv4 ノードまたは 6to4 ノードによるネイティブ IPv6 ノードに対する攻撃において重要な役割を果たします。
6to4 relays have only one significant security check they must perform for general safety: When decapsulating IPv4 packets, they check that 2002:V4ADDR::/48 and V4ADDR match in the source address. If this is not done, several threats become more serious; in the following analysis, it is assumed that such checks are implemented.
6to4 リレーには、一般的な安全性を確保するために実行する必要がある重要なセキュリティ チェックが 1 つだけあります。IPv4 パケットのカプセル化を解除するときに、送信元アドレスで 2002:V4ADDR::/48 と V4ADDR が一致するかどうかをチェックします。これを行わないと、いくつかの脅威がさらに深刻になります。以下の分析では、そのようなチェックが実装されていると仮定します。
6to4 relay should not relay packets between 6to4 addresses. In particular, packets decapsulated from 6to4 routers should not be encapsulated toward 6to4 routers, as described in Section 5. Similarly, packets with 6to4 source and destination addresses sent from IPv6 nodes should not be relayed. It is not clear whether this kind of check is typically implemented. The attacks described below assume that such checks are not implemented.
6to4 リレーは 6to4 アドレス間でパケットを中継しないでください。特に、6to4 ルーターからカプセル化解除されたパケットは、セクション 5 で説明されているように、6to4 ルーターに向けてカプセル化されるべきではありません。同様に、IPv6 ノードから送信される 6to4 送信元アドレスと宛先アドレスを持つパケットは中継されるべきではありません。この種のチェックが通常実装されるかどうかは不明です。以下で説明する攻撃は、そのようなチェックが実装されていないことを前提としています。
These attacks are the same as those employed against 6to4 routers, as described in Section 4.1.1.
これらの攻撃は、セクション 4.1.1 で説明したように、6to4 ルーターに対して行われた攻撃と同じです。
ATTACK DESCRIPTION
攻撃の説明
The attacker - a malicious IPv4 or 6to4 node - can send packets with a spoofed (or not spoofed) 6to4 source address to a native IPv6 node to accomplish a DoS attack.
攻撃者 (悪意のある IPv4 または 6to4 ノード) は、スプーフィングされた (またはスプーフィングされていない) 6to4 送信元アドレスを持つパケットをネイティブ IPv6 ノードに送信して、DoS 攻撃を実行する可能性があります。
The threat is similar to that involving 6to4 routers, as described in Section 4.1.2.
この脅威は、セクション 4.1.2 で説明した 6to4 ルーターに関する脅威と似ています。
The difference here is that the attack is initiated by IPv4 or 6to4 nodes. The source IPv6 address may or may not be spoofed. Note that, as mentioned above, the relay is assumed to correlate the source IPv4 address with the address embedded in the source IPv6 address during decapsulation. A side effect is that all spoofed traffic will have a 6to4 source address.
ここでの違いは、攻撃が IPv4 ノードまたは 6to4 ノードによって開始されることです。送信元 IPv6 アドレスはスプーフィングされる場合もあれば、スプーフィングされない場合もあります。前述したように、リレーはカプセル化解除中に送信元 IPv4 アドレスを送信元 IPv6 アドレスに埋め込まれたアドレスと関連付けることが想定されていることに注意してください。副作用として、スプーフィングされたトラフィックはすべて 6to4 送信元アドレスを持つことになります。
EXTENSIONS
拡張機能
Spoofed traffic may also be sent to native IPv6 nodes either by other native IPv6 nodes, by 6to4 nodes, or by malicious IPv4 nodes to conduct Reflection DoS on either native IPv6 nodes or 6to4 nodes.
スプーフィングされたトラフィックは、他のネイティブ IPv6 ノード、6to4 ノード、または悪意のある IPv4 ノードによってネイティブ IPv6 ノードに送信され、ネイティブ IPv6 ノードまたは 6to4 ノードでリフレクション DoS を実行することもあります。
Certain native IPv6 networks may have a trivial ACL (Access Control List) based firewall that allows traffic to pass through if it comes from particular source(s). Such a firewalling mechanism can be bypassed by address spoofing. This attack can therefore be used for trivial ACL avoidance as well. These attacks might be hampered by lost replies from the 6to4 node to the spoofed address.
特定のネイティブ IPv6 ネットワークには、特定の送信元からのトラフィックの通過を許可する簡単な ACL (アクセス コントロール リスト) ベースのファイアウォールがある場合があります。このようなファイアウォール メカニズムは、アドレス スプーフィングによってバイパスされる可能性があります。したがって、この攻撃は単純な ACL 回避にも使用できます。これらの攻撃は、6to4 ノードからスプーフィングされたアドレスへの応答が失われることによって妨げられる可能性があります。
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
脅威の分析と解決策/軽減方法
The Denial-of-Service attack based on traffic spoofing is not new; the only twist is that traces of an attack are more easily lost. The 6to4 relay typically does not log IPv4 addresses (as they would be treated as L2 addresses), and thus the source of the attack (if launched from an IPv4 node) is lost. Because traces to the src_v4 address are easily lost, these attacks can also be launched from IPv4 nodes whose connections are ingress-filtered.
トラフィック スプーフィングに基づくサービス拒否攻撃は新しいものではありません。唯一の工夫は、攻撃の痕跡が失われやすくなることです。6to4 リレーは通常、IPv4 アドレスをログに記録しないため (L2 アドレスとして扱われるため)、攻撃の発信元 (IPv4 ノードから開始された場合) が失われます。src_v4 アドレスへのトレースは簡単に失われるため、これらの攻撃は、接続がイングレス フィルタリングされている IPv4 ノードからも開始される可能性があります。
These attacks might not be easy to perform and might be hampered because of the following:
これらの攻撃は実行が容易ではなく、次の理由で阻止される可能性があります。
o It might be difficult to launch such attacks from 6to4 nodes because even if the 6to4 routers allow spoofing of the source IPv6 address, the 6to4 relay would check whether the source V4ADDR is the same as the one embedded in the source IPv6 address. Thus, 6to4 nodes will be forced to use the correct IPv6 prefix while launching an attack, making it easy to close such attacks.
o 6to4 ルーターが送信元 IPv6 アドレスのスプーフィングを許可している場合でも、6to4 リレーは送信元 V4ADDR が送信元 IPv6 アドレスに埋め込まれた V4ADDR と同じであるかどうかをチェックするため、6to4 ノードからこのような攻撃を開始するのは難しい場合があります。したがって、6to4 ノードは攻撃を開始する際に正しい IPv6 プレフィックスを使用することを強制されるため、そのような攻撃を簡単に終了できます。
o Packets may pass through choke point(s), namely a 6to4 relay. In addition to physical limitations, there could be some sort of traffic rate limiting mechanisms that may be implemented, and these could tone down the attack.
o パケットはチョーク ポイント、つまり 6to4 リレーを通過する可能性があります。物理的な制限に加えて、何らかのトラフィック レート制限メカニズムが実装されている可能性があり、これらによって攻撃が抑制される可能性があります。
o For every packet sent, at most one reply packet is generated: There is no amplification factor.
o 送信されるパケットごとに、最大 1 つの応答パケットが生成されます。増幅率はありません。
Some of the mitigation methods for such attacks are as follows:
このような攻撃に対する軽減方法のいくつかは次のとおりです。
1. Ingress filtering in the IPv4 Internet to prevent packets with a spoofed IPv4 source from being transmitted. As the relay checks that the 6to4 address embeds the IPv4 address, no spoofing can be achieved unless IPv4 addresses can be spoofed. However, this would probably be an unfeasible requirement.
1. IPv4 インターネットにおけるイングレス フィルタリング。スプーフィングされた IPv4 ソースを持つパケットの送信を防ぎます。リレーは 6to4 アドレスに IPv4 アドレスが埋め込まれていることをチェックするため、IPv4 アドレスがスプーフィングできない限り、スプーフィングは実行できません。ただし、これはおそらく実現不可能な要件です。
2. Security checks in the 6to4 relay. The 6to4 relay must drop traffic (from 6to4 nodes, or IPv4 nodes) with non-6to4 addresses as the source address, or for which the source IPv4 address does not match the address embedded in the source IPv6 address.
2. 6to4 リレーのセキュリティ チェック。6to4 リレーは、6to4 以外のアドレスを送信元アドレスとして持つトラフィック、または送信元 IPv4 アドレスが送信元 IPv6 アドレスに埋め込まれたアドレスと一致しないトラフィック (6to4 ノードまたは IPv4 ノードからの) をドロップする必要があります。
COMPARISON TO SITUATION WITHOUT 6to4
6to4のない状況との比較
Compared to Section 4.1.2, which describes more serious threats, this threat appears to be slightly more manageable. If the relays perform proper decapsulation checks, the spoofing can only be achieved, to a 6to4 source address, when the IPv4 address is spoofable as well.
より深刻な脅威について説明しているセクション 4.1.2 と比較すると、この脅威は若干管理しやすいようです。リレーが適切なカプセル化解除チェックを実行する場合、IPv4 アドレスもスプーフィング可能な場合、スプーフィングは 6to4 送信元アドレスに対してのみ実行できます。
ATTACK DESCRIPTION
攻撃の説明
These reflection attacks are similar to that involving 6to4 routers, as described in Section 4.1.3. Traffic may be reflected off native IPv6 nodes, or off 6to4 nodes. The attack can be initiated by one of the following:
これらのリフレクション攻撃は、セクション 4.1.3 で説明されているように、6to4 ルーターが関与するものと似ています。トラフィックはネイティブ IPv6 ノードまたは 6to4 ノードから反射される場合があります。攻撃は次のいずれかによって開始される可能性があります。
o Native IPv6 nodes. These nodes can send invalid traffic with spoofed native IPv6 addresses to valid 6to4 nodes. Replies from the 6to4 nodes are part of a reflection attack.
o ネイティブ IPv6 ノード。これらのノードは、スプーフィングされたネイティブ IPv6 アドレスを含む無効なトラフィックを有効な 6to4 ノードに送信する可能性があります。6to4 ノードからの応答はリフレクション攻撃の一部です。
o IPv4 nodes. These nodes can send traffic with native IPv6 source addresses (encapsulated by the IPv4 node itself into a protocol-41 packet) to 6to4 nodes. Replies from the 6to4 nodes are part of a reflection attack.
o IPv4 ノード。これらのノードは、ネイティブ IPv6 送信元アドレス (IPv4 ノード自体によってプロトコル 41 パケットにカプセル化されたもの) を持つトラフィックを 6to4 ノードに送信できます。6to4 ノードからの応答はリフレクション攻撃の一部です。
o 6to4 nodes. These nodes can perform attacks similar to those by IPv4 nodes, but this would require spoofing of the source address at the 6to4 site before encapsulation, which is likely to be difficult.
o 6to4ノード。これらのノードは、IPv4 ノードによる攻撃と同様の攻撃を実行できますが、これにはカプセル化の前に 6to4 サイトで送信元アドレスのスプーフィングが必要となり、これはおそらく困難です。
When launched from a native IPv6 node, the traffic goes through 6to4 relays twice, both before and after the reflection; when launched from a 6to4/IPv4 node, the traffic goes through a relay only after the reflection.
ネイティブ IPv6 ノードから起動された場合、トラフィックはリフレクションの前後で 6to4 リレーを 2 回通過します。6to4/IPv4 ノードから起動された場合、トラフィックはリフレクション後にのみリレーを通過します。
EXTENSIONS
拡張機能
A distributed reflection DoS can be performed if a large number of native IPv6 nodes or IPv4/6to4 nodes are involved in sending spoofed traffic with the same source IPv6 address.
分散リフレクション DoS は、多数のネイティブ IPv6 ノードまたは IPv4/6to4 ノードが同じ送信元 IPv6 アドレスを持つスプーフィング トラフィックの送信に関与している場合に実行できます。
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
脅威の分析と解決策/軽減方法
Some of the mitigation methods for such attacks are as follows:
このような攻撃に対する軽減方法のいくつかは次のとおりです。
1. Attacks from the native IPv6 nodes could be stopped by implementing ingress filtering in the IPv6 Internet; hopefully this will become commonplace, but past experience of IPv4 ingress filtering deployment (or lack thereof) does not promise much.
1. ネイティブ IPv6 ノードからの攻撃は、IPv6 インターネットにイングレス フィルタリングを実装することで阻止できます。これが一般的になることを願っていますが、IPv4 イングレス フィルタリングの導入 (またはその欠如) の過去の経験では、あまり期待できません。
2. Two measures are needed to stop or mitigate the attacks from IPv4 nodes: 1) Implementing ingress filtering in the IPv4 internet, and 2) logging IPv4 source addresses in the 6to4 router.
2. IPv4 ノードからの攻撃を阻止または軽減するには、2 つの対策が必要です。1) IPv4 インターネットにイングレス フィルタリングを実装する、2) 6to4 ルーターに IPv4 送信元アドレスを記録する。
3. Attacks from 6to4 nodes in other sites can be stopped if the 6to4 routers in those sites implement egress filtering. This could be done by those sites, but the sites that are most likely to be abused are typically also those most likely to neglect installing appropriate filtering at their edges.
3. 他のサイトの 6to4 ノードからの攻撃は、それらのサイトの 6to4 ルーターが出力フィルタリングを実装している場合に阻止できます。これはこれらのサイトによって実行される可能性がありますが、悪用される可能性が最も高いサイトは、通常、エッジでの適切なフィルタリングのインストールを無視する可能性が最も高いサイトでもあります。
4. The traffic passes through one or two relays, and traffic rate limiting in the 6to4 relays might help tone down the reflection attack.
4. トラフィックは 1 つまたは 2 つのリレーを通過し、6to4 リレーのトラフィック レート制限はリフレクション攻撃を軽減するのに役立つ可能性があります。
COMPARISON TO SITUATION WITHOUT 6to4
6to4のない状況との比較
Even though there are means to mitigate it, the attack is still rather efficient, especially when used by native IPv6 nodes with spoofed addresses. Using 6to4 relays and routers could easily take down the 6to4 relay system and/or provide an easy means for traffic laundering. However, if the attack is intended to DoS the victim, this can be achieved more smoothly by doing it directly (as the source address spoofing was available as well).
攻撃を軽減する手段はありますが、特にスプーフィングされたアドレスを持つネイティブ IPv6 ノードによって使用される場合、この攻撃は依然としてかなり効率的です。6to4 リレーとルーターを使用すると、6to4 リレー システムが簡単にダウンしたり、トラフィック ロンダリングの簡単な手段を提供したりする可能性があります。ただし、攻撃の目的が被害者への DoS である場合は、直接実行することでよりスムーズに実行できます (送信元アドレスのスプーフィングも利用できたため)。
Therefore, the threat to the availability and stability of the 6to4 relay system itself seems to be higher than to the native IPv6 Internet.
したがって、6to4 リレー システム自体の可用性と安定性に対する脅威は、ネイティブ IPv6 インターネットに対する脅威よりも高いと思われます。
This attack is similar to the ones employed against 6to4 routers, as described in Section 4.1.4. There are slight differences with regard to the source of the attacks. This attack can be initiated by:
この攻撃は、セクション 4.1.4 で説明されているように、6to4 ルーターに対して使用される攻撃に似ています。攻撃のソースに関しては若干の違いがあります。この攻撃は以下によって開始される可能性があります。
o native IPv6 nodes that may send traffic to the relay's subnet broadcast address, and
o リレーのサブネット ブロードキャスト アドレスにトラフィックを送信するネイティブ IPv6 ノード、および
o IPv4 nodes that may send traffic with a spoofed source IP address (to be the relay's broadcast address) to elicit replies (e.g., ICMPv6 Hop Limit Exceeded) from the 6to4 relay to its local nodes.
o IPv4 ノードは、6to4 リレーからローカル ノードへの応答 (ICMPv6 ホップ制限超過など) を引き出すために、スプーフィングされた送信元 IP アドレス (リレーのブロードキャスト アドレスとなる) を使用してトラフィックを送信する可能性があります。
The first approach is more dangerous than those in Section 4.1.4 because it can be initiated by any IPv6 node (allowed to use the relay); the approach is not limited to local users.
最初のアプローチは、任意の IPv6 ノード (リレーの使用が許可されている) によって開始できるため、セクション 4.1.4 のアプローチよりも危険です。このアプローチはローカル ユーザーに限定されません。
The second approach is trickier and not really useful. For it to succeed, the relay would have to accept native source addresses over the 6to4 pseudo-interface (we did not assume this check was implemented), as if coming from another relay, triggering an ICMPv6 message to the relay's local IPv4 subnet. The former method is more lucrative.
2 番目のアプローチはより複雑で、あまり役に立ちません。これが成功するには、リレーは、あたかも別のリレーから来たかのように、6to4 擬似インターフェイス (このチェックが実装されていることを想定していませんでした) を介してネイティブ ソース アドレスを受け入れ、リレーのローカル IPv4 サブネットへの ICMPv6 メッセージをトリガーする必要があります。前者の方法の方が儲かります。
EXTENSIONS
拡張機能
None.
なし。
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
脅威の分析と解決策/軽減方法
The threat is restricted to the relay's local subnet and is fixed by tightening the 6to4 security checks.
この脅威はリレーのローカル サブネットに限定されており、6to4 セキュリティ チェックを強化することで修正されています。
COMPARISON TO SITUATION WITHOUT 6to4
6to4のない状況との比較
This scenario is caused by 6to4, but fortunately the issue is not serious.
このシナリオは 6to4 が原因で発生しますが、幸いなことに問題は深刻ではありません。
ATTACK DESCRIPTION
攻撃の説明
The 6to4 relay administrators would often want to use some policy to limit the use of the relay to specific 6to4 sites and/or specific IPv6 sites.
6to4 リレー管理者は、多くの場合、何らかのポリシーを使用して、リレーの使用を特定の 6to4 サイトや特定の IPv6 サイトに制限したいと考えます。
The policy control is usually enacted by applying restrictions to where the routing information for 2002::/16 and/or 192.188.99.0/24 (if the anycast address used [3]) will spread.
ポリシー制御は通常、2002::/16 および/または 192.188.99.0/24 (エニーキャスト アドレス [3] が使用されている場合) のルーティング情報が拡散する場所に制限を適用することによって制定されます。
Some users may be able to use the service regardless of these controls, by
一部のユーザーは、次の方法により、これらの制御に関係なくサービスを使用できる場合があります。
o configuring the address of the relay using its IPv4 address instead of 192.88.99.1, or
o 192.88.99.1 の代わりに IPv4 アドレスを使用してリレーのアドレスを構成する、または
o using the routing header to route IPv6 packets to reach specific 6to4 relays. (Other routing tricks, such as using static routes, may also be used.)
o ルーティング ヘッダーを使用して IPv6 パケットをルーティングし、特定の 6to4 リレーに到達します。(静的ルートの使用など、他のルーティング手法も使用される場合があります。)
EXTENSIONS
拡張機能
None.
なし。
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
脅威の分析と解決策/軽減方法
Attempts to use the relay's IPv4 address instead of 192.88.99.1 can be mitigated in the following ways:
192.88.99.1 の代わりにリレーの IPv4 アドレスを使用しようとする試みは、次の方法で軽減できます。
1. IPv4 domains should prevent use of the actual IPv4 address of the relay instead of 192.88.99.1.
1. IPv4 ドメインでは、192.88.99.1 の代わりにリレーの実際の IPv4 アドレスを使用しないようにする必要があります。
2. Usage of access lists in the 6to4 relay to limit access. This is only feasible if the number of IP networks the relay is supposed to serve is relatively low.
2. アクセスを制限するための 6to4 リレーでのアクセス リストの使用。これは、リレーがサービスを提供する IP ネットワークの数が比較的少ない場合にのみ実現可能です。
3. The 6to4 relay should filter out arriving tunneled packets with protocol 41 (IPv6) that do not have 192.88.99.1 as the destination address.
3. 6to4 リレーは、宛先アドレスとして 192.88.99.1 を持たない、プロトコル 41 (IPv6) で到着するトンネルパケットをフィルターで除外する必要があります。
The other threat, of using routing tricks in the IPv6 networks to reach the 6to4 relay, has similar solutions:
もう 1 つの脅威は、IPv6 ネットワークでルーティング トリックを使用して 6to4 リレーに到達するというもので、同様の解決策があります。
1. Usage of access lists in the relay to limit access.
1. アクセスを制限するためのリレー内のアクセス リストの使用。
2. Filtering out the packets with a routing header (although this may have other implications).
2. ルーティング ヘッダーを持つパケットをフィルターで除外します (ただし、これには他の影響がある可能性があります)。
3. Monitoring the source addresses going through the relay to detect, e.g., peers setting up static routes.
3. リレーを通過する送信元アドレスを監視して、静的ルートを設定しているピアなどを検出します。
Routing Header is not specific to 6to4. The main thing one could do with it here would be to select the relay. Some generic threats about routing header use are described in [11].
ルーティング ヘッダーは 6to4 に固有のものではありません。ここで行うことができる主な作業は、リレーを選択することです。ルーティングヘッダーの使用に関するいくつかの一般的な脅威については、[11] で説明されています。
As this threat does not have implications for anything other than the organization providing 6to4 relay, it is not analyzed any further.
この脅威は 6to4 リレーを提供する組織以外には影響を及ぼさないため、これ以上分析されません。
COMPARISON TO SITUATION WITHOUT 6to4
6to4のない状況との比較
These threats are specific to 6to4 relays (or in general anycast services) and do not exist in networks without 6to4.
これらの脅威は 6to4 リレー (または一般的なエニーキャスト サービス) に特有であり、6to4 のないネットワークには存在しません。
ATTACK DESCRIPTION
攻撃の説明
Several attacks use 6to4 relays to anonymize the traffic; this often results in packets being tunneled from the relay to a supposedly-6to4 site.
いくつかの攻撃では、6to4 リレーを使用してトラフィックを匿名化します。これにより、パケットがリレーから 6to4 サイトと思われるサイトにトンネリングされることがよくあります。
However, as was pointed out in Section 4.2, the IPv4 source address used by the relay could, on a cursory look, be seen as the source of these "protocol-41" attacks.
ただし、セクション 4.2 で指摘したように、リレーで使用される IPv4 送信元アドレスは、ざっと見ただけでは、これらの「プロトコル 41」攻撃の送信元であると見なすことができます。
This could cause a number of concerns for the operators deploying 6to4 relay service, including the following:
これにより、6to4 リレー サービスを展開する通信事業者に次のような多くの懸念が生じる可能性があります。
o being contacted a lot (via email, phone, fax, or lawyers) on suspected "abuse",
o 「虐待」の疑いで頻繁に（電子メール、電話、ファックス、または弁護士経由で）連絡を受けている、
o having the whole IPv4 address range rejected as a source of abuse or spam, causing outage to other operations as well, or
o IPv4 アドレス範囲全体が不正行為またはスパムの送信元として拒否され、他の操作も停止する可能性があります。
o causing the whole IPv4 address range to be blacklisted in some "spammer databases", if the relay were used for those purposes.
o リレーがこれらの目的で使用された場合、一部の「スパマー データベース」で IPv4 アドレス範囲全体がブラックリストに登録されることになります。
This threat seems slightly similar to the outburst of SMTP abuse caused by open relays but is more generic.
この脅威は、オープンリレーによって引き起こされる SMTP 悪用の爆発に少し似ているように見えますが、より一般的です。
EXTENSIONS
拡張機能
None.
なし。
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
脅威の分析と解決策/軽減方法
This problem can be avoided (or, really, "made someone else's problem") by using the 6to4 anycast address in 192.88.99.0/24 as the source address. Blacklisting or rejecting this should not cause problems to the other operations.
この問題は、送信元アドレスとして 192.88.99.0/24 の 6to4 エニーキャスト アドレスを使用することで回避できます (または、実際には「他人事にする」) ことができます。これをブラックリストに登録したり拒否したりしても、他の操作に問題が生じることはありません。
Further, when someone files complaints to the owner of 192.88.99.0/24, depending on which registry they are querying, they might get, for example:
さらに、誰かが 192.88.99.0/24 の所有者に苦情を提出すると、クエリしているレジストリに応じて、たとえば次のようなメッセージが表示される可能性があります。
o knowledge that this is a special IANA address block, with no real contact person,
o これが特別な IANA アドレス ブロックであり、実際の連絡担当者が存在しないことを知っていて、
o knowledge that this is a special address block for RFC 3068, or
o これが RFC 3068 の特別なアドレス ブロックであることを知っている、または
o knowledge that this is a special address block for RFC 3068, and that there are multiple entries by relay operators in the database.
o これは RFC 3068 の特別なアドレス ブロックであり、データベースにはリレー オペレーターによる複数のエントリがあることを知っています。
Any of these, at least when processed by a human, should show that the 6to4 relay is in fact innocent. Of course, this could result in reports going to the closest anycast 6to4 relay as well, which had nothing to do with the incident.
これらのいずれも、少なくとも人間によって処理された場合、6to4 リレーが実際には無害であることを示すはずです。もちろん、これにより、インシデントとは何の関係もない、最も近いエニーキャスト 6to4 リレーにもレポートが送信される可能性があります。
However, the widespread usage of 192.88.99.1 as the source address may make it more difficult to disambiguate the relays, which might be a useful feature for debugging purposes.
ただし、送信元アドレスとして 192.88.99.1 が広く使用されているため、リレーを明確にすることがより困難になる可能性があり、これはデバッグ目的で役立つ機能となる可能性があります。
COMPARISON TO SITUATION WITHOUT 6to4
6to4のない状況との比較
This threat is caused by 6to4 deployment but can be avoided, at least in the short-term, by using 192.88.99.1 as the source address.
この脅威は 6to4 展開によって引き起こされますが、送信元アドレスとして 192.88.99.1 を使用することで、少なくとも短期的には回避できます。
There are two types of attacks on the IPv4 internet - spoofed traffic, and reflection. These can be initiated by native IPv6 nodes, 6to4 nodes, and IPv4 nodes.
IPv4 インターネットには、スプーフィング トラフィックとリフレクションという 2 種類の攻撃があります。これらは、ネイティブ IPv6 ノード、6to4 ノード、および IPv4 ノードによって開始できます。
Attacks initiated by IPv4 nodes that send spoofed traffic, which would not use the 6to4 infrastructure, are considered out of the scope of this document. 6to4 infrastructure may be used in reflection attacks initiated by IPv4 nodes.
6to4 インフラストラクチャを使用しない、なりすましトラフィックを送信する IPv4 ノードによって開始される攻撃は、このドキュメントの範囲外とみなされます。6to4 インフラストラクチャは、IPv4 ノードによって開始されるリフレクション攻撃に使用される可能性があります。
It is difficult for these attacks to be effective, as the traffic sent out will be IPv6-in-IPv4. Such traffic will be rejected by most IPv4 nodes unless they have implemented some sort of IPv6-in-IPv4 tunneling.
送信されるトラフィックは IPv6-in-IPv4 であるため、これらの攻撃が効果的であることは困難です。このようなトラフィックは、何らかの IPv6-in-IPv4 トンネリングを実装していない限り、ほとんどの IPv4 ノードによって拒否されます。
Columns:
列:
o Section number. The section that describes the attack.
o セクション番号。攻撃について説明するセクション。
o Attack name.
o 攻撃名。
o Initiator. The node that initiates the attack.
o イニシエータ。攻撃を開始するノード。
* I_4 - IPv4 node
* I_4 - IPv4 ノード
* I_6 - native IPv6 node
* I_6 - ネイティブ IPv6 ノード
* 6to4 - 6to4 node
* 6to4 - 6to4 ノード
* * - All of the above
o Victim. The victim node
o 被害者。被害者ノード
* I_4 - IPv4 node
* I_4 - IPv4 ノード
* I_6 - native IPv6 node
* I_6 - ネイティブ IPv6 ノード
* 6to4 - 6to4 node
* 6to4 - 6to4 ノード
* Relay - 6to4 relay
* リレー - 6to4 リレー
* Router - 6to4 router
* ルーター - 6to4 ルーター
o ToA. Type of Attack
o へA。攻撃の種類
* D - DoS
* D - サービス妨害
* R - Reflection DoS
* R - リフレクション DoS
* T - Theft of Service
* T - サービスの盗難
o Fix. Specified who is responsible for fixing the attack.
o 修理。攻撃を修正する責任者を指定します。
* 6 - The 6to4 developer and/or operator can completely mitigate this attack.
* 6 - 6to4 開発者および/またはオペレーターは、この攻撃を完全に軽減できます。
* 6* - The 6to4 developer and/or operator can partially mitigate this attack.
* 6* - 6to4 開発者および/またはオペレーターは、この攻撃を部分的に軽減できます。
* E - This threat cannot be fixed by the 6to4 developer or the 6to4 operator.
* E - この脅威は 6to4 開発者または 6to4 オペレーターによって修正できません。
Summary of attacks on a 6to4 network:
6to4 ネットワークに対する攻撃の概要:
+-------+----------------------+---------+----------+-----+-----+
| Sec | Attack name |Initiator| Victim | ToA | Fix |
+-------+----------------------+---------+----------+-----+-----+
| 4.1.1 | Attacks with ND | I_4 | Router | D | 6 |
+-------+----------------------+---------+----------+-----+-----+
| 4.1.2 | Spoofing Traffic | I_4,I_6 | 6to4 | D | E |
+-------+----------------------+---------+----------+-----+-----+
| 4.1.3 | Reflection Attacks | * | 6to4 | R | 6* |
+-------+----------------------+---------+----------+-----+-----+
| 4.1.4 | Local IPv4 Broadcast | * | Router | D | 6 |
+-------+----------------------+---------+----------+-----+-----+
Figure 9
図9
Summary of attacks on the native IPv6 internet:
ネイティブ IPv6 インターネットに対する攻撃の概要:
+-------+----------------------+---------+----------+-----+-----+
| Sec | Attack name |Initiator| Victim | ToA | Fix |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.1 | Attacks with ND | I_4 | Relay | D | 6 |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.2 | Spoofing Traffic | I_4,6to4| I_6 | D | 6* |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.3 | Reflection Attacks | * | I_6 | R | 6* |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.4 | Local IPv4 Broadcast | * | Relay | D | 6 |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.5 | Theft of Service | 6to4 | Relay | T | 6 |
+-------+----------------------+---------+----------+-----+-----+
| 4.2.6 | Relay Operators ... | - | - | D | 1) |
+-------+----------------------+---------+----------+-----+-----+
Figure 10
図10
Notes:
ノート：
1) This attack is a side-effect of the other attacks and thus does not have any Initiator, Victim, and Fix. It is a Denial of Service attack not on the network but on the organization in-charge of the relay.
1) この攻撃は他の攻撃の副作用であるため、開始者、被害者、修正はありません。これはネットワークではなく、中継を担当する組織に対するサービス妨害攻撃です。
Summary of attacks on IPv4 internet:
IPv4 インターネットに対する攻撃の概要:
+-------+----------------------+---------+----------+-----+-----+
| Sec | Attack name |Initiator| Victim | ToA | Fix |
+-------+----------------------+---------+----------+-----+-----+
| 4.3 | Spoofing Traffic | * | I_4 | D | 6* |
+-------+----------------------+---------+----------+-----+-----+
| 4.3 | Reflection Attacks | * | I_4 | R | 6* |
+-------+----------------------+---------+----------+-----+-----+
Figure 11
図11
This section describes several ways to implement the security checks required or implied by the specification [1] or augmented by this memo. These do not, in general, protect against most of the threats listed above in the "Threat Analysis" section. They are only prerequisites for a relatively safe and simple 6to4 implementation.
このセクションでは、仕様 [1] で要求または暗示される、またはこのメモで強化されるセキュリティ チェックを実装するためのいくつかの方法について説明します。これらは一般に、上記の「脅威分析」セクションにリストされているほとんどの脅威から保護するものではありません。これらは、比較的安全でシンプルな 6to4 実装の前提条件にすぎません。
Note that, in general, the 6to4 router or relay does not know whether it is acting as a router or relay. It would be possible to include a toggle to specify the behaviour, to be used when, e.g., the interface is brought up, but as of February 2004, no implementations were known to do that. Therefore, the checks are described as that which works independently of whether the node is a router or relay.
一般に、6to4 ルーターまたはリレーは、ルーターまたはリレーとして機能しているかどうかを認識しないことに注意してください。たとえばインターフェースが起動されたときに使用される動作を指定するトグルを組み込むことは可能ですが、2004 年 2 月の時点では、それを行う実装は知られていませんでした。したがって、チェックは、ノードがルーターであるかリレーであるかに関係なく機能するものとして説明されています。
The checks described in this section are to be performed when encapsulating IPv6 into IPv4.
このセクションで説明するチェックは、IPv6 を IPv4 にカプセル化するときに実行されます。
The encapsulation rules are mainly designed to keep implementors from "shooting themselves in the foot." For example, the source address check would verify that the packet will be acceptable to the decapsulator, or the sanity checks would ensure that addresses derived from private addresses are not used (which would be equally unacceptable).
カプセル化ルールは主に、実装者が「自らの足を撃つ」ことを防ぐように設計されています。たとえば、送信元アドレス チェックでは、パケットがカプセル化解除装置に受け入れられるかどうかが確認されます。また、サニティ チェックでは、プライベート アドレスから派生したアドレスが使用されていないことが確認されます (これも同様に受け入れられません)。
src_v6 and dst_v6 MUST pass ipv6-sanity checks (see below) else drop
if prefix (src_v6) == 2002::/16
ipv4 address embedded in src_v6 MUST match src_v4
else if prefix (dst_v6) == 2002::/16
dst_v4 SHOULD NOT be assigned to the router
else
drop
/* we somehow got a native-native ipv6 packet */
fi
accept
The checks described in this section are to be performed when decapsulating IPv4 into IPv6. They will be performed in both the 6to4 router and relay.
このセクションで説明するチェックは、IPv4 を IPv6 にカプセル化解除するときに実行されます。これらは 6to4 ルーターとリレーの両方で実行されます。
src_v4 and dst_v4 MUST pass ipv4-sanity checks, else drop src_v6 and dst_v6 MUST pass ipv6-sanity checks, else drop if prefix (dst_v6) == 2002::/16 ipv4 address embedded in dst_v6 MUST match dst_v4 if prefix (src_v6) == 2002::/16 ipv4 address embedded in src_v6 MUST match src_v4 dst_v4 SHOULD be assigned to the router fi elif prefix (src_v6) == 2002::/16 ipv4 address embedded in src_v6 MUST match src_v4 dst_v4 SHOULD be assigned to the router (see notes below)
src_v4 と dst_v4 は ipv4 健全性チェックに合格しなければなりません。そうでない場合、src_v6 と dst_v6 は ipv6 健全性チェックに合格しなければなりません。そうでない場合はドロップします。プレフィックス (dst_v6) == 2002::/16 dst_v6 に埋め込まれた ipv4 アドレスは、プレフィックス (src_v6) = の場合、dst_v4 と一致しなければなりません。= 2002::/16 src_v6 に埋め込まれた ipv4 アドレスは、src_v4 と一致しなければなりません。 dst_v4 はルータ フィールドに割り当てられるべきです (SHOULD) プレフィックス (src_v6) == 2002::/16 src_v6 に埋め込まれる ipv4 アドレスは、src_v4 と一致しなければなりません。 dst_v4 はルータに割り当てられるべきです (以下の注を参照してください)
else
drop
/* the we somehow got a native-native ipv6 packet */
fi
accept
The encapsulation and decapsulation checks include certain sanity checks for both IPv4 and IPv6. These are described here in detail.
カプセル化チェックとカプセル化解除チェックには、IPv4 と IPv6 の両方に対する特定の健全性チェックが含まれます。これらについては、ここで詳しく説明します。
IPv4 address MUST be a global unicast address, as required by the 6to4 specification. The disallowed addresses include those defined in [14], and others widely used and known not to be global. These are
IPv4 アドレスは、6to4 仕様で要求されているように、グローバル ユニキャスト アドレスでなければなりません。許可されていないアドレスには、[14] で定義されているアドレスや、広く使用されているがグローバルではないことが知られているその他のアドレスが含まれます。これらは
o 0.0.0.0/8 (the system has no address assigned yet)
o 0.0.0.0/8 (システムにはまだアドレスが割り当てられていません)
o 10.0.0.0/8 (private)
o 10.0.0.0/8 (プライベート)
o 127.0.0.0/8 (loopback)
o 127.0.0.0/8 (ループバック)
o 172.16.0.0/12 (private)
o 172.16.0.0/12 (プライベート)
o 192.168.0.0/16 (private)
o 192.168.0.0/16 (プライベート)
o 169.254.0.0/16 (IANA Assigned DHCP link-local)
o 169.254.0.0/16 (IANA 割り当て DHCP リンクローカル)
o 224.0.0.0/4 (multicast)
o 224.0.0.0/4 (マルチキャスト)
o 240.0.0.0/4 (reserved and broadcast)
o 240.0.0.0/4 (予約およびブロードキャスト)
In addition, the address MUST NOT be any of the system's broadcast addresses. This is especially important if the implementation is made so that it can
さらに、アドレスはシステムのブロードキャスト アドレスであってはなりません。これは、次のような実装が行われる場合に特に重要です。
o receive and process encapsulated IPv4 packets arriving at its broadcast addresses, or
o ブロードキャスト アドレスに到着するカプセル化された IPv4 パケットを受信して処理する、または
o send encapsulated IPv4 packets to one of its broadcast addresses.
o カプセル化された IPv4 パケットをブロードキャスト アドレスの 1 つに送信します。
IPv6 address MUST NOT be
IPv6 アドレスは使用できません
o 0::/16 (compatible, mapped addresses, loopback, unspecified, ...)
o 0::/16 (互換性、マップされたアドレス、ループバック、未指定など)
o fe80::/10 (link-local)
o fe80::/10 (リンクローカル)
o fec0::/10 (site-local)
o fec0::/10 (サイトローカル)
o ff00::/8 (any multicast)
o ff00::/8 (任意のマルチキャスト)
Note: Only link-local multicast would be strictly required, but it is believed that multicast with 6to4 will not be feasible, so it has been disallowed as well.
注: リンクローカル マルチキャストのみが厳密に必要ですが、6to4 でのマルチキャストは実現不可能であると考えられているため、同様に禁止されています。
In addition, it MUST be checked that equivalent 2002:V4ADDR::/48 checks, where V4ADDR is any of the above IPv4 addresses, will not be passed.
さらに、同等の 2002:V4ADDR::/48 チェック (V4ADDR は上記の IPv4 アドレスのいずれか) がパスしないことを確認しなければなりません。
In addition, the implementation in the 6to4 router may perform some form of ingress filtering (e.g., Unicast Reverse Path Forwarding checks). For example, if the 6to4 router has multiple interfaces, of which some are "internal", receiving either IPv4 or IPv6 packets with source address belonging to any of these internal networks from the Internet might be disallowed.
さらに、6to4 ルーターの実装では、何らかの形式のイングレス フィルタリング (ユニキャスト リバース パス転送チェックなど) を実行する場合があります。たとえば、6to4 ルーターに複数のインターフェイスがあり、その一部が「内部」である場合、これらの内部ネットワークのいずれかに属する送信元アドレスを持つ IPv4 または IPv6 パケットをインターネットから受信することは許可されない可能性があります。
If these checks are implemented and enabled by default, it's recommended that there be a toggle to disable them if needed.
これらのチェックがデフォルトで実装され有効になっている場合は、必要に応じて無効にするトグルを用意することをお勧めします。
The rule "dst_v4 SHOULD be assigned to the router" is not needed if the 6to4 router implementation only accepts and processes encapsulated IPv4 packets arriving to its unicast IPv4 addresses, and when the destination address is known to be a local broadcast address, it does not try to encapsulate and send packets to it. (See Sections 4.1.4 and 4.2.4 about this threat.)
6to4 ルーター実装がユニキャスト IPv4 アドレスに到着するカプセル化された IPv4 パケットのみを受け入れて処理する場合、および宛先アドレスがローカル ブロードキャスト アドレスであることがわかっている場合は、ルール「dst_v4 をルーターに割り当てる必要がある」は必要ありません。パケットをカプセル化して送信してみます。(この脅威については、セクション 4.1.4 および 4.2.4 を参照してください。)
Some checks, especially the IPv4/IPv6 Sanity Checks, could be at least partially implementable with system-level access lists, if one would like to avoid placing too many restrictions in the 6to4 implementation itself. This depends on how many hooks are in place for the access lists. In practice, it seems that this could not be done effectively enough unless the access list mechanism is able to parse the encapsulated packets.
一部のチェック、特に IPv4/IPv6 健全性チェックは、6to4 実装自体に多大な制限を課すことを避けたい場合、システム レベルのアクセス リストを使用して少なくとも部分的に実装できる可能性があります。これは、アクセス リストに設定されているフックの数によって異なります。実際には、アクセス リスト メカニズムがカプセル化されたパケットを解析できない限り、これを十分に効果的に行うことはできないようです。
This section tries to give an overview of some of the problems 6to4 implementations face, and the kind of generic problems the 6to4 users could come up with.
このセクションでは、6to4 の実装が直面するいくつかの問題の概要と、6to4 ユーザーが遭遇する可能性のある一般的な問題の種類について説明します。
There is a problem with multiple transition mechanisms if strict security checks are implemented. This may vary a bit from implementation to implementation.
厳格なセキュリティチェックが実装されている場合、複数の移行メカニズムに問題が発生します。これは実装ごとに多少異なる場合があります。
Consider three mechanisms using automatic tunneling: 6to4, ISATAP [15], and Automatic Tunneling using Compatible Addresses [4] (currently removed [10] but typically still supported). All of these use IP-IP (protocol 41) [16] IPv4 encapsulation with, more or less, a pseudo-interface.
自動トンネリングを使用する 3 つのメカニズムを検討してください。6to4、ISATAP [15]、互換アドレスを使用した自動トンネリング [4] (現在は削除されています [10] ですが、通常はまだサポートされています)。これらはすべて、多かれ少なかれ擬似インターフェイスを備えた IP-IP (プロトコル 41) [16] IPv4 カプセル化を使用します。
When a router, which has any two of these enabled, receives an IPv4 encapsulated IPv6 packet
これらのいずれか 2 つが有効になっているルータが、IPv4 でカプセル化された IPv6 パケットを受信すると
src_v6 = 2001:db8::1
dst_v6 = 2002:1010:1010::2
src_v4 = 10.0.0.1
dst_v4 = 20.20.20.20
What can it do? How should it decide which transition mechanism this belongs to; there is no "transition mechanism number" in the IPv6 or IPv4 header to signify this. (This can also be viewed as a flexibility benefit.)
何ができるのでしょうか？これがどの移行メカニズムに属するかをどのように決定すべきか。IPv6 または IPv4 ヘッダーには、これを示す「移行メカニズム番号」がありません。(これは柔軟性の利点とみなすこともできます。)
Without any kind of security checks (in any of the implemented methods), these often just "work", as the mechanisms aren't differentiated but handled in "one big lump".
メカニズムが区別されず「1 つの大きな塊」として処理されるため、(実装されたメソッドのいずれにおいても) セキュリティ チェックの種類がなければ、これらは多くの場合単に「機能」します。
Configured tunneling [4] does not suffer from this, as it is point-to-point and based on src_v6/dst_v6 pairs of both IPv4 and IPv6 addresses, so the tunnel interface can be logically deduced.
構成されたトンネリング [4] は、ポイントツーポイントであり、IPv4 アドレスと IPv6 アドレスの両方の src_v6/dst_v6 ペアに基づいているため、この影響を受けず、トンネル インターフェイスを論理的に推定できます。
Solutions for this include 1) not using more than one automatic tunneling mechanism in a node and 2) binding different mechanisms to different IPv4 addresses.
この問題の解決策には、1) ノード内で複数の自動トンネリング メカニズムを使用しないこと、2) 異なるメカニズムを異なる IPv4 アドレスにバインドすることが含まれます。
Even though this was already discussed in Section 4.1.2, it bears some additional elaboration, as it was the only problem that cannot be even partially solved using the current deployment model. There are some mitigation methods.
これについてはセクション 4.1.2 ですでに説明しましたが、現在の展開モデルを使用しても部分的にさえ解決できない唯一の問題であるため、さらに詳しく説明します。軽減方法はいくつかあります。
6to4 routers receive traffic from non-6to4 ("native") sources via 6to4 relays. 6to4 routers have no way of matching the IPv4 source address of the relay with the non-6to4 IPv6 address of the source. Consequently, anyone can spoof any non-6to4 IPv6 address by sending traffic, encapsulated, directly to 6to4 routers.
6to4 ルーターは、6to4 リレーを介して非 6to4 (「ネイティブ」) ソースからトラフィックを受信します。6to4 ルーターには、リレーの IPv4 送信元アドレスと送信元の非 6to4 IPv6 アドレスを照合する方法がありません。その結果、カプセル化されたトラフィックを 6to4 ルーターに直接送信することで、誰でも 6to4 以外の IPv6 アドレスをなりすますことができます。
It could be possible to turn the deployment assumptions of 6to4 around a bit to eliminate some threats caused by untrusted 6to4 relays:
6to4 の展開の前提を少し変えて、信頼できない 6to4 リレーによって引き起こされるいくつかの脅威を排除することが可能である可能性があります。
o Every dual-stack site (or even ISP) would be required to have its own 6to4 relay. (This assumes that IPv6-only is so far away that 6to4 would be retired by that point.) That is, there would not be third-party relays, and 2002::/16 and 192.88.99.0/24 routes would not need to be advertised globally.
o すべてのデュアル スタック サイト (または ISP) には独自の 6to4 リレーが必要です。(これは、IPv6 のみが実現するのはかなり先のことで、その時点までに 6to4 が廃止されることを前提としています。) つまり、サードパーティのリレーは存在せず、2002::/16 および 192.88.99.0/24 ルートは、そのリレーを行う必要がありません。世界中で宣伝される。
o The security implications of 6to4 use could be pushed back to the level of trust inside the site or ISP (or their acceptable use policies). This is something that the sites and ISPs should already be familiar with already.
o 6to4 の使用によるセキュリティへの影響は、サイトまたは ISP (またはその許容使用ポリシー) 内の信頼レベルにまで押し戻される可能性があります。これは、サイトと ISP がすでによく知っていることです。
However, this presents a number of problems:
ただし、これには次のような多くの問題が生じます。
This model would shift most of the burden of supporting 6to4 to IPv6 sites that don't employ or use 6to4 at all, i.e., "those who deploy proper native dual-stack." It could be argued that the deployment pain should be borne by 6to4 users, not by the others.
このモデルは、6to4 をサポートする負担の大部分を、6to4 を採用またはまったく使用していない IPv6 サイト、つまり「適切なネイティブ デュアル スタックを展開しているサイト」に移すことになります。導入の苦労は他のユーザーではなく、6to4 ユーザーが負担すべきであると主張する人もいるかもしれません。
The main advantage of 6to4 is easy deployment and free relays. This would require that everyone the 6to4 sites wish to communicate with implement these measures.
6to4 の主な利点は、展開が簡単で中継が無料であることです。これには、6to4 サイトが通信したい全員がこれらの措置を実装する必要があります。
The model would not fix the "relay spoofing problem", unless everybody also deployed 6to4 addresses on the nodes (alongside with native addresses, if necessary), which would in turn change 6to4 to operate without relays completely.
このモデルでは、全員がノード上に 6to4 アドレスを (必要に応じてネイティブ アドレスとともに) 展開しない限り、「リレー スプーフィング問題」は解決されません。これにより、6to4 が完全にリレーなしで動作するように変更されます。
This document discusses security considerations of 6to4.
この文書では、6to4 のセキュリティに関する考慮事項について説明します。
Even if proper checks are implemented, there are a large number of different security threats; these threats are analyzed in Section 4.
たとえ適切なチェックが実装されていたとしても、さまざまなセキュリティ上の脅威が多数存在します。これらの脅威はセクション 4 で分析されます。
There are mainly four classes of potential problem sources:
潜在的な問題の原因には主に 4 つのクラスがあります。
1. 6to4 routers not being able to identify whether relays are legitimate
1. 6to4 ルーターはリレーが正当なものかどうかを識別できない
2. Wrong or impartially implemented 6to4 router or relay security checks
2. 6to4 ルーターまたはリレーのセキュリティ チェックが間違っているか、公平に実装されていない
3. 6to4 architecture used to participate in DoS or reflected DoS attacks or made to participate in "packet laundering", i.e., making another attack harder to trace
3. 6to4 アーキテクチャは、DoS 攻撃または反射型 DoS 攻撃に参加するために使用され、または「パケット ロンダリング」に参加するために使用されます。つまり、別の攻撃の追跡が困難になります。
4. 6to4 relays being subject to "administrative abuse" e.g., theft of service or being seen as a source of abuse.
4. 6to4 リレーは、サービスの盗難や悪用の原因とみなされているなど、「管理上の悪用」の対象となっています。
The first is the toughest problem, still under research. The second can be fixed by ensuring the correctness of implementations; this is important. The third is also a very difficult problem, impossible to solve completely; therefore it is important to be able to analyze whether this results in a significant increase of threats. The fourth problem seems to have feasible solutions.
1 つ目は最も困難な問題ですが、まだ研究中です。2 番目の問題は、実装の正確性を確保することで修正できます。これは重要。3 番目も非常に難しい問題であり、完全に解決することは不可能です。したがって、これが脅威の大幅な増加につながるかどうかを分析できることが重要です。4 番目の問題には、実行可能な解決策があるようです。
These are analyzed in detail in "Threat Analysis", in Section 4.
これらは、セクション 4 の「脅威分析」で詳細に分析されます。
Some issues were first brought up by Itojun Hagino in [17], and Alain Durand introduced one specific problem at IETF51 in August 2001 (though there was some discussion on the list prior to that); these two gave the authors the push to start looking into the details of securing 6to4.
いくつかの問題は [17] で萩野糸純によって初めて提起され、Alain Durand は 2001 年 8 月の IETF51 で 1 つの特定の問題を紹介しました (ただし、その前にリストについてはいくつかの議論がありました)。この 2 つのおかげで、著者は 6to4 のセキュリティ保護の詳細を検討し始めるようになりました。
Alexey Kuznetsov brought up the implementation problem with IPv6 martian checks. Christian Huitema formulated the rules that rely on 6to4 relays using only anycast. Keith Moore brought up the point about reduced flexibility. Brian Carpenter, Tony Hain, and Vladislav Yasevich are acknowledged for lengthy discussions. Alain Durand reminded the authors about relay spoofing problems. Brian Carpenter reminded the authors about the BGP-based 6to4 router model. Christian Huitema gave a push for a more complete threat analysis. Itojun Hagino spelled out the operators' fears about 6to4 relay abuse. Rob Austein brought up the idea of a different 6to4 deployment model.
Alexey Kuznetsov は、IPv6 火星チェックの実装上の問題を提起しました。Christian Huitema は、エニーキャストのみを使用して 6to4 リレーに依存するルールを策定しました。Keith Moore は柔軟性の低下について指摘しました。ブライアン・カーペンター、トニー・ヘイン、ウラジスラフ・ヤセビッチは長時間にわたる議論で知られています。Alain Durand は、リレーのなりすましの問題について著者らに思い出させました。Brian Carpenter は、著者らに BGP ベースの 6to4 ルーター モデルについて思い出させました。Christian Huitema 氏は、より完全な脅威分析を推進しました。萩野糸純氏は、6to4 リレーの不正使用に対するオペレータの懸念を詳しく述べました。Rob Austein は、別の 6to4 導入モデルのアイデアを提案しました。
In the latter phase, discussions with Christian Huitema, Brian Carpenter, and Alain Durand were helpful when improving the document.
最後の段階では、文書を改善する際に、Christian Huitema、Brian Carpenter、Alain Durand との議論が役に立ちました。
David Malone, Iljitsch van Beijnum, and Tim Chown gave feedback on the document.
David Malone、Iljitsch van Beijnum、Tim Cown がこの文書についてフィードバックを提供しました。
[1] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[1] Carpenter, B. および K. Moore、「IPv4 クラウドを介した IPv6 ドメインの接続」、RFC 3056、2001 年 2 月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner, S.、「要件レベルを示すために RFC で使用するキーワード」、BCP 14、RFC 2119、1997 年 3 月。
[3] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[3] Huitema, C.、「6to4 リレー ルーターのエニーキャスト プレフィックス」、RFC 3068、2001 年 6 月。
[4] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000.
[4] Gilligan, R. および E. Nordmark、「IPv6 ホストおよびルーターの移行メカニズム」、RFC 2893、2000 年 8 月。
[5] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[5] IANA、「特殊用途の IPv4 アドレス」、RFC 3330、2002 年 9 月。
[6] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[6] Rekhter, Y. および T. Li、「ボーダー ゲートウェイ プロトコル 4 (BGP-4)」、RFC 1771、1995 年 3 月。
[7] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[7] Draves, R.、「インターネット プロトコル バージョン 6 (IPv6) のデフォルト アドレス選択」、RFC 3484、2003 年 2 月。
[8] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[8] Nikander, P.、Kempf, J.、および E. Nordmark、「IPv6 近隣探索 (ND) 信頼モデルと脅威」、RFC 3756、2004 年 5 月。
[9] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", Work in Progress, July 2004.
[9] Arkko, J.、Kempf, J.、Sommerfeld, B.、Zill, B.、および P. Nikander、「SEcure Neighbor Discovery (SEND)」、進行中の作業、2004 年 7 月。
[10] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", Work in Progress, September 2004.
[10] Nordmark, E. および R. Gilligan、「IPv6 ホストおよびルーターの基本移行メカニズム」、進行中の作業、2004 年 9 月。
[11] Savola, P., "Security of IPv6 Routing Header and Home Address Options", Work in Progress, March 2002.
[11] Savola, P.、「IPv6 ルーティング ヘッダーとホーム アドレス オプションのセキュリティ」、進行中の作業、2002 年 3 月。
[12] 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.
[12] Ferguson, P. および D. Senie、「ネットワーク イングレス フィルタリング: IP ソース アドレス スプーフィングを使用するサービス拒否攻撃の阻止」、BCP 38、RFC 2827、2000 年 5 月。
[13] Bellovin, S., Leech, M. and T. Taylor, "ICMP Traceback Messages", Work in Progress, February 2003.
[13] Bellovin, S.、Leech, M.、および T. Taylor、「ICMP トレースバック メッセージ」、進行中の作業、2003 年 2 月。
[14] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[14] Baker, F.、「IP バージョン 4 ルーターの要件」、RFC 1812、1995 年 6 月。
[15] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", Work in Progress, May 2004.
[15] Templin, F.、Gleeson, T.、Talwar, M.、D. Thaler、「サイト内自動トンネル アドレッシング プロトコル (ISATAP)」、進行中の作業、2004 年 5 月。
[16] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
[16] Simpson, W.、「IP トンネリングにおける IP」、RFC 1853、1995 年 10 月。
[17] Hagino, J., "Possible abuse against IPv6 transition technologies", Work in Progress, July 2000.
[17] ハギノ J.、「IPv6 移行テクノロジーに対する悪用の可能性」、進行中の作業、2000 年 7 月。
Here, a few trivial attack scenarios are outlined -- ones that are prevented by implementing checks listed in [1] or in section 6.
ここでは、いくつかの簡単な攻撃シナリオの概要を説明します。これらのシナリオは、[1] またはセクション 6 にリストされているチェックを実装することで防止されます。
When two 6to4 routers send traffic to each others' domains, the packet sent by RA to RB resembles the following:
2 つの 6to4 ルーターが互いのドメインにトラフィックを送信する場合、RA から RB に送信されるパケットは次のようになります。
src_v6 = 2002:0800:0001::aaaa
dst_v6 = 2002:0800:0002::bbbb
src_v4 = 8.0.0.1 (added when encapsulated to IPv4)
dst_v4 = 8.0.0.2 (added when encapsulated to IPv4)
When the packet is received by IPv4 stack on RB, it will be decapsulated so that only src_v6 and dst_v6 remain, as originally sent by RA:
パケットが RB 上の IPv4 スタックによって受信されると、パケットはカプセル化解除され、最初に RA によって送信されたように src_v6 と dst_v6 のみが残ります。
src_v6 = 2002:0800:0001::aaaa
dst_v6 = 2002:0800:0002::bbbb
As every other node is just one hop away (IPv6-wise) and the link-layer (IPv4) addresses are lost, this may open many possibilities for misuse.
他のすべてのノードは (IPv6 的に) わずか 1 ホップ離れており、リンク層 (IPv4) アドレスが失われるため、悪用の可能性が多くなる可能性があります。
As an example, unidirectional IPv6 spoofing is made trivial because nobody can check (without delving into IP-IP packets) whether the encapsulated IPv6 addresses were authentic. (With native IPv6, this can be done by, e.g., RPF-like mechanisms or access lists in upstream routers.)
一例として、カプセル化された IPv6 アドレスが本物かどうかを (IP-IP パケットを詳しく調査することなく) 誰もチェックできないため、一方向の IPv6 スプーフィングは簡単になります。(ネイティブ IPv6 では、これは、上流ルーターの RPF のようなメカニズムやアクセス リストによって実行できます。)
src_v6 = 2002:1234:5678::aaaa (forged)
dst_v6 = 2002:0800:0002::bbbb
src_v4 = 8.0.0.1 (added when encapsulated to IPv4)
dst_v4 = 8.0.0.2 (added when encapsulated to IPv4)
A similar attack with "src" being the native address is made possible, even with the security checks, by having the sender node pretend to be a 6to4 relay router.
「src」をネイティブ アドレスとする同様の攻撃は、送信側ノードが 6to4 リレー ルーターのふりをすることで、セキュリティ チェックがあっても可能になります。
More worries come into the picture if, e.g.,
たとえば、次のような場合には、さらに懸念が生じます。
src_v6 = ::ffff:[some trusted IPv4 in a private network]
src_v6/dst_v6 = ::ffff:127.0.0.1
src_v6/dst_v6 = ::1
src_v6/dst_v6 = ...
Some implementations might have been careful enough to design the stack so as to avoid the incoming (or reply) packets going to IPv4 packet processing through special addresses (e.g., IPv4-mapped addresses), but who can say for all ...
一部の実装では、受信 (または応答) パケットが特別なアドレス (IPv4 マップされたアドレスなど) を介して IPv4 パケット処理に送られることを回避するようにスタックを設計するのに十分な注意を払っていたかもしれませんが、誰がすべてについて言えるでしょうか...
Authors' Addresses
著者の住所
Pekka Savola CSC/FUNET Espoo Finland
ペッカ サヴォラ CSC/FUNET エスポー フィンランド
EMail: psavola@funet.fi
Chirayu Patel All Play, No Work 185, Defence Colony Bangalore, Karnataka 560038 India
Chirayu Patel All Play, No Work 185, Defence Colony Bangalore, Karnataka インド 560038
Phone: +91-98452-88078
EMail: chirayu@chirayu.org
URI: http://www.chirayu.org
Full Copyright Statement
完全な著作権に関する声明
Copyright (C) The Internet Society (2004).
著作権 (C) インターネット協会 (2004)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78 に含まれる権利、ライセンス、および制限の対象となり、そこに規定されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書およびここに含まれる情報は「現状のまま」で提供され、寄稿者、寄稿者が代表または後援する組織（存在する場合）、インターネット協会およびインターネット エンジニアリング タスク フォースは、明示的または明示的または明示的に、すべての保証を否認します。ここに記載された情報の使用がいかなる権利も侵害しないことの黙示的な保証、または商品性や特定の目的への適合性の黙示的な保証を含みますが、これに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF は、本書に記載されているテクノロジの実装または使用に関連すると主張される知的財産権またはその他の権利の有効性や範囲、あるいはそのような権利に基づくライセンスが適用されるかどうかの範囲に関して、いかなる立場も負いません。利用可能であること。また、そのような権利を特定するために独自の努力を行ったことを示すものでもありません。IETF 文書の権利に関する IETF の手順に関する情報は、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 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ (http://www.ietf.org/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 (ietf-ipr@ietf.org) に送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC エディター機能の資金は現在、インターネット協会によって提供されています。