Network Working Group                                            S. Kent
Request for Comments: 4302                              BBN Technologies
Obsoletes: 2402                                            December 2005
Category: Standards Track
                        IP Authentication Header

Status of This Memo


This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD 1)の最新版を参照してください。このメモの配布は無制限です。

Copyright Notice


Copyright (C) The Internet Society (2005).




This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document obsoletes RFC 2402 (November 1998).

この文書では、IPv4とIPv6での認証サービスを提供するように設計されたIP認証ヘッダ(AH)の更新バージョンを記述する。この文書は、RFC 2402(1998年11月)を廃止します。

Table of Contents


   1. Introduction ....................................................3
   2. Authentication Header Format ....................................4
      2.1. Next Header ................................................5
      2.2. Payload Length .............................................5
      2.3. Reserved ...................................................6
      2.4. Security Parameters Index (SPI) ............................6
      2.5. Sequence Number ............................................8
           2.5.1. Extended (64-bit) Sequence Number ...................8
      2.6. Integrity Check Value (ICV) ................................9
   3. Authentication Header Processing ................................9
      3.1. Authentication Header Location .............................9
           3.1.1. Transport Mode ......................................9
           3.1.2. Tunnel Mode ........................................11
      3.2. Integrity Algorithms ......................................11
      3.3. Outbound Packet Processing ................................11
           3.3.1. Security Association Lookup ........................12
           3.3.2. Sequence Number Generation .........................12
           3.3.3. Integrity Check Value Calculation ..................13
         Handling Mutable Fields ...................13
         Padding and Extended Sequence Numbers .....16
           3.3.4. Fragmentation ......................................17
      3.4. Inbound Packet Processing .................................18
           3.4.1. Reassembly .........................................18
           3.4.2. Security Association Lookup ........................18
           3.4.3. Sequence Number Verification .......................19
           3.4.4. Integrity Check Value Verification .................20
   4. Auditing .......................................................21
   5. Conformance Requirements .......................................21
   6. Security Considerations ........................................22
   7. Differences from RFC 2402 ......................................22
   8. Acknowledgements ...............................................22
   9. References .....................................................22
      9.1. Normative References ......................................22
      9.2. Informative References ....................................23
   Appendix A: Mutability of IP Options/Extension Headers ............25
      A1. IPv4 Options ...............................................25
      A2. IPv6 Extension Headers .....................................26
   Appendix B: Extended (64-bit) Sequence Numbers ....................28
      B1. Overview ...................................................28
      B2. Anti-Replay Window .........................................28
          B2.1. Managing and Using the Anti-Replay Window ............29
          B2.2. Determining the Higher-Order Bits (Seqh) of the
                Sequence Number ......................................30
          B2.3. Pseudo-Code Example ..................................31
      B3. Handling Loss of Synchronization due to Significant
          Packet Loss ................................................32
          B3.1. Triggering Re-synchronization ........................33
          B3.2. Re-synchronization Process ...........................33
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.


The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97].

彼らは、この文書に表示されるRFC 2119 [Bra97]で説明したように解釈される際のキーワードは、REQUIREDは、、、、、MAY、推奨、およびオプションのすべきでないないものとものとしてはなりませんしなければなりません。

The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just "integrity") and to provide protection against replays. This latter, optional service may be selected, by the receiver, when a Security Association (SA) is established. (The protocol default requires the sender to increment the sequence number used for anti-replay, but the service is effective only if the receiver checks the sequence number.) However, to make use of the Extended Sequence Number feature in an interoperable fashion, AH does impose a requirement on SA management protocols to be able to negotiate this new feature (see Section 2.5.1 below).

IP認証ヘッダ(AH)は、(以下、単に「整合性」と呼ばれる)IPデータグラムのためのコネクションレス完全性とデータ発信元認証を提供し、リプレイに対する保護を提供するために使用されます。セキュリティアソシエーション(SA)が確立されるとき、この後者のオプションサービスは、受信機によって、選択することができます。 (プロトコルデフォルトは、アンチリプレイのために使用されるシーケンス番号をインクリメントする送信者を必要とするが、サービスは、受信機がシーケンス番号をチェックした場合にのみ有効である。)が、相互運用可能な方法で拡張シーケンス番号の機能を利用するために、AH SA管理プロトコル上の要件を課すんこの新機能を(下記のセクション2.5.1を参照)を交渉することができるようにします。

AH provides authentication for as much of the IP header as possible, as well as for next level protocol data. However, some IP header fields may change in transit and the value of these fields, when the packet arrives at the receiver, may not be predictable by the sender. The values of such fields cannot be protected by AH. Thus, the protection provided to the IP header by AH is piecemeal. (See Appendix A.)

AHは、できるだけIPヘッダの多く、並びに次のレベルのプロトコルデータについての認証を提供します。しかし、いくつかのIPヘッダフィールドは、パケットが受信機に到達したとき、送信者が予測できない場合があり、トランジット及びこれらのフィールドの値に変更してもよいです。このようなフィールドの値は、AHで保護することはできません。このように、AHによってIPヘッダに設けられた保護は、断片的です。 (付録Aを参照してください)

AH may be applied alone, in combination with the IP Encapsulating Security Payload (ESP) [Ken-ESP], or in a nested fashion (see Security Architecture document [Ken-Arch]). Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. ESP may be used to provide the same anti-replay and similar integrity services, and it also provides a confidentiality (encryption) service. The primary difference between the integrity provided by ESP and AH is the extent of the coverage. Specifically, ESP does not protect any IP header fields unless those fields are encapsulated by ESP (e.g., via use of tunnel mode). For more details on how to use AH and ESP in various network environments, see the Security Architecture document [Ken-Arch].

AH IPカプセル化セキュリティペイロード(ESP)[ケン-ESP]、またはネストされた形で(セキュリティアーキテクチャ文書[ケン-アーチ]を参照)と組み合わせて、一人でも適用することができます。セキュリティサービスは、セキュリティゲートウェイを通信する対の間、またはセキュリティゲートウェイとホストとの間で、ホストと通信する一対の間に設けることができます。 ESPは同じアンチリプレイと同様の整合性サービスを提供するために使用することができる、そしてそれはまた、機密性(暗号化)サービスを提供しています。 ESPとAHが提供する完全性との間の主な違いは、カバレッジの範囲です。これらのフィールドは、(トンネルモードの使用を介して、例えば)ESPによってカプセル化されていない限り、具体的には、ESPは、任意のIPヘッダフィールドを保護しません。さまざまなネットワーク環境でAHとESPを使用する方法の詳細については、セキュリティアーキテクチャ文書[ケン-アーチ]を参照してください。

Section 7 provides a brief review of the differences between this document and RFC 2402 [RFC2402].

第7節は、この文書およびRFC 2402 [RFC2402]との違いの簡単なレビューを提供します。

2. Authentication Header Format

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.


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   | Next Header   |  Payload Len  |          RESERVED             |
   |                 Security Parameters Index (SPI)               |
   |                    Sequence Number Field                      |
   |                                                               |
   +                Integrity Check Value-ICV (variable)           |
   |                                                               |

Figure 1. AH Format

図1. AHフォーマット

   The following table refers to the fields that comprise AH,
   (illustrated in Figure 1), plus other fields included in the
   integrity computation, and illustrates which fields are covered by
   the ICV and what is transmitted.
                                                      What    What
                                     # of     Requ'd  Integ    is
                                     bytes     [1]    Covers  Xmtd
                                     ------   ------  ------  ------
          IP Header                  variable    M     [2]    plain
          Next Header                   1        M      Y     plain
          Payload Len                   1        M      Y     plain
          RESERVED                      2        M      Y     plain
          SPI                           4        M      Y     plain
          Seq# (low-order 32 bits)      4        M      Y     plain
          ICV                        variable    M      Y[3]  plain
          IP datagram [4]            variable    M      Y     plain
          Seq# (high-order 32 bits)     4      if ESN   Y     not xmtd
          ICV Padding                variable  if need  Y     not xmtd
       [1] - M = mandatory
       [2] - See Section 3.3.3, "Integrity Check Value Calculation", for
             details of which IP header fields are covered.
       [3] - Zeroed before ICV calculation (resulting ICV placed here
             after calculation)
       [4] - If tunnel mode -> IP datagram
             If transport mode -> next header and data

The following subsections define the fields that comprise the AH format. All the fields described here are mandatory; i.e., they are always present in the AH format and are included in the Integrity Check Value (ICV) computation (see Sections 2.6 and 3.3.3).


Note: All of the cryptographic algorithms used in IPsec expect their input in canonical network byte order (see Appendix of RFC 791 [RFC791]) and generate their output in canonical network byte order. IP packets are also transmitted in network byte order.

