IPsec

IPsec（Security Architecture for Internet Protocol又またはInternet Protocol Security、アイピーセック）は、データストリームの各かくIPパケットを認証にんしょう／暗号あんごう化かすることにより、ネットワーク層そうでIP通信つうしんを保護ほごするためのプロトコル群ぐんである^[1]。暗号あんごう技術ぎじゅつを用もちいることで、IP パケット単位たんいで改竄かいざん検知けんちや秘匿ひとく機能きのうを提供ていきょうするプロトコルである。これによって、暗号あんごう化かをサポートしていないトランスポート層そうやアプリケーションを用もちいても、通信つうしん路みちの途中とちゅうで、通信つうしん内容ないようを覗のぞき見みられたり改竄かいざんされることを防止ぼうしできる。

IPsecは、IPv6では必須ひっすとされた時期じき^[2]があり、専用せんようの拡張かくちょうヘッダが定義ていぎされている。一方いっぽう、IPv4では、利用りよう可能かのうだが必須ひっすではなく、IP ヘッダオプションを利用りようする。

バージョン

IPsecの規格きかくはIETFの ipsec wg にて策定さくていし、RFCとして公開こうかいしている。IETF ではIPsecにバージョン番号ばんごうを与あたえていないが、非公式ひこうしきに下記かきのバージョンが与あたえられて^[3]おり、2016年ねん現在げんざいのバージョンはIPsec-v3である：

IPsec-v1：RFC182x 形式けいしきのもの
IPsec-v2：RFC240x 形式けいしきのもの
IPsec-v3：RFC430x 形式けいしきのもの

プロトコル概要がいよう

構成こうせい

IPsecは、2つのピアの間あいだにSA (Security Association)という単たん方向ほうこうコネクションを確立かくりつすることで、ピア間あいだにセキュアな通信つうしんを確立かくりつする（詳細しょうさい後述こうじゅつ）。なお、SAは、単たん方向ほうこうであるため、双方向そうほうこう通信つうしんを行おこなう場合ばあいには、上のぼりと下くだりの2つのSAを確立かくりつする必要ひつようがある。

ピアは、ホストとセキュリティ・ゲートウェイの二に種類しゅるいに分類ぶんるいできる。前者ぜんしゃは、個人こじん端末たんまつやサーバのようなIP通信つうしんの端点たんてんに相当そうとうする機器ききである。後者こうしゃは、ルータのようなIP通信つうしんの中継ちゅうけいを担になう機器ききである。

IPsecは、原理げんり的てきにはピアがどちらのタイプであるのかを問とわない。したがって、ホストからホストまでの通信つうしん全体ぜんたいを直接ちょくせつ1つのSAで保護ほごすることもできるし、2つの中継ちゅうけい地点ちてん間あいだ毎ごとに別々べつべつのSAを確立かくりつして通信つうしんを保護ほごするリレー形態けいたいの運用うんようも可能かのうである。しかし後述こうじゅつするように、ピアがどちらのタイプであるかによって推奨すいしょうされる通信つうしんモードが存在そんざいする。

IPsecの各かくピアは、SPD（security policy database）、SAD（security association database）という2つのデータベースを管理かんりする。

SPDは、IPアドレス、プロトコル(TCP/UDP/ICMP等とう)、TCPポートといった情報じょうほうに応おうじて、パケットを破棄はき（discard）するのか、IPsecを使つかわずに送信そうしん（bypass IPsec）するのか、IPsecを使つかって送信そうしん（apply IPsec）するのかを決きめるセキュリティポリシーのデータベースである。

一方いっぽう、SADは、各かくピアとSAを確立かくりつする際さいに用もちいるパラメータのデータベースである。

プロトコルの流ながれ

ピアSがピアRに向むけてIPsecで通信つうしんするには、以下いかの3ステップを踏ふむ。

SからRへのSAを確立かくりつする。
SAを使つかってパケットをSがRに暗号あんごう通信つうしんする。
Rがデータを受信じゅしんし、復号ふくごうなどの必要ひつよう処理しょりを行おこなう。

第だい一いちステップであるSAを確立かくりつする段階だんかいでは、鍵かぎ共有きょうゆうプロトコルが実行じっこうされる。このときに共有きょうゆうされた鍵かぎを用もちいて、第だい二にステップで通信つうしんを暗号あんごう化かし、第だい三さんステップで復号ふくごうする。以下いかでは、この3つのステップの概略がいりゃくを述のべる。

SAの確立かくりつ

