Subject: [Secauth] side meeting -- portal BCP

From: Michael Richardson <[email-masked]>
Date: Sun, 16 Nov 2014 00:21:46 -0500

Between the NOMCOM office hours and the IPv6-Scotch, I stopped into the side
meeting for secauth.  I admit that I know little about what Hosniah is
proposing, but it seems like a solution looking for a problem...  I don't
understand any of the SDN involvements at all. 

We did come to believe that it would be SO NICE if we could have
hotel/airport/etc. wifi-portals which did not suck: the bad ones rely on DNS
poisioning, the really really bad ones rely on your device USING the DNS
search path... the better ones just hijack port-80, which HTTP2.0 will likely
break.  

Tero suggested some kind of assertion that would at least say, "I've already
agreed to your terms and conditions" which one could put in... I guess a
DHCP* request. 

In the hotel (I had to switch hotels Friday night, so I was in a little
airport motel) van today, on the way to the airfort, the driver asked what I 
do, and I explained briefly what the IETF was.  He mentioned that on the
shaka.net hotel wifi they have, that Android phones get on no delays, but
that iPhones always need to be prodded.  I don't know what is up; but my
guess is that the hotel portal software whitelists by MAC address.  And newer
iPhone builds are doing MAC address randomization, while Android ROMs in the
field always (sadly) old...  This is a place where privacy improvements are
going to suck for a lot of people, I think.

I don't think we can write a useful/deployable BCP on portals without
participation of at least some of: AOSP/CyangogenMod, Apple/iPhone, and some
large portal users.  I'm thinking Starbucks... maybe we could use our IAOC
connections to the Hilton to suck them in.    The operators have to be at the
table, because most of the public facing portals are internally built.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 17 Nov 2014 10:42:00 +0200

> agreed to your terms and conditions" which one could put in... I guess a

That was not me, that was someone else. I think there is no way we are
going to be able to do anything, as if the hotel staff do not care
that the portals are bad for the customers, and operators want to show
all kind of advertisments and ask all kind of questions from you (your
email address, whatever, or just to agree on their terms and
conditions, which usally include all kind of junk), why should they
want to change.

I mean it will only help users, and none of those people seam to care.
Actually in some hotels they just know the system is stupid, but they
cannot do anything, as it is provided by third party and there is
"nothing" the hotel can do to fix situations.

In one hotel in argentina the travel info page told us that the wifi
is broken (the review was 2 years old), and it still was broken, and
when we asked the reception, they said that yes, they know it is
broken, but it is provided by 3rd party and they have not been able to
fix it, but we have put one adsl line and wlan modem in the reception,
you can use that :-)

So the hotel had few dozen useless wifi access points around the
hotel, and only one working that was put there most likely without
approval, that actually worked... Unfortunately that meant we had to
sit in the hotel lobby quite close to the reception... 

> table, because most of the public facing portals are internally built.

The internal built portals would be the ones that could be fixed, as
they might have way to fix things. The 3rd party portals provided by
telecom, isps etc are the ones which are impossible to fix, as hotels
most likely have multiyear contracts with them, and those 3rd party
operators have no interest of fixing anything, and if they can show
you few more ads while you log in, they might get more money.

So as the owners of the network do not care, I think this is problem
that we (the IETF) cannot fix...
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Nov 2014 13:30:42 -0500

for those CC'ed:
 http://mailarchive.ietf.org/arch/msg/secauth/-T5LFjp29NHyoCbCq19mufsn3VQ

    > "nothing" the hotel can do to fix situations.

I agree with you in practice.
In principle, educated customers could ask if the hotel wireless was BCPXXX
compliant.  This would include no molesting one's DNSSEC queries, and I
was lead to believe that this could wind up in a government procurement
request, if only there was a specification they could point to.

    > So the hotel had few dozen useless wifi access points around the hotel,
    > and only one working that was put there most likely without approval,
    > that actually worked... Unfortunately that meant we had to sit in the
    > hotel lobby quite close to the reception...

So the hotel has a contract and managemenet problem, and somehow this is not
affecting the hotel's ability to get business... did you consider just
unplugging the broken system for them?

    >> connections to the Hilton to suck them in.  The operators have to be
    >> at the table, because most of the public facing portals are internally
    >> built.

    > operators have no interest of fixing anything, and if they can show you
    > few more ads while you log in, they might get more money.

    > that we (the IETF) cannot fix...

