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

From: Rolf Winter <[email-masked]>
Date: Mon, 18 Jan 2016 13:07:45 +0100

Hi,

we just posted a draft that discusses considerations for IP 
broadcast/multicast protocol designers:

https://tools.ietf.org/html/draft-winfaa-intarea-broadcast-consider-00

We presented this work briefly during the last meeting in Yokohama in a 
1 minute pitch during the chairs presentation. This also relates to the 
experiment that was done on the IETF network during the last meeting as 
well.

This work addresses privacy problems with current broadcast and 
multicast protocols (many of which are implemented by popular 
applications). In other words, this work addresses issues that can be 
frequently observed today.

Previous versions of the document can be found here:

https://tools.ietf.org/html/draft-winfaa-broadcast-consider

We are happy to receive feedback on the document and discuss its content.

Best,

Rolf

---

From: Joe Touch <[email-masked]>
Date: Mon, 25 Jan 2016 13:23:55 -0800

This doc *ignores* dominant uses of multicast and broadcast today (e.g.,
ARP, DAD, IPv6 autoconfiguration, DHCP, etc.).

You should also review "Advice for Internet Subnetwork Designers", RFC
3819, esp. sec 5 and 6.

Joe

On 1/18/2016 4:07 AM, Rolf Winter wrote:
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Rolf Winter <[email-masked]>
Date: Mon, 25 Jan 2016 22:47:05 +0100

Hi Joe,

The document focusses right now on observed behaviour of dominant 
protocols by a) volume/message frequency and b) content that gives away 
privacy relevant information. Some of these are (popular) apps, not IETF 
protocols, and we believe guidance to these protocol designers would be 
valuable. E.g. some of the protocols we see today would completely break 
the efforts on MAC address randomization.

You mentioned DHCP. There is 
https://tools.ietf.org/html/draft-ietf-dhc-dhcp-privacy-03 and 
https://tools.ietf.org/html/draft-ietf-dhc-anonymity-profile-03. ARP is 
not terribly interesting compared to the other things we have observed 
but we can include any of the protocols you suggest. In the next version 
of the document we will add a section of ongoing work such as MAC 
address randomization and the work on DHCP mentioned above but I would 
prefer not to duplicate that effort but rather reference it.

Best,

Rolf

---

From: Joe Touch <[email-masked]>
Date: Mon, 25 Jan 2016 13:54:46 -0800

> the efforts on MAC address randomization.

You're looking under the lamppost of privacy. You need to consider that
there are plenty of protocols for which your recommendations are both
incorrect and inappropriate.

> prefer not to duplicate that effort but rather reference it.

The entirety of your document needs to be limited to use cases where
privacy is both desired and appropriate - including the title. That
includes a survey of *widely deployed and critical* IETF protocols that
already rely on broadcast and multicast snooping for correct behavior.

Joe

---

From: Rolf Winter <[email-masked]>
Date: Mon, 25 Jan 2016 23:15:34 +0100

> incorrect and inappropriate.

Sure, that's why they are considerations. One should think about these 
things when designing a new protocol. If they do not apply, that is fine.

> privacy is both desired and appropriate - including the title.

I think I agree with you. The title probably needs adjustment to reflect 
that privacy is the focus of the document.

> That

OK.

Rolf

---

From: Christian Huitema <[email-masked]>
Date: Tue, 26 Jan 2016 00:10:57 +0000

On Monday, January 25, 2016 2:16 PM, Rolf Winter wrote: 
> >> protocols by a) volume/message frequency and b) content that gives
> >> away privacy relevant information. Some of these are (popular) apps,
> >> not IETF protocols, and we believe guidance to these protocol
> >> designers would be valuable. E.g. some of the protocols we see today
> >> would completely break the efforts on MAC address randomization.
> >
> > You're looking under the lamppost of privacy. You need to consider
> > that there are plenty of protocols for which your recommendations are
> > both incorrect and inappropriate.
> 

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?

-- Christian Huitema

---

From: Rolf Winter <[email-masked]>
Date: Tue, 26 Jan 2016 01:37:07 +0100

> 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…

DHCP is well covered, I agree. MDNS was one of the main "offenders" in 
our experiments but that links strongly to your hostnames document. 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. 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). 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.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 26 Jan 2016 01:01:07 +0000

On Monday, January 25, 2016 4:37 PM, Rolf Winter wrote:
> ...
> > 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.

> 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
> 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

---

From: Rolf Winter <[email-masked]>
Date: Tue, 26 Jan 2016 10:33:10 +0100

> 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…

I would agree.

> 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 wan…

That makes sense. It is not really shaming because often in isolation, 
these protocols are "harmless". Only when you start correlating the 
information from a number of protocols, these things leak a lot of 
information. In experiments with students that gave us their consent to 
look at the broadcast/multicast data in the clear (and only that data), 
we could easily find out names of people in the room, if they share data 
and with whom (often also identified by name) and a bunch of other 
intereting things about individuals on the network (things like 
nicknames). Just from looking at broadcast/multicast data.

> 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.…

Not yet, no. We know what they are trying to achieve and it is generally 
things that make a lot of sense. But users are generally not aware of 
the things these protocols do and how often and where they do it.

> Yes, but presenting it as "case studies" could be more convincing.

I guess you are right. From the discussion so far it seems we didn't get 
our point across very well.

> No question there. But we also need to tell them how to achieve the result they want without breakage...

Right. Some of that is (probably hidden) in the text such as declaring a 
"safe" environment (something that is somewhat built into Windows 
devices when you connect to networks but often lacking in applications). 
But it's really an early document and there is much left to do.