【図解】初心者に分かりやすいIPsecの仕組みとシーケンス~パケットフォーマット,DPD(keepalive)について~ | SEの道標
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 では機能として組み込まれています。

コメント

  1. たぶん将来のセキュリティエンジニア より:

    IPsecでリモートアクセスVPNをするとなると通信の方向でモードが違うような気がするのですが,それは間違いでしょうか?

    例えば,Fortigateを利用してリモートアクセスVPNを構築すると,以下のような通信があると思います.

    PC –> Fortigate
    PC Fortigate はトンネルモード
    PC <– Fortigate はトランスポートモード

    それとも,この記事ではリモートアクセスVPNがトンネルモードに分類されているように,PC <– Fortigateの通信もトンネルモードで,PC側ではあたかも拠点ルータがあるように振る舞っているのでしょうか?

    2度目の長い質問失礼します.

    (…IPで私の所属がわかっちゃいますね)

    • nesuke より:

      こんばんは。2度目のコメントありがとうございます。所属は把握させて頂きましたw

      まず前提として、IKE, IPsec は RFC で書かれていることよりも「どのように実装されているか」が正義だと思います。(IKEv1 の歴史もそうですが、ポリシーベースだけでなくルートベースのものが出てきたり、など)

      https://milestone-of-se.nesuke.com/nw-basic/ipsec/proxy-id-and-policy-route-based/

      その点も踏まえてご回答すると、例えそのような実装が可能だとしても、誰も得しない実装なので、普通に考えて「通信の往復で同じモードを使う」実装をするでしょう。(片側だけカプセル化しないとなると FW の Stateful Inspection も効かないですしその他NW上でも大きな制約が出てきます。)

      私が知る一般的な実装では (SSL-VPNでも一緒ですが) 、トンネルモードが利用され、PC側では「仮想インタフェース」が作られ、これが貴殿が仰られた拠点ルータのように振る舞います。

      • たぶん将来のセキュリティエンジニア より:

        長文コメントしたら,中盤の文がすっぽり抜けてしまいました.
        汲み取って答えていただきありがとうございます.

        内容はこんな感じでした.
        ———————————
        IPsecでリモートアクセスVPNをするとなると通信の方向でモードが違うような気がするのですが,それは間違いでしょうか?

        例えば,Fortigateを利用してリモートアクセスVPNを構築すると,以下のような通信があると思います.

        PC –> Fortigate
        PC Fortigate はトンネルモード
        PC <– Fortigate はトランスポートモード

        この記事ではリモートアクセスVPNはトンネルモードに分類されているように,PC <– Fortigateの通信もトンネルモードで,PC側ではあたかも拠点ルータがあるように振る舞っているのでしょうか?
        ——————————–

        確かにFWのinspectが双方で異なるのは面倒になりそうですね.考えていませんでした.
        まだ気になるのでパケット覗いてみます.

        • たぶん将来のセキュリティエンジニア より:

          あれ?なんか,2回目も中盤の文が抜けてしまいますね.
          なんでですかね笑

          • nesuke より:

            たぶん < > で囲まれた部分が html タグとして解釈された上で消えてしまっていると思います。。

            面倒ですみませんが、< や > を使う場合は &lt; や &gt; をお使い下さい。

  2. kei より:

    はじめまして。
    参考にさせて頂き、ネットワークについて勉強中のものです。

    IPsecでリモートアクセスVPNというと、本などにはL2TP/IPsecが紹介されています。
    また、IPsecは拠点間接続で使用すると記載されています。

    なので、リモートアクセスはL2TP/IPsec、拠点間接続がIPsecだと思っていたのですが、
    iPhoneのVPN設定には、タイプがIPsecとL2TPとがあり、AndroidでもVPNサーバの方式はL2TP/IPsecとIPsecの選択肢が別にあり、少し混乱しています。
    IPsecは拠点間接続だけでなく、リモートアクセスでも使えるのでしょうか?
    また、リモートアクセスのIPsecとL2TP/IPsecは別物なのでしょうか?

    • nesuke より:

      keiさんこんばんは。コメントありがとうございます。

      端的に回答すると
      > IPsecは拠点間接続だけでなく、リモートアクセスでも使えるのでしょうか?
      はい、記事に掲載している通り、リモートアクセスも使えます。

      > また、リモートアクセスのIPsecとL2TP/IPsecは別物なのでしょうか?
      はい、別物です。以下の記事が参考になると思います。
      https://www.allied-telesis.co.jp/solution/vpn/vpn_type.html

      IPsec は IPv4/IPv6 専用の機能ですが、L2TP はそれ以外のL3プロトコルも通すことができます。ただし、L2TPは「IPを使ってトンネルする」「暗号化機能が無い」ので IPsec と併用して暗号化をしつつIP以外のプロトコルを伝搬することができます。(ただ、IP 以外を通すケースは私はほとんど知りませんので通常の IPsec で十分だとは考えています。)

      • kei より:

        ご回答頂き、ありがとうございます。
        返信が遅くなりすみません。

        ご教示頂いた内容と、色々と自分でも調べてみました。

        IPsec単位で暗号化と認証の機能を備えているため、リモートアクセスでも拠点間接続でも利用できる。
        L2TP/IPsecは、IP以外のプロトコルを通したい時に使うと理解しました。

        ルーターやUTMにIPsec機能が搭載されていればiPhoneのVPN設定のタイプにはIPsecを選択し、ルーターやUTMにL2TP/IPsec機能が搭載されていればiPhoneのVPN設定のタイプにはL2TPを選択する。ということですかね。

        iPhoneのVPN設定のタイプには、ikev2もあるのですが、これはIPsecで鍵の交換にikev1ではなくikev2を使った場合に選択するということでしょうか?

        • nesuke より:

          kei さん
          すみません、iPhoneの設定は分からないですが、頂いた情報だけで判断するとそういう風に受け取れますね。

  3. 急にVPN設定任せられて困っているインフラエンジニア より:

    記事及びコメント欄の内容、大変参考になります。ありがとうございます。

    • nesuke より:

      > 急にVPN設定任せられて困っているインフラエンジニアさん

      だいぶ亀レスですみません。本サイト参考に頂いたとのことで、お役に立てたようで何よりです。
      今後もどうぞよろしくお願いします。

  4. nnao より:

    ネットワークスペシャリストを勉強しているものですが、
    非常に分かり易い図で、大変参考にさせていただいております。

    気になった点があったので、書き込みします。NAT-Traversalの
    パケット図ですが、USPヘッダとESPヘッダの位置が逆になっていると
    思われます。

    • nesuke より:

      > nnao さん、コメントありがとうございます。

      本当ですね。。すぐ直します!ご指摘ありがとうございます!

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