Markus Stenberg writes:
> > There is also ikev2 version of group key management
> > (draft-yeung-g-ikev2), but the draft seems to have expired some time
> > ago. I still think it was supposed to be published.
>
> Ah, interesting, did not know about that. Thanks ;)
>
> > If homenet needs multicast support then it might be good idea to push
> > that document forward.
>
> How does this solution work with e.g. link-local-only
> littleconf-TOFU setup?
I have no idea what littleconf-TOFU setup looks like, so cannot
comment..
> To be more precise, I am not sure which node would be GCKS, and how
> other nodes would find that node. Based on cursory read of the
> draft, it seems to assume that non-GCKS nodes know GCKS address in
> advance.
As the G-IKEv2 uses IKE_SA_INIT from the IKEv2 for the first exchange,
the RFC5685 IKEv2 redirect with anycast address (see section 4 of
RFC5685) would work with it just fine.
I.e. the new device wanting to know the GCKS to talk to would send
anycast IKEv2 packet to the network:
Initiator Responder (any VPN GW)
--------- -------------------------
(IP_I:500 -> ANYCAST:500)
HDR(A,0), SAi1, KEi, Ni) -->
N(REDIRECT_SUPPORTED)
(ANYCAST:500 -> IP_I:500)
<-- HDR(A,0), N(REDIRECT, New_GW_ID, Ni_data)
(with G-IKEv2 the port number would be the normal G-IKEv2 port, i.e.
848, not 500).
I.e. now the router listening this link can reply to the anycast
request, with the proper gateway address (which might be his own, if
he is the one acting as GCKS).
The anycast support for redirect was meant to be used for
bootstrapping cases, i.e. where the client does not know yet who to
talk to.
> > I do not think replacing the IKEv2 with TLS would help at all. If you
> > go for application level protection then using DTLS or similar is
> > better than getting ESP involved at all.
>
> DTLS has rather sad multicast story too (=manually keyed IPsec
> without IPsec and draft-only at the moment). Of course, whether or
> not we really have to secure multicast at all in case of HNCP is
> debatable. However, as a general solution, it is somewhat lacking,
> as leveraging same thing for e.g. bit more multicast-heavy routing
> protocols would not work in case of DTLS (then again, I am not sure
> if GDOI / G-IKEv2 are much better due to them being mostly
> draft-only vaporware at this point).
At least the G-IKEv2 stuff is there, and the actual ESP use of
multicast has been defined for manual keys for quite long time (and is
in the RFCs already, not only drafts).
I have no idea if there is any implementations about the G-IKEv2, but
I doubt that there is anything to protect multicast ready now...
--
[email protected]
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
