Subject: Re: [Int-area] IP broadcast and multicast protocol considerations

From: Tim Chown <[email-masked]>
Date: Mon, 8 Feb 2016 13:06:05 +0000

Hi,

> On 26 Jan 2016, at 01:01, Christian Huitema <[email-masked]> wrote:
> 
> On Monday, January 25, 2016 4:37 PM, Rolf Winter wrote:
>> 
>> Am 1/26/16 um 1:10 AM schrieb Christian Huitema:
>> ...
>>> 
>>> Rolf, I appreciate that you are trying to improve network privacy, but I
>> wonder whether a generic abstract draft is the best way to achieve that, by
>> opposition to specific drafts covering specific broadcast protocols.
>>> 
>>> If I look at protocols covered by INT Area, there are 5 big targets: DHCP and
>> DHCPv6, ARP and IPv6 Neighbor Discovery, and MDNS. DHCP and DHCPv6
>> are arguably already covered by the privacy work in the DHCP working
>> group. Maybe we should start by an analysis of the other 3 protocols? Or do
>> you have other similar protocols in mind?
>>> 
>> 
>> DHCP is well covered, I agree. MDNS was one of the main "offenders" in our
>> experiments but that links strongly to your hostnames document. 
> 
> Actually, MDNS would probably benefit from an in depth analysis. There is one obvious issue, broadcasting host names, but there may be more. The MDNS design largely assumes UI interaction, in which the user sees what is out there and makes an explicit decision to connect to it or not. But there are usage patterns in which a software agent sends a request over the network and then "automatically connects" if it find something, and those patterns are an accidient waiting to happen.

In this light, contributions to and review of draft-otis-dnssd-scalable-dns-sd-threats-02 would be very welcome, which is about the dnssd work on scaling DNS based service discovery beyond a single link.  See RFC 7558 and the dnssd charter at https://datatracker.ietf.org/wg/dnssd/charter/.

Tim

>> The not
>> covered "offenders" are often not IETF-specified potocols. I give you one
>> example. The DropBox LanSync protocol used by the DropBox desktop
>> client. Messages contain an identifier that identifies the installation of the
>> application. It broadcasts very frequently. Now with all the pricacy work in
>> the IEEE and IETF and other places, here is a protocol that, with a relatively
>> high frequency, broadcasts a persistent stable identifier. When e.g. your
>> MAC address changes (for privacy reasons e.g.), the LanSync protocol allows
>> you to easily recognize that you just changed your MAC address and all that
>> trouble changing the MAC address was useless. 
> 
> Obviously, your draft is based on experience and measurements in your lab. But you only write up your conclusions. It would be very nice if you could describe what you observed. OK, you may not want to name and shame a particular company. Maybe you can just anonymize, e.g. mention "Company X" or "Game Y."
> 
> Did you interact with the developers of these products? Do you know what they were trying to achieve with their design? Ideally, we should be able to point them to a standard and safe alternative. Your draft could document for each example the problematic design, the privacy or security issues, and the recommended alternative. The IETF would be very much in its role when doing that.
> 
>> There is a lot of effort all
>> over the place (IETF and other SDOs) to make protocols better regarding the
>> protection of privacy but there are deployed protocols that make many of
>> these efforts useless if these practices prevail. There are other things we
>> have observed today which can reveal interesting things with a little more
>> effort. I think there is good (generic) advice the IETF can give to protocol
>> designers (in particular outside the IETF). 
> 
> Yes, but presenting it as "case studies" could be more convincing.
> 
>> We can have a look at ND and ARP
>> and what not, but the professional protocol engineers at the IETF are not the
>> main target for such a document. We already have
>> RFC6973 and RFC7258 that talk about privacy and I believe the IETF
>> community has already a good sense of privacy implications of protocol
>> choices, but the people outside the IETF building broadcast/multicast
>> protocols might not. It really means telling people what they break when the
>> do certain things.
> 
> No question there. But we also need to tell them how to achieve the result they want without breakage...
> 
> -- Christian Huitema
> 
> 
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area