Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

Dave Dolson <ddolson@sandvine.com> Mon, 10 July 2017 15:54 UTC

Return-Path: <ddolson@sandvine.com>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0CAF1317BD for <captive-portals@ietfa.amsl.com>; Mon, 10 Jul 2017 08:54:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MARKETING_PARTNERS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpCkhMRu6SLe for <captive-portals@ietfa.amsl.com>; Mon, 10 Jul 2017 08:54:25 -0700 (PDT)
Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C17141317C4 for <captive-portals@ietf.org>; Mon, 10 Jul 2017 08:54:24 -0700 (PDT)
Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-2.sandvine.com (192.168.194.177) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 10 Jul 2017 11:54:22 -0400
Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by blr-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Mon, 10 Jul 2017 11:54:22 -0400
From: Dave Dolson <ddolson@sandvine.com>
To: David Bird <dbird@google.com>, Tommy Pauly <tpauly@apple.com>
CC: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, "captive-portals@ietf.org" <captive-portals@ietf.org>
Thread-Topic: [Captive-portals] Use Case: "Carrier Grade Captive Portal"
Thread-Index: AQHSxAspm2jwFnBWgkqjQKiot+mYpKHim5WQgAHxpYCAKua1AIAALgAAgAJV74CABl/BAIAI6m4AgAOfPACADjOEMIADVqkAgAMFLHCAEevbAIACYi0A///YbYA=
Date: Mon, 10 Jul 2017 15:54:21 +0000
Message-ID: <E8355113905631478EFF04F5AA706E9870638DFD@wtl-exchp-1.sandvine.com>
References: <201705031442.50683.heiko.folkerts@bsi.bund.de> <E8355113905631478EFF04F5AA706E98705C6C57@wtl-exchp-1.sandvine.com> <CAHw9_iJARf4MUA8nHqHA54jLvJNq-_Vek67A-rjHpSK6vC7r+Q@mail.gmail.com> <1BB90528-B35F-43F0-AF18-0215DC735FF0@cable.comcast.com> <CABkgnnWT6Xtqyx6pofpNOGa5E1FjJO1gPX1axmmiRaMnzxdoPg@mail.gmail.com> <AD3F2B14-E9AD-4156-96A6-9B83F8545B54@cable.comcast.com> <754719c5-c74c-fbdc-405e-b8c91478c0a5@netcologne.de> <CAAedzxoZkuauME8n3B3aZqE1rra8p2hB9rGJLqoYyVi8usnx+g@mail.gmail.com> <CADo9JyVsfVYTPQjHiEn1JcJ=_NzOOvtWjbuCZdQ-4jsRPpz2wQ@mail.gmail.com> <E8355113905631478EFF04F5AA706E987061FACA@wtl-exchp-1.sandvine.com> <CE7B0AC2-8803-41B5-9B0B-EB1217A5A8EC@cisco.com> <E8355113905631478EFF04F5AA706E98706252AA@wtl-exchp-1.sandvine.com> <E4CEB868-5100-4F7E-8AB7-2826F56D4BA7@apple.com> <CADo9JyWZCqdgS6PYrFoin-QBL2OZQqm3s9JyU=sn6T1CWBaesQ@mail.gmail.com>
In-Reply-To: <CADo9JyWZCqdgS6PYrFoin-QBL2OZQqm3s9JyU=sn6T1CWBaesQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.200.114]
x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794
Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9870638DFDwtlexchp1sandvi_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/XTSH6u-0-K14NAXUiGkzHaqUTx0>
Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Jul 2017 15:54:35 -0000

David,
Is it fair to say your concerns are mainly about misconfigured networks?
And this is the reason that devices will always be incented to probe regardless of any method of provisioning?

-Dave


From: David Bird [mailto:dbird@google.com]
Sent: Monday, July 10, 2017 9:39 AM
To: Tommy Pauly
Cc: Dave Dolson; Eric Vyncke (evyncke); captive-portals@ietf.org
Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

On Sat, Jul 8, 2017 at 6:14 PM, Tommy Pauly <tpauly@apple.com<mailto:tpauly@apple.com>> wrote:
[snip]
The idea with explicit PvD discovery is that it would, as a step, replace a separate captive portal detection strategy.

My overall concern with discovery mechanisms that are specific to only captive portals is that this is an extra step that is performed potentially on every network association, that may have limited extensibility for non-captive use cases. Since the explicit PvD design promises a way to discover many properties beyond captivity, and is bootstrapped very early on in the network association, it should hopefully allow clients to avoid the extra probe.



I have concerns with the PvD approach, as described.

If a network was misconfigured to advertise a PvD that does have a (Internet based) HTTPS server with a JSON file on it describing a captive portal network, then devices utilizing the PvD information will *never* get on this network while devices not using the PvD information do. That could be very confusing to users and network administrators alike.

