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

From: Erik Kline <[email-masked]>
Date: Mon, 16 Oct 2017 21:19:32 +0900

<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?

---

From: Dave Dolson <[email-masked]>
Date: Mon, 16 Oct 2017 14:23:40 +0000

Erik,

I infer you mean the MAC address is required so that the portal can open/close the firewall using it as a filter.
I'd prefer to see this done at the Internet layer (AKA layer3), with IPv4/6 addresses, to avoid limiting usefulness to a particular access technology.

So then, 
(a) one of the user's IP addresses would be used to make the request, but we might expect to include multiple addresses in the body of the request itself.
E.g., to provision IPv4 and (multiple) IPv6 at the same time.

Or, (b) we could say that provisioning must be repeated from each IP address to be used. Then the address could be implicit in the connection used for communication--which also serves as proof of ownership.

Just some thoughts.
-Dave

-----Original Message-----
From: Erik Kline [mailto:[email-masked]] 
Sent: Monday, October 16, 2017 8:20 AM
To: Kyle Larose; Dave Dolson
Cc: [email-masked]; David Bird
Subject: client identifying info between API and enforcement

<hat-free />

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Oct 2017 00:01:05 +0900

On Mon, Oct 16, 2017 at 11:23 PM, Dave Dolson <[email-masked]> wrote:

> I infer you mean the MAC address is required so that the portal can
> open/close the firewall using it as a filter.
> I'd prefer to see this done at the Internet layer (AKA layer3), with
> IPv4/6 addresses, to avoid limiting usefulness to a particular access
> technology.
>

How do you do that when devices can create new IPv6 addresses at will?

---

From: Kyle Larose <[email-masked]>
Date: Mon, 16 Oct 2017 15:03:19 +0000

This is a bit of a stream of consciousness, so sorry if I ramble. :)

Dave: There's also actions such as querying the state of captivity we need to consider.

Regarding the main question: Does it make sense to have the query be in two steps, or would that too complicated? E.g. if the API could indicate to the user that a particular piece of information was required -- MAC vs IP vs something else -- then it could be useful. 

In the hackathon at IETF 98, the API worked in a few steps. The User Agent would do a get on the URL, which would tell it where to create its session. It would then create a session with its MAC. That returned a session ID which was used for further communication. If the session already existed, the create would just return the same info as before. It worked pretty well, but the enforcement device was on the same segment as the user equipment.

Now, I'm not saying this is what we want to do here, since if the API is read only, we may not want to look at creating sessions. But, if the first get could return one of "Give me your MAC address, or give me your IP, or ...." then would that be sufficient? Or, are we concerned about the security of this? For example, I could just query random IPs on the network to see who is connected/active. If we had a randomized integer, it may be a little more secure. But, if it's a random integer, presumably it's handed out by the enforcement device or provisioning service. And that comes to your point about the URL not being per client. Would it be possible to include an extra field in the RA/PvD mechanics to hold this information?

(I need to read up more on both of these, admittedly, so I'm probably missing something here).

Do we need to worry about things like NAT, here, or should we call that out of scope? I'm thinking about my laptop behind some sort of portable router point querying the status of the captive portal to which that portable router is connected.

-----Original Message-----
From: Dave Dolson 
Sent: Monday, October 16, 2017 10:24 AM
To: Erik Kline; Kyle Larose
Cc: [email-masked]; David Bird
Subject: RE: client identifying info between API and enforcement

Erik,

So then,

Just some thoughts.
-Dave

-----Original Message-----
From: Erik Kline [mailto:[email-masked]]
Sent: Monday, October 16, 2017 8:20 AM
To: Kyle Larose; Dave Dolson
Cc: [email-masked]; David Bird
Subject: client identifying info between API and enforcement

<hat-free />

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).

---

From: Dave Dolson <[email-masked]>
Date: Mon, 16 Oct 2017 15:41:32 +0000

