Re: [IPsec] Preliminary minutes for the IPsecME meeting

[<[e-mail]>]

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

> -----Message d'origine-----
> De : Valery Smyslov [mailto:[e-mail]]
> Envoyé : jeudi 28 mars 2019 20:37
> À : BOUCADAIR Mohamed TGI/OLN; 'Tero Kivinen'; [e-mail]
> Objet : RE: [IPsec] Preliminary minutes for the IPsecME meeting
> 
> 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.
> 
> > Hi Tero,
> >
> > Thank you for sharing the minutes.
> >
> > Please see inline a comment to Valery.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : IPsec [mailto:[e-mail]] De la part de Tero Kivinen
> > > Envoyé : jeudi 28 mars 2019 17:18 À : [e-mail] Objet : [IPsec]
> > > Preliminary minutes for the IPsecME meeting
> > >
> > > 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.
> >
> > [Med] The draft does not use error types but notification status types.
> >
> >  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
> > > --
> > > [e-mail]
> > >
> > > _______________________________________________
> > > IPsec mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/ipsec
> >
> > _______________________________________________
> > IPsec mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ipsec