メインコンテンツまでスキップ

3.3.3. Integrity Check Value Calculation (完全性チェック値計算)

AH ICVは次のものに対して計算されます:

  • AHヘッダーの前のIPまたは拡張ヘッダーフィールドで, 転送中に不変であるか, AH SAのエンドポイントに到着時に値が予測可能なもの
  • AHヘッダー (Next Header, Payload Len, Reserved, SPI, Sequence Number (下位32ビット), およびICV (この計算のためにゼロに設定されます), および明示的なパディングバイト (ある場合))
  • AHの後のすべては転送中に不変であると想定されます
  • ESNの上位ビット (使用されている場合), および完全性アルゴリズムによって要求される暗黙的なパディング

3.3.3.1. Handling Mutable Fields (可変フィールドの処理)​

フィールドが転送中に変更される可能性がある場合, ICV計算の目的で, フィールドの値はゼロに設定されます。フィールドが可変であるが, (IPsec) 受信者でのその値が予測可能である場合, ICV計算の目的で, その値がフィールドに挿入されます。完全性チェック値フィールドも, この計算の準備としてゼロに設定されます。各フィールドの値をゼロで置き換えることにより, フィールドを省略するのではなく, ICV計算のためのアライメントが保持されることに注意してください。また, ゼロ埋めアプローチにより, そのように処理されるフィールドの長さは, その内容がICVによって明示的にカバーされていなくても, 転送中に変更できないことが保証されます。

新しい拡張ヘッダーまたはIPv4オプションが作成されると, それは独自のRFCで定義され, AH ICVを計算するときにそれをどのように処理すべきかについての指示を (セキュリティに関する考察セクションに) 含めるべきです (SHOULD)。IP (v4またはv6) 実装が認識しない拡張ヘッダーに遭遇した場合, パケットを破棄し, ICMPメッセージを送信します。IPsecはパケットを見ることはありません。IPsec実装が認識しないIPv4オプションに遭遇した場合, オプションの2番目のバイトを長さとして使用して, オプション全体をゼロにする必要があります。IPv6オプション (宛先拡張ヘッダーまたはホップバイホップ拡張ヘッダー内) には, 可変性を示すフラグが含まれており, このようなオプションの適切な処理を決定します。

3.3.3.1.1. ICV Computation for IPv4 (IPv4のICV計算)​

3.3.3.1.1.1. Base Header Fields (ベースヘッダーフィールド)​

IPv4ベースヘッダーフィールドは次のように分類されます:

Immutable (不変):

  • Version
  • Internet Header Length
  • Total Length
  • Identification
  • Protocol (これはAHの値である必要があります。)
  • Source Address
  • Destination Address (ルーズまたはストリクトソースルーティングなし)

Mutable but predictable (可変だが予測可能):

  • Destination Address (ルーズまたはストリクトソースルーティングあり)

Mutable (ICV計算前にゼロ化) (可変):

  • Differentiated Services Code Point (DSCP) (6ビット, RFC 2474 [NBBB98] を参照)
  • Explicit Congestion Notification (ECN) (2ビット, RFC 3168 [RFB01] を参照)
  • Flags
  • Fragment Offset
  • Time to Live (TTL)
  • Header Checksum

DSCP - ルーターは, 必要なローカルまたはエンドツーエンドサービスを提供するために必要に応じてDSフィールドを書き換える場合があるため, 受信時の値は送信者によって予測できません。

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

Flags - このフィールドは, 送信元がDFビットを選択していなくても, 中間ルーターがDFビットを設定する可能性があるため, 除外されます。

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

TTL - これは, ルーターによる処理の通常の過程でルート上で変更されるため, 受信者での値は送信者によって予測できません。

Header Checksum - これは, これらの他のフィールドのいずれかが変更された場合に変更されるため, 受信時の値は送信者によって予測できません。

3.3.3.1.1.2. Options (オプション)​

IPv4の場合 (IPv6とは異なり), 転送中にオプションを可変としてタグ付けするメカニズムはありません。したがって, IPv4オプションは付録Aに明示的にリストされ, 不変, 可変だが予測可能, または可変として分類されます。IPv4の場合, オプション全体が単位として見なされます。したがって, ほとんどのオプション内のタイプおよび長さフィールドは転送中に不変ですが, オプションが可変として分類されている場合, ICV計算の目的でオプション全体がゼロ化されます。

3.3.3.1.2. ICV Computation for IPv6 (IPv6のICV計算)​

3.3.3.1.2.1. Base Header Fields (ベースヘッダーフィールド)​

