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

From: Kyle Larose <[email-masked]>
Date: Sun, 17 Jun 2018 10:05:32 -0400

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