[174884] in North American Network Operators' Group
Re: Marriott wifi blocking
daemon@ATHENA.MIT.EDU (Hugo Slabbert)
Fri Oct 3 23:46:00 2014
X-Original-To: nanog@nanog.org
Date: Fri, 3 Oct 2014 20:45:48 -0700
From: Hugo Slabbert <hugo@slabnet.com>
To: Jay Ashworth <jra@baylink.com>
In-Reply-To: <fa7fa015-f92d-403b-a59c-bf5074445d00@email.android.com>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
--Cp3Cp8fzgozWLBWL
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Jay,
Thanks; I think I was stretching this a bit far beyond just the Marriott=20
example. Killing hotspots of completely discrete networks "because $$$"=20
is heinous. I had extended this to e.g.:
1. Hotel charges for either wired or wireless access per device and has=20
network policies to that effect.
2. Guest pays for a single device and hooks up an AP or AP/NAT combo to=20
the wired port.
3. User piggybacks multiple devices on that device's WLAN.
=2E..to try to flesh out the scenarios. In the attempt I went a bit far=20
off the reservation. Apologies for the noise.
--
Hugo
On Fri 2014-Oct-03 23:32:39 -0400, Jay Ashworth <jra@baylink.com> wrote:
>Hugo, I still don't think that you have quite made it to the distinction t=
hat we are looking for here.
>
>In the case of the hotel, we are talking about an access point that connec=
ts via 4G to a cellular carrier. An access point that attempts to create it=
s own network for the subscribers devices. A network disjoint from the netw=
ork provided by the hotel or its contractor.
>
>This is a different case from the circumstance in a business office where =
equipment is deployed to prevent someone from walking in with an access poi=
nt /which pretends to be part of the network which the office runs./
>
>In the latter case, the security hardware is justified in deassociating pe=
ople from the rogue access point, /because it is pretending to be part of a=
network it is not authorized to be part of/.
>
>In the Marriott case, that is not the circumstance. The networks which the=
deauth probes are being aimed at are networks which are advertising themse=
lves as being /separate from the network operated by the hotel/, and this i=
s the distinction that makes Marriott's behavior is unacceptable.
>
>(In my opinion; I am NOT a lawyer. If following my advice breaks something=
, you get to keep both pieces.)
>
>On October 3, 2014 11:04:08 PM EDT, Hugo Slabbert <hugo@slabnet.com> wrote:
>>On Fri 2014-Oct-03 19:45:57 -0700, Michael Van Norman <mvn@ucla.edu>
>>wrote:
>>
>>>On 10/3/14 7:25 PM, "Hugo Slabbert" <hugo@slabnet.com> wrote:
>>>
>>>>On Fri 2014-Oct-03 17:21:08 -0700, Michael Van Norman <mvn@ucla.edu>
>>>>wrote:
>>>>
>>>>>IANAL, but I believe they are. State laws may also apply (e.g.
>>>>>California
>>>>>Code - Section 502). In California, it is illegal to "knowingly and
>>>>>without permission disrupts or causes the disruption of computer
>>services
>>>>>or denies or causes the denial of computer services to an authorized
>>user
>>>>>of a computer, computer system, or computer network." Blocking
>>access to
>>>>>somebody's personal hot spot most likely qualifies.
>>>>
>>>>My guess would be that the hotel or other organizations using the
>>>>blocking tech would probably just say the users/admin of the rogue
>>APs
>>>>are not authorized users as setting up said AP would probably be in
>>>>contravention of the AUP of the hotel/org network.
>>>
>>>They can say anything they want, it does not make it legal.
>>>
>>>There's no such thing as a "rogue" AP in this context. I can run an
>>>access point almost anywhere I want (there are limits established by
>>the
>>>FCC in some areas) and it does not matter who owns the land
>>underneath.
>>>They have no authority to decide whether or not my access point is
>>>"authorized." They can certainly refuse to connect me to their wired
>>>network; and they can disconnect me if they decide I am making
>>>inappropriate use of their network -- but they have no legal authority
>>to
>>>interfere with my wireless transmissions on my own network (be it my
>>>personal hotspot, WiFi router, etc.). FWIW, the same is true in
>>almost
>>>all corporate environments as well.
>>
>>Thanks; I think that's the distinction I was looking for here. By
>>spoofing deauth, the org is actively/knowingly participating on *my
>>network* and causing harm to it without necessarily having proof that
>>*my network* is in any way attached to *their network*. The assumption
>>
>>in the hotel case is likely that the WLANs of the "rogue" APs they're
>>targeting are attached to their wired network and are attempts to
>>extend
>>that wireless network without authorization (and that's probably
>>generally a pretty safe assumption), but that doesn't forgive causing
>>harm to that WLAN. There's no reason they can't cut off the wired port
>>
>>of the AP if it is connected to the org's network as that's their
>>attachment point and their call, but spoofed deauth stuff does seem to
>>be out of bounds.
>>
>>I'm not clear on whether it runs afoul of FCC regs as it's not RF
>>interference directly but rather an (ab)use of higher layer control
>>mechanisms operating on that spectrum, but it probably does run afoul
>>of
>>most "thou shalt not harm other networks" legislation like the
>>California example.
>>
>>>
>>>/Mike
>>>
>>>
>>
>>--
>>Hugo
>
>--=20
>Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--=20
Hugo
--Cp3Cp8fzgozWLBWL
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAEBCgAGBQJUL21sAAoJEJqxD/2xeDE+8Q0QAJZQnHivnanDwpTlRPBhlQ+s
rhrKY6dw/tXQjnvogEW/VrpVctlPngTkaRxQD3oleRrcphTKQTzilnPXJoPbsYoA
R/b4YP6fqGeP6APmJqdbwK4xdQayeY/SZVariro+cF3AWsMTluSak6+KiViJeBGx
NB6cxRnKgjC8CtBMz5oHblEmmpgIJiYRHJSIZWJwcnt6+JrHpP03OaeolyAT5z41
9fLzA6j7S1cNVos4ZVuZNpK9b0DbttyuuLyPbz7WcGNydAqM2kZSSH/YB3RnuNrG
430PJAfUKOOdunXbqpTkksyotD/CzfdJwH9ovWjqdc2JRoseaC21XexTm3eGcQTv
gnhPRLjP7nQZdW0x79UuuOOiGOFXv4jJx3FS+qtETacSGrf/5PVGgL+k81CfDDfn
lbSgZa4fIxi5S3mj/NStDhqNgZmjV0hONawlNA/zDXgA0jcIXhgdV+XAw86wqKzx
1O6mT95BwOiI4Nl2qjvuzZg6LxmBcdsX1fCOcO5iKB/C3BcoyubcTXvIQ5XRRP5W
5S/bZCEda+MTd5H+JZIDZgKM6GhRYMSbXPeLzOn9CnWfctM+hMsZlqtmNYTKN/XA
CRsqZ83Z43YWAO91aTWCfedxDFd9+T36tyDH0e10KrZy1oBmLSMuVY2fDN6hatcJ
RbH/sKyL+45MHtBdrWoV
=atmh
-----END PGP SIGNATURE-----
--Cp3Cp8fzgozWLBWL--