IPv6ベースヘッダーフィールドは次のように分類されます:

Immutable (不変):

  • Version
  • Payload Length
  • Next Header
  • Source Address
  • Destination Address (ルーティング拡張ヘッダーなし)

Mutable but predictable (可変だが予測可能):

  • Destination Address (ルーティング拡張ヘッダーあり)

Mutable (ICV計算前にゼロ化) (可変):

  • DSCP (6ビット, RFC2474 [NBBB98] を参照)
  • ECN (2ビット, RFC3168 [RFB01] を参照)
  • Flow Label (*)
  • Hop Limit

(*) AHv1で説明されているフローラベルは可変であり, RFC 2460 [DH98] では潜在的に可変でした。既存のAH実装との互換性を保持するために, フローラベルはAHv2のICVに含まれていません。

3.3.3.1.2.2. Extension Headers Containing Options (オプションを含む拡張ヘッダー)​

ホップバイホップおよび宛先拡張ヘッダーのIPv6オプションには, オプションが転送中に (予測不可能に) 変更される可能性があるかどうかを示すビットが含まれています。ルート上で内容が変更される可能性のあるオプションの場合, ICVを計算または検証するときに, 「Option Data」フィールド全体をゼロ値のオクテットとして扱わなければなりません。Option TypeとOpt Data Lenは, ICV計算に含まれます。ビットが不変性を示すすべてのオプションは, ICV計算に含まれます。詳細については, IPv6仕様 [DH98] を参照してください。

3.3.3.1.2.3. Extension Headers Not Containing Options (オプションを含まない拡張ヘッダー)​

オプションを含まないIPv6拡張ヘッダーは, 付録Aに明示的にリストされ, 不変, 可変だが予測可能, または可変として分類されます。

3.3.3.2. Padding and Extended Sequence Numbers (パディングと拡張シーケンス番号)​

3.3.3.2.1. ICV Padding (ICVパディング)​

セクション2.6で述べたように, AHヘッダーが32ビット (IPv4) または64ビット (IPv6) の倍数であることを保証するために必要な場合, ICVフィールドには明示的なパディングが含まれる場合があります。パディングが必要な場合, その長さは2つの要因によって決まります:

  • ICVの長さ
  • IPプロトコルバージョン (v4またはv6)

例えば, 選択されたアルゴリズムの出力が96ビットの場合, IPv4またはIPv6にパディングは必要ありません。ただし, 異なるアルゴリズムの使用により異なる長さのICVが生成される場合, 長さとIPプロトコルバージョンに応じてパディングが必要になる場合があります。パディングフィールドの内容は, 送信者によって任意に選択されます。(パディングは任意ですが, セキュリティを達成するためにランダムである必要はありません。) これらのパディングバイトは, ICV計算に含まれ, ペイロード長の一部としてカウントされ, 受信者がICV計算を実行できるようにするためにICVフィールドの最後に送信されます。IPv4/IPv6のアライメント要件を満たすために必要な最小量を超えるパディングを含めることは禁止されています。

3.3.3.2.2. Implicit Packet Padding and ESN (暗黙的パケットパディングとESN)​

SAに対してESNオプションが選択されている場合, ESNの上位32ビットをICV計算に含める必要があります。ICV計算の目的で, これらのビットはペイロードの終わりの直後, 暗黙的パケットパディングの前に (暗黙的に) 追加されます。

一部の完全性アルゴリズムの場合, ICV計算が実行されるバイト文字列は, アルゴリズムによって指定されたブロックサイズの倍数でなければなりません。IPパケット長 (AHおよび有効な場合はESNの32上位ビットを含む) が, アルゴリズムのブロックサイズ要件と一致しない場合, ICV計算の前に, パケットの最後に暗黙的パディングを追加しなければなりません (MUST)。パディングオクテットの値はゼロでなければなりません (MUST)。ブロックサイズ (したがってパディングの長さ) は, アルゴリズム仕様によって指定されます。このパディングはパケットと一緒に送信されません。完全性アルゴリズムを定義する文書を参照して, 上記で説明したように暗黙的パディングが必要かどうかを判断しなければなりません。文書がこれに対する回答を指定していない場合, デフォルトでは, 暗黙的パディングが必要であると想定されます (パケット長をアルゴリズムのブロックサイズに一致させるために必要に応じて)。パディングバイトが必要だが, アルゴリズムがパディングの内容を指定していない場合, パディングオクテットの値はゼロでなければなりません (MUST)。

に最終更新