Subject: Re: [Captive-portals] Not good....

From: Michael Richardson <[email-masked]>
Date: Sun, 02 Apr 2017 18:27:45 -0400

David Bird <[email-masked]> wrote:
    > Wi-Fi at Chicago O'Hare Airport defeating Chome captive portal check.
    > They also require using their DHCP assigned DNS (why don't they just
    > DNAT DNS to their server, I don't know -- chilli will do that :)

One of the things we are going to need to do is to find a way use the
stick as well as the carrot when it comes to poorly behaved sites.

This requires that we have running code and RFCs to form the carrot first.
But, we do need a place to record the problems we and others see with
captive portals that there out there.   It would be lovely if we could
get one or more social media travel sites to introduce categories for
"poor captive portal" in their reviews.

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

---

From: David Bird <[email-masked]>
Date: Sun, 2 Apr 2017 15:53:59 -0700

Great idea. This list is also a good place to document a current state of
things (?) - and IETF travels will see it all!

Disclaimers: While I recommend Wireshark for troubleshooting, and things
like pcap files are valuable for reference and debugging, please do not
post anything containing PII to the mailing list (or to anyone, delete it!).

---

From: mariko kobayashi <[email-masked]>
Date: Mon, 3 Apr 2017 18:56:03 +0900

+1
I know some other strange behaviors of capport and very interested in 
the idea.
If we can define their common problems, reasons and solutions, it will 
be helpful output for some people.
My survey can also includes some contents related to "poor captive portal."

Mariko

On 2017/04/03 7:53, David Bird wrote:
> Great idea. This list is also a good place to document a current state 
> of things (?) - and IETF travels will see it all!
>
> Disclaimers: While I recommend Wireshark for troubleshooting, and 
> things like pcap files are valuable for reference and debugging, 
> please do not post anything containing PII to the mailing list (or to 
> anyone, delete it!).
>
> On Sun, Apr 2, 2017 at 3:27 PM, Michael Richardson 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     David Bird <[email-masked] <mailto:[email-masked]>> wrote:
>     Michael Richardson <[email-masked]
>     <mailto:[email-masked]>>, Sandelman Software Works
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals

-- 
------------------------------------------------⭐︎

　Mariko Kobayashi([email-masked])
　Keio Univ. SFC B4
   Jun Murai Lab./WIDE/ao(あお)
　
---------------------------⭐︎

---

From: Martin Thomson <[email-masked]>
Date: Mon, 3 Apr 2017 18:29:35 -0500

> stick as well as the carrot when it comes to poorly behaved sites.

The big stick I see here is the increased use of HTTPS.  Do we really
need anything more?

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 4 Apr 2017 14:43:12 -0700

> On 3 Apr 2017, at 4:29 pm, Martin Thomson <[email-masked]> wrote:
> 

Especially if browsers ever flip the default for the location bar from HTTP to HTTPS (see <https://bugzilla.mozilla.org/show_bug.cgi?id=1158191>).

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Michael Richardson <[email-masked]>
Date: Tue, 04 Apr 2017 20:36:13 -0400

> The big stick I see here is the increased use of HTTPS.  Do we really

Well, we can wish, but I don't know that it will feedback to the right place.

(On my laptop, I open a disposable firefox profile (without HTTPS
everywhere), and I have to find some site that has an http redirect.  I can
usually depend upon my city's web site to be clueless.
That's a lot of effort and I'm technically clueful.  The Freehand Chicago had
all these problems, plus their DNS was intolerant of AAAA requests.)

So I don't see HTTPS as fixing or shaming any portals; rather I just see
users getting frustrated and going someplace else without knowing why.
They don't call support; and if they do, support will ask them to "turn it
off and on", and to please try IE6.

What they might do is write a review, and this is where I think we need to do
something.

---

From: David Bird <[email-masked]>
Date: Tue, 4 Apr 2017 17:53:51 -0700

This is something we *can* solve...

I thought so a year ago:
https://www.ietf.org/jabber/logs/capport/2016-04-05.html

[21:55:16]
<https://www.ietf.org/jabber/logs/capport/2016-04-05.html#21:55:16.776272>
<David
Bird> I think solving the HTTPS issue is a priority for the group.
[21:55:21]
<https://www.ietf.org/jabber/logs/capport/2016-04-05.html#21:55:21.399884>
<Alan
DeKok> yes
[snip]
[21:58:26]
<https://www.ietf.org/jabber/logs/capport/2016-04-05.html#21:58:26.100385>
<David
Bird> ICMP + DHCP URL option can solve the HTTPS issue.

And still do... :)

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Apr 2017 11:56:12 -0400

David Bird <[email-masked]> wrote:
    > This is something we can solve...

Yes, I agree.  That's the carrot part.
     "Do X and life will be better"

But, I was talking about the stick part:
     "Until you do X, you'll get a bad review"

I realize that this isn't a protocol we can write.
It is something that the occured when we did the ECN experiment.

I am suggesting that when a platform fails to find X, I think it
SHOULD let the user know about it.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 06 Apr 2017 11:31:29 -0400

Michael Richardson <[email-masked]> wrote:
    > Yes, I agree.  That's the carrot part.  "Do X and life will be better"

    > But, I was talking about the stick part: "Until you do X, you'll get a
    > bad review"

    > I realize that this isn't a protocol we can write.  It is something
    > that the occured when we did the ECN experiment.

    > I am suggesting that when a platform fails to find X, I think it SHOULD
    > let the user know about it.

I was thinking more about IETF actions relating to poorly behaved legacy
portals.

I would like to propose that this WG write a document detailing how legacy
portals attempt to deceive hosts, standardizing the descriptions.

For each case where the host concludes that they have detected some specific
kind of deception, the document would provide a standardized description of
what kind of event was detected.  We would provide simplified (but common)
english descriptions of the kind of deception (i.e. "DNS request for
wellknown.example.com returned lie", or "DNSSEC bits were turned off", or
ICMP to 8.8.8.8 is not answered, or port-443 to wellknown.example.com returns
invalid certificate, etc...) along with an error code such that the
descriptions could be translated.

As an extension the user agents could collect the information for upload
to reputation systems of the end user's choice. (or not, as the user wishes)
(I suspect that MILE has all the common infrastructure we want for the
format)

So in effect, I'm asking for a standardized interface from a user space
application (an "app") to the captive portal detection system inside the
OS.

---

From: David Bird <[email-masked]>
Date: Thu, 6 Apr 2017 09:27:27 -0700

I think there are some good ideas here, however,  :-)

- Is this really about "captive portals" or "public access" networks?

- 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.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 06 Apr 2017 15:26:03 -0400

David Bird <[email-masked]> 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.

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.

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.

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

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.

---

From: David Bird <[email-masked]>
Date: Thu, 6 Apr 2017 14:49:24 -0700

> No, I don't think that I'm saying that.
Sorry for putting words in your mouth :)

> that allows end hosts to work across public access networks, even if

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).

> 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
This sounds like an awkward (or maybe therapeutic, if spanking is allowed)
conversation with your local network administrator, or perhaps HR.

> comtemplating, and I very much want to go down this road. It's the correct
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.