Or change MAC addresses at will?
Each change could be handled as a new capport session.

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Monday, October 16, 2017 11:01 AM
To: Dave Dolson
Cc: Erik Kline; Kyle Larose; [email-masked]; David Bird
Subject: Re: [Captive-portals] client identifying info between API and enforcement

On Mon, Oct 16, 2017 at 11:23 PM, Dave Dolson <[email-masked]<mailto:[email-masked]>> wrote:
I infer you mean the MAC address is required so that the portal can open/close the firewall using it as a filter.
I'd prefer to see this done at the Internet layer (AKA layer3), with IPv4/6 addresses, to avoid limiting usefulness to a particular access technology.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Oct 2017 00:59:34 +0900

We shouldn't be requiring devices to request permission from the network
every time they create a new IPv6 address. See RFC 7934 for rationale and
best current practices.

As for changing MAC addresses at will - captive portals are usually
deployed on wifi, and 802.11 is very much tied to a single MAC address. On
typical host platforms it's sometimes possible to change the MAC address,
but it's very hard to use more than one at the same time.

On Tue, Oct 17, 2017 at 12:41 AM, Dave Dolson <[email-masked]> wrote:

> *From:* Lorenzo Colitti [mailto:[email-masked]]
> *Sent:* Monday, October 16, 2017 11:01 AM
> *To:* Dave Dolson
> *Cc:* Erik Kline; Kyle Larose; [email-masked]; David Bird
> *Subject:* Re: [Captive-portals] client identifying info between API and
> enforcement
>
>
>

---

From: Kyle Larose <[email-masked]>
Date: Thu, 19 Oct 2017 15:10:36 +0000

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-masked]] 
Sent: Monday, October 16, 2017 8:20 AM
To: Kyle Larose; Dave Dolson
Cc: [email-masked]; David Bird
Subject: client identifying info between API and enforcement

<hat-free />

---

From: Erik Kline <[email-masked]>
Date: Fri, 20 Oct 2017 20:39:26 +0900

<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)).

---

From: Dave Dolson <[email-masked]>
Date: Fri, 20 Oct 2017 12:19:23 +0000

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-masked]; David Bird
Subject: Re: client identifying info between API and enforcement

<still no hats>

---

From: Erik Kline <[email-masked]>
Date: Fri, 20 Oct 2017 22:38:51 +0900

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...

---

From: Dave Dolson <[email-masked]>
Date: Fri, 20 Oct 2017 14:13:00 +0000

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

---

From: Dave Dolson <[email-masked]>
Date: Fri, 20 Oct 2017 14:14:53 +0000

> 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.

-Dave

---

From: Erik Kline <[email-masked]>
Date: Fri, 27 Oct 2017 17:16:03 +0900

<no_hats />

> 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?

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
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.

---

From: Kyle Larose <[email-masked]>
Date: Sat, 28 Oct 2017 12:41:11 +0000

> 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.

> which identifier (if any) the host presents when communicating with

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.

> Sent: Friday, October 27, 2017 4:16 AM
> To: Dave Dolson
> >> There also needs to be a basis for enforcement, i.e., the
> firewall block/allow rules. This must be something carried in every
> packet.
> >> 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
> >>> 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?
> >>>
> >>>

---

From: Erik Kline <[email-masked]>
Date: Tue, 31 Oct 2017 15:06:15 +0900

> 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 -- an…

<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.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Oct 2017 14:58:22 -0400

> architectures that are currently in use:

I think that I got you, but I need a picture.

    > [3] login service updates enforcement point about token_1's state

I think that login service updating enforcement point can simply say:
  "allow the L2 address associated with token_1"

If the tokens are big enough (16 bytes or more), they could be the L2 address
encrypted (privately) by the enforcement point, making the enforcement point
stateless.

I think that the access decisions need to be made by the enforcement device
at the L2 level for a bunch of different reasons including auditing.

At this point I think the industry has established that L2-mac-address
randomization is good, but that having it totally random is bad.

It should be the same whenever the ESSID/AP is the same, with some caveats,
and this gets us the nice property that access control doesn't have to be
done every time one visits the same place.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-