Subject: [Int-area] Call for adoption of draft-winfaa-intarea-broadcast-consider-02

From: Juan Carlos Zuniga <[email-masked]>
Date: Thu, 25 Aug 2016 18:56:20 -0400

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

---

From: Eliot Lear <[email-masked]>
Date: Sat, 27 Aug 2016 09:29:26 +0200

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

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?

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.

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.

Regards,

Eliot

On 8/26/16 12:56 AM, Juan Carlos Zuniga wrote:
> 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.
>
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Rolf Winter <[email-masked]>
Date: Mon, 29 Aug 2016 20:57:26 +0200

Eliot,

thanks for the review. Please find comments inline:

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

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

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

> network itself.  There's a hint of this in Section 2.1 re performance

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

---

From: Eliot Lear <[email-masked]>
Date: Mon, 29 Aug 2016 22:13:28 +0200

Rolf,

Thanks.  Please see below.

On 8/29/16 8:57 PM, Rolf Winter wrote:
> 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.

Precisely my point and this is the real crux of the matter.  It would be
VERY helpful if you were able to give some very specific examples of
discovery done wrong and how it would be done right.  It is probably
worth noting that sometimes this is just moving the problem from
"impossible to solve" to "impractical to solve", such as when PII moves
from discovery to an application protocol where the information is sent
in the clear, and that might even make matters worse, because the
distance of the stretch of the connection.  Another approach you might
want to explore is to examine common reasons why identifying information
ends up in discovery messages and what alternatives would prove better.

Now I realize that one draft can't fix everything, but there needs to be
enough advice for the developer to act on, and right now I don't think
there is.

> I would argue that some things require user configuration. But that
> does not necessarily mean editing YAML files or similar which is too
> (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.

I would suggest then that you require more support for your assertion. 
If you like I can dig up many papers that go the other way, not to
mention the long sordid history of TLS.

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

I think the case Stewart likes to look at is the baseball stadium or the
mall.

Eliot