RFC5082 日本語訳
5082 The Generalized TTL Security Mechanism (GTSM). V. Gill, J.Heasley, D. Meyer, P. Savola, Ed., C. Pignataro. October 2007. (Format: TXT=36579 bytes) (Obsoletes RFC3682) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group V. Gill
Request for Comments: 5082 J. Heasley
Obsoletes: 3682 D. Meyer
Category: Standards Track P. Savola, Ed.
C. Pignataro
October 2007
コメントを求めるワーキンググループV.エラ要求をネットワークでつないでください: 5082J.Heasleyは以下を時代遅れにします。 3682年のD.マイヤーカテゴリ: エド標準化過程P.Savola、C.Pignataro2007年10月
The Generalized TTL Security Mechanism (GTSM)
一般化されたTTLセキュリティー対策(GTSM)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify whether the packet was originated by an adjacent node on a connected link has been used in many recent protocols. This document generalizes this technique. This document obsoletes Experimental RFC 3682.
パケットが接続リンクの上の隣接しているノードによって溯源されたか否かに関係なく、Live(TTL)(IPv4)かHop Limit(IPv6)へのパケットのTimeの確かめる使用は多くの最近のプロトコルに使用されました。 このドキュメントはこのテクニックを広めます。 このドキュメントはExperimental RFC3682を時代遅れにします。
Gill, et al. Standards Track [Page 1] RFC 5082 GTSM October 2007
エラ、他 規格はGTSM2007年10月にRFC5082を追跡します[1ページ]。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Assumptions Underlying GTSM . . . . . . . . . . . . . . . . . 3
2.1. GTSM Negotiation . . . . . . . . . . . . . . . . . . . . . 4
2.2. Assumptions on Attack Sophistication . . . . . . . . . . . 4
3. GTSM Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5.1. TTL (Hop Limit) Spoofing . . . . . . . . . . . . . . . . . 7
5.2. Tunneled Packets . . . . . . . . . . . . . . . . . . . . . 7
5.2.1. IP Tunneled over IP . . . . . . . . . . . . . . . . . 8
5.2.2. IP Tunneled over MPLS . . . . . . . . . . . . . . . . 9
5.3. Onlink Attackers . . . . . . . . . . . . . . . . . . . . . 11
5.4. Fragmentation Considerations . . . . . . . . . . . . . . . 11
5.5. Multi-Hop Protocol Sessions . . . . . . . . . . . . . . . 12
6. Applicability Statement . . . . . . . . . . . . . . . . . . . 12
6.1. Backwards Compatibility . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Multi-Hop GTSM . . . . . . . . . . . . . . . . . . . 15
Appendix B. Changes Since RFC 3682 . . . . . . . . . . . . . . . 15
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 GTSM. . . . . . . . . . . . . . . . . 3 2.1の基礎となる仮定。 GTSM交渉. . . . . . . . . . . . . . . . . . . . . 4 2.2。 攻撃洗練. . . . . . . . . . . 4 3における仮定。 GTSM手順. . . . . . . . . . . . . . . . . . . . . . . . 5 4。 承認. . . . . . . . . . . . . . . . . . . . . . . 6 5。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 6 5.1。 TTL(ホップ限界)スプーフィング. . . . . . . . . . . . . . . . . 7 5.2。 パケット. . . . . . . . . . . . . . . . . . . . . 7 5.2.1にトンネルを堀りました。 IP. . . . . . . . . . . . . . . . . 8 5.2の上で.2にトンネルを堀られたIP IPはMPLS. . . . . . . . . . . . . . . . 9 5.3の上でトンネルを堀りました。 Onlink攻撃者. . . . . . . . . . . . . . . . . . . . . 11 5.4。 断片化問題. . . . . . . . . . . . . . . 11 5.5。 マルチホッププロトコルセッション. . . . . . . . . . . . . . . 12 6。 適用性証明. . . . . . . . . . . . . . . . . . . 12 6.1。 遅れている互換性. . . . . . . . . . . . . . . . . 12 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1。 引用規格. . . . . . . . . . . . . . . . . . . 13 7.2。 RFC3682.15以来の有益な参照. . . . . . . . . . . . . . . . . . 14付録A.マルチホップGTSM. . . . . . . . . . . . . . . . . . . 15付録B.変化
1. Introduction
1. 序論
The Generalized TTL Security Mechanism (GTSM) is designed to protect a router's IP-based control plane from CPU-utilization based attacks. In particular, while cryptographic techniques can protect the router- based infrastructure (e.g., BGP [RFC4271], [RFC4272]) from a wide variety of attacks, many attacks based on CPU overload can be prevented by the simple mechanism described in this document. Note that the same technique protects against other scarce-resource attacks involving a router's CPU, such as attacks against processor- line card bandwidth.
Generalized TTL Security Mechanism(GTSM)は、基づくCPU使用率攻撃からルータのIPベースの制御飛行機を保護するように設計されています。 暗号のテクニックがさまざまな攻撃からベースのルータインフラストラクチャ(例えば、BGP[RFC4271]、[RFC4272])を保護できる間、特に、本書では説明された簡単なメカニズムはCPUオーバーロードに基づく多くの攻撃を防ぐことができます。 同じテクニックがルータのCPUにかかわるプロセッサ線カード帯域幅に対する攻撃などの他の不十分なリソース攻撃から守ることに注意してください。
GTSM is based on the fact that the vast majority of protocol peerings are established between routers that are adjacent. Thus, most protocol peerings are either directly between connected interfaces or, in the worst case, are between loopback and loopback, with static routes to loopbacks. Since TTL spoofing is considered nearly impossible, a mechanism based on an expected TTL value can provide a simple and reasonably robust defense from infrastructure attacks based on forged protocol packets from outside the network. Note, however, that GTSM is not a substitute for authentication mechanisms. In particular, it does not secure against insider on-the-wire attacks, such as packet spoofing or replay.
GTSMはプロトコルpeeringsのかなりの大部分が隣接しているルータの間で確立されるという事実に基づいています。 したがって、ほとんどのプロトコルpeeringsは接続インタフェースの間のどちらか直接には、あるか、またはループバックとループバックの間には、最悪の場合にはあります、ループバックへのスタティックルートで。 TTLスプーフィングがほとんど不可能であると考えられるので、予想されたTTL値に基づくメカニズムは偽造プロトコルパケットに基づくインフラストラクチャ攻撃からネットワークの外から簡単で合理的に体力を要しているディフェンスを提供できます。 しかしながら、GTSMが認証機構の代用品でないことに注意してください。それは、特に、インサイダーに対してワイヤに対するパケットスプーフィングなどの攻撃を保証もしませんし、再演もされません。
Gill, et al. Standards Track [Page 2] RFC 5082 GTSM October 2007
エラ、他 規格はGTSM2007年10月にRFC5082を追跡します[2ページ]。
Finally, the GTSM mechanism is equally applicable to both TTL (IPv4) and Hop Limit (IPv6), and from the perspective of GTSM, TTL and Hop Limit have identical semantics. As a result, in the remainder of this document the term "TTL" is used to refer to both TTL or Hop Limit (as appropriate).
最終的に、GTSMメカニズムは等しくTTL(IPv4)とHop Limit(IPv6)の両方に適切です、そして、GTSMの見解から、TTLとHop Limitには、同じ意味論があります。 その結果、この残りに、存在という両方について言及するのにおいて中古の用語"TTL"TTLかホップ限界(適宜)を記録してください。
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 RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Assumptions Underlying GTSM
2. GTSMの基礎となる仮定
GTSM is predicated upon the following assumptions:
GTSMは以下の仮定で叙述されます:
1. The vast majority of protocol peerings are between adjacent
routers.
1. 隣接しているルータの間には、プロトコルpeeringsのかなりの大部分があります。
2. Service providers may or may not configure strict ingress
filtering [RFC3704] on non-trusted links. If maximal protection
is desired, such filtering is necessary as described in
Section 2.2.
2. サービスプロバイダーは非信じられたリンクの[RFC3704]をフィルターにかける厳しいイングレスを構成するかもしれません。 最大限度の保護が望まれているなら、そのようなフィルタリングがセクション2.2で説明されるように必要です。
3. Use of GTSM is OPTIONAL, and can be configured on a per-peer
(group) basis.
3. GTSMの使用は、OPTIONALであり、1同輩あたり1個の(グループ)ベースで構成できます。
4. The peer routers both implement GTSM.
4. 同輩ルータはともにGTSMを実行します。
5. The router supports a method to use separate resource pools
(e.g., queues, processing quotas) for differently classified
traffic.
5. ルータは異なって分類された交通に、別々のリソースプール(例えば、割当てを処理して、列を作る)を使用する方法を支持します。
Note that this document does not prescribe further restrictions that a router may apply to packets not matching the GTSM filtering rules, such as dropping packets that do not match any configured protocol session and rate-limiting the rest. This document also does not suggest the actual means of resource separation, as those are hardware and implementation-specific.
このドキュメントがルータがGTSMフィルタリングを合わせないことでパケットに適用されるかもしれないというさらなる制限を定めないというメモはどんな構成されたプロトコルセッションのときにも合っていないパケットとレート制限を落とすのなどように残りを統治します。 それらがハードウェアであって実現特有であるので、このドキュメントもリソース分離の実際の手段を示しません。
However, the possibility of denial-of-service (DoS) attack prevention is based on the assumption that classification of packets and separation of their paths are done before the packets go through a scarce resource in the system. In practice, the closer GTSM processing is done to the line-rate hardware, the more resistant the system is to DoS attacks.
しかしながら、サービスの否定(DoS)攻撃防止の可能性はパケットがシステムの不十分なリソースに直面する前にパケットの分類とそれらの経路の分離をするという仮定に基づいています。 習慣、処理が行われるより近いGTSMに、DoS攻撃にはライン料率ハードウェア、より抵抗力があることへのシステムがあります。
Gill, et al. Standards Track [Page 3] RFC 5082 GTSM October 2007
エラ、他 規格はGTSM2007年10月にRFC5082を追跡します[3ページ]。
2.1. GTSM Negotiation
2.1. GTSM交渉
This document assumes that, when used with existing protocols, GTSM will be manually configured between protocol peers. That is, no automatic GTSM capability negotiation, such as is provided by RFC 3392 [RFC3392], is assumed or defined.
このドキュメントは、既存のプロトコルと共に使用されるとGTSMがプロトコル同輩の間で手動で構成されると仮定します。 すなわち、どんな自動GTSM能力交渉(RFC3392[RFC3392]によって提供される)も、想定もされませんし、定義もされません。
If a new protocol is designed with built-in GTSM support, then it is recommended that procedures are always used for sending and validating received protocol packets (GTSM is always on, see for example [RFC2461]). If, however, dynamic negotiation of GTSM support is necessary, protocol messages used for such negotiation MUST be authenticated using other security mechanisms to prevent DoS attacks.
新しいプロトコルがGTSMサポート内蔵設計されるなら、手順が容認されたプロトコルパケットを送って、有効にするのにいつも用いられるのは(GTSMがいつもオンです、と例えば、[RFC2461]は見ます)、お勧めです。 しかしながら、GTSMサポートのダイナミックな交渉が必要であるなら、DoS攻撃を防ぐのに他のセキュリティー対策を使用して、そのような交渉に使用されるプロトコルメッセージを認証しなければなりません。
Also note that this specification does not offer a generic GTSM capability negotiation mechanism, so messages of the protocol augmented with the GTSM behavior will need to be used if dynamic negotiation is deemed necessary.
また、ダイナミックな交渉が必要であると考えられるとGTSMの振舞いに従って増大するプロトコルに関するメッセージが、使用される必要があるように、この仕様が一般的なGTSM能力交渉メカニズムを提供しないことに注意してください。
2.2. Assumptions on Attack Sophistication
2.2. 攻撃洗練における仮定
Throughout this document, we assume that potential attackers have evolved in both sophistication and access to the point that they can send control traffic to a protocol session, and that this traffic appears to be valid control traffic (i.e., it has the source/ destination of configured peer routers).
このドキュメント中では、私たちは、潜在的攻撃者が彼らがコントロール交通をプロトコルセッションに送ることができて、この交通が有効なコントロール交通であるように見えるという(すなわち、それには、構成された同輩ルータのソース/目的地があります)ポイントへの洗練とアクセスの両方で進化したと思います。
We also assume that each router in the path between the attacker and the victim protocol speaker decrements TTL properly (clearly, if either the path or the adjacent peer is compromised, then there are worse problems to worry about).
また、私たちは、攻撃者と犠牲者プロトコルスピーカーの間の経路の各ルータがTTLを適切に減少させると思います(明確に、経路か隣接している同輩のどちらかが妥協するなら、心配するように、より悪い問題が周囲にあります)。
For maximal protection, ingress filtering should be applied before the packet goes through the scarce resource. Otherwise an attacker directly connected to one interface could disturb a GTSM-protected session on the same or another interface. Interfaces that aren't configured with this filtering (e.g., backbone links) are assumed to not have such attackers (i.e., are trusted).
最大限度の保護において、パケットが不十分なリソースに直面する前にイングレスフィルタリングは適用されるべきです。 さもなければ、直接1つのインタフェースに接された攻撃者は同じくらいか別のインタフェースのGTSMによって保護されたセッションを擾乱できました。 (例えば、背骨リンク)をフィルターにかけるこれによって構成されないインタフェースにはそのような攻撃者(すなわち、信じられます)がいないと思われます。
As a specific instance of such interfaces, we assume that tunnels are not a back-door for allowing TTL-spoofing on protocol packets to a GTSM-protected peering session with a directly connected neighbor. We assume that: 1) there are no tunneled packets terminating on the router, 2) tunnels terminating on the router are assumed to be secure and endpoints are trusted, 3) tunnel decapsulation includes source address spoofing prevention [RFC3704], or 4) the GTSM-enabled session does not allow protocol packets coming from a tunnel.
そのようなインタフェースの特定の例として、私たちは、トンネルが直接接続された隣人とのGTSMによって保護されたじっと見るセッションまでのプロトコルパケットにおける許容のための逆ドアのTTL-スプーフィングでないと思います。 私たちは、以下のことと思います。 1) ルータで終わるパケットがトンネルを堀られないか、ルータで終わる2つの)トンネルが安全であると思われて、終点が信じられるか、3)トンネル被膜剥離術がソースアドレススプーフィング防止[RFC3704]を含むか、またはGTSMによって可能にされたセッションがする4は)トンネルから来るプロトコルパケットを許容しません。
Gill, et al. Standards Track [Page 4] RFC 5082 GTSM October 2007
エラ、他 規格はGTSM2007年10月にRFC5082を追跡します[4ページ]。
Since the vast majority of peerings are between adjacent routers, we can set the TTL on the protocol packets to 255 (the maximum possible for IP) and then reject any protocol packets that come in from configured peers that do NOT have an inbound TTL of 255.
隣接しているルータの間には、peeringsのかなりの大部分があるので、私たちは、プロトコルパケットにTTLを255(IPに、可能な最大)までけしかけて、次に、255の本国行きのTTLを持っていない構成された同輩から入るどんなプロトコルパケットも拒絶できます。
GTSM can be disabled for applications such as route-servers and other multi-hop peerings. In the event that an attack comes in from a compromised multi-hop peering, that peering can be shut down.
ルートサーバや他のマルチホップpeeringsなどのアプリケーションのためにGTSMを無効にすることができます。 攻撃が妥協しているマルチホップのじっと見るのから入る場合、そのじっと見ることを止めることができます。
3. GTSM Procedure
3. GTSM手順
If GTSM is not built into the protocol and is used as an additional feature (e.g., for BGP, LDP, or MSDP), it SHOULD NOT be enabled by default in order to remain backward-compatible with the unmodified protocol. However, if the protocol defines a built-in dynamic capability negotiation for GTSM, a protocol peer MAY suggest the use of GTSM provided that GTSM would only be enabled if both peers agree to use it.
GTSMはプロトコルが組み込まれないで、付加的な機能として使用されて(例えば、BGP、自由民主党、またはMSDPのために)、それはSHOULD NOTです。後方に変更されていないプロトコルと互換性があったままで残るためにデフォルトで可能にされてください。 しかしながら、プロトコルがGTSMのために内蔵のダイナミックな能力交渉を定義するなら、両方の同輩が、それを使用するのに同意する場合にだけGTSMが有効にされれば、プロトコル同輩はGTSMの使用を勧めるかもしれません。
If GTSM is enabled for a protocol session, the following steps are added to the IP packet sending and reception procedures:
GTSMがプロトコルセッションのために有効にされるなら、以下のステップはIPパケット発信とレセプション手順に追加されます:
Sending protocol packets:
発信して、パケットについて議定書の中で述べてください:
The TTL field in all IP packets used for transmission of
messages associated with GTSM-enabled protocol sessions MUST be
set to 255. This also applies to the related ICMP error
handling messages.
GTSMによって可能にされたプロトコルセッションに関連しているメッセージの伝達に使用されるすべてのIPパケットのTTL分野を255に設定しなければなりません。 また、これは関連するICMPエラー処理メッセージに適用されます。
On some architectures, the TTL of control plane originated
traffic is under some configurations decremented in the
forwarding plane. The TTL of GTSM-enabled sessions MUST NOT be
decremented.
いくつかの構造、溯源された制御飛行機のTTLに、交通が推進飛行機で減少するいくつかの構成の下にあります。 GTSMによって可能にされたセッションのTTLは減少してはいけません。
Receiving protocol packets:
受信して、パケットについて議定書の中で述べてください:
The GTSM packet identification step associates each received
packet addressed to the router's control plane with one of the
following three trustworthiness categories:
GTSMパケット識別ステップはルータの制御飛行機に記述されたそれぞれの容認されたパケットを以下の3つの信頼できることのカテゴリの1つに関連づけます:
+ Unknown: these are packets that cannot be associated with
any registered GTSM-enabled session, and hence GTSM cannot
make any judgment on the level of risk associated with them.
+ 未知: これらはどんな登録されたGTSMによって可能にされたセッションにも関連づけることができないパケットです、そして、したがって、GTSMはそれらに関連しているリスクのレベルにおける少しの判断もすることができません。
+ Trusted: these are packets that have been identified as
belonging to one of the GTSM-enabled sessions, and their TTL
values are within the expected range.
信じられた+: これらは1つに属すとして特定されたGTSMによって可能にされたセッションのパケットです、そして、予想された範囲の中にそれらのTTL値があります。
Gill, et al. Standards Track [Page 5] RFC 5082 GTSM October 2007
エラ、他 規格はGTSM2007年10月にRFC5082を追跡します[5ページ]。
+ Dangerous: these are packets that have been identified as
belonging to one of the GTSM-enabled sessions, but their TTL
values are NOT within the expected range, and hence GTSM
believes there is a risk that these packets have been
spoofed.
+危険: 予想された範囲の中でそれらのTTL値はそうではありません、そして、これらは1つに属すとして特定されたGTSMによって可能にされたセッションのパケットですが、したがって、GTSMはこれらのパケットがだまされたというリスクがあると信じています。
The exact policies applied to packets of different
classifications are not postulated in this document and are
expected to be configurable. Configurability is likely
necessary in particular with the treatment of related messages
(ICMP errors). It should be noted that fragmentation may
restrict the amount of information available for
classification.
異なった分類のパケットに適用された正確な方針は、本書では仮定されないで、構成可能であると予想されます。 Configurabilityが特に関連するメッセージ(ICMP誤り)の処理によっておそらく必要です。 断片化が分類に有効な情報量を制限するかもしれないことに注意されるべきです。
However, by default, the implementations:
しかしながら、デフォルトで、実現:
+ SHOULD ensure that packets classified as Dangerous do not
compete for resources with packets classified as Trusted or
Unknown.
+ SHOULDは、パケットがTrustedかUnknownとして分類されている状態でDangerousとして分類されたパケットがリソースを競争しないのを確実にします。
+ MUST NOT drop (as part of GTSM processing) packets
classified as Trusted or Unknown.
+はTrustedかUnknownとして分類されたパケットを落としてはいけません(GTSM処理の一部として)。
+ MAY drop packets classified as Dangerous.
+ Dangerousとして分類された5月の低下パケット。
4. Acknowledgments
4. 承認
The use of the TTL field to protect BGP originated with many different people, including Paul Traina and Jon Stewart. Ryan McDowell also suggested a similar idea. Steve Bellovin, Jay Borkenhagen, Randy Bush, Alfred Hoenes, Vern Paxon, Robert Raszuk, and Alex Zinin also provided useful feedback on earlier versions of this document. David Ward provided insight on the generalization of the original BGP-specific idea. Alex Zinin, Alia Atlas, and John Scudder provided a significant amount of feedback for the newer versions of the document. During and after the IETF Last Call, useful comments were provided by Francis Dupont, Sam Hartman, Lars Eggert, and Ross Callon.
ポールTrainaとジョン・スチュワートを含んでいて、BGPを保護するTTL分野の使用は多くの異なった人々の発案でした。 また、ライアン・マクドウェルは同様の考えを勧めました。 また、スティーブBellovin、ジェイBorkenhagen、ランディ・ブッシュ、アルフレッドHoenes、バーンPaxon、ロバートRaszuk、およびアレックス・ジニンはこのドキュメントの以前のバージョンの役に立つフィードバックを提供しました。 デヴィッド・ウォードは独創的なBGP特有のアイデアの一般化のときに洞察を提供しました。 アレックス・ジニン、アリアAtlas、およびジョンScudderはかなりの量のフィードバックをドキュメントの、より新しいバージョンに提供しました。 IETF Last CallとIETF Last Callの後に、役に立つコメントはフランシス・デュポン、サム・ハートマン、ラース・エッゲルト、およびロスCallonによって提供されました。
5. Security Considerations
5. セキュリティ問題
GTSM is a simple procedure that protects single-hop protocol sessions, except in those cases in which the peer has been compromised. In particular, it does not protect against the wide range of on-the-wire attacks; protection from these attacks requires more rigorous security mechanisms.
GTSMは単一のホッププロトコルセッションを保護する簡単な手順です、同輩が妥協したそれらの場合を除いて。 特に、ワイヤに対する広範囲の攻撃から守りません。 これらの攻撃からの保護は、より厳密なセキュリティー対策を必要とします。
Gill, et al. Standards Track [Page 6] RFC 5082 GTSM October 2007
エラ、他 規格はGTSM2007年10月にRFC5082を追跡します[6ページ]。
5.1. TTL (Hop Limit) Spoofing
5.1. TTL(ホップ限界)スプーフィング
The approach described here is based on the observation that a TTL (or Hop Limit) value of 255 is non-trivial to spoof, since as the packet passes through routers towards the destination, the TTL is decremented by one per router. As a result, when a router receives a packet, it may not be able to determine if the packet's IP address is valid, but it can determine how many router hops away it is (again, assuming none of the routers in the path are compromised in such a way that they would reset the packet's TTL).
ここで説明されたアプローチは255のTTL(または、Hop Limit)値がだますために重要であるという観測に基づいています、パケットが目的地に向かってルータを通り抜けるのに従ってTTLが1ルータあたり1つ減少するので。 ルータがパケットを受けるとき、その結果、パケットのIPアドレスが有効であるかどうか決定できないかもしれませんが、それは、いくつのルータが遠くをそれを飛び越すかがあることを(再び、経路のルータのいずれもパケットのTTLをリセットするような方法で妥協しないと仮定します)決定できます。
Note, however, that while engineering a packet's TTL such that it has a particular value when sourced from an arbitrary location is difficult (but not impossible), engineering a TTL value of 255 from non-directly connected locations is not possible (again, assuming none of the directly connected neighbors are compromised, the packet has not been tunneled to the decapsulator, and the intervening routers are operating in accordance with RFC 791 [RFC0791]).
しかしながら、任意の位置から出典を明示されるとそれには特定の値があるようにパケットのTTLを設計するのが難しい、そして、(不可能でない)ですが、非直接接続された位置から255のTTL値を設計するのが可能でないことに注意してください(直接接続された隣人のだれも妥協しないと仮定して、一方、パケットはdecapsulatorにトンネルを堀られていません、そして、RFC791[RFC0791]によると、介入しているルータは作動しています)。
5.2. Tunneled Packets
5.2. トンネルを堀られたパケット
The security of any tunneling technique depends heavily on authentication at the tunnel endpoints, as well as how the tunneled packets are protected in flight. Such mechanisms are, however, beyond the scope of this memo.
どんなトンネリングのテクニックのセキュリティも大いにトンネル終点での認証によります、トンネルを堀られたパケットがどう飛行で保護されるかと同様に。 しかしながら、そのようなメカニズムはこのメモの範囲を超えています。
An exception to the observation that a packet with TTL of 255 is difficult to spoof may occur when a protocol packet is tunneled and the tunnel is not integrity-protected (i.e., the lower layer is compromised).
プロトコルパケットがトンネルを堀られるとき、255のTTLがあるパケットはだますのが難しいという観測への例外が起こるかもしれません、そして、トンネルは保全によって保護されていません(すなわち、下層は妥協します)。
When the protocol packet is tunneled directly to the protocol peer (i.e., the protocol peer is the decapsulator), the GTSM provides some limited added protection as the security depends entirely on the integrity of the tunnel.
プロトコルパケットが直接プロトコル同輩にトンネルを堀られるとき(すなわち、プロトコル同輩はdecapsulatorです)、セキュリティが完全なトンネルの保全によるとき、GTSMは何らかの限られた加えられた保護を提供します。
For protocol adjacencies over a tunnel, if the tunnel itself is deemed secure (i.e., the underlying infrastructure is deemed secure, and the tunnel offers degrees of protection against spoofing such as keys or cryptographic security), the GTSM can serve as a check that the protocol packet did not originate beyond the head-end of the tunnel. In addition, if the protocol peer can receive packets for the GTSM-protected protocol session from outside the tunnel, the GTSM can help thwart attacks from beyond the adjacent router.
トンネルの上のプロトコル隣接番組のために、トンネル自体が安全であると考えられるなら(すなわち、基本的なインフラストラクチャは安全であると考えられます、そして、トンネルはキーか暗号のセキュリティとしてそのようなものをだますことに対する保護の度合いを提供します)、GTSMはプロトコルパケットがトンネルのギヤエンドに溯源しなかったチェックとして機能できます。 さらに、プロトコル同輩がGTSMによって保護されたプロトコルセッションのためにトンネルの外からパケットを受けることができるなら、GTSMは邪魔する隣接しているルータを超えた攻撃助けることができます。
When the tunnel tail-end decapsulates the protocol packet and then IP-forwards the packet to a directly connected protocol peer, the TTL is decremented as described below. This means that the tunnel
トンネルの末端decapsulatesであるときに、直接接続されたプロトコル同輩へのパケット、プロトコルパケットと次に、前方へIP TTLは以下で説明されるように減少します。 これがそれを意味する、トンネル
Gill, et al. Standards Track [Page 7] RFC 5082 GTSM October 2007
エラ、他 規格はGTSM2007年10月にRFC5082を追跡します[7ページ]。
decapsulator is the penultimate node from the GTSM-protected protocol peer's perspective. As a result, the GTSM check protects from attackers encapsulating packets to your peers. However, specific cases arise when the connection from the tunnel decapsulator node to the protocol peer is not an IP forwarding hop, where TTL-decrementing does not happen (e.g., layer-2 tunneling, bridging, etc). In the IPsec architecture [RFC4301], another example is the use of Bump-in- the-Wire (BITW) [BITW].
decapsulatorはGTSMによって保護されたプロトコル同輩の見解からの終わりから二番目のノードです。 その結果、GTSMチェックはパケットをカプセルに入れっている攻撃者からあなたの同輩まで保護されます。 しかしながら、トンネルdecapsulatorノードからプロトコル同輩までの接続がIP推進ホップでないときに、特定のケースは起こります、TTL-減少が起こらないところで(例えば、層-2のトンネリング、橋を架けなどであること)。 IPsec構造[RFC4301]において、別の例が中のBumpの使用である、-、-配線してください、(BITW) [BITW。]
5.2.1. IP Tunneled over IP
5.2.1. IPの上でトンネルを堀られたIP
Protocol packets may be tunneled over IP directly to a protocol peer, or to a decapsulator (tunnel endpoint) that then forwards the packet to a directly connected protocol peer. Examples of tunneling IP over IP include IP-in-IP [RFC2003], GRE [RFC2784], and various forms of IPv6-in-IPv4 (e.g., [RFC4213]). These cases are depicted below.
プロトコルパケットはIPの上で直接プロトコル同輩、または、次に直接接続されたプロトコル同輩にパケットを送るdecapsulator(トンネル終点)にトンネルを堀られるかもしれません。 IPの上でIPにトンネルを堀る例はIPv4のIPv6(例えば、[RFC4213])のIPにおけるIP[RFC2003]、GRE[RFC2784]、および様々な用紙を含んでいます。 これらのケースは以下に表現されます。
Peer router ---------- Tunnel endpoint router and peer
TTL=255 [tunnel] [TTL=255 at ingress]
[TTL=255 at processing]
同輩ルータ---------- トンネル終点ルータと同輩TTL=255[トンネル][イングレスにおけるTTL=255][処理におけるTTL=255]
Peer router -------- Tunnel endpoint router ----- On-link peer
TTL=255 [tunnel] [TTL=255 at ingress] [TTL=254 at ingress]
[TTL=254 at egress]
同輩ルータ-------- トンネル終点ルータ----- リンクの上の同輩TTL=255[トンネル][イングレスにおけるTTL=255][イングレスにおけるTTL=254][出口のTTL=254]
In both cases, the encapsulator (origination tunnel endpoint) is the (supposed) sending protocol peer. The TTL in the inner IP datagram can be set to 255, since RFC 2003 specifies the following behavior:
どちらの場合も、encapsulator(創作トンネル終点)は(想定される)の送付プロトコル同輩です。 RFC2003が以下の振舞いを指定して、内側のIPデータグラムのTTLは255に用意ができることができます:
When encapsulating a datagram, the TTL in the inner IP
header is decremented by one if the tunneling is being
done as part of forwarding the datagram; otherwise, the
inner header TTL is not changed during encapsulation.
データグラムを要約するとき、データグラムを進める一部としてトンネリングをしているなら、内側のIPヘッダーのTTLを1つ減少させます。 さもなければ、内側のヘッダーTTLはカプセル化の間、変えられません。
In the first case, the encapsulated packet is tunneled directly to the protocol peer (also a tunnel endpoint), and therefore the encapsulated packet's TTL can be received by the protocol peer with an arbitrary value, including 255.
前者の場合、直接プロトコル同輩(トンネル終点も)に要約のパケットにトンネルを堀ります、そして、したがって、プロトコル同輩は任意の値で要約のパケットのTTLを受け取ることができます、255を含んでいて。
In the second case, the encapsulated packet is tunneled to a decapsulator (tunnel endpoint), which then forwards it to a directly connected protocol peer. For IP-in-IP tunnels, RFC 2003 specifies the following decapsulator behavior:
2番目の場合では、decapsulator(トンネル終点)に要約のパケットにトンネルを堀ります。(次に、decapsulatorは直接接続されたプロトコル同輩にそれを送ります)。 IPにおけるIPトンネルとして、RFC2003は以下のdecapsulatorの振舞いを指定します:
The TTL in the inner IP header is not changed when decapsulating.
If, after decapsulation, the inner datagram has TTL = 0, the
decapsulator MUST discard the datagram. If, after decapsulation,
the decapsulator forwards the datagram to one of its network
decapsulatingするとき、内側のIPヘッダーのTTLは変えられません。 内側のデータグラムにTTL=0が被膜剥離術の後にあるなら、decapsulatorはデータグラムを捨てなければなりません。 被膜剥離術の後にdecapsulatorがネットワークの1つにデータグラムを送るなら
Gill, et al. Standards Track [Page 8] RFC 5082 GTSM October 2007
エラ、他 規格はGTSM2007年10月にRFC5082を追跡します[8ページ]。
interfaces, it will decrement the TTL as a result of doing normal
IP forwarding. See also Section 4.4.
インタフェースであり、通常のIP推進をすることの結果、それはTTLを減少させるでしょう。 また、セクション4.4を見てください。
And similarly, for GRE tunnels, RFC 2784 specifies the following decapsulator behavior:
そして、同様に、GREトンネルとして、RFC2784は以下のdecapsulatorの振舞いを指定します:
When a tunnel endpoint decapsulates a GRE packet which has an IPv4
packet as the payload, the destination address in the IPv4 payload
packet header MUST be used to forward the packet and the TTL of
the payload packet MUST be decremented.
トンネル終点がペイロードとしてIPv4パケットを持っているGREパケットをdecapsulatesするとき、パケットを進めるのにIPv4ペイロードパケットのヘッダーの送付先アドレスを使用しなければなりません、そして、ペイロードパケットのTTLは減少しなければなりません。
Hence the inner IP packet header's TTL, as seen by the decapsulator, can be set to an arbitrary value (in particular, 255). If the decapsulator is also the protocol peer, it is possible to deliver the protocol packet to it with a TTL of 255 (first case). On the other hand, if the decapsulator needs to forward the protocol packet to a directly connected protocol peer, the TTL will be decremented (second case).
したがって、decapsulatorによって見られる内側のIPパケットのヘッダーのTTLは任意の値(特に255)に用意ができることができます。 また、decapsulatorがプロトコル同輩であるなら、255(最初のケース)のTTLと共にプロトコルパケットをそれに届けるのは可能です。 他方では、decapsulatorが、直接接続されたプロトコル同輩にプロトコルパケットを送る必要があると、TTLは減少するでしょう(2番目のケース)。
5.2.2. IP Tunneled over MPLS
5.2.2. MPLSの上でトンネルを堀られたIP
Protocol packets may also be tunneled over MPLS Label Switched Paths (LSPs) to a protocol peer. The following diagram depicts the topology.
また、プロトコルパケットはMPLS Label Switched Paths(LSPs)の上でプロトコル同輩にトンネルを堀られるかもしれません。 以下のダイヤグラムはトポロジーについて表現します。
Peer router -------- LSP Termination router and peer
TTL=255 MPLS LSP [TTL=x at ingress]
同輩ルータ-------- LSP Terminationルータと同輩TTL=255 MPLS LSP[イングレスにおけるTTL=x]
MPLS LSPs can operate in Uniform or Pipe tunneling models. The TTL handling for these models is described in RFC 3443 [RFC3443] that updates RFC 3032 [RFC3032] in regards to TTL processing in MPLS networks. RFC 3443 specifies the TTL processing in both Uniform and Pipe Models, which in turn can used with or without penultimate hop popping (PHP). The TTL processing in these cases results in different behaviors, and therefore are analyzed separately. Please refer to Section 3.1 through Section 3.3 of RFC 3443.
MPLS LSPsはモデルにトンネルを堀るUniformかPipeで作動できます。 これらのモデルのためのTTL取り扱いはTTL処理に関してMPLSネットワークでRFC3032[RFC3032]をアップデートするRFC3443[RFC3443]で説明されます。 RFC3443は終わりから二番目のホップの飛び出し(PHP)のあるなしにかかわらず使用されて、順番にそうすることができるUniformとPipe Modelsの両方でTTL処理を指定します。 これらの場合で処理するTTLは異なった振舞いをもたらして、したがって、別々に分析されます。 RFC3443のセクション3.3を通してセクション3.1を参照してください。
The main difference from a TTL processing perspective between Uniform and Pipe Models at the LSP termination node resides in how the incoming TTL (iTTL) is determined. The tunneling model determines the iTTL: For Uniform Model LSPs, the iTTL is the value of the TTL field from the popped MPLS header (encapsulating header), whereas for Pipe Model LSPs, the iTTL is the value of the TTL field from the exposed header (encapsulated header).
入って来るTTL(iTTL)がどう断固としているかでLSP終了ノードのUniformとPipe Modelsの間のTTL処理見解からの主な違いはあります。 トンネリングモデルはiTTLを決定します: Uniform Model LSPsに関しては、iTTLは露出しているヘッダー(ヘッダーをカプセルに入れる)からのTTL分野のPipe Model LSPsに関する値ですが、iTTLは飛び出しているMPLSヘッダー(ヘッダーをカプセルに入れる)からのTTL分野の値です。
Gill, et al. Standards Track [Page 9] RFC 5082 GTSM October 2007
エラ、他 規格はGTSM2007年10月にRFC5082を追跡します[9ページ]。
For Uniform Model LSPs, RFC 3443 states that at ingress:
Uniform Model LSPsに関しては、RFC3443はイングレスでそれを述べます:
For each pushed Uniform Model label, the TTL is copied from the
label/IP-packet immediately underneath it.
それぞれの押されたUniform Modelラベルに関しては、TTLはそれのすぐ下のIPラベル/パケットからコピーされます。
From this point, the inner TTL (i.e., the TTL of the tunneled IP datagram) represents non-meaningful information, and at the egress node or during PHP, the ingress TTL (iTTL) is equal to the TTL of the popped MPLS header (see Section 3.1 of RFC 3443). In consequence, for Uniform Model LSPs of more than one hop, the TTL at ingress (iTTL) will be less than 255 (x <= 254), and as a result the check described in Section 3 of this document will fail.
このポイントから、内側のTTL(すなわち、トンネルを堀られたIPデータグラムのTTL)は非有意義な情報を表します、そして、出口ノードにおいて、または、PHP間、イングレスTTL(iTTL)は飛び出しているMPLSヘッダーのTTLと等しいです(RFC3443のセクション3.1を見てください)。 その結果、イングレス(iTTL)におけるTTLは十二分にワンバウンドのUniform Model LSPsに関する255歳未満になるでしょう、そして、(x<=254)その結果、このドキュメントのセクション3で説明されたチェックは失敗するでしょう。
The TTL treatment is identical between Short Pipe Model LSPs without PHP and Pipe Model LSPs (without PHP only). For these cases, RFC 3443 states that:
TTL処理はShort Pipe Model LSPsの間でPHPとPipe Model LSPs(PHPだけのない)なしで同じです。 これらのケースのために、RFC3443は、以下のことと述べます。
For each pushed Pipe Model or Short Pipe Model label, the TTL
field is set to a value configured by the network operator. In
most implementations, this value is set to 255 by default.
それぞれの押されたPipe ModelかShort Pipe Modelラベルにおいて、TTL分野はネットワーク・オペレータによって構成された値に設定されます。 ほとんどの実現では、この値はデフォルトで255に設定されます。
In these models, the forwarding treatment at egress is based on the tunneled packet as opposed to the encapsulation packet. The ingress TTL (iTTL) is the value of the TTL field of the header that is exposed, that is the tunneled IP datagram's TTL. The protocol packet's TTL as seen by the LSP termination can therefore be set to an arbitrary value (including 255). If the LSP termination router is also the protocol peer, it is possible to deliver the protocol packet with a TTL of 255 (x = 255).
これらのモデルでは、出口での推進処理はカプセル化パケットと対照的にトンネルを堀られたパケットに基づいています。 イングレスTTL(iTTL)はすなわち、露出しているヘッダー、トンネルを堀られたIPデータグラムのTTLのTTL分野の値です。 したがって、LSP終了で見られるプロトコルパケットのTTLは任意の値に用意ができることができます(255を含んでいて)。 また、LSP終了ルータがプロトコル同輩であるなら、255(x=255)のTTLがあるプロトコルパケットを届けるのは可能です。
Finally, for Short Pipe Model LSPs with PHP, the TTL of the tunneled packet is unchanged after the PHP operation. Therefore, the same conclusions drawn regarding the Short Pipe Model LSPs without PHP and Pipe Model LSPs (without PHP only) apply to this case. For Short Pipe Model LSPs, the TTL at egress has the same value with or without PHP.
最終的に、PHPとShort Pipe Model LSPsに関して、トンネルを堀られたパケットのTTLはPHP操作の後に変わりがありません。 したがって、Short Pipe Model LSPsに関してPHPとPipe Model LSPs(PHPだけのない)なしで達せられる同じ結論は本件に適用されます。 Short Pipe Model LSPsに関しては、出口のTTLには、PHPのあるなしにかかわらず同じ値があります。
In conclusion, GTSM checks are possible for IP tunneled over Pipe model LSPs, but not for IP tunneled over Uniform model LSPs. Additionally, for all tunneling modes, if the LSP termination router needs to forward the protocol packet to a directly connected protocol peer, it is not possible to deliver the protocol packet to the protocol peer with a TTL of 255. If the packet is further forwarded, the outgoing TTL (oTTL) is calculated by decrementing iTTL by one.
結論として、GTSMチェックは、PipeモデルLSPsの上でトンネルを堀られたIPに可能ですが、UniformモデルLSPsの上でトンネルを堀られたIPのために可能であるというわけではありません。 さらに、LSP終了ルータが、直接接続されたプロトコル同輩にプロトコルパケットを送る必要があるなら、すべてのトンネリングモードには、255のTTLをもっているプロトコル同輩にプロトコルパケットを届けるのは可能ではありません。 さらにパケットを進めるなら、iTTLを1つ減少させることによって、出発しているTTL(oTTL)について計算します。
Gill, et al. Standards Track [Page 10] RFC 5082 GTSM October 2007
エラ、他 規格はGTSM2007年10月にRFC5082を追跡します[10ページ]。
5.3. Onlink Attackers
5.3. Onlink攻撃者
As described in Section 2, an attacker directly connected to one interface can disturb a GTSM-protected session on the same or another interface (by spoofing a GTSM peer's address) unless ingress filtering has been applied on the connecting interface. As a result, interfaces that do not include such protection need to be trusted not to originate attacks on the router.
セクション2で説明されるように、イングレスフィルタリングが接続インタフェースで適用されていない場合、直接1つのインタフェースに接された攻撃者は同じくらいのGTSMによって保護されたセッションか別のインタフェース(GTSM同輩のアドレスをだますのによる)を擾乱できます。 その結果、そのような保護を含んでいないインタフェースは、ルータに対する攻撃を溯源しないと信じられる必要があります。
5.4. Fragmentation Considerations
5.4. 断片化問題
As mentioned, fragmentation may restrict the amount of information available for classification. Since non-initial IP fragments do not contain Layer 4 information, it is highly likely that they cannot be associated with a registered GTSM-enabled session. Following the receiving protocol procedures described in Section 3, non-initial IP fragments would likely be classified with Unknown trustworthiness. And since the IP packet would need to be reassembled in order to be processed, the end result is that the initial-fragment of a GTSM- enabled session effectively receives the treatment of an Unknown- trustworthiness packet, and the complete reassembled packet receives the aggregate of the Unknowns.
言及されるように、断片化は分類に有効な情報量を制限するかもしれません。 非初期のIP断片がLayer4情報を含んでいないので、登録されたGTSMによって可能にされたセッションにそれらを非常に関連づけそうであることができません。 手順がセクション3で説明した受信プロトコルに従って、非初期のIP断片はUnknown信頼できることでおそらく分類されるでしょう。 IPパケットは、処理されるために組み立て直される必要があるでしょう、そして、したがって、結末が事実上、GTSMの可能にされたセッションの初期の断片がUnknown信頼できることのパケットの処理を受けて、完全な組み立て直されたパケットがUnknownsの集合を受け取るということです。
In principle, an implementation could remember the TTL of all received fragments. Then when reassembling the packet, verify that the TTL of all fragments match the required value for an associated GTSM-enabled session. In the likely common case that the implementation does not do this check on all fragments, then it is possible for a legitimate first fragment (which passes the GTSM check) to be combined with spoofed non-initial fragments, implying that the integrity of the received packet is unknown and unprotected. If this check is performed on all fragments at reassembly, and some fragment does not pass the GTSM check for a GTSM-enabled session, the reassembled packet is categorized as a Dangerous-trustworthiness packet and receives the corresponding treatment.
原則として、実現は、すべてのTTLが断片を受けたのを覚えているかもしれません。 そして、パケットを組み立て直すときには、すべての断片のTTLが関連GTSMによって可能にされたセッションのために必要な値に合っていることを確かめてください。 実現がすべての断片のこのチェックをしないありそうなよくある例では、次に、正統の最初の断片(GTSMチェックを通過する)がだまされた非初期の断片に結合されるのは、可能です、容認されたパケットの保全が未知であって保護がないのを含意して。 このチェックが再アセンブリのすべての断片に実行されて、何らかの断片がGTSMによって可能にされたセッションのためにGTSMチェックを通過しないなら、組み立て直されたパケットは、Dangerous-信頼できることのパケットとして分類されて、対応する処理を受けます。
Further, reassembly requires to wait for all the fragments and therefore likely invalidates or weakens the fifth assumption presented in Section 2: it may not be possible to classify non- initial fragments before going through a scarce resource in the system, when fragments need to be buffered for reassembly and later processed by a CPU. That is, when classification cannot be done with the required granularity, non-initial fragments of GTSM-enabled session packets would not use different resource pools.
さらに、したがって、再アセンブリはおそらくセクション2に提示された5番目の仮定を、すべてのために待ちに断片を必要として、無効にするか、または弱めます: システムの不十分なリソースに直面する前に非初期の断片を分類するのは可能でないかもしれません、断片が再アセンブリのためにバッファリングされて、後でCPUによって処理される必要があると。 すなわち、必要な粒状で分類できないなら、GTSMによって可能にされたセッションパケットの非初期の断片は異なったリソースプールを使用しないでしょう。
Consequently, to get practical protection from fragment attacks, operators may need to rate-limit or discard all received fragments. As such, it is highly RECOMMENDED for GTSM-protected protocols to
その結果、断片攻撃から実用的な保護を得るために、オペレータはレート限界か破棄にすべての容認された断片を必要とするかもしれません。 そういうものとして、それが非常にそうである、GTSMによって保護されたプロトコルのためのRECOMMENDED
Gill, et al. Standards Track [Page 11] RFC 5082 GTSM October 2007
エラ、他 規格はGTSM2007年10月にRFC5082を追跡します[11ページ]。
avoid fragmentation and reassembly by manual MTU tuning, using adaptive measures such as Path MTU Discovery (PMTUD), or any other available method [RFC1191], [RFC1981], or [RFC4821].
手動のMTU調律で断片化と再アセンブリを避けてください、Path MTUディスカバリー(PMTUD)、いかなる他の利用可能な方法[RFC1191]、[RFC1981]、または[RFC4821]などの適応型の測定も使用して。
5.5. Multi-Hop Protocol Sessions
5.5. マルチホッププロトコルセッション
GTSM could possibly offer some small, though difficult to quantify, degree of protection when used with multi-hop protocol sessions (see Appendix A). In order to avoid having to quantify the degree of protection and the resulting applicability of multi-hop, we only describe the single-hop case because its security properties are clearer.
GTSMは小さく、もっとも、定量化するのが難しいいくつかを提供できました、保護のマルチホッププロトコルセッションと共に使用されると度合い(Appendix Aを見てください)。 保護の度合いとマルチホップの結果として起こる適用性を定量化しなければならないのを避けるために、セキュリティの特性が、より明確であるので、私たちは単一のホップケースについて説明するだけです。
6. Applicability Statement
6. 適用性証明
GTSM is only applicable to environments with inherently limited topologies (and is most effective in those cases where protocol peers are directly connected). In particular, its application should be limited to those cases in which protocol peers are directly connected.
GTSMは本来限られたtopologies(そして、プロトコル同輩が直接接されるそれらの場合では、最も効果的である)で単に環境に適切です。 特に、アプリケーションは直接プロトコル同輩に接するそれらの場合に制限されるべきです。
GTSM will not protect against attackers who are as close to the protected station as its legitimate peer. For example, if the legitimate peer is one hop away, GTSM will not protect from attacks from directly connected devices on the same interface (see Section 2.2 for more).
GTSMは保護されたステーションの正統の同輩と同じくらい近くにいる攻撃者から守らないでしょう。 例えば、正統の同輩が遠くでワンバウンドであるなら、GTSMは同じインタフェースに攻撃から直接接続された装置から保護しないでしょう(詳しい情報については、セクション2.2を見てください)。
Experimentation on GTSM's applicability and security properties is needed in multi-hop scenarios. The multi-hop scenarios where GTSM might be applicable is expected to have the following characteristics: the topology between peers is fairly static and well-known, and in which the intervening network (between the peers) is trusted.
GTSMの適用性とセキュリティ所有地における実験がマルチホップシナリオで必要です。 GTSMが適切であるかもしれないマルチホップシナリオが以下の特性を持っていると予想されます: 介入しているネットワーク(同輩の間の)がどれであるかで、同輩の間のトポロジーは、かなり静的で、周知で、信じられます。
6.1. Backwards Compatibility
6.1. 遅れている互換性
RFC 3682 [RFC3682] did not specify how to handle "related messages" (ICMP errors). This specification mandates setting and verifying TTL=255 of those as well as the main protocol packets.
RFC3682[RFC3682]は「関連するメッセージ」(ICMP誤り)を扱う方法を指定しませんでした。 メインと同様にそれらのこの仕様の命令の設定と検証TTL=255はパケットについて議定書の中で述べます。
Setting TTL=255 in related messages does not cause issues for RFC 3682 implementations.
関連するメッセージにTTL=255をはめ込むのはRFC3682実現のために問題を引き起こしません。
Requiring TTL=255 in related messages may have impact with RFC 3682 implementations, depending on which default TTL the implementation uses for originated packets; some implementations are known to use 255, while 64 or other values are also used. Related messages from the latter category of RFC 3682 implementations would be classified
関連するメッセージでTTL=255を必要とするのにおいて、RFC3682実現がある影響力があるかもしれません、実現が溯源されたパケットにどのデフォルトTTLを使用するかによって。 いくつかの実現が255を使用するのが知られていますが、また、64か他の値が使用されます。 RFC3682実現の後者のカテゴリからの関連メッセージは分類されるでしょう。
Gill, et al. Standards Track [Page 12] RFC 5082 GTSM October 2007
エラ、他 規格はGTSM2007年10月にRFC5082を追跡します[12ページ]。
as Dangerous and treated as described in Section 3. This is not believed to be a significant problem because protocols do not depend on related messages (e.g., typically having a protocol exchange for closing the session instead of doing a TCP-RST), and indeed the delivery of related messages is not reliable. As such, related messages typically provide an optimization to shorten a protocol keepalive timeout. Regardless of these issues, given that related messages provide a significant attack vector to e.g., reset protocol sessions, making this further restriction seems sensible.
セクション3で説明されるのと同じくらいDangerousであって同じくらい扱われます。 プロトコルが関連するメッセージ(例えば、TCP-RSTをすることの代わりにセッションを終えることへのプロトコル交換を通常持っている)によらないので、これは重大な問題であると信じられていません、そして、本当に、関連するメッセージの配送は信頼できません。 そういうものとして、関連するメッセージは、プロトコルkeepaliveタイムアウトを短くするために最適化を通常提供します。 これらの問題にかかわらず、関連するメッセージが例えば、リセットプロトコルセッションまで重要な攻撃ベクトルを提供するなら、このさらなる制限をするのは分別があるように思えます。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[RFC2003] パーキンス、C.、「IPの中のIPカプセル化」、RFC2003、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2461]Narten、T.、Nordmark、E.、およびW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
2000年3月の[RFC2784]ファリナッチとD.と李とT.とハンクスとS.とマイヤー、D.とP.Traina、「一般ルーティングのカプセル化(GRE)」RFC2784。
[RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement
with BGP-4", RFC 3392, November 2002.
[RFC3392] チャンドラとR.とJ.Scudder、「BGP-4インチがある能力広告、RFC3392、2002年11月。」
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
in Multi-Protocol Label Switching (MPLS) Networks",
RFC 3443, January 2003.
[RFC3443]AgarwalとP.とB.Akyol、「生きるマルチプロトコルラベルスイッチング(MPLS)ネットワークで処理される時間(TTL)」、RFC3443、2003年1月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] NordmarkとE.とR.ギリガン、「IPv6ホストとルータのための基本的な変遷メカニズム」、RFC4213、2005年10月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter、Y.、李、T.、およびS.野兎、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC4271 2006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
Gill, et al. Standards Track [Page 13] RFC 5082 GTSM October 2007
エラ、他 規格はGTSM2007年10月にRFC5082を追跡します[13ページ]。
7.2. Informative References
7.2. 有益な参照
[BITW] "Thread: 'IP-in-IP, TTL decrementing when forwarding and
BITW' on int-area list, Message-ID:
<Pine.LNX.4.64.0606020830220.12705@netcore.fi>",
June 2006, <http://www1.ietf.org/mail-archive/web/
int-area/current/msg00267.html>.
[BITW] 「縫うように通ってください」 int-領域リスト、Message-IDの'IPにおけるIP、進めるときのTTL減少、およびBITW': 「<Pine.LNX.4.64.0606020830220.12705@netcore.fi>」、2006年6月、int<メールhttp://www1.ietf.org/アーカイブ/ウェブ/領域/電流/msg00267.html>。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC1191] ムガール人とJ.とS.デアリング、「経路MTU探索」、RFC1191、1990年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996.
[RFC1981] マッキャン、J.、デアリング、S.、およびJ.ムガール人、「IPのための経路MTUディスカバリー、バージョン6インチ、RFC1981、1996インチ年8月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3032] ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、「MPLSラベルスタックコード化」、RFC3032(2001年1月)。
[RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL
Security Mechanism (GTSM)", RFC 3682, February 2004.
[RFC3682]エラ、V.、Heasley、J.、およびD.マイヤー、「一般化されたTTLセキュリティー対策(GTSM)」、RFC3682 2004年2月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F.とP.Savola、「Multihomedのためにネットワークをフィルターにかけるイングレス」BCP84、2004年3月のRFC3704。
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, January 2006.
[RFC4272] マーフィー、S.、「BGPセキュリティの脆弱性分析」、RFC4272、2006年1月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007.
[RFC4821] マシスとM.とJ.ヘフナー、「Packetization層の経路MTU発見」、RFC4821、2007年3月。
Gill, et al. Standards Track [Page 14] RFC 5082 GTSM October 2007
エラ、他 規格はGTSM2007年10月にRFC5082を追跡します[14ページ]。
Appendix A. Multi-Hop GTSM
付録A.マルチホップGTSM
NOTE: This is a non-normative part of the specification.
以下に注意してください。 これは仕様の非標準の部分です。
The main applicability of GTSM is for directly connected peers. GTSM could be used for non-directly connected sessions as well, where the recipient would check that the TTL is within a configured number of hops from 255 (e.g., check that packets have 254 or 255). As such deployment is expected to have a more limited applicability and different security implications, it is not specified in this document.
GTSMの主な適用性は直接接続された同輩のためのものです。 また、非直接接続されたセッションにGTSMを使用できました、受取人が、TTLが構成された数のホップの中で255から来ているのをチェックするだろうところで(例えば、パケットには254か255があるのをチェックしてください)。 そのような展開には、より限られた適用性と異なったセキュリティ意味があると予想されるとき、それは本書では指定されません。
Appendix B. Changes Since RFC 3682
RFC3682以来の付録B.変化
o Bring the work on the Standards Track (RFC 3682 was Experimental).
o Standards Trackへの作業をもたらしてください(RFC3682はExperimentalでした)。
o New text on GTSM applicability and use in new and existing
protocols.
o GTSMの適用性に関する新しいテキストと新しくて既存のプロトコルにおける使用。
o Restrict the scope to not specify multi-hop scenarios.
o マルチホップシナリオを指定しないように範囲を制限してください。
o Explicitly require that related messages (ICMP errors) must also
be sent and checked to have TTL=255. See Section 6.1 for
discussion on backwards compatibility.
o また、TTL=255を持つために、関連するメッセージ(ICMP誤り)を送られて、チェックしなければならないのを明らかに必要であってください。 遅れている互換性についての議論に関してセクション6.1を見てください。
o Clarifications relating to fragmentation, security with tunneling,
and implications of ingress filtering.
o トンネリングで断片化、セキュリティに関連する明確化、およびイングレスフィルタリングの含意。
o A significant number of editorial improvements and clarifications.
o 多くの編集の改良と明確化。
Authors' Addresses
作者のアドレス
Vijay Gill EMail: vijay@umbc.edu
ビジェイエラメール: vijay@umbc.edu
John Heasley EMail: heas@shrubbery.net
ジョンHeasleyはメールします: heas@shrubbery.net
David Meyer EMail: dmm@1-4-5.net
デヴィッドマイヤーEMail: dmm@1-4-5.net
Pekka Savola (editor) Espoo Finland EMail: psavola@funet.fi
ペッカSavola(エディタ)エスポーフィンランドEMail: psavola@funet.fi
Carlos Pignataro EMail: cpignata@cisco.com
カルロスPignataroはメールします: cpignata@cisco.com
Gill, et al. Standards Track [Page 15] RFC 5082 GTSM October 2007
エラ、他 規格はGTSM2007年10月にRFC5082を追跡します[15ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Gill, et al. Standards Track [Page 16]
エラ、他 標準化過程[16ページ]
一覧
スポンサーリンク
