Re: [IPsec] comments on draft-ietf-ipsecme-g-ikev2-07

[Valery Smyslov <[e-mail]>]

> > Unless I'm missing something, it's not immediately clear for me how you want
> > to use HPKE here. Can you clarify?
> 
> Similar to how MLS is using it to (re)generate  the keys for the binary tree. They addressed the same
> problem of having a group and members joining and leaving and ensuring left members can’t decrypt
> new messages anymore.

It seems to me taht the requirements for MLS and G-IKEv2 are a bit different.

In G-IKEv2 (or generally in GDOI architecture) we have a group controller,
which have a complete view of the group (it manages membership and generates
and distributes all the multicast keys). Generally speaking, the controller may be
out of the group (i.e. it may have no data to send to the members or to receive
from them other than multicast keys).

In my understanding in MLS there is no such a controller, the group is managed 
by its members and the keys are constantly updated by all members.

In other words, in G-IKEv2 group management and key distribution
is centralized, which is not the case for MLS. I didn't look into MLS
deeply, but it seems to me that it is more suitable for low-bandwidth
communications (like group chat), while G-IKEv2 approach is more 
appropriate for high-speed communications (e.g. live broadcasting).

And you may want to know that there is a mechanism in G-IKEv2
that allows excluding group members (so that they cannot decrypt multicast data anymore) 
using only multicast messages (yes!). It is called LKH (Logical Key Hierarchy)
and is currently a part of G-IKEv2 document. Such mechanisms are pluggable,
more can be defined in future.

Regards,
Valery.