RFC4302 日本語訳
4302 IP Authentication Header. S. Kent. December 2005. (Format: TXT=82328 bytes) (Obsoletes RFC2402) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Kent Request for Comments: 4302 BBN Technologies Obsoletes: 2402 December 2005 Category: Standards Track
コメントを求めるワーキンググループS.ケント要求をネットワークでつないでください: 4302のBBN技術が以下を時代遅れにします。 2402 2005年12月のカテゴリ: 標準化過程
IP Authentication Header
IP認証ヘッダー
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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).
このドキュメントはIP Authentication Header(AH)のアップデートされたバージョンについて説明します。(Authentication Headerは、IPv4とIPv6に認証サービスを供給するように設計されています)。 このドキュメントはRFC2402(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
1. 序論…3 2. 認証ヘッダー形式…4 2.1. 次のヘッダー…5 2.2. 有効搭載量の長さ…5 2.3. 予約されます…6 2.4. セキュリティパラメタは(SPI)に索引をつけます…6 2.5. 一連番号…8 2.5.1. (64ビット)の一連番号を広げています…8 2.6. 保全チェック価値(ICV)…9 3. 認証ヘッダー処理…9 3.1. 認証ヘッダー位置…9 3.1.1. モードを輸送してください…9 3.1.2. モードにトンネルを堀ってください…11 3.2. 保全アルゴリズム…11 3.3. 外国行きのパケット処理…11 3.3.1. セキュリティ協会ルックアップ…12 3.3.2. 一連番号世代…12 3.3.3. 保全チェック値の計算…13 3.3.3.1. 無常の分野を扱います…13 3.3.3.2. 詰め物と拡張配列番号…16
Kent Standards Track [Page 1] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[1ページ]。
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
3.3.4. 断片化…17 3.4. 本国行きのパケット処理…18 3.4.1. Reassembly…18 3.4.2. セキュリティ協会ルックアップ…18 3.4.3. 一連番号検証…19 3.4.4. 保全チェック値の検証…20 4. 監査します。21 5. 順応要件…21 6. セキュリティ問題…22 7. RFC2402からの違い…22 8. 承認…22 9. 参照…22 9.1. 標準の参照…22 9.2. 有益な参照…23 付録A: IPオプション/拡張ヘッダーの無常…25 A1。 IPv4オプション…25 A2。 IPv6拡張ヘッダー…26 付録B: (64ビット)の一連番号を広げています…28 B1。 概要…28 B2。 反再生ウィンドウ…28 B2.1。 反再生ウィンドウを管理して、使用します…29 B2.2。 一連番号の高次なビット(Seqh)を測定します…30 B2.3。 中間コードの例…31 B3。 Synchronizationの取り扱いLossはSignificant Packet Lossがそうします。32 B3.1。 再同期の引き金となります…33 B3.2。 再同期プロセス…33
Kent Standards Track [Page 2] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[2ページ]。
1. Introduction
1. 序論
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ドキュメントと呼ばれた「インターネットプロトコルのためのセキュリティー体系」[ケン-アーチ]で説明された用語と概念に詳しいと仮定します。 読者はEncapsulating Security有効搭載量(超能力)[ケン-超能力]とIP Authentication Header(AH)によって提供されたセキュリティー・サービスの定義、Security Associationsの概念、Authentication Header(AH)に関連して超能力を使用できる方法、および超能力と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].
キーワードが解釈しなければならない、本書では現れるとき、RFC2119[Bra97]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
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 Authentication Header(AH)は、IPデータグラム(今後まさしく「保全」と呼ばれる)のためのコネクションレスな保全とデータ発生源認証を提供して、再生に対する保護を提供するのに使用されます。 Security Association(SA)が設立されるとき、この後者の、そして、任意のサービスは受信機によって選択されるかもしれません。 (プロトコルデフォルトは、送付者が反再生に使用される一連番号を増加するのを必要としますが、受信機が一連番号をチェックする場合にだけ、サービスは有効です。) しかしながら、共同利用できるファッションにおけるExtended Sequence Numberの特徴を利用するなら、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
AHはIP Encapsulating Security有効搭載量(超能力)[ケン-超能力]と組み合わせた入れ子にされたファッションで単独で適用されるかもしれません(Security Architectureが[ケン-アーチ]を記録するのを見てください)。 1組の交信しているホストの間、または、1組の交信しているセキュリティゲートウェイの間、または、セキュリティゲートウェイとホストの間にセキュリティー・サービスを提供できます。 超能力は同じ反再生の、そして、同様の保全サービスを提供するのに使用されるかもしれません、そして、また、それは秘密性(暗号化)サービスを提供します。 超能力によって提供された保全とAHのプライマリ違いは適用範囲の範囲です。 明確に、それらの分野が保護しない場合、超能力は少しのIPヘッダーフィールドも保護しません。
Kent Standards Track [Page 3] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[3ページ]。
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と超能力を使用するかに関するその他の詳細に関しては、Security Architectureドキュメント[ケン-アーチ]を見てください。
Section 7 provides a brief review of the differences between this document and RFC 2402 [RFC2402].
セクション7はこのドキュメントとRFC2402[RFC2402]の違いの寸評を提供します。
2. Authentication Header Format
2. 認証ヘッダー形式
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ヘッダーSHALLに先行するプロトコルヘッダー(IPv4、IPv6、またはIPv6 Extension)がプロトコル(IPv4)かNext Header(IPv6、Extension)分野[DH98]に値51を保管しています。 図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) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 次のヘッダー| Payloadレン| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セキュリティパラメタインデックス(SPI)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一連番号分野| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 保全チェック値-ICV(可変)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. AH Format
図1。 ああ、形式
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のイラスト入り)、および他の分野を含んでいるAHを包括する野原を呼んで、どの分野がICVでカバーされているか、そして、何が伝えられるかを例証します。 RequのどんなWhat#、がそうするだろうか、Integはバイト[1]カバー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
Kent Standards Track [Page 4] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[4ページ]。
[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]--Mは義務的な[2]と等しいです--セクション3.3.3、「保全チェック値の計算」を見てください、IPヘッダーフィールドがカバーされている詳細のために。 [3]--トンネルモード->IPデータグラムIf交通機関->次ヘッダーとデータであるならICV計算(結果として起こるICVは後計算をここに置いた)の前に[4]のゼロを合わせます。
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形式でいつも存在していて、Integrity Check Value(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で使用される暗号アルゴリズムのすべてが、正準なネットワークバイトオーダー(RFC791[RFC791]のAppendixを見る)における彼らの入力を予想して、正準なネットワークバイトオーダーにおける彼らの出力を生成します。 また、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、例えば、IKE[IKEv2]のコンパチブルバージョンかバンドで出ている構成メカニズムを確実にするのに2人のIPsec同輩の間のシグナル伝達機構を使用することによって、それらを扱わなければなりません。
2.1. Next Header
2.1. 次のヘッダー
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.
Next HeaderはAuthentication Headerの後に次のペイロードのタイプを特定する8ビットの分野です。 この分野の値はインターネットAssigned民数記Authority(IANA)のウェブページで定義されたIPプロトコル民数記のセットから選ばれています。 例えば、4の値はIPv4を示します、そして、41の値はIPv6を示します、そして、6の値はTCPを示します。
2.2. Payload Length
2.2. ペイロード長
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ビットの分野は「2インチ」を引いて32ビットの単語(4バイトのユニット)による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詰め物。」
Kent Standards Track [Page 5] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[5ページ]。
2.3. Reserved
2.3. 予約されます。
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ビットの分野は今後の使用のために予約されます。 送付者、およびそれでSHOULDを「ゼロに合わせる」ようにそれを設定しなければなりません。受取人によって無視されます。 (値がICV計算に含まれていますが、別の方法で受取人によって無視されることに注意してください。)
2.4. Security Parameters Index (SPI)
2.4. セキュリティパラメタインデックス(SPI)
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を指定するのにSA、SPIをそれ自体で使用できますか、またはそれはIPsecプロトコルタイプ(この場合AH)に関連して使用されるかもしれません。 SPI値が受信機によってユニキャストSAsにおいて生成されるので、値自体がSAを特定できるかどうかくらいIPsecプロトコル価値に関連してそれを使用しなければならないかどうかが、地域にかかわる事柄です。 SPI分野は義務的です、そして、すべてのAH実装で上で説明されたユニキャストSAsにインバウンドトラフィックを写像するためのこのメカニズムをサポートしなければなりません。
If an IPsec implementation supports multicast, then it MUST support multicast SAs using the algorithm below for mapping inbound IPsec datagrams to SAs. Implementations that support only unicast traffic need not implement this de-multiplexing algorithm.
IPsec実装がマルチキャストをサポートするなら、本国行きのIPsecデータグラムをSAsに写像するのに以下のアルゴリズムを使用して、それは、マルチキャストがSAsであるとサポートしなければなりません。 ユニキャストトラフィックだけをサポートする実装はこの逆多重化アルゴリズムを実装する必要はありません。
In many secure multicast architectures, e.g., [RFC3740], a central Group Controller/Key Server unilaterally assigns the group security association's SPI. This SPI assignment is not negotiated or coordinated with the key management (e.g., IKE) subsystems that reside in the individual end systems that comprise the group. Consequently, it is possible that a group security association and a unicast security association can simultaneously use the same SPI. A multicast-capable IPsec implementation MUST correctly de-multiplex inbound traffic even in the context of SPI collisions.
多くの安全なマルチキャストアーキテクチャ、例えば、[RFC3740]では、中央のGroup Controller/主要なServerは一方的にグループセキュリティ協会のSPIを割り当てます。 このSPI課題は、グループを包括する個々のエンドシステムにあるかぎ管理(例えば、IKE)サブシステムで、交渉もされませんし、調整もされません。 その結果、グループセキュリティ協会とユニキャストセキュリティ協会が同時に同じSPIを使用できるのは、可能です。 マルチキャストできるIPsec実装は反-正しくSPI衝突の文脈さえにおけるインバウンドトラフィックを多重送信しなければなりません。
Each entry in the Security Association Database (SAD) [Ken-Arch] must indicate whether the SA lookup makes use of the destination, or destination and source, IP addresses, in addition to the SPI. For multicast SAs, the protocol field is not employed for SA lookups. For each inbound, IPsec-protected packet, an implementation must conduct its search of the SAD such that it finds the entry that matches the "longest" SA identifier. In this context, if two or more SAD entries match based on the SPI value, then the entry that also matches based on destination, or destination and source, address comparison (as indicated in the SAD entry) is the "longest" match. This implies a logical ordering of the SAD search as follows:
Security Association Database(SAD)[ケン-アーチ]の各エントリーは、SAルックアップが目的地か、目的地とソースを利用するかどうかを示さなければなりません、IPアドレス、SPIに加えて。 マルチキャストSAsにおいて、プロトコル分野はSAルックアップに使われません。 それぞれの本国行きの、そして、IPsecによって保護されたパケットに関しては、実装がSADの検索を行わなければならないので、それは「最も長い」SA識別子に合っているエントリーを見つけます。 このような関係においては、2つ以上のSADエントリーがSPI値、次にまた、目的地か、目的地とソースに基づいて合っているエントリーに基づいて合っているなら、アドレス比較(SADエントリーにみられるように)は「最も長い」マッチです。 これは以下のSAD検索の論理的な注文を含意します:
Kent Standards Track [Page 6] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[6ページ]。
1. Search the SAD for a match on {SPI, destination
address, source address}. If an SAD entry
matches, then process the inbound AH packet with that
matching SAD entry. Otherwise, proceed to step 2.
1. マッチのためにSPI、送付先アドレス、ソースアドレスをSADを捜してください。 SADエントリーが合っているなら、そんなに合っているSADエントリーで本国行きのAHパケットを処理してください。 さもなければ、ステップ2に進んでください。
2. Search the SAD for a match on {SPI, destination
address}. If an SAD entry matches, then process
the inbound AH packet with that matching SAD
entry. Otherwise, proceed to step 3.
2. マッチのためにSPI、送付先アドレスを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.
3. 受信機が、別の方法でAHと超能力か、SPI、プロトコルの上のただ一つのSPIスペースを維持するのを選んだなら、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エントリーが分類されるので、それらは繋がっているリストで最後のエントリーです。 ハードウェアベースの実装は本質的に最も長いマッチ検索に作用できるかもしれません、一般的に利用可能なTernary Contentアドレス可能なMemory(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構成か交渉使用を通したSA管理プロトコル、例えば、IKEの副作用かInterpretationのGroup Domainとしてのセットが(GDOI)であったに違いない[RFC3547]なら本国行きのIPsecトラフィックをSAsに写像するのに必要です。 通常、Source特有のMulticast(SSM)[HC03]グループはSPIで構成された3-tuple SA識別子、送付先マルチキャストアドレス、およびソースアドレスを使用します。 Any-ソース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"
範囲1〜255のSPI値のセットは今後の使用のためにインターネットAssigned民数記Authority(IANA)によって予約されます。 割り当てられたSPI価値の使用がRFCで指定されないと、通常、予約されたSPI値はIANAによって割り当てられないでしょう。 (0)がないSPI値を地方の実装特定的用法のために予約して、ワイヤに送ってはいけません。 (例えば、かぎ管理実装はSPIが「セキュリティ協会は全く存在しません」と意味するために評価するゼロを使用するかもしれません。
Kent Standards Track [Page 7] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[7ページ]。
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.)
IPsec実装が、かぎ管理実体が新しいSAを設立するよう要求しましたが、SAがまだ設立されていない期間。)
2.5. Sequence Number
2.5. 一連番号
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つによる増加が送った対価を含んでいます、すなわち、1SAあたり1つのパケット一連番号。 ユニキャストのために、SAか独身の送付者マルチキャストSA、送付者があらゆる伝えられたパケットのためのこの分野を増加しなければなりません。 一般に推薦されませんが、複数の送付者の中でSAを共有するのは受入れられます。 AHは複数の送付者の中でパケットカウンタを連動させるか、または意味深長に受信機パケットカウンタと窓を管理する手段を全く複数の送付者の文脈に提供しません。 セクション3.3.2と3.4を見てください。その結果、マルチ送付者SAに、AHの反回答機能が利用可能でない、(.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のために反再生サービスを可能にするのを選ばないでも、分野は、義務的であり、いつも存在していなければなりません。 受信機の裁量にはSequence Number分野の処理がありますが、すべてのAH実装がセクション3.3.2、「一連番号世代」、およびセクション3.4.3で説明された処理、「一連番号検証」を実行できなければなりません。 したがって、送付者はいつもこの野原を伝えなければなりませんが、受信機はそれに作用する必要はありません。
The sender's counter and the receiver's counter are initialized to 0 when an SA is established. (The first packet sent using a given SA will have a sequence number of 1; see Section 3.3.2 for more details on how the sequence number is generated.) If anti-replay is enabled (the default), the transmitted sequence number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA.
SAが設立されるとき、送付者のカウンタと受信機のカウンタは0に初期化されます。 (与えられたSAが使用させられた最初のパケットは1の一連番号を持つでしょう; 一連番号がどう発生しているかに関するその他の詳細に関してセクション3.3.2を見てください。) 反再生が可能にされるなら(デフォルト)、伝えられた一連番号を決して循環させてはいけません。 したがって、SAにおける2^第32パケットのトランスミッションの前に送付者のカウンタと受信機のカウンタをリセットしなければなりません(新しいSAとその結果新しいキーを設立することによって)。
2.5.1. Extended (64-bit) Sequence Number
2.5.1. (64ビット)の拡張一連番号
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.)
一連番号SHOULDのために高速IPsec実装、新しいオプションをサポートするために、提供してください、現在の、そして、32ビットの一連番号分野への拡大として。 SA管理プロトコルでExtended Sequence Number(ESN)の使用を交渉しなければなりません。 IKEv2では、この交渉が暗に示されていることに注意してください。 32ビットの一連番号が明らかに交渉されない場合、デフォルトはESNです。 (ESNの特徴はユニキャストSAsと同様にマルチキャストに適切です。)
The ESN facility allows use of a 64-bit sequence number for an SA. (See Appendix B, "Extended (64-bit) Sequence Numbers", for details.) Only the low-order 32 bits of the sequence number are transmitted in
ESN施設は64ビットの一連番号のSAの使用を許します。 (Appendix B、「(64ビット)の拡張一連番号」を詳細に関して見てください。) 一連番号の32ビットが伝えられる下位だけ
Kent Standards Track [Page 8] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[8ページ]。
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.
その結果パケットオーバーヘッドを最小にするそれぞれのパケットのAHヘッダー。 高位32ビットは、一連番号カウンタの一部として送信機と受信機の両方によって維持されて、ICVの計算に含まれていますが、伝えられません。
2.6. Integrity Check Value (ICV)
2.6. 保全チェック価値(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 Check Value(ICV)を含む可変長の分野です。 分野は長さが32ビット(IPv4かIPv6)の不可欠の倍数であるに違いありません。 ICV処理の詳細は.4、「保全チェック値の検証」というセクション3.3.3、「保全チェック値の計算」、およびセクション3.4で説明されます。 この分野は、必要なら、AHヘッダーの長さが32ビット(IPv4)か64ビット(IPv6)の不可欠の倍数であることを保証するために明白な詰め物を含むかもしれません。 IPv4/IPv6整列要求を満たすためにそっと歩いて、すべての実装が、そのような詰め物をサポートしなければならなくて、十分だけを挿入しなければなりません。 長さを水増ししながらどう必要を計算するかに関する詳細はセクション3.3で以下に明らかにされます。.3 .2 「水増し」。 保全アルゴリズム仕様は合法化のためのICVの長さ、比較規則、および処理ステップを指定しなければなりません。
3. Authentication Header Processing
3. 認証ヘッダー処理
3.1. Authentication Header Location
3.1. 認証ヘッダー位置
AH may be employed in two ways: transport mode or tunnel mode. (See the Security Architecture document for a description of when each should be used.)
AHは2つの方法で使われるかもしれません: モードかトンネルモードを輸送してください。 (それぞれが使用されるべきである時に関する記述のためのSecurity Architectureドキュメントを見てください。)
3.1.1. Transport Mode
3.1.1. 交通機関
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に制限するのが用語「輸送」モードに誤解されるべきでないことに注意してください。) 以下のダイヤグラムは基礎「前後」のときにaで典型的なIPv4パケットのためのAH交通機関位置決めを例証します。
Kent Standards Track [Page 9] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[9ページ]。
BEFORE APPLYING AH
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
適用する前、ああ。---------------------------- IPv4|orig IP hdr| | | |(どんなオプションも)| TCP| データ| ----------------------------
AFTER APPLYING AH
-------------------------------------------------------
IPv4 |original IP hdr (any options) | AH | TCP | Data |
-------------------------------------------------------
|<- mutable field processing ->|<- immutable fields ->|
|<----- authenticated except for mutable fields ----->|
適用した後、ああ。------------------------------------------------------- IPv4|オリジナルのIP hdr(どんなオプションも)| ああ| 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 |
---------------------------------------
適用する前、ああ。--------------------------------------- IPv6| | ext hdrs| | | | orig IP hdr|現在| TCP| データ| ---------------------------------------
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 ----------->|
適用した後、ああ。------------------------------------------------------------ IPv6| |ホップごとのdest*| | dest| | | |orig IP hdr|掘って、断片化してください。 | ああ| *を選んでください。| TCP| データ| ------------------------------------------------------------ | <、-、-- 無常のフィールド処理-->| <-- 不変の分野-->| | <、-、-、-- 無常の分野を除いて、認証されます。----------->|
* = 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.
さまざまなモードで超能力とAHヘッダーを結合できます。 IPsec Architectureドキュメントはサポートしなければならないセキュリティ協会の組み合わせについて説明します。
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.
または、交通機関で「スタックでの隆起」ゆえそれに注意してください、「中で突き当たる、-、-配線してください、」 実装、Security Architectureドキュメントで定義されるように、本国行きの、そして、外国行きのIP断片はこの仕様に従って、透明なIPsecにサポートを供給するために付加的なIP再アセンブリ/断片化を実行するためにIPsec実装を必要とするかもしれません。 特別な注意が、複数のインタフェースが使用中であるときに、これらの実装の中でそのような操作を実行するのに必要です。
Kent Standards Track [Page 10] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[10ページ]。
3.1.2. Tunnel Mode
3.1.2. トンネル・モード
In tunnel mode, the "inner" IP header carries the ultimate (IP) source and destination addresses, while an "outer" IP header contains the addresses of the IPsec "peers," e.g., addresses of security gateways. Mixed inner and outer IP versions are allowed, i.e., IPv6 over IPv4 and IPv4 over IPv6. In tunnel mode, AH protects the entire inner IP packet, including the entire inner IP header. The position of AH in tunnel mode, relative to the outer IP header, is the same as for AH in transport mode. The following diagram illustrates AH tunnel mode positioning for typical IPv4 and IPv6 packets.
トンネルモードで、「内側」のIPヘッダーは究極の(IP)ソースと送付先アドレスを運びます、「外側」のIPヘッダーはIPsec「同輩」のアドレスを含んでいますが、例えば、セキュリティゲートウェイのアドレス。 すなわち、内側の、そして、外側のIPバージョンが許容されているMixed、IPv6の上のIPv4とIPv4の上のIPv6。 トンネルモードで、AHは全体の内側のIPヘッダーを含む全体の内側のIPパケットを保護します。 外側のIPヘッダーに比例して、トンネルモードによるAHの位置はAHのように交通機関で同じです。 以下のダイヤグラムは、典型的なIPv4とIPv6のためにパケットを置きながら、AHトンネルモードを例証します。
----------------------------------------------------------------
IPv4 | | | orig IP hdr* | | |
|new IP header * (any options) | AH | (any options) |TCP| Data |
----------------------------------------------------------------
|<- mutable field processing ->|<------ immutable fields ----->|
|<- authenticated except for mutable fields in the new IP hdr->|
---------------------------------------------------------------- IPv4| | | orig IP hdr*| | | |新しいIPヘッダー*(どんなオプションも)| ああ| (どんなオプションも) |TCP| データ| ---------------------------------------------------------------- | <、- 無常のフィールド処理、->| <、-、-、-、-、-- 不変の分野----->| | <、- 新しい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 ->|
-------------------------------------------------------------- IPv6| | ext hdrs*| | | ext hdrs*| | | |新しいIP hdr*|現在| ああ|orig IP hdr*|現在|TCP|データ| -------------------------------------------------------------- | <、-、-- 無常の分野-->| <、-、-、-、-、-、-、-、-- 不変の分野-------->|、| 処理| | <-- 新しいIP hdrの無常の分野を除いて、認証される、->|
* = if present, construction of outer IP hdr/extensions and
modification of inner IP hdr/extensions is discussed in
the Security Architecture document.
* = 存在しているなら、Security Architectureドキュメントで外側のIP hdr/拡大の工事と内側のIP hdr/拡大の変更について議論します。
3.2. Integrity Algorithms
3.2. 保全アルゴリズム
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など)に関する合わせられたメッセージ立証コード(MACs)を含んでいます。 マルチキャストコミュニケーションに関しては、保全を提供するためのさまざまな暗号の戦略を開発してあります、そして、研究はこの領域で続きます。
3.3. Outbound Packet Processing
3.3. 外国行きのパケット処理
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
交通機関で、送付者はIPヘッダーの後と次の層のプロトコルヘッダーの前にAHヘッダーを挿入します、上で説明されるように。 トンネルモードで、外側の、そして、内側のIPヘッダー/拡大はそうであることができます。
Kent Standards Track [Page 11] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[11ページ]。
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ヘッダー/拡大の工事はSecurity Architectureドキュメントで説明されます。
3.3.1. Security Association Lookup
3.3.1. セキュリティ協会ルックアップ
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.
IPsec実装が、パケットがAH処理を求めるSAに関連していることを決定した後にだけAHは外国行きのパケットに適用されます。 アウトバウンドトラフィックに適用されたIPsec処理がどんなであるも何であるかを決定するプロセスはSecurity Architectureドキュメントで説明されます。
3.3.2. Sequence Number Generation
3.3.2. 一連番号世代
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と差し込みのためにSequence Number分野への価値の下位の32ビットで一連番号(または、ESN)カウンタを増加します。 したがって、与えられた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.
反再生が可能にされるなら(デフォルト)、送付者は、新しい値を差し込む前にカウンタがSequence Number分野を循環させていないのを保証するためにチェックします。 言い換えれば、そうするのが一連番号を引き起こすなら、送付者はサイクルまでパケットをSAに送ってはいけません。 一連番号オーバーフローをもたらすパケットを伝える試みは監査可能イベントです。 このイベントSHOULDのための監査ログエントリーはSPI値、現在の日付/時間、Source Address、Destination Address、および(IPv6の)cleartext Flow IDを含んでいます。
The sender assumes anti-replay is enabled as a default, unless otherwise notified by the receiver (see Section 3.4.3) or if the SA was configured using manual key management. Thus, typical behavior of an AH implementation calls for the sender to establish a new SA when the Sequence Number (or ESN) cycles, or in anticipation of this value cycling.
送付者は、反再生がデフォルトとして可能にされると仮定します、受信機(セクション3.4.3を見る)によって別の方法で通知されなかったか、またはSAが手動のかぎ管理を使用することで構成されたなら。 したがって、AH実装の典型的な振舞いはSequence Number(または、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を見てください)。 しかしながら、送付者はまだカウンタを増加しています、そして、最大値に達すると、カウンタはゼロにひっくり返って戻ります。 (この振舞いはマルチ送付者のために推薦されます、マルチキャスト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(Appendix Bを見る)が選択されるなら、一連番号の下位の32ビットだけがSequence Number分野で伝えられます、送付者と受信機の両方が完全な64ビットのESNカウンタを維持しますが。 しかしながら、高位32ビットはICV計算に含まれています。
Kent Standards Track [Page 12] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[12ページ]。
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のために反再生を可能にしないのを選ぶなら、受信機SHOULD NOTはSA管理プロトコルでESNを交渉します。 ESNの使用は受信機が一般にSAのための反再生の無効にすることの概念とは逆にある反再生ウィンドウ(正しい値をICV計算で使われるESNの何高位のビットも決定するために)を管理する必要性を作成します。
3.3.3. Integrity Check Value Calculation
3.3.3. 保全チェック値の計算
The AH ICV is computed over:
AH ICVは以下の上で計算されます。
o IP or extension header fields before the AH header that are
either immutable in transit or that are predictable in value
upon arrival at the endpoint for the AH SA
o the AH header (Next Header, Payload Len, Reserved, SPI,
Sequence Number (low-order 32 bits), and the ICV (which is set
to zero for this computation), and explicit padding bytes (if
any))
o everything after AH is assumed to be immutable in transit
o the high-order bits of the ESN (if employed), and any implicit
padding required by the integrity algorithm
o AHの後のすべてがESNのトランジットoにおける高位不変のビットであると思われるAHヘッダー(次のHeader、Payloadレン、Reserved、SPI、Sequence Number(下位の32ビット)、ICV(この計算のためにゼロに設定される)、および明白な詰め物バイト(もしあれば))のAH SA o oにおいて、AHヘッダーの前のトランジットかそれで不変であることのIPか拡張ヘッダー分野は終点への到着の値で予測できます(使われるなら); そして、どんな暗黙の詰め物も保全アルゴリズムが必要です。
3.3.3.1. Handling Mutable Fields
3.3.3.1. 無常の分野を扱います。
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計算の目的のために分野に挿入されます。 また、Integrity Check Value分野はこの計算に備えたゼロへのセットです。 分野を省略するよりそれぞれむしろフィールドの値をゼロに取り替えることによって、整列が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で定義されるでしょう、そして、SHOULDはAH ICVについて計算するとき、それがどう扱われるべきであるか方向を含んでいます(Security Considerations部で)。 IP(v4かv6)実装がそれが見分けない拡張ヘッダーに遭遇すると、それは、パケットを捨てて、ICMPメッセージを送るでしょう。 IPsecはパケットを決して見ないでしょう。 IPsec実装がそれが認識しないIPv4オプションに遭遇するなら、全体のオプションのゼロを合わせるべきです、長さとしてオプションの2番目のバイトを使用して。 IPv6オプション(Destination Extension HeadersかホップによるHop Extension Headerの)は無常を示す旗を含んでいます。無常はそのようなオプションのための適切な処理を決定します。
Kent Standards Track [Page 13] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[13ページ]。
3.3.3.1.1. ICV Computation for IPv4
3.3.3.1.1. IPv4のためのICV計算
3.3.3.1.1.1. Base Header Fields
3.3.3.1.1.1. 基地のヘッダーフィールド
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)
不変のバージョンインターネットHeader Length Total Length Identificationプロトコル(これは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計算の前にゼロに合わせられている)の差別化されたServices Code Point(DSCP)(6ビット、RFC2474[NBBB98]を見る)の明白なCongestion Notification(電子証券取引ネットワーク)はLive(TTL)ヘッダーChecksumにFragment Offset Timeに旗を揚げさせます(2ビット、RFC3168[RFB01]を見てください)。
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.
電子証券取引ネットワーク--これは、ルートに沿ったルータが混雑になるかどうかを変えて、その結果、送付者はレセプションの値を予測できません。
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).
断片Offset--AHが非断片化しているIPパケットだけに適用されるので、いつもOffset Fieldはゼロであるに違いなく、その結果、それは除かれます(それが予測できますが)。
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--途中で、処理の常軌としてルータでこれを変えて、その結果、受信機の値は送付者が予測できません。
Kent Standards Track [Page 14] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[14ページ]。
Header Checksum - This will change if any of these other fields change, and thus its value upon reception cannot be predicted by the sender.
ヘッダーChecksum--これは、これらの他の分野のどれかが変化するかどうかを変えて、その結果、送付者はレセプションの値を予測できません。
3.3.3.1.1.2. Options
3.3.3.1.1.2. オプション
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オプションは、Appendix Aに明らかに記載されていて、不変、無常にもかかわらず、予測できる、または無常として分類されます。 IPv4に関しては、全体のオプションは一体にして見られます。 それで、オプションが無常として分類されるなら、ほとんどのオプションの中のタイプと長さの分野はトランジットで不変ですが、全体のオプションのゼロはICV計算目的のために合わせられています。
3.3.3.1.2. ICV Computation for IPv6
3.3.3.1.2. IPv6のためのICV計算
3.3.3.1.2.1. Base Header Fields
3.3.3.1.2.1. 基地のヘッダーフィールド
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(6ビット、RFC2474[NBBB98]を見る)電子証券取引ネットワーク(2ビット、RFC3168[RFB01]を見る)流れLabel(*)ホップ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.
流れラベルがAHv1で説明した(*)は、無常であり、RFC2460[DH98]で潜在的に無常でした。 既存のAH実装との互換性を保有するために、流れラベルはAHv2のICVに含まれていません。
3.3.3.1.2.2. Extension Headers Containing Options
3.3.3.1.2.2. オプションを含む拡張ヘッダー
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
ホップによるHopとDestination Extension HeadersのIPv6オプションはしばらくをオプションがトランジットの間、変化するかもしれないかどうかを(予想外に)示す含んでいます。 ICVについて計算するか、または確かめるとき、コンテンツが途中で変化するかもしれないどんなオプションにおいても、全体の「オプションデータ」分野を無評価された八重奏として扱わなければなりません。 The
Kent Standards Track [Page 15] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[15ページ]。
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.
オプションTypeとOpt DataレンはICV計算に含まれています。 ビットが不変性を示すすべてのオプションがICV計算に含まれています。 詳しい情報のためのIPv6仕様[DH98]を見てください。
3.3.3.1.2.3. Extension Headers Not Containing Options
3.3.3.1.2.3. オプションを含まない拡張ヘッダー
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拡張ヘッダーは、Appendix Aに明らかに記載されていて、不変、無常にもかかわらず、予測できる、または無常として分類されます。
3.3.3.2. Padding and Extended Sequence Numbers
3.3.3.2. 詰め物と拡張配列番号
3.3.3.2.1. ICV Padding
3.3.3.2.1. ICV詰め物
As mentioned in Section 2.6, the ICV field may include explicit padding if required to ensure that the AH header is a multiple of 32 bits (IPv4) or 64 bits (IPv6). If padding is required, its length is determined by two factors:
セクション2.6で言及されるように、ICV分野は必要なら、AHヘッダーが32ビット(IPv4)か64ビット(IPv6)の倍数であることを保証するために明白な詰め物を含むかもしれません。 詰め物が必要であるなら、長さは2つの要素で測定されます:
- the length of the ICV
- the IP protocol version (v4 or v6)
- ICVの長さ--IPプロトコルバージョン(v4かv6)
For example, if the output of the selected algorithm is 96 bits, no padding is required for IPv4 or IPv6. However, if a different length ICV is generated, due to use of a different algorithm, then padding may be required depending on the length and IP protocol version. The content of the padding field is arbitrarily selected by the sender. (The padding is arbitrary, but need not be random to achieve security.) These padding bytes are included in the ICV calculation, counted as part of the Payload Length, and transmitted at the end of the ICV field to enable the receiver to perform the ICV calculation. Inclusion of padding in excess of the minimum amount required to satisfy IPv4/IPv6 alignment requirements is prohibited.
例えば、選択されたアルゴリズムの出力が96ビットであるなら、水増しはIPv4かIPv6に必要ではありません。 しかしながら、ICVが異なったアルゴリズムの使用のため異なった長さに生成されるなら、長さとIPプロトコルバージョンによって、詰め物が必要であるかもしれません。 詰め物分野の内容は送付者によって任意に選択されます。 (詰め物は、任意ですが、安定を得るために無作為である必要はありません。) バイトを水増しするこれらは、受信機がICV計算を実行するのを可能にするためにICV計算に含まれていて、有効搭載量Lengthの一部にみなされて、ICV分野の端で伝えられます。 IPv4/IPv6整列要求を満たすために最小の必要額を超えてそっと歩く包含は禁止されています。
3.3.3.2.2. Implicit Packet Padding and ESN
3.3.3.2.2. 暗黙のパケット詰め物とESN
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のために選ばれるなら、ICV計算にESNの高位32ビットを含まなければなりません。 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計算が実行されるバイトストリングはアルゴリズムで指定されて、aの倍数にblocksizeされるということでなければなりません。 IPパケット長(AHと32を含んでいて、可能にされるなら、ESNのビットを高値で配置する)が合っていない、blocksizeする、アルゴリズムのための要件、パケットの端まで暗黙の詰め物を追加しなければなりません、ICV計算の前に。 詰め物八重奏
Kent Standards Track [Page 16] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[16ページ]。
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.
ゼロの値を持たなければなりません。 blocksizeする、(そして、したがって、詰め物の長さ) アルゴリズム仕様で、指定されます。 この詰め物はパケットで伝えられません。 上で説明されるように暗黙の詰め物が必要であるかどうか決定するために保全アルゴリズムを定義するドキュメントを参照しなければなりません。 ドキュメントがこの答えを指定しないなら、デフォルトは暗黙の詰め物が必要であると仮定する(合うのが必要であるので、アルゴリズムのものへのパケット長はblocksizeされます。)ことです。 詰め物バイトが必要ですが、アルゴリズムが詰め物コンテンツを指定しないなら、詰め物八重奏には、ゼロの値がなければなりません。
3.3.4. Fragmentation
3.3.4. 断片化
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断片化はAH処理の後にIPsec実装の中に起こります。 したがって、交通機関AHは全体のIPデータグラム(IPに断片化しない)だけに適用されます。 途中で、ルータによって断片化されてください。そうすれば、AH処理の前に受信機でそのような断片を組み立て直さなければなりません。(そこには、ルータの開始している断片化が全くありません)。AHが適用されたIPv4パケットがそうするかもしれない、それ自体. (これはIPv6に適用されません。) トンネルモードで、AHはIPパケットに適用されます。そのペイロードは断片化しているIPパケットであるかもしれません。 または、例えば、セキュリティゲートウェイか「スタックでの隆起」、「中で突き当たる、-、-配線してください、」 IPsec実装(詳細のためのSecurity Architectureドキュメントを見る)はトンネルモード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の終わりに言及されるようにモードを輸送してください、スタックで突き当たってください、ワイヤでの隆起実装が最初にローカルアイピー層によって断片化されたパケットを組み立て直し、次に、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.
以下に注意してください。 断片化ヘッダーとしたがって、それがいるかどうか決定するためにすべての拡張ヘッダーを調べるのに、パケットが、IPsec処理の前に組み立て直す必要であるのがIPv6、スタックでの隆起とワイヤでの隆起実装に、必要になるでしょう。
Fragmentation, whether performed by an IPsec implementation or by routers along the path between IPsec peers, significantly reduces performance. Moreover, the requirement for an AH receiver to accept fragments for reassembly creates denial of service vulnerabilities. Thus, an AH implementation MAY choose to not support fragmentation and may mark transmitted packets with the DF bit, to facilitate Path MTU (PMTU) discovery. In any case, an AH implementation MUST support generation of ICMP PMTU messages (or equivalent internal signaling for native host implementations) to minimize the likelihood of fragmentation. Details of the support required for MTU management are contained in the Security Architecture document.
IPsec実装かIPsec同輩の間の経路に沿ったルータによって実行されるか否かに関係なく、断片化は性能をかなり抑えます。 そのうえ、AH受信機が再アセンブリのために断片を受け入れるという要件はサービスの弱点の否定を作成します。 したがって、AH実装は、Path MTU(PMTU)発見を容易にするために断片化をサポートしないのを選んで、DFビットで伝えられたパケットをマークするかもしれません。 どのような場合でも、AH実装は断片化の見込みを最小にするICMP PMTUメッセージ(または、ネイティブのホスト導入のための同等な内部のシグナリング)の世代をサポートしなければなりません。 MTU管理に必要であるサポートの詳細はSecurity Architectureドキュメントに含まれています。
Kent Standards Track [Page 17] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[17ページ]。
3.4. Inbound Packet Processing
3.4. 本国行きのパケット処理
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.
1つ以上の存在しているIPsecヘッダー/拡張子があれば、各々がどんなIPsecヘッダーも無視するので(どんなゼロもしないで、またどんな使用もしません)、処理は処理されるヘッダーにおいてその後で適用されました。
3.4.1. Reassembly
3.4.1. Reassembly
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断片であるように見えるか、すなわち、OFFSET分野が非零であるまたはMORE FRAGMENTS旗が設定されるなら、受信機はパケットを捨てなければなりません。 これは監査可能イベントです。 このイベントSHOULDのための監査ログエントリーはSPI値、日付/時間、Source Address、Destination Address、および(IPv6の)Flow 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仕様はOFFSET分野のゼロかMORE FRAGMENTS旗の開拓地のどちらかを必要としません。 組み立て直されたパケットがIPsec(見かけの断片として捨てられることと対照的に)によって処理されるように、パケットを組み立て直した後にIPコードはこれらの2つのことをしなければなりません。
3.4.2. Security Association Lookup
3.4.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 Authentication Headerを含むパケットを受け取り次第、受信機はSADのルックアップで適切な(単方向)SAを決定します。 SA、この決断に基づいているユニキャストのために、SPIかSPIがそのうえ、分野について議定書の中で述べます、セクション2.4で説明されるように。 また、実装がマルチキャストトラフィックをサポートするなら、送付先アドレスはルックアップ(SPIに加えた)で使われます、そして、送付者アドレスも使われるかもしれません、セクション2.4で説明されるように。 (このプロセスはさらに詳細にSecurity Architectureドキュメントで説明されます。) また、SAのためのSADエントリーは、Sequence Number分野がチェックされるかどうかと、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.
どんな有効なSecurity Associationもこのパケットのために存在していないなら、受信機はパケットを捨てなければなりません。 これは監査可能イベントです。 このイベントSHOULDのための監査ログエントリーはSPI値、日付/時間、Source Address、Destination Address、および(IPv6の)Flow 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.)
(SPIに基づいてIKEパケットなどのようにSA管理トラフィックが処理される必要はなくて、すなわち、1つが反-別々に例えば、NextプロトコルとPort分野に基づくこのトラフィックを多重送信できることに注意します)
Kent Standards Track [Page 18] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[18ページ]。
3.4.3. Sequence Number Verification
3.4.3. 一連番号検証
All AH implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. Anti-replay is applicable to unicast as well as multicast SAs. However, this standard specifies no mechanisms for providing anti- replay for a multi-sender SA (unicast or multicast). In the absence of negotiation (or manual configuration) of an anti-replay mechanism for such an SA, it is recommended that sender and receiver checking of the Sequence Number for the SA be disabled (via negotiation or manual configuration), as noted below.
すべてのAH実装が、反再生がサービスであるとサポートしなければなりません、使用は、1SAあたり1個のベースで受信機によって可能にされるか、または無効にされるかもしれませんが。 反再生はマルチキャストSAsと同様にユニキャストに適切です。 しかしながら、この規格はマルチ送付者SA(ユニキャストかマルチキャスト)のための反再生の提供にメカニズムを全く指定しません。 そのようなSAのための反再生メカニズムの交渉(または、手動の構成)がないとき、SAのためのSequence Numberの送付者と受信機点検が無効にされるのは(交渉か手動の構成で)、お勧めです、以下に述べられるように。
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のために反再生を可能にしないなら、どんな本国行きのチェックもSequence Numberに実行されません。 しかしながら、送付者の見解から、デフォルトは反再生が受信機で可能にされると仮定することです。IKEなどのSA設立プロトコルが採用しているなら送付者に不要な一連番号モニターとSAセットアップ(セクション3.3.2、「一連番号世代」を見る)をさせるのを避けるために、受信機SHOULDは送付者に通知します、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 MUSTに関する、ことになってください。 それぞれの容認されたパケットに関しては、受信機は、パケットがこのSAの寿命の間に受け取られたいかなる他のパケットのSequence NumberもコピーしないSequence Numberを含むことを確かめなければなりません。 このSHOULD、それが写しパケットの拒絶を促進するためにSAに合わせられた後にパケットに適用された最初のAHチェックになってください。
Duplicates are rejected through the use of a sliding receive window. How the window is implemented is a local matter, but the following text describes the functionality that the implementation must exhibit.
写しは拒絶されて、滑りの使用で、窓に受信されているということです。 窓がどう実装されるかは、地域にかかわる事柄ですが、以下のテキストは実装が示さなければならない機能性について説明します。
The "right" edge of the window represents the highest, validated Sequence Number value received on this SA. Packets that contain sequence numbers lower than the "left" edge of the window are rejected. Packets falling within the window are checked against a list of received packets within the window.
窓の「正しい」縁はこのSAに最も高くて、有効にされたSequence Number対価領収を表します。 窓の「左」の縁より低一連番号を含むパケットが拒絶されます。 窓の中に落ちるパケットは窓の中で容認されたパケットのリストに対してチェックされます。
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
ESNオプションがSAのために選択されるなら、一連番号の下位の32ビットだけが明らかに伝えられて、唯一の受信機が完全な一連番号が容認されたSequence Numberをチェックするとき、示されたSA(地元のカウンタからの)に高位32ビットを使用することで計算した雇用である、窓を受けてください。 下位の32ビットが運び込んだなら、完全な一連番号を構成します。
Kent Standards Track [Page 19] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[19ページ]。
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.)
値でパケットが受信機の一連番号カウンタの下位の32ビットより低い、受信機は高位32ビットが増加されたと仮定します、新しい一連番号部分空間に移行して。 (このアルゴリズムは2**32-1のパケットと同じくらい大きい独身のSAのためのレセプションでギャップを収容します。 より大きいギャップが起こるなら、受信機の一連番号カウンタの再同期のための追加していて、発見的なチェックは使われるかもしれません、Appendix 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同じくらいデータグラムを捨てなければなりません。 これは監査可能イベントです。 このイベントSHOULDのための監査ログエントリーはSPI値、日付/時間、Source Address、Destination Address、Sequence Number、および(IPv6の)Flow 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のパケットのMINIMUMウィンドウサイズをサポートしなければなりませんが、64のウィンドウサイズが好まれる、SHOULD、デフォルトとして、使われてください。 別のウィンドウサイズは受信機によって選ばれるかもしれません(MINIMUMより大きい)。. (受信機はウィンドウサイズについて送付者に通知しません。) レシーブ・ウィンドウ・サイズは保証問題の如何にかかわらずより高い速度環境のために増強されるべきです。 非常に高速な(例えば、マルチギガビット/秒)デバイスのための最小の、そして、お勧めのレシーブ・ウィンドウ・サイズのための値はこの規格によって指定されません。
3.4.4. Integrity Check Value Verification
3.4.4. 保全チェック値の検証
The receiver computes the ICV over the appropriate fields of the packet, using the specified integrity algorithm, and verifies that it is the same as the ICV included in the ICV field of the packet. Details of the computation are provided below.
受信機は、指定された保全アルゴリズムを使用して、パケットの適切な分野に関してICVを計算して、それがパケットのICV分野にICVを含んでいるのと同じであることを確かめます。 計算の詳細は以下に明らかにされます。
If the computed and received ICVs match, then the datagram is valid, and it is accepted. If the test fails, then the receiver MUST discard the received IP datagram as invalid. This is an auditable event. The audit log entry SHOULD include the SPI value, date/time received, Source Address, Destination Address, and (in IPv6) the Flow ID.
計算されて容認されたICVsが合っているなら、データグラムは有効です、そして、それを受け入れます。 テストが失敗するなら、受信機は無効の容認されたIP同じくらいデータグラムを捨てなければなりません。 これは監査可能イベントです。 監査ログエントリーSHOULDはSPI値、日付/受付時刻、Source Address、Destination Address、および(IPv6の)Flow 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計算を実行する前に議論のために「無常の分野を扱う」それの.1の分野のゼロが合わせられているセクション3.3.3を見てください。)
Kent Standards Track [Page 20] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[20ページ]。
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計算に使用されるなら、マッチング過程は、より複雑です。)
4. Auditing
4. 監査
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のための監査を可能にするか、または無効にするのを許容しなければなりません。 監査の粒状はだいたい、地域にかかわる事柄です。 しかしながら、いくつかの監査可能イベントがこの仕様で特定されます、そして、それぞれのこれらのイベントにおいて、SHOULDが監査ログに含まれているという最小の情報は定義されます。 追加情報もこの仕様で明らかに大声で叫んで、また、監査航空日誌記入事項をもたらすかもしれないのではなく、それぞれのこれらのイベント、および追加イベントのための監査ログに含まれるかもしれません。 受信機が監査可能イベントの検出に対応してどんなメッセージも主張された送付者に送るという要件が全くありません、そのような動作でサービスの否定を引き起こす可能性のために。
5. Conformance Requirements
5. 順応要件
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構文と処理を完全に実装しなければならなくて、Security Architectureドキュメント[ケン-アーチ]のすべての要件に従わなければなりません。 さらに、実装が、マルチキャストトラフィックをサポートすると主張するなら、それはそのようなトラフィックのサポートに指定される追加要件に応じなければなりません。 ICVを計算するのに使用されるキーが手動で分配されるなら、正しい反再生サービスの支給は送付者でカウンタ州の正しいメインテナンスを必要とするでしょう、キーを取り替えて、カウンタオーバーフローが差し迫っているならどんな自動化された回復支給もおそらくないまで。 その結果、SHOULD NOTが手動で合わせられるSAsに関連してこのサービスを提供する対応する実装。
The mandatory-to-implement algorithms for use with AH are described in a separate RFC [Eas04], to facilitate updating the algorithm requirements independently from the protocol per se. Additional algorithms, beyond those mandated for AH, MAY be supported.
AHとの使用のための実装するために義務的なアルゴリズムは、プロトコルからアルゴリズム要件を独自にそういうものとしてアップデートするのを容易にするために別々のRFC[Eas04]で説明されます。 追加アルゴリズムはAHのために強制されたものを超えてサポートされるかもしれません。
Kent Standards Track [Page 21] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[21ページ]。
6. Security Considerations
6. セキュリティ問題
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.
セキュリティはこのプロトコルのデザインに主要です、そして、これらのセキュリティ問題は仕様を普及させます。 Security ArchitectureドキュメントでIPsecプロトコルを使用する追加セキュリティ関連している局面について議論します。
7. Differences from RFC 2402
7. RFC2402からの違い
This document differs from RFC 2402 [RFC2402] in the following ways.
このドキュメントは以下の方法でRFC2402[RFC2402]と異なっています。
o SPI -- modified to specify a uniform algorithm for SAD lookup
for unicast and multicast SAs, covering a wider range of
multicast technologies. For unicast, the SPI may be used
alone to select an SA, or may be combined with the protocol,
at the option of the receiver. For multicast SAs, the SPI is
combined with the destination address, and optionally the
source address, to select an SA.
o Extended Sequence Number -- added a new option for a 64-bit
sequence number for very high-speed communications. Clarified
sender and receiver processing requirements for multicast SAs
and multi-sender SAs.
o Moved references to mandatory algorithms to a separate
document [Eas04].
o SPI--ユニキャストとマルチキャストSAsとしてSADルックアップに一定のアルゴリズムを指定するために、より広い範囲のマルチキャスト技術をカバーしていて、変更されます。 SPIはユニキャストにおいて、SAを選択するのに単独で使用されるか、またはプロトコルに結合されるかもしれません、受信機の選択のときに。ソースが扱う、SA o Extended Sequence Number--非常に高速なコミュニケーションのために64ビットの一連番号のための新しいオプションを加えるのを選択するために。マルチキャストSAsにおいて、SPIは送付先アドレスに任意に結合されます。 マルチ送付者SAs義務的なアルゴリズムのマルチキャストSAsとo Moved参照のために送付者と受信機処理所要を別々のドキュメント[Eas04]にはっきりさせました。
8. Acknowledgements
8. 承認
The author would like to acknowledge the contributions of Ran Atkinson, who played a critical role in initial IPsec activities, and who authored the first series of IPsec standards: RFCs 1825-1827. Karen Seo deserves special thanks for providing help in the editing of this and the previous version of this specification. The author also would like to thank the members of the IPsec and MSEC working groups who have contributed to the development of this protocol specification.
作者は初期のIPsec活動における重要な役割を果たして、最初のシリーズのIPsec規格を書いたRanアトキンソンの貢献を承諾したがっています: RFCs1825-1827。 カレンSeoはこの編集とこの仕様の旧バージョンに助けを提供することの特別な感謝に値します。 作者もこのプロトコル仕様の開発に貢献したIPsecとMSECワーキンググループのメンバーに感謝したがっています。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
[Bra97] ブラドナー、S.、「Indicate Requirement LevelへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[DH98] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[DH98]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
Kent Standards Track [Page 22] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[22ページ]。
[Eas04] 3rd Eastlake, D., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4305, December 2005.
[Eas04] 第3イーストレーク、D.、「セキュリティが有効搭載量(超能力)と認証ヘッダー(ああ)であるとカプセル化するための暗号アルゴリズム実装要件」、RFC4305(2005年12月)。
[Ken-Arch] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[ケン-アーチ] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC1108] Kent, S., "U.S. Department of Defense Security Options for
the Internet Protocol", RFC 1108, November 1991.
[RFC1108] ケント、S.、「インターネットプロトコルのための米国国防総省のセキュリティオプション」、RFC1108、1991年11月。
9.2. Informative References
9.2. 有益な参照
[AES] Advanced Encryption Standard (AES), Federal Information
Processing Standard 197, National Institutes of Standards
and Technology, November 26, 2001.
[AES]は暗号化規格(AES)と連邦情報処理基準197と規格の国家の研究所と技術、2001年11月26日を唱えました。
[HC03] Holbrook, H. and B. Cain, "Source Specific Multicast for
IP", Work in Progress, November 3, 2002.
[HC03] 「IPのためのソースの特定のマルチキャスト」というホルブルック、H.、およびB.カインは進歩、2002年11月3日に働いています。
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[IKEv2] コーフマン、C.、エド、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、12月2005日
[Ken-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[ケン-超能力] ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、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分野)の定義」、RFC2474(1998年12月)。
[RFB01] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001.
[RFB01] Ramakrishnan、K.、フロイド、S.、およびD.黒、「明白な混雑通知のIPへの追加(電子証券取引ネットワーク)」、RFC3168(2001年9月)。
[RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP
MTU discovery options", RFC 1063, July 1988.
[RFC1063] ムガール人とJ.とケントとC.とPartridge、C.とK.McCloghrie、「IP MTU発見オプション」、RFC1063、1988年7月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC1191] ムガール人とJ.とS.デアリング、「経路MTU探索」、RFC1191、1990年11月。
[RFC1385] Wang, Z., "EIP: The Extended Internet Protocol", RFC 1385,
November 1992.
[RFC1385]ワング、Z.、「EIP:」 「拡張インターネットプロトコル」、RFC1385、1992年11月。
Kent Standards Track [Page 23] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[23ページ]。
[RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393,
January 1993.
[RFC1393] マルキン、G.、「IPオプションを使用するトレースルート」、RFC1393、1993年1月。
[RFC1770] Graff, C., "IPv4 Option for Sender Directed Multi-
Destination Delivery", RFC 1770, March 1995.
[RFC1770]グラフ、C.、「送付者の指示されたマルチの目的地配送のためのIPv4オプション」、RFC1770、1995年3月。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February
1997.
[RFC2113] キャッツ、D.、「IPルータ警戒オプション」、RFC2113、1997年2月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[RFC2402] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003.
2003年7月の[RFC3547]BaugherとM.とウィスとB.とHardjono、T.とH.ハーニー、「解釈のグループドメイン」RFC3547。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, March 2004.
[RFC3740] HardjonoとT.とB.ウィス、「マルチキャストグループセキュリティー体系」、RFC3740、2004年3月。
Kent Standards Track [Page 24] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[24ページ]。
Appendix A: Mutability of IP Options/Extension Headers
付録A: IPオプション/拡張ヘッダーの無常
A1. IPv4 Options
A1。 IPv4オプション
This table shows how the IPv4 options are classified with regard to "mutability". Where two references are provided, the second one supercedes the first. This table is based in part on information provided in RFC 1700, "ASSIGNED NUMBERS", (October 1994).
このテーブルはIPv4オプションが「無常」に関してどう分類されるかを示しています。 2つの参照箇所を提供して、2番目の1supercedesが1番目であるところ。 このテーブルは「数は割り当てられた」RFC1700(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]
選んでください。 コピークラス#名前参照---- ----- --- ------------------------- -------- IMMUTABLE--ICV計算では、Router AlertのOptions List[RFC791]0 0 1ノーOperation[RFC791]1 0 2Security[RFC1108](歴史的な、しかし、使用中の)1 0 5Extended Security[RFC1108](歴史的な、しかし、使用中の)1 0 6Commercial Security1 0 20[RFC2113]1 0 21Sender Directed Multi[RFC1770]目的地Delivery MUTABLE--1 0 3Loose Source Route[RFC791]0 2 4Time Stamp[RFC791]0 0 7Record Route[RFC791]1 0 9Strict Source Route[RFC791]0 2 18Tracerouteのゼロを合わせる0 0 0Endを含んでいます。[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
EXPERIMENTAL、SUPERCEDED--1 0 8Stream ID[RFC791、RFC1122(ホストReq)]0 0 11MTU Probe[RFC1063、RFC1191(PMTU)]0 0 12MTU Reply[RFC1063、RFC1191(PMTU)]1 0 17Extendedインターネットプロトコル[RFC1385、DH98(IPv6)]0 0 10Experimental Measurement1 2 13Experimental Flow Control1 0 14Experimental Access Ctlのゼロを合わせる、0 0、15 1 0 16IMIトラフィック記述子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
以下に注意してください。 Router Alertオプションの使用は潜在的にIPsecの使用と両立しないです。 オプションは不変ですが、使用は、パケットの経路に沿った各ルータがパケットを「処理し」て、その結果、パケットを変えるかもしれないのを含意します。 パケットがルータからルータまで行くのに従って、これはホップによるホップベースで起こるでしょう。 prior to
Kent Standards Track [Page 25] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[25ページ]。
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.
オプションコンテンツが向けられるアプリケーション(例えば、Resource予約プロトコル(RSVP)/インターネットGroup Managementプロトコル(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オプションの分類が不変でパケットの経路に沿ったシステムによる(例えば、Basic Security Option(BSO)、Extended Security Option(ESO)、またはCommercialインターネット・プロトコル・セキュリティーOption(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バイトの境界で終わるのを保証するのに同じくらい必要な状態で繰り返されて、Options ListオプションSHOULDを終わらせてください。
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]
オプション/拡大名前参照----------------------------------- --------- MUTABLE BUT PREDICTABLE--ICV計算ルート設定(0をタイプする)では、含まれています。[DH98]
BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING
TRANSIT)
Hop-by-Hop options [DH98]
Destination options [DH98]
ホップごとのBIT INDICATES IF OPTION IS MUTABLE(CHANGES UNPREDICTABLY DURING TRANSIT)オプション[DH98]目的地オプション[DH98]
NOT APPLICABLE
Fragmentation [DH98]
適切な断片化でない[DH98]
Options -- IPv6 options in the Hop-by-Hop and Destination
Extension Headers contain a bit that indicates whether the option
might change (unpredictably) during transit. For any option for
which contents may change en route, the entire "Option Data" field
must be treated as zero-valued octets when computing or verifying
the ICV. The Option Type and Opt Data Len are included in the ICV
calculation. All options for which the bit indicates immutability
are included in the ICV calculation. See the IPv6 specification
[DH98] for more information.
オプション--ホップによるHopとDestination Extension HeadersのIPv6オプションはしばらくをオプションがトランジットの間、変化するかもしれないかどうかを(予想外に)示す含んでいます。 ICVについて計算するか、または確かめるとき、コンテンツが途中で変化するかもしれないどんなオプションにおいても、全体の「オプションデータ」分野を無評価された八重奏として扱わなければなりません。 Option TypeとOpt DataレンはICV計算に含まれています。 ビットが不変性を示すすべてのオプションがICV計算に含まれています。 詳しい情報のためのIPv6仕様[DH98]を見てください。
Kent Standards Track [Page 26] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[26ページ]。
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ルート設定Header、「0インチが望んでいるタイプはソースから目的地までのトランジットの間、パケットの中でアドレス・フィールドを再配列します」。 しかしながら、パケットの内容は受信機に現れるように送付者と、そして、すべての中間的ホップに知られています。 したがって、IPv6ルート設定Headerは「保全チェック値の計算で無常ですが、予測できた状態で含まれていた0インチをタイプします」。 送付者が分野を命令しなければならないので、受信機で見えるように見えます、ICV計算を実行する前に。
Fragmentation -- Fragmentation occurs after outbound IPsec
processing (Section 3.3) and reassembly occurs before inbound IPsec
processing (Section 3.4). So the Fragmentation Extension Header, if
it exists, is not seen by IPsec.
断片化--外国行きのIPsec処理の(セクション3.3)と再アセンブリが本国行きのIPsec処理(セクション3.4)の前に現れた後に断片化は起こります。 それで、存在しているなら、Fragmentation Extension Headerは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実装は適所にaをFragmentation Extension Headerに残すかもしれません。 これが起こるなら、AHがICVに処理をする前にパケットを受けるとき、AH MUSTは、このヘッダーを「取り除い」て(飛び越えてください)、Fragmentation Extension Headerの「次のヘッダー」分野になるように前のヘッダーの「次のヘッダー」分野を変えます。
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のOffset(最初の断片)と0のMore Fragments Flag(最後の断片)とFragmentation Extension HeaderがあるパケットをIPsecコードに与えるかもしれません。 これが起こるなら、AH MUSTは、ICVに処理をする前に、最初に、このヘッダーを「取り除い」て(飛び越えてください)、Fragmentation Extension Headerの「次のヘッダー」分野になるように前のヘッダーの「次のヘッダー」分野を変えます。
Kent Standards Track [Page 27] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[27ページ]。
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(超能力とAH)と共に使用のExtended Sequence Number(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.Thisウィンドウの反再生ウィンドウが遠くにオーダーを、パケットがどう使い果たすことができたかを制限すると主張するでしょう、今までのところ認証された中で最も高い一連番号があるパケットに比例して。 (要件は全く最小の、または、お勧めのサイズのためにこの窓に確立されません、値が既に32ビットの一連番号ウィンドウに確立した32と64パケットを超えて。 しかしながら、インタフェース速度と一致したこれらの値が実装でそれをサポートしたimplementerスケールが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
var. サイズ名(ビット)の意味---- ------ --------------------------- T64Highest一連番号が今までのところ認証した窓、T B64Lowerの32ビットが縛ったSeqのSeq Seqh32Upper32ビットの容認されたパケットSeql32Lower32ビットのB Seq64Sequence NumberのB Bh32Upper32ビットのウィンドウBl32Lower32ビットのT Th32UpperのウィンドウTl32Lower32ビットの上限のW32サイズ
Kent Standards Track [Page 28] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[28ページ]。
When performing the anti-replay check, or when determining which high-order bits to use to authenticate an incoming packet, there are two cases:
反再生チェックを実行するとき、入って来るパケットを認証するのにどの高位のビットを使用したらよいかを決定するとき、2つのケースがあります:
+ Case A: Tl >= (W - 1). In this case, the window is within one
sequence number subspace. (See Figure 1)
+ Case B: Tl < (W - 1). In this case, the window spans two
sequence number subspaces. (See Figure 2)
+ ケースA: Tl>=(W--1)。 この場合、1つの一連番号部分空間の中に窓があります。 (図1を参照します) + ケースB: Tl<(W--1)。 この場合、窓は2つの一連番号部分空間にかかります。 (図2を参照します)
In the figures below, the bottom line ("----") shows two consecutive
sequence number subspaces, with zeros indicating the beginning of
each subspace. The two shorter lines above it show the higher-order
bits that apply. The "====" represents the window. The "****"
represents future sequence numbers, i.e., those beyond the current
highest sequence number authenticated (ThTl).
以下の数字、結論、(「----」、)、ゼロがそれぞれの部分空間の始まりを示していて、2つの連続した一連番号部分空間を示しています。 それの上の2つより少ない系列は適用される高次なビットを見せています。 「The」====「窓を表します。」 ****、」 将来の一連番号、すなわち、向こうの現在の最も高い一連番号が認証したもの(ThTl)を表します。
Th+1 *********
+1 *****第****
Th =======*****
th=======*****
--0--------+-----+-----0--------+-----------0--
Bl Tl Bl
(Bl+2^32) mod 2^32
--0--------+-----+-----0--------+-----------0-- Bl Tl Bl (Bl+2^32) mod 2^32
Figure 1 -- Case A
図1--ケースA
Th ====**************
th====**************
Th-1 ===
-1番目===
--0-----------------+--0--+--------------+--0--
Bl Tl Bl
(Bl+2^32) mod 2^32
--0-----------------+--0--+--------------+--0-- Bl Tl Bl (Bl+2^32) mod 2^32
Figure 2 -- Case B
図2--ケースB
B2.1. Managing and Using the Anti-Replay Window
B2.1。 反再生ウィンドウを管理して、使用します。
The anti-replay window can be thought of as a string of bits where `W' defines the length of the string. W = T - B + 1 and cannot exceed 2^32 - 1 in value. The bottom-most bit corresponds to B and the top-most bit corresponds to T, and each sequence number from Bl through Tl is represented by a corresponding bit. The value of the bit indicates whether or not a packet with that sequence number has been received and authenticated, so that replays can be detected and rejected.
'W'がストリングの長さを定義する一連のビットとして反再生ウィンドウを考えることができます。 Wは、T--B+1と等しく、値における2^32--1を超えることができません。 最も下部ビットはBに対応しています、そして、最も最高ビットはTに対応しています、そして、BlからTlの各一連番号は対応するビットによって表されます。 ビットの価値は、その一連番号があるパケットが受け取られて、認証されたかどうかを示します、再生を検出して、拒絶できるように。
Kent Standards Track [Page 29] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[29ページ]。
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による(Seq--T)+(Seq--T)によって増強されて、ビットがその一連番号があるパケットが示してください+ トップビットが設定される窓の上位ですが、受け取って、+ (Seq--T)ビットが加えられる窓のローエンドから下げられて、認証されて、+ Tとトップビットの間の新しいビットが、それらの一連番号があるパケットが全くまだ受け取られていないのを示すように設定されるということです。 + Tは新しい一連番号に設定されます。
In checking for replayed packets,
再演されたパケットがないかどうかチェックする際に
+ Under Case A: If Seql >= Bl (where Bl = Tl - W + 1) AND
Seql <= Tl, then check the corresponding bit in the window to
see if this Seql has already been seen. If yes, reject the
packet. If no, perform integrity check (see Appendix B2.2
below for determination of SeqH).
+ 場合A:の下で Seql>がBl(どこBl=Tl--W+1)と等しいか、そして、Seql<がTlと等しいなら窓で対応するビットをチェックして、このSeqlが既に見られたかどうか確認してください。 はいなら、パケットを拒絶してください。 いいえなら、保全チェックを実行してください(SeqHの決断に関して以下のAppendix B2.2を見てください)。
+ Under Case B: If Seql >= Bl (where Bl = Tl - W + 1) OR
Seql <= Tl, then check the corresponding bit in the window to
see if this Seql has already been seen. If yes, reject the
packet. If no, perform integrity check (see Appendix B2.2
below for determination of Seqh).
場合Bの下における+: Seql>=Bl(どこBl=Tl--W+1)OR Seql<がTlと等しいかなら窓で対応するビットをチェックして、このSeqlが既に見られたかどうか確認してください。 はいなら、パケットを拒絶してください。 いいえなら、保全チェックを実行してください(Seqhの決断に関して以下のAppendix 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を選択する方法を定義します。 極端なパケット損失からどう回復するかに関する議論に関してAppendix B3を見てください。
+ Under Case A (Figure 1):
If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th
If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th + 1
+ 下のケースA(図1): Seql>がBl(どこBl=Tl--W+1)と等しいかならSeqhがIf Seql<第Bl(どこBl=Tl--W+1)、当時のSeqh=と等しいか、+ 1番目
+ Under Case B (Figure 2):
If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th - 1
If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th
場合B(図2)の下における+: Seql>がBl(どこBl=Tl--W+1)、当時のSeqh=と等しいか、第--、1If Seql<Bl(どこBl=Tl--W+1)、当時の第Seqh=
Kent Standards Track [Page 30] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[30ページ]。
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です。
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
Seql Passに対応している、(保全チェックを通過します)セットがElse廃棄物パケットElse廃棄物パケットElse If(保全チェックを通過する)Tlの上のパケットに噛み付いて、Seql Passに対応していたなら(パス再生チェック)がSeql(シフトビット)セット・ビットと等しいなら(Tl>=W--1)ケースA If(Seql>=Tl--W+1)Seqhが第If(Seql<はTlと等しい)と等しいなら+ Elseの廃棄物のパケットのElse Seqhの=の1If(保全チェックを通過する)の第Tlの上のパケットがSeqlと等しい、(シフトビット)第等しさ、+ 1番目; セットがElse廃棄物パケットElse Case B If(Seql>=Tl--W+1)Seqh=の上のパケットに噛み付いて、Seql Passに対応していた、第--(パス保全チェック)が(パス再生チェック)であるなら(パス保全チェック)であるならElse廃棄物パケットElse廃棄物パケットElse Seqh=第If(Seql<はTlと等しい)でSeql Passパケットに対応するビットを設定するなら1If(再生チェックを通過する)がElse廃棄物パケットElse廃棄物パケットでSeql Passパケットに対応するビットを設定する
Kent Standards Track [Page 31] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[31ページ]。
Else
If (pass integrity check)
Tl = Seql (shift bits)
Set the bit corresponding to Seql
Pass packet on
Else reject packet
ほかに、If(保全チェックを通過する)Tl=Seql(シフトビット)はElse廃棄物パケットでSeql Passパケットに対応するビットを設定します。
B3. Handling Loss of Synchronization due to Significant Packet Loss
B3。 Significant Packet LossによるSynchronizationの取り扱いLoss
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.
2^32以上の連続したパケットの非検出されたパケット損失が独身のSAにあると、送信機と受信機は高位のビットの同期を失うでしょう、すなわち、Appendix B2.2の方程式。正しい値をもたらさないでしょう。 この問題が検出されて、記述されないと、このSAの上のその後のパケットは、認証チェックに失敗して、捨てられるでしょう。 以下の手順SHOULD、ESNオプションをサポートするあらゆるIPsec(超能力か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.
この種類の拡張交通の損失が問題のSAにおける交通のどれか重要な部分もTCPであるなら起こりそうにないことに注意してください、2つの^32パケットが失われたずっと前に、ソースは、ACKsを受け取らないで、発信するのを止めるでしょう、したがって。 また、どんな両性愛者の方向のアプリケーション、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.
+は、攻撃者が再同期の過程にリソースの転換を強制するのを許容することによって起こるかもしれないようなサービス攻撃の新しい否定の機会を作成するのを避けます。 反再生が受信機のためだけのサービスであるので、+は回収機構を受信機に制限します、そして、一般に、送信機は受信機がこの任意のサービスを支持して一連番号を使用しているかどうかを意識していません。 回収機構が受信機にローカルであることは、望ましいです。また、これは後方のために互換性を許容します。
Kent Standards Track [Page 32] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[32ページ]。
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の上の有効なパケットの領収書はゼロにカウンタをリセットします。 再同期の過程の引き金となるのに使用される値はローカルのパラメタです。 implementerは、そうするのを選ぶかもしれませんが、異なったSAsのために異なった引き金の値を支持するという要件が全くありません。
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(または、超能力)ペイロードの後にそれとなく置かれるので、パケットの上で保全アルゴリズムをペイロードの終点まで実行することによってこの手順を最適化して、次に、Seqhの値を変えることによって異なった候補ICVsを計算するのは可能であるかもしれません。) この手順を通したパケットのうまくいっている認証は、容認されたパケットのものに連続した失敗カウントをリセットして、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モールトン・通りMA02138ケンブリッジ(米国)
Phone: +1 (617) 873-3988 EMail: kent@bbn.com
以下に電話をしてください。 +1 (617) 873-3988 メールしてください: kent@bbn.com
Kent Standards Track [Page 33] RFC 4302 IP Authentication Header December 2005
ケント規格はIP認証ヘッダー2005年12月にRFC4302を追跡します[33ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Kent Standards Track [Page 34]
ケント標準化過程[34ページ]
一覧
スポンサーリンク
