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

From: "Tom-PT Taylor"<[email-masked]>
Date: Tue, 2 Apr 2002 11:50:08 -0500

My previous posting was probably too abstract without an example of how it
works, so here is an extract showing application to the first scenario.

5.1	Simple server behind NAT/Firewall

Since the intent is to cover semantics (i.e. what should be included in the
MIDCOM messages), informal Midcom messages are shown. The syntax in
describing the required information in the messages will be dependent on the
selected protocol.

   Middlebox Beta			Midcom Agent Alpha
                   <--------------------
      PolicyRuleRequest
          (Version, TransactionId=x, AgentId=Alpha, Credentials,
           RuleID=r, Policy Rule=[see below], Lifetime=eternal,
           Integrity=all-or-nothing) 

   				  -------------------->
         PolicyRuleResponse [success case]
              (Version, TransactionId=x, MiddleboxId=Beta, Credentials,
               RuleID=r, Policy Rule=[see below], Lifetime=eternal,
               Reason=accepted)

 				  -------------------->
      PolicyRuleResponse [failure case]
           (Version, TransactionId=x, MiddleboxId=Beta, Credentials,
            RuleID=r, Policy Rule={}, Lifetime=0,
            Reason=no authority)

The Policy Rule in the Request consists of a single {Filter, Action} pair as
follows:

Filter = 
	Source addr = ANY
	Source port= ANY
	Source realm=Outside
	Map addr = CHOOSE
	Map port= CHOOSE
	Map realm= Outside
      Dest addr= InternalHostaddr ; address of the internal host
	Dest port=80
	Dest realm= Inside
	Protocol=TCP

Action= Allow
					
This {Filter, Action} pair is used to ask the Middlebox for a mapped
address/port pair to allow an incoming TCP connection to be established.

The success case Response shown above indicates that the Middlebox has
granted the request.  The Policy Rule returned in this example is:

Filter =
	Source addr = ANY
	Source port= ANY
	Source realm=Outside
	Map addr = 193.252.187.186
	Map port= 25000
	Map realm= Outside
	Dest addr= InternalHostaddr
	Dest port=80
	Dest realm= Inside
	Protocol=TCP

Action= Allow

Scenario 1 does not mention enabling of outward flows.  That may be because
default policies already allow such flows.  On the other hand, the required
flow could be installed either as an increment to the Policy Rule just
installed or when the SYN is received.  In the example shown here, the
Midcom Agent requests another filter to be added within the existing policy
rule installed on the Middlebox, to allow packets to flow from the server to
the external network. 

   Middlebox Beta			Midcom Agent Alpha
                   <--------------------
      PolicyRuleRequest
          (Version, TransactionId=y, AgentId=Alpha, Credentials,
           RuleID=r, Policy Rule=[see below], Lifetime=eternal,
           Integrity=all-or-nothing) 

				  -------------------->
         PolicyRuleResponse
              (Version, TransactionId=y, MiddleboxId=Beta, Credentials,
               RuleID=r, Policy Rule=[see below], Lifetime=eternal,
               Reason=accepted)

For the Request and Response both, the Policy Rule now consists of two
{Filter, Action} pairs.  The first pair is the one returned in the first
Response.  The second is for the outgoing flow:

Filter =
      Source addr = InternalHostaddr
	Source port= 80
	Source realm=Inside
	Map addr = 193.252.187.186
	Map port= 25000
	Map realm= Outside
	Dest addr= ANY
	Dest port= ANY
	Dest realm= Outside
	Protocol=TCP
	
Action= Allow
	
The server can now start receiving start receiving incoming connections, and
replying back to the external client.

The same message sequence is applicable to other transport protocols (UDP,
SCTP, ...), and to third-party control of the Middlebox.

5.2	Peer-to-peer communication with ad-hoc rendezvous

The message sequence for the Internal Server in this case looks the same as
in the previous case, except that the "Outside" address and port may be
specific values rather than ANY.

In the case where the "external" host is behind a firewall and wants to
predict its mapped source address, the outgoing {Filter, Action} pair it
sends in its Policy Rule Request looks like this:

Filter =
Source addr = External Host's addr
	Source port= External Host's port
	Source realm=External Host's realm
	Map addr = CHOOSE
	Map port = CHOOSE
	Map realm= Outside
	Dest addr= ANY
	Dest port= ANY
	Dest realm= Outside
	Protocol=TCP
	
Action= Allow

The response provides a specific Map Address-Port which the external host
can send to the internal host by way of the IM server.

To close the holes opened by Policy Rule y when the session is done, the
internal host deactivates it by modifying it to be empty:

   Middlebox Beta			Midcom Agent Alpha
                   <--------------------
      PolicyRuleRequest
          (Version, TransactionId=z, AgentId=Alpha, Credentials,
           RuleID=r, Policy Rule={}, Lifetime=0,
           Integrity=all-or-nothing) 

				  -------------------->
         PolicyRuleResponse
              (Version, TransactionId=z, MiddleboxId=Beta, Credentials,
               RuleID=r, Policy Rule={}, Lifetime=0,
               Reason=accepted)

Policy Rule Identifier r is now available for reuse.

-----Original Message-----
From: Taylor, Tom-PT [CAR:B800:EXCH] 
Sent: Tuesday, April 02, 2002 10:25 AM
To: [email-masked]
Cc: Aoun, Cedric [QPD:MA01:EXCH]
Subject: [midcom] MIDCOM SEmantics: Policy Rule Content

This is the theoretical section of the I-D Cedric and I are working on.  We
are still validating it against the various scenarios.

4	Structure And Comparison Of Policy Rules

In this note, a Policy Rule is defined to be a set of terms of the form
{Filter, Action}, the union of which defines the desired policy.  Any such
set can be refined into a canonical form in which the Filter part of each
{Filter,Action} term represents a rectangular prism (i.e. a box) in N-space,
where N is the number of components of the filter.  If two such filters are
compared for overlap, the zone of overlap, if any, will be another box.  See
the diagram below, where the area of overlap is marked with X's.

                  +-------------------------+
                  |     Filter 1            |
                  |                         |
                  |                         |
                  |            +-------------------------+
                  |            |XXXXXXXXXXXX  Filter 2   |
                  |            |XXXXXXXXXXXX             |
                  |            |XXXXXXXXXXXX             |
                  |            +-------------------------+
                  |                         |
                  +-------------------------+

Suppose now that these two filters are associated with actions which
contradict each other.  Then the decision rules used by the Middlebox will
decide which action will apply in the region of overlap.  By assumption,
these decision rules will be based on the combination of order of
specification and policy at the Middlebox.

There are two possible cases:

(1) The Policy Rule associated with each of the two {Filter, Action} pairs
must be installed completely or not at all.  In this case, if there is a
conflict between the two rules in the zone of overlap, the lower-priority
Policy Rule will be disallowed (if it was the later arrival) or deactivated
(if it was already installed).

(2) The Policy Rule which has lower priority in the zone of conflict allows
for partial implementation.  Thus the desired {Filter, Action} pair is
modified to exclude the zone of overlap.  There are two sub-cases:

