[要約] RFC 4302は、IP Authentication Header (AH)に関する文書で、IPパケットの完全性とデータの起源認証を保証するためのメカニズムを定義しています。このプロトコルは、送信者が送ったデータが改ざんされずに受信者に届くことを保証し、また、データが確かに送信者から来たものであることを確認するために使用されます。主にVPNやIPsecプロトコルスイートの一部として利用されます。関連するRFCにはRFC 2401（IPsecのアーキテクチャを定義）、RFC 2406（IP Encapsulating Security Payload (ESP)）、RFC 4301（IPsecのセキュリティアーキテクチャ）などがあります。
Network Working Group S. Kent
Request for Comments: 4302 BBN Technologies
Obsoletes: 2402 December 2005
Category: Standards Track
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 (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document obsoletes RFC 2402 (November 1998).
このドキュメントでは、IPv4およびIPv6で認証サービスを提供するように設計されたIP認証ヘッダー（AH）の更新バージョンについて説明します。このドキュメントは、RFC 2402を廃止します（1998年11月）。
Table of Contents
目次
1. Introduction ....................................................3
2. Authentication Header Format ....................................4
2.1. Next Header ................................................5
2.2. Payload Length .............................................5
2.3. Reserved ...................................................6
2.4. Security Parameters Index (SPI) ............................6
2.5. Sequence Number ............................................8
2.5.1. Extended (64-bit) Sequence Number ...................8
2.6. Integrity Check Value (ICV) ................................9
3. Authentication Header Processing ................................9
3.1. Authentication Header Location .............................9
3.1.1. Transport Mode ......................................9
3.1.2. Tunnel Mode ........................................11
3.2. Integrity Algorithms ......................................11
3.3. Outbound Packet Processing ................................11
3.3.1. Security Association Lookup ........................12
3.3.2. Sequence Number Generation .........................12
3.3.3. Integrity Check Value Calculation ..................13
3.3.3.1. Handling Mutable Fields ...................13
3.3.3.2. Padding and Extended Sequence Numbers .....16
3.3.4. Fragmentation ......................................17
3.4. Inbound Packet Processing .................................18
3.4.1. Reassembly .........................................18
3.4.2. Security Association Lookup ........................18
3.4.3. Sequence Number Verification .......................19
3.4.4. Integrity Check Value Verification .................20
4. Auditing .......................................................21
5. Conformance Requirements .......................................21
6. Security Considerations ........................................22
7. Differences from RFC 2402 ......................................22
8. Acknowledgements ...............................................22
9. References .....................................................22
9.1. Normative References ......................................22
9.2. Informative References ....................................23
Appendix A: Mutability of IP Options/Extension Headers ............25
A1. IPv4 Options ...............................................25
A2. IPv6 Extension Headers .....................................26
Appendix B: Extended (64-bit) Sequence Numbers ....................28
B1. Overview ...................................................28
B2. Anti-Replay Window .........................................28
B2.1. Managing and Using the Anti-Replay Window ............29
B2.2. Determining the Higher-Order Bits (Seqh) of the
Sequence Number ......................................30
B2.3. Pseudo-Code Example ..................................31
B3. Handling Loss of Synchronization due to Significant
Packet Loss ................................................32
B3.1. Triggering Re-synchronization ........................33
B3.2. Re-synchronization Process ...........................33
This document assumes that the reader is familiar with the terms and concepts described in the "Security Architecture for the Internet Protocol" [Ken-Arch], hereafter referred to as the Security Architecture document. In particular, the reader should be familiar with the definitions of security services offered by the Encapsulating Security Payload (ESP) [Ken-ESP] and the IP Authentication Header (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.
このドキュメントは、読者が「インターネットプロトコルのセキュリティアーキテクチャ」[Ken-Arch]に記載されている用語と概念に精通していることを前提としています。特に、読者は、セキュリティペイロード（ESP）[KEN-ESP]とIP認証ヘッダー（AH）によって提供されるセキュリティサービスの定義に精通している必要があります。Authentication Header（AH）と組み合わせて使用され、ESPおよびAHで利用可能なさまざまな主要な管理オプション。
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].
キーワードは、このドキュメントに表示される場合、RFC 2119 [bra97]に記載されているように解釈される場合、必要な、必須、必要は、推奨、推奨、勧めてはいけません。
The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just "integrity") and to provide protection against replays. This latter, optional service may be selected, by the receiver, when a Security Association (SA) is established. (The protocol default requires the sender to increment the sequence number used for anti-replay, but the service is effective only if the receiver checks the sequence number.) However, to make use of the Extended Sequence Number feature in an interoperable fashion, AH does impose a requirement on SA management protocols to be able to negotiate this new feature (see Section 2.5.1 below).
IP認証ヘッダー（AH）は、IPデータグラムのコネクションレスの整合性とデータオリジン認証を提供するために使用されます（以下、単なる「整合性」と呼ばれます）、リプレイに対する保護を提供します。セキュリティ協会（SA）が確立されると、この後者のオプションサービスが受信者によって選択される場合があります。（プロトコルのデフォルトでは、送信者がアンチレプレイに使用されるシーケンス番号をインクリメントする必要がありますが、レシーバーがシーケンス番号をチェックする場合にのみサービスは効果的です。）ただし、相互運用可能な方法で拡張シーケンス番号機能を使用するために、AHこの新しい機能を交渉できるように、SA管理プロトコルに要件を課しています（以下のセクション2.5.1を参照）。
AH provides authentication for as much of the IP header as possible, as well as for next 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 piecemeal. (See Appendix A.)
AHは、できるだけ多くのIPヘッダーに、および次のレベルのプロトコルデータに認証を提供します。ただし、一部のIPヘッダーフィールドは輸送が変化する場合があり、これらのフィールドの値は、パケットが受信機に到着すると、送信者が予測できない場合があります。そのようなフィールドの値は、AHで保護することはできません。したがって、AHによってIPヘッダーに提供される保護は断片的です。（付録Aを参照）
AH may be applied alone, in combination with the IP Encapsulating Security Payload (ESP) [Ken-ESP], or in a nested fashion (see Security Architecture document [Ken-Arch]). 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 anti-replay and similar integrity services, and it also provides a confidentiality (encryption) service. The primary difference between the integrity 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 (e.g., via use of tunnel mode). For more details on how to use AH and ESP in various network environments, see the Security Architecture document [Ken-Arch].
AHは、セキュリティペイロード（ESP）[Ken-esp]をカプセル化するIPと組み合わせて、またはネストされた方法で単独で適用できます（セキュリティアーキテクチャドキュメント[Ken-Arch]を参照）。セキュリティサービスは、通信ホストのペア間、セキュリティゲートウェイの通信のペア、またはセキュリティゲートウェイとホストの間で提供できます。ESPは、同じアンチレプレイと同様の整合性サービスを提供するために使用される場合があり、機密性（暗号化）サービスも提供します。ESPとAHによって提供される整合性の主な違いは、カバレッジの範囲です。具体的には、ESPは、これらのフィールドがESPによってカプセル化されない限り（たとえば、トンネルモードの使用による）IPヘッダーフィールドを保護しません。さまざまなネットワーク環境でAHとESPを使用する方法の詳細については、セキュリティアーキテクチャドキュメント[Ken-Arch]を参照してください。
Section 7 provides a brief review of the differences between this document and RFC 2402 [RFC2402].
セクション7では、このドキュメントとRFC 2402 [RFC2402]の違いの簡単なレビューを提供します。
The protocol header (IPv4, IPv6, or IPv6 Extension) immediately preceding the AH header SHALL contain the value 51 in its Protocol (IPv4) or Next Header (IPv6, Extension) fields [DH98]. Figure 1 illustrates the format for AH.
AHヘッダーの直前のプロトコルヘッダー（IPv4、IPv6、またはIPv6拡張）には、そのプロトコル（IPv4）または次のヘッダー（IPv6、拡張）フィールドに値51が含まれます[DH98]。図1は、AHの形式を示しています。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Integrity Check Value-ICV (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. AH Format
図1. AH形式
The following table refers to the fields that comprise AH,
(illustrated in Figure 1), plus other fields included in the
integrity computation, and illustrates which fields are covered by
the ICV and what is transmitted.
What What
# of Requ'd Integ is
bytes [1] Covers Xmtd
------ ------ ------ ------
IP Header variable M [2] plain
Next Header 1 M Y plain
Payload Len 1 M Y plain
RESERVED 2 M Y plain
SPI 4 M Y plain
Seq# (low-order 32 bits) 4 M Y plain
ICV variable M Y[3] plain
IP datagram [4] variable M Y plain
Seq# (high-order 32 bits) 4 if ESN Y not xmtd
ICV Padding variable if need Y not xmtd
[1] - M = mandatory
[2] - See Section 3.3.3, "Integrity Check Value Calculation", for
details of which IP header fields are covered.
[3] - Zeroed before ICV calculation (resulting ICV placed here
after calculation)
[4] - If tunnel mode -> IP datagram
If transport mode -> next header and data
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を参照）。
Note: All of the cryptographic algorithms used in IPsec expect their input in canonical network byte order (see Appendix of RFC 791 [RFC791]) and generate their output in canonical network byte order. IP packets are also transmitted in network byte order.
注：IPSECで使用されるすべての暗号化アルゴリズムは、標準的なネットワークバイト順序での入力を期待しています（RFC 791 [RFC791]の付録を参照））。IPパケットもネットワークバイトの順序で送信されます。
AH does not contain a version number, therefore if there are concerns about backward compatibility, they MUST be addressed by using a signaling mechanism between the two IPsec peers to ensure compatible versions of AH, e.g., IKE [IKEv2] or an out-of-band configuration mechanism.
AHにはバージョン番号が含まれていないため、後方互換性について懸念がある場合は、2つのIPSECピア間のシグナル伝達メカニズムを使用して、互換性のあるバージョン、たとえばIKE [IKEV2]またはOut-Of-of-Of-Of-Of-Of-Of-Ofを確保することで対処する必要があります。バンド構成メカニズム。
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 on the web page of Internet Assigned Numbers Authority (IANA). For example, a value of 4 indicates IPv4, a value of 41 indicates IPv6, and a value of 6 indicates TCP.
次のヘッダーは、認証ヘッダー後の次のペイロードのタイプを識別する8ビットフィールドです。このフィールドの値は、Internet Assigned Numbers Authority（IANA）のWebページで定義されたIPプロトコル番号のセットから選択されます。たとえば、4の値はIPv4、41の値はIPv6を示し、6の値はTCPを示します。
This 8-bit field specifies the length of AH in 32-bit words (4-byte units), minus "2". Thus, for example, if an integrity algorithm yields a 96-bit authentication value, this length field will be "4" (3 32-bit word fixed fields plus 3 32-bit words for the ICV, minus 2). For IPv6, the total length of the header must be a multiple of 8-octet units. (Note that although IPv6 [DH98] characterizes AH as an extension header, its length is measured in 32-bit words, not the 64-bit words used by other IPv6 extension headers.) See Section 2.6, "Integrity Check Value (ICV)", for comments on padding of this field, and Section 3.3.3.2.1, "ICV Padding".
この8ビットフィールドは、32ビット単語（4バイト単位）、マイナス「2」でAHの長さを指定します。したがって、たとえば、整合性アルゴリズムが96ビット認証値を生成する場合、この長さフィールドは「4」（3 32ビット単語固定フィールドとICVの3 32ビット単語、マイナス2）になります。IPv6の場合、ヘッダーの全長は8オクテットのユニットの倍数でなければなりません。（IPv6 [DH98]はAHを拡張ヘッダーとして特徴づけているが、その長さは他のIPv6拡張ヘッダーで使用される64ビット語ではなく、32ビット語で測定されることに注意してください。）セクション2.6、「Integrity Check値（ICV）「このフィールドのパディングに関するコメント、およびセクション3.3.3.2.1、「ICVパディング」。
This 16-bit field is reserved for future use. It MUST be set to "zero" by the sender, and it SHOULD be ignored by the recipient. (Note that the value is included in the ICV calculation, but is otherwise ignored by the recipient.)
この16ビットフィールドは、将来の使用のために予約されています。送信者によって「ゼロ」に設定する必要があり、受信者は無視する必要があります。（値はICV計算に含まれているが、それ以外の場合は受信者によって無視されることに注意してください。）
The SPI is an arbitrary 32-bit value that is used by a receiver to identify the SA to which an incoming packet is bound. For a unicast SA, the SPI can be used by itself to specify an SA, or it may be used in conjunction with the IPsec protocol type (in this case AH). Because for unicast SAs the SPI value is generated by the receiver, whether the value is sufficient to identify an SA by itself or whether it must be used in conjunction with the IPsec protocol value is a local matter. The SPI field is mandatory, and this mechanism for mapping inbound traffic to unicast SAs described above MUST be supported by all AH implementations.
SPIは、受信機が使用する任意の32ビット値であり、着信パケットがバインドされるSAを識別します。ユニキャストSAの場合、SPIはSAを指定するために単独で使用できます。または、IPSECプロトコルタイプ（この場合はAH）と組み合わせて使用できます。ユニキャストSASの場合、SPI値はレシーバーによって生成されるため、値がSAを単独で識別するのに十分であるかどうか、またはIPSECプロトコル値と併用する必要があるかどうかはローカルな問題です。SPIフィールドは必須であり、上記のユニキャストSASへのインバウンドトラフィックをマッピングするためのこのメカニズムは、すべてのAH実装によってサポートされなければなりません。
If an IPsec implementation supports multicast, then it MUST support multicast SAs using the algorithm below for mapping inbound IPsec datagrams to SAs. Implementations that support only unicast traffic need not implement this de-multiplexing algorithm.
IPSECの実装がマルチキャストをサポートする場合、インバウンドIPSECデータグラムをSASにマッピングするために、以下のアルゴリズムを使用してマルチキャストSASをサポートする必要があります。ユニキャストトラフィックのみをサポートする実装では、この脱倍化アルゴリズムを実装する必要はありません。
In many secure multicast architectures, e.g., [RFC3740], a central Group Controller/Key Server unilaterally assigns the group security association's SPI. This SPI assignment is not negotiated or coordinated with the key management (e.g., IKE) subsystems that reside in the individual end systems that comprise the group. Consequently, it is possible that a group security association and a unicast security association can simultaneously use the same SPI. A multicast-capable IPsec implementation MUST correctly de-multiplex inbound traffic even in the context of SPI collisions.
多くの安全なマルチキャストアーキテクチャなど、[RFC3740]、中央グループコントローラー/キーサーバーがグループセキュリティ協会のSPIを一方的に割り当てます。このSPIの割り当ては、グループを構成する個々のエンドシステムに存在する主要な管理（IKE）サブシステムと交渉または調整されていません。その結果、グループセキュリティ協会とユニキャストセキュリティ協会が同時に同じSPIを使用できる可能性があります。マルチキャスト利用可能なIPSECの実装は、SPI衝突のコンテキストでも、インバウンドトラフィックを正しく脱化する必要があります。
Each entry in the Security Association Database (SAD) [Ken-Arch] must indicate whether the SA lookup makes use of the destination, or destination and source, IP addresses, in addition to the SPI. For multicast SAs, the protocol field is not employed for SA lookups. For each inbound, IPsec-protected packet, an implementation must conduct its search of the SAD such that it finds the entry that matches the "longest" SA identifier. In this context, if two or more SAD entries match based on the SPI value, then the entry that also matches based on destination, or destination and source, address comparison (as indicated in the SAD entry) is the "longest" match. This implies a logical ordering of the SAD search as follows:
Security Association Database（SAD）[Ken-Arch]の各エントリは、SAルックアップがSPIに加えて宛先または宛先とソースのIPアドレスを利用するかどうかを示す必要があります。マルチキャストSASの場合、SAルックアップにはプロトコルフィールドが使用されていません。IPSECで保護された各パケットについて、実装は、「最も長い」SA識別子と一致するエントリを見つけるように、SADの検索を実施する必要があります。これに関連して、SPI値に基づいて2つ以上のSADエントリが一致する場合、宛先または宛先とソースに基づいて一致するエントリ（SADエントリに示されているように）が「最長」の一致です。これは、次のように悲しい検索の論理的な順序を意味します。
1. Search the SAD for a match on {SPI, destination address, source address}. If an SAD entry matches, then process the inbound AH packet with that matching SAD entry. Otherwise, proceed to step 2.
1. {spi、宛先アドレス、ソースアドレス}の一致を悲しみを検索します。悲しいエントリが一致する場合は、その一致する悲しいエントリでインバウンドAHパケットを処理します。それ以外の場合は、ステップ2に進みます。
2. Search the SAD for a match on {SPI, destination address}. If an SAD entry matches, then process the inbound AH packet with that matching SAD entry. Otherwise, proceed to step 3.
2. {spi、宛先アドレス}の試合を悲しみを検索します。悲しいエントリが一致する場合は、その一致する悲しいエントリでインバウンドAHパケットを処理します。それ以外の場合は、ステップ3に進みます。
3. Search the SAD for a match on only {SPI} if the receiver has chosen to maintain a single SPI space for AH and ESP, or on {SPI, protocol} otherwise. If an SAD entry matches, then process the inbound AH packet with that matching SAD entry. Otherwise, discard the packet and log an auditable event.
3. ReceiverがAHとESPの単一のSPIスペースを維持するか、{SPI、プロトコル}で維持することを選択した場合、{SPI}のみの試合を検索してください。悲しいエントリが一致する場合は、その一致する悲しいエントリでインバウンドAHパケットを処理します。それ以外の場合は、パケットを破棄し、監査可能なイベントを記録します。
In practice, an implementation MAY choose any method to accelerate this search, although its externally visible behavior MUST be functionally equivalent to having searched the SAD in the above order. For example, a software-based implementation could index into a hash table by the SPI. The SAD entries in each hash table bucket's linked list are kept sorted to have those SAD entries with the longest SA identifiers first in that linked list. Those SAD entries having the shortest SA identifiers are sorted so that they are the last entries in the linked list. A hardware-based implementation may be able to effect the longest match search intrinsically, using commonly available Ternary Content-Addressable Memory (TCAM) features.
実際には、実装はこの検索を加速する方法を選択する場合がありますが、その外部的に表示される動作は、上記の順序でSADを検索することと機能的に同等でなければなりません。たとえば、ソフトウェアベースの実装は、SPIによってハッシュテーブルにインデックスを付けることができます。各ハッシュテーブルバケットのリンクリストの悲しいエントリは、そのリンクリストで最初に最初に最も長いSA識別子を持つこれらの悲しいエントリを持つように並べ替えられます。最短のSA識別子を持つこれらの悲しいエントリは、リンクリストの最後のエントリであるようにソートされます。ハードウェアベースの実装は、一般的に利用可能な3成分アドレス可能なメモリ（TCAM）機能を使用して、本質的に最長の一致検索に影響を与えることができる場合があります。
The indication of whether source and destination address matching is required to map inbound IPsec traffic to SAs MUST be set either as a side effect of manual SA configuration or via negotiation using an SA management protocol, e.g., IKE or Group Domain of Interpretation (GDOI) [RFC3547]. Typically, Source-Specific Multicast (SSM) [HC03] groups use a 3-tuple SA identifier composed of an SPI, a destination multicast address, and source address. An Any-Source Multicast group SA requires only an SPI and a destination multicast address as an identifier.
INBOUND IPSECトラフィックをSASにマッピングするためにソースと宛先アドレスのマッチングが必要かどうかを示すことは、SAマネジメントプロトコルなど、IKEまたはグループドメインの解釈（GDOI）を使用したネゴシエーションを使用して、マニュアルSA構成の副作用として設定する必要があります。[RFC3547]。通常、ソース固有のマルチキャスト（SSM）[HC03]グループは、SPI、宛先マルチキャストアドレス、およびソースアドレスで構成される3タプルSA識別子を使用します。任意のソースマルチキャストグループSAには、識別子としてSPIと宛先マルチキャストアドレスのみが必要です。
The set of SPI values in the range 1 through 255 is 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. 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 might 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.)
範囲1〜255のSPI値のセットは、将来の使用のためにインターネットに割り当てられた数字の権限（IANA）によって予約されています。割り当てられたSPI値の使用がRFCで指定されていない限り、予約されたSPI値は通常IANAによって割り当てられません。ゼロ（0）のSPI値は、ローカルの実装固有の使用のために予約されており、ワイヤーに送信してはなりません。（たとえば、主要な管理実装では、ゼロSPI値を使用して、IPSECの実装が主要な管理エンティティが新しいSAを確立するように要求したが、SAはまだ確立されていない期間中に「セキュリティ協会が存在しない」ことを意味する場合があります。））
This unsigned 32-bit field contains a counter value that increases by one for each packet sent, i.e., a per-SA packet sequence number. For a unicast SA or a single-sender multicast SA, the sender MUST increment this field for every transmitted packet. Sharing an SA among multiple senders is permitted, though generally not recommended. AH provides no means of synchronizing packet counters among multiple senders or meaningfully managing a receiver packet counter and window in the context of multiple senders. Thus, for a multi-sender SA, the anti-reply features of AH are not available (see Sections 3.3.2 and 3.4.3).
この署名されていない32ビットフィールドには、送信されるパケットごとに1つずつ増加するカウンター値、つまりSAあたりのパケットシーケンス番号が含まれています。ユニキャストSAまたはシングルセンダーマルチキャストSAの場合、送信者は、送信されたパケットごとにこのフィールドを増やす必要があります。複数の送信者間でSAを共有することは許可されていますが、一般的には推奨されません。AHは、複数の送信者の間でパケットカウンターを同期させたり、複数の送信者のコンテキストで受信機パケットカウンターとウィンドウを有意義に管理したりする手段を提供しません。したがって、マルチセンダーSAの場合、AHの反復機能は利用できません（セクション3.3.2および3.4.3を参照）。
The field is mandatory and MUST always be 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, but all AH implementations MUST be capable of performing the processing described in Section 3.3.2, "Sequence Number Generation", and Section 3.4.3, "Sequence Number Verification". Thus, the sender MUST always transmit this field, but the receiver need not act upon it.
フィールドは必須であり、受信者が特定のSAのアンチレプレイサービスを有効にすることを選択していなくても、常に存在する必要があります。シーケンス番号フィールドの処理は受信機の裁量にありますが、すべてのAH実装は、セクション3.3.2、「シーケンス番号生成」、およびセクション3.4.3、「シーケンス番号検証」で説明されている処理を実行できなければなりません。したがって、送信者は常にこのフィールドを送信する必要がありますが、受信機はそれに基づいて動作する必要はありません。
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^32ndパケットを送信する前に（新しいSAと新しいキーを確立することにより）リセットする必要があります。
To support high-speed IPsec implementations, a new option for sequence numbers SHOULD be offered, as an extension to the current, 32-bit sequence number field. Use of an Extended Sequence Number (ESN) MUST be negotiated by an SA management protocol. Note that in IKEv2, this negotiation is implicit; the default is ESN unless 32-bit sequence numbers are explicitly negotiated. (The ESN feature is applicable to multicast as well as unicast SAs.)
高速IPSEC実装をサポートするには、現在の32ビットシーケンス番号フィールドへの拡張として、シーケンス番号の新しいオプションを提供する必要があります。拡張シーケンス番号（ESN）の使用は、SA管理プロトコルによって交渉する必要があります。IKEV2では、この交渉は暗黙的であることに注意してください。32ビットシーケンス番号が明示的にネゴシエートされない限り、デフォルトはESNです。（ESN機能は、マルチキャストおよびユニキャストSASに適用できます。）
The ESN facility allows use of a 64-bit sequence number for an SA. (See Appendix B, "Extended (64-bit) Sequence Numbers", for details.) Only the low-order 32 bits of the sequence number are transmitted in the AH header of each packet, thus minimizing packet overhead. The high-order 32 bits are maintained as part of the sequence number counter by both transmitter and receiver and are included in the computation of the ICV, but are not transmitted.
ESN施設では、SAに64ビットシーケンス番号を使用できます。（詳細については、付録B、「拡張（64ビット）シーケンス番号」を参照してください。）各パケットのAHヘッダーには、低次の32ビットのシーケンス番号のみが送信されるため、パケットオーバーヘッドを最小限に抑えます。高次の32ビットは、送信機と受信機の両方によってシーケンス番号カウンターの一部として維持され、ICVの計算に含まれていますが、送信されません。
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 (IPv4 or IPv6) in length. The details of ICV processing are described in Section 3.3.3, "Integrity Check Value Calculation", and Section 3.4.4, "Integrity Check Value Verification". This field may include explicit padding, if required 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 and MUST insert only enough padding to satisfy the IPv4/IPv6 alignment requirements. Details of how to compute the required padding length are provided below in Section 3.3.3.2, "Padding". The integrity algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation.
これは、このパケットの整合性チェック値（ICV）を含む可変長さのフィールドです。フィールドは、長さが32ビット（IPv4またはIPv6）の積分倍でなければなりません。ICV処理の詳細は、セクション3.3.3、「整合性チェック値の計算」、およびセクション3.4.4、「整合性チェック値の検証」で説明されています。このフィールドには、AHヘッダーの長さが32ビット（IPv4）または64ビット（IPv6）の積分倍であることを確認するために必要な場合、明示的なパディングが含まれる場合があります。すべての実装は、そのようなパディングをサポートする必要があり、IPv4/IPv6アライメント要件を満たすのに十分なパディングのみを挿入する必要があります。必要なパディングの長さを計算する方法の詳細は、セクション3.3.3.2「パディング」に以下に示されています。整合性アルゴリズムの仕様は、ICVの長さと、検証のための比較ルールと処理手順を指定する必要があります。
AH may be employed in two ways: transport mode or tunnel mode. (See the Security Architecture document for a description of when each should be used.)
AHは、輸送モードまたはトンネルモードの2つの方法で採用される場合があります。（それぞれを使用する時期の説明については、セキュリティアーキテクチャドキュメントを参照してください。）
In transport mode, AH is inserted after the IP header and before a next 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 next layer protocol. (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP.) The following diagram illustrates AH transport mode positioning for a typical IPv4 packet, on a "before and after" basis.
トランスポートモードでは、AHはIPヘッダーの後、次のレイヤープロトコル（TCP、UDP、ICMPなど）の前、または既に挿入されている他のIPSECヘッダーの前に挿入されます。IPv4のコンテキストでは、これはIPヘッダー（および含まれるオプション）の後にAHを配置する必要がありますが、次のレイヤープロトコルの前にあります。（「輸送」モードという用語は、その使用をTCPとUDPに制限するものとして誤解されるべきではないことに注意してください。）次の図は、「前後」に基づいて、典型的なIPv4パケットのAH輸送モードの位置付けを示しています。
BEFORE APPLYING AH
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING AH
-------------------------------------------------------
IPv4 |original IP hdr (any options) | AH | TCP | Data |
-------------------------------------------------------
|<- mutable field processing ->|<- immutable fields ->|
|<----- 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 before or after or both before and 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 |
------------------------------------------------------------
|<--- mutable field processing -->|<-- immutable fields -->|
|<---- authenticated except for mutable fields ----------->|
* = if present, could be before AH, after AH, or both
* =存在する場合は、ああ、ああ、またはその両方の前にいる可能性があります
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アーキテクチャドキュメントでは、サポートする必要があるセキュリティ協会の組み合わせについて説明しています。
Note that in transport mode, 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.
トランスポートモードでは、セキュリティアーキテクチャドキュメントで定義されているように、「バンプインザスタック」または「バンプインザワイヤ」実装の場合、インバウンドおよびアウトバウンドIPフラグメントが必要になる場合があることに注意してください。この仕様に適合し、透明なIPSECサポートを提供するために、再組み立て/断片化。複数のインターフェイスが使用されている場合、これらの実装内でそのような操作を実行するには、特別な注意が必要です。
In tunnel mode, the "inner" IP header carries the ultimate (IP) source and destination addresses, while an "outer" IP header contains the addresses of the IPsec "peers," e.g., addresses of security gateways. Mixed inner and outer IP versions are allowed, i.e., IPv6 over IPv4 and IPv4 over IPv6. 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.
トンネルモードでは、「内側」のIPヘッダーには究極の（IP）ソースと宛先アドレスが搭載されていますが、「外側」IPヘッダーには、IPSECの「ピア」のアドレス（セキュリティゲートウェイのアドレス」が含まれています。混合内のIPバージョン、つまりIPv4を介したIPv6およびIPv6を介してIPv6を混合しています。トンネルモードでは、AHは内側のIPヘッダー全体を含む内側のIPパケット全体を保護します。外側のIPヘッダーと比較して、トンネルモードでのAHの位置は、輸送モードのAHの場合と同じです。次の図は、典型的なIPv4およびIPv6パケットのAHトンネルモードの位置を示しています。
----------------------------------------------------------------
IPv4 | | | orig IP hdr* | | |
|new IP header * (any options) | AH | (any options) |TCP| Data |
----------------------------------------------------------------
|<- mutable field processing ->|<------ immutable fields ----->|
|<- 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|
--------------------------------------------------------------
|<--- mutable field -->|<--------- immutable fields -------->|
| processing |
|<-- authenticated except for mutable fields in new IP hdr ->|
* = if present, construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed in the Security Architecture document.
* =存在する場合、外側のIP HDR/拡張機能の構築と内部IP HDR/拡張機能の変更については、セキュリティアーキテクチャドキュメントで説明します。
The integrity algorithm employed for the ICV computation is specified by the SA. For point-to-point communication, suitable integrity algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., AES [AES]) or on one-way hash functions (e.g., MD5, SHA-1, SHA-256, etc.). For multicast communication, a variety of cryptographic strategies for providing integrity have been developed and research continues in this area.
ICV計算に使用される整合性アルゴリズムは、SAによって指定されています。ポイントツーポイント通信の場合、適切な整合性アルゴリズムには、対称暗号化アルゴリズム（AES [AES]）または一方向ハッシュ関数（MD5、SHA-1、SHA-に基づくキー付きメッセージ認証コード（MAC）が含まれます。256など）。マルチキャストコミュニケーションのために、整合性を提供するためのさまざまな暗号化戦略が開発され、この分野では研究が継続されています。
In transport mode, the sender inserts the AH header after the IP header and before a next layer protocol header, as described above. In tunnel mode, the outer and inner IP header/extensions can be interrelated 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ヘッダー/拡張機能の構築については、セキュリティアーキテクチャドキュメントで説明します。
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は、IPSECの実装により、パケットがAH処理を必要とするSAに関連付けられていると判断した後にのみ、アウトバウンドパケットに適用されます。IPSEC処理がアウトバウンドトラフィックに適用されるものを決定するプロセスは、セキュリティアーキテクチャドキュメントで説明されています。
The sender's counter is initialized to 0 when an SA is established. The sender increments the sequence number (or ESN) counter for this SA and inserts the low-order 32 bits of the value into the Sequence Number field. Thus, the first packet sent using a given SA will contain a sequence number of 1.
送信者のカウンターは、SAが確立されたときに0に初期化されます。送信者は、このSAのシーケンス番号（またはESN）カウンターを増分し、値の32ビットをシーケンス番号フィールドに挿入します。したがって、特定の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. The audit log entry for this event SHOULD include the SPI value, current date/time, Source Address, Destination Address, and (in IPv6) the cleartext Flow ID.
アンチレプレイが有効になっている場合（デフォルト）、送信者はシーケンス番号フィールドに新しい値を挿入する前にカウンターが循環していないことを確認します。言い換えれば、送信者は、SAにパケットを送信してはなりません。シーケンス数のオーバーフローをもたらすパケットを送信しようとする試みは、監査可能なイベントです。このイベントの監査ログエントリには、SPI値、現在の日付/時間、ソースアドレス、宛先アドレス、および（IPv6で）クリアテキストフローIDを含める必要があります。
The sender assumes anti-replay is enabled as a default, unless otherwise notified by the receiver (see Section 3.4.3) or if the SA was configured using manual key management. Thus, typical behavior of an AH implementation calls for the sender to establish a new SA when the Sequence Number (or ESN) cycles, or in anticipation of this value cycling.
送信者は、レシーバーから特に通知されない限り（セクション3.4.3を参照）、またはManual Key Managementを使用してSAが構成されている場合を除き、アンチレプレイがデフォルトとして有効になることを想定します。したがって、AH実装の典型的な動作では、シーケンス番号（またはESN）サイクルのときに新しいSAを確立するために、またはこの値サイクリングを予想して送信者が新しいSAを確立する必要があります。
If anti-replay is disabled (as noted above), 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. (This behavior is recommended for multi-sender, multicast SAs, unless anti-replay mechanisms outside the scope of this standard are negotiated between the sender and receiver.)
アンチレプレイが無効になっている場合（上記のように）、送信者はカウンターを監視またはリセットする必要はありません。たとえば、手動キー管理の場合（セクション5を参照）。ただし、送信者は引き続きカウンターを増分し、最大値に達すると、カウンターはゼロに戻ります。（この標準の範囲外のアンチレプレイメカニズムが送信者と受信機の間で交渉されない限り、この動作はマルチセンダー、マルチキャストSASに推奨されます。）
If ESN (see Appendix B) is selected, only the low-order 32 bits of the sequence number are transmitted in the Sequence Number field, although both sender and receiver maintain full 64-bit ESN counters. However, the high-order 32 bits are included in the ICV calculation.
ESN（付録Bを参照）が選択されている場合、シーケンス番号フィールドに低次の32ビットのみがシーケンス番号フィールドに送信されますが、送信者と受信機の両方が完全な64ビットESNカウンターを維持しています。ただし、高次の32ビットはICV計算に含まれています。
Note: If a receiver chooses not to enable anti-replay for an SA, then the receiver SHOULD NOT negotiate ESN in an SA management protocol. Use of ESN creates a need for the receiver to manage the anti-replay window (in order to determine the correct value for the high-order bits of the ESN, which are employed in the ICV computation), which is generally contrary to the notion of disabling anti-replay for an SA.
注：レシーバーがSAのアンチレプレイを有効にしないことを選択した場合、レシーバーはSA管理プロトコルでESNをネゴシエートしてはなりません。ESNを使用すると、受信者がアンチレプレイウィンドウを管理する必要があります（ICV計算で使用されているESNの高次ビットの正しい値を決定するため）。これは一般に概念に反しています。SAのアンチレプレイを無効にする。
The AH ICV is computed over:
AH ICVは計算されます：
o IP or extension header fields before the AH header 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 (low-order 32 bits), and the ICV (which is set to zero for this computation), and explicit padding bytes (if any)) o everything after AH is assumed to be immutable in transit o the high-order bits of the ESN (if employed), and any implicit padding required by the integrity algorithm
o AHヘッダー（次のヘッダー、ペイロードレン、予約済み、SPI、シーケンス番号）のエンドポイントに到着すると予測可能なAHヘッダーの前のIPまたは拡張ヘッダーフィールド32ビットを注文）、およびICV（この計算でゼロに設定）、および明示的なパディングバイト（もしあれば））採用）、および整合性アルゴリズムで必要な暗黙のパディング
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 Integrity Check Value 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 the Hop-by-Hop Extension Header) contain a flag indicating mutability, which determines appropriate processing for such options.
新しいエクステンションヘッダーまたはIPv4オプションが作成されると、独自のRFCで定義され、AH ICVの計算時にどのように処理するかについての（セキュリティに関する考慮事項セクション）指示を含める必要があります。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) Differentiated Services Code Point (DSCP) (6 bits, see RFC 2474 [NBBB98]) Explicit Congestion Notification (ECN) (2 bits, see RFC 3168 [RFB01]) Flags Fragment Offset Time to Live (TTL) Header Checksum
可変（ICV計算前にゼロ）分化サービスコードポイント（DSCP）（6ビット、RFC 2474 [NBBB98]を参照）明示的な混雑通知（ECN）（2ビット、RFC 3168 [RFB01]を参照）フラグフラグメントオフセット時間（TTL）ヘッダーチェックサム
DSCP - Routers may rewrite the DS field as needed to provide a desired local or end-to-end service, thus its value upon reception cannot be predicted by the sender.
DSCP-ルーターは、必要に応じてDSフィールドを書き換えて、目的のローカルまたはエンドツーエンドサービスを提供するため、受信時の値は送信者が予測することはできません。
ECN - This will change if a router along the route experiences congestion, and thus its value upon reception cannot be predicted by the sender.
ECN-これは、ルートに沿ったルーターが混雑を発生させると変化します。したがって、受信時の値は送信者によって予測できません。
Flags - This field is excluded because 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 change, 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の場合、オプション全体がユニットと見なされます。したがって、ほとんどのオプション内のタイプと長さのフィールドは輸送中に不可能ですが、オプションが可変として分類されている場合、オプション全体はICV計算目的でゼロになります。
The IPv6 base header fields are classified as follows:
IPv6ベースヘッダーフィールドは、次のように分類されます。
Immutable Version Payload Length Next Header Source Address Destination Address (without Routing Extension Header)
不変のバージョンペイロード長いヘッダーソースアドレス宛先アドレス（ルーティング拡張ヘッダーなし）
Mutable but predictable Destination Address (with Routing Extension Header)
可変だが予測可能な宛先アドレス（ルーティング拡張ヘッダー付き）
Mutable (zeroed prior to ICV calculation) DSCP (6 bits, see RFC2474 [NBBB98]) ECN (2 bits, see RFC3168 [RFB01]) Flow Label (*) Hop Limit
Mutable（ICV計算前にゼロ）DSCP（6ビット、RFC2474 [NBBB98]を参照）ECN（2ビット、RFC3168 [RFB01]）フローラベル（*）ホップ制限
(*) The flow label described in AHv1 was mutable, and in RFC 2460 [DH98] was potentially mutable. To retain compatibility with existing AH implementations, the flow label is not included in the ICV in AHv2.
（*）AHV1に記載されているフローラベルは可変であり、RFC 2460 [DH98]で可変性がありました。既存のAH実装との互換性を保持するために、フローラベルはAHV2の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 [DH98] for more information.
ホップバイホップおよび宛先拡張ヘッダーのIPv6オプションには、トランジット中にオプションが（予測不可能に）変更される可能性があるかどうかを示すビットが含まれています。内容がen-routeを変更する可能性のあるオプションの場合、ICVを計算または検証する際に、「オプションデータ」フィールド全体をゼロ値のオクテットとして扱う必要があります。オプションタイプとOPTデータレンは、ICV計算に含まれています。ビットが不変性を示しているすべてのオプションは、ICV計算に含まれています。詳細については、IPv6仕様[DH98]を参照してください。
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 ICV field may include explicit padding if required 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で述べたように、ICVフィールドには、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 IPv4 or 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 ICV calculation, counted as part of the Payload Length, and transmitted at the end of the ICV field to enable the receiver to perform the ICV calculation. Inclusion of padding in excess of the minimum amount required to satisfy IPv4/IPv6 alignment requirements is prohibited.
たとえば、選択したアルゴリズムの出力が96ビットの場合、IPv4またはIPv6にはパディングは必要ありません。ただし、異なる長さのICVが生成された場合、異なるアルゴリズムの使用により、長さとIPプロトコルバージョンに応じてパディングが必要になる場合があります。パディングフィールドの内容は、送信者によって任意に選択されます。（パディングは任意ですが、セキュリティを達成するためにランダムである必要はありません。）これらのパディングバイトは、ICV計算に含まれ、ペイロード長の一部としてカウントされ、ICVフィールドの最後に送信され、受信者が実行できます。ICV計算。IPv4/IPv6アライメント要件を満たすために必要な最小量を超えるパディングを含めることは禁止されています。
If the ESN option is elected for an SA, then the high-order 32 bits of the ESN must be included in the ICV computation. For purposes of ICV computation, these bits are appended (implicitly) immediately after the end of the payload, and before any implicit packet padding.
ESNオプションがSAに対して選出された場合、ESNの高次32ビットをICV計算に含める必要があります。ICV計算の目的で、これらのビットは、ペイロードの終了直後、および暗黙のパケットパディングの前に（暗黙的に）追加されます。
For some integrity 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 and the 32 high-order bits of the ESN, if enabled) 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. The document that defines an integrity algorithm MUST be consulted to determine if implicit padding is required as described above. If the document does not specify an answer to this, then the default is to assume that implicit padding is required (as needed to match the packet length to the algorithm's blocksize.) If padding bytes are needed but the algorithm does not specify the padding contents, then the padding octets MUST have a value of zero.
一部の整合性アルゴリズムの場合、ICV計算が実行されるバイト文字列は、アルゴリズムによって指定されたブロックサイズの倍数でなければなりません。IPパケットの長さ（AHおよびESNの32の高次ビットを含む、有効にする場合）がアルゴリズムのブロックサイズ要件と一致しない場合、ICV計算の前に、暗黙のパディングをパケットの最後に追加する必要があります。パディングオクテットの値はゼロです。ブロックサイズ（したがって、パディングの長さ）は、アルゴリズムの仕様によって指定されます。このパディングはパケットで送信されません。整合性アルゴリズムを定義するドキュメントを参照して、暗黙のパディングが必要かどうかを判断するために相談する必要があります。ドキュメントがこれへの回答を指定していない場合、デフォルトは、パッキングバイトが必要な場合、アルゴリズムがパディングの内容を指定していない場合、パケットの長さをアルゴリズムのブロックサイズに一致させるために必要な場合に必要なパディングが必要であると仮定することです。、次に、パディングオクテットにはゼロの値が必要です。
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 IPv4 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. (This does not apply to IPv6, where there is no router-initiated fragmentation.) 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が適用されているIPv4パケット自体は、ルーター自体が途中で断片化される可能性があり、そのようなフラグメントは、受信機でAH処理する前に再組み立てする必要があります。（これは、ルーターが開始した断片化がないIPv6には適用されません。）トンネルモードでは、AHはIPパケットに適用され、そのペイロードは断片化されたIPパケットである可能性があります。たとえば、セキュリティゲートウェイまたは「スタックの衝突」または「ワイヤーの衝突」IPSEC実装（詳細については、セキュリティアーキテクチャドキュメントを参照）は、トンネルモードAHをそのようなフラグメントに適用する場合があります。
NOTE: For transport mode -- As mentioned at the end of Section 3.1.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.1の最後に述べたように、スタックの隆起と衝突の実装は、最初にローカルIPレイヤーによって断片化されたパケットを再組み立てし、次に適用する必要がある場合があります。IPSEC、そして結果のパケットをフラグメントします。
NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire implementations, it will be necessary to examine 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処理に。
Fragmentation, whether performed by an IPsec implementation or by routers along the path between IPsec peers, significantly reduces performance. Moreover, the requirement for an AH receiver to accept fragments for reassembly creates denial of service vulnerabilities. Thus, an AH implementation MAY choose to not support fragmentation and may mark transmitted packets with the DF bit, to facilitate Path MTU (PMTU) discovery. In any case, an AH implementation MUST support generation of ICMP PMTU messages (or equivalent internal signaling for native host implementations) to minimize the likelihood of fragmentation. Details of the support required for MTU management are contained in the Security Architecture document.
IPSECの実装によって実行されるか、IPSECピア間のパスに沿ったルーターによって実行されるかどうかにかかわらず、断片化はパフォーマンスを大幅に低下させます。さらに、AHレシーバーが再組み立てのためにフラグメントを受け入れるための要件は、サービスの脆弱性を拒否します。したがって、AHの実装は、断片化をサポートしないことを選択し、PATH MTU（PMTU）の発見を促進するために、送信されたパケットをDFビットでマークする場合があります。いずれにせよ、AHの実装は、断片化の可能性を最小限に抑えるために、ICMP PMTUメッセージ（またはネイティブホスト実装の同等の内部信号）の生成をサポートする必要があります。MTU管理に必要なサポートの詳細は、セキュリティアーキテクチャドキュメントに含まれています。
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 nonzero 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フラグメントのように見える場合、つまりオフセットフィールドがゼロではないか、フラグメントフラグが設定されている場合、受信機はパケットを廃棄する必要があります。これは監査可能なイベントです。このイベントの監査ログエントリには、SPI値、日付/時刻、ソースアドレス、宛先アドレス、および（IPv6で）フローIDを含める必要があります。
NOTE: For packet reassembly, the current IPv4 spec does NOT require either the zeroing 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仕様では、オフセットフィールドのゼロ化またはより多くのフラグメントフラグのクリアのいずれも必要ありません。IPSECによって再組み立てされたパケットを処理するために（見かけのフラグメントとして破棄するのではなく）、IPコードはパケットを再組み立てした後、これら2つのことを行う必要があります。
Upon receipt of a packet containing an IP Authentication Header, the receiver determines the appropriate (unidirectional) SA via lookup in the SAD. For a unicast SA, this determination is based on the SPI or the SPI plus protocol field, as described in Section 2.4. If an implementation supports multicast traffic, the destination address is also employed in the lookup (in addition to the SPI), and the sender address also may be employed, as described in Section 2.4. (This process is described in more detail in the Security Architecture document.) The SAD entry for the SA also indicates whether the Sequence Number field will be checked and whether 32- or 64-bit sequence numbers are employed for the SA. The SAD entry for the SA also specifies the algorithm(s) employed for ICV computation, and indicates the key required to validate the ICV.
IP認証ヘッダーを含むパケットを受信すると、受信者はSADのルックアップを介して適切な（単方向）SAを決定します。ユニキャストSAの場合、この決定は、セクション2.4で説明されているように、SPIまたはSPI Plusプロトコルフィールドに基づいています。実装がマルチキャストトラフィックをサポートする場合、宛先アドレスも検索で（SPIに加えて）採用され、セクション2.4で説明されているように、送信者アドレスも採用される場合があります。（このプロセスについては、セキュリティアーキテクチャドキュメントで詳細に説明します。）SAの悲しいエントリは、SAにシーケンス番号フィールドがチェックされるかどうか、およびSAに32ビットまたは64ビットシーケンス番号が使用されているかどうかも示します。SAの悲しいエントリは、ICV計算に使用されるアルゴリズムも指定し、ICVを検証するために必要なキーを示します。
If no valid Security Association exists for this packet 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を含める必要があります。
(Note that SA management traffic, such as IKE packets, does not need to be processed based on SPI, i.e., one can de-multiplex this traffic separately based on Next Protocol and Port fields, for example.)
（IKEパケットなどのSA管理トラフィックは、SPIに基づいて処理する必要はないことに注意してください。つまり、次のプロトコルとポートフィールドに基づいて、このトラフィックを個別に脱マルテックスできます。
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. Anti-replay is applicable to unicast as well as multicast SAs. However, this standard specifies no mechanisms for providing anti-replay for a multi-sender SA (unicast or multicast). In the absence of negotiation (or manual configuration) of an anti-replay mechanism for such an SA, it is recommended that sender and receiver checking of the Sequence Number for the SA be disabled (via negotiation or manual configuration), as noted below.
すべてのAH実装は、Anti Replayサービスをサポートする必要がありますが、その使用は、SAごとにレシーバーによって有効または無効にされる場合があります。アンチレプレイは、マルチキャストSASと同様にユニキャストに適用できます。ただし、この標準は、マルチセンダーSA（ユニキャストまたはマルチキャスト）にアンチレプレイを提供するためのメカニズムを指定していません。以下に示すように、このようなSAのアンチレプレイメカニズムのネゴシエーション（または手動構成）がない場合、SA BEのシーケンス番号を（交渉または手動構成を介して）送信者と受信者チェックすることをお勧めします。
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, "Sequence Number Generation"), 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.2、「シーケンス番号の生成」を参照）、IKEなどのSA施設プロトコルが使用されている場合、受信者はSA施設中に送信者に通知する必要があります。受信機は、レプレイ防止保護を提供しません。
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 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.
重複は、スライド受信ウィンドウを使用して拒否されます。ウィンドウの実装方法はローカルの問題ですが、次のテキストは、実装が示す必要がある機能を説明しています。
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.
ウィンドウの「右」の端は、このSAで受信した最高の検証されたシーケンス数値を表します。ウィンドウの「左」の端よりも低いシーケンス番号を含むパケットは拒否されます。ウィンドウ内にあるパケットは、ウィンドウ内の受信したパケットのリストに対してチェックされます。
If the ESN option is selected for an SA, only the low-order 32 bits of the sequence number are explicitly transmitted, but the receiver employs the full sequence number computed using the high-order 32 bits for the indicated SA (from his local counter) when checking the received Sequence Number against the receive window. In constructing the full sequence number, if the low-order 32 bits carried in the packet are lower in value than the low-order 32 bits of the receiver's sequence number counter, the receiver assumes that the high-order 32 bits have been incremented, moving to a new sequence number subspace. (This algorithm accommodates gaps in reception for a single SA as large as 2**32-1 packets. If a larger gap occurs, additional, heuristic checks for re-synchronization of the receiver's sequence number counter MAY be employed, as described in Appendix B.)
SAに対してESNオプションが選択されている場合、シーケンス番号の低次の32ビットのみが明示的に送信されますが、受信機は、指定されたSAの高次32ビットを使用して計算された完全なシーケンス番号を使用します（ローカルカウンターから）受信したシーケンス番号を受信ウィンドウに対してチェックするとき。完全なシーケンス番号の構築において、パケットに運ばれる低次の32ビットの値がレシーバーのシーケンス番号カウンターの低次の32ビットよりも値が低い場合、レシーバーは高次の32ビットが増加していると想定しています。新しいシーケンス番号サブスペースに移動します。（このアルゴリズムは、2 ** 32-1パケットの大きな単一のSAの受信のギャップに対応します。大きなギャップが発生した場合、付録で説明されているように、レシーバーのシーケンス番号カウンターの再同期のための追加のヒューリスティックチェックが使用される場合があります。B.）
If the received packet falls within the window and is not a duplicate, 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データグラムを無効として破棄する必要があります。これは監査可能なイベントです。このイベントの監査ログエントリには、SPI値、日付/時刻、ソースアドレス、宛先アドレス、シーケンス番号、および（IPv6の）フローIDを含める必要があります。受信ウィンドウは、ICV検証が成功した場合にのみ更新されます。
A MINIMUM window size of 32 packets 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.) The receive window size should be increased for higher-speed environments, irrespective of assurance issues. Values for minimum and recommended receive window sizes for very high-speed (e.g., multi-gigabit/second) devices are not specified by this standard.
32パケットの最小ウィンドウサイズをサポートする必要がありますが、64のウィンドウサイズが優先され、デフォルトとして使用する必要があります。別のウィンドウサイズ（最小よりも大きい）は、受信機によって選択される場合があります。（受信者は、ウィンドウサイズを送信者に通知しません。）保証の問題に関係なく、より高いスピード環境では、受信ウィンドウサイズを増やす必要があります。最小値と推奨される値は、非常に高速（マルチギガビット/秒）デバイスのウィンドウサイズを受信します。この標準では指定されていません。
The receiver computes the ICV over the appropriate fields of the packet, using the specified integrity algorithm, and verifies that it is the same as the ICV included in the ICV field of the packet. Details of the computation are provided below.
受信機は、指定された整合性アルゴリズムを使用して、パケットの適切なフィールドでICVを計算し、パケットのICVフィールドに含まれるICVと同じであることを確認します。計算の詳細を以下に示します。
If the computed and received ICVs 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.
計算されたICVSと受信したICVが一致する場合、データグラムは有効であり、受け入れられます。テストが失敗した場合、受信者は受信したIPデータグラムを無効として破棄する必要があります。これは監査可能なイベントです。監査ログエントリには、SPI値、受信した日付/時刻、ソースアドレス、宛先アドレス、および（IPv6で）フローIDを含める必要があります。
Implementation Note:
実装注：
Implementations can use any set of steps that results in the same result as the following set of steps. Begin by saving the ICV value and replacing it (but not any ICV field padding) with zero. Zero all other fields that may have been modified during transit. (See Section 3.3.3.1, "Handling Mutable Fields", for a discussion of which fields are zeroed before performing the ICV calculation.) If the ESN option is elected for this SA, append the high-order 32 bits of the ESN after the end of the packet. Check the overall length of the packet (as described above), and if it requires implicit padding based on the requirements of the integrity algorithm, append zero-filled bytes to the end of the packet (after the ESN if present) 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フィールドパディングではない）ことから始めます。輸送中に変更された可能性のある他のすべてのフィールドをゼロ。（ICV計算を実行する前にどのフィールドがゼロになっているかについての議論については、セクション3.3.3.1、「可変フィールドの取り扱い」を参照してください。）このSAに対してESNオプションが選出されている場合、ESNの高次32ビットを追加します。パケットの終わり。パケットの全長（上記のように）を確認し、整合性アルゴリズムの要件に基づいて暗黙のパディングが必要な場合は、必要に応じて（存在する場合はESNの後）パケットの最後にゼロで充填されたバイトを追加します。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 for unicast traffic, and MUST comply with all requirements of the Security Architecture document [Ken-Arch]. Additionally, if an implementation claims to support multicast traffic, it MUST comply with the additional requirements specified for support of such traffic. 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.
この仕様への適合性またはコンプライアンスを主張する実装は、ユニキャストトラフィックのためにここで説明するAHの構文と処理を完全に実装する必要があり、セキュリティアーキテクチャドキュメント[Ken-Arch]のすべての要件に準拠する必要があります。さらに、実装がマルチキャストトラフィックをサポートすると主張する場合、そのようなトラフィックのサポートのために指定された追加要件に準拠する必要があります。ICVの計算に使用されるキーが手動で分散されている場合、キーが交換されるまで、アンチレプレイサービスの正しい提供が送信者でのカウンター状態の正しいメンテナンスが必要になり、カウンターオーバーフローの場合、自動回復条項がない可能性があります差し迫っていた。したがって、準拠した実装では、このサービスを手動でキー化されたSASと併用してはなりません。
The mandatory-to-implement algorithms for use with AH are described in a separate RFC [Eas04], to facilitate updating the algorithm requirements independently from the protocol per se. Additional algorithms, beyond those mandated for AH, MAY be supported.
AHで使用するための必須の実装アルゴリズムは、プロトコル自体とは独立してアルゴリズム要件の更新を容易にするために、別のRFC [EAS04]で説明されています。AHに義務付けられたものを超えた追加のアルゴリズムがサポートされる場合があります。
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 document differs from RFC 2402 [RFC2402] in the following ways.
このドキュメントは、次の方法でRFC 2402 [RFC2402]とは異なります。
o SPI -- modified to specify a uniform algorithm for SAD lookup for unicast and multicast SAs, covering a wider range of multicast technologies. For unicast, the SPI may be used alone to select an SA, or may be combined with the protocol, at the option of the receiver. For multicast SAs, the SPI is combined with the destination address, and optionally the source address, to select an SA. o Extended Sequence Number -- added a new option for a 64-bit sequence number for very high-speed communications. Clarified sender and receiver processing requirements for multicast SAs and multi-sender SAs. o Moved references to mandatory algorithms to a separate document [Eas04].
o SPI -UnicastおよびマルチキャストSASのSADルックアップのための均一なアルゴリズムを指定するように変更され、より広範なマルチキャストテクノロジーをカバーしています。ユニキャストの場合、SPIはSAを選択するために単独で使用されるか、レシーバーのオプションでプロトコルと組み合わせることができます。マルチキャストSASの場合、SPIは宛先アドレス、およびオプションでソースアドレスと組み合わされて、SAを選択します。o拡張シーケンス番号 - 非常に高速通信のために64ビットシーケンス番号の新しいオプションを追加しました。マルチキャストSASおよびマルチセンダーSASの送信者と受信機処理要件を明確にしました。o必須アルゴリズムへの参照を別のドキュメント[EAS04]に移動しました。
The author would like to acknowledge the contributions of Ran Atkinson, who played a critical role in initial IPsec activities, and who authored the first series of IPsec standards: RFCs 1825-1827. Karen Seo deserves special thanks for providing help in the editing of this and the previous version of this specification. The author also would like to thank the members of the IPsec and MSEC working groups who have contributed to the development of this protocol specification.
著者は、最初のIPSECアクティビティで重要な役割を果たし、IPSEC標準の最初のシリーズであるRFCS 1825-1827を執筆したRan Atkinsonの貢献を認めたいと思います。Karen Seoは、この仕様の以前のバージョンの編集に支援を提供してくれたことに特に感謝します。著者はまた、このプロトコル仕様の開発に貢献したIPSECおよびMSECワーキンググループのメンバーにも感謝したいと思います。
[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月。
[DH98] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[DH98] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[Eas04] 3rd Eastlake, D., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005.
[EAS04] 3rd EastLake、D。、「セキュリティペイロード（ESP）および認証ヘッダー（AH）をカプセル化するための暗号化アルゴリズムの実装要件」、RFC 4305、2005年12月。
[Ken-Arch] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[Ken-Arch] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC1108] Kent, S., "U.S. Department of Defense Security Options for the Internet Protocol", RFC 1108, November 1991.
[RFC1108] Kent、S。、「インターネットプロトコルの米国国防総省セキュリティオプション」、RFC 1108、1991年11月。
[AES] Advanced Encryption Standard (AES), Federal Information Processing Standard 197, National Institutes of Standards and Technology, November 26, 2001.
[AES]高度な暗号化標準（AES）、連邦情報処理標準197、国立標準技術研究所、2001年11月26日。
[HC03] Holbrook, H. and B. Cain, "Source Specific Multicast for IP", Work in Progress, November 3, 2002.
[HC03] Holbrook、H。およびB. Cain、「IPのソース固有のマルチキャスト」、2002年11月3日、進行中の作業。
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEV2] Kaufman、C.、ed。、「Internet Key Exchange（IKEV2）Protocol」、RFC 4306、2005年12月。
[Ken-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[Ken-esp] Kent、S。、「セキュリティペイロードをカプセル化するIP（ESP）」、RFC 4303、2005年12月。
[NBBB98] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[NBBB98] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[RFB01] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFB01] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP MTU discovery options", RFC 1063, July 1988.
[RFC1063] Mogul、J.、Kent、C.、Partridge、C。、およびK. McCloghrie、「IP MTU Discovery Options」、RFC 1063、1988年7月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[RFC1385] Wang, Z., "EIP: The Extended Internet Protocol", RFC 1385, November 1992.
[RFC1385] Wang、Z。、「EIP：The Extended Internet Protocol」、RFC 1385、1992年11月。
[RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393, January 1993.
[RFC1393] Malkin、G。、「IPオプションを使用したTraceroute」、RFC 1393、1993年1月。
[RFC1770] Graff, C., "IPv4 Option for Sender Directed Multi-Destination Delivery", RFC 1770, March 1995.
[RFC1770] Graff、C。、「送信者向けのIPv4オプション」、1995年3月、RFC 1770。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113] Katz、D。、「IPルーターアラートオプション」、RFC 2113、1997年2月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]ケント、S。およびR.アトキンソン、「IP認証ヘッダー」、RFC 2402、1998年11月。
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3547] Baugher、M.、Weis、B.、Hardjono、T。、およびH. Harney、「The Group Domain of Strettation」、RFC 3547、2003年7月。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC3740] Hardjono、T。およびB. Weis、「The Multicast Group Security Architecture」、RFC 3740、2004年3月。
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 RFC 1700, "ASSIGNED NUMBERS", (October 1994).
この表は、IPv4オプションが「変動」に関してどのように分類されるかを示しています。2つの参照が提供されている場合、2番目の参照は最初の参照です。この表は、RFC 1700（割り当てられた番号」（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
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 Protocol [RFC1385, DH98 (IPv6)]
0 0 10 Experimental Measurement
1 2 13 Experimental Flow Control
1 0 14 Experimental Access Ctl
0 0 15 ???
1 0 16 IMI Traffic Descriptor
1 0 19 Address Extension
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., Resource Reservation Protocol (RSVP)/Internet Group Management Protocol (IGMP)), the packet should encounter AH processing. 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.
注：ルーターアラートオプションの使用は、IPSECの使用と互換性がない可能性があります。オプションは不変ですが、その使用は、パケットのパスに沿った各ルーターがパケットを「処理」し、その結果パケットを変更する可能性があることを意味します。これは、パケットがルーターからルーターに移動するため、ホップバイホップベースで発生します。オプションの内容が指示されるアプリケーション（リソース予約プロトコル（RSVP）/インターネットグループ管理プロトコル（IGMP））によって処理される前に、パケットはAH処理に遭遇するはずです。ただし、AH処理では、パスに沿った各ルーターがSPIによって定義されたマルチキャストSAのメンバーであることが必要です。これは、厳密にソースルーティングされていないパケットに問題を引き起こす可能性があり、現在利用できないマルチキャストサポート技術が必要です。
NOTE: Addition or removal of security labels (e.g., Basic Security Option (BSO), Extended Security Option (ESO), or Commercial Internet Protocol Security Option (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 that 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) [DH98]
BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING TRANSIT) Hop-by-Hop options [DH98] Destination options [DH98]
BITは、オプションが可変であるかどうかを示します（輸送中に予測不可能に変更）ホップバイホップオプション[DH98]宛先オプション[DH98]
NOT APPLICABLE Fragmentation [DH98]
適用されない断片化[DH98]
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 [DH98] for more information.
オプション-Hop-by-Hopおよび宛先拡張ヘッダーのIPv6オプションには、トランジット中にオプションが（予測不可能に）変更される可能性があるかどうかを示すビットが含まれています。途中でコンテンツが変更される可能性のあるオプションの場合、ICVを計算または検証する際に、「オプションデータ」フィールド全体をゼロ値のオクテットとして扱う必要があります。オプションタイプとOPTデータレンは、ICV計算に含まれています。ビットが不変性を示しているすべてのオプションは、ICV計算に含まれています。詳細については、IPv6仕様[DH98]を参照してください。
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 Integrity Check Value 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）の前に再組み立てが発生します。したがって、フラグメンテーションエクステンションヘッダーが存在する場合、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実装により、再組み立てが行われると、フラグメンテーションエクステンションヘッダーが配置される可能性があることに注意してください。これが発生した場合、AHがICV処理を行う前にパケットを受信した場合、AHはこのヘッダーを「削除」（またはスキップ）する必要があり、以前のヘッダーの「次のヘッダー」フィールドをフラグメンテーションエクステンションの「次のヘッダー」フィールドに変更する必要があります。ヘッダ。
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（最初のフラグメント）と0のフラグメントフラグ（最後のフラグメント）を備えたフラグメンテーションエクステンションヘッダーを備えたパケットを提供できることに注意してください。これが発生した場合、ICV処理を行う前に、AHは最初にこのヘッダーを「削除」（またはスキップ）し、以前のヘッダーの「次のヘッダー」フィールドを断片化拡張ヘッダーの「次のヘッダー」フィールドに変更する必要があります。
Appendix B: Extended (64-bit) Sequence Numbers
付録B：拡張（64ビット）シーケンス番号
B1. Overview
B1。概要
This appendix describes an Extended Sequence Number (ESN) scheme for use with IPsec (ESP and AH) that employs a 64-bit sequence number, but in which only the low-order 32 bits are transmitted as part of each packet. It covers both the window scheme used to detect replayed packets and the determination of the high-order bits of the sequence number that are used both for replay rejection and for computation of the ICV. It also discusses a mechanism for handling loss of synchronization relative to the (not transmitted) high-order bits.
この付録では、64ビットシーケンス番号を使用するIPSEC（ESPおよびAH）で使用するための拡張シーケンス番号（ESN）スキームについて説明しますが、低次の32ビットのみが各パケットの一部として送信されます。再生されたパケットを検出するために使用されるウィンドウスキームと、リプレイ拒否とICVの計算の両方に使用されるシーケンス番号の高次ビットの決定の両方をカバーします。また、（送信されていない）高次ビットに対する同期の損失を処理するメカニズムについても説明しています。
B2. Anti-Replay Window
B2。アンチレプレイウィンドウ
The receiver will maintain an anti-replay window of size W. This window will limit how far out of order a packet can be, relative to the packet with the highest sequence number that has been authenticated so far. (No requirement is established for minimum or recommended sizes for this window, beyond the 32- and 64-packet values already established for 32-bit sequence number windows. However, it is suggested that an implementer scale these values consistent with the interface speed supported by an implementation that makes use of the ESN option. Also, the algorithm described below assumes that the window is no greater than 2^31 packets in width.) All 2^32 sequence numbers associated with any fixed value for the high-order 32 bits (Seqh) will hereafter be called a sequence number subspace. The following table lists pertinent variables and their definitions.
受信機は、サイズWのアンチレプレイウィンドウを維持します。このウィンドウは、これまでに認証されている最高のシーケンス番号を持つパケットと比較して、パケットの距離を制限します。（このウィンドウの最小または推奨サイズの要件は、32ビットシーケンス番号ウィンドウに対して既に確立されている32パケットと64パケットの値を超えて確立されています。ただし、実装者は、サポートされているインターフェイス速度と一致するこれらの値をスケーリングすることをお勧めします。また、ESNオプションを使用する実装により。また、以下に説明するアルゴリズムは、ウィンドウが幅の2^31パケットに大きくないことを前提としています。）高次の32の固定値に関連付けられたすべての2^32シーケンス番号ビット（SEQH）は、今後シーケンス番号サブスペースと呼ばれます。次の表には、適切な変数とその定義を示します。
Var. Size
Name (bits) Meaning
---- ------ ---------------------------
W 32 Size of window
T 64 Highest sequence number authenticated so far,
upper bound of window
Tl 32 Lower 32 bits of T
Th 32 Upper 32 bits of T
B 64 Lower bound of window
Bl 32 Lower 32 bits of B
Bh 32 Upper 32 bits of B
Seq 64 Sequence Number of received packet
Seql 32 Lower 32 bits of Seq
Seqh 32 Upper 32 bits of Seq
When performing the anti-replay check, or when determining which high-order bits to use to authenticate an incoming packet, there are two cases:
アンチレプレイチェックを実行する場合、または着信パケットを認証するために使用する高次のビットを決定するとき、2つのケースがあります。
+ Case A: Tl >= (W - 1). In this case, the window is within one sequence number subspace. (See Figure 1) + Case B: Tl < (W - 1). In this case, the window spans two sequence number subspaces. (See Figure 2)
+ ケースA：tl> =（w -1）。この場合、ウィンドウは1つのシーケンス番号サブスペース内にあります。（図1を参照）ケースB：TL <（W -1）。この場合、ウィンドウは2つのシーケンス番号サブスペースに及びます。（図2を参照）
In the figures below, the bottom line ("----") shows two consecutive
sequence number subspaces, with zeros indicating the beginning of
each subspace. The two shorter lines above it show the higher-order
bits that apply. The "====" represents the window. The "****"
represents future sequence numbers, i.e., those beyond the current
highest sequence number authenticated (ThTl).
Th+1 *********
Th =======*****
--0--------+-----+-----0--------+-----------0--
Bl Tl Bl
(Bl+2^32) mod 2^32
Figure 1 -- Case A
図1-ケースa
Th ====**************
Th-1 ===
--0-----------------+--0--+--------------+--0--
Bl Tl Bl
(Bl+2^32) mod 2^32
Figure 2 -- Case B
図2-ケースb
B2.1. Managing and Using the Anti-Replay Window
B2.1。レプレイ防止ウィンドウの管理と使用
The anti-replay window can be thought of as a string of bits where `W' defines the length of the string. W = T - B + 1 and cannot exceed 2^32 - 1 in value. The bottom-most bit corresponds to B and the top-most bit corresponds to T, and each sequence number from Bl through Tl is represented by a corresponding bit. The value of the bit indicates whether or not a packet with that sequence number has been received and authenticated, so that replays can be detected and rejected.
アンチレプレイウィンドウは、「w」が文字列の長さを定義する一連のビットと考えることができます。w = t -b 1で、値が2^32-1を超えることはできません。一番下のビットはbに対応し、最上部ビットはtに対応し、BLからTLからの各シーケンス番号は対応するビットで表されます。ビットの値は、そのシーケンス番号を含むパケットが受信および認証されたかどうかを示しているため、リプレイを検出して拒否することができます。
When a packet with a 64-bit sequence number (Seq) greater than T is received and validated,
Tより大きい64ビットシーケンス番号（seq）を持つパケットが受信および検証された場合、
+ B is increased by (Seq - T) + (Seq - T) bits are dropped from the low end of the window + (Seq - T) bits are added to the high end of the window + The top bit is set to indicate that a packet with that sequence number has been received and authenticated + The new bits between T and the top bit are set to indicate that no packets with those sequence numbers have been received yet. + T is set to the new sequence number
+ bは（seq -t）（seq -t）ビットをウィンドウのローエンド（seq -t）ビットから窓のハイエンドに追加します。そのシーケンス番号が受信され、Tと上部ビットの間の新しいビットが設定されており、これらのシーケンス番号がまだ受信されていないことを示すように設定されています。Tは新しいシーケンス番号に設定されています
In checking for replayed packets,
再生されたパケットをチェックする際、
+ Under Case A: If Seql >= Bl (where Bl = Tl - W + 1) AND Seql <= Tl, then check the corresponding bit in the window to see if this Seql has already been seen. If yes, reject the packet. If no, perform integrity check (see Appendix B2.2 below for determination of SeqH).
+ ケースa：seql> = bl（bl = tl -w 1）およびseql <= tlの場合、ウィンドウの対応するビットをチェックして、このseqlがすでに見られているかどうかを確認します。はいの場合、パケットを拒否します。いいえの場合は、整合性チェックを実行します（SEQHの決定については、以下の付録B2.2を参照）。
+ Under Case B: If Seql >= Bl (where Bl = Tl - W + 1) OR Seql <= Tl, then check the corresponding bit in the window to see if this Seql has already been seen. If yes, reject the packet. If no, perform integrity check (see Appendix B2.2 below for determination of Seqh).
+ ケースB：seql> = bl（bl = tl -w 1）またはseql <= tlの場合、ウィンドウの対応するビットを確認して、このseqlがすでに見られているかどうかを確認します。はいの場合、パケットを拒否します。いいえの場合は、整合性チェックを実行します（SEQHの決定については、以下の付録B2.2を参照）。
B2.2. Determining the Higher-Order Bits (Seqh) of the Sequence Number
B2.2。シーケンス番号の高次ビット（SEQH）を決定する
Because only `Seql' will be transmitted with the packet, the receiver must deduce and track the sequence number subspace into which each packet falls, i.e., determine the value of Seqh. The following equations define how to select Seqh under "normal" conditions; see Appendix B3 for a discussion of how to recover from extreme packet loss.
パケットで「seql」のみが送信されるため、受信者は各パケットが落ちるシーケンス番号サブスペースを推定して追跡する必要があります。つまり、seqhの値を決定する必要があります。次の方程式は、「通常の」条件下でSEQHを選択する方法を定義します。極端なパケット損失から回復する方法についての議論については、付録B3を参照してください。
+ Under Case A (Figure 1): If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th + 1
+ ケースa（図1）：seql> = bl（bl = tl -w 1）の場合、seqh = thの場合はseql <bl（bl = tl -w 1）、seqh = th 1
+ Under Case B (Figure 2): If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th - 1 If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th
+ ケースB（図2）：seql> = bl（bl = tl -w 1）の場合、seqh = th -1 seql <bl（bl = tl -w 1）、seqh = th
B2.3. Pseudo-Code Example
B2.3。擬似コードの例
The following pseudo-code illustrates the above algorithms for anti-replay and integrity checks. The values for `Seql', `Tl', `Th', and `W' are 32-bit unsigned integers. Arithmetic is mod 2^32.
次の擬似コードは、アンチレプレイと整合性チェックの上記のアルゴリズムを示しています。「seql」、 `tl '、` th'、および `w 'の値は、32ビットの符号なし整数です。算術はmod 2^32です。
If (Tl >= W - 1) Case A If (Seql >= Tl - W + 1) Seqh = Th If (Seql <= Tl) If (pass replay check) If (pass integrity check) Set bit corresponding to Seql Pass the packet on Else reject packet Else reject packet Else If (pass integrity check) Tl = Seql (shift bits) Set bit corresponding to Seql Pass the packet on Else reject packet Else Seqh = Th + 1 If (pass integrity check) Tl = Seql (shift bits) Th = Th + 1 Set bit corresponding to Seql Pass the packet on Else reject packet Else Case B If (Seql >= Tl - W + 1) Seqh = Th - 1 If (pass replay check) If (pass integrity check) Set the bit corresponding to Seql Pass packet on Else reject packet Else reject packet Else Seqh = Th If (Seql <= Tl) If (pass replay check) If (pass integrity check) Set the bit corresponding to Seql Pass packet on Else reject packet Else reject packet
if（tl> = w -1）case a if（seql> = tl -w 1）seqh = th if（seql <= tl）if（pass repray check）if（pass Integrity check）set set bitにseqlパスに対応するelseのパケット拒否パケットelse redject packet else else（パス整合性チェック）tl = seql（shift bits）set set set seet seql ass elsed packet else seqh = th 1 if（pass intecrity check）tl = seql（shift（shift（shift）bits）th = th = th 1 set seqlに対応するビット他のパケット拒否パケットのパケットパッケージelseケースb（seql> = tl -w 1）seqh = th -1 if（pass repray check）if（pass Integrity check）Setを設定しますseql passパケットに対応するビットelsejed packet else else redject packet packet else else seqh = th if（seql <= tl）if（pass repray check）if（pass Integrity check）はパケット
Else If (pass integrity check) Tl = Seql (shift bits) Set the bit corresponding to Seql Pass packet on Else reject packet
else（パス整合性チェック）tl =続編（シフトビット）elseのシールパスパケットに対応するビットを設定します
B3. Handling Loss of Synchronization due to Significant Packet Loss
B3。重大なパケット損失による同期の損失
If there is an undetected packet loss of 2^32 or more consecutive packets on a single SA, then the transmitter and receiver will lose synchronization of the high-order bits, i.e., the equations in Appendix B2.2. will fail to yield the correct value. Unless this problem is detected and addressed, subsequent packets on this SA will fail authentication checks and be discarded. The following procedure SHOULD be implemented by any IPsec (ESP or AH) implementation that supports the ESN option.
単一のSAで2^32以上の連続したパケットの検出されないパケット損失がある場合、トランスミッターとレシーバーは高次ビットの同期、つまり付録B2.2の方程式を失います。正しい値をもたらすことができません。この問題が検出され、対処されない限り、このSAの後続のパケットは認証チェックに失敗し、破棄されます。以下の手順は、ESNオプションをサポートするIPSEC（ESPまたはAH）実装によって実装する必要があります。
Note that this sort of extended traffic loss seems unlikely to occur if any significant fraction of the traffic on the SA in question is TCP, because the source would fail to receive ACKs and would stop sending long before 2^32 packets had been lost. Also, for any bi-directional application, even ones operating above UDP, such an extended outage would likely result in triggering some form of timeout. However, a unidirectional application, operating over UDP, might lack feedback that would cause automatic detection of a loss of this magnitude, hence the motivation to develop a recovery method for this case.
ソースがACKを受け取ることができず、2^32パケットが失われる前に長く送信を停止するため、問題のSAのトラフィックのかなりの部分がTCPである場合、この種の延長されたトラフィック損失が発生する可能性は低いことに注意してください。また、双方向のアプリケーションでも、UDPを超えて動作しているものでさえ、そのような拡張停止により、何らかの形のタイムアウトがトリガーされる可能性があります。ただし、UDPを介して動作する単方向用途には、この大きさの喪失の自動検出を引き起こすフィードバックがないため、この場合の回復方法を開発する動機があります。
The solution we've chosen was selected to:
私たちが選択したソリューションは、次のように選択されました。
+ minimize the impact on normal traffic processing.
+ 通常の交通処理への影響を最小限に抑えます。
+ avoid creating an opportunity for a new denial of service attack such as might occur by allowing an attacker to force diversion of resources to a re-synchronization process. + limit the recovery mechanism to the receiver because anti-replay is a service only for the receiver, and the transmitter generally is not aware of whether the receiver is using sequence numbers in support of this optional service. It is preferable for recovery mechanisms to be local to the receiver. This also allows for backward compatibility.
+ 攻撃者が再同期プロセスへのリソースの迂回を強制することにより、発生する可能性など、新しいサービス攻撃の機会を作成しないでください。アンチレプレイは受信機のみのサービスであり、送信機は一般に、このオプションのサービスをサポートするためにレシーバーがシーケンス番号を使用しているかどうかを一般に認識していないため、受信機に制限されます。回復メカニズムが受信機にローカルになることをお勧めします。これにより、後方互換性も可能になります。
B3.1. Triggering Re-synchronization
B3.1。再同期のトリガー
For each SA, the receiver records the number of consecutive packets that fail authentication. This count is used to trigger the re-synchronization process, which should be performed in the background or using a separate processor. Receipt of a valid packet on the SA resets the counter to zero. The value used to trigger the re-synchronization process is a local parameter. There is no requirement to support distinct trigger values for different SAs, although an implementer may choose to do so.
各SAについて、受信機は認証に失敗する連続したパケットの数を記録します。このカウントは、再同期プロセスをトリガーするために使用されます。これは、バックグラウンドで実行するか、別のプロセッサを使用する必要があります。SAで有効なパケットを受信して、カウンターをゼロにリセットします。再同期プロセスをトリガーするために使用される値は、ローカルパラメーターです。実装者がそうすることを選択する場合は、異なるSAの異なるトリガー値をサポートする要件はありません。
B3.2. Re-synchronization Process
B3.2。再同期プロセス
When the above trigger point is reached, a "bad" packet is selected for which authentication is retried using successively larger values for the upper half of the sequence number (Seqh). These values are generated by incrementing by one for each retry. The number of retries should be limited, in case this is a packet from the "past" or a bogus packet. The limit value is a local parameter. (Because the Seqh value is implicitly placed after the AH (or ESP) payload, it may be possible to optimize this procedure by executing the integrity algorithm over the packet up to the endpoint of the payload, then compute different candidate ICVs by varying the value of Seqh.) Successful authentication of a packet via this procedure resets the consecutive failure count and sets the value of T to that of the received packet.
上記のトリガーポイントに到達すると、シーケンス番号（SEQH）の上半分の上半分の値がより大きな値を使用して認証が再試行される「悪い」パケットが選択されます。これらの値は、再試行ごとに1つずつ増加することによって生成されます。これが「過去」または偽のパケットからのパケットである場合、レトリの数を制限する必要があります。制限値はローカルパラメーターです。（SEQH値はAH（またはESP）ペイロードの後に暗黙的に配置されるため、パケットを介してペイロードのエンドポイントまで整合性アルゴリズムを実行して、この手順を最適化することができる場合があります。SEQHの。）この手順を介してパケットの認証を成功させると、連続障害カウントをリセットし、Tの値を受信パケットの値に設定します。
This solution requires support only on the part of the receiver, thereby allowing for backward compatibility. Also, because re-synchronization efforts would either occur in the background or utilize an additional processor, this solution does not impact traffic processing and a denial of service attack cannot divert resources away from traffic processing.
このソリューションでは、レシーバーの側でのみサポートが必要であり、それにより、後方互換性が可能になります。また、再同期の取り組みはバックグラウンドで発生するか、追加のプロセッサを利用するため、このソリューションはトラフィック処理に影響を与えず、サービス拒否攻撃はトラフィック処理から離れてリソースをそらすことはできません。
Author's Address
著者の連絡先
Stephen Kent BBN Technologies 10 Moulton Street Cambridge, MA 02138 USA
Stephen Kent BBN Technologies 10 Moulton Street Cambridge、MA 02138 USA
Phone: +1 (617) 873-3988
EMail: kent@bbn.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。