Subject: Re: [Captive-portals] UE Identification

From: David Bird <[email-masked]>
Date: Tue, 16 Jan 2018 10:24:48 -0800

Do we have a preliminary draft of the API yet?

Requirements, purpose, whatnot...

On Mon, Dec 4, 2017 at 12:39 PM, David Bird <[email-masked]> wrote:

> 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 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]> 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-masked]> 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-masked]
>>>> https://www.ietf.org/mailman/listinfo/captive-portals
>>>>
>>>
>>>
>> _______________________________________________
>> Captive-portals mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/captive-portals
>>
>>
>>
>

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 16 Jan 2018 14:06:38 -0800

The WIP is up on GitHub here:

https://github.com/capport-wg/api <https://github.com/capport-wg/api>

Thanks,
Tommy

> On Jan 16, 2018, at 10:24 AM, David Bird <[email-masked]> wrote:
> 
> On Mon, Dec 4, 2017 at 12:39 PM, David Bird <[email-masked] <mailto:[email-masked]>> wrote:
> Looking forward to it!
> 
> 
> On Mon, Dec 4, 2017 at 12:35 PM, Tommy Pauly <[email-masked] <mailto:[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 Dec 4, 2017, at 9:11 AM, David Bird <[email-masked] <mailto:[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>
>> 
>> 
>> [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: Tue, 16 Jan 2018 15:17:09 -0800

Thanks!

Would be great to get more of Requirements/Purpose section nailed down
before deep dives into implementation...  We currently have:

- The state of captivity (whether or not the host has access to the
Internet)
[Also provided by ICMP]

- A URI that a host's browser can present to a user to get out of captivity
[Also provided by RFC 7710]

- An encrypted connection (TLS for both the API and portal URI)
[Captive portals can use TLS today... API needs defining.]

On Tue, Jan 16, 2018 at 2:06 PM, Tommy Pauly <[email-masked]> wrote:

> https://github.com/capport-wg/api
>
> Thanks,
> Tommy
>
>