ピアSは、自身じしんのSPDを参照さんしょうすることで、上位じょういレイヤのプロトコルがRに送おくることを要求ようきゅうしたパケットを廃棄はいきするのか、そのまま送おくるのか、それともIPsecで保護ほごして送おくるのかを決定けっていする。

IPsecで保護ほごして送おくることに決定けっていした場合ばあい、ピアSは、SAの確立かくりつに必要ひつようなデータがすでにSADに存在そんざいするかどうかを確認かくにんする。データが揃そろっていれば、それらのデータをSADから読よみ込こむ。

一方いっぽう、SAの確立かくりつに必要ひつようなデータがSADにすべて揃そろっていない場合ばあいは、SAに必要ひつような情報じょうほうを確立かくりつするプロトコルであるIKE（Internet Key Exchange）をピアRとともに実行じっこうする。2016年ねん現在げんざい、IKEの最新さいしん版ばんはIKEv2である。

IKEは、上述じょうじゅつのように、SAに必要ひつような情報じょうほうを確立かくりつするプロトコルであるが、その中なかでメインとなるのはその名称めいしょうが示しめす通とおり、ピアRとの鍵かぎ共有きょうゆうである。

なお、SAに必要ひつような情報じょうほうを確立かくりつするプロトコルとして、IKEの代かわりにKerberized Internet Negotiation of Keys（英語えいご版ばん） (KINK)やIPSECKEY DNS recordsを使用しようすることもできる^[4]^[5]^[6]^[7]。

暗号あんごう通信つうしん

SAが確立かくりつされた後のち、ピアSとRは、以下いかの2つのうちいずれかのプロトコル用もちいて、通信つうしんを行おこなう（原理げんり的てきには、両方りょうほうのプロトコルを適用てきようすることも可能かのうである）：

AH (Authentication Header) ：IPパケットにメッセージ認証にんしょう子こ(MAC)をつけるが暗号あんごう化かは行おこなわない。IPプロトコル番号ばんごう 51。
ESP (Encapsulated Security Payload) ：IPパケットに認証にんしょう暗号あんごうを施ほどこす。IPプロトコル番号ばんごう 50。

AHやESPの暗号あんごう処理しょりに必要ひつような共通きょうつう鍵かぎは、SAの確立かくりつの際さいに生成せいせいもしくは読よみ込こんだものを用もちいる。

認証にんしょう暗号あんごうは、平文へいぶんの暗号あんごう化かとメッセージ認証にんしょうの両方りょうほうを実行じっこうできる共通きょうつう鍵かぎ暗号あんごう方式ほうしきである。したがって、ESPを用もちいた場合ばあい、パケットの秘匿ひとく性せいと改竄かいざん検知けんちの両方りょうほうが担保たんぽされる。一方いっぽう、AHを用もちいた場合ばあい、改竄かいざん検知けんちしか担保たんぽされない。

通信つうしんは、以下いかの2つのいずれかの動作どうさモードに従したがって行おこなう：

トランスポートモード：パケットデータ部ぶのみを暗号あんごう処理しょりを施ほどこす。
トンネルモード：ヘッダを含ふくめたパケット全体ぜんたいを丸まるごと「データ」として暗号あんごう処理しょりを施ほどこし新あらたなIPヘッダを付加ふか。

トランスポートモードは、主おもに2つのホスト間あいだの通信つうしんで使つかわれ、トンネルモードは、主おもにセキュリティ・ゲートウェイとセキュリティ・ゲートウェイ、およびセキュリティ・ゲートウェイとホストの間あいだの通信つうしんで使つかわれる。

受信じゅしん時じの処理しょり

ピアRは、パケットを受うけ取とり、SADの記載きさいに従したがって、パケットを破棄はきするか否ひかを決きめる。そして、パケットがIPsecのものであれば、パケットを復号ふくごうし（暗号あんごう化かされている場合ばあい）、さらにメッセージ認証にんしょうの検証けんしょうを行おこなった上うえで、上位じょういレイヤーのプロトコルにパケットを渡わたす。パケットがIPsecではなく通常つうじょうのIPのものである場合ばあい、復号ふくごうなどの処理しょりを施ほどこさず、直接ちょくせつ上位じょういレイヤーのプロトコルにパケットを渡わたす。

利用りようする暗号あんごう方式ほうしき

特とくに断ことわりがない限かぎり本節ほんぶしの記述きじゅつはRFC 7321 2.3-2.4節せつで要求ようきゅうレベルがSHOULD以上いじょうのものに基もとづいた。

AHのMACとしてAES-GMACがSHOULD+、AES-XCBC-MAC の出力しゅつりょくを96ビットに切きり詰つめたもの（AES-XCBC-MAC-96）がSHOULDである。NULL（＝MAC無なし）もMAYである。

ESPの認証にんしょう暗号あんごうとしてAES-GCMがSHOULD+である。Encryption-then-Mac (EtM)型がたの認証にんしょう暗号あんごうとしては、暗号あんごう部分ぶぶんはNULL （＝暗号あんごう化かしない）とAES-CBCがMUSTであり、MAC部分ぶぶんはHMAC-SHA1の出力しゅつりょくを96ビットに切きり詰つめたもの(HMAC-SHA1-96)がMUST、鍵かぎ長ちょう128ビットのAES-GMACがSHOULD+、AES-XCBC-MAC の出力しゅつりょくを96ビットに切きり詰つめたもの（AES-XCBC-MAC-96）がSHOULDである。

ただし以上いじょうの要求ようきゅうレベルは過去かこの経緯けいいにも基もとづいており、安全あんぜん性せいや効率こうりつの観点かんてんから見みた場合ばあいはAHにはAES-GMAC、ESPにはAES-GCMを推奨すいしょうしている(RFC 7321 4.1節せつ、4.3節せつ)。

各かくプロトコルの詳細しょうさい

AH

AH (Authentication Header) は、認証にんしょうおよび改竄かいざん防止ぼうし機能きのうを提供ていきょうする。データそのものは暗号あんごう化かされないので、盗聴とうちょう防止ぼうしには利用りようできない。RFC 1826 形式けいしきの AH には再送さいそう防止ぼうし機能きのう (Anti Replay Counter) が無ないが、RFC 2402 では 32 bit の、RFC 4302 では 64 bit のカウンタが付つけられており、過去かこに送信そうしんされたパケットがコピー再送さいそうされても多重たじゅう受信じゅしんしない機能きのうがオプションとして利用りようできる。

*Authentication （AH）ヘッダー* フォーマット（RFC2402/RFC4302形式けいしき）
Offsets	Octet₁₆	0								1								2								3
Octet₁₆	Bit₁₀	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Next Header								ペイロード長なが								予約よやく済ずみ
4	32	Security Parameters Index (SPI)
8	64	順序じゅんじょ番号ばんごう
C	96	Integrity Check Value (ICV) …
…	…	Integrity Check Value (ICV) …

ESP

ESP (Encapsulated Security Payload) はペイロード部ぶを暗号あんごう化かする。正確せいかくには、IP ヘッダ、経路けいろヘッダ、ホップバイホップオプションヘッダを除のぞいた部分ぶぶんが暗号あんごう化かされる。RFC 1827 形式けいしきの ESP には認証にんしょう機能きのうが無ないが、RFC 2406 / RFC 4303 形式けいしきの ESP にはオプションとして「認証にんしょうトレイラー」機能きのうがあり、AH を併用へいようせずとも改竄かいざん防止ぼうし機能きのうを利用りようすることが可能かのうとなっている (ただし保証ほしょうされるのはデータ部分ぶぶんだけで、IP ヘッダ部分ぶぶんの改竄かいざんを検出けんしゅつすることはできない)。また後者こうしゃには AH 同様どうように再送さいそう防止ぼうし機能きのうも追加ついかされている。

RFC 1826 / RFC 1827 形式けいしきの AH/ESP はそれ以降いこうの RFC とヘッダ長ちょうが異ことなるため互換ごかん性せいがない。RFC 4302 / RFC 4303 形式けいしきの 64 bit カウンタは ESN (Extended Sequence Number) とも呼よばれるが、実際じっさいにパケットに付加ふかされるのは下位かい 32 bit だけで、見みた目めは RFC 2402 形式けいしきのパケットと区別くべつが付つかない。ただし認証にんしょうベクタ (ICV) の算出さんしゅつには全ぜん 64 bit が使用しようされるため、RFC 2402 / RFC 2406 形式けいしきの IPsec と RFC 4302 / RFC 4303 形式けいしきの IPsec の間あいだにも直接ちょくせつの互換ごかん性せいはない。RFC 4302 / RFC 4303 仕様しようの IPsec 実装じっそうで RFC 2402 / RFC 2406 形式けいしきと通信つうしんするためには、32 bit の互換ごかんカウンタ使用しようを明示めいじ指定していする必要ひつようがある。

