Regarding the sacrificial q‎ueries, I would hope these are considered temporary measures to detect existing portals, not the preferred approach.
David Dolson Sandvine From: Erik Kline Sent: Sunday, April 23, 2017 10:41 AM To: David Bird; Kyle Larose Cc: captive-portals@ietf.org Subject: [Captive-portals] thoughts on two documents All, I have the vague feeling that there might be some general agreement around the idea of having an ICMP unreachable code for captive portals (like an HTTP 511 code [https://tools.ietf.org/html/rfc6585#section-6] for ICMP :-), and it seems like there's no objection from captive portal implementers with respect to the basic functional elements captured in draft-larose-capport-architecture. Where I think some rough spots might lie for both of these is in their integration with as-yet-undecided new behaviour. To that point, I would like to take my co-chair hat off and ask the authors and the group for opinions of the following. [ draft-wkumari-capport-icmp-unreach ] There was some unresolved discussion about the contents of any included extension. I wonder if the extra payload parts might be removed (Dave Dolson's comment, I think?) and thereby simplify this version of the document. Given that Destination Unreachable is a TCP soft error (vis. RFC 5461) I'm not sure how much the proposed extra validation semantics are really adding. If the document simply said that receiving and authenticating an ICMP message with the capport code generically "MAY/SHOULD trigger the receiving node's captive portal handling subsystem", would that be something that folks might agree on? We'll need to run this whole thing by intarea and 6man as well, of course. And nothing stops us from proposing a mulit-part extension to be optionally included in a future document, once the captive portal interaction recommendations are more fully understood. [ draft-larose-capport-architecture ] I felt it was promising to hear some agreement about the functional elements of a captive portal system as documented. Given that the captive portal interaction process is still on-going work, would the document authors think it worth trying to advance the document with either (a) section 3 removed or (b) section 3 rewritten to describe broadly how most clients behave today? Even given the variety of clients I think it could be roughly captured (e.g. make a few sacrificial queries to trigger DNS/HTTP rewrites, keep trying until a sacrificial query produces an expected result while launching an HTTP-capable application, and so on). -Erik
_______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
