【図解】初心者に分かりやすいIPsecの仕組みとシーケンス～パケットフォーマット,DPD(keepalive)について～

IPsec とは

IPsec (読み方：あいぴーせっく) とはその名が示す通り、レイヤー 3 の IP に対してセキュリティ を 強化 する プロトコル スイート ( プロトコル 群 ) です 。

1995年 RFC1825 により『Security Architecture for IP』という名称で標準化され、現在も改訂されながら根強く使い続けられています。

なお、名称は RFC6071では『Internet Protocol Security』 に 変わる て い ます 。

具体的に実現することは、暗号化 (Encryption) によって盗聴 を 防ぐ、完全性検査 (Integrity Check) により改竄を防ぐことです。

IPsec の2種類のプロトコルと2種類のモード

IPsec に は 大きい2 種類のプロトコルが あり ます 。

1 つは ESP (Encapsulating Security Payload) プロトコルで、パケットデータを暗号化し、さらにオプションで完全性検査ができるため、盗聴と改竄を防ぐことができます。IPのプロトコル番号は 50 です 。

もう 1 つは AH (Authentication Header) プロトコルで、完全性検査のみを行います。つまり暗号化はしません。IP のプロトコル番号は 51 です 。これは過去の政治的な話で「暗号化を禁止」する国があったため、その配慮として作られたものですが、今の時代ではほぼ使われません。

また、IPsec には 2 種類 の モードが あり ます 。

1 つがトランスポート モードで、エンドポイント同士が直接暗号化・復号化を行うモードです。このモードは SSL/TLS と守備範囲が競合していますが、利便性の面で SSL/TLS が上回るため、ほぼ使われていません。より詳細は以下の記事をご参照下さい。

【図解】IPsecとSSL/TLSの違い ～セキュリティ強度や用途,メリット/デメリットの比較～

IPsec vs SSL/TLS IPsec も SSL/TLS も共に『通信相…

もう 1 つがトンネルモードで、NW 機器同士 (サイト間 VPN)、もしくは、クライアント PC と NW機器 (リモートアクセス VPN) の間で通信を保護します。

リモートアクセス VPN は SSL/TLS による SSL-VPN と守備範囲が競合しますが、パフォーマンスの面で IPsec VPN が有利です。

また、サイト間 VPN については SSL/TLS では実現できません。

な の で 、 現場 の ネットワーク エンジニア が 覚える べき は 図 の 通り ESP トンネル モード です 。 この 記事 に 限る ず 、 本 サイト で は 特に 明記 さ れ ない 限り 、 『IPsec = ESP トンネルモード』を指すこととします。

IPsecの動作概要とシーケンス

IPsec では IKE が作成した SPD および SAD を参照することで動作します。

ike プロトコル は UDP 500 番 を 使う て 対向 ルータ と ネゴシエーション し 、 対向 ルータ を 互い に 認証 し 、 対向 と 双 方向 の 暗号 化 トンネル ( ike SA ) を 構築 し た 上 で 、 SPD と sad を 完成 さ せる ため の 情報 を 交換 し ます 。

交換 する 情報 is 値 は 例えば 暗号 アルト リズム や 完全 性 検査 ( メッセージ 認証 ) アルゴリズム 、 プロトコル ( AH or ESP ) 、 モード 、 DH 鍵 交換 の 公開 値 、 など です 。

SAD は IKE で交換する情報だけを使って作られますが、SPD は config 設定と IKE によって構成されます。

SPD と SAD が 完成 し たら IPsec SA と 呼ぶ れる 片 方向 の 暗号 化 トンネル が 出来る 上がる 、 IPsec を 使う 準備 is 整い が 整う ます 。

準備 の 整う た ルータ に パケット が 入る て くる と 、 ルータ is SPD は まず SPD のセレクタ [ 送信 元 IP , 宛先 IP , プロトコル , 送信 元 Port , 宛先 Port ] に ヒット する エントリ を 探す 、『 Processing Choice is 該当 』 が 以下 の どれ に 該当 する かによって処理を決めます。

• protect : IPsec に よる 保護 を 行う こと と し 、 sad を 参照 する
• bypass : IPsec の 処理 は せ ず 、 通常 通り 、 ルーティング テーブル を 見る て 転送 先 を 決める
• discard : パケット を 破棄 する

protect の 場合 は sad を 参照 し 、 対向 の 共通 鍵 で IP パケット を 丸 ごと 暗号 化 し 、 SPI と いう インデックス を 平文 で つけ て 新た な IP ヘッダ を 付ける て 対向 に 送信 し ます 。

対向 の ルータ で は パケット の SPI を 見る て SAD から ヒット する エントリ を 検索 し 、 その エントリ の 共通 鍵 で 復号 し ます 。

IKEとIPsecのバージョン

