Re: [Captive-portals] UE Identification

On Dec 4, 2017, at 9:11 AM, David Bird <[email protected]> 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 protected]> 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" ... 

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 protected]> wrote:

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?

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

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