Re: [Anima] BRSKI over 802.11
Artur Hecker wrote: > Hi Michael, > My opinion: I don't think understood the question :-) 1) It's not about Wireless Access Points, so all of the Wifi Alliance, etc. talk makes no sense to me. There can be no access points until they have been configured. It's possible that there might NEVER been any access points, because the operator actually doesn't want/need any enabled. Think about inside of a cage in a data center. 2) It's about *devices* that have 802.11 interfaces. You can't use WPS or anything else involving 802.1x until you have credentials, which is what BRSKI gets you. So you can't use WPS to *bootstrap* WPS. (and pushing buttons on the front of the AP is by definition not "zero-touch") > 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. 3) The ACP is secured inside IPsec over Link-Layer IPv6 (or MACSEC, or a bunch of other possible technologies in the ACP document). It's not about the security of the ACP. Since the point of the ACP is that it's always available, it needs to be available even when the Wifi Access Point is toast or not yet configured. Of course, once there is a non-adhoc/IBSS network available, the ACP would see this as additional interfaces and make additional mesh links across it for the ACP to use. But that's not bootstrap, that's operation. > 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. Maybe you could point to specific documents that would permit two devices which have never been touched to communicate over 802.11 without configuration. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] changes to draft-richardson-enrollment-roadmap-01.txt
Htmlized:
https://datatracker.ietf.org/doc/html/draft-richardson-enrollment-roadmap-01
diff:
https://www.ietf.org/rfcdiff?url2=draft-richardson-enrollment-roadmap-01
I posted an -01 of the enrollment roadmap document. The intro says:
There are numerous mechanisms being proposed to solve the problem
of securely introducing a new devices into an existing managed network.
This document provides an overview of the different mechanisms showing what
technologies are common. The document starts with a diagram showing the
various components and how they go together to form five enrollment
scenarios.
The work crosses many groups, but does not fit into any of them.
The document might be good as a way to keep track of things, but may not be
worth publishing.
Yes, could go the wiki way, but I find it significantly less satisfying.
In particular I'd like to include guidance on why one process vs another,
which I think would be worth preserving.
On the other hand, there are sections explaining which documents are of
cross-WG interest, and if they have been adopted in any place (or not!!).
That's really ephermeral information that doesn't belong in an RFC until it's
been resolved.
It would also be nice to have a different name than "Transition to
Constrained Enrollment" that more accurately reflected the interests of that
group of deployers (it includes Lighting/Fairhair, and
electricity-AMI/Itron/Cisco.)
If there are those who want to review/contribute to it,
https://github.com/anima-wg/enrollment-roadmap.git might be the best place
to send pull requests. I'm personally not enthralled by using github issues
for discussion (I prefer email lists), but I don't object to it.
If there is interest in publishing it, my suggestion is to use iot-dir
to get some beef into it, and then submit as an AD-sponsored document.
Alternatively saag.
I think that the document should expand by about 4 pages of discussion, and
then sit in stasis for awhile.
The most significant change in -01 is that I changed how the boxes around
the ascii art diagram are rendered. I hope that it is more readable that
way. {If you haven't tried "asciio", I suggest you try it out.}
Other than that, more text in the sections.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] BRSKI over 802.11
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
[Anima] BRSKI over 802.11
<#secure method=pgpmime mode=sign> 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. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[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[ signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
