[要約] RFC 2406は、IP Encapsulating Security Payload（ESP）プロトコルに関する仕様を提供しています。ESPは、IPパケットの暗号化と認証を提供するために使用されます。このRFCの目的は、ESPの機能と動作を定義し、ネットワークセキュリティの向上を促進することです。
Network Working Group S. Kent
Request for Comments: 2406 BBN Corp
Obsoletes: 1827 R. Atkinson
Category: Standards Track @Home Network
November 1998
IP Encapsulating Security Payload (ESP)
IPカプセル化セキュリティペイロード（ESP）
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 (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Table of Contents
目次
1. Introduction..................................................2
2. Encapsulating Security Payload Packet Format..................3
2.1 Security Parameters Index................................4
2.2 Sequence Number .........................................4
2.3 Payload Data.............................................5
2.4 Padding (for Encryption).................................5
2.5 Pad Length...............................................7
2.6 Next Header..............................................7
2.7 Authentication Data......................................7
3. Encapsulating Security Protocol Processing....................7
3.1 ESP Header Location......................................7
3.2 Algorithms..............................................10
3.2.1 Encryption Algorithms..............................10
3.2.2 Authentication Algorithms..........................10
3.3 Outbound Packet Processing..............................10
3.3.1 Security Association Lookup........................11
3.3.2 Packet Encryption..................................11
3.3.3 Sequence Number Generation.........................12
3.3.4 Integrity Check Value Calculation..................12
3.3.5 Fragmentation......................................13
3.4 Inbound Packet Processing...............................13
3.4.1 Reassembly.........................................13
3.4.2 Security Association Lookup........................13
3.4.3 Sequence Number Verification.......................14
3.4.4 Integrity Check Value Verification.................15
3.4.5 Packet Decryption..................................16
4. Auditing.....................................................17
5. Conformance Requirements.....................................18
6. Security Considerations......................................18
7. Differences from RFC 1827....................................18
Acknowledgements................................................19
References......................................................19
Disclaimer......................................................20
Author Information..............................................21
Full Copyright Statement........................................22
The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. ESP may be applied alone, in combination with the IP Authentication Header (AH) [KA97b], or in a nested fashion, e.g., through the use of tunnel mode (see "Security Architecture for the Internet Protocol" [KA97a], hereafter referred to as the Security Architecture document). Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. For more details on how to use ESP and AH in various network environments, see the Security Architecture document [KA97a].
カプセル化セキュリティペイロード（ESP）ヘッダーは、IPv4とIPv6でセキュリティサービスの組み合わせを提供するように設計されています。 ESPは、単独で、IP認証ヘッダー（AH）[KA97b]と組み合わせて、またはトンネルモードを使用するなど、入れ子にして適用できます（「インターネットプロトコルのセキュリティアーキテクチャ」[KA97a]を参照してください）。セキュリティアーキテクチャドキュメントとして）。セキュリティサービスは、通信するホストのペア間、通信するセキュリティゲートウェイのペア間、またはセキュリティゲートウェイとホストの間に提供できます。さまざまなネットワーク環境でESPおよびAHを使用する方法の詳細については、セキュリティアーキテクチャドキュメント[KA97a]を参照してください。
The ESP header is inserted after the IP header and before the upper layer protocol header (transport mode) or before an encapsulated IP header (tunnel mode). These modes are described in more detail below.
ESPヘッダーは、IPヘッダーの後、上位層プロトコルヘッダーの前（トランスポートモード）またはカプセル化されたIPヘッダーの前（トンネルモード）に挿入されます。これらのモードについては、以下で詳しく説明します。
ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. The set of services provided depends on options selected at the time of Security Association establishment and on the placement of the implementation. Confidentiality may be selected independent of all other services. However, use of confidentiality without integrity/authentication (either in ESP or separately in AH) may subject traffic to certain forms of active attacks that could undermine the confidentiality service (see [Bel96]). Data origin authentication and connectionless integrity are joint services (hereafter referred to jointly as "authentication) and are offered as an option in conjunction with (optional) confidentiality. The anti-replay service may be selected only if data origin authentication is selected, and its election is solely at the discretion of the receiver. (Although the default calls for the sender to increment the Sequence Number used for anti-replay, the service is effective only if the receiver checks the Sequence Number.) Traffic flow confidentiality requires selection of tunnel mode, and is most effective if implemented at a security gateway, where traffic aggregation may be able to mask true source-destination patterns. Note that although both confidentiality and authentication are optional, at least one of them MUST be selected.
ESPは、機密性、データ発信元認証、コネクションレスの整合性、アンチリプレイサービス（部分的なシーケンス整合性の形式）、および制限されたトラフィックフローの機密性を提供するために使用されます。提供されるサービスのセットは、セキュリティアソシエーションの確立時に選択されたオプションと実装の配置によって異なります。機密性は、他のすべてのサービスから独立して選択できます。ただし、整合性/認証なしで（ESPまたは個別にAHのいずれかで）機密性を使用すると、機密性サービスを損なう可能性のある特定の形式のアクティブな攻撃を受ける可能性があります（[Bel96]を参照）。データ発信元認証とコネクションレスインテグリティは共同サービス（以下、「認証」と総称します）であり、（オプションの）機密性とともにオプションとして提供されます。アンチリプレイサービスは、データ発信元認証が選択されている場合にのみ選択できます。選出は受信者の裁量にのみ依存します（デフォルトでは、送信者がアンチリプレイに使用されるシーケンス番号をインクリメントするように要求しますが、サービスは受信者がシーケンス番号をチェックする場合にのみ有効です）。モード、およびトラフィック集約が真の送信元-宛先パターンをマスクできるセキュリティゲートウェイに実装されている場合に最も効果的です。機密性と認証の両方がオプションですが、少なくとも1つを選択する必要があることに注意してください。
It is assumed that the reader is familiar with the terms and concepts described in the Security Architecture document. In particular, the reader should be familiar with the definitions of security services offered by ESP and AH, the concept of Security Associations, the ways in which ESP can be used in conjunction with the Authentication Header (AH), and the different key management options available for ESP and AH. (With regard to the last topic, the current key management options required for both AH and ESP are manual keying and automated keying via IKE [HC98].)
読者は、セキュリティアーキテクチャドキュメントで説明されている用語と概念に精通していることを前提としています。特に、読者は、ESPとAHによって提供されるセキュリティサービスの定義、セキュリティアソシエーションの概念、認証ヘッダー（AH）と組み合わせてESPを使用する方法、およびさまざまなキー管理オプションに精通している必要があります。 ESPおよびAHで使用できます。 （最後のトピックに関して、AHとESPの両方に必要な現在のキー管理オプションは、手動キーイングとIKE [HC98]による自動キーイングです。）
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97].
このドキュメントに記載されているキーワードは、必須、必須、必須、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY、およびOPTIONALであり、RFC 2119 [Bra97]に記載されているとおりに解釈されます。
The protocol header (IPv4, IPv6, or Extension) immediately preceding the ESP header will contain the value 50 in its Protocol (IPv4) or Next Header (IPv6, Extension) field [STD-2].
ESPヘッダーの直前のプロトコルヘッダー（IPv4、IPv6、または拡張）では、プロトコル（IPv4）または次のヘッダー（IPv6、拡張）フィールド[STD-2]に値50が含まれます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| Security Parameters Index (SPI) | ^Auth.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |erage
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data* (variable) | | ^
~ ~ | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |erage*
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Authentication Data (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* If included in the Payload field, cryptographic synchronization data, e.g., an Initialization Vector (IV, see
* ペイロードフィールドに含まれている場合は、暗号化同期データ（初期化ベクトル（IV、
Section 2.3), usually is not encrypted per se, although it often is referred to as being part of the ciphertext.
セクション2.3）は、それ自体は暗号化されていませんが、暗号文の一部と呼ばれることがよくあります。
The following subsections define the fields in the header format. "Optional" means that the field is omitted if the option is not selected, i.e., it is present in neither the packet as transmitted nor as formatted for computation of an Integrity Check Value (ICV, see Section 2.7). Whether or not an option is selected is defined as part of Security Association (SA) establishment. Thus the format of ESP packets for a given SA is fixed, for the duration of the SA. In contrast, "mandatory" fields are always present in the ESP packet format, for all SAs.
次のサブセクションでは、ヘッダー形式でフィールドを定義します。 「オプション」とは、オプションが選択されていない場合、つまり、送信されたパケットにも、整合性チェック値（ICV、セクション2.7を参照）の計算用にフォーマットされたフィールドにも存在しない場合、フィールドが省略されることを意味します。オプションが選択されるかどうかは、セキュリティアソシエーション（SA）確立の一部として定義されます。したがって、特定のSAのESPパケットの形式は、SAの期間中、固定されています。対照的に、「必須」フィールドは、すべてのSAのESPパケット形式で常に存在します。
The SPI is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (ESP), uniquely identifies the Security Association for this datagram. The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use; a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. It is ordinarily selected by the destination system upon establishment of an SA (see the Security Architecture document for more details). The SPI field is mandatory.
SPIは任意の32ビット値であり、宛先IPアドレスおよびセキュリティプロトコル（ESP）と組み合わせて、このデータグラムのセキュリティアソシエーションを一意に識別します。 1から255の範囲のSPI値のセットは、将来使用するためにInternet Assigned Numbers Authority（IANA）によって予約されています。予約済みのSPI値は、割り当てられたSPI値の使用がRFCで指定されていない限り、通常はIANAによって割り当てられません。これは通常、SAの確立時に宛先システムによって選択されます（詳細については、セキュリティアーキテクチャのドキュメントを参照してください）。 SPIフィールドは必須です。
The SPI value of zero (0) is reserved for local, implementation-specific use and MUST NOT be sent on the wire. For example, a key management implementation MAY use the zero SPI value to mean "No Security Association Exists" during the period when the IPsec implementation has requested that its key management entity establish a new SA, but the SA has not yet been established.
ゼロ（0）のSPI値は、ローカルの実装固有の使用のために予約されており、ネットワーク上で送信してはなりません（MUST NOT）。たとえば、キー管理実装は、IPSec実装がそのキー管理エンティティに新しいSAを確立するように要求したが、SAはまだ確立されていない期間に、ゼロSPI値を使用して「セキュリティアソシエーションが存在しない」ことを意味する場合があります。
This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). It is mandatory and is always present even if the receiver does not elect to enable the anti-replay service for a specific SA. Processing of the Sequence Number field is at the discretion of the receiver, i.e., the sender MUST always transmit this field, but the receiver need not act upon it (see the discussion of Sequence Number Verification in the "Inbound Packet Processing" section below).
この符号なし32ビットフィールドには、単調に増加するカウンター値（シーケンス番号）が含まれています。これは必須であり、受信者が特定のSAのアンチリプレイサービスを有効にすることを選択しなかった場合でも、常に存在します。シーケンス番号フィールドの処理は受信者の裁量にあります。つまり、送信者は常にこのフィールドを送信する必要がありますが、受信者はそれに応じる必要はありません（以下の「受信パケット処理」セクションのシーケンス番号検証の説明を参照）。 。
The sender's counter and the receiver's counter are initialized to 0 when an SA is established. (The first packet sent using a given SA will have a Sequence Number of 1; see Section 3.3.3 for more details on how the Sequence Number is generated.) If anti-replay is enabled (the default), the transmitted Sequence Number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA.
SAが確立されると、送信側のカウンターと受信側のカウンターは0に初期化されます。 （特定のSAを使用して送信される最初のパケットのシーケンス番号は1です。シーケンス番号の生成方法の詳細については、セクション3.3.3を参照してください。）アンチリプレイが有効な場合（デフォルト）、送信されたシーケンス番号は循環することは決してありません。したがって、SAで2 ^ 32番目のパケットを送信する前に、送信者のカウンターと受信者のカウンターをリセットする必要があります（新しいSA、つまり新しいキーを確立することによって）。
Payload Data is a variable-length field containing data described by the Next Header field. The Payload Data field is mandatory and is an integral number of bytes in length. If the algorithm used to encrypt the payload requires cryptographic synchronization data, e.g., an Initialization Vector (IV), then this data MAY be carried explicitly in the Payload field. Any encryption algorithm that requires such explicit, per-packet synchronization data MUST indicate the length, any structure for such data, and the location of this data as part of an RFC specifying how the algorithm is used with ESP. If such synchronization data is implicit, the algorithm for deriving the data MUST be part of the RFC.
ペイロードデータは、次のヘッダーフィールドで記述されるデータを含む可変長フィールドです。ペイロードデータフィールドは必須で、長さはバイト単位の整数です。ペイロードの暗号化に使用されるアルゴリズムが暗号化同期データ、たとえば初期化ベクトル（IV）を必要とする場合、このデータはペイロードフィールドで明示的に運ばれる場合があります。そのような明示的なパケットごとの同期データを必要とする暗号化アルゴリズムは、ESPでのアルゴリズムの使用方法を指定するRFCの一部として、そのようなデータの長さ、構造、およびこのデータの場所を示す必要があります。そのような同期データが暗黙的である場合、データを導出するためのアルゴリズムはRFCの一部である必要があります。
Note that with regard to ensuring the alignment of the (real) ciphertext in the presence of an IV:
IVの存在下での（実際の）暗号文の整列を保証することに関して、
o For some IV-based modes of operation, the receiver treats the IV as the start of the ciphertext, feeding it into the algorithm directly. In these modes, alignment of the start of the (real) ciphertext is not an issue at the receiver. o In some cases, the receiver reads the IV in separately from the ciphertext. In these cases, the algorithm specification MUST address how alignment of the (real) ciphertext is to be achieved.
o 一部のIVベースの操作モードでは、受信者はIVを暗号文の開始として扱い、直接アルゴリズムにフィードします。これらのモードでは、（実際の）暗号文の開始の整列は受信側の問題ではありません。 o場合によっては、受信者は暗号文とは別にIVを読み取ります。これらの場合、アルゴリズム仕様は、（実際の）暗号文の整列がどのように達成されるかを扱わなければなりません（MUST）。
Several factors require or motivate use of the Padding field.
いくつかの要因がPaddingフィールドの使用を要求または動機付けます。
o If an encryption algorithm is employed that requires the plaintext to be a multiple of some number of bytes, e.g., the block size of a block cipher, the Padding field is used to fill the plaintext (consisting of the Payload Data, Pad Length and Next Header fields, as well as the Padding) to the size required by the algorithm.
o プレーンテキストをバイト数の倍数にする必要がある暗号化アルゴリズムが使用されている場合（ブロック暗号のブロックサイズなど）、Paddingフィールドを使用して、プレーンテキスト（ペイロードデータ、パッド長、次から構成される）が入力されます。ヘッダーフィールドとPadding）をアルゴリズムで必要なサイズに設定します。
o Padding also may be required, irrespective of encryption algorithm requirements, to ensure that the resulting ciphertext terminates on a 4-byte boundary. Specifically, the Pad Length and Next Header fields must be right aligned within a 4-byte word, as illustrated in the ESP packet format figure above, to ensure that the Authentication Data field (if present) is aligned on a 4-byte boundary.
o暗号化アルゴリズムの要件に関係なく、結果の暗号文が4バイト境界で確実に終了するように、パディングが必要になる場合もあります。具体的には、上記のESPパケット形式の図に示すように、パッド長と次のヘッダーフィールドを4バイトワード内で右揃えにして、認証データフィールド（存在する場合）が4バイト境界に揃うようにする必要があります。
o Padding beyond that required for the algorithm or alignment reasons cited above, may be used to conceal the actual length of the payload, in support of (partial) traffic flow confidentiality. However, inclusion of such additional padding has adverse bandwidth implications and thus its use should be undertaken with care.
o （部分的な）トラフィックフローの機密性をサポートするために、上記のアルゴリズムまたはアライメントの理由で必要なパディングを超えるパディングを使用して、ペイロードの実際の長さを隠すことができます。ただし、このような追加のパディングを含めることは、帯域幅に悪影響を与えるため、その使用には注意が必要です。
The sender MAY add 0-255 bytes of padding. Inclusion of the Padding field in an ESP packet is optional, but all implementations MUST support generation and consumption of padding.
送信者は、0〜255バイトのパディングを追加してもよい（MAY）。 ESPパケットにパディングフィールドを含めることはオプションですが、すべての実装はパディングの生成と消費をサポートする必要があります。
a. For the purpose of ensuring that the bits to be encrypted are a multiple of the algorithm's blocksize (first bullet above), the padding computation applies to the Payload Data exclusive of the IV, the Pad Length, and Next Header fields.
a. 暗号化されるビットがアルゴリズムのブロックサイズ（上記の最初の箇条書き）の倍数であることを保証する目的で、パディング計算は、IV、パッド長、および次のヘッダーフィールドを除くペイロードデータに適用されます。
b. For the purposes of ensuring that the Authentication Data is aligned on a 4-byte boundary (second bullet above), the padding computation applies to the Payload Data inclusive of the IV, the Pad Length, and Next Header fields.
b. 認証データが4バイト境界に整列されるようにするため（上記の2番目の箇条書き）、パディング計算は、IV、パッド長、および次のヘッダーフィールドを含むペイロードデータに適用されます。
If Padding bytes are needed but the encryption algorithm does not specify the padding contents, then the following default processing MUST be used. The Padding bytes are initialized with a series of (unsigned, 1-byte) integer values. The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3, ... When this padding scheme is employed, the receiver SHOULD inspect the Padding field. (This scheme was selected because of its relative simplicity, ease of implementation in hardware, and because it offers limited protection against certain forms of "cut and paste" attacks in the absence of other integrity measures, if the receiver checks the padding values upon decryption.)
パディングバイトが必要であるが、暗号化アルゴリズムがパディングコンテンツを指定していない場合は、次のデフォルト処理を使用する必要があります。パディングバイトは、一連の（符号なし、1バイト）整数値で初期化されます。平文に追加された最初のパディングバイトには1の番号が付けられ、後続のパディングバイトは単調に増加するシーケンスを構成します。1、2、3、...このパディングスキームが使用される場合、受信者はパディングフィールドを検査する必要があります。 （このスキームが選択されたのは、その比較的単純さ、ハードウェアでの実装の容易さ、および受信者が復号化時にパディング値をチェックする場合、他の整合性対策がない場合に特定の形式の「カットアンドペースト」攻撃に対する保護が制限されるためです。 。）
Any encryption algorithm that requires Padding other than the default described above, MUST define the Padding contents (e.g., zeros or random data) and any required receiver processing of these Padding bytes in an RFC specifying how the algorithm is used with ESP. In such circumstances, the content of the Padding field will be determined by the encryption algorithm and mode selected and defined in the corresponding algorithm RFC. The relevant algorithm RFC MAY specify that a receiver MUST inspect the Padding field or that a receiver MUST inform senders of how the receiver will handle the Padding field.
上記のデフォルト以外のパディングを必要とする暗号化アルゴリズムでは、パディングの内容（たとえば、ゼロまたはランダムデータ）と、アルゴリズムがESPでどのように使用されるかを指定するRFCでこれらのパディングバイトの必要なレシーバー処理を定義する必要があります。このような状況では、Paddingフィールドの内容は、対応するアルゴリズムRFCで選択および定義された暗号化アルゴリズムとモードによって決定されます。関連するアルゴリズムRFCは、レシーバーがパディングフィールドを検査しなければならないこと、またはレシーバーがパディングフィールドを処理する方法を送信者に通知しなければならないことを指定できます（MAY）。
The Pad Length field indicates the number of pad bytes immediately preceding it. The range of valid values is 0-255, where a value of zero indicates that no Padding bytes are present. The Pad Length field is mandatory.
Pad Lengthフィールドは、その直前のパッドバイト数を示します。有効な値の範囲は0〜255です。ゼロの値は、パディングバイトが存在しないことを示します。 Pad Lengthフィールドは必須です。
The Next Header is an 8-bit field that identifies the type of data contained in the Payload Data field, e.g., an extension header in IPv6 or an upper layer protocol identifier. The value of this field is chosen from the set of IP Protocol Numbers defined in the most recent "Assigned Numbers" [STD-2] RFC from the Internet Assigned Numbers Authority (IANA). The Next Header field is mandatory.
次のヘッダーは、IPv6の拡張ヘッダーや上位層プロトコル識別子など、ペイロードデータフィールドに含まれるデータのタイプを識別する8ビットのフィールドです。このフィールドの値は、Internet Assigned Numbers Authority（IANA）の最新の「Assigned Numbers」[STD-2] RFCで定義されているIPプロトコル番号のセットから選択されます。次のヘッダーフィールドは必須です。
The Authentication Data is a variable-length field containing an Integrity Check Value (ICV) computed over the ESP packet minus the Authentication Data. The length of the field is specified by the authentication function selected. The Authentication Data field is optional, and is included only if the authentication service has been selected for the SA in question. The authentication algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation.
認証データは、ESPパケットから認証データを差し引いて計算された整合性チェック値（ICV）を含む可変長フィールドです。フィールドの長さは、選択した認証機能によって指定されます。 「認証データ」フィールドはオプションであり、問題のSAに対して認証サービスが選択されている場合にのみ含まれます。認証アルゴリズムの仕様では、ICVの長さと、検証のための比較ルールと処理手順を指定する必要があります。
Like AH, ESP may be employed in two ways: transport mode or tunnel mode. The former mode is applicable only to host implementations and provides protection for upper layer protocols, but not the IP header. (In this mode, note that for "bump-in-the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use.)
AHと同様に、ESPはトランスポートモードまたはトンネルモードの2つの方法で使用できます。前者のモードはホスト実装にのみ適用可能であり、上位層プロトコルを保護しますが、IPヘッダーは保護しません。 （このモードでは、セキュリティアーキテクチャのドキュメントで定義されている「bump-in-the-stack」または「bump-in-the-wire」実装の場合、インバウンドおよびアウトバウンドIPフラグメントは、追加のIPsec実装を必要とする場合があることに注意してください。この仕様に準拠し、透過的なIPsecサポートを提供するためのIPの再構成/断片化。複数のインターフェースが使用されている場合、これらの実装内でそのような操作を実行するには、特別な注意が必要です。）
In transport mode, ESP is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other IPsec headers that have already been inserted. In the context of IPv4, this translates to placing ESP after the IP header (and any options that it contains), but before the upper layer protocol. (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP. For example, an ICMP message MAY be sent using either "transport" mode or "tunnel" mode.) The following diagram illustrates ESP transport mode positioning for a typical IPv4 packet, on a "before and after" basis. (The "ESP trailer" encompasses any Padding, plus the Pad Length, and Next Header fields.)
トランスポートモードでは、ESPはIPヘッダーの後で、TCP、UDP、ICMPなどの上位層プロトコルの前、またはすでに挿入されている他のIPsecヘッダーの前に挿入されます。 IPv4のコンテキストでは、これは、IPヘッダー（およびそれに含まれるすべてのオプション）の後、上位層プロトコルの前にESPを配置することを意味します。 （「トランスポート」モードという用語は、その使用をTCPおよびUDPに制限するものと誤解されるべきではないことに注意してください。たとえば、ICMPメッセージは、「トランスポート」モードまたは「トンネル」モードのいずれかを使用して送信できます。）次の図は、ESPトランスポートを示しています「前と後」ベースでの典型的なIPv4パケットのモードポジショニング。 （「ESPトレーラー」には、すべてのパディング、パッド長、および次のヘッダーフィールドが含まれます。）
BEFORE APPLYING ESP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING ESP
-------------------------------------------------
IPv4 |orig IP hdr | ESP | | | ESP | ESP|
|(any options)| Hdr | TCP | Data | Trailer |Auth|
-------------------------------------------------
|<----- encrypted ---->|
|<------ authenticated ----->|
In the IPv6 context, ESP is viewed as an end-to-end payload, and thus should appear after hop-by-hop, routing, and fragmentation extension headers. The destination options extension header(s) could appear either before or after the ESP header depending on the semantics desired. However, since ESP protects only fields after the ESP header, it generally may be desirable to place the destination options header(s) after the ESP header. The following diagram illustrates ESP transport mode positioning for a typical IPv6 packet.
IPv6のコンテキストでは、ESPはエンドツーエンドのペイロードと見なされるため、ホップバイホップ、ルーティング、およびフラグメンテーション拡張ヘッダーの後に表示されます。宛先オプション拡張ヘッダーは、必要なセマンティクスに応じて、ESPヘッダーの前または後に表示されます。ただし、ESPはESPヘッダーの後のフィールドのみを保護するため、通常、宛先オプションヘッダーをESPヘッダーの後に配置することが望ましい場合があります。次の図は、一般的なIPv6パケットのESPトランスポートモードの配置を示しています。
BEFORE APPLYING ESP
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
AFTER APPLYING ESP
---------------------------------------------------------
IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP|
|IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer|Auth|
---------------------------------------------------------
|<---- encrypted ---->|
|<---- authenticated ---->|
* = if present, could be before ESP, after ESP, or both
* =存在する場合、ESPの前、ESPの後、またはその両方の可能性があります
ESP and AH headers can be combined in a variety of modes. The IPsec Architecture document describes the combinations of security associations that must be supported.
ESPヘッダーとAHヘッダーは、さまざまなモードで組み合わせることができます。 IPsecアーキテクチャドキュメントでは、サポートする必要があるセキュリティアソシエーションの組み合わせについて説明しています。
Tunnel mode ESP may be employed in either hosts or security gateways. When ESP is implemented in a security gateway (to protect subscriber transit traffic), tunnel mode must be used. In tunnel mode, the "inner" IP header carries the ultimate source and destination addresses, while an "outer" IP header may contain distinct IP addresses, e.g., addresses of security gateways. In tunnel mode, ESP protects the entire inner IP packet, including the entire inner IP header. The position of ESP in tunnel mode, relative to the outer IP header, is the same as for ESP in transport mode. The following diagram illustrates ESP tunnel mode positioning for typical IPv4 and IPv6 packets.
トンネルモードESPは、ホストまたはセキュリティゲートウェイで使用できます。 ESPがセキュリティゲートウェイに実装されている場合（サブスクライバー通過トラフィックを保護するため）、トンネルモードを使用する必要があります。トンネルモードでは、「内部」IPヘッダーは最終的な送信元アドレスと宛先アドレスを伝達しますが、「外部」IPヘッダーには、セキュリティゲートウェイのアドレスなどの個別のIPアドレスが含まれる場合があります。トンネルモードでは、ESPは内部IPヘッダー全体を含む内部IPパケット全体を保護します。トンネルモードのESPの位置は、外部IPヘッダーを基準にして、トランスポートモードのESPと同じです。次の図は、一般的なIPv4およびIPv6パケットのESPトンネルモードの配置を示しています。
-----------------------------------------------------------
IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP|
|(any options)| ESP | (any options) |TCP|Data|Trailer|Auth|
-----------------------------------------------------------
|<--------- encrypted ---------->|
|<----------- authenticated ---------->|
------------------------------------------------------------
IPv6 | new* |new ext | | orig*|orig ext | | | ESP | ESP|
|IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer|Auth|
------------------------------------------------------------
|<--------- encrypted ----------->|
|<---------- authenticated ---------->|
* = if present, construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed below.
* =存在する場合、外部IP hdr /拡張の構築と内部IP hdr /拡張の変更について以下で説明します。
The mandatory-to-implement algorithms are described in Section 5, "Conformance Requirements". Other algorithms MAY be supported. Note that although both confidentiality and authentication are optional, at least one of these services MUST be selected hence both algorithms MUST NOT be simultaneously NULL.
実装に必須のアルゴリズムについては、5項「適合要件」で説明しています。他のアルゴリズムはサポートされるかもしれません。機密性と認証はどちらもオプションですが、これらのサービスの少なくとも1つを選択する必要があるため、両方のアルゴリズムを同時にNULLにすることはできません。
The encryption algorithm employed is specified by the SA. ESP is designed for use with symmetric encryption algorithms. Because IP packets may arrive out of order, each packet must carry any data required to allow the receiver to establish cryptographic synchronization for decryption. This data may be carried explicitly in the payload field, e.g., as an IV (as described above), or the data may be derived from the packet header. Since ESP makes provision for padding of the plaintext, encryption algorithms employed with ESP may exhibit either block or stream mode characteristics. Note that since encryption (confidentiality) is optional, this algorithm may be "NULL".
使用される暗号化アルゴリズムは、SAによって指定されます。 ESPは、対称暗号化アルゴリズムで使用するように設計されています。 IPパケットは順不同で到着する可能性があるため、各パケットは、受信者が復号化のための暗号同期を確立できるようにするために必要なデータを運ぶ必要があります。このデータは、ペイロードフィールドで明示的に、たとえばIVとして（上記のように）運ばれるか、またはデータがパケットヘッダーから取得されます。 ESPはプレーンテキストのパディングを提供するため、ESPで使用される暗号化アルゴリズムは、ブロックモードまたはストリームモードのいずれかの特性を示す場合があります。暗号化（機密性）はオプションであるため、このアルゴリズムは「NULL」の場合があることに注意してください。
The authentication algorithm employed for the ICV computation is specified by the SA. For point-to-point communication, suitable authentication algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., DES) or on one-way hash functions (e.g., MD5 or SHA-1). For multicast communication, one-way hash algorithms combined with asymmetric signature algorithms are appropriate, though performance and space considerations currently preclude use of such algorithms. Note that since authentication is optional, this algorithm may be "NULL".
ICV計算に使用される認証アルゴリズムは、SAによって指定されます。ポイントツーポイント通信の場合、適切な認証アルゴリズムには、対称暗号化アルゴリズム（DESなど）または一方向ハッシュ関数（MD5またはSHA-1など）に基づくキー付きメッセージ認証コード（MAC）が含まれます。マルチキャスト通信では、非対称署名アルゴリズムと組み合わせた一方向ハッシュアルゴリズムが適切ですが、現在、パフォーマンスとスペースの考慮により、そのようなアルゴリズムは使用できません。認証はオプションであるため、このアルゴリズムは「NULL」の場合があることに注意してください。
In transport mode, the sender encapsulates the upper layer protocol information in the ESP header/trailer, and retains the specified IP header (and any IP extension headers in the IPv6 context). In tunnel mode, the outer and inner IP header/extensions can be inter-related in a variety of ways. The construction of the outer IP header/extensions during the encapsulation process is described in the Security Architecture document. If there is more than one IPsec header/extension required by security policy, the order of the application of the security headers MUST be defined by security policy.
トランスポートモードでは、送信者は上位層プロトコル情報をESPヘッダー/トレーラーにカプセル化し、指定されたIPヘッダー（およびIPv6コンテキストのIP拡張ヘッダー）を保持します。トンネルモードでは、外部IPヘッダーと内部IPヘッダー/拡張をさまざまな方法で相互に関連付けることができます。カプセル化プロセス中の外部IPヘッダー/拡張の構築については、セキュリティアーキテクチャのドキュメントで説明されています。セキュリティポリシーで必要なIPsecヘッダー/拡張機能が複数ある場合は、セキュリティヘッダーの適用順序をセキュリティポリシーで定義する必要があります。
ESP is applied to an outbound packet only after an IPsec implementation determines that the packet is associated with an SA that calls for ESP processing. The process of determining what, if any, IPsec processing is applied to outbound traffic is described in the Security Architecture document.
ESPは、IPsec実装がパケットがESP処理を要求するSAに関連付けられていると判断した後にのみ、送信パケットに適用されます。発信トラフィックに適用されるIPsec処理がある場合は、それを決定するプロセスについては、セキュリティアーキテクチャのドキュメントで説明されています。
In this section, we speak in terms of encryption always being applied because of the formatting implications. This is done with the understanding that "no confidentiality" is offered by using the NULL encryption algorithm. Accordingly, the sender:
このセクションでは、フォーマットの影響により常に適用される暗号化について説明します。これは、NULL暗号化アルゴリズムを使用して「機密性なし」が提供されることを理解して行われます。したがって、送信者は：
1. encapsulates (into the ESP Payload field): - for transport mode -- just the original upper layer protocol information. - for tunnel mode -- the entire original IP datagram. 2. adds any necessary padding. 3. encrypts the result (Payload Data, Padding, Pad Length, and Next Header) using the key, encryption algorithm, algorithm mode indicated by the SA and cryptographic synchronization data (if any). - If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is input to the encryption algorithm per the algorithm specification and placed in the Payload field. - If implicit cryptographic synchronication data, e.g., an IV, is indicated, it is constructed and input to the encryption algorithm as per the algorithm specification.
1. カプセル化（ESPペイロードフィールドに）：-トランスポートモードの場合-元の上位層プロトコル情報のみ。 -トンネルモードの場合-元のIPデータグラム全体。 2.必要なパディングを追加します。 3.キー、暗号化アルゴリズム、SAが示すアルゴリズムモード、および暗号化同期データ（存在する場合）を使用して、結果（ペイロードデータ、パディング、パッド長、および次のヘッダー）を暗号化します。 -IVなどの明示的な暗号化同期データが示されている場合、アルゴリズム仕様に従って暗号化アルゴリズムに入力され、ペイロードフィールドに配置されます。 -暗黙の暗号同期データ（IVなど）が示されている場合は、アルゴリズム仕様に従ってデータが作成され、暗号化アルゴリズムに入力されます。
The exact steps for constructing the outer IP header depend on the mode (transport or tunnel) and are described in the Security Architecture document.
外部IPヘッダーを構築するための正確な手順は、モード（トランスポートまたはトンネル）によって異なり、セキュリティアーキテクチャのドキュメントで説明されています。
If authentication is selected, encryption is performed first, before the authentication, and the encryption does not encompass the Authentication Data field. This order of processing facilitates rapid detection and rejection of replayed or bogus packets by the receiver, prior to decrypting the packet, hence potentially reducing the impact of denial of service attacks. It also allows for the possibility of parallel processing of packets at the receiver, i.e., decryption can take place in parallel with authentication. Note that since the Authentication Data is not protected by encryption, a keyed authentication algorithm must be employed to compute the ICV.
認証が選択されている場合、暗号化は認証の前に最初に実行され、暗号化は[認証データ]フィールドを含みません。この処理順序により、パケットを復号化する前に、受信者による再生されたパケットや偽のパケットの迅速な検出と拒否が容易になり、サービス拒否攻撃の影響が軽減される可能性があります。また、受信側でのパケットの並列処理の可能性を可能にします。つまり、認証と並行して復号化を行うことができます。認証データは暗号化によって保護されていないため、ICVの計算には鍵付き認証アルゴリズムを使用する必要があることに注意してください。
The sender's counter is initialized to 0 when an SA is established. The sender increments the Sequence Number for this SA and inserts the new value into the Sequence Number field. Thus the first packet sent using a given SA will have a Sequence Number of 1.
SAが確立されると、送信者のカウンターは0に初期化されます。送信者は、このSAのシーケンス番号を増分し、新しい値を[シーケンス番号]フィールドに挿入します。したがって、特定のSAを使用して送信される最初のパケットのシーケンス番号は1になります。
If anti-replay is enabled (the default), the sender checks to ensure that the counter has not cycled before inserting the new value in the Sequence Number field. In other words, the sender MUST NOT send a packet on an SA if doing so would cause the Sequence Number to cycle. An attempt to transmit a packet that would result in Sequence Number overflow is an auditable event. (Note that this approach to Sequence Number management does not require use of modular arithmetic.)
アンチリプレイが有効な場合（デフォルト）、送信者は、[シーケンス番号]フィールドに新しい値を挿入する前に、カウンターが循環していないことを確認します。言い換えると、送信者がシーケンス番号を循環させる場合は、SAでパケットを送信してはならない（MUST NOT）。シーケンス番号のオーバーフローを引き起こすパケットを送信する試みは、監査可能なイベントです。 （シーケンス番号管理へのこのアプローチでは、モジュラー演算を使用する必要がないことに注意してください。）
The sender assumes anti-replay is enabled as a default, unless otherwise notified by the receiver (see 3.4.3). Thus, if the counter has cycled, the sender will set up a new SA and key (unless the SA was configured with manual key management).
送信者は、受信者からの通知がない限り、アンチリプレイがデフォルトで有効になっていると想定します（3.4.3を参照）。したがって、カウンターが循環している場合、送信者は新しいSAとキーをセットアップします（SAが手動のキー管理で構成されていない場合）。
If anti-replay is disabled, the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5). However, the sender still increments the counter and when it reaches the maximum value, the counter rolls over back to zero.
アンチリプレイが無効になっている場合、送信者はカウンターを監視またはリセットする必要はありません。たとえば、手動のキー管理の場合（セクション5を参照）。ただし、送信者は引き続きカウンタをインクリメントし、最大値に達すると、カウンタはロールオーバーしてゼロに戻ります。
If authentication is selected for the SA, the sender computes the ICV over the ESP packet minus the Authentication Data. Thus the SPI, Sequence Number, Payload Data, Padding (if present), Pad Length, and Next Header are all encompassed by the ICV computation. Note that the last 4 fields will be in ciphertext form, since encryption is performed prior to authentication.
SAに対して認証が選択されている場合、送信者はESPパケットから認証データを差し引いたICVを計算します。したがって、SPI、シーケンス番号、ペイロードデータ、パディング（存在する場合）、パッド長、および次のヘッダーはすべてICV計算に含まれます。暗号化は認証の前に実行されるため、最後の4つのフィールドは暗号文形式になることに注意してください。
For some authentication algorithms, the byte string over which the ICV computation is performed must be a multiple of a blocksize specified by the algorithm. If the length of this byte string does not match the blocksize requirements for the algorithm, implicit padding MUST be appended to the end of the ESP packet, (after the Next Header field) prior to ICV computation. The padding octets MUST have a value of zero. The blocksize (and hence the length of the padding) is specified by the algorithm specification. This padding is not transmitted with the packet. Note that MD5 and SHA-1 are viewed as having a 1-byte blocksize because of their internal padding conventions.
一部の認証アルゴリズムでは、ICV計算が実行されるバイト文字列は、アルゴリズムで指定されたブロックサイズの倍数でなければなりません。このバイト文字列の長さがアルゴリズムのブロックサイズ要件と一致しない場合は、ICV計算の前に、ESPパケットの末尾（次のヘッダーフィールドの後）に暗黙のパディングを追加する必要があります。パディングオクテットはゼロの値を持っている必要があります。ブロックサイズ（およびパディングの長さ）は、アルゴリズムの仕様で指定されています。このパディングはパケットとともに送信されません。 MD5とSHA-1は、内部の埋め込み規則により、1バイトのブロックサイズを持っていると見なされることに注意してください。
If necessary, fragmentation is performed after ESP processing within an IPsec implementation. Thus, transport mode ESP is applied only to whole IP datagrams (not to IP fragments). An IP packet to which ESP has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to ESP processing at a receiver. In tunnel mode, ESP is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation (as defined in the Security Architecture document) may apply tunnel mode ESP to such fragments.
必要に応じて、IPsec実装内のESP処理の後にフラグメンテーションが実行されます。したがって、トランスポートモードESPは、IPデータグラム全体にのみ適用されます（IPフラグメントには適用されません）。 ESPが適用されたIPパケットは、途中でルーターによってフラグメント化される可能性があり、そのようなフラグメントは、受信側でのESP処理の前に再構成する必要があります。トンネルモードでは、ESPはIPパケットに適用され、そのペイロードはフラグメント化されたIPパケットである場合があります。たとえば、セキュリティゲートウェイ、または「bump-in-the-stack」または「bump-in-the-wire」IPsec実装（セキュリティアーキテクチャドキュメントで定義）は、そのようなフラグメントにトンネルモードESPを適用できます。
NOTE: For transport mode -- As mentioned at the beginning of Section 3.1, bump-in-the-stack and bump-in-the-wire implementations may have to first reassemble a packet fragmented by the local IP layer, then apply IPsec, and then fragment the resulting packet.
注：トランスポートモードの場合-セクション3.1の冒頭で述べたように、bump-in-the-stack実装とbump-in-the-wire実装では、最初にローカルIPレイヤーでフラグメント化されたパケットを再構成し、次にIPsecを適用する必要があります。そして、結果のパケットをフラグメント化します。
NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire implementations, it will be necessary to walk through all the extension headers to determine if there is a fragmentation header and hence that the packet needs reassembling prior to IPsec processing.
注：IPv6の場合-バンプインザスタックおよびバンプインザワイヤー実装の場合、すべての拡張ヘッダーを調べて、フラグメンテーションヘッダーがあるかどうかを判断し、パケットを再組み立てする必要があるかどうかを判断する必要があります。 IPsec処理の前。
If required, reassembly is performed prior to ESP processing. If a packet offered to ESP for processing appears to be an IP fragment, i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, Sequence Number, and (in IPv6) the Flow ID.
必要に応じて、ESP処理の前に再アセンブリが実行されます。処理のためにESPに提供されたパケットがIPフラグメントであるように見える場合、つまり、OFFSETフィールドがゼロ以外であるか、MORE FRAGMENTSフラグが設定されている場合、受信者はパケットを破棄する必要があります。これは監査可能なイベントです。このイベントの監査ログエントリには、SPI値、受信日時、送信元アドレス、宛先アドレス、シーケンス番号、およびフローID（IPv6の場合）を含める必要があります（SHOULD）。
NOTE: For packet reassembly, the current IPv4 spec does NOT require either the zero'ing of the OFFSET field or the clearing of the MORE FRAGMENTS flag. In order for a reassembled packet to be processed by IPsec (as opposed to discarded as an apparent fragment), the IP code must do these two things after it reassembles a packet.
注：パケットの再構成の場合、現在のIPv4仕様では、OFFSETフィールドをゼロにすることも、MORE FRAGMENTSフラグをクリアすることも必要ありません。再構成されたパケットがIPsecによって処理されるように（見かけ上のフラグメントとして破棄されるのではなく）、IPコードはパケットを再構成した後にこれら2つのことを行う必要があります。
Upon receipt of a (reassembled) packet containing an ESP Header, the receiver determines the appropriate (unidirectional) SA, based on the destination IP address, security protocol (ESP), and the SPI. (This process is described in more detail in the Security Architecture document.) The SA indicates whether the Sequence Number field will be checked, whether the Authentication Data field should be present, and it will specify the algorithms and keys to be employed for decryption and ICV computations (if applicable).
ESPヘッダーを含む（再構成された）パケットを受信すると、受信者は、宛先IPアドレス、セキュリティプロトコル（ESP）、およびSPIに基づいて適切な（単方向）SAを決定します。 （このプロセスは、セキュリティアーキテクチャドキュメントで詳細に説明されています。）SAは、シーケンス番号フィールドがチェックされるかどうか、認証データフィールドが存在する必要があるかどうか、および復号化に使用されるアルゴリズムとキーを指定します。 ICV計算（該当する場合）。
If no valid Security Association exists for this session (for example, the receiver has no key), the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, Sequence Number, and (in IPv6) the cleartext Flow ID.
このセッションに有効なセキュリティアソシエーションが存在しない場合（たとえば、レシーバーにキーがない場合）、レシーバーはパケットを破棄する必要があります。これは監査可能なイベントです。このイベントの監査ログエントリには、SPI値、受信日時、送信元アドレス、宛先アドレス、シーケンス番号、および（IPv6の場合）クリアテキストフローIDを含める必要があります（SHOULD）。
All ESP implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. This service MUST NOT be enabled unless the authentication service also is enabled for the SA, since otherwise the Sequence Number field has not been integrity protected. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single SA (irrespective of whether the destination address is unicast, broadcast, or multicast). Thus the anti-replay service SHOULD NOT be used in a multi-sender environment that employs a single SA.)
すべてのESP実装は、アンチリプレイサービスをサポートする必要がありますが、SAごとにレシーバーによって使用が有効または無効にされる場合があります。認証サービスもSAに対して有効になっていない限り、このサービスを有効にしてはなりません。それ以外の場合、シーケンス番号フィールドは整合性が保護されていないためです。 （送信先アドレスがユニキャスト、ブロードキャスト、マルチキャストのいずれであるかに関係なく、単一のSAにトラフィックを送信する複数の送信者間で送信されたシーケンス番号値を管理するための規定がないことに注意してください。したがって、アンチリプレイサービスは、単一のSAを使用するマルチセンダー環境。）
If the receiver does not enable anti-replay for an SA, no inbound checks are performed on the Sequence Number. However, from the perspective of the sender, the default is to assume that anti-replay is enabled at the receiver. To avoid having the sender do unnecessary sequence number monitoring and SA setup (see section 3.3.3), if an SA establishment protocol such as IKE is employed, the receiver SHOULD notify the sender, during SA establishment, if the receiver will not provide anti-replay protection.
レシーバーがSAのアンチリプレイを有効にしない場合、シーケンス番号に対してインバウンドチェックは実行されません。ただし、送信側から見ると、デフォルトでは、受信側でアンチリプレイが有効になっていると想定しています。送信者が不必要なシーケンス番号の監視とSAのセットアップ（セクション3.3.3を参照）を行わないようにするために、IKEなどのSA確立プロトコルが採用されている場合、受信者は、SAの確立中に受信者がアンチを提供しない場合、送信者に通知する必要があります（SHOULD）。 -リプレイ保護。
If the receiver has enabled the anti-replay service for this SA, the receive packet counter for the SA MUST be initialized to zero when the SA is established. For each received packet, the receiver MUST verify that the packet contains a Sequence Number that does not duplicate the Sequence Number of any other packets received during the life of this SA. This SHOULD be the first ESP check applied to a packet after it has been matched to an SA, to speed rejection of duplicate packets.
レシーバーがこのSAのアンチリプレイサービスを有効にしている場合、SAが確立されたときに、SAの受信パケットカウンターをゼロに初期化する必要があります。受信したパケットごとに、受信者は、パケットに、このSAの有効期間中に受信した他のパケットのシーケンス番号と重複しないシーケンス番号が含まれていることを確認する必要があります。これは、パケットがSAに一致した後にパケットに適用される最初のESPチェックであり、重複パケットの拒否を高速化する必要があります。
Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following text describes the functionality that the implementation must exhibit.) A MINIMUM window size of 32 MUST be supported; but a window size of 64 is preferred and SHOULD be employed as the default.
スライディング受信ウィンドウを使用すると、重複が拒否されます。 （ウィンドウの実装方法はローカルな問題ですが、次のテキストは実装が示す必要のある機能を説明しています。）32の最小ウィンドウサイズをサポートする必要があります。ただし、64のウィンドウサイズが推奨され、デフォルトとして使用する必要があります（SHOULD）。
Another window size (larger than the MINIMUM) MAY be chosen by the receiver. (The receiver does NOT notify the sender of the window size.)
別のウィンドウサイズ（MINIMUMより大きい）は、受信者が選択できます。 （受信者は送信者にウィンドウサイズを通知しません。）
The "right" edge of the window represents the highest, validated Sequence Number value received on this SA. Packets that contain Sequence Numbers lower than the "left" edge of the window are rejected. Packets falling within the window are checked against a list of received packets within the window. An efficient means for performing this check, based on the use of a bit mask, is described in the Security Architecture document.
ウィンドウの「右」の端は、このSAで受信した検証済みの最高のシーケンス番号値を表します。ウィンドウの「左」端よりも小さいシーケンス番号を含むパケットは拒否されます。ウィンドウ内にあるパケットは、ウィンドウ内で受信したパケットのリストと照合されます。ビットマスクの使用に基づいてこのチェックを実行する効率的な方法は、セキュリティアーキテクチャのドキュメントに記載されています。
If the received packet falls within the window and is new, or if the packet is to the right of the window, then the receiver proceeds to ICV verification. If the ICV validation fails, the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, the Sequence Number, and (in IPv6) the Flow ID. The receive window is updated only if the ICV verification succeeds.
受信したパケットがウィンドウ内にあり、新しい場合、またはパケットがウィンドウの右側にある場合、受信者はICV検証に進みます。 ICV検証が失敗した場合、受信者は受信したIPデータグラムを無効として破棄しなければなりません（MUST）。これは監査可能なイベントです。このイベントの監査ログエントリには、SPI値、受信日時、送信元アドレス、宛先アドレス、シーケンス番号、およびフローID（IPv6の場合）を含める必要があります（SHOULD）。受信ウィンドウは、ICV検証が成功した場合にのみ更新されます。
DISCUSSION:
討論：
Note that if the packet is either inside the window and new, or is outside the window on the "right" side, the receiver MUST authenticate the packet before updating the Sequence Number window data.
パケットがウィンドウ内で新しい場合、または「右側」のウィンドウ外にある場合、受信者はシーケンス番号ウィンドウデータを更新する前にパケットを認証する必要があることに注意してください。
If authentication has been selected, the receiver computes the ICV over the ESP packet minus the Authentication Data using the specified authentication algorithm and verifies that it is the same as the ICV included in the Authentication Data field of the packet. Details of the computation are provided below.
認証が選択されている場合、受信者は指定された認証アルゴリズムを使用してESPパケットから認証データを差し引いたICVを計算し、それがパケットの認証データフィールドに含まれているICVと同じであることを確認します。計算の詳細を以下に示します。
If the computed and received ICV's match, then the datagram is valid, and it is accepted. If the test fails, then the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The log data SHOULD include the SPI value, date/time received, Source Address, Destination Address, the Sequence Number, and (in IPv6) the cleartext Flow ID.
計算および受信したICVが一致した場合、データグラムは有効であり、受け入れられます。テストが失敗した場合、受信者は受信したIPデータグラムを無効として破棄する必要があります。これは監査可能なイベントです。ログデータには、SPI値、受信した日付/時刻、送信元アドレス、宛先アドレス、シーケンス番号、および（IPv6の場合）クリアテキストフローIDを含める必要があります（SHOULD）。
DISCUSSION:
討論：
Begin by removing and saving the ICV value (Authentication Data field). Next check the overall length of the ESP packet minus the Authentication Data. If implicit padding is required, based on the blocksize of the authentication algorithm, append zero-filled bytes to the end of the ESP packet directly after the Next Header field. Perform the ICV computation and compare the result with the saved value, using the comparison rules defined by the algorithm specification. (For example, if a digital signature and one-way hash are used for the ICV computation, the matching process is more complex.)
まず、ICV値（認証データフィールド）を削除して保存します。次に、ESPパケットの全長から認証データを差し引いた長さを確認します。認証アルゴリズムのブロックサイズに基づいて暗黙的なパディングが必要な場合は、ESPパケットの最後の「次のヘッダー」フィールドの直後にゼロで埋められたバイトを追加します。 ICV計算を実行し、アルゴリズム仕様で定義された比較ルールを使用して、結果を保存された値と比較します。 （たとえば、デジタル署名と一方向ハッシュがICV計算に使用される場合、照合プロセスはより複雑になります。）
As in section 3.3.2, "Packet Encryption", we speak here in terms of encryption always being applied because of the formatting implications. This is done with the understanding that "no confidentiality" is offered by using the NULL encryption algorithm. Accordingly, the receiver:
セクション3.3.2「パケットの暗号化」と同様に、ここでは、フォーマットの影響により常に適用される暗号化について説明します。これは、NULL暗号化アルゴリズムを使用して「機密性なし」が提供されることを理解して行われます。したがって、レシーバー：
1. decrypts the ESP Payload Data, Padding, Pad Length, and Next Header using the key, encryption algorithm, algorithm mode, and cryptographic synchronization data (if any), indicated by the SA. - If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is taken from the Payload field and input to the decryption algorithm as per the algorithm specification. - If implicit cryptographic synchronization data, e.g., an IV, is indicated, a local version of the IV is constructed and input to the decryption algorithm as per the algorithm specification. 2. processes any padding as specified in the encryption algorithm specification. If the default padding scheme (see Section 2.4) has been employed, the receiver SHOULD inspect the Padding field before removing the padding prior to passing the decrypted data to the next layer. 3. reconstructs the original IP datagram from: - for transport mode -- original IP header plus the original upper layer protocol information in the ESP Payload field - for tunnel mode -- tunnel IP header + the entire IP datagram in the ESP Payload field.
1. SAによって示されるキー、暗号化アルゴリズム、アルゴリズムモード、および暗号化同期データ（存在する場合）を使用して、ESPペイロードデータ、パディング、パッド長、および次のヘッダーを復号化します。 -明示的な暗号化同期データ（IVなど）が示されている場合は、ペイロードフィールドから取得され、アルゴリズム仕様に従って復号化アルゴリズムに入力されます。 -暗黙の暗号同期データ（IVなど）が示されている場合、IVのローカルバージョンが作成され、アルゴリズム仕様に従って復号化アルゴリズムに入力されます。 2.暗号化アルゴリズム仕様で指定されているパディングを処理します。デフォルトのパディング方式（セクション2.4を参照）が採用されている場合、受信者は、次の層に復号化されたデータを渡す前にパディングを削除する前にパディングフィールドを検査する必要があります（SHOULD）。 3.元のIPデータグラムを以下から再構築します。-トランスポートモードの場合-ESPペイロードフィールドの元のIPヘッダーと上位層プロトコル情報-トンネルモードの場合-トンネルIPヘッダー+ ESPペイロードフィールドのIPデータグラム全体。
The exact steps for reconstructing the original datagram depend on the mode (transport or tunnel) and are described in the Security Architecture document. At a minimum, in an IPv6 context, the receiver SHOULD ensure that the decrypted data is 8-byte aligned, to facilitate processing by the protocol identified in the Next Header field.
元のデータグラムを再構築するための正確な手順は、モード（トランスポートまたはトンネル）によって異なり、セキュリティアーキテクチャのドキュメントで説明されています。少なくとも、IPv6のコンテキストでは、受信者は、次のヘッダーフィールドで識別されるプロトコルによる処理を容易にするために、復号化されたデータが8バイトに整列されていることを保証する必要があります。
If authentication has been selected, verification and decryption MAY be performed serially or in parallel. If performed serially, then ICV verification SHOULD be performed first. If performed in parallel, verification MUST be completed before the decrypted packet is passed on for further processing. This order of processing facilitates rapid detection and rejection of replayed or bogus packets by the receiver, prior to decrypting the packet, hence potentially reducing the impact of denial of service attacks. Note:
認証が選択されている場合、検証と復号化はシリアルまたはパラレルで実行される場合があります。連続して実行する場合、ICV検証を最初に実行する必要があります。並行して実行する場合は、復号化されたパケットがさらに処理される前に検証を完了する必要があります。この処理順序により、パケットを復号化する前に、受信者による再生されたパケットや偽のパケットの迅速な検出と拒否が容易になり、サービス拒否攻撃の影響が軽減される可能性があります。注意：
If the receiver performs decryption in parallel with authentication, care must be taken to avoid possible race conditions with regard to packet access and reconstruction of the decrypted packet.
受信側が認証と並行して復号化を実行する場合は、パケットアクセスと復号化されたパケットの再構築に関して起こり得る競合状態を回避するように注意する必要があります。
Note that there are several ways in which the decryption can "fail":
復号化が「失敗」する可能性があるいくつかの方法があることに注意してください。
a. The selected SA may not be correct -- The SA may be mis-selected due to tampering with the SPI, destination address, or IPsec protocol type fields. Such errors, if they map the packet to another extant SA, will be indistinguishable from a corrupted packet, (case c). Tampering with the SPI can be detected by use of authentication. However, an SA mismatch might still occur due to tampering with the IP Destination Address or the IPsec protocol type field.
a. 選択したSAが正しくない可能性があります-SPI、宛先アドレス、またはIPsecプロトコルタイプのフィールドが改ざんされているため、SAが誤って選択されている可能性があります。このようなエラーは、パケットを別の現存するSAにマップする場合、破損したパケットと区別できません（ケースc）。 SPIの改ざんは、認証を使用して検出できます。ただし、IP宛先アドレスまたはIPsecプロトコルタイプフィールドの改ざんが原因で、SAの不一致が引き続き発生する可能性があります。
b. The pad length or pad values could be erroneous -- Bad pad lengths or pad values can be detected irrespective of the use of authentication.
b. パッド長またはパッド値が誤っている可能性があります-認証の使用に関係なく、不良パッド長またはパッド値が検出される可能性があります。
c. The encrypted ESP packet could be corrupted -- This can be detected if authentication is selected for the SA.,
c. 暗号化されたESPパケットが破損している可能性があります-これは、SAに対して認証が選択されている場合に検出できます。
In case (a) or (c), the erroneous result of the decryption operation (an invalid IP datagram or transport-layer frame) will not necessarily be detected by IPsec, and is the responsibility of later protocol processing.
（a）または（c）の場合、復号化操作の誤った結果（無効なIPデータグラムまたはトランスポート層フレーム）は必ずしもIPsecによって検出されるとは限らず、後のプロトコル処理の責任です。
Not all systems that implement ESP will implement auditing. However, if ESP is incorporated into a system that supports auditing, then the ESP implementation MUST also support auditing and MUST allow a system administrator to enable or disable auditing for ESP. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this specification and for each of these events a minimum set of information that SHOULD be included in an audit log is defined. Additional information also MAY be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also MAY result in audit log entries. There is no requirement for the receiver to transmit any message to the purported sender in response to the detection of an auditable event, because of the potential to induce denial of service via such action.
ESPを実装するすべてのシステムが監査を実装するわけではありません。ただし、監査をサポートするシステムにESPが組み込まれている場合、ESP実装は監査もサポートする必要があり、システム管理者がESPの監査を有効または無効にできるようにする必要があります。ほとんどの場合、監査の粒度はローカルな問題です。ただし、この仕様ではいくつかの監査可能なイベントが識別されており、これらの各イベントについて、監査ログに含める必要がある最低限の情報のセットが定義されています。これらの各イベントの追加情報も監査ログに含めることができます。また、この仕様で明示的に呼び出されていない追加のイベントも、監査ログエントリになる場合があります。監査可能なイベントの検出に応答して、意図された送信者にメッセージを送信する必要はありません。これは、そのようなアクションによってサービス拒否を引き起こす可能性があるためです。
Implementations that claim conformance or compliance with this specification MUST implement the ESP syntax and processing described here and MUST comply with all requirements of the Security Architecture document. If the key used to compute an ICV is manually distributed, correct provision of the anti-replay service would require correct maintenance of the counter state at the sender, until the key is replaced, and there likely would be no automated recovery provision if counter overflow were imminent. Thus a compliant implementation SHOULD NOT provide this service in conjunction with SAs that are manually keyed. A compliant ESP implementation MUST support the following mandatory-to-implement algorithms:
この仕様への準拠または準拠を主張する実装は、ここで説明するESP構文と処理を実装しなければならず、セキュリティアーキテクチャドキュメントのすべての要件に準拠しなければなりません。 ICVの計算に使用されるキーが手動で配布される場合、アンチリプレイサービスを正しく提供するには、キーが交換されるまで、送信者でカウンターの状態を正しく維持する必要があり、カウンターがオーバーフローした場合、自動復旧プロビジョニングはおそらくありません。差し迫っていた。したがって、準拠した実装では、手動でキーを設定したSAと組み合わせてこのサービスを提供してはなりません（SHOULD NOT）。準拠ESP実装は、次の実装必須アルゴリズムをサポートする必要があります。
- DES in CBC mode [MD97] - HMAC with MD5 [MG97a] - HMAC with SHA-1 [MG97b] - NULL Authentication algorithm - NULL Encryption algorithm
- CBCモードのDES [MD97]-MD5を使用したHMAC [MG97a]-SHA-1を使用したHMAC [MG97b]-NULL認証アルゴリズム-NULL暗号化アルゴリズム
Since ESP encryption and authentication are optional, support for the 2 "NULL" algorithms is required to maintain consistency with the way these services are negotiated. NOTE that while authentication and encryption can each be "NULL", they MUST NOT both be "NULL".
ESPの暗号化と認証はオプションであるため、これらのサービスのネゴシエーション方法との一貫性を維持するには、2つの「NULL」アルゴリズムのサポートが必要です。認証と暗号化はそれぞれ「NULL」にすることができますが、両方を「NULL」にすることはできません。
Security is central to the design of this protocol, and thus security considerations permeate the specification. Additional security-relevant aspects of using the IPsec protocol are discussed in the Security Architecture document.
セキュリティはこのプロトコルの設計の中心であり、したがってセキュリティの考慮事項が仕様に浸透しています。 IPsecプロトコルの使用に関するその他のセキュリティ関連の側面については、セキュリティアーキテクチャのドキュメントで説明されています。
This document differs from RFC 1827 [ATK95] in several significant ways. The major difference is that, this document attempts to specify a complete framework and context for ESP, whereas RFC 1827 provided a "shell" that was completed through the definition of transforms. The combinatorial growth of transforms motivated the reformulation of the ESP specification as a more complete document, with options for security services that may be offered in the context of ESP. Thus, fields previously defined in transform documents are now part of this base ESP specification. For example, the fields necessary to support authentication (and anti-replay) are now defined here, even though the provision of this service is an option. The fields used to support padding for encryption, and for next protocol identification, are now defined here as well. Packet processing consistent with the definition of these fields also is included in the document.
このドキュメントはいくつかの重要な点でRFC 1827 [ATK95]と異なります。主な違いは、このドキュメントではESPの完全なフレームワークとコンテキストを指定しようとしているのに対し、RFC 1827では変換の定義を通じて完成した「シェル」を提供していることです。トランスフォームの組み合わせの増加は、ESPのコンテキストで提供される可能性のあるセキュリティサービスのオプションを備えた、より完全なドキュメントとしてのESP仕様の再編成を動機付けました。したがって、以前に変換ドキュメントで定義されたフィールドは、現在、この基本ESP仕様の一部です。たとえば、認証（およびリプレイ防止）をサポートするために必要なフィールドがここで定義されていますが、このサービスの提供はオプションです。暗号化および次のプロトコル識別のためのパディングをサポートするために使用されるフィールドは、ここでも定義されています。これらのフィールドの定義と一致するパケット処理もドキュメントに含まれています。
Acknowledgements
謝辞
Many of the concepts embodied in this specification were derived from or influenced by the US Government's SP3 security protocol, ISO/IEC's NLSP, or from the proposed swIPe security protocol. [SDNS89, ISO92, IB93].
この仕様で具体化されている概念の多くは、米国政府のSP3セキュリティプロトコル、ISO / IECのNLSP、または提案されたswIPeセキュリティプロトコルから派生または影響を受けています。 [SDNS89、ISO92、IB93]。
For over 3 years, this document has evolved through multiple versions and iterations. During this time, many people have contributed significant ideas and energy to the process and the documents themselves. The authors would like to thank Karen Seo for providing extensive help in the review, editing, background research, and coordination for this version of the specification. The authors would also like to thank the members of the IPsec and IPng working groups, with special mention of the efforts of (in alphabetic order): Steve Bellovin, Steve Deering, Phil Karn, Perry Metzger, David Mihelcic, Hilarie Orman, Norman Shulman, William Simpson and Nina Yuan.
3年以上にわたり、このドキュメントは複数のバージョンとイテレーションを経て進化してきました。この間、多くの人々が重要なアイデアとエネルギーをプロセスとドキュメント自体に提供してきました。著者は、このバージョンの仕様のレビュー、編集、バックグラウンド調査、および調整に広範な支援を提供してくれたKaren Seoに感謝します。著者はまた、IPsecおよびIPngワーキンググループのメンバーに感謝の意を表します（特にアルファベット順）：Steve Bellovin、Steve Deering、Phil Karn、Perry Metzger、David Mihelcic、Hilarie Orman、Norman Shulman 、ウィリアム・シンプソン、ニーナ・ユアン。
References
参考文献
[ATK95] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, August 1995.
[ATK95] Atkinson、R。、「IP Encapsulating Security Payload（ESP）」、RFC 1827、1995年8月。
[Bel96] Steven M. Bellovin, "Problem Areas for the IP Security Protocols", Proceedings of the Sixth Usenix Unix Security Symposium, July, 1996.
[Bel96] Steven M. Bellovin、「IPセキュリティプロトコルの問題領域」、第6回Usenix Unixセキュリティシンポジウムの議事録、1996年7月。
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[Bra97] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[HC98] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[HC98] Harkins、D。、およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[IB93] John Ioannidis & Matt Blaze, "Architecture and Implementation of Network-layer Security Under Unix", Proceedings of the USENIX Security Symposium, Santa Clara, CA, October 1993.
[IB93] John IoannidisとMatt Blaze、「Unixでのネットワーク層セキュリティのアーキテクチャと実装」、USENIXセキュリティシンポジウムの議事録、カリフォルニア州サンタクララ、1993年10月。
[ISO92] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992.
[ISO92] ISO / IEC JTC1 / SC6、ネットワーク層セキュリティプロトコル、ISO-IEC DIS 11577、国際標準化機構、スイス、ジュネーブ、1992年11月29日。
[KA97a] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[KA97a]ケント、S。、およびR.アトキンソン、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[KA97b] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[KA97b]ケント、S。、およびR.アトキンソン、「IP認証ヘッダー」、RFC 2402、1998年11月。
[MD97] Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
[MD97] Madson、C。、およびN. Doraswamy、「明示的なIVを使用したESP DES-CBC暗号アルゴリズム」、RFC 2405、1998年11月。
[MG97a] Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
[MG97a] Madson、C。、およびR. Glenn、「The Use of HMAC-MD5-96 within ESP and AH」、RFC 2403、1998年11月。
[MG97b] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[MG97b] Madson、C。、およびR. Glenn、「The Use of HMAC-SHA-1-96 within ESP and AH」、RFC 2404、1998年11月。
[STD-2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994. See also:
http://www.iana.org/numbers.html
[SDNS89] SDNS Secure Data Network System, Security Protocol 3, SP3, Document SDN.301, Revision 1.5, 15 May 1989, as published in NIST Publication NIST-IR-90-4250, February 1990.
[SDNS89] SDNSセキュアデータネットワークシステム、セキュリティプロトコル3、SP3、ドキュメントSDN.301、リビジョン1.5、15、1989年5月、NIST Publication NIST-IR-90-4250、1990年2月に発行。
Disclaimer
免責事項
The views and specification here are those of the authors and are not necessarily those of their employers. The authors and their employers specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification.
ここでの見解と仕様は著者の見解であり、必ずしもそれらの雇用者の見解ではありません。著者とその雇用者は、この仕様の正しいまたは正しくない実装または使用から生じる問題に対する責任を明確に放棄します。
Author Information
著者情報
Stephen Kent BBN Corporation 70 Fawcett Street Cambridge, MA 02140 USA
Stephen Kent BBN Corporation 70 Fawcett Street Cambridge、MA 02140 USA
Phone: +1 (617) 873-3988
EMail: kent@bbn.com
Randall Atkinson @Home Network 425 Broadway, Redwood City, CA 94063 USA
Randall Atkinson @Home Network 425 Broadway、Redwood City、CA 94063 USA
Phone: +1 (415) 569-5000
EMail: rja@corp.home.net
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。