RFC3964 日本語訳
3964 Security Considerations for 6to4. P. Savola, C. Patel. December 2004. (Format: TXT=83360 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Savola
Request for Comments: 3964 CSC/FUNET
Category: Informational C. Patel
All Play, No Work
December 2004
Savolaがコメントのために要求するワーキンググループP.をネットワークでつないでください: 3964年のCSC/FUNETカテゴリ: 情報のC.パテルは仕事2004年12月がないのにすべてプレーしません。
Security Considerations for 6to4
6to4のためのセキュリティ問題
Status of this Memo
この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).
Copyright(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ネットワークとインタコネクトするためにトンネルを堀りながら、自動IPv6過剰IPv4を使用します。 アーキテクチャは6to4ルータと6to4リレールータ、どれが受け入れるか、そして、およびdecapsulate IPv4プロトコル-41を含んでいます。(「IPv4"のIPv6) あらゆるノードから、IPv4インターネットで取引してください。」 この特性は多くの軍事的脅威、主にサービス妨害を可能にします。 また、それで、ノードがIPv6にアドレスを偽造するのが、より簡単になります。 このドキュメントは、さらに詳細にこれらの問題について議論して、問題を軽減するために増進を示します。
Savola & Patel Informational [Page 1] RFC 3964 Security Considerations for 6to4 December 2004
6to4 December 2004のためのSavolaとパテル情報[1ページ]のRFC3964セキュリティ問題
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 異なった6to4推進シナリオ. . . . . . . . . . . . . 4 2.1。 6to4から6to4. . . . . . . . . . . . . . . . . . . 4 2.2まで。 ネイティブから6to4. . . . . . . . . . . . . . . . . . 5 2.3まで。 6to4からネイティブ. . . . . . . . . . . . . . . . . . 5 2.4まで 他のモデル. . . . . . . . . . . . . . . . . . . . . . 6 2.4.1。 6to4ルータとリレー. . . . . . 6 2.4.2の間のBGP。 最適化メソッド. . . . . . . . . 7 2.4.3としての6to4。 トンネルエンドポイントアドレシングメカニズム. . 8 3としての6to4。 6to4の機能性はコンポーネント. . . . . . . . . . 9 3.1をネットワークでつなぎます。 6to4ルータ. . . . . . . . . . . . . . . . . . . . . . 9 3.2。 6to4リレールータ. . . . . . . . . . . . . . . . . . . 10 4。 脅威分析. . . . . . . . . . . . . . . . . . . . . . . 11 4.1。 6to4では、.1にネットワーク. . . . . . . . . . . . . . . . 12 4.1を攻撃します。 第メッセージ. . . . . . . . . . . . 13 4.1.2がある攻撃。 6to4ノード. . . . . . . . . 14 4.1.3にトラフィックを偽造します。 6to4ノード. . . . . . . . 17 4.1.4にトラフィックを反映します。 地方のIPv4は攻撃. . . . . . . . . . 19 4.2を放送します。 ネイティブのIPv6インターネット. . . . . . . . . . . . 20 4.2.1に対する攻撃。 第メッセージ. . . . . . . . . . . . 21 4.2.2がある攻撃。 固有のIPv6ノードにトラフィックを偽造します。 . . . . . 21 4.2.3. 固有のIPv6ノード. . . . 23 4.2.4にトラフィックを反映します。 地方のIPv4は攻撃. . . . . . . . . . 24 4.2.5を放送します。 サービス. . . . . . . . . . . . . . . . 25 4.2.6の窃盗。 乱用. . . . 26 4.3の源と考えられたオペレータをリレーしてください。 IPv4インターネット. . . . . . . . . . . . . . . . 28 4.4に対する攻撃。 攻撃. . . . . . . . . . . . . . . . . 28 5の概要。 6to4. . . . . . . . . 30 5.1で適切なセキュリティチェックを実装します。 IPv4. . . . . . . . . . . . . . 31 5.2にIPv6をカプセル化します。 IPv6. . . . . . . . . . . . . . 31 5.3へのDecapsulating IPv4。 IPv4とIPv6健全度チェック. . . . . . . . . . . . . . 32 5.3.1。 IPv4. . . . . . . . . . . . . . . . . . . . . . 32 5.3.2。 IPv6. . . . . . . . . . . . . . . . . . . . . . 33 5.3.3。 任意のイングレスフィルタリング. . . . . . . . . . . 33 5.3.4。 チェック. . . . . . . . . . . . . 33 6に関する注。 6to4実装と使用. . . . . . . . . . . . 34 6.1での問題。 自動Tunnels. . 34 6.2がいる実装問題。 6to4展開. . . . . . . . . 35 7のための異なったモデル。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 36 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 36 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 37A.は概説された作者の.39のものが.40の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 41を扱ういくつかの些細な攻撃シナリオです。
Savola & Patel Informational [Page 2] RFC 3964 Security Considerations for 6to4 December 2004
6to4 December 2004のためのSavolaとパテル情報[2ページ]のRFC3964セキュリティ問題
1. Introduction
1. 序論
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.
「6to4"[1]はトンネルIPv4アドレスをIPv6 6to4接頭語に埋め込みながら、孤立しているIPv6雲とインタコネクトするためにトンネルを堀る自動IPv6過剰IPv4を指定する」IPv6の当座のメカニズム。
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リレーからのdecapsulate 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.
簡単にするために、本書では、ネイティブのインターネットが他の変遷メカニズムを使用することによって形成されたIPv6ネットワークを包含すると思われます。(例えば、これらのメカニズムとしてのRFC2893[4])は直接6to4ネットワークと話すことができません。
Savola & Patel Informational [Page 3] RFC 3964 Security Considerations for 6to4 December 2004
6to4 December 2004のためのSavolaとパテル情報[3ページ]のRFC3964セキュリティ問題
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[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.
.0/24が使用されるブロック7.0.0 24、.0/8.0.0 24、および.0/9.0.0からのこのメモ、IPv4アドレス中では、あらわな目的であり、グローバルなIPv4アドレスを表すために、それは互いに関係がありません。 2つの理由にただ192.0.2.0/24[5]からのアドレスを使用することの代わりにこのアプローチは選ばれました: 6to4マッピングがぎらぎらと明白であるアドレスを使用して、異なった6to4ゲートウェイのアドレスが必要とするIPv4が互いとの少しの関係も持っていないのを明白にするように。
2. Different 6to4 Forwarding Scenarios
2. 異なった6to4推進シナリオ
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.
1つが6to4とネイティブのドメインの間で交信するとき、2つの方向に使用される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番目の小区分で提示されます。
2.1. From 6to4 to 6to4
2.1. 6to4から6to4まで
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トラフィックをいつも交換します。 6to4接頭語2002: V4ADDRから終点アドレスV4ADDRを得ます:、:目的地の/48。
.--------. _----_ .--------.
| 6to4 | _( IPv4 )_ | 6to4 |
| router | <====> ( Internet ) <===> | router |
'--------' (_ _) '--------'
^ '----' ^
| Direct tunneling over IPv4 |
V V
.--------. .-------.
| 6to4 | | 6to4 |
| host | | host |
'--------' '--------'
.--------. _----_ .--------. | 6to4| _(IPv4)_ | 6to4| | ルータ| <==>(インターネット)<。===>| ルータ| '--------' (_ _) '--------' ^ '----' ^ | IPv4の上のダイレクトトンネリング| V V。--------. .-------. | 6to4| | 6to4| | ホスト| | ホスト| '--------' '--------'
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と)と考えるのが必要です。
Savola & Patel Informational [Page 4] RFC 3964 Security Considerations for 6to4 December 2004
6to4 December 2004のためのSavolaとパテル情報[4ページ]のRFC3964セキュリティ問題
2.2. From Native to 6to4
2.2. 6to4のネイティブから
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 |
'--------'
「固有のIPv6ノード」について最も近く。--------. _----_ .------------. .--------. | ネイティブ| _(IPv6)_ | 6to4リレー| トンネルを堀られます。| 6to4| | IPv6| ->(インターネット)-->。| ルータ| =========>| ルータ| | ノード| (_ _) '------------' 9.0.0.1 '--------' '--------' '----'dst_v6=2002:0900:0001:、:、'1 | V。-------. | 6to4| | ホスト| '--------'
Figure 2
図2
2.3. From 6to4 to Native
2.3. 6to4からネイティブまで
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ドメインは、IPv4の上でそれらの構成された6to4リレールータ、または6to4 IPv4 Anycast[3]を使用することによって見つけられる中で最も近い方にそれにトンネルを堀ることによって、ネイティブのドメインにトラフィックを送ります。 リレーは、いかなる他のIPv6パケットであるだろうことのようにもパケットをdecapsulateして、ネイティブの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 例で。
Savola & Patel Informational [Page 5] RFC 3964 Security Considerations for 6to4 December 2004
6to4 December 2004のためのSavolaとパテル情報[5ページ]のRFC3964セキュリティ問題
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 |
'--------'
または、構成、-、-IPv4 Anycastを設立してください。--------. _----_ .------------. .--------. | ネイティブ| _(IPv6)_ | 6to4リレー| トンネルを堀られます。| 6to4| | クライアント| <。 (インターネット) <--、| ルータ| <===== | ルータ| '--------' (_ _) '------------' 192.88.99.1'--------'2001 : db8:、:、'1 '----'(または、構成されます)^'| .-------. | 6to4| | クライアント| '--------'
Figure 3
図3
2.4. Other Models
2.4. 他のモデル
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操作の多少特別なケースです。 後の章では、別の方法で述べられない場合、一般に、大部分だけが考えられて、(above)がそうするモデルを使用しました。
2.4.1. BGP between 6to4 Routers and Relays
2.4.1. 6to4ルータとリレーの間のBGP
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).
セクション5.2 .2 .2 [1]では、静的な構成の代わりにBGP[6]が6to4リレールータと6to4ルータ(外向的なリレー選択だけのための)の間で使用されるモデルを提示します。
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.
6to4ルータがすべての可能な6to4リレーの間でBGPセッションを確立して、/48接頭語のそれらに広告を出したなら[1]より遠くに行く場合、非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を実行できません、そして、これらのセッションをセットアップするのは、リレーオペレータにとってのずっと多くの仕事でしょう、したがって、これがそうです。
Savola & Patel Informational [Page 6] RFC 3964 Security Considerations for 6to4 December 2004
6to4 December 2004のためのSavolaとパテル情報[6ページ]のRFC3964セキュリティ問題
2.4.2. 6to4 as an Optimization Method
2.4.2. 最適化メソッドとしての6to4
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.
また、これらのサイトは、本国行きの接続に影響するように6to4とDNSの非6to4アドレスの両方を発表します。 送信元ホストのデフォルトアドレス選択[7]が適切に働いていると、6to4ソースは、非6to4が扱うサイトと非6to4ノード使用に達するのに6to4アドレスを使用するでしょう。 外国ノードのこの動きを想定できるなら、そのようなサイトへの軍事的脅威をかなり簡素化できます。
Savola & Patel Informational [Page 7] RFC 3964 Security Considerations for 6to4 December 2004
6to4 December 2004のためのSavolaとパテル情報[7ページ]のRFC3964セキュリティ問題
2.4.3. 6to4 as Tunnel End-Point Addressing Mechanism
2.4.3. トンネルエンドポイントアドレシングメカニズムとしての6to4
6to4 addresses can also be used only as an IPv6-in-IPv4 tunnel endpoint addressing and routing mechanism.
また、単にIPv4のIPv6トンネル終点アドレシングとルーティングメカニズムとして6to4アドレスを使用できます。
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 )
(_ _)
'----'
2001: db8: 0:10:、:/60 2001: db8: 0:20:、:/60 .--------. .--------. (支店1) (支店2) '--------' '--------' | | .--------. _----_ .--------. | 6to4| _(IPv4)_ | 6to4| | ルータ| <==>(インターネット)<。===>| ルータ| '--------' (_ _) '--------' 9.0.0.1 '----' 8.0.0.2 ^^ || vv。--------. | 6to4| 7.0.0.3 | ルータ| '--------' | 2001 : db8:、:/48 .-----------. (本社) '-----------' ^ | _に対して----_ _(IPv6)_ (インターネット) (_ _) '----'
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:10:、:/60->2002:0900:0001:、:1
2001:db8:0:20::/60 -> 2002:0800:0002::1
2001: db8: 0:20:、:/60->2002:0800:0002:、:1
Savola & Patel Informational [Page 8] RFC 3964 Security Considerations for 6to4 December 2004
6to4 December 2004のためのSavolaとパテル情報[8ページ]のRFC3964セキュリティ問題
And a branch office sets up two routes as well:
そして、支店はまた、2つのルートをセットアップします:
2001:db8:0:20::/60 -> 2002:0800:0002::1
2001: db8: 0:20:、:/60->2002:0800:0002:、:1
default -> 2002:0700:0003::1
デフォルト->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 2002として支店がどんな6to4の目的地にもパケットを送ると、本社を通らないことに注意してください:、:/16ルートはデフォルトルートをくつがえします。
This approach may make addressing and routing slightly easier in some circumstances.
このアプローチで、アドレシングとルーティングはいくつかの事情でわずかに簡単になるかもしれません。
3. Functionalities of 6to4 Network Components
3. 6to4ネットワーク要素の機能性
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関連の定義のためのRFC3056[1]のセクション1.1を参照してください。
3.1. 6to4 Routers
3.1. 6to4ルータ
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 トンネルパケットは構成された/anycast 6to4で最も近いリレールータへの非6to4アドレスに発信しました。
Savola & Patel Informational [Page 9] RFC 3964 Security Considerations for 6to4 December 2004
6to4 December 2004のためのSavolaとパテル情報[9ページ]のRFC3964セキュリティ問題
o Decapsulate directly received IPv4 packets from foreign 6to4
addresses.
o Decapsulateは外国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ソースの最も近くにリレーで受け取られたDecapsulate 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はトンネル、または合っている6to4で接頭語を扱います(詳細に関してセクション5.3.1を見ます)。
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接頭語(es)以外の接頭語のために受け取られたトラフィックを捨ててください。
3.2. 6to4 Relay Routers
3.2. 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ルーティングへ前に置く、その結果、すべての6to4にトラフィックを受ける/は最も近くから固有のIPv6ノードを扱います。
Savola & Patel Informational [Page 10] RFC 3964 Security Considerations for 6to4 December 2004
6to4 December 2004のためのSavolaとパテル情報[10ページ]のRFC3964セキュリティ問題
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 IPv4「6to4リレーanycast接頭語」の可到達性の広告を出す、(RFC3068[3]が実装されるなら)(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 そしてパケットが6to4アドレスから正常なIPv6ルーティングを使用することによってトンネルを堀ることで受けたdecapsulatesとフォワード。
o tunnels packets received through normal IPv6 routing from native
addresses that are destined for 2002::/16 to the corresponding
6to4 router.
o パケットが2002年のために運命づけられている固有のアドレスから以下を掘る正常なIPv6を通して受けたトンネル:対応する6to4ルータへの/16。
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 個人的にそれが持っているトラフィックを禁じるか、放送してください。さもないと、ある特定の予約されたIPv4はトンネル、または合っている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 Discard traffic received from 6to4 routers with the destination as
a 6to4 prefix.
o 6to4接頭語として目的地で6to4ルータから受け取られたトラフィックを捨ててください。
4. Threat Analysis
4. 脅威分析
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)(悪意があるノードは攻撃しているノードと他のノードとのコミュニケーションを防ぎます)は攻撃されます。
Savola & Patel Informational [Page 11] RFC 3964 Security Considerations for 6to4 December 2004
6to4 December 2004のためのSavolaとパテル情報[11ページ]のRFC3964セキュリティ問題
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. 少なくとも2、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サイトからの/に制限する特徴があるかもしれないことに注意してください。 この書くこと時点で、この特徴は投機的です、そして、より多くの仕事がロジスティクスを決定するためにする必要があります。
4.1. Attacks on 6to4 Networks
4.1. 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ユーザ)が後でメモで説明されるほかの場所にいる攻撃。
Savola & Patel Informational [Page 12] RFC 3964 Security Considerations for 6to4 December 2004
6to4 December 2004のためのSavolaとパテル情報[12ページ]のRFC3964セキュリティ問題
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ルータもそれが正統の6to4リレーかある他のノードにかかわらずトラフィックを受けるIPv4ノードのアイデンティティを確認する方法が全くありません。 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. 隣人発見(ノースダコタ)メッセージとの攻撃
2. Spoofing traffic to 6to4 nodes
2. 6to4ノードにトラフィックを偽造します。
3. Reflecting traffic from 6to4 nodes
3. 6to4ノードからトラフィックを反映します。
4. Local IPv4 broadcast attack
4. 地方のIPv4放送攻撃
4.1.1. Attacks with ND Messages
4.1.1. 第メッセージとの攻撃
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ネットワークにおけるどんなノードからのノースダコタメッセージも使用することによって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:
攻撃は、例えば、特に大破壊を引き起こすために作られたRoute AdvertisementかNeighbor Advertisementメッセージであるかもしれません。 そのようなパケットのアドレスは以下に以下に類似するかもしれません。
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)
src_v6はfe80と等しいです:、:2 (アドレスを偽造します) dst_v6はfe80と等しいです:、:1 (有効であるか無効のアドレス)src_v4=8.0.0.1(有効であるか偽造しているアドレス)dst_v4=9.0.0.2(有効なアドレス、マッチ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
Neighborディスカバリーの脅威(再直接のDoS、またはDoS)は[8]で説明されます。 すべての攻撃が6to4として適切であるかもしれないというわけではないことに注意してください。
Savola & Patel Informational [Page 13] RFC 3964 Security Considerations for 6to4 December 2004
6to4 December 2004のためのSavolaとパテル情報[13ページ]のRFC3964セキュリティ問題
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.
疑似インタフェースにはリンクレイヤアドレスがないと思われます。(セクション3.8RFC2893[4])。 しかしながら、6to4ルータがNeighborディスカバリー見解からのルータかホストのどちらかであるかもしれないことに注意してください。
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 ノースダコタメッセージの用法を禁止できました。 これは、リンク地方で範囲のアドレスを使用するすべてのパケットが静かに捨てられるのを含意します。 RFC3056[1]のセクション3.1はリンクローカルアドレスの将来の用途のための範囲を出ます。 このメソッドには、落とし穴があります: それは、どんな種類に関するノースダコタメッセージも禁止して、その結果、他のノースダコタのオプションの開発と使用の門戸を閉ざすでしょう。 これが重大な問題であるかどうかが別のものです。
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 ノースダコタメッセージが必要であるなら、SENDのIPsec[4]か拡大のどちらかがリンクローカルアドレスを使用することでパケット交換を保証する中古の[9]であるかもしれません。 リンクレイヤには、アドレスがありません、そして、IPsecはかなり複雑でしょう、したがって、バニラSENDが働いていないでしょう。
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]か構成されたトンネリングを使用することによって、可能です(1つがトンネルエンドポイントのものへのアドレスをソース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は簡単な手段を提供します。(手段はそれなしで存在しないでしょう)。
4.1.2. Spoofing Traffic to 6to4 Nodes
4.1.2. 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:
パケットのIPv6とIPv4アドレスは以下と同様になるでしょう:
Savola & Patel Informational [Page 14] RFC 3964 Security Considerations for 6to4 December 2004
6to4 December 2004のためのSavolaとパテル情報[14ページ]のRFC3964セキュリティ問題
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)
src_v6=2001: db8:、:1(アドレスを偽造する)dst_v6=2002:0900:0002:、:1 (有効なアドレス)src_v4=8.0.0.1(有効であるか偽造しているアドレス)dst_v4=9.0.0.2(有効なアドレス、マッチ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、それらをdecapsulatesして、ソースアドレスを含むIPv4ヘッダーを捨てる、8.0、.0、.1、標準としてそれらを処理する、(攻撃者が推測するか、または得た、「多くのテクニックの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.
反射DoSに参加する6to4ノードをもたらして、トラフィックに関する回答はsrc_v6アドレスに向けられるでしょう。 この攻撃はさらに詳細にセクション4.2.3で説明されます。 回答(例えば、TCP SYN ACK、TCP RST、ICMPv6 Echo Reply、入力はUDPエコーサービスに発信しました、ICMPv6 Destination Unreachable)を犠牲者(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(アクセスControl List)に基づいているファイアウォールがあるかもしれません。 そのようなfirewallingメカニズムはアドレススプーフィングで迂回できます。 したがって、また、些細な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ノードからこれらの攻撃に着手できます。
Savola & Patel Informational [Page 15] RFC 3964 Security Considerations for 6to4 December 2004
6to4 December 2004のためのSavolaとパテル情報[15ページ]のRFC3964セキュリティ問題
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
そのような攻撃を防ぐどんな簡単な方法も存在していません、そして、イングレスなどの、より長い期間ソリューションが[12]かitrace[13]をフィルターにかける場合、フィルターにかけたでしょう。
Savola & Patel Informational [Page 16] RFC 3964 Security Considerations for 6to4 December 2004
6to4 December 2004のためのSavolaとパテル情報[16ページ]のRFC3964セキュリティ問題
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.)
IPv6とIPv4の両方で配布されるために、助けるネットワークは攻撃の源を特定します。 総侵入はおそらく不可能です。 (itrace仕事が2004年7月にこの書くこと現在やめられたことに注意してください。)
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スプーフィング能力と比較できました。
4.1.3. Reflecting Traffic to 6to4 Nodes
4.1.3. 6to4ノードにトラフィックを反映します。
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.
6to4ノードに対して反射攻撃を実行するために、偽造しているトラフィック(セクション4.2.2で説明されるように)を固有のIPv6ノードに送るかもしれません。
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)
src_v6=2002:1234:1234:、:1(目標6to4ノードのアドレスを偽造する)dst_v6=2002:0900:0002:、:1 (有効なアドレス)src_v4=8.0.0.1(有効であるか無効のアドレス)dst_v4=9.0.0.2(有効なアドレス、マッチ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.
リレーが適切な被膜剥離術セキュリティチェックを実装して(詳細に関してセクション5を見てください)、IPv4ノードがsrc_v6を合わせるためにソースアドレスを偽造することができないならリレーによる攻撃が防がれることに注意してください。 同様に、展開をフィルターにかけるグローバルなイングレスは固有の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でトラフィックであると偽造された発信にかかわるなら、分配されたReflection DoSを実行できます。
Savola & Patel Informational [Page 17] RFC 3964 Security Considerations for 6to4 December 2004
6to4 December 2004のためのSavolaとパテル情報[17ページ]のRFC3964セキュリティ問題
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ノードによって受け取られたメッセージに回答を包括します。 攻撃者はパケットにおけるより少ないコントロールをタイプさせます、そして、これはあるタイプの攻撃を抑制するでしょう。 例えば、TCP SYNパケットで6to4ノードをあふれさせるのは可能でないでしょう(例えば、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でサービスプロバイダーをフィルターにかけるイングレスの実装はこの攻撃を排除するでしょう、6to4アドレスとしてsrc_v6を偽造することができなかったので。 しかしながら、これが起こると予想するのは実用的でないかもしれません。
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サイトからトラフィックがレートを制限する特徴であり、レート限界がトラフィックであると実装することができます。
Savola & Patel Informational [Page 18] RFC 3964 Security Considerations for 6to4 December 2004
6to4 December 2004のためのSavolaとパテル情報[18ページ]のRFC3964セキュリティ問題
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.
セキュリティチェック(かなり簡単である)とイングレスフィルタリングの適切な履行でこの特定の攻撃を緩和できます。 イングレスフィルタリングが実装されないとき、攻撃するのは「トラフィック洗浄」が攻撃の明確な目標でないなら直接反射より通常簡単です。 したがって、この攻撃は非常に重大に見えません。
4.1.4. Local IPv4 Broadcast Attack
4.1.4. 地方のIPv4放送攻撃
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.
第1の選択では、それが9.0であると仮定してください。.0 .255は6to4ルータの放送演説です。 目的地でパケットを受けた後に同類を扱ってください、「2002:0900:00ff:、:、」ローカルの6to4ノードからの「bbbb」、ルータがそうしないなら目的地が広く、それが9.0へのカプセル化されたプロトコル-41パケットを送るサブネットのために.255に.0を扱うチェック すべてのノードでサブネットでこれを受け取るでしょう、そして、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.
また、悪意があるサイトはDNS(使用どれが6to4ノードで6to4ルータによるローカル放送をもたらすかを)の偽造6to4アドレスを埋め込むかもしれません。 この攻撃を実行する1つの方法は6to4技術に基づいているネットワークに無効のURL(例えば、http://[2002:0900:00ff: : bbbb]/index.html)へのリンクをすべてのユーザに含むHTMLメールを送るだろうことです。 メールの始まりは同時に、ブロードキャスト・ストームをもたらすでしょう。
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:
2番目の種類の攻撃は、より複雑です: 無効(例えば、2002:0900:00ff: : bbbb)のソースアドレスがあるトラフィックを送ることができる限り、企業内情報通信網のものないIPv4ノードは攻撃を開始できます。 6to4ルータは、パケットをICMPv6に送ることによって、トラフィックにソースか、(例えば、Hop Limit ExceededかDestination Unreachable)に戻った状態で応じなければなりません。 パケットは以下の通りでしょう:
Savola & Patel Informational [Page 19] RFC 3964 Security Considerations for 6to4 December 2004
6to4 December 2004のためのSavolaとパテル情報[19ページ]のRFC3964セキュリティ問題
src_v6 = 2002:0800:00ff::bbbb (broadcast address of the router) dst_v6 = 2002:0800:0001::0001 (valid non-existent address)
src_v6は2002:0800:00ffと等しいです:、:bbbb(ルータの放送演説)dst_v6=2002:0800:0001:、:0001 (有効な実在しないアドレス)
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実装でサイトに制限されます。
4.2. Attacks on Native IPv6 Internet
4.2. ネイティブのIPv6インターネットに対する攻撃
This section describes attacks against native IPv6 Internet that somehow leverage 6to4 architecture. Attacks against 6to4 nodes were described in the previous section.
このセクションはネイティブのIPv6インターネットに対して6to4がアーキテクチャであるとどうにか利用する攻撃を説明します。 攻撃は前項で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つの重要なセキュリティチェックしかありません: decapsulating IPv4パケットであるときに、その2002をチェックします:、V4ADDR:、:/48とV4ADDRはソースアドレスで合っています。 これが完了していないなら、いくつかの脅威が、より重大になります。 以下の分析では、そのようなチェックが実装されると思われます。
Savola & Patel Informational [Page 20] RFC 3964 Security Considerations for 6to4 December 2004
6to4 December 2004のためのSavolaとパテル情報[20ページ]のRFC3964セキュリティ問題
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アドレスの間のパケットをリレーするはずがありません。 特に、セクション5で説明されるように6to4ルータからdecapsulatedされたパケットを6to4ルータに向かってカプセルに入れるべきではありません。 同様に、IPv6ノードから6to4ソースと送付先アドレスを送るパケットをリレーするべきではありません。 この種類のチェックが通常実装されるかどうかは、明確ではありません。 以下で説明された攻撃は、そのようなチェックが実装されないと仮定します。
4.2.1. Attacks with ND Messages
4.2.1. 第メッセージとの攻撃
These attacks are the same as those employed against 6to4 routers, as described in Section 4.1.1.
これらの攻撃はものがセクション4.1.1で説明されるように6to4に対してルータを使ったのと同じです。
4.2.2. Spoofing Traffic to Native IPv6 Node
4.2.2. 固有のIPv6ノードにトラフィックを偽造します。
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ノード)は、DoS攻撃を実行するために偽造している(または、偽造されない)6to4ソースアドレスがあるパケットを固有のIPv6ノードに送ることができます。
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アドレスは偽造されるかもしれません。 上に言及されるようにアドレスが被膜剥離術の間、ソースIPv6アドレスに埋め込まれている状態でリレーがソースIPv4アドレスを関連させると思われることに注意してください。 副作用はトラフィックであると偽造されたすべてが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ノードの上でReflection DoSを行うためにIPv6ノードごとに固有である偽造しているトラフィックを送るかもしれません。
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(アクセスControl List)に基づいているファイアウォールがあるかもしれません。 そのようなfirewallingメカニズムはアドレススプーフィングで迂回できます。 したがって、また、些細なACL回避にこの攻撃を使用できます。 これらの攻撃は無くなっている6to4ノードから偽造しているアドレスまでの回答で妨げられるかもしれません。
Savola & Patel Informational [Page 21] RFC 3964 Security Considerations for 6to4 December 2004
6to4 December 2004のためのSavolaとパテル情報[21ページ]のRFC3964セキュリティ問題
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アドレスに埋め込まれたものと同じであるかどうかチェックするでしょう、したがって、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ノードからの)がソースアドレスとして扱うか、またはソースIPv4アドレスがソースIPv6アドレスに埋め込まれたアドレスに合っていない6to4リレーは、低下しなければなりません。
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(より重大な脅威について説明する)と比べて、この脅威はわずかに処理しやすいように見えます。 リレーが適切な被膜剥離術チェックを実行するなら、スプーフィングを達成できるだけです、6to4ソースアドレスに、IPv4アドレスもまた、偽造可能なときに。
Savola & Patel Informational [Page 22] RFC 3964 Security Considerations for 6to4 December 2004
6to4 December 2004のためのSavolaとパテル情報[22ページ]のRFC3964セキュリティ問題
4.2.3. Reflecting Traffic to Native IPv6 Nodes
4.2.3. 固有のIPv6ノードにトラフィックを反映します。
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ノードから反映されるかもしれません。 以下の1つで攻撃を開始できます:
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.
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.
EXTENSIONS
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.
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.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
Some of the mitigation methods for such attacks are as follows:
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. 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.
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. 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.
Savola & Patel Informational [Page 23] RFC 3964 Security Considerations for 6to4 December 2004
Savola & Patel Informational [Page 23] RFC 3964 Security Considerations for 6to4 December 2004
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. 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.
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. The traffic passes through one or two relays, and traffic rate limiting in the 6to4 relays might help tone down the reflection attack.
COMPARISON TO SITUATION WITHOUT 6to4
COMPARISON TO SITUATION WITHOUT 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).
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).
Therefore, the threat to the availability and stability of the 6to4 relay system itself seems to be higher than to the native IPv6 Internet.
Therefore, the threat to the availability and stability of the 6to4 relay system itself seems to be higher than to the native IPv6 Internet.
4.2.4. Local IPv4 Broadcast Attack
4.2.4. Local IPv4 Broadcast Attack
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:
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:
o native IPv6 nodes that may send traffic to the relay's subnet
broadcast address, and
o native IPv6 nodes that may send traffic to the relay's subnet broadcast address, and
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 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.
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.
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.
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.
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.
Savola & Patel Informational [Page 24] RFC 3964 Security Considerations for 6to4 December 2004
Savola & Patel Informational [Page 24] RFC 3964 Security Considerations for 6to4 December 2004
EXTENSIONS
EXTENSIONS
None.
None.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
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.
The threat is restricted to the relay's local subnet and is fixed by tightening the 6to4 security checks.
COMPARISON TO SITUATION WITHOUT 6to4
COMPARISON TO SITUATION WITHOUT 6to4
This scenario is caused by 6to4, but fortunately the issue is not serious.
This scenario is caused by 6to4, but fortunately the issue is not serious.
4.2.5. Theft of Service
4.2.5. Theft of Service
ATTACK DESCRIPTION
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.
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.
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.
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.
Some users may be able to use the service regardless of these controls, by
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 configuring the address of the relay using its IPv4 address instead of 192.88.99.1, or
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 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.)
EXTENSIONS
EXTENSIONS
None.
None.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
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:
Attempts to use the relay's IPv4 address instead of 192.88.99.1 can be mitigated in the following ways:
1. IPv4 domains should prevent use of the actual IPv4 address of the
relay instead of 192.88.99.1.
1. IPv4 domains should prevent use of the actual IPv4 address of the relay instead of 192.88.99.1.
Savola & Patel Informational [Page 25] RFC 3964 Security Considerations for 6to4 December 2004
Savola & Patel Informational [Page 25] RFC 3964 Security Considerations for 6to4 December 2004
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. 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.
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. 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.
The other threat, of using routing tricks in the IPv6 networks to reach the 6to4 relay, has similar solutions:
The other threat, of using routing tricks in the IPv6 networks to reach the 6to4 relay, has similar solutions:
1. Usage of access lists in the relay to limit access.
1. Usage of access lists in the relay to limit access.
2. Filtering out the packets with a routing header (although this
may have other implications).
2. Filtering out the packets with a routing header (although this may have other implications).
3. Monitoring the source addresses going through the relay to
detect, e.g., peers setting up static routes.
3. Monitoring the source addresses going through the relay to detect, e.g., peers setting up static routes.
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].
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].
As this threat does not have implications for anything other than the organization providing 6to4 relay, it is not analyzed any further.
As this threat does not have implications for anything other than the organization providing 6to4 relay, it is not analyzed any further.
COMPARISON TO SITUATION WITHOUT 6to4
COMPARISON TO SITUATION WITHOUT 6to4
These threats are specific to 6to4 relays (or in general anycast services) and do not exist in networks without 6to4.
These threats are specific to 6to4 relays (or in general anycast services) and do not exist in networks without 6to4.
4.2.6. Relay Operators Seen as Source of Abuse
4.2.6. Relay Operators Seen as Source of Abuse
ATTACK DESCRIPTION
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.
Several attacks use 6to4 relays to anonymize the traffic; this often results in packets being tunneled from the relay to a supposedly-6to4 site.
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.
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.
This could cause a number of concerns for the operators deploying 6to4 relay service, including the following:
This could cause a number of concerns for the operators deploying 6to4 relay service, including the following:
o being contacted a lot (via email, phone, fax, or lawyers) on
suspected "abuse",
o being contacted a lot (via email, phone, fax, or lawyers) on suspected "abuse",
Savola & Patel Informational [Page 26] RFC 3964 Security Considerations for 6to4 December 2004
Savola & Patel Informational [Page 26] RFC 3964 Security Considerations for 6to4 December 2004
o having the whole IPv4 address range rejected as a source of abuse
or spam, causing outage to other operations as well, or
o having the whole IPv4 address range rejected as a source of abuse or spam, causing outage to other operations as well, or
o causing the whole IPv4 address range to be blacklisted in some
"spammer databases", if the relay were used for those purposes.
o causing the whole IPv4 address range to be blacklisted in some "spammer databases", if the relay were used for those purposes.
This threat seems slightly similar to the outburst of SMTP abuse caused by open relays but is more generic.
This threat seems slightly similar to the outburst of SMTP abuse caused by open relays but is more generic.
EXTENSIONS
EXTENSIONS
None.
None.
THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS
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.
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.
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:
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:
o knowledge that this is a special IANA address block, with no real
contact person,
o knowledge that this is a special IANA address block, with no real contact person,
o knowledge that this is a special address block for RFC 3068, or
o knowledge that this is a special address block for RFC 3068, or
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 knowledge that this is a special address block for RFC 3068, and that there are multiple entries by relay operators in the database.
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.
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.
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.
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.
COMPARISON TO SITUATION WITHOUT 6to4
COMPARISON TO SITUATION WITHOUT 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.
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.
Savola & Patel Informational [Page 27] RFC 3964 Security Considerations for 6to4 December 2004
Savola & Patel Informational [Page 27] RFC 3964 Security Considerations for 6to4 December 2004
4.3. Attacks on IPv4 Internet
4.3. Attacks on IPv4 Internet
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.
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.
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.
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.
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.
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.
4.4. Summary of the Attacks
4.4. Summary of the Attacks
Columns:
Columns:
o Section number. The section that describes the attack.
o Section number. The section that describes the attack.
o Attack name.
o Attack name.
o Initiator. The node that initiates the attack.
o Initiator. The node that initiates the attack.
* I_4 - IPv4 node
* I_4 - IPv4 node
* I_6 - native IPv6 node
* I_6 - native IPv6 node
* 6to4 - 6to4 node
* 6to4 - 6to4 node
* * - All of the above
* * - All of the above
o Victim. The victim node
o Victim. The victim node
* I_4 - IPv4 node
* I_4 - IPv4 node
* I_6 - native IPv6 node
* I_6 - native IPv6 node
* 6to4 - 6to4 node
* 6to4 - 6to4 node
* Relay - 6to4 relay
* Relay - 6to4 relay
* Router - 6to4 router
* Router - 6to4 router
Savola & Patel Informational [Page 28] RFC 3964 Security Considerations for 6to4 December 2004
Savola & Patel Informational [Page 28] RFC 3964 Security Considerations for 6to4 December 2004
o ToA. Type of Attack
o ToA. Type of Attack
* D - DoS
* D - DoS
* R - Reflection DoS
* R - Reflection DoS
* T - Theft of Service
* T - Theft of Service
o Fix. Specified who is responsible for fixing the attack.
o Fix. Specified who is responsible for fixing the attack.
* 6 - The 6to4 developer and/or operator can completely mitigate
this attack.
* 6 - The 6to4 developer and/or operator can completely mitigate this attack.
* 6* - The 6to4 developer and/or operator can partially mitigate
this attack.
* 6* - The 6to4 developer and/or operator can partially mitigate this attack.
* E - This threat cannot be fixed by the 6to4 developer or the
6to4 operator.
* E - This threat cannot be fixed by the 6to4 developer or the 6to4 operator.
Summary of attacks on a 6to4 network:
Summary of attacks on a 6to4 network:
+-------+----------------------+---------+----------+-----+-----+
| 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 |
+-------+----------------------+---------+----------+-----+-----+
+-------+----------------------+---------+----------+-----+-----+ | 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
Figure 9
Savola & Patel Informational [Page 29] RFC 3964 Security Considerations for 6to4 December 2004
Savola & Patel Informational [Page 29] RFC 3964 Security Considerations for 6to4 December 2004
Summary of attacks on the native IPv6 internet:
Summary of attacks on the native IPv6 internet:
+-------+----------------------+---------+----------+-----+-----+
| 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) |
+-------+----------------------+---------+----------+-----+-----+
+-------+----------------------+---------+----------+-----+-----+ | 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
Figure 10
Notes:
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) 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.
Summary of attacks on IPv4 internet:
Summary of attacks on IPv4 internet:
+-------+----------------------+---------+----------+-----+-----+
| Sec | Attack name |Initiator| Victim | ToA | Fix |
+-------+----------------------+---------+----------+-----+-----+
| 4.3 | Spoofing Traffic | * | I_4 | D | 6* |
+-------+----------------------+---------+----------+-----+-----+
| 4.3 | Reflection Attacks | * | I_4 | R | 6* |
+-------+----------------------+---------+----------+-----+-----+
+-------+----------------------+---------+----------+-----+-----+ | 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
Figure 11
5. Implementing Proper Security Checks in 6to4
5. Implementing Proper Security Checks in 6to4
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.
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.
Savola & Patel Informational [Page 30] RFC 3964 Security Considerations for 6to4 December 2004
Savola & Patel Informational [Page 30] RFC 3964 Security Considerations for 6to4 December 2004
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.
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.
5.1. Encapsulating IPv6 into IPv4
5.1. Encapsulating IPv6 into IPv4
The checks described in this section are to be performed when encapsulating IPv6 into IPv4.
The checks described in this section are to be performed when encapsulating IPv6 into 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).
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
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
5.2. Decapsulating IPv4 into IPv6
5.2. Decapsulating IPv4 into IPv6
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.
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.
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 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)
Savola & Patel Informational [Page 31] RFC 3964 Security Considerations for 6to4 December 2004
Savola & Patel Informational [Page 31] RFC 3964 Security Considerations for 6to4 December 2004
else
drop
/* the we somehow got a native-native ipv6 packet */
fi
accept
else drop /* the we somehow got a native-native ipv6 packet */ fi accept
5.3. IPv4 and IPv6 Sanity Checks
5.3. IPv4 and IPv6 Sanity Checks
The encapsulation and decapsulation checks include certain sanity checks for both IPv4 and IPv6. These are described here in detail.
The encapsulation and decapsulation checks include certain sanity checks for both IPv4 and IPv6. These are described here in detail.
5.3.1. IPv4
5.3.1. IPv4
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 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
o 0.0.0.0/8 (the system has no address assigned yet)
o 0.0.0.0/8 (the system has no address assigned yet)
o 10.0.0.0/8 (private)
o 10.0.0.0/8 (private)
o 127.0.0.0/8 (loopback)
o 127.0.0.0/8 (loopback)
o 172.16.0.0/12 (private)
o 172.16.0.0/12 (private)
o 192.168.0.0/16 (private)
o 192.168.0.0/16 (private)
o 169.254.0.0/16 (IANA Assigned DHCP link-local)
o 169.254.0.0/16 (IANA Assigned DHCP link-local)
o 224.0.0.0/4 (multicast)
o 224.0.0.0/4 (multicast)
o 240.0.0.0/4 (reserved and broadcast)
o 240.0.0.0/4 (reserved and broadcast)
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
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 receive and process encapsulated IPv4 packets arriving at its broadcast addresses, or
o send encapsulated IPv4 packets to one of its broadcast addresses.
o send encapsulated IPv4 packets to one of its broadcast addresses.
Savola & Patel Informational [Page 32] RFC 3964 Security Considerations for 6to4 December 2004
Savola & Patel Informational [Page 32] RFC 3964 Security Considerations for 6to4 December 2004
5.3.2. IPv6
5.3.2. IPv6
IPv6 address MUST NOT be
IPv6 address MUST NOT be
o 0::/16 (compatible, mapped addresses, loopback, unspecified, ...)
o 0::/16 (compatible, mapped addresses, loopback, unspecified, ...)
o fe80::/10 (link-local)
o fe80::/10 (link-local)
o fec0::/10 (site-local)
o fec0::/10 (site-local)
o ff00::/8 (any multicast)
o ff00::/8 (any multicast)
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.
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.
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.
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.
5.3.3. Optional Ingress Filtering
5.3.3. Optional Ingress Filtering
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.
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.
If these checks are implemented and enabled by default, it's recommended that there be a toggle to disable them if needed.
If these checks are implemented and enabled by default, it's recommended that there be a toggle to disable them if needed.
5.3.4. Notes about the Checks
5.3.4. Notes about the Checks
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.)
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.)
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.
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.
Savola & Patel Informational [Page 33] RFC 3964 Security Considerations for 6to4 December 2004
Savola & Patel Informational [Page 33] RFC 3964 Security Considerations for 6to4 December 2004
6. Issues in 6to4 Implementation and Use
6. Issues in 6to4 Implementation and Use
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.
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.
6.1. Implementation Considerations with Automatic Tunnels
6.1. Implementation Considerations with Automatic Tunnels
There is a problem with multiple transition mechanisms if strict security checks are implemented. This may vary a bit from implementation to implementation.
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.
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.
When a router, which has any two of these enabled, receives an IPv4 encapsulated IPv6 packet
When a router, which has any two of these enabled, receives an IPv4 encapsulated IPv6 packet
src_v6 = 2001:db8::1 dst_v6 = 2002:1010:1010::2 src_v4 = 10.0.0.1 dst_v4 = 20.20.20.20
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.)
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.)
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".
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".
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.
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.
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.
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.
Savola & Patel Informational [Page 34] RFC 3964 Security Considerations for 6to4 December 2004
Savola & Patel Informational [Page 34] RFC 3964 Security Considerations for 6to4 December 2004
6.2. A Different Model for 6to4 Deployment
6.2. A Different Model for 6to4 Deployment
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.
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.
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 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.
It could be possible to turn the deployment assumptions of 6to4 around a bit to eliminate some threats caused by untrusted 6to4 relays:
It could be possible to turn the deployment assumptions of 6to4 around a bit to eliminate some threats caused by untrusted 6to4 relays:
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 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 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 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.
However, this presents a number of problems:
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.
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.
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.
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.
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.
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.
Savola & Patel Informational [Page 35] RFC 3964 Security Considerations for 6to4 December 2004
Savola & Patel Informational [Page 35] RFC 3964 Security Considerations for 6to4 December 2004
7. Security Considerations
7. Security Considerations
This document discusses security considerations of 6to4.
This document discusses security considerations of 6to4.
Even if proper checks are implemented, there are a large number of different security threats; these threats are analyzed in Section 4.
Even if proper checks are implemented, there are a large number of different security threats; these threats are analyzed in Section 4.
There are mainly four classes of potential problem sources:
There are mainly four classes of potential problem sources:
1. 6to4 routers not being able to identify whether relays are
legitimate
1. 6to4 routers not being able to identify whether relays are legitimate
2. Wrong or impartially implemented 6to4 router or relay security
checks
2. Wrong or impartially implemented 6to4 router or relay security checks
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. DoSか反射したDoS攻撃に参加するのに使用されたか、またはすなわち別の攻撃をたどるのをより困難にしながら「パケット洗浄」に参加させられた6to4構造
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で詳細に分析されます。
8. Acknowledgments
8. 承認
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]でItojun Haginoによって持って来られました、そして、アラン・ジュランドは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
AlexeyクズネツォーフはIPv6の火星のチェックに関する実現問題を持って来ました。 クリスチャンのHuitemaはanycastだけを使用することで6to4リレーに依存する規則を定式化しました。 キース・ムーアは減少している柔軟性に関するポイントを持って来ました。 ブライアンCarpenter、トニー・ハイン、およびウラディスラフYasevichは長い議論のために承認されます。 アラン・ジュランドはリレースプーフィング問題に関して作者に思い出させました。ブライアンCarpenterはBGPベースの6to4ルータモデルに関して作者に思い出させました。 クリスチャンのHuitemaは、より完全な脅威分析のためにプッシュを与えました。 Itojun Haginoは6to4リレーに関するオペレータの恐怖について詳しく説明しました。
Savola & Patel Informational [Page 36] RFC 3964 Security Considerations for 6to4 December 2004
6to4 December 2004のためのSavolaとパテル情報[36ページ]のRFC3964セキュリティ問題
abuse. Rob Austein brought up the idea of a different 6to4 deployment model.
乱用します。 ロブAusteinは異なった6to4展開モデルの考えを持って来ました。
In the latter phase, discussions with Christian Huitema, Brian Carpenter, and Alain Durand were helpful when improving the document.
後者のフェーズでは、ドキュメントを改良するとき、クリスチャンのHuitema、ブライアンCarpenter、およびアラン・ジュランドとの議論は役立っていました。
David Malone, Iljitsch van Beijnum, and Tim Chown gave feedback on the document.
デヴィッド・マローン、IljitschバンBeijnum、およびティムChownはドキュメントの上にフィードバックしました。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[1] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4
Clouds", RFC 3056, February 2001.
[1] 大工とB.とK.ムーア、「IPv4 Cloudsを通したIPv6 Domainsの接続」、RFC3056、2001年2月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC
3068, June 2001.
[3]Huitema、C.、「6to4リレールータのためのAnycast接頭語」、RFC3068、2001年6月。
9.2. Informative References
9.2. 有益な参照
[4] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
Hosts and Routers", RFC 2893, August 2000.
[4] ギリガンとR.とE.Nordmark、「IPv6ホストとルータのための変遷メカニズム」、RFC2893、2000年8月。
[5] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[5]IANA、「特別な使用IPv4アドレス」、RFC3330、2002年9月。
[6] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995.
[6]RekhterとY.と1995年のT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC1771行進。
[7] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003.
[7]Draves、R.、「インターネットプロトコルバージョン6(IPv6)のためのデフォルトAddress Selection」、RFC3484、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.、ケンフ、J.、およびE.Nordmark、「IPv6隣人発見(ノースダコタ)信用モデルと脅威」(RFC3756)は2004がそうするかもしれません。
[9] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", Work in Progress, July 2004.
[9] Arkko、J.、ケンフ、J.、ゾンマーフェルト、B.、Zill、B.、およびP.Nikander、「安全な隣人発見(発信する)」が進行中(2004年7月)で働いています。
[10] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
IPv6 Hosts and Routers", Work in Progress, September 2004.
[10] 「IPv6ホストとルータのための基本的な変遷メカニズム」というNordmark、E.、およびR.ギリガンは進歩、2004年9月に働いています。
[11] Savola, P., "Security of IPv6 Routing Header and Home Address
Options", Work in Progress, March 2002.
[11] P.、「IPv6ルート設定ヘッダーとホームアドレスオプションのセキュリティ」というSavolaは進歩、2002年3月に働いています。
Savola & Patel Informational [Page 37] RFC 3964 Security Considerations for 6to4 December 2004
6to4 December 2004のためのSavolaとパテル情報[37ページ]のRFC3964セキュリティ問題
[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] ファーガソン、P.、およびD.Senieは「以下をフィルターにかけるイングレスをネットワークでつなぎます」。 「IP Source Address Spoofingを使うサービス妨害Attacksを破ります」、BCP38、RFC2827、2000年5月。
[13] Bellovin, S., Leech, M. and T. Taylor, "ICMP Traceback
Messages", Work in Progress, February 2003.
[13] Bellovin(S.)はまとわりついて、「ICMP Tracebackメッセージ」というM.とT.テイラーは進歩、2003年2月に働いています。
[14] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995.
[14] ベイカー、F.、「IPバージョン4ルータのための要件」、RFC1812、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] 「イントラサイトの自動トンネルアドレシングプロトコル(ISATAP)」というテンプリン、F.、グリーソン、T.、Talwar、M.、およびD.ターレルは進行中(2004年5月)で動作します。
[16] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
[16] シンプソン、1995年10月、W.、「IPトンネリングにおけるIP」RFC1853。
[17] Hagino, J., "Possible abuse against IPv6 transition
technologies", Work in Progress, July 2000.
[17]Hagino、J.、「IPv6変遷技術に対する可能な乱用」、Progress、2000年7月のWork。
Savola & Patel Informational [Page 38] RFC 3964 Security Considerations for 6to4 December 2004
6to4 December 2004のためのSavolaとパテル情報[38ページ]のRFC3964セキュリティ問題
Appendix A. Some Trivial Attack Scenarios Outlined
いくつかの些細な攻撃シナリオが概説した付録A.
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)
src_v6=2002:0800:0001:、:aaaa dst_v6=2002:0800:0002:、:bbbb src_v4は8.0.0.1(IPv4に要約されると、加えられる)dst_v4=8.0.0.2と等しいです。(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:
src_v6とdst_v6だけがRBの上のIPv4スタックでパケットを受け取るとき、それをdecapsulatedするので、残っています、元々RAによって送られるように:
src_v6 = 2002:0800:0001::aaaa dst_v6 = 2002:0800:0002::bbbb
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的な)、リンクレイヤ(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)
src_v6=2002:1234:5678:、:aaaa(鍛造されます)dst_v6=2002:0800:0002:、:bbbb src_v4は8.0.0.1(IPv4に要約されると、加えられる)dst_v4=8.0.0.2と等しいです。(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 = ...
src_v6=:、:ffff: [或るものは私設のネットワークでIPv4を信じました] src_v6/dst_v6=:、:ffff: 127.0 .0 .1 src_v6/dst_v6=:、:1 src_v6/dst_v6=…
Savola & Patel Informational [Page 39] RFC 3964 Security Considerations for 6to4 December 2004
6to4 December 2004のためのSavolaとパテル情報[39ページ]のRFC3964セキュリティ問題
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
ペッカ・Savola CSC/FUNETエスポーフィンランド
EMail: psavola@funet.fi
メール: psavola@funet.fi
Chirayu Patel All Play, No Work 185, Defence Colony Bangalore, Karnataka 560038 India
パテルがすべて演じるChirayu、いいえ仕事185、ディフェンス居留地バンガロール、カルナタカ560038インド
Phone: +91-98452-88078 EMail: chirayu@chirayu.org URI: http://www.chirayu.org
以下に電話をしてください。 +91-98452-88078はメールされます: chirayu@chirayu.org ユリ: http://www.chirayu.org
Savola & Patel Informational [Page 40] RFC 3964 Security Considerations for 6to4 December 2004
6to4 December 2004のためのSavolaとパテル情報[40ページ]のRFC3964セキュリティ問題
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Savola & Patel Informational [Page 41]
SavolaとパテルInformationalです。[41ページ]
一覧
スポンサーリンク
