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

[David Bird <[e-mail]>]

Sorry, NOC == Network Operations Center (Data Center).

My concern isn't that an API *can* make claims about your captive state, it
is more:
- The implementation of the API/PvD web services will be highly varied --
in compliance to the RFC, integration with the infrastructure (RADIUS,
portal, etc), and easy to misconfigure.
- It separates enforcement for Capport devices from enforcement of
non-Capport devices, which has consequences... (*)
- It may very well make "Hotspots" more complicated, error prone, and
"broken"

(*) This question isn't rhetorical :-)  ... What will "First vendor with
PvD client" do when a new phone, and only that new phone, has problems at
(just for arguments sake) Chicago O'Hare?

- Complain to venue? (even though their friend isn't having problems)
- Tell the user to turn off PvD?
- Tell the user to use their old phone?
- UE vendor will start contacting venues?
- Start doing legacy probes on top of PvD?

My concern is that after all this work... UEs will still be doing legacy
probing...

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

> Hmm, maybe we understand this very differently then.  I see PvD as
> providing configuration in exactly the same way as 7710 does.
>
> That is,
>
> * 7710 says "here is the URL you go to for ???"  where "???" is one or
> both of "web browsing" and "API" (see the API doc).  It doesn't really
> say whether the endpoint is currently captive or not (and nor can it
> do so).
>
> * PvD, as I understand it, would say the same, though it might provide
> separate "web browsing" and "API" URLs, if we accept that an API is
> valuable (see below).  It *could* also act in the "API" role, and I
> think that Tommy in particular finds that idea appealing, but my
> understanding was that we would consider that to be a logically
> distinct function.
>
> If, as we seem to have agreed in Prague, consider API to be basically
> reduced to "am I captive? y/n" and maybe "for how long? <time>" for
> now.
>
> You seem to be most concerned about the potential for an API that
> could make claims about whether a given host is captive or not.  Is
> that the source of your concerns here?
>
> If we agree - as seem to, based on your comments here - that the
> configuration of a URL has no effect until the host discovers that it
> is captive (somehow), is this a concern more about the API than the
> existence of a mechanism like PvD?
>
> (NOC == NIC?)
>
> On 25 August 2017 at 11:49, David Bird <[e-mail]> wrote:
> > 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
> >> >>>
> >> >>>
> >> >>
> >> >
> >> >
> >
> >
>