Re: [Captive-portals] customizing API URLs vs ???

Nicolas Mailhot <nicolas.mailhot@laposte.net> Wed, 31 July 2019 18:20 UTC

Return-Path: <nicolas.mailhot@laposte.net>
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 143611206A5 for <captive-portals@ietfa.amsl.com>; Wed, 31 Jul 2019 11:20:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=laposte.net
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 VTtlWOG8kRLy for <captive-portals@ietfa.amsl.com>; Wed, 31 Jul 2019 11:20:23 -0700 (PDT)
Received: from smtp.laposte.net (smtpoutz27.laposte.net [194.117.213.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7317B12067C for <captive-portals@ietf.org>; Wed, 31 Jul 2019 11:20:21 -0700 (PDT)
Received: from smtp.laposte.net (localhost [127.0.0.1]) by lpn-prd-vrout015 (Postfix) with ESMTP id 5A1A1276754 for <captive-portals@ietf.org>; Wed, 31 Jul 2019 20:20:19 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=laposte.net; s=mail0; t=1564597219; bh=MNWaopKKbAvaInphAoYr/gETJnnF4etOvfTieQSf1Jk=; h=Subject:From:To:Date:In-Reply-To:References; b=BomNDG1yQi6hKF6ezDzi1SigYFSRD6MDFLjoewmgwtfvjqj3vZ0Sc5oeOGYNpNu55 L1kW2cY3jGytHTBkUifuzpPN/N3IR9kIDj8PZhorLbBytD0nj5mfQIyUEZOkQME+TA X0DoLpIvptWUSeKZJ65EXZ6PNPBZ6ZdPmZVn1anWSiXwfSNJWjH6qhXaXq6cV2yBT5 6+eVHwus1Wgxzg5LhGc5meF/sFKnAlCyDhvhf0x7Ggbs6Iy6wtz92zavXCG+Hiyqif /WYVpi9aAcaiQ6L/AxpkV6FqS3xG/38k+f3PxCeLiD+Gsb7rBOogbV05IlQ+OX014w hTbiRLbk5zOFg==
Received: from smtp.laposte.net (localhost [127.0.0.1]) by lpn-prd-vrout015 (Postfix) with ESMTP id 4B4602767BA for <captive-portals@ietf.org>; Wed, 31 Jul 2019 20:20:19 +0200 (CEST)
Received: from lpn-prd-vrin001 (lpn-prd-vrin001.laposte [10.128.63.2]) by lpn-prd-vrout015 (Postfix) with ESMTP id 45EE4276754 for <captive-portals@ietf.org>; Wed, 31 Jul 2019 20:20:19 +0200 (CEST)
Received: from lpn-prd-vrin001 (localhost [127.0.0.1]) by lpn-prd-vrin001 (Postfix) with ESMTP id D53253736A6 for <captive-portals@ietf.org>; Wed, 31 Jul 2019 20:20:18 +0200 (CEST)
Received: from arekh.ddns.net (82-64-49-105.subs.proxad.net [82.64.49.105]) by lpn-prd-vrin001 (Postfix) with ESMTPA id 7725E373676; Wed, 31 Jul 2019 20:20:18 +0200 (CEST)
Received: from cerebro.okg (unknown [192.168.0.75]) by arekh.ddns.net (Postfix) with ESMTPSA id F1006220303; Wed, 31 Jul 2019 20:20:15 +0200 (CEST)
Message-ID: <99e64b26afc674f8411463b5ec55dde295e8c33d.camel@laposte.net>
From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
To: Michael Richardson <mcr+ietf@sandelman.ca>, captive-portals@ietf.org
Date: Wed, 31 Jul 2019 20:20:15 +0200
In-Reply-To: <16883.1564590555@localhost>
References: <CAKD1Yr32DXr8fYHP_x7z9pQWwSchey8zQW11vw02bW9ONEV8Kg@mail.gmail.com> <01ad5bf0-1f60-4dbb-aa83-31d14fce6082@www.fastmail.com> <CAKD1Yr08LmfDhmDLqpR87iQQ4Z61CVpR9BTDeRHobpsvVxFJvA@mail.gmail.com> <CADo9JyW6TmBnr5f0AuSXKnKMXnMxGhMkgYbGQ1WYOQjSMefy=w@mail.gmail.com> <CAKD1Yr1Zo0NQod=p4ZqT6fJYJ=Xqh1q8eJT2+ich+p7Jmg1WiA@mail.gmail.com> <CADo9JyX1T8AnxirXLfGdcJzmjvy5_UGJktnbYByAuO7H++y8uA@mail.gmail.com> <CAKD1Yr0C_KEUpGUC-wbAV-ufG_VpNposecmzNQU5rEXaCeSZNQ@mail.gmail.com> <26405.1564182227@dooku.sandelman.ca> <CAKxhTx_CngPfs3V8sZ5n0SYbTN4zcu3L_cvGuLpbLJOZYu-1Kg@mail.gmail.com> <14eba834-e18a-4324-8baa-3a8b90cdaec4@www.fastmail.com> <CAFaTyiG_LxmyaSvBcqKgkYb9-SiaMcDr1khPV7oV-AVs85_x8g@mail.gmail.com> <16883.1564590555@localhost>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.33.4 (3.33.4-2.fc31)
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-VR-FullState: 0
X-VR-Score: 0
X-VR-Cause-1: gggruggvucftvghtrhhoucdtuddrgeduvddrleehgdduvddvucetufdoteggodetrfdotffvucfrrhho
X-VR-Cause-2: fhhilhgvmecunfetrffquffvgfenuceurghilhhouhhtmecuhedttdenucenucfjughrpefkuffhvfff
X-VR-Cause-3: jghftggfggfgsehtkeertddtreejnecuhfhrohhmpefpihgtohhlrghsucforghilhhhohhtuceonhhi
X-VR-Cause-4: tgholhgrshdrmhgrihhlhhhotheslhgrphhoshhtvgdrnhgvtheqnecuffhomhgrihhnpehtvggrmhhs
X-VR-Cause-5: rdhnvghtfihorhhknecukfhppeekvddrieegrdegledruddtheenucfrrghrrghmpehmohguvgepshhm
X-VR-Cause-6: thhpohhuthdpihhnvghtpeekvddrieegrdegledruddthedphhgvlhhopegrrhgvkhhhrdguughnshdr
X-VR-Cause-7: nhgvthdpmhgrihhlfhhrohhmpehnihgtohhlrghsrdhmrghilhhhohhtsehlrghpohhsthgvrdhnvght
X-VR-Cause-8: pdhrtghpthhtoheptggrphhtihhvvgdqphhorhhtrghlshesihgvthhfrdhorhhgpdhrtghpthhtohep
X-VR-Cause-9: mhgtrhdoihgvthhfsehsrghnuggvlhhmrghnrdgtrgenucevlhhushhtvghrufhiiigvpedt
X-VR-AvState: No
X-VR-State: 0
X-VR-State: 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/MdE7mg_7o-MYLr17GDctT9zKDj0>
Subject: Re: [Captive-portals] customizing API URLs vs ???
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, 31 Jul 2019 18:20:27 -0000

Le mercredi 31 juillet 2019 à 12:29 -0400, Michael Richardson a écrit :
> Chris Spencer <chris.spencer@globalreachtech.com> wrote:
>     > Would not a feed of option 82 rather than create a new API
> work? option
>     > 82 can carry MAC/IP (it could create a GUID/UUID) and other
> location
>     > identifiers? if the external portal could get a feed of this,
> the
>     > portal at layer 3 could look up the device MAC from the option
> 82
>     > elements by the IP?  or if the DHCP server is centralised along
> with
>     > the portal architecture and DHCP relay is used on the local
> site?
> 
> Option 82 is usually inserted by a DHCP relay when forwarding to a
> centralized DHCP server.  It certainly could be used to customize the
> URL,
> but in many systems this isn't going to work.

[snip]

> It probably occurs less in places like airports, hotels and
> enterprises where
> there is more local operational clue.

In entrerprises the dhcp layer is mostly owned by desktop IT (ADs, in
the hands of people still stuggling to come to terms with the way
Microsoft adopted networking and the cloud with a vengeance) while
access to the internal network (or from the "safe" internal network to
the wild internet, or from low-security visitor networks to high-
security internal networks) is managed by network or security teams.

Network/security teams will want to plop the security portal in a
single tighly controled place (a datacenter, or a set of datacenters
for redundancy), while local/desktop IT would not care less about
security considerations (but then, they are not asked to care about
them).

Therefore, deep collaboration between local networking and the portal
is wishful thinking. The security dialog has to happen between the
client and the central portal, with as little constrains and smartness
as possible delegated to the local networking kit (ideally, just let
everyone talk to the portal, and let IP/Macs/whatever requires as
little effort as possible to identify a system talk to other network
ranges, as long as they match the whitelist published by the central
portal for those ranges).

-- 
Nicolas Mailhot