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
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.
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/
Valery Smyslov (20 min)
Outstanding issues:
No opinions.
VS: Yes.
Tero Kivinen (TK): Yes.
VS: no strict opinion.
No other opinions.
VS: AUTHORIZATION_FAILED for GM problem, REGISTRATION_FAILED for
group problem.
No other opinions.
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.
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.
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.
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.
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.
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.
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.
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--