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

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.

-Dave

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
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals