Subject: [Int-area] Warren Kumari's Discuss on draft-ietf-intarea-broadcast-consider-08: (with DISCUSS and COMMENT)

From: Warren Kumari <[email-masked]>
Date: Wed, 24 Jan 2018 15:58:24 -0800

Warren Kumari has entered the following ballot position for
draft-ietf-intarea-broadcast-consider-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-intarea-broadcast-consider/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Sorry for the late DISCUSS. I'm likely to clear after discussions on the call
tomorrow.

I'm somewhat surprised at how much this document glosses over the (sometimes
extensive) broadcast/multicast twiddling that Access Points and similar do (a
fair bit of discussion of which can be found in
draft-perkins-intarea-multicast-ieee802 (which I think will be expiring) or
draft-mcbride-mboned-wifi-mcast-problem-statement). Simply saying: "A feature
not uncommonly found on access points e.g. is to filter broadcast and multicast
traffic.  This will potentially break certain applications or some of their
functionality but will also protect the users from potentially leaking
sensitive information." seems to be shrugging off all of the privacy benefits
(or possibly harms) that this might create.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I found this sentence very confusing:
" 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. "   -- I know what it
is trying to say, but I don't think it accomplishes what it intends to.

---

From: Rolf Winter <[email-masked]>
Date: Thu, 25 Jan 2018 14:35:09 +0100

Warren,

I think I understand the issue you have with that bit of text. 
draft-perkins-intarea-multicast-ieee802 discusses a bunch of bcast/mcast 
management features that certain classes of APs provide. We have one 
example of this in the draft (and should point to 
draft-perkins-intarea-multicast-ieee802 for more examples). The problem 
is, that these features target specific protocols, i.e. ones that are 
standardized and worth paying attention to. The rest can only be dealt 
with by not rebroadcasting frames over the wireless medium. That is the 
best you can do. And it is done for performance reasons on networks such 
as the IETF meeting network, but I guess not for privacy reasons. All we 
really wanted to say was, that as a network administrator you can 
protect your users from the privacy risks described in the document, but 
you might affect certain applications, potentially rendering them 
useless. And we wanted it to be value-free because this in not a black 
and white thing in my personal opinion.

As a suggestion, we would add 
draft-mcbride-mboned-wifi-mcast-problem-statement and respective text. 
Since we already have the other draft in the document, we would point to 
the already implemented things in 
draft-perkins-intarea-multicast-ieee802, which really makes a good point 
for reusing IETF-specified protocols and not invent something new. Would 
that clear your discuss?

Best,

Rolf

Am 25.01.18 um 00:58 schrieb Warren Kumari:
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: Warren Kumari <[email-masked]>
Date: Thu, 25 Jan 2018 09:07:51 -0500

On Thu, Jan 25, 2018 at 8:35 AM, Rolf Winter <[email-masked]> wrote:
> management features that certain classes of APs provide. We have one example
> of this in the draft (and should point to
> draft-perkins-intarea-multicast-ieee802 for more examples). The problem is,
> that these features target specific protocols, i.e. ones that are
> standardized and worth paying attention to. The rest can only be dealt with
> by not rebroadcasting frames over the wireless medium. That is the best you
> can do. And it is done for performance reasons on networks such as the IETF
> meeting network, but I guess not for privacy reasons. All we really wanted
> to say was, that as a network administrator you can protect your users from
> the privacy risks described in the document, but you might affect certain
> applications, potentially rendering them useless. And we wanted it to be
> value-free because this in not a black and white thing in my personal
> opinion.
>
> draft-mcbride-mboned-wifi-mcast-problem-statement and respective text. Since
> we already have the other draft in the document, we would point to the
> already implemented things in draft-perkins-intarea-multicast-ieee802, which
> really makes a good point for reusing IETF-specified protocols and not
> invent something new. Would that clear your discuss?

Sure -- as I said, I was likely to be willing to clear during / after
the telechat.

WiFi networks are (in my opinion) one of the obvious/easiest places
where attackers can see other people's broadcast and multicast traffic
-- I'd like a bit more text discussing the fact that access points
already do some "magic" (e.g things like proxy arp, RA suppression,
etc) -- this will give a large hint to operators to want to minimize
leakage through multicast / broadcast that they should go and read
their vendors docs on this sort of thing. Your current text gets
close, but fleshing it out a bit would be helpful -- something like
"Operators wishing to minimize the privacy implications of broadcast
and multicast traffic on wireless networks are strongly encouraged to
investigate the broadcast and multicast suppression options provided
by their wireless equipment" (or something, this might be too much of
a value judgement, or whatever). Oh, as far as I know, the authors of
draft-perkins-intarea-multicast-ieee802 (I'm one of them) are not
planning on continuing work on this document, and so I'd suggest
against referencing it specifically / normatively :-)

Actually, my primary concern was that the text I quoted felt (to me)
like an afterthought; I wanted to make sure that y'all had known about
and considered the (in my opinion, powerful) privacy implications of
network / AP fiddling while writing this. It sounds like you have, so
I'll clear my discuss shortly.

Thank you,
W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf