Re: [Captive-portals] UE Identification

[Tommy Pauly]

The WIP is up on GitHub here:

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

Thanks,
Tommy

> On Jan 16, 2018, at 10:24 AM, David Bird  wrote:
> 
> Do we have a preliminary draft of the API yet?
> 
> Requirements, purpose, whatnot...
> 
> On Mon, Dec 4, 2017 at 12:39 PM, David Bird  > wrote:
> Looking forward to it!
> 
> 
> On Mon, Dec 4, 2017 at 12:35 PM, Tommy Pauly  > 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 > > 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 > > 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 > > 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
>> Captive-portals@ietf.org 
>> https://www.ietf.org/mailman/listinfo/captive-portals 
>> 
>> 
>> 
>> ___
>> Captive-portals mailing list
>> 

Re: [Captive-portals] UE Identification

[David Bird]

Looking forward to it!


On Mon, Dec 4, 2017 at 12:35 PM, Tommy Pauly  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  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  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 > > 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
>>> Captive-portals@ietf.org
>>> https://www.ietf.org/mailman/listinfo/captive-portals
>>>
>>
>>
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals
>
>
>
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] UE Identification

[Tommy Pauly]

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  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  > 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  > 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
> Captive-portals@ietf.org 
> https://www.ietf.org/mailman/listinfo/captive-portals 
> 
> 
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

[Captive-portals] UE Identification

[Martin Thomson]

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
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals