Subject: RE: [midcom] WG scope/deliverables

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 1 Feb 2001 02:22:24 -0500

> -----Original Message-----
> From: Pyda Srisuresh [mailto:[email-masked]]
> Sent: Thursday, February 01, 2001 1:09 AM
> To: [email-masked]
> Subject: RE: [midcom] WG scope/deliverables
> 
> 
> --- Christian Huitema <[email-masked]> wrote:
> > Well, maybe we should keep the Midcom discussion in Midcom without
> > spamming the whole IETF list...
> > 
> 
> Sounds good.
> 
> > I actually believe that Keith has a point. The point is not 
> whether or
> > not we deal with NAT; we know we have to, at least in the 
> short term.
> > The real point is that we have to aim for simplicity. 
> Basically, Midcom
> 
> Agreed.
> 
> > can do one of two things: study a grand design for a new Internet
> > architecture based on a patchwork of firewalled networks, 
> or come out
> > with a short term fix for crossing the NAT and firewalls 
> that we have
> > today. I have absolutely no confidence that an IETF working 
> group could
> > solve the general problem in any reasonable time frame, and thus I
> > believe we should focus on a simple short term solution.
> > 
> 
> Agreed. I dont believe, we are assuming a paradigm in which there are 
> multiple NATs and firewalls along the way. Certainly, NAT/firewall 
> discovery is out of the ascope of this work group. 
> 
> In my mind, we are merely pursuing a much simpler scenario in which 
> you have a single middlebox (running NAT or firewall) along the 
> application route. This, I believe, is basicaly the applicability 
> statement.

Yes.

I really like the notion of characterizing the problem of one of
"decomposition". Right now, existing firewall and NAT products have
application layer functionality in them, which they use to examine/rewrite
application layer packets, and also they have a pure transport layer piece,
which just examines/mucks around with the 5-tuples in IP packets. The
architecture we are describing here allows me to decompose the application
layer intelligence external to the fast packet IP processing. The
decomposition is identical to megaco. In megaco, a gateway (which has
application layer, i.e., signaling, and media path processing) is decomposed
into a pure application component, usually software (called the MGC), and a
pure media processing piece, called the MG. Between them is a protocol for
control/reporting, and thats megaco. 

Thats what we want here. We want to extract the application layer
intelligence into one component, and maintain the application unaware (at
least, unaware beyond port numbers), fast packet processing in a separate
component. We put a protocol between them, and thats the protocol we are
discussing here.

Whether the application aware component is an end system, like a PC
application, or whether its a network application device, like a SIP proxy
or H.323 gatekeeper, is orthogonal, although it has impacts on the security
models, as we have discussed.

The decomposition viewpoint (and thats all it is) helps clarify the scope of
the problem, I think. 

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 01 Feb 2001 00:34:27 -0800

Jonathan Rosenberg wrote:
> [Pyda]

> Yes.
[...] 
> models, as we have discussed.

Christian, Keith, and others have pointed out that the hard part is in
the listener portion of all of this.  It is one thing to have an H.323
gateway listen for call set up and then communicate that information to
both the firewall and the end.  It is quite something else if there is
no notion of a gatekeeper or gateway.  How do you listen() such that the
firewall "gets it"?  And then, in a large deployment of multiple middle
boxes, which firewall needs to get it?  And then what are the
ramifications for the middle box?  If the end application registers with
all middleboxes and requires NAT functionality, then it will need to be
aware of multiple addresses that it could have, assuming it would need
to know the mapping for one reason or another.

Let's assume that the service is established.  This requires that the
middlebox actually manage DNS to allow for the appropriate management of
translations.  For example:

iHOST=10.1.1.1
oHOST=128.6.4.4

oHOST wants to communicate with iHOST through the internet, but iHOST is
not addressable.  That requires a middlebox to establish an A record for
iHOST, and bind a given address / port translation.

OR

there's an ALG.

Messy messy.
--
Eliot Lear
[email-masked]