Re: [Int-area] Rtgdir telechat review of draft-ietf-intarea-broadcast-consider-05

[Rolf Winter <[e-mail]>]

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 <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> Carlos,
>>
>> thanks for the review. Comments below:
> 
> Thanks to you for the quick response, and for the document. Please see 
> inline.
> 
>>
>> Am 14.01.18 um 05:20 schrieb Carlos Pignataro:
>>> 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?
>>
>>
>> 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”
>>
> 
> Thanks! I believe that change will add much clarity.
> 
>> We published a new version reflecting that already.
>>
>>> 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.
>>
>> 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?
> 
>>
>>> 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.
>>
>> 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
>>>    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?
>>
>> 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)
> 
>>> 4. Qualification of examples used to derive conclusions.
>>> "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 ;)
>>
> 
> Understood — thank you for explaining that the discussion happened. And 
> agreed.
> 
>>> 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.
>>
>> 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.
>>
>>> 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.
>>
>> There is a reference in the security considerations section which 
>> gives a hint at the complexity involved.
>>
>>> 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".
>>
>> 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.
>>> 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.
>>
>> Not given the special nature of bcast/mcast.
>>
> 
> 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:
>>> "   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)?
>>
>> We clarified that the document really cares about protocols making use 
>> of bcast/mcast. That should deal with this, right?
> 
> Indeed. Thank you.
> 
>>
>>> 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?
>>
>> 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
>>> 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)"
>>
>> 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, [e-mail] <mailto:[e-mail]>
> 
> /“Sometimes I use big words that I do not fully understand, to make 
> myself sound more photosynthesis."/
> /
> /