Subject: [Captive-portals] UE Identification

From: Martin Thomson <[email-masked]>
Date: Mon, 4 Dec 2017 18:53:10 +1100

Thanks Kyle for the summary of the discussion.

The chairs would like to focus your attention on the issue of User
Equipment identification.  The basic problem is that the enforcement
point and API are two different entities.  They might also need to
talk about the UE with other entities (RADIUS servers, logging
systems, payment systems, and all sorts of backend systems).

How should the UE be identified?

We had a great discussion about this in Singapore and it's the view of
the chairs that there was no consensus for defining a set of UE
identifiers for explicit use in the protocols.  There were a few
reasons for this. One was that it would be difficult to find a set of
identifiers that would work for all deployments.  Also, allowing the
UE to include identifiers would increase the risk that the UE spoofs
those identifiers.

The two options that were discussed at length both involved having the
UE identified implicitly.  That is, some property of the packets that
arrive at the enforcement point would be used to identify the UE.  The
concern being that the identifier(s) were not subject to spoofing.
MAC, IP, or the circuit on which the packets arrive might all be
acceptable.

There was some discussion about how to manage consistent
identification between API and enforcement.  From the discussion, we
appear to have two options:

1. Identify the UE at the API the same way that it is identified at
enforcement.  API and enforcement would have to agree on the
identifier they use.  This would also constrain deployments so that
the API has to be located on the network in a position where
spoofing identifiers isn't possible.

2. Have the enforcement device pass an identifier (a "session ID") to
the UE for use with the API.  The enforcement would probably use an
ICMP extension to pass this information back.  This would need to be
authenticated, so that the UE couldn't generate a valid identifier.
There was plenty of discussion about that, but the short summary is
that this is possible if we want to have it happen.

It seems like there is some sense that the first option was preferred.
We'd like to get a sense of the list here.  Which of these options is
preferable, and why?

---

From: David Bird <[email-masked]>
Date: Mon, 4 Dec 2017 09:08:21 -0800

These are good questions for the group to consider and provide feedback
on...

While doing so, also consider the fact that the "The basic problem is that
the enforcement point and API are two different entities." is a problem of
our own creation in an effort to support an API that we haven't clearly
defined.

I suggest rethinking the problem, let the extra ICMP semantics sink in, and
consider the fact that we could achieve similar use-cases (if not
identical, even more use-cases) without the above "basic problem" ...

The use-cases I speak of specially are:

- A way to better identify captivity in the network and feedback (on a need
to know basis) of what resources are allowed in the walled garden.
- A non-redirect (non-flow terminating) way of notifying of pending session
interruptions or otherwise suggesting a portal visit.
- A deployment model that doesn't put huge requirements on systems
integrations and installers.

On Sun, Dec 3, 2017 at 11:53 PM, Martin Thomson <[email-masked]>
wrote:

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

---

From: David Bird <[email-masked]>
Date: Mon, 4 Dec 2017 09:11:58 -0800

I will also point out that the API is not only ill-defined, it doesn't have
editors... right?

On Mon, Dec 4, 2017 at 9:08 AM, David Bird <[email-masked]> wrote:

> While doing so, also consider the fact that the "The basic problem is
> that the enforcement point and API are two different entities." is a
> problem of our own creation in an effort to support an API that we haven't
> clearly defined.
>
> I suggest rethinking the problem, let the extra ICMP semantics sink in,
> and consider the fact that we could achieve similar use-cases (if not
> - A way to better identify captivity in the network and feedback (on a
> need to know basis) of what resources are allowed in the walled garden.
> - A non-redirect (non-flow terminating) way of notifying of pending
> session interruptions or otherwise suggesting a portal visit.

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 04 Dec 2017 12:35:37 -0800

Darshak Thakore and I are now the editors of the API document, and will be posting a new version of the document hopefully soon that addresses the discussions from the previous two IETF meetings. This definition will be a lot simpler, and should make it clearer how to interact with the ICMP path. 

Thanks,
Tommy

> On Dec 4, 2017, at 9:11 AM, David Bird <[email-masked]> wrote:
> 
> I will also point out that the API is not only ill-defined, it doesn't have editors... right?
> 
> On Mon, Dec 4, 2017 at 9:08 AM, David Bird <[email-masked] <mailto:[email-masked]>> wrote:
> These are good questions for the group to consider and provide feedback on...
> 
> While doing so, also consider the fact that the "The basic problem is that the enforcement point and API are two different entities." is a problem of our own creation in an effort to support an API that we haven't clearly defined.
> 
> I suggest rethinking the problem, let the extra ICMP semantics sink in, and consider the fact that we could achieve similar use-cases (if not identical, even more use-cases) without the above "basic problem" ... 
> 
> - A way to better identify captivity in the network and feedback (on a need to know basis) of what resources are allowed in the walled garden.
> - A non-redirect (non-flow terminating) way of notifying of pending session interruptions or otherwise suggesting a portal visit.
> - A deployment model that doesn't put huge requirements on systems integrations and installers.
> 
> 
> On Sun, Dec 3, 2017 at 11:53 PM, Martin Thomson <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/captive-portals <https://www.ietf.org/mailman/listinfo/captive-portals>
> 
>

---

From: David Bird <[email-masked]>
Date: Mon, 4 Dec 2017 12:39:59 -0800

Looking forward to it!

On Mon, Dec 4, 2017 at 12:35 PM, Tommy Pauly <[email-masked]> wrote:

> Darshak Thakore and I are now the editors of the API document, and will be
> posting a new version of the document hopefully soon that addresses the
> discussions from the previous two IETF meetings. This definition will be a
> lot simpler, and should make it clearer how to interact with the ICMP path.
>
> Thanks,
> Tommy
>
>
>> On Sun, Dec 3, 2017 at 11:53 PM, Martin Thomson <[email-masked]
>> > wrote:
>>