From midcom-admin@ietf.org Wed May 2 16:10: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 QAA22004 for ; Wed, 2 May 2001 16:10:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10938; Wed, 2 May 2001 16:05:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10908 for ; Wed, 2 May 2001 16:05:46 -0400 (EDT) Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21874 for ; Wed, 2 May 2001 16:05:43 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f42K5Id07573 for ; Wed, 2 May 2001 13:05:19 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f42K5Cw21414 for ; Wed, 2 May 2001 13:05:12 -0700 (PDT) Received: from spandex (rtp-vpn-147.cisco.com [10.82.192.147]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with SMTP id NAA21362 for ; Wed, 2 May 2001 13:05:09 -0700 (PDT) Message-ID: <028001c0d343$3c41f900$d45904d1@cisco.com> From: "Melinda Shore" To: Date: Wed, 2 May 2001 16:05:28 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_027D_01C0D321.B491A800" 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 Subject: [midcom] Fw: I-D ACTION:draft-carpenter-midtax-01.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 This is a multi-part message in MIME format. ------=_NextPart_000_027D_01C0D321.B491A800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit For those who may not have seen the announcent ... The mailing list has been quiet for the past month or so, so may we assume that those who have read Christian's draft find it both correct and complete? The revised framework and requirements drafts should be available soon, and I hope that interested individuals will read those documents and make their views known on the mailing list. We are scheduled to deliver the documents to the IESG in August, which means that they must survive working group last call by then. I'd especially like to avoid sandbagging our document editors at the August IETF meeting, as has happened at the previous two. If you have serious objections to the contents of either of the documents it's good for us to know that well in advance of the meetings and/or document last call. Melinda ----- Original Message ----- From: To: Sent: Tuesday, May 01, 2001 7:37 AM Subject: I-D ACTION:draft-carpenter-midtax-01.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Middle boxes: taxonomy and issues > Author(s) : B. Carpenter, S. Brim > Filename : draft-carpenter-midtax-01.txt > Pages : 22 > Date : 30-Apr-01 > > This document is intended as part of an IETF discussion about > 'middleboxes' - 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. This document > establishes a catalogue or taxonomy of middleboxes, cites previous > and current IETF work concerning middleboxes, and attempts to > identify some preliminary conclusions. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-carpenter-midtax-01.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-01.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-01.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. > ------=_NextPart_000_027D_01C0D321.B491A800 Content-Type: application/octet-stream; name="ATT00632.dat" Content-Disposition: attachment; filename="ATT00632.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20010430143039.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-carpenter-midtax-01.txt ------=_NextPart_000_027D_01C0D321.B491A800 Content-Type: text/plain; name="draft-carpenter-midtax-01.txt" Content-Disposition: attachment; filename="draft-carpenter-midtax-01.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20010430143039.I-D@ietf.org> ------=_NextPart_000_027D_01C0D321.B491A800-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed May 2 17:17: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 RAA23843 for ; Wed, 2 May 2001 17:17:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13998; Wed, 2 May 2001 17:15:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13970 for ; Wed, 2 May 2001 17:15:57 -0400 (EDT) Received: from linux.aravox.com ([209.46.41.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23794 for ; Wed, 2 May 2001 17:15:55 -0400 (EDT) Received: from sfischer (sfischer.aravox.com [192.168.1.136]) by linux.aravox.com (8.9.3/8.9.3) with SMTP id QAA01947; Wed, 2 May 2001 16:14:47 -0500 Message-ID: <00e701c0d34d$39f872a0$8801a8c0@aravox.com> From: "Stephen Fischer" To: "Melinda Shore" , References: <028001c0d343$3c41f900$d45904d1@cisco.com> Date: Wed, 2 May 2001 16:17:00 -0500 Organization: Aravox Technologies, Inc. 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 Subject: [midcom] HR 1542 bill would prohibit VoIP 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 URGENT: HELP STOP HR 1542! May 2, 2001 - Update - Does HR 1542 Make VoIP Illegal?" April 30, 2001 - The Republican leadership of the U.S. House of Representatives is preparing to push through a bill that caves in to the Bell Companies and opens the door for the FCC to regulate IP voice over data networks. The "Tauzin-Dingell Broadband Bill" incorporates for the first time Internet applications and broadband in the legacy telecom regulatory framework. The bill will make it illegal to offer IP based voice services over the Internet and give the Bells hooks to kill off remaining broadband competitors. The US House of Representatives Telecommunications Subcommitte approved "HR 1542" on Thursday, April 26th. The bill will get voted on by the Commerce Committee and the full House of Representatives soon. The Internet has prospered precisely because applications remained beyond the reach of regulators. The Bell companies have used regulatory means to build monopoly advantage in virtually all areas of telecommunications. The Bells have so far failed to monopolize Internet applications, such as; email, world wide web, VoIP, ecommerce, streaming, peer-to-peer networking, and others as yet unknown. The entire bill starting with its title "Internet Freedom and Broadband Deployment Act" is remarkably disingenuous. The bill ends Internet freedom and removes any hope for broadband deployment. Existing telecom regulations make no mention of the "Internet". Tauzin's bill which takes the form of amending existing regulations specifically uses the word "Internet" 50 times. The Bell companies have served and continue to serve as the dominant obstacle to broadband deployment. The Bells have longstanding efforts to protect their lucrative business selling 1970's T1 technology from competition. Bell efforts to deploy DSL appear only in areas where a competitor exists. Their deployments slow, customer service degrades, and prices rise as soon as they weaken or kill off competition. Provisions of the bill: Incorporates Internet applications in framework established by Telecom Act of 1934 Defines for the first time meaning of term "Internet" Defines for the first time meaning of term "Internet Access" Defines for the first time meaning of broadband "High Speed Data Service" Makes voice applications of Internet illegal Eliminates limitations on Bell entry into long distance data service business Eliminates requirements on Bells to resell broadband related services In other words, it removes all regulatory restraint on the Bell monopolies leaving no prospects for competition. No matter how the Bells might want to spin the story, actions speak clearly that monopolies produce high prices for substandard services. Long distance, wireless, and Internet access services have improved in quality with declining prices only to extent competition existed. The Bell monopoly controlled local service has not improved even given increasing prices since the break up of AT&T in 1984. A year ago we rallied and as an industry and helped stop HR 1291. We can do it again. WE MUST STOP HR 1542! Applications of the Internet should remain unregulated, with no exceptions for voice applications and services. Contact your representative in Congress via the switchboard at 1.202.224.3121 I urge you to call and email your Representative and the House Leadership with the message that HR 1542 is a mistake. The Internet should remain unregulated, without no exceptions for voice applications and services. http://www.house.gov and http://www.house.gov/writerep will help you locate the address of your Representative. Let them know that: "The Internet Freedom and Broadband Deployment Act" does neither! If they open the door to regulating any Internet service, it will set a terrible precedent Using the Internet for voice communications is a good thing and should not be regulated or taxed. Consumers will be hurt and only the old monopoly telephone companies will benefit. Internet voice services are used mostly by low income people for international communications, as a substitute for vastly inflated international long-distance calls. This is a new source of privacy concerns, as companies pry apart traffic streams to determine what's "voice" To learn more about HR 1542, you can get info on status and text of bills at: http://thomas.loc.gov/ Just type HR1542 into search window. Read section 6 (b) k Send jeff@pulver.com a bcc if you'd like and I'll keep you posted. ---------------------------------------------------------------------------- ---- Click here to subscribe to the HR 1542 mailing list _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed May 2 18:07:30 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 SAA24989 for ; Wed, 2 May 2001 18:07:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15833; Wed, 2 May 2001 18:05:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15800 for ; Wed, 2 May 2001 18:05:40 -0400 (EDT) Received: from internet-gateway.zurich.ibm.com (internet-gateway-x.zurich.ibm.com [195.212.119.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24964 for ; Wed, 2 May 2001 18:05:38 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.2.193]) by internet-gateway.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id AAA59076 for ; Thu, 3 May 2001 00:05:10 +0200 Received: from gsine06.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA44498 from ; Thu, 3 May 2001 00:05:08 +0200 Message-Id: <3AF082E8.215B28CF@hursley.ibm.com> Date: Wed, 02 May 2001 16:58:00 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: midcom@ietf.org Subject: Re: [midcom] HR 1542 bill would prohibit VoIP References: <028001c0d343$3c41f900$d45904d1@cisco.com> <00e701c0d34d$39f872a0$8801a8c0@aravox.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 Actually, it only prohibits Bell Operating Companies from evading the current restrictions on them by use of VoIP. And I don't see what it has to do with this WG. Brian Stephen Fischer wrote: > > URGENT: HELP STOP HR 1542! > May 2, 2001 - Update - Does HR 1542 Make VoIP Illegal?" > > April 30, 2001 - The Republican leadership of the U.S. House of > Representatives is preparing to push through a bill that caves in to the > Bell Companies and opens the door for the FCC to regulate IP voice over data > networks. > > The "Tauzin-Dingell Broadband Bill" incorporates for the first time Internet > applications and broadband in the legacy telecom regulatory framework. The > bill will make it illegal to offer IP based voice services over the Internet > and give the Bells hooks to kill off remaining broadband competitors. > > The US House of Representatives Telecommunications Subcommitte approved "HR > 1542" on Thursday, April 26th. The bill will get voted on by the Commerce > Committee and the full House of Representatives soon. > > The Internet has prospered precisely because applications remained beyond > the reach of regulators. The Bell companies have used regulatory means to > build monopoly advantage in virtually all areas of telecommunications. The > Bells have so far failed to monopolize Internet applications, such as; > email, world wide web, VoIP, ecommerce, streaming, peer-to-peer networking, > and others as yet unknown. > > The entire bill starting with its title "Internet Freedom and Broadband > Deployment Act" is remarkably disingenuous. The bill ends Internet freedom > and removes any hope for broadband deployment. Existing telecom regulations > make no mention of the "Internet". Tauzin's bill which takes the form of > amending existing regulations specifically uses the word "Internet" 50 > times. The Bell companies have served and continue to serve as the dominant > obstacle to broadband deployment. The Bells have longstanding efforts to > protect their lucrative business selling 1970's T1 technology from > competition. Bell efforts to deploy DSL appear only in areas where a > competitor exists. Their deployments slow, customer service degrades, and > prices rise as soon as they weaken or kill off competition. > > Provisions of the bill: > > Incorporates Internet applications in framework established by Telecom Act > of 1934 > Defines for the first time meaning of term "Internet" > Defines for the first time meaning of term "Internet Access" > Defines for the first time meaning of broadband "High Speed Data > Service" > Makes voice applications of Internet illegal > Eliminates limitations on Bell entry into long distance data service > business > Eliminates requirements on Bells to resell broadband related services > In other words, it removes all regulatory restraint on the Bell monopolies > leaving no prospects for competition. No matter how the Bells might want to > spin the story, actions speak clearly that monopolies produce high prices > for substandard services. Long distance, wireless, and Internet access > services have improved in quality with declining prices only to extent > competition existed. The Bell monopoly controlled local service has not > improved even given increasing prices since the break up of AT&T in 1984. > A year ago we rallied and as an industry and helped stop HR 1291. We can do > it again. WE MUST STOP HR 1542! > > Applications of the Internet should remain unregulated, with no exceptions > for voice applications and services. > > Contact your representative in Congress via the switchboard at > 1.202.224.3121 > > I urge you to call and email your Representative and the House Leadership > with the message that HR 1542 is a mistake. The Internet should remain > unregulated, without no exceptions for voice applications and services. > http://www.house.gov and http://www.house.gov/writerep will help you locate > the address of your Representative. > > Let them know that: "The Internet Freedom and Broadband Deployment Act" does > neither! > > If they open the door to regulating any Internet service, it will set a > terrible precedent > Using the Internet for voice communications is a good thing and should not > be regulated or taxed. Consumers will be hurt and only the old monopoly > telephone companies will benefit. > Internet voice services are used mostly by low income people for > international communications, as a substitute for vastly inflated > international long-distance calls. > This is a new source of privacy concerns, as companies pry apart traffic > streams to determine what's "voice" > To learn more about HR 1542, you can get info on status and text of bills > at: > > http://thomas.loc.gov/ Just type HR1542 into search window. Read section 6 > (b) k > > Send jeff@pulver.com a bcc if you'd like and I'll keep you posted. > > ---------------------------------------------------------------------------- > ---- > Click here to subscribe to the HR 1542 mailing list > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu May 3 12:23: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 MAA29089 for ; Thu, 3 May 2001 12:23:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14340; Thu, 3 May 2001 12:20:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14309 for ; Thu, 3 May 2001 12:20:51 -0400 (EDT) Received: from df-inet1.exchange.microsoft.com ([131.107.8.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28986 for ; Thu, 3 May 2001 12:20:48 -0400 (EDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Thu, 3 May 2001 09:21:03 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 03 May 2001 09:20:13 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 3 May 2001 09:20:13 -0700 content-class: urn:content-classes:message Subject: RE: [midcom] Fw: I-D ACTION:draft-carpenter-midtax-01.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 3 May 2001 09:20:12 -0700 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.4703.0 Thread-Topic: [midcom] Fw: I-D ACTION:draft-carpenter-midtax-01.txt Thread-Index: AcDTRZYbO2rGfUXARcm2VOlKimdFYQApvsiQ From: "Christian Huitema" To: "Melinda Shore" , X-OriginalArrivalTime: 03 May 2001 16:20:13.0460 (UTC) FILETIME=[EE910D40:01C0D3EC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA14310 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 There was an interesting discussion on the SIP mailing list yesterday, and it impacts on our work. Basically, implementers are warning us of many cases in which a "media call" use "asymmetric RTP." That is, the address and port from which a host sends packets are not necessarily the same as the address and port at which the host expects to receive packets. I am preparing a revision of the scenario document to document that. -- Christian Huitema > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Wednesday, May 02, 2001 1:05 PM > To: midcom@ietf.org > Subject: [midcom] Fw: I-D ACTION:draft-carpenter-midtax-01.txt > > For those who may not have seen the announcent ... > > The mailing list has been quiet for the past month or so, > so may we assume that those who have read Christian's > draft find it both correct and complete? The revised > framework and requirements drafts should be available soon, > and I hope that interested individuals will read those > documents and make their views known on the mailing list. > We are scheduled to deliver the documents to the IESG in > August, which means that they must survive working group > last call by then. I'd especially like to avoid sandbagging our > document editors at the August IETF meeting, as has happened > at the previous two. If you have serious objections to > the contents of either of the documents it's good for us > to know that well in advance of the meetings and/or document > last call. > > Melinda > > ----- Original Message ----- > From: > To: > Sent: Tuesday, May 01, 2001 7:37 AM > Subject: I-D ACTION:draft-carpenter-midtax-01.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Middle boxes: taxonomy and issues > > Author(s) : B. Carpenter, S. Brim > > Filename : draft-carpenter-midtax-01.txt > > Pages : 22 > > Date : 30-Apr-01 > > > > This document is intended as part of an IETF discussion about > > 'middleboxes' - 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. This document > > establishes a catalogue or taxonomy of middleboxes, cites previous > > and current IETF work concerning middleboxes, and attempts to > > identify some preliminary conclusions. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-carpenter-midtax-01.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-01.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-01.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. > > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu May 3 12:45: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 MAA29847 for ; Thu, 3 May 2001 12:45:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14989; Thu, 3 May 2001 12:43:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14961 for ; Thu, 3 May 2001 12:43:34 -0400 (EDT) Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29803 for ; Thu, 3 May 2001 12:43:32 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f43Gh8d18452; Thu, 3 May 2001 09:43:08 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f43Gh1D07776; Thu, 3 May 2001 09:43:01 -0700 (PDT) Received: from spandex (rtp-vpn-100.cisco.com [10.82.192.100]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with SMTP id JAA01535; Thu, 3 May 2001 09:42:59 -0700 (PDT) Message-ID: <02c701c0d3f0$28bf2080$d45904d1@cisco.com> From: "Melinda Shore" To: "Christian Huitema" , References: Subject: Re: [midcom] Fw: I-D ACTION:draft-carpenter-midtax-01.txt Date: Thu, 3 May 2001 12:43:15 -0400 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 >There was an interesting discussion on the SIP mailing list yesterday, >and it impacts on our work. Basically, implementers are warning us of >many cases in which a "media call" use "asymmetric RTP." This is usually the case with H.323 (NetMeeting varies from common practice in this regard, however). Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon May 7 06:51: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 GAA05826 for ; Mon, 7 May 2001 06:51:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21026; Mon, 7 May 2001 06:46:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20998 for ; Mon, 7 May 2001 06:46:52 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05538; Mon, 7 May 2001 06:46:51 -0400 (EDT) Message-Id: <200105071046.GAA05538@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 07 May 2001 06:46:51 -0400 Subject: [midcom] I-D ACTION:draft-ietf-midcom-scenarios-01.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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : MIDCOM Scenarios Author(s) : C. Huitema Filename : draft-ietf-midcom-scenarios-01.txt Pages : 16 Date : 04-May-01 As trusted third parties are increasingly being asked to make policy decisions on behalf of the various entities participating in an application's operation, a need has developed for applications to be able to communicate their needs to the devices in the network that provide transport policy enforcement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-scenarios-01.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-ietf-midcom-scenarios-01.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-ietf-midcom-scenarios-01.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010504122307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-scenarios-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-scenarios-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010504122307.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed May 9 18:13: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 SAA27098 for ; Wed, 9 May 2001 18:13:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00436; Wed, 9 May 2001 18:09:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00407 for ; Wed, 9 May 2001 18:09:57 -0400 (EDT) Received: from pavilion ([24.31.80.230]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26979 for ; Wed, 9 May 2001 18:09:50 -0400 (EDT) Message-ID: <2282420015392214920@pavilion> X-EM-Version: 5, 0, 0, 19 X-EM-Registration: #01B0530810E603002D00 X-Priority: 3 X-MSMail-Priority: Normal From: "Mitchell" To: midcom@ietf.org Date: Wed, 9 May 2001 12:01:49 -1000 MIME-Version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA00408 Subject: [midcom] Business/Employment Opportunity 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 Dear Friend: "Making over half million dollars every 4 to 5 months from your home for an investment of only $25 U.S. Dollars expense one time" THANKS TO THE COMPUTER AGE AND THE INTERNET! =============================================== BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR !! Before you say "Bull" , please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the internet, a national weekly news program recently devoted an entire show to the investigation of this program described below , to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are "absolutely no laws prohibiting the participation in the program and if people can follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost". DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one had to say: "Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received total $ 610,470.00 in 21 weeks, with money still coming in". Pam Hedland, Fort Lee, New Jersey. ------------------------------------------------------------------------- Here is another testimonial: "This program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed thesimple instructions and walaa ..... 3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program,I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything ." More testimonials later but first, ****** PRINT THIS NOW FOR YOUR FUTURE REFERENCE ******* $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following...THEN READ IT AGAIN and AGAIN !!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: **** Order all 5 reports shown on the list below. **** For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. **** When you place your order, make sure you order each of the 5 reports. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00. **** Within a few days you will receive, via e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happen to your computer. ****.IMPORTANT - DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in steps 1 through6 or you will loose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work!!! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!! 1.. After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT # 5. This person has made it through the cycle and is no doubt counting their fortune. 2.... Move the name & address in REPORT # 4 down TO REPORT # 5. 3.... Move the name & address in REPORT # 3 down TO REPORT # 4. 4.... Move the name & address in REPORT # 2 down TO REPORT # 3. 5.... Move the name & address in REPORT # 1 down TO REPORT # 2 6.... Insert YOUR name & address in the REPORT # 1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY ! ========================================================= Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if you loose any data. To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally, where to find thousands of free classified ads and much more. There are 2 Primary methods to get this venture going: METHOD # 1 : BY SENDING BULK E-MAIL LEGALLY ============================================ let's say that you decide to start small, just to see how it goes, and we will assume You and those involved send out only 5,000 e-mails each. Let's also assume that the mailing receive only a0.2% response (the response could be much better but lets just say it is only 0.2% . Also many people will send out hundreds of thousands e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that is only 10 orders for report # 1. Those 10 people responded by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's = 100 people responded and ordered Report # 2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for Report # 3. Those 1000 people send out 5,000 e-mails each for a total of 5 million e-mails sent out. The 0.2% response to that is 10,000 orders for Report # 4. Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report # 5. THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half million). Your total income in this example is: 1..... $50 + 2..... $500 + 3..... $5,000 + 4..... $50,000 + 5..... $500,000 ......... Grand Total = $555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY ! ------------------------------------------------------------------------------ REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone, or half or even one 4th of those people mailed 100,000 e-mails each or more? There are over 250 million people on the internet worldwide and counting. Believe me, many people will do just that, and more! METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET =================================================== Advertising on the net is very very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free adson the internet will easily get a larger response. We strongly suggest you start with Method # 1 and add METHOD # 2 as you go along. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it . Always provide same day service on all orders. This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they can not advertise until they receive the report. _____________________ AVAILABLE REPORTS_____________________ ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those sheets of paper, Write the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and your name and postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW : ============================================== REPORT #1, "The Insider's Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #1 FROM: G. Donaldson P.O. Box 25884 Honolulu, Hawaii 96825-0884 don't forget to provide a permanent e-mail address in clear writing (better typed) to receive the reports. We had problems in delivery e-mails before!!! ============================================== REPORT #2 "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #2 FROM: Vijay Paul C-291, Second Floor Defence Colony New Delhi - 110024 INDIA ============================================== REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: JD P.O.Box 1114 Des Plaines, IL 60017 USA ============================================== REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: J Santi 833 Walter Ave Des Plaines, IL 60016 USA ============================================== REPORT #5 "How to SEND 1,000,000 e-mails for FREE" ORDER REPORT #5 FROM: Elaine Rix 138 Dundas Street, West, #243 Toronto, Ontario Canada M5G 1C3 ============================================== There are currently more than 250,000,000 people online worldwide! $$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$ Follow these guidelines to guarantee your success: If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do. After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT # 2. If you did not, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for Report # 2, YOU CAN RELAX, because the system is already working for you , and the cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER : Every time your name is moved down on the list, you are placed in front of a different report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business !!! ____________________________________________________ FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved others to #2...........# 5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on everyone of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW ! ************** MORE TESTIMONIALS **************** "My name is Mitchell. My wife , Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Jody about receiving ''junk mail''. I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old ''I told you so'' on her when the thing didn'twork. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received a total of $ 147,200.00 all cash! I was shocked. I have joined Jody in her ''hobby''." Mitchell Wolf, Chicago, Illinois ------------------------------------------------------------ "Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back. I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00 in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big." Dan Sondstrom, Alberta, Canada ----------------------------------------------------------- "I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else.........11 months passed then it luckily came again...... I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks". Susan De Suza, New York, N.Y. ---------------------------------------------------- "It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $ 20,560.00 and by the end of third month my total cash count was $ 362,840.00. Life is beautiful, Thanx to internet". Fred Dellaca, Westport, New Zealand ------------------------------------------------------------ ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM ! ======================================================= If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D.C. Under Bill s.1618 TITLE III passed by the 105th US Congress this letter cannot be considered spam as long as the sender includes contact information and a method of removal. This is one time e-mail transmission. No request for removal is necessary. ------------------------------------------------------------ This message is sent in compliance of the new email Bill HR 1910. Under Bill HR 1910 passed by the 106th US Congress on May 24, 1999, this message cannot be considered Spam as long as we include the way to be removed. Per Section HR 1910, Please type "REMOVE" in the subject line and reply to this email. All removal requests are handled personally an immediately once received. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed May 9 20:59:57 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 UAA00230 for ; Wed, 9 May 2001 20:59:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03088; Wed, 9 May 2001 20:58:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03057 for ; Wed, 9 May 2001 20:58:46 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00216 for ; Wed, 9 May 2001 20:58:43 -0400 (EDT) Received: from blv-av-01.boeing.com ([192.54.3.60]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id RAA21209 for ; Wed, 9 May 2001 17:58:45 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id RAA04581 for ; Wed, 9 May 2001 17:58:45 -0700 (PDT) Received: from xch-pssbh-03.nw.nos.boeing.com by blv-hub-01.boeing.com with ESMTP; Wed, 9 May 2001 17:58:37 -0700 Received: by xch-pssbh-03.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 May 2001 17:58:36 -0700 Message-Id: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12CB6@XCH-NW-01.nw.nos.boeing.com> From: "Fleischman, Eric W" To: "'midcom@ietf.org'" , "'huitema@exchange.microsoft.com'" Date: Wed, 9 May 2001 17:58:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [midcom] Comments on draft-ietf-midcom-scenarios-01.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 I thank Christian Huitema for this excellent internet-draft document. Although I have only read the first five pages with care, having only glanced through the rest of the document at this time, I nevertheless have a few comments that I would like to share with you based upon this early (semi-)reading. I like Christian's approach of describing distinct configuration scenarios which the midcom protocol will need to support. I believe that this is an excellent basis for stating these requirements and that Christian has provided us with an excellent text to base our discussions upon. However, I find the granularity of this current discussion to be very troubling, missing important sets of requirements that need to be captured up front. -------------------------- Issue 1: Confusion of Scenarios with Policy The current text appears to imply that the first generic scenario (TCP Server behind a firewall/NAT), described in Section 2.1, will open a semi-permanent hole through the middle box to a specific "Internal Host", while the second generic scenario (Peer-to-Peer communication with ad-hoc rendezvous) produces an "authorization [that] is typically valid for only a single TCP connection" (see penultimate paragraph in section 2.2). I firmly state that any such implication is unacceptable. I rather state that the configuration scenarios are independent from local policy issues. Specifically, it is a local policy decision whether the first approach can open "semi-permanent holes" and the second approach a transitory hole (i.e., "valid only a single TCP connection") or vice-versa. The requirements need to recognize that the midcom protocol has two orthogonal requirements it must fulfill: it must satisfy the needs of communication protocols to operate as described by Christian's scenarios and it also must cooperate with and support local policies. These two functions are distinct from each other and must not be confused. Specifically, I can not imagine (though I may be mistaken) the administrators of my company's firewalls deploying a product which, based upon the protocol exchange described in section 2.1 [even with explicit authentication checks (which weren't mentioned, BTW)], will permit the Internal Host to open any unconstrained hole through our firewall to itself. Rather, we will require the ability to restrict the nature of that hole based upon local policy. Simultaneously, we would be very interested in knowing just how big a hole that application wants, since it is more aware than we are about the needs it is trying to satisfy. Policy is therefore not (always) a binary thing, and some policy negotiation capabilities need to be built into the midcom protocol. It is therefore very desirable, but not required, that the Internal Host, in such a scenario, provide input as to the nature of the hole they are requesting. This input can specify the range of remote source addresses which can be permitted to go through that hole as well as the duration during which that hole will be maintained. It should also optionally state how many simultaneous sessions can be supported by this request. The protocol should also address the possibility that corporate policy will restrict the hole to be smaller than what the requesting agent requested, and the nature of that restriction should be conveyable back to the requesting party, since any policy enforcement point has "the final word" on such matters. This ability to restrict the hole to a "range of addresses" is a very important matter and should not be deprecated. It reflects the fact that (increasingly) the interactions between corporations is partially a function of whether their respective policies collide or synergize together. This is a very big topic that I would prefer to not get into now, but I will point out that any company having ITAR restrictions upon itself must be very aware of the nature of its interactions with other corporations, to ensure that their cumulative policies do not violate this mandate of the US Government. It is difficult to imagine creating a viable collaborate infrastructure in the aerospace industry without addressing such concerns. ------------------------------------ Issue 2: Middleboxes are PEPs Middleboxes function as Policy Enforcement Points. As such, it wouldn't hurt matters to explicitly mention that the firewall/NAT may need to use COPS to query a Policy Server (PDP) concerning what response it should give to the Internal Host's request that it open a hole through itself. I recognize that this is a implementation detail, but I am concerned that a failure to capture this possibility may also mean that we fail to acknowledge the other parts of the system that need to be considered to create a viable standard. --------------------------------------- Issue 3: Authentication and Access Control are Big Issues I am concerned with the lack of emphasis given to the importance of the midcom protocol to satisfy rigorous authentication and access control requirements. I readily admit that access control (i.e., authorization) -- and how it is done -- is probably a "local implementation issue". However, authentication isn't, and it needs to be explicitly addressed. Specifically, the penultimate paragraph of Section 2.1 states: "It is quite clear that the interaction between the internal host and the firewall/NAT described in the first step of the scenario may require some form of access control." This text assumes that access control is a function of this scenario, but not of the preceding one. This is wrong. Authentication is potentially needed for ALL of the scenarios -- every one of them. Thus, this idea is incorrectly positioned within the paper. It should rather be noted up front within this document that a firm requirement of the Midcom Protocol is that it must optionally provide authentication between the Middlebox and the requester. I don't know whether two-way authentication is required or not, but I will assert that the Middlebox had better be able to authenticate the requester if it is going to be deployed upon our machines. --------------------------------------- Issue 4: Section 2.2.2 I would rather state that the issue of both peers being behind firewalls should preferentially be treated by considering mechanisms by which the external IP address, negotiated by the Internal host with the firewall, can be communicated to its remote peer, and vice-versa. This can be done via "out of band" signaling (e.g., Email exchange) or SDP-based approaches. Alternatively, it could be handled by both systems publishing their IP addresses to name services. However it is done, the configuration should not dictate policy as the current text implies when it says "Allow the internal host to accept TCP connections from any external address." Thank you for your attention to this posting. --Eric Fleischman _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed May 9 21:58:22 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 VAA01864 for ; Wed, 9 May 2001 21:58:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA03833; Wed, 9 May 2001 21:57:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA03766 for ; Wed, 9 May 2001 21:57:09 -0400 (EDT) Received: from mail4.microsoft.com ([131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01844 for ; Wed, 9 May 2001 21:57:05 -0400 (EDT) Received: from 157.54.9.108 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 09 May 2001 18:47:44 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Wed, 9 May 2001 18:47:45 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Wed, 9 May 2001 18:47:38 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 9 May 2001 18:47:14 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.4688.0 Date: Wed, 9 May 2001 18:47:14 -0700 Message-ID: Thread-Topic: Comments on draft-ietf-midcom-scenarios-01.txt Thread-Index: AcDY7IWC5njn7RtaSOK220lsL+5hfAABVFVw From: "Christian Huitema" To: "Fleischman, Eric W" , X-OriginalArrivalTime: 10 May 2001 01:47:14.0672 (UTC) FILETIME=[23448700:01C0D8F3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id VAA03767 Subject: [midcom] RE: Comments on draft-ietf-midcom-scenarios-01.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: 8bit Eric, Thanks for your comments. The absence of any mention of security requirements in the scenario was quite deliberate. The idea was to explain the nature of the holes that would have to be opened for the applications to work, so as to derive what I would call the "functional requirements" of the protocol. It is quite clear that we also have other requirements, notably security requirements. In the scenarios, I described what the application needs in order to run; whether the application is actually allowed to run or not is a matter of local policy. In order to meet the functional requirements, the midcom protocol will have to enable the scenarios that I described. In order to meet the security requirements, the midcom protocol will have to provide adequate controls. I have my own understanding of these controls: I believe that the protocol should be able to express who is asking the query (authentication) as well as what the query is intended to achieve, e.g. what application, for which user, using what amount of resource. In addition, we also have operational requirements, e.g. support stable operation even if some of the systems involved crash; enable multi-homing; etc. I would expect that functional, security and operational requirements will be written down in the "requirements" draft. Now, if we are waiting too long for that draft, I could indeed increment the scenario draft with a listing of these requirements... -- Christian Huitema > -----Original Message----- > From: Fleischman, Eric W [mailto:Eric.Fleischman@PSS.Boeing.com] > Sent: Wednesday, May 09, 2001 5:58 PM > To: 'midcom@ietf.org'; Christian Huitema > Subject: Comments on draft-ietf-midcom-scenarios-01.txt > > I thank Christian Huitema for this excellent internet-draft document. > Although I have only read the first five pages with care, having only > glanced through the rest of the document at this time, I nevertheless have > a few comments that I would like to share with you based upon this early > (semi-)reading. > > I like Christian's approach of describing distinct configuration scenarios > which the midcom protocol will need to support. I believe that this is an > excellent basis for stating these requirements and that Christian has > provided us with an excellent text to base our discussions upon. However, > I find the granularity of this current discussion to be very troubling, > missing important sets of requirements that need to be captured up front. > > -------------------------- > Issue 1: Confusion of Scenarios with Policy > The current text appears to imply that the first generic scenario (TCP > Server behind a firewall/NAT), described in Section 2.1, will open a semi- > permanent hole through the middle box to a specific "Internal Host", while > the second generic scenario (Peer-to-Peer communication with ad-hoc > rendezvous) produces an "authorization [that] is typically valid for only > a single TCP connection" (see penultimate paragraph in section 2.2). I > firmly state that any such implication is unacceptable. > > I rather state that the configuration scenarios are independent from local > policy issues. Specifically, it is a local policy decision whether the > first approach can open "semi-permanent holes" and the second approach a > transitory hole (i.e., "valid only a single TCP connection") or vice- > versa. The requirements need to recognize that the midcom protocol has two > orthogonal requirements it must fulfill: it must satisfy the needs of > communication protocols to operate as described by Christian's scenarios > and it also must cooperate with and support local policies. These two > functions are distinct from each other and must not be confused. > > Specifically, I can not imagine (though I may be mistaken) the > administrators of my company's firewalls deploying a product which, based > upon the protocol exchange described in section 2.1 [even with explicit > authentication checks (which weren't mentioned, BTW)], will permit the > Internal Host to open any unconstrained hole through our firewall to > itself. Rather, we will require the ability to restrict the nature of that > hole based upon local policy. Simultaneously, we would be very interested > in knowing just how big a hole that application wants, since it is more > aware than we are about the needs it is trying to satisfy. Policy is > therefore not (always) a binary thing, and some policy negotiation > capabilities need to be built into the midcom protocol. > > It is therefore very desirable, but not required, that the Internal Host, > in such a scenario, provide input as to the nature of the hole they are > requesting. This input can specify the range of remote source addresses > which can be permitted to go through that hole as well as the duration > during which that hole will be maintained. It should also optionally state > how many simultaneous sessions can be supported by this request. > > The protocol should also address the possibility that corporate policy > will restrict the hole to be smaller than what the requesting agent > requested, and the nature of that restriction should be conveyable back to > the requesting party, since any policy enforcement point has "the final > word" on such matters. > > This ability to restrict the hole to a "range of addresses" is a very > important matter and should not be deprecated. It reflects the fact that > (increasingly) the interactions between corporations is partially a > function of whether their respective policies collide or synergize > together. This is a very big topic that I would prefer to not get into > now, but I will point out that any company having ITAR restrictions upon > itself must be very aware of the nature of its interactions with other > corporations, to ensure that their cumulative policies do not violate this > mandate of the US Government. It is difficult to imagine creating a viable > collaborate infrastructure in the aerospace industry without addressing > such concerns. > > ------------------------------------ > Issue 2: Middleboxes are PEPs > Middleboxes function as Policy Enforcement Points. As such, it wouldn't > hurt matters to explicitly mention that the firewall/NAT may need to use > COPS to query a Policy Server (PDP) concerning what response it should > give to the Internal Host's request that it open a hole through itself. I > recognize that this is a implementation detail, but I am concerned that a > failure to capture this possibility may also mean that we fail to > acknowledge the other parts of the system that need to be considered to > create a viable standard. > > --------------------------------------- > Issue 3: Authentication and Access Control are Big Issues > I am concerned with the lack of emphasis given to the importance of the > midcom protocol to satisfy rigorous authentication and access control > requirements. I readily admit that access control (i.e., authorization) -- > and how it is done -- is probably a "local implementation issue". However, > authentication isn't, and it needs to be explicitly addressed. > > Specifically, the penultimate paragraph of Section 2.1 states: "It is > quite clear that the interaction between the internal host and the > firewall/NAT described in the first step of the scenario may require some > form of access control." This text assumes that access control is a > function of this scenario, but not of the preceding one. This is wrong. > Authentication is potentially needed for ALL of the scenarios -- every one > of them. Thus, this idea is incorrectly positioned within the paper. It > should rather be noted up front within this document that a firm > requirement of the Midcom Protocol is that it must optionally provide > authentication between the Middlebox and the requester. I don't know > whether two-way authentication is required or not, but I will assert that > the Middlebox had better be able to authenticate the requester if it is > going to be deployed upon our machines. > > --------------------------------------- > Issue 4: Section 2.2.2 > I would rather state that the issue of both peers being behind firewalls > should preferentially be treated by considering mechanisms by which the > external IP address, negotiated by the Internal host with the firewall, > can be communicated to its remote peer, and vice-versa. This can be done > via "out of band" signaling (e.g., Email exchange) or SDP-based > approaches. Alternatively, it could be handled by both systems publishing > their IP addresses to name services. However it is done, the configuration > should not dictate policy as the current text implies when it says "Allow > the internal host to accept TCP connections from any external address." > > Thank you for your attention to this posting. > > --Eric Fleischman _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu May 10 08:40:19 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 IAA24251 for ; Thu, 10 May 2001 08:40:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19170; Thu, 10 May 2001 08:35:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19139 for ; Thu, 10 May 2001 08:35:34 -0400 (EDT) Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA24153 for ; Thu, 10 May 2001 08:35:29 -0400 (EDT) Received: from spandex (rtp-vpn-254.cisco.com [10.82.192.254]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with SMTP id f4ACUeU10237; Thu, 10 May 2001 05:30:40 -0700 (PDT) Message-ID: <016701c0d94d$1249a7a0$d45904d1@cisco.com> From: "Melinda Shore" To: "Fleischman, Eric W" , , References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12CB6@XCH-NW-01.nw.nos.boeing.com> Subject: Re: [midcom] Comments on draft-ietf-midcom-scenarios-01.txt Date: Thu, 10 May 2001 08:30:57 -0400 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 [Please wrap long lines - not everybody uses GUI-based readers. It's sufficiently annoying to reformat that I'm not going to quote your text.] Thanks for your comments. A couple of things: 1) this is not a requirements document, but rather a description of use scenarios from which requirements and architecture can be further developed. I think that we do need to pay more attention to the second leg of our architecture (the nature of the interface between middlebox and policy server), but I don't see Christian's document as obscuring that interface. Incidentally, we won't get a document approved that doesn't allow the middlebox to reject requests, whether it's because policy forbids the action being requested or because resources aren't available or because the middlebox simply has no idea what you're talking about. The security stuff continues to be a problem in midcom, and thank you for bringing that out. I'm not sure your concerns apply to this document, which is illustrative rather than definitive, but perhaps it would be useful to include an example where authentication is a gating operation. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu May 10 09:32:52 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 JAA26122 for ; Thu, 10 May 2001 09:32:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19801; Thu, 10 May 2001 09:20:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19769 for ; Thu, 10 May 2001 09:20:47 -0400 (EDT) Received: from linux.aravox.com ([209.46.41.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25596 for ; Thu, 10 May 2001 09:20:35 -0400 (EDT) Received: from sfischer (sfischer.aravox.com [192.168.1.136]) by linux.aravox.com (8.9.3/8.9.3) with SMTP id IAA27080; Thu, 10 May 2001 08:19:33 -0500 Message-ID: <023f01c0d953$b04ca5a0$8801a8c0@aravox.com> From: "Stephen Fischer" To: "Mitchell" , References: <2282420015392214920@pavilion> Subject: Re: [midcom] Business/Employment Opportunity Date: Thu, 10 May 2001 08:18:22 -0500 Organization: Aravox Technologies, Inc. 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 Mitchell- Despite your reference to two bills at the bottom, this really is Spam. This mailing list is completely inappropriate for this kind of mail. Please remove this list from future mailings! ----- Original Message ----- From: Mitchell To: Sent: Wednesday, May 09, 2001 5:01 PM Subject: [midcom] Business/Employment Opportunity > Dear Friend: > > "Making over half million dollars every 4 to 5 months from your > home for an investment of only $25 U.S. Dollars expense one > time" > > THANKS TO THE COMPUTER AGE AND THE INTERNET! > =============================================== > > BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR !! > > Before you say "Bull" , please read the following. This is the > letter you have been hearing about on the news lately. Due to the > popularity of this letter on the internet, a national weekly news > program recently devoted an entire show to the investigation of > this program described below , to see if it really can make people > money. > > The show also investigated whether or not the program was legal. > Their findings proved once and for all that there are "absolutely > no laws prohibiting the participation in the program and if people > can follow the simple instructions, they are bound to make > some mega bucks with only $25 out of pocket cost". > > DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT > THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING > BETTER THAN EVER. > > This is what one had to say: > > "Thanks to this profitable opportunity. I was approached > many times before but each time I passed on it. I am so glad > I finally joined just to see what one could expect in return > for the minimal effort and money required. To my astonishment, I > received total $ 610,470.00 in 21 weeks, with money still > coming in". > Pam Hedland, Fort Lee, New Jersey. > > ------------------------------------------------------------------------- > > Here is another testimonial: > > "This program has been around for a long time but I never > believed in it. But one day when I received this again in > the mail I decided to gamble my $25 on it. I followed thesimple instructions and walaa ..... 3 weeks later the money > started to come in. First month I only made $240.00 but > the next 2 months after that I made a total of $290,000.00. > So far, in the past 8 months by re-entering the program,I > have made over $710,000.00 and I am playing it again. > The key to success in this program is to follow the simple > steps and NOT change anything ." > > More testimonials later but first, > > ****** PRINT THIS NOW FOR YOUR FUTURE REFERENCE ******* > > $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ > If you would like to make at least $500,000 every 4 to 5 months > easily and comfortably, please read the following...THEN READ > IT AGAIN and AGAIN !!! > $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ > > FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR > FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! > > INSTRUCTIONS: > > **** Order all 5 reports shown on the list below. > > **** For each report, send $5 CASH, THE NAME & NUMBER OF THE > REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS > to the person whose name appears ON THAT LIST next to the report. > MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE > TOP LEFT CORNER in case of any mail problems. > > **** When you place your order, make sure you order each of the 5 > reports. You will need all 5 reports so that you can save them on your > computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00. > > **** Within a few days you will receive, via e-mail, each of the 5 > reports from these 5 different individuals. Save them on your computer > so they will be accessible for you to send to the 1,000's of people > who will order them from you. Also make a floppy of these > reports and keep it on your desk in case something happen to your > computer. > > ****.IMPORTANT - DO NOT alter the names of the people who are > listed next to each report, or their sequence on the list, in > any way other than what is instructed below in steps 1 through6 or you will loose out on majority of your profits. Once you > understand the way this works, you will also see how it does not work if you > change it. > > Remember, this method has been tested, and if you alter, it > will NOT work!!! People have tried to put their friends/relatives names > on all five thinking they could get all the money. But it does not work this > way. Believe us, we all have tried to be greedy and then nothing happened. > So Do Not try to change anything other than what is instructed. Because if > you do, it will not work for you. Remember, honesty reaps the reward!!! > > 1.. After you have ordered all 5 reports, take this advertisement > and REMOVE the name & address of the person in REPORT # 5. This > person has made it through the cycle and is no doubt counting > their fortune. > > 2.... Move the name & address in REPORT # 4 down TO REPORT # 5. > > 3.... Move the name & address in REPORT # 3 down TO REPORT # 4. > > 4.... Move the name & address in REPORT # 2 down TO REPORT # 3. > > 5.... Move the name & address in REPORT # 1 down TO REPORT # 2 > > 6.... Insert YOUR name & address in the REPORT # 1 Position. > > PLEASE MAKE SURE you copy every name & address ACCURATELY ! > ========================================================= > > Take this entire letter, with the modified list of names, and save > it on your computer. DO NOT MAKE ANY OTHER CHANGES. > Save this on a disk as well just in case if you loose any data. > > To assist you with marketing your business on the internet, the > 5 reports you purchase will provide you with invaluable > marketing information which includes how to send bulk e-mails legally, > where to find thousands of free classified ads and much more. > > There are 2 Primary methods to get this venture going: > > METHOD # 1 : BY SENDING BULK E-MAIL LEGALLY > ============================================ > let's say that you decide to start small, just to see how it > goes, and we will assume You and those involved send out only > 5,000 e-mails each. Let's also assume that the mailing receive only a0.2% response (the response could be much better but lets just > say it is only 0.2% . Also many people will send out hundreds of > thousands e-mails instead of only 5,000 each). > > Continuing with this example, you send out only 5,000 e-mails. > With a 0.2% response, that is only 10 orders for report # 1. > Those 10 people responded by sending out 5,000 e-mail > each for a total of 50,000. Out of those 50,000 e-mails only > 0.2% responded with orders. That's = 100 people responded > and ordered Report # 2. Those 100 people mail out 5,000 > e-mails each for a total of 500,000 e-mails. The 0.2% response > to that is 1000 orders for Report # 3. Those 1000 people send > out 5,000 e-mails each for a total of 5 million e-mails sent out. > The 0.2% response to that is 10,000 orders for Report # 4. > Those 10,000 people send out 5,000 e-mails each for a total of > 50,000,000 (50 million) e-mails. The 0.2% response to that is > 100,000 orders for Report # 5. > > THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half million). > > Your total income in this example is: > 1..... $50 + > 2..... $500 + > 3..... $5,000 + > 4..... $50,000 + > 5..... $500,000 ......... Grand Total = $555,550.00 > > NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE > OUT THE WORST POSSIBLE RESPONSES AND NO MATTER > HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF > MONEY ! > > -------------------------------------------------------------------------- ---- > > REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE > ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for > a moment what would happen if everyone, or half or even one 4th > of those people mailed 100,000 e-mails each or more? There are > over 250 million people on the internet worldwide and counting. > Believe me, many people will do just that, and more! > > METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET > =================================================== > Advertising on the net is very very inexpensive and there are > hundreds of FREE places to advertise. Placing a lot of free adson the internet will easily get a larger response. We strongly > suggest you start with Method # 1 and add METHOD # 2 as you go > along. > > For every $5 you receive, all you must do is e-mail them the Report > they ordered. That's it . Always provide same day service on all > orders. This will guarantee that the e-mail they send out, with your > name and address on it, will be prompt because they can not advertise until > they receive the report. > > _____________________ AVAILABLE REPORTS_____________________ > > ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. > > Notes: Always send $5 cash (U.S. CURRENCY) for each Report. > Checks NOT accepted. Make sure the cash is concealed by wrapping > it in at least 2 sheets of paper. On one of those sheets of paper, > Write the NUMBER & the NAME of the Report you are ordering, YOUR > E-MAIL ADDRESS and your name and postal address. > > PLACE YOUR ORDER FOR THESE REPORTS NOW : > ============================================== > REPORT #1, "The Insider's Guide to Sending > Bulk E-mail on the Internet" > > ORDER REPORT #1 FROM: > > G. Donaldson > P.O. Box 25884 > Honolulu, Hawaii 96825-0884 > > > don't forget to provide a permanent e-mail address in clear writing (better > typed) to receive the reports. We had problems in delivery e-mails before!!! > > ============================================== > REPORT #2 "The Insider's Guide to Advertising for Free on the > Internet" > ORDER REPORT #2 FROM: > > Vijay Paul > C-291, Second Floor > Defence Colony > New Delhi - 110024 > INDIA > > ============================================== > REPORT #3 "The Secrets to Multilevel Marketing on the Internet" > ORDER REPORT #3 FROM: > > JD > P.O.Box 1114 > Des Plaines, IL 60017 > USA > > ============================================== > REPORT #4 "How to become a Millionaire utilizing the Power of > Multilevel Marketing and the Internet" > ORDER REPORT #4 FROM: > > J Santi > 833 Walter Ave > Des Plaines, IL 60016 > USA > > ============================================== > REPORT #5 "How to SEND 1,000,000 e-mails for FREE" > ORDER REPORT #5 FROM: > > Elaine Rix > 138 Dundas Street, West, #243 > Toronto, Ontario > Canada M5G 1C3 > > ============================================== > There are currently more than 250,000,000 people online > worldwide! > > $$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$ > > Follow these guidelines to guarantee your success: > > If you do not receive at least 10 orders for Report #1 within 2 > weeks, continue sending e-mails until you do. > > After you have received 10 orders, 2 to 3 weeks after that > you should receive 100 orders or more for REPORT # 2. > If you did not, continue advertising or sending e-mails until > you do. > Once you have received 100 or more orders for Report # 2, > YOU CAN RELAX, because the system is already working for > you , and the cash will continue to roll in ! > > THIS IS IMPORTANT TO REMEMBER : Every time your name is > moved down on the list, you are placed in front of a different report. > You can KEEP TRACK of your PROGRESS by watching which > report people are ordering from you. IF YOU WANT TO GENERATE > MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND > START THE WHOLE PROCESS AGAIN. There is NO LIMIT to > the income you can generate from this business !!! > ____________________________________________________ > > FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS > PROGRAM: > > You have just received information that can give you financial > freedom for the rest of your life, with NO RISK and JUST A > LITTLE BIT OF EFFORT. You can make more money in the > next few weeks and months than you have ever imagined. > > Follow the program EXACTLY AS INSTRUCTED. Do Not change > it in any way. It works exceedingly well as it is now. > Remember to e-mail a copy of this exciting report after you > have put your name and address in Report #1 and moved others to > #2...........# 5 as instructed above. One of the people you send this to may > send out 100,000 or more e-mails and your name will be on everyone of them. > Remember though, the more you send out the more potential customers you will > reach. > > So my friend, I have given you the ideas, information, > materials and opportunity to become financially independent. IT IS UP TO YOU > NOW ! > > ************** MORE TESTIMONIALS **************** > > "My name is Mitchell. My wife , Jody and I live in Chicago. > I am an accountant with a major U.S. Corporation and I > make pretty good money. When I received this program I grumbled > to Jody about receiving ''junk mail''. I made fun of the > whole thing, spouting my knowledge of the population and > percentages involved. I ''knew'' it wouldn't work. Jody > totally ignored my supposed intelligence and few days later she jumped in > with both feet. I made merciless fun of her, and was ready to > lay the old ''I told you so'' on her when the thing didn'twork. Well, the laugh was on me! Within 3 weeks she had received > 50 responses. Within the next 45 days she had received a > total of $ 147,200.00 all cash! I was shocked. I have > joined Jody in her ''hobby''." > Mitchell Wolf, > Chicago, Illinois > > ------------------------------------------------------------ > > "Not being the gambling type, it took me several weeks to > make up my mind to participate in this plan. But conservative that > I am, I decided that the initial investment was so little > that there was just no way that I wouldn't get enough orders to at > least get my money back. > > I was surprised when I found my medium size post office box > crammed with orders. I made $319,210.00 in the first 12 > weeks. The nice thing about this deal is that it does not matter > where people live. There simply isn't a better investment > with a faster return and so big." > Dan Sondstrom, Alberta, > Canada > > ----------------------------------------------------------- > > "I had received this program before. I deleted it, but > later I wondered if I should have given it a try. Of course, I had > no idea who to contact to get another copy, so I had to wait > until I was e-mailed again by someone else.........11 months > passed then it luckily came again...... I did not delete this > one! I made more than $490,000 on my first try and all the > money came within 22 weeks". > Susan De Suza, > New York, N.Y. > > ---------------------------------------------------- > > "It really is a great opportunity to make relatively easy > money with little cost to you. I followed the simple > instructions carefully and within 10 days the money > started to come in. My first month I made $ 20,560.00 > and by the end of third month my total cash count was > $ 362,840.00. Life is beautiful, Thanx to internet". > Fred Dellaca, Westport, > New Zealand > ------------------------------------------------------------ > > > ORDER YOUR REPORTS TODAY AND GET STARTED ON > YOUR ROAD TO FINANCIAL FREEDOM ! > > ======================================================= > > If you have any questions of the legality of this program, contact the > Office of Associate Director for Marketing Practices, Federal Trade > Commission, Bureau of Consumer Protection, Washington, D.C. > > > Under Bill s.1618 TITLE III passed by the 105th US Congress this > letter cannot be considered spam as long as the sender includes > contact information and a method of removal. > This is one time e-mail transmission. No request for removal is > necessary. > > ------------------------------------------------------------ > This message is sent in compliance of the new email > Bill HR 1910. Under Bill HR 1910 passed by the 106th > US Congress on May 24, 1999, this message cannot be > considered Spam as long as we include the way to be > removed. Per Section HR 1910, Please type "REMOVE" in > the subject line and reply to this email. All removal > requests are handled personally an immediately once > received. > > > > > > > > > _______________________________________________ > 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 May 10 12:08:24 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 MAA01610 for ; Thu, 10 May 2001 12:08:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23393; Thu, 10 May 2001 12:03:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23362 for ; Thu, 10 May 2001 12:02:53 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01464 for ; Thu, 10 May 2001 12:02:37 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA08707 for ; Thu, 10 May 2001 09:02:40 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id JAA10558 for ; Thu, 10 May 2001 09:02:40 -0700 (PDT) Received: from xch-pssbh-01.nw.nos.boeing.com by blv-hub-01.boeing.com with ESMTP; Thu, 10 May 2001 09:02:26 -0700 Received: by xch-pssbh-01.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 May 2001 09:02:26 -0700 Message-Id: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12CB8@XCH-NW-01.nw.nos.boeing.com> From: "Fleischman, Eric W" To: "'Christian Huitema'" , midcom@ietf.org Date: Thu, 10 May 2001 09:02:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [midcom] RE: Comments on draft-ietf-midcom-scenarios-01.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 Christian, I am not surprised to read that your goals and mine are the same. I would have been disappointed were that not the case. However, the current wording of this draft doesn't yet take us where we want to go, though it is a very fine beginning: 1) The confusion between policy and scenarios in the current draft needs to be corrected regardless of whether your document functions solely as a scenarios document or as the requirements document. Your second paragraph in your email below demonstrates that you also recognize that policy is orthogonal to the scenarios. If so, then you shouldn't intertwine policy within the scenarios at any point because by doing so you are implying that the scenarios prejudice policy decisions. They don't. Corporate policy will apply against all of the scenarios and you dare not guess what those policies or the local reaction to the scenarios will be, since it will be a local matter to that corporation (or individual), and may actually be a function of that local policy in response to specific established business relationships. 2) I have never understood the desire on the part of some of our peers to create a scenarios document separate from a requirements document. In my mind, what is needed is a single document where all of the requirements are located. Since I view these scenarios to be part of the requirements, I argued at the last IETF that you should be creating the first draft of this combined document. I still make the same argument, since I heard no explanation for why two documents are more desirable than one (i.e., why would anybody prefer to consult two documents to gather requirements when they could only consult one authoritative document? It just doesn't make any sense ... (to me, anyway)). 3) The requirements document must mention the requirement for optional authentication of the requestor. It also must address the fact that the requester needs to optionally specify the nature of the "hole" they are requesting, optionally including duration, ranges of remote addresses which can enter it, and the number of "simultaneous sessions" to that internal destination. Another requirement for the protocol is that the middlebox must be optionally able to tell the requester how it responded to the request, including whether it opened the "hole" as was originally requested or a "reduced hole", and if the latter, what the resulting "hole characteristics" are. 4) I had not previously thought of the operational requirements you mention in your third paragraph below. Now that I've thought of them, I very much want to see those ideas further developed in the requirements document (preferably by expanding your document, or else seeing a separate document). Those are indeed important requirements. They differ however from the items I was identifying in that those operational concepts don't need to be explicitly carried by the midcom protocol such as explicit authentication and policy negotiation do. They rather need to be attributes of the total system that are supported -- and anticipated -- by the total system, including the midcom protocol, even though the protocol itself will not need to carry any support negotiation. Please note that these last few sentences of mine are not a consensus of this WG. It is solely a personal opinion of mine. I encourage debate if anyone has a different perspective, otherwise I'd like to see it documen! te! d as a straw man position of the group. Changing topics, I did not see (in my glancing through the remainder of your document) any mention of a policy server (PDP) requesting "holes" through a middlebox to specific internal or external systems (note the plural). Is this out of scope (i.e., a local implementation matter) or in-scope? My own thoughts are confused on this point, since I see value in both positions. What does the WG think about this? --Eric -----Original Message----- From: Christian Huitema [mailto:huitema@exchange.microsoft.com] Sent: Wednesday, May 09, 2001 6:47 PM To: Fleischman, Eric W; midcom@ietf.org Subject: RE: Comments on draft-ietf-midcom-scenarios-01.txt Eric, Thanks for your comments. The absence of any mention of security requirements in the scenario was quite deliberate. The idea was to explain the nature of the holes that would have to be opened for the applications to work, so as to derive what I would call the "functional requirements" of the protocol. It is quite clear that we also have other requirements, notably security requirements. In the scenarios, I described what the application needs in order to run; whether the application is actually allowed to run or not is a matter of local policy. In order to meet the functional requirements, the midcom protocol will have to enable the scenarios that I described. In order to meet the security requirements, the midcom protocol will have to provide adequate controls. I have my own understanding of these controls: I believe that the protocol should be able to express who is asking the query (authentication) as well as what the query is intended to achieve, e.g. what application, for which user, using what amount of resource. In addition, we also have operational requirements, e.g. support stable operation even if some of the systems involved crash; enable multi-homing; etc. I would expect that functional, security and operational requirements will be written down in the "requirements" draft. Now, if we are waiting too long for that draft, I could indeed increment the scenario draft with a listing of these requirements... -- Christian Huitema > -----Original Message----- > From: Fleischman, Eric W [mailto:Eric.Fleischman@PSS.Boeing.com] > Sent: Wednesday, May 09, 2001 5:58 PM > To: 'midcom@ietf.org'; Christian Huitema > Subject: Comments on draft-ietf-midcom-scenarios-01.txt > > I thank Christian Huitema for this excellent internet-draft document. > Although I have only read the first five pages with care, having only > glanced through the rest of the document at this time, I nevertheless have > a few comments that I would like to share with you based upon this early > (semi-)reading. > > I like Christian's approach of describing distinct configuration scenarios > which the midcom protocol will need to support. I believe that this is an > excellent basis for stating these requirements and that Christian has > provided us with an excellent text to base our discussions upon. However, > I find the granularity of this current discussion to be very troubling, > missing important sets of requirements that need to be captured up front. > > -------------------------- > Issue 1: Confusion of Scenarios with Policy > The current text appears to imply that the first generic scenario (TCP > Server behind a firewall/NAT), described in Section 2.1, will open a semi- > permanent hole through the middle box to a specific "Internal Host", while > the second generic scenario (Peer-to-Peer communication with ad-hoc > rendezvous) produces an "authorization [that] is typically valid for only > a single TCP connection" (see penultimate paragraph in section 2.2). I > firmly state that any such implication is unacceptable. > > I rather state that the configuration scenarios are independent from local > policy issues. Specifically, it is a local policy decision whether the > first approach can open "semi-permanent holes" and the second approach a > transitory hole (i.e., "valid only a single TCP connection") or vice- > versa. The requirements need to recognize that the midcom protocol has two > orthogonal requirements it must fulfill: it must satisfy the needs of > communication protocols to operate as described by Christian's scenarios > and it also must cooperate with and support local policies. These two > functions are distinct from each other and must not be confused. > > Specifically, I can not imagine (though I may be mistaken) the > administrators of my company's firewalls deploying a product which, based > upon the protocol exchange described in section 2.1 [even with explicit > authentication checks (which weren't mentioned, BTW)], will permit the > Internal Host to open any unconstrained hole through our firewall to > itself. Rather, we will require the ability to restrict the nature of that > hole based upon local policy. Simultaneously, we would be very interested > in knowing just how big a hole that application wants, since it is more > aware than we are about the needs it is trying to satisfy. Policy is > therefore not (always) a binary thing, and some policy negotiation > capabilities need to be built into the midcom protocol. > > It is therefore very desirable, but not required, that the Internal Host, > in such a scenario, provide input as to the nature of the hole they are > requesting. This input can specify the range of remote source addresses > which can be permitted to go through that hole as well as the duration > during which that hole will be maintained. It should also optionally state > how many simultaneous sessions can be supported by this request. > > The protocol should also address the possibility that corporate policy > will restrict the hole to be smaller than what the requesting agent > requested, and the nature of that restriction should be conveyable back to > the requesting party, since any policy enforcement point has "the final > word" on such matters. > > This ability to restrict the hole to a "range of addresses" is a very > important matter and should not be deprecated. It reflects the fact that > (increasingly) the interactions between corporations is partially a > function of whether their respective policies collide or synergize > together. This is a very big topic that I would prefer to not get into > now, but I will point out that any company having ITAR restrictions upon > itself must be very aware of the nature of its interactions with other > corporations, to ensure that their cumulative policies do not violate this > mandate of the US Government. It is difficult to imagine creating a viable > collaborate infrastructure in the aerospace industry without addressing > such concerns. > > ------------------------------------ > Issue 2: Middleboxes are PEPs > Middleboxes function as Policy Enforcement Points. As such, it wouldn't > hurt matters to explicitly mention that the firewall/NAT may need to use > COPS to query a Policy Server (PDP) concerning what response it should > give to the Internal Host's request that it open a hole through itself. I > recognize that this is a implementation detail, but I am concerned that a > failure to capture this possibility may also mean that we fail to > acknowledge the other parts of the system that need to be considered to > create a viable standard. > > --------------------------------------- > Issue 3: Authentication and Access Control are Big Issues > I am concerned with the lack of emphasis given to the importance of the > midcom protocol to satisfy rigorous authentication and access control > requirements. I readily admit that access control (i.e., authorization) -- > and how it is done -- is probably a "local implementation issue". However, > authentication isn't, and it needs to be explicitly addressed. > > Specifically, the penultimate paragraph of Section 2.1 states: "It is > quite clear that the interaction between the internal host and the > firewall/NAT described in the first step of the scenario may require some > form of access control." This text assumes that access control is a > function of this scenario, but not of the preceding one. This is wrong. > Authentication is potentially needed for ALL of the scenarios -- every one > of them. Thus, this idea is incorrectly positioned within the paper. It > should rather be noted up front within this document that a firm > requirement of the Midcom Protocol is that it must optionally provide > authentication between the Middlebox and the requester. I don't know > whether two-way authentication is required or not, but I will assert that > the Middlebox had better be able to authenticate the requester if it is > going to be deployed upon our machines. > > --------------------------------------- > Issue 4: Section 2.2.2 > I would rather state that the issue of both peers being behind firewalls > should preferentially be treated by considering mechanisms by which the > external IP address, negotiated by the Internal host with the firewall, > can be communicated to its remote peer, and vice-versa. This can be done > via "out of band" signaling (e.g., Email exchange) or SDP-based > approaches. Alternatively, it could be handled by both systems publishing > their IP addresses to name services. However it is done, the configuration > should not dictate policy as the current text implies when it says "Allow > the internal host to accept TCP connections from any external address." > > Thank you for your attention to this posting. > > --Eric Fleischman _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu May 10 12:13:27 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 MAA01843 for ; Thu, 10 May 2001 12:13:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23500; Thu, 10 May 2001 12:09:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23459 for ; Thu, 10 May 2001 12:08:58 -0400 (EDT) Received: from lint.cisco.com ([171.68.224.209]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01622 for ; Thu, 10 May 2001 12:08:38 -0400 (EDT) Received: from cisco.com (sjc-vpn-tmp243.cisco.com [10.21.64.243]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA04530; Thu, 10 May 2001 09:07:19 -0700 (PDT) Message-ID: <3AFABC44.76BDAD24@cisco.com> Date: Thu, 10 May 2001 09:05:24 -0700 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: "Fleischman, Eric W" CC: "'midcom@ietf.org'" , "'huitema@exchange.microsoft.com'" Subject: Re: [midcom] Comments on draft-ietf-midcom-scenarios-01.txt References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12CB6@XCH-NW-01.nw.nos.boeing.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 Eric, Thanks for your comments. You raise a rather large concern, however. How much back and forth would you expect to have happen in the midcom protocol? Consider the following code-frag: Noting that some of this information will not always be available, what would you like to receive? -- Eliot Lear lear@cisco.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu May 10 12:22:48 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 MAA02079 for ; Thu, 10 May 2001 12:22:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23773; Thu, 10 May 2001 12:18:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23738 for ; Thu, 10 May 2001 12:18:15 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01988 for ; Thu, 10 May 2001 12:18:05 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA01255 for ; Thu, 10 May 2001 09:17:52 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id JAA21349 for ; Thu, 10 May 2001 09:17:52 -0700 (PDT) Received: from xch-pssbh-03.nw.nos.boeing.com by blv-hub-01.boeing.com with ESMTP; Thu, 10 May 2001 09:17:38 -0700 Received: by xch-pssbh-03.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 May 2001 09:17:37 -0700 Message-Id: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12CB9@XCH-NW-01.nw.nos.boeing.com> From: "Fleischman, Eric W" To: "'lear@cisco.com'" , "Fleischman, Eric W" Cc: "'midcom@ietf.org'" , "'huitema@exchange.microsoft.com'" Subject: RE: [midcom] Comments on draft-ietf-midcom-scenarios-01.txt Date: Thu, 10 May 2001 09:17:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain 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 like your code fragment. It's the type of thing I was also envisioning. Concerning back and forth, here's what I was thinking: requester ====> Middlebox (Optional: Middlebox ====> PDP followed by Middlebox <==== PDP) requester <=== Middlebox That is, I was not envisioning the requester being able to "argue with" the Middlebox concerning the middlebox's decisions, but merely a establishing a request/reply protocol between them. That's what I've been thinking. What have you been thinking? -----Original Message----- From: Eliot Lear [mailto:lear@cisco.com] Sent: Thursday, May 10, 2001 9:05 AM To: Fleischman, Eric W Cc: 'midcom@ietf.org'; 'huitema@exchange.microsoft.com' Subject: Re: [midcom] Comments on draft-ietf-midcom-scenarios-01.txt Eric, Thanks for your comments. You raise a rather large concern, however. How much back and forth would you expect to have happen in the midcom protocol? Consider the following code-frag: Noting that some of this information will not always be available, what would you like to receive? -- Eliot Lear lear@cisco.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu May 10 12:56: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 MAA03245 for ; Thu, 10 May 2001 12:56:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24289; Thu, 10 May 2001 12:52:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24256 for ; Thu, 10 May 2001 12:52:19 -0400 (EDT) Received: from lint.cisco.com ([171.68.224.209]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03103 for ; Thu, 10 May 2001 12:52:20 -0400 (EDT) Received: from cisco.com (sjc-vpn-572.cisco.com [10.21.66.60]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA24588; Thu, 10 May 2001 09:50:50 -0700 (PDT) Message-ID: <3AFAC6E8.A861D658@cisco.com> Date: Thu, 10 May 2001 09:50:48 -0700 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: "Fleischman, Eric W" CC: "'midcom@ietf.org'" , "'huitema@exchange.microsoft.com'" Subject: Re: [midcom] Comments on draft-ietf-midcom-scenarios-01.txt References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12CB9@XCH-NW-01.nw.nos.boeing.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 I have a goal of no negotiations in the classic sense, just as we pretty much avoided it with EHLO. Back and forth as you describe has performance implications. -- Eliot Lear lear@cisco.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu May 10 13:20: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 NAA04162 for ; Thu, 10 May 2001 13:20:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24831; Thu, 10 May 2001 13:14:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24802 for ; Thu, 10 May 2001 13:14:05 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03824 for ; Thu, 10 May 2001 13:14:05 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA23485 for ; Thu, 10 May 2001 10:14:09 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id KAA04209 for ; Thu, 10 May 2001 10:14:08 -0700 (PDT) Received: from xch-pssbh-03.nw.nos.boeing.com by blv-hub-01.boeing.com with ESMTP; Thu, 10 May 2001 10:14:00 -0700 Received: by xch-pssbh-03.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 May 2001 10:14:00 -0700 Message-Id: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12CBB@XCH-NW-01.nw.nos.boeing.com> From: "Fleischman, Eric W" To: "'lear@cisco.com'" Cc: "'midcom@ietf.org'" , "'huitema@exchange.microsoft.com'" Subject: RE: [midcom] Comments on draft-ietf-midcom-scenarios-01.txt Date: Thu, 10 May 2001 10:13:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain 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 Eliot, I had not considered this alternative. If I understand you correctly, you are considering a system where the communications solely are: requester ====> Middlebox (Optional: Middlebox ====> PDP followed by Middlebox <==== PDP) If this is accurate, then how will the application or individual who made the original request know whether or not it was granted? This is a very important issue for us end users. Please picture the following scenario: you are I are trying to set up a conference between our two organizations. Let's say we are going to use NetMeeting or some other H.323 technology. My system makes a request to our firewall and your system makes a request to yours -- or maybe mine makes the request to both -- it simply doesn't matter for this example. Anyway, we human beings have done all we can do and we try to start the session only to find that we fail to obtain an end-to-end connection. In my approach we know why the connection failed because the Middlebox has told us the status of our request. How does one know that in your approach? Specifically, what do you and I do next to establish our session, given the approach you are considering? --Eric -----Original Message----- From: Eliot Lear [mailto:lear@cisco.com] Sent: Thursday, May 10, 2001 9:51 AM To: Fleischman, Eric W Cc: 'midcom@ietf.org'; 'huitema@exchange.microsoft.com' Subject: Re: [midcom] Comments on draft-ietf-midcom-scenarios-01.txt I have a goal of no negotiations in the classic sense, just as we pretty much avoided it with EHLO. Back and forth as you describe has performance implications. -- Eliot Lear lear@cisco.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu May 10 16:06:57 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 QAA07358 for ; Thu, 10 May 2001 16:06:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28343; Thu, 10 May 2001 16:05:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28314 for ; Thu, 10 May 2001 16:05:31 -0400 (EDT) Received: from gollum.axion.bt.co.uk ([132.146.17.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07348 for ; Thu, 10 May 2001 16:05:29 -0400 (EDT) From: richard.swale@bt.com Received: from cbtlipnt02.btlabs.bt.co.uk by gollum (local) with ESMTP; Thu, 10 May 2001 20:49:01 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id <1PP9NKA7>; Thu, 10 May 2001 20:48:03 +0100 Message-ID: To: midcom@ietf.org Date: Thu, 10 May 2001 20:42:50 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Subject: [midcom] terminology in scenarios draft-01 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 Dear All, I have been looking at aligning the terminology across the three drafts at present and would like to make the suggestion that we include the use of the term "MIDCOM Agent" at appropriate points in the description of the various scenarios. For example, it appears variously in the guise of "Management Server", "Internal host", "Internal Server" and "6to4 router" - all of which are valuable and useful illustrations but with no reference back to the term introduced in the architecture document. Would it be possible to add this linkage please? Many thanks. regards Richard Richard Swale VoIP Technologist BTexact Technologies Room 140, Calisto House, Adastral Park, Martlesham, Ipswich IP5 3RE, UK e-mail: richard.swale@bt.com tel: +44(0) 1473 645785 mobile: +44(0) 7802 162410 fax: +44(0) 1473 64809 BTexact Technologies is a trademark of British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu May 10 16:52:24 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 QAA08108 for ; Thu, 10 May 2001 16:52:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29237; Thu, 10 May 2001 16:51:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29164 for ; Thu, 10 May 2001 16:50:56 -0400 (EDT) Received: from web13802.mail.yahoo.com ([216.136.175.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08082 for ; Thu, 10 May 2001 16:50:51 -0400 (EDT) Message-ID: <20010510205055.44725.qmail@web13802.mail.yahoo.com> Received: from [65.12.33.187] by web13802.mail.yahoo.com; Thu, 10 May 2001 13:50:55 PDT Date: Thu, 10 May 2001 13:50:55 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] RE: Comments on draft-ietf-midcom-scenarios-01.txt To: "Fleischman, Eric W" , "'Christian Huitema'" , midcom@ietf.org In-Reply-To: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12CB8@XCH-NW-01.nw.nos.boeing.com> 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 --- "Fleischman, Eric W" wrote: > Christian, > > I am not surprised to read that your goals and mine are the same. I would > have been disappointed were that not the case. However, the current wording > of this draft doesn't yet take us where we want to go, though it is a very > fine beginning: > > 1) The confusion between policy and scenarios in the current draft needs to > be corrected regardless of whether your document functions solely as a > scenarios document or as the requirements document. Your second paragraph in > your email below demonstrates that you also recognize that policy is > orthogonal to the scenarios. If so, then you shouldn't intertwine policy > within the scenarios at any point because by doing so you are implying that > the scenarios prejudice policy decisions. They don't. Corporate policy will > apply against all of the scenarios and you dare not guess what those policies > or the local reaction to the scenarios will be, since it will be a local > matter to that corporation (or individual), and may actually be a function of > that local policy in response to specific established business relationships. > Eric - Christian is simply depicting functional scenarios that ought to work with MIDCOM protocol. You have to make assumptions about an application, the location of end-host participants, MIDCOM participants and policy governing the authorization of MIDCOM agents in order to illustrate the scanarios. That is not making a statement about MIDCOM Policy Server. I really dont think scenarios are prejudicing policy decions. Scenarios are merely making certain local policy decisions. Without that, you have no credible scenario. > want to see those ideas further developed in the requirements document > (preferably by expanding your document, or else seeing a separate document). > Those are indeed important requirements. They differ however from the items I > was identifying in that those operational concepts don't need to be > explicitly carried by the midcom protocol such as explicit authentication and > policy negotiation do. They rather need to be attributes of the total system > that are supported -- and anticipated -- by the total system, including the > midcom protocol, even though the protocol itself will not need to carry any > support negotiation. Please note that these last few sentences of mine are > not a consensus of this WG. It is solely a personal opinion of mine. I > encourage debate if anyone has a different perspective, otherwise I'd like to > see it documen! As for the role of Policy Server vis-a-vis middlebox, you are apparently envisioning a PDP-PEP type of relationship. That is not the consensus of the Work Group. Below is what I have in the framework draft on Policy Server - This has gone through reviews from some WG folks. Policy Server is a management entity that interfaces with a middlebox to communicate policies concerning authorization of MIDCOM agents gaining access to middlebox resources. A MIDCOM agent may be pre-configured on a middlebox as a trusted entity. In the case where a MIDCOM agent is not pre-configured, the middlebox will consult Policy Server Out-of-band for validating the authorization to accept requests from the agent. A policy server might add or delete MIDCOM agents on a middlebox. The protocol facilitating the communication between a middlebox and Policy Server need not be part of MIDCOM protocol. > te! > d as a straw man position of the group. > > Changing topics, I did not see (in my glancing through the remainder of your > document) any mention of a policy server (PDP) requesting "holes" through a > middlebox to specific internal or external systems (note the plural). Policy Server does not request holes. MIDCOM agents do. See my comments earlier about PDP-PEP relationship you allude to. > Is this > out of scope (i.e., a local implementation matter) or in-scope? My own > thoughts are confused on this point, since I see value in both positions. Policy Servers requesting holes on a middlebox is out-of scope, as far as I understand. > What does the WG think about this? > > --Eric cheers, suresh > > -----Original Message----- > From: Christian Huitema [mailto:huitema@exchange.microsoft.com] > Sent: Wednesday, May 09, 2001 6:47 PM > To: Fleischman, Eric W; midcom@ietf.org > Subject: RE: Comments on draft-ietf-midcom-scenarios-01.txt > > > Eric, > > Thanks for your comments. The absence of any mention of security > requirements in the scenario was quite deliberate. The idea was to > explain the nature of the holes that would have to be opened for the > applications to work, so as to derive what I would call the "functional > requirements" of the protocol. > > It is quite clear that we also have other requirements, notably security > requirements. In the scenarios, I described what the application needs > in order to run; whether the application is actually allowed to run or > not is a matter of local policy. In order to meet the functional > requirements, the midcom protocol will have to enable the scenarios that > I described. In order to meet the security requirements, the midcom > protocol will have to provide adequate controls. I have my own > understanding of these controls: I believe that the protocol should be > able to express who is asking the query (authentication) as well as what > the query is intended to achieve, e.g. what application, for which user, > using what amount of resource. > > In addition, we also have operational requirements, e.g. support stable > operation even if some of the systems involved crash; enable > multi-homing; etc. > > I would expect that functional, security and operational requirements > will be written down in the "requirements" draft. Now, if we are waiting > too long for that draft, I could indeed increment the scenario draft > with a listing of these requirements... > > -- Christian Huitema > > > -----Original Message----- > > From: Fleischman, Eric W [mailto:Eric.Fleischman@PSS.Boeing.com] > > Sent: Wednesday, May 09, 2001 5:58 PM > > To: 'midcom@ietf.org'; Christian Huitema > > Subject: Comments on draft-ietf-midcom-scenarios-01.txt > > > > I thank Christian Huitema for this excellent internet-draft document. > > Although I have only read the first five pages with care, having only > > glanced through the rest of the document at this time, I nevertheless > have > > a few comments that I would like to share with you based upon this > early > > (semi-)reading. > > > > I like Christian's approach of describing distinct configuration > scenarios > > which the midcom protocol will need to support. I believe that this is > an > > excellent basis for stating these requirements and that Christian has > > provided us with an excellent text to base our discussions upon. > However, > > I find the granularity of this current discussion to be very > troubling, > > missing important sets of requirements that need to be captured up > front. > > > > -------------------------- > > Issue 1: Confusion of Scenarios with Policy > > The current text appears to imply that the first generic scenario (TCP > > Server behind a firewall/NAT), described in Section 2.1, will open a > semi- > > permanent hole through the middle box to a specific "Internal Host", > while > > the second generic scenario (Peer-to-Peer communication with ad-hoc > > rendezvous) produces an "authorization [that] is typically valid for > only > > a single TCP connection" (see penultimate paragraph in section 2.2). I > > firmly state that any such implication is unacceptable. > > > > I rather state that the configuration scenarios are independent from > local > > policy issues. Specifically, it is a local policy decision whether the > > first approach can open "semi-permanent holes" and the second approach > a > > transitory hole (i.e., "valid only a single TCP connection") or vice- > > versa. The requirements need to recognize that the midcom protocol has > two > > orthogonal requirements it must fulfill: it must satisfy the needs of > > communication protocols to operate as described by Christian's > scenarios > > and it also must cooperate with and support local policies. These two > > functions are distinct from each other and must not be confused. > > > > Specifically, I can not imagine (though I may be mistaken) the > > administrators of my company's firewalls deploying a product which, > based > > upon the protocol exchange described in section 2.1 [even with > explicit > > authentication checks (which weren't mentioned, BTW)], will permit the > > Internal Host to open any unconstrained hole through our firewall to > > itself. Rather, we will require the ability to restrict the nature of > that > > hole based upon local policy. Simultaneously, we would be very > interested > > in knowing just how big a hole that application wants, since it is > more > > aware than we are about the needs it is trying to satisfy. Policy is > > therefore not (always) a binary thing, and some policy negotiation > > capabilities need to be built into the midcom protocol. > > > > It is therefore very desirable, but not required, that the Internal > Host, > > in such a scenario, provide input as to the nature of the hole they > are > > requesting. This input can specify the range of remote source > addresses > > which can be permitted to go through that hole as well as the duration > > during which that hole will be maintained. It should also optionally > state > > how many simultaneous sessions can be supported by this request. > > > > The protocol should also address the possibility that corporate policy > > will restrict the hole to be smaller than what the requesting agent > > requested, and the nature of that restriction should be conveyable > back to > > the requesting party, since any policy enforcement point has "the > final > > word" on such matters. > > > > This ability to restrict the hole to a "range of addresses" is a very > > important matter and should not be deprecated. It reflects the fact > that > > (increasingly) the interactions between corporations is partially a > > function of whether their respective policies collide or synergize > > together. This is a very big topic that I would prefer to not get into > > now, but I will point out that any company having ITAR restrictions > upon > > itself must be very aware of the nature of its interactions with other > > corporations, to ensure that their cumulative policies do not violate > this > > mandate of the US Government. It is difficult to imagine creating a > viable > > collaborate infrastructure in the aerospace industry without > addressing > > such concerns. > > > > ------------------------------------ > > Issue 2: Middleboxes are PEPs > > Middleboxes function as Policy Enforcement Points. As such, it > wouldn't > > hurt matters to explicitly mention that the firewall/NAT may need to > use > > COPS to query a Policy Server (PDP) concerning what response it should > > give to the Internal Host's request that it open a hole through > itself. I > > recognize that this is a implementation detail, but I am concerned > that a > > failure to capture this possibility may also mean that we fail to > > acknowledge the other parts of the system that need to be considered > to > > create a viable standard. > > > > --------------------------------------- > > Issue 3: Authentication and Access Control are Big Issues > > I am concerned with the lack of emphasis given to the importance of > the > > midcom protocol to satisfy rigorous authentication and access control > > requirements. I readily admit that access control (i.e., > authorization) -- > > and how it is done -- is probably a "local implementation issue". > However, > > authentication isn't, and it needs to be explicitly addressed. > > > > Specifically, the penultimate paragraph of Section 2.1 states: "It is > > quite clear that the interaction between the internal host and the > > firewall/NAT described in the first step of the scenario may require > some > > form of access control." This text assumes that access control is a > > function of this scenario, but not of the preceding one. This is > wrong. > > Authentication is potentially needed for ALL of the scenarios -- every > one > > of them. Thus, this idea is incorrectly positioned within the paper. > It > > should rather be noted up front within this document that a firm > > requirement of the Midcom Protocol is that it must optionally provide > > authentication between the Middlebox and the requester. I don't know > > whether two-way authentication is required or not, but I will assert > that > > the Middlebox had better be able to authenticate the requester if it > is > > going to be deployed upon our machines. > > > > --------------------------------------- > > Issue 4: Section 2.2.2 > > I would rather state that the issue of both peers being behind > firewalls > > should preferentially be treated by considering mechanisms by which > the > > external IP address, negotiated by the Internal host with the > firewall, > > can be communicated to its remote peer, and vice-versa. This can be > done > > via "out of band" signaling (e.g., Email exchange) or SDP-based > > approaches. Alternatively, it could be handled by both systems > publishing > > their IP addresses to name services. However it is done, the > configuration > > should not dictate policy as the current text implies when it says > "Allow > > the internal host to accept TCP connections from any external > address." > > > > Thank you for your attention to this posting. > > > > --Eric Fleischman > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom ===== __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu May 10 17:01:29 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 RAA08273 for ; Thu, 10 May 2001 17:01:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29460; Thu, 10 May 2001 16:59:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29429 for ; Thu, 10 May 2001 16:59:51 -0400 (EDT) Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08235 for ; Thu, 10 May 2001 16:59:51 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f4AKxPd17889; Thu, 10 May 2001 13:59:25 -0700 (PDT) Received: from spandex (rtp-vpn-16.cisco.com [10.82.192.16]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AFF03506; Thu, 10 May 2001 13:59:22 -0700 (PDT) Message-ID: <014e01c0d994$27006b60$d45904d1@cisco.com> From: "Melinda Shore" To: "Pyda Srisuresh" , "Fleischman, Eric W" , "'Christian Huitema'" , References: <20010510205055.44725.qmail@web13802.mail.yahoo.com> Subject: Re: [midcom] RE: Comments on draft-ietf-midcom-scenarios-01.txt Date: Thu, 10 May 2001 16:59:48 -0400 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 > Policy Servers requesting holes on a middlebox is out-of scope, > as far as I understand. A policy server requesting a hole would 1) be using the midcom protocol, and 2) be functioning as a midcom agent in that case. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu May 10 18:34: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 SAA09399 for ; Thu, 10 May 2001 18:34:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01150; Thu, 10 May 2001 18:30:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01121 for ; Thu, 10 May 2001 18:30:38 -0400 (EDT) Received: from lint.cisco.com ([171.68.224.209]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09330 for ; Thu, 10 May 2001 18:30:32 -0400 (EDT) Received: from cisco.com (sjc-vpn-380.cisco.com [10.21.65.124]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA03167; Thu, 10 May 2001 15:30:02 -0700 (PDT) Message-ID: <3AFB1668.59CB5D77@cisco.com> Date: Thu, 10 May 2001 15:30:00 -0700 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: "Fleischman, Eric W" CC: "'midcom@ietf.org'" , "'huitema@exchange.microsoft.com'" Subject: Re: [midcom] Comments on draft-ietf-midcom-scenarios-01.txt References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12CBB@XCH-NW-01.nw.nos.boeing.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 Hi Erik, I'm not proposing NO feedback to the client. I would, however, like the client to make known all that is necessary on the first pass, or in the absolutely worst case, the second pass. In other words: client -> middlebox with request and that code frag I sent earlier. middlebox -> client with response, possibly including a valid ip address it will be using. What I want to avoid is this: client -> middlebox (request) middlebox -> client (i need username, application name) client -> middlebox (username lear, application name netscape) middlebox -> client (i need src,dst,proto) client -> middlebox (src=10.1.33.23,4323,dst=128.33.239,110,TCP) middlebox -> client (i need duration) client -> middlebox (duration=1h) user to both ends: (i need a coffee) this is the sort of chit chat i want to avoid. -- Eliot Lear lear@cisco.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu May 10 19:50:19 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 TAA10279 for ; Thu, 10 May 2001 19:50:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02029; Thu, 10 May 2001 19:49:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02000 for ; Thu, 10 May 2001 19:49:06 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10269 for ; Thu, 10 May 2001 19:49:06 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id QAA20232 for ; Thu, 10 May 2001 16:49:10 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id QAA00197 for ; Thu, 10 May 2001 16:49:09 -0700 (PDT) Received: from xch-pssbh-03.nw.nos.boeing.com by blv-hub-01.boeing.com with ESMTP; Thu, 10 May 2001 16:49:03 -0700 Received: by xch-pssbh-03.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 May 2001 16:49:03 -0700 Message-Id: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12CC0@XCH-NW-01.nw.nos.boeing.com> From: "Fleischman, Eric W" To: "'lear@cisco.com'" Cc: "'midcom@ietf.org'" , "'huitema@exchange.microsoft.com'" Subject: RE: [midcom] Comments on draft-ietf-midcom-scenarios-01.txt Date: Thu, 10 May 2001 16:48:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain 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 Thanks, Eliot. Based by your description, I am on the same page as you in that I did not envision a chatty protocol either, but rather a tight request/reply protocol. -----Original Message----- From: Eliot Lear [mailto:lear@cisco.com] Sent: Thursday, May 10, 2001 3:30 PM To: Fleischman, Eric W Cc: 'midcom@ietf.org'; 'huitema@exchange.microsoft.com' Subject: Re: [midcom] Comments on draft-ietf-midcom-scenarios-01.txt Hi Erik, I'm not proposing NO feedback to the client. I would, however, like the client to make known all that is necessary on the first pass, or in the absolutely worst case, the second pass. In other words: client -> middlebox with request and that code frag I sent earlier. middlebox -> client with response, possibly including a valid ip address it will be using. What I want to avoid is this: client -> middlebox (request) middlebox -> client (i need username, application name) client -> middlebox (username lear, application name netscape) middlebox -> client (i need src,dst,proto) client -> middlebox (src=10.1.33.23,4323,dst=128.33.239,110,TCP) middlebox -> client (i need duration) client -> middlebox (duration=1h) user to both ends: (i need a coffee) this is the sort of chit chat i want to avoid. -- Eliot Lear lear@cisco.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 04:40:45 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 EAA02364 for ; Fri, 11 May 2001 04:40:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16452; Fri, 11 May 2001 04:33:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16421 for ; Fri, 11 May 2001 04:33:55 -0400 (EDT) Received: from gandalf.axion.bt.co.uk (gandalf.axion.bt.co.uk [132.146.17.29]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02335 for ; Fri, 11 May 2001 04:33:48 -0400 (EDT) From: richard.swale@bt.com Received: from cbtlipnt02.btlabs.bt.co.uk by gandalf (local) with ESMTP; Fri, 11 May 2001 09:30:37 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id <1PP9NR3H>; Fri, 11 May 2001 09:29:37 +0100 Message-ID: To: lear@cisco.com, Eric.Fleischman@PSS.Boeing.com Cc: midcom@ietf.org, huitema@exchange.microsoft.com Subject: RE: [midcom] Comments on draft-ietf-midcom-scenarios-01.txt Date: Fri, 11 May 2001 09:24:23 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 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 Eliot, I agree with this discussion but think there are probably two types of interaction that we need to highlight. One is concerned with an application being able to interact with infrastructure (eg DNS, SIP Proxy servers et al) beyond the middlebox and the other is the media/stream/data transfer aspect. I think both of these are imlicit in Christian's scenarios document although may not have been brought out as distinct phases of activity. For some applications these two will have similar life times but for other this will not necessarily be the case. I see this as being important to appreciate because for large scale deployments the transactional load they may create on infrastructure servers will be very different - if you follow my point. regards Richard -----Original Message----- From: Eliot Lear [mailto:lear@cisco.com] Sent: 10 May 2001 23:30 To: Fleischman, Eric W Cc: 'midcom@ietf.org'; 'huitema@exchange.microsoft.com' Subject: Re: [midcom] Comments on draft-ietf-midcom-scenarios-01.txt Hi Erik, I'm not proposing NO feedback to the client. I would, however, like the client to make known all that is necessary on the first pass, or in the absolutely worst case, the second pass. In other words: client -> middlebox with request and that code frag I sent earlier. middlebox -> client with response, possibly including a valid ip address it will be using. What I want to avoid is this: client -> middlebox (request) middlebox -> client (i need username, application name) client -> middlebox (username lear, application name netscape) middlebox -> client (i need src,dst,proto) client -> middlebox (src=10.1.33.23,4323,dst=128.33.239,110,TCP) middlebox -> client (i need duration) client -> middlebox (duration=1h) user to both ends: (i need a coffee) this is the sort of chit chat i want to avoid. -- Eliot Lear lear@cisco.com _______________________________________________ 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 Fri May 11 11:21: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 LAA12821 for ; Fri, 11 May 2001 11:21:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23472; Fri, 11 May 2001 11:20:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23443 for ; Fri, 11 May 2001 11:20:00 -0400 (EDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12787 for ; Fri, 11 May 2001 11:19:53 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016.europe.nortel.com [47.255.64.31]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA16019 for ; Fri, 11 May 2001 10:20:10 -0500 (CDT) Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com; Fri, 11 May 2001 15:59:30 +0100 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 May 2001 15:43:04 +0100 Message-ID: <9154CB41F208D5118DD200508BE39C300B8877@zjguc006.europe.nortel.com> From: "Cedric Aoun" To: "'Christian Huitema'" , "Midcom IETF (E-mail)" Date: Fri, 11 May 2001 15:43:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DA28.AFF54E10" Subject: [midcom] Some comments on scenario draft 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_01C0DA28.AFF54E10 Content-Type: text/plain; charset="iso-8859-1" Christian, I have a couple of minor comments on the draft: -I'm not quite sure that basic NAT (1 address to 1 address mapping) will be completely forgotten in IPv6, enterprises will still would like to have a certain independence from their ISP since the used addresses are provided by the ISP and they don't want to change their addresses when they change their ISP. -In big corporations we could have a lot of cases where the signaling flow will traverse a different Middle box than the bearer path, this is a realistic scenario. It won't happen for residential customers and SME (might happen) but for big corporations having several gateways it will happen. I know that middle box discovery is out of scope of the workgroup, and that is the main reason why this scenario is not in your draft but I think it is worth to note it. I'm sure that other people in the list are interested in this scenario as well. Feedback is welcomed Regards Cedric Aoun Nortel Networks 33, quai Paul Doumer Paris La Defense 92415 Courbevoie Cedex France Gsm +33 6 85 74 43 04 Fax +33 1 46215598 cedric.aoun@nortelnetworks.com ------_=_NextPart_001_01C0DA28.AFF54E10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Some comments on scenario draft

Christian,
I have a couple of minor comments on = the draft:
-I'm not quite sure that basic NAT (1 = address to 1 address mapping) will be completely forgotten in IPv6, = enterprises will still would like to have a certain independence from = their ISP since the used addresses are provided by the ISP and they = don't want to change their addresses when they change their = ISP.

-In big corporations we could have a = lot of cases where the signaling flow will traverse a different Middle = box than the bearer path, this is a realistic scenario.

It won't happen for residential = customers and SME (might happen) but for big corporations having = several gateways it will happen.

I know that middle box discovery is = out of scope of the workgroup, and that is the main reason why this = scenario is not in your draft but I think it is worth to

note it.

I'm sure that other people in the list = are interested in this scenario as well.
Feedback is welcomed
Regards

Cedric Aoun
Nortel Networks
33, quai Paul Doumer
Paris La Defense
92415 Courbevoie Cedex France
Gsm +33 6 85 74 43 04
Fax  +33 1 46215598
cedric.aoun@nortelnetworks.com



------_=_NextPart_001_01C0DA28.AFF54E10-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 13:29: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 NAA16255 for ; Fri, 11 May 2001 13:29:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25656; Fri, 11 May 2001 13:19:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25629 for ; Fri, 11 May 2001 13:19:56 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15937 for ; Fri, 11 May 2001 13:19:49 -0400 (EDT) Received: from 157.54.9.108 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 11 May 2001 09:57:02 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 11 May 2001 09:58:59 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 11 May 2001 09:58:59 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 11 May 2001 09:58:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4688.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 11 May 2001 09:58:55 -0700 Message-ID: Thread-Topic: Some comments on scenario draft Thread-Index: AcDaL9wWiJaIiUhVSB2eXimEJYVr/AACkHoA From: "Christian Huitema" To: "Cedric Aoun" , "Midcom IETF (E-mail)" X-OriginalArrivalTime: 11 May 2001 16:58:56.0221 (UTC) FILETIME=[AA5840D0:01C0DA3B] X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA25630 Subject: [midcom] RE: Some comments on scenario draft 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 X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id NAA25656 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA16255 The plan of record for IPv6 is indeed that you will not use address translation and IPv6; frankly, if you still used NAT, there would be little reason to move to IPv6 in the first place! What I point out in the scenario is, what changes when IPv6 gives you global addressing. You are right about discovery. The "signaling server" has to understand the location of the firewalls in order to open the proper holes. This is not in scope for MIDCOM the scenarios merely assume that discovery somehow happens, and that the server knows which firewall will be used. That should definitely work in the main cases, when there is exactly one firewall per domain, or maybe one firewall cluster. -- Christian Huitema -----Original Message----- From: Cedric Aoun [mailto:CEDRIC.AOUN@nortelnetworks.com] Sent: Friday, May 11, 2001 7:43 AM To: Christian Huitema; Midcom IETF (E-mail) Subject: Some comments on scenario draft Christian, I have a couple of minor comments on the draft: -I'm not quite sure that basic NAT (1 address to 1 address mapping) will be completely forgotten in IPv6, enterprises will still would like to have a certain independence from their ISP since the used addresses are provided by the ISP and they don't want to change their addresses when they change their ISP. -In big corporations we could have a lot of cases where the signaling flow will traverse a different Middle box than the bearer path, this is a realistic scenario. It won't happen for residential customers and SME (might happen) but for big corporations having several gateways it will happen. I know that middle box discovery is out of scope of the workgroup, and that is the main reason why this scenario is not in your draft but I think it is worth to note it. I'm sure that other people in the list are interested in this scenario as well. Feedback is welcomed Regards Cedric Aoun Nortel Networks 33, quai Paul Doumer Paris La Defense 92415 Courbevoie Cedex France Gsm +33 6 85 74 43 04 Fax  +33 1 46215598 cedric.aoun@nortelnetworks.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 13:29: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 NAA16266 for ; Fri, 11 May 2001 13:29:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25723; Fri, 11 May 2001 13:23:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25697 for ; Fri, 11 May 2001 13:23:49 -0400 (EDT) Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16064 for ; Fri, 11 May 2001 13:23:43 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4BHNOU02804; Fri, 11 May 2001 10:23:24 -0700 (PDT) Received: from spandex (rtp-vpn-167.cisco.com [10.82.192.167]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AFF27762; Fri, 11 May 2001 10:23:10 -0700 (PDT) Message-ID: <038601c0da3f$1c443200$d45904d1@cisco.com> From: "Melinda Shore" To: "Cedric Aoun" , "'Christian Huitema'" , "Midcom IETF (E-mail)" References: <9154CB41F208D5118DD200508BE39C300B8877@zjguc006.europe.nortel.com> Subject: Re: [midcom] Some comments on scenario draft Date: Fri, 11 May 2001 13:23:33 -0400 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 > It won't happen for residential customers and SME (might happen) but for big > corporations having several gateways it will happen. > I know that middle box discovery is out of scope of the workgroup, and that > is the main reason why this scenario is not in your draft but I think it is > worth to > note it. It may be worth pointing out that while there's a discovery (or location) component to what you're describing, it's really a routing problem and it's rather difficult. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 13:46:22 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 NAA16815 for ; Fri, 11 May 2001 13:46:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26129; Fri, 11 May 2001 13:44:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26099 for ; Fri, 11 May 2001 13:44:58 -0400 (EDT) Received: from iere.net.avaya.com ([198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16776 for ; Fri, 11 May 2001 13:44:52 -0400 (EDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f4BHiMC28199 for ; Fri, 11 May 2001 13:44:22 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f4BHiMQ28188 for ; Fri, 11 May 2001 13:44:22 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DA42.1A1ABFD2" Subject: RE: [midcom] RE: Some comments on scenario draft X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Fri, 11 May 2001 11:45:00 -0600 Message-ID: Thread-Topic: Some comments on scenario draft Thread-Index: AcDaL9wWiJaIiUhVSB2eXimEJYVr/AACkHoAAAGGfhA= From: "Zmolek, Andrew (Andrew)" To: "Christian Huitema" , "Cedric Aoun" , "Midcom IETF (E-mail)" 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 a multi-part message in MIME format. ------_=_NextPart_001_01C0DA42.1A1ABFD2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Regardless of the plan of record, it seems quite clear that most enterprises have countless reasons to stick with IPv4 in their network core for decades. Moving to IPv6, as experience in the Asia-Pacific region bears out, is fundamentally a function of address space (at least that's what is driving this today). Hence, it will be a mistake not to assume that an IPv4 core to IPv6 edge won't be a commonly deployed topology over the next decade at least. Perhaps this is beyond the scope of midcom. But we need to be very careful about our assumptions here. Does midcom today make any assumptions with respect to v4 <-> v6 transit? Correct me if I'm wrong, but I believe this is merely an issue of capturing scenarios at this point. Nevertheless, I think Cedric raises some valid issues worth addressing in our scenarios. --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Christian Huitema [mailto:huitema@exchange.microsoft.com] Sent: Friday, May 11, 2001 10:59 AM To: Cedric Aoun; Midcom IETF (E-mail) Subject: [midcom] RE: Some comments on scenario draft The plan of record for IPv6 is indeed that you will not use address translation and IPv6; frankly, if you still used NAT, there would be little reason to move to IPv6 in the first place! What I point out in the scenario is, what changes when IPv6 gives you global addressing. You are right about discovery. The "signaling server" has to understand the location of the firewalls in order to open the proper holes. This is not in scope for MIDCOM the scenarios merely assume that discovery somehow happens, and that the server knows which firewall will be used. That should definitely work in the main cases, when there is exactly one firewall per domain, or maybe one firewall cluster. -- Christian Huitema=20 -----Original Message----- From: Cedric Aoun [mailto:CEDRIC.AOUN@nortelnetworks.com]=20 Sent: Friday, May 11, 2001 7:43 AM To: Christian Huitema; Midcom IETF (E-mail) Subject: Some comments on scenario draft Christian,=20 I have a couple of minor comments on the draft:=20 -I'm not quite sure that basic NAT (1 address to 1 address mapping) will be completely forgotten in IPv6, enterprises will still would like to have a certain independence from their ISP since the used addresses are provided by the ISP and they don't want to change their addresses when they change their ISP. -In big corporations we could have a lot of cases where the signaling flow will traverse a different Middle box than the bearer path, this is a realistic scenario. It won't happen for residential customers and SME (might happen) but for big corporations having several gateways it will happen. I know that middle box discovery is out of scope of the workgroup, and that is the main reason why this scenario is not in your draft but I think it is worth to note it.=20 I'm sure that other people in the list are interested in this scenario as well.=20 Feedback is welcomed=20 Regards=20 Cedric Aoun=20 Nortel Networks=20 33, quai Paul Doumer=20 Paris La Defense=20 92415 Courbevoie Cedex France=20 Gsm +33 6 85 74 43 04=20 Fax=A0 +33 1 46215598=20 cedric.aoun@nortelnetworks.com=20 _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C0DA42.1A1ABFD2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] RE: Some comments on scenario draft

