IP Security Maintenance and Extensions (IPsecME) WG

IETF 112 - Monday November 8th, 2021 12:00-14:00 UTC
https://meetings.conf.meetecho.com/ietf112/?group=ipsecme&short=&item=1

Minutes by Paul Wouters, Donald Eastlake, and Jonathan Hammell.

Agenda bashing - no changes.

Agenda

• Note Well, technical difficulties and agenda bashing -
  Chairs (5 min)
• Document Status -
  Chairs (10 min)
• Work items
• IPTFS
  Christian Hopps (20 min)
• Quantum-resistant IKEv2 and big keys
  Stefan-Lukas Gazdag and Daniel Herzinger (10 min)
• Group Key Management using IKEv2
  Valery Smyslov (10 min)
• Announcing Supported Authentication Methods in IKEv2
  Valery Smyslov (10 min)
• AOB + Open Mic (55 min)

WG Status Update

Non-adopted documents not listed in the WG Status Report haven't had recent activity, so if editors wish to progress they will need updating.

Mohamed Boudacair (on Jabber): Question about draft-btw-add-ipsecme-ike.
Tero: Yes. I think that is ready and we should probably start an adoption.

Work items

IPTFS

Christian Hopps, draft-ietf-ipsecme-iptfs

WGLC completed in February 2021. Versions -08-11 cover post WGLC comments. Clarified that the reorder window should be small. Recommend use of drop timer instead of reorder window to address packet loss. One last issue from Tero (Oct 31) to resolve.

Tero presented on the problem he sees (slides-112-ipsecme-ip-traffic-flow-security-reorderlost-frame-issue-00).

Christian: The drop timer is meant to address the delay of inner packets when there is a lost frame.

Tero: If IPTFS is fixing reordering, that is a service IPsec wasn't defined for.

Christian: Indeed, we are also defining aggregation of packets and fixing the MTU issues with fragmentation, IPTFS is a new technologoy that does new things.

Christian: Reorder window is useful in non-constant send-rate scenarios. Drop timer fixes the issue.

Ben Kaduk summarized the discussion up to this point.

Christian: The drop timer determines the delay. The text should already indicate this.

Ben: Others in broader IETF may have thoughts on this.

Christian: Using MAYs in Tero's text allows for either behaviour. Should not wait to publish.

Ben: Prefer to pick a single solution that we are comfortable with.

Lou Berger: Protocols are not built to handle massive reorder windows. Some delay is acceptable. Seems risky to recommend SHOULD in Tero's text. It makes a strong assumption on applications. We don't have the operational experience. Could live with MAY.

Valery Smyslov: Processing in reordered flow may cause congestion when the group of inner packets sent. Transport recommendations should be in the draft.

Christian: This is still an area of study for the transport area.

Tero: Clarified that Valery was recommending documenting the effects of the different scenarios on the flow (will be bursty or delayed) but not on higher protocols.

Ben: There are many things we could document, but we might have to be careful about too much. There are many different applications and it will be difficult to give recommendations. Using MAY in both places in the text will allow for this.

Tero: Could live with MAY. Recommend renaming the 'drop timer' as 'lost timer'. Should also include a note on the burstiness of inner packets with out-of-order outer packets.

Lou: delay and burstiness is documented in the text already.

Yoav: Should have a recommendation for the length of the packet lost timer.

Deb Cooley (in Jabber): Timer could be proportional to the tunnel rate.

Christian: Will publish new draft based on the above agreements/comments.

Quantum-resistant IKEv2 and Big Keys

Stefan-Lukas Gazdag, Daniel Herzinger, slides-112-ipsecme-quantum-resistant-ikev2-and-big-keys-00

Motivation to use of McEliece KEM. Implemented IKE_INTERMEDIATE, Muliple-KE, and Beyond-64KB drafts, using UDP rather than mixed-mode. First slide 100 Mbps. As long as packet loss rate is not too high, around 10 seconds for SA establishment. May be acceptable for high-security scenarios. Second slide is 1 Mbps. The handshake takes much too long. This draft does not seem to be appropriate for this use case.

Large key sizes of McEliece could cause memory-exhaustion leading to denial of service attack. Recommend sending large KEs after the AUTH exchange.

Valery: Using UDP in unreliable networks is not desirable and is why mixed-mode was introduced. A single classical and single post-quantum exchange may not be desired in all scenarios; Multiple-KE gives much more flexibility.

Scott Fluhrer: Questioned whether a 20 second delay was acceptable. Often a single gateway talks to many clients coming in at the same time. How would this proposal be affected?

Daniel: Hopefully the central gateway would have more than 100Mbps throughput. You will likely run into problems.

Stefan-Lukas: The high-security use cases often have fewer connection end-points. McEliece is likely not appropriate for mobile workstation use case.

Valery: Tested with McEliece but without simulation of packet loss. It took 2-3 seconds to complete in my experience.

Group Key Management using IKEv2

Valery Smyslov, draft-ietf-ipsecme-g-ikev2

Motivation to secure IP multicast. Intended to be used in IEEE 802.15.9. Draft adopted in 2019, but underwent major rewrite in July 2020. Couple minor updates since, but editors think the draft is mature. More reviewers are needed.

Tero: Does the draft support IKE_INTERMEDIATE?
Valery: Likely, but not explicit in the text.

Tero: To start WGLC soon to encourage reviews.

Announcing Supported Authentication Methods in IKEv2

Valery Smyslov, draft-smyslov-ipsecme-ikev2-auth-announce

Unlike IKEv1, authentication method in IKEv2 is not negotiated. Problem first encountered when RSA-PSS was introduced in IKEv2; new initiators sent RSA-PSS, but received authentication failed from older responders.

Proposed solution adds new optional status notification SUPPORTED_AUTH_METHODS. Desire to avoid creating a new IANA registry. Three format options based on whether linked to CERTREQ.

Paul Wouters: Confusion between configured and supported authentication methods. The responder may not know which authentication methods to send since it does not know the identity of the initiator.

Valery: Provides "supported" methods for initiator and "configured" methods for responder.

Tero: To start WG adoption call.

Any other Business

Valery: Revised cookie processing draft awaiting adoption. Alternative mechanism for mixing pre-shared key draft is also waiting adoption. The existing PPK draft does not work well with G-IKEv2. Beyond 64KB draft is also waiting for adoption.

Tero: Please request adoption on mailing list.

Paul: Multiple SA draft looking for reviews. Removed QoS based on comments, simplifying the draft.

Christian: Expect to look at the Multiple SA draft relatively soon as we would have a use for it.

Christian: A new version of the IPTFS is posted based on earlier discussion.

Tero: That brings us to the end of this session.

-- end --