(a) In the simpler case, the exclusion of the zone of overlap still leaves a
box in N-space.  This is true of Filter 2 in the diagram.  In this case, the
original {Filter, Action} pair is replaced by another {Filter', Action} pair
where Filter' defines the region outside the zone of overlap.

(b) In the more complex case, the exclusion of the zone of overlap leaves a
complex region rather than a simple box.  This is true of Filter 1 in the
above diagram.  In this case, the region can be partitioned into a set of up
to 2N simple boxes in N-space.  Thus the canonical outcome of the conflict
with respect to the original {Filter, Action} pair is a set of {Filter,
Action} pairs where Action is the same as in the original pair.

Policy rules are evaluated for conflict through a pairwise comparison of
their individual {Filter, Action} components.

Let us turn now to the detailed semantic content of the {Filter, Action}
pairs.  As the examples of section 4 illustrate, it is possible to represent
NAT and firewall policies using sets of uni-directional filters of the form
 
{<Source Address-Port>, <Map Address-Port>, <Destination Address-Port>,
Protocol} 

with suitable wildcarding.  Each Address-Port term has the detailed form
{Address, Port, Realm}.  Two wildcards are needed:

 - ANY is a placeholder for a value to be bound when a flow instance is
matched against the Policy Rule.

 - CHOOSE is a value to be assigned by the Middlebox at Policy Rule
installation time.  That is, each CHOOSE in a Policy Rule Request must be
replaced by a specific value in a Policy Rule Response.  CHOOSE must only be
used for components of <Map Address-Port>.

Our requirements indicate the need for two additional items.  It must be
possible on occasion for the filter to specify a range of ports rather than
a single port.  Moreover, it must be possible to constrain the parity of the
Map port assignment(s).  These requirements are satisfied by adding three
modifiers to the port components of the filter:

 - the Count modifier is an integer from 1 upwards.  If it is included in a
port component, it indicates that a range of ports is requested.  If the
filter provides a specific value rather than a wildcard for the port in
question, the port assignments begin with that value.  If Count is absent,
only one port is indicated.

 - the Step modifier must not be present unless the Count modifier is also
present.  It is an integer from 1 upwards indicating the increment to be
applied in determining port numbers for a port number range.  One example of
when Step would be needed is when allocating RTP or RTCP ports for layered
encoding.  In this example, Step would have value 2.  The default if Step is
absent is an increment of 1. 

 - the Parity modifier has values Odd or Even.  If it is included in a port
component, it indicates that the port (or the first port of a range) must
have the given parity.  If Parity is not specified, port assignment is
unconstrained.

Tom Taylor
[email-masked]
Ph. +1 613 736 0961 (ESN 396 1490)

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

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

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 03 Apr 2002 13:56:41 +0200

Tom-PT,

I'm glad midcom has gained momentum to focus on real things.

As for the overlapping rules: I'm very much in favor of the approach
#1, i.e., disallowing overlapping rules. I think MidCom's primary
purpose is to get apps over NATs/FWs for which this is good enough.
It is not good enough for a FW/NAT mgmt protocol, but that is not
what we are concerned with. Allowing overlapping rules would result 
in unnecessarily higher complexity of midcom servers. Simple is good.

Rather then priorities, I would prefer to use first-come, first-served 
conflict resolution then. 

-Jiri

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Thu, 4 Apr 2002 17:55:01 -0500

First, does the requirement have to be supported across different agents, or
does it just apply to one agent?  Secondly, could we consider the
requirement fulfilled if both the broader and the narrower filter had to
belong to the same Policy Rule?

-----Original Message-----
From: Sen, Sanjoy [NGC:B692:EXCH] 
Sent: Thursday, April 04, 2002 5:28 PM
To: 'Jiri Kuthan'; Taylor, Tom-PT [CAR:B800:EXCH]; [email-masked]
Cc: Aoun, Cedric [QPD:MA01:EXCH]
Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content

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.

Any comments?

Sanjoy

> From: Jiri Kuthan [mailto:[email-masked]]
> Sent: Wednesday, April 03, 2002 5:57 AM
> To: Taylor, Tom-PT [CAR:B800:EXCH]; [email-masked]
> Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content
> 
> 
> Tom-PT,
>

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 05 Apr 2002 01:04:10 +0200

At 12:27 AM 4/5/2002, Sanjoy Sen wrote:
>How will then the following requirement from Midcom requirements draft be satisfied? 

Perhaps by reading "should" as "there may exist valid reasons in particular 
circumstances to ignore a particular item, but the full implications must 
be understood and carefully weighed before choosing a different course."
(RFC2119).

>Whether you want it or not, there would be overlapping rulesets because the filterspec may overlap for different rulesets installed by independent agents. 

Why? Again, thats a matter of protocol scope. If we define MidCom to be
firewall/NAT opener, then overlaps are errors and can be as such denied.
If we define it as a management protocol, things are different -- but
MidCom is not a management protocol. Whereas some people may like
extending its scope, I am in favor of keeping things very simple.

-Jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 05 Apr 2002 03:01:20 +0200

At 01:46 AM 4/5/2002, Sanjoy Sen wrote:

>Jiri, 
>  Why wouldn't a network/firewall administration application be able to use the same Midcom protocol for opening/closing firewall pinholes? Nothing in the charter says that this out of scope. 

Sanjoy,

I think simplicity is good. If we focus on the issues which are indeed
compelling we will have good chances to come out with a usable protocol.
Building a management protocol is not precluded in charter, but it is
neither stated there. That makes me think that management protocols are
better discussed in a BOF in the management area.

>Also, what you're suggesting may be too retrictive. I can't possibly assume that all NAT's & firewalls will be Midcom-enabled at the same time. So there might be a situation where a Midcom agent would like to open pinhole in a firewall which is sandwitched between two NAT's which are not Midcom-aware. The Agent doesn't have any idea about the exact NAT binds that will be used on both sides of the FW but knows about the range of possible binds. There'll be overlap in this case between rulesets of agents controlling the firewall.

Well, I'm not sure whether we want to align midcom protocol design to such
cumbersome scenarios. If so, it should be probably documented in the
Midcom Scenarios I-D.

-Jiri

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Fri, 5 Apr 2002 10:45:13 -0500

If the purpose of the Midcom protocol is just to open holes, life is very
easy -- you can't ever get contradictions.  Can I confirm that the Action is
always "allow", and never "deny"?  (That's assuming that one closes holes or
at least reverts to default policy by deactivating the Policy Rule).

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Friday, April 05, 2002 9:34 AM
To: [email-masked]
Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content

I believe that the problem turns on how large a range of "rules" we want to 
allow.
My understanding of the goal is to allow a controlling entity to:
1) create some holes that will allow traffic to pass through the middle box
2) find out certain things about these holes (for NAT)
3) provide auxiliary processing for some packets.

Note that for cases 1 and 2, there is not much trouble.  Overlapping holes 
merely means that that hole remains open as long as either requestor needs
it.

As far as I can tell, it is only the "auxilliary processing" case that 
makes life complicated.  It would seem that we could again say "both" for
that.

We are not providing arbitrary policy management.
At the same time, declaring that two servers can not open overlapping holes 
in the same firewall / NAT would seem counter-factual.

Yours,
Joel M. Halpern

