IPsecME WG - IETF 106, Singapore Date: 2019-11-21 15:50-17:20 (90 min) Room: Olivia Chairs: Tero Kivinen , David Waltermire Scribe: Sean Turner Agenda ====== * Adminstrivia (5 min) * Agenda bashing, Logistics -- Chairs (5 min) * Draft status -- Chairs (10 min) * Work Items (25 min) * draft-tjhai-ipsecme-hybrid-qske-ikev2 Interop * draft-hopps-ipsecme-ipft * draft-ietf-ipsecme-labeled-ipsec * Other presentations (40 min) * draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt * draft-pwouters-ikev1-ipsec-graveyard * draft-smyslov-ipsecme-ikev2-qr-alt * draft-mglt-ipsecme-multiple-child-sas ------------------------------------------------------------------------------ Adminstrivia ============ (chairs) https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-chair-slides-02.pdf No agenda bash Draft status ============ (chairs) https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-chair-slides-02.pdf No comments. See slide 5-6. Work Items ========== QSKE Hybrid Interop =================== (Valery Smyslov) draft-tjhai-ipsecme-hybrid-qske-ikev2 https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-hybrid-qske-for-ikev2-interoperability-testing-event-01 S Turner: Consider: publishing to https://ietf.org/how/runningcode/implementation-reports/ Jonathan Hammell: Did you test child rekey? VS: No. David Waltermire: Plans to do so? VS: Yes once draft is adopted. Needs more list discussion. David Waltermire: Please post the feedback to the list, IP Traffic Flow Security ======================== (Christian Hopps) draft-hopps-ipsecme-ipft https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-ip-traffic-flow-security-00 VS: You seem to leave out transport mode? Any reason? CH: We only tunnel. We need to encsapsulte and shrink it and grow it. VS: Do you see a need for transport mode? CH: Transport Mode is the least secure because you give away souce and deestination. You are gicing away so much already why bother. VS: You want to allocate an IP protocol number? Is it only use on ? next protocol. Do you need it? CH: It's the scope of how the next header field. It's easier to get a new protocol number than redoing ESP registry. Ben Kaduk: IP # is kind of a big deal, the IESG give each other a heads-up when there's potential for allocating one. My second point is about the alignment question -- the general sense I get from the IETF as a whole is that if we have to be adding new protocol machinery for things like variable length paddding then there's not much interest in the rest of the IETF. Just adding a byte of padding so our fields are internally consistent is generally reasonable, if we can spare the space. CH: We would probably align on 32. Tero: For the protocol # since we only need it in inner esp trailer. We could just say there are multiple buckets inside. The other option is to use WRAP ESP. Third option is that since we negotiate in IKE we can say the final protocol is ignored becaue it has no meaning. Michael Richardson: If we use WRAP ESP that would be the protocol number of the outer or the next header within ESP? Tero: I would put it as the outer. Michael Richardon: When we do ESP ove UDP doesn't the outer say it's ESP so we don't know the protocol. Tero: WRAP ESP does explain how to do it over UDP. CH: We shouldn't be so freaked out about asking for an early allocation. Michael Richardson: I am supportive of making use of WRAP ESP. David Watermire: Tero please send some examples of how this might work. Chair: There is some consensus in the room to invistigate options that would not require a new IP # assignment. Options should be explored first before requesting assignment. Labeled IPsec Traffic Selector support for IKEv2 ================================================ (Paul Wouters) draft-ietf-ipsecme-labeled-ipsec https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-labeled-ipsec-00 VS: I think the second one is not really an option. Traffic selectors are a logical or. The third option is the most right from a formal point of view. It will lead to an explosition of types. Hu Jun: Don't like 3 one. Notify is a new rype to a tunnel not the child SA. PW: This would work for a child SA. Michael Richardson: Consider two things: 1 how would an implementation that doesn't support it respond, 2 is it useful for an endpoint will negotiate and end point that doesn't have? PW: It would be a failure - no tunnel would result. Michael Richardson: Not sure it matters which choice you make then. PW: Do that into account that I have a specific use, but other might want to support it. Michael Richardson: Unless these others complain just do you what you want. Tero: Prefer option 3. Ben Kaduk: Relaying Yoav from jabber: The notify payload seems better because nobody has ever defined new traffic selector types, but we have done notify types. Implementations might choke on a new TS type Daniel Migualt: Where is the label going to be used. Chair: Sounds like the 3rd option? PW: In theory 3rd option is nice, but 1st option is practially better. VS: It might be discussd on the list. Tero: Notify is bad because you know have to do tear downs if you don't need it. SPT: I agree with Paul -- 3 is what you'd do if you were perfect world, but 1 is the practical option that we have to do. We could hum for option 1 and confirm on the list. Tero: problem with option 1 is that it's not in any drafts. Postpone hum until we have something in writing. Michael Richardson: Just do humm for objection? Chair: If you understand what we're asking for in Option 1. [some hums, pretty quiet] Chair: any concerns with option 1? [one from jabber but none apparent in room] Chair: Write up what option 1 would like and go from there. Other presentations =================== IKEv2 Optional SA&TS Payloads in Child Exchange =============================================== (Wei Pan) draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-ikev2-optional-sats-payloads-in-child-exchange-00 Paul Wouters: What i do not like is that initiator can send the notify, but the responder can reject it. Because now I have a failed rekey. Does you responder dynmically decide to do this or not? WP: We think that for some products we will give the confurations on the responder side and this will occur immediately. Some products may not do this immediately. Paul Wouters: So now what you're saying you negotiate what you are willing to do, buyt soimewhat in the middle don't do it. Michael Richardson: Take the initial is AES-256, AES-128 but responder has only AES-128. They agree on AES-128. Now if responder policy changes to allow AES-256 (in addition to AES-128) then they can rekey and switch to AES-256. PW: It's not allowed you have to do the exact same parameters. You need to use the same parameters throughout. VS: I do not think this draft gives us enough optimization. For child SA it is slightly different beause you need pull traffic selector and it can be quite long. WP: It is their aim and we implemented it. Christian Hopps: Isn't it just possible that this is over engineered. Just tear the SA down so you can avoid the issues. What you chances of screwing it up. Paul Wouters: For the Child SA it is really useful. Tero: I don't like because it's just more options because it increases that chances of mistakes. Ben Kaduk (Yoav Nir): Why not just have one notification type? (since the context makes it clear which type of SA is being referred to). Chair: There is some IPR. Sean Turner: It says reasonable and non-discriminatory, with possibility for royalty-free. Tero: having to talk to IPR holder before implementing is annoying. Ben Kaduk: Need to update/review charter before adopting. Paul Wouters: We thought about the minor charter updates - this is minor extension WG and this is minor. Deprecation of IKEv1 and obsoleted algorithms ============================================= (Paul Wouters) draft-pwouters-ikev1-ipsec-graveyard https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-ikev1-graveyard-01 Dan: It says IKEv1 MUST NOT be deployed. Can't really say that. Tero: We closed the registry anyway programatically. Dan: Who did you tell? Tero: We sent a liaison. Ben Kaduk: We should send a liaison before we close them. Dan: we're doing the same kind of thing in TLS. Ben Kaduk: IESG will send it. Sean Turner: Will send some text about historic. An Alternative Approach for Postquantum Preshared Keys in IKEv2 =============================================================== (Valery Smyslov) draft-smyslov-ipsecme-ikev2-qr-alt https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-an-alternative-approach-for-postquantum-preshared-keys-in-ikev2-00 Daniel: This draft has been presented many times we should adopt it. VS: This is the first time. Tero: Who read it: 3. WP: Easy to understand and should be done. David Walertmine: Daniel and Paul volunteered to read the draft. Multiple SAs in one create child SA exchange ============================================ (Daniel Migault) draft-mglt-ipsecme-multiple-child-sas https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-draft-mglt-ipsecme-multiple-child-sa-00 Tero: I don't think we can do this with SPi nubmers. We had this in IKEv1, but only one person implemented and nobody wanted it. Need use case before implementing Daniel: You can extend SPI as long as you like. The use case is when you have multiple cores. Michael Richardson: Replay counter impacts. Ben Kaduk: All the Child SAs get the same traffic selectors. Daniel Migualt: Yes. VS: Remember there is an indiviation of # keying material because there is a counter so you can't interate on SP+ more than #. ... Daniel: .... Paul Wouters: I also thought about this a while ago. There are three use cases: 1) brigin up many Childs SAs with PFS for each one - Tero came up with a better solution, 2) To do more processing on CPU - you can do this on demand when a new CPU comes online, 3) For QoS you can just bring them up on demand. So this optimiztion is not really that I understand. Daniel: What to exchange 24 cores. Paul Wouters: At that point you got Gigs so why bother. Open Discussion ===============