Subject: [Captive-portals] Minutes for IETF 102 meeting

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Jul 2018 16:52:46 -0400

Thanks everyone for a productive and constructive discussion today.
Minutes are up:

https://datatracker.ietf.org/doc/minutes-102-capport/
https://github.com/capport-wg/wg-materials/blob/master/ietf102/minutes.txt

I've opened a few issues for those things that I identified as needing
issues.  Pull requests are welcome - I did miss a few things and
likely mischaracterized some other things.

---

From: David Bird <[email-masked]>
Date: Tue, 17 Jul 2018 15:10:29 -0700

A couple questions to clarify...

"lorenzo - if the API is advertised on a non-captive network, that's
equivalent to being logged in"

Only if the API is advertised and saying you are captive, right?  Or, is
this addressing the case there the API is advertised on a network that has
no network integration (e.g. no actual captive portal, just open WiFi)? If
the latter, how did the UE determine the "logged in" state, with a probe?

"warren - extra edgecase - incorrect API listed, either it is down or the
information is wrong"
"tommy - we fall back"

Knowing the information is wrong will be tricky, unless UEs are going to
keep probing like they do today...

And, fall back to what? Hoping that infrastructure vendors redirect HTTPS
so users don't have bad experiences in case the API was wrong about expiry
time?

"eric kinnear - this won't work if the network is suddenly captive after
not being captive"

This was an good comment that didn't seem to get replies... Without network
signaling, the user would be in limbo when the network puts them in
captivity (e.g. Idle timeout, maybe a virus detected) before the UE had
time to be notified from polling the API. We aren't any closer to getting
rid of HTTPS redirecting... which is part of the 'fall back' solution.

"tommy - should we suggest that the probe use the Accept header we use for
the API?"

We are formalizing probing? Wasn't that something we wanted to eliminate
the need for?

So... we keep probing, we require the status-quo as our 'fall back', we
don't really solve HTTPS redirecting (in fact, we sorta still need it); I'm
just not sure we are solving things or just adding layers of complexity.

On Tue, Jul 17, 2018 at 1:53 PM Martin Thomson <[email-masked]>
wrote:

> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 20 Jul 2018 15:25:35 -0400

> Thanks everyone for a productive and constructive discussion today.

A very big thank you.
The minutes are probably more verbose than is useful... suggest ACTION or
something to indicate when there was something to do.

> darshak - logged in is not necessary a binary state - what if the
> network wants to block netflix

It is noted that we can't get consensus.  Some questions:
1) is that we can't get consensus on whether this is a good idea?
2) that we can't get consensus on how to signal this?
3) on how to represent this in the protocol?

I think that it's useful to clearly state what is going to be out-of-scope.
(and I think that we really do need this)

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Jul 2018 13:12:56 +1000

> something to indicate when there was something to do.

The word "conclusion" is adjacent to the critical points.  There are
only a few of those.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Jul 2018 13:20:36 +1000

(I thought this needed a new thread.)

> 3) on how to represent this in the protocol?

Good question.

My reading is that it could be all three, but my hope is that it turns
out that we can agree to a weaker form of signaling that will allow us
to avoid having to agree on 1, even if that is what lies at the root
of this particular issue.

My reading of the conversation thus far is that we might get consensus
to make this part of the communication between the network operator
and a human.  That is, the network operator is expected to use the web
page to communicate this sort of information rather than to encode it
in the sort of terms that we would express in something as precise and
harsh as JSON.

As David mentions here and on the other thread, the ways in which the
network access you get and the network access you assume you have (or
each of us might assume is ideal) differ are virtually innumerable.
Blocking of access to certain destination is not the only thing that
might be considered: rate limiting, path selection, quality of
service, packet markings, and all sorts of variations are possible.

The IAB attempted to look at this problem a while back with RFC 4084 -
https://tools.ietf.org/html/rfc4084 - which was mentioned in the
meeting.  That might be a useful reference in any text that addresses
this point.  Not because the taxonomy there is useful (it's long since
been overtaken by events), but because it helps illustrate the
complexities involved.

In writing this, I realize that this conclusion would be something of
a cop-out on our part.  In other words, lacking consensus on the
fundamental issue, we instead to shift the responsibility to the
individual least able and empowered in this entire transaction.  While
acknowledging that flaw, the benefits here could still outweigh that
negative.  We might not fix the underlying problem, but we can still
fix the technical side-effects of it (attempts to MitM HTTPS, lack of
clarity at the UE end, etc...).  I'm guessing here, but it's possible
that attempting to use this work as a means of forcing people to
change their practices is more likely to result in the work we produce
being roundly ignored.

> (and I think that we really do need this)

I opened https://github.com/capport-wg/architecture/issues/13 during
the meeting to track this. You weren't the only one to realize this (I
won't claim credit, but can't remember who to give credit to - you can
try the recording if you like).

Thanks,
Martin (not a chair at this time, though the chair part would
definitely like to see this resolve)

---

From: David Bird <[email-masked]>
Date: Tue, 24 Jul 2018 07:49:01 -0700

Hi Martin,

-- quote --
-- /quote --

Thanks for this... it sums up my thoughts nicely too. The key word is
*could* -- it is a gamble. My conclusion, however, is that unless we
address the fundamental issues at the network layer, we can't really fix
the technical side effects of it (indeed, we can only add more side
effects). My conclusion is that enforcement function vendors will have no
idea if the API is implemented, integrated, and deployed correctly (enough)
for them to phase out MitM HTTPS - even after 10 years of CAPPORT solutions
and UE support - because there are too many edge cases. Also, as the API is
seen to be wrong or misleading in the wild, UEs continue to probe, they
don't really have clarity we anticipated...