Markus Stenberg writes: > > I have no idea what littleconf-TOFU setup looks like, so cannot > > comment.. > > Guess I’ll come over and discuss this at some point (not sure how > much you have followed the 100+ message thread here).
I have skimmed through some of the emails, but not that well, so the security model of the bootstrap process is still unclear for me (I am not sure if it clear for anybody). > > 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. > > Hmmh. In G-IKEv2 case, I am not sure if it is this simple. Because > ultimately you want there to be only one GCKS (per link), but at > boot time, there is lots of raciness about who comes up first, and > decides they are one. > > i.e. > > router 1 boots up > -> anycast > (no reply) > > ~at same time router 2 boots up > -> anycast > (no reply) > > both think they can be the GCKS. I suppose one could define some > robust mechanics to make sure that ultimately you have only one > and/or share state between them so that it does not matter? I think there needs to be some kind of voting process to select the master for each network. This is something that is not really part of the multicast security or security in general, it needs to be defined by the homenet. Also the problem is not just simultaneous boot, but also partitions and reconnects, i.e. when someone unplugs ethernets and partitions the home network in two parts, both of the parts still need to function, i.e. both of parts need to make sure each of them have one master. When user then plugs them back together there is need to select new one. I do not know if that can be combined to the routing information, i.e. routers will know when the links go down and start the process of making sure connected parts of the network is served by master, and starting corrective actions when new links are connected. The corrective operations would most likely be run over unicast, i.e. when new network is connected the two parts have different multicast keys, so those cannot be used, so the master of network 1 could simply connect master of network 2 and they could agree who continues to be master, redistribute new keys, and rekey peers multicast keys so the whole new network has common keys. G-IKEv2 and IKEv2 or whether security protocol is used there, are just tools for such protocol, I do not think that protocol should be part of the the security protocol. -- kivi...@iki.fi _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
