Here is preliminary minutes, if you have any comments, additions etc
to them, send them to chairs. Thanks to mcr to taking the minutes.
----------------------------------------------------------------------
# IPsecME WG
## IETF 105, Montreal
* Date: 2019-07-23
* Time: 15:20-16:50 (90 min)
* Room: Sainte-Catherine
* Chair: Tero Kivinen
* Chair: David Waltermire
---
## Agenda
### Adminstrivia (5 min)
* Agenda bashing, Logistics -- Chairs (5 min)
1) Paul asks about Graveyard draft, Chairs mention that authors need
to push, chairs won't pull.
Paul says that it is ready for WG Adoption Call.
### Draft status -- Chairs (10 min)
* draft-ietf-ipsecme-implicit-iv
- Implicit IV for Counter-based Ciphers in Encapsulating Security
Payload (ESP)
Already in publication requested
* draft-ietf-ipsecme-ipv6-ipv4-codes
- IKEv2 Notification Status Types for IPv4/IPv6 Coexistence
WG LC will be issued shortly
* draft-ietf-ipsecme-qr-ikev2
- Postquantum Preshared Keys for IKEv2
Already in publication requested state
Apple is shipping Postquantum in iOS 13
### Other issues
--- call for experts for independent review of candidate/nominated
specifications for PAKE for CFRG.
Valery, framework for PAKE is RFC6467, integration for IKEv2 PAKE.
Experimental RFC.
### Work Items (25 min)
* draft-ietf-ipsecme-ikev2-intermediate -- Valery Smyslov (5 min)
- Intermediate Exchange in the IKEv2 Protocol
INTERMEDIATE->IKE_INTERMEDIATE.
Thinks this is the last rename.
It can not be resumed.
How the IKE_INTERMEDIATE exchange is included in the AUTH has changed again.
authenticated as if it were sent unfragmented
peers may disagree on length field in the headers, e.g. by padding
differences.
-> remove the length fields.
Should be ready for WG LC soon
* draft-ietf-ipsecme-labeled-ipsec -- Paul Wouters (5 min)
- Labeled IPsec Traffic Selector support for IKEv2
went back to previous version of the format.
opaque blob with a >0 length
Valery pointed out that the text restricts ability for a responder to
select more than one TSi (if proposed). Paul replies that this was
unintentional, and will be removed.
Also should be ready for WG LC soon
* draft-yeung-g-ikev2 -- Valery Smyslov (15 min)
- Group Key Management using IKEv2
Is the GSA_REKEY signed (assymetrically) by Initiator?
YES, there is this [AUTH] payload (optional, could be symmetric key
only).
Large step forward since IETF99, more implementations interoperated
before, but significant changes which need to be retested.
MCR asked if there was really the multicast expertise of
implementors in the WG. Tobias Heider from U of Munich answers in
Jabber.
Should be ready for WG Adoption call.
### Other presentations (35 min)
* draft-tjhai-ipsecme-hybrid-qske-ikev2 -- Valery Smyslov (10 min)
- Framework to Integrate Post-quantum Key Exchanges into Internet
Key Exchange Protocol Version 2 (IKEv2)
Do we need fresh nonces in every IKE_INTERMEDIATE?
Scott Fluhrer says that the nonces are for nonces, and we have
already proved things by completing the first AUTH.
Tero: Why are you using INFORMATIONAL for additional
information?
Valery: Because we want to have the same properties as the
first, and INFORMATIONAL is wildcard.
Paul suggests using new exchange called "SA_INTERMEDIATE"
Tobias (jabber): +1 on Paul.
MCR: asks about how the state machine can be verified without
having some QSKE to chain to?
Scott: Proposed they could use group 18, which is already big.
Tero: There has also been some interest to add 12k and 16k DH
keys, they would be even larger.
Tobias Heider: mic: We at LMU Munich are actually working on a
formal verification model to make sure the state machine is working
Should be ready for WG Adoptation call.
* draft-hopps-ipsecme-iptfs -- Christian Hopps (10 min)
- IP Traffic Flow Security
Added a don't fragment bit.
moved congestion control from out-of-band to in-band.
David Black: Transport experts were asked, and it looks like they
got it right.
Valery: the purpose is to fill as much data as possible?
No: the purpose is to hide the data size.
Valery: for a fixed packet size, you want to put as many data as
possible? Did you consider to reduce the size of the reserved
fields?
Yes, considered ways to eliminate the header all-together. The
implementations will either set to the largest MTU, or will do
Path MTU in general.... but alignment is good.
Paul: you are using a traffic selector to request this?
No, it's a transform selector.
Yoav: not only is this supposed to do, but IKEv2 was supposed to
do this properly from the start.
Tero: the measurement, was it done with real traffic, or ??
Chris: it was done with I-Mix traffic distribution?
Tero: asks about latency? you can't wait for long time because of
TCP ACKs
Chris: yes, there is a latency problem, and so there is an
challenge.
This is not part of our charter, we need to recharter to include
this. There seems to be enough
interest for this work, so chairs will propose new charter item to ADs.
* draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt -- Wei Pan/Sandeep
Kampati (15 min)
- IKEv2 Optional SA&TS Payloads in Child Exchange
MCR: hypothesis that rekey situation 3 is not interesting, that
most will just kill (IKE) SA and restart.
Scott reports that his products will apply the new policy to the
CHILD SA without killing IKE, i.e., using rekey.
Bharath Meduri: For ACL Change Kill all and create new. but for
crypto just allow after reky
Paul points out that we should never have send the TSx on rekey, so
that nobody could change them by mistake.
Valery: suggest that it is not useful for IKE, and that maybe just
do this for Traffic Selectors, and not SA properties.
Tero: if you are rekeying that you are using the same thing, then
this makes sense, just rekey, i.e., send REKEY_SA notify, and
include new SPI there, and leave the SA and TS payloads out. Just
do not bother rekeying the IKE SA, so what's the point of
optimizing this. If you do so much that the algorithms or TS are
changing, then it isn't a REKEY.
Tero says that is in the charter, as it fits into compressing
IKEv2.
Tero suggests that there is enough interest.
Document will get a WG Adoption Call.
Other business:
Paul: no-one from NIST is talking about new document.
Revision-1 guide to deploying IPsec VPNs.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
