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.
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?
On Tue, Oct 6, 2015 at 11:23 AM, Roscoe, Alexander <[email protected]> wrote: