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

[David Bird <[e-mail]>]

I don't see RFC7710 grouped with PvD and vs ICMP. In fact, RFC7710 is
required in the ICMP draft.

So, it should be 7710 & ICMP vs PvD. Nobody is arguing 7710 should stand
alone, or is useful by itself.

There are unique considerations when the captive portal "client" is a
router and not the UE... In this example, no clients get 'released' from
captivity - so, it doesn't really have to trace clients by IP address. The
CPE firmware needs updating to have RFC7710 configurable via their
management system -- this might be a good opportunity to have a minimal
Capport ICMP based captive portal implemented completely in CPE firmware,
perhaps Linux iptables w/Capport ICMP support. Assuming they don't do that
(but do get RFC 7710 supported), the CPE can be configuring clients for
Capport and ICMP coming multiple hops away.. validated by (yet to be
defined) material in the original DHCP/RA, is just fine... (better, maybe
the CPE reconfigures into a bridge and has a L2 capport in the NOC, which
can maybe help users identity exactly which machine has the virus....)

There is no harm, btw, in having RFC7710 *always* configured in networks
that support features like this... it could be a multi-purpose portal. RFC
7710 should always be ignored until (yet to be defined) notification is
received.






On Thu, Aug 24, 2017 at 4:55 PM, Martin Thomson <[e-mail]>
wrote:

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