Eliot,
thanks for the review. Please find comments inline:
Am 8/27/16 um 9:29 AM schrieb Eliot Lear:
Juan Carlos,
I like the idea of this document being published as an informational
document, but I wonder if the document needs another rev or two first.
While it is important to have privacy considerations for discovery
protocols, this document needs to go further than that to be useful to
developers so that they just get it right. Section 1 talks about how
the document is intended for non-IETF protocols. I think we need
guidance for both IETF and non-IETF. As a port reviewer, I want to
encourage developers to use common mechanisms. In fact I want to be
able to refuse port requests that don't use those common mechanisms
without good reason. That means that the common mechanisms need to
really do the right thing. And so when the authors write:
For one, non-
standard protocols will likely not receive operational attention and
support in making them more secure such as e.g. DHCP snooping does
for DHCP because they typically are not documented.
That is a very strong argument for use of IETF protocols, and they
should say so (but that last phrase should be made more clear as to what
it means - I had trouble parsing it.).
We can be more clear here. The general principle here is that the
protocols of the IETF are well-known and their header structure and
operation are understood, so it is possible to make operational
provisions in case the network administrator wants to protect the
privacy of its users or strengthen the security of the network. DHCP
snooping is an example of this where DHCP packets are not re-broadcast
over the wireless interface. You can also generally switch off e.g.
broadcasts but that is not always desirable. We had broadcasts generally
switched off on the IETF wireless network in Yokohama and Berlin (but
for performance reasons). With multicast, that is however not as trivial.
What is needed are specific recommendations or even the strengthening of
a generalized mechanism, the obvious candidate being mDNS/DNS-SD. What
specific recommendations would the authors make when using 6761/6762?
Using a well-known protocols such as mDNS, DNS-SD, LLMNR etc. is only
solving parts of the problem. In our experiments, mDNS - albeit being a
standard - was a big problem concerning privacy as it often contained
PII. Section 2.3. addresses this.
Also, Section 2.5 talks about configurability as if that's a good
thing. Given the opportunity of the user to make a decision in this
space, he or she is likely to make the wrong one. We know this from
long experience. Again what is needed is far more specific
recommendations that do not require user interaction.
I would argue that some things require user configuration. But that does
not necessarily mean editing YAML files or similar which is too
technical for the average user. A good example (to me at least) is how
e.g. Windows asks a user what kind of network an unknown network is
(private, work or public I think are option here). Every user can answer
that and Windows decides how to configure itself based on that piece of
information. That is enough for potentially privacy leaking protocols
where at home a broadcast is supposingly fine, but broadcasting your
identity on the airport network is probably not. Making a wrong decision
here is also better than no decision I would assume, because many
protocols we observed broadcast/multicast irrespective of the network
location today. So the user won't be worse off compared to today.
There is probably another avenue of consideration here as well. It is
probably also helpful to discuss scale. Use of unique identifiers can
adversely impact scale either within the server implementation or on the
network itself. There's a hint of this in Section 2.1 re performance
and energy consumption.
An the operational experience on the IETF meeting network. We can add
text here but some of that would be duplications of the referenced work.
But that is fine. On one of the networks where we did our experiments,
there was an average rate of 20kbit/s of broadcast and multicast
traffic. That does not sound like much, but that is average, including
nights and weekends, where there is hardly any traffic.
Best,
Rolf
Regards,
Eliot
On 8/26/16 12:56 AM, Juan Carlos Zuniga wrote:
Dear all,
At the Berlin meeting we got strong support to adopt
draft-winfaa-intarea-broadcast-consider-02 as a WG work item. We are
now confirming the adoption by issuing this call on the ML.
The document has been presented and discussed now for a few meetings
and we believe the contents are highly relevant to the group.
Please indicate your support (or lack thereof) by replying to this
email until September 9.
https://tools.ietf.org/html/draft-winfaa-intarea-broadcast-consider-02
Regards,
Juan Carlos & Wassim
___
Int-area
