On Thu, Oct 2, 2014 at 1:29 PM, Joe Clarke <[email protected]> wrote: > On 10/1/14 5:21 PM, Warren Kumari wrote: >> >> <no hats> >> Hi there all, >> >> I have a draft that I'd like some review / feedback on. >> It will likely be AD sponsored (it doesn't really fit in any working >> groups). >> >> It is designed to help make the captive portal experience better^W less >> bad. >> We've all experienced this -- you arrive at a hotel or coffee-shop. >> You open your laptop and connect to the Hilton_Guest network (or >> whatever) and then nothing happens... >> You click refresh on your (in this day and age) https:// pages, and >> either they just hang, or you get some unintelligible SSL error about >> the certificate not matching the site you were trying to get to... or >> you have a VPN / proxy, in which case *nothing* happens. >> You kill the VPN, still nothing. >> You curse a few times, then notice that DNS isn't working. After some >> futzing (and more swearing) you disable your local validating >> resolver, and update resolv.conf to use the hotel network. >> >> Eventually you get a web page that tells you you can get to the >> Internet for the low low price of $9.95 for 24hours. 3 hours later the >> process repeats. After throwing your laptop on the floor and jumping >> up and down you redo the captive portal dance and continue using the >> 'net. >> >> Now, obviously the bestest possible outcome would be if there were no >> captive portals, but, well, that ain't going to happen.... so, this >> document lets DHCP / RA *tell* your machine where the CP is, so your >> OS can make a connection as soon as you try access the Internet. Yup, >> there are many more details, go read the draft... >> >> >> http://tools.ietf.org/html/draft-wkumari-dhc-capport-05 > > > This sounds reasonable in principle, but how do you divorce the DHCP lease > from the interactive desktop experience on certain platforms? For example, > on my FreeBSD laptop, a DHCP lease is obtained asynchronously before I even > login to GDM/X. How does my browser know that the CP has been provided via > DHCP? Will this require some fundamental change up the stack into all > network aware applications?
Yes, kinda. Not really changes up the stack, simply the operating system, using some OS proprietary mechanism the fact that the machine is behind the captive portal. We are explicitly *not* defining how this gets exposed in the draft, it's simply not our place... but... Once you login the OS could automagically start a browser instance (with a separate cookie store, etc) connecting to the URI provided by DHCP (Apple already does something similar to this -- MacOS and iOS try "get" http://www.apple.com/library/test/success.html (e.g: http://blog.erratasec.com/2010/09/apples-secret-wispr-request.html#.VC2U2ildUcs )). Or, when you manually start the browser / network application it could ask the OS (possibly by reading something out of /proc, a sysctl, etc) and discover that it needs to do "stuff". How this gets done internally is entirely up to the OS vendor.... W > > Joe -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
