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

Rolf Winter <rolf.winter@hs-augsburg.de> Wed, 30 September 2020 07:29 UTC

Return-Path: <rolf.winter@hs-augsburg.de>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968B13A129C; Wed, 30 Sep 2020 00:29:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.112
X-Spam-Level:
X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6v5cpWvtu6Iy; Wed, 30 Sep 2020 00:29:49 -0700 (PDT)
Received: from fly2.rz.hs-augsburg.de (fly2.RZ.HS-Augsburg.DE [141.82.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEE243A133A; Wed, 30 Sep 2020 00:29:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by fly2.rz.hs-augsburg.de (Postfix) with ESMTP id 305D81218DD; Wed, 30 Sep 2020 09:29:15 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at hs-augsburg.de
Received: from fly2.rz.hs-augsburg.de ([127.0.0.1]) by localhost (fly2.rz.hs-augsburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MqOD9RE1NONv; Wed, 30 Sep 2020 09:29:14 +0200 (CEST)
Received: from wat.fritz.box (ppp-93-104-37-92.dynamic.mnet-online.de [93.104.37.92]) by fly2.rz.hs-augsburg.de (Postfix) with ESMTPSA id 177D0121343; Wed, 30 Sep 2020 09:29:13 +0200 (CEST)
To: Juan Carlos Zuniga <j.c.zuniga@ieee.org>, Peter Yee <peter@akayla.com>
Cc: int-area@ietf.org, homenet@ietf.org, captive-portals@ietf.org, Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <20200922201317.097C3389D4@tuna.sandelman.ca> <15660.1600807202@localhost> <902400f2-9172-9581-25ab-59ad08e67bee@cs.tcd.ie> <D81695FF-973F-472D-BC0A-9B0F57278B21@comcast.com> <ca575a6b-987e-d998-2713-91e45190f5ea@cs.tcd.ie> <0A436777-D9CE-4A4C-BE45-C8C2CAB9FBF6@comcast.com> <29901277-6da1-46fc-b244-ca289005841d@www.fastmail.com> <af0451b1-8eae-4714-849f-d6e384dda075@huitema.net> <19117.1601400596@localhost> <CAH1iCip7UBe+FR-Cz+sP6SdS11NUQC9gV_s=99yO0tjcvCcX6A@mail.gmail.com> <4215.1601404884@localhost> <3a4b39c8-6b71-5d84-1422-3470c3b01591@cs.tcd.ie> <037001d69698$4b7a4cf0$e26ee6d0$@akayla.com> <CAHLBt83U67qntQN8gx5Kez8oLBBfZN281qBBTMTDae+E+gETfw@mail.gmail.com>
From: Rolf Winter <rolf.winter@hs-augsburg.de>
Message-ID: <657595a5-167f-5c85-354a-cefd5310c000@hs-augsburg.de>
Date: Wed, 30 Sep 2020 09:29:25 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <CAHLBt83U67qntQN8gx5Kez8oLBBfZN281qBBTMTDae+E+gETfw@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms030104000303000904010707"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/TNNxpYLspUjsQlYGkhM3RbjS5Lg>
Subject: Re: [Captive-portals] [Int-area] [homenet] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2020 07:29:52 -0000

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 <peter@akayla.com 
> <mailto:peter@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]
>     https://mentor.ieee.org/802.11/dcn/20/11-20-0995-10-0rcm-rcm-sg-agenda.pptx
> 
> 
> 
>     _______________________________________________
>     Int-area mailing list
>     Int-area@ietf.org <mailto:Int-area@ietf.org>
>     https://www.ietf.org/mailman/listinfo/int-area
> 
> 
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
>