Subject: Re: RA extension review requested for draft-wkumari-dhc-capport

From: Warren Kumari <[email-masked]>
Date: Mon, 20 Apr 2015 16:59:42 -0400

So, I'm having a hard time trying to convert these comments into
actual text that I can put in the document. If people have anything
specific that they would like incorporated, please send text.

The purpose of this document is simply to inform the client that it is
behind a CP **and how to reach that CaptivePortal**.
A client connecting to a new network has to assume that there may be a
CP present, and perform probing to try and find the CP. Providing the
client with an explicit signal and location allows the client to get
connected faster.

I do not think that the *network* needs to (or should) keep track of
the state of the client; it feels like a layer violation, and adds
much complexity. Many networks with captive portals are small networks
like coffee shops, doctor's offices, or similar, and so have very
limited networking devices. So, keeping this as simple and
non-resource intensive is a definite goal. For example, many homes'
CPE contain CP functionality, for example for guest networks. As we
have often seen, the quality of home CPE is far from stellar and so
keeping the functionality simple and easy to implement would be good.

The captive portal needs some state because it acts as a gatekeeper,
and the client needs *some* state because it establishes a TCP
connection and does the login dance. There is a mailing list to
discuss the larger set of interactions around captive portals, and I
suspect we will probably end up with a protocol between the client and
the CP that provides information to the client such as how long it's
access is valid for, etc.

So, again, this document is not trying to address the whole CP
interaction, instead it is simply a "Dude, there is a CP at $location,
you will have to talk to it before you can reach the Internet"...

On Fri, Mar 27, 2015 at 3:55 PM, Warren Kumari <[email-masked]> wrote:
> Hi all,
>
> Just quickly wanted to say thanks for the comments --  I haven't done
> anything useful with them yet, but will address them after the meeting
> is all done, I've gotten home, etc...
>
> W
>
>
> On Fri, Mar 27, 2015 at 8:43 AM, Alexandru Petrescu
> <[email-masked]> wrote:
>> Le 27/03/2015 08:12, Dan Lüdtke a écrit :
>>>
>>>
>>>>>
>>>>>>
>>>>>> Why would there be two routers on the same Client subnet in the
>>>>>> first place?
>>>>>
>>>>>
>>>>> So the clients can be multi-homed.
>>>>
>>>>
>>>> Ok, so each router would advertise a different prefix.
>>>>
>>>> In a similar way, two DHCP Relays (software present in each Router)
>>>> would be in charge of two different prefixes, distinction visible
>>>> in DHCP Server's conf file.
>>>>
>>>
>>> Only if both routers are from the same provider or administrative
>>> domain, right?
>>
>>
>> Right.
>>
>> I think two non-DHCP-Relay Routers too will need to be from the same
>> provider or same administrative domain in order to advertise two
>> different prefixes on the same link.  The reason of that necessity is
>> that they must make sure only one of them claims (RA) to be a default
>> router, otherwise they will fool the Client with two default routes (a
>> Client uses only one default route).  That can be achieved only if they
>> are administered by a single entity, be that an ISP or a sysadmin.
>>
>>> Not sure what the direction is you want to got there, but I remember
>>> it was about “the full picture”.
>>
>>
>> I am trying to say that the full picture of a network can easily include
>> a DHCP server(s), as much as a well-administered set of Routers sending RAs.
>>
>> This full picture would be needed when conceiving how the portal
>> notification should be given to a client.
>>
>> Suggesting not to set DHCP out of it.
>>
>> Alex
>>
>>
>>
>>>
>>>
>>> Dan
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>    ---maf

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Jared Mauch <[email-masked]>
Date: Mon, 20 Apr 2015 17:15:32 -0400

with the HTTPS everywhere movement, a method such as this needs to be
simple and widely available.  Today we see interception of tcp/80 as
part of a natural browser <-> server interaction to drive the user
to the authentication portal.

Allowing a DHCP option to specify one is behind a CP, allows authentication
to occur regardless of the end-site the user is attempting to interact with.

Information such as duration SHOULD be communicated via the duration of
lease.  Things such as multiple DHCP servers should not be in such a
document as it increases the complexity of response without adding value.
If one has multiple DHCP servers giving out different portals without
further communication between them, of course things will break.  It’s
not incumbent to document all the ways a network can poorly perform, but
we are defining how it should perform well, leaving the implementation
details of clustering, etc.. should be left to the implementing network.

- Jared

> On Apr 20, 2015, at 4:59 PM, Warren Kumari <[email-masked]> wrote:
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: David Farmer <[email-masked]>
Date: Mon, 20 Apr 2015 19:16:18 -0500

On 4/20/15 15:59 , Warren Kumari wrote:
...
> client with an explicit signal and location allows the client to get

I don't know if this has been discussed already, but I think the ability 
to provide an explicit signal there is NO CP would also be useful, as 
well an primary intent of an explicit signal there is a CP.  Countering 
the assumption that a client needs to test for a CP.

...
> you will have to talk to it before you can reach the Internet"...

