Re: [93attendees] Network experiment during the meeting

Rolf Winter <> Wed, 15 July 2015 08:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D9EA11A8930 for <>; Wed, 15 Jul 2015 01:52:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.489
X-Spam-Status: No, score=0.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xcrTnstoLcXs for <>; Wed, 15 Jul 2015 01:52:24 -0700 (PDT)
Received: from (fly.RZ.HS-Augsburg.DE [IPv6:2001:638:102:2::217:48]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 162941A892B for <>; Wed, 15 Jul 2015 01:52:24 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B7681D6024; Wed, 15 Jul 2015 10:52:10 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id GM3eT5J0K_47; Wed, 15 Jul 2015 10:52:08 +0200 (CEST)
Received: from [] ( []) by (Postfix) with ESMTPSA id A8F6C1D6028; Wed, 15 Jul 2015 10:52:07 +0200 (CEST)
To: Toerless Eckert <>, Jari Arkko <>
References: <> <> <> <> <>
From: Rolf Winter <>
Message-ID: <>
Date: Wed, 15 Jul 2015 10:52:18 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------080003060209060404020607"
Archived-At: <>
Cc: joel jaeggli <>,,
Subject: Re: [93attendees] Network experiment during the meeting
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Mailing list of IETF 93 attendees that have opted in on this list. " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Jul 2015 08:52:27 -0000


we were sloppy in our description, apologies. Multicast _is_ being 
collected. Basically everything the NIC receives which is not unicast. 
But ARP is actually not all that interesting. Most interesting are 
actually applications using broadcast/multicast messages. Here is a 
protocol distribution of a previous experiment omitting everything below 
7% of the overall broadcast/multicast traffic volume.

mDNS (16%), SSDP (15%), LLMNR (13%), NetBIOS (7%) and Dropbox LAN-sync (7%).

This clearly depends on the population of your LAN (mostly depending on 
OS distribution and installed apps). In this particular case, 
broadcast/multicast traffic peaked at around 1 GB a day, averaging at 
about 200 MB a day.

I hope this answers some of your no-legal questions.



Am 7/15/15 um 6:07 AM schrieb Toerless Eckert:
> Rolfs web page explain almost nothing more than his email. I wouldn't
> know any actual broacast packet of interest except for ARP. I am
> pretty sure he means L2/L3 multicast. Having him say just "rfc919 / broadcast"
> makes me a bit nervuous about how well the other bits are thought out.
> As soon as IETF gives access for Rolf to any reasonable protected packets,
> i would assume IETF is at least partially indemnifying Rolfs org from
> legal responsibilities and takes on legal responsibilities itself.
> It would be good to understand what the IETF is really responsible for.
> I would fear that to be on the safe side, IETF should indemnify itself
> against the attendees by having them sign "something". I am sure
> that "something" needs to be better than "rfc919 / broadcast" unless he
> really only wants to analyze ARP patterns.
> Didn't IETF have security folks running around for decades telling us
> to not be insecure because they will be tap'ing our unprotected WiFi
> traffic and post our passwords ? Whatever happened of those experiments
> (sorry, can't remember) ?
> Logically its hilarious discussing legalese when Rolf would only tap
> what amounts to publically accessible packets, eg: on no- or obvious-password
> encrypted WiFI accessible in public areas like Hotel lobbies. Of course i
> am sure with digital laws being what they are, there is going to be difference
> in him publishing a paper about those packets vs. posting a paper
> about him observing/counting IETF participants in the public hotel
> lobby and oh, their observable legal drug consumption patterns.
> I am actually interested in what the heck the technical details are.
> Depending on what protocols are of interest, the different ways of how
> multicast traffic is constrained (IGMP snooping) or L2 unicast converted
> (vendor specific) makes a lot of difference to what can be observed where.
> If he can show some really useful stats he would create, i am all for giving
> him all the access needed as long as we can make sure the IETF indemnifies
> itself well enough so that it does not have to spend money later on some stupid
> lawsuit with some disgruntled ITEF participant. But then again, i am using
> a VPN tunnel for all my traffic anyhow.
> Cheers
>      Toerless
> On Tue, Jul 14, 2015 at 07:29:28PM +0300, Jari Arkko wrote:
>>> Rolf contacted me a while ago and I had him contact Jari for approval of
>>> this "experiment". Jari has approved it.
>> Right. I think it is a useful experiment and I find the privacy safeguards adequate.
>> And indeed, the main purpose of passing this kind of experiments via the
>> IETF chair is that I try to catch issues; in this case I reviewed the suggested
>> safeguards and suggested some changes, and felt that the result was adequate.
>> It is possible that there are legal or other standards that would specify in
>> detail what we can and can not do. I am obviously not a lawyer either.
>> I don?t mind passing this to someone who understands laws about
>> human subject research or privacy, of course.
>> Jari
>> _______________________________________________
>> 93attendees mailing list