Re: [homenet] [Int-area] [Captive-portals] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications

[Philip Homburg]

>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.

Observer may be the wrong term, the more standard term is attack scenario.

Some attacks are passively observing the network, but many attacks are
more complex than that. For example, an application may phone home, an
attacker may actively probe a network, an attacker may combine different
pieces of information.

___
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

[Rolf Winter]

Hi,

these pointers are very useful. Thanks. I would add one more:

https://tools.ietf.org/html/rfc8386

We know for a fact that there are protocols out there, even at the 
application layer, that would thwart efforts to randomize MAC addresses. 
Of course you'd have to be connected to the same L2 network, but the 
IETF meeting network, internet cafes, campus networks... it is not 
uncommon to be connected at L2 to devices that you probably do not 
trust, manage, know about.


I think a BoF about this general topic would be interesting, but I 
believe it should be scoped tightly, so the discussion can be focussed.


Best,

Rolf

Am 29.09.20 um 22:10 schrieb Juan Carlos Zuniga:
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


___
Int-area mailing list
int-a...@ietf.org
https://www.ietf.org/mailman/listinfo/int-area





smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Weil, Jason]

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] [Int-area] [Captive-portals] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications

[Juan Carlos Zuniga]

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] [Int-area] [Captive-portals] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications

[Brian Dickson]

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

[Michael Richardson]

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

[Christian Huitema]

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