Subject: Rtgdir telechat review of draft-ietf-intarea-broadcast-consider-05

From: Carlos Pignataro <[email-masked]>
Date: Sat, 13 Jan 2018 20:20:49 -0800

Reviewer: Carlos Pignataro
Review result: Not Ready

 Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Summary:

This document has a set of minor issues, detailed below.

Comments:

1. Target

The document's title targets "IP broadcast and multicast protocol designers",
the Abstract and document throughout about "Therefore, broadcast/multicast
protocol designers". However, upon reading, it becomes clear that the target
audience of this document is not multicast/broadcast protocol designers, but
rather designers (?) of higher-level protocols that use broadcast or multicast.
The Abstract does say "A number of application-layer protocols make use of IP
broadcasts or". This causes major confusion on the first few reads of the doc.

In addition to the target layer, the role is unclear. The document says "Also
application developers use broadcast/multicast messages to implement" in at
least one more instance. Do these considerations target designers, developers,
both? Of multicast protocols? Of application protocols?

2. Threat model

The document talks about "a passive observer in the same broadcast/multicast
domain". It does not seem to cover, however, how exactly is bcast/mcast
different from unicast, when the passive observer has an interface is
promiscuous mode or has a packet capture library.

The doc then says "can trivially record these messages and analyze their
content". But how trivial or not it is to analyze the message contents seems to
be independent of the means in which they are sent. After captured, how is a
unicast different than a bcast/mcast? The content can have cryptographic
protection, which might make it not trivial to analyze.

3. References:

The document says:

"  Most of these items
   are based on protocol behavior observed as part of experiments on
   operational networks [TRAC2016]."

Based on this citation, should [TRAC2016] be Normative? And is it readily
available?

4. Qualification of examples used to derive conclusions.

"of a popular application", "A popular operating system". Which ones?

Further, the document includes the following text:

"  This is
   clearly true for any protocol, but broadcast/multicast is special in
   at least two respects:

   (a)  The aforementioned large receiver group, consisting of receivers
        unknown to the sender.  This makes eavesdropping without special
        privileges or a special location in the network trivial for
        anybody in the broadcast/multicast domain.

   (b)  Encryption is more difficult when broadcast/multicast messages,
        leaving content of these messages in the clear and making it
        easier to spoof and replay them.

   Given the above, privacy protection for protocols based on broadcast
   or multicast communication is significantly more difficult compared
   to unicast communication and at the same time invading the privacy is
   much easier.
"

But I do not directly follow how a large (including unknown) set of receivers
makes eavesdropping "trivial" (and not on unicast). Or how more difficult
encryption is in mcast/bcast to result in only replaying messages.

Or how the privacy protection for protocols leveraging mcast/bcast is
"significantly more difficult". That would be the case if privacy would depend
only on location preference for eavesdropping and encryption. However, there
are other methods to protect privacy. It seems "trivial" and "significantly"
overexagerate for effect, without granular qualification.

5. I do not understand this sentence:

   In particular, carelessly designed
   broadcast/multicast protocols can break privacy efforts at different
   layers of the protocol stack such as MAC address or IP address
   randomization [RFC4941].

Or at least I do not follow the "how".

6. Applicability.

The great majority of the content in the Section titled "Message frequency"
seems applicable to unicast as well.

That said, the assumption that when a protocol sends packets a user is playing
seems quite weak. In protocol design, there is a tradeoff.

7. More applicability.

Section 2.2 starts with:

"   A few broadcast/multicast protocols observed in the wild make use of
   persistent identifiers.  This includes the use of host names or more
   abstract persistent identifiers such as a universally unique
   identifiers (UUID) or similar.  These IDs, which e.g. identify the
   installation of a certain application might not change across updates
   of the software and are therefore extremely long lived. "

However, it is not clear to me what these application level identifier design
choices have to do with the IP layer or link-layer multi/uni-cast choice.

How does it follow that these considerations are for "bcast/mcast" (other than
the fact that were seen in an application that is not mentioned)?

8. Operational suggestions.

I really appreciate a document including operational considerations. The value
of Section 3 is not clear to me. This section now targets "network
administrators/operators" as opposed to designers or developers and how to
design and develop (at the same time) operational and privacy-aware application
protocols.

The advice of "filtering mcast/bcast in access points" is a bit puzzling. The
double negative ("not uncommonly") seems unhelpful. What is the value of config
advice for an access point, in a (ideally) broadly scoped guidance for protocol
designers and developers? Do developers control all operational deployments?

