Subject: RE: [midcom] Proxies / ALG in Midcom framework document

From: John LaCour <[email-masked]>
Date: Mon, 2 Jul 2001 15:57:52 -0700

> From: Maciocco, Christian [mailto:[email-masked]]
> 
> While the Midcom framework scope is defined to be NAT & 
> Firewall in the
> Introduction chapter I think that describing Proxies and 
> especially ALG
> later in the doc is confusing about this WG charter. There 
> have been a lot
> of "proposed extension" lately, e.g. QoS support, OOP w/ 
> packets diversion,
> etc. We should make sure to focus the document to transport 
> level issues
> only.

Its not clear to me whether or not the MIDCOM group is chartered
to be concerned ONLY about middleboxes which affect or care
about layers 3 and 4.

It is clear to me that MIDCOM appears to have chosen to focus
on packet filters and NAT initially.  Will we extend the scope of
the wg to additional layer 3 and 4 middlebox functions or 
other functions in other layers as well?

I have a middlebox that enforces policies based on layers 2 through
7.  I'd like to minimize the number of MIDCOM-like protocols I have
to deal with without losing the ability for trusted application
agents to tell me how to help them manage/mangle/manipulate data
at the relevant layer.

-John LaCour

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

---

From: "Melinda Shore" <[email-masked]>
Date: Tue, 3 Jul 2001 08:31:36 -0400

> From: "John LaCour" <[email-masked]>
> To: "'Maciocco, Christian'" <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, July 02, 2001 6:57 PM
> Subject: RE: [midcom] Proxies / ALG in Midcom framework document

> to be concerned ONLY about middleboxes which affect or care

We are.  We're trying to solve a pressing problem with firewall
and NAT traversal.  We're trying to do it in a manner that may
generalize well to other middlebox-type problems, but we do have
a very specific piece of work in front of us at this time.  The
question of our relationship with groups doing application-layer
middlebox interfaces remains open, in no small part because this
work is so new.  I believe that there are plans to discuss what
midcom is doing and how it relates to OPES at the OPES session
during the August meeting.  We can discuss it on the mailing
list prior to that, obviously.

As we start to think about rechartering and as charter/scope issues
continue to crop up on the mailing list it might be worth
considering 1) what a next rev. of a midcom working group might
look like, and 2) how people interested in using midcom for something
else (QoS, packet diversion) might proceed.  My *personal* opinion
and my personal preference is that if we are rechartered it will be 
specifically to do protocol development for an interface to firewalls 
and NATs.  We are not here to solve every problem related to 
middleboxes in the network.  However, if we do a good job and
the framework is correct and useful, it may be that other work
is proposed to the IETF based on our framework, and that work will
have to go through the chartering and review process on its own.

Melinda

---

From: "Michael W. Condry" <[email-masked]>
Date: Tue, 03 Jul 2001 12:41:48 -0700

group cooperation is good for all of us.

>have to go through the chartering and review process on its own.

Michael W. Condry
Director,  Network Edge Technology

---

From: Bobby Sardana <[email-masked]>
Date: Tue, 03 Jul 2001 20:28:22 -0700

Greetings:

So what happens to all the application layer protocols (SIP,HTTP) who have their
own means of firewall traversal? Will they have to comply to the MIDCOM
specification once it is published?

Regards,

Bobby Sardana.
[email-masked]

---

From: "Melinda Shore" <[email-masked]>
Date: Wed, 4 Jul 2001 08:43:35 -0400

> specification once it is published?

I don't know of any protocol that has its own means of
firewall traversal.  Firewalls may or may not have support
for particular protocols.  That won't change, of course, 
and firewalls that do stateful inspection will continue
to be useful in cases where there's no application support
for midcom or when performance and application security
are not issues.

Melinda