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

[Kyle Larose <[e-mail]>]

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.

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