IKE には IKEv1 と IKEv2 が あり ます 。一方、IPsec のバージョンには主に IPsec-v2 と IPsec-v3 が使われています。(IPsec-v1 もありますが今はまず実装されていません。)

IKE と IPsec は互いに独立しているため、IKEv2 を使った場合でも IPsec-v2 と IPsec-v3 のどちらでも使うことができます。また、IKE も IPsec もバージョン違いによる互換性はありません。

IKEv1 は汎用性やモジュール指向を求めた結果、仕様が複雑かつ抽象的になり、ベンダ実装に大きな乖離が出ることとなり、異なるベンダ間での相互接続性に問題が生じやすくなりました。その反省を踏まえ、IKEv2 ではシンプルかつ確定的な仕様になりました。

IKE のバージョンの違いや詳細の動作については以下の記事をご参照下さい。

【 図解 / IPsec 】 ikev 1 と ikev 2 の 違い と 仕組み ~ シーケンス , フォーマット , isakmp , DH Group , PFS に つい て ～

ike の 位置 付け ike ( Internet Key Exchange ) と は 盗 . . .

IPsec のバージョンについては RFC6071 の3章に記載がありますが、

• IPsec バージョン 2 : RFC 2401 , RFC 2402 , RFC 2406
• IPsec バージョン3 : RFC4301, RFC4302, RFC4303

となっています。IPsec-v3 はベースとなる IPsec-v2 に以下 2 つの機能が追加されています。

• ESN : Extended Sequence Number
• TFC : Traffic flow confidentiality

esn と TFC

ESN はシーケンス番号を従来の 32 bit から 64 bit へ拡張するフィールドです。

後述しますが、IPsec のパケットフォーマットには Sequence Number (シーケンス番号) という 32 bit のフィールドがあり、これを使ってリプレイ攻撃などを防いでいます。ですが高速通信時においては十分な時間を置くことなく 32 bit のシーケンス番号を使い尽くしてしまうことが懸念され始めました。

そのため、ESN という 32 bit のフィールドを新たに設け、通常の Sequence Number と合わせた 64 bit のシーケンス番号を使ってこの懸念を払拭しました。なお、これも後述しますが、追加された ESN についてはメッセージ認証のハッシュ計算 (ICV : Integrity Check Value) には含めますが、実際には送信しません。4 Byte 分ですが省略することでトラフィック効率を高めています。対向でも ESN を使って ICV を計算し、これが合致することで相手と ESN が同じ値であることを確認します。

ESN 機能の ON/OFF は IKEv2 ネゴシエーション時に “ESN transform” フィールドを通して行われます。0 なら OFF, 1 なら ON です 。(IKEv1 を使う場合は ESN は使えない)

また、TFC はデータ長を隠蔽するための Padding です 。

IPsec – V 2 に おい て は暗号化前のデータの長さが推定され、この情報を攻撃に使われる懸念が あり まし た 。 その ため 、 TFC に よる 穴埋め ( padding ) に より データ 長 を 隠蔽 する こと で この 懸念 を 払拭 し まし た 。

TFC の機能は IKEv2 利用時にデフォルトで ON になります。この機能を OFF にするためには IKEv2 ネゴシエーション時に明示的に “ESP_TFC_PADDING_NOT_SUPPORTED” notification を送信します。(IKEv1 を使う場合は TFC は使えない)

ポリシーベースIPsecとルート ベースIPsec

ベンダの IPsec 実装でポリシーベースとルート ベースという言葉が あり ます 。これは RFC では定義されていない言葉です。というよりも、RFC で は ポリシー ベース が 前提で作られています。ルート ベースはベンダ主導でそのポジションを獲得した実装です。

ポリシーベース IPsec では、パケットがルータに入ったタイミングでまずは SPD によるポリシー精査が走ります。要はポリシーベースルーティングです。

一方、ルート ベース IPsec で は 、 SA を トンネル インタフェース 等 の 仮想 インタフェース で 接続 し ます 。 そして パケット is 入る が ルータ に 入る とまず は ルーティング テーブル を 見る て、 nexthop が IPsec 用 の 仮想 インタフェース だっ た 場合 は SPD に よる ポリシー 精査 が 走る ます が 、 ここ で は 基本 的 に 全て を IPsec 保護 対象 と し ます 。

ルート ベースにすると『BYPASS』と『DISACRD』の選択肢が無くなり、全て『PROTECT: IPsec で保護』となりますが、そもそもポリシーベースでも『BYPASS』と『DISACRD』の選択肢は現場レベルの実装設計ではほぼ利用されません。

ルート ベースではトンネルインタフェース (仮想インタフェース) を使うことで普通のルーティングテーブルベースで設計することができます。複雑なポリシーベースルーティングのような設計を行う必要がありません。

