[174970] in North American Network Operators' Group
Re: Marriott wifi blocking
daemon@ATHENA.MIT.EDU (Owen DeLong)
Tue Oct 7 07:56:36 2014
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <5432D219.5050701@mtcc.com>
Date: Tue, 7 Oct 2014 04:52:29 -0700
To: Michael Thomas <mike@mtcc.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>, Brandon Ross <bross@pobox.com>
Errors-To: nanog-bounces@nanog.org
On Oct 6, 2014, at 10:32 AM, Michael Thomas <mike@mtcc.com> wrote:
> On 10/06/2014 10:12 AM, Owen DeLong wrote:
>> On Oct 6, 2014, at 8:06 AM, Michael Thomas <mike@mtcc.com> wrote:
>>=20
>>> On 10/06/2014 07:37 AM, Owen DeLong wrote:
>>>> On Oct 4, 2014, at 11:23 PM, Michael Thomas <mike@mtcc.com> wrote:
>>>>=20
>>>>> 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.
>>>>>>=20
>>>>>> Further, you seem to assume a level of control over client =
behavior that is rare in my experience.
>>>>>>=20
>>>>>> Owen
>>>>>>=20
>>>>> 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.
>>>>=20
>>>> Some corporations exercise extreme control over their clients. They =
are the exception, not the rule.
>>>>=20
>>>> The vast majority of corporate environments have to face the =
realities of BYOD and minimal control over client configuration, =
software load, etc.
>>>>=20
>>>>=20
>>> 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=94.
>> I think most environments already support this to some extent in =
terms of the APs participating in the controller framework and 802.1x =
authentication.
>>=20
>> However, that doesn=92t cover the guy that brings a linksys in and =
plugs it into his wired port.
>>=20
>> I think the only solution for those is detection followed by blocking =
the wired port until resolution.
>=20
> 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=92d use $CORPROSSID?
He=92ll 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=92m 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.
>=20
> That's orthogonal to somebody backhauling the AP's traffic to some =
other (possibly evil) network.
And back hauling the AP=92s 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=92s got nothing to do with what this discussion was =
about, however, you=92ve warped it into a completely different problem =
space.
>>=20
>>=20
>=20
> 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=92s.
That doesn=92t mean that 802.1x doesn=92t address the issue exactly as =
you described. People argue all kinds of things and there are lots of =
networks that haven=92t deployed 802.1x and/or strong authentication =
(WPA2-Enterprise, et. al).
Failure to deploy the tools doesn=92t mean the tools and standards don=92t=
exist.
Owen
