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

From: Nicolas Mailhot <[email-masked]>
Date: Tue, 01 Jan 2019 09:36:51 +0100

Le lundi 31 décembre 2018 à 17:44 -0800, David Bird a écrit :
> 
> - A misguided attempt at enforcing net neutrality

And it's a disgrace the IETF did not state clearly, from day one, that
such objectives and arguments have no place in an engineering forum. 

That's “crypto that protects honest people but not terrorists” land
(whatever *your* definition of honest people is). Humans have morals.
Tech and tools do not. That's been true since humans picked up their
first stone and used it to cruch nuts or fellow human beings.

Regards,

-- 
Nicolas Mailhot

---

From: Kyle Larose <[email-masked]>
Date: Wed, 2 Jan 2019 13:47:57 -0500

On Thu, 27 Dec 2018 at 14:14, David Bird <[email-masked]> 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

---

From: David Bird <[email-masked]>
Date: Thu, 3 Jan 2019 11:17:04 -0800

See inline

On Wed, Jan 2, 2019 at 10:48 AM Kyle Larose <[email-masked]> 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).
> discovery was compromised, the API itself was compromised, or it's

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 !