注:IPsecのに使用される暗号化アルゴリズムのすべてが正規のネットワークバイト順での入力は、(RFC 791 [RFC791]の付録を参照)、正規ネットワークバイト順での出力を生成する期待します。 IPパケットは、ネットワークバイトオーダーで送信されています。

AH does not contain a version number, therefore if there are concerns about backward compatibility, they MUST be addressed by using a signaling mechanism between the two IPsec peers to ensure compatible versions of AH, e.g., IKE [IKEv2] or an out-of-band configuration mechanism.

AHは、下位互換性の懸念がある場合、したがって、それらは例えば、IKE [IKEv2の]、またはアウトオブ、AHの互換バージョンを確実にするために、2つのIPSecピア間のシグナリングメカニズムを使用して対処しなければならない、バージョン番号が含まれていませんバンド構成メカニズム。

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.

次ヘッダは、認証ヘッダの後の次のペイロードのタイプを識別する8ビットのフィールドです。このフィールドの値は、Internet Assigned Numbers Authority(IANA)のWebページ上で定義された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, "ICV Padding".

この8ビットのフィールドは、32ビット・ワード(4バイト単位)、マイナス「2」にAHの長さを指定します。完全性アルゴリズムは、96ビットの認証値をもたらす場合したがって、例えば、この長さフィールドが「4」(3 32ビットワード固定フィールドプラスICV 3の32ビットワード、マイナス2)となります。 IPv6の場合、ヘッダの長さの合計は、8オクテット単位の倍数でなければなりません。 (IPv6の[DH98]は拡張ヘッダとしてAHを特徴付けるが、その長さは、32ビットワード内の他のIPv6拡張ヘッダで使用されていない64ビットワードに測定されることに注意してください。)セクション2.6を参照、「完全性値(ICV)を確認します」、このフィールドのパディングに関するコメント、およびセクション3.のために、 『ICVパディング』。

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ビットのフィールドは、将来の使用のために予約されています。これは、送信者が「ゼロ」に設定しなければならなくて、それが受信者によって無視されるべきです。 (値は、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のために、SPIは、SAを指定するために単独で使用することができ、またはそれは(この場合AH)にIPsecプロトコルタイプと組み合わせて使用​​することができます。ユニキャストSAのSPI値が受信機によって生成されるので、値が十分であるかどうかをそれ自体でSAを識別するか、IPsecプロトコル値と一緒に使用する必要があるかどうかローカルの問題であることができます。 SPIフィールドは必須であり、そしてSAが上記ユニキャストするインバウンドトラフィックをマッピングするこのメカニズムは、すべてのAH実装によってサポートされなければなりません。

If an IPsec implementation supports multicast, then it MUST support multicast SAs using the algorithm below for mapping inbound IPsec datagrams to SAs. Implementations that support only unicast traffic need not implement this de-multiplexing algorithm.


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.


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:


           1. Search the SAD for a match on {SPI, destination
              address, source address}.  If an SAD entry
              matches, then process the inbound AH packet with that
              matching SAD entry.  Otherwise, proceed to step 2.

2. Search the SAD for a match on {SPI, destination address}. If an SAD entry matches, then process the inbound AH packet with that matching SAD entry. Otherwise, proceed to step 3.

2. {SPI、宛先アドレス}に一致するSADを検索します。 SADエントリが一致した場合、その一致するSADエントリでインバウンドAHパケットを処理します。それ以外の場合は、ステップ3に進みます。

3. Search the SAD for a match on only {SPI} if the receiver has chosen to maintain a single SPI space for AH and ESP, or on {SPI, protocol} otherwise. If an SAD entry matches, then process the inbound AH packet with that matching SAD entry. Otherwise, discard the packet and log an auditable event.

受信機は、AHとESPのための単一のSPI空間を維持するために選択され、または{SPIプロトコル}に別段た場合3.のみ{SPI}に一致するSADを検索します。 SADエントリが一致した場合、その一致するSADエントリでインバウンドAHパケットを処理します。それ以外の場合は、パケットを破棄し、監査可能なイベントをログに記録します。

In practice, an implementation MAY choose any method to accelerate this search, although its externally visible behavior MUST be functionally equivalent to having searched the SAD in the above order. For example, a software-based implementation could index into a hash table by the SPI. The SAD entries in each hash table bucket's linked list are kept sorted to have those SAD entries with the longest SA identifiers first in that linked list. Those SAD entries having the shortest SA identifiers are sorted so that they are the last entries in the linked list. A hardware-based implementation may be able to effect the longest match search intrinsically, using commonly available Ternary Content-Addressable Memory (TCAM) features.


The indication of whether source and destination address matching is required to map inbound IPsec traffic to SAs MUST be set either as a side effect of manual SA configuration or via negotiation using an SA management protocol, e.g., IKE or Group Domain of Interpretation (GDOI) [RFC3547]. Typically, Source-Specific Multicast (SSM) [HC03] groups use a 3-tuple SA identifier composed of an SPI, a destination multicast address, and source address. An Any-Source Multicast group SA requires only an SPI and a destination multicast address as an identifier.

送信元および宛先アドレスマッチングをSAのにインバウンドIPsecトラフィックをマップするために必要であるかどうかの指示は、SA管理プロトコルを使用して手動SA設定の副作用として、または交渉を介してのいずれかで設定しなければなりません、例えば、IKE又は解釈のグループドメイン(GDOI) [RFC3547]。典型的には、ソース固有マルチキャスト(SSM)[HC03]基はSPIからなる3タプルSA識別子、宛先マルチキャストアドレス、およびソースアドレスを使用します。 SAのみSPIと宛先識別子としてマルチキャストアドレスを必要とする - ソースのマルチキャストグループ。

The set of SPI values in the range 1 through 255 is reserved by the Internet Assigned Numbers Authority (IANA) for future use; a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. The SPI value of zero (0) is reserved for local, implementation-specific use and MUST NOT be sent on the wire. (For example, a key management implementation might use the zero SPI value to mean "No Security Association Exists" during the period when the IPsec implementation has requested that its key management entity establish a new SA, but the SA has not yet been established.)

255までの範囲1にSPI値のセットは、将来の使用のためInternet Assigned Numbers Authority(IANA)によって予約されています。割り当てられたSPI値の使用は、RFCで指定されていない限り、予約SPI値は、通常、IANAによって割り当てられません。 (0)ゼロのSPI値は、ローカル、実装に固有の使用のために予約されており、ワイヤ上で送信してはいけません。 (例えば、鍵管理の実装は、IPsec実装がその鍵管理エンティティが新しいSAを確立することを要求しましたが、SAがまだ確立されていない期間中に「いいえセキュリティアソシエーションが存在する」ことを意味するゼロSPI値を使用する場合があります。 )

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つ、すなわち、によって増加カウンタ値ごと-SAパケットのシーケンス番号を含みます。ユニキャストSAまたは単一の送信者のマルチキャストSAの場合、送信者は、すべての送信パケットのために、このフィールドを増加しなければなりません。一般的に推奨されていないが、複数の送信者の間でSAを共有するには、許可されています。 AHは、複数の送信者の間でパケットカウンタを同期させるか、有意義複数の送信者の文脈における受信パケットカウンタとウィンドウの管理のない手段を提供しません。したがって、マルチ送信者SAのために、AHの抗返信機能は使用できません(セクション3.3.2および3.4​​.3を参照されたいです)。

The field is mandatory and MUST always be present even if the receiver does not elect to enable the anti-replay service for a specific SA. Processing of the Sequence Number field is at the discretion of the receiver, but all AH implementations MUST be capable of performing the processing described in Section 3.3.2, "Sequence Number Generation", and Section 3.4.3, "Sequence Number Verification". Thus, the sender MUST always transmit this field, but the receiver need not act upon it.


The sender's counter and the receiver's counter are initialized to 0 when an SA is established. (The first packet sent using a given SA will have a sequence number of 1; see Section 3.3.2 for more details on how the sequence number is generated.) If anti-replay is enabled (the default), the transmitted sequence number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA.

SAが確立されたときに、送信者のカウンタと受信側のカウンタが0に初期化されています。 (1のシーケンス番号を持つことになります与えられたSAを使用して送信された最初のパケットは、シーケンス番号の生成方法についての詳細は、セクション3.3.2を参照してください。)抗リプレイが(デフォルト)有効になっている場合は、送信シーケンス番号が必要サイクルに許されることはありません。したがって、送信側のカウンタと受信側のカウンタは、SAに2 ^ 32パケットの送信に先立って(従って新しいSAと新しい鍵を確立することによって)リセットする必要があります。

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.)

