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

<hat off>

I don't think we should be limiting the ability of the host to address
itself.  And requiring each new address that is formed to be approved
by the capport infrastructure creates that opportunity, going against
the spirit of 7934.

Is it possible instead to scope our current work to enforcement
environments that are able to use only "properties of or from the
link" in their "are you captive or not" decisions?

By "properties of or from the link" I mean things like enforcing based on:

    - MAC address
    - the IPv6 /64 from which the source address comes
    - the IPv6 /56 (or other known delegation boundary)
    - DSL line-id
    - other link-associated metadata appropriate to the environment

Maybe "properties discernible from available link information" is a
(slightly) better phrasing.

On 5 December 2017 at 00:22, Dave Dolson <ddolson@sandvine.com> wrote:
> 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:captive-portals-bounces@ietf.org] On Behalf Of Erik Kline
> Sent: Sunday, December 3, 2017 10:48 PM
> To: Michael Richardson
> Cc: Kyle Larose; captive-portals@ietf.org
> Subject: Re: [Captive-portals] IETF 100: ICMP Discussion Summary
>
> On 4 December 2017 at 09:25, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>>
>> {did not make it in person, and had a conflict and I haven't watched
>> the session on youtube yet}
>>
>> Kyle Larose <klarose@sandvine.com> 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.
>
> 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>
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

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

Attachment: smime.p7s