At 01:16 PM 4/5/2002 +0200, Juergen Quittek wrote:
>Sanjoy,
>
>--On 04 April 2002 17:04 -0600 Sanjoy Sen wrote:
>>
>>Inline.
>>
>>
>>Sent: Thursday, April 04, 2002 12:57 PM
>>To: 'Martin Stiemerling'
>>Cc: [email-masked]; Aoun, Cedric [QPD:MA01:EXCH]
>>That's two people so far who have said requests should be satisfied 
>>completely
>>or not at all.  Shall we take this as the working assumption?
>>
>>First-come-first-serve vs. policy hides another issue: how to allow
multiple
>>authorized agents to work on the same ruleset (requirement 2.2.7).
>>Our proposals so far assumed this was handled through a policy mechanism.
>>There is a distinction, of course, between two agents operating on the
same
>>Policy Rule Identifier (which is perhaps what 2.2.7 permits) and two
agents
>>defining identical rulesets with different Policy Rule Identifiers.
>>So I have a couple of questions for the WG:
>>
>>  1) Does the protocol address the possibility of two agents defining
>>     overlapping rulesets and if so, are conflicts handled on a
>>     first-come-first-served basis?
>>
>>[SS] The protocol has to allow overlapping rulesets because multiple
agents
>>are installing rulesets independently and there're bound to be overlaps
in,
>>say, the filter spec.  Question is, what happens when there is a 
>>contradiction.
>>Requirement 2.2.11 seems to suggest that we need to allow the later agent 
>>to win,
>>at least, under special circumstances. For example, a Midcom agent
installs a
>>ruleset allowing packets from the address range 100.10.*.* to pass
through,
>>but at a later time, the firewall administrator wants to create a ruleset
>>disallowing packets from 100.10.50.10. I would like to think that the 
>>firewall
>>administrator would have the last say. An administrator Agent has the
highest
>>priority.
>
>I did not yet consider the midcom protocol as the interface for a system
>administrator to consider the firewall. I think this taks includes
restricting
>the the midcom interface's access to firewall control. So if the
administrator
>wants to disallow packets from 100.10.50.10, he should do it by configuring
>the access rights of the midcom server running at the firewall, for example
by
>modifying the midcom serve configuration files.
>
>But maybe I'm wrong here. I considered midcom to be used for temporary
>configurations by users or applications but not as a mean for permanent
>configuration of the firewall as it is done by the administrator.
>
>So, I clearly vote for not having priorities in order to KISS. However, if
>the WG decides to support also administrator configuration running over
>a midcom protocol, then it should be enough to have exactly two priorities:
>administrator and user (and first-come-first-serve per priority).
>
>>
>>IMO, an Agent priority list makes sense, with an agent higher up in the
>>priority list can modify/revoke rulesets created by lower priority agents.
>>For agents of same priority, a first-come-first-serve approach may be more
>>suitable.
>>
>>  2) Does the protocol need a formal delegation capability, so that Agent
A
>>can tell the Middlebox that Agent B can make requests affecting Policy
Rule
>>Identifier x?
>
>I think we do not need this at all. First, the scenario would be rather
>a rare one to happen. Second this increases complexity significantly on
>server side and on client side. More state need to be kept an more message
>types are required. We should not overdesign the protocol and avoid all
>complexity that is not required by a strong usage scenario.
>
>    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
>
>
>>Here we would distinguish between sharing of authority (both Agent A and
>>Agent B can manipulate the Policy Rule) vs. handoff (Agent A gives up its
>>authority to Agent B).  Which one might we want, if we want either?
>>I visualize a message exchange of the form:
>>
>>[SS] Since we're requiring the Middlebox to report unsolicitated messages
>>to the Agent, we can do this in another way. When there is an attempt by
>>Agent B to install a ruleset which overlaps with and has contradictory
>>action(s) to one that has been installed by Agent A, then the Middlebox
can
>>send a notification message reporting this event to A with Agent B's id.
>>Agent A may or may not allow this. If disallowed, the Middlebox may either
>>reject B's request to install or suggests an alternative/modified ruleset
>>by sending B an error message.
>>
>>     Agent A                     Middlebox                  Agent B
>>
>>     Grant(Policy Rule Id x, Agent B)
>>     ------------------------------->
>>                                         Notify (Grant, Policy Rule Id x)
>>     Grant Acknowledge               --------------------------->
>>     <-------------------------------
>>                                         Notify Acknowledge
>>                                     <---------------------------
>>
>>Sorry about the really theoretical stuff -- it was something I had to
think
>>through clearly for myself, but I can see it wouldn't be generally
helpful,
>>so we can omit it or put it into an appendix.
>>
>>From: Martin Stiemerling [mailto:[email-masked]]
>>Sent: Thursday, April 04, 2002 8:58 AM
>>To: Taylor, Tom-PT [CAR:B800:EXCH]
>>Cc: [email-masked]; Aoun, Cedric [QPD:MA01:EXCH]
>>Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content
>>
>>Hi,
>>
>>please find my comments embedded in the text.
>>
>>Regards
>>Martin
>>
>>Tom-PT Taylor wrote:
>>
>>Yes, it is very theoretical. We should aviod such text for internet
>>drafts, because a lot of people won't even continue reading the entire
>>document.
>>
>>[...]
>>This sounds very complicated and with a lot of administrative overhead.
>>I prefer Jiri's idea of disallowing overlapping rules at all and using a
>>first come, first served scheme, instead of priorities. Should there be
>>any conflict, reject the latest policy rule request.
>>
>>>
>>Hmm, how to tell the agent, that his rule request has been fulfilled
>>only partial? My opinion is, that the agent wants exactly this policy
>>rule and if he can't get this, tell him!
>
>
>

---

From: [email-masked]
Date: Fri, 5 Apr 2002 11:32:02 -0600

I think what Tom is suggesting here would lead to the following
general operational scenario:

1) a middle-box "straight from the factory" by default allows all
pin-holes and/or translations to be established, though none are yet
actually established;

2) the network administrator, using a network management protocol, i.e.,
*NOT* the midcom protocol, defines what is permitted operationally,
i.e., an operating policy, probably by defining a whole bunch of deny
rules that define what is not permitted; the policy may be defined
directly in the middlebox or separately in a policy server that is
referenced by the middlebox.

3) the middlebox dynamically establishes pin-holes and/or translations,
either:
    3.1) implicitly (i.e., a packet shows up that does not match an
         existing ruleset); or
    3.2) explicitly (i.e., an application (agent) uses the midcom protocol
         to request one),
SO LONG AS the dynamically created pin-holes and translations are
permitted or not denied by the policy set by the administrator AND don't
conflict with previous pin-holes and translations;

4) the middlebox dynamically removes pin-holes and/or translations either:
    3.1) implicitly, when they time-out;
    3.2) explicitly, upon request from the application (agent) that
         established the pin-hole and/or translation, again using the
         midcom protocol; or
    3.3) explicitly, by the middlebox administrator, again using a network
         management protocol, *NOT* the midcom protocol.

I like this operational scenario because it nicely scopes what the midcom
protocol MUST do, i.e., just permit the establishment and removal of
pin-holes and translations by application (agents). Anything beyond that
is gravy, should be looked at with great skepticism, and if adopted into
the midcom protocol should be optional in middlebox implementations.

And, of course, ya have to deal with all aspects of security.

Jim

"Tom-PT Taylor"<[email-masked]>@ietf.org on 04/05/2002 09:45:13
AM

Sent by:  [email-masked]

To:   "'Joel M. Halpern'" <[email-masked]>, [email-masked]
cc:
Subject:  RE: [midcom] MIDCOM SEmantics: Policy Rule Content

If the purpose of the Midcom protocol is just to open holes, life is very
easy -- you can't ever get contradictions.  Can I confirm that the Action
is
always "allow", and never "deny"?  (That's assuming that one closes holes
or
at least reverts to default policy by deactivating the Policy Rule).

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Friday, April 05, 2002 9:34 AM
To: [email-masked]
Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content

Yours,
Joel M. Halpern

multiple
same
agents
agents
in,
installs a
through,
highest
restricting
administrator
by
A
Rule
can
think
helpful,

---

From: [email-masked]
Date: Fri, 5 Apr 2002 12:25:11 -0600

It seems to me that we're getting into an area here that might be
described as "conflict resolution between requests from different
applications / agents". IMHO, this can get real hairy, real quick,
and might best be declared to be out of scope for the midcom protocol,
at least for now.

That said, I have no problem with the middlebox, when presented with a
conflicting request, reporting to the "conflictor" and the "conflictee"
the identities of the other party in the conflict, IF THEY HAVE AUTHORIZED
THE MIDDLEBOX TO DO SO.

Anything beyond that, I believe, should be left to the applications /
agents to work out for themselves in some way not specified in the midcom
protocol, using some other protocol, not the midcom protocol. Then one
or the other or both would adjust their established or requested filters
with the middlebox accordingly, so they hopefully no longer conflicted.

Once we have some more experience with this, maybe we will want to add
something to version 2 of the midcom protocol (Remember, it is required
to be compatibly extensible, perhaps just for reasons like this.). If we
are going to deal with this now, I think we need to have some very, very,
very specific use cases to justify this capability, not just "navel
scratchings".

Also, as as I hinted in a separate e-mail, if a "big" capabiltiy in this
area were included in the midcom protocol, I would want it to be optional
in implementation so that, e.g., SOHO cable/DSL/ISDN middleboxes would not
have to implement it to be RFC compliant.

I think trying to deal with this now may be premature, but I could be
wrong.

Jim

"Tom-PT Taylor"<[email-masked]>@ietf.org on 04/05/2002 10:43:54
AM

To:   "'Martin Stiemerling'" <[email-masked]>, "Sanjoy
      Sen"<[email-masked]>
cc:   "'Jiri Kuthan'" <[email-masked]>, [email-masked], "Cedric
      Aoun"<[email-masked]>
Subject:  RE: [midcom] MIDCOM SEmantics: Policy Rule Content

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

> 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

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Fri, 5 Apr 2002 13:38:35 -0500

Well, if the conflict-free model you postulated in your previous note is
accepted by everyone as valid, we don't need to worry about this anyway.

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

Jim

-----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];

Martin
--
Martin Stiemerling

---

From: [email-masked]
Date: Fri, 5 Apr 2002 12:56:34 -0600

