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.
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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/captive-portals
_______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
