IP Security Maintenance and Extensions (IPsecME) WG.

IETF 114 - Monday July 25th, 2022 15:00-17:00 EST
https://meetings.conf.meetecho.com/ietf114/?group=ipsecme&short=&item=1

Agenda

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

• New Work items

  • IKEv2 Downstream Fragmentation Notification Extension - Daniel
    Migault (20 min)
  • IKEv2 Count Based SA Extension - Daniel Migault (20 min)
  • IPsec Multi SA - Paul Wouters (10 min)
  • Charter Update and Status - Chairs (10 min)

• AOB + Open Mic (40 min)

Note Well, technical difficulties and agenda bashing

Chairs

Document Status

Chairs

Valery: g-ikev2: needs more reviews
auth-announce: not ready for WGLC, but review is helpful.
add-ike: stable and ready for WGLC

Christian: IPTFS source code finally published on github

Tero: ietf has a registry for this too, please publish URL there too

New Work items

IKEv2 Downstream Fragmentation Notification Extension

Daniel Migault

Valery: Must get transport area review, there are transport issues
Message with MTU size shows no response packet. IKEv2 requires response
packet

Yoav: IESG transport area does review.

Valery: yes but with earlier draft they said we did everything
wrong. contact them sooner in process

Tero: I see no need for SUPPORTED notify.

Paul: you do or else you send useless MTU notify exchanges

Tero: True, but we only need to send MTU notify if mtu changes, or
we could defined it so that if other end supports this it will respond
with similar notify, and that will indicate support.

Tero: 32 bit MTU value is wrong, should be 16 bit

Tero: point 3. MAY perform outer fragmentation. If done midway,
gateway won't see this

Tero: leave outer fragmentation to the network. This notify could be
kind of same as Packet Too Big except comes within our layer leave "how
to avoid this" out of the draft.

Paul: Dont define process how to handle fragmentation, just note
this requires IKE/kernel information exchange

Chris: Use RFC 8899. Using the IKE packets to run 8899

Antony: Note, NAT encapsulation might get different path from IKE,
so individual 8899 process. Also Protocol 50 ESP and IKEv2 UDP might get
different processing by middleboxes for fragmentation.

Daniel: It is easy to get the MTU size

Chris + Tero: No it is not easy. hence RFC 8899

Yoav: Could also be different per Child SA because it traverses a
different network. So not IKE peer to IKE peer

Tero: Discuss more on list. If we talk about how to handle
discovery, goes outside of charter

Tero: are people interested? ... Talk more on list.

Daniel: first item is to talk to transport area? Anybody good to
contact?

Several people: Joe Touch

IKEv2 Count Based SA Extension

Daniel Migault

rekeys requires briefly multiple SA's, resulting in reduced capability
on hardware with fixed max SA support, but real issue is the reduntant
SAs created by the simultaneous rekeys.

Tero: in/outbound traffic pattern is different, so rekey never
happens at the same time. I don't see issue. It is implementation
guidance
We removed bytes/lifetime/etc decisions out of IKEv2, and it is not
negotiated by design. Each peer can decide themselves.
This caused issues in IKEv1 - negotiated values were causing rejected
connections.

Paul: I am confused again. is the problem to solve simulatious
rekeying, or rekeying causing multiple SAs in general

Tero: I think simultaneous rekeying

Valery: I agree with Tero. Need for limits comes from cryptographic
needs. No point counting bytes in receiving side, damage has been done
already
Count number of bytes sent, not received.
You can only reliably count sending count, you might not see every
packet that was sent to you, so your receiving count will be wrong.
If the receiving side is supposed to do the rekey, based on the protocol
described in the draft, then if there is lots of packets dropped on the
receiving side, it might not reach the rekeying limit before the other
end runs out of its hard limit, if counting received bytes and there is
packet loss.

Chris: Aren't these user settable values. Couldnt you just set the
values different? Maybe a BCP document? It is really implementation
detail

Paul: see rekeyfuzz= options of libreswan and strongswan

Daniel: We want 1 configuration file

Paul: time based more likely to happen simultaniously. Bytes
counters for in and outbound is useful for one end to prevent hitting a
cryptographic safety limit with very large safety margin :)

Yoav: Use the original initiator and responded to select who does
rekey etc.

Tero: In old code we had lifetime multiplied by constant and minus
some constants. Different values for initator/responder

Tero: no internet protocol draft, seems better to have BCP document
or informational implementation guidance

IPsec Multi SA

Paul Wouters

Valery: just read it, like it, have comments to possibly make it
simpler

Chris: good idea, did you talk to VPP people?

Antony: We talked to them, they use additional IPs to get "multiple
tunnels"

Paul: Object or do WGLC :)

Charter Update and Status

Chairs

Paul: note no update to ikev2-sa-ts-payloads-ops because we think we
are done, ready for WG adoption

Daniel: diet ESP, should be done in the IPsecME WG, want to
harmonize with SCHC or similar work.

Valery: cookie revised ready for WG adoption. Minor problem but real
problem to address.

Valery: beyond-64k-limit: developed but thought that NIST will
select McLiese, since NIST didn't select it less important. But it is
still in the race. Also BSI (germany national security) still recommends
it. WG should decide. Another idea in draft is mixed transport mode,
maybe useful for other things. Even selected signature algorithms for
sphinx+ it is about 55kb. Still requires some mechanism to deliver even
with IKE fragmentation. Eg use IKE over TCP, while doing ESP native or
using UDP.

Tero: this is part of our current charter, postquantum is in
charter, so >64kb will be in charter if proposals in few years need it.
Probably wait for NIST action then come back to this and work on it. As
it will still take several years. Would suggest we put on hold for now.
Does that sound okay ?

Valery: I agree, we can hold and wait for next NIST decision.

AOB + Open Mic (40 min)

Valery: is there any interest in PAKE and IKEv2

Tero: What should the WG do? We have older methods that are
individual ones. Not sure if we want to go back to that

Valery: should we promote it to the next track

Paul: seems not widely deployed, so promoting it to Internet
Standard seems wrong

Paul: If you want to see multi-sa demo, see Steffen Klaaser here

End