Hi Michael,
My opinion: Q1: In principle, I believe that it would make sense to do it. However, a different question is whether ANIMA WG of the IETF is the right place for it. For instance, the integration of WPA-Enterprise you mentioned had been done by the WiFi-Alliance, albeit heavily relying on IETF protocols (RADIUS, PPP, EAP, Microsoft's MPPE, VSAs, etc). Q2: Specifically, the relevant issues would seem to rather fall into the scope of IEEE 802.1 (for the supplicant), IEEE 802.11 (for the wireless client) or of the WiFi Alliance (for integration, etc). We need to consider their way(s) of specifying all that. For instance, one could argue that the bootstrapping should be done over the DS, whereas whether the DS itself is wireless or not should not play any role. In this case, I believe it would be wrong to define ESSIDs or modes of operation of 802.11, because it's extremely biased. I am not even talking about OAM, because I do not want troubles :-) Q3: Sorry, I did not quite understand this one. If you meant the ad-hoc essid based network, my first intuition would be to object, as I believe that we should not prescribe such modes for ACP, but rather use the best available one. Q4: As I believe that Q2 is strongly biased, I believe that so is Q4. The WiFi Alliance already specifies several ways how to bootstrap wireless access points, including e.g. WPS. We would rather need to see, how to integrate with such means. And again, I don't believe we have authority on that. Regards artur > -----Original Message----- > From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Michael > Richardson > Sent: 07 February 2018 17:00 > To: anima@ietf.org > Subject: [Anima] BRSKI over 802.11 > > > Q1) Is there interest in doing bootstrap of devices/routers/etc. over WIFI? > > Q2) If there is, should the BRSKI document proscribe an Ad-Hoc (IBSS) ESSID > on which bootstrap would be done (perhaps named "BRSKI" or "ANIMA"). > > Q3) Would you want to use this network as a substrate for the ACP later on? > > Q4) Should such a network be > a) unsecured (cleartext) > b) use WPA-PSK with a known "network key" > b) use WPA2 enterprise 802.1X using a published username/password. > (like we use for ietf network) > This is no less secure than unsecured, but unlike (b), each > session gets a unique session key. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails > [ _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima