nanog mailing list archives

Re: Breaking the internet (hotels, guestnet style)


From: Joe Greco <jgreco () ns sol net>
Date: Tue, 8 Dec 2009 03:39:18 -0600 (CST)



In message <200912080332.nB83WKSo037049 () aurora sol net>, Joe Greco writes:
IMHO there is no need for any sort of DNS redirection after user 
authentication has taken place.

It may be hazardous even before user authentication has taken place.
Even given a very low TTL, client resolvers may cache answers returned
during that initial authentication.

We of course redirect UDP/TCP 53 to one of our servers along with 80 
(http) 443 (https) 8080, 3128 (proxy) to the local hotspot *before* any 
authentication has occurred, but once this is completed the only reason 
any guest would use the local DNS server is if they were assigned a DHCP 
address.

Which, presumably, many/most of them are.  Supplying a functional DNS
server shouldn't be that difficult, but real world experience shows just
how well some operators run these services.

As far as our Routerboard/Mikrotik setup works, it'll masquerade for any 
non standard IP addresses that appear on the network (guests with static 
ip's assigned, corporate laptops etc) but once again after the 
authentication stage anything is allowed to pass unhindered.

The only redirection that is used after authentication is for port 25 as 
90% of user trying to send mail out via port 25 have no idea how to 
change their mail server, let alone why they might need to.
It can be an issue as some systems use authentication on port 25.

Sounds like an opportunity for a custom proxy.  Clients that can
successfully authenticate to an external mailserver on 25 are probably
by definition nonproblematic.  The remainder probably deserve to get
jammed through an aggressive spam, virus, and other-crap filter, with
in-line notification of rejections.  You can do some other sanity stuff
like counting the number of hosts contacted by a client; anything in
excess of a small number would seem to be a good indicator to stop.

This really should be a DHCP option which points to the authentification
server using ip addresses.  This should be return to clients even
if they don't request it.  Web browers could have a hot-spot button that
retrieves this option then connects using the value returned.

No need to compromise the DNS or intercept http.

But that doesn't change the fact that there's a need; it's a part of the 
flawed design of the various components, because this problem wasn't 
envisioned and solved and now we have a mess.  Even the hotspot vendors 
cannot agree on a unified way to do things; this means that each network
you try to connect to will implement its own set of unique brokenness,
ranging from requirements for a particular OS/browser, use of reserved/
allocated IP spaces for stupid reasons (hi, 1.1.1.1!), various DNS/HTTP
attempts at redirection, blocking, etc.

I know what you're saying, but seriously, haven't we just repeated all
the same mistakes in IPv6?  And of course it'd be a nightmare to cover
all the edge cases, this is why nobody tries to figure it out, so in
the end we end up with many really cruddy hatchet jobs.

Why would "web browsers" have a hot-spot button?  What if I want to
just use ssh?  And where's the web browser on my VoIP telephony 
adapter, etc?  :-)

It's gotta be difficult for the hotspot networks.  Even at&t can't seem
to make it all work right even when they control both sides; I've seen
iPhones just hang when connecting to attwifi (and I can say I've seen
it not work in some way maybe even more often than I've seen it actually 
work).  At least the iPhone seems to have some built-in support for this
sort of thing.  (Anybody know anything more about that?)

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.


Current thread: