Subject: RE: [midcom] requirements-01 status

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Wed, 27 Jun 2001 15:03:17 -0600

> the flow direction is inherent going from the source address to 
> destination address).

This assumes the middlebox is smart enough to discern to which interface
each rule applies. We should either capture that assumption or recognize
the possibility that a poorly engineered middlebox could in theory allow
spoofed packets to travel backwards, particularly if a wildcard is used.

--Andy Zmolek
    Technology & Standards Engineer
      CTO Standards
        Avaya Inc.

            [email-masked]
              +1 720 444 4001

---

From: [email-masked]
Date: Thu, 28 Jun 2001 08:41:07 +0100

Eric,

I'm not sure that concensus has been reached on the pin-hole direction issue
because we are still discussing the multiple interfaces issue. In many
respects this is one and the same problem i.e. what view of the Middlebox,
its physical connections and flows that cross it are made available via the
MIDCOM protocol to a MIDCOM Agent wishing to use the services provided by
the Middlebox to enable a given application to work correctly.

regards

Richard

> -----Original Message-----
> From: Fleischman, Eric W [mailto:[email-masked]]
> Sent: 27 June 2001 17:58
> To: [email-masked]
> Subject: [midcom] requirements-01 status
> 
> 
> OK, We've now had a flurry of emails on the requirements 
> draft. Many important points 
> have been made. However, what have we learned from this 
> email: what is our status?
> 
> I believe that we have consensus that directionality in the 
> Pinhole-descriptor is redundant.
> 
> Was there a consensus on Christian Huitema's posting where he said:
> 
> >Next comment concerns the figure on page 6. The "Application Control
> >Flow" line should be removed. It it a throw back of the 
> "OOP" debate; we
> >debated that OOP should maybe be mentioned in the framework with due
> >precautions; it certainly does not belong in the requirements.
> >Similarly, the paragraph that states that "The Middlebox must support
> >the explicit forwarding of application control session information"
> >should be removed, as well as the whole of section 7.
> 
> I fully agree with Christian's comment here, except for the 
> part about there being a
> consensus on OOP, which I feel was never reached. I think 
> that our strong division on
> OOP will hinder our making progress and we really need a 
> "Plan B" (i.e., a compromise).
> However, if I'm having a "senior moment" and there really was 
> a compromise reached on OOP, 
> is Christian's summary of it above accurate? If so, is the WG 
> ready to accept his 
> recommendation "as is"?
> 
> --Eric
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/midcom
> 

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

---

From: John LaCour <[email-masked]>
Date: Thu, 28 Jun 2001 17:39:29 -0700

The only way that we can allow the middlebox to figure out
which interfaces and direction to apply the requests to is
if the MIDCOM interface on the middlebox is administratively 
tied to one pair of interfaces and one direction.  Otherwise,
there are numerous problems with letting the middlebox
figure out on its own which interfaces to which the request 
should be applied.

Consider the following case:

 1) Agent requests pin-hole
 2) Middlebox consults routing table and other configuration
    parameters and creates pin-hole.
 3) Routing table changes
 4) Packet arrives but there is no pin-hole on the current
    route.

 So let us argue that this is an implementation detail for 
 middlebox vendors.  They will need to create pending 
 pin-holes across all interfaces until you get a packet 
 that matches, set that pin-hole, and close all of the 
 other pending pin-holes.  It gets even uglier when you
 consider a request to create a deny policy.

I think the reason why many of us want interfaces and 
direction specified in the protocol is so that dynamic
policies can be installed explicitly and based on the same 
information as static policies.  Also, so we don't have to run
multiple MIDCOM agents on a middlebox for all of the possible
combinations of interfaces which may be transited.

I'd like to suggest that we include in the protocol a
field such as 'middlebox-id' that could be used to reference 
an abstraction of a logical middlebox.  A logical middlebox
would be comprised of 'inside' and 'outside' interfaces.
The middlebox could be administratively configured so that
a given middlebox-id is tied to two interfaces on a physical 
middlebox.  Simple configurations or middleboxes which
want to figure out how to install policies on their own
could omit the 'middlebox-id' field.

Protocol requests would include something like 'inside-address',
'outside-address', 'middlebox-id', and 'direction'.  Direction 
would be 'in', 'out', or 'bi-directional'.

This would decrease the complexity required to implement 
MIDCOM in middleboxes, allow one instance of the protocol
to manage several logical middleboxes, and avoid having to
come up with some standard representation of interfaces in
the protocol.

-John

> From: Christian Huitema [mailto:[email-masked]]
> 
> I agree with Melinda here. The internal IP packets that are authorized
> to sneak through a "pin-hole" will carry an internal source 
> address and
> an "external" destination address; the internal routing 
> mechanisms will
> direct these packet towards the firewall. If the firewall is 
> to forward
> these packets, it will have to do that based solely on the 
> value of the
> destination address -- there is no "scope of address" field 
> in the IPv4
> packet.  To operate properly, the firewall must have an 
> internal routing
> table that maps an IP address to an exit interface. Thus, the
> "interface" to which an address is bound on a given midcom 
> box has to be
> deductible from the IP address itself. Ergo, direction and 
> scope fields
> are redundant.
> 
> -- Christian Huitema
> 
> > From: Melinda Shore [mailto:[email-masked]]
> > Sent: Thursday, June 28, 2001 12:39 PM
> > To: Sanjoy Sen; 'Bob Penfield'; midcom
> > Subject: Re: [midcom] requirements-01 status
> > 
> > > From: Sanjoy Sen <[email-masked]>
> > > To: 'Bob Penfield' <[email-masked]>; Melinda Shore
> > <[email-masked]>; midcom <[email-masked]>
> > > Sent: Thursday, June 28, 2001 3:11 PM
> > > Subject: RE: [midcom] requirements-01 status
> > 
> > 
> > > I agree with Bob. How would the MB know about the direction the
> packets
> > will
> > > be flowing from the flow tuple (src., dest. addr,ports, 
> protocol> if
> the
> > > endpoints are multi-hop away from the MB?
> > 
> > A middlebox with more that's got to forward to more than one
> > interface is often referred to as a "router," and there are
> > already mechanisms to do interface selection.  I am *extremely*
> > wary of 1) trying to replicate network-layer functions in the
> > application layer, and 2) trying to export network topology
> > information to applications.  I believe that the correct
> > approach here is to rely on routers to do their job, including
> > route determination/selection.
> > 
> > Melinda
> > 
> > 
> >

---

From: "Fernando Cuervo" <[email-masked]>
Date: Fri, 29 Jun 2001 14:34:17 -0400

You could also add a policy data object that is opaque to Midcom, it could
have a variety of applications within a "closed-preconfigured" system

Fernando Cuervo

> From:	Zmolek, Andrew (Andrew) [SMTP:[email-masked]]
> Sent:	Friday, June 29, 2001 12:45 PM
> To:	Bob Penfield; Christian Huitema; Melinda Shore; Sen, Sanjoy
> [NGB:B602:EXCH]; midcom
> > The middleboxes that I am talking about have no routing tables or
> routing 
> > capability. They sit on a pipe between two routers. Whatever comes in on
> one 
> > end of the pipe is sent out the other end. The routers take care of
> sending 
> > the packets down the right pipe. 
> 
> In this simplistic case, the routers can be reasonably expected to take
> care of anti-spoofing as well, so it really won't matter if the middlebox
> uses the same set of pinholes on all interfaces. But on the other hand, I
> don't see a big problem with adding something like a 1-byte token to the
> spec that could be given meaning outside of midcom. If you want to
> implement it to mean "interface" then that could be fine as long as you
> don't expect that byte to mean anything outside of your own closed,
> preconfigured system.
> 
> For the general case, I agree with Melinda that interface identification
> doesn't belong in midcom, especially when it forces application agents
> (assumed to be ignorant of the routing topology) to make interface
> decisions. We don't want to force the tail to wag the dog. But adding a
> 1-byte token might be useful for very simple toplogies with static routing
> and simple agent configuration. Comments?
> 
> --Andy Zmolek