9. Summary

There is a change of tone in Section 4, from "protocols SHOULD" to "you
SHOULD". It is potentially difficult to evaluate the applicability of some of
these statements:

"   o  If you really must use a broadcast/multicast protocol and cannot
      use an IETF-specified protocol, then:"

Or, what does this mean?

"      *  You SHOULD let the user configure safe environments if possible
         (e.g. based on the SSID)"

Thanks,

Carlos.

---

From: Rolf Winter <[email-masked]>
Date: Mon, 15 Jan 2018 20:53:01 +0100

Carlos,

thanks for the review. Comments below:

> both? Of multicast protocols? Of application protocols?

Point well taken. As the previous reviewer suggested something similar, 
we changed the title from:

"Privacy considerations for IP broadcast and multicast protocol designers"

to

  "Privacy considerations for protocols relying on IP broadcast and 
multicast""

And made textual changes throughout the document to rephrase 
"broadcast/multicast protocol" to something along the lines of "protocol 
making use of broadcast/multicast messages"

We published a new version reflecting that already.

> promiscuous mode or has a packet capture library.

But there is a whole section on what boradcast/multicast is being used 
for and how it differs from unicast. It also details which multicast 
addresses are most relevant for this work. The key is that the receiver 
group is much larger and protecting the traffic, with e.g. encryption is 
much harder.

> protection, which might make it not trivial to analyze.

That is the whole point and the document I thought is clear about it. In 
order to being able to even capture a unicast packet, you'd have to be 
at a special location inside the network such as a router. Bcast you 
just have to be connected to the network and then listen. Also, crypto 
is so much harder. With TLS two parties agree on keys etc. but in 
multicast it is not necessarily that trivial as more parties are 
involved. There is a reference regarding this also in the security 
considerations section.

> Based on this citation, should [TRAC2016] be Normative? And is it readily

I would think one understands the document without having read the 
paper, so I would assume informative would be ok?

> "of a popular application", "A popular operating system". Which ones?

We discussed it a bit in WG review and later again. We decided we did 
not want to put "blame" on any app or OS. If you read the paper though, 
you'll know some ;)

> encryption is in mcast/bcast to result in only replaying messages.

The size of the receiver group does not make it trivial but how easy it 
is to just listen to the traffic. Unicast traffic is typically not seen 
by other hosts on a subnet. You'd have to have access to a router e.g. 
In other words anybody on the subnet can listen to bcast/mcast but not 
to unicast. The crypto is more difficult as more parties are involved. 
You'd need group keys and infrastructure, configuration etc. do this. 
The "unkown" was based on earlier reviewer feedback. It basically means 
you have no idea about who is potentially listening in as this is all 
passive.

> overexagerate for effect, without granular qualification.

There is a reference in the security considerations section which gives 
a hint at the complexity involved.

> Or at least I do not follow the "how".

Here is an example: if you randomize a MAC address in order to make your 
device not easily traceable, but then you send a broadcast once every 
minute with a persistent identifier, the change of MAC address did 
nothing to protect your traceability as the persitent identifier gives 
your identity away.

> seems quite weak. In protocol design, there is a tradeoff.

Not given the special nature of bcast/mcast.

> the fact that were seen in an application that is not mentioned)?

We clarified that the document really cares about protocols making use 
of bcast/mcast. That should deal with this, right?

> designers and developers? Do developers control all operational deployments?

This is really just for completeness sake. Of course this is outside of 
the protocol designers control but we thought this is worth mentioning.

>           (e.g. based on the SSID)"

We can change this to "the protocol SHOULD". We will update the draft 
accordingly.

Best,

Rolf

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 16 Jan 2018 05:44:33 +0000

Hi, Rolf,

On Jan 16, 2018, at 4:53 AM, Rolf Winter <[email-masked]<mailto:[email-masked]>> wrote:

Carlos,

Thanks to you for the quick response, and for the document. Please see inline.

Point well taken. As the previous reviewer suggested something similar, we changed the title from:

to

"Privacy considerations for protocols relying on IP broadcast and multicast""

And made textual changes throughout the document to rephrase "broadcast/multicast protocol" to something along the lines of "protocol making use of broadcast/multicast messages”

Thanks! I believe that change will add much clarity.

2. Threat model

