Marriott wifi blocking
mike at mtcc.com
Mon Oct 6 17:32:09 UTC 2014
On 10/06/2014 10:12 AM, Owen DeLong wrote:
> On Oct 6, 2014, at 8:06 AM, Michael Thomas <mike at mtcc.com> wrote:
>> On 10/06/2014 07:37 AM, Owen DeLong wrote:
>>> On Oct 4, 2014, at 11:23 PM, Michael Thomas <mike at mtcc.com> wrote:
>>>> On 10/04/2014 11:13 PM, Owen DeLong wrote:
>>>>> Very true. I wasn't talking about ideal solutions. I was talking about current state of FCC regulations.
>>>>> Further, you seem to assume a level of control over client behavior that is rare in my experience.
>>>> I this particular case, I think that enterprise could go a very long way to driving a solution through
>>>> standards and deployment. They, after all, call the shots of who does and who doesn't get over
>>>> the corpro-drawbridge. A much different state of affairs than the typical unwashed masses dilemma.
>>> Not sure what you mean by corpro-drawbridge in this context.
>>> Some corporations exercise extreme control over their clients. They are the exception, not the rule.
>>> The vast majority of corporate environments have to face the realities of BYOD and minimal control over client configuration, software load, etc.
>> It means that they can exercise control of what they allow on their corporate network, byod or not. Nobody
>> would allow a WEP-only wireless device on their network these days, so it's not hard to imagine that if a standard
>> for authenticating AP's became available and enterprises went to the effort to upgrade their AP kit, they could
>> reasonably say "use a client that supports this, or you must vpn in”.
> I think most environments already support this to some extent in terms of the APs participating in the controller framework and 802.1x authentication.
> However, that doesn’t cover the guy that brings a linksys in and plugs it into his wired port.
> I think the only solution for those is detection followed by blocking the wired port until resolution.
If there's strong auth to the AP which enforces which SSID I connect to,
who cares about somebody bringing their
own AP and fire up an SSID with the same name as $COPROSSID?
> Most companies I have worked with that took the time to think this through simply made it an instant firing offense for anyone to plug in an unauthorized WAP to the corporate wired network, problem solved.
That's orthogonal to somebody backhauling the AP's traffic to some other
(possibly evil) network.
>> That's a much better outcome than quibbling about squatter's rights, blah blah blah.
> To the extent that such is a feasible solution, I think it was long since done. That’s got nothing to do with what this discussion was about, however, you’ve warped it into a completely different problem space.
Not really. The original posts posited that there were perfectly valid
reasons to send deauth frames to "rogue" AP's because
clients might connect to "spoofed" SSIDs. That's a bad solution to what
at its heart is an authentication problem. Bring strong
auth to the table, and there's no reason to worry about "spoofed" SSID's.
More information about the NANOG