高速IPsec実装をサポートするために、シーケンス番号の新しいオプションは、現在、32ビットのシーケンス番号フィールドの拡張として、提供されるべきです。拡張シーケンス番号(ESN)を使用することは、SA管理プロトコルによって交渉しなければなりません。 IKEv2の中で、この交渉は暗黙的であることに注意してください。 32ビットのシーケンス番号が明示的に交渉されない限り、デフォルトでESNです。 (ESN機能は、同様に、ユニキャストSAをマルチキャストに適用可能です。)

The ESN facility allows use of a 64-bit sequence number for an SA. (See Appendix B, "Extended (64-bit) Sequence Numbers", for details.) Only the low-order 32 bits of the sequence number are transmitted in the AH header of each packet, thus minimizing packet overhead. The high-order 32 bits are maintained as part of the sequence number counter by both transmitter and receiver and are included in the computation of the ICV, but are not transmitted.

ESN機能はSAのための64ビットのシーケンス番号の使用を可能にします。 (詳細については、「拡張(64ビット)シーケンス番号」、付録Bを参照)のみのシーケンス番号の下位32ビットは、このように、パケットのオーバーヘッドを最小限に抑える、各パケットのAHヘッダで送信されます。上位32ビットは、送信機と受信機の両方によってシーケンス番号カウンタの一部として維持され、ICVの計算に含まれているが、送信されません。

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, "Padding". The integrity algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation.

これは、Integrityは、このパケットの値(ICV)を確認含ま可変長フィールドです。フィールドは、長さが32ビット(IPv4またはIPv6)の整数倍でなければなりません。 ICV処理の詳細は、「整合性がチェック値の検証」、3.3.3項、「整合性チェック値の計算」、および3.4​​.4項で説明されています。 AHヘッダの長さが32ビット(IPv4)の64ビット(IPv6)のの整数倍であることを保証するために必要な場合、このフィールドは、明示的なパディングを含むことができます。すべての実装は、そのようなパディングをサポートしなければならないし、IPv4 / IPv6の整列の要件を満たすだけの十分なパディングを挿入する必要があります。必要なパディング長さを計算する方法の詳細については、セクション3.3.3.2、「パディング」で以下に提供されます。完全性アルゴリズムの仕様は、検証のためのICVの長さと比較ルール及び処理ステップを指定しなければなりません。

3. Authentication Header Processing
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二つの方法で使用することができます。 (それぞれが使用する必要があるときの説明については、セキュリティアーキテクチャ文書を参照してください。)

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への使用を制限するように誤解されるべきではないことに注意してください。)以下の図は、「前後」に基づいて、一般的なIPv4パケットのためのAHトランスポートモードの位置を示します。

                   BEFORE APPLYING AH
       IPv4  |orig IP hdr  |     |      |
             |(any options)| TCP | Data |
                   AFTER APPLYING AH
       IPv4  |original IP hdr (any options) | AH | TCP |    Data   |
             |<- mutable field processing ->|<- immutable fields ->|
             |<----- authenticated except for mutable fields ----->|

In the IPv6 context, AH is viewed as an end-to-end payload, and thus should appear after hop-by-hop, routing, and fragmentation extension headers. The destination options extension header(s) could appear before or after or both before and after the AH header depending on the semantics desired. The following diagram illustrates AH transport mode positioning for a typical IPv6 packet.


                        BEFORE APPLYING AH
       IPv6  |             | ext hdrs |     |      |
             | orig IP hdr |if present| TCP | Data |
                       AFTER APPLYING AH
      IPv6  |             |hop-by-hop, dest*, |    | dest |     |      |
            |orig IP hdr  |routing, fragment. | AH | opt* | TCP | Data |
            |<--- mutable field processing -->|<-- immutable fields -->|
            |<---- authenticated except for mutable fields ----------->|

* = if present, could be before AH, after AH, or both

* =存在する場合、AHの前、AHの後、あるいはその両方をすることができ

ESP and AH headers can be combined in a variety of modes. The IPsec Architecture document describes the combinations of security associations that must be supported.

ESPおよびAHヘッダは様々なモードで組み合わせることができます。 IPsecのアーキテクチャ文書はサポートされなければならないセキュリティアソシエーションの組み合わせを説明しています。

Note that in transport mode, for "bump-in-the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use.


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.


   IPv4 |                              |    | orig IP hdr*  |   |      |
        |new IP header * (any options) | AH | (any options) |TCP| Data |
        |<- mutable field processing ->|<------ immutable fields ----->|
        |<- authenticated except for mutable fields in the new IP hdr->|
   IPv6 |           | ext hdrs*|    |            | ext hdrs*|   |    |
        |new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data|
        |<--- mutable field -->|<--------- immutable fields -------->|
        |       processing     |
        |<-- authenticated except for mutable fields in new IP hdr ->|
          * = if present, construction of outer IP hdr/extensions and
              modification of inner IP hdr/extensions is discussed in
              the Security Architecture document.
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-に基づいて、キー入力メッセージ認証コード(MAC)を含みます256など)。マルチキャスト通信では、整合性を提供するための暗号様々な戦略が開発され、研究がこの分野で継続します。

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 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.


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.


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.


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.


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.


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.


Note: If a receiver chooses not to enable anti-replay for an SA, then the receiver SHOULD NOT negotiate ESN in an SA management protocol. Use of ESN creates a need for the receiver to manage the anti-replay window (in order to determine the correct value for the high-order bits of the ESN, which are employed in the ICV computation), which is generally contrary to the notion of disabling anti-replay for an SA.

注意:受信側がSAのためのアンチリプレイを有効にしないことを選択した場合、受信機はSA管理プロトコルにESNを交渉すべきではありません。 ESNの使用は、一般的概念に反して(ICVの計算に使用されるESNの上位ビットの正しい値を決定するために)アンチリプレイウィンドウを管理するための受信機の必要性を作成しますSAのためのアンチリプレイを無効にします。

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
        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 Handling Mutable Fields。変更可能なフィールドの扱い

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.


As a new extension header or IPv4 option is created, it will be defined in its own RFC and SHOULD include (in the Security Considerations section) directions for how it should be handled when calculating the AH ICV. If the IP (v4 or v6) implementation encounters an extension header that it does not recognize, it will discard the packet and send an ICMP message. IPsec will never see the packet. If the IPsec implementation encounters an IPv4 option that it does not recognize, it should zero the whole option, using the second byte of the option as the length. IPv6 options (in Destination Extension Headers or the Hop-by-Hop Extension Header) contain a flag indicating mutability, which determines appropriate processing for such options.

新しい拡張ヘッダまたはIPv4オプションが作成されると、それはそれ自身のRFCに定義され、(セキュリティ上の考慮事項のセクションで)AH ICVを計算するときに処理する方法のための指示を含むべきです。 IP(V4またはV6)の実装は、それが認識されない拡張ヘッダを検出した場合、そのパケットを破棄し、ICMPメッセージを送信します。 IPsecは、パケットを見ることはありません。 IPsec実装は、それが認識しないことのIPv4オプションに遭遇した場合、それは長さオプションの第2バイトを使用して、全体のオプションをゼロにする必要があります。 (先拡張ヘッダまたはホップバイホップ拡張ヘッダ中の)IPv6オプションは、オプションの適切な処理を決定する可変性を示すフラグを含みます。 ICV Computation for IPv4。 IPv4のICV計算 Base Header Fields。基本ヘッダフィールド

The IPv4 base header fields are classified as follows:


Immutable Version Internet Header Length Total Length Identification Protocol (This should be the value for AH.) Source Address Destination Address (without loose or strict source routing)


Mutable but predictable Destination Address (with loose or strict source routing)

(緩んでいるか、厳密なソースルーティングで)可変だが予測可能Destination Address

Mutable (zeroed prior to ICV calculation) Differentiated Services Code Point (DSCP) (6 bits, see RFC 2474 [NBBB98]) Explicit Congestion Notification (ECN) (2 bits, see RFC 3168 [RFB01]) Flags Fragment Offset Time to Live (TTL) Header Checksum

可変(ICV計算の前にゼロ)差別化サービスコードポイント(DSCP)(フラグフラグメントライブする時間オフセットを(RFC 3168 [RFB01]を参照、2ビット)明示的輻輳通知(ECN)(6ビットは、RFC 2474 [NBBB98]を参照されたいです) TTL)ヘッダチェックサム

DSCP - Routers may rewrite the DS field as needed to provide a desired local or end-to-end service, thus its value upon reception cannot be predicted by the sender.

