Subject: RE: [midcom] WG scope/deliverables

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 31 Jan 2001 22:08:33 -0800 (PST)

--- 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.

> I believe that the short term requirements are quite simple. Many users
> want to run real-time applications such as VoIP, or peer-to-peer
> applications such as Napster. The real-time applications require that
> one establish a "pin-hole" in the firewalls to let the media flow pass.
> The peer-to-peer application require that the host behind the NAT can
> publish an IP address and a port, and receive TCP connections to that
> port.
> 
> Both requirements can actually be met by the current generation of
> firewall and NAT products. Firewalls can open a hole based on a
> "5-tuple"; NAT products all allow for some form of "DMZ" or "service
> host" configuration that allow users to specify that an inside host will
> serve a specific outside port. The problem is thus not to create a new
> functionality, but to create a unified, standard way to exercize an
> existing functionality. Now, that should be a problem that an IETF WG
> can solve...

By adapting the new MIDCOM protocol, the NAT and firewall devices will 
be able to support newer applications (as listed above) they have not 
been able to support thus far. But, we certainly are not changing the
fundamental NAT and firewall functions in these devices.
 
> -- Christian Huitema

Thanks.

regards,
suresh

__________________________________________________
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

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

---

From: Manish Karir <[email-masked]>
Date: Thu, 1 Feb 2001 09:33:52 -0500 (EST)

does the defination of middle box include - proxies/caches?

manish karir

---

From: "Scott Brim" <[email-masked]>
Date: Thu, 1 Feb 2001 09:32:45 -0500

> believe we should focus on a simple short term solution.

That's why we've been stressing requirements.  We probably don't even
need a new protocol.  On the other hand a framework which essentially
captures this discussion, giving a perspective on what we're doing and
where we fit into the longer term engineering of the Internet, does not
detract from that.  Yes, you need to keep engineers reined in or they
start solving problems when they're supposed to be figuring out needs,
but that's normal.

...Scott