Re: [Captive-portals] Fwd: I-D Action: draft-ietf-capport-architecture-03.txt

[David Bird <[e-mail]>]

See inline

On Wed, Jan 2, 2019 at 10:48 AM Kyle Larose <[e-mail]> wrote:
>
> On Thu, 27 Dec 2018 at 14:14, David Bird <[e-mail]> wrote:
> >
> > The section titled  "Risk of Nuisance Captive Portal" should really be
talking about networks that USE the API and have NO network integration
(e.g. Captive by API only, not by any network enforcement function).
> >
>
> I think the nuisance captive portal SIGNALS are a legitimate concern.
> However, you raise a good point: we can't entirely trust the API -- it
> may become decoupled from the network for many reasons: an attack, a
> bug, misconfiguration, etc.
>
> So, now we're talking about the risk of a nuisance API as well as
> nuisance signals. I think we had been calling this a non-issue because
> UE discovers the API from somewhat trusted sources -- DHCP/RA,PvD.
> But, let's assume that the API is a bad actor for some reason --
> discovery was compromised, the API itself was compromised, or it's
> just plain broken.
>

Indeed, there are many, many reasons why the API might be "wrong".

I'd add that some networks will just slap together an API (or more likely
find one on the Internet) and make a simple DHCP server configuration
change -- and without any additional infrastructure costs, POOF ... they
have a 'modern day captive portal' according to the IETF.

Additionally, even when things are "working" the question is also "how
well" ... how fresh is the data in the API server? does it cover all types
of authentication (local, AAA, roaming, etc)? what happens when the queries
per second on the API server makes it crash ?

Below is a lot of new heuristics for a new service that was suppose to make
captive portal discovery / notification easier !


>
> Thinking about that case, you could have:
>
> 1. The API says that you have access when you don't.
> 2. The API says that you have access when you do.
> 3. The API says that you don't have access when you do.
> 4. The API says that you don't have access when you don't.
>
> We don't need to worry about 2, since things should just work. For 4,
> it could be a problem in that the portal will never really grant
> access... I discuss that a bit further down.
>
> In case 1. the system will try to access the network and fail. Barring
> probe functionality, this means that the system will simply fail to
> attach to the network properly. There's no good solution without user
> intervention. With probes, I think it works out naturally -- the
> system will work as it does today. But, without probes, I can't think
> of a nice solution.This is a concern that has been raised in the past
> (I think by you, David), since it means that we will still need probes
> for a "nice experience".
>
> In case 3. the UE will attempt to visit the portal. I can think of a
> few sub-cases here:
> a) The URI of the portal is bad/non-existent
> b) The URI is present, works and the portal says you have access
> c) The URI is present, works and the portal refuses to grant access.
>
> b) is easy: the UE proceeds with its connection and everything works.
>
> We need to consider a) a bit, since it's a fairly likely failure mode.
> I think it's probably safe to assume that, barring probes, network
> access is unavailable on this network, and the system should treat it
> as such.
> c) I think this should probably behave the same as a), though it's a
> bit nicer in that the user has actual feedback.
>
> It's a little unfortunate that with a) and c), the UE should have
> network access, but the user thinks they do not. What if they know
> that they should for some reason? Perhaps the recommendation should be
> to treat it as though network access is unavailable, barring explicit
> direction from the user to use the network, or confirmation that
> network access is available through probes.
>
> Case 4 can likely be handled in a similar way to case 3 -- you never
> get access, so the user either chooses a different network, or
> overrides the system's default, which then proves to them that the
> network does not provide access.
>
>
> > Happy Holidays!
> >
> > Cheers,
> > David
> >
> >