Subject: Fwd: I-D Action:draft-nottingham-http-portal-00.txt

From: Mark Nottingham <[email-masked]>
Date: Thu, 5 Aug 2010 16:11:38 +1000

[ reply-to http list ]

FYI. There was an old discussion about this on the HTTP list, starting at <http://www.w3.org/mid/[email-masked]>, and I think it's time to do something about it.
  
Feedback appreciated. My intent is to engage with folks who are using captive portals (have already made some small headway there) and register a new status code if a) feedback here and there is good and b) they indicate willingness to implement.

Cheers,

Begin forwarded message:

> From: [email-masked]
> Date: 5 August 2010 4:00:02 PM AEST
> To: [email-masked]
> Subject: I-D Action:draft-nottingham-http-portal-00.txt 
> Reply-To: [email-masked]
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Considerations for Captive Portals in HTTP
> 	Author(s)       : M. Nottingham
> 	Filename        : draft-nottingham-http-portal-00.txt
> 	Pages           : 6
> 	Date            : 2010-08-04
> 
> "Captive portals" are a commonly-deployed means of obtaining access
> credentials and/or payment for a network.  This memo discusses issues
> of their use for HTTP applications, and proposes one possible
> mitigation strategy.
> 
> This memo should be discussed on the [email-masked] mailing
> list, although it is not a work item of the HTTPbis WG.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nottingham-http-portal-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 5 Aug 2010 10:06:29 +0200

Interesting. "Network Auth Required" makes a lot of sense. It might also make sense to define a code for "Network Access Denied", when a network provider does not allow traffic to certain subnets/hosts. This is common in enterprise access to the outside world and some countries are known to implement such measures as well. A 403 is not really the same.

I would not put this in the scope of the draft, but:

As for non-HTTP connections (POP/IMAP etc.): an alternative to hacking OS network stacks might be to define a fixed URL where network restrictions can be retrieved. For example:

http://example.org/network

which serves a document listing restrictions (preferably human and machine readable). Owners of captive portals could redirect such requests and provide their own answer, listing the restrictions currently in place. It is then trivial to develop applications that check that url when the OS connects to a network. (The question is who wants to operate the real server which gets bombarded with requests from unrestricted networks? Anyone from akamai raises a hand?)

Just a thought.

Cheers, Stefan

Am 05.08.2010 um 08:11 schrieb Mark Nottingham:

> <Mail Attachment>

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

---

From: Dan Winship <[email-masked]>
Date: Wed, 18 Aug 2010 10:15:49 -0400

On 08/05/2010 02:11 AM, Mark Nottingham wrote:
> Feedback appreciated. My intent is to engage with folks who are
> using captive portals (have already made some small headway
> there) and register a new status code if a) feedback here and
> there is good and b) they indicate willingness to implement.

It really seems like this ought to be handled by a DHCP option saying
"the IP address I just assigned you won't be usable until you visit the
following URL". (Since, AFAIK normally the DHCP server is part of the
portal as well.)

from the draft:
>    Overall, there may also be an interesting discussion to be had about
>    improving network access methods to the point where a user interface
>    can be presented for the same purposes, without resorting to
>    intercepting HTTP traffic.  However, since such a mechanism would by
>    necessity require modifying the network stack and operating system of
>    the client, this memo takes a more modest approach.

It's true that on desktop platforms the browsers are faster-moving than
the core OS, but I don't think that's true for mobile devices.

And if we're getting the portal makers to make changes now anyway, it
might be more productive to get them to make two changes (an HTTP-only
fix and a whole-network-stack fix) at once. It might take a while before
Windows, eg, got updated to support the whole-network-stack fix, but
when they did, the portals would already be ready for them.

-- Dan

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 19 Aug 2010 15:23:36 +1000

> following URL". (Since, AFAIK normally the DHCP server is part of the

Agreed, but see below.

> when they did, the portals would already be ready for them.

It's not the browser that you have to worry about, it's all of the various feed readers, software that uses HTTP for updates, etc. 

For that matter, it's really all applications that use the network; you'd need some sort of strategy for telling them that the network isn't available due to authentication reasons (unless you just make it appear that the network is down, except for browsers going to the login portal).

As you can probably tell, I'm not at all against creating such a DHCP option, but I also think it's a longer-term and more difficult thing to get right. If you (or anyone else) wants to come up with a draft exploring the options there, please do so!

Cheers,