If you have seen walled garden configurations for large networks, you will notice a lot about the network operator's marketing partners. Indeed, many walled gardens are much larger than the network really wants... sometimes they just need to make things work in the garden. My point here is that operators may not *want* to list out their walled garden configuration on a public JSON file...

At the end of the day, I'd argue that the client *will always probe* -- wether it means to or not... A networking using PvD could just advertise all networks routes are available so that the device connects only to get caught up in a captive portal redirect anyway... back to step 1 and captive portal detection..

I'm also unclear how PvD would deal with scenarios where you might start out with internet connectivity (e.g. "MAC Authentication") then to have a captive portal return after a session timeout has occurred...





Note: the same “captivePortal” key is also defined in section 5.3 as a Boolean. Should I consider this to be a defect in the draft, or am I missing something?

The updated version of the draft (https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-domains-01) leaves out the specific keys for captive portals, and discusses it more abstractly. That would be a good thing to nail down at the Prague meeting. If PvD detection is done generically on network association, then a boolean or some way to indicate that this is *not* a captive portal will allow the device to not perform extra probing. If there is a captive network, we should be able to get the page or instructions on how to get beyond captivity.

Thanks,
Tommy




-Dave



From: Eric Vyncke (evyncke) [mailto:evyncke@cisco.com]
Sent: Sunday, June 25, 2017 8:27 PM
To: Dave Dolson; captive-portals@ietf.org<mailto:captive-portals@ietf.org>
Cc: David Bird
Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

At least Erik Kline and myself are following the captive-portal list :-)

And the more we think about it, PvD could really be useful and we, the PvD I-D authors, would be pleased to present at your WG

-éric

From: Captive-portals <captive-portals-bounces@ietf.org<mailto:captive-portals-bounces@ietf.org>> on behalf of Dave Dolson <ddolson@sandvine.com<mailto:ddolson@sandvine.com>>
Date: Friday 23 June 2017 at 11:57
To: "captive-portals@ietf.org<mailto:captive-portals@ietf.org>" <captive-portals@ietf.org<mailto:captive-portals@ietf.org>>
Cc: David Bird <dbird@google.com<mailto:dbird@google.com>>
Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

[resend with fewer recipients to avoid mailing list problems]

To echo David’s request,
> If the authors of the PvD concept (re-)present their I-D to the mailing list, and stick around for discussion, that would be helpful.


From: David Bird [mailto:dbird@google.com]
Sent: Wednesday, June 14, 2017 9:36 AM
To: Erik Kline
Cc: Gunther Nitzsche; Mark Townsley; Heiko Folkerts; Martin Thomson; captive-portals@ietf.org<mailto:captive-portals@ietf.org>; Livingood, Jason; Herzig, Willi; Warren Kumari; Dave Dolson
Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

On Sun, Jun 11, 2017 at 11:17 PM, Erik Kline <ek@google.com<mailto:ek@google.com>> wrote:
I'm not sure we have enough input on whether 511 is useful or not.  There seemed to be some suggestion it would help, and some that it wouldn't.  Perhaps one question we could ask is whether it's harmful?  And if we agree it's not harmful, is it worth developing some recommendations for its use?


In of itself, I don't believe it is harmful. However, if vendors use it as a reason to continue to terminate TLS connection in order to deliver the 511, then perhaps it is a bit harmful - or at least misleading. As the world moves to TLS (and QUIC), I think the time for the 511 code has already passed, to some degree. That, combined with the fact you may still have browsers not handling that return code properly, I don't see the value for any vendor or venue to implement this.


As for the ICMP unreachable option, I certainly don't think it would be harmful (with the extra URL bits removed for now).  Is that something we wish to progress?


I will work on a new draft that is only the basics. The additional fields could always be add in their own draft as extensions.


Given that we're probably looking at a portal detection method based on entirely new work, it seems to me we're free to look at new things like utilizing the PVD detection scheme (DNS queries for "provisioning domain names", followed by other interaction still TBD).  Have the portal implementors reviewed this and given consideration as to whether its useful?  (I think of the discovery of the portal and subsequent interaction with it as 2 separate processes conducted, obviously, in serial.)


I believe there are several talking points here, as the PvD method seems to have several possible implementations.

I think requiring Ipv6 to configure Ipv4 is weird (I believe that was one proposed method to convey configuration)

Several points I made in the thread "Arguments against any Capport API" regarding a web service - detached from the NAS - controlling the UE/station I think are relevant.

If the authors of the PvD concept (re-)present their I-D to the mailing list, and stick around for discussion, that would be helpful.


Thoughts?

_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org<mailto:Captive-portals@ietf.org>
https://www.ietf.org/mailman/listinfo/captive-portals

_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org<mailto:Captive-portals@ietf.org>
https://www.ietf.org/mailman/listinfo/captive-portals