[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Captive-portals] A new draft / idea - draft-wkumari-capport-icmp-unreach

I like the idea of an FQDN because certs and as well as load balancing. My current portal redirect is delivered by an HTTP 302 redirect from the gateway and then immediately upgrades to HTTPS. The gateway and AAA server act as the controller but they all deliver the same FQDN so I am able and able to terminate the cert at the load balancer.  VIPS could be used as well but FQDNs allow for more flexibility.  

For mobility, I have many Aps next to each other that can receive different treatments like free wifi or paid wifi.  . When a client jumps between SSIDs, it assumes its using the same IP and does not do a DHCP discovery.  There are devices out there in the wild that need to wait until the lease expires to get a new IP even if connectivity is poor.  I think having the ability to notify the user need to be authenticated as its a new network.
-- 
Alexander Roscoe
Comcast - Wireless Engineer
Phone – 215.286.7283
Cell – 215.609.2691

From: David Bird <[email protected]>
Date: Tuesday, October 6, 2015 at 3:09 PM
To: Alex Roscoe <[email protected]>
Cc: Michael Richardson <mcr+[email protected]>, "[email protected]" <[email protected]>
Subject: Re: [Captive-portals] A new draft / idea - draft-wkumari-capport-icmp-unreach

Is the suggestion of having a FQDN in the DHCP parameter for the purpose of "matching" against a HTTPS hostname? I can see the value of that, but that value only comes when you require the well known CP-NAS URL to be https://fqdn/...  The CP-NAS interface _could_ be shared among networks, but more likely it means you need a cert per CP-NAS (which can mean per AP/hotspot). Using a single cert for all NAS would probably violate your cert agreement, and storing a valid cert on the NAS is a security risk itself, in some situations. 

In the mobility case mentioned, if the client moved to a different network segment and DHCP server, wouldn't his lease be invalid? Can you also elaborate on the ICMP reply suggestion?

David

On Tue, Oct 6, 2015 at 11:23 AM, Roscoe, Alexander <[email protected]> wrote:
I am really a big fan of having the ability to pass FQDN as a DHCP option.  I assume all un-authed users will have access to DNS.  There are some edge case scenarios will this will fail, especially in mobility situations where a roams between 2 of the same SSIDs that have a different DHCP server and cache. I think an ICMP reply would offer another mechanism to determine the clients state.

I do not think HTTPS should be a requirement, this should be left to the discretion of the the hotspot provider.  Many hotspots, especially in the U.S. require users at a minimal check a terms of service box to get internet access.  An application like this would not need to be secure as there is no sensitive information being passed.


-- 
Alexander Roscoe
Comcast – Xfinity Wifi - Wireless Engineer 
Phone – 215.286.7283
Cell – 215.609.2691
From: David Bird <[email protected]>
Date: Tuesday, October 6, 2015 at 1:52 PM
To: Michael Richardson <mcr+[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [Captive-portals] A new draft / idea - draft-wkumari-capport-icmp-unreach

On Tue, Oct 6, 2015 at 10:07 AM, Michael Richardson <mcr+[email protected]> wrote:
David Bird <[email protected]> wrote:
    > To clarify, there is a CP access controller (let's call this CP-NAS)
    > and a CP web application (and this CP-WEB). The DHCP option could
    > return the IP address of the CP-NAS (if not the same as the default
    > gateway). We can then define a .well-known URL, such as
    > http://CP-NAS/.well-known/capport-redirect, which the client can use to

so, in this context, "CP-NAS" would be an IP address literal?
(I ask, because there are lots of portal vendors who think that DNS search
strings work, and might use a literal "cp-nas"...)


Yes, IP address literal. 
 
    > learn the (possibly device and session specific) URL to the CP-WEB
    > application. The CP-NAS URL is always HTTP and only does a 302 redirect
    > to the CP-WEB application. This provides a convenient and standard way
    > for the client to pick-up the CP-WEB URL (with all necessary query
    > string parameters added by the CP-NAS) without having to "guess" a URL
    > outside of the walled garden or wait for the user to visit a HTTP
    > site. The CP-WEB URL can, and should, be HTTPS if handling any user
    > data (though, perhaps not a MUST as a Terms of Service only wouldn't
    > necessarily require https).

good.
It does require https, because the browser and end user have to be sure that
they reached the right web site.


Though, having a SSL cert doesn't necessarily mean it's the "right" website. I don't think we have to require HTTPS in all situations, but I could be convinced otherwise.
 
    > * Note: CoovaChilli already has this type of internal URL
    > (http://chilli-ip:uam-port/prelogin).

Is CoovaChilli still alive as a project, btw?  It was unclear to me last time
I looked.


Yes, CoovaChilli is still active... It recently relocated to github and is supported by a (smallish, but active) community of developers, including myself. 
 
    > I'm not sure it belongs in RFC, but ideally, I'd like to see Clients
    > NOT use a limited (sandbox) browser when a CP-WEB is using HTTPS.

The logic is that you don't give strangers your cookies, or your
HTTP Basic Authentication headers.

With HTTP, we have no control over what name maps to what server (because
HTTP is trivially hijackable), so one would send any cookies one might have
for that FQDN.


I don't disagree... My point is simply that a network, Open or otherwise, without CP (or with CP that whitelisted the OS CP detection end-points) render this sandbox browser feature useless. Moreover, why would a Client STOP using the sandbox browser after "authentication" (does the client all the sudden trust this (probably open) public access network more now?). 

David