Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content

From: "Tom-PT Taylor"<[email-masked]>
Date: Fri, 5 Apr 2002 11:43:54 -0500

Assuming that contradictions are possible (see my previous message), we
should distinguish two cases:
 - a specific Agent contradicts a Policy Rule installed previously by that
same Agent
 - a specific Agent contradicts a Policy Rule installed by another Agent.

An underlying premise of our proposed semantics is that each Policy Rule
(defined as a set of {Filter, Action} pairs with a specific Policy Rule
Identifier) has one or more owners.  That is, the Middlebox remembers the
Agent(s) who installed those rules.

Whether more than one Agent should be able to work with the same Policy Rule
is a matter for discussion, though I sense an inclination not to allow this.
(But it seems to me that an Administrator should be able to audit all
installed Policy Rules and deactivate any of them if need be.)  On the other
hand, I think it is accepted that different Policy Rules could overlap in
their scope.  So I'll concentrate my discussion on the case where a new
Policy Rule is in conflict with a previously installed Policy Rule.

I would suggest a general approach to conflicts of this form:

 - If an Agent contradicts itself, the Middlebox denies the new Policy Rule
Request.  It returns an appropriate reason code and the Policy Rule
Identifier of the rule which is in conflict.  The Agent then has the
information it needs to choose between modifying the already-existing rule
to accommodate the new conditions or giving up on the new Policy Rule.

 - If an Agent contradicts another Agent, Agent priorities come into play.
I'm happy enough to allow only two priorities: Administrator and others, but
I'm not sure we need to specify this, only that there exists a hierarchy of
Agent priorities.  The general rule is then that the Policy Rule installed
by the higher priority agent prevails and the other one is rejected or
deactivated as the case may be.  Between equal-priority Agents, existing
Policy Rules take priority over new ones.

One open question is what diagnostic information should be supplied when a
Policy Rule is rejected or deactivated.  I see the following possibilities:
(1) The Middlebox computes and returns a modified Policy Rule that would be
consistent with the over-riding Policy Rule.
(2) The Middlebox returns the complete contents of the over-riding Policy
Rule.
(3) The Middlebox returns the (sub)set of {Filter, Action} pairs within the
over-riding Policy Rule which are in conflict with the disallowed Policy
Rule.
(4) The Middlebox returns a set of filters which describe the precise area
of conflict with the over-riding Policy Rule.

I have a bit of a concern with privacy which inclines me to alternative (4).

-----Original Message-----
From: Martin Stiemerling [mailto:[email-masked]]
Sent: Friday, April 05, 2002 9:57 AM
To: Sen, Sanjoy [NGC:B692:EXCH]
Cc: 'Jiri Kuthan'; Taylor, Tom-PT [CAR:B800:EXCH]; [email-masked];
Aoun, Cedric [QPD:MA01:EXCH]
Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content

Sanjoy Sen wrote:

> How will then the following requirement from Midcom requirements draft 
> be satisfied?
> *****
> 2.2.11.
> 
>      It should be possible to define rulesets that contain a more spe-
>      cific filter spec than an overlapping ruleset.  This should allow
>      agents to request actions for the subset that contradict those of
>      the overlapping set.
> *****

> Whether you want it or not, there would be overlapping rulesets because 
> the filterspec may overlap for different rulesets installed by 
> independent agents. The question - who wins when there're contradictory 

> actions is moot because the requirement above seems to suggest that we 
> need to allow contradictory behavior.

The questions is, who will decide how to behave in such a case? There 
are so many combinations of firewall/NAT configurations which will make 
it difficult to define a stable behaviour, i.e. how to react with this 
overlapping set. Furthermore, the requirement starts with "should"...

Martin
-- 
Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories  [email-masked]
IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 05 Apr 2002 23:16:30 +0200

Tom,

> Agent(s) who installed those rules.

Alternatively, you could
1. disallow contradictions
2. have a single owner per rule and have both of them active at the same time.
Both alternatives avoid multiple ownership.

> of conflict with the over-riding Policy Rule.

You omitted the most obvious choice:
(5) The middlebox does not return any diagnostic information. A simple
    error code, such as "denied" or "denied because of conflict" might
    be enough. I think that most clients will be rather simple and
    therefore not able to analyse complex diagnostic info and react
    accordingly.
    Diagnostic information would be interesting for manual operators,
    but this is not what our charter is about.

> I have a bit of a concern with privacy which inclines me to alternative (4).

Alternative (5) should be close to the optimum concerning privacy.

    Juergen
-- 
Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de