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--