RFC2402 日本語訳
2402 IP Authentication Header. S. Kent, R. Atkinson. November 1998. (Format: TXT=52831 bytes) (Obsoletes RFC1826) (Obsoleted by RFC4302, RFC4305) (Status: PROPOSED STANDARD)
RFC一覧
英語原文
Network Working Group S. Kent
Request for Comments: 2402 BBN Corp
Obsoletes: 1826 R. Atkinson
Category: Standards Track @Home Network
November 1998
IP Authentication Header
IP 認証ヘッダ
Status of this Memo
このメモの位置づけ
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
この文書は、Internet community のための Internet standards track
protocol を明細に記述し、改良のための討議と提案を要求する。このプロ
トコルの標準化状態とステータスについては、"Internet Official
Protocol Standards" (STD 1) の最新版を参照してもらいたい。このメモの
配布は、無制限である。
-----------------------------------------------------------------------
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
-----------------------------------------------------------------------
Table of Contents
目次
1. Introduction......................................................2
2. Authentication Header Format......................................3
2.1 Next Header...................................................4
2.2 Payload Length................................................4
2.3 Reserved......................................................4
2.4 Security Parameters Index (SPI)...............................4
2.5 Sequence Number...............................................5
2.6 Authentication Data ..........................................5
3. Authentication Header Processing..................................5
3.1 Authentication Header Location...............................5
3.2 Authentication Algorithms....................................7
3.3 Outbound Packet Processing...................................8
3.3.1 Security Association Lookup.............................8
3.3.2 Sequence Number Generation..............................8
3.3.3 Integrity Check Value Calculation.......................9
3.3.3.1 Handling Mutable Fields............................9
3.3.3.1.1 ICV Computation for IPv4.....................10
3.3.3.1.1.1 Base Header Fields.......................10
3.3.3.1.1.2 Options..................................11
3.3.3.1.2 ICV Computation for IPv6.....................11
3.3.3.1.2.1 Base Header Fields.......................11
3.3.3.1.2.2 Extension Headers Containing Options.....11
3.3.3.1.2.3 Extension Headers Not Containing Options.11
3.3.3.2 Padding...........................................12
3.3.3.2.1 Authentication Data Padding..................12
3.3.3.2.2 Implicit Packet Padding......................12
3.3.4 Fragmentation..........................................12
3.4 Inbound Packet Processing...................................13
3.4.1 Reassembly.............................................13
3.4.2 Security Association Lookup............................13
3.4.3 Sequence Number Verification...........................13
3.4.4 Integrity Check Value Verification.....................15
4. Auditing.........................................................15
5. Conformance Requirements.........................................16
6. Security Considerations..........................................16
7. Differences from RFC 1826........................................16
Acknowledgements....................................................17
Appendix A -- Mutability of IP Options/Extension Headers............18
A1. IPv4 Options.................................................18
A2. IPv6 Extension Headers.......................................19
References..........................................................20
Disclaimer..........................................................21
Author Information..................................................22
Full Copyright Statement............................................22
1. 序論..............................................................2
2. 認証ヘッダ形式....................................................3
2.1 次ヘッダ......................................................4
2.2 ペイロード長..................................................4
2.3 予約..........................................................4
2.4 セキュリティパラメータインデックス (SPI)......................4
2.5 順序番号......................................................5
2.6 認証データ....................................................5
3. 認証ヘッダ処理....................................................5
3.1 認証ヘッダ位置...............................................5
3.2 認証アルゴリズム.............................................7
3.3 外向けパケット処理...........................................8
3.3.1 セキュリティアソシエーションルックアップ................8
3.3.2 順序番号生成............................................8
3.3.3 完全性チェック値計算....................................9
3.3.3.1 変わりやすいフィールドの扱い.......................9
3.3.3.1.1 IPv4 についての ICV 計算.....................10
3.3.3.1.1.1 基本ヘッダフィールド.....................10
3.3.3.1.1.2 オプション...............................11
3.3.3.1.2 IPv6 についての ICV 計算.....................11
3.3.3.1.2.1 基本ヘッダフィールド.....................11
3.3.3.1.2.2 オプションを含む拡張ヘッダ...............11
3.3.3.1.2.3 オプションを含まない拡張ヘッダ...........11
3.3.3.2 パディング........................................12
3.3.3.2.1 認証データパディング.........................12
3.3.3.2.2 暗黙のパケットパディング.....................12
3.3.4 分割...................................................12
3.4 内向けパケット処理..........................................13
3.4.1 再構成.................................................13
3.4.2 セキュリティアソシエーションルックアップ...............13
3.4.3 順序番号検証...........................................13
3.4.4 完全性チェック値検証...................................15
4. 監査.............................................................15
5. 適合への要求.....................................................16
6. セキュリティに関する考察.........................................16
7. RFC 1826 との相違................................................16
謝辞................................................................17
付録 A -- IP オプション/拡張ヘッダの変わりやすさ....................18
A1. IPv4 オプション..............................................18
A2. IPv6 拡張ヘッダ..............................................19
参考文献............................................................20
否認声明書..........................................................21
著者の情報..........................................................22
著作権表示全文......................................................22
-----------------------------------------------------------------------
1. Introduction
1. 序論
The IP Authentication Header (AH) is used to provide connectionless
integrity and data origin authentication for IP datagrams (hereafter
referred to as just "authentication"), and to provide protection
against replays. This latter, optional service may be selected, by
the receiver, when a Security Association is established. (Although
the default calls for the sender to increment the Sequence Number
used for anti-replay, the service is effective only if the receiver
checks the Sequence Number.) AH provides authentication for as much
of the IP header as possible, as well as for upper level protocol
data. However, some IP header fields may change in transit and the
value of these fields, when the packet arrives at the receiver, may
not be predictable by the sender. The values of such fields cannot
be protected by AH. Thus the protection provided to the IP header by
AH is somewhat piecemeal.
IP Authentication Header (AH: 認証ヘッダ) は、IP データグラムにコネ
クションレス完全性とデータ源認証を提供するために使用される ((これら
2 つのサービスは) これから先、単に "authentication (認証)" として参
照される)。および AH は、replays に対する保護を提供するために使用さ
れる。後者の、オプションのサービスは、Security Association が確立さ
れる時、受信側により選択されるかもしれない。(anti-replay のために使
用される Sequence Number を増やす送信側を、デフォルトは必要とするけ
れども、受信側が Sequence Number をチェックする場合のみ、このサービ
スは有効である。) AH は、上位層プロトコルデータのためだけでなく、で
きるだけ IP ヘッダ大部分のための認証を提供する。しかしながら、一部の
IP ヘッダフィールドは転送中に変化するだろうし、パケットが受信側に到
着する時、それらフィールドの値は送信側により予測できないだろう。その
ようなフィールドの値は、AH により保護されない。したがって、AH により
IP ヘッダへと提供される保護は、やや少ない。
AH may be applied alone, in combination with the IP Encapsulating
Security Payload (ESP) [KA97b], or in a nested fashion through the
use of tunnel mode (see "Security Architecture for the Internet
Protocol" [KA97a], hereafter referred to as the Security Architecture
document). Security services can be provided between a pair of
communicating hosts, between a pair of communicating security
gateways, or between a security gateway and a host. ESP may be used
to provide the same security services, and it also provides a
confidentiality (encryption) service. The primary difference between
the authentication provided by ESP and AH is the extent of the
coverage. Specifically, ESP does not protect any IP header fields
unless those fields are encapsulated by ESP (tunnel mode). For more
details on how to use AH and ESP in various network environments, see
the Security Architecture document [KA97a].
AH は、次の 3 つの方法で適用されるかもしれない。それらの方法とは、単
独でか、IP Encapsulating Security Payload (ESP: 暗号ペイロード)
[KA97b] との組み合わせか、tunnel mode の使用を通しての入れ子の方法で
ある (これから先 Security Architecture 文書として参照される
"Security Architecture for the Internet Protocol" [KA97a] を参照しな
さい)。セキュリティサービスは、通信しているホストの組間、通信してい
るセキュリティゲートウェイの組間か、セキュリティゲートウェイとホスト
間で提供されることができる。ESP は、同じセキュリティサービスを提供す
るために使用されるかもしれない。そして ESP は、機密性 (暗号化) サー
ビスも提供する。ESP と AH により提供される認証の間の根本的な違いは、
保護範囲の広さである。特にもし IP ヘッダのフィールドが ESP (tunnel
mode) によりカプセル化されなければ、ESP はどんな IP ヘッダフィールド
をも保護しない。さまざまなネットワーク環境で、AH と ESP をどのように
使用するかというさらに多くの詳細について、Security Architecture 文書
[KA97a] を参照しなさい。
It is assumed that the reader is familiar with the terms and concepts
described in the Security Architecture document. In particular, the
reader should be familiar with the definitions of security services
offered by AH and ESP, the concept of Security Associations, the ways
in which AH can be used in conjunction with ESP, and the different
key management options available for AH and ESP. (With regard to the
last topic, the current key management options required for both AH
and ESP are manual keying and automated keying via IKE [HC98].)
読者は Security Architecture 文書で記述される用語と概念に精通してい
ると当然思われる。特に読者は、AH と ESP により提供されるセキュリティ
サービスの定義、Security Associations の概念、ESP とともに使用される
ことができる AH の方法と、AH と ESP に利用可能な異なる鍵管理オプショ
ンに精通しているべきである。(最後の topic に関し、AH と ESP 両方に必
要とされる現在の鍵管理オプションは、手動鍵設定と IKE [HC98] 経由での
自動鍵設定である。)
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in RFC 2119 [Bra97].
キーワード MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY と OPTIONAL が、この文書で現れた時、
RFC 2119 [Bra97] で記述されたとして解釈されることができる。
-----------------------------------------------------------------------
2. Authentication Header Format
2. 認証ヘッダ形式
The protocol header (IPv4, IPv6, or Extension) immediately preceding
the AH header will contain the value 51 in its Protocol (IPv4) or
Next Header (IPv6, Extension) field [STD-2].
AH ヘッダの直接前にあるプロトコルヘッダ (IPv4, IPv6 または Extension
(拡張)) は、その Protocol (IPv4) や Next Header (次ヘッダ) (IPv6,
Extension) フィールドに値 51 を含む [STD-2]。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Payload Len | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Authentication Data (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 次ヘッダ | ペイロード長 | 予約 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| セキュリティパラメータインデックス (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 順序番号フィールド |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ 認証データ (可変長) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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).
次に述べる subsections は、AH 形式を構成するフィールドを定義する。こ
こで記述されるすべてのフィールドは必須である。すなわち、これらフィー
ルドは、AH 形式にいつもあらわれ、そして Integrity Check Value (ICV:
完全性チェック値) 計算に含まれる (Sections 2.6 と 3.3.3 を参照しなさ
い)。
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 in the
most recent "Assigned Numbers" [STD-2] RFC from the Internet Assigned
Numbers Authority (IANA).
Next Header は、Authentication Header の後の次のペイロードタイプを識
別する 8-bit フィールドである。このフィールドの値は、IP Protocol
Numbers のセットから選ばれる。その IP Protocol Numbers のセットは、
Internet Assigned Numbers Authority (IANA) からの最も最新の
"Assigned Numbers" [STD-2] RFC で定義される。
2.2 Payload Length
2.2 ペイロード長
This 8-bit field specifies the length of AH in 32-bit words (4-byte
units), minus "2". (All IPv6 extension headers, as per RFC 1883,
encode the "Hdr Ext Len" field by first subtracting 1 (64-bit word)
from the header length (measured in 64-bit words). AH is an IPv6
extension header. However, since its length is measured in 32-bit
words, the "Payload Length" is calculated by subtracting 2 (32 bit
words).) In the "standard" case of a 96-bit authentication value
plus the 3 32-bit word fixed portion, this length field will be "4".
A "null" authentication algorithm may be used only for debugging
purposes. Its use would result in a "1" value for this field for
IPv4 or a "2" for IPv6, as there would be no corresponding
Authentication Data field (see Section 3.3.3.2.1 on "Authentication
Data Padding").
この 8-bit フィールドは、"2" (words) を引いた 32-bit words (4-byte
単位) での AH の長さを明細に述べる。(RFC 1883 に従い、すべての IPv6
extension header (拡張ヘッダ) は、(64-bit words での長さの) ヘッダ長
から 1 (64-bit word) を最初に引くことにより "Hdr Ext Len" フィールド
を符号化する。AH は、1 つの IPv6 拡張ヘッダである。しかしながら、こ
の (AH) 長さは 32-bit words での長さであるため、"Payload Length" は
2 (32 bit words) を引くことにより計算される。) 3 の 32-bit word
fixed portion (固定化された部分) を加えた 96-bit 認証値の "standard
(標準)" ケースについて、この長さフィールドは "4" である。"null" 認証
アルゴリズムは、デバッグ目的のためだけに使用されるかもしれない。一致
する Authentication Data フィールドがない時、その使用は、IPv4 でのこ
のフィールド使用のために "1"、または IPv6 のために "2" という結果に
なる ("Authentication Data Padding" の Section 3.3.3.2.1 を参照しな
さい)。
訳注) In the "standard" ... の部分で 4 の値が格納されるとは、
上の図で 1 (32-bit words) の Sequence Number と 3
(32-bit words) の Authentication Data の長さを足した値
のことを言う。
2.3 Reserved
2.3 予約
This 16-bit field is reserved for future use. It MUST be set to
"zero." (Note that the value is included in the Authentication Data
calculation, but is otherwise ignored by the recipient.)
この 16-bit フィールドは、将来の使用のために予約される。これは、
"zero" にセットされなければならない (MUST)。(この値は、
Authentication Data 計算に含まれるが、その他の点では受信側により無視
されることに注意しなさい。)
2.4 Security Parameters Index (SPI)
2.4 セキュリティパラメータインデックス (SPI)
The SPI is an arbitrary 32-bit value that, in combination with the
destination IP address and security protocol (AH), uniquely
identifies the Security Association for this datagram. The set of
SPI values in the range 1 through 255 are reserved by the Internet
Assigned Numbers Authority (IANA) for future use; a reserved SPI
value will not normally be assigned by IANA unless the use of the
assigned SPI value is specified in an RFC. It is ordinarily selected
by the destination system upon establishment of an SA (see the
Security Architecture document for more details).
SPI は、終点 IP アドレスとセキュリティプロトコル (AH) での組み合わせ
で、このデータグラムについての Security Association を一意に識別する
任意の 32-bit 値である。範囲 1 から 255 の SPI 値のセットは、将来の
使用のために Internet Assigned Numbers Authority (IANA) により予約さ
れる; もし割り当てられた SPI 値の使用法が RFC で明細に述べられなけれ
ば、予約された SPI 値は IANA により標準的に割り当てられないだろう。
これ (SPI) は、SA 確立の上で終点システムにより通常選択される (さらに
多くの詳細について、Security Architecture 文書を参照しなさい)。
The SPI value of zero (0) is reserved for local, implementation-
specific use and MUST NOT be sent on the wire. For example, a key
management implementation MAY use the zero SPI value to mean "No
Security Association Exists" during the period when the IPsec
implementation has requested that its key management entity establish
a new SA, but the SA has not yet been established.
zero (0) の SPI 値は、local と実装上の限定使用のために予約され、wire
上に決して送信されてはならない (MUST NOT)。使用例として、次に述べる
鍵管理実装が zero SPI 値を使用するかもしれない (MAY)。これは、その鍵
管理実体が新しい SA を確立することを IPsec 実装が要求するが SA はま
だ確立されていない時に、その期間は "No Security Association Exists
(セキュリティアソシエーションが存在しない)" ことを意味するために SPI
値を使用する場合である。
2.5 Sequence Number
2.5 順序番号
This unsigned 32-bit field contains a monotonically increasing
counter value (sequence number). It is mandatory and is always
present even if the receiver does not elect to enable the anti-replay
service for a specific SA. Processing of the Sequence Number field
is at the discretion of the receiver, i.e., the sender MUST always
transmit this field, but the receiver need not act upon it (see the
discussion of Sequence Number Verification in the "Inbound Packet
Processing" section below).
この符号なし 32-bit フィールドは、単調に増加していくカウンタ値 (順序
番号) を含む。これは必須であり、たとえある特定の SA について受信側が
anti-replay サービスを可能にすることを選ばなくても、このフィールドは
いつもある。Sequence Number フィールドの処理は、受信側の自由判断であ
る。すなわち送信側は、このフィールドをいつも転送しなければならない
(MUST) が、受信側は、これに従う必要はない (下の "Inbound Packet
Processing" section での Sequence Number Verification (順序番号検証)
審議を参照しなさい)。
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 の
Sequence Number を持つ; Sequence Number がどのように生成されるかとい
うさらなる詳細について、Section 3.3.2 を参照しなさい。) もし anti-
replay が可能である (default) なら、転送される Sequence Number は循
環を決して許してはならない。したがって、送信側のカウンタと受信側のカ
ウンタは、ある SA 上での 2^32 乗の転送より前に、(新しい SA と、した
がって新しい鍵を確立することにより) リセットされなければならない
(MUST)。
2.6 Authentication Data
2.6 認証データ
This is a variable-length field that contains the Integrity Check
Value (ICV) for this packet. The field must be an integral multiple
of 32 bits in length. The details of the ICV computation are
described in Section 3.3.2 below. This field may include explicit
padding. This padding is included to ensure that the length of the
AH header is an integral multiple of 32 bits (IPv4) or 64 bits
(IPv6). All implementations MUST support such padding. Details of
how to compute the required padding length are provided below. The
authentication algorithm specification MUST specify the length of the
ICV and the comparison rules and processing steps for validation.
これは、このパケットのための Integrity Check Value (ICV) を含む可変
長フィールドである。このフィールドは、長さが 32 bits での整数倍でな
ければならない。ICV 計算の詳細は、下の Section 3.2.2 で記述される。
このフィールドは、明示的なパディングを含むかもしれない。このパディン
グは、次のことを保証するために含まれる。それは、AH ヘッダ長が (IPv4
で) 32 bits か (IPv6 で) 64bits の整数倍であることを保証することであ
る。すべての実装は、そのようなパディングをサポートしなければならない
(MUST)。必要とされるパディング長をどのように計算するかという詳細は、
下で提供される。認証アルゴリズム仕様書は、有効であるかの認証に関する
ICV 長、比較規則と処理ステップを明細に述べなければならない (MUST)。
-----------------------------------------------------------------------
3. Authentication Header Processing
3. 認証ヘッダ処理
3.1 Authentication Header Location
3.1 認証ヘッダ位置
Like ESP, AH may be employed in two ways: transport mode or tunnel
mode. The former mode is applicable only to host implementations and
provides protection for upper layer protocols, in addition to
selected IP header fields. (In this mode, note that for "bump-in-
the-stack" or "bump-in-the-wire" implementations, as defined in the
Security Architecture document, inbound and outbound IP fragments may
require an IPsec implementation to perform extra IP
reassembly/fragmentation in order to both conform to this
specification and provide transparent IPsec support. Special care is
required to perform such operations within these implementations when
multiple interfaces are in use.)
ESP のように、AH は 2 つの方法: transport mode か tunnel mode で使用
されるだろう。前者の mode はホスト実装にのみ適用可能で、選ばれた IP
ヘッダフィールドを加えて上位層プロトコルの保護を提供する。(この mode
では、Security Architecture 文書で定義されたとして、"bump-in-the-
stack" や "bump-in-the-wire" 実装に関し、次のことに注意しなさい。そ
れは、inbound (内向け) と outbound (外向け) の IP 断片は、この仕様書
に従うことと透過的な IPsec サポートを提供すること両方のために、特別
の IP 再構成/分割をおこなう IPsec 実装を必要とするかもしれないことで
ある。複数インターフェイスが使用されている時、特別の注意が、それら実
装内でそのような処理をおこなうために必要とされる。)
In transport mode, AH is inserted after the IP header and before an
upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other
IPsec headers that have already been inserted. In the context of
IPv4, this calls for placing AH after the IP header (and any options
that it contains), but before the upper layer protocol. (Note that
the term "transport" mode should not be misconstrued as restricting
its use to TCP and UDP. For example, an ICMP message MAY be sent
using either "transport" mode or "tunnel" mode.) The following
diagram illustrates AH transport mode positioning for a typical IPv4
packet, on a "before and after" basis.
transport mode では、AH は IP ヘッダの後で、かつ上位層プロトコルの前
に挿入される。上位層プロトコルの例は、TCP, UDP, ICMP 等である。また
は ESP は、IP ヘッダの後で、かつすでに挿入された何らかの IPsec ヘッ
ダの前に挿入される。IPv4 の環境で、これは AH を IP ヘッダ (とその IP
ヘッダが含む何らかのオプション) の後に、しかし上位層プロトコルの前に
置くことを必要とする。(用語 "transport" mode は、TCP と UDP にその使
用を制限するとして誤解されるべきでないことに注意しなさい。たとえば
ICMP メッセージは "transport" mode か "tunnel" mode どちらかを使用し
て送信されるかもしれない (MAY)。) 次の図は、"before and after" 形式
で典型的な IPv4 パケットの位置を定めている AH transport mode を説明
する。
BEFORE APPLYING AH
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING AH
---------------------------------
IPv4 |orig IP hdr | | | |
|(any options)| AH | TCP | Data |
---------------------------------
|<------- authenticated ------->|
except for mutable fields
AH を適用する前
-------------------------------
IPv4 |もとの IP ヘッダ| | |
|(any options) | TCP | Data |
-------------------------------
AH を適用した後
------------------------------------
IPv4 |もとの IP ヘッダ| | | |
|(any options) | AH | TCP | Data |
------------------------------------
|<------------- 認証 ------------->|
変わりやすいフィールドを除いて
In the IPv6 context, AH is viewed as an end-to-end payload, and thus
should appear after hop-by-hop, routing, and fragmentation extension
headers. The destination options extension header(s) could appear
either before or after the AH header depending on the semantics
desired. The following diagram illustrates AH transport mode
positioning for a typical IPv6 packet.
IPv6 環境で、AH は endi-to-end ペイロードとして見られる。したがって
ESP は、hop-by-hop (中継点), routing (経路制御) と fragmentation (分
割) 拡張ヘッダの後に現れるだろう。destination (終点) オプション拡張
ヘッダ(s) は、望まれる semantics に依存して AH ヘッダの前か後のどち
らかに現れることができる。次の図は、典型的な IPv6 パケットの位置を定
めている AH transport mode を説明する。
BEFORE APPLYING AH
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
AFTER APPLYING AH
------------------------------------------------------------
IPv6 | |hop-by-hop, dest*, | | dest | | |
|orig IP hdr |routing, fragment. | AH | opt* | TCP | Data |
------------------------------------------------------------
|<---- authenticated except for mutable fields ----------->|
AH を適用する前
---------------------------------------
IPv6 | もとの | 拡張ヘッダ | | |
| IP ヘッダ |もしあるなら| TCP | Data |
---------------------------------------
AH を適用した後
------------------------------------------------------
IPv6 | もとの |中継点, 終点*, | | 終点 | | |
| IP ヘッダ |経路制御, 分割 | AH | opt* | TCP | Data |
------------------------------------------------------
|<---- 変わりやすいフィールドを除いた認証 ---------->|
* = if present, could be before AH, after AH, or both
* = もしあるなら、AH の前か後、もしくは両方であること
ができる
ESP and AH headers can be combined in a variety of modes. The IPsec
Architecture document describes the combinations of security
associations that must be supported.
ESP と AH ヘッダは、さまざまな modes で組み合わされることができる。
IPsec Architecture 文書は、サポートされなければならないセキュリティ
アソシエーションの組み合わせを記述する。
Tunnel mode AH may be employed in either hosts or security gateways
(or in so-called "bump-in-the-stack" or "bump-in-the-wire"
implementations, as defined in the Security Architecture document).
When AH is implemented in a security gateway (to protect transit
traffic), tunnel mode must be used. In tunnel mode, the "inner" IP
header carries the ultimate source and destination addresses, while
an "outer" IP header may contain distinct IP addresses, e.g.,
addresses of security gateways. In tunnel mode, AH protects the
entire inner IP packet, including the entire inner IP header. The
position of AH in tunnel mode, relative to the outer IP header, is
the same as for AH in transport mode. The following diagram
illustrates AH tunnel mode positioning for typical IPv4 and IPv6
packets.
tunnel mode AH は、ホスト間か security gateways 間のどちらかで使用さ
れるだろう (もしくは、Security Architecture 文書で定義されたとして
いわゆる "bump-in-the-stack" か "bump-in-the-wire" 実装で使用される
だろう)。(通過する traffic を保護するため) AH が security gateway で
実装される時、tunnel mode は使用されなければならない。tunnel mode で
"inner" IP ヘッダは、最終となる始点と終点アドレスを運ぶけれども、
"outer" IP ヘッダは、異なった IP アドレスを含むかもしれない。異なる
IP アドレスの例は、security gateways のアドレスである。tunnel mode
で、AH は、全体の IP ヘッダを含んだ全体の inner IP パケットを保護す
る。tunnel mode での AH の位置は、outer IP ヘッダと比較して、
transport mode での AH に関する限りでは同じである。次の図は、典型的
な IPv4 と IPv6 の位置を定めている AH tunnel mode を説明する。
------------------------------------------------
IPv4 | new IP hdr* | | orig IP hdr* | | |
|(any options)| AH | (any options) |TCP | Data |
------------------------------------------------
|<- authenticated except for mutable fields -->|
| in the new IP hdr |
--------------------------------------------------------------
IPv6 | | ext hdrs*| | | ext hdrs*| | |
|new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data|
--------------------------------------------------------------
|<-- authenticated except for mutable fields in new IP hdr ->|
---------------------------------------------------
IPv4 | 新 IP ヘッダ*| |もとの IP ヘッダ*| | |
|(any options) | AH |(any options) |TCP | Data |
---------------------------------------------------
|<- 新しい IP ヘッダ内の変わりやすいフィールド -->|
| を除いた認証 |
-----------------------------------------------------------
IPv6 |新 IP | 拡張ヘッダ*| |もとの IP| 拡張ヘッダ*| | |
|ヘッダ*|もしあるなら| AH |ヘッダ* |もしあるなら|TCP|Data|
-----------------------------------------------------------
|<- 新しい IP ヘッダ内の変わりやすいフィールドを除いた -->|
| 認証 |
* = construction of outer IP hdr/extensions and modification
of inner IP hdr/extensions is discussed below.
* = outer IP ヘッダ/拡張(s) の構造と inner IP ヘッダ/拡張(s)
の変更は、下で論じられる。
3.2 Authentication Algorithms
3.2 認証アルゴリズム
The authentication algorithm employed for the ICV computation is
specified by the SA. For point-to-point communication, suitable
authentication algorithms include keyed Message Authentication Codes
(MACs) based on symmetric encryption algorithms (e.g., DES) or on
one-way hash functions (e.g., MD5 or SHA-1). For multicast
communication, one-way hash algorithms combined with asymmetric
signature algorithms are appropriate, though performance and space
considerations currently preclude use of such algorithms. The
mandatory-to-implement authentication algorithms are described in
Section 5 "Conformance Requirements". Other algorithms MAY be
supported.
ICV 計算のために使用される認証アルゴリズムは、(使用する) SA により明
細に述べられる。point-to-point 通信のために、適切な認証アルゴリズム
は、次の 2 つのどちらかの処理に基づかれる keyed Message
Authentication Codes (MACs) を含む。その処理とは、対称暗号アルゴリズ
ム (たとえば DES) か、一方向ハッシュ関数 (たとえば MD5 や SHA-1) の
ことを言う。multicast 通信のために、パフォーマンスと空間への考慮は非
対称署名アルゴリズムで組み合わされる一方向ハッシュアルゴリズムの使用
を現在不可能にするが、そのようなアルゴリズムは適切である。mandatory-
to-implement (実装に必須な) 認証アルゴリズムは、Section 5
"Conformance Requirements" で記述される。他のアルゴリズムは、サポー
トされるかもしれない (MAY)。
3.3 Outbound Packet Processing
3.3 外向けパケット処理
In transport mode, the sender inserts the AH header after the IP
header and before an upper layer protocol header, as described above.
In tunnel mode, the outer and inner IP header/extensions can be
inter-related in a variety of ways. The construction of the outer IP
header/extensions during the encapsulation process is described in
the Security Architecture document.
transport mode で、送信側は、上で記述されたとして IP ヘッダの後に、
かつ上位層プロトコルヘッダの前に AH ヘッダを挿入する。tunnel mode で
outer と inner IP ヘッダ/拡張(s) は、さまざまな方法で相互に関係され
ることができる。カプセル化プロセスの間、outer IP ヘッダ/拡張(s) の構
成は、Security Architecture 文書で記述される。
If there is more than one IPsec header/extension required, the order
of the application of the security headers MUST be defined by
security policy. For simplicity of processing, each IPsec header
SHOULD ignore the existence (i.e., not zero the contents or try to
predict the contents) of IPsec headers to be applied later. (While a
native IP or bump-in-the-stack implementation could predict the
contents of later IPsec headers that it applies itself, it won't be
possible for it to predict any IPsec headers added by a bump-in-the-
wire implementation between the host and the network.)
もし必要とされる 2 つ以上の IPsec ヘッダ/拡張があるなら、そのセキュ
リティヘッダ(s) の適用順序は、セキュリティポリシーにより定義されなけ
ればならない (MUST)。処理の容易さのために、それぞれの IPsec ヘッダは
後で適用されることになっている IPsec ヘッダ(s) の存在を無視すべきで
ある (SHOULD) (すなわち、その (後の IPsec ヘッダの) 内容に専念しない
か、内容予測を試みないことで、処理の容易さを実現)。(native IP 実装や
bump-in-the-stack 実装は、IPsec ヘッダそれ自身に適用する後の IPsec
ヘッダ(s) の内容を予測できるけれども、それらの実装は、ホストとネット
ワーク間の bump-in-the-wire 実装により追加される何らかの IPsec ヘッ
ダ(s) も予測することは可能ではないだろう。)
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.
AH は、IPsec 実装が次のことを決定する後でのみ outbound パケットに適
用される。それは、パケットが AH 処理を必要とする SA で関連されること
を決定する時である。もしあるなら、どんな IPsec 処理が outbound
traffic に適用されるかの決定処理は、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 for this SA and inserts the
new value into the Sequence Number Field. Thus the first packet sent
using a given SA will have a Sequence Number of 1.
SA が確立された時、送信側のカウンタは 0 に初期化される。送信側は、こ
の SA についての Sequence Number を増やし、新しい値を Sequence
Number Field に挿入する。したがって、与えられた SA を使用して送信さ
れる最初のパケットは、1 の Sequence Number を持つ。
If anti-replay is enabled (the default), the sender checks to ensure
that the counter has not cycled before inserting the new value in the
Sequence Number field. In other words, the sender MUST NOT send a
packet on an SA if doing so would cause the Sequence Number to cycle.
An attempt to transmit a packet that would result in Sequence Number
overflow is an auditable event. (Note that this approach to Sequence
Number management does not require use of modular arithmetic.)
もし anti-replay が可能であるなら (default)、送信側は次のこと保証す
るためにチェックする。それは、Sequence Number フィールド内に新しい値
を挿入する前に、カウンタが巡回していないことを保証することである。い
いかえれば、もしそうすることが Sequence Number に巡回させるなら、送
信側はパケットを決して送信してはならない (MUST NOT)。Sequence Number
overflow となるパケットを転送する試みは、audit event (監査イベント)
である。(Sequence Number 管理へのこの方法は、モジュール算術 (?) の使
用を必要としないことに注意しなさい。)
The sender assumes anti-replay is enabled as a default, unless
otherwise notified by the receiver (see 3.4.3). Thus, if the counter
has cycled, the sender will set up a new SA and key (unless the SA
was configured with manual key management).
送信側は、anti-replay がデフォルトで可能であると想定する。もっともこ
れは、他の方法が受信側により通知されなければの場合である (3.4.3 を参
照しなさい)。したがって、もしカウンタが巡回するなら、送信側は新しい
SA と鍵をセットアップするだろう (もっとも、その SA が手動鍵管理で設
定されなければの場合である)。
If anti-replay is disabled, the sender does not need to monitor or
reset the counter, e.g., in the case of manual key management (see
Section 5.) However, the sender still increments the counter and when
it reaches the maximum value, the counter rolls over back to zero.
もし anti-replay が可能でなければ、送信側はカウンタを monitor したり
reset する必要はない。たとえば、これは手動鍵管理のケースである
(Section 5 を参照しなさい)。しかしながら、送信側はカウンタをそれでも
増加する。そしてカウンタが最大値に達する時、カウンタは zero へと元に
戻る。
3.3.3 Integrity Check Value Calculation
3.3.3 完全性チェック値計算
The AH ICV is computed over:
AH ICV は、次のデータ上で計算される:
o IP header fields that are either immutable in transit or
that are predictable in value upon arrival at the endpoint
for the AH SA
転送中に不変であるか、その AH SA の endpoint に到着の上で
値の予測できるどちらかでの IP ヘッダフィールド
o the AH header (Next Header, Payload Len, Reserved, SPI,
Sequence Number, and the Authentication Data (which is set
to zero for this computation), and explicit padding bytes
(if any))
AH ヘッダ (Next Header, Payload Len, Reserved, SPI,
Sequence Number と Authentication Data (この計算のために
zero にセットされる) と、もしあるなら明示的な padding
bytes)
o the upper level protocol data, which is assumed to be
immutable in transit
転送中に不変であると想定される、上位層プロトコルデータ
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 Authentication Data field is also set to zero in
preparation for this computation. Note that by replacing each
field's value with zero, rather than omitting the field, alignment is
preserved for the ICV calculation. Also, the zero-fill approach
ensures that the length of the fields that are so handled cannot be
changed during transit, even though their contents are not explicitly
covered by the ICV.
もしフィールドが転送の間に変更されるかもしれないなら、そのフィールド
の値は ICV 計算目的のため zero にセットされる。もしフィールドは変わ
りやすいが (IPsec) 受信側でその値が予測できるなら、それからその値は
ICV 計算目的のために、そのフィールドへと挿入される。Authentication
Data フィールドも、この計算のための準備で zero にセットされる。それ
ぞれのフィールド値を zero で置き換えることにより、フィールドを除外す
るよりむしろ、整列した配置は ICV 計算のため保護されることに注意しな
さい。その上 zero で埋める方法は、次のことを保証する。それは、たとえ
それらフィールドの内容が ICV により明示的に扱われなくても、zero とし
て扱われるフィールド範囲は転送の間に変更されることができないことを保
証することである。
As a new extension header or IPv4 option is created, it will be
defined in its own RFC and SHOULD include (in the Security
Considerations section) directions for how it should be handled when
calculating the AH ICV. If the IP (v4 or v6) implementation
encounters an extension header that it does not recognize, it will
discard the packet and send an ICMP message. IPsec will never see
the packet. If the IPsec implementation encounters an IPv4 option
that it does not recognize, it should zero the whole option, using
the second byte of the option as the length. IPv6 options (in
Destination extension headers or Hop by Hop extension header) contain
a flag indicating mutability, which determines appropriate processing
for such options.
新しい拡張ヘッダや IPv4 オプションが作られる時、そのことは、それ自身
の RFC で定義されるだろうし、AH ICV を計算する時どのように扱われるべ
きかに関する指示を (Security Considerations section で) 含むべきであ
る (SHOULD)。もし IP (v4 や v6) 実装が識別できない拡張ヘッダに直面す
るなら、実装はパケットを廃棄し、ICMP メッセージを送信する。IPsec は
決してパケットを理解しない。もし IPsec 実装が認識できない IPv4 オプ
ションに直面するなら、実装は、その長さであるオプションの 2 番目の
byte を使用して全体のオプションを zero にすべきである。(Destination
拡張ヘッダ(s) や Hop by Hop 拡張ヘッダの) IPv6 オプションは、変わり
やすさを指し示すフラグを含む。それは、そのようなオプションのための適
切な処理を決定する。
訳注) 認識できない IPv4 オプションの説明で 2 番目の byte を使
用すると書いてあるが、これは次の理由からである。IP オプ
ションの構成は
|CODE (1 byte)|LENGTH (1 byte)|POINTER (1 byte)|...
となっている。よって、あるオプションの長さは 2 番目の
LENGTH を見ることにより分かる。そこで、すべてのオプショ
ンの LENGTH を見て、オプションフィールドを 0 にしていけ
ば、すべてのオプションフィールドは 0 になるということで
ある。
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)
バージョン
インターネットヘッダ長
全長
識別子
プロトコル (これは、AH についての値であるべきである。)
始点アドレス
終点アドレス (loose や strict 始点経路制御なしに)
Mutable but predictable
変わりやすいが予測可能
Destination Address (with loose or strict source routing)
終点アドレス (loose や strict 始点経路制御あり)
Mutable (zeroed prior to ICV calculation)
変わりやすい (ICV 計算より前に zero とされる)
Type of Service (TOS)
Flags
Fragment Offset
Time to Live (TTL)
Header Checksum
タイプオブサービス (TOS)
フラグ
フラグメントオフセット
生存時間 (TTL)
ヘッダチェックサム
TOS -- This field is excluded because some routers are known to
change the value of this field, even though the IP
specification does not consider TOS to be a mutable header
field.
このフィールドは除外される。なぜならば、たとえ IP 仕様書が
TOS を変わりやすいヘッダフィールドとみなしていなくても、あ
るルータがこのフィールド値を変更すると知られているからであ
る。
Flags -- This field is excluded since an intermediate router might
set the DF bit, even if the source did not select it.
このフィールドは除外される。これは、たとえ始点が DF bit 設
定を選択しなくても、中間ルータが DF bit をセットするかもし
れないからである。
Fragment Offset -- Since AH is applied only to non-fragmented IP
packets, the Offset Field must always be zero, and thus it
is excluded (even though it is predictable).
AH は分割されていない IP パケットのみに適用されるので、
Offset Field はいつも zero でなければならない。したがって
このフィールドは除外される (たとえ予測可能だとしても)。
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.
これは、ルータによる処理の通常方針として、経路内で変更され
る。したがって、受信側でのその値は、送信側により予測可能で
はない。
Header Checksum -- This will change if any of these other fields
changes, and thus its value upon reception cannot be
predicted by the sender.
もしこれら他のフィールドのどれかが変わるなら、これは変更す
る。したがって、受信でのその値は、送信側により予測されるこ
とができない。
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.
(IPv6 と違い) IPv4 について、転送中に変わりやすいとオプションにタグ
する (札をつける) メカニズムはない。したがって、IPv4 オプションは
Appendix A で明示的にリストされる。そして、不変、変わりやすいが予測
可能、または変わりやすいと分類される。IPv4 について、全体のオプショ
ンは 1 つのものとして見られる; それで、たとえほとんどのオプション内
の type と length フィールドが転送中に不変であるとしても、もしあるオ
プションが変わりやすいと分類されるなら、全体のオプションは ICV 計算
目的のために zero にされる。
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 (This should be the value for AH.)
Source Address
Destination Address (without Routing Extension Header)
バージョン
ペイロード長
次ヘッダ (これは、AH についての値であるべきである。)
始点アドレス
終点アドレス (Routing Extension Header なしに)
Mutable but predictable
変わりやすいが予測可能
Destination Address (with Routing Extension Header)
終点アドレス (Routing Extension Header あり)
Mutable (zeroed prior to ICV calculation)
変わりやすい (ICV 計算より前に zero とされる)
Class
Flow Label
Hop Limit
クラス
フローラベル
ホップ制限
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
Option Type and Opt Data Len are included in the ICV calculation.
All options for which the bit indicates immutability are included in
the ICV calculation. See the IPv6 specification [DH95] for more
information.
Hop-by-Hop と Destination Extension Headers 内の IPv6 オプションは、
オプションが転送の間に (予測不可能で) 変更するかどうかを指し示す bit
を含む。内容が経路の中で変更されるかもしれない何らかのオプションにつ
いて、ICV を計算または確かめる時、全体の "Option Data" フィールドは
zero の値を持つ octets として扱われなければならない。Option Type と
Opt Data Len は、ICV 計算に含まれる。オプション内のある bit が不変で
あることを指し示している、そのすべてのオプションは、ICV 計算に含まれ
る。さらなる詳細について、IPv6 仕様書 [DH95] を参照しなさい。
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 拡張ヘッダ(s) は、Appendix A で明示的にリ
ストされる。そして不変、変わりやすいが予測可能、または変わりやすいと
分類される。
3.3.3.2 Padding
3.3.3.2 パディング
3.3.3.2.1 Authentication Data Padding
3.3.3.2.1 認証データパディング
As mentioned in section 2.6, the Authentication Data field explicitly
includes padding to ensure that the AH header is a multiple of 32
bits (IPv4) or 64 bits (IPv6). If padding is required, its length is
determined by two factors:
section 2.6 で言及されたとして、Authentication Data フィールドは、明
示的にパディングに含まれる。これは、AH ヘッダが 32 bits (IPv4) か 64
bits (IPv6) の倍数であることを保証するためである。もしパディングが必
要とされるなら、その長さは次の 2 つの要素により決定される:
- the length of the ICV
- the IP protocol version (v4 or v6)
- ICV 長
- IP プロトコルバージョン (v4 または v6)
For example, if the output of the selected algorithm is 96-bits, no
padding is required for either IPv4 or for IPv6. However, if a
different length ICV is generated, due to use of a different
algorithm, then padding may be required depending on the length and
IP protocol version. The content of the padding field is arbitrarily
selected by the sender. (The padding is arbitrary, but need not be
random to achieve security.) These padding bytes are included in the
Authentication Data calculation, counted as part of the Payload
Length, and transmitted at the end of the Authentication Data field
to enable the receiver to perform the ICV calculation.
たとえば、もし選択されたアルゴリズムの出力が 96-bits であるなら、パ
ディングは、IPv4 や IPv6 のために必要とされない。しかしながら、もし
異なるアルゴリズムのために異なる長さの ICV が生成されるなら、それか
らパディングは長さと IP プロトコルバージョンに依存して必要とされるか
もしれない。パディングフィールドの内容は、送信側により任意に選択され
る。(パディングは任意であるが、セキュリティを達成するためにランダム
である必要はない。) これらのパディングバイトは、Authentication Data
計算に含まれる。このパディングは、Payload Length の一部分として数え
られ、そして受信側に ICV 計算を可能にさせるために Authentication
Data フィールド終わりの部分で転送される。
3.3.3.2.2 Implicit Packet Padding
3.3.3.2.2 暗黙のパケットパディング
For some authentication algorithms, the byte string over which the
ICV computation is performed must be a multiple of a blocksize
specified by the algorithm. If the IP packet length (including AH)
does not match the blocksize requirements for the algorithm, implicit
padding MUST be appended to the end of the packet, prior to ICV
computation. The padding octets MUST have a value of zero. The
blocksize (and hence the length of the padding) is specified by the
algorithm specification. This padding is not transmitted with the
packet. Note that MD5 and SHA-1 are viewed as having a 1-byte
blocksize because of their internal padding conventions.
ある認証アルゴリズムについて、ICV 計算がおこなわれる byte string は
そのアルゴリズムにより明細に述べられるブロックサイズの倍数でなければ
ならない。もし (AH を含む) IP パケット長がそのアルゴリズムのブロック
サイズ要求にマッチしないなら、暗黙のパケットパディングが、ICV 計算よ
り前に、パケットの終わりに追加されなければならない (MUST)。パディン
グ octets は、zero 値を持たなければならない (MUST)。ブロックサイズ
(と、したがってパディング長) は、アルゴリズム仕様書により明細に述べ
られる。このパディングは、パケットともに転送されない。MD5 と SHA-1
は、1-byte ブロックサイズを持つとして見られることに注意しなさい。こ
れは、内部パディング約束のためである。
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 IP packet to which AH
has been applied may itself be fragmented by routers en route, and
such fragments must be reassembled prior to AH processing at a
receiver. In tunnel mode, AH is applied to an IP packet, the payload
of which may be a fragmented IP packet. For example, a security
gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec
implementation (see the Security Architecture document for details)
may apply tunnel mode AH to such fragments.
もし必要とされるなら、IPsec 実装内の AH 処理の後、IP 断片が生じる。
したがって、transport mode AH は、全体の IP データグラムのみ (IP 断
片にではなく) に適用される。AH が適用される IP パケットは、それ自身
経路中のルータにより分割されるかもしれない。たとえば、security
gateway や "bump-in-the-stack" IPsec 実装は、そのような断片へと
tunnel モード AH を適用するかもしれない (ここで IPsec は、詳細に
Security Architecture 文書を参照すること)。
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.
もし 2 つ以上示す IPsec ヘッダ/拡張があるなら、それぞれのヘッダに対
する処理は、処理されるヘッダに続いて適用されるどんな IPsec ヘッダも
無視する (そのヘッダを zero にしなく、使用しない)。
3.4.1 Reassembly
3.4.1 再構成
If required, reassembly is performed prior to AH processing. If a
packet offered to AH for processing appears to be an IP fragment,
i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set,
the receiver MUST discard the packet; this is an auditable event. The
audit log entry for this event SHOULD include the SPI value,
date/time, Source Address, Destination Address, and (in IPv6) the
Flow ID.
もし必要とされるなら、再構成は AH 処理より前におこなわれる。もし処理
のため ESP に提供されるパケットが IP 断片であるように見えるなら、受
信側はパケットを廃棄しなければならない (MUST); これは監査イベントで
ある。IP 断片であるとは、すなわち OFFSET フィールドが zero でないか
MORE FRAGMENTS フラグが設定されているかである。このイベントのための
監査ログエントリは、(次の 5/6 つの情報) SPI 値、日付/時間、Source
Address、Destination Address と (IPv6 で) Flow ID を含むべきである
(SHOULD)。
NOTE: For packet reassembly, the current IPv4 spec does NOT require
either the zero'ing of the OFFSET field or the clearing of the MORE
FRAGMENTS flag. In order for a reassembled packet to be processed by
IPsec (as opposed to discarded as an apparent fragment), the IP code
must do these two things after it reassembles a packet.
注意: パケット再構成について、現在の IPv4 スペックは、OFFSET フィー
ルドを zero とするか MORE FRAGMENTS フラグを clear とすることどちら
かを必要としない (NOT)。(明白な断片として廃棄されることとは対照的に)
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, based on the
destination IP address, security protocol (AH), and the SPI. (This
process is described in more detail in the Security Architecture
document.) The SA indicates whether the Sequence Number field will
be checked, specifies the algorithm(s) employed for ICV computation,
and indicates the key(s) required to validate the ICV.
IP Authentication Header を含むパケット受信の上で、受信側は、適切な
(1 方向の) SA を決定する。この SA は、終点 IP アドレス、セキュリティ
プロトコル (AH) と SPI に基づいて決定する。(この処理は、Security
Architecture 文書でより詳細に記述される。) この SA は、Sequence
Number フィールドがチェックされるかどうかを指し示し、ICV 計算のため
に使用されるアルゴリズム(s) を明細に述べ、そして ICV を確かめるため
に必要とされる鍵(s) を指し示す。
If no valid Security Association exists for this session (e.g., the
receiver has no key), the receiver MUST discard the packet; this is
an auditable event. The audit log entry for this event SHOULD
include the SPI value, date/time, Source Address, Destination
Address, and (in IPv6) the Flow ID.
もし有効でない Security Association がこのセッションに存在する (たと
えば受信側が鍵を持っていない) なら、受信側は、パケットを廃棄しなけれ
ばならない (MUST); これは監査イベントである。このイベントのための監
査ログエントリは、(次の 4/5 つの情報) SPI 値、日付/時間、Source
Address、Destination Address と (IPv6 で) Flow ID を含むべきである
(SHOULD)。
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.
(Note that there are no provisions for managing transmitted Sequence
Number values among multiple senders directing traffic to a single SA
(irrespective of whether the destination address is unicast,
broadcast, or multicast). Thus the anti-replay service SHOULD NOT be
used in a multi-sender environment that employs a single SA.)
anti-replay の使用は SA ごとに受信側で可能にも不可能にもさせるけれど
も、すべての AH 実装は、anti-replay サービスをサポートしなければなら
ない (MUST)。((終点アドレスが unicast, broadcast や multicast である
かどうかに関係なく) 単一 SA へ traffic を向ける複数送信者間で、転送
される Sequence Number 値を管理するための用意はないことに注意しなさ
い。したがって、anti-replay サービスは、単一 SA を使用する複数送信者
環境で使用されるべきではない (SHOULD)。)
If the receiver does not enable anti-replay for an SA, no inbound
checks are performed on the Sequence Number. However, from the
perspective of the sender, the default is to assume that anti-replay
is enabled at the receiver. To avoid having the sender do
unnecessary sequence number monitoring and SA setup (see section
3.3.2), if an SA establishment protocol such as IKE is employed, the
receiver SHOULD notify the sender, during SA establishment, if the
receiver will not provide anti-replay protection.
もし受信側が SA について anti-replay を可能にしなければ、inbound の
チェックは Sequence Number におこなわれない。しかしながら送信側の観
点から、デフォルトは、anti-replay が受信側で可能だと想定される。送信
側が不必要な順序番号モニタリングと SA セットアップを避けるため
(section 3.3.2 を参照しなさい)、もし IKE のような SA 確立プロトコル
が使用されるなら、受信側は送信側に次のことを通知すべきである
(SHOULD)。それは SA 確立の間、受信側が anti-replay 保護を提供しない
かどうかを通知することである。
If the receiver has enabled the anti-replay service for this SA, the
receiver packet counter for the SA MUST be initialized to zero when
the SA is established. For each received packet, the receiver MUST
verify that the packet contains a Sequence Number that does not
duplicate the Sequence Number of any other packets received during
the life of this SA. This SHOULD be the first AH check applied to a
packet after it has been matched to an SA, to speed rejection of
duplicate packets.
もし受信側がこの SA について anti-replay サービスが可能であるなら、
その SA が確立された時、その SA についての受信パケットカウンタは
zero に初期化されなければならない (MUST)。それぞれの受信されたパケッ
トについて受信側は、次のことを確かめなければならない (MUST)。それは
(受信された) パケットが、この SA 生存の間に受信された、どんな他のパ
ケットの Sequence Number とも重複しない Sequence Number を含んでいる
ことを確かめることである。これは、パケットが SA にマッチした後で、重
複したパケットの廃棄を促進するために、パケットに適用される最初の AH
チェックであるべきである (SHOULD)。
Duplicates are rejected through the use of a sliding receive window.
(How the window is implemented is a local matter, but the following
text describes the functionality that the implementation must
exhibit.) A MINIMUM window size of 32 MUST be supported; but a
window size of 64 is preferred and SHOULD be employed as the default.
Another window size (larger than the MINIMUM) MAY be chosen by the
receiver. (The receiver does NOT notify the sender of the window
size.)
重複は、sliding recieve window の使用を通して廃棄される。(window が
どのように実装されるかは local 問題である。しかし次に述べる text は
実装が示されなければならない機能を記述する。) 32 の MINIMUM window
サイズは、サポートされなければならない; しかし 64 の window サイズは
好まれ、デフォルトとして使用されるべきである (SHOULD)。(MINIMUM より
も大きい) 他の window サイズは、受信側により選ばれるかもしれない
(MAY)。(受信側は送信側に window サイズを知らせない。)
The "right" edge of the window represents the highest, validated
Sequence Number value received on this SA. Packets that contain
Sequence Numbers lower than the "left" edge of the window are
rejected. Packets falling within the window are checked against a
list of received packets within the window. An efficient means for
performing this check, based on the use of a bit mask, is described
in the Security Architecture document.
window の "right" 端は、この SA で受信された最も大きくて有効な
Sequence Number 値を表す。window の "left" 端より小さい Sequence
Number を含むパケットは、廃棄される。window 内で落ちるパケットは、
window 内の受信されたパケットリストとチェックされる。bit mask の使用
に基づく、このチェックをおこなうための効率的な方法は、Security
Architecture 文書で記述される。
If the received packet falls within the window and is new, or if the
packet is to the right of the window, then the receiver proceeds to
ICV verification. If the ICV validation fails, the receiver MUST
discard the received IP datagram as invalid; this is an auditable
event. The audit log entry for this event SHOULD include the SPI
value, date/time, Source Address, Destination Address, the Sequence
Number, and (in IPv6) the Flow ID. The receive window is updated
only if the ICV verification succeeds.
もし受信されたパケットが window 内で落ちてそのパケットが新しいか、ま
たはもしパケットが window の右端となるなら、それから受信側は ICV 検
証を始める。もし ICV 検証が失敗するなら、受信側は、有効でないとして
受信された IP データグラムを廃棄しなければならない (MUST); これは監
査イベントである。このイベントのための監査ログエントリは、(次の 5/6
つの) SPI 値、日付/時間、Source Address、Destination Address、
Sequence Number と (IPv6 で) Flow ID を含むべきである (SHOULD)。受信
window は、ICV 検証が成功した時のみに更新される。
DISCUSSION:
審議:
Note that if the packet is either inside the window and new, or is
outside the window on the "right" side, the receiver MUST
authenticate the packet before updating the Sequence Number window
data.
もしパケットが window 内か新しいか、または "right" 端の window の
外側であるなら、受信側は、Sequence Number window データを更新する
前にパケットを認証しなければならない (MUST) ことに注意しなさい。
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 authentication algorithm, and verifies
that it is the same as the ICV included in the Authentication Data
field of the packet. Details of the computation are provided below.
受信側は、明細に述べられた認証アルゴリズムを使用して、パケットの適切
なフィールドについて ICV を計算する。そして、計算結果がそのパケット
の Authentication Data フィールド内に含まれた ICV と同じということを
確かめる。その計算の詳細は、下で提供される。
If the computed and received ICV's match, then the datagram is valid,
and it is accepted. If the test fails, then the receiver MUST
discard the received IP datagram as invalid; this is an auditable
event. The audit log entry SHOULD include the SPI value, date/time
received, Source Address, Destination Address, and (in IPv6) the Flow
ID.
もし計算された ICV と受信された ICV がマッチするのであれば、それなら
データグラムは有効であり受理される。もしテストが失敗するなら、それか
ら受信側は、有効でないとして受信された IP データグラムを廃棄しなけれ
ばならない (MUST); これは監査イベントである。監査ログエントリは、SPI
値、受信された日付/時間、Source Address、Destination Address と
(IPv6 で) Flow ID を含むべきである (SHOULD)。
DISCUSSION:
審議:
Begin by saving the ICV value and replacing it (but not any
Authentication Data padding) with zero. Zero all other fields
that may have been modified during transit. (See section 3.3.3.1
for a discussion of which fields are zeroed before performing the
ICV calculation.) Check the overall length of the packet, and if
it requires implicit padding based on the requirements of the
authentication algorithm, append zero-filled bytes to the end of
the packet as required. Perform the ICV computation and compare
the result with the saved value, using the comparison rules
defined by the algorithm specification. (For example, if a
digital signature and one-way hash are used for the ICV
computation, the matching process is more complex.)
ICV 値を保存し、その値 (しかし、どんな Authentication Data パディ
ングでなく) を zero と置き換えなさい。転送中に変更されるかもしれ
ない他のすべてのフィールドを zero にしなさい。(ICV 計算をおこなう
前に、どのフィールドが zero にされるかの審議について section
3.3.3.1 を参照しなさい。) パケット全長をチェックしなさい。そして
もし認証アルゴリズムの要求に基づいて暗黙のパディングを必要とする
なら、必要とされるとしてパケットの終わりに zero である bytes を追
加しなさい。アルゴリズム仕様書により定義された比較ルールを使用し
て、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 実装は監査もサポートしなければならなく (MUST)、system
administrator に AH の監査を可能にするか不可能にするかを許可しなけれ
ばならない (MUST)。たいていの部分について、監査の粒度は local 問題で
ある。いくつかの監査イベントは、この仕様書で確認される。そして、これ
らイベントのそれぞれについて、監査ログに含まれるべき (SHOULD) 情報の
最小セットは定義される。追加の情報は、これらイベントのそれぞれについ
て監査ログにも含まれるかもしれない (MAY)。そして、この仕様書で明示的
に引き出されない追加のイベントは、監査ログエントリという結果にもなる
かもしれない (MAY)。受信側は、監査イベント発見の応答に (送信したと)
称された送信側へと、何らかのメッセージをも転送する必要はない。これは
そのような行為により denial of service を引き起こす可能性があるため
である。
-----------------------------------------------------------------------
5. Conformance Requirements
5. 適合への要求
Implementations that claim conformance or compliance with this
specification MUST fully implement the AH syntax and processing
described here and MUST comply with all requirements of the Security
Architecture document. If the key used to compute an ICV is manually
distributed, correct provision of the anti-replay service would
require correct maintenance of the counter state at the sender, until
the key is replaced, and there likely would be no automated recovery
provision if counter overflow were imminent. Thus a compliant
implementation SHOULD NOT provide this service in conjunction with
SAs that are manually keyed. A compliant AH implementation MUST
support the following mandatory-to-implement algorithms:
この仕様書に適合、もしくは準拠を主張する実装は、ここで記述される AH
syntax と処理を完全に実装しなければならない (MUST)。そして、Security
Architecture 文書のすべての要求に従わなければならない (MUST)。もし
ICV 計算に使用される鍵が手動で配布されるなら、その鍵が置き換えられる
まで、anti-replay サービスの正しい規定は、送信側でのカウンタ状態の正
しい維持を要求するだろう。そしてもしカウンタの overflow が差し迫った
なら、自動化された回復規定は、おそらくないであろう。したがって準拠す
る実装は、手動で鍵が設定された SA(s) とともに、このサービスを提供す
べきでない (SHOULD NOT)。準拠する AH 実装は、次に述べる実装必須のア
ルゴリズムをサポートしなければならない (MUST):
- HMAC with MD5 [MG97a]
- HMAC with SHA-1 [MG97b]
-----------------------------------------------------------------------
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.
セキュリティは、このプロトコル設計の中心をなす。そしてこれらのセキュ
リティに関する考察は、仕様書全体に行き渡る。IPsec プロトコルを使用す
る追加のセキュリティに関連する側面は、Security Architecture 文書で記
述される。
-----------------------------------------------------------------------
7. Differences from RFC 1826
7. RFC 1826 との相違
This specification of AH differs from RFC 1826 [ATK95] in several
important respects, but the fundamental features of AH remain intact.
One goal of the revision of RFC 1826 was to provide a complete
framework for AH, with ancillary RFCs required only for algorithm
specification. For example, the anti-replay service is now an
integral, mandatory part of AH, not a feature of a transform defined
in another RFC. Carriage of a sequence number to support this
service is now required at all times. The default algorithms
required for interoperability have been changed to HMAC with MD5 or
SHA-1 (vs. keyed MD5), for security reasons. The list of IPv4 header
fields excluded from the ICV computation has been expanded to include
the OFFSET and FLAGS fields.
AH に関するこの仕様書は、いくつかの重要な点で RFC 1826 [ATK95] と異
なる。しかし AH の基礎となる特徴は、完全なままである。RFC 1826 修正
の 1 つの目的は、アルゴリズム仕様書のためだけに必要とされた従属する
RFC(s) とともに、AH のための完全な枠組を提供することであった。たとえ
ば、anti-replay サービスは、他の RFC で定義される変換の特徴でなく、
現在 AH の不可欠な必須部分である。このサービスをサポートするための順
序番号転送は、現在常に必要とされる。相互互換性のために必要とされるデ
フォルトアルゴリズムは、セキュリティ理由のために、HMAC with MD5 や
HMAC with SHA-1 に (vs. keyed MD5) 変更された。ICV 計算から除外され
た IPv4 ヘッダのリストは、OFFSET と FLAGS フィールドを含むように拡張
された。
Another motivation for revision was to provide additional detail and
clarification of subtle points. This specification provides
rationale for exclusion of selected IPv4 header fields from AH
coverage and provides examples on positioning of AH in both the IPv4
and v6 contexts. Auditing requirements have been clarified in this
version of the specification. Tunnel mode AH was mentioned only in
passing in RFC 1826, but now is a mandatory feature of AH.
Discussion of interactions with key management and with security
labels have been moved to the Security Architecture document.
修正のための他の動機づけは、追加の詳細と微妙な点の明瞭化を提供するこ
とであった。この仕様書は、AH 適用範囲から選ばれた IPv4 ヘッダフィー
ルドの除外について、理論的根拠を提供する。そしてこの仕様書は、IPv4
と v6 環境両方で AH の位置を定めている例を提供する。監査要求は、この
仕様書のこのバージョンで明らかにされた。tunnel mode AH は、RFC 1826
で、話の途中でのみ述べられた。しかし tunnel mode AH は、現在 AH の必
須特徴である。鍵管理での相互作用とセキュリティラベルでの相互作用の審
議は、Security Architecture 文書に移動された。
-----------------------------------------------------------------------
Acknowledgements
謝辞
For over 3 years, this document has evolved through multiple versions
and iterations. During this time, many people have contributed
significant ideas and energy to the process and the documents
themselves. The authors would like to thank Karen Seo for providing
extensive help in the review, editing, background research, and
coordination for this version of the specification. The authors
would also like to thank the members of the IPsec and IPng working
groups, with special mention of the efforts of (in alphabetic order):
Steve Bellovin, Steve Deering, Francis Dupont, Phil Karn, Frank
Kastenholz, Perry Metzger, David Mihelcic, Hilarie Orman, Norman
Shulman, William Simpson, and Nina Yuan.
3 年以上の間、この文書は、複数のバージョンと繰り返しを通して発展され
た。この期間、多くの人々は、プロセスとこの文書自身に重要なアイデアと
エネルギーを寄与した。著者たちは、仕様書のこのバージョンについて、批
評、編集、背景調査と調整に、広範囲に渡る援助を提供した Karen Seo に
感謝したい。著者たちは、(アルファベット順に) Steve Bellovin, Steve
Deering, Francis Dupont, Phil Karn, Frank Kastenholz, Perry Metzger,
David Mihelcic, Hilarie Orman, Norman Shulman, William Simpson と
Nina Yuan の努力に関する特別の記載とともに、IPsec と IPng working
groups メンバーにも感謝したい。
-----------------------------------------------------------------------
Appendix A -- Mutability of IP Options/Extension Headers
付録 A -- IP オプション/拡張ヘッダの変わりやすさ
A1. IPv4 Options
A1. IPv4 オプション
This table shows how the IPv4 options are classified with regard to
"mutability". Where two references are provided, the second one
supercedes the first. This table is based in part on information
provided in RFC1700, "ASSIGNED NUMBERS", (October 1994).
この表は、IPv4 オプション(s) が "mutability (変わりやすさ)" に関しど
のように分類されるかを示す。2 つの参考文献が提供される場合では、2 つ
めの参考文献は、最初のに取って代わる。この表は、RFC 1700 "ASSIGNED
NUMBERS", (October 1994) で提供される情報の一部分に基づく。
Opt.
Copy Class # Name Reference
---- ----- --- ------------------------ ---------
IMMUTABLE -- included in ICV calculation
0 0 0 End of Options List [RFC791]
0 0 1 No Operation [RFC791]
1 0 2 Security [RFC1108(historic but in use)]
1 0 5 Extended Security [RFC1108(historic but in use)]
1 0 6 Commercial Security [expired I-D, now US MIL STD]
1 0 20 Router Alert [RFC2113]
1 0 21 Sender Directed Multi- [RFC1770]
Destination Delivery
MUTABLE -- zeroed
1 0 3 Loose Source Route [RFC791]
0 2 4 Time Stamp [RFC791]
0 0 7 Record Route [RFC791]
1 0 9 Strict Source Route [RFC791]
0 2 18 Traceroute [RFC1393]
EXPERIMENTAL, SUPERCEDED -- zeroed
1 0 8 Stream ID [RFC791, RFC1122 (Host Req)]
0 0 11 MTU Probe [RFC1063, RFC1191 (PMTU)]
0 0 12 MTU Reply [RFC1063, RFC1191 (PMTU)]
1 0 17 Extended Internet Proto [RFC1385, RFC1883 (IPv6)]
0 0 10 Experimental Measurement [ZSu]
1 2 13 Experimental Flow Control [Finn]
1 0 14 Experimental Access Ctl [Estrin]
0 0 15 ??? [VerSteeg]
1 0 16 IMI Traffic Descriptor [Lee]
1 0 19 Address Extension [Ullmann IPv7]
NOTE: Use of the Router Alert option is potentially incompatible with
use of IPsec. Although the option is immutable, its use implies that
each router along a packet's path will "process" the packet and
consequently might change the packet. This would happen on a hop by
hop basis as the packet goes from router to router. Prior to being
processed by the application to which the option contents are
directed, e.g., RSVP/IGMP, the packet should encounter AH processing.
注意: Router Alert オプションの使用は、IPsec の使用と潜在的に両立し
ない。このオプションは不変であるけれども、その使用は、次に述べること
を案に意味する。それは、パケットの経路に沿うそれぞれのルータはパケッ
トを "process (処理)" し、パケットを必然的に変更するかもしれないこと
である。パケットがルータからルータへと行くので、これは hop by hop 形
式で生じるだろう。(パケットの) オプション内容は、アプリケーション、
たとえば RSVP/IGMP へと割り当てられていて、 (パケットが) アプリケー
ションにより処理されるよりも前に、そのパケットは AH 処理をおこなわせ
るべきである。
However, AH processing would require that each router along the path
is a member of a multicast-SA defined by the SPI. This might pose
problems for packets that are not strictly source routed, and it
requires multicast support techniques not currently available.
しかしながら、AH 処理は、次のことを要求する。その要求とは、経路に沿
うそれぞれのルータは、SPI により定義された multicast-SA のメンバーで
あることである。これは、厳密な始点経路でないパケット(s) に問題(s) を
引き起こすかもしれない。そしてそれは、現在利用できない技術をサポート
する multicast を要求する。
NOTE: Addition or removal of any security labels (BSO, ESO, CIPSO) by
systems along a packet's path conflicts with the classification of
these IP Options as immutable and is incompatible with the use of
IPsec.
注意: パケットの経路に沿うシステムにより、何らかのセキュリティラベル
(BSO, ESO, CIPSO) の追加や除去は、不変であるとして、これら IP
Options の分類と矛盾する。そしてこれは、IPsec の使用と両立しない。
NOTE: End of Options List options SHOULD be repeated as necessary to
ensure that the IP header ends on a 4 byte boundary in order to
ensure that there are no unspecified bytes which could be used for a
covert channel.
注意: End of Options List オプションは、次のことを保証するために必要
であるとして繰り返されるべきである (SHOULD)。それは、隠されたチャネ
ルのために使用されるような明細に述べない bytes がないことを保証する
ため、IP ヘッダが 4 byte 境界で終わることを保証することである。
A2. IPv6 Extension Headers
A2. IPv6 拡張ヘッダ
This table shows how the IPv6 Extension Headers are classified with
regard to "mutability".
この表は、IPv6 Extension Headers が "mutability" に関し、どのように
分類されるかを示す。
Option/Extension Name Reference
----------------------------------- ---------
MUTABLE BUT PREDICTABLE -- included in ICV calculation
Routing (Type 0) [RFC1883]
BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING TRANSIT)
Hop by Hop options [RFC1883]
Destination options [RFC1883]
NOT APPLICABLE
Fragmentation [RFC1883]
Options -- IPv6 options in the Hop-by-Hop and Destination
Extension Headers contain a bit that indicates whether the
option might change (unpredictably) during transit. For
any option for which contents may change en-route, the
entire "Option Data" field must be treated as zero-valued
octets when computing or verifying the ICV. The Option
Type and Opt Data Len are included in the ICV calculation.
All options for which the bit indicates immutability are
included in the ICV calculation. See the IPv6
specification [DH95] for more information.
Hop-by-Hop 内の IPv6 オプション(s) と Destination
Extension Headers は、オプションが転送の間に (予測できず)
変更するかどうかを指し示す 1 つの bit を含む。(オプション
の) 内容が経路中に変更されるかもしれないどんなオプションに
ついても、ICV を計算し確認する時、(オプションの) 全体の
"Option Data" フィールドは、zero 値 octets として扱われな
ければならない。Option Type と Opt Data Len は、ICV 計算に
含まれる。不変であると bit が指し示すような、すべてのオプ
ション(s) は、ICV 計算に含まれる。さらなる情報について、
IPv6 仕様書 [DH95] を参照しなさい。
Routing (Type 0) -- The IPv6 Routing Header "Type 0" will
rearrange the address fields within the packet during
transit from source to destination. However, the contents
of the packet as it will appear at the receiver are known
to the sender and to all intermediate hops. Hence, the
IPv6 Routing Header "Type 0" is included in the
Authentication Data calculation as mutable but predictable.
The sender must order the field so that it appears as it
will at the receiver, prior to performing the ICV
computation.
IPv6 Routing Header "Type 0" は、始点から終点への転送の間
パケット内のアドレスフィールドを設定し直すだろう。しかしな
がら、受信側でその内容は現れるだろうとして、パケットの内容
は、送信側とすべての中間 hops に知られている。したがって、
IPv6 Routing Header "Type 0" は、変わりやすいが予測可能で
あるとして、Authentication Data 計算に含まれる。受信側で
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.
分割は outbound IPsec 処理 (section 3.3) の後に生じ、再構
成は inbound IPsec 処理 (section 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 実装が再構成をおこなう時、IP 実装は、いつもの
所に Fragmentation Header を残すことができることに注意しな
さい。もしこれが生じるなら、それから AH がパケットを受け取
る時、ICV 処理をする前に、AH はこのヘッダを "remove (取り
除く)" しなければならない (MUST)。そして前のヘッダの "Next
Header" フィールドを Fragmentation Extension Header の
"Next Header" フィールドであるように変更しなければならない
(MUST)。
Note that on the send side, the IP implementation could
give the IPsec code a packet with a Fragmentation Extension
Header with Offset of 0 (first fragment) and a More
Fragments Flag of 0 (last fragment). If this happens, then
before doing ICV processing, AH MUST first "remove" (or
skip over) this header and change the previous header's
"Next Header" field to be the "Next Header" field in the
Fragmentation Extension Header.
送信側で、IP 実装は、IPsec code に、0 (最初の断片) の
Offset と 0 (最後の断片) の More Fragments Flag を持つ
Fragmentation Extension Header があるパケットを渡すことが
できることに注意しなさい。もしこれが生じるなら、それから
ICV 処理をする前に、AH はこのヘッダを "remove (取り除く)"
しなければならない (MUST)。そして前のヘッダの "Next
Header" フィールドを Fragmentation Extension Header の
"Next Header" フィールドであるように変更しなければならない
(MUST)。
-----------------------------------------------------------------------
References
参考文献
[ATK95] Atkinson, R., "The IP Authentication Header", RFC 1826,
August 1995.
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
[DH95] Deering, S., and B. Hinden, "Internet Protocol version 6
(IPv6) Specification", RFC 1883, December 1995.
[HC98] Harkins, D., and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[KA97a] Kent, S., and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[KA97b] Kent, S., and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[MG97a] Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within
ESP and AH", RFC 2403, November 1998.
[MG97b] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
[STD-2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994. See also:
http://www.iana.org/numbers.html
-----------------------------------------------------------------------
Disclaimer
否認声明書
The views and specification here are those of the authors and are not
necessarily those of their employers. The authors and their
employers specifically disclaim responsibility for any problems
arising from correct or incorrect implementation or use of this
specification.
ここでの意見と仕様は著者たちのものであり、必ずしも著者たちの雇い主の
ものではない。著者たちとその雇い主は、正確または不正確な実装から生じ
る、あるいは、この仕様の利用から生じるどんな問題についても責任を明確
に否認する。
-----------------------------------------------------------------------
Author Information
著者の情報
Stephen Kent
BBN Corporation
70 Fawcett Street
Cambridge, MA 02140
USA
Phone: +1 (617) 873-3988
EMail: kent@bbn.com
Randall Atkinson
@Home Network
425 Broadway,
Redwood City, CA 94063
USA
Phone: +1 (415) 569-5000
EMail: rja@corp.home.net
-----------------------------------------------------------------------
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
一覧
スポンサーリンク
