RFC3682 日本語訳

Network Working Group                                            V. Gill
Request for Comments: 3682                                    J. Heasley
Category: Experimental                                          D. Meyer
                                                           February 2004

コメントを求めるワーキンググループV.エラ要求をネットワークでつないでください: 3682年のJ.Heasleyカテゴリ: 実験的なD.マイヤー2004年2月

             The Generalized TTL Security Mechanism (GTSM)

一般化されたTTLセキュリティー対策(GTSM)

Status of this Memo

このMemoの状態

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Copyright(C)インターネット協会(2004)。 All rights reserved。

Abstract

要約

   The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6)
   to protect a protocol stack from CPU-utilization based attacks has
   been proposed in many settings (see for example, RFC 2461).  This
   document generalizes these techniques for use by other protocols such
   as BGP (RFC 1771), Multicast Source Discovery Protocol (MSDP),
   Bidirectional Forwarding Detection, and Label Distribution Protocol
   (LDP) (RFC 3036).  While the Generalized TTL Security Mechanism
   (GTSM) is most effective in protecting directly connected protocol
   peers, it can also provide a lower level of protection to multi-hop
   sessions.  GTSM is not directly applicable to protocols employing
   flooding mechanisms (e.g., multicast), and use of multi-hop GTSM
   should be considered on a case-by-case basis.

CPU使用率からのプロトコル・スタックのベースの攻撃を保護するLive(TTL)(IPv4)かHop Limit(IPv6)へのパケットのTimeの使用は多くの設定で提案されました(例えば、見てください、RFC2461)。 BGPなどの他のプロトコル(RFC1771)、Multicast Sourceディスカバリープロトコル(MSDP)、Bidirectional Forwarding Detection、およびLabel Distributionプロトコル(自由民主党)(RFC3036)でこのドキュメントは使用のためのこれらのテクニックを広めます。 また、直接接続されたプロトコル同輩を保護するのにおいてGeneralized TTL Security Mechanism(GTSM)が最も効果的である間、それはマルチホップセッションまで保護の下のレベルを提供できます。 ケースバイケースで考えられて、GTSMは直接氾濫メカニズム(例えば、マルチキャスト)、およびマルチホップGTSMの使用を使うのがそうするべきであるプロトコルに適切ではありません。

Table of Contents

目次

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Assumptions Underlying GTSM. . . . . . . . . . . . . . . . . .  2
       2.1.  GTSM Negotiation . . . . . . . . . . . . . . . . . . . .  3
       2.2.  Assumptions on Attack Sophistication . . . . . . . . . .  3
   3.  GTSM Procedure . . . . . . . . . . . . . . . . . . . . . . . .  3
       3.1.  Multi-hop Scenarios. . . . . . . . . . . . . . . . . . .  4
             3.1.1.  Intra-domain Protocol Handling . . . . . . . . .  5
   4.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  Security Considerations. . . . . . . . . . . . . . . . . . . .  5
       5.1.  TTL (Hop Limit) Spoofing . . . . . . . . . . . . . . . .  5
       5.2.  Tunneled Packets . . . . . . . . . . . . . . . . . . . .  6
             5.2.1.  IP in IP . . . . . . . . . . . . . . . . . . . .  6

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 GTSMの基礎となる仮定。 . . . . . . . . . . . . . . . . . 2 2.1. GTSM交渉. . . . . . . . . . . . . . . . . . . . 3 2.2。 攻撃洗練. . . . . . . . . . 3 3における仮定。 GTSM手順. . . . . . . . . . . . . . . . . . . . . . . . 3 3.1。 マルチホップシナリオ。 . . . . . . . . . . . . . . . . . . 4 3.1.1. イントラドメインプロトコル取り扱. . . . . . . . . 5 4い。 承認。 . . . . . . . . . . . . . . . . . . . . . . . 5 5. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 5 5.1. TTL(ホップ限界)スプーフィング. . . . . . . . . . . . . . . . 5 5.2。 パケット. . . . . . . . . . . . . . . . . . . . 6 5.2.1にトンネルを堀りました。 IP. . . . . . . . . . . . . . . . . . . . 6におけるIP

Gill, et al.                  Experimental                      [Page 1]

RFC 3682           Generalized TTL Security Mechanism      February 2004

エラ、他 TTLセキュリティー対策2004年2月に一般化された実験的な[1ページ]RFC3682

             5.2.2.  IP in MPLS . . . . . . . . . . . . . . . . . . .  7
       5.3.  Multi-Hop Protocol Sessions. . . . . . . . . . . . . . .  8
   6.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  8
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
       7.1.  Normative References . . . . . . . . . . . . . . . . . .  8
       7.2.  Informative References . . . . . . . . . . . . . . . . .  9
   8.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
   9.  Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11

5.2.2. MPLS. . . . . . . . . . . . . . . . . . . 7 5.3のIP。 マルチホッププロトコルセッション。 . . . . . . . . . . . . . . 8 6. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 8 7. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1。 引用規格. . . . . . . . . . . . . . . . . . 8 7.2。 有益な参照. . . . . . . . . . . . . . . . . 9 8。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 10 9。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 11

1.  Introduction

1. 序論

   The Generalized TTL Security Mechanism (GTSM) is designed to protect
   a router's TCP/IP based control plane from CPU-utilization based
   attacks.  In particular, while cryptographic techniques can protect
   the router-based infrastructure (e.g., BGP [RFC1771], [RFC1772]) 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使用率攻撃からルータのTCP/IPに基づいている制御飛行機を保護するように設計されています。 暗号のテクニックがさまざまな攻撃からルータベースのインフラストラクチャ(例えば、BGP[RFC1771]、[RFC1772])を保護できる間、特に、本書では説明された簡単なメカニズムはCPUオーバーロードに基づく多くの攻撃を防ぐことができます。 同じテクニックがルータのCPUにかかわるプロセッサ線カード帯域幅に対する攻撃などの他の不十分なリソース攻撃から守ることに注意してください。

   GTSM is based on the fact that the vast majority of protocol peerings
   are established between routers that are adjacent [PEERING].  Thus
   most protocol peerings are either directly between connected
   interfaces or at 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.

