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

[Warren Kumari <[e-mail]>]

On Thu, Jan 25, 2018 at 8:35 AM, Rolf Winter <[e-mail]> wrote:
> 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?

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


>
> Best,
>
> Rolf
>
> Am 25.01.18 um 00:58 schrieb Warren Kumari:
>
>> 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.
>>
>>
>> _______________________________________________
>> Int-area mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/int-area
>>
>



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