Re: [Captive-portals] IETF 100: ICMP Discussion Summary

[Michael Richardson]

Dave Dolson  wrote:
> Regarding multiple IPv6 addresses, consider these two alternatives:
> 1. Associate the new address with an existing capport "session", for
> uninterrupted experience.

...

> I propose that the capport API permits new IP addresses to be assigned
> to an existing session, by providing an appropriate token.

Given an approriate HTTP Cookie which is not tied to a particular v6 end
point, then one could call some API, having already authenticated.
So I can see that this could perhaps work.

The downside is that if I pass this cookie around to my friends, then my
friends can get service via me.  Unless the enforcement point enforces L2
addresses, which if it did, then we would have no problem.

I'm not sure if we can require that the new IP address be added from an
address that is already authenticated.  Not only does it mean that my host
has to figure out how to use what might be an expired temporary address, but
it also means that I could add my friends' IPs to my ACL rather easily.
How many can I add?  All 2^64 of them? :-)


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





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

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