IPsec

【図解】初心者に分かりやすい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 を完成させるための情報を交換します。

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

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

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

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

  • 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】IKEv1とIKEv2の違いと仕組み~シーケンス,フォーマット,isakmp,DH group,PFSについて~
IKEの位置付け IKE (Internet Key Exchange) とは...

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

  • IPsec バージョン2 : RFC2401, RFC2402, RFC2406
  • 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-v2 においては暗号化前のデータの長さが推定され、この情報を攻撃に使われる懸念がありました。そのため、TFC による穴埋め (Padding) によりデータ長を隠蔽することでこの懸念を払拭しました。

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

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

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

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

一方、ルートベース IPsecでは、SA をトンネルインタフェース等の仮想インタフェースで接続します。そしてパケットがルータに入るとまずはルーティングテーブルを見て、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 を読む限り、そのような機能は存在しません。おそらく ICV のことを言っていると思われます。

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

IPsecのNAT超え問題と NAT-Trarersal

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

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

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

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

NAT-Traversal は RFC3947 (2005年) で規定されました。IKEv1 ではオプション扱いですが、IKEv2 では機能として組み込まれています。

SA の Lifetime

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

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

RFC4301 の 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 は Soft Lifetime と Hard Lifetime の間に自動的に新たな SAを確立するように動作します。

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

RFC4306 の Section 2.8 Rekeying から引用

A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes were negotiated. In IKEv2, 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 の設計では相手の死活を監視する仕組みがありませんでした。

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

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

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

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

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

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

コメント

タイトルとURLをコピーしました