Re: [Captive-portals] Review of draft-ietf-capport-rfc7710bis

David Bird <dbird@google.com> Thu, 25 July 2019 14:10 UTC

Return-Path: <dbird@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 78D6C1202DA for <captive-portals@ietfa.amsl.com>; Thu, 25 Jul 2019 07:10:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 WbUesBllzKEK for <captive-portals@ietfa.amsl.com>; Thu, 25 Jul 2019 07:10:06 -0700 (PDT)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 F3BF312028F for <captive-portals@ietf.org>; Thu, 25 Jul 2019 07:10:03 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id v24so48235481ljg.13 for <captive-portals@ietf.org>; Thu, 25 Jul 2019 07:10:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UBTkrYfUzBtm/RGdGFtpnfOPYKdNo/P6ru1JkBhAMMc=; b=tMODYmAtqgmoIu/0cNOon9RDqjFXiyTnzyp8r+JHag5Xzln34SRSILfIVgScFldcJZ ItWwTNHrelPp2wPR59JPmymx86qQHmJjMxRqIJbXVqz5h486Yo9lS2xGpbYt6ZgyJ6DS Z1iNCDxjnWKRmc6yvUeZ6NomycyXnlzNlb34wQOvNPkIMCY0pBFkJNsxQsTHUZkQC8CY 7DNE2uKXVC2gCyGrzRmErqoPzkkIBjv3TbzH+fjlB5EuYwOeSsDJS44nzxmfZZ27VUTh Mrzhiy2FZWYorlAF7/ab8HS6tabdtLPy1JALpF87Ta1g8woXGQBSAYq2gCcRFo/D5RiG GiWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UBTkrYfUzBtm/RGdGFtpnfOPYKdNo/P6ru1JkBhAMMc=; b=sil+K41COQWXFjg+sWGSzcCHYrIq8A7GJyofXddwpIxBqQtuH5+MykxHkWNt0exJSx fSDR5HfVAfiEQlhbxRwEH9IAHHhku57nUoQo3tot8shCdEoGve+bbxKWzQe83kirnqxf vfwQx/50jE/GGUCikf5jESvgXwG14s3HY6ytvTeJTcM3lTNWWABGpW0fR9xatr2+Xd+j x0C2I2Q7C3ES1UQXZuAv59sOo6JLpCgH8MVx/UmFUJYKqWf35ozfbhG9fChrWv/i+pzr kvZ+DyFy4KHqe69qq/zlR+OAZWBi6Hl7X63bagXJq1gaa0PsM7MKIBpyHvMZ2jvgrjDW 3Kvg==
X-Gm-Message-State: APjAAAWQ7QAe0ei7Gm90Ye6TBoMp6i77wZ9GKyxSxOtBErsjP8YkWwUy w9Zy3T+F6ga47aC/jSXToBtyfym5murmvMT8PkU9m5YJqRI=
X-Google-Smtp-Source: APXvYqy4UmQl3y4yEmZgfAfTC72sqfj9SZeivnKPV2nb1gf/1c8jw0oaY9CqHdq9T9PVgx5WqCuQ3K2GJ3N5Ha6K21k=
X-Received: by 2002:a2e:5b1b:: with SMTP id p27mr44973002ljb.97.1564063801664; Thu, 25 Jul 2019 07:10:01 -0700 (PDT)
MIME-Version: 1.0
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> <bb3dea12-294d-4a68-82b4-cc487f242f19@www.fastmail.com> <CADo9JyWZ0YjXUky+m_PDWc8BrjFVzOvs6XmjqUcV18hbPE_BpA@mail.gmail.com>
In-Reply-To: <CADo9JyWZ0YjXUky+m_PDWc8BrjFVzOvs6XmjqUcV18hbPE_BpA@mail.gmail.com>
From: David Bird <dbird@google.com>
Date: Thu, 25 Jul 2019 07:09:50 -0700
Message-ID: <CADo9JyXT1+Vopz_u1XjQABkzGLvCdoBs9ePXXNANaZ8FTf4_0A@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: captive-portals@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004e4a6e058e81fbd0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/uwNxuDnqIUgVgWIoLqlMNyYG0VA>
Subject: Re: [Captive-portals] Review of draft-ietf-capport-rfc7710bis
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: Thu, 25 Jul 2019 14:10:12 -0000

Expanding on that Cisco example for a minute....

How would Cisco implement 7710bis and API?

It would make sense for Cisco to implement the API server directly into
their WLAN controller... In that case, it probably could use the same URL
for the API server for all subscribers (and be in a position to uniquely
identify the session and lookup internally its state).  [As I've argued
before, the NAS/WLC is the *right* place for capport notification - or API
- mechanism because it is the ultimate source of truth for the state of the
session -- it is, after all, the one doing the enforcement].

However,  who would own the API SSL cert? Often times, the "hotspot
services company" isn't the owner of the WLAN Controller. Ideally, the
venue is buying their own certs and installing them in their own gear..
but, is that what will happen in practice? I could also imagine that
hotspot services companies will see the API an extension of their service
and want to control it... so, my question is, how will vendors implement
this?

On Thu, Jul 25, 2019 at 5:56 AM David Bird <dbird@google.com> wrote:

> Hi Martin,
>
> The "this" refers to uniquely identifying the UE/session. The API server
> will need to "lookup" the UE/session in some way (like in a database shared
> with AAA) to get its state (captive or not, how much time/data remaining,
> etc). In this regard, the API and the Captive Portal itself *both* need
> this ability to uniquely identify the UE/session.
>
> Sure, one *could* design an API server, to reside on the same L2 segment
> as the subscribers, so that it can determine the UE mac address from
> looking up the remote IP address in the local ARP table. But... in
> practice, I think the tendency would be to host the API in the same
> centralized place as the captive portal itself (and share the same
> database).
>
> In terms of generating a "session-id" ... a lot of this is very
> implementation dependent. For example, many hotspot systems are integrated
> with DHCP/RA because the IP address of subscribers may come from AAA (or a
> PGW in 3gpp). The redirection URL is often "minted" with the right
> session_id for that session by the backend AAA/PCRF.
>
> Here is one example:
>
> https://www.cisco.com/c/en/us/td/docs/wireless/controller/7-5/configuration-guide/b_cg75/b_cg75_chapter_01011101.pdf
>
>
> On Thu, Jul 25, 2019 at 4:31 AM Martin Thomson <mt@lowentropy.net> wrote:
>
>> Hi David,
>>
>> On Mon, Jul 22, 2019, at 19:40, David Bird wrote:
>> > ultimately a "session-id" is
>> > typically carried in the redirect URL on a per UE/session basis. If
>> > everyone gets the exact same URL, this can only be done by IP address
>> > at the portal... Is that the design networks are encouraged to take?
>>
>> I'm not following your "this" here.  Can you say more?
>>
>> I understand that a session ID is needed, but is this something that can
>> be inserted on the transition from the API endpoint to the web page?
>>
>> _______________________________________________
>> Captive-portals mailing list
>> Captive-portals@ietf.org
>> https://www.ietf.org/mailman/listinfo/captive-portals
>>
>