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

"Weil, Jason" <Jason.Weil@charter.com> Tue, 29 September 2020 21:04 UTC

Return-Path: <Jason.Weil@charter.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF823A1198; Tue, 29 Sep 2020 14:04:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 nN9CrhsuQ44G; Tue, 29 Sep 2020 14:04:44 -0700 (PDT)
Received: from nce.mail.chartercom.com (nce.mail.chartercom.com [142.136.234.134]) (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 E6CFF3A11A0; Tue, 29 Sep 2020 14:04:43 -0700 (PDT)
IronPort-SDR: o+mBDJ/azSW5TZCLLLK15yWVijNkCn1FKl+zeFJ8kwcAeDO/tuTHOko+cZjS4nJDbGaeBOg+rD URncr3Cnugng==
X-IronPort-AV: E=Sophos;i="5.77,319,1596517200"; d="scan'208,217";a="119500812"
Received: from unknown (HELO NCEMEXGP002.CORP.CHARTERCOM.com) ([142.136.234.7]) by nce.mail.chartercom.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 29 Sep 2020 16:04:40 -0500
Received: from NCEMEXGP003.CORP.CHARTERCOM.COM (2002:8e88:ea08::8e88:ea08) by NCEMEXGP002.CORP.CHARTERCOM.com (2002:8e88:ea07::8e88:ea07) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 29 Sep 2020 16:04:40 -0500
Received: from NCEMEXGP003.CORP.CHARTERCOM.COM ([fe80::8c4b:a9c4:de9c:e113]) by NCEMEXGP003.CORP.CHARTERCOM.com ([fe80::8c4b:a9c4:de9c:e113%20]) with mapi id 15.00.1473.003; Tue, 29 Sep 2020 16:04:40 -0500
From: "Weil, Jason" <Jason.Weil@charter.com>
To: Juan Carlos Zuniga <j.c.zuniga@ieee.org>, Peter Yee <peter@akayla.com>
CC: "int-area@ietf.org" <int-area@ietf.org>, "homenet@ietf.org" <homenet@ietf.org>, "captive-portals@ietf.org" <captive-portals@ietf.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Thread-Topic: [Int-area] [Captive-portals] [homenet] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications
Thread-Index: AQHWlphXK8/hPZVeSUqopGW6nlwH/KmAX8cA///MFYA=
Date: Tue, 29 Sep 2020 21:04:39 +0000
Message-ID: <D3230F2E-E017-40B3-B386-6593973E803F@charter.com>
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>
In-Reply-To: <CAHLBt83U67qntQN8gx5Kez8oLBBfZN281qBBTMTDae+E+gETfw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.19.200810
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [142.136.235.123]
Content-Type: multipart/alternative; boundary="_000_D3230F2EE01740B3B3866593973E803Fchartercom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/KtG3hC7Y4GxvQRfTnHzbqPGz28s>
Subject: Re: [Int-area] [Captive-portals] [homenet] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2020 21:04:47 -0000

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 <int-area-bounces@ietf.org> on behalf of Juan Carlos Zuniga <j.c.zuniga@ieee.org>
Date: Tuesday, September 29, 2020 at 4:11 PM
To: Peter Yee <peter@akayla.com>
Cc: "int-area@ietf.org" <int-area@ietf.org>, "homenet@ietf.org" <homenet@ietf.org>, "captive-portals@ietf.org" <captive-portals@ietf.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
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 <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
E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.