Network Working Group S. Kent
Request for Comments: 4302 BBN Technologies
Obsoletes: 2402 December 2005
Category: Standards Track
IP Authentication Header
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).
著作権（C）インターネット協会（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.
この文書は、読者が「インターネットプロトコルのためのセキュリティアーキテクチャ」[ケン-ARCH]に記載の用語と概念に精通していることを前提とし、以下、セキュリティアーキテクチャ文書と呼びます。具体的には、リーダは、カプセル化セキュリティペイロード（ESP）[ケン-ESP]およびIP認証ヘッダ（AH）、セキュリティアソシエーションの概念によって提供されるセキュリティサービスの定義は、ESPができる方法を理解しておく必要があり認証ヘッダ（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]で説明したように解釈される際のキーワードは、REQUIREDは、、、、、MAY、推奨、およびオプションのすべきでないないものとものとしてはなりませんしなければなりません。
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 IPカプセル化セキュリティペイロード（ESP）[ケン-ESP]、またはネストされた形で（セキュリティアーキテクチャ文書[ケン-アーチ]を参照）と組み合わせて、一人でも適用することができます。セキュリティサービスは、セキュリティゲートウェイを通信する対の間、またはセキュリティゲートウェイとホストとの間で、ホストと通信する一対の間に設けることができます。 ESPは同じアンチリプレイと同様の整合性サービスを提供するために使用することができる、そしてそれはまた、機密性（暗号化）サービスを提供しています。 ESPとAHが提供する完全性との間の主な違いは、カバレッジの範囲です。これらのフィールドは、（トンネルモードの使用を介して、例えば）ESPによってカプセル化されていない限り、具体的には、ESPは、任意のIPヘッダフィールドを保護しません。さまざまなネットワーク環境でAHとESPを使用する方法の詳細については、セキュリティアーキテクチャ文書[ケン-アーチ]を参照してください。
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.
プロトコルヘッダ（IPv4の、IPv6の、またはIPv6拡張）直ちにプロトコル（IPv4）のまたは次のヘッダ（IPv6の拡張）フィールド[DH98]の値51を含まなければならないAHヘッダを先行。図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形式で存在し、（セクション2.6及び3.3.3を参照）整合性チェック値（ICV）計算に含まれます。
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は、下位互換性の懸念がある場合、したがって、それらは例えば、IKE [IKEv2の]、またはアウトオブ、AHの互換バージョンを確実にするために、2つのIPSecピア間のシグナリングメカニズムを使用して対処しなければならない、バージョン番号が含まれていませんバンド構成メカニズム。
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を特徴付けるが、その長さは、32ビットワード内の他のIPv6拡張ヘッダで使用されていない64ビットワードに測定されることに注意してください。）セクション2.6を参照、「完全性値（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は、着信パケットがバインドされているSAを識別するために受信機によって使用される任意の32ビット値です。ユニキャストSAのために、SPIは、SAを指定するために単独で使用することができ、またはそれは（この場合AH）にIPsecプロトコルタイプと組み合わせて使用することができます。ユニキャストSAのSPI値が受信機によって生成されるので、値が十分であるかどうかをそれ自体でSAを識別するか、IPsecプロトコル値と一緒に使用する必要があるかどうかローカルの問題であることができます。 SPIフィールドは必須であり、そしてSAが上記ユニキャストするインバウンドトラフィックをマッピングするこのメカニズムは、すべての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実装がマルチキャストをサポートしている場合、それは、SASへのインバウンドのIPsecデータグラムをマッピングするための以下のアルゴリズムを使用してマルチキャストSAをサポートしなければなりません。ユニキャストトラフィックだけをサポートする実装は、この逆多重化アルゴリズムを実装する必要がありません。
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:
セキュリティアソシエーションデータベース（SAD）[ケン-ARCH]の各エントリは、SA検索がSPIに加えて、宛先、または宛先や送信元、IPアドレスを使用するかどうかを示す必要があります。マルチキャストSAのために、プロトコルフィールドは、SAの検索に採用されていません。それは「最長」SA識別子と一致するエントリが見つかったことを各インバウンド、IPsecで保護されたパケットの場合、実装は、SADなどの検索を行わなければなりません。二つ以上のSADエントリがSPI値に基づいて、一致した場合、この文脈では、次に、宛先、または宛先およびソース、アドレス比較（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.
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、宛先アドレス}に一致するSADを検索します。 SADエントリが一致した場合、その一致するSADエントリでインバウンド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.
受信機は、AHとESPのための単一のSPI空間を維持するために選択され、または{SPIプロトコル}に別段た場合3.のみ{SPI}に一致するSADを検索します。 SADエントリが一致した場合、その一致するSADエントリでインバウンド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によりハッシュテーブルへのインデックスできました。各ハッシュ・テーブル・バケットのリンクリストでSADエントリは、最初にそのリンクリストの中で最も長いSA識別子を持つものSADエントリを持つようにソートされ保持されます。彼らはリンクリスト内の最後のエントリになるように最短SA識別子を有するものSADエントリがソートされています。ハードウェアベースの実装は、一般的に入手可能な三元連想メモリ（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.
送信元および宛先アドレスマッチングをSAのにインバウンドIPsecトラフィックをマップするために必要であるかどうかの指示は、SA管理プロトコルを使用して手動SA設定の副作用として、または交渉を介してのいずれかで設定しなければなりません、例えば、IKE又は解釈のグループドメイン（GDOI） [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.)
255までの範囲1にSPI値のセットは、将来の使用のためInternet Assigned Numbers Authority（IANA）によって予約されています。割り当てられたSPI値の使用は、RFCで指定されていない限り、予約SPI値は、通常、IANAによって割り当てられません。 （0）ゼロのSPI値は、ローカル、実装に固有の使用のために予約されており、ワイヤ上で送信してはいけません。 （例えば、鍵管理の実装は、IPsec実装がその鍵管理エンティティが新しいSAを確立することを要求しましたが、SAがまだ確立されていない期間中に「いいえセキュリティアソシエーションが存在する」ことを意味するゼロSPI値を使用する場合があります。 ）
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に初期化されています。 （1のシーケンス番号を持つことになります与えられたSAを使用して送信された最初のパケットは、シーケンス番号の生成方法についての詳細は、セクション3.3.2を参照してください。）抗リプレイが（デフォルト）有効になっている場合は、送信シーケンス番号が必要サイクルに許されることはありません。したがって、送信側のカウンタと受信側のカウンタは、SAに2 ^ 32パケットの送信に先立って（従って新しい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機能は、同様に、ユニキャストSAをマルチキャストに適用可能です。）
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ビットのシーケンス番号の使用を可能にします。 （詳細については、「拡張（64ビット）シーケンス番号」、付録Bを参照）のみのシーケンス番号の下位32ビットは、このように、パケットのオーバーヘッドを最小限に抑える、各パケットのAHヘッダで送信されます。上位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.
これは、Integrityは、このパケットの値（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二つの方法で使用することができます。 （それぞれが使用する必要があるときの説明については、セキュリティアーキテクチャ文書を参照してください。）
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
* =存在する場合、AHの前、AHの後、あるいはその両方をすることができ
ESP and AH headers can be combined in a variety of modes. The IPsec Architecture document describes the combinations of security associations that must be supported.
ESPおよびAHヘッダは様々なモードで組み合わせることができます。 IPsecのアーキテクチャ文書はサポートされなければならないセキュリティアソシエーションの組み合わせを説明しています。
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.
「bump-in-the-スタック」または「バンプ・イン・ザ・ワイヤー」の実装のために、トランスポートモードでなお、セキュリティアーキテクチャ文書で定義されているように、インバウンドとアウトバウンドのIPフラグメントは、余分なIPを実行するためにIPsec実装が必要な場合がありますこの仕様に準拠し、透明な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ヘッダはIPsecの「ピア」セキュリティゲートウェイの例えば、アドレスのアドレスを含んでいるが、トンネルモードでは、「内側」IPヘッダは、究極（IP）送信元アドレスと宛先アドレスを運びます。混合内側および外側IPバージョンは、すなわち、IPv6のIPv4およびIPv6のIPv4の上の上、許されます。トンネルモードでは、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.
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値、現在の日付/時刻、送信元アドレス、宛先アドレス、および平文のフローID（IPv6では）を含むべきです。
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項を参照）、デフォルトで有効になってやSAは手動鍵管理を使用して構成されている場合されていると仮定します。送信者が時にシーケンス番号（またはESN）サイクル、またはこの値サイクリングを見越して新しいSAを確立するためにこのように、AH実装の典型的な動作が呼び出されます。
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を参照）を選択した場合、送信側と受信側の両方が完全な64ビットESNカウンタを維持するが、シーケンス番号の唯一の下位32ビットは、シーケンス番号フィールドで送信されます。しかし、上位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
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)
（緩んでいるか、厳密なソースルーティングで）可変だが予測可能Destination Address
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）（フラグフラグメントライブする時間オフセットを（RFC 3168 [RFB01]を参照、2ビット）明示的輻輳通知（ECN）（6ビットは、RFC 2474 [NBBB98]を参照されたいです） 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.
（IPv6のとは違って）IPv4の場合、輸送中の可変などのオプションをタグ付けするためのメカニズムがありません。従って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)
（ルーティング拡張ヘッダ付き）可変だが予測可能Destination Address
Mutable (zeroed prior to ICV calculation) DSCP (6 bits, see RFC2474 [NBBB98]) ECN (2 bits, see RFC3168 [RFB01]) Flow Label (*) Hop Limit
可変（ゼロICV計算に先立って）DSCPフローラベル（*）ホップリミット（RFC3168 [RFB01]を参照して、2ビット）ECN（6ビットは、RFC2474 [NBBB98]を参照します）
(*) 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.
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
でIPv6オプション拡張ヘッダーオプションが輸送中（予測できない）変更される可能性があるかどうかを示すビットが含まれているホップバイホップと宛先。 ICVを計算または検証するとき内容は、EN-経路変更することができるため、任意のオプションのために、全体の「オプションデータ」フィールドは、ゼロ値のオクテットとして扱わなければなりません。ザ・
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.
オプションタイプとオプトデータレンは、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で述べたようにAHヘッダが32ビット（IPv4）の64ビット（IPv6）のの倍数であることを保証するために必要であれば、ICVフィールドは、明示的なパディングを含むことができます。パディングが必要な場合は、その長さは2つの要素によって決定されます。
- the length of the ICV
- the IP protocol version (v4 or 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
いくつかの整合性アルゴリズムの場合は、ICVの計算が行われた上で、バイト文字列は、アルゴリズムによって指定されたブロックサイズの倍数でなければなりません。 （有効な場合、AHおよびESNの上位32ビットを含む）は、IPパケットの長さはアルゴリズムのブロックサイズ要件と一致しない場合、暗黙のパディングが前ICV計算に、パケットの最後に追加されなければなりません。パディングオクテット
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.
ゼロの値を持たなければなりません。ブロックサイズ（従って、パディングの長さ）は、アルゴリズムの仕様によって指定されます。このパディングはパケットで送信されていません。完全性アルゴリズムを定義文書は、上記のように、暗黙のパディングが必要であるかどうかを決定するために調べなければなりません。文書はこの答えを指定しない場合、デフォルトでは、暗黙のパディングがパディングバイトが必要な場合（アルゴリズムのブロックサイズにパケット長を一致させることができます。必要に応じて）が、アルゴリズムは、パディングの内容を指定していないが必要であると仮定することです、その後、パディングオクテットはゼロの値を持つ必要があります。
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.
必要な場合は、IPフラグメンテーションは、IPsec実装内でAH処理後に発生します。このように、トランスポートモード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実装は断片化をサポートし、DFビットで送信されたパケットをマークすることができる、パスMTU（PMTU）の発見を容易にするためではないことを選択してもよいです。いずれの場合においても、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の仕様では、オフセットフィールドをゼロ化またはMORE FRAGMENTSフラグのクリアのいずれかを必要としません。それは、パケットを再構成した後に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を決定します。セクション2.4で説明したように、ユニキャストSAのために、この決意は、SPIまたはSPIプラスプロトコルフィールドに基づいています。実装はマルチキャストトラフィックをサポートしている場合は、送信先アドレスは、（SPIに加えて）ルックアップで採用されており、2.4節で説明したように、送信者のアドレスも、使用することができます。 （このプロセスは、セキュリティアーキテクチャ文書においてより詳細に記載されている。）SAのSADエントリはまた、シーケンス番号フィールドがチェックされるかどうかを示し、32ビットまたは64ビットのシーケンス番号は、SAのために使用されているかどうか。 SAのためのSADエントリも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.)
（SA管理トラフィックは、例えばIKEパケットとして、例えば、すなわち、一方は別々に次のプロトコルおよびポートフィールドに基づいてこのトラフィックを逆多重化することができ、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.
その使用はSA毎に受信側によって有効または無効にすることができるものの、すべてのAH実装は、アンチリプレイサービスをサポートしなければなりません。アンチリプレイは、マルチキャストのSAだけでなく、ユニキャストに適用可能です。しかし、この規格は、マルチ送信者SA（ユニキャストまたはマルチキャスト）するためのアンチリプレイを提供するための機構を指定しません。そのようなSAのためのアンチリプレイ機構のネゴシエーション（または手動設定）の非存在下では、以下に記載のようにSAのシーケンス番号の送信者と受信者チェックは、（ネゴシエーションまたは手動設定を介して）無効にすることが推奨されます。
If the receiver does not enable anti-replay for an SA, no inbound checks are performed on the Sequence Number. However, from the perspective of the sender, the default is to assume that anti-replay is enabled at the receiver. To avoid having the sender do unnecessary sequence number monitoring and SA setup (see Section 3.3.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のためのアンチリプレイを有効にしない場合、インバウンドチェックはシーケンス番号に実行されません。しかし、送信者の視点から、デフォルトではアンチリプレイが受信機で有効になっていると仮定することです。送信者を避けるようIKEなどのSA確立プロトコルが使用される場合、不必要なシーケンス番号監視およびSAのセットアップ（セクション3.3.2を参照して、「シーケンス番号の生成」）を行い、受信機は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チェックであるべきである（SHOULD）。
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.)
ESNオプションがSAのために選択された場合、シーケンス番号の唯一の下位32ビットは、明示的に送信するが、受信機は、彼のローカルカウンタから指示SAのための上位32ビットを使用して計算フルシーケンス番号を（採用されています）受信ウィンドウに対して受信したシーケンス番号を確認するとき。下位32ビットはパケットで運ばれた場合に、フルシーケンス番号を構築する際に、受信機のシーケンス番号カウンタの下位32ビットよりも価値が低い、受信機は、上位32ビットがインクリメントされていることを前提とし、新しいシーケンス番号部分空間に移動します。 （このアルゴリズムは、単一のSAとして大32-1 ** 2としてパケットの受信のギャップを収容している。大きなギャップが発生した場合は、付録に記載されているように、受信機のシーケンス番号カウンタの再同期のための追加、ヒューリスティックチェックは、使用することができます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.
計算された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.)
実装は、以下のステップのセットと同じ結果をもたらすステップの任意のセットを使用することができます。ゼロ（任意のICVフィールドのパディングではなく）ICV値を保存し、それを置き換えることから始めます。輸送中に変更された可能性がゼロで他のすべてのフィールド。 （フィールドはICV計算を実行する前にゼロにしているの議論については、「変更可能なフィールドの処理」、3.3.3.1項を参照してください。）
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.)
ESNオプションがこのSAのために選出されている場合は、パケットの終了後に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の構文と処理を実装しなければならない、とセキュリティアーキテクチャ文書[ケン-ARCH]のすべての要件を遵守しなければなりません。実装は、マルチキャストトラフィックをサポートするために主張した場合また、そのようなトラフィックのサポートのために指定された追加要求事項を遵守しなければなりません。 ICVを計算するために使用されるキーを手動で分散されている場合、アンチリプレイサービスの正しい提供は鍵が交換されるまで、送信側のカウンタ状態の正確なメンテナンスを必要とする、とそうであれば何の自動回復の規定はないだろうカウンタのオーバーフロー目前に迫りました。このように、準拠した実装は手動鍵管理されるSAで、このサービスを提供すべきではありません。
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].
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.
RFCの1825-1827：著者は、最初のIPsec活動に重要な役割を果たし、およびIPsec規格の最初のシリーズを執筆蘭アトキンソンの貢献を認めたいと思います。カレンソはこれを編集し、この仕様の以前のバージョンでヘルプを提供するための特別な感謝に値します。著者はまた、このプロトコル仕様の発展に貢献したIPsecとMSECワーキンググループのメンバーに感謝したいと思います。
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[Bra97]ブラドナーの、S.、BCP 14、RFC 2119、1997年3月 "のRFCsにおける使用のためのキーワードは、要求レベルを示すために"。
[DH98] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[DH98]デアリング、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]第三イーストレイク、D.、RFC 4305、2005年12月 "カプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）のための暗号アルゴリズム実装要件"。
[Ken-Arch] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[ケン-アーチ]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]ポステル、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]ケント、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]のAdvanced Encryption Standard（AES）、連邦情報処理標準197、標準技術、2001年11月26日の国立研究所。
[HC03] Holbrook, H. and B. Cain, "Source Specific Multicast for IP", Work in Progress, November 3, 2002.
[HC03]ホルブルック、H.、およびB.カイン、 "IPのためのソース固有マルチキャスト"、進歩、2002年11月3日での作業。
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2の]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[Ken-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[ケン-ESP]ケント、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]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "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.
"IPに明示的輻輳通知の添加（ECN）" [RFB01]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。
[RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP MTU discovery options", RFC 1063, July 1988.
[RFC1063]ムガール人、J.、ケント、C.、ヤマウズラ、C.、およびK. McCloghrie、 "IP MTUディスカバリオプション"、RFC 1063、1988年7月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC1385] Wang, Z., "EIP: The Extended Internet Protocol", RFC 1385, November 1992.
[RFC1385]王、Z.、 "EIP：拡張インターネット・プロトコル"、RFC 1385、1992年11月。
[RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393, January 1993.
[RFC1393]マルキン、G.、 "tracerouteのIPオプションの使用"、RFC 1393、1993年1月。
[RFC1770] Graff, C., "IPv4 Option for Sender Directed Multi-Destination Delivery", RFC 1770, March 1995.
[RFC1770] Graffの、C.、RFC 1770 "送信者監督マルチ先の配達のためのIPv4オプション"、1995年3月。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113]カッツ、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.、ヴァイス、B.、Hardjono、T.、およびH.ハーニー、 "解釈のグループドメイン"、RFC 3547、2003年7月。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC3740] Hardjono、T.とB.ウィス、 "マルチキャストグループのセキュリティアーキテクチャ"、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つの参照が提供される場合には、もう一つは第一に優先します。このテーブルは、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
代わら、実験 - 1 0 8ストリームID [RFC791、RFC1122（ホストREQ）] 0 11 MTUプローブ[RFC1063、RFC1191（PMTU）] 0 12 MTU返信[RFC1063、RFC1191（PMTU）] 1 0 17拡張をゼロインターネットプロトコル[RFC1385、DH98（IPv6）の] 0 10実測1 2 13実験フロー制御1回の0 14回の実験アクセスのCtl 0 0 15？ 1 0 16 IMIトラフィック記述子1 0 19アドレス拡張
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.
注：としてこれらのIPオプションの分類とパケットのパスの競合に沿ってシステムによる追加またはセキュリティラベルの除去（例えば、基本的なセキュリティ・オプション（BSO）、拡張セキュリティオプション（ESO）、または商用インターネットプロトコルセキュリティオプション（CIPSO））不変と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]
OPTIONは、可変（予測できない輸送中CHANGES）ホップバイホップオプション[DH98]宛先オプションであればBITが示す[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.
オプション - ホップバイホップでのIPv6オプションと宛先拡張ヘッダーは、オプションが輸送中（予測できない）変更される可能性があるかどうかを示すビットが含まれています。 ICVを計算または検証するときにコンテンツが途中で変更することができるため、任意のオプションのために、全体の「オプションデータ」フィールドは、ゼロ値のオクテットとして扱わなければなりません。オプションタイプとオプトデータレンは、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.4）の前に発生するアウトバウンドIPsec処理（セクション3.3）と再組立後に生じます。だから、フラグメンテーション拡張ヘッダは、それが存在する場合は、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.
送信側なお、0（最初の断片）のオフセットを用いて、IPの実装は、IPsecコードをフラグメンテーション拡張ヘッダを持つパケットを与えることができると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ビットのシーケンス番号を使用するが、これだけ下位32ビットは、各パケットの一部として送信されたIPsec（ESPおよびAH）で使用するための拡張シーケンス番号（ESN）方式が記載されています。これは、リプレイパケットを検出するために使用されるウィンドウ方式及び再生拒絶および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.のアンチリプレイウィンドウを維持します。 （NO要件が既に32ビットのシーケンス番号のウィンドウのために確立さ32および64のパケット値を超えて、このウィンドウの最小値または推奨サイズのために確立されていない。しかし、実装規模がインタフェース速度と一致して、これらの値がサポートすることが示唆されていますESNオプションを利用して実装することにより、また、以下に説明するアルゴリズムは、ウィンドウの幅が大きくない31 ^ 2よりもパケットであることを前提としている。）上位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）。この場合、ウィンドウは、一つのシーケンス番号の部分空間内にあります。 +ケースB（図1参照）：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 + 1 *********
Th =======*****
第======= *****
--0--------+-----+-----0--------+-----------0--
Bl Tl Bl
(Bl+2^32) mod 2^32
Figure 1 -- Case A
図1 - ケースA
Th ====**************
第==== **************
Th-1 ===
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に対応し、TlのスルーBLから各シーケンス番号は、対応するビットによって表されます。リプレイを検出して排除することができるように、ビットの値は、そのシーケンス番号を持つパケットを受信し、認証されたか否かを示します。
When a packet with a 64-bit sequence number (Seq) greater than T is received and validated,
場合、64ビットのシーケンス番号（SEQ）Tより大きいが受信され検証されたパケット、
+ 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（配列 - T）だけ増加させる+（配列 - T）ビットがウィンドウ+の下端から落下（配列 - 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（ここでB1を= Tlの - W + 1）AND Seql <= T1が、このSeqlが既に見られているかどうかを見るためにウィンドウ内の対応するビットをチェックします。 yesの場合、パケットを拒否します。いいえ、整合性チェックを実行した場合（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（ここでB1を= Tlの - W + 1）場合、またはSeql <= T1は、このSeqlが既に見られているかどうかを見るためにウィンドウ内の対応するビットをチェックします。 yesの場合、パケットを拒否します。いいえ、整合性チェックを実行した場合（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（ここでB1を= Tlの - W + 1）、次いでSEQH = Thの場合Seql <BL（ここでB1を= 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（ここでB1を= Tlの - W + 1）、次いでSEQH = Thの - 1 Seql <BL（ここでB1を= 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ビットの符号なし整数です。算術演算は、2 ^ 32のmodです。
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
Else
If (pass integrity check)
Tl = Seql (shift bits)
Set the bit corresponding to Seql
Pass packet on
Else reject packet
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）ペイロードの後に配置されているので（それはペイロードのエンドポイントまでのパケットにわたって完全性アルゴリズムを実行することによって、この手順を最適化することが可能であってもよいし、その値を変化させることによって、異なる候補たICVを計算します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
スティーブン・ケントBBNテクノロジーズ10モールトンストリートケンブリッジ、MA 02138 USA
Phone: +1 (617) 873-3988 EMail: kent@bbn.com
電話：+1（617）873-3988 Eメール：kent@bbn.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。