Re: [Captive-portals] thoughts on two documents
Erik Kline <ek@google.com> Sun, 23 April 2017 22:40 UTC
Return-Path: <ek@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 344CF126579 for <captive-portals@ietfa.amsl.com>; Sun, 23 Apr 2017 15:40:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 9br-M29_5iXa for <captive-portals@ietfa.amsl.com>; Sun, 23 Apr 2017 15:40:31 -0700 (PDT)
Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (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 048511205D3 for <captive-portals@ietf.org>; Sun, 23 Apr 2017 15:40:30 -0700 (PDT)
Received: by mail-yw0-x232.google.com with SMTP id 203so67672842ywe.0 for <captive-portals@ietf.org>; Sun, 23 Apr 2017 15:40:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uQ2FtD7eAkw+hgrbdV0QHkucmAYOROc6oxOqyOcBX40=; b=mezx6OqNLuicwP3E6g1Abd6Opwt4II7Dxsrg9g2g7TrghJfs2d5JrIpGrZWyga8rvZ s4v4B+A8aMqjxdkBUA+xOrIpMXjHfFEvY4fSgIKVDTCTJngUYW+CQRRoVv0XAECkl+2k EmaaMqFh7L1N0LMPFooBNlgZd4+4Y1Y3RniAKl+5GDY4rScHlyzfFvtfSWB3as0MCPep ku3l7EYla0Rws8OGXamYfB8NpdKTPfWaonR/kN5bh56IuTN9miESPJGqfeDNibOGYpXP VlOukOsdMoeTKpoll8v0HuJonDae2JJBXQsNbCIPfy1d09go1zpyb6+5iDOCW/ez22/b xe0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uQ2FtD7eAkw+hgrbdV0QHkucmAYOROc6oxOqyOcBX40=; b=mAX1j++/1scVwtgHEE9WXkhdtIWKc/OZR28HPjrWhWmPPMO96SIr8n5XN4tMIWiaU0 Q749W73mNp6WNL2bvaA90IdwCQZllccrK38oCbUgTVsV12ugOE0N1MVz/thUuDTMe0jy mE0RMYENWLa1K/vDsX+/N0ETKQH8FBi7tWdTHQAniW+2vtOIXCSayI3M+mNJxvqKqerX 9K18/6dpq1j6eHYLmNkHNZOHULsZmdma2tk2tC7gnh3qA/7ZOoHbgI7iOkrgeEaFs9C1 jKMQclgGAVkGWU5qZlK2IcAlNOKqjrPStNyJ+Hl1XLGvtaLrPAyma7rMTIhdC2GqCdb6 sc8A==
X-Gm-Message-State: AN3rC/4nAuGI8TptUX/nqo2EmwnN/SJakr1MhHiiJoFXrWASgNXXydqC Tk8cEIkIkyhlUdltw0Qh6FFG8ocSraIW
X-Received: by 10.129.115.212 with SMTP id o203mr2884979ywc.55.1492987229858; Sun, 23 Apr 2017 15:40:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.105.84 with HTTP; Sun, 23 Apr 2017 15:40:09 -0700 (PDT)
In-Reply-To: <20170423160926.5161041.8476.9279@sandvine.com>
References: <CAAedzxqP4-JeBL5W-2zG7p1fxwT6oHj29WAPVyQWK-hz20rX3A@mail.gmail.com> <20170423160926.5161041.8476.9279@sandvine.com>
From: Erik Kline <ek@google.com>
Date: Mon, 24 Apr 2017 07:40:09 +0900
Message-ID: <CAAedzxqu0p+KDSHvBvKmrtR+8k+6a1XmLFN69U=1FwzbEKH_NA@mail.gmail.com>
To: Dave Dolson <ddolson@sandvine.com>
Cc: David Bird <dbird@google.com>, Kyle Larose <klarose@sandvine.com>, "captive-portals@ietf.org" <captive-portals@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="001a11492530850c44054ddd2d25"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/OsMa7yVebmbnU8HQc97NC3TjBtw>
Subject: Re: [Captive-portals] thoughts on two documents
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 23 Apr 2017 22:40:33 -0000
On 24 April 2017 at 01:09, Dave Dolson <ddolson@sandvine.com> wrote: > Regarding the sacrificial q‎ueries, I would hope these are considered > temporary measures to detect existing portals, not the preferred approach. > If such a section were to be included then yes, I would think I needs to be clear that it's documenting some current behaviour. David Dolson > Sandvine > *From: *Erik Kline > *Sent: *Sunday, April 23, 2017 10:41 AM > *To: *David Bird; Kyle Larose > *Cc: *captive-portals@ietf.org > *Subject: *[Captive-portals] thoughts on two documents > > All, > > I have the vague feeling that there might be some general agreement around > the idea of having an ICMP unreachable code for captive portals (like an > HTTP 511 code [https://tools.ietf.org/html/rfc6585#section-6] for ICMP > :-), and it seems like there's no objection from captive portal > implementers with respect to the basic functional elements captured in > draft-larose-capport-architecture. > > Where I think some rough spots might lie for both of these is in their > integration with as-yet-undecided new behaviour. > > To that point, I would like to take my co-chair hat off and ask the > authors and the group for opinions of the following. > > [ draft-wkumari-capport-icmp-unreach ] > > There was some unresolved discussion about the contents of any included > extension. I wonder if the extra payload parts might be removed (Dave > Dolson's comment, I think?) and thereby simplify this version of the > document. Given that Destination Unreachable is a TCP soft error (vis. RFC > 5461) I'm not sure how much the proposed extra validation semantics are > really adding. > > If the document simply said that receiving and authenticating an ICMP > message with the capport code generically "MAY/SHOULD trigger the receiving > node's captive portal handling subsystem", would that be something that > folks might agree on? > > We'll need to run this whole thing by intarea and 6man as well, of course. > > And nothing stops us from proposing a mulit-part extension to be > optionally included in a future document, once the captive portal > interaction recommendations are more fully understood. > > [ draft-larose-capport-architecture ] > > I felt it was promising to hear some agreement about the functional > elements of a captive portal system as documented. > > Given that the captive portal interaction process is still on-going work, > would the document authors think it worth trying to advance the document > with either (a) section 3 removed or (b) section 3 rewritten to describe > broadly how most clients behave today? Even given the variety of clients I > think it could be roughly captured (e.g. make a few sacrificial queries to > trigger DNS/HTTP rewrites, keep trying until a sacrificial query produces > an expected result while launching an HTTP-capable application, and so on). > > -Erik >
- Re: [Captive-portals] thoughts on two documents Lorenzo Colitti
- Re: [Captive-portals] thoughts on two documents Dave Dolson
- [Captive-portals] thoughts on two documents Erik Kline
- Re: [Captive-portals] thoughts on two documents Erik Kline
- Re: [Captive-portals] thoughts on two documents Michael Richardson
- Re: [Captive-portals] thoughts on two documents Michael Richardson