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

[David Bird <[e-mail]>]

There are no unsolicited pushes of ICMP by the network; they all have a
flow context and in response to traffic (in the latest draft). There isn't
any need for an idle device to require notification (and should be left to
go idle... stop session, lose lease, etc). The ICMP proposal does
allow for "when
to re-join the portal" warning notifications... and, when time does expire,
the notification is immediate (assuming there is traffic).

I'm not convinced this really improves the 'trust model' as the weakest
link, as discussed, was in discovery. Having a source to query about
information is a good idea, and some networks even already do such things
[1]...

However, the assumptions behind a PvD web service 'working' are huge.. It
will *require* RADIUS Accounting integration such that this API knows when
sessions start/stop. It will *require* knowing RADIUS Authorization logic
to know, before hand, when the RADIUS server might be sending a CoA to stop
the session (to provide the warnings) -- it would also need to be
integrated with provisioning logic (be it in RADIUS, or a portal, or both)
for situations where a CoA is sent for reasons other than Stop (to change
walled garden, session parameters, etc).

Should "First Vendor to Release PvD Client" products start getting
complaints about their devices having problems at Hotspots, unseen by other
devices, what will they do?

I was only proposing the client heuristics as something the client _could_
do, should that _threat_ actually materialize... (which I doubt)

[1]
https://sourceforge.net/p/hotcakes/wiki/Coova%20Chilli%20JSON%20Interface/

On Thu, Aug 24, 2017 at 9:03 AM, Tommy Pauly <[e-mail]> wrote:

> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>>>> wrote:
>>>>
>>>>> On Thu, Aug 24, 2017 at 10:40 PM, David Bird <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/captive-portals
>>>
>>>
>>>
>>
>
>