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

On Tue, Mar 20, 2018, 9:56 AM Pierre Pfister <pierre.pfister@darou.fr>
wrote:

> Turning the requirements around I would add that sending ICMP messages
> based on a session being ‘almost done’ might be challenging from a
> router/hardware perspective. Routers might have to rate-limit such
> messages, and sometimes fail to send them.
>

My feeling is just the opposite.. the NAS knows perfectly when it will or
will not hold a session captive. If that NAS is being told what to do (e.g.
it isn't working on it's own counters, but relying on a radius server),
then the radius CoA could just come early with extra parameters (e.g.
'grace period' or even how many and how often to send icmp warnings...)

> So I would add that the ICMP message should only be relied upon as a
> backup mechanism to detect that something is wrong while the API mechanism
> already failed to detect that the session is almost over.
> In other words, I think the detection of a session being almost over is
> first and foremost a problem to be solved by the API mechanism, and as a
> backup (i.e. in case of inconsistency between the API and the Enforcement
> point), with the ICMP mechanism.
>
> - Pierre
>
> Le 20 mars 2018 à 15:29, Lorenzo Colitti <lorenzo@google.com> a écrit :
>
> 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
>
>
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals
>