GTSMはプロトコルpeeringsのかなりの大部分が隣接しているルータ[PEERING]の間で確立されるという事実に基づいています。 したがって、ほとんどのプロトコルpeeringsは接続インタフェースの直接間、または、最悪の場合においてあって、ループバックとループバックの間には、あります、ループバックへのスタティックルートで。 TTLスプーフィングがほとんど不可能であると考えられるので、予想されたTTL値に基づくメカニズムは偽造プロトコルパケットに基づくインフラストラクチャ攻撃から簡単で合理的に体力を要しているディフェンスを提供できます。

   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 BCP 14, RFC 2119
   [RFC2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[RFC2119]で説明されるように本書では解釈されることであるべきです。

2.  Assumptions Underlying GTSM

2. GTSMの基礎となる仮定

   GTSM is predicated upon the following assumptions:

GTSMは以下の仮定で叙述されます:

   (i)    The vast majority of protocol peerings are between adjacent
          routers [PEERING].

(i) 隣接しているルータ[PEERING]の間には、プロトコルpeeringsのかなりの大部分があります。

Gill, et al.                  Experimental                      [Page 2]

RFC 3682           Generalized TTL Security Mechanism      February 2004

エラ、他 TTLセキュリティー対策2004年2月に一般化された実験的な[2ページ]RFC3682

   (ii)   It is common practice for many service providers to ingress
          filter (deny) packets that have the provider's loopback
          addresses as the source IP address.

(ii) それはソースIPアドレスとしてプロバイダーのループバックアドレスを持っているイングレスフィルタ(否定する)パケットへの多くのサービスプロバイダーのための一般的な習慣です。

   (iii)  Use of GTSM is OPTIONAL, and can be configured on a per-peer
          (group) basis.

GTSMの(iii)使用は、OPTIONALであり、1同輩あたり1個の(グループ)ベースで構成できます。

   (iv)   The router supports a method of classifying traffic destined
          for the route processor into interesting/control and
          not-control queues.

(iv) ルータはルートプロセッサのためにおもしろい/コントロールとコントロールでない待ち行列に運命づけられた交通を分類する方法を支持します。

   (iv)   The peer routers both implement GTSM.

(iv) 同輩ルータはともにGTSMを実行します。

2.1.  GTSM Negotiation

2.1. GTSM交渉

   This document assumes that GTSM will be manually configured between
   protocol peers.  That is, no automatic GTSM capability negotiation,
   such as is envisioned by RFC 2842 [RFC2842] is assumed or defined.

このドキュメントは、GTSMがプロトコル同輩の間で手動で構成されると仮定します。 すなわち、RFC2842[RFC2842]によって思い描かれるようなどんな自動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., 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を適切に減少させると思います(明確に、経路か隣接している同輩のどちらかが妥協するなら、心配するように、より悪い問題が周囲にあります)。

   Since the vast majority of our 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 which 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
   large diameter multi-hop peerings.  In the event that an the attack
   comes in from a compromised multi-hop peering, that peering can be
   shut down (a method to reduce exposure to multi-hop attacks is
   outlined below).

ルートサーバや他の大きい直径マルチホップpeeringsなどのアプリケーションのためにGTSMを無効にすることができます。 攻撃は妥協しているマルチホップのじっと見るのから入って、そのじっと見ることは止めることができます(マルチホップ攻撃への露出を抑える方法は以下に概説されています)。

3.  GTSM Procedure

3. GTSM手順

   GTSM SHOULD NOT be enabled by default.  The following process
   describes the per-peer behavior:

GTSM SHOULD NOT、デフォルトで可能にされてください。 以下の過程は1同輩あたりの振舞いについて説明します:

Gill, et al.                  Experimental                      [Page 3]

RFC 3682           Generalized TTL Security Mechanism      February 2004

エラ、他 TTLセキュリティー対策2004年2月に一般化された実験的な[3ページ]RFC3682

    (i)   If GTSM is enabled, an implementation performs the following
          procedure:

(i) GTSMが有効にされるなら、実現は以下の手順を実行します:

          (a)  For directly connected routers,

(a) 直接接続されたルータのために

              o Set the outbound TTL for the protocol connection to 255.

o 255へのプロトコル接続に外国行きのTTLを設定してください。

              o For each configured protocol peer:

o それぞれの構成されたプロトコルには、じっと見てください:

                Update the receive path Access Control List (ACL) or
                firewall to only allow protocol packets to pass onto the
                Route Processor (RP) that have the correct <source,
                destination, TTL> tuple.  The TTL must either be 255
                (for a directly connected peer), or 255-(configured-
                range-of-acceptable-hops) for a multi-hop peer.  We
                specify a range here to achieve some robustness to
                changes in topology.  Any directly connected check MUST
                be disabled for such peerings.

アップデート、経路Access Control List(ACL)かプロトコルパケットが正しい<ソースがあるRoute Processor(RP)に通るのを許容するだけであるファイアウォールを受け取ってください、目的地、TTL>tuple。 TTLは255歳であるに違いありません(直接接続された同輩のための)か255がマルチホップ同輩のための(許容できるホップの構成された範囲)です。 私たちは、トポロジーの変化に何らかの丈夫さを達成するためにここで範囲を指定します。 そのようなpeeringsのためにどんな直接接続されたチェックも無効にしなければなりません。

                It is assumed that a receive path ACL is an ACL that is
                designed to control which packets are allowed to go to
                the RP.  This procedure will only allow protocol packets
                from adjacent router to pass onto the RP.

aが経路を受けると思われます。ACLはどのパケットがRPに行くことができるかを制御するように設計されているACLです。 この手順で、隣接しているルータからのプロトコルパケットはRPに通るだけでしょう。

          (b)  If the inbound TTL is 255 (for a directly connected
               peer), or 255-(configured-range-of-acceptable-hops) (for
               multi-hop peers), the packet is NOT processed.  Rather,
               the packet is placed into a low priority queue, and
               subsequently logged and/or silently discarded.  In this
               case, an ICMP message MUST NOT be generated.

(b) 本国行きのTTLが255歳(直接接続された同輩のための)であるか255が(構成された範囲の許容できるホップ)(マルチホップ同輩のために)であるなら、パケットは処理されません。 むしろ、パケットは、低い優先待ち行列に置かれて、次に、登録される、そして/または、静かに捨てられます。 この場合、ICMPメッセージは発生してはいけません。

    (ii)  If GTSM is not enabled, normal protocol behavior is followed.

(ii) GTSMが有効にされないなら、通常のプロトコルの振舞いは続かれています。

3.1.  Multi-hop Scenarios

3.1. マルチホップシナリオ

   When a multi-hop protocol session is required, we set the expected
   TTL value to be 255-(configured-range-of-acceptable-hops).  This
   approach provides a qualitatively lower degree of security for the
   protocol implementing GTSM (i.e., a DoS attack could theoretically be
   launched by compromising some box in the path).  However, GTSM will
   still catch the vast majority of observed DDoS attacks against a
   given protocol.  Note that since the number of hops can change
   rapidly in real network situations, it is considered that GTSM may
   not be able to handle this scenario adequately and an implementation
   MAY provide OPTIONAL support.

マルチホッププロトコルセッションが必要であるときに、私たちは、予想されたTTL値に255(構成された範囲の許容できるホップ)であるように設定します。 このアプローチは質的に下側の度のセキュリティをGTSMを実行するプロトコルに提供します(ある箱で妥協することによって、経路で理論的にすなわち、DoS攻撃に着手できるでしょう)。 しかしながら、それでも、GTSMは与えられたプロトコルに観測されたDDoS攻撃のかなりの大部分を引っ掛けするでしょう。 ホップの数が本当のネットワーク状況で急速に変化できるのでGTSMが適切にこのシナリオを扱うことができないかもしれないと考えられて、実現がOPTIONALサポートを前提とするかもしれないことに注意してください。

Gill, et al.                  Experimental                      [Page 4]

RFC 3682           Generalized TTL Security Mechanism      February 2004

エラ、他 TTLセキュリティー対策2004年2月に一般化された実験的な[4ページ]RFC3682

3.1.1.  Intra-domain Protocol Handling

3.1.1. イントラドメインプロトコル取り扱い

   In general, GTSM is not used for intra-domain protocol peers or
   adjacencies.  The special case of iBGP peers can be protected by
   filtering at the network edge for any packet that has a source
   address of one of the loopback addresses used for the intra-domain
   peering.  In addition, the current best practice is to further
   protect such peers or adjacencies with an MD5 signature [RFC2385].

一般に、GTSMはイントラドメインプロトコル同輩か隣接番組に使用されません。 ネットワーク縁のフィルタリングはイントラドメインのじっと見るのにループバックアドレスの1つのソースアドレスを使用するどんなパケットのためにもiBGP同輩の特別なケースを保護できます。 さらに、現在の最も良い習慣はMD5署名[RFC2385]でさらにそのような同輩か隣接番組を保護することになっています。

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, Vern Paxon, Pekka Savola, and Robert Raszuk
   also provided useful feedback on earlier versions of this document.
   David Ward provided insight on the generalization of the original
   BGP-specific idea.

ポールTrainaとジョン・スチュワートを含んでいて、BGPを保護するTTL分野の使用は多くの異なった人々の発案でした。 また、ライアン・マクドウェルは同様の考えを勧めました。 また、スティーブBellovin、ジェイBorkenhagen、ランディ・ブッシュ、バーンPaxon、ペッカSavola、およびロバートRaszukはこのドキュメントの以前のバージョンの役に立つフィードバックを提供しました。 デヴィッド・ウォードは独創的なBGP特有のアイデアの一般化のときに洞察を提供しました。

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.

GTSMはただ一つのホッププロトコルセッションを保護する簡単な手順です、同輩が妥協したそれらの場合を除いて。

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.  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つ減少するので。 ルータがパケットを受けるとき、その結果、パケットの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
   hasn't been tunneled to the decapsulator, and the intervening routers
   are operating in accordance with RFC 791 [RFC791]).

しかしながら、任意の位置から出典を明示されるとそれには特定の値があるようにパケットのTTLを設計するのが難しい、そして、(不可能でない)ですが、非直接接続された位置から255のTTL値を設計するのが可能でないことに注意してください(直接接続された隣人のだれも妥協しないと仮定して、一方、パケットはdecapsulatorにトンネルを堀られていません、そして、RFC791[RFC791]によると、介入しているルータは作動しています)。

Gill, et al.                  Experimental                      [Page 5]

RFC 3682           Generalized TTL Security Mechanism      February 2004

エラ、他 TTLセキュリティー対策2004年2月に一般化された実験的な[5ページ]RFC3682

5.2.  Tunneled Packets

5.2. トンネルを堀られたパケット

   An exception to the observation that a packet with TTL of 255 is
   difficult to spoof occurs when a protocol packet is tunneled to a
   decapsulator who then forwards the packet to a directly connected
   protocol peer.  In this case the decapsulator (tunnel endpoint) can
   either be the penultimate hop, or the last hop itself.  A related
   case arises when the protocol packet is tunneled directly to the
   protocol peer (the protocol peer is the decapsulator).

プロトコルパケットが次に直接接続されたプロトコル同輩にパケットを送るdecapsulatorにトンネルを堀られるとき、255のTTLがあるパケットはだますのが難しいという観測への例外が起こります。 この場合、decapsulator(トンネル終点)は終わりから二番目のホップ、またはホップ自体のどちらかであるかもしれません最後の。 プロトコルパケットが直接プロトコル同輩にトンネルを堀られるとき(プロトコル同輩はdecapsulatorです)、関連するケースは起こります。

   When the protocol packet is encapsulated in IP, it is possible to
   spoof the TTL.  It may also be impossible to legitimately get the
   packet to the protocol peer with a TTL of 255, as in the IP in MPLS
   cases described below.

