Subject: [Captive-portals] Splitting the enforcement device into two logical components

From: Kyle Larose <[email-masked]>
Date: Tue, 26 Jun 2018 20:39:36 -0400

During IETF 101 hackathon I played around with a modification to the
architecture where a device adjacent to the user equipment ensures that it
is not spoofing the implicit identity used by the captive portal
deployment. This worked out pretty well.

So, the proposal is to create a second "enforcement" device whose
responsibility is to ensure that traffic allowed into the captive network
carries the identity expected by the network. This allows the deployment to
vary in its topology -- the enforcement device need not be adjacent to the
user equipment.

This removes some concerns from the implicit identity, but it raises a new
question: what should this new enforcement device do if the traffic is
denied? Does it silently drop it, or should it signal back with the
signalling protocol?

I'm inclined at this point to not take this suggestion; I'm worried about
the extra complexity of adding yet another component, and I think we can
get by without it.

What does everyone else think? I can provide more concrete examples/text if
you'd like.

Thanks.

Kyle

---

From: David Bird <[email-masked]>
Date: Thu, 28 Jun 2018 06:08:24 -0700

Hi Kyle,

I'm not sure about the term "device" ... conceptually, I think maybe
"enforcement function" is more appropriate. This enforcement function could
be encoring captive portal, rate limiting, etc., so the "function" might
even be split up between multiple pieces of software, potentially running
on different devices in the network infrastructure.

I think it is beneficial to define formally what the enforcement function
_should_ do. E.g. silently drop vs. send back notifications -- some vendors
already send back ICMP / Dest Unreach / Filtered, some might do TCP RST,
none of these give the UE any accurate insight into the fate of the packet.

Cheers,
David

See
https://www.juniper.net/documentation/en_US/junos/topics/concept/pcrf-pcef-ocs-interactions-understanding.html

On Tue, Jun 26, 2018 at 5:40 PM Kyle Larose <[email-masked]> wrote:

> What does everyone else think? I can provide more concrete examples/text
> if you'd like.
>
> Thanks.
>
> Kyle
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>

---

From: David Bird <[email-masked]>
Date: Thu, 28 Jun 2018 06:25:19 -0700

Forgive my typos...   s/encoring/enforcing/  :)

Also, worth noting... because enforcement functions have no way of
signaling captivity specifically, we have vendors today REDIRECTING HTTPS
(with all the security implications that carries) because they simply do
not want to just silently drop (user watching browser timeout) or do TCP
RST / existing ICMP (user sees browser fail). This is something we can and
should SOLVE!

On Thu, Jun 28, 2018 at 6:08 AM David Bird <[email-masked]> wrote:

>> This removes some concerns from the implicit identity, but it raises a
>> new question: what should this new enforcement device do if the traffic is

---

From: Nicolas Mailhot <[email-masked]>
Date: Fri, 29 Jun 2018 18:48:28 +0200

Thanks a lot for the analysis. That is pretty much what I prayed for
months/years ago before this group was formed.

You have enforcement nodes. Their sole function is to stop or limit
whatever traffic the network owner does not like (abusive users, rogue
iot gadgets, slacking students, ddos attacks, whatever). They can
potentially process huge levels of traffic. Their location in the
network topology varies depending on what the network owner wants to
achieve. They don't have any fancy UI because they can address all kinds
of traffic.

And you have autorisation nodes. They allow network clients to request
being treated some other way by enforcing. They can have fancy human-
oriented UIs, or robot-oriented enrolment portals. They communicate with
enforcing out of band (client does not see this part). If the network
operator is nice, he makes sures they can be reached without enforcing
interference :).

The only message needed by network clients is indication of the location
of the corresponding authorization node when some enforcing node drops
or limits parts of their communication attempts. (and the network client
can choose to talk to the authorization node, stop communicating, or
switch to another traffic form that does not trigger enforcing)

Regards,

-- 
Nicolas Mailhot

---

From: David Bird <[email-masked]>
Date: Sat, 30 Jun 2018 06:12:18 -0700

Thanks Nicolas,

I too have been hoping this WG addresses the core issues for several years
now. Indeed, I will upgrade my statement in this thread from saying
defining how the enforcement function should behave would be *beneficial*,
to being *fundamental*. We need you, and others that agree, to speak up in
the WG as, when needed, it seems support for these concepts isn't always
present on the list and meetings. The API is a nice to have, but trying to
solve network layer issues at an application layer (with no network
feedback) is inherently going to problematic. It provides a bigger path for
networks to be misconfigured, misinformed, and not fully integrated, than
it does in solving the core issues at hand.

Cheers,
David

---

From: David Bird <[email-masked]>
Date: Sat, 30 Jun 2018 07:08:40 -0700

Defining what the enforcement function should be doing (from some time
ago)...

On Sat, Jun 30, 2018 at 6:12 AM David Bird <[email-masked]> wrote:

> to being *fundamental*. We need you, and others that agree, to speak up
> in the WG as, when needed, it seems support for these concepts isn't always