Hyperbole aside, the techniques in use today can be deployed in any network gear along the path, even theoretically in a core router, and also to present any kind of alert. Yet the internet has not degraded into chaos.
I know that some captive portal enforcement points reside at locations other than WiFi access points. Sometimes the networks aren't even WiFi networks. So failing to provide for those would mean mobile devices would need to continue with proprietary methods and new methods as well. So I think this group could try to solve the general problem, or just address the "WiFi at hotels and airports" problem. The former is what I'd expect from IETF. -Dave Original Message From: 🔓Dan Wing Sent: Monday, June 29, 2015 10:33 PM To: Dave Dolson Cc: Warren Kumari; captive-portals@ietf.org Subject: Re: [Captive-portals] Feedback requested: Charter text. On 26-Jun-2015 11:11 am, Dave Dolson <ddol...@sandvine.com> wrote: > > A couple of discussion points, since you asked: > > 1. > "Captive Portal" is a term that seems to be specifically about getting access > to the network. > Could this technology embrace other forms of alerts, such as > tornado/tsunami/fire/toxic-spill ? > In other words, the ability of the network to interrupt the user with, > "I need your eyes on this information, right now" Only if the device can handle such alerts (opt-in, somehow). I mean, we don't want our own fire alarm system interrupted from its communication because of a tornado 10 miles away, and we don't want our Internet-connected door lock interrupted because of a fire (even a fire within the same building). And we don't want to relive 1987 for our normal web usage, either; https://en.wikipedia.org/wiki/Max_Headroom_broadcast_signal_intrusion. That is, such interruptions need to be authorized and authenticated. tl;dr: No. > 2. > On an unrelated note, should probably allow devices without operators or > screens (IoT devices) to fulfill CP requirements. > Hence, not just about browsers rendering HTML to humans, but any kind of > client. > > > 3. > Although the proposed charter doesn't say it, some discussion seems to > indicate this should be a link-layer > problem. I.e., a matter for DHCP and the first-hop router. I'd like to see > this posed as an internet-layer > problem, hence applicable to all forms of internet access, and made > enforceable by any forwarding device > along the path. As a simple example, a device behind a NAT may need to > receive a captive-portal alert from > an enforcement point on the other side of the NAT. I'm not sure how that would work. Are you mentioning NAT because of address sharing (NAPT) which makes it difficult/impossible to distinguish separate devices on the public side of a NAPT? I would not want any device along the path able to inject itself to become a captive portal; imagine the chaos if a core router did that. -d > > > I don't know if any of my points warrant changes to the proposed charter. But > if the above are to be > specifically excluded, it's probably worth saying so. > > > > -Dave > > > > > > > > -----Original Message----- > From: Captive-portals [mailto:captive-portals-boun...@ietf.org] On Behalf Of > Warren Kumari > Sent: Tuesday, June 23, 2015 2:26 PM > To: captive-portals@ietf.org > Subject: [Captive-portals] Feedback requested: Charter text. > > Hi all, > > We have a BoF scheduled for the IETF in Prague. > > We would like to get a discussion going on some *strawman* charter text. > > > ----- > > Captive Portals are used to restrict access to a network until users > have purchased access, or accepted Acceptable Use Polices (AUP). > They accomplish this by intercepting connections from unauthenticated > clients, redirecting them to an authentication server, and then > granting access (if satisfied). By developing a standard set of > Captive Portal interactions (including simple ways for clients to > discover and interact with CPs), we will significantly improve the CP > user experience, increase security, and simply the CP interceptions. > This will increase the user completion rate, increase the CP > interception reliability, and decrease the implementation complexity > and cost. > > Many of the interception techniques are very similar to > man-in-the-middle attacks, and, as clients become more secure, are > increasingly ineffective, leading to a poor user experience. Many of > the captive portals require a web browser to interact with the > authentication system, and may require that the user disconnects any > VPNs, browses to a non-HTTPs site, or similar. In addition, there is > no standard way to discover the existence of the captive portal, when > the captive portal has been satisfied, and how much time remains > before the captive portal restricts access again. > > The Captive Portal (CAPPORT) Working Group will address these (and > related issues) by defining a standard mechanism for clients to > interact with Captive Portals, including how to connect to the captive > portal and how to communicate with it to obtain status information > such as remaining access time, purchased bandwith class, etc. > > This working group will seek participation and input from browser / > operating system vendors, captive portal developers and operators. > One of the known challenges is that some captive portal operators may > not want to use a standard interaction protocol, preferring to perform > more intrusive interception and interactions. We are hoping that the > benefits to CP standardization outlined here are sufficient to not > only encourage input from CP developers and operators, but also aid in > deployment. > > Milestones: > TDB: Initial problem statement / use case document [0] > TBD: Initial terminology document [1] > TBD: Initial portal interaction document (perhaps based upon > http://coova.org/CoovaChilli/JSON ?) > TBD: Extended portal interaction document (for systems without browsers) > > [ Each of these milestones is actually Initial draft -> WGLC -> IESG, etc ] > > > [0]: Primarily to ensure that we are understand what we are trying to > accomplish / working to the same goal. This may or may not become an > RFC... > [1]: We have already discovered that we have issues here - what's the > webpage after the CP has granted access called? What's the "lease" > time called -- different vendors have different names for things. > Crappy first pass: > http://www.ietf.org/mail-archive/web/captive-portals/current/msg00009.html > > ---- > > > -- > 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 > > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals > > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
