Re: [93attendees] Network experiment during the meeting

Jared Mauch <jared@puck.Nether.net> Tue, 14 July 2015 14:34 UTC

Return-Path: <jared@puck.nether.net>
X-Original-To: 93attendees@ietfa.amsl.com
Delivered-To: 93attendees@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A214A1ACDFF for <93attendees@ietfa.amsl.com>; Tue, 14 Jul 2015 07:34:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.788
X-Spam-Level:
X-Spam-Status: No, score=0.788 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 Cx6H_vTI7Cl8 for <93attendees@ietfa.amsl.com>; Tue, 14 Jul 2015 07:34:34 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id CF7D11ACDEF for <93attendees@ietf.org>; Tue, 14 Jul 2015 07:34:34 -0700 (PDT)
Received: by puck.nether.net (Postfix, from userid 162) id 7B4D45408DE; Tue, 14 Jul 2015 10:34:34 -0400 (EDT)
Date: Tue, 14 Jul 2015 10:34:34 -0400
From: Jared Mauch <jared@puck.Nether.net>
To: Rolf Winter <rolf.winter@hs-augsburg.de>
Message-ID: <20150714143434.GA5386@puck.nether.net>
References: <55A41BEB.3090102@hs-augsburg.de> <55A41FD7.5030906@dcrocker.net> <55A4B86B.3000907@hs-augsburg.de> <55A513C9.4030601@dcrocker.net> <55A5182E.9000504@Opus1.COM> <55A51C67.3000008@hs-augsburg.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <55A51C67.3000008@hs-augsburg.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/93attendees/m-MzYdnjOH7qBZ9o2xG7U5GNQa0>
Cc: Joel M Snyder <Joel.Snyder@Opus1.COM>, dcrocker@bbiw.net, 93attendees@ietf.org
Subject: Re: [93attendees] Network experiment during the meeting
X-BeenThere: 93attendees@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Mailing list of IETF 93 attendees that have opted in on this list. " <93attendees.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/93attendees>, <mailto:93attendees-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/93attendees/>
List-Post: <mailto:93attendees@ietf.org>
List-Help: <mailto:93attendees-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/93attendees>, <mailto:93attendees-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jul 2015 14:34:37 -0000

On Tue, Jul 14, 2015 at 04:27:51PM +0200, Rolf Winter wrote:
> Hi,
> 
> I am not a lawyer so anything I say is solely based on common sense, which
> probably means that legally speaking I am wrong. Just for the folks that
> have not read the description of our experiment, we solely talk about
> broadcast data.
> 
> I have actually talked to our lawyer here, and her spontaneous suggestion
> was to ask whether one of the participants/sponsors from the Czech Republic
> could ask their lawyers/data protection officers if such an experiment would
> be OK under Czech Republic law? I found that a smashing idea. Anybody on
> this list who could help out?

	I find this study interesting because it's about data that people are
sharing by default settings of their software and acceptance of EULA.

	Attending a RIPE/NANOG/IETF meeting is interesting seeing all the
messages and disclosures from hosts that are broadcast.

	The same is true of CDP/LLDP and other protocols that operate
within this space.

	If you haven't looked at the data your laptop leaks from running iTunes,
mDNS/Bonjour, etc you may want to investigate it before joining an
untrusted network.

	The apple messages app and itunes share a lot of data, plus even
in just DHCP you see plenty of details.  Example from my home:

	  Client-Ethernet-Address c8:0a:a9:2d:c9:25
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Discover
	    MSZ Option 57, length 2: 576
	    Vendor-Class Option 60, length 21: "Broadcom:LB4M:1.1.0.8"


	  Client-Ethernet-Address 5c:f9:38:da:d8:79
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Request
	    Parameter-Request Option 55, length 6: 
	      Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
	      Option 119, Option 252
	    MSZ Option 57, length 2: 1500
	    Client-ID Option 61, length 7: ether 5c:f9:38:da:d8:79
	    Requested-IP Option 50, length 4: 10.0.0.182
	    Lease-Time Option 51, length 4: 7776000
	    Hostname Option 12, length 15: "FamilyRAppleTV2"

	Take a look if you haven't studied this traffic.  Keep in mind what
this may do to the basic-1mbs rates supported on 802.11 radios and
how a large broadcast domain with lots of fe80:: traffic for NDP
will cause RF congestion due to speed changes.

	- Jared

-- 
Jared Mauch  | pgp key available via finger from jared@puck.nether.net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.