[要約] RFC 7602は、IS-ISプロトコルにおける拡張シーケンス番号TLVの仕様を定義しています。このTLVは、IS-ISネットワークでのパケットの順序制御を向上させるために使用されます。
Internet Engineering Task Force (IETF) U. Chunduri
Request for Comments: 7602 W. Lu
Category: Standards Track A. Tian
ISSN: 2070-1721 Ericsson Inc.
N. Shen
Cisco Systems, Inc.
July 2015
IS-IS Extended Sequence Number TLV
IS-IS拡張シーケンス番号TLV
Abstract
概要
This document defines the Extended Sequence Number TLV to protect Intermediate System to Intermediate System (IS-IS) PDUs from replay attacks.
このドキュメントでは、中間システム間（IS-IS）PDUをリプレイ攻撃から保護するための拡張シーケンス番号TLVを定義しています。
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/rfc7602.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7602で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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
1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Replay Attacks and Impact on IS-IS Networks . . . . . . . . . 4
2.1. IIHs . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. SNPs . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Extended Sequence Number TLV . . . . . . . . . . . . . . . . 4
3.1. Sequence Number Wrap . . . . . . . . . . . . . . . . . . 5
4. Mechanism and Packet Encoding . . . . . . . . . . . . . . . . 5
4.1. IIHs . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. SNPs . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Backward Compatibility and Deployment . . . . . . . . . . . . 6
5.1. IIHs and SNPs . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. ESSN Encoding Mechanisms . . . . . . . . . . . . . . 10
A.1. Using Timestamps . . . . . . . . . . . . . . . . . . . . 10
A.2. Using Non-volatile Storage . . . . . . . . . . . . . . . 10
Appendix B. Operational/Implementation Considerations . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
Intermediate System to Intermediate System (IS-IS) [ISO10589] has been adopted widely in various Layer 2 / Layer 3 routing and switching deployments of data centers and for critical business operations. Its flexibility and scalability make it well suited for the rapid development of new data center infrastructures. Also, while technologies such as Software-Defined Networking (SDN) may improve network management and enable new applications, their use has an effect on the security requirements of the routing infrastructure.
Intermediate System to Intermediate System（IS-IS）[ISO10589]は、データセンターのさまざまなレイヤー2 /レイヤー3ルーティングおよびスイッチングの展開、および重要なビジネスオペレーションに広く採用されています。その柔軟性と拡張性により、新しいデータセンターインフラストラクチャの迅速な開発に最適です。また、ソフトウェア定義ネットワーク（SDN）などのテクノロジはネットワーク管理を改善し、新しいアプリケーションを有効にする可能性がありますが、その使用はルーティングインフラストラクチャのセキュリティ要件に影響します。
A replayed IS-IS PDU can potentially cause many problems in IS-IS networks, including bouncing adjacencies, blackholing, and even some form of Denial-of-Service (DoS) attacks as explained in Section 2. This problem is also discussed in the Security Considerations section, in the context of cryptographic authentication work as described in [RFC5304] and [RFC5310].
再生されたIS-IS PDUは、セクション2で説明されているように、バウンス隣接、ブラックホール、さらには何らかの形のサービス拒否（DoS）攻撃など、IS-ISネットワークで多くの問題を引き起こす可能性があります。この問題については、 [RFC5304]および[RFC5310]で説明されているように、暗号化認証のコンテキストでのセキュリティの考慮事項のセクション。
Currently, there is no mechanism to protect IS-IS Hello (IIH) PDUs and Sequence Number PDUs (SNPs) from replay attacks. However, Link State PDUs (LSPs) have a sequence number in the LSP header as defined in [ISO10589], with which they can effectively mitigate intra-session replay attacks. But, LSPs are still susceptible to inter-session replay attacks.
現在、IS-IS Hello（IIH）PDUとシーケンス番号PDU（SNP）をリプレイアタックから保護するメカニズムはありません。ただし、リンク状態PDU（LSP）は、[ISO10589]で定義されているように、LSPヘッダーにシーケンス番号があり、セッション内のリプレイ攻撃を効果的に軽減できます。ただし、LSPは依然としてセッション間リプレイ攻撃の影響を受けます。
This document defines the Extended Sequence Number (ESN) TLV to protect IS-IS PDUs from replay attacks.
このドキュメントでは、IS-IS PDUをリプレイ攻撃から保護するための拡張シーケンス番号（ESN）TLVを定義しています。
The new ESN TLV defined here thwarts these threats and can be deployed with the authentication mechanisms specified in [RFC5304] and [RFC5310] for a more secure network.
ここで定義された新しいESN TLVはこれらの脅威を阻止し、[RFC5304]と[RFC5310]で指定された認証メカニズムを使用して展開することで、より安全なネットワークを実現できます。
Replay attacks can be effectively mitigated by deploying a group key management protocol (being developed as defined in [GROUP-IKEv2] and [MRKMP]) with a frequent key change policy. Currently, there is no such mechanism defined for IS-IS. Even if such a mechanism is defined, usage of this TLV can be helpful to avoid replays before the keys are changed.
頻繁なキー変更ポリシーを備えたグループキー管理プロトコル（[GROUP-IKEv2]および[MRKMP]で定義されているように開発されている）を展開することにより、リプレイ攻撃を効果的に軽減できます。現在、IS-ISに定義されているそのようなメカニズムはありません。このようなメカニズムが定義されている場合でも、このTLVの使用は、キーが変更される前のリプレイを回避するのに役立ちます。
Also, it is believed that, even when such a key management system is deployed, there always will be some systems based on manual keying that coexist with systems based on key management protocols. The ESN TLV defined in this document is helpful for such deployments.
また、そのような鍵管理システムが配備されている場合でも、鍵管理プロトコルに基づくシステムと共存する手動鍵に基づくシステムが常に存在すると考えられています。このドキュメントで定義されているESN TLVは、このような展開に役立ちます。
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]で説明されているように解釈されます。
CSNP - Complete Sequence Number PDU
CSNP-完全なシーケンス番号PDU
ESN - Extended Sequence Number
ESN-拡張シーケンス番号
IIH - IS-IS Hello
IIH-IS-ISこんにちは
IS - Intermediate System
IS-中間システム
LSP - IS-IS Link State PDU
LSP-IS-ISリンク状態PDU
PDU - Protocol Data Unit PSNP - Partial Sequence Number PDU
PDU-プロトコルデータユニットPSNP-部分シーケンス番号PDU
SNP - Sequence Number PDU
SNP-シーケンス番号PDU
Replaying a captured protocol packet to cause damage is a common threat for any protocol. Securing the packet with cryptographic authentication information alone cannot mitigate this threat completely. This section explains the replay attacks and their applicability to each IS-IS PDU.
キャプチャしたプロトコルパケットを再生して損傷を与えることは、どのプロトコルにとっても一般的な脅威です。暗号化認証情報だけでパケットを保護しても、この脅威を完全に緩和することはできません。このセクションでは、リプレイ攻撃と、各IS-IS PDUへの適用について説明します。
When an adjacency is brought up, an IS sends an IIH packet with an empty neighbor list (TLV 6); it can be sent with or without authentication information. Packets can be replayed later on the broadcast network, and this may cause all ISs to bounce the adjacency, thus churning the network. Note that mitigating replay is only possible when authentication information is present.
隣接関係が始動すると、ISは空のネイバーリスト（TLV 6）を含むIIHパケットを送信します。認証情報の有無にかかわらず送信できます。パケットは後でブロードキャストネットワークで再生できます。これにより、すべてのISが隣接関係をバウンスし、ネットワークを混乱させる可能性があります。リプレイの軽減は、認証情報が存在する場合にのみ可能であることに注意してください。
Normal operation of the IS-IS update process as specified in [ISO10589] provides timely recovery from all LSP replay attacks. Therefore, the use of the extensions defined in this document is prohibited in LSPs. Further discussion of the vulnerability of LSPs to replay attacks can be found in [ISIS-ANALYSIS].
[ISO10589]で指定されているIS-IS更新プロセスの通常の操作は、すべてのLSPリプレイ攻撃からタイムリーに回復します。したがって、このドキュメントで定義されている拡張機能をLSPで使用することは禁止されています。 LSPのリプレイ攻撃に対する脆弱性の詳細については、[ISIS-ANALYSIS]を参照してください。
A replayed CSNP can result in the sending of unnecessary PSNPs on a given link. A replayed CSNP or PSNP can result in unnecessary LSP flooding on the link.
CSNPを再生すると、特定のリンクで不要なPSNPが送信される可能性があります。 CSNPまたはPSNPを再生すると、リンクで不要なLSPフラッディングが発生する可能性があります。
The Extended Sequence Number (ESN) TLV is composed of 1 octet for the Type, 1 octet that specifies the number of bytes in the Value field, and a 12-byte Value field. This TLV is defined only for IIH and SNP PDUs.
拡張シーケンス番号（ESN）TLVは、タイプの1オクテット、値フィールドのバイト数を指定する1オクテット、および12バイトの値フィールドで構成されます。このTLVは、IIHおよびSNP PDUに対してのみ定義されています。
Code - 11.
コード-11。
Length - total length of the value field, which is 12 bytes.
長さ-値フィールドの全長（12バイト）。
Value - 64-bit Extended Session Sequence Number (ESSN), which is followed by a 32-bit, monotonically increasing, per-packet sequence number.
値-64ビットの拡張セッションシーケンス番号（ESSN）。その後に32ビットの単調増加するパケットごとのシーケンス番号が続きます。
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
+-+-+-+-+-+-+-+-+
| Type |
+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Session Sequence Number (High-Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Session Sequence Number (Low-Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Sequence Number (32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Extended Sequence Number (ESN) TLV
図1：拡張シーケンス番号（ESN）TLV
The ESN TLV defined here is optional. Though this is an optional TLV, it can be mandatory on a link when 'verify' mode is enabled as specified in Section 5.1. The ESN TLV MAY be present only in IIH PDUs and SNPs. A PDU with multiple ESN TLVs is invalid and MUST be discarded on receipt.
ここで定義されるESN TLVはオプションです。これはオプションのTLVですが、セクション5.1で指定されているように「検証」モードが有効になっている場合は、リンクで必須になる場合があります。 ESN TLVは、IIH PDUおよびSNPにのみ存在する場合があります。複数のESN TLVを持つPDUは無効であり、受信時に破棄する必要があります。
The 64-bit ESSN MUST be nonzero and MUST contain a number that is increased whenever it is changed due any situation, as specified in Section 3.1. Encoding the 64-bit unsigned integer ESSN value is a local matter, and implementations MAY use one of the alternatives provided in Appendix A. Effectively, for each PDU that contains the ESN TLV, the 96-bit unsigned integer value consisting of the 64-bit ESSN and 32-bit Packet Sequence Number (PSN) -- where the ESSN is the higher-order 64 bits -- MUST be greater than the most recently received value in a PDU of the same type originated by the same IS.
セクション3.1で指定されているように、64ビットのESSNはゼロ以外でなければならず、状況によって変更されるたびに増加する数値を含んでいる必要があります。 64ビットの符号なし整数のESSN値のエンコードはローカルな問題であり、実装は、付録Aで提供される代替案の1つを使用することができます。事実上、ESN TLVを含む各PDUに対して、64ビットのビットESSNおよび32ビットのパケットシーケンス番号（PSN）（ESSNが上位64ビットの場合）は、同じISから発信された同じタイプのPDUで最後に受信した値よりも大きい必要があります。
If the 32-bit Packet Sequence Number in the ESN TLV wraps or the router performs a cold restart, the 64-bit ESSN value MUST be set higher than the previous value. IS-IS implementations MAY use the guidelines provided in Appendix A for accomplishing this.
ESN TLVの32ビットのパケットシーケンス番号がラップするか、ルーターがコールドリスタートを実行する場合、64ビットのESSN値は以前の値よりも高く設定する必要があります。 IS-IS実装は、これを達成するために付録Aで提供されるガイドラインを使用する場合があります。
The encoding of the ESN TLV in each applicable IS-IS PDU is detailed below. Please refer to Section 5 for appropriate operations on how to interoperate with legacy node(s) that do not support the extensions defined in this document. If the received PDU with the ESN TLV is accepted, then the stored value for the corresponding originator and PDU type MUST be updated with the latest value received. Please note that level information is included in the PDU type.
該当する各IS-IS PDUでのESN TLVのエンコードについて、以下で詳しく説明します。このドキュメントで定義されている拡張機能をサポートしていないレガシーノードと相互運用する方法の適切な操作については、セクション5を参照してください。 ESN TLVで受信したPDUが受け入れられる場合、対応するオリジネーターとPDUタイプの格納された値は、受信した最新の値で更新する必要があります。レベル情報はPDUタイプに含まれていることに注意してください。
ESN TLV information is maintained for each type of IIH PDU being sent on a given circuit. The procedures for encoding, verification, and sequence number wrapping are explained in Section 3.
ESN TLV情報は、特定の回線で送信されるIIH PDUのタイプごとに維持されます。エンコード、検証、シーケンス番号の折り返しの手順については、セクション3で説明します。
Separate CSNP/PSNP ESN TLV information is maintained per PDU type, per originator, and per link. The procedures for encoding, verification, and sequence number wrapping are explained in Section 3.
個別のCSNP / PSNP ESN TLV情報は、PDUタイプごと、発信元ごと、およびリンクごとに維持されます。エンコード、検証、シーケンス番号の折り返しの手順については、セクション3で説明します。
The implementation and deployment of the ESN TLV can be done to support backward compatibility and gradual deployment in the network without requiring a flag day. This feature can also be deployed for the links in a certain area of the network where the maximum security mechanism is needed, or it can be deployed for the entire network.
ESN TLVの実装と展開を行うことで、フラグデイを必要とせずに、下位互換性とネットワークでの段階的な展開をサポートできます。この機能は、最大のセキュリティメカニズムが必要なネットワークの特定の領域のリンクに展開することも、ネットワーク全体に展開することもできます。
The implementation SHOULD allow the configuration of ESN TLV features on each IS-IS link level. The implementation SHOULD also allow operators to control the configuration of the 'send' and/or 'verify' feature of IS-IS PDUs for the links and for the node. In this document, the 'send' mode is to include the ESN TLV in its own IS-IS PDUs, and the 'verify' mode is to process the ESN TLV in the receiving IS-IS PDUs from neighbors.
実装は、各IS-ISリンクレベルでのESN TLV機能の設定を許可する必要があります（SHOULD）。実装は、オペレーターがリンクとノードのIS-IS PDUの「送信」または「検証」機能の構成を制御できるようにする必要もあります（SHOULD）。このドキュメントでは、「送信」モードは独自のIS-IS PDUにESN TLVを含めることであり、「検証」モードはネイバーから受信するIS-IS PDUでESN TLVを処理することです。
When an adversary is actively attacking, it is possible to have inconsistent data views in the network, if there is a considerable delay in enabling the 'verify' mode where nodes were configured to the 'send' mode, e.g., from the first to the last node or all nodes of a particular LAN segment. This happens primarily because replay PDUs can potentially be accepted by the nodes where the 'verify' mode is still not provisioned at the time of the attack. To minimize such a window, it is recommended that provisioning of 'verify' SHOULD be done in a timely fashion by the network operators.
攻撃者が積極的に攻撃しているときに、ノードが「送信」モードに構成されている「検証」モードを有効にするのにかなりの遅延がある場合、ネットワークでデータビューに一貫性がない可能性があります。特定のLANセグメントの最後のノードまたはすべてのノード。これは主に、攻撃時に「検証」モードがまだプロビジョニングされていないノードがリプレイPDUを受け入れる可能性があるために発生します。そのようなウィンドウを最小化するために、「検証」のプロビジョニングは、ネットワークオペレーターによってタイムリーに実行される必要があります。
On the link level, the ESN TLV involves the IIH PDUs and SNPs (both CSNP and PSNP). The 'send' and 'verify' modes described above can be set independently on each link and, in the case of a broadcast network, independently on each level.
リンクレベルでは、ESN TLVにはIIH PDUとSNP（CSNPとPSNPの両方）が含まれます。上記の「送信」および「検証」モードは、各リンクで個別に設定でき、ブロードキャストネットワークの場合は、各レベルで個別に設定できます。
To introduce ESN support without disrupting operations, ISs on a given interface are first configured to operate in 'send' mode. Once all routers operating on an interface are operating in 'send' mode, 'verify' mode can be enabled on each IS. Once 'verify' mode is set for an interface, all the IIH PDUs and SNPs being sent on that interface MUST contain the ESN TLV. Any such PDU received without an ESN TLV MUST be discarded when 'verify' mode is enabled. Similarly, to safely disable ESN support on a link, 'verify' mode is disabled on all ISs on the link. Once 'verify' mode is disabled on all routers operating on an interface, 'send' mode can be disabled on each IS. Please refer to Section 5 for considerations on enabling or disabling 'verify' mode on all ISs on a link.
操作を中断せずにESNサポートを導入するには、特定のインターフェイスのISを「送信」モードで動作するように最初に設定します。インターフェイスで動作しているすべてのルーターが「送信」モードで動作している場合、各ISで「検証」モードを有効にできます。インターフェースに「検証」モードが設定されると、そのインターフェースで送信されるすべてのIIH PDUとSNPにESN TLVが含まれている必要があります。 ESN TLVなしで受信されたそのようなPDUは、「検証」モードが有効になっている場合は破棄する必要があります。同様に、リンクのESNサポートを安全に無効にするには、リンクのすべてのISで「検証」モードを無効にします。インターフェイスで動作しているすべてのルーターで「確認」モードを無効にすると、各ISで「送信」モードを無効にできます。リンク上のすべてのISで「検証」モードを有効または無効にする際の考慮事項については、セクション5を参照してください。
A new TLV codepoint, as defined in this document, has been assigned by IANA from the "IS-IS TLV Codepoints" registry. It is referred to as the Extended Sequence Number TLV and has the following attributes:
このドキュメントで定義されている新しいTLVコードポイントは、IANAによって「IS-IS TLVコードポイント」レジストリから割り当てられています。これは拡張シーケンス番号TLVと呼ばれ、次の属性があります。
Value Name IIH LSP SNP Purge
----- --------------------- --- --- --- -----
11 ESN TLV y n y n
This document describes a mechanism to mitigate the replay attack threat as discussed in the Security Considerations sections of [RFC5304] and [RFC5310]. If an adversary interferes either by not forwarding packets or by delaying messages as described in Section 3.3 of [RFC6862], the mechanism specified in this document cannot mitigate those threats. Also, some of the threats described in Section 2.3 of [ISIS-ANALYSIS] are not addressable with the ESN TLV as specified in this document. This document does not introduce any new security concerns to IS-IS or any other specifications referenced.
このドキュメントでは、[RFC5304]および[RFC5310]のセキュリティに関する考慮事項のセクションで説明されている、リプレイ攻撃の脅威を軽減するメカニズムについて説明します。パケットが転送されないか、[RFC6862]のセクション3.3で説明されているようにメッセージを遅延させることによって攻撃者が干渉した場合、このドキュメントで指定されたメカニズムはこれらの脅威を軽減できません。また、[ISIS-ANALYSIS]のセクション2.3で説明されている脅威の一部は、このドキュメントで指定されているESN TLVでは対処できません。このドキュメントでは、IS-ISまたは参照されているその他の仕様に対する新しいセキュリティ上の懸念は紹介していません。
[ISO10589] International Organization for Standardization, "Intermediate system to intermediate system intra-domain-routing routine information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, Nov. 2002.
[ISO10589]国際標準化機構、「中間システムから中間システムへのドメイン内ルーティングルーチン情報交換プロトコル、コネクションレスモードのネットワークサービス（ISO 8473）を提供するためのプロトコルと組み合わせて使用」、ISO / IEC 10589：2002 、第2版、2002年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <http://www.rfc-editor.org/info/rfc5905>.
[RFC5905] Mills、D.、Martin、J.、Ed。、Burbank、J。、およびW. Kasch、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、DOI 10.17487 / RFC5905、2010年6月、 <http://www.rfc-editor.org/info/rfc5905>。
[MRKMP] Hartman, S., Zhang, D., and G. Lebovitz, "Multicast Router Key Management Protocol (MaRK)", Work in Progress, draft-hartman-karp-mrkmp-05, September 2012.
[MRKMP] Hartman、S.、Zhang、D。、およびG. Lebovitz、「Multicast Router Key Management Protocol（MaRK）」、Work in Progress、draft-hartman-karp-mrkmp-05、2012年9月。
[ISIS-ANALYSIS] Chunduri, U., Tian, A., and W. Lu, "KARP IS-IS security analysis", Work in Progress, draft-ietf-karp-isis-analysis-07, July 2015.
[ISIS-ANALYSIS] Chunduri、U.、Tian、A。、およびW. Lu、「KARP IS-ISセキュリティ分析」、Work in Progress、draft-ietf-karp-isis-analysis-07、2015年7月。
[GROUP-IKEv2] Rowles, S., Yeung, A., Ed., Tran, P., and Y. Nir, "Group Key Management using IKEv2", Work in Progress, draft-yeung-g-ikev2-08, October 2014.
[GROUP-IKEv2] Rowles、S.、Yeung、A.、Ed。、Tran、P。、およびY. Nir、「IKEv2を使用したグループキー管理」、作業中、draft-yeung-g-ikev2-08、 2014年10月。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, <http://www.rfc-editor.org/info/rfc5304>.
[RFC5304] Li、T。およびR. Atkinson、「IS-IS Cryptographic Authentication」、RFC 5304、DOI 10.17487 / RFC5304、2008年10月、<http://www.rfc-editor.org/info/rfc5304>。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <http://www.rfc-editor.org/info/rfc5310>.
[RFC5310] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R。、およびM. Fanto、「IS-IS Generic Cryptographic Authentication」、RFC 5310、DOI 10.17487 / RFC5310、 2009年2月、<http://www.rfc-editor.org/info/rfc5310>。
[RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements", RFC 6862, DOI 10.17487/RFC6862, March 2013, <http://www.rfc-editor.org/info/rfc6862>.
[RFC6862] Lebovitz、G.、Bhatia、M。、およびB. Weis、「ルーティングプロトコル（KARP）のキーイングと認証の概要、脅威、および要件」、RFC 6862、DOI 10.17487 / RFC6862、2013年3月、<http： //www.rfc-editor.org/info/rfc6862>。
[RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., "Security Extension for OSPFv2 When Using Manual Key Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, <http://www.rfc-editor.org/info/rfc7474>.
[RFC7474] Bhatia、M.、Hartman、S.、Zhang、D。、およびA. Lindem、編、「手動キー管理を使用する場合のOSPFv2のセキュリティ拡張」、RFC 7474、DOI 10.17487 / RFC7474、2015年4月、< http://www.rfc-editor.org/info/rfc7474>。
IS-IS nodes implementing this specification SHOULD use available mechanisms to preserve the 64-bit Extended Session Sequence Number's strictly increasing property, whenever it is changed for the deployed life of the IS-IS node (including cold restarts).
この仕様を実装するIS-ISノードは、IS-ISノードのデプロイされた寿命（コールドリスタートを含む）が変更されるたびに、利用可能なメカニズムを使用して64ビット拡張セッションシーケンス番号の厳密に増加するプロパティを保持する必要があります（SHOULD）。
This appendix provides guidelines for maintaining the strictly increasing property of the 64-bit ESSN in the ESN TLV, and implementations can resort to any similar method as long as this property is maintained.
この付録では、ESN TLVで64ビットESSNの厳密に増加するプロパティを維持するためのガイドラインを示します。このプロパティが維持されている限り、実装では同様の方法を使用できます。
One mechanism for accomplishing this is by encoding the 64-bit ESSN as the system time represented by a 64-bit unsigned integer value. This MAY be similar to the system timestamp encoding for the NTP long format as defined in Appendix A.4 of [RFC5905]. The new current time MAY be used when the IS-IS node loses its sequence number state including when the Packet Sequence Number wraps.
これを実現するための1つのメカニズムは、64ビットのESSNを、64ビットの符号なし整数値で表されるシステム時間としてエンコードすることです。これは、[RFC5905]の付録A.4で定義されているNTPロングフォーマットのシステムタイムスタンプエンコーディングに類似している場合があります。 IS-ISノードがパケットシーケンス番号の折り返しを含むシーケンス番号状態を失う場合、新しい現在の時刻が使用される場合があります。
Implementations MUST make sure while encoding the 64-bit ESN value with the current system time that it does not default to any previous value or some default node time of the system, especially after cold restarts or any other similar events. In general, system time must be preserved across cold restarts in order for this mechanism to be feasible. One example of such implementation is to use a battery backed real-time clock (RTC).
実装は、64ビットのESN値を現在のシステム時刻でエンコードする際に、特にコールドリスタートやその他の同様のイベントの後に、システムの以前の値やデフォルトのノード時刻にデフォルト設定されないことを確認する必要があります。一般に、このメカニズムを実現するには、コールドリスタート全体でシステム時間を維持する必要があります。このような実装の1つの例は、バッテリバックアップのリアルタイムクロック（RTC）を使用することです。
One other mechanism for accomplishing this is similar to the one specified in [RFC7474] -- use the 64-bit ESSN as a wrap/boot count stored in non-volatile storage. This value is incremented anytime the IS-IS node loses its sequence number state, including when the Packet Sequence Number wraps.
これを達成するためのもう1つのメカニズムは、[RFC7474]で指定されているメカニズムに似ています-不揮発性ストレージに保存されるラップ/ブートカウントとして64ビットのESSNを使用します。この値は、IS-ISノードがシーケンス番号の状態を失うたびに増加します。これには、パケットシーケンス番号がラップしたときも含まれます。
There is a drawback to this approach, which is described as follows in Section 8 of [RFC7474]. It requires the IS-IS implementation to be able to save its boot count in non-volatile storage. If the non-volatile storage is ever repaired or router hardware is upgraded such that the contents are lost, keys MUST be changed to prevent replay attacks.
[RFC7474]のセクション8で次のように説明されているこのアプローチには欠点があります。ブートカウントを不揮発性ストレージに保存するには、IS-IS実装が必要です。不揮発性ストレージが修復されるか、ルーターのハードウェアがアップグレードされて内容が失われた場合、リプレイ攻撃を防ぐためにキーを変更する必要があります。
Appendix B. Operational/Implementation Considerations
付録B.運用/実装に関する考慮事項
Since the ESN is maintained per PDU type, per originator, and per link, this scheme can be useful for monitoring the health of the IS-IS adjacency. A Packet Sequence Number skip that occurs upon receiving an IIH can be recorded by the neighbors and can be used later to correlate adjacency state changes over the interface. For instance, in multi-access media, completely different issues on the network may be indicated when all neighbors record skips from the same IIH sender versus when only one neighbor records skips. For operational issues, effective usage of the TLV defined in this document MAY also need more system information before making concrete conclusions; defining all that information is beyond the scope of this document.
ESNはPDUタイプごと、発信元ごと、およびリンクごとに維持されるため、このスキームはIS-IS隣接の状態を監視するのに役立ちます。 IIHの受信時に発生するパケットシーケンス番号のスキップは、ネイバーによって記録され、後でインターフェイス上の隣接状態の変化を関連付けるために使用できます。たとえば、マルチアクセスメディアでは、すべてのネイバーレコードが同じIIH送信者からスキップする場合と、1つのネイバーレコードのみがスキップする場合とでは、ネットワーク上のまったく異なる問題が示される場合があります。運用上の問題については、このドキュメントで定義されているTLVを効果的に使用するには、具体的な結論を出す前に、より多くのシステム情報が必要になる場合があります。そのすべての情報を定義することは、このドキュメントの範囲を超えています。
Acknowledgements
謝辞
As some sort of sequence number mechanism to thwart protocol replays is a old concept, the authors of this document do not make any claims on the originality of the overall protection idea described. The authors are thankful for the review and the valuable feedback provided by Acee Lindem and Joel Halpern. Thanks to Alia Atlas, Chris Hopps, Nevil Brownlee, and Adam W. Montville for their reviews and suggestions during IESG directorate review. The authors also thank Christer Holmberg, Ben Campbell, Barry Leiba, Stephen Farrell, and Alvaro Retana for their reviews of this document.
プロトコルのリプレイを阻止するためのある種のシーケンス番号メカニズムは古い概念であるため、このドキュメントの作成者は、説明されている全体的な保護のアイデアの独創性については一切主張しません。著者はレビューとAcee LindemとJoel Halpernからの貴重なフィードバックに感謝しています。 IESG総局レビューでのレビューと提案を提供してくれたAlia Atlas、Chris Hopps、Nevil Brownlee、Adam W. Montvilleに感謝します。著者はまた、このドキュメントのレビューについて、Christer Holmberg、Ben Campbell、Barry Leiba、Stephen Farrell、およびAlvaro Retanaに感謝します。
Contributors
貢献者
The authors would like to thank Les Ginsberg for his significant contribution in detailed reviews and suggestions.
著者は、詳細なレビューと提案に多大な貢献をしてくれたLes Ginsbergに感謝します。
Authors' Addresses
著者のアドレス
Uma Chunduri Ericsson Inc. 300 Holger Way, San Jose, California 95134 United States
Uma Chunduri Ericsson Inc. 300 Holger Way、San Jose、California 95134アメリカ合衆国
Phone: 408 750-5678 Email: uma.chunduri@ericsson.com
電話：408 750-5678メール：uma.chunduri@ericsson.com
Wenhu Lu Ericsson Inc. 300 Holger Way, San Jose, California 95134 United States
Wenhu Lu Ericsson Inc. 300 Holger Way、San Jose、California 95134アメリカ合衆国
Email: wenhu.lu@ericsson.com
Albert Tian Ericsson Inc. 300 Holger Way, San Jose, California 95134 United States
Albert Tian Ericsson Inc. 300 Holger Way、San Jose、California 95134アメリカ合衆国
Phone: 408 750-5210 Email: albert.tian@ericsson.com
電話：408 750-5210メール：albert.tian@ericsson.com
Naiming Shen Cisco Systems, Inc. 225 West Tasman Drive, San Jose, California 95134 United States
Naiming Shen Cisco Systems、Inc. 225 West Tasman Drive、San Jose、California 95134 United States
Email: naiming@cisco.com