tree 1b7444cfc8a6ff4fad13a5fed69d8503ae8cf7af
parent 6091d230e3786c635eea3513d73af45081a5770c
author Andrew Yourtchenko <ayourtch@gmail.com> 1522240428 +0200
committer Damjan Marion <dmarion.lists@gmail.com> 1522442881 +0000

acl-plugin: implement an optional session reclassification when ACL is (re-)applied

There were several discussions in which users would expect the sessions to be deleted
if the new policy after the change does not permit them.
There is no right or wrong answer to this question - it is a policy decision.

This patch implements an idea to approach this. It uses a per-interface-per-direction counter to designate
a "policy epoch" - a period of unchanging rulesets. The moment one removes or adds an ACL applied to
an interface, this counter increments.
The newly created connections inherit the current policy epoch in a given direction.
Likewise, this counter increments if anyone updates an ACL applied to an interface.

There is also a new (so far hidden) CLI "set acl-plugin reclassify-sessions [0|1]"
(with default being 0) which allows to enable the checking of the existing sessions
against the current policy epoch in a given direction.

The session is not verified unless there is traffic hitting that session
 *in the direction of the policy creation* - if the epoch has changed,
the session is deleted and within the same processing cycle is evaluated
against the ACL rule base and recreated - thus, it should allow traffic-driven
session state refresh without affecting the connectivity for the existing sessions.

If the packet is coming in the direction opposite to which the session was initially
created, the state adjustment is never done, because doing so generically
is not really possible without diving too deep into the special cases,
which may or may not work.

Change-Id: I9e90426492d4bd474b5e89ea8dfb75a7c9de2646
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>