0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@hshimomu(Hideaki Shimomura)

Cisco Catalyst SD-WAN 26.2.1でPQC鍵交換を試す：IKEv2 × ML-KEMの設定と検証

0
Last updated at Posted at 2026-10-01

はじめに

Cisco Catalyst SD-WAN 26.2.1では、データプレーンのIPsecトンネルに使う鍵を、エッジルータ同士がIKEv2で交換できるようになりました。対応ルータでは、IKEv2の鍵交換にML-KEMを使うPQCも選べます。本稿では、SD-WAN Managerでの設定と、ルータ上での確認方法をまとめます。

ここで扱うPQCは、従来の鍵交換にML-KEMを組み合わせるハイブリッド鍵交換です。IPsecのデータ暗号化には、引き続きAESなどの共通鍵暗号を使用します。機能の概要、対応条件、制約はCiscoの設定ガイドを参照してください。

前提と対応範囲

  • Cisco IOS XE Catalyst SD-WANとSD-WAN Managerは、ともに26.2.1以降を前提とします。
  • 本稿のGUI手順で扱うPQCは、SD-WANルータ同士のデータプレーンIPsecトンネルが対象です。SSE/SIGなど、SD-WAN以外のピアとの接続は後述の別ケースです。
  • IKEv2によるデータプレーンの鍵交換と、ML-KEMによるPQCは区別します。Ciscoの設定ガイドでは、ML-KEMを使うPQCの対象をCisco 8000 Series Secure Routerとしています。
  • 経路上のファイアウォールやNATでは、IKEv2の交渉とIPsecデータプレーン通信に使うUDP 12346〜12445を通過できることを確認します。
  • IPsecの鍵管理方式を従来方式からIKEv2に変更した場合は、変更を有効にするためにルータの再起動が必要です。

検証では、PQC対応ルータ2台と非対応ルータ1台の混在構成を使用しました。以下の画像は、画面全体ではなく設定項目が読める範囲を切り出しました。

何が変わるのか

従来の構成では、SD-WAN Controllerがデータプレーンの鍵管理に関わります。IKEv2方式では、ルータ同士がデータプレーンのIPsec鍵を直接確立・更新します。Controllerは、ピア情報や、ルータ間の認証に使う事前共有鍵の配布を引き続き担います。

従来のControllerベースの鍵管理と、ルータ間IKEv2鍵管理の比較

図のピンク枠は鍵管理に関する差分です。右側では、ルータ間のIKEv2による鍵交換がデータプレーンのトンネルに使われます。

SD-WAN Managerで設定する

1. Configuration GroupのSystem Profileを開く

Configuration > Configuration Groupsで対象のConfiguration Groupを開き、関連付けられたSystem Profileを編集します。

Configuration GroupからSystem Profileを開く場所

2. Fabric Securityを追加する

System ProfileのAdd New FeatureからFabric Securityを選びます。

System ProfileにFabric Securityを追加する画面

3. IKEv2とPQCを選ぶ

Fabric Securityで、次の項目を設定します。画面内のPQE typeは、公式ガイドでいうPost quantum encryptionの選択項目です。

項目 設定例 意味
IPSec keying method IKEv2 ルータ間でIKEv2を使ってIPsec鍵を管理する
PQE type PQC ML-KEMを使うPQC鍵交換を選ぶ
Algorithm ML-KEM-768 使用するML-KEM方式。公式ガイドではML-KEM-1024も選択可能
Fallback to non pqc On PQCを交渉できない相手との古典的な鍵交換を許可する

IKEv2、PQC、Fallback、ML-KEMアルゴリズムの設定箇所

まず混在環境を確認するなら、Fallback to non pqcを有効にした構成から始めると、PQCに対応しないピアとの接続も評価できます。PQCを必須にする設定は後述します。

4. 対象ルータへデプロイして再起動する

Fabric SecurityをSystem Profileに追加した後、Configuration Groupの変更を対象ルータへデプロイします。デプロイ前に対象台数と差分を確認してください。

Configuration Groupのデプロイ画面

IPSec keying methodを切り替えたルータは再起動します。 検証時に再起動前から設定が見えたとしても、Ciscoのガイドは切り替え後の再起動を要件としています。再起動後にBFD、SD-WAN、IKEv2、IPsecの状態を確認します。

資料で再起動前に採取した出力は、IKEv2セッションがまだ成立していない状態です。以下は主要行の抜粋です。

再起動前のshowコマンド出力を表示 
Device# show crypto ikev2 sdwan stats
Total SDWAN IKEV2 sessions : 0

Device# show crypto session
Session status: UP-NO-IKE

ML-KEMで鍵交換できたか確認する

まずBFDセッションとIKEv2 SAの状態を確認します。以下は資料のshowコマンド出力を文字にした抜粋です。機器名、IPアドレス、SPIなどは省略・匿名化しています。

BFDのshowコマンド出力を表示 
Device# show sdwan bfd summary
sessions-total  1
sessions-up     0

Device# show sdwan bfd sessions alt
SYSTEM IP    SITE ID  STATE  ... FLAGS
<system-ip>  10       down   ... IKEv2

この採取時点では、KeyringフラグにIKEv2が表示されてもBFDはdownです。フラグだけを接続成功の判定に使わず、SAとセッション状態を続けて確認します。

後続の検証ログでは、SD-WAN IKEv2セッションが1件成立し、SAの詳細にML-KEMが表示されています。以下は機器名、IPアドレス、SPIなどを省いた出力の主要行です。

SD-WAN IKEv2 SAとセッションのshowコマンド出力を表示 
Device# show crypto ikev2 sdwan stats
Total SDWAN IKEv2 sessions          : 1
Total SDWAN IKEv2 active sessions   : 1
Total SDWAN IKEv2 inactive sessions : 0

Device# show crypto ikev2 sa detailed
Tunnel-id  Local       Remote      fvrf/ivrf  Status
2          <local-ip>  <peer-ip>   none/none  READY
PQC Key Exchange: ML-KEM-768
Status Description: Negotiation done
Quantum-safe Encryption using PQC: ML-KEM-768
PEER TYPE: SD-WAN

Device# show crypto session detail
Profile: ikev2_profile_sdwan
Session status: UP-ACTIVE
Capabilities:DFNUQ

PQC Key Exchange: ML-KEM-768 は、当該IKEv2 SAでML-KEMが交渉されたことを示します。show crypto session detailの凡例ではQがQuantum-safe Encryptionを表します。IKEv2 SAのREADY、IKEv2セッション数、crypto sessionのUP-ACTIVEも合わせて確認します。データ転送の確認には、BFDのUp、IPsecの送受信カウンター、実トラフィックの疎通も照合します。コマンドの詳細はCiscoの検証手順を参照してください。

PQCを必須にする場合

Fallback to non pqcをOffにすると、古典的な鍵交換へのフォールバックを許可しません。PQCを交渉できないピアとのトンネルは成立しなくなるため、混在構成では対象ピアを確認してから切り替えます。

Fallback to non pqcをOffにした設定

ピアの組み合わせ Fallback On Fallback Off
両端のML-KEM方式・認証などの設定が一致 PQCで接続可能 PQCで接続可能
一方がML-KEM非対応 両端が許可する古典的な鍵交換へ切り替え可能 PQCを交渉できず接続不可

上表は設定の意味を整理したものです。実際の接続は、両端の対応機種・設定・ポリシーを確認してください。

資料のPQC必須設定後の出力では、対応ルータ間のSAにはREADYとML-KEMの表示があり、非対応ルータ側のshow crypto ikev2 saにはSAが表示されていません。以下も主要行のみの抜粋です。

PQC必須設定後のshowコマンド出力を表示 
PQC-capable# show crypto ikev2 sa
Tunnel-id  Local       Remote      fvrf/ivrf  Status
2          <local-ip>  <peer-ip>   none/none  READY
PQC Key Exchange: ML-KEM-768

Legacy# show crypto ikev2 sa
Legacy#

SD-WAN以外のIPsec接続（SSE/SIG）への適用範囲

ここまでのFabric SecurityによるPQC設定は、SD-WANルータ間のトンネルを対象とします。Fabric Securityが構成するikev2_proposal_sdwanと、この検証環境の非SD-WAN IPsec接続で使うp1-globalは別のproposalです。

SSE/SIGへのIPsecトンネルは別の機能として設定します。本稿で参照した公式ガイドからは、26.2.1のcontroller modeで非SD-WANピアにML-KEMを適用する正式な手順は確認できません。一般のIKEv2 PQC設定ガイドはautonomous modeを対象としているため、以下はラボでの接続検証例として紹介します。SSE/SIGサービスへの適用可否は、各サービスと対象リリースの対応条件を確認してください。

検証環境では、CLI profileを使って非SD-WAN側の設定を上書きし、ラボ内の非SD-WANピアとのIPsec接続を確認しました。次は差分の例です。p1-globalやif-ipsec1-ipsec-profileはこの環境の名前であり、既存の暗号・認証設定などを含む完全な設定例ではありません。

crypto ikev2 proposal p1-global
 pqc mlkem768 optional
 prf sha256
 group 19

crypto ipsec profile if-ipsec1-ipsec-profile
 set pfs group19

SD-WAN用のIKEv2 profileにはmatch application sdwanがあり、非SD-WAN側では別のprofileが使われます。次はshow running-config | sec ikev2 profileの抜粋です。アドレスは伏せています。

IKEv2 profileのshowコマンド出力を表示 
Device# show running-config | sec ikev2 profile
crypto ikev2 profile ikev2_profile_sdwan
 match application sdwan
 match identity remote any
 authentication remote pre-share
 authentication local pre-share
 nat force-encap
crypto ikev2 profile if-ipsec1-ikev2-profile
 match identity remote address <peer-ip> 255.255.255.255
 identity local address <local-id>
 authentication remote pre-share
 authentication local pre-share
 keyring local if-ipsec1-ikev2-keyring
 lifetime 14400
 dpd 10 3 on-demand
 no config-exchange request

このCLI上書きは接続を検証した例であり、Ciscoから正規にサポートを受けられる設定手順としては扱いません。 PQCの成立は、該当する非SD-WANピアとのSA出力でPQC Key Exchangeを確認します。CiscoのIKEv2 PQC設定ガイドも参照してください。

検証時はshow crypto ikev2 saで確認しました。非SD-WANピア192.168.64.50との接続はTunnel-id 6で、READYとPQC Key Exchange: ML-KEM-768が表示されています。同じ出力には、別のピアとのTunnel-id 1、2も含まれます。

非SD-WANピアを含むshow crypto ikev2 saの出力を表示 
cedge10#show crypto ikev2 sa
 IPv4 Crypto IKEv2  SA

Tunnel-id Local                 Remote                fvrf/ivrf            Status
1         192.168.64.73/12346   192.168.64.84/12366   none/none            READY
      Encr: AES-GCM, keysize: 256, PRF: SHA256, Hash: None, DH Grp:19, Auth sign: PSK, Auth verify: PSK
      Life/Active Time: 86400/33511 sec
      CE id: 1023, Session-id: 12
      Local spi: 2462755A99B4ECAF       Remote spi: DDB22F1772D8D15D

Tunnel-id Local                 Remote                fvrf/ivrf            Status
6         192.168.64.73/500     192.168.64.50/500     none/none            READY
      Encr: AES-CBC, keysize: 256, PRF: SHA256, Hash: SHA256, DH Grp:19, Auth sign: PSK, Auth verify: PSK
      PQC Key Exchange: ML-KEM-768
      Life/Active Time: 14400/6448 sec
      CE id: 0, Session-id: 14
      Local spi: E23735184C07D7DB       Remote spi: FA177CBC68EF9871

Tunnel-id Local                 Remote                fvrf/ivrf            Status
2         192.168.64.73/12346   192.168.64.75/12346   none/none            READY
      Encr: AES-GCM, keysize: 256, PRF: SHA256, Hash: None, DH Grp:19, Auth sign: PSK, Auth verify: PSK
      PQC Key Exchange: ML-KEM-768
      Life/Active Time: 86400/33492 sec
      CE id: 0, Session-id: 13
      Local spi: F8877359364811C4       Remote spi: BB6048BA39AC8E59

この出力で確認できるのは、当該ピアとのIKEv2 SAでML-KEMが交渉されたことです。IPsec Child SAの再鍵交換で使用する方式は、IKEv2 SAの表示に加えてPFS設定と再鍵交換時の状態も確認します。

補足: コントロールプレーンとPPK

データプレーンのIKEv2設定とは別に、コントロールプレーンのPQCではControl Connection ProtocolをDTLSからTLSへ変更します。SD-WAN ManagerのConfiguration > Control Components > Common Control Component Settings > Securityから設定し、デプロイ後に交渉グループを確認します。ルータ側の確認例はshow sdwan control connections detail、以下のvSmartログではshow control connections detailを使っています。Ciscoの設定ガイドにもp521_mlkem1024の確認例があります。

Control connection protocolでTLSを選ぶ画面

検証ログのvSmart上では、TLS 1.3でML-KEMを交渉した接続を確認できます。以下は証明書情報とアドレスを省いたshow control connections detailの抜粋です。

ML-KEMを交渉したcontrol connectionのshowコマンド出力を表示 
vsmart# show control connections detail
site-id                                10
protocol                               tls
protocol-version                       TLS1_3
state                                  up
SSL handshake negotiated group         p521_mlkem1024

同じログには、TLS 1.3でも従来のグループを交渉した別ピアの接続があります。tlsやTLS1_3の表示だけでPQCと判断せず、交渉グループまで確認します。

従来グループを交渉したcontrol connectionの出力を表示 
site-id                                30
protocol                               tls
protocol-version                       TLS1_3
state                                  up
SSL handshake negotiated group         secp521r1

この採取ログでは、vManageとの接続はp521_mlkem1024、vBondとの接続はDTLS 1.2とsecp521r1でした。接続先ごとに方式を確認します。

vManageとvBondへのcontrol connectionの出力を表示 
site-id                                1
protocol                               tls
protocol-version                       TLS1_3
SSL handshake negotiated group         p521_mlkem1024

site-id                                0
protocol                               dtls
protocol-version                       DTLS1_2
SSL handshake negotiated group         secp521r1

また、IKEv2のPost quantum encryptionには、PPK（Post-quantum Preshared Key）もあります。動的PPKは外部の鍵ソースから鍵を取得し、手動PPKはCLI add-onで両端に同じ鍵を設定します。ML-KEMとは設定と確認ポイントが異なるため、ここでは扱いません。

参考資料

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?