There's an additional consideration that might be worth pulling out here. And it's not an impact on network operations, it's a potential for applications that interact with these network services to undo the work of lower parts of their stack.
For instance, if your device connects to the same network and the same captive portal it might open a web browser to connect to that portal. If the web browser presents the cookies it received from the portal last time they talked, it undoes the work of the OS. Now, some implementations use these nasty browser-like things with aggressive sandboxing that don't save cookies. That comes with other costs, but it addresses the problem up until the point that the network connection is restored and then who knows what happens once the pseudo-browser is no longer involved. Maybe that is out of scope for your draft, but it shouldn't be out of scope for a group that attempts to look more closely at providing advice for dealing with these features. (Does this thread really need to be cross-posted so widely? Can we decide on a single venue?) On Wed, Sep 23, 2020, at 07:24, Lee, Yiu wrote: > Noted and clear. Will keep this in mind in the next update. > > Thanks, > Yiu > > On 9/22/20, 5:18 PM, "Stephen Farrell" <stephen.farr...@cs.tcd.ie> wrote: > > > Hiya, > > On 22/09/2020 22:08, Lee, Yiu wrote: > > Hi Stephen, > > > > Thanks for the notes. Actually, we believe that there are good > > privacy reasons to randomize mac-address. This BoF isn't trying to > > "fix" randomized mac-address. On the contrary, we want the community > > to embrace it. In order to ease the anxiety for transitioning, we > > want to document what may break and propose best practice to > > transition to dynamic mac-address. > > Sure, I get that. However, we've seen a number of these > efforts start thusly but end up being perceived to be > partly trying to unwind the privacy benefits, so I think > a good way to avoid that mis-perception is to also present > the reasons for (in this case, MAC address randomisation) > as fully as the description of the challenges caused. > > Cheers, > S. > > > > > > Thanks, Yiu > > > > > > On 9/22/20, 4:51 PM, "Int-area on behalf of Stephen Farrell" > > <int-area-boun...@ietf.org on behalf of stephen.farr...@cs.tcd.ie> > > wrote: > > > > > > That agenda and draft seem to make the seemingly common enough > > mistake of only focusing on what a new privacy or security > mechanism > > breaks and glossing over the good reasons why people introduce > these > > mechanisms. I hope the BoF proponents fix that because otherwise > they > > may end up giving the impression that they would prefer to not see > > the privacy benefits (which I'd guess is not their goal at all). > One > > reason those good reasons need to be included is that they > constrain > > the kinds of additions that might make sense to better handle the > new > > mechanism. > > > > We've seen a number of these kinds of reactions and I figure it'd > > really be better if the reaction were not to appear purely > > reactionary;-) > > > > If that were fixed, then there may be a better discussion of > what, if > > any, additional things need doing. If that is not fixed, I'd not > be > > surprised if the putative BoF were to devolve into a "it's bad" > vs. > > "no, it's good" bun fight that won't really take us further. > > > > Cheers, S. > > > > On 22/09/2020 21:40, Michael Richardson wrote: > >> > >> Damn. Spelt captive-portal without the s again. Reposting, sorry > >> for duplicates. I hate when WG names and list names do not match, > >> and that we can't have aliases. And I think that reply-to gets > >> filtered. > >> > >> Archived-At: > >> > <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/int-area/14Skgm84GslPZ9UcGoWY3uzmK6I__;!!CQl3mcHX2A!Q0pEjWrLTcmcryUR2EMbSc6uWBNU-xJadaznxWvwmDk2-ARoR0DYYq_eprXSEjo$ > >> > To: int-a...@ietf.org, captive-por...@ietf.org, > homenet@ietf.org > >> From: Michael Richardson <mcr+i...@sandelman.ca> Date: Tue, 22 > Sep > >> 2020 16:34:33 -0400 > >> > >> This thread was started today on the INTAREA WG ML. > >> > >> While I don't object to a BOF, I don't know where it goes. What I > >> see is that much of this problem needs to be resolved through > >> increased use of 802.1X: making WPA-Enterprise easier to use and > >> setup, this changing core identity from MAC Address to IDevID. > >> > >> My understanding is that Apple intends to randomize MAC every 12 > >> hours, even on the same "LAN" (ESSID), and that they will just > >> repeat the WPA authentication afterwards to get back on the > >> network. If the per-device unique policy (including CAPPORT > >> authorization) can be tied to the device better, than the MAC > >> address based "physical" exception can be updated. > >> > >> But, WPA-PSK doesn't work, because it does not, in general, > >> distinguish between different devices. > >> > >> It can be made to work if every device is given a unique PSK, and > >> there are some successful experiments doing exactly that. Mostly > >> it just works, but the challenge is communicating the unique PSK > >> through an unreliable human. BRSKI can certainly do this, and it > >> can leverage that unencrypted ESSID present at most hospitality > >> locations to get onto the encrypted WPA-Enterprise. Or > BRSKI-TEEP, > >> or some other BRSKI-EAP method. The unencrypted SSID is not > going > >> away at those locations. > >> > >> Thus QR-code based methods are best, yet those do not work for > many > >> IoT devices. EMU's EAP-NOOB can help in certain cases, but we, > as > >> a community need be clear on what direction we want to go. One > >> answer is that IoT devices have little reason to randomize their > >> MAC if they are not generally ported. > >> > >> > >> On 2020-09-22 3:49 p.m., Lee, Yiu wrote: > >>> Hi team, > >>> > >>> We proposed a BoF. The agenda is in > >>> > https://urldefense.com/v3/__https://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md__;!!CQl3mcHX2A!Q0pEjWrLTcmcryUR2EMbSc6uWBNU-xJadaznxWvwmDk2-ARoR0DYYq_e7alyc8U$ > >>> and the proposal is in > >>> > https://urldefense.com/v3/__https://github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-20200918.md__;!!CQl3mcHX2A!Q0pEjWrLTcmcryUR2EMbSc6uWBNU-xJadaznxWvwmDk2-ARoR0DYYq_eNfKGqkE$ > >>> . You can also find the draft here > >>> > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01__;!!CQl3mcHX2A!Q0pEjWrLTcmcryUR2EMbSc6uWBNU-xJadaznxWvwmDk2-ARoR0DYYq_erhCF3-A$ > >>> . > >>> > >>> At this stage, we are looking for inputs for more use cases and > >>> interests of working together in this domain. Please post your > >>> comments in the mailing list. > >>> > >>> Thanks > >>> > >> > >> > >> -- Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT > >> consulting ) Sandelman Software Works Inc, Ottawa and Worldwide > >> > >> > >> _______________________________________________ homenet mailing > >> list homenet@ietf.org > >> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/homenet__;!!CQl3mcHX2A!Q0pEjWrLTcmcryUR2EMbSc6uWBNU-xJadaznxWvwmDk2-ARoR0DYYq_epVo5mQQ$ > > > >> > > > > > > _______________________________________________ homenet mailing > list > > homenet@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/homenet__;!!CQl3mcHX2A!QmyqyKwbOOxTGfm0x58b5xfYvrm-ivhzQUDCjlF7XvYCa411l20nyTY4Gc-Mvoc$ > > > > _______________________________________________ > Captive-portals mailing list > captive-port...@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals > _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
