Subject: Re: [Captive-portals] A final check on draft-ietf-capport-architecture-09

From: David Dolson <[email-masked]>
Date: Tue, 01 Sep 2020 12:49:29 -0400

How do such devices obtain IP addresses? 

Arguably the domain of Captive Portal solution is limited to the case
when the agent assigning IP addresses is controlling access to the
network as well. 

-Dave 

On 2020-09-01 01:28, Erik Kline wrote:

> One thing I realized that we didn't discuss in 7710bis, and didn't really discuss here either, is the issue of devices attached to routers which are themselves on the link with the provisioning service. 
> 
> Such clients would not have a way to receive an RA option nor any of the DHCP options since we didn't say what routers that observe these on a network should do (e.g. routers should/may include verbatim the 7710bis options in any of the applicable mechanisms for downstream clients). 
> 
> The section 2.5 captive portal signal might be able to come to the rescue here, but as we don't have such a thing. 
> 
> But...maybe that's a separate document?  
> 
> On Sun, Aug 9, 2020 at 5:11 PM Martin Thomson <[email-masked]> wrote: 
> 
>> The editors of draft-ietf-capport-architecture have put in a huge amount of work over the past few weeks in addressing the review comments.
>> 
>> https://tools.ietf.org/html/draft-ietf-capport-architecture-09
>> 
>> As there have been quite a few changes, I would like to request that people take a brief look again before we proceed.  I've been watching closely, and the changes look good, but I would like to confirm.  The changes are:
>> 
>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-capport-architecture-09.txt
>> 
>> Please send comments before 2020-08-16.
>> 
>> _______________________________________________
>> Captive-portals mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/captive-portals
> 
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals

---

From: Erik Kline <[email-masked]>
Date: Tue, 1 Sep 2020 11:35:14 -0700

> How do such devices obtain IP addresses?
In IPv4, this would be NAT.  The first host to connect would probably pass
the captive portal for all other devices, but only because of the
HTTP-intercept technique.  No clients would see the API URL, and they would
never be able to learn the venue URL

In IPv6 it's more complicated, and largely not yet addressed.  With Proxy
ND, the downstream clients would see the RA/DHCPv6 option(s).  With
64share, the same is possible but would, I suspect, be
implementation-dependent.

Arguably the domain of Captive Portal solution is limited to the case when
> the agent assigning IP addresses is controlling access to the network as
> well.
>
> -Dave
>

As we've currently scoped things, I agree.

The more I think about it, the use case I had in mind (capport
implementation in an ISP's modem/CPE) would probably require things we've
not yet completed.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Sep 2020 09:42:59 -0400

Erik Kline <[email-masked]> wrote:
    > One thing I realized that we didn't discuss in 7710bis, and didn't really
    > discuss here either, is the issue of devices attached to routers which are
    > themselves on the link with the provisioning service.

So, I agree with the thread that the options need to be passed on like DNS.
I guess architecturally maybe this needs to be specified.

From an implementation point of view, the router, whether IPv4 NAT44 or IPv6,
acts as a layer-2 "NAT", keeping the policy enforcement point from seeing the
end device's L2 address.

As such, mechanisms that whitelist^Waccept-list the client by L2 address
won't work, or will work wrong.
I think that many of us geeks have the experience of throwing our own router onto
the hotel LAN, then accepting the Terms using our laptop, and sharing that
with our other devices.

That accept-lists the router for IPv4, but IPv6 won't work that way.
And now temporary addresses uses for privacy each get caught.

    > But...maybe that's a separate document?

Our current solution isn't perfect, but it is a significant step forward.
Let's worry about this situation later.

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