Subject: RE: [midcom] Out-of-Path Midcom Agents in framework-02

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

> p.s. Just to be clear, I was attacking *your misrepresenation* of NATs
and ALGs,
not NATs and ALGs themselves.

Fair enough. But it would be far more useful to me and the rest of the
group to elaborate your concerns with more reason and less passion.
Calling the ideas "barefaced lies" imputes a great deal more about your
view of their contributor than the fundamental misrepresentation you
claim to be concerned about. 

I for one would still like to see an improvement of terminology being
used and I think this discussion furthers that goal as long as we can
refrain from personal attacks on the mailing list. The suggestion I made
which you bristled at was just that: a suggestion, begging for
refinement. 

Regarding the inclusion of OOP agents into the draft, I think there is
an acceptable middle ground here that all but the zealots can support. A
discussion of OOP agents is proper and warranted. Midcom should neither
endorse nor preclude its use with OOP agents. Another protocol (likely
proprietary at least for now) will still be needed to deal with some of
the more fundamental policy provisioning and agent authentication
issues, but that's out of scope for midcom anyway. 

Given the resistance that many of the established firewall vendors have
toward midcom implementation, I think it's most important to make midcom
friendly to those willing to implement midcom in an alternative firewall
framework. Unless that framework is decomposeable (i.e. NAT, ALG, and
other middlebox functionality is modular in nature), there won't be a
good enough story there to sell anything. And midcom will be a waste if
it doesn't find its way into high-volume products at some point. 

The good news is that most of us want midcom to be widely deployable and
sufficiently flexible so as to allow for different usage modes. Let's
keep it that way.

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

            [email-masked] 
              +1 720 444 4001

---

From: Keith Moore <[email-masked]>
Date: Wed, 20 Jun 2001 15:31:12 -0400

> > p.s. Just to be clear, I was attacking *your misrepresenation* of NATs and
> > ALGs, not NATs and ALGs themselves.
> 
> Fair enough. But it would be far more useful to me and the rest of the group
> to elaborate your concerns with more reason and less passion.

granted. though I submit it also be useful to this group if you would 
refrain from name-calling and ad hominem attacks. characterizing those
who disagree with you as 'zealots' or 'crusty old purists' 
doesn't exactly increase the signal-to-noise ratio either.

there are still serious operational, security, scalability, deployability 
and interoperability hazards associated with what midcom is working on.  
folks ignore these at their peril, and at the peril of the Internet.

midcom's purpose, like that of the rest of IETF, is to figure out
what makes sense from an engineering perspective, and design protocols
that fit within a sensible engineering framework, for the benefit
of the entire Internet community.  the fact that some companies want to 
deploy products that do not make engineering sense in this context
is not a justification for demanding that midcom help them do so.

Keith

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

---

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

> Another protocol (likely

That stuff is in scope, actually.

Melinda

---

From: Abdallah Rayhan <[email-masked]>
Date: Thu, 21 Jun 2001 11:38:40 -0400 (EDT)

Andrew makes a good point here. I also dont buy the security
threat arguement against OOP mentioned in earlier emails. OOP 
are no worse than In-Path agents. The latter opens 
a pinhole and allows worms to traverse the MB. While the 
former does something to ensure that it is not a worm. 

Issues of trust are always there whenever a new box is
to be deployed. This is a risk that you have to take 
if you want the benefit of a new service. Some firewall 
vendors have adapted open proprietary interfaces. They have 
done it before and the issue of security didnt raise many 
eyes brows then. If it is done right there wont be any
reason to say that it is not secure enough. This does not
necessarily require discovery or complex mechanisms.

Ensuring that the architecture of the MB is extensible 
enough to support a number of services makes market
adaptation of MIDCOM more likely. Focusing only on 
In-Path agents for VoIP like applications is restrictive; 
one firewall for VoIP, another for content inspection, 
another for .... hay here is an idea for a new 
firewall interop-WG!

regards,
Abdallah

> it doesn't find its way into high-volume products at some point. 

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