Subject: Re: [Captive-portals] practicality of 511 HTTP status code

From: Dave Dolson <[email-masked]>
Date: Fri, 23 Jun 2017 18:11:23 +0000

It seems 511 is probably better than 30x for non-browser requests-clearly an error instead of redirecting to something unexpected.
Is 511 likely to be OK for old IoT devices? Probably a better outcome than 307.

Do we expect the enforcement device should be checking user-agent to decide on 511 vs. 30x code?

For captive portals to want to use 511 (vs. 307), the browsers would have to behave in a better way from the network operator's perspective.
I would expect the browsers to show the information that the operator wants to be displayed.

Having said all of that, this solution is specific to HTTP, vs. the ICMP approach that works for any protocol.

-Dave

From: Captive-portals [mailto:[email-masked]] On Behalf Of Vincent van Dam
Sent: Sunday, May 7, 2017 3:09 PM
To: David Bird; Erik Kline
Cc: [email-masked]
Subject: Re: [Captive-portals] practicality of 511 HTTP status code

- A legacy 30X response will still be needed for some user-agents

Is that because you don't expect all user-agents (webbrowsers specifically) to support it?

- The response contains HTML that should contain the login URL (or a meta refresh, etc), which isn't a very well structured way to get the URL

I agree, it makes more sense that the url would be in a response header instead (like the 30x status).

   It is not intended to

   encourage deployment of captive portals -- only to limit the damage

   caused by them.

Damage? Hm...

In terms of non-browsers accessing apis, they should be using TLS! And perhaps not follow redirects or otherwise add some integrity to their api.

I agree, apis should use tls. Not every developer might agree though (a rest api containing weather predictions?).

But also, I don't think we can fix the world, fix every api/client that is ever made. We can only at least identify mitm 30x scenarios are implemented, and try to regulate that scenario a bit more, which has been done by introducing the 511.

________________________________
Van: Captive-portals [[email-masked]] namens David Bird [[email-masked]]
Verzonden: zondag 7 mei 2017 20:36
Aan: Erik Kline
CC: [email-masked]<mailto:[email-masked]>
Onderwerp: Re: [Captive-portals] practicality of 511 HTTP status code
I personally do not find it very useful in public access networks, because:
- A legacy 30X response will still be needed for some user-agents
- Returning 511 is still a man-in-the-middle response (nothing changed there)
- The response contains HTML that should contain the login URL (or a meta refresh, etc), which isn't a very well structured way to get the URL
- differences in how browsers handle the 'error' and the associated user experience

There are a couple other oddities:

   Note that the 511 response SHOULD NOT contain a challenge or the

   login interface itself, because browsers would show the login

   interface as being associated with the originally requested URL,

   which may cause confusion.

Why shouldn't it contain a challenge? (the reason given only relates to the 'login interface itself').

   It is not intended to

   encourage deployment of captive portals -- only to limit the damage

   caused by them.

Damage? Hm...

In terms of non-browsers accessing apis, they should be using TLS! And perhaps not follow redirects or otherwise add some integrity to their api.

On Sun, May 7, 2017 at 1:05 AM, Erik Kline <[email-masked]<mailto:[email-masked]>> wrote:
I wanted to poll the group's thoughts on the usefulness of the rfc6585#section-6 511 HTTP status code.

Has anybody tried to serve 511s to clients, and if so what were the results?

Might it be useful to serve an API endpoint (rather than the full-blown HTML UI)?

I'm trying to get a sense of whether this will be a useful tool to use in assembling a recommended portal interaction.  If we determine it's not really going to be a workable component, then that's useful to know too.

_______________________________________________
Captive-portals mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/captive-portals

---

From: Julian Reschke <[email-masked]>
Date: Fri, 23 Jun 2017 20:34:23 +0200

On 2017-06-23 20:11, Dave Dolson wrote:
> It seems 511 is probably better than 30x for non-browser 
> requests—clearly an error instead of redirecting to something unexpected.
> 
> ...

FWIW, why is *307* desirable in the first place? Wouldn't it be better 
to use 301/302 or even 303?

Best regards, Julian

---

From: Dave Dolson <[email-masked]>
Date: Fri, 23 Jun 2017 18:53:33 +0000

Probably all of those codes are used, as well as 200 (with content).
We could debate which is best, but that's a distraction, since we want portals to stop pretending to be the real end-point.
(FWIW, I think 301 is a bad idea, since later requests should try the real URI again.)

My hypothesis is that 511 is an acceptable thing to send an old (pre-RFC6585) device, when there is no expectation of causing user interaction.

-Dave

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Friday, June 23, 2017 2:34 PM
To: Dave Dolson; Vincent van Dam; David Bird; Erik Kline
Cc: [email-masked]
Subject: Re: [Captive-portals] practicality of 511 HTTP status code

On 2017-06-23 20:11, Dave Dolson wrote:
> requests-clearly an error instead of redirecting to something unexpected.
> 

FWIW, why is *307* desirable in the first place? Wouldn't it be better to use 301/302 or even 303?

Best regards, Julian

---

From: mariko kobayashi <[email-masked]>
Date: Sat, 24 Jun 2017 09:37:08 +0900

(This is just information)
I haven't seen Captive Portal which responses 307, and most of them 
reply 302 or 200.
I only saw Meraki's one replies 307.

Although I cannot guess how it can be implemented on the current Wi-Fi 
services,
511 will be helpful for such devices because we do not have a clear 
method to check the existence of Captive Portal.

- Mariko
On 2017/06/24 3:53, Dave Dolson wrote:
> [email-masked]

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

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 24 Jun 2017 11:31:57 +1000

The idea behind 511 was that it's an explicit signal that the response is NOT from the origin.

The payload will be displayed by browsers that don't understand its semantics, and you can use JS or http-equiv redirects if you want to send that user somewhere else.

The real value only comes when a) browsers understand its semantics, and b) a payload format is designed to do something interesting with them.

Cheers,

> On 24 Jun 2017, at 4:53 am, Dave Dolson <[email-masked]> wrote:
> 

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

---

From: Dave Dolson <[email-masked]>
Date: Tue, 27 Jun 2017 14:56:27 +0000

Mark, thanks for the info about 511.

But to the working group, I think this discussion about HTTP status codes is a distraction.

I think the ICMP approach is a superior solution that doesn't require modification of transport-layer data.

Redirection of clear-text HTTP is an existing practice. It will continue for some time;
but there is no need to tweak it, since tweaks would not be recognized by existing software anyhow...

Redirection of encrypted HTTP should be discouraged.
The ICMP notification allows HTTPS traffic (and all other IPv4/6 traffic) to be notified of the captive network.

-Dave

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: Friday, June 23, 2017 9:32 PM
To: Dave Dolson
Cc: Julian F. Reschke; Vincent van Dam; David Bird; Erik Kline; [email-masked]
Subject: Re: [Captive-portals] practicality of 511 HTTP status code

Cheers,

---

From: Julian Reschke <[email-masked]>
Date: Tue, 27 Jun 2017 17:55:33 +0200

> Redirection of clear-text HTTP is an existing practice. It will continue for some time;

Yes.

> but there is no need to tweak it, since tweaks would not be recognized by existing software anyhow...

Existing software == browsers? They should be totally OK with 511. Do 
you have evidence to the contrary?

Best regards, Julian

---

From: David Bird <[email-masked]>
Date: Tue, 27 Jun 2017 09:12:20 -0700

On Tue, Jun 27, 2017 at 8:55 AM, Julian Reschke <[email-masked]>
wrote:

> Existing software == browsers? They should be totally OK with 511. Do you
> have evidence to the contrary?
>
> ...
>>
>
>

It would be interesting to have a review of browsers and how they handle
511. Most browsers are probably "OK" with 511, but how about the venue?
That would depend on if the user experience is broken, or not as desirable.
A venue/operator could just use javascript to redirect (if the sandboxed
browser environment allows it) as suggested, but assuming the browser
didn't otherwise 'break' the UX, how is that different from a 30X redirect?
Sure, some headless Apps making API calls might be 'broken' with unexpected
results, but do we care? Those developers should use TLS, not follow
redirects, and write robust software with exception handling..

---

From: Dave Dolson <[email-masked]>
Date: Tue, 27 Jun 2017 16:18:42 +0000

Regardless of how 511 is handled, I think it is orthogonal to the work at hand. It only helps with the clear-text http, which I think operators would be resistant to change.

David Dolson
Sandvine
  Original Message
From: Julian Reschke
Sent: Tuesday, June 27, 2017 11:55 AM
To: Dave Dolson; Mark Nottingham
Cc: [email-masked]
Subject: Re: [Captive-portals] practicality of 511 HTTP status code

Yes.

Best regards, Julian