*Encapsulating Security Payload*（ESP）フォーマット（RFC2406/RFC4303形式けいしき）
Offsets	Octet₁₆	0								1								2								3
Octet₁₆	Bit₁₀	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Security Parameters Index (SPI)
4	32	順序じゅんじょ番号ばんごう
8	64	ペイロード
…	…	ペイロード
…	…
…	…									Padding (0-255 octets)
…	…																	Pad Length								Next Header
…	…	Integrity Check Value (ICV) …
…	…	Integrity Check Value (ICV) …

IKE

IKE (Internet Key Exchange protocol) は SAを構築こうちくするのに必要ひつような情報じょうほうの交換こうかんを安全あんぜんに行おこなうプロトコル。IKEv1 (RFC 2409) と IKEv2 (RFC 4306) が定義ていぎされており、2016年ねん現在げんざいの最新さいしん版ばんは後者こうしゃである。

また IKEv1/v2 以外いがいにも Photuris (RFC 2522), KINK (RFC 4430) などの鍵かぎ交換こうかんプロトコルが提案ていあんされている。

IKEv2

IKEv1

IKEv1は Internet Key Exchange protocol version 1 の意味いみであり、UDP ポート番号ばんごう500上じょうで通信つうしんされる鍵かぎ交換こうかんプロトコルである。開発かいはつ時じには ISAKMP/Oakley と呼よばれた過去かこがあり、これはISAKMP(Internet Security Association and Key Management Protocol)プロトコルの上うえで Oakley 鍵かぎ交換こうかん手順てじゅんを実装じっそうしたものという意味いみである。すなわち、IKEv1 は ISAKMP と必かならずしも同おなじものではない。

IKEv1 はフェーズ1、フェーズ2と呼よばれる二に段階だんかいの手順てじゅんで鍵かぎ交換こうかんを行おこなう。まずフェーズ1で IKE プロトコル同士どうしの認証にんしょうと暗号あんごう交換こうかんを行おこない（これをISAKMP SA交換こうかんとも呼よぶ）、フェーズ2で IPsec の適用てきよう条件じょうけんと鍵かぎ情報じょうほうの交換こうかんを行おこなう（IPsec SA 交換こうかんとも呼よぶ）。フェーズ1には Main Mode,Aggressive Mode と呼よばれる2つの手順てじゅんがある。前者ぜんしゃは ISAKMP 仕様しようにおける Identity Protection Exchange 手順てじゅんの呼よび名なであり、後者こうしゃは ISAKMP 仕様しようにおける Aggressive Exchange 手順てじゅんの呼よび名なである。（用語ようご定義ていぎの錯綜さくそうと難解なんかいさも IKE の理解りかいを難むずかしくしている理由りゆうの一ひとつである）。フェーズ2の通信つうしんはフェーズ1において成立せいりつした共有きょうゆう鍵かぎを用もちいて暗号あんごう化かされる。フェーズ2の手順てじゅんは Quick Mode と呼よばれ、これは ISAKMP にはなく IKEv1 で新あらたに定義ていぎされたものである。IKEv1 の規格きかく上じょうでは New Group Mode という手順てじゅんも定義ていぎされているが、実際じっさいには殆ほとんど使つかわれていない。

Oakley 鍵かぎ交換こうかん手順てじゅんは公開こうかい鍵かぎ暗号あんごうを用もちいた鍵かぎ交換こうかん手順てじゅんのアルゴリズムとパラメータのセットをいくつか定さだめたもので、アルゴリズムは大おおきく分わけて Diffie-Hellman鍵かぎ共有きょうゆう (DH-MODP) と楕円だえん曲線きょくせん暗号あんごう (EC2N) の2種しゅがある。鍵かぎ長ちょうは DH-MODP で768,1024,1536,2048,3072,4096,6144,8192bit、EC2N で155,188,163,283,409,571bit が定義ていぎされている。

IKE の通信つうしんを行おこなうノードを IKE ピアと呼よび、IKE 要求ようきゅうを発行はっこうする側がわをイニシエータ、受信じゅしんした側がわをレスポンダと呼よぶ。Oakley のパラメータや IPsec SA の詳細しょうさいはイニシエータ側がわが使用しよう可能かのうな組くみ合あわせを提示ていじし（これをプロポーザルと呼よぶ）、レスポンダ側がわが最もっとも適切てきせつと判断はんだんしたものを選択せんたくして合意ごういを取とるという手順てじゅんを踏ふむ。何なにをもって「適切てきせつ」とみなすかは実装じっそうと設定せっていに依存いぞんし、これを「ポリシー」と呼よぶ場合ばあいもあるが、狭義きょうぎの意味いみにおける IPsec Security Policy とは必かならずしも同おなじニュアンスではないので混同こんどうしないよう注意ちゅういが必要ひつようである。用語ようごの混同こんどうを避さけるため、RFC 4301 においてはこれら「鍵かぎ交換こうかん時じの挙動きょどうを定さだめるパラメータの一覧いちらん」を Peer Authorization Database (PAD) と呼よんでいる。

