IP Security Maintenance and Extensions (IPsecME) WG. IETF 113 - Friday March 25th, 2022 11:30-13:30:00 UTC, 12:30-14:30 CET https://meetings.conf.meetecho.com/ietf113/?group=ipsecme&short=&item=1 # Agenda - Note Well, technical difficulties and agenda bashing - Chairs (5 min) - Document Status - Chairs (10 min) - Work items - Group Key Management using IKEv2 Valery Smyslov (20 min) - IKEv2 Optional SA&TS Payloads in Child Exchange William Panwei (10 min) - AOB + Open Mic (75 min) # WG Status Update Christian Hopps (CH): We are starting work on a Linux implementation of IPTFS. It would be good to reference an RFC rather than an Internet-Draft when submitting a patch. Valery Smyslov (VS): One more round is needed on draft-ietf-ipsecme-g-ikev2. # Work items ## Group Key Management using IKEv2 https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/ Valery Smyslov (20 min) Outstanding issues: - Changing Public Key in Rekey operations - OK? No opinions. - Using ports - should the unicast IKE SA switch from port 848 to 4500 if NAT is detected? VS: Yes. Tero Kivinen (TK): Yes. - Unregistration of a GM - is it needed? VS: no strict opinion. No other opinions. - AUTHORIZATION_FAILED vs REGISTRATION_FAILED - Which notification to use in which case? VS: AUTHORIZATION_FAILED for GM problem, REGISTRATION_FAILED for group problem. No other opinions. - Explicit PSK authentication - Is explicit mode needed for authentication based on symmetric shared secret for multicast rekey operations? Other mode: implicit. VS: No strict opinion. TK: if you have authentication and encryption keys, you can change the authentication keys faster than the encryption keys, although you would probably want to do that the other way around. Less options is better, so drop explicit. VS: I'll drop explicit in the next version. - Extended Sequence Number (ESN) - Use of ESNs in multicast Data-Security SAs is problematic and resource consuming. Should we make ESNs in this case SHOULD NOT or MUST NOT? TK: we could also put the high-order 32-bits of the ESNs when sending or updating the key material so that late joiners can quickly get the high order bits. VS: that won't work. Paul Wouters (PW): I don't like MUST NOT and might not like SHOULD NOT. Which leaves the resource-intensive method of finding out the high-order 32 bits. Scott Fluher (SF): this should be a MUST NOT because of complexity, but if you do it, you need to say how to implement it. A group member joining after the stream has gone for quite a while, the difference could be quite large and thus the process is very inefficient. Especially if the tested packet is not valid, because then you would be doing a lot of work. Yoav Nir (YN): unicast and multicast are very different. In unicast, you don't expect to miss 4 billion packets, but in group communications, you don't know if you are that far out of synch. TK: Group members who have the key and know the ESN might notify the GCKS every billion packets of the ESN. A joining node could then receive at least some guess from the GCKS of the general vicinity of the high-order bits of the ESN. That obviates the need for the GKCS to be a member of the group. VS: sequence numbers in multicast are not probably all that useful if you have multiple senders as they will be independently incrementing their idea of the sequence number. TK: agreed. Maybe we need text saying that you shouldn't use ESN unless you have one sender. And that sender should notify the GCKS of the ESN. VS: Or the sender could unregister, making a new Group SA necessary. Let's take this question to the mailing list. - Integration with RFC 8784 - is the attack described in the slides justification for developing draft-smyslov-ipsecme-ikev2-qr-alt? VS: no strict opinion. TK: If it is important for the application to protect against that, they can do an IKE SA rekey immediately. This is already mentioned in the PPK draft. - Using Tunnel Mode - In regards to the special Tunnel Mode with Address Preservation, how does the GCKS know if a SGW is participating in the group? Preconfiguration? Who controls if source addresses are preserved? TK: just keep transport mode, don't bother with this tunnel mode. Maybe we can get some input from the Transport Area. SF: the problem with transport mode is that the IP addresses aren't protected. VS: that's a good point. Lou Berger (LB): there is a working group on multicast. If you're not supporting on a mode in a base RFC, you can't just ignore a mode. - UDP encapsulation - If UDP encapsulation is needed for multicast Data-Security SAs, does it need to be signaled explicitly or implicitly? VS: no strict opinion. TK: If there's a NAT in the middle, multicast probably doesn't work. Non-NAT, multicast UDP might go through. But everyone has to get things the same way, either protocol 50 or port 4500. This can be done on a per-receiver basis. We can deal with this later via an extension if someone wants it. - Transport mode signaling - GSAs can have IPsec SAs created in tunnel mode or transport mode. How is the SA mode signaled? VS: I prefer to change the semantics of USE_TRANSPORT_MODE when used for G-IKEv2. TK: it would be simpler to not allow mixed modes. Use different groups for different modes. Let's get this out as simply as possible, as opposed to thinking too much about what someone might want at some point in the future. VS will issue a new version and asks for reviews, as this will be a large update. PW volunteered to review the document. ## IKEv2 Optional SA&TS Payloads in Child Exchange https://datatracker.ietf.org/doc/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt/ William Panwei (WP) (10 min) The authors this Internet-Draft are asking for WG adoption. PW: Plan on implementing it. VS: clarification requested for new notify is the SPI stored in the SPI field or in the notify data field PW: the new SPI is in the notify payload. TK: That is the correct way of doing it, the SPI fields in notify is to identify the existing SA this notify belongs, thats why you use notify payload data. TK: this isn't explicitly listed in our charter, but it seems like a minor update. I will check with our new SEC AD. Anyone objection to starting a WG adoption call? No objections from the participants. ## Any Other Business PW: I want to point out that for multi-SA, we have a Linux implementation that is not merged into the main line kernel until the document is approved. Feedback would be appreciated. VS: Any interest in beyond 64 kB payloads? TK: You should initiate discussion of the adoption of the above. It's within our charter. -- end--