From behave-bounces@ietf.org Thu Oct 04 14:51:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdVmN-0002Oz-BY; Thu, 04 Oct 2007 14:50:35 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IdVmM-0002NI-0R for behave-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 14:50:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdVmL-0002LX-Ld; Thu, 04 Oct 2007 14:50:33 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdVmK-0003NH-Hl; Thu, 04 Oct 2007 14:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 70718329EF; Thu, 4 Oct 2007 18:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IdVlq-0006dQ-Ae; Thu, 04 Oct 2007 14:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 04 Oct 2007 14:50:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-multicast-11.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 : IP Multicast Requirements for a Network Address (and port) Translator (NAT) Author(s) : D. Wing, T. Eckert Filename : draft-ietf-behave-multicast-11.txt Pages : 15 Date : 2007-10-04 This document specifies requirements for a Network Address (and port) Translator (NAT) that supports 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-11.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-multicast-11.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-multicast-11.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: <2007-10-04144459.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-multicast-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-multicast-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-04144459.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 https://www1.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Fri Oct 05 11:38:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdpFQ-0003aO-Fk; Fri, 05 Oct 2007 11:37:52 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IdVh6-0006FK-1Y for behave-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 14:45:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdVh5-0006F4-NM for behave@ietf.org; Thu, 04 Oct 2007 14:45:07 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdVh5-00031t-IL for behave@ietf.org; Thu, 04 Oct 2007 14:45:07 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns1.neustar.com (Postfix) with ESMTP id 73C3526E74; Thu, 4 Oct 2007 18:45:02 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IdVh0-0002zN-Bp; Thu, 04 Oct 2007 14:45:02 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: dwing@cisco.com From: IETF I-D Submission Tool Message-Id: Date: Thu, 04 Oct 2007 14:45:02 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Fri, 05 Oct 2007 11:37:52 -0400 Cc: eckert@cisco.com, behave@ietf.org Subject: [BEHAVE] New Version Notification for draft-ietf-behave-multicast-11 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org A new version of I-D, draft-ietf-behave-multicast-11.txt has been successfuly submitted by Dan Wing and posted to the IETF repository. Filename: draft-ietf-behave-multicast Revision: 11 Title: IP Multicast Requirements for a Network Address (and port) Translator (NAT) Creation_date: 2007-10-04 WG ID: behave Number_of_pages: 15 Abstract: This document specifies requirements for a Network Address (and port) Translator (NAT) that supports 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. The IETF Secretariat. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Oct 05 19:04:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdwDB-0002IO-St; Fri, 05 Oct 2007 19:04:01 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IdwDA-0002Cz-8O for behave-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 19:04:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdwD9-0002AD-SD for behave@ietf.org; Fri, 05 Oct 2007 19:03:59 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdwD9-0008O1-F0 for behave@ietf.org; Fri, 05 Oct 2007 19:03:59 -0400 X-IronPort-AV: E=Sophos;i="4.21,237,1188802800"; d="scan'208";a="404457603" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 05 Oct 2007 16:03:49 -0700 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 l95N3mib011085 for ; Fri, 5 Oct 2007 16:03:48 -0700 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l95N3mYt020244 for ; Fri, 5 Oct 2007 23:03:48 GMT From: "Dan Wing" To: Date: Fri, 5 Oct 2007 16:03:48 -0700 Message-ID: <002301c807a3$fd1cb5c0$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgHo/y9jNB2BumXTOyr5qYo0hCqyg== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1726; t=1191625428; x=1192489428; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20updated=20milestones,=20document=20status |Sender:=20; bh=rjOGrkAdAs//U1/sjr4BzECbFjhwGL9Yr0n8WCxOtf8=; b=K2wCjGGWYRK4kRDcN/f6WT9ZPzqN4DvILMEJdcySoKUo7BT4Nm1PtNvEQgf1MhrT3tjwgeEB gCiB6gawLH5tPzGXOVfraBOCpAJTGRzMxGqCoEdGgctEjA1uciWSzaTq; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [BEHAVE] updated milestones, document status X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Our milestones have been updated -- most of the changes are slipped dates. The behavior-discovery document is now also Experimental, per the consensus reached on the mailing list. Document status is at http://www.employees.org/behave/document-status.html. In summary: Documents wrapping up: * draft-ietf-behave-multicast-11, in IESG processing * draft-ietf-behave-nat-icmp-05, submitted to IESG * draft-ietf-behave-p2p-state-04, submitted to IESG Active documents: * draft-ietf-behave-rfc3489bis-10, awaiting revision based on AD comments * draft-ietf-behave-turn-04, waiting for architectural rewrite based on http://www1.ietf.org/mail-archive/web/behave/current/msg02742.html * draft-ietf-behave-turn-ipv6-03, waiting on TURN * draft-ietf-behave-nat-behavior-discovery-01, now Experimental New milestone dates: http://www.ietf.org/html.charters/behave-charter.html ... Done Submit BCP that defines unicast UDP behavioral requirements for NATs to IESG Done Submit a BCP that defines TCP behavioral requireents for NATs to IESG Done Submit IPv6 relay protocol to IESG Done Submit a BCP that defines ICMP behavioral requirements for NATs to IESG Done Submit informational that discusses current NAT traversal techniques used by applications Done Submit BCP that defines multicast UDP Oct 2007 Submit revision of RFC 3489 to IESG behavioral requirements for NATs to IESG Dec 2007 Submit standards-track IPv6 relay protocol Dec 2007 Submit standards-track relay protocol Jan 2008 Submit experimental document that describes how an application can determine the type of NAT it is behind Jan 2008 Close WG or recharter ... -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Oct 08 11:10:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeuEB-0001BQ-Oj; Mon, 08 Oct 2007 11:09:03 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IeuEA-0001B7-QH for behave-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 11:09:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeuEA-0001Ae-3T; Mon, 08 Oct 2007 11:09:02 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IeuE9-0003La-DF; Mon, 08 Oct 2007 11:09:02 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E0FAF2045E; Mon, 8 Oct 2007 17:09:00 +0200 (CEST) X-AuditID: c1b4fb3e-ae831bb0000007e1-b6-470a480c4ad7 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C898D21778; Mon, 8 Oct 2007 17:09:00 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Oct 2007 17:09:00 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Oct 2007 17:09:00 +0200 Message-ID: <470A480C.4040506@ericsson.com> Date: Mon, 08 Oct 2007 17:09:00 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: TSV Area , Behave WG , "mmusic (E-mail)" X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Oct 2007 15:09:00.0265 (UTC) FILETIME=[27E1FD90:01C809BD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Subject: [BEHAVE] BOF request under consideration: SAFE X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, We ADs have received a request for a BOF in Vancouver: SAFE - Self-Address Fixing Evolution. See description below. I would appreciate any feedback on this. For public discussion please use the SAFE mailing list. Post: safe@ietf.org Subscribe: https://www1.ietf.org/mailman/listinfo/safe Draft: http://www.ietf.org/internet-drafts/draft-wing-behave-nat-control-stun-usage-03.txt SAFE - Self-Address Fixing Evolution ------------------------------------ Chairs: TBD ICE and its companion protocol STUN have been successfully deployed on the Internet for NAT traversal. ICE and STUN have several characteristics which contribute to their success: 1. incremental deployment. ICE and STUN are functional without any modifications to existing NATs. 2. nested NATs. ICE and STUN work when there are multiple NATs between a host and the Internet. 3. topology unaware. ICE and STUN are not configured with information about NATs, firewalls, or their locations -- only with the IP address of a server on the Internet. 4. simple security model. If a host behind a NAT is allowed to send a packet across the NAT, it is allowed to receive a response. 5. works on routed networks, which allows operation in both enterprise networks and home networks. Other NAT traversal protocols do not share these characteristics, which hinders their widespread deployment. Specifically, * incremental deployment is not possible with MIDCOM, NSIS-NSLP, UPnP, or Bonjour. With all of these protocols, both the NAT and the endpoint have to support the same protocol. * nested NATs are not possible with UPnP or Bonjour. * topology awareness is required of MIDCOM. * security must be established between the controlling entity and the NAT for MIDCOM and NSIS-NSLP. * Both UPnP and Bonjour use broadcast packets which don't work well on routed networks. However, a drawback of ICE/STUN is its chatty keepalive traffic, which is a result of STUN not knowing the binding lifetime of its on-path NATs. This chattiness causes a burden on servers and consumes network bandwidth, which is especially critical on wireless networks. It is desirable to reduce this chattiness while still retaining the important characteristics of STUN and ICE. This BoF is intended to discuss one proposed technique, draft-wing-behave-nat-control-stun-usage, which nearly eliminates STUN's keepalive chatter and still preserves the desirable characteristics of STUN/ICE. The purpose of this BoF is to create a working group for this effort. Agenda: Introduction, Agenda .................................... 5 Summary of existing NAT traversal techniques ............ 40 (UPnP, NAT-PMP/Bonjour, MIDCOM techniques, NSIS-NSLP, ICE) draft-wing-behave-nat-control-stun-usage ................ 40 Q&A ..................................................... 25 ---------- total: 110 Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- 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://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Oct 08 18:08:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1If0lv-0004TD-8o; Mon, 08 Oct 2007 18:08:19 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1If0lt-0004So-VN for behave-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 18:08:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1If0lt-0004RG-Kk for behave@ietf.org; Mon, 08 Oct 2007 18:08:17 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1If0ln-0006Nz-7r for behave@ietf.org; Mon, 08 Oct 2007 18:08:17 -0400 X-IronPort-AV: E=Sophos;i="4.21,244,1188802800"; d="scan'208";a="11479331" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 08 Oct 2007 15:08:06 -0700 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 l98M85NO011184 for ; Mon, 8 Oct 2007 15:08:05 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l98M85cb016154 for ; Mon, 8 Oct 2007 22:08:05 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); Mon, 8 Oct 2007 15:08:00 -0700 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Oct 2007 15:07:59 -0700 Message-ID: <470AAA56.5040301@cisco.com> Date: Mon, 08 Oct 2007 18:08:22 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Oct 2007 22:07:59.0897 (UTC) FILETIME=[B0456890:01C809F7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5112; t=1191881285; x=1192745285; 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:=20TURN=20status=20and=20direction |Sender:=20; bh=u1sdx0A1+m0OKNWXvH/+otxGhXieNetUrqO8LYq1IIQ=; b=kRA8mOwfEs+eLJ+dmTbBEOdC8tWxRSnHFq508t09r0j0UWx6rHbWGKS/9Oul8BHKHissliRH 5Le8k1KyyxVzeAJ817wwNOkJ1y4+KIBjxPHdWG4WKmVzYKQZg8q7JARE; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: [BEHAVE] TURN status and direction X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Almost a month back, I sent a note to the behave list about a possible change in TURN to try to simplify things: http://www1.ietf.org/mail-archive/web/behave/current/msg02742.html the design team has been meeting 1-2 times a week since then, working through this proposal, and also working through the details on TCP and forking. Our original plan was to have a revised TURN available by October 1, but given the issues we were tackling, this has proven to be impossible. We're aiming for a draft now prior to the IETF. So, until then, I wanted to summarize our current thinking on changes in TURN. As in my previous note, we still think its a good idea to add a small shim to UDP that is always used. This would be a 1-byte shim, which signals a channel number. Channel 0 is reserved for TURN traffic between the client and the TURN server. THe other channels are for data to a specific remote destination (IP address and port). Except for channel 0, the channel numbers in each direction are independent. The Send and Data indications remain, allowing the client and TURN server respectively to send TURN-encapsulated data in each direction. However, these messages will now carry a channel attribute that is used to establish a channel. So, for example, when the client begins sending data through the TURN server to a particular remote destination, it will use the Send indication. It picks an unallocated channel, and includes that in the Send indication. The TURN server will, in response to a Send indication, send an empty Data indication back to the client, echoing the channel number. It will also store a mapping that binds this channel to the remote destination (IP and port) in the Send. The empty Data indication allows the client to know that the channel allocation has succeeded. Once the client has received this empty Data indication, it knows it is free to send data on that allocated channel. The client can then send UDP packets for that remote destination by just sending a UDP packet to the TURN server with the 8-byte header including the allocated channel. For data from the TURN server back to the client, it works just the same. The TURN server includes a channel number in its Data indications, and the client acknowledges this with an empty Send indication echoing the channel number back. When the TURN server receives data from a remote peer (assuming there is a permission), it sends it on the appropriate data channel if one has been set up, else sends it unencapsulated which has the side-effect of allocating a channel. We debated many variations on this technique; the leading alternative was to use a separate transaction for channel allocation, rather than piggybacking on the data and send indications. This works less effectively with ICE (sends more packets and increases delay), and requires a STUN server side transaction model in clients, which is not required here. So we chose the approach above. The second issue we debated extensively was in response to Matt Mathis' comments, about the case of two remote tcp connections being multiplexed into a single tcp connection from client to TURN server. This is something that WILL happen; there are several use cases for it. The most likely one is a call from an ICE agent to a non-ICE peer, where the media stream is actually something like MSRP, and the request forks to two remote agents. This case will cause the two remote agents to each open a tcp connection to the default candidate in the SDP - usually a TURN candidate. Typically only one of these connections survives in the long term; depending on which remote agent answers. But during the early media period both remain. We worked through some approaches for causing multiple tcp connections to get formed from client to turn server when this happens. In the end, they were all really complicated. We felt it was better to simplify turn than add features to deal with this case. So instead our proposal is to make clear in the spec that, should this case happen (multiple tcp connections to remote agents), and more than a trivial amount of data is to be sent (and we'll quantify that), the agent MUST do a re-invite (or equivalent for non-SIP cases) to get a new turn candidate and thus separate connections for one of the remote peers. This is a purposeful limitation in TURN - its only meant to be used with a single remote correspondent at a time. We are now beginning the process of integrating these changes into the TURN draft, while working through the other issues raised in the review period. Comments or questions on the above proposals are welcome. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Oct 10 10:04:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfcAO-0001G9-GJ; Wed, 10 Oct 2007 10:04:04 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IfcAM-0001G2-GO for behave-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 10:04:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfcAM-0001Fq-4e for behave@ietf.org; Wed, 10 Oct 2007 10:04:02 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfcAL-0005kY-Iv for behave@ietf.org; Wed, 10 Oct 2007 10:04:02 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9AE3cB5019200; Wed, 10 Oct 2007 17:03:57 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 17:03:49 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 17:03:49 +0300 Received: from [172.18.176.123] (essapo-nirac253186.europe.nokia.com [10.162.253.186]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9AE3hKh029332; Wed, 10 Oct 2007 17:03:45 +0300 In-Reply-To: <470AAA56.5040301@cisco.com> References: <470AAA56.5040301@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Subject: Re: [BEHAVE] TURN status and direction Date: Wed, 10 Oct 2007 09:03:42 -0500 To: ext Jonathan Rosenberg X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 Oct 2007 14:03:49.0137 (UTC) FILETIME=[617EB810:01C80B46] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 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="===============0894237452==" Errors-To: behave-bounces@ietf.org --===============0894237452== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-31--1030542346; protocol="application/pkcs7-signature" --Apple-Mail-31--1030542346 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On 2007-10-8, at 17:08, ext Jonathan Rosenberg wrote: > We worked through some approaches for causing multiple tcp > connections to get formed from client to turn server when this > happens. In the end, they were all really complicated. these approaches are complicated because multiplexing different TCP connections onto a single one *is* a complex operation. > We felt it was better to simplify turn than add features to deal > with this case. So instead our proposal is to make clear in the > spec that, should this case happen (multiple tcp connections to > remote agents), and more than a trivial amount of data is to be > sent (and we'll quantify that), the agent MUST do a re-invite (or > equivalent for non-SIP cases) to get a new turn candidate and thus > separate connections for one of the remote peers. This is a > purposeful limitation in TURN - its only meant to be used with a > single remote correspondent at a time. I'm not sure I fully understand this proposal based on this short description, but I can see some reasons why this could be problematic. First, the TURN server cannot enforce how an application uses TCP. Second, the ability to re-invite may not be present in many TCP-using applications. If TURN needs the ability to multiplex TCP connections, it needs to specify a mechanism that works for *all* uses of TCP, and not just a convenient subset. Lars --Apple-Mail-31--1030542346 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzEwMTAxNDAzNDJaMCMGCSqGSIb3DQEJBDEWBBTv3BQ//RZBiNVx jGkZgVQbNUMVpzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAuPuGosD53dBKvp4IJ0B43y+tlOZcaZWh50fDvSoJG5IeGKHBJe4w l9fjP9WlOOq8CRO2A2fBiPgnSdN73d2yI0UEsMhXm2f00FJaMxae7HRgebjAojFEbKvpYPphDJCQ pxf9aDx/s3uWZPzQ7n5XSauWGQtG442IHkU7lG7Ja709gSX3m7EPDXY5DWYJ9sZP0kM5URap1y24 2fP9e0N+IsdBHnkrlKGlVr1zwVlv5TcP7sk0uA/+naUKT5o/Cg2H9lyIm7xEFZrH0zVHRAzpg8wF tWIQoWRVlPzsWjmfEPgqvLlF2h2W1PE7jQS8PkWUPMBDYtxcznujZ+J0q3SXkwAAAAAAAA== --Apple-Mail-31--1030542346-- --===============0894237452== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --===============0894237452==-- From behave-bounces@ietf.org Wed Oct 10 10:50:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfcsS-0003bc-UN; Wed, 10 Oct 2007 10:49:36 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IfcsR-0003bH-LH for behave-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 10:49:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfcsR-0003b9-AM for behave@ietf.org; Wed, 10 Oct 2007 10:49:35 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfcsQ-00072U-TL for behave@ietf.org; Wed, 10 Oct 2007 10:49:35 -0400 X-IronPort-AV: E=Sophos;i="4.21,255,1188792000"; d="scan'208";a="134529211" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 10 Oct 2007 10:49:33 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9AEnWs6000960; Wed, 10 Oct 2007 10:49:32 -0400 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 l9AEnLtC019210; Wed, 10 Oct 2007 14:49:32 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); Wed, 10 Oct 2007 10:49:27 -0400 Received: from [64.101.247.128] ([64.101.247.128]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 10:49:27 -0400 Message-ID: <470CE68F.3080603@cisco.com> Date: Wed, 10 Oct 2007 10:49:51 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lars Eggert Subject: Re: [BEHAVE] TURN status and direction References: <470AAA56.5040301@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Oct 2007 14:49:27.0339 (UTC) FILETIME=[C1972FB0:01C80B4C] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15474.002 X-TM-AS-Result: No--22.143200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2345; t=1192027772; x=1192891772; c=relaxed/simple; s=rtpdkim2001; 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]=20TURN=20status=20and=20direction |Sender:=20 |To:=20Lars=20Eggert=20; bh=HNLar3cdhJ51OmGQcotO7aTxQfezwKoG21k6znkSFTI=; b=TdV+MnMaSTk6o9/8Z+nZllX5AYMbaXywLjGnKaozFnEKv45kkvi2l2vk6uCJRsOf5ZGDbmo0 iq3KfBp0Wz50htWpqpkIfC9oa+qnzOJczdUgPXhmwKh/X7MO9RNW3kWg; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org inline. Lars Eggert wrote: >> We felt it was better to simplify turn than add features to deal with >> this case. So instead our proposal is to make clear in the spec that, >> should this case happen (multiple tcp connections to remote agents), >> and more than a trivial amount of data is to be sent (and we'll >> quantify that), the agent MUST do a re-invite (or equivalent for >> non-SIP cases) to get a new turn candidate and thus separate >> connections for one of the remote peers. This is a purposeful >> limitation in TURN - its only meant to be used with a single remote >> correspondent at a time. > > I'm not sure I fully understand this proposal based on this short > description, but I can see some reasons why this could be problematic. > First, the TURN server cannot enforce how an application uses TCP. > Second, the ability to re-invite may not be present in many TCP-using > applications. > > If TURN needs the ability to multiplex TCP connections, it needs to > specify a mechanism that works for *all* uses of TCP, and not just a > convenient subset. TURN has always assumed that there was some kind of rendezvous protocol working with it. The entire permission model is built off of the idea that a client knows the IP addresses of its remote peers, through that rendezvous mechanism. So, what we have here is just another requirement on the rendezvous protocol. We require that, it either return a single address for a remote peer, or if it ends up with multiple, it have the ability to provide an updated IP address and port to the remote peer. This requirement is readily met by SIP and also seems to be OK for other things you can think of that might use TURN. The design team couldn't think of cases where this limitation was a problem. So I am reluctant to add functionality into the TURN layer when we can address the problem in the rendezvous protocol. Doing something in one place is better than two. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Oct 10 13:45:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iffbo-0007nq-FR; Wed, 10 Oct 2007 13:44:36 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Iffbm-0007lr-LC for behave-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 13:44:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iffbm-0007lj-BN for behave@ietf.org; Wed, 10 Oct 2007 13:44:34 -0400 Received: from mail1.sea5.speakeasy.net ([69.17.117.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iffbg-00027n-FT for behave@ietf.org; Wed, 10 Oct 2007 13:44:34 -0400 Received: (qmail 16495 invoked from network); 10 Oct 2007 17:44:14 -0000 Received: from 63-110-43-11.client.cypresscom.net (HELO [127.0.0.1]) (lainestump@[63.110.43.11]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 10 Oct 2007 17:44:14 -0000 Message-ID: <470D0F6B.2050702@laine.org> Date: Wed, 10 Oct 2007 13:44:11 -0400 From: Laine Stump User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [BEHAVE] TURN status and direction References: <470AAA56.5040301@cisco.com> In-Reply-To: <470AAA56.5040301@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: laine+behave@laine.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org (Sorry I didn't pipe up last month when you sent the original message and asked for comments. My only excuse is that I wasn't paying attention.) Jonathan Rosenberg wrote: > As in my previous note, we still think its a good idea to add a small > shim to UDP that is always used. This would be a 1-byte shim, which > signals a channel number. As an implementor of a TURN server based on the previous drafts, I have a couple concerns with this change in the design that I didn't see addressed in this mail or your earlier message on the subject: Adding a single byte at the beginning of every relayed packet will 1) necessitate recalculation of the UDP checksum, as well as 2) potentially causing alignment problems on architectures that care about that (for relays that want to do something with the payload on its way through, eg collect statistics). Have you considered 1) making the channel number byte a negotiated option, so that simplistic uses can enjoy lower overhead on the relay, and/or 2) using 2 bytes for the channel number when it is there, to make recomputing the checksum simpler (it could be adjusted rather than recomputed from scratch), or 4 bytes, to also alleviate alignment problems? The current model of 0 modifications to the payload (once the active destination is set) certainly makes for a more efficient relay process in all of the cases where there is a single destination per allocation. Although I understand the need for adding the channel functionality (and cleaning out the "Set Active Destination" stuff), it would be sad to lose the current model's post-setup elegance even when the extra functionality isn't required. > The client can then send > UDP packets for that remote destination by just sending a UDP packet > to the TURN server with the 8-byte header including the allocated > channel. I think I missed something here. Which 8 byte header? Did you mean 8 *bit*? _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Oct 11 07:10:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifvv6-0005rY-Oz; Thu, 11 Oct 2007 07:09:36 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Ifvv5-0005q1-FN for behave-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 07:09:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifvv4-0005pt-R8 for behave@ietf.org; Thu, 11 Oct 2007 07:09:34 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ifvuy-0003b7-5y for behave@ietf.org; Thu, 11 Oct 2007 07:09:34 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9BB95Tb028257; Thu, 11 Oct 2007 14:09:15 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 14:08:05 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 13:49:58 +0300 Received: from esdhcp04049.research.nokia.com ([172.21.40.49]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 13:49:58 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org, laine+behave@laine.org Subject: Re: [BEHAVE] TURN status and direction Date: Thu, 11 Oct 2007 13:50:28 +0300 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <470AAA56.5040301@cisco.com> <470D0F6B.2050702@laine.org> In-Reply-To: <470D0F6B.2050702@laine.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200710111350.29021.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 11 Oct 2007 10:49:58.0480 (UTC) FILETIME=[777F0D00:01C80BF4] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Le Wednesday 10 October 2007 20:44:11 ext Laine Stump, vous avez =E9crit=A0: > Have you considered 1) making the channel number byte a negotiated > option, so that simplistic uses can enjoy lower overhead on the relay, > and/or 2) using 2 bytes for the channel number when it is there, to make > recomputing the checksum simpler (it could be adjusted rather than > recomputed from scratch), or 4 bytes, to also alleviate alignment problem= s? I wouldn't mind using 2 bytes instead of 1 if that really matters. In any=20 case, MTU limits tend to be multiple of 8 bytes, so adding two rather than= =20 one bytes will make no practical difference with regard to packets size. As regard alignment, I think the most important thing is that, the=20 (mis)alignment MUST be always the same, so that it can be compensated easil= y=20 (as with the Ethernet 14-bytes header), rather than have it retain some kin= d=20 of alignment. In fact, if the payload is RTP, the needed alignment would be= 4=20 bytes, but what if, as Lars pointed out, is not RTP? For the reference, som= ey=20 IETF protocols use multiple of 8-bytes boundaries (IPv6 and ICMPv6 comes to= =20 mind), and who knows what the requirement for the upper-layer protocol will= =20 be?? > The current model of 0 modifications to the payload (once the active > destination is set) certainly makes for a more efficient relay process > in all of the cases where there is a single destination per allocation. Bah, modern IP stacks (both in kernel- and user-land) support vectorized I/= O=20 to work around this. > Although I understand the need for adding the channel functionality (and > cleaning out the "Set Active Destination" stuff), it would be sad to > lose the current model's post-setup elegance even when the extra > functionality isn't required. I'd say the opposite. I'd rather have some unique and harmonized way of doi= ng=20 things, that is simple to implement, easy to demultiplex and has predictibl= e=20 alignment properties. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Oct 11 07:53:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifwb3-0006Zi-Mq; Thu, 11 Oct 2007 07:52:57 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Ifwb1-0006Wg-MJ for behave-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 07:52:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifwb1-0006WW-CV for behave@ietf.org; Thu, 11 Oct 2007 07:52:55 -0400 Received: from smtp5.freeserve.com ([193.252.22.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ifwaq-00056m-Ua for behave@ietf.org; Thu, 11 Oct 2007 07:52:55 -0400 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3423.me.freeserve.com (SMTP Server) with ESMTP id 1F5AE1C0008A; Thu, 11 Oct 2007 13:52:39 +0200 (CEST) Received: from Codalogic (user-5af19a7a.tcl111.dsl.pol.co.uk [90.241.154.122]) by mwinf3423.me.freeserve.com (SMTP Server) with ESMTP id C88601C00081; Thu, 11 Oct 2007 13:52:38 +0200 (CEST) X-ME-UUID: 20071011115238821.C88601C00081@mwinf3423.me.freeserve.com Message-ID: <001001c80bfd$3707f940$5d00a8c0@Codalogic> From: "Pete Cordell" To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , , References: <470AAA56.5040301@cisco.com> <470D0F6B.2050702@laine.org> <200710111350.29021.remi.denis-courmont@nokia.com> Subject: Re: [BEHAVE] TURN status and direction Date: Thu, 11 Oct 2007 12:52:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org -Original Message From: "R=E9mi Denis-Courmont"=20 > As regard alignment, I think the most important thing is that, the > (mis)alignment MUST be always the same, so that it can be compensated=20 > easily > (as with the Ethernet 14-bytes header), rather than have it retain some= =20 > kind > of alignment. In fact, if the payload is RTP, the needed alignment woul= d=20 > be 4 > bytes, but what if, as Lars pointed out, is not RTP? For the reference,= =20 > somey > IETF protocols use multiple of 8-bytes boundaries (IPv6 and ICMPv6 come= s=20 > to > mind), and who knows what the requirement for the upper-layer protocol=20 > will > be?? Isn't the issue more a case of what the various processors will accomodat= e=20 as word alignment rather than what the protocols natural alignment is? My understanding is that x86 is quite happy to do 32-bit word accesses th= at=20 are not aligned to 32-word boundaries. However, it will do two rather th= an=20 one bus accesses to do it (sub-optimal, but not a disaster). In the past= ,=20 processors such as PowePC and Sparc couldn't cope at all with doing=20 non-aligned accesses (more of a disaster!), although I think this situati= on=20 is now improved. Problems may occur on embedded processors such a ARM/AR= C,=20 and DSP cores that has code optimized to exploit RTP's alignment to 32-bi= t=20 boundaries. To me, having a 4 byte header seems safest, and least likely to cause=20 problems. > > The current model of 0 modifications to the payload (once the active > > destination is set) certainly makes for a more efficient relay proces= s > > in all of the cases where there is a single destination per allocatio= n. > > Bah, modern IP stacks (both in kernel- and user-land) support vectorize= d=20 > I/O > to work around this. I've not heard of such stacks (or is it something like Windows I/O=20 completion ports?), but can they vectorize with non-aligned boundaries? Pete. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Pete Cordell Codalogic XML Schema to C++ data binding http://www.codalogic.com/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Oct 11 08:08:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfwpC-0005N1-Vk; Thu, 11 Oct 2007 08:07:34 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IfwpC-0005Mw-Eh for behave-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 08:07:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfwpC-0005Mo-4t for behave@ietf.org; Thu, 11 Oct 2007 08:07:34 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ifwp5-0005ij-Hu for behave@ietf.org; Thu, 11 Oct 2007 08:07:34 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9BC7Hor011056; Thu, 11 Oct 2007 15:07:21 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 15:07:20 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 15:07:20 +0300 Received: from esdhcp04049.research.nokia.com ([172.21.40.49]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 15:07:20 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Pete Cordell" Subject: Re: [BEHAVE] TURN status and direction Date: Thu, 11 Oct 2007 15:07:51 +0300 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <470AAA56.5040301@cisco.com> <200710111350.29021.remi.denis-courmont@nokia.com> <001001c80bfd$3707f940$5d00a8c0@Codalogic> In-Reply-To: <001001c80bfd$3707f940$5d00a8c0@Codalogic> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200710111507.51345.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 11 Oct 2007 12:07:20.0242 (UTC) FILETIME=[4633B920:01C80BFF] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Le Thursday 11 October 2007 14:52:31 ext Pete Cordell, vous avez =E9crit=A0: > Isn't the issue more a case of what the various processors will accomodate > as word alignment rather than what the protocols natural alignment is? (...) > To me, having a 4 byte header seems safest, and least likely to cause > problems. It does not matter what the processors want if the protocol does not abide = by=20 the processor wishes in the first place. If we have a non-RTP protocol that= =20 includes 64-bits quantity (e.g. doing IPv6 tunneling through a TURN relay),= =20 we'd need a 8-bytes alignment to make 64-bits processors happy/happier. Doe= s=20 that mean the TURN header should be a multiple of 8 bytes? What if I have a 128-bits processor and a protocol with 128-bits quantities= ?=20 TURN can be used with any upper-layer protocols... It seems a lot more safe= =20 to have a *fixed-size* *always* *included* header. That's how Ethernet=20 drivers cope with the 14 bytes Etherne II header; receive the packet with a= =20 two bytes initial offset from the "natural" boundary (14+2=3D16) so the net= work=20 header is well-aligned. However, for this to work, the header size must be= =20 known in advance. > > Bah, modern IP stacks (both in kernel- and user-land) support vectorized > > I/O to work around this. > > I've not heard of such stacks (or is it something like Windows I/O > completion ports?), but can they vectorize with non-aligned boundaries? I meant, scatter-gather I/O arrays: struct iovec with POSIX sendmsg/recvmsg= ,=20 or WSABUF with Windows WSASend/WSARecv. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Oct 11 09:58:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfyYC-0000Xs-Mf; Thu, 11 Oct 2007 09:58:08 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IfyYB-0000Xi-EQ for behave-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 09:58:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfyYB-0000Xa-2e for behave@ietf.org; Thu, 11 Oct 2007 09:58:07 -0400 Received: from smtp5.freeserve.com ([193.252.22.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfyYA-0005Iz-HG for behave@ietf.org; Thu, 11 Oct 2007 09:58:06 -0400 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3417.me.freeserve.com (SMTP Server) with ESMTP id D71E21C00082; Thu, 11 Oct 2007 15:58:05 +0200 (CEST) Received: from Codalogic (user-5af19a7a.tcl111.dsl.pol.co.uk [90.241.154.122]) by mwinf3417.me.freeserve.com (SMTP Server) with ESMTP id 85A201C00088; Thu, 11 Oct 2007 15:58:05 +0200 (CEST) X-ME-UUID: 20071011135805547.85A201C00088@mwinf3417.me.freeserve.com Message-ID: <004201c80c0e$bd496b40$5d00a8c0@Codalogic> From: "Pete Cordell" To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= References: <470AAA56.5040301@cisco.com> <200710111350.29021.remi.denis-courmont@nokia.com> <001001c80bfd$3707f940$5d00a8c0@Codalogic> <200710111507.51345.remi.denis-courmont@nokia.com> Subject: Re: [BEHAVE] TURN status and direction Date: Thu, 11 Oct 2007 14:57:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org - Original Message From: "R=E9mi Denis-Courmont" > > Isn't the issue more a case of what the various processors will=20 > > accomodate > > as word alignment rather than what the protocols natural alignment is= ? > (...) > > To me, having a 4 byte header seems safest, and least likely to cause > > problems. > > It does not matter what the processors want if the protocol does not ab= ide=20 > by > the processor wishes in the first place. ... If I wasn't convinced by the utility of the scatter-gather I/O you mentio= n=20 below I would dispute that. Fortunately I can save myself (and yourself)= =20 the effort! > ... It seems a lot more safe > to have a *fixed-size* *always* *included* header. I agree that a fixed sized, always present (or at least, predictably=20 present) header is important. > > > Bah, modern IP stacks (both in kernel- and user-land) support=20 > > > vectorized > > > I/O to work around this. > > > > I've not heard of such stacks (or is it something like Windows I/O > > completion ports?), but can they vectorize with non-aligned boundarie= s? > > I meant, scatter-gather I/O arrays: struct iovec with POSIX=20 > sendmsg/recvmsg, > or WSABUF with Windows WSASend/WSARecv. So, on a 64-bit machine that's handling a 64-bit aligned protocol, I take= it=20 you mean doing something like: char stun_channel[1]; // Could be just a char, but hey... int64_t protocol_buffer[LOTS]; struct iovec recv_iovec[2] =3D { { (caddr_t)stun_channel, 1 }, { (caddr_t)protocol_buffer, sizeof(protocol_buffer) } }; int res =3D recvmsg( ???, recv_iovec, 2, ??? ); if( stun_channel[0] !=3D 0 ) digest_protocol( protocol_buffer ); If there are no issues with this approach, then I don't have any alignmen= t=20 concerns. Cheers, Pete. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Pete Cordell Codalogic XML Schema to C++ data binding http://www.codalogic.com/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Oct 11 11:30:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfzzA-0007o9-WF; Thu, 11 Oct 2007 11:30:05 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Ifzz9-0007lB-5v for behave-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 11:30:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifzz8-0007jj-Ry for behave@ietf.org; Thu, 11 Oct 2007 11:30:02 -0400 Received: from mail1.sea5.speakeasy.net ([69.17.117.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ifzyy-0006pR-GI for behave@ietf.org; Thu, 11 Oct 2007 11:29:58 -0400 Received: (qmail 28205 invoked from network); 11 Oct 2007 15:29:22 -0000 Received: from 63-110-43-11.client.cypresscom.net (HELO [127.0.0.1]) (lainestump@[63.110.43.11]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 11 Oct 2007 15:29:22 -0000 Message-ID: <470E4150.70701@laine.org> Date: Thu, 11 Oct 2007 11:29:20 -0400 From: Laine Stump User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: behave@ietf.org Subject: Re: [BEHAVE] TURN status and direction References: <470AAA56.5040301@cisco.com> <200710111350.29021.remi.denis-courmont@nokia.com> <001001c80bfd$3707f940$5d00a8c0@Codalogic> <200710111507.51345.remi.denis-courmont@nokia.com> In-Reply-To: <200710111507.51345.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: laine+behave@laine.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org (A preface - our implementation tries to keep relayed packets in the kernel, and in the original buffers the ethernet driver put them in, as much as possible (for UDP->UDP anyway), so recvmsg() scatter-gather tricks won't help. On the other hand, for those who are copying every packet up to an application, even recomputing the checksum is a non-issue (you're doing it anyway), and you probably don't care about the other small differences in performance either (they're dwarfed in comparison to just copying from kernel to application, and context switching back and forth), which is why you likely think I'm nit-picking. At the application level, I have 0 problems with the proposed protocol changes, too.) Rémi Denis-Courmont wrote: > What if I have a 128-bits processor and a protocol with 128-bits quantities? > TURN can be used with any upper-layer protocols... It seems a lot more safe > to have a *fixed-size* *always* *included* header. Your point about data other than RTP having broader alignment requirements is well taken (of course, I'd wager that the great majority of alignment needs would be met by 32 bits, a much higher percentage than with 1 byte headers anyway). But alignment for the sake of the hardware architecture is secondary for me. Since I'm working on an x86 architecture, I'm (selfishly) more concerned about spending the time to redo the entire checksum rather than just adjusting it* or leaving it alone (hardware assist makes that a moot point, but isn't always available), and moving the bytes around (or allocating auxiliary buffers) rather than not. * It's a simple matter to adjust the checksum of data that has had an even number of bytes prepended (or any number of bytes appended), but I'm not aware of a simple algorithm to adjust the checksum when an odd number of bytes has been prepended - instead the entire checksum must be recomputed. > That's how Ethernet > drivers cope with the 14 bytes Ethernet II header; receive the packet with a > two bytes initial offset from the "natural" boundary (14+2=16) so the network > header is well-aligned. However, for this to work, the header size must be > known in advance. At the level that matters to those of us trying to do an in-kernel, 0-copy implementation (ie the ethernet driver) even if you make the assumption that every packet will be IPv4, you still can't make the assumption that every packet will be a TURN "1-byte-channel + data" encapsulated packet (since other traffic for other protocols can be arrving on the same interface). Unless you dedicate an interface to receiving only the encapsulated TURN data, your stated goal of "fixed size, always included header" can't be met at this level, and you're doomed to either reduced performance due to non-aligned memory accesses, or copying the data to align it. (Again, alignment is only a problem when the relay wants to do something with the data, rather than just blindly passing it along, so it's not as important as the checksum problem, or the mere presence of any amount of extra data). As far as predictability is concerned - since any processing taking place will have to be based on the address:port tuple flows anyway, as long as the format of the packet is predictable/identical for all packets in the same flow, code paths for the different formats (encapsulated, unencapsulated) can be made available and the code can be just as streamlined for each possibility. There would of course be some extra code to write, and a bit of setup at the beginning of the session, but that happens once, compared to thousands of relayed packets per session. >>> Bah, modern IP stacks (both in kernel- and user-land) support vectorized >>> I/O to work around this. >> I've not heard of such stacks (or is it something like Windows I/O >> completion ports?), but can they vectorize with non-aligned boundaries? > > I meant, scatter-gather I/O arrays: struct iovec with POSIX sendmsg/recvmsg, > or WSABUF with Windows WSASend/WSARecv. Even in the kernel, when adding the encapsulation header at write time, yes - this works reasonably well, but different semantics (eg, a list of packet buffers) may require that you spend the time to acquire a second buffer, initialize it, attach it to the list, and free it once you're finished (actually, if the buffer has some headroom/tailroom built in, it may be more efficient to just move the ethernet/IP/UDP headers down by one byte, or the payload up by one byte and pop the channel in the middle). When reading encapsulated packets, I don't see how it could be any help at all (as described above). I know that each of these things (recomputing the entire checksum, allocating and freeing a 2nd buffer to add in the encapsulation byte, accessing large words at unaligned addresses) doesn't take much by itself, but added together and repeated for every single media (or whatever) packet they can make a difference, especially when there's so little else that needs to happen to get the packet through. I'd rather pay a bit extra up-front in development time and session setup time. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Oct 11 19:06:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig75p-0001J5-JO; Thu, 11 Oct 2007 19:05:25 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Ig75o-0001IW-Ia for behave-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 19:05:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig75n-0000yf-VW for behave@ietf.org; Thu, 11 Oct 2007 19:05:24 -0400 Received: from oe8.briank.com ([198.144.201.197]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ig75Y-0001wd-0H for behave@ietf.org; Thu, 11 Oct 2007 19:05:08 -0400 Received: from [192.168.255.18] (sol-ethernet.local.briank.com [192.168.255.18]) by oe8.briank.com (8.13.7/8.12.3) with ESMTP id l9BN54vq093799; Thu, 11 Oct 2007 16:05:04 -0700 (PDT) (envelope-from briank@briank.com) In-Reply-To: <470D0F6B.2050702@laine.org> References: <470AAA56.5040301@cisco.com> <470D0F6B.2050702@laine.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <14C0B7F7-2517-4B37-A52E-E39ACEB34414@briank.com> Content-Transfer-Encoding: 7bit From: Brian Korver Subject: Re: [BEHAVE] TURN status and direction Date: Thu, 11 Oct 2007 16:05:04 -0700 To: laine+behave@laine.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Oct 10, 2007, at 10:44 AM, Laine Stump wrote: > (Sorry I didn't pipe up last month when you sent the original > message and asked for comments. My only excuse is that I wasn't > paying attention.) > > Jonathan Rosenberg wrote: > > As in my previous note, we still think its a good idea to add a > small > > shim to UDP that is always used. This would be a 1-byte shim, which > > signals a channel number. > > As an implementor of a TURN server based on the previous drafts, I > have a couple concerns with this change in the design that I didn't > see addressed in this mail or your earlier message on the subject: > Adding a single byte at the beginning of every relayed packet will > 1) necessitate recalculation of the UDP checksum, as well as 2) > potentially causing alignment problems on architectures that care > about that (for relays that want to do something with the payload > on its way through, eg collect statistics). > > Have you considered 1) making the channel number byte a negotiated > option, so that simplistic uses can enjoy lower overhead on the > relay, and/or 2) using 2 bytes for the channel number when it is > there, to make recomputing the checksum simpler (it could be > adjusted rather than recomputed from scratch), or 4 bytes, to also > alleviate alignment problems? I'm not following your reasoning for making the channel number being a negotiated option. The TURN server has to re-compute the UDP checksum on relayed data because the address 4-tuple in the IP header changes, right? I don't see the point of going to a 2 byte channel number tho'. Either the TURN server is relaying the packet or processing it locally (channel=0). In the former case (which is the common case), alignment doesn't matter but bumping up against MTU limits does. In the later case, alignment may be required (or at least desired), but these events don't occur often and so an extra memcpy for the purposes of alignment is a small price to pay for optimizing the common case. > > The current model of 0 modifications to the payload (once the > active destination is set) certainly makes for a more efficient > relay process in all of the cases where there is a single > destination per allocation. Although I understand the need for > adding the channel functionality (and cleaning out the "Set Active > Destination" stuff), it would be sad to lose the current model's > post-setup elegance even when the extra functionality isn't required. > > > > The client can then send > > UDP packets for that remote destination by just sending a UDP packet > > to the TURN server with the 8-byte header including the allocated > > channel. > > I think I missed something here. Which 8 byte header? Did you mean > 8 *bit*? > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave -brian briank@briank.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Oct 11 21:40:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig9U7-0004fE-0l; Thu, 11 Oct 2007 21:38:39 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Ig9U5-0004eb-O4 for behave-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 21:38:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig9U5-0004cl-9c for behave@ietf.org; Thu, 11 Oct 2007 21:38:37 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig9Ty-0006QR-RF for behave@ietf.org; Thu, 11 Oct 2007 21:38:37 -0400 X-IronPort-AV: E=Sophos;i="4.21,262,1188802800"; d="scan'208";a="405817194" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 11 Oct 2007 18:38:28 -0700 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 l9C1cSuY026597; Thu, 11 Oct 2007 18:38:28 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9C1cSlD024436; Fri, 12 Oct 2007 01:38:28 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); Thu, 11 Oct 2007 18:38:27 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 18:38:27 -0700 Message-ID: <470E9702.4060902@cisco.com> Date: Thu, 11 Oct 2007 17:34:58 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Magnus Westerlund References: <46EE4EF5.9080804@ericsson.com> In-Reply-To: <46EE4EF5.9080804@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Oct 2007 01:38:27.0520 (UTC) FILETIME=[96290400:01C80C70] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8299; t=1192153108; x=1193017108; 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=20AD=20comments=20on=20draft-ietf-behave-rfc3489bis-10 |Sender:=20; bh=PH7ymEfWjiVVTxBu4PcyvqTnnODitG1NSZ18BDScBmg=; b=tBplybCHsyTwAv3LuAOKBJ3+1Basas//rrsmJL8TKCgCSudOO05Q/S0Pn6SU1m2JdPUfMqSM OJtaQvgtAED3cHgtlgLQS9liodndAPOPyuIsnNDZ2trR78cjQIcIu7XqDyDjLKgpkuoCXgA3J/ dhVO4i1ZeeCrhMjUX/UDWzg5Q=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 1.4 (+) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: Behave WG , draft-ietf-behave-rfc3489bis@tools.ietf.org Subject: [BEHAVE] Re: AD comments on draft-ietf-behave-rfc3489bis-10 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Thanks for the review Magnus. I've updated the document based on yor comments. Responses below. Magnus Westerlund wrote: > Hi, > > I have performed a combined AD-review / shepherding review and have some > comments. I think some of these will require an updated version before > proceeding. I hope this can be accomplished quickly to avoid to much delay. > > > 1. Section 7.2.1: > It is not obvious why the number 7900 ms is the end of listening for > responses. How did one arrive on that number? Well, its basically the same value we had from rfc3489. But its a reasonable number. The final request is sent at 6300ms, so this gives us 1.6 seconds to wait for a response to that before giving up. In case this last packet does get through, we want to wait at least as long as a big RTT; 1.6 seconds provides lots of margin. I added the note in parens to the following text: Retransmissions continue until a response is received, or until a total of 7 requests have been sent. If, after the last request, a duration equal to 16 times the RTO has passed without a response (providing ample time to get a response if only this final request actually succeeds), > > 2. Section 12.2: > " A STUN server can detect when a given Binding Request message was > sent from an RFC 3489 [RFC3489] client by the absence of the correct > value in the Magic Cookie field. When the server detects an RFC 3489 > client, it SHOULD copy the value seen in the Magic Cookie field in > the Binding Request to the Magic Cookie field in the Binding Response > message, and insert a MAPPED-ADDRESS attribute instead of an XOR- > MAPPED-ADDRESS attribute." > > I think this text should have some warning about what functionality > issues regarding MUXing STUN with other protocols may have due to this > backwards compatibility issue. If I understand things correctly, having > 3489 compatibility means that demuxer only can use the two first bits > and two last of the first word to separate STUN from normal data packets? Per the rest of this thread, I added your proposed text verbatim to this section. > > 3. Section 14.4: > > " The key used as input to HMAC is the password." > > Section 10.2: > > "For STUN servers used in conjunction with SIP servers, it is > desirable to use the same credentials for authentication to the SIP > server and STUN server. Typically, SIP systems utilizing SIP's > digest authentication mechanism do not actually store the password in > the database. Rather, they store a value called H(A1), which is > computed as: > > H(A1) = MD5(username ":" realm ":" password) > > If a system wishes to utilize this credential, the STUN password > would be computed by taking the user-entered username and password, > and using H(A1) as the STUN password. It is RECOMMENDED that clients > utilize this construction for the STUN password." > > Isn't these two in contradiction. In addition aren't they a potential > for interoperability issues between client and server. This as the > actual key used in the HMAC must be the same to allow correct integrity > verification. So, how is it inteded to work? Is it something the usage > needs to define? I had intended that it each deployment could make a decision on this one way or another. But upon further consideration I agree this is a recipe for interop problems. Even if its not SIP there is no reason why you cannot use the H(A1) as the stun password. I've aligned the text around this, and moved the rules on computing the HMAC using H(A1) into the section on hmac computation itself, so that it is mandatory. > > 4. Section 15.1.2: > > " A rogue client may use a STUN server as a reflector, sending it > requests with a falsified source IP address and port. In such a > case, the response would be delivered to that source IP and port. > There is no amplification with this attack, and it is mitigated by > ingress source address filtering." > > I think there is missing a clarification on what type of amplication > that is not possible with STUN. To my understanding there can't be any > packet rate amplification in this attack. However some percent of packet > size amplification seems possible due to NONCE and other error > indication added by the server. Maybe a clarification that there is no > amplification in the number of packets is warrented. Text now reads: A rogue client may use a STUN server as a reflector, sending it requests with a falsified source IP address and port. In such a case, the response would be delivered to that source IP and port. There is no amplification of the number of packets with this attack (the STUN server sends one packet for each packet sent by the client), though there is a small increase in the amount of data, since STUN responses are typically larger than requests. This attack is mitigated by ingress source address filtering. > > 5. Section 15.2: > > " Most of the attacks in this section revolve around an attacker > modifying the reflexive address learned by a STUN client through a > Binding Request/Binding Response transaction. Since the usage of the > reflexive address is a function of the usage, the applicability and > remediation of these attacks is usage-specific. In common > situations, modification of the reflexive address by an on-path > attacker is easy to do. Consider, for example, the common situation > where STUN is run directly over UDP. In this case, an on-path > attacker can modify the source IP address of the Binding Request > before it arrives at the STUN server. The STUN server will then > return this IP address in the XOR-MAPPED-ADDRESS attribute to the > client. Protecting against this attack by using a message-integrity > check is impossible, since a message-integrity value cannot cover the > source IP address, since the intervening NAT must be able to modify > this value. Instead, one solution to preventing the attacks listed > below is for the client to verify the reflexive address learned, as > is done in ICE [I-D.ietf-mmusic-ice]. Other usages may use other > means to prevent these attacks." > > I think there are a serious thinking error that affects most of the > attack variants in this description. If on on-path attacker changes the > source IP-address of the packet the packet will not be routed back to > the client issuing the request. Thus they are looking like lost packets. > To me the only attack being really viable is if the attacker changes the > source address to itself and then forwards the packet to the client > (target of the attack). This is of course assuming that the attacker is > not sitting very closely to the server and can see all/most traffic to > and from the server? Actually thats exactly the assumption; you can rewrite the source IP to point to anyone that you'd naturally be on-path for a message from the STUN server to that IP. As you say, this is more valuable when the attacker is closest to the server, less so as it gets closer to the client. I could swear there was text on this somewhere at some point but its clearly not here now. I will mention this and then discuss how that limitation applies more in 15.2.1 and 15.2.2. > > Can we be a bit clearer on when the attacks are possible. Thus I think > that 15.2.1 and 15.2.2 are more difficult to achieve (assuming integrity > checks between client and server) than 15.2.3 and 15.2.4. > > 6. Section 15.3: > > " This specification uses SHA-1 for computation of the message > integrity. " > > Shouldn't there be a HMAC before SHA-1 here? Fixed. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Oct 11 22:27:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgAEM-00012S-CQ; Thu, 11 Oct 2007 22:26:26 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IgAEL-00012I-V5 for behave-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 22:26:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgAEL-00012A-LH for behave@ietf.org; Thu, 11 Oct 2007 22:26:25 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgAEK-0007kr-IH for behave@ietf.org; Thu, 11 Oct 2007 22:26:25 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns0.neustar.com (Postfix) with ESMTP id 6045832880; Fri, 12 Oct 2007 02:26:24 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IgAEK-0006nX-9h; Thu, 11 Oct 2007 22:26:24 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: jdrosen@cisco.com From: IETF I-D Submission Tool Message-Id: Date: Thu, 11 Oct 2007 22:26:24 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: huitema@microsoft.com, behave@ietf.org, philip_matthews@magma.ca, dwing@cisco.com, rohan@ekabal.com Subject: [BEHAVE] New Version Notification for draft-ietf-behave-rfc3489bis-11 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org A new version of I-D, draft-ietf-behave-rfc3489bis-11.txt has been successfuly submitted by Jonathan Rosenberg and posted to the IETF repository. Filename: draft-ietf-behave-rfc3489bis Revision: 11 Title: Session Traversal Utilities for (NAT) (STUN) Creation_date: 2007-10-11 WG ID: behave Number_of_pages: 44 Abstract: 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. The IETF Secretariat. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Oct 11 22:30:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgAHs-0002dE-U9; Thu, 11 Oct 2007 22:30:04 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IgAHr-0002d6-PK for behave-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 22:30:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgAHr-0002co-0D; Thu, 11 Oct 2007 22:30:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgAHq-0007qg-JR; Thu, 11 Oct 2007 22:30:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 754C926E77; Fri, 12 Oct 2007 02:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IgAHq-0006yO-At; Thu, 11 Oct 2007 22:30:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 11 Oct 2007 22:30:02 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-rfc3489bis-11.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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-11.txt Pages : 44 Date : 2007-10-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-11.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-11.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-11.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: <2007-10-11222620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-rfc3489bis-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-rfc3489bis-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-11222620.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 https://www1.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Fri Oct 12 02:52:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgENd-0001oq-0V; Fri, 12 Oct 2007 02:52:17 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IgENb-0001i5-Np for behave-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 02:52:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgENW-0001Vx-U0 for behave@ietf.org; Fri, 12 Oct 2007 02:52:10 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgENQ-000736-Hi for behave@ietf.org; Fri, 12 Oct 2007 02:52:10 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9C6pduM026961; Fri, 12 Oct 2007 09:52:02 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 09:51:59 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 09:51:58 +0300 Received: from esdhcp04194.research.nokia.com ([172.21.41.94]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 09:51:58 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org, laine+behave@laine.org Subject: Re: [BEHAVE] TURN status and direction Date: Fri, 12 Oct 2007 09:52:29 +0300 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <470AAA56.5040301@cisco.com> <200710111507.51345.remi.denis-courmont@nokia.com> <470E4150.70701@laine.org> In-Reply-To: <470E4150.70701@laine.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200710120952.29926.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 12 Oct 2007 06:51:58.0560 (UTC) FILETIME=[6269EE00:01C80C9C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Laine, As I already noted, real-life MTUs tend to be multiple of 8, and are pretty= =20 much always multiple of 4 bytes. As such, I have no problem using a two byt= e=20 header, or even 4 bytes, if it is deemed that NAT-like O(1) IP&UDP checksum= =20 adjustment is a nice thing to have. In fact, one big advantage with the 4 bytes header may be to harmonize the = UDP=20 and TCP framing of TURN, i.e. two bytes channel and two bytes length. That= =20 being noted, I am not an author to the TURN I-D, nor am I attending the DT. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Oct 12 02:54:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgEPu-0007R5-So; Fri, 12 Oct 2007 02:54:38 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IgEPs-0007G0-Jg for behave-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 02:54:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgEPs-0007Fs-AD for behave@ietf.org; Fri, 12 Oct 2007 02:54:36 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgEPq-00076S-VB for behave@ietf.org; Fri, 12 Oct 2007 02:54:36 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9C6sQjM028961 for ; Fri, 12 Oct 2007 09:54:33 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 09:54:31 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 09:54:31 +0300 Received: from esdhcp04194.research.nokia.com ([172.21.41.94]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 09:54:31 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] TURN status and direction Date: Fri, 12 Oct 2007 09:55:03 +0300 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <470AAA56.5040301@cisco.com> <470D0F6B.2050702@laine.org> <14C0B7F7-2517-4B37-A52E-E39ACEB34414@briank.com> In-Reply-To: <14C0B7F7-2517-4B37-A52E-E39ACEB34414@briank.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200710120955.03164.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 12 Oct 2007 06:54:31.0520 (UTC) FILETIME=[BD95C600:01C80C9C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Le Friday 12 October 2007 02:05:04 ext Brian Korver, vous avez =E9crit=A0: > I don't see the point of going to a 2 byte channel number tho'. > Either the TURN server is relaying the packet or processing it > locally (channel=3D0). In the former case (which is the common case), > alignment doesn't matter but bumping up against MTU limits does. In > the later case, alignment may be required (or at least desired), but > these events don't occur often and so an extra memcpy for the > purposes of alignment is a small price to pay for optimizing the > common case. The point of 2 bytes rather than 1 byte channel ID is that you can "fix" th= e=20 outer UDP checksum with a single substraction. Many NATs device "fix" the U= DP=20 checksum by simply substracting and adding the modified port numbers, rathe= r=20 than checksumming the entire UDP payload. Of course, this type of optimization is only valid for raw (in-kernel)=20 implementations, where the checksum field can be accessed. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Oct 12 10:12:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgLFV-0002fW-7c; Fri, 12 Oct 2007 10:12:21 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IgLFT-0002dQ-J9 for behave-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 10:12:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgLFT-0002cG-8T; Fri, 12 Oct 2007 10:12:19 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgLFT-00080c-0f; Fri, 12 Oct 2007 10:12:19 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id AB4E8175C0; Fri, 12 Oct 2007 14:12:08 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IgLFI-00076R-7H; Fri, 12 Oct 2007 10:12:08 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Fri, 12 Oct 2007 10:12:08 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: behave@ietf.org Subject: [BEHAVE] Last Call: draft-ietf-behave-rfc3489bis (Session Traversal Utilities for (NAT) (STUN)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org The IESG has received a request from the Behavior Engineering for Hindrance Avoidance WG (behave) to consider the following document: - 'Session Traversal Utilities for (NAT) (STUN) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-10-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-11.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12416&rfc_flag=0 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Oct 12 14:29:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgPF3-0005yn-6o; Fri, 12 Oct 2007 14:28:09 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IgPF2-0005yg-AN for behave-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 14:28:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgPF2-0005x3-0D for behave@ietf.org; Fri, 12 Oct 2007 14:28:08 -0400 Received: from oe8.briank.com ([198.144.201.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgPEv-0007uk-Ja for behave@ietf.org; Fri, 12 Oct 2007 14:28:07 -0400 Received: from [192.168.255.18] (sol-ethernet.local.briank.com [192.168.255.18]) by oe8.briank.com (8.13.7/8.12.3) with ESMTP id l9CIRlFW025400; Fri, 12 Oct 2007 11:27:49 -0700 (PDT) (envelope-from briank@briank.com) In-Reply-To: <200710120955.03164.remi.denis-courmont@nokia.com> References: <470AAA56.5040301@cisco.com> <470D0F6B.2050702@laine.org> <14C0B7F7-2517-4B37-A52E-E39ACEB34414@briank.com> <200710120955.03164.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Brian Korver Subject: Re: [BEHAVE] TURN status and direction Date: Fri, 12 Oct 2007 11:27:46 -0700 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Oct 11, 2007, at 11:55 PM, R=E9mi Denis-Courmont wrote > Le Friday 12 October 2007 02:05:04 ext Brian Korver, vous avez =E9crit = : >> I don't see the point of going to a 2 byte channel number tho'. >> Either the TURN server is relaying the packet or processing it >> locally (channel=3D0). In the former case (which is the common = case), >> alignment doesn't matter but bumping up against MTU limits does. In >> the later case, alignment may be required (or at least desired), but >> these events don't occur often and so an extra memcpy for the >> purposes of alignment is a small price to pay for optimizing the >> common case. > > The point of 2 bytes rather than 1 byte channel ID is that you can =20 > "fix" the > outer UDP checksum with a single substraction. Many NATs device =20 > "fix" the UDP > checksum by simply substracting and adding the modified port =20 > numbers, rather > than checksumming the entire UDP payload. > > Of course, this type of optimization is only valid for raw (in-kernel) > implementations, where the checksum field can be accessed. We're optimizing for in-kernel NAT implementations? Hmm, I still don't see the real point to the 2 byte channel number. > > --=20 > R=E9mi Denis-Courmont > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave -brian briank@briank.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Oct 12 14:32:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgPIt-0006KL-KP; Fri, 12 Oct 2007 14:32:07 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IgPIs-0006KF-RR for behave-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 14:32:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgPIs-0006K7-Hu for behave@ietf.org; Fri, 12 Oct 2007 14:32:06 -0400 Received: from oe8.briank.com ([198.144.201.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgPIq-00082Y-Ru for behave@ietf.org; Fri, 12 Oct 2007 14:32:06 -0400 Received: from [192.168.255.18] (sol-ethernet.local.briank.com [192.168.255.18]) by oe8.briank.com (8.13.7/8.12.3) with ESMTP id l9CIW4XV025454; Fri, 12 Oct 2007 11:32:04 -0700 (PDT) (envelope-from briank@briank.com) In-Reply-To: <200710120952.29926.remi.denis-courmont@nokia.com> References: <470AAA56.5040301@cisco.com> <200710111507.51345.remi.denis-courmont@nokia.com> <470E4150.70701@laine.org> <200710120952.29926.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <87979AAD-970B-4290-B4BD-97AC975B166C@briank.com> Content-Transfer-Encoding: quoted-printable From: Brian Korver Subject: Re: [BEHAVE] TURN status and direction Date: Fri, 12 Oct 2007 11:32:03 -0700 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Oct 11, 2007, at 11:52 PM, R=E9mi Denis-Courmont wrote: > Laine, > > As I already noted, real-life MTUs tend to be multiple of 8, and =20 > are pretty > much always multiple of 4 bytes. As such, I have no problem using a =20= > two byte > header, or even 4 bytes, if it is deemed that NAT-like O(1) IP&UDP =20 > checksum > adjustment is a nice thing to have. I have been assuming that packet sizes are essentially random, but =20 perhaps that's not a correct assumption. Specifically, I assume that increasing the packet size by 2 bytes instead of 1 byte will make it more likely =20= that the packet will then exceed the MTU. Exceeding the MTU seems like an especially bad thing for TURN to do. > > In fact, one big advantage with the 4 bytes header may be to =20 > harmonize the UDP > and TCP framing of TURN, i.e. two bytes channel and two bytes =20 > length. That > being noted, I am not an author to the TURN I-D, nor am I attending =20= > the DT. > > --=20 > R=E9mi Denis-Courmont > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave -brian briank@briank.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Oct 12 17:42:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgSGE-0007SO-6Q; Fri, 12 Oct 2007 17:41:34 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IgSGD-0007OE-5r for behave-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 17:41:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgSGC-0007Ll-RD for behave@ietf.org; Fri, 12 Oct 2007 17:41:32 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgSGB-0005vS-HY for behave@ietf.org; Fri, 12 Oct 2007 17:41:32 -0400 X-IronPort-AV: E=Sophos;i="4.21,268,1188802800"; d="scan'208";a="534554530" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 12 Oct 2007 14:41:31 -0700 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 l9CLfUFk014923; Fri, 12 Oct 2007 14:41:30 -0700 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 l9CLfUsZ023754; Fri, 12 Oct 2007 21:41:30 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 14:41:30 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 14:41:29 -0700 Message-ID: <470FEA22.80201@cisco.com> Date: Fri, 12 Oct 2007 17:41:54 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Korver Subject: Re: [BEHAVE] TURN status and direction References: <470AAA56.5040301@cisco.com> <470D0F6B.2050702@laine.org> <14C0B7F7-2517-4B37-A52E-E39ACEB34414@briank.com> <200710120955.03164.remi.denis-courmont@nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 12 Oct 2007 21:41:29.0613 (UTC) FILETIME=[A60A53D0:01C80D18] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3452; t=1192225290; x=1193089290; c=relaxed/simple; s=sjdkim2002; 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]=20TURN=20status=20and=20direction |Sender:=20; bh=q0LdDX8QvYM3ILT5VJgPbHW5VWYPYKsA6Fr+jfR4vok=; b=HPI09swAzrDHLfx3fxQUC2qF3S/b/HYZL2YoPC4T9oU8S1+6xTbi0b6brB+OxhMzK16/hpP5 0NybIlAY+tm/V1M/wIyMF8+fF/c2lbWCY+BIHagwBcWeMdnScTIj2+yC; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org The design team had a call today to discuss all of this. Our thinking was this: 1. its always a good thing to support real implementations; if folks want to do kernel level implementations and they get a measurable benefit by using an even number of bytes for the overhead, thats a good thing 2. There is a big jump in complexity once we make usage of the channel mechanism optional. In fact the overall protocol becomes more complex than if we had left it out. A big thing to remember is that, with ICE, TURN ends up being the 'mechanism of last resort', and if the rest of behaves deliverables are implemented, the need for turn goes away. So given that it is a protocol meant to address a corner case that goes away, I think you need to drive the complexity way down, even at the expense of a few more bytes. So I'd rather ALWAYS use it. 3. While you can work your way around the word aligmnent issues and still have a decent implementation that performs well, its likely this will be troubling for some implementors. 4. the unification of the framing between UDP and TCP is attractive. So I'd propose that the framing for UDP also use the 32 bit framing that TCP uses. This would include a 16 bit length that is always set to zero for UDP. This also makes it predictable so it can be compressed out should someone have real heartache about it (a ROHC extension or something could handle that I suspect). -Jonathan R. Brian Korver wrote: > On Oct 11, 2007, at 11:55 PM, Rémi Denis-Courmont wrote >> Le Friday 12 October 2007 02:05:04 ext Brian Korver, vous avez écrit : >>> I don't see the point of going to a 2 byte channel number tho'. >>> Either the TURN server is relaying the packet or processing it >>> locally (channel=0). In the former case (which is the common case), >>> alignment doesn't matter but bumping up against MTU limits does. In >>> the later case, alignment may be required (or at least desired), but >>> these events don't occur often and so an extra memcpy for the >>> purposes of alignment is a small price to pay for optimizing the >>> common case. >> >> The point of 2 bytes rather than 1 byte channel ID is that you can >> "fix" the >> outer UDP checksum with a single substraction. Many NATs device "fix" >> the UDP >> checksum by simply substracting and adding the modified port numbers, >> rather >> than checksumming the entire UDP payload. >> >> Of course, this type of optimization is only valid for raw (in-kernel) >> implementations, where the checksum field can be accessed. > > We're optimizing for in-kernel NAT implementations? Hmm, I still > don't see the real point to the 2 byte channel number. > > >> >> -- >> Rémi Denis-Courmont >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave > > -brian > briank@briank.com > > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Oct 15 14:46:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhUw0-0007Yx-DO; Mon, 15 Oct 2007 14:45:00 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IhUvy-0007Se-HM for behave-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 14:44:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhUvw-0007Od-Sx for behave@ietf.org; Mon, 15 Oct 2007 14:44:57 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhUvu-0006Qt-SZ for behave@ietf.org; Mon, 15 Oct 2007 14:44:56 -0400 X-IronPort-AV: E=Sophos;i="4.21,278,1188802800"; d="scan'208";a="535564384" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 15 Oct 2007 11:44:55 -0700 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 l9FIis3x027785; Mon, 15 Oct 2007 11:44:54 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id l9FIijmA005544; Mon, 15 Oct 2007 18:44:54 GMT In-Reply-To: <470FEA22.80201@cisco.com> References: <470AAA56.5040301@cisco.com> <470D0F6B.2050702@laine.org> <14C0B7F7-2517-4B37-A52E-E39ACEB34414@briank.com> <200710120955.03164.remi.denis-courmont@nokia.com> <470FEA22.80201@cisco.com> Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <3CEA1E64-BC11-4A43-9F34-052A80635645@cisco.com> Content-Transfer-Encoding: quoted-printable From: Cullen Jennings Subject: Re: [BEHAVE] TURN status and direction Date: Mon, 15 Oct 2007 11:44:26 -0700 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5020; t=1192473894; x=1193337894; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20status=20and=20direction |Sender:=20; bh=597f3aprFPpjaTLILNAgCurRTQjKGBYS+yNCx5n3UNs=; b=I3EqxgwdgAECamVTRs5vS69IB/5zCOVfJ0zaBcT4viJJtpSK8ki8sph0OLY99on79BkCBGB8 FOTK4HOJjOLe/HRpPMf9/hnT3bFdysk+/OfbxJGci9DVjVy5D5s3aW/n; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: Brian Korver , behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I don't know what I think of this change - not sure I really care, =20 but I don't view the reasons as very strong. On Oct 12, 2007, at 2:41 PM, Jonathan Rosenberg wrote: > The design team had a call today to discuss all of this. Our =20 > thinking was this: > > 1. its always a good thing to support real implementations; if =20 > folks want to do kernel level implementations and they get a =20 > measurable benefit by using an even number of bytes for the =20 > overhead, thats a good thing I don't believe this would offer any performance improvement in the =20 kernel or not - any modern processor I am aware of can copy and =20 checksum the data just as fast as coping the data. > > 2. There is a big jump in complexity once we make usage of the =20 > channel mechanism optional. In fact the overall protocol becomes =20 > more complex than if we had left it out. A big thing to remember is =20= > that, with ICE, TURN ends up being the 'mechanism of last resort', =20 > and if the rest of behaves deliverables are implemented, the need =20 > for turn goes away. So given that it is a protocol meant to address =20= > a corner case that goes away, I think you need to drive the =20 > complexity way down, even at the expense of a few more bytes. So =20 > I'd rather ALWAYS use it. Agree with the goal of making the protocol less complicated but I =20 really have a hard time believing the inclusion of a length field =20 that is always set to zero for UDP somehow makes the protocol =20 substantially less complex. > > 3. While you can work your way around the word aligmnent issues and =20= > still have a decent implementation that performs well, its likely =20 > this will be troubling for some implementors. Again, I don't believe this at all. Dealing with a TCP stream is =20 going to more or less make you deal with misaligned stuff anyways. We =20= are talking a handful of lines of code. > > 4. the unification of the framing between UDP and TCP is attractive. Personally I view this as amazingly minimal since the code for =20 reading them will still be fairly separate due to the difference in =20 handling connected TCP sockets and most likely a single file =20 descriptor for the UDP implementations. > > > So I'd propose that the framing for UDP also use the 32 bit framing =20= > that TCP uses. This would include a 16 bit length that is always =20 > set to zero for UDP. This also makes it predictable so it can be =20 > compressed out should someone have real heartache about it (a ROHC =20 > extension or something could handle that I suspect). I don't know that I really have an opinion on if this is a good =20 change or not but I just find the reasons sort of dubious. > > -Jonathan R. > > Brian Korver wrote: >> On Oct 11, 2007, at 11:55 PM, R=E9mi Denis-Courmont wrote >>> Le Friday 12 October 2007 02:05:04 ext Brian Korver, vous avez =20 >>> =E9crit : >>>> I don't see the point of going to a 2 byte channel number tho'. >>>> Either the TURN server is relaying the packet or processing it >>>> locally (channel=3D0). In the former case (which is the common =20 >>>> case), >>>> alignment doesn't matter but bumping up against MTU limits =20 >>>> does. In >>>> the later case, alignment may be required (or at least desired), =20= >>>> but >>>> these events don't occur often and so an extra memcpy for the >>>> purposes of alignment is a small price to pay for optimizing the >>>> common case. >>> >>> The point of 2 bytes rather than 1 byte channel ID is that you =20 >>> can "fix" the >>> outer UDP checksum with a single substraction. Many NATs device =20 >>> "fix" the UDP >>> checksum by simply substracting and adding the modified port =20 >>> numbers, rather >>> than checksumming the entire UDP payload. >>> >>> Of course, this type of optimization is only valid for raw (in-=20 >>> kernel) >>> implementations, where the checksum field can be accessed. >> We're optimizing for in-kernel NAT implementations? Hmm, I still >> don't see the real point to the 2 byte channel number. >>> >>> --=20 >>> R=E9mi Denis-Courmont >>> >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www1.ietf.org/mailman/listinfo/behave >> -brian >> briank@briank.com >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave > > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ =20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Oct 15 14:55:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhV5q-0000i7-VU; Mon, 15 Oct 2007 14:55:10 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IhV5q-0000h2-D7 for behave-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 14:55:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhV5p-0000g6-49 for behave@ietf.org; Mon, 15 Oct 2007 14:55:09 -0400 Received: from [209.213.211.195] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhV5o-0002Pt-Mk for behave@ietf.org; Mon, 15 Oct 2007 14:55:09 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id D659733C28; Mon, 15 Oct 2007 11:50:59 -0700 (PDT) Date: Mon, 15 Oct 2007 11:50:59 -0700 From: Eric Rescorla To: Cullen Jennings Subject: Re: [BEHAVE] TURN status and direction In-Reply-To: <3CEA1E64-BC11-4A43-9F34-052A80635645@cisco.com> References: <470AAA56.5040301@cisco.com> <470D0F6B.2050702@laine.org> <14C0B7F7-2517-4B37-A52E-E39ACEB34414@briank.com> <200710120955.03164.remi.denis-courmont@nokia.com> <470FEA22.80201@cisco.com> <3CEA1E64-BC11-4A43-9F34-052A80635645@cisco.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") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071015185059.D659733C28@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Brian Korver , behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org At Mon, 15 Oct 2007 11:44:26 -0700, Cullen Jennings wrote: > > > I don't know what I think of this change - not sure I really care, > but I don't view the reasons as very strong. > > On Oct 12, 2007, at 2:41 PM, Jonathan Rosenberg wrote: > > > The design team had a call today to discuss all of this. Our > > thinking was this: > > > > 1. its always a good thing to support real implementations; if > > folks want to do kernel level implementations and they get a > > measurable benefit by using an even number of bytes for the > > overhead, thats a good thing > > I don't believe this would offer any performance improvement in the > kernel or not - any modern processor I am aware of can copy and > checksum the data just as fast as coping the data. I tend to agree with Cullen here. Do we have some actual measurements? > > 2. There is a big jump in complexity once we make usage of the > > channel mechanism optional. In fact the overall protocol becomes > > more complex than if we had left it out. A big thing to remember is > > that, with ICE, TURN ends up being the 'mechanism of last resort', > > and if the rest of behaves deliverables are implemented, the need > > for turn goes away. So given that it is a protocol meant to address > > a corner case that goes away, I think you need to drive the > > complexity way down, even at the expense of a few more bytes. So > > I'd rather ALWAYS use it. > > Agree with the goal of making the protocol less complicated but I > really have a hard time believing the inclusion of a length field > that is always set to zero for UDP somehow makes the protocol > substantially less complex. To the extent to which we care about on-the-wire packet size, it seems like adding 2 bytes to avoid an if statement in the code seems unwise. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Oct 16 01:28:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IheyH-00023A-LV; Tue, 16 Oct 2007 01:28:01 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IheyF-00021w-A8 for behave-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 01:27:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IheyE-00020D-97 for behave@ietf.org; Tue, 16 Oct 2007 01:27:58 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IheyD-0003if-SO for behave@ietf.org; Tue, 16 Oct 2007 01:27:58 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns1.neustar.com (Postfix) with ESMTP id AB08426E4D; Tue, 16 Oct 2007 05:27:42 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1Ihexy-0000aY-Jm; Tue, 16 Oct 2007 01:27:42 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: srisuresh@yahoo.com From: IETF I-D Submission Tool Message-Id: Date: Tue, 16 Oct 2007 01:27:42 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: baford@mit.edu, dank06@kegel.com, behave@ietf.org Subject: [BEHAVE] New Version Notification for draft-ietf-behave-p2p-state-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org A new version of I-D, draft-ietf-behave-p2p-state-05.txt has been successfuly submitted by Pyda Srisuresh and posted to the IETF repository. Filename: draft-ietf-behave-p2p-state Revision: 05 Title: State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs) Creation_date: 2007-10-15 WG ID: behave Number_of_pages: 29 Abstract: This memo documents the various methods known to be in use by applications to establish direct communication in the presence of Network Address Translators (NATs) at the current time. Although this memo is intended to be mainly descriptive, the Security Considerations section makes some purely advisory recommendations about how to deal with security vulnerabilities the applications could inadvertently create when using the methods described. This memo covers NAT traversal approaches used by both TCP and UDP based applications. This memo is not an endorsement of the methods described, but merely an attempt to capture them in a document. The IETF Secretariat. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Oct 16 01:30:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihf0N-00047C-Nf; Tue, 16 Oct 2007 01:30:11 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Ihf0H-000441-Cw for behave-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 01:30:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihf0F-00042P-K4; Tue, 16 Oct 2007 01:30:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ihf0E-0003xn-Fi; Tue, 16 Oct 2007 01:30:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 55A41329F1; Tue, 16 Oct 2007 05:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ihf0E-0003Ut-6W; Tue, 16 Oct 2007 01:30:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 16 Oct 2007 01:30:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-p2p-state-05.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 : State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs) Author(s) : P. Srisuresh, et al. Filename : draft-ietf-behave-p2p-state-05.txt Pages : 29 Date : 2007-10-16 This memo documents the various methods known to be in use by applications to establish direct communication in the presence of Network Address Translators (NATs) at the current time. Although this memo is intended to be mainly descriptive, the Security Considerations section makes some purely advisory recommendations about how to deal with security vulnerabilities the applications could inadvertently create when using the methods described. This memo covers NAT traversal approaches used by both TCP and UDP based applications. This memo is not an endorsement of the methods described, but merely an attempt to capture them in a document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-p2p-state-05.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-p2p-state-05.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-p2p-state-05.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: <2007-10-16012740.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-p2p-state-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-p2p-state-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-16012740.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 https://www1.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Tue Oct 16 01:30:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihf0q-0004Pq-NV; Tue, 16 Oct 2007 01:30:40 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Ihf0k-0004MM-Fv for behave-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 01:30:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihf0j-0004LB-Cs; Tue, 16 Oct 2007 01:30:33 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ihf0i-00041K-94; Tue, 16 Oct 2007 01:30:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 3FC8E329ED; Tue, 16 Oct 2007 05:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ihf0E-0003Uo-4w; Tue, 16 Oct 2007 01:30:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 16 Oct 2007 01:30:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-nat-icmp-06.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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-06.txt Pages : 22 Date : 2007-10-16 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-06.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-06.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-06.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: <2007-10-16012658.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-nat-icmp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-nat-icmp-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-16012658.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 https://www1.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Tue Oct 16 01:54:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhfMw-0003pZ-6n; Tue, 16 Oct 2007 01:53:30 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IhfMu-0003pT-IW for behave-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 01:53:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhfMt-0003pB-91 for behave@ietf.org; Tue, 16 Oct 2007 01:53:27 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhfMs-0005TG-5Y for behave@ietf.org; Tue, 16 Oct 2007 01:53:27 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns0.neustar.com (Postfix) with ESMTP id AD4A4329E4; Tue, 16 Oct 2007 05:27:00 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IhexI-0000aK-K6; Tue, 16 Oct 2007 01:27:00 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: srisuresh@yahoo.com From: IETF I-D Submission Tool Message-Id: Date: Tue, 16 Oct 2007 01:27:00 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: baford@mit.edu, behave@ietf.org Subject: [BEHAVE] New Version Notification for draft-ietf-behave-nat-icmp-06 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org A new version of I-D, draft-ietf-behave-nat-icmp-06.txt has been successfuly submitted by Pyda Srisuresh and posted to the IETF repository. Filename: draft-ietf-behave-nat-icmp Revision: 06 Title: NAT Behavioral Requirements for ICMP protocol Creation_date: 2007-10-15 WG ID: behave Number_of_pages: 22 Abstract: 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. The IETF Secretariat. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Oct 16 16:19:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihsrb-0003aP-IC; Tue, 16 Oct 2007 16:18:03 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IhsrZ-0003Yo-Cy for behave-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 16:18:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhsrY-0003YB-8i for behave@ietf.org; Tue, 16 Oct 2007 16:18:00 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhsrX-0004S1-Tm for behave@ietf.org; Tue, 16 Oct 2007 16:18:00 -0400 X-IronPort-AV: E=Sophos;i="4.21,284,1188802800"; d="scan'208";a="181259086" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 16 Oct 2007 13:17:49 -0700 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 l9GKHnfu009275 for ; Tue, 16 Oct 2007 13:17:49 -0700 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 l9GKHksj019818 for ; Tue, 16 Oct 2007 20:17:49 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); Tue, 16 Oct 2007 13:17:22 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 13:17:22 -0700 Message-ID: <47151C6C.8030000@cisco.com> Date: Tue, 16 Oct 2007 16:17:48 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2007 20:17:22.0338 (UTC) FILETIME=[8F484820:01C81031] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=710; t=1192565869; x=1193429869; 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:=20General=20consensus=20on=20a=20UDP=20shim=20for=20TURN |Sender:=20; bh=/AeHBYnqlVo4OXuk/4S6abNKHa8vxkI5EcFrUpGOf/4=; b=GZ87oyWe01dFkXv+GWAbqJ5Gz1aAvXohgFIGWI+lRNpbc0PLNuiPgZlUmflui9aAkcjyPa3h /Dw7x9xKPdtkUx757QUZ5n+rOliR9aY7QuAE2gbP7KMZumTmIKsi8EcB; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [BEHAVE] General consensus on a UDP shim for TURN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org The TURN editing team is anxious to start making changes to TURN. The big thing we need to get group consensus on is this: Is there general consensus around adding some kind of shim (we can debate 8 vs. 32 bits) for UDP, for the purposes of adding a channel concept so we can remove the active destination functionality from the spec? Please weigh in. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Oct 17 04:22:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii49R-0002R3-6o; Wed, 17 Oct 2007 04:21:13 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Ii49O-0002Px-Vi for behave-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 04:21:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii49N-0002LD-RN for behave@ietf.org; Wed, 17 Oct 2007 04:21:09 -0400 Received: from wx-out-0506.google.com ([66.249.82.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ii49C-0002pM-8g for behave@ietf.org; Wed, 17 Oct 2007 04:21:07 -0400 Received: by wx-out-0506.google.com with SMTP id s8so2059384wxc for ; Wed, 17 Oct 2007 01:20:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=/BpPvrZsxH/PuP7hI8tMmj/Y5L7rZ/wGHKM8G0fx67M=; b=iej34UE/I1QunV+vEbIx+GRQmHp5ExXhI+KI/KsF52iVopjJnMXtFn3PyGVkS3GRUCeRGDJsqzAf8m4gFp0hjSnfJ0DQuPR1hQeDtMS2IgsSMt19hFGjaHPj2QRYVo3MPf3pbceWQpQUY1UDAn65htIK6iuwxZ2mt+86y8Xqnxw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=oa08Bjw+ZcFYzusGYHm2RCXtoFUnUvqkvq8KudHVMIgQdTgg0CLJqsCPk5cJSNW+8GHu0VUkhYBMVi2/NGYTa2AchUW+Tx0Wbq1WKEVKYR20xtk7sadP/UypUlIuWDslXRGBza9pLycICEaw+hpDlAeq8cm8z/IUa0kyNhi3uh4= Received: by 10.142.201.3 with SMTP id y3mr2404084wff.1192609214587; Wed, 17 Oct 2007 01:20:14 -0700 (PDT) Received: by 10.142.245.16 with HTTP; Wed, 17 Oct 2007 01:20:14 -0700 (PDT) Message-ID: Date: Wed, 17 Oct 2007 01:20:14 -0700 From: "Derek MacDonald" To: "Jonathan Rosenberg" Subject: Re: [BEHAVE] General consensus on a UDP shim for TURN In-Reply-To: <47151C6C.8030000@cisco.com> MIME-Version: 1.0 References: <47151C6C.8030000@cisco.com> X-Google-Sender-Auth: 7c890f8a8d8eecdd X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 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="===============0677006093==" Errors-To: behave-bounces@ietf.org --===============0677006093== Content-Type: multipart/alternative; boundary="----=_Part_13139_10687855.1192609214593" ------=_Part_13139_10687855.1192609214593 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I prefer the channel approach over the active destination approach mainly for aesthetic reasons. AD always seemed like a bit of a hack and required lots of jumping through hoops when forking happened, but it wasn't too hard to hide from the user of our turn library. That said, I think we need to keep the shim as light as possible; I have seen deployments where there is very little headroom in the UDP packets--~20 bytes. It's possible to optimize down to th bone when you have prediictable uris(numeric, 10 digit) and record routes(IP addrs) in your network. 8 bits sounds good:) -Derek On 10/16/07, Jonathan Rosenberg wrote: > > The TURN editing team is anxious to start making changes to TURN. The > big thing we need to get group consensus on is this: Is there general > consensus around adding some kind of shim (we can debate 8 vs. 32 bits) > for UDP, for the purposes of adding a channel concept so we can remove > the active destination functionality from the spec? > > Please weigh in. > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > ------=_Part_13139_10687855.1192609214593 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I prefer the channel approach over the active destination approach mainly for aesthetic reasons. AD always seemed like a bit of a hack and required lots of jumping through hoops when forking happened, but it wasn't too hard to hide from the user of our turn library.

That said, I think we need to keep the shim as light as possible; I have seen deployments where there is very little headroom in the UDP packets--~20 bytes.  It's possible to optimize down to th bone when you have prediictable uris(numeric, 10 digit) and record routes(IP addrs) in your network. 8 bits sounds good:)
-Derek


On 10/16/07, Jonathan Rosenberg <jdrosen@cisco.com> wrote:
The TURN editing team is anxious to start making changes to TURN. The
big thing we need to get group consensus on is this: Is there general
consensus around adding some kind of shim (we can debate 8 vs. 32 bits)
for UDP, for the purposes of adding a channel concept so we can remove
the active destination functionality from the spec?

Please weigh in.

Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com


_______________________________________________
Behave mailing list
Behave@ietf.org
https://www1.ietf.org/mailman/listinfo/behave

------=_Part_13139_10687855.1192609214593-- --===============0677006093== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --===============0677006093==-- From behave-bounces@ietf.org Wed Oct 17 10:19:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii9jp-0007PG-4V; Wed, 17 Oct 2007 10:19:09 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Ii9jl-0007Il-P5 for behave-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 10:19:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii9jk-0007ID-TB for behave@ietf.org; Wed, 17 Oct 2007 10:19:04 -0400 Received: from server.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ii9jf-0006Um-KM for behave@ietf.org; Wed, 17 Oct 2007 10:19:04 -0400 Received: by server.implementers.org (Postfix, from userid 1001) id 03561D9D403A; Wed, 17 Oct 2007 07:18:42 -0700 (PDT) Received: from [192.168.1.3] (c-24-4-253-5.hsd1.ca.comcast.net [24.4.253.5]) by server.implementers.org (Postfix) with ESMTP id 3DC75D9D4038 for ; Wed, 17 Oct 2007 07:18:39 -0700 (PDT) Message-ID: <471619BE.4050902@acm.org> Date: Wed, 17 Oct 2007 07:18:38 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071008) MIME-Version: 1.0 To: Behave WG Subject: Re: [BEHAVE] General consensus on a UDP shim for TURN References: <47151C6C.8030000@cisco.com> In-Reply-To: <47151C6C.8030000@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Jonathan Rosenberg wrote: > The TURN editing team is anxious to start making changes to TURN. The > big thing we need to get group consensus on is this: Is there general > consensus around adding some kind of shim (we can debate 8 vs. 32 bits) > for UDP, for the purposes of adding a channel concept so we can remove > the active destination functionality from the spec? I like the channel proposal. This is simpler to implement than the active destination stuff and also remove the problem of having to choose what destination is the active one. I already wrote some basic code implementing this, and didn't find any issue yet. I support using 16 bits for the channel #, and no length field. I fell better with 65535 channels available in each direction than 255, knowing that channels # cannot be reused. -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Oct 18 02:08:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiOXw-0003Fn-GZ; Thu, 18 Oct 2007 02:07:52 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IiOXt-0003Cq-71 for behave-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 02:07:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiOXo-0003AK-Ip for behave@ietf.org; Thu, 18 Oct 2007 02:07:44 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiOXi-00031B-TS for behave@ietf.org; Thu, 18 Oct 2007 02:07:44 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9I67Hw5001389; Thu, 18 Oct 2007 09:07:20 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 09:07:16 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 09:07:16 +0300 Received: from esdhcp04053.research.nokia.com ([172.21.40.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 09:07:16 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] General consensus on a UDP shim for TURN Date: Thu, 18 Oct 2007 09:07:56 +0300 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <47151C6C.8030000@cisco.com> In-Reply-To: <47151C6C.8030000@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200710180907.56664.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 18 Oct 2007 06:07:16.0081 (UTC) FILETIME=[22029E10:01C8114D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Le Tuesday 16 October 2007 23:17:48 ext Jonathan Rosenberg, vous avez =E9cr= it=A0: > The TURN editing team is anxious to start making changes to TURN. The > big thing we need to get group consensus on is this: Is there general > consensus around adding some kind of shim (we can debate 8 vs. 32 bits) > for UDP, for the purposes of adding a channel concept so we can remove > the active destination functionality from the spec? I tend to prefer fixed size "overhead" (whatever the size), but I won't whi= ne=20 if the SAD approach is maintained. But I really do NOT want to have both options in the protocol. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Oct 19 05:00:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iini5-0004aW-8T; Fri, 19 Oct 2007 05:00:01 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Iini2-0004YX-UL for behave-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 04:59:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iini1-0004YO-V7 for behave@ietf.org; Fri, 19 Oct 2007 04:59:58 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iini0-0001ux-RU for behave@ietf.org; Fri, 19 Oct 2007 04:59:57 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 37BCD2054D; Fri, 19 Oct 2007 10:59:56 +0200 (CEST) X-AuditID: c1b4fb3e-b1837bb0000007e1-47-4718720c72b5 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 13E02200BA; Fri, 19 Oct 2007 10:59:56 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 10:59:55 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 10:59:55 +0200 Message-ID: <4718720B.6040107@ericsson.com> Date: Fri, 19 Oct 2007 10:59:55 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Behave WG , draft-ietf-behave-rfc3489bis@tools.ietf.org X-Enigmail-Version: 0.95.3 Content-Type: multipart/mixed; boundary="------------030105020305070704080202" X-OriginalArrivalTime: 19 Oct 2007 08:59:55.0551 (UTC) FILETIME=[6B260AF0:01C8122E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: Peter Koch Subject: [BEHAVE] [Fwd: Re: DNS directorate review of draft-ietf-behave-rfc3489bis-11] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. --------------030105020305070704080202 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I requested a review of STUNbis from the DNS directorate and here is the review done by Peter Koch. Authors please respond to the comments he provide. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------030105020305070704080202 Content-Type: message/rfc822; name="Re: DNS directorate review of draft-ietf-behave-rfc3489bis-11.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="Re: DNS directorate review of draft-ietf-behave-rfc3489bis-1"; filename*1="1.eml" Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw103.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 00:05:26 +0200 Received: from mailgw2.ericsson.se ([193.180.251.37]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 00:05:26 +0200 Received: from mailgw2.ericsson.se (unknown [127.0.0.1]) by mailgw2.ericsson.se (Symantec Mail Security) with ESMTP id D45B820488 for ; Fri, 19 Oct 2007 00:05:25 +0200 (CEST) X-AuditID: c1b4fb25-b06e7bb000000831-22-4717d8a5b1d6 Received: from denic.de (fw-d-whp.denic.de [81.91.160.27]) by mailgw2.ericsson.se (Symantec Mail Security) with ESMTP id 3890F202AB for ; Fri, 19 Oct 2007 00:05:25 +0200 (CEST) Received: by unknown.office.denic.de (Postfix, from userid 501) id 3E8C654D3ED; Thu, 18 Oct 2007 23:59:01 +0200 (CEST) Date: Thu, 18 Oct 2007 23:59:00 +0200 From: Peter Koch To: Jari Arkko Cc: dns directorate , Magnus Westerlund Subject: Re: DNS directorate review of draft-ietf-behave-rfc3489bis-11 Message-ID: <20071018215900.GU5305@unknown.office.denic.de> References: <470F4261.6020908@ericsson.com> <470F6FC8.5080408@piuha.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <470F6FC8.5080408@piuha.net> User-Agent: Mutt/1.4.2.1i X-Brightmail-Tracker: AAAAAA== Return-Path: pk@DENIC.DE X-OriginalArrivalTime: 18 Oct 2007 22:05:26.0337 (UTC) FILETIME=[FCDF8310:01C811D2] On Fri, Oct 12, 2007 at 03:59:52PM +0300, Jari Arkko wrote: > Magnus Westerlund wrote: > > STUN (draft-ietf-behave-rfc3489bis-11) is using DNS to locate STUN > > services for the desired protocol (UDP or TCP). Could you please have > > the DNS directorate review what is written on this usage. I have reviewed this draft for the DNS Directorate and therefore focused on Section 9 "DNS Discovery of a Server" and the security considerations. There are several issues with the use of SRV RRs that need to be addressed. > 9. DNS Discovery of a Server > > This section describes an optional procedure for STUN that allows a > client to use DNS to determine the IP address and port of a server. > A STUN usage must describe if and when this extension is used. To > use this procedure, the client must have a domain name and a service > name; the usage must also describe how the client obtains these. NIT: since it's not about the client's name but the servers: "the client must _know_ ..."; otherwise easy to mis-read. > When a client wishes to locate a STUN server in the public Internet > that accepts Binding Request/Response transactions, the SRV service > name is "stun". STUN usages MAY define additional DNS SRV service > names. This is in violation of RFC 2782. The port name assigned by IANA is "nat-stun-port", so this should be the one used in SRV handling. Same for the definition of additional service names. > The domain name is resolved to a transport address using the SRV > procedures specified in [RFC2782]. The DNS SRV service name is the > service name provided as input to this procedure. The protocol in > the SRV lookup is the transport protocol the client will run STUN > over: "udp" for UDP, "tcp" for TCP, and "tls" for TLS-over-TCP. If, The introduction of "tls" as another string for the RFC 2782 "Proto" field also violates that RFC, since it's not defined as an IP protocol in the "protocol-numbers" registry. > in the future, additional SRV records are defined for TLS over other > transport protocols, those will need to utilize an SRV transport > token of the form "tls-foo" for transport protocol "foo". Even more so, the "Proto" parameter isn't application specific, so the draft under consideration is just the wrong place to make this reservation. > The procedures of RFC 2782 are followed to determine the server to > contact. RFC 2782 spells out the details of how a set of SRV records > are sorted and then tried. However, RFC2782 only states that the > client should "try to connect to the (protocol, address, service)" > without giving any details on what happens in the event of failure. I'm not sure I understand this concern. Since RFC 2782's section on "Usage rules" says that one should iterate over the sorted (according to Priority and Weight) list until a "connection" succeeds, isn't that all that's needed? > When following these procedures, if the STUN transaction times out > without receipt of a response, the client SHOULD retry the request to > the next server in the list of servers from the DNS SRV response. Well, _ordered_ list as of RFC 2782. > Such a retry is only possible for request/response transmissions, > since indication transactions generate no response or timeout. > > The default port for STUN requests is 3478, for both TCP and UDP. > Administrators SHOULD use this port in their SRV records for UDP and > TCP, but MAY use others. There is no default port for STUN over TLS, I'd emphasize here that the administrator _of the STUN server_ is encouraged to use port 3478 and then, subsequently, to use this port in the DNS, not vice versa. I.e., the DNS SRV RR should reflect which port is actually listened on. > however a STUN server SHOULD use a port number for TLS different from > 3478 so that the server can determine whether the first message it > will receive after the TCP connection is set up, is a STUN message or > a TLS message. > > If no SRV records were found, the client performs an A or AAAA record > lookup of the domain name. The result will be a list of IP The change here is to allow AAAA in addition to A, the original fallback mechanism already envisioned in RFC 2782. However, it's time to move forward and instead of extending a bad idea to v6 it should be terminated and no "fallback" given. Especially because this is not a legacy service that existed before SRV was invented and RFC 3489 already included the SRV usage, there's no need to address "old" v6 clients agnostic of SRV. Operational laziness shouldn't be encouraged. At the very least, the fallback MUST be excluded for explicit "stop" SRV RRs (those including the "." target). > addresses, each of which can be contacted at the default port using > UDP or TCP, independent of the STUN usage. For usages that require > TLS, lack of SRV records is equivalent to a failure of the > transaction, since the request or indication MUST NOT be sent unless > SRV records provided a transport address specifically for TLS. In the Security Considerations section the usual DNS caveats and threats should be mentioned, especially since SRV provides a level of indirection that can't be protected by use of TLS (you might end up to securely talk to the perfectly authenticated - albeit wrong - server). Also, even though the mechanism of obtaining the server's domain name is not specified in the draft, I'd suggest to mention the risk of hardcoding the domain name in the application software because of the chance to "loose" a domain name (by accidental expiry, legal action and so on). -Peter PS: Unrelated to DNS, aren't there privacy concerns worth mentioning because of the opportunity to monitor application usage? --------------030105020305070704080202 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --------------030105020305070704080202-- From behave-bounces@ietf.org Mon Oct 22 13:42:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik1Gz-00026Z-Iv; Mon, 22 Oct 2007 13:41:05 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Ik1Gy-00026L-6w for behave-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 13:41:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik1Gx-00025d-6l for behave@ietf.org; Mon, 22 Oct 2007 13:41:03 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-05.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik1Gw-0003Et-7R for behave@ietf.org; Mon, 22 Oct 2007 13:41:03 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Ik1GU-0003rF-2r; Mon, 22 Oct 2007 13:40:35 -0400 In-Reply-To: <4718720B.6040107@ericsson.com> References: <4718720B.6040107@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Mon, 22 Oct 2007 13:41:17 -0400 To: Magnus Westerlund , Peter Koch X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Cc: Behave WG , Dan Wing Subject: [BEHAVE] Re: [Fwd: Re: DNS directorate review of draft-ietf-behave-rfc3489bis-11] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I have given an initial response to some (but no all) of these points inline. - Philip On 19-Oct-07, at 04:59 , Magnus Westerlund wrote: > I requested a review of STUNbis from the DNS directorate and here > is the > review done by Peter Koch. Authors please respond to the comments he > provide. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > From: Peter Koch > Date: October 18, 2007 17:59:00 EDT (CA) > To: Jari Arkko > Cc: dns directorate , Magnus Westerlund > > Subject: Re: DNS directorate review of draft-ietf-behave-rfc3489bis-11 > > > On Fri, Oct 12, 2007 at 03:59:52PM +0300, Jari Arkko wrote: > >> Magnus Westerlund wrote: > >>> STUN (draft-ietf-behave-rfc3489bis-11) is using DNS to locate STUN >>> services for the desired protocol (UDP or TCP). Could you please >>> have >>> the DNS directorate review what is written on this usage. > > I have reviewed this draft for the DNS Directorate and therefore > focused > on Section 9 "DNS Discovery of a Server" and the security > considerations. > There are several issues with the use of SRV RRs that need to be > addressed. > >> 9. DNS Discovery of a Server >> >> This section describes an optional procedure for STUN that >> allows a >> client to use DNS to determine the IP address and port of a >> server. >> A STUN usage must describe if and when this extension is used. To >> use this procedure, the client must have a domain name and a >> service >> name; the usage must also describe how the client obtains these. > > NIT: since it's not about the client's name but the servers: "the > client > must _know_ ..."; otherwise easy to mis-read. Yes. This would improve readability. > >> When a client wishes to locate a STUN server in the public >> Internet >> that accepts Binding Request/Response transactions, the SRV >> service >> name is "stun". STUN usages MAY define additional DNS SRV service >> names. > > This is in violation of RFC 2782. The port name assigned by IANA is > "nat-stun-port", so this should be the one used in SRV handling. > Same for > the definition of additional service names. The use of "stun" for this service was introduced in RFC 3489, and I believe that there is already some deployment today. As I see it, the problem is that IANA assigned a name of "nat-stun- port" for the assigned port number for STUN, rather than simply "stun". So my initial thought is to see if IANA has any objections to changing the name of this port to "stun". > >> The domain name is resolved to a transport address using the SRV >> procedures specified in [RFC2782]. The DNS SRV service name is >> the >> service name provided as input to this procedure. The protocol in >> the SRV lookup is the transport protocol the client will run STUN >> over: "udp" for UDP, "tcp" for TCP, and "tls" for TLS-over- >> TCP. If, > > The introduction of "tls" as another string for the RFC 2782 > "Proto" field > also violates that RFC, since it's not defined as an IP protocol in > the > "protocol-numbers" registry. How do other protocols handle this issue (wanting to run over both TCP and TLS over TCP)? > >> The procedures of RFC 2782 are followed to determine the server to >> contact. RFC 2782 spells out the details of how a set of SRV >> records >> are sorted and then tried. However, RFC2782 only states that the >> client should "try to connect to the (protocol, address, service)" >> without giving any details on what happens in the event of >> failure. > > I'm not sure I understand this concern. Since RFC 2782's section on > "Usage rules" says that one should iterate over the sorted > (according to > Priority and Weight) list until a "connection" succeeds, isn't that > all > that's needed? This paragraph was added before I came on board as an author. However, I believe the concern is as follows. RCC 2782 says: for each address record found, try to connect to the (protocol, address, service). This doesn't say what to do if the attempt fails. Since there are at least conceivably a couple of ways this might be handled in STUN, it seems desirable to be explicit. Thus the document says: When following these procedures, if the STUN transaction times out without receipt of a response, the client SHOULD retry the request to the next server in the list of servers from the DNS SRV response. Such a retry is only possible for request/response transmissions, since indication transactions generate no response or timeout. > >> When following these procedures, if the STUN transaction times out >> without receipt of a response, the client SHOULD retry the >> request to >> the next server in the list of servers from the DNS SRV response. > > Well, _ordered_ list as of RFC 2782. I think that you are suggesting that this be reworded as "the next server in the order defined by RFC 2782". This seems good. >> >> The default port for STUN requests is 3478, for both TCP and UDP. >> Administrators SHOULD use this port in their SRV records for >> UDP and >> TCP, but MAY use others. There is no default port for STUN >> over TLS, > > I'd emphasize here that the administrator _of the STUN server_ is > encouraged > to use port 3478 and then, subsequently, to use this port in the DNS, > not vice versa. I.e., the DNS SRV RR should reflect which port is > actually > listened on. Yes. Good point. > >> however a STUN server SHOULD use a port number for TLS >> different from >> 3478 so that the server can determine whether the first message it >> will receive after the TCP connection is set up, is a STUN >> message or >> a TLS message. >> >> If no SRV records were found, the client performs an A or AAAA >> record >> lookup of the domain name. The result will be a list of IP > > The change here is to allow AAAA in addition to A, the original > fallback > mechanism already envisioned in RFC 2782. However, it's time to move > forward and instead of extending a bad idea to v6 it should be > terminated and > no "fallback" given. Especially because this is not a legacy > service that > existed before SRV was invented and RFC 3489 already included the > SRV usage, > there's no need to address "old" v6 clients agnostic of SRV. > Operational > laziness shouldn't be encouraged. > At the very least, the fallback MUST be excluded for explicit > "stop" SRV > RRs (those including the "." target). > >> addresses, each of which can be contacted at the default port >> using >> UDP or TCP, independent of the STUN usage. For usages that >> require >> TLS, lack of SRV records is equivalent to a failure of the >> transaction, since the request or indication MUST NOT be sent >> unless >> SRV records provided a transport address specifically for TLS. > > In the Security Considerations section the usual DNS caveats and > threats > should be mentioned, especially since SRV provides a level of > indirection > that can't be protected by use of TLS (you might end up to securely > talk > to the perfectly authenticated - albeit wrong - server). > Also, even though the mechanism of obtaining the server's domain name > is not specified in the draft, I'd suggest to mention the risk of > hardcoding > the domain name in the application software because of the chance to > "loose" a domain name (by accidental expiry, legal action and so on). > > -Peter > > PS: Unrelated to DNS, aren't there privacy concerns worth mentioning > because of the opportunity to monitor application usage? > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Oct 22 21:35:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik8fr-00026f-UQ; Mon, 22 Oct 2007 21:35:15 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Ik8fq-00022t-Cj for behave-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 21:35:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik8fp-000205-9J for behave@ietf.org; Mon, 22 Oct 2007 21:35:13 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik8fl-00044U-Uc for behave@ietf.org; Mon, 22 Oct 2007 21:35:10 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Ik8fj-0007I2-2p; Mon, 22 Oct 2007 21:35:08 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2C554067-E90F-446C-B405-FAA49BE489DF@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Mon, 22 Oct 2007 21:35:27 -0400 To: Behave WG X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Dan Wing Subject: [BEHAVE] Would anyone be negatively affected by this change? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org It was recently pointed out to us by Peter Koch (in a message forwarded to this list by Magnus) that http://www.iana.org/assignments/port-numbers assigns a service name of "nat-stun-port" to port 3478, which is the well-known port assigned to STUN. As Peter points out, this introduces an inconsistency with RFC 2782. One way to correct this inconsistency is to change the service name from "nat-stun-port" to just "stun". The authors of draft-ietf-behave-rfc3489bis would like to know if anyone would be negatively affected by this change if we were to go ahead with it. Does anyone currently use "nat-stun-port" as a service name for STUN? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Oct 26 03:40:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlJmp-00085r-Qt; Fri, 26 Oct 2007 03:39:19 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IlJmo-00084a-BW for behave-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 03:39:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlJmj-00081C-EM for behave@ietf.org; Fri, 26 Oct 2007 03:39:13 -0400 Received: from nz-out-0506.google.com ([64.233.162.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlJmd-0000lR-4x for behave@ietf.org; Fri, 26 Oct 2007 03:39:13 -0400 Received: by nz-out-0506.google.com with SMTP id n1so683451nzf for ; Fri, 26 Oct 2007 00:38:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=UhDr21o2N8+NTZOxd07yEFAa35cczq0yi1s3AluzA+4=; b=AqYHlZRpbwVU7hOBkXx5IhDrvAbBnYibo9hgUtGti/n/4eesovkqkiL4/N+zbBwzO0fxaWERRdLVzx4UGvP2km/lszEXqsKslc0oXAD3/GkBrQEXxpKxkUSCrKadMA+jGltTXnepgcyZphU/bUaIVv80e6O74/dN/PrJwV5LVlo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=REpEcdSNetPnVnEi0rekPfx5i3OkOeWWdCCRyxx7hQRfXrMpFjv5nJvRN3PxlghhfEdUsSUoYSkcinxbeQ1EjTMV90v+T+k/bZUGcH8WX+pfX1OcD0Helhe9xYvA7prMIM7o1hKJCFuyo6GPbmr/jlwxWTUXFOvsPMYIoj+JH0s= Received: by 10.142.215.5 with SMTP id n5mr779556wfg.1193384330920; Fri, 26 Oct 2007 00:38:50 -0700 (PDT) Received: by 10.142.89.5 with HTTP; Fri, 26 Oct 2007 00:38:50 -0700 (PDT) Message-ID: <8f8143dc0710260038n2fdd7feq7bf50d9d7e8c7f54@mail.gmail.com> Date: Fri, 26 Oct 2007 09:38:50 +0200 From: "=?ISO-8859-1?Q?Ga=EBl_Br=E9ard?=" To: behave@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [BEHAVE] TURN : How can a client ask a TCP disconnection ? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 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="===============1370990901==" Errors-To: behave-bounces@ietf.org --===============1370990901== Content-Type: multipart/alternative; boundary="----=_Part_5556_27933891.1193384330914" ------=_Part_5556_27933891.1193384330914 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline One simple question about TURN : Imagine the case where a TURN client has allocated a TCP address (a TCP server) on a TURN server. Several remote peers have established a connection on this allocated port. And now, the client wants to disconnect one of them (and only one). I did not found any request to do that. --=20 Ga=EBl Br=E9ard ------=_Part_5556_27933891.1193384330914 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
One simple question about TURN :

Imagine the case where a TURN c= lient has allocated a TCP address (a TCP server) on a TURN server.
Sever= al remote peers have established a connection on this allocated port.

And now, the client wants to disconnect one of them (and only one).
= I did not found any request to do that.


--
Ga=EBl Br=E9ard ------=_Part_5556_27933891.1193384330914-- --===============1370990901== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --===============1370990901==-- From behave-bounces@ietf.org Fri Oct 26 03:53:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlJzs-00016G-JM; Fri, 26 Oct 2007 03:52:48 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IlJzr-000169-C7 for behave-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 03:52:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlJzr-00015u-1t for behave@ietf.org; Fri, 26 Oct 2007 03:52:47 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlJzq-00084T-GT for behave@ietf.org; Fri, 26 Oct 2007 03:52:46 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9Q7qXWI025276; Fri, 26 Oct 2007 10:52:43 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 10:52:19 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 10:52:19 +0300 Received: from esdhcp04068.research.nokia.com ([172.21.40.68]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 10:52:17 +0300 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org, ext =?utf-8?q?Ga=C3=ABl_Br=C3=A9ard?= Subject: Re: [BEHAVE] TURN : How can a client ask a TCP disconnection ? Date: Fri, 26 Oct 2007 10:53:13 +0300 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <8f8143dc0710260038n2fdd7feq7bf50d9d7e8c7f54@mail.gmail.com> In-Reply-To: <8f8143dc0710260038n2fdd7feq7bf50d9d7e8c7f54@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200710261053.13990.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 26 Oct 2007 07:52:17.0880 (UTC) FILETIME=[217AD580:01C817A5] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Le Friday 26 October 2007 10:38:50 ext Ga=C3=ABl Br=C3=A9ard, vous avez =C3= =A9crit=C2=A0: > One simple question about TURN : > > Imagine the case where a TURN client has allocated a TCP address (a TCP > server) on a TURN server. > Several remote peers have established a connection on this allocated port. > > And now, the client wants to disconnect one of them (and only one). > I did not found any request to do that. It used to be so that you terminated the TCP connection. Multiple TCP=20 connections per TURN session was then added, but remains buggy to this day. As far as I understand, the current public draft is way out-of-sync with wh= ere=20 the WG is heading anyway. =2D-=20 R=C3=A9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Oct 26 13:31:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlT1v-0003Ks-E0; Fri, 26 Oct 2007 13:31:31 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IlT1t-0003Iz-Eg for behave-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 13:31:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlT1t-0003GG-3b; Fri, 26 Oct 2007 13:31:29 -0400 Received: from lancia.electric.net ([216.129.90.248]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlT1k-0001Re-G3; Fri, 26 Oct 2007 13:31:20 -0400 Received: from 1IlT1g-0006XI-UN by lancia.electric.net with emc1-ok (Exim 4.67) (envelope-from ) id 1IlT1h-0006ZA-TP; Fri, 26 Oct 2007 10:31:17 -0700 Received: by emcmailer; Fri, 26 Oct 2007 10:31:17 -0700 Received: from 64-85-36-161.ip.van.radiant.net ([64.85.36.161] helo=[127.0.0.1]) by lancia.electric.net with esmtpa (Exim 4.67) (envelope-from ) id 1IlT1g-0006XI-UN; Fri, 26 Oct 2007 10:31:16 -0700 Message-ID: <47222589.7060903@eyeball.com> Date: Fri, 26 Oct 2007 10:36:09 -0700 From: Raihan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: livio.torrero@polito.it Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Outbound-IP: 64.85.36.161 X-Env-From: raihan@eyeball.com X-Virus-Status: Scanned by VirusSMART (c) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: behave@ietf.org, mmusic@ietf.org Subject: [BEHAVE] Re: [MMUSIC] Looking for UAs supporting ICE X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi Livio, Sorry for the late response. My employer, Eyeball Networks, has a user-agent and other NAT-traversal solutions that support recent drafts of STUN, TURN and ICE. We have three products of interest: - Eyeball Messenger: A soft-client or user-agent that provides voice, video and IM features with NAT traversal using STUN, TURN and ICE. - AnyFirewall Engine: Industry's leading firewall and NAT traversal SDK offering a comprehensive implementation of STUN, TURN and ICE (along with optional support for UPnP gateways and HTTP-tunneling), and - AnyFirewall Server: A carrier-grade STUN and TURN server ready for mass deployment. Eyeball white-paper titled, "NAT Traversal using ICE for VoIP and Internet Communications" provides a high level overview of how NAT-traversal using ICE works, and how Eyeball solutions can help. (http://www.eyeball.com/technology/whitepapers/NAT_Traversal_Using_ICE.pdf) Hope this helps. Please let me know if you need additional information. Regards, Raihan ------------------- Date: Thu, 23 Aug 2007 16:45:23 +0200 >> From: Livio Torrero >> Subject: [MMUSIC] Looking for UAs supporting ICE >> To: MMUSIC >> Message-ID: <46CD9D83.6090305@polito.it> >> Content-Type: text/plain; charset=ISO-8859-15; format=flowed >> >> I'm currently investigating NAT traversal techniques for SIP User >> Agents >> and I've read all the ICE-related drafts. I'm very interested in it and >> >> I would like to try a UA supporting ICE. Could you please suggest me if >> >> and where I can download a free UA supporting ICE? If it is not >> possible, can you please suggest me commercial UAs supporting it? I've >> just tried Counterpath X-lite but it seems to me that the ICE version >> included is out of date. Is there any chance to have an UA supporting a >> >> more recent version? >> >> Best regards, >> Livio Torrero _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Oct 26 14:43:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlU9T-0008Qy-8y; Fri, 26 Oct 2007 14:43:23 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IlU9R-0008QH-Vg for behave-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 14:43:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlU9R-0008Q9-Kp for behave@ietf.org; Fri, 26 Oct 2007 14:43:21 -0400 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IlU9R-0003f1-1Q for behave@ietf.org; Fri, 26 Oct 2007 14:43:21 -0400 Received: from lappy ([98.207.96.5]) by quinthar.com for ; Fri, 26 Oct 2007 11:43:15 -0700 From: "David Barrett" To: "'Raihan'" , Subject: RE: [BEHAVE] Re: [MMUSIC] Looking for UAs supporting ICE Date: Fri, 26 Oct 2007 11:43:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <47222589.7060903@eyeball.com> Thread-Index: AcgX9nFINjOKLs9JSUmzqcfHaF0blQACXkwA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Message-Id: Cc: behave@ietf.org, mmusic@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org That's great! Do you have any test results showing the effectiveness of the NAT penetration technology? Specifically, what is the success rate of direct peer connectivity (non-TURN), and how long does it take to set up a connection? -david > -----Original Message----- > From: Raihan [mailto:raihan@eyeball.com] > Sent: Friday, October 26, 2007 10:36 AM > To: livio.torrero@polito.it > Cc: behave@ietf.org; mmusic@ietf.org > Subject: [BEHAVE] Re: [MMUSIC] Looking for UAs supporting ICE > > Hi Livio, > > Sorry for the late response. > > My employer, Eyeball Networks, has a user-agent and other NAT-traversal > solutions that support recent drafts of STUN, TURN and ICE. We have three > products of interest: > > - Eyeball Messenger: A soft-client or user-agent that provides voice, > video > and IM features with NAT traversal using STUN, TURN and ICE. > > - AnyFirewall Engine: Industry's leading firewall and NAT traversal SDK > offering a comprehensive implementation of STUN, TURN and ICE (along with > optional support for UPnP gateways and HTTP-tunneling), and > > - AnyFirewall Server: A carrier-grade STUN and TURN server ready for mass > deployment. > > Eyeball white-paper titled, "NAT Traversal using ICE for VoIP > and Internet Communications" provides a high level overview of how > NAT-traversal using ICE works, and how Eyeball solutions can help. > (http://www.eyeball.com/technology/whitepapers/NAT_Traversal_Using_ICE.pdf > ) > > Hope this helps. Please let me know if you need additional information. > > Regards, > Raihan > > > ------------------- > > Date: Thu, 23 Aug 2007 16:45:23 +0200 > >> From: Livio Torrero > >> Subject: [MMUSIC] Looking for UAs supporting ICE > >> To: MMUSIC > >> Message-ID: <46CD9D83.6090305@polito.it> > >> Content-Type: text/plain; charset=ISO-8859-15; format=flowed > >> > >> I'm currently investigating NAT traversal techniques for SIP User > >> Agents > >> and I've read all the ICE-related drafts. I'm very interested in it and > >> > >> I would like to try a UA supporting ICE. Could you please suggest me if > >> > >> and where I can download a free UA supporting ICE? If it is not > >> possible, can you please suggest me commercial UAs supporting it? I've > >> just tried Counterpath X-lite but it seems to me that the ICE version > >> included is out of date. Is there any chance to have an UA supporting a > >> > >> more recent version? > >> > >> Best regards, > >> Livio Torrero > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Oct 29 05:07:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImQa6-0005CX-6h; Mon, 29 Oct 2007 05:06:46 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ImQa4-0005CB-E2 for behave-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 05:06:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImQa4-0005BG-2j for behave@ietf.org; Mon, 29 Oct 2007 05:06:44 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImQa2-0001yD-LO for behave@ietf.org; Mon, 29 Oct 2007 05:06:44 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 345BA2135D; Mon, 29 Oct 2007 10:06:42 +0100 (CET) X-AuditID: c1b4fb3e-af833bb0000007e1-f0-4725a2a23312 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 169292145F; Mon, 29 Oct 2007 10:06:42 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Oct 2007 10:06:41 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Oct 2007 10:06:41 +0100 Message-ID: <4725A2A1.9050701@ericsson.com> Date: Mon, 29 Oct 2007 10:06:41 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Behave WG X-Enigmail-Version: 0.95.4 Content-Type: multipart/mixed; boundary="------------020202080703030309000103" X-OriginalArrivalTime: 29 Oct 2007 09:06:41.0695 (UTC) FILETIME=[055C32F0:01C81A0B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: Subject: [BEHAVE] [Fwd: DISCUSS and COMMENT: draft-ietf-behave-nat-icmp] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. --------------020202080703030309000103 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Behave, I think the discuss from Lars below needs WG discussion. I like to here opinions about this. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------020202080703030309000103 Content-Type: message/rfc822; name="DISCUSS and COMMENT: draft-ietf-behave-nat-icmp.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="DISCUSS and COMMENT: draft-ietf-behave-nat-icmp.eml" Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw103.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 27 Oct 2007 23:47:04 +0200 Received: from mailgw2.ericsson.se ([193.180.251.37]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 27 Oct 2007 23:47:03 +0200 Received: from mailgw2.ericsson.se (unknown [127.0.0.1]) by mailgw2.ericsson.se (Symantec Mail Security) with ESMTP id CCD9C20C5B for ; Sat, 27 Oct 2007 23:47:03 +0200 (CEST) X-AuditID: c1b4fb25-b06e7bb000000831-ea-4723b1d7d355 Received: from megatron.ietf.org (odin.ietf.ORG [156.154.16.145]) by mailgw2.ericsson.se (Symantec Mail Security) with ESMTP id 67D3620C67 for ; Sat, 27 Oct 2007 23:47:03 +0200 (CEST) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IltUf-0003mO-TW; Sat, 27 Oct 2007 17:46:57 -0400 Received: from iesg by megatron.ietf.org with local (Exim 4.43) id 1IltUe-0003mF-RW for iesg-confirm+ok@megatron.ietf.org; Sat, 27 Oct 2007 17:46:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IltUe-0003m6-HL for iesg@ietf.org; Sat, 27 Oct 2007 17:46:56 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IltUe-0001MM-7a for iesg@ietf.org; Sat, 27 Oct 2007 17:46:56 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id DE82817620; Sat, 27 Oct 2007 21:46:45 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IltUT-0005tj-EB; Sat, 27 Oct 2007 17:46:45 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: iesg@ietf.org From: Lars Eggert Message-Id: Date: Sat, 27 Oct 2007 17:46:45 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: behave-chairs@tools.ietf.org, draft-ietf-behave-nat-icmp@tools.ietf.org Subject: DISCUSS and COMMENT: draft-ietf-behave-nat-icmp X-BeenThere: iesg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: iesg.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iesg-bounces@ietf.org X-Brightmail-Tracker: AAAAAA== Return-Path: iesg-bounces@ietf.org X-OriginalArrivalTime: 27 Oct 2007 21:47:04.0035 (UTC) FILETIME=[E9915330:01C818E2] Discuss: Section 4.1., paragraph 4: > REQ-3: When an ICMP Error packet is received, the NAT device > SHOULD do the following. > a) If the IP checksum of the embedded packet fails to validate, drop > the Error packet DISCUSS: I disagree. (And I apologize for not catching this during my earlier review.) The reason that (part of) the packet that caused an ICMP message to be generated is included is for diagnostic purposes, so the end hosts can determine what went wrong and determine whether they need to react in some way. This can't happen if NATs drop these packets. Also, the reason why some end system OSs drop ICMP messages with invalid checksums is to protect against some attacks. NATs, however, are not firewalls. It is inappropriate for this document to specify NAT mechanisms that implement a specific security policy. There is also no IETF standard that recommends that end hosts drop ICMP packets with payloads that have invalid checksums, which is another reason why this document should not recommend that NATs do this. (And, as an aside, the effectiveness of this "security" measure is questionable, because if I can't spoof the complete packet with a valid checksum, I'd just include a partial packet in the payload, for which you can't validate the checksum, but that you must still act on.) Comment: Section 240, paragraph 0: > ICMP Query session timer MUST not expire in less than 60 seconds. We s/MUST not/MUST NOT/ Section 240, paragraph 1: > RECOMMEND however that the administrator(s) be allowed to configure RECOMMEND is not an RFC2119 term. You need to rephrase to say RECOMMENDED, MUST or REQUIRED. (Or use lowercase here, because REQ-2 has the correct 2119 phrasing.) --------------020202080703030309000103 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --------------020202080703030309000103-- From behave-bounces@ietf.org Mon Oct 29 09:46:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImUwZ-0003Lm-Ad; Mon, 29 Oct 2007 09:46:15 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ImUwW-0003KU-M5 for behave-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 09:46:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImUwW-0003KC-8c for behave@ietf.org; Mon, 29 Oct 2007 09:46:12 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImUwU-0000xy-RT for behave@ietf.org; Mon, 29 Oct 2007 09:46:12 -0400 X-IronPort-AV: E=Sophos;i="4.21,342,1188802800"; d="scan'208";a="13689196" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-4.cisco.com with ESMTP; 29 Oct 2007 06:46:09 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9TDk9DU030065; Mon, 29 Oct 2007 09:46:09 -0400 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 l9TDk6dM020674; Mon, 29 Oct 2007 13:46:06 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); Mon, 29 Oct 2007 09:46:06 -0400 Received: from [10.82.211.73] ([10.82.211.73]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Oct 2007 09:46:02 -0400 Message-ID: <47252B93.3040003@cisco.com> Date: Sun, 28 Oct 2007 20:38:43 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Philip Matthews References: <4718720B.6040107@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Oct 2007 13:46:06.0204 (UTC) FILETIME=[0DC943C0:01C81A32] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15508.000 X-TM-AS-Result: No--45.315700-8.000000-1 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10555; t=1193665569; x=1194529569; c=relaxed/simple; s=rtpdkim2001; 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[Fwd=3A=20Re=3A=20DNS=20directorate=20review=20of=20d raft-ietf-behave-rfc3489bis-11] |Sender:=20 |To:=20Philip=20Matthews=20; bh=Xr1dfjwvx7KqZ7521K4FbUe9Z0CBHSC00YVJq/k+b74=; b=NX9cMeBCMIka8ezZUTfUN/BFBBUMyKOv0L+97GPJBBAl7K2P31M+qovCklviPFiAMLdiU/9E 4TvltFYcN7dlJI9MnSiCLW8jI/triczuWDQLd9MwSaAELLrueW/7p+vE; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 1.8 (+) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Cc: Peter Koch , Behave WG , Dan Wing Subject: [BEHAVE] Re: [Fwd: Re: DNS directorate review of draft-ietf-behave-rfc3489bis-11] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Peter, Thanks for the review. Some additional comments and responses inline: Philip Matthews wrote: > I have given an initial response to some (but no all) of these points > inline. > > - Philip > > On 19-Oct-07, at 04:59 , Magnus Westerlund wrote: > >> I requested a review of STUNbis from the DNS directorate and here is the >> review done by Peter Koch. Authors please respond to the comments he >> provide. >> >> Cheers >> >> Magnus Westerlund >> >> IETF Transport Area Director & TSVWG Chair >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM/M >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 8 4048287 >> Torshamsgatan 23 | Fax +46 8 7575550 >> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> From: Peter Koch >> Date: October 18, 2007 17:59:00 EDT (CA) >> To: Jari Arkko >> Cc: dns directorate , Magnus Westerlund >> >> Subject: Re: DNS directorate review of draft-ietf-behave-rfc3489bis-11 >> >> >> On Fri, Oct 12, 2007 at 03:59:52PM +0300, Jari Arkko wrote: >> >>> Magnus Westerlund wrote: >> >>>> STUN (draft-ietf-behave-rfc3489bis-11) is using DNS to locate STUN >>>> services for the desired protocol (UDP or TCP). Could you please have >>>> the DNS directorate review what is written on this usage. >> >> I have reviewed this draft for the DNS Directorate and therefore focused >> on Section 9 "DNS Discovery of a Server" and the security considerations. >> There are several issues with the use of SRV RRs that need to be >> addressed. >> >>> 9. DNS Discovery of a Server >>> >>> This section describes an optional procedure for STUN that allows a >>> client to use DNS to determine the IP address and port of a server. >>> A STUN usage must describe if and when this extension is used. To >>> use this procedure, the client must have a domain name and a service >>> name; the usage must also describe how the client obtains these. >> >> NIT: since it's not about the client's name but the servers: "the client >> must _know_ ..."; otherwise easy to mis-read. > > Yes. This would improve readability. fixed. > >> >>> When a client wishes to locate a STUN server in the public Internet >>> that accepts Binding Request/Response transactions, the SRV service >>> name is "stun". STUN usages MAY define additional DNS SRV service >>> names. >> >> This is in violation of RFC 2782. The port name assigned by IANA is >> "nat-stun-port", so this should be the one used in SRV handling. Same for >> the definition of additional service names. > > The use of "stun" for this service was introduced in RFC 3489, and I > believe that > there is already some deployment today. > As I see it, the problem is that IANA assigned a name of "nat-stun-port" > for > the assigned port number for STUN, rather than simply "stun". > So my initial thought is to see if IANA has any objections to changing > the name of this port to "stun". I agree. Changing this to 'nat-stun-port' at this time would break backwards compatibility with rfc3489; something we have been trying to retain, at least for deployed functionality (including this). > > >> >>> The domain name is resolved to a transport address using the SRV >>> procedures specified in [RFC2782]. The DNS SRV service name is the >>> service name provided as input to this procedure. The protocol in >>> the SRV lookup is the transport protocol the client will run STUN >>> over: "udp" for UDP, "tcp" for TCP, and "tls" for TLS-over-TCP. If, >> >> The introduction of "tls" as another string for the RFC 2782 "Proto" >> field >> also violates that RFC, since it's not defined as an IP protocol in the >> "protocol-numbers" registry. > > How do other protocols handle this issue (wanting to run over both TCP > and TLS over TCP)? The only other solutions I am aware of for this, would be to add NAPTR support as a layer on top, or add something akin to STARTTLS to stun, both of which I'd rather avoid. Hopefully there is a simpler alternative you can suggest. > >> >>> The procedures of RFC 2782 are followed to determine the server to >>> contact. RFC 2782 spells out the details of how a set of SRV records >>> are sorted and then tried. However, RFC2782 only states that the >>> client should "try to connect to the (protocol, address, service)" >>> without giving any details on what happens in the event of failure. >> >> I'm not sure I understand this concern. Since RFC 2782's section on >> "Usage rules" says that one should iterate over the sorted (according to >> Priority and Weight) list until a "connection" succeeds, isn't that all >> that's needed? > > This paragraph was added before I came on board as an author. > However, I believe the concern is as follows. RCC 2782 says: > > for each address record found, try to connect to the > (protocol, address, service). > > This doesn't say what to do if the attempt fails. Since there are at least > conceivably a couple of ways this might be handled in STUN, it seems > desirable > to be explicit. Thus the document says: > When following these procedures, if the STUN transaction times out > without receipt of a response, the client SHOULD retry the request to > the next server in the list of servers from the DNS SRV response. > Such a retry is only possible for request/response transmissions, > since indication transactions generate no response or timeout. Right. This trend, of clarifying failure treatment, was something started in RFC 3263 and has carried into most of the DNS behaviors described in other RAI-related protocols. > > >> >>> When following these procedures, if the STUN transaction times out >>> without receipt of a response, the client SHOULD retry the request to >>> the next server in the list of servers from the DNS SRV response. >> >> Well, _ordered_ list as of RFC 2782. > I think that you are suggesting that this be reworded as > "the next server in the order defined by RFC 2782". > This seems good. fixed. > >>> >>> The default port for STUN requests is 3478, for both TCP and UDP. >>> Administrators SHOULD use this port in their SRV records for UDP and >>> TCP, but MAY use others. There is no default port for STUN over TLS, >> >> I'd emphasize here that the administrator _of the STUN server_ is >> encouraged >> to use port 3478 and then, subsequently, to use this port in the DNS, >> not vice versa. I.e., the DNS SRV RR should reflect which port is >> actually >> listened on. > > Yes. Good point. Added a sentence saying this. > > >> >>> however a STUN server SHOULD use a port number for TLS different from >>> 3478 so that the server can determine whether the first message it >>> will receive after the TCP connection is set up, is a STUN message or >>> a TLS message. >>> >>> If no SRV records were found, the client performs an A or AAAA record >>> lookup of the domain name. The result will be a list of IP >> >> The change here is to allow AAAA in addition to A, the original fallback >> mechanism already envisioned in RFC 2782. However, it's time to move >> forward and instead of extending a bad idea to v6 it should be >> terminated and >> no "fallback" given. Especially because this is not a legacy service >> that >> existed before SRV was invented and RFC 3489 already included the SRV >> usage, >> there's no need to address "old" v6 clients agnostic of SRV. Operational >> laziness shouldn't be encouraged. >> At the very least, the fallback MUST be excluded for explicit "stop" SRV >> RRs (those including the "." target). Its not so much about backwards compatibility as domains that simply elect not to deploy SRV. Unfortunately we've seen lots of cases where folks just deploy A records and don't use SRV at all. The fallback makes the client maximally interopreable. >> >>> addresses, each of which can be contacted at the default port using >>> UDP or TCP, independent of the STUN usage. For usages that require >>> TLS, lack of SRV records is equivalent to a failure of the >>> transaction, since the request or indication MUST NOT be sent unless >>> SRV records provided a transport address specifically for TLS. >> >> In the Security Considerations section the usual DNS caveats and threats >> should be mentioned, especially since SRV provides a level of indirection >> that can't be protected by use of TLS (you might end up to securely talk >> to the perfectly authenticated - albeit wrong - server). >> Also, even though the mechanism of obtaining the server's domain name >> is not specified in the draft, I'd suggest to mention the risk of >> hardcoding >> the domain name in the application software because of the chance to >> "loose" a domain name (by accidental expiry, legal action and so on). In fact the text used to describe these standard DNS attacks. However the draft was restructured and broken into this core document and into usages. As the security considerations section discusses, usages actually need to do the analysis to see what attacks apply. For example one stun usage doesn't use the DNS mechanism at all and so the attack doesnt apply. ICE does use it, and the attack you mention is described there. I mentioned that the domain name should not be hard coded. >> >> -Peter >> >> PS: Unrelated to DNS, aren't there privacy concerns worth mentioning >> because of the opportunity to monitor application usage? STUN attacks whereby an attacker can intercept traffic to monitor it, are described as part of the usage. ICE disucsses this attack for example. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Oct 29 11:14:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImWJF-0007Mm-UA; Mon, 29 Oct 2007 11:13:45 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ImWJE-0007Mh-5V for behave-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 11:13:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImWJD-0007MZ-Ry for behave@ietf.org; Mon, 29 Oct 2007 11:13:43 -0400 Received: from hen.cisco.com ([64.102.19.198] helo=av-tac-rtp.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImWJ7-0003zU-CP for behave@ietf.org; Mon, 29 Oct 2007 11:13:43 -0400 X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id l9TFDLs09911; Mon, 29 Oct 2007 11:13:21 -0400 (EDT) Received: from [64.102.159.125] (dhcp-64-102-159-125.cisco.com [64.102.159.125]) by rooster.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id l9TFDc615989; Mon, 29 Oct 2007 11:13:38 -0400 (EDT) Message-ID: <4725F89B.7020509@cisco.com> Date: Mon, 29 Oct 2007 11:13:31 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [BEHAVE] [Fwd: DISCUSS and COMMENT: draft-ietf-behave-nat-icmp] References: <4725A2A1.9050701@ericsson.com> In-Reply-To: <4725A2A1.9050701@ericsson.com> X-Enigmail-Version: 0.95.4 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-rtp.cisco.com id l9TFDLs09911 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Magnus, Lars, Please find my 2=C2=A2 in a couple of comments inline. On 10/29/2007 5:06 AM, Magnus Westerlund said the following: > Behave, >=20 > I think the discuss from Lars below needs WG discussion. I like to here > opinions about this. >=20 > Cheers >=20 > Magnus Westerlund >=20 > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 >=20 > -----------------------------------------------------------------------= - >=20 > Subject: > DISCUSS and COMMENT: draft-ietf-behave-nat-icmp > From: > Lars Eggert > Date: > Sat, 27 Oct 2007 17:46:45 -0400 > To: > iesg@ietf.org >=20 > To: > iesg@ietf.org > CC: > behave-chairs@tools.ietf.org, draft-ietf-behave-nat-icmp@tools.ietf.org >=20 >=20 > Discuss: > Section 4.1., paragraph 4: >> REQ-3: When an ICMP Error packet is received, the NAT device >> SHOULD do the following. >> a) If the IP checksum of the embedded packet fails to validate, dro= p >> the Error packet >=20 > DISCUSS: I disagree. (And I apologize for not catching this during my > earlier review.) The reason that (part of) the packet that caused an > ICMP message to be generated is included is for diagnostic purposes, > so the end hosts can determine what went wrong and determine whether > they need to react in some way. This requirement is about the IP Header Checksum of the embedded packet, and ICMPs should not be generated when the IP Header Checksum fails: For hosts: RFC1122: 3.2 PROTOCOL WALK-THROUGH 3.2.1 Internet Protocol -- IP 3.2.1.2 Checksum: RFC-791 Section 3.1 ... A host MUST verify the IP header checksum on every received datagram and silently discard every datagram that has a bad checksum. For routers: RFC1812: 5.2.2 IP Header Validation ... that the header is meaningful. If the packet fails any of the following tests, it MUST be silently discarded, and the error SHOULD be logged. ... (2) The IP checksum must be correct. Therefore, I don't disagree with this requirement. If the IP Header Checksum is incorrect, and the NAT fixes-up the embedded IP Address, how should it update the checksum? > This can't happen if NATs drop these > packets. Also, the reason why some end system OSs drop ICMP messages > with invalid checksums is to protect against some attacks. NATs, > however, are not firewalls. It is inappropriate for this document to > specify NAT mechanisms that implement a specific security policy. > There is also no IETF standard that recommends that end hosts drop > ICMP packets with payloads that have invalid checksums, which is > another reason why this document should not recommend that NATs do > this. (And, as an aside, the effectiveness of this "security" measure > is questionable, because if I can't spoof the complete packet with a > valid checksum, I'd just include a partial packet in the payload, for > which you can't validate the checksum, but that you must still act > on.) The REQ-3 a) quoted in the discuss refers to the IP Header Checksum of the embedded packet. However this comment seems to be referring to REQ-3 d), i.e.: d) If the embedded packet contains the entire transport segment, and the transport protocol of the embedded packet requires the recipient to validate the transport checksum, and the checksum fails to validate, drop the Error packet. In that case, I think a MAY for REQ-3 d) is likely more appropriate (to leave some room for implementing it if desired), although another option is removing it as a requirement. I agree that the "protection" effectiveness is questionable, but in any case it's a mechanism that I'd think would kick in in very limited cases. I cannot think of a general harmful scenario that would result for dropping those, but maybe something that might not get widely implemented either. There seem to be soem corner case scenarios. E.g.: this requirement may possibly mask a bug in a host or NAT setting bad tcp checksums that trigger the generation of ICMPs before the destination TCP gets to process the transport checksum (e.g., unreachables, time exceeded, that also embed the complete segment), and those ICMPs would not reach the sending host. However, it those packets did reach the destination application, the source would not receive a hint of what the problem is either. Thanks, --Carlos. >=20 > Comment: > Section 240, paragraph 0: >> ICMP Query session timer MUST not expire in less than 60 seconds. W= e >=20 > s/MUST not/MUST NOT/ >=20 > Section 240, paragraph 1: >> RECOMMEND however that the administrator(s) be allowed to configure >=20 > RECOMMEND is not an RFC2119 term. You need to rephrase to say > RECOMMENDED, MUST or REQUIRED. (Or use lowercase here, because REQ-2 > has the correct 2119 phrasing.) >=20 >=20 >=20 >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave --=20 --Carlos Pignataro. Escalation RTP - cisco Systems _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Oct 30 11:47:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImtIk-0003zK-AO; Tue, 30 Oct 2007 11:46:46 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ImtIj-0003zF-PS for behave-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 11:46:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImtIj-0003z7-E5 for behave@ietf.org; Tue, 30 Oct 2007 11:46:45 -0400 Received: from web33306.mail.mud.yahoo.com ([68.142.206.121]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ImtIi-0007os-Pv for behave@ietf.org; Tue, 30 Oct 2007 11:46:45 -0400 Received: (qmail 22345 invoked by uid 60001); 30 Oct 2007 15:46:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=MHidlhIjZt6Zx5g8qz1enOPRpTlKwG8NY3DKg1Uy8+7hOAJBvDn5kMgwP5nhKcRBoMJFx4a3/Casst+zfJBbl7NTnMw5uxKuH+Q+zH8+Wr0WaOK5c6iEZ/vLtpYtjOXq/NqOLrYFbPgVGQrKizL3VjRBtVx8kkaAZdmiCp8KdUU=; X-YMail-OSG: lKdGR54VM1kqrmnlqySCFEmhZFDKxyvOL8DnRNLBAEzT_AQ5V44Iz7FmY647UAk2kMwXDEGwFvR.sZL72MbQBFaonI7UtZh4QgB35Ap4DmhUFSsUIsM- Received: from [69.236.102.97] by web33306.mail.mud.yahoo.com via HTTP; Tue, 30 Oct 2007 08:46:44 PDT Date: Tue, 30 Oct 2007 08:46:44 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [BEHAVE] [Fwd: DISCUSS and COMMENT: draft-ietf-behave-nat-icmp] To: Magnus Westerlund , Behave WG In-Reply-To: <4725A2A1.9050701@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <27869.21908.qm@web33306.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Lars and Magnus, Please see my responses inline. regards, suresh --- Magnus Westerlund wrote: > Behave, > > I think the discuss from Lars below needs WG discussion. I like to here > opinions about this. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > To: iesg@ietf.org > From: Lars Eggert > Date: Sat, 27 Oct 2007 17:46:45 -0400 > CC: behave-chairs@tools.ietf.org, draft-ietf-behave-nat-icmp@tools.ietf.org > Subject: DISCUSS and COMMENT: draft-ietf-behave-nat-icmp > > Discuss: > Section 4.1., paragraph 4: > > REQ-3: When an ICMP Error packet is received, the NAT device > > SHOULD do the following. > > a) If the IP checksum of the embedded packet fails to validate, drop > > the Error packet > > DISCUSS: I disagree. (And I apologize for not catching this during my > earlier review.) The reason that (part of) the packet that caused an > ICMP message to be generated is included is for diagnostic purposes, > so the end hosts can determine what went wrong and determine whether > they need to react in some way. This can't happen if NATs drop these > packets. [suresh] As Carlos responded on this e-mail thread, ICMP error messages should not be generated by endhosts or router when the IP Header Checksum fails. Packets with bad IP header checksum MUST be silently dropped by endhosts and routers. The recommendation here is also to drop an ICMP error message if the embedded IP Header Checksum is BAD. > Also, the reason why some end system OSs drop ICMP messages > with invalid checksums is to protect against some attacks. NATs, > however, are not firewalls. It is inappropriate for this document to > specify NAT mechanisms that implement a specific security policy. > There is also no IETF standard that recommends that end hosts drop > ICMP packets with payloads that have invalid checksums, which is > another reason why this document should not recommend that NATs do > this. [Suresh] I Assume, you are refering to Req-3d here. We had extensive discussion on this in the WG and in the end agreed to make this a SHOULD. Here are some reasons I recall. End-hosts should not be generating IP packets with BAD transport checksum. Further, ICMP error messages are not generated due to BAD transport checksum in the IP packet. So, the likely case where an ICMP error packet contains a BAD embedded transport checksum is when it is spoofed. Also, many new implemenations now check against BAD embedded trasnport checksum in ICMP error messages (when the payload contains requsite bytes to compute the checksum). So, we decided to make this a SHOULD requirement to mitigate malformed ICMP errors from reaching endhosts. > (And, as an aside, the effectiveness of this "security" measure > is questionable, because if I can't spoof the complete packet with a > valid checksum, I'd just include a partial packet in the payload, for > which you can't validate the checksum, but that you must still act > on.) [Suresh] Right, checksum validation merely mitigates end hosts from malformed ICMP Error attacks, doesnt eliminate it. The security consideratiosn section also has a discussion on this. > > Comment: > Section 240, paragraph 0: > > ICMP Query session timer MUST not expire in less than 60 seconds. We > > s/MUST not/MUST NOT/ > [suresh] Will do. > Section 240, paragraph 1: > > RECOMMEND however that the administrator(s) be allowed to configure > > RECOMMEND is not an RFC2119 term. You need to rephrase to say > RECOMMENDED, MUST or REQUIRED. (Or use lowercase here, because REQ-2 > has the correct 2119 phrasing.) > [suresh] OK. I will reword the sentence as follows. Thanks. It is RECOMMENDED however that the administrator(s) be allowed to configure the timer. regards, suresh > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Oct 30 12:36:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imu3S-000479-0B; Tue, 30 Oct 2007 12:35:02 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Imu3Q-00046a-7t for behave-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 12:35:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imu3P-00046S-Ud for behave@ietf.org; Tue, 30 Oct 2007 12:34:59 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imu3K-0002QF-66 for behave@ietf.org; Tue, 30 Oct 2007 12:34:59 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9UGYDof021403; Tue, 30 Oct 2007 18:34:43 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 18:34:27 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 18:34:26 +0200 Received: from [172.21.34.135] (esdhcp034135.research.nokia.com [172.21.34.135]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9UGYP3B020022; Tue, 30 Oct 2007 18:34:25 +0200 In-Reply-To: <4725F89B.7020509@cisco.com> References: <4725A2A1.9050701@ericsson.com> <4725F89B.7020509@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <85C08C04-1D88-440E-8BC9-3908C0B34065@nokia.com> Content-Transfer-Encoding: 7bit From: Lars Eggert Subject: Re: [BEHAVE] [Fwd: DISCUSS and COMMENT: draft-ietf-behave-nat-icmp] Date: Tue, 30 Oct 2007 18:34:24 +0200 To: ext Carlos Pignataro X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 30 Oct 2007 16:34:26.0857 (UTC) FILETIME=[BCA85990:01C81B12] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, you are right that I had been mixing two issues in my DISCUSS,. i.e., what NATs should do when the IP checksum of the embedded packet is incorrect, and what they should do when the transport checksum is incorrect. Let's discuss these separately. On 2007-10-29, at 17:13, ext Carlos Pignataro wrote: >> Discuss: >> Section 4.1., paragraph 4: >>> REQ-3: When an ICMP Error packet is received, the NAT device >>> SHOULD do the following. >>> a) If the IP checksum of the embedded packet fails to >>> validate, drop >>> the Error packet >> >> DISCUSS: I disagree. (And I apologize for not catching this >> during my >> earlier review.) The reason that (part of) the packet that >> caused an >> ICMP message to be generated is included is for diagnostic >> purposes, >> so the end hosts can determine what went wrong and determine >> whether >> they need to react in some way. > > This requirement is about the IP Header Checksum of the embedded > packet, > and ICMPs should not be generated when the IP Header Checksum fails: I agree that ICMPs should not be generated in response to receiving a packet with an invalid checksum. But REQ-3 is about acting on the IP and transport checksums of packets that are embedded in the payload of an ICMP packet. RFCs 1122 and 1812 don't apply to this. > If the IP Header Checksum is incorrect, and the NAT fixes-up the > embedded IP Address, how should it update the checksum? Dropping them is one option. Leave the checksum incorrect but still translating the addresses is another, and one that leaves the end host in the loop. It leaves the end host the choice on what to do, whereas dropping the packet removes that choice. (Not translating the embedded IP addresses is a third option, but I'm not sure how useful that is.) >> This can't happen if NATs drop these >> packets. Also, the reason why some end system OSs drop ICMP >> messages >> with invalid checksums is to protect against some attacks. NATs, >> however, are not firewalls. It is inappropriate for this >> document to >> specify NAT mechanisms that implement a specific security policy. >> There is also no IETF standard that recommends that end hosts drop >> ICMP packets with payloads that have invalid checksums, which is >> another reason why this document should not recommend that NATs do >> this. (And, as an aside, the effectiveness of this "security" >> measure >> is questionable, because if I can't spoof the complete packet >> with a >> valid checksum, I'd just include a partial packet in the >> payload, for >> which you can't validate the checksum, but that you must still act >> on.) > > The REQ-3 a) quoted in the discuss refers to the IP Header Checksum of > the embedded packet. However this comment seems to be referring to > REQ-3 > d), i.e.: > > d) If the embedded packet contains the entire transport segment, > and the transport protocol of the embedded packet requires the > recipient to validate the transport checksum, and the checksum > fails to validate, drop the Error packet. > > In that case, I think a MAY for REQ-3 d) is likely more appropriate > (to > leave some room for implementing it if desired), A MAY is not appropriate. No standards track RFC allows this (MAY) or recommends this (SHOULD/MUST) for end systems. So even a MAY for NATs goes beyond our current recommendations for end systems. > although another option > is removing it as a requirement. This would be my preferred resolution. > I agree that the "protection" > effectiveness is questionable, but in any case it's a mechanism > that I'd > think would kick in in very limited cases. So if you agree that the effectiveness is questionable and it may not kick in very often either, why burden NAT implementations with this functionality? Lars _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Oct 30 12:39:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imu7V-0002uR-N4; Tue, 30 Oct 2007 12:39:13 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Imu7U-0002kz-4K for behave-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 12:39:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imu7T-0002hp-Or for behave@ietf.org; Tue, 30 Oct 2007 12:39:11 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imu7T-0000zG-75 for behave@ietf.org; Tue, 30 Oct 2007 12:39:11 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9UGcosF004227; Tue, 30 Oct 2007 18:39:08 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 18:39:01 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 18:39:01 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 18:39:01 +0200 Received: from [172.21.34.135] (esdhcp034135.research.nokia.com [172.21.34.135]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9UGcx3d023191; Tue, 30 Oct 2007 18:38:59 +0200 In-Reply-To: <27869.21908.qm@web33306.mail.mud.yahoo.com> References: <27869.21908.qm@web33306.mail.mud.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2EBB41E8-1A5C-4334-BC8E-B73293B070A8@nokia.com> Content-Transfer-Encoding: 7bit From: Lars Eggert Subject: Re: [BEHAVE] [Fwd: DISCUSS and COMMENT: draft-ietf-behave-nat-icmp] Date: Tue, 30 Oct 2007 18:38:58 +0200 To: ext Pyda Srisuresh X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 30 Oct 2007 16:39:01.0683 (UTC) FILETIME=[60777830:01C81B13] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 2007-10-30, at 17:46, ext Pyda Srisuresh wrote: > [suresh] As Carlos responded on this e-mail thread, ICMP error > messages should > not be generated by endhosts or router when the IP Header Checksum > fails. > Packets with bad IP header checksum MUST be silently dropped by > endhosts and > routers. The recommendation here is also to drop an ICMP error > message if the > embedded IP Header Checksum is BAD. As I said in my earlier reply to Carlos, the 1122 and 1812 recommendations aren't about IP headers embedded in ICMP payloads. > [Suresh] I Assume, you are refering to Req-3d here. We had > extensive discussion > on this in the WG and in the end agreed to make this a SHOULD. Here > are some > reasons I recall. > > End-hosts should not be generating IP packets with BAD transport > checksum. > Further, ICMP error messages are not generated due to BAD transport > checksum in > the IP packet. So, the likely case where an ICMP error packet > contains a BAD > embedded transport checksum is when it is spoofed. No. The likely case is flaky hardware that introduces bit errors. > Also, many new > implemenations now check against BAD embedded trasnport checksum in > ICMP error > messages (when the payload contains requsite bytes to compute the > checksum). > So, we decided to make this a SHOULD requirement to mitigate > malformed ICMP > errors from reaching endhosts. NATs are not firewalls. It is not their task to protect the end systems from anything. Lars _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Oct 30 13:30:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImuuQ-0001Ec-O1; Tue, 30 Oct 2007 13:29:46 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1ImuuP-0001EW-SP for behave-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 13:29:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImuuP-0001EO-Ir for behave@ietf.org; Tue, 30 Oct 2007 13:29:45 -0400 Received: from hen.cisco.com ([64.102.19.198] helo=av-tac-rtp.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImuuO-0004XZ-EA for behave@ietf.org; Tue, 30 Oct 2007 13:29:45 -0400 X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id l9UHTih09578; Tue, 30 Oct 2007 13:29:44 -0400 (EDT) Received: from [10.83.216.157] (rtp-cpignata-vpn12.cisco.com [10.83.216.157]) by rooster.cisco.com (8.11.7p3+Sun/8.11.7) with SMTP id l9UHU0622806; Tue, 30 Oct 2007 13:30:00 -0400 (EDT) Message-ID: <47276A0B.6040205@cisco.com> Date: Tue, 30 Oct 2007 13:29:47 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Lars Eggert Subject: Re: [BEHAVE] [Fwd: DISCUSS and COMMENT: draft-ietf-behave-nat-icmp] References: <4725A2A1.9050701@ericsson.com> <4725F89B.7020509@cisco.com> <85C08C04-1D88-440E-8BC9-3908C0B34065@nokia.com> In-Reply-To: <85C08C04-1D88-440E-8BC9-3908C0B34065@nokia.com> X-Enigmail-Version: 0.95.4 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 10/30/2007 12:34 PM, Lars Eggert said the following: > Hi, > > you are right that I had been mixing two issues in my DISCUSS,. i.e., > what NATs should do when the IP checksum of the embedded packet is > incorrect, and what they should do when the transport checksum is > incorrect. Let's discuss these separately. > > On 2007-10-29, at 17:13, ext Carlos Pignataro wrote: >>> Discuss: >>> Section 4.1., paragraph 4: >>>> REQ-3: When an ICMP Error packet is received, the NAT device >>>> SHOULD do the following. >>>> a) If the IP checksum of the embedded packet fails to >>>> validate, drop >>>> the Error packet >>> DISCUSS: I disagree. (And I apologize for not catching this >>> during my >>> earlier review.) The reason that (part of) the packet that >>> caused an >>> ICMP message to be generated is included is for diagnostic >>> purposes, >>> so the end hosts can determine what went wrong and determine >>> whether >>> they need to react in some way. >> This requirement is about the IP Header Checksum of the embedded >> packet, >> and ICMPs should not be generated when the IP Header Checksum fails: > > I agree that ICMPs should not be generated in response to receiving a > packet with an invalid checksum. > > But REQ-3 is about acting on the IP and transport checksums of > packets that are embedded in the payload of an ICMP packet. RFCs 1122 > and 1812 don't apply to this. IMHO, the question is: under which legitimate circumstances can an IP datagram with invalid Internet Header Checksum generate an ICMP error, such that it gets embedded in the ICMP? RFC1122 and 1812 do apply in the processing of a packet with invalid checksum, and if they need to be silently dropped, how can they get embedded into ICMPs? So the citations are in the ICMP-eliciting path. The only option (besides bugs) appears to be that the IP Hdr checksum got corrupted after the IP Hdr got embedded on the icmp and it's on its way back, in which case the ICMP checksum would fail and the "corrupted" header won't be processed by the originating host anyway, correct? > >> If the IP Header Checksum is incorrect, and the NAT fixes-up the >> embedded IP Address, how should it update the checksum? > > Dropping them is one option. > > Leave the checksum incorrect but still translating the addresses is > another, and one that leaves the end host in the loop. It leaves the > end host the choice on what to do, whereas dropping the packet > removes that choice. It's not clear to me that there's a lot of meaningful information that the host would want to be in the loop for in these cases (see the previous para). > > (Not translating the embedded IP addresses is a third option, but I'm > not sure how useful that is.) But this one could potentially expose cross-realm addresses. > >>> This can't happen if NATs drop these >>> packets. Also, the reason why some end system OSs drop ICMP >>> messages >>> with invalid checksums is to protect against some attacks. NATs, >>> however, are not firewalls. It is inappropriate for this >>> document to >>> specify NAT mechanisms that implement a specific security policy. >>> There is also no IETF standard that recommends that end hosts drop >>> ICMP packets with payloads that have invalid checksums, which is >>> another reason why this document should not recommend that NATs do >>> this. (And, as an aside, the effectiveness of this "security" >>> measure >>> is questionable, because if I can't spoof the complete packet >>> with a >>> valid checksum, I'd just include a partial packet in the >>> payload, for >>> which you can't validate the checksum, but that you must still act >>> on.) >> The REQ-3 a) quoted in the discuss refers to the IP Header Checksum of >> the embedded packet. However this comment seems to be referring to >> REQ-3 >> d), i.e.: >> >> d) If the embedded packet contains the entire transport segment, >> and the transport protocol of the embedded packet requires the >> recipient to validate the transport checksum, and the checksum >> fails to validate, drop the Error packet. >> >> In that case, I think a MAY for REQ-3 d) is likely more appropriate >> (to >> leave some room for implementing it if desired), > > A MAY is not appropriate. No standards track RFC allows this (MAY) or > recommends this (SHOULD/MUST) for end systems. So even a MAY for NATs > goes beyond our current recommendations for end systems. lowercase "might"? :) See below. > >> although another option >> is removing it as a requirement. > > This would be my preferred resolution. > >> I agree that the "protection" >> effectiveness is questionable, but in any case it's a mechanism >> that I'd >> think would kick in in very limited cases. > > So if you agree that the effectiveness is questionable and it may not > kick in very often either, why burden NAT implementations with this > functionality? Because it appears the WG found consensus around leaving it as something potentially (or under some cases) useful, and it appears to be something that a "strict policy" might want, I think that leaving room for implementing it (while not requiring) is of value. Thanks, --Carlos. > > Lars > -- --Carlos Pignataro. Escalation RTP - cisco Systems _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Oct 31 04:32:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In8ym-00089S-4j; Wed, 31 Oct 2007 04:31:12 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1In8yl-00088r-0n for behave-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 04:31:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In8yk-00087Z-7K for behave@ietf.org; Wed, 31 Oct 2007 04:31:10 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In8yi-00081l-Lr for behave@ietf.org; Wed, 31 Oct 2007 04:31:10 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9V8U4Qt012942; Wed, 31 Oct 2007 10:30:41 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 10:30:35 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 10:30:35 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 10:30:34 +0200 Received: from [172.21.35.97] (esdhcp03597.research.nokia.com [172.21.35.97]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9V8UWbl014388; Wed, 31 Oct 2007 10:30:33 +0200 In-Reply-To: <47276A0B.6040205@cisco.com> References: <4725A2A1.9050701@ericsson.com> <4725F89B.7020509@cisco.com> <85C08C04-1D88-440E-8BC9-3908C0B34065@nokia.com> <47276A0B.6040205@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <7B802A9A-DB56-4EE2-B50B-4E136BB41287@nokia.com> From: Lars Eggert Subject: Re: [BEHAVE] [Fwd: DISCUSS and COMMENT: draft-ietf-behave-nat-icmp] Date: Wed, 31 Oct 2007 10:30:31 +0200 To: ext Carlos Pignataro X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Oct 2007 08:30:34.0453 (UTC) FILETIME=[4E68D050:01C81B98] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 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="===============1539616819==" Errors-To: behave-bounces@ietf.org --===============1539616819== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-36-763866964; protocol="application/pkcs7-signature" --Apple-Mail-36-763866964 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-10-30, at 19:29, ext Carlos Pignataro wrote: > On 10/30/2007 12:34 PM, Lars Eggert said the following: >> I agree that ICMPs should not be generated in response to receiving a >> packet with an invalid checksum. >> >> But REQ-3 is about acting on the IP and transport checksums of >> packets that are embedded in the payload of an ICMP packet. RFCs 1122 >> and 1812 don't apply to this. > > IMHO, the question is: under which legitimate circumstances can an IP > datagram with invalid Internet Header Checksum generate an ICMP error, > such that it gets embedded in the ICMP? RFC1122 and 1812 do apply > in the > processing of a packet with invalid checksum, and if they need to be > silently dropped, how can they get embedded into ICMPs? You assume that an ICMP message that contains an embedded IP packet with an invalid checksum was generated somewhere in response to receiving this IP packet with an invalid header checksum. It is equally possible that the ICMP message was generated based on an IP packet with a valid checksum, but then got corrupted during transmission. > So the citations > are in the ICMP-eliciting path. The only option (besides bugs) appears > to be that the IP Hdr checksum got corrupted after the IP Hdr got > embedded on the icmp and it's on its way back, in which case the ICMP > checksum would fail and the "corrupted" header won't be processed > by the > originating host anyway, correct? The ICMP checksum only covers the ICMP header and not the payload. (Unless I'm seriously misreading RFC792.) >> Leave the checksum incorrect but still translating the addresses is >> another, and one that leaves the end host in the loop. It leaves the >> end host the choice on what to do, whereas dropping the packet >> removes that choice. > > It's not clear to me that there's a lot of meaningful information that > the host would want to be in the loop for in these cases (see the > previous para). It's not obvious to me that hosts wouldn't. Not dropping these packets leaves them the option to choose. >> (Not translating the embedded IP addresses is a third option, but I'm >> not sure how useful that is.) > > But this one could potentially expose cross-realm addresses. Right, that's why it's not useful. Let me try to make my point with a different argument: What would a plain RFC1812 router do, if it was in the path instead of a NAT? A router would simply forward the ICMP packet, irrespective of whether the IP checksum of a packet embedded on an ICMP message was valid or not. A NAT should do exactly the same, in my opinion, i.e., it should forward the packet whenever it can. So if it has a binding that allows it to translate the embedded IP header, it should always do so, even if the embedded checksum is invalid. >>>> The REQ-3 a) quoted in the discuss refers to the IP Header >>>> Checksum of >>> the embedded packet. However this comment seems to be referring to >>> REQ-3 >>> d), i.e.: >>> >>> d) If the embedded packet contains the entire transport segment, >>> and the transport protocol of the embedded packet requires the >>> recipient to validate the transport checksum, and the checksum >>> fails to validate, drop the Error packet. >>> >>> In that case, I think a MAY for REQ-3 d) is likely more appropriate >>> (to leave some room for implementing it if desired), >> >> A MAY is not appropriate. No standards track RFC allows this (MAY) or >> recommends this (SHOULD/MUST) for end systems. So even a MAY for NATs >> goes beyond our current recommendations for end systems. > > lowercase "might"? :) See below. I wouldn't even want to allow that. >>> although another option >>> is removing it as a requirement. >> >> This would be my preferred resolution. >> >>> I agree that the "protection" >>> effectiveness is questionable, but in any case it's a mechanism >>> that I'd >>> think would kick in in very limited cases. >> >> So if you agree that the effectiveness is questionable and it may not >> kick in very often either, why burden NAT implementations with this >> functionality? > > Because it appears the WG found consensus around leaving it as > something > potentially (or under some cases) useful, and it appears to be > something > that a "strict policy" might want, I think that leaving room for > implementing it (while not requiring) is of value. BEHAVE isn't chartered to design security mechanisms ("strict policy".) I'm not saying that that shouldn't be done, but BEHAVE under the current charter isn't the WG to do it. Lars --Apple-Mail-36-763866964 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzEwMzEwODMwMzJaMCMGCSqGSIb3DQEJBDEWBBQnDhfxTpDxNrDE EkemTaIvWTC85TCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAUH1OX8583TthoByJAtl/+nE4f3XIRQe3tHYi17Xv7H4iFR1430Ho OwNjb7Ri5tbIDfPYh0Y7x19iOxkgJ9cIN81P++4IEY1lL5aIxGk4MFjYiFIvBzpJZrPd3+l3Mmzu VpFs9p4BsjvDIEbCTSF0Ecdq8pTSlz3aVvVHrrAdc7ixlpuZL478oCUVf1KtuQ71uRgcfhNAGBQ7 9qjs9LAX/aK4Px/EW4gw8hmlDfeaTKWfGaJ1PZLfWE4h5dA9c9A/yYXkpkTJF4gwsqg88yUdmXfC qxrGSZlmatbqNdYPpcgpd/MMPkeiJDv6OdwCvy5w+3piObJPLP6BfndgOQPZTgAAAAAAAA== --Apple-Mail-36-763866964-- --===============1539616819== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --===============1539616819==-- From behave-bounces@ietf.org Wed Oct 31 09:07:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InDH9-0000it-6F; Wed, 31 Oct 2007 09:06:27 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1InDH7-0000gv-L5 for behave-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 09:06:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InDH1-0000fp-3t for behave@ietf.org; Wed, 31 Oct 2007 09:06:19 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-08.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InDGu-00049U-Pp for behave@ietf.org; Wed, 31 Oct 2007 09:06:15 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-08.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1InDGp-0006Df-1o; Wed, 31 Oct 2007 09:06:07 -0400 In-Reply-To: <200710261053.13990.remi.denis-courmont@nokia.com> References: <8f8143dc0710260038n2fdd7feq7bf50d9d7e8c7f54@mail.gmail.com> <200710261053.13990.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Philip Matthews Subject: Re: [BEHAVE] TURN : How can a client ask a TCP disconnection ? Date: Wed, 31 Oct 2007 09:06:49 -0400 To: =?ISO-8859-1?Q?ext_Ga=EBl_Br=E9ard?= X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 26-Oct-07, at 03:53 , R=E9mi Denis-Courmont wrote: > Le Friday 26 October 2007 10:38:50 ext Ga=EBl Br=E9ard, vous avez = =E9crit : >> One simple question about TURN : >> >> Imagine the case where a TURN client has allocated a TCP address =20 >> (a TCP >> server) on a TURN server. >> Several remote peers have established a connection on this =20 >> allocated port. >> >> And now, the client wants to disconnect one of them (and only one). >> I did not found any request to do that. > > It used to be so that you terminated the TCP connection. Multiple TCP > connections per TURN session was then added, but remains buggy to =20 > this day. > > As far as I understand, the current public draft is way out-of-sync =20= > with where > the WG is heading anyway. > > --=20 > R=E9mi Denis-Courmont Ga=EBl: Thanks for bring this up. Remi is right in that TURN is undergoing major changes right now. =20 There is a design team that talks by conference call twice a week. We were =20 hoping to have a draft out by Oct 1, but that proved too ambitious with all the =20 concerns that people had, and so we are now just trying to get something out before =20= the next meeting. The problem is that people are now starting to look at =20 ICE/STUN/TURN as a general NAT traversal solution, and solutions that work well for =20= SIP are not always general enough. For example, for SIP one can say that in most cases, there is only one remote destination that one exchanges media with, and in the few =20 cases this is not true, it is reasonable to require the client to obtain a second =20 TURN address. However, this may or may not be a reasonable assumption in the =20 general case. So if you could wait just a few more weeks ... - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Oct 31 10:30:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InEZL-0005UI-VI; Wed, 31 Oct 2007 10:29:19 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1InEZL-0005U8-7Y for behave-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 10:29:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InEZK-0005U0-Pb for behave@ietf.org; Wed, 31 Oct 2007 10:29:18 -0400 Received: from web33302.mail.mud.yahoo.com ([68.142.206.117]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1InEZJ-0007RI-Iq for behave@ietf.org; Wed, 31 Oct 2007 10:29:18 -0400 Received: (qmail 53158 invoked by uid 60001); 31 Oct 2007 14:29:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=tSC/31o82hVjutxxsBnf9wciwCSic33OgldiQDLUG9R8U3aGFmaMUheue7DQmoF7vJC8ivn43JPCR8WEpQXouRFQpipZWO0s4VPCFyj1mUK+9p6Atpnx6N1rJh93euXMsOGp8LN0puU7Y4b085xLWsHgA1RML4Zy+tHX1t+dF2I=; X-YMail-OSG: TmFMHa8VM1n6LoItnIVi17BkTvrMtRQg029hsxhJxaIAeiw0Wa3Ud_tsFf9dpMLoupHyrWvTn4HT77KnhGF..KGb.hkJIxKnki0TpIp7Lmb6bZBVQSo- Received: from [69.236.102.97] by web33302.mail.mud.yahoo.com via HTTP; Wed, 31 Oct 2007 07:29:16 PDT Date: Wed, 31 Oct 2007 07:29:16 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [BEHAVE] [Fwd: DISCUSS and COMMENT: draft-ietf-behave-nat-icmp] To: Lars Eggert , ext Carlos Pignataro In-Reply-To: <7B802A9A-DB56-4EE2-B50B-4E136BB41287@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <5966.52888.qm@web33302.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --- Lars Eggert wrote: > On 2007-10-30, at 19:29, ext Carlos Pignataro wrote: > > On 10/30/2007 12:34 PM, Lars Eggert said the following: > >> I agree that ICMPs should not be generated in response to receiving a > >> packet with an invalid checksum. > >> > >> But REQ-3 is about acting on the IP and transport checksums of > >> packets that are embedded in the payload of an ICMP packet. RFCs 1122 > >> and 1812 don't apply to this. > > > > IMHO, the question is: under which legitimate circumstances can an IP > > datagram with invalid Internet Header Checksum generate an ICMP error, > > such that it gets embedded in the ICMP? RFC1122 and 1812 do apply > > in the > > processing of a packet with invalid checksum, and if they need to be > > silently dropped, how can they get embedded into ICMPs? > > You assume that an ICMP message that contains an embedded IP packet > with an invalid checksum was generated somewhere in response to > receiving this IP packet with an invalid header checksum. > > It is equally possible that the ICMP message was generated based on > an IP packet with a valid checksum, but then got corrupted during > transmission. [suresh] We all agree that IP packets with BAD IP header checksum are silently dropped by end-hosts and routers. ICMP errors are not generated by end-hosts or routers in response to IP packets with bad IP header checksums. In that case, how could the embedded IP header checksum have been corrupted? You say, one possibility is corruption during transmission. Corruption of which specific bits in the IP header? It could have been transmission corruption on any part of the IP header - Src/Dest IP addresses, TTL, Length, Checksum etc. We cannot assume that every other part of the IP header may be OK, but checksum alone may have gotten corrupted. In other words, if the IP header checksum is corrupted, the entire IP header is suspect. That is the gist of recommendation for REQ-3a. Unlike a router that does not examine the ICMP error payload, NAT examines the embedded payload for session match and modify IP addresses and fixes checksum before forwarding the IP packet to the intended recipient. In order for a NAT to make the mods, NAT needs to start with a good base. Modifying an IP packet, fully knowing that it's header is suspect, could result in bombarding the wrong end-host with the ICMP error message. It woudl be derelict to not drop suspect IP packets for a device that examines the payload and detects checksum failure. I do believe, the current recommendation of SHOULD as Best Current Practice is the right thing to do. > > > So the citations > > are in the ICMP-eliciting path. The only option (besides bugs) appears > > to be that the IP Hdr checksum got corrupted after the IP Hdr got > > embedded on the icmp and it's on its way back, in which case the ICMP > > checksum would fail and the "corrupted" header won't be processed > > by the > > originating host anyway, correct? > > The ICMP checksum only covers the ICMP header and not the payload. > (Unless I'm seriously misreading RFC792.) [suresh] I do believe, the ICMP checksum covers the entire ICMP message includign the payload. > > >> Leave the checksum incorrect but still translating the addresses is > >> another, and one that leaves the end host in the loop. It leaves the > >> end host the choice on what to do, whereas dropping the packet > >> removes that choice. > > > > It's not clear to me that there's a lot of meaningful information that > > the host would want to be in the loop for in these cases (see the > > previous para). > > It's not obvious to me that hosts wouldn't. Not dropping these > packets leaves them the option to choose. > > >> (Not translating the embedded IP addresses is a third option, but I'm > >> not sure how useful that is.) > > > > But this one could potentially expose cross-realm addresses. > > Right, that's why it's not useful. > > Let me try to make my point with a different argument: What would a > plain RFC1812 router do, if it was in the path instead of a NAT? A > router would simply forward the ICMP packet, irrespective of whether > the IP checksum of a packet embedded on an ICMP message was valid or > not. A NAT should do exactly the same, in my opinion, i.e., it should > forward the packet whenever it can. So if it has a binding that > allows it to translate the embedded IP header, it should always do > so, even if the embedded checksum is invalid. > [suresh] Please see my comment above. NAT does a combination of router and end-host functionality. Unlike a router, it is a requirement for NAT to examine the ICMP error payload in order to determine where to forward the ICMP error packet. If the enbedded IP header is suspect, NAT cannot do its job right. > >>>> The REQ-3 a) quoted in the discuss refers to the IP Header > >>>> Checksum of > >>> the embedded packet. However this comment seems to be referring to > >>> REQ-3 > >>> d), i.e.: > >>> > >>> d) If the embedded packet contains the entire transport segment, > >>> and the transport protocol of the embedded packet requires the > >>> recipient to validate the transport checksum, and the checksum > >>> fails to validate, drop the Error packet. > >>> > >>> In that case, I think a MAY for REQ-3 d) is likely more appropriate > >>> (to leave some room for implementing it if desired), > >> > >> A MAY is not appropriate. No standards track RFC allows this (MAY) or > >> recommends this (SHOULD/MUST) for end systems. So even a MAY for NATs > >> goes beyond our current recommendations for end systems. > > > > lowercase "might"? :) See below. > > I wouldn't even want to allow that. > > >>> although another option > >>> is removing it as a requirement. > >> > >> This would be my preferred resolution. > >> > >>> I agree that the "protection" > >>> effectiveness is questionable, but in any case it's a mechanism > >>> that I'd > >>> think would kick in in very limited cases. > >> > >> So if you agree that the effectiveness is questionable and it may not > >> kick in very often either, why burden NAT implementations with this > >> functionality? > > > > Because it appears the WG found consensus around leaving it as > > something > > potentially (or under some cases) useful, and it appears to be > > something > > that a "strict policy" might want, I think that leaving room for > > implementing it (while not requiring) is of value. > > BEHAVE isn't chartered to design security mechanisms ("strict > policy".) I'm not saying that that shouldn't be done, but BEHAVE > under the current charter isn't the WG to do it. > [suresh] Lars - This is not one of designing a security mechanism within BCP. This is a NAT functionality requirement. NAT needs to examine the IP and transport headers in order to make decisions concerning translation and forwarding. When the IP and transport checksums are BAD, the corresponding IP and transport headers are suspect. When the IP and trasport headers are suspect, NAT does not have a good base to start from. I hope, you agree, it is not advisible to do lookups or translations knowing fully well the base headers are suspect. Hence, the recommendations REQ-3a, 3d. Thanks. regards, suresh > Lars > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Oct 31 11:10:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InFCT-0001kc-T5; Wed, 31 Oct 2007 11:09:45 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1InFCS-0001kR-Fa for behave-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 11:09:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InFCS-0001kE-5N for behave@ietf.org; Wed, 31 Oct 2007 11:09:44 -0400 Received: from hen.cisco.com ([64.102.19.198] helo=av-tac-rtp.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InFCJ-0002Tu-Fl for behave@ietf.org; Wed, 31 Oct 2007 11:09:44 -0400 X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id l9VF9TX11188; Wed, 31 Oct 2007 11:09:29 -0400 (EDT) Received: from [64.102.159.125] (dhcp-64-102-159-125.cisco.com [64.102.159.125]) by rooster.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id l9VF9k607355; Wed, 31 Oct 2007 11:09:47 -0400 (EDT) Message-ID: <47289AA9.3090802@cisco.com> Date: Wed, 31 Oct 2007 11:09:29 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Lars Eggert Subject: Re: [BEHAVE] [Fwd: DISCUSS and COMMENT: draft-ietf-behave-nat-icmp] References: <4725A2A1.9050701@ericsson.com> <4725F89B.7020509@cisco.com> <85C08C04-1D88-440E-8BC9-3908C0B34065@nokia.com> <47276A0B.6040205@cisco.com> <7B802A9A-DB56-4EE2-B50B-4E136BB41287@nokia.com> In-Reply-To: <7B802A9A-DB56-4EE2-B50B-4E136BB41287@nokia.com> X-Enigmail-Version: 0.95.4 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Lars, Thanks for the follow-up, please see some comments inline (separating Req3-a from Req3-d) On 10/31/2007 4:30 AM, Lars Eggert said the following: > On 2007-10-30, at 19:29, ext Carlos Pignataro wrote: >> On 10/30/2007 12:34 PM, Lars Eggert said the following: >>> I agree that ICMPs should not be generated in response to receiving a >>> packet with an invalid checksum. >>> >>> But REQ-3 is about acting on the IP and transport checksums of >>> packets that are embedded in the payload of an ICMP packet. RFCs 1122 >>> and 1812 don't apply to this. >> IMHO, the question is: under which legitimate circumstances can an IP >> datagram with invalid Internet Header Checksum generate an ICMP error, >> such that it gets embedded in the ICMP? RFC1122 and 1812 do apply >> in the >> processing of a packet with invalid checksum, and if they need to be >> silently dropped, how can they get embedded into ICMPs? > > You assume that an ICMP message that contains an embedded IP packet > with an invalid checksum was generated somewhere in response to > receiving this IP packet with an invalid header checksum. > > It is equally possible that the ICMP message was generated based on > an IP packet with a valid checksum, but then got corrupted during > transmission. Yes, as noted below. > >> So the citations >> are in the ICMP-eliciting path. The only option (besides bugs) appears >> to be that the IP Hdr checksum got corrupted after the IP Hdr got >> embedded on the icmp and it's on its way back, in which case the ICMP >> checksum would fail and the "corrupted" header won't be processed >> by the >> originating host anyway, correct? > > The ICMP checksum only covers the ICMP header and not the payload. > (Unless I'm seriously misreading RFC792.) No, the ICMP checksum covers the complete ICMP message starting from the ICMP Type. It does not include a pseudo-header (unlike ICMPv6). For ICMP errors, the checksum includes the embedded packet. As such, the host receiving the ICMP would not get to processing the "corrupted" header. > >>> Leave the checksum incorrect but still translating the addresses is >>> another, and one that leaves the end host in the loop. It leaves the >>> end host the choice on what to do, whereas dropping the packet >>> removes that choice. >> It's not clear to me that there's a lot of meaningful information that >> the host would want to be in the loop for in these cases (see the >> previous para). > > It's not obvious to me that hosts wouldn't. Not dropping these > packets leaves them the option to choose. It is not clear to me under which conditions it would, and that the host would actually get to processing the embedded info. > >>> (Not translating the embedded IP addresses is a third option, but I'm >>> not sure how useful that is.) >> But this one could potentially expose cross-realm addresses. > > Right, that's why it's not useful. > > Let me try to make my point with a different argument: What would a > plain RFC1812 router do, if it was in the path instead of a NAT? A > router would simply forward the ICMP packet, irrespective of whether > the IP checksum of a packet embedded on an ICMP message was valid or > not. A NAT should do exactly the same, in my opinion, i.e., it should > forward the packet whenever it can. So if it has a binding that > allows it to translate the embedded IP header, it should always do > so, even if the embedded checksum is invalid. I don't think that this comparison is valid, because an RFC1812 router does not examine and modify the ICMP payload to perform its function (and as was noted on this list, from the outside network's perspective a NAT is more host-like). However, one additional viewpoint, if the embedded IP Header checksum is invalid, and a binding is found, do you think the NAT should trust and act upon that binding (given that the embedded IP addresses, IP protocol numbers can be corrupt)? Do you think it should recalculate a correct checksum? IMHO, a SHOULD in Req3-a is useful. > >>>>> The REQ-3 a) quoted in the discuss refers to the IP Header >>>>> Checksum of >>>> the embedded packet. However this comment seems to be referring to >>>> REQ-3 >>>> d), i.e.: >>>> >>>> d) If the embedded packet contains the entire transport segment, >>>> and the transport protocol of the embedded packet requires the >>>> recipient to validate the transport checksum, and the checksum >>>> fails to validate, drop the Error packet. >>>> >>>> In that case, I think a MAY for REQ-3 d) is likely more appropriate >>>> (to leave some room for implementing it if desired), >>> A MAY is not appropriate. No standards track RFC allows this (MAY) or >>> recommends this (SHOULD/MUST) for end systems. So even a MAY for NATs >>> goes beyond our current recommendations for end systems. >> lowercase "might"? :) See below. > > I wouldn't even want to allow that. > >>>> although another option >>>> is removing it as a requirement. >>> This would be my preferred resolution. >>> >>>> I agree that the "protection" >>>> effectiveness is questionable, but in any case it's a mechanism >>>> that I'd >>>> think would kick in in very limited cases. >>> So if you agree that the effectiveness is questionable and it may not >>> kick in very often either, why burden NAT implementations with this >>> functionality? >> Because it appears the WG found consensus around leaving it as >> something >> potentially (or under some cases) useful, and it appears to be >> something >> that a "strict policy" might want, I think that leaving room for >> implementing it (while not requiring) is of value. > > BEHAVE isn't chartered to design security mechanisms ("strict > policy".) I'm not saying that that shouldn't be done, but BEHAVE > under the current charter isn't the WG to do it. I was thinking in terms of "reliability" rather than "security". If the embedded L4 checksum is incorrect, the L4 ports or pseudo-headers may be incorrect, resulting in a mis-binding. I'd think that the NAT could not reliably perform its function (or could mis-associate). OTOH, I agree that there may be cases in which a host may want to see these. IMHO, the text of Req3-d is useful, and it should be a recommendation; the level of recommendation IMHO could be either MAY or SHOULD (though SHOULD may be a bit too strong here). Thanks, --Carlos. > > Lars > -- --Carlos Pignataro. Escalation RTP - cisco Systems _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave