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.]
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 <[email protected]> wrote:Sending to list...---------- Forwarded message ----------
From: "Martin Thomson" <[email protected]>
Date: Aug 30, 2017 3:52 PM
Subject: Re: [Captive-portals] Questions about PvD/API
To: "David Bird" <[email protected]>
Cc:
sending that to the list would be helpful
On 30 August 2017 at 23:11, David Bird <[email protected]> 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 <[email protected]>
> 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 <[email protected]> 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
>> > <[email protected]>
>> > 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 <[email protected]> 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
>> >> > <[email protected]>
>> >> > 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 <[email protected]>
>> >> >> 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 [captive-portals-bounces@ietf.org ] namens
>> >> >> > Tommy
>> >> >> > Pauly
>> >> >> > [[email protected]]
>> >> >> > Verzonden: donderdag 24 augustus 2017 18:03
>> >> >> > Aan: Lorenzo Colitti
>> >> >> > CC: Erik Kline; Eric Vyncke (evyncke); Martin Thomson;
>> >> >> > [email protected]; 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 <[email protected]>
>> >> >> > 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 <[email protected]>
>> >> >> > 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 <[email protected]>
>> >> >> >> 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
>> >> >> >>> <[email protected]>
>> >> >> >>> 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 <[email protected]>
>> >> >> >>> 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
>> >> >> >>>> <[email protected]>
>> >> >> >>>> wrote:
>> >> >> >>>>>
>> >> >> >>>>> On Thu, Aug 24, 2017 at 10:40 PM, David Bird
>> >> >> >>>>> <[email protected]>
>> >> >> >>>>> 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
>> >> >> >>> [email protected]
>> >> >> >>> https://www.ietf.org/mailman/listinfo/captive-portals
>> >> >> >>>
>> >> >> >>>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>
>