Erik, Good questions. Some options:
(a) enforcement should be done at the access layer. In that case we'd have to support multiple types of access-specific identities (MAC address, IMSI/IMEI, ...) (b) Is it reasonable to require DHCPv6 (either stateful or using prefix delegation) at captive portals, excluding SLAAC? I think it's interesting to consider the tethered and virtual-machine use-cases. I'm on the fence about whether these devices should be considered independent agents or fall under the session of the parent device. -Dave -----Original Message----- From: Erik Kline [mailto:e...@google.com] Sent: Friday, October 20, 2017 9:39 AM To: Dave Dolson Cc: Kyle Larose; captive-portals@ietf.org; David Bird Subject: Re: client identifying info between API and enforcement With temporary addresses being created on the fly whenever desired, the user could be perpetually bombarded with non-stop portal interactions. Not to mention, there is (currently) no guarantee that the IP address the device uses for interacting with the portal is necessarily the same as the newly created address that needs to be used (speaking of IPv6 only; in IPv4 I think we all accept devices really only get one and only one address). Clearly if the enforcement box is on the same link as the shared prefix it's a solvable problem, right? (just record {l2, l3} pairs) The issue is then one of what to do about architectures where the enforcement point is not on the same link as a shared prefix? In a deeply multi-tiered architecture this could get really difficult... hmm... On 20 October 2017 at 21:19, Dave Dolson <ddol...@sandvine.com> wrote: > There also needs to be a basis for enforcement, i.e., the firewall > block/allow rules. This must be something carried in every packet. > I think the user IP address is the best candidate. > > In some types of access, users are granted /64 IPv6 prefixes, from which > devices can choose the address. In such cases, the enforcement can be based > on the prefixes. > > If multiple users are sharing a prefix, I see no alternative to having the > user device register each address to be used. > > The initial capport conversation could have the server produce a token for > later use. The client would generally be motivated to use the token in > subsequent updates vs starting a new session. > > > David Dolson > Sandvine > Original Message > From: Erik Kline > Sent: Friday, October 20, 2017 7:39 AM > To: Kyle Larose > Cc: Dave Dolson; captive-portals@ietf.org; David Bird > Subject: Re: client identifying info between API and enforcement > > > <still no hats> > > In the abstract we could define the requirements for what could > replace MAC address. The MAC address is really just a "token" that > the enforcement point adds to the URL and then gets it back from the > API-serving element (AIUI). > > It could just as well be HMAC("my c00l secr3t", <client_mac_address>) > which, when passed back to the enforcement point is looked up in some > hash that can expire old entries to find the mapping that identifies > the client. > > But that still leaves the issue of how does that "token" get into the > API URL in the first place. Currently, I have seen what looks like > the enforcement point rewriting URLs to insert this stuff. I just > think we should be explicit in calling out what we think needs calling > out in this area. (if for no other reason than it might become > "operational guidance" if someone wants to write such a doc in the > future) > > The issue of link-layer token to IP address policy is a somewhat > separate discussion, I feel. We definitely shouldn't give IPv6 SLAAC > addresses any grief though. And to me, that points toward the token > being fairly well tied to the link-layer, though of course it can be > made an opaque token (opaque to everything bug the enforcement > device(s)). > > On 20 October 2017 at 00:10, Kyle Larose <klar...@sandvine.com> wrote: >> Is another way of looking at this problem to consider defining the identity >> of the user equipment? >> >> From the perspective of the enforcement device, it's probably the source MAC >> address or source IP (or both) of the packets being sent through it. It's >> hard to spoof that without wrecking the network, right? >> >> But, if we intend on having the API server potentially live elsewhere in the >> network, those identifying characteristics may not be available in the >> requests being sent to that server, or if they are, they may be different >> due to intermediate devices such as NAT, routers, etc. >> >> If the user equipment understands its identity, then it can always put that >> into requests. As long as everyone agrees on what constitutes the identify, >> we're good. That sort of aligns with my earlier email about potentially >> negotiating what identifies a user equipment. >> >> However, what concerns me with this approach is security: how can we trust >> that the client of the API server isn't spoofing its identity? So, the >> question becomes: what verifiable identify can a user equipment have that an >> API server can validate, and if necessary, translate into an identity >> understood by the enforcement device? >> >> >> -----Original Message----- >> From: Erik Kline [mailto:e...@google.com] >> Sent: Monday, October 16, 2017 8:20 AM >> To: Kyle Larose; Dave Dolson >> Cc: captive-portals@ietf.org; David Bird >> Subject: client identifying info between API and enforcement >> >> <hat-free /> >> >> Kyle, Dave, (David, all,) >> >> When a client is trying to talk to an [architecture-2.3] API server, >> using the URL is learned in [architecture-2.2], will it need to >> present some token that the API server can ultimately use when >> communicating back to the enforcement box? >> >> I'm effectively wondering about how we get (something like) the MAC >> address of a client into this URL, /especially/ when the URL might not >> be custom crafted for each client (i.e. in the case of the URL in an >> ICMPv6 RA or learned via PvD mechanics). >> >> What's required here and how do we think it should work? _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
