Looking forward to it!
On Mon, Dec 4, 2017 at 12:35 PM, Tommy Pauly <[email protected]> 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 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 > > >
_______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
