IETF Logo Mail Archive

Re: [Captive-portals] Fixing RFC 7710

Martin Thomson <martin.thomson@gmail.com> Sun, 04 March 2018 22:46 UTC

Return-Path: <martin.thomson@gmail.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 1B69B124217 for <captive-portals@ietfa.amsl.com>; Sun, 4 Mar 2018 14:46:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 vJ79Geq1P_n7 for <captive-portals@ietfa.amsl.com>; Sun, 4 Mar 2018 14:46:35 -0800 (PST)
Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (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 A1244120227 for <captive-portals@ietf.org>; Sun, 4 Mar 2018 14:46:35 -0800 (PST)
Received: by mail-ot0-x22a.google.com with SMTP id l5so13316097otf.9 for <captive-portals@ietf.org>; Sun, 04 Mar 2018 14:46:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=R3+WkaWV5h2Fd9P9+iElEEsimLrr3uT3Xtp5ofO5vUw=; b=gVUbwwlI0mKVXQe8W3XVI8R+P9DPw4EsJH0EOyCtYW5k80c7VVLj/6zbXmTi3VNwvv fR/wKgDgQBoGfJw59dnEycleyZq71Ap4QcCWnaugix+cyi0Ihhe4R+wh+yjDBA1tZdrt CyP+xECs5gpzqVAapf0vggTGkhyD7FhPQiwBse8zTJRRYUPePP8d2xbuZi6GYRbd+ZZN XZIpyqYL2k7Fnm45FcDVWyqSlZu8QCZsp2BfjwCHDkjbckwjLG0ehJ/O2pBe+y2Etcjq M7WaysaRZ8eAkHUPPmAUPTyDJhtEqxO8vx27on3rO6V31e7gU8UkkJEE0OU75tqY7H0/ 1C8A==
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:content-transfer-encoding; bh=R3+WkaWV5h2Fd9P9+iElEEsimLrr3uT3Xtp5ofO5vUw=; b=hjAs3TrtB4d+ibKQ7JRQ3FylB2VFLBveBym0EqDKhKpnCdpeXweIc8mbO+jSY30/5g XKPXEJMsY8Sq3gnmLCzUxM7lWyZsXlKsgw9MN2jWUpqwrbTk/M90jCZEFCaDPdfSJTjk xi4gASMP8xKo3Fd7S4TbUHlFA9K5vTwqYZZkv4qV2VbfH/AU9/ssDiQYvdpQOd96IeSl PhBj2HXoqUBfGfZeiZzrmIH0RXIAtJIbclLsloLPhxMx4rSo4Z/uMF0ImnPbB2EVM+aq N4ySpLxRn/dbCfUS3tDqLCEy+NLEloU5yvErDusXtS1k0l6Xjz3oF0TD3ygugt+bQBIJ X8WA==
X-Gm-Message-State: AElRT7FCLvb6H7hNISdbCLnIYqXjM8SNxFAg9NY5aXtaxgaXwcAWYSRW q+FjMlH7kiwpcalBG/DrcY3cldhcaE/YGzXTSkE=
X-Google-Smtp-Source: AG47ELuMybXT/UrVLdJyYNDvPAVaxpLnP+Xe3p9y87CdJ24pIbU18ALwWD/IHNya4HJY+HlMusqEBrZoGPSQlV+bugw=
X-Received: by 10.157.12.229 with SMTP id o34mr9481616otd.352.1520203594954; Sun, 04 Mar 2018 14:46:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.16.85 with HTTP; Sun, 4 Mar 2018 14:46:34 -0800 (PST)
In-Reply-To: <CAN6NTqys4p_nQq=by0xkAtEGBj4Smzk0URK1EmisFK8_TLRRSQ@mail.gmail.com>
References: <CABkgnnWJMipRtG-p0EoUXmK3u1c2ab-v4xN3WZfm3XL8s08aZA@mail.gmail.com> <CAN6NTqys4p_nQq=by0xkAtEGBj4Smzk0URK1EmisFK8_TLRRSQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 05 Mar 2018 09:46:34 +1100
Message-ID: <CABkgnnVsr5AWbB9GJFR53tg_5BRh6RcDPJ6eGRLjbufwxB-duQ@mail.gmail.com>
To: Ólafur Guðmundsson <olafur@cloudflare.com>
Cc: captive-portals@ietf.org, Warren Kumari <warren@kumari.net>, Paul Ebersman <ebersman-ietf@dragon.net>, Steve Sheng <steve.sheng@icann.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/bMJwc2sZ0bLZpniC23ezIsnQ1dQ>
Subject: Re: [Captive-portals] Fixing RFC 7710
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: Sun, 04 Mar 2018 22:46:37 -0000

On Sat, Mar 3, 2018 at 8:58 AM, Ólafur Guðmundsson
<olafur@cloudflare.com> wrote:
> Fixing or make RFC7710 more useful ?

Both, I hope.

Thanks for your reply.

>> Erik and I would like to propose a plan for that work.  We would keep
>> this to addressing the issues that we have identified thus far.
>> Namely:
>>
>> 1. The purpose of the URI is not well defined.  We would reference the
>> capport architecture and API documents for that.  The group would need
>> to decide between:
>>   a. point to the API
>>   b. point to a login page
>>
>
> Our (or at least my thought) was in the beginning,
> just send the device to the location of the portal, as I hate having
> connections intercepted.
> Then the USER could just see that page and decide what to do.

I think that the idea is this:

If the URI is the special one, then the process is done and the
network good to use.
If the URI is special, find the API and check status.  If the portal
says OK, then the network is good to use.
If the API returns captive, open the login page in a browser.

We don't have any more automation than this, but you will observe that
there isn't any probing.  The network can make a clear statement
quickly an unambiguously about access.  If the situation is more
complex (as we have seen that it often is, then it can use the login
page to convey that additional information).

v2.23.0 | Report a Bug | By Email