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:[email protected]] > Envoyé : jeudi 28 mars 2019 20:37 > À : BOUCADAIR Mohamed TGI/OLN; 'Tero Kivinen'; [email protected] > 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:[email protected]] De la part de Tero Kivinen > > > Envoyé : jeudi 28 mars 2019 17:18 À : [email protected] 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 > > > -- > > > [email protected] > > > > > > _______________________________________________ > > > IPsec mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > > IPsec mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
