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 <db...@google.com> 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 <db...@google.com > <mailto:db...@google.com>> 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 <martin.thom...@gmail.com > <mailto:martin.thom...@gmail.com>> 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 <mailto:Captive-portals@ietf.org> > https://www.ietf.org/mailman/listinfo/captive-portals > <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