Tom,

The model I proposed in my previous note is not conflict free. Having
granted one filter request, a middlebox could very well be presented with
another conflicting request from the same or a different application
(agent). I suppose we could define filter capabilities to be so restrictive
that no conflicts were ever possible, but I'm skeptical that such a
definition is possible or useful.

I think we can agree that the middlebox cannot simply grant the
second request (unless it "undoes" the conflicting part of the first,
already granted, request; but I, for one, don't want to go there.). And
I wouldn't want it to reject the second request without some at least
minimal explanation of why it did so.

All I'm saying is that, sans compelling use cases to open the door of
conflict resolution, we should limit ourselves to what might be described
as "conflict identification", a necessary first step in the midcom protocol
if the application (agent)s are to resolve the conflict with mechanisms
outside of the midcom protocol.

Jim

"Tom-PT Taylor"<[email-masked]> on 04/05/2002 12:38:35 PM

Sent by:  "Tom-PT Taylor"<[email-masked]>

To:   James Renkel/MW/US/3Com
cc:   [email-masked]
Subject:  RE: [midcom] MIDCOM SEmantics: Policy Rule Content

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, April 05, 2002 1:25 PM
To: Taylor, Tom-PT [CAR:B800:EXCH]
Cc: 'Martin Stiemerling'; Sen, Sanjoy [NGC:B692:EXCH]; 'Jiri Kuthan';

Jim

-----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];

Martin
--
Martin Stiemerling

(See attached file: C.htm)

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Fri, 5 Apr 2002 14:08:28 -0500

OK, so you're saying in effect that in case of a conflict the newest rule is
ALWAYS rejected.  Am I right?

You're also saying that the diagnostic information, where authorized,
consists of the identity of the conflicting agent.  I'm not sure this will
be very helpful, given that agents could be servers somewhere in the middle
of the network.  Why not identify the scope of the conflict instead?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, April 05, 2002 1:57 PM
To: Taylor, Tom-PT [CAR:B800:EXCH]
Cc: [email-masked]
Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content

Tom,

Jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, April 05, 2002 1:25 PM
To: Taylor, Tom-PT [CAR:B800:EXCH]
Cc: 'Martin Stiemerling'; Sen, Sanjoy [NGC:B692:EXCH]; 'Jiri Kuthan';

Jim

-----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];

Martin
--
Martin Stiemerling

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Mon, 8 Apr 2002 10:06:52 -0400

A couple of comments here:

1) You talk of more specific rules taking precedence ove less specific ones.
But what about cases of overlap, as illustrated in my theoretical note?
Would the zone of overlap be considered to be "more specific"?

2) I think your requirement for one agent (B) to act on behalf of another
(A) can be met if agent (B) takes on the identity of agent (A).  This
wouldn't have a direct impact on the protocol -- sharing of identities and
credentials would happen behind the scenes -- but must have implications for
our security analysis.  Bob, would this meet requirement 2.2.7 in your view,
or do you prefer a formal "B can work on this too" in the original Policy
Rule Request? 

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]]
Sent: Friday, April 05, 2002 3:04 PM
To: Taylor, Tom-PT [CAR:B800:EXCH]; 'Martin Stiemerling'
Cc: [email-masked]; Aoun, Cedric [QPD:MA01:EXCH]
Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content

There have been a lot of comments on this thread, but I want to go back to
the original questions and make a few points which may also apply to later
comments.

----- Original Message -----
From: "Tom-PT Taylor" <[email-masked]>

> completely or not at all.  Shall we take this as the working assumption?

First, I think that each request from the agent should be atomic. Partial
rule installation just makes everything too complex.

multiple
> authorized agents to work on the same ruleset (requirement 2.2.7).  Our
> proposals so far assumed this was handled through a policy mechanism.
There
> is a distinction, of course, between two agents operating on the same
Policy
> Rule Identifier (which is perhaps what 2.2.7 permits)

That is exactly what 2.2.7 is talking about. The motivation for allowing
multiple agents to work on the same rule came from the need for redundancy
and reliability in the application layer (i.e. the agents). I don't think
the case would be that both agents would create/install the rule, but rather
one would create it and the other might modify or remove if the second agent
became responsible for the rule because the first agent died.

> and two agents
> defining identical rulesets with different Policy Rule Identifiers.  So I
> have a couple of questions for the WG:
>

I think first-come-first-served is the right approach. However, I would see
a conflict only when the filter was identical. We had talked about having
overlapping rules, but one would have a "more specific" filter. For example,
a rule might allow a whole range of addresses and ports thru, but there
might be rules to deny more specific or narrower ranges of addresses and
ports. The more specific filter would take precedence when deciding what to
do with a specific packet which matched multiple rules (i.e. their filters).

>
>  2) Does the protocol need a formal delegation capability, so that Agent A
Rule
> Identifier x?

