Marriott wifi blocking

Tue Oct 7 11:52:29 UTC 2014

On Oct 6, 2014, at 10:32 AM, Michael Thomas <mike at mtcc.com> wrote:

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

Who said he’d use $CORPROSSID?

He’ll probably use Linksys, leave it wide open, and, you know, your internal network just became accessible to any script-kiddie on a nearby mountain top with a coffee can.

I’m going to guess that most IT managers and CSOs would be unhappy with that situation, but perhaps I am wrong.

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

And back hauling the AP’s traffic to some other (possibly evil) network is completely orthogonal to ANY of the threads in this discussion.

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

That doesn’t mean that 802.1x doesn’t address the issue exactly as you described. People argue all kinds of things and there are lots of networks that haven’t deployed 802.1x and/or strong authentication (WPA2-Enterprise, et. al).

Failure to deploy the tools doesn’t mean the tools and standards don’t exist.

Owen