Aggressive Mode はフェーズ1におけるプロポーザル手順てじゅんの一部いちぶを削減さくげんし、パラメータの一部いちぶを決きめ打うちとすることで Main Mode にくらべパケット交換こうかん回数かいすうを減へらし（3往復おうふく6パケット → 1.5往復おうふく3パケット）通信つうしん効率こうりつを向上こうじょうしている。ただし Main Mode では最後さいごに交換こうかんされる ID パケットが暗号あんごう化かされるのに対たいし、Agressive ModeではID情報じょうほうが暗号あんごう化かされないまま送信そうしんされるので、盗聴とうちょうによるセキュリティホールを招まねきかねないというリスクもある。フェーズ1にどちらのモードを用もちいるかはイニシエータに依存いぞんし、やはりそのネットワークにおけるポリシー (PAD) によって決定けっていされる。

IKEv1 では鍵かぎ交換こうかんと同時どうじに相手あいてピアの認証にんしょうを行おこなう。認証にんしょうアルゴリズムもフェーズ1において提示ていじ-合意ごういのプロセスを踏ふんで実行じっこうされ、認証にんしょう方式ほうしきには事前じぜん鍵かぎ共有きょうゆう方式ほうしき (PSK:Pre Shared Key)、デジタル署名しょめい方式ほうしき (Digital Signatures)、公開こうかい鍵かぎ暗号あんごう方式ほうしき (Public Key Encryption) などがある。

フェーズ2で生成せいせいされる IPsec SA の鍵かぎ情報じょうほうは、原則げんそくとしてフェーズ1で生成せいせいされた共有きょうゆう鍵かぎ情報じょうほうから生成せいせいされる。しかし複数個ふくすうこの IPsec SA をまとめて生成せいせいするような使用しよう法ほうの場合ばあい、全すべての IPsec SA 情報じょうほうが1つの秘密ひみつ情報じょうほうに依存いぞんすることは好このましくない場合ばあいがある。このような場合ばあい、IKEv1 では Perfect Forward Secrecy (PFS) と呼よばれるオプション機能きのうの利用りようが（通信つうしんピア双方そうほうに実装じっそうされていれば）可能かのうである。PFS は個々ここのフェーズ2交換こうかん時じに新あらたな Oakley 鍵かぎ交換こうかんを行おこない、個々ここに異ことなった共有きょうゆう鍵かぎを生成せいせいして IPsec SA の秘密ひみつ鍵かぎ生成せいせい時じに適用てきようするものである。PFSは一般いっぱんに通信つうしん秘匿ひとく性せいを向上こうじょうさせるがピアの処理しょり負荷ふかも向上こうじょうさせるため、これを適用てきようすべきか否ひかもポリシー（あるいはPAD）に応おうじて決定けっていすべきとされている。

なお1回かいのフェーズ1交換こうかんに付随ふずいするフェーズ2の回数かいすうを1回かいかぎりに制限せいげんすることにより、結果けっか的てきに全すべてのフェーズ2生成せいせい鍵かぎを異ことなったものにすることで PFS と同等どうとうの秘匿ひとく性せいを得える実装じっそうもあり、これを Master PFS と呼よぶこともある。この場合ばあい、上記じょうきの「狭義きょうぎのPFS」は Session PFS と呼よばれて区別くべつされる。

このように IKEv1 には数すう多おおくのモードとパラメータとオプションの組くみ合あわせがあり、さらに多おおくの拡張かくちょう仕様しようが存在そんざいする。その中なかには標準ひょうじゅん案あんとして提案ていあんされたもののドラフトを通過つうかできず、正式せいしきな RFC として記載きさいされずに終おわったものも少すくなくない。また IKEv1 仕様しようには難解なんかいで紛まぎらわしい用語ようごが錯綜さくそうしているため、実装じっそう系けいにおいて独自どくじの名前なまえを与あたえている場合ばあいもある（例たとえば Microsoft Windows では IPsec におけるセレクタをフィルタと呼よび、ポリシーをアクションと呼よんでいる)。このため「IETF標準ひょうじゅん」であるはずの IKEv1 同士どうしでも異い機種きしゅ間あいだ接続せつぞくのためにはプロトコルおよび製品せいひん実装じっそうの深遠しんえんな理解りかいが必要ひつようになってしまい、「IPsec でネットワークを組くむ場合ばあいは同おなじメーカーの同おなじ機器ききを使用しようすることが最もっとも確実かくじつ」という慣習かんしゅうを生うむことになってしまった。

