Re: [homenet] [Int-area] [Captive-portals] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications
Thank you Juan and Peter for the links to the prior work in the IEEE on this topic. I have been following RCM and was actually just reading one of the publicly available draft versions of the 802E Privacy Recommendations. This work will be very useful for reference once it is published. My interest in considering this work within the IETF goes directly to the point stated here and in the IEEE draft work that privacy doesn’t exist at one layer of then network and in fact covers all of them. The IEEE is making good progress on changes to 802 that improve the operation of the network at the data link layer. I see the WiFi Alliance is also looking at options for in its various specifications and which use cases those specs can be applied to in the realm of MAC randomization impacts. The goal of this BoF from my viewpoint is to gauge IETF community interest on identifying and working on updates, new work or BCP/s that would capture the privacy concerns and needs of end users as well as the impact to network operators and local network administrators (campus networks, home networks, public WiFis nets, etc). A number of areas/WG work have already been brought up in the discussion on this list. I think some of points that came up in the IEEE and WiFi discussions are equally worth discussing in this org including the periodicity of endpoint address (or other ‘thing’ that represents a device) change. The impact on varying trust models that would allow an end user to choose between various levels of trust and the impact on how much the network is able to remember them is also an interesting discussion topic. Jason Weil From: Int-area on behalf of Juan Carlos Zuniga Date: Tuesday, September 29, 2020 at 4:11 PM To: Peter Yee Cc: "int-a...@ietf.org" , "homenet@ietf.org" , "captive-port...@ietf.org" , Stephen Farrell Subject: Re: [Int-area] [Captive-portals] [homenet] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance. Indeed, this is a continuation of the work started at IEEE 802 back in 2014 after the STRINT Workshop pre-IETF 89 [1] [2]. So far IEEE 802 has developed the (soon to be published) 802E Privacy Recommendations [3], the recommended use of MAC address randomization in 802c [4], and now the work in 802.11 that Peter points out. We carried out the experiment on the IETF (x2) and IEEE 802 Wi-Fi meeting networks and we published some results at the time [5]. Even though we found some very minor impact on DHCP, the experiment showed that MAC address randomization worked fine. However, as we pointed out the Privacy issues should not stop at L3. If there is a good take away from that work, it is that Privacy cannot be solved at a single layer, and effective solutions should be system-wide. Juan Carlos [1] https://mentor.ieee.org/802-ec/dcn/14/ec-14-0043-01-00EC-internet-privacy-tutorial.pdf [2] http://www.ieee802.org/PrivRecsg/ [3] https://1.ieee802.org/security/802e/ [4] https://ieeexplore.ieee.org/document/8016709 [5] https://ieeexplore.ieee.org/abstract/document/7390443/ pre-print: https://www.it.uc3m.es/cjbc/papers/pdf/2015_bernardos_cscn_privacy.pdf On Tue, Sep 29, 2020 at 3:40 PM Peter Yee mailto:pe...@akayla.com>> wrote: On 29/09/2020 12:03, Stephen Farrell wrote: > More on-topic, I do think MAC address randomisation has a role to play for > WiFi as it does for BLE, but yes there is a lack of guidance as to how to > implement and deploy such techniques well. It's a bit tricky though as it's > fairly OS dependent so maybe not really in scope for the IETF? > (For the last 3 years I've set a possible student project in this space, but > each time a student has considered it, it turned out "too hard";-) As I mentioned previously, IEEE 802.11 is looking into this area, both from an operational perspective and from a privacy perspective. New IEEE 802.11 amendments (IEEE 802.11bh and IEEE 802.11bi, if approved) are being discussed. The (very) high-level documents describing each can be found at [1] and [2]. I would be happy to convey input to IEEE 802.11 regarding either document, particularly in regards to layers 3 and above. Without wishing to open up a can of worms about meeting fees, I will note that IEEE 802.11 is currently not charging for its online meetings, so if anyone wishes to take part in the random MAC address discussions directly, the next meeting will be held in early November. The RCM Study Group met yesterday morning (Americas) and will meet again in two weeks. See [3]. -Peter [1] https://mentor.ieee.org/802.11/dcn/20/11-20-0742-04-0rcm-proposed-par-draft.docx [2] https://mentor.ieee.org/802.11/dcn/20/11-20-0854-06-0rcm-par-proposal-for-privacy.pdf [3]
Re: [homenet] [Captive-portals] [Int-area] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications
Hiya, On 29/09/2020 20:56, Michael Richardson wrote: > > Stephen Farrell wrote: > > > On 29/09/2020 19:41, Michael Richardson wrote: > >> It will be good if we can get a document from the MAC randomization > >> proponents (if there is such a group), to explain the thread profile. > >> I don't think it includes active compromised hosts. > > > That is a problem yes. I no longer think "compromised host" is the > > correct term there though. In the case of android, we found google play > > services regularly calls home linking all these identifiers and more > > (phone#, sim serial, imei...) [1] for Google's own uses. I'd be very > > I feel that you have confounded two things, and I don't think it's helpful. > I won't dispute your observatrions about surveillance capitalism, but I feel > that you've sensationalized what I thought was a pretty specific technical > point. Namely: > You can't see into the L3 layer of WIFI, even when there are > ARP broadcasts, unless your are also part of that L2 network. I disagree about sensationalising, obviously;-) The point is that we tended to think of a compromised host as one that had been subject to a successful attack often run by an unknown party. For mobile phones, the privacy adversary seems more often to be an entity that the phone user has accepted one way or another, whether that be the OS or handset vendor or whoever wrote that cute spirit- level app. > > I'm sure that Google Play calls home and tells Google all the your > L2/L3/IMEI/etc. I don't doubt it. > > I don't see how this relates to a local passive eavesdropping observing the > L2 frames with the encrypted L3. One not involved with the operation > of the wifi, nor connected to that link. The MAC address and other identifiers are payload with the source IP address and thus correlated at the destination without having to locally eavesdrop. But they can be used to later correlate with the local eavesdropper's data, probably after that's also been centralised (perhaps via another app using the same SDK). > > Unless you are saying that Google Play operates as active eavesdropper on all > the networks on which it is connected? I.e. it sends the L2/L3 mappings for > all devices on that network? I don't believe google do that for that attack, but they can correlate the MAC and IP addresses, yes, for all the devices on a n/w running their OS. > > > More on-topic, But yeah the above is a bit off-topic, except that it shows there's a *lot* more to do in the mobile context to get benefit from address randomisation. S. PS: to be clear - the above's not really anti-google - we've seen similar looking traffic from handset vendors' pre-installed s/w too. > I do think MAC address randomisation has a role to play > > for WiFi as it does for BLE, but yes there is a lack of guidance as to > > how to implement and deploy such techniques well. It's a bit tricky > > though as it's fairly OS dependent so maybe not really in scope for the > > IETF? > > The IEEE has a spec on how to do MAC address ramdomization. > It says nothing about how to automatically update the accept-list rules > created by RFC8520, or RFC8908/RFC8910 (CAPPORT). Or EAP-FOO. > > > (For the last 3 years I've set a possible student project in > > this space, but each time a student has considered it, it turned out > > "too hard";-) > > :-( > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works|IoT architect [ > ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails > [ > > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Int-area] [Captive-portals] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications
Indeed, this is a continuation of the work started at IEEE 802 back in 2014 after the STRINT Workshop pre-IETF 89 [1] [2]. So far IEEE 802 has developed the (soon to be published) 802E Privacy Recommendations [3], the recommended use of MAC address randomization in 802c [4], and now the work in 802.11 that Peter points out. We carried out the experiment on the IETF (x2) and IEEE 802 Wi-Fi meeting networks and we published some results at the time [5]. Even though we found some very minor impact on DHCP, the experiment showed that MAC address randomization worked fine. However, as we pointed out the Privacy issues should not stop at L3. If there is a good take away from that work, it is that Privacy cannot be solved at a single layer, and effective solutions should be system-wide. Juan Carlos [1] https://mentor.ieee.org/802-ec/dcn/14/ec-14-0043-01-00EC-internet-privacy-tutorial.pdf [2] http://www.ieee802.org/PrivRecsg/ [3] https://1.ieee802.org/security/802e/ [4] https://ieeexplore.ieee.org/document/8016709 [5] https://ieeexplore.ieee.org/abstract/document/7390443/ pre-print: https://www.it.uc3m.es/cjbc/papers/pdf/2015_bernardos_cscn_privacy.pdf On Tue, Sep 29, 2020 at 3:40 PM Peter Yee wrote: > On 29/09/2020 12:03, Stephen Farrell wrote: > > > More on-topic, I do think MAC address randomisation has a role to play > for WiFi as it does for BLE, but yes there is a lack of guidance as to how > to implement and deploy such techniques well. It's a bit tricky though as > it's fairly OS dependent so maybe not really in scope for the IETF? > > (For the last 3 years I've set a possible student project in this space, > but each time a student has considered it, it turned out "too hard";-) > > As I mentioned previously, IEEE 802.11 is looking into this area, both > from an operational perspective and from a privacy perspective. New IEEE > 802.11 amendments (IEEE 802.11bh and IEEE 802.11bi, if approved) are being > discussed. The (very) high-level documents describing each can be found at > [1] and [2]. I would be happy to convey input to IEEE 802.11 regarding > either document, particularly in regards to layers 3 and above. Without > wishing to open up a can of worms about meeting fees, I will note that IEEE > 802.11 is currently not charging for its online meetings, so if anyone > wishes to take part in the random MAC address discussions directly, the > next meeting will be held in early November. The RCM Study Group met > yesterday morning (Americas) and will meet again in two weeks. See [3]. > > -Peter > > [1] > https://mentor.ieee.org/802.11/dcn/20/11-20-0742-04-0rcm-proposed-par-draft.docx > [2] > https://mentor.ieee.org/802.11/dcn/20/11-20-0854-06-0rcm-par-proposal-for-privacy.pdf > [3] > https://mentor.ieee.org/802.11/dcn/20/11-20-0995-10-0rcm-rcm-sg-agenda.pptx > > > > ___ > Int-area mailing list > int-a...@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Captive-portals] [Int-area] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications
Stephen Farrell wrote: > On 29/09/2020 19:41, Michael Richardson wrote: >> It will be good if we can get a document from the MAC randomization >> proponents (if there is such a group), to explain the thread profile. >> I don't think it includes active compromised hosts. > That is a problem yes. I no longer think "compromised host" is the > correct term there though. In the case of android, we found google play > services regularly calls home linking all these identifiers and more > (phone#, sim serial, imei...) [1] for Google's own uses. I'd be very I feel that you have confounded two things, and I don't think it's helpful. I won't dispute your observatrions about surveillance capitalism, but I feel that you've sensationalized what I thought was a pretty specific technical point. Namely: You can't see into the L3 layer of WIFI, even when there are ARP broadcasts, unless your are also part of that L2 network. I'm sure that Google Play calls home and tells Google all the your L2/L3/IMEI/etc. I don't doubt it. I don't see how this relates to a local passive eavesdropping observing the L2 frames with the encrypted L3. One not involved with the operation of the wifi, nor connected to that link. Unless you are saying that Google Play operates as active eavesdropper on all the networks on which it is connected? I.e. it sends the L2/L3 mappings for all devices on that network? > More on-topic, I do think MAC address randomisation has a role to play > for WiFi as it does for BLE, but yes there is a lack of guidance as to > how to implement and deploy such techniques well. It's a bit tricky > though as it's fairly OS dependent so maybe not really in scope for the > IETF? The IEEE has a spec on how to do MAC address ramdomization. It says nothing about how to automatically update the accept-list rules created by RFC8520, or RFC8908/RFC8910 (CAPPORT). Or EAP-FOO. > (For the last 3 years I've set a possible student project in > this space, but each time a student has considered it, it turned out > "too hard";-) :-( -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Captive-portals] [Int-area] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications
On 29/09/2020 12:03, Stephen Farrell wrote: > More on-topic, I do think MAC address randomisation has a role to play for > WiFi as it does for BLE, but yes there is a lack of guidance as to how to > implement and deploy such techniques well. It's a bit tricky though as it's > fairly OS dependent so maybe not really in scope for the IETF? > (For the last 3 years I've set a possible student project in this space, but > each time a student has considered it, it turned out "too hard";-) As I mentioned previously, IEEE 802.11 is looking into this area, both from an operational perspective and from a privacy perspective. New IEEE 802.11 amendments (IEEE 802.11bh and IEEE 802.11bi, if approved) are being discussed. The (very) high-level documents describing each can be found at [1] and [2]. I would be happy to convey input to IEEE 802.11 regarding either document, particularly in regards to layers 3 and above. Without wishing to open up a can of worms about meeting fees, I will note that IEEE 802.11 is currently not charging for its online meetings, so if anyone wishes to take part in the random MAC address discussions directly, the next meeting will be held in early November. The RCM Study Group met yesterday morning (Americas) and will meet again in two weeks. See [3]. -Peter [1] https://mentor.ieee.org/802.11/dcn/20/11-20-0742-04-0rcm-proposed-par-draft.docx [2] https://mentor.ieee.org/802.11/dcn/20/11-20-0854-06-0rcm-par-proposal-for-privacy.pdf [3] https://mentor.ieee.org/802.11/dcn/20/11-20-0995-10-0rcm-rcm-sg-agenda.pptx ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] homenet - Not having a session at IETF 109
Barbara Stark, a chair of the homenet working group, indicated that the homenet working group does not plan to hold a session at IETF 109. This message was generated and sent by the IETF Meeting Session Request Tool. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Captive-portals] [Int-area] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications
Hiya, On 29/09/2020 19:41, Michael Richardson wrote: > It will be good if we can get a document from the MAC randomization > proponents (if there is such a group), to explain the thread profile. > I don't think it includes active compromised hosts. That is a problem yes. I no longer think "compromised host" is the correct term there though. In the case of android, we found google play services regularly calls home linking all these identifiers and more (phone#, sim serial, imei...) [1] for Google's own uses. I'd be very surprised if other entities (e.g. other OS and handset makers) weren't doing the same kind of thing (in fact I've seen some of that but we've not yet written it up). And supposedly innocuous "apps" can and do embed SDKs that also do that kind of thing. [2] I don't think "compromised" is an apt term for such a host. Perhaps it is apt for almost the entire mobile ecosystem? More on-topic, I do think MAC address randomisation has a role to play for WiFi as it does for BLE, but yes there is a lack of guidance as to how to implement and deploy such techniques well. It's a bit tricky though as it's fairly OS dependent so maybe not really in scope for the IETF? (For the last 3 years I've set a possible student project in this space, but each time a student has considered it, it turned out "too hard";-) Cheers, S. [1] https://www.scss.tcd.ie/Doug.Leith/pubs/contact_tracing_app_traffic.pdf [2] https://arxiv.org/abs/2009.06077 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Captive-portals] [Int-area] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications
<#secure method=pgpmime mode=sign>
Brian Dickson wrote:
> Any host/interface that uses ARP (not sure whether any flavor of WiFi
> does, or if so which flavors), exposes the L3/L2 mapping.
Yes, WIFI does use ARP. On all flavours.
Encrypted WIFI, which is mostly the default now, encrypts everything above
the L2, so the L3 part of the mapping is not seen by passive EM observers.
ARP broadcasts as you mention, so other stations on the network could see the
mapping, and the AP by default helpfully re-encrypts broadcasts to every
station. But, that's not a passive observer: the observer is on the network.
Many APs filter ARP broadcasts as being useless chatter.
> So, wired
> IPv4 for certain (except in very locked-down enterprise settings with
> static MAC addresses, perhaps) leaks this information to every host on
> the same broadcast domain (same subnet and possibly additional subnets
> on the same LAN/VLAN).
Yes, but that's not wifi. Phones do not have wired connections.
> ARP L2 broadcasts solicit information about IP addresses, and at a
> minimum each such query exposes its own MAC and IP address. Responses
> may be unicast or broadcast, not sure which. An active compromised
> host can easily solicit that information by iterating over all the IP
> addresses on the subnet and performing an ARP for each one.
It will be good if we can get a document from the MAC randomization
proponents (if there is such a group), to explain the thread profile.
I don't think it includes active compromised hosts.
Such hosts can also ARP/ND spoof, and can even do that for the router (".1"),
capturing all the traffic on the network.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Int-area] [Captive-portals] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications
On Tue, Sep 29, 2020 at 10:30 AM Michael Richardson wrote: > Christian Huitema wrote: > > Martin is making an important point here. There are a number of > privacy > > enhancing technologies deployed at different layers: MAC address > > randomization at L2, Privacy addresses at L3, various forms of > > encryption and compartments at L4 and above. Each of these > technologies > > is useful by itself, but they can easily be defeated by deployment > > mistakes. For example: > > You are spot on. > But, even your four points muddle things. > > We need some diagrams that we can all agree upon, and we need to name the > different observers. > > Each thing defends against different kinds of observers, and not all > observers can see all things. > Some observers may collaborate (I invoke, the WWII French resistance > emotion > for this term...) > Some observers may have strong reasons not to. > > > 1) Using the same IP address with different MAC addresses negates a > lot > > of the benefits of randomized MAC addresses, > > This assumes that a single observer can observe both at the same time. > WEP++ leaves MAC addresses visible, but encrypts the rest of L3 content. > Any host/interface that uses ARP (not sure whether any flavor of WiFi does, or if so which flavors), exposes the L3/L2 mapping. So, wired IPv4 for certain (except in very locked-down enterprise settings with static MAC addresses, perhaps) leaks this information to every host on the same broadcast domain (same subnet and possibly additional subnets on the same LAN/VLAN). ARP L2 broadcasts solicit information about IP addresses, and at a minimum each such query exposes its own MAC and IP address. Responses may be unicast or broadcast, not sure which. An active compromised host can easily solicit that information by iterating over all the IP addresses on the subnet and performing an ARP for each one. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Int-area] [Captive-portals] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications
Christian Huitema wrote: > Martin is making an important point here. There are a number of privacy > enhancing technologies deployed at different layers: MAC address > randomization at L2, Privacy addresses at L3, various forms of > encryption and compartments at L4 and above. Each of these technologies > is useful by itself, but they can easily be defeated by deployment > mistakes. For example: You are spot on. But, even your four points muddle things. We need some diagrams that we can all agree upon, and we need to name the different observers. Each thing defends against different kinds of observers, and not all observers can see all things. Some observers may collaborate (I invoke, the WWII French resistance emotion for this term...) Some observers may have strong reasons not to. > 1) Using the same IP address with different MAC addresses negates a lot > of the benefits of randomized MAC addresses, This assumes that a single observer can observe both at the same time. WEP++ leaves MAC addresses visible, but encrypts the rest of L3 content. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Int-area] [Captive-portals] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications
On 9/22/2020 5:52 PM, Martin Thomson wrote: > 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?) Martin is making an important point here. There are a number of privacy enhancing technologies deployed at different layers: MAC address randomization at L2, Privacy addresses at L3, various forms of encryption and compartments at L4 and above. Each of these technologies is useful by itself, but they can easily be defeated by deployment mistakes. For example: 1) Using the same IP address with different MAC addresses negates a lot of the benefits of randomized MAC addresses, 2) Using a private IP address provides some privacy to client connections. However, if the same address is also used for a publicly accessible server, a lot of the privacy benefits disappear. 3) Using a private IP address without also using a randomized MAC address is not going to provide privacy against local observers. 4) Web cookies and other forms of web tracking are widely used to enable surveillance. Randomizing the MAC address and the IP address without also doing something about web tracking is not going to provide much gains. Defining that "something about web tracking" is challenging, given requirements for users to identify themselves to social media sites and other services. My personal choice would be some form of compartments, each with their own IP address and MAC address, but opinions will probably vary. That would be a great topic for a BOF. -- Christian Huitema ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
