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

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

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

On Sat, Jun 30, 2018 at 6:12 AM David Bird <[email protected]> wrote:
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. 


On Fri, Jun 29, 2018 at 9:48 AM Nicolas Mailhot <nicolas.mailhot=[email protected]> wrote:
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)


Nicolas Mailhot

Attachment: Capport ICMP (2) (1).pdf
Description: Adobe PDF document