IKEの情報 （イケ）
芸能人・有名人Wiki検索（誕生日、出身地）

白部真一: NIKE「西武ライオンズ」、「鹿島アントラーズ新ユニ発表」、「S.T.H」

池真理子: （名字〈IKE>、及びアイゼンハワー米大統領のニックネームから）

岩永洋昭: NIKE・バスケットボールカタログ（2004年）

谷佳樹: GEKIIKE本公演第7回『月下燦然ノ星-帝都奇譚-』（2015年10月15日 - 26日、シアターグリーン Box in Box）- 宮沢理一 役

北尾茂久: STRIKES BACK結成

藤原祐規: 4STRIKE（2012年10月10日 - 20日、新宿FACE/10月23日 - 24日、心斎橋BIGCAT）- RIKU 役

かかずゆみ: ハングリーハート WILD STRIKER（古木リエ）

長谷和征: 2010年 9月 - IKEMEN NAGOYA「BOYS AND MEN」入隊。

嬉野秋彦: THE KING OF FIGHTERS 2000 〜STRIKERS STRIKE BACK〜 ISBN 4-7577-0348-1 2001年3月

松山鷹志: ストリートファイターIII 3rd STRIKE -Fight for the Future-（オロ）

安田朗: ストリートファイターIII 3rd STRIKE -Fight for the Future-

尾崎礼香: フォーエスエンターテイメント　TOMOIKEプロデュース「あの壁の絵～キタナイ涙2022～」（2022年6月17日 - 19日　下北沢 小劇場B1）日比野カレン（謎の女）　役

愛川こずえ: 2010年5月からラジオ番組『THUNDER STRIKES』の週替わりコーナーでDJを務めていた。

マイク＝シノダ: 同年のサマーソニックには、MIKE SHINODA of LINKIN PARK名義で、8月18日大阪（OCEAN STAGE）、8月19日東京（MARINE STAGE）に出演した。

葉山たけし: 高原由妃「FEEL LIKE MAKING LOVE」

岡野昭仁: 2018年6月23日：豊洲 MIFA Football Parkで開催されたフットサルトーナメント『NIKE FTBL CUP』のLegendチームにKEIGO（FLOW）と共にスペシャルゲストとして参加。

山下晃和: 枻出版 HONDA　BIKES　

天野亜希子: BIKERS PARADISE Sweet Emotion　横浜エフエム放送

駒澤晴信: IKEA船橋店

赤塚不二夫: マンガ劇画展 赤塚ギャグはここで生まれる!（1970年11月4日 - 、池袋・IKEBUKURO東武） マンガ劇画展の一環としてのイベント 原画展のほか、赤塚とフジオ・プロスタッフによる漫画製作の実演も披露

松本美千穂: GUN CRAZY Episode4 『用心棒の鎮魂歌（レクイエム）』THE MAGNIFICENT FIVE STRIKE （2002年公開）

加奈崎芳太郎: 加奈崎芳太郎 with IMAIKE ACCIDENTS(2018年11月)

今谷皆美: “源平繚乱絵巻 -GIKEI- OPムービー”. インレ. 2020年10月26日閲覧。

若野桂: 1999年 - 2000年、NIKEバスケットボールのアジアおよび北米における「PLAYER'S DElIGHT」キャンペーンのアートワーク担当及び企画参加。

新木宏典: BAYFM CREATORS BANK～LIKE LABO～(2022年4月19日・26日、bayfm)

石川大介: ハングリーハート WILD STRIKER（おりも）

松山鷹志: ハングリーハート WILD STRIKER（村上監督）

塩谷哲: 1996年にSING LIKE TALKINGの佐藤竹善とのユニット『SALT&SUGAR』を結成。

日野聡: 弱虫ペダル SPARE BIKE（新開隼人） - 劇場先行上映

成清加奈子: IKENAI!いんびテーション

IKEのプロフィール Wikipedia（ウィキペディア）

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

IPsecは、IPv6では必須とされた時期があり、専用の拡張ヘッダが定義されている。一方、IPv4では、利用可能だが必須ではなく、IP ヘッダオプションを利用する。

IPsecの規格はIETFの ipsec wg にて策定し、RFCとして公開している。IETF ではIPsecにバージョン番号を与えていないが、非公式に下記のバージョンが与えられており、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つのステップの概略を述べる。

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を使用することもできる。

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

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 の互換カウンタ使用を明示指定する必要がある。

IKE (Internet Key Exchange protocol) は SAを構築するのに必要な情報の交換を安全に行うプロトコル。IKEv1 (RFC 2409) と IKEv2 (RFC 4306) が定義されており、2016年現在の最新版は後者である。

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

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はネットワーク層でセキュリティを実現するプロトコルであるため、アプリケーションなどの上位層が暗号化をサポートしていない場合でも通信全体としてのセキュリティを担保することが出来る。なおセキュリティをネットワーク層で実現しているため、アプリケーション層でセキュリティを実現している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を使いこなすには総じて高度な専門知識が要求される。

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) はDARPAの資金による研究プロジェクトの一部としてアメリカ海軍調査研究所で研究され、1993年12月、IETFのSIPP作業部会によってSIPPに対するセキュリティ拡張としてドラフトが公開された。このESPはもともとISOのネットワーク層セキュリティプロトコル（NLSP）ではなく、アメリカ国防総省のSP3Dプロトコルから派生したものだった。SP3Dプロトコルの仕様はNISTにより公開されたが、アメリカ国防総省のセキュアデータ・ネットワークシステム・プロジェクトにより設計されたものだった。セキュリティ認証ヘッダ（AH）の一部は、以前のSimple Network Management Protocol(SNMP)バージョン2の認証のためのIETF標準策定作業から派生したものである。

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

IPsecは公式にはインターネット・エンジニアリング・タスクフォース(IETF)のRequest for Comments(RFC)の一連の文書として標準化され、さまざまなコンポーネントや拡張に対応している。その文書でプロトコルの名称はIPsecと表記すると定められている。

RFC 1829: The ESP DES-CBC Transform

RFC 2403: The Use of HMAC-MD5-96 within ESP and AH

RFC 2404: The Use of HMAC-SHA-1-96 within ESP and AH

RFC 2405: The ESP DES-CBC Cipher Algorithm With Explicit IV

RFC 2410: The NULL Encryption Algorithm and Its Use With IPsec

RFC 2451: The ESP CBC-Mode Cipher Algorithms

RFC 2857: The Use of HMAC-RIPEMD-160-96 within ESP and AH

RFC 3526: More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)

RFC 3602: The AES-CBC Cipher Algorithm and Its Use with IPsec

RFC 3686: Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)

RFC 3947: Negotiation of NAT-Traversal in the IKE

RFC 3948: UDP Encapsulation of IPsec ESP Packets

RFC 4106: The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)

RFC 4301: Security Architecture for the Internet Protocol

RFC 4302: IP Authentication Header

RFC 4303: IP Encapsulating Security Payload

RFC 4304: Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)

RFC 4307: Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)

RFC 4308: Cryptographic Suites for IPsec

RFC 4309: Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)

RFC 4543: The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH

RFC 4555: IKEv2 Mobility and Multihoming Protocol (MOBIKE)

RFC 4806: Online Certificate Status Protocol (OCSP) Extensions to IKEv2

RFC 4868: Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec

RFC 4945: The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX

RFC 5282: Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol

RFC 5386: Better-Than-Nothing Security: An Unauthenticated Mode of IPsec

RFC 5529: Modes of Operation for Camellia for Use with IPsec

RFC 5685: Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)

RFC 5723: Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption

RFC 5857: IKEv2 Extensions to Support Robust Header Compression over IPsec

RFC 5858: IPsec Extensions to Support Robust Header Compression over IPsec

RFC 7296: Internet Key Exchange Protocol Version 2 (IKEv2)

RFC 7321: Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)

RFC 7383: Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation

RFC 7427: Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)

RFC 7634: ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec

RFC 4478: Repeated Authentication in Internet Key Exchange (IKEv2) Protocol

RFC 2367: PF_KEY Interface

RFC 2412: The OAKLEY Key Determination Protocol

RFC 3706: A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers

RFC 3715: IPsec-Network Address Translation (NAT) Compatibility Requirements

