[要約] RFC 7349は、LDP（Label Distribution Protocol）Hello Cryptographic Authenticationの仕様を定義しており、LDPネットワークでの認証を強化するための方法を提供しています。このRFCの目的は、LDPネットワークのセキュリティを向上させ、不正なアクセスや攻撃から保護することです。
Internet Engineering Task Force (IETF) L. Zheng
Request for Comments: 7349 M. Chen
Category: Standards Track Huawei Technologies
ISSN: 2070-1721 M. Bhatia
Ionos Networks
August 2014
LDP Hello Cryptographic Authentication
LDP Hello暗号認証
Abstract
概要
This document introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages. It secures the Hello messages against spoofing attacks and some well-known attacks against the IP header. This document describes a mechanism to secure the LDP Hello messages using Hashed Message Authentication Code (HMAC) with the National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms.
このドキュメントでは、LDPがHelloメッセージを保護するために使用できる新しいオプションの暗号化認証TLVを紹介します。スプーフィング攻撃やIPヘッダーに対するよく知られた攻撃からHelloメッセージを保護します。このドキュメントでは、国立標準技術研究所（NIST）のセキュアハッシュ標準アルゴリズムファミリーでハッシュメッセージ認証コード（HMAC）を使用してLDP Helloメッセージを保護するメカニズムについて説明します。
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/rfc7349.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7349で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Cryptographic Authentication TLV . . . . . . . . . . . . . . 4
2.1. Optional Parameter for Hello Message . . . . . . . . . . 4
2.2. LDP Security Association . . . . . . . . . . . . . . . . 4
2.3. Cryptographic Authentication TLV Encoding . . . . . . . . 6
2.4. Sequence Number Wrap . . . . . . . . . . . . . . . . . . 7
3. Cryptographic Authentication Procedure . . . . . . . . . . . 8
4. Cross-Protocol Attack Mitigation . . . . . . . . . . . . . . 8
5. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . 8
5.1. Preparing the Cryptographic Key . . . . . . . . . . . . . 9
5.2. Computing the Hash . . . . . . . . . . . . . . . . . . . 9
5.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Processing Hello Message Using Cryptographic Authentication . 10
6.1. Transmission Using Cryptographic Authentication . . . . . 10
6.2. Receipt Using Cryptographic Authentication . . . . . . . 10
7. Operational Considerations . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 14
The Label Distribution Protocol (LDP) [RFC5036] sets up LDP sessions that run between LDP peers. The peers could either be directly connected at the link level or be multiple hops away. An LDP Label Switching Router (LSR) could either be configured with the identity of its peers or could discover them using LDP Hello messages. These messages are sent encapsulated in UDP addressed to "all routers on this subnet" or to a specific IP address. Periodic Hello messages are also used to maintain the relationship between LDP peers necessary to keep the LDP session active.
ラベル配布プロトコル（LDP）[RFC5036]は、LDPピア間で実行されるLDPセッションをセットアップします。ピアは、リンクレベルで直接接続することも、複数ホップ離れることもできます。 LDPラベルスイッチングルーター（LSR）は、ピアのIDを使用して構成するか、LDP Helloメッセージを使用してそれらを検出できます。これらのメッセージは、「このサブネット上のすべてのルーター」または特定のIPアドレスにアドレス指定されたUDPにカプセル化されて送信されます。定期的なHelloメッセージは、LDPセッションをアクティブに保つために必要なLDPピア間の関係を維持するためにも使用されます。
Since the Hello messages are sent using UDP and not TCP, these messages cannot use the security mechanisms defined for TCP [RFC5926]. While some configuration guidance is given in [RFC5036] to help protect against false discovery messages, it does not provide an explicit security mechanism to protect the Hello messages.
HelloメッセージはTCPではなくUDPを使用して送信されるため、これらのメッセージはTCP [RFC5926]に定義されたセキュリティメカニズムを使用できません。 [RFC5036]には、誤った検出メッセージから保護するための構成ガイダンスがいくつか記載されていますが、Helloメッセージを保護するための明示的なセキュリティメカニズムは提供されていません。
Spoofing a Hello message for an existing adjacency can cause the valid adjacency to time out and in turn can result in termination of the associated session. This can occur when the spoofed Hello specifies a smaller Hold Time, causing the receiver to expect Hellos within this smaller interval, while the true neighbor continues sending Hellos at the previously agreed lower frequency. Spoofing a Hello message can also cause the LDP session to be terminated directly, which can occur when the spoofed Hello specifies a different Transport Address, other than the previously agreed one between neighbors. Spoofed Hello messages have been observed and reported as a real problem in production networks [RFC6952].
既存の隣接関係のHelloメッセージをスプーフィングすると、有効な隣接関係がタイムアウトし、関連するセッションが終了する可能性があります。これは、スプーフィングされたHelloがより短いホールドタイムを指定し、レシーバーがこのより短い間隔内でHelloを期待するときに発生し、真のネイバーは以前に合意された低い周波数でHelloを送信し続けます。 Helloメッセージをスプーフィングすると、LDPセッションが直接終了することもあります。これは、スプーフィングされたHelloが、以前にネイバー間で合意したものとは異なるトランスポートアドレスを指定した場合に発生する可能性があります。スプーフィングされたHelloメッセージが確認され、実稼働ネットワークにおける実際の問題として報告されています[RFC6952]。
For Link Hello, [RFC5036] states that the threat of spoofed Hellos can be reduced by accepting Hellos only on interfaces to which LSRs that can be trusted are directly connected and ignoring Hellos not addressed to the "all routers on this subnet" multicast group. The Generalized TTL Security Mechanism (GTSM) provides a simple and reasonably robust defense mechanism for Link Hello [RFC6720], but it does not secure against packet spoofing attacks or replay attacks [RFC5082].
Link Helloの場合、[RFC5036]は、信頼できるLSRが直接接続されているインターフェイスでのみHelloを受け入れ、「このサブネット上のすべてのルーター」マルチキャストグループにアドレス指定されていないHelloを無視することで、なりすましHelloの脅威を軽減できると述べています。 Generalized TTL Security Mechanism（GTSM）は、Link Hello [RFC6720]にシンプルで適度に堅牢な防御メカニズムを提供しますが、パケットスプーフィング攻撃やリプレイ攻撃[RFC5082]に対しては安全ではありません。
Spoofing attacks via Targeted Hellos are a potentially more serious threat. [RFC5036] states that an LSR can reduce the threat of spoofed Targeted Hellos by filtering them and accepting only those originating at sources permitted by an access list. However, filtering using access lists requires LSR resources and does not prevent IP-address spoofing.
Targeted Helloを介したなりすまし攻撃は、より深刻な脅威になる可能性があります。 [RFC5036]は、LSRがそれらをフィルタリングし、アクセスリストによって許可されたソースで発信されたもののみを受け入れることにより、偽装されたターゲットHelloの脅威を軽減できると述べています。ただし、アクセスリストを使用したフィルタリングにはLSRリソースが必要であり、IPアドレススプーフィングを防止しません。
This document introduces a new Cryptographic Authentication TLV that is used in LDP Hello messages as an optional parameter. It enhances the authentication mechanism for LDP by securing the Hello message against spoofing attacks. It also introduces a cryptographic sequence number carried in the Hello messages that can be used to protect against replay attacks.
このドキュメントでは、LDP Helloメッセージでオプションパラメータとして使用される新しい暗号化認証TLVを紹介します。スプーフィング攻撃からHelloメッセージを保護することにより、LDPの認証メカニズムを強化します。また、リプレイ攻撃から保護するために使用できるHelloメッセージに含まれる暗号化シーケンス番号も導入しています。
Using this Cryptographic Authentication TLV, one or more secret keys (with corresponding Security Association (SA) IDs) are configured in each system. For each LDP Hello message, the key is used to generate and verify an HMAC Hash that is stored in the LDP Hello message. For the cryptographic hash function, this document proposes to use SHA-1, SHA-256, SHA-384, and SHA-512 defined in US NIST Secure Hash Standard (SHS) [FIPS-180-4]. The HMAC authentication mode defined in [RFC2104] is used. Of the above, implementations MUST include support for at least HMAC-SHA-256, SHOULD include support for HMAC-SHA-1, and MAY include support for HMAC-SHA-384 and HMAC-SHA-512.
この暗号化認証TLVを使用して、1つ以上の秘密鍵（対応するセキュリティアソシエーション（SA）ID付き）が各システムで構成されます。 LDP Helloメッセージごとに、キーは、LDP Helloメッセージに格納されているHMACハッシュを生成および検証するために使用されます。このドキュメントでは、暗号化ハッシュ関数について、US NIST Secure Hash Standard（SHS）[FIPS-180-4]で定義されているSHA-1、SHA-256、SHA-384、およびSHA-512の使用を提案しています。 [RFC2104]で定義されたHMAC認証モードが使用されます。上記のうち、実装は少なくともHMAC-SHA-256のサポートを含む必要があり、SHOULDはHMAC-SHA-1のサポートを含み、HMAC-SHA-384およびHMAC-SHA-512のサポートを含めることができます（MAY）。
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]で説明されているように解釈されます。
[RFC5036] defines the encoding for the Hello message. Each Hello message contains zero or more Optional Parameters, each encoded as a TLV. Three Optional Parameters are defined by [RFC5036]. This document defines a new Optional Parameter: the Cryptographic Authentication parameter.
[RFC5036]は、Helloメッセージのエンコーディングを定義します。各Helloメッセージには0個以上のオプションパラメータが含まれ、それぞれがTLVとしてエンコードされます。 [RFC5036]によって3つのオプションパラメータが定義されています。このドキュメントでは、新しいオプションパラメータである暗号化認証パラメータを定義します。
Optional Parameter Type
-------------------------------- --------
IPv4 Transport Address 0x0401 (RFC 5036)
Configuration Sequence Number 0x0402 (RFC 5036)
IPv6 Transport Address 0x0403 (RFC 5036)
Cryptographic Authentication TLV 0x0405 (this document)
The encoding for the Cryptographic Authentication TLV is described in Section 2.3.
暗号化認証TLVのエンコーディングについては、セクション2.3で説明しています。
An LDP Security Association (SA) contains a set of parameters shared between any two legitimate LDP speakers.
LDP Security Association（SA）には、2つの正当なLDPスピーカー間で共有される一連のパラメータが含まれています。
Parameters associated with an LDP SA are as follows:
LDP SAに関連するパラメータは次のとおりです。
o Security Association Identifier (SA ID)
o せくりｔｙ あっそしあちおん いでんちふぃえｒ （さ いＤ）
This is a 32-bit unsigned integer used to uniquely identify an LDP SA between two LDP peers, as manually configured by the network operator (or, possibly by some key management protocol specified by the IETF in the future).
これは32ビットの符号なし整数で、ネットワークオペレーター（または将来IETFによって指定されるいくつかのキー管理プロトコル）によって手動で構成されるように、2つのLDPピア間のLDP SAを一意に識別するために使用されます。
The receiver determines the active SA by looking at the SA ID field in the incoming Hello message.
受信者は、着信HelloメッセージのSA IDフィールドを確認して、アクティブなSAを決定します。
The sender, based on the active configuration, selects an SA to use and puts the correct SA ID value associated with the SA in the LDP Hello message. If multiple valid and active LDP SAs exist for a given interface, the sender may use any of those SAs to protect the packet.
送信者は、アクティブな構成に基づいて、使用するSAを選択し、SAに関連付けられた正しいSA ID値をLDP Helloメッセージに書き込みます。特定のインターフェイスに複数の有効でアクティブなLDP SAが存在する場合、送信者はそれらのSAのいずれかを使用してパケットを保護できます。
Using SA IDs makes changing keys while maintaining protocol operation convenient. Each SA ID specifies two independent parts, the authentication algorithm and the authentication key, as explained below.
SA IDを使用すると、プロトコルの操作を維持しながらキーを変更できます。各SA IDは、以下で説明するように、認証アルゴリズムと認証キーの2つの独立した部分を指定します。
Normally, an implementation would allow the network operator to configure a set of keys in a key chain, with each key in the chain having a fixed lifetime. The actual operation of these mechanisms is outside the scope of this document.
通常、実装により、ネットワークオペレーターは、キーチェーン内のキーのセットを構成できます。チェーン内の各キーは、有効期間が固定されています。これらのメカニズムの実際の操作は、このドキュメントの範囲外です。
Note that each SA ID can indicate a key with a different authentication algorithm. This allows the introduction of new authentication mechanisms without disrupting existing LDP sessions.
各SA IDは、異なる認証アルゴリズムのキーを示す可能性があることに注意してください。これにより、既存のLDPセッションを中断することなく、新しい認証メカニズムを導入できます。
o Authentication Algorithm
o 認証アルゴリズム
This signifies the authentication algorithm to be used with the LDP SA. This information is never sent in clear text over the wire. Because this information is not sent on the wire, the implementer chooses an implementation-specific representation for this information.
これは、LDP SAで使用される認証アルゴリズムを示します。この情報がネットワーク上でクリアテキストで送信されることはありません。この情報はネットワーク上で送信されないため、実装者はこの情報の実装固有の表現を選択します。
Currently, the following algorithms are supported:
現在、次のアルゴリズムがサポートされています。
HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512.
HMAC-SHA-1、HMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512。
o Authentication Key
o 認証キー
This value denotes the cryptographic authentication key associated with the LDP SA. The length of this key is variable and depends upon the authentication algorithm specified by the LDP SA.
この値は、LDP SAに関連付けられた暗号化認証キーを示します。このキーの長さは可変であり、LDP SAによって指定された認証アルゴリズムによって異なります。
o KeyStartAccept
o KeyStartAccept
The time that this LDP router will accept packets that have been created with this LDP Security Association.
このLDPルータが、このLDPセキュリティアソシエーションで作成されたパケットを受け入れる時間。
o KeyStartGenerate
o KeyStartGenerate
The time that this LDP router will begin using this LDP Security Association for LDP Hello message generation.
このLDPルータがLDP Helloメッセージ生成のためにこのLDPセキュリティアソシエーションを使用し始める時間。
o KeyStopGenerate
o KeyStopGenerate
The time that this LDP router will stop using this LDP Security Association for LDP Hello message generation.
このLDPルーターがこのLDP Security Association for LDP Helloメッセージ生成の使用を停止する時間。
o KeyStopAccept
o KeyStopAccept
The time that this LDP router will stop accepting packets generated with this LDP Security Association.
このLDPルータが、このLDPセキュリティアソシエーションで生成されたパケットの受け入れを停止する時間。
In order to achieve smooth key transition, KeyStartAccept SHOULD be less than KeyStartGenerate, and KeyStopGenerate SHOULD be less than KeyStopAccept. If KeyStartGenerate or KeyStartAccept are left unspecified, the time will default to 0, and the key will be used immediately. If KeyStopGenerate or KeyStopAccept are left unspecified, the time will default to infinity, and the key's lifetime will be infinite. When a new key replaces an old, the KeyStartGenerate time for the new key MUST be less than or equal to the KeyStopGenerate time of the old key. Any unspecified values are encoded as zero.
スムーズなキーの移行を実現するために、KeyStartAcceptはKeyStartGenerate未満である必要があり、KeyStopGenerateはKeyStopAccept未満である必要があります。 KeyStartGenerateまたはKeyStartAcceptを指定しない場合、時間はデフォルトで0になり、キーはすぐに使用されます。 KeyStopGenerateまたはKeyStopAcceptが指定されていない場合、時間はデフォルトで無限大になり、キーの有効期間は無限になります。新しいキーが古いキーを置き換えるとき、新しいキーのKeyStartGenerate時間は古いキーのKeyStopGenerate時間以下でなければなりません。指定されていない値はすべてゼロとしてエンコードされます。
Key storage SHOULD persist across a system restart, warm or cold, to avoid operational issues. In the event that the last key associated with an interface expires, it is unacceptable to revert to an unauthenticated condition and not advisable to disrupt routing. Therefore, the router SHOULD send a "last Authentication Key expiration" notification to the network manager and treat the key as having an infinite lifetime until the lifetime is extended, the key is deleted by network management, or a new key is configured.
運用上の問題を回避するために、キーストレージは、システムの再起動（ウォームまたはコールド）を通じて維持する必要があります。インターフェイスに関連付けられた最後のキーが期限切れになった場合、認証されていない状態に戻すことは受け入れられず、ルーティングを中断することはお勧めできません。したがって、ルーターは、「最終認証キーの有効期限」通知をネットワークマネージャーに送信して、ライフタイムが延長されるか、ネットワーク管理によってキーが削除されるか、新しいキーが構成されるまで、キーを無限のライフタイムとして扱う必要があります。
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| Auth (0x0405) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number (High-Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number (Low-Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data (Variable) |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: 0x0405, Cryptographic Authentication
o タイプ：0x0405、暗号化認証
o Length: The length in octets of the value field, including the Security Association ID and Cryptographic Sequence Number fields.
o 長さ：値フィールドの長さ（オクテット単位）。セキュリティアソシエーションIDおよび暗号化シーケンス番号フィールドを含みます。
o Security Association ID: The 32-bit field that maps to the authentication algorithm and the secret key used to create the message digest carried in LDP payload.
o セキュリティアソシエーションID：LDPペイロードで運ばれるメッセージダイジェストを作成するために使用される認証アルゴリズムと秘密鍵にマップする32ビットのフィールド。
Though the SA ID implies the algorithm, the HMAC output size should not be used by implementers as an implicit hint because additional algorithms may be defined in the future that have the same output size.
SA IDはアルゴリズムを意味しますが、HMAC出力サイズは、同じ出力サイズを持つ追加のアルゴリズムが将来定義される可能性があるため、暗黙のヒントとして実装者が使用するべきではありません。
o Cryptographic Sequence Number: The 64-bit, strictly increasing sequence number that is used to guard against replay attacks. The 64-bit sequence number MUST be incremented for every LDP Hello message sent by the LDP router. Upon reception, the sequence number MUST be greater than the sequence number in the last LDP Hello message accepted from the sending LDP neighbor. Otherwise, the LDP message is considered a replayed packet and is dropped. The Cryptographic Sequence Number is a single space per LDP router.
o 暗号化シーケンス番号：64ビットの厳密に増加するシーケンス番号。リプレイ攻撃から保護するために使用されます。 LDPルーターが送信するすべてのLDP Helloメッセージごとに、64ビットのシーケンス番号をインクリメントする必要があります。受信時、シーケンス番号は、送信側LDPネイバーから受け入れられた最後のLDP Helloメッセージのシーケンス番号よりも大きい必要があります。それ以外の場合、LDPメッセージは再生されたパケットと見なされ、ドロップされます。暗号化シーケンス番号は、LDPルーターごとに1つのスペースです。
LDP routers implementing this specification MUST use existing mechanisms to preserve the sequence number's strictly increasing property for the deployed life of the LDP router (including cold restarts). One mechanism for accomplishing this could be to use the high-order 32 bits of the sequence number as a boot count that is incremented anytime the LDP router loses its sequence number state. Techniques such as sequence number space partitioning described above or non-volatile storage preservation can be used but are beyond the scope of this specification. Sequence number wrap is described in Section 2.4.
この仕様を実装するLDPルーターは、既存のメカニズムを使用して、LDPルーターのデプロイされたライフ（コールドリスタートを含む）の間、シーケンス番号の厳密に増加するプロパティを維持する必要があります。これを実現する1つのメカニズムは、シーケンス番号の上位32ビットを、LDPルータがシーケンス番号の状態を失うたびに増分されるブートカウントとして使用することです。上記のシーケンス番号スペースの分割や不揮発性ストレージの保存などの手法を使用できますが、この仕様の範囲を超えています。シーケンス番号の折り返しについては、セクション2.4で説明します。
o Authentication Data: This field carries the digest computed by the Cryptographic Authentication algorithm in use. The length of the Authentication Data varies based on the cryptographic algorithm in use, which is shown below:
o 認証データ：このフィールドには、使用中の暗号化認証アルゴリズムによって計算されたダイジェストが含まれます。認証データの長さは、使用中の暗号化アルゴリズムに基づいて異なります。以下に示します。
Auth type Length
--------------- ----------
HMAC-SHA1 20 bytes
HMAC-SHA-256 32 bytes
HMAC-SHA-384 48 bytes
HMAC-SHA-512 64 bytes
When incrementing the sequence number for each transmitted LDP message, the sequence number should be treated as an unsigned 64-bit value. If the lower-order 32-bit value wraps, the higher-order 32-bit value should be incremented and saved in non-volatile storage. If the LDP router is deployed long enough that the 64-bit sequence number wraps, all keys, independent of the key distribution mechanism, MUST be reset. This is done to avoid the possibility of replay attacks. Once the keys have been changed, the higher-order sequence number can be reset to 0 and saved to non-volatile storage.
送信された各LDPメッセージのシーケンス番号をインクリメントするとき、シーケンス番号は符号なし64ビット値として扱われる必要があります。下位32ビット値がラップする場合は、上位32ビット値をインクリメントして、不揮発性ストレージに保存する必要があります。 LDPルーターが64ビットのシーケンス番号がラップするほど長く展開されている場合、キー配布メカニズムに関係なく、すべてのキーをリセットする必要があります。これは、リプレイ攻撃の可能性を回避するために行われます。キーを変更すると、上位シーケンス番号を0にリセットして、不揮発性ストレージに保存できます。
As noted earlier, the Security Association ID maps to the authentication algorithm and the secret key used to generate and verify the message digest. This specification discusses the computation of LDP Cryptographic Authentication data when any of the NIST SHS family of algorithms is used in the Hashed Message Authentication Code (HMAC) mode.
前述のように、セキュリティアソシエーションIDは、メッセージダイジェストの生成と検証に使用される認証アルゴリズムと秘密鍵にマップされます。この仕様では、NIST SHSファミリーのアルゴリズムのいずれかがハッシュメッセージ認証コード（HMAC）モードで使用される場合のLDP暗号認証データの計算について説明します。
The currently valid algorithms (including mode) for LDP Cryptographic Authentication include:
LDP暗号化認証に現在有効なアルゴリズム（モードを含む）は次のとおりです。
HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512
HMAC-SHA-1、HMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512
Of the above, implementations of this specification MUST include support for at least HMAC-SHA-256, SHOULD include support for HMAC-SHA-1, and MAY also include support for HMAC-SHA-384 and HMAC-SHA-512.
上記のうち、この仕様の実装には、少なくともHMAC-SHA-256のサポートが含まれている必要があり、HMAC-SHA-1のサポートが含まれている必要があります。また、HMAC-SHA-384およびHMAC-SHA-512のサポートも含まれている場合があります。
Implementations of this standard MUST use HMAC-SHA-256 as the default authentication algorithm.
この標準の実装では、デフォルトの認証アルゴリズムとしてHMAC-SHA-256を使用する必要があります。
In order to prevent cross-protocol replay attacks for protocols sharing common keys, the 2-octet LDP Cryptographic Protocol ID is appended to the authentication key prior to use (refer to Section 8). Other protocols using the common key similarly append their own Cryptographic Protocol IDs to their keys prior to use, thus ensuring that a different key value is used for each protocol.
共通キーを共有するプロトコルに対するクロスプロトコルリプレイ攻撃を防ぐために、2オクテットLDP暗号化プロトコルIDが使用前に認証キーに追加されます（セクション8を参照）。共通キーを使用する他のプロトコルも同様に、使用前に独自の暗号化プロトコルIDをキーに追加するため、プロトコルごとに異なるキー値が使用されます。
In the algorithm description below, the following nomenclature is used:
以下のアルゴリズムの説明では、次の用語が使用されています。
o H is the specific hashing algorithm (e.g., SHA-256).
o Hは特定のハッシュアルゴリズムです（SHA-256など）。
o K is the Authentication Key from the LDP Security Association.
o KはLDP Security Associationからの認証キーです。
o Ks is a Protocol-Specific Authentication Key obtained by appending Authentication Key (K) with the 2-octet LDP Cryptographic Protocol ID.
o Ksは、認証キー（K）に2オクテットLDP暗号化プロトコルIDを付加することにより取得されるプロトコル固有の認証キーです。
o Ko is the cryptographic key used with the hash algorithm.
o Koは、ハッシュアルゴリズムで使用される暗号化キーです。
o L is the length of the hash, measured in octets rather than bits.
o Lはハッシュの長さで、ビットではなくオクテットで測定されます。
o AuthTag is a value that is the same length as the hash output. In the case of IPv4, the first 4 octets contain the IPv4 source address followed by the hexadecimal value 0x878FE1F3 repeated (L-4)/4 times. In the case of IPv6, the first 16 octets contain the IPv6 source address followed by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times. This implies that hash output is always a length of at least 16 octets.
o AuthTagは、ハッシュ出力と同じ長さの値です。 IPv4の場合、最初の4オクテットにはIPv4送信元アドレスが含まれ、その後に16進数値0x878FE1F3が（L-4）/ 4回繰り返されます。 IPv6の場合、最初の16オクテットにはIPv6送信元アドレスが含まれ、その後に16進数値0x878FE1F3が（L-16）/ 4回繰り返されます。これは、ハッシュ出力が常に少なくとも16オクテットの長さであることを意味します。
The LDP Cryptographic Protocol ID is appended to the Authentication Key (K) yielding a Protocol-Specific Authentication Key (Ks). In this application, Ko is always L octets long. Keys that are longer than the bit length of the hash function are hashed to force them to this length, as we describe below. Ks is computed as follows.
LDP暗号化プロトコルIDが認証キー（K）に追加され、プロトコル固有の認証キー（Ks）が生成されます。このアプリケーションでは、Koは常にLオクテットの長さです。ハッシュ関数のビット長よりも長いキーは、以下で説明するように、ハッシュされてこの長さにされます。 Ksは次のように計算されます。
If the Protocol-Specific Authentication Key (Ks) is L octets long, then Ko is equal to Ks. If the Protocol-Specific Authentication Key (Ks) is more than L octets long, then Ko is set to H(Ks). If the Protocol-Specific Authentication Key (Ks) is less than L octets long, then Ko is set to the Protocol-Specific Authentication Key (Ks) with zeros appended to the end of the Protocol-Specific Authentication Key (Ks) such that Ko is L octets long.
プロトコル固有の認証キー（Ks）がLオクテット長の場合、KoはKsと等しくなります。プロトコル固有の認証キー（Ks）がLオクテットより長い場合、KoはH（Ks）に設定されます。プロトコル固有の認証キー（Ks）がLオクテットより短い場合、Koはプロトコル固有の認証キー（Ks）に設定され、プロトコル固有の認証キー（Ks）の末尾にゼロが追加されてKo Lオクテット長です。
For higher entropy, it is RECOMMENDED that Key Ks should be at least L octets long.
エントロピーを高めるには、キーKを少なくともLオクテットにすることをお勧めします。
First, the Authentication Data field in the Cryptographic Authentication TLV is filled with the value AuthTag. Then, to compute HMAC over the Hello message it performs:
まず、暗号化認証TLVの認証データフィールドに値AuthTagが入力されます。次に、Helloメッセージを介してHMACを計算するために実行します
AuthData = HMAC(Ko, Hello Message)
AuthData = HMAC（Ko、Hello Message）
Hello Message refers to the LDP Hello message excluding the IP and the UDP headers.
Helloメッセージとは、IPおよびUDPヘッダーを除くLDP Helloメッセージを指します。
The resultant Hash becomes the Authentication Data that is sent in the Authentication Data field of the Cryptographic Authentication TLV. The length of the Authentication Data field is always identical to the message digest size of the specific hash function H that is being used.
結果のハッシュは、暗号化認証TLVの認証データフィールドで送信される認証データになります。 [認証データ]フィールドの長さは、使用されている特定のハッシュ関数Hのメッセージダイジェストサイズと常に同じです。
This also means that the use of hash functions with larger output sizes will also increase the size of the LDP message as transmitted on the wire.
これは、出力サイズが大きいハッシュ関数を使用すると、回線で送信されるLDPメッセージのサイズも大きくなることも意味します。
Prior to transmitting the LDP Hello message, the Length in the Cryptographic Authentication TLV header is set as per the authentication algorithm that is being used. It is set to 24 for HMAC-SHA-1, 36 for HMAC-SHA-256, 52 for HMAC-SHA-384, and 68 for HMAC-SHA-512.
LDP Helloメッセージを送信する前に、暗号化認証TLVヘッダーの長さが、使用されている認証アルゴリズムに従って設定されます。 HMAC-SHA-1の場合は24、HMAC-SHA-256の場合は36、HMAC-SHA-384の場合は52、HMAC-SHA-512の場合は68に設定されます。
The Security Association ID field is set to the ID of the current authentication key. The HMAC Hash is computed as explained in Section 5. The resulting Hash is stored in the Authentication Data field prior to transmission. The authentication key MUST NOT be carried in the packet.
Security Association IDフィールドは、現在の認証キーのIDに設定されます。 HMACハッシュは、セクション5で説明するように計算されます。結果のハッシュは、送信前に認証データフィールドに格納されます。認証キーはパケットで運ばれてはいけません。
The receiving LSR applies acceptability criteria for received Hellos using cryptographic authentication. If the Cryptographic Authentication TLV is unknown to the receiving LSR, the received packet MUST be discarded according to Section 3.5.1.2.2 of [RFC5036].
受信側のLSRは、暗号化認証を使用して、受信したHelloに許容基準を適用します。暗号化認証TLVが受信側LSRに認識されない場合、[RFC5036]のセクション3.5.1.2.2に従って、受信したパケットを破棄する必要があります。
The receiving router MUST determine whether or not to accept a Hello message from a particular source IP address as follows. First, if the router has, for that source IP address, a stored LDP Hello cryptographic sequence number or is configured to require LDP Hello authentication, then the router MUST discard any unauthenticated Hello packets. As specified later in this section, a cryptographic sequence number is only stored for a source IP address as a result of receiving a valid authenticated Hello.
受信側ルーターは、特定の送信元IPアドレスからのHelloメッセージを受け入れるかどうかを次のように決定する必要があります。まず、ルーターがそのソースIPアドレスに対して、保存されているLDP Hello暗号シーケンス番号を持っているか、LDP Hello認証を要求するように構成されている場合、ルーターは認証されていないHelloパケットを破棄する必要があります。このセクションで後ほど説明するように、暗号化シーケンス番号は、有効な認証済みのHelloを受信した結果として、送信元IPアドレスに対してのみ格納されます。
The receiving LSR locates the LDP SA using the Security Association ID field carried in the message. If the SA is not found or if the SA is not valid for reception (i.e., current time < KeyStartAccept or current time >= KeyStopAccept), the LDP Hello message MUST be discarded, and an error event SHOULD be logged.
受信LSRは、メッセージに含まれるセキュリティアソシエーションIDフィールドを使用してLDP SAを見つけます。 SAが見つからない場合、またはSAが受信に有効でない場合（つまり、現在の時刻<KeyStartAcceptまたは現在の時刻> = KeyStopAccept）の場合、LDP Helloメッセージを破棄する必要があり、エラーイベントをログに記録する必要があります（SHOULD）。
If the cryptographic sequence number in the LDP Hello message is less than or equal to the last sequence number received from the same neighbor, the LDP Hello message MUST be discarded, and an error event SHOULD be logged.
LDP Helloメッセージの暗号化シーケンス番号が同じネイバーから受信した最後のシーケンス番号以下の場合、LDP Helloメッセージを破棄する必要があり、エラーイベントをログに記録する必要があります（SHOULD）。
Before the receiving LSR performs any processing, it needs to save the values of the Authentication Data field. The receiving LSR then replaces the contents of the Authentication Data field with AuthTag and computes the Hash using the authentication key specified by the received Security Association ID field, as explained in Section 3. If the locally computed Hash is equal to the received value of the Authentication Data field, the received packet is accepted for other normal checks and processing as described in [RFC5036]. Otherwise, if the locally computed Hash is not equal to the received value of the Authentication Data field, the received LDP Hello message MUST be discarded, and an error event SHOULD be logged. The aforesaid logging needs to be carefully rate limited, because while a LDP router is under attack by a storm of spoofed Hellos, the resources required for logging could be overwhelming.
受信側のLSRが処理を実行する前に、認証データフィールドの値を保存する必要があります。次に、受信LSRは、認証データフィールドの内容をAuthTagに置き換え、セクション3で説明するように、受信したセキュリティアソシエーションIDフィールドで指定された認証キーを使用してハッシュを計算します。ローカルで計算されたハッシュが、認証データフィールド。受信したパケットは、[RFC5036]で説明されているように、他の通常のチェックと処理のために受け入れられます。それ以外の場合、ローカルで計算されたハッシュが認証データフィールドの受信した値と等しくない場合、受信したLDP Helloメッセージを破棄する必要があり、エラーイベントをログに記録する必要があります（SHOULD）。 LDPルーターがスプーフィングされたHelloの嵐の攻撃を受けている間、ロギングに必要なリソースが圧倒される可能性があるため、前述のロギングは慎重にレート制限する必要があります。
After the LDP Hello message has been successfully authenticated, implementations MUST store the 64-bit cryptographic sequence number for the LDP Hello message received from the source IP address. The saved cryptographic sequence numbers will be used for replay checking for subsequent packets received from the source IP address.
LDP Helloメッセージが正常に認証された後、実装は、送信元IPアドレスから受信したLDP Helloメッセージの64ビット暗号シーケンス番号を格納する必要があります。保存された暗号化シーケンス番号は、送信元IPアドレスから受信した後続のパケットのリプレイチェックに使用されます。
Careful consideration must be given to when and how to enable and disable authentication on LDP Hellos. On the one hand, it is critical that an attack cannot cause the authentication to be disabled. On the other hand, it is equally important that an operator can change the hardware and/or software associated with a neighbor's IP address and successfully bring up an LDP adjacency with the desired level of authentication, which may be with different or no authentication due to software restrictions.
LDP Helloで認証を有効および無効にするタイミングと方法を慎重に検討する必要があります。一方では、攻撃によって認証が無効にされないことが重要です。一方、オペレーターがネイバーのIPアドレスに関連付けられたハードウェアやソフトウェアを変更し、必要な認証レベルでLDP隣接関係を正常に起動できることも同様に重要です。ソフトウェアの制限。
LDP Hello authentication information (e.g., whether authentication is enabled and what the last cryptographic sequence number is) associated with an IP address is learned via a set of interfaces. If an interface is administratively disabled, the LDP Hello authentication information learned via that interface MAY be forgotten. This enables an operator that is not specifically manipulating LDP Hello authentication configurations to easily bring up an LDP adjacency. An implementation of this standard SHOULD provide a configuration mechanism by which the LDP Hello authentication information associated with an IP address can be shown and can be forgotten; configuration mechanisms are assumed to be accessed via an authenticated channel.
IPアドレスに関連付けられているLDP Hello認証情報（認証が有効になっているかどうか、最後の暗号シーケンス番号が何であるかなど）は、一連のインターフェースを介して学習されます。インターフェイスが管理上無効になっている場合、そのインターフェイスを介して学習されたLDP Hello認証情報は忘れられる場合があります。これにより、特にLDP Hello認証設定を操作していないオペレーターがLDP隣接関係を簡単に立ち上げることができます。この標準の実装は、IPアドレスに関連付けられたLDP Hello認証情報を表示し、忘れることができる構成メカニズムを提供する必要があります（SHOULD）。構成メカニズムは、認証されたチャネルを介してアクセスされると想定されています。
Section 1 of this document describes the security issues arising from the use of unauthenticated LDP Hello messages. In order to address those issues, it is RECOMMENDED that all deployments use the Cryptographic Authentication TLV to authenticate the Hello messages.
このドキュメントのセクション1では、認証されていないLDP Helloメッセージの使用から生じるセキュリティ問題について説明します。これらの問題に対処するために、すべての展開で暗号化認証TLVを使用してHelloメッセージを認証することをお勧めします。
The quality of the security provided by the Cryptographic Authentication TLV depends completely on the strength of the cryptographic algorithm in use, the strength of the key being used, and the correct implementation of the security mechanism in communicating LDP implementations. Also, the level of security provided by the Cryptographic Authentication TLV varies based on the authentication type used.
暗号化認証TLVによって提供されるセキュリティの品質は、使用中の暗号化アルゴリズムの強度、使用されているキーの強度、および通信LDP実装におけるセキュリティメカニズムの正しい実装に完全に依存します。また、暗号化認証TLVによって提供されるセキュリティのレベルは、使用される認証タイプによって異なります。
It should be noted that the authentication method described in this document is not being used to authenticate the specific originator of a packet but is rather being used to confirm that the packet has indeed been issued by a router that has access to the authentication key.
このドキュメントで説明する認証方法は、パケットの特定の発信元を認証するために使用されるのではなく、認証キーにアクセスできるルーターによってパケットが実際に発行されたことを確認するために使用されることに注意してください。
Deployments SHOULD use sufficiently long and random values for the authentication key so that guessing and other cryptographic attacks on the key are not feasible in their environments. In support of these recommendations, management systems SHOULD support hexadecimal input of authentication keys.
デプロイメントでは、認証キーに十分に長いランダムな値を使用する必要があるため、キーに対する推測やその他の暗号化攻撃は、その環境では実行できません。これらの推奨事項をサポートするために、管理システムは認証キーの16進数入力をサポートする必要があります（SHOULD）。
The mechanism described herein is not perfect. However, this mechanism introduces a significant increase in the effort required for an adversary to successfully attack the LDP Hello protocol while not causing undue implementation, deployment, or operational complexity.
ここで説明するメカニズムは完璧ではありません。ただし、このメカニズムにより、攻撃者がLDP Helloプロトコルを正常に攻撃するのに必要な労力が大幅に増加する一方で、過度の実装、展開、または運用の複雑さは発生しません。
The IANA has assigned a new TLV from the "Label Distribution Protocol (LDP) Parameters" registry, "TLV Type Name Space".
IANAは、「Label Distribution Protocol（LDP）Parameters」レジストリから「TLV Type Name Space」という新しいTLVを割り当てました。
Value Description Reference
------ -------------------------------- ---------------------------
0x0405 Cryptographic Authentication TLV this document (Section 2.3)
The IANA has also assigned a value from the "Authentication Cryptographic Protocol ID" registry under the "Keying and Authentication for Routing Protocols (KARP) Parameters" category.
IANAはまた、「ルーティングプロトコル（KARP）パラメータのキーイングと認証」カテゴリの下の「認証暗号化プロトコルID」レジストリから値を割り当てました。
Value Description Reference
----- -------------------------------- -------------------------
2 LDP Cryptographic Protocol ID this document (Section 4)
We are indebted to Yaron Sheffer who helped us enormously in rewriting the document to get rid of the redundant crypto mathematics that we had added here.
ここで追加した冗長な暗号数学を取り除くために文書を書き直す際に多大な助けをしてくれたYaron Shefferに感謝します。
We would also like to thank Liu Xuehu for his work on background and motivation for LDP Hello authentication. Last but not least, we would also thank Adrian Farrel, Eric Rosen, Sam Hartman, Stephen Farrell, Eric Gray, Kamran Raza, and Acee Lindem for their valuable comments.
LDP Hello認証の背景と動機付けに関するLiu Xuehu氏の仕事にも感謝します。最後に重要なことですが、貴重なコメントをいただいたAdrian Farrel、Eric Rosen、Sam Hartman、Stephen Farrell、Eric Grey、Kamran Raza、Acee Lindemにも感謝します。
[FIPS-180-4] National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", FIPS 180-4, March 2012.
[FIPS-180-4]国立標準技術研究所（NIST）、「Secure Hash Standard（SHS）」、FIPS 180-4、2012年3月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[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月。
[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)", RFC 5926, June 2010.
[RFC5926] Lebovitz、G。およびE. Rescorla、「TCP Authentication Option（TCP-AO）の暗号化アルゴリズム」、RFC 5926、2010年6月。
[RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP)", RFC 6720, August 2012.
[RFC6720] Pignataro、C。およびR. Asati、「Label Distribution Protocol（LDP）の一般化されたTTLセキュリティメカニズム（GTSM）」、RFC 6720、2012年8月。
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, May 2013.
[RFC6952] Jethanandani、M.、Patel、K。、およびL. Zheng、「BGP、LDP、PCEP、およびMSDP問題の分析（ルーティングプロトコルのキーイングおよび認証（KARP）設計ガイドに従って」）、RFC 6952、5月2013。
Authors' Addresses
著者のアドレス
Lianshu Zheng Huawei Technologies China
lイアン番号Zは非常にGH UAは技術中国
EMail: vero.zheng@huawei.com
Mach(Guoyi) Chen Huawei Technologies China
Mach（GU O一）Chen hu Aテクノロジー中国
EMail: mach.chen@huawei.com
Manav Bhatia Ionos Networks India
Manav Bhatia Ionos Networksインド
EMail: manav@ionosnetworks.com