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

On Tue, Mar 20, 2018 at 8:29 AM, Lorenzo Colitti <lorenzo@google.com> 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.
>
>
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.

>
>    -
>    - 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.
>

Agreed.

>
> 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.

> 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.
>

Agreed. That wasn't part of the draft.

>
> Cheers,
> Lorenzo
>
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals
>
>