But there is a whole section on what boradcast/multicast is being used for and how it differs from unicast. It also details which multicast addresses are most relevant for this work. The key is that the receiver group is much larger and protecting the traffic, with e.g. encryption is much harder.

I think you are pointing to S1.1. In my comment, I was referring more to the characteristics of the user, rather than those of bcast/mcast. Stephane’s email response explained that. Maybe better defining a “passive observer”? “Plugging” into the segment and capturing without any tapping?

That is the whole point and the document I thought is clear about it. In order to being able to even capture a unicast packet, you'd have to be at a special location inside the network such as a router.

“Passive observer” does not specify the attachment characteristics or location of the observing. That’s why I suggested above define the vector with more precision.

Bcast you just have to be connected to the network and then listen. Also, crypto is so much harder. With TLS two parties agree on keys etc. but in multicast it is not necessarily that trivial as more parties are involved. There is a reference regarding this also in the security considerations section.

This also did not directly translate to my reading, hence my comment for your consideration. Sentences like "can trivially record these messages and analyze their content” somewhat merge the two concepts of how to capture and the difficulty of encrypting. Separating the two concepts might provide less aliasing of the qualifier. “Trivial to capture if/because” and “trivial to analyze if/because”.

3. References:
The document says:
"  Most of these items

I would think one understands the document without having read the paper, so I would assume informative would be ok?

That’s for you/authors/WG/chairs/AD to discuss. To me, as a “passive observer” of the work, it reads as more normative than informative (since the methods are relevant to the conclusions)

We discussed it a bit in WG review and later again. We decided we did not want to put "blame" on any app or OS. If you read the paper though, you'll know some ;)

Understood — thank you for explaining that the discussion happened. And agreed.

The size of the receiver group does not make it trivial but how easy it is to just listen to the traffic. Unicast traffic is typically not seen by other hosts on a subnet. You'd have to have access to a router e.g. In other words anybody on the subnet can listen to bcast/mcast but not to unicast.

Sorry for repeating the same point I made earlier. I understand what you say, but my confusion was because the location and characteristics of the observer, other than being passive, were not fully described. I was drawn to making assumptions against a worst case.

The crypto is more difficult as more parties are involved. You'd need group keys and infrastructure, configuration etc. do this. The "unkown" was based on earlier reviewer feedback. It basically means you have no idea about who is potentially listening in as this is all passive.

There is a reference in the security considerations section which gives a hint at the complexity involved.

Here is an example: if you randomize a MAC address in order to make your device not easily traceable, but then you send a broadcast once every minute with a persistent identifier, the change of MAC address did nothing to protect your traceability as the persitent identifier gives your identity away.

Right, and that’s the type of example I thought that “break privacy efforts” was alluding to. But the text said "carelessly designed broadcast/multicast protocols”, and then I did not follow. I see revision -06 fixed this. Although the next text:

   In particular, carelessly designed
   protocols that use broadcast/multicast can break privacy efforts at
   different layers of the protocol stack such as MAC address or IP
   address randomization [RFC4941].

Could be improved as:

   In particular, carelessly designed application-layer
   protocols that use broadcast/multicast and embed persistent identifiers
   can negate outcome of privacy efforts at
   different layers of the protocol stack, such as MAC address or IP
   address randomization [RFC4941], and allow traceability even in the
   presence of other privacy protections.

Just a thought for your consideration.

6. Applicability.

There is the assumption in the text that protocol verbosity or timing is (always) directly related or consequential to user action. That does not seem to be the case, even for applications mentioned in the paper.

7. More applicability.
Section 2.2 starts with:

We clarified that the document really cares about protocols making use of bcast/mcast. That should deal with this, right?

Indeed. Thank you.

This is really just for completeness sake. Of course this is outside of the protocol designers control but we thought this is worth mentioning.

9. Summary

We can change this to "the protocol SHOULD". We will update the draft accordingly.

Thank you. My concern was three-fold, and mostly around:
1. how to know if someone "really must use”,
2. what “IETF-specified protocols” have to do in the mix, and
3. What is a “safe environment” and how it relates to “SSID” for a doc scope more broadly than WiFi.
Not really the grammar.

Thanks again for the consideration to the review and the very quick round-trip!

Best,

Carlos.

Best,

Rolf

Thanks,
Carlos.

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

---

From: Rolf Winter <[email-masked]>
Date: Fri, 19 Jan 2018 11:23:33 +0100

