[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Captive-portals] client identifying info between API and enforcement



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:[email protected]] 
Sent: Friday, October 20, 2017 9:39 AM
To: Dave Dolson
Cc: Kyle Larose; [email protected]; 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 <[email protected]> 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; [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
> 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 <[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?