プロトコルパケットがIPでカプセルに入れられるとき、TTLをだますのは可能です。 また、255のTTLと共にプロトコル同輩にパケットを合法的に届けるのも不可能であるかもしれません、以下で説明されたMPLS場合におけるIPのように。

   Finally, note that 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.

トンネルを堀られたパケットがどう飛行で保護されるかと同様に最終的に、どんなトンネリングのテクニックのセキュリティも大いにトンネル終点での認証によることに注意してください。 しかしながら、そのようなメカニズムはこのメモの範囲を超えています。

5.2.1.  IP in 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 (e.g., in IP-in-IP [RFC2003],
   GRE [RFC2784], or various forms of IPv6-in-IPv4 [RFC2893]).  These
   cases are depicted below.

プロトコルパケットはIPの上で直接プロトコル同輩、または、次に直接接続されたプロトコル同輩(例えば、IPv4のIPv6[RFC2893]のIPにおけるIP[RFC2003]、GRE[RFC2784]、または様々な形の)にパケットを送るdecapsulator(トンネル終点)にトンネルを堀られるかもしれません。 これらのケースは以下に表現されます。

    Peer router ---------- Tunnel endpoint router and peer
     TTL=255     [tunnel]   [TTL=255 at ingress]
                            [TTL=255 at egress]

同輩ルータ---------- トンネル終点ルータと同輩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 the first case, in which the encapsulated packet is tunneled
   directly to the protocol peer, the encapsulated packet's TTL can be
   set arbitrary value.  In the second case, in which the encapsulated
   packet is tunneled to a decapsulator (tunnel endpoint) which then
   forwards it to a directly connected protocol peer, RFC 2003 specifies
   the following behavior:

最初の場合では、要約のパケットのTTLは任意の値を設定することであるかもしれません。(それで直接プロトコル同輩に要約のパケットにトンネルを堀ります)。 2番目の場合では、RFC2003は以下の振舞いを指定します:(そこでは、次に直接接続されたプロトコル同輩にそれを送るdecapsulator(トンネル終点)に要約のパケットにトンネルを堀ります)。

      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.  If the resulting TTL in the inner
      IP header is 0, the datagram is discarded and an ICMP Time

データグラムを要約するとき、データグラムを進める一部としてトンネリングをしているなら、内側のIPヘッダーのTTLを1つ減少させます。 さもなければ、内側のヘッダーTTLはカプセル化の間、変えられません。 内側のIPヘッダーの結果として起こるTTLが0歳であるなら、データグラムは、捨てられてICMP Timeです。

Gill, et al.                  Experimental                      [Page 6]

RFC 3682           Generalized TTL Security Mechanism      February 2004

エラ、他 TTLセキュリティー対策2004年2月に一般化された実験的な[6ページ]RFC3682

      Exceeded message SHOULD be returned to the sender.  An
      encapsulator MUST NOT encapsulate a datagram with TTL = 0.

超えられていて、SHOULDを通信させてください。送付者に返します。 encapsulatorはTTL=0でデータグラムを要約してはいけません。

   Hence the inner IP packet header's TTL, as seen by the decapsulator,
   can be set to an arbitrary value (in particular, 255).  As a result,
   it may not be possible to deliver the protocol packet to the peer
   with a TTL of 255.

