サイト内関連リンク：
RFC 791 IP(日本語訳)
RFC 4301 IPsec(日本語訳)
RFC 4303 ESP(日本語訳)
原文：ftp://ftp.rfc-editor.org/in-notes/rfc4302.txt
原文との対訳として読みたい方へ：このページをローカルに保存して、スタイルシートの original クラスの display 属性を none から block に変更してみてください。
2009/11/19 0.1.0 初版
2012/01/14 0.2.0 RFC 4303の翻訳に合わせて全体を見直しました。
ソーシャルブックマーク：
サイト内関連リンク：
RFC 791 IP(日本語訳)
RFC 4301 IPsec(日本語訳)
RFC 4303 ESP(日本語訳)
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. この文書はインターネットコミュニティのためのインターネット標準トラックプロトコルについて述べており、改良に向けての議論と提案を求めている。このプロトコルの標準化の状態と状況については "Internet Official Protocol Standards" (STD 1)を参照してほしい。この文書の配布に制限はない。
Copyright (C) The Internet Society (2005).
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 認証ヘッダの最新版を説明している。この文書は RFC 2402 (1998年11月)を廃止する。
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. 本文書は、読者が "Security Architecture for the Internet Protocol" [Ken-Arch] (以降、セキュリティアーキテクチャ文書と呼ぶ)で説明されている用語と概念とに精通していることを前提としている。特にカプセル化セキュリティペイロード(ESP)[Ken-ESP] と IP 認証ヘッダ(AH)とによって提供されるセキュリティサービスの定義、セキュリティアソシエーションの概念、認証ヘッダ(AH)と同時に ESP を使用する方法、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]. 文書中のキーワード MUST、 MUST NOT、 REQUIRED、 SHALL、 SHALL NOT、 SHOULD、 SHOUL NOT、 RECOMMENDED、 MAY、 OPTIONAL は、それぞれ RFC 2119 [Bra97] で説明されている通りに解釈される。
The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just "integrity") and to provide protection against replays. This latter, optional service may be selected, by the receiver, when a Security Association (SA) is established. (The protocol default requires the sender to increment the sequence number used for anti-replay, but the service is effective only if the receiver checks the sequence number.) However, to make use of the Extended Sequence Number feature in an interoperable fashion, AH does impose a requirement on SA management protocols to be able to negotiate this new feature (see Section 2.5.1 below). IP 認証ヘッダ(AH)は、IP データグラムのためのコネクションレス完全性とデータ送信元認証(以降、単に "完全性(integrity)" と記述する)、およびリプレイに対する保護を提供するために使用される。後者のオプションサービスは、セキュリティアソシエーション(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)[Ken-ESP]と組み合わせて、またはネストさせて(セキュリティアーキテクチャ文書 [Ken-Arch] 参照)適用できる。セキュリティサービスは、通信するホストの組の間、通信するセキュリティゲートウェイの間、セキュリティゲートウェイとホストとの間で提供できる。ESP も同じアンチリプレイと、同じような完全性サービスとを提供し、また機密性(暗号化)サービスも提供する。ESP と AH とにより提供される完全性の主な違いは、その適用範囲である。具体的にいうと、ESP は(例えばトンネルモードを使用して)ESP によってカプセル化されない限り、IP ヘッダフィールドを保護しない。さまざまなネットワーク環境における AH および ESP の使用法の詳細は、セキュリティアーキテクチャ文書 [Ken-Arch] を参照してほしい。
Section 7 provides a brief review of the differences between this document and RFC 2402 [RFC2402]. セクション 7 は、本文書と RFC 2402 [RFC2402] との間の違いの簡単な説明を提供している。
The protocol header (IPv4, IPv6, or IPv6 Extension) immediately preceding the AH header SHALL contain the value 51 in its Protocol (IPv4) or Next Header (IPv6, Extension) fields [DH98]. Figure 1 illustrates the format for AH. AH ヘッダに先行する直前のプロトコルヘッダ(IPv4、IPv6、IPv6 拡張)は、そのプロトコルフィールド(IPv4)または次ヘッダフィールド(IPv6、IPv6 拡張)[DH98]に値 51 を含むべきである(SHALL)。図 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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 次ヘッダ | ペイロード長 | 予約済み |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| セキュリティパラメータインデックス (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| シーケンス番号フィールド |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ 完全性検査値 ICV (可変長) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
図 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. 以下の表は、AH を構成するフィールド(図 1 で説明されている)と完全性の計算に含まれるその他のフィールドとを表し、またどのフィールドが ICV によって網羅され、何が送信されるのかを説明している。
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
バイト数 必須[1] 完全性 送信内容
-------- ------ ------ ------------
IP ヘッダ 可変 M [2] そのまま
次ヘッダ 1 M Y そのまま
ペイロード長 1 M Y そのまま
予約済み 2 M Y そのまま
SPI 4 M Y そのまま
シーケンス番号 4 M Y そのまま
(下位 32 ビット)
ICV 可変 M Y[3] そのまま
IP データグラム [4] 可変 M Y そのまま
シーケンス番号 4 ESN なら Y 送信されない
(上位 32 ビット)
ICV パディング 可変 必要なら Y 送信されない
[1] - M = 必須
[2] - どの IP ヘッダフィールドが網羅されるかに付いての詳細は
セクション 3.3.3 "完全性検査値の計算" を参照
[3] - ICV 計算の前にゼロにされる
(計算後に結果の ICV がここに置かれる)
[4] - トンネルモードの場合 -> IP データグラム
トランスポートモードの場合 -> 次のヘッダとデータ
The following subsections define the fields that comprise the AH format. All the fields described here are mandatory; i.e., they are always present in the AH format and are included in the Integrity Check Value (ICV) computation (see Sections 2.6 and 3.3.3). 以降のセブセクションは、AH フォーマットを構成するフィールドを定義する。ここで説明されているフィールドはすべて必須である。つまり、それらは常に AH フォーマットに現れ、完全性検査値(ICV)(セクション 2.6 および 3.3.3 参照)の計算に含まれる。
Note: All of the cryptographic algorithms used in IPsec expect their input in canonical network byte order (see Appendix of RFC 791 [RFC791]) and generate their output in canonical network byte order. IP packets are also transmitted in network byte order. 注意：IPsec で使用される暗号化アルゴリズムは、入力が標準的なネットワークバイトオーダー(RFC 791 [RFC791] の付録参照)であることを期待し、出力も標準的なネットワークバイトオーダーで生成する。IP パケットもネットワークバイトオーダーで転送される。
AH does not contain a version number, therefore if there are concerns about backward compatibility, they MUST be addressed by using a signaling mechanism between the two IPsec peers to ensure compatible versions of AH, e.g., IKE [IKEv2] or an out-of-band configuration mechanism. AH はバージョン番号を含まないため、下位互換性の懸念がある場合に互換性のある AH のバージョンを保証するために、二つの IPsec ピア間の伝達メカニズム(例えば IKE [IKEv2])、または帯域外の構成メカニズムを使用して指定されなければならない(MUST)。
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)のウェブページ上で定義されている 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 バイト)単位の AH の長さから "2" を引いた値を表す。つまり、例えば完全性アルゴリズムが 96 ビットの認証値を生成した場合、このフィールドは "4" となる(3 つの 32 ビット固定フィールドと ICV のための 3 つの 32 ビットワードとから 2 を引く)。IPv6 の場合、ヘッダの全長は必ず 8 オクテット単位の倍数になる。(IPv6 [DH98] が AH を拡張ヘッダと見なす場合でも、その長さは他の IPv6 拡張ヘッダによって使用される 64 ビットワードではなく、32 ビットワード単位で計測される。) このフィールドのパディングに付いての説明はセクション 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 ビットのフィールドは将来のために予約されている。送信者は "ゼロ(zero)" をセットしなければならず(MUST)、受信者は無視するべきである(SHOULD)。(ICV の計算には含まれるが、それ以外では受信者によって無視されることに注意してほしい。)
The SPI is an arbitrary 32-bit value that is used by a receiver to identify the SA to which an incoming packet is bound. For a unicast SA, the SPI can be used by itself to specify an SA, or it may be used in conjunction with the IPsec protocol type (in this case AH). Because for unicast SAs the SPI value is generated by the receiver, whether the value is sufficient to identify an SA by itself or whether it must be used in conjunction with the IPsec protocol value is a local matter. The SPI field is mandatory, and this mechanism for mapping inbound traffic to unicast SAs described above MUST be supported by all AH implementations. SPI は任意の 32 ビット値であり、入力パケットがどの SA に対応するのかを識別するために受信者によって使用される。ユニキャスト SA の場合、SPI はそれ自体で SA を特定するために使用できるか、IPsec プロトコル種別(この場合は AH)と合わせて使用することができる。ユニキャスト SA の場合は受信者が SPI 値を生成するため、その値がそれ自体で SA を特定するのに十分かどうか、または IPsec プロトコル値と合わせて使用されなければならないかどうかは、ローカルの問題である。SPI フィールドは必須であり、入力トラフィックをユニキャスト SA にマッピングするための上記のメカニズムは、すべての AH 実装によってサポートされなければならない(MUST)。
If an IPsec implementation supports multicast, then it MUST support multicast SAs using the algorithm below for mapping inbound IPsec datagrams to SAs. Implementations that support only unicast traffic need not implement this de-multiplexing algorithm. IPsec 実装がマルチキャストをサポートする場合、複数の入力 IPsec データグラムを複数の SA にマッピングするための後述のアルゴリズムを使用するマルチキャスト SA をサポートしなければならない(MUST)。ユニキャストトラフィックのみをサポートする実装は、この分離アルゴリズムを実装する必要はない。
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])では、中央の Group Controller/Key Server がグループセキュリティアソシエーションの SPI を一方的に割り当てる。この SPI の割り当ては、そのグループを含む各エンドシステム内にある鍵管理(例えば IKE)サブシステムとの交渉や連携を行わない。その結果として、グループセキュリティアソシエーションとユニキャストセキュリティアソシエーションとが同じ SPI を同時に使用することができる。マルチキャスト能力を持つ IPsec 実装は、SPI が衝突するそのような状況でも入力トラフィックを正しく分離しなければならない(MUST)。
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)[Ken-Arch]内の各エントリは、SA 検索が SPI に加えて宛先 IP アドレスまたは宛先・送信元 IP アドレスのどちらを使用するのかを表さなければならない。マルチキャスト SA の場合、プロトコルフィールドは SA 検索に採用されない。入力の IPsec 保護されたパケットごとに、実装は "最長の(longest)" SA 識別子に一致するエントリを見つけるために SAD 検索を行わなければならない。このような状況において、SPI 値に基づくと二つ以上の SAD エントリが一致する場合、宛先、または宛先/送信元のアドレス比較(SAD エントリ内で示されている通り)に基づいて一致したエントリが、"最長の(longest)" 一致である。これは、以下のような SAD 検索の論理的順序を意味する：
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. 実際には、実装はこの検索を高速化するための任意の手段を選択してよい(MAY)。ただしその外見的な振る舞いは、上記の順序で SAD を検索した場合と機能的に等しくなければならない(MUST)。例えばソフトウェアベースの実装は、ハッシュテーブルに SPI によるインデックスを付けられるだろう。ハッシュテーブルの各リンクリスト内の SAD エントリが、そのリンクリスト内で最長の SA 識別子を持つ SAD エントリを先頭に持つようにソートされた状態を維持する。最短の SAD 識別子を持つ 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. 入力 IPsec トラフィックを SA にマッピングするために送信元・宛先アドレスのマッチングが必要かどうかの指示は、手動 SA 構成によってか、SA 管理プロトコル(例えば IKE や、Group Domain of Interpretation (GDOI)[RFC3547])による交渉を通して設定されなければならない(MUST)。一般に、Source-Specific Multicast (SSM) [HC03] グループは、SPI・宛先マルチキャストアドレス・送信元アドレスから成る 3 要素の SA 識別子を使用する。Any-Source Multicast グループ SA は、識別子として SPI・宛先マルチキャストアドレスだけを必要とする。
The set of SPI values in the range 1 through 255 is reserved by the Internet Assigned Numbers Authority (IANA) for future use; a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. The SPI value of zero (0) is reserved for local, implementation-specific use and MUST NOT be sent on the wire. (For example, a key management implementation might use the zero SPI value to mean "No Security Association Exists" during the period when the IPsec implementation has requested that its key management entity establish a new SA, but the SA has not yet been established.) 1 ～ 255 の範囲の SPI 値は、Internet Assigned Numbers Authority (IANA) によって将来のために予約されている。通常、予約済みの SPI 値は RFC において規定されない限り IANA によって割り当てられることはない。ゼロ(0)の SPI 値はローカルの実装固有の用途に予約されており、送信されてはならない(MUST NOT)。(例えば鍵管理の実装は、IPsec 実装が自身の鍵管理エンティティが新しい SA の確立を要求したが、まだそれが確立されていない間に、"セキュリティアソシエーションが存在しない(No Security Association Exists)")ことを表すために、ゼロの 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 の場合、送信者はパケット送信ごとにこのフィールドをインクリメントしなければならない(MUST)。複数の送信者間で SA を共有してもよいが、一般には推奨されない。AH は、複数送信者間でパケットカウンタを同期する手段も、複数送信者の状況において受信者パケットのカウンタおよびウィンドウの意味のある管理手段も提供しない。したがって複数送信者 SA の場合、AH のアンチリプレイ機能(※)は使用できない(セクション 3.3.2 および 3.4.3 参照)。
(※ 訳注：原文では「anti-reply」(アンチリプライ)となっていますが、多分間違いだと思います。)
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 のためにアンチリプレイサービスを有効にしていない場合でも、常に現れなければならない(MUST)。シーケンス番号フィールドの処理は受信者の裁量だが、すべての AH 実装はセクション 3.3.2 ("シーケンス番号の生成")およびセクション 3.4.3 ("シーケンス番号の検証")で説明されている処理を実行する能力を持たなければならない(MUST)。したがって送信者は常にこのフィールドを送信しなければならない(MUST)が、受信者がそれに基づいて動作する必要はない。
The sender's counter and the receiver's counter are initialized to 0 when an SA is established. (The first packet sent using a given SA will have a sequence number of 1; see Section 3.3.2 for more details on how the sequence number is generated.) If anti-replay is enabled (the default), the transmitted sequence number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA. 送信側のカウンタと受信側のカウンタは、SA の確立時に 0 に初期化される。(ある SA を使用して送信される最初のパケットはシーケンス番号 1 を持つことになる。シーケンス番号の生成方法に付いての詳細はセクション 3.3.2 を参照してほしい。) アンチリプレイが有効な場合(デフォルトは有効である)、転送されるシーケンス番号は決して循環してはならない。したがって送信側のカウンタと受信側のカウンタは、ひとつの SA 上で 2^32 番目のパケットが転送される前に(新しい鍵で新しい SA を確立することで)リセットされなければならない(MUST)。
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 ビットシーケンス番号フィールドの拡張として、シーケンス番号の新しい選択肢を提供するべきである(SHOULD)。拡張シーケンス番号(ESN)の使用は、SA 管理プロトコルによって交渉されなければならない(MUST)。IKEv2 ではこの交渉は暗黙的に行われ、32 ビットシーケンス番号が明示的に交渉されない限り、デフォルトで ESN が使用されることに注意してほしい。(ESN 機能はマルチキャスト SA にもユニキャスト 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 ビットシーケンス番号が使用可能になる。(詳細は付録 B "拡張(64 ビット)シーケンス番号"を参照してほしい。) 各パケットの AH ヘッダ内ではシーケンス番号の下位 32 ビットのみが転送されるため、パケットのオーバーヘッドは最小化される。上位 32 ビットは送信者および受信者の両方によってシーケンス番号の一部として保持され、ICV の計算には含まれるが、転送はされない。
This is a variable-length field that contains the Integrity Check Value (ICV) for this packet. The field must be an integral multiple of 32 bits (IPv4 or IPv6) in length. The details of ICV processing are described in Section 3.3.3, "Integrity Check Value Calculation", and Section 3.4.4, "Integrity Check Value Verification". This field may include explicit padding, if required to ensure that the length of the AH header is an integral multiple of 32 bits (IPv4) or 64 bits (IPv6). All implementations MUST support such padding and MUST insert only enough padding to satisfy the IPv4/IPv6 alignment requirements. Details of how to compute the required padding length are provided below in Section 3.3.3.2, "Padding". The integrity algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation. これはパケットのための完全性検査値(ICV)を含む可変長フィールドである。このフィールドの長さは 32 ビットの整数倍でなければならない(IPv4 または IPv6 の場合)。ICV の処理の詳細は、セクション 3.3.3 "完全性検査値の計算"、およびセクション 3.4.4 "完全性検査値の検証" で説明される。AH ヘッダの長さが 32 ビット(IPv4)または 64 ビット(IPv6)の整数倍になることを保証するために必要であれば、このフィールドは明示的なパディングを含んでもよい。すべての実装はこのパディングをサポートしなければならず(MUST)、また IPv4/IPv6 のアラインメント要件を満たすために必要なだけのパディングのみを挿入しなければならない(MUST)。必要なパディング長を計算する方法の詳細は、セクション 3.3.3.2 に示されている。完全性アルゴリズムの仕様は、ICV の長さ・比較規則・検証の処理ステップを規定しなければならない(MUST)。
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 ----->|
AH 適用前
---------------------------------
IPv4 |元の IP ヘッダ | | |
|(任意のオプション)| TCP | Data |
---------------------------------
AH 適用後
---------------------------------------------------------
IPv4 |元の IP ヘッダ(任意のオプション) | AH | TCP | データ |
---------------------------------------------------------
|<- 可変フィールド処理 ---------->|<- 不変フィールド --->|
|<----- 可変フィールドを除いて認証される --------------->|
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 適用前
------------------------------------------
IPv6 | |もしあれば| | |
| 元の IP ヘッダ |拡張ヘッダ| TCP |データ|
------------------------------------------
AH 適用後
------------------------------------------------------------
IPv6 | |hop-by-hop, dest*, | | dest | | |
|元のIPヘッダ |routing, fragment. | AH | opt* | TCP |データ|
------------------------------------------------------------
|<--- 可変フィールド処理 -------->|<-- 不変フィールド -->|
|<---- 可変フィールドを除いて認証される ------------------>|
* = もしあれば AH の前、AH の後、または両方に
hop-by-hop = ホップバイホップ
routing = ルーティング
fragment. = フラグメンテーション
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-stack" または "bump-in-the-wire" の実装(セキュリティアーキテクチャ文書で定義されている通り)の場合、入力および出力の IP フラグメントは、本仕様に従うために、および透過的な IPsec サポートを提供するために、IPsec 実装が追加の IP 再構築/フラグメント化を実行することを必要としてもよい。複数のインターフェイスを使用する場合、これらの実装内でこのような操作を実行するには特別な配慮が必要である。
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. トンネルモードでは "内側(inner)" の IP ヘッダが最終的な(IP)送信元/宛先アドレスを運び、"外側(outer)" の IP ヘッダは IPsec "ピア(peers)" のアドレス(つまりセキュリティゲートウェイのアドレス)を含む。内側と外側とで IP のバージョンが混在してもよい(つまり、IPv4 上の IPv6、IPv6 上の IPv4)。トンネルモードでは、AH は内側の IP パケット全体を、内側の IP ヘッダ全体を含めて保護する。トンネルモードにおける AH の(外側の IP ヘッダとの相対的な)位置は、トランスポートモードにおける 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.
---------------------------------------------------------------
IPv4 |新しい IP ヘッダ * | | 元の IP ヘッダ* | | |
| (任意のオプション) | AH | (任意のオプション)|TCP|データ|
---------------------------------------------------------------
|<- 可変フィールド処理 ->|<------ 不変フィールド ----->|
|<- 新しい IP ヘッダ内の可変フィールドを除いて認証される ->|
-----------------------------------------------------------------
IPv6 | 新しい |もしあれば | | 元の |もしあれば | | |
| IP ヘッダ*|拡張ヘッダ*| AH | IP ヘッダ*|拡張ヘッダ*|TCP|データ|
-----------------------------------------------------------------
|<- 可変フィールド処理 ->|<--------- 不変フィールド -------->|
|<-- 新しい IP ヘッダ内のフィールドを除いて認証される ->|
* = もしあれば、外側の IP ヘッダ/拡張の構築および内側の
IP ヘッダ/拡張の変更は、セキュリティアーキテクチャ文書
で議論される。
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-256 など)に基づく鍵化メッセージ認証コード(Message Authentication Codes)(MAC)が含まれる。マルチキャスト通信に完全性を提供するためのさまざまな暗号戦略が開発されており、この分野の研究が続いている。
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 は、そのパケットが AH 処理を求める SA に対応すると IPsec 実装が判断した後にのみ出力パケットに適用される。出力トラフィックにどの 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. アンチリプレイが有効な場合(デフォルトで使用可能)、送信側はシーケンス番号フィールドに新しい値を挿入する前に、カウンダが循環していないことを確認する。言い換えると、送信者はシーケンス番号の循環を起こすようなパケットを送信してはならない(MUST NOT)。シーケンス番号のオーバーフローを引き起こすパケットの送信の試みは監査可能なイベントである。このイベントのための監査ログエントリは、SPI 値、現在の日付/時刻、送信元アドレス、宛先アドレス、(IPv6 の場合)平文のフロー ID を含むべきである(SHOULD)。
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 が手動鍵管理を使用して構成されている場合を除き、デフォルトでアンチリプレイが使用可能であると仮定する。したがって AH 実装の典型的な振る舞いは、シーケンス番号(または ESN)が循環するとき、またはその値の循環が予想されるときに、送信者に新しい SA の確立を要求するというものである。
If anti-replay is disabled (as noted above), the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5). However, the sender still increments the counter and when it reaches the maximum value, the counter rolls over back to zero. (This behavior is recommended for multi-sender, multicast SAs, unless anti-replay mechanisms outside the scope of this standard are negotiated between the sender and receiver.) アンチリプレイが無効な場合(前述の通り)、送信側がカウンタを監視したりリセットしたりする必要はない。例えば手動鍵管理(セクション 5 参照)の場合がそうである。しかしながら、それでも送信側はカウンタをインクリメントし、それが最大値に達したとき、カウンタをゼロに戻す。(送信者と受信者との間で本標準の範囲外のアンチリプレイメカニズムが交渉されていない限り、この振る舞いは複数送信者のマルチキャスト SA に推奨される。)
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 ビットのみがシーケンス番号フィールドで転送される。しかしながら、ICV の計算には上位 32 ビットも含まれる。
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 を交渉するべきではない(SHOULD NOT)。ESN を使用することで受信側がアンチリプレイウィンドウを管理する必要性が生じる(ESN (これは ICV 計算に採用される)の上位ビットの正しい値を決定するためである)。一般にこれは、SA のためのアンチリプレイを無効にする発想の対極にある。
The AH ICV is computed over: AH ICV は以下に関して計算される：
If a field may be modified during transit, the value of the field is set to zero for purposes of the ICV computation. If a field is mutable, but its value at the (IPsec) receiver is predictable, then that value is inserted into the field for purposes of the ICV calculation. The Integrity Check Value field is also set to zero in preparation for this computation. Note that by replacing each field's value with zero, rather than omitting the field, alignment is preserved for the ICV calculation. Also, the zero-fill approach ensures that the length of the fields that are so handled cannot be changed during transit, even though their contents are not explicitly covered by the ICV. 転送中に変更される可能性のあるフィールドの場合、ICV の計算時にはそのフィールドにゼロをセットする。フィールドは可変だが、(IPsec の)受信側での値を予測可能な場合、ICV の計算時にはその値をフィールドに挿入する。完全性検査値フィールドにもこの計算の準備時点でゼロをセットする。フィールドを省略するのではなくその値をゼロに置き換えることで、ICV 計算のためのアラインメントが保持されることに注意してほしい。同様にこのゼロ埋めのアプローチは、そのように扱われるフィールドの長さが、たとえそれらの内容が明示的に ICV によってカバーされなくとも、転送中に変更できないことを保証する。
As a new extension header or IPv4 option is created, it will be defined in its own RFC and SHOULD include (in the Security Considerations section) directions for how it should be handled when calculating the AH ICV. If the IP (v4 or v6) implementation encounters an extension header that it does not recognize, it will discard the packet and send an ICMP message. IPsec will never see the packet. If the IPsec implementation encounters an IPv4 option that it does not recognize, it should zero the whole option, using the second byte of the option as the length. IPv6 options (in Destination Extension Headers or the Hop-by-Hop Extension Header) contain a flag indicating mutability, which determines appropriate processing for such options. 新しい拡張ヘッダまたは IPv4 オプションが生成される場合、それはそれ自体の RFC において定義され、それが AH ICV の計算時にどのように扱われるべきかの指示を(そのセキュリティ考察セクションに)含むべきである(SHOULD)。認識できない拡張ヘッダに遭遇した IP 実装(v4 または v6)は、そのパケットを破棄し、ICMP メッセージを送信するだろう。そのため IPsec はそのようなパケットに決して遭遇しないことになる。認識できない IPv4 オプションに遭遇した IPsec 実装 は、オプションの第 2 バイトを長さとして使用しながら、そのオプション全体をゼロにするべきである。IPv6 オプションは(宛先拡張ヘッダ(Destination Extension Header) またはホップバイホップ拡張ヘッダ(Hop-by-Hop Extension Header) 内に)変更可能性を表すフラグを含み、それがそのオプションの適切な処理を決定する。
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)
Mutable but predictable
Destination Address (with loose or strict source routing)
Mutable (zeroed prior to ICV calculation)
Differentiated Services Code Point (DSCP)
(6 bits, see RFC 2474 [NBBB98])
Explicit Congestion Notification (ECN)
(2 bits, see RFC 3168 [RFB01])
Flags
Fragment Offset
Time to Live (TTL)
Header Checksum
不変
Version
Internet Header Length
Total Length
Identification
Protocol (AH を表す値でなければならない)
Source Address
Destination Address (ルーズ/ストリクト ソースルーティングなし)
可変だか予測可能
Destination Address (ルーズ/ストリクト ソースルーティングあり)
可変 (ICV 計算の前にゼロにされる)
Differentiated Services Code Point (DSCP)
(6 ビット、RFC 2474 [NBBB98] 参照)
Explicit Congestion Notification (ECN)
(2 ビット、RFC 3168 [RFB01] 参照)
Flags
Fragment Offset
Time to Live (TTL)
Header Checksum
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. Flags - たとえ送信元が選択していなくても、中間ルータが 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). Fragment Offset - 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. Header Checksum - これは他のフィールドが変化すると変更される。したがって送信側は受信時の値を予測できない。
For IPv4 (unlike IPv6), there is no mechanism for tagging options as mutable in transit. Hence the IPv4 options are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable. For IPv4, the entire option is viewed as a unit; so even though the type and length fields within most options are immutable in transit, if an option is classified as mutable, the entire option is zeroed for ICV computation purposes. IPv4 の場合(IPv6 とは異なり)、転送中に変更可能なタグ付けオプションのメカニズムがない。そのため IPv4 のオプションは付録 A に明示的にリストされており、不変・可変だが予測可能・可変の何れかに分類されている。IPv4 ではオプション全体が一体と見なされる。そのため、大部分のオプション内のタイプおよびレングスが不変でも、あるオプションが可変に分類されるなら、ICV 計算のためにはオプション全体をゼロにする。
The IPv6 base header fields are classified as follows: IPv6 の基本ヘッダフィールドは以下のように分類される：
Immutable
Version
Payload Length
Next Header
Source Address
Destination Address (without Routing Extension Header)
Mutable but predictable
Destination Address (with Routing Extension Header)
Mutable (zeroed prior to ICV calculation)
DSCP (6 bits, see RFC2474 [NBBB98])
ECN (2 bits, see RFC3168 [RFB01])
Flow Label (*)
Hop Limit
(*) 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.
不変
Version
Payload Length
Next Header
Source Address
Destination Address (Routing Extension Header なし)
可変だが予測可能
Destination Address (Routing Extension Header あり)
可変 (ICV 計算の前にゼロにされる)
DSCP (6 ビット、RFC2474 [NBBB98] 参照)
ECN (2 ビット、RFC3168 [RFB01] 参照)
Flow Label (*)
Hop Limit
(*) AHv1 で説明されているフローラベルは可変であり、
また RFC 2460 [DH98] では潜在的に不変であった。
既存の AH 実装との互換性を保つために、フローラベルは
AHv2 の ICV に含まれていない。
IPv6 options in the Hop-by-Hop and Destination Extension Headers contain a bit that indicates whether the option might change (unpredictably) during transit. For any option for which contents may change en-route, the entire "Option Data" field must be treated as zero-valued octets when computing or verifying the ICV. The Option Type and Opt Data Len are included in the ICV calculation. All options for which the bit indicates immutability are included in the ICV calculation. See the IPv6 specification [DH98] for more information. ホップバイホップおよび宛先拡張ヘッダ内の IPv6 オプションは、オプションが転送中に(予測不能な)変更を受ける可能性があるかどうかを表すビットを含む。経路上で内容が変更される可能性のあるすべてのオプションに対して、その "オプションデータ(Option Data)" フィールド全体を、ICV の計算時または検証時に値ゼロのオクテットとして扱わなければならない。オプションタイプとオプションデータレングスは 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 フィールドに明示的なパディングを含むことができる。パディングが必要な場合、その長さは二つの要因から決定できる：
- the length of the ICV
- the IP protocol version (v4 or v6)
- ICV の長さ
- IP プロトコルのバージョン (v4 または v6)
For example, if the output of the selected algorithm is 96 bits, no padding is required for IPv4 or IPv6. However, if a different length ICV is generated, due to use of a different algorithm, then padding may be required depending on the length and IP protocol version. The content of the padding field is arbitrarily selected by the sender. (The padding is arbitrary, but need not be random to achieve security.) These padding bytes are included in the ICV calculation, counted as part of the Payload Length, and transmitted at the end of the ICV field to enable the receiver to perform the ICV calculation. Inclusion of padding in excess of the minimum amount required to satisfy IPv4/IPv6 alignment requirements is prohibited. 例えば選択されたアルゴリズムの出力が 96 ビットなら、IPv4 または IPv6 のためのパディングは必要ない。しかしながら、別のアルゴリズムの使用により異なる長さの ICV が生成された場合、その長さと IP プロトコルバージョンとに依存してパディングが必要となる。パディングフィールドの内容は送信者によって任意に選択される。(パディングの内容は任意だが、セキュリティのためにランダム値を取る必要はない。) これらのパディングバイトは ICV 計算に含まれ、ペイロード長の一部として計算され、受信側が ICV 計算を行うのを可能にするために ICV フィールドの終わりに転送される。IPv4/IPv6 のアラインメント要求を満たすために必要な最低限を超えてパディングを含むことは禁止されている。
If the ESN option is elected for an SA, then the high-order 32 bits of the ESN must be included in the ICV computation. For purposes of ICV computation, these bits are appended (implicitly) immediately after the end of the payload, and before any implicit packet padding. SA のために ESN オプションが選択されている場合、ESN の上位 32 ビットが ICV 計算に含まれなければならない。ICV 計算のためには、ペイロードの終端の直後、すべての暗黙的なパケットパディングの前に(暗黙的に)これらのビットが追加される。
For some integrity algorithms, the byte string over which the ICV computation is performed must be a multiple of a blocksize specified by the algorithm. If the IP packet length (including AH and the 32 high-order bits of the ESN, if enabled) does not match the blocksize requirements for the algorithm, implicit padding MUST be appended to the end of the packet, prior to ICV computation. The padding octets MUST have a value of zero. The blocksize (and hence the length of the padding) is specified by the algorithm specification. This padding is not transmitted with the packet. The document that defines an integrity algorithm MUST be consulted to determine if implicit padding is required as described above. If the document does not specify an answer to this, then the default is to assume that implicit padding is required (as needed to match the packet length to the algorithm's blocksize.) If padding bytes are needed but the algorithm does not specify the padding contents, then the padding octets MUST have a value of zero. 一部の完全性アルゴリズムでは、ICV 計算を実行されるバイト文字列がそのアルゴリズムの規定するブロックサイズの倍数でなければならない。IP パケット長(AH および有効であれば ESN の上位 32 ビットを含む)がアルゴリズムの要求するブロックサイズに一致しない場合、ICV 計算の前に、パケットの最後に暗黙のパディングを追加しなければならない(MUST)。パディングオクテットの値はゼロでなければならない(MUST)。ブロックサイズ(したがってパディングの長さ)はアルゴリズムの仕様によって規定される。このパディングはパケットとともに送信されない。前述の暗黙的なパディングが必要かどうかを判断するために、完全性アルゴリズムを定義する文書を調べなければならない(MUST)。その文書に答えが示されていなかった場合、デフォルトは(パケット長がそのアルゴリズムのブロックサイズに一致するのに必要なだけの)暗黙のパディングが必要であると仮定することである。パディングバイトは必要だが、アルゴリズムがパディングの内容を規定していない場合、パディングオクテットの値はゼロでなければならない(MUST)。
If required, IP fragmentation occurs after AH processing within an IPsec implementation. Thus, transport mode AH is applied only to whole IP datagrams (not to IP fragments). An IPv4 packet to which AH has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to AH processing at a receiver. (This does not apply to IPv6, where there is no router- initiated fragmentation.) In tunnel mode, AH is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway or a "bump-in-the-stack" or "bump-in- the-wire" IPsec implementation (see the Security Architecture document for details) may apply tunnel mode AH to such fragments. 必要であれば、IPsec 実装内部の AH 処理の後に IP フラグメンテーションが発生する。したがってトランスポートモード AH は、(IP フラグメントに対してではなく)IP データグラム全体に対してのみ適用される。AH を適用された IPv4 パケット自体が経路上でルータによってフラグメント化される可能性があり、そのようなフラグメントは受信側の AH 処理の前に再構築されなければならない。(IPv6 にはルータによるフラグメンテーションがないため、これは当てはまらない。) トンネルモードの場合、AH は IP パケットに適用されるが、そのペイロードがフラグメント化された IP パケットである可能性がある。例えば、セキュリティゲートウェイまたは "bump-in-the-stack" または "bump-in-the-wire" の 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 の終わりで述べている通り、bump-in-the-stack および bump-in-the-wire の実装は、ローカル IP レイヤによってフラグメント化されたパケットを最初に再構築し、次に IPsec を適用し、その結果のパケットをフラグメント化しなければならないだろう。
NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire
implementations, it will be necessary to examine all the extension
headers to determine if there is a fragmentation header, and either
the More flag or the Fragment Offset is non-zero. If so that packet
needs reassembling prior to IPsec processing.
注意：IPv6 の場合 -- bump-in-the-stack および bump-in-the-wire の実装では、フラグメンテーションヘッダがあるかどうか、また More フラグまたはフラグメントオフセットのどちらかがゼロ以外かどうかを判断するために、すべての拡張ヘッダを検査する必要があるだろう。もしそうなら、そのパケットを IPsec 処理の前に再構築する必要がある。
訳注：上記は Errata を反映しています。
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 実装はフラグメンテーションをサポートしないことを選択してもよく(MAY)、パス MTU (PMTU) 探索を促進するために、転送されるパケットに DF ビットをセットしてもよい。いかなる場合でも、AH 実装はフラグメンテーションの可能性を最小化するために、ICMP PMTU メッセージ(またはネイティブホスト実装の場合はそれと同等の内部的なシグナル)の生成をサポートしなければならない(MUST)。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 フラグメントと思われる場合(つまりオフセットフィールドがゼロではない、またはモアフラグメントフラグがセットされている場合)、受信側はそのパケットを無視しなければならない(MUST)。これは監査可能なイベントである。このイベントのための監査ログエントリは、SPI 値、日付/時刻、送信元アドレス、宛先アドレス、(IPv6 の場合)フロー ID を含むべきである。
NOTE: For packet reassembly, the current IPv4 spec does NOT require either the zeroing of the OFFSET field or the clearing of the MORE FRAGMENTS flag. In order for a reassembled packet to be processed by IPsec (as opposed to discarded as an apparent fragment), the IP code must do these two things after it reassembles a packet. 注意：パケットの再構築のために、現在の IPv4 仕様はオフセットフィールドをゼロ埋めしたり、モアフラグメントフラグをクリアしたりすることを必要としない。再構築されたパケットが IPsec によって(明白なフラグメントとして破棄されるのとは対照的に)処理されるように、IP コードはこれら二つの動作をパケットの再構築後に行わなければならない。
Upon receipt of a packet containing an IP Authentication Header, the receiver determines the appropriate (unidirectional) SA via lookup in the SAD. For a unicast SA, this determination is based on the SPI or the SPI plus protocol field, as described in Section 2.4. If an implementation supports multicast traffic, the destination address is also employed in the lookup (in addition to the SPI), and the sender address also may be employed, as described in Section 2.4. (This process is described in more detail in the Security Architecture document.) The SAD entry for the SA also indicates whether the Sequence Number field will be checked and whether 32- or 64-bit sequence numbers are employed for the SA. The SAD entry for the SA also specifies the algorithm(s) employed for ICV computation, and indicates the key required to validate the ICV. IP 認証ヘッダを含むパケットを受信後、受信側は SAD 検索によって適切な(単方向) SA を決定する。ユニキャスト SA の場合、セクション 2.4 で説明されている通り、この判断は SPI に基づいて、または SPI とプロトコルフィールドとに基づいて行われる。実装がマルチキャストトラフィックをサポートする場合、セクション 2.4 で説明されている通り、(SPI に加えて)宛先アドレスも検索に採用され、送信元アドレスも採用されてよい。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. パケットのための有効なセキュリティアソシエーションが存在しない場合、受信側はそのパケットを破棄しなければならない(MUST)。これは監査可能なイベントである。このイベントのための監査ログは、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 実装がこのサービスをサポートしなければならない(MUST)。アンチリプレイはユニキャストだけでなくマルチキャストにも適用可能である。しかしながら本標準は、複数送信者 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 の確立中に受信側が送信側にそれを通知するべきである(SHOULD)
If the receiver has enabled the anti-replay service for this SA, the receive packet counter for the SA MUST be initialized to zero when the SA is established. For each received packet, the receiver MUST verify that the packet contains a Sequence Number that does not duplicate the Sequence Number of any other packets received during the life of this SA. This SHOULD be the first AH check applied to a packet after it has been matched to an SA, to speed rejection of duplicate packets. 受信側が SA のためのアンチリプレイサービスを有効化した場合、その SA のための受信パケットカウンタを SA 確立時にゼロに初期化しなければならない(MUST)。各受信パケットごとに、受信側はそのパケットが、その SA の寿命中に受信したすべてのパケットのシーケンス番号と重複しないシーケンス番号を持つことを検証しなければならない(MUST)。これは重複パケットの拒否を促すための、パケットが 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. ウィンドウの "右(right)" 端は、その SA 上で受信した最大の有効なシーケンス番号を表す。ウィンドウの "左(left)" 端より小さいシーケンス番号を含むパケットは拒否される。ウィンドウ内に含まれるパケットは、そのウィンドウ内の受信済みパケットのリストに対してチェックされる。
If the ESN option is selected for an SA, only the low-order 32 bits of the sequence number are explicitly transmitted, but the receiver employs the full sequence number computed using the high-order 32 bits for the indicated SA (from his local counter) when checking the received Sequence Number against the receive window. In constructing the full sequence number, if the low-order 32 bits carried in the packet are lower in value than the low-order 32 bits of the receiver's sequence number counter, the receiver assumes that the high-order 32 bits have been incremented, moving to a new sequence number subspace. (This algorithm accommodates gaps in reception for a single SA as large as 2**32-1 packets. If a larger gap occurs, additional, heuristic checks for re-synchronization of the receiver's sequence number counter MAY be employed, as described in Appendix B.) SA のために ESN オプションが選択されている場合、その下位 32 ビットのみが明示的に転送されるが、受信側が受信したシーケンス番号を受信ウィンドウに対して確認するとき、その SA のための上位 32 ビットを(ローカルのカウンタから)使用して計算された完全なシーケンス番号を採用する。完全なシーケンス番号の構築において、パケット内で運ばれた下位 32 ビットが受信側のシーケンス番号カウンタの下位 32 ビットより小さい値の場合、受信側はその上位 32 ビットがインクリメントされたと仮定し、シーケンス番号の新しい部分空間に移動する。(このアルゴリズムは単一 SA のために 2**32-1 パケットの規模の受け取り間隔を収容できる。それより大きい間隔が発生した場合、受信側のシーケンス番号カウンタを再同期するための追加の発見的手法(付録 B で説明されている)を採用してもよい(MAY)。)
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 の妥当性確認に失敗した場合、受信側は受信したデータグラムを無効として破棄しなければならない(MUST)。これは監査可能なイベントである。このイベントのための監査ログは、SPI 値、日付/時刻、送信元アドレス、宛先アドレス、シーケンス番号、(IPv6 の場合)フロー ID を含むべきである(SHOULD)。受信ウィンドウは 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 パケットのサイズのウィンドウがサポートされなければならない(MUST)が、64 パケットのサイズが望ましく、デフォルトで採用されるべきである(SHOULD)。受信側によって別の(最低限よりは大きい)ウィンドウサイズが選択されてもよい(MAY)。(受信側は送信側にウィンドウサイズを通知しない。) 高速な環境の場合、保証問題とは無関係に受信ウィンドウサイズを増やすべきである。高速(例えば数ギガビット/秒)のデバイスのための最小限かつ推奨される受信ウィンドウサイズは、本仕様で規定されない。
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 と受信した ICV が一致する場合、そのデータグラムは有効であり、受け入れられる。確認に失敗した場合、受信側は受信した IP データグラムを無効として破棄しなければならない(MUST)。これは監査可能なイベントである。この監査ログイベントは、SPI 値、受信日付/時刻、送信元アドレス、宛先アドレス、(IPv6 の場合)フロー ID を含むべきである(SHOULD)。
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 "可変フィールドの扱い(Handling Mutable Fields)" を参照してほしい。)
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.) その SA のために ESN オプションが選択されている場合、その ESN の上位 32 ビットをパケットの最後に付加する。(前述の通り)パケットの全長を確認し、完全性アルゴリズムの要件に基づく暗黙のパディングが必要なら、必要に応じてパケットの最後(もしあれば ESN の後)にゼロ埋めされたバイトを付加する。ICV 計算を実行し、そのアルゴリズム仕様によって定義される比較規則を使用して、保存された値と計算結果とを比較する。(例えば ICV 計算にデジタル署名と単方向ハッシュとが使用される場合、この照合プロセスはより複雑になる。)
Not all systems that implement AH will implement auditing. However, if AH is incorporated into a system that supports auditing, then the AH implementation MUST also support auditing and MUST allow a system administrator to enable or disable auditing for AH. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this specification, and for each of these events a minimum set of information that SHOULD be included in an audit log is defined. Additional information also MAY be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also MAY result in audit log entries. There is no requirement for the receiver to transmit any message to the purported sender in response to the detection of an auditable event, because of the potential to induce denial of service via such action. AH を実装するすべてのシステムが監査を実装するわけではないことに注意してほしい。しかしながら監査をサポートするシステムに AH が組み込まれている場合、その AH 実装も監査をサポートしなければならず(MUST)、システム管理者が AH のための監査を有効化/無効化することを許可しなければならない(MUST)。監査の粒度は大部分がローカルの問題である。しかしながら、本仕様においていくつかの監査可能イベントが特定されており、それらのイベントのそれぞれに付いて、監査ログに含まれるべき(SHOULD)最低限の情報の集合が定義されている。これらのイベントのそれぞれのための監査ログに追加の情報が含まれてもよく(MAY)、本仕様で明示的に呼び出されると記述されていない追加イベントが監査ログエントリを生成してもよい(MAY)。監査可能イベントの検出に応えて、受信側が送信者と思われる相手に何らかのメッセージを送信するという要求事項はない。そのような動作はサービス不能攻撃を引き起こす潜在性があるためである。
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 の構文と、ユニキャストのためにここで説明されている処理とを完全に実装しなければならず(MUST)、セキュリティアーキテクチャ文書 [Ken-Arch] のすべての要求事項に従わなければならない(MUST)。加えて、実装がマルチキャストトラフィックのサポートを宣言する場合、そのようなトラフィックのサポートのために規定されている追加の要求事項にも従わなければならない(MUST)。ICV の計算に使用される鍵が手動で配布される場合、アンチリプレイサービスの正しい対策は、その鍵が置き換えられるまで送信側のカウンター状態が正しく維持されることを必要とするだろう。またカウンタのオーバーフローが差し迫った場合の自動的な復旧対策もないだろう。したがって適合実装は、このサービスを手動鍵の SA と同時に提供しないべきである(SHOULD NOT)。
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 に必須のアルゴリズムを超える追加のアルゴリズムがサポートされてもよい(MAY)。
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] と以下の点で異なる。
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. 著者は Ran Atkinson の貢献に感謝する。彼は初期の IPsec 活動において重要な役割を果たし、最初の IPsec 標準一式(RFC 1825 - 1827)を著した。Karen Seo は、本仕様および本仕様の前バージョンの編集における手助けに付いて、特別な感謝に値する。また、本プロトコル仕様の開発に貢献してくれた IPsec and MSEC ワーキンググループのメンバーにも感謝する。
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). この表は、"変更可能性(mutability)" に関して IPv4 のオプションがどう分類されるかを表している。参照が二つ示されているところでは、二番目の参照が最初の参照に優先する。この表は一部 RFC 1700("ASSIGNED NUMBERS", (October 1994))で提供される情報に基づいている。
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
Opt.
コピー クラス # 名前 参照
------ ------ --- ------------------------- --------
不変 -- ICV 計算に含まれる
0 0 0 End of Options List [RFC791]
0 0 1 No Operation [RFC791]
1 0 2 Security [RFC1108] (歴史的だか使用中)
1 0 5 Extended Security [RFC1108] (歴史的だか使用中)
1 0 6 Commercial Security
1 0 20 Router Alert [RFC2113]
1 0 21 Sender Directed Multi- [RFC1770]
Destination Delivery
可変 -- ゼロにされる
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]
実験的、廃止 -- ゼロにされる
1 0 8 Stream ID [RFC791, RFC1122 (ホスト要件)]
0 0 11 MTU Probe [RFC1063, RFC1191 (PMTU)]
0 0 12 MTU Reply [RFC1063, RFC1191 (PMTU)]
1 0 17 Extended Internet Protocol [RFC1385, DH98 (IPv6)]
0 0 10 Experimental Measurement
1 2 13 Experimental Flow Control
1 0 14 Experimental Access Ctl
0 0 15 ???
1 0 16 IMI Traffic Descriptor
1 0 19 Address Extension
NOTE: Use of the Router Alert option is potentially incompatible with use of IPsec. Although the option is immutable, its use implies that each router along a packet's path will "process" the packet and consequently might change the packet. This would happen on a hop- by-hop basis as the packet goes from router to router. Prior to being processed by the application to which the option contents are directed (e.g., Resource Reservation Protocol (RSVP)/Internet Group Management Protocol (IGMP)), the packet should encounter AH processing. However, AH processing would require that each router along the path is a member of a multicast-SA defined by the SPI. This might pose problems for packets that are not strictly source routed, and it requires multicast support techniques not currently available. 注意：Router Alert オプションの使用は IPsec の使用と潜在的に互換性がない。オプションが不変であっても、その使用はパケットの経路上の各ルータがそのパケットを "処理(process)" することを意味し、その結果としてパケットが変更される可能性がある。これはパケットがルータからルータへと進むにつれて、ホップバイホップの原則で起こるだろう。オプションの内容が向けられるアプリケーション(例えば Resource Reservation Protocol (RSVP)/Internet Group Management Protocol (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. 注意：パケットの経路上のシステムによるセキュリティラベル(例えば Basic Security Option (BSO), Extended Security Option (ESO), Commercial Internet Protocol Security Option (CIPSO))の追加または削除は、不変と分類される IP オプションと競合し、IPsec の使用と互換性を持たない。
NOTE: End of Options List options SHOULD be repeated as necessary to ensure that the IP header ends on a 4-byte boundary in order to ensure that there are no unspecified bytes that could be used for a covert channel. 注意：End of Options List オプションは、秘密のチャネルに使用される不明なバイトが存在しないことを保証するために IP ヘッダが確実に 4 バイト境界で終了するように、必要に応じて繰り返されるべきである(SHOULD)。
This table shows how the IPv6 extension headers are classified with regard to "mutability". この表は、"変更可能性(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]
NOT APPLICABLE
Fragmentation [DH98]
オプション/拡張名 参照
----------------------------------- ---------
可変だか予測可能 -- ICV 計算に含まれる
Routing (Type 0) [DH98]
オプションが可変(転送中に予測不能な変更が行われる)かどうかをビットが表す
Hop-by-Hop オプション [DH98]
Destination オプション [DH98]
適用できない
Fragmentation [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 を計算または検証するとき、内容が経路上で変更される可能性のあるすべてのオプションの "Option Data" フィールド全体を値ゼロとして扱わなければならない。Option Type および Opt Data Len は 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. Routing (Type 0) -- IPv6 のルーティングヘッダ "Type 0" は、送信元から宛先までの転送中にパケット内のアドレスフィールドを再配置するだろう。しかしながら、受信側に現れるであろうパケットの内容を送信側とすべての中間ホップとが知っている。したがって IPv6 のルーティングヘッダ "Type 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. Fragmentation -- フラグメンテーションは出力 IPsec 処理(セクション 3.3)の後に発生し、再構築は入力 IPsec 処理(セクション 3.4)の前に発生する。したがって、フラグメンテーション拡張ヘッダが存在する場合、IPsec からそれは見えない。
Note that on the receive side, the IP implementation could leave a Fragmentation Extension Header in place when it does re-assembly. If this happens, then when AH receives the packet, before doing ICV processing, AH MUST "remove" (or skip over) this header and change the previous header's "Next Header" field to be the "Next Header" field in the Fragmentation Extension Header. 受信側においてフラグメンテーション拡張ヘッダを再構築するとき、IP 実装はそれをそのままにしておけることに注意してほしい。もしそうする場合、パケットを受信した AH は、ICV 処理を実行する前にこのヘッダを "削除(remove)" (またはスキップ)し、前のヘッダの "Next Header" フィールドがフラグメンテーション拡張ヘッダ内の "Next Header" フィールドになるように変更しなければならない(MUST)。
Note that on the send side, the IP implementation could give the IPsec code a packet with a Fragmentation Extension Header with Offset of 0 (first fragment) and a More Fragments Flag of 0 (last fragment). If this happens, then before doing ICV processing, AH MUST first "remove" (or skip over) this header and change the previous header's "Next Header" field to be the "Next Header" field in the Fragmentation Extension Header. 送信側において IP 実装は、オフセット 0 (先頭のフラグメント)かつモアフラグメントフラグが 0 (最終フラグメント)のフラグメンテーション拡張ヘッダを持つパケットを IPsec コードに与えてよいことに注意してほしい。もしそうする場合、ICV 処理を実行する前に AH は最初にこのヘッダを "削除(remove)" (またはスキップ)し、前のヘッダの "Next Header" がフラグメンテーション拡張ヘッダ内の "Next Header" になるように変更しなければならない(MUST)。
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. この付録は拡張シーケンス番号(ESN)の仕組みを説明する。拡張シーケンス番号は 64 ビットのシーケンス番号を採用する IPsc (ESP および AH)と共に使用されるが、各パケットの一部としてその下位 32 ビットのみが送信される。この付録には、リプレイパケットの検出に使用されるウィンドウの仕組みと、リプレイ拒否と ICV 計算とに使用されるシーケンス番号の上位ビットの判断とを網羅する。また、(送信されない)上位ビットに対して同期を喪失した場合の扱いに付いても議論する。
The receiver will maintain an anti-replay window of size W. This window will limit how far out of order a packet can be, relative to the packet with the highest sequence number that has been authenticated so far. (No requirement is established for minimum or recommended sizes for this window, beyond the 32- and 64-packet values already established for 32-bit sequence number windows. However, it is suggested that an implementer scale these values consistent with the interface speed supported by an implementation that makes use of the ESN option. Also, the algorithm described below assumes that the window is no greater than 2^31 packets in width.) All 2^32 sequence numbers associated with any fixed value for the high-order 32 bits (Seqh) will hereafter be called a sequence number subspace. The following table lists pertinent variables and their definitions. 受信側はサイズ W のアンチリプレイウィンドウを保持する。このウィンドウはすでに認証済みの最大のシーケンス番号を持つパケットに対して、パケットがどれほど外れられるかを制限する。(32 ビットのシーケンス番号ウィンドウ向けにすでに確立されている 32 および 64 パケットを超えるような、このウィンドウの最小または推奨されるサイズの要求事項はない。しかしながら実装者には、ESN オプションを利用する実装がサポートするインターフェイススピードに相応しい値を見積もることが推奨される。また、以下で説明されるアルゴリズムは、このウィンドウが 2^31 パケットを超える幅を持たないことを前提としている。) これ以降、上位 32 ビット(Seqh)のための任意の固定値に対応する 2^32 個のすべてのシーケンス番号を、シーケンス番号部分空間と呼ぶ。以下の表は関連する変数とその定義である。
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
変数 サイズ
名 (ビット) 意味
---- ------ ---------------------------
W 32 ウィンドウサイズ
T 64 これまでに認証済みの最大のシーケンス番号
ウィンドウの上限
Tl 32 T の下位 32 ビット
Th 32 T の上位 32 ビット
B 64 ウィンドウの下限
Bl 32 B の下位 32 ビット
Bh 32 B の上位 32 ビット
Seq 64 受信したパケットのシーケンス番号
Seql 32 Seq の下位 32 ビット
Seqh 32 Seq の上位 32 ビット
When performing the anti-replay check, or when determining which high-order bits to use to authenticate an incoming packet, there are two cases: アンチリプレイのチェックを実行するとき、または入力パケットを認証するためにどの上位ビットを使用するかを判断するとき、二つのケースがある：
+ Case A: Tl >= (W - 1). In this case, the window is within one
sequence number subspace. (See Figure 1)
+ Case B: Tl < (W - 1). In this case, the window spans two
sequence number subspaces. (See Figure 2)
+ ケース A: Tl >= (W - 1). この場合、ウィンドウはひとつのシーケンス
番号部分空間内に収まる (図 1 参照)
+ ケース B: Tl < (W - 1). この場合、ウィンドウは二つのシーケンス
番号部分空間にまたがる (図 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). 以下の図において、最下行("----")は連続するシーケンス番号部分空間を表し、0 が各部分空間の先頭を表す。その上にある二つの短い線は適用される上位ビットを表す。"====" はウィンドウを表す。"****" は未来のシーケンス番号(つまり、現時点で認証済みの最大シーケンス番号を超えるシーケンス番号(ThTl))を表す。
Th+1 *********
Th =======*****
--0--------+-----+-----0--------+-----------0--
Bl Tl Bl
(Bl+2^32) mod 2^32
Figure 1 -- Case A
Th+1 *********
Th =======*****
--0--------+-----+-----0--------+-----------0--
Bl Tl Bl
(Bl+2^32) mod 2^32
図 1 -- ケース A
Th ====**************
Th-1 ===
--0-----------------+--0--+--------------+--0--
Bl Tl Bl
(Bl+2^32) mod 2^32
Figure 2 -- Case B
Th ====**************
Th-1 ===
--0-----------------+--0--+--------------+--0--
Bl Tl Bl
(Bl+2^32) mod 2^32
図 2 -- ケース B
The anti-replay window can be thought of as a string of bits where `W' defines the length of the string. W = T - B + 1 and cannot exceed 2^32 - 1 in value. The bottom-most bit corresponds to B and the top-most bit corresponds to T, and each sequence number from Bl through Tl is represented by a corresponding bit. The value of the bit indicates whether or not a packet with that sequence number has been received and authenticated, so that replays can be detected and rejected. アンチリプレイウィンドウは、`W' がその長さを定義するビット列と考えることができる。W = T - B + 1 であり、値は 2^32 - 1 を超えられない。最下位ビットは B に対応し、最上位ビットは T に対応し、Bl から Tl までの各シーケンス番号が対応するビットで表される。ビットの値はそのシーケンス番号のパケットが受信済みかつ認証済みかどうかを表し、これによってリプレイを検出し、拒否することができる。
When a packet with a 64-bit sequence number (Seq) greater than T is received and validated, T より大きい 64 ビットシーケンス番号(Seq)を持つパケットを受信し、その妥当性を確認したとき、
+ B is increased by (Seq - T)
+ (Seq - T) bits are dropped from the low end of the window
+ (Seq - T) bits are added to the high end of the window
+ The top bit is set to indicate that a packet with that sequence
number has been received and authenticated
+ The new bits between T and the top bit are set to indicate that
no packets with those sequence numbers have been received yet.
+ T is set to the new sequence number
+ B が (Seq - T) だけ増やされる
+ ウィンドウの下端から (Seq - T) ビットが捨てられる
+ ウィンドウの上端に (Seq - T) ビットが足される
+ そのシーケンス番号を持つパケットが受信・認証されたことを表すために、
最上位ビットがセットされる
+ T と最上位ビットとの間の新しいビットが、それらのシーケンス番号を持つ
パケットがまだ受信されていないことを表すためにセットされる。
+ T に新しいシーケンス番号がセットされる
In checking for replayed packets, リプレイパケットの確認において、
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' のみであるため、受信側は各パケットが含まれるシーケンス番号部分空間を推測および追跡しなければならない。以下の式は、"通常の(normal)" 状況下で 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
+ 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
+ ケース A(図 1) の場合：
Seql >= Bl (ここで Bl = Tl - W + 1) なら、Seqh = Th
Seql < Bl (ここで Bl = Tl - W + 1) なら、Seqh = Th + 1
+ ケース B(図 2) の場合：
Seql >= Bl (ここで Bl = Tl - W + 1) なら、Seqh = Th - 1
Seql < Bl (ここで Bl = Tl - W + 1) なら、Seqh = Th
The following pseudo-code illustrates the above algorithms for anti- replay and integrity checks. The values for `Seql', `Tl', `Th', and `W' are 32-bit unsigned integers. Arithmetic is mod 2^32. 以下の擬似コードは、アンチリプレイと完全性チェックとのための前述のアルゴリズムを説明している。`Seql'、`Tl'、`Th'、`W' の値は 32 ビット符号なし整数である。計算能力は mod 2^32 である。
If (Tl >= W - 1) Case A
If (Seql >= Tl - W + 1)
Seqh = Th
If (Seql <= Tl)
If (pass replay check)
If (pass integrity check)
Set bit corresponding to Seql
Pass the packet on
Else reject packet
Else reject packet
Else
If (pass integrity check)
Tl = Seql (shift bits)
Set bit corresponding to Seql
Pass the packet on
Else reject packet
Else
Seqh = Th + 1
If (pass integrity check)
Tl = Seql (shift bits)
Th = Th + 1
Set bit corresponding to Seql
Pass the packet on
Else reject packet
Else Case B
If (Seql >= Tl - W + 1)
Seqh = Th - 1
If (pass replay check)
If (pass integrity check)
Set the bit corresponding to Seql
Pass packet on
Else reject packet
Else reject packet
Else
Seqh = Th
If (Seql <= Tl)
If (pass replay check)
If (pass integrity check)
Set the bit corresponding to Seql
Pass packet on
Else reject packet
Else reject packet
Else
If (pass integrity check)
Tl = Seql (shift bits)
Set the bit corresponding to Seql
Pass packet on
Else reject packet
If (Tl >= W - 1) ケース A
If (Seql >= Tl - W + 1)
Seqh = Th
If (Seql <= Tl)
If (リプレイチェックに合格)
If (完全性チェックに合格)
Seql に対応するビットをセットする
パケットを通す
Else パケットを拒否する
Else パケットを拒否する
Else
If (完全性チェックに合格)
Tl = Seql (ビットシフトする)
Seql に対応するビットをセットする
パケットを通す
Else パケットを拒否する
Else
Seqh = Th + 1
If (完全性チェックに合格)
Tl = Seql (ビットをシフトする)
Th = Th + 1
Seql に対応するビットをセットする
パケットを通す
Else パケットを通す
Else ケース B
If (Seql >= Tl - W + 1)
Seqh = Th - 1
If (リプレイチェックに合格)
If (完全性チェックに合格)
Seql に対応するビットをセットする
パケットを通す
Else パケットを拒否する
Else パケットを拒否する
Else
Seqh = Th
If (Seql <= Tl)
If (リプレイチェックに合格)
If (完全性チェックに合格)
Seql に対応するビットをセットする
パケットを通す
Else パケットを拒否する
Else パケットを拒否する
Else
If (完全性チェックに合格)
Tl = Seql (ビットをシフトする)
Seql に対応するビットをセットする
パケットを通す
Else パケットを拒否する
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)実装は、以下の手続きを実装するべきである(SHOULD)。
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. SA 上のトラフィックの大部分が TCP の場合、2^32 個のパケットを失う前に送信元が送信を停止すると考えられるため、このような大規模なトラフィック損失は起こりそうにないことに注意してほしい。また任意の双方向アプリケーションの場合、たとえそれが UDP 上で運用されていたとしても、このような大規模な障害は何らかのタイムアウトを生じると考えられる。しかしながら UDP 上で運用されている単方向アプリケーションは、このような規模の損失を自動的に検出するフィードバックを持たない可能性があり、復旧方法を作成する動機はそのような場合のためである。
The solution we've chosen was selected to: 私たちの解決策は、以下の目的のために選択された：
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 のために個別のトリガー値をサポートするという要件はないが、実装者がそうすることを選択してもよい。
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)に連続するより大きい値を使用して認証を再試行する "不正な(bad)" パケットを選択する。これらの値は各リトライごとに 1 だけ加算されることで生成される。再試行の回数は、それが "過去の(past)" パケットまたは偽装パケットであったときのために、制限されるべきである。この制限回数はローカルのパラメータである。(Seqh の値が AH(または ESP)の後に暗黙的に置かれるため、パケットのペイロードの終端までに渡って完全性アルゴリズムを実行し、その後 Seqh を変化させて別の ICV の候補を計算することで、この手続きを最適化できるだろう。) この手続きによるパケット認証の成功は、連続障害カウントをリセットし、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. この解決策は受信側でのサポートのみを必要とし、それによって下位互換性が保たれる。また、再同期の作業はバックグラウンドか追加プロセッサを利用して行われるであろうから、この解決策はトラフィック処理に影響を与えず、サービス不能攻撃がトラフィック処理からリソースを奪うことはできない。
Stephen Kent BBN Technologies 10 Moulton Street Cambridge, MA 02138 USA Phone: +1 (617) 873-3988 EMail: kent@bbn.com
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
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.
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.
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.
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.
Funding for the RFC Editor function is currently provided by the Internet Society. RFC 編集者の活動資金は、現在 Internet Society によって提供されている。