Cisco IOS XE 26.1.1 で IKEv2/IPsec の PQC対応が来た: ML-KEM と proposal の挙動を確認
Cisco IOS XE 26.1.1 から、Cisco Secure Router 8000 シリーズで ML-KEM を使った hybrid 鍵交換による IKEv2/IPsec がサポートされました。
PQC といえば、やはり本命は IKEv2/IPsec だと感じている方が多いのではないでしょうか。前回は SSH 側の話だったので、少し肩透かしに感じた方もいたかもしれません。
お待たせしました。今回は待望の IKEv2 での ML-KEM 対応です。
今回は手元のDMVPN検証ログを見ながら、実際に何が変わったのか、どこに注意が必要かを整理してみます。
また、strongSwan との異機種間 VTI IPsec 検証もできたので、その内容もお届けします。
前回の SSH 側の話はこちらです。
先に結論
- Cisco IOS XE 26.1.1 から、Cisco Secure Router 8000 シリーズで ML-KEM を使った hybrid IKEv2/IPsec がサポートされる
- 26.1.1 へアップグレードすると、
crypto ikev2 proposal defaultには自動的に PQC の設定項目が追加される - 一方で、
crypto ikev2 proposal IKEPROPOSALのように個別に作成済みの proposal には、自動では PQC 設定は入らない - そのため、既存の DMVPN / FlexVPN が自動的に PQC 化されるとは限らない
- ISR1100 などの旧シリーズでは、SSH の ML-KEM はサポートされるが、ML-KEM を使った IKEv2 はサポートされない
- なお、PPK は別機能であり、ML-KEM IKEv2 のサポート有無とは分けて考える必要がある（詳しくは後述）
今回うれしいポイント
やはり大きいのは、PQC の話が SSH だけでなく、ようやく IKEv2/IPsec に入ってきたことです。
拠点間 VPN、DMVPN、FlexVPN のようなユースケースを考えると、実運用でよりインパクトが大きいのはむしろこちらです。
そういう意味でも、今回の 26.1.1 での対応は「ついに来た」という印象が強いアップデートかと思います。
26.1.1 では、SD-WAN (controller mode) での IKEv2 (ML-KEM) サポートは含まれておらず、今後の対応予定です。
また ML-DSA-87 のようなPQC署名やPQCセキュアブートも含まれておらず、これも今後の対応予定です。
実際の確認ログ
まず、ルータは IOS XE 26.1.1 に上がっています。
今回は Cisco Secure Router C8235-G2 を利用しています。
Router#show version
Cisco IOS XE Software, Version 26.01.01
Cisco IOS Software [IOSXE], c8kg2be Software (ARMV8EL_LINUX_IOSD-UNIVERSALK9-M), Version 26.01.1, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2026 by Cisco Systems, Inc.
Compiled Tue 07-Apr-26 18:26 by mcpre
Router#show install summary
[ Chassis 1/R0 provisioned software ]
---------------------------
Type Version
---------------------------
SR 26.01.01.0.340
26.1.1 へのアップグレード後、crypto ikev2 proposal default にだけ次の行が追加されていました。
crypto ikev2 proposal default
pqc mlkem768 mlkem1024 optional
encryption aes-cbc-256 aes-cbc-128
integrity sha256 sha384 sha512
group 19 20 21 14
つまり、crypto ikev2 proposal default には ML-KEM の設定、つまり、pqc mlkem768 mlkem1024 optional が自動的に追加されます。
一方で、個別に作成していた proposal はそのままでした。
crypto ikev2 proposal PROPOSAL
encryption aes-cbc-256 aes-cbc-128
integrity sha256 sha384 sha512
group 19 20 21 14
Configuration mode では、以下のような設定が可能です。
Router(config)#crypto ikev2 proposal PROPOSAL
Router(config-ikev2-proposal)#pqc mlkem768 ?
mlkem1024 ML-KEM-1024
mlkem512 ML-KEM-512
optional PQC Key Exchange is optional
<cr> <cr>
ここが今回のいちばん大事なポイントです。
optional を付けると、ML-KEM 未対応の対向先であっても従来方式での IKEv2 鍵交換を許容します。
逆に optional を外すと、ML-KEM を使った IKEv2 鍵交換を必須にします。
何が重要か
crypto ikev2 proposal default に PQC 設定が入ったからといって、既存の IKEv2/IPsec 全部が自動的に ML-KEM 化されるわけではありません。
実際のトンネルで参照している proposal が default なら、その恩恵を受ける可能性があります。
しかし、DMVPN や FlexVPN で IKEPROPOSAL のような個別 proposal を使っている場合、その proposal に PQC 設定が入っていなければ、PQC Key Exchange: none のままです。
つまり、運用上は次のように考える必要があります。
- Cisco Secure Router を 26.1.1 にアップグレードする
-
show crypto ikev2 proposalで、どの proposal に PQC が入っているか確認する - 実際に使っている IKEv2 policy / profile / tunnel がどの proposal を参照しているか確認する
- 個別 proposal を使っている場合は、必要に応じて明示的に PQC 設定を追加する
- IKEv2 initiator が ML-KEM を
optionalで提案した場合でも、IKEv2 responder 側に設定が入っていなければ ML-KEM のネゴシエーションは成立しない
crypto ikev2 proposal default を使う場合、アップグレード手順や対向側の設定状況によっては、後述の通り接続影響が出ます。
その意味でも、crypto ikev2 proposal default の利用は避け、明示的な proposal を指定した方が安全そうです。
show コマンドでの見え方
show crypto ikev2 sa detailed
以下のコマンドにより、ML-KEM を使った IKEv2 SA が成立していることを確認できます。
Router#show crypto ikev2 sa detailed
IPv4 Crypto IKEv2 SA
Tunnel-id Local Remote fvrf/ivrf Status
1 198.51.100.10/500 203.0.113.10/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: 86400/2138 sec
CE id: 0, Session-id: 2
Local spi: 136C9DB85C7A2CAF Remote spi: 23A2FFDA654BC774
Status Description: Negotiation done
Local id: 198.51.100.10
Remote id: 203.0.113.10
Local req msg id: 3 Remote req msg id: 0
Local next msg id: 3 Remote next msg id: 0
Local req queued: 3 Remote req queued: 0
Local window: 20 Remote window: 20
DPD configured for 30 seconds, retry 5
Fragmentation not configured.
Quantum-safe Encryption using PQC: ML-KEM-768
Dynamic Route Update: enabled
Extended Authentication not configured.
NAT-T is not detected
Cisco Trust Security SGT is disabled
Initiator of SA : Yes
PEER TYPE: IOS-XE
IPv6 Crypto IKEv2 SA
この出力では、PQC Key Exchange: ML-KEM-768 と Quantum-safe Encryption using PQC: ML-KEM-768 が見えているので、ML-KEM を使った IKEv2 が成立していることが分かります。
show crypto ipsec sa detail
ちなみに IPsec そのものは AES-GCM 256 のままで、見た目には大きく変わりません。
Router#show crypto ipsec sa detail
interface: Tunnel4
Crypto map tag: Tunnel4-head-0, local addr 198.51.100.10
protected vrf: (none)
local ident (addr/mask/prot/port): (198.51.100.10/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (203.0.113.10/255.255.255.255/47/0)
current_peer 203.0.113.10 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 3, #pkts encrypt: 3, #pkts digest: 3
#pkts decaps: 2, #pkts decrypt: 2, #pkts verify: 2
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#pkts no sa (send) 0, #pkts invalid sa (rcv) 0
#pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
#pkts invalid prot (recv) 0, #pkts verify failed: 0
#pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
#pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
##pkts replay failed (rcv): 0
#pkts tagged (send): 0, #pkts untagged (rcv): 0
#pkts not tagged (send): 0, #pkts not untagged (rcv): 0
#pkts internal err (send): 0, #pkts internal err (recv) 0
local crypto endpt.: 198.51.100.10, remote crypto endpt.: 203.0.113.10
plaintext mtu 1426, path mtu 1460, ip mtu 1460, ip mtu idb Tunnel0
current outbound spi: 0x1A39FCB0(440007856)
PFS (Y/N): N, DH group: none
inbound esp sas:
spi: 0x150166A3(352413347)
transform: esp-gcm 256 ,
in use settings ={Transport, }
conn id: 2022, flow_id: ESG:22, sibling_flags FFFFFFFF80004008, crypto map: Tunnel4-head-0, initiator : True
sa timing: remaining key lifetime (sec): 3593
Kilobyte Volume Rekey has been disabled
IV size: 8 bytes
replay detection support: Y replay window size: 1024
Status: ACTIVE(ACTIVE)
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x1A39FCB0(440007856)
transform: esp-gcm 256 ,
in use settings ={Transport, }
conn id: 2021, flow_id: ESG:21, sibling_flags FFFFFFFF80004008, crypto map: Tunnel4-head-0, initiator : True
sa timing: remaining key lifetime (sec): 3593
Kilobyte Volume Rekey has been disabled
IV size: 8 bytes
replay detection support: Y replay window size: 1024
Status: ACTIVE(ACTIVE)
outbound ah sas:
outbound pcp sas:
ここで見えている transform: esp-gcm 256 は、IPsec の暗号スイート自体が急に別物になるわけではないことを示しています。
今回の主題はあくまで IKEv2 の鍵交換側に ML-KEM が入る、という点です。
なお、AES-GCM 自体は NIST で標準化された利用実績のある方式であり、CNSA 2.0 の文脈でも IPsec では AES-256-GCM が用いられます。Cisco IOS でも C800 シリーズのころからサポートされている方式であり、利用実績のある組み合わせだと言えます。
show dmvpn
とくに違いは認められません
Router#show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
T1 - Route Installed, T2 - Nexthop-override, B - BGP
C - CTS Capable, I2 - Temporary
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
UpDn Time --> Up or Down Time for a Tunnel
==========================================================================
Interface: Tunnel4, IPv4 NHRP Details
Type:Spoke, NHRP Peers:1,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 203.0.113.10 192.0.2.2 UP 00:23:06 S
Interface: Tunnel6, IPv4 NHRP Details
Type:Spoke, NHRP Peers:3,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 2001:db8:200::10
192.0.2.12 UP 01:26:27 S
2 2001:db8:200::11
192.0.2.21 UP 01:25:35 DT1
192.0.2.21 UP 01:25:35 DT2
2 2001:db8:200::12
192.0.2.22 UP 01:24:48 DT1
192.0.2.22 UP 01:24:48 DT2
Cisco C8235-G2 によるスループット試験の結果
あわせて、Cisco C8235-G2 ルータ同士を OCN のフレッツ 光クロス回線で接続し、iperf3 によるスループット確認も実施しました。
今回の試験では、PC 側インタフェースが 1Gbps までしか出せないため、そこで頭打ちになります。つまり、この結果はルータの限界というより、試験系のインタフェース上限に張り付いていると見るのが自然です。
実際の iperf3 は、10並列で以下のような結果でした。
$ iperf3-darwin -c 192.0.2.32 -P 10
[SUM] 0.00-10.00 sec 1.07 GBytes 922 Mbits/sec 1566 sender
[SUM] 0.00-10.01 sec 1.07 GBytes 919 Mbits/sec receiver
各秒のスループットもおおむね 911 - 929 Mbit/sec で推移しており、1GbE 環境としてはかなりきれいにラインレート近くまで出ています。
さらに、試験中の QFP 利用率を見ると、1分平均でも余力がかなり残っています。
Router#show platform hardware qfp active datapath utilization
CPP 0: Subdev 0 5 secs 1 min 5 min 60 min
Input: Priority (pps) 0 0 0 0
(bps) 0 0 0 0
Non-Priority (pps) 134318 140706 37470 3250
(bps) 1053053488 1089261656 292495856 24973112
Total (pps) 134318 140706 37470 3250
(bps) 1053053488 1089261656 292495856 24973112
Output: Priority (pps) 0 0 0 0
(bps) 0 120 128 128
Non-Priority (pps) 131991 140521 37467 3248
(bps) 989160328 1040896624 280383920 23958128
Total (pps) 131991 140521 37467 3248
(bps) 989160328 1040896744 280384048 23958256
Processing: Load (pct) 19 19 6 1
Crypto/IO
RX: Load (pct) 0 0 0 0
TX: Load (pct) 12 10 4 2
Idle (pct) 88 89 95 97
このとおり、1分平均で見ても
Processing: Load (pct) 19Crypto/IO TX: Load (pct) 10
にとどまっており、1GbEとはいえ、1分程度の継続試験でも datapath / crypto には十分な余力があり、少なくとも今回の条件では、PQC の導入による暗号処理負荷の増大は顕著ではないことが分かります。
アップグレードの順序に関する気付きと考察
ここは実運用で特に気を付けたいポイントでした。
今回の検証では、26.1.1 に上げた側で crypto ikev2 proposal default を使っている状態のまま、対向の DMVPN hub がまだ 17.18.2 のケースを確認しています。
その状態では、26.1.1 側からの IKEv2 が上がらず、hub 側では次のようなエラーが出ました。
*Apr 22 10:17:14.462: IKEv2-ERROR:Failed to parse the packet: The peer's proposal is invalid
*Apr 22 10:17:27.425: IKEv2-ERROR:(SESSION ID = 21,SA ID = 3):% IKEv2 profile not found
*Apr 22 10:17:27.425: IKEv2-ERROR:(SESSION ID = 21,SA ID = 3):Received Policies: : Failed to find a matching policyESP: Proposal 1: ENCRYPTION: AES-GCM-128 SEQUENCE: Don't use ESN
*Apr 22 10:19:24.513: IKEv2-ERROR:(SESSION ID = 32,SA ID = 3):: Failed to find a matching policy
*Apr 22 10:19:24.513: IKEv2-ERROR:(SESSION ID = 32,SA ID = 3):Initial exchange failed: Initial exchange failed
別のログでは、hub 側が受信した IKE proposal と、期待している proposal の差分も見えていました。
*Apr 22 10:19:24.512: IKEv2-ERROR:(SESSION ID = 32,SA ID = 3):Received Policies: : Failed to find a matching policyProposal 1: ENCRYPTION: AES-CBC-256 ENCRYPTION: AES-CBC-128 ENCRYPTION: 3DES ENCRYPTION: DES PRF: SHA1 PRF: MD5 INTEGRITY: SHA96 INTEGRITY: MD596 DH GROUP: DH_GROUP_1024_MODP/Group 2 DH GROUP: DH_GROUP_1536_MODP/Group 5 DH GROUP: DH_GROUP_2048_MODP/Group 14
*Apr 22 10:19:24.513: IKEv2-ERROR:(SESSION ID = 32,SA ID = 3):Expected Policies: : Failed to find a matching policyProposal 1: ENCRYPTION: AES-CBC-256 ENCRYPTION: AES-CBC-128 PRF: SHA256 PRF: SHA384 PRF: SHA512 INTEGRITY: SHA256 INTEGRITY: SHA384 INTEGRITY: SHA512 DH GROUP: DH_GROUP_256_ECP/Group 19 DH GROUP: DH_GROUP_384_ECP/Group 20 DH GROUP: DH_GROUP_521_ECP/Group 21 DH GROUP: DH_GROUP_2048_MODP/Group 14
このときの問題点は、26.1.1 では crypto ikev2 proposal default に自動で PQC 関連の設定が入り、17.18.2 側はその proposal を正常に扱えない、という点です。
今回のログから、pqcにoptional が付いていても、対向先が旧バージョンである場合、fail-back の成否以前に、旧バージョン側が proposal 自体を正常に解釈できず、ネゴシエーションそのものが成立しません。
特に DMVPN では、Spoke 側が initiator になって hub 側へ張りに行く場面が多いため、
- Spoke を先に
26.1.1に上げる - しかも
crypto ikev2 proposal defaultをそのまま使う
という条件が重なると、旧バージョンの hub 側で IKEv2 が不成立になります。
このケースの整理
- 26.1.1 では
crypto ikev2 proposal defaultに ML-KEM の設定が自動追加される - custom proposal には自動追加されない
- mixed-version 期間に
crypto ikev2 proposal defaultを使っていると、旧バージョン peer 側で proposal mismatch が発生する - 今回の実ログでも、hub 側で
The peer's proposal is invalidやFailed to find a matching policyが出ていた
つまり、crypto ikev2 proposal default の自動更新は便利ですが、事前にアップグレードプランを検討する事が重要になります。
回避策
実運用で取りやすい回避策は、次のどちらかです。
1. DMVPN hub (responder) から先にバージョンアップする
crypto ikev2 proposal default を使い続ける前提での現実的な workaround だと考えています。
旧バージョンの spoke から新バージョンの hub へは、従来 proposal のまま接続できる一方で、新バージョンの spoke から旧バージョンの hub へは crypto ikev2 proposal default の差分により IKEv2 のネゴシエーションに失敗していることが確認できました。
そのため crypto ikev2 proposal default を使っている DMVPN/FlexVPN/Static IPsec では、
- hub を
26.1.1へ先行アップグレード - その後 spoke を順次アップグレード
の順序にする必要があります。
2. crypto ikev2 proposal default を使わず、明示的な proposal を使う
こちらはより確実な方法です。
たとえば、mixed-version 期間は従来方式だけを含む proposal を明示的に使い、全 peer のバージョンが揃った後で pqc mlkem768 optional などを追加する方が、挙動を管理しやすくなります。
つまり、crypto ikev2 proposal default の自動更新に期待するよりも、
- どの proposal を使うか
- その proposal に PQC を入れるか
- どの順序で peer を上げるか
を明示的に設計した方が、アップグレード時の事故を減らしやすいということです。
strongSwan との異機種間 VTI IPsec 検証
また今回の検証では、Cisco 側を Cisco Secure Router 8000 シリーズ (IOS XE 26.1.1)、Linux 側を Debian 13 + strongSwan 6.0.5 として、異機種間で static な route-based IPsec を張ってみました。
Cisco IOS XE 側は static VTI、Debian 側は xfrm interface ベースで構成しています。Debian では distribution 標準の strongSwan では ML-KEM が使えなかったため、upstream の strongSwan 6.0.5 を .deb 化して導入しました。
Cisco IOS XE 側設定
今回の Cisco IOS XE 側設定は以下のとおりです。
pqc mlkem768 optional が設定されていることが確認できるかと思います。
crypto ikev2 proposal VTI-PROP
pqc mlkem768 optional
encryption aes-cbc-256
integrity sha256
group 19
!
crypto ikev2 policy VTI-POL
proposal VTI-PROP
!
crypto ikev2 keyring VTI-KR
peer DEBIAN
address 198.51.100.172
pre-shared-key 0 example-pre-shared-key
!
crypto ikev2 profile VTI-PROFILE
match identity remote address 198.51.100.172 255.255.255.255
identity local address 203.0.113.14
dpd 30 5 on-demand
authentication remote pre-share
authentication local pre-share
keyring local VTI-KR
!
crypto ipsec transform-set VTI-TS esp-gcm 256
mode tunnel
!
crypto ipsec profile VTI-IPSEC
set transform-set VTI-TS
set ikev2-profile VTI-PROFILE
トンネルインタフェース側は、例えば次のようなイメージです。
interface Tunnel100
ip address 169.254.100.1 255.255.255.252
tunnel source Tunnel0
tunnel destination 198.51.100.172
tunnel mode ipsec ipv4
tunnel protection ipsec profile VTI-IPSEC
Debian / strongSwan 側設定
Debian 側では swanctl.conf ベースで構成しています。PQC ありの最終形では、proposal を次のようにしました。ここで ke1_none は、追加鍵交換が利用できない場合に追加鍵交換なしでも成立できるようにする指定です。
今回の build でポイントだったのは、Debian 標準パッケージの strongSwan では ML_KEM_768 が使えなかったため、upstream の strongSwan 6.0.5 をビルドして .deb 化したことです。
特に OpenSSL backend で ML-KEM を有効化するために --enable-ml を入れ、systemd 管理で使うため --enable-systemd、不要な legacy 管理インタフェースを避けるため --disable-stroke を付けています。最終的には swanctl --list-algs で ML_KEM_768[openssl] と ML_KEM_1024[openssl] が見えることを確認しました。
ビルド方針
./configure \
--prefix=/usr \
--sysconfdir=/etc \
--enable-systemd \
--disable-stroke \
--enable-ml
設定
connections {
cisco-vti {
version = 2
local_addrs = 198.51.100.172
remote_addrs = 203.0.113.14
proposals = aes256-sha256-prfsha256-ecp256-ke1_mlkem768-ke1_none
encap = no
fragmentation = yes
dpd_delay = 30s
local {
auth = psk
id = 198.51.100.172
}
remote {
auth = psk
id = 203.0.113.14
}
children {
routed {
mode = tunnel
local_ts = 0.0.0.0/0
remote_ts = 0.0.0.0/0
esp_proposals = aes256gcm16
start_action = trap
dpd_action = restart
if_id_in = 42
if_id_out = 42
}
}
}
}
secrets {
ike-psk {
id-1 = 198.51.100.172
id-2 = 203.0.113.14
secret = "example-pre-shared-key"
}
}
インタフェース側は xfrm interface を使って、次のように 169.254.100.2/30 を持たせています。
ip link add ipsec0 type xfrm dev eth0 if_id 42
ip addr add 169.254.100.2 peer 169.254.100.1 dev ipsec0
ip link set ipsec0 up
show コマンドの流れ
まず Debian 側では、ML-KEM が有効になっているかを確認します。
swanctl --list-algs | egrep 'ML_KEM|ECP_256'
swanctl --list-sas
ip -brief addr show ipsec0
例えば、アルゴリズム一覧では次のような出力が見えます。
ML_KEM_768[openssl]
ML_KEM_1024[openssl]
ECP_256[openssl]
SA が上がると、strongSwan 側では ECP_256/KE1_ML_KEM_768 や TUNNEL が確認できます。
selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256/KE1_ML_KEM_768
CHILD_SA routed{1} established with SPIs ..., TUNNEL
Cisco 側では、次の順で追うのが分かりやすいです。
show crypto ikev2 sa detailed
show crypto session remote 198.51.100.172 detail
ping 169.254.100.2 source 169.254.100.1 repeat 3
今回の検証では、最終的に Cisco 側でも ML-KEM-768 を使った IKEv2 SA が確認できています。
Router#show crypto ikev2 sa detailed
IPv4 Crypto IKEv2 SA
Tunnel-id Local Remote fvrf/ivrf Status
2 203.0.113.14/500 198.51.100.172/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
Quantum-safe Encryption using PQC: ML-KEM-768
NAT-T is not detected
疎通確認も最終的には成功しました。
Router#ping 169.254.100.2 source 169.254.100.1 repeat 3
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 169.254.100.2, timeout is 2 seconds:
Packet sent with a source address of 169.254.100.1
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 8/8/8 ms
今回の検証では、最終的に UDP/500 と ESP を用いる通常の IKEv2/IPsec として安定して動作しました。strongSwan 側でも CHILD_SA は TUNNEL として入り、Cisco 側でも NAT-T is not detected が確認できています。
FRR による BGP over IPsec
あわせて、Debian 側に FRR を導入し、BGP over IPsec も確認しました。
隣接は、IPsec 上のトンネルアドレスである 169.254.100.1 と 169.254.100.2 の間で張っています。BGP セッション自体は問題なく成立し、Debian 側では対向からの prefix を受信できることも確認できました。
strongswan# show ip bgp
BGP table version is 13, local router ID is 198.51.100.172, vrf id 0
Default local pref 100, local AS 65001
Network Next Hop Metric LocPrf Weight Path
*> 198.18.4.0/24 169.254.100.1 0 65000 ?
*> 198.18.0.0/15 169.254.100.1 0 65000 i
*> 198.19.120.0/30 169.254.100.1 0 0 65000 i
*> 198.19.124.0/30 169.254.100.1 0 0 65000 i
192.0.2.0/24 0.0.0.0 0 32768 i
*> 198.51.100.0/24 169.254.100.1 0 65000 i
*> 203.0.113.0/24 169.254.100.1 0 65000 i
*> 203.0.113.64/27 169.254.100.1 0 65000 i
*> 198.51.100.128/25 169.254.100.1 0 65000 ?
*> 198.51.100.192/26 169.254.100.1 0 65000 ?
*> 203.0.113.128/26 169.254.100.1 0 65000 i
*> 203.0.113.192/27 169.254.100.1 0 65000 i
*> 198.51.100.64/26 169.254.100.1 0 65000 i
*> 198.51.100.96/27 169.254.100.1 0 65000 i
このとおり、IKEv2/IPsec の上に FRR を載せて BGP の経路交換まで確認できています。
ただし今回は lab 構成の都合で、この先の経路を有効化するとルーティングループになるため、BGP over IPsec は経路受信の確認までで止めています。少なくとも、ML-KEM-768 を使った IKEv2/IPsec の上で BGP セッションと経路交換が成立するところまでは確認できました。
Cisco Secure Router 8000 シリーズ と 旧シリーズとの違い
ここも少しややこしいポイントです。
Cisco Secure Router 8000 シリーズでは、26.1.1 から ML-KEM を使った hybrid IKEv2/IPsec がサポートされます。 一方で、
ISR1100 や Catalyst 8000シリーズルータ、 Catalyst 8000V ルータなどの Cisco Secure Router シリーズ以前の機種では、SSH の ML-KEM は利用可能なものの、ML-KEM を使った IKEv2 は利用できません。
たとえば、C8000V実機では以下になります
router(config)#crypto ikev2 proposal C8000V
router(config-ikev2-proposal)#pqc mlkem768 optional
Warning!! IKEv2 PQC is not supported on this platform.
このように Warning!! IKEv2 PQC is not supported on this platform. と表示され、設定が適用されません。
このあたりは「PQC に対応しているか」を一言で言ってしまうと誤解しやすい部分です。
- SSH での ML-KEM 対応
- IKEv2/IPsec での ML-KEM hybrid 対応
- PPK のサポート
これらは別々に見る必要があります。
特に IKEv2 で言うと、PPK がサポートされていても、それは ML-KEM hybrid 鍵交換のサポートとは別です。
ちなみに 17.11 以降で ISR1000 シリーズをはじめ多くの機種でサポートされている PPK であれば、以下のような見え方になります。
Tunnel-id fvrf/ivrf Status
4 none/none READY
Local 2001:db8:100::10/500
Remote 2001:db8:200::10/500
Encr: AES-CBC, keysize: 256, PRF: SHA256, Hash: SHA256, DH Grp:19, Auth sign: PSK, Auth verify: PSK, QR
Life/Active Time: 86400/2102 sec
CE id: 0, Session-id: 1
Local spi: C7BC734A85DAA0A6 Remote spi: E12D023D21BA9B79
Status Description: Negotiation done
Local id: 2001:db8:100::10
Remote id: 2001:db8:200::10
Local req msg id: 0 Remote req msg id: 0
Local next msg id: 0 Remote next msg id: 0
Local req queued: 0 Remote req queued: 0
Local window: 20 Remote window: 20
DPD configured for 30 seconds, retry 5
Fragmentation not configured.
Dynamic Route Update: enabled
Extended Authentication not configured.
NAT-T is not detected
Cisco Trust Security SGT is disabled
Initiator of SA : Yes
Quantum-safe Encryption using Manual PPK
PEER TYPE: IOS-XE
こちらは Quantum-safe Encryption using Manual PPK および Auth verify: PSK, QR と表示されており、PPK であることが分かります。
まとめ
Cisco IOS XE 26.1.1 で、Cisco Secure Router 8000 シリーズに待望の ML-KEM hybrid IKEv2/IPsec が入ってきたのは、PQC 対応としてかなり大きな前進です。
- Cisco Secure Router 8000 シリーズで ML-KEM hybrid IKEv2/IPsec の設定が確認できた
- 今回の対応により、RFC 9370 で標準化された IKEv2 の multiple key exchange の流れに沿って、ML-KEM を追加鍵交換として利用できるようになった
- Cisco IOS XE機種同士だけではなく、異機種 (strongSwan)との接続も確認できた
PQC といえばやはり IKEv2/IPsec、という目線で見ていた方にとっては、今回はかなりうれしいアップデートだと思います。
その一方で、crypto ikev2 proposal は crypto ikev2 proposal default だけ見て安心せず、実際に使っている proposal と tunnel の関連まで追うのが大事です。
特に注意が必要なことは、26.1.1 へのアップグレードで crypto ikev2 proposal default には ML-KEM の設定が自動で反映され、custom proposal には反映されません。
この挙動は、実機で show crypto ikev2 proposal や show crypto ikev2 sa detailed を見ないと気づきにくいところですし、アップグレードの順序を誤ると IKEv2 の接続に失敗するため、重要なポイントになります。
前回の SSH 側の PQC については、こちらもあわせてどうぞ。
関連リンク
- Configuring Quantum-Safe Encryption Using Postquantum Preshared Keys
- Cisco Secure Router 8000 シリーズ
- strongSwan の Algorithm Proposals (
ke1_mlkem768など) - NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard
- NIST FIPS 197: Advanced Encryption Standard (AES)
- NIST SP 800-38D: Galois/Counter Mode (GCM) and GMAC
- NSA Post-Quantum Cybersecurity Resources