Re: [Captive-portals] captive portal detectors

[David Bird <dbird@google.com>]

On Thu, Apr 6, 2017 at 12:26 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

David Bird <dbird@google.com> wrote:
    > - I think statements like 'portals attempt to deceive hosts'
    > reinforces the belief that captive portals are themselves hostile,
    > while in fact I think you mean public access networks are hostile.

No, I don't think that I'm saying that.

Sorry for putting words in your mouth :)

 

We have created a bunch of protocols (DNSSEC, HTTPS, PKIX specifically),
that allows end hosts to work across public access networks, even if
they are hostile.

That is great (that your protocols protect the user even when not 'compliant' with hostile network access policies that compromise your security or protection)! But, has nothing to do directly with captive portals. 

I am by no means defending what people may or may not do in hostile networks (or networks you consider trusted). 

 

Yet, many captive portals choose to lie to me in order to "improve"
my user experience.  They claim to be IP addresses that they aren't,
and some of them still answer DNS queries in non-truthful ways.

DNS 'poisoning' is not common practice today in (respectable) Hotspots (because it leads quickly to broken user experiences and complaints). There are better ways to implement a captive portal that these networks could use, if they wanted to. Other than complain about what people do in hostile networks, and create protocols that protect the user in such networks (even if that means not working), what can the IETF do about it?

 

This is as true on "trusted" corporate networks that include a portal step as
public networks.

This sounds like an awkward (or maybe therapeutic, if spanking is allowed) conversation with your local network administrator, or perhaps HR.

 

Back in 1994, I built some of the first transparent proxies, when the term
NAT was unknown.  A major feature of firewalls of the time was that they
could authenticate the user before letting them out.
So I know lot about intercepting traffic in order to "help" users.
It was a mistake, and it was step 0 of an arms race.
I even created ICMP mechanisms such that firewalls could demand
IPsec authentication before traversal...   So I've been down the road we are
comtemplating, and I very much want to go down this road. It's the correct
answer.

If there is an 'arms race' between people who provide networks (employers, Hotspots, whomever) and the user, I don't think it is IETF's place to pick sides. We can only create protocols that create a fair, objective, and safe environment for users and their providers to conduct their business.