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

From: "Fleischman, Eric W" <[email-masked]>
Date: Tue, 19 Jun 2001 11:43:54 -0700

Melinda,

Since you requested that we reply to the whole list, my vote 
is that we NOT consider OOP agents.

My reasons are:
1) I do not understand why advocates for OOP agents desire
them: what scenarios do OOP agents enable? What are they
trying to do that they can not do with in-path agents? Are 
those scenarios "safe" or do they violate "due diligence"?
Does this undercut the very nature of the protection currently
provided by firewalls?
2) I fear this capability will be easily abused by hackers/
crackers. The clandestine nature of OOP agents make them a
preferential attack base when compared with proxies, which 
are much more publicly known and inspectable.
3) The WG has adopted a definition of "firewall" as being a
packet filters. That's fine, but the standard definition I'm used 
to includes the combination of both packet filters and proxies. 
Thus, we as a corporation are oriented to be disposed to 
extend our propagation of trust to include proxies -- in band 
agents. However, I know of no co-worker who would similarly trust
OOP agents, nor have I become clever enough to understand how
we could do so or what that would mean, which is why I started
out asking the questions in bullet 1 above. My bottom line is 
that we must not undermine the function the middleboxes
are performing if the midcom protocol is to be usable. I am
particularly concerned about keeping firewalls secure.

--Eric

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]]
Sent: Tuesday, June 19, 2001 11:15 AM
To: [email-masked]
Subject: [midcom] Straw poll - out-of-path midcom agents

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

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

---

From: "Reinaldo Penno" <[email-masked]>
Date: Tue, 19 Jun 2001 17:32:57 -0700

So,

IMO having a in-path agent might be really the focus of this group, but I
have doubts this model will fly. Unless is for a subset of
applications/deployment scenarios.

So, if this WG is not going to deal with OOP, I would like to know if this
problem/scenario is going to be discussed in some other mailing list (I want
to be in). Or if some folks are interested on taking this discussion offline
and trying to put something on paper, I also would like that.

I totally agree with these statements. There is also a scenario where a
Service Provider want to wholesale a MIDCOM box to different enterprises
using a VR model, where different traffic might be redirected to different
agents in different locations. 

" 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 far as the protocol between the MIDCOM box and agent, that might
proprietary or not. I would like it to a multi-vendor effort since some
manufactures might build MIDCOM boxes, but not agents and vice-versa.

regards,

Reinaldo
NortelNetworks

> From: Pyda Srisuresh [mailto:[email-masked]]
> Sent: Tuesday, June 19, 2001 2:26 PM
> To: Melinda Shore; [email-masked]
> Subject: Re: [midcom] Straw poll - out-of-path midcom agents
> 
> 
> 
> 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.

---

From: "Sanjoy Sen" <[email-masked]>
Date: Tue, 19 Jun 2001 22:17:59 -0500

My vote will be a NO for OOP MA at this stage. I'm not sure I clearly see
the impact of this "datagram diversion" function on the MIDCOM protocol as
this can be configured as a routing policy on the Middlebox. Apart from
this, how's the control of the Middlebox any different between the IP and
OOP MA's? I agree with Scott that this can be added later, if deem required.

Sanjoy

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]]
Sent: Tuesday, June 19, 2001 1:15 PM
To: midcom
Subject: [midcom] Straw poll - out-of-path midcom agents

Melinda

---

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Wed, 20 Jun 2001 07:00:05 -0600

My vote: include support. OOP agents are likely to proliferate without
regard to work done in this group and while an argument can be made that
they can be ignored and still implement midcom, I'd prefer to see better
consideration of them in our scenarios and discussion moving forward.

In spite of the fact that OOP agents will create new security
nightmares, I would much rather see us tackling this as part of a more
complete solution. Forcing vendor competing vendor extensions to decide
this issue might further delay acceptance of midcom in the industry in
general.

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

            [email-masked]
              +1 720 444 4001

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]]
Sent: Tuesday, June 19, 2001 12:15 PM
To: [email-masked]
Subject: [midcom] Straw poll - out-of-path midcom agents

Melinda

---

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Wed, 20 Jun 2001 07:29:00 -0600

By the time midcom is implementable, the notion of firewall traversal is
unlikely (for enterprises anyway) to refer to passage across a single
device now known as a firewall. If there is something wrong with this
group's efforts to date, it may well be found in the simplistic
perimeter view taken by our scenarios as now written.

Frankly the value of midcom is found in enabling what might be termed a
decomposed firewall architecture. The OOP issue gets to the heart of
this and if we're not going to tackle this in midcom then those of us
who are expecting that solution will be forced to look elsewhere.

--Andy Zmolek

            [email-masked]
              +1 720 444 4001

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]]
Sent: Tuesday, June 19, 2001 1:08 PM
To: Melinda Shore; [email-masked]
Subject: RE: [midcom] Straw poll - out-of-path midcom agents

I do not believe that we should provide support for out of path agent.
The group should focus on solving the problems exposed in the scenarios
draft, none of which involves out of path agents.

The debate on OOP is, IMHO, typical of what is wrong with this group.
Instead of solving the very simple problem of firewall traversal and
actually enabling communication, the group is trying to invent all kinds
of "transformers" that could be placed at arbitrary places in the
network. We should cut that and focus.

-- Christian Huitema

---

From: "Fernando Cuervo" <[email-masked]>
Date: Wed, 20 Jun 2001 10:00:03 -0400

OOPs in the framework: NO
Are OOPs useful: yes
So why not? 
1-this is not in the "focus" areas of Midcom (see charter)
2-a timely outcome would be less likely to occur since reusability of
existing protocols would
   be more difficult with all the baggage of OOPs
3-the description in section 5.2 of the framework document is trying to
specify the functionality of
  the middlebox to support OOPs not the interoperability aspects
4-the WG is NOT dealing with discovery, I believe OOPs are an essential
component of discovery,
  therefore the WG shall not get into areas that is not willing to address.

Fernando Cuervo
> From:	Melinda Shore [SMTP:[email-masked]]
> Sent:	Tuesday, June 19, 2001 2:15 PM
> To:	midcom

---

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Wed, 20 Jun 2001 13:22:57 -0600

The easier we make implementation of an OOP agent, the more likely that
the supplier of an application implementation can *also* be the supplier
of the application's perimeter traversal agent. This is likely to
improve design of both applications and middleboxes and may
(paradoxically) accelerate the elimination of NAT and IP boundary
traversal problems.

In the end, it isn't realistic to expect that a firewall have an ALG for
every conceivable application, and firewall traversal isn't getting any
easier for new applications. While some would call this approach a
band-aid, it does provides a reasonable road map and I don't see any
alternatives thriving (mainly because they mandate a forklift at some
level and few are willing to buy that kind of value proposition).

This is all to say that the decomposition of firewall architecture via
midcom is a very good thing in general. So let's not spend so much time
in mortal fear of arriving there.

--Andy Zmolek

            [email-masked]
              +1 720 444 4001

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]]
Sent: Wednesday, June 20, 2001 1:09 PM
To: [email-masked]; Mark Duffy
Subject: Re: [midcom] Straw poll - out-of-path midcom 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. 

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