したがって、decapsulatorによって見られる内側のIPパケットのヘッダーのTTLは任意の値(特に255)に用意ができることができます。 その結果、255のTTLをもっている同輩にプロトコルパケットを届けるのは可能でないかもしれません。

5.2.2.  IP in MPLS

5.2.2. MPLSのIP

   Protocol packets may also be tunneled over MPLS to a protocol peer
   which either the penultimate hop (when the penultimate hop popping
   (PHP) is employed [RFC3032]), or one hop beyond the penultimate hop.
   These cases are depicted below.

プロトコルパケットも、また、プロトコル同輩への終わりから二番目のが飛び越す(終わりから二番目のホップの飛び出し(PHP)が採用しているとき[RFC3032])MPLSの上でトンネルを堀られるか、または終わりから二番目のホップを超えてワンバウンドであるかもしれません。 これらのケースは以下に表現されます。

    Peer router ---------- Penultimate Hop (PH) and peer
     TTL=255     [tunnel]   [TTL=255 at ingress]
                            [TTL<=254 at egress]

同輩ルータ---------- 終わりから二番目のHop(ペーハー)と同輩TTL=255[トンネル][イングレスにおけるTTL=255][出口のTTL<=254]

    Peer router ---------- Penultimate Hop  -------- 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]

   TTL handling for these cases is described in RFC 3032.  RFC 3032
   states that when the IP packet is first labeled:

これらのケースのためのTTL取り扱いはRFC3032で説明されます。 IPパケットが最初にラベルされるとき、RFC3032はそれを述べます:

      ... the TTL field of the label stack entry MUST BE set to the
      value of the IP TTL field.  (If the IP TTL field needs to be
      decremented, as part of the IP processing, it is assumed that
      this has already been done.)

… ラベルスタックエントリーのTTL分野をIP TTL分野の値に設定しなければなりません。 (IP TTL分野が、IP処理の一部として減少される必要があるなら、これが既に完了していたと思われます。)

   When the label is popped:

ラベルが飛び出すとき:

      When a label is popped, and the resulting label stack is empty,
      then the value of the IP TTL field SHOULD BE replaced with the
      outgoing TTL value, as defined above.  In IPv4 this also requires
      modification of the IP header checksum.

ラベルが飛び出して、結果として起こるラベルスタックが空であると、IP TTL分野SHOULD BEの値はTTL値を外向的に取り替えました、上で定義されるように。 また、IPv4では、これはIPヘッダーチェックサムの変更を必要とします。

   where the definition of "outgoing TTL" is:

「出発しているTTL」の定義があるところ:

      The "incoming TTL" of a labeled packet is defined to be the value
      of the TTL field of the top label stack entry when the packet is
      received.

ラベルされたパケットの「入って来るTTL」は、パケットが受け取られているときの先頭のラベルスタックエントリーのTTL分野の値になるように定義されます。

Gill, et al.                  Experimental                      [Page 7]

RFC 3682           Generalized TTL Security Mechanism      February 2004

エラ、他 TTLセキュリティー対策2004年2月に一般化された実験的な[7ページ]RFC3682

   The "outgoing TTL" of a labeled packet is defined to be the larger
   of:

ラベルされたパケットの「出発しているTTL」は、以下で、より大きくなるように定義されます。

      a) one less than the incoming TTL,
      b) zero.

a) 入って来るTTL、bより少ない1つ) ゼロ。

   In either of these cases, the minimum value by which the TTL could be
   decremented would be one (the network operator prefers to hide its
   infrastructure by decrementing the TTL by the minimum number of LSP
   hops, one, rather than decrementing the TTL as it traverses its MPLS
   domain).  As a result, the maximum TTL value at egress from the MPLS
   cloud is 254 (255-1), and as a result the check described in section
   3 will fail.

これらのケースのどちらかでは、TTLが減少できた最小値は1(ネットワーク・オペレータは、MPLSドメインを横断するのに従ってTTLを減少させるよりTTLをLSPホップ、1の最小の数でむしろ減少させることによってインフラストラクチャを隠すのを好む)でしょう。 その結果、MPLS雲からの出口の最大のTTL値は254(255-1)です、そして、その結果、セクション3で説明されたチェックは失敗するでしょう。

5.3.  Multi-Hop Protocol Sessions

5.3. マルチホッププロトコルセッション

   While the GTSM method is less effective for multi-hop protocol
   sessions, it does close the window on several forms of attack.
   However, in the multi-hop scenario GTSM is an OPTIONAL extension.
   Protection of the protocol infrastructure beyond what is provided by
   the GTSM method will likely require cryptographic machinery such as
   is envisioned by Secure BGP (S-BGP) [SBGP1,SBGP2], and/or other
   extensions.  Finally, note that in the multi-hop case described
   above, we specify a range of acceptable TTLs in order to achieve some
   robustness to topology changes.  This robustness to topological
   change comes at the cost of the loss of some robustness to different
   forms of attack.

GTSM方法はマルチホッププロトコルセッションのためにそれほど効果的ではありませんが、それはいくつかの形式の攻撃のときに近くで窓をします。 しかしながら、マルチホップシナリオでは、GTSMはOPTIONAL拡張子です。 GTSM方法で提供されるものを超えたプロトコルインフラストラクチャの保護はおそらくSecure BGP(S-BGP)[SBGP1、SBGP2]、そして/または、他の拡大で思い描かれるような暗号の機械を必要とするでしょう。 上で説明されたマルチホップ場合では私たちがトポロジー変化に何らかの丈夫さを達成するためにさまざまな許容できるTTLsを指定するという最終的にメモ。 位相的な変化へのこの丈夫さは何らかの丈夫さの損失の費用で異なった形式の攻撃に来ます。

6.  IANA Considerations

6. IANA問題

   This document creates no new requirements on IANA namespaces
   [RFC2434].

このドキュメントはIANA名前空間[RFC2434]にどんな新しい要件も作成しません。

7.  References

7. 参照

7.1.  Normative References

7.1. 引用規格

   [RFC791]   Postel, J., "Internet Protocol Specification", STD 5, RFC
              791, September 1981.

[RFC791] ポステル、J.、「インターネットプロトコル仕様」、STD5、RFC791、1981年9月。

   [RFC1771]  Rekhter, Y. and T. Li (Editors), "A Border Gateway
              Protocol (BGP-4)", RFC 1771, March 1995.

[RFC1771] RekhterとY.とT.李(エディターズ)、「ボーダ・ゲイトウェイ・プロトコル(BGP-4)」、RFC1771、1995年3月。

   [RFC1772]  Rekhter, Y. and P. Gross, "Application of the Border
              Gateway Protocol in the Internet", RFC 1772, March 1995.

[RFC1772]RekhterとY.とP.グロス、「インターネットでのボーダ・ゲイトウェイ・プロトコルの応用」、RFC1772、1995年3月。

   [RFC2003]  Perkins, C., "IP Encapsulation with IP", RFC 2003, October
              1996.

[RFC2003] パーキンス、C.、「IPがあるIPカプセル化」、RFC2003、1996年10月。

Gill, et al.                  Experimental                      [Page 8]

RFC 3682           Generalized TTL Security Mechanism      February 2004

