Telechat Review of draft-ietf-intarea-broadcast-consider-05
review-ietf-intarea-broadcast-consider-05-rtgdir-telechat-pignataro-2018-01-13-00

Request Review of draft-ietf-intarea-broadcast-consider
Requested rev. no specific revision (document currently at 09)
Type Telechat Review
Team Routing Area Directorate (rtgdir)
Deadline 2018-01-23
Requested 2018-01-05
Requested by Alvaro Retana
Authors Rolf Winter, Michael Faath, Fabian Weisshaar
Draft last updated 2018-01-13
Completed reviews Iotdir Early review of -04 by Nancy Cam-Winget (diff)
Intdir Early review of -04 by Carlos Bernardos (diff)
Secdir Telechat review of -05 by Vincent Roca (diff)
Rtgdir Telechat review of -05 by Carlos Pignataro (diff)
Secdir Telechat review of -07 by Vincent Roca (diff)
Assignment Reviewer Carlos Pignataro
State Completed
Review review-ietf-intarea-broadcast-consider-05-rtgdir-telechat-pignataro-2018-01-13
Reviewed rev. 05 (document currently at 09)
Review result Not Ready
Review completed: 2018-01-13

Review
review-ietf-intarea-broadcast-consider-05-rtgdir-telechat-pignataro-2018-01-13

 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.