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

Erik Kline <ek@google.com> Tue, 23 May 2017 13:29 UTC

Return-Path: <ek@google.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 ADF15129B33 for <captive-portals@ietfa.amsl.com>; Tue, 23 May 2017 06:29:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 SreZ4gagYoO5 for <captive-portals@ietfa.amsl.com>; Tue, 23 May 2017 06:29:25 -0700 (PDT)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD176129B2E for <captive-portals@ietf.org>; Tue, 23 May 2017 06:29:24 -0700 (PDT)
Received: by mail-yw0-x22c.google.com with SMTP id p73so63482315ywp.0 for <captive-portals@ietf.org>; Tue, 23 May 2017 06:29:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bO27eN05ZML85d/YkmufyVixOLSdRJinApmdtmyUQTQ=; b=sYKVgUHx8SE73hF9NjX6FvRKmhQ6qCmbv6+NtQRMrxeffOItVJ5V+wGFdCuGMZI8ZH WSbXGfbxDGjVIfQHrRexKMr4owQN8mjrVoZXQMf5/rwN6oW5wkikKc3D10rR1umKFD2m +ZLF5FzlzSg89kmmT9NXlSF2hE/YSXvo+Qmz2FbQ2ZsAdtCm44j1RimPs1JoC6qBhbTP E/Wv/0z62P+mcZj5zBzKWeoGKQH30ZZLLJ0SNQtkfbsWYzmdVYyZguOtP2BgJEHq+d1r Fg9hv4VYOozMPdozBNmHnv7RTuj5sOuwXM49wfMsmhSaLvrzEfDIDVRjxPWrfNfSeasy Y5eQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bO27eN05ZML85d/YkmufyVixOLSdRJinApmdtmyUQTQ=; b=XcLFreOp84VMCc2mZUY+Iv4eA9SOwKgrCzr4sJWi5Si1Ma68wAWncSxCg+Ma0KqpNO MDUNDVotywR5LhjNARz+OV8k4cpSCzHVhuzKsF0pQPd02TaqLyBdUoSf3BLq2X4AJBNb ym8do9aE68bcOJDUmaMp8J0arHQBZdHSxB/w4esfCBCzCEzg67s8ai1CYdN2ug3RqP7C u0rONpKO7XrrAayNfy/dfHYqJp/Jgk7MR6AoePYb4umavr332xVfR20tsk+e2/LSW5jV H6zadC2bdKxtTVFGe3vCbAODoLgD2+3hG8cD44UWsDzOr7n76FKo6K/Lwjl7SNohpSYZ qoLg==
X-Gm-Message-State: AODbwcDv2Ib1vs2VK8PmuqeWOZUIzYFrToW3oBXEM5/SqgnP/4M2A4Oj dVxCU6yffcqL9Q8kv/KJUO+sGPKX+Unx
X-Received: by 10.129.173.74 with SMTP id l10mr22427944ywk.114.1495546163859; Tue, 23 May 2017 06:29:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.50.77 with HTTP; Tue, 23 May 2017 06:29:03 -0700 (PDT)
In-Reply-To: <D2A19ABBC0147C40BFBB83D1CF3E95F03FEF271B@wtl-exchp-2.sandvine.com>
References: <201705031442.50683.heiko.folkerts@bsi.bund.de> <8951dd0a-044b-b3ed-4454-e24fac407c4e@netcologne.de> <CADo9JyVdkzrtWE6RMt3CVYCkHrdB=+LKA9eDazN8Xf+R=Vza_Q@mail.gmail.com> <7e4e6be2-3f2e-897e-4c7b-0374f0b7b0b5@netcologne.de> <D2A19ABBC0147C40BFBB83D1CF3E95F03FEF271B@wtl-exchp-2.sandvine.com>
From: Erik Kline <ek@google.com>
Date: Tue, 23 May 2017 22:29:03 +0900
Message-ID: <CAAedzxr0N81R9-v76R2kQ4dFbOF+Q1souR61=9-TeXVLAAwH7Q@mail.gmail.com>
To: Vincent van Dam <VvanDam@sandvine.com>
Cc: Gunther Nitzsche <gnitzsche@netcologne.de>, David Bird <dbird@google.com>, Heiko Folkerts <heiko.folkerts@bsi.bund.de>, "Herzig, Willi" <willi.herzig@bsi.bund.de>, "captive-portals@ietf.org" <captive-portals@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="f403045ea6f6dc9626055030f941"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/p7m0qZOMbwj-uJRUS5rcIRlDxAE>
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: Tue, 23 May 2017 13:29:27 -0000

On 19 May 2017 at 05:33, Vincent van Dam <VvanDam@sandvine.com> wrote:

> > > The separation of "configuration" and "notification" is by design.
>
> > That might be a design error.  Notification is done by the provider, but
> configuration (how to react
> > on e.g. icmp unreachable) is up to the enduser. The provider cannot (and
> will not) configure
> > any customer's client device. Maybe the CPE can be (pre-)configured
> (cable-modem/dsl-router) but
> > not the home-PC. How do I tell the home-PC to open up a specific URL
> when capport
> > detection gets activated (if it would exist)?
>
> The url is not included in the icmp payload as it would introduce a ddos
> security risk.
>
> Good point. In the home-network realm, advertising the url using dhcp
> would also require the CPE to propagate this url to the home network. I
> agree this would be challenging.
>
> Maybe we can learn/inspire from the “Proposals to discover Provisioning
> Domains” draft that was shared with this wg earlier this year (
> https://tools.ietf.org/html/draft-bruneau-pvd-00; note it has been
> replaced). This draft tackles a similar problem, discovery of the
> configuration url. In this draft the authors define in chapter 3, they
> could retrieve what they required by using the “Fully Qualified Domain Name
> which belongs to the network operator” (chapter 3). And later (4.2) they
> specify a fixed location where this information can be fetched. Maybe we
> can use a similar approach. If the UE doesn’t have the url as it would have
> been advertised in the dhcp, retrieve some config from a fixed url based on
> the fqdn that belongs to the operator?
>

That necessitates a UE-side change.  Learning a captive portal URL by means
other than DHCP (which would require router changes as well to somehow
propagate the information into a multi-hop home) certainly does seem worth
considering.

But I'm assuming that operationally HTTP intercept and redirection will
have to persist, until un-upgraded UEs are somehow not worth the effort.