Re: [Captive-portals] Fixing RFC 7710

Ólafur Guðmundsson <olafur@cloudflare.com> Fri, 02 March 2018 21:59 UTC

Return-Path: <olafur@cloudflare.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 620EB124239 for <captive-portals@ietfa.amsl.com>; Fri, 2 Mar 2018 13:59:01 -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, HTML_MESSAGE=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 (1024-bit key) header.d=cloudflare.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 kn_4OI-wTKEz for <captive-portals@ietfa.amsl.com>; Fri, 2 Mar 2018 13:59:00 -0800 (PST)
Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (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 A951D12025C for <captive-portals@ietf.org>; Fri, 2 Mar 2018 13:58:59 -0800 (PST)
Received: by mail-wr0-x22b.google.com with SMTP id v111so11504784wrb.3 for <captive-portals@ietf.org>; Fri, 02 Mar 2018 13:58:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=D7sXX8fwC3m94BE7e+NUt8Lx8gbXoMFf1Gn/LPbp20w=; b=s98aXvjpS9WTO5pEd46Xl19iFMY0+YivsQj+YBBVe5A2WXIv2P8tRWYqRpYpAT7nut vR8w/nxXOZhhi20GNGUa/6To9TcL3M9CIrPDV4jbVEZ9O06hVQxWKZXG9585c8FTsGsj 7a+Oa2f3Vxa+/dVTyuwdLpcm9I1GQvJnLn4xE=
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=D7sXX8fwC3m94BE7e+NUt8Lx8gbXoMFf1Gn/LPbp20w=; b=KavNwp7nSyLU1ZfljfOlLnbvOwztVETbpIbGvSKakQFd8GH+cS/B+ki67JHr4CQRST aueT0JnLUWMil/8XjwtpIQ1MTdm1BGMH6UACsAdpqs0C2g9pVQw1yjy1C22fObBHjBZs Cb4kDGwrqLit+Ia4Z+q5CDyrRhBk6M5osJk8Ne5IqNP6d/i7sA+t9rhzVY4guXDZx9ix xjsCFqLpIEzjuTFWiPBc4hkeg2ItebgmkmfLTVuq7l8AZwzCnFUl4lMDJUv1h5/YcwdI 7zZd+sU0yFPKNTKspevnGrT3gZ5hWVAhPlJtq77poxyyR17hhHh0lFW3Lfr3O6tjI7hR Y0wg==
X-Gm-Message-State: APf1xPD0YjNecv3DRNypWeSne2F9jXknOX4xYhd6G63TbLJAP3SYoLxs LVpRWE0MtKn+aNjuzlH2fSRCIjtGVKaE62rvT63F4w==
X-Google-Smtp-Source: AG47ELvixuAgeWzgq3j5VrMu94LiMZrTrAQMSO6jtmYUbhqJIchTQ6ClJ3qurvotMDRYIfJBnip2E697A3cepoe4azw=
X-Received: by 10.223.147.227 with SMTP id 90mr6135327wrp.230.1520027938013; Fri, 02 Mar 2018 13:58:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.209.146 with HTTP; Fri, 2 Mar 2018 13:58:57 -0800 (PST)
In-Reply-To: <CABkgnnWJMipRtG-p0EoUXmK3u1c2ab-v4xN3WZfm3XL8s08aZA@mail.gmail.com>
References: <CABkgnnWJMipRtG-p0EoUXmK3u1c2ab-v4xN3WZfm3XL8s08aZA@mail.gmail.com>
From: Ólafur Guðmundsson <olafur@cloudflare.com>
Date: Fri, 02 Mar 2018 16:58:57 -0500
Message-ID: <CAN6NTqys4p_nQq=by0xkAtEGBj4Smzk0URK1EmisFK8_TLRRSQ@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.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: multipart/alternative; boundary="94eb2c0df1444b5865056675159f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/FhTqWlKvhUITqcY7vYQEGoW9puA>
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: Fri, 02 Mar 2018 21:59:01 -0000

On Thu, Mar 1, 2018 at 10:58 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> We've had a number of discussions in the captive portals group about
> fixing RFC 7710.
>

Fixing or make RFC7710 more useful ?


>
> 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.

Now you are taking that basic idea forward to allow a handshake between
device and portal ; this is good
Happy to help with that anything that allows [semi/fully]-automated sign-on
is great.

2. There isn't a clear way to signal that there is no captive portal
> in the network.  It has been suggested that we use a special URL -
> e.g., urn:ietf:params:capport:unrestricted. Alternatively, we could
> privilege the empty string, but that doesn't have as clear a signal of
> intent.
>
> This seems to be a standard problem in DHCP i.e. there is no way to issue
a denial or list available options


> 3. RFC 7710 states that the URL SHOULD use an address literal.  This
> works at odds with the idea of using HTTPS.


If there is a better way then this is the reason to do an RFC7710-bis,
the items above only need to CITE RFC7711, and there could be more than one
API proposed/documented.


>
>
Is there anyone who is willing to take on this work?  We aim to start
> and complete this work in <1 meeting cycle, starting in London.
>
> This is a great goal, willing to review


> For the authors of RFC 7710, let us know if you have any concerns.
>

not really, thanks for pushing the idea forward.

Olafur