From behave-bounces@ietf.org Fri Feb 1 02:54:29 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 534BB3A6911; Fri, 1 Feb 2008 02:54:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clFZ2vJP+8Uw; Fri, 1 Feb 2008 02:54:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E9F03A68B5; Fri, 1 Feb 2008 02:54:28 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 197363A68B5 for ; Fri, 1 Feb 2008 02:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzytvYPM9Jh8 for ; Fri, 1 Feb 2008 02:54:25 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id 226DA3A6910 for ; Fri, 1 Feb 2008 02:54:24 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 77F531C00F8; Fri, 1 Feb 2008 11:55:58 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 731E11C00F4; Fri, 1 Feb 2008 11:55:58 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 6F74358EB6A; Fri, 1 Feb 2008 11:55:58 +0100 (CET) Date: Fri, 1 Feb 2008 11:55:58 +0100 From: Stephane Bortzmeyer To: Philip Matthews Message-ID: <20080201105558.GB15412@nic.fr> References: <08A6A2ED-2BF5-46D7-B6D1-8785E4958A61@magma.ca> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <08A6A2ED-2BF5-46D7-B6D1-8785E4958A61@magma.ca> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Behave WG Subject: Re: [BEHAVE] Summary of TURN open-issues call on Monday, 28 Jan 2008 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Mon, Jan 28, 2008 at 05:06:11PM -0500, Philip Matthews wrote a message of 125 lines which said: > *) Preserving bits in the IP header. When relaying packets, how > should various IP header bits be set? My personal opinion, based on the tests I ran on various machines, is that: TURN is a "last resort" solution, anyway, for the case where users are stuck behind badly behaving NATs. We all know it is not the best solution but its main feature is that it always works, whatever the behaviour of the NATs. So, having more things (such as preservation of IP options) is nice but should not be mandatory, it is most important to have TURN servers available than to have them preserve every IP option. So, I favor something like "TURN servers MAY preserve the options set in the IP header". Other things to keep in mind (and that's why i suggest MAY and not SHOULD): * being a TURN server will not be fun, it takes a lot of resources. We should not ask them more. * IP options such as DSCP are very rarely used, anyway. * we can always design later an extension which will ask for strict preservation of IP options. _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From mailman-bounces@core3.amsl.com Fri Feb 1 05:26:00 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A7A428EAB1 for ; Fri, 1 Feb 2008 05:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4af7qUJx+tUb for ; Fri, 1 Feb 2008 05:25:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B0B329438B for ; Fri, 1 Feb 2008 05:05:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: behave-archive@optimus.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:02:13 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/behave/behave-archive%40optimus.ietf.org From mailman-bounces@core3.amsl.com Fri Feb 1 05:26:50 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 178BC2943C9 for ; Fri, 1 Feb 2008 05:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eV-Z4FsLg72e for ; Fri, 1 Feb 2008 05:25:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 697862943D5 for ; Fri, 1 Feb 2008 05:05:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: behave-archive@optimus.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:02:13 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/behave/behave-archive%40optimus.ietf.org From behave-bounces@ietf.org Fri Feb 1 07:27:21 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E97928C238; Fri, 1 Feb 2008 07:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.554 X-Spam-Level: X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_20=-0.74] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15UAYasW04Ic; Fri, 1 Feb 2008 07:27:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FAAD3A6A9C; Fri, 1 Feb 2008 07:21:19 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 011803A6A96 for ; Fri, 1 Feb 2008 07:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rwxh3eetZ1dw for ; Fri, 1 Feb 2008 07:21:14 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id CD8DD28C77F for ; Fri, 1 Feb 2008 06:58:42 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JVK00EIOF0G2L@usaga01-in.huawei.com> for behave@ietf.org; Fri, 01 Feb 2008 07:00:16 -0800 (PST) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JVK00D6ZF0DMY@usaga01-in.huawei.com> for behave@ietf.org; Fri, 01 Feb 2008 07:00:16 -0800 (PST) Date: Fri, 01 Feb 2008 08:59:36 -0600 From: Spencer Dawkins To: Behave WG Message-id: <218901c864e3$1039db00$6401a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <08A6A2ED-2BF5-46D7-B6D1-8785E4958A61@magma.ca> <20080201105558.GB15412@nic.fr> Subject: Re: [BEHAVE] Summary of TURN open-issues call on Monday, 28 Jan 2008 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org From: "Stephane Bortzmeyer" > On Mon, Jan 28, 2008 at 05:06:11PM -0500, > Philip Matthews wrote > a message of 125 lines which said: > >> *) Preserving bits in the IP header. When relaying packets, how >> should various IP header bits be set? > > My personal opinion, based on the tests I ran on various machines, is > that: > > TURN is a "last resort" solution, anyway, for the case where users are > stuck behind badly behaving NATs. We all know it is not the best > solution but its main feature is that it always works, whatever the > behaviour of the NATs. So, having more things (such as preservation of > IP options) is nice but should not be mandatory, it is most important > to have TURN servers available than to have them preserve every IP > option. I guess a related question is whether TURN servers would refuse clients if the client asks for IP option preservation and the TURN server doesn't do that - I'm guessing "no", but does anyone think the answer is "yes"? Spencer _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 1 10:44:00 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECD3728C5A7; Fri, 1 Feb 2008 10:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoI-8qjZDWif; Fri, 1 Feb 2008 10:44:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B6AE28C66F; Fri, 1 Feb 2008 10:41:58 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D22528C66C for ; Fri, 1 Feb 2008 10:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1asnqHNi0oN for ; Fri, 1 Feb 2008 10:41:56 -0800 (PST) Received: from mail-07.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id D228628C5AE for ; Fri, 1 Feb 2008 10:40:18 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JL0ph-0004Oq-2y; Fri, 01 Feb 2008 13:41:50 -0500 In-Reply-To: <20080130100029.GA11872@sources.org> References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <200801030949.41979.remi.denis-courmont@nokia.com> <914FB0C9-1F63-4EBB-BADE-26F5506619A7@magma.ca> <200801081223.17053.remi.denis-courmont@nokia.com> <20080129210631.GA965@sources.org> <20080130100029.GA11872@sources.org> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <143C83F9-F2EF-4B65-BD4C-99DDDA1586A9@magma.ca> From: Philip Matthews Date: Fri, 1 Feb 2008 13:41:36 -0500 To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] Cc: Behave WG Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > On Fri, 1-Feb-08, at 05:55 , Stephane Bortzmeyer wrote: >> On Mon, Jan 28, 2008 at 05:06:11PM -0500, >> Philip Matthews wrote >> a message of 125 lines which said: >> >>> *) Preserving bits in the IP header. When relaying packets, how >>> should various IP header bits be set? >> >> My personal opinion, based on the tests I ran on various machines, is >> that: >> >> TURN is a "last resort" solution, anyway, for the case where users >> are >> stuck behind badly behaving NATs. We all know it is not the best >> solution but its main feature is that it always works, whatever the >> behaviour of the NATs. So, having more things (such as >> preservation of >> IP options) is nice but should not be mandatory, it is most important >> to have TURN servers available than to have them preserve every IP >> option. >> >> So, I favor something like "TURN servers MAY preserve the options set >> in the IP header". >> What if we come up with something that can be fairly easily done by a unprivileged user-land process? Do you still think MAY is important? - Philip _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Feb 3 10:43:17 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03B2E3A6CD8; Sun, 3 Feb 2008 10:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.291 X-Spam-Level: X-Spam-Status: No, score=-6.291 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I25e87PJcsFL; Sun, 3 Feb 2008 10:43:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F6733A6CE7; Sun, 3 Feb 2008 10:43:16 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA4EB3A6CE7 for ; Sun, 3 Feb 2008 10:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t03G0+AQGLQU for ; Sun, 3 Feb 2008 10:43:14 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 360983A6CD8 for ; Sun, 3 Feb 2008 10:43:14 -0800 (PST) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 03 Feb 2008 10:44:49 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m13Iinpw011707 for ; Sun, 3 Feb 2008 10:44:49 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m13Iinwh025674 for ; Sun, 3 Feb 2008 18:44:49 GMT From: "Dan Wing" To: "'Behave WG'" Date: Sun, 3 Feb 2008 10:44:49 -0800 Message-ID: <361101c86694$db2001c0$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchmlNrHvSSAUZkxSue4lxl9Djr0pw== Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [BEHAVE] new and adjusted milestones X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org BEHAVE has a three new milestones: * DCCP, July 2008 This is a BCP document describing NAT operation for DCCP. At this time, the most likely candidate document appears to be draft-denis-behave-nat-dccp-00. * SCTP, December 2008 This is a BCP document describing NAT operation for SCTP, including SCTP multi-homing across NATs. At this time, the most likely candidate document appears to be draft-stewart-behave-sctpnat-03; discussion of SCTP multihoming is in draft-xie-behave-sctp-nat-cons-03. * STUN test vectors, January 2008 This is the WG-adopted document draft-ietf-behave-stun-test-vectors-00. the dates for TURN, TURN-v6, and TURN-TCP were slipped. (TURN is actually missing from the milestones right now; I am getting that corrected). -d _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 4 08:18:04 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11A193A7019; Mon, 4 Feb 2008 08:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.571 X-Spam-Level: X-Spam-Status: No, score=-4.571 tagged_above=-999 required=5 tests=[AWL=2.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aqhH6mzcwbC; Mon, 4 Feb 2008 08:18:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 040573A6FD2; Mon, 4 Feb 2008 08:18:01 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9D993A6FB4 for ; Mon, 4 Feb 2008 08:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-MMIE4Nd5-n for ; Mon, 4 Feb 2008 08:17:58 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D97B43A6FF3 for ; Mon, 4 Feb 2008 08:16:11 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 04 Feb 2008 08:17:46 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m14GHkev027815; Mon, 4 Feb 2008 08:17:46 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id m14GHjCv027452; Mon, 4 Feb 2008 16:17:45 GMT From: "Dan Wing" To: "'Behave WG'" Date: Mon, 4 Feb 2008 08:17:44 -0800 Message-ID: <0a0501c86749$79f741a0$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchnSXmHGdVvjqwGSS60nlCnI9pl9A== Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [BEHAVE] WGLC: draft-ietf-behave-stun-test-vectors-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org I am starting a two-week working group last call on draft-ietf-behave-stun-test-vectors-00.txt, ending February 18: http://tools.ietf.org/html/draft-ietf-behave-stun-test-vectors-00 Abstract: This document includes test vectors for the MESSAGE-INTEGRITY and FINGERPRINT attributes of the STUN protocol. This document is being published as an Informational document. -d _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Feb 5 15:22:06 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F3803A6B2D; Tue, 5 Feb 2008 15:22:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REFGKVl1UGf4; Tue, 5 Feb 2008 15:22:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 011383A6CF6; Tue, 5 Feb 2008 15:02:20 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00E813A6CC1 for ; Tue, 5 Feb 2008 15:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9-ORQNKdMxi for ; Tue, 5 Feb 2008 15:02:18 -0800 (PST) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.224]) by core3.amsl.com (Postfix) with ESMTP id 35EB03A7610 for ; Tue, 5 Feb 2008 14:36:26 -0800 (PST) Received: by wr-out-0506.google.com with SMTP id 50so2949651wri.25 for ; Tue, 05 Feb 2008 14:37:58 -0800 (PST) Received: by 10.142.242.8 with SMTP id p8mr4791115wfh.142.1202251077007; Tue, 05 Feb 2008 14:37:57 -0800 (PST) Received: by 10.142.52.6 with HTTP; Tue, 5 Feb 2008 14:37:56 -0800 (PST) Message-ID: Date: Tue, 5 Feb 2008 14:37:56 -0800 From: "Derek MacDonald" To: "Philip Matthews" In-Reply-To: <612E2627-E9BA-494A-9C92-C59C886CEDC4@magma.ca> MIME-Version: 1.0 Content-Disposition: inline References: <4759CD14.10208@cisco.com> <47630B03.3050708@cisco.com> <200801150931.19631.remi.denis-courmont@nokia.com> <36970DB3-7EA2-4807-9659-FA005B303C94@cisco.com> <4790D31B.5060501@ericsson.com> <612E2627-E9BA-494A-9C92-C59C886CEDC4@magma.ca> X-Google-Sender-Auth: d67eb555155ff450 Cc: Behave WG Subject: Re: [BEHAVE] TURN Issue #5: Port Range X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org I really don't think we need *any* text about the fact that ports the TURN server uses can't be used by another app. It's so obvious that people will think the txt must have some deeper meaning and waste time trying to find that meaning. -Derek On Jan 18, 2008 9:05 AM, Philip Matthews wrote: > A number of people have now told me, either publicly or privately, > that they would be happy with the text if I simply removed the > discussion on firewalls. So here is my revised text: > > The server SHOULD only allocate ports from the range 49152 - 65535 > (the Dynamic and/or Private Port range [Port-Numbers]), unless the > TURN server application knows, through some means not specified > here, > that other applications running on the same host as the TURN server > application will not be impacted by allocating ports outside this > range. This condition can often be satisfied by running the TURN > server application on a dedicated machine and/or by arranging that > any other applications on the machine allocate ports before the TURN > server application starts. In any case, the TURN server SHOULD NOT > allocate ports in the range 0 - 1023 (the Well-Known Port range) to > discourage clients from using TURN to run standard services. > > Comments? > > - Philip > > > _______________________________________________ > > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From "Philip Matthews" Tue Feb 5 04:49:41 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-dwing_2007_a (2007-08-08) on dwing-wxp01.cisco.com X-Spam-Level: X-Spam-Bayes-Spam: 0.987-2--x12, 0.987-2--x90 X-Spam-Status: No, Score=-103.1/5.0, AWL=-0.611,BAYES_00=-2.599, LOCAL_ALWAYSTRUE=0.01,RDNS_NONE=0.1,USER_IN_WHITELIST=-100, autolearn=no X-Spam-RBL: [127.0.0.11] X-Spam-UnTrusted: [ ip=64.170.98.86 rdns= helo=core3.amsl.com by=sj-inbound-f.cisco.com ident= envfrom= intl=0 id= auth= msa=0 ] [ ip=127.0.0.1 rdns=localhost helo=localhost by=core3.amsl.com ident= envfrom= intl=0 id=80AD03A85C5 auth= msa=0 ] [ ip=127.0.0.1 rdns= helo=core3.amsl.com by=localhost ident= envfrom= intl=0 id=QphS36dHj8ll auth= msa=0 ] [ ip=127.0.0.1 rdns=localhost helo=core3.amsl.com by=mail.ietf.org ident= envfrom= intl=0 id=410A23A9F1E auth= msa=0 ] [ ip=216.254.141.173 rdns=mail6.primus.ca helo=mail-05.primus.ca by=mail.ietf.org ident= envfrom= intl=0 id=670D83AA0F3 auth= msa=0 ] [ ip=216.13.42.68 rdns= helo=!10.10.80.124! by=mail-05.primus.ca ident= envfrom=philip_matthews@magma.ca intl=0 id=1JMNEE-00077U-15 auth=esmtpa msa=0 ] X-Spam-Bayes-Summ: summary=Tokens: new, 299; hammy, 149; neutral, 358; spammy, 2. Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-22a.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 13:28:01 -0800 Received: from sj-iport-2.cisco.com ([171.71.176.71]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 13:28:00 -0800 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 05 Feb 2008 13:27:59 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m15LRx1a017582; Tue, 5 Feb 2008 13:27:59 -0800 Received: from sj-inbound-f.cisco.com (sj-inbound-f.cisco.com [128.107.234.207]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id m15LRpje012859; Tue, 5 Feb 2008 21:27:59 GMT X-from-outside-Cisco: 64.170.98.86 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAENjqEdAqmJWnmdsb2JhbACBWI5UAQEBAQEGBAYHChiBFZtwAQ X-IronPort-AV: E=Sophos;i="4.25,309,1199692800"; d="scan'208";a="16130721" Received: from core3.amsl.com ([64.170.98.86]) by sj-inbound-f.cisco.com with ESMTP; 05 Feb 2008 13:27:59 -0800 Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80AD03A85C5; Tue, 5 Feb 2008 13:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QphS36dHj8ll; Tue, 5 Feb 2008 13:26:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by mail.ietf.org (Postfix) with ESMTP id 410A23A9F1E; Tue, 5 Feb 2008 11:44:39 -0800 (PST) X-Original-To: behave@ietf.org Delivered-To: behave@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 1B52D3A7E39; Tue, 5 Feb 2008 10:52:51 -0800 (PST) Received: from mail-05.primus.ca (mail6.primus.ca [216.254.141.173]) by mail.ietf.org (Postfix) with ESMTP id 670D83AA0F3 for ; Tue, 5 Feb 2008 04:48:12 -0800 (PST) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JMNEE-00077U-15; Tue, 05 Feb 2008 07:48:46 -0500 In-Reply-To: <0a0501c86749$79f741a0$c4f0200a@cisco.com> References: <0a0501c86749$79f741a0$c4f0200a@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <31516C20-EF51-40EC-B84B-5DC1555AC6B2@magma.ca> From: Philip Matthews Date: Tue, 5 Feb 2008 07:49:41 -0500 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: "'Behave WG'" Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-stun-test-vectors-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Authentication-Results: sj-dkim-2; header.From=philip_matthews@magma.ca; dkim=neutral Return-Path: behave-bounces@ietf.org X-OriginalArrivalTime: 05 Feb 2008 21:28:00.0196 (UTC) FILETIME=[FB821840:01C8683D] From "Rémi Denis-Courmont" Tue Feb 5 05:09:56 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-dwing_2007_a (2007-08-08) on dwing-wxp01.cisco.com X-Spam-Level: X-Spam-Bayes-Spam: 0.965-+--H*RT:128.107.234.204, 0.950-+--H*RU:sk:sj-inbo, 0.949-+--H*RT:sk:sj-inbo, 0.946-+--HX-Spam-Relays-Internal:128.107.234.204, 0.940-+--HAuthentication-Results:neutral X-Spam-Status: No, Score=-110.9/5.0, AWL=-9.768,BAYES_00=-2.599, LOCAL_ALWAYSTRUE=0.01,MIME_QP_LONG_LINE=1.396,RDNS_NONE=0.1, USER_IN_WHITELIST=-100, autolearn=no X-Spam-RBL: [64.170.98.32] X-Spam-UnTrusted: [ ip=64.170.98.86 rdns= helo=core3.amsl.com by=sj-inbound-a.cisco.com ident= envfrom= intl=0 id= auth= msa=0 ] [ ip=127.0.0.1 rdns=localhost helo=localhost by=core3.amsl.com ident= envfrom= intl=0 id=A09F63A737C auth= msa=0 ] [ ip=127.0.0.1 rdns= helo=core3.amsl.com by=localhost ident= envfrom= intl=0 id=Dn67hSNBLmF7 auth= msa=0 ] [ ip=127.0.0.1 rdns=localhost helo=core3.amsl.com by=mail.ietf.org ident= envfrom= intl=0 id=5F2643A93D6 auth= msa=0 ] [ ip=192.100.122.230 rdns=smtp.nokia.com helo=mgw-mx03.nokia.com by=mail.ietf.org ident= envfrom= intl=0 id=125C828C13A auth= msa=0 ] [ ip=172.21.143.143 rdns=esebh107.ntc.nokia.com helo=esebh107.NOE.Nokia.com by=mgw-mx03.nokia.com ident= envfrom= intl=0 id=m15D8s34001066 auth= msa=0 ] [ ip=172.21.138.183 rdns= helo=esebh102.NOE.Nokia.com by=esebh107.NOE.Nokia.com ident= envfrom= intl=0 id= auth= msa=0 ] [ ip=172.21.41.95 rdns= helo=esdhcp04195.research.nokia.com by=esebh102.NOE.Nokia.com ident= envfrom= intl=0 id= auth= msa=0 ] X-Spam-Bayes-Summ: summary=Tokens: new, 74; hammy, 137; neutral, 108; spammy, 14. Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-22a.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 14:45:29 -0800 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 14:45:29 -0800 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 05 Feb 2008 14:45:27 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m15MjQMj018423; Tue, 5 Feb 2008 14:45:26 -0800 Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m15MjIfh016367; Tue, 5 Feb 2008 22:45:26 GMT X-from-outside-Cisco: 64.170.98.86 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAL11qEdAqmJWnmdsb2JhbACQLgEBAQEBBgQGBwoYnUY X-IronPort-AV: E=Sophos;i="4.25,309,1199692800"; d="scan'208";a="20923177" Received: from core3.amsl.com ([64.170.98.86]) by sj-inbound-a.cisco.com with ESMTP; 05 Feb 2008 14:45:26 -0800 Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A09F63A737C; Tue, 5 Feb 2008 14:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dn67hSNBLmF7; Tue, 5 Feb 2008 14:26:31 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by mail.ietf.org (Postfix) with ESMTP id 5F2643A93D6; Tue, 5 Feb 2008 11:43:15 -0800 (PST) X-Original-To: behave@ietf.org Delivered-To: behave@mail.ietf.org Received: by mail.ietf.org (Postfix, from userid 51) id 465103A753D; Tue, 5 Feb 2008 10:37:50 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by mail.ietf.org (Postfix) with ESMTP id 125C828C13A for ; Tue, 5 Feb 2008 05:07:53 -0800 (PST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m15D8s34001066; Tue, 5 Feb 2008 15:09:24 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 15:09:20 +0200 Received: from esdhcp04195.research.nokia.com ([172.21.41.95]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 15:09:20 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Philip Matthews" Date: Tue, 5 Feb 2008 15:09:56 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <0a0501c86749$79f741a0$c4f0200a@cisco.com> <31516C20-EF51-40EC-B84B-5DC1555AC6B2@magma.ca> In-Reply-To: <31516C20-EF51-40EC-B84B-5DC1555AC6B2@magma.ca> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200802051509.56473.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 05 Feb 2008 13:09:20.0166 (UTC) FILETIME=[51C7D460:01C867F8] X-Nokia-AV: Clean Cc: "'Behave WG'" Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-stun-test-vectors-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Authentication-Results: sj-dkim-2; header.From=remi.denis-courmont@nokia.com; dkim=neutral Return-Path: behave-bounces@ietf.org Le Tuesday 05 February 2008 14:49:41 ext Philip Matthews, vous avez écrit : > > All included vectors are represented as a series of hexadecimal > > values in network byte order. Each pair of hexadecimal digits > > represents one byte. > > > > Messages follow the ICE Connectivity Checks use case of STUN, (see > > [I-D.ietf-mmusic-ice]). They include both FINGERPRINT and MESSAGE- > > INTEGRITY attributes. > > You might want to say a bit more about the implications of the statement > that these messages follow the ICE use case. Well - the reason why this document uses ICE connectivity checks is simply that I wanted packets with all of the following attributes: - MESSAGE-INTEGRITY to check SHA-1 summing, - FINGERPRINT to check CRC32 summing, - XOR-MAPPED-ADDRESS to check XOR'ing, - any text field with "undefined" padding (namely USERNAME). All four of these have actually proven to be buggy in some of the Work-In-Progress STUN stacks around here (including mine). Had STUN Binding Discovery *customarily* used all of these, I would have gone for it instead. I don't mind adding more verbose descriptions (as long as it does not screw up the schematics layout :P). Then again, I didn't intend this document to be of much use to someone who does not even know the STUN message and attribute header formats - so the question is, should it or should it not? -- Rémi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 6 07:28:26 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B0423A683D; Wed, 6 Feb 2008 07:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itTgFLLmshRZ; Wed, 6 Feb 2008 07:28:25 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21B9F3A6BD3; Wed, 6 Feb 2008 07:28:25 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D02B13A6CB1 for ; Wed, 6 Feb 2008 07:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zy4KgHxpS41S for ; Wed, 6 Feb 2008 07:28:23 -0800 (PST) Received: from mail-02.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id C69113A683D for ; Wed, 6 Feb 2008 07:28:22 -0800 (PST) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JMmDh-0007cT-14; Wed, 06 Feb 2008 10:29:53 -0500 In-Reply-To: References: <4759CD14.10208@cisco.com> <47630B03.3050708@cisco.com> <200801150931.19631.remi.denis-courmont@nokia.com> <36970DB3-7EA2-4807-9659-FA005B303C94@cisco.com> <4790D31B.5060501@ericsson.com> <612E2627-E9BA-494A-9C92-C59C886CEDC4@magma.ca> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <3884808C-9D4C-40BB-A177-B2B5BECA7F5C@magma.ca> From: Philip Matthews Date: Wed, 6 Feb 2008 10:30:00 -0500 To: Derek MacDonald X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: Behave WG Subject: Re: [BEHAVE] TURN Issue #5: Port Range X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Hi Derek: If you are really concerned, raise it on the call tomorrow. But we did discuss this on the last conference call and most people seemed happy with the text. And since the text is already in -06, I am reluctant to change it. - Philip On Tue, 5-Feb-08, at 17:37 , Derek MacDonald wrote: > I really don't think we need *any* text about the fact that ports the > TURN server uses can't be used by another app. It's so obvious that > people will think the txt must have some deeper meaning and waste time > trying to find that meaning. > > -Derek > > On Jan 18, 2008 9:05 AM, Philip Matthews > wrote: >> A number of people have now told me, either publicly or privately, >> that they would be happy with the text if I simply removed the >> discussion on firewalls. So here is my revised text: >> >> The server SHOULD only allocate ports from the range 49152 - >> 65535 >> (the Dynamic and/or Private Port range [Port-Numbers]), unless >> the >> TURN server application knows, through some means not specified >> here, >> that other applications running on the same host as the TURN >> server >> application will not be impacted by allocating ports outside this >> range. This condition can often be satisfied by running the TURN >> server application on a dedicated machine and/or by arranging >> that >> any other applications on the machine allocate ports before >> the TURN >> server application starts. In any case, the TURN server >> SHOULD NOT >> allocate ports in the range 0 - 1023 (the Well-Known Port >> range) to >> discourage clients from using TURN to run standard services. >> >> Comments? >> >> - Philip >> >> >> _______________________________________________ >> >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave >> > _______________________________________________ > Behave mailing list > Behave@ietf.org > http://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 6 13:07:54 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF5F13A708A; Wed, 6 Feb 2008 13:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62Xfd4pbzPcw; Wed, 6 Feb 2008 13:07:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 749693A6E66; Wed, 6 Feb 2008 13:07:53 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B48B3A6E66 for ; Wed, 6 Feb 2008 13:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bh0JE9ARzKkt for ; Wed, 6 Feb 2008 13:07:51 -0800 (PST) Received: from mail-08.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 739F13A6C9E for ; Wed, 6 Feb 2008 13:07:51 -0800 (PST) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-08.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JMrWE-0001Jo-2K; Wed, 06 Feb 2008 16:09:22 -0500 In-Reply-To: <47A8A54D.5040402@acm.org> References: <47A8A54D.5040402@acm.org> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Philip Matthews Date: Wed, 6 Feb 2008 16:09:26 -0500 To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: 'Behave WG' Subject: Re: [BEHAVE] DF bit in TURN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Marc: Many thanks for doing this investigation! As I see it, here are the relevant points in this discussion: * We don't know a way to read the DF bit on a received packet without using RAW sockets (which requires root privileges) * Requiring root privileges is undesirable for P2P apps, but might be acceptable for a stand-alone server * Always setting the DF bit will result in large UDP packets (e.g. SIP msgs) always getting dropped. * Forwarding packets at the IP layer (which Marc mentioned) also requires RAW sockets. So here is my new strawman proposal: * In normal operation, a TURN server does not set the DF bit when sending over UDP (either to the client or to the peer). * An application using TURN that wants to ensure that its packets are not fragmented must keep its packet size below 576 bytes. * A TURN server MAY choose to do IP layer forwarding on UDP-to-UDP connections; in this case, it should preserve the DF bit when forwarding. By not setting the DF bit, a TURN server is following the principle of "maximize the chances of getting the application data through" which is the whole point of TURN in the first place. An application on the client or the peer doing 4821 will not determine the Path MTU, but will determine the maximum UDP packet size that will be delivered to the remote destination; the resulting UDP datagram might get fragmented, but it will be delivered. The result may not be optimal, but TURN is not really optimal anyway. A TURN server that wants do provide a "high-quality" service may choose to do IP layer forwarding using RAW sockets. This would mean that 4821 would determine the actual Path MTU. Though complex to implement, I think it is do-able. I would be interested in hearing from those interested in this option, and of any attempts to implement it. Comments? - Philip On Tue, 5-Feb-08, at 13:05 , Marc Petit-Huguenin wrote: > To understand the problems with the bits to preserve in the IP header > when tunneling through TURN, I tried to implement something that > use the > DF bit. My idea was that two endpoints exchanging video over > RTP/UDP/IPv4 would certainly benefit of using RFC 1191 and RFC 4821 to > find the PMTU in each direction and use it to adjust the maximum > size of > the RTP packets that can be sent. I am assuming that both > endpoints are > using ICE, so they both contain a STUN client and a STUN server for > the > connectivity checks. It is then easy to implement PMTU discovery by > using something like a Echo transactions with the PADDING attribute[1] > as probes. > > From the point of view of the endpoint using TURN there is two cases, > PMTU discovery from this endpoint to the other endpoint, and PMTU > discovery from the other endpoint to this endpoint. > > It is assumed that both the TURN client and the TURN server know the > PMTU inside the tunnel in each other direction, i.e. for TCP or TLS it > would be something like 65535 minus various headers and for UDP it can > be discovered by the same algorithm than described above. > > The simplest case is PMTU discovery from the endpoint behind the TURN > tunnel to the other endpoint. The STUN client behind the TURN client > sends a probe, the TURN server relays it to the other endpoint (peer) > after setting the DF bit. If a router on the path between the TURN > server and the peer drops the packet because it would be fragmented, > then the RFC 4821 algorithm will work. If a router sends back an ICMP > Packet Too Big then it will be dropped by the TURN server, and the RFC > 4821 algorithm will also work. There can be two improvements that can > be done in the TURN protocol to help; firstly to add a way for the > TURN > client to set the value of the DF bit that will be used to forward the > packets to the peer and secondly to tunnel the ICMP packets > received by > the TURN server to the TURN client. > > Now a more difficult case is PMTU discovery from the other endpoint to > the endpoint behind the TURN tunnel. The TURN server will receive a > packet from the peer with the DF bit set, but a TURN server running in > userland cannot retrieve the value of this bit. If the transport > between the TURN server and the TURN client is TCP this is not a > problem, the tunnel PMTU been close to 65535 there is no reason to > send > an ICMP Packet Too Big or to drop the packet. But if the transport > used > is UDP, then the TURN server is supposed to send an ICMP Packet Too > Big > or to drop the packet if the DF bit is set, or to send it > fragmented to > the TURN client if the DF bit is not set. And this is the second > problem, there is no way in TURN to fragment the packet between the > TURN > server and the TURN client. It is certainly possible to extend > TURN to > do that, but it does not solve the problem that a userland application > cannot test the DF bit in a received packet. There is also, AFAIK, no > way to send an ICMP packet after receiving a UDP packet in > userland, but > this is less a problem, as simply dropping the packet would work with > RFC 4821. > > A simple alternative to this mess would be to tunnel IP packets over > TURN instead of UDP packets. This would solve the DF problem and also > the problems for the other IP header bits, but it left open the > problem > of TCP[2] between the TURN server and the peer (additionally to the > problem that the TURN server needs to be root). > > > [1] draft-ietf-behave-nat-behavior-discovery > [2] http://www.lemis.com/grog/Documentation/vj/lca06vj.pdf > > -- > Marc Petit-Huguenin [ ] > Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] > Work: marc@8x8.com [ ] > [ ] > > _______________________________________________ > Behave mailing list > Behave@ietf.org > http://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 6 14:20:34 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A9E43A7076; Wed, 6 Feb 2008 14:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.439 X-Spam-Level: X-Spam-Status: No, score=0.439 tagged_above=-999 required=5 tests=[AWL=0.934, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVlHVukqoBM3; Wed, 6 Feb 2008 14:20:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A1943A6DFA; Wed, 6 Feb 2008 14:20:33 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1F663A6E73 for ; Wed, 6 Feb 2008 14:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDkB9MU+ogx5 for ; Wed, 6 Feb 2008 14:20:32 -0800 (PST) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id D44B43A6D92 for ; Wed, 6 Feb 2008 14:20:31 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id AF2A95084E; Wed, 6 Feb 2008 14:23:45 -0800 (PST) Date: Wed, 06 Feb 2008 14:23:45 -0800 From: Eric Rescorla To: Philip Matthews In-Reply-To: References: <47A8A54D.5040402@acm.org> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080206222345.AF2A95084E@romeo.rtfm.com> Cc: 'Behave WG' Subject: Re: [BEHAVE] DF bit in TURN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org At Wed, 6 Feb 2008 16:09:26 -0500, Philip Matthews wrote: > > Marc: Many thanks for doing this investigation! > > As I see it, here are the relevant points in this discussion: > * We don't know a way to read the DF bit on a received packet without > using RAW sockets (which requires root privileges) > * Requiring root privileges is undesirable for P2P apps, but might be > acceptable for a stand-alone server This isn't an issue primarily of root privileges. If you're using raw sockets you are rquired to do the transport layer. This is totally prohibitive if that's TCP. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 6 14:39:23 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E10FE3A693F; Wed, 6 Feb 2008 14:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPP1W0C1cq5M; Wed, 6 Feb 2008 14:39:23 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05A063A6DC2; Wed, 6 Feb 2008 14:39:23 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 025963A6B2B for ; Wed, 6 Feb 2008 14:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f91xKvJOn9bm for ; Wed, 6 Feb 2008 14:39:21 -0800 (PST) Received: from mail-05.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 3D5333A693F for ; Wed, 6 Feb 2008 14:39:21 -0800 (PST) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JMsvx-0005xP-31; Wed, 06 Feb 2008 17:40:02 -0500 In-Reply-To: <20080206222345.AF2A95084E@romeo.rtfm.com> References: <47A8A54D.5040402@acm.org> <20080206222345.AF2A95084E@romeo.rtfm.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Philip Matthews Date: Wed, 6 Feb 2008 17:40:55 -0500 To: Eric Rescorla X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: 'Behave WG' Subject: Re: [BEHAVE] DF bit in TURN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Wed, 6-Feb-08, at 17:23 , Eric Rescorla wrote: > At Wed, 6 Feb 2008 16:09:26 -0500, > Philip Matthews wrote: >> >> Marc: Many thanks for doing this investigation! >> >> As I see it, here are the relevant points in this discussion: >> * We don't know a way to read the DF bit on a received packet without >> using RAW sockets (which requires root privileges) >> * Requiring root privileges is undesirable for P2P apps, but might be >> acceptable for a stand-alone server > > This isn't an issue primarily of root privileges. If you're using > raw sockets you are rquired to do the transport layer. This is > totally prohibitive if that's TCP. I agree that we would only want to use RAW sockets for UDP packets. - Philip _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 6 18:23:54 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6416A3A7174; Wed, 6 Feb 2008 18:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0dZfVjNjn4v; Wed, 6 Feb 2008 18:23:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A7F53A7047; Wed, 6 Feb 2008 18:23:53 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA3573A7047 for ; Wed, 6 Feb 2008 18:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQbm99Do9bsj for ; Wed, 6 Feb 2008 18:23:51 -0800 (PST) Received: from mail-07.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 436EA3A67ED for ; Wed, 6 Feb 2008 18:23:51 -0800 (PST) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JMwRz-0005y5-0c for behave@ietf.org; Wed, 06 Feb 2008 21:25:19 -0500 Mime-Version: 1.0 (Apple Message framework v753) Message-Id: To: Behave WG From: Philip Matthews Date: Wed, 6 Feb 2008 21:25:23 -0500 X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Subject: [BEHAVE] TURN: Rebinding channels X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Here is a strawman proposal for a mechanism to rebind channels. * A channel becomes unbound when its associated permission expires. * A server only allows unbound channels to be bound to a peer. Attempts to bind an already bound channel are rejected. * If a server receives a ChannelData msg on an unbound channel, it replies with an UnboundChannel indication. To prevent any form of amplification, the indication is suppressed if another indication was sent within the last 100 msec. Comments? - Philip _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Feb 7 06:14:28 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BADA3A78C6; Thu, 7 Feb 2008 06:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.451 X-Spam-Level: X-Spam-Status: No, score=-6.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPk-LhaYnn3h; Thu, 7 Feb 2008 06:14:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F8593A7843; Thu, 7 Feb 2008 06:14:27 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21F463A7843 for ; Thu, 7 Feb 2008 06:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpNnkNbsAiZK for ; Thu, 7 Feb 2008 06:14:25 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1507F3A7640 for ; Thu, 7 Feb 2008 06:14:25 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 07 Feb 2008 06:15:56 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m17EFuma016122; Thu, 7 Feb 2008 06:15:56 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m17EFp63019369; Thu, 7 Feb 2008 14:15:55 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Feb 2008 06:15:54 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Feb 2008 06:15:53 -0800 Message-ID: <47AB128A.6090806@cisco.com> Date: Thu, 07 Feb 2008 09:15:38 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Philip Matthews References: In-Reply-To: X-OriginalArrivalTime: 07 Feb 2008 14:15:53.0580 (UTC) FILETIME=[F2DDF2C0:01C86993] Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Behave WG Subject: Re: [BEHAVE] TURN: Rebinding channels X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org I agree with the first and second bullets. I'm worried about the third. Since indications are not authenticated, and attacker can send an UnboundChannel indication and cause the client to cease using that channel, instead trying to rebind with a channel bind transaction. This provides amplification and increases work on the server. -Jonathan R. Philip Matthews wrote: > Here is a strawman proposal for a mechanism to rebind channels. > > * A channel becomes unbound when its associated permission expires. > * A server only allows unbound channels to be bound to a peer. > Attempts to bind an already bound channel are rejected. > * If a server receives a ChannelData msg on an unbound channel, it > replies with an UnboundChannel indication. To prevent any form of > amplification, the indication is suppressed if another indication was > sent within the last 100 msec. > > Comments? > > - Philip > > _______________________________________________ > Behave mailing list > Behave@ietf.org > http://www.ietf.org/mailman/listinfo/behave > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Feb 7 06:23:00 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C6503A790B; Thu, 7 Feb 2008 06:23:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.634 X-Spam-Level: X-Spam-Status: No, score=-1.634 tagged_above=-999 required=5 tests=[AWL=0.665, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXC+vlhJ7Jj6; Thu, 7 Feb 2008 06:22:59 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2FA03A78B3; Thu, 7 Feb 2008 06:22:59 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7D0B3A78B3 for ; Thu, 7 Feb 2008 06:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwbXZyYHgGZp for ; Thu, 7 Feb 2008 06:22:58 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 1E7C13A76F7 for ; Thu, 7 Feb 2008 06:22:57 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m17EPJMO014820; Thu, 7 Feb 2008 08:25:43 -0600 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Feb 2008 16:24:02 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Feb 2008 16:24:02 +0200 Received: from esdhcp04095.research.nokia.com ([172.21.40.95]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Feb 2008 16:24:01 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Date: Thu, 7 Feb 2008 16:24:41 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <47AB128A.6090806@cisco.com> In-Reply-To: <47AB128A.6090806@cisco.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200802071624.41620.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 07 Feb 2008 14:24:01.0981 (UTC) FILETIME=[15FA06D0:01C86995] X-Nokia-AV: Clean Cc: Philip Matthews Subject: Re: [BEHAVE] TURN: Rebinding channels X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Le Thursday 07 February 2008 16:15:38 ext Jonathan Rosenberg, vous avez = =E9crit=A0: > I agree with the first and second bullets. I'm worried about the third. > Since indications are not authenticated, and attacker can send an > UnboundChannel indication and cause the client to cease using that > channel, instead trying to rebind with a channel bind transaction. This > provides amplification and increases work on the server. I agree here. UDP is UDP. It is not reliable and voil=E0. The application-layer protocol = running on top of TURN needs to have some kind of time out detection that = will be triggered to address this particular case. Also: If the server resets, it shall loose entire TURN allocations, not jus= t = some channels. So it does not seem that useful. It feels like yet = another "dear client, I, the server, am sorry to inform you that you are = buggy and I cannot deal with you" type of message, that I can happily live = without. -- = R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Feb 7 07:19:23 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D4DE3A789A; Thu, 7 Feb 2008 07:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjRwXoKL-qAQ; Thu, 7 Feb 2008 07:19:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BCCC3A78A5; Thu, 7 Feb 2008 07:19:22 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78A3C3A789A for ; Thu, 7 Feb 2008 07:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9iVamd0xaYT for ; Thu, 7 Feb 2008 07:19:19 -0800 (PST) Received: from mail-02.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 1064A3A7851 for ; Thu, 7 Feb 2008 07:19:18 -0800 (PST) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JN8YS-0005ti-2P; Thu, 07 Feb 2008 10:20:48 -0500 In-Reply-To: <200802071624.41620.remi.denis-courmont@nokia.com> References: <47AB128A.6090806@cisco.com> <200802071624.41620.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <347E6B1A-325E-4A22-94EA-A2A66B7B940C@magma.ca> From: Philip Matthews Date: Thu, 7 Feb 2008 10:20:59 -0500 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= , Jonathan Rosenberg X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: Behave WG Subject: Re: [BEHAVE] TURN: Rebinding channels X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Good point about the lack of authentication on indications. So let's modify the proposal as Remi suggests and change the third = bullet to: * If a server or client receives a ChannelData msg on an unbound = channel, the msg is silently discarded. - Philip On Thu, 7-Feb-08, at 09:24 , R=E9mi Denis-Courmont wrote: > Le Thursday 07 February 2008 16:15:38 ext Jonathan Rosenberg, vous = > avez > =E9crit : >> I agree with the first and second bullets. I'm worried about the = >> third. >> Since indications are not authenticated, and attacker can send an >> UnboundChannel indication and cause the client to cease using that >> channel, instead trying to rebind with a channel bind transaction. = >> This >> provides amplification and increases work on the server. > > I agree here. > > UDP is UDP. It is not reliable and voil=E0. The application-layer = > protocol > running on top of TURN needs to have some kind of time out = > detection that > will be triggered to address this particular case. > > Also: If the server resets, it shall loose entire TURN allocations, = > not just > some channels. So it does not seem that useful. It feels like yet > another "dear client, I, the server, am sorry to inform you that = > you are > buggy and I cannot deal with you" type of message, that I can = > happily live > without. > > -- = > R=E9mi Denis-Courmont > _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Feb 7 08:35:07 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D01C13A7824; Thu, 7 Feb 2008 08:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzqUmz7zlrGQ; Thu, 7 Feb 2008 08:35:01 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDCDD3A7887; Thu, 7 Feb 2008 08:35:01 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B427D3A7887 for ; Thu, 7 Feb 2008 08:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7SGZWR3sf28 for ; Thu, 7 Feb 2008 08:34:55 -0800 (PST) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.184]) by core3.amsl.com (Postfix) with ESMTP id E8B4C3A706F for ; Thu, 7 Feb 2008 08:34:54 -0800 (PST) Received: by rn-out-0910.google.com with SMTP id a46so1435509rne.10 for ; Thu, 07 Feb 2008 08:36:24 -0800 (PST) Received: by 10.143.17.13 with SMTP id u13mr6348502wfi.69.1202402183423; Thu, 07 Feb 2008 08:36:23 -0800 (PST) Received: by 10.142.233.11 with HTTP; Thu, 7 Feb 2008 08:36:23 -0800 (PST) Message-ID: <953beacc0802070836s268baadao1e9f546e6e95da51@mail.gmail.com> Date: Thu, 7 Feb 2008 08:36:23 -0800 From: "Rohan Mahy" To: "Behave WG" , "Philip Matthews" MIME-Version: 1.0 Subject: [BEHAVE] TURN Allocation retransmission behavior X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0636931344==" Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org --===============0636931344== Content-Type: multipart/alternative; boundary="----=_Part_21643_1311180.1202402183391" ------=_Part_21643_1311180.1202402183391 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline From Philip Mathews: *) Stateful allocation issue: In general, sending an Allocate Request on 5-tuple where there is an existing allocation is not allowed; instead, to refresh the allocation the client uses the Refresh Request. However, there is the issue that, over UDP, retransmissions are allowed. Everyone agrees on the high-level concept, but there were some comments about the exact text in the TURN-06 document. There was a lot of discussion here, which I did not capture. However, in the end this seems to boil down to the best way of implementing the above high-level intent. ACTION: Rohan to send proposed text to the mailing list by the end of Wed, 30 Jan 2008. Hopefully this is better late than never: DISCUSSION: If an Allocate request succeeded, the text in the STUN base spec indicates that a retransmission (an *identical* request) must result in an identical response. I don't think this is a generally a problem. As the text below mentions, except for my caveats mentioned below, the server can recompute a bitwise identical response from the information that is probably stored with the allocation anyway. I think where folks had a problem with this is that if the request received an error response or if the client is actively trying to mess with the server, the response won't be identical, but that is non-problem. CAVEAT 1: One side effect of this requirement is that any nonce provided could (very, very rarely) become stale between being used for the initial allocation and the time the retransmission was received. The server should check that the same credentials are present and are the same as the credentials used to authenticate the original request. In the code path for rebuilding retransmissions, the server should assume that it already checked nonce freshness the first time. CAVEAT 2: If a late Allocation retransmission and a de-Allocation cross on the wire, it is possible that the allocation state has been destroyed already. In this case, I think it should be acceptable to provide a neutral error or ignore the retransmission, but I do not have a strong feeling about this. This brings up a more general race condition question. Is it necessary to prevent the reuse of UDP allocations for some short period of time in case late traffic might get forwarded? CURRENT TEXT (Section 5.2.1): When the server receives the Allocate Request, it begins by processing it according to the base protocol procedures described in [STUN], plus the Long-Term Credential Mechanism procedures if the server is using this mechanism. It then checks if the 5-tuple used for the Allocate Request matches the 5-tuple used for an existing allocation. If there is a match, then: * If the transport protocol is UDP, and the transaction id in the request message matches the transaction id used for the original allocation, then the server treats this as a retransmission of the original request, and replies with the same response as it did to the original request. The server may do this by either storing its original response and resending it, or by rebuilding its original response from other state data. * If the transport protocol is not UDP, or if the transaction id in the request message does not match the transaction id used for the original allocation, then the server replies with an error response containing the error code 437 Allocation Mismatch. If the 5-tuple does not match an existing allocation, then processing continues as described below. PROPOSED TEXT: When the server receives the Allocate Request, it begins by processing it according to the base protocol procedures described in [STUN]. It then checks if the 5-tuple used for the Allocate Request matches the 5-tuple used for an existing allocation. If there is a match, then: * If the allocation has already been recently deleted, the server replies with an appropriate neutral error response. * If the transport protocol is UDP, and the transaction id in the request message matches the transaction id used for the original allocation, then the server treats this as a retransmission of the original request. The server may reply with either the original stored response, or by rebuilding a new response from stored state data. If the request is a retransmission, the rebuilt response will be identical to the original response. * If the transport protocol is not UDP, or if the transaction id in the request message does not match the transaction id used for the original allocation, then the server replies with an error response containing the error code 437 Allocation Mismatch. If the 5-tuple does not match an existing allocation, then the server follows the Long-Term Credential Mechanism procedures if the server is using this mechanism. If authentication is successful processing continues as described below. thanks, -rohan From Section 7.3.1, 3rd paragraph of 3489bis-13: If the request uses UDP transport and is a retransmission of a request for which the server has already generated a success response within the last 10 seconds, the server MUST retransmit the same success response. One way for a server to do this is to remember all transaction IDs received over UDP and their corresponding responses in the last 10 seconds. Another way is to reprocess the request and recompute the response. The latter technique MUST only be applied to requests which are idempotent (a request is considered idempotent when the same request can be safely repeated without impacting the overall state of the system) and result in the same success response for the same request. The Binding method is considered to idempotent in this way (even though certain rare network events could cause the reflexive transport address value to change). Extensions to STUN SHOULD state whether their request types have this property or not. ------=_Part_21643_1311180.1202402183391 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline From Philip Mathews:
*) Stateful allocation issue: In general, sending an Allocate Request on 5-tuple where there is an existing allocation is not allowed; instead, to refresh the allocation the client uses the Refresh Request.  However, there is the issue that, over UDP, retransmissions are allowed. Everyone agrees on the high-level concept, but there were some comments about the exact text in the TURN-06 document.
There was a lot of discussion here, which I did not capture. However, in the end this seems to boil down to the best way of implementing the above high-level intent.
ACTION: Rohan to send proposed text to the mailing list by the end of Wed, 30 Jan 2008.

Hopefully this is better late than never:

DISCUSSION:
If an Allocate request succeeded, the text in the STUN base spec indicates that a retransmission (an *identical* request) must result in an identical response.  I don't think this is a generally a problem.  As the text below mentions, except for my caveats mentioned below, the server can recompute a bitwise identical response from the information that is probably stored with the allocation anyway. I think where folks had a problem with this is that if the request received an error response or if the client is actively trying to mess with the server, the response won't be identical, but that is non-problem.

CAVEAT 1:
One side effect of this requirement is that any nonce provided could (very, very rarely) become stale between being used for the initial allocation and the time the retransmission was received. The server should check that the same credentials are present and are the same as the credentials used to authenticate the original request. In the code path for rebuilding retransmissions, the server should assume that it already checked nonce freshness the first time.

CAVEAT 2:
If a late Allocation retransmission and a de-Allocation cross on the wire, it is possible that the allocation state has been destroyed already. In this case, I think it should be acceptable to provide a neutral error or ignore the retransmission, but I do not have a strong feeling about this.

This brings up a more general race condition question. Is it necessary to prevent the reuse of UDP allocations for some short period of time in case late traffic might get forwarded? 

CURRENT TEXT (Section 5.2.1):
When the server receives the Allocate Request, it begins by processing it according to the base protocol procedures described in [STUN], plus the Long-Term Credential Mechanism procedures if the server is using this mechanism.

It then checks if the 5-tuple used for the Allocate Request matches the 5-tuple used for an existing allocation. If there is a match, then:

    * If the transport protocol is UDP, and the transaction id in the request message matches the transaction id used for the original allocation, then the server treats this as a retransmission of the original request, and replies with the same response as it did to the original request. The server may do this by either storing its original response and resending it, or by rebuilding its original response from other state data.
    * If the transport protocol is not UDP, or if the transaction id in the request message does not match the transaction id used for the original allocation, then the server replies with an error response containing the error code 437 Allocation Mismatch.

If the 5-tuple does not match an existing allocation, then processing continues as described below.

PROPOSED TEXT:
When the server receives the Allocate Request, it begins by processing it according to the base protocol procedures described in [STUN].

It then checks if the 5-tuple used for the Allocate Request matches the 5-tuple used for an existing allocation. If there is a match, then:

    * If the allocation has already been recently deleted, the server replies with an appropriate neutral error response.
    * If the transport protocol is UDP, and the transaction id in the request message matches the transaction id used for the original allocation, then the server treats this as a retransmission of the original request. The server may reply with either the original stored response, or by rebuilding a new response from stored state data.  If the request is a retransmission, the rebuilt response will be identical to the original response.
    * If the transport protocol is not UDP, or if the transaction id in the request message does not match the transaction id used for the original allocation, then the server replies with an error response containing the error code 437 Allocation Mismatch.

If the 5-tuple does not match an existing allocation, then the server follows the Long-Term Credential Mechanism procedures if the server is using this mechanism. If authentication is successful processing continues as described below.


thanks,
-rohan




From Section 7.3.1, 3rd paragraph of 3489bis-13:
   If the request uses UDP transport and is a retransmission of a
   request for which the server has already generated a success response
   within the last 10 seconds, the server MUST retransmit the same
   success response.  One way for a server to do this is to remember all
   transaction IDs received over UDP and their corresponding responses
   in the last 10 seconds.  Another way is to reprocess the request and
   recompute the response.  The latter technique MUST only be applied to
   requests which are idempotent (a request is considered idempotent
   when the same request can be safely repeated without impacting the
   overall state of the system) and result in the same success response
   for the same request.  The Binding method is considered to idempotent
   in this way (even though certain rare network events could cause the
   reflexive transport address value to change).  Extensions to STUN
   SHOULD state whether their request types have this property or not.


------=_Part_21643_1311180.1202402183391-- --===============0636931344== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave --===============0636931344==-- From behave-bounces@ietf.org Thu Feb 7 14:02:51 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E04DB3A7B88; Thu, 7 Feb 2008 14:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBgNSFOn6ZPb; Thu, 7 Feb 2008 14:02:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7C683A76D3; Thu, 7 Feb 2008 14:02:49 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D79B23A7B25 for ; Thu, 7 Feb 2008 14:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgOE7glY5Wed for ; Thu, 7 Feb 2008 14:02:47 -0800 (PST) Received: from mail-09.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 6B8CE3A7BBA for ; Thu, 7 Feb 2008 14:02:09 -0800 (PST) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JNEqK-0006mN-1M for behave@ietf.org; Thu, 07 Feb 2008 17:03:40 -0500 Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <6F768FDE-A39E-47B1-932F-53FD905E8AB5@magma.ca> To: Behave WG From: Philip Matthews Date: Thu, 7 Feb 2008 17:03:49 -0500 X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Subject: [BEHAVE] Summary of TURN open-issues call on 7 Feb 2008 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org TURN open-issues call on Thursday, 7 Feb 2008 Attendees: Philip Matthews Jonathan Rosenberg Rohan Mahy Dan Wing Eric Rescorla Marc Petit-Huguenin Derek MacDonald Remi Denis-Courmond A big thanks to everyone who dialed in. The discussions were good and we reached agreement on a lot of open issues. *) Unbinding Channels: Do we need a mechanism to remove a channel binding? Two possible reasons for having such a mechanism were discussed. The first was a DOS attack by the client against the server where the client would allocate lots and lots of channels and consume lots of resources on the server. After discussion, it was agreed that we were not really worried about this case, since the client needs a username and password to use the server and can thus be assumed to be somewhat trusted. The second reason, which was felt to be more compelling, was a client with a long-lived allocation; the client is not trying to be hostile, but without a method of unbinding channels, the client will naturally allocate more and more channels and consume resources on the server. The attendees then reached consensus on the following proposal for cleaning up unneeded channel bindings: * The server will only allow unbound channels to be bound. Attempts to bind an already bound channel are rejected. * If a client or server receives a ChannelData msg on an unbound channel, the msg is silently discarded. * A channel becomes unbound some time (perhaps 5 minutes, perhaps longer) after its associated permission expires. On the second bullet point, the attendees discussed whether the server should sent an indication to the client that the channel is unbound. There was lots of discussion on possible race conditions that might produce this condition and why an indication might be necessary or very useful, but no clear problem emerged. It was finally agreed that the problem could be detected and was probably best detected at the application layer (because application data would not make it through). On the first bullet point, it was agreed that unbinding the channel immediately when the permission expired might lead to race conditions, and waiting for some time afterwards would probably eliminate them. *) Port Adjacency: How can a client allocate an even port number, or a pair of adjacent ports? After the previous call, Cullen e-mailed a proposal to the mailing list. In brief, his proposal was that an Allocate request could contain either (a) a flag requesting an even port, or (b) a flag requesting a pair of adjacent ports. In the latter case, the server would return a token which the client could use in an Allocate request on a different 5-tuple to allocate the higher numbered port. The higher numbered port would be reserved for "at least 30 seconds" (allowing an implementation to either use a timer, or to simply reserve it for the lifetime of the allocation of the lower- numbered port). There was agreement to use Cullen's proposed mechanism. There was then a discussion on whether a mechanism was needed to request the same IP address as a previous allocation, so that related video and audio streams would have the same IP address. Aattendees were split whether UAs today could handle the streams using different IP addresses, but there was a feeling that there might be applications (perhaps non-SIP apps) that could not handle different IP addresses. So the attendees agreed to a proposal from Jonathan that the server should try to allocate subsequent relayed transport addresses on the same IP address as the first (if possible). This proposal is consistent with the recommendation in RFC 4787 that NATs use an "IP Address Pooling" behavior of "Paired". *) Permission and Allocation Lifetimes: The attendees agreed to the following two proposals with little discussion: * Permission lifetimes MUST be at least 2 minutes, with a recommended value of 5 minutes. * The spec will NOT include a mechanism for either adjusting or learning the permission lifetime. However, there was no agreement on the following proposal (from Cullen): * No explicit allocation lifetime; allocation expires 30 seconds after the last permission expires. ACTION: Philip and Cullen to send e-mail to the mail list why they thing this last point is desirable. *) Preserving bits in the IP header The attendees agreed to the following proposal: * Do not set the DF bit if possible (some stacks supposedly always set this bit) * ECN bits are not copied * TTL bits are not copied * DSCP bits are copied if possible (it seems that some stacks allow the DSCP bits to be read, but other do not) * The document will discuss in detail the implications of the first bullet on Path MTU Discovery The motivation for this proposal has been discussed on the mailing list. There was a brief discussion on whether to define a forwarding behavior which mimics forwarding at the IP layer, but none of the attendees was interested in work out or implementing this. The attendees recognized that no all views on this issue were present on the call, and so more discussion on this point might be necessary. *) Demuxing ChannelData msgs After some discussion, the attendees agreed to go with the demuxing method described in TURN-06 (= the first two bits of a STUN-formatted msg are 00). *) Permission Policy The attendees re-affirmed the decision to go with an address- restricted permission policy. Philip argued that specifying this policy was unnecessary because an IT admin would just allow access to TURN servers that implemented acceptable policies; others agreed but still felt that the address-restricted permission policy should be mandatory. *) Must the server use authentication? The attendees agreed that the server 'MUST implement and SHOULD use' the long-term credential mechanism. *) Does allocating a channel install/refresh a permission? The attendees agreed to "Yes". *) Should an ICMP message be sent in reply if the server discards an incoming UDP packet because there is no corresponding permission? ACTION: Philip to look at what the BEHAVE-ICMP document says. *) Is it possible to change the password while an allocation is still alive? Rohan has proposed that the document be silent about this, and the attendees agreed. - Philip _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Feb 7 15:33:57 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71BFC3A7DE1; Thu, 7 Feb 2008 15:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.489 X-Spam-Level: X-Spam-Status: No, score=-17.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+rUFu9Y0PLy; Thu, 7 Feb 2008 15:33:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 299803A7DC5; Thu, 7 Feb 2008 15:33:53 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C17E3A7D4B; Thu, 7 Feb 2008 15:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmr5WqWmWFJC; Thu, 7 Feb 2008 15:33:48 -0800 (PST) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 780513A7CD8; Thu, 7 Feb 2008 15:32:01 -0800 (PST) Received: by bosco.isi.edu (Postfix, from userid 70) id D8F4710DC79; Thu, 7 Feb 2008 15:33:31 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20080207233331.D8F4710DC79@bosco.isi.edu> Date: Thu, 7 Feb 2008 15:33:31 -0800 (PST) Cc: behave@ietf.org, rfc-editor@rfc-editor.org Subject: [BEHAVE] BCP0135, RFC 5135 on IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. BCP 135 RFC 5135 Title: IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) Author: D. Wing, T. Eckert Status: Best Current Practice Date: February 2008 Mailbox: dwing@cisco.com, eckert@cisco.com Pages: 16 Characters: 36528 Updates: See-Also: BCP0135 I-D Tag: draft-ietf-behave-multicast-12.txt URL: http://www.rfc-editor.org/rfc/rfc5135.txt This document specifies requirements for a for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) that support Any Source IP Multicast or Source-Specific IP Multicast. An IP multicast-capable NAT device that adheres to the requirements of this document can optimize the operation of IP multicast applications that are generally unaware of IP multicast NAT devices. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document is a product of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 8 00:00:04 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C10E28C127; Fri, 8 Feb 2008 00:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBWZthLfhO-0; Fri, 8 Feb 2008 00:00:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A17A28C128; Fri, 8 Feb 2008 00:00:03 -0800 (PST) X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D392628C123; Fri, 8 Feb 2008 00:00:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080208080001.D392628C123@core3.amsl.com> Date: Fri, 8 Feb 2008 00:00:01 -0800 (PST) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-nat-icmp-07.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : NAT Behavioral Requirements for ICMP protocol Author(s) : P. Srisuresh, et al. Filename : draft-ietf-behave-nat-icmp-07.txt Pages : 25 Date : 2008-02-07 This document specifies the behavioral properties required of the Network Address Translator (NAT) devices in conjunction with the Internet Control Message Protocol (ICMP). The objective of this memo is to make NAT devices more predictable and compatible with diverse application protocols that traverse the devices. Companion documents provide behavioral recommendations specific to TCP, UDP and other protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-icmp-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-behave-nat-icmp-07.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-behave-nat-icmp-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-07234755.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-nat-icmp-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-nat-icmp-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-07234755.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Fri Feb 8 00:52:20 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA80B28C151; Fri, 8 Feb 2008 00:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.071 X-Spam-Level: X-Spam-Status: No, score=-1.071 tagged_above=-999 required=5 tests=[AWL=1.528, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSCUcAF6OiTc; Fri, 8 Feb 2008 00:52:19 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A845528C0F5; Fri, 8 Feb 2008 00:52:19 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CBE728C0F5 for ; Fri, 8 Feb 2008 00:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYGED3J1d8tg for ; Fri, 8 Feb 2008 00:52:13 -0800 (PST) Received: from web33313.mail.mud.yahoo.com (web33313.mail.mud.yahoo.com [68.142.206.128]) by core3.amsl.com (Postfix) with SMTP id 8317528C0EB for ; Fri, 8 Feb 2008 00:52:13 -0800 (PST) Received: (qmail 85286 invoked by uid 60001); 8 Feb 2008 08:53:43 -0000 X-YMail-OSG: ngJDq.UVM1nM87DoUKR0z4x.Dw2UhGQfm8cpmJfBPrcbcdLGsu1EjYwLVO_wCa_utS8PDAYLZe5Os_AQpeMG6TCyPLVj8nN3QjSDP1cBGQUuDccBfKQ- Received: from [76.231.46.132] by web33313.mail.mud.yahoo.com via HTTP; Fri, 08 Feb 2008 00:53:42 PST Date: Fri, 8 Feb 2008 00:53:42 -0800 (PST) From: Pyda Srisuresh To: behave@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-802231758-1202460822=:85223" Content-Transfer-Encoding: 8bit Message-ID: <80922.85223.qm@web33313.mail.mud.yahoo.com> Cc: draft-ietf-behave-nat-icmp@tools.ietf.org, behave-chairs@tools.ietf.org Subject: [BEHAVE] Fwd: I-D Action:draft-ietf-behave-nat-icmp-07.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org --0-802231758-1202460822=:85223 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Id: Content-Disposition: inline Dear all, The latest rev (-07) of the ICMP draft is just out. I believe, this addresses all the comments raised by the IESG members. Below is a summary of the changes made in response to their comments. Please give this a read to ensure there is agreement within the WG to make those changes. Thanks. 1. Added definition for the terms "Realm" and "NAT Session" in terminology section (Section 2). 2. Fixed the text preceding the Requirements (REQ-xx), so the text matches the wording in Requirements, when using RFC 2119 terms (MUST, SHOULD etc.). Ex: Text preceding Req-1, Req-2, Req-3 etc. 3. Section 4.1 - Req-3 was subject to most comments from the IESG. The final text is what we agreed to, with one exception. Lars had a DISCUSS on the SHOULD requirements for ICMP checksum validation and the checksum validation of the embedded IP header. I.e., Lars did not think it necessary to have a SHOULD requirement to validate either of the checksums. However, Lars was willing to abstain if there is concurrence from the WG with the currently worded text. Please let us know whether or not there is concurrence to keep the text as-is. 4. Section 7. Tightened up the text, so the conformance is scoped to section 4.3 of RFC1812. 5. Revised Security consideration sections, so it is in conformance with the revised Req-3. 6. Miscellaneous: In many places where there is possibility of confusion, the text is tightened, so it is clearer now. Thanks. regards, suresh --- Internet-Drafts@ietf.org wrote: > To: i-d-announce@ietf.org > From: Internet-Drafts@ietf.org > Date: Fri, 8 Feb 2008 00:00:01 -0800 (PST) > CC: behave@ietf.org > Subject: [BEHAVE] I-D Action:draft-ietf-behave-nat-icmp-07.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Behavior Engineering for Hindrance Avoidance > Working Group of the IETF. > > > Title : NAT Behavioral Requirements for ICMP protocol > Author(s) : P. Srisuresh, et al. > Filename : draft-ietf-behave-nat-icmp-07.txt > Pages : 25 > Date : 2008-02-07 > > This document specifies the behavioral properties required of the > Network Address Translator (NAT) devices in conjunction with the > Internet Control Message Protocol (ICMP). The objective of this > memo is to make NAT devices more predictable and compatible with > diverse application protocols that traverse the devices. Companion > documents provide behavioral recommendations specific to TCP, UDP > and other protocols. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-icmp-07.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > 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-behave-nat-icmp-07.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-behave-nat-icmp-07.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. > > _______________________________________________ > Behave mailing list > Behave@ietf.org > http://www.ietf.org/mailman/listinfo/behave > --0-802231758-1202460822=:85223 Content-Type: text/plain; charset=us-ascii Content-Description: pat1417092943 Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave --0-802231758-1202460822=:85223 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave --0-802231758-1202460822=:85223-- From behave-bounces@ietf.org Fri Feb 8 01:32:32 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B32B03A771E; Fri, 8 Feb 2008 01:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doys4uS+D90w; Fri, 8 Feb 2008 01:32:31 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBB2D28C12F; Fri, 8 Feb 2008 01:32:31 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D44A3A6AFA for ; Fri, 8 Feb 2008 01:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEg9mhp4A7av for ; Fri, 8 Feb 2008 01:32:29 -0800 (PST) Received: from submit01.sysedata.no (submit01.sysedata.no [195.159.29.244]) by core3.amsl.com (Postfix) with ESMTP id E521828C118 for ; Fri, 8 Feb 2008 01:31:58 -0800 (PST) Received: from [82.196.214.14] (helo=[192.168.1.87]) by submit01.sysedata.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.62) (envelope-from ) id 1JNPbp-0000HR-Vl; Fri, 08 Feb 2008 10:33:26 +0100 Message-ID: <47AC21E9.8030907@db.org> Date: Fri, 08 Feb 2008 10:33:29 +0100 From: "Alfred E. Heggestad" User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: Philip Matthews References: <6F768FDE-A39E-47B1-932F-53FD905E8AB5@magma.ca> In-Reply-To: <6F768FDE-A39E-47B1-932F-53FD905E8AB5@magma.ca> Cc: Behave WG Subject: Re: [BEHAVE] Summary of TURN open-issues call on 7 Feb 2008 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Philip Matthews wrote: > > *) Preserving bits in the IP header > The attendees agreed to the following proposal: > * Do not set the DF bit if possible (some stacks supposedly always > set this bit) > * ECN bits are not copied > * TTL bits are not copied > * DSCP bits are copied if possible (it seems that some stacks allow > the DSCP bits to be read, but other do not) > * The document will discuss in detail the implications of the first > bullet on Path MTU Discovery > The motivation for this proposal has been discussed on the mailing list. > There was a brief discussion on whether to define a forwarding > behavior which mimics forwarding at the IP layer, but none of the > attendees was interested in work out or implementing this. > The attendees recognized that no all views on this issue were present > on the call, and so more discussion on this point might be necessary. > I have a suggestion for how to keep the TOS field for outgoing packets on the external interface; since not all platforms allow per-packet TOS field, it might be better and more practical to do it per *session* instead. Some SIP UAs have a configurable TOS-value for outgoing SIP and RTP packets. is it likely that this value will change during a session? No. So we could add a new TURN attribute TOS-FIELD which contains an 8-bit value which will be used for all outgoing packets, from the external interface of the TURN server. This will then be per session.. /alfred _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 8 01:33:45 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4010A28C150; Fri, 8 Feb 2008 01:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtBVSJFlVQeU; Fri, 8 Feb 2008 01:33:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 455E328C188; Fri, 8 Feb 2008 01:33:44 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DE7228C150 for ; Fri, 8 Feb 2008 01:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xU-mrFfxf051 for ; Fri, 8 Feb 2008 01:33:41 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 62DC528C12E for ; Fri, 8 Feb 2008 01:33:41 -0800 (PST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m189YfZC006873; Fri, 8 Feb 2008 11:35:08 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Feb 2008 11:34:47 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Feb 2008 11:34:47 +0200 Received: from esdhcp034233.research.nokia.com ([172.21.34.233]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Feb 2008 11:34:46 +0200 Message-Id: <51595914-6564-46DA-869C-CE3B84A595DB@nokia.com> From: Lars Eggert To: ext Pyda Srisuresh In-Reply-To: <80922.85223.qm@web33313.mail.mud.yahoo.com> Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 8 Feb 2008 11:34:44 +0200 References: <80922.85223.qm@web33313.mail.mud.yahoo.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 08 Feb 2008 09:34:46.0966 (UTC) FILETIME=[D7FEA560:01C86A35] X-Nokia-AV: Clean Cc: behave@ietf.org, behave-chairs@tools.ietf.org, draft-ietf-behave-nat-icmp@tools.ietf.org Subject: Re: [BEHAVE] Fwd: I-D Action:draft-ietf-behave-nat-icmp-07.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On 2008-2-8, at 10:53, ext Pyda Srisuresh wrote: > 3. Section 4.1 - Req-3 was subject to most comments from the IESG. > The final > text is what we agreed to, with one exception. Lars had a DISCUSS on > the SHOULD > requirements for ICMP checksum validation and the checksum > validation of the > embedded IP header. I.e., Lars did not think it necessary to have a > SHOULD > requirement to validate either of the checksums. However, Lars was > willing to > abstain if there is concurrence from the WG with the currently > worded text. > Please let us know whether or not there is concurrence to keep the > text as-is. Related to this, here's my rationale: There's four checksums in an ICMP error packet: +-----------+---------------+-------------+-----------------+ | IP IP-chk | ICMP ICMP-chk | IP2 IP2-chk | Transport T-chk | +-----------+---------------+-------------+-----------------+ IP-chk is the IP checksum of the ICMP error message. The NAT, acting as a router, validates this and drops the packet if it's invalid. (No argument here, I think.) In order to forward the packet, the NAT needs to translate the outer IP header - and *only* the outer IP header. This is important, so I'll say it also in a different way: all the other headers don't matter for the purposes of forwarding the ICMP message. What matters is the destination IP address in the outer header (and to a lesser degree the source address, but that is the NAT's own anyway.) So, where does the NAT get the destination address it should put in the outer IP header from? From a binding. How does it find the binding? Based on the inner "IP2+Transport" five-tuple. Here's our disagreement. You are saying that unless the NAT can validate ICMP-chk and IP2-chk, it should drop the packet. In other words, if there's anything fishy with the payload, don't even try to relay. (Originally, you also said that if it can validate T-chk and it's invalid, it should drop the packet. But I think that's been removed from consideration based on our discussion.) I'm of the opinion that ICMP messages are a diagnostic tool that is of value to the end system, and in the spirit of "be liberal in what you send", the NAT should try hard to forward ICMP whenever it can. What's the issue with not validating the inner checksums? First, the NAT may not have any binding for an invalid five-tuple gleaned from the payload. So the ICMP gets dropped anyway. Effect is the same as if the checksums were validated. Second, the invalid five-tuple happens to match the wrong binding. This can cause the ICMP packet to be forwarded to the wrong host. However, most hosts already check incoming ICMP messages before they act on them, and because a translated header with an invalid checksum will most likely come out with a translated invalid checksum, hosts will detect this. (And note that the translation of the inner headers isn't needed to forward the ICMP packet - it's needed so that the received can associate the ICMP message with one of its communication sessions. That's the difference I was getting at earlier.) So I see little danger in ignoring the checksums and just forwarding things, and some benefit in not complicating NATs with all these checksum validation steps. All that said, I realize that I'm arguing about a corner case here. If this still doesn't convince the authors and the WG, I'm confortable with moving to an ABSTAIN, in order to not block this document endlessly. Lars _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 8 04:45:40 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F97628C281; Fri, 8 Feb 2008 04:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sxd1fcAIfa0L; Fri, 8 Feb 2008 04:45:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8290A28C26B; Fri, 8 Feb 2008 04:45:36 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4E9628C26B for ; Fri, 8 Feb 2008 04:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KuR59D+avSC for ; Fri, 8 Feb 2008 04:45:35 -0800 (PST) Received: from mail-06.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 0A15728C236 for ; Fri, 8 Feb 2008 04:45:34 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JNSdE-0004HY-0w; Fri, 08 Feb 2008 07:47:04 -0500 In-Reply-To: <47AC21E9.8030907@db.org> References: <6F768FDE-A39E-47B1-932F-53FD905E8AB5@magma.ca> <47AC21E9.8030907@db.org> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <3BE16EE3-35EE-4E10-B37C-989932E071A0@magma.ca> From: Philip Matthews Date: Fri, 8 Feb 2008 07:47:16 -0500 To: Alfred E. Heggestad X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] Cc: Behave WG Subject: Re: [BEHAVE] Summary of TURN open-issues call on 7 Feb 2008 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Fri, 8-Feb-08, at 04:33 , Alfred E. Heggestad wrote: > > I have a suggestion for how to keep the TOS field for outgoing packets > on the external interface; > > since not all platforms allow per-packet TOS field, it might be better > and more practical to do it per *session* instead. > > Some SIP UAs have a configurable TOS-value for outgoing SIP and RTP > packets. is it likely that this value will change during a session? > No. > > > So we could add a new TURN attribute TOS-FIELD which contains > an 8-bit value which will be used for all outgoing packets, > from the external interface of the TURN server. This will then > be per session.. How do you handle packets traveling from the peer to the client? - Philip _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 8 05:33:14 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2224028C29E; Fri, 8 Feb 2008 05:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[AWL=-0.476, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koZqnNcZd7YD; Fri, 8 Feb 2008 05:33:13 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 307FE28C269; Fri, 8 Feb 2008 05:33:13 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF2EE28C269 for ; Fri, 8 Feb 2008 05:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4eAb8AxW+vQ for ; Fri, 8 Feb 2008 05:33:11 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id D8EFF28C263 for ; Fri, 8 Feb 2008 05:33:10 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m18DYmei021107; Fri, 8 Feb 2008 07:35:45 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Feb 2008 15:34:23 +0200 Received: from esdhcp04074.research.nokia.com ([172.21.40.74]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Feb 2008 15:34:22 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Date: Fri, 8 Feb 2008 15:35:03 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <6F768FDE-A39E-47B1-932F-53FD905E8AB5@magma.ca> <47AC21E9.8030907@db.org> In-Reply-To: <47AC21E9.8030907@db.org> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200802081535.03783.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 08 Feb 2008 13:34:23.0036 (UTC) FILETIME=[50CCD7C0:01C86A57] X-Nokia-AV: Clean Cc: Philip Matthews Subject: Re: [BEHAVE] Summary of TURN open-issues call on 7 Feb 2008 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Le Friday 08 February 2008 11:33:29 ext Alfred E. Heggestad, vous avez =E9c= rit=A0: > I have a suggestion for how to keep the TOS field for outgoing packets > on the external interface; On most (all?) platforms, TOS is per-socket, not per-packet. But as long as = the TOS value can be modified during the socket lifetime, it's as if it wer= e = a per-packet API. > since not all platforms allow per-packet TOS field, > it might be better and more practical to do it per *session* instead. > > Some SIP UAs have a configurable TOS-value for outgoing SIP and RTP > packets. is it likely that this value will change during a session? > No. Actually, it is likely. I can very well see why the audio and video flows = would get a different TOS. Under a model where the server only handles 1:1 = flows, your proposal may make sense. But this was rejected. TURN is going t= o = handle 1 client-server flow to N server-peer flows. As such I think your = assumption is too restrictive, provided we care about TOS. > So we could add a new TURN attribute TOS-FIELD which contains > an 8-bit value which will be used for all outgoing packets, > from the external interface of the TURN server. This will then > be per session.. That could actually work, on a per-channel rather than per-allocation basis = (maybe). Still... it is clear that some OSes could do per-packet TOS "carry-over", = without root privileges. It is also clear that some other OSes will not = support any kind of TOS support. What's wrong with "In the UDP-to-UDP case, TURN server =D7=D7=D7 preserve t= he TOS = bits in both directions"? We can debate whether =D7=D7=D7 is MUST NOT, SHOU= LD NOT, = MAY, SHOULD, MUST. -- = R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 8 13:47:40 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76BC628C5A1; Fri, 8 Feb 2008 13:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRRNFJr-7hSG; Fri, 8 Feb 2008 13:47:39 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E62728C578; Fri, 8 Feb 2008 13:47:39 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D95C128C578 for ; Fri, 8 Feb 2008 13:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoUP+wLMlYqp for ; Fri, 8 Feb 2008 13:47:38 -0800 (PST) Received: from mail-06.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id A1E1B28C572 for ; Fri, 8 Feb 2008 13:47:37 -0800 (PST) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JNb5i-0005KJ-30; Fri, 08 Feb 2008 16:49:03 -0500 In-Reply-To: <347E6B1A-325E-4A22-94EA-A2A66B7B940C@magma.ca> References: <47AB128A.6090806@cisco.com> <200802071624.41620.remi.denis-courmont@nokia.com> <347E6B1A-325E-4A22-94EA-A2A66B7B940C@magma.ca> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Philip Matthews Date: Fri, 8 Feb 2008 16:49:13 -0500 To: Behave WG X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Subject: Re: [BEHAVE] TURN: Rebinding channels X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org During yesterday's conf call, we agreed to make channel bindings last longer than permissions, but were vague on whether to keep their lifetime tied to permissions or not. (As I recall, Jonathan thought they should not be tied, someone else thought they should, and we left the issue unresolved). As I think more about things today, I now feel they SHOULD NOT be tied to permissions: since they have a different lifetime, I think it makes things clearer if their lifetime is not tied. So here is my modified proposal: * A channel binding last 10 minutes unless refreshed. * A channel binding can be refreshed either (a) by sending a ChannelData message from the client to the server on the channel, or (b) by sending a ChannelBind message to the server rebinding the channel to the same peer. * Attempting to bind a already-bound channel to a different peer is an error (rebinding to the same peer is OK). * A ChannelData message on an unbound channel is silently ignored. Channels interact with permissions as follows: * ChannelBind and ChannelData messages from the client to the server also install/refresh a permission for the IP address of the peer. This proposal also removes the small defect in the previous proposal that sending data to port X on a peer would keep a channel to port Y on the same peer open, even if the channel was never used. (I don't think this is a big issue, but it is a little bonus). Another thing I like about this proposal is that it is easy to document. All the text goes into the section on Channels; there is no need to add text to the (new) section on Permissions (and associated cross-references). Unless I hear objections, this is what I plan to put into TURN-07. - Philip _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 11 10:37:10 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 254DF3A6D66; Mon, 11 Feb 2008 10:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.896 X-Spam-Level: X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGP+03LZ4oHH; Mon, 11 Feb 2008 10:37:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5204D3A6D42; Mon, 11 Feb 2008 10:37:09 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D0453A6D4D for ; Mon, 11 Feb 2008 10:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Hk3l-gAtyqP for ; Mon, 11 Feb 2008 10:37:07 -0800 (PST) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.185]) by core3.amsl.com (Postfix) with ESMTP id C06B13A6D1A for ; Mon, 11 Feb 2008 10:37:06 -0800 (PST) Received: by rn-out-0910.google.com with SMTP id a46so1907207rne.10 for ; Mon, 11 Feb 2008 10:38:32 -0800 (PST) Received: by 10.143.17.13 with SMTP id u13mr282239wfi.69.1202755111133; Mon, 11 Feb 2008 10:38:31 -0800 (PST) Received: by 10.142.52.6 with HTTP; Mon, 11 Feb 2008 10:38:31 -0800 (PST) Message-ID: Date: Mon, 11 Feb 2008 10:38:31 -0800 From: "Derek MacDonald" To: "Philip Matthews" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <47AB128A.6090806@cisco.com> <200802071624.41620.remi.denis-courmont@nokia.com> <347E6B1A-325E-4A22-94EA-A2A66B7B940C@magma.ca> X-Google-Sender-Auth: 002d50f53d250280 Cc: Behave WG Subject: Re: [BEHAVE] TURN: Rebinding channels X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Are zero-length ChannelData messages going to be defined as a mechanism for keeping a channel alive? On Feb 8, 2008 1:49 PM, Philip Matthews wrote: > During yesterday's conf call, we agreed to make channel bindings last > longer than permissions, but were vague on whether to keep their > lifetime tied to permissions or not. (As I recall, Jonathan thought > they should not be tied, someone else thought they should, and we > left the issue unresolved). As I think more about things today, I now > feel they SHOULD NOT be tied to permissions: since they have a > different lifetime, I think it makes things clearer if their lifetime > is not tied. > > So here is my modified proposal: > > * A channel binding last 10 minutes unless refreshed. > * A channel binding can be refreshed either (a) by sending a > ChannelData message from the client to the server on the channel, or > (b) by sending a ChannelBind message to the server rebinding the > channel to the same peer. > * Attempting to bind a already-bound channel to a different peer is > an error (rebinding to the same peer is OK). > * A ChannelData message on an unbound channel is silently ignored. > > Channels interact with permissions as follows: > * ChannelBind and ChannelData messages from the client to the server > also install/refresh a permission for the IP address of the peer. > > This proposal also removes the small defect in the previous proposal > that sending data to port X on a peer would keep a channel to port Y > on the same peer open, even if the channel was never used. (I don't > think this is a big issue, but it is a little bonus). > > Another thing I like about this proposal is that it is easy to > document. All the text goes into the section on Channels; there is no > need to add text to the (new) section on Permissions (and associated > cross-references). > > Unless I hear objections, this is what I plan to put into TURN-07. > > - Philip > > _______________________________________________ > Behave mailing list > Behave@ietf.org > http://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 11 11:57:00 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C97828C1CC; Mon, 11 Feb 2008 11:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[AWL=-0.874, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkQl9vsirSMl; Mon, 11 Feb 2008 11:56:59 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A56128C196; Mon, 11 Feb 2008 11:56:59 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8B8628C15F for ; Mon, 11 Feb 2008 11:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyE6haJmxbKS for ; Mon, 11 Feb 2008 11:56:57 -0800 (PST) Received: from mail-01.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 3437428C17E for ; Mon, 11 Feb 2008 11:56:57 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JOenG-0005wd-0j; Mon, 11 Feb 2008 14:58:22 -0500 In-Reply-To: References: <47AB128A.6090806@cisco.com> <200802071624.41620.remi.denis-courmont@nokia.com> <347E6B1A-325E-4A22-94EA-A2A66B7B940C@magma.ca> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Philip Matthews Date: Mon, 11 Feb 2008 14:58:29 -0500 To: "Derek MacDonald" X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] Cc: Behave WG Subject: Re: [BEHAVE] TURN: Rebinding channels X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Mon, 11-Feb-08, at 13:38 , Derek MacDonald wrote: > Are zero-length ChannelData messages going to be defined as a > mechanism for keeping a channel alive? At present, a zero-length ChannelData message will result in a UDP datagram with zero data bytes being sent to the peer. Like all ChannelData messages from the client to the server, this will refresh the binding. Alternatively, the client can rebind the channel to the peer (= send a ChannelBind message rebinding the channel number to the peer). This will refresh the channel binding without causing anything to be sent to the peer. Right now, I don't see a need to special-case the zero-length ChannelData message. - Philip _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 11 13:50:45 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F45928C308; Mon, 11 Feb 2008 13:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.704 X-Spam-Level: ** X-Spam-Status: No, score=2.704 tagged_above=-999 required=5 tests=[AWL=3.141, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsZY6RlR8le7; Mon, 11 Feb 2008 13:50:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70F473A6982; Mon, 11 Feb 2008 13:50:44 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A74953A6982 for ; Mon, 11 Feb 2008 13:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WR1MCzr+fcR for ; Mon, 11 Feb 2008 13:50:43 -0800 (PST) Received: from mail.bortzmeyer.org (bortzmeyer.netaktiv.com [80.67.170.53]) by core3.amsl.com (Postfix) with ESMTP id E52963A6909 for ; Mon, 11 Feb 2008 13:50:42 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 1B01924084B; Mon, 11 Feb 2008 22:52:06 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id EB8E812570; Mon, 11 Feb 2008 22:51:01 +0100 (CET) Date: Mon, 11 Feb 2008 22:51:01 +0100 From: Stephane Bortzmeyer To: Cullen Jennings Message-ID: <20080211215101.GB11811@sources.org> References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <200801030949.41979.remi.denis-courmont@nokia.com> <914FB0C9-1F63-4EBB-BADE-26F5506619A7@magma.ca> <200801081223.17053.remi.denis-courmont@nokia.com> <20080129210631.GA965@sources.org> <4F41EBF1-3F49-4626-8912-70D8B9351DF0@cisco.com> <20080211214502.GA11292@sources.org> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080211214502.GA11292@sources.org> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i Cc: Behave WG Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Mon, Feb 11, 2008 at 10:45:02PM +0100, Stephane Bortzmeyer wrote a message of 887 lines which said: > Here is the documentation of the tool, I'll send the actual reports > later. (I forgot to say that the tool was tested only with UDP/IPv4.) Linux (tested on two Debian machines, with kernels 2.4 and 2.6) : Can set TOS/DSCP (including ECN) - raising precedence requires to be root -, TTL and DF. Can get TOS/DSCP (including ECN) and TTL. FreeBSD (tested on 6.2) : Can set TOS/DSCP (including ECN) and TTL. Can get TTL. NetBSD (tested on 3.1) : Can set TOS/DSCP (including ECN) and TTL. Cannot get anything. VMS : Can set TOS/DSCP (including ECN) and TTL. Cannot get anything. _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 11 13:54:35 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C9F728C2E7; Mon, 11 Feb 2008 13:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=-2.120, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BajpI5-biMX7; Mon, 11 Feb 2008 13:54:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AAF13A6923; Mon, 11 Feb 2008 13:54:34 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BE8D3A6909 for ; Mon, 11 Feb 2008 13:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Das4+cKaKmNK for ; Mon, 11 Feb 2008 13:54:32 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id C477528C15D for ; Mon, 11 Feb 2008 13:54:31 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id D8F991C0091; Mon, 11 Feb 2008 22:55:55 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id D3A411C008D; Mon, 11 Feb 2008 22:55:55 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id C6EED58ECC8; Mon, 11 Feb 2008 22:55:55 +0100 (CET) Date: Mon, 11 Feb 2008 22:55:55 +0100 From: Stephane Bortzmeyer To: Cullen Jennings Message-ID: <20080211215555.GA3184@nic.fr> References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <200801030949.41979.remi.denis-courmont@nokia.com> <914FB0C9-1F63-4EBB-BADE-26F5506619A7@magma.ca> <200801081223.17053.remi.denis-courmont@nokia.com> <20080129210631.GA965@sources.org> <4F41EBF1-3F49-4626-8912-70D8B9351DF0@cisco.com> <20080211214502.GA11292@sources.org> <20080211215101.GB11811@sources.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080211215101.GB11811@sources.org> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Behave WG Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Mon, Feb 11, 2008 at 10:51:01PM +0100, Stephane Bortzmeyer wrote a message of 41 lines which said: > > Here is the documentation of the tool, I'll send the actual reports > > later. > > (I forgot to say that the tool was tested only with UDP/IPv4.) Tru64 / OSF1 : Can set TOS/DSCP (including ECN) and TTL. Cannot get anything. _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 11 13:55:47 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39D1228C2E7; Mon, 11 Feb 2008 13:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.73 X-Spam-Level: * X-Spam-Status: No, score=1.73 tagged_above=-999 required=5 tests=[AWL=2.167, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1F8dyZJztkx0; Mon, 11 Feb 2008 13:55:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 736EE3A6A68; Mon, 11 Feb 2008 13:55:46 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ED823A6AD7 for ; Mon, 11 Feb 2008 13:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRCaC9UdLO8p for ; Mon, 11 Feb 2008 13:55:44 -0800 (PST) Received: from mail.bortzmeyer.org (virtual3.netaktiv.com [80.67.170.53]) by core3.amsl.com (Postfix) with ESMTP id 84F833A6A68 for ; Mon, 11 Feb 2008 13:55:44 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id DC7F024084F; Mon, 11 Feb 2008 22:57:07 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id 76D081018B; Mon, 11 Feb 2008 22:53:45 +0100 (CET) Date: Mon, 11 Feb 2008 22:53:45 +0100 From: Stephane Bortzmeyer To: Philip Matthews Message-ID: <20080211215344.GB11292@sources.org> References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <200801030949.41979.remi.denis-courmont@nokia.com> <914FB0C9-1F63-4EBB-BADE-26F5506619A7@magma.ca> <200801081223.17053.remi.denis-courmont@nokia.com> <20080129210631.GA965@sources.org> <20080130100029.GA11872@sources.org> <143C83F9-F2EF-4B65-BD4C-99DDDA1586A9@magma.ca> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <143C83F9-F2EF-4B65-BD4C-99DDDA1586A9@magma.ca> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i Cc: Behave WG Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Fri, Feb 01, 2008 at 01:41:36PM -0500, Philip Matthews wrote a message of 33 lines which said: > What if we come up with something that can be fairly easily done by > a unprivileged user-land process? Even if it were the case (but I'm skeptical), I really cannot understand why it is so important. TURN provides a last-resort solution to the connectivity problem. The important things is that it works, not that it is perfect. Frankly, who uses DSCP bits, anyway? I understand only the need for DF manipulation (because of MTU issues) but that's all. Enlightenment welcome. A MAY is sufficient for me. _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 11 14:50:14 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF35C28CA13; Mon, 11 Feb 2008 14:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.053 X-Spam-Level: X-Spam-Status: No, score=-2.053 tagged_above=-999 required=5 tests=[AWL=-2.616, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1npAFHAK7fS; Mon, 11 Feb 2008 14:50:14 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1237628C8A1; Mon, 11 Feb 2008 14:50:14 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A691B28C8A1 for ; Mon, 11 Feb 2008 14:50:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHMldsWuzndV for ; Mon, 11 Feb 2008 14:50:11 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id DD4DB28C1FC for ; Mon, 11 Feb 2008 14:50:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,335,1199692800"; d="scan'208,217";a="12494066" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 11 Feb 2008 14:51:37 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1BMpa1U022906; Mon, 11 Feb 2008 14:51:36 -0800 Received: from [192.168.17.72] (sjc-vpn2-1474.cisco.com [10.21.117.194]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id m1BMpYWt000217; Mon, 11 Feb 2008 22:51:34 GMT Message-Id: From: Cullen Jennings To: "Stephane Bortzmeyer" In-Reply-To: <20080211215101.GB11811@sources.org> Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 11 Feb 2008 14:51:32 -0800 References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <200801030949.41979.remi.denis-courmont@nokia.com> <914FB0C9-1F63-4EBB-BADE-26F5506619A7@magma.ca> <200801081223.17053.remi.denis-courmont@nokia.com> <20080129210631.GA965@sources.org> <4F41EBF1-3F49-4626-8912-70D8B9351DF0@cisco.com> <20080211214502.GA11292@sources.org> <20080211215101.GB11811@sources.org> X-Mailer: Apple Mail (2.915) Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Behave WG Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0218047552==" Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org --===============0218047552== Content-Type: multipart/alternative; boundary=Apple-Mail-2--1022690667 --Apple-Mail-2--1022690667 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit That's really great - thank you. On Feb 11, 2008, at 1:51 PM, Stephane Bortzmeyer wrote: > On Mon, Feb 11, 2008 at 10:45:02PM +0100, > Stephane Bortzmeyer wrote > a message of 887 lines which said: > > > Here is the documentation of the tool, I'll send the actual reports > > later. > > (I forgot to say that the tool was tested only with UDP/IPv4.) > > > Linux (tested on two Debian machines, with kernels 2.4 and 2.6) : > > Can set TOS/DSCP (including ECN) - raising precedence requires to be > root -, TTL and DF. > > Can get TOS/DSCP (including ECN) and TTL. > > > FreeBSD (tested on 6.2) : > > Can set TOS/DSCP (including ECN) and TTL. > > Can get TTL. > > > NetBSD (tested on 3.1) : > > Can set TOS/DSCP (including ECN) and TTL. > > Cannot get anything. > > > VMS : > > Can set TOS/DSCP (including ECN) and TTL. > > Cannot get anything. > --Apple-Mail-2--1022690667 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

That's really great - thank = you. 

On Feb 11, 2008, at 1:51 PM, Stephane = Bortzmeyer wrote:

On Mon, Feb 11, 2008 at 10:45:02PM +0100,
 Stephane = Bortzmeyer <bortzmeyer@nic.fr> wrote
=  a message of 887 lines which said:

> Here is the = documentation of the tool, I'll send the actual reports
> = later.

(I forgot to say that the tool was tested only with = UDP/IPv4.)


Linux (tested on two Debian machines, with = kernels 2.4 and 2.6) :

Can set TOS/DSCP (including ECN) - = raising precedence requires to be
root -, TTL and DF.

Can = get TOS/DSCP (including ECN) and TTL.


FreeBSD (tested on = 6.2) :

Can set TOS/DSCP (including ECN) and TTL.

Can = get TTL.


NetBSD (tested on 3.1) :

Can set = TOS/DSCP (including ECN) and TTL.

Cannot get anything.

=
VMS :

Can set TOS/DSCP (including ECN) and TTL.

= Cannot get anything.

=

= --Apple-Mail-2--1022690667-- --===============0218047552== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave --===============0218047552==-- From behave-bounces@ietf.org Mon Feb 11 18:58:26 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CBED3A6DC4; Mon, 11 Feb 2008 18:58:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=-1.736, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9K8Ds-uol1Fu; Mon, 11 Feb 2008 18:58:25 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DE283A6A63; Mon, 11 Feb 2008 18:58:25 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0232F3A68C9 for ; Mon, 11 Feb 2008 18:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfIP1wymSb0k for ; Mon, 11 Feb 2008 18:58:22 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id CB93F3A6A63 for ; Mon, 11 Feb 2008 18:58:22 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 11 Feb 2008 18:59:47 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1C2xl5H018102 for ; Mon, 11 Feb 2008 18:59:47 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1C2xgEJ019087 for ; Tue, 12 Feb 2008 02:59:47 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Feb 2008 18:59:45 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Feb 2008 18:59:44 -0800 Message-ID: <47B10B92.2070409@cisco.com> Date: Mon, 11 Feb 2008 21:59:30 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Behave WG X-OriginalArrivalTime: 12 Feb 2008 02:59:44.0876 (UTC) FILETIME=[5219BAC0:01C86D23] Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [BEHAVE] Updated rfc3489bis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org I've just submitted an update to rfc3489bis: http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-14.txt This update reflects the DISCUSS comments raised by IESG. There were many discusses and this took some time to address. Below is the full set of changes I made to the document. There are some non-trivial ones, particularly the retransmission behaviors, MTU, and internationalization. So please take a look: * fixed bug in MESSAGE-INTEGRITY section which gave inconsistent advice on usage of the length field in the STUN header * security considerations section mentions usage of strong passwords is a SHOULD * make more explicit mention of the security problems in rfc3489 and why they are mitigated now * now mandating the use of SASLPrep (RFC 4013) for conveying username and processing of password, to deal with internationalization issues. * maximum STUN message size now set to 576 bytes for v4, 1280 for v6, when pmtu is unknown. It was previously 1500 when pmtu is unknown. * default RTO and minimum RTO changed from 100ms to 500ms. Exceptions are provided for non-Internet usages and for cases where rate limits are determined through other means (for example, ICE's RTP-rate matching algorithm). STUN transaction duration changed to 39500ms in the default case as a consequence. Also, the duration that a server has to generate the same response it sent previously to a request (i.e., retransmissions) is moved to 40s. * clarified that, STUN over TCP is unframed when talking to a server you learned through dns or on the default port. Use of framing is only in cases where you have negotiated such as part of the usage - i.e., ICE connectivity checks. * removed text that had servers accept new requests and drop existing connections in cases of overload. Now, just recommend following industry best practices in this area. Clarified that servers have to allow clients to close the connection since the client needs to hold the connection open to use the binding. * ALTERNATE-SERVER mechanism requires clients to remember that they sent a request to a server previously and not try it again if they just tried it within the last 5 minutes. Basically prevents infinite ping-ponging of retry loops. * ICMP failure cases were fuzzy, citing just 'fatal' ones. THis has been clarified to mean hard failure codes as defined in RFC1122. * added a new section defining a 'basic standalone stun server'. This basically describes what was previously called the 'binding discovery usage'. * clarified in the security considerations section that the message integrity mechanism is not always needed and the usage needs to describe this. * the TLS ciphersuites described for STUN over TCP/TLS apply only for cases where STUN is run by itself. When muxed with other protocols the rules of that protocol apply. * mentioned that usage specifications need to discuss the implications of RFC4107, which discusses manual vs. automated key management * pointed to RFC2617 for guidance on NONCE rotation * when a client is redirected via alternate-server, the text now says that the client should use the same transport protoocl used for the previous request. * changed IANA registry rules for error codes from specification required to IETF consensus * noted that the DNS SRV procedures for TCP and TLS are different than they were in RFC 3489 * in the FINGERPRINT section, note that this mechanism is not compatible with rfc3489 and cannot be used in environments where such interoperability is required * changed the number of retransmissions of a request from 7 to a value called Rc which SHOULD be configurable and SHOULD have a default of 7 * removed the MAY part of: "servers SHOULD run STUN on the default port but MAY use others" * removed the requirement that STUN over TLS be on a different port than plain STUN over TCP. If your server software can demux than go for it. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 11 19:00:09 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 701FC3A6E13; Mon, 11 Feb 2008 19:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvlG6RvXA1Cw; Mon, 11 Feb 2008 19:00:08 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CFD73A6CF3; Mon, 11 Feb 2008 19:00:08 -0800 (PST) X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 68D993A6CF3; Mon, 11 Feb 2008 19:00:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080212030006.68D993A6CF3@core3.amsl.com> Date: Mon, 11 Feb 2008 19:00:02 -0800 (PST) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-rfc3489bis-14.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Session Traversal Utilities for (NAT) (STUN) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-behave-rfc3489bis-14.txt Pages : 50 Date : 2008-02-11 Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with NAT traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution. This document obsoletes RFC 3489. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-14.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-behave-rfc3489bis-14.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-behave-rfc3489bis-14.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-11185606.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-rfc3489bis-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-rfc3489bis-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-11185606.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Tue Feb 12 03:20:41 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43EDD28C1F8; Tue, 12 Feb 2008 03:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[AWL=-0.685, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgGEV8q7LkUy; Tue, 12 Feb 2008 03:20:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EB3B28C1EE; Tue, 12 Feb 2008 03:20:40 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F48228C1C6 for ; Tue, 12 Feb 2008 03:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrAS2ndqox5m for ; Tue, 12 Feb 2008 03:20:33 -0800 (PST) Received: from mail-02.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id ACD0428C1DE for ; Tue, 12 Feb 2008 03:20:33 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JOtD4-0002rC-0W; Tue, 12 Feb 2008 06:21:58 -0500 In-Reply-To: <20080211215344.GB11292@sources.org> References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <200801030949.41979.remi.denis-courmont@nokia.com> <914FB0C9-1F63-4EBB-BADE-26F5506619A7@magma.ca> <200801081223.17053.remi.denis-courmont@nokia.com> <20080129210631.GA965@sources.org> <20080130100029.GA11872@sources.org> <143C83F9-F2EF-4B65-BD4C-99DDDA1586A9@magma.ca> <20080211215344.GB11292@sources.org> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <69505D3B-262C-467B-855B-B887BCCCFCD2@magma.ca> From: Philip Matthews Date: Tue, 12 Feb 2008 06:22:18 -0500 To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] Cc: Behave WG Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Mon, 11-Feb-08, at 16:53 , Stephane Bortzmeyer wrote: > On Fri, Feb 01, 2008 at 01:41:36PM -0500, > Philip Matthews wrote > a message of 33 lines which said: > >> What if we come up with something that can be fairly easily done by >> a unprivileged user-land process? > > Even if it were the case (but I'm skeptical), I really cannot > understand why it is so important. TURN provides a last-resort > solution to the connectivity problem. The important things is that it > works, not that it is perfect. Frankly, who uses DSCP bits, anyway? > > I understand only the need for DF manipulation (because of MTU issues) > but that's all. Enlightenment welcome. > > A MAY is sufficient for me. > I agree with you that TURN is the last-resort solution to the connectivity problem. For that reason, the current proposal says that the TURN server should try to preserve the DSCP bits IF IT CAN. It seems that a TURN server can do this on certain OSes, but not on others. - Philip _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Feb 12 03:53:41 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6EFA28C1FB; Tue, 12 Feb 2008 03:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.018 X-Spam-Level: X-Spam-Status: No, score=0.018 tagged_above=-999 required=5 tests=[AWL=-2.241, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWQkye8YvJdH; Tue, 12 Feb 2008 03:53:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5923A6AE6; Tue, 12 Feb 2008 03:53:40 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DD8F28C1C2; Tue, 12 Feb 2008 03:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsgdkPQff29w; Tue, 12 Feb 2008 03:53:38 -0800 (PST) Received: from people.com.cn (unknown [202.99.23.227]) by core3.amsl.com (Postfix) with SMTP id CE46F3A6AE6; Tue, 12 Feb 2008 03:53:37 -0800 (PST) Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm6d47b1eeee; Tue, 12 Feb 2008 20:08:43 +0800 Received: from core3.amsl.com([64.170.98.86]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm12147ad128f; Sat, 09 Feb 2008 02:01:23 +0800 Received: from core3.amsl.com([64.170.98.86]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Sat, 09 Feb 2008 02:01:23 +0800 Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97EEA3A7F20; Thu, 7 Feb 2008 15:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vf5Paq5Snpnj; Thu, 7 Feb 2008 15:37:43 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E330B3A7DC3; Thu, 7 Feb 2008 15:33:52 -0800 (PST) X-Original-To: ietf-announce@core3.amsl.com Delivered-To: ietf-announce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C17E3A7D4B; Thu, 7 Feb 2008 15:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmr5WqWmWFJC; Thu, 7 Feb 2008 15:33:48 -0800 (PST) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 780513A7CD8; Thu, 7 Feb 2008 15:32:01 -0800 (PST) Received: by bosco.isi.edu (Postfix, from userid 70) id D8F4710DC79; Thu, 7 Feb 2008 15:33:31 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20080207233331.D8F4710DC79@bosco.isi.edu> Date: Thu, 7 Feb 2008 15:33:31 -0800 (PST) X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list MIME-Version: 1.0 X-AIMC-AUTH: (null) X-AIMC-MAILFROM: ietf-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: rfc-editor@rfc-editor.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn Cc: behave@ietf.org, rfc-editor@rfc-editor.org Subject: [BEHAVE] BCP0135, RFC 5135 on IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) X-BeenThere: behave@ietf.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. BCP 135 RFC 5135 Title: IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) Author: D. Wing, T. Eckert Status: Best Current Practice Date: February 2008 Mailbox: dwing@cisco.com, eckert@cisco.com Pages: 16 Characters: 36528 Updates: See-Also: BCP0135 I-D Tag: draft-ietf-behave-multicast-12.txt URL: http://www.rfc-editor.org/rfc/rfc5135.txt This document specifies requirements for a for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) that support Any Source IP Multicast or Source-Specific IP Multicast. An IP multicast-capable NAT device that adheres to the requirements of this document can optimize the operation of IP multicast applications that are generally unaware of IP multicast NAT devices. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document is a product of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org http://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Feb 12 04:07:08 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F32A93A6C90; Tue, 12 Feb 2008 04:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.886 X-Spam-Level: X-Spam-Status: No, score=-0.886 tagged_above=-999 required=5 tests=[AWL=-0.749, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvKIDgMnCMNK; Tue, 12 Feb 2008 04:07:07 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21AA93A6B16; Tue, 12 Feb 2008 04:07:07 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32F053A6B16 for ; Tue, 12 Feb 2008 04:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tApnlHlzEL5h for ; Tue, 12 Feb 2008 04:07:05 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id DC6633A6A5B for ; Tue, 12 Feb 2008 04:07:00 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1CC7t2R013222; Tue, 12 Feb 2008 14:08:20 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Feb 2008 14:08:18 +0200 Received: from esdhcp04098.research.nokia.com ([172.21.40.98]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Feb 2008 14:08:17 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Date: Tue, 12 Feb 2008 14:09:03 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <20080211215344.GB11292@sources.org> <69505D3B-262C-467B-855B-B887BCCCFCD2@magma.ca> In-Reply-To: <69505D3B-262C-467B-855B-B887BCCCFCD2@magma.ca> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200802121409.03821.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 12 Feb 2008 12:08:17.0202 (UTC) FILETIME=[F3602120:01C86D6F] X-Nokia-AV: Clean Cc: ext Philip Matthews Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Le Tuesday 12 February 2008 13:22:18 ext Philip Matthews, vous avez =E9crit= =A0: > I agree with you that TURN is the last-resort solution to the > connectivity problem. For that reason, the current proposal says that > the TURN server should try to preserve the DSCP bits IF IT CAN. It > seems that a TURN server can do this on certain OSes, but not on others. One related issue I was wondering about is, how do NATs and firewalls inter= act = (or preferably not interact) with the TOS bits. It is well known that some deployed firewalls screw up with ECN, but I supp= ose = it's an issue with the TCP flags, rather than the IP-layer flags, right? On the other hand, RFC4380, which also tunnels specifically through NATs, d= oes = not say anything about preserving the TOS bits. I haven't checked ESP-in-UD= P. -- = R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Feb 12 09:27:21 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 140AD28C36B; Tue, 12 Feb 2008 09:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=-0.954, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqTZKwP5YJ1M; Tue, 12 Feb 2008 09:27:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A375D3A6E72; Tue, 12 Feb 2008 09:27:15 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 164403A6E6F for ; Tue, 12 Feb 2008 09:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfBNlVnfROSk for ; Tue, 12 Feb 2008 09:27:12 -0800 (PST) Received: from mail-09.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 314E33A6C55 for ; Tue, 12 Feb 2008 09:27:12 -0800 (PST) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JOyvs-0000NH-0Y; Tue, 12 Feb 2008 12:28:36 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Philip Matthews Date: Tue, 12 Feb 2008 12:28:56 -0500 To: Behave WG X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: Dan Wing Subject: Re: [BEHAVE] TURN Issue: Re-using the 5-tuple X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On 19-Dec-07, at 10:14 , Marc Petit-Huguenin wrote: > There is no explanation on what can be done after an allocation > expires. > Is it possible to create a new one from the same source IP and port? > With the same username/realm/password? > As I think more about this, I now think that the TURN server should do the following: 1) It should not reuse the relayed transport address, AND 2) It should reject attempts to re-use the 5-tuple for some time after the allocation expires. Point (1) prevents data packets from the peer to the server from being delivered to the wrong client. Point (2) prevents data packets from the client to the server from being delivered to the wrong peer. I am thinking that the time should be either 2 minutes (as suggested by Dan) or 4 minutes (2*MSL, which is what BEHAVE-TCP uses). Comments? - Philip _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Feb 12 09:58:23 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5767C28CC53; Tue, 12 Feb 2008 09:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.242 X-Spam-Level: X-Spam-Status: No, score=-3.242 tagged_above=-999 required=5 tests=[AWL=-2.805, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cd72uAPCJ-7V; Tue, 12 Feb 2008 09:58:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F3BB28C248; Tue, 12 Feb 2008 09:58:15 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97C2028C236 for ; Tue, 12 Feb 2008 09:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4gkRuPCVhNc for ; Tue, 12 Feb 2008 09:58:06 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8346A28CC6C for ; Tue, 12 Feb 2008 09:58:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,341,1199692800"; d="scan'208";a="5705938" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 12 Feb 2008 09:59:30 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m1CHxT2i020016; Tue, 12 Feb 2008 09:59:29 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1CHxSJM005205; Tue, 12 Feb 2008 17:59:29 GMT From: "Dan Wing" To: References: <80922.85223.qm@web33313.mail.mud.yahoo.com> <51595914-6564-46DA-869C-CE3B84A595DB@nokia.com> Date: Tue, 12 Feb 2008 09:59:28 -0800 Message-ID: <08eb01c86da1$0378a6a0$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <51595914-6564-46DA-869C-CE3B84A595DB@nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchqNe14RQJGJobmQWWiEkHoO9UC9wDasA6w Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: draft-ietf-behave-nat-icmp@tools.ietf.org Subject: Re: [BEHAVE] Fwd: I-D Action:draft-ietf-behave-nat-icmp-07.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Folks, We will wait a few more days for working group comments on these changes. If there are none, we will continue with IESG processing of this draft with the changes as-is. Side-by-side differences are available at: or . -d > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Lars Eggert > Sent: Friday, February 08, 2008 1:35 AM > To: ext Pyda Srisuresh > Cc: behave@ietf.org; behave-chairs@tools.ietf.org; > draft-ietf-behave-nat-icmp@tools.ietf.org > Subject: Re: [BEHAVE] Fwd: I-D > Action:draft-ietf-behave-nat-icmp-07.txt > > On 2008-2-8, at 10:53, ext Pyda Srisuresh wrote: > > 3. Section 4.1 - Req-3 was subject to most comments from the IESG. > > The final > > text is what we agreed to, with one exception. Lars had a > DISCUSS on > > the SHOULD > > requirements for ICMP checksum validation and the checksum > > validation of the > > embedded IP header. I.e., Lars did not think it necessary > to have a > > SHOULD > > requirement to validate either of the checksums. However, Lars was > > willing to > > abstain if there is concurrence from the WG with the currently > > worded text. > > Please let us know whether or not there is concurrence to keep the > > text as-is. > > Related to this, here's my rationale: > > There's four checksums in an ICMP error packet: > > +-----------+---------------+-------------+-----------------+ > | IP IP-chk | ICMP ICMP-chk | IP2 IP2-chk | Transport T-chk | > +-----------+---------------+-------------+-----------------+ > > IP-chk is the IP checksum of the ICMP error message. The NAT, acting > as a router, validates this and drops the packet if it's > invalid. (No > argument here, I think.) > > In order to forward the packet, the NAT needs to translate the outer > IP header - and *only* the outer IP header. This is > important, so I'll > say it also in a different way: all the other headers don't > matter for > the purposes of forwarding the ICMP message. What matters is the > destination IP address in the outer header (and to a lesser > degree the > source address, but that is the NAT's own anyway.) > > So, where does the NAT get the destination address it should put in > the outer IP header from? From a binding. How does it find the > binding? Based on the inner "IP2+Transport" five-tuple. > > Here's our disagreement. You are saying that unless the NAT can > validate ICMP-chk and IP2-chk, it should drop the packet. In other > words, if there's anything fishy with the payload, don't even try to > relay. (Originally, you also said that if it can validate T-chk and > it's invalid, it should drop the packet. But I think that's been > removed from consideration based on our discussion.) > > I'm of the opinion that ICMP messages are a diagnostic tool > that is of > value to the end system, and in the spirit of "be liberal in > what you > send", the NAT should try hard to forward ICMP whenever it can. > > What's the issue with not validating the inner checksums? > > First, the NAT may not have any binding for an invalid five-tuple > gleaned from the payload. So the ICMP gets dropped anyway. Effect is > the same as if the checksums were validated. > > Second, the invalid five-tuple happens to match the wrong binding. > This can cause the ICMP packet to be forwarded to the wrong host. > However, most hosts already check incoming ICMP messages before they > act on them, and because a translated header with an invalid > checksum > will most likely come out with a translated invalid checksum, hosts > will detect this. > > (And note that the translation of the inner headers isn't needed to > forward the ICMP packet - it's needed so that the received can > associate the ICMP message with one of its communication sessions. > That's the difference I was getting at earlier.) > > So I see little danger in ignoring the checksums and just forwarding > things, and some benefit in not complicating NATs with all these > checksum validation steps. > > All that said, I realize that I'm arguing about a corner case > here. If > this still doesn't convince the authors and the WG, I'm confortable > with moving to an ABSTAIN, in order to not block this document > endlessly. > > Lars > _______________________________________________ > Behave mailing list > Behave@ietf.org > http://www.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Feb 12 10:24:38 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF85828CCF3; Tue, 12 Feb 2008 10:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.936 X-Spam-Level: X-Spam-Status: No, score=-2.936 tagged_above=-999 required=5 tests=[AWL=-2.799, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6MhubohqG9D; Tue, 12 Feb 2008 10:24:37 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B30828CB6D; Tue, 12 Feb 2008 10:24:37 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45F4F3A698D for ; Tue, 12 Feb 2008 10:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQgr+vbzdDlp for ; Tue, 12 Feb 2008 10:24:34 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 193F328CCFB for ; Tue, 12 Feb 2008 10:24:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,341,1199692800"; d="scan'208";a="5711971" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 12 Feb 2008 10:25:34 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m1CIPYW7011741; Tue, 12 Feb 2008 10:25:34 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1CIPXnY020284; Tue, 12 Feb 2008 18:25:33 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Denis-Courmont'?=" , References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca><20080211215344.GB11292@sources.org><69505D3B-262C-467B-855B-B887BCCCFCD2@magma.ca> <200802121409.03821.remi.denis-courmont@nokia.com> Date: Tue, 12 Feb 2008 10:25:33 -0800 Message-ID: <090d01c86da4$a8078b70$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200802121409.03821.remi.denis-courmont@nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Achtb/8t40Mea5JjTliIDC5bPAJ5qwANGpIg Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'ext Philip Matthews' Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > One related issue I was wondering about is, how do NATs and > firewalls interact (or preferably not interact) with the TOS > bits. I am not aware of any tests. You can do your own easily enough -- even Windows XP's built-in PING utility allows setting ToS bits using "-v". However, even "-v 255" on my system only seems to allow setting the ToS bits to 0x2, according to tcpdump. My IOS NAT and my Linksys WRT54G running Tomato both preserve the ToS value to a host on the Internet. For whatever that's worth... -d _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Feb 12 10:27:50 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DA1528CCB7; Tue, 12 Feb 2008 10:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.982 X-Spam-Level: X-Spam-Status: No, score=-100.982 tagged_above=-999 required=5 tests=[AWL=-0.545, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxMq5tM+c+Pr; Tue, 12 Feb 2008 10:27:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 630263A6BA5; Tue, 12 Feb 2008 10:27:49 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1332328C3DA for ; Tue, 12 Feb 2008 10:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unsdkKAR+s1j for ; Tue, 12 Feb 2008 10:27:47 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 4484C3A6B47 for ; Tue, 12 Feb 2008 10:27:47 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 8A4A07F109A; Tue, 12 Feb 2008 18:29:11 +0000 (UTC) Received: from [192.168.1.3] (c-71-202-183-123.hsd1.ca.comcast.net [71.202.183.123]) by server.implementers.org (Postfix) with ESMTP id 96C907F103C; Tue, 12 Feb 2008 18:29:09 +0000 (UTC) Message-ID: <47B1E574.408@acm.org> Date: Tue, 12 Feb 2008 10:29:08 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080109) MIME-Version: 1.0 To: Philip Matthews References: In-Reply-To: Cc: Behave WG , Dan Wing Subject: Re: [BEHAVE] TURN Issue: Re-using the 5-tuple X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Philip Matthews wrote: > > On 19-Dec-07, at 10:14 , Marc Petit-Huguenin wrote: >> There is no explanation on what can be done after an allocation expires. >> Is it possible to create a new one from the same source IP and port? >> With the same username/realm/password? >> > > As I think more about this, I now think that the TURN server should do > the following: > 1) It should not reuse the relayed transport address, AND > 2) It should reject attempts to re-use the 5-tuple > for some time after the allocation expires. > > Point (1) prevents data packets from the peer to the server from being > delivered to the wrong client. I agree with this. > Point (2) prevents data packets from the > client to the server from being delivered to the wrong peer. What happen when a NAT reuse the same port after the expiration of the binding? 192.168.1.1 208.77.188.166 Client NAT TURN | Port 5000 | | |------------------>| Port 49567 | | |---------------->| : : : | | Binding expires | : : : | Port 5001 | | |------------------>| Port 49567 | | |---------------->| Rejected If the Binding on the NAT expires after 15 seconds, but the TURN server rejects allocations two minutes after the expiration of the allocation, then legitimate allocation from a different port will fail (note that the NAT should apply the same rule and do not reuse port 49567 for 2 minutes after the binding expires, but you cannot count on it). A solution would be to have a specific return code in this case, so the client knows that the NAT reused a port less than two minutes after the binding expires. The client can then retry. Also the I-D should say that the TURN client cannot reuse a port for two minutes (or perhaps that this should be said in rfc3489bis?) > > I am thinking that the time should be either 2 minutes (as suggested by > Dan) or 4 minutes (2*MSL, which is what BEHAVE-TCP uses). > > Comments? > > - Philip > -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Feb 12 10:36:44 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CCED28C39E; Tue, 12 Feb 2008 10:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.004 X-Spam-Level: X-Spam-Status: No, score=-3.004 tagged_above=-999 required=5 tests=[AWL=-2.567, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3PcUTWZnUz7; Tue, 12 Feb 2008 10:36:43 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 646C128C282; Tue, 12 Feb 2008 10:36:43 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AE8B3A6E6D for ; Tue, 12 Feb 2008 10:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjLECq+4fhOc for ; Tue, 12 Feb 2008 10:36:40 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 890343A6E5B for ; Tue, 12 Feb 2008 10:36:40 -0800 (PST) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 12 Feb 2008 10:38:05 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1CIc4Wk026148; Tue, 12 Feb 2008 10:38:04 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1CIc3nY004296; Tue, 12 Feb 2008 18:38:04 GMT From: "Dan Wing" To: "'Marc Petit-Huguenin'" , "'Philip Matthews'" References: <47B1E574.408@acm.org> Date: Tue, 12 Feb 2008 10:38:03 -0800 Message-ID: <093301c86da6$67604420$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <47B1E574.408@acm.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchtpT/zU/ntoP1DT7eLMJ/+Epaf4wAANtWg Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'Behave WG' Subject: Re: [BEHAVE] TURN Issue: Re-using the 5-tuple X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org ... > A solution would be to have a specific return code in this > case, so the > client knows that the NAT reused a port less than two minutes > after the > binding expires. The client can then retry. > > Also the I-D should say that the TURN client cannot reuse a > port for two minutes (or perhaps that this should be said in > rfc3489bis?) I don't believe rfc3489bis should say anything about this; the MSL isn't relevant for classic STUN. In TURN, I would cite as justification for the two minutes Section 3.3 of draft-ietf-tsvwg-udp-guidelines-05 which reads, in part: ... Finally, it is important to note that delay spikes can be very large. This can cause reordered packets to arrive many seconds after they were sent. [RFC0793] defines the the maximum delay a TCP segment should experience - the Maximum Segment Lifetime (MSL) - as 2 minutes. No other RFC defines an MSL for other transport protocols or IP itself. This document clarifies that the MSL value to be used for UDP SHOULD be the same 2 minutes as for TCP. Applications SHOULD be robust to the reception of delayed or duplicate packets that are received within this 2-minute interval. ... -d _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Feb 12 11:34:48 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B95D28C434; Tue, 12 Feb 2008 11:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[AWL=-0.940, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4LssYT+XLlc; Tue, 12 Feb 2008 11:34:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A52928C178; Tue, 12 Feb 2008 11:34:46 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F13928C28D for ; Tue, 12 Feb 2008 11:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Z8SBxmrRVej for ; Tue, 12 Feb 2008 11:34:44 -0800 (PST) Received: from mail-08.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 31D7528C162 for ; Tue, 12 Feb 2008 11:34:44 -0800 (PST) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-08.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JP0vI-0004VQ-0s; Tue, 12 Feb 2008 14:36:08 -0500 In-Reply-To: <47B1E574.408@acm.org> References: <47B1E574.408@acm.org> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Philip Matthews Date: Tue, 12 Feb 2008 14:36:27 -0500 To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: Behave WG , Dan Wing Subject: Re: [BEHAVE] TURN Issue: Re-using the 5-tuple X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Tue, 12-Feb-08, at 13:29 , Marc Petit-Huguenin wrote: > Philip Matthews wrote: >> >> On 19-Dec-07, at 10:14 , Marc Petit-Huguenin wrote: >>> There is no explanation on what can be done after an allocation >>> expires. >>> Is it possible to create a new one from the same source IP and port? >>> With the same username/realm/password? >>> >> >> As I think more about this, I now think that the TURN server >> should do >> the following: >> 1) It should not reuse the relayed transport address, AND >> 2) It should reject attempts to re-use the 5-tuple >> for some time after the allocation expires. >> >> Point (1) prevents data packets from the peer to the server from >> being >> delivered to the wrong client. > > I agree with this. > >> Point (2) prevents data packets from the >> client to the server from being delivered to the wrong peer. > > What happen when a NAT reuse the same port after the expiration of the > binding? > > 192.168.1.1 208.77.188.166 > Client NAT TURN > | Port 5000 | | > |------------------>| Port 49567 | > | |---------------->| > : : : > | | Binding expires | > : : : > | Port 5001 | | > |------------------>| Port 49567 | > | |---------------->| Rejected > > If the Binding on the NAT expires after 15 seconds, but the TURN > server > rejects allocations two minutes after the expiration of the > allocation, > then legitimate allocation from a different port will fail (note that > the NAT should apply the same rule and do not reuse port 49567 for 2 > minutes after the binding expires, but you cannot count on it). > > A solution would be to have a specific return code in this case, so > the > client knows that the NAT reused a port less than two minutes after > the > binding expires. The client can then retry. The obvious code to use in this case is 437 Allocation Mismatch. As I think more about this, I see the following recovery actions for the client on receipt of a 437 (in this case or in other cases): 1) If the client sent an Allocate request, then this means that the server thinks the allocation already exists for some reason. Since the client thinks there is no allocation, its recovery action is to try a different 5-tuple. 2) If the client sent any other request, then this means that the server thinks the allocation does not exist. Since there is no way for the client to recover its allocation, its only recovery action is to start over with a different 5-tuple. If this seems reasonable, I will add some text about how a client can recovery from a 437 to the document. - Philip _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Feb 12 11:35:49 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85C1628C3FB; Tue, 12 Feb 2008 11:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.308 X-Spam-Level: X-Spam-Status: No, score=-1.308 tagged_above=-999 required=5 tests=[AWL=-0.871, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kl--Ez6CPJRA; Tue, 12 Feb 2008 11:35:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD5C128C28D; Tue, 12 Feb 2008 11:35:48 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55AB928C162 for ; Tue, 12 Feb 2008 11:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Npy2+zGEggos for ; Tue, 12 Feb 2008 11:35:46 -0800 (PST) Received: from mail-01.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id A33CC28C28D for ; Tue, 12 Feb 2008 11:35:46 -0800 (PST) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JP0wI-0000cQ-0s; Tue, 12 Feb 2008 14:37:10 -0500 In-Reply-To: <093301c86da6$67604420$c4f0200a@cisco.com> References: <47B1E574.408@acm.org> <093301c86da6$67604420$c4f0200a@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <92977066-C65B-47F7-82BA-A24970AC8FDC@magma.ca> From: Philip Matthews Date: Tue, 12 Feb 2008 14:37:29 -0500 To: "Dan Wing" X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: 'Behave WG' Subject: Re: [BEHAVE] TURN Issue: Re-using the 5-tuple X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Tue, 12-Feb-08, at 13:38 , Dan Wing wrote: > > In TURN, I would cite as justification for the two minutes Section > 3.3 of > draft-ietf-tsvwg-udp-guidelines-05 which reads, in part: > > ... > Finally, it is important to note that delay spikes can be very > large. > This can cause reordered packets to arrive many seconds after they > were sent. [RFC0793] defines the the maximum delay a TCP segment > should experience - the Maximum Segment Lifetime (MSL) - as 2 > minutes. No other RFC defines an MSL for other transport protocols > or IP itself. This document clarifies that the MSL value to be > used > for UDP SHOULD be the same 2 minutes as for TCP. Applications > SHOULD > be robust to the reception of delayed or duplicate packets that are > received within this 2-minute interval. > ... Thanks for the pointer. I will add this to the document. - Philip _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Feb 12 11:49:22 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5ABB28C492; Tue, 12 Feb 2008 11:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.482 X-Spam-Level: X-Spam-Status: No, score=-3.482 tagged_above=-999 required=5 tests=[AWL=-3.045, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyUeAWoGWEme; Tue, 12 Feb 2008 11:49:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B73A528C46B; Tue, 12 Feb 2008 11:49:19 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5145D28C3B9 for ; Tue, 12 Feb 2008 11:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrWsquDMhV-T for ; Tue, 12 Feb 2008 11:49:14 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id B65D628C3E2 for ; Tue, 12 Feb 2008 11:49:00 -0800 (PST) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 12 Feb 2008 11:50:25 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1CJoP1k003143; Tue, 12 Feb 2008 11:50:25 -0800 Received: from [192.168.17.72] (sjc-vpn3-514.cisco.com [10.21.66.2]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1CJoFJM000036; Tue, 12 Feb 2008 19:50:16 GMT Message-Id: <90313308-3229-4B02-8307-817962639CE0@cisco.com> From: Cullen Jennings To: Stephane Bortzmeyer In-Reply-To: <20080211215344.GB11292@sources.org> Mime-Version: 1.0 (Apple Message framework v915) Date: Tue, 12 Feb 2008 11:50:14 -0800 References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <200801030949.41979.remi.denis-courmont@nokia.com> <914FB0C9-1F63-4EBB-BADE-26F5506619A7@magma.ca> <200801081223.17053.remi.denis-courmont@nokia.com> <20080129210631.GA965@sources.org> <20080130100029.GA11872@sources.org> <143C83F9-F2EF-4B65-BD4C-99DDDA1586A9@magma.ca> <20080211215344.GB11292@sources.org> X-Mailer: Apple Mail (2.915) Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Behave WG , Philip Matthews Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Feb 11, 2008, at 1:53 PM, Stephane Bortzmeyer wrote: > The important things is that it > works, not that it is perfect. Frankly, who uses DSCP bits, anyway? Many voip deployments use DSCP. When you are running in an enterprise environment over a VPN with a DLS line, they can help make sure that downloading email does not trash a phone call. _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Feb 12 14:42:31 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FE5D3A69A4; Tue, 12 Feb 2008 14:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.338 X-Spam-Level: X-Spam-Status: No, score=-3.338 tagged_above=-999 required=5 tests=[AWL=-2.901, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4xMV7cNIx8x; Tue, 12 Feb 2008 14:42:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9270828C3E0; Tue, 12 Feb 2008 14:42:30 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86DBC28C3E0 for ; Tue, 12 Feb 2008 14:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCxOG16H4w3I for ; Tue, 12 Feb 2008 14:42:28 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 8C1233A6CCB for ; Tue, 12 Feb 2008 14:42:28 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m1CMhjw19872; Tue, 12 Feb 2008 22:43:45 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 12 Feb 2008 16:43:43 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF14D1D0FD@zrc2hxm0.corp.nortel.com> In-Reply-To: <90313308-3229-4B02-8307-817962639CE0@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] TURN Issue: Preserving bits in the IP header Thread-Index: AchtsJ4yUQDz4OU5Shi8KTHHzywwCwAGBOuw References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <200801030949.41979.remi.denis-courmont@nokia.com> <914FB0C9-1F63-4EBB-BADE-26F5506619A7@magma.ca> <200801081223.17053.remi.denis-courmont@nokia.com> <20080129210631.GA965@sources.org> <20080130100029.GA11872@sources.org> <143C83F9-F2EF-4B65-BD4C-99DDDA1586A9@magma.ca> <20080211215344.GB11292@sources.org> <90313308-3229-4B02-8307-817962639CE0@cisco.com> From: "Francois Audet" To: "Cullen Jennings" , "Stephane Bortzmeyer" Cc: Behave WG , Philip Matthews Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Correct. It is widely used. > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: Tuesday, February 12, 2008 11:50 > To: Stephane Bortzmeyer > Cc: Behave WG; Philip Matthews > Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header > > > On Feb 11, 2008, at 1:53 PM, Stephane Bortzmeyer wrote: > > > The important things is that it > > works, not that it is perfect. Frankly, who uses DSCP bits, anyway? > > Many voip deployments use DSCP. When you are running in an > enterprise environment over a VPN with a DLS line, they can > help make sure that downloading email does not trash a phone call. > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > http://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Feb 12 15:01:20 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD07F28C426; Tue, 12 Feb 2008 15:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.228 X-Spam-Level: X-Spam-Status: No, score=-1.228 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LcxY5r-FYfP; Tue, 12 Feb 2008 15:01:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9E1228C3C4; Tue, 12 Feb 2008 15:01:18 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 893853A6E83 for ; Tue, 12 Feb 2008 15:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KNGW+Hn8zIp for ; Tue, 12 Feb 2008 15:01:16 -0800 (PST) Received: from submit01.sysedata.no (submit01.sysedata.no [195.159.29.244]) by core3.amsl.com (Postfix) with ESMTP id 759713A6E65 for ; Tue, 12 Feb 2008 15:01:16 -0800 (PST) Received: from [84.215.127.238] (helo=[10.0.0.4]) by submit01.sysedata.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.62) (envelope-from ) id 1JP498-0006Mb-AM; Wed, 13 Feb 2008 00:02:38 +0100 Message-ID: <47B2258D.9070707@db.org> Date: Wed, 13 Feb 2008 00:02:37 +0100 From: "Alfred E. Heggestad" User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: Jonathan Rosenberg References: <20080212030006.68D993A6CF3@core3.amsl.com> In-Reply-To: <20080212030006.68D993A6CF3@core3.amsl.com> Cc: 'Behave WG' Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-rfc3489bis-14.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Hi Jonathan I have two small nits to the new draft-ietf-behave-rfc3489bis-14: > 7.2. Sending the Request or Indication > > connectivity checks), a client SHOULD space new transactions to a > server by RTO and SHOULD limit itself to ten outstanding transactions > to the same sevrer. ^^^^^^ Typo -> Should be "server" > 7.3.1. Processing a Request > > within the last 40 seconds, the server MUST retransmit the same > success response. One way for a server to do this is to remember all > transaction IDs received over UDP and their corresponding responses > in the last 10 seconds. Another way is to reprocess the request and The number of seconds to wait was increased from 10 to 40 in 14. However only the first value is updated, the value on the last line still says "10 seconds" /alfred Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. > > > Title : Session Traversal Utilities for (NAT) (STUN) > Author(s) : J. Rosenberg, et al. > Filename : draft-ietf-behave-rfc3489bis-14.txt > Pages : 50 > Date : 2008-02-11 > > Session Traversal Utilities for NAT (STUN) is a protocol that serves > as a tool for other protocols in dealing with NAT traversal. It can > be used by an endpoint to determine the IP address and port allocated > to it by a NAT. It can also be used to check connectivity between > two endpoints, and as a keep-alive protocol to maintain NAT bindings. > STUN works with many existing NATs, and does not require any special > behavior from them. > > STUN is not a NAT traversal solution by itself. Rather, it is a tool > to be used in the context of a NAT traversal solution. This is an > important change from the previous version of this specification (RFC > 3489), which presented STUN as a complete solution. > > This document obsoletes RFC 3489. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-14.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > 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-behave-rfc3489bis-14.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-behave-rfc3489bis-14.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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Behave mailing list > Behave@ietf.org > http://www.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 13 00:15:12 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2A8E3A6F40; Wed, 13 Feb 2008 00:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.513 X-Spam-Level: X-Spam-Status: No, score=-1.513 tagged_above=-999 required=5 tests=[AWL=-1.426, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADsuA8+St1-2; Wed, 13 Feb 2008 00:15:12 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09C893A6F3C; Wed, 13 Feb 2008 00:15:12 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89AC93A6F0D for ; Wed, 13 Feb 2008 00:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPpFmcinDbzr for ; Wed, 13 Feb 2008 00:15:07 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id 99AEA3A6E9E for ; Wed, 13 Feb 2008 00:15:07 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 88A881C010F; Wed, 13 Feb 2008 09:16:30 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 82FFF1C0091; Wed, 13 Feb 2008 09:16:30 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 7F64458ECC9; Wed, 13 Feb 2008 09:16:30 +0100 (CET) Date: Wed, 13 Feb 2008 09:16:30 +0100 From: Stephane Bortzmeyer To: Francois Audet Message-ID: <20080213081630.GA10526@nic.fr> References: <200801030949.41979.remi.denis-courmont@nokia.com> <914FB0C9-1F63-4EBB-BADE-26F5506619A7@magma.ca> <200801081223.17053.remi.denis-courmont@nokia.com> <20080129210631.GA965@sources.org> <20080130100029.GA11872@sources.org> <143C83F9-F2EF-4B65-BD4C-99DDDA1586A9@magma.ca> <20080211215344.GB11292@sources.org> <90313308-3229-4B02-8307-817962639CE0@cisco.com> <1ECE0EB50388174790F9694F77522CCF14D1D0FD@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1ECE0EB50388174790F9694F77522CCF14D1D0FD@zrc2hxm0.corp.nortel.com> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-6-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Behave WG , Philip Matthews Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Tue, Feb 12, 2008 at 04:43:43PM -0600, Francois Audet wrote a message of 27 lines which said: > Correct. It is widely used. I was talking about its use on the public Internet (you do not need TURN if you're entirely inside your own network). _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 13 03:23:28 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5D728C754; Wed, 13 Feb 2008 03:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.327 X-Spam-Level: X-Spam-Status: No, score=-1.327 tagged_above=-999 required=5 tests=[AWL=-1.240, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+YhLH6Vk61o; Wed, 13 Feb 2008 03:23:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0668D3A6F62; Wed, 13 Feb 2008 03:23:27 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A29033A6F62 for ; Wed, 13 Feb 2008 03:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id of+xjrv4x3dE for ; Wed, 13 Feb 2008 03:23:20 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id ACF2C3A6F5F for ; Wed, 13 Feb 2008 03:23:19 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 3252E1C00D7; Wed, 13 Feb 2008 12:24:42 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 1C5811C0075; Wed, 13 Feb 2008 12:24:42 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 18AA558ECC8; Wed, 13 Feb 2008 12:24:42 +0100 (CET) Date: Wed, 13 Feb 2008 12:24:41 +0100 From: Stephane Bortzmeyer To: Dan Wing Message-ID: <20080213112441.GA31129@nic.fr> References: <200802121409.03821.remi.denis-courmont@nokia.com> <090d01c86da4$a8078b70$c4f0200a@cisco.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline In-Reply-To: <090d01c86da4$a8078b70$c4f0200a@cisco.com> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-6-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) Cc: behave@ietf.org, 'ext Philip Matthews' Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Feb 12, 2008 at 10:25:33AM -0800, Dan Wing wrote a message of 18 lines which said: > You can do your own easily enough -- even Windows XP's built-in PING > utility allows setting ToS bits using "-v". It may be simpler to use the program I mentioned on that list which, strangely, was not archived in http://www.ietf.org/mail-archive/web/behave/. It should work on Windows, too. I attach the program again, to compensate for its non-archival. --XsQoSWH+UP9D9v3l Content-Type: application/octet-stream Content-Disposition: attachment; filename="tests-socket.tar.gz" Content-Transfer-Encoding: base64 H4sICHLTskcCA3Rlc3RzLXNvY2tldC50YXIA7Tz9c9pIsvnV+ivm2E0MLsBgY+fKXqfOwXZC XWxcgJO9WqcoIQbQGUk8aYTN7uX97dfdM6MvZOfT3rv3NLUbgzTT09/T3TOD4IEIaoFn3XCx /exxWgPay709/Nt8uddI/tXtWRN6tPb2mnv7zWeNZutlY+8Z23v2BC0MhOkz9mzk+eJ3h6+4 n9/vc+//S5tIyt9e1GbcHHO/FnBRt36k/PdbrXvk32zsvyT5t17u7+zsNeF5Ez6/fMYahfwf vf1ku9Y8HHP2SyDGtlefvTJSj+b2KP2M+7673s30p+lnoWvD42w/33ZT/TZ+cbkYZ2YIVsG2 WC14sP5Y6un681AErunw9AsAbbuo1S4+N7a32LkXCOZNGNDg+bWZ6QJ57pT5Xog9AxYIb85d NvE9h/UFX3I32GQjz7sJ2Na2YSw9e8wSDcAMYfayNQMN2gLqqqxer1cOczv6XHxZx/8J7Zye 9CBuWzDvkOYXfhleEyTDWQ0XRFu5YvxhbEwWwG8xKYMg4GmVldjz4NotVVlqMIz+lBhvuxNv bTgw6OHh21sG22I9bnlL7pujOZc8rjN2iUCYyRweBOaUVxlwnQEzQt9lwmOWOZ9z6AfDEYLm FFEOStWkf3ckF3SnwYwzqUusBH9LzAEjZsGCW/ZkxQS8tTwX8Ahsz1WPbcsU+G3i+YDACoEG NOk2Kcb7495x702/id+JE/dIDNmyNIdz0O1IFAgKBIDP0ZWIMj6oIoLAmo1llouasoDemkPu jsvqq7ERCwC/TSbzMJipkdg9fgD4URfJyIQIzkxhzu9jPvFecN+xXVPwOjvx3E3BxqGzAI75 8vUYnyEkwpu4CfIW3NkMGNk+W5rzkKckRir7nyCyPNv5PpmR4aRkNlmEwipvXrub+EJJYk2S /A4waVbyJQP6PwcBjNEATMVesoTPigwBZaRWZaMQvnqfERgBskXAzAC8qI3TIzA1TUqc6NP+ E6SZ41t/tDDzDFB50Hwp9qTnMjX9QKgwbRc/Bp4DXB6PbSQURO0BJCDandaUhMd8AZNxl8wL zdx3iCl1duEJDnwzQY72ZMJ96MMU/wJcsK4uOr+i4OypG/eQ4jNx7gA1iSQPq6CSNwwrkfxL rGx5zsL0udSHTVzogE+I860tZmx3D0GNuLjlsPr1JbLvSWFe90+qJDN+ZzqLOa+Ahg5mdkAT BxJlewJdpWIjHOCIZAGDbiNOnEF6UNddD5D0JTmSKVV2y6X6gJC4vwCHhoQoVYyUF6DFii2n nXIX+YtWNFPLjVxcYBL2T1JI7o41sDEooQNCiXgjoSu2SbQkdK2V2RXXSC17qIjARWFbLOro BFN499tOo/ERlQf4Upaz/OWINSoMRmwEShllV1hTy8+DSomUUqodDcBFdeMT4/OA0ygFuPGR HbHN68YmvtW+nylYiWUcY/qht0AZDGE2kL4L3JCWNDdHfF5FZoN+Cgyaoi/AGiILvyabs5Jh 1+H6K58H4Rxf6D6AoPxQvjwbdi5OB1XW77b/Pjx50zs+r7Ljs+HVRf/ytI0EIn/icUes1pQ8 0qZfapsuytLyOYhZwT1gpYomH+fGCbnAd0BBBK7KOpeXve6gO+xcVmNCX0gqgd3279yblIGc isZEgYtFpUOA0m8A6fW70/OPTCEUSB2FcAj157kNOFWZYqziY1p+a5EUjAxCywLfOwnn85WE iKAovloHZWxYcy/gEX1S2ADTcMD5lGnF8KdWVQl5C74s75GlEHPgWbNxCJHyZMwnwKlBtz8c vO11r968vbwa5A7yAhiU7QkgkMT7BzTuGn893MDA27yzHeA5sA2C7ekMllC0sZ/AQO1JGpHL 3ml72O51Bp328LR9mQccnITFwY9aPEIqM+oBzFKDG3dmgxDsmXbASaiJ9yCRkuWDL7NKCWxz YHLLldTuELDT9kXNMhcUBgsf/OQCckeEsBHa46FIDYUnD9kVGHZoCabyG6Zc1BAXD7I6GA4z T8ET2OOyjE4yqjYAZ4A+GFwekmeO7DlQxEl1Ue1GGBPY0r12LpnM/0ENc4Gdr9hV5wQdu1JV wgC7RtYYIqLlFwlEH7SwlKFDBCTHx1a+Tk+8DCAa+F+VkHdMawZZnHyKyKG7jbGow2fpBZIP IRDjZpB5qCAhBllXWhoM3pXQuwzhQ1WaU36/bl/16/ar0iBy+4GupPqBKuX2i9Uy1T1+XEkY 9PB8cDU86fTb3fenPQNVcuBFXuvkDGVO6+7MtG4glAGFEHPgwdRDRVEmSn0vARCTaAQUpRgb mBmAOqNy10mn11CFCeRcEg7CkDgnsaIH+AofDE+6uUQDJAvk438lrItBJXIAa/pz4bEb17t1 2a250jYQs0UGGqBCUh+kHWjDz8AC/Spdux9MHyOwA+Sn54IvRyooKDFFYmmC6QLg92Kxql67 1wLVnXqQTVoihNBkYdJKKC0wAHgQsIE/d6d8rOyRwtEGOf9Hqf+dmzd8Ys/5I9R/76//NZo7 uy1Z/222Gjv7WP/b393dLep/T9Ha7aOpZRnts3fHb/pHtQ/ogmtTVus2jHcnRz//0W5/gg/y rTE47r0+fvfuaFs4i+2k5tSBh4YBYw8o6OaY4VrchhQGopRkUfmApWvMnrHx8x/vTj4x/Jdm +cRqHvv5b2v9jMyDLCQLIQG2AKmtAVlrfQyJnkbzgfmjDob+FA3Knyp6aWjaDyIuPDBPoosR f04MzZ8t8Zri/Qw7jI16uppvGGMbe6E/dY2NsjWGfPqQXYPXBfWvWUtWq/E7qpwepXxCPVi6 rDaB2ZX0P7Hke/biBQKZ/m4vAMII3sAfSBghfIpHVCCbwnkPIE5wEFgKtazKsK26x7b+1zCe Fe1p93+0Cj+t/9/b3d1T/n8XXH+L/P9Osf/ztPs/JctzHM+tz0rrpY8xBmYzL4CMJJup0CsM CA/zR+GrIcbdh4bKZczx2McwW3bAsqaM9zCj+bPqF39qAQNiamhApMutZAkjy57aK9MeIvcw 8tS8z+0w5+43lDUUBlSICA5UWSMSfTUW9RMVYNa2r76gEJOonwCEjbiEgknQ61DVBE13hdE/ Zi8/tkqTYIk7TjDj5HhwHBGNXypV1lgnPNnh80Uo3KwxhZmQ1/MgJTHkQCS09W277ygr/eA6 RtYzQPYtAl1CRQyQObsVxQ/a5Cld4bYFkpwyA6Q79YBKLyUq+C9/a3xUloPUR3wCcTkQunpW +fz41+Hbbn9wcXx+GnWJPFjc76IzhK790977isTeWqzKCUuhyZofsy8jSKrHzsfUJADfFJ6d 6YtdHO6A7pVfEF9AcyJVogckS1DvD5zJwKtzuWyx8rH0XxU24pYZBlxXgKIw63ZmWzNmB+R/ lq0aZq911hFYQUEN42awqsodAqq9Sz9HZfqJaQERoHgOZIzMJAgOSNquLXxPeJY3B/30MTwl IyM06+CcJqZjgyEdMYXcYeIdwsdtf3gbe9xkZWnKhdaQcp5bUqzVXHqRdY8PukSpVIkp1E4d 7n2QklyDO7guMVmvR8tKusYp4q9L+BK+srCiSPfoRbqiSldU6RJVukcokv1/yf/iosIT5n/N Rquxl63/7beK+t+fl//dn0GtJXmoMoso0lKZ3noYmOx0KENM8GZDXO/LKvqznGA6G/t0osL3 ZCoHPrHrsjOfczqIcBtFL4wiBXAovdP2e3Dy0ca/9Pl1dul7I/B+K3Cco3BKPjB2vGpQvIWu 5qwjDkMZhBwpUOxf/2L3vVZwYj/2BfAqtEUYoQeB2RwSjCqeogDyxh5SgeEFRhhb4PuXKTIx HInTrXq9zqK+0QZlzjGAcm5inI3OlQDYlj57FAW8KtxM9atU4pFadlvWED7B86yajEI8tJKO tCnNyUkaIHudQsx5xHSnHHiKwcOvgavH5MCPQuzolGIcY2tuVGQkTp9rr1Cwtre8j0Xwilu5 I2qv4J/hCOIZGCvRv7cXHkY9UvzI6SRfN2X0f65kpqgETeIqjL/Dw1KwYnLw7KvokMsZaJLt gvNzMZR/e8kGfrjfosghGkraZwtlPC5az0V3eH7a7x+/OR22YQnvdd9l8NLzH7G0jA7z+0ka 0qKJ1/IoYAWzX8KoREodSyoTuv7yBaUO7UUof9ZHcNbS4wdKAz0JYAwhNhutwNIo0FaR/+GD 3EJh9TknmynvVig620C7LpPxALHt8/6b4Vmn1x+8PelplawcMm1cG1KdVe8ydb/4Ndm5Kt9W VBWB2CPB116RT5qDMsylU9JlGqzkRz55S42nRAcaOMHPjX+/T64IoCQ7xs7v/T7k1pfvOued gUZrna/XAlMH9HRR+iId3BZVI7YqkjlotWWFIjJEywrp/AyaBA4ouhdPDNo/h1+3v33Sb1/+ iUh2Lwed7sXnEAWpqryA4fG/53dfi+sadKzESQAwhdr7rkI+yO8W3MJ9bzIpyGMlVWAedIAV EU9yao3+6hqhCg8D/1fLa84O/AamCk7G91F6YAq2mJsCT1mCceO6qpOJiQ0oxaxJpw+fHqsE JqvY8euuy5X3frg4hnlh96R7gGWdfSy6eOQy1CB0h1iygN6wbq+o/HvfopToW6lky2s795XX 0sFbXEqTBYW16O8zVbKcEal6Wfq9LonljFLHdb+vtuJzc1wUVx4urvwJOyM6GJPqnA7G5DMZ WsnPtVeB7eaVFlPvlTrNBJhhRp9S0hvZqcp91nbQY0Z45SGVkPMDhOMsWbJz85Mv3WKJR1XZ C3AtEXLw+UdssShZgs3g4hzxT6OeW8YxpHdWXtcMbggSjgdbhLzTc9Au5bGnYM1p11N+OcOc bv9bmIPVuG9mDi02X8IfHRx8F5M0kK/n1NfzBWKJp2BMIhjJsiZVVSxnqow/5PvaRldRJ1yv //VOj0/OTx/l/vcD5z9azZ3s+b+9vb1WUf97iqajo5l3q+vsGLBDQMWWpm97YRAZrQqgohDJ 2Pr2Zhh0iyjAUJEmBeCBjTeM2ML3pr7pBLL6MMIrSbe+LQSXl8cQhdenb4/fnxqd08EZ++D5 N0jAG98LF6w8E2JxsL0NUfI8qNtcTOqeP92+nW6POMKrQMCGNx1xR8YO+HxlaJimJeylLVb6 qtHgqnfB9G4m7XXCl6U95smbWypsxLN1VhjQdTdzBF6dlS7Ba3J/iZjlxpelOrKArxjGyrds 5YV0FwnPz+F9Ks0FiAhdyR8lhLl9Q0tolZ2cVY1omSj3ztpsp/WyBQSeti/k993m/l8rMM85 UIz3cilKXKnjxnSeASStFxXIkBAJnM+acetG80GWSoAOIwDiqwzYRVvCpj6vHLh0IY0qmDiA yMVsE0IcDgmh5fkAQwAeHQnR9CG4XAIoPd8otOd4YNrnsfQPDGOLlVLnBLFGI1UEOCXHoKqG GLzKvezo/HWAyAB4g9EEQxg9lPfzFB8JujzuViIoJb33gQkO7TGRnuBlO9vC5Q/vKnvOwp7z aFaAjlcv5dwkR0QE9BRe4t1OMKIZcV0JFom/nXl4OfpOHuw2jDbBRPYmbKPrsivXvpNRvaQZ r7N581DfqwOQoVsTptRd+DtCQ6JU26Ns29jErfnNOusQI1RhWdoUDplalqYHMcT8nEawdvvI sjZZGQjxuVGyrBLOByD8qH9FQ9VX5jIVQ3UBFFNxQ6fm0bEBVp4kKo+y6lhJYmDUTtbLZpt1 4krynh4kPeilOKQqDA+tgzovTLwQCDpQloruc6lV1ehwbjU+Y2sRu/SuR0V/IwnD8LUSKTD+ /Xkf9NLSZ30NkNuN/mxcBZEUDSOjucjCWHdJY+mGIlHtSWmzzcyR3U0DUZLTsk0/dNPHZpEl 96gwUY43NMlSOE4YqWOd9QCS59K8pqFzRlNelVQc1tctMZ/XPfDibuLyKUCoJ6cUILqA4EI2 HzrQRaov5V1u6IwALGCDN3e5a+Cl1wh5OVTcetFQldDSwQsqKpD1ucK0hMbUyAAGGtGlQk4f KuQJejViL0iurk64QgZXQ4usadqaGIeQhiGvD/SZb3YAKdzP5/846fT/fvAb/u3Vz//Rv3oN Hz4qleJ33HgYqrLAW1NegpXelVijXO9oRcYEy9FE6QXSYLJNsbDomnfNNcLxgignqgnwJkoE fZqY0R1bG/Jf0wceHIdi5unV2TD6gi/A2cCqGUUw7Jc4mvmba1v1if9KenUH72ZDcuHekI/5 ANpiY+VrbKjfw6A1uEQMdTmIzL/RLhtTlJKBrdhV/y+N/7UzfOLz3/v7zbXz3639Iv4vfv/n R/7+z7dchf7am9CPeRH6e+5BP8I16G+/BW38BETi+oibThDjQ5JWip4lj+Cynb291AusT4C8 Us8ISLOx0yp+4an4hafiF56KX3gqfuGp+IWn4heeil94+j/6C09Fylq0ohWtaEUrWtGKVrSi Fa1oRSta0YpWtKIVrWhFK1rRila0ohWtaEUrWtEy7d+Ya/ZOAHgAAA== --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave --XsQoSWH+UP9D9v3l-- From behave-bounces@ietf.org Wed Feb 13 07:36:39 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FC9F28C896; Wed, 13 Feb 2008 07:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.851 X-Spam-Level: X-Spam-Status: No, score=-2.851 tagged_above=-999 required=5 tests=[AWL=-2.414, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jb4kOjSYOVqQ; Wed, 13 Feb 2008 07:36:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21CC028C806; Wed, 13 Feb 2008 07:36:37 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B54A528C882 for ; Wed, 13 Feb 2008 07:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aFEYksKEE55 for ; Wed, 13 Feb 2008 07:36:35 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6442E28C593 for ; Wed, 13 Feb 2008 07:36:35 -0800 (PST) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by rtp-iport-2.cisco.com with ESMTP; 13 Feb 2008 10:37:54 -0500 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1DFbrC7014247; Wed, 13 Feb 2008 07:37:53 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1DFbo0l023421; Wed, 13 Feb 2008 15:37:50 GMT From: "Dan Wing" To: "'Stephane Bortzmeyer'" References: <200802121409.03821.remi.denis-courmont@nokia.com> <090d01c86da4$a8078b70$c4f0200a@cisco.com> <20080213112441.GA31129@nic.fr> Date: Wed, 13 Feb 2008 07:37:47 -0800 Message-ID: <054601c86e56$633946c0$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20080213112441.GA31129@nic.fr> Thread-Index: AchuMxJUH7Ee2kl+Qi2EeEzxdic7YAAIz0rw Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: behave@ietf.org, 'ext Philip Matthews' Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org = > -----Original Message----- > From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr] = > Sent: Wednesday, February 13, 2008 3:25 AM > To: Dan Wing > Cc: 'R=E9mi Denis-Courmont'; behave@ietf.org; 'ext Philip Matthews' > Subject: Re: TURN Issue: Preserving bits in the IP header > = > On Tue, Feb 12, 2008 at 10:25:33AM -0800, > Dan Wing wrote = > a message of 18 lines which said: > = > > You can do your own easily enough -- even Windows XP's built-in PING > > utility allows setting ToS bits using "-v". > = > It may be simpler to use the program I mentioned on that list which, > strangely, was not archived in > http://www.ietf.org/mail-archive/web/behave/. There were some archival issues during the switchover of IETF servers. I hadn't realized BEHAVE was affected. = > It should work on > Windows, too. > = > I attach the program again, to compensate for its non-archival. Thanks. -d _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 13 07:58:29 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5EC428C826; Wed, 13 Feb 2008 07:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=-1.888, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5D8D7REh9o5; Wed, 13 Feb 2008 07:58:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5D5228C7D0; Wed, 13 Feb 2008 07:58:28 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA8FA3A6F8D for ; Wed, 13 Feb 2008 07:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxI2CtZoohdI for ; Wed, 13 Feb 2008 07:58:27 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id E4EDA28C7D0 for ; Wed, 13 Feb 2008 07:58:26 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m1DFxcQ16588; Wed, 13 Feb 2008 15:59:39 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Feb 2008 09:59:07 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF14D1DB0D@zrc2hxm0.corp.nortel.com> In-Reply-To: <20080213081630.GA10526@nic.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TURN Issue: Preserving bits in the IP header Thread-Index: AchuGMACqQEBIl0yTAeXNy6aC9zyyQAQI+sg References: <200801030949.41979.remi.denis-courmont@nokia.com> <914FB0C9-1F63-4EBB-BADE-26F5506619A7@magma.ca> <200801081223.17053.remi.denis-courmont@nokia.com> <20080129210631.GA965@sources.org> <20080130100029.GA11872@sources.org> <143C83F9-F2EF-4B65-BD4C-99DDDA1586A9@magma.ca> <20080211215344.GB11292@sources.org> <90313308-3229-4B02-8307-817962639CE0@cisco.com> <1ECE0EB50388174790F9694F77522CCF14D1D0FD@zrc2hxm0.corp.nortel.com> <20080213081630.GA10526@nic.fr> From: "Francois Audet" To: "Stephane Bortzmeyer" Cc: Behave WG , Philip Matthews Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org That, I don't know. Probably need input from service providers. > -----Original Message----- > From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr] > Sent: Wednesday, February 13, 2008 00:17 > To: Audet, Francois (SC100:3055) > Cc: Cullen Jennings; Stephane Bortzmeyer; Behave WG; Philip Matthews > Subject: Re: TURN Issue: Preserving bits in the IP header > > On Tue, Feb 12, 2008 at 04:43:43PM -0600, Francois Audet > wrote a message of 27 lines which said: > > > Correct. It is widely used. > > I was talking about its use on the public Internet (you do > not need TURN if you're entirely inside your own network). > _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 13 08:47:47 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFF5828C8DA; Wed, 13 Feb 2008 08:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.801 X-Spam-Level: X-Spam-Status: No, score=-100.801 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BR8ENmKdA6xz; Wed, 13 Feb 2008 08:47:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B4663A6BE9; Wed, 13 Feb 2008 08:47:47 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A12A63A6F65 for ; Wed, 13 Feb 2008 08:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAj-F1hRnm37 for ; Wed, 13 Feb 2008 08:47:45 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 019663A6F53 for ; Wed, 13 Feb 2008 08:47:45 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 362747F109A; Wed, 13 Feb 2008 16:49:08 +0000 (UTC) Received: from [192.168.1.3] (c-71-202-183-123.hsd1.ca.comcast.net [71.202.183.123]) by server.implementers.org (Postfix) with ESMTP id 7F6667F103C; Wed, 13 Feb 2008 16:49:05 +0000 (UTC) Message-ID: <47B31F80.7090805@acm.org> Date: Wed, 13 Feb 2008 08:49:04 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080109) MIME-Version: 1.0 To: Stephane Bortzmeyer References: <200801030949.41979.remi.denis-courmont@nokia.com> <914FB0C9-1F63-4EBB-BADE-26F5506619A7@magma.ca> <200801081223.17053.remi.denis-courmont@nokia.com> <20080129210631.GA965@sources.org> <20080130100029.GA11872@sources.org> <143C83F9-F2EF-4B65-BD4C-99DDDA1586A9@magma.ca> <20080211215344.GB11292@sources.org> <90313308-3229-4B02-8307-817962639CE0@cisco.com> <1ECE0EB50388174790F9694F77522CCF14D1D0FD@zrc2hxm0.corp.nortel.com> <20080213081630.GA10526@nic.fr> In-Reply-To: <20080213081630.GA10526@nic.fr> Cc: Behave WG , Philip Matthews Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Stephane Bortzmeyer wrote: > On Tue, Feb 12, 2008 at 04:43:43PM -0600, > Francois Audet wrote > a message of 27 lines which said: > >> Correct. It is widely used. > > I was talking about its use on the public Internet (you do not need > TURN if you're entirely inside your own network). See also RFC4504 section 2.12. -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 13 12:18:27 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 494383A67A7; Wed, 13 Feb 2008 12:18:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.367 X-Spam-Level: X-Spam-Status: No, score=-3.367 tagged_above=-999 required=5 tests=[AWL=-2.930, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAbzFdYbRdI3; Wed, 13 Feb 2008 12:18:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7385B3A68DF; Wed, 13 Feb 2008 12:18:26 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 094EA3A6D7C for ; Wed, 13 Feb 2008 12:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0e1EVW1hN81d for ; Wed, 13 Feb 2008 12:18:24 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id EE6BB3A68DF for ; Wed, 13 Feb 2008 12:18:23 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 13 Feb 2008 12:19:47 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1DKJlsk021532; Wed, 13 Feb 2008 12:19:47 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id m1DKJkPp009640; Wed, 13 Feb 2008 20:19:46 GMT From: Cullen Jennings To: Stephane Bortzmeyer In-Reply-To: <20080213081630.GA10526@nic.fr> Impp: xmpp:cullenfluffyjennings@jabber.org References: <200801030949.41979.remi.denis-courmont@nokia.com> <914FB0C9-1F63-4EBB-BADE-26F5506619A7@magma.ca> <200801081223.17053.remi.denis-courmont@nokia.com> <20080129210631.GA965@sources.org> <20080130100029.GA11872@sources.org> <143C83F9-F2EF-4B65-BD4C-99DDDA1586A9@magma.ca> <20080211215344.GB11292@sources.org> <90313308-3229-4B02-8307-817962639CE0@cisco.com> <1ECE0EB50388174790F9694F77522CCF14D1D0FD@zrc2hxm0.corp.nortel.com> <20080213081630.GA10526@nic.fr> Message-Id: <1CBB39B6-CC90-426E-A335-0C4E8E19C5C1@cisco.com> Mime-Version: 1.0 (Apple Message framework v915) Date: Wed, 13 Feb 2008 12:19:36 -0800 X-Mailer: Apple Mail (2.915) Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Behave WG , Philip Matthews Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Feb 13, 2008, at 12:16 AM, Stephane Bortzmeyer wrote: > On Tue, Feb 12, 2008 at 04:43:43PM -0600, > Francois Audet wrote > a message of 27 lines which said: > >> Correct. It is widely used. > > I was talking about its use on the public Internet (you do not need > TURN if you're entirely inside your own network). If I was inside my network and wanted to phone someone outside the network, I might need TURN. There also are plenty of internal networks that would need TURN for phone calls purely inside the internal network. _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 13 14:36:05 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C72D43A6EA1; Wed, 13 Feb 2008 14:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.196 X-Spam-Level: X-Spam-Status: No, score=-3.196 tagged_above=-999 required=5 tests=[AWL=-2.759, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZ7gJShM-HX4; Wed, 13 Feb 2008 14:36:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 091B03A67D9; Wed, 13 Feb 2008 14:36:05 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA3C33A67D9 for ; Wed, 13 Feb 2008 14:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIQlwIjCaFwk for ; Wed, 13 Feb 2008 14:36:03 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 977DC3A67D0 for ; Wed, 13 Feb 2008 14:36:01 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 13 Feb 2008 14:37:24 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1DMbOWv021416; Wed, 13 Feb 2008 14:37:24 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id m1DMbIPp015416; Wed, 13 Feb 2008 22:37:23 GMT From: Cullen Jennings To: "Alfred E. Heggestad" In-Reply-To: <47AC21E9.8030907@db.org> Impp: xmpp:cullenfluffyjennings@jabber.org References: <6F768FDE-A39E-47B1-932F-53FD905E8AB5@magma.ca> <47AC21E9.8030907@db.org> Message-Id: <3FC8CF05-440A-49DD-8AEB-3DBBC685CDFC@cisco.com> Mime-Version: 1.0 (Apple Message framework v915) Date: Wed, 13 Feb 2008 14:37:07 -0800 X-Mailer: Apple Mail (2.915) Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Behave WG , Philip Matthews Subject: Re: [BEHAVE] Summary of TURN open-issues call on 7 Feb 2008 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Feb 8, 2008, at 1:33 AM, Alfred E. Heggestad wrote: > Some SIP UAs have a configurable TOS-value for outgoing SIP and RTP > packets. is it likely that this value will change during a session? > No. There are some video systems that mark the packets for different parts of the video stream with different TOS values. The idea is to try and bias things so that the important parts of the video stream are not lost (Such as I frames). This would result in changing TOS values in a single session. _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 13 14:57:30 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 294E43A6FDE; Wed, 13 Feb 2008 14:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 tagged_above=-999 required=5 tests=[AWL=-2.611, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiNk3qijSPkO; Wed, 13 Feb 2008 14:57:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C4D43A68D4; Wed, 13 Feb 2008 14:57:29 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34F993A67D5 for ; Wed, 13 Feb 2008 14:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+uiPdAL5NQZ for ; Wed, 13 Feb 2008 14:57:27 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id CFE693A68D4 for ; Wed, 13 Feb 2008 14:57:24 -0800 (PST) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 13 Feb 2008 14:58:47 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m1DMwlUu001898; Wed, 13 Feb 2008 14:58:47 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id m1DMwjVh008974; Wed, 13 Feb 2008 22:58:46 GMT From: Cullen Jennings To: Philip Matthews In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org References: Message-Id: Mime-Version: 1.0 (Apple Message framework v915) Date: Wed, 13 Feb 2008 14:58:35 -0800 X-Mailer: Apple Mail (2.915) Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Behave WG , Dan Wing Subject: Re: [BEHAVE] TURN Issue: Re-using the 5-tuple X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org I'm a bit confused about this whole open issue so take this email with a huge grain of salt. Hopefully when I read it in the draft I will understand better. On Feb 12, 2008, at 9:28 AM, Philip Matthews wrote: > > On 19-Dec-07, at 10:14 , Marc Petit-Huguenin wrote: >> There is no explanation on what can be done after an allocation >> expires. >> Is it possible to create a new one from the same source IP and port? >> With the same username/realm/password? >> > > As I think more about this, I now think that the TURN server should > do the following: > 1) It should not reuse the relayed transport address, AND I wonder if you are over engineering this. I'm not sure I understand the case you are trying to fix with this right but ... Let's say I have a 10 minute permission/binding from device A, and device A is receiving streaming video, and I am 2 minutes into the permission when a power outage happens at my site. The devices at my site all reboot and a different device, device B, gets the IP that device A used to have. For the next several minutes, Device B is going to be getting the streaming video packets until the permission expires. It seems like we can't fix this but we are trying to fix a far more unlikely corner case. > > 2) It should reject attempts to re-use the 5-tuple > for some time after the allocation expires. I don't know what 5 tuple you are talking about here. If you have a have a music on hold server that used a fixed port and public IP, and you had a call where when you put me on hold then which transferred the audio stream to the music on hold server, then took me off hold, then put me back on, it seems like I might want to reuse the same 5 tuple. Anyways, I could be very confused here - I'm having a hard time following what is being proposed so my concern may be totally bogus. > > > Point (1) prevents data packets from the peer to the server from > being delivered to the wrong client. Point (2) prevents data packets > from the client to the server from being delivered to the wrong peer. > > I am thinking that the time should be either 2 minutes (as suggested > by Dan) or 4 minutes (2*MSL, which is what BEHAVE-TCP uses). > > Comments? > > - Philip > _______________________________________________ > Behave mailing list > Behave@ietf.org > http://www.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 13 17:21:51 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 775473A6C8F; Wed, 13 Feb 2008 17:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.116 X-Spam-Level: X-Spam-Status: No, score=0.116 tagged_above=-999 required=5 tests=[AWL=-1.524, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kk+do8p5xVPR; Wed, 13 Feb 2008 17:21:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B3073A682A; Wed, 13 Feb 2008 17:21:50 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C76B33A682A for ; Wed, 13 Feb 2008 17:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOUHuH32gFhk for ; Wed, 13 Feb 2008 17:21:48 -0800 (PST) Received: from mail-06.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id DAE363A67D0 for ; Wed, 13 Feb 2008 17:21:47 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JPSog-0005gr-1L for behave@ietf.org; Wed, 13 Feb 2008 20:23:10 -0500 Mime-Version: 1.0 (Apple Message framework v753) Message-Id: To: Behave WG From: Philip Matthews Date: Wed, 13 Feb 2008 20:23:05 -0500 X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] Subject: [BEHAVE] TURN: ALTERNATE-SERVER X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org TURN-06 contains the following text that describes how a TURN server can redirect a client to an alternate TURN server: When a server returns an error response, it MAY include an ALTERNATE- SERVER attribute if it has positive knowledge that the problem reported in the error response will not be a problem on the alternate server. For example, a 443 response (Invalid IP Address) with an ALTERNATE-SERVER means that the other server is responsible for that IP address. A 442 (Unsupported Transport Protocol) with this attribute means that the other server is known to support that transport protocol. A 507 (Insufficient Capacity) means that the other server is known to have sufficient capacity. Using the ALTERNATE-SERVER mechanism in the 507 (Insufficient Capacity) response can only be done if the rejecting server has definitive knowledge of available capacity on the target. This will require some kind of state sharing mechanism between TURN servers, which is beyond the scope of this specification. If a TURN server attempts to redirect to another server without knowledge of available capacity, it is possible that all servers are in a congested state, resulting in series of rejections that only serve to further increase the load on the system. This can cause congestion collapse. I now realize that there are a couple of problems with this text. First of all, this text applies only to the Allocate request; it doesn't make sense to redirect a Refresh or ChannelBind request, for example. More importantly, the text says that the referring server must have positive knowledge that the error that causes the problem won't occur on the alternate server, otherwise there may be redirect loops. However, there are three conditions under which a redirect might be appropriate: 442 (Unsupported Transport Protocol), 486 (Allocation Quota Reached) and 507 (Insufficient Capacity) [the 443 error is going away now that we have adopted Cullen's proposal]. If server X redirects the client to server Y because of a 442 error, and server Y redirects the client back to server X because of a 507 error, then we will still have a redirect loop. One possible fix is to require the redirecting server to have positive knowledge that the alternate server will not reject the request for ANY of the above conditions. However, an alternate fix is to rely on new text that was added to draft-ietf-behave-rfc3489bis (STUN) since the words above were written. That document now says: If the server has been redirected to a server on which it has already tried this request within the last five minutes, it MUST ignore the redirection and consider the transaction to have failed. This prevents infinite ping-ponging between servers in case of redirection loops. My proposal is to simply remind the TURN implementor of this (new) STUN requirement, and remove all the words about "positive knowledge" from the TURN spec. Comments? - Philip _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 13 18:04:21 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC58F3A6FF8; Wed, 13 Feb 2008 18:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.751 X-Spam-Level: X-Spam-Status: No, score=-0.751 tagged_above=-999 required=5 tests=[AWL=-0.314, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWI9GtZ+TPFj; Wed, 13 Feb 2008 18:04:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A914E3A6FD4; Wed, 13 Feb 2008 18:04:20 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21B0628C4F6 for ; Wed, 13 Feb 2008 18:04:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLIkK1FajB-s for ; Wed, 13 Feb 2008 18:04:18 -0800 (PST) Received: from mail-02.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 0C71E28C737 for ; Wed, 13 Feb 2008 18:03:55 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JPTTS-000173-1e; Wed, 13 Feb 2008 21:05:18 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Philip Matthews Date: Wed, 13 Feb 2008 21:05:12 -0500 To: Cullen Jennings X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] Cc: Behave WG , Dan Wing Subject: Re: [BEHAVE] TURN Issue: Re-using the 5-tuple X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Wed, 13-Feb-08, at 17:58 , Cullen Jennings wrote: > > I'm a bit confused about this whole open issue so take this email > with a huge grain of salt. Hopefully when I read it in the draft I > will understand better. I am working hard right now on getting TURN-07 out. All these little e-mails I am sending are arising from things that strike me as I work on it. With all the changes we have made, it will be another major revision ... > > On Feb 12, 2008, at 9:28 AM, Philip Matthews wrote: > >> >> On 19-Dec-07, at 10:14 , Marc Petit-Huguenin wrote: >>> There is no explanation on what can be done after an allocation >>> expires. >>> Is it possible to create a new one from the same source IP and port? >>> With the same username/realm/password? >>> >> >> As I think more about this, I now think that the TURN server should >> do the following: >> 1) It should not reuse the relayed transport address, AND > > I wonder if you are over engineering this. I'm not sure I > understand the case you are trying to fix with this right but ... > Let's say I have a 10 minute permission/binding from device A, and > device A is receiving streaming video, and I am 2 minutes into the > permission when a power outage happens at my site. The devices at > my site all reboot and a different device, device B, gets the IP > that device A used to have. For the next several minutes, Device B > is going to be getting the streaming video packets until the > permission expires. It seems like we can't fix this but we are > trying to fix a far more unlikely corner case. I suppose this could happen in an enterprise setting where the NAT or FW is on a UPS, but the DHCP server (a different box) is not. Not sure how likely this case is, but I also don't see any way to fix it. > >> >> 2) It should reject attempts to re-use the 5-tuple >> for some time after the allocation expires. > > I don't know what 5 tuple you are talking about here. If you have a > have a music on hold server that used a fixed port and public IP, > and you had a call where when you put me on hold then which > transferred the audio stream to the music on hold server, then took > me off hold, then put me back on, it seems like I might want to > reuse the same 5 tuple. Anyways, I could be very confused here - > I'm having a hard time following what is being proposed so my > concern may be totally bogus. This is the 5-tuple that describes the communication path between the client and the server: (client IP address, client port, server IP address, server port, transport protocol). This 5-tuple is one way to uniquely identify an allocation (the other way being the relayed transport address). I believe you are thinking of the 5-tuple that describes the communication path between the server and the peer. I don't think there is any problem in the scenario you are talking about -- but hey, I may be wrong. - Philip _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Feb 17 14:37:17 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95B223A6C00; Sun, 17 Feb 2008 14:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.811 X-Spam-Level: X-Spam-Status: No, score=-99.811 tagged_above=-999 required=5 tests=[AWL=-1.233, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W91IOxbCDyND; Sun, 17 Feb 2008 14:37:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 723133A69DF; Sun, 17 Feb 2008 14:37:14 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7754E3A6864 for ; Sun, 17 Feb 2008 14:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvMOibGRzr9c for ; Sun, 17 Feb 2008 14:37:11 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 23D3F3A6BEC for ; Sun, 17 Feb 2008 14:36:04 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 9468F7F1030; Sun, 17 Feb 2008 20:37:07 +0000 (UTC) Received: from [192.168.1.3] (c-71-202-183-123.hsd1.ca.comcast.net [71.202.183.123]) by server.implementers.org (Postfix) with ESMTP id 294D47F1036; Sun, 17 Feb 2008 20:31:17 +0000 (UTC) Message-ID: <47B89994.4020500@acm.org> Date: Sun, 17 Feb 2008 12:31:16 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080109) MIME-Version: 1.0 To: Jonathan Rosenberg References: <47B10B92.2070409@cisco.com> In-Reply-To: <47B10B92.2070409@cisco.com> Cc: Behave WG Subject: Re: [BEHAVE] Updated rfc3489bis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Hi Jonathan, Jonathan Rosenberg wrote: > I've just submitted an update to rfc3489bis: > > http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-14.txt > It seems that between -06 and -07 we lost the text that fixed the second issue discussed here: http://www.ietf.org/mail-archive/web/behave/current/msg01218.html It could be also a good thing to add examples for long-term authentication in draft-ietf-behave-stun-test-vectors. Thanks. -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Feb 19 01:18:42 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E83FE28C3E1; Tue, 19 Feb 2008 01:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[AWL=-1.352, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8AzCCx+S2PV; Tue, 19 Feb 2008 01:18:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6E4F3A6DD8; Tue, 19 Feb 2008 01:18:36 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 114033A6DD8 for ; Tue, 19 Feb 2008 01:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8P1zuM+wWO6 for ; Tue, 19 Feb 2008 01:18:34 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 0409C28C3E1 for ; Tue, 19 Feb 2008 01:18:32 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 19 Feb 2008 01:18:29 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1J9ITpm007088 for ; Tue, 19 Feb 2008 01:18:29 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m1J9ISuL005454 for ; Tue, 19 Feb 2008 09:18:28 GMT From: "Dan Wing" To: "'Behave WG'" Date: Tue, 19 Feb 2008 01:18:27 -0800 Message-ID: <059701c872d8$632dd6b0$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Achy2GLcGgY7etx2TueQD/lAREcFbQ== Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [BEHAVE] preliminary agenda posted X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org The preliminary agenda for BEHAVE is now at: http://www.ietf.org/proceedings/08mar/agenda/behave.html Please email me for changes or additions. -d _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 20 02:22:51 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B0D628C6F4; Wed, 20 Feb 2008 02:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.692 X-Spam-Level: X-Spam-Status: No, score=-0.692 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2gFGwNE14WW; Wed, 20 Feb 2008 02:22:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FFC13A696E; Wed, 20 Feb 2008 02:22:50 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50C1228C368 for ; Wed, 20 Feb 2008 02:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2TbzNvIqsmx for ; Wed, 20 Feb 2008 02:22:47 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 28E1928C713 for ; Wed, 20 Feb 2008 02:22:30 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1C62D215F0; Wed, 20 Feb 2008 11:22:26 +0100 (CET) X-AuditID: c1b4fb3e-aa9ffbb000000b15-13-47bbff62b9a2 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0C5022171C; Wed, 20 Feb 2008 11:22:26 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 11:21:50 +0100 Received: from [127.0.0.1] ([147.214.30.103]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 11:21:50 +0100 Message-ID: <47BBFF3E.1010705@ericsson.com> Date: Wed, 20 Feb 2008 11:21:50 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Philip Matthews References: <6F768FDE-A39E-47B1-932F-53FD905E8AB5@magma.ca> In-Reply-To: <6F768FDE-A39E-47B1-932F-53FD905E8AB5@magma.ca> X-OriginalArrivalTime: 20 Feb 2008 10:21:50.0326 (UTC) FILETIME=[67CE3160:01C873AA] X-Brightmail-Tracker: AAAAAA== Cc: Behave WG Subject: Re: [BEHAVE] Summary of TURN open-issues call on 7 Feb 2008 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Philip Matthews skrev: > > *) Preserving bits in the IP header > The attendees agreed to the following proposal: > * Do not set the DF bit if possible (some stacks supposedly always > set this bit) > * ECN bits are not copied > * TTL bits are not copied > * DSCP bits are copied if possible (it seems that some stacks allow > the DSCP bits to be read, but other do not) > * The document will discuss in detail the implications of the first > bullet on Path MTU Discovery > The motivation for this proposal has been discussed on the mailing list. > There was a brief discussion on whether to define a forwarding > behavior which mimics forwarding at the IP layer, but none of the > attendees was interested in work out or implementing this. > The attendees recognized that no all views on this issue were present > on the call, and so more discussion on this point might be necessary. > Hi, Sorry for being quite late on commenting on this. However, this is not acceptable. You are breaking IP functionality by this stated direction. I do understand that you are trying to do this in OS userland. But if OS userland doesn't support what you need to be doing, you can't use userland. You will need to work through this and for each field find what is acceptable to do or not. Some of these can probably be made to work in a compliant way combined with the correct relay behavior. For example ECN can be correctly handled if the all CE (Congestion Experienced) marked packets when they arrive are dropped by the relay. However, that is just as likely not implementable in user-land as copying the value from incoming to outgoing. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 20 03:18:35 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2B133A6B35; Wed, 20 Feb 2008 03:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.993 X-Spam-Level: X-Spam-Status: No, score=-0.993 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eka8OfvbrN5y; Wed, 20 Feb 2008 03:18:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C66F528C108; Wed, 20 Feb 2008 03:18:34 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64D6F3A6974 for ; Wed, 20 Feb 2008 03:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOMvgLYh01hw for ; Wed, 20 Feb 2008 03:18:32 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id 9D07128C108 for ; Wed, 20 Feb 2008 03:18:32 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 68D8E1C00E9; Wed, 20 Feb 2008 12:18:29 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 633461C00E0; Wed, 20 Feb 2008 12:18:29 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 553E358EBC5; Wed, 20 Feb 2008 12:18:29 +0100 (CET) Date: Wed, 20 Feb 2008 12:18:29 +0100 From: Stephane Bortzmeyer To: Magnus Westerlund Message-ID: <20080220111829.GA11647@nic.fr> References: <6F768FDE-A39E-47B1-932F-53FD905E8AB5@magma.ca> <47BBFF3E.1010705@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <47BBFF3E.1010705@ericsson.com> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-6-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Behave WG , Philip Matthews Subject: Re: [BEHAVE] Summary of TURN open-issues call on 7 Feb 2008 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Wed, Feb 20, 2008 at 11:21:50AM +0100, Magnus Westerlund wrote a message of 54 lines which said: > You are breaking IP functionality by this stated direction. I am, as always, very surprised by this argument. NAT breaks IP functionality. BEHAVE stuff tries to reestablish *some* of the functionality but it is certainly not realistic to hope that we could maintain 100 % of the end-to-end experience with BEHAVE protocols, specially with TURN, which is the furthest away from E2E IP! IMHO, "keeping IP functionality" is a non-goal. _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 20 03:33:35 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC7DA3A6927; Wed, 20 Feb 2008 03:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.458 X-Spam-Level: X-Spam-Status: No, score=0.458 tagged_above=-999 required=5 tests=[AWL=-0.801, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSmk1J8GyA-4; Wed, 20 Feb 2008 03:33:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D0AB3A6B14; Wed, 20 Feb 2008 03:33:35 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E621D3A696B for ; Wed, 20 Feb 2008 03:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01gMKl8u6Qxn for ; Wed, 20 Feb 2008 03:33:33 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id D60E83A67DF for ; Wed, 20 Feb 2008 03:33:32 -0800 (PST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1KBXIW0029467; Wed, 20 Feb 2008 13:33:26 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 13:33:23 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 13:33:22 +0200 Received: from esdhcp041109.research.nokia.com ([172.21.41.109]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 13:33:22 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Date: Wed, 20 Feb 2008 13:33:26 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <6F768FDE-A39E-47B1-932F-53FD905E8AB5@magma.ca> <47BBFF3E.1010705@ericsson.com> <20080220111829.GA11647@nic.fr> In-Reply-To: <20080220111829.GA11647@nic.fr> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200802201333.26469.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 20 Feb 2008 11:33:22.0804 (UTC) FILETIME=[66525B40:01C873B4] X-Nokia-AV: Clean Cc: Philip Matthews Subject: Re: [BEHAVE] Summary of TURN open-issues call on 7 Feb 2008 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Le Wednesday 20 February 2008 13:18:29 ext Stephane Bortzmeyer, vous avez = =E9crit=A0: > On Wed, Feb 20, 2008 at 11:21:50AM +0100, > Magnus Westerlund wrote > > a message of 54 lines which said: > > You are breaking IP functionality by this stated direction. > > I am, as always, very surprised by this argument. NAT breaks IP > functionality. BEHAVE stuff tries to reestablish *some* of the > functionality but it is certainly not realistic to hope that we could > maintain 100 % of the end-to-end experience with BEHAVE protocols, > specially with TURN, which is the furthest away from E2E IP! Do you know any NAT that does anything *except* one of the the following wi= th = the TOS bits: - leave them unmodified, or - reset them to zero. Do you know any NAT that does anything *except* one of the the following wi= th = the TTL: - decrement it by one unit (and discard the packet if 0), or - leave it unmodified. Certainly, if NATs commonly break down upon seeing TOS, we should force the= m = to zero. However as a matter of fact, I've been using TOS on my NAT'ed home = network for the sake of fair queuing, and it works great, and I would rathe= r = keep it. In any case, it would seem from earlier discussions that some peop= le = *DO* use TOS with traffic that may eventually be relayed with TURN. As for IP fragmentation, there are many ways NAT may screw it up, but we = cannot really ignore the problem. > IMHO, "keeping IP functionality" is a non-goal. I thought the goal of TURN was to restore IP functionality. -- = R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 20 05:24:10 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 291B528C81B; Wed, 20 Feb 2008 05:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6dzJL98nBkA; Wed, 20 Feb 2008 05:24:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25EDE28C7DA; Wed, 20 Feb 2008 05:24:09 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A23E28C807 for ; Wed, 20 Feb 2008 05:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIy0EwrqnzZw for ; Wed, 20 Feb 2008 05:24:05 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 16E5328C465 for ; Wed, 20 Feb 2008 05:24:05 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 829AB21852; Wed, 20 Feb 2008 14:24:00 +0100 (CET) X-AuditID: c1b4fb3e-a81fabb000000b15-29-47bc29f0b000 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6E7CA2167B; Wed, 20 Feb 2008 14:24:00 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 14:23:42 +0100 Received: from [127.0.0.1] ([147.214.30.103]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 14:23:42 +0100 Message-ID: <47BC29DE.5070008@ericsson.com> Date: Wed, 20 Feb 2008 14:23:42 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Stephane Bortzmeyer References: <6F768FDE-A39E-47B1-932F-53FD905E8AB5@magma.ca> <47BBFF3E.1010705@ericsson.com> <20080220111829.GA11647@nic.fr> In-Reply-To: <20080220111829.GA11647@nic.fr> X-OriginalArrivalTime: 20 Feb 2008 13:23:42.0524 (UTC) FILETIME=[CFFB77C0:01C873C3] X-Brightmail-Tracker: AAAAAA== Cc: Behave WG , Philip Matthews Subject: Re: [BEHAVE] Summary of TURN open-issues call on 7 Feb 2008 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Stephane Bortzmeyer skrev: > On Wed, Feb 20, 2008 at 11:21:50AM +0100, > Magnus Westerlund wrote > a message of 54 lines which said: > >> You are breaking IP functionality by this stated direction. > > I am, as always, very surprised by this argument. NAT breaks IP > functionality. BEHAVE stuff tries to reestablish *some* of the > functionality but it is certainly not realistic to hope that we could > maintain 100 % of the end-to-end experience with BEHAVE protocols, > specially with TURN, which is the furthest away from E2E IP! > > IMHO, "keeping IP functionality" is a non-goal. So you argue that TURN should break things that aren't broken or only minor problematic in IP simply because NATs where so badly standardized. So any bad thing done previously is a allowing for all future continue to do bad things. I don't think so, or at least not on my watch. Please accept that TURN will not be able to advance until the specification explicitly discuss how to threat the IP and transport header fields when relaying. And I do expect that these description are compatible with the specification of these fields. Regards Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 20 06:58:22 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 719A528C1A1; Wed, 20 Feb 2008 06:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.732 X-Spam-Level: X-Spam-Status: No, score=-0.732 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvIgqLlgSVdk; Wed, 20 Feb 2008 06:58:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 991DB28C14A; Wed, 20 Feb 2008 06:58:21 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE5873A6E6B for ; Wed, 20 Feb 2008 06:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3yYU3wKhG+w for ; Wed, 20 Feb 2008 06:58:20 -0800 (PST) Received: from mail-09.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id EF1733A6E5F for ; Wed, 20 Feb 2008 06:58:19 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JRqOm-00025Z-2Z; Wed, 20 Feb 2008 09:58:16 -0500 In-Reply-To: <47B89994.4020500@acm.org> References: <47B10B92.2070409@cisco.com> <47B89994.4020500@acm.org> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <7046FC57-9F58-47DF-9A38-1631A0077EE3@magma.ca> From: Philip Matthews Date: Wed, 20 Feb 2008 09:58:11 -0500 To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] Cc: Behave WG Subject: Re: [BEHAVE] Updated rfc3489bis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Sun, 17-Feb-08, at 15:31 , Marc Petit-Huguenin wrote: > Hi Jonathan, > > Jonathan Rosenberg wrote: >> I've just submitted an update to rfc3489bis: >> >> http://www.ietf.org/internet-drafts/draft-ietf-behave- >> rfc3489bis-14.txt >> > > It seems that between -06 and -07 we lost the text that fixed the > second > issue discussed here: > > http://www.ietf.org/mail-archive/web/behave/current/msg01218.html I will let Jonathan address this issue since he is handling STUN right now. > > It could be also a good thing to add examples for long-term > authentication in draft-ietf-behave-stun-test-vectors. This sounds like a good idea. > > > Thanks. > > -- > Marc Petit-Huguenin [ ] > Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] > Work: marc@8x8.com [ ] > [ ] > _______________________________________________ > Behave mailing list > Behave@ietf.org > http://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 20 07:43:20 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4954D28C80A; Wed, 20 Feb 2008 07:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.723 X-Spam-Level: X-Spam-Status: No, score=-0.723 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otzwYiPcXV8N; Wed, 20 Feb 2008 07:43:19 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3648428C7B7; Wed, 20 Feb 2008 07:43:19 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70F7128C7DA for ; Wed, 20 Feb 2008 07:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5qrKuimVKbm for ; Wed, 20 Feb 2008 07:43:16 -0800 (PST) Received: from mail-08.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 3DA3728C14A for ; Wed, 20 Feb 2008 07:43:16 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-08.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JRr6E-0008DJ-2C; Wed, 20 Feb 2008 10:43:13 -0500 In-Reply-To: <479B3E75.8030407@acm.org> References: <479B3E75.8030407@acm.org> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Philip Matthews Date: Wed, 20 Feb 2008 10:43:04 -0500 To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] Cc: Behave WG Subject: Re: [BEHAVE] Comments on TURN-06 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Marc: Thanks for the comments. And sorry to be slow in responding. I was busy working on TURN-07, which is now almost done. On Sat, 26-Jan-08, at 09:06 , Marc Petit-Huguenin wrote: > 1. Section 5.2.1.2: "If the request did not contain a > REQUESTED-TRANSPORT attribute, the server MUST use the same transport > protocol as the request arrived on." > > As TURN-06 only defines the usage of UDP between the server and the > peer, I do not see how to implement this. UDP should be the > default if > there is no REQUESTED-TRANSPORT attribute. I have totally rewritten this section. Elsewhere TURN-06 required the Allocate request to contain a REQUESTED-TRANSPORT attribute, so I went with that approach instead. TURN-07 currently says that the client MUST request UDP, and the server will reject any protocols it doesn't support. > > > 2. Section 5.2.1.6: "Note that the LIFETIME attribute in an Allocate > request can be zero, though this is effectively a no-op, since it will > create and destroy the allocation in one transaction." > > I saw that section 5.2.1.5 now allow the server to reject too short > values of LIFETIME, which is good. Let's also reject a LIFETIME value > of 0 in the Allocate request. TURN-07 now takes a more radical approach. Allocation lifetimes now default to 10 minutes. Clients can ask the server to increase this, but the server ignores any requests to decrease it. I didn't see any real need for shorter lifetimes. > > > 3. Section 5.2.2: "If its associated Allocate request contained the > BANDWIDTH attribute, or this Refresh request contained a new BANDWIDTH > attribute, the response MUST also contain the BANDWIDTH attribute." > > I think that this is inconsistent with what is said in section > 5.2.1.7, > were a BANDWIDTH attribute is always added to the response. I think > that it should be the same for the Refresh response. Currently in TURN-07, the BANDWIDTH attribute is always included in the response. > > > 4. Section 6.2: "Any other attributes appearing in the message are > treated as unexpected." > > I am not sure what this means, but I hope that this is not meant to > override rfc3489bis-13 section 7.3.2, i.e. to consider all other > attributes as comprehension-required attributes and to discard the > indication if any other attribute appears in the message. I would > suggest to remove this sentence completely. It was not meant to override that section. Jonathan complained about this too, so I have remove that sentence. > > > 5. Section 17.1, issue #2: "...under the assumption that the IT > administrator will only allow clients to contact those servers that > implement whatever permission policy the IT administrator can accept?" > > And how the IT administrator knows that the contacted server > implements > the correct permission policy, if the server is not in the domain > managed by IT and TLS is used between the client and the server? My idea was that the IT admin would config the firewall to only allow TURN traffic to certain IP addresses. But no one seemed to like this idea on the conf calls, so I have dropped it. > > > 6. Section 17.1, issue #3: "Port Adjacency" > > I do not see what the big deal is with this issue. The first Allocate > binds multiple ports and returns the first one. If it cannot, then > the > Allocate fails. Other Allocate requests from different tuples > authenticated with the same credentials can explicitly request the > additional ports. If the additional ports are never requested, > they are > deallocated at the same time the first port is deallocated. And this > mechanism can be extended in the future by using the remaining bits in > REQUESTED-PORTS to some other exotic allocation schemes, like > requesting > multiple contiguous ports, or multiple ports that are all subsequent > prime numbers or whatever. TURN-07 uses a slightly modified version of Cullen's proposal for port properties. This is as per our conf call discussions. > > > 7. Section 17.1, issue #10: "Allowed PEER-ADDRESS values" > > The problem is not what is allowed in a PEER-ADDRESS attribute, but > what > values of PEER-ADDRESS are valid for this specification. I suggest to > explicitly say in the spec that the usage of multicast addresses, > broadcast addresses and 0.0.0.0 address is not defined in this spec > (but > can be in extensions) and that a Send indication with this addresses > will be dropped and a Bind Channel request will be rejected. The PEER-ADDRESS attribute is now gone (as per Cullen's proposal), though I have re-used the codepoint for the new RESERVATION-TOKEN attribute that conveys the token in Cullen's proposal. > > > 8. Section 17.1, issue #13: "Re-using the 5-tuple" > > A client should be able to reuse the same tuple immediately, with same > or different credentials. Currently, TURN-07 requires a 2 minute delay in re-using the 5-tuple, as per my e-mail on the subject a week or so ago. > > > 9. Section 17.1, issue #14: "Password change" > > TURN, especially when used with SIP, is different from other > authenticated protocols like HTTP, IMAP, POP in that the allocation > can > have a very long lifetime (excepted when SIP use the charged-by-minute > model of the PSTN). So I think that we should define in the spec what > happen when the password change. > > I think that the right solution would be to reject the next Refresh so > the user is prompted for a new password. The remaining allocation > lifetime should be displayed to the user so s/he knows that the > allocation will expire if s/he does not enter the new password timely. TURN-07 adopts Rohan's proposal to not say anything about this, except that a couple of MUSTs were changed to SHOULDs to allow a mechanism to be added. > > > Thanks. > > -- > Marc Petit-Huguenin [ ] > Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] > Work: marc@8x8.com [ ] > Again, thanks for the comments. - Philip _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 20 08:26:33 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16C5428C818; Wed, 20 Feb 2008 08:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrGkjF0KuPqp; Wed, 20 Feb 2008 08:26:31 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0D6A28C1BE; Wed, 20 Feb 2008 08:26:31 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4C4428C1BE for ; Wed, 20 Feb 2008 08:26:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tbrh8Kiu0Io5 for ; Wed, 20 Feb 2008 08:26:29 -0800 (PST) Received: from mail-06.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 2433A28C1B4 for ; Wed, 20 Feb 2008 08:26:29 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JRrm5-0002df-1N; Wed, 20 Feb 2008 11:26:26 -0500 In-Reply-To: <20080126232920.7DBF75081A@romeo.rtfm.com> References: <20080126232920.7DBF75081A@romeo.rtfm.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <2A72CA4E-35C5-4B34-B8E4-72A03CDA70C6@magma.ca> From: Philip Matthews Date: Wed, 20 Feb 2008 11:26:21 -0500 To: Eric Rescorla X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] Cc: behave@ietf.org Subject: Re: [BEHAVE] Review of draft-ietf-behave-turn-06 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Sat, 26-Jan-08, at 18:29 , Eric Rescorla wrote: > $Id: draft-ietf-behave-turn-06-rev.txt,v 1.1 2008/01/26 23:08:30 > ekr Exp $ > > > TECHNICAL > S 4. > The ALTERNATE-SERVER stuff seems problematic for the reasons > Cullen indicates. If you're overloaded, better ot simply not > handle the request and let ordinary H-A methods take over. I have simplified the ALTERNATE-SERVER stuff in TURN-07, but left it in for now. See my e-mail of a week ago on the subject. However, I have no strong attachment to it, and left it in only because I thought there were some who still wanted it. It is listed as one of the (currently 2) open issues remaining in the document. > > > S 5.1.1. > If the response is an error response and contains a 442, 443 or 444 > error code, the client knows that its requested properties could > not > be met. The client MAY retry with different properties, with the > same properties (in a hope that something has changed on the > server), > or give up, depending on the needs of the application. However, if > the client retries, it SHOULD wait 500ms, and if the request fails > again, wait 1 second, then 2 seconds, and so on, exponentially > backing off. > > I don't see the purpose of this. This kind of backoff is gnenerally > used for congestion control, but if you're getitng errors you know > that the packets weren't lost, so why back off? I have made major changes in this area to try to bring some clarity to the various ways a client can try to recover from an Allocate error response. The text currently says that a client must wait at least one minute before retrying the request (except for a 442, which is not likely to change). In the meantime, the client can try a different server. > > S 5.1.2. > This 3/4 guidance seems like it's inappropriate in a number of > respects. Why not simply indicate that clients need to leave > some time for the refresh. > > The idea of refreshing with different bandwidth requested > seems problematic. What happens if the server refuses? Do you > need to refresh again with a lower bandwidth if you're willing > to live with that? A policy that refreshes didn't change anything > seems more sensible. I have changed the default allocation lifetime to 10 minutes, which the client can increase but not decrease. So the current text recommends refreshing the allocation 1 minute before it expires. You can still change the bandwidth on a refresh. If the client asks for less bandwidth, the bandwidth goes down. If the client asks for more bandwidth, the server tries to accommodate. If the bandwidth is currently 10 and the clients asks for 20 but the server can only do 15, then the bandwidth is set to 15. Even if the bandwidth cannot be increased at all, the request still succeeds. Having said this, bandwidth is still the biggest open issue in the document. I haven't had the time to focus on it, so I just wrote something that was vaguely reasonable while I fixed the rest of the document. I expect to have extensive discussions on bandwidth once TURN-07 gets out. > > S 5.2.1. > o If the transport protocol is UDP, and the transaction id in the > request message matches the transaction id used for the original > allocation, then the server treats this as a retransmission > of the > original request, and replies with the same response as it > did to > the original request. The server may do this by either storing > its original response and resending it, or by rebuilding its > original response from other state data. > > This is a new requirement that's not in STUN (The stun reqt is 10 > seconds) and seems impractical to implement. If I throw an error on a > transaction, how long do I need to be willing to return the same > error? Forever? What seems appropriate here is that as long as an > allocation exists (And maybe for X seconds afterward) you need > to return the same response. We discussed this on the conf call. We will weaken the STUN requirement to make the above implementation ok. And I don't see your point about an error: we are talking about a retransmission of the Allocate request here. If the first copy generated an error, then the allocation would not be created and the above mechanism does not come into play. So the first copy must have succeeded, and the problem is only that the success response got lost. > > > S 5.2.1.1. > If it does, the server attempts to allocate a transport address for > the client. The Allocate Request can contain several additional > attributes that allow the client to request specific > characteristics > of the transport address. If it doesn't, it sends an error > response. > > What error? This section has been totally rewritten. Cullen's proposal is now used, and appropriate error responses are specified. > > > S 5.2.1.4. > So, I get that you would want an even port for RTP and consecutive > ports for RTP/RTCP, but are there any implementations which > need arbitrary odd ports? As per our conf call, odd ports can no longer be requested. > > > S 6.3. > This section contains way too much information about the UDP datagram > (Length, Checksum...) It should simply specify that a UDP datagram > with the following contents is sent to the following location as per > standard procedure. I have left this for now. Much of this detail was in previous versions of TURN, abeit in different words in a different part of the text. > > > S 7.7. > When the server receives a valid ChannelData message, it forms a > UDP > datagram as follows: the source transport address is the relayed > transport address of the allocation, where the allocation is > determined by the 5-tuple on which the ChannelData message arrived; > the destination transport address is the peer address to which the > channel is bound; the data following the UDP header is the contents > of the data field of the ChannelData message; the Length field > in the > UDP header is set to the Length field of the ChannelData message > + 8; > and the Checksum field in the UDP header is computed as > described in > > > Again, too much information about the UDP header.. See comment above. > > > EDITORIAL > Abstract: > Is TURN really "more properly" used as part of ICE? The idea is that you should really be using TURN with ICE. Can you suggest alternate text that expresses this? > > S 1. > The only way to obtain a UDP transport address that can be used for > corresponding with a peer through such a NAT is to make use of a > relay. > > Well, actually, the only reliable way. You mgiht guess correctly. OK. I added "reliable". > > S 2.5. > the client can determine the peer that send the UDP datagram. > > s/send/sends/ This text is not in TURN-07. > > S 4. > After the initial Allocate transaction, all subsequent TURN > transactions need to be sent in the context of a valid allocation. > The source and destination IP address and ports for these TURN > messages MUST match the those used in the initial Allocate Request. > > I'm not sure what "in the context means". The seconds sentence seems > clearer. TURN-07 spells out the rules around this in greater detail. > > > S 5.2.1.7. > This section would be imroved by having the required attributes being > a bulleted list. This section has been completely rewritten. Lists are used to describe both the checks that need to be done, and the attribute that must be included in the response. > > S 6. > Merging send and data indications (which are basically unrelated) into > a single section is really confusing. It would be better to give them > separate sections. This section was rewritten to try to make client and server behavior clearer. Send and Data indications are now described separately. > > There should be some explicit statement of what missing DATA > attributes > are for (keepalives). There is now an explicit statement. > > S 7. > As described in the overview, channel mechanism provides a way > for a > client and server to send application data using ChannelData > > s/channel mechanism/the channel mechanism/ I have rewritten this section to try to clarify how things work. This sentence vanished in the rewrite. > > > S 7.1. > > Over UDP, the client SHOULD NOT send ChannelData messages on the > channel until it has received a ChannelBind Success Response for > the > binding attempt. Sending them before the success response is > received risks having them dropped by the server if he ChannelBind > Request was lost. > > I think we discussed this onlist. This text was moved up one level and rewritten. It now says: In the other direction, the client MAY elect to send ChannelData messages before receiving the ChannelBind success response. Doing so, however, runs the risk of having the ChannelData messages dropped by the server if the ChannelBind request does not succeed for some reason (e.g., packet lost if the request is sent over UDP, or the server being unable to fulfill the request). A client that wishes to be safe should either queue the data, or use Send indications until the channel binding is confirmed. I think this captures what we agreed to on the conference call. > > > > S 11. > discovery. As a consequence, TURN runs on a separate port from > STUN. > The client discovers the address and port of the TURN server using > the same DNS procedures defined in [I-D.ietf-behave-rfc3489bis], > but > using an SRV service name of "turn" (or "turns" for TURN over TLS) > > Didn't we get rid of separate ports? By default, TURN now runs on the same port as STUN. This can be changed using the SRV procedures, or using ALTERNATE-SERVER. > > > S 12. > TURN cannot be used by clients for subverting firewall policies. > > This is untrue, as acknowledged in the section on using TLS. I think this is mostly true, which is why we have all the restrictions on how TURN can be used. Do you have a proposed replacement for this sentence? > > > > -Ekr - Philip _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 20 08:40:36 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B94A3A6E74; Wed, 20 Feb 2008 08:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.238 X-Spam-Level: X-Spam-Status: No, score=-0.238 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNSlxtyRiSlS; Wed, 20 Feb 2008 08:40:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 560963A6E49; Wed, 20 Feb 2008 08:40:35 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0450C3A6A26 for ; Wed, 20 Feb 2008 08:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+NUlpLZ1J59 for ; Wed, 20 Feb 2008 08:40:33 -0800 (PST) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 34F6D3A69AF for ; Wed, 20 Feb 2008 08:40:33 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 443335081A; Wed, 20 Feb 2008 08:42:18 -0800 (PST) Date: Wed, 20 Feb 2008 08:42:18 -0800 From: Eric Rescorla To: Philip Matthews In-Reply-To: <2A72CA4E-35C5-4B34-B8E4-72A03CDA70C6@magma.ca> References: <20080126232920.7DBF75081A@romeo.rtfm.com> <2A72CA4E-35C5-4B34-B8E4-72A03CDA70C6@magma.ca> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080220164218.443335081A@romeo.rtfm.com> Cc: behave@ietf.org Subject: Re: [BEHAVE] Review of draft-ietf-behave-turn-06 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org At Wed, 20 Feb 2008 11:26:21 -0500, Philip Matthews wrote: > On Sat, 26-Jan-08, at 18:29 , Eric Rescorla wrote: > > > $Id: draft-ietf-behave-turn-06-rev.txt,v 1.1 2008/01/26 23:08:30 > > ekr Exp $ > > > > > > TECHNICAL > > S 4. > > The ALTERNATE-SERVER stuff seems problematic for the reasons > > Cullen indicates. If you're overloaded, better ot simply not > > handle the request and let ordinary H-A methods take over. > > I have simplified the ALTERNATE-SERVER stuff in TURN-07, but left it > in for now. See my e-mail of a week ago on the subject. However, I > have no strong attachment to it, and left it in only because I > thought there were some who still wanted it. It is listed as one of > the (currently 2) open issues remaining in the document. Can those who are in favor of this speak up? > I have made major changes in this area to try to bring some clarity > to the various ways a client can try to recover from an Allocate > error response. The text currently says that a client must wait at > least one minute before retrying the request (except for a 442, which > is not likely to change). In the meantime, the client can try a > different server. Again, I'd like to understand why you need to wait at all? > > S 6.3. > > This section contains way too much information about the UDP datagram > > (Length, Checksum...) It should simply specify that a UDP datagram > > with the following contents is sent to the following location as per > > standard procedure. > > I have left this for now. Much of this detail was in previous > versions of TURN, abeit in different words in a different part of the > text. Sure, so I should have caught it before, but that doesn't make it more right. > > EDITORIAL > > Abstract: > > Is TURN really "more properly" used as part of ICE? > > The idea is that you should really be using TURN with ICE. Can you > suggest alternate text that expresses this? I don't see why we should be expressing this sentiment at all. > > S 12. > > TURN cannot be used by clients for subverting firewall policies. > > > > This is untrue, as acknowledged in the section on using TLS. > > I think this is mostly true, which is why we have all the > restrictions on how TURN can be used. > Do you have a proposed replacement for this sentence? "TURN attempts to adhere as closely as possible to common firewall policies, consistent with allowing data to flow. For instance, TURN cannot be used to implement an ordinary server such as a a Web or SMTP server." -Ekr _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 20 08:59:37 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C18828C226; Wed, 20 Feb 2008 08:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.383 X-Spam-Level: X-Spam-Status: No, score=-1.383 tagged_above=-999 required=5 tests=[AWL=-0.946, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-2GwNFs9bBg; Wed, 20 Feb 2008 08:59:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61A0128C22D; Wed, 20 Feb 2008 08:59:36 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81E0028C226 for ; Wed, 20 Feb 2008 08:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnMftaC06sRV for ; Wed, 20 Feb 2008 08:59:34 -0800 (PST) Received: from mail.sipeerior.com (mail.sipeerior.com [128.239.5.131]) by core3.amsl.com (Postfix) with ESMTP id B11353A6E49 for ; Wed, 20 Feb 2008 08:59:34 -0800 (PST) Received: from [128.239.5.143] (unknown [128.239.5.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sipeerior.com (Postfix) with ESMTP id 45057505AE2; Wed, 20 Feb 2008 11:59:31 -0500 (EST) In-Reply-To: <47B10B92.2070409@cisco.com> References: <47B10B92.2070409@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Bruce Lowekamp Date: Wed, 20 Feb 2008 11:59:30 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.753) Cc: Behave WG Subject: Re: [BEHAVE] Updated rfc3489bis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Feb 11, 2008, at 9:59 PM, Jonathan Rosenberg wrote: > > * maximum STUN message size now set to 576 bytes for v4, 1280 for v6, > when pmtu is unknown. It was previously 1500 when pmtu is unknown. > This breaks the PADDING attribute of nat-behavior-discovery that is intended to help probe fragment handling. Can this be changed to a SHOULD? Alternatively, leave it a MUST but include some text to the effect that STUN usages MAY specify exceptions to this rule? > > * clarified that, STUN over TCP is unframed when talking to a server > you learned through dns or on the default port. Use of framing is > only in cases where you have negotiated such as part of the usage - > i.e., ICE connectivity checks. > I like this text better. I think this text addresses my previous concerns on that issue. Bruce _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 20 09:16:33 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3CE328C73A; Wed, 20 Feb 2008 09:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.467 X-Spam-Level: X-Spam-Status: No, score=0.467 tagged_above=-999 required=5 tests=[AWL=-0.792, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+aO5oBPzvQ7; Wed, 20 Feb 2008 09:16:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCB1E28C5AB; Wed, 20 Feb 2008 09:16:32 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A31728C5AB for ; Wed, 20 Feb 2008 09:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bf5Gl1Zpul7v for ; Wed, 20 Feb 2008 09:16:30 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id E536928C36B for ; Wed, 20 Feb 2008 09:16:29 -0800 (PST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1KHGCl3023099; Wed, 20 Feb 2008 19:16:17 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 19:07:38 +0200 Received: from esdhcp041109.research.nokia.com ([172.21.41.109]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 19:07:37 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Date: Wed, 20 Feb 2008 19:07:41 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <47B10B92.2070409@cisco.com> In-Reply-To: <47B10B92.2070409@cisco.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200802201907.41353.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 20 Feb 2008 17:07:37.0959 (UTC) FILETIME=[18202770:01C873E3] X-Nokia-AV: Clean Subject: Re: [BEHAVE] Updated rfc3489bis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Le Tuesday 12 February 2008 04:59:30 ext Jonathan Rosenberg, vous avez =E9c= rit=A0: > * maximum STUN message size now set to 576 bytes for v4, 1280 for v6, > when pmtu is unknown. It was previously 1500 when pmtu is unknown. Should it not be clarified that this is the IP-layer datagram size, not = the "STUN message size"? In other words, the maximumem STUN message size is = 548 bytes minus would-be IPv4 options resp. 1232 bytes minus would-be IPv6 = extension headers? -- = R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 20 10:10:30 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A87628C8D5; Wed, 20 Feb 2008 10:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.254 X-Spam-Level: X-Spam-Status: No, score=0.254 tagged_above=-999 required=5 tests=[AWL=-1.149, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+wWUejcEjFA; Wed, 20 Feb 2008 10:10:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CDC428C53E; Wed, 20 Feb 2008 10:10:28 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60B3C28C418 for ; Wed, 20 Feb 2008 10:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mwTxVkKQK9B for ; Wed, 20 Feb 2008 10:10:26 -0800 (PST) Received: from mail-05.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 9BBC928C53E for ; Wed, 20 Feb 2008 10:10:25 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JRtNo-0001vW-0J; Wed, 20 Feb 2008 13:09:28 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <1C49A51F-1E08-41E8-880B-9BF7C8C1D865@magma.ca> From: Philip Matthews Date: Wed, 20 Feb 2008 13:10:18 -0500 To: Cullen Jennings X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] Cc: Behave WG Subject: Re: [BEHAVE] TURN 06 Comments X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Cullen: Thanks for your comments. Sorry to be slow in responding. Some of your comments have been overtaken by subsequent discussions, but I have made some changes in the document as a result of others. See more in-line. On Fri, 25-Jan-08, at 01:39 , Cullen Jennings wrote: > > Gave the document a quick skim. Few comments .... > > > The whole design of refreshing and lifetimes of allocations and > permissions seems very disjoint and sub optimal. I would be > tempted to go with allocation go away 30 seconds after they have no > valid permissions. Permissions can be updated by client sending > data or zero length send. Permissions durations match BEHAVE UDP > documents. Personally, I like your idea that allocations go away 30 second after the last permission. However, on the last conf call, so one else was in favor. People wanted to keep the explicit refresh mechanism for allocations. One reason to keep this is that it provides a way to change the allocation bandwidth, which is (currently) another TURN feature. So I have make the following changes instead: * Permission lifetime is 5 minutes, fixed. * Channel lifetime is 10 minutes, fixed. * Allocation lifetime is 10 minutes, adjustable. The client can increase the allocation lifetime, but cannot decrease it. For refreshing: * Permissions are refreshed by sending data to that IP address, or with a Data indication with no DATA attribute. * Channels are refreshed by sending data on that channel, or by rebinding the channel to the same peer. * Allocations are refreshed using the Refresh transaction. IMO, this simplifies things and gets rid of silly things like a 20 second allocation lifetime. > > Much of the discussions around permissions make them sound like > they are not bound to a specific allocation and instead the > permissions is granted to the whole TURN server. This needs to be > cleaned up. (Normative stuff looks right). I have rewritten section 2.5 in the Overview of Operation section. It now says: 2.5. Permissions To ease concerns amongst enterprise IT administrators that TURN could be used to bypass corporate firewall security, TURN includes the notion of permissions. TURN permissions mimic the address- restricted filtering mechanism of NATs that comply with [RFC4787]. If the client has send data to a peer (via the server) within the last 5 minutes, then any peer with the same IP address (the port numbers can differ) is permitted to send data to the client. After 5 minutes, the permission times out and the server drops any UDP datagrams arriving at the relayed transport from that IP address. Note that permissions are within the context of an allocation, so adding or expiring a permission in one allocation does not affect other allocations. Data received from the peer DOES NOT refresh the permission. In addition, there is now a new section in the normative portion of the document that goes into detail on how permissions work. Other sections now reference that section whenever they mention one of they ways that a client can establish/refresh a permission. > > I view the whole redirect to another TURN server as a really bad > idea. Not to mention that it conflicts with the 3489 usage of this > but even worse, it is highly likely to cause things to fail during > overload in a way where the overloaded machine gets bounced around > and the system never recovers. I think the SRV mechanisms are > sufficient for load balancing, work well, and we should get rid of > this stuff. I have simplified the text, but have left it in for now. But I have flagged it as an open issue. Personally, I am happy to take it out if no one want it. > > Not a big deal but I don't like the waiting to 3/4 of LIFETIME, If > the lifetime is 7200 this is way too early - I would prefer > something more like LIFETIME minus 5 seconds and some introduction > of jitter. The text now recommends 1 minute before the allocation expires (out of min 10 minute allocation lifetime). I think 5 seconds before is too short. > > section 5.2, 2nd bullet point. It looks like it always replies with > 437 to a request over TCP. I might just be reading this wrong. This section has been rewritten. I think the problem has gone away. > > Bandwidth - section 5.2.1.1 I would not want to use the words" > determines if there is sufficient capacity" as this may be very > hard to do, instead something like "decide if willing to grant this > bandwidth". The contract is not guaranteeing a minimum, it is > setting a max and suggesting a best attempts will be made to do > minimum, We still need to specify the algo for computing this. The text now uses the word "grant". It also points out that all this is really placeholder text and that we still need to work out the details. > > Section 5.2.1.4: One of the key design points of this protocols is > that you can not use it to pick an arbitrary port number to run > over. This seems to change that and that is one of the things I > feel very strong about. You need to support paired ports for RTP/ > RTCP because TURN is the last line of defense that is supposed to > always work. I am fine with a protocol where the client asks for a > pair and gets X and knows that X+1 is reserved and then requests X > +1. I am not ok with a protocol where the client gets to choose the > port the server uses. TURN now uses your proposed mechanism, though I changed the encoding details slightly. > > 5.2.1.6, 2nd para. The idea that "standard services" run on ports > below 1024 does not seem true. What words would you say here? > > Section 6.3 - This should be reworded to say what goes in the UDP > payload and then a UDP packets is sent. Once we start talking about > forming UDP checksums, it is a sign something is not right :-) OK, OK!! After your and EKR's comments, I have removed the last two bullets. The text now says: If the received Send indication contains a DATA attribute, then it forms a UDP datagram as follows: o the source transport address is the relayed transport address of the allocation, where the allocation is determined by the 5-tuple on which the Send Indication arrived; o the destination transport address is taken from the PEER-ADDRESS attribute; o the data following the UDP header is the contents of the value field of the DATA attribute. The resulting UDP datagram is then sent to the peer. If any errors are detected during this process (e.g., the Send indication does not contain a PEER-ADDRESS attribute), the received indication is silently discarded and no UDP datagram is sent. I made a similar change in the section on channels. > > Section 7.5, first para. Where you have SHOULD use the Channel- > Data, I think that has to be a MUST. The server has no way of > knowing what the clients bandwidth issues are thus cannot make a > reasonable determination. I have changed it to a "MUST". > > Section 2.1. para 2. I find this paragraph somewhat bogus. The > visibility of peers to attacker between client and TURN server is > not a threat model I have seen brought up before. Doubt it is > relevant. I find the argument that TLS has better success rate of > traversing firewalls than TCP to be, uh, unproven at best. Jonathan had a related comment, so we changed the text to the following: For TURN clients, using TLS over TCP to communicate with the TURN server provides two benefits. First, the client can be assured that the addresses of its peers are not visible to any attackers between it and the server. Second, the client may be able to communicate with TURN servers using TLS when it would not be able to communicate with the same server using TCP or UDP, due to the policy of a firewall between the TURN client and its server. In this second case, TLS between the client and TURN server facilitates traversal. However, this does not address your first comment. Do you feel we should drop TLS as a transport to the server for TURN? If not, then what benefits do you think it provides? > > Section 12 > > The whole document (not just this section) seems a bit weak on > short and long term credentials. My understanding is that we don't > want to create unauthenticated open relays. So even if anyone can > get an account on a public server, we still want to be able to log > what account did what. My recollection of previous conversations > when doing STUN bis was the allocated were going to use long term > credentials and help set up the short term credentials used to > authenticate the data, send, and channel data. I'm not claiming I > corruptly remember any of this but either way, still looks like > some work needed here on how this is all authorized. The idea of using the long-term credential mechanism to set up short- term credentials was dropped last spring during the big "finish 3489bis" push. I convinced Jonathan that it was way too complex. So short-term credentials are not used in TURN. TURN uses only the Long-Term Credential mechanism. Most of the text on how it is used has been rewritten in TURN-07. Hopefully the details are now clear. The one point that I am somewhat unsure about is how a public TURN server might work. The text currently says that the server SHOULD use the Long-Term Credential mechanism, where the idea behind the SHOULD is to allow public servers to not do it. But this really weakens TURN security. I have added this as an open issue. > As a trivial side note, it looks like some of the issues with NAT > remote in section 12 could be substantially mitigated by clients > choosing random channel numbers. I think they are also mitigated by waiting 2 minutes before the 5- tuple (between the client and the server) can be re-used. This is what TURN now does. > > On the open issues, I don't actually think all of these are open: > > 1) thought we agreed to do this BANDWIDTH is being retained, but the details are still open. TURN-07 has a placeholder mechanism while we debate the details. > > 2) I think we agreed address-restricted. I suspect I was the only > person arguing for address-and-port and well, I loose :-) Yup. > > 3) we need this TURN-07 uses your mechanism. > > 4) uh, we are looking for a demux simpler than bit mask 2 bits? > Surely you are joking :-) Actually I have no idea if we are done or > not here. I think we need to go think carefully about all the demux. We agreed to keep the mechanism of TURN-06. > > 6) any reason why not? No. So I have adopted this. > > 8) I found Magnus and Lars emails about this pretty much sold me on > the answer It seems that Magnus and Lars don't like the current "preserving IP header bits" proposal. > > 10) A client should only be able to request an IP address returned > in allocate response fro the same server and for a allocation that > is still valid. Err... This was not the issue in question. Anyway, I closed the issue as "no restrictions" > > 11) we should make this the same as the BEHAVE UDP documents. Note > that choices other than this will result in the same long > discussions over again and be difficult to implement for some > styles of implementations (i.e. windows or unix not running as root). We agreed to silently discard. > > 12, 14 - see previous comments on this See responses above. > > 15 - I don't care but my gut feeling is put on v4/v6 relays for > now. Or at least make sure you have the support of the v6ops > community before you do it. The document now prevents v4-to-v6 relaying, and points at Oscar and Gonzalo's document as a possible extension to allow this. > > Cullen > - Philip _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 20 10:19:55 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36BFA28C996; Wed, 20 Feb 2008 10:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gb31OBUUCXmh; Wed, 20 Feb 2008 10:19:54 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23F423A6E76; Wed, 20 Feb 2008 10:19:54 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51153A6E76 for ; Wed, 20 Feb 2008 10:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muI5Y4jEMQmc for ; Wed, 20 Feb 2008 10:19:52 -0800 (PST) Received: from mail-08.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 1824D3A6E74 for ; Wed, 20 Feb 2008 10:19:52 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-08.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JRtXp-0001NI-01 for behave@ietf.org; Wed, 20 Feb 2008 13:19:49 -0500 Mime-Version: 1.0 (Apple Message framework v753) In-Reply-To: References: Message-Id: <9C27357E-5BC6-4302-B892-1ECAD74287BF@magma.ca> From: Philip Matthews Date: Wed, 20 Feb 2008 13:19:44 -0500 To: Behave WG X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] Subject: [BEHAVE] TURN: Drop ALTERNATE-SERVER? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Cullen and EKR are both suggesting that we drop the ALTERNATE-SERVER mechanism from TURN. They think the mechanism adds complexity for no real value. They suggest that the SRV mechanism, combined with an admonition for the client to not immediately retry when an Allocate transaction fails due to capacity problems, is sufficient to handle load balancing I have recently rewritten the text on ALTERNATE-SERVER for the forthcoming TURN-07. The text is simpler, but I tend to agree that it does not add a lot of value. Could anyone who wants it speak up and explain what they want it for? If I don't hear anything, then the text will probably remain in TURN-07, but get removed in TURN-08. - Philip _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 20 10:49:31 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A02A628C9E2; Wed, 20 Feb 2008 10:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.646 X-Spam-Level: X-Spam-Status: No, score=-0.646 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9Si5rzeg9Wq; Wed, 20 Feb 2008 10:49:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3A5D28C992; Wed, 20 Feb 2008 10:49:05 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9137E28C459 for ; Wed, 20 Feb 2008 10:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80gWQ14MUzcn for ; Wed, 20 Feb 2008 10:49:01 -0800 (PST) Received: from mail-07.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 868D528C9E7 for ; Wed, 20 Feb 2008 10:47:22 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JRtyN-0005Uf-1r; Wed, 20 Feb 2008 13:47:15 -0500 In-Reply-To: <20080220164218.443335081A@romeo.rtfm.com> References: <20080126232920.7DBF75081A@romeo.rtfm.com> <2A72CA4E-35C5-4B34-B8E4-72A03CDA70C6@magma.ca> <20080220164218.443335081A@romeo.rtfm.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Philip Matthews Date: Wed, 20 Feb 2008 13:47:14 -0500 To: Eric Rescorla X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] Cc: behave@ietf.org Subject: Re: [BEHAVE] Review of draft-ietf-behave-turn-06 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Wed, 20-Feb-08, at 11:42 , Eric Rescorla wrote: > At Wed, 20 Feb 2008 11:26:21 -0500, > Philip Matthews wrote: >> On Sat, 26-Jan-08, at 18:29 , Eric Rescorla wrote: >> >>> $Id: draft-ietf-behave-turn-06-rev.txt,v 1.1 2008/01/26 23:08:30 >>> ekr Exp $ >>> >>> >>> TECHNICAL >>> S 4. >>> The ALTERNATE-SERVER stuff seems problematic for the reasons >>> Cullen indicates. If you're overloaded, better ot simply not >>> handle the request and let ordinary H-A methods take over. >> >> I have simplified the ALTERNATE-SERVER stuff in TURN-07, but left it >> in for now. See my e-mail of a week ago on the subject. However, I >> have no strong attachment to it, and left it in only because I >> thought there were some who still wanted it. It is listed as one of >> the (currently 2) open issues remaining in the document. > > Can those who are in favor of this speak up? Yes. Please do. (See my separate e-mail to the mailing list about this) > > >> I have made major changes in this area to try to bring some clarity >> to the various ways a client can try to recover from an Allocate >> error response. The text currently says that a client must wait at >> least one minute before retrying the request (except for a 442, which >> is not likely to change). In the meantime, the client can try a >> different server. > > Again, I'd like to understand why you need to wait at all? Say the server has run out of ports, and has just rejected allocation requests from 20 clients. Do you really think they should immediately retry? The chance of something having changed is small, and I am worried about what looks like an inadvertent DoS attack. > > >>> S 6.3. >>> This section contains way too much information about the UDP >>> datagram >>> (Length, Checksum...) It should simply specify that a UDP datagram >>> with the following contents is sent to the following location as per >>> standard procedure. >> >> I have left this for now. Much of this detail was in previous >> versions of TURN, abeit in different words in a different part of the >> text. > > Sure, so I should have caught it before, but that doesn't make it > more right. OK. OK! You and Cullen sound like a tag team. ;-) I have removed the last two bullets (that describe how the length and the checksum are computed). See my reply to Cullen for the details. > > >>> EDITORIAL >>> Abstract: >>> Is TURN really "more properly" used as part of ICE? >> >> The idea is that you should really be using TURN with ICE. Can you >> suggest alternate text that expresses this? > > I don't see why we should be expressing this sentiment at all. Because TURN is an inefficient solution with certain deficiencies, and is thus best reserved for cases where a direct connection cannot be established. > >>> S 12. >>> TURN cannot be used by clients for subverting firewall policies. >>> >>> This is untrue, as acknowledged in the section on using TLS. >> >> I think this is mostly true, which is why we have all the >> restrictions on how TURN can be used. >> Do you have a proposed replacement for this sentence? > > "TURN attempts to adhere as closely as possible to common > firewall policies, consistent with allowing data to flow. > For instance, TURN cannot be used to implement an ordinary > server such as a a Web or SMTP server." OK. I changed the text to read as follows: TURN attempts to adhere as closely as possible to common firewall policies, consistent with allowing data to flow. TURN has fairly limited applicability, requiring a user to explicitly authorize permission to receive data from a peer, one IP address at a time. Thus, it does not provide a general technique for externalizing sockets. Rather, it has similar security properties to the placement of an address-restricted NAT in the network, allowing messaging in from a peer only if the internal client has sent a packet out towards the IP address of that peer. This limitation means that TURN cannot be used to run web servers, email servers, SIP servers, or other network servers that service a large number of clients. Rather, it facilitates rendezvous of NATted clients that use some other protocol, such as SIP, to communicate IP addresses and ports for communications. > > -Ekr > - Philip _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 20 10:55:49 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 509DC28C776; Wed, 20 Feb 2008 10:55:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.248 X-Spam-Level: X-Spam-Status: No, score=-0.248 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oniU5J9v+7p; Wed, 20 Feb 2008 10:55:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34BBC28C848; Wed, 20 Feb 2008 10:55:48 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6878628C776 for ; Wed, 20 Feb 2008 10:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZI6Z9iBUgoC for ; Wed, 20 Feb 2008 10:55:46 -0800 (PST) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 9445B3A6E47 for ; Wed, 20 Feb 2008 10:55:46 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 7CCE65081A; Wed, 20 Feb 2008 10:57:31 -0800 (PST) Date: Wed, 20 Feb 2008 10:57:31 -0800 From: Eric Rescorla To: Philip Matthews In-Reply-To: References: <20080126232920.7DBF75081A@romeo.rtfm.com> <2A72CA4E-35C5-4B34-B8E4-72A03CDA70C6@magma.ca> <20080220164218.443335081A@romeo.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080220185731.7CCE65081A@romeo.rtfm.com> Cc: behave@ietf.org Subject: Re: [BEHAVE] Review of draft-ietf-behave-turn-06 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org At Wed, 20 Feb 2008 13:47:14 -0500, Philip Matthews wrote: > On Wed, 20-Feb-08, at 11:42 , Eric Rescorla wrote: > >> I have made major changes in this area to try to bring some clarity > >> to the various ways a client can try to recover from an Allocate > >> error response. The text currently says that a client must wait at > >> least one minute before retrying the request (except for a 442, which > >> is not likely to change). In the meantime, the client can try a > >> different server. > > > > Again, I'd like to understand why you need to wait at all? > > Say the server has run out of ports, and has just rejected allocation > requests from 20 clients. Do you really think they should immediately > retry? The chance of something having changed is small, and I am > worried about what looks like an inadvertent DoS attack. Fair enough, but what if your credentials didn't work cause you mistyped your password? > >>> EDITORIAL > >>> Abstract: > >>> Is TURN really "more properly" used as part of ICE? > >> > >> The idea is that you should really be using TURN with ICE. Can you > >> suggest alternate text that expresses this? > > > > I don't see why we should be expressing this sentiment at all. > > Because TURN is an inefficient solution with certain deficiencies, > and is thus best reserved for cases where a direct connection cannot > be established. Fair enough, but there might be other ways to know this besides ICE. > >>> S 12. > >>> TURN cannot be used by clients for subverting firewall policies. > >>> > >>> This is untrue, as acknowledged in the section on using TLS. > >> > >> I think this is mostly true, which is why we have all the > >> restrictions on how TURN can be used. > >> Do you have a proposed replacement for this sentence? > > > > "TURN attempts to adhere as closely as possible to common > > firewall policies, consistent with allowing data to flow. > > For instance, TURN cannot be used to implement an ordinary > > server such as a a Web or SMTP server." > > OK. I changed the text to read as follows: > > TURN attempts to adhere as closely as possible to common firewall > policies, consistent with allowing data to flow. TURN has fairly > limited applicability, requiring a user to explicitly authorize > permission to receive data from a peer, one IP address at a time. > Thus, it does not provide a general technique for externalizing > sockets. Rather, it has similar security properties to the > placement > of an address-restricted NAT in the network, allowing messaging in > from a peer only if the internal client has sent a packet out > towards > the IP address of that peer. This limitation means that TURN cannot > be used to run web servers, email servers, SIP servers, or other > network servers that service a large number of clients. Rather, it > facilitates rendezvous of NATted clients that use some other > protocol, such as SIP, to communicate IP addresses and ports for > communications. Looks good. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 20 10:57:52 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C48F28C934; Wed, 20 Feb 2008 10:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.797 X-Spam-Level: X-Spam-Status: No, score=-0.797 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dHENWbnKzU8; Wed, 20 Feb 2008 10:57:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 432E828C243; Wed, 20 Feb 2008 10:57:49 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E42E28C90B for ; Wed, 20 Feb 2008 10:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLbboa3KJL+u for ; Wed, 20 Feb 2008 10:57:46 -0800 (PST) Received: from shell.rawbw.com (shell.rawbw.com [198.144.192.42]) by core3.amsl.com (Postfix) with ESMTP id 8788228C222 for ; Wed, 20 Feb 2008 10:56:51 -0800 (PST) Received: from [192.168.255.18] (IDENT:stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell.rawbw.com (8.13.6/8.13.6) with ESMTP id m1KIumEP067913; Wed, 20 Feb 2008 10:56:48 -0800 (PST) Message-Id: From: Brian Korver To: Philip Matthews In-Reply-To: <9C27357E-5BC6-4302-B892-1ECAD74287BF@magma.ca> Mime-Version: 1.0 (Apple Message framework v915) Date: Wed, 20 Feb 2008 10:56:47 -0800 References: <9C27357E-5BC6-4302-B892-1ECAD74287BF@magma.ca> X-Mailer: Apple Mail (2.915) Cc: Behave WG Subject: Re: [BEHAVE] TURN: Drop ALTERNATE-SERVER? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Philip, When I implemented ALTERNATE-SERVER, I felt it was overly complicated (it didn't graft into the control flow especially easily), even though the concept is simple. I vote for drop it in favor of SRV. -brian briank@briank.com On Feb 20, 2008, at 10:19 AM, Philip Matthews wrote: > Cullen and EKR are both suggesting that we drop the ALTERNATE-SERVER > mechanism from TURN. They think the mechanism adds complexity for no > real value. They suggest that the SRV mechanism, combined with an > admonition for the client to not immediately retry when an Allocate > transaction fails due to capacity problems, is sufficient to handle > load balancing > > I have recently rewritten the text on ALTERNATE-SERVER for the > forthcoming TURN-07. The text is simpler, but I tend to agree that it > does not add a lot of value. > > Could anyone who wants it speak up and explain what they want it for? > > If I don't hear anything, then the text will probably remain in > TURN-07, but get removed in TURN-08. > > - Philip > _______________________________________________ > Behave mailing list > Behave@ietf.org > http://www.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 20 11:30:08 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8260E3A6930; Wed, 20 Feb 2008 11:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.633 X-Spam-Level: X-Spam-Status: No, score=-0.633 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TABnfxuCd6i; Wed, 20 Feb 2008 11:30:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A38B028CA94; Wed, 20 Feb 2008 11:28:29 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3895E28CA6A for ; Wed, 20 Feb 2008 11:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8in5CxOwlc48 for ; Wed, 20 Feb 2008 11:28:25 -0800 (PST) Received: from mail-09.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id B775F28CA8A for ; Wed, 20 Feb 2008 11:24:56 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JRuYm-00080a-3C; Wed, 20 Feb 2008 14:24:53 -0500 In-Reply-To: <20080220185731.7CCE65081A@romeo.rtfm.com> References: <20080126232920.7DBF75081A@romeo.rtfm.com> <2A72CA4E-35C5-4B34-B8E4-72A03CDA70C6@magma.ca> <20080220164218.443335081A@romeo.rtfm.com> <20080220185731.7CCE65081A@romeo.rtfm.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Philip Matthews Date: Wed, 20 Feb 2008 14:24:49 -0500 To: Eric Rescorla X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] Cc: behave@ietf.org Subject: Re: [BEHAVE] Review of draft-ietf-behave-turn-06 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Wed, 20-Feb-08, at 13:57 , Eric Rescorla wrote: > At Wed, 20 Feb 2008 13:47:14 -0500, > Philip Matthews wrote: >> On Wed, 20-Feb-08, at 11:42 , Eric Rescorla wrote: >>>> I have made major changes in this area to try to bring some clarity >>>> to the various ways a client can try to recover from an Allocate >>>> error response. The text currently says that a client must wait at >>>> least one minute before retrying the request (except for a 442, >>>> which >>>> is not likely to change). In the meantime, the client can try a >>>> different server. >>> >>> Again, I'd like to understand why you need to wait at all? >> >> Say the server has run out of ports, and has just rejected allocation >> requests from 20 clients. Do you really think they should immediately >> retry? The chance of something having changed is small, and I am >> worried about what looks like an inadvertent DoS attack. > > Fair enough, but what if your credentials didn't work cause > you mistyped your password? This is a 401 error. The text currently says: o 401 (Unauthorized): If the client has followed the procedures of the Long-Term Credential mechanism and still gets this error, then the server is not accepting the client's credentials. The client SHOULD notify the user or operator and SHOULD NOT send any further requests to this server until it believes the problem has been fixed. The client MAY try a different server. The stuff about waiting at least one minute only applies to errors where the server effectively says "I cannot satisfy this request right now for capacity reasons, but you are welcome to try again later". As I said, I completely rewrote all the text on handling Allocate errors yesterday because I felt there was a mis-mash of text on how they should be handled. In the process, I made a number of changes, and it is likely that I got some stuff wrong. How about we pause this topic for now until you read the TURN-07? I am just waiting for Jonathan's and Rohan's comments before publishing TURN-07 (as co- authors, they get first peek, sorry! :-). > > >>>>> EDITORIAL >>>>> Abstract: >>>>> Is TURN really "more properly" used as part of ICE? >>>> >>>> The idea is that you should really be using TURN with ICE. Can you >>>> suggest alternate text that expresses this? >>> >>> I don't see why we should be expressing this sentiment at all. >> >> Because TURN is an inefficient solution with certain deficiencies, >> and is thus best reserved for cases where a direct connection cannot >> be established. > > Fair enough, but there might be other ways to know this besides > ICE. Perhaps. But I still feel that TURN is best viewed as a part of the overall ICE solution and I would like to say this somehow in the abstract. The STUN (rfc3489bis) abstract has similar words. > > >>>>> S 12. >>>>> TURN cannot be used by clients for subverting firewall >>>>> policies. >>>>> >>>>> This is untrue, as acknowledged in the section on using TLS. >>>> >>>> I think this is mostly true, which is why we have all the >>>> restrictions on how TURN can be used. >>>> Do you have a proposed replacement for this sentence? >>> >>> "TURN attempts to adhere as closely as possible to common >>> firewall policies, consistent with allowing data to flow. >>> For instance, TURN cannot be used to implement an ordinary >>> server such as a a Web or SMTP server." >> >> OK. I changed the text to read as follows: >> >> TURN attempts to adhere as closely as possible to common firewall >> policies, consistent with allowing data to flow. TURN has fairly >> limited applicability, requiring a user to explicitly authorize >> permission to receive data from a peer, one IP address at a time. >> Thus, it does not provide a general technique for externalizing >> sockets. Rather, it has similar security properties to the >> placement >> of an address-restricted NAT in the network, allowing >> messaging in >> from a peer only if the internal client has sent a packet out >> towards >> the IP address of that peer. This limitation means that TURN >> cannot >> be used to run web servers, email servers, SIP servers, or other >> network servers that service a large number of clients. >> Rather, it >> facilitates rendezvous of NATted clients that use some other >> protocol, such as SIP, to communicate IP addresses and ports for >> communications. > Looks good. Great! Thanks for the text. > > -Ekr > - Philip _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 20 11:49:45 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C63A28CA12; Wed, 20 Feb 2008 11:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.254 X-Spam-Level: X-Spam-Status: No, score=-0.254 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSVo2OQN6j0H; Wed, 20 Feb 2008 11:49:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 922FD28CA8F; Wed, 20 Feb 2008 11:47:48 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FFA528CAE0 for ; Wed, 20 Feb 2008 11:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6X5RT9UOLdcQ for ; Wed, 20 Feb 2008 11:47:46 -0800 (PST) Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 9421528CAD9 for ; Wed, 20 Feb 2008 11:45:59 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 9CC845081A; Wed, 20 Feb 2008 11:47:44 -0800 (PST) Date: Wed, 20 Feb 2008 11:47:44 -0800 From: Eric Rescorla To: Philip Matthews In-Reply-To: References: <20080126232920.7DBF75081A@romeo.rtfm.com> <2A72CA4E-35C5-4B34-B8E4-72A03CDA70C6@magma.ca> <20080220164218.443335081A@romeo.rtfm.com> <20080220185731.7CCE65081A@romeo.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080220194744.9CC845081A@romeo.rtfm.com> Cc: behave@ietf.org Subject: Re: [BEHAVE] Review of draft-ietf-behave-turn-06 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org At Wed, 20 Feb 2008 14:24:49 -0500, Philip Matthews wrote: > > > On Wed, 20-Feb-08, at 13:57 , Eric Rescorla wrote: > > > At Wed, 20 Feb 2008 13:47:14 -0500, > > Philip Matthews wrote: > >> On Wed, 20-Feb-08, at 11:42 , Eric Rescorla wrote: > >>>> I have made major changes in this area to try to bring some clarity > >>>> to the various ways a client can try to recover from an Allocate > >>>> error response. The text currently says that a client must wait at > >>>> least one minute before retrying the request (except for a 442, > >>>> which > >>>> is not likely to change). In the meantime, the client can try a > >>>> different server. > >>> > >>> Again, I'd like to understand why you need to wait at all? > >> > >> Say the server has run out of ports, and has just rejected allocation > >> requests from 20 clients. Do you really think they should immediately > >> retry? The chance of something having changed is small, and I am > >> worried about what looks like an inadvertent DoS attack. > > > > Fair enough, but what if your credentials didn't work cause > > you mistyped your password? > > This is a 401 error. The text currently says: > o 401 (Unauthorized): If the client has followed the procedures of > the Long-Term Credential mechanism and still gets this error, > then > the server is not accepting the client's credentials. The client > SHOULD notify the user or operator and SHOULD NOT send any > further > requests to this server until it believes the problem has been > fixed. The client MAY try a different server. > > The stuff about waiting at least one minute only applies to errors > where the server effectively says "I cannot satisfy this request > right now for capacity reasons, but you are welcome to try again later". > > As I said, I completely rewrote all the text on handling Allocate > errors yesterday because I felt there was a mis-mash of text on how > they should be handled. In the process, I made a number of changes, > and it is likely that I got some stuff wrong. How about we pause this > topic for now until you read the TURN-07? I am just waiting for > Jonathan's and Rohan's comments before publishing TURN-07 (as co- > authors, they get first peek, sorry! :-). No problem. > Perhaps. But I still feel that TURN is best viewed as a part of the > overall ICE solution and I would like to say this somehow in the > abstract. The STUN (rfc3489bis) abstract has similar words. Can't say I'm any happier with it there... -Ekr _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 20 12:10:04 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BD163A6A66; Wed, 20 Feb 2008 12:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.804 X-Spam-Level: X-Spam-Status: No, score=-99.804 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_BACKHAIR_12=1, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FMljYLGga8U; Wed, 20 Feb 2008 12:10:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6FDB28CA96; Wed, 20 Feb 2008 12:07:56 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEA7428CA40 for ; Wed, 20 Feb 2008 12:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znAr-rTqf9+X for ; Wed, 20 Feb 2008 12:07:55 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 4B8B328CA8D for ; Wed, 20 Feb 2008 12:04:17 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 0A3EDF9CC1FA; Wed, 20 Feb 2008 20:04:14 +0000 (UTC) Received: from [192.168.1.3] (c-71-202-183-123.hsd1.ca.comcast.net [71.202.183.123]) by server.implementers.org (Postfix) with ESMTP id 7FB17F9CC1F8; Wed, 20 Feb 2008 20:04:11 +0000 (UTC) Message-ID: <47BC87BA.3020905@acm.org> Date: Wed, 20 Feb 2008 12:04:10 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080109) MIME-Version: 1.0 To: Philip Matthews References: <47B10B92.2070409@cisco.com> <47B89994.4020500@acm.org> <7046FC57-9F58-47DF-9A38-1631A0077EE3@magma.ca> In-Reply-To: <7046FC57-9F58-47DF-9A38-1631A0077EE3@magma.ca> Cc: Behave WG Subject: Re: [BEHAVE] Updated rfc3489bis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Philip Matthews wrote: > = > On Sun, 17-Feb-08, at 15:31 , Marc Petit-Huguenin wrote: >> >> It could be also a good thing to add examples for long-term >> authentication in draft-ietf-behave-stun-test-vectors. > = > This sounds like a good idea. > = So I propose to add the following text: 2.4. Sample request with long-term authentication This request uses the following parameters (without quotes): Username: "username" Nonce: "f//499k954d6OL34oL9FSTvy64sA" Realm: "example.org" Password: "The=ADMtr" 00 01 00 54 Request type and message length 21 12 a4 42 Message cookie 57 ca b8 83 } cd ec 6c 2a } Transaction ID 2d 4f 63 68 } 00 06 00 08 USERNAME attribute header 75 73 65 72 } Username (8 bytes) 6e 61 6d 65 } 00 15 00 1c NONCE attribute header 66 2f 2f 34 } 39 39 6b 39 } 35 34 64 36 } 4f 4c 33 34 } Nonce value 6f 4c 39 46 } 53 54 76 79 } 36 34 73 41 } 00 14 00 0b REALM attribute header 65 78 61 6d } 70 6c 65 2e } Realm value (11 bytes) and padding (1 byte) 6f 72 67 00 } 00 08 00 14 MESSAGE-INTEGRITY attribute header 27 ca 6a b8 } 0f aa f2 67 } 85 b9 dd 0f } HMAC-SHA1 value 2e 17 68 0f } 85 60 98 4b } -- = Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 20 12:21:37 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DA1028C675; Wed, 20 Feb 2008 12:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.587 X-Spam-Level: X-Spam-Status: No, score=-1.587 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDnU-lWbVnL0; Wed, 20 Feb 2008 12:21:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2DD53A687A; Wed, 20 Feb 2008 12:21:36 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A228528C15A for ; Wed, 20 Feb 2008 12:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oqi2q7CPh6xo for ; Wed, 20 Feb 2008 12:21:34 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id CEAE13A67D5 for ; Wed, 20 Feb 2008 12:21:34 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 20 Feb 2008 12:21:31 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1KKLVxp008704; Wed, 20 Feb 2008 12:21:31 -0800 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1KKLUJg026938; Wed, 20 Feb 2008 20:21:30 GMT From: "Dan Wing" To: "'Philip Matthews'" References: <20080126232920.7DBF75081A@romeo.rtfm.com><2A72CA4E-35C5-4B34-B8E4-72A03CDA70C6@magma.ca><20080220164218.443335081A@romeo.rtfm.com> Date: Wed, 20 Feb 2008 12:21:29 -0800 Message-ID: <12fb01c873fe$2e06bca0$c4f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: Achz8XLGc+HKtAWfRa6ElJF3vl614QADBlEA Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: behave@ietf.org Subject: Re: [BEHAVE] Review of draft-ietf-behave-turn-06 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > > "TURN attempts to adhere as closely as possible to common > > firewall policies, consistent with allowing data to flow. > > For instance, TURN cannot be used to implement an ordinary > > server such as a a Web or SMTP server." > > OK. I changed the text to read as follows: > > TURN attempts to adhere as closely as possible to common firewall > policies, consistent with allowing data to flow. TURN has fairly > limited applicability, requiring a user to explicitly authorize > permission to receive data from a peer, one IP address at a time. > Thus, it does not provide a general technique for externalizing > sockets. Rather, it has similar security properties to the > placement > of an address-restricted NAT in the network, allowing messaging in > from a peer only if the internal client has sent a packet out > towards > the IP address of that peer. This limitation means that > TURN cannot > be used to run web servers, email servers, SIP servers, or other > network servers that service a large number of clients. TURN can't listen for incoming TCP connections at all, so referencing web (HTTP) or email (SMTP/IMAP/POP) servers, which all use TCP, doesn't make sense. TURN-TCP could potentially do that, but I expect we will castrate TURN-TCP in a similar manner to prevent such use. You might also want to explicitly point out, in this same paragraph, that TURN can only establish UDP connections to remote peers. Please reduce the reference to UDP servers, and use "e.g.". A reasonable list of interesting UDP servers might be NTP, SIP, and TFTP. -d > Rather, it > facilitates rendezvous of NATted clients that use some other > protocol, such as SIP, to communicate IP addresses and ports for > communications. _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 20 12:28:04 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34E7F3A6A69; Wed, 20 Feb 2008 12:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.126 X-Spam-Level: X-Spam-Status: No, score=-0.126 tagged_above=-999 required=5 tests=[AWL=-0.689, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_BACKHAIR_12=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umRj1aO4jpkY; Wed, 20 Feb 2008 12:28:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A2EA3A6A00; Wed, 20 Feb 2008 12:28:03 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0C573A6A69 for ; Wed, 20 Feb 2008 12:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N50yQxobog06 for ; Wed, 20 Feb 2008 12:28:01 -0800 (PST) Received: from mail-09.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 1BA633A687A for ; Wed, 20 Feb 2008 12:28:01 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JRvXn-0008Cr-04; Wed, 20 Feb 2008 15:27:57 -0500 In-Reply-To: <47BC87BA.3020905@acm.org> References: <47B10B92.2070409@cisco.com> <47B89994.4020500@acm.org> <7046FC57-9F58-47DF-9A38-1631A0077EE3@magma.ca> <47BC87BA.3020905@acm.org> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <89343971-77FA-42C5-BE1B-96B284159185@magma.ca> From: Philip Matthews Date: Wed, 20 Feb 2008 15:27:51 -0500 To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] Cc: Behave WG Subject: Re: [BEHAVE] Updated rfc3489bis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org How about showing an example with a realm or username that uses characters outside the ASCII subset of UTF-8? - Philip On Wed, 20-Feb-08, at 15:04 , Marc Petit-Huguenin wrote: > Philip Matthews wrote: >> >> On Sun, 17-Feb-08, at 15:31 , Marc Petit-Huguenin wrote: >>> >>> It could be also a good thing to add examples for long-term >>> authentication in draft-ietf-behave-stun-test-vectors. >> >> This sounds like a good idea. >> > > So I propose to add the following text: > > 2.4. Sample request with long-term authentication > > This request uses the following parameters (without quotes): > Username: "username" > Nonce: "f//499k954d6OL34oL9FSTvy64sA" > Realm: "example.org" > Password: "The Mtr" > > 00 01 00 54 Request type and message length > 21 12 a4 42 Message cookie > 57 ca b8 83 } > cd ec 6c 2a } Transaction ID > 2d 4f 63 68 } > 00 06 00 08 USERNAME attribute header > 75 73 65 72 } Username (8 bytes) > 6e 61 6d 65 } > 00 15 00 1c NONCE attribute header > 66 2f 2f 34 } > 39 39 6b 39 } > 35 34 64 36 } > 4f 4c 33 34 } Nonce value > 6f 4c 39 46 } > 53 54 76 79 } > 36 34 73 41 } > 00 14 00 0b REALM attribute header > 65 78 61 6d } > 70 6c 65 2e } Realm value (11 bytes) and padding (1 byte) > 6f 72 67 00 } > 00 08 00 14 MESSAGE-INTEGRITY attribute header > 27 ca 6a b8 } > 0f aa f2 67 } > 85 b9 dd 0f } HMAC-SHA1 value > 2e 17 68 0f } > 85 60 98 4b } > > -- > Marc Petit-Huguenin [ ] > Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] > Work: marc@8x8.com [ ] > [ ] > _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 20 12:59:08 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32FDB28C948; Wed, 20 Feb 2008 12:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.604 X-Spam-Level: X-Spam-Status: No, score=-0.604 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0m+W5OTBAS13; Wed, 20 Feb 2008 12:59:07 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6104E28C7FD; Wed, 20 Feb 2008 12:59:06 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89F7C28C7FD for ; Wed, 20 Feb 2008 12:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEvwK8kIO1NG for ; Wed, 20 Feb 2008 12:59:04 -0800 (PST) Received: from mail-08.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 8F46628C1C9 for ; Wed, 20 Feb 2008 12:59:04 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-08.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JRw1t-0000ey-0w; Wed, 20 Feb 2008 15:59:01 -0500 In-Reply-To: <12fb01c873fe$2e06bca0$c4f0200a@cisco.com> References: <20080126232920.7DBF75081A@romeo.rtfm.com><2A72CA4E-35C5-4B34-B8E4-72A03CDA70C6@magma.ca><20080220164218.443335081A@romeo.rtfm.com> <12fb01c873fe$2e06bca0$c4f0200a@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Philip Matthews Date: Wed, 20 Feb 2008 15:58:59 -0500 To: "Dan Wing" X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] Cc: behave@ietf.org Subject: Re: [BEHAVE] Review of draft-ietf-behave-turn-06 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Wed, 20-Feb-08, at 15:21 , Dan Wing wrote: >>> "TURN attempts to adhere as closely as possible to common >>> firewall policies, consistent with allowing data to flow. >>> For instance, TURN cannot be used to implement an ordinary >>> server such as a a Web or SMTP server." >> >> OK. I changed the text to read as follows: >> >> TURN attempts to adhere as closely as possible to common firewall >> policies, consistent with allowing data to flow. TURN has fairly >> limited applicability, requiring a user to explicitly authorize >> permission to receive data from a peer, one IP address at a time. >> Thus, it does not provide a general technique for externalizing >> sockets. Rather, it has similar security properties to the >> placement >> of an address-restricted NAT in the network, allowing >> messaging in >> from a peer only if the internal client has sent a packet out >> towards >> the IP address of that peer. This limitation means that >> TURN cannot >> be used to run web servers, email servers, SIP servers, or other >> network servers that service a large number of clients. > > TURN can't listen for incoming TCP connections at all, so > referencing web > (HTTP) or email (SMTP/IMAP/POP) servers, which all use TCP, doesn't > make > sense. TURN-TCP could potentially do that, but I expect we will > castrate > TURN-TCP in a similar manner to prevent such use. You might also > want to > explicitly point out, in this same paragraph, that TURN can only > establish UDP > connections to remote peers. > > Please reduce the reference to UDP servers, and use "e.g.". A > reasonable list > of interesting UDP servers might be NTP, SIP, and TFTP. > > -d Done. (Confession time: I didn't even look at the security considerations section until now, so it might well be out-of-date from all the changes that have been made recently to TURN.) - Philip _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 20 13:20:59 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1574828C993; Wed, 20 Feb 2008 13:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.744 X-Spam-Level: X-Spam-Status: No, score=-99.744 tagged_above=-999 required=5 tests=[AWL=-0.307, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_BACKHAIR_12=1, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbTx6oN1DC0v; Wed, 20 Feb 2008 13:20:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B6B628CA84; Wed, 20 Feb 2008 13:20:45 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A981B28C8E6 for ; Wed, 20 Feb 2008 13:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFj7FkuAHB8u for ; Wed, 20 Feb 2008 13:20:38 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 739D228CA8B for ; Wed, 20 Feb 2008 13:19:29 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 71165F9CC1F8; Wed, 20 Feb 2008 21:19:26 +0000 (UTC) Received: from [192.168.1.3] (c-71-202-183-123.hsd1.ca.comcast.net [71.202.183.123]) by server.implementers.org (Postfix) with ESMTP id A0A73F9CC1FA; Wed, 20 Feb 2008 21:19:24 +0000 (UTC) Message-ID: <47BC995C.8000307@acm.org> Date: Wed, 20 Feb 2008 13:19:24 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080109) MIME-Version: 1.0 To: Philip Matthews References: <47B10B92.2070409@cisco.com> <47B89994.4020500@acm.org> <7046FC57-9F58-47DF-9A38-1631A0077EE3@magma.ca> <47BC87BA.3020905@acm.org> <89343971-77FA-42C5-BE1B-96B284159185@magma.ca> In-Reply-To: <89343971-77FA-42C5-BE1B-96B284159185@magma.ca> Cc: Behave WG Subject: Re: [BEHAVE] Updated rfc3489bis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Philip Matthews wrote: > How about showing an example with a realm or username that uses > characters outside the ASCII subset of UTF-8? OK, what about this (username is "Matorikkusu" - aka The Matrix - in katakana): 2.4. Sample request with long-term authentication This request uses the following parameters (without quotes): Username: "" Nonce: "f//499k954d6OL34oL9FSTvy64sA" Realm: "example.org" Password: "The=ADMtr" 00 01 00 60 Request type and message length 21 12 a4 42 Message cookie 78 ad 34 33 } c6 ad 72 c0 } Transaction ID 29 da 41 2e } 00 06 00 12 USERNAME attribute header e3 83 9e e3 } 83 88 e3 83 } aa e3 83 83 } Username value (18 bytes) and padding (2 bytes) e3 82 af e3 } 82 b9 00 00 } 00 15 00 1c NONCE attribute header 66 2f 2f 34 } 39 39 6b 39 } 35 34 64 36 } 4f 4c 33 34 } Nonce value 6f 4c 39 46 } 53 54 76 79 } 36 34 73 41 } 00 14 00 0b REALM attribute header 65 78 61 6d } 70 6c 65 2e } Realm value (11 bytes) and padding (1 byte) 6f 72 67 00 } 00 08 00 14 MESSAGE-INTEGRITY attribute header f6 70 24 65 } 6d d6 4a 3e } 02 b8 e0 71 } HMAC-SHA1 value 2e 85 c9 a2 } 8c a8 96 66 } > > - Philip > > On Wed, 20-Feb-08, at 15:04 , Marc Petit-Huguenin wrote: > >> Philip Matthews wrote: >>> >>> On Sun, 17-Feb-08, at 15:31 , Marc Petit-Huguenin wrote: >>>> >>>> It could be also a good thing to add examples for long-term >>>> authentication in draft-ietf-behave-stun-test-vectors. >>> >>> This sounds like a good idea. >>> -- = Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Feb 21 08:10:40 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B882D28C77F; Thu, 21 Feb 2008 08:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[AWL=-0.759, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L75RWzO9CeKS; Thu, 21 Feb 2008 08:10:39 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9686728C321; Thu, 21 Feb 2008 08:10:39 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49CC428C321 for ; Thu, 21 Feb 2008 08:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKi36qLL1c2h for ; Thu, 21 Feb 2008 08:10:37 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 79D0A3A696A for ; Thu, 21 Feb 2008 08:10:37 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1LGBYKY027683 for ; Thu, 21 Feb 2008 10:11:56 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 18:09:59 +0200 Received: from esdhcp041109.research.nokia.com ([172.21.41.109]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 18:10:00 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Date: Thu, 21 Feb 2008 18:09:59 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200802211810.00082.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 21 Feb 2008 16:10:00.0079 (UTC) FILETIME=[357B49F0:01C874A4] X-Nokia-AV: Clean Subject: [BEHAVE] draft-denis-behave-nat-dccp updated X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Hello, It was already discussed in Vancouver. I tried to flesh the document out. I= t's = essentially the same as BEHAVE-TCP, adapted to DCCP (assuming that DCCP = simulatenous open goes forward in DCCP wg). There is one exception though: = the ALG requirement. Currently, they are forbidden for DCCP, while they are = merely discouraged for TCP. I cannot think of a way they'd cope with the = lossiness of DCCP, except perhaps if they never alter the payload size. I haven't heard of any deployed DCCP ALG anyway. Regards, -- = R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Feb 21 10:02:23 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF2843A696E; Thu, 21 Feb 2008 10:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjuvMjpu3BLC; Thu, 21 Feb 2008 10:02:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF60F28C9BC; Thu, 21 Feb 2008 10:02:22 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC4D328C9BC for ; Thu, 21 Feb 2008 10:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23M+isepbUhY for ; Thu, 21 Feb 2008 10:02:20 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 513D828C91D for ; Thu, 21 Feb 2008 10:02:20 -0800 (PST) Received: (qmail invoked by alias); 21 Feb 2008 18:02:15 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp005) with SMTP; 21 Feb 2008 19:02:15 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19AYO828i1AVJliAdFVTotUy/sZoFxCV25TforBR7 k2AsLVnTMDRbK2 Message-ID: <47BDBCA6.7080002@gmx.net> Date: Thu, 21 Feb 2008 20:02:14 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= References: <200802211810.00082.remi.denis-courmont@nokia.com> In-Reply-To: <200802211810.00082.remi.denis-courmont@nokia.com> X-Y-GMX-Trusted: 0 Cc: behave@ietf.org Subject: Re: [BEHAVE] draft-denis-behave-nat-dccp updated X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Have you (or someone else) heard about deployments of DCCP? R=E9mi Denis-Courmont wrote: > Hello, > > It was already discussed in Vancouver. I tried to flesh the document out.= It's = > essentially the same as BEHAVE-TCP, adapted to DCCP (assuming that DCCP = > simulatenous open goes forward in DCCP wg). There is one exception though= : = > the ALG requirement. Currently, they are forbidden for DCCP, while they a= re = > merely discouraged for TCP. I cannot think of a way they'd cope with the = > lossiness of DCCP, except perhaps if they never alter the payload size. > > I haven't heard of any deployed DCCP ALG anyway. > > Regards, > > = _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Feb 21 15:58:50 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAB6F3A6CF5; Thu, 21 Feb 2008 15:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.224 X-Spam-Level: X-Spam-Status: No, score=-100.224 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahrU-xoUD3Ie; Thu, 21 Feb 2008 15:58:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CE223A6B7E; Thu, 21 Feb 2008 15:58:49 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A0D33A685E for ; Thu, 21 Feb 2008 15:58:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTmXZrZXGWSd for ; Thu, 21 Feb 2008 15:58:47 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id B8ACE3A6823 for ; Thu, 21 Feb 2008 15:58:47 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 4B6FEF9CC1FC; Thu, 21 Feb 2008 23:58:44 +0000 (UTC) Received: from [192.168.1.3] (c-71-202-183-123.hsd1.ca.comcast.net [71.202.183.123]) by server.implementers.org (Postfix) with ESMTP id 38910F9CC1F8 for ; Thu, 21 Feb 2008 23:58:42 +0000 (UTC) Message-ID: <47BE1031.4060804@acm.org> Date: Thu, 21 Feb 2008 15:58:41 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080109) MIME-Version: 1.0 To: Behave WG References: <9C27357E-5BC6-4302-B892-1ECAD74287BF@magma.ca> In-Reply-To: <9C27357E-5BC6-4302-B892-1ECAD74287BF@magma.ca> Subject: Re: [BEHAVE] TURN: Drop ALTERNATE-SERVER? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Philip Matthews wrote: > Cullen and EKR are both suggesting that we drop the ALTERNATE-SERVER > mechanism from TURN. They think the mechanism adds complexity for no > real value. They suggest that the SRV mechanism, combined with an > admonition for the client to not immediately retry when an Allocate > transaction fails due to capacity problems, is sufficient to handle > load balancing > > I have recently rewritten the text on ALTERNATE-SERVER for the > forthcoming TURN-07. The text is simpler, but I tend to agree that it > does not add a lot of value. > > Could anyone who wants it speak up and explain what they want it for? The problem here is that using SRV RR is not a replacement for all the usages of ALTERNATE-SERVER. I would agree 100% to remove ALTERNATE-SERVER if its only usage was for load balancing, but there is other usages. In fact I suggested multiple times that it would be more useful to return a domain name instead of an IP address, but even with only one IP address returned it is still possible to do something useful. I have two examples of usages: First example is for the clients that does not implement SRV RR. In this case, the client contacts the TURN server at the IP address (A or AAAA) of the domain and the default port for TURN (let's say 3479). Running at this IP address/port is a simple server that queries the DNS for the SRV RR of the domain, runs the RFC 2782 algorithm and returns an IP address in the ALTERNATE-SERVER attribute. Failover and priority will not work, but at least the requests will be balanced between the servers according to the weight in the SRV RR. The client will not work better but it has less chance to overload the servers. Second example is to redirect a client to a "closer" TURN server. I explained how this could work with a domain name returned instead of an IP address in this email: http://www.ietf.org/mail-archive/web/behave/current/msg02716.html Even without the domain name, it is possible to redirect to a closer server, which is better than nothing. Note that anycast does not work for this example, as explained in rfc3489bis, section 7.2. So as a conclusion, I would like to keep ALTERNATE-SERVER if there is not a better mechanism to redirect for *other* reasons than load-balancing. If ALTERNATE-SERVER is kept in its current form, I would suggest to add some text that strongly advise against using it for load balancing. Thanks. -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 22 06:45:26 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5938528C3C9; Fri, 22 Feb 2008 06:45:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.149 X-Spam-Level: X-Spam-Status: No, score=-0.149 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SF1XKD8qdjkv; Fri, 22 Feb 2008 06:45:25 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85E7128C2FE; Fri, 22 Feb 2008 06:45:25 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03D5628C32E for ; Fri, 22 Feb 2008 06:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwqHMpyPlLZ6 for ; Fri, 22 Feb 2008 06:45:23 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 9906628C2B6 for ; Fri, 22 Feb 2008 06:45:15 -0800 (PST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1MEifp8021234 for ; Fri, 22 Feb 2008 16:45:09 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Feb 2008 16:45:07 +0200 Received: from essapo-nirac25230.europe.nokia.com ([10.162.252.30]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Feb 2008 16:45:06 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Date: Fri, 22 Feb 2008 16:45:06 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <9C27357E-5BC6-4302-B892-1ECAD74287BF@magma.ca> <47BE1031.4060804@acm.org> In-Reply-To: <47BE1031.4060804@acm.org> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200802221645.06195.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 22 Feb 2008 14:45:06.0899 (UTC) FILETIME=[841F7230:01C87561] X-Nokia-AV: Clean Subject: Re: [BEHAVE] TURN: Drop ALTERNATE-SERVER? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Le Friday 22 February 2008 01:58:41 ext Marc Petit-Huguenin, vous avez =E9c= rit=A0: > First example is for the clients that does not implement SRV RR. As far as I remember, SRV is a MUST anyway, and I would not bother trying t= o = support non-standard clients in a standard specification. -- = R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 22 07:05:31 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A35963A6CBD; Fri, 22 Feb 2008 07:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.113 X-Spam-Level: X-Spam-Status: No, score=-100.113 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SywiglDV21hF; Fri, 22 Feb 2008 07:05:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C360528C1C8; Fri, 22 Feb 2008 07:05:30 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C70A628C1C8 for ; Fri, 22 Feb 2008 07:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xW9sycWiTnAm for ; Fri, 22 Feb 2008 07:05:29 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 01F2F3A6A40 for ; Fri, 22 Feb 2008 07:05:29 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 05072F9CC2D4; Fri, 22 Feb 2008 15:05:25 +0000 (UTC) Received: from [192.168.1.3] (c-71-202-183-123.hsd1.ca.comcast.net [71.202.183.123]) by server.implementers.org (Postfix) with ESMTP id 096B3F9CC2D2; Fri, 22 Feb 2008 15:05:21 +0000 (UTC) Message-ID: <47BEE4B1.5010204@acm.org> Date: Fri, 22 Feb 2008 07:05:21 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080109) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= References: <9C27357E-5BC6-4302-B892-1ECAD74287BF@magma.ca> <47BE1031.4060804@acm.org> <200802221645.06195.remi.denis-courmont@nokia.com> In-Reply-To: <200802221645.06195.remi.denis-courmont@nokia.com> Cc: behave@ietf.org Subject: Re: [BEHAVE] TURN: Drop ALTERNATE-SERVER? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org R=E9mi Denis-Courmont wrote: > Le Friday 22 February 2008 01:58:41 ext Marc Petit-Huguenin, vous avez = =E9crit : >> First example is for the clients that does not implement SRV RR. > = > As far as I remember, SRV is a MUST anyway, and I would not bother trying= to = > support non-standard clients in a standard specification. > = I am not suggesting to add text to support non-standard clients, I am trying to show that there is other usages to ALTERNATE-SERVER than load-balancing. -- = Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 22 08:05:47 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BCE428C20B; Fri, 22 Feb 2008 08:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.055 X-Spam-Level: X-Spam-Status: No, score=-1.055 tagged_above=-999 required=5 tests=[AWL=-0.618, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mq4E1pIxQau3; Fri, 22 Feb 2008 08:05:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A75428C11D; Fri, 22 Feb 2008 08:05:46 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AD1228C11D for ; Fri, 22 Feb 2008 08:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIzY1E8A6S9k for ; Fri, 22 Feb 2008 08:05:44 -0800 (PST) Received: from mail.sipeerior.com (mail.sipeerior.com [128.239.5.131]) by core3.amsl.com (Postfix) with ESMTP id AC47728C0F7 for ; Fri, 22 Feb 2008 08:05:44 -0800 (PST) Received: from [128.239.5.143] (unknown [128.239.5.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sipeerior.com (Postfix) with ESMTP id 31557505AE1; Fri, 22 Feb 2008 11:05:40 -0500 (EST) In-Reply-To: <475C1A7A.7010604@db.org> References: <475C1A7A.7010604@db.org> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Bruce Lowekamp Date: Fri, 22 Feb 2008 11:05:38 -0500 To: Alfred E. Heggestad X-Mailer: Apple Mail (2.753) Cc: 'Behave WG' Subject: Re: [BEHAVE] Comments on draft-ietf-behave-nat-behavior-discovery-02 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Alfred, Thanks for the feedback. I really regret not objecting to the non- orthogonal endpoint-independent and address-dependent combination in 4787, but I made a pass through the whole document to make the terminology correct (including the hyphenation), so it should be fixed in -03. Also clarified the ALG text. Thanks for the comments. Bruce On Dec 9, 2007, at 11:40 AM, Alfred E. Heggestad wrote: > Comments on draft-ietf-behave-nat-behavior-discovery-02 > > by Alfred E. Heggestad > 9. Dec 2007 > > > > > > 2.2. Example Use with P2P Overlays > > > > behind NATs to avoid the cost of dedicated servers. A supernode > > candidate requires that its NAT(s) offer(s) Address Independent > > Filtering. ^^^^^^^^^^^^^^^^^^^ > > ^^^^^^^^^ > > There is no such things as "Address Independent Filtering". See RFC > 4787 > for the definitions. What you probably mean here is "Endpoint > Independent" > filtering > > > > > > 3.6. Detecting Generic ALGs > > > > It should be noted wether this test is applicable to UDP, TCP, TLS > over TCP. > > > > > > 4.3. Determining NAT Filtering Behavior > > > > its alternate IP address and alternate port. If the client > receives > > a response the current behaviour of the NAT is Address Independent > > Filtering. ^^^^^^^^^^^^^^^^^^^ > > ^^^^^^^^^ > > There is no such things as "Address Independent Filtering". See RFC > 4787 > for the definitions. What you probably mean here is "Endpoint > Independent" > filtering > > > > > _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Feb 23 10:50:42 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBFF63A6B97; Sat, 23 Feb 2008 10:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.904 X-Spam-Level: X-Spam-Status: No, score=-0.904 tagged_above=-999 required=5 tests=[AWL=-0.767, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P432v-SGOCd3; Sat, 23 Feb 2008 10:50:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C726B3A69E1; Sat, 23 Feb 2008 10:50:41 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 966043A69E1 for ; Sat, 23 Feb 2008 10:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amU3qMT2-7Bh for ; Sat, 23 Feb 2008 10:50:39 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8B4BC3A6986 for ; Sat, 23 Feb 2008 10:50:39 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 23 Feb 2008 13:50:34 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1NIoYRa011979; Sat, 23 Feb 2008 13:50:34 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1NIoYUi021854; Sat, 23 Feb 2008 18:50:34 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 23 Feb 2008 13:50:34 -0500 Received: from [10.82.240.196] ([10.82.240.196]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 23 Feb 2008 13:50:34 -0500 Message-ID: <47C06AEF.2010701@cisco.com> Date: Sat, 23 Feb 2008 13:50:23 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= References: <47B10B92.2070409@cisco.com> <200802201907.41353.remi.denis-courmont@nokia.com> In-Reply-To: <200802201907.41353.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 23 Feb 2008 18:50:34.0439 (UTC) FILETIME=[F8D57570:01C8764C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1040; t=1203792634; x=1204656634; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20Updated=20rfc3489bis |Sender:=20 |To:=20=3D?ISO-8859-1?Q?R=3DE9mi_Denis-Courmont?=3D=0A=20; bh=oiesvBwdbUGP+OeiUvEi/kZma9Ptsdgytbkda9kw3M8=; b=po/rund9pSrPbtj3YYAMJ/oPeQo7hJEMEYQnii9kCG8PhXWD1iR2iOrFsT m/BGt0bdlTmxMG9hnUk+g1u86W4j5PMXLY1OBYXyVLBO+VdFQr20YFqNwuzL nGfhYJF5Kp; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: behave@ietf.org Subject: Re: [BEHAVE] Updated rfc3489bis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Yes, I will clarify this. I'll also change to SHOULD per Bruce's comment, and clarify in the text = that this is a SHOULD and not a MUST to deal with cases where STUN is = used explicitly to probe fragment handling. -Jonathan R. R=E9mi Denis-Courmont wrote: > Le Tuesday 12 February 2008 04:59:30 ext Jonathan Rosenberg, vous avez = =E9crit : >> * maximum STUN message size now set to 576 bytes for v4, 1280 for v6, >> when pmtu is unknown. It was previously 1500 when pmtu is unknown. > = > Should it not be clarified that this is the IP-layer datagram size, not = > the "STUN message size"? In other words, the maximumem STUN message size = is = > 548 bytes minus would-be IPv4 options resp. 1232 bytes minus would-be IPv= 6 = > extension headers? > = -- = Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Feb 23 10:50:45 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D28F43A6C1F; Sat, 23 Feb 2008 10:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.068 X-Spam-Level: X-Spam-Status: No, score=-1.068 tagged_above=-999 required=5 tests=[AWL=-0.631, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxQmgxc4yEwP; Sat, 23 Feb 2008 10:50:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9AD53A6B97; Sat, 23 Feb 2008 10:50:44 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B78843A6B0B for ; Sat, 23 Feb 2008 10:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1atkTngD5gEf for ; Sat, 23 Feb 2008 10:50:43 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D6DAA3A69E1 for ; Sat, 23 Feb 2008 10:50:42 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 23 Feb 2008 13:50:38 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1NIocrc012033; Sat, 23 Feb 2008 13:50:38 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1NIoUUs021629; Sat, 23 Feb 2008 18:50:33 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 23 Feb 2008 13:48:59 -0500 Received: from [10.82.240.196] ([10.82.240.196]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 23 Feb 2008 13:48:59 -0500 Message-ID: <47C06A90.1080609@cisco.com> Date: Sat, 23 Feb 2008 13:48:48 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Marc Petit-Huguenin References: <47B10B92.2070409@cisco.com> <47B89994.4020500@acm.org> In-Reply-To: <47B89994.4020500@acm.org> X-OriginalArrivalTime: 23 Feb 2008 18:48:59.0348 (UTC) FILETIME=[C027B940:01C8764C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=900; t=1203792638; x=1204656638; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20Updated=20rfc3489bis |Sender:=20 |To:=20Marc=20Petit-Huguenin=20; bh=ZanXU8Yvu/Qaiff6cj/q/jgK49f1P+wL+jvSMH8y1v4=; b=gb5QiY5aNYTrkWo38pMuVF5o7j0tsNPgeibZ/sGthoX+CWNGgweXc146b5 nvj83DPY0CHvDY4XOeUCptw3k1eZp8j61x7GE/EnV2JjdtVY77EOt7ozaaN0 oyInPkbP6n; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Behave WG Subject: Re: [BEHAVE] Updated rfc3489bis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Wow, that is a great catch. I'll submit a -15 with this included. -Jonathan R. Marc Petit-Huguenin wrote: > Hi Jonathan, > > Jonathan Rosenberg wrote: >> I've just submitted an update to rfc3489bis: >> >> http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-14.txt >> > > It seems that between -06 and -07 we lost the text that fixed the second > issue discussed here: > > http://www.ietf.org/mail-archive/web/behave/current/msg01218.html > > It could be also a good thing to add examples for long-term > authentication in draft-ietf-behave-stun-test-vectors. > > > Thanks. > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Feb 23 11:24:39 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAF713A6B76; Sat, 23 Feb 2008 11:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.065 X-Spam-Level: X-Spam-Status: No, score=-1.065 tagged_above=-999 required=5 tests=[AWL=-0.628, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdN-hsWBrfzq; Sat, 23 Feb 2008 11:24:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE63E3A6B19; Sat, 23 Feb 2008 11:24:38 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB79F3A6AF0 for ; Sat, 23 Feb 2008 11:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xua6hc-DCIdT for ; Sat, 23 Feb 2008 11:24:37 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id AA97C3A6B0B for ; Sat, 23 Feb 2008 11:24:36 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 23 Feb 2008 14:24:32 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1NJOWRe030144 for ; Sat, 23 Feb 2008 14:24:32 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1NJO0JT011074 for ; Sat, 23 Feb 2008 19:24:31 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 23 Feb 2008 14:24:08 -0500 Received: from [10.82.240.196] ([10.82.240.196]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 23 Feb 2008 14:24:08 -0500 Message-ID: <47C072CD.3050003@cisco.com> Date: Sat, 23 Feb 2008 14:23:57 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Behave WG X-OriginalArrivalTime: 23 Feb 2008 19:24:08.0759 (UTC) FILETIME=[A9764C70:01C87651] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=810; t=1203794672; x=1204658672; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20updated=20rfc3489bis |Sender:=20 |To:=20Behave=20WG=20; bh=pOG/BWYihUAmV28C3LAtEmRXzhDhke9EqGN2MB9eltA=; b=NPj6jVy/z3iQPM/6AXE0yMSoAhSAV+qTdptSxR+R8178Y/mH8kit6svK9Y +Y5fqIeIpNa76SA9z+sDWtLK94n5RARAan91XTAcCvfs5CzspKAb6Z9O7ZSo wL96V7VX0i; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [BEHAVE] updated rfc3489bis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Just submitted: http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-15.txt Changes based on recent comments: * MTU limit from MUST to SHOULD, with an explanation of why (namely, behavior discovery) * added clarification on MD5 being the 16 byte output and not ascii armored, also including an example. This was some text that was in 3489bis till -05 and got lost in the big rewrite to -06. * clarified that the MTU limit applies to the entire datagram and not just the STUN message -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Feb 23 11:30:06 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 450E628C3E1; Sat, 23 Feb 2008 11:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWZbLU1U4OZ0; Sat, 23 Feb 2008 11:30:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C89A528C37B; Sat, 23 Feb 2008 11:30:04 -0800 (PST) X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8C6AD28C27E; Sat, 23 Feb 2008 11:30:02 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080223193002.8C6AD28C27E@core3.amsl.com> Date: Sat, 23 Feb 2008 11:30:02 -0800 (PST) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-rfc3489bis-15.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Session Traversal Utilities for (NAT) (STUN) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-behave-rfc3489bis-15.txt Pages : 51 Date : 2008-02-23 Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with NAT traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution. This document obsoletes RFC 3489. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-15.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-behave-rfc3489bis-15.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-behave-rfc3489bis-15.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-23112023.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-rfc3489bis-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-rfc3489bis-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-23112023.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Sat Feb 23 11:50:51 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31D603A6BC2; Sat, 23 Feb 2008 11:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[AWL=-0.803, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYmKkTkaq1YT; Sat, 23 Feb 2008 11:50:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DD263A6A58; Sat, 23 Feb 2008 11:50:50 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AACBB3A6A43 for ; Sat, 23 Feb 2008 11:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hm1pQxHOYaeY for ; Sat, 23 Feb 2008 11:50:47 -0800 (PST) Received: from mail-09.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 44E683A6998 for ; Sat, 23 Feb 2008 11:50:47 -0800 (PST) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JT0OQ-0004k0-1i; Sat, 23 Feb 2008 14:50:42 -0500 In-Reply-To: <47C072CD.3050003@cisco.com> References: <47C072CD.3050003@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <58EB653D-BFD2-4B96-8AB7-AC4335A3FBFC@magma.ca> From: Philip Matthews Date: Sat, 23 Feb 2008 14:50:39 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: Behave WG Subject: Re: [BEHAVE] updated rfc3489bis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Sat, 23-Feb-08, at 14:23 , Jonathan Rosenberg wrote: > Just submitted: > http://www.ietf.org/internet-drafts/draft-ietf-behave- > rfc3489bis-15.txt > > Changes based on recent comments: > > * MTU limit from MUST to SHOULD, with an explanation of why (namely, > behavior discovery) We also need this for TURN. Though TURN-07 says that an application using TURN should either do Path MTU discovery or obey these limits, I don't think that TURN client or server code should drop application data if the resulting Send or Data indication would violate these limits. > > * added clarification on MD5 being the 16 byte output and not ascii > armored, also including an example. This was some text that was in > 3489bis till -05 and got lost in the big rewrite to -06. Actually, the big rewrite was -07 and thus most likely my fault. Sorry. > > * clarified that the MTU limit applies to the entire datagram and not > just the STUN message > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > _______________________________________________ > Behave mailing list > Behave@ietf.org > http://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 25 08:15:37 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBDA83A6CF2; Mon, 25 Feb 2008 08:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnRYWex3q+CC; Mon, 25 Feb 2008 08:15:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E0B73A6D3A; Mon, 25 Feb 2008 08:15:05 -0800 (PST) X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 83CAF28C4D0; Mon, 25 Feb 2008 08:15:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080225161501.83CAF28C4D0@core3.amsl.com> Date: Mon, 25 Feb 2008 08:15:01 -0800 (PST) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-turn-07.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-behave-turn-07.txt Pages : 49 Date : 2008-02-25 If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers) located behind other NATs. In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. The TURN protocol can be used in isolation, but is more properly used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-behave-turn-07.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-behave-turn-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-25080811.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-turn-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-turn-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-25080811.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Mon Feb 25 08:30:48 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66C953A6D7B; Mon, 25 Feb 2008 08:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.178 X-Spam-Level: X-Spam-Status: No, score=-1.178 tagged_above=-999 required=5 tests=[AWL=-0.741, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pn9JcVYzcBKF; Mon, 25 Feb 2008 08:30:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15B8E3A6D41; Mon, 25 Feb 2008 08:27:09 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 092A93A6DA4 for ; Mon, 25 Feb 2008 08:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIybrK7L1frZ for ; Mon, 25 Feb 2008 08:27:05 -0800 (PST) Received: from mail-09.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 76AE53A6D41 for ; Mon, 25 Feb 2008 08:24:48 -0800 (PST) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JTg89-00044y-1y; Mon, 25 Feb 2008 11:24:41 -0500 Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <1AA36692-D467-47DB-94C6-5D511A941B27@magma.ca> From: Philip Matthews Date: Mon, 25 Feb 2008 11:24:40 -0500 To: Behave WG X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: Rohan Mahy , Dan Wing Subject: [BEHAVE] draft-ietf-behave-turn-07 submitted X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Folks: I have just submitted the -07 version of TURN to the repository. Much of the draft has been rewritten since the -06 version. All the changes that we have agreed on since the -06 version have been implemented. In addition, for the minor issues that we never discussed, I simply selected what I thought was the best solution. I also discovered some minor things as I was writing and changed the text to fix them. Finally, a number of sections were rewritten simply to try to improve the presentation. There are three open issues left in the document. They are listed in section 20. By far the biggest is what to do about the BANDWIDTH attribute. We have agreed to leave this in, but more clarification on what I means is still required. I did not have time to research this, so I simply put a placeholder proposal into the document. This was mostly to allow people who wanted to to implement something, rather than being a serious proposal. I plan to research a more serious proposal soon, so we can discuss it at Philly. - Philip 19.1. Changes from -06 to -07 o Rewrote the General Behavior section, making various changes in the process. o Changed the usage of authentication from MUST to SHOULD. o Changed the requirement that subsequent requests use the same username and password from MUST to SHOULD to allow for the possibility of changing the credentials using some unspecified mechanism. o Introduced a 438 (Wrong Credentials) error which is used when a non-Allocate request authenticates but does not use the same username and password as the Allocate request. Having a separate error code for this case avoids the client being confused over what the error actually is. o The server must now prevent the relayed transport address and the 5-tuple from being reused in different allocations for 2 minutes after the allocation expires. o Changed the usage of FINGERPRINT from MUST NOT to MAY, to allow for the possible multiplexing of TURN with some other protocol. o Rewrote much of the section on Allocations, splitting it into three new sections (one on allocations in general, one on creating an allocation, and one on refreshing an allocation). o Replaced the mechanism for requesting relayed transport addresses with specific properties. The new mechanism is less powerful: a client can request an even port, or a pair of ports, but cannot request a single odd port or a specific port as was possible under the old mechanism. Nor can the client request a specific IP address. o Changed the rules for handling ALTERNATE-SERVER, removing the requirement that the referring server have "positive knowledge" about the state of the alternate server. The new rules instead rely on text in STUN to prevent referral loops. o Changed the rules for allocation lifetimes. Allocations lifetimes are now a minimum of 10 minutes; the client can ask for longer values, but requests for shorter values are ignored. The text now recommends that the client refresh an allocation one minute before Rosenberg, et al. Expires August 28, 2008 [Page 41] Internet-Draft TURN February 2008 it expires. o Put in temporary procedures for handling the BANDWIDTH attribute, modelled on the LIFETIME attribute. These procedures are mostly placeholders and likely to change in the next revision. o Added a detailed description of how a client reacts to the various errors it can receive in reply to an Allocate request. This replaces the various descriptions that were previously scattered throughout the document, which were inconsistent and sometimes contradictory. o Added a new section that gives the normative rules for permissions. o Changed the rules around permission lifetimes. The text used to recommend a value of one minute; it MUST now be 5 minutes. o Removed the errors "Channel Missing or Invalid", "Peer Address Missing or Invalid" and "Lifetime Malformed or Invalid" and used 400 "Bad Request" instead. o Rewrote portions of the section on Send and Data indications and the section on Channels to try to make the client vs. server behavior clearer. o Channel bindings now expire after 10 minutes, and must be refreshed to keep them alive. o Binding a channel now installs or refreshes a permission for the IP address of corresponding peer. o Changed the wording describing the situation when the client sends a ChannelData message before receiving the ChannelBind success response. -06 said that client SHOULD NOT do this; -07 now says that a client MAY, but describes the consequences of doing it. o Added a section discussing the setting of fields in the IP header. o Replaced the REQUESTED-PORT-PROPS attribute with the REQUESTED- PROPS attribute that has a different format and semantics, but reuses the same code point. o Replaced the REQUESTED-IP attribute with the RESERVATION-TOKEN attribute, which has a different format and semantics, but reuses the same code point. Rosenberg, et al. Expires August 28, 2008 [Page 42] Internet-Draft TURN February 2008 o Removed error codes 443 and 444, and replaced them with 508 (Insufficient Port Capacity). Also changed the error text for code 507 from "Insufficient Capacity" to "Insufficient Bandwidth Capacity". _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 25 08:42:55 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D04AB28C572; Mon, 25 Feb 2008 08:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[AWL=-0.463, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zdc4xW4SbqVw; Mon, 25 Feb 2008 08:42:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20F3F3A6875; Mon, 25 Feb 2008 08:42:52 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB8133A6B8F for ; Mon, 25 Feb 2008 08:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyPkVAOLy2mX for ; Mon, 25 Feb 2008 08:42:50 -0800 (PST) Received: from mail.sipeerior.com (mail.sipeerior.com [128.239.5.131]) by core3.amsl.com (Postfix) with ESMTP id F01023A67A2 for ; Mon, 25 Feb 2008 08:41:49 -0800 (PST) Received: from [128.239.5.143] (unknown [128.239.5.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sipeerior.com (Postfix) with ESMTP id 08ACD505B0A; Mon, 25 Feb 2008 11:41:43 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Bruce Lowekamp Date: Mon, 25 Feb 2008 11:41:42 -0500 To: Behave WG X-Mailer: Apple Mail (2.753) Cc: Dan Wing Subject: [BEHAVE] nat-behavior-discovery updated X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org I have just uploaded version -03 of nat-behavior-discovery. Changes Derek and I have made since -02 include: * fix terminology for endpoint-independent, address-dependent, and address and port-dependent from rfc4787 * define the ALG detection to apply to UDP and TCP * fix >From typo in 9.5 * added exception to single MTU size restriction for PADDING * removed OPEN ISSUE about CHANGE-REQUEST IANA registry based on the belief that we need to list that definition here now that 3489bis is dropping it. _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 25 08:45:18 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 222D828C6BC; Mon, 25 Feb 2008 08:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HlbyNHVfpaF; Mon, 25 Feb 2008 08:45:14 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7CFD28C4FC; Mon, 25 Feb 2008 08:45:12 -0800 (PST) X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C2B6C3A68ED; Mon, 25 Feb 2008 08:45:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080225164501.C2B6C3A68ED@core3.amsl.com> Date: Mon, 25 Feb 2008 08:45:01 -0800 (PST) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-nat-behavior-discovery-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : NAT Behavior Discovery Using STUN Author(s) : D. MacDonald, B. Lowekamp Filename : draft-ietf-behave-nat-behavior-discovery-03.txt Pages : 28 Date : 2008-02-25 This specification defines an experimental usage of the Simple Traversal Underneath Network Address Translators (NAT) (STUN) Protocol that discovers the presence and current behaviour of NATs and firewalls between the STUN client and the STUN server.Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-behavior-discovery-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-behave-nat-behavior-discovery-03.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-behave-nat-behavior-discovery-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-25084116.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-nat-behavior-discovery-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-nat-behavior-discovery-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-25084116.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Fri Feb 29 03:55:21 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C00828C851; Fri, 29 Feb 2008 03:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.727 X-Spam-Level: X-Spam-Status: No, score=-1.727 tagged_above=-999 required=5 tests=[AWL=-1.290, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pld69bl3Hy5S; Fri, 29 Feb 2008 03:55:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C618E3A6F2E; Fri, 29 Feb 2008 03:55:17 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AC353A6F25 for ; Fri, 29 Feb 2008 03:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDernagf5zbQ for ; Fri, 29 Feb 2008 03:55:12 -0800 (PST) Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by core3.amsl.com (Postfix) with ESMTP id 8703828C5F7 for ; Fri, 29 Feb 2008 03:55:12 -0800 (PST) Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 6D4DD2D8D; Fri, 29 Feb 2008 13:55:04 +0200 (EET) X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id C9D892D8C; Fri, 29 Feb 2008 13:55:03 +0200 (EET) Date: Fri, 29 Feb 2008 13:55:03 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: behave@ietf.org Message-ID: MIME-Version: 1.0 Cc: hip-nat-traversal@piuha.net Subject: [BEHAVE] STUN and RFC3948 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Folks, we have been discussing about STUN and RFC3948 compatibility with the NAT traversal design team for HIP. The design team has planned to use STUN/ICE for connectivity tests and keepalives for HIP. However, we found out an incompatibility with STUN and UDP encapsulation of IPsec ESP [RFC3948] (HIP uses ESP). The problem is that section 2.2. in RFC3948 assumes 32-bits of zeroes after the UDP header. We would have HIP, STUN and ESP messages arriving at the same UDP port number and being demuxed using the 32-bits after the UDP header based on the following: * HIP (or IKE): zero bytes [RFC3948] * ESP: non-zero bytes [RFC3948] * STUN: 0x00 + length + type [RFC3489bis-14] (* IPsec keepalive: 0xFF [RFC3948]) There is conflict between demuxing ESP and STUN in the current standards. I wonder if it would still be possible to add 32-bits of zeroes in the beginning of STUN header to make it compatible with RFC3948? I would image that this could make STUN more attractive solution also to some other protocols such as IKE. We could also bend ESP towards this direction, but unfortunately it appears to imply some negative tradeoffs related to security, performance and deployment. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 29 04:22:18 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FF7328C16D; Fri, 29 Feb 2008 04:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.153 X-Spam-Level: X-Spam-Status: No, score=-0.153 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIOW1dRubP1u; Fri, 29 Feb 2008 04:22:12 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D04C23A6D0B; Fri, 29 Feb 2008 04:22:12 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A91483A6CD4 for ; Fri, 29 Feb 2008 04:22:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2whmKnCUNRd for ; Fri, 29 Feb 2008 04:22:06 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id DAEF83A6AAB for ; Fri, 29 Feb 2008 04:22:05 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1TCLjQw001358; Fri, 29 Feb 2008 14:21:55 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 14:20:39 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 14:20:39 +0200 Received: from esdhcp04151.research.nokia.com ([172.21.41.51]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 14:20:39 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Date: Fri, 29 Feb 2008 14:20:48 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200802291420.48974.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 29 Feb 2008 12:20:39.0726 (UTC) FILETIME=[7EFA0CE0:01C87ACD] X-Nokia-AV: Clean Cc: hip-nat-traversal@piuha.net, pasi.eronen@nokia.com Subject: Re: [BEHAVE] STUN and RFC3948 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Le Friday 29 February 2008 13:55:03 ext Miika Komu, vous avez =E9crit=A0: > we have been discussing about STUN and RFC3948 compatibility with the NAT > traversal design team for HIP. The design team has planned to use STUN/ICE > for connectivity tests and keepalives for HIP. Makes sense. > However, we found out an = > incompatibility with STUN and UDP encapsulation of IPsec ESP [RFC3948] > (HIP uses ESP). > > The problem is that section 2.2. in RFC3948 assumes 32-bits of zeroes > after the UDP header. We would have HIP, STUN and ESP messages arriving at > the same UDP port number and being demuxed using the 32-bits after the UDP > header based on the following: > > * HIP (or IKE): zero bytes [RFC3948] > * ESP: non-zero bytes [RFC3948] > * STUN: 0x00 + length + type [RFC3489bis-14] > (* IPsec keepalive: 0xFF [RFC3948]) This does not affect the validity of your point, but STUN does not start wi= th = a zero byte, it starts with two zero bits. > There is conflict between demuxing ESP and STUN in the current standards. > I wonder if it would still be possible to add 32-bits of zeroes in the > beginning of STUN header to make it compatible with RFC3948? I would image > that this could make STUN more attractive solution also to some other > protocols such as IKE. As long as the first two bits remain zeroes, we can demux STUN from RTP, wh= ich = is what SIP and XMPP need. In that sense, this would be do-able. And it wou= ld = allow using ICE cleanly with ESP-in-UDP - not only HIP. However, this would totally break backward compatibility with RFC3489. This= is = not a problem for ICE, but is a problem for STUN binding discovery (which I= CE = relies upon anyway) with RFC3489 STUN servers - i.e. those currently deploy= ed = STUN servers. That had probably better be avoided. > We could also bend ESP towards this direction, but unfortunately it > appears to imply some negative tradeoffs related to security, performance > and deployment. You mean, like adding restrictions on the SPI field? I don't know IPsec wel= l = enough to realistically comment on this. Did you consider the use of the STUN FINGERPRINT attribute? I am not sure i= f = it would have serious security implications. -- = R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 29 05:43:09 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC2BB28C510; Fri, 29 Feb 2008 05:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.894 X-Spam-Level: X-Spam-Status: No, score=-0.894 tagged_above=-999 required=5 tests=[AWL=-0.757, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWUun6Uevu40; Fri, 29 Feb 2008 05:43:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EFEE3A6CDA; Fri, 29 Feb 2008 05:43:07 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFAF33A69FD for ; Fri, 29 Feb 2008 05:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZuQam-L1ZJ5 for ; Fri, 29 Feb 2008 05:43:00 -0800 (PST) Received: from mail-09.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 9E13928C23D for ; Fri, 29 Feb 2008 05:42:34 -0800 (PST) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JV5VL-0003uc-0h; Fri, 29 Feb 2008 08:42:27 -0500 In-Reply-To: <200802291420.48974.remi.denis-courmont@nokia.com> References: <200802291420.48974.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Philip Matthews Date: Fri, 29 Feb 2008 08:42:28 -0500 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: pasi.eronen@nokia.com, behave@ietf.org, hip-nat-traversal@piuha.net Subject: Re: [BEHAVE] STUN and RFC3948 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Fri, 29-Feb-08, at 07:20 , R=E9mi Denis-Courmont wrote: > >> We could also bend ESP towards this direction, but unfortunately it >> appears to imply some negative tradeoffs related to security, = >> performance >> and deployment. > > You mean, like adding restrictions on the SPI field? I don't know = > IPsec well > enough to realistically comment on this. Yes. As long as the SPI field does not look like 00........00, the = demux is simple. However, I am not enough of a security expert to = know what affect putting this restriction on the SPI field might have = on ESP security. > > Did you consider the use of the STUN FINGERPRINT attribute? I am = > not sure if > it would have serious security implications. Yes. Without a restriction in the SPI range, it seems that the only = way to demux is to do the full suite of STUN demux tests: * First longword looks like 00...........00 * Second longword contains the magic cookie value. * STUN packet contains a FINGERPRINT attribute. Packets passing all three tests are STUN, others are ESP. It is certainly possible to do this. There was just some grumblings = about the time/complexity of implementing the third test, especially = since some OSes process ESP packets in the kernel. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 29 05:46:58 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AB303A6F3A; Fri, 29 Feb 2008 05:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=-0.626, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_43=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TLsXYOkxREI; Fri, 29 Feb 2008 05:46:57 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BCD63A6A56; Fri, 29 Feb 2008 05:46:57 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D70173A6F29 for ; Fri, 29 Feb 2008 05:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeVqDmvmVF89 for ; Fri, 29 Feb 2008 05:46:56 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 01CEB28C23D for ; Fri, 29 Feb 2008 05:46:56 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 63FF221281; Fri, 29 Feb 2008 14:32:27 +0100 (CET) X-AuditID: c1b4fb3c-ae8bcbb000007e19-71-47c8096b699d Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 524A021277; Fri, 29 Feb 2008 14:32:27 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 14:32:26 +0100 Received: from [127.0.0.1] ([147.214.30.103]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 14:32:26 +0100 Message-ID: <47C8096A.5050002@ericsson.com> Date: Fri, 29 Feb 2008 14:32:26 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: draft-ietf-behave-turn@tools.ietf.org, Behave WG X-OriginalArrivalTime: 29 Feb 2008 13:32:26.0711 (UTC) FILETIME=[8623CE70:01C87AD7] X-Brightmail-Tracker: AAAAAA== Subject: [BEHAVE] TURN 07: Channel ID collisions with usage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Hi, In the review of TURN 07 I found that the draft doesn't at all take care of a case I asked about previous. The allocation response include the server reflexive address to the TURN client. The only reason for doing this is to enable a client to co-locate both a TURN client and a direct STUN+UDP based protocol, for example RTP, on the same port. However, the TURN channel header has overlap with RTP thus causing a demultiplexing collision when channel numbers in the 8000-8FFF range is used. This seriously need to be taken care of. I think the simplest thing is to stop co-locating the TURN client with anything else. And thus also the XOR-MAPPED-ADDRESS should not be returned in the allocate response either. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 29 06:36:06 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0A2F3A6F14; Fri, 29 Feb 2008 06:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_43=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LW-7QxFoonAe; Fri, 29 Feb 2008 06:36:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A59B23A6D71; Fri, 29 Feb 2008 06:36:05 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78D0E3A6B67 for ; Fri, 29 Feb 2008 06:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rH0hGC80j75o for ; Fri, 29 Feb 2008 06:36:00 -0800 (PST) Received: from figas.ekabal.com (figas.ekabal.com [204.61.215.10]) by core3.amsl.com (Postfix) with ESMTP id 7D7893A6784 for ; Fri, 29 Feb 2008 06:36:00 -0800 (PST) Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id m1TEZMo10460; Fri, 29 Feb 2008 06:35:22 -0800 In-Reply-To: <47C8096A.5050002@ericsson.com> References: <47C8096A.5050002@ericsson.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <00A7B7ED-315D-457B-BDD2-74F13812D8F4@ekabal.com> From: Rohan Mahy Date: Fri, 29 Feb 2008 06:35:16 -0800 To: Magnus Westerlund X-Mailer: Apple Mail (2.753) Cc: Rohan Mahy , draft-ietf-behave-turn@tools.ietf.org, Behave WG Subject: Re: [BEHAVE] TURN 07: Channel ID collisions with usage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Hi Magnus, The main motivation to return XOR-MAPPED-ADDRESS is so the client can issue one request which provides the equivalent of a STUN response and a TURN response at the same time. Then ICE will usually pick the server reflexive address from XOR-MAPPED-ADDRESS instead of the relayed address, and either explicitly deallocate the relayed address or let it time out. thanks, -rohan On Feb 29, 2008, at 5:32 AM, Magnus Westerlund wrote: > Hi, > > In the review of TURN 07 I found that the draft doesn't at all take > care of a case I asked about previous. > > The allocation response include the server reflexive address to the > TURN client. The only reason for doing this is to enable a client > to co-locate both a TURN client and a direct STUN+UDP based > protocol, for example RTP, on the same port. > > However, the TURN channel header has overlap with RTP thus causing > a demultiplexing collision when channel numbers in the 8000-8FFF > range is used. > > This seriously need to be taken care of. I think the simplest thing > is to stop co-locating the TURN client with anything else. And thus > also the XOR-MAPPED-ADDRESS should not be returned in the allocate > response either. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 29 06:58:34 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B40543A6CDD; Fri, 29 Feb 2008 06:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[AWL=-0.604, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_43=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26c4KhAYqLAd; Fri, 29 Feb 2008 06:58:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 908053A6BB2; Fri, 29 Feb 2008 06:58:33 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7487228C2DE for ; Fri, 29 Feb 2008 06:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3g5PgdcHK21 for ; Fri, 29 Feb 2008 06:58:25 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id F24A328C3B5 for ; Fri, 29 Feb 2008 06:57:58 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 962A921B33; Fri, 29 Feb 2008 15:44:08 +0100 (CET) X-AuditID: c1b4fb3c-af0bdbb000007e19-20-47c81a38824f Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 898B021B30; Fri, 29 Feb 2008 15:44:08 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 15:44:08 +0100 Received: from [127.0.0.1] ([147.214.30.103]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 15:44:08 +0100 Message-ID: <47C81A37.4030703@ericsson.com> Date: Fri, 29 Feb 2008 15:44:07 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Rohan Mahy References: <47C8096A.5050002@ericsson.com> <00A7B7ED-315D-457B-BDD2-74F13812D8F4@ekabal.com> In-Reply-To: <00A7B7ED-315D-457B-BDD2-74F13812D8F4@ekabal.com> X-OriginalArrivalTime: 29 Feb 2008 14:44:08.0219 (UTC) FILETIME=[8A09D6B0:01C87AE1] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-behave-turn@tools.ietf.org, Behave WG Subject: Re: [BEHAVE] TURN 07: Channel ID collisions with usage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Rohan Mahy skrev: > Hi Magnus, > > The main motivation to return XOR-MAPPED-ADDRESS is so the client can > issue one request which provides the equivalent of a STUN response and a > TURN response at the same time. Then ICE will usually pick the server > reflexive address from XOR-MAPPED-ADDRESS instead of the relayed > address, and either explicitly deallocate the relayed address or let it > time out. But my point is that you can't reliable demultiplex TURN with channel bindings and RTP/UDP being delivered directly to the port. Thus if one use TURN to get both a relayed and server reflexive candidate in ICE one can shoot oneself in the foot unless one have completed ICE and deallocated the other candidate prior to doing a channel binding. This needs to be resolved somehow! > > thanks, > -rohan > > On Feb 29, 2008, at 5:32 AM, Magnus Westerlund wrote: > >> Hi, >> >> In the review of TURN 07 I found that the draft doesn't at all take >> care of a case I asked about previous. >> >> The allocation response include the server reflexive address to the >> TURN client. The only reason for doing this is to enable a client to >> co-locate both a TURN client and a direct STUN+UDP based protocol, for >> example RTP, on the same port. >> >> However, the TURN channel header has overlap with RTP thus causing a >> demultiplexing collision when channel numbers in the 8000-8FFF range >> is used. >> >> This seriously need to be taken care of. I think the simplest thing is >> to stop co-locating the TURN client with anything else. And thus also >> the XOR-MAPPED-ADDRESS should not be returned in the allocate response >> either. >> >> Cheers >> >> Magnus Westerlund >> >> IETF Transport Area Director & TSVWG Chair >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 8 4048287 >> Torshamsgatan 23 | Fax +46 8 7575550 >> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- > > -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 29 07:20:22 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1488728C671; Fri, 29 Feb 2008 07:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.269 X-Spam-Level: X-Spam-Status: No, score=-0.269 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_43=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6UZMASvUv1Z; Fri, 29 Feb 2008 07:20:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C04728C426; Fri, 29 Feb 2008 07:20:08 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A92C28C426 for ; Fri, 29 Feb 2008 07:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPPaLaUHhXJ9 for ; Fri, 29 Feb 2008 07:20:00 -0800 (PST) Received: from figas.ekabal.com (figas.ekabal.com [204.61.215.10]) by core3.amsl.com (Postfix) with ESMTP id DAD4228C414 for ; Fri, 29 Feb 2008 07:19:53 -0800 (PST) Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id m1TFJLo11726; Fri, 29 Feb 2008 07:19:21 -0800 In-Reply-To: <47C81A37.4030703@ericsson.com> References: <47C8096A.5050002@ericsson.com> <00A7B7ED-315D-457B-BDD2-74F13812D8F4@ekabal.com> <47C81A37.4030703@ericsson.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <2586C64F-4F3E-41A9-9BCA-6A02505CCB23@ekabal.com> From: Rohan Mahy Date: Fri, 29 Feb 2008 07:19:16 -0800 To: Magnus Westerlund X-Mailer: Apple Mail (2.753) Cc: Rohan Mahy , draft-ietf-behave-turn@tools.ietf.org, Behave WG Subject: Re: [BEHAVE] TURN 07: Channel ID collisions with usage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Hi Magnus, With this feature, there is no multiplexing of TURN and another protocol. A softphone application on Alice's PC goes sends a TURN Allocate Request through her home NAT to turn.example.net. She takes the RELAYED-ADDRESS and the XOR-MAPPED-ADDRESS and puts these in ICE candidates in an offer that she sends to Bob's UA. She could have also sent a STUN Binding Request to stun.example.net instead to get the XOR-MAPPED-ADDRESS, but that would require an additional transaction for Alice's UA. This convenience feature has nothing to do with ICE connectivity checks which are different STUN requests sent either directly to Alice's UA or forwarded through a relayed address used by Alice on the TURN server. ICE does not suggest in any way that Alice or Bob will accept *TURN* requests on the same port used for RTP. Does this make sense? thanks, -rohan On Feb 29, 2008, at 6:44 AM, Magnus Westerlund wrote: > Rohan Mahy skrev: >> Hi Magnus, >> The main motivation to return XOR-MAPPED-ADDRESS is so the client >> can issue one request which provides the equivalent of a STUN >> response and a TURN response at the same time. Then ICE will >> usually pick the server reflexive address from XOR-MAPPED-ADDRESS >> instead of the relayed address, and either explicitly deallocate >> the relayed address or let it time out. > > But my point is that you can't reliable demultiplex TURN with > channel bindings and RTP/UDP being delivered directly to the port. > Thus if one use TURN to get both a relayed and server reflexive > candidate in ICE one can shoot oneself in the foot unless one have > completed ICE and deallocated the other candidate prior to doing a > channel binding. > > This needs to be resolved somehow! > >> thanks, >> -rohan >> On Feb 29, 2008, at 5:32 AM, Magnus Westerlund wrote: >>> Hi, >>> >>> In the review of TURN 07 I found that the draft doesn't at all >>> take care of a case I asked about previous. >>> >>> The allocation response include the server reflexive address to >>> the TURN client. The only reason for doing this is to enable a >>> client to co-locate both a TURN client and a direct STUN+UDP >>> based protocol, for example RTP, on the same port. >>> >>> However, the TURN channel header has overlap with RTP thus >>> causing a demultiplexing collision when channel numbers in the >>> 8000-8FFF range is used. >>> >>> This seriously need to be taken care of. I think the simplest >>> thing is to stop co-locating the TURN client with anything else. >>> And thus also the XOR-MAPPED-ADDRESS should not be returned in >>> the allocate response either. >>> >>> Cheers >>> >>> Magnus Westerlund >>> >>> IETF Transport Area Director & TSVWG Chair >>> -------------------------------------------------------------------- >>> -- >>> Multimedia Technologies, Ericsson Research EAB/TVM >>> -------------------------------------------------------------------- >>> -- >>> Ericsson AB | Phone +46 8 4048287 >>> Torshamsgatan 23 | Fax +46 8 7575550 >>> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>> -------------------------------------------------------------------- >>> -- > > > -- > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 29 07:36:36 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C52C28C242; Fri, 29 Feb 2008 07:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.727 X-Spam-Level: X-Spam-Status: No, score=-0.727 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nY4Q3lahOCv; Fri, 29 Feb 2008 07:36:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A759628C386; Fri, 29 Feb 2008 07:36:30 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88BC928C173 for ; Fri, 29 Feb 2008 07:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDjVITktuWN5 for ; Fri, 29 Feb 2008 07:36:28 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 30EA628C242 for ; Fri, 29 Feb 2008 07:36:28 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 50EB322220; Fri, 29 Feb 2008 16:18:13 +0100 (CET) X-AuditID: c1b4fb3e-a99fdbb000000b15-07-47c822356c5e Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 31FA82221D; Fri, 29 Feb 2008 16:18:13 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 16:18:12 +0100 Received: from [127.0.0.1] ([147.214.30.103]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 16:18:12 +0100 Message-ID: <47C82234.2000905@ericsson.com> Date: Fri, 29 Feb 2008 16:18:12 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: draft-ietf-behave-turn@tools.ietf.org, Behave WG X-OriginalArrivalTime: 29 Feb 2008 15:18:12.0821 (UTC) FILETIME=[4CB75850:01C87AE6] X-Brightmail-Tracker: AAAAAA== Subject: [BEHAVE] TURN 07: Header bits (Section 11) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Hi, I have now reviewed what you have written in section 11 and have the following comments and observations: A. Section 11.1, last paragraph on page 32: Why is this paragraph here? I find it very strange. If you can read it sometimes you should be able to read it all the times. Also I think allowing something like this for efficiency reasons is the wrong reason. If there exist other reasons then that may make more sense. B. Section 11.1: It is missing what behavior you should have if you can't read the DSCP field. Defaulting to best effort seems to be the least harmful you can do. C. Section 11.2, first paragraph: When the client sends a Data indication or ChannelData message to the server using UDP IPv4, it SHOULD NOT set the DF (Don't Fragment) bit unless the application explicitly requests the bit to be set. I don't understand the motivation behind this. I the transport from TURN client to server any fragmentation that occur will trigger an ICMP towards the TURN client, that at least has no additional issues compared to non-related session to deal with this ICMP message. So why is this recommended? D. Section 11.2, Third paragraph: When using TCP or TLS over TCP, the client and the server MAY let the setting of the DF bit be determined by the TCP/IP stack. I think this MAY should be changed to SHOULD. There are no reason for the TURN server to interfere with the TCP connection and its selection of the TCP segment size which after all is what has the most relation to how large TCP packets are generated. E. Section 11.2, Second paragraph: When the server sends a UDP datagram to a peer over IPv4, or when sends a Data indication or a ChannelData message to the client using UDP over IPv4, the server SHOULD NOT set the DF bit. I agree that this is the right choice unless one actually are going to start generate ICMP messages in the relay. However, I think that one can point out that this is relying on the IPv4 fragmentation mechanism and affects loss probability, especially considering that NAT's capability to forward them. F. Section 11.2: What about IPv6 behavior? If I understand this correctly, this specification does allow relaying IPv4 to IPv4 and IPv6 to IPv6, but not either of IPv4 to IPv6 nor IPv6 to IPv4 which is what draft-ietf-behave-turn-ipv6 is for. I am missing how an IPv6 is going to deal with the fragmentation issue. That as any fragmentation needs to happen on the outgoing interface of the TURN server for traffic going to the TURN client. G. Section 11, More IPv6. What about the IPv6 Flow label in forwarding? Taking a look at RFC 3697 is recommened to ensure that TURN will fulfil the requirements. H. Section 11.3: The server SHOULD NOT preserve the ECN (Explicit Congestion Notification) field, and MAY preserve thee TTL (Time-To-Live) fields when relaying application data. It is not that simple as not preserving the ECN field. One actually have to mandate that the forwarded packets have the ECN field set to non-ECN capable. Otherwise you are indicating that you are capable but not listing to the information. That is not acceptable. In fact you have to to mandate that TURN clients (unless using TCP) SHALL NOT indicate that they are ECN capable. Also the Peers should if they now that they are being relayed by TURN not use ECN for UDP/IP. I. Section 11.4: I am missing the obvious recommendation that application that now that they are using TURN in the communication take some worst case figures into account when generating the packets. And those worst case figures should be shown how to calculate in this section. J. Proposal instead of bad compromise: I think we mostly know what a good TURN relay should do with the IP header fields. We also know what they can't do from user land. Why don't we define two behavior profiles. One for user land implementations that clearly explains what they loose. Then one for full relaying that does everything right. That way we can even include a "port req" attribute for requesting "full relay". Because if you are implementing a TURN server within the operating system you can set all the fields in the right way. I do want to indicate what the right thing to do would be, well knowing that it will mostly not be used. But there clearly are some deployments that could have advantage of "full relay". For full relay I would also like to look into what can be done on getting the ICMP relaying working. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 29 07:36:41 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C613E28C524; Fri, 29 Feb 2008 07:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.67 X-Spam-Level: X-Spam-Status: No, score=-0.67 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_43=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFo+ABaLSjJa; Fri, 29 Feb 2008 07:36:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBCFD28C409; Fri, 29 Feb 2008 07:36:33 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BBBA28C406 for ; Fri, 29 Feb 2008 07:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFf05VT-hHDS for ; Fri, 29 Feb 2008 07:36:26 -0800 (PST) Received: from mail-06.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id D844428C290 for ; Fri, 29 Feb 2008 07:36:25 -0800 (PST) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JV7HV-0006pz-2w; Fri, 29 Feb 2008 10:36:18 -0500 In-Reply-To: <47C8096A.5050002@ericsson.com> References: <47C8096A.5050002@ericsson.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Philip Matthews Date: Fri, 29 Feb 2008 10:36:16 -0500 To: Magnus Westerlund X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: draft-ietf-behave-turn@tools.ietf.org, Behave WG Subject: Re: [BEHAVE] TURN 07: Channel ID collisions with usage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Magnus: Thanks for point out this issue, which I had not previously considered. As I see it, there are a number of ways that a client can solve this problem: 1) Since the choice of channel numbers is totally under the control of the client, the client can avoid channel numbers that make demuxing a problem. In the case of RTP, this would mean that the client should avoid channel numbers that have the first two bits as either 00 or 10 (the first is used by STUN and the second is used by RTP). This still leaves 2^31 possible channel numbers. For application protocols other than RTP, the client may have to avoid other channel numbers. 2) If the client knows that, for a given call, its peers will either all use the direct path or all use the TURN server, then it can simply wait to allocate channel numbers until it knows which case it is dealing with. If all peers are going via the TURN server, then there can be no conflict with the application protocol (e.g. RTP) since all application protocol packets arrive at the client encapsulated inside either a Data indication or a ChannelData message, so all channel numbers except those starting with 00 can be used. 3) If the client is dealing with an application protocol where the demux problem is harder (for example, a protocol which allows arbitrary values in the first 32 bits), then the client must use a different client transport address to talk to the TURN server. In this case, the XOR-MAPPED-ADDRESS in the Allocate response is not useful. On a separate thread, we are discussing whether ESP falls into case (3). In terms of the document, I suggest adding text that basically says the above. I would make it general (i.e., not specific to RTP), but we could add an appendix that discusses the issue for certain specific application protocols. - Philip On Fri, 29-Feb-08, at 08:32 , Magnus Westerlund wrote: > Hi, > > In the review of TURN 07 I found that the draft doesn't at all take > care of a case I asked about previous. > > The allocation response include the server reflexive address to the > TURN client. The only reason for doing this is to enable a client > to co-locate both a TURN client and a direct STUN+UDP based > protocol, for example RTP, on the same port. > > However, the TURN channel header has overlap with RTP thus causing > a demultiplexing collision when channel numbers in the 8000-8FFF > range is used. > > This seriously need to be taken care of. I think the simplest thing > is to stop co-locating the TURN client with anything else. And thus > also the XOR-MAPPED-ADDRESS should not be returned in the allocate > response either. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 29 07:42:21 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCA0128C410; Fri, 29 Feb 2008 07:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.72 X-Spam-Level: X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4n2qsRq9P4m; Fri, 29 Feb 2008 07:42:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50EC028C3DA; Fri, 29 Feb 2008 07:42:16 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B59CB28C3E2 for ; Fri, 29 Feb 2008 07:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlVuawFi2Kv7 for ; Fri, 29 Feb 2008 07:42:09 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 06FEE28C3DA for ; Fri, 29 Feb 2008 07:42:08 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 71896213C7; Fri, 29 Feb 2008 16:34:08 +0100 (CET) X-AuditID: c1b4fb3c-ad8babb000007e19-59-47c825f07186 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 669A320FE8; Fri, 29 Feb 2008 16:34:08 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 16:34:08 +0100 Received: from [127.0.0.1] ([147.214.30.103]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 16:34:07 +0100 Message-ID: <47C825EF.6060307@ericsson.com> Date: Fri, 29 Feb 2008 16:34:07 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: draft-ietf-behave-turn@tools.ietf.org, Behave WG X-OriginalArrivalTime: 29 Feb 2008 15:34:07.0929 (UTC) FILETIME=[86014290:01C87AE8] X-Brightmail-Tracker: AAAAAA== Subject: [BEHAVE] TURN 07: Some more comments X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Hi, Here is the final comments I have from my review. 1. Section 6.1: The client first needs to pick a host transport address that the server does not think is currently in use, or was recently in use. The client SHOULD pick a currently-unused transport address on the client's host (typically by allowing its OS to pick a currently- unused port for a new socket). I found this section to be unclear and not discuss the issues. I guess the gist of this is that a host should not reuse a port that was used the last 2 minutes. The problem is reuse of the same port as earlier or getting the same server reflexive address as the previous allocation was done over. 2. Section 6.1: "The transport protocol MUST be one of UDP, TCP, or TLS over TCP." Can this be reformulated or extended to be clearer that the list can be extended in the future? 3. Section 10.7: "If there is, then it SHOULD form and send a ChannelData message as described in Section 10.5." I think the above sentence is in contradiction of the following sentence in section 10.5: "The server, on the other hand, MUST use the ChannelData message if a channel has been bound to the peer." 4. Section 13.3 Bandwidth: As pointed out this definition is still is an open issue. Either an average with defined averaging window or a token bucket. 5. Section 15: In the third paragraph there is "TODO" item. 6. Section 16: The registries needs to be explicitly named. For example: " The codepoints for the new STUN methods defined in this specification are listed in Section 12." Would be better written as: Register the 5 new STUN methods listed in Section 12 in the "STUN Methods" Registry. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 29 07:49:13 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB3693A6950; Fri, 29 Feb 2008 07:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.942 X-Spam-Level: X-Spam-Status: No, score=-0.942 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emgz+JN2XXQk; Fri, 29 Feb 2008 07:49:08 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 542773A69BD; Fri, 29 Feb 2008 07:49:08 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A10573A683B for ; Fri, 29 Feb 2008 07:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aba0h9MfCZ-y for ; Fri, 29 Feb 2008 07:49:02 -0800 (PST) Received: from mail-07.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 3D06128C23F for ; Fri, 29 Feb 2008 07:49:02 -0800 (PST) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JV7Td-00049C-1n; Fri, 29 Feb 2008 10:48:49 -0500 In-Reply-To: <2586C64F-4F3E-41A9-9BCA-6A02505CCB23@ekabal.com> References: <47C8096A.5050002@ericsson.com> <00A7B7ED-315D-457B-BDD2-74F13812D8F4@ekabal.com> <47C81A37.4030703@ericsson.com> <2586C64F-4F3E-41A9-9BCA-6A02505CCB23@ekabal.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <2BF0D6E8-AAD7-4527-9492-7A289986F0B0@magma.ca> From: Philip Matthews Date: Fri, 29 Feb 2008 10:48:53 -0500 To: Rohan Mahy X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: draft-ietf-behave-turn@tools.ietf.org, Behave WG Subject: Re: [BEHAVE] TURN 07: Channel ID collisions with usage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Fri, 29-Feb-08, at 10:19 , Rohan Mahy wrote: > With this feature, there is no multiplexing of TURN and another > protocol. > > A softphone application on Alice's PC goes sends a TURN Allocate > Request through her home NAT to turn.example.net. She takes the > RELAYED-ADDRESS and the XOR-MAPPED-ADDRESS and puts these in ICE > candidates in an offer that she sends to Bob's UA. She could have > also sent a STUN Binding Request to stun.example.net instead to get > the XOR-MAPPED-ADDRESS, but that would require an additional > transaction for Alice's UA. > > This convenience feature has nothing to do with ICE connectivity > checks which are different STUN requests sent either directly to > Alice's UA or forwarded through a relayed address used by Alice on > the TURN server. ICE does not suggest in any way that Alice or Bob > will accept *TURN* requests on the same port used for RTP. This is not quite true. If the client tries to use the same transport address for both direct connections and indirect connections via the TURN server, then the client will receive 4 different types of packets on the same transport address: 1) STUN-formatted TURN packets 2) STUN connectivity packets from the peer 3) RTP packets 4) ChannelData messages The client can demux these by looking at the first two bits in the packets: 00 - Packet is either case (1) or (2), and must be further demuxed by looking at the source transport address 01 - Packet is a ChannelData message 10 - Packet is an RTP packet 11 - Packet is a ChannelData message This only works if the client refrains from using channel numbers that start with 10. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 29 08:03:47 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44C5F28C5B1; Fri, 29 Feb 2008 08:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.42 X-Spam-Level: X-Spam-Status: No, score=-0.42 tagged_above=-999 required=5 tests=[AWL=-0.583, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_12=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xf4DzqdPd68H; Fri, 29 Feb 2008 08:03:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE83728C426; Fri, 29 Feb 2008 08:03:40 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A366428C346 for ; Fri, 29 Feb 2008 08:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPyoG+Z7G42k for ; Fri, 29 Feb 2008 08:03:37 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 07B7C3A6B0A for ; Fri, 29 Feb 2008 08:02:58 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3BD3D21DB1; Fri, 29 Feb 2008 16:45:05 +0100 (CET) X-AuditID: c1b4fb3e-aa1febb000000b15-39-47c828811f57 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3058A21D89; Fri, 29 Feb 2008 16:45:05 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 16:45:04 +0100 Received: from [127.0.0.1] ([147.214.30.103]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 16:45:03 +0100 Message-ID: <47C8287F.7050505@ericsson.com> Date: Fri, 29 Feb 2008 16:45:03 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Rohan Mahy References: <47C8096A.5050002@ericsson.com> <00A7B7ED-315D-457B-BDD2-74F13812D8F4@ekabal.com> <47C81A37.4030703@ericsson.com> <2586C64F-4F3E-41A9-9BCA-6A02505CCB23@ekabal.com> In-Reply-To: <2586C64F-4F3E-41A9-9BCA-6A02505CCB23@ekabal.com> X-OriginalArrivalTime: 29 Feb 2008 15:45:03.0784 (UTC) FILETIME=[0CECCA80:01C87AEA] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-behave-turn@tools.ietf.org, Behave WG Subject: Re: [BEHAVE] TURN 07: Channel ID collisions with usage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Rohan Mahy skrev: > Hi Magnus, > > With this feature, there is no multiplexing of TURN and another protocol. > > A softphone application on Alice's PC goes sends a TURN Allocate Request > through her home NAT to turn.example.net. She takes the RELAYED-ADDRESS > and the XOR-MAPPED-ADDRESS and puts these in ICE candidates in an offer > that she sends to Bob's UA. She could have also sent a STUN Binding > Request to stun.example.net instead to get the XOR-MAPPED-ADDRESS, but > that would require an additional transaction for Alice's UA. > > This convenience feature has nothing to do with ICE connectivity checks > which are different STUN requests sent either directly to Alice's UA or > forwarded through a relayed address used by Alice on the TURN server. > ICE does not suggest in any way that Alice or Bob will accept *TURN* > requests on the same port used for RTP. > > Does this make sense? Okay, take 3 to explain my headache. Alice's PC sends a TURN allocate request from port P on interface X to turn.example.net. It gets back two addresses: R:rp and S:sp, i.e. a relayed and a server reflexive address that both has X:P as base for them. This have the implications that when BOB sends his STUN checks to R:rp they will arrive at X:P in either a DATA indication or with a channelbinding header. BOB can also send his STUN check to S:sp that arrives at X:P without a TURN header. So far no major problems. The X:P can demultiplex directly arriving STUN requests and the ones that first goes to the TURN client. But we also have the capability to handle data on this socket. In fact one could illustrate the multiplexing like this: /-- Data receiver / /- TURN Client ---- STUN Server / X:P ----- STUN server \ \- Data receiver The issue is that a RTP data receiver both would like to have data with payloads starting with 10 in the first octet. Thus you are unable to decide what the correct demultiplexing in this case is, at least as long as you are using channelID in the 8000-8FFF range with RTP. Do you now see the issue? Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 29 08:04:13 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07B3228C4E5; Fri, 29 Feb 2008 08:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.708 X-Spam-Level: X-Spam-Status: No, score=-0.708 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2fhpz2XkzDn; Fri, 29 Feb 2008 08:04:07 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70AFE28C1A9; Fri, 29 Feb 2008 08:04:07 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD53C28C1EA for ; Fri, 29 Feb 2008 08:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 738UeI0DxVSd for ; Fri, 29 Feb 2008 08:04:00 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id F16003A68A3 for ; Fri, 29 Feb 2008 08:03:59 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C6DA621C9F; Fri, 29 Feb 2008 16:47:39 +0100 (CET) X-AuditID: c1b4fb3e-a81fabb000000b15-3f-47c8291b6e1b Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AF44C218E0; Fri, 29 Feb 2008 16:47:39 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 16:47:39 +0100 Received: from [127.0.0.1] ([147.214.30.103]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 16:47:38 +0100 Message-ID: <47C8291A.5080002@ericsson.com> Date: Fri, 29 Feb 2008 16:47:38 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Philip Matthews References: <47C8096A.5050002@ericsson.com> In-Reply-To: X-OriginalArrivalTime: 29 Feb 2008 15:47:38.0726 (UTC) FILETIME=[69471060:01C87AEA] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-behave-turn@tools.ietf.org, Behave WG Subject: Re: [BEHAVE] TURN 07: Channel ID collisions with usage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Philip Matthews skrev: > Magnus: > > Thanks for point out this issue, which I had not previously considered. > As I see it, there are a number of ways that a client can solve this > problem: > > 1) Since the choice of channel numbers is totally under the control of > the client, the client can avoid channel numbers that make demuxing a > problem. In the case of RTP, this would mean that the client should > avoid channel numbers that have the first two bits as either 00 or 10 > (the first is used by STUN and the second is used by RTP). This still > leaves 2^31 possible channel numbers. For application protocols other > than RTP, the client may have to avoid other channel numbers. > > 2) If the client knows that, for a given call, its peers will either all > use the direct path or all use the TURN server, then it can simply wait > to allocate channel numbers until it knows which case it is dealing > with. If all peers are going via the TURN server, then there can be no > conflict with the application protocol (e.g. RTP) since all application > protocol packets arrive at the client encapsulated inside either a Data > indication or a ChannelData message, so all channel numbers except those > starting with 00 can be used. > > 3) If the client is dealing with an application protocol where the demux > problem is harder (for example, a protocol which allows arbitrary values > in the first 32 bits), then the client must use a different client > transport address to talk to the TURN server. In this case, the > XOR-MAPPED-ADDRESS in the Allocate response is not useful. > > On a separate thread, we are discussing whether ESP falls into case (3). > > In terms of the document, I suggest adding text that basically says the > above. I would make it general (i.e., not specific to RTP), but we could > add an appendix that discusses the issue for certain specific > application protocols. > Yes, I think it is important to point out the issue clearly. I think another thing that the client can do is to not use channelbindings until one has promoted a single candidate and closed down the other multiplexing points. First when this is accomplished can one start using channelbindings. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 29 08:49:16 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF0D328C4C4; Fri, 29 Feb 2008 08:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.939 X-Spam-Level: X-Spam-Status: No, score=-0.939 tagged_above=-999 required=5 tests=[AWL=-0.502, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCHq+NNGYkml; Fri, 29 Feb 2008 08:49:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D681A28C369; Fri, 29 Feb 2008 08:49:15 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC96C28C1C5 for ; Fri, 29 Feb 2008 08:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnFmsoSybbNO for ; Fri, 29 Feb 2008 08:49:09 -0800 (PST) Received: from mail-01.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id 4AFC328C369 for ; Fri, 29 Feb 2008 08:49:09 -0800 (PST) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JV8Ps-0001Wl-35; Fri, 29 Feb 2008 11:49:01 -0500 In-Reply-To: <47C8291A.5080002@ericsson.com> References: <47C8096A.5050002@ericsson.com> <47C8291A.5080002@ericsson.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <50FDBD2A-C078-4A10-80B5-997381053F3C@magma.ca> From: Philip Matthews Date: Fri, 29 Feb 2008 11:49:00 -0500 To: Magnus Westerlund X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: draft-ietf-behave-turn@tools.ietf.org, Behave WG Subject: Re: [BEHAVE] TURN 07: Channel ID collisions with usage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Fri, 29-Feb-08, at 10:47 , Magnus Westerlund wrote: > I think another thing that the client can do is to not use > channelbindings until one has promoted a single candidate and > closed down the other multiplexing points. First when this is > accomplished can one start using channelbindings. I am sorry, but I don't see why binding a channel before a candidate is promoted could be a problem. Would you explain a bit more? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 29 12:30:55 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19A873A6F25; Fri, 29 Feb 2008 12:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.904 X-Spam-Level: X-Spam-Status: No, score=-0.904 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPUGulwjXFQG; Fri, 29 Feb 2008 12:30:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2D0128C735; Fri, 29 Feb 2008 12:30:49 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E71728C6DD for ; Fri, 29 Feb 2008 12:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYgu07wliaTr for ; Fri, 29 Feb 2008 12:30:43 -0800 (PST) Received: from mail-01.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id F28A63A6E45 for ; Fri, 29 Feb 2008 12:30:42 -0800 (PST) Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JVBsF-0001f7-2U; Fri, 29 Feb 2008 15:30:31 -0500 In-Reply-To: References: <47C8096A.5050002@ericsson.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Philip Matthews Date: Fri, 29 Feb 2008 15:30:31 -0500 To: Philip Matthews X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] Cc: draft-ietf-behave-turn@tools.ietf.org, Behave WG Subject: Re: [BEHAVE] TURN 07: Channel ID collisions with usage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Fri, 29-Feb-08, at 10:36 , Philip Matthews wrote: > 1) Since the choice of channel numbers is totally under the control > of the client, the client can avoid channel numbers that make > demuxing a problem. In the case of RTP, this would mean that the > client should avoid channel numbers that have the first two bits as > either 00 or 10 (the first is used by STUN and the second is used by > RTP). This still leaves 2^31 possible channel numbers. Correction: "This still leaves 2^15 (32K) channel numbers." Channel numbers are only 16 bits long. ==== - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 29 12:31:34 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6C2028C73E; Fri, 29 Feb 2008 12:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.288 X-Spam-Level: X-Spam-Status: No, score=-100.288 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M22ohsDAMfY4; Fri, 29 Feb 2008 12:31:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B54428C569; Fri, 29 Feb 2008 12:31:29 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 223C53A6F29 for ; Fri, 29 Feb 2008 12:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LU7dxsdQsSFN for ; Fri, 29 Feb 2008 12:31:27 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 7082B3A6F10 for ; Fri, 29 Feb 2008 12:31:27 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 046F97F104C; Fri, 29 Feb 2008 20:31:20 +0000 (UTC) Received: from [192.168.1.3] (c-71-202-183-123.hsd1.ca.comcast.net [71.202.183.123]) by server.implementers.org (Postfix) with ESMTP id EAF617F103E; Fri, 29 Feb 2008 20:31:16 +0000 (UTC) Message-ID: <47C86B94.3040708@acm.org> Date: Fri, 29 Feb 2008 12:31:16 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080109) MIME-Version: 1.0 To: Jonathan Rosenberg References: <47C072CD.3050003@cisco.com> In-Reply-To: <47C072CD.3050003@cisco.com> Cc: Behave WG Subject: Re: [BEHAVE] updated rfc3489bis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org I just did a complete review of my code against rfc3489bis-15 and have some questions: - Section 7.1 "All STUN requests and responses sent over UDP SHOULD be less than the path MTU": Shouldn't indications be added to this list? - Section 9: Now that there will be a default port defines for STUN over TLS, shouldn't the last sentence of the last paragraph removed? - Section 15.8: Shouln't the section says that the text must be a UTF-8 encoded sequence, like for USERNAME and REALM? Thanks. Jonathan Rosenberg wrote: > Just submitted: > http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-15.txt > > Changes based on recent comments: > > * MTU limit from MUST to SHOULD, with an explanation of why (namely, > behavior discovery) > > * added clarification on MD5 being the 16 byte output and not ascii > armored, also including an example. This was some text that was in > 3489bis till -05 and got lost in the big rewrite to -06. > > * clarified that the MTU limit applies to the entire datagram and not > just the STUN message > > -Jonathan R. -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 29 13:56:40 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD59928C73E; Fri, 29 Feb 2008 13:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.787 X-Spam-Level: X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_43=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZW9oeqmwE4Z; Fri, 29 Feb 2008 13:56:39 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F8C53A6CFD; Fri, 29 Feb 2008 13:56:39 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E6C63A6D01 for ; Fri, 29 Feb 2008 13:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmgWPGTprSwu for ; Fri, 29 Feb 2008 13:56:37 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5AF983A6CFD for ; Fri, 29 Feb 2008 13:56:37 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 29 Feb 2008 13:56:30 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m1TLuTqQ030973; Fri, 29 Feb 2008 13:56:29 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m1TLtuc7020012; Fri, 29 Feb 2008 21:56:29 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 13:56:17 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 13:56:16 -0800 Message-ID: <47C87F75.6020403@cisco.com> Date: Fri, 29 Feb 2008 16:56:05 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Philip Matthews References: <47C8096A.5050002@ericsson.com> In-Reply-To: X-OriginalArrivalTime: 29 Feb 2008 21:56:16.0515 (UTC) FILETIME=[E881D530:01C87B1D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4373; t=1204322189; x=1205186189; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20TURN=2007=3A=20Channel=20ID=20collision s=20with=20usage |Sender:=20; bh=OqsDlS4Imx++FUcnPNAKt8xRRuBNHKmbWgXM0ygQDK4=; b=CIR+/QsqwXwKWbDdvJi/5Lotulkl2jryUSZPbwch7P+ytKynviJYMozwSr 16gZknxolfsuQC0tVeys44eb0VNUntSW9E5WMxyuHeQo08bkpbcbBr0yM8+S W4DeGWCKW+; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: draft-ietf-behave-turn@tools.ietf.org, Behave WG Subject: Re: [BEHAVE] TURN 07: Channel ID collisions with usage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org I had thought that the client would FIRST demux packets from the TURN server, vs. those not from the TURN server. For stuff coming from the TURN server, it is always TURN or channeldata, and we know how to demux that. For stuff not coming from the TURN server, its never channeldata, and never TURN; it can be RTP or STUN. ANd those are easy to demux. So I think this needs to be explained but I see no need to constrain channel numbers or any other such thing. Think of what would happen in the case of tcp from client to turn server; everything over that connection is clearly TURN and treated as such. Just do the same for UDP. Thanks, Jonathan R. Philip Matthews wrote: > Magnus: > > Thanks for point out this issue, which I had not previously considered. > As I see it, there are a number of ways that a client can solve this > problem: > > 1) Since the choice of channel numbers is totally under the control of > the client, the client can avoid channel numbers that make demuxing a > problem. In the case of RTP, this would mean that the client should > avoid channel numbers that have the first two bits as either 00 or 10 > (the first is used by STUN and the second is used by RTP). This still > leaves 2^31 possible channel numbers. For application protocols other > than RTP, the client may have to avoid other channel numbers. > > 2) If the client knows that, for a given call, its peers will either all > use the direct path or all use the TURN server, then it can simply wait > to allocate channel numbers until it knows which case it is dealing > with. If all peers are going via the TURN server, then there can be no > conflict with the application protocol (e.g. RTP) since all application > protocol packets arrive at the client encapsulated inside either a Data > indication or a ChannelData message, so all channel numbers except those > starting with 00 can be used. > > 3) If the client is dealing with an application protocol where the demux > problem is harder (for example, a protocol which allows arbitrary values > in the first 32 bits), then the client must use a different client > transport address to talk to the TURN server. In this case, the > XOR-MAPPED-ADDRESS in the Allocate response is not useful. > > On a separate thread, we are discussing whether ESP falls into case (3). > > In terms of the document, I suggest adding text that basically says the > above. I would make it general (i.e., not specific to RTP), but we could > add an appendix that discusses the issue for certain specific > application protocols. > > - Philip > > > On Fri, 29-Feb-08, at 08:32 , Magnus Westerlund wrote: > >> Hi, >> >> In the review of TURN 07 I found that the draft doesn't at all take >> care of a case I asked about previous. >> >> The allocation response include the server reflexive address to the >> TURN client. The only reason for doing this is to enable a client to >> co-locate both a TURN client and a direct STUN+UDP based protocol, for >> example RTP, on the same port. >> >> However, the TURN channel header has overlap with RTP thus causing a >> demultiplexing collision when channel numbers in the 8000-8FFF range >> is used. >> >> This seriously need to be taken care of. I think the simplest thing is >> to stop co-locating the TURN client with anything else. And thus also >> the XOR-MAPPED-ADDRESS should not be returned in the allocate response >> either. >> >> Cheers >> >> Magnus Westerlund >> >> IETF Transport Area Director & TSVWG Chair >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 8 4048287 >> Torshamsgatan 23 | Fax +46 8 7575550 >> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> > > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 29 13:58:41 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C758C28C6E7; Fri, 29 Feb 2008 13:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.083 X-Spam-Level: X-Spam-Status: No, score=-1.083 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUJ0EqKEWK3O; Fri, 29 Feb 2008 13:58:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B474B28C2C9; Fri, 29 Feb 2008 13:58:40 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 809D028C5D0 for ; Fri, 29 Feb 2008 13:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0hCPyJ3ON2J for ; Fri, 29 Feb 2008 13:58:34 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 650533A6D01 for ; Fri, 29 Feb 2008 13:58:33 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,429,1199692800"; d="scan'208";a="15426197" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 29 Feb 2008 13:58:26 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1TLwP2Y004420; Fri, 29 Feb 2008 13:58:25 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1TLwDCe005190; Fri, 29 Feb 2008 21:58:19 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 13:58:15 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 13:58:14 -0800 Message-ID: <47C87FEB.3000807@cisco.com> Date: Fri, 29 Feb 2008 16:58:03 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Philip Matthews References: <200802291420.48974.remi.denis-courmont@nokia.com> In-Reply-To: X-OriginalArrivalTime: 29 Feb 2008 21:58:14.0609 (UTC) FILETIME=[2EE58C10:01C87B1E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2003; t=1204322305; x=1205186305; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20STUN=20and=20RFC3948 |Sender:=20; bh=vx0a+Z2GDcU/CPOItD77p+4WXSS3npu7UzffC1iy0NA=; b=LxAhgQ3zXbTqjHWNvYIM/5ktJgBpL8QCQ8xM8nTY2hPLuTr9RwFmwPsSeV uFuFuxwp2H1I6W8pjlQQT3boEj2uh7pVKU+M75aGGgwypeyeZ8qew5Bk0mzB AtalXMUW7rRWs6r3b7OsdeEXSK0G/gfmaT/1Mjhv3SZZLe4ledhss=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: pasi.eronen@nokia.com, behave@ietf.org, hip-nat-traversal@piuha.net Subject: Re: [BEHAVE] STUN and RFC3948 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Right - my answer was going to be, "thats why there is the FINGERPRINT". = Clearly we cannot modify the stun header every time we want to demux = with a new protocol; thats why FINGERPRINT was added. -Jonathan R. Philip Matthews wrote: > On Fri, 29-Feb-08, at 07:20 , R=E9mi Denis-Courmont wrote: >>> We could also bend ESP towards this direction, but unfortunately it >>> appears to imply some negative tradeoffs related to security, = >>> performance >>> and deployment. >> You mean, like adding restrictions on the SPI field? I don't know = >> IPsec well >> enough to realistically comment on this. > = > Yes. As long as the SPI field does not look like 00........00, the = > demux is simple. However, I am not enough of a security expert to = > know what affect putting this restriction on the SPI field might have = > on ESP security. > = >> Did you consider the use of the STUN FINGERPRINT attribute? I am = >> not sure if >> it would have serious security implications. > = > Yes. Without a restriction in the SPI range, it seems that the only = > way to demux is to do the full suite of STUN demux tests: > * First longword looks like 00...........00 > * Second longword contains the magic cookie value. > * STUN packet contains a FINGERPRINT attribute. > Packets passing all three tests are STUN, others are ESP. > = > It is certainly possible to do this. There was just some grumblings = > about the time/complexity of implementing the third test, especially = > since some OSes process ESP packets in the kernel. > = > - Philip > = > = > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > = -- = Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave