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

Dave Dolson <> Tue, 20 March 2018 15:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B45E126D74 for <>; Tue, 20 Mar 2018 08:39:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pPlA94xbjS8F for <>; Tue, 20 Mar 2018 08:39:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 87F5F126579 for <>; Tue, 20 Mar 2018 08:39:47 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from <>) id 1eyJMY-00086d-7s for; Tue, 20 Mar 2018 11:39:46 -0400
References: <>
From: Dave Dolson <>
Message-ID: <>
Date: Tue, 20 Mar 2018 11:39:37 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------E4C49BE03611DA64204CB700"
Content-Language: en-US
Archived-At: <>
Subject: Re: [Captive-portals] Requirements for "captive portal closed" notifications
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of issues related to captive portals <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Mar 2018 15:39:49 -0000

I agree about viewing ICMP as a hint for the user equipment to visit the 
API. The UE should trust nothing in the ICMP message itself.

And querying the API should be harmless (GET having no side-effects), 
aside from the load imposed on it. So we should say that the UE must 
rate-limit ICMP-triggered API visits.  Example wording: "The UE MUST 
rate-limit ICMP-triggered API requests to once every 5s."

We could get fancy with back-off retries, or allowing the API to specify 
the rate limit, but my main point is that the ICMP message does not 
require any sort of authentication if we make a spoofed message harmless.


On 2018-03-20 11:29 AM, Lorenzo Colitti wrote:
> Per discussion at the mike today on what we should do with the ICMP 
> unreachable draft - here are some properties I think are necessary in 
> a hint to the UE that the captive portal is closed.
> 1. The notification should not be easy to spoof. This is easiest to do 
> by making it a hint to the UE that it should talk to the API.
>   * 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.
>   * Tero points out that if we do want to secure such a message, then
>     we should not roll our own security but should use an existing,
>     secure protocol such as IPsec.
> 2. It should be possible to send the notification *before* the captive 
> portal closes, to facilitate seamless connectivity. Ideally the user 
> should be able to re-up the captive portal without having to wait 
> until the network is dead or the device has switched to another network.
> 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.
> 4. I'm not sure whether it's possible for the hint to be anything more 
> than a binary "you are or will very soon be captive". Saying things 
> like "an upgrade opportunity is available" may be hard to encode.
> Cheers,
> Lorenzo
> _______________________________________________
> Captive-portals mailing list