Re: [Captive-portals] A final check on draft-ietf-capport-architecture-09

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 02 September 2020 13:43 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 4B5F13A102D for <captive-portals@ietfa.amsl.com>; Wed, 2 Sep 2020 06:43:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 69O6uezidgaa for <captive-portals@ietfa.amsl.com>; Wed, 2 Sep 2020 06:43:06 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 181E53A0E57 for <captive-portals@ietf.org>; Wed, 2 Sep 2020 06:43:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 3BDB5389C3 for <captive-portals@ietf.org>; Wed, 2 Sep 2020 09:21:56 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dVSIs9qv2YXH for <captive-portals@ietf.org>; Wed, 2 Sep 2020 09:21:55 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5F854389BA for <captive-portals@ietf.org>; Wed, 2 Sep 2020 09:21:55 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9486C69B for <captive-portals@ietf.org>; Wed, 2 Sep 2020 09:42:59 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: captive-portals <captive-portals@ietf.org>
In-Reply-To: <CAMGpriXiwEWov__Ha+-t0vTiJnOCob=bpu_d2bqTV=8UwWq-_w@mail.gmail.com>
References: <b666d3af-fcf6-4534-be01-7e7441d0d6d2@www.fastmail.com> <CAMGpriXiwEWov__Ha+-t0vTiJnOCob=bpu_d2bqTV=8UwWq-_w@mail.gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 02 Sep 2020 09:42:59 -0400
Message-ID: <28902.1599054179@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/ccrXfn2gMSEhENq3XvpDzibLvzI>
Subject: Re: [Captive-portals] A final check on draft-ietf-capport-architecture-09
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 02 Sep 2020 13:43:13 -0000

Erik Kline <ek.ietf@gmail.com> wrote:
    > One thing I realized that we didn't discuss in 7710bis, and didn't really
    > discuss here either, is the issue of devices attached to routers which are
    > themselves on the link with the provisioning service.

So, I agree with the thread that the options need to be passed on like DNS.
I guess architecturally maybe this needs to be specified.

From an implementation point of view, the router, whether IPv4 NAT44 or IPv6,
acts as a layer-2 "NAT", keeping the policy enforcement point from seeing the
end device's L2 address.

As such, mechanisms that whitelist^Waccept-list the client by L2 address
won't work, or will work wrong.
I think that many of us geeks have the experience of throwing our own router onto
the hotel LAN, then accepting the Terms using our laptop, and sharing that
with our other devices.

That accept-lists the router for IPv4, but IPv6 won't work that way.
And now temporary addresses uses for privacy each get caught.

    > The section 2.5 captive portal signal might be able to come to the rescue
    > here, but as we don't have such a thing.

    > But...maybe that's a separate document?

Our current solution isn't perfect, but it is a significant step forward.
Let's worry about this situation later.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-