Re: [Captive-portals] Questions about PvD/API

I agree that the information you describe should be pulled from somewhere, however, I am more concerned _when_ they should be pulled.

In this working group we acknowledged (welcomed) use cases that go beyond connecting to a network; the latest example: https://www.ietf.org/mail-archive/web/captive-portals/current/msg00455.html

If these use cases are indeed in scope; signalling, or a solution that allows detection that the walled garden is (re)activated after joining the network, need to be in place. The alternative to a signal would be polling, or doing some mitm on protocols that allow it. I think both mitm, and polling regularly to see if the connection state is walled are bad.

Just focussing on signalling (without the semantics/api); I think that leaves us with three directions:

* descope any solution that would improve the scenario where walled gardens are (re-)activated

* accept icmp is a valid direction, and think of a way on how we can use this securely in our use-case

* invent a new signal? something the nas is allowed to send to the ue, but not icmp?

Gr., Vincent

________________________________
Van: Captive-portals [captive-portals-bounces@ietf.org] namens Tommy Pauly [tpauly@apple.com]
Verzonden: donderdag 24 augustus 2017 18:03
Aan: Lorenzo Colitti
CC: Erik Kline; Eric Vyncke (evyncke); Martin Thomson; captive-portals@ietf.org; David Bird
Onderwerp: Re: [Captive-portals] Questions about PvD/API

If the client OS needs to add in heuristics to reach a certain volume of ICMP messages before trusting them, I think the design is flawed. Beyond that, the information we'd like to get isn't just as simple as a boolean value that can be aggregated (like unreachable would be). Among the problems we're trying to solve for CAPPORT is "how much time do I have left", and "when to re-join the portal". Having a source we can query about those properties seems to dramatically simplify the flow and trust model. However we do things, it seems like this information should be pull-able (even if it allows the client to open a connection on which changes are pushed or notified) rather than unsolicited pushes of ICMP by the network.

On Aug 24, 2017, at 8:33 AM, Lorenzo Colitti <lorenzo@google.com<mailto:lorenzo@google.com>> wrote:

It seems to me that any solution involving coordination between two protocols is little different, in terms of your criticism that it will lead to "a higher rate of misconfiguration", from the PVD solution. (Personally I don't think that's a valid argument - saying that if you misconfigure the network it won't work well is pretty much a tautology - but you were the one that cited that argument in support of the ICMP solution.)

As for several flows, I don't see what would stop an attacker from trying to spoof several flows.

On Fri, Aug 25, 2017 at 12:21 AM, David Bird <dbird@google.com<mailto:dbird@google.com>> wrote:
You are both describing decisions the UE makes... perhaps the UE waits for several flows (with same session-id) to indicate capport warning/errors before acting on it... especially when already connected. There were also proposals to link the ICMP messages to the DHCP message somehow so that ICMP is 'authenticated' against the original DHCP. Theses are solvable concerns, not road blocks.

On Thu, Aug 24, 2017 at 8:14 AM, Tommy Pauly <tpauly@apple.com<mailto:tpauly@apple.com>> wrote:
Right, I think the difference between an unreachable destination, and a captive portal or walled garden, is that we expect the captive portal style interaction to be an Operating System-level action, and one that will have consequences on everything the device does while associated to a given network. You can certain use spoofed ICMP to disrupt connections, but (a) the user would notice and (b) you're not causing the Operating System to change behavior. When the OS thinks it is on a captive network or not, it will change what network it considers primary/usable, which may potentially be invisible to the user other than an icon change. I would be able to go onto a captive network, start sending out ICMP messages, and potentially bump other people's connection off the network.

Having the UE fetch some resource in order to determine captive state, especially if that resource can be somehow signed, makes it much harder for an attacker to cause the OS to take silent behavior.

Tommy

On Aug 24, 2017, at 7:40 AM, Lorenzo Colitti <lorenzo@google.com<mailto:lorenzo@google.com>> wrote:

A forged destination unreachable can't cause someone else's device to think that wifi is a portal and switch to possibly expensive cellular data.

On Thu, Aug 24, 2017 at 11:29 PM, David Bird <dbird@google.com<mailto:dbird@google.com>> wrote:
Just like the rampant problem we see in ICMP Dest-Unreachable forgery attacks?

On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo Colitti <lorenzo@google.com<mailto:lorenzo@google.com>> wrote:
On Thu, Aug 24, 2017 at 10:40 PM, David Bird <dbird@google.com<mailto:dbird@google.com>> wrote:
Can you give an example of how ICMP could be misconfigured?

It doesn't matter how hard it is to misconfigure, because it is trivial to forge.

_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org<mailto:Captive-portals@ietf.org>
https://www.ietf.org/mailman/listinfo/captive-portals