エラ、他 TTLセキュリティー対策2004年2月に一般化された実験的な[8ページ]RFC3682

   [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月。

   [RFC2385]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
              Signature Option", RFC 2385, August 1998.

[RFC2385] ヘファーナン、A.、「TCP MD5 Signature Optionを通したBGPセッションズの保護」、RFC2385、1998年8月。

   [RFC2461]  Narten, T., Nordmark, E. and W. Simpson, "Neighbor
              Discover for IP Version 6 (IPv6)", RFC 2461, December
              1998.

[RFC2461] NartenとT.とNordmarkとE.とW.シンプソン、「隣人はIPのために、バージョン6(IPv6)を発見する」RFC2461、1998年12月。

   [RFC2784]  Farinacci, D., "Generic Routing Encapsulation (GRE)", RFC
              2784, March 2000.

2000年のD.、「一般ルーティングのカプセル化(GRE)」、RFC2784行進の[RFC2784]ファリナッチ。

   [RFC2842]  Chandra, R. and J. Scudder, "Capabilities Advertisement
              with BGP-4", RFC 2842, May 2000.

[RFC2842] チャンドラとR.とJ.Scudder、「BGP-4インチがある能力広告、RFC2842、2000年5月。」

   [RFC2893]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for
              IPv6 Hosts and Routers", RFC 2893, August 2000.

[RFC2893] ギリガンとR.とE.Nordmark、「IPv6ホストとルータのための変遷メカニズム」、RFC2893、2000年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月。

   [RFC3036]  Andersson, L., Doolan, P., Feldman, N., Fredette, A. and
              B. Thomas, "LDP Specification", RFC 3036, January 2001.

[RFC3036] アンデションとL.とDoolanとP.とフェルドマンとN.とFredetteとA.とB.トーマス、「自由民主党仕様」、RFC3036、2001年1月。

   [RFC3392]  Chandra, R. and J. Scudder, "Capabilities Advertisement
              with BGP-4", RFC 3392, November 2002.

[RFC3392] チャンドラとR.とJ.Scudder、「BGP-4インチがある能力広告、RFC3392、2002年11月。」

   [SBGP1]    Kent, S., C. Lynn, and K. Seo, "Secure Border Gateway
              Protocol (Secure-BGP)", IEEE Journal on Selected Areas in
              Communications, volume 18, number 4, April, 2000.

[SBGP1] ケント、S.、C.リン、およびK.Seoは「ボーダ・ゲイトウェイ・プロトコル(安全なBGP)を保証します」、CommunicationsのSelected Areasの上のIEEE Journal、第18巻、No.4、2000年4月。

   [SBGP2]    Kent, S., C. Lynn, J. Mikkelson, and K. Seo, "Secure
              Border Gateway Protocol (S-BGP) -- Real World Performance
              and Deployment Issues", Proceedings of the IEEE Network
              and Distributed System Security Symposium, February, 2000.

[SBGP2]ケント、S.、C.リン、J.Mikkelson、およびK.Seo、「ボーダ・ゲイトウェイ・プロトコル(S-BGP)を保証してください--本当の世界パフォーマンスと展開問題」、IEEEの議事。ネットワークと分散システムセキュリティシンポジウム(2000年2月)。

7.2.  Informative References

7.2. 有益な参照

   [BFD]      Katz, D. and D. Ward, "Bidirectional Forwarding
              Detection", Work in Progress, June 2003.

[BFD] 「双方向の推進検出」というキャッツ、D.、およびD.区は進歩、2003年6月に働いています。

   [PEERING]  Empirical data gathered from the Sprint and AOL backbones,
              October, 2002.

[PEERING]実験によって得られるデータはスプリントとAOL背骨、2002年10月から集まりました。

Gill, et al.                  Experimental                      [Page 9]

RFC 3682           Generalized TTL Security Mechanism      February 2004

エラ、他 TTLセキュリティー対策2004年2月に一般化された実験的な[9ページ]RFC3682

   [RFC2028]  Hovey, R. and S. Bradner, "The Organizations Involved in
              the IETF Standards Process", BCP 11, RFC 2028, October
              1996.

[RFC2028] ハービとR.とS.ブラドナー、「IETF標準化過程にかかわる組織」、BCP11、RFC2028、1996年10月。

   [RFC2434]  Narten, T., and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

[RFC2434] Narten、T.、およびH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」、BCP26、RFC2434(1998年10月)。

   [RFC3618]  Meyer, D. and W. Fenner, Eds., "The Multicast Source
              Discovery Protocol (MSDP)", RFC 3618, October 2003.

[RFC3618] マイヤーとD.とW.フェナー、Eds、「マルチキャストソース発見プロトコル(MSDP)」、RFC3618、10月2003日

8.  Authors' Addresses

8. 作者のアドレス

   Vijay Gill

ビジェイGill

   EMail: vijay@umbc.edu

メール: vijay@umbc.edu

   John Heasley

ジョンHeasley

   EMail: heas@shrubbery.net

メール: heas@shrubbery.net

   David Meyer

デヴィッド・マイヤー

   EMail: dmm@1-4-5.net

メール: dmm@1-4-5.net

Gill, et al.                  Experimental                     [Page 10]

RFC 3682           Generalized TTL Security Mechanism      February 2004

エラ、他 TTLセキュリティー対策2004年2月に一般化された実験的な[10ページ]RFC3682

9.  Full Copyright Statement

9. 完全な著作権宣言文

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Copyright(C)インターネット協会(2004)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Gill, et al.                  Experimental                     [Page 11]

エラ、他 実験的[11ページ]