鍵の材料を先に交換し、守れる状態にしてから相手を確かめる

図 11 では、送信用の SA に書かれた方式と鍵で暗号化する、と書きました。

その方式と鍵がどこから来るかには触れていません。 まだ封のできていない道で、相手と方式を決め、鍵の材料をやり取りするしかありません。 この記事は、図 7 で挙げた 3 つの問題を直接解く図ではなく、図 11 が使う取り決めを作る段を扱います。

この連載は、ネットワークの言葉を 3 つの層に置いて読みます。 もの（物理か論理か）、結びつき（人が設定で付ける手動か、機器が学習する自動か、製造時に決まる固定か）、通信フロー（1 本の通信がそれらを順に通る道筋）の 3 つです。

登場するもの

管理用の SA

論理のもので、自動でできます。 打合せそのものを守るための取り決めです。 相手 1 つにつき 1 つです。

データ用の SA

論理のもので、自動でできます。 図 11 で実際にデータを包むのに使う取り決めです。 送信用と受信用の 2 本できます。

事前共有鍵

論理のもので、人が書きます。 相手の IP と対で登録する合言葉です。 両側に同じ文字列を設定します。 値は図にも記録にも書きません。

打合せの通信そのもの

UDP のポート番号 500 を使います。 間に NAT があるときは 4500 も使います。 図 11 のデータのほうはポート番号を持ちません。

結びつき

• 事前共有鍵 ⇄ 相手の IP は手動です。両側で同じ文字列でないと、フェーズ 1 で止まります。
• 方式の候補（暗号・ハッシュ・DH グループ）⇄ 相手は手動です。両側に共通のものが 1 つも無ければ、合意に至りません。
• 守る通信の並び ⇄ 相手も手動です。ここが食い違うと、フェーズ 1 は上がるのにデータが通りません。
• SA ⇄ 打合せの結果は自動です。人が SA を直接書くことはありません。

通信フロー

① 守る通信、つまり外向きの口に貼った並びに一致するパケットが、ルータ 1 に届きます。図 11 の ① と同じパケットです。

② ルータ 1 は「封をすべき通信なのに、使える取り決めが 1 本も無い」と気づきます。そこで ① は落とし、相手の外側 IP へ打合せを持ちかけます。初回の通信が失敗するのはこのためです。

③ フェーズ 1。まず使える方式の候補を出し合い、鍵の材料を交換します。その材料でできた鍵で中身を守れるようになってから、相手が本物かを確かめます。確かめ方は事前共有鍵です。合意すると、管理用の SA が 1 つできます。

④ フェーズ 2。その守られた中で、守る通信の範囲とデータを守る方式を決めます。合意すると、データ用の SA が送信用・受信用の 2 本できます。

⑤ ここでやっと ① のパケットが ESP で包まれて流れます（図 11 の ② から ⑤）。SA には寿命があり、切れる前に打合せをやり直します。

図 12

図の上半分が構成図と 2 段階の打合せ・切り分け、下半分が設定と増えるもの・通信の中身の推移です。

図 11 の ②「送信用の SA で暗号化する」の前に、その SA を作る往復が入ります。 図 10・図 11・図 12 の 3 枚で 1 つの流れになります。

図 9 の行の並びが、ここでもう一度出てきます。 フェーズ 2 で「守る通信の範囲」として合意の材料になり、両側で食い違うと通りません。 つながらないときの切り分けは、この 2 段階に対応します。 セッションが DOWN のままならフェーズ 1 で、方式の候補・事前共有鍵・相手の IP のどれかが両側で違います。 フェーズ 1 は上がるのに通らないならフェーズ 2 で、守る通信の並びが両側で食い違っています。

図 1 でルーティングテーブルの行を人が書いたのと同じで、方式・鍵・守る範囲は人が両側で揃えます。

未検証・注意

• 「守る通信が実際に来てから打合せを始める」は、勉強会で初回の通信をするまで状態が 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 の値、鍵の寿命の実数は書いていません。

出典

• 勉強会での本人の観察（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 の 4500
• RFC 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

関連

• ネットワーク_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）