[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec
Subject:    [IPsec] IPsecME Meeting minutes
From:       Tero Kivinen <kivinen () iki ! fi>
Date:       2021-11-08 14:50:16
Message-ID: 24969.14632.966850.894560 () fireball ! acr ! fi
[Download RAW message or body]

Here is IPsecME WG minutes. Thanks to minute takers, for making good
minutes and including enough of the discussion, especially for the
IPTFS issues. 
----------------------------------------------------------------------
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 --
-- 
kivinen@iki.fi

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


[prev in list] [next in list] [prev in thread] [next in thread]