Subject: RE: [midcom] policy & duration

From: "Fleischman, Eric W" <[email-masked]>
Date: Wed, 8 Aug 2001 02:58:29 -0700

I see OPES and midcom addressing very dissimilar problems. I do not view the problems of enhancing web services (OPES) as directly related to the problems of opening pinholes through perimeter devices in a manner consistent with enterprise policies (midcom). I therefore do not think that OPES has a role in providing feedback to midcom documents that is any more relevant than the insights coming from other IETF WGs. Thus, even a "dating relationship" is unnecessary.

> ----------
> From: 	Melinda Shore[SMTP:[email-masked]]
> Sent: 	Wednesday, August 08, 2001 1:24 AM
> To: 	[email-masked]; [email-masked]; Michael W. Condry
> Cc: 	[email-masked]
> Subject: 	Re: [midcom] policy & duration
> 
> > From: "Michael W. Condry" <[email-masked]>
> > To: <[email-masked]>; <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Wednesday, August 08, 2001 3:12 AM
> > Subject: Re: [midcom] policy & duration
> 
> 
> > Do you think that alignment between OPES policy and MidCom policy
> > concepts should be applied where appropriate?  If so, should the document
> > not reflect this?
> 
> I do think that there's value in trying to keep these aligned,
> and it would probably be useful to get some feedback on our 
> documents from OPES.  In the interests of keeping our work
> moving forward, it would probably be best to regard midcom
> and OPES as dating rather than married.
> 
> Melinda
> 
> 
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/midcom
> 

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

---

From: "Michael W. Condry" <[email-masked]>
Date: Wed, 08 Aug 2001 06:53:21 -0700

I agree about the dissimilar problem space.
However, I still stand by the position that IF there areas of problem overlap,
such as some policy matters, that ignoring each others requirements
is a beneficial strategy (or "Dating Relationship").

At 02:58 AM 8/8/2001, Fleischman, Eric W wrote:
>I see OPES and midcom addressing very dissimilar problems. I do not view 
>the problems of enhancing web services (OPES) as directly related to the 
>problems of opening pinholes through perimeter devices in a manner 
>consistent with enterprise policies (midcom). I therefore do not think 
>that OPES has a role in providing feedback to midcom documents that is any 
>more relevant than the insights coming from other IETF WGs. Thus, even a 
>"dating relationship" is unnecessary.
>
> > ----------

Michael W. Condry
Director,  Network Edge Technology

---

From: "Sanjoy Sen" <[email-masked]>
Date: Wed, 8 Aug 2001 10:50:45 -0500

There seems to be deviation here from the original purpose of the policy
function in the MIDCOM context, which was only to help the Middlebox
authorize the resource request from a Midcom Agent. It seems to me that
"Open pinholes" is not a valid example of policy function in the Midcom
context, but "Is this Midcom Agent allowed to open pinholes?" is a valid
policy function. This will require the Midcom Agent present some form of id
to the Middlebox along with the type of resources requested (which the
Middlebox may send to the Policy server for verification). 

Comments?  

> -----Original Message-----
> From: Eliot Lear [mailto:[email-masked]]
> Sent: Tuesday, August 07, 2001 10:43 AM
> To: [email-masked]
> Subject: [midcom] policy & duration
> 
> 
> 
> In our bar-fob we had a number of issues with policy.  i have 
> promised to
> provide some words to help improve the situation.  I hope this does. 
> Please note that there is a trivial case hidden in these requirements,
> obviating the need for a policy server in many instances.  Thus the
> wording allows for a fairly flexible architecture.  Don't 
> understand the
> policy conditions?  Go ask the policy server.
> 
> This information supersedes section 4.3 of the requirements 
> document and
> augments (and will need to be reconciled with) sections 2.9 
> and 6 of the
> framework document.  The wording here will need to be further 
> reconciled
> with the policy documents.
> 
> Please note that I have not addressed what information is 
> returned to the
> midcom agent.  That is an important topic and it needs to be better
> understood.
> 
> I've also taken a stab at rewriting the duration discussion.  
> There may be
> lots of text we can borrow from the policy people on this subject.
> 
> --
> 
> 4.3  Policy
> 
> Each middlebox decision is made based on either configured 
> policy or by
> querying a policy server.  While it is not within the midcom rubric to
> specify policy configuration methods, the actual policy configuration
> itself is important to discuss.
> 
> A policy statement consists of one or more policy conditions 
> and a policy
> action.[policy]
> 
> 4.3.1 Policy conditions
> 
> Some policy decisions, such as those based on 5-tuple simple 
> access lists
> are likely to be made by a middle box.  Other decisions, however, are
> likely to be more complex.  Hence we propose a nuanced approach that
> allows the policy function to be split.
> 
> The midcom agent MUST be able to satisfy informational 
> requirements of the
> policy conditions in a policy statement in order for the 
> policy server to
> make a decision.  Therefore, a structured exchange that contains those
> components MUST occur between the midcom agent and the middlebox, both
> query and response.  In as much as a policy server is 
> required to resolve
> the policy conditions, a structured exchange MUST also occur 
> between the
> middle box and the policy server.
> 
> If a middle box acts as its own policy server, it MUST understand any
> policy information needed to execute a policy statement.  Put 
> another way,
> it MAY discard any policy information that it doesn't 
> understand so long
> as that information is not required to make a policy decision.
> 
> If the middle box does not understand all of the policy conditions, it
> MUST refer the request to a policy server.  It is a 
> configuration error to
> have a policy condition that neither the middle box nor the 
> policy agent
> can evaluate.
> 
> A middle box SHOULD understand, at a minimum, policy conditions that
> contain the interfaces involved, protocol, source address and port,
> destination address and port, all of which with the exception 
> of protocol
> and interfaces MUST be capable of being expressed as a range 
> of values. 
> This is the trivial case, necessary to deploy a middlebox without the
> assistance of a policy server.
> 
> One should expect a middle box that understands a given 
> policy condition
> to police it.  However, we do not require it.
> 
> 4.3.2 Policy actions
> 
> Policy actions are those actions associated with a set of policy
> conditions in a policy statement.  Examples might be "open a 
> pinhole" or
> "return NAT bindings for a given system".
> 
> The middle box MUST understand the policy action it is to take.  The
> semantics and syntax of each of those policy actions MUST be 
> documented in
> a standard.
> 
> Hence, policy information SHOULD be encoded in a standard form that is
> possible for a middle box to decode, even if it cannot evaluate each
> policy condition.
> 
> Examples of policy statements can be found in [POLICY].
> 
> X Duration
> 
> Decisions made by middle boxes MUST have a specific duration.  That
> duration MUST include a time interval or a set of actual 
> dates and times,
> and MAY include additional termination conditions.  Examples of
> termination conditions include an exchange of TCP FINs, the 
> excessive use
> of bandwidth, or the exchange of unauthorized content.  A 
> midcom agent MAY
> request a change in duration, but the decision of the middle box, like
> every other decision will be bound by policy.
> --
> Eliot Lear
> [email-masked]
>

---

From: Scott Cadzow <[email-masked]>
Date: Wed, 8 Aug 2001 18:26:47 +0200

In order to build an appropriate function it is essential to ensure that it
meets the context it is built for. The requirements work has to be allowed
to question the entire context and to refine a set of requirements for
MIDCOM that are unique to it. It is also fair to determine therefore what
policy functions are managed in this framework and thence in the resulting
protocols. In other words lets discuss the impact without narrowing our
scope too quickly.
 
Scott

-----Original Message-----
From: Sanjoy Sen [mailto:[email-masked]]
Sent: 08 August 2001 17:51
To: [email-masked]'; [email-masked]
Subject: RE: [midcom] policy & duration

Comments?  

> From: Eliot Lear [ mailto:[email-masked] <mailto:[email-masked]> ] 
<http://www1.ietf.org/mailman/listinfo/midcom>

---

From: "Reinaldo Penno" <[email-masked]>
Date: Wed, 8 Aug 2001 17:06:11 -0700

Hello Andrew,

> 	I think it's important to figure out what those essential
> interactions are between your SIP code and the routing processes,
> interface manager, firewall, etc. Presumably the SIP code interacts
> with many things non-SIP, some of those things are sort of 
> network-ish,
> and some of THOSE things might naturally fall into a middlebox.
> 
> 	Whatever interactions can be reasonably imagined between
> say, SIP code and such middleboxy non-SIP things should be well
> understood before we go much further. The point of MIDCOM is, to
> first order, to develop a protocol expressive enough to capture
> those interactions. If we fail to produce something powerful enough
> for, say, the SIP community, we have failed entirely. 

We are in agreement. 

> 
> 	I don't actually know what, apart from 5-tuples and masks
> for them needs to get carted around in these interactions. That much
> information seems to work fairly well for pinholes and NAT bindings,
> at any rate. Well, it's nice to be able to carry around things
> like expected bandwidth and pinhole lifetime and whatnot, is this
> the kind of thing you mean? 

I simpler example is interface. 

Or do you want to open a pinhole for
> RTP traffic, and be able to specify approximately what RTP traffic
> looks like BEYOND 'UDP traffic from that place to this other place'?

Yes.

> Things like size of packet, expected values at expected offsets in
> the payload?

Yes.

thanks,

Reinaldo

---

From: "Sanjoy Sen" <[email-masked]>
Date: Wed, 8 Aug 2001 19:32:30 -0500

> 
> 	This has ABSOLUTELY NOTHING to do with the "policy" implemented
> by the middlebox in the form of pinholes and NAT binding. I 
> suggest the
> phrases 'Agent Policy' and 'Traffic Policy' to distinguish 
> between these
> two utterly disjoint notions, in contexts where it may not be clear.
> 

I agree.

---

From: "Reinaldo Penno" <[email-masked]>
Date: Wed, 8 Aug 2001 17:37:45 -0700

Hello Andrew,
 
just adding some points on what we disucssed based on my reading of the
charter...
 
IMO MIDCOM should be a protocol that is general or extensible enough so that
I can inform the firewall how to identify, for instance, RTP packets or more
generally offsets as you said. 
 
It seems some people only want to solve specifically "how to pass SIP
through a firewall". This is very evident from the fact that some people
think 5 tuple is enough. If we are thinking about getting any type of ALGs
from the middlebox, put on a MA and still have the same funcionality,
clearly this is not enough.
 
The charter of the group is very generic. If what we want to solve is how to
pass SIP through a firewall, then we need to change  the charter to
something like "SIP Firewall Transversal Group", cause we are clearly not
making it general/extensible enough.
 
thanks,
 
Reinaldo

-----Original Message-----   
From: Penno, Reinaldo [SC9:T327:EXCH] 
Sent: Wednesday, August 08, 2001 5:06 PM
To: 'Andrew Molitor';  <mailto:[email-masked]'> [email-masked]'  
Subject: RE: [midcom] policy & duration

Hello Andrew, 

We are in agreement. 

Yes. 

Yes. 

thanks, 

Reinaldo

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 9 Aug 2001 03:07:03 -0700

> From: Melinda Shore [mailto:[email-masked]]
> Sent: Thursday, August 09, 2001 3:03 AM
> To: Bob Penfield; Fleischman, Eric W; 'Andrew Molitor'; midcom; Penno,
> Reinaldo [SC9:T327:EXCH]
> > From: "Bob Penfield" <[email-masked]>
> >> From: "Fleischman, Eric W" <[email-masked]>
> > To: "'Andrew Molitor'" <[email-masked]>; 
> <[email-masked]>; "'Reinaldo
>  
> > > If a five tuple is not enough information to identify a 
> pinhole, what
> > would be enough?
> > 
> > ingress realm (interface or set of interfaces on which the 
> packets will
> > arrive)
> > source address or address mask or address prefix
> > source port or range of ports
> > destination address or address mask or address prefix
> > destination port or range of ports
> > transport protocol
> 
> I think we need to allow for extremely general filter descriptions,
> which may include well-understood things like protocol and port
> number but which may also include arbitrary length data at arbitrary
> offsets.  Consider the bpf filter machine.

Totally agreed.

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 9 Aug 2001 03:17:38 -0700

> Sent: Thursday, August 09, 2001 2:56 AM
> To: lear; Scott Brim; Mark Duffy
> Cc: midcom
> > Mark Duffy:
> > Not only that, but the directionality is already an aspect 
> of the existing
> > firewall functionality we are providing control over.  I too believe
> > directionality should be included.
> 
> I think that functionality will be very, very hard to
> replicate (i.e. "impossible to do") without introducing
> network layer topological and routing information into the
> midcom agent.  This is particularly a headache when the
> middlebox has more than two interfaces.  Directionality is
> implicit in the source and destination addresses in the packet
> header and a middlebox with more than one interface already
> knows how to route.

Hello Melinda,

I am not sure if I follow your argument, but how do you propose to solve,
for instance, a scenario where two customers connected to same middlebox
have overlapping IP address and are going to same destination? Think of
these subscribers as dynamic so that their interface identifier changes.
Anyway, there are several variations for this scenarios if you think of
network based Firewalls, wireless, etc

Now, going back to the point to my discussion with Andrew, we have to assess
what kind of funcionality a MA cannot "mimic". Or if can can, at what cost.
Then we should be very explicit of what subset scenarios midcom propose
solve based on what amount of information of its "surrondings" it should
have (for instance, network layer information as you pointed out). 

regards,

Reinaldo

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 9 Aug 2001 06:49:19 -0700

Hello,

> From: Paul Sijben [mailto:[email-masked]]
> Sent: Thursday, August 09, 2001 6:45 AM
> To: Melinda Shore
> Cc: [email-masked]
> Melinda,
> the issue is clearer when you also address the point that is 
> outside the
> scope of MIDCOM, namely discovery of middleboxes. 
> 
> If you do not address that problem you have *no* idea where 
> the flows are
> going to end up and you can only push a generic policy to *all*
> middleboxes in your network rather than send clear commands 
> to *one* box.
> Obviously, this does not scale. 
> 
> So assuming sufficuently large networks that make midcom deployment
> interesting (rather than stuffing all application intelligence in the
> firewall), you need to know where the flow is going to hit a 
> middlebox and
> (assuming middleboxes with more than 2 interfaces) you need 
> to know where
> the flow needs to go to go.

Yes, good point. Cedric wrote a draft about this. 

> 
> This makes the midcom agent party to the network topology 
> information as
> far as it needs to know. 
> 
> Now, I am OK that we leave the aspect of getting that kind of 
> information
> to the agent out of the discussion but we can hardly ignore the larger
> architectural impact.  
> 
> Paul
>

---

From: Mark Duffy <[email-masked]>
Date: Thu, 09 Aug 2001 08:46:20 -0400

I second what Reinaldo wrote.  Specifying interface/realm/direction/etc
may not be as important with simple 2-interface middleboxes, but for
larger/ more complex MBs such as those with many interfaces and
implementing different policies on them, it is key.  

Consider a network based mb that is providing NAT to multiple unrelated
domains, each using network 10.  The direction is not implicit in the
addresses (not unambiguously anyway). 

-Mark

At 03:17 AM 8/9/01 -0700, Reinaldo Penno wrote: 

<excerpt>

> From: Melinda Shore [<<mailto:[email-masked]>mailto:[email-masked]] 

Hello Melinda, 

Now, going back to the point to my discussion with Andrew, we have to
assess what kind of funcionality a MA cannot "mimic". Or if can can, at
what cost. Then we should be very explicit of what subset scenarios
midcom propose solve based on what amount of information of its
"surrondings" it should have (for instance, network layer information as
you pointed out). 

regards, 

Reinaldo 

<<http://www1.ietf.org/mailman/listinfo/midcom>http://www1.ietf.org/mailman/listinfo/midcom 

</excerpt><<<<<<<<

---

From: John LaCour <[email-masked]>
Date: Thu, 9 Aug 2001 07:18:08 -0700

There are many types of policy decisions a middlebox will
have to make.  I suspect in many implementations many of
them will be implicitly allowed.

For example:
- Which Agents are allowed to talk to me?
- What types of requests can they make?
- Is a specific request allowed?
- How does a middlebox resolve conflicting requests
  from 2 or more agents?
- How does a middlebox resolve conflicting requests
  from Agents and other sources (ie. administratively
  set static policies - eg. CLI)

Its not clear to me what the scope is of our discussion
on policy and policy servers in the drafts.  Changes
should make clear what the scope is of the discussion
and also why we even care.

My preference is to keep the scope limited to authorizing
Agents and authorizing Agents to ask for certain types
of requests and leave.  I don't think any thing else
remotely has any bearing on the protocol.

-John

> Sent: Tuesday, August 07, 2001 8:43 AM
> To: [email-masked]

---

From: "Sanjoy Sen" <[email-masked]>
Date: Wed, 15 Aug 2001 10:11:46 -0500

Since there'll be both types of implementations in the market, can we not
make the direction (or Realm) an optional element in the Midcom protocol
instead of a mandatory one? 

Or, even if the protocol element is there, a Middlebox implementation with
the capability to determine the direction, will chose to ignore it (i.e.
Middlebox's decision is final). 

Sanjoy

> From: Mark Duffy [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2001 8:25 AM
> To: Jiri Kuthan; Andrew Molitor; [email-masked]
> >I'm glad you gave this specific example. It shows the choice 
> of putting
> >direction-guessing-logic in agent. The protocol conversation 
> could then
> >look like "A: please, allocate a translation from address A in realm
> >RA to address B in RB. MB: Yes, sir." The opposite choice is 
> to have the
> >piece of logic in the middlebox. Fictive conversation 
> example: "A: Please,
> >allocate a translation from A to B. MB: No translation needed."
> >
> >Our implementation takes the second way. Why? Because we have limited
> >manpower and do not want to replicate the same 
> direction-guessing-logic 
> >in every possible agent. 
> 
> Jiri, no matter how smart the middlebox is, doesn't each agent need
> sufficient topological information that it can determine 
> which middlebox to
> make a request of?  Given that the agent must know that, it 
> seems to me to
> be a very small increment in knowledge for the agent to know 
> the direction
> of the flow relative to that middlebox.
> 
> -Mark
> 
>

---

From: "Cedric Aoun" <[email-masked]>
Date: Thu, 16 Aug 2001 17:28:33 +0100

I don't know if this has been covered or not ..., if sorry apologies for the
spam.

We should not consider the simplistic MB approach.
Let's consider this practical example:

Alice is part of VPN A and Bob is in VPN B . Here I'm talking of IP VPN and
Telephony VPNs.
If Alice calls BOB, you know from your application translation (E164 or
through domain names) that you are going outside of your VPN.
Assuming that MB discovery is not used, you will configure on the agent that
users of telephony VPN A are behind Middle Boxes x,y and z.
Based on the translation of the uri or the E164 number, the agent knows that
it is an extra VPN call (again telephony VPN).Now it has to discuss MIDCOM
with one of the MBs.

1- By looking through the *crystal ball* (:-) the agent knows that y is the
MB to talk to. 
The problem is that MB y is a provider provisioned MB where other realms
overlap on the address realm of VPN B (here I'm talking of IP VPN). How can
I use the standard matching expression to identify the flow (i.e 5 tuple) ?

By some way I need to tell my MB y that I'm talking of traffing flowing from
realm B to the outer realm, the outer realm is probably the registered
address realm (i.e. public realm), in case it is not I will need to indicate
it because maybe it is overlapped by another (or several realms) that MB y
is connected to; thus requiring the outer realm id.

This is the reason to have the realm identifier(s) in the n tuple.
Since we are already configuring application client information on the
application servers (user id ...), the realm id will not be such an
overload.

In case Alice calls Pat who is in telephony VPN A, the MA knows that it
doesn't need to get in touch with the MB.
I don't know if could use the same analogy to other applications or not (any
comments ?)

I tried to raise the concerns/reasons relevant to topology, I think that
they are quite clear in this example (hopefully).

Cedric
-----Original Message-----
From: Jiri Kuthan [mailto:[email-masked]]
Sent: Monday, August 13, 2001 5:26 PM
To: Mark Duffy; Mark Duffy; [email-masked]; Scott Brim
Cc: [email-masked]
Subject: Re: [midcom] policy & duration

Mark,

I am still sceptic about agent's ability to figure out the direction.
In the example I gave before agents actually do not know. The only thing
a SIP proxy surely knows is destination address and port number of media. 
(It also might try to guess source IP address, though guessing might fail). 
So it might try to infer direction from the 5-tuple. Doing so is 
however not app-specific and might be done in middleboxes as well.

Consider the following example: two SIP phones which are registered with a
company's
SIP server are temporarily in an external network. Which means there is no
need
for pinholes at all if they want to speak to each other! Who will figure it
out?
I doubt there is something useful for determining the direction what a SIP
proxy knows 
a middlebox does not. A middlebox can be configured to guess which IP
addresses is external and which not. Doing the same in every agent 
is lot of work which is perhaps not needed.

This is where my doubts for use of interfaces come from. 

-Jiri

At 12:57 PM 8/10/2001, Mark Duffy wrote:
>In general, a mb has no idea what direction anything *wants* to go in.  All
>it does is open pinholes etc at the behest of agents.  If the agent, with
>the applic. intelligence, can't determine that, then probably no one can --
>maybe in that case the agent should just ask the mb for both directions.
>>From the point of view of the typical mb, a 5-tuple in one direction is
>completely different from the same 5-tuple in the opposite direction.  If
>the agent via the midcom protocol cannot express that difference, then the
>overall system is essentially dumbed-down to that level.  The result would
>be reduced security, if packets matching an n-tuple are permitted in either
>direction when in fact they should only be permitted in one.  I believe
>that would be an unacceptable reduction in security.
>
>-Mark
>
>At 05:37 PM 8/9/01 +0200, Jiri Kuthan wrote:
>>How does a, say SIP proxy, know what the direction of a media stream
>>belonging to a SIP session will be?
>>
>>-Jiri
>>
>>At 04:21 PM 8/8/2001, Mark Duffy wrote:
>>>>Also, I think we remove directionality at our peril.  In an
>>>>internal/external communication, the reversing of directional rules on
>>>>interfaces would lead to a weakening of enterprise security.
>>>
>>>Not only that, but the directionality is already an aspect of the
existing

--
Jiri Kuthan            http://iptel.org/~jiri

---

From: Mark Duffy <[email-masked]>
Date: Thu, 16 Aug 2001 16:23:32 -0400

Yes!

At 05:28 PM 8/16/01 +0100, Cedric Aoun wrote: 

<excerpt>The problem is that MB y is a provider provisioned MB where
other realms overlap on the address realm of VPN B (here I'm talking of
IP VPN). How can I use the standard matching expression to identify the
flow (i.e 5 tuple) ?

By some way I need to tell my MB y that I'm talking of traffing flowing
from realm B to the outer realm, the outer realm is probably the
registered address realm (i.e. public realm), in case it is not I will
need to indicate it because maybe it is overlapped by another (or several
realms) that MB y is connected to; thus requiring the outer realm id.

</excerpt><<<<<<<<