Hi Carlos,

we just uploaded a new version. I think I now better understood your 
comments. We stressed the fact, that in order to become a receiver (for 
the relevant addresses described in section 1.1. "To become a receiver, 
the only requirement is to be part of the same subnetwork." I hope this 
makes it much clearer, what the thread is and what a "passive observer" is.

We also changed the wording the the summary from "you SHOULD"... to "the 
protocol SHOULD".

Thanks again for your feedback.

Rolf

Am 16.01.18 um 06:44 schrieb Carlos Pignataro (cpignata):
> Hi, Rolf,
> 
>> On Jan 16, 2018, at 4:53 AM, Rolf Winter <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Carlos,
>>
>> "broadcast/multicast protocol" to something along the lines of 
>> "protocol making use of broadcast/multicast messages”
>>
> 
>> addresses are most relevant for this work. The key is that the 
>> receiver group is much larger and protecting the traffic, with e.g. 
>> encryption is much harder.
> 
> I think you are pointing to S1.1. In my comment, I was referring more to 
> the characteristics of the user, rather than those of bcast/mcast. 
> Stephane’s email response explained that. Maybe better defining a 
> “passive observer”? “Plugging” into the segment and capturing without 
> any tapping?
> 
>>
>> That is the whole point and the document I thought is clear about it. 
>> In order to being able to even capture a unicast packet, you'd have to 
>> be at a special location inside the network such as a router.
> 
> “Passive observer” does not specify the attachment characteristics or 
> location of the observing. That’s why I suggested above define the 
> vector with more precision.
> 
>> Bcast you just have to be connected to the network and then listen. 
>> Also, crypto is so much harder. With TLS two parties agree on keys 
>> etc. but in multicast it is not necessarily that trivial as more 
>> parties are involved. There is a reference regarding this also in the 
>> security considerations section.
>>
> 
> This also did not directly translate to my reading, hence my comment for 
> your consideration. Sentences like "can trivially record these messages 
> and analyze their content” somewhat merge the two concepts of how to 
> capture and the difficulty of encrypting. Separating the two concepts 
> might provide less aliasing of the qualifier. “Trivial to capture 
> if/because” and “trivial to analyze if/because”.
> 
>>> 3. References:
>>> The document says:
>>> "  Most of these items
> That’s for you/authors/WG/chairs/AD to discuss. To me, as a “passive 
> observer” of the work, it reads as more normative than informative 
> (since the methods are relevant to the conclusions)
> 
>> not want to put "blame" on any app or OS. If you read the paper 
>> though, you'll know some ;)
>>
> 
>> The size of the receiver group does not make it trivial but how easy 
>> it is to just listen to the traffic. Unicast traffic is typically not 
>> seen by other hosts on a subnet. You'd have to have access to a router 
>> e.g. In other words anybody on the subnet can listen to bcast/mcast 
>> but not to unicast.
> 
> Sorry for repeating the same point I made earlier. I understand what you 
> say, but my confusion was because the location and characteristics of 
> the observer, other than being passive, were not fully described. I was 
> drawn to making assumptions against a worst case.
> 
>> The crypto is more difficult as more parties are involved. You'd need 
>> group keys and infrastructure, configuration etc. do this. The 
>> "unkown" was based on earlier reviewer feedback. It basically means 
>> Here is an example: if you randomize a MAC address in order to make 
>> your device not easily traceable, but then you send a broadcast once 
>> every minute with a persistent identifier, the change of MAC address 
>> did nothing to protect your traceability as the persitent identifier 
>> gives your identity away.
> 
> Right, and that’s the type of example I thought that “break privacy 
> efforts” was alluding to. But the text said "carelessly designed 
> broadcast/multicast protocols”, and then I did not follow. I see 
> revision -06 fixed this. Although the next text:
> 
> There is the assumption in the text that protocol verbosity or timing is 
> (always) directly related or consequential to user action. That does not 
> seem to be the case, even for applications mentioned in the paper.
> 
>>> 7. More applicability.
>>> Section 2.2 starts with:
>> This is really just for completeness sake. Of course this is outside 
>> of the protocol designers control but we thought this is worth mentioning.
>>
>>> 9. Summary
> Carlos Pignataro, [email-masked] <mailto:[email-masked]>
> 
> /“Sometimes I use big words that I do not fully understand, to make 
> myself sound more photosynthesis."/
> /
> /