From midcom-admin@ietf.org Wed Jan 17 14:31:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24739 for ; Wed, 17 Jan 2001 14:31:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18661; Wed, 17 Jan 2001 14:23:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18632 for ; Wed, 17 Jan 2001 14:23:11 -0500 (EST) Received: from zcars04f.ca.nortel.com ([47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24659 for ; Wed, 17 Jan 2001 14:23:10 -0500 (EST) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 17 Jan 2001 14:13:23 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id CZ80BYTK; Wed, 17 Jan 2001 14:10:46 -0500 Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Y6C6N2B8; Wed, 17 Jan 2001 14:10:47 -0500 Message-ID: <3A65EF02.EA0D0A54@americasm01.nt.com> Date: Wed, 17 Jan 2001 14:14:10 -0500 From: "Abdallah Rayhan" Organization: Nortel Networks X-Mailer: Mozilla 4.72C-CCK-MCD CUE 6.2H or 8S [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: midcom@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Content-Transfer-Encoding: 7bit Subject: [midcom] Fail over mechanism in midcom Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Fail over mechanisms, IMHO, should be addressed as part of the midcom architecture. By fail over I mean two things: 1- external agent going out of service and handing the service off to another agent. Should the middle box trust the new agent and impose security challenges on it? Should state-transfer be assumed between the old agent and the new one? There are issues related to provisioning, such as should the middle box be pre-provisioned to authorize the new agent to engage in signaling? etc... 2- middle box going out of service and handing the service off to another middle box. In addition to the issues in 1, we probably need to identify how to handle existing pinholes when service change occurs. Obviously there are issues that needs to be addressed in each case to make such handing over seamless to the apps/users that is if we decided to support this feature. regards Abdallah _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jan 17 17:28:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27188 for ; Wed, 17 Jan 2001 17:28:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20859; Wed, 17 Jan 2001 17:18:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20830 for ; Wed, 17 Jan 2001 17:18:42 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27017 for ; Wed, 17 Jan 2001 17:18:41 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id OAA15293; Wed, 17 Jan 2001 14:18:15 -0800 (PST) Received: from spandex (rtp-vpn-85.cisco.com [10.82.192.85]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id ADU80358; Wed, 17 Jan 2001 14:18:10 -0800 (PST) Message-ID: <02a201c080d3$8d3528e0$d45904d1@cisco.com> From: "Melinda Shore" To: "Abdallah Rayhan" , References: <3A65EF02.EA0D0A54@americasm01.nt.com> Subject: Re: [midcom] Fail over mechanism in midcom Date: Wed, 17 Jan 2001 17:19:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > 1- external agent going out of service and handing the > service off to another agent. > Should the middle box trust the new agent and > impose security challenges on it? I think you're missing something here but raising a related question that does need to be addressed. We're already assuming that more than one agent can talk to a middlebox. What we haven't discussed, however, is the question of ownership of transactions. If agent A can request a pinhole, will it be possible to authorize agent B to dink with that pinhole (close it, extend its lifetime, etc.). This strikes me as an authorization/policy question rather than having much to do directly with failover. > 2- middle box going out of service and handing the service > off to another middle box. This really is a very hard problem for a bunch of reasons and I cannot imagine how to do it reliably for NAT unless the whole box is being failed over. And if that's the case, then it's already being handled elsewhere. You may want to look at the reliable server pooling documents, although I think that rserpool is quite unsuitable for applications maintaining a lot of state, which a middlebox (firewall, NAT, etc.) almost inarguably is. At any rate, this is clearly out of scope for midcom. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jan 17 17:52:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27698 for ; Wed, 17 Jan 2001 17:52:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21141; Wed, 17 Jan 2001 17:45:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21109 for ; Wed, 17 Jan 2001 17:45:23 -0500 (EST) Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27631 for ; Wed, 17 Jan 2001 17:45:21 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA08290; Wed, 17 Jan 2001 17:48:05 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 17 Jan 2001 17:42:05 -0500 Message-ID: From: Tim Rang To: "'Melinda Shore'" , Abdallah Rayhan , midcom@ietf.org Subject: RE: [midcom] Fail over mechanism in midcom Date: Wed, 17 Jan 2001 17:42:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Inflexible ownership would be a very bad thing. Consider an application that dies and another takes over it's work. If that "fail-over" box cannot terminate a resource, the only way that resource may be able to be cleaned up is by timeout, if a timeout is available. Unless that ownership could be defined as a group to which multiple apps might belong... Tim Rang > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Wednesday, January 17, 2001 5:19 PM > To: Abdallah Rayhan; midcom@ietf.org > Subject: Re: [midcom] Fail over mechanism in midcom > > > > 1- external agent going out of service and handing the > > service off to another agent. > > Should the middle box trust the new agent and > > impose security challenges on it? > > I think you're missing something here but raising > a related question that does need to be addressed. > We're already assuming that more than one agent > can talk to a middlebox. What we haven't discussed, > however, is the question of ownership of transactions. > If agent A can request a pinhole, will it be possible > to authorize agent B to dink with that pinhole (close > it, extend its lifetime, etc.). This strikes me as an > authorization/policy question rather than having much > to do directly with failover. > > > 2- middle box going out of service and handing the service > > off to another middle box. > > This really is a very hard problem for a bunch of > reasons and I cannot imagine how to do it reliably > for NAT unless the whole box is being failed over. > And if that's the case, then it's already being handled > elsewhere. You may want to look at the reliable > server pooling documents, although I think that > rserpool is quite unsuitable for applications > maintaining a lot of state, which a middlebox > (firewall, NAT, etc.) almost inarguably is. At > any rate, this is clearly out of scope for midcom. > > Melinda > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jan 17 18:55:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29131 for ; Wed, 17 Jan 2001 18:55:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21769; Wed, 17 Jan 2001 18:45:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21736 for ; Wed, 17 Jan 2001 18:45:52 -0500 (EST) Received: from mordred.cs.ucla.edu (xu0n05@[131.179.192.128]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28805 for ; Wed, 17 Jan 2001 18:45:53 -0500 (EST) Received: (from scottm@localhost) by mordred.cs.ucla.edu (8.11.1/UCLACS-5.0) id f0HNjrc97951 for midcom@ietf.org; Wed, 17 Jan 2001 15:45:53 -0800 (PST) Date: Wed, 17 Jan 2001 15:45:53 -0800 From: Scott Michel To: midcom@ietf.org Message-ID: <20010117154553.B97933@mordred.cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [midcom] How much leeway does this WG have? Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I've yet to read the charter, so this is going to be a completely clueless question, but I'm willing to take some heat for it. How much leeway does the WG have in proposing architectures? Clearly, as WREC and FOGHAT pointed out, there's a lot of intermediate infrastructure out there that add value. However, it does strike me that we're moving in the direction of building application-level networks. Which, it turns out, happens to be my PhD research topic. Would it be completely inappropriate for me to write an I-D that describes a generalized application-level router/forwarder architecture? Such an architecture doesn't really exist and while this WG is clearly a distraction from getting my research work done to proove the concept, the I-D may nonetheless be somewhat useful. -scooter -- Scott Michel | No research ideal ever survives UCLA Computer Science | contact with implementation. PhD Graduate Student | !! Futuaris nisi irrisus ridebis !! _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jan 17 19:33:55 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29772 for ; Wed, 17 Jan 2001 19:33:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA22152; Wed, 17 Jan 2001 19:23:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA22121 for ; Wed, 17 Jan 2001 19:23:36 -0500 (EST) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29582 for ; Wed, 17 Jan 2001 19:23:31 -0500 (EST) Received: from fokus.gmd.de (dhcp012 [195.37.78.140]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id BAA00037; Thu, 18 Jan 2001 01:23:28 +0100 (MET) Message-ID: <3A663776.6A65908B@fokus.gmd.de> Date: Thu, 18 Jan 2001 01:23:18 +0100 From: Jiri Kuthan Organization: GMD Fokus X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Scott Michel CC: midcom@ietf.org Subject: Re: [midcom] How much leeway does this WG have? References: <20010117154553.B97933@mordred.cs.ucla.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Scott Michel wrote: [...] > Would it be completely inappropriate for me to write an I-D that > describes a generalized application-level router/forwarder architecture? > Such an architecture doesn't really exist and while this WG is clearly > a distraction from getting my research work done to proove the concept, > the I-D may nonetheless be somewhat useful. I personally consider application in network a suboptimal idea. I accept as a matter of fact that ALGs are present in firewalls/NATs and would like to make the ALGs somewhat easier to live with by decomposition. I would not advocate adding even more application into network. As for this WG I think we should keep focused on the urgent problems and not extend the scope. Jiri _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jan 17 19:48:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29976 for ; Wed, 17 Jan 2001 19:48:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA22391; Wed, 17 Jan 2001 19:39:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA22360 for ; Wed, 17 Jan 2001 19:39:03 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29852 for ; Wed, 17 Jan 2001 19:39:03 -0500 (EST) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA11175; Wed, 17 Jan 2001 16:38:42 -0800 (PST) Received: from localhost.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by airborne.cisco.com (Mirapoint) with ESMTP id AEW01414; Wed, 17 Jan 2001 16:38:32 -0800 (PST) Received: by localhost.cisco.com (Postfix, from userid 500) id 0FCE418992; Wed, 17 Jan 2001 19:38:33 -0500 (EST) Date: Wed, 17 Jan 2001 19:38:33 -0500 From: Scott Brim To: Scott Michel Cc: midcom@ietf.org Subject: Re: [midcom] How much leeway does this WG have? Message-ID: <20010117193833.B1033@localhost.co-nectschools.net> References: <20010117154553.B97933@mordred.cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010117154553.B97933@mordred.cs.ucla.edu>; from scottm@cs.ucla.edu on Wed, Jan 17, 2001 at 03:45:53PM -0800 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Wed, Jan 17, 2001 at 03:45:53PM -0800, Scott Michel wrote: > Would it be completely inappropriate for me to write an I-D that > describes a generalized application-level router/forwarder architecture? > Such an architecture doesn't really exist and while this WG is clearly > a distraction from getting my research work done to proove the concept, > the I-D may nonetheless be somewhat useful. Right now IMHO it would be much more appropriate to address the basic requirements we're trying to meet. After that you could demonstrate how your architecture meets those requirements and also satisfies other potential needs without causing its performance of midcom functions to deteriorate too much. ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jan 18 09:20:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24356 for ; Thu, 18 Jan 2001 09:20:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06544; Thu, 18 Jan 2001 09:13:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06518 for ; Thu, 18 Jan 2001 09:13:20 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24118 for ; Thu, 18 Jan 2001 09:13:16 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA05816; Thu, 18 Jan 2001 06:12:57 -0800 (PST) Received: from spandex (rtp-vpn-122.cisco.com [10.82.192.122]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id ADV04923; Thu, 18 Jan 2001 06:11:58 -0800 (PST) Message-ID: <009001c08158$e7b248e0$d45904d1@cisco.com> From: "Melinda Shore" To: "Scott Michel" , References: <20010117154553.B97933@mordred.cs.ucla.edu> Subject: Re: [midcom] How much leeway does this WG have? Date: Thu, 18 Jan 2001 09:13:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > How much leeway does the WG have in proposing architectures? Clearly, > as WREC and FOGHAT pointed out, there's a lot of intermediate > infrastructure out there that add value. However, it does strike me > that we're moving in the direction of building application-level > networks. Which, it turns out, happens to be my PhD research topic. It's probably (!!) a good idea to read the charter. We're not going to be modifying our scope or deliverables absent some really (and I mean *really*) compelling reason to do so, and frankly I just don't see that happening. That said, one of the things we're doing is proposing an architecture. The immediate focus of that architectural work is firewalls and NATs. Anything that moves the work forward is quite very extremely welcome, whether it's contributed in the form of mailing list discussion, meeting participation, or writing an individual draft. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jan 18 14:31:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02257 for ; Thu, 18 Jan 2001 14:31:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12242; Thu, 18 Jan 2001 14:21:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12212 for ; Thu, 18 Jan 2001 14:21:54 -0500 (EST) Received: from panther.cs.ucla.edu (Panther.CS.UCLA.EDU [131.179.128.25]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01978 for ; Thu, 18 Jan 2001 14:21:52 -0500 (EST) Received: from rdwarrior (panther.cs.ucla.edu [131.179.128.25]) by panther.cs.ucla.edu (8.9.1/UCLACS-5.0) with SMTP id LAA15356 for ; Thu, 18 Jan 2001 11:21:51 -0800 (PST) Message-ID: <009e01c08184$16f11b60$47cadd82@aero.org> From: "B. Scott Michel" To: Subject: Fw: [midcom] How much leeway does this WG have? Date: Thu, 18 Jan 2001 11:23:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Thanks to Jiri for forwarding this back to me. I forgot to cc the list. :-( ----- Original Message ----- > On Thu, Jan 18, 2001 at 01:23:18AM +0100, Jiri Kuthan wrote: > > Scott Michel wrote: > > I personally consider application in network a suboptimal idea. I accept > > as a matter of fact that ALGs are present in firewalls/NATs and would > > like to make the ALGs somewhat easier to live with by decomposition. > > I would not advocate adding even more application into network. > > > > As for this WG I think we should keep focused on the urgent problems > > and not extend the scope. I didn't say anything about putting applications in networks. Let me clarify: There seems to be a trend where the interaction between applications looks more like a network and not the traditional model of client-server, with the "middle" boxes transparently or not so transparently interacting with the traffic in-flight. There are several application-level networks interacting in this WG's charter, one of which happens need to communicate policy between the middle boxes. I'm willing to propose an application-level routing and forwarding architecture which does solve the middle-box interaction problem. It's what I'm researching for a degree anyway. I think my proposal would fit into the charter in the first deliverable but would have to be narrowed so as not to broaden the scope of the WG. It should be sufficiently general so as to provide the generalized communication interfaces referenced in the WG's charter. If my proposal is spooge, it's spooge. If it's a useful contribution, so much the better. -scooter _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jan 19 17:05:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07122 for ; Fri, 19 Jan 2001 17:05:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07421; Fri, 19 Jan 2001 16:56:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07389 for ; Fri, 19 Jan 2001 16:55:58 -0500 (EST) Received: from ctron-dnm.ctron.com (firewall-user@[12.25.1.120]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07006 for ; Fri, 19 Jan 2001 16:55:57 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id RAA28744 for ; Fri, 19 Jan 2001 17:01:44 -0500 (EST) Received: from olympus.ctron.com(134.141.72.253) by ctron-dnm.ctron.com via smap (4.1) id xma028686; Fri, 19 Jan 01 17:01:33 -0500 Received: from ctron-exc2.ctron.com (ctron-exc2 [134.141.77.97]) by olympus.ctron.com (8.8.7/8.8.7) with ESMTP id QAA03730 for ; Fri, 19 Jan 2001 16:55:46 -0500 (EST) Received: by ctron-exc2.ctron.com with Internet Mail Service (5.5.2650.21) id ; Fri, 19 Jan 2001 16:55:45 -0500 Message-ID: From: "Norseth, KC" To: midcom@ietf.org Date: Fri, 19 Jan 2001 16:55:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08262.920D349E" Subject: [midcom] Tunneling Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08262.920D349E Content-Type: text/plain; charset="iso-8859-1" How does this relate to tunneling and the communications involved with it? ------_=_NextPart_001_01C08262.920D349E Content-Type: text/html; charset="iso-8859-1" Tunneling

How does this relate to tunneling and the communications involved with it?

------_=_NextPart_001_01C08262.920D349E-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jan 23 04:52:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07972 for ; Tue, 23 Jan 2001 04:52:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18110; Tue, 23 Jan 2001 04:40:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18079 for ; Tue, 23 Jan 2001 04:40:41 -0500 (EST) Received: from exchange_03.2wire.com ([63.203.253.73]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07931 for ; Tue, 23 Jan 2001 04:40:41 -0500 (EST) Received: by exchange.2wire.com with Internet Mail Service (5.5.2650.21) id ; Tue, 23 Jan 2001 01:51:18 -0800 Message-ID: <91CDB24C5FCDD31198A2009027E79021011BD840@exchange.2wire.com> From: Randy Turner To: "'midcom@ietf.org'" Date: Tue, 23 Jan 2001 01:51:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [midcom] WG scope/deliverables Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I'm assuming that the model of an RSIP client and server would be an example of middlebox communication, per the charter. And further, that the real deliverable for this working group would be a capability that would superset RSIP and provide a more generic model for middlebox policy interrogation, including more sophisticated trust models. Is this correct? Thanks! Randy _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jan 23 05:24:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08128 for ; Tue, 23 Jan 2001 05:24:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18489; Tue, 23 Jan 2001 05:12:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18459 for ; Tue, 23 Jan 2001 05:12:46 -0500 (EST) Received: from newdev.harvard.edu ([140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08081 for ; Tue, 23 Jan 2001 05:12:45 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id FAA08299; Tue, 23 Jan 2001 05:12:45 -0500 (EST) Date: Tue, 23 Jan 2001 05:12:45 -0500 (EST) From: Scott Bradner Message-Id: <200101231012.FAA08299@newdev.harvard.edu> To: midcom@ietf.org, rturner@2wire.com Subject: Re: [midcom] WG scope/deliverables Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org at this point the midcom WG is working on requirements not solutions RSIP may be an option but it looks to me like its one of the more complex options Scott --- From midcom-admin@ietf.org Tue Jan 23 05:00:10 2001 From: Randy Turner To: "'midcom@ietf.org'" Date: Tue, 23 Jan 2001 01:51:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [midcom] WG scope/deliverables Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I'm assuming that the model of an RSIP client and server would be an example of middlebox communication, per the charter. And further, that the real deliverable for this working group would be a capability that would superset RSIP and provide a more generic model for middlebox policy interrogation, including more sophisticated trust models. Is this correct? Thanks! Randy _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jan 23 08:22:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10630 for ; Tue, 23 Jan 2001 08:22:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20085; Tue, 23 Jan 2001 08:14:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20057 for ; Tue, 23 Jan 2001 08:14:15 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10485 for ; Tue, 23 Jan 2001 08:14:15 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id FAA11208; Tue, 23 Jan 2001 05:13:55 -0800 (PST) Received: from spandex (rtp-vpn-69.cisco.com [10.82.192.69]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id ADY14905; Tue, 23 Jan 2001 05:13:41 -0800 (PST) Message-ID: <007801c0853e$7d8f8c40$d45904d1@cisco.com> From: "Melinda Shore" To: "Randy Turner" , References: <91CDB24C5FCDD31198A2009027E79021011BD840@exchange.2wire.com> Subject: Re: [midcom] WG scope/deliverables Date: Tue, 23 Jan 2001 08:14:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > I'm assuming that the model of an RSIP client and server would be an example > of middlebox communication, per the charter. And further, that the real > deliverable for this working group > would be a capability that would superset RSIP and provide a more generic > model for middlebox policy interrogation, including more sophisticated trust > models. Is this correct? This isn't a competition and there's no intention to supersede RSIP. RSIP doesn't solve the entire set of problems we're facing (3rd-party "control" interfaces, large number of always- or usually-on devices). It's possible that RSIP may end up being used as the base protocol when we do get to that stage, but there are other candidate protocols, as well. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jan 23 16:10:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24622 for ; Tue, 23 Jan 2001 16:10:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25630; Tue, 23 Jan 2001 15:57:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25599 for ; Tue, 23 Jan 2001 15:57:13 -0500 (EST) Received: from canospam.agcs.com ([130.131.166.29]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24401 for ; Tue, 23 Jan 2001 15:57:12 -0500 (EST) Received: from pxilesafe.agcs.com (pxilesafe.agcs.com [130.131.74.113]) by canospam.agcs.com (8.9.3/8.9.1) with SMTP id NAA25506 for ; Tue, 23 Jan 2001 13:56:41 -0700 (MST) Posted-Date: Tue, 23 Jan 2001 13:56:41 -0700 (MST) Received: FROM bootstrap.agcs.com BY pxilesafe.agcs.com ; Tue Jan 23 13:56:44 2001 -0700 Received: from pxmail1.agcs.com (pxmail1.agcs.com [130.131.168.5]) by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id NAA03959 for ; Tue, 23 Jan 2001 13:56:40 -0700 (MST) Received: from agcs.com ([130.131.32.37]) by pxmail1.agcs.com (Netscape Messaging Server 3.61) with ESMTP id AAA41FC for ; Tue, 23 Jan 2001 13:56:39 -0700 Message-ID: <3A6DEFDD.48607C38@agcs.com> Date: Tue, 23 Jan 2001 13:55:57 -0700 From: "Brian Hagar" Reply-To: hagarb@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Midcom Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] March information needed Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Greetings, I am looking for information on how to subscribe to the March (middlebox discovery) mailing list. Is there also a URL? If not is there an archive of past e-mail messages? Thank You, Brian Hagar _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jan 24 08:09:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19583 for ; Wed, 24 Jan 2001 08:09:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA11042; Wed, 24 Jan 2001 08:00:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28654 for ; Tue, 23 Jan 2001 21:07:50 -0500 (EST) Received: from lint.cisco.com ([171.68.224.209]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28092 for ; Tue, 23 Jan 2001 21:07:50 -0500 (EST) Received: from cisco.com (dhcp-2sjc13-85-244.cisco.com [171.70.85.244]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA18579; Tue, 23 Jan 2001 18:06:47 -0800 (PST) Message-ID: <3A6E38C9.6229473B@cisco.com> Date: Tue, 23 Jan 2001 18:07:05 -0800 From: Eliot Lear Reply-To: lear@cisco.com X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: hagarb@agcs.com CC: Midcom Subject: Re: [midcom] March information needed References: <3A6DEFDD.48607C38@agcs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Send an email to mailer@cisco.com. Include in it the following: subscribe march {youraddresshere} Eliot Brian Hagar wrote: > > Greetings, > > I am looking for information on how to subscribe to the March (middlebox discovery) mailing list. Is there also a URL? If not is there an archive of past e-mail messages? > > Thank You, > Brian Hagar > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom -- Eliot Lear lear@cisco.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jan 24 20:09:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02937 for ; Wed, 24 Jan 2001 20:09:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19416; Wed, 24 Jan 2001 20:01:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19387 for ; Wed, 24 Jan 2001 20:01:33 -0500 (EST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02807 for ; Wed, 24 Jan 2001 20:01:34 -0500 (EST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 24 Jan 2001 09:40:09 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 24 Jan 2001 09:40:53 -0800 (Pacific Standard Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Wed, 24 Jan 2001 09:40:53 -0800 content-class: urn:content-classes:message Subject: RE: [midcom] WG scope/deliverables Date: Wed, 24 Jan 2001 09:40:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0 Thread-Topic: [midcom] WG scope/deliverables Thread-Index: AcCFPpaudcfRie5PTaqI9JDjsZxzZAA6+Q3Q From: "Christian Huitema" To: "Melinda Shore" , "Randy Turner" , X-OriginalArrivalTime: 24 Jan 2001 17:40:53.0559 (UTC) FILETIME=[CC984C70:01C0862C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA19388 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit At this stage, I believe it is important to concentrate on the requirements. Part of the problem with RSIP is that it tries to solve a very large problem set, and so end up being very hard to deploy -- you basically have to rework all the TCP stack in the clients. I think that we should take the "ease of deployment" into account. I see at least three dimensions that affect the ease of deployment: 1) Timing considerations. Should we open resources in real time, exactly when we need them, or through an off-line configuration action? The latter is less powerful, but it is also much less intrusive on the host software. A configuration can be changed by usin the right command line parameter; a real-time action implies rewriting the software to call an API, and to deal with the new error cases introduced by this API. 2) Trust model. Most of the "NAT appliance" configuration systems today have a very simple trust model: whoever is inside the perimeter is allowed to modify the mappings through some vendor specific web interaction or telnet connection. Most of the firewalls also have a simple trust model: only registered administrators can change the configuration. We could change that to introduce various forms of ACL or policy decisions, but this definitely introduces a higher complexity in both software and operation. 3) First party versus third party. There are implications on the trust model, which is obviously more complex in the first party case, and on the protocol design -- this has already been debated in the list. First party solutions tend to be only required if we want to enable "real-time" opening, but real-time can also be achieved with relay servers. -- Christian Huitema > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Tuesday, January 23, 2001 5:15 AM > To: Randy Turner; midcom@ietf.org > Subject: Re: [midcom] WG scope/deliverables > > > > I'm assuming that the model of an RSIP client and server > would be an example > > of middlebox communication, per the charter. And further, > that the real > > deliverable for this working group > > would be a capability that would superset RSIP and provide > a more generic > > model for middlebox policy interrogation, including more > sophisticated trust > > models. Is this correct? > > This isn't a competition and there's no intention to > supersede RSIP. RSIP doesn't solve the entire set of > problems we're facing (3rd-party "control" interfaces, > large number of always- or usually-on devices). It's > possible that RSIP may end up being used as the base > protocol when we do get to that stage, but there are > other candidate protocols, as well. > > Melinda > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jan 25 09:27:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26709 for ; Thu, 25 Jan 2001 09:27:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03306; Thu, 25 Jan 2001 09:17:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03275 for ; Thu, 25 Jan 2001 09:17:57 -0500 (EST) Received: from po4.wam.umd.edu (po4.wam.umd.edu [128.8.10.166]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26476 for ; Thu, 25 Jan 2001 09:17:55 -0500 (EST) Received: from rac4.wam.umd.edu (IDENT:root@rac4.wam.umd.edu [128.8.10.144]) by po4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id JAA03782 for ; Thu, 25 Jan 2001 09:17:55 -0500 (EST) Received: from rac4.wam.umd.edu (IDENT:sendmail@localhost [127.0.0.1]) by rac4.wam.umd.edu (8.9.3/8.9.3) with SMTP id JAA25046 for ; Thu, 25 Jan 2001 09:17:54 -0500 (EST) Received: from localhost (karir@localhost) by rac4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id JAA25042 for ; Thu, 25 Jan 2001 09:17:54 -0500 (EST) X-Authentication-Warning: rac4.wam.umd.edu: karir owned process doing -bs Date: Thu, 25 Jan 2001 09:17:54 -0500 (EST) From: Manish Karir To: midcom@ietf.org Subject: RE: [midcom] WG scope/deliverables In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Hi, I'm new to the list and this working group... though I have scanned the charter and the list archives..I'm still not clear regarding the scope of the WG and where this group fits with the rest of the group. Basically I found this WG while looking for a more sympathetic place for my arguments for supporting intelligence in the middle of the network-boxes....All the other groups are outright hostile to anyone proposing anything thats not End-to-End. Is this the charter of this group?. Basically to come up with some agreed upon symantics for devices int he middle of the network, to support things cannot be done end-to-end.? Though I have seen talk of NAT in this group..I would also like to point out some other types of devices that might benefit from this effort. In particular my interest was in TCP-connection splitting gateways. But to a certain extent caches and all sorts of proxies fall into the same group as well. thanks manish _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jan 25 11:23:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03033 for ; Thu, 25 Jan 2001 11:23:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04860; Thu, 25 Jan 2001 11:14:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04833 for ; Thu, 25 Jan 2001 11:14:23 -0500 (EST) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02716 for ; Thu, 25 Jan 2001 11:14:22 -0500 (EST) Received: from fokus.gmd.de (dhcp012 [195.37.78.140]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id RAA24032; Thu, 25 Jan 2001 17:14:13 +0100 (MET) Message-ID: <3A7050CD.11AD06E8@fokus.gmd.de> Date: Thu, 25 Jan 2001 17:14:05 +0100 From: Jiri Kuthan Organization: GMD Fokus X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Manish Karir CC: midcom@ietf.org Subject: Re: [midcom] WG scope/deliverables References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Manish Karir wrote: > > Hi, > > I'm new to the list and this working group... > though I have scanned the charter and the list archives..I'm still > not clear regarding the scope of the WG and where this group fits > with the rest of the group. > > Basically I found this WG while looking for a more sympathetic > place for my arguments for supporting intelligence in the middle > of the network-boxes....All the other groups are outright hostile > to anyone proposing anything thats not End-to-End. Actually, the idea here is to move the intelligence OUT of the boxes. Jiri _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jan 26 09:42:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11846 for ; Fri, 26 Jan 2001 09:42:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26222; Fri, 26 Jan 2001 09:33:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26191 for ; Fri, 26 Jan 2001 09:33:30 -0500 (EST) Received: from sean.ebone.net (IDENT:postfix@sean.ebone.net [195.158.227.211]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11764 for ; Fri, 26 Jan 2001 09:33:27 -0500 (EST) Received: by sean.ebone.net (Postfix, from userid 1113) id 959DC817; Fri, 26 Jan 2001 15:33:27 +0100 (CET) To: midcom@ietf.org From: Sean Doran Date: 26 Jan 2001 15:33:27 +0100 Message-ID: <52n1cetmbs.fsf@sean.ebone.net> Lines: 86 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [midcom] middle-boxes and a historical precedence Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org One of the obvious slants one can take on the posted WG description is that "existing IETF protocols" end up being a language used to communicate with a middle-box, which translates that language into something another host or middle-box elsewhere in the network can process. In essence, IPv4 can be seen as a host-to-router protocol, and the router-to-router protocol can be IPv4-with-different-addresses, IPv6, MPLS, OSI CLNP/X.25 PLP(IS8208 "CONP")/IONL, you-name-it. The major difference between a middle-box and a traditional router is that the adjustments done to packets may go beyond simple bookkeeping adjustments in the network layer header. In other words: a traditional router adjusts the likes of TTL, does fragmentation, sends back error messages, and so forth; a middle-box router does all this and _also_ may rewrite network-layer addresses, may rewrite the network-layer header information into a completely different protocol's analogue, may make adjustments to the payload of the network-layer, and may even act as an ALG. In my opinion, there shouldn't be an assumption about _where_ the middle-box sits; it could be on a LAN with a bunch of hosts, it could be on either side of a provider/customer network boundary, it could be on a provider/provider boundary, or going the other way, it could be integrated directly with a single host. If this is a reasonable point of view, then an obvious goal of the WG would be to attempt to keep the possible output of a middle-box as general as possible when the input is an IPv4 packet from a host (and of course the complementary maximally-general->IPv4 for packets destined to the same host). At the same time, the host should be as close to unaware as possible that this whole process is occurring. The output of the IRTF's NSRG (when it comes) likely would be useful to the WG. See http://www.irtf.org/charters/namespace.html Ad blurb. Padlipsky's book, _The Elements of Networking Style_, is available once again, thanks to backinprint.com; it's apparently available in the usual book-buying places. An interesting MIDCOM-relevant excerpt: [writing in ca. 1984 about INFOCOM 83's "Futures" panel, which was thinking about what things would be like when hardwar was cheap enough that "everybody" had enough "computer power" at home, Padlipsky developed a Vision, which he shared with the audience] Given enough "compute power," what will happen is that the technotheology can and will become moot: Nobody will have to give up his or her favorite approach to Intercomputer networking, nor will anybody have to give up on the sunken investment in current networking software, nor will somebody have to come up with something that really does border on the magical by way of Translating / Mapping Gateways. No, what will happen is that when you want to get at a particular resource you'll just go off to it in _its "own" protocol suite_... because you'll have an Outboard Processing Environment (see Chapter 6) available to you, on that cheap and plentiful enough hardware, which is capable of interpreting all reasonable (and some unreasonable) suites "in parallel," so it doesn't really mattter much -- except to technoaestheticians -- which suite is "best". I'd like to think that's the way it will be, actually; it's so attractively Ecumenical. [Though I must confess to a lingering fear that the suites which do assume end-to-endness of the Network level c0ould still foul things up...] The Outboard Processing Environment is basically a middle-box as above, only the hosts may talk not just IPv4, but also IPv6, MPLS, Appletalk, IPX, DECNET, bla bla bla. This "OPE" middle-box would then convert to something that some set of routers could actually deliver to some other middle-box, or host, in such a way that the ultimate host can use the data as intended (including replying to it). Sean. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jan 26 10:00:55 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12056 for ; Fri, 26 Jan 2001 10:00:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26445; Fri, 26 Jan 2001 09:52:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26414 for ; Fri, 26 Jan 2001 09:52:36 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11967 for ; Fri, 26 Jan 2001 09:52:36 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id GAA26443; Fri, 26 Jan 2001 06:51:36 -0800 (PST) Received: from spandex (rtp-vpn-142.cisco.com [10.82.192.142]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id ADZ10087; Fri, 26 Jan 2001 06:51:32 -0800 (PST) Message-ID: <00e401c087a7$a96c2920$d45904d1@cisco.com> From: "Melinda Shore" To: , "Sean Doran" References: <52n1cetmbs.fsf@sean.ebone.net> Subject: Re: [midcom] middle-boxes and a historical precedence Date: Fri, 26 Jan 2001 09:52:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > In my opinion, there shouldn't be an assumption about > _where_ the middle-box sits; it could be on a LAN with a > bunch of hosts, it could be on either side of a > provider/customer network boundary, it could be on a > provider/provider boundary, or going the other way, it > could be integrated directly with a single host. This is the ideal, I think, but we should remember that it's at the cost of additional complexity in the security mechanisms. > At the same time, the host should be > as close to unaware as possible that this whole process is > occurring. I'm not sure exactly what you mean, here, but inasmuch as the intention is to offload application processing from the middlebox and move it back to a host or something like a call-control server, I'd probably disagree. It may be possible to do something similar to the auto-SOCKS- ification DLLs and shared libraries, but those really aren't *that* transparent. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jan 26 10:31:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12364 for ; Fri, 26 Jan 2001 10:31:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26903; Fri, 26 Jan 2001 10:22:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26876 for ; Fri, 26 Jan 2001 10:22:53 -0500 (EST) Received: from sean.ebone.net (IDENT:postfix@sean.ebone.net [195.158.227.211]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12236 for ; Fri, 26 Jan 2001 10:22:52 -0500 (EST) Received: by sean.ebone.net (Postfix, from userid 1113) id C69E9817; Fri, 26 Jan 2001 16:22:52 +0100 (CET) To: midcom@ietf.org, mshore@cisco.com, smd@ebone.net Subject: Re: [midcom] middle-boxes and a historical precedence Message-Id: <20010126152252.C69E9817@sean.ebone.net> Date: Fri, 26 Jan 2001 16:22:52 +0100 (CET) From: smd@ebone.net (Sean Doran) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org | This is the ideal, I think, but we should remember | that it's at the cost of additional complexity in | the security mechanisms. Well, Chiappa has been accused of "arbitrary complexity for the sake of maximum flexibility", and we tend to agree on a bunch of things, so, yes... :-) I agree that the closer to a host a middle-box is, the easier it's going to be to implement, by and large. I am also quite happy to be told that putting a middle-box between size-large NSPs is ludicrous, and today it probably is. | > At the same time, the host should be | > as close to unaware as possible that this whole process is | > occurring. | | I'm not sure exactly what you mean, here, Many things tend to work in the presence of a NAT, or a NAT+ALG, without needing either host to adapt to or even be aware of the translation/gatewaying. This is a nice feature. It would be nice to maintain this feature when translating between IPv4 and some arbitrary protocol (like v6). Obviously, trust issues will complicate things, where identities are implicit or tightly-coupled with network layer addresses. Having some set of guidelines which describe how to be middle-box-friendly seems like a useful tool for future developer/networker types, but at least as useful is minimizing the amount of work needed to be middle-box-friendly in the first place.. Sean. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jan 26 15:57:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21555 for ; Fri, 26 Jan 2001 15:57:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01559; Fri, 26 Jan 2001 15:45:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01532 for ; Fri, 26 Jan 2001 15:45:15 -0500 (EST) Received: from ginger.lcs.mit.edu (ginger.lcs.mit.edu [18.26.0.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21149 for ; Fri, 26 Jan 2001 15:45:11 -0500 (EST) Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id PAA06731; Fri, 26 Jan 2001 15:45:10 -0500 Date: Fri, 26 Jan 2001 15:45:10 -0500 From: "J. Noel Chiappa" Message-Id: <200101262045.PAA06731@ginger.lcs.mit.edu> To: midcom@ietf.org Subject: Re: [midcom] middle-boxes and a historical precedence Cc: jnc@ginger.lcs.mit.edu Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > From: smd@ebone.net (Sean Doran) >> we should remember that it's at the cost of additional complexity > Well, Chiappa has been accused of "arbitrary complexity for the sake of > maximum flexibility" Since my name is being bandied about here, let me just throw in a parenthetical aside that a certain level of complexity (q.v. Nimrod) doesn't bother me, as long as i) it's kept *as simple as possible*, and ii) you're getting *some really good capability* out of it. However, lots of the stuff I see being deployed today is i) incredibly complicated, and ii) doesn't seem to be gaining a whole lot of ground in terms of *new* functionality. Noel _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jan 31 02:57:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07834 for ; Wed, 31 Jan 2001 02:57:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA03639; Wed, 31 Jan 2001 02:47:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA03612 for ; Wed, 31 Jan 2001 02:47:24 -0500 (EST) Received: from gate.internaut.com ([64.38.134.108]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07790 for ; Wed, 31 Jan 2001 02:47:23 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f0V7gRR17768; Tue, 30 Jan 2001 23:42:27 -0800 From: "Bernard Aboba" To: "Randy Turner" , Subject: RE: [midcom] WG scope/deliverables Date: Tue, 30 Jan 2001 23:47:39 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <91CDB24C5FCDD31198A2009027E79021011BD840@exchange.2wire.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit >the real deliverable for this working group would be a capability that >would superset RSIP Keep it simple, please. RSIP's major failing was that it tried to do too much, not too little. The world is littered with the bones of under-deployed firewall traversal solutions. The crux of the problem is enabling inbound traffic. Let's solve that with as little extraneous baggage as possible. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jan 31 03:43:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08160 for ; Wed, 31 Jan 2001 03:43:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA04217; Wed, 31 Jan 2001 03:27:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA04186 for ; Wed, 31 Jan 2001 03:27:33 -0500 (EST) Received: from exchange_03.2wire.com (exchange_03 [63.203.253.73] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08068 for ; Wed, 31 Jan 2001 03:27:32 -0500 (EST) Received: by exchange.2wire.com with Internet Mail Service (5.5.2650.21) id ; Wed, 31 Jan 2001 00:38:21 -0800 Message-ID: <91CDB24C5FCDD31198A2009027E79021011BD894@exchange.2wire.com> From: Randy Turner To: "'Bernard Aboba '" , Randy Turner , "'midcom@ietf.org '" Subject: RE: [midcom] WG scope/deliverables Date: Wed, 31 Jan 2001 00:38:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org The charter seems to indicate much more than just enabling inbound traffic, but I'll wait and see what falls out for requirements. I think "enabling inbound traffic" is the first easily recognizable, enumerated requirement I've heard. I personally didn't have much of a problem with RSIP, although it did put a large burden on existing client stacks. As a vendor that would have to implement the server side of this equation, we saw RSIP functionality as pretty straightforward. A lot of good information and useful techniques and knowledge are available from the RSIP group. So I would ask that, if the goals of this effort are a proper subset of what RSIP provides, then we should probably reuse the ideas instead of reinventing them again. Of course we could recast these techniques in a different transport methodology, but alot of the concepts of operation would be the same. Randy -----Original Message----- From: Bernard Aboba To: Randy Turner; midcom@ietf.org Sent: 1/30/01 11:47 PM Subject: RE: [midcom] WG scope/deliverables >the real deliverable for this working group would be a capability that >would superset RSIP Keep it simple, please. RSIP's major failing was that it tried to do too much, not too little. The world is littered with the bones of under-deployed firewall traversal solutions. The crux of the problem is enabling inbound traffic. Let's solve that with as little extraneous baggage as possible. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jan 31 09:54:50 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16164 for ; Wed, 31 Jan 2001 09:54:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08828; Wed, 31 Jan 2001 09:43:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08745 for ; Wed, 31 Jan 2001 09:41:05 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15335 for ; Wed, 31 Jan 2001 09:41:05 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id JAA12469; Wed, 31 Jan 2001 09:39:45 -0500 (EST) Message-Id: <200101311439.JAA12469@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Bernard Aboba" cc: "Randy Turner" , midcom@ietf.org Subject: Re: [midcom] WG scope/deliverables In-reply-to: Your message of "Tue, 30 Jan 2001 23:47:39 PST." Date: Wed, 31 Jan 2001 09:39:45 -0500 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > Keep it simple, please. RSIP's major failing was that it tried to do too > much, not too little. In a sense that's true, but I'd say it differently. RSIP's major failing was that it tried to do more than is reasonable or feasible given the inherent limitations of NAT. If this group takes the attitude that NATs are inherently broken and that there's really no way to fix them in the long term without phasing out the NAT part, it's much more likely to produce something useful than if it tries to find a way to incorporate NATs into the mainstream architecture of the Internet. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jan 31 13:02:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22085 for ; Wed, 31 Jan 2001 13:02:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12362; Wed, 31 Jan 2001 12:49:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12334 for ; Wed, 31 Jan 2001 12:49:14 -0500 (EST) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21610 for ; Wed, 31 Jan 2001 12:49:14 -0500 (EST) Received: from fokus.gmd.de (dhcp012 [195.37.78.140]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id SAA29438 for ; Wed, 31 Jan 2001 18:49:14 +0100 (MET) Message-ID: <3A784E0C.32F24E6F@fokus.gmd.de> Date: Wed, 31 Jan 2001 18:40:28 +0100 From: Jiri Kuthan Organization: GMD Fokus X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: midcom@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] [Fwd: I-D ACTION:draft-carpenter-midtax-00.txt] Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Middle boxes: taxonomy and issues > Author(s) : B. Carpenter > Filename : draft-carpenter-midtax-00.txt > Pages : 15 > Date : 30-Jan-01 > > This document is intended as input to IETF discussion about 'middle > boxes' - defined as any intermediary box performing functions apart > from normal, standard functions of an IP router on the data path > between a source host and destination host. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-carpenter-midtax-00.txt > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-carpenter-midtax-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-carpenter-midtax-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > Content-Type: text/plain > Content-ID: <20010130111555.I-D@ietf.org> -- Jiri Kuthan http://www.fokus.gmd.de/usr/kuthan tel:+49-30-34637271 Internet Telephony: http://www.fokus.gmd.de/glone/projects/ipt _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jan 31 14:25:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24131 for ; Wed, 31 Jan 2001 14:25:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13435; Wed, 31 Jan 2001 14:04:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13404 for ; Wed, 31 Jan 2001 14:04:37 -0500 (EST) Received: from ginger.lcs.mit.edu (ginger.lcs.mit.edu [18.26.0.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23637; Wed, 31 Jan 2001 14:04:33 -0500 (EST) Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id OAA21343; Wed, 31 Jan 2001 14:04:29 -0500 Date: Wed, 31 Jan 2001 14:04:29 -0500 From: "J. Noel Chiappa" Message-Id: <200101311904.OAA21343@ginger.lcs.mit.edu> To: midcom@ietf.org, moore@cs.utk.edu Subject: Re: [midcom] WG scope/deliverables Cc: ietf@ietf.org, jnc@ginger.lcs.mit.edu Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > From: Keith Moore > If this group takes the attitude that NATs are inherently broken and > that there's really no way to fix them in the long term without phasing > out the NAT part, it's much more likely to produce something useful > than if it tries to find a way to incorporate NATs into the mainstream > architecture of the Internet. Keith, why don't you start an NAT-Haters mailing list, and take all this disgust with NAT's there? (I'm quite serious about this.) You seem to be having problems accepting that fact that NAT's are selling several orders of magnitudes (I'd guess at least 3, but it's probably more) more units than your preferred alternative. Most people would regard this as a sign that the world has decided, and move on. When life gives you lemons, you have to make lemonade. NAT's are a fact of life, and we will, indeed, have to find some way of incorporating them into the mainstream architecture of the Internet. This is a subject on which I have pondered a lot, for several years - maybe you should wrestle with it too. Noel _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jan 31 16:30:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26094 for ; Wed, 31 Jan 2001 16:30:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14828; Wed, 31 Jan 2001 16:18:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14800 for ; Wed, 31 Jan 2001 16:18:28 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25813; Wed, 31 Jan 2001 16:18:26 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id QAA15700; Wed, 31 Jan 2001 16:18:14 -0500 (EST) Message-Id: <200101312118.QAA15700@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "J. Noel Chiappa" cc: midcom@ietf.org, moore@cs.utk.edu, ietf@ietf.org Subject: Re: [midcom] WG scope/deliverables In-reply-to: Your message of "Wed, 31 Jan 2001 14:04:29 EST." <200101311904.OAA21343@ginger.lcs.mit.edu> Date: Wed, 31 Jan 2001 16:18:14 -0500 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > Keith, why don't you start an NAT-Haters mailing list, and take all this > disgust with NAT's there? (I'm quite serious about this.) Noel, I expressed an opinion that this group should confine itself to addressing short-term goals rather than trying to make NATs a part of the Internet architecture. I said this because I've looked at the problem quite extensively. The more I have done so, the more have concluded that there's no way to restore the valuable functionality that NATs have removed from the Internet without providing another global address space, and that it's much more efficient and less painful to embellish the NATs to become IPv6 routers than it is to embellish both the NATs and applications to support a segmented address space. Thus, while I accept that the market needs a short-term solution to deal with NATs, I also am firmly of the opinion that it's a short-term solution. IPv6 will be attractive for the same reasons that NAT was attractive - it will be the path of least pain to solving a pressing set of problems. Being over-ambitious about goals has prevented more than one working group from accomplishing anything useful, and exhausted lots of talented people in the process. I hardly think that advocating a little restraint in this group's ambition is sufficient justification for personal attacks. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jan 31 17:39:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27074 for ; Wed, 31 Jan 2001 17:39:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15635; Wed, 31 Jan 2001 17:23:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15509 for ; Wed, 31 Jan 2001 17:09:55 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26499; Wed, 31 Jan 2001 17:08:43 -0500 (EST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 31 Jan 2001 22:08:41 +0000 To: "J. Noel Chiappa" cc: midcom@ietf.org, moore@cs.utk.edu, ietf@ietf.org Subject: Re: [midcom] WG scope/deliverables In-reply-to: Your message of "Wed, 31 Jan 2001 14:04:29 EST." <200101311904.OAA21343@ginger.lcs.mit.edu> Date: Wed, 31 Jan 2001 22:08:40 +0000 Message-ID: <17330.980978920@cs.ucl.ac.uk> From: Jon Crowcroft Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org In message <200101311904.OAA21343@ginger.lcs.mit.edu>, "J. Noel Chiappa" typed: >>Keith, why don't you start an NAT-Haters mailing list, and take all this >>disgust with NAT's there? (I'm quite serious about this.) >>You seem to be having problems accepting that fact that NAT's are selling >>several orders of magnitudes (I'd guess at least 3, but it's probably more) >>more units than your preferred alternative. Most people would regard this as >>a sign that the world has decided, and move on. many nats cost nothin - many are check boxes on existing products - alternatives cost money - some day tho, they may be required like IP was when we started with x.25:-) >>When life gives you lemons, you have to make lemonade. NAT's are a fact of >>life, and we will, indeed, have to find some way of incorporating them into >>the mainstream architecture of the Internet. This is a subject on which I have >>pondered a lot, for several years - maybe you should wrestle with it too. when life gives you lemons, pick grapes instead and make wine or bottle spring water and sell that (with or without added CO2) its better for your teeth. cheers jon _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jan 31 18:17:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27686 for ; Wed, 31 Jan 2001 18:17:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16204; Wed, 31 Jan 2001 18:06:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16148 for ; Wed, 31 Jan 2001 18:06:24 -0500 (EST) Received: from web1405.mail.yahoo.com (web1405.mail.yahoo.com [128.11.23.169]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27479 for ; Wed, 31 Jan 2001 18:06:21 -0500 (EST) Received: (qmail 17957 invoked by uid 60001); 31 Jan 2001 23:06:23 -0000 Message-ID: <20010131230623.17956.qmail@web1405.mail.yahoo.com> Received: from [63.202.10.110] by web1405.mail.yahoo.com; Wed, 31 Jan 2001 15:06:23 PST Date: Wed, 31 Jan 2001 15:06:23 -0800 (PST) From: Pyda Srisuresh Subject: Re: [midcom] WG scope/deliverables To: Keith Moore , "J. Noel Chiappa" Cc: midcom@ietf.org, moore@cs.utk.edu, ietf@ietf.org In-Reply-To: <200101312118.QAA15700@astro.cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --- Keith Moore wrote: > > Keith, why don't you start an NAT-Haters mailing list, and take all this > > disgust with NAT's there? (I'm quite serious about this.) > > Noel, > > I expressed an opinion that this group should confine itself to addressing > short-term goals rather than trying to make NATs a part of the Internet > architecture. > With all due respect, Keith, you are saying that addressing NAT concerns should not be a short-term goal. You are OK with the WG addressing firewall concerns however. But, insisting on this and repeating the mantra many times over, even after the WG is formed with a specific mission and chater, is really disruptive to the work being done in the WG. The charter requires the work group to address both NAT and firewall concerns. It is very confusing and intimidating to the folks who are genuinely trying to contribute. You jump on the bandwagon the moment someone says anything about NAT. Soon it turns into a flaming fest. > I said this because I've looked at the problem quite extensively. > The more I have done so, the more have concluded that there's no way > to restore the valuable functionality that NATs have removed from the > Internet without providing another global address space, and that it's > much more efficient and less painful to embellish the NATs to become > IPv6 routers than it is to embellish both the NATs and applications to > support a segmented address space. Well, I (and perhaps many others) respectfully disagree. This is not a short-term solution yet, not until folks have V6 networks deployed. > > Thus, while I accept that the market needs a short-term solution to deal > with NATs, I also am firmly of the opinion that it's a short-term solution. So, if you do agree working that dealing with NATs is a short term solution, why are you so repeatedly trying to torpedo the effort going in to solve the short term problems ? > IPv6 will be attractive for the same reasons that NAT was attractive - > it will be the path of least pain to solving a pressing set of problems. > Agreed, perhaps with the exception of address renumbering. > Being over-ambitious about goals has prevented more than one working > group from accomplishing anything useful, and exhausted lots of > talented people in the process. I hardly think that advocating a little > restraint in this group's ambition is sufficient justification for > personal attacks. > This has been more than just a little advocation of restraint, I might add. > Keith > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom Thanks. regards, suresh __________________________________________________ Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jan 31 19:41:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28926 for ; Wed, 31 Jan 2001 19:41:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17155; Wed, 31 Jan 2001 19:30:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17126 for ; Wed, 31 Jan 2001 19:30:15 -0500 (EST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28806 for ; Wed, 31 Jan 2001 19:30:15 -0500 (EST) Received: from df-virus1.platinum.corp.microsoft.com ([172.30.236.36]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 31 Jan 2001 15:51:29 -0800 Received: from 172.30.236.11 by df-virus1.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 31 Jan 2001 15:52:14 -0800 (Pacific Standard Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Wed, 31 Jan 2001 15:52:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4638.0 content-class: urn:content-classes:message Subject: RE: [midcom] WG scope/deliverables MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 31 Jan 2001 15:52:13 -0800 Message-ID: Thread-Topic: [midcom] WG scope/deliverables Thread-Index: AcCL3a+gDkPAAZLoQ3WBurOegRtzCAAAR1Og From: "Christian Huitema" To: Cc: "J. Noel Chiappa" , "Keith Moore" , "Pyda Srisuresh" , "Ed Gerck" , "Jon Crowcroft" X-OriginalArrivalTime: 31 Jan 2001 23:52:13.0941 (UTC) FILETIME=[D5A10A50:01C08BE0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA17127 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit Well, maybe we should keep the Midcom discussion in Midcom without spamming the whole IETF list... 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 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. 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... -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jan 31 19:48:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29009 for ; Wed, 31 Jan 2001 19:47:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17231; Wed, 31 Jan 2001 19:37:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17196 for ; Wed, 31 Jan 2001 19:37:28 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28874 for ; Wed, 31 Jan 2001 19:37:27 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id TAA17914; Wed, 31 Jan 2001 19:37:19 -0500 (EST) Message-Id: <200102010037.TAA17914@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pyda Srisuresh cc: Keith Moore , midcom@ietf.org Subject: Re: [midcom] WG scope/deliverables In-reply-to: Your message of "Wed, 31 Jan 2001 15:06:23 PST." <20010131230623.17956.qmail@web1405.mail.yahoo.com> Date: Wed, 31 Jan 2001 19:37:19 -0500 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org [ietf@ietf.org list removed from the reply] > > I expressed an opinion that this group should confine itself to addressing > > short-term goals rather than trying to make NATs a part of the Internet > > architecture. > > > > With all due respect, Keith, you are saying that addressing NAT > concerns should not be a short-term goal. You are OK with the WG > addressing firewall concerns however. That was before the group was chartered, in the context of a discussion about what the charter of the group would be (and whether the group should be chartered), and on a different mailing list. At that time, I tried to get the group to investigate solutions that were viable in the long term because I thought that was a better use of the group's energies; and I thought (and still think) that vendors could address this problem well enough and that IETF should not lend its efforts toward promoting an architectural dead end. But now that the group is chartered, I'm not objecting to the group extending NAT - I'm just suggesting that the since group has chosen this particular path it should realize that this work only has use for the near term - so it should do that work as quickly as possible and not get bogged down trying to do more than can reasonably be done with NAT (as RSIP did). > But, insisting on this and repeating the mantra many times over, > even after the WG is formed with a specific mission and chater, > is really disruptive to the work being done in the WG. No. What is disruptive is for people to respond to a message without even bothering to consider what is actually being said, to make knee-jerk reactions to any input that is based on different assumptions or experiences than their world-view, and to personally attack the poster or accuse the poster of malice - all of which compels the poster to at least respond to some of some of those accusations and consume the group's energy and bandwidth defending himself. > Well, I (and perhaps many others) respectfully disagree. > This is not a short-term solution yet, not until folks have > V6 networks deployed. V6 has got a huge headstart on whatever this group will produce. But no matter. Get on with this work, and do whatever good you can, while you still can. > So, if you do agree working that dealing with NATs is a short term solution, > why are you so repeatedly trying to torpedo the effort going in to solve > the short term problems ? I'm not trying to torpedo the effort, I'm trying to salvage it. (actually I never was trying to torpedo it - but I was trying to encourage it to go in more useful directions, and I make no apology for that.) > > IPv6 will be attractive for the same reasons that NAT was attractive - > > it will be the path of least pain to solving a pressing set of problems. > > > > Agreed, perhaps with the exception of address renumbering. Agreed that this is the hardest remaining problem to solve for v6. > > Being over-ambitious about goals has prevented more than one working > > group from accomplishing anything useful, and exhausted lots of > > talented people in the process. I hardly think that advocating a little > > restraint in this group's ambition is sufficient justification for > > personal attacks. > > > > This has been more than just a little advocation of restraint, I might add. Other than responses to the replies from my message, I have posted exactly one message to the midcom list. I will not, repeat, *not* try to keep this group from doing what it is chartered to do. However I do have the right to contribute from time to time to the group's discussion, (keeping my comments within the scope as defined by the charter) because I do have a stake in the outcome, and I do have relevant experience and background. And while I'll try to fashion my comments so that they'll be constructive, I don't make any promises that you'll like what I say. Keith p.s. I suggest that this be the last message in this thread, but I don't claim any right to have the last word. So if folks really feel like they need to respond, please make it brief - or respond to me in private mail. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jan 31 19:53:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29165 for ; Wed, 31 Jan 2001 19:53:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17306; Wed, 31 Jan 2001 19:42:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17272 for ; Wed, 31 Jan 2001 19:42:29 -0500 (EST) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28947 for ; Wed, 31 Jan 2001 19:42:29 -0500 (EST) Received: from fokus.gmd.de (dhcp012 [195.37.78.140]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id BAA03081 for ; Thu, 1 Feb 2001 01:42:29 +0100 (MET) Message-ID: <3A78B100.EBD0DD8F@fokus.gmd.de> Date: Thu, 01 Feb 2001 01:42:40 +0100 From: Jiri Kuthan Organization: GMD Fokus X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 CC: midcom@ietf.org Subject: Re: [midcom] WG scope/deliverables References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I absolutely second what Christian is saying. The requirement to keep midcom simple should appear in the WG documents. Jiri Christian Huitema wrote: > > Well, maybe we should keep the Midcom discussion in Midcom without > spamming the whole IETF list... > > 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 > 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. > > 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... > > -- Christian Huitema > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom -- Jiri Kuthan http://www.fokus.gmd.de/usr/kuthan tel:+49-30-34637271 Internet Telephony: http://www.fokus.gmd.de/glone/projects/ipt _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jan 31 20:12:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29529 for ; Wed, 31 Jan 2001 20:12:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA17629; Wed, 31 Jan 2001 20:01:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA17598 for ; Wed, 31 Jan 2001 20:01:54 -0500 (EST) Received: from snap.CS.Berkeley.EDU (IDENT:root@snap.CS.Berkeley.EDU [128.32.37.81]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29356 for ; Wed, 31 Jan 2001 20:01:53 -0500 (EST) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3-ZUUL) id RAA24692 for midcom@ietf.org; Wed, 31 Jan 2001 17:04:43 -0800 Date: Wed, 31 Jan 2001 17:04:43 -0800 From: John Lazzaro Message-Id: <200102010104.RAA24692@snap.CS.Berkeley.EDU> To: midcom@ietf.org Subject: RE: [midcom] WG scope/deliverables Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > Christian Huitema writes ... > 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. Please, don't forget UDP as well -- I've had success in my own projects using the Activision techniques described in RFC3027 which are aimed as UDP, and it would be nice to see UDP-oriented techniques of this nature be a part of this WG ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jan 31 23:38:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05445 for ; Wed, 31 Jan 2001 23:38:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA19493; Wed, 31 Jan 2001 23:27:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA19462 for ; Wed, 31 Jan 2001 23:26:59 -0500 (EST) Received: from sean.ebone.net (IDENT:postfix@sean.ebone.net [195.158.227.211]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04995 for ; Wed, 31 Jan 2001 23:26:56 -0500 (EST) Received: by sean.ebone.net (Postfix, from userid 1113) id 9322B817; Thu, 1 Feb 2001 05:26:56 +0100 (CET) To: midcom@ietf.org Subject: RE: [midcom] WG scope/deliverables Cc: huitema@exchange.microsoft.com Message-Id: <20010201042656.9322B817@sean.ebone.net> Date: Thu, 1 Feb 2001 05:26:56 +0100 (CET) From: smd@ebone.net (Sean Doran) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org [moved off main ietf list, and Cc list pruned] Christian Huitema writes: | The point being that if you have an arbitrary bunch of firewalls and | NATs between any two points, then you are forced into telephone-like | "call set-up" scenarios, which don't really scale to large groups, | specially when the application consists of sporadic messages to | arbitrary destinations. So the middle box joins a multicast group and forwards on behalf of the things behind it messages to the group, and messages from the group. In the messages the source and set of receivers will have to have some indication of identity of the sender/receiver set. This identity is the "who"; the "where" part is "behind middle box", which is the visible source address in the IP multicast header. Or, if we presuppose an IPv4 multicast scheme that is more single-source-ish, in the sense of groups with one sender and maybe millions of receivers, we can build our own private MBONE among middleboxen and do native multicast on the "outside" of the Internet core, keeping the S,G state hidden from it, by putting unicast tunneling into the middleboxen. There are many other ways to skin the cat of many-host messaging, even with huge groups, infrequent senders, untrustworthy or mangled source topological locators, sub-grouping (i.e., pruning out listeners who don't want or can't use certain messages), a desire for unicast communication triggered by a many-host announcement, and so forth. USENET is an excellent proof of all of this, thanks to the Instant Propagation Party of some years past. You might point to the difficulty of sending to some party that does not know they should be listening for the transmission, and thus have not "tuned-in" to the multicast group (or newsgroup or ...). Tricky, but, arbitrary messages sent to destinations that one might not be able to reach directly, perhaps even because a gateway must be used, was solved for SMTP by using MX RRs. An ALG RR analogous to an MX RR but more general than for "M"ail proxying, is an obvious solution, although I would hope someone smarter could think up a creative approach that revs neither BIND and equivalents nor the contents of the DNS. Sean. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom