Subject: [IPsec] Preliminary minutes for the IPsecME meeting

From: Tero Kivinen <[email-masked]>
Date: Thu, 28 Mar 2019 18:18:00 +0200

Here is the preliminary minutes for the todays IPsecME meeting. Thank
you for Yoav for taking the notes, and Paul for jabber scribing.

If you have any comments, corrections or additions to minutes, post
them as soon as possible. I will submit these to the meeting materials
early next week.
----------------------------------------------------------------------
IETF 104 IPsecME WG meeting in Prague
Thursday, March 28, 2019
10:50-12:20 Karlin 1/2

Agenda:
- Agenda bashing, Logistics -- Chairs (5 min)
- Draft status -- Chairs (10 min)
  - draft-ietf-ipsecme-split-dns
  - draft-ietf-ipsecme-qr-ikev2
  - draft-ietf-ipsecme-implicit-iv
  - draft-ietf-ipsecme-ipv6-ipv4-codes
- Work items
  - Intermediate Exchange in the IKEv2 Protocol - Valery Smyslov (10 min)
    - draft-smyslov-ipsecme-ikev2-aux-02
  - Post-quantum Key Exchanges in IKEv2 - Valery Smyslov (10 min)
    - draft-tjhai-ipsecme-hybrid-qske-ikev2-03
  - An implementor's view on Hybrid PQKE in IKEv2 - Tobias Heider (10 min)
  - PQC for IKEv2 in strongSwan - Leonie Bruckert (5 min)
  - ESP Header Compression and Diet-ESP - Tobias Guggemos (10 min)
    - draft-mglt-ipsecme-diet-esp-07
  - Labeled IPsec - Paul Wouters (10 min)
    - draft-ietf-ipsecme-labeled-ipsec
  - IKEv1 Graveyard - Paul Wouters (5 min)
    - draft-pwouters-ikev1-ipsec-graveyard
- Other presentations
  - IP Traffic Flow Security - Christian Hopps (15 min)
    - draft-hopps-ipsecme-iptfs-00

Agenda bashing, Logistics
=========================
Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-chair-slides-04

(no agenda bashing)

Draft status
============

draft-ietf-ipsecme-qr-ikev2 has a nit. Waiting for resolution to proceed
Valery: Nit is a false positive; will make it go away very soon.

Draft-ietf-ipsecme-ipv6-ipv4-codes
==================================

Tero talked about draft-ietf-ipsecme-ipv6-ipv4-codes
The room was polled about the alternate designs.
Valery: Use status notification states rather than error. Prefers
	Tero's design (over his own) 
Tero: Not enought people commenting here. Both are acceptable. Will
      take to the list. 

Intermediate Exchange in the IKEv2 Protocol
===========================================
Valery Smyslov - draft-smyslov-ipsecme-ikev2-aux-02
Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-intermediate-exchange-in-the-ikev2-00

Paul Wouters: Update 7296?  Because it changes the msgid of IKE_AUTH
Valery: Will check
PW: Silly to send an empty intermediate.  Need to know what to ef
Valery: An accompanying document will define what it goes there.
	Always need a new one. 
PW: rename to IKE_INTERMEDIATE, since this applies to IKE only
Valery: don't mind.
Tommy: Seems fine with msgid. RFC 7296 doesn't require it to be 1 for
       IKE_AUTH 
Tobias Heider: ??
Valery: This is just a framework document
Tero: It's OK to say this is just a framework. The documents that
      actually use it will define what goes in it. 
Tobias Guggemos: You can do PQ in IKE_INIT if you don't need IKE
       fragmentation.  
Tero: Too early for hum. Are we only going to ever have one?
Tero: Any objection for adoption?

    (crickets)

Tero: So will push the button and make this a WG draft (already asked
      on the list) 

Post-quantum Key Exchanges in IKEv2
===================================
Valery Smyslov - draft-tjhai-ipsecme-hybrid-qske-ikev2-03
Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-post-quantum-key-exchanges-in-ikev2-00

Surprisingly, a document using INTERMEDIATE IKE_INTERMEDIATE.  What
are the odds?

Tero: I would hate to see this happening: 7 key exchanges sharing the
      same type 4. These are complete key exchange - not the same thing as
      DH. Need a new registry - they'll probably have their own parameters.
Valery: They do the same thing as D-H: negotiate a key.
Scott: Specifically we wanted to allow doing this group, then this
      other, then an isogeny group.  This construct allows this to be
      done relatively straightforward. 
Tobias Heider: Like the idea of combining old (DH, ECDH) and new stuff 
Martin Fadman: Why the limit 7?
Valery: Arbitrary
Martin: Maybe this argues for the hierarchical idea. 
Valery: Scott things that in most cases different types will be used.
      We have three types, so let's double it 
Tero: Why negotiate all of this in the first SA payload? Interacts
      badly with parameters.  Maybe negotiate them one-by-one along
      the way? 
Valery: What you are proposing will complicate things. Better to
      negotiate in advance what is going to follow.  Maybe the
      responder doesn't support what you are going to require in the
      third round 
Mark ???: Having them all in one place is better
Scott: About parameters: transforms can have attributes. Regarding the
      size of the SA proposal: not a problem with the encoding of
      IKEv2 proposals, at least for sane policies 
Tero: will continue on the list (as we're running out of time)
Yoav: This is just for CCSA with PFS? We can still do CCSA without PFS 
Valery: Yes, and for rekeying of IKE SA
Mark: Support adoption
Tobias Heider: adopt, and rename to hybrid key exchange. Because it
      can be used with multiple classic D-H. 
Yoav: if we're adopting this should adopt also intermediate, and no
      point in adopting intermediate if we're not adopting this. 
Daniel Migault: Adopt, then make changes

An implementor's view on Hybrid PQKE in IKEv2
=============================================
Tobias Heider
Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-an-implementors-view-on-hybrid-pqke-00

Still controversy about breaking the PQ exhcnages out. Also with how
to accomodate McEliece (large keys) 
Yoav: Can define a new "extended-size" payload to accomodate >64K key exchanges.

PQC for IKEv2 in strongSwan
===========================
Leonie Bruckert
Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-pqc-for-ikev2-in-strongswan-00

Tobias Guggemos: We have 4 implementations. Maybe do a Hackathon?
Tero: You going to organize this?  Thanks!
Tobias: Yes, if you fly me to Montreal
Dave: Will take to the list

ESP Header Compression and Diet-ESP
===================================
Tobias Guggemos - draft-mglt-ipsecme-diet-esp-07
Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-esp-header-compression-and-diet-esp-00

(discussion on adoption will be done on the list) 

Labeled IPsec
=============
Paul Wouters - draft-ietf-ipsecme-labeled-ipsec
Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-labeled-ipsec-00

(already a WG draft. Discussion on Paul's proposed changed in
selecting TS types will be done on the list) 

IKEv1 Graveyard
===============
Paul Wouters - draft-pwouters-ikev1-ipsec-graveyard
Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-ikev1-graveyard-00

Tero: We don't instruct people what to use. We can't tell people what
      to use. 
Dan Harkins: IKEv1 is already obsoleted. What more do we need? 
PW: We want to tell people not to use it.
Smyslov: Support deprecating IKEv1
Benedict: Cannot get rid of 3DES.  Used in telephony.
PW: Yes, for now, but it's time for CAST

IP Traffic Flow Security
========================
Christian Hopps - draft-hopps-ipsecme-iptfs-00
Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-ip-traffic-flow-security-00

Valery: Interesting proposal. You fragment IP packets to arbitrary
	size and then re-assemble. This complicates IPsec
	implementation. I'd rather sacrifice some performance
	(efficiency?) by allowing combining but not fragmenting.
Christian: Let's discuss on the list
Paul Wouters: Privacy and compressing are different goals. Why do we
	      need the extra things.  
Christian: the 20,000% overhead.
Lou Berger: The present thing is not deployable. We're destroying the
	    available bandwidth with the trimodal distribution of packets. 

-- discussion to continue on list
-- 
[email-masked]

---

From: <[email-masked]>
Date: Thu, 28 Mar 2019 17:14:56 +0000

Hi Tero, 

Thank you for sharing the minutes. 

Please see inline a comment to Valery. 

Cheers,
Med

> -----Message d'origine-----
> De : IPsec [mailto:[email-masked]] De la part de Tero Kivinen
> Envoyé : jeudi 28 mars 2019 17:18
> À : [email-masked]
> Objet : [IPsec] Preliminary minutes for the IPsecME meeting
> 
> Valery: Use status notification states rather than error.

[Med] The draft does not use error types but notification status types.  

 Prefers
> Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-
> ipsecme-intermediate-exchange-in-the-ikev2-00
> 
> Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-
> ipsecme-post-quantum-key-exchanges-in-ikev2-00
> 
> Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-
> ipsecme-an-implementors-view-on-hybrid-pqke-00
> 
> Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-
> ipsecme-esp-header-compression-and-diet-esp-00
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tobias Heider <[email-masked]>
Date: Thu, 28 Mar 2019 18:36:11 +0100

> Tobias Heider: ??
The question I asked was:
The draft already says that INTERMEDIATE can not be used without another
document
that specifies what payloads are sent in INTERMEDIATE. Why can't that
additional
document also define it's own exchange ID for that instance of
INTERMEDIATE instead of using
the same ID for different things.

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 28 Mar 2019 22:36:54 +0300

Hi Med,

I know that your current draft doesn't use error type notifications,
as it was in its first version. My comment was too concise and thus
not clear enough. I just wanted to support Tero's ideas
to further simplify the design (and I suggested similar ideas before).
So I meant that there are still ways to make the draft simpler,
as it was done when you switched from error to status and reduced the
number of notifications. Sorry for not being clear.

Regards,
Valery.

> > Envoyé : jeudi 28 mars 2019 17:18 À : [email-masked] Objet : [IPsec]
> > Preliminary minutes for the IPsecME meeting
> >
> > ipsecme-chair-slides-04
> > ipsecme-pqc-for-ikev2-in-strongswan-00
> >
> > ipsecme-labeled-ipsec-00
> > ipsecme-ikev1-graveyard-00
> >
> > ipsecme-ip-traffic-flow-security-00
> >

---

From: <[email-masked]>
Date: Fri, 29 Mar 2019 06:43:09 +0000

Hi Valery,

Thank you for sharing your thoughts. 

As shown in the slides presented in the meeting, both approaches are acceptable and simple. There is a difference at the server side though: in the approach currently documented in the I-D, the code is blindly returned (i.e., the code is explicit about the capability) while in the other one the code is returned as a function of the requested address. 

I personally like explicit codes as this is helpful for troubleshooting at the initiator side when problems are encountered. 

That's said, I don't have a problem to make the change if this is what the WG wants. 

Cheers,
Med

> De : Valery Smyslov [mailto:[email-masked]]
> Envoyé : jeudi 28 mars 2019 20:37
> À : BOUCADAIR Mohamed TGI/OLN; 'Tero Kivinen'; [email-masked]
> Objet : RE: [IPsec] Preliminary minutes for the IPsecME meeting
> 
> Hi Med,
>