And I'd like to also see an option for "Dude, your all set to talk to 
the Internet", there is no need to probe for a captive portal.  There 
still maybe reasons to check and see if you are really connected to the 
Internet, things do break from time to time, but there SHOULD NOT be a 
CP in the way.

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Christian Huitema <[email-masked]>
Date: Tue, 21 Apr 2015 01:44:33 +0000

On Monday, April 20, 2015, at 5:16 PM, David Farmer wrote:
> ... 
> I don't know if this has been discussed already, but I think the ability to provide
> an explicit signal there is NO CP would also be useful, as well an primary intent of
> an explicit signal there is a CP.  Countering the assumption that a client needs to
> test for a CP.

+1

Of course, that won't work on day 1. In the absence of information, the client will have to go on testing for CP. But still, that makes the eventual outcome better.

-- Christian Huitema

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 21 Apr 2015 15:10:29 +0900

On Tue, Apr 21, 2015 at 9:16 AM, David Farmer <[email-masked]> wrote:

>> to provide an explicit signal there is NO CP would also be useful, as well
>> an primary intent of an explicit signal there is a CP.  Countering the
>> assumption that a client needs to test for a CP.
>>
>
Yeah, because people won't ever the "no captive portal" signal if there's a
captive portal, will they?

http://www.cadinc.com/why-your-apple-ios-7-device-wont-connect-to-the-wifi-network
http://www.cisco.com/c/en/us/td/docs/wireless/controller/7-4/configuration/guides/consolidated/b_cg74_CONSOLIDATED/b_cg74_CONSOLIDATED_chapter_01010101.html

---

From: Warren Kumari <[email-masked]>
Date: Tue, 21 Apr 2015 08:36:58 -0400

> http://www.cisco.com/c/en/us/td/docs/wireless/controller/7-4/configuration/guides/consolidated/b_cg74_CONSOLIDATED/b_cg74_CONSOLIDATED_chapter_01010101.html

Yeah, unfortunately Lorenzo is right -- there is an incentive for
networks who have a CP to claim that they do not, and so providing an
explicit "there is no CP here" signal seems like it may be a bad idea.

For the foreseeable future, and possibly for ever, clients will still
need to perform captive portal probing. Having the network inform the
client that it is behind a captive portal, and how it contact it is an
*optimization* - it allows the client to reach the CP faster / more
reliably, but does not, unfortunately, remove the need to probe.

W

---

From: Warren Kumari <[email-masked]>
Date: Tue, 21 Apr 2015 09:24:57 -0400

On Mon, Apr 20, 2015 at 5:15 PM, Jared Mauch <[email-masked]> wrote:
> lease.

I've heard this suggestion a few times (and I almost added a TTL to
the option), but it turns out this won't work - I guess I should add a
note to the document explaining why.

At many venues (for example, hotels), you can purchase different
amounts of time -- 1h for $2.95, 3h for $4.95, 1d for $15.95 or a week
for $<all the money in your wallet>.
The DHCP server doesn't know (actually, no-one knows) how much you
will purchase until you do :-)
You *could* possibly design something where the CP informs the DHCP
server after you have purchased, so that next time you connect you can
be told, but this seems overly complex.

There is a captive portal mailing list (and we may hold a BoF in
Prague) where we are discussing a captive portal interaction protocol.
Basically, you will discover the CP (using the DHCP/RA option, or
through probing), and the CP will include something like a
/.well-known/ URL, a WISPr Redirect, <something> that will allow the
client to come back and poll the CP itself for status - things like
remaining time, where to go to re-authenticate, etc. Basically the
stuff in the current doc just says:
"There is a CP. It live at <foo>",  and there will (eventually!) be a
better way of getting more info....

>  Things such as multiple DHCP servers should not be in such a

Yah. There are many ways to screw yourself, trying to enumerate all of
them leads to failure (and gives people ideas!)

At one point I tried to explain what a client should do it it gets CP
information via multiple means (e.g: RA and DHCPv4). This got tricky
(and was somewhat arbitrary). Eventually Ted Lemon suggested:

"In order to support multiple "classes" of clients (e.g: IPv4 only,
   IPv6 only with DHCPv6([RFC3315]), IPv6 only with RA) the captive
   portal can provide the URI via multiple methods (IPv4 DHCP, IPv6
   DHCP, IPv6 RA).  The captive portal operator should ensure that the
   URIs handed out are equivalent to reduce the chance of operational
   problems. "

This seems very similar to the above....

W

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 21 Apr 2015 23:42:14 +0900

> be told, but this seems overly complex.

If you're using RAs, you can just include that in the RA option. RAs are
dynamic.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 21 Apr 2015 11:01:19 -0400

> If you're using RAs, you can just include that in the RA option. RAs are

Yeah, you *could*, but it seems to me to have the same issue - it
would be fairly complex, especially if the CP is not the device
generating the RA...

Also, what, multicast with one TTL for folk joining the network, and
then unicast to specific clients who have joined their unique time
remaining?

The CP functionality of often baked into CPE (for example, my
neighbor's Linksys has a "guest network" with CP functionality. It
only barely kinda works at the moment, and the v6 functionality is
similarly wonky -- getting it to send different RAs to different
clients seems like a bridge too far...

W