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

From: "Tom-PT Taylor"<[email-masked]>
Date: Wed, 17 Apr 2002 09:56:37 -0400

I agree that the double wildcarding goes a bit far, but most of the
scenarios in Christian's document require wildcarding at one end or the
other.

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

Hi Tom,

--On 12 April 2002 08:51 -0400 Tom-PT Taylor <[email-masked]>
wrote:

>
> I agree with your distinction between the issues of rule overlapping and
access control.  I do wonder if you are being too dogmatic on the matter of
rule overlapping, and would beg for exceptions in two cases:
>
>   -- the rules do not involve contradictory actions (e.g. both rules allow
flows)
>
>   -- the rules both come from the same Agent.
>
> Here is an example scenario in which I could see the possibility of rule
overlapping: a rule is set up allowing any node inside to connect to a
specific address outside.  Then an Agent sets up a rule allowing connection
from a specific inside address
> to that outside address.  In the process, the Agent receives an address
binding to the mapped address at the Middlebox.  Using the notation I have
proposed earlier, the first rule is:
>
> Filter= { Source address:      ANY,
>           Source port:         ANY,
>           Source realm:        <the internal realm>,
>           Map address:         ANY,
>           Map port:            ANY,
>           Map realm:           <the external realm>,
>           Destination address: <specific external address>,
>           Destination port:    <specific external port>,
>           Destination realm:   <the external realm>,
>           Protocol             <a specific protocol> },
>
> Action = Allow

Maybe I'm wrong, but I consider this kind of rule to be out of scope of
midcom. This colesction of wildcards looks like an administrative NAT
configuration but not like something that an application requires.

    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

> The second, more specific rule is:
>
> Filter= { Source address:      <specific internal address>,
>           Source port:         <specific internal port>,
>           Source realm:        <the internal realm>,
>           Map address:         CHOOSE,
>           Map port:            CHOOSE,
>           Map realm:           <the external realm>,
>           Destination address: <specific external address>,
>           Destination port:    <specific external port>,
>           Destination realm:   <the external realm> },
>
> Action = Allow
>
> In response to this second rule the Middlebox reports the bindings it has
assigned for the CHOOSE entries.
>
> I can think of one or two arguments you may have against this sort of
situation, but I don't know which particular arguments you would choose.  So
I'll see what you have to say.
>
> As for allowing an Agent to amend or contradict itself, I see this as a
matter of convenience.  It makes it easier to associate specific Policy
Rules with specific application sessions, regardless of how they interact.
If you disallow it, the
> workaround is for the agent to combine everything into a single Policy
Rule.  This is OK provided that the Agent knows that it itself is the source
of the overlap.
>
> -----Original Message-----
> From: Jiri Kuthan [mailto:[email-masked]]
> Sent: Friday, April 12, 2002 5:30 AM
> To: Taylor, Tom-PT [CAR:B800:EXCH]; 'Martin Stiemerling'; Sen, Sanjoy
> [NGC:B692:EXCH]
> Cc: [email-masked]; Aoun, Cedric [QPD:MA01:EXCH]
> Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content
>
> I think people mix up two issues: rule overlapping and access control.
>
> I argumented against rule overlapping -- I want to disallow rules
> with different packet matching expressions with packets matching
> both of them. Doing anything else is a ticket for unneeded complexity
> and I see reluctance to enter such business on mailing list.
>
> The other, security-policy issue is how access to rules
> with identical packet matching expressions is governed. Which is
> a different discussion.
>
> -Jiri
>
> At 06:43 PM 4/5/2002, Tom-PT Taylor wrote:
>
>> Assuming that contradictions are possible (see my previous message),
>
> Please NO.
>
>> 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]>mailto:[email-masked]
.de]
>> 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>http://www.ccrle.nec.de  IPv6:
<http://www.ipv6.ccrle.nec.de>http://www.ipv6.ccrle.nec.de

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

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 17 Apr 2002 17:19:22 +0200

> scenarios in Christian's document require wildcarding at one end or the

Some wildcarding will be required for sure, but setting the IP address
and the port number to wildcard is too much wildcarding, i.e. especially 
the sys admins won't like this.
A good wildcarding situation would be that the IP address is known, but 
not the specific port number.

Martin

-- 
Martin Stiemerling

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