[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Captive-portals] Requirements on the signal from the enforcement device



Thanks again Lorenzo for putting together the requirements and posting them to the list. I'm planning on integrating them into the architecture document in the next week.

Given the lively discussion held in response to your post, I think it's worth re-posting the requirements, along with some editorial that captures my view on the outcome of the discussion.

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.
General agreement. There was also agreement on a proposal to rate limit API requests triggered by the ICMP messages, which in turn lead to t proposal that we should just rate limit API requests in general. This seems reasonable to me, though I wonder i we may want different rates for icmp-triggered API requests, and other ones? I don't see why we would want to complicate things by having more than one, but I figured it was worth asking.
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.

General agreement

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.

There seemed to be some disagreement here. In particular, most people responding were worried about limiting use-cases where explicit access was required to view certain content, such as allowing a teacher to override generic rules for a student. 
The obvious way to resolve this issue is to leave it out of the requirements, and let the protocol implementing the signal fight for whatever use-cases it needs to support here. That said, is there a way we can consider human rights without restricting business cases too much?
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.

Nobody spoke out against this, and we had one vote in favour, so I think it's safe to say that we can keep the requirements talking about the simple binary signal.

A final point was made that the enforcement device, or a device between it and the UE may rate limit the ICMP message, if we choose to go with ICMP. So, we should consider requirements relating to the reliability of the protocol.

In particular, I think it's worth pointing out a few things:
1. The architecture needs to be resilient to delivery issues with the ICMP message
2. It is NOT REQUIRED that the signalling protocol be reliable
3. The protocol SHOULD continue to send signals as long as the state which triggered the first message holds, subject to reasonable rate limiting at the sending itself. This makes the overall protocol more resilient/stateless/etc.

My plan for now is to create a section in the architecture for the protocol requirements. I'll take #1 and #2 from Lorenzo's post, along with the comments about rate limiting. I'll also work in the points I made above.

Finally, I'll make the protocol a MAY in the overall workflow/etc, and refer to the generic protocol rather than ICMP.

Feel free to let me know if I misunderstood, misrepresented or missed something in my summary.

Thanks,

Kyle