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

From: "Fleischman, Eric W" <[email-masked]>
Date: Mon, 18 Jun 2001 09:01:40 -0700

I've now been through the email archives
and I've failed to find a discussion concerning
the strengths and weaknesses of permitting out-of-
path Midcom agents.

I question the wisdom of specifying out-of-path
Midcom agents because the provision is an
excellent mechanism to be exploited by hackers,
crackers, and DoS attacks. The natural fit of this
provision for these types of exploits is so obvious
that I question why this provision was added
to the framework document. The sparse examples within
the text are noncompelling (e.g., FTP), since one 
could easily accomplish the same thing via in-path
agents, and this particular provision of FTP has been
criticized in security circles for some time.

Therefore, I'd like to either have a very strong
justification for this provision be added to the
text or else have the provision removed as unacceptably
dangerous. Either way, we need a discussion on this
capability.

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

---

From: Andrew Molitor <[email-masked]>
Date: Mon, 18 Jun 2001 12:43:58 -0500 (CDT)

> criticized in security circles for some time.

	I find this puzzling. To my way of thinking, an OOP agent
is (or is very close to) a pretty ordinary transparent application
layer gateway that's been taught how to talk to a middlebox to
fast-path traffic. In In-Path agent is a non-transparent application
layer gateway with the same teaching.

	Are you claiming that a transparent ALG is in some way
easier to fool/spoof/hack than a non-transparent one?

	What am I missing?

		Andrew

P.S. I am of, course, aware that MIDCOM Agent is not actually synonymous
with ALG. It just seems to me that most implementations will tend to
fall somewhat along these lines.

---

From: "Scott Brim" <[email-masked]>
Date: Wed, 20 Jun 2001 10:34:34 -0400

> easier to fool/spoof/hack than a non-transparent one?

It's precisely because it's potentially application-layer transparent
(although I suspect it won't be in many cases) that it's more
vulnerable.  Who will be checking the validity of its actions?  The
endpoints don't know about it explicitly.  The middlebox just does what
it's told.

...Scott