Re: [Captive-portals] CAPPORT ICMP

+captive-portals

On Sat, Apr 1, 2017 at 1:22 PM, Martin Thomson <[email protected]> wrote:

(Adding ek; though I'm thinking that we should just take this discussion to the list.)

Those places that use a public address space for their closed network (or the part that houses the enforcement device) would suffer in that case.

That wouldn't matter much -- unless there is some sort of source routing in play...

Maybe we should step back and examine the security goal. We want to reduce the chance that a spurious signal is accepted by a client. In this case, a signal is spurious if it comes from off path, if it is sent from a network that is too remote (a definition that probably needs some refinement), or if data flows despite the signal.

I'd argue that are goals are not particularly 'security' focused.. Though, agreed it is a concern. We certainly shouldn't worsen the security.

I'm starting to think that an explicit probe is what we want here, just as David (Bird) said. That is, a message that is guaranteed* to elicit a response from a portal. Let's say that an endpoint receives an ICMP unreachable with the captive portal decoration. At that point, it kicks the detection engine. That generates a series of ICMP messages** with low TTLs and high entropy payloads (this could be a traceroute in effect) and the same capport extension. If the captive portal is valid, it will return the packet and include the capport extension.

Agreed, good point.

It shouldn't take very long to detect a legitimate block this way. So during the check, the endpoint does not disable the affected interface. If it continues to receive data on the flow that triggered this, it should consider the original ICMP unreachable as spurious and cancel the probe. Ideally this is all in the kernel, but an application could implement this logic itself.

(BTW, I think that the entire payload in draft-kumari is unwise. It would be better if we rely on something like draft-donnelly and ask for expiration times. I'll follow up on the list.)

My concern (fundamentally) about asking the API anything is that it could be wrong (and, I'd argue, it WILL be wrong so often that UEs will just start ignoring it). I think the API should only, more or less, confirm information and provide a means for "auto-login" (pinning saved credentials in the WiFi profile to an API URI and server x509 certificate).

The NAS, imho, MUST be the source of truth. Yes, the API can be in the NAS, but if you secure it with https (and want a real cert) that is expensive. Moreover, many operator would want that API more centralized. As they do that, things will start falling apart...

Some examples:

- What if a network (configured by mistake, configured poorly, or otherwise) configures RFC 7710 in their DHCP server and creates the CAPPORT API, and that is it! Now, imagine the customer complaints about the CAPPORT detection features in handsets when they figure out only THEY get the portal when legacy devices do NOT.

- It is not unusual for a Hotspot to have MULTIPLE authentication sources: MAC Authentication, different RADIUS servers used by realm, etc. Having an API that is the source of truth would require networks redesign -- broken networks galore.

- It is also not unusual for captive portals to be outsources to companies that DO NOT own, operator, install, or otherwise administer the Wi-Fi infrastructure. Sure, they need to coordinate configurations, to some degree, for things like Walled garden to work, but once that is done once, the configuration is fragile (unless the operator does out-of-band synchronization of configurations to APs). -- again, broken networks galore.

- You are pretty much guaranteed (minus the risk for forgery) that the one sending the ICMP is the NAS!

* by our specification at least, we have to allow for packet loss, of course.
** straw man example only

On 1 April 2017 at 12:59, David Bird <[email protected]> wrote:
We could restrict the sending address space to something in rfc1918...

On Sat, Apr 1, 2017 at 10:38 AM, Dave Dolson <[email protected]> wrote:

I don't think we should assume the enforcement point is always on the local link.

David Dolson
Sandvine

From: David Bird

Sent: Saturday, April 1, 2017 12:14 PM

To: Dave Dolson

Cc: Martin Thomson; Kyle Larose

Subject: Re: CAPPORT ICMP

Also, as suggested by Erik Kline, we can make further limitations on who can send these messages - link local / unroutable addresses, etc.

On Apr 1, 2017 8:46 AM, "David Bird" <[email protected]> wrote:

In https://github.com/wlanmac/draft-wkumari-capport-icmp-unreach I was thinking that a Session ID could be used to group ICMP messages into, more or less, a single event. Only when the Session ID changes (and also based on input from the Validity and Delay times) would the UE revisit the API. And, a UE would not expect the Session ID to constantly be changing (I think then it can assume it is under attack from a malicious user or just a really unfriendly network provider).

On Fri, Mar 31, 2017 at 7:02 AM, Dave Dolson <[email protected]> wrote:

I think we can mitigate concerns about the ICMP by rate-limiting visits to the capport API, which is not something that can be done with current redirect approaches.

From: David Bird

Sent: Friday, March 31, 2017 8:09 AM

To: Martin Thomson

Cc: Dave Dolson; Kyle Larose

Subject: Re: CAPPORT ICMP

With RFC 4884, which we could require, the UE still has to remember
every packet it sends. I think that is the larger burden. One
potential way to fix that would be to treat an ICMP unreachable as
provisional and then run an explicit test.

It wasn't the intention that UEs would have to remember what it sends. Should the ICMP be supported in the kernel, the capport "enriched" Dest Unreach bubbles up to the application. Without kernel support, something similar can be done where the application can ask another service "was my Dest Unreach with this tuple blocked by capport?" In that scenario, the "another service" just needs to intercept ICMP and hold the tuple for a little while in case an application queries about it.

And, yes, the capport detection engine in the OS should be kicked whenever a capport ICMP is received. It is also not the intention that a UE will do something for EVERY ICMP, rather taken as input/signal to the capport detection.