[要約] RFC 2890はGREプロトコルにおけるキーとシーケンス番号の拡張に関する仕様であり、要約すると以下のようになります。1. GREプロトコルにセキュリティ機能を追加するためのキーとシーケンス番号の拡張を提供する。 2. パケットの整合性と認証を確保し、GREトンネルのセキュリティを向上させる。 3. GREプロトコルのセキュリティ要件を満たすための拡張機能を提供する。
Network Working Group G. Dommety
Request for Comments: 2890 Cisco Systems
Category: Standards Track September 2000
Key and Sequence Number Extensions to GRE
GREへのキーおよびシーケンス番号拡張
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
GRE (Generic Routing Encapsulation) specifies a protocol for encapsulation of an arbitrary protocol over another arbitrary network layer protocol. This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header [1].
GRE（汎用ルーティングカプセル化）別の任意のネットワークレイヤープロトコルを介した任意のプロトコルのカプセル化のためのプロトコルを指定します。このドキュメントでは、キーとシーケンス番号の2つのフィールドをオプションでGREヘッダーで運ぶことができる拡張機能について説明します[1]。
The current specification of Generic Routing Encapsulation [1] specifies a protocol for encapsulation of an arbitrary protocol over another arbitrary network layer protocol. This document describes enhancements by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header [1]. The Key field is intended to be used for identifying an individual traffic flow within a tunnel. The Sequence Number field is used to maintain sequence of packets within the GRE Tunnel.
一般的なルーティングカプセル化[1]の現在の仕様は、別の任意のネットワークレイヤープロトコル上の任意のプロトコルのカプセル化のためのプロトコルを指定します。このドキュメントでは、キーとシーケンス番号の2つのフィールドをオプションでGREヘッダーで運ぶことができる拡張機能について説明します[1]。キーフィールドは、トンネル内の個々の交通フローを識別するために使用することを目的としています。シーケンス番号フィールドは、GREトンネル内のパケットのシーケンスを維持するために使用されます。
The keywords "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 [3].
キーワードは「必要」、「必要」、「必須」、「shall」、「shall "、" sulld "、" nove "、" becommended "、" "、" optional "は、RFC 2119 [3]に記載されているように解釈されます。
In addition, the following words are used to signify the requirements of the specification.
さらに、次の単語を使用して、仕様の要件を意味します。
Silently discard The implementation discards the datagram without further processing, and without indicating an error to the sender. The implementation SHOULD provide the capability of logging the error, including the contents of the discarded datagram, and SHOULD record the event in a statistics counter.
実装は、さらに処理せずに、および送信者へのエラーを示さずにデータグラムを廃棄します。実装は、破棄されたデータグラムの内容を含むエラーを記録する機能を提供し、統計カウンターにイベントを記録する必要があります。
The GRE packet header[1] has the following format:
GREパケットヘッダー[1]には、次の形式があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| Reserved0 | Ver | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum (optional) | Reserved1 (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The proposed GRE header will have the following format:
提案されているGREヘッダーには、次の形式があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| |K|S| Reserved0 | Ver | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum (optional) | Reserved1 (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key Present (bit 2)
キープレゼント（ビット2）
If the Key Present bit is set to 1, then it indicates that the Key field is present in the GRE header. Otherwise, the Key field is not present in the GRE header.
キープレゼントビットが1に設定されている場合、キーフィールドがGREヘッダーに存在することを示します。それ以外の場合、キーフィールドはGREヘッダーに存在しません。
Sequence Number Present (bit 3)
シーケンス番号が表示されます（ビット3）
If the Sequence Number Present bit is set to 1, then it indicates that the Sequence Number field is present. Otherwise, the Sequence Number field is not present in the GRE header.
存在するシーケンス番号が1に設定されている場合、シーケンス番号フィールドが存在することを示します。それ以外の場合、GREヘッダーにはシーケンス番号フィールドが存在しません。
The Key and the Sequence Present bits are chosen to be compatible with RFC 1701 [2].
キーとシーケンスの存在ビットは、RFC 1701と互換性があるように選択されます[2]。
The Key field contains a four octet number which was inserted by the encapsulator. The actual method by which this Key is obtained is beyond the scope of the document. The Key field is intended to be used for identifying an individual traffic flow within a tunnel. For example, packets may need to be routed based on context information not present in the encapsulated data. The Key field provides this context and defines a logical traffic flow between encapsulator and decapsulator. Packets belonging to a traffic flow are encapsulated using the same Key value and the decapsulating tunnel endpoint identifies packets belonging to a traffic flow based on the Key Field value.
キーフィールドには、エンコプセーターによって挿入された4つのオクテット番号が含まれています。このキーが取得される実際の方法は、ドキュメントの範囲を超えています。キーフィールドは、トンネル内の個々の交通フローを識別するために使用することを目的としています。たとえば、カプセル化されたデータに存在しないコンテキスト情報に基づいてパケットをルーティングする必要がある場合があります。重要なフィールドは、このコンテキストを提供し、エンカプセーターとデカプセーター間の論理的なトラフィックフローを定義します。トラフィックフローに属するパケットは、同じキー値を使用してカプセル化され、脱カプセンシングトンネルエンドポイントは、キーフィールド値に基づいてトラフィックフローに属するパケットを識別します。
The Sequence Number field is a four byte field and is inserted by the encapsulator when Sequence Number Present Bit is set. The Sequence Number MUST be used by the receiver to establish the order in which packets have been transmitted from the encapsulator to the receiver. The intended use of the Sequence Field is to provide unreliable but in-order delivery. If the Key present bit (bit 2) is set, the sequence number is specific to the traffic flow identified by the Key field. Note that packets without the sequence bit set can be interleaved with packets with the sequence bit set.
シーケンス番号フィールドは4バイトフィールドであり、シーケンス番号の表示ビットが設定されると、エンカプセーターによって挿入されます。シーケンス番号は、受信機がパケットがエンコーサレータから受信機に送信された順序を確立する必要があります。シーケンスフィールドの意図された使用は、信頼できないが注文内の配信を提供することです。キープレゼントビット（ビット2）が設定されている場合、シーケンス番号は、キーフィールドによって識別されるトラフィックフローに固有です。シーケンスビットセットのないパケットは、シーケンスビットセットを備えたパケットとインターリーブできることに注意してください。
The sequence number value ranges from 0 to (2**32)-1. The first datagram is sent with a sequence number of 0. The sequence number is thus a free running counter represented modulo 2**32. The receiver maintains the sequence number value of the last successfully decapsulated packet. Upon establishment of the GRE tunnel, this value should be set to (2**32)-1.
シーケンス数の値の範囲は0〜（2 ** 32）-1です。最初のデータグラムは、0のシーケンス番号で送信されます。したがって、シーケンス番号は、モジュロ2 ** 32を表すフリーランニングカウンターです。受信機は、最後に正常に脱カプセル化されたパケットのシーケンス番号値を維持します。GREトンネルが確立されると、この値は（2 ** 32）-1に設定する必要があります。
When the decapsulator receives an out-of sequence packet it SHOULD be silently discarded. A packet is considered an out-of-sequence packet if the sequence number of the received packet is less than or equal to the sequence number of last successfully decapsulated packet. The sequence number of a received message is considered less than or equal to the last successfully received sequence number if its value lies in the range of the last received sequence number and the preceding 2**31-1 values, inclusive.
カプセレータがシーケンス外のパケットを受信する場合、静かに廃棄する必要があります。受信したパケットのシーケンス番号が最後に正常に脱カプセル化されたパケットのシーケンス番号以下である場合、パケットはアウトオブシーケンスパケットと見なされます。受信したメッセージのシーケンス番号は、その値が最後に受信したシーケンス番号の範囲と前の2 ** 31-1値の範囲にある場合、最後に正常に受信したシーケンス番号以下と見なされます。
If the received packet is an in-sequence packet, it is successfully decapsulated. An in-sequence packet is one with a sequence number exactly 1 greater than (modulo 2**32) the last successfully decapsulated packet, or one in which the sequence number field is not present (S bit not set).
受信したパケットがシーケンスパケットである場合、それは正常に脱カプセル化されます。シーケンスパケットは、最後に正常に脱カプセル化されたパケット、またはシーケンス番号フィールドが存在しない（sビットが設定されていない）よりも正確に1（Modulo 2 ** 32）より大きいシーケンス番号を持つものです。
If the received packet is neither an in-sequence nor an out-of-sequence packet it indicates a sequence number gap. The receiver may perform a small amount of buffering in an attempt to recover the original sequence of transmitted packets. In this case, the packet may be placed in a buffer sorted by sequence number. If an in-sequence packet is received and successfully decapsulated, the receiver should consult the head of this buffer to see if the next in-sequence packet has already been received. If so, the receiver should decapsulate it as well as the following in-sequence packets that may be present in the buffer. The "last successfully decapsulated sequence number" should then be set to the last packet that was decapsulated from the buffer.
受信したパケットがシーケンスでもシーケンス外パケットでもない場合、シーケンス数のギャップを示します。受信機は、送信されたパケットの元のシーケンスを回復しようとして、少量のバッファリングを実行できます。この場合、パケットはシーケンス番号でソートされたバッファーに配置できます。シーケンスパケットが受信され、脱カプセル化に成功した場合、受信者はこのバッファーのヘッドに相談して、次のシーケンスパケットが既に受信されているかどうかを確認する必要があります。その場合、受信機はそれをバッファに存在する可能性のある次のインセンセンスパケットと同様にそれを脱カプセル化する必要があります。「最後の成功した脱カプセル化シーケンス番号」は、バッファから脱カプセル化された最後のパケットに設定する必要があります。
Under no circumstances should a packet wait more that OUTOFORDER_TIMER milliseconds in the buffer. If a packet has been waiting that long, the receiver MUST immediately traverse the buffer in sorted order, decapsulating packets (and ignoring any sequence number gaps) until there are no more packets in the buffer that have been waiting longer than OUTOFORDER_TIMER milliseconds. The "last successfully decapsulated sequence number" should then be set to the last packet so decapsulated.
いかなる状況でも、パケットはバッファ内のoutoforder_timerミリ秒よりも多くの待機をしてはなりません。パケットがそのように長い間待っていた場合、受信者は、バッファーにパケットを脱カプセル化する（およびシーケンス番号のギャップを無視する）バッファーを脱カプセル化して、バッファーにパケットを脱カプセル化する（および任意のシーケンス番号のギャップを無視する）ことをすぐに通過している必要があります。「最後の成功した脱カプセル化シーケンス番号」は、脱カプセル化された最後のパケットに設定する必要があります。
The receiver may place a limit on the number of packets in any per-flow buffer (Packets with the same Key Field value belong to a flow). If a packet arrives that would cause the receiver to place more than MAX_PERFLOW_BUFFER packets into a given buffer, then the packet at the head of the buffer is immediately decapsulated regardless of its sequence number and the "last successfully decapsulated sequence number" is set to its sequence number. The newly arrived packet may then be placed in the buffer.
レシーバーは、流量ごとのバッファー（同じキーフィールド値を持つパケットがフローに属する）にパケットの数に制限を配置する場合があります。受信機がMAX_PERFLOW_BUFFERを特定のバッファーに配置するパケットが到着すると、バッファーのヘッドのパケットがシーケンス番号に関係なくすぐに脱カプセル化されます。シーケンス番号。新しく到着したパケットは、バッファーに配置できます。
Note that the sequence number is used to detect lost packets and/or restore the original sequence of packets (with buffering) that may have been reordered during transport. Use of the sequence number option should be used appropriately; in particular, it is a good idea a avoid using when tunneling protocols that have higher layer in-order delivery mechanisms or are tolerant to out-of-order delivery. If only at certain instances the protocol being carried in the GRE tunnel requires in-sequence delivery, only the corresponding packets encapsulated in a GRE header can be sent with the sequence bit set.
シーケンス番号は、失われたパケットを検出したり、輸送中に再注文した可能性のあるパケットの元のシーケンス（バッファリング付き）を復元するために使用されることに注意してください。シーケンス番号の使用オプションは適切に使用する必要があります。特に、より高い層内送達メカニズムを備えた、または秩序外の配信に耐性のあるトンネリングプロトコルを使用することは避けています。特定のインスタンスでのみ、GREトンネルに携帯されているプロトコルがシーケンス配信を必要とする場合、GREヘッダーにカプセル化された対応するパケットのみをシーケンスビットセットで送信できます。
Reordering of out-of sequence packets MAY be performed by the decapsulator for improved performance and tolerance to reordering in the network. A small amount of reordering buffer (MAX_PERFLOW_BUFFER) may help in improving performance when the higher layer employs stateful compression or encryption. Since the state of the stateful compression or encryption is reset by packet loss, it might help the performance to tolerate some small amount of packet reordering in the network by buffering.
ネットワークでの並べ替えに対するパフォーマンスと耐性の改善のために、脱カプセル装置によって順序外のパケットの並べ替えが実行される場合があります。少量の並べ替えバッファー（MAX_PERFLOW_BUFFER）は、高層がステートフルな圧縮または暗号化を使用すると、パフォーマンスの向上に役立ちます。州の圧縮または暗号化の状態はパケット損失によってリセットされるため、パフォーマンスがバッファリングによってネットワーク内の少量のパケットの並べ替えを許容するのに役立つ可能性があります。
This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GRE (Generic Routing Encapsulation) Header [1]. When using the Sequence number field, it is possible to inject packets with an arbitrary Sequence number and launch a Denial of Service attack. In order to protect against such attacks, IP security protocols [4] MUST be used to protect the GRE header and the tunneled payload. Either ESP (Encapsulating Security Payload) [5] or AH (Authentication Header)[6] MUST be used to protect the GRE header. If ESP is used it protects the IP payload which includes the GRE header. If AH is used the entire packet other than the mutable fields are authenticated. Note that Key field is not involved in any sort or security (despite its name).
このドキュメントでは、キーとシーケンス番号の2つのフィールドをオプションでGRE（汎用ルーティングカプセル化）ヘッダーで運ぶことができる拡張機能について説明します[1]。シーケンス番号フィールドを使用する場合、パケットを任意のシーケンス番号で注入し、サービス拒否攻撃を開始することができます。このような攻撃から保護するには、GREヘッダーとトンネル付きペイロードを保護するために、IPセキュリティプロトコル[4]を使用する必要があります。ESP（セキュリティペイロードのカプセル化）[5]またはAH（認証ヘッダー）[6]を使用して、GREヘッダーを保護する必要があります。ESPを使用すると、GREヘッダーを含むIPペイロードを保護します。AHを使用すると、可変フィールド以外のパケット全体が認証されます。キーフィールドは、いかなる種類やセキュリティにも関与していないことに注意してください（その名前にもかかわらず）。
This document does not require any allocations by the IANA and therefore does not have any new IANA considerations.
このドキュメントでは、IANAによる割り当ては必要ありません。したがって、新しいIANAの考慮事項はありません。
This document is derived from the original ideas of the authors of RFC 1701. Kent Leung, Pete McCann, Mark Townsley, David Meyer, Yingchun Xu, Ajoy Singh and many others provided useful discussion. The author would like to thank all the above people.
このドキュメントは、RFC 1701の著者の元のアイデアから派生しています。KentLeung、Pete McCann、Mark Townsley、David Meyer、Yingchun Xu、Ajoy Singhなどが有用な議論を提供しました。著者は、上記のすべての人々に感謝したいと思います。
[1] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[1] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「一般的なルーティングカプセル化（GRE）」、RFC 2784、2000年3月。
[2] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic Routing Encapsulation", RFC 1701, October 1994.
[2] Hanks、S.、Li、T、Farinacci、D。、およびP. Traina、「一般的なルーティングカプセル化」、RFC 1701、1994年10月。
[3] Bradner S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner S.、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[4] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[4] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[5] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[5] Kent、S。およびR. Atkinson、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[6] Kent, S., and R. Atkinson, " IP Authentication Header", RFC 2402, November 1998.
[6] Kent、S。、およびR. Atkinson、「IP Authentication Header」、RFC 2402、1998年11月。
Author's Address
著者の連絡先
Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
Gopal Dommety Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134
EMail: gdommety@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。