DSCPは、 - 所望の局所又はエンドツーエンドのサービスを提供するために、必要に応じてルータのDSフィールドを書き換えることができる、受信するので、その値は、送信者によって予測することはできません。

ECN - This will change if a router along the route experiences congestion, and thus its value upon reception cannot be predicted by the sender.

ECN - これは、ルートに沿って、ルータが輻輳を経験する場合には変更されますので、受信時にその値は、送信者によって予測することはできません。

Flags - This field is excluded because an intermediate router might set the DF bit, even if the source did not select it.

フラグは - 中間ルータは、ソースがそれを選択しなかった場合でも、DFビットを設定する可能性があるため、このフィールドは除外されています。

Fragment Offset - Since AH is applied only to non-fragmented IP packets, the Offset Field must always be zero, and thus it is excluded (even though it is predictable).

フラグメントオフセット - AHは、唯一の非断片化されたIPパケットに適用されるので、オフセットフィールドは常にゼロでなければならず、従って(それが予測可能であっても)は除外されます。

TTL - This is changed en route as a normal course of processing by routers, and thus its value at the receiver is not predictable by the sender.

TTL - これは、ルータの処理の通常の過程のように途中で変更されるので、受信機でその値が送信者によって予測できません。

Header Checksum - This will change if any of these other fields change, and thus its value upon reception cannot be predicted by the sender.

ヘッダチェックサムは - これは、これらの他のフィールドのいずれかが変更された場合に変更されますので、受信時にその値は、送信者によって予測することはできません。 Options。オプション

For IPv4 (unlike IPv6), there is no mechanism for tagging options as mutable in transit. Hence the IPv4 options are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable. For IPv4, the entire option is viewed as a unit; so even though the type and length fields within most options are immutable in transit, if an option is classified as mutable, the entire option is zeroed for ICV computation purposes.

(IPv6のとは違って)IPv4の場合、輸送中の可変などのオプションをタグ付けするためのメカニズムがありません。従ってIPv4オプションが明示的に、付録Aに記載されていると、不変可変だが予測可能、または可変として分類されます。 IPv4の場合、全体のオプションは、ユニットとして見られます。ほとんどのオプション内のタイプと長さフィールドは、輸送中に不変であってもオプションは可変として分類されている場合ので、全体のオプションはICV計算のためにゼロにされます。 ICV Computation for IPv6。 IPv6のICV計算 Base Header Fields。基本ヘッダフィールド

The IPv6 base header fields are classified as follows:


Immutable Version Payload Length Next Header Source Address Destination Address (without Routing Extension Header)


Mutable but predictable Destination Address (with Routing Extension Header)

(ルーティング拡張ヘッダ付き)可変だが予測可能Destination Address

Mutable (zeroed prior to ICV calculation) DSCP (6 bits, see RFC2474 [NBBB98]) ECN (2 bits, see RFC3168 [RFB01]) Flow Label (*) Hop Limit

可変(ゼロICV計算に先立って)DSCPフローラベル(*)ホップリミット(RFC3168 [RFB01]を参照して、2ビット)ECN(6ビットは、RFC2474 [NBBB98]を参照します)

        (*) The flow label described in AHv1 was mutable, and in
            RFC 2460 [DH98] was potentially mutable.  To retain
            compatibility with existing AH implementations, the
            flow label is not included in the ICV in AHv2. Extension Headers Containing 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

でIPv6オプション拡張ヘッダーオプションが輸送中(予測できない)変更される可能性があるかどうかを示すビットが含まれているホップバイホップと宛先。 ICVを計算または検証するとき内容は、EN-経路変更することができるため、任意のオプションのために、全体の「オプションデータ」フィールドは、ゼロ値のオクテットとして扱わなければなりません。ザ・

Option Type and Opt Data Len are included in the ICV calculation. All options for which the bit indicates immutability are included in the ICV calculation. See the IPv6 specification [DH98] for more information.

オプションタイプとオプトデータレンは、ICV計算に含まれています。ビットは不変を示しているすべてのオプションはICV計算に含まれています。詳細については、IPv6の仕様[DH98]を参照してください。 Extension Headers Not Containing Options。拡張ヘッダーは、オプションを含みません

The IPv6 extension headers that do not contain options are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable.

オプションを含まないIPv6拡張ヘッダは、明示的に、付録Aに記載されていると、不変、可変だが予測可能、可変として分類されています。 Padding and Extended Sequence Numbers。パディングと拡張シーケンス番号 ICV Padding。 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:


           - the length of the ICV
           - the IP protocol version (v4 or v6)

For example, if the output of the selected algorithm is 96 bits, no padding is required for IPv4 or IPv6. However, if a different length ICV is generated, due to use of a different algorithm, then padding may be required depending on the length and IP protocol version. The content of the padding field is arbitrarily selected by the sender. (The padding is arbitrary, but need not be random to achieve security.) These padding bytes are included in the ICV calculation, counted as part of the Payload Length, and transmitted at the end of the ICV field to enable the receiver to perform the ICV calculation. Inclusion of padding in excess of the minimum amount required to satisfy IPv4/IPv6 alignment requirements is prohibited.

選択されたアルゴリズムの出力は96ビットである場合、例えば、パディングは、IPv4またはIPv6のために必要とされません。異なる長さのICVが生成される場合は、異なるアルゴリズムを使用することにより、その後パディング長さとIPプロトコルのバージョンに応じて必要とされ得ます。パディングフィールドの内容は、任意の送信者によって選択されています。 (パディングは任意であるが、セキュリティを達成するためにランダムである必要はない。)これらのパディングバイトは、ICV計算に含まれるペイロード長の一部としてカウントされ、実行するために受信機を有効にするためにICVフィールドの最後で送信されますICV計算。 IPv4 / IPv6の整列の要件を満たすために必要な最小量の過剰でパディングを含めることが禁止されます。 Implicit Packet Padding and ESN。暗黙的パケットパディングと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のために選出されている場合は、ESNの上位32ビットがICV計算に含まれなければなりません。 ICV計算の目的のために、これらのビットは直ちにペイロードの終了後、任意の暗黙のパケットのパディングの前に(暗黙的に)付加されます。

For some integrity algorithms, the byte string over which the ICV computation is performed must be a multiple of a blocksize specified by the algorithm. If the IP packet length (including AH and the 32 high-order bits of the ESN, if enabled) does not match the blocksize requirements for the algorithm, implicit padding MUST be appended to the end of the packet, prior to ICV computation. The padding octets

いくつかの整合性アルゴリズムの場合は、ICVの計算が行われた上で、バイト文字列は、アルゴリズムによって指定されたブロックサイズの倍数でなければなりません。 (有効な場合、AHおよびESNの上位32ビットを含む)は、IPパケットの長さはアルゴリズムのブロックサイズ要件と一致しない場合、暗黙のパディングが前ICV計算に、パケットの最後に追加されなければなりません。パディングオクテット

MUST have a value of zero. The blocksize (and hence the length of the padding) is specified by the algorithm specification. This padding is not transmitted with the packet. The document that defines an integrity algorithm MUST be consulted to determine if implicit padding is required as described above. If the document does not specify an answer to this, then the default is to assume that implicit padding is required (as needed to match the packet length to the algorithm's blocksize.) If padding bytes are needed but the algorithm does not specify the padding contents, then the padding octets MUST have a value of zero.


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フラグメンテーションは、IPsec実装内でAH処理後に発生します。このように、トランスポートモードAHは、(断片をIPにない)IPデータグラム全体に対してのみ適用されます。 AHが適用されたIPv4パケット自体が途中ルータによって断片化することができ、そのようなフラグメントは、受信機での前AH処理を再組み立てしなければなりません。 (これはないルータが開始フラグメンテーションが存在しないのIPv6には適用されない。)、トンネルモードでは、AHは、IPパケットに適用され、ペイロードは、その断片化されたIPパケットであってもよいです。例えば、セキュリティゲートウェイまたは「イン・ザ・スタック・バンプ」または「バンプ・イン・ザ・ワイヤ」IPsec実装(詳細については、セキュリティアーキテクチャ文書を参照)は、このようなフラグメントにトンネルモードAHを適用することができます。

NOTE: For transport mode -- As mentioned at the end of Section 3.1.1, bump-in-the-stack and bump-in-the-wire implementations may have to first reassemble a packet fragmented by the local IP layer, then apply IPsec, and then fragment the resulting packet.

注:トランスポートモードの場合 - セクション3.1.1の最後に述べたように、インスタック・バンプとバンプ・イン・ザ・ワイヤー実装が最初にローカルIPレイヤによって断片化パケットを再構築する必要がある可能性があり、その後、適用IPsecは、次いで得られたパケットを断片化します。

NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire implementations, it will be necessary to examine all the extension headers to determine if there is a fragmentation header and hence that the packet needs reassembling prior to IPsec processing.

注意:IPv6の場合 - インスタックバンプとバンプ・イン・ザ・ワイヤ実装では、パケットのニーズが前再び組み立てること、したがって断片化ヘッダが存在するかどうかを決定するために、すべての拡張ヘッダを検査することが必要となりますIPsec処理します。

Fragmentation, whether performed by an IPsec implementation or by routers along the path between IPsec peers, significantly reduces performance. Moreover, the requirement for an AH receiver to accept fragments for reassembly creates denial of service vulnerabilities. Thus, an AH implementation MAY choose to not support fragmentation and may mark transmitted packets with the DF bit, to facilitate Path MTU (PMTU) discovery. In any case, an AH implementation MUST support generation of ICMP PMTU messages (or equivalent internal signaling for native host implementations) to minimize the likelihood of fragmentation. Details of the support required for MTU management are contained in the Security Architecture document.

断片化は、IPsecピアとの間の経路に沿ってIPsec実装によって、またはルータによって実行されるかどうか、大幅に性能を低下させます。また、再構成のためのフラグメントを受け入れるAH受信機の要件は、サービスの脆弱性の拒否を作成します。したがって、AH実装は断片化をサポートし、DFビットで送信されたパケットをマークすることができる、パスMTU(PMTU)の発見を容易にするためではないことを選択してもよいです。いずれの場合においても、AH実装は、断片化の可能性を最小限にするためにICMP PMTUメッセージ(またはネイティブホスト実装の等価内部信号)の生成をサポートしなければなりません。 MTUの管理に必要なサポートの詳細については、セキュリティアーキテクチャ文書に含まれています。

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.


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 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.


NOTE: For packet reassembly, the current IPv4 spec does NOT require either the zeroing of the OFFSET field or the clearing of the MORE FRAGMENTS flag. In order for a reassembled packet to be processed by IPsec (as opposed to discarded as an apparent fragment), the IP code must do these two things after it reassembles a packet.

注:パケットの再構成のために、現在のIPv4の仕様では、オフセットフィールドをゼロ化またはMORE FRAGMENTSフラグのクリアのいずれかを必要としません。それは、パケットを再構成した後にIPsec(見かけの断片として破棄ではなく)によって処理される再構成されたパケットのためのためには、IPコードは、これらの2つのことを行う必要があります。

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認証ヘッダを含むパケットを受信すると、受信機は、SAD内のルックアップを介して適切な(一方向)SAを決定します。セクション2.4で説明したように、ユニキャストSAのために、この決意は、SPIまたはSPIプラスプロトコルフィールドに基づいています。実装はマルチキャストトラフィックをサポートしている場合は、送信先アドレスは、(SPIに加えて)ルックアップで採用されており、2.4節で説明したように、送信者のアドレスも、使用することができます。 (このプロセスは、セキュリティアーキテクチャ文書においてより詳細に記載されている。)SAのSADエントリはまた、シーケンス番号フィールドがチェックされるかどうかを示し、32ビットまたは64ビットのシーケンス番号は、SAのために使用されているかどうか。 SAのためのSADエントリもICV計算のために使用されるアルゴリズム(複数可)を指定し、ICVを検証するために必要なキーを示します。

If no valid Security Association exists for this packet the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID.


(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.)


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.


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.


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.


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.


If the ESN option is selected for an SA, only the low-order 32 bits of the sequence number are explicitly transmitted, but the receiver employs the full sequence number computed using the high-order 32 bits for the indicated SA (from his local counter) when checking the received Sequence Number against the receive window. In constructing the full sequence number, if the low-order 32 bits carried in the packet are lower in value than the low-order 32 bits of the receiver's sequence number counter, the receiver assumes that the high-order 32 bits have been incremented, moving to a new sequence number subspace. (This algorithm accommodates gaps in reception for a single SA as large as 2**32-1 packets. If a larger gap occurs, additional, heuristic checks for re-synchronization of the receiver's sequence number counter MAY be employed, as described in Appendix B.)

ESNオプションがSAのために選択された場合、シーケンス番号の唯一の下位32ビットは、明示的に送信するが、受信機は、彼のローカルカウンタから指示SAのための上位32ビットを使用して計算フルシーケンス番号を(採用されています)受信ウィンドウに対して受信したシーケンス番号を確認するとき。下位32ビットはパケットで運ばれた場合に、フルシーケンス番号を構築する際に、受信機のシーケンス番号カウンタの下位32ビットよりも価値が低い、受信機は、上位32ビットがインクリメントされていることを前提とし、新しいシーケンス番号部分空間に移動します。 (このアルゴリズムは、単一のSAとして大32-1 ** 2としてパケットの受信のギャップを収容している。大きなギャップが発生した場合は、付録に記載されているように、受信機のシーケンス番号カウンタの再同期のための追加、ヒューリスティックチェックは、使用することができますB.)

If the received packet falls within the window and is not a duplicate, or if the packet is to the right of the window, then the receiver proceeds to ICV verification. If the ICV validation fails, the receiver MUST discard the received IP datagram as invalid. This is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, the Sequence Number, and (in IPv6) the Flow ID. The receive window is updated only if the ICV verification succeeds.


A MINIMUM window size of 32 packets MUST be supported, but a window size of 64 is preferred and SHOULD be employed as the default. Another window size (larger than the MINIMUM) MAY be chosen by the receiver. (The receiver does NOT notify the sender of the window size.) The receive window size should be increased for higher-speed environments, irrespective of assurance issues. Values for minimum and recommended receive window sizes for very high-speed (e.g., multi-gigabit/second) devices are not specified by this standard.

32のパケットの最小ウィンドウサイズをサポートしなければなりませんが、64のウィンドウサイズが好ましく、デフォルトとして使用されるべきです。別のウィンドウサイズ(最小値よりも大きい)は、受信機によって選択されてもよいです。 (受信ウィンドウサイズの送信者に通知しない。)受信ウィンドウサイズに関係なく保証の問題の、より高速な環境に増加させるべきです。最小および推奨の値(例えば、マルチギガビット/秒)デバイスは、この規格で規定されていない非常に高速のためのウィンドウサイズを受信します。

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.


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.


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, "Handling Mutable Fields", for a discussion of which fields are zeroed before performing the ICV calculation.)

実装は、以下のステップのセットと同じ結果をもたらすステップの任意のセットを使用することができます。ゼロ(任意のICVフィールドのパディングではなく)ICV値を保存し、それを置き換えることから始めます。輸送中に変更された可能性がゼロで他のすべてのフィールド。 (フィールドはICV計算を実行する前にゼロにしているの議論については、「変更可能なフィールドの処理」、項を参照してください。)

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

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の監査を有効または無効にできるようにしなければなりません。ほとんどの部分については、監査の粒度は、ローカルの問題です。しかし、いくつかの監査可能なイベントは、本明細書において同定されており、これらのイベントのそれぞれについて監査ログに含まれるべき情報の最小セットが定義されます。追加情報は、また、これらのイベント、および追加のイベントごとに、監査ログに含まれるかもしれ、明示的にも監査ログエントリになることがあり、この仕様で呼び出しません。受信機があるため、このような作用を介してサービス拒否攻撃を誘発する可能性を、監査可能なイベントの検出に応答して主張送信者へのメッセージを送信するための要件はありません。

5. Conformance Requirements

Implementations that claim conformance or compliance with this specification MUST fully implement the AH syntax and processing described here for unicast traffic, and MUST comply with all requirements of the Security Architecture document [Ken-Arch]. Additionally, if an implementation claims to support multicast traffic, it MUST comply with the additional requirements specified for support of such traffic. If the key used to compute an ICV is manually distributed, correct provision of the anti-replay service would require correct maintenance of the counter state at the sender, until the key is replaced, and there likely would be no automated recovery provision if counter overflow were imminent. Thus, a compliant implementation SHOULD NOT provide this service in conjunction with SAs that are manually keyed.

この仕様に準拠する実装は完全にユニキャストトラフィックのために、ここで説明したAHの構文と処理を実装しなければならない、とセキュリティアーキテクチャ文書[ケン-ARCH]のすべての要件を遵守しなければなりません。実装は、マルチキャストトラフィックをサポートするために主張した場合また、そのようなトラフィックのサポートのために指定された追加要求事項を遵守しなければなりません。 ICVを計算するために使用されるキーを手動で分散されている場合、アンチリプレイサービスの正しい提供は鍵が交換されるまで、送信側のカウンタ状態の正確なメンテナンスを必要とする、とそうであれば何の自動回復の規定はないだろうカウンタのオーバーフロー目前に迫りました。このように、準拠した実装は手動鍵管理されるSAで、このサービスを提供すべきではありません。

The mandatory-to-implement algorithms for use with AH are described in a separate RFC [Eas04], to facilitate updating the algorithm requirements independently from the protocol per se. Additional algorithms, beyond those mandated for AH, MAY be supported.

AHで使用するために強制的に実装するアルゴリズムは、プロトコル自体から独立してアルゴリズムの要件を更新容易にするために、別々のRFC [Eas04]に記載されています。さらなるアルゴリズムは、AHのために義務付けられたものを超えて、サポートされるかもしれません。

6. Security Considerations

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プロトコルを使用しての追加のセキュリティ関連の側面は、セキュリティアーキテクチャ文書で説明されています。

7. Differences from

This document differs from RFC 2402 [RFC2402] in the following ways.

このドキュメントは、次の方法でRFC 2402 [RFC2402]とは異なります。

        o SPI -- modified to specify a uniform algorithm for SAD lookup
          for unicast and multicast SAs, covering a wider range of
          multicast technologies.  For unicast, the SPI may be used
          alone to select an SA, or may be combined with the protocol,
          at the option of the receiver.  For multicast SAs, the SPI is
          combined with the destination address, and optionally the
          source address, to select an SA.
        o Extended Sequence Number -- added a new option for a 64-bit
          sequence number for very high-speed communications.  Clarified
          sender and receiver processing requirements for multicast SAs
          and multi-sender SAs.
        o Moved references to mandatory algorithms to a separate
          document [Eas04].
8. Acknowledgements

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.


9. References
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.、BCP 14、RFC 2119、1997年3月 "のRFCsにおける使用のためのキーワードは、要求レベルを示すために"。

[DH98] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.

[DH98]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6(IPv6)の仕様"、RFC 2460、1998年12月。

[Eas04] 3rd Eastlake, D., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005.

[Eas04]第三イーストレイク、D.、RFC 4305、2005年12月 "カプセル化セキュリティペイロード(ESP)と認証ヘッダー(AH)のための暗号アルゴリズム実装要件"。

[Ken-Arch] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.

[ケン-アーチ]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。

