IPsec（Internet Protocol Security）は、IPパケット自体を認証・暗号化するためのプロトコル群で、1995年8月にIETFがRFC 1825〜1829として最初の仕様を公開し、1998年のRFC 2401〜2412（IPsec-v1）、2005年のRFC 4301〜4309（IPsec-v3）へと改訂されてきました。AH（Authentication Header）とESP（Encapsulating Security Payload）の2つのプロトコルを核に、IKE（Internet Key Exchange）で鍵交換を自動化する設計が特徴です。サイト間VPN・リモートアクセス・モバイル通信などで広く使われ、TLSと並ぶインターネット暗号化の代表的な土台になっています。
この記事の目次
- AH・ESP・IKEの三部構成
- 1995年初版から現代までの歩み
- VPN・リモートアクセスでの主な用途
- TLS・WireGuardとの比較
- まとめ
AH・ESP・IKEの三部構成
IPsecの中身は大きく3つに分かれます。1つ目は完全性と認証だけを提供するAH（Authentication Header, RFC 4302）、2つ目は完全性・認証に加え暗号化も行うESP（Encapsulating Security Payload, RFC 4303）、3つ目は両者で使う暗号鍵・SA（Security Association）を自動交換するIKE（Internet Key Exchange）です。現代の実装ではNAT越え（NAT-T, RFC 3947/3948）の都合や暗号化要求から、AHはあまり使われずESPがほぼ標準となっています。
動作モードはTransport ModeとTunnel Modeの2種類があります。Transportは元IPヘッダを残してペイロード部のみ保護し、ホスト間直接通信向きです。Tunnelは元IPパケット全体を新たな外側IPヘッダで包み込み、ゲートウェイ間VPN・サイト間VPNでの標準モードとなっています。IKEは初版IKEv1（RFC 2409, 1998年）が長らく使われましたが、複雑さや脆弱性のため、現在は2005年のRFC 4306と2010年のRFC 5996を経たIKEv2（RFC 7296, 2014年）への移行が進んでいます。
1995年初版から現代までの歩み
IPsecの起源は1995年8月のRFC 1825〜1829に遡ります。当時米国海軍研究所などが進めていたSwIPseプロジェクトの成果を基に、ランディ・ベリック氏らがIETFに持ち込み、TCP/IPの暗号化基盤として標準化が始まりました。IPv6で必須機能と位置付けられたことも追い風となり、IPv4にも適用可能なフレームワークとして広まりました。
1998年11月にはRFC 2401〜2412として「IPsec-v1」がまとまり、IKEv1とAH/ESPの仕様が整理されました。2005年12月にはRFC 4301〜4309の「IPsec-v3」が発行され、SAデータベースの取り扱い・暗号アルゴリズムの整理（DESの廃止、AES-CBCの導入）などが進みました。鍵交換はIKEv2（RFC 5996, 後にRFC 7296で整理）で大幅に簡素化され、EAP連携やMOBIKE（移動端末対応）の機能も標準化されています。暗号アルゴリズム面でも、AES-GCMの導入（RFC 4106）、Suite B/CNSA対応、ポスト量子暗号への準備（IKEv2の拡張議論）などが継続中で、現代のセキュリティ要件に合わせて進化を続けています。
VPN・リモートアクセスでの主な用途
IPsecの最も古くからの用途は、本社と拠点を専用回線ではなくインターネットで結ぶサイト間VPNです。Cisco ASA・Fortigate・Palo Alto・Juniper SRX・Linuxのstrongswanなどが、IKEv2/ESPでサイト間トンネルを構築し、企業WANのコストを大幅に下げる選択肢として浸透しました。AWSのSite-to-Site VPN・Azure VPN Gateway・Google Cloud VPNといったクラウドVPN接続も、IPsec（多くがIKEv2/AES-GCM）が標準です。
リモートアクセスVPNでは、iOSやmacOS・Windowsの組み込みIKEv2クライアントを使う方式が広まり、L2TP/IPsecから純IKEv2への移行が進みました。MOBIKE（RFC 4555）を使えば、Wi-Fi→LTE切り替えでもVPNセッションを維持でき、モバイル業務に適しています。SD-WANではEdge間のオーバレイ通信を全てIPsecで暗号化するのが標準で、運用者がほとんど意識せずとも、拠点間の通信は常にIPsecで保護される設計が一般化しています。Always-On VPNやZero Trust製品にも組み込まれ、現代の社内ネットワーク暗号化の基盤として広く動作しています。
TLS・WireGuardとの比較
TLSはアプリケーション層で動作し、HTTPSをはじめとする個別アプリの暗号化に使われます。IPsecはIP層で透過的に動作するため、上位アプリは何もしなくても暗号化される点が大きな違いです。サイト間VPN・OSが直接管理する暗号化トンネル用途ではIPsecが、Webや個別アプリの暗号化用途ではTLSが、それぞれ適材適所で使われます。
近年は、よりシンプルで高速な代替として2017年にジェイソン・ドネンフェルト氏が公開したWireGuardが急速に普及しました。WireGuardはCurve25519・ChaCha20-Poly1305・BLAKE2を採用し、コード量が4000行程度と非常に小さく、Linuxカーネル5.6（2020年）以降は標準搭載されています。Tailscale・CloudflareのMagic WANといった現代的VPN製品はWireGuardをベースに管理面を強化した形です。IPsecはより重厚で複雑ですが、相互運用性・成熟度・既存資産の豊富さで依然として優位な領域があり、用途によって使い分けるのが現代の現場の標準です。
まとめ
IPsecは1995年のRFC 1825〜1829に始まり、1998年・2005年・2014年の改訂を経てIP層の透過的暗号化を支える標準プロトコル群です。AH・ESP・IKEの3要素とTransport/Tunnelモードを軸に、サイト間VPN・リモートアクセス・クラウドVPN・SD-WANのオーバレイ暗号化まで幅広く採用されています。TLSやWireGuardといった代替・補完技術と棲み分けながら、現代の企業ネットワーク暗号化の基盤として今後も使われ続ける成熟技術です。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント