Re: [Captive-portals] WGLC on draft-ietf-capport-architecture and ...-api

Kyle Larose <kyle@agilicus.com> Mon, 30 March 2020 12:17 UTC

Return-Path: <kyle@agilicus.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 8A0E23A150B for <captive-portals@ietfa.amsl.com>; Mon, 30 Mar 2020 05:17:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=agilicus.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 7e-ycIrdLa-G for <captive-portals@ietfa.amsl.com>; Mon, 30 Mar 2020 05:17:32 -0700 (PDT)
Received: from mail-il1-x144.google.com (mail-il1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) (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 DA7DC3A14DF for <captive-portals@ietf.org>; Mon, 30 Mar 2020 05:17:27 -0700 (PDT)
Received: by mail-il1-x144.google.com with SMTP id k29so15504854ilg.0 for <captive-portals@ietf.org>; Mon, 30 Mar 2020 05:17:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agilicus.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=8lzrTeMlmRrL4aN+8kUMVvCBxk8ebI3N0FFuh2k+tDY=; b=T3FEUG92etEWpm4524TwEvqFiKFYonJK7NesntXog9kdfKmLc6SLJ/0yNE8IECJHWF UwqUE4EDR+yY+uCDLrog1NaZEIyEhHVLo8B4cYHVMIEH1hq8Ev6WmzTBB0yNk4mW8WXx bO3KUIVTf/2bnyKsAExukdiIqtBBu4FnzaZ4uhQ1n+MruMOijHA2ZNeZFskMeR4WBoVv 1JVf+BdIsuo+LEQIPakLWLDQS96alqU0aDiuFrSwb5DONB8p0iEp2j2cP/bAzjlE1OaO CXkc37CACUq4YROgMHCgPpVXh/t/IsARXdZhdUaa0AZDT0p9X0cxqUy6+NVjCjF0j+OZ drQQ==
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:content-transfer-encoding; bh=8lzrTeMlmRrL4aN+8kUMVvCBxk8ebI3N0FFuh2k+tDY=; b=nAy5edLh9uACd+XvFU4F+GH+CTTUEQHqfDFsgRCC6uov9dlyJnUMWe0xhYW2fMlvQt QmLomB8FAeWFHx1TqMdqbbl7xQ3ZVovlR6DIH+E6q/OgKgsEW/jeyXOHec8qmekdG1/P rf5d1WpPi2B/MwKR2jEtacnxqA0fcjJDjIHqJW5DHe4z2oRsZVfepJp58uj1sndAq9eT yk/3BBHwkC4lE1EIoivoltbbujtCFcwTjNvoEURvEEqE20TyIK49Ua1G8vStufx/kO1R csiPwyOrkaz3jaQqpLlJim432yk0/6eLz2drhZQ2bqb+LURunoDV1AAxbCFKW/Ko4E8k yOkQ==
X-Gm-Message-State: ANhLgQ2ezXbQsuPOsuJdO6d8MA1GHGoWss2dkGugOR7RIRQWPAZscRie hcHaTiTdDC+1sRcu6KNmXyD6OZJlttLDfshvablO
X-Google-Smtp-Source: ADFU+vuJ9YQoKrFJN2c8KgCHa1l4ZFWga+tIuOjDHMCRbrk9sXL8yF0nVBsmnoP9INQnQeaEqJmkFAeVyUOs1BsPAZ0=
X-Received: by 2002:a92:9c54:: with SMTP id h81mr11097191ili.109.1585570646875; Mon, 30 Mar 2020 05:17:26 -0700 (PDT)
MIME-Version: 1.0
References: <6c3d2931-f8fc-4724-a5aa-81062be9a51e@beta.fastmail.com> <1fceca08-743c-87a2-521c-37276ba34aab@cis-india.org> <99f2c4eb-d59b-46c9-8ddb-e728c9937422@www.fastmail.com>
In-Reply-To: <99f2c4eb-d59b-46c9-8ddb-e728c9937422@www.fastmail.com>
From: Kyle Larose <kyle@agilicus.com>
Date: Mon, 30 Mar 2020 08:17:16 -0400
Message-ID: <CACuvLgwb85WeaFO=76vRi3zoprY_tTcFbH942pW+zJ=dnRCgDw@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: Gurshabad Grover <gurshabad@cis-india.org>, captive-portals@ietf.org, Heng Liu <liucougar@google.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/iK0BCvMey_kTx6UACAqEeclxheE>
Subject: Re: [Captive-portals] WGLC on draft-ietf-capport-architecture and ...-api
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: Mon, 30 Mar 2020 12:17:40 -0000

Thanks Martin,

It's unfortunate that we weren't able to better expand on the signals
section, but if the section is confusing or misleading, we probably
should reduce it to something like you've suggested. I think that text
captures the essence of the signal. I'll submit an issue to change it.

On Wed, 25 Mar 2020 at 00:53, Martin Thomson <mt@lowentropy.net> wrote:
>
> Thanks for doing this Gurshabad.
>
> I think we've debated the removal of the signaling section on a number of occasions.  Could this text perhaps be reduced to something simpler, especially in light of our decision not to specify anything?
>
> Perhaps:
>
> --->8--
> When User Equipment first connects to a network, or when there are changes in status, the Enforcement Device could generate a signal toward the User Equipment.  This signal indicates that the User Equipment might need to contact the API Server to receive updated information.  For instance, this signal might be generated when the end of a session is imminent.
>
> An Enforcement Device MUST rate limit any signal; User Equipment MUST rate limit attempts to contact the API Server; see Section 7.4.
> --8<---
>
> That loses a lot of text, but I don't know that any of what is presently there is critical.  For instance, the current text recommends against a spoofable signal, but doesn't really say what it means to spoof.
>
> What do the editors of the spec think?
>
> On Tue, Mar 24, 2020, at 13:52, Gurshabad Grover wrote:
> > On 3/5/20 12:25 PM, Martin Thomson wrote:> This starts a joint working
> > group last call on these documents. Please respond this mail with your
> > views regarding the suitability of these documents for publication (as
> > Informational RFC and Proposed Standard RFC respectively) before 2020-03-23.
> > >
> >
> > Thanks for all the great work, authors and editors! I have reviewed
> > capport-architecture, and I support its publication as an RFC. Some
> > comments below.
> >
> > On capport signal
> > -----------------
> > The Captive Portal Signal section (2.5) was a bit confusing to me.
> >
> > Is 'signal' only meant to be binary information, i.e. whether traffic is
> > restricted or not? (pt. 3 in the section) If yes, the inclusion of a
> > 'pending expiry' notification in the same section seems contradictory.
> > (It also assumes that some information is available since "On receipt of
> > preemptive notification, the User Equipment can prompt the user to
> > refresh.")
> >
> > I think the clearest explanation of it is offered in the Security
> > Considerations rather than the section itself, i.e. the signal should
> > not carry any information at all, that it just acts as a prompt for the
> > User Equipment to contact the API. (This explanation makes other things
> > fall in line as well: the 'pending expiry' notification is just a
> > timed-signal that is no different from any other except for when it was
> > triggered.)
> >
> > I would suggest rephrasing sentences in the Captive Portals section to
> > make them as clear as the security considerations text. If my
> > understanding is correct, please let me know and I'm happy to submit a
> > PR to this effect.
> >
> >
> > Pull request
> > ------------
> > I have submitted a pull request with some editorial suggestions; happy
> > to elaborate on them if the motivation is not clear from the changes.
> > <https://github.com/capport-wg/architecture/pull/51>
> >
> >
> > Privacy considerations
> > ----------------------
> > Since we're dealing with unique identifiers and traffic information,
> > would love to hear people's thoughts on whether a brief privacy
> > considerations section would be useful. If yes, happy to help with that.
> >
> >
> >
> > Thank you.
> > -Gurshabad
> >