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
