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

Rolf Winter <rolf.winter@hs-augsburg.de> Mon, 15 January 2018 19:53 UTC

Return-Path: <rolf.winter@hs-augsburg.de>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBFB12EBBA; Mon, 15 Jan 2018 11:53:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LL94BTeCWzx; Mon, 15 Jan 2018 11:53:11 -0800 (PST)
Received: from fly2.rz.hs-augsburg.de (fly2.RZ.HS-Augsburg.DE [141.82.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D538312EBC6; Mon, 15 Jan 2018 11:53:10 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by fly2.rz.hs-augsburg.de (Postfix) with ESMTP id 91F9D120E54; Mon, 15 Jan 2018 20:52:49 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at hs-augsburg.de
Received: from fly2.rz.hs-augsburg.de ([127.0.0.1]) by localhost (fly2.rz.hs-augsburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RdrqeOdB5W0p; Mon, 15 Jan 2018 20:52:45 +0100 (CET)
Received: from [192.168.178.42] (ppp-212-114-180-26.dynamic.mnet-online.de [212.114.180.26]) by fly2.rz.hs-augsburg.de (Postfix) with ESMTPSA id D7681120C51; Mon, 15 Jan 2018 20:52:44 +0100 (CET)
To: Carlos Pignataro <cpignata@cisco.com>, rtg-dir@ietf.org
Cc: int-area@ietf.org, draft-ietf-intarea-broadcast-consider.all@ietf.org, ietf@ietf.org
References: <151590364970.3170.13650222639051565830@ietfa.amsl.com>
From: Rolf Winter <rolf.winter@hs-augsburg.de>
Message-ID: <712376b6-103b-fa47-263a-4d575a4d631a@hs-augsburg.de>
Date: Mon, 15 Jan 2018 20:53:01 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <151590364970.3170.13650222639051565830@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/vLUFCOSwpx1uToi7pyx9PAVYzEs>
Subject: Re: [Int-area] Rtgdir telechat review of draft-ietf-intarea-broadcast-consider-05
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jan 2018 19:53:14 -0000

Carlos,

thanks for the review. Comments below:

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"

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.

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

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

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

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

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

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

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


Best,

Rolf


> Thanks,
> 
> Carlos.
>