{"schema":"article/1","id":"art_3db49be497","owner":"u_owner","status":"published","visibility":"public","version":1,"title":"鍵の材料を先に交換し、守れる状態にしてから相手を確かめる","rawTitle":"鍵の材料を先に交換し、守れる状態にしてから相手を確かめる","slug":"nw-basics-12-ike","file":"ネットワーク_12_IKE","relPath":"content/published/ネットワーク_12_IKE.md","aliases":[],"kind":"published","area":"tech","topic":"ネットワーク","category":"ネットワーク","tags":["ネットワーク","ike","ipsec","vpn","concept"],"summary":"図 11 が使う取り決めを、まだ守られていない道でどうやって作るか。守る通信が来るまで打合せは始まらず、合意するまでデータ用の取り決めは 1 本も無い","date":"2026-09-14","updated":"2026-09-14","links":["nw-basics-index","nw-basics-00-three-layers","nw-basics-11-ipsec","nw-basics-09-acl","nw-basics-10-gre","nw-basics-13-ospf"],"blocks":[{"id":"blk_c0753f","type":"paragraph","markdown":"図 11 では、送信用の SA に書かれた方式と鍵で暗号化する、と書きました。","text":"図 11 では、送信用の SA に書かれた方式と鍵で暗号化する、と書きました。","line":2,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_f83500","type":"paragraph","markdown":"その方式と鍵がどこから来るかには触れていません。\nまだ封のできていない道で、相手と方式を決め、鍵の材料をやり取りするしかありません。\nこの記事は、図 7 で挙げた 3 つの問題を直接解く図ではなく、図 11 が使う取り決めを作る段を扱います。","text":"その方式と鍵がどこから来るかには触れていません。\nまだ封のできていない道で、相手と方式を決め、鍵の材料をやり取りするしかありません。\nこの記事は、図 7 で挙げた 3 つの問題を直接解く図ではなく、図 11 が使う取り決めを作る段を扱います。","line":4,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_bb713c","type":"paragraph","markdown":"この連載は、ネットワークの言葉を 3 つの層に置いて読みます。\nもの（物理か論理か）、結びつき（人が設定で付ける手動か、機器が学習する自動か、製造時に決まる固定か）、通信フロー（1 本の通信がそれらを順に通る道筋）の 3 つです。","text":"この連載は、ネットワークの言葉を 3 つの層に置いて読みます。\nもの（物理か論理か）、結びつき（人が設定で付ける手動か、機器が学習する自動か、製造時に決まる固定か）、通信フロー（1 本の通信がそれらを順に通る道筋）の 3 つです。","line":8,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_34ba84","type":"heading","depth":2,"markdown":"## 登場するもの","text":"登場するもの","line":11,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_e11bca","type":"heading","depth":4,"markdown":"#### 管理用の SA","text":"管理用の SA","line":13,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_f8322c","type":"paragraph","markdown":"論理のもので、自動でできます。\n打合せそのものを守るための取り決めです。\n相手 1 つにつき 1 つです。","text":"論理のもので、自動でできます。\n打合せそのものを守るための取り決めです。\n相手 1 つにつき 1 つです。","line":15,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_26ae48","type":"heading","depth":4,"markdown":"#### データ用の SA","text":"データ用の SA","line":19,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_3597ff","type":"paragraph","markdown":"論理のもので、自動でできます。\n図 11 で実際にデータを包むのに使う取り決めです。\n送信用と受信用の 2 本できます。","text":"論理のもので、自動でできます。\n図 11 で実際にデータを包むのに使う取り決めです。\n送信用と受信用の 2 本できます。","line":21,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_9e70a2","type":"heading","depth":4,"markdown":"#### 事前共有鍵","text":"事前共有鍵","line":25,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_e60444","type":"paragraph","markdown":"論理のもので、人が書きます。\n相手の IP と対で登録する合言葉です。\n両側に同じ文字列を設定します。\n値は図にも記録にも書きません。","text":"論理のもので、人が書きます。\n相手の IP と対で登録する合言葉です。\n両側に同じ文字列を設定します。\n値は図にも記録にも書きません。","line":27,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_2b37a4","type":"heading","depth":4,"markdown":"#### 打合せの通信そのもの","text":"打合せの通信そのもの","line":32,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_ef9c01","type":"paragraph","markdown":"UDP のポート番号 500 を使います。\n間に NAT があるときは 4500 も使います。\n図 11 のデータのほうはポート番号を持ちません。","text":"UDP のポート番号 500 を使います。\n間に NAT があるときは 4500 も使います。\n図 11 のデータのほうはポート番号を持ちません。","line":34,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_118c7a","type":"heading","depth":2,"markdown":"## 結びつき","text":"結びつき","line":38,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_5c0a69","type":"list","markdown":"- 事前共有鍵 ⇄ 相手の IP は手動です。両側で同じ文字列でないと、フェーズ 1 で止まります。\n- 方式の候補（暗号・ハッシュ・DH グループ）⇄ 相手は手動です。両側に共通のものが 1 つも無ければ、合意に至りません。\n- 守る通信の並び ⇄ 相手も手動です。ここが食い違うと、フェーズ 1 は上がるのにデータが通りません。\n- SA ⇄ 打合せの結果は自動です。人が SA を直接書くことはありません。","text":"事前共有鍵 ⇄ 相手の IP は手動です。両側で同じ文字列でないと、フェーズ 1 で止まります。方式の候補（暗号・ハッシュ・DH グループ）⇄ 相手は手動です。両側に共通のものが 1 つも無ければ、合意に至りません。守る通信の並び ⇄ 相手も手動です。ここが食い違うと、フェーズ 1 は上がるのにデータが通りません。SA ⇄ 打合せの結果は自動です。人が SA を直接書くことはありません。","line":40,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_df21fc","type":"heading","depth":2,"markdown":"## 通信フロー","text":"通信フロー","line":45,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_a065d2","type":"paragraph","markdown":"① 守る通信、つまり外向きの口に貼った並びに一致するパケットが、ルータ 1 に届きます。図 11 の ① と同じパケットです。","text":"① 守る通信、つまり外向きの口に貼った並びに一致するパケットが、ルータ 1 に届きます。図 11 の ① と同じパケットです。","line":47,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_5cef00","type":"paragraph","markdown":"② ルータ 1 は「封をすべき通信なのに、使える取り決めが 1 本も無い」と気づきます。そこで ① は落とし、相手の外側 IP へ打合せを持ちかけます。初回の通信が失敗するのはこのためです。","text":"② ルータ 1 は「封をすべき通信なのに、使える取り決めが 1 本も無い」と気づきます。そこで ① は落とし、相手の外側 IP へ打合せを持ちかけます。初回の通信が失敗するのはこのためです。","line":49,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_a7e0cc","type":"paragraph","markdown":"③ フェーズ 1。まず使える方式の候補を出し合い、鍵の材料を交換します。その材料でできた鍵で中身を守れるようになってから、相手が本物かを確かめます。確かめ方は事前共有鍵です。合意すると、管理用の SA が 1 つできます。","text":"③ フェーズ 1。まず使える方式の候補を出し合い、鍵の材料を交換します。その材料でできた鍵で中身を守れるようになってから、相手が本物かを確かめます。確かめ方は事前共有鍵です。合意すると、管理用の SA が 1 つできます。","line":51,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_5871f9","type":"paragraph","markdown":"④ フェーズ 2。その守られた中で、守る通信の範囲とデータを守る方式を決めます。合意すると、データ用の SA が送信用・受信用の 2 本できます。","text":"④ フェーズ 2。その守られた中で、守る通信の範囲とデータを守る方式を決めます。合意すると、データ用の SA が送信用・受信用の 2 本できます。","line":53,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_b51c82","type":"paragraph","markdown":"⑤ ここでやっと ① のパケットが ESP で包まれて流れます（図 11 の ② から ⑤）。SA には寿命があり、切れる前に打合せをやり直します。","text":"⑤ ここでやっと ① のパケットが ESP で包まれて流れます（図 11 の ② から ⑤）。SA には寿命があり、切れる前に打合せをやり直します。","line":55,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_859041","type":"heading","depth":2,"markdown":"## 図 12","text":"図 12","line":57,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_4a3ad1","type":"paragraph","markdown":"図の上半分が構成図と 2 段階の打合せ・切り分け、下半分が設定と増えるもの・通信の中身の推移です。","text":"図の上半分が構成図と 2 段階の打合せ・切り分け、下半分が設定と増えるもの・通信の中身の推移です。","line":59,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_a819a1","type":"html","markdown":"\n \n IKE：封をする前の打合せ。方式と鍵を、まだ守られていない道で決める\n 図 7 の 3 つの問題を直接解く図ではなく、図 11（問題 3 の解）が使う取り決めを作る段。フェーズ 1 で管理用の SA、その中でフェーズ 2 がデータ用の SA を 2 本作る\n \n 支店（自分のもの）\n \n インターネット（他人のもの）\n \n データセンター（自分のもの）\n \n PC-A\n 192.168.10.10\n GW 192.168.10.1\n \n \n ルータ 1\n Gi0 192.168.10.1\n Gi1 203.0.113.10\n （グローバル IP）\n Gi0\n Gi1\n \n \n ISP-1\n 他人の\n ルータ\n \n \n ISP-2\n 他人の\n ルータ\n \n \n ISP-3\n 他人の\n ルータ\n \n \n ルータ 2\n Gi0 198.51.100.20\n （グローバル IP）\n Gi1 192.168.3.1\n Gi0\n Gi1\n \n \n PC-C\n 192.168.3.10\n GW 192.168.3.1\n \n crypto map\n Gi1 に貼る（手動）\n \n crypto map\n Gi0 に貼る（手動）\n \n \n 打合せ（IKE）。まだ封のできていない道で、方式と鍵を決める\n \n \n 3\n 4\n 打合せもこの中を通る。だから「相手が本物か」を確かめる段が要る\n 合意ができるまで、データ用の取り決め（SA）は 1 本も無い\n \n 1\n 2\n \n 5\n SA が無い\n 合意できてから、初めてデータが ESP で流れる（図 11）\n ③④ の中身：打合せは 2 段階に分かれている\n \n \n \n \n ルータ 1\n ルータ 2\n ③ フェーズ 1：管理用の取り決めを作る（メインモードの段取り）\n 使える方式の候補を出す → 鍵の材料を交換する → その上で相手が本物か確かめる\n \n 合意。管理用の SA が 1 つできる。ここから先の打合せは守られる\n \n ④ フェーズ 2：データ用の取り決めを作る\n 守る通信の範囲と、データを守る方式を決める（もう読まれない道の中で）\n \n 合意。データ用の SA が 送信用・受信用 の 2 本できる\n \n ⑤ ここでやっと、①のパケットが ESP で包まれて流れる\n \n \n 打合せが始まるきっかけ\n 口に貼っただけでは、打合せは\n まだ始まらない\n 守る通信の並びに一致する\n パケットが実際に来てから、\n 相手に声をかける\n \n 勉強会の観察：初回の通信を\n するまで状態は ACTIVE に\n ならず、Active SAs も 0 のまま\n （この動きの一次資料は未確認）\n \n つながらないときの切り分け\n セッションが DOWN のまま ＝ フェーズ 1 が合っていない\n 　方式の候補・事前共有鍵・相手の IP のどれかが両側で違う\n フェーズ 1 は上がるのに通らない ＝ フェーズ 2 が合っていない\n 　守る通信の並び（ACL）が両側で食い違っている\n どちらも「両側で同じものを人が設定する」でしか合わない\n \n 新旧（IKEv2 の表で今どれを使うか）\n IKEv1 は Historic（役割を終えた文書）に移された\n 今の現行は IKEv2。段取りの呼び名も変わっている\n DH グループ 1 は MUST NOT（使ってはいけない）\n グループ 2 は SHOULD NOT、グループ 14 が MUST\n 勉強会の group 1 は、この表では「使ってはいけない」側\n フロー\n ① 守る通信（外向きの口に貼った並びに一致するパケット）が、ルータ 1 に届く。図 11 の ① と同じパケット\n ② ルータ 1 は「封をすべき通信なのに、使える取り決め（SA）が 1 本も無い」と気づく。そこで ① は落とし、相手の外側 IP へ打合せを持ちかける\n ③ フェーズ 1。まず使える方式の候補を出し合い、鍵の材料を交換する。その材料でできた鍵で中身を守れるようになってから、相手が本物かを確かめる\n 確かめ方は事前共有鍵（両側に同じ文字列を人が手で設定したもの）。合意すると、管理用の SA が 1 つできる\n ④ フェーズ 2。その守られた中で、データ用の取り決めの中身（守る通信の範囲・暗号の方式）を決める\n 合意すると、データ用の SA が 送信用・受信用 の 2 本できる（片道に 1 本ずつ）\n ⑤ ここでやっと ① のパケットが ESP で包まれて流れる（図 11 の ②〜⑤）。SA には寿命があり、切れる前に打合せをやり直す\n 増えたもの\n 管理用の SA（論理・自動）：打合せそのものを守るための取り決め。1 つの相手につき 1 つ\n 事前共有鍵（論理・手動）：相手の IP と対で登録する合言葉。両側に同じ文字列を人が設定する\n 3 層で見ると\n もの：管理用の SA・データ用の SA（どちらも論理）・事前共有鍵（論理）・UDP ポート番号 500\n 結びつき：事前共有鍵 ⇄ 相手の IP（手動・両側で同じ文字列）／方式の候補 ⇄ 相手（手動・両側で合わないと決まらない）／SA は合意の結果できる（自動）\n フロー：図 11 の ②「送信用の SA で暗号化する」の前に、その SA を作る往復が入る。通信が来るまで始まらない\n\n設定と、打合せが進むにつれて増えるもの（③④ の番号は上のフローに対応。青字）\n \n ルータ 1: フェーズ 1 の設定（手動）\n 相手を確かめる方法：事前共有鍵\n 暗号の方式・ハッシュの方式\n DH グループ番号（鍵の材料の作り方）\n ③この 4 つが両側で合わないと先へ進まない\n \n ルータ 1: 事前共有鍵の登録（手動）\n 相手の IP：198.51.100.20\n その相手に使う合言葉：両側で同じ文字列\n （値そのものは図にも記録にも書かない）\n \n ルータ 1: フェーズ 2 の設定（手動）\n 守る通信の並び（図 9 の ACL）\n データを守る暗号の組合せ\n 相手：198.51.100.20\n ④守る通信の並びが両側で食い違うと通らない\n \n 打合せの前（②の時点）\n 管理用の SA：0\n データ用の SA：0\n セッションの状態：DOWN\n この状態で ① のパケットが来て、③ が始まる\n \n フェーズ 1 の後\n ③管理用の SA：1（相手 1 つにつき 1 つ）\n データ用の SA：0\n まだデータは 1 バイトも流れない\n \n フェーズ 2 の後（⑤ が流れる状態）\n 管理用の SA：1\n ④データ用の SA：2（送信用・受信用）\n 勉強会の表示 Active SAs: 2 はこの 2 本\n 寿命が切れる前に、また打合せが起きる\n通信の中身の推移（フローごとのフレーム／パケット）\n ① 守る通信が届く（図 11 の ① と同じ。これが打合せのきっかけ）\n \n 宛先 MAC\n MAC R1-Gi0\n \n 送信元 MAC\n MAC A\n \n 宛先 IP\n 192.168.3.10\n \n 送信元 IP\n 192.168.10.10\n \n データ\n ping\n \n フレーム＝全部。ただしスイッチが見るのは MAC とタグの部分だけ\n \n パケット＝この部分。ルータはここ（IP）を見る\n ② ルータ 1 の中\n 守る通信の並びには一致した。しかし使えるデータ用の SA が無い。そこで ① は落とし（初回の通信が失敗するのはこのため）、相手へ打合せの通信を出す\n ③ フェーズ 1 の往復（ルータ 1 → ルータ 2。中身はまだ守られていない）\n \n 宛先 MAC\n MAC ISP-1\n \n 送信元 MAC\n MAC R1-Gi1\n \n 宛先 IP\n 198.51.100.20\n \n 送信元 IP\n 203.0.113.10\n \n UDP ポート番号\n 500\n \n データ\n 方式の候補\n ③ の途中から\n 鍵の材料を交換し終えた後は、同じ UDP ポート番号 500 のまま、中身が守られた状態になる。相手が本物かを確かめるやり取りは、その守られた中で行う\n ④ フェーズ 2 の往復（同じ口・同じポート番号。中身はもう読めない）\n \n 宛先 MAC\n MAC ISP-1\n \n 送信元 MAC\n MAC R1-Gi1\n \n 宛先 IP\n 198.51.100.20\n \n 送信元 IP\n 203.0.113.10\n \n UDP ポート番号\n 500\n \n 暗号化されて読めない部分\n データ用の取り決めの中身\n ⑤ データ（図 11 の ③ と同じ。ここで初めて封ができる）\n \n 宛先 MAC\n MAC ISP-1\n \n 送信元 MAC\n MAC R1-Gi1\n \n 外側 宛先 IP\n 198.51.100.20\n \n 外側 送信元 IP\n 203.0.113.10\n \n ESP ヘッダ\n SPI・連番\n \n 暗号化されて読めない部分\n 内側 IP ヘッダ＋データ＋末尾\n \n 認証データ\n 改ざん検知用\n打合せは UDP ポート番号 500 を使う。間に NAT があるときは 4500 も使う（RFC 7296 §2、NAT 越えを扱う §2.23）\n図 11 のデータ（ESP）のほうはポート番号を持たない。外側 IP ヘッダのプロトコルの欄 50 で見分ける\nデータ用の SA は必ず送信用・受信用の対でできる。片方を消すときは両方消す（RFC 7296 §1.4.1）。勉強会で見た Active SAs: 2 はこの対のこと\n「フェーズ 1・フェーズ 2」は IKEv1 の言い方。IKEv2 では IKE_SA_INIT と IKE_AUTH の 2 往復で、管理用の SA と最初のデータ用 SA まで作ってしまう（RFC 7296 §1.2）\n　CREATE_CHILD_SA を使うのは、データ用の SA を 2 本目以降足すときと、寿命が来て作り直すとき（RFC 7296 §1.3）。IKEv2 は 2 段階に分かれていない\n古い方式について: IKEv1（RFC 2409）と、その土台の RFC 2408・2407 は Historic（役割を終えた文書）に移された（RFC 9395）。勉強会の crypto isakmp の設定は IKEv1 側\nDH グループ 1（768 ビット）は MUST NOT、グループ 2（1024 ビット）は SHOULD NOT、グループ 14（2048 ビット）が MUST（RFC 8247 §2.4）\n勉強会で使った group 1 は、この表では「使ってはいけない」側にあたる\n同じく IKEv2 では 3DES が MAY まで下がり、SHA-1 を使う鍵生成は MUST-（SHA-1 への攻撃を理由に格下げ）（RFC 8247 §2.1・§2.2）\n出典（IKEv2 の段取り・ポート番号・SA の対）: RFC 7296 https://www.rfc-editor.org/rfc/rfc7296\n出典（IKEv1 が Historic に移されたこと）: RFC 9395 https://www.rfc-editor.org/rfc/rfc9395\n出典（DH グループと方式の新旧）: RFC 8247 https://www.rfc-editor.org/rfc/rfc8247\n未検証: 「守る通信が実際に来てから打合せを始める」は、勉強会で初回の通信をするまで状態が ACTIVE にならなかった観察を一般化したもの。この動きを定めた一次資料は確認できていない\n未検証: 上の帯のフェーズ 1・フェーズ 2 の往復は、IKEv1 のメインモードの段取りを 1 往復ずつに単純化して描いている\n　　　　実際の通信の数と、どの欄がどこまで守られるかは、この図では確かめていない\n\n## 図 11・図 9 との接続","text":"\n \n IKE：封をする前の打合せ。方式と鍵を、まだ守られていない道で決める\n 図 7 の 3 つの問題を直接解く図ではなく、図 11（問題 3 の解）が使う取り決めを作る段。フェーズ 1 で管理用の SA、その中でフェーズ 2 がデータ用の SA を 2 本作る\n \n 支店（自分のもの）\n \n インターネット（他人のもの）\n \n データセンター（自分のもの）\n \n PC-A\n 192.168.10.10\n GW 192.168.10.1\n \n \n ルータ 1\n Gi0 192.168.10.1\n Gi1 203.0.113.10\n （グローバル IP）\n Gi0\n Gi1\n \n \n ISP-1\n 他人の\n ルータ\n \n \n ISP-2\n 他人の\n ルータ\n \n \n ISP-3\n 他人の\n ルータ\n \n \n ルータ 2\n Gi0 198.51.100.20\n （グローバル IP）\n Gi1 192.168.3.1\n Gi0\n Gi1\n \n \n PC-C\n 192.168.3.10\n GW 192.168.3.1\n \n crypto map\n Gi1 に貼る（手動）\n \n crypto map\n Gi0 に貼る（手動）\n \n \n 打合せ（IKE）。まだ封のできていない道で、方式と鍵を決める\n \n \n 3\n 4\n 打合せもこの中を通る。だから「相手が本物か」を確かめる段が要る\n 合意ができるまで、データ用の取り決め（SA）は 1 本も無い\n \n 1\n 2\n \n 5\n SA が無い\n 合意できてから、初めてデータが ESP で流れる（図 11）\n ③④ の中身：打合せは 2 段階に分かれている\n \n \n \n \n ルータ 1\n ルータ 2\n ③ フェーズ 1：管理用の取り決めを作る（メインモードの段取り）\n 使える方式の候補を出す → 鍵の材料を交換する → その上で相手が本物か確かめる\n \n 合意。管理用の SA が 1 つできる。ここから先の打合せは守られる\n \n ④ フェーズ 2：データ用の取り決めを作る\n 守る通信の範囲と、データを守る方式を決める（もう読まれない道の中で）\n \n 合意。データ用の SA が 送信用・受信用 の 2 本できる\n \n ⑤ ここでやっと、①のパケットが ESP で包まれて流れる\n \n \n 打合せが始まるきっかけ\n 口に貼っただけでは、打合せは\n まだ始まらない\n 守る通信の並びに一致する\n パケットが実際に来てから、\n 相手に声をかける\n \n 勉強会の観察：初回の通信を\n するまで状態は ACTIVE に\n ならず、Active SAs も 0 のまま\n （この動きの一次資料は未確認）\n \n つながらないときの切り分け\n セッションが DOWN のまま ＝ フェーズ 1 が合っていない\n 　方式の候補・事前共有鍵・相手の IP のどれかが両側で違う\n フェーズ 1 は上がるのに通らない ＝ フェーズ 2 が合っていない\n 　守る通信の並び（ACL）が両側で食い違っている\n どちらも「両側で同じものを人が設定する」でしか合わない\n \n 新旧（IKEv2 の表で今どれを使うか）\n IKEv1 は Historic（役割を終えた文書）に移された\n 今の現行は IKEv2。段取りの呼び名も変わっている\n DH グループ 1 は MUST NOT（使ってはいけない）\n グループ 2 は SHOULD NOT、グループ 14 が MUST\n 勉強会の group 1 は、この表では「使ってはいけない」側\n フロー\n ① 守る通信（外向きの口に貼った並びに一致するパケット）が、ルータ 1 に届く。図 11 の ① と同じパケット\n ② ルータ 1 は「封をすべき通信なのに、使える取り決め（SA）が 1 本も無い」と気づく。そこで ① は落とし、相手の外側 IP へ打合せを持ちかける\n ③ フェーズ 1。まず使える方式の候補を出し合い、鍵の材料を交換する。その材料でできた鍵で中身を守れるようになってから、相手が本物かを確かめる\n 確かめ方は事前共有鍵（両側に同じ文字列を人が手で設定したもの）。合意すると、管理用の SA が 1 つできる\n ④ フェーズ 2。その守られた中で、データ用の取り決めの中身（守る通信の範囲・暗号の方式）を決める\n 合意すると、データ用の SA が 送信用・受信用 の 2 本できる（片道に 1 本ずつ）\n ⑤ ここでやっと ① のパケットが ESP で包まれて流れる（図 11 の ②〜⑤）。SA には寿命があり、切れる前に打合せをやり直す\n 増えたもの\n 管理用の SA（論理・自動）：打合せそのものを守るための取り決め。1 つの相手につき 1 つ\n 事前共有鍵（論理・手動）：相手の IP と対で登録する合言葉。両側に同じ文字列を人が設定する\n 3 層で見ると\n もの：管理用の SA・データ用の SA（どちらも論理）・事前共有鍵（論理）・UDP ポート番号 500\n 結びつき：事前共有鍵 ⇄ 相手の IP（手動・両側で同じ文字列）／方式の候補 ⇄ 相手（手動・両側で合わないと決まらない）／SA は合意の結果できる（自動）\n フロー：図 11 の ②「送信用の SA で暗号化する」の前に、その SA を作る往復が入る。通信が来るまで始まらない\n\n設定と、打合せが進むにつれて増えるもの（③④ の番号は上のフローに対応。青字）\n \n ルータ 1: フェーズ 1 の設定（手動）\n 相手を確かめる方法：事前共有鍵\n 暗号の方式・ハッシュの方式\n DH グループ番号（鍵の材料の作り方）\n ③この 4 つが両側で合わないと先へ進まない\n \n ルータ 1: 事前共有鍵の登録（手動）\n 相手の IP：198.51.100.20\n その相手に使う合言葉：両側で同じ文字列\n （値そのものは図にも記録にも書かない）\n \n ルータ 1: フェーズ 2 の設定（手動）\n 守る通信の並び（図 9 の ACL）\n データを守る暗号の組合せ\n 相手：198.51.100.20\n ④守る通信の並びが両側で食い違うと通らない\n \n 打合せの前（②の時点）\n 管理用の SA：0\n データ用の SA：0\n セッションの状態：DOWN\n この状態で ① のパケットが来て、③ が始まる\n \n フェーズ 1 の後\n ③管理用の SA：1（相手 1 つにつき 1 つ）\n データ用の SA：0\n まだデータは 1 バイトも流れない\n \n フェーズ 2 の後（⑤ が流れる状態）\n 管理用の SA：1\n ④データ用の SA：2（送信用・受信用）\n 勉強会の表示 Active SAs: 2 はこの 2 本\n 寿命が切れる前に、また打合せが起きる\n通信の中身の推移（フローごとのフレーム／パケット）\n ① 守る通信が届く（図 11 の ① と同じ。これが打合せのきっかけ）\n \n 宛先 MAC\n MAC R1-Gi0\n \n 送信元 MAC\n MAC A\n \n 宛先 IP\n 192.168.3.10\n \n 送信元 IP\n 192.168.10.10\n \n データ\n ping\n \n フレーム＝全部。ただしスイッチが見るのは MAC とタグの部分だけ\n \n パケット＝この部分。ルータはここ（IP）を見る\n ② ルータ 1 の中\n 守る通信の並びには一致した。しかし使えるデータ用の SA が無い。そこで ① は落とし（初回の通信が失敗するのはこのため）、相手へ打合せの通信を出す\n ③ フェーズ 1 の往復（ルータ 1 → ルータ 2。中身はまだ守られていない）\n \n 宛先 MAC\n MAC ISP-1\n \n 送信元 MAC\n MAC R1-Gi1\n \n 宛先 IP\n 198.51.100.20\n \n 送信元 IP\n 203.0.113.10\n \n UDP ポート番号\n 500\n \n データ\n 方式の候補\n ③ の途中から\n 鍵の材料を交換し終えた後は、同じ UDP ポート番号 500 のまま、中身が守られた状態になる。相手が本物かを確かめるやり取りは、その守られた中で行う\n ④ フェーズ 2 の往復（同じ口・同じポート番号。中身はもう読めない）\n \n 宛先 MAC\n MAC ISP-1\n \n 送信元 MAC\n MAC R1-Gi1\n \n 宛先 IP\n 198.51.100.20\n \n 送信元 IP\n 203.0.113.10\n \n UDP ポート番号\n 500\n \n 暗号化されて読めない部分\n データ用の取り決めの中身\n ⑤ データ（図 11 の ③ と同じ。ここで初めて封ができる）\n \n 宛先 MAC\n MAC ISP-1\n \n 送信元 MAC\n MAC R1-Gi1\n \n 外側 宛先 IP\n 198.51.100.20\n \n 外側 送信元 IP\n 203.0.113.10\n \n ESP ヘッダ\n SPI・連番\n \n 暗号化されて読めない部分\n 内側 IP ヘッダ＋データ＋末尾\n \n 認証データ\n 改ざん検知用\n打合せは UDP ポート番号 500 を使う。間に NAT があるときは 4500 も使う（RFC 7296 §2、NAT 越えを扱う §2.23）\n図 11 のデータ（ESP）のほうはポート番号を持たない。外側 IP ヘッダのプロトコルの欄 50 で見分ける\nデータ用の SA は必ず送信用・受信用の対でできる。片方を消すときは両方消す（RFC 7296 §1.4.1）。勉強会で見た Active SAs: 2 はこの対のこと\n「フェーズ 1・フェーズ 2」は IKEv1 の言い方。IKEv2 では IKE_SA_INIT と IKE_AUTH の 2 往復で、管理用の SA と最初のデータ用 SA まで作ってしまう（RFC 7296 §1.2）\n　CREATE_CHILD_SA を使うのは、データ用の SA を 2 本目以降足すときと、寿命が来て作り直すとき（RFC 7296 §1.3）。IKEv2 は 2 段階に分かれていない\n古い方式について: IKEv1（RFC 2409）と、その土台の RFC 2408・2407 は Historic（役割を終えた文書）に移された（RFC 9395）。勉強会の crypto isakmp の設定は IKEv1 側\nDH グループ 1（768 ビット）は MUST NOT、グループ 2（1024 ビット）は SHOULD NOT、グループ 14（2048 ビット）が MUST（RFC 8247 §2.4）\n勉強会で使った group 1 は、この表では「使ってはいけない」側にあたる\n同じく IKEv2 では 3DES が MAY まで下がり、SHA-1 を使う鍵生成は MUST-（SHA-1 への攻撃を理由に格下げ）（RFC 8247 §2.1・§2.2）\n出典（IKEv2 の段取り・ポート番号・SA の対）: RFC 7296 https://www.rfc-editor.org/rfc/rfc7296\n出典（IKEv1 が Historic に移されたこと）: RFC 9395 https://www.rfc-editor.org/rfc/rfc9395\n出典（DH グループと方式の新旧）: RFC 8247 https://www.rfc-editor.org/rfc/rfc8247\n未検証: 「守る通信が実際に来てから打合せを始める」は、勉強会で初回の通信をするまで状態が ACTIVE にならなかった観察を一般化したもの。この動きを定めた一次資料は確認できていない\n未検証: 上の帯のフェーズ 1・フェーズ 2 の往復は、IKEv1 のメインモードの段取りを 1 往復ずつに単純化して描いている\n　　　　実際の通信の数と、どの欄がどこまで守られるかは、この図では確かめていない\n\n## 図 11・図 9 との接続","line":61,"sources":["src_1","src_2","src_3"],"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_18ab2a","type":"paragraph","markdown":"図 11 の ②「送信用の SA で暗号化する」の前に、その SA を作る往復が入ります。\n図 10・図 11・図 12 の 3 枚で 1 つの流れになります。","text":"図 11 の ②「送信用の SA で暗号化する」の前に、その SA を作る往復が入ります。\n図 10・図 11・図 12 の 3 枚で 1 つの流れになります。","line":332,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_efab08","type":"paragraph","markdown":"図 9 の行の並びが、ここでもう一度出てきます。\nフェーズ 2 で「守る通信の範囲」として合意の材料になり、両側で食い違うと通りません。\nつながらないときの切り分けは、この 2 段階に対応します。\nセッションが DOWN のままならフェーズ 1 で、方式の候補・事前共有鍵・相手の IP のどれかが両側で違います。\nフェーズ 1 は上がるのに通らないならフェーズ 2 で、守る通信の並びが両側で食い違っています。","text":"図 9 の行の並びが、ここでもう一度出てきます。\nフェーズ 2 で「守る通信の範囲」として合意の材料になり、両側で食い違うと通りません。\nつながらないときの切り分けは、この 2 段階に対応します。\nセッションが DOWN のままならフェーズ 1 で、方式の候補・事前共有鍵・相手の IP のどれかが両側で違います。\nフェーズ 1 は上がるのに通らないならフェーズ 2 で、守る通信の並びが両側で食い違っています。","line":335,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_58d337","type":"paragraph","markdown":"図 1 でルーティングテーブルの行を人が書いたのと同じで、方式・鍵・守る範囲は人が両側で揃えます。","text":"図 1 でルーティングテーブルの行を人が書いたのと同じで、方式・鍵・守る範囲は人が両側で揃えます。","line":341,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_703626","type":"heading","depth":2,"markdown":"## 未検証・注意","text":"未検証・注意","line":343,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_cdeca1","type":"list","markdown":"- 「守る通信が実際に来てから打合せを始める」は、勉強会で初回の通信をするまで状態が ACTIVE にならず、SA の数も 0 のままだった観察を一般化したものです。この動きを定めた一次資料は確認できていません。\n- 図の帯では、フェーズ 1 とフェーズ 2 を 1 往復ずつに単純化して描いています。実際の通信の数と、どの欄がどこまで守られるかは確かめていません。フェーズ 1 の途中で中身が守られるようになる切り替わりの位置も、図では大まかにしか描けていません。\n- 「フェーズ 1・フェーズ 2」は IKEv1 の言い方です。勉強会が使ったのが IKEv1 だったので、図もその言葉で描いています。③ の往復は IKEv1 のメインモードの段取りです。\n- IKEv2 では段取りが違います。IKE\\_SA\\_INIT と IKE\\_AUTH の 2 往復で、管理用の SA と最初のデータ用 SA まで作ってしまいます。CREATE\\_CHILD\\_SA を使うのは、データ用の SA を 2 本目以降足すときと、寿命が来て作り直すときです。フェーズ 1 を IKE\\_SA\\_INIT と IKE\\_AUTH、フェーズ 2 を CREATE\\_CHILD\\_SA に対応づける読み方はできません。\n- IKEv1 は「非推奨」ではなく、Historic（役割を終えた文書）に移されました。RFC 2409 と、その土台の RFC 2408・RFC 2407 が対象です。\n- 古い方式について書くとき、参照した表は IKEv2 向けのものです。勉強会が使った IKEv1 の設定を、IKEv2 の表で評価していることになります。その表では DH グループ 1（768 ビット）が MUST NOT、グループ 2（1024 ビット）が SHOULD NOT、グループ 14（2048 ビット）が MUST、グループ 19 が SHOULD です。3DES は MAY まで下がり、SHA-1 を使う鍵生成は MUST- です。勉強会で使ったグループ 1 は、この表では使ってはいけない側にあたります。\n- 事前共有鍵の値、SPI の値、鍵の寿命の実数は書いていません。","text":"「守る通信が実際に来てから打合せを始める」は、勉強会で初回の通信をするまで状態が ACTIVE にならず、SA の数も 0 のままだった観察を一般化したものです。この動きを定めた一次資料は確認できていません。図の帯では、フェーズ 1 とフェーズ 2 を 1 往復ずつに単純化して描いています。実際の通信の数と、どの欄がどこまで守られるかは確かめていません。フェーズ 1 の途中で中身が守られるようになる切り替わりの位置も、図では大まかにしか描けていません。「フェーズ 1・フェーズ 2」は IKEv1 の言い方です。勉強会が使ったのが IKEv1 だったので、図もその言葉で描いています。③ の往復は IKEv1 のメインモードの段取りです。IKEv2 では段取りが違います。IKE_SA_INIT と IKE_AUTH の 2 往復で、管理用の SA と最初のデータ用 SA まで作ってしまいます。CREATE_CHILD_SA を使うのは、データ用の SA を 2 本目以降足すときと、寿命が来て作り直すときです。フェーズ 1 を IKE_SA_INIT と IKE_AUTH、フェーズ 2 を CREATE_CHILD_SA に対応づける読み方はできません。IKEv1 は「非推奨」ではなく、Historic（役割を終えた文書）に移されました。RFC 2409 と、その土台の RFC 2408・RFC 2407 が対象です。古い方式について書くとき、参照した表は IKEv2 向けのものです。勉強会が使った IKEv1 の設定を、IKEv2 の表で評価していることになります。その表では DH グループ 1（768 ビット）が MUST NOT、グループ 2（1024 ビット）が SHOULD NOT、グループ 14（2048 ビット）が MUST、グループ 19 が SHOULD です。3DES は MAY まで下がり、SHA-1 を使う鍵生成は MUST- です。勉強会で使ったグループ 1 は、この表では使ってはいけない側にあたります。事前共有鍵の値、SPI の値、鍵の寿命の実数は書いていません。","line":345,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_240080","type":"heading","depth":2,"markdown":"## 出典","text":"出典","line":353,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_e7f307","type":"list","markdown":"- 勉強会での本人の観察（2026-09-13 実機ハンズオン。資料は非公開）\n- [RFC 7296: Internet Key Exchange Protocol Version 2 (IKEv2)](https://www.rfc-editor.org/rfc/rfc7296) — §1.2 で IKE\\_SA\\_INIT が方式の合意と鍵の材料の交換、IKE\\_AUTH が「authenticate the previous messages, exchange identities and certificates, and establish the first Child SA」。§1.3 で CREATE\\_CHILD\\_SA は新しい Child SA の作成と作り直し。§1.4.1「ESP and AH SAs always exist in pairs, with one SA in each direction」。§2 の UDP 500 と §2.23 の 4500\n- [RFC 9395: Deprecation of the Internet Key Exchange Version 1 (IKEv1) Protocol and Obsoleted Algorithms](https://www.rfc-editor.org/rfc/rfc9395) — IKEv1 は deprecate され、RFC 2407・2408・2409 は Historic に移された\n- [RFC 8247: Algorithm Implementation Requirements and Usage Guidance for IKEv2](https://www.rfc-editor.org/rfc/rfc8247) — IKEv2 向けの表。§2.1 で ENCR\\_3DES は MAY、§2.2 で PRF\\_HMAC\\_SHA1 は MUST-、§2.4 で DH グループ 1 は MUST NOT、グループ 2 は SHOULD NOT、グループ 14 は MUST、グループ 19 は SHOULD","text":"勉強会での本人の観察（2026-09-13 実機ハンズオン。資料は非公開）RFC 7296: Internet Key Exchange Protocol Version 2 (IKEv2) — §1.2 で IKE_SA_INIT が方式の合意と鍵の材料の交換、IKE_AUTH が「authenticate the previous messages, exchange identities and certificates, and establish the first Child SA」。§1.3 で CREATE_CHILD_SA は新しい Child SA の作成と作り直し。§1.4.1「ESP and AH SAs always exist in pairs, with one SA in each direction」。§2 の UDP 500 と §2.23 の 4500RFC 9395: Deprecation of the Internet Key Exchange Version 1 (IKEv1) Protocol and Obsoleted Algorithms — IKEv1 は deprecate され、RFC 2407・2408・2409 は Historic に移されたRFC 8247: Algorithm Implementation Requirements and Usage Guidance for IKEv2 — IKEv2 向けの表。§2.1 で ENCR_3DES は MAY、§2.2 で PRF_HMAC_SHA1 は MUST-、§2.4 で DH グループ 1 は MUST NOT、グループ 2 は SHOULD NOT、グループ 14 は MUST、グループ 19 は SHOULD","line":355,"sources":["src_1","src_2","src_3"],"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_1f7c1f","type":"heading","depth":2,"markdown":"## 関連","text":"関連","line":360,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}},{"id":"blk_147e61","type":"list","markdown":"- [ネットワーク\\_INDEX](/notes/nw-basics-index) — 連載の目次\n\n- 連載の入口: [ネットワーク\\_00\\_3層で言葉を置く](/notes/nw-basics-00-three-layers)（`/notes/nw-basics-00-three-layers`）\n\n- 前の記事（図 11）: [ネットワーク\\_11\\_IPsec](/notes/nw-basics-11-ipsec)（`/notes/nw-basics-11-ipsec`）\n\n- 守る通信を選ぶ行の並び: [ネットワーク\\_09\\_ACL](/notes/nw-basics-09-acl)（`/notes/nw-basics-09-acl`）\n\n- 包む形そのもの: [ネットワーク\\_10\\_GREトンネル](/notes/nw-basics-10-gre)（`/notes/nw-basics-10-gre`）\n\n- 次の記事（図 13）: [ネットワーク\\_13\\_OSPF](/notes/nw-basics-13-ospf)（`/notes/nw-basics-13-ospf`）","text":"ネットワーク_INDEX — 連載の目次連載の入口: ネットワーク_00_3層で言葉を置く（/notes/nw-basics-00-three-layers）前の記事（図 11）: ネットワーク_11_IPsec（/notes/nw-basics-11-ipsec）守る通信を選ぶ行の並び: ネットワーク_09_ACL（/notes/nw-basics-09-acl）包む形そのもの: ネットワーク_10_GREトンネル（/notes/nw-basics-10-gre）次の記事（図 13）: ネットワーク_13_OSPF（/notes/nw-basics-13-ospf）","line":362,"lineage":[],"authoredBy":{"kind":"human","id":"owner","label":"ぴぐお"}}],"sources":[{"id":"src_1","url":"https://www.rfc-editor.org/rfc/rfc7296","title":"RFC 7296: Internet Key Exchange Protocol Version 2 (IKEv2)","accessed":"2026-09-14","kind":"secondary"},{"id":"src_2","url":"https://www.rfc-editor.org/rfc/rfc9395","title":"RFC 9395: Deprecation of the Internet Key Exchange Version 1 (IKEv1) Protocol and Obsoleted Algorithms","accessed":"2026-09-14","kind":"secondary"},{"id":"src_3","url":"https://www.rfc-editor.org/rfc/rfc8247","title":"RFC 8247: Algorithm Implementation Requirements and Usage Guidance for IKEv2","accessed":"2026-09-14","kind":"secondary"}],"errata":[]}