From behave-bounces@ietf.org Thu Jan 03 02:49:20 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAKpG-0000Xt-6Y; Thu, 03 Jan 2008 02:49:14 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JAKpF-0000Xn-2p for behave-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 02:49:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAKpE-0000Xf-N6 for behave@ietf.org; Thu, 03 Jan 2008 02:49:12 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAKpE-0008OS-AQ for behave@ietf.org; Thu, 03 Jan 2008 02:49:12 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m037nNqs019765; Thu, 3 Jan 2008 01:49:52 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Jan 2008 09:49:06 +0200 Received: from esdhcp041123.research.nokia.com ([172.21.41.123]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Jan 2008 09:49:06 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header Date: Thu, 3 Jan 2008 09:49:41 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> In-Reply-To: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200801030949.41979.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 03 Jan 2008 07:49:06.0515 (UTC) FILETIME=[1DEB9A30:01C84DDD] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ext Philip Matthews 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 Saturday 22 December 2007 00:15:59 ext Philip Matthews, vous avez =E9cri= t=A0: > The thread on exceeding the MTU size has raised another issue about > TURN: what bits (if any) in the IP header should be preserved across > a TURN relay? > > My proposal is: > > A TURN server MUST preserve the Don't Fragment (DF) and TOS > (=3D ECN and DiffServ) bits in the IP header when relaying IPv4 =20 > packets.=20 I don't know what ECN will do for UDP, and I suppose that would not work fo= r=20 TCP (since it works in pair with CWR). As with TOS, your proposal makes sense to me. In fact, I think there is an = RFC=20 on TOS handling through tunnels. Unfortunately, from an API perspective, th= at=20 might be challenging enough that I am willing to bet at least some TURN=20 server implementations will ignore the requirement. Namely, there is no=20 standard for setting TOS per outgoing IPv4 packets (usually, it can only be= =20 set per socket). Perhaps RFC3542 would need to be "backported" to IPv4. By the way, does anyone know if some NATs screw up with TOS? =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 Jan 04 17:17:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAuqd-00052o-QA; Fri, 04 Jan 2008 17:17:03 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JAuqc-00052i-Px for behave-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 17:17:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAuqc-00052Y-FI for behave@ietf.org; Fri, 04 Jan 2008 17:17:02 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-01.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAuqc-0004T8-4S for behave@ietf.org; Fri, 04 Jan 2008 17:17:02 -0500 Received: from adsl-068-209-246-231.sip.mia.bellsouth.net ([68.209.246.231] helo=[192.168.1.90]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JAuqb-0000pg-0u; Fri, 04 Jan 2008 17:17:01 -0500 In-Reply-To: <47685AF4.9030909@cisco.com> References: <4759D19B.50005@cisco.com> <4760B1A0.6080807@cisco.com> <9B05C6FD-FF8A-4472-966E-D13C8573A9BF@magma.ca> <5D6A5A89-18B3-49A3-B852-EF0982730E35@magma.ca> <47620CD5.3010304@cisco.com> <4ECA60E2-558A-4EA8-8D08-53DCFE34C661@cisco.com> <30C5AFE6-C9FC-40FE-8A74-80B568FBD554@magma.ca> <1C97A587-D403-48D0-B086-584F7975FC31@cisco.com> <3E8D0268-A6CF-460B-827C-7358367FC961@magma.ca> <47685AF4.9030909@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1C6AF3B7-BB61-45B1-A2CA-C02EAFFB5B66@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages Date: Fri, 4 Jan 2008 17:17:24 -0500 To: Jonathan Rosenberg , Derek MacDonald X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - adsl-068-209-246-231.sip.mia.bellsouth.net ([192.168.1.90]) [68.209.246.231] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Rohan Mahy , 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 During the conference call on Dec 20, we agreed to remove the TURN framing header before TURN control messages. To allow the maximum number of channels, I would like to propose that TURN control messages be identified as having the leading two bits be "00", as is typically done with STUN messages. This leaves the other combination of bits for channel numbers. That is, if the first two bits are: 00 - TURN control message 01 - TURN data packet 10 - TURN data packet 11 - TURN data packet This means that channel numbers would run from 0x4000 to 0xFFFF, with 0xFFFF being a reserved channel number. This gives 49151 different channels. Comments? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 04 19:34:24 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAwzX-0001In-5h; Fri, 04 Jan 2008 19:34:23 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JAwzV-0001Ie-Io for behave-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 19:34:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAwzV-0001IW-9E for behave@ietf.org; Fri, 04 Jan 2008 19:34:21 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAwzU-0000tc-Ul for behave@ietf.org; Fri, 04 Jan 2008 19:34:21 -0500 Received: from adsl-068-209-246-231.sip.mia.bellsouth.net ([68.209.246.231] helo=[192.168.1.90]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JAwzU-0001vX-0o; Fri, 04 Jan 2008 19:34:20 -0500 Mime-Version: 1.0 (Apple Message framework v753) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Behave WG , Jonathan Rosenberg , Rohan Mahy From: Philip Matthews Date: Fri, 4 Jan 2008 19:34:47 -0500 X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - adsl-068-209-246-231.sip.mia.bellsouth.net ([192.168.1.90]) [68.209.246.231] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Subject: [BEHAVE] TURN Issue: Interaction between ChannelBind and permissions 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 One small point with EKR's proposed channel allocation mechanism is the interaction with permissions. Consider the following message flow Client TURN Server Peer1 Peer2 | | | | | | | | | | | | |(1) Allocate | | | |--------------->| | | | | | | | | | | |(2) AllocOK | | | |<---------------| | | | | | | | | | | | | | | |(3) ChannelBind(0x4000) | | |--------------->| | | | | | | |(4) BindOK | | | |<---------------| | | | | | | | |(5) UDP Packet | | | |<---------------| | | | | | | |(6) UDP Packet | | | |<--------------------------------| | | | | | | | | At step (3), the client allocated channel 0x4000 to Peer1. At step (5), a packet arrives from Peer1 before the client has sent any data to Peer1 or otherwise opened a permission. Is that packet dropped? At step (6), a packet arrives from Peer2. Is that packet dropped? I have the following proposal: Binding a channel to a remote address and port opens up a permission for that address. Thus packet (5) is accepted, and packet (6) is accepted provided that it comes from the same address as packet (5). Comments? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 04 22:02:23 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAzIj-0007Au-Ld; Fri, 04 Jan 2008 22:02:21 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JAzIj-0007Ao-3t for behave-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 22:02:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAzIi-0007Ag-QI for behave@ietf.org; Fri, 04 Jan 2008 22:02:20 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-09.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAzIi-0003dp-FF for behave@ietf.org; Fri, 04 Jan 2008 22:02:20 -0500 Received: from adsl-068-209-246-231.sip.mia.bellsouth.net ([68.209.246.231] helo=[192.168.1.90]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JAzIf-0007GU-1E; Fri, 04 Jan 2008 22:02:17 -0500 Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Fri, 4 Jan 2008 22:02:44 -0500 To: Behave WG X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - adsl-068-209-246-231.sip.mia.bellsouth.net ([192.168.1.90]) [68.209.246.231] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Rohan Mahy Subject: [BEHAVE] TURN Issue: How important are channels anyway? 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 whole point of the TURN channel mechanism is to provide an alternate encapsulation mechanism, one that has about 32 bytes less overhead (over IPv4). Is this reduction in overhead important? Channels certainly add some complexity to TURN: the Framing Header and the issues around its Length field and how-to-demux, the ChannelBind method, and the yet-to-be-defined mechanism for deallocating channels. About half of the issues we have been discussing since Vancouver have been about the channel mechanism. There are a lot of other things out there today that add overhead to a packet. Moving to IPv6, for example. Various tunneling technologies inside the network, for another (MPLS, VPNs, IP tunnels, ...). So perhaps an extra 32 bytes is not a killer. Or perhaps the 32 bytes should be removed using other techniques: compression techniques between a handset and its base station, for example. Moreover, with the decision that TURN control messages are NOT framed, channels are now cleanly separable from the rest of TURN. Channels are very much an extra mechanism. So it would be easy to add channels as an extension to TURN. So the question is: Is removing these 32 bytes important enough to add channels to the base TURN specification (with the consequent delays to the specification that this will inevitably add), or should they be defined as an extension to TURN? Comments? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Jan 05 08:37:05 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JB9Cv-0007hF-3z; Sat, 05 Jan 2008 08:37:01 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JB9Cu-0007SP-4C for behave-confirm+ok@megatron.ietf.org; Sat, 05 Jan 2008 08:37:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JB9Ct-0007J2-Gv for behave@ietf.org; Sat, 05 Jan 2008 08:36:59 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-07.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JB9Cr-00031k-Be for behave@ietf.org; Sat, 05 Jan 2008 08:36:59 -0500 Received: from adsl-068-209-246-231.sip.mia.bellsouth.net ([68.209.246.231] helo=[192.168.1.90]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JB9Cn-00022I-1M; Sat, 05 Jan 2008 08:36:53 -0500 In-Reply-To: <4759A13C.8080106@cisco.com> References: <4759A13C.8080106@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #3: Address v. Address and Port Restricted Date: Sat, 5 Jan 2008 08:37:24 -0500 To: Behave WG X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - adsl-068-209-246-231.sip.mia.bellsouth.net ([192.168.1.90]) [68.209.246.231] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Rohan Mahy 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 am starting to think that the permission policy for TURN should be something that is left up to the administrator of the TURN server. That is, some administrators may configure their TURN servers to be address-restricted, while other may configure theirs to be either address-and-port-restricted or endpoint-independent. The original idea was that, by mandating that TURN must use an address-restricted permission policy, corporate IT managers would view TURN as "safe" and thus allow TURN through their corporate firewalls. But just because we write "MUST be address-restricted" in the TURN spec, this doesn't mean that a TURN implementor has to follow this policy. A TURN implementor could easily implement another policy; there are lots of examples of "MUSTs" in specifications being ignored. This means that corporate IT managers that want to be safe must configure their firewalls to allow TURN only to designated TURN servers. This is not really a problem, since most clients will need credentials that allow them to use a specific TURN server anyway. So I suggest that we not mandate a specific permission policy in the TURN spec, but simply list what we think are the three reasonable policies (endpoint-independent, address-restricted, and address-and- port-restricted) and list the consequences of each choice. Comments? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 07 02:31:24 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBmS9-0002kF-Do; Mon, 07 Jan 2008 02:31:21 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JBmS7-0002iZ-Vj for behave-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 02:31:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBmS7-0002iR-LY for behave@ietf.org; Mon, 07 Jan 2008 02:31:19 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBmS5-0008QF-9N for behave@ietf.org; Mon, 07 Jan 2008 02:31:19 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m077UU5u002547; Mon, 7 Jan 2008 09:30:53 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 09:30:49 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 09:30:48 +0200 Received: from esdhcp041133.research.nokia.com ([172.21.41.133]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 09:30:48 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages Date: Mon, 7 Jan 2008 09:31:31 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <4759D19B.50005@cisco.com> <47685AF4.9030909@cisco.com> <1C6AF3B7-BB61-45B1-A2CA-C02EAFFB5B66@magma.ca> In-Reply-To: <1C6AF3B7-BB61-45B1-A2CA-C02EAFFB5B66@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200801070931.31299.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 07 Jan 2008 07:30:48.0985 (UTC) FILETIME=[3964D090:01C850FF] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Rohan Mahy , ext Philip Matthews 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 Saturday 05 January 2008 00:17:24 ext Philip Matthews, vous avez =E9crit= =A0: > That is, if the first two bits are: > 00 - TURN control message > 01 - TURN data packet > 10 - TURN data packet > 11 - TURN data packet > > This means that channel numbers would run from 0x4000 to 0xFFFF, with > 0xFFFF being a reserved channel number. This gives 49151 different > channels. As was pointed out in the telco, I think the difference between 0x7fff and= =20 0xbfff is not significant here, as these quantities are of the same order o= f=20 magnitude. On the other hand, testing two bits ((buf[0] >> 6) =3D=3D 0) ins= tead=20 of just one ((buf[0] >> 7) =3D=3D 0) is also totally insignificant a change. As such, I would like to stay neutral on this question :) =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 07 02:34:42 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBmVO-0000MN-1t; Mon, 07 Jan 2008 02:34:42 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JBmVM-0000MI-Hn for behave-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 02:34:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBmVM-0000MA-7u for behave@ietf.org; Mon, 07 Jan 2008 02:34:40 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBmVL-0008Tc-PL for behave@ietf.org; Mon, 07 Jan 2008 02:34:40 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m077YO7M015744 for ; Mon, 7 Jan 2008 09:34:38 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 09:34:33 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 09:34:33 +0200 Received: from esdhcp041133.research.nokia.com ([172.21.41.133]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 09:34:33 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] TURN Issue: Interaction between ChannelBind and permissions Date: Mon, 7 Jan 2008 09:35:16 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200801070935.16185.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 07 Jan 2008 07:34:33.0594 (UTC) FILETIME=[BF456DA0:01C850FF] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Saturday 05 January 2008 02:34:47 ext Philip Matthews, vous avez =E9crit= =A0: > I have the following proposal: > Binding a channel to a remote address and port opens up a > permission for that address. > Thus packet (5) is accepted, and packet (6) is accepted provided that > it comes from the same address as packet (5). > > Comments? I am not sure what you are asking. I surely agree that binding a channel=20 should automatically add the relevant permission. I am mixed as to whether the permission should be toward the address, or=20 toward the address and port combination. But I thought we had rough consens= us=20 to go for address-only permissions. What I forgot is, how is a packet that= =20 matches a permission but does not match any channel framed by the TURN serv= er=20 to the TURN client? =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 07 02:41:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBmbm-00057j-GZ; Mon, 07 Jan 2008 02:41:18 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JBmbY-0004Mg-7t for behave-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 02:41:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBmbX-0004Hd-Kq for behave@ietf.org; Mon, 07 Jan 2008 02:41:03 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBmbX-00082H-96 for behave@ietf.org; Mon, 07 Jan 2008 02:41:03 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m077eBTv005974 for ; Mon, 7 Jan 2008 01:41:47 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 09:41:00 +0200 Received: from esdhcp041133.research.nokia.com ([172.21.41.133]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 09:40:59 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] TURN Issue: How important are channels anyway? Date: Mon, 7 Jan 2008 09:41:43 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200801070941.43082.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 07 Jan 2008 07:40:59.0970 (UTC) FILETIME=[A591BA20:01C85100] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Saturday 05 January 2008 05:02:44 ext Philip Matthews, vous avez =E9crit= =A0: > The whole point of the TURN channel mechanism is to provide an > alternate encapsulation mechanism, one that has about 32 bytes less > overhead (over IPv4). Is this reduction in overhead important? > > Channels certainly add some complexity to TURN: the Framing Header > and the issues around its Length field and how-to-demux, the > ChannelBind method, and the yet-to-be-defined mechanism for > deallocating channels. About half of the issues we have been > discussing since Vancouver have been about the channel mechanism. On the other hand, fixed size overhead simplifies lots of things. For=20 instance, programmers can use scatter-gather buffer arrays on the receive=20 path, which help avoid extra memory-copying. It also avoids the need for ev= en=20 more intricate demultiplexing (remember how older TURN spec used Send and=20 Data indication...). > There are a lot of other things out there today that add overhead to > a packet. Moving to IPv6, for example. Various tunneling > technologies inside the network, for another (MPLS, VPNs, IP > tunnels, ...). So perhaps an extra 32 bytes is not a killer. Or > perhaps the 32 bytes should be removed using other techniques: > compression techniques between a handset and its base station, for > example. I would rather add 32 bits *always* than add lots bytes of sometimes =3D> pseudo-random looking failures. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 07 12:04:17 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBvOY-0004fe-Jm; Mon, 07 Jan 2008 12:04:14 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JBvOX-0004fR-C4 for behave-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 12:04:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBvOX-0004fH-1A for behave@ietf.org; Mon, 07 Jan 2008 12:04:13 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBvOW-0004JY-Gl for behave@ietf.org; Mon, 07 Jan 2008 12:04:12 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m07H3oF6001209; Mon, 7 Jan 2008 19:04:09 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 19:04:05 +0200 Received: from [192.168.255.2] ([10.162.252.187]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 19:04:05 +0200 Message-Id: <6C4E6148-7EDA-4A44-AED2-CFE02B06A341@nokia.com> From: Lars Eggert To: =?ISO-8859-1?Q?ext_R=E9mi_Denis-Courmont?= In-Reply-To: <200801030949.41979.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header Date: Mon, 7 Jan 2008 19:04:04 +0200 References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <200801030949.41979.remi.denis-courmont@nokia.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 07 Jan 2008 17:04:05.0565 (UTC) FILETIME=[4F5A66D0:01C8514F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: behave@ietf.org, ext Philip Matthews 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 2008-1-3, at 9:49, ext R=E9mi Denis-Courmont wrote: > I don't know what ECN will do for UDP, and I suppose that would not =20= > work for > TCP (since it works in pair with CWR). ECN is orthogonal to what transport is used. All an ECN mark is is a =20 signal from a router on the path that says "I almost dropped this =20 packet." Various transports are free to define various appropriate responses to =20= that signal. TCP decided to treat the ECN signal as if there had been =20= a loss, but that is only one possibility. For example, a UDP sender =20 that was using TFRC to compute a safe rate might decide to reduce its =20= send rate when an ECN mark is received. Or a CBR UDP sender might =20 decide to stop transmission after receiving ECN marks at a certain =20 rate, in order to take load off the network a bit quicker when there =20 is congestion. So ECN marks do need to be preserved, in order to let any intended =20 response mechanism kick in. (Also see draft-briscoe-tsvwg-ecn-tunnel on ECN interactions with =20 tunneling.) Lars= _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 08 00:53:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC7P7-000751-SP; Tue, 08 Jan 2008 00:53:37 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JC7P6-0006v1-VO for behave-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 00:53:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC7P6-0006tB-KK for behave@ietf.org; Tue, 08 Jan 2008 00:53:36 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JC7P5-0000Bb-1g for behave@ietf.org; Tue, 08 Jan 2008 00:53:36 -0500 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id m085rXl5011508; Mon, 7 Jan 2008 22:53:33 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Mon, 7 Jan 2008 22:53:33 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] TURN Issue: How important are channels anyway? Date: Mon, 7 Jan 2008 22:53:32 -0700 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C6B4ADF1@srvxchg3.cablelabs.com> In-Reply-To: <200801070941.43082.remi.denis-courmont@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] TURN Issue: How important are channels anyway? Thread-Index: AchRALIO3JOS2l1GTg65cviQmoFJWwAuZ4Gw References: <200801070941.43082.remi.denis-courmont@nokia.com> From: "Kevin Johns" To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 I tend to agree that while channel numbers complicate TURN, they do = provide simplification in other areas. In addition to Remi's points, = they also make network resource allocation a bit easier since you don't = have to figure out which flow has the single active destination vs. all = the others which don't and thus require additional overhead. Kevin=20 -----Original Message----- From: R=E9mi Denis-Courmont [mailto:remi.denis-courmont@nokia.com]=20 Sent: Monday, January 07, 2008 12:42 AM To: behave@ietf.org Subject: Re: [BEHAVE] TURN Issue: How important are channels anyway? Le Saturday 05 January 2008 05:02:44 ext Philip Matthews, vous avez = =E9crit=A0: > The whole point of the TURN channel mechanism is to provide an=20 > alternate encapsulation mechanism, one that has about 32 bytes less=20 > overhead (over IPv4). Is this reduction in overhead important? > > Channels certainly add some complexity to TURN: the Framing Header and = > the issues around its Length field and how-to-demux, the ChannelBind=20 > method, and the yet-to-be-defined mechanism for deallocating channels. = > About half of the issues we have been discussing since Vancouver have=20 > been about the channel mechanism. On the other hand, fixed size overhead simplifies lots of things. For = instance, programmers can use scatter-gather buffer arrays on the = receive path, which help avoid extra memory-copying. It also avoids the = need for even more intricate demultiplexing (remember how older TURN = spec used Send and Data indication...). > There are a lot of other things out there today that add overhead to a = > packet. Moving to IPv6, for example. Various tunneling technologies=20 > inside the network, for another (MPLS, VPNs, IP tunnels, ...). So=20 > perhaps an extra 32 bytes is not a killer. Or perhaps the 32 bytes=20 > should be removed using other techniques: > compression techniques between a handset and its base station, for=20 > example. I would rather add 32 bits *always* than add lots bytes of sometimes = =3D> pseudo-random looking failures. -- R=E9mi Denis-Courmont _______________________________________________ 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 Jan 08 03:24:24 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC9ki-0001oO-EL; Tue, 08 Jan 2008 03:24:04 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JC9kh-0001oG-J9 for behave-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 03:24:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC9kh-0001nZ-9B for behave@ietf.org; Tue, 08 Jan 2008 03:24:03 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-05.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JC9kf-0002E9-52 for behave@ietf.org; Tue, 08 Jan 2008 03:24:03 -0500 Received: from adsl-068-209-246-231.sip.mia.bellsouth.net ([68.209.246.231] helo=[192.168.1.90]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JC9jx-000534-13; Tue, 08 Jan 2008 03:23:17 -0500 In-Reply-To: <200801070931.31299.remi.denis-courmont@nokia.com> References: <4759D19B.50005@cisco.com> <47685AF4.9030909@cisco.com> <1C6AF3B7-BB61-45B1-A2CA-C02EAFFB5B66@magma.ca> <200801070931.31299.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <5B1BB386-BE8C-4C0D-9DBB-777BB37926F8@magma.ca> Content-Transfer-Encoding: quoted-printable From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages Date: Tue, 8 Jan 2008 03:24:33 -0500 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - adsl-068-209-246-231.sip.mia.bellsouth.net ([192.168.1.90]) [68.209.246.231] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: behave@ietf.org, Rohan Mahy 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 Some of the motivation for this proposal comes from the fact that =20 testing that the first two bits are 00 is something that STUN already =20= does. - Philip On 7-Jan-08, at 02:31 , R=E9mi Denis-Courmont wrote: > Le Saturday 05 January 2008 00:17:24 ext Philip Matthews, vous avez =20= > =E9crit : >> That is, if the first two bits are: >> 00 - TURN control message >> 01 - TURN data packet >> 10 - TURN data packet >> 11 - TURN data packet >> >> This means that channel numbers would run from 0x4000 to 0xFFFF, with >> 0xFFFF being a reserved channel number. This gives 49151 different >> channels. > > As was pointed out in the telco, I think the difference between =20 > 0x7fff and > 0xbfff is not significant here, as these quantities are of the same =20= > order of > magnitude. On the other hand, testing two bits ((buf[0] >> 6) =3D=3D = 0) =20 > instead > of just one ((buf[0] >> 7) =3D=3D 0) is also totally insignificant a =20= > change. > > As such, I would like to stay neutral on this question :) > > --=20 > R=E9mi Denis-Courmont > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 08 03:56:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCAGA-0007qW-CH; Tue, 08 Jan 2008 03:56:34 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JCAG9-0007pv-OA for behave-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 03:56:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCAG9-0007pn-Dk for behave@ietf.org; Tue, 08 Jan 2008 03:56:33 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-01.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCAG9-0004RN-2r for behave@ietf.org; Tue, 08 Jan 2008 03:56:33 -0500 Received: from adsl-068-209-246-231.sip.mia.bellsouth.net ([68.209.246.231] helo=[192.168.1.90]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JCAG8-00085d-0J; Tue, 08 Jan 2008 03:56:32 -0500 In-Reply-To: <200801070941.43082.remi.denis-courmont@nokia.com> References: <200801070941.43082.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <1994E9F1-B90C-4D5C-AC56-82416C4DEB3A@magma.ca> Content-Transfer-Encoding: quoted-printable From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue: How important are channels anyway? Date: Tue, 8 Jan 2008 03:57:06 -0500 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - adsl-068-209-246-231.sip.mia.bellsouth.net ([192.168.1.90]) [68.209.246.231] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 7-Jan-08, at 02:41 , R=E9mi Denis-Courmont wrote: > > On the other hand, fixed size overhead simplifies lots of things. For > instance, programmers can use scatter-gather buffer arrays on the =20 > receive > path, which help avoid extra memory-copying. It also avoids the =20 > need for even > more intricate demultiplexing (remember how older TURN spec used =20 > Send and > Data indication...). In general, always using Send/Data indications also gives a fixed-=20 size overhead: STUN header 20 bytes PEER-ADDRESS attribute 12 bytes (for IPv4) DATA attribute 4 bytes + size of application data + =20= 0-3 bytes of padding However, it is true that TURN currently allows clients and servers to =20= add extra attributes to these indications if they wish, nor does TURN =20= currently specify the order of the PEER-ADDRESS vs DATA attribute. - Philip =20 =20= _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 08 04:06:14 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCAPV-0005tD-DY; Tue, 08 Jan 2008 04:06:13 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JCAPT-0005sz-Ks for behave-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 04:06:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCAPS-0005sr-NL for behave@ietf.org; Tue, 08 Jan 2008 04:06:10 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-06.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCAPS-0004kt-9E for behave@ietf.org; Tue, 08 Jan 2008 04:06:10 -0500 Received: from adsl-068-209-246-231.sip.mia.bellsouth.net ([68.209.246.231] helo=[192.168.1.90]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JCAPR-0000Zw-2M; Tue, 08 Jan 2008 04:06:10 -0500 In-Reply-To: <200801070935.16185.remi.denis-courmont@nokia.com> References: <200801070935.16185.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <8FD6883C-AEF8-4ABA-AD47-3DDFB76022D3@magma.ca> Content-Transfer-Encoding: quoted-printable From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue: Interaction between ChannelBind and permissions Date: Tue, 8 Jan 2008 04:06:44 -0500 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - adsl-068-209-246-231.sip.mia.bellsouth.net ([192.168.1.90]) [68.209.246.231] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 7-Jan-08, at 02:35 , R=E9mi Denis-Courmont wrote: > Le Saturday 05 January 2008 02:34:47 ext Philip Matthews, vous avez =20= > =E9crit : >> I have the following proposal: >> Binding a channel to a remote address and port opens up a >> permission for that address. > >> Thus packet (5) is accepted, and packet (6) is accepted provided that >> it comes from the same address as packet (5). >> >> Comments? > > I am not sure what you are asking. I surely agree that binding a =20 > channel > should automatically add the relevant permission. > > I am mixed as to whether the permission should be toward the =20 > address, or > toward the address and port combination. But I thought we had rough =20= > consensus > to go for address-only permissions. What I forgot is, how is a =20 > packet that > matches a permission but does not match any channel framed by the =20 > TURN server > to the TURN client? A UDP packet arriving at the server at an allocated relayed transport =20= address can have one of three things happen: * It is dropped because there is no permission entry currently for =20 the IP address of the UDP packet, * It is forwarded on a channel if a channel has been bound to the =20 source transport address (=3D IP address and port of the peer sending =20= the packet), * If it forwarded in a Data Indication otherwise. What I suggested is that binding a channel to a given (IP address, =20 port) would automatically add a permission for that IP address. This =20 permission would last the usual interval (a recommended 60 seconds =20 currently, which I now realize should match what we said in RFC 4787 =20 - whoops!). Thinking about this more, I guess I am now neutral about this =20 proposal. On the one hand, it makes sense. On the other hand, it =20 mixes a control operation with permissions, which is something we do =20 not currently have. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 08 04:07:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCAR0-0002B0-Vq; Tue, 08 Jan 2008 04:07:46 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JCAR0-00029m-2P for behave-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 04:07:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCAQz-00026u-Mx for behave@ietf.org; Tue, 08 Jan 2008 04:07:45 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-07.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCAQz-0004ne-A6 for behave@ietf.org; Tue, 08 Jan 2008 04:07:45 -0500 Received: from adsl-068-209-246-231.sip.mia.bellsouth.net ([68.209.246.231] helo=[192.168.1.90]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JCAQv-0001nv-36; Tue, 08 Jan 2008 04:07:42 -0500 In-Reply-To: <200801030949.41979.remi.denis-courmont@nokia.com> References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <200801030949.41979.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <914FB0C9-1F63-4EBB-BADE-26F5506619A7@magma.ca> Content-Transfer-Encoding: quoted-printable From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header Date: Tue, 8 Jan 2008 04:08:19 -0500 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - adsl-068-209-246-231.sip.mia.bellsouth.net ([192.168.1.90]) [68.209.246.231] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Can you say more about the implementation complexity of doing this? It is clearly pointless to require this if many implementations are =20 going to ignore it. - Philip On 3-Jan-08, at 02:49 , R=E9mi Denis-Courmont wrote: > Le Saturday 22 December 2007 00:15:59 ext Philip Matthews, vous =20 > avez =E9crit : >> The thread on exceeding the MTU size has raised another issue about >> TURN: what bits (if any) in the IP header should be preserved across >> a TURN relay? >> >> My proposal is: >> >> A TURN server MUST preserve the Don't Fragment (DF) and TOS >> (=3D ECN and DiffServ) bits in the IP header when relaying IPv4 >> packets. > > I don't know what ECN will do for UDP, and I suppose that would not =20= > work for > TCP (since it works in pair with CWR). > > As with TOS, your proposal makes sense to me. In fact, I think =20 > there is an RFC > on TOS handling through tunnels. Unfortunately, from an API =20 > perspective, that > might be challenging enough that I am willing to bet at least some =20 > TURN > server implementations will ignore the requirement. Namely, there =20 > is no > standard for setting TOS per outgoing IPv4 packets (usually, it can =20= > only be > set per socket). Perhaps RFC3542 would need to be "backported" to =20 > IPv4. > > By the way, does anyone know if some NATs screw up with TOS? > > --=20 > R=E9mi Denis-Courmont > > > _______________________________________________ > 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 Jan 08 05:22:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCBbX-0008N3-Lt; Tue, 08 Jan 2008 05:22:43 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JCBbW-0008Mx-Sj for behave-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 05:22:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCBbW-0008Mp-HK for behave@ietf.org; Tue, 08 Jan 2008 05:22:42 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCBbW-0006gS-0J for behave@ietf.org; Tue, 08 Jan 2008 05:22:42 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m08AMBBN031715; Tue, 8 Jan 2008 12:22:39 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jan 2008 12:22:32 +0200 Received: from esdhcp041225.research.nokia.com ([172.21.41.225]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jan 2008 12:22:32 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Philip Matthews" Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header Date: Tue, 8 Jan 2008 12:23:16 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <200801030949.41979.remi.denis-courmont@nokia.com> <914FB0C9-1F63-4EBB-BADE-26F5506619A7@magma.ca> In-Reply-To: <914FB0C9-1F63-4EBB-BADE-26F5506619A7@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200801081223.17053.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 08 Jan 2008 10:22:32.0107 (UTC) FILETIME=[60F237B0:01C851E0] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Tuesday 08 January 2008 11:08:19 ext Philip Matthews, vous avez =E9crit= =A0: > Can you say more about the implementation complexity of doing this? > It is clearly pointless to require this if many implementations are > going to ignore it. As far as I know the Winsock (Windows), Linux and BSD socket API=20 implementations, none of them provide per-packet TOS and ECN bit=20 specification. I know applications can get the TOS value from a received packet on Linux/B= SD,=20 but they set the value individually for each sent packet. This functionalit= y=20 is present in the IPv6 APIs, but not the IPv4 ones. For ECN, as far as I=20 know, you cannot send nor receive the value from userland in any of these=20 operating systems. And even then, this only works for UDP. With TCP, there is no 1:1 mapping=20 between packets on the wire, and read/write socket operations, so it is=20 impossible to receive any bit from the IP header anyway. I understand why TURN should preserve TOS and ECN bits, but we have to know= =20 that if this were required, this would require in-kernel implementation for= =20 most typical operating systems. And because people will anyway try to make= =20 userland implementations, they'll get it wrong. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 08 05:24:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCBcw-0002Gh-Al; Tue, 08 Jan 2008 05:24:10 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JCBcv-0002Gc-50 for behave-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 05:24:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCBcu-0002GU-Rd for behave@ietf.org; Tue, 08 Jan 2008 05:24:08 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCBcu-0004ZC-HK for behave@ietf.org; Tue, 08 Jan 2008 05:24:08 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m08ANQZG000449; Tue, 8 Jan 2008 12:24:06 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jan 2008 12:24:05 +0200 Received: from esdhcp041225.research.nokia.com ([172.21.41.225]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jan 2008 12:24:05 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Philip Matthews" Subject: Re: [BEHAVE] TURN Issue: How important are channels anyway? Date: Tue, 8 Jan 2008 12:24:50 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200801070941.43082.remi.denis-courmont@nokia.com> <1994E9F1-B90C-4D5C-AC56-82416C4DEB3A@magma.ca> In-Reply-To: <1994E9F1-B90C-4D5C-AC56-82416C4DEB3A@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200801081224.50531.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 08 Jan 2008 10:24:05.0510 (UTC) FILETIME=[989E6260:01C851E0] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Tuesday 08 January 2008 10:57:06 ext Philip Matthews, vous avez =E9crit= =A0: > On 7-Jan-08, at 02:41 , R=E9mi Denis-Courmont wrote: > > On the other hand, fixed size overhead simplifies lots of things. For > > instance, programmers can use scatter-gather buffer arrays on the > > receive > > path, which help avoid extra memory-copying. It also avoids the > > need for even > > more intricate demultiplexing (remember how older TURN spec used > > Send and > > Data indication...). > > In general, always using Send/Data indications also gives a fixed- > size overhead: > STUN header 20 bytes > PEER-ADDRESS attribute 12 bytes (for IPv4) > DATA attribute 4 bytes + size of application data + > 0-3 bytes of padding Overhead is always fixed, or it is not fixed. There is no such thing=20 as "generally fixed" in that sense. Send/Data overhead is NOT fixed, becaus= e=20 data from the active destination is not wrapped while data from other=20 destination is. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 08 19:50:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCP8m-0002L4-GC; Tue, 08 Jan 2008 19:49:56 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JCP8l-0002Hs-9Q for behave-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 19:49:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCP8k-0002Af-St for behave@ietf.org; Tue, 08 Jan 2008 19:49:54 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-02.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCP8g-0003Kp-43 for behave@ietf.org; Tue, 08 Jan 2008 19:49:50 -0500 Received: from adsl-068-209-246-231.sip.mia.bellsouth.net ([68.209.246.231] helo=[192.168.1.90]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JCP8f-0000pl-0Y; Tue, 08 Jan 2008 19:49:49 -0500 In-Reply-To: <200801081224.50531.remi.denis-courmont@nokia.com> References: <200801070941.43082.remi.denis-courmont@nokia.com> <1994E9F1-B90C-4D5C-AC56-82416C4DEB3A@magma.ca> <200801081224.50531.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <9E954EEA-D319-4250-8B21-F13DA493418C@magma.ca> Content-Transfer-Encoding: quoted-printable From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue: How important are channels anyway? Date: Tue, 8 Jan 2008 19:50:25 -0500 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - adsl-068-209-246-231.sip.mia.bellsouth.net ([192.168.1.90]) [68.209.246.231] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 8-Jan-08, at 05:24 , R=E9mi Denis-Courmont wrote: > Le Tuesday 08 January 2008 10:57:06 ext Philip Matthews, vous avez =20 > =E9crit : >> On 7-Jan-08, at 02:41 , R=E9mi Denis-Courmont wrote: >>> On the other hand, fixed size overhead simplifies lots of things. =20= >>> For >>> instance, programmers can use scatter-gather buffer arrays on the >>> receive >>> path, which help avoid extra memory-copying. It also avoids the >>> need for even >>> more intricate demultiplexing (remember how older TURN spec used >>> Send and >>> Data indication...). >> >> In general, always using Send/Data indications also gives a fixed- >> size overhead: >> STUN header 20 bytes >> PEER-ADDRESS attribute 12 bytes (for IPv4) >> DATA attribute 4 bytes + size of application data + >> 0-3 bytes of padding > > Overhead is always fixed, or it is not fixed. There is no such thing > as "generally fixed" in that sense. Send/Data overhead is NOT =20 > fixed, because > data from the active destination is not wrapped while data from other > destination is. There is no longer a "Set Active Destination" concept in TURN. It was =20= removed in TURN-05. I was thinking about this some more, and now believe that an =20 implementation could easily detect the very common case where a Send =20 or Data indication is formatted as shown above. A few quick tests are =20= sufficient to confirm this. When the Send or Data indication is =20 formatted this way, it can be processed efficiently, and if the tests =20= fail, then the general STUN parsing code can be invoked. So I think the question really come down to the NUMBER of bytes of =20 overhead present. It is certainly true that Send and Data indications =20= require more bytes. Is this really important. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 08 23:30:26 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCSa7-0004HS-CF; Tue, 08 Jan 2008 23:30:23 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JCSa5-0004Gs-DV for behave-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 23:30:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCSa4-0004Gk-HY for behave@ietf.org; Tue, 08 Jan 2008 23:30:20 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCSa3-0007Br-3t for behave@ietf.org; Tue, 08 Jan 2008 23:30:20 -0500 X-IronPort-AV: E=Sophos;i="4.24,260,1196668800"; d="scan'208";a="32701132" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 08 Jan 2008 20:30:18 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m094UIff022751; Tue, 8 Jan 2008 20:30:18 -0800 Received: from [128.107.139.232] (dhcp-128-107-139-232.cisco.com [128.107.139.232]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m094U8cV019747; Wed, 9 Jan 2008 04:30:08 GMT In-Reply-To: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4C434B62-A6C6-4924-AC3D-932297594959@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header Date: Tue, 8 Jan 2008 20:30:03 -0800 To: Philip Matthews X-Mailer: Apple Mail (2.753) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=706; t=1199853018; x=1200717018; c=relaxed/simple; s=sjdkim4002; 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=20Issue=3A=20Preserving =20bits=20in=20the=20IP=20header |Sender:=20; bh=Hbs8wJi6ALO67CnGeZTcu07lpWuKVXAOWw92zlBQUVE=; b=WgXpq+fIU/cv7hUvb4AdKqY1vE2Vr0HcZc8DLXTGOJqJ2US/IPuZ//BYBl KPzMqedJEvbmicnDKIjVEUfto+1FZdw7nD8t9ikELT54t3rVY/0lTuLaIxWz AseQl5E3nl; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Rohan Mahy , 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 I think you need to separate what happens here in the TCP to UDP case from the UDP to UDP case. Cullen On Dec 21, 2007, at 2:15 PM, Philip Matthews wrote: > The thread on exceeding the MTU size has raised another issue about > TURN: what bits (if any) in the IP header should be preserved > across a TURN relay? > > My proposal is: > > A TURN server MUST preserve the Don't Fragment (DF) and TOS (= > ECN and DiffServ) bits in the IP header when relaying IPv4 packets. > > Comments? > > - Philip > > > _______________________________________________ > 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 Jan 08 23:38:19 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCShn-0004G8-JE; Tue, 08 Jan 2008 23:38:19 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JCShm-0004G2-4D for behave-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 23:38:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCShl-0004Fu-MZ for behave@ietf.org; Tue, 08 Jan 2008 23:38:17 -0500 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 1JCShl-0007kV-CZ for behave@ietf.org; Tue, 08 Jan 2008 23:38:17 -0500 X-IronPort-AV: E=Sophos;i="4.24,260,1196668800"; d="scan'208";a="10723225" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 08 Jan 2008 20:38:16 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m094cG4m029655; Tue, 8 Jan 2008 20:38:16 -0800 Received: from [128.107.139.232] (dhcp-128-107-139-232.cisco.com [128.107.139.232]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m094cCcV024885; Wed, 9 Jan 2008 04:38:12 GMT In-Reply-To: References: <4759A13C.8080106@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <80FB9D04-93CE-44C8-A3D4-CE7B0141D9C2@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] TURN Issue #3: Address v. Address and Port Restricted Date: Tue, 8 Jan 2008 20:38:06 -0800 To: Philip Matthews X-Mailer: Apple Mail (2.753) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=453; t=1199853496; x=1200717496; c=relaxed/simple; s=sjdkim4002; 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=20Issue=20#3=3A=20Addre ss=20v.=20Address=20and=20Port=20Restricted |Sender:=20; bh=MbNMkWYdffMe0mvFgZxy6WHS+qyLeHlFOpGAZ6E3z7g=; b=RK/gSP+vt+wNw6sIGs35iPSYKgPbeFlwuqJ2Baz4cOy2pqq76tGf32NPxL DlkWiU9AkFDR4eo4ip2mvguwGwzmiWZXoOZP7ALXdKGDw2fh7phPvLvKOny+ FTPKOKZuip; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Rohan Mahy , 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 Jan 5, 2008, at 5:37 AM, Philip Matthews wrote: > Comments? strongly oppose this. I believe this will allow TURN to be widely used for violation of firewall administrators desires which will result in in being blocked by firewalls - this will reduce our success rate of VoIP calls. Not doing this has been a key design principle of this work since day one - changing this now is a bad idea. Cullen _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 08 23:41:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCSkV-0006LR-Ud; Tue, 08 Jan 2008 23:41:07 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JCSkU-0006LM-4e for behave-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 23:41:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCSkT-0006LE-RE for behave@ietf.org; Tue, 08 Jan 2008 23:41:05 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCSkT-0007HT-FB for behave@ietf.org; Tue, 08 Jan 2008 23:41:05 -0500 X-IronPort-AV: E=Sophos;i="4.24,260,1196668800"; d="scan'208";a="6410083" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 08 Jan 2008 20:41:04 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m094f41x011174; Tue, 8 Jan 2008 20:41:04 -0800 Received: from [128.107.139.232] (dhcp-128-107-139-232.cisco.com [128.107.139.232]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m094exSZ026008; Wed, 9 Jan 2008 04:40:59 GMT In-Reply-To: <1C6AF3B7-BB61-45B1-A2CA-C02EAFFB5B66@magma.ca> References: <4759D19B.50005@cisco.com> <4760B1A0.6080807@cisco.com> <9B05C6FD-FF8A-4472-966E-D13C8573A9BF@magma.ca> <5D6A5A89-18B3-49A3-B852-EF0982730E35@magma.ca> <47620CD5.3010304@cisco.com> <4ECA60E2-558A-4EA8-8D08-53DCFE34C661@cisco.com> <30C5AFE6-C9FC-40FE-8A74-80B568FBD554@magma.ca> <1C97A587-D403-48D0-B086-584F7975FC31@cisco.com> <3E8D0268-A6CF-460B-827C-7358367FC961@magma.ca> <47685AF4.9030909@cisco.com> <1C6AF3B7-BB61-45B1-A2CA-C02EAFFB5B66@magma.ca> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9C098BE8-2A70-478F-84BE-75141FABE8EB@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages Date: Tue, 8 Jan 2008 20:40:53 -0800 To: Philip Matthews X-Mailer: Apple Mail (2.753) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=341; t=1199853664; x=1200717664; 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=20Issue=20#6=3A=20Frami ng=20header=20for=20actual=20TURN=20messages |Sender:=20; bh=dp7RMH2VVlCTELGz8CJadeUNup6VeQ6v6OiVaaMnQU0=; b=uvW2dnNz930Ni9KRXV/0Xdz2JV69c8TooNDhgu2IH4f7i2uLxICJRgDnHa vdndSU5kVQLdYtS5WSBU+o4mQpcMPXh2bJQM8azJWJNnb4Dcbvms2j0tPYZU dDKyyG2aIE; 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Rohan Mahy , 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 Jan 4, 2008, at 2:17 PM, Philip Matthews wrote: > This means that channel numbers would run from 0x4000 to 0xFFFF, > with 0xFFFF being a reserved channel number. This gives 49151 > different channels. > > Comments? No one has ever explained to me why we need more than 200 channels. Cullen _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 08 23:52:09 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCSvA-0002Tr-6O; Tue, 08 Jan 2008 23:52:08 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JCSv8-0002Tm-Rc for behave-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 23:52:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCSv8-0002Te-Gh for behave@ietf.org; Tue, 08 Jan 2008 23:52:06 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCSv8-000886-2V for behave@ietf.org; Tue, 08 Jan 2008 23:52:06 -0500 X-IronPort-AV: E=Sophos;i="4.24,260,1196668800"; d="scan'208";a="32708552" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 08 Jan 2008 20:52:05 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m094q5DD021068; Tue, 8 Jan 2008 20:52:05 -0800 Received: from [128.107.139.232] (dhcp-128-107-139-232.cisco.com [128.107.139.232]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id m094q4fr001561; Wed, 9 Jan 2008 04:52:05 GMT In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] TURN Issue: How important are channels anyway? Date: Tue, 8 Jan 2008 20:51:59 -0800 To: Philip Matthews X-Mailer: Apple Mail (2.753) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2148; t=1199854325; x=1200718325; c=relaxed/simple; s=sjdkim1004; 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=20Issue=3A=20How=20impo rtant=20are=20channels=20anyway? |Sender:=20; bh=HzGW/uH7HMaR/c5zdQQSiRm6Lvjv4H6ZyFDWgzaEi1o=; b=YKV0IfL0bzyZ/ay6bnm/26ZCgeNnmebQCxyYKe3Pxt47t/12/obBsSiU3i LizUi2/yXiUTT2PLT1Ah7+yc9MjpGzLRcz9QyLRubTTedpWP52Y/o4JCNxA2 1gpeMbZvVBDW947AGBkFnzBFczTBjMqstJtli1Wm/vn5gCzAT7uFg=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Rohan Mahy , 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 For the specific case of RTP over TURN, I think this is a requirement question better asked in AVT. There has been significant discussion of packet overhead when we came to the consensus that a new security protocol (SRTP) was needed instead of using RTP over an existing protocol such at TLS or IPSEC. I would encourage people to review how long that conversation went on last time we had it. On Jan 4, 2008, at 7:02 PM, Philip Matthews wrote: > The whole point of the TURN channel mechanism is to provide an > alternate encapsulation mechanism, one that has about 32 bytes less > overhead (over IPv4). Is this reduction in overhead important? > > Channels certainly add some complexity to TURN: the Framing Header > and the issues around its Length field and how-to-demux, the > ChannelBind method, and the yet-to-be-defined mechanism for > deallocating channels. About half of the issues we have been > discussing since Vancouver have been about the channel mechanism. > > There are a lot of other things out there today that add overhead > to a packet. Moving to IPv6, for example. Various tunneling > technologies inside the network, for another (MPLS, VPNs, IP > tunnels, ...). So perhaps an extra 32 bytes is not a killer. Or > perhaps the 32 bytes should be removed using other techniques: > compression techniques between a handset and its base station, for > example. > > Moreover, with the decision that TURN control messages are NOT > framed, channels are now cleanly separable from the rest of TURN. > Channels are very much an extra mechanism. So it would be easy to > add channels as an extension to TURN. > > So the question is: Is removing these 32 bytes important enough to > add channels to the base TURN specification (with the consequent > delays to the specification that this will inevitably add), or > should they be defined as an extension to TURN? > > Comments? > > - Philip > > > > > _______________________________________________ > 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 Jan 09 04:46:31 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCXW0-0000Or-Rz; Wed, 09 Jan 2008 04:46:28 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JCXVz-0000Ol-Ka for behave-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 04:46:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCXVz-0000Od-7y for behave@ietf.org; Wed, 09 Jan 2008 04:46:27 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCXVy-0004zV-Ng for behave@ietf.org; Wed, 09 Jan 2008 04:46:27 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m099k3IF022731; Wed, 9 Jan 2008 11:46:24 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jan 2008 11:46:22 +0200 Received: from [172.16.174.76] ([10.162.252.82]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jan 2008 11:46:22 +0200 Message-Id: From: Lars Eggert To: =?ISO-8859-1?Q?ext_R=E9mi_Denis-Courmont?= In-Reply-To: <200801081223.17053.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header Date: Wed, 9 Jan 2008 10:46:17 +0100 References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <200801030949.41979.remi.denis-courmont@nokia.com> <914FB0C9-1F63-4EBB-BADE-26F5506619A7@magma.ca> <200801081223.17053.remi.denis-courmont@nokia.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 09 Jan 2008 09:46:22.0367 (UTC) FILETIME=[7E17EAF0:01C852A4] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: behave@ietf.org, ext Philip Matthews 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 2008-1-8, at 11:23, ext R=E9mi Denis-Courmont wrote: > I understand why TURN should preserve TOS and ECN bits, but we have =20= > to know > that if this were required, this would require in-kernel =20 > implementation for > most typical operating systems. And because people will anyway try =20 > to make > userland implementations, they'll get it wrong. Understood, doing things correctly is hard with existing APIs. But =20 having TURN break ECN and DiffServ isn't the right approach, either. Lars= _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 09 20:06:19 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JClsA-0002Sc-03; Wed, 09 Jan 2008 20:06:18 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JCls8-0002QE-N8 for behave-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 20:06:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCls8-0002OZ-BY for behave@ietf.org; Wed, 09 Jan 2008 20:06:16 -0500 Received: from nz-out-0506.google.com ([64.233.162.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCls8-0005VO-4G for behave@ietf.org; Wed, 09 Jan 2008 20:06:16 -0500 Received: by nz-out-0506.google.com with SMTP id n1so263652nzf.4 for ; Wed, 09 Jan 2008 17:06:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=ic9BUyaXSTwRpy16DiDUKTm7VaFxq3i7XbvCQ56/yIA=; b=VLFBuvaCZRcnHmB63l3kCBODX+HpDic+fwzvXBlrbiRys2WaIhkKfQjsULg+Fu+27FCpRnBKle0edcsedf7cr9g04vZ6JF8mW1elVM+8uMGUs0poxP1+4G9pilR4MBfMypsGNI71LIzsGVYOvoDLYpoXeWWUsP1FMSSpxdfOYy8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=bKroaHdv1aYdvD2D9ASf/tlWpyVsoDCguJ4dJIUDykTlAliZEfqlfUEfQpZOOgXCRH44qCZ4S24Meljt+RyNApRfuby8wYS1U5CZuv1E9myHUVFC87Aa/ugh+oiUafbUUFtZgzILlIpu7wi7rpdOEcrVYN4uTUBDfGHVdW7wbRQ= Received: by 10.142.76.4 with SMTP id y4mr706417wfa.110.1199927174996; Wed, 09 Jan 2008 17:06:14 -0800 (PST) Received: by 10.142.52.6 with HTTP; Wed, 9 Jan 2008 17:06:14 -0800 (PST) Message-ID: Date: Wed, 9 Jan 2008 17:06:14 -0800 From: "Derek MacDonald" To: "Cullen Jennings" Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages In-Reply-To: <9C098BE8-2A70-478F-84BE-75141FABE8EB@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4759D19B.50005@cisco.com> <47620CD5.3010304@cisco.com> <4ECA60E2-558A-4EA8-8D08-53DCFE34C661@cisco.com> <30C5AFE6-C9FC-40FE-8A74-80B568FBD554@magma.ca> <1C97A587-D403-48D0-B086-584F7975FC31@cisco.com> <3E8D0268-A6CF-460B-827C-7358367FC961@magma.ca> <47685AF4.9030909@cisco.com> <1C6AF3B7-BB61-45B1-A2CA-C02EAFFB5B66@magma.ca> <9C098BE8-2A70-478F-84BE-75141FABE8EB@cisco.com> X-Google-Sender-Auth: 1de7ac21dc51c345 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Rohan Mahy , Behave WG , Philip Matthews 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 No channel re-use, so lots of channels allows long lived allocations. 32768 is plenty for me(and was antural from a protocol persepctive), and it makes the 1 byte read from TCP case easy. -Derek On Jan 8, 2008 8:40 PM, Cullen Jennings wrote: > > On Jan 4, 2008, at 2:17 PM, Philip Matthews wrote: > > > This means that channel numbers would run from 0x4000 to 0xFFFF, > > with 0xFFFF being a reserved channel number. This gives 49151 > > different channels. > > > > Comments? > > No one has ever explained to me why we need more than 200 channels. > > Cullen > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 09 21:55:06 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCnZQ-0004np-BE; Wed, 09 Jan 2008 21:55:04 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JCnZO-0004ne-Uq for behave-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 21:55:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCnZO-0004nW-JL for behave@ietf.org; Wed, 09 Jan 2008 21:55:02 -0500 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 1JCnZN-0007id-Sz for behave@ietf.org; Wed, 09 Jan 2008 21:55:02 -0500 X-IronPort-AV: E=Sophos;i="4.24,264,1196668800"; d="scan'208";a="11020504" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 09 Jan 2008 18:55:01 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m0A2t1cD005045; Wed, 9 Jan 2008 18:55:01 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id m0A2stSa006736; Thu, 10 Jan 2008 02:54:55 GMT In-Reply-To: References: <4759D19B.50005@cisco.com> <47620CD5.3010304@cisco.com> <4ECA60E2-558A-4EA8-8D08-53DCFE34C661@cisco.com> <30C5AFE6-C9FC-40FE-8A74-80B568FBD554@magma.ca> <1C97A587-D403-48D0-B086-584F7975FC31@cisco.com> <3E8D0268-A6CF-460B-827C-7358367FC961@magma.ca> <47685AF4.9030909@cisco.com> <1C6AF3B7-BB61-45B1-A2CA-C02EAFFB5B66@magma.ca> <9C098BE8-2A70-478F-84BE-75141FABE8EB@cisco.com> Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <167B480F-E725-43F8-BEBA-FF7957D5F21D@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages Date: Wed, 9 Jan 2008 18:53:59 -0800 To: "Derek MacDonald" X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1351; t=1199933701; x=1200797701; c=relaxed/simple; s=sjdkim4002; 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=20Issue=20#6=3A=20Frami ng=20header=20for=20actual=20TURN=20messages |Sender:=20; bh=aAgRdibY3ZddYeg2jEV35JfbVyLD45HPUMVWZjzWYo4=; b=m+oN6lddbPGpuL/85r2EdOza1ts6FvngB82eJ9d9j7C6mZ9z0G4BMw54Gg kDDlWt51f6Y26UfY7ljFXkjA3EPPtle/QHkGEBFCMizzZGwm0SeBq3qj7dSI ZszKgvWpJH; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Rohan Mahy , Behave WG , Philip Matthews 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 RIght, but I am missing the need for an allocation that is longer lived than 200 connections given how easy it is to get a new allocation. I'm pushing on the "why" for this because the only use cases I could imagine require us to do things that seem somewhat problematic. (as a side issue, I suspect we are going to end up needing a close command for channels to get the ICMP error to behave correctly which would then allow channel reuse but that is totally a side issue - the current issue is I don't understand the need for more than 200 channels) Cullen On Jan 9, 2008, at 5:06 PM, Derek MacDonald wrote: > No channel re-use, so lots of channels allows long lived allocations. > > 32768 is plenty for me(and was antural from a protocol persepctive), > and it makes the 1 byte read from TCP case easy. > > -Derek > > On Jan 8, 2008 8:40 PM, Cullen Jennings wrote: > > > > On Jan 4, 2008, at 2:17 PM, Philip Matthews wrote: > > > > > This means that channel numbers would run from 0x4000 to 0xFFFF, > > > with 0xFFFF being a reserved channel number. This gives 49151 > > > different channels. > > > > > > Comments? > > > > No one has ever explained to me why we need more than 200 channels. > > > > Cullen > > > > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jan 10 03:18:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCscZ-0002AO-RY; Thu, 10 Jan 2008 03:18:39 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JCscY-0002AA-0f for behave-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 03:18:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCscX-00029w-GW for behave@ietf.org; Thu, 10 Jan 2008 03:18:37 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCscW-0004ES-Tv for behave@ietf.org; Thu, 10 Jan 2008 03:18:37 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0A8IRet030475; Thu, 10 Jan 2008 10:18:34 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 10:18:32 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 10:18:32 +0200 Received: from esdhcp04166.research.nokia.com ([172.21.41.66]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 10:18:32 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: Lars Eggert Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header Date: Thu, 10 Jan 2008 10:19:16 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <200801081223.17053.remi.denis-courmont@nokia.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200801101019.17836.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 10 Jan 2008 08:18:32.0086 (UTC) FILETIME=[632C9B60:01C85361] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: behave@ietf.org, ext Philip Matthews 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 09 January 2008 11:46:17 Lars Eggert, vous avez =E9crit=A0: > On 2008-1-8, at 11:23, ext R=E9mi Denis-Courmont wrote: > > I understand why TURN should preserve TOS and ECN bits, but we have > > to know that if this were required, this would require in-kernel > > implementation for most typical operating systems. And because > > people will anyway try to make userland implementations, they'll > > get it wrong.=20 > > Understood, doing things correctly is hard with existing APIs. But > having TURN break ECN and DiffServ isn't the right approach, either. Of course. I am rather wondering if this would be a SHOULD, or a MUST. That= =20 would make some a whole class implementations non-compliant, though they'd= =20 still mostly work. =46or UDP (and UDP-Lite if we ever define if for TURN), we certainly want T= OS=20 and ECN preservation. That works fine because each client-to-relay packet=20 corresponds to one or zero relay-to-peer packet, and each peer-to-relay=20 packet corresponds to one or zero relay-to-client packet. I am a whole lot more suspicious when it comes to TURN-TCP though. It is=20 fortunate, we have split that out of the TURN baseline spec, because I can= =20 already imagine the headaches. With TCP, there is no obvious matching of IP= =20 packets on each sides of the relay. TCP does not preserve datagram=20 boundaries. Hence a single packets from one side could turn into multiples= =20 packets on the other side for various reasons. Worse yet, a single packet o= n=20 one side could be "coming from" different packets from the original side. =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 Jan 10 03:43:49 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCt0t-0001b5-9C; Thu, 10 Jan 2008 03:43:47 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JCt0s-0001b0-HZ for behave-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 03:43:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCt0r-0001as-T2 for behave@ietf.org; Thu, 10 Jan 2008 03:43:45 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCt0r-0002Ov-As for behave@ietf.org; Thu, 10 Jan 2008 03:43:45 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0A8hOOO008929; Thu, 10 Jan 2008 10:43:42 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 10:43:41 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 10:43:41 +0200 Received: from esdhcp035135.research.nokia.com ([172.21.35.135]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 10:43:40 +0200 Message-Id: From: Lars Eggert To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= In-Reply-To: <200801101019.17836.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header Date: Thu, 10 Jan 2008 10:43:40 +0200 References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <200801081223.17053.remi.denis-courmont@nokia.com> <200801101019.17836.remi.denis-courmont@nokia.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 10 Jan 2008 08:43:40.0758 (UTC) FILETIME=[E669AF60:01C85364] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: behave@ietf.org, ext Philip Matthews 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 2008-1-10, at 10:19, R=E9mi Denis-Courmont wrote: > For UDP (and UDP-Lite if we ever define if for TURN), we certainly =20 > want TOS > and ECN preservation. That works fine because each client-to-relay =20 > packet > corresponds to one or zero relay-to-peer packet, and each peer-to-=20 > relay > packet corresponds to one or zero relay-to-client packet. Agreed. And I hadn't even considered TURN-TCP in my earlier emails, I thought =20= we were talking about TURN-UDP only. You're right in what you write =20 below; what should be done for TURN-TCP in this regard is very =20 different. > I am a whole lot more suspicious when it comes to TURN-TCP though. =20 > It is > fortunate, we have split that out of the TURN baseline spec, because =20= > I can > already imagine the headaches. With TCP, there is no obvious =20 > matching of IP > packets on each sides of the relay. TCP does not preserve datagram > boundaries. Hence a single packets from one side could turn into =20 > multiples > packets on the other side for various reasons. Worse yet, a single =20 > packet on > one side could be "coming from" different packets from the original =20= > side. Lars= _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jan 10 17:25:28 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD5q2-0004bj-Gd; Thu, 10 Jan 2008 17:25:26 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JD5q0-0004XF-RD for behave-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 17:25:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD5q0-0004TJ-A0 for behave@ietf.org; Thu, 10 Jan 2008 17:25:24 -0500 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 1JD5pz-0000Ig-RV for behave@ietf.org; Thu, 10 Jan 2008 17:25:24 -0500 X-IronPort-AV: E=Sophos;i="4.24,268,1196668800"; d="scan'208";a="11282407" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 10 Jan 2008 14:25:23 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0AMPNcN006157; Thu, 10 Jan 2008 14:25:23 -0800 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0AMPMcV007327; Thu, 10 Jan 2008 22:25:22 GMT From: "Dan Wing" To: "'Lars Eggert'" , "=?iso-8859-1?Q?'R=E9mi_Denis-Courmont'?=" References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca><200801081223.17053.remi.denis-courmont@nokia.com><200801101019.17836.remi.denis-courmont@nokia.com> Subject: RE: [BEHAVE] TURN Issue: Preserving bits in the IP header Date: Thu, 10 Jan 2008 14:25:22 -0800 Message-ID: <0f3701c853d7$b0f61350$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchTZO7mv/OuAbL5RGiZTZRRTLmflwAckC4A In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2018; t=1200003923; x=1200867923; c=relaxed/simple; s=sjdkim1004; 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:=20RE=3A=20[BEHAVE]=20TURN=20Issue=3A=20Preserving =20bits=20in=20the=20IP=20header |Sender:=20; bh=wmuSgZuP8TCmyu/uzsjU0naF+BxDoNMNJTn7aus0N4I=; b=mPMifAQp3748KmoP43VsXq4C9Ocmz71BEIt+gqC3TRF1ezHnRvCKVCr9Pg DJDg2J8Jf/jnndLD1MNnzOf18ezObpTnIk+GdtS85Rh0hVAn3lGuCTrCCVYa U2Bn4sOolAx/pZpyv2EV4FbJAAlwI69+kekJHtb39zVhz2+fAmlSk=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: behave@ietf.org, 'ext Philip Matthews' 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 2008-1-10, at 10:19, R=E9mi Denis-Courmont wrote: > > For UDP (and UDP-Lite if we ever define if for TURN), we certainly =20 > > want TOS > > and ECN preservation. That works fine because each client-to-relay =20 > > packet > > corresponds to one or zero relay-to-peer packet, and each peer-to-=20 > > relay > > packet corresponds to one or zero relay-to-client packet. >=20 > Agreed. >=20 > And I hadn't even considered TURN-TCP in my earlier emails, I=20 > thought we were talking about TURN-UDP only. You're right in=20 > what you write below; what should be done for TURN-TCP in=20 > this regard is very different. The "TURN-UDP" document, draft-ietf-behave-turn, does support TCP between the TURN client and its TURN server. In all cases,=20 however, the connection from the TURN server to the remote TURN peer is always UDP. See the table in section 3.1, http://tools.ietf.org/html/draft-ietf-behave-turn-05#section-3.1 So, I expect "TURN-UDP" does have the problems you and Remi are=20 discussing: specifically, a (sent or received) TCP packet on the=20 'left' of a TURN server will not necessarily have a 1:1=20 correspondence with a UDP packet (received or sent) on the=20 'right'. -d > > I am a whole lot more suspicious when it comes to TURN-TCP though. =20 > > It is > > fortunate, we have split that out of the TURN baseline=20 > spec, because =20 > > I can > > already imagine the headaches. With TCP, there is no obvious =20 > > matching of IP > > packets on each sides of the relay. TCP does not preserve datagram > > boundaries. Hence a single packets from one side could turn into =20 > > multiples > > packets on the other side for various reasons. Worse yet, a single =20 > > packet on > > one side could be "coming from" different packets from the=20 > original =20 > > side. >=20 > Lars >=20 > _______________________________________________ > 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 Fri Jan 11 08:40:14 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDK7J-00065G-0f; Fri, 11 Jan 2008 08:40:13 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JDK7H-00064T-RE for behave-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 08:40:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDK7H-00064H-F7 for behave@ietf.org; Fri, 11 Jan 2008 08:40:11 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDK7G-0007Kc-TJ for behave@ietf.org; Fri, 11 Jan 2008 08:40:11 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0BDe1Wg011711; Fri, 11 Jan 2008 15:40:07 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 15:40:00 +0200 Received: from esdhcp04047.research.nokia.com ([172.21.40.47]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 15:39:59 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Dan Wing" Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header Date: Fri, 11 Jan 2008 15:40:47 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <0f3701c853d7$b0f61350$c2f0200a@cisco.com> In-Reply-To: <0f3701c853d7$b0f61350$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200801111540.48008.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 11 Jan 2008 13:39:59.0747 (UTC) FILETIME=[75EDDD30:01C85457] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: behave@ietf.org, 'ext Philip Matthews' 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 11 January 2008 00:25:22 ext Dan Wing, vous avez =E9crit=A0: > The "TURN-UDP" document, draft-ietf-behave-turn, does support TCP > between the TURN client and its TURN server. In all cases, > however, the connection from the TURN server to the remote TURN > peer is always UDP. See the table in section 3.1, > http://tools.ietf.org/html/draft-ietf-behave-turn-05#section-3.1 > > So, I expect "TURN-UDP" does have the problems you and Remi are > discussing: specifically, a (sent or received) TCP packet on the > 'left' of a TURN server will not necessarily have a 1:1 > correspondence with a UDP packet (received or sent) on the > 'right'. There might be tricks such as disabling the Nagle algorithm and playing tri= cks=20 with TCP/PSH and such uglinesses. However, I wonder if it makes much sense.= =20 The TURN client (or a TURN peer in the case of TURN-TCP) IP stack would=20 normally make use of the ECN bit on a TCP packet within the context of the= =20 corresponding TCP session. An a QoS middlebox may do the same thing with th= e=20 TOS bits. This is yet another argument in favor of NOT allowing multiple TCP peer=20 connections through a single TCP session to the TURN server. It basically=20 comes down to the same TCP congestion control issues. As far as I understand, it has however been more or less settled that TURN= =20 will allow this. Then, it may do more harm than good to preserve the ECN an= d=20 TOS bits when using TCP on either or both sides of the TURN relay. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 14 16:30:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEWsX-0006zw-5k; Mon, 14 Jan 2008 16:29:57 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JEWsV-0006zq-T5 for behave-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 16:29:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEWsV-0006zi-JK for behave@ietf.org; Mon, 14 Jan 2008 16:29:55 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-09.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEWsT-000686-EB for behave@ietf.org; Mon, 14 Jan 2008 16:29:55 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JEWsS-0006M8-2C; Mon, 14 Jan 2008 16:29:52 -0500 Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <643DFF11-26A2-4797-9355-43E219569B03@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Mon, 14 Jan 2008 16:30:41 -0500 To: Behave WG X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Rohan Mahy , Dan Wing Subject: [BEHAVE] TURN-06 delayed 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 Folks: Some of you may have noticed that the self-imposed deadline of Jan 8 for submitting version -06 of TURN-UDP has come and gone. The authors apologize about this; we actually did some work on the draft during the first week of January, but last week various things intervened and no work was done. However, we should be able to get back to it this week and are tentatively shooting to get the draft out early next week. This new draft will reflect the issues that have been closed and will allow people to make sure the draft reflects what they think was agreed to. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 14 17:33:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEXsJ-0006fT-3z; Mon, 14 Jan 2008 17:33:47 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JEXsH-0006fG-RL for behave-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 17:33:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEXsH-0006f7-FK for behave@ietf.org; Mon, 14 Jan 2008 17:33:45 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-01.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEXsH-0008PS-06 for behave@ietf.org; Mon, 14 Jan 2008 17:33:45 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JEXsF-0006OV-2X; Mon, 14 Jan 2008 17:33:43 -0500 In-Reply-To: <47630B03.3050708@cisco.com> References: <4759CD14.10208@cisco.com> <152D0B93-6269-4B44-A313-1D90EE6E8E73@nokia.com> <4762116C.3080106@cisco.com> <0B26C595-C3F5-4546-87DB-1732460BD75C@nokia.com> <47630B03.3050708@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #5: Port Range Date: Mon, 14 Jan 2008 17:34:32 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] 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: , Errors-To: behave-bounces@ietf.org On 14-Dec-07, at 18:00 , Jonathan Rosenberg wrote: > > > Lars Eggert wrote: >> On 2007-12-14, at 7:15, ext Jonathan Rosenberg wrote: >>> This would put a serious dent in the capacity of a TURN server. >>> As far as I know there is nothing that actually breaks by reusing >>> the registered ports for a dynamic allocation. >> If TURN grabs a port that my app has registered, I can't run my >> app on the TRUN server. Preventing this is exactly why port >> registries exist. > > As you state below, my assumption is that TURN is the only thing > running. Or, if there are things, they are known and probably up > and running before the TURN process starts (like SNMP). > >> (A minor related issue is that if TURN uses a port registered to >> my app, and there are firewalls that have rules for my app based >> on that port, the TURN traffic will get that treatment.) > > Well, we can have a conversation on the efficacy of port-based > treatment of traffic in a firewall. But I do agree firewalls do > block specific ports. > >>> Since TURN can't be used to run traditional servers, and the IP >>> and port must be exchanged with peers through a rendezvous >>> protocol, the typical issue of port conflict doesn't come up. >>> What am I missing? >> I think you assume that the TURN server will be the only thing >> running on an IP address. That's not a safe assumption. > > Right. > > OK, so how about this. > > The spec says SHOULD be limited to the dynamic range as you > suggest. However, as with other SHOULDs, it gives conditions under > which you can violate this should. Then it talks about cases where > no other applications run on the server, and where firewalls aren't > blocking ports, and if you know these aren't problems it is OK to > grab other ports. This would allow vendors of standalone TURN > servers to use the full range since both of these conditions exist > there. However, if TURN is run in an endpoint like a p2psip peer, > it would use the more limited range, which is fine anyway for that > use case. > > Sound OK? As I read this over again, I see an issue that I hadn't seen before. Say a TURN server allocates a port P in the Registered port range. How can the TURN server know that one or more peers are not behind firewalls that block access to this port? So I don't see the firewall part of this SHOULD condition. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 15 02:31:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEgGm-0006vr-8g; Tue, 15 Jan 2008 02:31:36 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JEgGl-0006vl-8F for behave-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 02:31:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEgGk-0006vc-Sa for behave@ietf.org; Tue, 15 Jan 2008 02:31:34 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEgGk-0006lV-9h for behave@ietf.org; Tue, 15 Jan 2008 02:31:34 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0F7OAxE029312; Tue, 15 Jan 2008 09:31:25 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jan 2008 09:31:18 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jan 2008 09:31:18 +0200 Received: from esdhcp04042.research.nokia.com ([172.21.40.42]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jan 2008 09:31:18 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] TURN Issue #5: Port Range Date: Tue, 15 Jan 2008 09:31:19 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <4759CD14.10208@cisco.com> <47630B03.3050708@cisco.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200801150931.19631.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 15 Jan 2008 07:31:18.0533 (UTC) FILETIME=[9E4F7B50:01C85748] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ext Philip Matthews 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 15 January 2008 00:34:32 ext Philip Matthews, vous avez =E9crit= =A0: > As I read this over again, I see an issue that I hadn't seen before. > > Say a TURN server allocates a port P in the Registered port range. > How can the TURN server know that one or more peers are not behind > firewalls that block access to this port? It cannot. Don't even try to solve the problem. Yes, some registered ports are routinely firewalled. The Battle.net ports a= nd=20 the Valve/Steam games ports are good examples from the registered port rang= e.=20 So is any port that has been used by a well publicized trojan horse. If your peer cannot reach some registered ports, your peer is broken. You w= ill=20 have the same problem whether you use plain SIP (or plain XMPP), or STUN or= =20 TURN or UPnP or NAT-PMP or anything. The only solution is to run everything on port TCP/443 over TLS, if you wan= t=20 to be sure your peer can reach you. > So I don't see the firewall part of this SHOULD condition. No. I don't think it's very appropriate for TURN to specify firewalling. Ev= en=20 if it did, it would not really help anyway. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 15 09:51:42 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEn8c-0003PC-Fw; Tue, 15 Jan 2008 09:51:38 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JEn8a-0003Oq-1i for behave-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 09:51:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEn8T-0003BB-DH for behave@ietf.org; Tue, 15 Jan 2008 09:51:29 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-05.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEn8T-0005pg-1B for behave@ietf.org; Tue, 15 Jan 2008 09:51:29 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JEn7g-0003rH-2y; Tue, 15 Jan 2008 09:50:41 -0500 In-Reply-To: <200801150931.19631.remi.denis-courmont@nokia.com> References: <4759CD14.10208@cisco.com> <47630B03.3050708@cisco.com> <200801150931.19631.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #5: Port Range Date: Tue, 15 Jan 2008 09:52:16 -0500 To: Behave WG X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 After thinking about this for a bit, and taking Remi's comments into account, I have come up with the following proposed text for this: The server SHOULD only allocate ports from the range 49152 - 65535 (the Dynamic and/or Private Port range [IANA]), unless the following conditions are met: o The TURN server application knows, through some means not specified here, that other applications running on the same host as the TURN server application will not be impacted by allocating ports outside this range, AND o The TURN server application believes, through some means not specified here, that firewalls between it and any peers are unlikely to block the port allocated. The first condition can often by satisfied by running the TURN server application on a dedicated machine and/or by arranging that any other applications allocate ports before the TURN server application starts. The second condition is harder to satisfy, but administrators MAY decide that certain ports outside the Dynamic and/or Private Port range are unlikely to be blocked by firewalls and are thus safe to use for TURN allocations. In any case, the TURN server SHOULD NOT allocate ports in the range 0 - 1023 (the Well- Known Port range) to discourage clients from using TURN to run standard services. Comments? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 15 10:23:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEnd0-0002o3-HS; Tue, 15 Jan 2008 10:23:02 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JEncy-0002gP-NI for behave-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 10:23:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEncy-0002ea-CE for behave@ietf.org; Tue, 15 Jan 2008 10:23:00 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-07.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEncx-0006Kf-GS for behave@ietf.org; Tue, 15 Jan 2008 10:23:00 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JEnct-0002fw-2c; Tue, 15 Jan 2008 10:22:56 -0500 In-Reply-To: <7116202E-9599-4D08-B982-BFC9394D7ACD@magma.ca> References: <47599D4F.50102@cisco.com> <200712101056.32140.remi.denis-courmont@nokia.com> <475D5443.5050601@cisco.com> <4A3D1671-D40E-449E-ADC3-24D2E8D16B90@magma.ca> <4760B414.3050703@cisco.com> <476210B3.4000603@cisco.com> <7116202E-9599-4D08-B982-BFC9394D7ACD@magma.ca> Mime-Version: 1.0 (Apple Message framework v753) 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 Issue #2: Stateful allocations Date: Tue, 15 Jan 2008 10:23:48 -0500 To: Behave WG X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: Rohan Mahy 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 Here is my proposed text to handle this issue: When the server receives the Allocate Request, it begins by processing it according to the base protocol procedures described in [I-D.ietf-behave-rfc3489bis], plus the Long-Term Credential =20 Mechanism procedures if the server is using this mechanism. It then checks if the 5-tuple used for the Allocate Request matches the 5-tuple used for an existing allocation. If there is a match, then: o If the transport protocol is UDP, and the transaction id in the request message matches the transaction id used for the original allocation, then the server treats this as a retransmission of =20= the original request, and replies with the same response as it did to the original request. The server may do this by either storing its original response and resending it, or by rebuilding its original response from other state data. o If the transport protocol is not UDP, or if the transaction id in the request message does not match the transaction id used for =20= the original allocation, then the server replies with an error response containing the error code 437 Allocation Mismatch. If the 5-tuple does not match an existing allocation, then =20 processing continues as described below. Comments? I am particularly interested in comments about how easy it is for =20 servers to rebuild the original response from other state data. I =20 took a quick look at this, and it seems straightforward to me: the =20 server simply pulls the values for the RELAY-ADDRESS, LIFETIME, and =20 BANDWIDTH from the state data. - Philip On 14-Dec-07, at 08:46 , Philip Matthews wrote: > That is fine with me. > - Philip > On 14-Dec-07, at 00:12 , Jonathan Rosenberg wrote: > >> Ah, OK. I think this is an esoteric case but I agree this is an =20 >> inconsistency. I'd suggest a minor word smithing in rfc3489bis to =20 >> fix this. >> >> -Jonathan R. >> >> Philip Matthews wrote: >>> I see a very small inconsistency between this and 3489bis. >>> Let's assume the server uses Remi's suggested implementation =20 >>> technique. And lets say a client does an Allocate transaction =20 >>> with the server, then immediately deletes the allocation, and =20 >>> then does a second Allocation that happens to use the same =20 >>> transaction id as the first, but which the server cannot accept =20 >>> for some reason. Say all this happens within 10 seconds. Then the =20= >>> server needs to response with an error response, but 3489bis says =20= >>> that is should respond with a success response. >>> The problem is simply that the language in 3489bis is too strong =20 >>> for the TURN case. We could fix this either by changing the =20 >>> language in 3489bis, or by specifying Remi's proposed =20 >>> implementation technique and saying that this overrides the text =20 >>> in 3489bis about the 10 second stuff. >>> - Philip >>> On 12-Dec-07, at 23:24 , Jonathan Rosenberg wrote: >>>> I don't see what the duration of the allocation has to do with =20 >>>> the 10 second timer. Another way to think about the timer is =20 >>>> that the server has to provide transaction state and retain it =20 >>>> for 10 seconds after the end of the transaction. >>>> >>>> -Jonathan R. >>>> >>>> Philip Matthews wrote: >>>>> On 10-Dec-07, at 06:59 , Jonathan Rosenberg wrote: >>>>>> inline: >>>>>> >>>>>> R=E9mi Denis-Courmont wrote: >>>>>>> Le Friday 07 December 2007 21:21:51 ext Jonathan Rosenberg, =20 >>>>>>> vous avez =E9crit : >>>>>>>> There was general agreement at the ad-hoc that this is a non-=20= >>>>>>>> issue. TURN >>>>>>>> servers are already required to maintain state, in the form of >>>>>>>> allocations, permissions, channel bindings, and so on. =20 >>>>>>>> Transaction state >>>>>>>> is not much more. >>>>>>>> >>>>>>>> Note that, rfc3489bis requires stun transactions (including =20 >>>>>>>> extensions >>>>>>>> like TURN) to be idempotent. Note that, despite the =20 >>>>>>>> different response >>>>>>>> codes for a retransmit and new transaction, TURN remains =20 >>>>>>>> idempotent. >>>>>>>> Idempotency only requires that subsequent retries do not =20 >>>>>>>> alter the state >>>>>>>> on the server; it does NOT require the same response. We =20 >>>>>>>> went through >>>>>>>> this ad-nauseum on XCAP. >>>>>>>> >>>>>>>> The proposal is therefore to just document this fact, but =20 >>>>>>>> otherwise not >>>>>>>> change anything. >>>>>>>> >>>>>>>> Please comment if you agree (or not) with this. >>>>>>> If I understand correctly, this practically means the server =20 >>>>>>> must remember the ID of the STUN transaction that created the =20= >>>>>>> TURN allocation. When it receives an allocation, it returns a =20= >>>>>>> success response if it's the same ID or an error if it's not. =20= >>>>>>> Right? >>>>>> >>>>>> Yes. >>>>> To be consistent with 3489bis, you would also have to have a 10 =20= >>>>> second timer. 3489bis says: >>>>> If the request uses UDP transport and is a retransmission of a >>>>> request for which the server has already generated a success =20= >>>>> response >>>>> within the last 10 seconds, the server MUST retransmit the same >>>>> success response. One way for a server to do this is to =20 >>>>> remember all >>>>> transaction IDs received over UDP and their corresponding =20 >>>>> responses >>>>> in the last 10 seconds. >>>>> For short-lived TURN allocations, the 10-second timer is =20 >>>>> probably pointless, even though 3489bis requires it. For long-=20 >>>>> lived allocations (days or weeks or even months), the timer =20 >>>>> might become important -- I haven't worked out the math. In =20 >>>>> either case, I think the two documents should be consistent. >>>>> - Philip >>>> >>>> --=20 >>>> Jonathan D. Rosenberg, Ph.D. 499 Thornall St. >>>> Cisco Fellow Edison, NJ 08837 >>>> Cisco, Voice Technology Group >>>> jdrosen@cisco.com >>>> http://www.jdrosen.net PHONE: (408) =20 >>>> 902-3084 >>>> http://www.cisco.com >>>> >> >> --=20 >> Jonathan D. Rosenberg, Ph.D. 499 Thornall St. >> Cisco Fellow Edison, NJ 08837 >> Cisco, Voice Technology Group >> jdrosen@cisco.com >> http://www.jdrosen.net PHONE: (408) 902-3084 >> http://www.cisco.com >> > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://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 Jan 15 11:02:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEoFP-0002ga-8H; Tue, 15 Jan 2008 11:02:43 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JEoFN-0002gS-ST for behave-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 11:02:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEoFN-0002gK-Ih for behave@ietf.org; Tue, 15 Jan 2008 11:02:41 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEoFN-0006q1-5Y for behave@ietf.org; Tue, 15 Jan 2008 11:02:41 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0FG3K0h004585; Tue, 15 Jan 2008 10:03:32 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jan 2008 18:02:18 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jan 2008 18:02:17 +0200 Received: from esdhcp04042.research.nokia.com ([172.21.40.42]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jan 2008 18:02:17 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Philip Matthews" Subject: Re: [BEHAVE] TURN Issue #5: Port Range Date: Tue, 15 Jan 2008 18:02:20 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <4759CD14.10208@cisco.com> <200801150931.19631.remi.denis-courmont@nokia.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200801151802.20892.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 15 Jan 2008 16:02:17.0948 (UTC) FILETIME=[00BEF1C0:01C85790] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 Le Tuesday 15 January 2008 16:52:16 ext Philip Matthews, vous avez =E9crit= =A0: > The server SHOULD only allocate ports from the range 49152 - 65535 > (the Dynamic and/or Private Port range [IANA]), unless the following > conditions are met: Makes sense, though I expect servers will rather allocate from the locally= =20 configured dynamic port ranges (many OSes have this as configurable values). > o The TURN server application believes, through some means not > specified here, that firewalls between it and any peers are > unlikely to block the port allocated. On the Internet, the TURN server can now for sure that this is false for an= y=20 given port. That makes no sense to me. It is already too big a restriction for a TURN server to know a non-firewal= led=20 ports range for its clients. It is pretty impossible to know a non-firewall= ed=20 ports range for its client's peers. I repeat, you cannot fix this problem with any dynamic port allocation sche= me.=20 Some firewalls do block the ephemeral port range, e.g. to prevent tracerout= e. > Comments? I think the only solution to the firewalled ports issue is would be to=20 allocate a fixed port (or set thereof) for whatever protocol you want to ru= n. In the case of TURN, and NAT traversal this is simply impossible. If the pe= er=20 has a restrictive firewalling ruleset, it's its duty to use a TURN or SOCKS= =20 server or anything on its side, to work around the problem. In my humble=20 opinion, there is no need to specify anything, *and* specifying anything=20 around this issue would be useless. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 15 12:13:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEpML-00027g-0b; Tue, 15 Jan 2008 12:13:57 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JEpMJ-00027Z-7T for behave-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 12:13:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEpMI-00027R-Tx for behave@ietf.org; Tue, 15 Jan 2008 12:13:54 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEpMI-0001EL-4f for behave@ietf.org; Tue, 15 Jan 2008 12:13:54 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 15 Jan 2008 09:13:53 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m0FHDrSh029401; Tue, 15 Jan 2008 09:13:53 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m0FHDkt3021866; Tue, 15 Jan 2008 17:13:49 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jan 2008 09:13:38 -0800 Received: from [10.21.74.219] ([10.21.74.219]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jan 2008 09:13:37 -0800 Message-ID: <478CE9AE.9080102@cisco.com> Date: Tue, 15 Jan 2008 12:13:18 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [BEHAVE] TURN Issue: How important are channels anyway? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jan 2008 17:13:37.0301 (UTC) FILETIME=[F7706450:01C85799] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3217; t=1200417233; x=1201281233; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20Issue=3A=20How=20impo rtant=20are=20channels=20anyway? |Sender:=20; bh=bLhW9w0/jrT0uX6x31TxSDqYTrlhpMvjBkFi/5g+p8Y=; b=h+HaDl/OnD6E97KTl/baT+zkBO3r3KvkSH0U82fprWogNr64a2LKP8thIB L7iNYu5CV84Jk9SPBl/ng8rAsToipJVdKu1qmYt9x6NfqG4vQHM2T8dWX0wL RmvQgKSkmA; 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: d185fa790257f526fedfd5d01ed9c976 Cc: Rohan Mahy , Behave WG , Philip Matthews 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 Sorry for popping in late here... From the very, very beginning, it has been a requirement of TURN to support a very low overhead encapsulation since RTP and voip in particular has been its primary usage. I haven't seen anything that indicates these requirements have changed. Efficiency of RTP has been and continues to be an issue, driving work like SRTP (as Cullen mentioned) and ROHC. I don't see any reason to revisit this design decision and think we should continue our current course of providing a low-overhead encapsulation. -Jonathan R. Cullen Jennings wrote: > > For the specific case of RTP over TURN, I think this is a requirement > question better asked in AVT. There has been significant discussion of > packet overhead when we came to the consensus that a new security > protocol (SRTP) was needed instead of using RTP over an existing > protocol such at TLS or IPSEC. I would encourage people to review how > long that conversation went on last time we had it. > > > On Jan 4, 2008, at 7:02 PM, Philip Matthews wrote: > >> The whole point of the TURN channel mechanism is to provide an >> alternate encapsulation mechanism, one that has about 32 bytes less >> overhead (over IPv4). Is this reduction in overhead important? >> >> Channels certainly add some complexity to TURN: the Framing Header and >> the issues around its Length field and how-to-demux, the ChannelBind >> method, and the yet-to-be-defined mechanism for deallocating channels. >> About half of the issues we have been discussing since Vancouver have >> been about the channel mechanism. >> >> There are a lot of other things out there today that add overhead to a >> packet. Moving to IPv6, for example. Various tunneling technologies >> inside the network, for another (MPLS, VPNs, IP tunnels, ...). So >> perhaps an extra 32 bytes is not a killer. Or perhaps the 32 bytes >> should be removed using other techniques: compression techniques >> between a handset and its base station, for example. >> >> Moreover, with the decision that TURN control messages are NOT framed, >> channels are now cleanly separable from the rest of TURN. Channels are >> very much an extra mechanism. So it would be easy to add channels as >> an extension to TURN. >> >> So the question is: Is removing these 32 bytes important enough to add >> channels to the base TURN specification (with the consequent delays to >> the specification that this will inevitably add), or should they be >> defined as an extension to TURN? >> >> Comments? >> >> - Philip >> >> >> >> >> _______________________________________________ >> 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 > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 15 12:29:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEpax-000604-J8; Tue, 15 Jan 2008 12:29:03 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JEpaw-0005zL-6q for behave-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 12:29:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEpav-0005z6-T9 for behave@ietf.org; Tue, 15 Jan 2008 12:29:01 -0500 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 1JEpav-0001Vf-EO for behave@ietf.org; Tue, 15 Jan 2008 12:29:01 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 15 Jan 2008 09:28:59 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0FHSxXk020677; Tue, 15 Jan 2008 09:28:59 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0FHSSir027436; Tue, 15 Jan 2008 17:28:58 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); Tue, 15 Jan 2008 09:28:55 -0800 Received: from [10.21.74.219] ([10.21.74.219]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jan 2008 09:28:55 -0800 Message-ID: <478CED44.4070008@cisco.com> Date: Tue, 15 Jan 2008 12:28:36 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #5: Port Range References: <4759CD14.10208@cisco.com> <47630B03.3050708@cisco.com> <200801150931.19631.remi.denis-courmont@nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jan 2008 17:28:55.0348 (UTC) FILETIME=[1AA33F40:01C8579C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1516; t=1200418139; x=1201282139; 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=20Issue=20#5=3A=20Port= 20Range |Sender:=20; bh=XcDlaQhpat5nBKWzW7r9HM9fiEzIcUP6R7HJXHEJcm0=; b=DTMmbifEcq6okP06KNm7ZNCYDXuwbVkjygjC8HtD/w1jxf24YsJRMuGSbN vTBYO6HYLjlnnl42xhpTMN3cvuzSW3rBT+1fqK3/YsJrkW3M8GCKBO5P2DJm zZ71qs5T69; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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: Philip Matthews wrote: > After thinking about this for a bit, and taking Remi's comments into > account, I have come up with the following proposed text for this: > > The server SHOULD only allocate ports from the range 49152 - 65535 > (the Dynamic and/or Private Port range [IANA]), unless the following > conditions are met: > > o The TURN server application knows, through some means not > specified here, that other applications running on the same host > as the TURN server application will not be impacted by allocating > ports outside this range, AND > > o The TURN server application believes, through some means not > specified here, that firewalls between it and any peers are > unlikely to block the port allocated. I think the right wording here is that the administrator believes that the firewalls in its own administrative domain are unlikely to block this port - thats the best we can do. I think its also worth nothing that there is basically NO way to know what your peer's firewalls may block; that this is highly variable. It is something to consider but it is not something that recommendations can be made on. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 15 15:54:25 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEsnf-0006Wb-3j; Tue, 15 Jan 2008 15:54:23 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JEsnd-0006WW-6l for behave-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 15:54:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEsnc-0006WN-TA for behave@ietf.org; Tue, 15 Jan 2008 15:54:20 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-02.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEsna-0005bn-CP for behave@ietf.org; Tue, 15 Jan 2008 15:54:20 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JEsnZ-0007aj-2u; Tue, 15 Jan 2008 15:54:18 -0500 In-Reply-To: <478CED44.4070008@cisco.com> References: <4759CD14.10208@cisco.com> <47630B03.3050708@cisco.com> <200801150931.19631.remi.denis-courmont@nokia.com> <478CED44.4070008@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7692B0A6-0794-400C-9464-AACCC3ADA81A@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #5: Port Range Date: Tue, 15 Jan 2008 15:55:07 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 I think we are all saying the same thing: to wit, there is no way to know for sure which ports are blocked by firewalls between the server and the peers. I tried to capture this in the following sentence (which you cut off in your reply): The second condition is harder to satisfy, but administrators MAY decide that certain ports outside the Dynamic and/or Private Port range are unlikely to be blocked by firewalls and are thus safe to use for TURN allocations. - Philip On 15-Jan-08, at 12:28 , Jonathan Rosenberg wrote: > inline: > > Philip Matthews wrote: >> After thinking about this for a bit, and taking Remi's comments >> into account, I have come up with the following proposed text for >> this: >> The server SHOULD only allocate ports from the range 49152 - 65535 >> (the Dynamic and/or Private Port range [IANA]), unless the >> following >> conditions are met: >> o The TURN server application knows, through some means not >> specified here, that other applications running on the same >> host >> as the TURN server application will not be impacted by >> allocating >> ports outside this range, AND >> o The TURN server application believes, through some means not >> specified here, that firewalls between it and any peers are >> unlikely to block the port allocated. > > I think the right wording here is that the administrator believes > that the firewalls in its own administrative domain are unlikely to > block this port - thats the best we can do. I think its also worth > nothing that there is basically NO way to know what your peer's > firewalls may block; that this is highly variable. It is something > to consider but it is not something that recommendations can be > made on. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > 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 Jan 15 16:59:36 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEtoh-0007nJ-NL; Tue, 15 Jan 2008 16:59:31 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JEtog-0007n1-UH for behave-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 16:59:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEtog-0007mt-Jv for behave@ietf.org; Tue, 15 Jan 2008 16:59:30 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-07.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEtoe-0007Lo-Fw for behave@ietf.org; Tue, 15 Jan 2008 16:59:30 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JEtoa-0005ME-0s; Tue, 15 Jan 2008 16:59:24 -0500 Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Tue, 15 Jan 2008 17:00:18 -0500 To: Behave WG X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Rohan Mahy Subject: [BEHAVE] TURN Issue: Recommended Permission Lifetime 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 TURN-05 recommends a permission lifetime of 60 seconds: o checks if a timer has been set for this permission. If none has been started, the server starts one. It is RECOMMENDED that it have a value of sixty seconds. If the timer is already running, it MUST be reset. However the BEHAVE-UDP specification (RFC 4787) recommends a much longer lifetime for the similar UDP mapping timer: REQ-5: A NAT UDP mapping timer MUST NOT expire in less than two minutes, unless REQ-5a applies. a) For specific destination ports in the well-known port range (ports 0-1023), a NAT MAY have shorter UDP mapping timers that are specific to the IANA-registered application running over that specific destination port. b) The value of the NAT UDP mapping timer MAY be configurable. c) A default value of five minutes or more for the NAT UDP mapping timer is RECOMMENDED. It seems to me that these two lifetimes should be consistent, and thus I propose to change the recommended TURN permission lifetime to be 5 minutes. Comments? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 16 12:28:34 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFC3w-0007Vh-Rh; Wed, 16 Jan 2008 12:28:28 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFC3v-0007UN-BA for behave-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 12:28:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFC3v-0007UF-0a for behave@ietf.org; Wed, 16 Jan 2008 12:28:27 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFC3u-00038k-Nn for behave@ietf.org; Wed, 16 Jan 2008 12:28:26 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 16 Jan 2008 09:28:26 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0GHSQg3030331 for ; Wed, 16 Jan 2008 09:28:26 -0800 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0GHSPiX002820 for ; Wed, 16 Jan 2008 17:28:25 GMT From: "Dan Wing" To: Date: Wed, 16 Jan 2008 09:28:26 -0800 Message-ID: <0bbf01c85865$341dd290$d94b150a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchX2ZWhanSXUp4FRF+VPs9cTGF7owAhlJ1w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=216; t=1200504506; x=1201368506; c=relaxed/simple; s=sjdkim1004; 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:=20IPR=20on=20RFC3489=20and=20draft-ietf-behave-na t-behavior-discovery |Sender:=20; bh=8NKK6e/ShNu1pPYlS/pSbtAYHUawgLBwzQCd7u67ftI=; b=Ik6sPEI1+7f1zubJWdnU7CETyBybDzg1iSz7X1lxame0NrDPB0bqp7Tr2e xu6f8tW84hlLD/iY7RZqj4Tv0OHkfvZfmUgY/ECce20ZJ3VlHb0/Y9gBtBI1 ocF9EMvpd50LsE1Ljg7BQzzuTW6/fuzu3k3wNFLhmPXzphOxvsb74=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [BEHAVE] IPR on RFC3489 and draft-ietf-behave-nat-behavior-discovery 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 following two IPR disclosures were submitted on January 14, 2008: draft-ietf-behave-nat-behavior-discovery: https://datatracker.ietf.org/ipr/919/ RFC3489: https://datatracker.ietf.org/ipr/918/ -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 16 14:18:36 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFDmU-0005pp-Su; Wed, 16 Jan 2008 14:18:34 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFDmT-0005pj-6C for behave-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 14:18:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFDmS-0005pZ-RB for behave@ietf.org; Wed, 16 Jan 2008 14:18:32 -0500 Received: from server.implementers.org ([69.55.225.91]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFDmS-0005ir-EN for behave@ietf.org; Wed, 16 Jan 2008 14:18:32 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id 69D6CF9CC1F8; Wed, 16 Jan 2008 11:18:31 -0800 (PST) Received: from [192.168.1.3] (c-71-202-183-123.hsd1.ca.comcast.net [71.202.183.123]) by server.implementers.org (Postfix) with ESMTP id 78FECF9CC1F6; Wed, 16 Jan 2008 11:18:28 -0800 (PST) Message-ID: <478E5883.5090606@acm.org> Date: Wed, 16 Jan 2008 11:18:27 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080109) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> In-Reply-To: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Rohan Mahy , 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 Philip Matthews wrote: > The thread on exceeding the MTU size has raised another issue about > TURN: what bits (if any) in the IP header should be preserved across a > TURN relay? > > My proposal is: > > A TURN server MUST preserve the Don't Fragment (DF) and TOS (= ECN and > DiffServ) bits in the IP header when relaying IPv4 packets. > > Comments? > I propose to do not try to preserve the values of this bits in the transport between the TURN client and server, but to carry them in the TURN protocol. The idea is that the bit values are different for the transport between the TURN client and the TURN server and for the channel between the application and the peer (even if part of this transport is tunneled): |--------- endpoint ---------| Application TURN client TURN Server Peer |=======================| |-------------------------------------------------------------| |=======================| The TURN spec should define the usage of this bits between the TURN client and the TURN server, but the usage of this bits between the application and the peer should be left to the application using TURN. The definition of the usage this bits in the TURN spec should make sense for any usage of this bits between the application and the peer. The transport of the bits can be done by adding an attribute to the Send and Data indications. Depending if the bits are set per channel or per packet they will have also to be carried in the ChannelBind transaction or as an additional header of the channel. -- 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 Wed Jan 16 23:29:36 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFMNh-0005VV-6o; Wed, 16 Jan 2008 23:29:33 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFMNg-0005VO-2Z for behave-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 23:29:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFMNf-0005VG-Cp for behave@ietf.org; Wed, 16 Jan 2008 23:29:31 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFMNe-0000ra-W2 for behave@ietf.org; Wed, 16 Jan 2008 23:29:31 -0500 X-IronPort-AV: E=Sophos;i="4.24,299,1196668800"; d="scan'208";a="8438527" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 16 Jan 2008 20:29:30 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m0H4TUjn003790; Wed, 16 Jan 2008 20:29:30 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id m0H4TUnj012556; Thu, 17 Jan 2008 04:29:30 GMT From: Cullen Jennings To: Philip Matthews In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org Subject: Re: [BEHAVE] TURN Issue #5: Port Range References: <4759CD14.10208@cisco.com> <47630B03.3050708@cisco.com> <200801150931.19631.remi.denis-courmont@nokia.com> Message-Id: <36970DB3-7EA2-4807-9659-FA005B303C94@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Wed, 16 Jan 2008 20:29:15 -0800 X-Mailer: Apple Mail (2.915) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=898; t=1200544170; x=1201408170; c=relaxed/simple; s=sjdkim4002; 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=20Issue=20#5=3A=20Port= 20Range |Sender:=20; bh=QuHN67f/I8CDuGrFvwiYMuMmg1zUVAzmgckZxdBKRbM=; b=LtmLJPSRD3dA6P81iVtZmtPcVZtMASnhAT+ItVGcGAvkLA48yPlBn9nD4B q2baK9Q+XeuZb05V05MCcs++4yC65tahFBl7uv9akoXq0LgB0WPBvUwHBoXP P8RaeCRIj8; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Jan 15, 2008, at 6:52 AM, Philip Matthews wrote: > o The TURN server application believes, through some means not > specified here, that firewalls between it and any peers are > unlikely to block the port allocated. I think you should drop all the text on firewalls - there is no more guarantee that port 49153 will get through any given firewall than port 49150. The topic of the firewalls is an operation concern and not a protocol specification issue here - the fact that the firewall has to be configured to allow access to ports the TURN server needs to use barely seems worth mentioning. The harm in this text is that it requires TURN server to not use a large portion of the address space. I suspect you are going outside what Lars was looking for here - you might want to sync up with him. Cullen with my individual contributor hat on _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 16 23:31:06 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFMPC-00076J-OE; Wed, 16 Jan 2008 23:31:06 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFMPB-000768-IK for behave-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 23:31:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFMPB-000760-7C for behave@ietf.org; Wed, 16 Jan 2008 23:31:05 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFMPA-0001Me-Qn for behave@ietf.org; Wed, 16 Jan 2008 23:31:05 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 16 Jan 2008 20:31:04 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0H4V4IO028606; Wed, 16 Jan 2008 20:31:04 -0800 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 m0H4UxiX003783; Thu, 17 Jan 2008 04:30:59 GMT From: Cullen Jennings To: Philip Matthews In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org Subject: Re: [BEHAVE] TURN Issue: Recommended Permission Lifetime References: Message-Id: <73FE7DD2-615E-4DF6-AE85-38855EB2010A@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Wed, 16 Jan 2008 20:30:45 -0800 X-Mailer: Apple Mail (2.915) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1505; t=1200544264; x=1201408264; c=relaxed/simple; s=sjdkim2002; 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=20Issue=3A=20Recommende d=20Permission=20Lifetime |Sender:=20; bh=uR80gJHmNh1mDBLlS5tDMQmCFEraYYrEJ1w2N9riSbk=; b=zSXaMBqScifXpy/Y6xsjoUnKi0PyXYBz2irUK+7Ec6gHwmGpFzKpI177Qm uih8l2nlv/4/qbFN4IQtST9tg0xknjNn9f5qBWcTN0X89G3LlkYzkl5KgYtI 6dvYqVMyO/; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Rohan Mahy , 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 Jan 15, 2008, at 2:00 PM, Philip Matthews wrote: > TURN-05 recommends a permission lifetime of 60 seconds: > > o checks if a timer has been set for this permission. If none has > been started, the server starts one. It is RECOMMENDED that it > have a value of sixty seconds. If the timer is already running, > it MUST be reset. > > > However the BEHAVE-UDP specification (RFC 4787) recommends a much > longer lifetime for the similar UDP mapping timer: > > REQ-5: A NAT UDP mapping timer MUST NOT expire in less than two > minutes, unless REQ-5a applies. > > a) For specific destination ports in the well-known port range > (ports 0-1023), a NAT MAY have shorter UDP mapping timers that > are specific to the IANA-registered application running over > that specific destination port. > > b) The value of the NAT UDP mapping timer MAY be configurable. > > c) A default value of five minutes or more for the NAT UDP > mapping > timer is RECOMMENDED. > > It seems to me that these two lifetimes should be consistent, and > thus I propose to change the recommended TURN permission lifetime to > be 5 minutes. > > Comments? I agree - I think 5 min RECOMMENDED and MUST NOT be less than 2 minutes would be good. > > > - Philip > > > > _______________________________________________ > 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 Jan 16 23:41:06 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFMYr-0004ZX-Db; Wed, 16 Jan 2008 23:41:05 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFMYp-0004ZP-Jy for behave-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 23:41:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFMYp-0004ZH-AI for behave@ietf.org; Wed, 16 Jan 2008 23:41:03 -0500 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 1JFMYo-0000zb-Qe for behave@ietf.org; Wed, 16 Jan 2008 23:41:03 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 16 Jan 2008 20:41:02 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m0H4f2KY021906; Wed, 16 Jan 2008 20:41:02 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id m0H4f1nj019863; Thu, 17 Jan 2008 04:41:01 GMT From: Cullen Jennings To: Philip Matthews In-Reply-To: <478E5883.5090606@acm.org> Impp: xmpp:cullenfluffyjennings@jabber.org Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <478E5883.5090606@acm.org> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Wed, 16 Jan 2008 20:40:47 -0800 X-Mailer: Apple Mail (2.915) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3231; t=1200544862; x=1201408862; 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=20Issue=3A=20Preserving =20bits=20in=20the=20IP=20header |Sender:=20; bh=I2sp7+tJfZ3I4n34HfS8LCKiKXAzjmlcTYrxVJ3tRaY=; b=BbDtcViEVno761Zx0yKV57hDz8DfndfB2LWTKX23k9tz7nwWegu2v8RH2g sTuz2JSvY/M56PwZFd43m2QDQI/kv2YBvW2jkYrFZpe5Pg62XiVcAcOnoRZ2 SDeHtWrGhw; 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: cd26b070c2577ac175cd3a6d878c6248 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 I think we should figure out what we want to do in the TCP to UDP case first then worry about the UDP to UDP case. My logic is the TCP/UDP case is harder and once we decide there, we will probably do the same thing for the UDP/UDP case. As far as requirements, I do believe we need be able to control the DF and TOS. I can not imagine a strong use case where we needed different values of DF or TOS on one side vs the other side but perhaps someone will think of one. I do feel very strongly that it should be possible to implement whatever we do on common OS without too many complications. It would also be important for the P2P work that a TURN server could run without being "super user" sort of privileges. I can imagine solutions like Marc is proposing or ones that just preserve the bits from side to side but I'm not sure if both theses are easily implementable. Can anyone point at details of how to do this? Cullen On Jan 16, 2008, at 11:18 AM, Marc Petit-Huguenin wrote: > Philip Matthews wrote: >> The thread on exceeding the MTU size has raised another issue about >> TURN: what bits (if any) in the IP header should be preserved >> across a >> TURN relay? >> >> My proposal is: >> >> A TURN server MUST preserve the Don't Fragment (DF) and TOS (= ECN >> and >> DiffServ) bits in the IP header when relaying IPv4 packets. >> >> Comments? >> > > I propose to do not try to preserve the values of this bits in the > transport between the TURN client and server, but to carry them in the > TURN protocol. > > The idea is that the bit values are different for the transport > between > the TURN client and the TURN server and for the channel between the > application and the peer (even if part of this transport is tunneled): > > |--------- endpoint ---------| > Application TURN client TURN Server Peer > |=======================| > |-------------------------------------------------------------| > |=======================| > > The TURN spec should define the usage of this bits between the TURN > client and the TURN server, but the usage of this bits between the > application and the peer should be left to the application using TURN. > The definition of the usage this bits in the TURN spec should make > sense > for any usage of this bits between the application and the peer. > > The transport of the bits can be done by adding an attribute to the > Send > and Data indications. Depending if the bits are set per channel or > per > packet they will have also to be carried in the ChannelBind > transaction > or as an additional header of the channel. > > -- > 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 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jan 17 03:21:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFQ0D-0002Mf-5h; Thu, 17 Jan 2008 03:21:33 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFQ0B-0002MY-Gl for behave-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 03:21:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFQ0B-0002LX-46 for behave@ietf.org; Thu, 17 Jan 2008 03:21:31 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFQ0A-0005T0-Bo for behave@ietf.org; Thu, 17 Jan 2008 03:21:30 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0H8LNqZ002526; Thu, 17 Jan 2008 02:22:08 -0600 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 10:21:03 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 10:21:03 +0200 Received: from esdhcp04163.research.nokia.com ([172.21.41.63]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 10:21:03 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header Date: Thu, 17 Jan 2008 10:21:07 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <478E5883.5090606@acm.org> In-Reply-To: <478E5883.5090606@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200801171021.07978.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 17 Jan 2008 08:21:03.0391 (UTC) FILETIME=[E6402AF0:01C858E1] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Philip Matthews , Rohan Mahy 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 16 January 2008 21:18:27 ext Marc Petit-Huguenin, vous avez=20 =E9crit=A0: > Philip Matthews wrote: > > The thread on exceeding the MTU size has raised another issue about > > TURN: what bits (if any) in the IP header should be preserved across a > > TURN relay? > > > > My proposal is: > > > > A TURN server MUST preserve the Don't Fragment (DF) and TOS (=3D ECN = and > > DiffServ) bits in the IP header when relaying IPv4 packets. > > > > Comments? > > I propose to do not try to preserve the values of this bits in the > transport between the TURN client and server, but to carry them in the > TURN protocol. Most probably we don't want to customize the DF bit for TCP packets. Rather= we=20 should let the TCP stack figure the MSS and do all the magic by itself. I can think of two sensible options: =2D One option is to replicate the bits from each sides. This only works if= we=20 have UDP on both sides. =2D Another option is to specify the desired values for sending, during the= =20 binding (or allocate) requests. That works fine in all combination of TCP a= nd=20 UDP, on the client->relay->peer direction, under the assumption that the=20 values are constant for a TURN binding lifetime. This does not put any extr= a=20 requirement on the TURN client IP stack, and puts requirements that should = be=20 met by any server-grade operating system on the TURN relay stack. In the peer->relay->client direction, I would think the client does not rea= lly=20 care about the "incoming" DF and TOS bits. These are mostly of interest to= =20 the boxes on the path. As such, I don't see much point into carrying them=20 into the TURN protocol. So we should try to replicate the bits in UDP-to-UD= P=20 case. With TCP, we may have to ignore them altogether, or use the "sending= =20 values" set by the TURN client. > The transport of the bits can be done by adding an attribute to the > Send and Data indications. =A0Depending if the bits are set per channel > or per packet they will have also to be carried in the ChannelBind > transaction or as an additional header of the channel. I very much disagree. First this may add a big overhead, as we may end up=20 using Send/Data indications all the time. Second, that hides the TOS/DF bit= s=20 away from those who actually care about them: the middleboxes. =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 Jan 17 04:03:06 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFQeH-0005EX-V3; Thu, 17 Jan 2008 04:02:57 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFQeH-0005B9-B0 for behave-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 04:02:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFQeG-00052z-JQ for behave@ietf.org; Thu, 17 Jan 2008 04:02:56 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFQeE-0004u6-Cs for behave@ietf.org; Thu, 17 Jan 2008 04:02:56 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id m0H92XU10799; Thu, 17 Jan 2008 01:02:34 -0800 In-Reply-To: <200801171021.07978.remi.denis-courmont@nokia.com> References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <478E5883.5090606@acm.org> <200801171021.07978.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <1A6A9A9F-09A4-40E3-8C86-09D4A5615717@ekabal.com> Content-Transfer-Encoding: quoted-printable From: Rohan Mahy Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header Date: Thu, 17 Jan 2008 01:02:34 -0800 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= X-Mailer: Apple Mail (2.753) X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: Rohan Mahy , behave@ietf.org, Philip Matthews 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 If we do anything at all, then Rem=ED's second suggestion seems the =20 most sensible to me. Of course there are those who believe that TURN is only going to get =20 used in practice when sending traffic across administrative domains. =20 In most of those cases, the TURN server will be reasonably close to =20 the core of the Internet. The markings between the client and the =20 TURN server and between the peer and between the TURN server and the =20 peer will typically be remarked to zero. While we could influence =20 the ToS in the same domain as the TURN server, this seems unlikely to =20= be important. thanks, -rohan On Jan 17, 2008, at 12:21 AM, R=E9mi Denis-Courmont wrote: > Le Wednesday 16 January 2008 21:18:27 ext Marc Petit-Huguenin, vous =20= > avez > =E9crit : >> Philip Matthews wrote: >>> The thread on exceeding the MTU size has raised another issue about >>> TURN: what bits (if any) in the IP header should be preserved =20 >>> across a >>> TURN relay? >>> >>> My proposal is: >>> >>> A TURN server MUST preserve the Don't Fragment (DF) and TOS (=3D =20= >>> ECN and >>> DiffServ) bits in the IP header when relaying IPv4 packets. >>> >>> Comments? >> >> I propose to do not try to preserve the values of this bits in the >> transport between the TURN client and server, but to carry them in =20= >> the >> TURN protocol. > > Most probably we don't want to customize the DF bit for TCP =20 > packets. Rather we > should let the TCP stack figure the MSS and do all the magic by =20 > itself. > > I can think of two sensible options: > > - One option is to replicate the bits from each sides. This only =20 > works if we > have UDP on both sides. > > - Another option is to specify the desired values for sending, =20 > during the > binding (or allocate) requests. That works fine in all combination =20 > of TCP and > UDP, on the client->relay->peer direction, under the assumption =20 > that the > values are constant for a TURN binding lifetime. This does not put =20 > any extra > requirement on the TURN client IP stack, and puts requirements that =20= > should be > met by any server-grade operating system on the TURN relay stack. > > In the peer->relay->client direction, I would think the client does =20= > not really > care about the "incoming" DF and TOS bits. These are mostly of =20 > interest to > the boxes on the path. As such, I don't see much point into =20 > carrying them > into the TURN protocol. So we should try to replicate the bits in =20 > UDP-to-UDP > case. With TCP, we may have to ignore them altogether, or use the =20 > "sending > values" set by the TURN client. > >> The transport of the bits can be done by adding an attribute to the >> Send and Data indications. Depending if the bits are set per channel >> or per packet they will have also to be carried in the ChannelBind >> transaction or as an additional header of the channel. > > I very much disagree. First this may add a big overhead, as we may =20 > end up > using Send/Data indications all the time. Second, that hides the =20 > TOS/DF bits > away from those who actually care about them: the middleboxes. > > --=20 > R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jan 17 08:17:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFUcl-00028U-CD; Thu, 17 Jan 2008 08:17:39 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFUck-00025c-Hh for behave-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 08:17:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFUcj-00020S-PO for behave@ietf.org; Thu, 17 Jan 2008 08:17:37 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFUcj-0002Qo-6U for behave@ietf.org; Thu, 17 Jan 2008 08:17:37 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0HDHNvl001644; Thu, 17 Jan 2008 15:17:28 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 15:16:38 +0200 Received: from [10.10.107.181] ([10.162.252.206]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 15:16:37 +0200 Message-Id: From: Lars Eggert To: ext Cullen Jennings In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header Date: Thu, 17 Jan 2008 14:16:34 +0100 References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <478E5883.5090606@acm.org> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 17 Jan 2008 13:16:37.0729 (UTC) FILETIME=[30BD6510:01C8590B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Behave WG , Philip Matthews 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 2008-1-17, at 5:40, ext Cullen Jennings wrote: > As far as requirements, I do believe we need be able to control the > DF and TOS. The bits that should be preserved across a TURN relay are the ones that are important end-to-end. The DF bit isn't one of these, because the transport connections are terminated at the TURN relay, so it needs to diddle them according to what its local stack requires, for both relayed connections. For the ECN bits, it matters what transport protocols are used: For UDP-UDP relays, and assuming a 1:1 packet ratio, the ECN bits can be relayed, to let the applications react to them. (With different ratios, my feeling is that they can also be relayed, but I need to think about this more.) For TCP-UDP relays, the ECN bits should not be relayed, because the transport connection for which they are a signal terminates at the TURN relay, and it should be the entity to react to the signal. Relaying the ECN bits doesn't make sense, because they have no meaning to the control loop that controls transmissions on the "other side" of the TURN relay. With the DSCP, issues are similar than for ECN. For the UDP case, where there's a 1:1 correspondence between packets sent and received, the TURN relay can copy (or remark) the DSCP. For UDP-TCP, it's not clear how that could happen. Lars _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jan 17 09:13:46 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFVV2-0005mm-Vq; Thu, 17 Jan 2008 09:13:44 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFVV0-0005mc-QH for behave-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 09:13:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFVV0-0005mU-Ej for behave@ietf.org; Thu, 17 Jan 2008 09:13:42 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-09.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFVUz-0001dq-T2 for behave@ietf.org; Thu, 17 Jan 2008 09:13:42 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JFVUw-0004HP-0H; Thu, 17 Jan 2008 09:13:38 -0500 In-Reply-To: References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <478E5883.5090606@acm.org> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4A3CAD0D-F58D-4EE2-B59A-04F463745D1D@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header Date: Thu, 17 Jan 2008 09:14:33 -0500 To: Behave WG X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Rohan Mahy 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 its heart, this issue is about whether we see one end-to-end connection between the client and the peer, or whether we see two connections (client to server, and server to peer) with some linkage between them. I originally subscribed to the first view, and had the idea that the relay could be viewed as forwarding at the IP layer, not the UDP layer. However, various things now make me think that the second view is the correct view, with the support for TCP to UDP relaying being a key point. If we adopt the second view, then I think the answer is that the ECN and DF bits on the two connections are independent of each other. To see why I think this is the right choice, consider the TCP to UDP relaying case. In this case, TCP is controlling the settings of the ECN and DF bits on the TCP connection, while UDP is controlling the setting of these bits on the UDP connection. I feel this is especially obvious if you consider the case of a single TCP connection to the server, but two or more UDP connections from the server to two or more peers. Regarding the DS bits, I think the best solution is for the client to send the server some indication of what type of traffic is being transported, and let the server set the DS bits appropriately. Such an indication would also be useful to the server when determining whether to allow a new allocation. Specifically, I propose that: The transport layer used between the client and the server will set the ECN, and DF bits as it sees fit, and similarly the transport layer between the client and the peer will set the ECN and DF bits as it sees fit. The client cannot influence or learn the ECN and DF bits settings between the server and the peer. The client will send the server an indication of the traffic type at allocation time, and the server will use this to set the DS bits on the server-to-peer connections (and perhaps on the server-to-client connection as well). Comments? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jan 17 11:29:20 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFXcF-0008Fr-Oe; Thu, 17 Jan 2008 11:29:19 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFXcE-0008E6-M9 for behave-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 11:29:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFXcD-0008A4-Qd for behave@ietf.org; Thu, 17 Jan 2008 11:29:17 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFXcD-0005LT-EV for behave@ietf.org; Thu, 17 Jan 2008 11:29:17 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 17 Jan 2008 08:29:16 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0HGTG0O027290; Thu, 17 Jan 2008 08:29:16 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id m0HGTGsj020636; Thu, 17 Jan 2008 16:29:16 GMT From: Cullen Jennings To: Lars Eggert In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <478E5883.5090606@acm.org> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Thu, 17 Jan 2008 08:29:03 -0800 X-Mailer: Apple Mail (2.915) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1654; t=1200587356; x=1201451356; c=relaxed/simple; s=sjdkim2002; 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=20Issue=3A=20Preserving =20bits=20in=20the=20IP=20header |Sender:=20; bh=Qvm4/e/YMQNKXOXWlxSJyNwfDEzdteZy7ZQ60owqubw=; b=eJCWgpXUs42O4yB4gSQbL7++a0mt4slyKAvfKB/LDdZJk4hvjzJMhuxySC Dc4zAUVYk6PkUu0YsbY6kxnpeNLyxgsKQeyvZE8sn4VNgzAHS5te1E6nie/f F7voiSGp77; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Behave WG , Philip Matthews 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 Jan 17, 2008, at 5:16 AM, Lars Eggert wrote: > On 2008-1-17, at 5:40, ext Cullen Jennings wrote: >> As far as requirements, I do believe we need be able to control the >> DF and TOS. > > The bits that should be preserved across a TURN relay are the ones > that are important end-to-end. The DF bit isn't one of these, > because the transport connections are terminated at the TURN relay, > so it needs to diddle them according to what its local stack > requires, for both relayed connections. > > For the ECN bits, it matters what transport protocols are used: > > For UDP-UDP relays, and assuming a 1:1 packet ratio, the ECN bits > can be relayed, to let the applications react to them. (With > different ratios, my feeling is that they can also be relayed, but I > need to think about this more.) > > For TCP-UDP relays, the ECN bits should not be relayed, because the > transport connection for which they are a signal terminates at the > TURN relay, and it should be the entity to react to the signal. > Relaying the ECN bits doesn't make sense, because they have no > meaning to the control loop that controls transmissions on the > "other side" of the TURN relay. > > With the DSCP, issues are similar than for ECN. For the UDP case, > where there's a 1:1 correspondence between packets sent and > received, the TURN relay can copy (or remark) the DSCP. For UDP-TCP, > it's not clear how that could happen. > > Lars works for me - I was also thinking about doing end to end PMTU. Would the client need a way to tell the relay to set the DF on the traffic to the peer? _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jan 17 11:34:19 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFXh4-00035T-QP; Thu, 17 Jan 2008 11:34:18 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFXh3-00035M-1w for behave-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 11:34:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFXh2-00035E-OT for behave@ietf.org; Thu, 17 Jan 2008 11:34:16 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFXh0-0007pe-A3 for behave@ietf.org; Thu, 17 Jan 2008 11:34:16 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 17 Jan 2008 08:34:13 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0HGYDKB026770; Thu, 17 Jan 2008 08:34:13 -0800 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 m0HGYBiX006696; Thu, 17 Jan 2008 16:34:11 GMT From: Cullen Jennings To: Philip Matthews In-Reply-To: <4A3CAD0D-F58D-4EE2-B59A-04F463745D1D@magma.ca> Impp: xmpp:cullenfluffyjennings@jabber.org Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <478E5883.5090606@acm.org> <4A3CAD0D-F58D-4EE2-B59A-04F463745D1D@magma.ca> Message-Id: <3C898AB6-05B8-4854-8E20-5E87B304F905@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Thu, 17 Jan 2008 08:33:57 -0800 X-Mailer: Apple Mail (2.915) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2539; t=1200587653; x=1201451653; c=relaxed/simple; s=sjdkim1004; 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=20Issue=3A=20Preserving =20bits=20in=20the=20IP=20header |Sender:=20; bh=Ya642aYhIXfupOimsrhppv2z+CCYqzTL55dMGnxkl2o=; b=ufXEiBSDla6jyY3r0k0wK7oIJSlET05Dn40xzZx1ltOlDv2AebzM6sbiIo tXfH4fmaxSvhdD6PJnLFyDWr+WTjj2ronFv+QEoPuz7O+zf4Kd/ekYhvuhCV oGKX9r5HGxgiF79tVMKH+lVlNuCspy751NTYdgff43AgPMHfny6n4=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Rohan Mahy , 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 Jan 17, 2008, at 6:14 AM, Philip Matthews wrote: > At its heart, this issue is about whether we see one end-to-end > connection between the client and the peer, or whether we see two > connections (client to server, and server to peer) with some linkage > between them. > > I originally subscribed to the first view, and had the idea that the > relay could be viewed as forwarding at the IP layer, not the UDP > layer. > > However, various things now make me think that the second view is > the correct view, with the support for TCP to UDP relaying being a > key point. > > If we adopt the second view, then I think the answer is that the ECN > and DF bits on the two connections are independent of each other. > > To see why I think this is the right choice, consider the TCP to UDP > relaying case. In this case, TCP is controlling the settings of the > ECN and DF bits on the TCP connection, while UDP is controlling the > setting of these bits on the UDP connection. I feel this is > especially obvious if you consider the case of a single TCP > connection to the server, but two or more UDP connections from the > server to two or more peers. > > Regarding the DS bits, I think the best solution is for the client > to send the server some indication of what type of traffic is being > transported, and let the server set the DS bits appropriately. Such > an indication would also be useful to the server when determining > whether to allow a new allocation. Hmm - I have no idea how I would implement "let the server set the DS bits appropriately". I think the DS bits are the indication of what type of traffic is. I'd be happier with the client told the relay the DS bits to use on the other side. But as long as it is clear how to implement this these seems like a possible path. > > > Specifically, I propose that: > > The transport layer used between the client and the server will > set the ECN, and DF bits as it sees fit, and similarly the transport > layer between the client and the peer will set the ECN and DF bits > as it sees fit. The client cannot influence or learn the ECN and DF > bits settings between the server and the peer. The client will send > the server an indication of the traffic type at allocation time, and > the server will use this to set the DS bits on the server-to-peer > connections (and perhaps on the server-to-client connection as well). > > Comments? > > - Philip > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jan 17 11:46:29 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFXsk-00025Z-8g; Thu, 17 Jan 2008 11:46:22 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFXsj-00025U-LU for behave-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 11:46:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFXsj-00025L-0y for behave@ietf.org; Thu, 17 Jan 2008 11:46:21 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-05.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFXsi-0005s7-N8 for behave@ietf.org; Thu, 17 Jan 2008 11:46:20 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JFXry-0007cS-2V; Thu, 17 Jan 2008 11:45:34 -0500 In-Reply-To: <3C898AB6-05B8-4854-8E20-5E87B304F905@cisco.com> References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <478E5883.5090606@acm.org> <4A3CAD0D-F58D-4EE2-B59A-04F463745D1D@magma.ca> <3C898AB6-05B8-4854-8E20-5E87B304F905@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <96483AA0-7F26-494C-9931-19D9BAB0017D@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header Date: Thu, 17 Jan 2008 11:47:14 -0500 To: Cullen Jennings X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Rohan Mahy , 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 17-Jan-08, at 11:33 , Cullen Jennings wrote: > > Hmm - I have no idea how I would implement "let the server set the > DS bits appropriately". I think the DS bits are the indication of > what type of traffic is. I'd be happier with the client told the > relay the DS bits to use on the other side. But as long as it is > clear how to implement this these seems like a possible path. Please correct me if I am wrong, but I seem to recall that the exact DS codepoint for a given traffic type is network-dependent. If I am correct, then the client cannot say to the server "use codepoint X for my traffic", because the network in which the server resides may use codepoint Y for that traffic type. So the client needs to instead say "use the codepoint for VoIP traffic" and that causes the server to use codepoint Y. Does this make any sense? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jan 17 13:05:45 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFZ7X-0000bw-Mp; Thu, 17 Jan 2008 13:05:43 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFZ7W-0000VH-8u for behave-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 13:05:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFZ7V-0000V9-Ug for behave@ietf.org; Thu, 17 Jan 2008 13:05:41 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFZ7V-0001XN-4m for behave@ietf.org; Thu, 17 Jan 2008 13:05:41 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 17 Jan 2008 10:05:40 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m0HI5e0a005463; Thu, 17 Jan 2008 10:05:40 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id m0HI5Xsj024975; Thu, 17 Jan 2008 18:05:34 GMT From: Cullen Jennings To: Philip Matthews In-Reply-To: <96483AA0-7F26-494C-9931-19D9BAB0017D@magma.ca> Impp: xmpp:cullenfluffyjennings@jabber.org Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <478E5883.5090606@acm.org> <4A3CAD0D-F58D-4EE2-B59A-04F463745D1D@magma.ca> <3C898AB6-05B8-4854-8E20-5E87B304F905@cisco.com> <96483AA0-7F26-494C-9931-19D9BAB0017D@magma.ca> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Thu, 17 Jan 2008 10:05:20 -0800 X-Mailer: Apple Mail (2.915) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1799; t=1200593140; x=1201457140; 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=20Issue=3A=20Preserving =20bits=20in=20the=20IP=20header |Sender:=20; bh=7Yh2w3dqiT3XO17rQHaj0Te6VHYZNdamZHIZuFG4Jsc=; b=LW61A7otCl5vilo2w1ypUNwRFB+SNT69Ghxxol9/SbU0o3Laqpzt07M1kq 0/xjoOxfn/ROF9YX3aljUAlDVaxd4MAoSp9IwrWtpLnMNz/epx2StiSotdmm YmtSCbgJPt; 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: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Rohan Mahy , 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 I'm assuming that the operator that configured the UA also knew about the TURN server and understands what DSCP would be appropriate both at the UA and at the TURN server. It's a bit more complicated than just "set the DS bits for voip" - the type of media changes things, signaling changes, different types of calls and different users or systems may get different ones. It seems like it will be hard to communicate enough information from the UA to the TURN server to have it make theses decision. It can probably be done if you want to go this way but there are some things to deal with. I think what this comes down to is that if you believe TURN is only for RTP, then it is a much more tractable problem than if you believe TURN is for many things. Cullen On Jan 17, 2008, at 8:47 AM, Philip Matthews wrote: > > On 17-Jan-08, at 11:33 , Cullen Jennings wrote: > > > > Hmm - I have no idea how I would implement "let the server set the > > DS bits appropriately". I think the DS bits are the indication of > > what type of traffic is. I'd be happier with the client told the > > relay the DS bits to use on the other side. But as long as it is > > clear how to implement this these seems like a possible path. > > Please correct me if I am wrong, but I seem to recall that the exact > DS codepoint for a given traffic type is network-dependent. If I am > correct, then the client cannot say to the server "use codepoint X > for my traffic", because the network in which the server resides may > use codepoint Y for that traffic type. So the client needs to instead > say "use the codepoint for VoIP traffic" and that causes the server > to use codepoint Y. > > Does this make any sense? > > - Philip > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 18 03:30:27 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFmcH-00066G-Og; Fri, 18 Jan 2008 03:30:21 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFmcG-00066B-TO for behave-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 03:30:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFmcA-0005fp-23 for behave@ietf.org; Fri, 18 Jan 2008 03:30:14 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFmc9-0001U0-He for behave@ietf.org; Fri, 18 Jan 2008 03:30:14 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0I8TOmO014168; Fri, 18 Jan 2008 10:29:49 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 10:29:37 +0200 Received: from esdhcp04076.research.nokia.com ([172.21.40.76]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 10:29:37 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Cullen Jennings" Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header Date: Fri, 18 Jan 2008 10:29:41 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <4A3CAD0D-F58D-4EE2-B59A-04F463745D1D@magma.ca> <3C898AB6-05B8-4854-8E20-5E87B304F905@cisco.com> In-Reply-To: <3C898AB6-05B8-4854-8E20-5E87B304F905@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200801181029.42562.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 18 Jan 2008 08:29:37.0192 (UTC) FILETIME=[42E9BA80:01C859AC] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Behave WG , Rohan Mahy , Philip Matthews 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 17 January 2008 18:33:57 ext Cullen Jennings, vous avez =E9crit= =A0: > > Regarding the DS bits, I think the best solution is for the client > > to send the server some indication of what type of traffic is being > > transported, and let the server set the DS bits appropriately. Such > > an indication would also be useful to the server when determining > > whether to allow a new allocation. > > Hmm - I have no idea how I would implement "let the server set the DS > bits appropriately". I think the DS bits are the indication of what > type of traffic is. I'd be happier with the client told the relay the > DS bits to use on the other side. But as long as it is clear how to > implement this these seems like a possible path. What are the DS bits? At least some IP stacks do allow, without any specific privileges: * on a per-socket basis: - enabling/disabling path MTU discovery, which determines the DF, - setting the TOS bits, - setting the IPv4 TTL and IPv6 HL, * on a per-datagram basis (UDP, UDP-Lite and raw only): - getting the TOS bits, - getting the IPv4 TTL or IPv6 HL, - setting the TOS bits for each outgoing packets (IPv6-only) [1], - setting the IPv6 HL [1]. I am not aware of any socket stack that provides access to ECN bits, but th= en=20 again, I don't know that many socket stacks either. By the way, should we preserve the TTL as well? so that you cannot make TUR= N=20 loops?? [1] For IPv6, (informational) Advanced socket API RFC specifies it, hence=20 widely implemented. Doable for IPv4 too, but no stack seemed to bother=20 providing the option this far. I did have an unofficial Linux patch for thi= s=20 at some point. And if we really want to split hairs, what about the IPv6 Traffic Class bit= s? =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 Jan 18 09:48:50 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFsWW-0002Kl-VN; Fri, 18 Jan 2008 09:48:48 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFsWW-0002Ke-F8 for behave-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 09:48:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFsWW-0002KW-5J for behave@ietf.org; Fri, 18 Jan 2008 09:48:48 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-05.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFsWU-0000p1-RU for behave@ietf.org; Fri, 18 Jan 2008 09:48:48 -0500 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JFsVk-00038Q-1s; Fri, 18 Jan 2008 09:48:00 -0500 In-Reply-To: <200801181029.42562.remi.denis-courmont@nokia.com> References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <4A3CAD0D-F58D-4EE2-B59A-04F463745D1D@magma.ca> <3C898AB6-05B8-4854-8E20-5E87B304F905@cisco.com> <200801181029.42562.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <1A39E432-A9EA-43E9-BAE4-3C179C281432@magma.ca> Content-Transfer-Encoding: quoted-printable From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header Date: Fri, 18 Jan 2008 09:49:37 -0500 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Behave WG , Rohan Mahy 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 18-Jan-08, at 03:29 , R=E9mi Denis-Courmont wrote: > > What are the DS bits? The DS bits are the DiffServ bits. The old TOS field in the IP header has now been divided into a 6-bit =20 DiffServ field and a 2-bit ECN field. And thanks for the info on what can and cannot be done with standard =20 APIs. - Philip= _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 18 10:05:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFsmk-0003y4-Im; Fri, 18 Jan 2008 10:05:34 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFsmj-0003xq-A9 for behave-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 10:05:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFsmi-0003xh-W6 for behave@ietf.org; Fri, 18 Jan 2008 10:05:33 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-01.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFsmi-0005qi-Ms for behave@ietf.org; Fri, 18 Jan 2008 10:05:32 -0500 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JFsmh-0005Ya-1v for behave@ietf.org; Fri, 18 Jan 2008 10:05:31 -0500 Mime-Version: 1.0 (Apple Message framework v753) Content-Transfer-Encoding: 7bit Message-Id: <6A5F0867-AC09-443A-BA06-F1033F465167@magma.ca> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Behave WG From: Philip Matthews Date: Fri, 18 Jan 2008 10:06:27 -0500 X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [BEHAVE] Conf call on 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 I am trying to schedule a 2-hour conference call on TURN for the week of Jan 28 - Feb 1. The goal of the call will be to discuss and try to resolve open issues. If you have a strong interest in attending this call and would like to influence when the call is held, then send me an e-mail ASAP and I will let you know the times that we are considering for the call and you can then let me know your availability. Note that, even if you do not contact me, you can still join the call once the time is announced. All you get by contacting me now is input into when the call is scheduled. I plan to send out an e-mail announcing the details of the call on Tuesday, Jan 22. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 18 10:32:31 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtCo-0001dL-Gr; Fri, 18 Jan 2008 10:32:30 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFtCm-0001dC-UR for behave-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 10:32:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtCm-0001cv-C8 for behave@ietf.org; Fri, 18 Jan 2008 10:32:28 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFtCl-0001hS-Ng for behave@ietf.org; Fri, 18 Jan 2008 10:32:28 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F01C420783; Fri, 18 Jan 2008 16:32:26 +0100 (CET) X-AuditID: c1b4fb3c-ab2eebb0000007e0-cf-4790c68a4da8 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CBA9D20544; Fri, 18 Jan 2008 16:32:26 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 16:32:26 +0100 Received: from [127.0.0.1] ([147.214.30.230]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 16:32:26 +0100 Message-ID: <4790C67D.8030607@ericsson.com> Date: Fri, 18 Jan 2008 16:32:13 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages References: <4759D19B.50005@cisco.com> <4760B1A0.6080807@cisco.com> <9B05C6FD-FF8A-4472-966E-D13C8573A9BF@magma.ca> <5D6A5A89-18B3-49A3-B852-EF0982730E35@magma.ca> <47620CD5.3010304@cisco.com> <4ECA60E2-558A-4EA8-8D08-53DCFE34C661@cisco.com> <30C5AFE6-C9FC-40FE-8A74-80B568FBD554@magma.ca> <1C97A587-D403-48D0-B086-584F7975FC31@cisco.com> <3E8D0268-A6CF-460B-827C-7358367FC961@magma.ca> <47685AF4.9030909@cisco.com> <1C6AF3B7-BB61-45B1-A2CA-C02EAFFB5B66@magma.ca> In-Reply-To: <1C6AF3B7-BB61-45B1-A2CA-C02EAFFB5B66@magma.ca> X-Enigmail-Version: 0.95.6 X-OriginalArrivalTime: 18 Jan 2008 15:32:26.0156 (UTC) FILETIME=[53FE6EC0:01C859E7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Rohan Mahy , 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="===============2135545455==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2135545455== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD304A2E6B1BEBDFD78893E17" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD304A2E6B1BEBDFD78893E17 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, Sorry for being this late in commenting on this. However, I wonder if=20 you are recreating a issue STUN was designed to avoid or not. These two=20 bits in STUN is 00 to avoid matching RTP. Thus, with the proposed=20 definition it is important that one never tries to multiplex TURN and=20 RTP on the same local port. I got worried as someone thought this change would allow running STUN=20 and TURN on the same local port. This implied for me that also RTP would = be used on this same port. I think it is important to point out that=20 TURNs thin encapsulation does not support enough mechanisms to detect=20 protocol collisions to allow multiplexing protocols on the same port. Cheers Magnus Philip Matthews skrev: > During the conference call on Dec 20, we agreed to remove the TURN=20 > framing header before TURN control messages. >=20 > To allow the maximum number of channels, I would like to propose that=20 > TURN control messages be identified as having the leading two bits be=20 > "00", as is typically done with STUN messages. This leaves the other=20 > combination of bits for channel numbers. >=20 > That is, if the first two bits are: > 00 - TURN control message > 01 - TURN data packet > 10 - TURN data packet > 11 - TURN data packet >=20 > This means that channel numbers would run from 0x4000 to 0xFFFF, with=20 > 0xFFFF being a reserved channel number. This gives 49151 different=20 > channels. >=20 > Comments? >=20 > - Philip >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave >=20 --=20 Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------enigD304A2E6B1BEBDFD78893E17 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHkMaJqpZsSJeFbtkRAon0AJ4sPS9VH9cYcxHCUmzzS3RQynex0gCeMyE2 XX7JSfsrnDVUcns/anIKeVg= =o710 -----END PGP SIGNATURE----- --------------enigD304A2E6B1BEBDFD78893E17-- --===============2135545455== 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 --===============2135545455==-- From behave-bounces@ietf.org Fri Jan 18 10:39:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtJm-0007Er-RX; Fri, 18 Jan 2008 10:39:42 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFtJk-00075l-UH for behave-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 10:39:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtJk-00070i-FP for behave@ietf.org; Fri, 18 Jan 2008 10:39:40 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFtJj-0006b6-JE for behave@ietf.org; Fri, 18 Jan 2008 10:39:40 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id m0IFcjU16569; Fri, 18 Jan 2008 07:38:46 -0800 In-Reply-To: <96483AA0-7F26-494C-9931-19D9BAB0017D@magma.ca> References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <478E5883.5090606@acm.org> <4A3CAD0D-F58D-4EE2-B59A-04F463745D1D@magma.ca> <3C898AB6-05B8-4854-8E20-5E87B304F905@cisco.com> <96483AA0-7F26-494C-9931-19D9BAB0017D@magma.ca> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header Date: Fri, 18 Jan 2008 07:38:43 -0800 To: Philip Matthews X-Mailer: Apple Mail (2.753) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Rohan Mahy , 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 Philip, The DS codepoint can be network-dependent, but since DS codepoints are almost always reset to zero upon crossing an administrative domain boundary, the point is moot. If there is no TURN server, peer1 says use codepoint X and the traffic arrives at peer2 marked with zero. With a TURN server we could do the following things: 1) Have the TURN server explicitly use zero for all traffic. This is appropriate for a TURN server in the core of the public Internet. 2) Have the TURN server copy the codepoint set by the client to the traffic for the peer. In the core of the Internet, this will be copying zero to zero. If the client, peer, and TURN server are all in the same administrative domain and all in the same access network, it could cause the correct codepoint to be copied. Note that this case is highly unlikely. It won't happen in any service provider network that I am familiar with, and any enterprise network who was trying to be nice enough to install their own TURN server in the access network would probably just configure their firewall so the client could communicate with the peer (in the same enterprise) using local addressing or STUN instead. 3) Have the client indicate what codepoint to use and have the TURN server honor this. For a TURN server in the public Internet, this will allow the client to ask the server to mark traffic in the core of the network (where it is completely and utterly useless); the codepoint will then be remarked to zero before going to the peer's access network. As we saw in #2 this approach is equally useless in an enterprise setting. In summary, approach #1 is easy, approach #2 is useless, and approach #3 is useless. I vote for approach #1. thanks, -rohan On Jan 17, 2008, at 8:47 AM, Philip Matthews wrote: > On 17-Jan-08, at 11:33 , Cullen Jennings wrote: >> >> Hmm - I have no idea how I would implement "let the server set the >> DS bits appropriately". I think the DS bits are the indication of >> what type of traffic is. I'd be happier with the client told the >> relay the DS bits to use on the other side. But as long as it is >> clear how to implement this these seems like a possible path. > > Please correct me if I am wrong, but I seem to recall that the > exact DS codepoint for a given traffic type is network-dependent. > If I am correct, then the client cannot say to the server "use > codepoint X for my traffic", because the network in which the > server resides may use codepoint Y for that traffic type. So the > client needs to instead say "use the codepoint for VoIP traffic" > and that causes the server to use codepoint Y. > > Does this make any sense? > > - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 18 10:40:55 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtKx-0008Ba-N2; Fri, 18 Jan 2008 10:40:55 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFtKw-0008BV-8j for behave-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 10:40:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtKv-0008BN-U2 for behave@ietf.org; Fri, 18 Jan 2008 10:40:53 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFtKv-0006co-B5 for behave@ietf.org; Fri, 18 Jan 2008 10:40:53 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 653D4210C9; Fri, 18 Jan 2008 16:40:52 +0100 (CET) X-AuditID: c1b4fb3e-ad5edbb0000007e1-3b-4790c884e639 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 46644200BC; Fri, 18 Jan 2008 16:40:52 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 16:40:52 +0100 Received: from [127.0.0.1] ([147.214.30.230]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 16:40:51 +0100 Message-ID: <4790C87C.4030607@ericsson.com> Date: Fri, 18 Jan 2008 16:40:44 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [BEHAVE] TURN Issue #4: Port Adjacency References: <4759CC2B.9050206@cisco.com> <47620F8F.2060606@cisco.com> In-Reply-To: <47620F8F.2060606@cisco.com> X-Enigmail-Version: 0.95.6 X-OriginalArrivalTime: 18 Jan 2008 15:40:51.0943 (UTC) FILETIME=[81776770:01C859E8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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="===============0983288610==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0983288610== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB2C163BEDA2EA78CDE155889" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB2C163BEDA2EA78CDE155889 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Jonathan Rosenberg skrev: > The use case is communicating between an ICE agent and a non-ICE=20 > traditional Voip client, like a PSTN gateway. Those endpoints frequentl= y=20 > implement the old original 1889 and do RTP and RTCP on adjacent ports. = > Since ICE recommends TURN as the default candidate, when communicating = > with these peers, we'd be able to get RTCP. WIthout this feature, RTCP = > will not work. >=20 > There are still a LOT of endpoints in real deployment that assume=20 > RTP/RTCP port adjacency. >=20 Yes, port adjacency must work. Cheers Magnus Westerlund (with individual hat) IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------enigB2C163BEDA2EA78CDE155889 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHkMiDqpZsSJeFbtkRAv4eAJ9ZePRLF0WWCzrlqlnwqaowknR+fQCgl2It 29KXTOAoCBKzNbYCF3kThzg= =JrVV -----END PGP SIGNATURE----- --------------enigB2C163BEDA2EA78CDE155889-- --===============0983288610== 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 --===============0983288610==-- From behave-bounces@ietf.org Fri Jan 18 10:44:28 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtOO-00026e-76; Fri, 18 Jan 2008 10:44:28 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFtON-00026U-8D for behave-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 10:44:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtOM-00026L-TF for behave@ietf.org; Fri, 18 Jan 2008 10:44:26 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-06.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFtOM-0006kD-FU for behave@ietf.org; Fri, 18 Jan 2008 10:44:26 -0500 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JFtOL-0000af-03; Fri, 18 Jan 2008 10:44:25 -0500 In-Reply-To: <4790C67D.8030607@ericsson.com> References: <4759D19B.50005@cisco.com> <4760B1A0.6080807@cisco.com> <9B05C6FD-FF8A-4472-966E-D13C8573A9BF@magma.ca> <5D6A5A89-18B3-49A3-B852-EF0982730E35@magma.ca> <47620CD5.3010304@cisco.com> <4ECA60E2-558A-4EA8-8D08-53DCFE34C661@cisco.com> <30C5AFE6-C9FC-40FE-8A74-80B568FBD554@magma.ca> <1C97A587-D403-48D0-B086-584F7975FC31@cisco.com> <3E8D0268-A6CF-460B-827C-7358367FC961@magma.ca> <47685AF4.9030909@cisco.com> <1C6AF3B7-BB61-45B1-A2CA-C02EAFFB5B66@magma.ca> <4790C67D.8030607@ericsson.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <951756A8-E7C3-48C8-9C8A-2D359AB7700D@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages Date: Fri, 18 Jan 2008 10:45:06 -0500 To: Magnus Westerlund X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Rohan Mahy , 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 18-Jan-08, at 10:32 , Magnus Westerlund wrote: > Hi, > > Sorry for being this late in commenting on this. However, I wonder > if you are recreating a issue STUN was designed to avoid or not. > These two bits in STUN is 00 to avoid matching RTP. Thus, with the > proposed definition it is important that one never tries to > multiplex TURN and RTP on the same local port. I don't foresee any need to multiplex TURN and RTP. However, I do foresee carrying RTP inside TURN messages. > > I got worried as someone thought this change would allow running > STUN and TURN on the same local port. The change to remove the framing header from TURN message _would_ allow STUN and TURN to run on the same port. Recall that TURN is just an extension to STUN, so this is a pretty natural thing to do. In fact, the TURN Allocate Response message also carries the XOR-MAPPED- ADDRESS attribute, so there is no need to a Binding transaction if you do an Allocate transaction. > This implied for me that also RTP would be used on this same port. No. I don't see any need right now to multiplex TURN with any other protocol (other than STUN, which isn't really a multiplexing situation). > I think it is important to point out that TURNs thin encapsulation > does not support enough mechanisms to detect protocol collisions to > allow multiplexing protocols on the same port. I agree. We would have to give up a portion of the channel number space to make multiplexing possible, if this was needed. But as I said, I don't see a need for it right now. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 18 10:54:26 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtXz-0001RP-Iv; Fri, 18 Jan 2008 10:54:23 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFtXw-0001Q8-BR for behave-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 10:54:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtXv-0001Pi-Q9 for behave@ietf.org; Fri, 18 Jan 2008 10:54:19 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFtXu-00027D-7a for behave@ietf.org; Fri, 18 Jan 2008 10:54:19 -0500 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JFtXp-0008E8-0S; Fri, 18 Jan 2008 10:54:13 -0500 In-Reply-To: <478CE9AE.9080102@cisco.com> References: <478CE9AE.9080102@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3020DC10-80F2-4241-819C-D7B15A00A436@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue: How important are channels anyway? Date: Fri, 18 Jan 2008 10:55:09 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: Rohan Mahy , 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 It seems that everyone still wants the channel mechanism, despite the difficulties we are having in resolving the open issues around it. So the channel mechanism will be in TURN-06 (coming soon!). However, as noted below, the changes that we have agreed to have made in a non- core mechanism, so it is now presented after the other, more basic, parts of TURN. - Philip On 15-Jan-08, at 12:13 , Jonathan Rosenberg wrote: > Sorry for popping in late here... > > From the very, very beginning, it has been a requirement of TURN to > support a very low overhead encapsulation since RTP and voip in > particular has been its primary usage. I haven't seen anything that > indicates these requirements have changed. Efficiency of RTP has > been and continues to be an issue, driving work like SRTP (as > Cullen mentioned) and ROHC. > > I don't see any reason to revisit this design decision and think we > should continue our current course of providing a low-overhead > encapsulation. > > -Jonathan R. > > Cullen Jennings wrote: >> For the specific case of RTP over TURN, I think this is a >> requirement question better asked in AVT. There has been >> significant discussion of packet overhead when we came to the >> consensus that a new security protocol (SRTP) was needed instead >> of using RTP over an existing protocol such at TLS or IPSEC. I >> would encourage people to review how long that conversation went >> on last time we had it. >> On Jan 4, 2008, at 7:02 PM, Philip Matthews wrote: >>> The whole point of the TURN channel mechanism is to provide an >>> alternate encapsulation mechanism, one that has about 32 bytes >>> less overhead (over IPv4). Is this reduction in overhead important? >>> >>> Channels certainly add some complexity to TURN: the Framing >>> Header and the issues around its Length field and how-to-demux, >>> the ChannelBind method, and the yet-to-be-defined mechanism for >>> deallocating channels. About half of the issues we have been >>> discussing since Vancouver have been about the channel mechanism. >>> >>> There are a lot of other things out there today that add overhead >>> to a packet. Moving to IPv6, for example. Various tunneling >>> technologies inside the network, for another (MPLS, VPNs, IP >>> tunnels, ...). So perhaps an extra 32 bytes is not a killer. Or >>> perhaps the 32 bytes should be removed using other techniques: >>> compression techniques between a handset and its base station, >>> for example. >>> >>> Moreover, with the decision that TURN control messages are NOT >>> framed, channels are now cleanly separable from the rest of TURN. >>> Channels are very much an extra mechanism. So it would be easy to >>> add channels as an extension to TURN. >>> >>> So the question is: Is removing these 32 bytes important enough >>> to add channels to the base TURN specification (with the >>> consequent delays to the specification that this will inevitably >>> add), or should they be defined as an extension to TURN? >>> >>> Comments? >>> >>> - Philip >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > -- > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 18 11:04:23 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFthf-0007s6-4C; Fri, 18 Jan 2008 11:04:23 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFthe-0007rz-Ct for behave-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 11:04:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFthe-0007ro-30 for behave@ietf.org; Fri, 18 Jan 2008 11:04:22 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFthc-0002Iv-DH for behave@ietf.org; Fri, 18 Jan 2008 11:04:22 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D3B0E208F4; Fri, 18 Jan 2008 17:04:19 +0100 (CET) X-AuditID: c1b4fb3c-ad31ebb0000007e0-15-4790ce0326c0 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B6E1A20D71; Fri, 18 Jan 2008 17:04:19 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 17:04:19 +0100 Received: from [127.0.0.1] ([147.214.30.230]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 17:04:19 +0100 Message-ID: <4790CDFA.3000209@ericsson.com> Date: Fri, 18 Jan 2008 17:04:10 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <478E5883.5090606@acm.org> <4A3CAD0D-F58D-4EE2-B59A-04F463745D1D@magma.ca> <3C898AB6-05B8-4854-8E20-5E87B304F905@cisco.com> <96483AA0-7F26-494C-9931-19D9BAB0017D@magma.ca> In-Reply-To: X-Enigmail-Version: 0.95.6 X-OriginalArrivalTime: 18 Jan 2008 16:04:19.0530 (UTC) FILETIME=[C87422A0:01C859EB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Behave WG , Philip Matthews 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="===============1612423941==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1612423941== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFA8A6000A8471074FF6785DF" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFA8A6000A8471074FF6785DF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Rohan Mahy skrev: > Philip, >=20 > The DS codepoint can be network-dependent, but since DS codepoints are = > almost always reset to zero upon crossing an administrative domain=20 > boundary, the point is moot. If there is no TURN server, peer1 says=20 > use codepoint X and the traffic arrives at peer2 marked with zero. >=20 > With a TURN server we could do the following things: >=20 > 1) Have the TURN server explicitly use zero for all traffic. This is=20 > appropriate for a TURN server in the core of the public Internet. > 2) Have the TURN server copy the codepoint set by the client to the=20 > traffic for the peer. In the core of the Internet, this will be copyin= g=20 > zero to zero. > If the client, peer, and TURN server are all in the same administrative= =20 > domain and all in the same access network, it could cause the correct=20 > codepoint to be copied. Note that this case is highly unlikely. It=20 > won't happen in any service provider network that I am familiar with,=20 > and any enterprise network who was trying to be nice enough to install = > their own TURN server in the access network would probably just=20 > configure their firewall so the client could communicate with the peer = > (in the same enterprise) using local addressing or STUN instead. > 3) Have the client indicate what codepoint to use and have the TURN=20 > server honor this. For a TURN server in the public Internet, this will= =20 > allow the client to ask the server to mark traffic in the core of the=20 > network (where it is completely and utterly useless); the codepoint wil= l=20 > then be remarked to zero before going to the peer's access network. As= =20 > we saw in #2 this approach is equally useless in an enterprise setting.= >=20 > In summary, approach #1 is easy, approach #2 is useless, and approach #= 3=20 > is useless. I vote for approach #1. As an individual contributor: I am not agreeing with this conclusion that it is useless to preserver=20 DSCP. There clearly are cases where TURN will be deployed in an operator = or company network where it is desired to use diffserv and keep the=20 mappings that has been created. This at least applies for UDP to UDP=20 usage. It is likely to do so even TCP-UDP. So I don't think you get to=20 take the easy way out of this. I think approach 2 is the right one, as that will even work when TURN=20 client and server are in different AS with different realization of the=20 PHBs mapping to DSCP. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------enigFA8A6000A8471074FF6785DF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHkM4CqpZsSJeFbtkRAhOeAJ9dZVQPdfGmj7cKoC4EHuJFI+YhZACdEa5y R5u+cf9KRT6Xny7rWdVzNTU= =Oh51 -----END PGP SIGNATURE----- --------------enigFA8A6000A8471074FF6785DF-- --===============1612423941== 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 --===============1612423941==-- From behave-bounces@ietf.org Fri Jan 18 11:21:12 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtxv-0000H5-AW; Fri, 18 Jan 2008 11:21:11 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFtxt-0000Gx-Hz for behave-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 11:21:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtxt-0000Gm-6w for behave@ietf.org; Fri, 18 Jan 2008 11:21:09 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFtxs-0008Dw-FK for behave@ietf.org; Fri, 18 Jan 2008 11:21:09 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E03F720830; Fri, 18 Jan 2008 17:21:07 +0100 (CET) X-AuditID: c1b4fb3c-ad31ebb0000007e0-92-4790d1f380f8 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C024620C9F; Fri, 18 Jan 2008 17:21:07 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 17:21:07 +0100 Received: from [127.0.0.1] ([147.214.30.230]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 17:21:07 +0100 Message-ID: <4790D1EB.8070108@ericsson.com> Date: Fri, 18 Jan 2008 17:20:59 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Lars Eggert Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <478E5883.5090606@acm.org> In-Reply-To: X-Enigmail-Version: 0.95.6 X-OriginalArrivalTime: 18 Jan 2008 16:21:07.0039 (UTC) FILETIME=[20F9CEF0:01C859EE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Behave WG , Philip Matthews 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="===============1472725134==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1472725134== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF3005B71A9C3A32C04564188" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF3005B71A9C3A32C04564188 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Lars Eggert skrev: > On 2008-1-17, at 5:40, ext Cullen Jennings wrote: >> As far as requirements, I do believe we need be able to control the DF= =20 >> and TOS. >=20 > The bits that should be preserved across a TURN relay are the ones that= =20 > are important end-to-end. The DF bit isn't one of these, because the=20 > transport connections are terminated at the TURN relay, so it needs to = > diddle them according to what its local stack requires, for both relaye= d=20 > connections. >=20 I think we have some problem of being consistent if the relay are=20 resulting in two different transport connections or not, at least for=20 UDP. For UDP it would be good if it mostly was one end-to-end=20 connection. Especially in regards to congestion control. All congestion=20 or at least adaptation or rate limiting happens on the protocol above=20 UDP. To be able to handle a split transport connection correctly you=20 basically must know this protocol and be able to perform what ever=20 action on that level to correctly reflect what is happening. For UDP to UDP is is mostly copying the bits. In fact for some field=20 this will be required (DSCP) as they are only possible to interpret=20 within the current domain the packet is present in. A client can't know=20 what DSCP to set for the domain the TURN server is present in. DF bit=20 and the ICMP error resulting from fragmentation is problematic as the=20 TURN server should relay the ICMP message back. And if itself is=20 responsible for fragmentation due to adding the TURN encapsulation=20 header also generate ICMP towards the packet sender. For TCP-UDP this gets complicated as packet to packet mapping is not=20 likely to work. Also the congestion control part is interesting as=20 packets from UDP -> TCP can result in buffer overflow in the TURN=20 server. In fact I think it is important to recommend the TURN server to=20 not have a to large buffer here to actually cause these packet loss as=20 congestion indications. I think maintaining DSCP is one of the more=20 straightforward solutions. ECN is interesting, but I think a TURN server = needs to forward these markings somehow in the UDP->TCP direction. In=20 the other direction the problem doesn't exist as the client to server=20 TCP will take care of this and reduce the rate. The alternative is to=20 basically drop all arriving UDP packets which have the ECN field set to=20 Congestion Experienced (CE). So I don't think we have finished thinking about what to do with this one= =2E Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------enigF3005B71A9C3A32C04564188 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHkNHyqpZsSJeFbtkRAvBiAJ4pprBSz/OZrMlDMQbx2oq3DaIn7wCdEF2g U/rLDB3zPPudsys4oSd8dtg= =qCQ1 -----END PGP SIGNATURE----- --------------enigF3005B71A9C3A32C04564188-- --===============1472725134== 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 --===============1472725134==-- From behave-bounces@ietf.org Fri Jan 18 11:22:23 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtz5-0008UC-I6; Fri, 18 Jan 2008 11:22:23 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFtz3-0007ob-7s for behave-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 11:22:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtz2-0007dP-J0 for behave@ietf.org; Fri, 18 Jan 2008 11:22:20 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-06.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFtz1-0008FY-Vc for behave@ietf.org; Fri, 18 Jan 2008 11:22:20 -0500 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JFtym-0002xT-22; Fri, 18 Jan 2008 11:22:04 -0500 In-Reply-To: <4A3CAD0D-F58D-4EE2-B59A-04F463745D1D@magma.ca> References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <478E5883.5090606@acm.org> <4A3CAD0D-F58D-4EE2-B59A-04F463745D1D@magma.ca> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <37436CE7-7D28-4DB7-BA24-C34C1E2CBEF7@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header Date: Fri, 18 Jan 2008 11:23:00 -0500 To: Behave WG X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Rohan Mahy 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 am going to update my proposal slightly. I am now going to propose that the TURN server and the TURN client SHOULD always set the DF bit. This would allow Packetization Layer Path MTU Discovery [RFC 4821] to work. (Note that classic Path MTU Discovery won't work because TURN does not currently relay ICMP packets. ) To summarize the revised proposal: * There are two distinct connections: one from the client to the server, and a second from the server to the peer. * The ECN bits are set by the transport protocol used on each connection. For example, if TCP is used between the client and the server, then TCP sets the ECN bits on that connection, and these setting have nothing to do with how UDP sets the ECN bits on the connection between the server and a peer. * The DF bit SHOULD always be set by the client or the server when sending a packet. How the DiffServ bits are set is still under discussion. I originally proposed that the client should send some indication of traffic type to the server, which then determines an appropriate DiffServ Code Point (DSCP), which is then used for the lifetime of the connection (or at least, for a period of time and not per packet). Cullen doesn't see how this could work, and proposes that the client just tell the server which DSCP to use; again a single setting for the lifetime of the connection. And Rohan is now proposing that the server just always uses '000000'. From Remi's recent e-mail, it seems that any one of these variations could be easily implemented by a user-space implementation. Comments? In particular, are people happy with everything but the DiffServ bits part? - Philip On 17-Jan-08, at 09:14 , Philip Matthews wrote: > At its heart, this issue is about whether we see one end-to-end > connection between the client and the peer, or whether we see two > connections (client to server, and server to peer) with some > linkage between them. > > I originally subscribed to the first view, and had the idea that > the relay could be viewed as forwarding at the IP layer, not the > UDP layer. > > However, various things now make me think that the second view is > the correct view, with the support for TCP to UDP relaying being a > key point. > > If we adopt the second view, then I think the answer is that the > ECN and DF bits on the two connections are independent of each other. > > To see why I think this is the right choice, consider the TCP to > UDP relaying case. In this case, TCP is controlling the settings of > the ECN and DF bits on the TCP connection, while UDP is controlling > the setting of these bits on the UDP connection. I feel this is > especially obvious if you consider the case of a single TCP > connection to the server, but two or more UDP connections from the > server to two or more peers. > > Regarding the DS bits, I think the best solution is for the client > to send the server some indication of what type of traffic is being > transported, and let the server set the DS bits appropriately. Such > an indication would also be useful to the server when determining > whether to allow a new allocation. > > Specifically, I propose that: > > The transport layer used between the client and the server > will set the ECN, and DF bits as it sees fit, and similarly the > transport layer between the client and the peer will set the ECN > and DF bits as it sees fit. The client cannot influence or learn > the ECN and DF bits settings between the server and the peer. The > client will send the server an indication of the traffic type at > allocation time, and the server will use this to set the DS bits on > the server-to-peer connections (and perhaps on the server-to-client > connection as well). > > Comments? > > - Philip > > > > _______________________________________________ > 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 Fri Jan 18 11:24:20 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFu0y-0002Pj-7w; Fri, 18 Jan 2008 11:24:20 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFu0w-0002PT-CZ for behave-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 11:24:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFu0w-0002PL-2p for behave@ietf.org; Fri, 18 Jan 2008 11:24:18 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFu0v-0003Iv-HA for behave@ietf.org; Fri, 18 Jan 2008 11:24:18 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0628720527; Fri, 18 Jan 2008 17:24:17 +0100 (CET) X-AuditID: c1b4fb3c-aaaedbb0000007e0-63-4790d2b08fcf Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DD91E20E7B; Fri, 18 Jan 2008 17:24:16 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 17:24:16 +0100 Received: from [127.0.0.1] ([147.214.30.230]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 17:24:16 +0100 Message-ID: <4790D2AF.3060802@ericsson.com> Date: Fri, 18 Jan 2008 17:24:15 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages References: <4759D19B.50005@cisco.com> <4760B1A0.6080807@cisco.com> <9B05C6FD-FF8A-4472-966E-D13C8573A9BF@magma.ca> <5D6A5A89-18B3-49A3-B852-EF0982730E35@magma.ca> <47620CD5.3010304@cisco.com> <4ECA60E2-558A-4EA8-8D08-53DCFE34C661@cisco.com> <30C5AFE6-C9FC-40FE-8A74-80B568FBD554@magma.ca> <1C97A587-D403-48D0-B086-584F7975FC31@cisco.com> <3E8D0268-A6CF-460B-827C-7358367FC961@magma.ca> <47685AF4.9030909@cisco.com> <1C6AF3B7-BB61-45B1-A2CA-C02EAFFB5B66@magma.ca> <4790C67D.8030607@ericsson.com> <951756A8-E7C3-48C8-9C8A-2D359AB7700D@magma.ca> In-Reply-To: <951756A8-E7C3-48C8-9C8A-2D359AB7700D@magma.ca> X-Enigmail-Version: 0.95.6 X-OriginalArrivalTime: 18 Jan 2008 16:24:16.0460 (UTC) FILETIME=[91E128C0:01C859EE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: Rohan Mahy , 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="===============1197161899==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1197161899== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5C097391190DFB7EFF910CB7" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5C097391190DFB7EFF910CB7 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Okay, As long as this is clear. I think it will be required to point this out=20 as STUN is possible to multiplex with RTP. Cheers Magnus Philip Matthews skrev: >=20 > On 18-Jan-08, at 10:32 , Magnus Westerlund wrote: >=20 >> Hi, >> >> Sorry for being this late in commenting on this. However, I wonder if = >> you are recreating a issue STUN was designed to avoid or not. These=20 >> two bits in STUN is 00 to avoid matching RTP. Thus, with the proposed = >> definition it is important that one never tries to multiplex TURN and = >> RTP on the same local port. >=20 > I don't foresee any need to multiplex TURN and RTP. However, I do=20 > foresee carrying RTP inside TURN messages. >=20 >> >> I got worried as someone thought this change would allow running STUN = >> and TURN on the same local port. >=20 > The change to remove the framing header from TURN message _would_ allow= =20 > STUN and TURN to run on the same port. Recall that TURN is just an=20 > extension to STUN, so this is a pretty natural thing to do. In fact, th= e=20 > TURN Allocate Response message also carries the XOR-MAPPED-ADDRESS=20 > attribute, so there is no need to a Binding transaction if you do an=20 > Allocate transaction. >=20 >=20 >=20 >> This implied for me that also RTP would be used on this same port. > No. > I don't see any need right now to multiplex TURN with any other protoco= l=20 > (other than STUN, which isn't really a multiplexing situation). >=20 >> I think it is important to point out that TURNs thin encapsulation=20 >> does not support enough mechanisms to detect protocol collisions to=20 >> allow multiplexing protocols on the same port. >=20 > I agree. We would have to give up a portion of the channel number space= =20 > to make multiplexing possible, if this was needed. But as I said, I=20 > don't see a need for it right now. >=20 >=20 > - Philip >=20 --=20 Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------enig5C097391190DFB7EFF910CB7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHkNKvqpZsSJeFbtkRAplbAKCoy1qWDaQWYNvGLkKam2b90cwsrQCgosQg rrGdSuJ5ReJN0eBDBGXVFhk= =Y/lj -----END PGP SIGNATURE----- --------------enig5C097391190DFB7EFF910CB7-- --===============1197161899== 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 --===============1197161899==-- From behave-bounces@ietf.org Fri Jan 18 11:26:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFu2i-0002xt-D8; Fri, 18 Jan 2008 11:26:08 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFu2g-0002xf-SA for behave-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 11:26:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFu2g-0002xW-Gz for behave@ietf.org; Fri, 18 Jan 2008 11:26:06 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFu2f-0008Kp-TP for behave@ietf.org; Fri, 18 Jan 2008 11:26:06 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 52E8D20F3E; Fri, 18 Jan 2008 17:26:05 +0100 (CET) X-AuditID: c1b4fb3c-a92eabb0000007e0-db-4790d31d70b9 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3457F20BF7; Fri, 18 Jan 2008 17:26:05 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 17:26:05 +0100 Received: from [127.0.0.1] ([147.214.30.230]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 17:26:04 +0100 Message-ID: <4790D31B.5060501@ericsson.com> Date: Fri, 18 Jan 2008 17:26:03 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [BEHAVE] TURN Issue #5: Port Range References: <4759CD14.10208@cisco.com> <47630B03.3050708@cisco.com> <200801150931.19631.remi.denis-courmont@nokia.com> <36970DB3-7EA2-4807-9659-FA005B303C94@cisco.com> In-Reply-To: <36970DB3-7EA2-4807-9659-FA005B303C94@cisco.com> X-Enigmail-Version: 0.95.6 X-OriginalArrivalTime: 18 Jan 2008 16:26:04.0641 (UTC) FILETIME=[D25C4510:01C859EE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Behave WG , Philip Matthews 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="===============1112267930==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1112267930== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0327DD0A8B1F8C77154BE9FE" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0327DD0A8B1F8C77154BE9FE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cullen Jennings skrev: >=20 > On Jan 15, 2008, at 6:52 AM, Philip Matthews wrote: >=20 >> o The TURN server application believes, through some means not >> specified here, that firewalls between it and any peers are >> unlikely to block the port allocated. >=20 > I think you should drop all the text on firewalls - there is no more=20 > guarantee that port 49153 will get through any given firewall than port= =20 > 49150. The topic of the firewalls is an operation concern and not a=20 > protocol specification issue here - the fact that the firewall has to b= e=20 > configured to allow access to ports the TURN server needs to use barely= =20 > seems worth mentioning. The harm in this text is that it requires TURN= =20 > server to not use a large portion of the address space. I suspect you=20 > are going outside what Lars was looking for here - you might want to=20 > sync up with him. >=20 I think I have to agree with Cullen here. I supports Lars's=20 recommendation to first use the dynamic range. And I think the proposed=20 text minus the firewall related will be sufficient around this. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------enig0327DD0A8B1F8C77154BE9FE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHkNMcqpZsSJeFbtkRAlsqAJ9VDFYWrksG/AG0PkFU4HbgaNhaMACeNZHZ HeuiVfy60JiUek1SGBZqBvs= =fV/C -----END PGP SIGNATURE----- --------------enig0327DD0A8B1F8C77154BE9FE-- --===============1112267930== 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 --===============1112267930==-- From behave-bounces@ietf.org Fri Jan 18 11:37:55 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFuE6-0002CB-4E; Fri, 18 Jan 2008 11:37:54 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFuE3-0002C4-QN for behave-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 11:37:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFuE3-0002Br-FQ for behave@ietf.org; Fri, 18 Jan 2008 11:37:51 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFuE0-0000es-QV for behave@ietf.org; Fri, 18 Jan 2008 11:37:49 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id m0IGbEU17995; Fri, 18 Jan 2008 08:37:14 -0800 In-Reply-To: <4790CDFA.3000209@ericsson.com> References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <478E5883.5090606@acm.org> <4A3CAD0D-F58D-4EE2-B59A-04F463745D1D@magma.ca> <3C898AB6-05B8-4854-8E20-5E87B304F905@cisco.com> <96483AA0-7F26-494C-9931-19D9BAB0017D@magma.ca> <4790CDFA.3000209@ericsson.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header Date: Fri, 18 Jan 2008 08:37:13 -0800 To: Magnus Westerlund X-Mailer: Apple Mail (2.753) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Rohan Mahy , Behave WG , Philip Matthews 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 Magnus, I am still skeptical about this statement. Can you provide an example use case for this? > There clearly are cases where TURN will be deployed in an operator > or company network where it is desired to use diffserv and keep the > mappings that has been created. If there are indeed use cases for this, then maybe the TURN server can be configured to passthrough or to remark everything to zero. thanks, -rohan On Jan 18, 2008, at 8:04 AM, Magnus Westerlund wrote: > Rohan Mahy skrev: >> Philip, >> The DS codepoint can be network-dependent, but since DS codepoints >> are almost always reset to zero upon crossing an administrative >> domain boundary, the point is moot. If there is no TURN server, >> peer1 says use codepoint X and the traffic arrives at peer2 marked >> with zero. >> With a TURN server we could do the following things: >> 1) Have the TURN server explicitly use zero for all traffic. This >> is appropriate for a TURN server in the core of the public Internet. >> 2) Have the TURN server copy the codepoint set by the client to >> the traffic for the peer. In the core of the Internet, this will >> be copying zero to zero. >> If the client, peer, and TURN server are all in the same >> administrative domain and all in the same access network, it could >> cause the correct codepoint to be copied. Note that this case is >> highly unlikely. It won't happen in any service provider network >> that I am familiar with, and any enterprise network who was trying >> to be nice enough to install their own TURN server in the access >> network would probably just configure their firewall so the client >> could communicate with the peer (in the same enterprise) using >> local addressing or STUN instead. >> 3) Have the client indicate what codepoint to use and have the >> TURN server honor this. For a TURN server in the public Internet, >> this will allow the client to ask the server to mark traffic in >> the core of the network (where it is completely and utterly >> useless); the codepoint will then be remarked to zero before going >> to the peer's access network. As we saw in #2 this approach is >> equally useless in an enterprise setting. >> In summary, approach #1 is easy, approach #2 is useless, and >> approach #3 is useless. I vote for approach #1. > > As an individual contributor: > > I am not agreeing with this conclusion that it is useless to > preserver DSCP. There clearly are cases where TURN will be deployed > in an operator or company network where it is desired to use > diffserv and keep the mappings that has been created. This at least > applies for UDP to UDP usage. It is likely to do so even TCP-UDP. > So I don't think you get to take the easy way out of this. > > I think approach 2 is the right one, as that will even work when > TURN client and server are in different AS with different > realization of the PHBs mapping to DSCP. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 18 12:04:25 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFudk-0002Mt-19; Fri, 18 Jan 2008 12:04:24 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFudi-0002Mo-P6 for behave-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 12:04:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFudi-0002Mg-Em for behave@ietf.org; Fri, 18 Jan 2008 12:04:22 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-05.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFudi-0001Ll-3Y for behave@ietf.org; Fri, 18 Jan 2008 12:04:22 -0500 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JFucx-0007PL-2X for behave@ietf.org; Fri, 18 Jan 2008 12:03:36 -0500 Mime-Version: 1.0 (Apple Message framework v753) In-Reply-To: <4790D31B.5060501@ericsson.com> References: <4759CD14.10208@cisco.com> <47630B03.3050708@cisco.com> <200801150931.19631.remi.denis-courmont@nokia.com> <36970DB3-7EA2-4807-9659-FA005B303C94@cisco.com> <4790D31B.5060501@ericsson.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <612E2627-E9BA-494A-9C92-C59C886CEDC4@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #5: Port Range Date: Fri, 18 Jan 2008 12:05:14 -0500 To: Behave WG X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 number of people have now told me, either publicly or privately, that they would be happy with the text if I simply removed the discussion on firewalls. So here is my revised text: The server SHOULD only allocate ports from the range 49152 - 65535 (the Dynamic and/or Private Port range [Port-Numbers]), unless the TURN server application knows, through some means not specified here, that other applications running on the same host as the TURN server application will not be impacted by allocating ports outside this range. This condition can often be satisfied by running the TURN server application on a dedicated machine and/or by arranging that any other applications on the machine allocate ports before the TURN server application starts. In any case, the TURN server SHOULD NOT allocate ports in the range 0 - 1023 (the Well-Known Port range) to discourage clients from using TURN to run standard services. Comments? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 18 12:12:55 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFuly-0002zd-BR; Fri, 18 Jan 2008 12:12:54 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFulw-0002zE-IV for behave-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 12:12:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFulw-0002z4-44 for behave@ietf.org; Fri, 18 Jan 2008 12:12:52 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-07.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFulv-00052q-Nv for behave@ietf.org; Fri, 18 Jan 2008 12:12:52 -0500 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JFuls-0002Cs-1S; Fri, 18 Jan 2008 12:12:48 -0500 In-Reply-To: <73FE7DD2-615E-4DF6-AE85-38855EB2010A@cisco.com> References: <73FE7DD2-615E-4DF6-AE85-38855EB2010A@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <54804BBB-AB1E-4653-BC00-8477F08FBF2E@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue: Recommended Permission Lifetime Date: Fri, 18 Jan 2008 12:13:47 -0500 To: Cullen Jennings X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Rohan Mahy , 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 16-Jan-08, at 23:30 , Cullen Jennings wrote: > I agree - I think 5 min RECOMMENDED and MUST NOT be less than 2 > minutes would be good. I agree. So unless I hear any objections soon, this is what TURN-06 will say. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 18 12:41:40 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFvDm-0005JT-Dx; Fri, 18 Jan 2008 12:41:38 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFvDk-0005It-UK for behave-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 12:41:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFvDk-0005Ic-Iy for behave@ietf.org; Fri, 18 Jan 2008 12:41:36 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-02.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFvDk-0003N9-0W for behave@ietf.org; Fri, 18 Jan 2008 12:41:36 -0500 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JFvDj-0005hy-06 for behave@ietf.org; Fri, 18 Jan 2008 12:41:35 -0500 Mime-Version: 1.0 (Apple Message framework v753) In-Reply-To: <4790D2AF.3060802@ericsson.com> References: <4759D19B.50005@cisco.com> <4760B1A0.6080807@cisco.com> <9B05C6FD-FF8A-4472-966E-D13C8573A9BF@magma.ca> <5D6A5A89-18B3-49A3-B852-EF0982730E35@magma.ca> <47620CD5.3010304@cisco.com> <4ECA60E2-558A-4EA8-8D08-53DCFE34C661@cisco.com> <30C5AFE6-C9FC-40FE-8A74-80B568FBD554@magma.ca> <1C97A587-D403-48D0-B086-584F7975FC31@cisco.com> <3E8D0268-A6CF-460B-827C-7358367FC961@magma.ca> <47685AF4.9030909@cisco.com> <1C6AF3B7-BB61-45B1-A2CA-C02EAFFB5B66@magma.ca> <4790C67D.8030607@ericsson.com> <951756A8-E7C3-48C8-9C8A-2D359AB7700D@magma.ca> <4790D2AF.3060802@ericsson.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages Date: Fri, 18 Jan 2008 12:42:30 -0500 To: Behave WG X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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 Let me summarize what I believe is the current state of this issue. We have agreed that TURN control messages will _not_ use the framing header. Separately, we have also agreed to use EKRs mechanism to allocate channels. The combination of these two means that the "framing header" is only used for application data traveling on a channel. What this really means is that we have a new non-STUN- formatted message that carries application data. I am proposing to call this message a "ChannelData" message. So the point we are discussing now is how to distinguish a ChannelData message from a STUN-formatted message. Here the original proposal was to use the first bit of the message to distinguish the two: a STUN-formatted message has the first bit set to 0, and the ChannelData message has the first bit set to 1. My proposal is to instead use the first two bits. My reasoning is that the first two bits of a STUN message are always '00' and all other combinations can be used for the ChannelData message. To be precise, here is the text that I am proposing: The ChannelData message is used to carry application data between the client and the server. It has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Channel Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Application Data / / / | | | +-------------------------------+ | | +-------------------------------+ The Channel Number field specifies the number of the channel on which the data is traveling, and thus the address of the peer that is sending or is to receive the data. The channel number MUST be in the range 0x4000 - 0xFFFF, with channel number 0xFFFF being reserved for possible future extensions. Channel numbers 0x0000 - 0x3FFF cannot be used because bits 0 and 1 are used to distinguish ChannelData messages from STUN-formatted messages (i.e., Allocate, Send, Data, ChannelBind, etc). STUN- formatted messages always have bits 0 and 1 as "00", while ChannelData messages use combinations "01", "10", and "11". In discussing how to distinguish ChannelData messages from STUN- formatted messages, the following issues have been raised: * (Derek) It is easier to look at just one bit, rather than two bits. * (Cullen) How many channels do we need anyway? Why do we need more than 200 channels? In addition, there is the question of whether we need a way to de- allocate channels. During the conf call of 20 Dec, there was agreement amongst the participants that such a mechanism was required, but so far no mechanism has been proposed yet. Right now, my intention is to put the above text into TURN-06 and then flag three open issues: 1) What is the exact format of the ChannelData message? 2) How many channels do we need? 3) Do we need a mechanism to release channels, and if so, what does it look like? My personal opinion on #3 is now leaning to "YES", but I haven't had a chance to propose a mechanism yet. Comments? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 18 15:40:30 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFy0p-0000kB-2g; Fri, 18 Jan 2008 15:40:27 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFy0n-0000k5-Qy for behave-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 15:40:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFy0n-0000jx-H6 for behave@ietf.org; Fri, 18 Jan 2008 15:40:25 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFy0m-000605-Qj for behave@ietf.org; Fri, 18 Jan 2008 15:40:25 -0500 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JFy0m-00050x-34 for behave@ietf.org; Fri, 18 Jan 2008 15:40:25 -0500 Mime-Version: 1.0 (Apple Message framework v753) In-Reply-To: <4759D32F.8010304@cisco.com> References: <4759D32F.8010304@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2CB7A2B9-B19B-48FA-8AE8-7300F17FF1ED@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #7: Framing header length Date: Fri, 18 Jan 2008 15:41:18 -0500 To: Behave WG X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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 updated the document to reflect this decision, as well as fixed a minor related point. Below is the new text. Note that I have renamed the TURN framing header to the ChannelData message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Channel Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Application Data / / / | | | +-------------------------------+ | | +-------------------------------+ [SNIP] The Length field specifies the length in bytes of the application data field (i.e., it does not include the size of the ChannelData header). Note that 0 is a valid length. AND Over stream transports, the ChannelData message MUST be padded to a multiple of four bytes in order to ensure the alignment of subsequent messages. The padding is not reflected in the length field of the ChannelData message, so the actual size of a ChannelData message (including padding) is (4 + Length) rounded up to the nearest multiple of 4. Over UDP, the padding is not required but MAY be included. AND If the ChannelData message is received in a UDP datagram, and if the UDP datagram is too short to contain the claimed length of the ChannelData message (i.e., the UDP header length field value is less than the ChannelData header length field value + 4 + 8), then the message is silently discarded. If the ChannelData message is received over TCP or over TLS over TCP, then the actual length of the ChannelData message is as described in Section 7.5. Comments? - Philip On 7-Dec-07, at 18:11 , Jonathan Rosenberg wrote: > This was not in my slides. It was raised at the mike at the WG > session, discussed briefly at the WG meeting and again briefly at > the end of the ad-hoc. > > The current TURN framing header looks like: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > | Channel | Message > Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > > When TURN is running over UDP, the length header is redundant. The > current spec says to set it to zero. The issue was raised that, it > would be better to set it to to be the correct length, rather than > zero. The drawback of setting it to the correct length, is it > introduces an error condition. What happens if it doesn't match the > actual UDP length? Do we truncate (assuming the actual UDP packet > size is larger than the TURN header message length)? Or just discard? > > The point raised at the ad-hoc later, was that even if you set it > to zero, you still have the error condition, what if its not zero. > It was also pointed out, by setting the length we get the framing > header consistent between UDP and TCP. > > So there was rough agreement at the ad-hoc, to change turn so that > the message length is the actual message length, even over UDP. If > it mismatches the actual UDP message length, then the packet MUST > be discarded in error. > > Please comment as to whether you agree (or disagree) with this > conclusion. > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > 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 Fri Jan 18 15:53:39 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFyDb-00042x-Ad; Fri, 18 Jan 2008 15:53:39 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JFyDa-00042O-3r for behave-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 15:53:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFyDZ-00042G-PS for behave@ietf.org; Fri, 18 Jan 2008 15:53:37 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFyDZ-00049M-G3 for behave@ietf.org; Fri, 18 Jan 2008 15:53:37 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 18 Jan 2008 12:53:37 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m0IKraAF002080; Fri, 18 Jan 2008 12:53:36 -0800 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m0IKrMsj026214; Fri, 18 Jan 2008 20:53:27 GMT From: "Dan Wing" To: "'Philip Matthews'" , "'Cullen Jennings'" References: <73FE7DD2-615E-4DF6-AE85-38855EB2010A@cisco.com> <54804BBB-AB1E-4653-BC00-8477F08FBF2E@magma.ca> Subject: RE: [BEHAVE] TURN Issue: Recommended Permission Lifetime Date: Fri, 18 Jan 2008 12:53:22 -0800 Message-ID: <016001c85a14$31ef20e0$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchZ9WZnd56Uu4m/Qzi73zZYW7xVLQAHp9gg In-Reply-To: <54804BBB-AB1E-4653-BC00-8477F08FBF2E@magma.ca> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=380; t=1200689616; x=1201553616; c=relaxed/simple; s=sjdkim3002; 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:=20RE=3A=20[BEHAVE]=20TURN=20Issue=3A=20Recommende d=20Permission=20Lifetime |Sender:=20; bh=q69EhOcKm1D3yjJ4cZs7amfaOpMCFPGmWLJUDYv/DSs=; b=qtvq4W5UOI1XwjAwdJ3l8Q0oVYDQguxDUpmyIgBM1uzKTrPVTcnQKwUbKx YMANM3fj7KtMHrj+isemKx5YpnAVuY7R/s1RZdUXLXLXbeTyEpr54bjBAg7P i2+CCQ85Ix; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: 'Rohan Mahy' , '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 16-Jan-08, at 23:30 , Cullen Jennings wrote: > > I agree - I think 5 min RECOMMENDED and MUST NOT be less than 2 > > minutes would be good. > > I agree. So unless I hear any objections soon, this is what TURN-06 > will say. There is a signaling protocol (TURN). Why not have the TURN server indicate its default if it is anything other than 5 minutes. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 18 18:00:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JG0CP-0006yy-B0; Fri, 18 Jan 2008 18:00:33 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JG0CO-0006ys-91 for behave-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 18:00:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JG0CN-0006yk-UQ for behave@ietf.org; Fri, 18 Jan 2008 18:00:31 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-09.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JG0CN-00073m-Ip for behave@ietf.org; Fri, 18 Jan 2008 18:00:31 -0500 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JG0CL-0007nL-2k; Fri, 18 Jan 2008 18:00:29 -0500 Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Fri, 18 Jan 2008 18:01:25 -0500 To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Behave WG Subject: [BEHAVE] TURN Issue: Re-using the 5-tuple 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 19-Dec-07, at 10:14 , Marc Petit-Huguenin wrote: > There is no explanation on what can be done after an allocation > expires. > Is it possible to create a new one from the same source IP and port? > With the same username/realm/password? > Ignoring for now what it says in the document, I don't see any reason right now why this shouldn't work. If the allocation is expired, then it seems to be that all state concerning the allocation should be released. So, if one second later, the TURN server receives an Allocate Request using the same 5- tuple as the just released allocation, then it should create a new allocation. Of course, it is fairly unlikely that the server will allocate the same relayed transport address. Anyone see any problems with this? There should not be any problems with this happening accidently since the client must use Refresh instead of Allocate for refreshes. Comments? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 18 18:10:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JG0Lp-0005EG-Bp; Fri, 18 Jan 2008 18:10:17 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JG0Lo-0005EB-8m for behave-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 18:10:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JG0Ln-0005E3-VI for behave@ietf.org; Fri, 18 Jan 2008 18:10:15 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JG0Ln-0000EX-Kw for behave@ietf.org; Fri, 18 Jan 2008 18:10:15 -0500 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JG0Lm-0004hK-39; Fri, 18 Jan 2008 18:10:15 -0500 Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Fri, 18 Jan 2008 18:11:11 -0500 To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Behave WG Subject: [BEHAVE] TURN Issue: Changing the password during the lifetime of an allocation 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 19-Dec-07, at 10:14 , Marc Petit-Huguenin wrote: > > 19. Section 6.2.2 paragraph 2: "First, the request MUST be > authenticated using the same shared secret as the one associated with > the allocation." > > What happen if the user password is changed during an allocation? > I vaguely recall that we (the authors) discussed this question while we were working on TURN-05. Unfortunately, I cannot recall what we decided ... ;-) Do people want the ability to change the password during the lifetime of an allocation? (Or, for example, is it sufficient to simply force the client to create a new allocation? Assuming the answer is yes, then will the following scheme suffice? * To change the password, the server is configured with two passwords: the old and the new. While so configured, it will accept either. * The new password is then configured on the client, who immediately starts using the new password. * Eventually the old password is removed from the server. If this scheme is sufficient, then a sentence or two to mention it is all we need to do. Comments? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 18 19:18:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JG1QA-000510-6K; Fri, 18 Jan 2008 19:18:50 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JG1Q8-00050s-A8 for behave-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 19:18:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JG1Q8-00050j-01 for behave@ietf.org; Fri, 18 Jan 2008 19:18:48 -0500 Received: from server.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JG1Q6-0001Kd-HD for behave@ietf.org; Fri, 18 Jan 2008 19:18:47 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id DF612F9CC1F8; Fri, 18 Jan 2008 16:18:45 -0800 (PST) Received: from [192.168.1.3] (c-71-202-183-123.hsd1.ca.comcast.net [71.202.183.123]) by server.implementers.org (Postfix) with ESMTP id 214DCF9CC1F6; Fri, 18 Jan 2008 16:18:43 -0800 (PST) Message-ID: <479141E2.2060403@acm.org> Date: Fri, 18 Jan 2008 16:18:42 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080109) MIME-Version: 1.0 To: Philip Matthews References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Behave WG Subject: [BEHAVE] Re: TURN Issue: Re-using the 5-tuple 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 Philip Matthews wrote: > > On 19-Dec-07, at 10:14 , Marc Petit-Huguenin wrote: >> There is no explanation on what can be done after an allocation expires. >> Is it possible to create a new one from the same source IP and port? >> With the same username/realm/password? >> > > Ignoring for now what it says in the document, I don't see any reason > right now why this shouldn't work. > > If the allocation is expired, then it seems to be that all state > concerning the allocation should be released. So, if one second later, > the TURN server receives an Allocate Request using the same 5-tuple as > the just released allocation, then it should create a new allocation. Of > course, it is fairly unlikely that the server will allocate the same > relayed transport address. "fairly unlikely" is short for "It will only happen when you demo your product in front of a full room". > > Anyone see any problems with this? There should not be any problems with > this happening accidently since the client must use Refresh instead of > Allocate for refreshes. > I think that this is the right thing to do, I just wanted be sure that it was explicitly said in the I-D that a new allocation can be created in this case, eventually with a different username/realm/password. Thanks. -- 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 Fri Jan 18 19:33:05 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JG1du-0005CU-Ar; Fri, 18 Jan 2008 19:33:02 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JG1ds-0005CK-K7 for behave-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 19:33:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JG1ds-0005CC-AT for behave@ietf.org; Fri, 18 Jan 2008 19:33:00 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JG1ds-0001WK-0T for behave@ietf.org; Fri, 18 Jan 2008 19:33:00 -0500 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JG1dh-00060I-00; Fri, 18 Jan 2008 19:32:59 -0500 In-Reply-To: <479141E2.2060403@acm.org> References: <479141E2.2060403@acm.org> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <34CB4473-5256-4571-AFBD-F807DCD4DD8A@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Fri, 18 Jan 2008 19:33:41 -0500 To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Behave WG Subject: [BEHAVE] Re: TURN Issue: Re-using the 5-tuple 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 18-Jan-08, at 19:18 , Marc Petit-Huguenin wrote: > Philip Matthews wrote: >> >> On 19-Dec-07, at 10:14 , Marc Petit-Huguenin wrote: >>> There is no explanation on what can be done after an allocation >>> expires. >>> Is it possible to create a new one from the same source IP and port? >>> With the same username/realm/password? >>> >> >> Ignoring for now what it says in the document, I don't see any reason >> right now why this shouldn't work. >> >> If the allocation is expired, then it seems to be that all state >> concerning the allocation should be released. So, if one second >> later, >> the TURN server receives an Allocate Request using the same 5- >> tuple as >> the just released allocation, then it should create a new >> allocation. Of >> course, it is fairly unlikely that the server will allocate the same >> relayed transport address. > > "fairly unlikely" is short for "It will only happen when you demo your > product in front of a full room". Just don't have any expectations about which relayed transport address you get back and everything should be ok. > >> >> Anyone see any problems with this? There should not be any >> problems with >> this happening accidently since the client must use Refresh >> instead of >> Allocate for refreshes. >> > > I think that this is the right thing to do, I just wanted be sure that > it was explicitly said in the I-D that a new allocation can be created > in this case, eventually with a different username/realm/password. Right now, it is in as an open issue. If I get time over the weekend, I will make sure the text reflects this. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 18 19:40:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JG1lO-0005rY-F3; Fri, 18 Jan 2008 19:40:46 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JG1lN-0005rC-6N for behave-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 19:40:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JG1lM-0005qv-Sm for behave@ietf.org; Fri, 18 Jan 2008 19:40:44 -0500 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 1JG1lK-0001fu-NE for behave@ietf.org; Fri, 18 Jan 2008 19:40:44 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 18 Jan 2008 16:40:42 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0J0eg2e005650; Fri, 18 Jan 2008 16:40:42 -0800 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0J0efnj017568; Sat, 19 Jan 2008 00:40:41 GMT From: "Dan Wing" To: "'Philip Matthews'" , "'Marc Petit-Huguenin'" References: Subject: RE: [BEHAVE] TURN Issue: Changing the password during the lifetime ofan allocation Date: Fri, 18 Jan 2008 16:40:41 -0800 Message-ID: <026e01c85a33$eb79f750$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchaJ2cZulwb4vr+RDGj9X82xyD2mwADDEuA In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=639; t=1200703242; x=1201567242; 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:=20RE=3A=20[BEHAVE]=20TURN=20Issue=3A=20Changing=2 0the=20password=20during=20the=20lifetime=20ofan=20allocatio n |Sender:=20; bh=KLoCSrbkr+UZ1fTT1a95bRbVSgQrko/mIEdJ1+eNgcs=; b=a9URbyFWYLOLZjAXH+zGjf/eTQlkTk8tDJJFdnWdSqkRUtFsL/eE0D0VKu Qe5e9ZANTWG7Kph7y+KJqIeXZSzCEFxrfiJd00QvVC/Qj9NjKV49FaENl2dA b53KtQHIDf; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 19-Dec-07, at 10:14 , Marc Petit-Huguenin wrote: > > > > 19. Section 6.2.2 paragraph 2: "First, the request MUST be > > authenticated using the same shared secret as the one > > associated with the allocation." > > > > What happen if the user password is changed during an allocation? > > > > I vaguely recall that we (the authors) discussed this question while > we were working on TURN-05. Unfortunately, I cannot recall what we > decided ... ;-) The same thing should occur for TURN that occurs when your password is changed with other protocols (HTTP, IMAP, POP, SMTP AUTH): leave it undefined. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 18 19:52:05 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JG1wK-0003bO-FT; Fri, 18 Jan 2008 19:52:04 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JG1wJ-0003Zh-7s for behave-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 19:52:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JG1wI-0003Z9-UJ for behave@ietf.org; Fri, 18 Jan 2008 19:52:02 -0500 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 1JG1wI-000351-Fe for behave@ietf.org; Fri, 18 Jan 2008 19:52:02 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 18 Jan 2008 16:52:02 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m0J0q1gJ025567; Fri, 18 Jan 2008 16:52:01 -0800 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m0J0pxsj002957; Sat, 19 Jan 2008 00:52:00 GMT From: "Dan Wing" To: "'Philip Matthews'" , "'Marc Petit-Huguenin'" References: Subject: RE: [BEHAVE] TURN Issue: Re-using the 5-tuple Date: Fri, 18 Jan 2008 16:51:58 -0800 Message-ID: <027801c85a35$8078b520$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchaJf59P8o5UoyuRga3+ijujm8TNgADkUZg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2375; t=1200703921; x=1201567921; c=relaxed/simple; s=sjdkim4002; 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:=20RE=3A=20[BEHAVE]=20TURN=20Issue=3A=20Re-using=2 0the=205-tuple |Sender:=20; bh=PT/mbu9DqO7OKQzu1DWK8o6KBeafx3k4aU/OU+itv5k=; b=P6PA5fXCldzSfA946ZQdDJS/hhsjPkWr9vB2Z6LzEcBxAgtwPcvL74Bqmt mbqByDLPMj6qGggc38nKiqkbU9RiPeBZlQ+kiCP34HwZS8NDfAuzfClXZPMP Vlg2bghFyy; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 19-Dec-07, at 10:14 , Marc Petit-Huguenin wrote: > > There is no explanation on what can be done after an allocation > > expires. > > Is it possible to create a new one from the same source IP and port? > > With the same username/realm/password? > > > > Ignoring for now what it says in the document, I don't see > any reason right now why this shouldn't work. > > If the allocation is expired, then it seems to be that all state > concerning the allocation should be released. So, if one second > later, the TURN server receives an Allocate Request using the same 5- > tuple as the just released allocation, then it should create a new > allocation. Of course, it is fairly unlikely that the server will > allocate the same relayed transport address. > > Anyone see any problems with this? draft-ietf-tsvwg-udp-guidelines-04 describes a concern with immediately re-using the same socket: When an application closes a TCP, SCTP or DCCP socket, the transport protocol on the receiving host is required to maintain TIME-WAIT state. This prevents delayed packets from the closed connection instance from being mistakenly associated with a later connection instance that happens to reuse the same IP address and port pairs. The UDP protocol does not implement such a mechanism. Therefore, UDP-based applications need to robust to this case. One application may close a socket or terminate, followed in time by another application receiving on the same port. This later application may then receive packets intended for the first application that were delayed in the network. I think some text to that point would be useful, something like: When the TURN server allocates an IP and UDP port, that transport address SHOULD remain unusable for two minutes after it is freed. This is to avoid packets delayed in the network from a previous session from being sent to a new TURN client [I-D.ietf-tsvwg-udp-guidelines]. -d > There should not be any problems > with this happening accidently since the client must use Refresh > instead of Allocate for refreshes. > > Comments? > > - Philip > > > > > _______________________________________________ > 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 Jan 21 00:06:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGos1-0001bx-Pj; Mon, 21 Jan 2008 00:06:53 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JGos1-0001bs-1Q for behave-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 00:06:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGos0-0001bk-LN for behave@ietf.org; Mon, 21 Jan 2008 00:06:52 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGos0-0001mR-7T for behave@ietf.org; Mon, 21 Jan 2008 00:06:52 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 20 Jan 2008 21:06:51 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m0L56pJ8020082; Sun, 20 Jan 2008 21:06:51 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0L56kiX005640; Mon, 21 Jan 2008 05:06:46 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Jan 2008 21:06:46 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Jan 2008 21:06:44 -0800 Message-ID: <47942854.6090507@cisco.com> Date: Mon, 21 Jan 2008 00:06:28 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dan Wing Subject: Re: [BEHAVE] TURN Issue: Recommended Permission Lifetime References: <73FE7DD2-615E-4DF6-AE85-38855EB2010A@cisco.com> <54804BBB-AB1E-4653-BC00-8477F08FBF2E@magma.ca> <016001c85a14$31ef20e0$c3f0200a@cisco.com> In-Reply-To: <016001c85a14$31ef20e0$c3f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jan 2008 05:06:45.0096 (UTC) FILETIME=[6B048680:01C85BEB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1059; t=1200892011; x=1201756011; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20Issue=3A=20Recommende d=20Permission=20Lifetime |Sender:=20; bh=g5YfR7UhOuv2/gDXvUXIcfbJ3a7p2Sn1+4tCGG7oH7Q=; b=D7Q5392LS0lFFXjnmb6wN4QPCWU6vJT02eZJX1gap3EYzEw7aWfwrLknxP mPsbvuDnSZ/vEAUv+PZfvEBPWZ6B4k/DMB8drlc/kaXv+X9L7RVpkTtiJp1Z OuRM4w08hA; 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: 97adf591118a232206bdb5a27b217034 Cc: 'Rohan Mahy' , 'Behave WG' , 'Philip Matthews' 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 think we agreed to not handle signaling of permission lifetimes, since that capability doesn't exist for NAT either. If SAFE happens and we get a mechanism then we can use it for turn too. -Jonathan R. Dan Wing wrote: >> On 16-Jan-08, at 23:30 , Cullen Jennings wrote: >>> I agree - I think 5 min RECOMMENDED and MUST NOT be less than 2 >>> minutes would be good. >> I agree. So unless I hear any objections soon, this is what TURN-06 >> will say. > > There is a signaling protocol (TURN). Why not have the TURN > server indicate its default if it is anything other than 5 > minutes. > > -d > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 21 02:24:11 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGr0p-0006eA-Is; Mon, 21 Jan 2008 02:24:07 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JGr0o-0006e5-Kv for behave-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 02:24:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGr0n-0006dx-NF for behave@ietf.org; Mon, 21 Jan 2008 02:24:05 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGr0n-0005mg-AX for behave@ietf.org; Mon, 21 Jan 2008 02:24:05 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0L7P0IW030150 for ; Mon, 21 Jan 2008 01:25:03 -0600 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jan 2008 09:23:18 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jan 2008 09:23:05 +0200 Received: from esdhcp04076.research.nokia.com ([172.21.40.76]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jan 2008 09:22:23 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] TURN Issue: Changing the password during the lifetime ofan allocation Date: Mon, 21 Jan 2008 09:22:33 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <026e01c85a33$eb79f750$c3f0200a@cisco.com> In-Reply-To: <026e01c85a33$eb79f750$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200801210922.33266.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 21 Jan 2008 07:22:23.0486 (UTC) FILETIME=[5DE049E0:01C85BFE] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Saturday 19 January 2008 02:40:41 ext Dan Wing, vous avez =E9crit=A0: > > On 19-Dec-07, at 10:14 , Marc Petit-Huguenin wrote: > > > 19. Section 6.2.2 paragraph 2: "First, the request MUST be > > > authenticated using the same shared secret as the one > > > associated with the allocation." > > > > > > What happen if the user password is changed during an allocation? > > > > I vaguely recall that we (the authors) discussed this question while > > we were working on TURN-05. Unfortunately, I cannot recall what we > > decided ... ;-) > > The same thing should occur for TURN that occurs when your password is > changed with other protocols (HTTP, IMAP, POP, SMTP AUTH): leave it > undefined. Agreed. I expect authentication will be offloaded to some kind of database= =20 subsystem mostly independent from the TURN server, especially as TURN has=20 been designed to share credentials with SIP. I miss the fact that I cannot use plaintext password over encrypted TLS by = the=20 way :( This prevent use of TURN with password database using different type= s=20 of hashes for storage, especially those that cannot be "stolen" from the=20 server. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 21 02:26:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGr2g-0000aa-Ds; Mon, 21 Jan 2008 02:26:02 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JGr2f-0000aU-9w for behave-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 02:26:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGr2e-0000aM-Vw for behave@ietf.org; Mon, 21 Jan 2008 02:26:01 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGr2e-0004So-Di for behave@ietf.org; Mon, 21 Jan 2008 02:26:00 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0L7PMw1021963; Mon, 21 Jan 2008 09:25:57 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jan 2008 09:25:56 +0200 Received: from esdhcp04076.research.nokia.com ([172.21.40.76]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jan 2008 09:25:55 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Philip Matthews" Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header Date: Mon, 21 Jan 2008 09:26:05 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <200801181029.42562.remi.denis-courmont@nokia.com> <1A39E432-A9EA-43E9-BAE4-3C179C281432@magma.ca> In-Reply-To: <1A39E432-A9EA-43E9-BAE4-3C179C281432@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200801210926.05908.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 21 Jan 2008 07:25:55.0716 (UTC) FILETIME=[DC600440:01C85BFE] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 Le Friday 18 January 2008 16:49:37 ext Philip Matthews, vous avez =E9crit= =A0: > On 18-Jan-08, at 03:29 , R=E9mi Denis-Courmont wrote: > > What are the DS bits? > > The DS bits are the DiffServ bits. > The old TOS field in the IP header has now been divided into a 6-bit > DiffServ field and a 2-bit ECN field. In that case, getting/setting the ECN bits is as easy/difficult as=20 getting/setting the DSCP bits. You can use the TOS API in both cases. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 21 08:27:07 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGwg5-0002Dz-F4; Mon, 21 Jan 2008 08:27:05 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JGwg2-0002Dr-MH for behave-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 08:27:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGwg2-0002Dj-CT for behave@ietf.org; Mon, 21 Jan 2008 08:27:02 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-02.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGwg0-0005G1-Nx for behave@ietf.org; Mon, 21 Jan 2008 08:27:02 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JGwfw-0007Gt-1D; Mon, 21 Jan 2008 08:26:56 -0500 In-Reply-To: <4790C87C.4030607@ericsson.com> References: <4759CC2B.9050206@cisco.com> <47620F8F.2060606@cisco.com> <4790C87C.4030607@ericsson.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #4: Port Adjacency Date: Mon, 21 Jan 2008 08:27:58 -0500 To: Behave WG X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Rohan Mahy 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 discussion on this point has been fairly quiet recently, so let me try to summarize where we are at and make a proposal for how to resolve this issue. I am definitely not an RTP expert, but here is what I understand to be the use-case for this feature. Please correct me if I am wrong. Say X and Y are SIP UAs that want to communicate. Y is an old endpoint that does RFC 1889 and expects RTCP on the next-higher port and does not signal this fact. If X is behind a NAT (any type of NAT!) and Y has a public IP address, then X and Y can communicate and use both RTP and RTCP only if X allocates two adjacent ports on a TURN server with a public IP address. As far as I can see, if Y is behind a NAT, then there is no easy way to get this to work, because Y's NAT will most likely map Y's ports to non-adjacent ports and there is no easy way to determine what Y's RTCP port was mapped to. Given the above use-case and the fact that some people want to support it, then here is my proposal to resolve this issue: In an Allocate Request, a client can request that the server reserve the next-higher port number. The server may or may not be able to do this; for example, the server may not support this feature, or the server may support it but be unable to find two adjacent ports. When the server is not able to reserve the next- higher port, the server returns an error code and thus the allocation attempt fails. At this point, the client may give up and try a different server, or it may decided to retry without the request to reserve the next-higher port. If the server IS able to reserve the next-higher port, then it keeps this reservation until (a) a client request that exact port number, or (b) the lower-numbered allocation expires. In case (a), this is hopefully the client that reserved the lower-numbered port. The only drawback I can see with this is that clients will need code to retry the request if they are willing to proceed without the reserved next-higher port. Thus this will cause some delay in gathering ICE candidates. If this is seen as a big problem, then the alternative would be for the server to do the allocation and return a flag saying that it was not able to reserve the next-higher port. However, I don't really like this since REQUESTED-PORT-PROPS can be used to request other properties and it is not very clear how to generalize this (e.g., if you request an odd port, can the server allocate an even one and say "sorry but I could only find an even one to allocate"?). Comments on the use-case or the proposal? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 21 08:36:09 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGwor-0007ZY-Ei; Mon, 21 Jan 2008 08:36:09 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JGwoq-0007ZT-VQ for behave-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 08:36:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGwoq-0007ZK-LV for behave@ietf.org; Mon, 21 Jan 2008 08:36:08 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-05.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGwoq-0005V5-5h for behave@ietf.org; Mon, 21 Jan 2008 08:36:08 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JGwo5-00030S-14; Mon, 21 Jan 2008 08:35:21 -0500 In-Reply-To: <027801c85a35$8078b520$c3f0200a@cisco.com> References: <027801c85a35$8078b520$c3f0200a@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0373EA89-62FF-4ABA-9D60-40CFED215F70@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue: Re-using the 5-tuple Date: Mon, 21 Jan 2008 08:37:10 -0500 To: Dan Wing X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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 Just to be clear, I think we are talking about two slightly different things here. Marc was talking about the 5-tuple (client's IP address, client's port, server's IP address, server's port, transport), while you are talking about the relayed transport address. Never-the-less, I think your comment is a good one and will add it to the document. - Philip On 18-Jan-08, at 19:51 , Dan Wing wrote: > >> On 19-Dec-07, at 10:14 , Marc Petit-Huguenin wrote: >>> There is no explanation on what can be done after an allocation >>> expires. >>> Is it possible to create a new one from the same source IP and port? >>> With the same username/realm/password? >>> >> >> Ignoring for now what it says in the document, I don't see >> any reason right now why this shouldn't work. >> >> If the allocation is expired, then it seems to be that all state >> concerning the allocation should be released. So, if one second >> later, the TURN server receives an Allocate Request using the same 5- >> tuple as the just released allocation, then it should create a new >> allocation. Of course, it is fairly unlikely that the server will >> allocate the same relayed transport address. >> >> Anyone see any problems with this? > > draft-ietf-tsvwg-udp-guidelines-04 describes a concern with > immediately re-using the same socket: > > When an application closes a TCP, SCTP or DCCP socket, the > transport > protocol on the receiving host is required to maintain TIME-WAIT > state. This prevents delayed packets from the closed connection > instance from being mistakenly associated with a later connection > instance that happens to reuse the same IP address and port pairs. > The UDP protocol does not implement such a mechanism. Therefore, > UDP-based applications need to robust to this case. One > application > may close a socket or terminate, followed in time by another > application receiving on the same port. This later application may > then receive packets intended for the first application that were > delayed in the network. > > I think some text to that point would be useful, something like: > > When the TURN server allocates an IP and UDP port, that transport > address SHOULD remain unusable for two minutes after it is freed. > This is to avoid packets delayed in the network from a previous > session from being sent to a new TURN client > [I-D.ietf-tsvwg-udp-guidelines]. > > -d > >> There should not be any problems >> with this happening accidently since the client must use Refresh >> instead of Allocate for refreshes. >> >> Comments? >> >> - Philip >> >> >> >> >> _______________________________________________ >> 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 > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 21 12:00:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH00s-0005KN-Px; Mon, 21 Jan 2008 12:00:46 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JH00r-0005KC-NP for behave-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 12:00:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH00r-0005K3-Cp for behave@ietf.org; Mon, 21 Jan 2008 12:00:45 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JH00q-0004P3-SK for behave@ietf.org; Mon, 21 Jan 2008 12:00:45 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 67D9A208CD; Mon, 21 Jan 2008 18:00:44 +0100 (CET) X-AuditID: c1b4fb3c-aaaedbb0000007e0-e4-4794cfbcbbbb Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4B6FE206E0; Mon, 21 Jan 2008 18:00:44 +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, 21 Jan 2008 18:00:44 +0100 Received: from [127.0.0.1] ([153.88.21.145]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jan 2008 18:00:43 +0100 Message-ID: <4794CFAC.2080203@ericsson.com> Date: Mon, 21 Jan 2008 18:00:28 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <478E5883.5090606@acm.org> <4A3CAD0D-F58D-4EE2-B59A-04F463745D1D@magma.ca> <3C898AB6-05B8-4854-8E20-5E87B304F905@cisco.com> <96483AA0-7F26-494C-9931-19D9BAB0017D@magma.ca> <4790CDFA.3000209@ericsson.com> In-Reply-To: X-Enigmail-Version: 0.95.6 X-OriginalArrivalTime: 21 Jan 2008 17:00:43.0722 (UTC) FILETIME=[28D41AA0:01C85C4F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Behave WG , Philip Matthews 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="===============1854430821==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1854430821== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8500AE341F5B5E21A03CD0CA" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8500AE341F5B5E21A03CD0CA Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Rohan Mahy skrev: > Hi Magnus, >=20 > I am still skeptical about this statement. Can you provide an example = > use case for this? >> There clearly are cases where TURN will be deployed in an operator or = >> company network where it is desired to use diffserv and keep the=20 >> mappings that has been created. To my understanding a cellular network would such a network where=20 diffserv could be used in the service network where the TURN server=20 would be placed. In that case you don't want to change the QoS=20 properties of the relayed media traffic by having the turn server reset=20 the DSCP field. >=20 >=20 > If there are indeed use cases for this, then maybe the TURN server can = > be configured to passthrough or to remark everything to zero. Hmmm, I don't know if it is so simple. We are talking about the end to=20 end behavior of relayed traffic. You are suggesting that it should be=20 configurable if one like to break diffserv (and likely PCN) or not by=20 having a TURN server. And the reason we having this discussion is=20 because of the short comings of the OS APIs when sending and receiving=20 packets. Yes, I understand that user-land implementations of TURN seems=20 to become pretty hard. But I don't think sacrificing core IP=20 functionality is okay. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------enig8500AE341F5B5E21A03CD0CA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHlM+4qpZsSJeFbtkRAqinAJwOTsIdqj8C9vmegWXBlQdYIO4hwACfUMOg lY8oo0ALttiu7K5xVmIRtXQ= =9Tjp -----END PGP SIGNATURE----- --------------enig8500AE341F5B5E21A03CD0CA-- --===============1854430821== 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 --===============1854430821==-- From behave-bounces@ietf.org Mon Jan 21 12:31:13 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH0UI-0003hS-JP; Mon, 21 Jan 2008 12:31:10 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JH0UG-0003gl-TH for behave-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 12:31:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH0UG-0003gd-Jh for behave@ietf.org; Mon, 21 Jan 2008 12:31:08 -0500 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 1JH0UG-0005Me-Ax for behave@ietf.org; Mon, 21 Jan 2008 12:31:08 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 21 Jan 2008 09:31:07 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0LHV7Q1018997; Mon, 21 Jan 2008 09:31:07 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id m0LHV3sj012362; Mon, 21 Jan 2008 17:31:03 GMT From: Cullen Jennings To: Philip Matthews In-Reply-To: <3020DC10-80F2-4241-819C-D7B15A00A436@magma.ca> Impp: xmpp:cullenfluffyjennings@jabber.org Subject: Re: [BEHAVE] TURN Issue: How important are channels anyway? References: <478CE9AE.9080102@cisco.com> <3020DC10-80F2-4241-819C-D7B15A00A436@magma.ca> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 21 Jan 2008 09:30:47 -0800 X-Mailer: Apple Mail (2.915) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=583; t=1200936667; x=1201800667; c=relaxed/simple; s=sjdkim2002; 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=20Issue=3A=20How=20impo rtant=20are=20channels=20anyway? |Sender:=20; bh=tABkp3kkY9guJaB0D8Htj9/26eU9sboj+UPFwC+SYlg=; b=Q5vIuA8O/Uv1s1bVbzdYbAmIyzOPYZ/0r+DTtyCoDizDtyjm44vkG1t7r8 EV8e+0ZqZfUTvvmi2lMUwBEGd0nCDlf9A6Ks7OTceGNQ8PGhrTjtDfx9LBCm HMp4BNsFg4; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Rohan Mahy , 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 Jan 18, 2008, at 7:55 AM, Philip Matthews wrote: > It seems that everyone still wants the channel mechanism, despite > the difficulties we are having in resolving the open issues around it. > > So the channel mechanism will be in TURN-06 (coming soon!). However, > as noted below, the changes that we have agreed to have made in a > non-core mechanism, so it is now presented after the other, more > basic, parts of TURN. > > - Philip What does "non core" mean? If this means "optional" then I sure missed the part were we came to agreement about it. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 21 14:48:31 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH2d9-0000Ag-Ke; Mon, 21 Jan 2008 14:48:27 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JH2d8-0000AV-AN for behave-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 14:48:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH2d8-0000AN-08 for behave@ietf.org; Mon, 21 Jan 2008 14:48:26 -0500 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JH2d7-0006Nk-LW for behave@ietf.org; Mon, 21 Jan 2008 14:48:25 -0500 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 3E1375081A; Mon, 21 Jan 2008 11:50:01 -0800 (PST) Date: Mon, 21 Jan 2008 11:50:01 -0800 From: Eric Rescorla To: Philip Matthews Subject: Re: [BEHAVE] Conf call on TURN In-Reply-To: <6A5F0867-AC09-443A-BA06-F1033F465167@magma.ca> References: <6A5F0867-AC09-443A-BA06-F1033F465167@magma.ca> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080121195001.3E1375081A@romeo.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 At Fri, 18 Jan 2008 10:06:27 -0500, Philip Matthews wrote: > > I am trying to schedule a 2-hour conference call on TURN for the week > of Jan 28 - Feb 1. The goal of the call will be to discuss and try to > resolve open issues. > > If you have a strong interest in attending this call and would like > to influence when the call is held, then send me an e-mail ASAP and I > will let you know the times that we are considering for the call and > you can then let me know your availability. > > Note that, even if you do not contact me, you can still join the call > once the time is announced. All you get by contacting me now is input > into when the call is scheduled. > > I plan to send out an e-mail announcing the details of the call on > Tuesday, Jan 22. This week is open for me, with the exception of Wed AM before 11 Pacific, when I'm totally booked. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 21 15:13:36 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH31Q-0008GZ-JW; Mon, 21 Jan 2008 15:13:32 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JH31O-0008GU-25 for behave-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 15:13:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH31N-0008GM-Od for behave@ietf.org; Mon, 21 Jan 2008 15:13:29 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-07.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JH31N-0003Yt-Hz for behave@ietf.org; Mon, 21 Jan 2008 15:13:29 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JH31K-0001pQ-0t for behave@ietf.org; Mon, 21 Jan 2008 15:13:26 -0500 Mime-Version: 1.0 (Apple Message framework v753) Content-Transfer-Encoding: 7bit Message-Id: <262EBFFA-D31D-40BC-93A5-7E91A42092F6@magma.ca> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Behave WG From: Philip Matthews Date: Mon, 21 Jan 2008 15:14:32 -0500 X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [BEHAVE] Conf call on TURN scheduled 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 conf call on TURN is now scheduled for Monday, 28 Jan at the following time: 11 - 13 Pacific / 14 - 16 Eastern / 21 - 23 Finland Bridge information will be sent out tomorrow. This call is open to anyone who wishes to attend. However, I would really appreciate it if you would RSVP if you plan to attend, so I can make sure the bridge will have enough capacity. The goal of the call is to discuss the open issues in TURN-06. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 21 15:36:31 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH3Nc-0005LP-9N; Mon, 21 Jan 2008 15:36:28 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JH3Na-0005LF-7P for behave-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 15:36:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH3NZ-0005L4-Sc for behave@ietf.org; Mon, 21 Jan 2008 15:36:25 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-06.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JH3NZ-0008BP-Ez for behave@ietf.org; Mon, 21 Jan 2008 15:36:25 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JH3NY-0002fd-1D; Mon, 21 Jan 2008 15:36:24 -0500 In-Reply-To: References: <478CE9AE.9080102@cisco.com> <3020DC10-80F2-4241-819C-D7B15A00A436@magma.ca> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8AF575A5-99E0-456C-973C-579B8B4C32E3@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue: How important are channels anyway? Date: Mon, 21 Jan 2008 15:37:27 -0500 To: Cullen Jennings X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Rohan Mahy , 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 21-Jan-08, at 12:30 , Cullen Jennings wrote: > > On Jan 18, 2008, at 7:55 AM, Philip Matthews wrote: > >> It seems that everyone still wants the channel mechanism, despite >> the difficulties we are having in resolving the open issues around >> it. >> >> So the channel mechanism will be in TURN-06 (coming soon!). >> However, as noted below, the changes that we have agreed to have >> made in a non-core mechanism, so it is now presented after the >> other, more basic, parts of TURN. >> >> - Philip > > What does "non core" mean? If this means "optional" then I sure > missed the part were we came to agreement about it. "Non-core" means that channels are supplemental; they provide a second encapsulation scheme. Send and Data indications are the primary scheme. They are primary because there are situations where Send and Data indications must be used. Channels, on the other handle, do not have to be used. As for "optional", TURN-06 never uses this term, but in a sense channels are optional. How? Note that, over UDP transport, a client MUST always wait for a success response to a ChannelBind Request before using the channel (since the ChannelBind Request might get lost). So any robust client would work as follows: if Data to send to remote peer If channel exists to remote peer then Form and send a ChannelData message else Form and send a Send Indication So if the server always replies with an error response to any ChannelBind requests (or just silently ignores them), then everything would continue to work, albeit without any channels. To repeat, TURN-06 _does not_ use the word "optional" or even "supplemental". It just introduces channels as an "alternative" encapsulation scheme. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 21 15:46:41 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH3XU-0003eF-MT; Mon, 21 Jan 2008 15:46:40 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JH3XS-0003du-Qv for behave-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 15:46:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH3XS-0003dm-HE for behave@ietf.org; Mon, 21 Jan 2008 15:46:38 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JH3XS-0004fS-1l for behave@ietf.org; Mon, 21 Jan 2008 15:46:38 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 21 Jan 2008 12:46:37 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m0LKkb8G007170; Mon, 21 Jan 2008 12:46:37 -0800 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 m0LKkaiX005031; Mon, 21 Jan 2008 20:46:36 GMT From: Cullen Jennings To: "Philip Matthews" In-Reply-To: <8AF575A5-99E0-456C-973C-579B8B4C32E3@magma.ca> Impp: xmpp:cullenfluffyjennings@jabber.org Subject: Re: [BEHAVE] TURN Issue: How important are channels anyway? References: <478CE9AE.9080102@cisco.com> <3020DC10-80F2-4241-819C-D7B15A00A436@magma.ca> <8AF575A5-99E0-456C-973C-579B8B4C32E3@magma.ca> Message-Id: <21CB6B58-6AC4-4F71-89EB-09AFBA42C4ED@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 21 Jan 2008 12:46:20 -0800 X-Mailer: Apple Mail (2.915) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2042; t=1200948397; x=1201812397; c=relaxed/simple; s=sjdkim4002; 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=20Issue=3A=20How=20impo rtant=20are=20channels=20anyway? |Sender:=20; bh=yznsyZRAGcvlYkIs8/QmJOzNuIYCG4tWE7d1es7elRw=; b=HAbzqLvLc0gsF3Hkau6bQ2oCLmxjTDRvn+vCeDSCLGWcDr0wiwVjhVf89V czOFRoPokAbm5Z5MoaFW3Sgf0E73BEBik4XCwKV9Sbmr3NIDsNkylKBheH6F QOyjXmahcR; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Rohan Mahy , 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 ok, thanks - I'll stop bugging you and let you get the draft done :-) On Jan 21, 2008, at 12:37 PM, Philip Matthews wrote: > > On 21-Jan-08, at 12:30 , Cullen Jennings wrote: > > > > > On Jan 18, 2008, at 7:55 AM, Philip Matthews wrote: > > > >> It seems that everyone still wants the channel mechanism, despite > >> the difficulties we are having in resolving the open issues around > >> it. > >> > >> So the channel mechanism will be in TURN-06 (coming soon!). > >> However, as noted below, the changes that we have agreed to have > >> made in a non-core mechanism, so it is now presented after the > >> other, more basic, parts of TURN. > >> > >> - Philip > > > > What does "non core" mean? If this means "optional" then I sure > > missed the part were we came to agreement about it. > > "Non-core" means that channels are supplemental; they provide a > second encapsulation scheme. > > Send and Data indications are the primary scheme. They are primary > because there are situations where Send and Data indications must be > used. Channels, on the other handle, do not have to be used. > > As for "optional", TURN-06 never uses this term, but in a sense > channels are optional. How? Note that, over UDP transport, a client > MUST always wait for a success response to a ChannelBind Request > before using the channel (since the ChannelBind Request might get > lost). So any robust client would work as follows: > if Data to send to remote peer > If channel exists to remote peer then > Form and send a ChannelData message > else > Form and send a Send Indication > So if the server always replies with an error response to any > ChannelBind requests (or just silently ignores them), then everything > would continue to work, albeit without any channels. > > To repeat, TURN-06 _does not_ use the word "optional" or even > "supplemental". It just introduces channels as an "alternative" > encapsulation scheme. > > - Philip > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 21 15:57:25 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH3hs-0003fm-AU; Mon, 21 Jan 2008 15:57:24 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JH3hq-0003fe-Ud for behave-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 15:57:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH3hq-0003fW-Kv for behave@ietf.org; Mon, 21 Jan 2008 15:57:22 -0500 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JH3hq-0004vJ-6b for behave@ietf.org; Mon, 21 Jan 2008 15:57:22 -0500 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 1393F5081A; Mon, 21 Jan 2008 12:58:58 -0800 (PST) Date: Mon, 21 Jan 2008 12:58:58 -0800 From: Eric Rescorla To: Philip Matthews Subject: Re: [BEHAVE] TURN Issue: How important are channels anyway? In-Reply-To: <8AF575A5-99E0-456C-973C-579B8B4C32E3@magma.ca> References: <478CE9AE.9080102@cisco.com> <3020DC10-80F2-4241-819C-D7B15A00A436@magma.ca> <8AF575A5-99E0-456C-973C-579B8B4C32E3@magma.ca> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080121205858.1393F5081A@romeo.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Rohan Mahy , 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 At Mon, 21 Jan 2008 15:37:27 -0500, Philip Matthews wrote: > > > On 21-Jan-08, at 12:30 , Cullen Jennings wrote: > > > > > On Jan 18, 2008, at 7:55 AM, Philip Matthews wrote: > > > >> It seems that everyone still wants the channel mechanism, despite > >> the difficulties we are having in resolving the open issues around > >> it. > >> > >> So the channel mechanism will be in TURN-06 (coming soon!). > >> However, as noted below, the changes that we have agreed to have > >> made in a non-core mechanism, so it is now presented after the > >> other, more basic, parts of TURN. > >> > >> - Philip > > > > What does "non core" mean? If this means "optional" then I sure > > missed the part were we came to agreement about it. > > "Non-core" means that channels are supplemental; they provide a > second encapsulation scheme. > > Send and Data indications are the primary scheme. They are primary > because there are situations where Send and Data indications must be > used. Channels, on the other handle, do not have to be used. > > As for "optional", TURN-06 never uses this term, but in a sense > channels are optional. How? Note that, over UDP transport, a client > MUST always wait for a success response to a ChannelBind Request > before using the channel (since the ChannelBind Request might get > lost). So any robust client would work as follows: > if Data to send to remote peer > If channel exists to remote peer then > Form and send a ChannelData message > else > Form and send a Send Indication > So if the server always replies with an error response to any > ChannelBind requests (or just silently ignores them), then everything > would continue to work, albeit without any channels. > > To repeat, TURN-06 _does not_ use the word "optional" or even > "supplemental". It just introduces channels as an "alternative" > encapsulation scheme. True, but it seems that the spec needs to read that servers MUST implement and serve ChannelBind requests. I.e., it's not OK to write a server which just refules all channel binding and call it TURN. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 21 16:04:29 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH3oi-0006De-RZ; Mon, 21 Jan 2008 16:04:28 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JH3oh-0006DX-Ey for behave-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 16:04:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH3oh-0006DP-5D for behave@ietf.org; Mon, 21 Jan 2008 16:04:27 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-02.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JH3of-000554-Si for behave@ietf.org; Mon, 21 Jan 2008 16:04:27 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JH3of-0006xN-24; Mon, 21 Jan 2008 16:04:25 -0500 In-Reply-To: <20080121205858.1393F5081A@romeo.rtfm.com> References: <478CE9AE.9080102@cisco.com> <3020DC10-80F2-4241-819C-D7B15A00A436@magma.ca> <8AF575A5-99E0-456C-973C-579B8B4C32E3@magma.ca> <20080121205858.1393F5081A@romeo.rtfm.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue: How important are channels anyway? Date: Mon, 21 Jan 2008 16:05:28 -0500 To: Eric Rescorla X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Rohan Mahy , 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 21-Jan-08, at 15:58 , Eric Rescorla wrote: > > True, but it seems that the spec needs to read that servers MUST > implement and serve ChannelBind requests. I.e., it's not OK to > write a server which just refules all channel binding and call > it TURN. We can do that, but I also think that clients MUST be able to handle the server rejecting the ChannelBind Request. A server might do that for perfectly valid reasons (e.g., out of resources). - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 21 16:20:17 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH43z-0001WS-JG; Mon, 21 Jan 2008 16:20:15 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JH43y-0001WN-Kv for behave-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 16:20:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH43y-0001WE-9V for behave@ietf.org; Mon, 21 Jan 2008 16:20:14 -0500 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JH43x-0005Vh-9E for behave@ietf.org; Mon, 21 Jan 2008 16:20:14 -0500 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 2698A5081A; Mon, 21 Jan 2008 13:21:49 -0800 (PST) Date: Mon, 21 Jan 2008 13:21:49 -0800 From: Eric Rescorla To: Philip Matthews Subject: Re: [BEHAVE] TURN Issue: How important are channels anyway? In-Reply-To: References: <478CE9AE.9080102@cisco.com> <3020DC10-80F2-4241-819C-D7B15A00A436@magma.ca> <8AF575A5-99E0-456C-973C-579B8B4C32E3@magma.ca> <20080121205858.1393F5081A@romeo.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080121212149.2698A5081A@romeo.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Rohan Mahy , 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 At Mon, 21 Jan 2008 16:05:28 -0500, Philip Matthews wrote: > > > On 21-Jan-08, at 15:58 , Eric Rescorla wrote: > > > > True, but it seems that the spec needs to read that servers MUST > > implement and serve ChannelBind requests. I.e., it's not OK to > > write a server which just refules all channel binding and call > > it TURN. > > We can do that, but I also think that clients MUST be able to handle > the server rejecting the ChannelBind Request. A server might do that > for perfectly valid reasons (e.g., out of resources). I was going to say I totally agree, but really, what resource would you run out of here? I mean, the channel is just this a small memory structure, right? If the TURN server gets that low on memory, it's going to crash shortly anyway, so it's not clear to me that this is really that legitimate a case. That said, I think that a TURN client needs to be able to handle the server rejecting the ChannelBind in that it doesn't crash or reformat your hard drive, but it's reasonable for the client to handle that by closing the connection entirely, since any TURN server which won't do this is basically broken. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 21 22:19:32 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH9fd-0006fP-2Q; Mon, 21 Jan 2008 22:19:29 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JH9fc-0006fK-48 for behave-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 22:19:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH9fb-0006fC-OZ for behave@ietf.org; Mon, 21 Jan 2008 22:19:27 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-08.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JH9fb-0003G4-Aq for behave@ietf.org; Mon, 21 Jan 2008 22:19:27 -0500 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-08.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JH9fU-00039E-0q; Mon, 21 Jan 2008 22:19:20 -0500 In-Reply-To: <20080121212149.2698A5081A@romeo.rtfm.com> References: <478CE9AE.9080102@cisco.com> <3020DC10-80F2-4241-819C-D7B15A00A436@magma.ca> <8AF575A5-99E0-456C-973C-579B8B4C32E3@magma.ca> <20080121205858.1393F5081A@romeo.rtfm.com> <20080121212149.2698A5081A@romeo.rtfm.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <631A1726-0496-4CDC-A893-BA8419154D8F@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue: How important are channels anyway? Date: Mon, 21 Jan 2008 22:20:23 -0500 To: Eric Rescorla X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Rohan Mahy , 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 21-Jan-08, at 16:21 , Eric Rescorla wrote: > At Mon, 21 Jan 2008 16:05:28 -0500, > Philip Matthews wrote: >> >> >> On 21-Jan-08, at 15:58 , Eric Rescorla wrote: >>> >>> True, but it seems that the spec needs to read that servers MUST >>> implement and serve ChannelBind requests. I.e., it's not OK to >>> write a server which just refules all channel binding and call >>> it TURN. >> >> We can do that, but I also think that clients MUST be able to handle >> the server rejecting the ChannelBind Request. A server might do that >> for perfectly valid reasons (e.g., out of resources). > > I was going to say I totally agree, but really, what resource would > you run out of here? I mean, the channel is just this a small memory > structure, right? If the TURN server gets that low on memory, it's > going to crash shortly anyway, so it's not clear to me that this is > really that legitimate a case. > > That said, I think that a TURN client needs to be able to handle the > server rejecting the ChannelBind in that it doesn't crash or reformat > your hard drive, but it's reasonable for the client to handle that by > closing the connection entirely, since any TURN server which won't do > this is basically broken. Maybe. But I could easily imagine an implementation which, on startup, allocated space for a fixed number of channel bindings and handed them out to various allocations on demand, keeping a free list of those not currently in use. The application would only get memory on startup and would not do any more mallocs after that. When channel binding entries ran out, the ChannelBind request would fail, but the application would be totally robust because the next time an allocation expired it would free up some channel binding entries for re-use. Most of the embedded products that I am most familiar with and been heavily involved in coding work this way. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 21 23:01:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHAJx-00077V-Ah; Mon, 21 Jan 2008 23:01:09 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JHAJw-00077N-5Q for behave-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 23:01:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHAJv-00077F-Rp for behave@ietf.org; Mon, 21 Jan 2008 23:01:07 -0500 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHAJu-0006fN-D0 for behave@ietf.org; Mon, 21 Jan 2008 23:01:07 -0500 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 455635081A; Mon, 21 Jan 2008 20:02:42 -0800 (PST) Date: Mon, 21 Jan 2008 20:02:42 -0800 From: Eric Rescorla To: Philip Matthews Subject: Re: [BEHAVE] TURN Issue: How important are channels anyway? In-Reply-To: <631A1726-0496-4CDC-A893-BA8419154D8F@magma.ca> References: <478CE9AE.9080102@cisco.com> <3020DC10-80F2-4241-819C-D7B15A00A436@magma.ca> <8AF575A5-99E0-456C-973C-579B8B4C32E3@magma.ca> <20080121205858.1393F5081A@romeo.rtfm.com> <20080121212149.2698A5081A@romeo.rtfm.com> <631A1726-0496-4CDC-A893-BA8419154D8F@magma.ca> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080122040242.455635081A@romeo.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Rohan Mahy , 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 At Mon, 21 Jan 2008 22:20:23 -0500, Philip Matthews wrote: > > > On 21-Jan-08, at 16:21 , Eric Rescorla wrote: > > > At Mon, 21 Jan 2008 16:05:28 -0500, > > Philip Matthews wrote: > >> > >> > >> On 21-Jan-08, at 15:58 , Eric Rescorla wrote: > >>> > >>> True, but it seems that the spec needs to read that servers MUST > >>> implement and serve ChannelBind requests. I.e., it's not OK to > >>> write a server which just refules all channel binding and call > >>> it TURN. > >> > >> We can do that, but I also think that clients MUST be able to handle > >> the server rejecting the ChannelBind Request. A server might do that > >> for perfectly valid reasons (e.g., out of resources). > > > > I was going to say I totally agree, but really, what resource would > > you run out of here? I mean, the channel is just this a small memory > > structure, right? If the TURN server gets that low on memory, it's > > going to crash shortly anyway, so it's not clear to me that this is > > really that legitimate a case. > > > > That said, I think that a TURN client needs to be able to handle the > > server rejecting the ChannelBind in that it doesn't crash or reformat > > your hard drive, but it's reasonable for the client to handle that by > > closing the connection entirely, since any TURN server which won't do > > this is basically broken. > > Maybe. > > But I could easily imagine an implementation which, on startup, > allocated space for a fixed number of channel bindings and handed > them out to various allocations on demand, keeping a free list of > those not currently in use. The application would only get memory on > startup and would not do any more mallocs after that. When channel > binding entries ran out, the ChannelBind request would fail, but the > application would be totally robust because the next time an > allocation expired it would free up some channel binding entries for > re-use. > > Most of the embedded products that I am most familiar with and been > heavily involved in coding work this way. As Randy Bush is fond of saying: I encourage my competitors to design their systems this way. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 22 11:39:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHM9M-0003Ll-ED; Tue, 22 Jan 2008 11:39:00 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JHM9K-0003Lf-RE for behave-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 11:38:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHM9K-0003LX-Fq for behave@ietf.org; Tue, 22 Jan 2008 11:38:58 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-09.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHM9K-0001Zq-20 for behave@ietf.org; Tue, 22 Jan 2008 11:38:58 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JHM9J-00017O-2D for behave@ietf.org; Tue, 22 Jan 2008 11:38:57 -0500 Mime-Version: 1.0 (Apple Message framework v753) Content-Transfer-Encoding: 7bit Message-Id: <28EBDE9C-826C-4D8A-84F2-343463B3FC1D@magma.ca> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Behave WG From: Philip Matthews Date: Tue, 22 Jan 2008 11:40:03 -0500 X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [BEHAVE] TURN-06 submitted 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 just submitted TURN-06 to the archives. It should appear shortly. Below is a list of the major changes since TURN-05. The main goal of this revision has been to reflect the decisions made on the mailing list and confirmed during the conf call of 20 Dec 2007. There are still quite a few open issues that we need to resolve. These are now listed in a new section in the document. Almost all of these issues are currently being discussed in a thread on the mailing list. In the interest of time, the authors have elected to release this revision in a more "raw" state that they would normally prefer. As a result, there are some rough spots in the presentation. The authors elected to do this in order to make more rapid progress on the open issues. There is a conference call scheduled for Monday, January 28th to discuss the open issues in the document. See separate e-mail. - Philip Major changes since TURN-05: o Changed the mechanism for allocating channels to the one proposed by Eric Rescorla at the Dec 2007 IETF meeting. o Removed the framing mechanism (which was used to frame all messages) and replaced it with the ChannelData message. As part of this change, noted that the demux of ChannelData messages from TURN messages can be done using the first two bits of the message. o Rewrote the sections on transmitted and receiving data as a result of the above to changes, splitting it into a section on Send and Data Indications and a separate section on channels. o Clarified the handling of Allocate Request messages. In particular, subsequent Allocate Request messages over UDP with the same transaction id are not an error but a retransmission. o Restricted the range of ports available for allocation to the Dynamic and/or Private Port range, and noted when ports outside this range can be used. o Changed the format of the REQUESTED-TRANSPORT attribute. The previous version used 00 for UDP and 01 for TCP; the new version uses protocol numbers from the IANA protocol number registry. The format of the attribute also changed. o Made a large number of changes to the non-normative portion of the document to reflect technical changes and improve the presentation. o Added the Issues section. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 22 11:40:06 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHMAQ-0003w5-OX; Tue, 22 Jan 2008 11:40:06 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JHMAN-0003vm-1e for behave-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 11:40:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHMAM-0003vW-LT; Tue, 22 Jan 2008 11:40:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHMAM-0008T0-5Z; Tue, 22 Jan 2008 11:40:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 00B8526E72; Tue, 22 Jan 2008 16:40:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JHMAL-0007fu-SP; Tue, 22 Jan 2008 11:40:01 -0500 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, 22 Jan 2008 11:40:01 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-turn-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 : Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-behave-turn-06.txt Pages : 43 Date : 2008-01-22 If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers) located behind other NATs. In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. The TURN protocol can be used in isolation, but is more properly used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-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-turn-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-turn-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: <2008-01-22113721.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-turn-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-turn-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-22113721.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 Jan 22 12:01:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHMVK-00006m-NS; Tue, 22 Jan 2008 12:01:42 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JHMVJ-00005a-6s for behave-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 12:01:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHMVI-00005B-Rv for behave@ietf.org; Tue, 22 Jan 2008 12:01:40 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-01.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHMVI-0002JR-FN for behave@ietf.org; Tue, 22 Jan 2008 12:01:40 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JHMVH-0005Hi-27 for behave@ietf.org; Tue, 22 Jan 2008 12:01:39 -0500 Mime-Version: 1.0 (Apple Message framework v753) In-Reply-To: <262EBFFA-D31D-40BC-93A5-7E91A42092F6@magma.ca> References: <262EBFFA-D31D-40BC-93A5-7E91A42092F6@magma.ca> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3477DE93-6451-4D15-8130-51E3D1C89D75@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] Conf call on TURN scheduled Date: Tue, 22 Jan 2008 12:02:45 -0500 To: Behave WG X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 small change from what I said yesterday. The call is open to anyone who wishes to attend. However, I ask that you send me an e-mail if you are interested in joining this call, and I will then send you the information on how to join. - Philip On 21-Jan-08, at 15:14 , Philip Matthews wrote: > The conf call on TURN is now scheduled for Monday, 28 Jan at the > following time: > 11 - 13 Pacific / 14 - 16 Eastern / 21 - 23 Finland > > Bridge information will be sent out tomorrow. > > This call is open to anyone who wishes to attend. However, I would > really appreciate it if you would RSVP if you plan to attend, so I > can make sure the bridge will have enough capacity. > > The goal of the call is to discuss the open issues in TURN-06. > > - Philip > > > _______________________________________________ > 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 Jan 22 12:53:46 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHNJh-0007xW-3u; Tue, 22 Jan 2008 12:53:45 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JHNJg-0007xQ-Ay for behave-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 12:53:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHNJf-0007wB-UG for behave@ietf.org; Tue, 22 Jan 2008 12:53:44 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHNJf-0004hS-E0 for behave@ietf.org; Tue, 22 Jan 2008 12:53:43 -0500 X-IronPort-AV: E=Sophos;i="4.25,234,1199682000"; d="scan'208";a="84061683" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 22 Jan 2008 12:53:43 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0MHrg45012375; Tue, 22 Jan 2008 12:53:42 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0MHquv8016350; Tue, 22 Jan 2008 17:53:38 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); Tue, 22 Jan 2008 12:53:36 -0500 Received: from [161.44.34.109] ([161.44.34.109]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jan 2008 12:53:36 -0500 Message-ID: <47962D90.5020808@cisco.com> Date: Tue, 22 Jan 2008 12:53:20 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [BEHAVE] TURN Issue: How important are channels anyway? References: <478CE9AE.9080102@cisco.com> <3020DC10-80F2-4241-819C-D7B15A00A436@magma.ca> <8AF575A5-99E0-456C-973C-579B8B4C32E3@magma.ca> <20080121205858.1393F5081A@romeo.rtfm.com> <20080121212149.2698A5081A@romeo.rtfm.com> <631A1726-0496-4CDC-A893-BA8419154D8F@magma.ca> In-Reply-To: <631A1726-0496-4CDC-A893-BA8419154D8F@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jan 2008 17:53:36.0510 (UTC) FILETIME=[B65EE1E0:01C85D1F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3010; t=1201024422; x=1201888422; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20Issue=3A=20How=20impo rtant=20are=20channels=20anyway? |Sender:=20 |To:=20Philip=20Matthews=20; bh=+D8UhDiYq9YSwsj4IU5HvNS3JUz0EvUKAy4w1rvMJ6k=; b=eQ0G+901NZE7FIG+8p0l1DgAkfYOkYkGGb1gb6UbBvryJt9Sp+13EEWYK4 bx8udt5XV5zzz9E+qUbDadZ10RPh/HSGqwkEI4uqXcoyDNP8kUnqWqsVhFol PebwgkFlwQ; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Rohan Mahy , 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 Options adds to complexity. Implementation of the channel mechanism is not optional for servers. Its mandatory. Clients can use it or not, at their discretion. A server should never reject a ChannelBind message because of lack of implementation or lack of memory or whatever, and CERTAINLY we should not require clients to handle these cases. If a broken server wants to reject a ChannelBind with a 400 because its out of memory, so be it, but we don't need to say anything about that in the spec. -Jonathan R. Philip Matthews wrote: > > On 21-Jan-08, at 16:21 , Eric Rescorla wrote: > >> At Mon, 21 Jan 2008 16:05:28 -0500, >> Philip Matthews wrote: >>> >>> >>> On 21-Jan-08, at 15:58 , Eric Rescorla wrote: >>>> >>>> True, but it seems that the spec needs to read that servers MUST >>>> implement and serve ChannelBind requests. I.e., it's not OK to >>>> write a server which just refules all channel binding and call >>>> it TURN. >>> >>> We can do that, but I also think that clients MUST be able to handle >>> the server rejecting the ChannelBind Request. A server might do that >>> for perfectly valid reasons (e.g., out of resources). >> >> I was going to say I totally agree, but really, what resource would >> you run out of here? I mean, the channel is just this a small memory >> structure, right? If the TURN server gets that low on memory, it's >> going to crash shortly anyway, so it's not clear to me that this is >> really that legitimate a case. >> >> That said, I think that a TURN client needs to be able to handle the >> server rejecting the ChannelBind in that it doesn't crash or reformat >> your hard drive, but it's reasonable for the client to handle that by >> closing the connection entirely, since any TURN server which won't do >> this is basically broken. > > Maybe. > > But I could easily imagine an implementation which, on startup, > allocated space for a fixed number of channel bindings and handed them > out to various allocations on demand, keeping a free list of those not > currently in use. The application would only get memory on startup and > would not do any more mallocs after that. When channel binding entries > ran out, the ChannelBind request would fail, but the application would > be totally robust because the next time an allocation expired it would > free up some channel binding entries for re-use. > > Most of the embedded products that I am most familiar with and been > heavily involved in coding work this way. > > - Philip > > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 22 13:14:17 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHNdX-00030F-L4; Tue, 22 Jan 2008 13:14:15 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JHNdX-00030A-2q for behave-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 13:14:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHNdW-000302-PV for behave@ietf.org; Tue, 22 Jan 2008 13:14:14 -0500 Received: from server.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHNdW-00038O-Hd for behave@ietf.org; Tue, 22 Jan 2008 13:14:14 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id 21B1ADBCCA2C; Tue, 22 Jan 2008 18:14:14 +0000 (UTC) Received: from [192.168.1.3] (c-71-202-183-123.hsd1.ca.comcast.net [71.202.183.123]) by server.implementers.org (Postfix) with ESMTP id 929C9DBCCA2A; Tue, 22 Jan 2008 18:14:09 +0000 (UTC) Message-ID: <47963271.5000706@acm.org> Date: Tue, 22 Jan 2008 10:14:09 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080109) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [BEHAVE] TURN-06 submitted References: <28EBDE9C-826C-4D8A-84F2-343463B3FC1D@magma.ca> In-Reply-To: <28EBDE9C-826C-4D8A-84F2-343463B3FC1D@magma.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 Philip, Philip Matthews wrote: > I have just submitted TURN-06 to the archives. It should appear shortly. > The ChannelBind codepoint is missing in section 8 as are 3 response codes in section 10, meaning that this spec is unimplementable. No running code that be written on top of an unimplementable spec. Thanks. -- 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 Tue Jan 22 14:19:39 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHOel-0000ZM-Rn; Tue, 22 Jan 2008 14:19:35 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JHOek-0000Ot-Jn for behave-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 14:19:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHOek-0000Mm-8c for behave@ietf.org; Tue, 22 Jan 2008 14:19:34 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-08.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHOei-0004NU-Ow for behave@ietf.org; Tue, 22 Jan 2008 14:19:34 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-08.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JHOeg-0007Rg-2k; Tue, 22 Jan 2008 14:19:30 -0500 In-Reply-To: <47963271.5000706@acm.org> References: <28EBDE9C-826C-4D8A-84F2-343463B3FC1D@magma.ca> <47963271.5000706@acm.org> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7EFFEC17-D198-4DD0-9665-091B2C10BD47@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN-06 submitted Date: Tue, 22 Jan 2008 14:20:36 -0500 To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 Marc: Thanks for catching the missing ChannelBind codepoint. I suggest we just re-use the ChannelConfirmation codepoint of TURN-05, and thus assign it a code point of 0x009. I'll add that to my TURN-07 draft. As far as the three response codes, those are actually the subject of a debate between Rohan and myself. I'll start a separate thread on this issue. Are these missing codepoints a big issue? There are a number of open issues in the document, and we are really hoping to close a number of them and issue a TURN-07 soon. So you really want to implement TURN-06, or would you wait until things settle down a bit? And this raises another issue. I currently consider TURN to be in flux, and am assuming that no one is actually deploying the spec. So, unlike early versions of ICE, I am not thinking about how to detect version numbering or backwards compatibility, etc. Does anyone feel I should think otherwise? - Philip On 22-Jan-08, at 13:14 , Marc Petit-Huguenin wrote: > Hi Philip, > > Philip Matthews wrote: >> I have just submitted TURN-06 to the archives. It should appear >> shortly. >> > > The ChannelBind codepoint is missing in section 8 as are 3 response > codes in section 10, meaning that this spec is unimplementable. No > running code that be written on top of an unimplementable spec. > > Thanks. > > -- > 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 Tue Jan 22 14:29:16 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHOo8-0001AC-Ab; Tue, 22 Jan 2008 14:29:16 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JHOo7-0001A5-A9 for behave-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 14:29:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHOo7-00019v-0T for behave@ietf.org; Tue, 22 Jan 2008 14:29:15 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHOo5-0004d5-Mr for behave@ietf.org; Tue, 22 Jan 2008 14:29:14 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JHOo5-0002N6-0H; Tue, 22 Jan 2008 14:29:13 -0500 Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6066E435-B304-4616-A9B3-353FC42FFCE1@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Tue, 22 Jan 2008 14:30:18 -0500 To: Behave WG X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [BEHAVE] TURN Issue: Codepoints for errors 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 TURN-06 proposes three new error codes: (tbd) (Channel Number Missing or Invalid): The request requires a channel number, but the CHANNEL-NUMBER attribute is missing, or the specified channel number is invalid in some way. (tbd) (Peer Address Missing or Invalid): The request requires a peer transport address, but the PEER-ADDRESS attribute is missing, or the specified peer transport address is invalid in some way. (tbd) (Lifetime Malformed or Invalid): The LIFETIME attribute is malformed or the specified lifetime is invalid in some way. Rohan has proposed that these three codepoints be eliminated, and we just use 400 Bad Request. Does anyone care about this? Note that an implementation is always free to change the text associated with a codepoint, so it could say something like 400 "Channel Number Missing or Invalid". This is not something that we have specified before with STUN, but it is something allowed by the spec. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 22 14:29:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHOoD-0001E4-Jb; Tue, 22 Jan 2008 14:29:21 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JHOoC-0001DY-5Q for behave-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 14:29:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHOoB-0001DI-Pl for behave@ietf.org; Tue, 22 Jan 2008 14:29:19 -0500 Received: from server.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHOo9-0004dA-G4 for behave@ietf.org; Tue, 22 Jan 2008 14:29:19 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id CF9A2DBCCA2E; Tue, 22 Jan 2008 19:29:16 +0000 (UTC) Received: from [192.168.1.3] (c-71-202-183-123.hsd1.ca.comcast.net [71.202.183.123]) by server.implementers.org (Postfix) with ESMTP id A4293DBCCA2C; Tue, 22 Jan 2008 19:29:14 +0000 (UTC) Message-ID: <47964409.10900@acm.org> Date: Tue, 22 Jan 2008 11:29:13 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080109) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [BEHAVE] TURN-06 submitted References: <28EBDE9C-826C-4D8A-84F2-343463B3FC1D@magma.ca> <47963271.5000706@acm.org> <7EFFEC17-D198-4DD0-9665-091B2C10BD47@magma.ca> In-Reply-To: <7EFFEC17-D198-4DD0-9665-091B2C10BD47@magma.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 Philip Matthews wrote: > Hi Marc: > > Thanks for catching the missing ChannelBind codepoint. I suggest we just > re-use the ChannelConfirmation codepoint of TURN-05, and thus assign it > a code point of 0x009. I'll add that to my TURN-07 draft. > > As far as the three response codes, those are actually the subject of a > debate between Rohan and myself. I'll start a separate thread on this > issue. Ok, but that does not prevent to assign a value to the response code. > > Are these missing codepoints a big issue? There are a number of open > issues in the document, and we are really hoping to close a number of > them and issue a TURN-07 soon. So you really want to implement TURN-06, > or would you wait until things settle down a bit? Well, I am an implementer, not a network protocol designer as all of you. The only way to be sure if something works that I know of is to implement and test it. So yes, I am implementing TURN-06, and plan to offer accounts on my TURN server to TURN client implementers just after the conference call (unless there is another complete change). > > And this raises another issue. I currently consider TURN to be in flux, > and am assuming that no one is actually deploying the spec. So, unlike > early versions of ICE, I am not thinking about how to detect version > numbering or backwards compatibility, etc. Does anyone feel I should > think otherwise? We already talked about this I think, and there is no need for backward compatibility between I-Ds. People implementing the I-D know the risk and plan accordingly. > > - Philip > > On 22-Jan-08, at 13:14 , Marc Petit-Huguenin wrote: > >> Hi Philip, >> >> Philip Matthews wrote: >>> I have just submitted TURN-06 to the archives. It should appear shortly. >>> >> >> The ChannelBind codepoint is missing in section 8 as are 3 response >> codes in section 10, meaning that this spec is unimplementable. No >> running code that be written on top of an unimplementable spec. >> -- 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 Tue Jan 22 14:36:29 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHOv6-0006uP-9l; Tue, 22 Jan 2008 14:36:28 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JHOv5-0006uG-5f for behave-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 14:36:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHOv4-0006u8-Qx for behave@ietf.org; Tue, 22 Jan 2008 14:36:26 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-07.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHOv4-0007Kc-7u for behave@ietf.org; Tue, 22 Jan 2008 14:36:26 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JHOuz-0006pB-1e; Tue, 22 Jan 2008 14:36:22 -0500 In-Reply-To: <47962D90.5020808@cisco.com> References: <478CE9AE.9080102@cisco.com> <3020DC10-80F2-4241-819C-D7B15A00A436@magma.ca> <8AF575A5-99E0-456C-973C-579B8B4C32E3@magma.ca> <20080121205858.1393F5081A@romeo.rtfm.com> <20080121212149.2698A5081A@romeo.rtfm.com> <631A1726-0496-4CDC-A893-BA8419154D8F@magma.ca> <47962D90.5020808@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue: How important are channels anyway? Date: Tue, 22 Jan 2008 14:37:29 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: Rohan Mahy , 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 The spec currently says: Over UDP, the client SHOULD NOT send ChannelData messages on the channel until it has received a ChannelBind Success Response for the binding attempt. Sending them before the success response is received risks having them dropped by the server if he ChannelBind Request was lost. In my opinion, the same should apply for ChannelBind over TCP, since the server might reject. It may be unlikely, but it could still happen. And I still claim that a robust client will do what I suggested earlier: If data to send then If have a channel to destination peer then Send ChannelData message else Send a "Send" indication - Philip On 22-Jan-08, at 12:53 , Jonathan Rosenberg wrote: > Options adds to complexity. > > Implementation of the channel mechanism is not optional for > servers. Its mandatory. Clients can use it or not, at their > discretion. > > A server should never reject a ChannelBind message because of lack > of implementation or lack of memory or whatever, and CERTAINLY we > should not require clients to handle these cases. If a broken > server wants to reject a ChannelBind with a 400 because its out of > memory, so be it, but we don't need to say anything about that in > the spec. > > -Jonathan R. > > Philip Matthews wrote: >> On 21-Jan-08, at 16:21 , Eric Rescorla wrote: >>> At Mon, 21 Jan 2008 16:05:28 -0500, >>> Philip Matthews wrote: >>>> >>>> >>>> On 21-Jan-08, at 15:58 , Eric Rescorla wrote: >>>>> >>>>> True, but it seems that the spec needs to read that servers MUST >>>>> implement and serve ChannelBind requests. I.e., it's not OK to >>>>> write a server which just refules all channel binding and call >>>>> it TURN. >>>> >>>> We can do that, but I also think that clients MUST be able to >>>> handle >>>> the server rejecting the ChannelBind Request. A server might do >>>> that >>>> for perfectly valid reasons (e.g., out of resources). >>> >>> I was going to say I totally agree, but really, what resource would >>> you run out of here? I mean, the channel is just this a small memory >>> structure, right? If the TURN server gets that low on memory, it's >>> going to crash shortly anyway, so it's not clear to me that this is >>> really that legitimate a case. >>> >>> That said, I think that a TURN client needs to be able to handle the >>> server rejecting the ChannelBind in that it doesn't crash or >>> reformat >>> your hard drive, but it's reasonable for the client to handle >>> that by >>> closing the connection entirely, since any TURN server which >>> won't do >>> this is basically broken. >> Maybe. >> But I could easily imagine an implementation which, on startup, >> allocated space for a fixed number of channel bindings and handed >> them out to various allocations on demand, keeping a free list of >> those not currently in use. The application would only get memory >> on startup and would not do any more mallocs after that. When >> channel binding entries ran out, the ChannelBind request would >> fail, but the application would be totally robust because the next >> time an allocation expired it would free up some channel binding >> entries for re-use. >> Most of the embedded products that I am most familiar with and >> been heavily involved in coding work this way. >> - Philip >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave > > -- > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 22 14:45:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHP4C-0006vV-MX; Tue, 22 Jan 2008 14:45:52 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JHP4B-0006vQ-QR for behave-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 14:45:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHP4B-0006vI-Fz for behave@ietf.org; Tue, 22 Jan 2008 14:45:51 -0500 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHP4B-0007a0-4H for behave@ietf.org; Tue, 22 Jan 2008 14:45:51 -0500 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 1E7035081A; Tue, 22 Jan 2008 11:47:27 -0800 (PST) Date: Tue, 22 Jan 2008 11:47:27 -0800 From: Eric Rescorla To: Philip Matthews Subject: Re: [BEHAVE] TURN Issue: How important are channels anyway? In-Reply-To: References: <478CE9AE.9080102@cisco.com> <3020DC10-80F2-4241-819C-D7B15A00A436@magma.ca> <8AF575A5-99E0-456C-973C-579B8B4C32E3@magma.ca> <20080121205858.1393F5081A@romeo.rtfm.com> <20080121212149.2698A5081A@romeo.rtfm.com> <631A1726-0496-4CDC-A893-BA8419154D8F@magma.ca> <47962D90.5020808@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: <20080122194727.1E7035081A@romeo.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Rohan Mahy , 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 At Tue, 22 Jan 2008 14:37:29 -0500, Philip Matthews wrote: > > The spec currently says: > Over UDP, the client SHOULD NOT send ChannelData messages on the > channel until it has received a ChannelBind Success Response for the > binding attempt. Sending them before the success response is > received risks having them dropped by the server if he ChannelBind > Request was lost. I actually think this is wrong. In the vast majority of cases the ChannelBind will work (if this isn't true your network is likely unusably hosed). Since the consequences of sending ChannelData prior to a ChannelBind success is purely that the ChannelData gets dropped, this isn't an interop issue and it should be up to the client what it wants to do. The spec should simply describe the possible cases and be silent on recommendations. > In my opinion, the same should apply for ChannelBind over TCP, since > the server might reject. I definitely think this is wrong. First, as I argued above, it's up to the client how he wants to balance these risks. Second, if the server rejects, the client may well want to simply drop the connection, in which case it's hard to see why it shouldn't it be optimistic? -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 22 14:47:13 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHP5V-0000em-M2; Tue, 22 Jan 2008 14:47:13 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JHP5U-0000eU-HZ for behave-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 14:47:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHP5U-0000eM-7K for behave@ietf.org; Tue, 22 Jan 2008 14:47:12 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-09.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHP5U-0007dv-0W for behave@ietf.org; Tue, 22 Jan 2008 14:47:12 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JHP5T-0003iG-39; Tue, 22 Jan 2008 14:47:12 -0500 In-Reply-To: <47964409.10900@acm.org> References: <28EBDE9C-826C-4D8A-84F2-343463B3FC1D@magma.ca> <47963271.5000706@acm.org> <7EFFEC17-D198-4DD0-9665-091B2C10BD47@magma.ca> <47964409.10900@acm.org> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <565C3ACA-DC40-41A3-877D-DE626D9598AC@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN-06 submitted Date: Tue, 22 Jan 2008 14:48:17 -0500 To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 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 OK. Let's try to resolve the error code issue quickly then. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 22 15:30:31 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHPlM-0007F6-48; Tue, 22 Jan 2008 15:30:28 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JHPlK-0007Er-VJ for behave-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 15:30:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHPlK-0007CW-JR for behave@ietf.org; Tue, 22 Jan 2008 15:30:26 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-05.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHPlK-0000aU-4z for behave@ietf.org; Tue, 22 Jan 2008 15:30:26 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JHPkT-0004Uk-2G; Tue, 22 Jan 2008 15:29:33 -0500 In-Reply-To: <20080122194727.1E7035081A@romeo.rtfm.com> References: <478CE9AE.9080102@cisco.com> <3020DC10-80F2-4241-819C-D7B15A00A436@magma.ca> <8AF575A5-99E0-456C-973C-579B8B4C32E3@magma.ca> <20080121205858.1393F5081A@romeo.rtfm.com> <20080121212149.2698A5081A@romeo.rtfm.com> <631A1726-0496-4CDC-A893-BA8419154D8F@magma.ca> <47962D90.5020808@cisco.com> <20080122194727.1E7035081A@romeo.rtfm.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <32C5979F-5CEF-4EE7-A1BD-F05B5FF0ACDB@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue: How important are channels anyway? Date: Tue, 22 Jan 2008 15:31:23 -0500 To: Eric Rescorla X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Rohan Mahy , 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 Eric: If I understand your proposal correctly, you would like to see the document list the consequences of sending a ChannelData message before receiving a ChannelBind success response, where the two consequences are: (1) over UDP, the ChannelBind request might be lost, and (2) over any transport, the server might reject the ChannelBind request. The document would then say "the client MAY send in this situation". I believe you think that (2) is possible, but think it is very unlikely. I personally think the chances are a bit higher. But I would suggest we just be silent about probabilities. I am happy with this change. As you point out, letting clients send or not in this case does not break interoperability or have bad network side-effects. The only side-effect is possible lost packets. Any comments from anyone else? - Philip - Philip On 22-Jan-08, at 14:47 , Eric Rescorla wrote: > At Tue, 22 Jan 2008 14:37:29 -0500, > Philip Matthews wrote: >> >> The spec currently says: >> Over UDP, the client SHOULD NOT send ChannelData messages on the >> channel until it has received a ChannelBind Success Response >> for the >> binding attempt. Sending them before the success response is >> received risks having them dropped by the server if he >> ChannelBind >> Request was lost. > > I actually think this is wrong. > > In the vast majority of cases the ChannelBind will work (if this > isn't true your network is likely unusably hosed). Since > the consequences of sending ChannelData prior to a ChannelBind > success is purely that the ChannelData gets dropped, this isn't > an interop issue and it should be up to the client what it > wants to do. > > The spec should simply describe the possible cases and be > silent on recommendations. > > >> In my opinion, the same should apply for ChannelBind over TCP, since >> the server might reject. > > I definitely think this is wrong. First, as I argued above, it's > up to the client how he wants to balance these risks. Second, > if the server rejects, the client may well want to simply drop > the connection, in which case it's hard to see why it shouldn't > it be optimistic? > > -Ekr > > > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 23 02:40:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHaDG-0001jn-Cf; Wed, 23 Jan 2008 02:39:58 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JHaDD-0001jb-R2 for behave-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 02:39:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHaDD-0001gf-Dd for behave@ietf.org; Wed, 23 Jan 2008 02:39:55 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHaDB-0006Fs-Js for behave@ietf.org; Wed, 23 Jan 2008 02:39:55 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0N7dH0O030713 for ; Wed, 23 Jan 2008 09:39:51 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 09:39:41 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 09:39:41 +0200 Received: from esdhcp04076.research.nokia.com ([172.21.40.76]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 09:39:41 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: Behave WG Date: Wed, 23 Jan 2008 09:39:53 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200801230939.54040.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 23 Jan 2008 07:39:41.0346 (UTC) FILETIME=[1D50A820:01C85D93] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [BEHAVE] TURN traffic amplification? 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 Hello, =46ollowing the discussion on preserving the TOS bits, I had been wondering= =20 whether TURN should also preserve the TTL. The case for this would mostly b= e=20 to reduce the risk of loops. I have considered this a bit more, and I am no= w=20 wondering if TURN won't provide a similar traffic amplification attack as t= he=20 IPv6-RH0 one. In one case, the client would create many TURN allocations between two=20 servers, recursively, i.e. making each new allocation through the previous= =20 allocation, and so on. With the current 4-bytes framing and the typical 1500 MTU, this allows=20 bouncing a single packet around 375 times on the path! In theory, if we do= =20 allow fragmentation, the amplification factor could go as high as 16000. I = am=20 willing to believe the IP reassembly buffers on the TURN servers would=20 explode way before this happens. But we may need to reconsider this issue=20 when TCP comes... If we specify that TURN servers must "decrement the TTL", the factor goes d= own=20 to (255 - distance_to_server) / distance_between_servers < 255. This is sti= ll=20 not quite good if the servers are very close, but a lot better anyway. As=20 such, I would think it's a good idea. Anyone? =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 23 09:50:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHgvS-0004R2-Fp; Wed, 23 Jan 2008 09:50:02 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JHgvR-0004QY-2c for behave-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 09:50:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHgvQ-0004QQ-Om for behave@ietf.org; Wed, 23 Jan 2008 09:50:00 -0500 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHgvO-0000sr-EY for behave@ietf.org; Wed, 23 Jan 2008 09:50:00 -0500 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id B721D5081A; Wed, 23 Jan 2008 06:51:34 -0800 (PST) Date: Wed, 23 Jan 2008 06:51:34 -0800 From: Eric Rescorla To: =?ISO-8859-1?Q?R=E9mi?= Denis-Courmont Subject: Re: [BEHAVE] TURN traffic amplification? In-Reply-To: <200801230939.54040.remi.denis-courmont@nokia.com> References: <200801230939.54040.remi.denis-courmont@nokia.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=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20080123145134.B721D5081A@romeo.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 At Wed, 23 Jan 2008 09:39:53 +0200, R=E9mi Denis-Courmont wrote: >=20 > Hello, >=20 > Following the discussion on preserving the TOS bits, I had been wondering= =20 > whether TURN should also preserve the TTL. The case for this would mostly= be=20 > to reduce the risk of loops. I have considered this a bit more, and I am = now=20 > wondering if TURN won't provide a similar traffic amplification attack as= the=20 > IPv6-RH0 one. >=20 > In one case, the client would create many TURN allocations between two=20 > servers, recursively, i.e. making each new allocation through the previou= s=20 > allocation, and so on. >=20 > With the current 4-bytes framing and the typical 1500 MTU, this allows=20 > bouncing a single packet around 375 times on the path! In theory, if we d= o=20 > allow fragmentation, the amplification factor could go as high as 16000. = I am=20 > willing to believe the IP reassembly buffers on the TURN servers would=20 > explode way before this happens. But we may need to reconsider this issue= =20 > when TCP comes... >=20 > If we specify that TURN servers must "decrement the TTL", the factor goes= down=20 > to (255 - distance_to_server) / distance_between_servers < 255. This is s= till=20 > not quite good if the servers are very close, but a lot better anyway. As= =20 > such, I would think it's a good idea. Anyone? This seems to be of extremely marginal value.=20 I'm also not sure it can be implemented. A quick look at FreeBSD's=20 man pages doesn't show any way to configure TTL on a per-socket level. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 23 11:50:23 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHinr-000371-Gu; Wed, 23 Jan 2008 11:50:19 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JHinq-00036u-Ds for behave-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 11:50:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHinq-00036m-23 for behave@ietf.org; Wed, 23 Jan 2008 11:50:18 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHinp-0006wa-Ah for behave@ietf.org; Wed, 23 Jan 2008 11:50:17 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 23 Jan 2008 08:50:16 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0NGoGdr032430; Wed, 23 Jan 2008 08:50:16 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0NGo73d020399; Wed, 23 Jan 2008 16:50:12 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 08:50:11 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 08:50:11 -0800 Message-ID: <47977032.1000004@cisco.com> Date: Wed, 23 Jan 2008 11:49:54 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #4: Port Adjacency References: <4759CC2B.9050206@cisco.com> <47620F8F.2060606@cisco.com> <4790C87C.4030607@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jan 2008 16:50:11.0159 (UTC) FILETIME=[049E2670:01C85DE0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3718; t=1201107016; x=1201971016; 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=20Issue=20#4=3A=20Port= 20Adjacency |Sender:=20; bh=Xvvy/4n5hYEuifFFuRRCnh43OxzgedzDxHnkNjsSxkM=; b=M/NCN1jvgfYAawukjxlwD+kDzP4RA1r6PVTiJxVA1pLFOh8jDK2echNdk5 a8+S2j8Kje2/uhscDBA3VAQrhgacgdpqDE04c+9dyAs2APsU4J8VtyT4QlBD +/kVGvcDDc; 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: b7b9551d71acde901886cc48bfc088a6 Cc: Rohan Mahy , 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 A couple of comments: Philip Matthews wrote: > The discussion on this point has been fairly quiet recently, so let me > try to summarize where we are at and make a proposal for how to resolve > this issue. > > I am definitely not an RTP expert, but here is what I understand to be > the use-case for this feature. Please correct me if I am wrong. > > Say X and Y are SIP UAs that want to communicate. Y is an old endpoint > that does RFC 1889 and expects RTCP on the next-higher port and does not > signal this fact. If X is behind a NAT (any type of NAT!) and Y has a > public IP address, then X and Y can communicate and use both RTP and > RTCP only if X allocates two adjacent ports on a TURN server with a > public IP address. > > As far as I can see, if Y is behind a NAT, then there is no easy way to > get this to work, because Y's NAT will most likely map Y's ports to > non-adjacent ports and there is no easy way to determine what Y's RTCP > port was mapped to. > > > > Given the above use-case and the fact that some people want to support > it, then here is my proposal to resolve this issue: > In an Allocate Request, a client can request that the server reserve > the next-higher port number. The server may or may not be able to do > this; for example, the server may not support this feature, no - this is not an optional feature. I don't want to negotiate this capability. or the > server may support it but be unable to find two adjacent ports. When the > server is not able to reserve the next-higher port, the server returns > an error code and thus the allocation attempt fails. At this point, the > client may give up and try a different server, or it may decided to > retry without the request to reserve the next-higher port. > If the server IS able to reserve the next-higher port, then it keeps > this reservation until (a) a client request that exact port number, or Minor correction - the SAME CLIENT requests that exact port number. Same means, uses the same credentials (username, pass, realm). > (b) the lower-numbered allocation expires. In case (a), this is > hopefully the client that reserved the lower-numbered port. I'm agnostic on whether (b) should be as you describe, or a short timeout (say 30s). > > > The only drawback I can see with this is that clients will need code to > retry the request if they are willing to proceed without the reserved > next-higher port. Assuming that the server cannot allocate it. THis would only happen if the server is running low on resources, presumably. In that case, any allocation might fail, for adjacent ports or not. > Thus this will cause some delay in gathering ICE > candidates. If this is seen as a big problem, then the alternative would > be for the server to do the allocation and return a flag saying that it > was not able to reserve the next-higher port. However, I don't really > like this since REQUESTED-PORT-PROPS can be used to request other > properties and it is not very clear how to generalize this (e.g., if you > request an odd port, can the server allocate an even one and say "sorry > but I could only find an even one to allocate"?). I don't want to do this. The request is for two ports. It should fail completely, or succeed completley. I hate dealing with partial success cases. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 23 16:41:30 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHnLd-0001kC-2Z; Wed, 23 Jan 2008 16:41:29 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JHnLb-0001jz-QV for behave-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 16:41:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHnLb-0001jr-GL for behave@ietf.org; Wed, 23 Jan 2008 16:41:27 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-08.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHnLa-0007yP-Rn for behave@ietf.org; Wed, 23 Jan 2008 16:41:27 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-08.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JHnLb-0001Sz-1F; Wed, 23 Jan 2008 16:41:27 -0500 In-Reply-To: <47977032.1000004@cisco.com> References: <4759CC2B.9050206@cisco.com> <47620F8F.2060606@cisco.com> <4790C87C.4030607@ericsson.com> <47977032.1000004@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1BCB74CC-CA0C-48EE-91B7-9DC0E9C06BCF@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #4: Port Adjacency Date: Wed, 23 Jan 2008 16:41:22 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: Rohan Mahy , 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 23-Jan-08, at 11:49 , Jonathan Rosenberg wrote: > A couple of comments: > > Philip Matthews wrote: >> The discussion on this point has been fairly quiet recently, so >> let me try to summarize where we are at and make a proposal for >> how to resolve this issue. >> I am definitely not an RTP expert, but here is what I understand >> to be the use-case for this feature. Please correct me if I am wrong. >> Say X and Y are SIP UAs that want to communicate. Y is an old >> endpoint that does RFC 1889 and expects RTCP on the next-higher >> port and does not signal this fact. If X is behind a NAT (any type >> of NAT!) and Y has a public IP address, then X and Y can >> communicate and use both RTP and RTCP only if X allocates two >> adjacent ports on a TURN server with a public IP address. >> As far as I can see, if Y is behind a NAT, then there is no easy >> way to get this to work, because Y's NAT will most likely map Y's >> ports to non-adjacent ports and there is no easy way to determine >> what Y's RTCP port was mapped to. >> Given the above use-case and the fact that some people want to >> support it, then here is my proposal to resolve this issue: >> In an Allocate Request, a client can request that the server >> reserve the next-higher port number. The server may or may not be >> able to do this; for example, the server may not support this >> feature, > > no - this is not an optional feature. I don't want to negotiate > this capability. Two comments on this: 1) I don't see any negotiation here. The client asks for this feature and is told "Sorry". The client doesn't know whether the "Sorry" is because the server can never do this, or just cannot do this right now. 2) In practice, I don't see the server not implementing features as a big deal. The client is not trying random TURN servers, rather the administrator as arranged for the client to be able to use certain servers. So the administrator knows the capabilities of the servers. If the administrator feels that support for this service is important, he/she will only sign contracts with TURN server providers that support this feature. BTW, both of these comments apply to the ChannelBind failure case as well. > > or the >> server may support it but be unable to find two adjacent ports. >> When the server is not able to reserve the next-higher port, the >> server returns an error code and thus the allocation attempt >> fails. At this point, the client may give up and try a different >> server, or it may decided to retry without the request to reserve >> the next-higher port. >> If the server IS able to reserve the next-higher port, then it >> keeps this reservation until (a) a client request that exact port >> number, or > > Minor correction - the SAME CLIENT requests that exact port number. > Same means, uses the same credentials (username, pass, realm). It may be that there is a unique username per client. But personally I suspect that, at least in some cases, there will be a large number of clients all provisioned with the same set of credentials. This is probably what I will suggest Avaya does, because it is easier. > >> (b) the lower-numbered allocation expires. In case (a), this is >> hopefully the client that reserved the lower-numbered port. > > I'm agnostic on whether (b) should be as you describe, or a short > timeout (say 30s). Yup. This is your original option 2b. > >> The only drawback I can see with this is that clients will need >> code to retry the request if they are willing to proceed without >> the reserved next-higher port. > > Assuming that the server cannot allocate it. THis would only happen > if the server is running low on resources, presumably. In that > case, any allocation might fail, for adjacent ports or not. Sure. > > >> Thus this will cause some delay in gathering ICE candidates. If >> this is seen as a big problem, then the alternative would be for >> the server to do the allocation and return a flag saying that it >> was not able to reserve the next-higher port. However, I don't >> really like this since REQUESTED-PORT-PROPS can be used to request >> other properties and it is not very clear how to generalize this >> (e.g., if you request an odd port, can the server allocate an even >> one and say "sorry but I could only find an even one to allocate"?). > > I don't want to do this. The request is for two ports. It should > fail completely, or succeed completley. I hate dealing with partial > success cases. I don't like this either. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 23 19:01:53 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHpXS-0004cJ-H6; Wed, 23 Jan 2008 19:01:50 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JHpXQ-0004bv-S1 for behave-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 19:01:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHpXQ-0004bk-GF for behave@ietf.org; Wed, 23 Jan 2008 19:01:48 -0500 Received: from wx-out-0506.google.com ([66.249.82.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHpXQ-0007rp-7x for behave@ietf.org; Wed, 23 Jan 2008 19:01:48 -0500 Received: by wx-out-0506.google.com with SMTP id s8so70711wxc.31 for ; Wed, 23 Jan 2008 16:01:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=6Pc9TKPuzxsMuUuX/9O1Dqjzuou0SSVw6ZHcFopYx+0=; b=s2mmuSlM9GexsUn+aPPyht2+fFDrMGj8w1n7pi52PomFu5qF41w6fWPq6Igu7afSz+PIAluCvSpgIRJv9p1tUBnAGMGH1ZT4KZy0VhrsEtL/be34ZrHP0rvlDX8haoZjX/2YGrzsvAzujRtKy/zBBNQ7eroc00a8Rrfo6QmSHlY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=orv7irYyj1A25IhMZs+F0gipRmKGEGAIxiVovmznkBwAOkDw4OEiMop3vaCU4kghDqof3WjAGrHod+WcBPR1DTNqrjwn3DmdqRWASFFOxGdtuK5fF7N6nnjN+EhnC3P2REhAWdXa4BDe7ZlyNHcNRelmO9+PmLRCHVTKz+QPp34= Received: by 10.143.164.19 with SMTP id r19mr5404532wfo.179.1201132906118; Wed, 23 Jan 2008 16:01:46 -0800 (PST) Received: by 10.142.105.16 with HTTP; Wed, 23 Jan 2008 16:01:46 -0800 (PST) Message-ID: <6d2996bb0801231601w14bb95dcl235b48c851cd3da3@mail.gmail.com> Date: Wed, 23 Jan 2008 19:01:46 -0500 From: "Saikat Guha" To: "Eric Rescorla" Subject: Re: [BEHAVE] TURN traffic amplification? In-Reply-To: <20080123145134.B721D5081A@romeo.rtfm.com> MIME-Version: 1.0 References: <200801230939.54040.remi.denis-courmont@nokia.com> <20080123145134.B721D5081A@romeo.rtfm.com> X-Google-Sender-Auth: ae86fceddc3cd5f4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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="===============0163819254==" Errors-To: behave-bounces@ietf.org --===============0163819254== Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline T24gSmFuIDIzLCAyMDA4IDk6NTEgQU0sIEVyaWMgUmVzY29ybGEgPGVrckBuZXR3b3JrcmVzb25h bmNlLmNvbT4gd3JvdGU6Cj4gUsOpbWkgRGVuaXMtQ291cm1vbnQgd3JvdGU6Cj4gPiB3b25kZXJp bmcgaWYgVFVSTiB3b24ndCBwcm92aWRlIGEgc2ltaWxhciB0cmFmZmljIGFtcGxpZmljYXRpb24g YXR0YWNrIGFzIHRoZQo+ID4gSVB2Ni1SSDAgb25lLgoKT25lIGRpZmZlcmVuY2Ugd2l0aCBSSDAg aXMgdGhhdCBmb3IgVFVSTiBvbmUgY2Fubm90IGZpcmUgdGhlIHBhY2tldCBhdAphbnkgb2RkIFRV Uk4gc2VydmVyIC0tLSBvbmx5IHRvIHNlcnZlcnMgdGhhdCBhbGxvd3MgdGhlIGF0dGFja2VyIHRv CmNyZWF0ZSBhbiBhbGxvY2F0aW9uIG9uIHRoZSBzZXJ2ZXIuIFRoZSBhdHRhY2sgc3VyZmFjZSBp cyBtdWNoCnNtYWxsZXIuCgo+IEknbSBhbHNvIG5vdCBzdXJlIGl0IGNhbiBiZSBpbXBsZW1lbnRl ZC4gQSBxdWljayBsb29rIGF0IEZyZWVCU0Qncwo+IG1hbiBwYWdlcyBkb2Vzbid0IHNob3cgYW55 IHdheSB0byBjb25maWd1cmUgVFRMIG9uIGEgcGVyLXNvY2tldCBsZXZlbC4KClRoZSBJUF9IRFJJ TkNMIHNvY2tldCBvcHRpb24gYWxsb3dzIHRoZSBhcHAgdG8gcHJvdmlkZSBwZXItc29ja2V0IElQ CmhlYWRlciBiaXRzOyAoc3VwcG9zZWQgdG8pIHdvcmsgZm9yIGJvdGggVURQIGFuZCBUQ1Agc29j a2V0cyBJSVJDLgpEb2Vzbid0IHdvcmsgdW5kZXIgV2luZG93cyBmb3IgVENQIHNvY2tldHMgdGhv dWdoIGxhc3QgSSBjaGVja2VkLgoKLS0gClNhaWthdAo= --===============0163819254== 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 --===============0163819254==-- From behave-bounces@ietf.org Wed Jan 23 19:47:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHqFB-0007yI-Bm; Wed, 23 Jan 2008 19:47:01 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JHqF9-0007we-V3 for behave-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 19:46:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHqF9-0007wW-LA for behave@ietf.org; Wed, 23 Jan 2008 19:46:59 -0500 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHqF9-0005JM-79 for behave@ietf.org; Wed, 23 Jan 2008 19:46:59 -0500 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 97B1A5081A; Wed, 23 Jan 2008 16:48:35 -0800 (PST) Date: Wed, 23 Jan 2008 16:48:35 -0800 From: Eric Rescorla To: "Saikat Guha" Subject: Re: [BEHAVE] TURN traffic amplification? In-Reply-To: <6d2996bb0801231601w14bb95dcl235b48c851cd3da3@mail.gmail.com> References: <200801230939.54040.remi.denis-courmont@nokia.com> <20080123145134.B721D5081A@romeo.rtfm.com> <6d2996bb0801231601w14bb95dcl235b48c851cd3da3@mail.gmail.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=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20080124004835.97B1A5081A@romeo.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 At Wed, 23 Jan 2008 19:01:46 -0500, Saikat Guha wrote: >=20 > On Jan 23, 2008 9:51 AM, Eric Rescorla wrote: > > R=E9mi Denis-Courmont wrote: > > > wondering if TURN won't provide a similar traffic amplification attac= k as the > > > IPv6-RH0 one. >=20 > One difference with RH0 is that for TURN one cannot fire the packet at > any odd TURN server --- only to servers that allows the attacker to > create an allocation on the server. The attack surface is much > smaller. >=20 > > I'm also not sure it can be implemented. A quick look at FreeBSD's > > man pages doesn't show any way to configure TTL on a per-socket level. >=20 > The IP_HDRINCL socket option allows the app to provide per-socket IP > header bits; (supposed to) work for both UDP and TCP sockets IIRC. > Doesn't work under Windows for TCP sockets though last I checked. Here's what the man page says about that: IP_HDRINCL indicates the complete IP header is included with the data = and may be used only with the SOCK_RAW type. That seems problematic. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 23 20:15:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHqgw-0000Jj-AB; Wed, 23 Jan 2008 20:15:42 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JHqgv-0000JU-6C for behave-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 20:15:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHqgu-0000JM-RL for behave@ietf.org; Wed, 23 Jan 2008 20:15:40 -0500 Received: from nz-out-0506.google.com ([64.233.162.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHqgu-0005w5-DR for behave@ietf.org; Wed, 23 Jan 2008 20:15:40 -0500 Received: by nz-out-0506.google.com with SMTP id n1so27821nzf.4 for ; Wed, 23 Jan 2008 17:15:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=vdk3R09byB01sMaJm5lcAXSklhI5bY9w4JokxslWvXA=; b=MpY9W/lRz/NOpNjwm/uYkr1OpV5sF1YRQRety80qf/vF7AAaWtXYrexkTP4dyRd0zko4a/PTG907lZ/uTP9/GWH0VrwIw/obcGUM5/qrttu0z1HhrAoRXsaOFGpi8iOQZa6QAnE+mABj2b3hbnw5M4JQlXyX0Vtxl9pXcSRm9hA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=pVRV3YoNiH3rTWtgWdMF7cCaW+YCUbE6opMf0fjygQAutmlHYok4OA+u9wTqxi7CwZe2VUK0awIMsUeVMQY546LUhKLpikJ8mIsNrEsjQR6/KmTnBhPC6aazb0I9uObvkh/CtKyHtoy7Mre86GwLhNmyC8C+R8PB7ymi7rF91Yw= Received: by 10.142.73.8 with SMTP id v8mr12624wfa.68.1201137339590; Wed, 23 Jan 2008 17:15:39 -0800 (PST) Received: by 10.142.105.16 with HTTP; Wed, 23 Jan 2008 17:15:39 -0800 (PST) Message-ID: <6d2996bb0801231715r3ba9623fg692f2efac1fcaac2@mail.gmail.com> Date: Wed, 23 Jan 2008 20:15:39 -0500 From: "Saikat Guha" To: "Eric Rescorla" Subject: Re: [BEHAVE] TURN traffic amplification? In-Reply-To: <20080124004835.97B1A5081A@romeo.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200801230939.54040.remi.denis-courmont@nokia.com> <20080123145134.B721D5081A@romeo.rtfm.com> <6d2996bb0801231601w14bb95dcl235b48c851cd3da3@mail.gmail.com> <20080124004835.97B1A5081A@romeo.rtfm.com> X-Google-Sender-Auth: fb891e74db166000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 Jan 23, 2008 7:48 PM, Eric Rescorla wrote: > At Wed, 23 Jan 2008 19:01:46 -0500, > IP_HDRINCL indicates the complete IP header is included with the data and > may be used only with the SOCK_RAW type. > > That seems problematic. Oops, yes, you are right. There is another option then, IP_TTL maybe? I am pretty sure I have successfully set the TTL under Linux at some point. -- Saikat _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 23 22:26:42 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHsjf-0003T0-UR; Wed, 23 Jan 2008 22:26:40 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JHsjd-0003Su-On for behave-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 22:26:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHsjd-0003Sm-Df for behave@ietf.org; Wed, 23 Jan 2008 22:26:37 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHsjc-0004If-Vl for behave@ietf.org; Wed, 23 Jan 2008 22:26:37 -0500 X-IronPort-AV: E=Sophos;i="4.25,241,1199692800"; d="scan'208";a="9463732" Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 23 Jan 2008 19:26:28 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id m0O3QSQp032469; Wed, 23 Jan 2008 19:26:28 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0O3QS3V000812; Thu, 24 Jan 2008 03:26:28 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 19:26:28 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 19:26:27 -0800 Message-ID: <47980553.4090905@cisco.com> Date: Wed, 23 Jan 2008 22:26:11 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [BEHAVE] TURN Issue: Codepoints for errors References: <6066E435-B304-4616-A9B3-353FC42FFCE1@magma.ca> In-Reply-To: <6066E435-B304-4616-A9B3-353FC42FFCE1@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2008 03:26:27.0728 (UTC) FILETIME=[E7A04900:01C85E38] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2112; t=1201145188; x=1202009188; c=relaxed/simple; s=sjdkim8002; 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=20Issue=3A=20Codepoints =20for=20errors |Sender:=20; bh=+BT50XxY5HiC3aqf9O4a7GZeSc9PDpKmZeftBiHrKV8=; b=YrNar4FDpfllbXzowwp+WN2rggSxZmjQ5gjseFA3cZMrxrpliZapF1Likm Kg1POKxrs/bgoLqO/NZ+zCl6JTxq33ht1SQHCwP58Lnk6/OqcG0C8hKYKEeN XKIx9KXX21; Authentication-Results: sj-dkim-8; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 I agree completely with Rohan. I've been through this a gazillion times with protocol design. There is absolutely, positively, NO VALUE in defining codepoints which basically say, "the spec said you were supposed to include this header formatted this way, but you didn't". These errors ONLY occur as a consequence of implementation error, and they are utterly unrecoverable. Thus, rather than adding a slew of error codes for addressing each and every syntax error that can happen (and this IS a syntax error), we should just use one code - 400. -Jonathan R. Philip Matthews wrote: > TURN-06 proposes three new error codes: > > (tbd) (Channel Number Missing or Invalid): The request requires a > channel number, but the CHANNEL-NUMBER attribute is missing, or > the specified channel number is invalid in some way. > > (tbd) (Peer Address Missing or Invalid): The request requires a peer > transport address, but the PEER-ADDRESS attribute is missing, or > the specified peer transport address is invalid in some way. > > (tbd) (Lifetime Malformed or Invalid): The LIFETIME attribute is > malformed or the specified lifetime is invalid in some way. > > > Rohan has proposed that these three codepoints be eliminated, and we > just use 400 Bad Request. Does anyone care about this? > > Note that an implementation is always free to change the text associated > with a codepoint, so it could say something like 400 "Channel Number > Missing or Invalid". This is not something that we have specified > before with STUN, but it is something allowed by the spec. > > - Philip > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 23 22:28:48 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHslk-0006zt-0i; Wed, 23 Jan 2008 22:28:48 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JHsli-0006zo-IJ for behave-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 22:28:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHsli-0006zg-6m for behave@ietf.org; Wed, 23 Jan 2008 22:28:46 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHslh-0004L2-4i for behave@ietf.org; Wed, 23 Jan 2008 22:28:46 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 23 Jan 2008 19:28:44 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0O3SiMK005452; Wed, 23 Jan 2008 19:28:44 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0O3SZj5018162; Thu, 24 Jan 2008 03:28:35 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); Wed, 23 Jan 2008 19:28:35 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 19:28:34 -0800 Message-ID: <479805D2.5060609@cisco.com> Date: Wed, 23 Jan 2008 22:28:18 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [BEHAVE] TURN Issue: How important are channels anyway? References: <478CE9AE.9080102@cisco.com> <3020DC10-80F2-4241-819C-D7B15A00A436@magma.ca> <8AF575A5-99E0-456C-973C-579B8B4C32E3@magma.ca> <20080121205858.1393F5081A@romeo.rtfm.com> <20080121212149.2698A5081A@romeo.rtfm.com> <631A1726-0496-4CDC-A893-BA8419154D8F@magma.ca> <47962D90.5020808@cisco.com> <20080122194727.1E7035081A@romeo.rtfm.com> <32C5979F-5CEF-4EE7-A1BD-F05B5FF0ACDB@magma.ca> In-Reply-To: <32C5979F-5CEF-4EE7-A1BD-F05B5FF0ACDB@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2008 03:28:34.0931 (UTC) FILETIME=[3371EC30:01C85E39] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2875; t=1201145324; x=1202009324; 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=20Issue=3A=20How=20impo rtant=20are=20channels=20anyway? |Sender:=20; bh=39qjbkR0ZcDHQINoekzymgJoR4DM7XUiYV95UGcqi1w=; b=WrHe4ZV5aU/p0xV7CE/9mWL3qOcRAe8U2G/Slk8ig4tlDEoUdy8ZO4S1aS 4AXmHDo0inV3In+iUvfsLBUTR8L6Yn81uROPwVyulQeMCXF3dbmqToshSqMr Hkc58Xqvt+; 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: b7b9551d71acde901886cc48bfc088a6 Cc: Rohan Mahy , 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 I agree with what Ekr is saying. And I think the probability of rejecting CHannelBind is low - really low. I don't buy this argument about running out of memory or some other such thing. -Jonathan R. Philip Matthews wrote: > Eric: > > If I understand your proposal correctly, you would like to see the > document list the consequences of sending a ChannelData message before > receiving a ChannelBind success response, where the two consequences > are: (1) over UDP, the ChannelBind request might be lost, and (2) over > any transport, the server might reject the ChannelBind request. The > document would then say "the client MAY send in this situation". > > I believe you think that (2) is possible, but think it is very unlikely. > I personally think the chances are a bit higher. But I would suggest we > just be silent about probabilities. > > I am happy with this change. As you point out, letting clients send or > not in this case does not break interoperability or have bad network > side-effects. The only side-effect is possible lost packets. > > Any comments from anyone else? > > - Philip > > > > > - Philip > > On 22-Jan-08, at 14:47 , Eric Rescorla wrote: > >> At Tue, 22 Jan 2008 14:37:29 -0500, >> Philip Matthews wrote: >>> >>> The spec currently says: >>> Over UDP, the client SHOULD NOT send ChannelData messages on the >>> channel until it has received a ChannelBind Success Response for the >>> binding attempt. Sending them before the success response is >>> received risks having them dropped by the server if he ChannelBind >>> Request was lost. >> >> I actually think this is wrong. >> >> In the vast majority of cases the ChannelBind will work (if this >> isn't true your network is likely unusably hosed). Since >> the consequences of sending ChannelData prior to a ChannelBind >> success is purely that the ChannelData gets dropped, this isn't >> an interop issue and it should be up to the client what it >> wants to do. >> >> The spec should simply describe the possible cases and be >> silent on recommendations. >> >> >>> In my opinion, the same should apply for ChannelBind over TCP, since >>> the server might reject. >> >> I definitely think this is wrong. First, as I argued above, it's >> up to the client how he wants to balance these risks. Second, >> if the server rejects, the client may well want to simply drop >> the connection, in which case it's hard to see why it shouldn't >> it be optimistic? >> >> -Ekr >> >> >> >> > > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 23 22:32:32 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHspM-00035s-4p; Wed, 23 Jan 2008 22:32:32 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JHspL-00033B-9v for behave-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 22:32:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHspK-00031e-VD for behave@ietf.org; Wed, 23 Jan 2008 22:32:30 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHspJ-0008CI-VI for behave@ietf.org; Wed, 23 Jan 2008 22:32:30 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-6.cisco.com with ESMTP; 23 Jan 2008 19:32:29 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id m0O3WTD3032529; Wed, 23 Jan 2008 19:32:29 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0O3W73p004415; Thu, 24 Jan 2008 03:32:20 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); Wed, 23 Jan 2008 19:32:20 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 19:32:19 -0800 Message-ID: <479806B3.2030701@cisco.com> Date: Wed, 23 Jan 2008 22:32:03 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #4: Port Adjacency References: <4759CC2B.9050206@cisco.com> <47620F8F.2060606@cisco.com> <4790C87C.4030607@ericsson.com> <47977032.1000004@cisco.com> <1BCB74CC-CA0C-48EE-91B7-9DC0E9C06BCF@magma.ca> In-Reply-To: <1BCB74CC-CA0C-48EE-91B7-9DC0E9C06BCF@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2008 03:32:19.0853 (UTC) FILETIME=[B9824BD0:01C85E39] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3668; t=1201145549; x=1202009549; c=relaxed/simple; s=sjdkim7002; 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=20Issue=20#4=3A=20Port= 20Adjacency |Sender:=20; bh=FIB3TEOh320Ky3guBpUk+kBt29iqhOcVR8cYOI821tY=; b=OhZXnt23GYG9gAucVzbgySj3xd8y0kMHC67teEb3CmGen+ObApRFjVjcyS YbU+uuMAmzQ4vjAswvqr8E1Imv3k5LU3K251nJ5D3UtyDagtg5hvEm1twXmx g1DtCleqpU; Authentication-Results: sj-dkim-7; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Rohan Mahy , 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: Philip Matthews wrote: > > On 23-Jan-08, at 11:49 , Jonathan Rosenberg wrote: > >> A couple of comments: >> >> Philip Matthews wrote: >>> The discussion on this point has been fairly quiet recently, so let >>> me try to summarize where we are at and make a proposal for how to >>> resolve this issue. >>> I am definitely not an RTP expert, but here is what I understand to >>> be the use-case for this feature. Please correct me if I am wrong. >>> Say X and Y are SIP UAs that want to communicate. Y is an old >>> endpoint that does RFC 1889 and expects RTCP on the next-higher port >>> and does not signal this fact. If X is behind a NAT (any type of >>> NAT!) and Y has a public IP address, then X and Y can communicate and >>> use both RTP and RTCP only if X allocates two adjacent ports on a >>> TURN server with a public IP address. >>> As far as I can see, if Y is behind a NAT, then there is no easy way >>> to get this to work, because Y's NAT will most likely map Y's ports >>> to non-adjacent ports and there is no easy way to determine what Y's >>> RTCP port was mapped to. >>> Given the above use-case and the fact that some people want to >>> support it, then here is my proposal to resolve this issue: >>> In an Allocate Request, a client can request that the server >>> reserve the next-higher port number. The server may or may not be >>> able to do this; for example, the server may not support this feature, >> >> no - this is not an optional feature. I don't want to negotiate this >> capability. > > Two comments on this: > 1) I don't see any negotiation here. The client asks for this feature > and is told "Sorry". The client doesn't know whether the "Sorry" is > because the server can never do this, or just cannot do this right now. Its 'negotiation' in that, now the client has to be prepared for the case where the server doesn't support the thing. I want to make it so that failure of these requests is rare - corner cases like capacity failures under overload. I DONT want it to become a common case, because the server decided to reject due to lack of support for the feature. Protocol options complicate things. THis is a protocol option I don't want. All servers MUST implement this capability, and MUST either fully accept the request, or fully reject it. Do, or do not. There is no try. -Jedi Master Yoda > 2) In practice, I don't see the server not implementing features as a > big deal. The client is not trying random TURN servers, rather the > administrator as arranged for the client to be able to use certain > servers. So the administrator knows the capabilities of the servers. If > the administrator feels that support for this service is important, > he/she will only sign contracts with TURN server providers that support > this feature. It still means client software has to be prepared for all of these cases. Please, there is NO REASON for this optionality. > > BTW, both of these comments apply to the ChannelBind failure case as well. No. That request should fail almost never. I just commented on this in another thread. ANd that means clients don't need to implement failure cases like, 'my server doesn't support it'. ChannelBind is a MUST implement and support on the server, full stop. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jan 24 02:16:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHwKT-0008OP-CT; Thu, 24 Jan 2008 02:16:53 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JHwKR-0008OE-CB for behave-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 02:16:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHwKQ-0008Nq-Ma for behave@ietf.org; Thu, 24 Jan 2008 02:16:50 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHwKP-0003d7-5G for behave@ietf.org; Thu, 24 Jan 2008 02:16:50 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0O7FqHw005942; Thu, 24 Jan 2008 09:16:47 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jan 2008 09:16:32 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jan 2008 09:16:31 +0200 Received: from esdhcp04076.research.nokia.com ([172.21.40.76]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jan 2008 09:16:31 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Eric Rescorla" Subject: Re: [BEHAVE] TURN traffic amplification? Date: Thu, 24 Jan 2008 09:16:45 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200801230939.54040.remi.denis-courmont@nokia.com> <20080123145134.B721D5081A@romeo.rtfm.com> In-Reply-To: <20080123145134.B721D5081A@romeo.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200801240916.46050.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 24 Jan 2008 07:16:31.0728 (UTC) FILETIME=[0B738700:01C85E59] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 Le Wednesday 23 January 2008 16:51:34 ext Eric Rescorla, vous avez =E9crit= =A0: > I'm also not sure it can be implemented. A quick look at FreeBSD's > man pages doesn't show any way to configure TTL on a per-socket level. I doubt anything with "BSD" in its name would lack the ability to do=20 traceroute or send multicast traffic beyond the local subnet. =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 Jan 24 02:21:11 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHwOd-0003mc-7J; Thu, 24 Jan 2008 02:21:11 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JHwOc-0003mS-Jj for behave-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 02:21:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHwOc-0003mD-9u for behave@ietf.org; Thu, 24 Jan 2008 02:21:10 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHwOZ-0003iv-RX for behave@ietf.org; Thu, 24 Jan 2008 02:21:10 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0O7KUhP011920; Thu, 24 Jan 2008 09:21:04 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jan 2008 09:20:24 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jan 2008 09:20:24 +0200 Received: from esdhcp04076.research.nokia.com ([172.21.40.76]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jan 2008 09:20:24 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Dan Wing" , Behave WG Subject: Re: [BEHAVE] TURN traffic amplification? Date: Thu, 24 Jan 2008 09:20:39 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200801230939.54040.remi.denis-courmont@nokia.com> <550b01c85def$d5abc470$c3f0200a@cisco.com> In-Reply-To: <550b01c85def$d5abc470$c3f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200801240920.39281.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 24 Jan 2008 07:20:24.0822 (UTC) FILETIME=[9662D960:01C85E59] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 23 January 2008 20:43:23 ext Dan Wing, vous avez =E9crit=A0: > The TURN client which is doing this traffic amplification would > need to be an authorized user on both of those TURN servers, right? Yes. However some TURN servers may have a very low entry barrier. Imagine=20 Gtalk, AIM or MSN providing VoIP service with TURN to their users for=20 instance. =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 Jan 24 07:58:42 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI1fF-0007lL-4G; Thu, 24 Jan 2008 07:58:41 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JI1fE-0007kH-7l for behave-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 07:58:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI1fD-0007k6-SY for behave@ietf.org; Thu, 24 Jan 2008 07:58:39 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JI1fD-0002sR-Iq for behave@ietf.org; Thu, 24 Jan 2008 07:58:39 -0500 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id A505B1C00E4; Thu, 24 Jan 2008 13:58:38 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 9F9B51C0098; Thu, 24 Jan 2008 13:58:38 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 91F1758ECBD; Thu, 24 Jan 2008 13:58:38 +0100 (CET) Date: Thu, 24 Jan 2008 13:58:38 +0100 From: Stephane Bortzmeyer To: =?iso-8859-1?Q?R=E9mi?= Denis-Courmont Message-ID: <20080124125838.GA24458@nic.fr> References: <200801230939.54040.remi.denis-courmont@nokia.com> <20080123145134.B721D5081A@romeo.rtfm.com> <200801240916.46050.remi.denis-courmont@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <200801240916.46050.remi.denis-courmont@nokia.com> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Behave WG Subject: [BEHAVE] Re: TURN traffic amplification? 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 Thu, Jan 24, 2008 at 09:16:45AM +0200, R=E9mi Denis-Courmont wrote=20 a message of 15 lines which said: > I doubt anything with "BSD" in its name would lack the ability to do > traceroute or send multicast traffic beyond the local subnet. Yes, but may be only with raw sockets, meaning you need to be root, which is certainly a problem. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jan 24 08:25:29 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI257-0003Ry-6n; Thu, 24 Jan 2008 08:25:25 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JI255-0003Rt-Nj for behave-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 08:25:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI255-0003Rl-Dr for behave@ietf.org; Thu, 24 Jan 2008 08:25:23 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JI254-0004IV-Rx for behave@ietf.org; Thu, 24 Jan 2008 08:25:23 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0ODPJ49000429; Thu, 24 Jan 2008 15:25:20 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jan 2008 15:24:44 +0200 Received: from esdhcp04076.research.nokia.com ([172.21.40.76]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jan 2008 15:24:44 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Stephane Bortzmeyer" Date: Thu, 24 Jan 2008 15:25:00 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200801230939.54040.remi.denis-courmont@nokia.com> <200801240916.46050.remi.denis-courmont@nokia.com> <20080124125838.GA24458@nic.fr> In-Reply-To: <20080124125838.GA24458@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200801241525.00848.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 24 Jan 2008 13:24:45.0037 (UTC) FILETIME=[7C16F1D0:01C85E8C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Behave WG Subject: [BEHAVE] Re: TURN traffic amplification? 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 24 January 2008 14:58:38 ext Stephane Bortzmeyer, vous avez=20 =E9crit=A0: > On Thu, Jan 24, 2008 at 09:16:45AM +0200, > R=E9mi Denis-Courmont wrote > > a message of 15 lines which said: > > I doubt anything with "BSD" in its name would lack the ability to do > > traceroute or send multicast traffic beyond the local subnet. > > Yes, but may be only with raw sockets, meaning you need to be root, > which is certainly a problem. Needing root to send multicast packets, that would be seriously brain=20 damaged... =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 Jan 24 13:17:06 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI6dM-0005Ed-Fn; Thu, 24 Jan 2008 13:17:04 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JI6dL-0005DG-H4 for behave-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 13:17:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI6dL-00058p-2z for behave@ietf.org; Thu, 24 Jan 2008 13:17:03 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JI6dK-0006U9-AV for behave@ietf.org; Thu, 24 Jan 2008 13:17:02 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id m0OIEvU00320; Thu, 24 Jan 2008 10:14:58 -0800 In-Reply-To: <479806B3.2030701@cisco.com> References: <4759CC2B.9050206@cisco.com> <47620F8F.2060606@cisco.com> <4790C87C.4030607@ericsson.com> <47977032.1000004@cisco.com> <1BCB74CC-CA0C-48EE-91B7-9DC0E9C06BCF@magma.ca> <479806B3.2030701@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <46A232B2-BFCB-4115-B686-EB78CB181ACB@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [BEHAVE] TURN Issue #4: Port Adjacency Date: Thu, 24 Jan 2008 10:14:55 -0800 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.753) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Rohan Mahy , Behave WG , Philip Matthews 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 agree with JDR (and Master Yoda) on this one. thanks, -rohan On Jan 23, 2008, at 7:32 PM, Jonathan Rosenberg wrote: > inline: > > Philip Matthews wrote: >> On 23-Jan-08, at 11:49 , Jonathan Rosenberg wrote: >>> A couple of comments: >>> >>> Philip Matthews wrote: >>>> The discussion on this point has been fairly quiet recently, so >>>> let me try to summarize where we are at and make a proposal for >>>> how to resolve this issue. >>>> I am definitely not an RTP expert, but here is what I understand >>>> to be the use-case for this feature. Please correct me if I am >>>> wrong. >>>> Say X and Y are SIP UAs that want to communicate. Y is an old >>>> endpoint that does RFC 1889 and expects RTCP on the next-higher >>>> port and does not signal this fact. If X is behind a NAT (any >>>> type of NAT!) and Y has a public IP address, then X and Y can >>>> communicate and use both RTP and RTCP only if X allocates two >>>> adjacent ports on a TURN server with a public IP address. >>>> As far as I can see, if Y is behind a NAT, then there is no easy >>>> way to get this to work, because Y's NAT will most likely map >>>> Y's ports to non-adjacent ports and there is no easy way to >>>> determine what Y's RTCP port was mapped to. >>>> Given the above use-case and the fact that some people want to >>>> support it, then here is my proposal to resolve this issue: >>>> In an Allocate Request, a client can request that the server >>>> reserve the next-higher port number. The server may or may not >>>> be able to do this; for example, the server may not support this >>>> feature, >>> >>> no - this is not an optional feature. I don't want to negotiate >>> this capability. >> Two comments on this: >> 1) I don't see any negotiation here. The client asks for this >> feature and is told "Sorry". The client doesn't know whether the >> "Sorry" is because the server can never do this, or just cannot do >> this right now. > > Its 'negotiation' in that, now the client has to be prepared for > the case where the server doesn't support the thing. I want to make > it so that failure of these requests is rare - corner cases like > capacity failures under overload. I DONT want it to become a common > case, because the server decided to reject due to lack of support > for the feature. > > Protocol options complicate things. THis is a protocol option I > don't want. All servers MUST implement this capability, and MUST > either fully accept the request, or fully reject it. > > Do, or do not. There is no try. > -Jedi Master Yoda > > >> 2) In practice, I don't see the server not implementing features >> as a big deal. The client is not trying random TURN servers, >> rather the administrator as arranged for the client to be able to >> use certain servers. So the administrator knows the capabilities >> of the servers. If the administrator feels that support for this >> service is important, he/she will only sign contracts with TURN >> server providers that support this feature. > > It still means client software has to be prepared for all of these > cases. Please, there is NO REASON for this optionality. > >> BTW, both of these comments apply to the ChannelBind failure case >> as well. > > No. That request should fail almost never. I just commented on this > in another thread. ANd that means clients don't need to implement > failure cases like, 'my server doesn't support it'. ChannelBind is > a MUST implement and support on the server, full stop. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jan 24 17:17:00 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIANV-0007uE-J7; Thu, 24 Jan 2008 17:16:57 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JIANT-0007tb-1s for behave-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 17:16:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIANS-0007ry-NS for behave@ietf.org; Thu, 24 Jan 2008 17:16:54 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-05.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIANS-00028v-CC for behave@ietf.org; Thu, 24 Jan 2008 17:16:54 -0500 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JIAMf-0002qv-25; Thu, 24 Jan 2008 17:16:05 -0500 In-Reply-To: <47980553.4090905@cisco.com> References: <6066E435-B304-4616-A9B3-353FC42FFCE1@magma.ca> <47980553.4090905@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8B9608DC-F72B-422D-9ECF-6B79A3E449DD@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue: Codepoints for errors Date: Thu, 24 Jan 2008 17:16:50 -0500 To: Behave WG X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Rohan Mahy 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 Philip Matthews wrote: > TURN-06 proposes three new error codes: > (tbd) (Channel Number Missing or Invalid): The request requires a > channel number, but the CHANNEL-NUMBER attribute is missing, or > the specified channel number is invalid in some way. > (tbd) (Peer Address Missing or Invalid): The request requires a > peer > transport address, but the PEER-ADDRESS attribute is missing, or > the specified peer transport address is invalid in some way. > (tbd) (Lifetime Malformed or Invalid): The LIFETIME attribute is > malformed or the specified lifetime is invalid in some way. Is there anyone who feels there should be explicit error codes for these errors? If not, the next version of TURN will just use 400 Bad Request for these errors. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 25 01:40:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIIEQ-0008Pv-Gn; Fri, 25 Jan 2008 01:40:06 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JIIEM-0008Po-B4 for behave-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 01:40:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIIEL-0008Pc-Kq for behave@ietf.org; Fri, 25 Jan 2008 01:40:01 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JIIEK-0002t6-Oo for behave@ietf.org; Fri, 25 Jan 2008 01:40:01 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 24 Jan 2008 22:39:59 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m0P6dxsM005383; Thu, 24 Jan 2008 22:39:59 -0800 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 m0P6drj6012150; Fri, 25 Jan 2008 06:39:59 GMT Message-Id: From: Cullen Jennings To: Philip Matthews , Behave WG Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Thu, 24 Jan 2008 22:39:46 -0800 X-Mailer: Apple Mail (2.915) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5381; t=1201243199; x=1202107199; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20TURN=2006=20Comments |Sender:=20; bh=kbWY60DBKfXGSis3pLAixchfq1btW3d4l0ufe112dag=; b=lwI/fCBz6X6goch+wUtU51RUyMzWoEk2ehKwSaMcMLXxK7g4+P2w1dDc0a AO/osIrCrQvUyyyCgHojrWvxbKnmcRcOByibNE20jtGqmwLHXmhHHl1GHFoL //7r5yBYse; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 1.2 (+) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: Subject: [BEHAVE] TURN 06 Comments 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 Gave the document a quick skim. Few comments .... The whole design of refreshing and lifetimes of allocations and permissions seems very disjoint and sub optimal. I would be tempted to go with allocation go away 30 seconds after they have no valid permissions. Permissions can be updated by client sending data or zero length send. Permissions durations match BEHAVE UDP documents. Much of the discussions around permissions make them sound like they are not bound to a specific allocation and instead the permissions is granted to the whole TURN server. This needs to be cleaned up. (Normative stuff looks right). I view the whole redirect to another TURN server as a really bad idea. Not to mention that it conflicts with the 3489 usage of this but even worse, it is highly likely to cause things to fail during overload in a way where the overloaded machine gets bounced around and the system never recovers. I think the SRV mechanisms are sufficient for load balancing, work well, and we should get rid of this stuff. Not a big deal but I don't like the waiting to 3/4 of LIFETIME, If the lifetime is 7200 this is way too early - I would prefer something more like LIFETIME minus 5 seconds and some introduction of jitter. section 5.2, 2nd bullet point. It looks like it always replies with 437 to a request over TCP. I might just be reading this wrong. Bandwidth - section 5.2.1.1 I would not want to use the words" determines if there is sufficient capacity" as this may be very hard to do, instead something like "decide if willing to grant this bandwidth". The contract is not guaranteeing a minimum, it is setting a max and suggesting a best attempts will be made to do minimum, We still need to specify the algo for computing this. Section 5.2.1.4: One of the key design points of this protocols is that you can not use it to pick an arbitrary port number to run over. This seems to change that and that is one of the things I feel very strong about. You need to support paired ports for RTP/RTCP because TURN is the last line of defense that is supposed to always work. I am fine with a protocol where the client asks for a pair and gets X and knows that X+1 is reserved and then requests X+1. I am not ok with a protocol where the client gets to choose the port the server uses. 5.2.1.6, 2nd para. The idea that "standard services" run on ports below 1024 does not seem true. Section 6.3 - This should be reworded to say what goes in the UDP payload and then a UDP packets is sent. Once we start talking about forming UDP checksums, it is a sign something is not right :-) Section 7.5, first para. Where you have SHOULD use the Channel-Data, I think that has to be a MUST. The server has no way of knowing what the clients bandwidth issues are thus cannot make a reasonable determination. Section 2.1. para 2. I find this paragraph somewhat bogus. The visibility of peers to attacker between client and TURN server is not a threat model I have seen brought up before. Doubt it is relevant. I find the argument that TLS has better success rate of traversing firewalls than TCP to be, uh, unproven at best. Section 12 The whole document (not just this section) seems a bit weak on short and long term credentials. My understanding is that we don't want to create unauthenticated open relays. So even if anyone can get an account on a public server, we still want to be able to log what account did what. My recollection of previous conversations when doing STUN bis was the allocated were going to use long term credentials and help set up the short term credentials used to authenticate the data, send, and channel data. I'm not claiming I corruptly remember any of this but either way, still looks like some work needed here on how this is all authorized. As a trivial side note, it looks like some of the issues with NAT remote in section 12 could be substantially mitigated by clients choosing random channel numbers. On the open issues, I don't actually think all of these are open: 1) thought we agreed to do this 2) I think we agreed address-restricted. I suspect I was the only person arguing for address-and-port and well, I loose :-) 3) we need this 4) uh, we are looking for a demux simpler than bit mask 2 bits? Surely you are joking :-) Actually I have no idea if we are done or not here. I think we need to go think carefully about all the demux. 6) any reason why not? 8) I found Magnus and Lars emails about this pretty much sold me on the answer 10) A client should only be able to request an IP address returned in allocate response fro the same server and for a allocation that is still valid. 11) we should make this the same as the BEHAVE UDP documents. Note that choices other than this will result in the same long discussions over again and be difficult to implement for some styles of implementations (i.e. windows or unix not running as root). 12, 14 - see previous comments on this 15 - I don't care but my gut feeling is put on v4/v6 relays for now. Or at least make sure you have the support of the v6ops community before you do it. Cullen _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 25 02:32:55 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIJ3W-00052s-7l; Fri, 25 Jan 2008 02:32:54 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JIJ3V-00052l-En for behave-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 02:32:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIJ3V-00052W-2K for behave@ietf.org; Fri, 25 Jan 2008 02:32:53 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIJ3T-0006OQ-Lo for behave@ietf.org; Fri, 25 Jan 2008 02:32:53 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0P7XOOu006649; Fri, 25 Jan 2008 01:33:48 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jan 2008 09:32:08 +0200 Received: from esdhcp04076.research.nokia.com ([172.21.40.76]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jan 2008 09:32:08 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] TURN Issue: Codepoints for errors Date: Fri, 25 Jan 2008 09:32:24 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <6066E435-B304-4616-A9B3-353FC42FFCE1@magma.ca> <47980553.4090905@cisco.com> <8B9608DC-F72B-422D-9ECF-6B79A3E449DD@magma.ca> In-Reply-To: <8B9608DC-F72B-422D-9ECF-6B79A3E449DD@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200801250932.24582.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 25 Jan 2008 07:32:08.0197 (UTC) FILETIME=[640B1B50:01C85F24] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Rohan Mahy , ext Philip Matthews 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 25 January 2008 00:16:50 ext Philip Matthews, vous avez =E9crit= =A0: > Philip Matthews wrote: > > TURN-06 proposes three new error codes: > > (tbd) (Channel Number Missing or Invalid): The request requires a > > channel number, but the CHANNEL-NUMBER attribute is missing, or > > the specified channel number is invalid in some way. > > (tbd) (Peer Address Missing or Invalid): The request requires a > > peer > > transport address, but the PEER-ADDRESS attribute is missing, or > > the specified peer transport address is invalid in some way. > > (tbd) (Lifetime Malformed or Invalid): The LIFETIME attribute is > > malformed or the specified lifetime is invalid in some way. > > Is there anyone who feels there should be explicit error codes for > these errors? > If not, the next version of TURN will just use 400 Bad Request for > these errors. I agree it should be all 400. I already made that point a long time ago, I= =20 think. =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 Jan 25 07:57:55 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIO7z-0005SB-Ay; Fri, 25 Jan 2008 07:57:51 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JIO7y-0005Rv-Fi for behave-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 07:57:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIO7q-0005Nl-UT for behave@ietf.org; Fri, 25 Jan 2008 07:57:42 -0500 Received: from server.implementers.org ([69.55.225.91]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JIO7q-0005Ul-Js for behave@ietf.org; Fri, 25 Jan 2008 07:57:42 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id 97542DBCCA2A; Fri, 25 Jan 2008 12:57:26 +0000 (UTC) Received: from [192.168.1.3] (c-71-202-183-123.hsd1.ca.comcast.net [71.202.183.123]) by server.implementers.org (Postfix) with ESMTP id F32B5DBCCA2C; Fri, 25 Jan 2008 12:57:08 +0000 (UTC) Message-ID: <4799DC9A.9090901@acm.org> Date: Fri, 25 Jan 2008 04:56:58 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080109) MIME-Version: 1.0 To: Cullen Jennings Subject: 3/4 of LIFETIME [was Re: [BEHAVE] TURN 06 Comments] References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Behave WG , Philip Matthews 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 Cullen Jennings wrote: > > Gave the document a quick skim. Few comments .... > [snip] > Not a big deal but I don't like the waiting to 3/4 of LIFETIME, If the > lifetime is 7200 this is way too early - I would prefer something more > like LIFETIME minus 5 seconds and some introduction of jitter. > I agree with this. My suggestion was to use LIFETIME minus 7900ms (the duration of a STUN transaction), and to also reject too short LIFETIME values (e.g. with a 423 error code) and to reject a LIFETIME of 0 in the Allocate request instead of considering it a no-op. See comments #4, #7 and #18 in this email: http://www1.ietf.org/mail-archive/web/behave/current/msg02905.html Thanks. -- 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 Sat Jan 26 06:36:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIjKR-0004TC-CC; Sat, 26 Jan 2008 06:36:07 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JIjKP-0004MG-Lw for behave-confirm+ok@megatron.ietf.org; Sat, 26 Jan 2008 06:36:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIjKP-0004IG-1r for behave@ietf.org; Sat, 26 Jan 2008 06:36:05 -0500 Received: from submit01.sysedata.no ([195.159.29.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIjKN-0000nf-Cv for behave@ietf.org; Sat, 26 Jan 2008 06:36:05 -0500 Received: from [84.215.127.238] (helo=[10.0.0.4]) by submit01.sysedata.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.62) (envelope-from ) id 1JIjKB-0001AQ-0C; Sat, 26 Jan 2008 12:35:51 +0100 Message-ID: <479B1B16.1070603@db.org> Date: Sat, 26 Jan 2008 12:35:50 +0100 From: "Alfred E. Heggestad" User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [BEHAVE] TURN Issue #4: Port Adjacency References: <4759CC2B.9050206@cisco.com> <47620F8F.2060606@cisco.com> <4790C87C.4030607@ericsson.com> In-Reply-To: <4790C87C.4030607@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 (-) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 Westerlund wrote: > Jonathan Rosenberg skrev: >> The use case is communicating between an ICE agent and a non-ICE >> traditional Voip client, like a PSTN gateway. Those endpoints >> frequently implement the old original 1889 and do RTP and RTCP on >> adjacent ports. Since ICE recommends TURN as the default candidate, >> when communicating with these peers, we'd be able to get RTCP. WIthout >> this feature, RTCP will not work. >> >> There are still a LOT of endpoints in real deployment that assume >> RTP/RTCP port adjacency. >> > > Yes, port adjacency must work. > I also this that this operation should be 100% atomic. a simpler way of solving this using atomic allocations: - The client sends an AllocateRequest asking for two subsequent ports. - The server returns AllocateResponse with two RELAY-ADDRESS attributes, one for each mapping. This can also be extended to "I want to allocate N subsequent ports". What is missing here is a way for the client to map the two ports. /alfred > Cheers > > Magnus Westerlund (with individual hat) > > > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > > ------------------------------------------------------------------------ > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Jan 26 09:06:55 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIlgJ-0002JY-8S; Sat, 26 Jan 2008 09:06:51 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JIlgI-0002JS-Qr for behave-confirm+ok@megatron.ietf.org; Sat, 26 Jan 2008 09:06:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIlgI-0002JK-3B for behave@ietf.org; Sat, 26 Jan 2008 09:06:50 -0500 Received: from server.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIlgH-000465-Ak for behave@ietf.org; Sat, 26 Jan 2008 09:06:50 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id 41B4AD9D424A; Sat, 26 Jan 2008 14:06:48 +0000 (UTC) Received: from [192.168.1.3] (c-71-202-183-123.hsd1.ca.comcast.net [71.202.183.123]) by server.implementers.org (Postfix) with ESMTP id 6293DD9D4248 for ; Sat, 26 Jan 2008 14:06:46 +0000 (UTC) Message-ID: <479B3E75.8030407@acm.org> Date: Sat, 26 Jan 2008 06:06:45 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080109) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Subject: [BEHAVE] Comments on TURN-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 1. Section 5.2.1.2: "If the request did not contain a REQUESTED-TRANSPORT attribute, the server MUST use the same transport protocol as the request arrived on." As TURN-06 only defines the usage of UDP between the server and the peer, I do not see how to implement this. UDP should be the default if there is no REQUESTED-TRANSPORT attribute. 2. Section 5.2.1.6: "Note that the LIFETIME attribute in an Allocate request can be zero, though this is effectively a no-op, since it will create and destroy the allocation in one transaction." I saw that section 5.2.1.5 now allow the server to reject too short values of LIFETIME, which is good. Let's also reject a LIFETIME value of 0 in the Allocate request. 3. Section 5.2.2: "If its associated Allocate request contained the BANDWIDTH attribute, or this Refresh request contained a new BANDWIDTH attribute, the response MUST also contain the BANDWIDTH attribute." I think that this is inconsistent with what is said in section 5.2.1.7, were a BANDWIDTH attribute is always added to the response. I think that it should be the same for the Refresh response. 4. Section 6.2: "Any other attributes appearing in the message are treated as unexpected." I am not sure what this means, but I hope that this is not meant to override rfc3489bis-13 section 7.3.2, i.e. to consider all other attributes as comprehension-required attributes and to discard the indication if any other attribute appears in the message. I would suggest to remove this sentence completely. 5. Section 17.1, issue #2: "...under the assumption that the IT administrator will only allow clients to contact those servers that implement whatever permission policy the IT administrator can accept?" And how the IT administrator knows that the contacted server implements the correct permission policy, if the server is not in the domain managed by IT and TLS is used between the client and the server? 6. Section 17.1, issue #3: "Port Adjacency" I do not see what the big deal is with this issue. The first Allocate binds multiple ports and returns the first one. If it cannot, then the Allocate fails. Other Allocate requests from different tuples authenticated with the same credentials can explicitly request the additional ports. If the additional ports are never requested, they are deallocated at the same time the first port is deallocated. And this mechanism can be extended in the future by using the remaining bits in REQUESTED-PORTS to some other exotic allocation schemes, like requesting multiple contiguous ports, or multiple ports that are all subsequent prime numbers or whatever. 7. Section 17.1, issue #10: "Allowed PEER-ADDRESS values" The problem is not what is allowed in a PEER-ADDRESS attribute, but what values of PEER-ADDRESS are valid for this specification. I suggest to explicitly say in the spec that the usage of multicast addresses, broadcast addresses and 0.0.0.0 address is not defined in this spec (but can be in extensions) and that a Send indication with this addresses will be dropped and a Bind Channel request will be rejected. 8. Section 17.1, issue #13: "Re-using the 5-tuple" A client should be able to reuse the same tuple immediately, with same or different credentials. 9. Section 17.1, issue #14: "Password change" TURN, especially when used with SIP, is different from other authenticated protocols like HTTP, IMAP, POP in that the allocation can have a very long lifetime (excepted when SIP use the charged-by-minute model of the PSTN). So I think that we should define in the spec what happen when the password change. I think that the right solution would be to reject the next Refresh so the user is prompted for a new password. The remaining allocation lifetime should be displayed to the user so s/he knows that the allocation will expire if s/he does not enter the new password timely. Thanks. -- 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 Sat Jan 26 18:27:48 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIuR7-0007lr-KP; Sat, 26 Jan 2008 18:27:45 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JIuR6-0007le-Eu for behave-confirm+ok@megatron.ietf.org; Sat, 26 Jan 2008 18:27:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIuR5-0007lR-UB for behave@ietf.org; Sat, 26 Jan 2008 18:27:43 -0500 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIuR5-0004Yz-23 for behave@ietf.org; Sat, 26 Jan 2008 18:27:43 -0500 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 7DBF75081A for ; Sat, 26 Jan 2008 15:29:20 -0800 (PST) Date: Sat, 26 Jan 2008 15:29:20 -0800 From: Eric Rescorla To: behave@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080126232920.7DBF75081A@romeo.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Subject: [BEHAVE] Review of draft-ietf-behave-turn-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 $Id: draft-ietf-behave-turn-06-rev.txt,v 1.1 2008/01/26 23:08:30 ekr Exp $ TECHNICAL S 4. The ALTERNATE-SERVER stuff seems problematic for the reasons Cullen indicates. If you're overloaded, better ot simply not handle the request and let ordinary H-A methods take over. S 5.1.1. If the response is an error response and contains a 442, 443 or 444 error code, the client knows that its requested properties could not be met. The client MAY retry with different properties, with the same properties (in a hope that something has changed on the server), or give up, depending on the needs of the application. However, if the client retries, it SHOULD wait 500ms, and if the request fails again, wait 1 second, then 2 seconds, and so on, exponentially backing off. I don't see the purpose of this. This kind of backoff is gnenerally used for congestion control, but if you're getitng errors you know that the packets weren't lost, so why back off? S 5.1.2. This 3/4 guidance seems like it's inappropriate in a number of respects. Why not simply indicate that clients need to leave some time for the refresh. The idea of refreshing with different bandwidth requested seems problematic. What happens if the server refuses? Do you need to refresh again with a lower bandwidth if you're willing to live with that? A policy that refreshes didn't change anything seems more sensible. S 5.2.1. o If the transport protocol is UDP, and the transaction id in the request message matches the transaction id used for the original allocation, then the server treats this as a retransmission of the original request, and replies with the same response as it did to the original request. The server may do this by either storing its original response and resending it, or by rebuilding its original response from other state data. This is a new requirement that's not in STUN (The stun reqt is 10 seconds) and seems impractical to implement. If I throw an error on a transaction, how long do I need to be willing to return the same error? Forever? What seems appropriate here is that as long as an allocation exists (And maybe for X seconds afterward) you need to return the same response. S 5.2.1.1. If it does, the server attempts to allocate a transport address for the client. The Allocate Request can contain several additional attributes that allow the client to request specific characteristics of the transport address. If it doesn't, it sends an error response. What error? S 5.2.1.4. So, I get that you would want an even port for RTP and consecutive ports for RTP/RTCP, but are there any implementations which need arbitrary odd ports? S 6.3. This section contains way too much information about the UDP datagram (Length, Checksum...) It should simply specify that a UDP datagram with the following contents is sent to the following location as per standard procedure. S 7.7. When the server receives a valid ChannelData message, it forms a UDP datagram as follows: the source transport address is the relayed transport address of the allocation, where the allocation is determined by the 5-tuple on which the ChannelData message arrived; the destination transport address is the peer address to which the channel is bound; the data following the UDP header is the contents of the data field of the ChannelData message; the Length field in the UDP header is set to the Length field of the ChannelData message + 8; and the Checksum field in the UDP header is computed as described in Again, too much information about the UDP header.. EDITORIAL Abstract: Is TURN really "more properly" used as part of ICE? S 1. The only way to obtain a UDP transport address that can be used for corresponding with a peer through such a NAT is to make use of a relay. Well, actually, the only reliable way. You mgiht guess correctly. S 2.5. the client can determine the peer that send the UDP datagram. s/send/sends/ S 4. After the initial Allocate transaction, all subsequent TURN transactions need to be sent in the context of a valid allocation. The source and destination IP address and ports for these TURN messages MUST match the those used in the initial Allocate Request. I'm not sure what "in the context means". The seconds sentence seems clearer. S 5.2.1.7. This section would be imroved by having the required attributes being a bulleted list. S 6. Merging send and data indications (which are basically unrelated) into a single section is really confusing. It would be better to give them separate sections. There should be some explicit statement of what missing DATA attributes are for (keepalives). S 7. As described in the overview, channel mechanism provides a way for a client and server to send application data using ChannelData s/channel mechanism/the channel mechanism/ S 7.1. Over UDP, the client SHOULD NOT send ChannelData messages on the channel until it has received a ChannelBind Success Response for the binding attempt. Sending them before the success response is received risks having them dropped by the server if he ChannelBind Request was lost. I think we discussed this onlist. S 11. discovery. As a consequence, TURN runs on a separate port from STUN. The client discovers the address and port of the TURN server using the same DNS procedures defined in [I-D.ietf-behave-rfc3489bis], but using an SRV service name of "turn" (or "turns" for TURN over TLS) Didn't we get rid of separate ports? S 12. TURN cannot be used by clients for subverting firewall policies. This is untrue, as acknowledged in the section on using TLS. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Jan 26 19:08:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIv4M-0005pV-CX; Sat, 26 Jan 2008 19:08:18 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JIv4L-0005pQ-TD for behave-confirm+ok@megatron.ietf.org; Sat, 26 Jan 2008 19:08:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIv4L-0005pI-Gg for behave@ietf.org; Sat, 26 Jan 2008 19:08:17 -0500 Received: from wa-out-1112.google.com ([209.85.146.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JIv4J-0008RI-3A for behave@ietf.org; Sat, 26 Jan 2008 19:08:17 -0500 Received: by wa-out-1112.google.com with SMTP id k40so2848710wah.25 for ; Sat, 26 Jan 2008 16:08:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=lBTU8YXSemAx4/UnLZ/VjHaWjMhvdfJh0T0v1AswLvs=; b=SrSlkh1KZo0lONKGsCi53i/LzIxMXrOIUsSM1oa+BC29u58l9oaIxlJ58xREyUBwiD2NgYCRv30hs1A/BOLJcltD1o3CDFhUqCCDw3wwVZFaqrnEeZOONKFskBopY36Nudo8cREExYMao3Gm0gHC72vFhJSe5KWiG1nusPTK81Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=uiKeWen/jXRStoXKO0ncvHGh4F0m6DutLtiGEjbzm1h8fWOchOwAUG2U8NfErrc0qKFbOJJafohZq7j7igUitwMgmL1yQblxxaV0oE+LB8yqJTmGQUerlcGAdXcxFHS7DP0NYfsbySFZd900X0FbIv1uPbtQETwkc/f3kgMcjN8= Received: by 10.142.128.6 with SMTP id a6mr1853386wfd.206.1201392494380; Sat, 26 Jan 2008 16:08:14 -0800 (PST) Received: by 10.142.214.15 with HTTP; Sat, 26 Jan 2008 16:08:14 -0800 (PST) Message-ID: <953beacc0801261608s2f8480b1i36a384adbb11baf@mail.gmail.com> Date: Sat, 26 Jan 2008 16:08:14 -0800 From: "Rohan Mahy" To: "Philip Matthews" Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages In-Reply-To: MIME-Version: 1.0 References: <4759D19B.50005@cisco.com> <30C5AFE6-C9FC-40FE-8A74-80B568FBD554@magma.ca> <1C97A587-D403-48D0-B086-584F7975FC31@cisco.com> <3E8D0268-A6CF-460B-827C-7358367FC961@magma.ca> <47685AF4.9030909@cisco.com> <1C6AF3B7-BB61-45B1-A2CA-C02EAFFB5B66@magma.ca> <4790C67D.8030607@ericsson.com> <951756A8-E7C3-48C8-9C8A-2D359AB7700D@magma.ca> <4790D2AF.3060802@ericsson.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 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="===============1640561022==" Errors-To: behave-bounces@ietf.org --===============1640561022== Content-Type: multipart/alternative; boundary="----=_Part_5587_999241.1201392494373" ------=_Part_5587_999241.1201392494373 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I have watched this discussion for the last several weeks, fully expecting for sanity to reassert itself at some point in the discussion. I think it is wholly inappropriate to revisit this framing issue again. We had a very strong consensus at a previous meeting and on the mailing list that we were going to apply framing to every message. In fact we agreed that the framing length on UDP would be the actual length. This framing was added and we agreed at the adhoc and shortly thereafter on the list to use EKR's proposed ChannelBinding approach to associate non-zero channel numbers with a peer WITH the framing on every message. Then, on a phone call (on Dec 20th), the folks on the call decided to reopen a design decision that had no associated open issue and no technical problem associated with it. The supposed benefits of running without framing are not new and were mentioned explicitly the last time we went over this issue and we decided that they were pretty weak. 1) Running STUN and TURN on the same port: nobody cared, 3) Might make people more aware that TURN is an extension of STUN: this is philisophical wanking of the highest degree--WHO CARES!, 2) Ditching framing saves 4-bytes: This was the crux of the discussion and we decided the simplicity and determinism of using consistent framing was far more important than 4 octets when using UDP (recall that we always need this framing over TCP). Applying framing to every message consistently makes the protocol and its implementations simpler. When I rewrote TURN to use consistent framing, I was amazed at how much simpler the protocol was to explain in the spec and after speaking to several implementors, the feedback I received was very consistent. Consistent framing was easier to implement, resulted in fewer corner cases and resulted in code that was easier to understand and maintain. While I don't care how many bits we use to represent a channel number, I strongly suggest we go back to framing every TURN message. thanks, -rohan On Dec 7, 2007 3:04 PM, Jonathan Rosenberg wrote: > This issue was not in my slides. It was brought up at the mike in the > WG, and was discussed there. It was not discussed further at the ad-hoc. > > As of turn-05, we introduced a framing mechanism, which is a 4 byte > header consisting of 2 bytes channel and 2-bytes length. This framing > header precedes ALL packets sent between a client and its TURN server, > including both application data and TURN messages themselves, which are > sent on channel zero. > > Ekr raised a question of why this header was needed for actual TURN > messages. After all, he argued, we went through all this trouble to make > STUN (and thus TURN) differentiatable from each other. Indeed, others > noted that the framing header itself looks very similar to the top 4 > bytes of the STUN message format anyway: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0| STUN Message Type | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Magic Cookie | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Transaction ID (96 bits) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > and the proposed framing header: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Channel | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > So an alternative design is to make the framing header look like: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| Channel | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > So that there are 15 bits of channel instead of 16. Placing a 1 in that > position makes the framing header always a non-match for STUN messages. > Thus, it would not be even needed to do the more complex matching > operations defined in STUN; a 1-bit check would do the job to separate > out application data from STUN/TURN. > > The benefits of this change would be: > > 1. We would, once again, be able to run STUN and TURN on the same > port on the server. As of turn-05 they MUST run on different ports > because the framing header was unique to TURN. This could be a feature > or a bug depending on your perspective: > > FEATURE: TURN and STUN are actually very different; using > separate ports would allow a firewall to block one and not the other. > > BUG: practically speaking separate ports doesnt help since > with DNS the ports can be dynamic anyway. In addition, its always good > to use fewer ports on a server. Also its weird that an extension to a > protocol would run on a different port; that kind of tells you its not > an extension. > > 2. Reduces the size of TURN messages by 4 bytes. This is a minor > benefit and the real one is having a single port. > > 3. it'd be a little clearer to explain to people that TURN is an > extension to STUN, rather than saying, TURN is a STUN extension that is > run over a new framing header > > The drawbacks of this change would be: > > 1. cuts the number of channels in half > > > An alternative design would be to use the full 16 bits for channel > numbers, and then rely on the full suite of STUN differentiation > techniques to demux. However, my preference in general is to not do that > when its not actually needed. It complicates message processing and I > don't think its worth it. 32767 channels is also a LOT for our > envisioned use cases. > > This was somewhat inconclusive at the microphone. I'm personally on the > fence and don't feel that strongly. I probably midly prefer making this > change. > > Please comment on whether you prefer this change or not. On Jan 18, 2008 9:42 AM, Philip Matthews wrote: > Let me summarize what I believe is the current state of this issue. > > We have agreed that TURN control messages will _not_ use the framing > header. Separately, we have also agreed to use EKRs mechanism to > allocate channels. The combination of these two means that the > "framing header" is only used for application data traveling on a > channel. What this really means is that we have a new non-STUN- > formatted message that carries application data. I am proposing to > call this message a "ChannelData" message. > > So the point we are discussing now is how to distinguish a > ChannelData message from a STUN-formatted message. Here the original > proposal was to use the first bit of the message to distinguish the > two: a STUN-formatted message has the first bit set to 0, and the > ChannelData message has the first bit set to 1. > > My proposal is to instead use the first two bits. My reasoning is > that the first two bits of a STUN message are always '00' and all > other combinations can be used for the ChannelData message. To be > precise, here is the text that I am proposing: > > The ChannelData message is used to carry application data between > the > client and the server. It has the following format: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Channel Number | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > / Application Data / > / / > | | > | +-------------------------------+ > | | > +-------------------------------+ > > The Channel Number field specifies the number of the channel on > which > the data is traveling, and thus the address of the peer that is > sending or is to receive the data. The channel number MUST be in > the > range 0x4000 - 0xFFFF, with channel number 0xFFFF being reserved for > possible future extensions. > > Channel numbers 0x0000 - 0x3FFF cannot be used because bits 0 and 1 > are used to distinguish ChannelData messages from STUN-formatted > messages (i.e., Allocate, Send, Data, ChannelBind, etc). STUN- > formatted messages always have bits 0 and 1 as "00", while > ChannelData messages use combinations "01", "10", and "11". > > In discussing how to distinguish ChannelData messages from STUN- > formatted messages, the following issues have been raised: > * (Derek) It is easier to look at just one bit, rather than two bits. > * (Cullen) How many channels do we need anyway? Why do we need more > than 200 channels? > > In addition, there is the question of whether we need a way to de- > allocate channels. During the conf call of 20 Dec, there was > agreement amongst the participants that such a mechanism was > required, but so far no mechanism has been proposed yet. > > Right now, my intention is to put the above text into TURN-06 and > then flag three open issues: > 1) What is the exact format of the ChannelData message? > 2) How many channels do we need? > 3) Do we need a mechanism to release channels, and if so, what does > it look like? > > My personal opinion on #3 is now leaning to "YES", but I haven't had > a chance to propose a mechanism yet. > > Comments? > > - Philip > > > > > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > ------=_Part_5587_999241.1201392494373 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I have watched this discussion for the last several weeks, fully expecting for sanity to reassert itself at some point in the discussion.

I think it is wholly inappropriate to revisit this framing issue again.  We had a very strong consensus at a previous meeting and on the mailing list that we were going to apply framing to every message. In fact we agreed that the framing length on UDP would be the actual length. This framing was added and we agreed at the adhoc and shortly thereafter on the list to use EKR's proposed ChannelBinding approach to associate non-zero channel numbers with a peer WITH the framing on every message.  Then, on a phone call (on Dec 20th), the folks on the call decided to reopen a design decision that had no associated open issue and no technical problem associated with it.  

The supposed benefits of running without framing are not new and were mentioned explicitly the last time we went over this issue and we decided that they were pretty weak.  1) Running STUN and TURN on the same port: nobody cared, 3) Might make people more aware that TURN is an extension of STUN: this is philisophical wanking of the highest degree--WHO CARES!, 2) Ditching framing saves 4-bytes: This was the crux of the discussion and we decided the simplicity and determinism of using consistent framing was far more important than 4 octets when using UDP (recall that we always need this framing over TCP).

Applying framing to every message consistently makes the protocol and its implementations simpler. When I rewrote TURN to use consistent framing, I was amazed at how much simpler the protocol was to explain in the spec and after speaking to several implementors, the feedback I received was very consistent. Consistent framing was easier to implement, resulted in fewer corner cases and resulted in code that was easier to understand and maintain.  

While I don't care how many bits we use to represent a channel number, I strongly suggest we go back to framing every TURN message.

thanks,
-rohan


On Dec 7, 2007 3:04 PM, Jonathan Rosenberg <jdrosen@cisco.com> wrote:
This issue was not in my slides. It was brought up at the mike in the
WG, and was discussed there. It was not discussed further at the ad-hoc.

As of turn-05, we introduced a framing mechanism, which is a 4 byte
header consisting of 2 bytes channel and 2-bytes length. This framing
header precedes ALL packets sent between a client and its TURN server,
including both application data and TURN messages themselves, which are
sent on channel zero.

Ekr raised a question of why this header was needed for actual TURN
messages. After all, he argued, we went through all this trouble to make
STUN (and thus TURN) differentiatable from each other. Indeed, others
noted that the framing header itself looks very similar to the top 4
bytes of the STUN message format anyway:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0 0|     STUN Message Type     |         Message Length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Magic Cookie                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                     Transaction ID (96 bits)                  |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


and the proposed framing header:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Channel                |         Message Length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

So an alternative design is to make the framing header look like:


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |1|      Channel                |         Message Length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

So that there are 15 bits of channel instead of 16. Placing a 1 in that
position makes the framing header always a non-match for STUN messages.
Thus, it would not be even needed to do the more complex matching
operations defined in STUN; a 1-bit check would do the job to separate
out application data from STUN/TURN.

The benefits of this change would be:

  1. We would, once again, be able to run STUN and TURN on the same
port on the server. As of turn-05 they MUST run on different ports
because the framing header was unique to TURN. This could be a feature
or a bug depending on your perspective:

         FEATURE: TURN and STUN are actually very different; using
separate ports would allow a firewall to block one and not the other.

         BUG: practically speaking separate ports doesnt help since
with DNS the ports can be dynamic anyway. In addition, its always good
to use fewer ports on a server. Also its weird that an extension to a
protocol would run on a different port; that kind of tells you its not
an extension.

  2. Reduces the size of TURN messages by 4 bytes. This is a minor
benefit and the real one is having a single port.

  3. it'd be a little clearer to explain to people that TURN is an
extension to STUN, rather than saying, TURN is a STUN extension that is
run over a new framing header

The drawbacks of this change would be:

  1. cuts the number of channels in half


An alternative design would be to use the full 16 bits for channel
numbers, and then rely on the full suite of STUN differentiation
techniques to demux. However, my preference in general is to not do that
when its not actually needed. It complicates message processing and I
don't think its worth it. 32767 channels is also a LOT for our
envisioned use cases.

This was somewhat inconclusive at the microphone. I'm personally on the
fence and don't feel that strongly. I probably midly prefer making this
change.

Please comment on whether you prefer this change or not.

On Jan 18, 2008 9:42 AM, Philip Matthews <philip_matthews@magma.ca> wrote:
Let me summarize what I believe is the current state of this issue.

We have agreed that TURN control messages will _not_ use the framing
header. Separately, we have also agreed to use EKRs mechanism to
allocate channels. The combination of these two means that the
"framing header" is only used for application data traveling on a
channel. What this really means is that we have a new non-STUN-
formatted message that carries application data. I am proposing to
call this message a "ChannelData" message.

So the point we are discussing now is how to distinguish a
ChannelData message from a STUN-formatted message. Here the original
proposal was to use the first bit of the message to distinguish the
two: a STUN-formatted message has the first bit set to 0, and the
ChannelData message has the first bit set to 1.

My proposal is to instead use the first two bits. My reasoning is
that the first two bits of a STUN message are always '00' and all
other combinations can be used for the ChannelData message. To be
precise, here is the text that I am proposing:

   The ChannelData message is used to carry application data between
the
   client and the server.  It has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Channel Number        |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /                       Application Data                        /
   /                                                               /
   |                                                               |
   |                               +-------------------------------+
   |                               |
   +-------------------------------+

   The Channel Number field specifies the number of the channel on
which
   the data is traveling, and thus the address of the peer that is
   sending or is to receive the data.  The channel number MUST be in
the
   range 0x4000 - 0xFFFF, with channel number 0xFFFF being reserved for
   possible future extensions.

   Channel numbers 0x0000 - 0x3FFF cannot be used because bits 0 and 1
   are used to distinguish ChannelData messages from STUN-formatted
   messages (i.e., Allocate, Send, Data, ChannelBind, etc).  STUN-
   formatted messages always have bits 0 and 1 as "00", while
   ChannelData messages use combinations "01", "10", and "11".

In discussing how to distinguish ChannelData messages from STUN-
formatted messages, the following issues have been raised:
* (Derek) It is easier to look at just one bit, rather than two bits.
* (Cullen) How many channels do we need anyway? Why do we need more
than 200 channels?

In addition, there is the question of whether we need a way to de-
allocate channels. During the conf call of 20 Dec, there was
agreement amongst the participants that such a mechanism was
required, but so far no mechanism has been proposed yet.

Right now, my intention is to put the above text into TURN-06 and
then flag three open issues:
1) What is the exact format of the ChannelData message?
2) How many channels do we need?
3) Do we need a mechanism to release channels, and if so, what does
it look like?

My personal opinion on #3 is now leaning to "YES", but I haven't had
a chance to propose a mechanism yet.

Comments?

- Philip








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

------=_Part_5587_999241.1201392494373-- --===============1640561022== 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 --===============1640561022==-- From behave-bounces@ietf.org Sat Jan 26 22:41:23 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIyOX-0005rF-RY; Sat, 26 Jan 2008 22:41:21 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JIyOW-0005r8-ER for behave-confirm+ok@megatron.ietf.org; Sat, 26 Jan 2008 22:41:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIyOW-0005r0-4O for behave@ietf.org; Sat, 26 Jan 2008 22:41:20 -0500 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIyOU-0001pd-Ks for behave@ietf.org; Sat, 26 Jan 2008 22:41:20 -0500 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 2F6295081A; Sat, 26 Jan 2008 19:42:56 -0800 (PST) Date: Sat, 26 Jan 2008 19:42:55 -0800 From: Eric Rescorla To: "Rohan Mahy" Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages In-Reply-To: <953beacc0801261608s2f8480b1i36a384adbb11baf@mail.gmail.com> References: <4759D19B.50005@cisco.com> <30C5AFE6-C9FC-40FE-8A74-80B568FBD554@magma.ca> <1C97A587-D403-48D0-B086-584F7975FC31@cisco.com> <3E8D0268-A6CF-460B-827C-7358367FC961@magma.ca> <47685AF4.9030909@cisco.com> <1C6AF3B7-BB61-45B1-A2CA-C02EAFFB5B66@magma.ca> <4790C67D.8030607@ericsson.com> <951756A8-E7C3-48C8-9C8A-2D359AB7700D@magma.ca> <4790D2AF.3060802@ericsson.com> <953beacc0801261608s2f8480b1i36a384adbb11baf@mail.gmail.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: <20080127034256.2F6295081A@romeo.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Behave WG , Philip Matthews 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 Sat, 26 Jan 2008 16:08:14 -0800, Rohan Mahy wrote: > I think it is wholly inappropriate to revisit this framing issue again. We > had a very strong consensus at a previous meeting and on the mailing list > that we were going to apply framing to every message. Hmm.. I definitely remember some discussion of framing everything (Prague, right?) but I don't remember the implication being that STUN would framed, but rather that all other protocols would need to be framed. > In fact we agreed that > the framing length on UDP would be the actual length. This framing was added > and we agreed at the adhoc and shortly thereafter on the list to use EKR's > proposed ChannelBinding approach to associate non-zero channel numbers with > a peer WITH the framing on every message. I definitely don't remember that from the ad hoc. > Then, on a phone call (on Dec > 20th), the folks on the call decided to reopen a design decision that had no > associated open issue and no technical problem associated with it. Hmm TURN-04 had framing (though it was different) for stream transports but as I read the spec, STUN over UDP was un-framed. I'm not sure I would characterize discussing a design decision that first appeared in TURN-05 (in YVR) as "reopening it". This is a new design. I don't think it's the best one. > The supposed benefits of running without framing are not new and were > mentioned explicitly the last time we went over this issue and we decided > that they were pretty weak. 1) Running STUN and TURN on the same port: > nobody cared, I care. > 3) Might make people more aware that TURN is an extension of > STUN: this is philisophical wanking of the highest degree--WHO CARES!, 2) > Ditching framing saves 4-bytes: This was the crux of the discussion and we > decided the simplicity and determinism of using consistent framing was far > more important than 4 octets when using UDP (recall that we always need this > framing over TCP). Well, the 4 bytes wasn't *my* reason. Rather, I think that having a lot of different ways to demux STUN from other things is architecturally inelegant. And since as Cullen observed, it's possible to disambiguate them from the initial bytes, I don't see the value of having yet another piece of demuxing. Moreover, it makes writing a combined STUN/TURN stack modestly easier, IMO. > Applying framing to every message consistently makes the protocol and its > implementations simpler. Well, I guess this is a matter of opinion: I'm an implementor and I don't think that it makes that it makes the implementation simpler. On the contrary, I think it makes it more complicated. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Jan 27 10:02:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJ91h-0002Qb-MA; Sun, 27 Jan 2008 10:02:29 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JJ91g-0002QW-OH for behave-confirm+ok@megatron.ietf.org; Sun, 27 Jan 2008 10:02:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJ91g-0002QO-Cv for behave@ietf.org; Sun, 27 Jan 2008 10:02:28 -0500 Received: from server.implementers.org ([69.55.225.91]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJ91f-0002r2-OQ for behave@ietf.org; Sun, 27 Jan 2008 10:02:28 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id BD666D9D424A; Sun, 27 Jan 2008 15:02:26 +0000 (UTC) Received: from [192.168.1.3] (c-71-202-183-123.hsd1.ca.comcast.net [71.202.183.123]) by server.implementers.org (Postfix) with ESMTP id 392DBD9D4248; Sun, 27 Jan 2008 15:02:24 +0000 (UTC) Message-ID: <479C9CFF.4030900@acm.org> Date: Sun, 27 Jan 2008 07:02:23 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080109) MIME-Version: 1.0 To: Eric Rescorla Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages References: <4759D19B.50005@cisco.com> <30C5AFE6-C9FC-40FE-8A74-80B568FBD554@magma.ca> <1C97A587-D403-48D0-B086-584F7975FC31@cisco.com> <3E8D0268-A6CF-460B-827C-7358367FC961@magma.ca> <47685AF4.9030909@cisco.com> <1C6AF3B7-BB61-45B1-A2CA-C02EAFFB5B66@magma.ca> <4790C67D.8030607@ericsson.com> <951756A8-E7C3-48C8-9C8A-2D359AB7700D@magma.ca> <4790D2AF.3060802@ericsson.com> <953beacc0801261608s2f8480b1i36a384adbb11baf@mail.gmail.com> <20080127034256.2F6295081A@romeo.rtfm.com> In-Reply-To: <20080127034256.2F6295081A@romeo.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Behave WG , Philip Matthews 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 Eric Rescorla wrote: > At Sat, 26 Jan 2008 16:08:14 -0800, > Rohan Mahy wrote: >> I think it is wholly inappropriate to revisit this framing issue again. We >> had a very strong consensus at a previous meeting and on the mailing list >> that we were going to apply framing to every message. > > Hmm.. I definitely remember some discussion of framing everything > (Prague, right?) but I don't remember the implication being that STUN > would framed, but rather that all other protocols would > need to be framed. > > >> In fact we agreed that >> the framing length on UDP would be the actual length. This framing was added >> and we agreed at the adhoc and shortly thereafter on the list to use EKR's >> proposed ChannelBinding approach to associate non-zero channel numbers with >> a peer WITH the framing on every message. > > I definitely don't remember that from the ad hoc. > > >> Then, on a phone call (on Dec >> 20th), the folks on the call decided to reopen a design decision that had no >> associated open issue and no technical problem associated with it. > > Hmm TURN-04 had framing (though it was different) for stream > transports but as I read the spec, STUN over UDP was un-framed. I'm > not sure I would characterize discussing a design decision that first > appeared in TURN-05 (in YVR) as "reopening it". This is a new design. > I don't think it's the best one. > > >> The supposed benefits of running without framing are not new and were >> mentioned explicitly the last time we went over this issue and we decided >> that they were pretty weak. 1) Running STUN and TURN on the same port: >> nobody cared, > > I care. > > >> 3) Might make people more aware that TURN is an extension of >> STUN: this is philisophical wanking of the highest degree--WHO CARES!, 2) >> Ditching framing saves 4-bytes: This was the crux of the discussion and we >> decided the simplicity and determinism of using consistent framing was far >> more important than 4 octets when using UDP (recall that we always need this >> framing over TCP). > > Well, the 4 bytes wasn't *my* reason. Rather, I think that having a lot > of different ways to demux STUN from other things is architecturally > inelegant. And since as Cullen observed, it's possible to disambiguate > them from the initial bytes, I don't see the value of having yet > another piece of demuxing. Moreover, it makes writing a combined > STUN/TURN stack modestly easier, IMO. > > >> Applying framing to every message consistently makes the protocol and its >> implementations simpler. > > Well, I guess this is a matter of opinion: I'm an implementor and I don't > think that it makes that it makes the implementation simpler. On the > contrary, I think it makes it more complicated. > I now implemented both versions of the framing on a TURN client, TURN server and on a Wireshark dissector (Alice, Bob and Eve :-). The implementation difference between the two framings is minimal in the client and the server side. For the Wireshark dissector with the TURN-05 framing, TURN is decoded as a separate protocol and so need a separate dissector. With the TURN-06 framing, TURN is decoded as STUN protocol and so use the same dissector. This is the only real difference in my opinion: With TURN-05 the protocol can be explicitly decoded as TURN, with TURN-06 it is decoded as STUN and you have to look closer to find that the TURN extension is used. This said, I still have a small preference for the TURN-06 framing. -- 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 Mon Jan 28 01:22:09 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJNNe-00008p-Ln; Mon, 28 Jan 2008 01:22:06 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JJNNd-00007n-7Z for behave-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 01:22:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJNNc-00007e-Ql for behave@ietf.org; Mon, 28 Jan 2008 01:22:04 -0500 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJNNc-0007Dt-1G for behave@ietf.org; Mon, 28 Jan 2008 01:22:04 -0500 Received: by py-out-1112.google.com with SMTP id x19so1810704pyg.24 for ; Sun, 27 Jan 2008 22:22:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=jZDjgh6gh/ArFy6HcFKjPZcu8FT5pYNUcjCplNgTpPE=; b=Acg9fbK69R71aJa000drAwlCTZHv7J++qou+o1XnFZzs0UPjVKS9qwLzoIhXeT6NwnxdstjzGK8z9KEC9BlgS4pougmQ3UyPzCfgRdvyOCY4wIzPQltVChy1llNUoGSwoOOuIpkzeRAaqSmuVayF+a8wxLcnZcJGt6owxkluzqY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=RAaUjWol05ewM8fm6EAdNqyme8+yrXL1yLC5dFhYu7gFur/aYHAEGY3sRGGrnhAXJCKpboJ5/9QDrq8NU3Zea55amL72MVZorsDR+jgcnIHvU+T7o0czH57lJ7ke6ynhCd+Jb6zE3pnR/aWPgyUmBrWzo3PjtayZ4rlW+oD/Wjo= Received: by 10.142.203.13 with SMTP id a13mr2069220wfg.148.1201501323112; Sun, 27 Jan 2008 22:22:03 -0800 (PST) Received: by 10.142.214.15 with HTTP; Sun, 27 Jan 2008 22:22:03 -0800 (PST) Message-ID: <953beacc0801272222s5fefafa0l2cd4aaa3b1c95a52@mail.gmail.com> Date: Sun, 27 Jan 2008 22:22:03 -0800 From: "Rohan Mahy" To: "Eric Rescorla" Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages In-Reply-To: <20080127034256.2F6295081A@romeo.rtfm.com> MIME-Version: 1.0 References: <4759D19B.50005@cisco.com> <3E8D0268-A6CF-460B-827C-7358367FC961@magma.ca> <47685AF4.9030909@cisco.com> <1C6AF3B7-BB61-45B1-A2CA-C02EAFFB5B66@magma.ca> <4790C67D.8030607@ericsson.com> <951756A8-E7C3-48C8-9C8A-2D359AB7700D@magma.ca> <4790D2AF.3060802@ericsson.com> <953beacc0801261608s2f8480b1i36a384adbb11baf@mail.gmail.com> <20080127034256.2F6295081A@romeo.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: Behave WG , Philip Matthews 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="===============0749017725==" Errors-To: behave-bounces@ietf.org --===============0749017725== Content-Type: multipart/alternative; boundary="----=_Part_8283_11153970.1201501323085" ------=_Part_8283_11153970.1201501323085 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Eric, Two clarifying questions: Have you implemented both framing styles (pre-05 and 05)? Can you please explain why you care about running some STUN usage and the TURN protocol on the same port? Do you have a practical use case that is enabled that is important to you? thanks, -rohan On Jan 26, 2008 7:42 PM, Eric Rescorla wrote: > At Sat, 26 Jan 2008 16:08:14 -0800, > Rohan Mahy wrote: > > I think it is wholly inappropriate to revisit this framing issue again. > We > > had a very strong consensus at a previous meeting and on the mailing > list > > that we were going to apply framing to every message. > > Hmm.. I definitely remember some discussion of framing everything > (Prague, right?) but I don't remember the implication being that STUN > would framed, but rather that all other protocols would > need to be framed. > > > > In fact we agreed that > > the framing length on UDP would be the actual length. This framing was > added > > and we agreed at the adhoc and shortly thereafter on the list to use > EKR's > > proposed ChannelBinding approach to associate non-zero channel numbers > with > > a peer WITH the framing on every message. > > I definitely don't remember that from the ad hoc. > > > > Then, on a phone call (on Dec > > 20th), the folks on the call decided to reopen a design decision that > had no > > associated open issue and no technical problem associated with it. > > Hmm TURN-04 had framing (though it was different) for stream > transports but as I read the spec, STUN over UDP was un-framed. I'm > not sure I would characterize discussing a design decision that first > appeared in TURN-05 (in YVR) as "reopening it". This is a new design. > I don't think it's the best one. > > > > The supposed benefits of running without framing are not new and were > > mentioned explicitly the last time we went over this issue and we > decided > > that they were pretty weak. 1) Running STUN and TURN on the same port: > > nobody cared, > > I care. > > > > 3) Might make people more aware that TURN is an extension of > > STUN: this is philisophical wanking of the highest degree--WHO CARES!, > 2) > > Ditching framing saves 4-bytes: This was the crux of the discussion and > we > > decided the simplicity and determinism of using consistent framing was > far > > more important than 4 octets when using UDP (recall that we always need > this > > framing over TCP). > > Well, the 4 bytes wasn't *my* reason. Rather, I think that having a lot > of different ways to demux STUN from other things is architecturally > inelegant. And since as Cullen observed, it's possible to disambiguate > them from the initial bytes, I don't see the value of having yet > another piece of demuxing. Moreover, it makes writing a combined > STUN/TURN stack modestly easier, IMO. > > > > Applying framing to every message consistently makes the protocol and > its > > implementations simpler. > > Well, I guess this is a matter of opinion: I'm an implementor and I don't > think that it makes that it makes the implementation simpler. On the > contrary, I think it makes it more complicated. > > -Ekr > ------=_Part_8283_11153970.1201501323085 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Eric,

Two clarifying questions:

Have you implemented both framing styles (pre-05 and 05)?

Can you please explain why you care about running some STUN usage and the TURN protocol on the same port?  Do you have a practical use case that is enabled that is important to you?

thanks,
-rohan

On Jan 26, 2008 7:42 PM, Eric Rescorla <ekr@networkresonance.com> wrote:
At Sat, 26 Jan 2008 16:08:14 -0800,
Rohan Mahy wrote:
> I think it is wholly inappropriate to revisit this framing issue again.  We
> had a very strong consensus at a previous meeting and on the mailing list
> that we were going to apply framing to every message.

Hmm.. I definitely remember some discussion of framing everything
(Prague, right?) but I don't remember the implication being that STUN
would framed, but rather that all other protocols would
need to be framed.


> In fact we agreed that
> the framing length on UDP would be the actual length. This framing was added
> and we agreed at the adhoc and shortly thereafter on the list to use EKR's
> proposed ChannelBinding approach to associate non-zero channel numbers with
> a peer WITH the framing on every message.

I definitely don't remember that from the ad hoc.


> Then, on a phone call (on Dec
> 20th), the folks on the call decided to reopen a design decision that had no
> associated open issue and no technical problem associated with it.

Hmm TURN-04 had framing (though it was different) for stream
transports but as I read the spec, STUN over UDP was un-framed.  I'm
not sure I would characterize discussing a design decision that first
appeared in TURN-05 (in YVR) as "reopening it". This is a new design.
I don't think it's the best one.


> The supposed benefits of running without framing are not new and were
> mentioned explicitly the last time we went over this issue and we decided
> that they were pretty weak.  1) Running STUN and TURN on the same port:
> nobody cared,

I care.


> 3) Might make people more aware that TURN is an extension of
> STUN: this is philisophical wanking of the highest degree--WHO CARES!, 2)
> Ditching framing saves 4-bytes: This was the crux of the discussion and we
> decided the simplicity and determinism of using consistent framing was far
> more important than 4 octets when using UDP (recall that we always need this
> framing over TCP).

Well, the 4 bytes wasn't *my* reason. Rather, I think that having a lot
of different ways to demux STUN from other things is architecturally
inelegant. And since as Cullen observed, it's possible to disambiguate
them from the initial bytes, I don't see the value of having yet
another piece of demuxing. Moreover, it makes writing a combined
STUN/TURN stack modestly easier, IMO.


> Applying framing to every message consistently makes the protocol and its
> implementations simpler.

Well, I guess this is a matter of opinion: I'm an implementor and I don't
think that it makes that it makes the implementation simpler. On the
contrary, I think it makes it more complicated.

-Ekr

------=_Part_8283_11153970.1201501323085-- --===============0749017725== 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 --===============0749017725==-- From behave-bounces@ietf.org Mon Jan 28 01:54:36 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJNt3-0001VB-86; Mon, 28 Jan 2008 01:54:33 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JJNt2-0001Ue-1M for behave-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 01:54:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJNt1-0001UG-6G for behave@ietf.org; Mon, 28 Jan 2008 01:54:31 -0500 Received: from py-out-1112.google.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJNsz-0007nv-Gu for behave@ietf.org; Mon, 28 Jan 2008 01:54:31 -0500 Received: by py-out-1112.google.com with SMTP id x19so1821736pyg.24 for ; Sun, 27 Jan 2008 22:54:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=4fdcJZKy0UW447/Y5Zwqkoa77r+73AmB9KRAhDUDjNo=; b=hZobeutaQ//xKTklS/1jn2zSj3BZ2Pn2oIcbjwg8qk63xlasJd1PQFUG4gtT7K0Fq7I6R1OMDFcajXrhyiu4EPFSj+UF2bMz2JZqC50NKGx5T/byMgtrDZTQoTjpkKPO1lvtm9Ql5omZFE+W5ZQoOAMJv/5agmZGVSSUStAxOMg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=avTUgkT44aqBHEFbvSQ9uJLUuDHsgJvtST4Dy2Rq9pmg+jP2sqskTRB21rUzLMNxOL3KJDQ8BuSXSEa9Lc91oc+ZYH7bpU1TOR21mkhTGUeZjbAO9Z4Fqg263+UR/fAIkf4jUnyM4bd4Zaykw+BS3cA7mwMxWCeznGhFDJHUfjE= Received: by 10.142.52.9 with SMTP id z9mr2071694wfz.201.1201503267947; Sun, 27 Jan 2008 22:54:27 -0800 (PST) Received: by 10.142.214.15 with HTTP; Sun, 27 Jan 2008 22:54:27 -0800 (PST) Message-ID: <953beacc0801272254x364b0995y369319720333b3ab@mail.gmail.com> Date: Sun, 27 Jan 2008 22:54:27 -0800 From: "Rohan Mahy" To: "Behave WG" MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Subject: [BEHAVE] (mostly non) open issues 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="===============1338408556==" Errors-To: behave-bounces@ietf.org --===============1338408556== Content-Type: multipart/alternative; boundary="----=_Part_8360_21334118.1201503267926" ------=_Part_8360_21334118.1201503267926 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I think most of the so-called open issues in TURN-06 are not really open issues. My recollection follows for the ones I think are not open, and my opinion for items #4 and #8 which I consider the only real open issue on the list: 17.1. Open Issues 1. Bandwidth: What should we do with the BANDWIDTH attribute, which is currently ill-specified? Should we remove it? Or should we try to come up with a good specification, perhaps using ideas from RSVP? I recall that we agreed that it is a hint. 2. Permission Policy: What should the permission policy be? Address-restricted, as is currently specified in the document? Or address-and-port-restricted, as many firewalls implement today? Or should we leave this open to the implementor, under the assumption that the IT administrator will only allow clients to contact those servers that implement whatever permission policy the IT administrator can accept? We definitely agreed that the permission policy is address-restricted. 3. Port Adjacency: The spec currently allows a client to request that the server allocate a port and also reserve the next higher port number for a possible future allocation (on a different 5-tuple). However, the exact behavior of the server in this case is ill-specified. For example, must the next-higher-port be available for the allocation of the lower port number to succeed? How long is the next-higher-port reserved? 30 seconds? For the lifetime of the lower-numbered-port's allocation? Or should we just ditch this feature, since it is difficult to implement, it is at odds with port randomization, and paired port numbers applications don't work well with NATs anyway? We agreed to keep this at the adhoc. The server is asked to come up with ANY even port with the next higher port available. The client was never allowed to ask for a pair of ports with a specific port number (the syntax actually prevents this). IMO, the server is reserving the next port as a courtesy, so the amount of time the server wants to wait is up to the server. 4. Demuxing ChannelData messages: How does a client or server demux STUN-formatted messages from ChannelData messages? Does it use the first two bits (as currently specified) or just one bit? And how many channels do we need anyway? Some people are questioning the need for any more than 200 channels. If we don't need many channels, then the demux algorithm might become simpler. OPEN ISSUE: Unfortunately I have to agree that this is an open issue, but only because we are not using the 4-octet framing for every message as we had consensus to do in TURN -05. My opinion is that we should go back to TURN framing for all TURN messages. 5. Deallocating Channels: Do we need a mechanism for deallocating channels? Some have argued for this feature, because a TURN server administrator will want a way to recover resources for channels no longer in active use. If yes, then what is the mechanism? For example, should a channel binding expire when the corresponding permission expires? I recall that we came to consensus that this was not necessary. If the client is really concerned, it can open a new allocation and transition its active peers to the new address. 6. Permissions and Channel Allocations: Should allocating a channel for a peer automatically install a permission for that peer's IP address? We agreed long ago, and repeated agreeing that sending data (in a Send or within a channel) or sending a Send indication with no DATA attribute creates a permission. 7. Permission and Allocation Lifetimes: What should the default permission lifetime be? Should there be a minumum value? Should there be a way for the client to modify the permission lifetime? Should there be a way for the client to learn the current permission lifetime? And what is the relationship of the permission lifetime to the allocation lifetime? Does it make sense for the allocation lifetime to be less than the permission lifetime? We agreed a long time ago that 30 seconds for a UDP permission was appropriate and consistent with NATs. 8. Preserving bits in the IP header: What bits (if any) should be preserved in the IP header when a packet is relayed by the server? The bits under consideration are currently the Don't Fragment (DF) bit, the Explicit Congestion Notification (ECN) bits, and the DiffServ (DS) bits. OPEN ISSUE: IMO, this is an implementation issue. The server can try to preserve some of these bits, but is not obligated to do so. The client cannot count on any of these bits being passed along. If this is not good enough in practice, we can add an extension that provides this type of transparency. 9. Exceeding the Path MTU Size: TURN adds an overhead of 4 bytes (ChannelData msg) or 36 bytes (Send or Data Indication), thus potentially exceeding the path MTU between the client and server. This could either cause IP fragmentation, or cause the packet to be dropped if the DF bit is set. Who handles this problem? Does TURN need to handle this, or is this left up to the application to handle? We agreed back when we added the framing that this was a non-issue for the protocol. 10. Allowed PEER-ADDRESS values: Should there be any restrictions on the IP address the client can specify in the PEER-ADDRESS attribute? Are multicast addresses allowed? What about 0.0.0.0? Any other restrictions? I think server implementations are capable of taking care of this themselves. I don't think we need to specify this in the protocol. I certainly don't think this is an open issue, since I don't it is an issue. 11. Discarding UDP datagrams: If the server discards a received UDP datagram on the relayed transport address (because there is no corresponding permission), then does the server send an ICMP response? If so, what error code does it use? (What does RFC 4787 say about the corresponding situation in NATs? I believe many NATs silently discard these packets by default, or have a "stealth mode" that enables this behavior.) We agreed and the draft has said for a very long time "silently discards" 12. Authentication: Is the use of STUN's Long-Term Authentication Mechanism by a TURN server mandatory? The document currently implicitly assumes "yes", but what about someone who wants to operate a public TURN server? I believe we had consensus that even/especially public STUN servers MUST use long-term authentication. 13. Re-using the 5-tuple: If an allocation expires, is there any reason a client should not be able to immediately create a new allocation using the same 5-tuple? Yes, there is a good reason. The protocol does not allow requesting a specific requested ip address and port unless asking for the second port in a pair of ports. 14. Password change: Is it possible to change the password for the Long-Term Authentication mechanism during the lifetime of an allocation? If so, how is it done? IMO: Up to the implementation. 15. IPv6: TURN probably works fine in an all IPv6 environment, but there are a number of mixed IPv4/IPv6 cases that are ill- specified. As an example, the server needs to check that the PEER-ADDRESS in a Send Indication is of the same address family as the relayed transport address. Should we carefully work through all these cases and make sure we have caught them all, or should we just state that this document covers the IPv4 case only, and punt the specification of IPv6 and mixed IPv4/IPv6 operation to draft-ietf-behave-turn-ipv6? Does the current interest in resurecting IPv4-to-IPv6 NATs have any impact on TURN? We agreed that this will be handled in a separate document. thanks, -rohan ------=_Part_8360_21334118.1201503267926 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

I think most of the so-called open issues in TURN-06 are not really open issues. My recollection follows for the ones I think are not open, and my opinion for items #4 and #8 which I consider the only real open issue on the list:

17.1. Open Issues

   1.   Bandwidth: What should we do with the BANDWIDTH attribute, which
        is currently ill-specified?  Should we remove it?  Or should we
        try to come up with a good specification, perhaps using ideas
        from RSVP?

I recall that we agreed that it is a hint.

   2.   Permission Policy: What should the permission policy be?
        Address-restricted, as is currently specified in the document?
        Or address-and-port-restricted, as many firewalls implement
        today?  Or should we leave this open to the implementor, under
        the assumption that the IT administrator will only allow clients
        to contact those servers that implement whatever permission
        policy the IT administrator can accept?

We definitely agreed that the permission policy is address-restricted.

   3.   Port Adjacency: The spec currently allows a client to request
        that the server allocate a port and also reserve the next higher
        port number for a possible future allocation (on a different
        5-tuple).  However, the exact behavior of the server in this
        case is ill-specified.  For example, must the next-higher-port
        be available for the allocation of the lower port number to
        succeed?  How long is the next-higher-port reserved? 30 seconds?
        For the lifetime of the lower-numbered-port's allocation?  Or
        should we just ditch this feature, since it is difficult to
        implement, it is at odds with port randomization, and paired
        port numbers applications don't work well with NATs anyway?

We agreed to keep this at the adhoc. The server is asked to come up with ANY even port with the next higher port available.  The client was never allowed to ask for a pair of ports with a specific port number (the syntax actually prevents this). 

IMO, the server is reserving the next port as a courtesy, so the amount of time the server wants to wait is up to the server.

   4.   Demuxing ChannelData messages: How does a client or server demux
        STUN-formatted messages from ChannelData messages?  Does it use
        the first two bits (as currently specified) or just one bit?
        And how many channels do we need anyway?  Some people are
        questioning the need for any more than 200 channels.  If we
        don't need many channels, then the demux algorithm might become
        simpler.

OPEN ISSUE:
Unfortunately I have to agree that this is an open issue, but only because we are not using the 4-octet framing for every message as we had consensus to do in TURN -05. My opinion is that we should go back to TURN framing for all TURN messages.

   5.   Deallocating Channels: Do we need a mechanism for deallocating
        channels?  Some have argued for this feature, because a TURN
        server administrator will want a way to recover resources for
        channels no longer in active use.  If yes, then what is the
        mechanism?  For example, should a channel binding expire when
        the corresponding permission expires?

I recall that we came to consensus that this was not necessary.  If the client is really concerned, it can open a new allocation and transition its active peers to the new address.

   6.   Permissions and Channel Allocations: Should allocating a channel
        for a peer automatically install a permission for that peer's IP
        address?

We agreed long ago, and repeated agreeing that sending data (in a Send or within a channel) or sending a Send indication with no DATA attribute creates a permission.

   7.   Permission and Allocation Lifetimes: What should the default
        permission lifetime be?  Should there be a minumum value?
        Should there be a way for the client to modify the permission
        lifetime?  Should there be a way for the client to learn the
        current permission lifetime?  And what is the relationship of
        the permission lifetime to the allocation lifetime?  Does it
        make sense for the allocation lifetime to be less than the
        permission lifetime?

We agreed a long time ago that 30 seconds for a UDP permission was appropriate and consistent with NATs.

   8.   Preserving bits in the IP header: What bits (if any) should be
        preserved in the IP header when a packet is relayed by the
        server?  The bits under consideration are currently the Don't
        Fragment (DF) bit, the Explicit Congestion Notification (ECN)
        bits, and the DiffServ (DS) bits.

OPEN ISSUE:  IMO, this is an implementation issue.  The server can try to preserve some of these bits, but is not obligated to do so.  The client cannot count on any of these bits being passed along.  If this is not good enough in practice, we can add an extension that provides this type of transparency.

   9.   Exceeding the Path MTU Size: TURN adds an overhead of 4 bytes
        (ChannelData msg) or 36 bytes (Send or Data Indication), thus
        potentially exceeding the path MTU between the client and
        server.  This could either cause IP fragmentation, or cause the
        packet to be dropped if the DF bit is set.  Who handles this
        problem?  Does TURN need to handle this, or is this left up to
        the application to handle?

We agreed back when we added the framing that this was a non-issue for the protocol. 

   10.  Allowed PEER-ADDRESS values: Should there be any restrictions on
        the IP address the client can specify in the PEER-ADDRESS
        attribute?  Are multicast addresses allowed?  What about
        0.0.0.0?  Any other restrictions?

I think server implementations are capable of taking care of this themselves.  I don't think we need to specify this in the protocol.  I certainly don't think this is an open issue, since I don't it is an issue.

   11.  Discarding UDP datagrams: If the server discards a received UDP
        datagram on the relayed transport address (because there is no
        corresponding permission), then does the server send an ICMP
        response?  If so, what error code does it use?  (What does RFC
        4787 say about the corresponding situation in NATs?  I believe
        many NATs silently discard these packets by default, or have a
        "stealth mode" that enables this behavior.)

We agreed and the draft has said for a very long time "silently discards"

   12.  Authentication: Is the use of STUN's Long-Term Authentication
        Mechanism by a TURN server mandatory?  The document currently
        implicitly assumes "yes", but what about someone who wants to
        operate a public TURN server?

I believe we had consensus that even/especially public STUN servers MUST use long-term authentication.

   13.  Re-using the 5-tuple: If an allocation expires, is there any
        reason a client should not be able to immediately create a new
        allocation using the same 5-tuple?

Yes, there is a good reason.  The protocol does not allow requesting a specific requested ip address and port unless asking for the second port in a pair of ports.

   14.  Password change: Is it possible to change the password for the
        Long-Term Authentication mechanism during the lifetime of an
        allocation?  If so, how is it done?

IMO: Up to the implementation. 

   15.  IPv6: TURN probably works fine in an all IPv6 environment, but
        there are a number of mixed IPv4/IPv6 cases that are ill-
        specified.  As an example, the server needs to check that the
        PEER-ADDRESS in a Send Indication is of the same address family
        as the relayed transport address.  Should we carefully work
        through all these cases and make sure we have caught them all,
        or should we just state that this document covers the IPv4 case
        only, and punt the specification of IPv6 and mixed IPv4/IPv6
        operation to draft-ietf-behave-turn-ipv6?  Does the current
        interest in resurecting IPv4-to-IPv6 NATs have any impact on
        TURN?

We agreed that this will be handled in a separate document.

thanks,
-rohan
------=_Part_8360_21334118.1201503267926-- --===============1338408556== 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 --===============1338408556==-- From behave-bounces@ietf.org Mon Jan 28 09:17:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJUnE-00028k-Nd; Mon, 28 Jan 2008 09:17:00 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JJUnD-00028I-Am for behave-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 09:16:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJUnD-00028A-0X for behave@ietf.org; Mon, 28 Jan 2008 09:16:59 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-05.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJUn9-0000Ly-QL for behave@ietf.org; Mon, 28 Jan 2008 09:16:58 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JJUmM-00018k-1t; Mon, 28 Jan 2008 09:16:07 -0500 In-Reply-To: <953beacc0801261608s2f8480b1i36a384adbb11baf@mail.gmail.com> References: <4759D19B.50005@cisco.com> <30C5AFE6-C9FC-40FE-8A74-80B568FBD554@magma.ca> <1C97A587-D403-48D0-B086-584F7975FC31@cisco.com> <3E8D0268-A6CF-460B-827C-7358367FC961@magma.ca> <47685AF4.9030909@cisco.com> <1C6AF3B7-BB61-45B1-A2CA-C02EAFFB5B66@magma.ca> <4790C67D.8030607@ericsson.com> <951756A8-E7C3-48C8-9C8A-2D359AB7700D@magma.ca> <4790D2AF.3060802@ericsson.com> <953beacc0801261608s2f8480b1i36a384adbb11baf@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <81412184-0592-44E1-8EE5-47B54EFF68AA@magma.ca> From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages Date: Mon, 28 Jan 2008 09:16:56 -0500 To: Rohan Mahy X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 1.8 (+) X-Scan-Signature: 57b3d456dc4730784e7070d5c6b7d14f 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="===============0917765410==" Errors-To: behave-bounces@ietf.org --===============0917765410== Content-Type: multipart/alternative; boundary=Apple-Mail-7--115682710 --Apple-Mail-7--115682710 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I definitely remember the issue being raised at the group meeting in Vancouver. I also think it was discussed in the adhoc (but I may be wrong). It was definitely raised on the list by Jonathan and debated in the weeks before the conf call on 20 Dec. On Dec 20, it was discussed and agreed that the framing would not be used for STUN-formatted messages. I recall this well, because I was originally wanted to keep things as they were in TURN-05 and Derek was trying to convince me that he really wanted it to not use framing on STUN-formatted msgs. However, the group decided to not frame those msgs, and I really do not want to re-open this question now. - Philip On 26-Jan-08, at 19:08 , Rohan Mahy wrote: > I have watched this discussion for the last several weeks, fully > expecting for sanity to reassert itself at some point in the > discussion. > > I think it is wholly inappropriate to revisit this framing issue > again. We had a very strong consensus at a previous meeting and on > the mailing list that we were going to apply framing to every > message. In fact we agreed that the framing length on UDP would be > the actual length. This framing was added and we agreed at the > adhoc and shortly thereafter on the list to use EKR's proposed > ChannelBinding approach to associate non-zero channel numbers with > a peer WITH the framing on every message. Then, on a phone call > (on Dec 20th), the folks on the call decided to reopen a design > decision that had no associated open issue and no technical problem > associated with it. > > The supposed benefits of running without framing are not new and > were mentioned explicitly the last time we went over this issue and > we decided that they were pretty weak. 1) Running STUN and TURN on > the same port: nobody cared, 3) Might make people more aware that > TURN is an extension of STUN: this is philisophical wanking of the > highest degree--WHO CARES!, 2) Ditching framing saves 4-bytes: This > was the crux of the discussion and we decided the simplicity and > determinism of using consistent framing was far more important than > 4 octets when using UDP (recall that we always need this framing > over TCP). > > Applying framing to every message consistently makes the protocol > and its implementations simpler. When I rewrote TURN to use > consistent framing, I was amazed at how much simpler the protocol > was to explain in the spec and after speaking to several > implementors, the feedback I received was very consistent. > Consistent framing was easier to implement, resulted in fewer > corner cases and resulted in code that was easier to understand and > maintain. > > While I don't care how many bits we use to represent a channel > number, I strongly suggest we go back to framing every TURN message. > > thanks, > -rohan > > > On Dec 7, 2007 3:04 PM, Jonathan Rosenberg wrote: > This issue was not in my slides. It was brought up at the mike in the > WG, and was discussed there. It was not discussed further at the ad- > hoc. > > As of turn-05, we introduced a framing mechanism, which is a 4 byte > header consisting of 2 bytes channel and 2-bytes length. This framing > header precedes ALL packets sent between a client and its TURN server, > including both application data and TURN messages themselves, which > are > sent on channel zero. > > Ekr raised a question of why this header was needed for actual TURN > messages. After all, he argued, we went through all this trouble to > make > STUN (and thus TURN) differentiatable from each other. Indeed, others > noted that the framing header itself looks very similar to the top 4 > bytes of the STUN message format anyway: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > |0 0| STUN Message Type | Message > Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > | Magic > Cookie | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > > | | > | Transaction ID (96 > bits) | > > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > > > and the proposed framing header: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > | Channel | Message > Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > > So an alternative design is to make the framing header look like: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > |1| Channel | Message > Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > > So that there are 15 bits of channel instead of 16. Placing a 1 in > that > position makes the framing header always a non-match for STUN > messages. > Thus, it would not be even needed to do the more complex matching > operations defined in STUN; a 1-bit check would do the job to separate > out application data from STUN/TURN. > > The benefits of this change would be: > > 1. We would, once again, be able to run STUN and TURN on the same > port on the server. As of turn-05 they MUST run on different ports > because the framing header was unique to TURN. This could be a feature > or a bug depending on your perspective: > > FEATURE: TURN and STUN are actually very different; using > separate ports would allow a firewall to block one and not the other. > > BUG: practically speaking separate ports doesnt help since > with DNS the ports can be dynamic anyway. In addition, its always good > to use fewer ports on a server. Also its weird that an extension to a > protocol would run on a different port; that kind of tells you its not > an extension. > > 2. Reduces the size of TURN messages by 4 bytes. This is a minor > benefit and the real one is having a single port. > > 3. it'd be a little clearer to explain to people that TURN is an > extension to STUN, rather than saying, TURN is a STUN extension > that is > run over a new framing header > > The drawbacks of this change would be: > > 1. cuts the number of channels in half > > > An alternative design would be to use the full 16 bits for channel > numbers, and then rely on the full suite of STUN differentiation > techniques to demux. However, my preference in general is to not do > that > when its not actually needed. It complicates message processing and I > don't think its worth it. 32767 channels is also a LOT for our > envisioned use cases. > > This was somewhat inconclusive at the microphone. I'm personally on > the > fence and don't feel that strongly. I probably midly prefer making > this > change. > > Please comment on whether you prefer this change or not. > > On Jan 18, 2008 9:42 AM, Philip Matthews > wrote: > Let me summarize what I believe is the current state of this issue. > > We have agreed that TURN control messages will _not_ use the framing > header. Separately, we have also agreed to use EKRs mechanism to > allocate channels. The combination of these two means that the > "framing header" is only used for application data traveling on a > channel. What this really means is that we have a new non-STUN- > formatted message that carries application data. I am proposing to > call this message a "ChannelData" message. > > So the point we are discussing now is how to distinguish a > ChannelData message from a STUN-formatted message. Here the original > proposal was to use the first bit of the message to distinguish the > two: a STUN-formatted message has the first bit set to 0, and the > ChannelData message has the first bit set to 1. > > My proposal is to instead use the first two bits. My reasoning is > that the first two bits of a STUN message are always '00' and all > other combinations can be used for the ChannelData message. To be > precise, here is the text that I am proposing: > > The ChannelData message is used to carry application data between > the > client and the server. It has the following format: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Channel Number | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > / Application Data / > / / > | | > | +-------------------------------+ > | | > +-------------------------------+ > > The Channel Number field specifies the number of the channel on > which > the data is traveling, and thus the address of the peer that is > sending or is to receive the data. The channel number MUST be in > the > range 0x4000 - 0xFFFF, with channel number 0xFFFF being reserved > for > possible future extensions. > > Channel numbers 0x0000 - 0x3FFF cannot be used because bits 0 and 1 > are used to distinguish ChannelData messages from STUN-formatted > messages (i.e., Allocate, Send, Data, ChannelBind, etc). STUN- > formatted messages always have bits 0 and 1 as "00", while > ChannelData messages use combinations "01", "10", and "11". > > In discussing how to distinguish ChannelData messages from STUN- > formatted messages, the following issues have been raised: > * (Derek) It is easier to look at just one bit, rather than two bits. > * (Cullen) How many channels do we need anyway? Why do we need more > than 200 channels? > > In addition, there is the question of whether we need a way to de- > allocate channels. During the conf call of 20 Dec, there was > agreement amongst the participants that such a mechanism was > required, but so far no mechanism has been proposed yet. > > Right now, my intention is to put the above text into TURN-06 and > then flag three open issues: > 1) What is the exact format of the ChannelData message? > 2) How many channels do we need? > 3) Do we need a mechanism to release channels, and if so, what does > it look like? > > My personal opinion on #3 is now leaning to "YES", but I haven't had > a chance to propose a mechanism yet. > > Comments? > > - Philip > > > > > > > > > _______________________________________________ > 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 --Apple-Mail-7--115682710 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 I definitely remember the issue being raised at the group meeting in = Vancouver. I also think it was discussed in the adhoc (but I may be = wrong).

It was = definitely raised on the list by Jonathan and debated in the weeks = before the conf call on 20 Dec. On Dec 20, it was discussed and agreed = that the framing would not be used for STUN-formatted messages. I recall = this well, because I was originally wanted to keep things as they were = in TURN-05 and Derek was trying to convince me that he really wanted it = to not use framing on STUN-formatted msgs. =A0However, the group decided = to not frame those msgs, and I really do not want to re-open this = question now.

- Philip

On 26-Jan-08, at = 19:08 , Rohan Mahy wrote:

I = have watched this discussion for the last several weeks, fully expecting = for sanity to reassert itself at some point in the = discussion.

I = think it is wholly inappropriate to revisit this framing issue again. = =A0We had a very strong consensus at a previous meeting and on the = mailing list that we were going to apply framing to every message. In = fact we agreed that the framing length on UDP would be the actual = length. This framing was added and we agreed at the adhoc and shortly = thereafter on the list to use EKR's proposed ChannelBinding approach to = associate non-zero channel numbers with a peer WITH the framing on every = message. =A0Then, on a phone call (on Dec 20th), the folks on the call = decided to reopen a design decision that had no associated open issue = and no technical problem associated with it. =A0

The supposed benefits of = running without framing are not new and were mentioned explicitly the = last time we went over this issue and we decided that they were pretty = weak. =A01) Running STUN and TURN on the same port: nobody cared, 3) = Might make people more aware that TURN is an extension of STUN: this is = philisophical wanking of the highest degree--WHO CARES!, 2) Ditching = framing saves 4-bytes: This was the crux of the discussion and we = decided the simplicity and determinism of using consistent framing was = far more important than 4 octets when using UDP (recall that we always = need this framing over TCP).

Applying framing = to every message consistently makes the protocol and its implementations = simpler. When I rewrote TURN to use consistent framing, I was amazed at = how much simpler the protocol was to explain in the spec and after = speaking to several implementors, the feedback I received was very = consistent. Consistent framing was easier to implement, resulted in = fewer corner cases and resulted in code that was easier to understand = and maintain. =A0

While I don't care how = many bits we use to represent a channel number, I strongly suggest we go = back to framing every TURN message.

=
thanks,
-rohan


On Dec 7, 2007 3:04 PM, Jonathan Rosenberg <jdrosen@cisco.com> wrote:
=
This issue was not in my = slides. It was brought up at the mike in the
WG, and was discussed = there. It was not discussed further at the ad-hoc.

As of turn-05, = we introduced a framing mechanism, which is a 4 byte
header = consisting of 2 bytes channel and 2-bytes length. This framing
header = precedes ALL packets sent between a client and its TURN = server,
including both application data and TURN messages themselves, = which are
sent on channel zero.

Ekr raised a question of why = this header was needed for actual TURN
messages. After all, he = argued, we went through all this trouble to make
STUN (and thus TURN) = differentiatable from each other. Indeed, others
noted that the = framing header itself looks very similar to the top 4
bytes of the = STUN message format anyway:

=A0 =A0 =A0 =A0 0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 3
=A0 =A0 =A0 =A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=A0 =A0 =A0 = =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0= =A0 =A0 =A0|0 0| =A0 =A0 STUN Message Type =A0 =A0 | =A0 =A0 =A0 =A0 = Message Length =A0 =A0 =A0 =A0|
=A0 =A0 =A0 = =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Magic = Cookie =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0= =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0= =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 = =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Transaction ID (96 = bits) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0| =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 = =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=

and the proposed framing header:

=A0 =A0 =A0 =A0 0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3
=A0 =A0 =A0 =A0 0 1 2 3 4 5 6 7 8 9 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=A0 =A0 =A0 = =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0Channel =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 Message Length =A0 =A0 =A0 =A0|
=A0 =A0 =A0 = =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
So an alternative design is to make the framing header look like:
=

=A0 =A0 =A0 =A0 0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3
=A0= =A0 =A0 =A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 = 0 1
=A0 =A0 =A0 = =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= =A0 =A0 =A0 =A0|1| =A0 =A0 =A0Channel =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0= =A0 =A0 =A0 Message Length =A0 =A0 =A0 =A0|
=A0 =A0 =A0 = =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
So that there are 15 bits of channel instead of 16. Placing a 1 in = that
position makes the framing header always a non-match for STUN = messages.
Thus, it would not be even needed to do the more complex = matching
operations defined in STUN; a 1-bit check would do the job = to separate
out application data from STUN/TURN.

The benefits = of this change would be:

=A0 1. We would, once again, be able to = run STUN and TURN on the same
port on the server. As of turn-05 they = MUST run on different ports
because the framing header was unique to = TURN. This could be a feature
or a bug depending on your = perspective:

=A0 =A0 =A0 =A0 =A0FEATURE: TURN and STUN are = actually very different; using
separate ports would allow a firewall = to block one and not the other.

=A0 =A0 =A0 =A0 =A0BUG: = practically speaking separate ports doesnt help since
with DNS the = ports can be dynamic anyway. In addition, its always good
to use = fewer ports on a server. Also its weird that an extension to = a
protocol would run on a different port; that kind of tells you its = not
an extension.

=A0 2. Reduces the size of TURN messages by = 4 bytes. This is a minor
benefit and the real one is having a single = port.

=A0 3. it'd be a little clearer to explain to people that = TURN is an
extension to STUN, rather than saying, TURN is a STUN = extension that is
run over a new framing header

The drawbacks = of this change would be:

=A0 1. cuts the number of channels in = half


An alternative design would be to use the full 16 bits = for channel
numbers, and then rely on the full suite of STUN = differentiation
techniques to demux. However, my preference in = general is to not do that
when its not actually needed. It = complicates message processing and I
don't think its worth it. 32767 = channels is also a LOT for our
envisioned use cases.

This was = somewhat inconclusive at the microphone. I'm personally on the
fence = and don't feel that strongly. I probably midly prefer making = this
change.

Please comment on whether you prefer this change = or not.

On Jan = 18, 2008 9:42 AM, Philip Matthews <philip_matthews@magma.ca> = wrote:
Let me summarize = what I believe is the current state of this issue.

We have agreed = that TURN control messages will _not_ use the framing
header. = Separately, we have also agreed to use EKRs mechanism to
allocate = channels. The combination of these two means that the
"framing = header" is only used for application data traveling on a
channel. = What this really means is that we have a new non-STUN-
formatted = message that carries application data. I am proposing to
call this = message a "ChannelData" message.

So the point we are discussing = now is how to distinguish a
ChannelData message from a STUN-formatted = message. Here the original
proposal was to use the first bit of the = message to distinguish the
two: a STUN-formatted message has the = first bit set to 0, and the
ChannelData message has the first bit = set to 1.

My proposal is to instead use the first two bits. My = reasoning is
that the first two bits of a STUN message are always = '00' and all
other combinations can be used for the ChannelData = message. To be
precise, here is the text that I am = proposing:

=A0 =A0The ChannelData message is used to carry = application data between
the
=A0 =A0client and the server. =A0It = has the following format:

=A0 =A0 0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3
=A0 =A0 0 1 2 3 4 5 6 7 8 9 0 1 2 = 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=A0 = =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0 =A0| =A0 =A0 =A0 =A0 Channel Number =A0 =A0 =A0 =A0| =A0 =A0 =A0 = =A0 =A0 =A0Length =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 = =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0/= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Application Data =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/
=A0 =A0/ =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 /
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 |
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 +-------------------------------+
=A0 =A0| =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 = =A0+-------------------------------+

=A0 =A0The Channel Number = field specifies the number of the channel on
which
=A0 =A0the = data is traveling, and thus the address of the peer that is
=A0 = =A0sending or is to receive the data. =A0The channel number MUST be = in
the
=A0 =A0range 0x4000 - 0xFFFF, with channel number 0xFFFF = being reserved for
=A0 =A0possible future extensions.

=A0 = =A0Channel numbers 0x0000 - 0x3FFF cannot be used because bits 0 and = 1
=A0 =A0are used to distinguish ChannelData messages from = STUN-formatted
=A0 =A0messages (i.e., Allocate, Send, Data, = ChannelBind, etc). =A0STUN-
=A0 =A0formatted messages always have = bits 0 and 1 as "00", while
=A0 =A0ChannelData messages use = combinations "01", "10", and "11".

In discussing how to = distinguish ChannelData messages from STUN-
formatted messages, the = following issues have been raised:
* (Derek) It is easier to look at = just one bit, rather than two bits.
* (Cullen) How many channels do = we need anyway? Why do we need more
than 200 channels?

In = addition, there is the question of whether we need a way to = de-
allocate channels. During the conf call of 20 Dec, there = was
agreement amongst the participants that such a mechanism was
= required, but so far no mechanism has been proposed yet.

Right = now, my intention is to put the above text into TURN-06 and
then flag = three open issues:
1) What is the exact format of the ChannelData = message?
2) How many channels do we need?
3) Do we need a = mechanism to release channels, and if so, what does
it look = like?

My personal opinion on #3 is now leaning to "YES", but I = haven't had
a chance to propose a mechanism yet.
=
Comments?

- = Philip








________________________________= _______________
Behave mailing list
Behave@ietf.org
https://www1.ietf.org/mailman/listinfo/behave

Behave mailing list
=

= --Apple-Mail-7--115682710-- --===============0917765410== 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 --===============0917765410==-- From behave-bounces@ietf.org Mon Jan 28 11:24:03 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJWm9-0003YU-DF; Mon, 28 Jan 2008 11:24:01 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JJWm7-0003Mt-TB for behave-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 11:23:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJWm7-0003Mi-JL for behave@ietf.org; Mon, 28 Jan 2008 11:23:59 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJWm7-0003cU-4I for behave@ietf.org; Mon, 28 Jan 2008 11:23:59 -0500 X-IronPort-AV: E=Sophos;i="4.25,260,1199692800"; d="scan'208";a="10141241" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 28 Jan 2008 08:23:58 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m0SGNvXC013483; Mon, 28 Jan 2008 08:23:57 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m0SGNeAp010305; Mon, 28 Jan 2008 16:23:56 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jan 2008 08:23:22 -0800 Received: from [10.32.241.150] ([10.32.241.150]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jan 2008 08:23:21 -0800 Message-ID: <479E016A.1080005@cisco.com> Date: Mon, 28 Jan 2008 11:23:06 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Alfred E. Heggestad" Subject: Re: [BEHAVE] TURN Issue #4: Port Adjacency References: <4759CC2B.9050206@cisco.com> <47620F8F.2060606@cisco.com> <4790C87C.4030607@ericsson.com> <479B1B16.1070603@db.org> In-Reply-To: <479B1B16.1070603@db.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jan 2008 16:23:21.0767 (UTC) FILETIME=[19692B70:01C861CA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1752; t=1201537437; x=1202401437; c=relaxed/simple; s=sjdkim3002; 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=20Issue=20#4=3A=20Port= 20Adjacency |Sender:=20; bh=/POd/NNOyK7MzJ8XqWDdRI5rAF3IekjU2k7ZYLYf6Wo=; b=s+52OWKgQv4CAemtTq6ust2bEmyiFFxvrJnPaPN21b1m7VpCGD8lpT51Rq dTzYJiHoWFp6KE9llW5G+XtGCh62yLd2ZMJXuNaF2XK2xiwUK6WDJNed/bBK visbhGxqHV; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.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: Alfred E. Heggestad wrote: > Magnus Westerlund wrote: >> Jonathan Rosenberg skrev: >>> The use case is communicating between an ICE agent and a non-ICE >>> traditional Voip client, like a PSTN gateway. Those endpoints >>> frequently implement the old original 1889 and do RTP and RTCP on >>> adjacent ports. Since ICE recommends TURN as the default candidate, >>> when communicating with these peers, we'd be able to get RTCP. >>> WIthout this feature, RTCP will not work. >>> >>> There are still a LOT of endpoints in real deployment that assume >>> RTP/RTCP port adjacency. >>> >> >> Yes, port adjacency must work. >> > > I also this that this operation should be 100% atomic. > > > a simpler way of solving this using atomic allocations: > > - The client sends an AllocateRequest asking for two subsequent ports. > > - The server returns AllocateResponse with two RELAY-ADDRESS attributes, > one for each mapping. > > > This can also be extended to "I want to allocate N subsequent ports". > > > What is missing here is a way for the client to map the two ports. THe problem is that the client needs to send a separate request to the server for each port, so that the server can learn the mapping from the allocated ports to the server reflexive port towards the client. So you are needing multiple requests anyway even if you consider the first one to actually reserve both ports. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 28 11:29:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJWr0-0002bp-Rs; Mon, 28 Jan 2008 11:29:02 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JJWqy-0002bj-U8 for behave-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 11:29:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJWqy-0002bZ-J4 for behave@ietf.org; Mon, 28 Jan 2008 11:29:00 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-05.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJWqy-0000WV-6g for behave@ietf.org; Mon, 28 Jan 2008 11:29:00 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JJWqB-0007sI-1D; Mon, 28 Jan 2008 11:28:11 -0500 In-Reply-To: <4799DC9A.9090901@acm.org> References: <4799DC9A.9090901@acm.org> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: 3/4 of LIFETIME [was Re: [BEHAVE] TURN 06 Comments] Date: Mon, 28 Jan 2008 11:29:01 -0500 To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 I tried to capture this in the open issue around permission and allocation lifetimes. In particular, there seems to be no point in having the allocation lifetime to be less than the permission lifetime. So my suggestion is: * Permission lifetime MUST be at least 2 minutes, with a recommended value of 5 minutes (c.f. BEHAVE-UDP). * Allocation lifetime MUST be at least as long as the permission lifetime. * Allocation lifetime SHOULD be at most one hour. We can debate the exact value for the last point, but the goal is to make sure that the server can detect when the client has crashed. - Philip On 25-Jan-08, at 07:56 , Marc Petit-Huguenin wrote: > Cullen Jennings wrote: >> >> Gave the document a quick skim. Few comments .... >> > > [snip] > >> Not a big deal but I don't like the waiting to 3/4 of LIFETIME, If >> the >> lifetime is 7200 this is way too early - I would prefer something >> more >> like LIFETIME minus 5 seconds and some introduction of jitter. >> > > I agree with this. My suggestion was to use LIFETIME minus 7900ms > (the > duration of a STUN transaction), and to also reject too short LIFETIME > values (e.g. with a 423 error code) and to reject a LIFETIME of 0 > in the > Allocate request instead of considering it a no-op. See comments > #4, #7 > and #18 in this email: > > http://www1.ietf.org/mail-archive/web/behave/current/msg02905.html > > Thanks. > > -- > 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 Mon Jan 28 16:04:24 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJb9R-00032k-Gc; Mon, 28 Jan 2008 16:04:21 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JJb9Q-00032Y-C2 for behave-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 16:04:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJb9Q-00032P-2A for behave@ietf.org; Mon, 28 Jan 2008 16:04:20 -0500 Received: from wr-out-0506.google.com ([64.233.184.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJb9P-0005Ap-I4 for behave@ietf.org; Mon, 28 Jan 2008 16:04:20 -0500 Received: by wr-out-0506.google.com with SMTP id 68so916138wra.13 for ; Mon, 28 Jan 2008 13:04:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=/w4MXIoakRUDyjdEp0taHd5Vob0fNLFrJWvC9YTkuNI=; b=EhUfXAYq9NYmvkGJ1H0yPUAD4Wc8evQrMzaNipcbRHeI8mAq6wRNSVHA4ZMgA9Sr7anvj2PICH1QM3Y13rkwhVKtgUBFVZauzNNXAXW5sXRCE6Ld5158En6dYLNHfDHP1b71TfITLTSId2XbvnhGms5EOMBG/2mPhh7RrmKFLxY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=od630yy6fBDGYOYMgXihXrr/j4b9FNAce2kudtPiWR1Whg0yqR4fxBx+mVM38UFTgZXgbjwTLwF93qpOTf6dG+Y6ji7L1XcedrZAmpqmNfbWRT7wDGMkqA8dkxXgvkO6yfcFqn+yLhjwsZo/xORJg6ZZ3CrXqTrnumj2CWnZOVM= Received: by 10.142.112.5 with SMTP id k5mr2723961wfc.57.1201554257774; Mon, 28 Jan 2008 13:04:17 -0800 (PST) Received: by 10.142.214.15 with HTTP; Mon, 28 Jan 2008 13:04:17 -0800 (PST) Message-ID: <953beacc0801281304u635a0f91g1d758e335a1cc0c5@mail.gmail.com> Date: Mon, 28 Jan 2008 13:04:17 -0800 From: "Rohan Mahy" To: "Philip Matthews" Subject: Re: [BEHAVE] Conf call on TURN scheduled In-Reply-To: <262EBFFA-D31D-40BC-93A5-7E91A42092F6@magma.ca> MIME-Version: 1.0 References: <262EBFFA-D31D-40BC-93A5-7E91A42092F6@magma.ca> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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="===============0056302073==" Errors-To: behave-bounces@ietf.org --===============0056302073== Content-Type: multipart/alternative; boundary="----=_Part_11267_12911592.1201554257792" ------=_Part_11267_12911592.1201554257792 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On the call we had a question about whether the DF bit can be set by applications on common OSes. The following tool, allegedly allows user control over the DF bit and runs on UNIX, Mac, and Windows. http://www.hping.org/ thanks, -rohan On Jan 21, 2008 12:14 PM, Philip Matthews wrote: > The conf call on TURN is now scheduled for Monday, 28 Jan at the > following time: > 11 - 13 Pacific / 14 - 16 Eastern / 21 - 23 Finland > > Bridge information will be sent out tomorrow. > > This call is open to anyone who wishes to attend. However, I would > really appreciate it if you would RSVP if you plan to attend, so I > can make sure the bridge will have enough capacity. > > The goal of the call is to discuss the open issues in TURN-06. > > - Philip > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > ------=_Part_11267_12911592.1201554257792 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On the call we had a question about whether the DF bit can be set by applications on common OSes.  The following tool, allegedly allows user control over the DF bit and runs on UNIX, Mac, and Windows.

http://www.hping.org/

thanks,
-rohan

On Jan 21, 2008 12:14 PM, Philip Matthews <philip_matthews@magma.ca> wrote:
The conf call on TURN is now scheduled for Monday, 28 Jan at the
following time:
11 - 13 Pacific / 14 - 16 Eastern / 21 - 23 Finland

Bridge information will be sent out tomorrow.

This call is open to anyone who wishes to attend. However, I would
really appreciate it if you would RSVP if you plan to attend, so I
can make sure the bridge will have enough capacity.

The goal of the call is to discuss the open issues in TURN-06.

- Philip


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

------=_Part_11267_12911592.1201554257792-- --===============0056302073== 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 --===============0056302073==-- From behave-bounces@ietf.org Mon Jan 28 16:48:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJbqE-00019M-Jx; Mon, 28 Jan 2008 16:48:34 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JJbqD-00015Z-D0 for behave-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 16:48:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJbqD-000154-2F for behave@ietf.org; Mon, 28 Jan 2008 16:48:33 -0500 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJbqC-00052u-NR for behave@ietf.org; Mon, 28 Jan 2008 16:48:32 -0500 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id D90395081A; Mon, 28 Jan 2008 13:50:10 -0800 (PST) Date: Mon, 28 Jan 2008 13:50:10 -0800 From: Eric Rescorla To: "Rohan Mahy" Subject: Re: [BEHAVE] Conf call on TURN scheduled In-Reply-To: <953beacc0801281304u635a0f91g1d758e335a1cc0c5@mail.gmail.com> References: <262EBFFA-D31D-40BC-93A5-7E91A42092F6@magma.ca> <953beacc0801281304u635a0f91g1d758e335a1cc0c5@mail.gmail.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: <20080128215010.D90395081A@romeo.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Behave WG , Philip Matthews 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, 28 Jan 2008 13:04:17 -0800, Rohan Mahy wrote: > > On the call we had a question about whether the DF bit can be set by > applications on common OSes. The following tool, allegedly allows user > control over the DF bit and runs on UNIX, Mac, and Windows. > > http://www.hping.org/ Looks to me like it uses raw sockets. There are lots of tools that allow fine control of the IP header (e.g., traceroute) as long as you can use raw sockets. Unfortunately, raw sockets have two disadvantages: (1) It requires being root on most UNIXes, at least. (2) It means you need to reimplement the entire transport protocol in your app. This is no big deal for UDP, but for TCP, not so much. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 28 17:06:30 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJc7X-0002f8-1Q; Mon, 28 Jan 2008 17:06:27 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JJc7V-0002bO-G6 for behave-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 17:06:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJc7U-0002Zu-Pn for behave@ietf.org; Mon, 28 Jan 2008 17:06:24 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-09.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJc7T-00077O-3H for behave@ietf.org; Mon, 28 Jan 2008 17:06:24 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JJc7L-0007NV-0V; Mon, 28 Jan 2008 17:06:15 -0500 Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <08A6A2ED-2BF5-46D7-B6D1-8785E4958A61@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Mon, 28 Jan 2008 17:06:11 -0500 To: Behave WG X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: Rohan Mahy Subject: [BEHAVE] Summary of TURN open-issues call on Monday, 28 Jan 2008 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 NOTE: Those on the CC list have action items assigned to them. TURN open-issues call on Monday, 28 Jan 2008 Attendees: Philip Matthews Jonathan Rosenberg Rohan Mahy Cullen Jennings Eric Rescorla Lars Eggert Marc Petit-Huguenin Derek MacDonald Remi Denis-Courmond Bob Andreasen *) Stateful allocation issue: In general, sending an Allocate Request on 5-tuple where there is an existing allocation is not allowed; instead, to refresh the allocation the client uses the Refresh Request. However, there is the issue that, over UDP, retransmissions are allowed. Everyone agrees on the high-level concept, but there were some comments about the exact text in the TURN-06 document. There was a lot of discussion here, which I did not capture. However, in the end this seems to boil down to the best way of implementing the above high-level intent. ACTION: Rohan to send proposed text to the mailing list by the end of Wed, 30 Jan 2008. *) Framing for STUN-formatted messages. Rohan did not like the decision taken on the 20 Dec 2008 call that STUN-formatted messages would not be framed. He argued that we should revert to the way things were done in TURN-05. After discussion, a vote was taken and everyone except Rohan either said "don't care" or "leave as in TURN-06" DECISION: STUN-formatted messages will not be framed. *) Codepoints for new errors. There was the question of what codepoints to assign the three new error conditions identified in TURN-06. With very little discussion, everyone agreed that using 400 Bad Request for these cases was fine. DECISION: Remove this new error codes and use 400 Bad Request instead. *) Client sending data before the ChannelBind success response received. The question was: what should the document say about doing this? TURN-06 says the client SHOULD wait, but EKR pointed out that the client not doing so does not harm interoperability. The following proposal was made: - The client MAY send before receiving a success response - The spec will list the pros and cons of not waiting: - (Pro) Uses the channel faster - (Con) Might result in loss of data because (a) over UDP the initial ChannelBind Request might get lost, and (b) the server might be unable to allocate the channel - (Con) If data is lost, then the app might resend which result in much more delay than if the client just waited. DECISION: The proposal is adopted. *) Port Adjacency (and related issues). Should an application be able to request that the server reserve the "next-highest" port? A number of people had suggested (on the mailing list) that this feature be ditched, but others had argued that the feature was needed. In the discussions, all those who had argued that the feature be dropped were ultimately willing to keep the feature. The following proposal was made: - If the server can honor the request, the next-highest port is reserved until allocated (on a separate 5-tuple) via a request for that specific port or until the lower-numbered allocation expires. Philip proposed that a server could simply not implement this feature, but many implementors argued that this would make clients too complex. Cullen argued that the mechanism for actually allocating the next- highest port allows a client to request an specific port, which he does not like. Rohan noted that the REQUESTED-PORT-PROPS attribute also allows the client to request an odd-numbered port. DECISION: The proposal is adopted and implementing the feature is a MUST. DECISION: The ability to request odd ports will be removed ACTION: Cullen to propose a new mechanism that avoids his concerns by Friday, 1 Feb 2008. *) Preserving bits in the IP header. When relaying packets, how should various IP header bits be set? There was general agreement that the path between the client and the peer should be considered as two distinct connections (client <--> server and server <--> peer). However, we were not able to make much progress beyond that. EKR proposed that, as a guiding principle, we should only mandate stuff that could be implemented in a userland application that does not have special (= root) privileges. Philip pointed out that we can divide implementations into two groups: TURN servers running on dedicated machines, where root permission and/or a kernel implementation might be reasonable; and TURN servers in a peer-to- peer environment, where a user-land implementation with no special privileges is highly desirable. There was general agreement on these two points. However, we were unable to make much progress in deciding what to do about specific bits (e.g., the DF bit). A lot of the discussion revolved around what the existing APIs allow an application to do. The discussion then moved to discussing packets that exceed the MTU and how to handle this case, as this situation is highly affected by how IP header bits are set. However, we were still unable to find a good solution to this case. ACTIONS: - Remi will research what can and cannot be done with existing Linux APIs. - EKR will research what can and cannot be done with existing BSD and MacOS APIs. - Derek will research what can and cannot be done with existing Windows APIs. - Philip will research what SOCKS (version 5.1) and IP-in-IP tunneling says about this problem. At this point, time ran out, and a decision was made to try to schedule a second call during the week of Feb 4th. ACTION: Philip to poll attendees for times they can make a second call. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 28 22:19:11 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJh09-0004vj-OZ; Mon, 28 Jan 2008 22:19:09 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JJh08-0004v9-Dg for behave-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 22:19:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJh07-0004sA-Em for behave@ietf.org; Mon, 28 Jan 2008 22:19:07 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJh06-0004Ma-V9 for behave@ietf.org; Mon, 28 Jan 2008 22:19:07 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 28 Jan 2008 19:19:06 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0T3J63T019523; Mon, 28 Jan 2008 19:19:06 -0800 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 m0T3Ixj5001344; Tue, 29 Jan 2008 03:19:00 GMT Message-Id: From: Cullen Jennings To: Philip Matthews , Behave WG Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 28 Jan 2008 19:18:40 -0800 X-Mailer: Apple Mail (2.915) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2942; t=1201576746; x=1202440746; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Getting=20pairs=20of=20ports=20for=20RTP=20usin g=20TURN |Sender:=20; bh=U0BhQZHpl5bycmW74HKAyhih5wnu2lWkDX6WpwdybFQ=; b=hXjMRo+EdSUzVZcXd/wy2+od8f6Wsoe5AIziMSyuQl2oDHTDOYR1lGv49z G3KiBCD8NuImAndPtPIHtU/8MR7kLs39WLpxVpBGFrW2gi0ZQZJCRJvyj5Cn 4pCPxFkpqtN06ha/lDdujBagMuhimGqDPlpxcFd23gfjEhkGZtO1Q=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Subject: [BEHAVE] Getting pairs of ports for RTP using 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 RTP has an unfortunately design attribute that in some cases it expects the RTCP to be on the odd port above the RTP and RTP to be on an even port. We don't have other protocols like this and I really doubt we would want to design things this way in the future but none the less, there is a strong desire for TURN to support all forms of RTP including this. This leads to the need for a TURN client to be able to request an even port number in it's allocations and also for a TURN client to be able to request a pair of ports for use with RTP. Another key design principal of TURN has been to maximize the odds the firewall administrators allowing it thought he firewall by not subverting the will of the firewall admins which will simply result in it being blocked. One of the aspects of this has been to not allow TURN to be used to run general purpose servers without the consent of the firewall admin. The 06 draft is a bit broken with respect to all this but I have a proposal that I think would be very easy to implement, would simultaneously meet all these concerns, and is pretty easy to understand. My suggestion is that we remove the REQUEST-PORTS-PROPS and REQUEST-IP and add add two new attributes. REQUEST-EVEN-PORT and REQUEST-PORT- PAIR. Neither of these have any data and the presence of them is simply treated as a flag by the TURN server. Only one of them should be in a request. The REQUEST-EVEN-PORT causes the server to only allocate an even port. The REQUEST-PORT-PAIR causes the server to allocate a consecutive even port and the odd port that is one greater. The response returns the even port that was allocated along with ODD- PORT-PAIR-TOKEN attribute that caries a 32 bit identifier. When the client receives this token, it can perform another allocate that includes the ODD-PORT-PAIR-TOKEN. The server will recognize that the same user is requesting an allocation with the TOKEN that pairs it with the previous allocation and the TURN server will return the odd port that was allocated with the previous even port. The TURN server needs to ensure that it reserves the port pair for at least 30 seconds after the initial allocation and that it only allocates the port to a ALLOC request that was made by the same user as the initial allocation and where the request has the token that was returned in the original ALLOC. The token does not need to have any security properties - anyone can see it - the server can use an incrementing counter if it wishes. The security comes from only giving out the port to a user with the same credentials as the client that made the initial request. The token is purely used as a way of helping a client that is performing multiple allocations associated the correct pairs of allocations together. Cullen _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 29 03:03:41 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJlRT-0002gH-58; Tue, 29 Jan 2008 03:03:39 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JJlRR-0002fE-Su for behave-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 03:03:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJlRK-0002TA-KE for behave@ietf.org; Tue, 29 Jan 2008 03:03:30 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJlRK-0003Hm-8j for behave@ietf.org; Tue, 29 Jan 2008 03:03:30 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0T84KqF002094; Tue, 29 Jan 2008 02:04:35 -0600 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jan 2008 10:03:09 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jan 2008 10:03:09 +0200 Received: from esdhcp04054.research.nokia.com ([172.21.40.54]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jan 2008 10:03:08 +0200 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Date: Tue, 29 Jan 2008 10:03:32 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <262EBFFA-D31D-40BC-93A5-7E91A42092F6@magma.ca> <953beacc0801281304u635a0f91g1d758e335a1cc0c5@mail.gmail.com> In-Reply-To: <953beacc0801281304u635a0f91g1d758e335a1cc0c5@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200801291003.32195.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 29 Jan 2008 08:03:09.0024 (UTC) FILETIME=[62D5C600:01C8624D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Philip Matthews Subject: [BEHAVE] Linux socket settings 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 Hello, As promised during the telco: Note that I am only considering plain application-layer non-privileged=20 sockets, here. Linux sets the DF bits according path MTU per-socket setting, which can acc= ept=20 for different values (from man 7 ip): Path MTU discovery flags Meaning IP_PMTUDISC_WANT Use per-route settings. IP_PMTUDISC_DONT Never do Path MTU Discovery. IP_PMTUDISC_DO Always do Path MTU Discovery. IP_PMTUDISC_PROBE Set DF but ignore Path MTU. IP_PMTUDISC_WANT is the default, which basically defers to the routing tabl= e.=20 By default and in most cases, that enables Path MTU discovery, as=20 IP_MTUDISC_DO. The purpose of IP_PMTUDISC_PROBE is to allow userland software to do path M= TU=20 probing by themselves. It is also possible to read the current estimate of the Path MTU (IP_MTU=20 getsockopt), or to try to check if a message of a given size is sufficientl= y=20 small (MSG_PROBE send flag). As for DSCP resp. TTL, they can be set on a per-socket basis (IP_TOS resp.= =20 IP_TTL setsockopt). ECN bits cannot be set manually. With UDP *only*, TTL resp. DSCP bits of incoming packets can be received=20 (IP_RECVTTL resp. IP_RECVTOS setsockopt); this obviously does NOT work for= =20 TCP. =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 Tue Jan 29 05:31:32 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJnkX-0002AV-RG; Tue, 29 Jan 2008 05:31:29 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JJnkX-0002AO-6V for behave-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 05:31:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJnkW-0002AE-P0 for behave@ietf.org; Tue, 29 Jan 2008 05:31:28 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJnkW-0000xz-1S for behave@ietf.org; Tue, 29 Jan 2008 05:31:28 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5EA2C20B10; Tue, 29 Jan 2008 11:31:27 +0100 (CET) X-AuditID: c1b4fb3c-a8ae9bb0000007e0-db-479f007fa5f3 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3FBE320AD0; Tue, 29 Jan 2008 11:31:27 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jan 2008 11:31:26 +0100 Received: from [127.0.0.1] ([147.214.31.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jan 2008 11:31:26 +0100 Message-ID: <479F0077.80309@ericsson.com> Date: Tue, 29 Jan 2008 11:31:19 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [BEHAVE] Summary of TURN open-issues call on Monday, 28 Jan 2008 References: <08A6A2ED-2BF5-46D7-B6D1-8785E4958A61@magma.ca> In-Reply-To: <08A6A2ED-2BF5-46D7-B6D1-8785E4958A61@magma.ca> X-Enigmail-Version: 0.95.6 X-OriginalArrivalTime: 29 Jan 2008 10:31:26.0768 (UTC) FILETIME=[1A4DC300:01C86262] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Rohan Mahy , 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="===============2117548921==" Errors-To: behave-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2117548921== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig989207AC22414D2327379DD5" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig989207AC22414D2327379DD5 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable With my individual hat on! Philip Matthews skrev: >=20 > *) Preserving bits in the IP header. When relaying packets, how should = > various IP header bits be set? > There was general agreement that the path between the client and the=20 > peer should be considered as two distinct connections (client <-->=20 > server and server <--> peer). However, we were not able to make much=20 > progress beyond that. I personally don't agree with this characterization when it comes to UDP = on both legs. Because in this case unless you threat this as a single=20 end to end path that are bounced of an reflector, the TURN server will=20 be required to resolve for example the UDP congestion control problems=20 between the server and its peers. It also will need QoS reservation and=20 path MTU discovery signalling interfaces. The amount of information that = needs to be sent between the TURN client and the Turn server for each=20 packet will be significantly increased. Even in the case of TCP -> UDP is problematic. I don't see your=20 agreement to work in the real world. > EKR proposed that, as a guiding principle, we should only mandate stuff= =20 > that could be implemented in a userland application that does not have = > special (=3D root) privileges.=20 I think this requirement may result in that no solutions exist with most = current operating systems. Philip pointed out that we can divide > implementations into two groups: TURN servers running on dedicated=20 > machines, where root permission and/or a kernel implementation might be= =20 > reasonable; and TURN servers in a peer-to-peer environment, where a=20 > user-land implementation with no special privileges is highly desirable= =2E > There was general agreement on these two points. > However, we were unable to make much progress in deciding what to do=20 > about specific bits (e.g., the DF bit). A lot of the discussion revolve= d=20 > around what the existing APIs allow an application to do. > The discussion then moved to discussing packets that exceed the MTU and= =20 > how to handle this case, as this situation is highly affected by how IP= =20 > header bits are set. However, we were still unable to find a good=20 > solution to this case. > ACTIONS: > - Remi will research what can and cannot be done with existing Linu= x=20 > APIs. > - EKR will research what can and cannot be done with existing BSD=20 > and MacOS APIs. > - Derek will research what can and cannot be done with existing=20 > Windows APIs. > - Philip will research what SOCKS (version 5.1) and IP-in-IP=20 > tunneling says about this problem. >=20 I do understand the desire to not require kernal land or otherwise=20 privileged implementations but if that is the only way of ensuring that=20 things are done correctly, then they are that. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------enig989207AC22414D2327379DD5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHnwB+qpZsSJeFbtkRAvmCAKCh8o0wISvChX+tfmrAxKL6EHMKhACfZCCH /2MyPFB91MZjVc9ZxaDz3j8= =cEVu -----END PGP SIGNATURE----- --------------enig989207AC22414D2327379DD5-- --===============2117548921== 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 --===============2117548921==-- From behave-bounces@ietf.org Tue Jan 29 07:27:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJpXq-0004TG-5U; Tue, 29 Jan 2008 07:26:30 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JJpXo-0004Sm-KM for behave-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 07:26:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJpXo-0004RA-9k for behave@ietf.org; Tue, 29 Jan 2008 07:26:28 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJpXl-0007fA-Uj for behave@ietf.org; Tue, 29 Jan 2008 07:26:26 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0TCR7nG030550; Tue, 29 Jan 2008 06:27:29 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jan 2008 14:26:21 +0200 Received: from esdhcp034122.research.nokia.com ([172.21.34.122]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jan 2008 14:26:20 +0200 Message-Id: <89A45E2F-8DCC-4BCC-9385-9311E087B0F5@nokia.com> From: Lars Eggert To: ext Eric Rescorla In-Reply-To: <20080128215010.D90395081A@romeo.rtfm.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [BEHAVE] Conf call on TURN scheduled Date: Tue, 29 Jan 2008 14:26:17 +0200 References: <262EBFFA-D31D-40BC-93A5-7E91A42092F6@magma.ca> <953beacc0801281304u635a0f91g1d758e335a1cc0c5@mail.gmail.com> <20080128215010.D90395081A@romeo.rtfm.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 29 Jan 2008 12:26:20.0553 (UTC) FILETIME=[2751DF90:01C86272] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Behave WG , Philip Matthews 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 2008-1-28, at 23:50, ext Eric Rescorla wrote: > Unfortunately, raw sockets have two disadvantages: ... > (2) It means you need to reimplement the entire transport protocol > in your app. This is no big deal for UDP, but for TCP, not > so much. Well, you could use something like BSD divert sockets to intercept kernel-generated IP packet, diddle bits at in an app and reinject them using RAW sockets, but that's ugly. Lars _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 29 07:54:01 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJpyI-0005Ev-Fh; Tue, 29 Jan 2008 07:53:50 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JJpyG-0005BE-Nw for behave-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 07:53:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJpyG-00058n-Bz for behave@ietf.org; Tue, 29 Jan 2008 07:53:48 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJpyF-0000HV-Oz for behave@ietf.org; Tue, 29 Jan 2008 07:53:48 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0TCrJgs007821 for ; Tue, 29 Jan 2008 14:53:46 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jan 2008 14:53:20 +0200 Received: from esdhcp04054.research.nokia.com ([172.21.40.54]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jan 2008 14:53:21 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] Conf call on TURN scheduled Date: Tue, 29 Jan 2008 14:53:45 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <262EBFFA-D31D-40BC-93A5-7E91A42092F6@magma.ca> <20080128215010.D90395081A@romeo.rtfm.com> <89A45E2F-8DCC-4BCC-9385-9311E087B0F5@nokia.com> In-Reply-To: <89A45E2F-8DCC-4BCC-9385-9311E087B0F5@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200801291453.45542.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 29 Jan 2008 12:53:21.0199 (UTC) FILETIME=[ED4CD3F0:01C86275] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 29 January 2008 14:26:17 ext Lars Eggert, vous avez =E9crit=A0: > On 2008-1-28, at 23:50, ext Eric Rescorla wrote: > > Unfortunately, raw sockets have two disadvantages: > > ... > > > (2) It means you need to reimplement the entire transport protocol > > in your app. This is no big deal for UDP, but for TCP, not > > so much. > > Well, you could use something like BSD divert sockets to intercept > kernel-generated IP packet, diddle bits at in an app and reinject them > using RAW sockets, but that's ugly. BSD divert sockets, and Linux packet sockets have all kind of cool features= ,=20 such as kernel-level filtering using BPF, and memory mapped I/O with ring=20 buffers for high performance logging. It would work. =46or unfragmented UDP packets, it's even not that complicated. =46or TCP (or UDP fragments), it's not "ugly", it's an horrible awful hack,= =20 taking into account that you may have to do TCP re-assembly, and then demux= =20 TURN control messages, and channels stuff. Basically, it's like an=20 transparent ALG, but more complicated. I guess that's what EKR was hinting= =20 at. And then comes the problem of preventing the "regular" IP stack from answer= ing=20 the packets - if you don't use the normal API, it will think the port is no= t=20 allocated and send a ICMP Port Unreachable or TCP/RST back. So you have to= =20 mess up with the firewalling framework, and/or the normal socket API too.=20 Though one could argue that once you've gone to the pain of divert sockets,= =20 these is not that much extra hacking. In any case, while I have no immediate use case for TURN on a "client" box,= I=20 reckon some folks want to deploy TURN servers as normal unprivileged=20 software, to run some kind of peer-to-peer overlay. In this case, they can= =20 neither require privileges, neither extend the existing stack. I think the spec should say what the TURN servers SHOULD do with these=20 controversial bits, but it would be unrealistic that they MUST do that, les= t=20 there be many non-conformant TURN servers. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 29 09:27:18 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJrQh-0003oG-EP; Tue, 29 Jan 2008 09:27:15 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JJrQg-0003ns-UY for behave-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 09:27:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJrQg-0003mz-Iu for behave@ietf.org; Tue, 29 Jan 2008 09:27:14 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-05.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJrQf-00045c-V9 for behave@ietf.org; Tue, 29 Jan 2008 09:27:14 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JJrPs-0003oF-2u; Tue, 29 Jan 2008 09:26:25 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] Getting pairs of ports for RTP using TURN Date: Tue, 29 Jan 2008 09:27:11 -0500 To: Cullen Jennings X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 I like this proposal. I think it gives us what we need without adding extra complexity. I have one small suggested change. I suggest that the ODD-PORT-PAIR- TOKEN be a random number and perhaps be 64 bits rather than 32. This is because I feel it is likely that some organizations will pass out the same credentials (i.e., username and password) to a large number of devices. - Philip On 28-Jan-08, at 22:18 , Cullen Jennings wrote: > > RTP has an unfortunately design attribute that in some cases it > expects the RTCP to be on the odd port above the RTP and RTP to be > on an even port. We don't have other protocols like this and I > really doubt we would want to design things this way in the future > but none the less, there is a strong desire for TURN to support all > forms of RTP including this. This leads to the need for a TURN > client to be able to request an even port number in it's > allocations and also for a TURN client to be able to request a pair > of ports for use with RTP. > > Another key design principal of TURN has been to maximize the odds > the firewall administrators allowing it thought he firewall by not > subverting the will of the firewall admins which will simply result > in it being blocked. One of the aspects of this has been to not > allow TURN to be used to run general purpose servers without the > consent of the firewall admin. > > The 06 draft is a bit broken with respect to all this but I have a > proposal that I think would be very easy to implement, would > simultaneously meet all these concerns, and is pretty easy to > understand. > > My suggestion is that we remove the REQUEST-PORTS-PROPS and REQUEST- > IP and add add two new attributes. REQUEST-EVEN-PORT and REQUEST- > PORT-PAIR. Neither of these have any data and the presence of them > is simply treated as a flag by the TURN server. Only one of them > should be in a request. The REQUEST-EVEN-PORT causes the server to > only allocate an even port. The REQUEST-PORT-PAIR causes the server > to allocate a consecutive even port and the odd port that is one > greater. The response returns the even port that was allocated > along with ODD-PORT-PAIR-TOKEN attribute that caries a 32 bit > identifier. When the client receives this token, it can perform > another allocate that includes the ODD-PORT-PAIR-TOKEN. The server > will recognize that the same user is requesting an allocation with > the TOKEN that pairs it with the previous allocation and the TURN > server will return the odd port that was allocated with the > previous even port. > > The TURN server needs to ensure that it reserves the port pair for > at least 30 seconds after the initial allocation and that it only > allocates the port to a ALLOC request that was made by the same > user as the initial allocation and where the request has the token > that was returned in the original ALLOC. The token does not need to > have any security properties - anyone can see it - the server can > use an incrementing counter if it wishes. The security comes from > only giving out the port to a user with the same credentials as the > client that made the initial request. The token is purely used as a > way of helping a client that is performing multiple allocations > associated the correct pairs of allocations together. > > > Cullen > > > > > _______________________________________________ > 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 Jan 29 09:45:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJriY-000101-Ll; Tue, 29 Jan 2008 09:45:42 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JJriX-0000vS-2Y for behave-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 09:45:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJriW-0000ul-Ox for behave@ietf.org; Tue, 29 Jan 2008 09:45:40 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-02.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJriW-0001lB-AO for behave@ietf.org; Tue, 29 Jan 2008 09:45:40 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JJriV-0000Zo-2h; Tue, 29 Jan 2008 09:45:39 -0500 In-Reply-To: <4794CFAC.2080203@ericsson.com> References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <478E5883.5090606@acm.org> <4A3CAD0D-F58D-4EE2-B59A-04F463745D1D@magma.ca> <3C898AB6-05B8-4854-8E20-5E87B304F905@cisco.com> <96483AA0-7F26-494C-9931-19D9BAB0017D@magma.ca> <4790CDFA.3000209@ericsson.com> <4794CFAC.2080203@ericsson.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7ACC5B3A-4EC2-4BC0-9BB9-9CAD69B56B5D@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header Date: Tue, 29 Jan 2008 09:45:38 -0500 To: Magnus Westerlund X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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: I am replying to you under the "Preserving bits in the IP header" thread, since that is what we are talking about. As a general comment, I think many of us now view this as perhaps the hardest open issue that we have to solve. More inline. - Philip On 29-Jan-08, at 05:31 , Magnus Westerlund wrote: > With my individual hat on! > > Philip Matthews skrev: >> *) Preserving bits in the IP header. When relaying packets, how >> should various IP header bits be set? >> There was general agreement that the path between the client and >> the peer should be considered as two distinct connections (client >> <--> server and server <--> peer). However, we were not able to >> make much progress beyond that. > > I personally don't agree with this characterization when it comes > to UDP on both legs. Because in this case unless you threat this as > a single end to end path that are bounced of an reflector, the TURN > server will be required to resolve for example the UDP congestion > control problems between the server and its peers. It also will > need QoS reservation and path MTU discovery signalling interfaces. > The amount of information that needs to be sent between the TURN > client and the Turn server for each packet will be significantly > increased. > > Even in the case of TCP -> UDP is problematic. I don't see your > agreement to work in the real world. Personally, I am reluctant to treat the UDP-UDP case differently from the TCP-UDP case. So, unless we drop the TCP-UDP case, then I feel we need to focus an a good solution for that case, since it seems to be the harder one (as I think Cullen first pointed out). I think we are looking for a solution with the following requirements: a) Must work for both the UDP-UDP case and the TCP-UDP case b) Must work (or mostly work) when the TURN server runs as a ordinary, unprivileged user-land application c) Must provide a solution to the MTU exceeded problem (on either the client-server leg or the server-peer leg) d) Must provide a way to have end-to-end QOS. > > >> EKR proposed that, as a guiding principle, we should only mandate >> stuff that could be implemented in a userland application that >> does not have special (= root) privileges. > > I think this requirement may result in that no solutions exist with > most current operating systems. It may be that we will have to identify what will be lost with a non- privileged user-land implementation. However, I think that many people want to implement this type of implementation, so it behooves us to look hard for what we can achieve with such an implementation. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 29 10:33:14 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJsSV-0005Ay-1K; Tue, 29 Jan 2008 10:33:11 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JJsSS-0005Af-Fk for behave-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 10:33:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJsSS-0005AW-13 for behave@ietf.org; Tue, 29 Jan 2008 10:33:08 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJsSR-0005yF-Dw for behave@ietf.org; Tue, 29 Jan 2008 10:33:07 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JVE00EF9WJ6QH@usaga01-in.huawei.com> for behave@ietf.org; Tue, 29 Jan 2008 07:33:07 -0800 (PST) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JVE00AZNWJ4N1@usaga01-in.huawei.com> for behave@ietf.org; Tue, 29 Jan 2008 07:33:06 -0800 (PST) Date: Tue, 29 Jan 2008 09:32:36 -0600 From: Spencer Dawkins Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header To: Behave Mailing List Message-id: <015001c8628c$2cf02be0$6401a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <478E5883.5090606@acm.org> <4A3CAD0D-F58D-4EE2-B59A-04F463745D1D@magma.ca> <3C898AB6-05B8-4854-8E20-5E87B304F905@cisco.com> <96483AA0-7F26-494C-9931-19D9BAB0017D@magma.ca> <4790CDFA.3000209@ericsson.com> <4794CFAC.2080203@ericsson.com> <7ACC5B3A-4EC2-4BC0-9BB9-9CAD69B56B5D@magma.ca> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 >>> EKR proposed that, as a guiding principle, we should only mandate stuff >>> that could be implemented in a userland application that does not have >>> special (= root) privileges. >> >> I think this requirement may result in that no solutions exist with most >> current operating systems. > > It may be that we will have to identify what will be lost with a non- > privileged user-land implementation. However, I think that many people > want to implement this type of implementation, so it behooves us to look > hard for what we can achieve with such an implementation. > > - Philip FWIW, I agree with EKR's goal, Magnus's concern, and Philip's compromise :-) Thanks, Spencer _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 29 10:37:55 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJsX4-0007ht-Q9; Tue, 29 Jan 2008 10:37:54 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JJsX4-0007hX-5D for behave-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 10:37:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJsX3-0007hP-RU for behave@ietf.org; Tue, 29 Jan 2008 10:37:53 -0500 Received: from server.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJsX2-0002zD-1H for behave@ietf.org; Tue, 29 Jan 2008 10:37:53 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id 562257F103C; Tue, 29 Jan 2008 15:37:51 +0000 (UTC) Received: from [192.168.1.3] (c-71-202-183-123.hsd1.ca.comcast.net [71.202.183.123]) by server.implementers.org (Postfix) with ESMTP id A90B37F103C; Tue, 29 Jan 2008 15:37:47 +0000 (UTC) Message-ID: <479F4848.2000204@acm.org> Date: Tue, 29 Jan 2008 07:37:44 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080109) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [BEHAVE] Getting pairs of ports for RTP using TURN References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Behave WG , Philip Matthews 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 Cullen Jennings wrote: > > RTP has an unfortunately design attribute that in some cases it expects > the RTCP to be on the odd port above the RTP and RTP to be on an even > port. We don't have other protocols like this and I really doubt we > would want to design things this way in the future but none the less, > there is a strong desire for TURN to support all forms of RTP including > this. This leads to the need for a TURN client to be able to request an > even port number in it's allocations and also for a TURN client to be > able to request a pair of ports for use with RTP. > > Another key design principal of TURN has been to maximize the odds the > firewall administrators allowing it thought he firewall by not > subverting the will of the firewall admins which will simply result in > it being blocked. One of the aspects of this has been to not allow TURN > to be used to run general purpose servers without the consent of the > firewall admin. > > The 06 draft is a bit broken with respect to all this but I have a > proposal that I think would be very easy to implement, would > simultaneously meet all these concerns, and is pretty easy to understand. > > My suggestion is that we remove the REQUEST-PORTS-PROPS and REQUEST-IP > and add add two new attributes. REQUEST-EVEN-PORT and REQUEST-PORT-PAIR. > Neither of these have any data and the presence of them is simply > treated as a flag by the TURN server. Only one of them should be in a > request. The REQUEST-EVEN-PORT causes the server to only allocate an > even port. The REQUEST-PORT-PAIR causes the server to allocate a > consecutive even port and the odd port that is one greater. The response > returns the even port that was allocated along with ODD-PORT-PAIR-TOKEN > attribute that caries a 32 bit identifier. When the client receives this > token, it can perform another allocate that includes the > ODD-PORT-PAIR-TOKEN. The server will recognize that the same user is > requesting an allocation with the TOKEN that pairs it with the previous > allocation and the TURN server will return the odd port that was > allocated with the previous even port. I am not sure to understand how that it is better than the current text, assuming that REQUESTED-IP and REQUEST-PORTS-PROPS with specific port can only refer to an IP address/port allocated previously by the same user on the same tuple as the second port of a pair. Also the REQUESTED-IP attribute alone permitted to request a port on a specific IP address on a TURN server that have multiple interfaces. I do not know if there is SIP endpoints that are broken in presence of SDP with different IP addresses for different m= lines, but the REQUESTED-IP would help to fix this. > > The TURN server needs to ensure that it reserves the port pair for at > least 30 seconds after the initial allocation and that it only allocates > the port to a ALLOC request that was made by the same user as the > initial allocation and where the request has the token that was returned > in the original ALLOC. The problem of the 30 seconds is that an additional timer is needed in the implementation. Why do not just reserve the port for the duration of the allocation? > The token does not need to have any security > properties - anyone can see it - the server can use an incrementing > counter if it wishes. The security comes from only giving out the port > to a user with the same credentials as the client that made the initial > request. The token is purely used as a way of helping a client that is > performing multiple allocations associated the correct pairs of > allocations together. > > > Cullen > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > -- 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 Tue Jan 29 16:07:22 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJxfr-0007wm-9J; Tue, 29 Jan 2008 16:07:19 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JJxfq-0007wg-57 for behave-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 16:07:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJxfp-0007wY-Mm for behave@ietf.org; Tue, 29 Jan 2008 16:07:17 -0500 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJxfo-0003mG-Iq for behave@ietf.org; Tue, 29 Jan 2008 16:07:17 -0500 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 8946F24083C; Tue, 29 Jan 2008 22:07:11 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id F179D117A1; Tue, 29 Jan 2008 22:06:31 +0100 (CET) Date: Tue, 29 Jan 2008 22:06:31 +0100 From: Stephane Bortzmeyer To: =?iso-8859-1?Q?R=E9mi?= Denis-Courmont Message-ID: <20080129210631.GA965@sources.org> References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <200801030949.41979.remi.denis-courmont@nokia.com> <914FB0C9-1F63-4EBB-BADE-26F5506619A7@magma.ca> <200801081223.17053.remi.denis-courmont@nokia.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline In-Reply-To: <200801081223.17053.remi.denis-courmont@nokia.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3b8eea209b62bd15620865bc4fbef8cd Cc: behave@ietf.org, ext Philip Matthews Subject: [BEHAVE] Re: TURN Issue: Preserving bits in the IP header 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 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 08, 2008 at 12:23:16PM +0200, R=E9mi Denis-Courmont wrote=20 a message of 33 lines which said: > As far as I know the Winsock (Windows), Linux and BSD socket API > implementations, none of them provide per-packet TOS and ECN bit > specification. To ease the current survey of implementations, I wrote the attached small program, that you can run on your system (tested on many Unix, VMS - if someone wants to run a TURN server on VMS - and Windows XP), to see what bits in the IP header an ordinary application can *set* (wether it can *gets* them is another issue). To compile: make To run: make test If you are root, I suggest to run it with and without root privileges, the results may be different (for instance on Linux). It may be a good idea to send the results only to me or to the persons responsible for the tests (see http://www1.ietf.org/mail-archive/web/behave/current/msg03248.html). A big warning: the program only tests that the system accepts the option, not that it complies.=20 Executive summary of the results so far: TTL, ECN and DSCP seem to be easily settable. precedence and DF are more questionable. Some results: My UID is 1000 The system is Linux 2.6.8-4-k7, the machine is i686 TTL successfully set to 10 TOS successfully set to 8 ECN successfully set to 2 [PROBLEM] Cannot set the precedence to 160: (Operation not permitted) DF set through PMTU successfully set to 2 DF clear through PMTU successfully set to 0 My UID is 0 The system is Linux 2.6.8-4-k7, the machine is i686 TTL successfully set to 10 TOS successfully set to 8 ECN successfully set to 2 precedence successfully set to 160 DF set through PMTU successfully set to 2 DF clear through PMTU successfully set to 0 My UID is 1055 The system is OSF1 V5.1, the machine is alpha TTL successfully set to 10 TOS successfully set to 8 ECN successfully set to 2 precedence successfully set to 160 No known way to set the DF bit on this system My UID is 54131 The system is FreeBSD 6.2-RELEASE, the machine is i386 TTL successfully set to 10 TOS successfully set to 8 ECN successfully set to 2 precedence successfully set to 160 No known way to set the DF bit on this system My UID is 1000 The system is NetBSD 3.1, the machine is sparc64 TTL successfully set to 10 TOS successfully set to 8 ECN successfully set to 2 precedence successfully set to 160 No known way to set the DF bit on this system My UID is 0 The system is Darwin 9.1.0, the machine is i386 TTL successfully set to 10 TOS successfully set to 8 ECN successfully set to 2 precedence successfully set to 160 No known way to set the DF bit on this system My UID is 1005 The system is CYGWIN_NT-5.1 1.5.24(0.156/4/2), the machine is i686 TTL successfully set to 10 TOS successfully set to 8 ECN successfully set to 2 precedence successfully set to 160 No known way to set the DF bit on this system My UID is 8491703 The system is OpenVMS 0, the machine is HP_rx2600__(1.40GHz/1.5MB) TTL successfully set to 10 TOS successfully set to 8 ECN successfully set to 2 precedence successfully set to 160 No known way to set the DF bit on this system --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=Makefile CC=gcc CFLAGS=-Wall LD=${CC} LDFLAGS= all: ip-header-set ip-header-set: ip-header-set.o ${LD} ${LDFLAGS} -o $@ ip-header-set.o ip-header-set.o: ip-header-set.c ${CC} ${CFLAGS} -c ip-header-set.c test: ip-header-set ./ip-header-set clean: rm -f ip-header-set ip-header-set.o --tKW2IUtsqtDRztdT Content-Type: text/x-csrc; charset=us-ascii Content-Disposition: attachment; filename="ip-header-set.c" #include #include #include #include #include #include #include #include #include #include #include /* Most of error-handling routines stolen from Stevens' books */ void err_sys(char *str, ...); void err_ret(char *str, ...); void err_quit(char *str, ...); char *sys_err_str(); void my_perror() { fprintf(stderr, " %s\n", sys_err_str()); } void my_pinfo() { fprintf(stdout, " %s\n", sys_err_str()); } /* * Recoverable error. Print a message, and return to caller. * * err_ret(str, arg1, arg2, ...) * * The string "str" must specify the conversion specification for any args. */ /* VARARGS1 */ void err_ret(char *str, ...) { va_list args; va_start(args, str); vfprintf(stdout, str, args); va_end(args); my_pinfo(); fflush(stdout); fflush(stderr); return; } /* * Fatal error. Print a message and terminate. Don't dump core and don't * print the system's errno value. * * err_quit(str, arg1, arg2, ...) * * The string "str" must specify the conversion specification for any args. */ /* VARARGS1 */ void err_quit(char *str, ...) { va_list args; va_start(args, str); vfprintf(stderr, str, args); fputc('\n', stderr); va_end(args); exit(1); } /* * Fatal error related to a system call. Print a message and terminate. * Don't dump core, but do print the system's errno value and its associated * message. * * err_sys(str, arg1, arg2, ...) * * The string "str" must specify the conversion specification for any args. */ /* VARARGS1 */ void err_sys(char *str, ...) { va_list args; va_start(args, str); vfprintf(stderr, str, args); va_end(args); my_perror(); exit(1); } /* * Return a string containing some additional operating-system dependent * information. Note that different versions of UNIX assign different * meanings to the same value of "errno" (compare errno's starting with 35 * between System V and BSD, for example). This means that if an error * condition is being sent to another UNIX system, we must interpret the * errno value on the system that generated the error, and not just send the * decimal value of errno to the other system. */ char * sys_err_str() { static char msgstr[200]; if (errno != 0) { sprintf(msgstr, "(%s)", strerror(errno)); } else { msgstr[0] = '\0'; } return (msgstr); } void test_option_int(const char *label, int optname, int optval) { int mysocket; int result; mysocket = socket(PF_INET, SOCK_DGRAM, AF_UNSPEC); if (mysocket == -1) { err_sys("Cannot create socket: "); } result = setsockopt(mysocket, IPPROTO_IP, optname, &optval, sizeof(int)); if (result != 0) { err_ret("[PROBLEM] Cannot set the %s to %i: ", label, optval); } else { fprintf(stdout, "%s successfully set to %i\n", label, optval); } close(mysocket); } int main(int argc, char **argv) { int myttl = 10; #ifdef IPTOS_THROUGHPUT int mytos = IPTOS_THROUGHPUT; #else int mytos = 0x08; /* Maximize throughput */ #endif #ifdef IPTOS_PREC_CRITIC_ECP int myprecedence = IPTOS_PREC_CRITIC_ECP; #else int myprecedence = 0xa0; /* Raise the precedence to "critic" */ #endif int myecn = 0x02; /* ECN-capable transport */ uid_t myuid; int result; struct utsname system_info; myuid = getuid(); fprintf(stdout, "Testing of the abilities to set bits in the IP header\n"); fprintf(stdout, "My UID is %i\n", myuid); result = uname(&system_info); if (result != 0) { err_sys("Cannot call uname: "); } fprintf(stdout, "The system is %s %s, the machine is %s\n", system_info.sysname, system_info.release, system_info.machine); test_option_int("TTL", IP_TTL, myttl); test_option_int("TOS", IP_TOS, mytos); test_option_int("ECN", IP_TOS, myecn); test_option_int("precedence", IP_TOS, myprecedence); #ifdef IP_MTU_DISCOVER /* To set the DF bit, we hack a little, going through the PMTU options. Not * portable. */ test_option_int("DF set through PMTU", IP_MTU_DISCOVER, IP_PMTUDISC_DO); test_option_int("DF clear through PMTU", IP_MTU_DISCOVER, IP_PMTUDISC_DONT); #else fprintf(stdout, "No known way to set the DF bit on this system\n"); #endif fprintf(stdout, "\nWarning: we only tested that setsockopt was happy,\n\tnot that the actual packet headers were changed\n"); exit(0); } --tKW2IUtsqtDRztdT 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 --tKW2IUtsqtDRztdT-- From behave-bounces@ietf.org Tue Jan 29 17:29:36 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJyxS-0002we-Kv; Tue, 29 Jan 2008 17:29:34 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JJyxR-0002wZ-Ax for behave-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 17:29:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJyxQ-0002wR-W3 for behave@ietf.org; Tue, 29 Jan 2008 17:29:33 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJyxQ-0007Gs-Ho for behave@ietf.org; Tue, 29 Jan 2008 17:29:32 -0500 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:60864 helo=[192.168.0.4]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1JJyxP-0001et-G6; Tue, 29 Jan 2008 22:29:31 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <047FE29C-8341-4E37-8121-5AECFD89FEF5@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [BEHAVE] Getting pairs of ports for RTP using TURN Date: Tue, 29 Jan 2008 22:29:29 +0000 To: Cullen Jennings X-Mailer: Apple Mail (2.753) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Behave WG , Philip Matthews 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 29 Jan 2008, at 03:18, Cullen Jennings wrote: > RTP has an unfortunately design attribute that in some cases it > expects the RTCP to be on the odd port above the RTP and RTP to be > on an even port. We don't have other protocols like this and I > really doubt we would want to design things this way in the future > but none the less, there is a strong desire for TURN to support all > forms of RTP including this. This leads to the need for a TURN > client to be able to request an even port number in it's > allocations and also for a TURN client to be able to request a pair > of ports for use with RTP. While I don't doubt that there are many RTP implementations that still require port pairs, RFC 3605 is over four years old now. The TURN draft should make it clear that the ability to request odd or even port numbers is for backwards compatibility only, and that new RTP implementations need to be more flexible in how they allocate and signal ports (i.e. they SHOULD use RFC 3605 mechanisms to signal the port, and ideally should multiplex RTP and RTCP onto the same port as outlined in draft-ietf-avt-rtp-and-rtcp-mux-07.txt -- with the RFC Editor now). -- Colin Perkins http://csperkins.org/ _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 29 18:24:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJzoe-0003VP-Nv; Tue, 29 Jan 2008 18:24:32 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JJzod-0003VI-4I for behave-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 18:24:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJzoc-0003V9-QJ for behave@ietf.org; Tue, 29 Jan 2008 18:24:30 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-07.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJzob-0001qb-I7 for behave@ietf.org; Tue, 29 Jan 2008 18:24:30 -0500 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JJzoX-0007F1-1x; Tue, 29 Jan 2008 18:24:26 -0500 In-Reply-To: <20080129210631.GA965@sources.org> References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <200801030949.41979.remi.denis-courmont@nokia.com> <914FB0C9-1F63-4EBB-BADE-26F5506619A7@magma.ca> <200801081223.17053.remi.denis-courmont@nokia.com> <20080129210631.GA965@sources.org> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Philip Matthews Subject: Re: [BEHAVE] Re: TURN Issue: Preserving bits in the IP header Date: Tue, 29 Jan 2008 18:24:20 -0500 To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6379955759c38e2371a49573a0932fc7 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="===============0051928914==" Errors-To: behave-bounces@ietf.org --===============0051928914== Content-Type: multipart/alternative; boundary=Apple-Mail-3-3561255 --Apple-Mail-3-3561255 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Thanks for writing this program! I am curious to know exactly which bits are being set by each operation. The old Type of Service field from the IPv4 header was defined as =20 (RFC 791) 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | | | | | | | | PRECEDENCE | D | T | R | 0 | 0 | | | | | | | | +-----+-----+-----+-----+-----+-----+-----+-----+ while the new definition of this field is (RFC 2474): 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | DSCP | ECN | +---+---+---+---+---+---+---+---+ When your program refers to the TOS field, does it mean bits 0-7, or =20 just bits 3-5? - Philip On 29-Jan-08, at 16:06 , Stephane Bortzmeyer wrote: > On Tue, Jan 08, 2008 at 12:23:16PM +0200, > R=E9mi Denis-Courmont wrote > a message of 33 lines which said: > >> As far as I know the Winsock (Windows), Linux and BSD socket API >> implementations, none of them provide per-packet TOS and ECN bit >> specification. > > To ease the current survey of implementations, I wrote the attached > small program, that you can run on your system (tested on many Unix, > VMS - if someone wants to run a TURN server on VMS - and Windows XP), > to see what bits in the IP header an ordinary application can *set* > (wether it can *gets* them is another issue). > > To compile: > > make > > To run: > > make test > > If you are root, I suggest to run it with and without root privileges, > the results may be different (for instance on Linux). > > It may be a good idea to send the results only to me or to the persons > responsible for the tests (see > http://www1.ietf.org/mail-archive/web/behave/current/msg03248.html). > > A big warning: the program only tests that the system accepts the > option, not that it complies. > > Executive summary of the results so far: TTL, ECN and DSCP seem to be > easily settable. precedence and DF are more questionable. > > Some results: > > My UID is 1000 > The system is Linux 2.6.8-4-k7, the machine is i686 > TTL successfully set to 10 > TOS successfully set to 8 > ECN successfully set to 2 > [PROBLEM] Cannot set the precedence to 160: (Operation not permitted) > DF set through PMTU successfully set to 2 > DF clear through PMTU successfully set to 0 > > My UID is 0 > The system is Linux 2.6.8-4-k7, the machine is i686 > TTL successfully set to 10 > TOS successfully set to 8 > ECN successfully set to 2 > precedence successfully set to 160 > DF set through PMTU successfully set to 2 > DF clear through PMTU successfully set to 0 > > My UID is 1055 > The system is OSF1 V5.1, the machine is alpha > TTL successfully set to 10 > TOS successfully set to 8 > ECN successfully set to 2 > precedence successfully set to 160 > No known way to set the DF bit on this system > > My UID is 54131 > The system is FreeBSD 6.2-RELEASE, the machine is i386 > TTL successfully set to 10 > TOS successfully set to 8 > ECN successfully set to 2 > precedence successfully set to 160 > No known way to set the DF bit on this system > > My UID is 1000 > The system is NetBSD 3.1, the machine is sparc64 > TTL successfully set to 10 > TOS successfully set to 8 > ECN successfully set to 2 > precedence successfully set to 160 > No known way to set the DF bit on this system > > My UID is 0 > The system is Darwin 9.1.0, the machine is i386 > TTL successfully set to 10 > TOS successfully set to 8 > ECN successfully set to 2 > precedence successfully set to 160 > No known way to set the DF bit on this system > > My UID is 1005 > The system is CYGWIN_NT-5.1 1.5.24(0.156/4/2), the machine is i686 > TTL successfully set to 10 > TOS successfully set to 8 > ECN successfully set to 2 > precedence successfully set to 160 > No known way to set the DF bit on this system > > My UID is 8491703 > The system is OpenVMS 0, the machine is HP_rx2600__(1.40GHz/1.5MB) > TTL successfully set to 10 > TOS successfully set to 8 > ECN successfully set to 2 > precedence successfully set to 160 > No known way to set the DF bit on this system set.c>_______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave --Apple-Mail-3-3561255 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Thanks for writing this program!

I am curious to know = exactly which bits are being set by each operation.
The old = Type of Service field from the IPv4 header was defined as (RFC = 791)
=A0=A0 =A0 =A0 =A0=A00 =A0 =A0 1 =A0 =A0 = 2 =A0 =A0 3 =A0 =A0 4 =A0 =A0 5 =A0 =A0 6 =A0 =A0 7
=A0 =A0 =A0 = +-----+-----+-----+-----+-----+-----+-----+-----+
=A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = | =A0 =A0 | =A0 =A0 | =A0 =A0 | =A0 =A0 |
=A0 =A0 =A0 | =A0 PRECEDENCE=A0 =A0 |=A0 D=A0 |=A0 T=A0 = |=A0 R=A0 |=A0 0=A0 |=A0 0=A0 |
=A0 =A0 =A0 | = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 | =A0 =A0 | =A0 =A0 | =A0 =A0 = | =A0 =A0 |
=A0 =A0 =A0 = +-----+-----+-----+-----+-----+-----+-----+-----+

while the = new definition of this field is (RFC 2474):
=A0=A0 =A0 =A0 =A00 =A0 1 =A0 2 =A0 3 =A0 4 =A0 5 =A0 6 = =A0 7
=A0 =A0 =A0 = +---+---+---+---+---+---+---+---+
=A0 =A0 =A0 | = =A0 =A0 =A0 =A0 DSCP=A0 =A0 =A0 =A0 =A0 |=A0=A0ECN=A0=A0|
=A0 =A0 =A0 = +---+---+---+---+---+---+---+---+

When = your program refers to the TOS field, does it mean bits 0-7, or just = bits 3-5?

- = Philip


On 29-Jan-08, = at 16:06 , Stephane Bortzmeyer wrote:

On Tue, Jan 08, 2008 at 12:23:16PM +0200,
=A0R=E9mi= Denis-Courmont <remi.denis-courmont@nokia.co= m> wrote=A0
=A0a = message of 33 lines which said:

As far = as I know the Winsock (Windows), Linux and BSD socket API
implementations, none of them provide per-packet TOS = and ECN bit
specification.
=

To ease the current survey of implementations, I = wrote the attached
small program, that you can = run on your system (tested on many Unix,
VMS - if = someone wants to run a TURN server on VMS - and Windows XP),
to see what bits in the IP header an ordinary = application can *set*
(wether it can *gets* them = is another issue).
To compile:


To run:

make test

If you = are root, I suggest to run it with and without root = privileges,
the results may be different = (for instance on Linux).

It may be a good idea to send = the results only to me or to the persons

A big warning: the program only tests that the = system accepts the
option, not that it = complies.=A0

easily settable. precedence and DF are more = questionable.

Some results:

My UID is 1000
The system is Linux 2.6.8-4-k7, the machine is = i686
TTL successfully set to = 10
TOS successfully set to 8
ECN successfully set to 2
[PROBLEM] Cannot set the precedence to 160:=A0 (Operation not = permitted)
DF set through PMTU successfully = set to 2
DF clear through PMTU = successfully set to 0
My UID is 0
The system is Linux 2.6.8-4-k7, the machine is = i686
TTL successfully set to = 10
TOS successfully set to 8
ECN successfully set to 2
precedence successfully set to 160
DF set through PMTU successfully set to 2
DF clear through PMTU successfully set to = 0

My UID is 1055
The system is = OSF1 V5.1, the machine is alpha
TTL = successfully set to 10
TOS successfully set to = 8
ECN successfully set to 2
precedence successfully set to 160
No known way to set the DF bit on this = system

My UID is 54131
The system is = FreeBSD 6.2-RELEASE, the machine is i386
TTL = successfully set to 10
TOS successfully set to = 8
ECN successfully set to 2
precedence successfully set to 160
No known way to set the DF bit on this = system

My UID is 1000
The system is = NetBSD 3.1, the machine is sparc64
TTL = successfully set to 10
TOS successfully set to = 8
ECN successfully set to 2
precedence successfully set to 160
No known way to set the DF bit on this = system

My UID is 0
The system is = Darwin 9.1.0, the machine is i386
TTL = successfully set to 10
TOS successfully set to = 8
ECN successfully set to 2
precedence successfully set to 160
No known way to set the DF bit on this = system

My UID is 1005
The system is = CYGWIN_NT-5.1 1.5.24(0.156/4/2), the machine is i686
TTL successfully set to 10
TOS successfully set to 8
ECN successfully set to 2
precedence successfully set to 160
No known way to set the DF bit on this = system

My UID is 8491703
The = system is OpenVMS 0, the machine is HP_rx2600__(1.40GHz/1.5MB)
TTL successfully set to 10
TOS successfully set to 8
ECN successfully set to 2
precedence successfully set to 160
No known way to set the DF bit on this = system<Makefile><ip-header-set.c>___= ____________________________________________
Behave mailing list
=

= --Apple-Mail-3-3561255-- --===============0051928914== 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 --===============0051928914==-- From behave-bounces@ietf.org Tue Jan 29 18:43:52 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK07K-0000B0-7G; Tue, 29 Jan 2008 18:43:50 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JK07I-00007c-Sg for behave-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 18:43:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK07I-00006W-Fp for behave@ietf.org; Tue, 29 Jan 2008 18:43:48 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JK07H-0000kG-QB for behave@ietf.org; Tue, 29 Jan 2008 18:43:48 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 29 Jan 2008 15:43:47 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m0TNhkOd001656; Tue, 29 Jan 2008 15:43:47 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id m0TNhkAl007273; Tue, 29 Jan 2008 23:43:46 GMT From: Cullen Jennings To: Philip Matthews In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org Subject: Re: [BEHAVE] Getting pairs of ports for RTP using TURN References: Message-Id: <62C99CAD-6959-4B48-B4B2-8E3666DA6CDF@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Tue, 29 Jan 2008 15:43:26 -0800 X-Mailer: Apple Mail (2.915) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4013; t=1201650227; x=1202514227; c=relaxed/simple; s=sjdkim4002; 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]=20Getting=20pairs=20of=20ports =20for=20RTP=20using=20TURN |Sender:=20; bh=jE2B8m0uoGSHgadTtSfc8HF4zZoxb9VW4V5AF7Q4Kug=; b=ZO3yDYAJ0BLlsRxQxU6vljijgtWhOzmATW6Qv3yUWC2jrIillnmPRelk82 IgeZAwrYbvsRtOYhUDREKRwzBF7dmdlrVWnCfbTAZv4vXgwHuT/t3eM6n8wS FE9GbZjMx3; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 Sure. I choose 32 bits fairly arbitrarily and see no problems with using 64 bits. It's not a way I had imagined using it but I agree, If we want to use it tis way in some cases, then I agree 32 bits would be too small. On Jan 29, 2008, at 6:27 AM, Philip Matthews wrote: > I like this proposal. I think it gives us what we need without adding > extra complexity. > > I have one small suggested change. I suggest that the ODD-PORT-PAIR- > TOKEN be a random number and perhaps be 64 bits rather than 32. This > is because I feel it is likely that some organizations will pass out > the same credentials (i.e., username and password) to a large number > of devices. > > - Philip > > On 28-Jan-08, at 22:18 , Cullen Jennings wrote: > > > > > RTP has an unfortunately design attribute that in some cases it > > expects the RTCP to be on the odd port above the RTP and RTP to be > > on an even port. We don't have other protocols like this and I > > really doubt we would want to design things this way in the future > > but none the less, there is a strong desire for TURN to support all > > forms of RTP including this. This leads to the need for a TURN > > client to be able to request an even port number in it's > > allocations and also for a TURN client to be able to request a pair > > of ports for use with RTP. > > > > Another key design principal of TURN has been to maximize the odds > > the firewall administrators allowing it thought he firewall by not > > subverting the will of the firewall admins which will simply result > > in it being blocked. One of the aspects of this has been to not > > allow TURN to be used to run general purpose servers without the > > consent of the firewall admin. > > > > The 06 draft is a bit broken with respect to all this but I have a > > proposal that I think would be very easy to implement, would > > simultaneously meet all these concerns, and is pretty easy to > > understand. > > > > My suggestion is that we remove the REQUEST-PORTS-PROPS and REQUEST- > > IP and add add two new attributes. REQUEST-EVEN-PORT and REQUEST- > > PORT-PAIR. Neither of these have any data and the presence of them > > is simply treated as a flag by the TURN server. Only one of them > > should be in a request. The REQUEST-EVEN-PORT causes the server to > > only allocate an even port. The REQUEST-PORT-PAIR causes the server > > to allocate a consecutive even port and the odd port that is one > > greater. The response returns the even port that was allocated > > along with ODD-PORT-PAIR-TOKEN attribute that caries a 32 bit > > identifier. When the client receives this token, it can perform > > another allocate that includes the ODD-PORT-PAIR-TOKEN. The server > > will recognize that the same user is requesting an allocation with > > the TOKEN that pairs it with the previous allocation and the TURN > > server will return the odd port that was allocated with the > > previous even port. > > > > The TURN server needs to ensure that it reserves the port pair for > > at least 30 seconds after the initial allocation and that it only > > allocates the port to a ALLOC request that was made by the same > > user as the initial allocation and where the request has the token > > that was returned in the original ALLOC. The token does not need to > > have any security properties - anyone can see it - the server can > > use an incrementing counter if it wishes. The security comes from > > only giving out the port to a user with the same credentials as the > > client that made the initial request. The token is purely used as a > > way of helping a client that is performing multiple allocations > > associated the correct pairs of allocations together. > > > > > > Cullen > > > > > > > > > > _______________________________________________ > > 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 Jan 29 18:43:55 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK07P-0000Wj-Dt; Tue, 29 Jan 2008 18:43:55 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JK07O-0000SF-I1 for behave-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 18:43:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK07O-0000QN-5K for behave@ietf.org; Tue, 29 Jan 2008 18:43:54 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JK07N-0000kY-DW for behave@ietf.org; Tue, 29 Jan 2008 18:43:54 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 29 Jan 2008 15:43:52 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m0TNhq7w001765; Tue, 29 Jan 2008 15:43:52 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id m0TNhkAm007273; Tue, 29 Jan 2008 23:43:52 GMT From: Cullen Jennings To: Colin Perkins In-Reply-To: <047FE29C-8341-4E37-8121-5AECFD89FEF5@csperkins.org> Impp: xmpp:cullenfluffyjennings@jabber.org Subject: Re: [BEHAVE] Getting pairs of ports for RTP using TURN References: <047FE29C-8341-4E37-8121-5AECFD89FEF5@csperkins.org> Message-Id: <9E159458-231F-4385-8E93-243AE7B7BEDC@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Tue, 29 Jan 2008 15:43:42 -0800 X-Mailer: Apple Mail (2.915) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1370; t=1201650232; x=1202514232; c=relaxed/simple; s=sjdkim4002; 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]=20Getting=20pairs=20of=20ports =20for=20RTP=20using=20TURN |Sender:=20; bh=o352W3mlPx6p8l4lcsWrIOZdeFmC+T+jjeoTY09t9Bg=; b=rGxvZ2Bk/N8z5uKu2Yl+N6w0wTTL1AQEUEXTbZLda5efONZy2vs2f+o174 daA7tXBPRI5Uc2iOKh7JtnhHb+0jTbGBUJpFE9nSypLC3FNYLy0p2bLSDxPd 8v1QCkIuM7; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Jan 29, 2008, at 2:29 PM, Colin Perkins wrote: > On 29 Jan 2008, at 03:18, Cullen Jennings wrote: >> RTP has an unfortunately design attribute that in some cases it >> expects the RTCP to be on the odd port above the RTP and RTP to be >> on an even port. We don't have other protocols like this and I >> really doubt we would want to design things this way in the future >> but none the less, there is a strong desire for TURN to support all >> forms of RTP including this. This leads to the need for a TURN >> client to be able to request an even port number in it's >> allocations and also for a TURN client to be able to request a pair >> of ports for use with RTP. > > While I don't doubt that there are many RTP implementations that > still require port pairs, RFC 3605 is over four years old now. The > TURN draft should make it clear that the ability to request odd or > even port numbers is for backwards compatibility only, and that new > RTP implementations need to be more flexible in how they allocate > and signal ports (i.e. they SHOULD use RFC 3605 mechanisms to signal > the port, and ideally should multiplex RTP and RTCP onto the same > port as outlined in draft-ietf-avt-rtp-and-rtcp-mux-07.txt -- with > the RFC Editor now). I completely agree - I should have been clearer about that. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 29 18:57:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK0KE-0006CH-7A; Tue, 29 Jan 2008 18:57:10 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JK0KC-00069u-SZ for behave-confirm+ok@megatron.ietf.org; Tue, 29 Jan 2008 18:57:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK0KC-000694-GO for behave@ietf.org; Tue, 29 Jan 2008 18:57:08 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JK0KB-0001Lz-Kx for behave@ietf.org; Tue, 29 Jan 2008 18:57:08 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 29 Jan 2008 15:57:06 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m0TNv6Kx015372; Tue, 29 Jan 2008 15:57:06 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id m0TNv6J5008101; Tue, 29 Jan 2008 23:57:06 GMT From: Cullen Jennings To: Marc Petit-Huguenin In-Reply-To: <479F4848.2000204@acm.org> Impp: xmpp:cullenfluffyjennings@jabber.org Subject: Re: [BEHAVE] Getting pairs of ports for RTP using TURN References: <479F4848.2000204@acm.org> Message-Id: <2D990ADF-1F11-4EB3-BFDD-F21EEEE696C4@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Tue, 29 Jan 2008 15:56:46 -0800 X-Mailer: Apple Mail (2.915) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5267; t=1201651026; x=1202515026; 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]=20Getting=20pairs=20of=20ports =20for=20RTP=20using=20TURN |Sender:=20; bh=tPm3af36UfMoXAUj8b96Tnf5bIZAgHFX1MBJ6TIZLeY=; b=kNuCqe5Uw+NkKYXg0MfApxB0jHwKNfPsp+Lea3ERP1VU6g/huJVFHa1r9R v0wxYVtPHr8UIcmUrbJAg4OdIYAsWhQyXYLOzZvv6zZXIXXCuI18WrpOA2dp RgZIqToOGw; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: Behave WG , Philip Matthews 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 Good questions - inline ... On Jan 29, 2008, at 7:37 AM, Marc Petit-Huguenin wrote: > Cullen Jennings wrote: > > > > RTP has an unfortunately design attribute that in some cases it > expects > > the RTCP to be on the odd port above the RTP and RTP to be on an > even > > port. We don't have other protocols like this and I really doubt we > > would want to design things this way in the future but none the > less, > > there is a strong desire for TURN to support all forms of RTP > including > > this. This leads to the need for a TURN client to be able to > request an > > even port number in it's allocations and also for a TURN client to > be > > able to request a pair of ports for use with RTP. > > > > Another key design principal of TURN has been to maximize the odds > the > > firewall administrators allowing it thought he firewall by not > > subverting the will of the firewall admins which will simply > result in > > it being blocked. One of the aspects of this has been to not allow > TURN > > to be used to run general purpose servers without the consent of the > > firewall admin. > > > > The 06 draft is a bit broken with respect to all this but I have a > > proposal that I think would be very easy to implement, would > > simultaneously meet all these concerns, and is pretty easy to > understand. > > > > My suggestion is that we remove the REQUEST-PORTS-PROPS and > REQUEST-IP > > and add add two new attributes. REQUEST-EVEN-PORT and REQUEST-PORT- > PAIR. > > Neither of these have any data and the presence of them is simply > > treated as a flag by the TURN server. Only one of them should be > in a > > request. The REQUEST-EVEN-PORT causes the server to only allocate an > > even port. The REQUEST-PORT-PAIR causes the server to allocate a > > consecutive even port and the odd port that is one greater. The > response > > returns the even port that was allocated along with ODD-PORT-PAIR- > TOKEN > > attribute that caries a 32 bit identifier. When the client > receives this > > token, it can perform another allocate that includes the > > ODD-PORT-PAIR-TOKEN. The server will recognize that the same user is > > requesting an allocation with the TOKEN that pairs it with the > previous > > allocation and the TURN server will return the odd port that was > > allocated with the previous even port. > > I am not sure to understand how that it is better than the current > text, > assuming that REQUESTED-IP and REQUEST-PORTS-PROPS with specific port > can only refer to an IP address/port allocated previously by the same > user on the same tuple as the second port of a pair. > > Also the REQUESTED-IP attribute alone permitted to request a port on a > specific IP address on a TURN server that have multiple interfaces. I > do not know if there is SIP endpoints that are broken in presence of > SDP > with different IP addresses for different m= lines, but the > REQUESTED-IP > would help to fix this. > My experience has been that UA that support audio and video have a pretty high degree of being ok with different IP address in the m lines for these. This is because some of the common conferencing mixers to have different IPs for the audio mixer and video mixer so if you want to work with these audio/video conferencing systems you UA needs to support that. That said, if folks feel there is a need to be able to say "please put this allocation on the same IP as a previous allocation", I'm fine to work out a way to do that. Thoughts on if we have real example where we need that or not? > > > > > > The TURN server needs to ensure that it reserves the port pair for > at > > least 30 seconds after the initial allocation and that it only > allocates > > the port to a ALLOC request that was made by the same user as the > > initial allocation and where the request has the token that was > returned > > in the original ALLOC. > > The problem of the 30 seconds is that an additional timer is needed in > the implementation. Why do not just reserve the port for the duration > of the allocation? > I should have been clearer here. I choose the "at least 30 seconds" way or wording this so that an implementation could choose to just have it valid for the length of the original allocation if it wished to implement it that way. I would like to have something that is implementable without adding more timers because timers seem to always be a hassle. I can also imagine an implementation could be done by just having a time-stamp with the allocation record, and when the 2nd allocate came along, the code could check if the current time was within 30 seconds of original time stamp. At the same time the reserved ports that had not been allocated yet could be kept in a list and when trying to find a new port, the oldest entry on the list could be reused as long as it was older than 30 seconds. This would allow the ports to be "freed" if they were not going to be used after 30 seconds and they were needed for other allocations and still not require a timer. Cullen > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 30 02:38:09 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK7WH-00077j-T0; Wed, 30 Jan 2008 02:38:05 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JK7WG-00077e-QO for behave-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 02:38:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK7WG-00077W-ED for behave@ietf.org; Wed, 30 Jan 2008 02:38:04 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JK7WE-0001Yk-KD for behave@ietf.org; Wed, 30 Jan 2008 02:38:04 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0U7bf9u004994; Wed, 30 Jan 2008 09:37:59 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 09:37:57 +0200 Received: from esdhcp04163.research.nokia.com ([172.21.41.63]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 09:37:57 +0200 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] Linux socket settings Date: Wed, 30 Jan 2008 09:38:21 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <262EBFFA-D31D-40BC-93A5-7E91A42092F6@magma.ca> <953beacc0801281304u635a0f91g1d758e335a1cc0c5@mail.gmail.com> <200801291003.32195.remi.denis-courmont@nokia.com> In-Reply-To: <200801291003.32195.remi.denis-courmont@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200801300938.22119.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 30 Jan 2008 07:37:57.0373 (UTC) FILETIME=[083BE2D0:01C86313] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Philip Matthews 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 29 January 2008 10:03:32 ext R=C3=A9mi Denis-Courmont, vous avez= =C3=A9crit=C2=A0: > As for DSCP resp. TTL, they can be set on a per-socket basis (IP_TOS resp. > IP_TTL setsockopt). ECN bits cannot be set manually. > With UDP *only*, TTL resp. DSCP bits of incoming packets can be received > (IP_RECVTTL resp. IP_RECVTOS setsockopt); this obviously does NOT work for > TCP. Woops. ECN bits can be set manually, for UDP, just as DSCP, i.e. you can se= t=20 all of the 8 TOS bits. However, values of 0xA0 and above (historically=20 critical precedence and higher), are reserved for root. ECN bits can however NOT be set for TCP - any attempt to set them will be=20 ignored. Only the higher 6 order bits of TOS can be set in this case, subje= ct=20 to the same restriction as above. =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 Wed Jan 30 05:02:20 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK9lq-0001rG-LY; Wed, 30 Jan 2008 05:02:18 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JK9lp-0001rA-5i for behave-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 05:02:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK9lo-0001r2-SF for behave@ietf.org; Wed, 30 Jan 2008 05:02:16 -0500 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JK9lo-0004M8-Bi for behave@ietf.org; Wed, 30 Jan 2008 05:02:16 -0500 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 8ED0824083C; Wed, 30 Jan 2008 11:02:12 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id 8B35C119D8; Wed, 30 Jan 2008 11:00:29 +0100 (CET) Date: Wed, 30 Jan 2008 11:00:29 +0100 From: Stephane Bortzmeyer To: Philip Matthews Message-ID: <20080130100029.GA11872@sources.org> References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <200801030949.41979.remi.denis-courmont@nokia.com> <914FB0C9-1F63-4EBB-BADE-26F5506619A7@magma.ca> <200801081223.17053.remi.denis-courmont@nokia.com> <20080129210631.GA965@sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Behave WG Subject: [BEHAVE] Re: TURN Issue: Preserving bits in the IP header 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 Tue, Jan 29, 2008 at 06:24:20PM -0500, Philip Matthews wrote a message of 421 lines which said: > The old Type of Service field from the IPv4 header was defined as > (RFC 791) > 0 1 2 3 4 5 6 7 > +-----+-----+-----+-----+-----+-----+-----+-----+ > | | | | | | | > | PRECEDENCE | D | T | R | 0 | 0 | > | | | | | | | > +-----+-----+-----+-----+-----+-----+-----+-----+ > > while the new definition of this field is (RFC 2474): > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | DSCP | ECN | > +---+---+---+---+---+---+---+---+ Actually, RFC 2474 + RFC 3168 (RFC 2474 did not mention ECN and reserved the last two bits). Strangely, neither RFC 2474 nor 3168 claims they update RFC 791. I admit that my vocabulary was sloppy. This is partially because Posix did not change the name of the constants after RFC 2474. The argument of setsockopt() is still named IP_TOS. DSCP does not seem mentioned anywhere. On my very recent Linux machine, the comments in the header file are still RFC 791: #define IP_TOS 1 /* int; IP type of service and precedence. */ I hesitate to update the program: should I use RFC 2474 vocabulary or Posix one? > When your program refers to the TOS field, does it mean bits 0-7, or > just bits 3-5? The IP_TOS option apparently allows you to change the entire byte, so bits 0-7. Therefore, 0x08 (maximize throughput) means bit 4 set and all other bits clear (including ECN bits). If someone wants ECN *and* maximize throughput, he or she should set the field to 0x0A. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 30 13:42:45 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKHtU-0000SG-FO; Wed, 30 Jan 2008 13:42:44 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JKHtT-0000RB-CY for behave-confirm+ok@megatron.ietf.org; Wed, 30 Jan 2008 13:42:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKHtT-0000R3-2f for behave@ietf.org; Wed, 30 Jan 2008 13:42:43 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKHtR-0006Sq-RL for behave@ietf.org; Wed, 30 Jan 2008 13:42:43 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1JKHtR-0002QS-0x for behave@ietf.org; Wed, 30 Jan 2008 13:42:41 -0500 Mime-Version: 1.0 (Apple Message framework v753) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Behave WG From: Philip Matthews Date: Wed, 30 Jan 2008 13:42:40 -0500 X-Mailer: Apple Mail (2.753) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [BEHAVE] Next TURN call 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 scheduled another call to talk about the open issues in the TURN specification. The call will be a two-hour call on Thursday, 7 Feb 2008 at the following time: 8 - 10 Pacific / 11 - 13 Eastern / 18 - 20 Finland The call is open to anyone who wishes to participate. If you are interested, please reply to me and I will send you the information you need to join. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jan 31 13:50:12 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKeUD-0003LA-2A; Thu, 31 Jan 2008 13:50:09 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JKeUA-0003Fw-0Z for behave-confirm+ok@megatron.ietf.org; Thu, 31 Jan 2008 13:50:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKeU9-0003Fk-MS; Thu, 31 Jan 2008 13:50:05 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKeU6-0004lY-3Z; Thu, 31 Jan 2008 13:50:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 0D7883289D; Thu, 31 Jan 2008 18:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JKeU5-00073I-Ug; Thu, 31 Jan 2008 13:50:01 -0500 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, 31 Jan 2008 13:50:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-turn-ipv6-04.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 : Traversal Using Relays around NAT (TURN) Extension for IPv4/IPv6 Transition Author(s) : G. Camarillo, O. Novo Filename : draft-ietf-behave-turn-ipv6-04.txt Pages : 8 Date : 2008-01-31 This document defines the REQUESTED-ADDRESS-TYPE attribute for the Traversal Using Relays around NAT (TURN), which allows a client to explicitly request the address type the TURN server will allocate (e.g., an IPv4-only node may request the TURN server to allocate an IPv6 address). Additionally, this document also defines a new error response code with the value 440 (Address Family not Supported). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-ipv6-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-turn-ipv6-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-behave-turn-ipv6-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-01-31134353.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-turn-ipv6-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-turn-ipv6-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-31134353.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 Thu Jan 31 22:10:06 2008 Return-Path: X-Original-To: ietfarch-behave-archive@core3.amsl.com Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25D2C3A67EE; Thu, 31 Jan 2008 22:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZdwNeTvKRlo; Thu, 31 Jan 2008 22:10:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B7363A67FB; Thu, 31 Jan 2008 22:10:05 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F7D53A67FB for ; Thu, 31 Jan 2008 22:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhwZenVWlyeb for ; Thu, 31 Jan 2008 22:10:03 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id BDA2F3A67EE for ; Thu, 31 Jan 2008 22:10:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,288,1199692800"; d="scan'208";a="10918612" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 31 Jan 2008 22:11:36 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m116Ba8F029901; Thu, 31 Jan 2008 22:11:36 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id m116BYQE007951; Fri, 1 Feb 2008 06:11:36 GMT From: Cullen Jennings To: Stephane Bortzmeyer In-Reply-To: <20080129210631.GA965@sources.org> Impp: xmpp:cullenfluffyjennings@jabber.org References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <200801030949.41979.remi.denis-courmont@nokia.com> <914FB0C9-1F63-4EBB-BADE-26F5506619A7@magma.ca> <200801081223.17053.remi.denis-courmont@nokia.com> <20080129210631.GA965@sources.org> Message-Id: <4F41EBF1-3F49-4626-8912-70D8B9351DF0@cisco.com> Mime-Version: 1.0 (Apple Message framework v915) Date: Thu, 31 Jan 2008 22:10:56 -0800 X-Mailer: Apple Mail (2.915) Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Behave WG Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org that is very cool - thank you for writing that. Any thoughts on being = able to read any of these bits? On Jan 29, 2008, at 1:06 PM, Stephane Bortzmeyer wrote: > On Tue, Jan 08, 2008 at 12:23:16PM +0200, > R=E9mi Denis-Courmont wrote > a message of 33 lines which said: > >> As far as I know the Winsock (Windows), Linux and BSD socket API >> implementations, none of them provide per-packet TOS and ECN bit >> specification. > > To ease the current survey of implementations, I wrote the attached > small program, that you can run on your system (tested on many Unix, > VMS - if someone wants to run a TURN server on VMS - and Windows XP), > to see what bits in the IP header an ordinary application can *set* > (wether it can *gets* them is another issue). > > To compile: > > make > > To run: > > make test > > If you are root, I suggest to run it with and without root privileges, > the results may be different (for instance on Linux). > > It may be a good idea to send the results only to me or to the persons > responsible for the tests (see > http://www1.ietf.org/mail-archive/web/behave/current/msg03248.html). > > A big warning: the program only tests that the system accepts the > option, not that it complies. > > Executive summary of the results so far: TTL, ECN and DSCP seem to be > easily settable. precedence and DF are more questionable. > > Some results: > > My UID is 1000 > The system is Linux 2.6.8-4-k7, the machine is i686 > TTL successfully set to 10 > TOS successfully set to 8 > ECN successfully set to 2 > [PROBLEM] Cannot set the precedence to 160: (Operation not permitted) > DF set through PMTU successfully set to 2 > DF clear through PMTU successfully set to 0 > > My UID is 0 > The system is Linux 2.6.8-4-k7, the machine is i686 > TTL successfully set to 10 > TOS successfully set to 8 > ECN successfully set to 2 > precedence successfully set to 160 > DF set through PMTU successfully set to 2 > DF clear through PMTU successfully set to 0 > > My UID is 1055 > The system is OSF1 V5.1, the machine is alpha > TTL successfully set to 10 > TOS successfully set to 8 > ECN successfully set to 2 > precedence successfully set to 160 > No known way to set the DF bit on this system > > My UID is 54131 > The system is FreeBSD 6.2-RELEASE, the machine is i386 > TTL successfully set to 10 > TOS successfully set to 8 > ECN successfully set to 2 > precedence successfully set to 160 > No known way to set the DF bit on this system > > My UID is 1000 > The system is NetBSD 3.1, the machine is sparc64 > TTL successfully set to 10 > TOS successfully set to 8 > ECN successfully set to 2 > precedence successfully set to 160 > No known way to set the DF bit on this system > > My UID is 0 > The system is Darwin 9.1.0, the machine is i386 > TTL successfully set to 10 > TOS successfully set to 8 > ECN successfully set to 2 > precedence successfully set to 160 > No known way to set the DF bit on this system > > My UID is 1005 > The system is CYGWIN_NT-5.1 1.5.24(0.156/4/2), the machine is i686 > TTL successfully set to 10 > TOS successfully set to 8 > ECN successfully set to 2 > precedence successfully set to 160 > No known way to set the DF bit on this system > > My UID is 8491703 > The system is OpenVMS 0, the machine is HP_rx2600__(1.40GHz/1.5MB) > TTL successfully set to 10 > TOS successfully set to 8 > ECN successfully set to 2 > precedence successfully set to 160 > No known way to set the DF bit on this system > set.c>_______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org http://www.ietf.org/mailman/listinfo/behave