Subject: RE: [midcom] policy & duration

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

> I just want to chime in a say expression of direction without 
> a notion of
> which side is in or out is not of much use. I think is would 
> be more useful
> to define the ingress and egress realms. As I have said 
> before, I believe
> assuming all middleboxes will be connected to exactly two 
> realms would be
> unwise.

Direction doesn't really mean anything to me.  

I think a better description of what we want to describe is the 
PATH through the middlebox.  That may be in one interface and 
out another or in and out the same interface or in/out any type 
of logical interfaces such as those associated with VLAN or 
IPSec tunnels etc.

I see three possible options to deal with this interface, direction,
realm stuff:

1) Agree on a non-confusing abstraction of all of this stuff and
   allow include the appropriate stuff in the protocol to represent it.

  I think it will be hard to get consensus on this without coming up
  with a very simple dumbed down model.

2) Limit the protocol dialogue to affect only one logical middlebox
   and a restricted description of the path through it - maybe one or
   two paths through it.  The MIDCOM server in the middlebox would be
   tied to this specific Path.

  This is actually a good way to do it except that you end having
  multiple conversations between Agents and Physical middleboxes.

3) Include something in the protocol to arbitrarily describe which
   logical middlebox you're talking about.

  This is my suggestion.  If I can say in the protocol this open
  pin hole request is for logical middlebox 'incoming-to-dmz' and in 
  my middlebox implementation I configure my MIDCOM server to
  relate direction, interfaces or whatever to 'incoming-to-dmz' I'm 
  happy.  This also gives me more flexibilty should I decide to
  add interfaces to my middlebox or otherwise change the various
  interfaces, routing, directions, etc.

Anyone else have any preferences for any of these three options?

A fourth is to let the middlebox figure it out.  I don't think
anyone wants that or we wouldn't be having the discussions about
interfaces and direction.

-John

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

---

From: Mark Duffy <[email-masked]>
Date: Fri, 10 Aug 2001 15:52:10 -0400

Hi John, see below...  -Mark

>of logical interfaces such as those associated with VLAN or 

I agree with you in general but I think specifying the "path" (such as
'coming from realmA and going to realmB') couples together two things that
should not be related and the result is that one then has to deal with an
n-squared cross product of all the rules governing what comes in from
RealmA and the rules governing what goes out to RealmB!

A more appropriate way to deal with this, IMHO, is that each
rule/pinhole/resource specify the realm and direction as part of the
n-tuple.  One then ends up with rules that apply to say, packets entering
the MB from RealmA, or those leaving the MB to realmB.  Then if a packet
comes in from realmA and goes out to realmB, both rules could match it, one
at a time.  (The way the MB decides where the packet goes out is of course
out of scope of midcom.)

>  with a very simple dumbed down model.

I like option 1 and I am trying to be more optimistic about it :-)  For
example, even if <realm> got dumbed down to <interface>, that wouldn't be
too dumb, nor too far out, would it?

I agree that your other 2 options below would work as well, although I do
not prefer them.  And I would still like to have logical mb PLUS direction,
rather than encode the direction into the definition of a logical mb such
as 'incoming-to-dmz'.