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

[David Bird <[e-mail]>]

Indeed, one could just as easily misconfigure the "Captive Portal URL: "
field in the NAS. A key difference is that this configuration is enforced
the same way (with slight variation for capport) for all devices... It is
not just a misconfiguration only visible to "First Vendor to Release PvD
Client" products.

I'm trying to figure out the value the attacker is gaining (e.g. the
motivation) for putting others off the network using Capport ICMP. If they
are off-network, chances are their attacks will not work because of
firewalls. If they are on-network, particularly if this is Open SSID public
access network, I'd say they are wasting their time... Sending 802.11
Disassoc would be easier.

On Thu, 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
>>>
>>>
>>>
>>
>