[要約] RFC 5082は、Generalized TTL Security Mechanism（GTSM）に関する仕様を定めたものであり、パケットの送信元と宛先の間でのセキュリティを強化するためのメカニズムを提供します。GTSMの目的は、IPネットワーク上での不正なパケット送信を防ぐことです。
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
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
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.
パケットの時間（TTL）（IPv4）またはホップ制限（IPv6）を使用して、接続されたリンク上の隣接ノードによってパケットが発信されたかどうかを確認していることが、最近の多くのプロトコルで使用されています。このドキュメントは、この手法を一般的にしています。このドキュメントは、実験的なRFC 3682を廃止します。
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
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.
一般化されたTTLセキュリティメカニズム（GTSM）は、ルーターのIPベースのコントロールプレーンをCPU活性化ベースの攻撃から保護するように設計されています。特に、暗号化手法はルーターベースのインフラストラクチャ（例：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は、プロトコルピーリングの大部分が隣接するルーター間に確立されているという事実に基づいています。したがって、ほとんどのプロトコルピーリングは、接続されたインターフェイス間の直接的なものであるか、最悪の場合、ループバックとループバックの間で、ループバックへの静的ルートがあります。TTLスプーフィングはほぼ不可能であると考えられているため、予想されるTTL値に基づくメカニズムは、ネットワークの外部からの偽造プロトコルパケットに基づいたインフラストラクチャ攻撃からのシンプルで合理的に堅牢な防御を提供できます。ただし、GTSMは認証メカニズムに代わるものではないことに注意してください。特に、パケットのスプーフィングやリプレイなど、インサイダーオンザワイヤ攻撃に対して保護されていません。
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制限（IPv6）の両方に等しく適用でき、GTSMの観点からは、TTLとHOPリミットには同じセマンティクスがあります。その結果、このドキュメントの残りの部分では、「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", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
GTSM is predicated upon the following assumptions:
GTSMは、次の仮定に基づいています。
1. The vast majority of protocol peerings are between adjacent routers.
1. プロトコルピーリングの大部分は、隣接するルーターの間にあります。
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. サービスプロバイダーは、信頼されていないリンクでStrict Ingressフィルタリング[RFC3704]を構成する場合と構成できない場合があります。最大保護が必要な場合、セクション2.2で説明するように、このようなフィルタリングが必要です。
3. Use of GTSM is OPTIONAL, and can be configured on a per-peer (group) basis.
3. GTSMの使用はオプションであり、ピアごと（グループ）ベースで構成できます。
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攻撃に対してより耐性があります。
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がプロトコルピア間で手動で構成されると想定しています。つまり、RFC 3392 [RFC3392]によって提供されるような自動GTSM機能交渉は想定または定義されていません。
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の動作で増強されたプロトコルのメッセージを使用する必要があります。
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）ルーターで終了するトンネルは安全であり、エンドポイントが信頼されていると想定されていると仮定します。GTSM対応セッションでは、トンネルからのプロトコルパケットは許可されていません。
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.
ピーリングの大部分は隣接するルーターの間にあるため、プロトコルパケット上の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.
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、LDP、またはMSDPの場合）、変更されていないプロトコルと後方互換性を維持するためにデフォルトで有効にしないでください。ただし、プロトコルが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が発信されたトラフィックの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つの信頼性カテゴリのいずれかで、ルーターのコントロールプレーンにアドレス指定された受け取ったパケットをそれぞれ関連付けます。
+ 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.
+ 信頼：これらは、GTSM対応セッションの1つに属していると特定されたパケットであり、TTL値は予想範囲内にあります。
+ 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.
+ 危険：これらは、GTSM対応セッションの1つに属していると特定されたパケットですが、TTL値は予想される範囲内ではないため、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.
さまざまな分類のパケットに適用される正確なポリシーは、このドキュメントでは仮定されておらず、構成可能であると予想されます。特に、関連するメッセージの処理（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.
+ 危険として分類されたパケットが、信頼できるものまたは不明として分類されたパケットを使用してリソースを競わないようにする必要があります。
+ MUST NOT drop (as part of GTSM processing) packets classified as Trusted or Unknown.
+ （GTSM処理の一部として）信頼できるまたは不明として分類されたパケットをドロップしてはなりません。
+ MAY drop packets classified as Dangerous.
+ 危険として分類されたパケットをドロップする場合があります。
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.
BGPを保護するためのTTLフィールドの使用は、Paul TrainaやJon Stewartを含む多くの異なる人々から生まれました。ライアン・マクダウェルも同様のアイデアを提案しました。Steve Bellovin、Jay Borkenhagen、Randy Bush、Alfred Hoenes、Vern Paxon、Robert Raszuk、およびAlex Zininも、この文書の以前のバージョンに関する有用なフィードバックを提供しました。David Wardは、元のBGP固有のアイデアの一般化に関する洞察を提供しました。Alex Zinin、Alia Atlas、およびJohn Scudderは、ドキュメントの新しいバージョンにかなりの量のフィードバックを提供しました。IETFの最後の呼び出し中および最後のコールの後、フランシスデュポン、サムハートマン、ラースエガート、ロスコロンによって有用なコメントが提供されました。
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は、ピアが侵害されている場合を除き、シングルホッププロトコルセッションを保護する簡単な手順です。特に、幅広いワイヤー攻撃から保護していません。これらの攻撃からの保護には、より厳格なセキュリティメカニズムが必要です。
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（またはホップ制限）値がスプーフィングに対して非重要であるという観察に基づいています。パケットが宛先に向かってルーターを通過すると、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 has not been tunneled to the decapsulator, and the intervening routers are operating in accordance with RFC 791 [RFC0791]).
ただし、任意の場所から供給されたときに特定の値を持つようにパケットのTTLをエンジニアリングすることは困難ですが（不可能ではありません）、非方向に接続された場所から255のTTL値をエンジニアリングすることは不可能です（繰り返しますが、繰り返しますが、仮定してください。直接接続された隣人はいずれも妥協しておらず、パケットは脱カプセレータにトンネルを張られておらず、介在するルーターはRFC 791 [RFC0791]に従って動作しています。
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).
TTLのパケットが255のパケットを持つという観察の例外は、プロトコルパケットがトンネル化され、トンネルが整合性で保護されていない場合に発生する可能性があります（つまり、下層が損なわれます）。
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.
プロトコルパケットがプロトコルピアに直接トンネル化される場合（つまり、プロトコルピアは脱カプセレーターです）、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は隣接するルーターを越えて攻撃を阻止するのに役立ちます。
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 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].
トンネルテールエンドがプロトコルパケットを脱カプセル化し、その後、パケットを直接接続されたプロトコルピアにIPに復活させると、TTLは以下に説明するように減少します。これは、トンネルの脱カプセレータがGTSM保護されたプロトコルピアの視点からの最後から2番目のノードであることを意味します。その結果、GTSMチェックは、ピアにパケットをカプセル化する攻撃者から保護します。ただし、トンネルの脱カプセレーターノードからプロトコルピアへの接続がIP転送ホップではない場合に特定のケースが発生し、TTLデッキングが発生しません（レイヤー2トンネリング、ブリッジングなど）。IPSECアーキテクチャ[RFC4301]では、別の例として、ワイヤーの隆起（BITW）[BITW]の使用です。
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上でProtocol PeerまたはDecapsurator（トンネルエンドポイント）に直接トンネル化され、パケットを直接接続されたプロトコルピアに転送できます。IP経由のトンネルIPの例には、IP-in-IP [RFC2003]、GRE [RFC2784]、およびさまざまな形態のIPv6-in-IPV4（例えば[RFC4213]）が含まれます。これらのケースを以下に示します。
Peer router ---------- Tunnel endpoint router and peer
TTL=255 [tunnel] [TTL=255 at ingress]
[TTL=255 at processing]
Peer router -------- Tunnel endpoint router ----- On-link peer
TTL=255 [tunnel] [TTL=255 at ingress] [TTL=254 at ingress]
[TTL=254 at egress]
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:
どちらの場合も、カプセレータ（オリジネーショントンネルエンドポイント）は、プロトコルピアを送信する（想定）です。RFC 2003は次の動作を指定しているため、内部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番目のケースでは、カプセル化されたパケットがデカプセーター（トンネルエンドポイント）にトンネルされ、直接接続されたプロトコルピアに転送されます。IP-in-IPトンネルの場合、RFC 2003は次の脱カプセレーターの動作を指定します。
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 interfaces, it will decrement the TTL as a result of doing normal IP forwarding. See also Section 4.4.
内側のIPヘッダーのTTLは、脱カプセル化の場合は変更されません。脱カプセル化後、内側のデータグラムにttl = 0の場合、脱カプセレータはデータグラムを破棄する必要があります。脱カプセル化後、脱カプセーターがデータグラムをネットワークインターフェイスの1つに転送すると、通常のIP転送の結果としてTTLが減少します。セクション4.4も参照してください。
And similarly, for GRE tunnels, RFC 2784 specifies the following decapsulator behavior:
同様に、GREトンネルの場合、RFC 2784は次の脱カプセーターの動作を指定します。
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パケットを脱カプセル化する場合、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).
したがって、脱カプセレータで見られるように、内側のIPパケットヘッダーのTTLは、任意の値（特に255）に設定できます。カプセレータがプロトコルピアでもある場合、255のTTLでプロトコルパケットを配信することができます（最初のケース）。一方、脱カプセレータがプロトコルパケットを直接接続されたプロトコルピアに転送する必要がある場合、TTLは減少します（2番目のケース）。
Protocol packets may also be tunneled over MPLS Label Switched Paths (LSPs) to a protocol peer. The following diagram depicts the topology.
プロトコルパケットは、MPLSラベルスイッチ付きパス（LSP）をプロトコルピアにトンネル化することもできます。次の図はトポロジーを示しています。
Peer router -------- LSP Termination router and peer
TTL=255 MPLS LSP [TTL=x at ingress]
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 LSPは、均一またはパイプトンネリングモデルで動作できます。これらのモデルのTTL処理は、MPLSネットワークのTTL処理に関してRFC 3032 [RFC3032]を更新するRFC 3443 [RFC3443]で説明されています。RFC 3443は、均一モデルとパイプモデルの両方でTTL処理を指定し、最後から2番目のホップポップ（PHP）で使用できない場合と使用できない場合があります。これらの場合のTTL処理は異なる動作をもたらすため、個別に分析されます。RFC 3443のセクション3.3からセクション3.3を参照してください。
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).
LSPターミネーションノードでの均一モデルとパイプモデルの間のTTL処理の観点からの主な違いは、着信TTL（ITTL）の決定方法にあります。トンネリングモデルはITTLを決定します。均一なモデルLSPの場合、ITTLはポップされたMPLSヘッダー（カプセル化ヘッダー）からのTTLフィールドの値ですが、パイプモデルLSPの場合、ITTLは露出したヘッダーからのTTLフィールドの値です。（カプセル化されたヘッダー）。
For Uniform Model LSPs, RFC 3443 states that at ingress:
均一なモデルLSPの場合、RFC 3443は、Ingressで次のように述べています。
For each pushed Uniform Model label, the TTL is copied from the label/IP-packet immediately underneath it.
プッシュされた均一なモデルラベルごとに、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に等しくなります（RFC 3443のセクション3.1を参照してください）。その結果、複数のホップの均一なモデルLSPの場合、IngressのTTL（ITTL）は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処理は、PHPのない短いパイプモデルLSPとパイプモデルLSPS（PHPのみなし）の間で同一です。これらの場合、RFC 3443は次のように述べています。
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.
プッシュされたパイプモデルまたはショートパイプモデルラベルごとに、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).
これらのモデルでは、出口での転送処理は、カプセル化パケットとは対照的に、トンネルパケットに基づいています。Ingress TTL（ITTL）は、公開されているヘッダーのTTLフィールドの値、つまりTunneled IP Datagramの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を使用した短いパイプモデルLSPの場合、PHP操作後にトンネルパケットのTTLが変更されません。したがって、PHPとパイプモデルLSPのない短いパイプモデルLSPに関して描かれた同じ結論（PHPのみなし）がこのケースに適用されます。短いパイプモデルLSPの場合、出口の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チェックは、パイプモデルLSPを介してIPトンネリングを使用する可能性がありますが、均一なモデルLSPを介したIPトンネルを使用することはできません。さらに、すべてのトンネリングモードについて、LSPターミネーションルーターがプロトコルパケットを直接接続されたプロトコルピアに転送する必要がある場合、255のTTLでプロトコルパケットをプロトコルピアに配信することはできません。パケットがさらに転送された場合、発信TTL（OTTL）は、ITTLを1つ減らすことによって計算されます。
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ピアのアドレスをスプーフィングすることにより）で妨害する可能性があります。その結果、そのような保護を含めないインターフェイスは、ルーターへの攻撃を開始しないと信頼する必要があります。
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フラグメントにはレイヤー4情報が含まれていないため、登録されたGTSM対応セッションに関連付けられない可能性が高くなります。セクション3で説明されている受信プロトコル手順に続いて、非独創的なIPフラグメントは、不明な信頼性で分類される可能性があります。また、IPパケットを処理するために再組み立てする必要があるため、最終結果は、GTSM対応セッションの初期折り畳みが不明な信頼性パケットの処理を効果的に受信し、完全な再構築パケットが集計を受信することです。未知のもの。
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チェックに合格しない場合、再組み立てされたパケットは危険な信頼性パケットとして分類され、対応する治療を受けます。
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 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].
その結果、フラグメント攻撃から実際的な保護を得るには、オペレーターが受信したすべてのフラグメントを評価または破棄する必要がある場合があります。そのため、Path MTU Discovery（PMTUD）、または他の利用可能な方法[RFC1981]、[RFC1981]、[RFC48211などの適応測定を使用して、手動MTUチューニングによる断片化と再組み立てを避けるために、GTSM保護プロトコルに強くお勧めします。]。
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は、マルチホッププロトコルセッションで使用すると、定量化が困難ですが、定量化が困難ですが、保護の程度を提供する可能性があります（付録Aを参照）。保護の程度と結果として生じるマルチホップの適用性を定量化する必要がないようにするために、セキュリティプロパティがより明確であるため、シングルホップのケースのみを説明します。
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は、本質的に限られたトポロジを持つ環境にのみ適用できます（プロトコルピアが直接接続されている場合に最も効果的です）。特に、そのアプリケーションは、プロトコルピアが直接接続されているケースに限定する必要があります。
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は、正当なピアと同じくらい保護されたステーションに近い攻撃者から保護しません。たとえば、正当なピアが1つのホップアウェイである場合、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が適用される可能性のあるマルチホップシナリオには、次の特性があると予想されます。ピア間のトポロジーはかなり静的でよく知られており、介在するネットワーク（ピア間）が信頼されています。
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.
RFC 3682 [RFC3682]は、「関連するメッセージ」（ICMPエラー）を処理する方法を指定しませんでした。この仕様には、それらのTTL = 255の設定と検証と、メインプロトコルパケットの検証が義務付けられています。
Setting TTL=255 in related messages does not cause issues for RFC 3682 implementations.
関連するメッセージにTTL = 255を設定しても、RFC 3682実装の問題はありません。
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 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.
関連するメッセージでTTL = 255を必要とすることは、RFC 3682実装に影響を与える可能性があります。いくつかの実装は255を使用することが知られていますが、64以外の値も使用されます。RFC 3682実装の後者のカテゴリからの関連メッセージは、危険として分類され、セクション3で説明されているように扱われます。これは、プロトコルは関連メッセージに依存しないため、重要な問題であるとは考えられていません（例えば、クロージングのためのプロトコル交換がありますTCP-RSTを実行する代わりにセッション）、そして実際に関連するメッセージの配信は信頼できません。そのため、関連するメッセージは通常、プロトコルのKeepalive Timeoutを短縮するための最適化を提供します。これらの問題に関係なく、関連するメッセージがプロトコルセッションをリセットするための重要な攻撃ベクトルを提供することを考えると、このさらなる制限を賢明にするように思われます。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003] Perkins、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、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. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「Generic Routing Cancapstulation（GRE）」、RFC 2784、2000年3月。
[RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002.
[RFC3392] Chandra、R。およびJ. Scudder、「BGP-4による機能広告」、RFC 3392、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）処理」、RFC 3443、2003年1月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmark、E。およびR. Gilligan、「IPv6ホストとルーターの基本的な遷移メカニズム」、RFC 4213、2005年10月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、Li、T。、およびS. Hares、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[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] "スレッド： 'IP-in-IP、TTLが転送時に減少し、int-areaリストでbitw'、メッセージ-id：<pine.lnx.4.64.0606020830220.12705@netcore.fi>"、2006年6月、<httpp：//www1.ietf.org/mail-archive/web/ int-area/current/msg00267.html>。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のPath MTU Discovery」、RFC 1981、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] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「Mpls Label Stack Encoding」、RFC 3032、2001年1月。
[RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL Security Mechanism (GTSM)", RFC 3682, February 2004.
[RFC3682] Gill、V.、Heasley、J。、およびD. Meyer、「一般化されたTTLセキュリティメカニズム（GTSM）」、RFC 3682、2004年2月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704] Baker、F。およびP. Savola、「マルチホームネットワークのイングレスフィルタリング」、BCP 84、RFC 3704、2004年3月。
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006.
[RFC4272] Murphy、S。、「BGP Security脆弱性分析」、RFC 4272、2006年1月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、2007年3月。
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の確認）。そのような展開は、より限られた適用性と異なるセキュリティへの影響を持つと予想されるため、このドキュメントでは指定されていません。
o Bring the work on the Standards Track (RFC 3682 was Experimental).
o 標準トラックで作業を届けます（RFC 3682は実験的でした）。
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 関連するメッセージ（ICMPエラー）を送信してチェックしてTTL = 255を確認する必要があることが明示的に必要です。後方互換性に関する議論については、セクション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 Gillメール：vijay@umbc.edu
John Heasley EMail: heas@shrubbery.net
John Heasleyメール：heas@shrubbery.net
David Meyer EMail: dmm@1-4-5.net
David Meyerメール：dmm@1-4-5.net
Pekka Savola (editor) Espoo Finland EMail: psavola@funet.fi
Pekka Savola（編集者）Espoo Finlandメール：psavola@funet.fi
Carlos Pignataro EMail: cpignata@cisco.com
Carlos Pignataroメール：cpignata@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。