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

Tero Kivinen <kivinen@iki.fi> Wed, 21 March 2018 16:11 UTC

Return-Path: <kivinen@iki.fi>
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 C6D3D12D889 for <captive-portals@ietfa.amsl.com>; Wed, 21 Mar 2018 09:11:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level:
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 p9yJ_qQyxVCw for <captive-portals@ietfa.amsl.com>; Wed, 21 Mar 2018 09:11:34 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C0E012704A for <captive-portals@ietf.org>; Wed, 21 Mar 2018 09:11:34 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w2LGBSHu014244 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Mar 2018 18:11:28 +0200 (EET)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w2LGBSJA018808; Wed, 21 Mar 2018 18:11:28 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Message-ID: <23218.33840.363287.421172@fireball.acr.fi>
Date: Wed, 21 Mar 2018 18:11:28 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: captive-portals@ietf.org
In-Reply-To: <16033.1521638044@dooku.sandelman.ca>
References: <CAKD1Yr3rP24jQ6sMpoXZ3pU02FmvwDNc9=w2oAh4bMWZmEtQ_A@mail.gmail.com> <CADo9JyXpW-rn81kwOkqx8+=iBMTWd+x1FoMm-YTCm+Efmb23gQ@mail.gmail.com> <CAKD1Yr0oDZQJQ1n899Vtm1VPwwV2ZaLZTJV19a35G6pHf0x1Dg@mail.gmail.com> <16033.1521638044@dooku.sandelman.ca>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 3 min
X-Total-Time: 4 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/9ZALf6Bg6gtD-oj2DAYOS13-CF8>
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: Wed, 21 Mar 2018 16:11:37 -0000

Michael Richardson writes:
> Lorenzo Colitti <lorenzo@google.com> wrote:
>     david>     Is there any data that shows ICMP (and its insecurity) being used
>     david> for off-path attacks like this today? Networks (as they do today) may
>     david> 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".  
> 
> We have secdir secretary Tero on the list now...
> 
> Even if offpath attacks are challenging, given typical coffee shop wifi,
> on-path attacks are trivial.
> 
> The ICMP is a hint.  That's also good for many reasons involving rate
> limiting and idempotency.

Yes. This has been also used in the security protocols like IKEv2. For
example section 2.4 in RFC7296 (IKEv2 [1]) says following:

   Since IKE is designed to operate in spite of DoS attacks from the
   network, an endpoint MUST NOT conclude that the other endpoint has
   failed based on any routing information (e.g., ICMP messages) or
   IKE messages that arrive without cryptographic protection (e.g.,
   Notify messages complaining about unknown SPIs). An endpoint MUST
   conclude that the other endpoint has failed only when repeated
   attempts to contact it have gone unanswered for a timeout period or
   when a cryptographically protected INITIAL_CONTACT notification is
   received on a different IKE SA to the same authenticated identity.
   An endpoint should suspect that the other endpoint has failed based
   on routing information and initiate a request to see whether the
   other endpoint is alive. To check whether the other side is alive,
   IKE specifies an empty INFORMATIONAL request that (like all IKE
   requests) requires an acknowledgement (note that within the context
   of an IKE SA, an "empty" message consists of an IKE header followed
   by an Encrypted payload that contains no payloads). If a
   cryptographically protected (fresh, i.e., not retransmitted)
   message has been received from the other side recently, unprotected
   Notify messages MAY be ignored. Implementations MUST limit the rate
   at which they take actions based on unprotected messages.

So using ICMP as hint and doing rate limited operatins based on that
is acceptable.

[1] https://www.rfc-editor.org/rfc/rfc7296.txt
-- 
kivinen@iki.fi