IP Security Maintenance and Extensions (IPsecME) WG.

IETF 119 - Tuesday, March 19th, 2024 15:30-17:00
https://meetings.conf.meetecho.com/ietf119/?group=ipsecme&short=&item=1

Agenda

• Note Well, technical difficulties and agenda bashing - Chairs (5
  min)
• Document Status - Chairs (5 min)

• Other items

  • Post-quantum Hybrid Key Exchange with ML-KEM in the IKEv2
  • ESP Echo Protocol
  • Shared Use of IPsec Tunnel in a Multi-VPN Environment
  • IKEv2 Support for Anti-Replay Status Notification
  • Using ShangMi in the IKEv2
  • IKEv2 IPv4 Downstream Fragmentation
  • IKEv2 DSCP Notification

• AOB + Open Mic (10 min)

Minutes

note being taken badly by Michael "mcr" Richardson

Note well, agenda bashing etc

Chairs

Some documents were waiting for small comments to be acted upon, but
that is being sorted now.

ACTION: ipsecme-g-ikev2 is actually waiting for Shepherd write-up.

ikev2-sa-ts-payloads-opt: waiting for implementation feedback, not sure
if they can actually tell the different between PARENT SA and CHILD SA
rekey.

ikev2-qr-alt: got some reviews from individuals, and thinks those issues
have been addressed. Once done, it is very close to WGLC.

ikev2-diet-esp-extension, diet-esp had actually expired, but once
reposted, have actually been successfully adopted as IETF IPsecME
adoption.

ike-tcp: is that actually a new document, or just a DT left-over, as
this document is actually an RFC? CONCLUSION: it's a DT hiccup due to
new DT feature. chair will move it to abandonned.

Post-quantum Hybrid Key Exchange with ML-KEM in the IKEv2

draft-kampanakis-ml-kem-ikev2
Scott Fluhrer

This is first user of IKEv2 multiple-key exchange document (9370).
Paul: should we specify the detail
Ben: is this still a hybrid?
Scott: (YES) this is before the DH.
Ben: we could make this generic for ML-KEM? we could have more KEMs.
MCR: adopt it, disagree with Ben.
Quynh Dang: analysis is that ML-KEM-512 is better than AES-128.
Guilin: some questions about the point, Kyber SHOULD NOT -768?
Scott: should not be used in IKE-INIT, because there is not enough space
in the packet.
TK: it's a UDP size limit, but in TCP it would be fine.
MCR: you can rekey with a bigger KEM.
Valery: Support adoption, useful document
Yoav: pile on... same thing we did with CHACHA/Poly. Big document in
CFRG that explained the algorithm, and then TLS/IPsec had small
document. Supports adoption.

ESP Echo Protocol

draft-colitti-ipsecme-esp-ping
Jen Linkova

Valery: points out that UDP encap can be done for IPv6, and IPv4 can be
raw.
Jen: who cares about IPv4!
Jen: it's about fate sharing.
Lorenzo: there exists network in which IPv4 ESP works (site to site)
works. But, unmanaged nodes are typically IPv4/NAT44.
Valery: please spell out the use case for this. If you use MOBIKE, then
maybe this can be used because IKEv2 session is already up. Say if this
is to be used with a human operator, or when automatically by IKE
daemon. The draft assumes 7/8, but should say TBD7/TBD8.
Paul: the problem on slide 4, distinguish an endpoint does not support
this, and an endpoint that is blocked, which is why there is an IKE
Notify that can say it is supported.
Jen: Lorenzo might have ideas, but for VPN/Remote-access, one knows
out-of-band that the server supports it.
Paul: but, some firewall thinks that <256 is reserved and drops it. When
are you going to probe and when you take action, and if those paths.
Lorenzo: we are not recommending any algorithm, and do not think we
should, this is a tool to determine if the path is clean. It can be used
for many things. if you know ESP-IPv6-UDPencap is not supported, then
don't use IPv6 at all.
TK: when we send the ESP Ping, we can get three things: ICMP Protocol
parameter issue, there no protocol=50, IKE message (rare), one thing you
can do is, if you get a reply, then you know you can ESP. If you get
nothing, then can compensate like MOBIKE.
Scott: in IKE ask for an dummy ESP to be sent,...
Jen/Lorenzo: it's a test in the wrong way.
TK: discussion of adoption on the list.

Shared Use of IPsec Tunnel in a Multi-VPN Environment

draft-he-ipsecme-vpn-shared-ipsecsa
Wei Pan

Paul Q, and then clarifies that the traffic inside of the tunnels is
overlapping. Not sure that we need something new.
Scott: Cisco addressed this issue 15 years ago, but we did not have the
scalability challenge. The overlapping.

Wei: operators would like to share the tunnels for many RANs.
TK: map the IPv4 to IPv6, or just use different IPv6 networks for each
VPN in order to avoid VPN-ID change to ESP.

IKEv2 Support for Anti-Replay Status Notification

draft-pan-ipsecme-anti-replay-notification
Wei Pan

Valery: second approach (unbinding ESN/anti-replay) looks more suitable
to me.
TK: one reason why the seq no is not negotiated, is because you have to
keep track of how often it wraps for ESN. so you can not get rid of the
monitoring of the seq number, even if you ignore it.
Paul: the problem is that when people turn off anti-replay for
performance reasons, they turn off ESN. "Linux Kernel is doing it
wrong"... NVIDIA melanox cards can turn off replay-protection and still
do ESN. One idea is to put entire 64-bit SEQ number into packet, instead
of just 32-bits. Indeed it is not negotiated, just negotiated.
TK: bring this back to list!

Using ShangMi in the IKEv2

draft-guo-ipsecme-ikev2-using-shangmi
Frank (Liang) XIA

Document is going via ISE, this presentation is for FYI. (just like
RFC9385)
Valery: use generic "Digital Signature" authentication method instead of
signature authentication tied to a specific algorithm (and define
AlgorithmIddentifier for this purpose)
Valery: some more details about how the keying material is derived would
be good.
Paul: draft asks for Standards Track, but the ISE route would not be std
track.
Dan: don't understand why there is a CBC mode requirement for a new
cipher? Nothing to be backwards compatible with.

IKEv2 IPv4 Downstream Fragmentation

draft-liu-ipsecme-ikev2-mtu-dect
Daniel Migault

... move right on to:

IKEv2 DSCP Notification

draft-mglt-ipsecme-dscp-np
Daniel Migault

MCR: are we trying to adopt these things?
TK: they may not be "minor" extensions, so unclear if this fits into
charter. Will verify from the area directors.

Scott: what does receiver do with these notifies?
Daniel: receiver doesn't have to do anything... no damage, but can
optimize things.
TK: Two sides can keep all the traffic into the same (set) of SAs

AOB + Open Mic

EOF