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.
<no_hats/>
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
>> 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?
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