IETF は混沌こんとんとしてしまった IKEv1 の整理せいりを諦あきらめ、IKEv2 をもって標準ひょうじゅん化かの仕切しきり直なおしを図はかっている。

IPsec の特徴とくちょう

暗号あんごう化かする層そう

IPsecはネットワーク層そうでセキュリティを実現じつげんするプロトコルであるため、アプリケーションなどの上位じょうい層そうが暗号あんごう化かをサポートしていない場合ばあいでも通信つうしん全体ぜんたいとしてのセキュリティを担保たんぽすることが出来できる。なおセキュリティをネットワーク層そうで実現じつげんしているため、アプリケーション層そうでセキュリティを実現じつげんしているTLSのように暗号あんごう化かがどのプロトコルで行おこなわれているかをユーザーが容易よういに知しることはできない(TLSではwebブラウザに鍵かぎマークが表示ひょうじされるなど一見いっけんしてそれが分わかる表示ひょうじがされる場合ばあいがある)。 PCやスマートフォンなどのコンシューマ端末たんまつでもIPsecを利用りようすることは可能かのうであるが、現状げんじょうは専せん門もんの技術ぎじゅつ者しゃが管理かんりするGateway間あいだでVPNとして利用りようされることが多おおい。IPsecをVPNで利用りようする場合ばあいはIPアドレスを二に重じゅうに付加ふかするトンネルモードが利用りようできるが、IP以外いがいのパケットも伝達でんたつするためL2TPなどのプロトコルと併用へいようされる場合ばあいもある。

柔軟じゅうなんさと設定せっていの複雑ふくざつさ

IPsecはAHの認証にんしょう機能きのう、ESPの暗号あんごう機能きのうを組くみ合あわせて使つかうことができ、AH/ESPそれぞれに様々さまざまなアルゴリズムを指定していすることができる。この柔軟じゅうなんさが IPsec の利点りてんではあるが、設定せってい可能かのうな組くみ合あわせは膨大ぼうだいとなり、通信つうしんする二に点てん間あいだで全すべての設定せっていが一致いっちしていなければ通信つうしんが成立せいりつしない。多た台数だいすう間あいだのIPsec情報じょうほうを手動しゅどうで設定せっていすることは非常ひじょうに手間てまがかかる上うえに、手動しゅどう設定せっていの場合ばあいは同おなじ鍵かぎ情報じょうほうを長期間ちょうきかん使つかい続つづけることになるため、セキュリティ強度きょうどの観点かんてんからも好このましくない。IPsecが上述じょうじゅつしたVPNで利用りようされることが多おおいのはこのためである。この手間てまを軽減けいげんするためネットワークで自動じどう鍵かぎ交換こうかんを行おこなうIKEv1,IKEv2,KINK,Photurisなどのプロトコルも提案ていあんされているが、各かくプロトコルには互換ごかん性せいが無ない。最もっとも普及ふきゅうしているIKEv1でも動作どうさモード、認証にんしょうパラメータ、認証にんしょう方式ほうしき、鍵かぎ交換こうかんアルゴリズム、暗号あんごうアルゴリズム及および認証にんしょうアルゴリズムなど設定せってい項目こうもくの組くみ合あわせは多岐たきに渡わたり、IPsecを使つかいこなすには総そうじて高度こうどな専門せんもん知識ちしきが要求ようきゅうされる。

IPsec が使つかえるシステム

Windows - Windows 2000 / XP は IPv4, IPv6 で利用りよう可能かのうであるが、IPv6はESP暗号あんごう化かに対応たいおうしていない。Windows VistaはIPv4、IPv6で利用りよう可能かのうである。
macOS - KAME由来ゆらいのIPsecが利用りよう可能かのう。OS標準ひょうじゅんのGUIで利用りよう出来できるのはL2TP / IPsecのみである。
BSD - FreeBSD、NetBSDではKAMEで作つくられた実装じっそうが取とり込こまれており、OpenBSDでは独自どくじに実装じっそうを行おこなっている。
Linux - IPv4、IPv6で利用りよう可能かのう。IKEはKAME由来ゆらいのipsec-toolsのracoonを利用りようする。他たにFreeS/WANプロジェクトから派生はせいしたOpenswanとstrongSwanがある。

歴史れきし

