Re: [Captive-portals] Remediation url for CAPPORT

[Dan Wing]

To that point, the remediation URL only works if the client and the CP are in 
sync; that is, if the client wondered off to another network for a while (LTE, 
because of whatever reason) and then re-connected to WiFi, is the remediation 
URL supposed to be visited because the wall-clock time expired, or not visited 
because the time-on-network has not yet expired.  The CP may have abandoned 
that client, figuring it went away permanently when it disconnected from WiFi.

-d


> On Jan 13, 2020, at 5:02 PM, Tommy Pauly  
> wrote:
> 
> I have a similar initial reaction to Erik's. Adding another URL that 
> effectively is just another user portal, but meant to be used at certain 
> times, adds a lot of complexity. I'm certainly not ruling out adding such a 
> key as need arises, but I'd hesitate to make it part of the initial set.
> 
> Particularly, if we start seeing the "venue URL" be the main landing page we 
> redirect people to once they're logged it, it kind of makes sense to let the 
> user portal be the status/remediation/payment page.
> 
> Tommy
> 
>> On Jan 13, 2020, at 4:06 PM, Erik Kline > > wrote:
>> 
>> 
>> 
>> On Mon, 13 Jan 2020 at 15:26, Heng Liu 
>> mailto:40google@dmarc.ietf.org>> 
>> wrote:
>> On Sun, Jan 12, 2020 at 2:34 PM Erik Kline > > wrote:
>> Why should this different from the user-portal-url?  It seems to me that 
>> either the user-portal-url would remediation UI elements or it wouldn't.
>> Some CP vendors want to specify a different URL specifically tailored for 
>> remediation of a session. By providing a 3rd URL, we can accommodate this 
>> use case.
>> 
>> If the remediation URL is available but the user (somehow) navigates to the 
>> user-portal-url, what do they see?
>> 
>>  
>> With this 3rd URL, if the bytes/time does expire should the OS try to launch 
>> an interaction the remediation URL and then fallback to the user URL if it 
>> failed to load?  In which case, why not just leave all interaction with the 
>> user-portal-url?
>> if a remediation URL is present, and if it fails to load for whatever 
>> reason, no need to fallback to user portal URL: CP vendor should make sure 
>> the remediation URL is working properly (this is similar to user-portal url 
>> should work properly, if not, there is no other way for user to clear a CP)
>> 
>> I guess I'm just trying to be mindful of one person's flexibility is another 
>> person's complexity.  I think this just doubles the number of URLs that the 
>> CP vendor needs to make sure function correctly.
>> 
>> If the vendor doesn't implement a means to extend your session without 
>> completely shutting everything down and forcing to the user to restart the 
>> interaction flow anew, I could see that an OS would not want to bother the 
>> user with an interaction where they couldn't actually do anything useful.  
>> But that might suggest a boolean capability, rather than a new URL 
>> (remediation-supported={true|false})?
>> A boolean field could also be a positive signal to notify UE that 
>> remediation is possible, but this would prevent CP vendors from using 
>> different URLs for remediation.
>> 
>> (As mentioned in the initial thread, this URL approach is also taken by the 
>> Passpoint release 2.0 spec to signal remediation process.)
>> 
>> regards,
>> Heng
>> ___
>> 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

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Any other existing detection methods?

[Dan Wing]

Text in the PR is unclear if it intends to be normative ("This check should not 
be secured with TLS") or is discussing why TLS isn't used.  In my view, the 
hostname mismatch is a strong indicator the captive portal is intercepting the 
connection; in fact, that's exactly what my mail user agent complains about 
when my OS fails to detect the captive portal.  This failure occurs because 
captive portals purposefully return the "expected text", in order to fool the 
OS into displaying a WiFi "connected" indicator (the "pie") in the hopes the 
user will launch a non-restricted browser and view an un-encrypted HTTP page.  
Which is a faint hope in 2019 with nearly every page being HTTPS and with 
non-browser applications that may launch first (e.g., mail user agent, 
Facebook, Instagram, WhatsApp, etc.).

-d



> On Apr 1, 2019, at 8:52 AM, Thomas Peterson  wrote:
> 
> A recent pull request[0] for the architecture document contains a new 
> appendix describing known methods devices may use to detect a captive portal. 
> Two of the ways I have found are DNS and HTTP based.
> 
> Are the any other means that clients use to detect captive portal presence 
> besides what I have described? Wikipedia lists ICMP redirect[1] as a means, 
> but I have been unable to find documentation from a vendor to support this.
> 
> 
> Regards
> 
> 
> 0: https://github.com/capport-wg/architecture/pull/26
> 
> 1: https://en.wikipedia.org/wiki/Captive_portal#ICMP_redirect
> 
> ___
> 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