Re: [Captive-portals] Requirements for "captive portal closed" notifications

David Bird <dbird@google.com> Tue, 20 March 2018 18:04 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 340A7127286 for <captive-portals@ietfa.amsl.com>; Tue, 20 Mar 2018 11:04:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Q-oJsGj0yE7K for <captive-portals@ietfa.amsl.com>; Tue, 20 Mar 2018 11:04:50 -0700 (PDT)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 81433127201 for <captive-portals@ietf.org>; Tue, 20 Mar 2018 11:04:50 -0700 (PDT)
Received: by mail-io0-x22b.google.com with SMTP id g14so3449409iob.13 for <captive-portals@ietf.org>; Tue, 20 Mar 2018 11:04:50 -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=U1re4FX2xQB/PlmycKcr7Rq0/CrL9mXo52cqq+6Vlb8=; b=KqIPUkiHQ+4r4YKe/Bw1mkv1B8yXZ5ysNhsZlv1/sLJbhC1eLsvcWpn/u8W1jZQ/wF isDsD6DQL6nPOmRyDTKU5V0Qmf165asuwgy0fUSA3d8yTMl6ZMyNdxnCtcqZS+h2V69D saT9SMANhZ9iTb0ZzNDhkqpBqqwbvMOsRt9lPMitQWeb10NwxMEjGP/XobwvVuLKt5Dq gk5cNRM65q6O+oIKEoAe1d44z/eUYnUJrXuyO+ibTFO28ntgPEBqSjF7sKe6kg/8XsGN UZWIuu9GNz9o8xIDIxyncNWmQggTmUCZM2dS6UVckmMLsDdwn4lT/PKroKzEUjSER8gv T4wA==
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=U1re4FX2xQB/PlmycKcr7Rq0/CrL9mXo52cqq+6Vlb8=; b=gpUcp9VkQJPzdTHkeikmerVrYx6jyq1vM9DAPVa7vKzlxqyl2Q2+c6OIDdpb+lZFCw WsemA0IJp3D93Um6ImjeKyAgWG8m7ut9t5PLyneUAPiR6O747ANMiDQisLpg0IT1S4iY 2DB91YkS+9uHOuvhL7MgHDt7/edW8PAEGZ0rZu83JQIiZqbYkNm1uKjsY2o0Kbpp1PoH RtYX5J2OzQoLmpg9BOQ+wcgR1uHGcdj7TSochUfYGmtYstNwEjilY9O9IpdLyIS6Rjz0 NRcEqISo/yd3neiq9l9jOcQWT+F5ZgIKvR5JojsyiQb6Sa2RVbrbtbFpUYpeGw5ol8dF NSpw==
X-Gm-Message-State: AElRT7FqwyTtyQ3/RBXdVCNIWieOA4Y5yHFlYgUEE2sdDOF1Uqg/ncHa tv/jogrmRlqhyhzlSCXhqqbugw4TAbHf7Fu+n6mYmw8r
X-Google-Smtp-Source: AG47ELt8k0QGzEiFNCxmWSZPioyoZhdasmVMhxrod2/oyLzsEESkt/Pw/xVxObgKKd7EAbNE8QaxLNj/td1fxaCMzBE=
X-Received: by 10.107.53.96 with SMTP id c93mr17702322ioa.90.1521569089406; Tue, 20 Mar 2018 11:04:49 -0700 (PDT)
MIME-Version: 1.0
References: <CAKD1Yr3rP24jQ6sMpoXZ3pU02FmvwDNc9=w2oAh4bMWZmEtQ_A@mail.gmail.com> <CADo9JyXpW-rn81kwOkqx8+=iBMTWd+x1FoMm-YTCm+Efmb23gQ@mail.gmail.com> <CAKD1Yr0oDZQJQ1n899Vtm1VPwwV2ZaLZTJV19a35G6pHf0x1Dg@mail.gmail.com> <CADo9JyUWawp5FC8q=0KJMk8T4x-iyFjpj167UH_NPjT=b2Hn+A@mail.gmail.com>
In-Reply-To: <CADo9JyUWawp5FC8q=0KJMk8T4x-iyFjpj167UH_NPjT=b2Hn+A@mail.gmail.com>
From: David Bird <dbird@google.com>
Date: Tue, 20 Mar 2018 18:04:38 +0000
Message-ID: <CADo9JyUGz9wDxiNmPw1sHHY8eDKL3NUyRN6VkNJQ=O7RUo6YFw@mail.gmail.com>
To: Lorenzo Colitti <lorenzo@google.com>
Cc: captive-portals@ietf.org
Content-Type: multipart/alternative; boundary="001a11442f2c13dea50567dbe979"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/qEKtsuaz4bPSAUh9Gxjvdlz-uqY>
Subject: Re: [Captive-portals] Requirements for "captive portal closed" notifications
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: Tue, 20 Mar 2018 18:04:52 -0000

If we hammer in that the feature allows "you to reach all government
websites for free, where everything else is paid" and focus on that, we can
get more consensus. ;-)


On Tue, Mar 20, 2018 at 9:07 AM David Bird <dbird@google.com> wrote:

> On Tue, Mar 20, 2018 at 9:01 AM, Lorenzo Colitti <lorenzo@google.com>
> wrote:
>
>> On Tue, Mar 20, 2018 at 3:44 PM, David Bird <dbird@google.com> wrote:
>>
>>>
>>>>    - An ICMP message by itself is not secure. For example, it's
>>>>    trivial for an off-path attacker to generate ICMP messages for sessions
>>>>    from legitimate UEs to <popularwebsite>:443. Getting a UE to trust such a
>>>>    message only requires getting the ephemeral port right, and many OSes have
>>>>    a quite limited range of ephemeral ports.
>>>>
>>>>
>>> Is there any data that shows ICMP (and its insecurity) being used for
>>> off-path attacks like this today? Networks (as they do today) may just
>>> filter out ICMP they don't support from the edge.
>>>
>>
>> Regardless of whether this is happening today, it seems unwise to propose
>> something with an obvious security hole like this. The risk is that we do a
>> bunch of work and then security review tells us "?REDO FROM START".
>>
>>
>>> 3. The notification should not be on a per-destination basis. A hint
>>>> that conveys the information "you can reach facebook, but to reach CNN you
>>>> need to upgrade to another service plan" is not technically infeasible but
>>>> is unlikely ever to reach WG and IETF consensus and therefore I think we
>>>> should not spend our time talking about it.
>>>>
>>>
>>> Can't a network have this policy irrespective of how we implement ICMP?
>>> Can't they even today just use existing ICMP messages? I cringe when we
>>> start dictating how PUBLIC ACCESS networks manage their walled garden and
>>> businesses.
>>>
>>
>> My point was that there's no use in having that discussion, because we
>> know there are strong opinions on both sides and thus we're not likely to
>> get consensus.
>>
>
>
> My point is that you are the one *making* this a discussion not likely to
> get consensus by loading the question with statements like "you can reach
> facebook, but to reach CNN you need to upgrade to another service plan"
> ...  which isn't a problem with ICMP per se, rather how you don't like how
> some public access networks operate...
>
>