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

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

On 28 October 2017 at 21:41, Kyle Larose <[email protected]> wrote:
>> It strikes me that we should hear again about the extra information
>> in
>> the proposed ICMP option.  I'm wondering if it could be made more
>> opaque to the client, maybe boil it down to just the SESSION_ID
> I've also been wondering if we can somehow use ICMP to aid in communicating this sort of information.
>> portion.  Then what we'd need to figure out would be how to
>> associate
>> SESSION_IDs across multiple IP(v6) addresses such that there is some
>> higher-level session which the infrastructure uses for tracking, and
>> which identifier (if any) the host presents when communicating with
>> the API endpoint.
> So, you're saying this SESSION_ID is the global identifier that represents the user equipment on the captive network? It's independent of the devices' addresses on the network, but tied to them
> somehow.
> How about this: the enforcement device is the one device in the network that knows the information which identifies a device -- since it is using it to make a decision. But, if it fails to match a device in its capport rule table, it can't really provide it with a SESSION_ID. However, what it can do is put into the ICMP message the relevant information that it used to identify the device. So, when the device constructs its API call in response to the ICMP message, it could use this information in conjunction with a SESSION_ID provided at provisioning time. There are some security concerns here -- how do we prevent an arbitrary device from logging itself in? But, let's explore this a bit.
> For example, if the client device attempts to communicate with an IP that was not provisioned, it receives the ICMP message back. It maps the interface on which the message was received to an existing SESSION_ID. If it already has a session, it goes to the captive portal page with that SESSION_ID already populated.  Of course, that's not a very good user experience -- who cares to understand which IPs are being used underneath the hood? That's a case for the API *not* being read only. We make it automatic in the case where there is already a session in place.
> In the case where there is no session, it opens up the captive portal URL. The nice thing about this is that it keeps the solution simple for the single IP case -- similar to what we have now -- and add an extension for the case where there are multiple IPs.


I /think/ I might be following you, but I'm not sure.  I look forward
to a more robust discussion in Singapore.

I was expecting this is what might be required, given the
architectures that are currently in use:

    [1] for traffic from a new node not in the enforcement points's
database, ICMP w/ a new id token (token_1)
    [2] captive device ("node") talks to the login service (via web or
API) and presents token_1
    [3] login service updates enforcement point about token_1's state
    (assuming login success)
    [4] same captive device that used token_1 generates a new address,
notices ICMP w/ a new id token (token_2)
    [5] captive device talks to login service (via web or API) and
presents token_1 and token_2
    [6] login service updates enforcement with token_2's state, likely
also providing correlation info with token_1

For each repeated {4,5,6} with new id token, token_N, the node only
needs to present the login provider with the first token it recorded
using during the network association (token_1) and token_N.  The login
provider and possibly enforcement point need to keep some meta-session
state to tie all this together for the sake of the client.

Now, having said this I'm not sure if this is necessarily a great
idea.  But I'm also not sure I see another way by which this could
work for architectures where the enforcement point might not have
direct link layer knowledge of attached clients.

>> -----Original Message-----
>> From: Erik Kline [mailto:[email protected]]
>> Sent: Friday, October 27, 2017 4:16 AM
>> To: Dave Dolson
>> Cc: Kyle Larose; [email protected]; David Bird
>> Subject: Re: client identifying info between API and enforcement
>> <no_hats />
>> On 20 October 2017 at 23:14, Dave Dolson <[email protected]>
>> wrote:
>> >> 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
>> >
>> > So having the client explicitly mention the IP addresses in the
>> message is a good idea, vs.
>> > using addresses implied from the API client.
>> It does open up the possibility that one host could attempt to
>> request
>> access on behalf of another, I think.  Not sure what to make of
>> that,
>> but I suspect where payment per host is the model operators might
>> find
>> this...potentially problematic?
>> > -----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
>> >> 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?

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature