On Thu, Oct 2, 2014 at 4:13 PM, Joe Clarke <[email protected]> wrote: > On 10/2/14 2:15 PM, Warren Kumari wrote: >>>> >>>> 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 >> )). > > > Yeah, this would definitely put "burden" on the OS people. In the case of > FreeBSD, that would mean the ports developers as well so that DEs like > GNOME, KDE, and Xfce do the right thing. For those twm (or VTY) die-hards, > this would be left up to scripting and other hacks. I imagine stacks like > ISC's would need to be taught to write out CP info on a per-OS basis. > >> >> 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.... > > > Right, but in my case Firefox is an application completely independent from > FreeBSD. _It_ would need some knowledge of how FreeBSD exposes the CP info > obtained via DHCP. So from an application standpoint (layer 8, 9, ...) > there would need to be some per-OS knowledge. > > From a security standpoint, I like the idea.
Thank you! > And I get how implementation > is out of scope, though I know you're considering it. This was just my > thoughts coming from an "alternative" OS that might add some roadblocks in > terms of adoption, and require a longer life to things like TCP > interception. > Yah. Realistically the DNS / TCP interception stuff will be around for many years (10+ as a wild guestimate) -- however, if you are using a device that understands this, you can start getting benefits sooner... 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