RFC 4621: Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol

RFC 4809: Requirements for an IPsec Certificate Management Profile

RFC 5387: Problem and Applicability Statement for Better-Than-Nothing Security (BTNS)

RFC 5856: Integration of Robust Header Compression over IPsec Security Associations

RFC 5930: Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol

RFC 6027: IPsec Cluster Problem Statement

RFC 6071: IPsec and IKE Document Roadmap

RFC 6467: Secure Password Framework for Internet Key Exchange Version 2 (IKEv2)

RFC 5406: Guidelines for Specifying the Use of IPsec Version 2

RFC 1825: Security Architecture for the Internet Protocol (obsoleted by RFC 2401)

RFC 1826: IP Authentication Header (obsoleted by RFC 2402)

RFC 1827: IP Encapsulating Security Payload (ESP) (obsoleted by RFC 2406)

RFC 1828: IP Authentication using Keyed MD5 (historic)

RFC 2401: Security Architecture for the Internet Protocol (IPsec overview) (obsoleted by RFC 4301)

RFC 2406: IP Encapsulating Security Payload (ESP) (obsoleted by RFC 4303 and RFC 4305)

RFC 2407: The Internet IP Security Domain of Interpretation for ISAKMP (obsoleted by RFC 4306)

RFC 2409: The Internet Key Exchange (obsoleted by RFC 4306)

RFC 4305: Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) (obsoleted by RFC 4835)

RFC 4306: Internet Key Exchange (IKEv2) Protocol (obsoleted by RFC 5996)

RFC 4718: IKEv2 Clarifications and Implementation Guidelines (obsoleted by RFC 7296)

RFC 4835: Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) (obsoleted by RFC 7321)

RFC 5996: Internet Key Exchange Protocol Version 2 (IKEv2) (obsoleted by RFC 7296)

RFC 6379: Suite B Cryptographic Suites for IPsec

RFC 6380: Suite B Profile for Internet Protocol Security (IPsec)

Virtual Private Network

情報セキュリティ

NAT traversal

日和見暗号化

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. https://www.worldcat.org/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 (2005年12月). 2020年10月27日閲覧。 “The spelling "IPsec" is preferred and used throughout this and all related IPsec standards. All other capitalizations of IPsec [...] are deprecated.”

表

話

編

歴

SSTP（英語版）

IPsec

L2TP

L2TPv3（英語版）

PPTP

Split tunneling（英語版）

DTLS

SSL/TLS

tcpcrypt（英語版）

L2F

DirectAccess（英語版）

FreeLAN（英語版）

FreeS/WAN

Libreswan（英語版）

n2n（英語版）

OpenConnect（英語版）

OpenIKED（英語版）

Openswan

OpenVPN

SoftEther VPN

strongSwan

tcpcrypt（英語版）

Tinc（英語版）

VTun（英語版）

WireGuard

Shadowsocks

Avast SecureLine VPN（英語版）

Check Point VPN-1

Cisco Systems VPN Client（英語版）

CyberGhost VPN

ExpressVPN

HideMyAss!（英語版）

Hola（英語版）

LogMeIn Hamachi

Microsoft Forefront Unified Access Gateway（英語版）

NordVPN

Private Internet Access（英語版）

Proton VPN

PureVPN（英語版）

SaferVPN（英語版）

TunnelBear（英語版）

VPN.ht（英語版）

コンテンツフィルタリング

ディープ・コンテンツ・インスペクション（英語版）

ディープ・パケット・インスペクション

IPアドレスブロッキング（英語版）

ネットワーク・エニュメレーション（英語版）

ステートフル・ファイアウォール（英語版）

TCPリセット攻撃（英語版）

VPNブロッキング（英語版）

ドイツ

イスラエル

アメリカ

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

IPsec

トンネリング

暗号化プロトコル

インターネット層プロトコル

ネットワーク層プロトコル

コンピュータ・ネットワーク・セキュリティ

セキュア通信

RFC

VPN

書きかけの節のある項目

Curlieリンクを使用している記事

GND識別子が指定されている記事

J9U識別子が指定されている記事

LCCN識別子が指定されている記事

すべてのスタブ記事

コンピュータ関連のスタブ項目