1993年ねん12月、ソフトウェアIP暗号あんごう化かプロトコルen:swIPe (protocol)はコロンビア大学ころんびあだいがくとAT&Tベル研究所けんきゅうじょでジョン・ヨアニディス他たによって研究けんきゅうされていた。

クリントン政権せいけんがwhitehouse.govの電子でんしメールをトラスディド・インフォメーション・システムズにホスティングした資金しきんによって(1993年ねん6月がつ1日にちから1995年ねん1月がつ20日はつか)、ウェイ・シューは1994年ねん7月がつ、IPセキュリティの研究けんきゅうに着手ちゃくしゅ、IPプロトコルの機能きのうを拡張かくちょうし、BSDIプラットフォーム上じょうにIPSecを開発かいはつ、すぐにSunOS、HP-UX、その他たUNIXシステムにも移植いしょくした。その成功せいこうにもとづいてウェイはDESとトリプルDESの計算けいさん速度そくど改善かいぜんにも取とり組くんだ。アセンブリ言語げんごによるソフトウェア暗号あんごう化かはIntel 80386アーキテクチャではT1の通信つうしん速度そくどにさえ対応たいおうできなかった。ドイツからCryptoカードを輸出ゆしゅつ、ウェイはさらに今日きょうプラグアンドプレイと呼よばれる、自動じどう化かされたデバイスドライバも開発かいはつし、ハードウェアのCryptoと統合とうごうした。T1を超こえるスループットを実現じつげんした後のち、ウェイ・シューはついに実用じつように耐たえる商品しょうひんを作成さくせい、著名ちょめいなGauntletファイアーウォールの一部いちぶとしてリリースした。1994年ねん12月、米国べいこくの東海岸ひがしかいがん、西海岸にしかいがんにある遠隔えんかく拠点きょてんを結むすぶ通信つうしんを暗号あんごう化かするために初はじめて本番ほんばん導入どうにゅうされた。

一方いっぽう、IPカプセル化かセキュリティ・ペイロード (ESP) ^[8]はDARPAの資金しきんによる研究けんきゅうプロジェクトの一部いちぶとしてアメリカ海軍かいぐん調査ちょうさ研究所けんきゅうじょで研究けんきゅうされ、1993年ねん12月、IETFのSIPP作業さぎょう部会ぶかいによってSIPPに対たいするセキュリティ拡張かくちょうとしてドラフトが公開こうかいされた^[9]。このESPはもともとISOのネットワーク層そうセキュリティプロトコル（NLSP）ではなく、アメリカ国防総省こくぼうそうしょうのSP3Dプロトコルから派生はせいしたものだった。SP3Dプロトコルの仕様しようはNISTにより公開こうかいされたが、アメリカ国防総省こくぼうそうしょうのセキュアデータ・ネットワークシステム・プロジェクトにより設計せっけいされたものだった。セキュリティ認証にんしょうヘッダ（AH）の一部いちぶは、以前いぜんのSimple Network Management Protocol(SNMP)バージョン2の認証にんしょうのためのIETF標準ひょうじゅん策定さくてい作業さぎょうから派生はせいしたものである。

1995年ねん、IETFのIPsec作業さぎょう部会ぶかいはオープンかつ自由じゆうに利用りようできるバージョンのプロトコル作成さくせいを開始かいし、セキュアデータ・ネットワークシステム(SDNS)プロジェクトに関かんするアメリカ国家こっか安全あんぜん保障ほしょう局きょくの契約けいやくの下したで開発かいはつされた。SDNSプロジェクトが定義ていぎしたセキュリティプロトコル・レイヤー3(SP3)はNISTによって公開こうかいされ、ISOのネットワーク層そうセキュリティ・プロトコル(NLSP)^[10]の基礎きそにもなった。SP3の鍵かぎ管理かんりは鍵かぎ管理かんりプロトコル(KMP)によって提供ていきょうされ、これらに続つづくIPsec委員いいん会かいの作業さぎょうのベースラインを提供ていきょうした。

IPsecは公式こうしきにはインターネット・エンジニアリング・タスクフォース(IETF)のRequest for Comments(RFC)の一連いちれんの文書ぶんしょとして標準ひょうじゅん化かされ、さまざまなコンポーネントや拡張かくちょうに対応たいおうしている。その文書ぶんしょでプロトコルの名称めいしょうはIPsecと表記ひょうきすると定さだめられている。^[11]

外部がいぶリンク

