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

[Martin Thomson <[e-mail]>]

What is interesting about Heiko's example here is that this transition
is not necessarily visible to endpoints. Nor can they be forewarned
(assuming they are ignorant of the botnet using their link).
Endpoints were previously on a network without a captive portal, but
one is suddenly interjected.

I see several problems, different for each of the various solutions:

* With 7710 or PvD, the original network would have to be provisioned
with a captive portal, or the switch would happen and the endpoint
won't have a URI to talk to.  That seems relatively tractable,
providing that this didn't lead to a false assumption of captivity
(this is a problem with 7710, I think, because the existence of the
option seems to imply captivity, though this is quite unclear from the
RFC).

* With ICMP, the signal comes from more than one hop away.  An
unmodified router in the home would receive the ICMP message, reduce
the TTL and then it looks like a random Internet host was trying to
deny service.

So running through all the combinations:

7710/PvD + ICMP - you know where to go to get status information and
the network can signal

7710/PvD - ICMP - you know where to go to get status information, but
how would you decide to ask?  Is there some other trigger you would
use?  (This is, I think Vincent's question.)

ICMP - 7710/PvD - you get a signal, but is it legit?  How do you validate it?

Neither - that's the situation we have today.

It seems that there are at least a few people who think that this use
case is in scope.  It doesn't seem materially different from the case
where you run out of bytes (for networks that do accounting that way).
Maybe this use case can inform the design a little better.  Or maybe
someone would like to argue that we don't need to worry about this.



On 25 August 2017 at 06:58, Vincent van Dam <[e-mail]> wrote:
> 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 [[e-mail]] namens Tommy Pauly
> [[e-mail]]
> Verzonden: donderdag 24 augustus 2017 18:03
> Aan: Lorenzo Colitti
> CC: Erik Kline; Eric Vyncke (evyncke); Martin Thomson;
> [e-mail]; 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 <[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
>>>
>>>
>>
>
>