Subject: [midcom] Straw poll - out-of-path midcom agents

From: "Melinda Shore" <[email-masked]>
Date: Tue, 19 Jun 2001 14:14:43 -0400

We've been going around and around on out-of-path agents
since the first draft of the document and it's my sense
that we're failing to make progress on it.  I'd like to
take a straw poll to see how much support there is for
including support for diversion to out-of-path agents.  
Please indicate to the mailing list whether or not you'd
like us to include consideration of out-of-path agents.
Be prepared to defend your position :-).

Melinda

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

---

From: "Scott Brim" <[email-masked]>
Date: Tue, 19 Jun 2001 14:55:44 -0400

> Be prepared to defend your position :-).

I think it's okay to have it in the framework.  However, I'm in favor of
leaving it out now because it's something we can add on easily in the
future.  I don't think the possibility of OOP agents has any fundamental
implications for the midcom protocol.  If it didn't confuse and distract
people we could leave it in.

Why might we want it?  We don't know yet everything we're going to want
to communicate in the midcom protocol.  We don't know what processing
rules we're going to want to be able to pass down, besides "make a
pinhole for address X port Y".  Perhaps a general purpose, open-ended
capability will be too painful to implement.  Perhaps 90% of the
applications will only need a lean mean simple protocol.  In that case,
it would be nice to have left room for an agent to say "look, I can't
explain what I want, but when you see these packets just give them to me
and I'll deal with them".

But we could do that later.

OPES, if they get chartered at all, are describing a class of OOPA.
Perhaps, when we uncover a specific need for an OOPA, their protocol
might (be extensible to) cover the specific need.  We may never get to
the point of doing anything about OOPAs in midcom or its children.

...Scott

---

From: Abdallah Rayhan <[email-masked]>
Date: Tue, 19 Jun 2001 15:22:29 -0400 (EDT)

Melinda,

I am in favor of OOP. The reason is that it introduces 
the concept of open middlebox architecture.

If I have a middlebox which carries out function x to 
perform content filtering for a class of applications,
then the OOP would give me the ability to contract
whatever vendor I want to provide this service for
me without having to throw my current box. Later
I may decide to go with another vendor who provides
more scalable OOP inspection service. I should be
able to do this seamlessly since there is an open
interface for OOP-middlebox interaction. 

Focusing on VoIP type of applications for MIDCOM,
should not distract us from providing the proper
mechanisms to make the framework extensible to
other types of applications.

I believe that several security and non-security 
applications can make use of this framework.
While there are security concerns about how OOP
should be integrated within the architecture or 
deployed, that does not justify saying that we dont 
need it.

my 2 cents
regards,
Abdallah

> Be prepared to defend your position :-).

_______________________________________________________
Do You Yahoo!?
Get your free @yahoo.ca address at http://mail.yahoo.ca

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Jun 2001 14:12:18 -0500

There's a strong analogy between your question and the debate now
raging on the IETF list whether to charter OPES, which is about
OOP agents at the HTTP and RTSP level. I think midcom probably
needs to see which way the consensus and IESG decision go
for OPES; if the IETF isn't willing to charter OPES, it's
unlikely to be happy with midcom covering OOP agents.

In fact if you extend the definition of "firewall" to include
application entities, as Eric wants, you are in *exactly*
the OPES scenario.

If we have to decide today, I agree with Eric, and his
arguments, with perhaps a note that OOP is for future study.

   Brian

---

From: Andrew Molitor <[email-masked]>
Date: Tue, 19 Jun 2001 15:56:03 -0500 (CDT)

I think including OOP agents in the framework, at least, is
exceedingly reasonable. My defense follows:

	Transparent proxy/firewall technology is extremely widespread
and used (or at least present, even if disabled) in virtually every
firewall product in existence. A canonical OOP agent implementation is
to graft a MIDCOM agent interface onto one of these transparent firewall
devices. Conversely, such a transparent device is a natural device
onto which one might want to graft a MIDCOM agent interface. Of course,
not all OOP Agents will be built this way, but it's an interesting subset.

	In order to be really useful (say, for performance reasons), the
middlebox should operate in parallel with the transparent agent, not
serially (otherwise the transparent agent could just do all the policy
internal to itself!) This implies a packet diversion function in the
middlebox, since the Agent is out of the natural flow of traffic, as
indicated below.

This makes sense:

                +---------------+
                | Transparent   |
                | Fwall as OOP  |
                |   Agent       |
                +---------------+
                        |
                        |
       +--------+       |
       | Middle |       |
  -----|   Box  |-------+--------        <---> Natural Flow of Traffic
       +--------+

This does not, since the Fwall can just do the policy itself:

     +----------+            +-------------------+
     | Middle   |            | Transparent Fwall |
  ---|   Box    |------------|  as OOP Agent     |----
     +----------+            +-------------------+

	We can eliminate discussion of OOP agents, and retain the In-Path
agent, thereby implicitly (or perhaps explicitly) making MIDCOM specific
to applications which use some sort of explicit transaction routing
element which can be the In-Path agent. This for all practical purposes
makes MIDCOM SIP-specific -- name me another application which uses
In-Path control elements and which would truly benefit from MIDCOM! I do
not think this an acceptable scenario.

	If we eliminate OOP Agents, therefore, we must eliminate the
distinction between OOP and In-Path agents entirely, and make it Out Of
Scope to figure out how the Agent gets the information it needs. This, of
course, allows for OOP Agents, In-Path Agents, Secret Agents, and every
other sort of Agent you like.

	OOP agents will exist (and indeed are likely to outnumber In-Path
agents, in the field), and middleboxes will support packet diversion to
support them. If standards do not exist to allow an OOP agent to register
for specific traffic diversions, ad-hoc solutions will be devised by
vendors.

	Eliminating agent types would have the effect of focusing the
working group purely on the protocol definition, which is a useful
thing. My opinion, however, is that this also:

	- leaves the protocol work operating nearly in a vacuum, with too
	  little useful context.
	- eliminates consideration of specific protocol support for OOP
	  agents which is likely to, leading to non-standard solutions.
	- is not necessary, there is not at this point an excess of work
	  to be done -- trimming the scope is not necessary.

		Andrew

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 19 Jun 2001 14:26:24 -0700 (PDT)

I believe, the framework document should make the distinction
between In-Path and Out-Of-Path (OOP_ agents. There is no difference
in MIDCOM protocol, per se, irrespective of the agent type. Support
for diversion function or its implementation can be vendor proprietary.
There has never been a suggestion that this WG (or the follow-on WG)
should address it.

Not all applications have In-Path entities such as Proxies or Gateways.
There are many that dont. For those applications, the only viable choice
that this WG offers would be to fold the agent into end-hosts. This is
not necessarily a scalable or acceptable solution.

Even when an application has In-path entities(say proxies), there are
many enterprises that dont run them. It is not necessarily economical 
to run the agent on these entities, even when an enterprise has these
proxies installed in-house. The MIDCOM agent should not be mandated 
to run on just the In-path entities. 

There are many ASP vendors that might have a  proposition to 
accomplish the same using OOP agents, more economically - Say, running
the same OOP agent to work with multiple enterprises to enable a 
specific application (or) a set of applications. OOP agents have
the advantage of not being tied to a certain topological restriction.  

As such, it would be a mistake for the FW draft to restrict the use
or mention of OOP agents.

To reiterate - I believe, Support for OOP agents on a middlebox could be 
made vendor proprietray and as such, the diversion function or its 
implementation can be out of bounds for this WG (or the follow-on WG).

Ignoring or failing to mention the OOP agents in a MIDCOM framework
document is, at best, an incomplete work.

regards,
suresh

> Be prepared to defend your position :-).

__________________________________________________
Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 20 Jun 2001 09:20:45 -0400

I believe the idea of diverting packets to so called OOP agents needs to be
included in the framework. However, I don't see the need to explicitly
identify them as OOP in the MIDCOM protocol. I see diversion as just another
service that the middlebox provides (like NAT & firewall). Being a SIPer, I
can see this being very useful in the following scenario:

I have this big expensive SIP server that cannot talk MIDCOM and a middlebox
that does NAT and can talk MIDCOM. I want to add on this little inexpensive
MIDCOM Agent box that will "snoop" the SIP traffic, set up NATs in the
middlebox for the RTP/RTCP and modify the IP addresses in the SIP headers
and the SDP based on those NATs. This MIDCOM agent would ask the middlebox
to "divert" the SIP flow to itself via an IP tunnel (or whatever). The
RTP/RTCP flows are NATed just like with in-path agents.

Certainly defining the specific mechanisms for diversion are outside the
scope of the WG. However, MIDCOM should support any existing standard
mechanisms (if there are any).

I agree that keeping these things secure is a harder problem than with
in-path agents, but that doesn't mean we should not include it. I agree with
the esteemed Dr. Molitor that OOP agents may outnumber in-path agents at
least in initial deployments until the various types of applications become
MIDCOM enabled.

(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

---

From: Mark Duffy <[email-masked]>
Date: Wed, 20 Jun 2001 14:54:53 -0400

Melina, please count me in favor of support for OOP agents.

The objective of this WG is to facilitate removing application intelligence
from NAT and firewall middleboxes, and placing that intelligence instead in
a Midcom Agent.  Many applications never employ in-path intermediary boxes
that could take on the Agent role.  (Looking at the charter, I do not see
that the scope of the effort is to be limited to SIP amd H.323 -- am I
missing something?)  Other applications may not have in-path intermediaries
present in every case.

Placing OOP agents out-of-scope implies restricting the midcom effort to
supporting those applications that have in-path boxes suitable to step up
and act as midcom agents.  This would fall short of what many vendors of
middlebox equipment may be expecting from this effort.

I further believe that diversion mechanism(s) should be covered by the WG
effort.  Standardizing only part of the middlebox<-->agent communication
will not gain much multi-vendor interoperability.

Thanks,
Mark Duffy

---

From: "Melinda Shore" <[email-masked]>
Date: Wed, 20 Jun 2001 15:08:38 -0400

> a Midcom Agent. 

Right, but one thing that concerns me about this
discussion is that by using out-of-path agents we're
essentially taking application execution out of one
type of network box and putting it into another type
of network box.  That is to say, we're failing to 
move it closer to the application elements that are
already participating in the session.  

We *know* that requiring application participation
by firewalls and NATs causes all kinds of breakage,
and I'm not convinced that the implications of doing
packet diversion to something else that's not really
participating in the application have been fully considered. 

Anyway, vote noted and recorded.

Melinda

---

From: Mark Duffy <[email-masked]>
Date: Wed, 20 Jun 2001 17:59:23 -0400

>already participating in the session.  

That's true.  But if there are no intermediary boxes participating in the
session, then that just isn't an option anyway.  *And* one would hopefully
be moving the application intelligence out of a specialized, embedded,
proprietary device (whose supplier could never keep up with every new
application) into a more generic platform, that could hopefully install
middlebox-vendor-independent application intelligence modules provided in a
timely fashion by whoever sells/promotes the particular application.