well, I can't disagree with you; there seems to be an opportunity for someone.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Paul Lambert <[email-masked]>
Date: Mon, 17 Nov 2014 11:22:17 -0800

> On Nov 17, 2014, at 10:30 AM, Michael Richardson <[email-masked]> wrote:
> 
> 
> for those CC'ed:
>> that we (the IETF) cannot fix…

Other forums are working on the problem:  https://www.wi-fi.org/passpoint-release-2-operator-best-practices-for-aaa-interface-deployment-v200
(sorry … not a free spec :-(   

Paul

> _______________________________________________
> Secauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secauth

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 17 Nov 2014 23:34:26 +0100

> (sorry … not a free spec :-(

So we are not alone to think something could be done about it.

I think we could try to list the un-features of portals making them hard 
to automate through: i.e. the way it gets into DNS resolution path, the 
capture and change of IP packets, the http features helping with it.

And the features which may help - cookies were mentioned at the meeting, 
SDN-based firewall opening rules which may be triggered by an automated 
pass-through, scripting portal messaging, etc.

Total automation of portal get-through may not be achievable in all 
cases, but maybe a few goals could be imagined.  For example, ISPs with 
subscribed users may offer automated WiFi to them only, whereas other 
uses get the forms and the ad screens.

Another goal for simple automation may be the airport lounge hotspot 
providers who force into every-15minute ack the conditions.

Too, maybe a common recipe for Computers to automatically identify the 
presence of a capturing portal based on the kind of replies it receives 
(e.g. a DNS resolve of two different TLDs resolving into the same 
non-routable IP address) could be an achievable goal.

Alex

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Nov 2014 19:59:01 -0500

> Other forums are working on the problem:
    > https://www.wi-fi.org/passpoint-release-2-operator-best-practices-for-aaa-interface-deployment-v200

Thanks for the pointer.

will it be public once finished?  If not, then they are completely wasting
their time, as it just won't get implemented, because nobody will know it
exists. 

Does wi-fi.org think they have some actual customers involved who will be
able to drive adoption?

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Nov 2014 13:32:54 -0500

Yoav Nir <[email-masked]> wrote:
    > As another anecdote, I take the train to work every day. It's the same
    > physical train every morning, and I sit in the same car, and yet the
    > train wifi shows me the captive portal every day. Why? Because as soon
    > as I click "Enter", it shows a different web page with all their
    > notices ("the train from X to Y won't be running from 22-Nov at 20:00
    > until 24-Nov at 6:00") and their timetable web app. It's not a pleasant
    > experience, but they really want me to see that page, and providing a
    > technical means to not show this page wouldn't help.

I'm thinking about providing them a technical means by which to tell you
about the page; you then could look at it on the machine tath is actually
able to show it to you...

    > They're foiled anyway by the operating system on both my laptop and my
    > phone. As soon as the OS detects that it has "the Internet", the
    > special captive portal window disappears, so I manage to see the

I'm curious about this part.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Nov 2014 13:42:13 -0500

Yoav Nir <[email-masked]> wrote:
    > Macs, phones, Some VPN clients, they all use a similar mechanism.

Android 4.0 seems to do the same thing, but it only puts up a notify that one
might want to login, it doesn't do the continuing monitoring, and proceeding.

    > Macs it takes a few seconds so I can still see the notices and if I click
    > anything there it stays. On my phone (not an Apple product) it disappears
    > immediately.

People have talked about making it a standard way...

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 20 Nov 2014 15:52:09 +0200

> unplugging the broken system for them?

Yes. Or actually we asked if we could go and see if we can fix it, but
they didn't give us permission... :-)

It is also funny to see how different networks are in different
countries.

In Argentina every single bar, restaurant, hotel etc had free wifi,
but every single one were always encrypted using WEP or similar, with
very weak fixed password (hotel2013, internet2013, restaurantname,
restaurantname2013 etc). Usually you tried the name of place, name of
place + year or just internet / internet + year, and if none of those
worked, then you checked the password from the restaurant menu, or the
card in wall / table.

They didn't have captive protals or any of this click here to
continue.

Then on some other countries all hotels seem to have this similar
system printing one time username / password on thermal paper, and
those codes are valid for 30/60/120 minutes from first use for one
device, and they must be entered to the web captive portal when you
start to use them. Usually they are free, so you can go and ask as
many as you like, but on some other countries they cost few dollars
each...

All of this is just pointing out that it does not seem to be what
hotels / restaurants etc are wanting, but what have been sold to them
by either the regulations or by the consulting firms / ISPs in that
region, and the hotels / restaurants do not have real control over
whats get installed... If the only thing that is offered to you is the
ISP xxx's username + password based system, that is only thing you can
get unless you are have enough knowledge to set up the system
completely by yourself.
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Nov 2014 12:38:33 -0500

> worked, then you checked the password from the restaurant menu, or the

So basically just enough security to say that they didn't have an open AP,
could it be that having an open AP in Argentina is against some law?

    > many as you like, but on some other countries they cost few dollars

I had the same experience in many places.  My take is that management is
anxious about being able to get rid of undesireables from their front lobby,
etc. while the front desk staff mostly do not care.  One coffee shop chain in
Ottawa (Bridgehead, locally owned) has some shops with the printer system and
some are just open+click-through.  For awhile some of them would decline to
hand out usernames when the place was busy, but that seems to have
declined. I think it's a quesiton of control.

At the IETF level, I sure would like to have a DHCP option that told me the
URL at which I need to authenticate.    I'd like it if the initial lease was
rather short (10 minutes), and when I renew, it would tell me how long I have
in my ticket/username/etc. left.   One could as far as BCP's what the right
ICMP unreachable to return before login and/or after time is up.
This is particularly import for non-HTTP applications that run in the
background.

    > by either the regulations or by the consulting firms / ISPs in that

It would be lovely if we could capture what they actually want, but I don't
see a way to get the right people engaged in the conversation.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 20 Nov 2014 09:14:08 -0600

I'm responding in air, so I may be a bit back in the thread once this sends, but my thoughts on this have not changed from before the Hawaii IETF.  Inline

Sent from my iPhone

> On Nov 17, 2014, at 6:59 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

Exactly.  While this would be nice for users, providers of wifi access are not motivated to enable the seamless access described.  I'd need to see interested implementers come to the table before we could charter something.  Otherwise, an experimental, possibly ISE draft may be the only feasible option as this could just be a waste of time to solve.  

Once you setup access points, you can connect in the future without trouble unless re-authentication is required to pay a fee, register, etc.

Best regards,
Kathleen

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 21 Nov 2014 15:25:31 +0200

> could it be that having an open AP in Argentina is against some law?

Could be. At least I know that in some cases in Finland some people
have said that the owner could be liable for the traffic originating
from the open access point, but someone using their encrypted access
point without their knowledge (regardless how easy the password is)
would be considered as hacking, thus they are not liable for the
traffic. But I think that is actually not true even if someone claims
so. 

> This is particularly import for non-HTTP applications that run in the

I quite often have the problem that my web browser have about 2-3
dozen tabs open, and if I need to start my web browser to do login in
location where they redirect all urls to login page, I will be really
angry, as all my tabs are suddenly rendered unusable...

Thats why I do have separate browser installed just in case I need to
login before I can start my real browser... :-)
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Fri, 21 Nov 2014 14:20:23 -0500

> login before I can start my real browser... :-)

Yes, I do *exactly* the same thing.
And I always attempt access to some reliable site that I don't care
about... because likely my DNS will get poisoned too.  The real problem is
that once the site I choose turns on DNSSEC, instead of just being poisoned,
I will find that it just doesn't load.  Many portals are smarter and just
hijack port 80, which will also go away as a method.

That's why I'm CC'ing Steve Crocker and Dan York: it's about DNSSEC
deployment hurdles.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Nov 2014 11:07:30 +0100

> Michael Richardson writes:
[...]
>> URL at which I need to authenticate.

It sounds feasible.  I guess DHCP enhancements may be considered ok by 
portal manufacturers.  It can offer hints to the automatisation running 
in the client.

Alex

     I'd like it if the initial lease was