Subject: [Captive-portals] IETF 100: ICMP Discussion Summary

From: Kyle Larose <[email-masked]>
Date: Sun, 3 Dec 2017 19:11:09 +0000

Hey everyone,

At IETF 100 in Singapore the capport working group discussed the ICMP option for captive portals, and how to identify user equipment at the various components of the architecture.

I've gone over the Etherpad notes(https://etherpad.tools.ietf.org/p/notes-ietf-100-capport?useMonospaceFont=true). Below is what I think is the summary, in point form, along with what I think was the consensus. Note that no hums occurred during the discussion; any conclusions are my opinion from reading the notes.

Summary:
 - Discussed different deployment models:
   - Enforcement/API server on link with UE
   - Some combination of the above not being on link with the UE
   
   *** Consensus seemed to be that we must be flexible here to support carrier use-cases. ***

 - Discussed different identification methods:
   - Active/explicit (identity added by UE above lower layers in the request/packet -- e.g. session id)
    - various options: HMAC of UE information, local port id, etc.
	- Discussed whether the icmp message should contain a session ID that the UE can use to identify itself to the API server as an example of active identification.
   - Passive/implicit (identity inferred from normal addressing of device -- e.g. ip address)
   
   *** Consensus seemed to be leaning towards passive for security and simplicity reasons. ***
   
  - Discussed IPv4 vs IPv6, and how v6 seems to complicate matters with its ability to have many addresses for one UE:
   - Question was raised about whether we should restrict the number of v6 addresses (one address, one prefix, etc).
   - Related to the below discussion

  - Some discussion about what constitutes a new session:
   - new mac => new session?
   - new IP => new session?
   
   *** Didn't see any consensus about this, but I think we should continue that discussion. ***
   
  - I think there was a hint at multiple forms of enforcement:
   - What we've normally been calling the enforcement device: decide whether traffic can leave the network based on normal access rules
   - Enforcement of the identity of the source of the traffic: e.g. prevent spoofing so the API can trust passive data from the requests.
   
   *** Didn't really go anywhere that I could see, but probably warrants a bit more discussion. ***
   
Other stuff I recall, but didn't see much of in the notes:
 - Seemed to be agreement that we should try to put together a list of use-cases being deployed now that could benefit from capport so we can understand the impact of any restrictions we place on it.
 - I recall something about restricting the UE, API server and ED to be on the same link (or provisioning domain?) from the UE's perspective to simplify the passive identification. Didn't see it in the notes, though, so I may be imagining it.
 - There seemed to be general support for a simple form of the ICMP option (i.e. keep it a simple notification of a problem, rather than communicating further state within it). We need to work on what exactly this entails, and what we lose by taking out the more advanced capabilities (i.e. maybe first round has the simple methods, but we can add more extensions as the base technology is adopted).

That's it! Feel free to point out anything I've misinterpreted, or that is just plain wrong. Likewise, please point out anything important I've inadvertently omitted.

Thanks!

Kyle

---

From: Michael Richardson <[email-masked]>
Date: Sun, 03 Dec 2017 19:25:03 -0500

{did not make it in person, and had a conflict and I haven't watched the
session on youtube yet}

Kyle Larose <[email-masked]> wrote:
    > - Question was raised about whether we should restrict the number of v6
    > addresses (one address, one prefix, etc).

Was there any consensus?

I don't see a way to restrict the number of v6 addresses per UE except via stateful
DHCPv6, and few use that.

    > - I recall something about restricting the UE, API server and ED to be
    > on the same link (or provisioning domain?) from the UE's perspective to
    > simplify the passive identification. Didn't see it in the notes,
    > though, so I may be imagining it.

The term provisioning domain is probably more precise.

    > - There seemed to be general support for a simple form of the ICMP
    > option (i.e. keep it a simple notification of a problem, rather than
    > communicating further state within it). We need to work on what exactly
    > this entails, and what we lose by taking out the more advanced
    > capabilities (i.e. maybe first round has the simple methods, but we can
    > add more extensions as the base technology is adopted).