また、トンネルインタフェース経由で RIP や OSPF 等の動的ルーティングが使えるようになるのもメリットの 1 つです。

IPsec のパケットフォーマット

IPsec のパケットフォーマットを以下に示します。

前述の通り、ESN は Sequence Number を 32 bit から 64 bit に拡張するもので、ESN 自体は上位 32bit を担当しますが、送信されるパケットには含まれません。その代わり、ICV による完全性検査には ESN が含まれている体で ICV の計算が行われます。

wiki や 一部 の サイト で は 『 認証 トレイラー 』 と いう 改竄 防止 オプション 機能 が 紹介 さ れ て い ます が 、 RFC を 読む 限り 、 その よう な 機能 is 存在 は 存在 し ませ ん 。 おそらく ICV の こと を 言う て いる と 思う れ ます 。

IPsec の 規格 と し て は 完全 性 検査 は オプション 扱い の ため 、 完全 性 検査 を 利用 し ない 場合 は ICV is 送信 は 送信 さ れ ませ ん 。

IPsecのNAT超え問題と NAT-Trarersal

NAPT を越えて IPsec を正しく動作させるためには『NAT-Traversal』を使う必要が あり ます 。

NAPT 環境 の 場合 、 ポート 番号 を 変換 する 必要 が あり ます が 、 IPsec で は TCP / UDP ヘッダ も 暗号 化 し て い て 書き換え が でき ない ため です 。 この 問題 is 発生 は SSL / tls で は 発生 し ませ ん 。

そのため、NAT-Traversal 機能により、パケットに UDP ヘッダ (8 byte) を差し込んで対応します。

なお、AH においては暗号化はされないのでポートの書き換えは可能ですが、そもそも AH は IP アドレスの改竄も許さないため、やはり NAT-Traversal が必要です。IKE (isakmp) においては送信元ポートと宛先ポートがともに UDP 500 番であるため、NAPT によりポート番号が変わるのは NG です 。

NAT – Traversal is 規定 は RFC 3947 ( 2005 年 ) で 規定 さ れ まし た 。 ikev 1 で は オプション 扱い です が 、 ikev 2 で は 機能 と し て 組む 込む れ て い ます 。

SA の Lifetime

セキュリティの観点から、IKE SA および IPsec SA では Lifetime ( 寿命 ) があり、この時間を過ぎると SA は消滅し、交換した共通鍵は破棄されます。

SA には Lifetime が 2 種類あります。

RFC 4301 の SECTION 4 . 4 . 2 . 1 DATA items In THE sad から 引用

there should Be two kinds of lifetime ー a soft lifetime that warns THE implementation to initiate ACTION such AS setting UP a replacement SA , AND a hard lifetime when THE CURRENT SA ends AND is destroyed .

1 つ 目 はSoft Lifetime です 。一度 SA を確立すると、同じ相手からの SA 確立を拒否しますが Soft Lifetime を過ぎると、同じ SA を新たに確立することができます。

2 つ目は Hard Lifetime です 。この時間を過ぎると SA は消滅します。

つまり 、 IKE is 動作 は Soft Lifetime と Hard Lifetime の 間 に 自動 的 に 新た な SA を 確立 する よう に 動作 し ます 。

なお、Lifetime は IKEv1 においてはネゴシエーションすることになっていますが、IKEv2 では各々が各々の Lifetime に責任を持つことになっています。

RFC4306 の Section 2.8 Rekeying から引用

a difference Between ikev 1 AND ikev 2 is that In ikev 1 SA lifetimes were negotiated . In ikev 2 , each End of THE SA is responsible for enforcing ITS own lifetime Policy on THE SA AND rekeying THE SA when necessary .

DPD (Dead Peer Detection)

初期 の IPsec の 設計 で は 相手 の 死活 を 監視 する 仕組み is あり が あり ませ ん でし た 。

つまり、相手からパケットが来ないとき は 『対向 ( ピア ) 側 で IPsec トンネル を 使う 通信 is 無い が 無い』のか『対向 (ピア) が死んでるのか』を知る術がありませんでした。

この状況下においては、片方のルータが再起動する等で SA が消滅したとき、IPsec の再接続に時間が掛かる、といった事象に見舞われてしまいます。

なぜなら、相手が死んだかどうかが分からない上に、セキュリティの観点で複数の同じ SA を作れないからです。Soft Lifetime が過ぎるまで待つ必要が あり ます 。

これを解決するために登場したのが Dead Peer Detection (DPD) です 。

DPD では Keepalives のためのパケットを定期的に送信し、相手から返事が来ない場合は SA を消滅させます。これにより新たな SA を作ることができるようになります。

Dead Peer Detection は RFC3706 (2004年) で規定されました。IKEv1 ではオプション扱いですが、IKEv2 では機能として組み込まれています。