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

[David Bird <[e-mail]>]

My remaining questions:

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

- Can an API/PvD (in terms of captivity notification) be a solution for
https://www.ietf.org/mail-archive/web/captive-portals/current/msg00455.html
? (If not, does that show it's limitations?)

- And, a new question. I must be missing something... but, how does the API
or PvD identify UE/stations?
The API doc says:

5.1.1.  Associating User Equipment with its URL

   The CAPPORT API Server SHOULD associate an incoming request with a
   particular User Equipment consistently.  [TODO: specify how this
   would happen.]

This becomes a pretty important point because it can't be that each DHCP or
RA is custom formatted for each station with a UE specific URL. It also
needs to be a MUST if the API is returning information about
'bytes_remaining' and such. Or, does the UE self report it's MAC to the
API/PvD? The service needs some way of associating that API/PvD session
with the RADIUS accounting stream.

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

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