IETF ipsec WG ("IP Security Protocol" Working Group)
Computer Security - Curlie（英語えいご）
IETFの全すべてのアクティブなセキュリティWG
- IETF ipsecme WG ("IP Security Maintenance and Extensions" Working Group)
- IETF btns WG ("Better-Than-Nothing Security" Working Group)]

脚注きゃくちゅう

^ Stallings, William (2016). Foundations of modern networking : SDN, NFV, QoE, IoT, and Cloud. Florence Agboma, Sofiene Jelassi. Indianapolis, Indiana. ISBN 978-0-13-417547-8. OCLC 927715441
^ 『RFC6434』「Previously, IPv6 mandated implementation of IPsec and recommended the key management approach of IKE. This document updates that recommendation by making support of the IPsec Architecture [RFC4301] a SHOULD for all IPv6 nodes.」
^ RFC6071等とうの記述きじゅつに使用しようされている。
^ Harkins, D.; Carrel, D. (November 1998). The Internet Key Exchange (IKE) (英語えいご). IETF. doi:10.17487/RFC2409. RFC 2409。
^ Kaufman, C. (ed.). IKE Version 2 (英語えいご). IETF. doi:10.17487/RFC4306. RFC 4306。
^ Sakane, S.; Kamada, K.; Thomas, M.; Vilhuber, J. (November 1998). Kerberized Internet Negotiation of Keys (KINK) (英語えいご). IETF. doi:10.17487/RFC4430. RFC 4430。
^ Richardson, M. (February 2005). A Method for Storing IPsec Keying Material in DNS (英語えいご). IETF. doi:10.17487/RFC4025. RFC 4025。
^ “SIPP Encapsulating Security Payload”. IETF SIPP Working Group (1993年ねん). 2017年ねん1月がつ31日にち閲覧えつらん。
^ “Draft SIPP Specification”. IETF. p. 21 (1993年ねん). 2017年ねん1月がつ31日にち閲覧えつらん。
^ http://www.toad.com/gnu/netcrypt.html
^ “RFC4301: Security Architecture for the Internet Protocol”. Network Working Group of the IETF. p. 4 (December 2005). 2020年ねん10月がつ27日にち閲覧えつらん。 “The spelling "IPsec" is preferred and used throughout this and all related IPsec standards. All other capitalizations of IPsec [...] are deprecated.”

この項目こうもくは、コンピュータに関連かんれんした書かきかけの項目こうもくです。この項目こうもくを加筆かひつ・訂正ていせいなどしてくださる協力きょうりょく者しゃを求もとめています（PJ:コンピュータ/P:コンピュータ）。

[1] Stallings, William (2016). Foundations of modern networking : SDN, NFV, QoE, IoT, and Cloud. Florence Agboma, Sofiene Jelassi. Indianapolis, Indiana. ISBN 978-0-13-417547-8. OCLC 927715441

[2] 『RFC6434』「Previously, IPv6 mandated implementation of IPsec and recommended the key management approach of IKE. This document updates that recommendation by making support of the IPsec Architecture [RFC4301] a SHOULD for all IPv6 nodes.」

[3] RFC6071等とうの記述きじゅつに使用しようされている。

[rfc2409-4] Harkins, D.; Carrel, D. (November 1998). The Internet Key Exchange (IKE) (英語えいご). IETF. doi:10.17487/RFC2409. RFC 2409。

[rfc4306-5] Kaufman, C. (ed.). IKE Version 2 (英語えいご). IETF. doi:10.17487/RFC4306. RFC 4306。

[rfc4430-6] Sakane, S.; Kamada, K.; Thomas, M.; Vilhuber, J. (November 1998). Kerberized Internet Negotiation of Keys (KINK) (英語えいご). IETF. doi:10.17487/RFC4430. RFC 4430。

[{{IETF_RFC|4025}}-7] Richardson, M. (February 2005). A Method for Storing IPsec Keying Material in DNS (英語えいご). IETF. doi:10.17487/RFC4025. RFC 4025。

[8] “SIPP Encapsulating Security Payload”. IETF SIPP Working Group (1993年ねん). 2017年ねん1月がつ31日にち閲覧えつらん。

[9] “Draft SIPP Specification”. IETF. p. 21 (1993年ねん). 2017年ねん1月がつ31日にち閲覧えつらん。

[10] ttp://www.toad.com/gnu/netcrypt.html

[11] “RFC4301: Security Architecture for the Internet Protocol”. Network Working Group of the IETF. p. 4 (December 2005). 2020年ねん10月がつ27日にち閲覧えつらん。 “The spelling "IPsec" is preferred and used throughout this and all related IPsec standards. All other capitalizations of IPsec [...] are deprecated.”

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]