I don't think this is what we want. For the case of a failure of one agent
in a redundant pair, the crashed agent would not be able to "delegate" the
rule to the other agent. This relationship has to be established either by
policy in the middlebox, or in rule creation/modification with the semantics
of "BTW, allow agent X to also mess with this rule, and send it
notifications about this rule too".

cheers,
(-:bob

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Fri, 12 Apr 2002 13:45:45 -0400

Oops, had a two-hour interruption in the middle of answering this and forgot
what I had to put into the final filter spec to make my point.  The second
filter spec should look like this:

Source Address: <specific>
Source Port: <specific>
Map address: <specific>
Map port: <specific>
Destination Address: <specific>
Destination Port: <specific>
Protocol: TCP
Action: allow

-----Original Message-----
From: Taylor, Tom-PT [CAR:B800:EXCH] 
Sent: Friday, April 12, 2002 1:34 PM
To: 'Bob Penfield'; [email-masked]
Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content

I partly agree with you.  When the Agent is asking for a mapping to be
granted, the Map Address-Port is a return value, not really part of the
filter.  Since we are talking semantics rather than protocol notation, the
distinction should be made clear.

On the other hand, when a mapping has been granted previously and the Agent
is now enabling a specific flow, the Map-Address-Port is legitimately part
of the flow specification.

To show what I mean, suppose we are talking about a rule allowing inbound
flows to a service.  To set this up, the Agent issues a request like this:

Source Address: Any
Source Port: Any
Destination Address: <specific>
Destination Port: <specific>
Protocol: TCP
Action: new destination address-port

The response provides a specific Map-Address-Port as requested.

Now consider a rule allowing inbound flows through that mapped address-port,
from a specific external address.  (To avoid extraneous issues, assume it is
replacing the previous rule.)  The rule should have the form:

Source Address: <specific>
Source Port: <specific>
Destination Address: <specific>
Destination Port: <specific>
Protocol: TCP
Action: allow

One other point: do your actions "new source address" and "new destination
address" mean what I think they mean:
 - new source address: please assign an address which will appear as the
external source of flows originated from inside
 - new destination address: please assign an address which will appear as
the external destination of flows being forwarded to the inside?

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]]
Sent: Friday, April 12, 2002 10:12 AM
To: Taylor, Tom-PT [CAR:B800:EXCH]; [email-masked]
Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content

----- Original Message -----
<snip>
> {<Source Address-Port>, <Map Address-Port>, <Destination Address-Port>,

I would think that the filter would contain only the data used to match
packets. The Map Address-Port would part of the action. Also, I don't think
a single Map Address-Port is sufficient.

I see the parameters in the Filter as follows:

    Source Address-Port
    Destination Address-Port
    Transport Protocol (UDP, TCP, etc)

The actions would include:

    New Source Address-Port
    New Destination Address-Port
    Allow/Disallow

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Fri, 12 Apr 2002 14:50:39 -0400

Would the same Agent install both rules?

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]]
Sent: Friday, April 12, 2002 2:24 PM
To: Sen, Sanjoy [NGC:B692:EXCH]; Taylor, Tom-PT [CAR:B800:EXCH]; Jiri
Kuthan; Martin Stiemerling
Cc: [email-masked]; Aoun, Cedric [QPD:MA01:EXCH]
Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content

I am sorry, but the requirement was there for a very strong operational
reason. For example, it should be possible to say something like:

1) disallow UDP on port 3456 in general
2) allow UDP on port 3456 if the source is X and the destination Y.

-- Christian Huitema

-----Original Message-----
From: Sanjoy Sen [mailto:[email-masked]] 
Sent: Friday, April 12, 2002 10:21 AM
To: Tom-PT Taylor; 'Jiri Kuthan'; 'Martin Stiemerling'
Cc: [email-masked]'; Cedric Aoun
Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content

I support this as a good compromise. We should disallow contradictions in
overlapping rulesets (and resolve on a FCFS basis). But, we should allow
overlapping rulesets if there's no contradiction.  
> Sent: Friday, April 12, 2002 7:52 AM 
> To: 'Jiri Kuthan'; 'Martin Stiemerling'; Sen, Sanjoy [NGC:B692:EXCH] 
> 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 
> 
> 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. 
> 
> 
> Sent: Friday, April 12, 2002 5:30 AM 
> To: Taylor, Tom-PT [CAR:B800:EXCH]; 'Martin Stiemerling'; Sen, Sanjoy 
> [NGC:B692:EXCH] 
> 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 
> >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. 
> > 
> > - 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). 
> > 
> >From: Martin Stiemerling 
> [<mailto:[email-masked]>mailto:Martin.Stiemer 
[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

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 12 Apr 2002 12:16:13 -0700

The broader rule will often be a provisioned rule, but that is not necessary true.

The narrower rule will most likely be dynamic, but that is also not necessarily true -- we could for example have a provisioned rule that excludes a specific address from interacting with the outside.

-- Christian Huitema

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]] 
Sent: Friday, April 12, 2002 12:08 PM
To: Christian Huitema; Sanjoy Sen; Jiri Kuthan; Martin Stiemerling
Cc: [email-masked]; Cedric Aoun
Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content

Then perhaps we do have to debate decision rules, and can't just live with first-come, first-served.  However, let me make one last try: could the broader rule be provisioned, and the narrower one installed by the Midcom protocol?
-----Original Message----- 
From: Christian Huitema [mailto:[email-masked]] 
Sent: Friday, April 12, 2002 3:01 PM 
To: Taylor, Tom-PT [CAR:B800:EXCH]; Sen, Sanjoy [NGC:B692:EXCH]; Jiri 

Not necessarily. From an operational point of view, it is important to not tie a rule to an agent -- we debated that at length last year. 
-----Original Message----- 
From: Christian Huitema [mailto:[email-masked]] 
Sent: Friday, April 12, 2002 2:24 PM 
To: Sen, Sanjoy [NGC:B692:EXCH]; Taylor, Tom-PT [CAR:B800:EXCH]; Jiri 
I am sorry, but the requirement was there for a very strong operational reason. For example, it should be possible to say something like:
-----Original Message----- 
From: Sanjoy Sen [mailto:[email-masked]] 
Sent: Friday, April 12, 2002 10:21 AM 
To: Tom-PT Taylor; 'Jiri Kuthan'; 'Martin Stiemerling' 
Cc: [email-masked]'; Cedric Aoun 
Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content 
I support this as a good compromise. We should disallow contradictions in overlapping rulesets (and resolve on a FCFS basis). But, we should allow overlapping rulesets if there's no contradiction.  
[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

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 12 Apr 2002 12:00:35 -0700

-----Original Message----- 
From: Sanjoy Sen [mailto:[email-masked]] 
Sent: Friday, April 12, 2002 10:21 AM 
To: Tom-PT Taylor; 'Jiri Kuthan'; 'Martin Stiemerling' 
Cc: [email-masked]'; Cedric Aoun 
Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content 
[email-masked]]

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Fri, 12 Apr 2002 15:16:46 -0400

I'm happy enough with that as a general direction, though it seems to me
we're back almost where I started.  The original concern expressed was that
I expected too much provisioning on the Middlebox.  Maybe by not specifying
how the Middlebox makes its decisions we get around that and satisfy
everyone.

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]]
Sent: Friday, April 12, 2002 3:09 PM
To: [email-masked]
Cc: [email-masked]'
Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content

At 11:48 AM 4/12/02 -0700, Ted Hardie wrote:
>        Possibly my memory is faulty here, but I thought we had
>previously agreed that an override was a possibility for a standard
>rule.  

We did discuss it, and there was substantial agreement that
that should be the case.

>        I have not found that discussion in the archives after
>a quick scan, so it is possible I am mis-remembering the conculsion.
>If that was the conclusion, I think we have a slightly more
>complex problem, as there is no way for an agent to know in
>advance that the rule is overlapping.  

That touches on a question I've been having about this discussion,
actually.  I tend to think that whether or not a middlebox can
honor overlapping requests is out-of-scope.  We do need for
the middlebox to be able to provide a meaningful response to a
request, but we need to avoid overspecifying the behavior of
the middlebox itself.

Melinda

---

From: "Reinaldo Penno"<[email-masked]>
Date: Fri, 12 Apr 2002 12:17:02 -0700

Sorry if this questions was already hashed on this big thread,

but who will check and decide when rules overlap or are a complete subset of
one another? Or is it just out-of-scope? For simple rules (5-tuples type) it
might be easy, but if we have more complex rules it might be impossible. 

Even for 5-tuple there might be some border cases when you start installing
rules for protocols that can use both TCP and UDP like SIP, or use
domainnames instead of addresses.

thanks,

Reinaldo

>To: 'Christian Huitema'; Sen, Sanjoy [NGC:B692:EXCH]; Jiri Kuthan;
>Martin Stiemerling
>>> How will then the following requirement from Midcom 
>requirements draft 
>>> be satisfied? 
>>> ***** 
>>> 2.2.11. 
>>>

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Mon, 15 Apr 2002 15:24:46 -0400

I agree -- it doesn't guarantee you anything unless you know what else is in
the queue.  On the other hand, giving that information to every agent that
asks for it means privacy of individual communications is lost.  I'm just
trying to salvage something from the description of operation Andrew Molitor
gave us.

-----Original Message-----
From: Scott Brim [mailto:[email-masked]]
Sent: Monday, April 15, 2002 10:00 AM
To: [email-masked]
Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content

On Sun, Apr 14, 2002 10:53:41AM -0400, Tom-PT Taylor wrote:
> Let me propose this to ensure determinsitic behaviour:
> 
> (1) The Middlebox must support a queue model of rules.
> 
> (2) New entries can be added either at the head of the queue (processed
> first when looking for a match) or at the tail of a queue (processed last
> when looking for a match).
> 
> (3) Existing entries can be deleted from anywhere in the queue.

What is the engineering reason for this ordering?  I mean, yes, this
would make behavior deterministic, but does it make the middlebox do
what you want?