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

From: "Maciocco, Christian" <[email-masked]>
Date: Mon, 2 Jul 2001 14:58:19 -0700

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.

The concern I have if we describe ALG in this doc at this point is that as
we use SIP/RTP-RTCP/RTSP as example to describe the NAT & FW requirements,
having the ALG in the doc makes me think that I'm not too far from being
authorized by the Midcom framework to "process" these bitstreams content. If
the OPES WG is chartered, a framework enabling content processing would be
one aspect of this WG work. Considering the OPES box as a "Content level
middlebox" it will be interesting to see how it does cooperate w/ the MIDCOM
box.

Thanks
Christian

> -----Original Message-----
> From: Scott Brim [mailto:[email-masked]]
> Sent: Saturday, June 30, 2001 6:45 AM
> To: Pyda Srisuresh
> Cc: [email-masked]
> Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02
> 
> 
> On 25 Jun 2001 at 14:57 -0700, Pyda Srisuresh apparently wrote:
> > --- Scott Brim <[email-masked]> wrote:
> > > On 19 Jun 2001 at 13:11 -0700, Pyda Srisuresh apparently wrote:
> > > > 1. Paragraph 1 of section 1 - Introduction
> > > > 
> > > >    "Application Level gateways (ALGs) are used in 
> conjunction with NAT
> > > >     to provide end-to-end transparency for many of the 
> applications."
> > > > 
> > > >    I think, it should be OK to leave this unchanged.
> > > 
> > > OK, we're talking about application-layer transparency.  
> As long as you
> > > mean that the application data and the application behavior are
> > > unchanged, since that would fit the strict definition.  I 
> think I agree.
> > > 
> > 
> > ALG does not guarantee that application data is not 
> changed, even though
> > its intention is to keep the application behaviour unchanged.
> > It may in fact change the data in control payloads. So, the term 
> > "application level transparency" above doesnt meet the dictionary 
> > definition. 
> > 
> > Would the following rewording work for you?
> > 
> >    Application Level gateways (ALGs) are used in 
> conjunction with NAT
> >    to examine and optionally modify application payload so the 
> >    end-to-end application behaviour remains unchanged for many
> >    of the applications traversing NAT middleboxes.
> 
> Yes, thanks.
> 
> 
> _______________________________________________
> 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: "Scott Brim" <[email-masked]>
Date: Fri, 6 Jul 2001 20:55:17 -0400

> middlebox" it will be interesting to see how it does cooperate w/ the MIDCOM

What you do in a Midcom "agent" is completely out of scope for Midcom.
Midcom cares about how the agent controls the behavior (in particular
the NAT/Firewall behavior) of the middlebox functions.  You can
manipulate content all you want and the midcom protocol won't ever hear
about it.  If you want some protocol that communicates how content is or
should be manipulated, that's where you talk to OPES.

...Scott