[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

[RFC791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。

[RFC1108] Kent, S., "U.S. Department of Defense Security Options for the Internet Protocol", RFC 1108, November 1991.

[RFC1108]ケント、S.、「インターネットプロトコルのための防衛セキュリティオプションの米国部門」、RFC 1108、1991年11月。

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]のAdvanced Encryption Standard(AES)、連邦情報処理標準197、標準技術、2001年11月26日の国立研究所。

[HC03] Holbrook, H. and B. Cain, "Source Specific Multicast for IP", Work in Progress, November 3, 2002.

[HC03]ホルブルック、H.、およびB.カイン、 "IPのためのソース固有マルチキャスト"、進歩、2002年11月3日での作業。

[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.

[IKEv2の]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ(IKEv2の)プロトコル"、RFC 4306、2005年12月。

[Ken-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.

[ケン-ESP]ケント、S.、 "IPカプセル化セキュリティペイロード(ESP)"、RFC 4303、2005年12月。

[NBBB98] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.

[NBBB98]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野(DS分野)の定義"、RFC 2474、1998年12月。

[RFB01] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.

"IPに明示的輻輳通知の添加(ECN)" [RFB01]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。

[RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP MTU discovery options", RFC 1063, July 1988.

[RFC1063]ムガール人、J.、ケント、C.、ヤマウズラ、C.、およびK. McCloghrie、 "IP MTUディスカバリオプション"、RFC 1063、1988年7月。

[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.

[RFC1122]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。

[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.

[RFC1191]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。

[RFC1385] Wang, Z., "EIP: The Extended Internet Protocol", RFC 1385, November 1992.

[RFC1385]王、Z.、 "EIP:拡張インターネット・プロトコル"、RFC 1385、1992年11月。

[RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393, January 1993.

[RFC1393]マルキン、G.、 "tracerouteのIPオプションの使用"、RFC 1393、1993年1月。

[RFC1770] Graff, C., "IPv4 Option for Sender Directed Multi-Destination Delivery", RFC 1770, March 1995.

[RFC1770] Graffの、C.、RFC 1770 "送信者監督マルチ先の配達のためのIPv4オプション"、1995年3月。

[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.

[RFC2113]カッツ、D.、 "IPルータアラートオプション"、RFC 2113、1997年2月。

[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.

[RFC2402]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。

[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.

[RFC3547] Baugher、M.、ヴァイス、B.、Hardjono、T.、およびH.ハーニー、 "解釈のグループドメイン"、RFC 3547、2003年7月。

[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.

[RFC3740] Hardjono、T.とB.ウィス、 "マルチキャストグループのセキュリティアーキテクチャ"、RFC 3740、2004年3月。

Appendix A: Mutability of IP Options/Extension Headers


A1. IPv4 Options

A1。 IPv4のオプション

This table shows how the IPv4 options are classified with regard to "mutability". Where two references are provided, the second one supercedes the first. This table is based in part on information provided in RFC 1700, "ASSIGNED NUMBERS", (October 1994).

この表は、IPv4オプションの「可変度」に関する分類されている方法を示しています。 2つの参照が提供される場合には、もう一つは第一に優先します。このテーブルは、RFC 1700、「割り当てられた番号」、(1994年10月)で提供される情報に基づいています。

    Copy Class  #   Name                       Reference
    ---- ----- ---  -------------------------  --------
    IMMUTABLE -- included in ICV calculation
      0   0     0   End of Options List        [RFC791]
      0   0     1   No Operation               [RFC791]
      1   0     2   Security                   [RFC1108] (historic but
                                               in use)
      1   0     5   Extended Security          [RFC1108] (historic but
                                               in use)
      1   0     6   Commercial Security
      1   0    20   Router Alert               [RFC2113]
      1   0    21   Sender Directed Multi-     [RFC1770]
                    Destination Delivery
    MUTABLE -- zeroed
      1   0      3  Loose Source Route         [RFC791]
      0   2      4  Time Stamp                 [RFC791]
      0   0      7  Record Route               [RFC791]
      1   0      9  Strict Source Route        [RFC791]
      0   2     18  Traceroute                 [RFC1393]

EXPERIMENTAL, SUPERCEDED -- zeroed 1 0 8 Stream ID [RFC791, RFC1122 (Host Req)] 0 0 11 MTU Probe [RFC1063, RFC1191 (PMTU)] 0 0 12 MTU Reply [RFC1063, RFC1191 (PMTU)] 1 0 17 Extended Internet Protocol [RFC1385, DH98 (IPv6)] 0 0 10 Experimental Measurement 1 2 13 Experimental Flow Control 1 0 14 Experimental Access Ctl 0 0 15 ??? 1 0 16 IMI Traffic Descriptor 1 0 19 Address Extension

代わら、実験 - 1 0 8ストリームID [RFC791、RFC1122(ホストREQ)] 0 11 MTUプローブ[RFC1063、RFC1191(PMTU)] 0 12 MTU返信[RFC1063、RFC1191(PMTU)] 1 0 17拡張をゼロインターネットプロトコル[RFC1385、DH98(IPv6)の] 0 10実測1 2 13実験フロー制御1回の0 14回の実験アクセスのCtl 0 0 15? 1 0 16 IMIトラフィック記述子1 0 19アドレス拡張

NOTE: Use of the Router Alert option is potentially incompatible with use of IPsec. Although the option is immutable, its use implies that each router along a packet's path will "process" the packet and consequently might change the packet. This would happen on a hop-by-hop basis as the packet goes from router to router. Prior to being processed by the application to which the option contents are directed (e.g., Resource Reservation Protocol (RSVP)/Internet Group Management Protocol (IGMP)), the packet should encounter AH processing. However, AH processing would require that each router along the path is a member of a multicast-SA defined by the SPI. This might pose problems for packets that are not strictly source routed, and it requires multicast support techniques not currently available.


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.


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.


A2. IPv6 Extension Headers

A2。 IPv6拡張ヘッダー

This table shows how the IPv6 extension headers are classified with regard to "mutability".


       Option/Extension Name                  Reference
       -----------------------------------    ---------
       MUTABLE BUT PREDICTABLE -- included in ICV calculation
         Routing (Type 0)                    [DH98]



NOT APPLICABLE Fragmentation [DH98]


Options -- IPv6 options in the Hop-by-Hop and Destination Extension Headers contain a bit that indicates whether the option might change (unpredictably) during transit. For any option for which contents may change en route, the entire "Option Data" field must be treated as zero-valued octets when computing or verifying the ICV. The Option Type and Opt Data Len are included in the ICV calculation. All options for which the bit indicates immutability are included in the ICV calculation. See the IPv6 specification [DH98] for more information.

オプション - ホップバイホップでのIPv6オプションと宛先拡張ヘッダーは、オプションが輸送中(予測できない)変更される可能性があるかどうかを示すビットが含まれています。 ICVを計算または検証するときにコンテンツが途中で変更することができるため、任意のオプションのために、全体の「オプションデータ」フィールドは、ゼロ値のオクテットとして扱わなければなりません。オプションタイプとオプトデータレンは、ICV計算に含まれています。ビットは不変を示しているすべてのオプションはICV計算に含まれています。詳細については、IPv6の仕様[DH98]を参照してください。

Routing (Type 0) -- The IPv6 Routing Header "Type 0" will rearrange the address fields within the packet during transit from source to destination. However, the contents of the packet as it will appear at the receiver are known to the sender and to all intermediate hops. Hence, the IPv6 Routing Header "Type 0" is included in the Integrity Check Value calculation as mutable but predictable. The sender must order the field so that it appears as it will at the receiver, prior to performing the ICV computation.

ルーティング(タイプ0) - IPv6ルーティングヘッダ「タイプ0」は送信元から宛先までの通過中のパケット内のアドレスフィールドを再配置します。しかし、それが受信機に表示されるように、パケットの内容が送信者に、すべての中間ホップに知られています。したがって、IPv6ルーティングヘッダの「タイプ0」として、可変だが予測可能整合性チェック値の計算に含まれています。それは、受信機で、前ICVの計算を実行することが意志として表示されるように、送信者は、フィールドを注文する必要があります。

Fragmentation -- Fragmentation occurs after outbound IPsec processing (Section 3.3) and reassembly occurs before inbound IPsec processing (Section 3.4). So the Fragmentation Extension Header, if it exists, is not seen by IPsec.

断片化 - 断片化は、インバウンドIPsec処理(セクション3.4)の前に発生するアウトバウンドIPsec処理(セクション3.3)と再組立後に生じます。だから、フラグメンテーション拡張ヘッダは、それが存在する場合は、IPsecのでは見られません。

Note that on the receive side, the IP implementation could leave a Fragmentation Extension Header in place when it does re-assembly. If this happens, then when AH receives the packet, before doing ICV processing, AH MUST "remove" (or skip over) this header and change the previous header's "Next Header" field to be the "Next Header" field in the Fragmentation Extension Header.


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.


Appendix B: Extended (64-bit) Sequence Numbers


B1. Overview


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.


B2. Anti-Replay Window


The receiver will maintain an anti-replay window of size W. This window will limit how far out of order a packet can be, relative to the packet with the highest sequence number that has been authenticated so far. (No requirement is established for minimum or recommended sizes for this window, beyond the 32- and 64-packet values already established for 32-bit sequence number windows. However, it is suggested that an implementer scale these values consistent with the interface speed supported by an implementation that makes use of the ESN option. Also, the algorithm described below assumes that the window is no greater than 2^31 packets in width.) All 2^32 sequence numbers associated with any fixed value for the high-order 32 bits (Seqh) will hereafter be called a sequence number subspace. The following table lists pertinent variables and their definitions.

受信機は、このウィンドウには、パケットは、これまでに認証されたシーケンス番号が最大であるパケットに対する相対することができますどのように遠くオーダーのうち制限されますサイズW.のアンチリプレイウィンドウを維持します。 (NO要件が既に32ビットのシーケンス番号のウィンドウのために確立さ32および64のパケット値を超えて、このウィンドウの最小値または推奨サイズのために確立されていない。しかし、実装規模がインタフェース速度と一致して、これらの値がサポートすることが示唆されていますESNオプションを利用して実装することにより、また、以下に説明するアルゴリズムは、ウィンドウの幅が大きくない31 ^ 2よりもパケットであることを前提としている。)上位32のための任意の固定値に関連付けられているすべての2 ^ 32のシーケンス番号ビット(SEQH)は、以下のシーケンス番号部分空間と呼ぶことにします。次の表は、関連の変数とその定義を示しています。

        Var.   Size
        Name  (bits)             Meaning
        ----  ------   ---------------------------
        W       32     Size of window
        T       64     Highest sequence number authenticated so far,
                       upper bound of window
          Tl      32     Lower 32 bits of T
          Th      32     Upper 32 bits of T
        B       64     Lower bound of window
          Bl      32     Lower 32 bits of B
          Bh      32     Upper 32 bits of B
        Seq     64     Sequence Number of received packet
          Seql    32     Lower 32 bits of Seq
          Seqh    32     Upper 32 bits of Seq

When performing the anti-replay check, or when determining which high-order bits to use to authenticate an incoming packet, there are two cases:


+ Case A: Tl >= (W - 1). In this case, the window is within one sequence number subspace. (See Figure 1) + Case B: Tl < (W - 1). In this case, the window spans two sequence number subspaces. (See Figure 2)

+ケースA:Tlの> =(W - 1)。この場合、ウィンドウは、一つのシーケンス番号の部分空間内にあります。 +ケースB(図1参照):Tlの<(W - 1)。この場合、ウィンドウは2つのシーケンス番号部分空間にまたがります。 (図2参照)

   In the figures below, the bottom line ("----") shows two consecutive
   sequence number subspaces, with zeros indicating the beginning of
   each subspace.  The two shorter lines above it show the higher-order
   bits that apply.  The "====" represents the window.  The "****"
   represents future sequence numbers, i.e., those beyond the current
   highest sequence number authenticated (ThTl).

Th+1 *********

TH + 1 *********

Th =======*****

第======= *****

                         Bl    Tl            Bl
                                        (Bl+2^32) mod 2^32

Figure 1 -- Case A

図1 - ケースA

Th ====**************

第==== **************

Th-1 ===

TH-1 ===

                                  Bl    Tl            Bl
                                                 (Bl+2^32) mod 2^32

Figure 2 -- Case B

図2 - ケースB

B2.1. Managing and Using the Anti-Replay Window


The anti-replay window can be thought of as a string of bits where `W' defines the length of the string. W = T - B + 1 and cannot exceed 2^32 - 1 in value. The bottom-most bit corresponds to B and the top-most bit corresponds to T, and each sequence number from Bl through Tl is represented by a corresponding bit. The value of the bit indicates whether or not a packet with that sequence number has been received and authenticated, so that replays can be detected and rejected.

アンチリプレイウィンドウは 'W」は、文字列の長さを定義するビット列と考えることができます。 W = T - B + 1および2 ^ 32超えることができない - の値に1を。一番下のビットは、Bに対応し、最上位ビットは、Tに対応し、TlのスルーBLから各シーケンス番号は、対応するビットによって表されます。リプレイを検出して排除することができるように、ビットの値は、そのシーケンス番号を持つパケットを受信し、認証されたか否かを示します。

When a packet with a 64-bit sequence number (Seq) greater than T is received and validated,


+ B is increased by (Seq - T) + (Seq - T) bits are dropped from the low end of the window + (Seq - T) bits are added to the high end of the window + The top bit is set to indicate that a packet with that sequence number has been received and authenticated + The new bits between T and the top bit are set to indicate that no packets with those sequence numbers have been received yet. + T is set to the new sequence number

+ B(配列 - T)だけ増加させる+(配列 - T)ビットがウィンドウ+の下端から落下(配列 - T)ビットがウィンドウの上端に添加される+先頭ビットを示すために設定されていますそのシーケンス番号を持つパケットを受信し、認証+ Tと上部ビット間の新しいビットは、これらのシーケンス番号を持つパケットがまだ受信されていないことを示すように設定されていること。 + Tは、新しいシーケンス番号に設定されています

In checking for replayed packets,


+ Under Case A: If Seql >= Bl (where Bl = Tl - W + 1) AND Seql <= Tl, then check the corresponding bit in the window to see if this Seql has already been seen. If yes, reject the packet. If no, perform integrity check (see Appendix B2.2 below for determination of SeqH).

+ケースAの下で:もしSeql> = BL(ここでB1を= Tlの - W + 1)AND Seql <= T1が、このSeqlが既に見られているかどうかを見るためにウィンドウ内の対応するビットをチェックします。 yesの場合、パケットを拒否します。いいえ、整合性チェックを実行した場合(SEQHの決意については、以下の付録B2.2を参照してください)。

+ Under Case B: If Seql >= Bl (where Bl = Tl - W + 1) OR Seql <= Tl, then check the corresponding bit in the window to see if this Seql has already been seen. If yes, reject the packet. If no, perform integrity check (see Appendix B2.2 below for determination of Seqh).

+下ケースB:Seql> = BL(ここでB1を= Tlの - W + 1)場合、またはSeql <= T1は、このSeqlが既に見られているかどうかを見るためにウィンドウ内の対応するビットをチェックします。 yesの場合、パケットを拒否します。いいえ、整合性チェックを実行した場合(SEQHの決意については、以下の付録B2.2を参照してください)。

B2.2. Determining the Higher-Order Bits (Seqh) of the Sequence Number


Because only `Seql' will be transmitted with the packet, the receiver must deduce and track the sequence number subspace into which each packet falls, i.e., determine the value of Seqh. The following equations define how to select Seqh under "normal" conditions; see Appendix B3 for a discussion of how to recover from extreme packet loss.

唯一 `Seql」はパケットで送信されるため、受信機は、すなわち、SEQHの値を決定し、各パケットが属するにシーケンス番号部分空間を推定し、追跡しなければなりません。以下の式は、「正常な」条件でSEQHを選択する方法を定義します。極度のパケット損失から回復する方法の議論については、付録B3を参照してください。

+ Under Case A (Figure 1): If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th + 1

+ケースA(図1)の下で:もしSeql> = BL(ここでB1を= Tlの - W + 1)、次いでSEQH = Thの場合Seql <BL(ここでB1を= Tlの - W + 1)、次いでSEQH = TH + 1

+ Under Case B (Figure 2): If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th - 1 If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th

+ケースB(図2)の下で:もしSeql> = BL(ここでB1を= Tlの - W + 1)、次いでSEQH = Thの - 1 Seql <BL(ここでB1を= Tlの - W + 1)場合、SEQH = Thの

B2.3. Pseudo-Code Example


The following pseudo-code illustrates the above algorithms for anti-replay and integrity checks. The values for `Seql', `Tl', `Th', and `W' are 32-bit unsigned integers. Arithmetic is mod 2^32.

次の擬似コードは、アンチリプレイおよび整合性チェックのために上記のアルゴリズムを示します。 `Seql '' Tlの'、'のTh 'および' W' の値は、32ビットの符号なし整数です。算術演算は、2 ^ 32のmodです。

        If (Tl >= W - 1)                            Case A
            If (Seql >= Tl - W + 1)
                Seqh = Th
                If (Seql <= Tl)
                    If (pass replay check)
                        If (pass integrity check)
                            Set bit corresponding to Seql
                            Pass the packet on
                        Else reject packet
                    Else reject packet
                    If (pass integrity check)
                        Tl = Seql (shift bits)
                        Set bit corresponding to Seql
                        Pass the packet on
                    Else reject packet
                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
                Seqh = Th
                If (Seql <= Tl)
                    If (pass replay check)
                        If (pass integrity check)
                            Set the bit corresponding to Seql
                            Pass packet on
                        Else reject packet
                    Else reject packet
                    If (pass integrity check)
                        Tl = Seql (shift bits)
                        Set the bit corresponding to Seql
                        Pass packet on
                    Else reject packet

B3. Handling Loss of Synchronization due to Significant Packet Loss


If there is an undetected packet loss of 2^32 or more consecutive packets on a single SA, then the transmitter and receiver will lose synchronization of the high-order bits, i.e., the equations in Appendix B2.2. will fail to yield the correct value. Unless this problem is detected and addressed, subsequent packets on this SA will fail authentication checks and be discarded. The following procedure SHOULD be implemented by any IPsec (ESP or AH) implementation that supports the ESN option.

単一SA上の2 ^ 32以上の連続するパケットの未検出パケット損失がある場合、送信機と受信機は上位ビット、付録B2.2で、すなわち、方程式の同期を失うことになります。正しい値を得るために失敗します。この問題が検出され、対処されなければ、このSA上の後続のパケットが認証チェックを失敗し、破棄すること。次の手順では、ESNオプションをサポートする任意のIPsec(ESPまたはAH)の実装によって実施されるべきです。

Note that this sort of extended traffic loss seems unlikely to occur if any significant fraction of the traffic on the SA in question is TCP, because the source would fail to receive ACKs and would stop sending long before 2^32 packets had been lost. Also, for any bi-directional application, even ones operating above UDP, such an extended outage would likely result in triggering some form of timeout. However, a unidirectional application, operating over UDP, might lack feedback that would cause automatic detection of a loss of this magnitude, hence the motivation to develop a recovery method for this case.

ソースはACKを受信するために失敗し、2 ^ 32のパケットが失われていたずっと前に送信を停止してしまうため、拡張されたトラフィック損失のこの種の問題のSA上のトラフィックのかなりの部分がTCPである場合に発生する可能性は低いと思われることに注意してください。また、任意の双方向アプリケーションのために、UDP上で動作しても、ものは、そのような拡張された停電は、おそらくタイムアウトのいくつかのフォームをトリガすることになります。しかし、一方向のアプリケーションは、UDP上で動作し、したがって、この場合の復旧方法を開発する動機をこの大きさの喪失の自動検出の原因となるフィードバックが欠けているかもしれません。

The solution we've chosen was selected to:


+ minimize the impact on normal traffic processing.


+ avoid creating an opportunity for a new denial of service attack such as might occur by allowing an attacker to force diversion of resources to a re-synchronization process. + limit the recovery mechanism to the receiver because anti-replay is a service only for the receiver, and the transmitter generally is not aware of whether the receiver is using sequence numbers in support of this optional service. It is preferable for recovery mechanisms to be local to the receiver. This also allows for backward compatibility.


B3.1. Triggering Re-synchronization


For each SA, the receiver records the number of consecutive packets that fail authentication. This count is used to trigger the re-synchronization process, which should be performed in the background or using a separate processor. Receipt of a valid packet on the SA resets the counter to zero. The value used to trigger the re-synchronization process is a local parameter. There is no requirement to support distinct trigger values for different SAs, although an implementer may choose to do so.

各SAについて、受信機は、認証に失敗した連続したパケットの数を記録します。このカウントは、バックグラウンドで、または別個のプロセッサを用いて実行されるべきである再同期プロセスをトリガするために使用されます。 SAの有効なパケットの受信は、カウンタをゼロにリセットします。再同期プロセスをトリガするために使用される値は、ローカル・パラメータです。実装がそうすることを選択するかもしれないが、異なるSAの個別のトリガー値をサポートする必要はありません。

B3.2. Re-synchronization Process


When the above trigger point is reached, a "bad" packet is selected for which authentication is retried using successively larger values for the upper half of the sequence number (Seqh). These values are generated by incrementing by one for each retry. The number of retries should be limited, in case this is a packet from the "past" or a bogus packet. The limit value is a local parameter. (Because the Seqh value is implicitly placed after the AH (or ESP) payload, it may be possible to optimize this procedure by executing the integrity algorithm over the packet up to the endpoint of the payload, then compute different candidate ICVs by varying the value of Seqh.) Successful authentication of a packet via this procedure resets the consecutive failure count and sets the value of T to that of the received packet.

上記トリガ・ポイントに到達すると、「不良」パケットは、シーケンス番号(SEQH)の上半分順次大きな値を使用して再試行された認証のために選択されます。これらの値は、各再試行のために1ずつ増加によって生成されます。これは、「過去」または偽のパケットからのパケットである場合には再試行の回数は、制限されなければなりません。限界値は、ローカルパラメータです。 SEQH値を暗黙的にAH(またはESP)ペイロードの後に​​配置されているので(それはペイロードのエンドポイントまでのパケットにわたって完全性アルゴリズムを実行することによって、この手順を最適化することが可能であってもよいし、その値を変化させることによって、異なる候補たICVを計算しますSEQHた。)この手順を介してパケットの成功した認証は、連続失敗回数をリセットし、受信したパケットとTの値を設定します。

This solution requires support only on the part of the receiver, thereby allowing for backward compatibility. Also, because re-synchronization efforts would either occur in the background or utilize an additional processor, this solution does not impact traffic processing and a denial of service attack cannot divert resources away from traffic processing.


Author's Address


Stephen Kent BBN Technologies 10 Moulton Street Cambridge, MA 02138 USA

スティーブン・ケントBBNテクノロジーズ10モールトンストリートケンブリッジ、MA 02138 USA

Phone: +1 (617) 873-3988 EMail:

電話:+1(617)873-3988 Eメール

Full Copyright Statement


Copyright (C) The Internet Society (2005).


This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。


この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、(もしあれば)後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

Intellectual Property


The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at


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は、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。



Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。