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