From exim@www1.ietf.org Mon Feb 2 16:46:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14994 for ; Mon, 2 Feb 2004 16:46:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnltT-00038z-1r for midcom-archive@odin.ietf.org; Mon, 02 Feb 2004 16:46:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12LkAIN012061 for midcom-archive@odin.ietf.org; Mon, 2 Feb 2004 16:46:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnltJ-00036x-HN; Mon, 02 Feb 2004 16:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anlso-00036P-Cl for midcom@optimus.ietf.org; Mon, 02 Feb 2004 16:45:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14858 for ; Mon, 2 Feb 2004 16:45:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anlsm-00008Y-00 for midcom@ietf.org; Mon, 02 Feb 2004 16:45:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anlre-0007kw-00 for midcom@ietf.org; Mon, 02 Feb 2004 16:44:19 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Anlqs-0007Yn-00 for midcom@ietf.org; Mon, 02 Feb 2004 16:43:30 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 02 Feb 2004 13:48:46 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id i12LgqpB009986 for ; Mon, 2 Feb 2004 13:42:53 -0800 (PST) Received: from cisco.com ([10.25.65.182]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AQN51587; Mon, 2 Feb 2004 13:42:52 -0800 (PST) Date: Mon, 2 Feb 2004 16:42:49 -0500 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Melinda Shore To: midcom@ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.553) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [midcom] Fwd: I-D ACTION:draft-ietf-midcom-mib-00.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This doesn't appear to have been cc'ed to the midcom mailing list. Here's the announcement for the midcom MIB, our final piece of work. Please have a good, thorough look at it and bring any issues you identify to the mailing list. This will also be the primary agenda item at the upcoming IETF meeting. Melinda Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: Mon Feb 2, 2004 3:58:44 PM US/Eastern > To: IETF-Announce: ; > Subject: I-D ACTION:draft-ietf-midcom-mib-00.txt > Reply-To: Internet-Drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Definitions of Managed Objects for Middlebox Communication > Author(s) : J. Quittek > Filename : draft-ietf-midcom-mib-00.txt > Pages : 76 > Date : 2004-2-2 > > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it describes a set of managed objects that allow > configuring middleboxes, such as firewalls and network address > translators, in order to enable communication across these devices. > The definitions of managed objects in this documents follow closely > the MIDCOM semantics defined in RFC XXXX. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-midcom-mib-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > 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-mib-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-ietf-midcom-mib-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2004-2-2150325.I-D@ietf.org> _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Feb 2 17:04:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16952 for ; Mon, 2 Feb 2004 17:04:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmAn-0004g7-1A for midcom-archive@odin.ietf.org; Mon, 02 Feb 2004 17:04:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12M44JI017959 for midcom-archive@odin.ietf.org; Mon, 2 Feb 2004 17:04:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmAl-0004fH-Hr; Mon, 02 Feb 2004 17:04:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmAZ-0004cn-RJ for midcom@optimus.ietf.org; Mon, 02 Feb 2004 17:03:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16938 for ; Mon, 2 Feb 2004 17:03:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnmAX-00031G-00 for midcom@ietf.org; Mon, 02 Feb 2004 17:03:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anm9c-0002sF-00 for midcom@ietf.org; Mon, 02 Feb 2004 17:02:53 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Anm8L-0002Zp-00 for midcom@ietf.org; Mon, 02 Feb 2004 17:01:33 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 02 Feb 2004 14:06:55 +0000 Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i12M115j011100 for ; Mon, 2 Feb 2004 14:01:02 -0800 (PST) Received: from cisco.com (dhcp-171-69-45-16.cisco.com [171.69.45.16]) by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOU32912; Mon, 2 Feb 2004 14:01:00 -0800 (PST) Message-ID: <401EC89C.6070706@cisco.com> Date: Mon, 02 Feb 2004 14:01:00 -0800 From: Sumandra Majee User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: midcom@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [midcom] (no subject) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit unsubscribe sumandra majee _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Feb 10 14:16:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03591 for ; Tue, 10 Feb 2004 14:16:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqdMb-0001bA-EH for midcom-archive@odin.ietf.org; Tue, 10 Feb 2004 14:16:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AJG5Mm006120 for midcom-archive@odin.ietf.org; Tue, 10 Feb 2004 14:16:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqdMX-0001Zz-Qf; Tue, 10 Feb 2004 14:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqdLb-0001YU-Sq for midcom@optimus.ietf.org; Tue, 10 Feb 2004 14:15:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03505 for ; Tue, 10 Feb 2004 14:15:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqdLZ-00045S-00 for midcom@ietf.org; Tue, 10 Feb 2004 14:15:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqdKc-0003z5-00 for midcom@ietf.org; Tue, 10 Feb 2004 14:14:03 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AqdJn-0003p2-00 for midcom@ietf.org; Tue, 10 Feb 2004 14:13:11 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 10 Feb 2004 11:13:12 -0800 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i1AJCYlP000461 for ; Tue, 10 Feb 2004 11:12:35 -0800 (PST) Received: from cisco.com ([10.25.65.182]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AQU39680; Tue, 10 Feb 2004 11:12:33 -0800 (PST) Date: Tue, 10 Feb 2004 14:12:29 -0500 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Melinda Shore To: midcom@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <124ED8F1-5BFD-11D8-AC62-000A95E35274@cisco.com> X-Mailer: Apple Mail (2.553) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [midcom] Agenda for Seoul meeting Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I've appended the agenda for the midcom session at the meeting in Seoul. I'll be unable to attend myself, and Mary Barnes has agreed to chair the meeting in my absence. Please let us know of any additions or changes to the proposed agenda. Thanks, Melinda Middlebox Communication (midcom) Tuesday, March 2 at 1415-1315 ============================= CHAIR: Mary Barnes (sitting in for Melinda Shore) AGENDA: Agenda bashing/note-taker/blue sheets Status update draft-ietf-midcom-protocol-eval-06.txt draft-ietf-midcom-semantics-07.txt What do we do with draft-ietf-midcom-mib-analysis-01.txt? MIB document draft-ietf-midcom-mib-00.txt Way forward _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Feb 12 12:33:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03694 for ; Thu, 12 Feb 2004 12:33:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKi2-0007Jz-Gb for midcom-archive@odin.ietf.org; Thu, 12 Feb 2004 12:33:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CHX60u028120 for midcom-archive@odin.ietf.org; Thu, 12 Feb 2004 12:33:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKhx-0007J3-G0; Thu, 12 Feb 2004 12:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKhQ-0007IK-0s for midcom@optimus.ietf.org; Thu, 12 Feb 2004 12:32:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03636 for ; Thu, 12 Feb 2004 12:32:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArKhM-0005Dx-00 for midcom@ietf.org; Thu, 12 Feb 2004 12:32:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArKgR-00058A-00 for midcom@ietf.org; Thu, 12 Feb 2004 12:31:28 -0500 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 1ArKfg-00052K-00 for midcom@ietf.org; Thu, 12 Feb 2004 12:30:41 -0500 Received: by fox.iptel.org (Postfix, from userid 103) id CA90A17A56; Thu, 12 Feb 2004 18:27:14 +0100 (CET) Received: from jku07.fokus.fraunhofer.de (port-212-202-174-188.reverse.qsc.de [212.202.174.188]) by fox.iptel.org (Postfix) with ESMTP id 82F42179B1; Thu, 12 Feb 2004 18:27:13 +0100 (CET) Message-Id: <6.0.1.1.0.20040212155954.0586dec0@mailhub.fokus.fhg.de> X-Sender: jku@mailhub.fokus.fhg.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 12 Feb 2004 18:17:31 +0100 To: fluffy@cisco.com, Jonathan Rosenberg , Midcom From: Jiri Kuthan In-Reply-To: <402937BE.6030309@dynamicsoft.com> References: <402937BE.6030309@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [midcom] (no subject) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 08:57 PM 2/10/2004, Jonathan Rosenberg wrote: >This is a great piece of work. Thanks to Cullen for putting this together. Cullen, thanks, that's indeed a very helpful piece of information. In particular the observation that modern NATs are rarely symmetric makes me feel better. (The current situation is AFAIK roughly up to 20% of user population is behind symmetric NATs.) Can you send me STUN traces (PCAP at best) for some of the non-deterministic NATs? Particularly according to some tests we did long time ago, Linksys WRT54G was symmetric all the time. Unfortunately, I no longer have one around to retest and I did not record firmware version either. -jiri _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Feb 13 07:21:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06824 for ; Fri, 13 Feb 2004 07:21:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArcJe-0000OY-EB for midcom-archive@odin.ietf.org; Fri, 13 Feb 2004 07:21:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DCL60s001494 for midcom-archive@odin.ietf.org; Fri, 13 Feb 2004 07:21:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArcJa-0000Nh-4j; Fri, 13 Feb 2004 07:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArcJU-0000N3-LO for midcom@optimus.ietf.org; Fri, 13 Feb 2004 07:20:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06805 for ; Fri, 13 Feb 2004 07:20:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArcJU-00033T-00 for midcom@ietf.org; Fri, 13 Feb 2004 07:20:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArcIX-0002zb-00 for midcom@ietf.org; Fri, 13 Feb 2004 07:19:58 -0500 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 1ArcHr-0002vy-00 for midcom@ietf.org; Fri, 13 Feb 2004 07:19:15 -0500 Received: by fox.iptel.org (Postfix, from userid 103) id A23AFBDC5; Fri, 13 Feb 2004 13:15:42 +0100 (CET) Received: from jku07.fokus.fraunhofer.de (port-212-202-174-188.reverse.qsc.de [212.202.174.188]) by fox.iptel.org (Postfix) with ESMTP id A0B80A284; Fri, 13 Feb 2004 13:15:38 +0100 (CET) Message-Id: <6.0.1.1.0.20040213130456.03afaec0@mailhub.fokus.fhg.de> X-Sender: jku@mailhub.fokus.fhg.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 13 Feb 2004 13:08:10 +0100 To: fluffy@cisco.com, Jonathan Rosenberg , Midcom From: Jiri Kuthan In-Reply-To: <6.0.1.1.0.20040212155954.0586dec0@mailhub.fokus.fhg.de> References: <402937BE.6030309@dynamicsoft.com> <6.0.1.1.0.20040212155954.0586dec0@mailhub.fokus.fhg.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt] Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 06:17 PM 2/12/2004, Jiri Kuthan wrote: >At 08:57 PM 2/10/2004, Jonathan Rosenberg wrote: >>This is a great piece of work. Thanks to Cullen for putting this together. > >Cullen, > >thanks, that's indeed a very helpful piece of information. In particular >the observation that modern NATs are rarely symmetric makes me feel better. >(The current situation is AFAIK roughly up to 20% of user population is >behind symmetric NATs.) > >Can you send me STUN traces (PCAP at best) for some of the non-deterministic >NATs? Particularly according to some tests we did long time ago, Linksys WRT54G >was symmetric all the time. Unfortunately, I no longer have one around to retest >and I did not record firmware version either. WRT to this particular case, linksys web tells me the box is Linux based (http://www.linksys.com/support/gpl.asp) in which case chances are high the box is symmetric all the times. I agree it would be good to verify your list -- what a pity we just missed an opportunity at sipit. -jiri _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Feb 13 09:49:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11351 for ; Fri, 13 Feb 2004 09:49:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arecq-0001g5-RL for midcom-archive@odin.ietf.org; Fri, 13 Feb 2004 09:49:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DEn4C8006445 for midcom-archive@odin.ietf.org; Fri, 13 Feb 2004 09:49:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arecm-0001fS-VA; Fri, 13 Feb 2004 09:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arebr-0001du-Eh for midcom@optimus.ietf.org; Fri, 13 Feb 2004 09:48:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11324 for ; Fri, 13 Feb 2004 09:48:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arebp-0006JQ-00 for midcom@ietf.org; Fri, 13 Feb 2004 09:48:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Areay-0006FM-00 for midcom@ietf.org; Fri, 13 Feb 2004 09:47:09 -0500 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 1AreaI-0006B2-00 for midcom@ietf.org; Fri, 13 Feb 2004 09:46:26 -0500 Received: by fox.iptel.org (Postfix, from userid 103) id D8A9017A89; Fri, 13 Feb 2004 15:42:53 +0100 (CET) Received: from jku07.fokus.fraunhofer.de (port-212-202-174-188.reverse.qsc.de [212.202.174.188]) by fox.iptel.org (Postfix) with ESMTP id 3CC1417A8A; Fri, 13 Feb 2004 15:42:50 +0100 (CET) Message-Id: <6.0.1.1.0.20040212201517.03c5fec0@mailhub.fokus.fhg.de> X-Sender: jku@mailhub.fokus.fhg.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 13 Feb 2004 14:48:13 +0100 To: Jonathan Rosenberg , Midcom From: Jiri Kuthan Subject: Re: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt] In-Reply-To: <402937BE.6030309@dynamicsoft.com> References: <402937BE.6030309@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 08:57 PM 2/10/2004, Jonathan Rosenberg wrote: >This is a great piece of work. Thanks to Cullen for putting this together. > >One conclusion I draw from this is that, as STUN itself predicts, the NAT classification algorithm is brittle because it makes assumptions about the types of NATs and there behaviors. We are now seeing NATs that have this dual behavior, depending on whether the internal port is allocated or not, and STUN's detection algorithm does not take this into account. Indeed, I would be inclined to work on reivising STUN, and in such a revision, remove the detection algorithm and explain why that was done. What do people think of that? I think there is still some value in the NAT-type tests even with use of ICE. Positive assertions about traversable NATs may be brittle, I agree. Negative assertions about hard-to-traverse NATs are quite safe and can eliminiate unnecessary tries. Particularly, if you know you are behind a symmetric NAT you can safely eliminate STUN address from your offer. >To me, this also further strengthens the arguments behind something like ICE (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-00.txt), which uses STUN, but does *not* use the detection algorithm. Rather, it relies on dynamic connectivity checks to figure out whether an address works or not. The argument there is that, ultimately, the only way to know whether you can receive media sent from address A to interface X is if you can receive a packet from address A sent to interface X. Any other way of verifying this conclusion is based on assumptions that can be wrong. Whereas I am quite comfortable with ICE and enjoy its e2e robustness, I think there is still some other, parallel, undone work. The left option of using a media relay indicates to me that there is an architectural imperfection and I see it in silly NATs (silly is an aggregate word standing for undeterministic or symmetric or bad or whatsoever). It seems very desirable to me to abandon such devices and I think it is a quite realistic goal. Cullen's draft actually strengthens my hope that it is happening. A way the IETF can help is to collect recommendations for NATs. There was such an effort long time ago (http://www.iptel.org/ietf/firewall/nat/draft-ietf-mmusic-natreq4udp-00.txt), I maintain a very similar list as well (don't be silly, keep NAT bindings for a while, allow hairpinning, try to preserve port numbers, try to use stateless binding allocation algorithms). -jiri _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Feb 13 10:04:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12128 for ; Fri, 13 Feb 2004 10:04:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArerN-0005Kx-Jx for midcom-archive@odin.ietf.org; Fri, 13 Feb 2004 10:04:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DF45Ub020438 for midcom-archive@odin.ietf.org; Fri, 13 Feb 2004 10:04:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArerK-0005IZ-0U; Fri, 13 Feb 2004 10:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AreqQ-0004jJ-JH for midcom@optimus.ietf.org; Fri, 13 Feb 2004 10:03:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12023 for ; Fri, 13 Feb 2004 10:03:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AreqO-0007fn-00 for midcom@ietf.org; Fri, 13 Feb 2004 10:03:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArepV-0007bR-00 for midcom@ietf.org; Fri, 13 Feb 2004 10:02:10 -0500 Received: from out003pub.verizon.net ([206.46.170.103] helo=out003.verizon.net) by ietf-mx with esmtp (Exim 4.12) id 1Areos-0007Wh-00 for midcom@ietf.org; Fri, 13 Feb 2004 10:01:30 -0500 Received: from [192.168.1.100] ([151.199.24.202]) by out003.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040213150129.MOAE8426.out003.verizon.net@[192.168.1.100]>; Fri, 13 Feb 2004 09:01:29 -0600 From: Bryan Ford Organization: Massachusetts Institute of Technology To: Jiri Kuthan , Jonathan Rosenberg , Midcom Subject: Re: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt] Date: Fri, 13 Feb 2004 10:01:28 -0500 User-Agent: KMail/1.5 References: <402937BE.6030309@dynamicsoft.com> <6.0.1.1.0.20040212201517.03c5fec0@mailhub.fokus.fhg.de> In-Reply-To: <6.0.1.1.0.20040212201517.03c5fec0@mailhub.fokus.fhg.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200402131001.28752.baford@mit.edu> X-Authentication-Info: Submitted using SMTP AUTH at out003.verizon.net from [151.199.24.202] at Fri, 13 Feb 2004 09:01:29 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Friday 13 February 2004 08:48 am, Jiri Kuthan wrote: > A way the IETF can help is to collect recommendations for NATs. There was > such an effort long time ago > (http://www.iptel.org/ietf/firewall/nat/draft-ietf-mmusic-natreq4udp-00.txt >), I maintain a very similar list as well (don't be silly, keep NAT bindings > for a while, allow hairpinning, try to preserve port numbers, try to use > stateless binding allocation algorithms). FYI, Pyda Srisuresh, Dan Kegel and I have for a while been working on a document whose sole purpose is to collect precisely these things - general recommendations for NATs, and general (protocol-independent) recommendations for applications trying to traverse NATs. It's already gone through a few versions; the latest one recently came back from first review by the IESG, and we're hoping to have another, near-final update before long. The most recent version is available here: http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt Please let me know if you find inaccuracies or have other comments/additions. Thanks! Bryan _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Feb 13 10:23:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14528 for ; Fri, 13 Feb 2004 10:23:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arf9k-0003RD-1b for midcom-archive@odin.ietf.org; Fri, 13 Feb 2004 10:23:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DFN4ew013214 for midcom-archive@odin.ietf.org; Fri, 13 Feb 2004 10:23:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arf9h-0003Qf-Su; Fri, 13 Feb 2004 10:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arf8n-00031v-D7 for midcom@optimus.ietf.org; Fri, 13 Feb 2004 10:22:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14488 for ; Fri, 13 Feb 2004 10:22:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arf8l-00023V-00 for midcom@ietf.org; Fri, 13 Feb 2004 10:22:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arf7x-0001zT-00 for midcom@ietf.org; Fri, 13 Feb 2004 10:21:13 -0500 Received: from imo-r05.mx.aol.com ([152.163.225.101]) by ietf-mx with esmtp (Exim 4.12) id 1Arf7a-0001uL-00 for midcom@ietf.org; Fri, 13 Feb 2004 10:20:50 -0500 Received: from Juberti@aol.com by imo-r05.mx.aol.com (mail_out_v36_r4.14.) id h.8e.346a70d (16099); Fri, 13 Feb 2004 10:19:45 -0500 (EST) Received: from pc-sn654362.ad.aol.aoltw.net ([10.2.113.188]) by air-id11.mx.aol.com (v97.18) with ESMTP id MAILINID113-3ee3402ceb10346; Fri, 13 Feb 2004 10:19:45 -0500 Date: Fri, 13 Feb 2004 10:19:45 -0500 From: "Justin Uberti" Subject: Re: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt To: "Jiri Kuthan" cc: fluffy@cisco.com, "Jonathan Rosenberg" , Midcom In-Reply-To: <6.0.1.1.0.20040213130456.03afaec0@mailhub.fokus.fhg.de> Message-ID: <402CEB11.1060906@aol.com> References: <402937BE.6030309@dynamicsoft.com> <6.0.1.1.0.20040212155954.0586dec0@mailhub.fokus.fhg.de> <6.0.1.1.0.20040213130456.03afaec0@mailhub.fokus.fhg.de> X-Mailer: AOL Communicator (20030919.3 Win) Organization: America Online MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii X-AOL-IP: 10.2.113.188 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Here at AOL we have found that the WRT54G is port-restricted cone in its normal mode, which is what is documented by Cullen. Our other test results are also mostly consistent with the document, with the exception of some Linksys models, where the difference may be explained by different firmware versions. We were not able to find any symmetric NATs in our admittedly small sample. Cisco PIIX Port DLink DI-704P Cone Linksys BEFSR41 Addr Linksys BEFSX41 Addr Linksys BEFW11S4 Port Linksys WRT54G Port Netgear RP614 Cone Netgear WGR614 Cone FWIW, we have found that some Linksys routers will rewrite the IP address in the STUN reply to be the nonroutable (e.g. 192.168.x.x) address rather than the NAT address, causing the STUN detection to classify the connectivity as "Open". For our STUN-like protocol we have the server XOR the IP address prior to returning it to prevent such rewriting. Also, we have observed from our customers this approximate breakdown in market share: (obviously heavily skewed toward a US population) Linksys 59% Netgear 14% DLink 13% Belkin 5% Microsoft 3% SMC 2% Siemens 2% Zyxel 1% ActionTec 1% 3Com <1% Comcast <1% Dell <1% --justin Jiri Kuthan wrote on 2/13/2004, 7:08 AM: > At 06:17 PM 2/12/2004, Jiri Kuthan wrote: > >At 08:57 PM 2/10/2004, Jonathan Rosenberg wrote: > >>This is a great piece of work. Thanks to Cullen for putting this > together. > > > >Cullen, > > > >thanks, that's indeed a very helpful piece of information. In particular > >the observation that modern NATs are rarely symmetric makes me feel > better. > >(The current situation is AFAIK roughly up to 20% of user population is > >behind symmetric NATs.) > > > >Can you send me STUN traces (PCAP at best) for some of the > non-deterministic > >NATs? Particularly according to some tests we did long time ago, > Linksys WRT54G > >was symmetric all the time. Unfortunately, I no longer have one > around to retest > >and I did not record firmware version either. > > WRT to this particular case, linksys web tells me the box is Linux based > (http://www.linksys.com/support/gpl.asp) in which case chances are high > the box is symmetric all the times. I agree it would be good to verify > your > list -- what a pity we just missed an opportunity at sipit. > > -jiri > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Feb 13 10:45:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15707 for ; Fri, 13 Feb 2004 10:45:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfV1-0006GX-JJ for midcom-archive@odin.ietf.org; Fri, 13 Feb 2004 10:45:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DFj3Qh024053 for midcom-archive@odin.ietf.org; Fri, 13 Feb 2004 10:45:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfUz-0006FY-KZ; Fri, 13 Feb 2004 10:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfU3-00064Q-N2 for midcom@optimus.ietf.org; Fri, 13 Feb 2004 10:44:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15648 for ; Fri, 13 Feb 2004 10:43:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArfU1-0003qr-00 for midcom@ietf.org; Fri, 13 Feb 2004 10:44:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArfT3-0003l9-00 for midcom@ietf.org; Fri, 13 Feb 2004 10:43:02 -0500 Received: from out005pub.verizon.net ([206.46.170.143] helo=out005.verizon.net) by ietf-mx with esmtp (Exim 4.12) id 1ArfS5-0003fY-00 for midcom@ietf.org; Fri, 13 Feb 2004 10:42:01 -0500 Received: from [192.168.1.100] ([151.199.24.202]) by out005.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040213154200.ISYO2677.out005.verizon.net@[192.168.1.100]>; Fri, 13 Feb 2004 09:42:00 -0600 From: Bryan Ford Organization: Massachusetts Institute of Technology To: "Justin Uberti" , "Jiri Kuthan" Subject: Re: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt Date: Fri, 13 Feb 2004 10:41:59 -0500 User-Agent: KMail/1.5 Cc: fluffy@cisco.com, "Jonathan Rosenberg" , Midcom References: <402937BE.6030309@dynamicsoft.com> <6.0.1.1.0.20040213130456.03afaec0@mailhub.fokus.fhg.de> <402CEB11.1060906@aol.com> In-Reply-To: <402CEB11.1060906@aol.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200402131041.59038.baford@mit.edu> X-Authentication-Info: Submitted using SMTP AUTH at out005.verizon.net from [151.199.24.202] at Fri, 13 Feb 2004 09:41:59 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Friday 13 February 2004 10:19 am, Justin Uberti wrote: > Also, we have observed from our customers this approximate breakdown in > market share: (obviously heavily skewed toward a US population) > Linksys 59% > Netgear 14% > DLink 13% > Belkin 5% > Microsoft 3% > SMC 2% > Siemens 2% > Zyxel 1% > ActionTec 1% > 3Com <1% > Comcast <1% > Dell <1% That's very useful info - thanks very much for posting it! Out of curiosity, does anyone have any similar info about the types of "big-iron" NAT boxes are most commonly deployed at the ISP or corporate network level rather than at the consumer level? I assume this area is Cisco-dominated, but to what degree, and who are the other significant players, if any? The reason I ask is because it is at this level that not only [[port-]restricted] cone NAT becomes important, but also hairpin aka loopback translation support becomes critical, if users behind the same top-level NAT but separate second-level (consumer) NATs are to be able to talk to each other. Justin, you folks at AOL deploy a lot of such boxes, don't you? Do you know/can you divulge what type they are and what their NAT behavior is? Thanks, Bryan _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Feb 13 13:22:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23795 for ; Fri, 13 Feb 2004 13:22:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arhx2-0003SI-Se for midcom-archive@odin.ietf.org; Fri, 13 Feb 2004 13:22:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DIM8M2013258 for midcom-archive@odin.ietf.org; Fri, 13 Feb 2004 13:22:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arhwv-0003RR-7m; Fri, 13 Feb 2004 13:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arhw4-0003Mg-DZ for midcom@optimus.ietf.org; Fri, 13 Feb 2004 13:21:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23762 for ; Fri, 13 Feb 2004 13:21:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arhw2-0003Fq-00 for midcom@ietf.org; Fri, 13 Feb 2004 13:21:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arhv8-0003Cm-00 for midcom@ietf.org; Fri, 13 Feb 2004 13:20:11 -0500 Received: from imo-m26.mx.aol.com ([64.12.137.7]) by ietf-mx with esmtp (Exim 4.12) id 1Arhup-00039F-00 for midcom@ietf.org; Fri, 13 Feb 2004 13:19:51 -0500 Received: from Juberti@aol.com by imo-m26.mx.aol.com (mail_out_v36_r4.14.) id 6.105.3f5d2518 (16035); Fri, 13 Feb 2004 13:18:48 -0500 (EST) Received: from pc-sn654362.ad.aol.aoltw.net ([10.2.113.188]) by air-id10.mx.aol.com (v97.18) with ESMTP id MAILINID102-3ea3402d150717c; Fri, 13 Feb 2004 13:18:47 -0500 Date: Fri, 13 Feb 2004 13:18:47 -0500 From: "Justin Uberti" Subject: Re: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt To: "Bryan Ford" cc: "Jiri Kuthan" , fluffy@cisco.com, "Jonathan Rosenberg" , Midcom In-Reply-To: <200402131041.59038.baford@mit.edu> Message-ID: <402D1507.6000705@aol.com> References: <402937BE.6030309@dynamicsoft.com> <6.0.1.1.0.20040213130456.03afaec0@mailhub.fokus.fhg.de> <402CEB11.1060906@aol.com> <200402131041.59038.baford@mit.edu> X-Mailer: AOL Communicator (20030919.3 Win) Organization: America Online MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii X-AOL-IP: 10.2.113.188 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , We use Cisco PIIX for our corporate network. For our ISP customers, we supply fully routable addresses, i.e. we do not NAT them. I am curious to find out from our stats how many of our customers who use our software but not our ISP are NATed by their own ISP. Right now we have to go through a lot of craziness to deal with the case you mention where two customers are behind the same top-level NAT but separate residential NATs. Does ICE address this particular case? --justin Bryan Ford wrote on 2/13/2004, 10:41 AM: > On Friday 13 February 2004 10:19 am, Justin Uberti wrote: > > Also, we have observed from our customers this approximate breakdown in > > market share: (obviously heavily skewed toward a US population) > > Linksys 59% > > Netgear 14% > > DLink 13% > > Belkin 5% > > Microsoft 3% > > SMC 2% > > Siemens 2% > > Zyxel 1% > > ActionTec 1% > > 3Com <1% > > Comcast <1% > > Dell <1% > > That's very useful info - thanks very much for posting it! > > Out of curiosity, does anyone have any similar info about the types of > "big-iron" NAT boxes are most commonly deployed at the ISP or corporate > network level rather than at the consumer level? I assume this area is > Cisco-dominated, but to what degree, and who are the other significant > players, if any? The reason I ask is because it is at this level that > not > only [[port-]restricted] cone NAT becomes important, but also hairpin aka > loopback translation support becomes critical, if users behind the same > top-level NAT but separate second-level (consumer) NATs are to be able to > talk to each other. > > Justin, you folks at AOL deploy a lot of such boxes, don't you? Do you > know/can you divulge what type they are and what their NAT behavior is? > > Thanks, > Bryan > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Feb 13 13:29:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24254 for ; Fri, 13 Feb 2004 13:29:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ari3j-0004Ki-9t for midcom-archive@odin.ietf.org; Fri, 13 Feb 2004 13:29:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DIT3U5016633 for midcom-archive@odin.ietf.org; Fri, 13 Feb 2004 13:29:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ari3h-0004Jr-QB; Fri, 13 Feb 2004 13:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ari2u-0004Gr-Rb for midcom@optimus.ietf.org; Fri, 13 Feb 2004 13:28:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24088 for ; Fri, 13 Feb 2004 13:28:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ari2s-0003jv-00 for midcom@ietf.org; Fri, 13 Feb 2004 13:28:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ari1z-0003fO-00 for midcom@ietf.org; Fri, 13 Feb 2004 13:27:15 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1Ari1E-0003Wi-00 for midcom@ietf.org; Fri, 13 Feb 2004 13:26:28 -0500 Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1DIPNNr004082; Fri, 13 Feb 2004 13:25:24 -0500 (EST) Message-ID: <402D168A.3040507@dynamicsoft.com> Date: Fri, 13 Feb 2004 13:25:14 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Justin Uberti CC: Bryan Ford , Jiri Kuthan , fluffy@cisco.com, Midcom Subject: Re: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt References: <402937BE.6030309@dynamicsoft.com> <6.0.1.1.0.20040213130456.03afaec0@mailhub.fokus.fhg.de> <402CEB11.1060906@aol.com> <200402131041.59038.baford@mit.edu> <402D1507.6000705@aol.com> In-Reply-To: <402D1507.6000705@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Justin Uberti wrote: > We use Cisco PIIX for our corporate network. For our ISP customers, we > supply fully routable addresses, i.e. we do not NAT them. > > I am curious to find out from our stats how many of our customers who > use our software but not our ISP are NATed by their own ISP. Right now > we have to go through a lot of craziness to deal with the case you > mention where two customers are behind the same top-level NAT but > separate residential NATs. Does ICE address this particular case? Yes. It will dynamically detect the condition and the following will occur: If the top-level NAT supports hairpin, ICE will end up using a STUn discovered address outside of the top-level NAT, i.e., it would take advantage of the hairpin support. If the top-level NAT doesnt support hairpin, AND there was a stun server between the residential and to-most NAT, and the clients were configured to use such a stun server, those addresses would be used. Note that in this case, the stun server doesnt need to be a big, publically available server; any user of the same ISP that doesnt own a residential nat could run a stun server, and that could be used. If the top level NAT doesnt support hairpin, and there is no other stun server besides the one outside of the outermost nat, then the turn server outside the outermost nat would be used. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Feb 13 13:38:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24622 for ; Fri, 13 Feb 2004 13:38:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AriCa-0005LH-3I for midcom-archive@odin.ietf.org; Fri, 13 Feb 2004 13:38:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DIcBQQ020509 for midcom-archive@odin.ietf.org; Fri, 13 Feb 2004 13:38:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AriCP-0005G6-HP; Fri, 13 Feb 2004 13:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AriBW-000546-7a for midcom@optimus.ietf.org; Fri, 13 Feb 2004 13:37:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24585 for ; Fri, 13 Feb 2004 13:37:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AriBU-0004Uu-00 for midcom@ietf.org; Fri, 13 Feb 2004 13:37:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AriAZ-0004Pw-00 for midcom@ietf.org; Fri, 13 Feb 2004 13:36:07 -0500 Received: from imo-m02.mx.aol.com ([64.12.136.5]) by ietf-mx with esmtp (Exim 4.12) id 1Ari9j-0004Gj-00 for midcom@ietf.org; Fri, 13 Feb 2004 13:35:16 -0500 Received: from Juberti@aol.com by imo-m02.mx.aol.com (mail_out_v36_r4.14.) id r.f3.35f236bf (16112); Fri, 13 Feb 2004 13:34:05 -0500 (EST) Received: from pc-sn654362.ad.aol.aoltw.net ([10.2.113.188]) by air-id12.mx.aol.com (v97.18) with ESMTP id MAILINID124-3ef0402d189c2a9; Fri, 13 Feb 2004 13:34:04 -0500 Date: Fri, 13 Feb 2004 13:34:04 -0500 From: "Justin Uberti" Subject: Re: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt To: "Jonathan Rosenberg" cc: "Bryan Ford" , "Jiri Kuthan" , fluffy@cisco.com, Midcom In-Reply-To: <402D168A.3040507@dynamicsoft.com> Message-ID: <402D189C.1090903@aol.com> References: <402937BE.6030309@dynamicsoft.com> <6.0.1.1.0.20040213130456.03afaec0@mailhub.fokus.fhg.de> <402CEB11.1060906@aol.com> <200402131041.59038.baford@mit.edu> <402D1507.6000705@aol.com> <402D168A.3040507@dynamicsoft.com> X-Mailer: AOL Communicator (20030919.3 Win) Organization: America Online MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii X-AOL-IP: 10.2.113.188 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > If the top-level NAT doesnt support hairpin, AND there was a stun server > between the residential and to-most NAT, and the clients were configured > to use such a stun server, those addresses would be used. Note that in > this case, the stun server doesnt need to be a big, publically available > server; any user of the same ISP that doesnt own a residential nat could > run a stun server, and that could be used. > q1: How would the existence of said STUN server be made known to the calling client? q2: We currently use UPnP to address this particular situation, i.e. if we know that we are behind 2 NATs and the person we want to call is behind the same topmost NAT, we get the WAN address of our first-level NAT box using UPnP and give that to the callee. Is UPnP, or any other protocol for querying the WAN address of the NAT box, used in ICE? Thanks, --justin _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Feb 13 13:40:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24676 for ; Fri, 13 Feb 2004 13:40:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AriER-0005XK-6s for midcom-archive@odin.ietf.org; Fri, 13 Feb 2004 13:40:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DIe6E2021229 for midcom-archive@odin.ietf.org; Fri, 13 Feb 2004 13:40:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AriEQ-0005WJ-Bb; Fri, 13 Feb 2004 13:40:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AriDY-0005VA-Q5 for midcom@optimus.ietf.org; Fri, 13 Feb 2004 13:39:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24646 for ; Fri, 13 Feb 2004 13:39:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AriDW-0004dP-00 for midcom@ietf.org; Fri, 13 Feb 2004 13:39:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AriCZ-0004Zo-00 for midcom@ietf.org; Fri, 13 Feb 2004 13:38:11 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AriCJ-0004W9-00 for midcom@ietf.org; Fri, 13 Feb 2004 13:37:56 -0500 Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1DIb6Nr004086; Fri, 13 Feb 2004 13:37:06 -0500 (EST) Message-ID: <402D1949.8060804@dynamicsoft.com> Date: Fri, 13 Feb 2004 13:36:57 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Justin Uberti CC: Jiri Kuthan , fluffy@cisco.com, Midcom Subject: Re: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt References: <402937BE.6030309@dynamicsoft.com> <6.0.1.1.0.20040212155954.0586dec0@mailhub.fokus.fhg.de> <6.0.1.1.0.20040213130456.03afaec0@mailhub.fokus.fhg.de> <402CEB11.1060906@aol.com> In-Reply-To: <402CEB11.1060906@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Justin Uberti wrote: > Here at AOL we have found that the WRT54G is port-restricted cone in its > normal mode, which is what is documented by Cullen. Our other test > results are also mostly consistent with the document, with the exception > of some Linksys models, where the difference may be explained by > different firmware versions. We were not able to find any symmetric NATs > in our admittedly small sample. > > Cisco PIIX Port > DLink DI-704P Cone > Linksys BEFSR41 Addr > Linksys BEFSX41 Addr > Linksys BEFW11S4 Port > Linksys WRT54G Port > Netgear RP614 Cone > Netgear WGR614 Cone Thanks for the additional data. I think it would be really valuable to run the same tests Cullen has run against these, and include the results in the document. > > FWIW, we have found that some Linksys routers will rewrite the IP > address in the STUN reply to be the nonroutable (e.g. 192.168.x.x) > address rather than the NAT address, causing the STUN detection to > classify the connectivity as "Open". Sigh... Cullen reports in his document that he did not see this behavior. Its one of my regrets in stun - that we did not properly encrypt the address to avoid rewriting by nat. If we were to do a revision of stun, I would like to address this also. > For our STUN-like protocol we have > the server XOR the IP address prior to returning it to prevent such > rewriting. > > Also, we have observed from our customers this approximate breakdown in > market share: (obviously heavily skewed toward a US population) > Linksys 59% > Netgear 14% > DLink 13% > Belkin 5% > Microsoft 3% > SMC 2% > Siemens 2% > Zyxel 1% > ActionTec 1% > 3Com <1% > Comcast <1% > Dell <1% This is valuable data, thanks. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Feb 13 13:45:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24841 for ; Fri, 13 Feb 2004 13:45:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AriJD-0005up-Va for midcom-archive@odin.ietf.org; Fri, 13 Feb 2004 13:45:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DIj3P3022715 for midcom-archive@odin.ietf.org; Fri, 13 Feb 2004 13:45:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AriJC-0005ty-KO; Fri, 13 Feb 2004 13:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AriIM-0005mg-VE for midcom@optimus.ietf.org; Fri, 13 Feb 2004 13:44:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24827 for ; Fri, 13 Feb 2004 13:44:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AriIK-0004xe-00 for midcom@ietf.org; Fri, 13 Feb 2004 13:44:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AriHQ-0004u1-00 for midcom@ietf.org; Fri, 13 Feb 2004 13:43:12 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AriGe-0004ls-00 for midcom@ietf.org; Fri, 13 Feb 2004 13:42:24 -0500 Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1DIfaNr004090; Fri, 13 Feb 2004 13:41:37 -0500 (EST) Message-ID: <402D1A58.4030402@dynamicsoft.com> Date: Fri, 13 Feb 2004 13:41:28 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Justin Uberti CC: Bryan Ford , Jiri Kuthan , fluffy@cisco.com, Midcom Subject: Re: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt References: <402937BE.6030309@dynamicsoft.com> <6.0.1.1.0.20040213130456.03afaec0@mailhub.fokus.fhg.de> <402CEB11.1060906@aol.com> <200402131041.59038.baford@mit.edu> <402D1507.6000705@aol.com> <402D168A.3040507@dynamicsoft.com> <402D189C.1090903@aol.com> In-Reply-To: <402D189C.1090903@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Justin Uberti wrote: > > > If the top-level NAT doesnt support hairpin, AND there was a stun server > > between the residential and to-most NAT, and the clients were configured > > to use such a stun server, those addresses would be used. Note that in > > this case, the stun server doesnt need to be a big, publically available > > server; any user of the same ISP that doesnt own a residential nat could > > run a stun server, and that could be used. > > > q1: How would the existence of said STUN server be made known to the > calling client? Configuration of some sort. There is no magic that I know of to automatically discover these. > > q2: We currently use UPnP to address this particular situation, i.e. if > we know that we are behind 2 NATs and the person we want to call is > behind the same topmost NAT, How do you know this reliably? > we get the WAN address of our first-level > NAT box using UPnP and give that to the callee. Is UPnP, or any other > protocol for querying the WAN address of the NAT box, used in ICE? UPnp can be used with ICE, yes. ICE's philosophy is, "the more the merrier" in terms of addresses. The only requirement is that there is always at least one guaranteed-to-work address, generally obtained through turn. Beyond that, a client can obtain addresses from stun, turn, upnp, midcom, rsip, etc., and ice will dynamically figure out the one that is best to use. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Feb 13 13:49:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24952 for ; Fri, 13 Feb 2004 13:49:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AriN3-0006ET-69 for midcom-archive@odin.ietf.org; Fri, 13 Feb 2004 13:49:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DIn1Au023933 for midcom-archive@odin.ietf.org; Fri, 13 Feb 2004 13:49:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AriN2-0006Du-T0; Fri, 13 Feb 2004 13:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AriMH-0006Cp-60 for midcom@optimus.ietf.org; Fri, 13 Feb 2004 13:48:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24903 for ; Fri, 13 Feb 2004 13:48:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AriMF-0005Dw-00 for midcom@ietf.org; Fri, 13 Feb 2004 13:48:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AriLI-00059l-00 for midcom@ietf.org; Fri, 13 Feb 2004 13:47:12 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AriKn-000553-00 for midcom@ietf.org; Fri, 13 Feb 2004 13:46:41 -0500 Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1DIkBNr004093; Fri, 13 Feb 2004 13:46:11 -0500 (EST) Message-ID: <402D1B6A.70803@dynamicsoft.com> Date: Fri, 13 Feb 2004 13:46:02 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jiri Kuthan CC: Midcom Subject: Re: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt] References: <402937BE.6030309@dynamicsoft.com> <6.0.1.1.0.20040212201517.03c5fec0@mailhub.fokus.fhg.de> In-Reply-To: <6.0.1.1.0.20040212201517.03c5fec0@mailhub.fokus.fhg.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jiri Kuthan wrote: > At 08:57 PM 2/10/2004, Jonathan Rosenberg wrote: > >> This is a great piece of work. Thanks to Cullen for putting this >> together. >> >> One conclusion I draw from this is that, as STUN itself predicts, >> the NAT classification algorithm is brittle because it makes >> assumptions about the types of NATs and there behaviors. We are now >> seeing NATs that have this dual behavior, depending on whether the >> internal port is allocated or not, and STUN's detection algorithm >> does not take this into account. Indeed, I would be inclined to >> work on reivising STUN, and in such a revision, remove the >> detection algorithm and explain why that was done. What do people >> think of that? > > > I think there is still some value in the NAT-type tests even with use > of ICE. Positive assertions about traversable NATs may be brittle, I > agree. Negative assertions about hard-to-traverse NATs are quite safe > and can eliminiate unnecessary tries. Particularly, if you know you > are behind a symmetric NAT you can safely eliminate STUN address from > your offer. I disgaree. Cullen's results show that we are seeing hybrid NATs whose type depends on whether the random port selected by the client is allocated already or not. In such a case, if the client picks an already-allocated port during the detection phase, it may detect the nat as symmetric, when it fact it might be port restricted in other cases. With ICE, if you happen to be unlucky during a stun allocation, turn would get used. If you're lucky, and you get a port-restricted port, then the relay would not be used. > > > >> To me, this also further strengthens the arguments behind something >> like ICE >> (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-00.txt), >> which uses STUN, but does *not* use the detection algorithm. >> Rather, it relies on dynamic connectivity checks to figure out >> whether an address works or not. The argument there is that, >> ultimately, the only way to know whether you can receive media sent >> from address A to interface X is if you can receive a packet from >> address A sent to interface X. Any other way of verifying this >> conclusion is based on assumptions that can be wrong. > > > Whereas I am quite comfortable with ICE and enjoy its e2e robustness, > I think there is still some other, parallel, undone work. The left > option of using a media relay indicates to me that there is an > architectural imperfection and I see it in silly NATs (silly is an > aggregate word standing for undeterministic or symmetric or bad or > whatsoever). Yes, it would be nice to obliterate such devices. With ICE, once obliterated, the relay would simply cease seeing any traffic, and you know at that time that you can disconnect it safely. As such, ICE provides a nice way to transition from here to there. It seems very desirable to me to abandon such devices > and I think it is a quite realistic goal. Cullen's draft actually > strengthens my hope that it is happening. > > A way the IETF can help is to collect recommendations for NATs. There > was such an effort long time ago > (http://www.iptel.org/ietf/firewall/nat/draft-ietf-mmusic-natreq4udp-00.txt), > I maintain a very similar list as well (don't be silly, keep NAT > bindings for a while, allow hairpinning, try to preserve port > numbers, try to use stateless binding allocation algorithms). I agree work needs to be done here. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Feb 13 15:53:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02750 for ; Fri, 13 Feb 2004 15:53:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkJA-0001mq-4J for midcom-archive@odin.ietf.org; Fri, 13 Feb 2004 15:53:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DKr8Yn006843 for midcom-archive@odin.ietf.org; Fri, 13 Feb 2004 15:53:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkJ3-0001lv-4E; Fri, 13 Feb 2004 15:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkIS-0001kU-Mb for midcom@optimus.ietf.org; Fri, 13 Feb 2004 15:52:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02699 for ; Fri, 13 Feb 2004 15:52:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArkIQ-0000dX-00 for midcom@ietf.org; Fri, 13 Feb 2004 15:52:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArkHX-0000YT-00 for midcom@ietf.org; Fri, 13 Feb 2004 15:51:27 -0500 Received: from 67.105.118.114.ptr.us.xo.net ([67.105.118.114] helo=mail.kmerl.com) by ietf-mx with esmtp (Exim 4.12) id 1ArkGY-0000PU-00 for midcom@ietf.org; Fri, 13 Feb 2004 15:50:26 -0500 Subject: RE: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Feb 2004 12:49:56 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Message-ID: Thread-Topic: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt] Thread-Index: AcPyYhC1S+Zlc4zeT7yIWh+GIQ4D8gAEMcgA From: "Yutaka Takeda" To: "Midcom" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > > I think there is still some value in the NAT-type tests=20 > even with use > > of ICE. Positive assertions about traversable NATs may be brittle, I > > agree. Negative assertions about hard-to-traverse NATs are=20 > quite safe > > and can eliminiate unnecessary tries. Particularly, if you know you > > are behind a symmetric NAT you can safely eliminate STUN=20 > address from > > your offer. >=20 > I disgaree. >=20 > Cullen's results show that we are seeing hybrid NATs whose=20 > type depends=20 > on whether the random port selected by the client is=20 > allocated already=20 > or not. In such a case, if the client picks an already-allocated port=20 > during the detection phase, it may detect the nat as=20 > symmetric, when it=20 > fact it might be port restricted in other cases. >=20 > With ICE, if you happen to be unlucky during a stun allocation, turn=20 > would get used. If you're lucky, and you get a port-restricted port,=20 > then the relay would not be used. Cullen's results are also telling us that there are more chances for = clients to come across a symmetric case than we can see with current STUN=20 test. Since ICE has ability to traverse p2p UDP connection through a=20 symmetric NAT if the other end does not have or does has a full-cone=20 NAT or restricted, the results seem to motivate us more to go towards=20 ICE. Although ICE does this job without a knowledge of NAT types, I feel it is good to have a standardized protocol to discover the types of=20 NAT. In fact, we would have not been able to come to this point=20 without the knowledge of NAT types and actual discovery tests, but in=20 this case, clarification for applicability limitation of the NAT type=20 discovery process and their reasons should be added to the document I suppose. Yutaka _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sat Feb 14 11:22:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22823 for ; Sat, 14 Feb 2004 11:22:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2YQ-00008l-9m for midcom-archive@odin.ietf.org; Sat, 14 Feb 2004 11:22:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1EGM6rJ000444 for midcom-archive@odin.ietf.org; Sat, 14 Feb 2004 11:22:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2YK-00005F-SC; Sat, 14 Feb 2004 11:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2XM-0008To-Ta for midcom@optimus.ietf.org; Sat, 14 Feb 2004 11:21:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22738 for ; Sat, 14 Feb 2004 11:20:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As2XM-000794-00 for midcom@ietf.org; Sat, 14 Feb 2004 11:21:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As2WU-00073q-00 for midcom@ietf.org; Sat, 14 Feb 2004 11:20:06 -0500 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 1As2Vh-0006z6-00 for midcom@ietf.org; Sat, 14 Feb 2004 11:19:17 -0500 Received: by fox.iptel.org (Postfix, from userid 103) id EBD21BD8F; Sat, 14 Feb 2004 17:15:36 +0100 (CET) Received: from jku07.iptel.org (fesarius.fokus.fraunhofer.de [193.175.132.142]) by fox.iptel.org (Postfix) with ESMTP id 3AA2BB09F; Sat, 14 Feb 2004 17:15:35 +0100 (CET) Message-Id: <6.0.1.1.0.20040214163622.058b4eb0@mailhub.fokus.fhg.de> X-Sender: jiri@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 14 Feb 2004 16:37:49 +0100 To: Jonathan Rosenberg , Justin Uberti From: Jiri Kuthan Subject: Call for STUN results (was Re: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt Cc: fluffy@cisco.com, Midcom In-Reply-To: <402D1949.8060804@dynamicsoft.com> References: <402937BE.6030309@dynamicsoft.com> <6.0.1.1.0.20040212155954.0586dec0@mailhub.fokus.fhg.de> <6.0.1.1.0.20040213130456.03afaec0@mailhub.fokus.fhg.de> <402CEB11.1060906@aol.com> <402D1949.8060804@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 07:36 PM 2/13/2004, Jonathan Rosenberg wrote: >Thanks for the additional data. I think it would be really valuable to run the same tests Cullen has run against these, and include the results in the document. Absolutely. I think we should collect PCAP files for verification purposes though. I'll be happy to do the collector job if people send them to me. A first try is at http://iptel.org/stun_test. -jiri -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sat Feb 14 11:22:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22818 for ; Sat, 14 Feb 2004 11:22:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2YQ-00008j-9C for midcom-archive@odin.ietf.org; Sat, 14 Feb 2004 11:22:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1EGM5CA000448 for midcom-archive@odin.ietf.org; Sat, 14 Feb 2004 11:22:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2YL-00005N-AS; Sat, 14 Feb 2004 11:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2XQ-0008UP-61 for midcom@optimus.ietf.org; Sat, 14 Feb 2004 11:21:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22744 for ; Sat, 14 Feb 2004 11:21:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As2XP-00079i-00 for midcom@ietf.org; Sat, 14 Feb 2004 11:21:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As2WV-00074B-00 for midcom@ietf.org; Sat, 14 Feb 2004 11:20:08 -0500 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 1As2Vh-0006z8-00 for midcom@ietf.org; Sat, 14 Feb 2004 11:19:18 -0500 Received: by fox.iptel.org (Postfix, from userid 103) id 80889B0A0; Sat, 14 Feb 2004 17:15:38 +0100 (CET) Received: from jku07.iptel.org (fesarius.fokus.fraunhofer.de [193.175.132.142]) by fox.iptel.org (Postfix) with ESMTP id 0C3359C; Sat, 14 Feb 2004 17:15:35 +0100 (CET) Message-Id: <6.0.1.1.0.20040214150805.0586dec0@mailhub.fokus.fhg.de> X-Sender: jiri@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 14 Feb 2004 16:13:46 +0100 To: Bryan Ford , Jonathan Rosenberg , Midcom From: Jiri Kuthan Subject: Re: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt] In-Reply-To: <200402131001.28752.baford@mit.edu> References: <402937BE.6030309@dynamicsoft.com> <6.0.1.1.0.20040212201517.03c5fec0@mailhub.fokus.fhg.de> <200402131001.28752.baford@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , [...] At 04:01 PM 2/13/2004, Bryan Ford wrote: > (don't be silly, keep NAT bindings >> for a while, allow hairpinning, try to preserve port numbers, try to use >> stateless binding allocation algorithms). > http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt > >Please let me know if you find inaccuracies or have other comments/additions. >Thanks! I don't think any item on my shopping list above introduces anything new in addition to your Section 5. I just don't understand if there is not an overlap between your section 5.1 which mandates cone NATs and 5.3 which mandates preserving the same translation packets with the same source address and port number. Isn't that the same thing? I'm not sure I like the dual-NAT-type behaviour suggested in 5.2. At least I would have to understand how the application configuration process in NAT would work (My midcom bias is that application awareness in NATs is better avoided.) -jiri _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sat Feb 14 12:08:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22822 for ; Sat, 14 Feb 2004 11:22:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2YQ-00008k-9V for midcom-archive@odin.ietf.org; Sat, 14 Feb 2004 11:22:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1EGM6gI000441 for midcom-archive@odin.ietf.org; Sat, 14 Feb 2004 11:22:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2YK-000056-Fe; Sat, 14 Feb 2004 11:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2XO-0008UK-O9 for midcom@optimus.ietf.org; Sat, 14 Feb 2004 11:21:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22741 for ; Sat, 14 Feb 2004 11:21:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As2XN-00079S-00 for midcom@ietf.org; Sat, 14 Feb 2004 11:21:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As2WU-000741-00 for midcom@ietf.org; Sat, 14 Feb 2004 11:20:07 -0500 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 1As2Vh-0006z7-00 for midcom@ietf.org; Sat, 14 Feb 2004 11:19:17 -0500 Received: by fox.iptel.org (Postfix, from userid 103) id 52573B09F; Sat, 14 Feb 2004 17:15:37 +0100 (CET) Received: from jku07.iptel.org (fesarius.fokus.fraunhofer.de [193.175.132.142]) by fox.iptel.org (Postfix) with ESMTP id 59E02B0A0; Sat, 14 Feb 2004 17:15:35 +0100 (CET) Message-Id: <6.0.1.1.0.20040214162424.03c5fec0@mailhub.fokus.fhg.de> X-Sender: jiri@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 14 Feb 2004 16:46:21 +0100 To: "Justin Uberti" From: Jiri Kuthan Subject: Re: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt Cc: fluffy@cisco.com, "Jonathan Rosenberg" , Midcom In-Reply-To: <402CEB11.1060906@aol.com> References: <402937BE.6030309@dynamicsoft.com> <6.0.1.1.0.20040212155954.0586dec0@mailhub.fokus.fhg.de> <6.0.1.1.0.20040213130456.03afaec0@mailhub.fokus.fhg.de> <402CEB11.1060906@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 04:19 PM 2/13/2004, Justin Uberti wrote: >Here at AOL we have found that the WRT54G is port-restricted cone in its >normal mode, which is what is documented by Cullen. Interesting, I guess the WRT54G may have some patches -- I just retried iptel's STUN against a Linux 2.4.21 box and the test result is symmetric. (PCAP available for verification at http://iptel.org/stun_test) >Our other test >results are also mostly consistent with the document, with the exception >of some Linksys models, where the difference may be explained by >different firmware versions. We were not able to find any symmetric NATs >in our admittedly small sample. That's good news anyhow and thank you for this information. -jiri _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sat Feb 14 12:08:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22819 for ; Sat, 14 Feb 2004 11:22:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2YQ-00008m-A2 for midcom-archive@odin.ietf.org; Sat, 14 Feb 2004 11:22:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1EGM60O000447 for midcom-archive@odin.ietf.org; Sat, 14 Feb 2004 11:22:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2YL-00005X-Pl; Sat, 14 Feb 2004 11:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2XR-0008UU-Ea for midcom@optimus.ietf.org; Sat, 14 Feb 2004 11:21:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22747 for ; Sat, 14 Feb 2004 11:21:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As2XQ-00079v-00 for midcom@ietf.org; Sat, 14 Feb 2004 11:21:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As2WW-00074L-00 for midcom@ietf.org; Sat, 14 Feb 2004 11:20:08 -0500 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 1As2Vi-0006z9-00 for midcom@ietf.org; Sat, 14 Feb 2004 11:19:18 -0500 Received: by fox.iptel.org (Postfix, from userid 103) id A78699C; Sat, 14 Feb 2004 17:15:38 +0100 (CET) Received: from jku07.iptel.org (fesarius.fokus.fraunhofer.de [193.175.132.142]) by fox.iptel.org (Postfix) with ESMTP id 9E254BD8D; Sat, 14 Feb 2004 17:15:35 +0100 (CET) Message-Id: <6.0.1.1.0.20040214165345.04033e98@mailhub.fokus.fhg.de> X-Sender: jiri@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 14 Feb 2004 17:09:28 +0100 To: Jonathan Rosenberg From: Jiri Kuthan Subject: Re: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt] Cc: Midcom In-Reply-To: <402D1B6A.70803@dynamicsoft.com> References: <402937BE.6030309@dynamicsoft.com> <6.0.1.1.0.20040212201517.03c5fec0@mailhub.fokus.fhg.de> <402D1B6A.70803@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 07:46 PM 2/13/2004, Jonathan Rosenberg wrote: >I disgaree. > >Cullen's results show that we are seeing hybrid NATs whose type depends on whether the random port selected by the client is allocated already or not. In such a case, if the client picks an already-allocated port during the detection phase, it may detect the nat as symmetric, when it fact it might be port restricted in other cases. > >With ICE, if you happen to be unlucky during a stun allocation, turn would get used. If you're lucky, and you get a port-restricted port, then the relay would not be used. So here is a case which makes me puzzled and possibly needs some extra work: SIP client behind a restrictive NAT. With STUN assumptions it will work (as long as they hold, of course),the client will send a "primer" packet to UAS and UAS media will come in. With ICE, a UAS will first check connectivity to UAC's STUN address. The ICE draft suggests doing so on the initial application request (SIP INVITE e.g.) to keep call set up time low. At this moment however, UAC's NAT is not primed yet and the STUN check reports no connectivity. -jiri -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sat Feb 14 23:25:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12017 for ; Sat, 14 Feb 2004 23:25:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsDq8-00075m-PE for midcom-archive@odin.ietf.org; Sat, 14 Feb 2004 23:25:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1F4P887027238 for midcom-archive@odin.ietf.org; Sat, 14 Feb 2004 23:25:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsDq2-000751-Tc; Sat, 14 Feb 2004 23:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsDpD-00073p-K2 for midcom@optimus.ietf.org; Sat, 14 Feb 2004 23:24:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11988 for ; Sat, 14 Feb 2004 23:24:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsDpB-0003Yd-00 for midcom@ietf.org; Sat, 14 Feb 2004 23:24:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsDoK-0003Vy-00 for midcom@ietf.org; Sat, 14 Feb 2004 23:23:17 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AsDng-0003Qr-00 for midcom@ietf.org; Sat, 14 Feb 2004 23:22:36 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1F4MDNr004542; Sat, 14 Feb 2004 23:22:13 -0500 (EST) Message-ID: <402EF3ED.8070905@dynamicsoft.com> Date: Sat, 14 Feb 2004 23:22:05 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yutaka Takeda CC: Midcom Subject: Re: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt] References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Yutaka Takeda wrote: > Although ICE does this job without a knowledge of NAT types, I feel > it is good to have a standardized protocol to discover the types of > NAT. In fact, we would have not been able to come to this point > without the knowledge of NAT types and actual discovery tests, but in > this case, clarification for applicability limitation of the NAT type > discovery process and their reasons should be added to the document > I suppose. Such limitations are in there already. However, people are using these algorithms in any case and are trusting the results. I think, at the very least, that any nat detection or diagnostic usage should be totally removed from the main specification and described purely as a diagnostic tool. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sun Feb 15 19:58:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05713 for ; Sun, 15 Feb 2004 19:58:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsX5L-0003CJ-OJ for midcom-archive@odin.ietf.org; Sun, 15 Feb 2004 19:58:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G0w7Mp012258 for midcom-archive@odin.ietf.org; Sun, 15 Feb 2004 19:58:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsX5F-0003A6-8G; Sun, 15 Feb 2004 19:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsX58-00039t-0P for midcom@optimus.ietf.org; Sun, 15 Feb 2004 19:57:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05707 for ; Sun, 15 Feb 2004 19:57:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsX56-0004o4-00 for midcom@ietf.org; Sun, 15 Feb 2004 19:57:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsX4C-0004lM-00 for midcom@ietf.org; Sun, 15 Feb 2004 19:56:57 -0500 Received: from web40403.mail.yahoo.com ([66.218.78.100]) by ietf-mx with smtp (Exim 4.12) id 1AsX3m-0004if-00 for midcom@ietf.org; Sun, 15 Feb 2004 19:56:30 -0500 Message-ID: <20040216005600.88889.qmail@web40403.mail.yahoo.com> Received: from [66.224.113.194] by web40403.mail.yahoo.com via HTTP; Sun, 15 Feb 2004 16:56:00 PST Date: Sun, 15 Feb 2004 16:56:00 -0800 (PST) From: Pyda Srisuresh Subject: Re: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt] To: Bryan Ford , fluffy@cisco.com, Midcom Cc: srisuresh@yahoo.com In-Reply-To: <200402131001.28752.baford@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Cullen, Interesting compilation of results. Thank you. A few comments below. 1. Primary & Secondary columns in the draft being different - This strikes me as wierd. Would appreciate if you can shed some light on the test used to categorize it thus. If the tests did indeed correctly categrorize a box as being different between primary & secondary port users - Does someone have a clue as to why a vendor might have chosen to do this intentionally? (or) is it likely a unintended bug in the product? Take the case of a Primary being port-restricted and secondary being symmetric - Is the primary truely tested for port-restricted NAT criteria with multiple outgoing and incoming sessions? I..e, Did the same primary-port end-point initiate multiple outgoing connections; And, even as some of the outgoing connections have aged out, the permitted incoming connections are restricted to only those coming from the (ExtAddr, ExtPort) tuples to which there were outgoing sessions previously? Likewise, Was a secondary port user unable to initiate multiple outgoing sessions using the same port bind? In case, the test was performed using a single session on primary port user, I believe, the box may as well have been a "Symmetric NAT" all across (primary as well as secondary port users). Likewise, take the case of primary being port-restricted and secondary being full-cone. Depending upon how the test was performed, this may very well have been "Full cone" for both primary and secondary port users. 2. Group-D/BAD port-binding sounds buggy to me. Why would a vendor choose to do this intentionally? I.e., hope this is the right thing to do most of the time? 3. Port Restricted Cone NATs & Address restricted Cone NATs Below is my understanding of the operational behavior of restricted Cone NATs. Essentially, I believe, both restricted Cone NATs are variations of Full-Cone NAT, with additional firewall restrictions on the permitted incoming connections. I believe, the reverse of the outgoing NAT sessions are retained as firewall packet rules to restrict what is allowed for incoming sessions. The restriction may be one of (External address) or (External address, external port) depending upon whether the device is Address restricted or Port restricted. Now, the questions on their operational behavior. Are the restrictions valid only so long as the port-BIND is active? I.e., even as an outgoign NAT session ages out with idle time, the restricted Cone-NATs will preserve the firewall rules in the reverse direction, so long as the port-BIND is alive, Right? Once the port-BIND is aged out, the associated firewall rules will disappear, right? 4. Several enterrises use SonicWall as their NAT/firewall. Any insight on this from folks out there? 5. Lastly, I agree with the recommendations on the draft - Group-A type of NATs, which are Full-Cone NATs, and support hair-pin connectivity, with or without port-preservation. FWIW, the draft below (draft-ford-midcom-p2p-01.txt) also recommends the same as being P2P friendly. regards, suresh --- Bryan Ford wrote: > On Friday 13 February 2004 08:48 am, Jiri Kuthan wrote: > > A way the IETF can help is to collect recommendations for NATs. There was > > such an effort long time ago > > (http://www.iptel.org/ietf/firewall/nat/draft-ietf-mmusic-natreq4udp-00.txt > >), I maintain a very similar list as well (don't be silly, keep NAT bindings > > for a while, allow hairpinning, try to preserve port numbers, try to use > > stateless binding allocation algorithms). > > FYI, Pyda Srisuresh, Dan Kegel and I have for a while been working on a > document whose sole purpose is to collect precisely these things - general > recommendations for NATs, and general (protocol-independent) recommendations > for applications trying to traverse NATs. It's already gone through a few > versions; the latest one recently came back from first review by the IESG, > and we're hoping to have another, near-final update before long. The most > recent version is available here: > > http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt > > Please let me know if you find inaccuracies or have other comments/additions. > > Thanks! > > Bryan > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Feb 16 14:12:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12211 for ; Mon, 16 Feb 2004 14:12:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsoA1-00079F-82 for midcom-archive@odin.ietf.org; Mon, 16 Feb 2004 14:12:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GJC5ZE027453 for midcom-archive@odin.ietf.org; Mon, 16 Feb 2004 14:12:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aso9w-00078A-Ex; Mon, 16 Feb 2004 14:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aso9P-00076A-Vg for midcom@optimus.ietf.org; Mon, 16 Feb 2004 14:11:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12150 for ; Mon, 16 Feb 2004 14:11:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aso9N-0002g0-00 for midcom@ietf.org; Mon, 16 Feb 2004 14:11:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aso8S-0002ce-00 for midcom@ietf.org; Mon, 16 Feb 2004 14:10:28 -0500 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 1Aso7Z-0002Zm-00 for midcom@ietf.org; Mon, 16 Feb 2004 14:09:33 -0500 Received: by fox.iptel.org (Postfix, from userid 103) id 28A01313F; Mon, 16 Feb 2004 20:05:40 +0100 (CET) Received: from jku07.iptel.org (dhcp195.fokus.fraunhofer.de [195.37.78.195]) by fox.iptel.org (Postfix) with ESMTP id F046E313F; Mon, 16 Feb 2004 20:05:38 +0100 (CET) Message-Id: <6.0.1.1.0.20040216195742.04928ec0@mailhub.fokus.fhg.de> X-Sender: jiri@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 16 Feb 2004 20:00:42 +0100 To: Pyda Srisuresh , Bryan Ford , fluffy@cisco.com, Midcom From: Jiri Kuthan Subject: Re: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt] Cc: srisuresh@yahoo.com In-Reply-To: <20040216005600.88889.qmail@web40403.mail.yahoo.com> References: <200402131001.28752.baford@mit.edu> <20040216005600.88889.qmail@web40403.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 01:56 AM 2/16/2004, Pyda Srisuresh wrote: >Cullen, > >Interesting compilation of results. Thank you. A few comments below. > >1. Primary & Secondary columns in the draft being different - This strikes me >as wierd. I'm surprised by that too -- that's why I would like to see the STUN PCAPs. >5. Lastly, I agree with the recommendations on the draft - Group-A type of >NATs, which are Full-Cone NATs, and support hair-pin connectivity, with or >without port-preservation. S od I. -jiri _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Feb 17 22:27:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25677 for ; Tue, 17 Feb 2004 22:27:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtIMZ-00056m-Uy for midcom-archive@odin.ietf.org; Tue, 17 Feb 2004 22:27:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1I3R31j019631 for midcom-archive@odin.ietf.org; Tue, 17 Feb 2004 22:27:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtIMX-00056V-5H; Tue, 17 Feb 2004 22:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtIM2-00055P-Fv for midcom@optimus.ietf.org; Tue, 17 Feb 2004 22:26:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25641 for ; Tue, 17 Feb 2004 22:26:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtILz-0003Zh-00 for midcom@ietf.org; Tue, 17 Feb 2004 22:26:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtIL1-0003XI-00 for midcom@ietf.org; Tue, 17 Feb 2004 22:25:28 -0500 Received: from 67.105.118.114.ptr.us.xo.net ([67.105.118.114] helo=mail.kmerl.com) by ietf-mx with esmtp (Exim 4.12) id 1AtIKG-0003TU-00 for midcom@ietf.org; Tue, 17 Feb 2004 22:24:40 -0500 content-class: urn:content-classes:message Subject: RE: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Feb 2004 19:24:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: Thread-Topic: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt] Thread-Index: AcPzFs38aAaR+DP2T7KYobn9/lQTnwCs7fuw From: "Yutaka Takeda" To: "Jiri Kuthan" Cc: "Midcom" , "Jonathan Rosenberg" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > With ICE, a UAS will first check connectivity to UAC's STUN address. > The ICE draft suggests doing so on the initial application request > (SIP INVITE e.g.) to keep call set up time low. At this=20 > moment however,=20 > UAC's NAT is not primed yet and the STUN check reports no=20 > connectivity. My understanding is that the connectivity check is done at the same time at both ends. The UAS (responder) may initiate the connectivity check first, the UAS will send 183 Session Progress with SDP (accept message) back to the UAC (initiator) without waiting for completion of the = connectivity check. UAC will start the connectivity check immediately after it = receives the accept message. Timeout duration of STUN transaction is 9.5 seconds which is long enought for UAS to initiate the connectivity check before = UAS side connectivity check is complete. BTW, 9.5 seconds seems to me too long. I would like to know if there is a specific reason for that. Yutaka > -----Original Message----- > From: Jiri Kuthan [mailto:jiri@iptel.org] > Sent: Saturday, February 14, 2004 8:09 AM > To: Jonathan Rosenberg > Cc: Midcom > Subject: Re: [midcom] [Fwd: I-D=20 > ACTION:draft-jennings-midcom-stun-results-00.txt] >=20 >=20 > At 07:46 PM 2/13/2004, Jonathan Rosenberg wrote: > >I disgaree. > > > >Cullen's results show that we are seeing hybrid NATs whose=20 > type depends on whether the random port selected by the=20 > client is allocated already or not. In such a case, if the=20 > client picks an already-allocated port during the detection=20 > phase, it may detect the nat as symmetric, when it fact it=20 > might be port restricted in other cases. > > > >With ICE, if you happen to be unlucky during a stun=20 > allocation, turn would get used. If you're lucky, and you get=20 > a port-restricted port, then the relay would not be used. >=20 > So here is a case which makes me puzzled and possibly needs some > extra work: SIP client behind a restrictive NAT. With STUN assumptions > it will work (as long as they hold, of course),the client will send=20 > a "primer" packet to UAS and UAS media will come in. >=20 > With ICE, a UAS will first check connectivity to UAC's STUN address. > The ICE draft suggests doing so on the initial application request > (SIP INVITE e.g.) to keep call set up time low. At this=20 > moment however,=20 > UAC's NAT is not primed yet and the STUN check reports no=20 > connectivity. >=20 > -jiri >=20 > -- > Jiri Kuthan http://iptel.org/~jiri/=20 >=20 >=20 > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom >=20 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Feb 17 23:42:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28462 for ; Tue, 17 Feb 2004 23:42:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtJXK-0001zF-3L for midcom-archive@odin.ietf.org; Tue, 17 Feb 2004 23:42:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1I4gEGX007613 for midcom-archive@odin.ietf.org; Tue, 17 Feb 2004 23:42:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtJX6-0001vA-B5; Tue, 17 Feb 2004 23:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtJWk-0001uW-90 for midcom@optimus.ietf.org; Tue, 17 Feb 2004 23:41:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28421 for ; Tue, 17 Feb 2004 23:41:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtJWi-0001I6-00 for midcom@ietf.org; Tue, 17 Feb 2004 23:41:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtJVn-0001F0-00 for midcom@ietf.org; Tue, 17 Feb 2004 23:40:39 -0500 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 1AtJVE-0001C3-00 for midcom@ietf.org; Tue, 17 Feb 2004 23:40:04 -0500 Received: by fox.iptel.org (Postfix, from userid 103) id E6DBE99; Wed, 18 Feb 2004 05:36:02 +0100 (CET) Received: from jku07.iptel.org (dhcp241.fokus.fraunhofer.de [195.37.78.241]) by fox.iptel.org (Postfix) with ESMTP id 5ADA999; Wed, 18 Feb 2004 05:35:51 +0100 (CET) Message-Id: <6.0.1.1.0.20040218050833.04695ec0@localhost> X-Sender: jiri@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 18 Feb 2004 05:36:13 +0100 To: "Yutaka Takeda" From: Jiri Kuthan Subject: RE: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt] Cc: "Midcom" , "Jonathan Rosenberg" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 04:24 AM 2/18/2004, Yutaka Takeda wrote: >> With ICE, a UAS will first check connectivity to UAC's STUN address. >> The ICE draft suggests doing so on the initial application request >> (SIP INVITE e.g.) to keep call set up time low. At this >> moment however, >> UAC's NAT is not primed yet and the STUN check reports no >> connectivity. > >My understanding is that the connectivity check is done at the same time >at both ends. I am not sure ICE is now suggesting UAC's connectivity checks and I still see race conditions potential in the call flow. For example, UAS may get ICMP errors for the connectivity checks before UAC receives 183 and primes its NAT with its connectivity checks. -jiri >The UAS (responder) may initiate the connectivity check >first, the UAS will send 183 Session Progress with SDP (accept message) >back to the UAC (initiator) without waiting for completion of the connectivity >check. UAC will start the connectivity check immediately after it receives the >accept message. Timeout duration of STUN transaction is 9.5 seconds >which is long enought for UAS to initiate the connectivity check before UAS >side connectivity check is complete. > >BTW, 9.5 seconds seems to me too long. I would like to know if there is >a specific reason for that. > >Yutaka > > > >> -----Original Message----- >> From: Jiri Kuthan [mailto:jiri@iptel.org] >> Sent: Saturday, February 14, 2004 8:09 AM >> To: Jonathan Rosenberg >> Cc: Midcom >> Subject: Re: [midcom] [Fwd: I-D >> ACTION:draft-jennings-midcom-stun-results-00.txt] >> >> >> At 07:46 PM 2/13/2004, Jonathan Rosenberg wrote: >> >I disgaree. >> > >> >Cullen's results show that we are seeing hybrid NATs whose >> type depends on whether the random port selected by the >> client is allocated already or not. In such a case, if the >> client picks an already-allocated port during the detection >> phase, it may detect the nat as symmetric, when it fact it >> might be port restricted in other cases. >> > >> >With ICE, if you happen to be unlucky during a stun >> allocation, turn would get used. If you're lucky, and you get >> a port-restricted port, then the relay would not be used. >> >> So here is a case which makes me puzzled and possibly needs some >> extra work: SIP client behind a restrictive NAT. With STUN assumptions >> it will work (as long as they hold, of course),the client will send >> a "primer" packet to UAS and UAS media will come in. >> >> With ICE, a UAS will first check connectivity to UAC's STUN address. >> The ICE draft suggests doing so on the initial application request >> (SIP INVITE e.g.) to keep call set up time low. At this >> moment however, >> UAC's NAT is not primed yet and the STUN check reports no >> connectivity. >> >> -jiri >> >> -- >> Jiri Kuthan http://iptel.org/~jiri/ >> >> >> _______________________________________________ >> midcom mailing list >> midcom@ietf.org >> https://www1.ietf.org/mailman/listinfo/midcom >> -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Feb 18 23:56:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13138 for ; Wed, 18 Feb 2004 23:56:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtgEH-0003Ej-35 for midcom-archive@odin.ietf.org; Wed, 18 Feb 2004 23:56:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J4u4q4012406 for midcom-archive@odin.ietf.org; Wed, 18 Feb 2004 23:56:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtgEE-0003Cr-DQ; Wed, 18 Feb 2004 23:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtgE3-0003CC-JP for midcom@optimus.ietf.org; Wed, 18 Feb 2004 23:55:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13134 for ; Wed, 18 Feb 2004 23:55:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtgE1-0001jU-00 for midcom@ietf.org; Wed, 18 Feb 2004 23:55:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtgD9-0001i3-00 for midcom@ietf.org; Wed, 18 Feb 2004 23:54:56 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AtgCV-0001fO-00 for midcom@ietf.org; Wed, 18 Feb 2004 23:54:15 -0500 Received: from dynamicsoft.com ([63.113.46.116]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1J4rpNr006471; Wed, 18 Feb 2004 23:53:51 -0500 (EST) Message-ID: <40344155.9030703@dynamicsoft.com> Date: Wed, 18 Feb 2004 23:53:41 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yutaka Takeda CC: Jiri Kuthan , Midcom Subject: Re: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt] References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Yutaka Takeda wrote: >>With ICE, a UAS will first check connectivity to UAC's STUN address. >>The ICE draft suggests doing so on the initial application request >>(SIP INVITE e.g.) to keep call set up time low. At this >>moment however, >>UAC's NAT is not primed yet and the STUN check reports no >>connectivity. > > > My understanding is that the connectivity check is done at the same time > at both ends. The UAS (responder) may initiate the connectivity check > first, the UAS will send 183 Session Progress with SDP (accept message) > back to the UAC (initiator) without waiting for completion of the connectivity > check. This is allowed, yes. > UAC will start the connectivity check immediately after it receives the > accept message. Right. > Timeout duration of STUN transaction is 9.5 seconds > which is long enought for UAS to initiate the connectivity check before UAS > side connectivity check is complete. I think you mean "long enough for the UAC to initiate the connectivity check before the UAS side connectivity check is complete". I believe that will work, yes, though it does REQUIRE the UAS to issue a 183 immediately, as opposed to waiting as long as it wants. In the current draft, the original approach for dealing with port restricted was to do another ice cycle, i.e., a second o/a exchange which would re-do the checks. However, doing it with a single cycle would be highly preferred, so I like Yutaka's suggestion on this. > > BTW, 9.5 seconds seems to me too long. I would like to know if there is > a specific reason for that. Typical value for transaction timeouts on public Internet. SIP uses an even larger number, 32s. STUN is quite aggressive by comparison. Also, note that with ICE, the clients will use the "default" media path - generally through a relay - until the connectivity checks yield something better. So you'll still get media flowing even if the checks take much longer. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Feb 18 23:58:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13190 for ; Wed, 18 Feb 2004 23:58:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtgG9-0003Oj-S6 for midcom-archive@odin.ietf.org; Wed, 18 Feb 2004 23:58:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J4w1vB013037 for midcom-archive@odin.ietf.org; Wed, 18 Feb 2004 23:58:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtgG9-0003Nt-E8; Wed, 18 Feb 2004 23:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtgG1-0003NV-E1 for midcom@optimus.ietf.org; Wed, 18 Feb 2004 23:57:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13183 for ; Wed, 18 Feb 2004 23:57:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtgFz-0001nH-00 for midcom@ietf.org; Wed, 18 Feb 2004 23:57:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtgF2-0001ll-00 for midcom@ietf.org; Wed, 18 Feb 2004 23:56:52 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AtgEd-0001kD-00 for midcom@ietf.org; Wed, 18 Feb 2004 23:56:27 -0500 Received: from dynamicsoft.com ([63.113.46.116]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1J4u8Nr006477; Wed, 18 Feb 2004 23:56:08 -0500 (EST) Message-ID: <403441DD.206@dynamicsoft.com> Date: Wed, 18 Feb 2004 23:55:57 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jiri Kuthan CC: Yutaka Takeda , Midcom Subject: Re: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt] References: <6.0.1.1.0.20040218050833.04695ec0@localhost> In-Reply-To: <6.0.1.1.0.20040218050833.04695ec0@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jiri Kuthan wrote: > At 04:24 AM 2/18/2004, Yutaka Takeda wrote: > >>>With ICE, a UAS will first check connectivity to UAC's STUN address. >>>The ICE draft suggests doing so on the initial application request >>>(SIP INVITE e.g.) to keep call set up time low. At this >>>moment however, >>>UAC's NAT is not primed yet and the STUN check reports no >>>connectivity. >> >>My understanding is that the connectivity check is done at the same time >>at both ends. > > > I am not sure ICE is now suggesting UAC's connectivity checks Yes, ICE has both sides doing checks. > and I still see > race conditions potential in the call flow. For example, UAS may get ICMP errors > for the connectivity checks before UAC receives 183 and primes its NAT with its > connectivity checks. My understanding is that most NATs do not generate ICMP if you hit unallocated ports, as it would facilitate port scans. However, if this is a real concern, its easily addressed by simply mandating the checks on the uas side get done over some duration so that you are sure they really have failed. Are there other race conditions you know of? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Feb 19 12:28:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28053 for ; Thu, 19 Feb 2004 12:28:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtryB-0003KA-Tz for midcom-archive@odin.ietf.org; Thu, 19 Feb 2004 12:28:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JHSFmw012759 for midcom-archive@odin.ietf.org; Thu, 19 Feb 2004 12:28:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atrxx-0003H7-4m; Thu, 19 Feb 2004 12:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtrxF-00039O-On for midcom@optimus.ietf.org; Thu, 19 Feb 2004 12:27:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28004 for ; Thu, 19 Feb 2004 12:27:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtrxE-0001xs-00 for midcom@ietf.org; Thu, 19 Feb 2004 12:27:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtrwP-0001uQ-00 for midcom@ietf.org; Thu, 19 Feb 2004 12:26:25 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AtrvY-0001nl-00 for midcom@ietf.org; Thu, 19 Feb 2004 12:25:32 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 19 Feb 2004 09:34:50 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1JHOwuA006298 for ; Thu, 19 Feb 2004 09:24:58 -0800 (PST) Received: from cisco.com ([10.25.65.182]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ARB57909; Thu, 19 Feb 2004 09:24:57 -0800 (PST) Date: Thu, 19 Feb 2004 12:24:55 -0500 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Melinda Shore To: midcom@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <88AC842B-6300-11D8-AC62-000A95E35274@cisco.com> X-Mailer: Apple Mail (2.553) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [midcom] Fwd: [rfc-i] RFC Copyrights and Disclaimers for IPRs Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit FYI. Melinda Begin forwarded message: > From: Joyce Reynolds > Date: Thu Feb 19, 2004 12:05:39 PM US/Eastern > To: iab@ietf.org, iesg@ietf.org > Cc: rfc-editor@rfc-editor.org, rfc-interest@rfc-editor.org > Subject: [rfc-i] RFC Copyrights and Disclaimers for IPRs > Reply-To: Joyce Reynolds > > > > Following the publication of BCP 78 (RFC 3667), BCP 79 (RFC 3668), and > RFC 3669 on Feb 18, 2004, the RFC Editor has begun to incorporate into > all documents slated for RFC publication the copyright and intellectual > property rights statements called for by these documents. > > We have placed on our web pages the current RFC Editor rules governing > RFC copyrights and disclaimers for intellectual property rights, > derived from the above IETF documents: > > http://www.rfc-editor.org/copyright.html > > Joyce > (for RFC Editor) > > > _______________________________________________ > rfc-interest mailing list > rfc-interest@rfc-editor.org > http://www.rfc-editor.org/mailman/listinfo/rfc-interest > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Feb 19 16:18:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14466 for ; Thu, 19 Feb 2004 16:18:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtvYb-00026h-93 for midcom-archive@odin.ietf.org; Thu, 19 Feb 2004 16:18:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JLI5tW008065 for midcom-archive@odin.ietf.org; Thu, 19 Feb 2004 16:18:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtvYX-00025s-IE; Thu, 19 Feb 2004 16:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtvXw-00023W-Bx for midcom@optimus.ietf.org; Thu, 19 Feb 2004 16:17:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13059 for ; Thu, 19 Feb 2004 16:17:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtvXu-0000dy-00 for midcom@ietf.org; Thu, 19 Feb 2004 16:17:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtvX4-0000c4-00 for midcom@ietf.org; Thu, 19 Feb 2004 16:16:31 -0500 Received: from 67.105.118.114.ptr.us.xo.net ([67.105.118.114] helo=mail.kmerl.com) by ietf-mx with esmtp (Exim 4.12) id 1AtvWj-0000ZA-00 for midcom@ietf.org; Thu, 19 Feb 2004 16:16:09 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Feb 2004 13:15:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: Thread-Topic: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt] Thread-Index: AcP2pG/LJivNHDnRRqyx3XmqX4S/7wAhvAew From: "Yutaka Takeda" To: "Jonathan Rosenberg" Cc: "Jiri Kuthan" , "Midcom" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [midcom] STUN transaction timeout Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Jonathan Rosenberg wrote: > > BTW, 9.5 seconds seems to me too long. I would like to know=20 > if there is > > a specific reason for that. >=20 > Typical value for transaction timeouts on public Internet.=20 > SIP uses an=20 > even larger number, 32s. STUN is quite aggressive by comparison. >=20 > Also, note that with ICE, the clients will use the "default"=20 > media path=20 > - generally through a relay - until the connectivity checks yield=20 > something better. So you'll still get media flowing even if=20 > the checks=20 > take much longer. Thanks for the reply, although I am not clear about this yet... I understand we can grab a guaranteed media path through a relay for immediate connection, however, I believe there may be a service that can not afford the relay server, or even it could afford it, it is=20 desired that a client find the best path to be used ASAP. In connectivity check, STUN packets are used right on a media path.=20 Target transport addresses have already been ready to receive the STUN packets by the time a client initiates connectivity checks. To me, if there is considerable amount of delay, that is simply propagation delay on the media path, any other signal transactions=20 are not involved. If this is correct, the media path taking such a long=20 time would not be a good one to be used especially for a phone=20 conversation. Any other factors for the delay you are aware of? One thing I thought.. May be we can measure the propagation delay with STUN packet and put this factor into logic to determine the best path, leaving the timeout spec as is, so that client does not chose a path taking more than a specified amount of time (e.g. 2 seconds) for a phone=20 conversation. Yutaka _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Feb 20 19:15:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24186 for ; Fri, 20 Feb 2004 19:15:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuKnW-0001PX-Pu for midcom-archive@odin.ietf.org; Fri, 20 Feb 2004 19:15:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1L0FA2G005399 for midcom-archive@odin.ietf.org; Fri, 20 Feb 2004 19:15:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuKnO-0001Oe-DG; Fri, 20 Feb 2004 19:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuKme-0001AG-KD for midcom@optimus.ietf.org; Fri, 20 Feb 2004 19:14:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24170 for ; Fri, 20 Feb 2004 19:14:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuKmd-00014f-00 for midcom@ietf.org; Fri, 20 Feb 2004 19:14:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuKll-00011y-00 for midcom@ietf.org; Fri, 20 Feb 2004 19:13:22 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AuKl3-0000vr-00 for midcom@ietf.org; Fri, 20 Feb 2004 19:12:37 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 20 Feb 2004 16:21:31 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1L0C14Y028252; Fri, 20 Feb 2004 16:12:05 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQM51275; Fri, 20 Feb 2004 16:12:01 -0800 (PST) In-Reply-To: <402D1B6A.70803@dynamicsoft.com> References: <402937BE.6030309@dynamicsoft.com> <6.0.1.1.0.20040212201517.03c5fec0@mailhub.fokus.fhg.de> <402D1B6A.70803@dynamicsoft.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , Jiri Kuthan , Midcom From: Rohan Mahy Subject: Re: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt] Date: Fri, 20 Feb 2004 16:12:33 -0800 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Feb 13, 2004, at 10:46 AM, Jonathan Rosenberg wrote: > Jiri Kuthan wrote: > >> At 08:57 PM 2/10/2004, Jonathan Rosenberg wrote: >>> This is a great piece of work. Thanks to Cullen for putting this >>> together. >>> One conclusion I draw from this is that, as STUN itself predicts, >>> the NAT classification algorithm is brittle because it makes >>> assumptions about the types of NATs and there behaviors. We are now >>> seeing NATs that have this dual behavior, depending on whether the >>> internal port is allocated or not, and STUN's detection algorithm >>> does not take this into account. Indeed, I would be inclined to >>> work on reivising STUN, and in such a revision, remove the >>> detection algorithm and explain why that was done. What do people >>> think of that? >> I think there is still some value in the NAT-type tests even with use >> of ICE. Positive assertions about traversable NATs may be brittle, I >> agree. Negative assertions about hard-to-traverse NATs are quite safe >> and can eliminiate unnecessary tries. Particularly, if you know you >> are behind a symmetric NAT you can safely eliminate STUN address from >> your offer. > > I disgaree. > > Cullen's results show that we are seeing hybrid NATs whose type > depends on whether the random port selected by the client is allocated > already or not. In such a case, if the client picks an > already-allocated port during the detection phase, it may detect the > nat as symmetric, when it fact it might be port restricted in other > cases. > > With ICE, if you happen to be unlucky during a stun allocation, turn > would get used. If you're lucky, and you get a port-restricted port, > then the relay would not be used. I find this situation sufficiently unlikely that I would prefer to "just use TURN" when i detect a symmetric NAT for code-path simplicity and lower call setup delay. thx, -rohan >>> To me, this also further strengthens the arguments behind something >>> like ICE >>> (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-00.txt), >>> which uses STUN, but does *not* use the detection algorithm. >>> Rather, it relies on dynamic connectivity checks to figure out >>> whether an address works or not. The argument there is that, >>> ultimately, the only way to know whether you can receive media sent >>> from address A to interface X is if you can receive a packet from >>> address A sent to interface X. Any other way of verifying this >>> conclusion is based on assumptions that can be wrong. >> Whereas I am quite comfortable with ICE and enjoy its e2e robustness, >> I think there is still some other, parallel, undone work. The left >> option of using a media relay indicates to me that there is an >> architectural imperfection and I see it in silly NATs (silly is an >> aggregate word standing for undeterministic or symmetric or bad or >> whatsoever). > > Yes, it would be nice to obliterate such devices. With ICE, once > obliterated, the relay would simply cease seeing any traffic, and you > know at that time that you can disconnect it safely. As such, ICE > provides a nice way to transition from here to there. > > > It seems very desirable to me to abandon such devices >> and I think it is a quite realistic goal. Cullen's draft actually >> strengthens my hope that it is happening. >> A way the IETF can help is to collect recommendations for NATs. There >> was such an effort long time ago >> (http://www.iptel.org/ietf/firewall/nat/draft-ietf-mmusic-natreq4udp >> -00.txt), >> I maintain a very similar list as well (don't be silly, keep NAT >> bindings for a while, allow hairpinning, try to preserve port >> numbers, try to use stateless binding allocation algorithms). > > I agree work needs to be done here. > > -Jonathan R. > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sat Feb 21 21:53:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26490 for ; Sat, 21 Feb 2004 21:53:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aujjs-0004sQ-Hg for midcom-archive@odin.ietf.org; Sat, 21 Feb 2004 21:53:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1M2r4Kv018701 for midcom-archive@odin.ietf.org; Sat, 21 Feb 2004 21:53:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aujjs-0004rC-1P; Sat, 21 Feb 2004 21:53:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aujj9-0004lX-Ef for midcom@optimus.ietf.org; Sat, 21 Feb 2004 21:52:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26436 for ; Sat, 21 Feb 2004 21:52:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aujj6-0004ly-00 for midcom@ietf.org; Sat, 21 Feb 2004 21:52:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AujiF-0004fh-00 for midcom@ietf.org; Sat, 21 Feb 2004 21:51:23 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AujhF-0004U0-00 for midcom@ietf.org; Sat, 21 Feb 2004 21:50:21 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 21 Feb 2004 18:59:33 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1M2nq1o002511; Sat, 21 Feb 2004 18:49:54 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn2-891.cisco.com [10.21.115.123]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMO15054; Sat, 21 Feb 2004 18:49:52 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sat, 21 Feb 2004 17:34:28 -0800 Subject: Re: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt From: Cullen Jennings To: Justin Uberti , Midcom Message-ID: In-Reply-To: <402D1949.8060804@dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 2/13/04 10:36 AM, "Jonathan Rosenberg" wrote: >> >> FWIW, we have found that some Linksys routers will rewrite the IP >> address in the STUN reply to be the nonroutable (e.g. 192.168.x.x) >> address rather than the NAT address, causing the STUN detection to >> classify the connectivity as "Open". > > Sigh... Cullen reports in his document that he did not see this > behavior. Its one of my regrets in stun - that we did not properly > encrypt the address to avoid rewriting by nat. If we were to do a > revision of stun, I would like to address this also. If you can get me the version of the Linksys that did this - that would help me. Others have reported this too, I'm sure it happens, I just can't find a version that does it. There was a SIP ALG on the linksys stuff but that now defaults to off. I have some traces that show this happening on an older Speedstream ss2604 too so if someone has one of these and would be willing to send it to me, I'll swap you some other Linksys with a wireless access point. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sat Feb 21 21:53:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26489 for ; Sat, 21 Feb 2004 21:53:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aujjs-0004rW-4G for midcom-archive@odin.ietf.org; Sat, 21 Feb 2004 21:53:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1M2r3Qw018576 for midcom-archive@odin.ietf.org; Sat, 21 Feb 2004 21:53:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aujjq-0004oL-Nc; Sat, 21 Feb 2004 21:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aujj6-0004lN-Jz for midcom@optimus.ietf.org; Sat, 21 Feb 2004 21:52:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26430 for ; Sat, 21 Feb 2004 21:52:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aujj3-0004lf-00 for midcom@ietf.org; Sat, 21 Feb 2004 21:52:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AujiB-0004ex-00 for midcom@ietf.org; Sat, 21 Feb 2004 21:51:19 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AujhE-0004U0-02 for midcom@ietf.org; Sat, 21 Feb 2004 21:50:21 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 21 Feb 2004 18:59:31 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1M2nq1m002511; Sat, 21 Feb 2004 18:49:53 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn2-891.cisco.com [10.21.115.123]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMO15053; Sat, 21 Feb 2004 18:49:51 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sat, 21 Feb 2004 17:23:45 -0800 From: Cullen Jennings To: Midcom CC: Jonathan Rosenberg Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [midcom] Some extensions to STUN. Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'm interested in adding few other tests to characterize NATs. One is testing to see if they rewrite data inside the payload of a UDP packet. NATs have been observed that rewrite the mapped address inside the stun packet. Multiple people have suggested a solution to this - an extension that returned an encrypted (mostly likely with xor) form of the the mapped address with some predefined key would detect this. The other tests probably do not require any STUN extension. One would be to look at NATs that changed their characteristics after the first packet. For example some devices act like a full cone on the first packet then after the first packet arrives, restrict down to only accept future packets from the same location as this first packet. (Rohan, Dan Wing, others have proposed this) Another test would be to check if a NAT is sending to two different addresses from the same port, will a packet on one flow update binding times for both flows. Some recommendations are still needed on how to keep NAT bindings alive. I suspect the deeper we look into how NATs operate, the more we will find strange cases. This leads me to be fairly keen on using _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sat Feb 21 21:53:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26575 for ; Sat, 21 Feb 2004 21:53:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aujjt-0004tV-7u for midcom-archive@odin.ietf.org; Sat, 21 Feb 2004 21:53:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1M2r55g018772 for midcom-archive@odin.ietf.org; Sat, 21 Feb 2004 21:53:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aujjs-0004se-TX; Sat, 21 Feb 2004 21:53:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AujjE-0004m8-Tp for midcom@optimus.ietf.org; Sat, 21 Feb 2004 21:52:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26439 for ; Sat, 21 Feb 2004 21:52:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AujjC-0004mv-00 for midcom@ietf.org; Sat, 21 Feb 2004 21:52:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AujiK-0004gd-00 for midcom@ietf.org; Sat, 21 Feb 2004 21:51:29 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AujhL-0004U6-00 for midcom@ietf.org; Sat, 21 Feb 2004 21:50:27 -0500 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1M2ntuA021377; Sat, 21 Feb 2004 18:49:56 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn2-891.cisco.com [10.21.115.123]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMO15057; Sat, 21 Feb 2004 18:49:54 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sat, 21 Feb 2004 18:25:18 -0800 Subject: Re: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt] From: Cullen Jennings To: Pyda Srisuresh , Bryan Ford , Midcom Message-ID: In-Reply-To: <20040216005600.88889.qmail@web40403.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Whole bunch inline - thanks for the comments On 2/15/04 4:56 PM, "Pyda Srisuresh" wrote: > Cullen, > > Interesting compilation of results. Thank you. A few comments below. > > 1. Primary & Secondary columns in the draft being different - This strikes me > as wierd. Would appreciate if you can shed some light on the test used to > categorize it thus. If the tests did indeed correctly categrorize a box as > being different between primary & secondary port users - Does someone have a > clue as to why a vendor might have chosen to do this intentionally? (or) is it > likely a unintended bug in the product? I tracked down one programmer who was the guy who implemented this in one product with this same question. It was unintentional. It was intentional to try to preserve the port, it's more likely to make things work and keeps port numbers the same for network snifters. I'm not sure I fully buy the argument that you try and preserver ports but I at least can see the argument. Clearly you can't always use the same port (well ignoring group D for now :-). This one set of code ended up with two different logic flow depending on if the port was already in use or not. Since the implementer was unaware that symmetric vs. port restricted might make a difference at the time the code was written, they did not worry that the behavior was different. Actually it was somewhat a surprise to the implementer that the behavior was different. I suspect that in all the cases where the behavior changed, it was not an intention feature of the product but just an artifact of how the code ended up. > > Take the case of a Primary being port-restricted and secondary being symmetric > - Is the primary truely tested for port-restricted NAT criteria with multiple > outgoing and incoming sessions? I..e, Did the same primary-port end-point > initiate multiple outgoing connections; And, even as some of the outgoing > connections have aged out, the permitted incoming connections are restricted > to > only those coming from the (ExtAddr, ExtPort) tuples to which there were > outgoing sessions previously? Likewise, Was a secondary port user unable to > initiate multiple outgoing sessions using the same port bind? > > In case, the test was performed using a single session on primary port user, I > believe, the box may as well have been a "Symmetric NAT" all across (primary > as > well as secondary port users). The test was done by using a client that two IP addresses ( call the address A and B) on a single NIC. First stun was run from address A, and a fixed port (9000) was used as the port that the client sent the stun tests from. This takes a second or so. Right after that, the STUN tests are run from port 9000 on IP address B. On NATs that try to preserve ports, the first packet from A:9000 gets port 9000 on the public side of the NAT. When the packet comes from B, it wants to use 9000 but that port is already in use by A so it allocates some other port. I believe you would get the same results if you had run two STUN tests at the same time from two different clients running on two different PC's behind the same NAT and both STUN clients sending their packets from the same port number. The bad news about this test is that there is no way to know what type of NAT you are behind if all you have is a single IP address. > > Likewise, take the case of primary being port-restricted and secondary being > full-cone. Depending upon how the test was performed, this may very well have > been "Full cone" for both primary and secondary port users. > > 2. Group-D/BAD port-binding sounds buggy to me. Why would a vendor choose to > do > this intentionally? I.e., hope this is the right thing to do most of the time? > Uh, yah, I would think of this is a bug too. Some people of course would describe all NAT's as a serious bug in an IP router. I was goofing around with running applications from two PC's at the same time that were behind these NATs. Ironically, the robustness of the retransmission mechanism I the the IP protocols caused these to work better than I thought they would. One PC would get the response it wanted, plus some garbage meant for the other PC, then the other PC would retransmit and cause some result to be resent that was meant for it. The robustness for the packet retransmission schemes caused stuff to work. I don't mean to encourage anyone to use this approach - I think it is a bad approach - it did not work well - it just worked better than I thought it would. > 3. Port Restricted Cone NATs & Address restricted Cone NATs > > Below is my understanding of the operational behavior of restricted Cone NATs. > Essentially, I believe, both restricted Cone NATs are variations of Full-Cone > NAT, with additional firewall restrictions on the permitted incoming > connections. > > I believe, the reverse of the outgoing NAT sessions are retained as firewall > packet rules to restrict what is allowed for incoming sessions. The > restriction > may be one of (External address) or (External address, external port) > depending > upon whether the device is Address restricted or Port restricted. Yes > > Now, the questions on their operational behavior. > > Are the restrictions valid only so long as the port-BIND is active? I.e., even > as an outgoign NAT session ages out with idle time, the restricted Cone-NATs > will preserve the firewall rules in the reverse direction, so long as the > port-BIND is alive, Right? Once the port-BIND is aged out, the associated > firewall rules will disappear, right? Sounds like a good guess - I did not the aging and timing stuff. Most things seemed over 30 seconds and less than or equal to 7200 seconds. I'd like to do more experiments to learn a bit more about what types of things reset the timers (outgoing packets, incoming, either, etc) > > 4. Several enterrises use SonicWall as their NAT/firewall. Any insight on this > from folks out there? I'm going to get around to testing some of the enterprise stuff some time. I seem to recall one of the p2p authors had a more than casual understanding of things like SonicWall. Any tests you recommend that we should look at with enterprise systems? I want to tests that will detect anything that is going to give me a nasty surprise when I try to deploy RTP over it. > > 5. Lastly, I agree with the recommendations on the draft - Group-A type of > NATs, which are Full-Cone NATs, and support hair-pin connectivity, with or > without port-preservation. FWIW, the draft below > (draft-ford-midcom-p2p-01.txt) > also recommends the same as being P2P friendly. > Cool - I've been meaning to find the time to properly understand and sync up with you, Bryan, and Dan on the p2p draft. I've just been running out of time but I like what it is trying to accomplish. > regards, > suresh > > --- Bryan Ford wrote: >> On Friday 13 February 2004 08:48 am, Jiri Kuthan wrote: >>> A way the IETF can help is to collect recommendations for NATs. There was >>> such an effort long time ago >>> (http://www.iptel.org/ietf/firewall/nat/draft-ietf-mmusic-natreq4udp-00.txt >>> ), I maintain a very similar list as well (don't be silly, keep NAT bindings >>> for a while, allow hairpinning, try to preserve port numbers, try to use >>> stateless binding allocation algorithms). >> >> FYI, Pyda Srisuresh, Dan Kegel and I have for a while been working on a >> document whose sole purpose is to collect precisely these things - general >> recommendations for NATs, and general (protocol-independent) recommendations >> for applications trying to traverse NATs. It's already gone through a few >> versions; the latest one recently came back from first review by the IESG, >> and we're hoping to have another, near-final update before long. The most >> recent version is available here: >> >> http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt >> >> Please let me know if you find inaccuracies or have other comments/additions. >> >> Thanks! >> >> Bryan >> >> >> _______________________________________________ >> midcom mailing list >> midcom@ietf.org >> https://www1.ietf.org/mailman/listinfo/midcom > > > ===== > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sat Feb 21 22:40:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26485 for ; Sat, 21 Feb 2004 21:53:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aujjs-0004rk-6q for midcom-archive@odin.ietf.org; Sat, 21 Feb 2004 21:53:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1M2r3wf018566 for midcom-archive@odin.ietf.org; Sat, 21 Feb 2004 21:53:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aujjr-0004ok-67; Sat, 21 Feb 2004 21:53:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aujj7-0004lS-89 for midcom@optimus.ietf.org; Sat, 21 Feb 2004 21:52:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26433 for ; Sat, 21 Feb 2004 21:52:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aujj4-0004lk-00 for midcom@ietf.org; Sat, 21 Feb 2004 21:52:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AujiB-0004f5-00 for midcom@ietf.org; Sat, 21 Feb 2004 21:51:20 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AujhE-0004U3-00 for midcom@ietf.org; Sat, 21 Feb 2004 21:50:21 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 21 Feb 2004 19:00:10 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1M2nnuA021343 for ; Sat, 21 Feb 2004 18:49:50 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn2-891.cisco.com [10.21.115.123]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMO15046; Sat, 21 Feb 2004 18:49:48 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sat, 21 Feb 2004 14:14:31 -0800 From: Cullen Jennings To: Midcom Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.5 required=5.0 tests=AWL,DATE_IN_FUTURE_03_06 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [midcom] STUN Interop results Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit At the recent SIPIT, we tested a handful of clients and a few servers but, unfortunately, with only two types of NATs. All the clients worked with all the servers and agreed on the types of the NATs. No one did TLS for authorization. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sat Feb 21 22:40:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26491 for ; Sat, 21 Feb 2004 21:53:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aujjs-0004ro-8e for midcom-archive@odin.ietf.org; Sat, 21 Feb 2004 21:53:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1M2r3lG018564 for midcom-archive@odin.ietf.org; Sat, 21 Feb 2004 21:53:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aujjq-0004nO-6k; Sat, 21 Feb 2004 21:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aujj6-0004lH-2N for midcom@optimus.ietf.org; Sat, 21 Feb 2004 21:52:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26427 for ; Sat, 21 Feb 2004 21:52:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aujj3-0004la-00 for midcom@ietf.org; Sat, 21 Feb 2004 21:52:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AujiA-0004eo-00 for midcom@ietf.org; Sat, 21 Feb 2004 21:51:19 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AujhE-0004U0-01 for midcom@ietf.org; Sat, 21 Feb 2004 21:50:20 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 21 Feb 2004 18:59:30 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1M2nnuC021343; Sat, 21 Feb 2004 18:49:51 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn2-891.cisco.com [10.21.115.123]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMO15047; Sat, 21 Feb 2004 18:49:49 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sat, 21 Feb 2004 14:39:14 -0800 Subject: Re: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt From: Cullen Jennings To: Justin Uberti , Jiri Kuthan CC: Jonathan Rosenberg , Midcom Message-ID: In-Reply-To: <402CEB11.1060906@aol.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.5 required=5.0 tests=AWL,DATE_IN_FUTURE_03_06 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 2/13/04 7:19 AM, "Justin Uberti" wrote: > Linksys 59% > Netgear 14% > DLink 13% > Belkin 5% > Microsoft 3% > SMC 2% > Siemens 2% > Zyxel 1% > ActionTec 1% > 3Com <1% > Comcast <1% > Dell <1% That is great information to help deal with deciding what to do. Thank you very much for providing it. If anyone could provide similar information that would be great. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sat Feb 21 22:40:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26486 for ; Sat, 21 Feb 2004 21:53:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aujjs-0004rV-3j for midcom-archive@odin.ietf.org; Sat, 21 Feb 2004 21:53:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1M2r36v018558 for midcom-archive@odin.ietf.org; Sat, 21 Feb 2004 21:53:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aujjp-0004n8-AT; Sat, 21 Feb 2004 21:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aujj1-0004l7-PI for midcom@optimus.ietf.org; Sat, 21 Feb 2004 21:52:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26421 for ; Sat, 21 Feb 2004 21:52:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aujiy-0004l1-00 for midcom@ietf.org; Sat, 21 Feb 2004 21:52:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Auji6-0004e4-00 for midcom@ietf.org; Sat, 21 Feb 2004 21:51:14 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AujhD-0004U0-00 for midcom@ietf.org; Sat, 21 Feb 2004 21:50:19 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 21 Feb 2004 18:59:27 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1M2nmuA021334 for ; Sat, 21 Feb 2004 18:49:49 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn2-891.cisco.com [10.21.115.123]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMO15043; Sat, 21 Feb 2004 18:49:47 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sat, 21 Feb 2004 14:07:47 -0800 From: Cullen Jennings To: Midcom Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.5 required=5.0 tests=AWL,DATE_IN_FUTURE_03_06 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [midcom] Software used in stun results test Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I have had a few questions about the software used for the tests. It is all open source (not GPL can be used in commercial products) and is at http://sourceforge.net/projects/stun/ A server is running at larry.gloo.net. There is a windows executable (WinStun) that you can use to test what type of NAT you have with pretty minimal effort. There is a command line client and server that runs in linux, Macosx, and windows. It will probably work on most unix boxes. There are no instructions, it was hard to write, it should be hard to use. The server requires you to configure two IP addresses on the machine. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sat Feb 21 22:40:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26524 for ; Sat, 21 Feb 2004 21:53:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aujjs-0004rX-62 for midcom-archive@odin.ietf.org; Sat, 21 Feb 2004 21:53:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1M2r3A2018573 for midcom-archive@odin.ietf.org; Sat, 21 Feb 2004 21:53:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aujjp-0004nG-Nt; Sat, 21 Feb 2004 21:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aujj4-0004lC-Iv for midcom@optimus.ietf.org; Sat, 21 Feb 2004 21:52:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26424 for ; Sat, 21 Feb 2004 21:52:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aujj1-0004lN-00 for midcom@ietf.org; Sat, 21 Feb 2004 21:52:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Auji9-0004ef-00 for midcom@ietf.org; Sat, 21 Feb 2004 21:51:18 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AujhE-0004U0-00 for midcom@ietf.org; Sat, 21 Feb 2004 21:50:20 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 21 Feb 2004 18:59:29 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1M2nmuC021334; Sat, 21 Feb 2004 18:49:50 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn2-891.cisco.com [10.21.115.123]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMO15045; Sat, 21 Feb 2004 18:49:47 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sat, 21 Feb 2004 14:13:12 -0800 From: Cullen Jennings To: Jiri Kuthan , Midcom Message-ID: In-Reply-To: <6.0.1.1.0.20040213130456.03afaec0@mailhub.fokus.fhg.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.5 required=5.0 tests=AWL,DATE_IN_FUTURE_03_06 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [midcom] Stun results - WRT54G Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 2/13/04 4:08 AM, "Jiri Kuthan" wrote: > > WRT to this particular case, linksys web tells me the box is Linux based > (http://www.linksys.com/support/gpl.asp) in which case chances are high > the box is symmetric all the times. I agree it would be good to verify your > list -- what a pity we just missed an opportunity at sipit. Definitely agree it would be good to verify all of this. It's really easy to make a mistake. I put the pcap from both the client and the server for this NAT at http://www.employees.org/~fluffy/ietf/wrt54g_client2.pcap http://www.employees.org/~fluffy/ietf/wrt54g_server2.pcap "public" ip of nat was 10.0.1.4 IP of stun server was 10.0.1.150 and 151 Client was at 192.168.1.100 Model linksys WRT54G Firmware 1.42.2 Firewall protection was at default (enable) and Block Anonymous Internet Requests was checked (default) _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sun Feb 22 02:47:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19431 for ; Sun, 22 Feb 2004 02:47:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuoKP-00059u-Pc for midcom-archive@odin.ietf.org; Sun, 22 Feb 2004 02:47:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1M7l5V0019828 for midcom-archive@odin.ietf.org; Sun, 22 Feb 2004 02:47:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuoKL-00058k-VT; Sun, 22 Feb 2004 02:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuoJh-00057p-KP for midcom@optimus.ietf.org; Sun, 22 Feb 2004 02:46:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19423 for ; Sun, 22 Feb 2004 02:46:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuoJd-0007Kf-00 for midcom@ietf.org; Sun, 22 Feb 2004 02:46:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuoIi-0007I1-00 for midcom@ietf.org; Sun, 22 Feb 2004 02:45:21 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1AuoI4-0007BQ-00 for midcom@ietf.org; Sun, 22 Feb 2004 02:44:40 -0500 Received: from mail5.microsoft.com ([157.54.6.156]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 21 Feb 2004 23:44:23 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Sat, 21 Feb 2004 23:44:10 -0800 Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 21 Feb 2004 23:44:09 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 21 Feb 2004 23:44:47 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 21 Feb 2004 23:44:15 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sat, 21 Feb 2004 23:44:09 -0800 Content-class: urn:content-classes:message Subject: RE: [midcom] Some extensions to STUN. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Date: Sat, 21 Feb 2004 23:41:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Message-ID: Thread-Topic: [midcom] Some extensions to STUN. Thread-Index: AcP47y2oM+XCuTFhTaCnnStS6lLOJAAKBKHU From: "Christian Huitema" To: "Cullen Jennings" , "Midcom" Cc: "Jonathan Rosenberg" X-OriginalArrivalTime: 22 Feb 2004 07:44:09.0585 (UTC) FILETIME=[A8126E10:01C3F917] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F917.889E0AC9" ------_=_NextPart_001_01C3F917.889E0AC9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > One is testing to see if they rewrite data inside the payload of a UDP > packet. NATs have been observed that rewrite the mapped address inside = the > stun packet. Multiple people have suggested a solution to this - an > extension that returned an encrypted (mostly likely with xor) form of = the > the mapped address with some predefined key would detect this. We did observe that behavior in some NATs during the testing of Teredo, = and incorporated an XOR protection in Teredo. I suggested to incorporate = the same fix in STUN, but I was overruled by my co-authors. =20 -- Christian Huitema ------_=_NextPart_001_01C3F917.889E0AC9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= [midcom] Some extensions to STUN.=0A= =0A= =0A=
=0A=
> One is = testing to see if =0A= they rewrite data inside the payload of a UDP
> packet. NATs have = been =0A= observed that rewrite the mapped address inside the
> stun packet. =0A= Multiple people have suggested a solution to this - an
> extension = that =0A= returned an encrypted (mostly likely with xor) form of the
> the = mapped =0A= address with some predefined key would detect this.
=0A=
We did observe that behavior in some NATs = during the =0A= testing of Teredo, and incorporated an XOR protection in Teredo. I = suggested to =0A= incorporate the same fix in STUN, but I was overruled by my =0A= co-authors.
=0A=
 
=0A=
-- Christian Huitema
=0A= =0A= =0A= ------_=_NextPart_001_01C3F917.889E0AC9-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sun Feb 22 05:40:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23166 for ; Sun, 22 Feb 2004 05:40:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aur1v-00086w-5m for midcom-archive@odin.ietf.org; Sun, 22 Feb 2004 05:40:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1MAeAnb031146 for midcom-archive@odin.ietf.org; Sun, 22 Feb 2004 05:40:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aur1o-00085o-5L; Sun, 22 Feb 2004 05:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aur1G-00084b-NB for midcom@optimus.ietf.org; Sun, 22 Feb 2004 05:39:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23124 for ; Sun, 22 Feb 2004 05:39:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aur1D-0000MZ-00 for midcom@ietf.org; Sun, 22 Feb 2004 05:39:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aur0F-0000JS-00 for midcom@ietf.org; Sun, 22 Feb 2004 05:38:27 -0500 Received: from natsmtp01.rzone.de ([81.169.145.166]) by ietf-mx with esmtp (Exim 4.12) id 1Auqzz-0000G8-00 for midcom@ietf.org; Sun, 22 Feb 2004 05:38:12 -0500 Received: from sip (pD9E10250.dip.t-dialin.net [217.225.2.80]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i1MAc9H0018838; Sun, 22 Feb 2004 11:38:09 +0100 (MET) From: "Christian Stredicke" To: "'Midcom'" Cc: "'Jonathan Rosenberg'" Date: Sun, 22 Feb 2004 11:38:15 +0100 Message-ID: <017701c3f92f$fa7cfc20$2f00a8c0@sip> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,SUBJ_ALL_CAPS autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [midcom] TURN NONCE Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable We are trying to understand the Shared Secret Request server behavior. = =A7 7.1 (http://www.ietf.org/internet-drafts/draft-rosenberg-midcom-turn-04.txt) says that the server must return a NONCE, but I can't find the = definition of the NONCE attribute. Is it simply missing? What code should be used (0x0014)? Christian _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sun Feb 22 10:41:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29878 for ; Sun, 22 Feb 2004 10:41:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Auvj6-0003XV-AQ for midcom-archive@odin.ietf.org; Sun, 22 Feb 2004 10:41:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1MFf40o013581 for midcom-archive@odin.ietf.org; Sun, 22 Feb 2004 10:41:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Auvj2-0003WT-Sm; Sun, 22 Feb 2004 10:41:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Auvij-0003WC-Bx for midcom@optimus.ietf.org; Sun, 22 Feb 2004 10:40:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29853 for ; Sun, 22 Feb 2004 10:40:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Auvig-00003X-00 for midcom@ietf.org; Sun, 22 Feb 2004 10:40:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Auvhv-0007nB-00 for midcom@ietf.org; Sun, 22 Feb 2004 10:39:51 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AuvhM-0007gf-00 for midcom@ietf.org; Sun, 22 Feb 2004 10:39:16 -0500 Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i1MFctNr007827; Sun, 22 Feb 2004 10:38:56 -0500 (EST) Message-ID: <4038CCFE.506@dynamicsoft.com> Date: Sun, 22 Feb 2004 10:38:38 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Stredicke CC: "'Midcom'" References: <017701c3f92f$fa7cfc20$2f00a8c0@sip> In-Reply-To: <017701c3f92f$fa7cfc20$2f00a8c0@sip> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.dynamicsoft.com id i1MFctNr007827 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [midcom] Re: TURN NONCE Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Good catch, Christian. Yes, it is missing. I've added it in, assigning=20 it as 0x0014 as you suggest. Its format is a series of qdtext or quoted=20 pair; that is, the same exact grammar you'd find between the quotes if=20 the nonce occured in a SIP message. Thanks, Jonathan R. Christian Stredicke wrote: > We are trying to understand the Shared Secret Request server behavior. = =A7 7.1 > (http://www.ietf.org/internet-drafts/draft-rosenberg-midcom-turn-04.txt= ) > says that the server must return a NONCE, but I can't find the definiti= on of > the NONCE attribute. >=20 > Is it simply missing? What code should be used (0x0014)? >=20 > Christian >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Feb 24 10:58:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27342 for ; Tue, 24 Feb 2004 10:58:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avewi-0000uq-3t for midcom-archive@odin.ietf.org; Tue, 24 Feb 2004 10:58:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OFw8d2003519 for midcom-archive@odin.ietf.org; Tue, 24 Feb 2004 10:58:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avewb-0000sm-8F; Tue, 24 Feb 2004 10:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avevx-0000rI-Ex for midcom@optimus.ietf.org; Tue, 24 Feb 2004 10:57:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27265 for ; Tue, 24 Feb 2004 10:57:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avevu-0003nm-00 for midcom@ietf.org; Tue, 24 Feb 2004 10:57:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aveux-0003hV-00 for midcom@ietf.org; Tue, 24 Feb 2004 10:56:21 -0500 Received: from web40411.mail.yahoo.com ([66.218.78.108]) by ietf-mx with smtp (Exim 4.12) id 1AveuV-0003Z7-00 for midcom@ietf.org; Tue, 24 Feb 2004 10:55:51 -0500 Message-ID: <20040224155519.79897.qmail@web40411.mail.yahoo.com> Received: from [24.5.81.161] by web40411.mail.yahoo.com via HTTP; Tue, 24 Feb 2004 07:55:19 PST Date: Tue, 24 Feb 2004 07:55:19 -0800 (PST) From: Pyda Srisuresh Subject: Re: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt] To: Cullen Jennings , Bryan Ford , Midcom In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Cullen, Thank you for the response. Please see my comments inline. regards, suresh --- Cullen Jennings wrote: > > Whole bunch inline - thanks for the comments > > On 2/15/04 4:56 PM, "Pyda Srisuresh" wrote: > > > Cullen, > > > > Interesting compilation of results. Thank you. A few comments below. > > > > 1. Primary & Secondary columns in the draft being different - This strikes > me > > as wierd. Would appreciate if you can shed some light on the test used to > > categorize it thus. If the tests did indeed correctly categrorize a box as > > being different between primary & secondary port users - Does someone have > a > > clue as to why a vendor might have chosen to do this intentionally? (or) is > it > > likely a unintended bug in the product? > > I tracked down one programmer who was the guy who implemented this in one > product with this same question. It was unintentional. > > It was intentional to try to preserve the port, it's more likely to make > things work and keeps port numbers the same for network snifters. I'm not > sure I fully buy the argument that you try and preserver ports but I at > least can see the argument. Clearly you can't always use the same port > (well ignoring group D for now :-). This one set of code ended up with two > different logic flow depending on if the port was already in use or not. > Since the implementer was unaware that symmetric vs. port restricted might > make a difference at the time the code was written, they did not worry that > the behavior was different. Actually it was somewhat a surprise to the > implementer that the behavior was different. > > I suspect that in all the cases where the behavior changed, it was not an > intention feature of the product but just an artifact of how the code ended > up. > Interesting. Thank you for sharing the insight. I suspect, it may be similarly the case with others as well. > > > > Take the case of a Primary being port-restricted and secondary being > symmetric > > - Is the primary truely tested for port-restricted NAT criteria with > multiple > > outgoing and incoming sessions? I..e, Did the same primary-port end-point > > initiate multiple outgoing connections; And, even as some of the outgoing > > connections have aged out, the permitted incoming connections are > restricted > > to > > only those coming from the (ExtAddr, ExtPort) tuples to which there were > > outgoing sessions previously? Likewise, Was a secondary port user unable to > > initiate multiple outgoing sessions using the same port bind? > > > > In case, the test was performed using a single session on primary port > user, I > > believe, the box may as well have been a "Symmetric NAT" all across > (primary > > as > > well as secondary port users). > > The test was done by using a client that two IP addresses ( call the address > A and B) on a single NIC. First stun was run from address A, and a fixed > port (9000) was used as the port that the client sent the stun tests from. > This takes a second or so. Right after that, the STUN tests are run from > port 9000 on IP address B. > > On NATs that try to preserve ports, the first packet from A:9000 gets port > 9000 on the public side of the NAT. When the packet comes from B, it wants > to use 9000 but that port is already in use by A so it allocates some other > port. > I still believe, there might be an error in test characterization. A port-restricted cone-NAT is a symmetric NAT, when there is a single outgoing session initiated from the client. Unless there are a minimum of two outgoing sessions from the same (A, 9000) to two different (STUN-server address, port) pair and both outgoing sessions use the same Port-translation, a NAT device shouldnt be characterized as "port-restricted cone-NAT". Interestignly, all rows characterized as primary to be port-restricted and secondary to be symmetric, also have the port preservation enabled (wherever port preservation column is filled). Dont know what to make of this. Could that somehow have also contributed to incorrect characterization? > I believe you would get the same results if you had run two STUN tests at > the same time from two different clients running on two different PC's > behind the same NAT and both STUN clients sending their packets from the > same port number. Agreed. > > The bad news about this test is that there is no way to know what type of > NAT you are behind if all you have is a single IP address. > > > > > Likewise, take the case of primary being port-restricted and secondary > being > > full-cone. Depending upon how the test was performed, this may very well > have > > been "Full cone" for both primary and secondary port users. > > > > 2. Group-D/BAD port-binding sounds buggy to me. Why would a vendor choose > to > > do > > this intentionally? I.e., hope this is the right thing to do most of the > time? > > > > Uh, yah, I would think of this is a bug too. Some people of course would > describe all NAT's as a serious bug in an IP router. I was goofing around > with running applications from two PC's at the same time that were behind > these NATs. Ironically, the robustness of the retransmission mechanism I the > the IP protocols caused these to work better than I thought they would. One > PC would get the response it wanted, plus some garbage meant for the other > PC, then the other PC would retransmit and cause some result to be resent > that was meant for it. The robustness for the packet retransmission schemes > caused stuff to work. I don't mean to encourage anyone to use this approach > - I think it is a bad approach - it did not work well - it just worked > better than I thought it would. > > > 3. Port Restricted Cone NATs & Address restricted Cone NATs > > > > Below is my understanding of the operational behavior of restricted Cone > NATs. > > Essentially, I believe, both restricted Cone NATs are variations of > Full-Cone > > NAT, with additional firewall restrictions on the permitted incoming > > connections. > > > > I believe, the reverse of the outgoing NAT sessions are retained as > firewall > > packet rules to restrict what is allowed for incoming sessions. The > > restriction > > may be one of (External address) or (External address, external port) > > depending > > upon whether the device is Address restricted or Port restricted. > > Yes > > > > > Now, the questions on their operational behavior. > > > > Are the restrictions valid only so long as the port-BIND is active? I.e., > even > > as an outgoign NAT session ages out with idle time, the restricted > Cone-NATs > > will preserve the firewall rules in the reverse direction, so long as the > > port-BIND is alive, Right? Once the port-BIND is aged out, the associated > > firewall rules will disappear, right? > > Sounds like a good guess - I did not the aging and timing stuff. Most things > seemed over 30 seconds and less than or equal to 7200 seconds. I'd like to > do more experiments to learn a bit more about what types of things reset the > timers (outgoing packets, incoming, either, etc) > The problem is RFC 3489 definitions for NAPT varieties does not talk about the relation of NAT-sessions, and port bindings to Max-idletime. Below is another way NAPT variations could have been implemented without the aid of firewall. A Port-restricted Cone NAT could have been implemented with multiple NAT-sessions using the same port-bind (true NAPT implementation). An address-restricted Cone NAT could have been implemented same as above, except that the UDP NAT-sessions use ANY match on dest-port. A full cone NAT could also have been implemented with UDP NAT-sessions using ANY match on dest-address and ANY match on dest_port (or) simply making the port-BIND unidirectional and aging out the port-bind based on max-idletime. Unlike the above, a symmetric NAT does not maintain port bindings and each NAT-session goes through different port translation. > > > > 4. Several enterrises use SonicWall as their NAT/firewall. Any insight on > this > > from folks out there? > > I'm going to get around to testing some of the enterprise stuff some time. I > seem to recall one of the p2p authors had a more than casual understanding > of things like SonicWall. Any tests you recommend that we should look at > with enterprise systems? I want to tests that will detect anything that is > going to give me a nasty surprise when I try to deploy RTP over it. > > > > > 5. Lastly, I agree with the recommendations on the draft - Group-A type of > > NATs, which are Full-Cone NATs, and support hair-pin connectivity, with or > > without port-preservation. FWIW, the draft below > > (draft-ford-midcom-p2p-01.txt) > > also recommends the same as being P2P friendly. > > > > Cool - I've been meaning to find the time to properly understand and sync up > with you, Bryan, and Dan on the p2p draft. I've just been running out of > time but I like what it is trying to accomplish. > Thanks. > > regards, > > suresh > > regards, suresh > > --- Bryan Ford wrote: > >> On Friday 13 February 2004 08:48 am, Jiri Kuthan wrote: > >>> A way the IETF can help is to collect recommendations for NATs. There was > >>> such an effort long time ago > >>> > (http://www.iptel.org/ietf/firewall/nat/draft-ietf-mmusic-natreq4udp-00.txt > >>> ), I maintain a very similar list as well (don't be silly, keep NAT > bindings > >>> for a while, allow hairpinning, try to preserve port numbers, try to use > >>> stateless binding allocation algorithms). > >> > >> FYI, Pyda Srisuresh, Dan Kegel and I have for a while been working on a > >> document whose sole purpose is to collect precisely these things - general > >> recommendations for NATs, and general (protocol-independent) > recommendations > >> for applications trying to traverse NATs. It's already gone through a few > >> versions; the latest one recently came back from first review by the IESG, > >> and we're hoping to have another, near-final update before long. The most > >> recent version is available here: > >> > >> http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt > >> > >> Please let me know if you find inaccuracies or have other > comments/additions. > >> > >> Thanks! > >> > >> Bryan > >> > >> > >> _______________________________________________ > >> midcom mailing list > >> midcom@ietf.org > >> https://www1.ietf.org/mailman/listinfo/midcom > > > > > > ===== > > > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > > > ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Feb 26 19:23:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18434 for ; Thu, 26 Feb 2004 19:23:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwVmR-0007xS-WF for midcom-archive@odin.ietf.org; Thu, 26 Feb 2004 19:23:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R0N3MO030566 for midcom-archive@odin.ietf.org; Thu, 26 Feb 2004 19:23:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwVmP-0007wc-AN; Thu, 26 Feb 2004 19:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwVmI-0007tm-Nj for midcom@optimus.ietf.org; Thu, 26 Feb 2004 19:22:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18425 for ; Thu, 26 Feb 2004 19:22:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwVmH-00022A-00 for midcom@ietf.org; Thu, 26 Feb 2004 19:22:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwVlO-0001xd-00 for midcom@ietf.org; Thu, 26 Feb 2004 19:21:58 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AwVkh-0001nz-00 for midcom@ietf.org; Thu, 26 Feb 2004 19:21:15 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 26 Feb 2004 16:31:20 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1R0KhuA002702; Thu, 26 Feb 2004 16:20:44 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQR57528; Thu, 26 Feb 2004 16:20:37 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , Cullen Jennings From: Rohan Mahy Date: Thu, 26 Feb 2004 16:21:18 -0800 To: Midcom (E-mail) X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [midcom] snapshot of STUN test results every few years Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I think it would be very useful to publish a snapshot of "the state of the NAT" every few years. Publishing a snapshot in time of Cullen's document possibly with some NATs from a few other places (Europe, Japan, Korea, Australia, etc..) would allow us to look back in a few years and measure if we've made progress back towards and end-to-end Internet. thanks, -rohan _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Feb 26 19:24:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18460 for ; Thu, 26 Feb 2004 19:24:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwVnN-000870-C6 for midcom-archive@odin.ietf.org; Thu, 26 Feb 2004 19:24:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R0O1wB031109 for midcom-archive@odin.ietf.org; Thu, 26 Feb 2004 19:24:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwVnN-00085P-0l; Thu, 26 Feb 2004 19:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwVnE-00084a-Dt for midcom@optimus.ietf.org; Thu, 26 Feb 2004 19:23:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18452 for ; Thu, 26 Feb 2004 19:23:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwVnC-00026j-00 for midcom@ietf.org; Thu, 26 Feb 2004 19:23:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwVmI-00022Q-00 for midcom@ietf.org; Thu, 26 Feb 2004 19:22:55 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AwVlR-0001sq-00 for midcom@ietf.org; Thu, 26 Feb 2004 19:22:02 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1R0LT1m014394; Thu, 26 Feb 2004 16:21:30 -0800 (PST) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQR57597; Thu, 26 Feb 2004 16:21:28 -0800 (PST) In-Reply-To: <20040216005600.88889.qmail@web40403.mail.yahoo.com> References: <20040216005600.88889.qmail@web40403.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Bryan Ford , fluffy@cisco.com, Rohan Mahy , Midcom From: Rohan Mahy Subject: Re: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt] Date: Thu, 26 Feb 2004 16:22:10 -0800 To: Pyda Srisuresh X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Feb 15, 2004, at 4:56 PM, Pyda Srisuresh wrote: > Cullen, > > Interesting compilation of results. Thank you. A few comments below. > > 1. Primary & Secondary columns in the draft being different - This > strikes me > as wierd. Would appreciate if you can shed some light on the test used > to > categorize it thus. If the tests did indeed correctly categrorize a > box as > being different between primary & secondary port users - Does someone > have a > clue as to why a vendor might have chosen to do this intentionally? > (or) is it > likely a unintended bug in the product? who knows the motivation? I suspect its a bug. > Take the case of a Primary being port-restricted and secondary being > symmetric > - Is the primary truely tested for port-restricted NAT criteria with > multiple > outgoing and incoming sessions? I..e, Did the same primary-port > end-point > initiate multiple outgoing connections; yes and yes. the test client has two IP addresses from which it initiates several requests in some cases with the same source port. > And, even as some of the outgoing > connections have aged out, the permitted incoming connections are > restricted to > only those coming from the (ExtAddr, ExtPort) tuples to which there > were > outgoing sessions previously? Likewise, Was a secondary port user > unable to > initiate multiple outgoing sessions using the same port bind? > > In case, the test was performed using a single session on primary port > user, I > believe, the box may as well have been a "Symmetric NAT" all across > (primary as > well as secondary port users). > > Likewise, take the case of primary being port-restricted and secondary > being > full-cone. Depending upon how the test was performed, this may very > well have > been "Full cone" for both primary and secondary port users. > > 2. Group-D/BAD port-binding sounds buggy to me. Why would a vendor > choose to do > this intentionally? I.e., hope this is the right thing to do most of > the time? Exactly! thanks, -rohan _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom