[要約] RFC 2402は、IPパケットの認証ヘッダーの仕様を定義しており、パケットの送信元の認証とデータの改ざんの検出を目的としています。
Network Working Group S. Kent
Request for Comments: 2402 BBN Corp
Obsoletes: 1826 R. Atkinson
Category: Standards Track @Home Network
November 1998
IP Authentication Header
IP認証ヘッダー
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. Authentication Header Format......................................3
2.1 Next Header...................................................4
2.2 Payload Length................................................4
2.3 Reserved......................................................4
2.4 Security Parameters Index (SPI)...............................4
2.5 Sequence Number...............................................5
2.6 Authentication Data ..........................................5
3. Authentication Header Processing..................................5
3.1 Authentication Header Location...............................5
3.2 Authentication Algorithms....................................7
3.3 Outbound Packet Processing...................................8
3.3.1 Security Association Lookup.............................8
3.3.2 Sequence Number Generation..............................8
3.3.3 Integrity Check Value Calculation.......................9
3.3.3.1 Handling Mutable Fields............................9
3.3.3.1.1 ICV Computation for IPv4.....................10
3.3.3.1.1.1 Base Header Fields.......................10
3.3.3.1.1.2 Options..................................11
3.3.3.1.2 ICV Computation for IPv6.....................11
3.3.3.1.2.1 Base Header Fields.......................11
3.3.3.1.2.2 Extension Headers Containing Options.....11
3.3.3.1.2.3 Extension Headers Not Containing Options.11
3.3.3.2 Padding...........................................12
3.3.3.2.1 Authentication Data Padding..................12
3.3.3.2.2 Implicit Packet Padding......................12
3.3.4 Fragmentation..........................................12
3.4 Inbound Packet Processing...................................13
3.4.1 Reassembly.............................................13
3.4.2 Security Association Lookup............................13
3.4.3 Sequence Number Verification...........................13
3.4.4 Integrity Check Value Verification.....................15
4. Auditing.........................................................15
5. Conformance Requirements.........................................16
6. Security Considerations..........................................16
7. Differences from RFC 1826........................................16
Acknowledgements....................................................17
Appendix A -- Mutability of IP Options/Extension Headers............18
A1. IPv4 Options.................................................18
A2. IPv6 Extension Headers.......................................19
References..........................................................20
Disclaimer..........................................................21
Author Information..................................................22
Full Copyright Statement............................................22
The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just "authentication"), and to provide protection against replays. This latter, optional service may be selected, by the receiver, when a Security Association is established. (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.) AH provides authentication for as much of the IP header as possible, as well as for upper level protocol data. However, some IP header fields may change in transit and the value of these fields, when the packet arrives at the receiver, may not be predictable by the sender. The values of such fields cannot be protected by AH. Thus the protection provided to the IP header by AH is somewhat piecemeal.
IP認証ヘッダー（AH）は、IPデータグラムのコネクションレス整合性とデータ送信元認証（以下、単に「認証」と呼ぶ）を提供し、リプレイに対する保護を提供するために使用されます。この後者のオプションサービスは、セキュリティアソシエーションが確立されたときに、受信者が選択できます。 （デフォルトでは、送信側がアンチリプレイに使用されるシーケンス番号をインクリメントする必要がありますが、このサービスは、受信側がシーケンス番号をチェックする場合にのみ有効です。）AHは、IPヘッダーと上位レベルのプロトコルデータ。ただし、一部のIPヘッダーフィールドは転送中に変更される場合があり、これらのフィールドの値は、パケットが受信者に到着したときに送信者が予測できない場合があります。このようなフィールドの値はAHで保護できません。したがって、AHによってIPヘッダーに提供される保護は、少しずつ異なります。
AH may be applied alone, in combination with the IP Encapsulating Security Payload (ESP) [KA97b], or in a nested fashion 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. ESP may be used to provide the same security services, and it also provides a confidentiality (encryption) service. The primary difference between the authentication provided by ESP and AH is the extent of the coverage. Specifically, ESP does not protect any IP header fields unless those fields are encapsulated by ESP (tunnel mode). For more details on how to use AH and ESP in various network environments, see the Security Architecture document [KA97a].
AHは、IPカプセル化セキュリティペイロード（ESP）[KA97b]と組み合わせて単独で適用することも、トンネルモードを使用してネストして適用することもできます（「インターネットプロトコルのセキュリティアーキテクチャ」[KA97a]を参照）。セキュリティアーキテクチャドキュメント）。セキュリティサービスは、通信するホストのペア間、通信するセキュリティゲートウェイのペア間、またはセキュリティゲートウェイとホストの間に提供できます。 ESPは同じセキュリティサービスを提供するために使用でき、機密性（暗号化）サービスも提供します。 ESPとAHによって提供される認証の主な違いは、カバレッジの範囲です。具体的には、ESPはIPヘッダーフィールドをESP（トンネルモード）でカプセル化しない限り、それらを保護しません。さまざまなネットワーク環境でAHおよびESPを使用する方法の詳細については、セキュリティアーキテクチャドキュメント[KA97a]を参照してください。
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 AH and ESP, the concept of Security Associations, the ways in which AH can be used in conjunction with ESP, and the different key management options available for AH and ESP. (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].)
読者は、セキュリティアーキテクチャドキュメントで説明されている用語と概念に精通していることを前提としています。特に、AHとESPが提供するセキュリティサービスの定義、セキュリティアソシエーションの概念、AHをESPと組み合わせて使用する方法、およびAHとESPで使用できるさまざまなキー管理オプションについて理解している必要があります。 。 （最後のトピックに関して、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 AH header will contain the value 51 in its Protocol (IPv4) or Next Header (IPv6, Extension) field [STD-2].
AHヘッダーの直前のプロトコルヘッダー（IPv4、IPv6、または拡張）は、そのプロトコル（IPv4）または次のヘッダー（IPv6、拡張）フィールド[STD-2]に値51を含みます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Payload Len | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Authentication Data (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following subsections define the fields that comprise the AH format. All the fields described here are mandatory, i.e., they are always present in the AH format and are included in the Integrity Check Value (ICV) computation (see Sections 2.6 and 3.3.3).
以下のサブセクションでは、AH形式を構成するフィールドを定義します。ここで説明するすべてのフィールドは必須です。つまり、これらのフィールドは常にAH形式で存在し、整合性チェック値（ICV）計算に含まれます（セクション2.6および3.3.3を参照）。
The Next Header is an 8-bit field that identifies the type of the next payload after the Authentication Header. 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).
次のヘッダーは、認証ヘッダーの後の次のペイロードのタイプを識別する8ビットのフィールドです。このフィールドの値は、Internet Assigned Numbers Authority（IANA）の最新の「Assigned Numbers」[STD-2] RFCで定義されているIPプロトコル番号のセットから選択されます。
This 8-bit field specifies the length of AH in 32-bit words (4-byte units), minus "2". (All IPv6 extension headers, as per RFC 1883, encode the "Hdr Ext Len" field by first subtracting 1 (64-bit word) from the header length (measured in 64-bit words). AH is an IPv6 extension header. However, since its length is measured in 32-bit words, the "Payload Length" is calculated by subtracting 2 (32 bit words).) In the "standard" case of a 96-bit authentication value plus the 3 32-bit word fixed portion, this length field will be "4". A "null" authentication algorithm may be used only for debugging purposes. Its use would result in a "1" value for this field for IPv4 or a "2" for IPv6, as there would be no corresponding Authentication Data field (see Section 3.3.3.2.1 on "Authentication Data Padding").
この8ビットのフィールドは、AHの長さを32ビットワード（4バイト単位）から「2」を引いたもので指定します。 （すべてのIPv6拡張ヘッダーは、RFC 1883に従って、最初にヘッダー長（64ビットワードで測定）から1（64ビットワード）を引くことにより、「Hdr Ext Len」フィールドをエンコードします。AHはIPv6拡張ヘッダーです。ただし、 、その長さは32ビットワードで測定されるため、「ペイロード長」は2（32ビットワード）を引いて計算されます。96ビット認証値と3つの32ビットワードを固定した「標準」の場合この長さフィールドは「4」になります。 「null」認証アルゴリズムは、デバッグ目的でのみ使用できます。対応する認証データフィールドがないため、このフィールドを使用すると、IPv4の場合はこのフィールドの値が「1」になり、IPv6の場合は「2」になります（「認証データのパディング」のセクション3.3.3.2.1を参照）。
This 16-bit field is reserved for future use. It MUST be set to "zero." (Note that the value is included in the Authentication Data calculation, but is otherwise ignored by the recipient.)
この16ビットのフィールドは、将来の使用のために予約されています。 「ゼロ」に設定する必要があります。 （値は認証データの計算に含まれますが、それ以外の場合は受信者によって無視されることに注意してください。）
The SPI is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (AH), 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).
SPIは任意の32ビット値であり、宛先IPアドレスおよびセキュリティプロトコル（AH）と組み合わせて、このデータグラムのセキュリティアソシエーションを一意に識別します。 1から255の範囲のSPI値のセットは、将来使用するためにInternet Assigned Numbers Authority（IANA）によって予約されています。予約済みのSPI値は、割り当てられたSPI値の使用がRFCで指定されていない限り、通常はIANAによって割り当てられません。これは通常、SAの確立時に宛先システムによって選択されます（詳細については、セキュリティアーキテクチャのドキュメントを参照してください）。
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.2 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.2を参照してください。）アンチリプレイが有効な場合（デフォルト）、送信されたシーケンス番号は循環することは決してありません。したがって、SAで2 ^ 32番目のパケットを送信する前に、送信者のカウンターと受信者のカウンターをリセットする必要があります（新しいSA、つまり新しいキーを確立することによって）。
This is a variable-length field that contains the Integrity Check Value (ICV) for this packet. The field must be an integral multiple of 32 bits in length. The details of the ICV computation are described in Section 3.3.2 below. This field may include explicit padding. This padding is included to ensure that the length of the AH header is an integral multiple of 32 bits (IPv4) or 64 bits (IPv6). All implementations MUST support such padding. Details of how to compute the required padding length are provided below. The authentication algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation.
これは、このパケットの整合性チェック値（ICV）を含む可変長フィールドです。フィールドは、長さが32ビットの整数倍でなければなりません。 ICV計算の詳細については、以下のセクション3.3.2で説明します。このフィールドには、明示的なパディングが含まれる場合があります。このパディングは、AHヘッダーの長さが32ビット（IPv4）または64ビット（IPv6）の整数倍であることを保証するために含まれています。すべての実装は、そのようなパディングをサポートする必要があります。必要なパディング長を計算する方法の詳細を以下に示します。認証アルゴリズムの仕様では、ICVの長さと、検証のための比較ルールと処理手順を指定する必要があります。
Like ESP, AH 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, in addition to selected IP header fields. (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.) In transport mode, AH 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 calls for placing AH 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 AH transport mode positioning for a typical IPv4 packet, on a "before and after" basis.
ESPと同様に、AHはトランスポートモードまたはトンネルモードの2つの方法で使用できます。前者のモードはホスト実装にのみ適用可能であり、選択したIPヘッダーフィールドに加えて、上位層プロトコルを保護します。 （このモードでは、セキュリティアーキテクチャドキュメントで定義されている「bump-in-the-stack」または「bump-in-the-wire」実装の場合、インバウンドおよびアウトバウンドIPフラグメントは、追加のIPsec実装を必要とする場合があることに注意してください。この仕様に準拠し、透過的なIPsecサポートを提供するために、IPの再構成/断片化。複数のインターフェースが使用されている場合、これらの実装内でそのような操作を実行するには、特別な注意が必要です。トランスポートモードでは、AHはIPヘッダーの後と前に挿入されます。 TCP、UDP、ICMPなどの上位層プロトコル、またはすでに挿入されている他のIPsecヘッダーの前。 IPv4のコンテキストでは、これはIPヘッダー（およびそれに含まれるすべてのオプション）の後、ただし上位層プロトコルの前にAHを配置することを要求します。 （「トランスポート」モードという用語は、その使用をTCPおよびUDPに制限するものと誤解されるべきではないことに注意してください。たとえば、ICMPメッセージは、「トランスポート」モードまたは「トンネル」モードのいずれかを使用して送信できます。）次の図は、AHトランスポートを示しています「前と後」ベースでの典型的なIPv4パケットのモードポジショニング。
BEFORE APPLYING AH
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING AH
---------------------------------
IPv4 |orig IP hdr | | | |
|(any options)| AH | TCP | Data |
---------------------------------
|<------- authenticated ------->|
except for mutable fields
In the IPv6 context, AH 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 AH header depending on the semantics desired. The following diagram illustrates AH transport mode positioning for a typical IPv6 packet.
IPv6のコンテキストでは、AHはエンドツーエンドのペイロードと見なされるため、ホップバイホップ、ルーティング、およびフラグメンテーション拡張ヘッダーの後に表示されます。宛先オプション拡張ヘッダーは、必要なセマンティクスに応じて、AHヘッダーの前または後に表示されます。次の図は、一般的なIPv6パケットのAHトランスポートモードの配置を示しています。
BEFORE APPLYING AH
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
AFTER APPLYING AH
------------------------------------------------------------
IPv6 | |hop-by-hop, dest*, | | dest | | |
|orig IP hdr |routing, fragment. | AH | opt* | TCP | Data |
------------------------------------------------------------
|<---- authenticated except for mutable fields ----------->|
* = if present, could be before AH, after AH, or both
* =存在する場合、AHの前、AHの後、またはその両方の可能性があります
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 AH may be employed in either hosts or security gateways (or in so-called "bump-in-the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document). When AH is implemented in a security gateway (to protect 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, AH protects the entire inner IP packet, including the entire inner IP header. The position of AH in tunnel mode, relative to the outer IP header, is the same as for AH in transport mode. The following diagram illustrates AH tunnel mode positioning for typical IPv4 and IPv6 packets.
トンネルモードAHは、ホストまたはセキュリティゲートウェイ（または、セキュリティアーキテクチャドキュメントで定義されている、いわゆる「bump-in-the-stack」または「bump-in-the-wire」の実装）で使用できます。 （トランジットトラフィックを保護するために）セキュリティゲートウェイにAHが実装されている場合は、トンネルモードを使用する必要があります。トンネルモードでは、「内部」IPヘッダーは最終的な送信元アドレスと宛先アドレスを伝達しますが、「外部」IPヘッダーには、セキュリティゲートウェイのアドレスなどの個別のIPアドレスが含まれる場合があります。トンネルモードでは、AHは内部IPヘッダー全体を含む内部IPパケット全体を保護します。トンネルモードでのAHの位置は、外部IPヘッダーを基準にして、トランスポートモードでのAHと同じです。次の図は、一般的なIPv4およびIPv6パケットのAHトンネルモードの配置を示しています。
------------------------------------------------
IPv4 | new IP hdr* | | orig IP hdr* | | |
|(any options)| AH | (any options) |TCP | Data |
------------------------------------------------
|<- authenticated except for mutable fields -->|
| in the new IP hdr |
--------------------------------------------------------------
IPv6 | | ext hdrs*| | | ext hdrs*| | |
|new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data|
--------------------------------------------------------------
|<-- authenticated except for mutable fields in new IP hdr ->|
* = construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed below.
* =外部IP hdr /拡張の構築と内部IP hdr /拡張の変更については、以下で説明します。
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. The mandatory-to-implement authentication algorithms are described in Section 5 "Conformance Requirements". Other algorithms MAY be supported.
ICV計算に使用される認証アルゴリズムは、SAによって指定されます。ポイントツーポイント通信の場合、適切な認証アルゴリズムには、対称暗号化アルゴリズム（DESなど）または一方向ハッシュ関数（MD5またはSHA-1など）に基づくキー付きメッセージ認証コード（MAC）が含まれます。マルチキャスト通信では、非対称署名アルゴリズムと組み合わせた一方向ハッシュアルゴリズムが適切ですが、現在、パフォーマンスとスペースの考慮により、そのようなアルゴリズムは使用できません。実装に必須の認証アルゴリズムについては、セクション5「適合要件」で説明しています。他のアルゴリズムはサポートされるかもしれません。
In transport mode, the sender inserts the AH header after the IP header and before an upper layer protocol header, as described above. 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.
トランスポートモードでは、送信者は、前述のように、IPヘッダーの後、上位層プロトコルヘッダーの前にAHヘッダーを挿入します。トンネルモードでは、外部IPヘッダーと内部IPヘッダー/拡張をさまざまな方法で相互に関連付けることができます。カプセル化プロセス中の外部IPヘッダー/拡張の構築については、セキュリティアーキテクチャのドキュメントで説明されています。
If there is more than one IPsec header/extension required, the order of the application of the security headers MUST be defined by security policy. For simplicity of processing, each IPsec header SHOULD ignore the existence (i.e., not zero the contents or try to predict the contents) of IPsec headers to be applied later. (While a native IP or bump-in-the-stack implementation could predict the contents of later IPsec headers that it applies itself, it won't be possible for it to predict any IPsec headers added by a bump-in-the-wire implementation between the host and the network.)
複数のIPsecヘッダー/拡張機能が必要な場合は、セキュリティヘッダーの適用順序をセキュリティポリシーで定義する必要があります。処理を簡単にするために、各IPsecヘッダーは、後で適用されるIPsecヘッダーの存在を無視する必要があります（つまり、内容をゼロにしないか、内容を予測しようとします）。 （ネイティブIPまたはバンプインザスタックの実装は、それ自体が適用する後のIPsecヘッダーの内容を予測できますが、バンプインザワイヤーによって追加されたIPsecヘッダーを予測することはできません。ホストとネットワーク間の実装。）
AH is applied to an outbound packet only after an IPsec implementation determines that the packet is associated with an SA that calls for AH processing. The process of determining what, if any, IPsec processing is applied to outbound traffic is described in the Security Architecture document.
パケットがAH処理を要求するSAに関連付けられているとIPsec実装が判断した後にのみ、AHが発信パケットに適用されます。発信トラフィックに適用されるIPsec処理がある場合は、それを決定するプロセスについては、セキュリティアーキテクチャのドキュメントで説明されています。
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を参照）。ただし、送信者は引き続きカウンターをインクリメントし、最大値に達した場合、カウンターはゼロに戻ります。
The AH ICV is computed over: o IP header fields that are either immutable in transit or that are predictable in value upon arrival at the endpoint for the AH SA o the AH header (Next Header, Payload Len, Reserved, SPI, Sequence Number, and the Authentication Data (which is set to zero for this computation), and explicit padding bytes (if any)) o the upper level protocol data, which is assumed to be immutable in transit
AH ICVは次のように計算されます。o転送中に不変であるか、AH SAのエンドポイントに到着したときに値が予測可能なIPヘッダーフィールドo AHヘッダー（次のヘッダー、ペイロードLen、予約済み、SPI、シーケンス番号、認証データ（この計算ではゼロに設定されます）、および明示的なパディングバイト（存在する場合））o上位レベルのプロトコルデータ。転送中に不変であると見なされます。
If a field may be modified during transit, the value of the field is set to zero for purposes of the ICV computation. If a field is mutable, but its value at the (IPsec) receiver is predictable, then that value is inserted into the field for purposes of the ICV calculation. The Authentication Data field is also set to zero in preparation for this computation. Note that by replacing each field's value with zero, rather than omitting the field, alignment is preserved for the ICV calculation. Also, the zero-fill approach ensures that the length of the fields that are so handled cannot be changed during transit, even though their contents are not explicitly covered by the ICV.
トランジット中にフィールドが変更される可能性がある場合、ICV計算のためにフィールドの値がゼロに設定されます。フィールドが変更可能であるが、（IPsec）レシーバーでの値が予測可能な場合、その値はICV計算のためにフィールドに挿入されます。この計算の準備として、認証データフィールドもゼロに設定されます。各フィールドの値をゼロで置き換えることにより、フィールドを省略するのではなく、ICV計算のために位置合わせが保持されることに注意してください。また、ゼロフィルアプローチにより、そのように処理されるフィールドの長さが、ICVによって明示的にカバーされていなくても、転送中に変更できないことが保証されます。
As a new extension header or IPv4 option is created, it will be defined in its own RFC and SHOULD include (in the Security Considerations section) directions for how it should be handled when calculating the AH ICV. If the IP (v4 or v6) implementation encounters an extension header that it does not recognize, it will discard the packet and send an ICMP message. IPsec will never see the packet. If the IPsec implementation encounters an IPv4 option that it does not recognize, it should zero the whole option, using the second byte of the option as the length. IPv6 options (in Destination extension headers or Hop by Hop extension header) contain a flag indicating mutability, which determines appropriate processing for such options.
新しい拡張ヘッダーまたはIPv4オプションが作成されると、それは独自のRFCで定義され、AH ICVを計算するときの処理方法の指示を（セキュリティの考慮事項セクションに）含める必要があります（SHOULD）。 IP（v4またはv6）の実装が、認識しない拡張ヘッダーを検出すると、パケットを破棄してICMPメッセージを送信します。 IPsecはパケットを決して見ません。 IPsec実装が認識できないIPv4オプションを検出した場合、オプションの2番目のバイトを長さとして使用して、オプション全体をゼロにする必要があります。 IPv6オプション（宛先拡張ヘッダーまたはホップバイホップ拡張ヘッダー内）には、そのようなオプションの適切な処理を決定する可変性を示すフラグが含まれています。
The IPv4 base header fields are classified as follows:
IPv4ベースヘッダーフィールドは次のように分類されます。
Immutable Version Internet Header Length Total Length Identification Protocol (This should be the value for AH.) Source Address Destination Address (without loose or strict source routing)
不変バージョンインターネットヘッダー長全長識別プロトコル（これはAHの値である必要があります）
Mutable but predictable Destination Address (with loose or strict source routing)
変更可能だが予測可能な宛先アドレス（ルーズまたは厳密なソースルーティングを使用）
Mutable (zeroed prior to ICV calculation) Type of Service (TOS) Flags Fragment Offset Time to Live (TTL) Header Checksum
可変（ICV計算の前にゼロ化）タイプオブサービス（TOS）フラグフラグメントオフセット存続時間（TTL）ヘッダーチェックサム
TOS -- This field is excluded because some routers are known to change the value of this field, even though the IP specification does not consider TOS to be a mutable header field.
TOS-IP仕様でTOSを可変ヘッダーフィールドと見なしていない場合でも、一部のルーターはこのフィールドの値を変更することがわかっているため、このフィールドは除外されます。
Flags -- This field is excluded since an intermediate router might set the DF bit, even if the source did not select it.
フラグ-このフィールドは除外されます。ソースが選択していなくても、中間ルーターがDFビットを設定する可能性があるためです。
Fragment Offset -- Since AH is applied only to non-fragmented IP packets, the Offset Field must always be zero, and thus it is excluded (even though it is predictable).
フラグメントオフセット-AHはフラグメント化されていないIPパケットにのみ適用されるため、オフセットフィールドは常にゼロである必要があり、したがって（予測可能であっても）除外されます。
TTL -- This is changed en-route as a normal course of processing by routers, and thus its value at the receiver is not predictable by the sender.
TTL-これは、ルーターによる通常の処理過程で途中で変更されるため、受信側での値は送信側で予測できません。
Header Checksum -- This will change if any of these other fields changes, and thus its value upon reception cannot be predicted by the sender.
ヘッダーチェックサム-これらの他のフィールドのいずれかが変更された場合、これは変更されるため、受信時の値は送信者が予測できません。
For IPv4 (unlike IPv6), there is no mechanism for tagging options as mutable in transit. Hence the IPv4 options are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable. For IPv4, the entire option is viewed as a unit; so even though the type and length fields within most options are immutable in transit, if an option is classified as mutable, the entire option is zeroed for ICV computation purposes.
IPv4の場合（IPv6とは異なり）、移動中に変更可能としてタグ付けするためのメカニズムはありません。したがって、IPv4オプションは付録Aに明示的にリストされており、不変、変更可能だが予測可能、または変更可能として分類されています。 IPv4の場合、オプション全体が1つの単位として表示されます。したがって、ほとんどのオプション内のタイプフィールドと長さフィールドは転送中に不変ですが、オプションが可変として分類されている場合、ICV計算のためにオプション全体がゼロになります。
The IPv6 base header fields are classified as follows:
IPv6ベースヘッダーフィールドは次のように分類されます。
Immutable Version Payload Length Next Header (This should be the value for AH.) Source Address Destination Address (without Routing Extension Header)
不変バージョンペイロードの長さ次のヘッダー（これはAHの値である必要があります。）送信元アドレス宛先アドレス（ルーティング拡張ヘッダーなし）
Mutable but predictable Destination Address (with Routing Extension Header)
変更可能だが予測可能な宛先アドレス（ルーティング拡張ヘッダー付き）
Mutable (zeroed prior to ICV calculation) Class Flow Label Hop Limit
可変（ICV計算の前にゼロ化）クラスフローラベルホップ制限
IPv6 options in the Hop-by-Hop and Destination Extension Headers contain a bit that indicates whether the option might change (unpredictably) during transit. For any option for which contents may change en-route, the entire "Option Data" field must be treated as zero-valued octets when computing or verifying the ICV. The Option Type and Opt Data Len are included in the ICV calculation. All options for which the bit indicates immutability are included in the ICV calculation. See the IPv6 specification [DH95] for more information.
ホップバイホップおよび宛先拡張ヘッダーのIPv6オプションには、オプションが転送中に（予測できない）変更される可能性があるかどうかを示すビットが含まれています。途中で内容が変更される可能性のあるオプションについては、ICVを計算または検証するときに、「オプションデータ」フィールド全体をゼロ値のオクテットとして扱う必要があります。オプションタイプとオプションデータレンは、ICV計算に含まれます。ビットが不変性を示すすべてのオプションは、ICV計算に含まれます。詳細については、IPv6仕様[DH95]を参照してください。
The IPv6 extension headers that do not contain options are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable.
オプションを含まないIPv6拡張ヘッダーは、付録Aに明示的にリストされており、不変、可変、予測可能、または可変として分類されています。
As mentioned in section 2.6, the Authentication Data field explicitly includes padding to ensure that the AH header is a multiple of 32 bits (IPv4) or 64 bits (IPv6). If padding is required, its length is determined by two factors:
セクション2.6で述べたように、認証データフィールドには、AHヘッダーが32ビット（IPv4）または64ビット（IPv6）の倍数であることを保証するためのパディングが明示的に含まれています。パディングが必要な場合、その長さは次の2つの要素によって決定されます。
- the length of the ICV - the IP protocol version (v4 or v6)
- ICVの長さ-IPプロトコルバージョン（v4またはv6）
For example, if the output of the selected algorithm is 96-bits, no padding is required for either IPv4 or for IPv6. However, if a different length ICV is generated, due to use of a different algorithm, then padding may be required depending on the length and IP protocol version. The content of the padding field is arbitrarily selected by the sender. (The padding is arbitrary, but need not be random to achieve security.) These padding bytes are included in the Authentication Data calculation, counted as part of the Payload Length, and transmitted at the end of the Authentication Data field to enable the receiver to perform the ICV calculation.
たとえば、選択したアルゴリズムの出力が96ビットの場合、IPv4またはIPv6のいずれにもパディングは必要ありません。ただし、異なるアルゴリズムを使用するために、異なる長さのICVが生成される場合、長さとIPプロトコルのバージョンによっては、パディングが必要になることがあります。パディングフィールドの内容は、送信者が任意に選択します。 （パディングは任意ですが、セキュリティを達成するためにランダムである必要はありません。）これらのパディングバイトは、認証データの計算に含まれ、ペイロード長の一部としてカウントされ、認証データフィールドの最後に送信されて、受信機がICV計算を実行します。
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 IP packet length (including AH) does not match the blocksize requirements for the algorithm, implicit padding MUST be appended to the end of the packet, 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計算が実行されるバイト文字列は、アルゴリズムで指定されたブロックサイズの倍数でなければなりません。 IPパケット長（AHを含む）がアルゴリズムのブロックサイズ要件と一致しない場合、ICV計算の前に、暗黙のパディングをパケットの最後に追加する必要があります。パディングオクテットはゼロの値を持っている必要があります。ブロックサイズ（およびパディングの長さ）は、アルゴリズムの仕様で指定されています。このパディングはパケットとともに送信されません。 MD5とSHA-1は、内部の埋め込み規則により、1バイトのブロックサイズを持っていると見なされることに注意してください。
If required, IP fragmentation occurs after AH processing within an IPsec implementation. Thus, transport mode AH is applied only to whole IP datagrams (not to IP fragments). An IP packet to which AH has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to AH processing at a receiver. In tunnel mode, AH 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 (see the Security Architecture document for details) may apply tunnel mode AH to such fragments.
必要に応じて、IPsec実装内のAH処理後にIPフラグメンテーションが発生します。したがって、トランスポートモードAHは、IPデータグラム全体にのみ適用されます（IPフラグメントには適用されません）。 AHが適用されたIPパケットは、途中でルーターによってフラグメント化される可能性があり、そのようなフラグメントは、受信側でのAH処理の前に再構成する必要があります。トンネルモードでは、AHがIPパケットに適用され、そのペイロードはフラグメント化されたIPパケットである場合があります。たとえば、セキュリティゲートウェイまたは「bump-in-the-stack」または「bump-in-the-wire」IPsec実装（詳細については、セキュリティアーキテクチャのドキュメントを参照）は、そのようなフラグメントにトンネルモードAHを適用する場合があります。
If there is more than one IPsec header/extension present, the processing for each one ignores (does not zero, does not use) any IPsec headers applied subsequent to the header being processed.
複数のIPsecヘッダー/拡張が存在する場合、それぞれの処理は、処理中のヘッダーの後に適用されたIPsecヘッダーを無視します（ゼロにしない、使用しません）。
If required, reassembly is performed prior to AH processing. If a packet offered to AH 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, Source Address, Destination Address, and (in IPv6) the Flow ID.
必要に応じて、AH処理の前に再アセンブリが実行されます。処理のためにAHに提供されたパケットがIPフラグメントであるように見える場合、つまり、OFFSETフィールドがゼロ以外であるか、MORE FRAGMENTSフラグが設定されている場合、受信者はパケットを破棄する必要があります。これは監査可能なイベントです。このイベントの監査ログエントリには、SPI値、日付/時刻、送信元アドレス、宛先アドレス、および（IPv6の場合）フローIDを含める必要があります（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 packet containing an IP Authentication Header, the receiver determines the appropriate (unidirectional) SA, based on the destination IP address, security protocol (AH), 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, specifies the algorithm(s) employed for ICV computation, and indicates the key(s) required to validate the ICV.
IP認証ヘッダーを含むパケットを受信すると、受信者は、宛先IPアドレス、セキュリティプロトコル（AH）、およびSPIに基づいて、適切な（単方向）SAを決定します。 （このプロセスについては、セキュリティアーキテクチャのドキュメントで詳しく説明しています。）SAは、シーケンス番号フィールドがチェックされるかどうかを示し、ICV計算に使用されるアルゴリズムを指定し、ICVの検証に必要なキーを示します。 。
If no valid Security Association exists for this session (e.g., 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, Source Address, Destination Address, and (in IPv6) the Flow ID.
このセッションに有効なセキュリティアソシエーションが存在しない場合（たとえば、レシーバーにキーがない場合）、レシーバーはパケットを破棄する必要があります。これは監査可能なイベントです。このイベントの監査ログエントリには、SPI値、日付/時刻、送信元アドレス、宛先アドレス、および（IPv6の場合）フローIDを含める必要があります（SHOULD）。
All AH implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. (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.) 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.2), 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.
すべてのAH実装は、アンチリプレイサービスをサポートする必要がありますが、SAごとにレシーバーによってその使用が有効または無効にされる場合があります。 （送信先アドレスがユニキャスト、ブロードキャスト、またはマルチキャストのいずれであるかに関係なく、単一のSAにトラフィックを送信する複数の送信者間で送信されたシーケンス番号値を管理するための規定がないことに注意してください。したがって、アンチリプレイサービスは、単一のSAを使用するマルチセンダー環境。）レシーバーがSAのアンチリプレイを有効にしていない場合、シーケンス番号に対してインバウンドチェックは実行されません。ただし、送信側から見ると、デフォルトでは、受信側でアンチリプレイが有効になっていると想定しています。不必要なシーケンス番号の監視とSAのセットアップ（セクション3.3.2を参照）を送信者に行わせないようにするため、IKEなどのSA確立プロトコルが採用されている場合、受信者は、SAの確立中に受信者がアンチを提供しない場合、送信者に通知する必要があります（SHOULD）。 -リプレイ保護。
If the receiver has enabled the anti-replay service for this SA, the receiver 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 AH check applied to a packet after it has been matched to an SA, to speed rejection of duplicate packets.
レシーバーがこのSAのアンチリプレイサービスを有効にしている場合、SAが確立されたときに、SAのレシーバーパケットカウンターをゼロに初期化する必要があります。受信したパケットごとに、受信者は、パケットに、このSAの有効期間中に受信した他のパケットのシーケンス番号と重複しないシーケンス番号が含まれていることを確認する必要があります。これは、パケットがSAに一致した後にパケットに適用される最初のAHチェックであり、重複パケットの拒否を高速化する必要があります。
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. Another window size (larger than the MINIMUM) MAY be chosen by the receiver. (The receiver does NOT notify the sender of the window size.)
スライディング受信ウィンドウを使用すると、重複が拒否されます。 （ウィンドウの実装方法はローカルな問題ですが、次のテキストは実装が示す必要のある機能を説明しています。）32の最小ウィンドウサイズをサポートする必要があります。ただし、64のウィンドウサイズが推奨され、デフォルトとして使用する必要があります（SHOULD）。別のウィンドウサイズ（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, 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.
パケットがウィンドウ内で新しい場合、または「右側」のウィンドウ外にある場合、受信者はシーケンス番号ウィンドウデータを更新する前にパケットを認証する必要があることに注意してください。
The receiver computes the ICV over the appropriate fields of the packet, 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.
受信者は、指定された認証アルゴリズムを使用して、パケットの適切なフィールドで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 audit log entry SHOULD include the SPI value, date/time received, Source Address, Destination Address, and (in IPv6) the Flow ID.
計算および受信したICVが一致した場合、データグラムは有効であり、受け入れられます。テストが失敗した場合、受信者は受信したIPデータグラムを無効として破棄する必要があります。これは監査可能なイベントです。監査ログエントリには、SPI値、受信日時、送信元アドレス、宛先アドレス、および（IPv6の場合）フローIDを含める必要があります（SHOULD）。
DISCUSSION:
討論：
Begin by saving the ICV value and replacing it (but not any Authentication Data padding) with zero. Zero all other fields that may have been modified during transit. (See section 3.3.3.1 for a discussion of which fields are zeroed before performing the ICV calculation.) Check the overall length of the packet, and if it requires implicit padding based on the requirements of the authentication algorithm, append zero-filled bytes to the end of the packet as required. 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値を保存し、それ（認証データのパディングではなく）をゼロで置き換えることから始めます。転送中に変更された可能性のある他のすべてのフィールドをゼロにします。 （ICV計算を実行する前にゼロ化されるフィールドの説明については、セクション3.3.3.1を参照してください。）パケットの全長を確認し、認証アルゴリズムの要件に基づいて暗黙的なパディングが必要な場合は、ゼロで満たされたバイトを必要に応じてパケットの終わり。 ICV計算を実行し、アルゴリズム仕様で定義された比較ルールを使用して、結果を保存された値と比較します。 （たとえば、デジタル署名と一方向ハッシュがICV計算に使用される場合、照合プロセスはより複雑になります。）
Not all systems that implement AH will implement auditing. However, if AH is incorporated into a system that supports auditing, then the AH implementation MUST also support auditing and MUST allow a system administrator to enable or disable auditing for AH. 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.
AHを実装するすべてのシステムが監査を実装するわけではありません。ただし、AHが監査をサポートするシステムに組み込まれている場合、AH実装は監査もサポートする必要があり、システム管理者がAHの監査を有効または無効にできるようにする必要があります。ほとんどの場合、監査の粒度はローカルな問題です。ただし、この仕様ではいくつかの監査可能なイベントが識別されており、これらの各イベントについて、監査ログに含める必要がある最低限の情報のセットが定義されています。これらの各イベントの追加情報も監査ログに含めることができます。また、この仕様で明示的に呼び出されていない追加のイベントも、監査ログエントリになる場合があります。監査可能なイベントの検出に応答して、意図された送信者にメッセージを送信する必要はありません。これは、そのようなアクションによってサービス拒否を引き起こす可能性があるためです。
Implementations that claim conformance or compliance with this specification MUST fully implement the AH 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 AH implementation MUST support the following mandatory-to-implement algorithms:
この仕様への準拠または準拠を主張する実装は、ここで説明されているAH構文と処理を完全に実装しなければならず、セキュリティアーキテクチャドキュメントのすべての要件に準拠しなければなりません。 ICVの計算に使用されるキーが手動で配布される場合、アンチリプレイサービスを正しく提供するには、キーが交換されるまで、送信者でカウンターの状態を正しく維持する必要があり、カウンターがオーバーフローした場合、自動復旧プロビジョニングはおそらくありません。差し迫っていた。したがって、準拠した実装では、手動でキーを設定したSAと組み合わせてこのサービスを提供してはなりません（SHOULD NOT）。準拠するAH実装は、次の実装必須アルゴリズムをサポートする必要があります。
- HMAC with MD5 [MG97a] - HMAC with SHA-1 [MG97b]
- HMACとMD5 [MG97a]-HMACとSHA-1 [MG97b]
Security is central to the design of this protocol, and these security considerations permeate the specification. Additional security-relevant aspects of using the IPsec protocol are discussed in the Security Architecture document.
セキュリティはこのプロトコルの設計の中心であり、これらのセキュリティの考慮事項は仕様に浸透しています。 IPsecプロトコルの使用に関するその他のセキュリティ関連の側面については、セキュリティアーキテクチャのドキュメントで説明されています。
This specification of AH differs from RFC 1826 [ATK95] in several important respects, but the fundamental features of AH remain intact. One goal of the revision of RFC 1826 was to provide a complete framework for AH, with ancillary RFCs required only for algorithm specification. For example, the anti-replay service is now an integral, mandatory part of AH, not a feature of a transform defined in another RFC. Carriage of a sequence number to support this service is now required at all times. The default algorithms required for interoperability have been changed to HMAC with MD5 or SHA-1 (vs. keyed MD5), for security reasons. The list of IPv4 header fields excluded from the ICV computation has been expanded to include the OFFSET and FLAGS fields.
このAHの仕様はいくつかの重要な点でRFC 1826 [ATK95]とは異なりますが、AHの基本的な機能は損なわれていません。 RFC 1826の改訂の1つの目標は、AHの完全なフレームワークを提供することであり、補助的なRFCはアルゴリズムの仕様にのみ必要です。たとえば、アンチリプレイサービスは現在、AHの不可欠な必須部分であり、別のRFCで定義されている変換の機能ではありません。このサービスをサポートするためのシーケンス番号のキャリッジが常に必要になります。相互運用性に必要なデフォルトのアルゴリズムは、セキュリティ上の理由から、MD5またはSHA-1（対キー付きMD5）を備えたHMACに変更されました。 ICV計算から除外されるIPv4ヘッダーフィールドのリストは、OFFSETおよびFLAGSフィールドを含むように拡張されました。
Another motivation for revision was to provide additional detail and clarification of subtle points. This specification provides rationale for exclusion of selected IPv4 header fields from AH coverage and provides examples on positioning of AH in both the IPv4 and v6 contexts. Auditing requirements have been clarified in this version of the specification. Tunnel mode AH was mentioned only in passing in RFC 1826, but now is a mandatory feature of AH. Discussion of interactions with key management and with security labels have been moved to the Security Architecture document.
改訂のもう1つの動機は、微妙な点の詳細と説明を追加することでした。この仕様は、選択されたIPv4ヘッダーフィールドをAHカバレッジから除外する根拠を提供し、IPv4とv6の両方のコンテキストでのAHの配置に関する例を提供します。このバージョンの仕様では、監査要件が明確になっています。トンネルモードAHは、RFC 1826の通過でのみ言及されましたが、現在はAHの必須機能です。キー管理およびセキュリティラベルとの相互作用の説明は、セキュリティアーキテクチャドキュメントに移動されました。
Acknowledgements
謝辞
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, Francis Dupont, Phil Karn, Frank Kastenholz, Perry Metzger, David Mihelcic, Hilarie Orman, Norman Shulman, William Simpson, and Nina Yuan.
3年以上にわたり、このドキュメントは複数のバージョンとイテレーションを経て進化してきました。この間、多くの人々が重要なアイデアとエネルギーをプロセスとドキュメント自体に提供してきました。著者は、このバージョンの仕様のレビュー、編集、バックグラウンド調査、および調整に広範な支援を提供してくれたKaren Seoに感謝します。著者はまた、IPsecおよびIPngワーキンググループのメンバーに感謝の意を表します（特にアルファベット順）：Steve Bellovin、Steve Deering、Francis Dupont、Phil Karn、Frank Kastenholz、Perry Metzger、David Mihelcic 、ヒラリー・オーマン、ノーマン・シュルマン、ウィリアム・シンプソン、ニーナ・ユアン。
Appendix A -- Mutability of IP Options/Extension Headers
付録A-IPオプション/拡張ヘッダーの可変性
A1. IPv4 Options
A1。 IPv4オプション
This table shows how the IPv4 options are classified with regard to "mutability". Where two references are provided, the second one supercedes the first. This table is based in part on information provided in RFC1700, "ASSIGNED NUMBERS", (October 1994).
この表は、「可変性」に関してIPv4オプションがどのように分類されるかを示しています。 2つの参照が提供されている場合、2番目の参照が最初の参照より優先されます。この表は、RFC1700の「ASSIGNED NUMBERS」（1994年10月）で提供されている情報に一部基づいています。
Opt.
Copy Class # Name Reference
---- ----- --- ------------------------ ---------
IMMUTABLE -- included in ICV calculation
0 0 0 End of Options List [RFC791]
0 0 1 No Operation [RFC791]
1 0 2 Security [RFC1108(historic but in use)]
1 0 5 Extended Security [RFC1108(historic but in use)]
1 0 6 Commercial Security [expired I-D, now US MIL STD]
1 0 20 Router Alert [RFC2113]
1 0 21 Sender Directed Multi- [RFC1770]
Destination Delivery
MUTABLE -- zeroed
1 0 3 Loose Source Route [RFC791]
0 2 4 Time Stamp [RFC791]
0 0 7 Record Route [RFC791]
1 0 9 Strict Source Route [RFC791]
0 2 18 Traceroute [RFC1393]
EXPERIMENTAL, SUPERCEDED -- zeroed
1 0 8 Stream ID [RFC791, RFC1122 (Host Req)]
0 0 11 MTU Probe [RFC1063, RFC1191 (PMTU)]
0 0 12 MTU Reply [RFC1063, RFC1191 (PMTU)]
1 0 17 Extended Internet Proto [RFC1385, RFC1883 (IPv6)]
0 0 10 Experimental Measurement [ZSu]
1 2 13 Experimental Flow Control [Finn]
1 0 14 Experimental Access Ctl [Estrin]
0 0 15 ??? [VerSteeg]
1 0 16 IMI Traffic Descriptor [Lee]
1 0 19 Address Extension [Ullmann IPv7]
NOTE: Use of the Router Alert option is potentially incompatible with use of IPsec. Although the option is immutable, its use implies that each router along a packet's path will "process" the packet and consequently might change the packet. This would happen on a hop by hop basis as the packet goes from router to router. Prior to being processed by the application to which the option contents are directed, e.g., RSVP/IGMP, the packet should encounter AH processing.
注：ルーターアラートオプションの使用は、IPsecの使用と互換性がない可能性があります。このオプションは不変ですが、その使用は、パケットのパスに沿った各ルーターがパケットを「処理」し、結果としてパケットを変更する可能性があることを意味します。これは、パケットがルーター間を移動するときに、ホップバイホップで発生します。オプションのコンテンツが送信されるアプリケーション（RSVP / IGMPなど）によって処理される前に、パケットはAH処理に遭遇する必要があります。
However, AH processing would require that each router along the path is a member of a multicast-SA defined by the SPI. This might pose problems for packets that are not strictly source routed, and it requires multicast support techniques not currently available.
ただし、AH処理では、パス上の各ルーターがSPIによって定義されたマルチキャストSAのメンバーである必要があります。これは、厳密にソースルーティングされていないパケットに問題を引き起こす可能性があり、現在利用できないマルチキャストサポート技術が必要です。
NOTE: Addition or removal of any security labels (BSO, ESO, CIPSO) by systems along a packet's path conflicts with the classification of these IP Options as immutable and is incompatible with the use of IPsec.
注：パケットのパスに沿ったシステムによるセキュリティラベル（BSO、ESO、CIPSO）の追加または削除は、これらのIPオプションの不変としての分類と競合し、IPsecの使用と互換性がありません。
NOTE: End of Options List options SHOULD be repeated as necessary to ensure that the IP header ends on a 4 byte boundary in order to ensure that there are no unspecified bytes which could be used for a covert channel.
注：オプションリストの終わりのオプションは、IPヘッダーが4バイト境界で終了するように、必要に応じて繰り返して、隠れチャネルに使用できる未指定のバイトがないことを確認する必要があります。
A2. IPv6 Extension Headers
A2。 IPv6拡張ヘッダー
This table shows how the IPv6 Extension Headers are classified with regard to "mutability".
この表は、「可変性」に関してIPv6拡張ヘッダーがどのように分類されるかを示しています。
Option/Extension Name Reference
----------------------------------- ---------
MUTABLE BUT PREDICTABLE -- included in ICV calculation
Routing (Type 0) [RFC1883]
BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING TRANSIT) Hop by Hop options [RFC1883] Destination options [RFC1883]
オプションが変更可能である場合、ビットは示す（トランジット中に予期せず変更される）ホップバイホップオプション[RFC1883]宛先オプション[RFC1883]
NOT APPLICABLE Fragmentation [RFC1883]
該当しないフラグメンテーション[RFC1883]
Options -- IPv6 options in the Hop-by-Hop and Destination Extension Headers contain a bit that indicates whether the option might change (unpredictably) during transit. For any option for which contents may change en-route, the entire "Option Data" field must be treated as zero-valued octets when computing or verifying the ICV. The Option Type and Opt Data Len are included in the ICV calculation. All options for which the bit indicates immutability are included in the ICV calculation. See the IPv6 specification [DH95] for more information.
オプション-ホップバイホップおよび宛先拡張ヘッダーのIPv6オプションには、転送中にオプションが（予期せずに）変更される可能性があるかどうかを示すビットが含まれています。途中で内容が変更される可能性のあるオプションについては、ICVを計算または検証するときに、「オプションデータ」フィールド全体をゼロ値のオクテットとして扱う必要があります。オプションタイプとオプションデータレンは、ICV計算に含まれます。ビットが不変性を示すすべてのオプションは、ICV計算に含まれます。詳細については、IPv6仕様[DH95]を参照してください。
Routing (Type 0) -- The IPv6 Routing Header "Type 0" will rearrange the address fields within the packet during transit from source to destination. However, the contents of the packet as it will appear at the receiver are known to the sender and to all intermediate hops. Hence, the IPv6 Routing Header "Type 0" is included in the Authentication Data calculation as mutable but predictable. The sender must order the field so that it appears as it will at the receiver, prior to performing the ICV computation.
ルーティング（タイプ0）-IPv6ルーティングヘッダー「タイプ0」は、送信元から宛先への転送中にパケット内のアドレスフィールドを再配置します。ただし、受信側に表示されるパケットの内容は、送信側とすべての中間ホップで認識されます。したがって、IPv6ルーティングヘッダー「タイプ0」は変更可能ですが予測可能として認証データの計算に含まれます。送信者は、ICV計算を実行する前に、フィールドを受信者に表示されるように順序付ける必要があります。
Fragmentation -- Fragmentation occurs after outbound IPsec processing (section 3.3) and reassembly occurs before inbound IPsec processing (section 3.4). So the Fragmentation Extension Header, if it exists, is not seen by IPsec.
断片化-断片化はアウトバウンドIPsec処理（セクション3.3）の後に発生し、リアセンブリはインバウンドIPsec処理（セクション3.4）の前に発生します。そのため、Fragmentation Extensionヘッダーが存在しても、IPsecからは見えません。
Note that on the receive side, the IP implementation could leave a Fragmentation Extension Header in place when it does re-assembly. If this happens, then when AH receives the packet, before doing ICV processing, AH MUST "remove" (or skip over) this header and change the previous header's "Next Header" field to be the "Next Header" field in the Fragmentation Extension Header.
受信側では、IP実装が再構成を行うときにFragmentation Extensionヘッダーをそのまま残しておく可能性があることに注意してください。これが発生した場合、AHがパケットを受信すると、ICV処理を実行する前に、このヘッダーを「削除」（またはスキップ）し、前のヘッダーの「次のヘッダー」フィールドをフラグメント拡張の「次のヘッダー」フィールドに変更する必要があります。ヘッダ。
Note that on the send side, the IP implementation could give the IPsec code a packet with a Fragmentation Extension Header with Offset of 0 (first fragment) and a More Fragments Flag of 0 (last fragment). If this happens, then before doing ICV processing, AH MUST first "remove" (or skip over) this header and change the previous header's "Next Header" field to be the "Next Header" field in the Fragmentation Extension Header.
送信側では、IP実装がIPsecコードに、オフセットが0（最初のフラグメント）のFragmentation Extensionヘッダーと0のMore Fragments Flag（最後のフラグメント）を持つパケットを与えることに注意してください。これが発生した場合、ICV処理を行う前に、AHはまずこのヘッダーを「削除」（またはスキップ）し、前のヘッダーの「次のヘッダー」フィールドをFragmentation Extensionヘッダーの「次のヘッダー」フィールドに変更する必要があります。
References
参考文献
[ATK95] Atkinson, R., "The IP Authentication Header", RFC 1826, August 1995.
[ATK95] Atkinson、R。、「The IP Authentication Header」、RFC 1826、1995年8月。
[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月。
[DH95] Deering, S., and B. Hinden, "Internet Protocol version 6 (IPv6) Specification", RFC 1883, December 1995.
[DH95] Deering、S。、およびB. Hinden、「インターネットプロトコルバージョン6（IPv6）仕様」、RFC 1883、1995年12月。
[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月。
[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 Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[KA97b]ケント、S。、およびR.アトキンソン、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、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
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
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。