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

Martin Thomson <mt@lowentropy.net> Wed, 25 March 2020 04:53 UTC

Return-Path: <mt@lowentropy.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 DC2523A02BB for <captive-portals@ietfa.amsl.com>; Tue, 24 Mar 2020 21:53:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=lowentropy.net header.b=jMyzI09I; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XKwRGZbY
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 FsOgNJpC3TA4 for <captive-portals@ietfa.amsl.com>; Tue, 24 Mar 2020 21:53:26 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209A93A00D9 for <captive-portals@ietf.org>; Tue, 24 Mar 2020 21:53:26 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 7102E5A5; Wed, 25 Mar 2020 00:53:25 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 25 Mar 2020 00:53:25 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=uAJn7NZS/hP31liCwwaPtUthBL8T iux1DTkQqPl3KXE=; b=jMyzI09IsLAgQ/C2afy2nyNW2x601DYfo78LB/ashS9E WdxLKO6+L+KL6arwmgL0B85yvrlahzuL1cZvOqm2O39y6RGI67slH1W3hxMDiaP+ ybkpyC7qrTNaowkQnfEDxcGJkTWWWm8PsMObilTWSdZq73E8K5vVCJBrDzfbNfQn X/+MnTkXcMDAgc5y9k9fIAiAJkhn2jCN9iME+PnY5K2RGM20dMUg73SDbi1acue7 iHacse+I3hwPnRr9k+SP0gcBHa9wgB/5XEoxmKmMvKHX+ELhnnlFPPb15CmjqyWY okKYuXQ32z5HszQOJ2p8UJF7b5QBx3g1wWV5MWHlYQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=uAJn7N ZS/hP31liCwwaPtUthBL8Tiux1DTkQqPl3KXE=; b=XKwRGZbYd/rmIciWKbCM3p c8CI/AnwTiz6APexNIvTRIebTE2eafZ+COcT7WAAL7SuVXzz9qVhQV6HNzYzOeEw 0zOqBigv0qiobBMBqx88hdZtxZbGYRunMGWReDRm6zr8BGdx2Swi4+ULNuZypdtf NbASK+0Lnxi80FR9yJYJ0rZOY2bTBaCKtNRIEWedpEYGGLwzKf0XedCRE7inkG/w Him/gtAxpDh/SJOSpkSf8TrMyBagZZOmWtynU0IrGsgZUto6FT8AlAhOMnKoDIUw 85hgLF2JVovHq0EV7qQ2p4/W17kQDfXMCk/IJQoYu2PxgJxUo8H8+tKJ6q9Pi70g ==
X-ME-Sender: <xms:xON6XkfGgLlMuvpZZHaqFeOT4Xjcl4EZdo5e518THd7ky97DC6wBQQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudehvddgjeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecuff homhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:xON6Xh5vEn3fbVYeuffANj8kaXlWqC2PzNy6swZ2pVfNzMuGteY77g> <xmx:xON6Xh9Fy3SEPNgXp7IDunH1EIzKo9kaRElTU0ZwaXPLg-GAtO-9uw> <xmx:xON6XjEgWFHrb4z2alJsbePJbDh53UGkWpu3X2mubi710p1NLTwG-g> <xmx:xeN6XnkPY27O9EKlCEPmxsM2ZpWsstq1ejSlLyrudEdHfIUhgv0E5g>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0760AE00A6; Wed, 25 Mar 2020 00:53:24 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-1021-g152deaf-fmstable-20200319v1
Mime-Version: 1.0
Message-Id: <99f2c4eb-d59b-46c9-8ddb-e728c9937422@www.fastmail.com>
In-Reply-To: <1fceca08-743c-87a2-521c-37276ba34aab@cis-india.org>
References: <6c3d2931-f8fc-4724-a5aa-81062be9a51e@beta.fastmail.com> <1fceca08-743c-87a2-521c-37276ba34aab@cis-india.org>
Date: Wed, 25 Mar 2020 15:53:03 +1100
From: "Martin Thomson" <mt@lowentropy.net>
To: "Gurshabad Grover" <gurshabad@cis-india.org>, captive-portals@ietf.org
Cc: "Kyle Larose" <kyle@agilicus.com>, "Heng Liu" <liucougar@google.com>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/VNBimAc9jc53NfzAnaSUHeNZUxw>
Subject: Re: [Captive-portals] =?utf-8?q?WGLC_on_draft-ietf-capport-architect?= =?utf-8?b?dXJlIGFuZCAuLi4tYXBp?=
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, 25 Mar 2020 04:53:28 -0000

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
>