Regardless of the plan of record, it seems quite clear = that most enterprises have countless reasons to stick with IPv4 in their = network core for decades. Moving to IPv6, as experience in the = Asia-Pacific region bears out, is fundamentally a function of address = space (at least that's what is driving this today). Hence, it will be a = mistake not to assume that an IPv4 core to IPv6 edge won't be a commonly = deployed topology over the next decade at least.

Perhaps this is beyond the scope of midcom. But we = need to be very careful about our assumptions here. Does midcom today = make any assumptions with respect to v4 <-> v6 transit? Correct me = if I'm wrong, but I believe this is merely an issue of capturing = scenarios at this point. Nevertheless, I think Cedric raises some valid = issues worth addressing in our scenarios.

--Andy Zmolek
    Technology & Standards = Engineer
      CTO Standards
        Avaya = Inc.

          &nbs= p; zmolek@avaya.com
          &nbs= p;   +1 720 444 4001


-----Original Message-----
From: Christian Huitema [mailto:huitema@exchange.mi= crosoft.com]
Sent: Friday, May 11, 2001 10:59 AM
To: Cedric Aoun; Midcom IETF (E-mail)
Subject: [midcom] RE: Some comments on scenario = draft


The plan of record for IPv6 is indeed that you will = not use address
translation and IPv6; frankly, if you still used NAT, = there would be
little reason to move to IPv6 in the first place! = What I point out in
the scenario is, what changes when IPv6 gives you = global addressing.

You are right about discovery. The "signaling = server" has to understand
the location of the firewalls in order to open the = proper holes. This is
not in scope for MIDCOM the scenarios merely assume = that discovery
somehow happens, and that the server knows which = firewall will be used.
That should definitely work in the main cases, when = there is exactly one
firewall per domain, or maybe one firewall = cluster.

-- Christian Huitema

-----Original Message-----
From: Cedric Aoun [mailto:CEDRIC.AOUN@norteln= etworks.com]
Sent: Friday, May 11, 2001 7:43 AM
To: Christian Huitema; Midcom IETF (E-mail)
Subject: Some comments on scenario draft

Christian,
I have a couple of minor comments on the draft: =
-I'm not quite sure that basic NAT (1 address to 1 = address mapping) will
be completely forgotten in IPv6, enterprises will = still would like to
have a certain independence from their ISP since the = used addresses are
provided by the ISP and they don't want to change = their addresses when
they change their ISP.
-In big corporations we could have a lot of cases = where the signaling
flow will traverse a different Middle box than the = bearer path, this is
a realistic scenario.
It won't happen for residential customers and SME = (might happen) but for
big corporations having several gateways it will = happen.
I know that middle box discovery is out of scope of = the workgroup, and
that is the main reason why this scenario is not in = your draft but I
think it is worth to
note it.
I'm sure that other people in the list are interested = in this scenario
as well.
Feedback is welcomed
Regards
Cedric Aoun
Nortel Networks
33, quai Paul Doumer
Paris La Defense
92415 Courbevoie Cedex France
Gsm +33 6 85 74 43 04
Fax=A0 +33 1 46215598
cedric.aoun@nortelnetworks.com


_______________________________________________
midcom mailing list
midcom@ietf.org
http://www.ietf.org/= mailman/listinfo/midcom

------_=_NextPart_001_01C0DA42.1A1ABFD2-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 13:50:26 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 NAA16939 for ; Fri, 11 May 2001 13:50:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26203; Fri, 11 May 2001 13:48:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26168 for ; Fri, 11 May 2001 13:48:42 -0400 (EDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16891 for ; Fri, 11 May 2001 13:48:35 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id MAA29366 for ; Fri, 11 May 2001 12:48:53 -0500 (CDT) Received: from zrchb213.us.nortel.com by smtprch2.nortel.com; Fri, 11 May 2001 12:42:37 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 May 2001 12:48:02 -0500 Message-ID: <63E0DAD7784FD21188310000F80824B30660CAC2@zmpkdx02.us.nortel.com> From: "Francois Audet" To: "'Christian Huitema'" , "Cedric Aoun" , "'Midcom IETF (E-mail)'" Subject: RE: [midcom] RE: Some comments on scenario draft Date: Fri, 11 May 2001 12:48:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DA42.857AAD00" X-Orig: 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_01C0DA42.857AAD00 Content-Type: text/plain; charset="iso-8859-1" > The plan of record for IPv6 is indeed that you will not use address > translation and IPv6; frankly, if you still used NAT, there would be > little reason to move to IPv6 in the first place! What I point out in > the scenario is, what changes when IPv6 gives you global addressing. I'm afraid that if ISPs charge per IP address, there will continue to be NATs. ------_=_NextPart_001_01C0DA42.857AAD00 Content-Type: text/html; charset="iso-8859-1" RE: [midcom] RE: Some comments on scenario draft

> The plan of record for IPv6 is indeed that you will not use address
> translation and IPv6; frankly, if you still used NAT, there would be
> little reason to move to IPv6 in the first place! What I point out in
> the scenario is, what changes when IPv6 gives you global addressing.

I'm afraid that if ISPs charge per IP address, there will continue to be
NATs.
 

------_=_NextPart_001_01C0DA42.857AAD00-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 14:36:20 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 OAA17936 for ; Fri, 11 May 2001 14:36:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26968; Fri, 11 May 2001 14:28:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26937 for ; Fri, 11 May 2001 14:28:49 -0400 (EDT) Received: from web13806.mail.yahoo.com ([216.136.175.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17806 for ; Fri, 11 May 2001 14:28:41 -0400 (EDT) Message-ID: <20010511182847.73011.qmail@web13806.mail.yahoo.com> Received: from [65.12.33.187] by web13806.mail.yahoo.com; Fri, 11 May 2001 11:28:47 PDT Date: Fri, 11 May 2001 11:28:47 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] RE: Some comments on scenario draft To: Christian Huitema , Cedric Aoun , "Midcom IETF \(E-mail\)" In-Reply-To: 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 --- Christian Huitema wrote: > The plan of record for IPv6 is indeed that you will not use address > translation and IPv6; frankly, if you still used NAT, there would be > little reason to move to IPv6 in the first place! What I point out in > the scenario is, what changes when IPv6 gives you global addressing. Christian - I do not agree with your assertion above and a similar comment made in section 2.4. NAT-PT plays an important role in v6 transition strategy. NAT-PT is the only means of communication between V6-only hosts and V4-only hosts. I believe, the intoduction of V6 and V6 transition mechanisms in this document is a diversion to the main theme and would not suggest this to be part of this document. 6-to-4 router is neither a middlebox nor a MIDCOM agent nor an application we are trying to facilitate using the MIDCOM protocol. In that case, why not simply limit the illustrations to v4 hosts (or) v6 hosts only? Including IPv6 transition mechanism into the document serves no purpose in illustrating the MIDCOM protocol scenario. I believe, the entire section 2.4, with the exception of section 2.4.5, is not required. Unless you insist on including a V6-only network scenario, I would suggest replacing the reference to V6 hosts with V4 hosts in section 2.4.5 - as section 2.4.5 illustrates IPsec/IKE traversal scenario irrespective of whether both end-hosts are V6-only (or) V4-only. Regards, suresh __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 15:30:57 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 PAA18794 for ; Fri, 11 May 2001 15:30:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28027; Fri, 11 May 2001 15:26:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27996 for ; Fri, 11 May 2001 15:26:15 -0400 (EDT) Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18671 for ; Fri, 11 May 2001 15:26:07 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f4BJPfd13371; Fri, 11 May 2001 12:25:41 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn-457.cisco.com [10.21.65.201]) by airborne.cisco.com (Mirapoint) with SMTP id ABV09928; Fri, 11 May 2001 12:25:39 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Fri, 11 May 2001 15:25:37 -0400 Date: Fri, 11 May 2001 15:25:37 -0400 From: Scott Brim To: Melinda Shore Cc: Cedric Aoun , "'Christian Huitema'" , "Midcom IETF (E-mail)" Subject: Re: [midcom] Some comments on scenario draft Message-ID: <20010511152537.N1400@SBRIM-W2K> Mail-Followup-To: Scott Brim , Melinda Shore , Cedric Aoun , 'Christian Huitema' , "Midcom IETF (E-mail)" References: <9154CB41F208D5118DD200508BE39C300B8877@zjguc006.europe.nortel.com> <038601c0da3f$1c443200$d45904d1@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <038601c0da3f$1c443200$d45904d1@cisco.com>; from mshore@cisco.com on Fri, May 11, 2001 at 01:23:33PM -0400 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 Fri, May 11, 2001 at 01:23:33PM -0400, Melinda Shore wrote: > > It won't happen for residential customers and SME (might happen) but for big > > corporations having several gateways it will happen. > > I know that middle box discovery is out of scope of the workgroup, and that > > is the main reason why this scenario is not in your draft but I think it is > > worth to > > note it. > > It may be worth pointing out that while there's a discovery > (or location) component to what you're describing, it's > really a routing problem and it's rather difficult. > > Melinda Would you expect different middleboxes to have different routes available to them? I would think that if you have two middleboxes which both have the capabilities you're looking for, that the choice would mainly be one of load balancing. I have difficulty imagining two accessible middleboxes which wouldn't have the same routing. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 15:41:05 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 PAA19038 for ; Fri, 11 May 2001 15:41:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28366; Fri, 11 May 2001 15:38:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28337 for ; Fri, 11 May 2001 15:38:05 -0400 (EDT) Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19004 for ; Fri, 11 May 2001 15:37:57 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f4BJa4t03378; Fri, 11 May 2001 12:36:05 -0700 (PDT) Received: from spandex (rtp-vpn-167.cisco.com [10.82.192.167]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AFG02856; Fri, 11 May 2001 12:37:09 -0700 (PDT) Message-ID: <05f401c0da51$d25a18e0$d45904d1@cisco.com> From: "Melinda Shore" To: "Scott Brim" Cc: "Midcom IETF (E-mail)" References: <9154CB41F208D5118DD200508BE39C300B8877@zjguc006.europe.nortel.com> <038601c0da3f$1c443200$d45904d1@cisco.com> <20010511152537.N1400@SBRIM-W2K> Subject: Re: [midcom] Some comments on scenario draft Date: Fri, 11 May 2001 15:37:31 -0400 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 > Would you expect different middleboxes to have different routes > available to them? I would think that if you have two middleboxes which > both have the capabilities you're looking for, that the choice would > mainly be one of load balancing. I have difficulty imagining two > accessible middleboxes which wouldn't have the same routing. Not that kind of routing - the *other* kind of routing. In the case of VoIP, where you might have multiple gateways "owned" by a single call control server and that call control server is also functioning as a midcom agent, the call control server would need to know which middlebox to contact for which gateway. For large networks this is potentially pretty hairy. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 15:58: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 PAA19387 for ; Fri, 11 May 2001 15:58:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28557; Fri, 11 May 2001 15:55:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28528 for ; Fri, 11 May 2001 15:55:16 -0400 (EDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19330 for ; Fri, 11 May 2001 15:55:09 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA15291; Fri, 11 May 2001 15:54:45 -0400 (EDT) Message-Id: <200105111954.PAA15291@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pyda Srisuresh cc: Christian Huitema , Cedric Aoun , "Midcom IETF \(E-mail\)" Subject: Re: [midcom] RE: Some comments on scenario draft In-reply-to: Your message of "Fri, 11 May 2001 11:28:47 PDT." <20010511182847.73011.qmail@web13806.mail.yahoo.com> Date: Fri, 11 May 2001 15:54:45 -0400 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 Suresh, you are correct that NAT-PT and similar techniques involving address translation are necessary for interoperation between v4 and v4 hosts. nobody has suggested otherwise. however in order to avoid the interoperability problems caused by NATs it is imperative that no address translation occur when using IPv6 between v6-aware applications. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 16:23:57 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 QAA19915 for ; Fri, 11 May 2001 16:23:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29279; Fri, 11 May 2001 16:20:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29246 for ; Fri, 11 May 2001 16:20:39 -0400 (EDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19844 for ; Fri, 11 May 2001 16:20:31 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id QAA15455; Fri, 11 May 2001 16:16:49 -0400 (EDT) Message-Id: <200105112016.QAA15455@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pyda Srisuresh cc: Christian Huitema , Cedric Aoun , "Midcom IETF \(E-mail\)" Subject: Re: [midcom] RE: Some comments on scenario draft In-reply-to: Your message of "Fri, 11 May 2001 11:28:47 PDT." <20010511182847.73011.qmail@web13806.mail.yahoo.com> Date: Fri, 11 May 2001 16:16:49 -0400 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 > Including IPv6 transition mechanism into the document serves no purpose in > illustrating the MIDCOM protocol scenario. Suresh, I'm very puzzled by this statement. Is it your belief that middleboxes should not support untranslated IPv6 routing (including 6to4) in addition to any NAT or NAT-PT functions that they might support? Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 16:24: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 QAA19928 for ; Fri, 11 May 2001 16:24:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29014; Fri, 11 May 2001 16:05:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28981 for ; Fri, 11 May 2001 16:05:13 -0400 (EDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19554 for ; Fri, 11 May 2001 16:05:05 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id QAA15346; Fri, 11 May 2001 16:03:47 -0400 (EDT) Message-Id: <200105112003.QAA15346@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Francois Audet" cc: "'Christian Huitema'" , "Cedric Aoun" , "'Midcom IETF (E-mail)'" Subject: Re: [midcom] RE: Some comments on scenario draft In-reply-to: Your message of "Fri, 11 May 2001 12:48:00 CDT." <63E0DAD7784FD21188310000F80824B30660CAC2@zmpkdx02.us.nortel.com> Date: Fri, 11 May 2001 16:03:47 -0400 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 afraid that if ISPs charge per IP address, there will continue to be > NATs. with 6to4, even a single IPv4 address provides 2**80 IPv6 addresses, which is more than enough for most organizations. so I'd revise your statement to say: if ISPs charge more for a /48 in IPv6 than they do for a /32 in IPv4, there will continue to be 6to4 boxes. we should view NAT and v6 as complementary approaches rather than as competing ones. NAT gives you the ability to interoperate between v4 hosts even when there are not enough v4 addresses to go around; NAT-PT gives you the ability to interoperate between v4 and v4. v6 gives you the ability to address each host individually, which is essential to support applications that cannot work through NATs. I fully expect to find NAT, NAT-PT, and IPv6/6to4 in the same box, each handling different kinds of connections. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 16:29: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 QAA20048 for ; Fri, 11 May 2001 16:29:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29195; Fri, 11 May 2001 16:19:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29170 for ; Fri, 11 May 2001 16:19:01 -0400 (EDT) Received: from newdev.harvard.edu ([140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19785 for ; Fri, 11 May 2001 16:18:53 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id QAA23670 for midcom@ietf.org; Fri, 11 May 2001 16:18:58 -0400 (EDT) Date: Fri, 11 May 2001 16:18:58 -0400 (EDT) From: Scott Bradner Message-Id: <200105112018.QAA23670@newdev.harvard.edu> To: midcom@ietf.org Subject: Re: [midcom] RE: Some comments on scenario draft 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 > however in order to avoid the interoperability problems caused by NATs > it is imperative that no address translation occur when using IPv6 > between v6-aware applications. while it would clearly be good to avoid any such translations I fully expect that vendors will develop and sell such devices and that customers will buy them - for reasons such as the one already mentioned: some ISPs charge per IP address Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 16:30: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 QAA20072 for ; Fri, 11 May 2001 16:30:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29372; Fri, 11 May 2001 16:25:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29309 for ; Fri, 11 May 2001 16:25:03 -0400 (EDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19963 for ; Fri, 11 May 2001 16:24:56 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id PAA14558 for ; Fri, 11 May 2001 15:25:15 -0500 (CDT) Received: from zrchb213.us.nortel.com by smtprch2.nortel.com; Fri, 11 May 2001 15:18:56 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 May 2001 15:24:22 -0500 Message-ID: <63E0DAD7784FD21188310000F80824B30660CCE5@zmpkdx02.us.nortel.com> From: "Francois Audet" To: "'Keith Moore'" Cc: "'Christian Huitema'" , "Cedric Aoun" , "'Midcom IETF (E-mail)'" Subject: RE: [midcom] RE: Some comments on scenario draft Date: Fri, 11 May 2001 15:24:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DA58.5C165AC0" X-Orig: 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_01C0DA58.5C165AC0 Content-Type: text/plain; charset="iso-8859-1" The case I was thinking about is the residential user which want his multiple PCs to access the network, but wants to pay for one address. > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Friday, May 11, 2001 1:04 PM > To: Audet, Francois [SC2:4K02:EXCH] > Cc: 'Christian Huitema'; Aoun, Cedric [QPD:0000:EXCH]; 'Midcom IETF > (E-mail)' > Subject: Re: [midcom] RE: Some comments on scenario draft > > > > I'm afraid that if ISPs charge per IP address, there will > continue to be > > NATs. > > with 6to4, even a single IPv4 address provides 2**80 IPv6 addresses, > which is more than enough for most organizations. > > so I'd revise your statement to say: if ISPs charge more for a /48 in > IPv6 than they do for a /32 in IPv4, there will continue to be 6to4 > boxes. > > we should view NAT and v6 as complementary approaches rather than as > competing ones. NAT gives you the ability to interoperate between > v4 hosts even when there are not enough v4 addresses to go around; > NAT-PT gives you the ability to interoperate between v4 and v4. > v6 gives you the ability to address each host individually, which is > essential to support applications that cannot work through NATs. > > I fully expect to find NAT, NAT-PT, and IPv6/6to4 in the same box, > each handling different kinds of connections. > > Keith > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C0DA58.5C165AC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] RE: Some comments on scenario draft

The case I was thinking about is the residential user = which want
his multiple PCs to access the network, but wants to = pay for one
address.

> -----Original Message-----
> From: Keith Moore [mailto:moore@cs.utk.edu]
> Sent: Friday, May 11, 2001 1:04 PM
> To: Audet, Francois [SC2:4K02:EXCH]
> Cc: 'Christian Huitema'; Aoun, Cedric = [QPD:0000:EXCH]; 'Midcom IETF
> (E-mail)'
> Subject: Re: [midcom] RE: Some comments on = scenario draft
>
>
> > I'm afraid that if ISPs charge per IP = address, there will
> continue to be
> > NATs.
>
> with 6to4, even a single IPv4 address provides = 2**80 IPv6 addresses,
> which is more than enough for most = organizations. 
>
> so I'd revise your statement to say: if ISPs = charge more for a /48 in
> IPv6 than they do for a /32 in IPv4, there will = continue to be 6to4
> boxes.
>
> we should view NAT and v6 as complementary = approaches rather than as
> competing ones.  NAT gives you the ability = to interoperate between
> v4 hosts even when there are not enough v4 = addresses to go around;
> NAT-PT gives you the ability to interoperate = between v4 and v4.
> v6 gives you the ability to address each host = individually, which is
> essential to support applications that cannot = work through NATs.
>
> I fully expect to find NAT, NAT-PT, and = IPv6/6to4 in the same box,
> each handling different kinds of = connections.
>
> Keith
>
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www.ietf.org/mailman/listinfo/midcom=
>

------_=_NextPart_001_01C0DA58.5C165AC0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 16:33: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 QAA20168 for ; Fri, 11 May 2001 16:33:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29683; Fri, 11 May 2001 16:30:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29654 for ; Fri, 11 May 2001 16:30:23 -0400 (EDT) Received: from newdev.harvard.edu ([140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20066 for ; Fri, 11 May 2001 16:30:14 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id QAA23782 for midcom@ietf.org; Fri, 11 May 2001 16:30:20 -0400 (EDT) Date: Fri, 11 May 2001 16:30:20 -0400 (EDT) From: Scott Bradner Message-Id: <200105112030.QAA23782@newdev.harvard.edu> To: midcom@ietf.org Subject: Re: [midcom] RE: Some comments on scenario draft 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 > with 6to4, even a single IPv4 address provides 2**80 IPv6 addresses, > which is more than enough for most organizations. from RFC 3056 The mechanism is intended as a start-up transition tool used during the period of co-existence of IPv4 and IPv6. It is not intended as a permanent solution. is 6to4 now being seen as a permanent solution? Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 16:42: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 QAA20255 for ; Fri, 11 May 2001 16:42:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29818; Fri, 11 May 2001 16:38:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29788 for ; Fri, 11 May 2001 16:38:21 -0400 (EDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20208 for ; Fri, 11 May 2001 16:38:13 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id QAA15531; Fri, 11 May 2001 16:35:18 -0400 (EDT) Message-Id: <200105112035.QAA15531@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Francois Audet" cc: "'Keith Moore'" , "'Christian Huitema'" , "Cedric Aoun" , "'Midcom IETF (E-mail)'" Subject: Re: [midcom] RE: Some comments on scenario draft In-reply-to: Your message of "Fri, 11 May 2001 15:24:20 CDT." <63E0DAD7784FD21188310000F80824B30660CCE5@zmpkdx02.us.nortel.com> Date: Fri, 11 May 2001 16:35:18 -0400 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 case I was thinking about is the residential user which want > his multiple PCs to access the network, but wants to pay for one > address. sure. so he pays for one IPv4 address and uses 6to4 to tunnel up to 2**80 IPv6 addresses to and from that IPv4 endpoint. ISPs that provide native IPv6 will be encouraged to provide a minimum allocation of /48 to every IPv6 customer. But if they don't provide this minimum allocation, or if they charge more for an IPv6 /48 than for a single IPv4 address, the customer will just get his IPv6 access using 6to4 - much as that same customer gets multiple host IPv4 access through NAT today. Also, if the address registries do the right thing, IPv6 addresses will be cheaper and far less scare than IPv4 addresses. So the ISP will have less incentive to charge per-address in IPv6 than in IPv4. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 17:18:53 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 RAA20815 for ; Fri, 11 May 2001 17:18:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00417; Fri, 11 May 2001 17:13:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00386 for ; Fri, 11 May 2001 17:13:25 -0400 (EDT) Received: from corb.mc.mpls.visi.com ([208.42.156.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20733 for ; Fri, 11 May 2001 17:13:16 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id C9C6381AB for ; Fri, 11 May 2001 15:49:22 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id QAA25372 for ; Fri, 11 May 2001 16:12:07 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Fri, 11 May 2001 16:12:07 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] RE: Some comments on scenario draft In-Reply-To: <200105112035.QAA15531@astro.cs.utk.edu> 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 It is safe to assume that some administrators will find it undesirable to expose the internal structure of their network in the IP addresses they send. We may cease to call that NATs, and rename them 'address anonymizers' or something, but they'll still replace at least some of the bits in MY IPv6 addresses with opaque cookies when they're flying around outside. It may no longer be necessary to overload port numbers as an address space expander, but it may wind up still being useful to anonymize port numbers as well. It doesn't actually matter whether these devices are a Good Idea or not, and it certainly doesn't matter if the IETF issues Stern Memos condemning their existence. Vendors will placidly implement them, and customers will just as placidly buy them, and it would be well to proceed assuming they will exist. This is, in my opinion, part of the reason for MIDCOM's existence -- to recognize and deal with this truth, be it a sad and horrible truth, or a fine and glorious one. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 17:26: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 RAA20952 for ; Fri, 11 May 2001 17:26:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00595; Fri, 11 May 2001 17:23:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00563 for ; Fri, 11 May 2001 17:23:44 -0400 (EDT) Received: from web13804.mail.yahoo.com ([216.136.175.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20902 for ; Fri, 11 May 2001 17:23:35 -0400 (EDT) Message-ID: <20010511212342.43068.qmail@web13804.mail.yahoo.com> Received: from [65.12.33.187] by web13804.mail.yahoo.com; Fri, 11 May 2001 14:23:42 PDT Date: Fri, 11 May 2001 14:23:42 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] RE: Some comments on scenario draft To: Keith Moore Cc: Christian Huitema , Cedric Aoun , "Midcom IETF \(E-mail\)" In-Reply-To: <200105111954.PAA15291@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: > Suresh, > > you are correct that NAT-PT and similar techniques involving address > translation are necessary for interoperation between v4 and v4 hosts. > nobody has suggested otherwise. May be not explicitly. But, there was a suggestion to that effect in Christian's e-mail and in section 2.4 of his MIDCOM-scenarios draft. For example, there was a statement that said that the use of NAT would simply disappear with the advent of IPv6 and that "Firewall/NAT" combination will simply turn into "firewall" only. Yet, there was reference to RFC 3056 and 6to4 scenarios (i.e., V6 transition tools) in a sentence right after this. Mentioning these 2 sentences (complete V6-only scenario and V6 transition scenario) in the same paragraph, yet having no reference to NAT-PT at best is misleading. Keith - the real point I was trying to get across was that the intoduction of V6 and V6 transition mechanisms in the MIDCOM-scenarios document seemed like a red-herring and a diversion from the main theme of the document. > > however in order to avoid the interoperability problems caused by NATs > it is imperative that no address translation occur when using IPv6 > between v6-aware applications. I agree. > > Keith regards, suresh ===== __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 17:38: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 RAA21108 for ; Fri, 11 May 2001 17:38:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00955; Fri, 11 May 2001 17:34:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00924 for ; Fri, 11 May 2001 17:34:36 -0400 (EDT) Received: from web13802.mail.yahoo.com ([216.136.175.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21059 for ; Fri, 11 May 2001 17:34:26 -0400 (EDT) Message-ID: <20010511213433.7575.qmail@web13802.mail.yahoo.com> Received: from [65.12.33.187] by web13802.mail.yahoo.com; Fri, 11 May 2001 14:34:33 PDT Date: Fri, 11 May 2001 14:34:33 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] RE: Some comments on scenario draft To: Keith Moore Cc: Christian Huitema , Cedric Aoun , "Midcom IETF \(E-mail\)" In-Reply-To: <200105112016.QAA15455@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: > > Including IPv6 transition mechanism into the document serves no purpose in > > illustrating the MIDCOM protocol scenario. > > Suresh, > > I'm very puzzled by this statement. Is it your belief that middleboxes > should not support untranslated IPv6 routing (including 6to4) in addition > to any NAT or NAT-PT functions that they might support? > Thats not at all what I am saying. I am saying that support of an untranslated V6 datagrams is orthogonal to the middlebox definition. An intermediate device does not get to be called a "middlebox" merely by virtue of transiting v4-traffic or V6-traffic. A middlebox has application spcific processing requirements, in addition. For this reason, I dont believe, it is necessary to mention IPv6 transition mechanisms in illustrating the MIDCOM protocol scenario. > Keith regards, suresh __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 17:45:17 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 RAA21263 for ; Fri, 11 May 2001 17:45:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01042; Fri, 11 May 2001 17:39:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01017 for ; Fri, 11 May 2001 17:39:56 -0400 (EDT) Received: from china.com (TCE-E-7-182-12.bta.net.cn [202.106.182.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21140 for ; Fri, 11 May 2001 17:39:49 -0400 (EDT) Received: from china.com([10.1.7.101]) by china.com(AIMC 2.9.5.1) with SMTP id jm43afc6f67; Sat, 12 May 2001 05:39:43 +0800 Received: from loki.ietf.org([132.151.1.177]) by china.com(AIMC 2.9.5.1) with SMTP id jmcc3afbb93a; Fri, 11 May 2001 14:39:04 +0800 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA06854 for ietf-123-outbound.02@ietf.org; Mon, 7 May 2001 08:25:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA06051 for ; Mon, 7 May 2001 06:46:51 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05538; Mon, 7 May 2001 06:46:51 -0400 (EDT) Message-Id: <200105071046.GAA05538@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 07 May 2001 06:46:51 -0400 Subject: [midcom] I-D ACTION:draft-ietf-midcom-scenarios-01.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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : MIDCOM Scenarios Author(s) : C. Huitema Filename : draft-ietf-midcom-scenarios-01.txt Pages : 16 Date : 04-May-01 As trusted third parties are increasingly being asked to make policy decisions on behalf of the various entities participating in an application's operation, a need has developed for applications to be able to communicate their needs to the devices in the network that provide transport policy enforcement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-scenarios-01.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-ietf-midcom-scenarios-01.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-ietf-midcom-scenarios-01.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010504122307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-scenarios-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-scenarios-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010504122307.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 17:45:26 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 RAA21274 for ; Fri, 11 May 2001 17:45:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01113; Fri, 11 May 2001 17:42:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01080 for ; Fri, 11 May 2001 17:42:08 -0400 (EDT) Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21178 for ; Fri, 11 May 2001 17:42:01 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f4BLfg906971; Fri, 11 May 2001 14:41:42 -0700 (PDT) Received: from spandex (rtp-vpn-167.cisco.com [10.82.192.167]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AFG07746; Fri, 11 May 2001 14:41:35 -0700 (PDT) Message-ID: <068c01c0da63$306ad8a0$d45904d1@cisco.com> From: "Melinda Shore" To: "Pyda Srisuresh" Cc: "Midcom IETF (E-mail)" References: <20010511212342.43068.qmail@web13804.mail.yahoo.com> Subject: Re: [midcom] RE: Some comments on scenario draft Date: Fri, 11 May 2001 17:41:50 -0400 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 > Keith - the real point I was trying to get across was that the > intoduction of V6 and V6 transition mechanisms in the MIDCOM-scenarios > document seemed like a red-herring and a diversion from the main theme > of the document. It's not - it's explicitly in scope. Note that this document is not a working group deliverable and is intended to bring out architectural issues and requirements. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 17:53: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 RAA21415 for ; Fri, 11 May 2001 17:53:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01191; Fri, 11 May 2001 17:48:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01166 for ; Fri, 11 May 2001 17:48:36 -0400 (EDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21327 for ; Fri, 11 May 2001 17:48:29 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id RAA15889; Fri, 11 May 2001 17:48:17 -0400 (EDT) Message-Id: <200105112148.RAA15889@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pyda Srisuresh cc: Keith Moore , Christian Huitema , Cedric Aoun , "Midcom IETF \(E-mail\)" Subject: Re: [midcom] RE: Some comments on scenario draft In-reply-to: Your message of "Fri, 11 May 2001 14:23:42 PDT." <20010511212342.43068.qmail@web13804.mail.yahoo.com> Date: Fri, 11 May 2001 17:48:17 -0400 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 > May be not explicitly. But, there was a suggestion to that effect in > Christian's e-mail and in section 2.4 of his MIDCOM-scenarios draft. > For example, there was a statement that said that the use of NAT would > simply disappear with the advent of IPv6 and that "Firewall/NAT" > combination will simply turn into "firewall" only. perhaps eventually. but I don't think anybody thinks this will happen immediately, or for many years. in other words it won't be the "advent" of IPv6 that brings this about - it will only happen (if ever) after IPv6 is so widely deployed that IPv4 is redundant. (much as DECnet phase IV has become so redundant that nobody cares about PMR anymore) > Yet, there was > reference to RFC 3056 and 6to4 scenarios (i.e., V6 transition tools) > in a sentence right after this. Mentioning these 2 sentences (complete > V6-only scenario and V6 transition scenario) in the same paragraph, > yet having no reference to NAT-PT at best is misleading. seems like NAT-PT at least deserves mention - a middlebox that can support NAT-PT ought to be able to control those mappings via midcom protocols just as much as one that supports NAT. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 17:58:56 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 RAA21581 for ; Fri, 11 May 2001 17:58:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01279; Fri, 11 May 2001 17:55:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01250 for ; Fri, 11 May 2001 17:55:36 -0400 (EDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21474 for ; Fri, 11 May 2001 17:55:30 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id RAA15932; Fri, 11 May 2001 17:54:59 -0400 (EDT) Message-Id: <200105112154.RAA15932@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pyda Srisuresh cc: Keith Moore , Christian Huitema , Cedric Aoun , "Midcom IETF \(E-mail\)" Subject: Re: [midcom] RE: Some comments on scenario draft In-reply-to: Your message of "Fri, 11 May 2001 14:34:33 PDT." <20010511213433.7575.qmail@web13802.mail.yahoo.com> Date: Fri, 11 May 2001 17:54:59 -0400 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 seems like the very purpose of a scenarios document is to envision possibilities, and this requires casting a wide net. indeed, part of the point is to examine things that are on the edge of, and perhaps even outside of the intended scope of midcom protocols, just to see if there are any interactions that need to be considered in the design of those protocols. it would be bad if midcom somehow introduced additional barriers to an IPv6 transition. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 18:02:52 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 SAA21629 for ; Fri, 11 May 2001 18:02:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01356; Fri, 11 May 2001 17:59:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01331 for ; Fri, 11 May 2001 17:59:19 -0400 (EDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21601 for ; Fri, 11 May 2001 17:59:12 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id RAA15977; Fri, 11 May 2001 17:59:18 -0400 (EDT) Message-Id: <200105112159.RAA15977@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Scott Bradner cc: midcom@ietf.org Subject: Re: [midcom] RE: Some comments on scenario draft In-reply-to: Your message of "Fri, 11 May 2001 16:30:20 EDT." <200105112030.QAA23782@newdev.harvard.edu> Date: Fri, 11 May 2001 17:59:17 -0400 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 > is 6to4 now being seen as a permanent solution? certainly not in my mind. realistically, people are going to use it as long as no better alternative is available. but I think there will be sufficient incentives for ISPs to deploy native IPv6 and make it available at reasonable prices. I don't see 6to4 as any more of a permanent solution than NAT. so you may as well ask, is NAT now being seen as a permanent solution? :) Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 18:12:22 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 SAA21830 for ; Fri, 11 May 2001 18:12:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01700; Fri, 11 May 2001 18:09:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01665 for ; Fri, 11 May 2001 18:09:28 -0400 (EDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21732 for ; Fri, 11 May 2001 18:09:20 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id SAA16028; Fri, 11 May 2001 18:09:26 -0400 (EDT) Message-Id: <200105112209.SAA16028@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Scott Bradner cc: midcom@ietf.org Subject: Re: [midcom] RE: Some comments on scenario draft In-reply-to: Your message of "Fri, 11 May 2001 16:18:58 EDT." <200105112018.QAA23670@newdev.harvard.edu> Date: Fri, 11 May 2001 18:09:26 -0400 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 > while it would clearly be good to avoid any such translations I fully > expect that vendors will develop and sell such devices and that > customers will buy them - for reasons such as the one already > mentioned: some ISPs charge per IP address if that happens we might as well just declare IPv6 dead, because we will have polluted IPv6 with all of the problems of NAT. the fact that this group has such difficult problems to solve should be evidence enough that we don't want this to happen. one of the major incentives to deploy IPv6 is to enable applications that cannot work through NATs. if ISPs charge for multiple IP addresses, when everyone is forced to use a NAT straitjacket for everything, will those ISPs also charge for other demultiplexing tags? like DNS names? I won't swear that they won't do it, but they would just be shooting themselves in the feet. IETF cannot ensure sanity but we can do the groundwork to take advantage of sanity if it should prevail, and we can encourage sanity to some degree. All of our investment in IPv6 is wasted if IPv6 is widely NATted. In order to attempt to preserve that investment we should declare that traffic between IPv6 hosts should not be NATted. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 18:22: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 SAA21981 for ; Fri, 11 May 2001 18:22:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01776; Fri, 11 May 2001 18:17:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01748 for ; Fri, 11 May 2001 18:17:21 -0400 (EDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21927 for ; Fri, 11 May 2001 18:17:14 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id SAA16123; Fri, 11 May 2001 18:17:20 -0400 (EDT) Message-Id: <200105112217.SAA16123@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Andrew Molitor cc: midcom@ietf.org Subject: Re: [midcom] RE: Some comments on scenario draft In-reply-to: Your message of "Fri, 11 May 2001 16:12:07 CDT." Date: Fri, 11 May 2001 18:17:20 -0400 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 > It is safe to assume that some administrators will find > it undesirable to expose the internal structure of their network > in the IP addresses they send. yes, I think that's true. but there are better ways to solve this problem than address translation. few organizations' telephone numbers expose the internal structure of their telephone networks. and yet many organizations have thousands of telephones that are directly reachable from outside, with globally-unique, consistent, addersses. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 19:15: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 TAA22751 for ; Fri, 11 May 2001 19:15:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02660; Fri, 11 May 2001 19:11:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02636 for ; Fri, 11 May 2001 19:11:28 -0400 (EDT) Received: from web13808.mail.yahoo.com ([216.136.175.18]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22641 for ; Fri, 11 May 2001 19:11:22 -0400 (EDT) Message-ID: <20010511231127.90472.qmail@web13808.mail.yahoo.com> Received: from [65.12.33.187] by web13808.mail.yahoo.com; Fri, 11 May 2001 16:11:27 PDT Date: Fri, 11 May 2001 16:11:27 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] RE: Some comments on scenario draft To: Melinda Shore Cc: "Midcom IETF \(E-mail\)" In-Reply-To: <068c01c0da63$306ad8a0$d45904d1@cisco.com> 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 --- Melinda Shore wrote: > > Keith - the real point I was trying to get across was that the > > intoduction of V6 and V6 transition mechanisms in the MIDCOM-scenarios > > document seemed like a red-herring and a diversion from the main theme > > of the document. > > It's not - it's explicitly in scope. Note that this > document is not a working group deliverable and is > intended to bring out architectural issues and requirements. > > Melinda > > What specifically are the new architectural issues and requirements (for MIDCOM) that came about as a result of illustrating the 6-to-4 V6 transition mechanism or a V6-only network? regards, suresh __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 19:34:52 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 TAA22864 for ; Fri, 11 May 2001 19:34:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03014; Fri, 11 May 2001 19:33:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02981 for ; Fri, 11 May 2001 19:33:36 -0400 (EDT) Received: from web13803.mail.yahoo.com ([216.136.175.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22860 for ; Fri, 11 May 2001 19:33:30 -0400 (EDT) Message-ID: <20010511233335.19152.qmail@web13803.mail.yahoo.com> Received: from [65.12.33.187] by web13803.mail.yahoo.com; Fri, 11 May 2001 16:33:35 PDT Date: Fri, 11 May 2001 16:33:35 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] RE: Some comments on scenario draft To: Keith Moore Cc: Christian Huitema , Cedric Aoun , "Midcom IETF \(E-mail\)" In-Reply-To: <200105112148.RAA15889@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: > > May be not explicitly. But, there was a suggestion to that effect in > > Christian's e-mail and in section 2.4 of his MIDCOM-scenarios draft. > > For example, there was a statement that said that the use of NAT would > > simply disappear with the advent of IPv6 and that "Firewall/NAT" > > combination will simply turn into "firewall" only. > > perhaps eventually. but I don't think anybody thinks this will happen > immediately, or for many years. in other words it won't be the "advent" > of IPv6 that brings this about - it will only happen (if ever) after > IPv6 is so widely deployed that IPv4 is redundant. (much as DECnet > phase IV has become so redundant that nobody cares about PMR anymore) > Sure, I agree. > > Yet, there was > > reference to RFC 3056 and 6to4 scenarios (i.e., V6 transition tools) > > in a sentence right after this. Mentioning these 2 sentences (complete > > V6-only scenario and V6 transition scenario) in the same paragraph, > > yet having no reference to NAT-PT at best is misleading. > > seems like NAT-PT at least deserves mention - a middlebox that can > support NAT-PT ought to be able to control those mappings via midcom > protocols just as much as one that supports NAT. I agree. Perhaps, NAT-PT is the only V6-transition entity that will fit the definition of a middlebox. The WG focus so far has been limited to Firewalls and V4-NAT. Perhaps the WG will beneft if the scenarios document included a NAT-PT based middlebox scenario. > > Keith Thanks. regards, suresh __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 19:54:30 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 TAA23064 for ; Fri, 11 May 2001 19:54:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03199; Fri, 11 May 2001 19:47:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03130 for ; Fri, 11 May 2001 19:47:47 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23024 for ; Fri, 11 May 2001 19:47:39 -0400 (EDT) Received: from 157.54.1.52 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 11 May 2001 13:38:24 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 11 May 2001 13:40:01 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 11 May 2001 13:40:01 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 11 May 2001 13:39:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4688.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DA5A.8B117B2D" Subject: RE: [midcom] RE: Some comments on scenario draft Date: Fri, 11 May 2001 13:39:58 -0700 Message-ID: Thread-Topic: [midcom] RE: Some comments on scenario draft Thread-Index: AcDaWf8Ay1VZsLBcSZGWiJkDO/KgwQAAFMww From: "Christian Huitema" To: "Francois Audet" , "Keith Moore" Cc: "Cedric Aoun" , "Midcom IETF (E-mail)" X-OriginalArrivalTime: 11 May 2001 20:39:58.0542 (UTC) FILETIME=[8B4DD6E0:01C0DA5A] 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 a multi-part message in MIME format. ------_=_NextPart_001_01C0DA5A.8B117B2D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Even a single PC is expected to use multiple IPv6 addresses, if you turn on privacy protection. We fully expect that home users will receive a prefix, not a single address. =20 -----Original Message----- From: Francois Audet [mailto:audet@nortelnetworks.com]=20 Sent: Friday, May 11, 2001 1:24 PM To: 'Keith Moore' Cc: Christian Huitema; Cedric Aoun; 'Midcom IETF (E-mail)' Subject: RE: [midcom] RE: Some comments on scenario draft =20 The case I was thinking about is the residential user which want=20 his multiple PCs to access the network, but wants to pay for one=20 address.=20 > -----Original Message-----=20 > From: Keith Moore [mailto:moore@cs.utk.edu]=20 > Sent: Friday, May 11, 2001 1:04 PM=20 > To: Audet, Francois [SC2:4K02:EXCH]=20 > Cc: 'Christian Huitema'; Aoun, Cedric [QPD:0000:EXCH]; 'Midcom IETF=20 > (E-mail)'=20 > Subject: Re: [midcom] RE: Some comments on scenario draft=20 >=20 >=20 > > I'm afraid that if ISPs charge per IP address, there will=20 > continue to be=20 > > NATs.=20 >=20 > with 6to4, even a single IPv4 address provides 2**80 IPv6 addresses,=20 > which is more than enough for most organizations. =20 >=20 > so I'd revise your statement to say: if ISPs charge more for a /48 in=20 > IPv6 than they do for a /32 in IPv4, there will continue to be 6to4=20 > boxes.=20 >=20 > we should view NAT and v6 as complementary approaches rather than as=20 > competing ones. NAT gives you the ability to interoperate between=20 > v4 hosts even when there are not enough v4 addresses to go around;=20 > NAT-PT gives you the ability to interoperate between v4 and v4.=20 > v6 gives you the ability to address each host individually, which is=20 > essential to support applications that cannot work through NATs.=20 >=20 > I fully expect to find NAT, NAT-PT, and IPv6/6to4 in the same box,=20 > each handling different kinds of connections.=20 >=20 > Keith=20 >=20 > _______________________________________________=20 > midcom mailing list=20 > midcom@ietf.org=20 > http://www.ietf.org/mailman/listinfo/midcom=20 >=20 ------_=_NextPart_001_01C0DA5A.8B117B2D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [midcom] RE: Some comments on scenario draft

Even a single PC is expected to use multiple IPv6 addresses, if you turn on privacy protection. We fully = expect that home users will receive a prefix, not a single = address.

 

-----Original Message-----
From: Francois Audet [mailto:audet@nortelnetworks.com]
Sent: Friday, May 11, = 2001 1:24 PM
To: 'Keith Moore'
Cc: Christian Huitema; = Cedric Aoun; 'Midcom IETF (E-mail)'
Subject: RE: [midcom] RE: = Some comments on scenario draft

 

The case I was thinking about is the residential user which want =
his multiple PCs to = access the network, but wants to pay for one
address. =

> -----Original Message-----
> From: Keith Moore = [mailto:moore@cs.utk.edu]
> Sent: Friday, May = 11, 2001 1:04 PM
> To: Audet, Francois [SC2:4K02:EXCH]
> Cc: 'Christian = Huitema'; Aoun, Cedric [QPD:0000:EXCH]; 'Midcom IETF
> = (E-mail)'
> Subject: Re: = [midcom] RE: Some comments on scenario draft
>
>
> > I'm afraid = that if ISPs charge per IP address, there will
> continue to = be
> > = NATs.
>
> with 6to4, even a = single IPv4 address provides 2**80 IPv6 addresses,
> which is more than = enough for most organizations. 
>
> so I'd revise your = statement to say: if ISPs charge more for a /48 in
> IPv6 than they do = for a /32 in IPv4, there will continue to be 6to4
> = boxes.
>
> we should view NAT = and v6 as complementary approaches rather than as
> competing = ones.  NAT gives you the ability to interoperate between
> v4 hosts even when = there are not enough v4 addresses to go around;
> NAT-PT gives you = the ability to interoperate between v4 and v4.
> v6 gives you the = ability to address each host individually, which is
> essential to = support applications that cannot work through NATs.
>
> I fully expect to = find NAT, NAT-PT, and IPv6/6to4 in the same box,
> each handling = different kinds of connections.
>
> Keith =
>
> _______________________________________________
> midcom mailing = list
> = midcom@ietf.org
> http://www.ietf.org/mailman/listinfo/midcom<= /font>
>

=00 ------_=_NextPart_001_01C0DA5A.8B117B2D-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 21:16:27 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 VAA23793 for ; Fri, 11 May 2001 21:16:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA04680; Fri, 11 May 2001 21:15:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA04655 for ; Fri, 11 May 2001 21:15:21 -0400 (EDT) Received: from mail5.microsoft.com ([131.107.3.121]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23790 for ; Fri, 11 May 2001 21:15:14 -0400 (EDT) Received: from 157.54.9.101 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 11 May 2001 18:01:12 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 11 May 2001 18:00:24 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 11 May 2001 18:00:14 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 11 May 2001 18:00:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4688.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] RE: Some comments on scenario draft Date: Fri, 11 May 2001 18:00:10 -0700 Message-ID: Thread-Topic: [midcom] RE: Some comments on scenario draft Thread-Index: AcDadZy7rFi04ZkoQJCIzA/rCTTWMwACMpqQ From: "Christian Huitema" To: "Pyda Srisuresh" , "Melinda Shore" Cc: "Midcom IETF (E-mail)" X-OriginalArrivalTime: 12 May 2001 01:00:11.0049 (UTC) FILETIME=[E5155990:01C0DA7E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id VAA04656 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 > From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] > > > What specifically are the new architectural issues and requirements > (for MIDCOM) that came about as a result of illustrating the 6-to-4 > V6 transition mechanism or a V6-only network? Requirement to handle v6 addresses in the midcom protocol; Requirement to enable firewall traversal even if no mapping function is performed (also applies to firewalled networks with global IPv4 addresses, which are not so rare.) Requirement to enable traversal for other payload types than UDP and TCP, two examples being protocol type 41, used for IPv6 tunnelling (6to4 and other), as well as AH and ESP. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 11 22:15:22 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 WAA25488 for ; Fri, 11 May 2001 22:15:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA05871; Fri, 11 May 2001 22:13:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA05842 for ; Fri, 11 May 2001 22:13:50 -0400 (EDT) Received: from web13801.mail.yahoo.com ([216.136.175.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA25433 for ; Fri, 11 May 2001 22:13:42 -0400 (EDT) Message-ID: <20010512021349.28890.qmail@web13801.mail.yahoo.com> Received: from [65.12.33.187] by web13801.mail.yahoo.com; Fri, 11 May 2001 19:13:49 PDT Date: Fri, 11 May 2001 19:13:49 -0700 (PDT) From: Pyda Srisuresh Subject: RE: [midcom] RE: Some comments on scenario draft To: Christian Huitema , Melinda Shore Cc: "Midcom IETF \(E-mail\)" In-Reply-To: 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 --- Christian Huitema wrote: > > From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] > > > > > What specifically are the new architectural issues and requirements > > (for MIDCOM) that came about as a result of illustrating the 6-to-4 > > V6 transition mechanism or a V6-only network? > > Requirement to handle v6 addresses in the midcom protocol; Agreed. But, this is orthogonal to 6-to-4 transition mechanism. An obvious requirement when the resources and sessions are V6 based. > Requirement to enable firewall traversal even if no mapping function is > performed (also applies to firewalled networks with global IPv4 > addresses, which are not so rare.) Sorry, I dont understand this. What is the mapping function you are refering to? > Requirement to enable traversal for other payload types than UDP and > TCP, two examples being protocol type 41, used for IPv6 tunnelling (6to4 > and other), as well as AH and ESP. > Support for protocols other than TCP and UDP is a requirement that is very apparent, with or without the V6 illustration. > -- Christian Huitema If you wanted to mention about the requirement for support for V6 addresses, that did not require a whole section on V6 and a transition mechanism. Oh, well, sorry to have been a pest. Hope you understand. Thanks. Regards, suresh ===== __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sat May 12 07:54: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 HAA15400 for ; Sat, 12 May 2001 07:54:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20094; Sat, 12 May 2001 07:45:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20063 for ; Sat, 12 May 2001 07:45:02 -0400 (EDT) Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15283 for ; Sat, 12 May 2001 07:44:54 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f4CBiUd21355; Sat, 12 May 2001 04:44:30 -0700 (PDT) Received: from spandex (rtp-vpn-65.cisco.com [10.82.192.65]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AFH05698; Sat, 12 May 2001 04:44:27 -0700 (PDT) Message-ID: <002401c0dad8$f6855c20$d45904d1@cisco.com> From: "Melinda Shore" To: "Pyda Srisuresh" Cc: "Midcom IETF (E-mail)" References: <20010511233335.19152.qmail@web13803.mail.yahoo.com> Subject: Re: [midcom] RE: Some comments on scenario draft Date: Sat, 12 May 2001 07:44:53 -0400 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 agree. Perhaps, NAT-PT is the only V6-transition entity that will > fit the definition of a middlebox. The WG focus so far has been > limited to Firewalls and V4-NAT. If it has it's been because of an oversight. We talked about v4<->v6 during the chartering process. It's in scope. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sun May 13 03:44:48 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 DAA05695 for ; Sun, 13 May 2001 03:44:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA09934; Sun, 13 May 2001 03:39:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA09904 for ; Sun, 13 May 2001 03:39:50 -0400 (EDT) Received: from internaut.com ([64.38.134.99]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04980 for ; Sun, 13 May 2001 03:39:43 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id AAA20244; Sun, 13 May 2001 00:31:13 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Sun, 13 May 2001 00:31:13 -0700 (PDT) From: Bernard Aboba To: Scott Bradner cc: midcom@ietf.org Subject: Re: [midcom] RE: Some comments on scenario draft In-Reply-To: <200105112018.QAA23670@newdev.harvard.edu> 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 > while it would clearly be good to avoid any such translations I fully > expect that vendors will develop and sell such devices and that > customers will buy them - for reasons such as the one already > mentioned: some ISPs charge per IP address I am sad to say that you're probably right. For example, I'm told that dialup ISPs are likely to assign /128s to users even though we would probably like them to assign /64s or /48s, just because IPv4 behavior will carry over (use of addresses as a value pricing mechanism, fear of routing headaches, difficulty in administering both prefix assignment & route plumbing consistently, etc.). To get this right needs a change in mindset as much as a new code loads. Value pricing is a very powerful force that has consumed more than its share of technically good ideas. Probably the best we can hope for is to address the technical issues thoroughly and make enough information available that those so inclined can use what's available if they're so inclined. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon May 14 08:26: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 IAA08415 for ; Mon, 14 May 2001 08:26:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07680; Mon, 14 May 2001 08:19:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07650 for ; Mon, 14 May 2001 08:19:14 -0400 (EDT) Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08160 for ; Mon, 14 May 2001 08:19:05 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4ECInU26811 for ; Mon, 14 May 2001 05:18:49 -0700 (PDT) Received: from spandex (rtp-vpn-165.cisco.com [10.82.192.165]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AFI02315; Mon, 14 May 2001 05:18:23 -0700 (PDT) Message-ID: <02e601c0dc70$0acf9cc0$d45904d1@cisco.com> From: "Melinda Shore" To: Date: Mon, 14 May 2001 08:18:51 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_02E1_01C0DC4E.820B1CA0" 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 Subject: [midcom] Fw: I-D ACTION:draft-shore-midcom-apps-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 This is a multi-part message in MIME format. ------=_NextPart_000_02E1_01C0DC4E.820B1CA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit FYI. Melinda ----- Original Message ----- From: To: Sent: Monday, May 14, 2001 7:35 AM Subject: I-D ACTION:draft-shore-midcom-apps-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Application Considerations for Midcom Middleboxes > Author(s) : M. Shore > Filename : draft-shore-midcom-apps-00.txt > Pages : 8 > Date : 11-May-01 > > As an architecture is evolving around an interface > between middleboxes in the transport plane [Srisuresh] > and the applications which must traverse them, we need > to document the implications for applications. This > documentation is intended both to provide guidance for > application designers and to help network architects > come to a better understanding of sources of complexity > in our networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-shore-midcom-apps-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-shore-midcom-apps-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-shore-midcom-apps-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. > ------=_NextPart_000_02E1_01C0DC4E.820B1CA0 Content-Type: application/octet-stream; name="ATT00732.dat" Content-Disposition: attachment; filename="ATT00732.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20010511094232.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shore-midcom-apps-00.txt ------=_NextPart_000_02E1_01C0DC4E.820B1CA0 Content-Type: text/plain; name="draft-shore-midcom-apps-00.txt" Content-Disposition: attachment; filename="draft-shore-midcom-apps-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20010511094232.I-D@ietf.org> ------=_NextPart_000_02E1_01C0DC4E.820B1CA0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon May 14 11:44:30 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 LAA15674 for ; Mon, 14 May 2001 11:44:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11566; Mon, 14 May 2001 11:36:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11535 for ; Mon, 14 May 2001 11:36:37 -0400 (EDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15413 for ; Mon, 14 May 2001 11:36:28 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id LAA24551; Mon, 14 May 2001 11:36:33 -0400 (EDT) Message-Id: <200105141536.LAA24551@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Melinda Shore" cc: midcom@ietf.org Subject: Re: [midcom] Fw: I-D ACTION:draft-shore-midcom-apps-00.txt In-reply-to: Your message of "Mon, 14 May 2001 08:18:51 EDT." <02e601c0dc70$0acf9cc0$d45904d1@cisco.com> Date: Mon, 14 May 2001 11:36:33 -0400 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 Melinda, I strongly object to the notion that middleboxes are part of any kind of 'architecture'. They are a hack, nothing more. An architecture implies some aspect of overall design, making compromises between the needs of different facets of the design for the overall good. Such terminology does not apply to workarounds for the problems with NATs. Before this group was formed I tried to get it to work on a sound architecture for firewalls. That approach was soundly rejected in favor of the group working on short-term workarounds. It's disingenious and misleading to call this group's work any kind of architecture. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon May 14 13:43: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 NAA19516 for ; Mon, 14 May 2001 13:43:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13893; Mon, 14 May 2001 13:28:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13864 for ; Mon, 14 May 2001 13:28:56 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19064 for ; Mon, 14 May 2001 13:28:47 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA32206; Mon, 14 May 2001 18:28:23 +0100 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA20684; Mon, 14 May 2001 18:28:18 +0100 Message-ID: <3B0014F3.B31EB2A0@hursley.ibm.com> Date: Mon, 14 May 2001 12:25:07 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Pyda Srisuresh CC: Christian Huitema , Cedric Aoun , "Midcom IETF (E-mail)" Subject: Re: [midcom] RE: Some comments on scenario draft References: <20010511182847.73011.qmail@web13806.mail.yahoo.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 Pyda, I suspect that dual stack middleboxes themselves may prove to be very important means of communication between v6-only and v4-only hosts, making NAT-PT itself largely unnecessary. Whatever solutions midcom invents need to deal with all likely scenarios, however, so I think including v4/v6 coexistence in the scenarios is essential. Brian Pyda Srisuresh wrote: > > --- Christian Huitema wrote: > > The plan of record for IPv6 is indeed that you will not use address > > translation and IPv6; frankly, if you still used NAT, there would be > > little reason to move to IPv6 in the first place! What I point out in > > the scenario is, what changes when IPv6 gives you global addressing. > > Christian - I do not agree with your assertion above and a similar > comment made in section 2.4. NAT-PT plays an important role in v6 > transition strategy. NAT-PT is the only means of communication between > V6-only hosts and V4-only hosts. > > I believe, the intoduction of V6 and V6 transition mechanisms in this > document is a diversion to the main theme and would not suggest this > to be part of this document. 6-to-4 router is neither a middlebox nor > a MIDCOM agent nor an application we are trying to facilitate using the > MIDCOM protocol. In that case, why not simply limit the illustrations to > v4 hosts (or) v6 hosts only? > > Including IPv6 transition mechanism into the document serves no purpose in > illustrating the MIDCOM protocol scenario. I believe, the entire > section 2.4, with the exception of section 2.4.5, is not required. > Unless you insist on including a V6-only network scenario, I would suggest > replacing the reference to V6 hosts with V4 hosts in section 2.4.5 - as > section 2.4.5 illustrates IPsec/IKE traversal scenario irrespective > of whether both end-hosts are V6-only (or) V4-only. > > Regards, > suresh _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon May 14 14:15: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 OAA20286 for ; Mon, 14 May 2001 14:15:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14948; Mon, 14 May 2001 14:06:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14917 for ; Mon, 14 May 2001 14:06:08 -0400 (EDT) Received: from web13805.mail.yahoo.com ([216.136.175.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20132 for ; Mon, 14 May 2001 14:05:59 -0400 (EDT) Message-ID: <20010514180607.64396.qmail@web13805.mail.yahoo.com> Received: from [65.12.33.187] by web13805.mail.yahoo.com; Mon, 14 May 2001 11:06:07 PDT Date: Mon, 14 May 2001 11:06:07 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] RE: Some comments on scenario draft To: Brian E Carpenter Cc: Christian Huitema , Cedric Aoun , "Midcom IETF \(E-mail\)" In-Reply-To: <3B0014F3.B31EB2A0@hursley.ibm.com> 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 --- Brian E Carpenter wrote: > Pyda, > > I suspect that dual stack middleboxes themselves may prove to be very > important means of communication between v6-only and v4-only hosts, > making NAT-PT itself largely unnecessary. While dual-stack is a requirement, middlebox cannot do without NAT-PT for such a communication (between V6-only and V4-only end-hosts). > Whatever solutions midcom > invents need to deal with all likely scenarios, however, so I think > including v4/v6 coexistence in the scenarios is essential. OK. Thanks. > Brian > regards, suresh > Pyda Srisuresh wrote: > > > > --- Christian Huitema wrote: > > > The plan of record for IPv6 is indeed that you will not use address > > > translation and IPv6; frankly, if you still used NAT, there would be > > > little reason to move to IPv6 in the first place! What I point out in > > > the scenario is, what changes when IPv6 gives you global addressing. > > > > Christian - I do not agree with your assertion above and a similar > > comment made in section 2.4. NAT-PT plays an important role in v6 > > transition strategy. NAT-PT is the only means of communication between > > V6-only hosts and V4-only hosts. > > > > I believe, the intoduction of V6 and V6 transition mechanisms in this > > document is a diversion to the main theme and would not suggest this > > to be part of this document. 6-to-4 router is neither a middlebox nor > > a MIDCOM agent nor an application we are trying to facilitate using the > > MIDCOM protocol. In that case, why not simply limit the illustrations to > > v4 hosts (or) v6 hosts only? > > > > Including IPv6 transition mechanism into the document serves no purpose in > > illustrating the MIDCOM protocol scenario. I believe, the entire > > section 2.4, with the exception of section 2.4.5, is not required. > > Unless you insist on including a V6-only network scenario, I would suggest > > replacing the reference to V6 hosts with V4 hosts in section 2.4.5 - as > > section 2.4.5 illustrates IPsec/IKE traversal scenario irrespective > > of whether both end-hosts are V6-only (or) V4-only. > > > > Regards, > > suresh __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon May 14 14:43:24 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 OAA21171 for ; Mon, 14 May 2001 14:43:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15670; Mon, 14 May 2001 14:36:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15639 for ; Mon, 14 May 2001 14:36:12 -0400 (EDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20969 for ; Mon, 14 May 2001 14:36:03 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id OAA26097; Mon, 14 May 2001 14:34:38 -0400 (EDT) Message-Id: <200105141834.OAA26097@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian E Carpenter cc: Pyda Srisuresh , Christian Huitema , Cedric Aoun , "Midcom IETF (E-mail)" Subject: Re: [midcom] RE: Some comments on scenario draft In-reply-to: Your message of "Mon, 14 May 2001 12:25:07 CDT." <3B0014F3.B31EB2A0@hursley.ibm.com> Date: Mon, 14 May 2001 14:34:38 -0400 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 suspect that dual stack middleboxes themselves may prove to be very > important means of communication between v6-only and v4-only hosts, > making NAT-PT itself largely unnecessary. Brian, by "dual stack middleboxes" I take it you mean boxes that intercept traffic at layer 4 or higher, rather than NAT-PT which operates at layer 3? you may be right, but I hope not. NAT techniques are already disruptive enough - interfering with higher layers will just cause more problems. I'm curious as to why you think this. or if I've misunderstood what you meant, please clarify. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon May 14 15:18: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 PAA22179 for ; Mon, 14 May 2001 15:18:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16549; Mon, 14 May 2001 15:10:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16523 for ; Mon, 14 May 2001 15:10:37 -0400 (EDT) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21959 for ; Mon, 14 May 2001 15:10:28 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id MAA54498; Mon, 14 May 2001 12:09:58 -0700 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id MAA23250; Mon, 14 May 2001 12:10:02 -0700 Message-ID: <3B002C93.D79A5631@hursley.ibm.com> Date: Mon, 14 May 2001 14:05:55 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Keith Moore CC: Pyda Srisuresh , Christian Huitema , Cedric Aoun , "Midcom IETF (E-mail)" Subject: Re: [midcom] RE: Some comments on scenario draft References: <200105141834.OAA26097@astro.cs.utk.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 I believe that dual stack application level proxies and gateways will be the primary mode of interworking between IPv6-only networks and IPv4-only servers, for a large number of years. Brian Keith Moore wrote: > > > I suspect that dual stack middleboxes themselves may prove to be very > > important means of communication between v6-only and v4-only hosts, > > making NAT-PT itself largely unnecessary. > > Brian, > > by "dual stack middleboxes" I take it you mean boxes that intercept > traffic at layer 4 or higher, rather than NAT-PT which operates > at layer 3? you may be right, but I hope not. NAT techniques > are already disruptive enough - interfering with higher layers > will just cause more problems. > > I'm curious as to why you think this. or if I've misunderstood > what you meant, please clarify. > > Keith -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon May 14 15:20: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 PAA22248 for ; Mon, 14 May 2001 15:20:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16639; Mon, 14 May 2001 15:13:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16605 for ; Mon, 14 May 2001 15:13:04 -0400 (EDT) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22060 for ; Mon, 14 May 2001 15:12:54 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id MAA10268; Mon, 14 May 2001 12:12:24 -0700 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id MAA23988; Mon, 14 May 2001 12:12:30 -0700 Message-ID: <3B002D2C.5C5EC19B@hursley.ibm.com> Date: Mon, 14 May 2001 14:08:28 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Pyda Srisuresh CC: Christian Huitema , Cedric Aoun , "Midcom IETF (E-mail)" Subject: Re: [midcom] RE: Some comments on scenario draft References: <20010514180607.64396.qmail@web13805.mail.yahoo.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 Pyda Srisuresh wrote: > > --- Brian E Carpenter wrote: > > Pyda, > > > > I suspect that dual stack middleboxes themselves may prove to be very > > important means of communication between v6-only and v4-only hosts, > > making NAT-PT itself largely unnecessary. > > While dual-stack is a requirement, middlebox cannot do without NAT-PT > for such a communication (between V6-only and V4-only end-hosts). Yes it can, if it gateways or proxies the application. Brian > > > Whatever solutions midcom > > invents need to deal with all likely scenarios, however, so I think > > including v4/v6 coexistence in the scenarios is essential. > > OK. Thanks. > > > Brian > > > > regards, > suresh > > > Pyda Srisuresh wrote: > > > > > > --- Christian Huitema wrote: > > > > The plan of record for IPv6 is indeed that you will not use address > > > > translation and IPv6; frankly, if you still used NAT, there would be > > > > little reason to move to IPv6 in the first place! What I point out in > > > > the scenario is, what changes when IPv6 gives you global addressing. > > > > > > Christian - I do not agree with your assertion above and a similar > > > comment made in section 2.4. NAT-PT plays an important role in v6 > > > transition strategy. NAT-PT is the only means of communication between > > > V6-only hosts and V4-only hosts. > > > > > > I believe, the intoduction of V6 and V6 transition mechanisms in this > > > document is a diversion to the main theme and would not suggest this > > > to be part of this document. 6-to-4 router is neither a middlebox nor > > > a MIDCOM agent nor an application we are trying to facilitate using the > > > MIDCOM protocol. In that case, why not simply limit the illustrations to > > > v4 hosts (or) v6 hosts only? > > > > > > Including IPv6 transition mechanism into the document serves no purpose in > > > illustrating the MIDCOM protocol scenario. I believe, the entire > > > section 2.4, with the exception of section 2.4.5, is not required. > > > Unless you insist on including a V6-only network scenario, I would suggest > > > replacing the reference to V6 hosts with V4 hosts in section 2.4.5 - as > > > section 2.4.5 illustrates IPsec/IKE traversal scenario irrespective > > > of whether both end-hosts are V6-only (or) V4-only. > > > > > > Regards, > > > suresh _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon May 14 15:25: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 PAA22375 for ; Mon, 14 May 2001 15:25:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16789; Mon, 14 May 2001 15:20:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16754 for ; Mon, 14 May 2001 15:20:45 -0400 (EDT) Received: from web13806.mail.yahoo.com ([216.136.175.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22250 for ; Mon, 14 May 2001 15:20:36 -0400 (EDT) Message-ID: <20010514192044.96219.qmail@web13806.mail.yahoo.com> Received: from [65.12.33.187] by web13806.mail.yahoo.com; Mon, 14 May 2001 12:20:44 PDT Date: Mon, 14 May 2001 12:20:44 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] RE: Some comments on scenario draft To: Brian E Carpenter , Keith Moore Cc: Pyda Srisuresh , Christian Huitema , Cedric Aoun , "Midcom IETF \(E-mail\)" In-Reply-To: <3B002C93.D79A5631@hursley.ibm.com> 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 Brian, That sounds likely. But, these (proxies and gateways) donot the fit the definition of middleboxes the MIDCOM WG is looking at. The proxies and gateways, can be a reasonable choice to implement MIDCOM agent functionality. Thanks for the clarification. regards, suresh --- Brian E Carpenter wrote: > I believe that dual stack application level proxies and > gateways will be the primary mode of interworking between > IPv6-only networks and IPv4-only servers, for a large number > of years. > > Brian > > Keith Moore wrote: > > > > > I suspect that dual stack middleboxes themselves may prove to be very > > > important means of communication between v6-only and v4-only hosts, > > > making NAT-PT itself largely unnecessary. > > > > Brian, > > > > by "dual stack middleboxes" I take it you mean boxes that intercept > > traffic at layer 4 or higher, rather than NAT-PT which operates > > at layer 3? you may be right, but I hope not. NAT techniques > > are already disruptive enough - interfering with higher layers > > will just cause more problems. > > > > I'm curious as to why you think this. or if I've misunderstood > > what you meant, please clarify. > > > > Keith > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > On assignment for IBM at http://www.iCAIR.org > Board Chairman, Internet Society http://www.isoc.org ===== __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon May 14 16:02:22 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 QAA23089 for ; Mon, 14 May 2001 16:02:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17393; Mon, 14 May 2001 15:54:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17366 for ; Mon, 14 May 2001 15:54:55 -0400 (EDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22922 for ; Mon, 14 May 2001 15:54:45 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA26621; Mon, 14 May 2001 15:54:18 -0400 (EDT) Message-Id: <200105141954.PAA26621@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian E Carpenter cc: Keith Moore , Pyda Srisuresh , Christian Huitema , Cedric Aoun , "Midcom IETF (E-mail)" Subject: Re: [midcom] RE: Some comments on scenario draft In-reply-to: Your message of "Mon, 14 May 2001 14:05:55 CDT." <3B002C93.D79A5631@hursley.ibm.com> Date: Mon, 14 May 2001 15:54:18 -0400 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 believe that dual stack application level proxies and > gateways will be the primary mode of interworking between > IPv6-only networks and IPv4-only servers, for a large number > of years. thanks for the clarification. but given a choice between NAT-PT which works across several (though by no means all) applications, and a proxy which must be tailored for each application, why do you think the latter will be the primary mode? Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon May 14 16:56:19 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 QAA24533 for ; Mon, 14 May 2001 16:56:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18596; Mon, 14 May 2001 16:47:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18566 for ; Mon, 14 May 2001 16:47:10 -0400 (EDT) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24376 for ; Mon, 14 May 2001 16:47:01 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id NAA46044; Mon, 14 May 2001 13:46:30 -0700 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA23852; Mon, 14 May 2001 13:46:35 -0700 Message-ID: <3B004320.9C21EEB2@hursley.ibm.com> Date: Mon, 14 May 2001 15:42:08 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Keith Moore CC: Pyda Srisuresh , Christian Huitema , Cedric Aoun , "Midcom IETF (E-mail)" Subject: Re: [midcom] RE: Some comments on scenario draft References: <200105141954.PAA26621@astro.cs.utk.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 Keith Moore wrote: > > > I believe that dual stack application level proxies and > > gateways will be the primary mode of interworking between > > IPv6-only networks and IPv4-only servers, for a large number > > of years. > > thanks for the clarification. but given a choice between NAT-PT > which works across several (though by no means all) applications, > and a proxy which must be tailored for each application, why do > you think the latter will be the primary mode? Note that I said "IPv6-only networks" (i.e. not isolated IPv6-only hosts). I tend to believe that IPv6-only networks will depend on proxies and ALGs anyway, basically beacuse they will be cell phone networks. Melinda must be about to tell us we are off topic. Brian _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue May 15 15:19:31 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 PAA05506 for ; Tue, 15 May 2001 15:19:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21769; Tue, 15 May 2001 15:12:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21738 for ; Tue, 15 May 2001 15:12:28 -0400 (EDT) Received: from sapphire.int.ipverse.com ([65.195.29.42]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05436 for ; Tue, 15 May 2001 15:12:18 -0400 (EDT) Received: from matt.ipverse.com (MATT [10.1.1.157]) by sapphire.int.ipverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KDVGY7FC; Tue, 15 May 2001 12:11:56 -0700 Message-Id: <5.1.0.14.2.20010515120628.02127540@mail.ipverse.com> X-Sender: matt@mail.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 15 May 2001 12:11:01 -0700 To: Keith Moore From: Matt Holdrege Subject: Re: [midcom] Fw: I-D ACTION:draft-shore-midcom-apps-00.txt Cc: midcom@ietf.org In-Reply-To: <200105141536.LAA24551@astro.cs.utk.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 08:36 AM 5/14/2001, Keith Moore wrote: >Melinda, > >I strongly object to the notion that middleboxes are part of any kind >of 'architecture'. They are a hack, nothing more. An architecture >implies some aspect of overall design, making compromises between the >needs of different facets of the design for the overall good. >Such terminology does not apply to workarounds for the problems >with NATs. Real networks architectures that make compromises between the needs of different facets of the design for the overall good, use middleboxes. The definition of good is a variable. We need to address such designs and that's what this WG is about. In any case, a bad architecture is still an architecture. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue May 15 15:56:28 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 PAA05859 for ; Tue, 15 May 2001 15:56:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22599; Tue, 15 May 2001 15:47:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22570 for ; Tue, 15 May 2001 15:47:42 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05747 for ; Tue, 15 May 2001 15:47:32 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA04219; Tue, 15 May 2001 15:47:26 -0400 (EDT) Message-Id: <200105151947.PAA04219@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Matt Holdrege cc: Keith Moore , midcom@ietf.org Subject: Re: [midcom] Fw: I-D ACTION:draft-shore-midcom-apps-00.txt In-reply-to: Your message of "Tue, 15 May 2001 12:11:01 PDT." <5.1.0.14.2.20010515120628.02127540@mail.ipverse.com> Date: Tue, 15 May 2001 15:47:26 -0400 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 > Real networks architectures that make compromises between the needs of > different facets of the design for the overall good, use middleboxes. The > definition of good is a variable. > > We need to address such designs and that's what this WG is about. In any > case, a bad architecture is still an architecture. Let me try to state this in different words: (note: the word middlebox is so overloaded as to make nearly every use of the word ambiguous at best and misleading at worst. so I try not to use that word.) weasel-words in the charter notwithstanding, this working group exists primarily to work around some of the problems caused by NATs to a fairly narrow class of applications. that much was clear from the arguments preceding formation of the group in which any attempt to get the group to develop a reasonable architecture were quite loudly (and occasionally abusively) shouted down. yes, this group is also trying to accomodate firewalls, but this is due to a confusion that firewalls and NATs are similar in function. if this group were concentrating on firewalls rather than trying to justify and prolong NAT's existence it would be quite reasonable for it to develop an architecture for firewalls. the word architecture implies a compromise made in view of the needs of various parties. this does not describe even the typical use of NATs, which are NOT a compromise made in view of application developers. and the word 'architecture' quite emphatically does not describe the problems with NAT which motivated creation of this group. as I said in an earlier message, when a building is destroyed by explosives, you don't use the word 'architecture' to describe the rubble. this group is trying to salvage something of the rubble created by NATs. calling it 'architecture' is misleading and dishonest. if you want to develop an architecture, you start not by assuming the existence of NATs, but by determining what functional layers you need. then you can think about what name spaces are needed by those layers and how those names are going to be mapped to one another, and then you can start making compromises regarding how many namespaces you have and the efficiency and currency of the mappings, etc. if you find that the result accomodates NATs, then NATs might end up being part of the architecture. but in order to reach that conclusion you'd have to find a reason to discount many years of experience that demonstrate that translation of endpoint identifiers creates a royal mess. in fact, no such reason has been found, and the most recent experience with NATs (which in fact led to creation of this group) only serves to reinforce the earlier experience. the fact that NATs exist is not evidence of architectural soundness, any more than the fact that drunk driving exists is evidence of wisdom on the part of the drivers. both are examples of optimizing for short-term gain and ignoring the tragic result that is likely to happen in the long term if the practice is continued. which is not to say that NATs are as tragic as loss of life. but we are trying to build the world's first global general-purpose communications system. our work really does have profound effects that extend for decades beyond the next RFC or product release cycle. we have an obligation to try to do this work rationally and with some attempt at foresight. Keith p.s. for those who are tempted to dismiss this as a rant - it's not. it's a serious attempt at a wakeup call. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue May 15 16:36: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 QAA06423 for ; Tue, 15 May 2001 16:36:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23849; Tue, 15 May 2001 16:27:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23818 for ; Tue, 15 May 2001 16:27:07 -0400 (EDT) Received: from corb.mc.mpls.visi.com (corb.mc.mpls.visi.com [208.42.156.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06298 for ; Tue, 15 May 2001 16:26:56 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id BCE98814E for ; Tue, 15 May 2001 15:02:14 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id PAA09612 for ; Tue, 15 May 2001 15:27:05 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Tue, 15 May 2001 15:27:05 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] Fw: I-D ACTION:draft-shore-midcom-apps-00.txt In-Reply-To: <200105151947.PAA04219@astro.cs.utk.edu> 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 On Tue, 15 May 2001, Keith Moore wrote: > yes, this group is also trying to accomodate firewalls, but this is due > to a confusion that firewalls and NATs are similar in function. Here's your first problem. NATs and Firewalls are lumped together not because they're similar but because they're the two types of widgets in the way of making a whole lot of stuff work. It might be courteous to assume that we're not idiots, Keith. I shall try to do the same for you, and I apologize if I have not been scrupulous in that regard up to now. > as I said in an earlier message, when a building is destroyed by explosives, > you don't use the word 'architecture' to describe the rubble. this group > is trying to salvage something of the rubble created by NATs. calling it > 'architecture' is misleading and dishonest. This is pure opinion and sloppy rhetoric, and you know it. You start from the premise that NATs are "like rubble" and then declare "look! they're like rubble!" Such circular reasoning is beneath you. > the fact that NATs exist is not evidence of architectural soundness, > any more than the fact that drunk driving exists is evidence of > wisdom on the part of the drivers. both are examples of optimizing for > short-term gain and ignoring the tragic result that is likely to happen > in the long term if the practice is continued. Ditto. "NATs are like drunk drivers!" > p.s. for those who are tempted to dismiss this as a rant - it's not. > it's a serious attempt at a wakeup call. I appreciate the effort, but with such inflammatory rhetoric, you're unlikely to make headway. After reading your postscript, I deliberately took the time to re-read your essay in detail, and found very little beyond random shouting. Perhaps I missed something, but I really did try. By the way, the E.164 network is rife with NATs, and seems to have scaled quite well. Of course, we don't call them NATs, but they're there, and you use at least one every time you dial an 800 number or call someone's office using a direct-inward-dial number. I venture to suggest that the lads at Bellcore (oops, Telcordia, oops SAIC) think they might just have done a little architecture there. Just by way of a counter example. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue May 15 20:28:56 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 UAA10208 for ; Tue, 15 May 2001 20:28:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA29817; Tue, 15 May 2001 20:09:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA29792 for ; Tue, 15 May 2001 20:08:59 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA10071 for ; Tue, 15 May 2001 20:08:50 -0400 (EDT) Received: from 157.54.9.104 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 15 May 2001 14:26:54 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Tue, 15 May 2001 14:26:47 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Tue, 15 May 2001 14:26:45 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 15 May 2001 14:26:33 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] Fw: I-D ACTION:draft-shore-midcom-apps-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Tue, 15 May 2001 14:26:33 -0700 Message-ID: Thread-Topic: [midcom] Fw: I-D ACTION:draft-shore-midcom-apps-00.txt Thread-Index: AcDdgUpCuYZo8/OSQ/62wKv9Zzp8mAAAt+jQ From: "Christian Huitema" To: "Andrew Molitor" , X-OriginalArrivalTime: 15 May 2001 21:26:33.0876 (UTC) FILETIME=[B71AF540:01C0DD85] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA29793 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 Keith is basically right. The purpose of the group is to provide the requirements for a quick fix, i.e. how to make a certain set of application work through firewall and NAT. On the other hand, the existence of a short term solution has a high potential to encourage "internetting while intoxicated." The main problem with any solution that throws a third party in a communication between two hosts is known as "fate sharing", i.e. the fact that suddenly the behavior of the end-to-end is dependent on the continuous operation and proper behavior of an intermediate. A fairly fundamental tenet of the Internet architecture is that this kind of strong dependency should be avoided. There are different techniques that can be used for interoperation between the intermediate and the end point. Some of the techniques, such as address translation, mandate a hard state in the intermediate; other examples are various forms of tunneling. Other techniques such as for example port filtering are more amenable to a "soft state" implementation, in which the necessary "crossing state" is placed on demand in whichever firewall happens to be on the path. In short, packet inspection can be accommodated with a soft state solution, while packet rewriting is a much harder problem. The discussion on IPv6 shows that a significant fraction of this group is not terribly interested in engineering a clean solution that would preclude rewriting. Since shouting at each other is not particularly helpful, I suggest that we concentrate on what we agree is needed in the short term, i.e. the crossing of NAT and firewalls, and drop any attempt at a grandiose architecture of unspecified middleboxes... -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue May 15 22:20: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 WAA12466 for ; Tue, 15 May 2001 22:20:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02979; Tue, 15 May 2001 22:14:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02950 for ; Tue, 15 May 2001 22:14:36 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12348 for ; Tue, 15 May 2001 22:14:25 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id WAA06050; Tue, 15 May 2001 22:14:29 -0400 (EDT) Message-Id: <200105160214.WAA06050@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Andrew Molitor cc: midcom@ietf.org Subject: Re: [midcom] Fw: I-D ACTION:draft-shore-midcom-apps-00.txt In-reply-to: Your message of "Tue, 15 May 2001 15:27:05 CDT." Date: Tue, 15 May 2001 22:14:29 -0400 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 > NATs and Firewalls are lumped > together not because they're similar but because they're the two types > of widgets in the way of making a whole lot of stuff work. yes, but there's a huge difference: - NATs are "in the way" because they violate the Internet Protocol in some fairly fundamental ways, that (due to IPv4 address space shortage) cannot be fixed without moving to another address space. - firewalls are "in the way" because the site administrator has decided (for better or worse) that whatever you're trying to do is not compatible with the security policy. yes, there is a small conceptual similarity between the problem of opening up a hole in a firewall and allocating translation state in a NAT. and if this group mostly limits itself to defining a way to do that one thing, then it probably won't do too much harm. the problem is when people start assuming that this part of the future direction of the Internet, and that it needs an 'architecture' this is a short-term hack. it needs to be kept simple so that it can be deployed soon enough to be of use. > It might be courteous to assume that we're not idiots, Keith. I don't. Indeed, the paradox is that so many very intelligent people are, acting together, are capable of investing large amounts of effort in unproductive directions. > > as I said in an earlier message, when a building is destroyed by explosives, > > you don't use the word 'architecture' to describe the rubble. this group > > is trying to salvage something of the rubble created by NATs. calling it > > 'architecture' is misleading and dishonest. > > This is pure opinion and sloppy rhetoric, and you know it. > You start from the premise that NATs are "like rubble" and then > declare "look! they're like rubble!" it's an analogy, not a logical argument. it's intended to persuade folks who are capable of a bit of intiution and can see the similarity between NAT-damage and rubble. it's not intended to persuade folks who prefer to establish values and analyze the logical consequences of a particular approach with respect to those values. it's possible to demostrate that NATs are a bad idea via that method also, and this has been done. but it takes longer, and anyway logical arguments are lost on folks who assume that because NATs exist, they therefore must continue to exist. > > the fact that NATs exist is not evidence of architectural soundness, > > any more than the fact that drunk driving exists is evidence of > > wisdom on the part of the drivers. both are examples of optimizing for > > short-term gain and ignoring the tragic result that is likely to happen > > in the long term if the practice is continued. > > Ditto. "NATs are like drunk drivers!" that's it. repeat the hook line, and ignore the explanation contained in the same paragraph. > > p.s. for those who are tempted to dismiss this as a rant - it's not. > > it's a serious attempt at a wakeup call. > > I appreciate the effort, but with such inflammatory rhetoric, > you're unlikely to make headway. Indeed, I'm afraid that you're right. But I suspect there are plenty of intelligent people here who do not accept the "NATs are the future of the Internet" mantra without question, but who (for whatever reason) do not speak up when the group seems to go in that direction. I'm hoping that my speaking up will encourage others to do so also, and that this in turn will encourage the group to direct its energies more usefully. > After reading your postscript, I > deliberately took the time to re-read your essay in detail, and found > very little beyond random shouting. Perhaps I missed something, but > I really did try. > > By the way, the E.164 network is rife with NATs, and seems to > have scaled quite well. well, until recently the telephone network didn't have anything like a source endpoint identifier that was visible to the destination. and of course it was designed for a fairly narrow application space compared to the Internet. if all of the applications in the Internet were client-server, NATs wouldn't be as much of a problem - but in fact an Internet that can only do client-server applications is crippled compared to one that supports IP. I'll note that these days, caller line identification does tend to preserve addresses end-to-end, and the caller's source address has long been available at the destination for 800 number calls. so I don't think your argument holds. Keith p.s. it's not my intent to try to disrupt the group by consuming bandwidth, and I don't think that I'll persuade many more people by continuing this line of persuasion. so I'll probably drop it for now unless I see some significant point that I can make that hasn't been made recently. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu May 17 07:06: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 HAA13478 for ; Thu, 17 May 2001 07:06:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25600; Thu, 17 May 2001 06:59:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25571 for ; Thu, 17 May 2001 06:59:35 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13261; Thu, 17 May 2001 06:59:24 -0400 (EDT) Message-Id: <200105171059.GAA13261@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 17 May 2001 06:59:24 -0400 Subject: [midcom] I-D ACTION:draft-ietf-midcom-framework-01.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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : Middlebox Communication Architecture and framework Author(s) : P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan Filename : draft-ietf-midcom-framework-01.txt Pages : 38 Date : 16-May-01 There are a variety of intermediate devices in the Internet today that require application intelligence for their operation. Datagrams pertaining to real-time streaming applications such as SIP and H.323 and peer-to-peer applications such as Napster and NetMeeting cannot be identified by merely examining packet headers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-framework-01.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-ietf-midcom-framework-01.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-ietf-midcom-framework-01.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010516090853.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-framework-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-framework-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010516090853.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu May 17 12:26: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 MAA21630 for ; Thu, 17 May 2001 12:26:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09486; Thu, 17 May 2001 12:19:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09454 for ; Thu, 17 May 2001 12:19:17 -0400 (EDT) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21452 for ; Thu, 17 May 2001 12:19:05 -0400 (EDT) Received: from cisco.com (sjc-vpn-tmp131.cisco.com [10.21.64.131]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA00289 for ; Thu, 17 May 2001 09:18:44 -0700 (PDT) Message-ID: <3B03F956.36A5F13A@cisco.com> Date: Thu, 17 May 2001 09:16:22 -0700 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: midcom@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] framework document 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 Hi, Nice pictures. Still, I thought we had agreed in March that the In-Path/Out-of-path distinction was unnecessary for purposes of defining requirements for a MIDCOM protocol. The drawings in the draft even indicate this. So why mention it? If necessary at all, diversion should be an internal mechanism of the middle box. What am I missing? There is another concern the document only briefly discusses, which I should now like to cover. Do we need a separate protocol to communicate policy between the middlebox and policy server or can it be the same as that of the middlebox? I submit that the answer itself is a policy question. Since the caching of policy would require the sharing of policy outside of the policy server. This is the COPS-PR argument The cost of not sharing is of course performance, and perhaps some amount of reliability and latency. The opposite would be "mother may i", i.e., the COPS-RSVP mechanism. What is clear is that there is no requirement that the protocols be the same, and there is no need to proceed on the basis that this is in fact true. Thus, in the framework document, I would suggest a modification in the diagram to match what section 2.9 says, which is to draw the policy server line to the side of the middlebox. What is clear is that the midcom protocol itself must be a "mother may i" mechanism. -- Eliot Lear lear@cisco.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu May 17 13:45:22 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 NAA23289 for ; Thu, 17 May 2001 13:45:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12559; Thu, 17 May 2001 13:26:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12531 for ; Thu, 17 May 2001 13:26:57 -0400 (EDT) Received: from corb.mc.mpls.visi.com (corb.mc.mpls.visi.com [208.42.156.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22902 for ; Thu, 17 May 2001 13:26:47 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id BB9688199 for ; Thu, 17 May 2001 12:01:05 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id MAA12802 for ; Thu, 17 May 2001 12:26:56 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Thu, 17 May 2001 12:26:56 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] framework document In-Reply-To: <3B03F956.36A5F13A@cisco.com> 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 On Thu, 17 May 2001, Eliot Lear wrote: > Hi, > > Nice pictures. Still, I thought we had agreed in March that the > In-Path/Out-of-path distinction was unnecessary for purposes of defining > requirements for a MIDCOM protocol. The drawings in the draft even > indicate this. So why mention it? If necessary at all, diversion should > be an internal mechanism of the middle box. What am I missing? My thinking is that these things are there to provide context, to provide scope for the set of problems MIDCOM should solve. MIDCOM itself is very narrowly scoped, so if we reduce everything to stuff strictly in scope, all the pictures look like this: +----------+ +---------------+ | MIDCOM | MIDCOM | Middlebox | | Agent |<---------------->| | +----------+ +---------------+ > There is another concern the document only briefly discusses, which I > should now like to cover. Do we need a separate protocol to communicate > policy between the middlebox and policy server or can it be the same as > that of the middlebox? My opinion is that this is a separate protocol, and that it's out of scope for MIDCOM. Again, policy servers and whatnot are indicated, I think, to show scope. Also to quell that population of MIDCOM participants who would wonder why a policy element was NOT indicated, if it was not. Would it be helpful to update the framework document to more clearly delineate the difference between stuff that's context, and stuff that's In Scope? I don't find any problem distinguishing myself, but I may well be way to close to it to judge. There is certainly no shortage of policy lookup protocols available. > What is clear is that the midcom protocol itself must be a "mother may i" > mechanism. I am unclear on what exactly this means.. If it means what I think it might mean, I concur, but I could be wrong! _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu May 17 14:02:51 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 OAA23673 for ; Thu, 17 May 2001 14:02:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13888; Thu, 17 May 2001 13:52:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13858 for ; Thu, 17 May 2001 13:52:57 -0400 (EDT) Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23470 for ; Thu, 17 May 2001 13:52:46 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 219478161 for ; Thu, 17 May 2001 12:28:13 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id MAA14260 for ; Thu, 17 May 2001 12:52:55 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Thu, 17 May 2001 12:52:55 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [midcom] MIDCOM Protocol Performace Requirements - 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 Some of you may recall me beating a drum about explictly requiring that MIDCOM be, if not inherently high performance, at least admitting of high-performance implementations. There were many dissenting responses, including the admirable point that the SIP spec makes no mention of performance. I think I promised to put together my thoughts on this quite a while ago, and now I am finally delivering. SIP is a class 'slow protocol' it turns out. You send a message and wait for a response, no sliding windows, no nothing. The horror! Luckily, SIP doesn't NEED to be fast in this sense, and in fact I cannot think of any use things like sliding windows would have in SIP. SIP can be used to build high-performing networks successfully, basically because you can run arbitrarily many 'slow' transactions in parallel. Since each transaction is between (in general) a different pair of endpoints, they are uncorrelated, and things like authentication and whatnot need to be done on an endpoint-pair basis anyways, if you choose to do that sort of thing. MIDCOM is quite different. In a high-performance situation, you have (in the simple case) only two endpoints: an agent, and a middlebox. These two probably do NOT want to re-authenticate for every transaction. In the case of, say, a NAT-enabled high performance SIP network, all the many parallel 'slow' SIP transactions can get bottlenecked by a single Agent<->middlebox session gating transaction completion. One can do hacks like 'open a whole bunch of sessions between the Agent and the middlebox' but this really is a hack. It's even a hack I have considered, but it was just too darn ugly. I'm not trying to require that the protocol BE high performance, simply that it admit high-performance implementations. For example, a protocol that included an authentication phase, and then sequence numbered transactions within an authenticated session would (I think) be sufficient to permit windowed implementations and still allow easy slower ones. What I want to avoid is things like: - authenticate for every transaction. or: - authenticate once, send requests one at a time and wait for the response before you send another because you can't send two since there's no way to tell the replies apart. It is tempting to try to sell: - must have an authentication phase followed by - a series of transactions each uniquely identified by a sequence number at least 32 bits in size but that rather clearly falls OUT of the realm of requirements into the realm of solutions. I am happy with anything that lets me allow a single Agent to talk to a single middlebox and get at least a few hundred transations done per second on the middlebox even assuming a few milliseconds of latency between the Agent and the middlebox. If MIDCOM cannot be implemented in such a way as to allow that, it is useless to me. Andrew _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu May 17 14:41: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 OAA24509 for ; Thu, 17 May 2001 14:41:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15793; Thu, 17 May 2001 14:35:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAB15762 for ; Thu, 17 May 2001 14:35:54 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24362 for ; Thu, 17 May 2001 14:35:43 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f4HIXDt28027; Thu, 17 May 2001 11:33:54 -0700 (PDT) Received: from spandex (rtp-vpn-220.cisco.com [10.82.192.220]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AFR09479; Thu, 17 May 2001 11:34:40 -0700 (PDT) Message-ID: <02a001c0df00$1b118160$d45904d1@cisco.com> From: "Melinda Shore" To: "Andrew Molitor" , References: Subject: Re: [midcom] framework document Date: Thu, 17 May 2001 14:35:10 -0400 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 >From: Andrew Molitor > On Thu, 17 May 2001, Eliot Lear wrote: > > There is another concern the document only briefly discusses, which I > > should now like to cover. Do we need a separate protocol to communicate > > policy between the middlebox and policy server or can it be the same as > > that of the middlebox? > > My opinion is that this is a separate protocol, and that > it's out of scope for MIDCOM. I guess the charter is not completely clear on your first opinion but I do think that it's quite clear on the second. From the charter: The deliverables will be [ ... ] o a document describing the requirements for a policy enity Elliot is quite correct that the midcom protocol itself is a 'mother may I' kind of a thing - that's why we're "middlebox communication" and not "middlebox control." Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu May 17 16:56: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 QAA26898 for ; Thu, 17 May 2001 16:56:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20646; Thu, 17 May 2001 16:48:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20617 for ; Thu, 17 May 2001 16:48:48 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26786 for ; Thu, 17 May 2001 16:48:34 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id NAA19748 for ; Thu, 17 May 2001 13:48:43 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id NAA09102 for ; Thu, 17 May 2001 13:48:42 -0700 (PDT) Received: from xch-pssbh-03.nw.nos.boeing.com by blv-hub-01.boeing.com with ESMTP for midcom@ietf.org; Thu, 17 May 2001 13:48:33 -0700 Received: by xch-pssbh-03.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 17 May 2001 13:48:33 -0700 Message-Id: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12CEF@XCH-NW-01.nw.nos.boeing.com> From: "Fleischman, Eric W" To: "'midcom@ietf.org'" Date: Thu, 17 May 2001 13:48:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA20618 Subject: [midcom] Comments on Midcom Framework Draft (00) 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 X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id QAA20646 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA26898 This comment is in regards to draft-ietf-midcom-framework-00.txt. I value the different perspective on the midcom protocol framework which the authors have taken in this draft vis-à-vis my own assumptions. I find that much of their approach is satisfying, particularly the novel (to me anyway) idea of having proxies and application layer gateways be the primary elements to use the midcom protocol in order to establish "holes" through middleboxes. This idea differs from the model I had always assumed in which the end hosts themselves would be the primary entity doing midcom communications. This difference in orientation also translates into a very different idea between the authors and me as to the role of the policy server in the two approaches and the nature of the "hole" being established through the middleboxes themselves. Despite my appreciation of aspects of the authors' approach, I nevertheless am left believing that the ultimate result of their approach is to undermine the purposes for which we have deployed middleboxes in the first place, particularly firewalls. I realize that this is a complex topic and that this initial posting may not adequately convey the nature of my concerns, but I nevertheless request that you please consider my points. Section 5 of the draft is concerned with the authentication of MIDCOM agents to the middlebox, possibility including mutual authentication. Then, in the penultimate paragraph of this section (within Section 5.2), the authors write a very important sentence that says: "When Middlebox notices an incoming midcom connection, the middlebox will consult its policy server for authenticity, authorization, and trust guidelines for the connection." This sentence is important in several dimensions including: * It is true both for the authors' model and my model -- therefore I agree with it * This is the only point in which the authors explain how the authorization capabilities of the Policy Server, previously mentioned in Section 2.8, are explained. What is critical about this section is that it begs the question as to how such authorization can be accomplished. That is, Section 5 is solely concerned with authenticating MIDCOM agents. At no point does the document deal with authenticating users. However, the authorization for applications to access internal applications/services is a function of rights and permissions ascribed to the authenticated user. Certainly this is true for our firewalls and I believe that it is similarly true for yours. [In our case, the importance of this fact is perhaps elevated due to our requirements to establish Role Based Access Control (RBAC) constraints due to governmental regulations and eBusiness-based process evolution.] In any case, the whole goal of the firewall is to keep the bad guys out. Firewalls are concerned therefore with USER access: the authorization of a connection through a firewall is a function of the rights and permissions ascribed to the USER, as determined by local policy. This is orthogonal to the identity of the proxy or intermediate agent which the user may optionally use, which is the only entity being authenticated by this current draft. And that is why this approach undermines the utility of firewalls. If the authors wish to preserve their current model (i.e., if they still don't want to adopt my model), their model needs to be modified by having the midcom protocol convey the user's identity to the middlebox so that the middlebox can forward it to the Policy Server if the Policy Server is going to be able to authenticate and authorize that user's access into the corporation. Some readers doubtlessly will want to object to this assertion of mine by an argument similar to the following: The authors indeed intended to only authenticate the MIDCOM agent because that agent is an adjunct to the middlebox. It is solely that adjunct's responsibility to authenticate the user and, only if the user passes that authentication/authorization scrutiny, will the agent undertake to represent that user to the middlebox. Thus, only the agent needs to be authenticated to the middlebox and not the user, since the agent is the agent of the user. Similarly, the "authorization" spoken of in the draft is an authorization for the MIDCOM agent, since the agent is representing the user to the middlebox and only it needs to be authorized. There are several problems with this counter-argument. I will mention only two: 1) This approach opens a security loophole. A problem with this argument and approach is that there is no guarantee being provided that the MIDCOM agent will indeed authenticate (and authorize) the user, or that even if it does, it will use the same policies or authentication/authorization system (e.g., same directory) as the firewall would have done, which is necessary if that agent is to operate as an adjunct to the firewall. Worse, there is no assurance that it could do so. Unless this "hole" is satisfactorily addressed, this whole model is broken from a security standpoint, since the foundation of our firewall is based upon user authentication and access control, which can not be guaranteed to happen nor guaranteed to happen in a compatible way to the firewall. [Note: any argument that your firewalls may be based more on packet filtering upon IP address and Port addresses than upon user-based access control will nevertheless not deprecate the fact that ours increasingly is -- and is increasingly based upon RBAC. Certainly we all can agree that to be valid, the framework must address all existing firewall deployments, not only a few of them.] 2) This approach makes enterprise management much more difficult. One of the difficulties we face, when we try to protect our enterprises, is ensuring consistent policy and enforcement approaches system-wide. This approach introduces a firewall adjunct (i.e., a MIDCOM Agent), that has undefined mechanisms by which it conducts basic user authentication/authorization functions. It provides no assurances that these functions can be integrated into the current enforcement practices of the corporation. No tools are being proposed to help us to smoothly integrate this adjunct into our systems, or to ensure that the resulting system maintains the end-to-end security profile that the firewall is designed to provide. It is quite probable that you will claim that these issues are out-of-scope (i.e., not directly relevant to the midcom protocol itself). I counter that claim by saying that it implies a far-too-limited scope, since a fundamental requirement is that the midcom protocol not BREAK current firewalls. Regardless, this approach may make our jobs harder by adding more non-integrated elements into our system and by therefore introducing more opportunities for us to make mistakes. The approach appears to be introducing vulnerabilities into our system with no provision to patch them. Therefore, this framework is not viable from a system perspective. What we need is to simplify our environment, not make it monotonically more complex. The importance to authenticate/authorize the user within the midcom protocol is my major point above. I have a few minor points that I'd also like to make: * There needs to optionally be constraints upon the "hole" which can be opened through the middlebox. Duration and number of sessions constraints need to be able to be imposed. * The concept of "trust level" introduced in Section 5 (e.g., see section 5.2) is inherently problematic. This is a very fuzzy concept which is directly relevant to particular implementation approaches (and non-relevant to others). Please either abandon it or make it concrete. (I'd be interested in whether you can make it concrete without addressing my major point above.) * The midcom protocol needs provisions to reduce its ability to be used as a vehicle for Denial of Service attacks. * Establishing paths such that the same packet needs to traverse the same firewall two or more times, as is discussed in Section 6.3, is a VERY BAD idea. This should be explicitly avoided and protected against. Please re-think this point. --Eric _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu May 17 17:40: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 RAA27572 for ; Thu, 17 May 2001 17:40:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22259; Thu, 17 May 2001 17:34:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22226 for ; Thu, 17 May 2001 17:34:13 -0400 (EDT) Received: from thalia.fm.intel.com ([132.233.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27507 for ; Thu, 17 May 2001 17:34:01 -0400 (EDT) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.38 2001/05/09 12:49:45 root Exp $) with SMTP id VAA14662 for ; Thu, 17 May 2001 21:34:12 GMT Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 17 May 2001 21:34:12 0000 (GMT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 May 2001 14:34:11 -0700 Message-ID: From: "Menon, Rama R" To: midcom@ietf.org Date: Thu, 17 May 2001 14:33:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [midcom] Comments on draft-ietf-midcom-framework-01.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 Hi, I believe this draft is a bit confusing as it introduces other applications/services into the framework than what is considered in-scope for this WG. Specifically, during the IETF 50 MIDCOM session in Minneaplois, it was clarified that MIDCOM will limit its scope to NATs and firewalls - proxies, ALGs and the like were out-of-scope for this WG. What am I missing? Regards, - Rama ********* _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu May 17 22:51:41 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 WAA03733 for ; Thu, 17 May 2001 22:51:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01726; Thu, 17 May 2001 22:46:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01701 for ; Thu, 17 May 2001 22:46:13 -0400 (EDT) Received: from web13801.mail.yahoo.com (web13801.mail.yahoo.com [216.136.175.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03143 for ; Thu, 17 May 2001 22:45:27 -0400 (EDT) Message-ID: <20010518024538.73972.qmail@web13801.mail.yahoo.com> Received: from [65.12.33.187] by web13801.mail.yahoo.com; Thu, 17 May 2001 19:45:38 PDT Date: Thu, 17 May 2001 19:45:38 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] framework document To: lear@cisco.com, midcom@ietf.org In-Reply-To: <3B03F956.36A5F13A@cisco.com> 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 --- Eliot Lear wrote: > Hi, > > Nice pictures. Thanks. > Still, I thought we had agreed in March that the > In-Path/Out-of-path distinction was unnecessary for purposes of defining > requirements for a MIDCOM protocol. I dont recall that. My own recollection is that folks felt Out-of-Path agent description was not adequate and needed clearer explanation so the distinction between In-Path and Out-of-Path agents is clearer. That was why we spent so much effort trying to get the text on out-of-path agent clearer and used a timeline to illustrate the same. > The drawings in the draft even > indicate this. So why mention it? If necessary at all, diversion should Which diagrams are you refering to? Did you mean figures 2 & 3? And, the timeline flow in section 8.1? Yet, you dont see the difference between In-Path agent and OOP agent connections with middlebox? > be an internal mechanism of the middle box. What am I missing? > Sure, diversion would clearly be an internal component of the middlebox. This component is required only as the middlebox interfaces with an out-Of-path agent. This component is not required while interfacing with the an In-path agent. For an In-Path agent, Middlebox does not make divert the datagrams. The in-path entity terminates the packet session, after all. > There is another concern the document only briefly discusses, which I > should now like to cover. Do we need a separate protocol to communicate > policy between the middlebox and policy server or can it be the same as > that of the middlebox? > Section 2.9 explicitly states that the protocol facilitating the communication between a middlebox and Policy Server need not be part of MIDCOM protocol. > I submit that the answer itself is a policy question. Since the caching > of policy would require the sharing of policy outside of the policy > server. This is the COPS-PR argument The cost of not sharing is of course > performance, and perhaps some amount of reliability and latency. The > opposite would be "mother may i", i.e., the COPS-RSVP mechanism. What is > clear is that there is no requirement that the protocols be the same, and Yes. > there is no need to proceed on the basis that this is in fact true. Thus, Yes. > in the framework document, I would suggest a modification in the diagram > to match what section 2.9 says, which is to draw the policy server line to > the side of the middlebox. > I assume, you are refering to figure 1. Are you saying it is visually better to place Policy Server to the side of middlebox. I had it that way originally; and some folks wanted to see end-hosts by the sides. Well, there is only so much space that draft formatting allows. Anyways, I dont believe, the diagram violates section 2.9 in any way. So, why not leave the diagram as is. Thanks. > What is clear is that the midcom protocol itself must be a "mother may i" > mechanism. > -- > Eliot Lear > lear@cisco.com > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom cheers, suresh __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 18 00:00:59 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 AAA04689 for ; Fri, 18 May 2001 00:00:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA03458; Thu, 17 May 2001 23:57:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA03433 for ; Thu, 17 May 2001 23:57:01 -0400 (EDT) Received: from web13802.mail.yahoo.com (web13802.mail.yahoo.com [216.136.175.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04667 for ; Thu, 17 May 2001 23:56:48 -0400 (EDT) Message-ID: <20010518035659.3734.qmail@web13802.mail.yahoo.com> Received: from [65.12.33.187] by web13802.mail.yahoo.com; Thu, 17 May 2001 20:56:59 PDT Date: Thu, 17 May 2001 20:56:59 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Comments on draft-ietf-midcom-framework-01.txt To: "Menon, Rama R" , midcom@ietf.org In-Reply-To: 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 --- "Menon, Rama R" wrote: > Hi, > > I believe this draft is a bit confusing as it introduces other > applications/services into the > framework than what is considered in-scope for this WG. > > Specifically, during the IETF 50 MIDCOM session in Minneaplois, it was > clarified that > MIDCOM will limit its scope to NATs and firewalls - proxies, ALGs and the > like were > out-of-scope for this WG. > > What am I missing? > You are right about limiting the scope of middlebox services to NAT and firewall. As for the Proxies and ALGs - You might want to look at terminology section (2) on how they are refered in conjunction with MIDCOM agents. > Regards, > > - Rama > ********* cheers, suresh ===== __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 18 00:34:28 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 AAA05032 for ; Fri, 18 May 2001 00:34:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA04716; Fri, 18 May 2001 00:30:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA04641 for ; Fri, 18 May 2001 00:30:12 -0400 (EDT) Received: from web13801.mail.yahoo.com (web13801.mail.yahoo.com [216.136.175.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04962 for ; Fri, 18 May 2001 00:30:00 -0400 (EDT) Message-ID: <20010518043010.91026.qmail@web13801.mail.yahoo.com> Received: from [65.12.33.187] by web13801.mail.yahoo.com; Thu, 17 May 2001 21:30:10 PDT Date: Thu, 17 May 2001 21:30:10 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Comments on Midcom Framework Draft (00) To: "Fleischman, Eric W" , "'midcom@ietf.org'" In-Reply-To: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12CEF@XCH-NW-01.nw.nos.boeing.com> 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 X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id AAA04716 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA05032 Eric - You might refer the newer rev (-01( of the draft, released just this morning and see if some of your questions are answered there. Also, your e-mail is extremely difficult to read with long sentences wrapping around. Anyways, see my comments below. cheers, suresh --- "Fleischman, Eric W" wrote: > This comment is in regards to draft-ietf-midcom-framework-00.txt. > > I value the different perspective on the midcom protocol framework > which the authors have taken in this draft vis-à-vis my own assumptions. > I find that much of their approach is satisfying, particularly the novel > (to me anyway) idea of having proxies and application layer gateways be the > primary elements to use the midcom protocol in order to establish "holes" > through middleboxes. This idea differs from the model I had always assumed in > which the end hosts themselves would be the primary entity doing midcom > communications. This difference in orientation also translates into a very > different idea between the authors and me as to the role of the policy server > Why would the role of policy server change, whether an agent is run on a proxy or an end-host? > in the two approaches and the nature of the "hole" being established through > the middleboxes themselves. Once again, what does it matter where the agent is - Why would the nature of the hole change? > > Despite my appreciation of aspects of the authors' approach, I nevertheless > am left believing that the ultimate result of their approach is to > undermine the purposes for which we have deployed middleboxes in the first > place, > particularly firewalls. I realize that this is a complex topic and that this > initial > posting may not adequately convey the nature of my concerns, but I > nevertheless request > that you please consider my points. > Fair enough. > Section 5 of the draft is concerned with the authentication of MIDCOM agents > to > the middlebox, possibility including mutual authentication. Then, in the > penultimate paragraph of this section (within Section 5.2), the authors write > a very > important sentence that says: "When Middlebox notices an incoming midcom > connection, the > middlebox will consult its policy server for authenticity, authorization, and > trust > guidelines for the connection." This sentence is important in several > dimensions including: > > * It is true both for the authors' model and my model -- therefore I agree > with it > > * This is the only point in which the authors explain how the authorization > capabilities > of the Policy Server, previously mentioned in Section 2.8, are explained. > > What is critical about this section is that it begs the question as to how > such authorization > can be accomplished. From the policy server. > That is, Section 5 is solely concerned with > authenticating MIDCOM agents. Isnt this covered under the section titled - "Registration and Deregistration with a middlebox"? Authorization is covered under section 5.0 and 5.2, not under "Authentication" section. Anyways, would appreciate of you could refer the newer rev of the drfat and let me know what you think. Thanks. > At no point does the document deal with authenticating users. However, the > authorization for > applications to access internal applications/services is a function of rights > and permissions > ascribed to the authenticated user. Certainly this is true for our firewalls > and I believe that > it is similarly true for yours. [In our case, the importance of this fact is > perhaps elevated due to > our requirements to establish Role Based Access Control (RBAC) constraints > due to governmental regulations > and eBusiness-based process evolution.] In any case, the whole goal of the > firewall is to keep the > bad guys out. Firewalls are concerned therefore with USER access: the > authorization of a connection > through a firewall is a function of the rights and permissions ascribed to > the USER, as determined by > local policy. This is orthogonal to the identity of the proxy or intermediate > agent which the > user may optionally use, which is the only entity being authenticated by this > current draft. If the user(end-host) is not running the agent, then the user doest know about the agent. > And > that is why this approach undermines the utility of firewalls. Sorry, dont follow your logic here. > > If the authors wish to preserve their current model (i.e., if they still > don't want to adopt my > model), their model needs to be modified by having the midcom protocol convey > the user's > identity to the middlebox so that the middlebox can forward it to the Policy > Server if the Policy > Server is going to be able to authenticate and authorize that user's access > into the corporation. > I think, you have this all wrong. User has nothing to do with the MIDCOM, if the user is not running the agent. The domain administrator determines where to run the agent, how to authenticate the agent to middlebox etc.. > Some readers doubtlessly will want to object to this assertion of mine by an > argument similar to the > following: The authors indeed intended to only authenticate the MIDCOM agent > because that agent is > an adjunct to the middlebox. It is solely that adjunct's responsibility to > authenticate the user and, > only if the user passes that authentication/authorization scrutiny, will the > agent undertake to > represent that user to the middlebox. Thus, only the agent needs to be > authenticated to the middlebox > and not the user, since the agent is the agent of the user. Similarly, the > "authorization" spoken of > in the draft is an authorization for the MIDCOM agent, since the agent is > representing the user to > the middlebox and only it needs to be authorized. > More or less .. this is what the assertion is. > There are several problems with this counter-argument. I will mention only > two: > > 1) This approach opens a security loophole. A problem with this argument and > approach is that there > is no guarantee being provided that the MIDCOM agent will indeed authenticate > (and authorize) the > user, or that even if it does, it will use the same policies or MIDCOM agent doesnt authenticate the user. > authentication/authorization > system (e.g., same directory) as the firewall would have done, which is > necessary if that agent > is to operate as an adjunct to the firewall. Worse, there is no assurance > that it could do so. > Unless this "hole" is satisfactorily addressed, this whole model is broken > from a security > standpoint, since the foundation of our firewall is based upon user > authentication and access > control, which can not be guaranteed to happen nor guaranteed to happen in a > compatible way to the > firewall. [Note: any argument that your firewalls may be based more on packet > filtering upon IP > address and Port addresses than upon user-based access control will > nevertheless not deprecate > the fact that ours increasingly is -- and is increasingly based upon RBAC. > Certainly we all > can agree that to be valid, the framework must address all existing firewall > deployments, > not only a few of them.] > Sorry - I dont understand the logic. You are assuming stuff that is not stated in the document. > 2) This approach makes enterprise management much more difficult. One of the > difficulties > we face, when we try to protect our enterprises, is ensuring consistent > policy and enforcement approaches > system-wide. This approach introduces a firewall adjunct (i.e., a MIDCOM > Agent), that has undefined > mechanisms by which it conducts basic user authentication/authorization > functions. It provides no assurances > that these functions can be integrated into the current enforcement practices > of the corporation. > No tools are being proposed to help us to smoothly integrate this adjunct > into our systems, or to ensure > that the resulting system maintains the end-to-end security profile that the > firewall is designed to > provide. It is quite probable that you will claim that these issues are > out-of-scope (i.e., > not directly relevant to the midcom protocol itself). I counter that claim by > saying that it > implies a far-too-limited scope, since a fundamental requirement is that the > midcom protocol not BREAK > current firewalls. Regardless, this approach may make our jobs harder by > adding more non-integrated > elements into our system and by therefore introducing more opportunities for > us to make > mistakes. The approach appears to be introducing vulnerabilities into our > system with no provision > to patch them. Therefore, this framework is not viable from a system > perspective. What we need > is to simplify our environment, not make it monotonically more complex. This is a framework document. > > The importance to authenticate/authorize the user within the midcom protocol > is my major point > above. I have a few minor points that I'd also like to make: > > * There needs to optionally be constraints upon the "hole" which can be > opened through the > middlebox. Duration and number of sessions constraints need to be able to be > imposed. > > * The concept of "trust level" introduced in Section 5 (e.g., see section > 5.2) is inherently > problematic. This is a very fuzzy concept which is directly relevant to > particular implementation > approaches (and non-relevant to others). Please either abandon it or make it > concrete. (I'd be > interested in whether you can make it concrete without addressing my major > point above.) > > * The midcom protocol needs provisions to reduce its ability to be used as a > vehicle for Denial of > Service attacks. > What DOS attacks are you refering to? > * Establishing paths such that the same packet needs to traverse the same > firewall two or more times, > as is discussed in Section 6.3, is a VERY BAD idea. This should be explicitly > avoided and protected > against. Please re-think this point. > Please review the newer rev draft. That has a detailed illustration on this subject. > --Eric > Thanks. cheers, suresh ===== __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 18 08:44:01 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 IAA24966 for ; Fri, 18 May 2001 08:44:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27946; Fri, 18 May 2001 08:36:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27914 for ; Fri, 18 May 2001 08:36:47 -0400 (EDT) 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 IAA24711 for ; Fri, 18 May 2001 08:36:35 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4ICaMU14966; Fri, 18 May 2001 05:36:22 -0700 (PDT) Received: from spandex (rtp-vpn-121.cisco.com [10.82.192.121]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AGD01397; Fri, 18 May 2001 05:36:13 -0700 (PDT) Message-ID: <01d601c0df97$32d43e40$d45904d1@cisco.com> From: "Melinda Shore" To: "Fleischman, Eric W" , References: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12CEF@XCH-NW-01.nw.nos.boeing.com> Subject: Re: [midcom] Comments on Midcom Framework Draft (00) Date: Fri, 18 May 2001 08:36:44 -0400 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 > What is critical about this section is that it begs the question as to how such authorization > can be accomplished. That is, Section 5 is solely concerned with authenticating MIDCOM agents. > At no point does the document deal with authenticating users. However, the authorization for > applications to access internal applications/services is a function of rights and permissions > ascribed to the authenticated user. This is an important point - we are chartered with describing the requirements and framework for an interface between the middlebox and a policy server, as well, and to date those have received relatively little attention. Those who are so moved are encouraged to contribute text. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 18 08:49:29 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 IAA25162 for ; Fri, 18 May 2001 08:49:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28194; Fri, 18 May 2001 08:43:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28163 for ; Fri, 18 May 2001 08:43:53 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA24935 for ; Fri, 18 May 2001 08:43:41 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f4ICfso03529; Fri, 18 May 2001 05:41:54 -0700 (PDT) Received: from spandex (rtp-vpn-121.cisco.com [10.82.192.121]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AGD01452; Fri, 18 May 2001 05:43:19 -0700 (PDT) Message-ID: <01e701c0df98$310973e0$d45904d1@cisco.com> From: "Melinda Shore" To: "Pyda Srisuresh" , "Fleischman, Eric W" , References: <20010518043010.91026.qmail@web13801.mail.yahoo.com> Subject: Re: [midcom] Comments on Midcom Framework Draft (00) Date: Fri, 18 May 2001 08:43:47 -0400 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 > If the user(end-host) is not running the agent, then the user doest know > about the agent. Doesn't matter - if the organization's security policy includes restricting access on the basis of user identity, that identity must be communicated to the firewall so that it can be fed into the policy component as one of the parameters for an authorization decision. Note that network access policies may be different from application access policies (see my draft on application issues). Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 18 08:51:37 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 IAA25262 for ; Fri, 18 May 2001 08:51:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27676; Fri, 18 May 2001 08:31:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27647 for ; Fri, 18 May 2001 08:31:05 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA24444 for ; Fri, 18 May 2001 08:30:53 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f4ICUX928219; Fri, 18 May 2001 05:30:33 -0700 (PDT) Received: from spandex (rtp-vpn-121.cisco.com [10.82.192.121]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AGD01323; Fri, 18 May 2001 05:30:31 -0700 (PDT) Message-ID: <01cf01c0df96$6742e6a0$d45904d1@cisco.com> From: "Melinda Shore" To: "Menon, Rama R" , References: Subject: Re: [midcom] Comments on draft-ietf-midcom-framework-01.txt Date: Fri, 18 May 2001 08:31:02 -0400 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 > Specifically, during the IETF 50 MIDCOM session in Minneaplois, it was > clarified that > MIDCOM will limit its scope to NATs and firewalls - proxies, ALGs and the > like were > out-of-scope for this WG. Our job is to describe the framework and requirements for a protocol between a middlebox and something which wishes to influence the middlebox (we're calling that something a "midcom agent"). Describing the context within which the work is being done as well as issues that arise from the placement of the midcom agent are in scope. Specifying requirements for the equipment itself is not. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 18 10:08: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 KAA27413 for ; Fri, 18 May 2001 10:08:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01020; Fri, 18 May 2001 09:45:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00989 for ; Fri, 18 May 2001 09:45:42 -0400 (EDT) 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 JAA26896 for ; Fri, 18 May 2001 09:45:30 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4IDjHU15373; Fri, 18 May 2001 06:45:17 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f4IDj8w19268; Fri, 18 May 2001 06:45:09 -0700 (PDT) Message-ID: <3B052764.1D3571B9@cisco.com> Date: Fri, 18 May 2001 06:45:08 -0700 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: Pyda Srisuresh CC: midcom@ietf.org Subject: Re: [midcom] framework document References: <20010518024538.73972.qmail@web13801.mail.yahoo.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 Pyda, Let me be a bit more clear. You've chosen to take on this notion of Out-of-Path middleboxes. While such boxes *MAY* have their place, what you're essentially saying is, "punt the packet to an ALG if you don't know how to process it". Only to do what you suggest requires lots more than just a MIDCOM protocol- it requires policy-based routing or source-based routing. And it is not possible to do without additional interfaces (either real or tunneled) if you are not modifying the packet. Such constrained topology requirements will make for high MTTR when things go wrong. Why go down this route at all? Does this part of the requirement offer you great utility? This is more editorial in nature: > Section 2.9 explicitly states that the protocol facilitating the > communication between a middlebox and Policy Server need not be > part of MIDCOM protocol. Right, but I would make the statement more emphatically. Not only will it "need not be", but that we will separately consider requirements for such a protocol (hopefully briefly, since it looks like any other policy issue). In short, I want to cut short requirements discussion for policy protocols when discussing requirements for MIDCOM protocols. > I assume, you are refering to figure 1. Are you saying it is visually > better to place Policy Server to the side of middlebox. I had it that way > originally; and some folks wanted to see end-hosts by the sides. > Well, there is only so much space that draft formatting allows. Actually, all I was suggesting was starting the line from the side, not moving the box. I didn't count columns to know if ASCII art would allow you to do this. If it does not, you want to make it clear that the policy server is not using MIDCOM by drawing a dividing line, going north. If it would help I can send you a suggestion. -- Eliot Lear lear@cisco.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 18 11:22: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 LAA28698 for ; Fri, 18 May 2001 11:22:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04732; Fri, 18 May 2001 11:10:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04704 for ; Fri, 18 May 2001 11:10:38 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28444 for ; Fri, 18 May 2001 11:10:26 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f4IFAC911595; Fri, 18 May 2001 08:10:12 -0700 (PDT) Received: from spandex (rtp-vpn-121.cisco.com [10.82.192.121]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AGE01240; Fri, 18 May 2001 08:10:06 -0700 (PDT) Message-ID: <02b901c0dfac$b21407c0$d45904d1@cisco.com> From: "Melinda Shore" To: Cc: References: <20010518024538.73972.qmail@web13801.mail.yahoo.com> <3B052764.1D3571B9@cisco.com> Subject: Re: [midcom] framework document Date: Fri, 18 May 2001 11:10:37 -0400 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 > Right, but I would make the statement more emphatically. Not only will it > "need not be", but that we will separately consider requirements for such > a protocol (hopefully briefly, since it looks like any other policy > issue). In short, I want to cut short requirements discussion for policy > protocols when discussing requirements for MIDCOM protocols. You're correct in this regard, but I would add that we need to think about the policy *data*. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 18 11:26:01 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 LAA28749 for ; Fri, 18 May 2001 11:26:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04638; Fri, 18 May 2001 11:08:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04608 for ; Fri, 18 May 2001 11:08:37 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28407 for ; Fri, 18 May 2001 11:08:25 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f4IF86d09079; Fri, 18 May 2001 08:08:06 -0700 (PDT) Received: from spandex (rtp-vpn-121.cisco.com [10.82.192.121]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AGE01193; Fri, 18 May 2001 08:08:02 -0700 (PDT) Message-ID: <02b201c0dfac$682fb5a0$d45904d1@cisco.com> From: "Melinda Shore" To: , Date: Fri, 18 May 2001 11:08:32 -0400 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 Subject: [midcom] Updated framework draft 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 More comments: section 2.9: A policy server would not add or delete midcom agents on a middlebox. It would authorize or terminate authorization for an agent, it seems to me. All it can do is provide policy information. 5.2: I'm still not clear on where you're going (or why) with the out-of-band agent stuff. There were still a lot of questions about it coming out of the Minneapolis meeting and I'm not sure that they've been resolved. At this point I think it would be useful to hear from other people who see the need to include out-of-band agents in the framework. 6.0 Same as 2.9 - a policy server performs in an advisory capacity only. It can inform a middlebox that an agent is no longer authorized, but it cannot "delete" an agent. It's up to the middlebox to do that. I'm also not comfortable with the text around determining trust levels. It sounds like you're suggesting that the policy server probe the agent and then make its own determination about to what extent the agent can be trusted. Is that really what you mean? 6.1 I still don't like the appearance of AH and ESP in the text - if nothing else, given that particular range of options I'd personally prefer ESP for authentication, too. But aside from that, there are all sorts of mechanisms that could be used to provide authentication, integrity, and confidentiality, and given the interest in performance I might be inclined to put IPSec down towards the bottom of the list (assuming that you were planning on using IKE for SA establishment - were you?). In general we need to talk about *why* various protections are required rather than specifically what those protections would be. For example, a consequence of not authenticating an agent would be that an attacker could spoof the identity of a "legitimate" agent and open holes in the firewall. Another would be that it could otherwise manipulate state on a middlebox, creating a denial- of-service attack by closing needed pinholes or filling up a NAT table. A consequence of not authenticating the middlebox to an agent is that an attacker could pose as a middlebox and respond to NAT requests in a manner that would divert data to the attacker. And so on. Save discussion of mechanism until we have a basic understanding of what it is that we need to protect against. Also, I'm not clear why you have this section *and* a "security considerations" section. 6.2 Establishing a transport connection only involves authentication if you're using IPSec. (BTW, it may be worth tweaking the language so that it's still meaningful if the midcom protocol runs over UDP.) In terms of when to register, it may be worth pointing out that when you're using a session-oriented protocol with a NAT, you'll need to get a NAT table mapping *prior* to trying to establish a NATted stream, since the address will have to be embedded in the session signaling payload. In the last paragraph you suggest that the policy server tells the middlebox to deregister an agent. Too much information! A middlebox could deregister an agent for a lot of reasons, policy being one of them. 12: still really doesn't talk about the threat environment and largely repeats what's in 6.1. Aside from that, I think that I'd probably add some text to the effect that because stateful inspection firewalls and NATs require access to data in the clear, the use of traditional firewalls/NATs has mitigated against the use of encryption in some environments. Similarly, the use of stateful inspection and rewrite NATs has prevented the use of integrity protection on data streams expected to traverse NATs. By moving application state out of the middleboxes we're allowing applications to better protect themselves end-to-end. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 18 13:27:44 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 NAA02666 for ; Fri, 18 May 2001 13:27:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09735; Fri, 18 May 2001 13:14:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09697 for ; Fri, 18 May 2001 13:14:31 -0400 (EDT) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02057 for ; Fri, 18 May 2001 13:14:20 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id KAA17888; Fri, 18 May 2001 10:13:51 -0700 Received: from hursley.ibm.com ([9.29.3.172]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id KAA23364; Fri, 18 May 2001 10:13:56 -0700 Message-ID: <3B0557D2.BBF5E5F1@hursley.ibm.com> Date: Fri, 18 May 2001 12:11:46 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Melinda Shore CC: lear@cisco.com, midcom@ietf.org Subject: Re: [midcom] framework document References: <20010518024538.73972.qmail@web13801.mail.yahoo.com> <3B052764.1D3571B9@cisco.com> <02b901c0dfac$b21407c0$d45904d1@cisco.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 Melinda Shore wrote: > > > Right, but I would make the statement more emphatically. Not only will it > > "need not be", but that we will separately consider requirements for such > > a protocol (hopefully briefly, since it looks like any other policy > > issue). In short, I want to cut short requirements discussion for policy > > protocols when discussing requirements for MIDCOM protocols. > > You're correct in this regard, but I would add that we > need to think about the policy *data*. Maybe a bit more abstract - at least an informal policy model, even if you don't want to go as far as the formal models of the POLICY WG. In any case there is enough policy distribution work elsewhere in the IETF (SNMPCONF, RAP) that it certainly shouldn't be a job for midcom. Brian _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri May 18 16:50:53 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 QAA16135 for ; Fri, 18 May 2001 16:50:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18864; Fri, 18 May 2001 16:43:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18833 for ; Fri, 18 May 2001 16:43:07 -0400 (EDT) Received: from mail.netscreen.com ([63.126.135.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15893 for ; Fri, 18 May 2001 16:42:56 -0400 (EDT) Received: from ns-ca.netscreen.com (ns-ca.netscreen.com [10.100.10.21]) by mail.netscreen.com (8.10.0/8.10.0) with ESMTP id f4IKQOA31568; Fri, 18 May 2001 13:26:24 -0700 Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Fri, 18 May 2001 13:40:02 -0700 Message-ID: <9D048F4A422CD411A56500B0D0209C5B8B1751@NS-CA> From: Wanqun Bao To: "'lear@cisco.com'" , Pyda Srisuresh Cc: midcom@ietf.org Subject: RE: [midcom] framework document Date: Fri, 18 May 2001 13:40:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 >> I assume, you are refering to figure 1. Are you saying it is visually >> better to place Policy Server to the side of middlebox. I had it that way >> originally; and some folks wanted to see end-hosts by the sides. >> Well, there is only so much space that draft formatting allows. >Actually, all I was suggesting was starting the line from the side, not >moving the box. I didn't count columns to know if ASCII art would allow >you to do this. If it does not, you want to make it clear that the policy >server is not using MIDCOM by drawing a dividing line, going north. If it >would help I can send you a suggestion. >-- >Eliot Lear >lear@cisco.com One way to do this is to add a "Policy Interface" in the middlebox and let the "Policy Server" to point to it. I made a change in both Fig.1 and Fig. 2 as below. Note that I removed one of the box for "MIDCOM agent co-resident on End-hosts" in Fig. 1 because I think one such logical entity is enough for this diagram. Cheers, Wanqun Bao wbao@netscreen.com +---------------+ +---------------+ +-------------+ | MIDCOM agent | | MIDCOM agent | | Stand-alone | | co-resident on| | co-resident on| | MIDCOM agent| | Proxy Server | | Application GW| | | +---------------+ +---------------+ +-------------+ ^ ^ ^ | | | +--------+ | | | | Policy | | | | +-| Server | | | | / +--------+ | | MIDCOM | / +-------------+ | | Protocol | / | MIDCOM agent| | | | / | co-resident | | | | / | on End-hosts|<-+ | | | / +-------------+ | | | | | v v v v v +-------------------------------------------+ |Middlebox Communication Protocol|Policy | | (MIDCOM)Interface |Interface | +----------+--------+-----------+-----------+ Middlebox | | | | | Functions | Firewall | NAT | DiffServ- | Intrusion | | | | QOS | Detection | +----------+--------+-----------+-----------+ Middlebox | Firewall ACLs, Session-descriptors, | Managed | NAT-BINDs, NAT Address-Maps and other | Resources | other Middlebox function attributes | +-------------------------------------------+ Figure 1: MIDCOM agents interfacing with a middlebox +-----------+ | Middlebox | | Policy | | Server |~~~~~~~~~~~~| +-----------+ \ \ +---------+ \ | SIP |___ \ ________| Proxy | \ Middlebox \ / +---------+.. | +-----------------+ | : | MIDCOM | | | | RSTP +----------+ :..|........|MIDCOM |POLICY | SIP | ____| RSTP |.....|........|PROTOCOL |INTER- | | / | Proxy |___ | |INTERFACE|FACE | | | +----------+ \ \ |-----------------| | | \ \------| | | | \--------| | | | -----| FIREWALL |-->-- +-----------+ /-----| |--<-- +-----------+| Data streams // +-----------------+ +-----------+||----------->----// | |end-hosts ||------------<----- . +-----------+ (RTP, RSTP data, etc.) | . Outside the Within a private domain | private domain Legend: ---- Application data path datagrams ____ Application control path datagrams .... Middlebox Communication Protocol (MIDCOM) ~~~~ MIDCOM Policy Server Interface | . private domain Boundary | Figure 2: In-Path MIDCOM Agents for Middlebox Communication _______________________________________________ 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 Sat May 19 23:24:59 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 XAA19855 for ; Sat, 19 May 2001 23:24:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA06309; Sat, 19 May 2001 23:19:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA06286 for ; Sat, 19 May 2001 23:19:36 -0400 (EDT) Received: from web13806.mail.yahoo.com (web13806.mail.yahoo.com [216.136.175.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA19824 for ; Sat, 19 May 2001 23:19:23 -0400 (EDT) Message-ID: <20010520031936.74950.qmail@web13806.mail.yahoo.com> Received: from [65.12.33.187] by web13806.mail.yahoo.com; Sat, 19 May 2001 20:19:36 PDT Date: Sat, 19 May 2001 20:19:36 -0700 (PDT) From: Pyda Srisuresh Subject: RE: [midcom] framework document To: Wanqun Bao , "'lear@cisco.com'" Cc: midcom@ietf.org In-Reply-To: <9D048F4A422CD411A56500B0D0209C5B8B1751@NS-CA> 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 Having a Policy interface distinct from MIDCOM protocol interface does make it clearer. Thanks, Wanqun. I will use both your figures (and expand figure 3 as well accordingly). cheers, suresh --- Wanqun Bao wrote: > >> I assume, you are refering to figure 1. Are you saying it is visually > >> better to place Policy Server to the side of middlebox. I had it that way > >> originally; and some folks wanted to see end-hosts by the sides. > >> Well, there is only so much space that draft formatting allows. > > >Actually, all I was suggesting was starting the line from the side, not > >moving the box. I didn't count columns to know if ASCII art would allow > >you to do this. If it does not, you want to make it clear that the policy > >server is not using MIDCOM by drawing a dividing line, going north. If it > >would help I can send you a suggestion. > >-- > >Eliot Lear > >lear@cisco.com > > One way to do this is to add a "Policy Interface" in the middlebox and > let the "Policy Server" to point to it. I made a change in both Fig.1 and > Fig. 2 as below. Note that I removed one of the box for "MIDCOM agent > co-resident on End-hosts" in Fig. 1 because I think one such logical > entity is enough for this diagram. > > Cheers, > > Wanqun Bao > wbao@netscreen.com > > > +---------------+ +---------------+ +-------------+ > | MIDCOM agent | | MIDCOM agent | | Stand-alone | > | co-resident on| | co-resident on| | MIDCOM agent| > | Proxy Server | | Application GW| | | > +---------------+ +---------------+ +-------------+ > ^ ^ ^ > | | | +--------+ > | | | | Policy | > | | | +-| Server | > | | | / +--------+ > | | MIDCOM | / > +-------------+ | | Protocol | / > | MIDCOM agent| | | | / > | co-resident | | | | / > | on End-hosts|<-+ | | | / > +-------------+ | | | | | > v v v v v > +-------------------------------------------+ > |Middlebox Communication Protocol|Policy | > | (MIDCOM)Interface |Interface | > +----------+--------+-----------+-----------+ > Middlebox | | | | | > Functions | Firewall | NAT | DiffServ- | Intrusion | > | | | QOS | Detection | > +----------+--------+-----------+-----------+ > Middlebox | Firewall ACLs, Session-descriptors, | > Managed | NAT-BINDs, NAT Address-Maps and other | > Resources | other Middlebox function attributes | > +-------------------------------------------+ > > Figure 1: MIDCOM agents interfacing with a middlebox > > > > > +-----------+ > | Middlebox | > | Policy | > | Server |~~~~~~~~~~~~| > +-----------+ \ > \ > +---------+ \ > | SIP |___ \ > ________| Proxy | \ Middlebox \ > / +---------+.. | +-----------------+ > | : | MIDCOM | | | > | RSTP +----------+ :..|........|MIDCOM |POLICY | > SIP | ____| RSTP |.....|........|PROTOCOL |INTER- | > | / | Proxy |___ | |INTERFACE|FACE | > | | +----------+ \ \ |-----------------| > | | \ \------| | > | | \--------| | > | | -----| FIREWALL |-->-- > +-----------+ /-----| |--<-- > +-----------+| Data streams // +-----------------+ > +-----------+||----------->----// | > |end-hosts ||------------<----- . > +-----------+ (RTP, RSTP data, etc.) | > . Outside the > Within a private domain | private domain > > Legend: ---- Application data path datagrams > ____ Application control path datagrams > .... Middlebox Communication Protocol (MIDCOM) > ~~~~ MIDCOM Policy Server Interface > | > . private domain Boundary > | > > > Figure 2: In-Path MIDCOM Agents for Middlebox Communication > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom ===== __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sun May 20 02: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 CAA01674 for ; Sun, 20 May 2001 02:09:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA16729; Sun, 20 May 2001 01:57:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA16700 for ; Sun, 20 May 2001 01:57:08 -0400 (EDT) Received: from web13802.mail.yahoo.com (web13802.mail.yahoo.com [216.136.175.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23646 for ; Sun, 20 May 2001 01:56:58 -0400 (EDT) Message-ID: <20010520055710.83333.qmail@web13802.mail.yahoo.com> Received: from [65.12.33.187] by web13802.mail.yahoo.com; Sat, 19 May 2001 22:57:10 PDT Date: Sat, 19 May 2001 22:57:10 -0700 (PDT) From: Pyda Srisuresh To: Melinda Shore , midcom@ietf.org In-Reply-To: <02b201c0dfac$682fb5a0$d45904d1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [midcom] Policy Server interface (Was - Re: Updated framework draft) 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 Melinda, I take your comments below to be largely divided into 3 areas - (a) Policy Server Interface (b) Security considerations, (c) Out-of-Path agents . I will respond to the first two areas in this thread. Here is my basic view of the Policy Server Interface. I will use the following as the basis to address your concerns. These are the same principles that drove the text in the draft as well. Hope this will address the concerns raised by others (Eliot Lear, Eric Fliieshman etc.) as well. 1. An external Policy Server is not an absolute requirement on the middlebox. By that I mean that Policy Server function may be embedded within the middlebox. I.e., Agents may be pre-registered on the middlebox (or) may be registered on a Policy Server. 2. A Policy Server will have the following information concerning agents. Agent | Authorization Policy | Access (or) | Security Profile |(ie, sessions for which | Connectivity |(MIDCOM Message | agent is authorized) | Profile | level security) ---------|------------------------|--------------|------------------- Agent-1 |(, |Agent Type | Authentication, | , |(In-Path/OOP),| integrity and | |Accessibility,| confidentiality | |Host-auth info| requirements ---------|------------------------|--------------|------------------- Agent-2 |(, |Agent Type | Authentication, | , |(In-Path/OOP),| integrity and | |Accessibility,| confidentiality | |Host-auth info| requirements ---------|------------------------|--------------|------------------- ..... 3. Lastly, Policy Server may be consulted by the middlebox only during agent connection setup phase(not during run time). Further, when an agent is deregistered on a Policy Server (or) when deemed administratively appropriate by the Policy Server, the policy Server may notify the middlebox that a particular MIDCOM agent is no longer authorized. Please see my responses to your specific comments below. --- Melinda Shore wrote: > More comments: > > section 2.9: A policy server would not add or delete > midcom agents on a middlebox. It would authorize or > terminate authorization for an agent, it seems to me. > All it can do is provide policy information. > I disagree. See item (3) above. <... stuff deleted> > 6.0 Same as 2.9 - a policy server performs in an > advisory capacity only. It can inform a middlebox > that an agent is no longer authorized, but it cannot > "delete" an agent. It's up to the middlebox to do > that. I'm also not comfortable with the text around > determining trust levels. It sounds like you're > suggesting that the policy server probe the agent > and then make its own determination about to what > extent the agent can be trusted. Is that really > what you mean? > I dont understand where you picked up this noton that Policy Server is directly probing the agent. I dont recall ever stating this in the draft. I will be glad to fix any specific text that may have caused this mistaken notion. Thanks. Let me restate. - Policy Server is in the advisory capacity. - Policy Server is allowed to notify the middlebox to delete existing agents. - There is no direct communciation ever implied between the agent and the Policy Server. > 6.1 I still don't like the appearance of AH and ESP > in the text - if nothing else, given that particular > range of options I'd personally prefer ESP for > authentication, too. But aside from that, there are > all sorts of mechanisms that could be used to provide > authentication, integrity, and confidentiality, and > given the interest in performance I might be inclined > to put IPSec down towards the bottom of the list > (assuming that you were planning on using IKE for SA > establishment - were you?). In general we need to > talk about *why* various protections are required rather > than specifically what those protections would be. What is needed are as stated in item 2 above - Host authentication, Message level authentication, integrity and confidentiality. Section 6.1 addresses these requirements. Further, it identifies known ways of addressing these requirements - (a) source-address based security, (b) TLS based security, (c) IPsec based security. Are you averse to mentioning the mechansims? (or) do you find the list inadequate? And, why do you have a problem with listing the IPsec mechanism upfront? The document makes no specific recommendation of any of the mechansims specified. As for the why - it is listed under the security considerations section. > For example, a consequence of not authenticating > an agent would be that an attacker could spoof the > identity of a "legitimate" agent and open holes in > the firewall. Another would be that it could otherwise > manipulate state on a middlebox, creating a denial- > of-service attack by closing needed pinholes or filling > up a NAT table. A consequence of not authenticating > the middlebox to an agent is that an attacker could > pose as a middlebox and respond to NAT requests in a > manner that would divert data to the attacker. And Well, all this is stated in the Secutities considerations section even though, it might be hard to decipher. I do like your text composition and will be glad to use that in the follow-on rev. > so on. Save discussion of mechanism until we have a > basic understanding of what it is that we need to > protect against. What is the problem in stating the well-known mechanisms? The reader can relate to it quickly. > > Also, I'm not clear why you have this section *and* a > "security considerations" section. > The securities consideration section addresses (a) "Why" on secure communication between middlebox and agent, (b) Security vulnerability to applications being controlled by multiple agents. > 6.2 Establishing a transport connection only involves > authentication if you're using IPSec. (BTW, it may What is a transport connection to do with IPsec? Transport connection simply requires a host-based authentication. > be worth tweaking the language so that it's still meaningful > if the midcom protocol runs over UDP.) In terms of when The text makes no reference to TCP or UDP based connection. > to register, it may be worth pointing out that when > you're using a session-oriented protocol with a NAT, > you'll need to get a NAT table mapping *prior* to > trying to establish a NATted stream, since the address > will have to be embedded in the session signaling > payload. In the last paragraph you suggest that the > policy server tells the middlebox to deregister an agent. > Too much information! A middlebox could deregister an > agent for a lot of reasons, policy being one of them. > Isnt that what the text says? Policy Server notifying the middlebox is a way by which the middlebox could disconnect an agent. > 12: still really doesn't talk about the threat environment > and largely repeats what's in 6.1. Aside from that, I See my comments earlier. > think that I'd probably add some text to the effect that > because stateful inspection firewalls and NATs require > access to data in the clear, the use of traditional > firewalls/NATs has mitigated against the use of encryption > in some environments. This is nothing more than is inherently a requirement from the middleboxes, with or without MIDCOM, right? I agree, it is still worthwhile to state this one more time. > Similarly, the use of stateful > inspection and rewrite NATs has prevented the use of > integrity protection on data streams expected to traverse > NATs. Same as above. > By moving application state out of the middleboxes > we're allowing applications to better protect themselves > end-to-end. > This is true only when the agent is running on the end-host. > > Melinda > > cheers, suresh __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sun May 20 10:01:40 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 KAA10474 for ; Sun, 20 May 2001 10:01:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25313; Sun, 20 May 2001 09:52:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25283 for ; Sun, 20 May 2001 09:52:20 -0400 (EDT) Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10413 for ; Sun, 20 May 2001 09:52:08 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f4KDpr920400; Sun, 20 May 2001 06:51:54 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f4KDpxu14548; Sun, 20 May 2001 06:51:59 -0700 (PDT) Received: from spandex (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with SMTP id GAA18552; Sun, 20 May 2001 06:51:47 -0700 (PDT) Message-ID: <010e01c0e134$1733e5c0$d45904d1@trashbag.to> From: "Melinda Shore" To: "Pyda Srisuresh" , References: <20010520055710.83333.qmail@web13802.mail.yahoo.com> Date: Sun, 20 May 2001 09:52:19 -0400 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 Subject: [midcom] Re: Policy Server interface (Was - Re: Updated framework draft) 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. An external Policy Server is not an absolute requirement on the > middlebox. By that I mean that Policy Server function may be > embedded within the middlebox. Of course, but we need for that function to be addressed, regardless of whether it sits on the middlebox or sits elsewhere. It's the same as the situation with an agent, which may sit on the middlebox (for example, a stateful inspection firewall is implicitly running a midcom function between the stateful inspection element and the filtering policy element. We need for this to be clearer, whether it's addressed in this document or in another. Even if you don't accept this in principal, for practical purposes I should point out that it was the ADs who added the policy deliverable to our charter, so I would guess that failing to more fully consider the policy function will delay the approval of the documents. > 3. Lastly, Policy Server may be consulted by the middlebox only during > agent connection setup phase(not during run time). Not necessarily. What is your reason for saying that? > - Policy Server is in the advisory capacity. > - Policy Server is allowed to notify the middlebox to delete > existing agents. > - There is no direct communciation ever implied between > the agent and the Policy Server. Okay! The source of the confusion is the language: in several places you have said that the policy server, for example, deletes agents on a middlebox. It can't do that. > What is needed are as stated in item 2 above - Host authentication, > Message level authentication, integrity and confidentiality. Why? I don't get that from your document, and one thing I know for a fact is that when a draft says "we will use IPSec or TLS to protect our protocol" it means that they haven't thought very hard about security issues. > Section 6.1 addresses these requirements. Further, it identifies > known ways of addressing these requirements - (a) source-address > based security, (b) TLS based security, (c) IPsec based security. > Are you averse to mentioning the mechansims? (or) do you find > the list inadequate? I find it inappropriate. 1) Identify the problem to be solved, and 2) select the best mechanism. Security mechanisms are generally expensive and inconvenient and difficult to do correctly. It's important not to be cavalier about it, especially when we're talking about a protocol that 1) pokes holes in firewalls, and 2) tells endhosts to divert their data streams. > And, why do you have a problem with listing the IPsec mechanism > upfront? Because I don't know if IPSec is the best way to protect the protocol that has yet to be identified here. There's a very good chance that it's not. > What is the problem in stating the well-known mechanisms? > The reader can relate to it quickly. But you're not talking about why you're selecting those mechanisms. The naive reader may be able to relate to it, but I'm not sure that it's going to be useful to aid in protocol selection and design. > What is a transport connection to do with IPsec? Transport > connection simply requires a host-based authentication. Perhaps we need a definition of "transport" in the terminology section so that it's clear what's meant in this section. > > > be worth tweaking the language so that it's still meaningful > > if the midcom protocol runs over UDP.) In terms of when > > The text makes no reference to TCP or UDP based connection. Right! And we don't want to use language that's exclusive of UDP. > Isnt that what the text says? Policy Server notifying the > middlebox is a way by which the middlebox could disconnect > an agent. I think you'll need to add some text in that section to make it clear that the policy server asking the middlebox to terminate its connection with and/or registration of an agent is one way among many. > This is nothing more than is inherently a requirement from > the middleboxes, with or without MIDCOM, right? > I agree, it is still worthwhile to state this one more time. I think it's a security consideration. > > By moving application state out of the middleboxes > > we're allowing applications to better protect themselves > > end-to-end. > This is true only when the agent is running on the end-host. Nope. It doesn't matter where the agent is, as long as it's able to provide sufficient information to the middlebox to allow the middlebox to pass encrypted or integrity- protected data. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon May 21 13:11: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 NAA13957 for ; Mon, 21 May 2001 13:11:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15468; Mon, 21 May 2001 12:56:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15437 for ; Mon, 21 May 2001 12:56:44 -0400 (EDT) Received: from web13807.mail.yahoo.com ([216.136.175.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13251 for ; Mon, 21 May 2001 12:56:30 -0400 (EDT) Message-ID: <20010521165641.21199.qmail@web13807.mail.yahoo.com> Received: from [65.12.33.187] by web13807.mail.yahoo.com; Mon, 21 May 2001 09:56:41 PDT Date: Mon, 21 May 2001 09:56:41 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Re: Policy Server interface (Was - Re: Updated framework draft) To: Melinda Shore , midcom@ietf.org In-Reply-To: <010e01c0e134$1733e5c0$d45904d1@trashbag.to> 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 --- Melinda Shore wrote: > > 1. An external Policy Server is not an absolute requirement on the > > middlebox. By that I mean that Policy Server function may be > > embedded within the middlebox. > > Of course, but we need for that function to be addressed, > regardless of whether it sits on the middlebox or sits > elsewhere. It's the same as the situation with an agent, > which may sit on the middlebox (for example, a stateful > inspection firewall is implicitly running a midcom function > between the stateful inspection element and the filtering > policy element. > > We need for this to be clearer, whether it's addressed in > this document or in another. Even if you don't accept this > in principal, for practical purposes I should point out that > it was the ADs who added the policy deliverable to our > charter, so I would guess that failing to more fully > consider the policy function will delay the approval > of the documents. > Melinda - There is no disagreement thus far. I do understand the need for a Policy Server and that is why we have a dedicated section in the framework draft to address the policy Server. I am OK with changing the text wherever necessary to make the draft a better read. But, Fundamentally, there has to be a common understanding of what the function of a Policy Server is. It is with this in mind that I listed the three guiding principles (in my previous e-mail) to state my view of the Policy Server. > > 3. Lastly, Policy Server may be consulted by the middlebox only during > > agent connection setup phase(not during run time). > > Not necessarily. What is your reason for saying that? Hmm.. This is perhaps the big source of confusion that needs to be cleared. I believe, the policy server is a repertoire of information pertaining to various agents (that can connect to middlebox). The Policy server has no knowledge of middlebox service and as such cannot help a middlebox with any of the run-time policy decisions pertaining to middlebox resource control. I would like to understand why you said "Not necessarily". > > > - Policy Server is in the advisory capacity. > > - Policy Server is allowed to notify the middlebox to delete > > existing agents. > > - There is no direct communciation ever implied between > > the agent and the Policy Server. > > Okay! The source of the confusion is the language: > in several places you have said that the policy server, > for example, deletes agents on a middlebox. It can't > do that. > In that case, I will be glad to fix the text in all the places where it says the above. What I really meant to say was that a Policy Server may notify the middlebox to delete existing agents. > > What is needed are as stated in item 2 above - Host authentication, > > Message level authentication, integrity and confidentiality. > > Why? I don't get that from your document, and one thing > I know for a fact is that when a draft says "we will use > IPSec or TLS to protect our protocol" it means that they > haven't thought very hard about security issues. > Isnt this mentioned in the first paragraph of section 6.1? Let me try and expand on the text further. > > Section 6.1 addresses these requirements. Further, it identifies > > known ways of addressing these requirements - (a) source-address > > based security, (b) TLS based security, (c) IPsec based security. > > Are you averse to mentioning the mechansims? (or) do you find > > the list inadequate? > > I find it inappropriate. 1) Identify the problem to be > solved, and 2) select the best mechanism. Security mechanisms > are generally expensive and inconvenient and difficult to > do correctly. It's important not to be cavalier about it, Melinda - tell me a framework document that discusses security and does not mention IPsec as an option? Trust and Security are important to ensure when an external agent is controlling middlebox resources. The agent has to be trusted, just as much as the transport path in which the communication takes place. As such, the transport path has to be secured, even if the agent is trusted. Ipsec and TLS are two most common mechansims used for the security of transport path. Simple Source-address based security may be permitted in a trusted domain and should be limited only to the most trusted hosts. As for problem identification - I believe, the text in section 6.1 does that. But, I will try to expand on the text to make it clearer. Thanks for your feedback. > especially when we're talking about a protocol that 1) > pokes holes in firewalls, and 2) tells endhosts to divert ^^^^^^^^^^^^^^^^^^^^^^^^ > their data streams. > ^^^^^^^^^^^^^^^^^^^ MIDCOM protocol only tells the middlebox (not end-hosts) to divert the data streams. > > And, why do you have a problem with listing the IPsec mechanism > > upfront? > > Because I don't know if IPSec is the best way to > protect the protocol that has yet to be identified > here. There's a very good chance that it's not. > I believe, the last pragraph in section 6.1 implies IPsec and TLS as the only mechanisms to authenticate. Sorry, that was not the intent. I will remove the text in parenthesis. However, nowhere in the document is it said that IPsec is the best way to protect messages. > > What is the problem in stating the well-known mechanisms? > > The reader can relate to it quickly. > > But you're not talking about why you're selecting those > mechanisms. The naive reader may be able to relate to it, > but I'm not sure that it's going to be useful to aid in > protocol selection and design. > See my previous responses. > > What is a transport connection to do with IPsec? Transport > > connection simply requires a host-based authentication. > > Perhaps we need a definition of "transport" in the terminology > section so that it's clear what's meant in this section. > MIDCOM transport connection establishment simply requires host-based authentication. > > > > > be worth tweaking the language so that it's still meaningful > > > if the midcom protocol runs over UDP.) In terms of when > > > > The text makes no reference to TCP or UDP based connection. > > Right! And we don't want to use language that's exclusive > of UDP. > > > Isnt that what the text says? Policy Server notifying the > > middlebox is a way by which the middlebox could disconnect > > an agent. > > I think you'll need to add some text in that section to > make it clear that the policy server asking the middlebox > to terminate its connection with and/or registration of > an agent is one way among many. > OK. > > This is nothing more than is inherently a requirement from > > the middleboxes, with or without MIDCOM, right? > > I agree, it is still worthwhile to state this one more time. > > I think it's a security consideration. > OK. > > > By moving application state out of the middleboxes > > > we're allowing applications to better protect themselves > > > end-to-end. > > This is true only when the agent is running on the end-host. > > Nope. It doesn't matter where the agent is, as long as > it's able to provide sufficient information to the middlebox > to allow the middlebox to pass encrypted or integrity- > protected data. > That assumes that agent will have the same end-to-end ability as the end-host to interpret encrypted and integrity protected data, right? > Melinda > Thanks. cheers, suresh __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon May 21 13:42:51 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 NAA14790 for ; Mon, 21 May 2001 13:42:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16712; Mon, 21 May 2001 13:29:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16682 for ; Mon, 21 May 2001 13:29:53 -0400 (EDT) Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14357 for ; Mon, 21 May 2001 13:29:39 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4LHTTU05252; Mon, 21 May 2001 10:29:29 -0700 (PDT) Received: from spandex (rtp-vpn-69.cisco.com [10.82.192.69]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AGK03176; Mon, 21 May 2001 10:29:19 -0700 (PDT) Message-ID: <01f601c0e21b$a58ab820$d45904d1@cisco.com> From: "Melinda Shore" To: "Pyda Srisuresh" , References: <20010521165641.21199.qmail@web13807.mail.yahoo.com> Subject: Re: [midcom] Re: Policy Server interface (Was - Re: Updated framework draft) Date: Mon, 21 May 2001 13:29:52 -0400 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 believe, the policy server is a repertoire of information pertaining to > various agents (that can connect to middlebox). The Policy server has no > knowledge of middlebox service and as such cannot help a middlebox with > any of the run-time policy decisions pertaining to middlebox resource > control. All the policy server can do is manage and distribute policy data. That data could potentially be pretty much anything, and since we haven't yet talked much about what kind of data would be needed to support firewall and NAT services I think it's premature to say that it will never be consulted during a middlebox transaction. > Melinda - tell me a framework document that discusses security and > does not mention IPsec as an option? Trust and Security are important > to ensure when an external agent is controlling middlebox resources. > The agent has to be trusted, just as much as the transport path in > which the communication takes place. As such, the transport path > has to be secured, even if the agent is trusted. Ipsec and TLS are > two most common mechansims used for the security of transport path. Why specifically does it have to be trusted? What are the threats? How do we increase the likelihood that we will be selecting the correct mechanism? Why would IPSec be a better choice for a midcom protocol than, say, Kerberos? > > especially when we're talking about a protocol that 1) > > pokes holes in firewalls, and 2) tells endhosts to divert > ^^^^^^^^^^^^^^^^^^^^^^^^ > > their data streams. > > ^^^^^^^^^^^^^^^^^^^ > MIDCOM protocol only tells the middlebox (not end-hosts) to divert > the data streams. Picture this: I am an attacker posing as a middlebox. A SIP proxy server behind a NAT is functioning as a midcom agent, and I spoof my identity so that it registers with me. It then sends a request for a NAT table mapping for an RTP port, and I send it back the address of my handy-dandy data recorder. The SIP proxy server has no reason to think that there's anything wrong with the transaction and it puts the bogus address in the SDP for the INVITE. The call is established and the other party then duly ships off its outgoing RTP to my recorder. > MIDCOM transport connection establishment simply requires host-based > authentication. Not necessarily. > > Nope. It doesn't matter where the agent is, as long as > > it's able to provide sufficient information to the middlebox > > to allow the middlebox to pass encrypted or integrity- > > protected data. > That assumes that agent will have the same end-to-end ability as > the end-host to interpret encrypted and integrity protected > data, right? No, that's a different question. By removing the need for the middlebox inspect or manipulate data as they traverse it, we're allowing end-to-end security mechanisms to be used where it hasn't been possible in the past. The agent is involved only in that it's asking the middlebox to open holes, install NAT table entries, etc. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon May 21 15:50:28 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 PAA17279 for ; Mon, 21 May 2001 15:50:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21736; Mon, 21 May 2001 15:30:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21692 for ; Mon, 21 May 2001 15:30:34 -0400 (EDT) Received: from acmepacket.com ([63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16976 for ; Mon, 21 May 2001 15:30:20 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AC751020240; Mon, 21 May 2001 15:28:53 -0400 Message-ID: <006901c0e22c$a86f9fe0$2300000a@acmepacket.com> From: "Bob Penfield" To: "midcom mail-list" Date: Mon, 21 May 2001 15:31:39 -0400 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 Subject: [midcom] framework examples 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 have a few issues with the SIP examples in section 7. Having the SIP Proxy be part of the private domain might be a little more realistic. I doubt people are going to let external MIDCOM agents control their private Middleboxes. For the example in 7.1, the request to the middlebox to permit the Pri-to-ext flow should be done before the INVITE is sent on to the private SIP phone (assuming the INVITE has an SDP payload). In SIP, the calling party (external SIP phone in the example) must be ready to receive the media when it sends the INVITE with a session description. If the called party (internal phone) assumes this and sends "early media" (as described in 2.3.4 of the scenarios draft) before sending the 200 OK response, the firewall will block these packets. For the example in 7.2, I don't believe there is any need to modify SDP parameters in the ACK. Since the calling party is external, 'Ea' would be a global IP address that would not need to be changed. However, some of the SIP headers (To, From, Via, Contact) would require modification if they had IP addresses in them. Also, typically the SDP payload is sent with the INVITE as opposed to the ACK. The BYE request does not usually have an SDP payload, but you might have to modify SIP headers. For the example in 7.3, the notations of addresses and ports with RTP and F-RTP are a bit confusing. Shouldn't the Create NAT bind RTPx to F-RTPx? Also, In 7.1, there are 2 "permit" requests. Here they are combined into one. Is there really a difference? Also, could the "Create NAT" request imply a "permit" (why would you create a NAT if you we're going to allow the packets to flow?). This is probably a requirements issue, but I believe that most people feel the number of messages between a MIDCOM agent and a middlebox should be minimized in order to maximize performance. (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue May 22 07:15:22 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 HAA13332 for ; Tue, 22 May 2001 07:15:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00424; Tue, 22 May 2001 07:04:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00394 for ; Tue, 22 May 2001 07:04:30 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13051; Tue, 22 May 2001 07:04:14 -0400 (EDT) Message-Id: <200105221104.HAA13051@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 22 May 2001 07:04:14 -0400 Subject: [midcom] I-D ACTION:draft-ietf-midcom-scenarios-02.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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : MIDCOM Scenarios Author(s) : C. Huitema Filename : draft-ietf-midcom-scenarios-02.txt Pages : 19 Date : 21-May-01 As trusted third parties are increasingly being asked to make policy decisions on behalf of the various entities participating in an application's operation, a need has developed for applications to be able to communicate their needs to the devices in the network that provide transport policy enforcement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-scenarios-02.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-ietf-midcom-scenarios-02.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-ietf-midcom-scenarios-02.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010521131340.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-scenarios-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-scenarios-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010521131340.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom