[要約] RFC 6720は、ラベル配布プロトコル（LDP）のための一般化されたTTLセキュリティメカニズム（GTSM）に関するものです。このRFCの目的は、LDPセッションのセキュリティを向上させるために、GTSMを使用する方法を提案することです。
Internet Engineering Task Force (IETF) C. Pignataro
Request for Comments: 6720 R. Asati
Updates: 5036 Cisco Systems
Category: Standards Track August 2012
ISSN: 2070-1721
The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP)
ラベル配布プロトコル（LDP）の一般化されたTTLセキュリティメカニズム（GTSM）
Abstract
概要
The Generalized TTL Security Mechanism (GTSM) describes a generalized use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify that the packet was sourced by a node on a connected link, thereby protecting the router's IP control plane from CPU utilization-based attacks. This technique improves security and is used by many protocols. This document defines the GTSM use for the Label Distribution Protocol (LDP).
一般化されたTTLセキュリティメカニズム（GTSM）は、パケットの存続時間（TTL）（IPv4）またはホップリミット（IPv6）の一般化された使用法を説明し、接続されたリンク上のノードがパケットのソースであることを確認して、ルーターのIPを保護しますCPU使用率ベースの攻撃からのコントロールプレーン。この手法はセキュリティを向上させ、多くのプロトコルで使用されます。このドキュメントでは、Label Distribution Protocol（LDP）でのGTSMの使用を定義しています。
This specification uses a bit reserved in RFC 5036 and therefore updates RFC 5036.
この仕様はRFC 5036で予約されているビットを使用するため、RFC 5036を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6720.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6720で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................3
1.2. Scope ......................................................3
2. GTSM Procedures for LDP .........................................4
2.1. GTSM Flag in the Common Hello Parameter TLV ................4
2.2. GTSM Sending and Receiving Procedures for LDP Link Hello ...5
2.3. GTSM Sending and Receiving Procedures for LDP
Initialization .............................................5
3. LDP Peering Scenarios and GTSM Considerations ...................5
4. Security Considerations .........................................6
5. Acknowledgments .................................................7
6. References ......................................................7
6.1. Normative References .......................................7
6.2. Informative References .....................................8
LDP [RFC5036] specifies two peer discovery mechanisms, a Basic one and an Extended one, both using UDP transport. The Basic Discovery mechanism is used to discover LDP peers that are directly connected at the link level, whereas the Extended Discovery mechanism is used to locate Label Switching Router (LSR) neighbors that are not directly connected at the link level. Once discovered, the LSR neighbors can establish the LDP peering session, using the TCP transport connection.
LDP [RFC5036]は、基本的な拡張メカニズムと拡張された拡張メカニズムの2つのピア検出メカニズムを指定します。どちらもUDPトランスポートを使用します。基本検出メカニズムは、リンクレベルで直接接続されているLDPピアを検出するために使用されますが、拡張検出メカニズムは、リンクレベルで直接接続されていないラベルスイッチングルータ（LSR）ネイバーを見つけるために使用されます。検出されると、LSRネイバーは、TCPトランスポート接続を使用して、LDPピアリングセッションを確立できます。
The Generalized TTL Security Mechanism (GTSM) [RFC5082] is a mechanism based on IPv4 Time To Live (TTL) or IPv6 Hop Limit value verification so as to provide a simple and reasonably robust defense from infrastructure attacks using forged protocol packets from outside the network. GTSM can be applied to any protocol peering session that is established between routers that are adjacent. Therefore, GTSM can protect an LDP protocol peering session established using Basic Discovery.
Generalized TTL Security Mechanism（GTSM）[RFC5082]は、IPv4 Time To Live（TTL）またはIPv6ホップリミット値の検証に基づくメカニズムであり、ネットワーク外部からの偽造プロトコルパケットを使用したインフラストラクチャ攻撃からのシンプルで適度に堅牢な防御を提供します。 。 GTSMは、隣接するルーター間で確立された任意のプロトコルピアリングセッションに適用できます。したがって、GTSMは、基本検出を使用して確立されたLDPプロトコルピアリングセッションを保護できます。
This document specifies LDP enhancements to accommodate GTSM. In particular, this document specifies the enhancements in the following areas:
このドキュメントでは、GTSMに対応するためのLDPの機能強化について説明しています。特に、このドキュメントでは、次の領域での機能強化について説明しています。
1. The Common Hello Parameter TLV of LDP Link Hello message
1. LDPリンクHelloメッセージの共通HelloパラメータTLV
2. Sending and Receiving procedures for LDP Link Hello message
2. LDPリンクHelloメッセージの送受信手順
3. Sending and Receiving procedures for LDP Initialization message
3. LDP初期化メッセージの送受信手順
GTSM specifies that "it SHOULD NOT be enabled by default in order to remain backward compatible with the unmodified protocol" (see Section 3 of [RFC5082]). This document specifies a "built-in dynamic GTSM capability negotiation" for LDP to suggest the use of GTSM. GTSM will be used as specified in this document provided both peers on an LDP session can detect each others' support for GTSM procedures and agree to use it. That is, the desire to use GTSM (i.e., its negotiation mechanics) is enabled by default without any configuration.
GTSMは、「変更されていないプロトコルとの下位互換性を維持するために、デフォルトで有効にすべきではない」と規定しています（[RFC5082]のセクション3を参照）。このドキュメントでは、LDPがGTSMの使用を提案するための「組み込みの動的GTSM機能ネゴシエーション」を指定しています。 LDPセッションの両方のピアがGTSMプロシージャに対する互いのサポートを検出し、それを使用することに同意できる場合、GTSMはこのドキュメントで指定されているとおりに使用されます。つまり、GTSM（つまり、そのネゴシエーションメカニズム）を使用したいという要望は、デフォルトで設定なしで有効になっています。
This specification uses a bit reserved in Section 3.5.2 of [RFC5036] and therefore updates [RFC5036].
この仕様では、[RFC5036]のセクション3.5.2で予約されているビットを使用しているため、[RFC5036]を更新します。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document defines procedures for LDP using IPv4 routing but not for LDP using IPv6 routing, since the latter has GTSM built into the protocol definition [LDP-IPV6].
このドキュメントでは、IPv4ルーティングを使用するLDPの手順を定義していますが、IPv6ルーティングを使用するLDPの手順は定義していません。後者は、プロトコル定義[LDP-IPV6]にGTSMが組み込まれているためです。
Additionally, the GTSM for LDP specified in this document applies only to single-hop LDP peering sessions and not to multi-hop LDP peering sessions, in line with Section 5.5 of [RFC5082]. Consequently, any LDP method or feature (such as LDP IGP Synchronization [RFC5443] or LDP Session Protection [LDP-SPROT]) that relies on multi-hop LDP peering sessions would not work with GTSM and will require (statically or dynamically) disabling the GTSM capability. See Section 3.
さらに、このドキュメントで指定されているLDPのGTSMは、[RFC5082]のセクション5.5に従って、シングルホップLDPピアリングセッションにのみ適用され、マルチホップLDPピアリングセッションには適用されません。その結果、マルチホップLDPピアリングセッションに依存するLDPメソッドまたは機能（LDP IGP同期[RFC5443]またはLDPセッション保護[LDP-SPROT]など）は、GTSMでは機能せず、（静的または動的に）を無効にする必要があります。 GTSM機能。セクション3を参照してください。
A new flag in the Common Hello Parameter TLV, named G flag (for GTSM), is defined by this document in a previously reserved bit. An LSR indicates that it is capable of applying GTSM procedures, as defined in this document, to the subsequent LDP peering session, by setting the GTSM flag to 1. The Common Hello Parameters TLV, defined in Section 3.5.2 of [RFC5036], is updated as shown in Figure 1.
Common Hello Parameter TLVの新しいフラグであるGフラグ（GTSM用）は、このドキュメントで以前に予約されていたビットで定義されています。 LSRは、GTSMフラグを1に設定することにより、このドキュメントで定義されているように、GTSM手順を後続のLDPピアリングセッションに適用できることを示します。[RFC5036]のセクション3.5.2で定義されているCommon Hello Parameters TLV図1に示すように更新されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Common Hello Parms(0x0400)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hold Time |T|R|G| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
T, Targeted Hello As specified in [RFC5036].
T、[こんにちは] [RFC5036]で指定されているように。
R, Request Send Targeted Hellos As specified in [RFC5036].
R、[RFC5036]で指定されているように、ターゲットのHelloの送信を要求します。
G, GTSM A value of 1 specifies that this LSR supports GTSM procedures, where a value of 0 specifies that this LSR does not support GTSM.
G、GTSM値1は、このLSRがGTSMプロシージャをサポートすることを指定します。値0は、このLSRがGTSMをサポートしないことを指定します。
Reserved This field is reserved. It MUST be set to zero on transmission and ignored on receipt.
予約済みこのフィールドは予約済みです。送信時にはゼロに設定し、受信時には無視する必要があります。
Figure 1: GTSM Flag in the Common Hello Parameter TLV
図1：共通のHelloパラメーターTLVのGTSMフラグ
The G flag is meaningful only if the T flag is set to 0 (which must be the case for Basic Discovery); otherwise, the value of the G flag is ignored on receipt.
Gフラグが意味を持つのは、Tフラグが0に設定されている場合のみです（これは、基本ディスカバリーの場合に当てはまります）。それ以外の場合、Gフラグの値は受信時に無視されます。
Any LSR not supporting GTSM for LDP as defined in this document (i.e., an LSR that does not recognize the G flag) would continue to ignore the G flag, independent of the values of the T and R flags, as per Section 3.5.2 of [RFC5036]. Similarly, an LSR that does recognize the G flag but that does not support GTSM (either because it is not implemented or because it is so configured) would not set the G flag (i.e., G=0) when sending LDP Link Hellos and would effectively ignore the G flag when receiving LDP Link Hello messages.
このドキュメントで定義されているLDPのGTSMをサポートしていないLSR（つまり、Gフラグを認識しないLSR）は、3.5.2項のように、TフラグとRフラグの値に関係なく、引き続きGフラグを無視します。 [RFC5036]の。同様に、Gフラグを認識しているが（実装されていないか、そのように構成されているため）GTSMをサポートしないLSRは、LDPリンクHelloを送信するときにGフラグ（つまり、G = 0）を設定せず、 LDP Link Helloメッセージの受信時にGフラグを効果的に無視します。
First, LSRs using LDP Basic Discovery [RFC5036] send LDP Hello messages to link-level multicast address (224.0.0.2 or "all routers"). Such messages are never forwarded beyond one hop and are RECOMMENDED to have their IP TTL or Hop Count = 1.
まず、LDP Basic Discovery [RFC5036]を使用するLSRはLDP Helloメッセージをリンクレベルのマルチキャストアドレス（224.0.0.2または「すべてのルーター」）に送信します。このようなメッセージは1ホップを超えて転送されることはなく、IP TTLまたはホップカウント= 1にすることをお勧めします。
Unless configured otherwise, an LSR that supports GTSM procedures MUST set the G flag (for GTSM) to 1 in the Common Hello Parameter TLV in the LDP Link Hello message [RFC5036].
特に設定されていない限り、GTSMプロシージャをサポートするLSRは、LDPリンクHelloメッセージ[RFC5036]のCommon Hello Parameter TLVでGフラグ（GTSM用）を1に設定する必要があります。
If an LSR that supports GTSM and is configured to use it recognizes the presence of the G flag (in the Common Hello Parameter TLV) with the value = 1 in the received LDP Link Hello message, then it MUST enforce GTSM for LDP in the subsequent TCP/LDP peering session with the neighbor that sent the Hello message, as specified in Section 2.3 of this document.
GTSMをサポートし、それを使用するように構成されているLSRが、受信したLDPリンクHelloメッセージに値= 1のGフラグ（共通HelloパラメーターTLV内）の存在を認識している場合、それ以降のLDPにGTSMを適用する必要があります。このドキュメントのセクション2.3で指定されている、Helloメッセージを送信したネイバーとのTCP / LDPピアリングセッション。
If an LSR does not recognize the presence of the G flag (in the Common Hello Parameter TLV of Link Hello message), or recognizes the presence of G flag with the value = 0, then the LSR MUST NOT enforce GTSM for LDP in the subsequent TCP/LDP peering session with the neighbor that sent the Hello message. This ensures backward compatibility as well as automatic GTSM deactivation.
LSRがGフラグの存在を認識しない場合（Link HelloメッセージのCommon Hello Parameter TLV内）、または値が0のGフラグの存在を認識する場合、LSRは後続のLDPにGTSMを強制してはなりません（MUST NOT） Helloメッセージを送信したネイバーとのTCP / LDPピアリングセッション。これにより、下位互換性と自動GTSM非アクティブ化が保証されます。
If an LSR that has sent and received LDP Link Hello with G flag = 1 from the directly connected neighbor, then the LSR MUST enforce GTSM procedures, as defined in Section 3 of [RFC5082], in the forthcoming TCP Transport Connection with that neighbor. This means that the LSR MUST check for the incoming unicast packets' TTL or Hop Count to be 255 for the particular LDP/TCP peering session and decide the further processing as per [RFC5082].
直接接続されたネイバーからGフラグ= 1のLDPリンクHelloを送受信したLSRは、[RFC5082]のセクション3で定義されているように、そのネイバーとのTCPトランスポート接続でGTSM手順を実施する必要があります。これは、LSRが特定のLDP / TCPピアリングセッションの着信ユニキャストパケットのTTLまたはホップカウントが255であることを確認し、[RFC5082]に従ってさらなる処理を決定する必要があることを意味します。
If an LSR that has sent LDP Link Hello with G flag = 1, but received LDP Link Hello with G flag = 0 from the directly connected neighbor, then the LSR MUST NOT enforce GTSM procedures, as defined in Section 3 of [RFC5082], in the forthcoming TCP Transport Connection with that neighbor.
Gフラグ= 1でLDPリンクHelloを送信したが、直接接続されたネイバーからGフラグ= 0でLDPリンクHelloを受信したLSRは、[RFC5082]のセクション3で定義されているように、LSMがGTSM手順を強制してはならない（MUST NOT）。そのネイバーとの次のTCPトランスポート接続で。
This section discusses GTSM considerations arising from the LDP peering scenarios used, including single-hop versus multi-hop LDP neighbors, as well as the use of LDP Basic Discovery versus Extended Discovery.
このセクションでは、シングルホップLDPネイバーとマルチホップLDPネイバー、およびLDP基本検出と拡張検出の使用など、使用されるLDPピアリングシナリオから生じるGTSMの考慮事項について説明します。
The reason that the GTSM capability negotiation is enabled for Basic Discovery by default (i.e., G=1) but not for Extended Discovery is that the usage of Basic Discovery typically relates to a single-hop LDP peering session, whereas the usage of Extended Discovery typically relates to a multi-hop LDP peering session. GTSM protection for multi-hop LDP sessions is outside the scope of this specification (see Section 1.2). However, it is worth clarifying the following exceptions that may occur with Basic or Extended Discovery usage:
GTSM機能ネゴシエーションがデフォルトで有効になっている（つまり、G = 1）が拡張ディスカバリーではない理由は、基本ディスカバリーの使用は通常、シングルホップLDPピアリングセッションに関連しているのに対し、拡張ディスカバリーの使用は通常、マルチホップLDPピアリングセッションに関連しています。マルチホップLDPセッションのGTSM保護は、この仕様の範囲外です（セクション1.2を参照）。ただし、基本または拡張ディスカバリーの使用で発生する可能性がある以下の例外を明確にすることは価値があります。
a. Two adjacent LSRs (i.e., back-to-back PE routers) forming a single-hop LDP peering session after doing an Extended Discovery (e.g., for Pseudowire signaling)
a. 2つの隣接するLSR（つまり、バックツーバックPEルーター）は、拡張ディスカバリー（たとえば、疑似配線シグナリング用）を実行した後、シングルホップLDPピアリングセッションを形成します。
b. Two adjacent LSRs forming a multi-hop LDP peering session after doing a Basic Discovery, due to the way IP routing is set up between them (either temporarily or permanently)
b. 2つの隣接するLSRは、それらの間でIPルーティングが（一時的または永続的に）セットアップされる方法により、基本検出の実行後にマルチホップLDPピアリングセッションを形成します。
c. Two adjacent LSRs (i.e., back-to-back PE routers) forming a single-hop LDP peering session after doing both Basic and Extended Discovery
c. 基本ディスカバリーと拡張ディスカバリーの両方を実行した後、シングルホップLDPピアリングセッションを形成する2つの隣接LSR（つまり、バックツーバックPEルーター）
In the first case (a), GTSM is not enabled for the LDP peering session by default. In the second case (b), GTSM is actually enabled by default and enforced for the LDP peering session; hence, it would prohibit the LDP peering session from getting established (note that this may impact features such as LDP IGP Synchronization [RFC5443] or LDP Session Protection [LDP-SPROT]). In the third case (c), GTSM is enabled by default for Basic Discovery and enforced on the subsequent LDP peering, and is not for Extended Discovery. However, if each LSR uses the same IPv4 transport address object value in both Basic and Extended Discoveries, then it would result in a single LDP peering session that would be enabled with GTSM. Otherwise, GTSM would not be enforced on the second LDP peering session corresponding to the Extended Discovery.
最初のケース（a）では、GTSMはデフォルトでLDPピアリングセッションに対して有効になっていません。 2番目のケース（b）では、GTSMは実際にはデフォルトで有効になっており、LDPピアリングセッションに適用されます。したがって、LDPピアリングセッションの確立が禁止されます（これは、LDP IGP同期[RFC5443]またはLDPセッション保護[LDP-SPROT]などの機能に影響を与える可能性があることに注意してください）。 3番目のケース（c）では、GTSMはデフォルトで基本検出に対して有効になっており、後続のLDPピアリングに適用されます。拡張検出には適用されません。ただし、各LSRが基本ディスカバリーと拡張ディスカバリーの両方で同じIPv4トランスポートアドレスオブジェクト値を使用する場合、GTSMで有効になる単一のLDPピアリングセッションになります。それ以外の場合、GTSMは拡張ディスカバリーに対応する2番目のLDPピアリングセッションに適用されません。
This document allows for the implementation to provide an option to statically (e.g., via configuration) and/or dynamically override the default behavior and enable/disable GTSM on a per-peer basis. This would address all the exceptions listed above.
このドキュメントでは、実装で静的に（たとえば、構成を介して）オプションを提供したり、デフォルトの動作を動的にオーバーライドしたり、ピアごとにGTSMを有効または無効にしたりできます。これは、上記のすべての例外に対処します。
This document increases the security for LDP, making it more resilient to off-link attacks. Security considerations for GTSM are detailed in Section 5 of [RFC5082].
このドキュメントは、LDPのセキュリティを強化し、オフリンク攻撃に対する耐性を高めます。 GTSMのセキュリティに関する考慮事項は、[RFC5082]のセクション5で詳しく説明されています。
As discussed in Section 3, it is possible that
セクション3で説明したように、
o GTSM for LDP may not always be enforced on a single-hop LDP peering session, and LDP may still be susceptible to forged/ spoofed protocol packets, if a single-hop LDP peering session is set up using Extended Discovery.
o 拡張ホップを使用してシングルホップLDPピアリングセッションがセットアップされている場合、GTSM for LDPはシングルホップLDPピアリングセッションで常に適用されるとは限りません。また、LDPは偽造/スプーフィングプロトコルパケットの影響を受ける可能性があります。
o GTSM for LDP may cause the LDP peering session to not get established (or may be torn down), if IP routing ever declares that the directly connected peer is more than one IP hop away. Suffice to say, use of cryptographic integrity (e.g., [RFC5925]) is recommended as an alternate solution for detecting forged protocol packets (especially for the multi-hop case).
o 直接接続されたピアが複数のIPホップ以上離れているとIPルーティングが宣言した場合、GTSM for LDPによってLDPピアリングセッションが確立されない（または切断される）可能性があります。偽造されたプロトコルパケット（特にマルチホップの場合）を検出するための代替ソリューションとして、暗号の整合性（[RFC5925]など）の使用をお勧めします。
The GTSM specification [RFC5082] says that protocol messages used for dynamic negotiation of GTSM support MUST be authenticated. However, LDP discovery [RFC5036] uses UDP transport and does not have an authentication mechanism. The GTSM specification further elaborates by saying that GTSM is not a substitute for authentication and does not secure against insider on-the-wire attacks. LDP Basic Discovery uses link-level multicast address (224.0.0.2 or "all routers") that are never forwarded beyond the link, and this acts as a basic protection against off-the-wire attacks.
GTSM仕様[RFC5082]では、GTSMサポートの動的ネゴシエーションに使用されるプロトコルメッセージは認証される必要があると述べています。ただし、LDPディスカバリ[RFC5036]はUDPトランスポートを使用し、認証メカニズムはありません。 GTSM仕様は、GTSMは認証の代わりにはならず、インサイダーの有線攻撃に対して保護されないと述べてさらに詳しく説明しています。 LDP基本ディスカバリーは、リンクを超えて転送されないリンクレベルのマルチキャストアドレス（224.0.0.2または「すべてのルーター」）を使用します。これは、有線攻撃に対する基本的な保護として機能します。
The authors of this document do not make any claims on the originality of the ideas described. The concept of GTSM for LDP has been proposed a number of times and is documented in both the Experimental and Standards Track specifications of GTSM. Among other people, we would like to acknowledge Enke Chen and Albert Tian for their document "TTL-Based Security Option for the LDP Hello Message".
このドキュメントの作成者は、説明されているアイデアの独創性についていかなる主張もしません。 GTSM for LDPのコンセプトは何度も提案されており、GTSMの実験トラックと標準トラックの仕様の両方で文書化されています。とりわけ、ドキュメント「LDP HelloメッセージのTTLベースのセキュリティオプション」について、Enke ChenとAlbert Tianに感謝いたします。
The authors would like to thank Loa Andersson, Bin Mo, Mach Chen, Vero Zheng, Adrian Farrel, Eric Rosen, Eric Gray, and Brian Weis for their thorough reviews and useful comments and suggestions.
著者は、徹底的なレビューと有用なコメントと提案を提供してくれたLoa Andersson、Bin Mo、Mach Chen、Vero Zheng、Adrian Farrel、Eric Rosen、Eric Grey、およびBrian Weisに感謝します。
[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月。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、Minei、I。、およびB. Thomas、「LDP仕様」、RFC 5036、2007年10月。
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.
[RFC5082] Gill、V.、Heasley、J.、Meyer、D.、Savola、P。、およびC. Pignataro、「一般化されたTTLセキュリティメカニズム（GTSM）」、RFC 5082、2007年10月。
[LDP-IPV6] Asati, R., Manral, V., Papneja, R., and C. Pignataro, "Updates to LDP for IPv6", Work in Progress, June 2012.
[LDP-IPV6] Asati、R.、Manral、V.、Papneja、R。、およびC. Pignataro、「Updates to LDP for IPv6」、Work in Progress、2012年6月。
[LDP-SPROT] Cisco Systems, Inc., "MPLS LDP Session Protection", <http://www.cisco.com/en/US/docs/ios-xml/ios/mp_ldp/ configuration/12-4m/mp-ldp-sessn-prot.html>.
[LDP-SPROT] Cisco Systems、Inc。、「MPLS LDP Session Protection」、<http://www.cisco.com/en/US/docs/ios-xml/ios/mp_ldp/ configuration / 12-4m / mp -ldp-sessn-prot.html>。
[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP Synchronization", RFC 5443, March 2009.
[RFC5443] Jork、M.、Atlas、A。、およびL. Fang、「LDP IGP Synchronization」、RFC 5443、2009年3月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「The TCP Authentication Option」、RFC 5925、2010年6月。
Authors' Addresses
著者のアドレス
Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 USA
Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park、NC 27709 USA
EMail: cpignata@cisco.com
Rajiv Asati Cisco Systems 7025-6 Kit Creek Road Research Triangle Park, NC 27709 USA
Rajiv Asati Cisco Systems 7025-6 Kit Creek Road Research Triangle Park、NC 27709 USA
EMail: rajiva@cisco.com