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

[Lorenzo Colitti <[e-mail]>]

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
>>
>>
>>
>