+1

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

---

From: Erik Kline <[email-masked]>
Date: Mon, 4 Dec 2017 12:47:39 +0900

> DHCPv6, and few use that.

No consensus yet, IIRC.

<hats:off>

My opinion is that we cannot restrict IPv6 addresses (violation of
7934).  And any captive portal that identifies clients solely by IPv6
address is going to give some UEs a royally painful experience.  When
the downstream network architecture can include whole /64s given to
single devices (e.g. 64-per-host) the experience will get really bad.

This is just a reality of dealing with IPv6 (and I think it's a good
thing).  We just need to adapt, and I think it actually points to some
constraints we can use to narrow down the solution space.

As I see it at the moment, the only future-proof options come down do:

    - building into the portal/enforcement point knowledge of the
network architecture
    - identifying clients by things that identify the device on-link
(e.g. MAC address)
    - identifying clients by things that identify the link itself (DSL
line ID, /64, ...)

</hats>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Dec 2017 08:32:27 -0500

> - identifying clients by things that identify the link itself (DSL

I agree completely.

---

From: Dave Dolson <[email-masked]>
Date: Mon, 4 Dec 2017 15:22:43 +0000

Regarding multiple IPv6 addresses, consider these two alternatives:
1. Associate the new address with an existing capport "session", for uninterrupted experience.
2. Treat a new address as a new session, for increased anonymity to the captive portal.

(I don't see how one can have the anonymity without the pain of signing in again.)

Since the level of anonymity with the portal is dubious anyhow (it sees the MAC address, and possibly other credentials), and repeatedly signing into a portal is annoying, I think it is important to try to provide a standard for (1).
Even if (1) is provided, the device of a privacy-seeking user could nonetheless choose to trigger the workflow of a new device, case (2).

I propose that the capport API permits new IP addresses to be assigned to an existing session, by providing an appropriate token. 

-Dave

-----Original Message-----
From: Captive-portals [mailto:[email-masked]] On Behalf Of Erik Kline
Sent: Sunday, December 3, 2017 10:48 PM
To: Michael Richardson
Cc: Kyle Larose; [email-masked]
Subject: Re: [Captive-portals] IETF 100: ICMP Discussion Summary

On 4 December 2017 at 09:25, Michael Richardson <[email-masked]> wrote:
>
> {did not make it in person, and had a conflict and I haven't watched 
> the session on youtube yet}
>
> I don't see a way to restrict the number of v6 addresses per UE except 
> via stateful DHCPv6, and few use that.

No consensus yet, IIRC.

<hats:off>

My opinion is that we cannot restrict IPv6 addresses (violation of 7934).  And any captive portal that identifies clients solely by IPv6 address is going to give some UEs a royally painful experience.  When the downstream network architecture can include whole /64s given to single devices (e.g. 64-per-host) the experience will get really bad.

This is just a reality of dealing with IPv6 (and I think it's a good thing).  We just need to adapt, and I think it actually points to some constraints we can use to narrow down the solution space.

    - building into the portal/enforcement point knowledge of the network architecture
    - identifying clients by things that identify the device on-link (e.g. MAC address)
    - identifying clients by things that identify the link itself (DSL line ID, /64, ...)

</hats>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Dec 2017 18:58:28 -0500

> uninterrupted experience.

...

    > I propose that the capport API permits new IP addresses to be assigned
    > to an existing session, by providing an appropriate token.

Given an approriate HTTP Cookie which is not tied to a particular v6 end
point, then one could call some API, having already authenticated.
So I can see that this could perhaps work.

The downside is that if I pass this cookie around to my friends, then my
friends can get service via me.  Unless the enforcement point enforces L2
addresses, which if it did, then we would have no problem.

I'm not sure if we can require that the new IP address be added from an
address that is already authenticated.  Not only does it mean that my host
has to figure out how to use what might be an expired temporary address, but
it also means that I could add my friends' IPs to my ACL rather easily.
How many can I add?  All 2^64 of them? :-)