[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Captive-portals] client identifying info between API and enforcement
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.
From: Erik Kline
Sent: Friday, October 20, 2017 7:39 AM
To: Kyle Larose
Cc: Dave Dolson; [email protected]; 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
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
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
On 20 October 2017 at 00:10, Kyle Larose <[email protected]> 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:[email protected]]
> Sent: Monday, October 16, 2017 8:20 AM
> To: Kyle Larose; Dave Dolson
> Cc: [email protected]; 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?