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

[David Bird <[e-mail]>]

I will add Vincent's (valid) concern about API/PvD: It requires either
polling or push (over TCP, which does require keepalive for NAT traversal),
which means stations likely do not go idle on the network, and, in cases
where a captive portal is possible, but not probable, UEs still have to
maintain this API/PvD association if they want to ever get notified.

On Thu, Aug 31, 2017 at 5:54 AM, David Bird <[e-mail]> wrote:

> Sending to list...
> ---------- Forwarded message ----------
> From: "Martin Thomson" <[e-mail]>
> Date: Aug 30, 2017 3:52 PM
> Subject: Re: [Captive-portals] Questions about PvD/API
> To: "David Bird" <[e-mail]>
> Cc:
>
> sending that to the list would be helpful
>
> On 30 August 2017 at 23:11, David Bird <[e-mail]> wrote:
> > Part of the reason for confusion is that the "API" and "PvD" have a high
> > potential to overlap, and I generally feel that they will be merged
> somehow.
> > I got the impression from PvD authors in Prague that PvD could certainly
> > swallow the feature set of the API. So, without knowing exactly how the
> API
> > vs PvD will shake out, I generally lump them together.
> >
> > Re-looking at the drafts...
> >
> > PvD:
> > - The core material of interest to Capport is now largely in Appendix B.
> The
> > main part actually seems find... though, not very useful. If someone
> > *already* selected a WiFi network, do they really care about the name of
> the
> > network or the bandwidth? That data seems more important to know before
> > association (during network selection), not after. Anyways,
> > - Appendix B is where it gets more interesting -- and where I'm sure the
> > authors plan to baby-step in more features. This is where it starts
> > overstepping into 'enforcement' (and, frankly, should be triggering all
> the
> > same concern you have with ICMP; why doesn't it?):
> >
> >    [
> >      {
> >        "domains": ["example.com"]
> >      },
> >      {
> >        "prefixes4": ["78.40.123.182/32","78.40.123.183/32"]
> >      },
> >      {
> >        "beginDate": "2016-07-16T00:00:00Z",
> >        "endDate": "2016-07-17T23:59:59Z",
> >      },
> >      {
> >        "beginDate": "2016-06-20T00:00:00Z",
> >        "endDate": "2016-07-19T23:59:59Z",
> >        "trafficRemaining": 12000000
> >      },
> >      {
> >        "throughputMax": 100000
> >      }
> >    ]
> >
> >    If the host tries to download data from example.com, the conditions
> >    of the first elementary billing are fulfilled, so the host takes this
> >    elementary billing, finds no cost indication in it and so deduces
> >    that it is totally free.  If the host tries to exchange data with
> >    foobar.com and the date is 2016-07-14T19:00:00Z, the conditions of
> >    the first, second and third elementary billing are not fulfilled.
> >
> > API:
> > - Hm.. that doc seems stripped down a bit too. It has a network object
> which
> > has a 'state', 'conditions', etc, and a value for 'bytes_remaining' ..
> > (already overlaps?)
> >
> >
> >
> > On Sun, Aug 27, 2017 at 5:58 PM, Martin Thomson <
> [e-mail]>
> > wrote:
> >>
> >> Hi David, I'm just trying to work out if the concern is with PvD or
> >> the API to start with.  Baby steps because I want to make sure there
> >> is no miscommunication.  Can you address that question please?  I
> >> can't tell from your response here.
> >>
> >> On 25 August 2017 at 23:11, David Bird <[e-mail]> wrote:
> >> > 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/curren
> t/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
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >
>