Add support for RFC-7710bis - captive portal detection through DHCP

[garci66]

Is your feature request related to a problem? Please describe.
Trying to find a way to improve captive portal detection, as it seems to be hit-or-miss. As of two days ago, Apple has announced support (https://developer.apple.com/news/?id=q78sq5rv) for https://tools.ietf.org/html/draft-ietf-capport-rfc7710bis-08.

This allows networks to advertise the URL for the captive portal using DHCP options, which would make detecting a captive portal almost infallible (on supported devices, of course).

Describe the solution you'd like
Basically, we would have to add support for DHCP option 114 (for DHCPv4) and, if IPv6 support is eventually added, the corresponding DHCP and RA (Router Advertisment) options.

Looking at the code, it seems as it should be relatively simple to add:

*) We would need to add the option to the dhcp dictionary:
/go/dhcp/dictionary.go

var Tlv = TlvList{
	Tlvlist: map[int]TlvType{
<snip>
114: TlvType{"OptionCaptivePortal", tlvNstring},

and then I believe the following code for the dhcp config itself ( /go/dhcp/config.go ) should be (almost) enough:

options[dhcp.OptionCaptivePortal] = []byte(ConfNet.PortalFQDN)

We might want to add this only to the registration network (not 100% sure) or maybe registration and isolation. For "user" networks, if PF is in in-line mode it probably shouldn't be added.

Also, not 100% sure fi the PortalFQDN would be enough and a connection to the naked domain would be caught by haproxy or do we need more details for the specific portal to redirect to. If we need the exact URL, it might need slightly more work as the Portal URL would need to be exposed to the /go/pfconfigdriver/structs.go

Describe alternatives you've considered
This would be an enhancement to the current, dns based captive portal detection mechanism

Additional context
RFC-7710 (the original one) is from a few years back, but it seems it was never widely adopted by OS vendors. The main difference with the current version is that the DHCP option used to convey this URL has been changed in the new proposal as option 160 (the original) was de-facto used by polycom for provisioning and thus could create problems. The new option, 114, was assigned by IANA to Apple but was never used and is being given back to IANA for assignment for RFC 7710bis

With apple pushing this, hopefully other OS vendors get onboard and thus, finally, simplify the captive portal detection mess that today's DNS logic is.

[garci66]

Additionally, supporting the captive portal API endpoint specified in the related RFC https://tools.ietf.org/html/draft-ietf-capport-api-08 could be supported. Or, at a minimum, with a static content in the "registration" network with the "user-portal-url" pointing to the login url for the portal. This content should be served using application/captive+json as the content-type but it seems that if just issuing a standard 302 redirect as text/html could be enough to trigger the captive portal.

In the worse case, a "static" /api file hosted or generate by haproxy is probably enough to trigger the redirection to the correct portal.

It should be noted that all of these protocols expect the api and the portal to be enabled over https (with valid certs).. that's something to keep in mind.

[nqb]

Hello,

Thanks for this detailed request.

We received same request on #5627 but with more details. I closed it in favor of this one.

[fdurand]

I have no device that support that yet but i did the code here: https://github.com/inverse-inc/packetfence/compare/feature/rfc-7710

[garci66]

Awesom! Thanks a million!!! I will try to get hold of a device (worse case, virtual) and test. It might not be the same, but should be a good start! (I hadn't noticed the other request, but glad you worked on this so quickly!)

That was very fast!!!

By the way, is the go dhcp server always sending the configured options regardless of whether the dhcp client request them or not?

[fdurand]

Yes i set it as a default option , only if the secure redirect option is enable and the certificate on the portal is valid.
Also i enable it for any networks (registration/Isolation/Inline) and for the inline case, if the device try to go on /api then the captive value will depend of the status of the device.

[garci66]

awesome!!! you guys went "above an beyond".

…

On Thu, Jun 25, 2020 at 6:28 PM Durand ***@***.***> wrote: Yes i set it as a default option , only if the secure redirect option is enable and the certificate on the portal is valid. Also i enable it for any networks (registration/Isolation/Inline) and for the inline case, if the device try to go on /api then the captive value will depend of the status of the device. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#5638 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQV3WCUW7YQ576UU3AIYSTRYO6PJANCNFSM4OHBKDMQ> .

[danpoltawski]

I think this was merged as part of v10.2.0? Surprised that this wasn't mentioned in the release notes, I believe this will be a huge improvements for captive portal users!

[nqb]

You're right @danpoltawski: related PR has been merged for 10.2.0.

[garci66]

Just wanted to let you know that I got the feature working on a google pixel 3a device as well as an iphone 8 with the latest patches. On both devices I see the dhcp request asking for option 114 and the dhcp server offering it. On the pixel 3a I see the client doing an http get for the /rfc7710 url while the apple device does not. (It still opens the captive portal login page immediately so I guess its not an issue).

One small comment is that I DID have to restart the pfdhcp server after building the portal / adding the certs / etc which might be a minor note to add to the documentation. Before the restart, the pfdhcp server was not sending option 114 as I guess it was started before the portal had a valid cert, etc.

Thanks a million!