On 10/06/2014 10:12 AM, Owen DeLong wrote:
On Oct 6, 2014, at 8:06 AM, Michael Thomas <m...@mtcc.com> wrote:
On 10/06/2014 07:37 AM, Owen DeLong wrote:
On Oct 4, 2014, at 11:23 PM, Michael Thomas <m...@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?
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.
Mike
