From behave-bounces@ietf.org Fri Dec 01 08:37:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq8a2-0008KK-VF; Fri, 01 Dec 2006 08:37:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq8a2-0008Ia-Co for behave@ietf.org; Fri, 01 Dec 2006 08:37:30 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq8Zz-0000aI-IT for behave@ietf.org; Fri, 01 Dec 2006 08:37:30 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 53FDB194521 for ; Fri, 1 Dec 2006 14:37:16 +0100 (CET) Received: from [192.168.1.41] ([192.168.1.41]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 14:37:07 +0100 Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1cf82f96270263b25c2d09e8d64ba9e4@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Date: Fri, 1 Dec 2006 14:36:47 +0100 To: behave@ietf.org X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 01 Dec 2006 13:37:07.0635 (UTC) FILETIME=[CBA12830:01C7154D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: Subject: [BEHAVE] Comments and nits on rfc3489bis-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Apologies if there comments or nits already addressed. General -------- - Should TLS over TCP be TCP over TLS (there is also TLS-over-TCP)? Section 2 ---------- - ALGs have serious limitations. The security drawback is not mentioned. It might be worthwhile mentioning that integrity and confidentiality is compromised because any signed or encrypted parts of the application protocol message would cause failure Section 4 --------- - Add definition for STUN Indication - Add definition for short term credentials Section 5 ----------- - para 3: I think more text is needed explaining the purpose of the Indication transaction. Text needs to talk about why Indication transaction is defined in this document when there are no Indications defined. - para 12 and 15 (2nd last para) talk about repeats info about some stun usages require stun messages to be sent on the same transport address as the application protocol. That fine, but its kind of confusing since para 15 sounds like its talking about something new. Perhaps para 15 should say "... as mentioned above..." Section 6 --------- - "Indication messages can be sent over TCP or UDP" Why not TCP over TLS? - Fig 3: there are two M 2s :) - There are 2 bits for class. This makes the limitation of 4 classes. Are we ok with that? Will there ever be more than 4 classes? I think there might be. - s/ 1.As / 1. As (space missing) - "For request/response transactions, the transaction ID is chosen by the STUN client and MUST be unique for each new STUN transaction generated by that STUN client... ... As with requests, the value is chosen by the server and MUST be unique for each new STUN transaction generated by the server". There is a discrepancy here in who generates the transaction ID. Also, transaction IDs can be created by servers, if the server initiates it. Section 7.1 ------------ - Expand RTO - 100ms for initial RTO sounds a little high. Thats 5 pending STUN requests. maybe 80ms? or just explain why that number was chosen. - Karn's algorithm needs a reference - RTO cache of 10 mins requires explanation. Seems too short for me. My gut feeling tells me 1 hour is good enough. - fatal ICMP errors to TCP are not mentioned Section 8.3.1 ------------- - This section talks only about formulating the request message in the request/response transaction, but in point 2 of the text, STUN indications are mentioned. This reference to STUN indication should be removed and text should be repeated in the appropriate section for Indications. - " For TCP and TLS over TCP, the client MAY send multiple requests on the connection. When using TCP or TLS over TCP, the client SHOULD close the connection as soon as it has received the STUN Response, if it has no plans to send further requests. " should that last word here be "STUN requests or application protocol messages"? The client might want keep the connection open to send application protocol messages. Same for indications. Section 8.3.2 ------------- - There are a lot of "the request SHOULD NOT be retried" or "the client SHOULD NOT retry the request". Ok, but what should the client do in those cases? try the next SRV record? or what? - "However, the if the retries are repeatedly rejected with 436". How many rejected are considered a repeated rejections so the client can cease retrying? - "For error responses which can" -> "For error response that can" - "Furthermore, the client SHOULD cache the nonce, and continue using it in subsequent requests sent to the same server, identified by transport address. " Should you add that the client SHOULD cache the nonce if the authentication was successful. - The above quoted text is repeated in the last paragraph of this section Section 8.4 ----------- - section 8 is for client behaviour, but 8.4 talks about Indication transactions that apply for both client and server behaviour. Perhaps this section needs to be referenced from section 9.2. - The section does not talk about what a client does if it receives an Indication transaction. Should it ever receive those kinds of transactions? If no, then this should be mentioned earlier in the draft, but still explain how the client should behave. Section 9.1.1 ------------- - The server should remember responses it sent for 10 seconds, but the client is only waiting for 7.9 seconds. What's the logic here? Section 9.1.2 ------------- - "If the response is a type which can carry either MAPPED-ADDRESS or XOR-MAPPED-ADDRESS (the Binding Response as defined in this specification meets that criteria), the server examines the magic cookie in the STUN header. " what header? I assume the STUN request header. Right? Section 9.2 ----------- - Section does not mention sending indications by the server. Can it reference section 8.4? (at least section 4 days servers can send indications). - Text as to why a server would send indications would be good. Section 11.6 ------------ - what are those 0's there for? Section 11.7 ------------- - Why including the quotes? Section 11.9 ------------ - Why repeat an attribute for odd number of attributes instead of putting 0's or some sort of padding? Section 11.12 -------------- - Does encoding same way as MAPPED-ADDRESS mean that ALTERNATE-ADDRESS has a family, port and IP address? what if it was a FQDN? Section 12.1.1 -------------- - s/ an an / an (an repeated) Section 12.1.7 --------------- - "... is then using in..." -> "... is then used in..." - last para: might be a stupid question, but how does the client know if the response contains XORed address or not? Section 12.2.3 --------------- - "it is has" -> "it has"? Section 12.2.8 -------------- - how does the server know if it is getting a Binding request or a keepalive request? The text indicates that the latter does not need message integrity. Section 12.2.9 -------------- - Isn't there a DoS vulnerability. For SIP, the IP address and port in the stun response might end up in the contact of a REGISTER. Section 12.3.1 --------------- - 9 mins. Should it say at least 9 mins but no longer than 30? Section 12.3.4 ------------- - all other figures have a caption and number, except the figure in this section Section 12.3.7 ------------- - No mention of how long credentials are valid for. Server can have them valid for 9 to 30 mins. How would the client know that? Thanks, Hisham _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 01 12:59:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqCfR-0003Xr-LK; Fri, 01 Dec 2006 12:59:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqCfQ-0003Xl-I0 for behave@ietf.org; Fri, 01 Dec 2006 12:59:20 -0500 Received: from lambda.sipfoundry.org ([72.232.205.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqCfN-0007Wi-VJ for behave@ietf.org; Fri, 01 Dec 2006 12:59:20 -0500 Received: from smtp3.freeserve.com (smtp3.wanadoo.co.uk [193.252.22.156]) by lambda.sipfoundry.org (8.13.8/8.13.8) with ESMTP id kB1HxAVa053830 for ; Fri, 1 Dec 2006 11:59:15 -0600 (CST) (envelope-from pete.cordell@tech-know-ware.com) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3208.me.freeserve.com (SMTP Server) with ESMTP id 82C97740008A; Fri, 1 Dec 2006 18:59:04 +0100 (CET) Received: from Codalogic (user-5445210e.lns4-c11.dsl.pol.co.uk [84.69.33.14]) by mwinf3208.me.freeserve.com (SMTP Server) with ESMTP id 151FC740008C; Fri, 1 Dec 2006 18:59:04 +0100 (CET) X-ME-UUID: 20061201175904867.151FC740008C@mwinf3208.me.freeserve.com Message-ID: <003101c71572$652a8950$1c00a8c0@Codalogic> From: "Pete Cordell" To: "Philip Matthews" , "Francois Audet" References: <1ECE0EB50388174790F9694F77522CCF0E37A1C5@zrc2hxm0.corp.nortel.com> Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT Date: Fri, 1 Dec 2006 17:59:03 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.9 (+) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: ietf-behave@list.sipfoundry.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I'm happy with this, although technically the acronym would be STUNT, which may not project the right image. A compromise of all the suggestions so far could be: Set of Tools for Uncorking NATs My only reservation with that is it makes NATs sound like fine wine which doesn't seem right! On the other hand, Set of Tools for Unblocking NATs makes NATs sound more like drains, which may be more appropriate! Maybe if we want to toss around a few more ideas we can do it off-list, and come back when we've got a candidate. Pete. ----- Original Message ----- From: "Philip Matthews" To: "Francois Audet" Cc: "Spencer Dawkins" ; "Pete Cordell" ; Sent: Friday, December 01, 2006 2:32 AM Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT > Perhaps even more accurate would be > "Set of Tools and Usages for NAT traversal". > > - Philip > > > On 30-Nov-06, at 17:47 , Francois Audet wrote: > >> Yes agreed. >> >> In fact, the worst names we come up with is when we try to match an >> acronym. >> For example, "Behavior Engineering for Hindrance Avoidance"... >> >>> -----Original Message----- >>> From: Philip Matthews [mailto:philip_matthews@magma.ca] >>> Sent: Thursday, November 30, 2006 14:37 >>> To: Spencer Dawkins; Audet, Francois (SC100:3055); Pete Cordell >>> Cc: ietf-behave@list.sipfoundry.org >>> Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT >>> >>> I also agree with Francois and Spencer. >>> Though I will suggest that >>> "Set of Tools Useful for NAT traversal (STUN)" would be more accurate. >>> >>> And there is a history of not always having the acronym >>> correspond directly to the first letter of each work. >>> Consider, for example, RSVP (Resource Reservation Protocol). >>> I am sure folks can come up with other examples. >>> >>> - Philip >>> >>> >>> On 30-Nov-06, at 14:15 , Spencer Dawkins wrote: >>> >>>> Agree with Francois here. This would be a lot less confusing than >>>> having two specs come out for NAT traversal at the same time... >>>> >>>> Spencer >>>> >>>> ----- Original Message ----- From: "Francois Audet" >>> >>>> To: >>>> Sent: Thursday, November 30, 2006 12:58 PM >>>> Subject: RE: [BEHAVE] STUN -> Session Traversal Underneath NAT >>>> >>>> >>>> When you think about it, it's not even for NAT traversal >>> anymore (that >>>> would be ICE). >>>> >>>> It's more a set of generic tools for NAT support. >>>> >>>> STUN: Set of Tools Useful for NAT >>>> ^ ^ ^ ^ >>>> >>>> Cheers. >>>> -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx (or http://www.xml2cpp.com) ============================================= > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 01 17:02:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqGRS-0005MI-Oy; Fri, 01 Dec 2006 17:01:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqGRR-0005M9-E9 for behave@ietf.org; Fri, 01 Dec 2006 17:01:09 -0500 Received: from lambda.sipfoundry.org ([72.232.205.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqGRM-0000Gr-Gh for behave@ietf.org; Fri, 01 Dec 2006 17:01:09 -0500 Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by lambda.sipfoundry.org (8.13.8/8.13.8) with ESMTP id kB1M10v8064878 for ; Fri, 1 Dec 2006 16:01:04 -0600 (CST) (envelope-from jdrosen@cisco.com) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 01 Dec 2006 14:00:54 -0800 X-IronPort-AV: i="4.09,486,1157353200"; d="scan'208"; a="89554200:sNHT50176215" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kB1M0s3a011460; Fri, 1 Dec 2006 14:00:54 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB1M0sio013106; Fri, 1 Dec 2006 14:00:54 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 14:00:54 -0800 Received: from [10.32.241.153] ([10.32.241.153]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 14:00:53 -0800 Message-ID: <4570A614.4080302@cisco.com> Date: Fri, 01 Dec 2006 17:00:52 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete Cordell Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT References: <1ECE0EB50388174790F9694F77522CCF0E37A1C5@zrc2hxm0.corp.nortel.com> <003101c71572$652a8950$1c00a8c0@Codalogic> In-Reply-To: <003101c71572$652a8950$1c00a8c0@Codalogic> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2006 22:00:53.0752 (UTC) FILETIME=[2BCC9780:01C71594] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3997; t=1165010454; x=1165874454; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20STUN=20->=20Session=20Traversal=20Undernea th=20NAT |Sender:=20; bh=yG+qTua5ApTRw4SiqOFqn0cAXUZXDniKO2yeD3MAKvQ=; b=eq21mY6b8wEsaJ1um2IBphusfovVLh5N4MGBCo1Rk7gjo1h91HzE/x2ke9MvpwxqMQ3qEq7o njgT6gl5+c9DKvZsYQCeaA7Pu0RKlBl9tZaU/WPP8P5+V3eYriBJGx3d; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: ietf-behave@list.sipfoundry.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 Ahhh. Nothing brings out opinions like a naming debate. I think Francois got it right. I'd prefer "STUN: Set of Tools Useful for NAT". I like semi-derogatory things like Uncorking and Unblocking more for working group names (which is an IETF insider thing) and not protocol names (which are read by everyone). -Jonathan R. Pete Cordell wrote: > I'm happy with this, although technically the acronym would be STUNT, > which may not project the right image. > > A compromise of all the suggestions so far could be: > > Set of Tools for Uncorking NATs > > My only reservation with that is it makes NATs sound like fine wine > which doesn't seem right! > > On the other hand, > > Set of Tools for Unblocking NATs > > makes NATs sound more like drains, which may be more appropriate! > > Maybe if we want to toss around a few more ideas we can do it off-list, > and come back when we've got a candidate. > > Pete. > ----- Original Message ----- From: "Philip Matthews" > > To: "Francois Audet" > Cc: "Spencer Dawkins" ; "Pete Cordell" > ; > Sent: Friday, December 01, 2006 2:32 AM > Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT > > >> Perhaps even more accurate would be >> "Set of Tools and Usages for NAT traversal". >> >> - Philip >> >> >> On 30-Nov-06, at 17:47 , Francois Audet wrote: >> >>> Yes agreed. >>> >>> In fact, the worst names we come up with is when we try to match an >>> acronym. >>> For example, "Behavior Engineering for Hindrance Avoidance"... >>> >>>> -----Original Message----- >>>> From: Philip Matthews [mailto:philip_matthews@magma.ca] >>>> Sent: Thursday, November 30, 2006 14:37 >>>> To: Spencer Dawkins; Audet, Francois (SC100:3055); Pete Cordell >>>> Cc: ietf-behave@list.sipfoundry.org >>>> Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT >>>> >>>> I also agree with Francois and Spencer. >>>> Though I will suggest that >>>> "Set of Tools Useful for NAT traversal (STUN)" would be more accurate. >>>> >>>> And there is a history of not always having the acronym >>>> correspond directly to the first letter of each work. >>>> Consider, for example, RSVP (Resource Reservation Protocol). >>>> I am sure folks can come up with other examples. >>>> >>>> - Philip >>>> >>>> >>>> On 30-Nov-06, at 14:15 , Spencer Dawkins wrote: >>>> >>>>> Agree with Francois here. This would be a lot less confusing than >>>>> having two specs come out for NAT traversal at the same time... >>>>> >>>>> Spencer >>>>> >>>>> ----- Original Message ----- From: "Francois Audet" >>>> >>>> >>>> >>>>> To: >>>>> Sent: Thursday, November 30, 2006 12:58 PM >>>>> Subject: RE: [BEHAVE] STUN -> Session Traversal Underneath NAT >>>>> >>>>> >>>>> When you think about it, it's not even for NAT traversal >>>> >>>> anymore (that >>>> >>>>> would be ICE). >>>>> >>>>> It's more a set of generic tools for NAT support. >>>>> >>>>> STUN: Set of Tools Useful for NAT >>>>> ^ ^ ^ ^ >>>>> >>>>> Cheers. >>>>> > -- > ============================================= > Pete Cordell > Tech-Know-Ware Ltd > for XML to C++ data binding visit > http://www.tech-know-ware.com/lmx > (or http://www.xml2cpp.com) > ============================================= > >> > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 01 17:10:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqGaM-0002Rm-4Y; Fri, 01 Dec 2006 17:10:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqGaK-0002Qt-Sx for behave@ietf.org; Fri, 01 Dec 2006 17:10:20 -0500 Received: from lambda.sipfoundry.org ([72.232.205.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqGaH-0001dZ-JO for behave@ietf.org; Fri, 01 Dec 2006 17:10:20 -0500 Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by lambda.sipfoundry.org (8.13.8/8.13.8) with ESMTP id kB1MADmp065263 for ; Fri, 1 Dec 2006 16:10:17 -0600 (CST) (envelope-from AUDET@nortel.com) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kB1M9ua19731; Fri, 1 Dec 2006 17:09:56 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] STUN -> Session Traversal Underneath NAT Date: Fri, 1 Dec 2006 16:09:55 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E3DA955@zrc2hxm0.corp.nortel.com> In-Reply-To: <4570A614.4080302@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] STUN -> Session Traversal Underneath NAT thread-index: AccVlDI5qgZtNh/DTQyjCyDQ1y4emQAAMQDw From: "Francois Audet" To: "Jonathan Rosenberg" , "Pete Cordell" X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ietf-behave@list.sipfoundry.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 Thanks. By the way, I got the idea by reading the Abstract which pretty much says exactly that.=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Friday, December 01, 2006 14:01 > To: Pete Cordell > Cc: Philip Matthews; Audet, Francois (SC100:3055);=20 > ietf-behave@list.sipfoundry.org > Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT >=20 > Ahhh. Nothing brings out opinions like a naming debate. >=20 > I think Francois got it right. I'd prefer "STUN: Set of Tools=20 > Useful for NAT". I like semi-derogatory things like Uncorking=20 > and Unblocking more for working group names (which is an IETF=20 > insider thing) and not protocol names (which are read by everyone). _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 01 17:43:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqH65-0007ZN-FG; Fri, 01 Dec 2006 17:43:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqH63-0007Xp-Hg for behave@ietf.org; Fri, 01 Dec 2006 17:43:07 -0500 Received: from lambda.sipfoundry.org ([72.232.205.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqH5y-0005MU-T7 for behave@ietf.org; Fri, 01 Dec 2006 17:43:07 -0500 Received: from smtp1.freeserve.com (smtp1.wanadoo.co.uk [193.252.22.158]) by lambda.sipfoundry.org (8.13.8/8.13.8) with ESMTP id kB1MgwlE066439 for ; Fri, 1 Dec 2006 16:43:02 -0600 (CST) (envelope-from pete.cordell@tech-know-ware.com) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3002.me.freeserve.com (SMTP Server) with ESMTP id B9B991C0014B; Fri, 1 Dec 2006 23:42:50 +0100 (CET) Received: from Codalogic (user-5445210e.lns4-c11.dsl.pol.co.uk [84.69.33.14]) by mwinf3002.me.freeserve.com (SMTP Server) with ESMTP id 74B8E1C0014D; Fri, 1 Dec 2006 23:42:50 +0100 (CET) X-ME-UUID: 20061201224250478.74B8E1C0014D@mwinf3002.me.freeserve.com Message-ID: <001501c7159a$09ed9320$1c00a8c0@Codalogic> From: "Pete Cordell" To: "Francois Audet" , "Jonathan Rosenberg" References: <1ECE0EB50388174790F9694F77522CCF0E3DA955@zrc2hxm0.corp.nortel.com> Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT Date: Fri, 1 Dec 2006 22:42:47 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ietf-behave@list.sipfoundry.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 Excellent. All sorted. Pete. ----- Original Message ----- From: "Francois Audet" To: "Jonathan Rosenberg" ; "Pete Cordell" Cc: "Philip Matthews" ; Sent: Friday, December 01, 2006 10:09 PM Subject: RE: [BEHAVE] STUN -> Session Traversal Underneath NAT Thanks. By the way, I got the idea by reading the Abstract which pretty much says exactly that. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Friday, December 01, 2006 14:01 > To: Pete Cordell > Cc: Philip Matthews; Audet, Francois (SC100:3055); > ietf-behave@list.sipfoundry.org > Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT > > Ahhh. Nothing brings out opinions like a naming debate. > > I think Francois got it right. I'd prefer "STUN: Set of Tools > Useful for NAT". I like semi-derogatory things like Uncorking > and Unblocking more for working group names (which is an IETF > insider thing) and not protocol names (which are read by everyone). -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx (or http://www.xml2cpp.com) ============================================= _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 01 20:04:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqJIj-00041I-EG; Fri, 01 Dec 2006 20:04:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqJIi-00041A-2e for behave@ietf.org; Fri, 01 Dec 2006 20:04:20 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqJIO-0003RU-9Y for behave@ietf.org; Fri, 01 Dec 2006 20:04:20 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kB213sr11021; Fri, 1 Dec 2006 20:03:54 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Dec 2006 19:03:53 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437111B69E4D@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC3489bis-05 comments (section 8 onward) Thread-Index: AccVrbxQRimjR7WEShux0wR/Fu9BNA== From: "Brian Stucker" To: "Jonathan Rosenberg" , "Dan Wing" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: behave@ietf.org Subject: [BEHAVE] RFC3489bis-05 comments (section 8 onward) 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 all, Here are my remaining comments from section 8 onward: Section 8.3.1, paragraph 5 (a.k.a. step 3): NIT: Change 'nulls' to 'whitespace'. Section 8.3.1 Last sentence in the section about pipelining... Same question I raised about similar text in section 7.1. Question: Is it allowable to have multiple transactions outstanding between the same two endpoints, or is it intended that a given server will only have one transaction outstanding from any given client?=20 Suggest changing last sentence in 8.3.1 from: "Regardless of the transport protocol, a client MAY pipeline requests (that is, it can have multiple requests outstanding at the same time)." ...to: "Regardless of the transport protocol, a client MAY have multiple outstanding STUN requests (with different transaction IDs) and not wait for completion of one STUN transaction before initiating another STUN request to the same STUN server." Page 18, next to last paragraph: To match with section 8.3.3 should read: When using TCP or TLS over TCP, the client SHOULD close the connection as soon as it has received the STUN response, and determines it has no further messages to send to the server. Section 8.3.2, page 20, next to last paragraph: In the case of a 431 response, do we really want to specify a "SHOULD alert the user" clause in the protocol? Isn't that a UI issue that is out of scope, or at the very least a RECOMMENDED instead of a SHOULD?=20 What should the client do if it gets a 431 response to a request that did not use a short term credential obtained from a Shared Secret request in the request? Unrecoverable failure? Page 21, second paragraph: "It the client receives..." should be changed to "If the client receives..." I have the same issue of codifying when to alert the user in a protocol specification as in the previous text. What constitutes "repeated rejection" of a request by a 436 response? Two, three, ten? Can't we put a number on this? If you keep getting usernames from the Shared Secret request that are bad, why not limit this to two retries to get a new username and use that to retry the original request (just to be safe in case of race conditions)? Page 21, second paragraph: Although later in the document it becomes obvious that success responses do not have a response code, for those who are familiar with SIP/HTTP response codes, listing 100-299 as response codes to be discarded can be initially confusing. May want to point out that this paragraph is talking about error response messages as Section 8.3.2 talks about both types interchangibly. Page 22, first paragraph: This text states that indications are typically sent over the same TCP connection, but the next to last paragraph in section 8.3.1 said that the client SHOULD close the TCP connection after getting a response to a request. I understand that this is a TURN usage, and in that context, the two pieces of text make sense. However, since indications can be used for other usages in the future, this is an additional reason to relax the wording in section 8.3.1 from "further request" to "further messages" as noted above. Page 23, next to last paragraph: Idempotentcy is not guaranteed for binding requests in the case that the NAT creates a new binding between retransmissions of the same STUN request (NAT may have been rebooted, etc). Page 25, third paragraph of Secion 9.1.2: NIT: "source" in fifth sentence is given as "souce". Section 9.1.3: Should make all of the statements in this section normative MUSTs. Section 11.2, third paragraph: MAPPED-ADDRESS is left-padded with the first eight bits. USERNAME is right-padded with trailing bytes. What encoding is to be used for string-based attributes? UTF-8, US-ASCII (ANSI X3.4-1986)? Same question for other text-encoded elements in the STUN message. Is this padding a SHOULD, MUST, or RECOMMENDED? Section 11.3, last paragraph: Text should read: "If the PASSWORD is not a multiple of four bytes, it SHOULD/MUST/RECOMMENDED be right-padded for encoding into the STUN message to a natural four-byte boundary. The attribute length represents the length of the PASSWORD prior to any padding." Section 11.4: The hash would naturally be binary, so how was it encoded into text, and then how is that text encoded back into binary? Is padding MUST/SHOULD/RECOMMENDED? Section 11.13: First paragraph, typo on provides. Second paragraph... what does a refresh interval of zero mean? Regards, Brian _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 01 20:15:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqJSt-0005ly-PH; Fri, 01 Dec 2006 20:14:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqJSs-0005lt-Pt for behave@ietf.org; Fri, 01 Dec 2006 20:14:50 -0500 Received: from buggy.corp.yahoo.com ([207.126.225.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqJSr-0006SA-B3 for behave@ietf.org; Fri, 01 Dec 2006 20:14:50 -0500 Received: (from lloydh@localhost) by buggy.corp.yahoo.com (8.12.3/8.12.3) id kB21EkjW026389 for behave@ietf.org; Fri, 1 Dec 2006 17:14:46 -0800 (PST) (envelope-from lloydh) Date: Fri, 1 Dec 2006 17:14:46 -0800 From: Lloyd Hilaiel To: behave@ietf.org Message-ID: <20061202011446.GD74215@buggy.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Subject: [BEHAVE] draft-ietf-behave-rfc3489bis-05 nits 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 Greetings, This first email has editorial nits of draft-ietf-behave-rfc3489bis-05.txt. Please let me know if the the format (universal diffs) is inconvenient. These 13 issues are minor and don't require a response. I apologize if I duplicated previously discussed issues. Please drop said duplicates on the floor. I'll send along my (marginally) deeper questions in the next day. 0. There are at least three different phrases used to refer to the same usage: "binding refresh usage", "binding keepalive usage" and "NAT keepalive usage". One phrase should be chosen. (searching keepalive throughout reveals them all). 1. A repeat of Philip's comment about "client" and "server" being potentially confusing. Especially in the abstract where the terms haven't been defined yet, I found the use of the terms to be a bit misleading. @@ -59,3 +59,3 @@ allocated to them by a NAT and to keep NAT bindings open. It can - also serve as a check for connectivity between a client and a server + also serve as a means to check connectivity between two endpoints in the presence of NAT, and for the client to detect failure of the 2. In section 1, the stun relay usage does not handle the case where the "STUN server is not in a common address realm". @@ -248,4 +250,5 @@ STUN relay usage, when used by itself, eliminates all of the limitations of using the binding usage by itself, as described above. +>> except when the STUN server is not in a common shared address realm. However, it requires a server to act as a relay for application traffic, which can be expensive to provide, operate, and manage. 3. section 5, overview of operation. replace all with both. @@ -531,7 +534,7 @@ - These two usages all utilize the same Binding Request message, and - all require the same basic processing on the server. They differ + These two usages both utilize the same Binding Request message, and + both require the same basic processing on the server. They differ 4. section 5, overview of operation. I think we missed an update from rfc3489bis-04 to rfc3489bis-05. Fingerprint is no longer mandatory. Also, wondering if dropping "cryptographic" is appropriate due to the change in algorithm from SHA1 to CRC32. @@ -548,5 +553,6 @@ STUN defines a special field in the message called the magic cookie, - which is a fixed 32 bit value that identifies STUN traffic. STUN - requests also contain a fingerprint, which is a cryptographic hash of - the message, that allow for validation that the message was a STUN + which is a fixed 32 bit value that identifies STUN traffic. In cases + where the magic cookie is insufficient, STUN requests may also contain + a fingerprint, which is a hash of + the message, that allows for validation that the message was a STUN request and not a data packet that happened to have the same 32 bit 5. section 6, stun message structure. thoughts on word choice. I felt "consist of" was clearer than "utilize" @@ -585,4 +591,4 @@ There are two types of transactions in STUN - request/response - transactions, which utilize a request message and a response message, - and indication transactions, which utilizes a single indication + transactions, which consist of a request message and a response message, + and indication transactions, which consist of a single indication message. Furthermore, responses are broken into two types - success 8. 11.3 password. copy paste errors @@ -1690,6 +1723,6 @@ key in the MESSAGE-INTEGRITY attribute of a subsequent STUN - transaction. Note that, as described above, if the USERNAME is not a + transaction. Note that, as described above, if the PASSWORD is not a multiple of four bytes it is padded for encoding into the STUN message, in which case the attribute length represents the length of - the USERNAME prior to padding. + the PASSWORD prior to padding. 9. 11.5 fingerprint, word choice. @@ -1715,3 +1748,3 @@ - The FINGERPRINT attribute can be present in all STUN messages. It is + The FINGERPRINT attribute MAY be present in any STUN message. It is computed as the CRC-32 of the STUN message up to (but excluding) the 10. 11.11 server, copy paste errors @@ -1928,4 +1966,4 @@ of four bytes, it is padded for encoding into the STUN message, in - which case the attribute length represents the length of the USERNAME - prior to padding. + which case the attribute length represents the length of the SERVER + value prior to padding. 11. 11.13 refresh-interval, if this is normative, consider replacing "can" with "MAY" @@ -1953,3 +1991,3 @@ REFRESH-INTERVAL is specified as an unsigned 32 bit integer, and - represents an interval measured in millseconds. It can be present in + represents an interval measured in millseconds. It MAY be present in 12. 12.1.1 applicability of binding discovery. Don't know if this is useful, but I was confused by using the phrase "mapped address" because of the collision with the "MAPPED-ADDRESS" attribute. @@ -1995,6 +2033,6 @@ address that is assigned by a NAT between a STUN client and a STUN - server. This transport address will be present in the mapped address - of the STUN Binding Response. + server. This transport address will be present in the + XOR-MAPPED-ADDRESS attribute of the STUN Binding Response. best, lloyd -- lloydh@yahoo-inc.com | maintain granted for and be customers' http://docs.yahoo.com/info/values/ _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 01 21:16:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqKPn-0007vc-AO; Fri, 01 Dec 2006 21:15:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqKPl-0007v8-Un for behave@ietf.org; Fri, 01 Dec 2006 21:15:41 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqKPi-0007hx-Ji for behave@ietf.org; Fri, 01 Dec 2006 21:15:41 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kB228Mp21745; Fri, 1 Dec 2006 21:08:22 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] Review of rfc3489bis-05 up to section 8 Date: Fri, 1 Dec 2006 20:15:28 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437111B69E63@zrc2hxm2.corp.nortel.com> In-Reply-To: <1164853585.21947.31.camel@sioux.systems.cs.cornell.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Review of rfc3489bis-05 up to section 8 Thread-Index: AccUJvhqSTJ6DpuJRi6PKgntUXkGrABkKFGA From: "Brian Stucker" To: "Saikat Guha" , "Dan Wing" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: rohan@ekabal.com, 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 What if the TCP connection was established, but closed between the time a STUN request was sent out, and a response came back in? Failure? Seems like it would have to be, but what would the client be expected to do? Regards, Brian > -----Original Message----- > From: Saikat Guha [mailto:saikat@cs.cornell.edu]=20 > Sent: Wednesday, November 29, 2006 8:26 PM > To: Dan Wing > Cc: Stucker, Brian (RICH1:AR00); 'Jonathan Rosenberg';=20 > rohan@ekabal.com; behave@ietf.org > Subject: RE: [BEHAVE] Review of rfc3489bis-05 up to section 8 >=20 > On Wed, 2006-11-29 at 17:07 -0800, Dan Wing wrote: > > I expect that would interact poorly with TCP simultaneous-open. =20 > > Saikat, any thoughts? > > > > > -----Original Message----- > > > From: Brian Stucker [mailto:bstucker@nortel.com] > > >=20 > > > One other thought on section 7.1... The current text states that=20 > > > transport failures (ICMP errors) for UDP should be considered=20 > > > failures. > > > What about other transport failures? Does a TCP connection reset=20 > > > constitute a failure of the STUN transaction? >=20 > If an app is trying TCP S-O and *only* TCP S-O, then RSTs can=20 > be annoying, but apps should be doing both regular=20 > connections and S-O in parallel as per ICE. >=20 > If an endpoint gets an RST while trying to STUN the other=20 > end, then packets must be getting through to the other end=20 > (BEHAVE compliant NATs are not supposed to RST new=20 > connections). In those cases, the regular connection should=20 > work (i.e. local LAN or already-punched NAT). >=20 > -- > Saikat >=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Dec 02 19:20:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gqf4t-0001wM-5t; Sat, 02 Dec 2006 19:19:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gqf4r-0001vm-AP for behave@ietf.org; Sat, 02 Dec 2006 19:19:29 -0500 Received: from buggy.corp.yahoo.com ([207.126.225.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gqf4p-00020Z-UW for behave@ietf.org; Sat, 02 Dec 2006 19:19:29 -0500 Received: (from lloydh@localhost) by buggy.corp.yahoo.com (8.12.3/8.12.3) id kB30JRPE074913 for behave@ietf.org; Sat, 2 Dec 2006 16:19:27 -0800 (PST) (envelope-from lloydh) Date: Sat, 2 Dec 2006 16:19:27 -0800 From: Lloyd Hilaiel To: behave@ietf.org Message-ID: <20061203001926.GF74215@buggy.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Spam-Score: -15.0 (---------------) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: [BEHAVE] 3 more comments on draft-ietf-behave-rfc3489bis-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hello all, My remaining issues are 3 in number, and again, minor. Most of the notes I jotted down on a fresh read of rfc3489bis-05 ended up being already addressed by folks previously... Overall, I'm excited to see this go to RFC, and find it much clearer (and simpler, despite the name change) than RFC 3489. FWIW, I think moving nat type detection out into a seperate usage was a wonderful decision. 1. rename "magic cookie"? afaict, there are three roles the magic cookie serves: * provides a tool for demux * serves as a STUN version number * is the xor value used in encoding of XOR-MAPPED-ADDRESS (along with the transaction id) I would find it clearer if there were fewer interdependencies here, that is, if XOR-MAPPED-ADDRESS was encoded using a constant. And the magic cookie because simply a version number. So I'd propose: 1. change "magic cookie" to "STUN version number" 2. define a 16 byte constant in the document for encoding of XOR-MAPPED-ADDRESS (as is done in 11.5, FINGERPRINT) 3. everywhere we talk about the magic cookie being used as a demux tool, update language to refer to stun version number. This is a matter of semantics, and results in no normative changes other than xor mapped address encoding, I just felt it made it explicit what bits 32..61 in a STUN message really do. Also there was some wondering about why the transaction id needs to be 96 bits, this removes a reason. fwiw. My assumption is that it is not required /desired that the xor'd mapped address is a function of the stun header... 2. change the encoding of UNKNOWN-ATTRIBUTES: from section 11.9: "If the number of unknown attributes is an odd number, one of the attributes MUST be repeated in the list, so that the total length of the list is a multiple of 4 bytes." This seems needless ambiguity. I'd suggest zero byte padding and setting the length of the attribute header to only the usable portion of the payload. 3. confusion over transaction ids in indications. I find it a little unclear the conflicting language around TIDs and indications: section 8.4 says: "Indication message types are not sent reliably, do not elicit a response from the server, and are not retransmitted." vs. Section 6 says: "Indications are also identified by their transaction ID. The transaction ID there MUST also be uniformly and randomly distributed between 0 and 2**96 - 1.As with requests, the value is chosen by the server and MUST be unique for each unique indication generated by the server. Unless a request or indication is bit-wise identical to a previous request, and was sent to the same server from the same transport address, a client MUST choose a new transaction ID for it." The contradiction here is "Unless a request or indication is bit-wise identical to a previous request" suggests I may retransmit indications. while section 8.4 explicitly states I may not. Suggest "Unless a request is bit-wise identical to a previous request, a client MUST choose a new transaction ID for it. A client MUST NOT send two indications with the same transaction id." best, lloyd -- lloydh@yahoo-inc.com | irreverence responsibility share http://docs.yahoo.com/info/values/ _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Dec 03 13:50:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqwPX-0003F4-Dv; Sun, 03 Dec 2006 13:49:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqwPV-0003Es-FT for behave@ietf.org; Sun, 03 Dec 2006 13:49:57 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqwPU-0003GE-6K for behave@ietf.org; Sun, 03 Dec 2006 13:49:57 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-6.cisco.com with ESMTP; 03 Dec 2006 10:49:55 -0800 X-IronPort-AV: i="4.09,490,1157353200"; d="scan'208"; a="89667338:sNHT37764369" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id kB3InlsR019358 for ; Sun, 3 Dec 2006 10:49:47 -0800 Received: from dwingwxp ([10.32.240.194]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kB3InGdE010363 for ; Sun, 3 Dec 2006 10:49:31 -0800 (PST) From: "Dan Wing" To: Date: Sun, 3 Dec 2006 10:49:11 -0800 Message-ID: <075f01c7170b$c52c4380$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccXC7iuBqrlCHBETduLgtsQ4y5zLg== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=421; t=1165171787; x=1166035787; c=relaxed/simple; s=sjdkim7002; 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:=20BEHAVE=20minutes |Sender:=20; bh=EJc8hraEKVsmT5t5tVxXr3nWxv8jbr/zazuvYDI9l+s=; b=P4njTjD6Af8ANE9IGcBy9tMN+3LXbwAuUNr3choY+IyxauOmaHuLBUn5itaAQ63Wcdbje2XZ 81qPwhC8CMQ6U66PcUZzHB31+fV+EDSoKNiErqElbJNST2xb98QGLuuX; Authentication-Results: sj-dkim-7; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [BEHAVE] BEHAVE minutes 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 Minutes of the last BEHAVE meeting have been posted to: http://www3.ietf.org/proceedings/06nov/minutes/behave.html Please email me any corrections or additions. Final cut off for changes is 27 December, but I would need at least a day or two to incorporate any changes. Audio of the session is here (it's a bit noisy): http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf67/ietf67ch1-wed-am. mp3 -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 04 01:48:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr7cR-00078I-NW; Mon, 04 Dec 2006 01:48:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr7cQ-00075e-6L for behave@ietf.org; Mon, 04 Dec 2006 01:48:02 -0500 Received: from wx-out-0506.google.com ([66.249.82.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gr7cP-0003Rm-N1 for behave@ietf.org; Mon, 04 Dec 2006 01:48:02 -0500 Received: by wx-out-0506.google.com with SMTP id h27so3740258wxd for ; Sun, 03 Dec 2006 22:48:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=XY3KrhE2+mwKWNFJ9nfiwddzeXStASVthuc6+zF4UUTI5e/1/POBGeUp327U9vvuBge6Dsh0mZ+/emXzikwJqw4hdzX552y6HER4ZBgEzoCfZlLmixPr1oQIu4l4S1sXuuU2cMSP9bvDLxVOyXvw0ofZU24aGF6bwbF3+KmXTDc= Received: by 10.90.29.2 with SMTP id c2mr7518309agc.1165214881372; Sun, 03 Dec 2006 22:48:01 -0800 (PST) Received: by 10.90.90.18 with HTTP; Sun, 3 Dec 2006 22:48:01 -0800 (PST) Message-ID: Date: Mon, 4 Dec 2006 12:18:01 +0530 From: "Mayank Dev Sondhi" To: jdrosen@cisco.com, dwing@cisco.com, rohan@ekabal.com MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: behave@ietf.org Subject: [BEHAVE] draft-ietf-behave-rfc3489bis-05 review comments (apologize for the delay) 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="===============0143921970==" Errors-To: behave-bounces@ietf.org --===============0143921970== Content-Type: multipart/alternative; boundary="----=_Part_17689_15188219.1165214881346" ------=_Part_17689_15188219.1165214881346 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi everyone, I guess I may be a little late with this, Here are some of the comments on the draft from my side: --------------------------------------------------------------------------------------------------------------------------------------------------------- *Section 1: Applicability statement:* *Statement: "It will allow incoming UDP packets through NAT, but only through a subset of existing NAT types."* Comment: STUN does not allow by itself incoming UDP packets. Is this not a property of the NAT? *Statement: "Furthermore, the binding usage, when used by itself, does not work when a client is communicating with a peer which happens to be behind the same NAT."* Comment: There are specific NATs that seem to have this loopback characteristic. "Does Not" could be reworded to "May Not" *Section 5:* General Comment: The client server paradigm as outlined in the diagram, could be 2 peers as well. In that case should the word "server" be outlined in more detail as to what it means? *Statement: "Shared secret requests are sent over TLS(5) over TCP"* Comment: I believe this restriction on TLS over TCP should be relaxed a little? TLS over UDP as in DTLS(rfc4347) though still in infancy is a potential means as well. Also over mobile networks UDP has significant performance gains over TCP and UDP gains more importance in such scenarios. *Statement: "In the binding keepalive usage, a client sends an application protocol message (such as a SIP REGISTER message) to a server. The server notes the source transport address of the request, and remembers it. Later on, if it needs to reach the client, it sends a message to that transport address. However, this message will only be received by the client if the binding in the NAT is still alive. Since bindings allocated by NAT expire unless refreshed, the client must generate keepalive messages toward the server to refresh the binding. Rather than use expensive application layer messages, a STUN binding request is sent by the client to the server, and is sent to the exact same transport address used by the server for the application protocol. In the case of SIP, this would typically mean port 5060 or 5061. This has the effect of keeping the bindings in the NAT alive. The STUN binding responses also inform the client that the server is still responsive, and also inform the client if its transport address towards the server have changed (its reflexive transport address), in which case it may need application layer protocol messaging to update its transport address as seen by the server. The binding keepalive usage is used by the SIP outbound mechanism, for example [18]. "* Comment: One should note here that this would be gauranteed to work in case STUN functionality is in built in the SIP server(I assume the server referred to in the first line is a SIP server). If the 2 servers are different then certain NATs could cause problems in the above scenario. *Section 6:* *Statement: "The transaction ID MUST be uniformly and randomly distributed between 0 and 2**96 - 1"* Comment: Is 0 a special case scenario? *Statement: "A reponse to the STUN request"* Comment: typo, should be response. *Section 7.1:* *Statement: "If the client has not received a response after 7900ms, it considers the transaction to have timed out. "* Comment: Why this value, 7900ms? Is this done for consistency with UDP? As most TCP stacks have their own timeout right? *Section 7.2:* *Statement: "Indications are sent from the client to the server, or from the server to the client" * Comment: Indications as mentioned here, although specified only for the Relays, seem to convey the message that they are unidirectional. With UDP NATs an inherent problem could be the closing of bindings and/or improper usage of bindings. For example say request X is made, indication A is sent by the server and then response Y is sent by the server. Since ingress/egress semantics could be used by the NAT, the indication A may be taken as a response to X by the NAT and the binding could be closed BEFORE response Y is sent. Even with Keepalives this can still happen, can this point be elaborated further here? *Section 8.3.2:* *Statement: "If the client receives a 401 (Unauthorized) response and had not included a MESSAGE-INTEGRITY attribute in the request, it is an indication from the server that credentials are required"* Comment: Possible rewording as indications in STUN are used as something different. Signal seems like a better word instead of indication --------------------------------------------------------------------------------------------------------------------------------------------------------- My review has not been fully complete, and I apologize in advance if some of these comments have already been covered. Thanks Mayank ------=_Part_17689_15188219.1165214881346 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi everyone,
       I guess I may be a little late with this, Here are some of the comments on the draft from my side:
 
 
---------------------------------------------------------------------------------------------------------------------------------------------------------

Section 1: Applicability statement:

Statement: "It will allow incoming UDP packets through NAT, but only through a subset of existing NAT types."

Comment: STUN does not allow by itself incoming UDP packets. Is this not a property of the NAT?


Statement: "Furthermore, the binding usage, when used by itself, does not work when a client is communicating with a peer which happens to be behind the same NAT."

Comment: There are specific NATs that seem to have this loopback characteristic. "Does Not" could be reworded to "May Not"

Section 5:

General Comment: The client server paradigm as outlined in the diagram, could be 2 peers as well. In that case should the word "server" be outlined in more detail as to what it means?

Statement: "Shared secret requests are sent over TLS(5) over TCP"

Comment: I believe this restriction on TLS over TCP should be relaxed a little? TLS over UDP as in DTLS(rfc4347) though still in infancy is a potential means as well. Also over mobile networks UDP has significant performance gains over TCP and UDP gains more importance in such scenarios.

Statement: "In the binding keepalive usage, a client sends an application
   protocol message (such as a SIP REGISTER message) to a server.  The
   server notes the source transport address of the request, and
   remembers it.  Later on, if it needs to reach the client, it sends a
   message to that transport address.  However, this message will only
   be received by the client if the binding in the NAT is still alive.
   Since bindings allocated by NAT expire unless refreshed, the client
   must generate keepalive messages toward the server to refresh the
   binding.  Rather than use expensive application layer messages, a
   STUN binding request is sent by the client to the server, and is sent
   to the exact same transport address used by the server for the
   application protocol.  In the case of SIP, this would typically mean
   port 5060 or 5061.  This has the effect of keeping the bindings in
   the NAT alive.  The STUN binding responses also inform the client
   that the server is still responsive, and also inform the client if
   its transport address towards the server have changed (its reflexive
   transport address), in which case it may need application layer
   protocol messaging to update its transport address as seen by the
   server.  The binding keepalive usage is used by the SIP outbound
   mechanism, for example [18]. "

Comment: One should note here that this would be gauranteed to work in case STUN functionality is in built in the SIP server(I assume the server referred to in the first line is a SIP server).
If the 2 servers are different then certain NATs could cause problems in the above scenario.

Section 6:

Statement: "The transaction ID MUST be uniformly and randomly
   distributed between 0 and 2**96 - 1"

Comment: Is 0 a special case scenario?

Statement: "A reponse to the STUN request"

Comment: typo, should be response.


Section 7.1:

Statement: "If the client has not received a response after 7900ms, it
   considers the transaction to have timed out. "

Comment: Why this value, 7900ms? Is this done for consistency with UDP? As most TCP stacks have their own timeout right?

Section 7.2:

Statement: "Indications are sent from the client to the server, or from the
   server to the client"

Comment: Indications as mentioned here, although specified only for the Relays, seem to convey the message that they are unidirectional. With UDP NATs an inherent problem could be the closing of bindings and/or improper usage of bindings.
For example say request X is made, indication A is sent by the server and then response Y is sent by the server. Since ingress/egress semantics could be used by the NAT, the indication A may be taken as a response to X by the NAT and the binding could be closed BEFORE response Y is sent. Even with Keepalives this can still happen, can this point be elaborated further here?


Section 8.3.2:

Statement: "If the client receives a 401 (Unauthorized) response and had not
   included a MESSAGE-INTEGRITY attribute in the request, it is an
   indication  from the server that credentials are required"

Comment: Possible rewording as indications in STUN are used as something different. Signal seems like a better word instead of indication

---------------------------------------------------------------------------------------------------------------------------------------------------------

My review has not been fully complete, and I apologize in advance if some of these comments have already been covered. 

Thanks

Mayank
 

------=_Part_17689_15188219.1165214881346-- --===============0143921970== 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 --===============0143921970==-- From behave-bounces@ietf.org Mon Dec 04 08:29:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrDs6-0001jz-TN; Mon, 04 Dec 2006 08:28:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrDs5-0001jj-7V for behave@ietf.org; Mon, 04 Dec 2006 08:28:37 -0500 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrDs2-0006AD-Uw for behave@ietf.org; Mon, 04 Dec 2006 08:28:37 -0500 Received: from exchfe1.cs.cornell.edu ([128.84.97.33]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 08:28:29 -0500 Received: from [128.84.227.57] ([128.84.227.57]) by exchfe1.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 08:28:24 -0500 Subject: RE: [BEHAVE] Review of rfc3489bis-05 up to section 8 From: Saikat Guha To: Brian Stucker In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437111B69E63@zrc2hxm2.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437111B69E63@zrc2hxm2.corp.nortel.com> Organization: Cornell University Date: Mon, 04 Dec 2006 08:29:13 -0500 Message-Id: <1165238953.5311.19.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) X-OriginalArrivalTime: 04 Dec 2006 13:28:24.0899 (UTC) FILETIME=[134B3930:01C717A8] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: rohan@ekabal.com, behave@ietf.org, Dan Wing 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="===============1065074883==" Errors-To: behave-bounces@ietf.org --===============1065074883== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-9FaGeNCJuhiIQoJ22Hmw" --=-9FaGeNCJuhiIQoJ22Hmw Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2006-12-01 at 20:15 -0600, Brian Stucker wrote: > What if the TCP connection was established, but closed between the time > a STUN request was sent out, and a response came back in? Failure? Seems > like it would have to be, but what would the client be expected to do? Normally the OS would not report a failure on the write() call if the socket went away before the request would be written. (Actually, it would signal EPIPE and kill the process normally) I believe. --=20 Saikat --=-9FaGeNCJuhiIQoJ22Hmw Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFdCKpnFltqi691/oRAsh4AJ4uDthxle/lkYYzB1xl90YgDpebkQCfUjVj HBXw4fBWJPXXRxBjMZ+K6RM= =aSBF -----END PGP SIGNATURE----- --=-9FaGeNCJuhiIQoJ22Hmw-- --===============1065074883== 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 --===============1065074883==-- From behave-bounces@ietf.org Mon Dec 04 13:20:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrIQd-0003Ii-S9; Mon, 04 Dec 2006 13:20:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrIQb-0003Id-Pz for behave@ietf.org; Mon, 04 Dec 2006 13:20:33 -0500 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrIQZ-0004SR-Ch for behave@ietf.org; Mon, 04 Dec 2006 13:20:33 -0500 Received: by ug-out-1314.google.com with SMTP id 72so2688961ugd for ; Mon, 04 Dec 2006 10:20:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Zb7EFVmC5+H3jFDIO0b3Co4q0cDrhJusBxUvuDsv1jE7/L5EOqegdHcAENdrqu7dDGrt1l7+W7La4T1VvWF2EwuxJQ0bhq2ch/tzul3sX3DBV0QHmTJ8mJ1/vhNoLQtdR6jTyiIW12zcScWTmzLmM7B8Mo5D0h7x8AOhXhJIO2A= Received: by 10.78.200.3 with SMTP id x3mr7946327huf.1165256429952; Mon, 04 Dec 2006 10:20:29 -0800 (PST) Received: by 10.78.120.15 with HTTP; Mon, 4 Dec 2006 10:20:29 -0800 (PST) Message-ID: <953beacc0612041020o5956c413w8b465da950373aa3@mail.gmail.com> Date: Mon, 4 Dec 2006 10:20:29 -0800 From: "Rohan Mahy" To: "Dan Wing" Subject: Re: [BEHAVE] Question on TURN lockdown In-Reply-To: <089e01c714c2$e27be5d0$fe78150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <456F3901.2080309@sipstation.com> <089e01c714c2$e27be5d0$fe78150a@amer.cisco.com> X-Spam-Score: 1.9 (+) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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 Hi Alan, If you can propose some specific language that describes this kind of an exception I'll look at putting it in the draft. Current however, the UNSAF and Security Considerations rely heavily on the property that Dan described. thanks, -rohan On 11/30/06, Dan Wing wrote: > It was a conscious design decision when TURN was written so that > the TURN client (the user agent) would need to know the IP > address of the remote machine to communicate with the remote > machine. This was to assuage concerns of network security > administrators that TURN could be used to establish a > 'server' from behind a firewall or NAT -- which is exactly > what you're trying to allow. > > It might be possible to dance around this issue gently so that > p2p-sip using TURN can do what you want, whereas a normal, > non-p2p-sip TURN server would disallow this. The authors of > TURN may have suggestions on how this could be accomplished > in the upcoming turn-03. > > -d > > > > -----Original Message----- > > From: Alan Johnston [mailto:alan@sipstation.com] > > Sent: Thursday, November 30, 2006 12:03 PM > > To: behave@ietf.org > > Subject: [BEHAVE] Question on TURN lockdown > > > > My apologies for bringing up an old issue, but I've only just become > > aware of the removal of TURN's lockdown feature. This was last in > > version draft-ietf-behave-turn-02 (I know, ancient history - > > shows when > > I last read the draft ;-) > > > > Here is this old behavior described in Section 4: > > > > "TURN allows a client to > > obtain a transport address, from a server on the public Internet, > > which can be used in protocols meeting the above criteria. > > However, > > the transport addresses obtained from TURN servers are not > > generally > > useful for receiving data from anywhere. They are only useful for > > communicating with a single peer. Once a host sends > > packets to that > > transport address, it is ``locked down'', meaning that the client > > cannot cause packets to be sent to that host through the > > relay. The > > client will still receive packets sent from different peers to that > > transport address, but these are wrapped in TURN protocol headers, > > reducing their efficiency. This is done purposefully, so as to > > prevent TURN from being used to run servers (such as a web > > server or > > DNS server) on a client behind a NAT. In this way, > > enterprises which > > deploy NATs and firewalls to prevent users from running > > servers, can > > be confident that TURN will not cause any violations in their > > enterprise security policies." > > > > The absence of this feature makes TURN unsuitable for a > > signaling relay, > > something that could potentially be extremely useful for NAT > > traversal > > in P2P SIP without proxy servers. > > > > Is there any way we can bring back this feature, or some equivalent > > feature that allow a TURN user to at least receive notification that > > they are receiving packets from an arbitrary Internet host? > > The current > > mechanism for granting permission could then be used to > > activate forwarding. > > > > Perhaps this could have other uses as well, such as informing a user > > when their TURN server is being subject to a DOS attack, allowing the > > user to select another server. > > > > Thanks, > > Alan > > > > _______________________________________________ > > 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 Dec 04 13:29:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrIYm-0006az-GX; Mon, 04 Dec 2006 13:29:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrIYl-0006Yg-Cn for behave@ietf.org; Mon, 04 Dec 2006 13:28:59 -0500 Received: from lambda.sipfoundry.org ([72.232.205.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrIV0-0004xM-FS for behave@ietf.org; Mon, 04 Dec 2006 13:25:11 -0500 Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.226]) by lambda.sipfoundry.org (8.13.8/8.13.8) with ESMTP id kB4IOxGZ091545 for ; Mon, 4 Dec 2006 12:25:04 -0600 (CST) (envelope-from rohan.mahy@gmail.com) Received: by wr-out-0506.google.com with SMTP id i21so1188975wra for ; Mon, 04 Dec 2006 10:24:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FitRzFLJR9qiRI928JmUC28sxBLZDu97axFgS4/mn5tp/6101H+8rC/NhD2I4ux9yoHTCbpmYLpM+53R/vYCkjh8W09Arzkss2a7EG/e9Og3Qx4iC5x9FspZdrBBF9erWT6awOwRq7+hu/TNuUXA8pEHtRSyWOrRmBAI9v9W4WM= Received: by 10.78.185.15 with SMTP id i15mr7910407huf.1165256693500; Mon, 04 Dec 2006 10:24:53 -0800 (PST) Received: by 10.78.120.15 with HTTP; Mon, 4 Dec 2006 10:24:53 -0800 (PST) Message-ID: <953beacc0612041024y445955d9g31e4bdd8e538327b@mail.gmail.com> Date: Mon, 4 Dec 2006 10:24:53 -0800 From: "Rohan Mahy" To: "Lars Eggert" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45325E87.4060007@db.org> X-Spam-Score: 1.1 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ietf-behave@list.sipfoundry.org Subject: [BEHAVE] Re: [Ietf-behave] turn02 REQUESTED-TRANSPORT 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, My concern about using the IANA protocol registry is that it implies that any protocol in that registry is usable, which is certainly not the case. Also, TURN would not establish a registry of these values, since defining a new transport would require a significant body of normative text that the community would be unlikely to overlook. thanks, -rohan On 10/15/06, Lars Eggert wrote: > On Oct 16, 2006, at 1:15, Alfred E. Heggestad wrote: > > Instead of defining two new values for UDP/TCP transport can we reuse > > e.g. the values defined in netinet/in.h: > > These are taken from the IANA registry for protocol numbers (http:// > www.iana.org/assignments/protocol-numbers), and I agree that using > those numbers would be better than creating a new registry. > > Lars > -- > Lars Eggert NEC Network Laboratories > > > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@list.sipfoundry.org > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 04 22:17:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrQns-0006kC-Un; Mon, 04 Dec 2006 22:17:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrQnr-0006f4-64 for behave@ietf.org; Mon, 04 Dec 2006 22:17:07 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrQnm-0002zK-TV for behave@ietf.org; Mon, 04 Dec 2006 22:17:07 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 04 Dec 2006 19:17:02 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id kB53H0j0008727 for ; Mon, 4 Dec 2006 19:17:00 -0800 Received: from dwingwxp ([10.32.240.194]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kB53GndE024232 for ; Mon, 4 Dec 2006 19:16:54 -0800 (PST) From: "Dan Wing" To: Date: Mon, 4 Dec 2006 19:16:44 -0800 Message-ID: <0a8701c7181b$d214a360$c2f0200a@amer.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: AccYG8pnDrBmK2fxRoS1ekJDBsWizg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=338; t=1165288620; x=1166152620; c=relaxed/simple; s=sjdkim5002; 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:=20STUN=20attributes |Sender:=20; bh=mUW9oSD4GD/qzSFKicTLJNkUSg+qAyhOkVqIJryKLys=; b=KWVoaUFsnDubWKmGfLA9j3LPCcvRns0JkZeKXX0hf8FVA10tMek9uxs4N+4SHRScUD0n1n6b EiaK7SRjXEutZ0ih13oxZxrsrbLMQ+3PQeQNXsmruiGOnQP6+NSKQvpq; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [BEHAVE] STUN attributes 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 In case this helps anyone else, I built a table showing all of the STUN attributes and where they're defined, http://www.employees.org/behave/stun-attributes.html. As IANA will only maintain a registry after an RFC is published, we will probably maintain this page to coordinate STUN attribute values amongst Internet Drafts. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 04 23:19:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrRlK-0007b3-Ok; Mon, 04 Dec 2006 23:18:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrRlJ-0007at-5s for behave@ietf.org; Mon, 04 Dec 2006 23:18:33 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrRlI-0007sO-FW for behave@ietf.org; Mon, 04 Dec 2006 23:18:33 -0500 Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id AC9371CC22 for ; Mon, 4 Dec 2006 20:17:32 -0800 (PST) To: behave@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Mon, 04 Dec 2006 20:17:32 -0800 From: EKR Message-Id: <20061205041732.AC9371CC22@delta.rtfm.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Subject: [BEHAVE] Comments on draft-ietf-behave-rfc3489bis-05.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org $Id: draft-ietf-behave-rfc3489bis-05-rev.txt,v 1.1 2006/12/05 04:21:16 ekr Exp $ GENERAL COMMENTS The short-term/long-term username/password thing strikes me as weird. As I understand it, there are three cases: 1. You have a long-term credential which you use all the time. 2. You have a long-term credential which you bootstrap up to a short-term one. 3. You have no credentials and you get a short-term credential. It's clear what the first case is for, but I don't think I understand the second two. It looks to me like in case (2) you're using a short-term credential as a type of replay detection and in case (3) you're using it as a way to provide message integrity for an anonymous client. Am I right about this? So: 1. Is there any reason why short-term credentials should actually be short-term? Why not let them last indefinitely long, given that we understand techniques for issuing them statelessly. 2. If the short-term credential is purely for a-r, why not just use the nonce? Having two different "this is STUN" indicators, the cookie and the fingerprint, plus the cookie, is kind of complicated. Why not merge them into one long indicator. Is this just historical? DETAILED COMMENTS S 5. binding. Rather than use expensive application layer messages, a STUN binding request is sent by the client to the server, and is sent What's expensive about application-layer messages These two usages all utilize the same Binding Request message, and all require the same basic processing on the server. They differ only in where the server is (a standalone server in the network, or embedded in an application layer server), when the Binding Request is used and what the client does with the mapped address that is returned. It's worth noting that the keepalive usage overloads the binding request. As is observed later, the actual address returned isn't really used (see 12.2.9) S 6. The message type field is decomposed further into the following structure: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|M|M|M|M|C|M|M|M|C|M|M|M|M| |1|1|9|8|7|1|6|5|4|0|3|2|2|0| |1|0| | | | | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Format of STUN Message Type Field M11 through M0 represent a 12-bit encoding of the method. C1 through C0 represent a 2 bit encoding of the class. A class of 0 is a Request, a class of 1 is an indication, a class of 2 is a success response, and a class of 3 is an error response. This specification defines two methods, Binding and Shared Secret. Their method values are enumerated in Section 15. This bit-splitting (M and C intermixed) is kind of wonky. As I understand it, it's because the "class" thing was noted after the fact. Anyway, this weird format needs some explanation. Also, it looks like the next-to-rightmost bit should be M1, not M2. The transaction ID is a 96 bit identifier. STUN transactions are identified by their unique 96-bit transaction ID. The first sentence is redundant. Insert two paragraph breaks, one before "Indications are" and one before "As with requests" S 7.1. When running STUN over UDP it is possible that the STUN request or its response might be dropped by the network. Reliability of STUN request message types is accomplished through client retransmissions. Clients SHOULD retransmit the request starting with an interval of RTO, doubling after each retransmission. RTO is an estimate of the round-trip-time, and is computed as described in RFC 2988 [8], with two exceptions. I'd have to study my RFC 2988, but my memory is that RTO isn't strictly an RTT estimate. Rather, it's based on an RTT estimate but it's designed to provide neighborly retransmit behavior rather than be the best estimate. S 7.2. The default port for STUN requests is 3478, for both TCP and UDP. There is no default port for STUN over TLS. Administrators SHOULD use this port in their SRV records for UDP and TCP, but MAY use others. I would swap the 2nd and 3rd sentences. S 9.1.1. If the request is a retransmission of a request for which the server has already generated a response within the last 10 seconds, the server MUST retransmit the response. A server can do this either by remembering the response it transmitted, or by re-processing the request and computing the response. The latter technique can only be The latter technique MUST only be... Based on the usage, the server determines whether the request requires any authentication and message integrity checks. It can require none, short-term credential based authentication, or long- term credential authentication. s/none/no authentication/ S 9.1.2. When STUN is being multiplexed on the same transport address as application data, and there are valid application layer data packets which could be confused with STUN packets (because, for example, bits 32 through 63 can contain an arbitrary binary value which might be equal to 0x2112A442), the FINGERPRINT attribute MUST be present in the response. Otherwise, its inclusion is RECOMMENDED. So, from the receiver's perspective, does it unambiguously know when a fingerprint will be present for STUN? Maybe it's worth walking through the demux logic. S 11. To allow future revisions of this specification to add new attributes if needed, the attribute space is divided into optional and mandatory ones. Attributes with values greater than 0x7fff are optional, which means that the message can be processed by the client or server even though the attribute is not understood. Attributes with values less than or equal to 0x7fff are mandatory to understand, which means that the client or server cannot successfully process the message unless it understands the attribute. The values of the message attributes are enumerated in Section 15. The following figure indicates which attributes are present in which messages. An M indicates that inclusion of the attribute in the message is mandatory, O means its optional, C means it's conditional based on some other aspect of the message, and - means that the attribute is not applicable to that message type. Mandatory seems to be being used in two different ways here: 1. You must be able to parse it to process this message. 2. It must be in the message. At least in the security area, the term for the first meaning is "critical". S 11.3. Why re-explain the padding convention here? S 11.4. It's kind of unusual to use MD5(password) and then feed it into HMAC-SHA-1. I realize you're doing it to be compatible with old password files, but how important is that really? I notice there's no hash agility here. That will probably give you trouble with the SEC ADs, at least unless you explain why. Why are you padding the message out to 64 bytes? SHA has its own padding. S 11.8. Some more clarity about how NONCEs are used would probably be a good thing. I understand that the idea is you get a 438 and then re-transmit, but that's sort of implict, not stated. S 11.11. of four bytes, it is padded for encoding into the STUN message, in which case the attribute length represents the length of the USERNAME s/USERNAME/SERVER/. I'd remove this sentence anyway. S 12.1.8. It is RECOMMENDED that servers utilize short term credentials, obtained by the client from a Shared Secret request, for authentication and message integrity. Consequently, if a Binding Request is generated without a short term credential, the server SHOULD challenge for one. Why is it RECOMMENDED? S 12.2.8. The server SHOULD NOT authenticate the client or look for a MESSAGE- INTEGRITY attribute. Since the keepalives come with some regularity, and will come for each client that is connected to the server, the processing cost associated with authenticating each request is very high. It is? On most platforms, the cost of running HMAC of a message is pretty small. I think some computations would be in order here. S 12.3.9. password = HMAC takes the key first.... S 13.3. "Secondly", "Thirdly", should be "Second", and "Third" -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 05 14:37:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grg5q-0004Ib-Ub; Tue, 05 Dec 2006 14:36:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grg5p-0004HN-L1 for behave@ietf.org; Tue, 05 Dec 2006 14:36:41 -0500 Received: from lambda.sipfoundry.org ([72.232.205.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grg5k-00006B-7M for behave@ietf.org; Tue, 05 Dec 2006 14:36:41 -0500 Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by lambda.sipfoundry.org (8.13.8/8.13.8) with ESMTP id kB5JaRoI072392 for ; Tue, 5 Dec 2006 13:36:31 -0600 (CST) (envelope-from brodrig@avaya.com) Received: from MA0034AVEXU1.global.avaya.com (h135-35-75-7.avaya.com [135.35.75.7]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kB5JaQY4018857 for ; Tue, 5 Dec 2006 14:36:26 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] STUN -> Session Traversal Underneath NAT X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Tue, 5 Dec 2006 14:36:26 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] STUN -> Session Traversal Underneath NAT Thread-Index: AccVmlz/jfbmGam8SRqa4ewe3/NH1QDCRnYg From: "Rodrig, Benny \(Benny\)" To: "Pete Cordell" , "Francois Audet" , "Jonathan Rosenberg" , "Philip Matthews" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ietf-behave@list.sipfoundry.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 How about "Session Traversal Utilities for NAT"? Similar to "set of tools" but still keeping the meaningful "traversal". -----Original Message----- From: Pete Cordell [mailto:pete.cordell@tech-know-ware.com]=20 Sent: Friday, December 01, 2006 5:43 PM To: Francois Audet; Jonathan Rosenberg Cc: ietf-behave@list.sipfoundry.org Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT Excellent. All sorted. Pete. ----- Original Message ----- From: "Francois Audet" To: "Jonathan Rosenberg" ; "Pete Cordell"=20 Cc: "Philip Matthews" ; Sent: Friday, December 01, 2006 10:09 PM Subject: RE: [BEHAVE] STUN -> Session Traversal Underneath NAT Thanks. By the way, I got the idea by reading the Abstract which pretty much says exactly that. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Friday, December 01, 2006 14:01 > To: Pete Cordell > Cc: Philip Matthews; Audet, Francois (SC100:3055);=20 > ietf-behave@list.sipfoundry.org > Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT > > Ahhh. Nothing brings out opinions like a naming debate. > > I think Francois got it right. I'd prefer "STUN: Set of Tools Useful=20 > for NAT". I like semi-derogatory things like Uncorking and Unblocking=20 > more for working group names (which is an IETF insider thing) and not=20 > protocol names (which are read by everyone). -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx (or http://www.xml2cpp.com) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Dec 06 02:14:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grqyh-0007mj-OB; Wed, 06 Dec 2006 02:14:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grqyf-0007me-PQ for behave@ietf.org; Wed, 06 Dec 2006 02:14:01 -0500 Received: from lambda.sipfoundry.org ([72.232.205.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grqya-0008Lb-Fb for behave@ietf.org; Wed, 06 Dec 2006 02:14:01 -0500 Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.225]) by lambda.sipfoundry.org (8.13.8/8.13.8) with ESMTP id kB67DpvG065366 for ; Wed, 6 Dec 2006 01:13:56 -0600 (CST) (envelope-from msondhi@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so130621wxd for ; Tue, 05 Dec 2006 23:13:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=kS75o2cbaP1QxSk48oA74vfHM+T6GDLcVWjX/1rgE/8kJHrwCH3C176Gg3opnja1lIIAy0hQ7cqRJzc9w3SvBt3Q7S6r+pYhmF3MM4HCC335QloN9qyfar6hPB6pf95DVozDqLVF09vD9MosYFIkazcQqpm5fM++WMItAIISgfo= Received: by 10.90.101.19 with SMTP id y19mr339293agb.1165389230695; Tue, 05 Dec 2006 23:13:50 -0800 (PST) Received: by 10.90.90.18 with HTTP; Tue, 5 Dec 2006 23:13:50 -0800 (PST) Message-ID: Date: Wed, 6 Dec 2006 12:43:50 +0530 From: "Mayank Dev Sondhi" To: "Rodrig, Benny (Benny)" Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 1.9 (+) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: ietf-behave@list.sipfoundry.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: , Content-Type: multipart/mixed; boundary="===============1182632338==" Errors-To: behave-bounces@ietf.org --===============1182632338== Content-Type: multipart/alternative; boundary="----=_Part_40583_26623471.1165389230574" ------=_Part_40583_26623471.1165389230574 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Nice, I spent quite a lot of time thinking of words beginning with "U" until finally giving up. On 12/6/06, Rodrig, Benny (Benny) wrote: > > How about "Session Traversal Utilities for NAT"? Similar to "set of > tools" but still keeping the meaningful "traversal". > > -----Original Message----- > From: Pete Cordell [mailto:pete.cordell@tech-know-ware.com] > Sent: Friday, December 01, 2006 5:43 PM > To: Francois Audet; Jonathan Rosenberg > Cc: ietf-behave@list.sipfoundry.org > Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT > > Excellent. All sorted. > > Pete. > ----- Original Message ----- > From: "Francois Audet" > To: "Jonathan Rosenberg" ; "Pete Cordell" > > Cc: "Philip Matthews" ; > > Sent: Friday, December 01, 2006 10:09 PM > Subject: RE: [BEHAVE] STUN -> Session Traversal Underneath NAT > > > Thanks. > > By the way, I got the idea by reading the Abstract which pretty much > says exactly that. > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > Sent: Friday, December 01, 2006 14:01 > > To: Pete Cordell > > Cc: Philip Matthews; Audet, Francois (SC100:3055); > > ietf-behave@list.sipfoundry.org > > Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT > > > > Ahhh. Nothing brings out opinions like a naming debate. > > > > I think Francois got it right. I'd prefer "STUN: Set of Tools Useful > > for NAT". I like semi-derogatory things like Uncorking and Unblocking > > more for working group names (which is an IETF insider thing) and not > > protocol names (which are read by everyone). > -- > ============================================= > Pete Cordell > Tech-Know-Ware Ltd > for XML to C++ data binding visit > http://www.tech-know-ware.com/lmx > (or http://www.xml2cpp.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 > ------=_Part_40583_26623471.1165389230574 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Nice, I spent quite a lot of time thinking of words beginning with "U" until finally giving up.

On 12/6/06, Rodrig, Benny (Benny) <brodrig@avaya.com> wrote:
How about "Session Traversal Utilities for NAT"? Similar to "set of
tools" but still keeping the meaningful "traversal".

-----Original Message-----
From: Pete Cordell [mailto:pete.cordell@tech-know-ware.com]
Sent: Friday, December 01, 2006 5:43 PM
To: Francois Audet; Jonathan Rosenberg
Cc: ietf-behave@list.sipfoundry.org
Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT

Excellent.  All sorted.

Pete.
----- Original Message -----
From: "Francois Audet" <audet@nortel.com>
To: "Jonathan Rosenberg" <jdrosen@cisco.com>; "Pete Cordell"
<pete.cordell@tech-know-ware.com>
Cc: "Philip Matthews" <philip_matthews@magma.ca>;
< ietf-behave@list.sipfoundry.org>
Sent: Friday, December 01, 2006 10:09 PM
Subject: RE: [BEHAVE] STUN -> Session Traversal Underneath NAT


Thanks.

By the way, I got the idea by reading the Abstract which pretty much
says exactly that.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]
> Sent: Friday, December 01, 2006 14:01
> To: Pete Cordell
> Cc: Philip Matthews; Audet, Francois (SC100:3055);
> ietf-behave@list.sipfoundry.org
> Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT
>
> Ahhh. Nothing brings out opinions like a naming debate.
>
> I think Francois got it right. I'd prefer "STUN: Set of Tools Useful
> for NAT". I like semi-derogatory things like Uncorking and Unblocking
> more for working group names (which is an IETF insider thing) and not
> protocol names (which are read by everyone).
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
for XML to C++ data binding visit
http://www.tech-know-ware.com/lmx
(or http://www.xml2cpp.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

------=_Part_40583_26623471.1165389230574-- --===============1182632338== 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 --===============1182632338==-- From behave-bounces@ietf.org Wed Dec 06 15:31:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs3Ph-0002z7-Be; Wed, 06 Dec 2006 15:30:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs3Pg-0002z1-J7 for behave@ietf.org; Wed, 06 Dec 2006 15:30:44 -0500 Received: from wr-out-0506.google.com ([64.233.184.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs3Pg-0002bQ-6y for behave@ietf.org; Wed, 06 Dec 2006 15:30:44 -0500 Received: by wr-out-0506.google.com with SMTP id i7so466227wra for ; Wed, 06 Dec 2006 12:30:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=ktSanNLWxCAuvxqymW6BkP/4FbYE0BfEhgYm2waWVjclb/4KV3Y9hgKwdcPM0dyyAyAlQ0N6vux43DWolDw+zEtGOsa9OtW4M884eFilrIya34+vRy8fQAnW/q0kLzUIDxWYO/heBOaEoB0ZkPIf1s7UMhY9MzdhHSNdqTNTEFo= Received: by 10.78.17.4 with SMTP id 4mr882772huq.1165437042511; Wed, 06 Dec 2006 12:30:42 -0800 (PST) Received: by 10.78.120.15 with HTTP; Wed, 6 Dec 2006 12:30:41 -0800 (PST) Message-ID: <953beacc0612061230o4c86a5d8j4b73a8f8f97411eb@mail.gmail.com> Date: Wed, 6 Dec 2006 12:30:41 -0800 From: "Rohan Mahy" To: behave@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: Dan Wing Subject: [BEHAVE] STUN comments part 1 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, Below are the first part of my STUN comments through the end of Section 8.3.1. thanks, -rohan Substantive Comments 0) We have no statement about what level of backwards compatibility we are trying to maintain with this spec. The way the spec is written now a bis client will work with old or new servers, but not vice-versa (the server is required by the previous spec to include the historical attributes in several cases). I think this is potentially OK, but at least should be explicitly mentioned. 1) Use names of the usages consistently. I like the following: Binding Discovery Keepalive Shared Secret The Keepalive usage does not need to be used with a NAT, so 'NAT Keepalive' is not a great term for the usage. I really hate the term "Binding Keepalive" because it makes folks confused. Many think we are talking about the Binding Discovery usage, and others merge the two usages in their mental model. 2) In Section 7.1 paras 2 through 4 are less clear than the corresponding text in -03. I would be happy to take a stab at this. Is the final timer 1.6 seconds exactly or 16x RTO? 3) Section 7.2 para 2 (resending indications) is a bad idea for TURN and as far as I am aware, not useful for any other usage. I strongly recommend simply deleting this paragraph. If a new usage or extension needs this behavior in the future, it can add appropriate language then. 4a) IMO, the SRV discovery procedures in 8.1 should not contain any service names. The service name, if any, should be specified in each usage. The way this is worded now is actually self-contradictory. 4b) SRV transport protocols: I think we want to switch to _tls-tcp going forward and allow _tls for backwards compatibility. I am also fine if we just leave _tls, but we should be explicit that a new transport token should use _tls-foo. 5) Authentication is one of the most confusing aspects of this specification. I think a new subsection should be inserted before 8.3.1 called 'Including Credentials in Requests' which contains para 2 through 6 ("The NONCE..."). I would also add a non-normative table summarizing which authentication attributes are included when. credentials none short-term long-term In Requests MESSAGE-INTEGRITY - X X USERNAME - X X REALM - - X NONCE (first req) - - - NONCE (subsequent) - O X In Responses MESSAGE-INTEGRITY - X X USERNAME - X X REALM - - X NONCE - O X In Indications MESSAGE-INTEGRITY - X - USERNAME - X - REALM - - - NONCE - - - 6) When the magic-cookie is sufficient for demuxing, what will we recommend is done with the FINGERPRINT? SHOULD send, MAY send, SHOULD NOT send? NITS Sect 2, para 2 BEFORE ALGs have serious limitations, including scalability, reliability, and speed of deploying new applications. PROPOSED ALGs have serious limitations, including scalability, reliability, incompatibility with message integrity and encryption techniques, and speed of deploying new applications. Sect 4, STUN Server, last sentence s/Servers also send/Servers can also send/ Sect 4, Long Term Credential s/enrolles/enrolls/ Sect 5, 1st para add a period to the end of the last sentence para 3 s/in which client/in which a client/ para 4 s/outermost NAT towards the/outermost NAT with respect to the/ para 6 s/out-of-bands/out-of-band/ para 8 s\Binding requests\Binding and/or other requests\ para 9 s/Real Time Transport Protocol/Real-time Transport Protocol/ para 10 s/binding keepalive/Keepalive/ (see comment #1) delete sentence "In the case of SIP, this would typically...." s/and also inform/and over UDP, also inform/ para 11 s/These two usages all/These two usages both/ Sect 6, para 3 TCP/TLS --> TLS over TCP para 4 s/TCP or UDP/UDP, TCP, or TLS over TCP/ Figure 3 I think this diagram would be a bit clearer: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|M|M|M|M|M|C|M|M|M|C|M|M|M|M| | | |1|1|9|8|7|1|6|5|4|0|3|2|2|0| | | |1|0| | | | | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ para 11 (begins "The transaction ID...") OLD The transaction ID is a 96 bit identifier. STUN transactions are identified by their unique 96-bit transaction ID. For request/ response transactions, the transaction ID is chosen by the STUN client and MUST be unique for each new STUN transaction generated by that STUN client. The transaction ID MUST be uniformly and randomly distributed between 0 and 2**96 - 1. The large range is needed because the transaction ID serves as a form of randomization, helping to prevent replays of previously signed responses from the server. A reponse to the STUN request, whether it be a success or error response, carries the same transaction ID as the request. Indications are also identified by their transaction ID. The transaction ID there MUST also be uniformly and randomly distributed between 0 and 2**96 - 1.As with requests, the value is chosen by the server and MUST be unique for each unique indication generated by the server. Unless a request or indication is bit-wise identical to a previous request, and was sent to the same server from the same transport address, a client MUST choose a new transaction ID for it. NEW The transaction ID is a 96 bit identifier. STUN transactions are identified by their unique 96-bit transaction ID. For request/ response transactions, the transaction ID is chosen by the STUN client and MUST be unique for each new STUN transaction generated by that STUN client. The transaction ID MUST be uniformly and randomly distributed between 0 and 2**96 - 1. The large range is needed because the transaction ID serves as a form of randomization, helping to prevent replays of previously signed responses from the server. A reponse to the STUN request, whether it is a success or error response, carries the same transaction ID as the request. Unless a request is bit-wise identical to a previous request, and was sent to the same server from the same transport address, a client MUST choose a new transaction ID for it. Indications are also identified by their transaction ID. The transaction ID there MUST also be uniformly and randomly distributed between 0 and 2**96 - 1. The value is chosen by the sender of the indication, and MUST be unique for each unique indication generated by the sender. para 12 (begins "The Length...") s/attributes whose content is not a multiple of 4 bytes are padded with 1, 2 or 3 bytes of padding so that they are a multiple of 4 bytes. /any attribute whose content is not a multiple of 4 bytes is padded with 1, 2 or 3 bytes of padding so that its value contains a multiple of 4 bytes./ Sect 8 para 1 is really wrong. You only obtain a shared secret for some usages and obtaining the shared secret involves its own discovery step (never mentioned). I propose just deleting this whole paragraph. Sect 8.1 para 5 s/is set up is a/is set up, is a/ para 6 s/The application usage/Each application usage/ last para. replace with: Each STUN usage describes if shared secrets are employed by that usage and any additional rules for obtaining those shared secrets. Sect 8.3.1 para 5 (begins "3. If a long...") s/were/is/g para 10 (begins "For TCP and TLS...") s/to send further requests/to send or receive further data over this connection. The STUN usage may provide additional guidance about connection lifetime management./ _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Dec 06 19:45:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs7Ng-0005A5-MZ; Wed, 06 Dec 2006 19:44:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs7Ne-00059x-Sy for behave@ietf.org; Wed, 06 Dec 2006 19:44:54 -0500 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs7Ne-0004e7-BR for behave@ietf.org; Wed, 06 Dec 2006 19:44:54 -0500 Received: by ug-out-1314.google.com with SMTP id 72so291212ugd for ; Wed, 06 Dec 2006 16:44:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=kzqla88Gf548MNaLd15Vmcaxi7Nm0+ZMWQvlMNNc43PQ8sV+QoPr82jzdIo0XJQuZl+DHc5IBKijJv+YV/KHWihpY0eikBmgTAcNqQYXzbd8C80CSjfTKXdGeuUrX5iir8eLbWcrmGPk7IO5rpN9VD1SlFLiqEd6l13vICYsGtI= Received: by 10.78.204.1 with SMTP id b1mr1187283hug.1165452292853; Wed, 06 Dec 2006 16:44:52 -0800 (PST) Received: by 10.78.120.15 with HTTP; Wed, 6 Dec 2006 16:44:52 -0800 (PST) Message-ID: <953beacc0612061644y5fa7514ha178f0b243090c32@mail.gmail.com> Date: Wed, 6 Dec 2006 16:44:52 -0800 From: "Rohan Mahy" To: behave@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: Rohan Mahy , Dan Wing Subject: [BEHAVE] STUN comments part 2 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, Below are the rest of my STUN comments. thanks, -rohan STUN comments part 2 Substantive Comments 6) Sect 9.1.1 paras 8 and 12. Is a NONCE attribute required in a 438 response? The spec should say explicitly either way. 7a) We never actually define the semantics of the requests. I think we should insert a short section that defines the two methods and says which method-specific attributes MUST and MUST NOT be in these requests and responses. I consider MAPPED-ADDRESS, XOR-MAPPED-ADDRESS, REFRESH-INTERVAL, and PASSWORD to be method-specific. This doesn't mean I can't use them in a new method, but just that they don't have meaning automatically for all methods. 7b) I'd like to completely delete Figure 5 and the paragraph immediately prior, and the 2nd para of 12.3.4 and its table. We always get these kind of tables wrong and many implementors hate reading them. The implementors that do implement to the table tend to blindly implement our mistakes without considering context. I think this has been a disaster in the SIP spec and I do not want to repeat that train wreck. 8) In Section 11, I think it would be useful to put the attribute number in each subsection of 11. Also, I propose putting XOR-MAPPED-ADDRESS immediately after MAPPED-ADDRESS for improved flow. 9) Sect 11.1 para 5 and para 6. Why are we still using X-Port? No known generic NAT rewrites bare port numbers. This serves no purpose. NITS Sect 8.3.2 paras 1 and 2 - reword PROPOSED: When the client receives a response, first the client verifies that the transaction ID of the response matches a request sent by the client. If the client cannot find a matching request, it discards the response. Next the client checks if it already accepted a response for the corresponding request. Once the client has accepted a response to a request, the client ignores any additional responses to that request. This allows the client to discard retransmissions of responses and other spurious responses. At this point the client SHOULD check the response for a MESSAGE-INTEGRITY attribute. etc... para 3 (just append this sentence to the previous para) para 5 s/and had not included a MESSAGE-INTEGRITY attribute in the request, it is an indication from the server that credentials are required. /and did not include a MESSAGE-INTEGRITY attribute in the request, the server is indicating that credentials are required./ para 7 s/had omitted/omitted/ para 9 s/DNS procedures defined above/DNS discovery procedures defined in Section 12.3.2/ para 10 PROPOSED For a 431 (Integrity Check Failure) response code, the client SHOULD alert the user. If a short term credential obtained from a Shared Secret request was used previously, the client MAY obtain a new short term username and password and retry the request again. para 12 s/REALMS were equal/REALM attributes are the same/ para 14 PROPOSED If an authentication-related error response contains a NONCE attribute and the client retries the corresponding request, the client MUST include the NONCE in the resulting subsequent request. Furthermore the client SHOULD cache the NONCE, and continue using that nonce in subsequent request to the same server (as identified by its transport address). Sect 8.4 para 5 (begins "Typically, indication messages...") Delete the second sentence. We have no usage for the DNS discovery for standalone indications. If we need this type of new behavior we can introduce it in a new usage. Sect 9 As with clients, server behavior depends on whether the server receives a request or an indication. Sect 9.1.1 para 2 s/If the request/If a received request/ para 3 s/the server determines/the server optionally determines/ para 8 OLD: If the REALM attribute was present and the server is using a long term credential for authentication, the server checks for the existence of the NONCE attribute. If the NONCE attribute is not present, the server MUST generate an error response. That error response MUST include an ERROR-CODE attribute with a response code of 435 (Missing Nonce). That error response MUST include a REALM attribute. If the NONCE was absent and the server is authenticating with short term credentials, the server MAY generate an error response with an ERROR-CODE attribute with a response code of 435 (Missing Nonce). This response MUST include a NONCE. If the NONCE was present in the request, but the server has determined it is stale, the server MUST generate an error response with an ERROR-CODE attribute with a response code of 438 (Stale Nonce). PROPOSED: If the REALM attribute was present and the server is using a long term credential for authentication, the server checks for the existence of the NONCE attribute. If the NONCE attribute is not present, the server MUST generate an error response. That error response MUST include an ERROR-CODE attribute with a response code of 435 (Missing Nonce). That error response MUST include a REALM attribute. This response MUST include a NONCE. If the NONCE was absent and the server is authenticating with short term credentials, the server MAY generate an error response with an ERROR-CODE attribute with a response code of 435 (Missing Nonce). This response MUST include a NONCE. If a NONCE attribute was present in the request, but the server has determined it is stale, the server MUST generate an error response with an ERROR-CODE attribute with a response code of 438 (Stale Nonce). This can apply to authentication with either short-term or long-term credentials. para 11 s/from the one from the/from the HMAC in the/ Sect 9.1.2 para 3 and 4, move these to the Binding Discovery usage. (The Keepalive usage will always use XOR-MAPPED-ADDRESS and the magic cookie.) Sect 9.1.3 s/TCP connections that the request arrived on/TCP connections over which the corresponding request arrived/ Sect 9.2 1st para 1st sentence. Indication messages don't necessarily change the state of the server. Certainly this is the case with TURN Data and Send indications. I propose just delete this sentence. Sect 10, 1st para s/In the binding refresh usage/In the Keepalive usage/ Sect 11.5 s/xor-d/XORed/ Sect 11.8 Append "Quotes are not included in the NONCE Value." Sect 11.1 para 2 - replace 1st sentence with: This attribute MUST always be present in a Binding Response if the Binding Request contained the STUN magic cookie. This attribute can be used in other responses as well as specified in the method definition. Sect 11.13 1st para s/provies/provides/ Sect 12 para 3 s/standards-track/IETF Consensus/ Sect 12.1 This sentence is completely wrong, and completely unhelpful. RFC 3489 also described the Shared Secret usage. Delete the entire sentence. Sect 12.1.1 para 4 s/protocol data unit/application payload/ para 5 s/Real Time Control Protocol/Real-time Transport Control Protocol/ para 6 s/in the PDU/in the application payload/ Section 12.1.2 SRV service name strings 'stun' should be introduced here in Sections 12.1.2 instead of in 8.1 Sect 12.1.7 para 1 s/PDU/payload/ s/then using in/then used in/ para 2 s/version of the server/version of the server reached by the client/ Sect 12.2.1 para 1 s/(for example, a SIP proxy server)// [A proxy is not an example of a *protocol*] para 2 s/The client can also/For UDP, the client can also/ Sect 12.2.3 PROPOSED: The server multiplexes both STUN and its application protocol on the same port. The server knows to enable this usage because use of STUN with this application protocol was negotiated or discovered. Sect 12.3 s/In order to ensure interoperability, this usage/This usage/ [The whole point of this spec is to ensure interop] Sect 12.3.6 PROPOSED: No new error response codes are defined by this usage. [433 is already defined with all the rest of the error codes] Sect 12.3.7 para 3 s/If the response was a/If the response is a/ Sect 12.3.8 last para s/SHOULD be better than/SHOULD be smaller than/ Sect 12.3.9 para 4 s/on an Least/on a Least/ last para s/with using/with, using/ Sect 13 s/However, all of the other usages/However, the other two usages/ Sect 15.2 FINGERPRINT and ALTERNATE-SERVER conflict. Sect 16, 5th bullet s/0b00/zero/ insert into bulleted list "Introduced the concept of Indications." _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Dec 06 19:55:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs7XO-0000sQ-M1; Wed, 06 Dec 2006 19:54:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs7XO-0000sL-1E for behave@ietf.org; Wed, 06 Dec 2006 19:54:58 -0500 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs7XL-0006UK-LO for behave@ietf.org; Wed, 06 Dec 2006 19:54:58 -0500 Received: by ug-out-1314.google.com with SMTP id 72so293188ugd for ; Wed, 06 Dec 2006 16:54:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Lm66GQHOSDJpVO0jn0Kq19bhTOo4+yFlRKr4oFe7Xhr53nAvA2xikUf1cAYVLmBGBHstZ7b9AbydqT2DExuwolARcnd6v7X3BgaeibhXlbT8W02/ErPVXGi/N6AzJQv7tdju/tCisbWsPy+SwwlK+ialIJ9eGngnTc7x+WkIEjk= Received: by 10.78.136.9 with SMTP id j9mr1216238hud.1165452893976; Wed, 06 Dec 2006 16:54:53 -0800 (PST) Received: by 10.78.120.15 with HTTP; Wed, 6 Dec 2006 16:54:53 -0800 (PST) Message-ID: <953beacc0612061654v1d63e22fj4bd8d700b48a08d4@mail.gmail.com> Date: Wed, 6 Dec 2006 16:54:53 -0800 From: "Rohan Mahy" To: "Hisham Khartabil" Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <004e01c71316$1de5b4b0$1c00a8c0@Codalogic> X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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 I like Hisham's choices, especially: Session Traversal through Ubiquitous NATs thanks, -rohan On 11/30/06, Hisham Khartabil wrote: > Session Traversal for Users of NAT > Session Traversal through Ubiquitous NATs > > For the S, you can also use Sophisticated or Smooth, but maybe not > Simple ;) > > Hisham > > On Nov 29, 2006, at 9:36 PM, Philip Matthews wrote: > > > If we are going to do this, then I would prefer "Session Traversal > > through NAT". > > I don't see how "underneath" is really appropriate either. > > No one talks about sending a packet or a media session "underneath" a > > NAT. > > > > - Philip > > > > On 28-Nov-06, at 12:53 , Pete Cordell wrote: > > > >> I jested before, but the more I think about it, the more I find the > >> 'simple' in the STUN name irksome. > >> > >> STUN now is really (potentially) STUN + TURN of old. I don't see how > >> that combination can be called simple. Granted, it's not hugely > >> complex, but it is not HTTP 0.9 either! Between the two of them > >> there are 14 different types of message and 24 different attributes. > >> > >> Further, STUN on it's own isn't much good. In reality the STUN base > >> specs are just the message definitions, whereas ICE is how to use > >> those messages. Together there is 185 pages of documentation, which I > >> don't consider to be simple. (SIP is 269 pages and I don't think we > >> can argue that is simple. Thus STUN + usage is of comparable > >> complexity; to document at least.) > >> > >> But the thing I hate most about it though is the marketing spin feel > >> of it! Use this and your teeth will be whiter than white and it won't > >> cost you a penny! > >> > >> Actually, I think the word 'simple' should be avoided in all acronyms > >> as a matter of policy. Even if something starts out simple, if it's > >> useful it gets added to and evolves into something that is no longer > >> simple. Is SMTP still simple? > >> > >> Thus, I put to the floor that the acronym for STUN should expand to: > >> > >> Session Traversal Underneath NAT, > >> > >> and further request that statements such as "STUN is a simple ... > >> protocol" be removed from the spec. (Just use "STUN is a ... > >> protocol"). > >> > >> Pete. > >> -- > >> ============================================= > >> Pete Cordell > >> Tech-Know-Ware Ltd > >> for XML to C++ data binding visit > >> http://www.tech-know-ware.com/lmx > >> (or http://www.xml2cpp.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 > > > > > _______________________________________________ > 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 Dec 06 20:11:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs7ml-0000FW-1r; Wed, 06 Dec 2006 20:10:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs7mj-0000FO-DF for behave@ietf.org; Wed, 06 Dec 2006 20:10:49 -0500 Received: from lambda.sipfoundry.org ([72.232.205.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs7mg-0008Lu-RU for behave@ietf.org; Wed, 06 Dec 2006 20:10:49 -0500 Received: from mx3-1.spamtrap.magma.ca (mx3-1.spamtrap.magma.ca [209.217.78.168]) by lambda.sipfoundry.org (8.13.8/8.13.8) with ESMTP id kB71AgJK022495 for ; Wed, 6 Dec 2006 19:10:46 -0600 (CST) (envelope-from philip_matthews@magma.ca) Received: from mail1.magma.ca (mail1.internal.magma.ca [10.0.10.11]) by mx3-1.spamtrap.magma.ca (8.13.0/8.13.1) with ESMTP id kB71Ab05022404; Wed, 6 Dec 2006 20:10:37 -0500 Received: from [192.168.1.71] ([216.13.42.66]) (authenticated bits=0) by mail1.magma.ca (Magma's Mail Server) with ESMTP id kB71Aaa9026931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 6 Dec 2006 20:10:37 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: From: Philip Matthews Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT Date: Wed, 6 Dec 2006 20:11:23 -0500 To: Benny Rodrig X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: ietf-behave@list.sipfoundry.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: , Content-Type: multipart/mixed; boundary="===============1749811430==" Errors-To: behave-bounces@ietf.org --===============1749811430== Content-Type: multipart/alternative; boundary=Apple-Mail-7-315606418 --Apple-Mail-7-315606418 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I agree that this is a nice one. - Philip On 6-Dec-06, at 02:13 , Mayank Dev Sondhi wrote: > Nice, I spent quite a lot of time thinking of words beginning with > "U" until finally giving up. > > On 12/6/06, Rodrig, Benny (Benny) wrote: > How about "Session Traversal Utilities for NAT"? Similar to "set of > tools" but still keeping the meaningful "traversal". > > -----Original Message----- > From: Pete Cordell [mailto:pete.cordell@tech-know-ware.com] > Sent: Friday, December 01, 2006 5:43 PM > To: Francois Audet; Jonathan Rosenberg > Cc: ietf-behave@list.sipfoundry.org > Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT > > Excellent. All sorted. > > Pete. > ----- Original Message ----- > From: "Francois Audet" > To: "Jonathan Rosenberg" ; "Pete Cordell" > > Cc: "Philip Matthews" ; > < ietf-behave@list.sipfoundry.org> > Sent: Friday, December 01, 2006 10:09 PM > Subject: RE: [BEHAVE] STUN -> Session Traversal Underneath NAT > > > Thanks. > > By the way, I got the idea by reading the Abstract which pretty much > says exactly that. > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > Sent: Friday, December 01, 2006 14:01 > > To: Pete Cordell > > Cc: Philip Matthews; Audet, Francois (SC100:3055); > > ietf-behave@list.sipfoundry.org > > Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT > > > > Ahhh. Nothing brings out opinions like a naming debate. > > > > I think Francois got it right. I'd prefer "STUN: Set of Tools Useful > > for NAT". I like semi-derogatory things like Uncorking and > Unblocking > > more for working group names (which is an IETF insider thing) and > not > > protocol names (which are read by everyone). > -- > ============================================= > Pete Cordell > Tech-Know-Ware Ltd > for XML to C++ data binding visit > http://www.tech-know-ware.com/lmx > (or http://www.xml2cpp.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 > --Apple-Mail-7-315606418 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 I agree that this is a nice = one.
- Philip

On 6-Dec-06, at 02:13 , = Mayank Dev Sondhi wrote:

Nice, I = spent quite a lot of time thinking of words beginning with "U" until = finally giving up.

On 12/6/06, = Rodrig, Benny (Benny) <brodrig@avaya.com> = wrote:
How about = "Session Traversal Utilities for NAT"? Similar to "set of
tools" but = still keeping the meaningful "traversal".

-----Original = Message-----
From: Pete Cordell [mailto:pete.cordell@tech-know-war= e.com]
Sent: Friday, December 01, 2006 5:43 PM
To: Francois = Audet; Jonathan Rosenberg
Cc: ietf-behave@list.sipfoundr= y.org
Subject: Re: [BEHAVE] STUN -> Session Traversal = Underneath NAT

Excellent.=A0=A0All sorted.

Pete.
----- = Original Message -----
From: "Francois Audet" <audet@nortel.com>
To: = "Jonathan Rosenberg" <jdrosen@cisco.com>; "Pete = Cordell"
<pete.cordell@tech-know-war= e.com>
Cc: "Philip Matthews" <philip_matthews@magma.ca>;=
< = ietf-behave@list.sipfoundry.org>
Sent: Friday, December 01, = 2006 10:09 PM
Subject: RE: [BEHAVE] STUN -> Session Traversal = Underneath NAT


Thanks.

By the way, I got the idea by = reading the Abstract which pretty much
says exactly = that.

> -----Original Message-----
> From: Jonathan = Rosenberg [mailto:jdrosen@cisco.com]
> Sent: = Friday, December 01, 2006 14:01
> To: Pete Cordell
> Cc: = Philip Matthews; Audet, Francois (SC100:3055);
> ietf-behave@list.sipfoundr= y.org
> Subject: Re: [BEHAVE] STUN -> Session Traversal = Underneath NAT
>
> Ahhh. Nothing brings out opinions like a = naming debate.
>
> I think Francois got it right. I'd prefer = "STUN: Set of Tools Useful
> for NAT". I like semi-derogatory = things like Uncorking and Unblocking
> more for working group = names (which is an IETF insider thing) and not
> protocol names = (which are read by = everyone).
--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
Pete Cordell
Tech-Know-Ware Ltd
for XML to C++ data = binding visit
http://www.tech-know-ware.com/l= mx
(or http://www.xml2cpp.com)
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =



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


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


<= /HTML>= --Apple-Mail-7-315606418-- --===============1749811430== 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 --===============1749811430==-- From behave-bounces@ietf.org Thu Dec 07 11:02:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsLhz-0008Ve-1X; Thu, 07 Dec 2006 11:02:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsLhx-0008Ut-Um for behave@ietf.org; Thu, 07 Dec 2006 11:02:49 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsLhc-0001yc-GO for behave@ietf.org; Thu, 07 Dec 2006 11:02:49 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 07 Dec 2006 08:02:26 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id kB7G2QfR032221 for ; Thu, 7 Dec 2006 08:02:26 -0800 Received: from dwingwxp ([10.32.240.194]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kB7G2POV029775 for ; Thu, 7 Dec 2006 08:02:25 -0800 (PST) From: "Dan Wing" To: Date: Thu, 7 Dec 2006 08:02:25 -0800 Message-ID: <096f01c71a19$168136e0$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccaGRYQS+29D2zxTmGaSGJxfcBOlQ== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=243; t=1165507346; x=1166371346; c=relaxed/simple; s=sjdkim7002; 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:=20adopt=20draft-macdonald-behave-nat-behavior-discovery-00.txt |Sender:=20; bh=zP07WV4A7WpEjsa9UXE1DZnfv7B9MyIaQLqDpLfnPUk=; b=QoWsu/gNlmS0BMZIUvt0wGtzZ7mrONT2XwkRz2qw8tsVqlGIV42/XjFEqYDzRy9oqkOSk1DJ 8a4ryw7K2+t/1QmlgIolE7a0ha1vWdQ3Nyg3p8LqhmP5bPt5Wku+mAlr; Authentication-Results: sj-dkim-7; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [BEHAVE] adopt draft-macdonald-behave-nat-behavior-discovery-00.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 In San Diego, there was consensus to adopt draft-macdonald-behave-nat-behavior-discovery-00.txt as a working group document. If anyone has changed their mind, or wishes to express their opinion about this document, please speak up. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 07 17:40:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsRtu-0008EI-CP; Thu, 07 Dec 2006 17:39:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsRtt-0008EC-BI for behave@ietf.org; Thu, 07 Dec 2006 17:39:33 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsRts-0003G8-2e for behave@ietf.org; Thu, 07 Dec 2006 17:39:33 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kB7MdSm27725; Thu, 7 Dec 2006 17:39:28 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] adopt draft-macdonald-behave-nat-behavior-discovery-00.txt Date: Thu, 7 Dec 2006 16:39:24 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E554980@zrc2hxm0.corp.nortel.com> In-Reply-To: <096f01c71a19$168136e0$c2f0200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] adopt draft-macdonald-behave-nat-behavior-discovery-00.txt thread-index: AccaGRYQS+29D2zxTmGaSGJxfcBOlQAN2RmA From: "Francois Audet" To: "Dan Wing" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 strongly favor adopting this document. I find it will be very useful. =20 > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: Thursday, December 07, 2006 08:02 > To: behave@ietf.org > Subject: [BEHAVE] adopt=20 > draft-macdonald-behave-nat-behavior-discovery-00.txt >=20 > In San Diego, there was consensus to adopt=20 > draft-macdonald-behave-nat-behavior-discovery-00.txt as a=20 > working group document. If anyone has changed their mind, or=20 > wishes to express their opinion about this document, please speak up. >=20 > -d >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave >=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 07 18:33:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsSkH-0006b0-P9; Thu, 07 Dec 2006 18:33:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsSkG-0006ap-ST for behave@ietf.org; Thu, 07 Dec 2006 18:33:40 -0500 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsSkF-0003yJ-K4 for behave@ietf.org; Thu, 07 Dec 2006 18:33:40 -0500 Received: by ug-out-1314.google.com with SMTP id 72so557861ugd for ; Thu, 07 Dec 2006 15:33:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=TYSHNTV/KBRL2mUFYE6zZbWNLTPbOrn1Gp3xh/Il9JxEHP/zWBGJJ7ZukbR+Ue/CUsiloYwlv0rwks7XQytOhy9o95MmR7FDhocZ+Br8qQiGVCoQp7ugM4nCYsZ38rr66OFmxbq0v+KhQJmYkQfdfR3Nv8hj+r/yaoEXGf47RhQ= Received: by 10.78.39.16 with SMTP id m16mr1665789hum.1165534418262; Thu, 07 Dec 2006 15:33:38 -0800 (PST) Received: by 10.78.120.15 with HTTP; Thu, 7 Dec 2006 15:33:38 -0800 (PST) Message-ID: <953beacc0612071533t3d9abb6ldb2a1a0c5f75d27e@mail.gmail.com> Date: Thu, 7 Dec 2006 15:33:38 -0800 From: "Rohan Mahy" To: behave@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Rohan Mahy Subject: [BEHAVE] STUN error code repository 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, I think rfc3489bis should also include an error code repository: thanks, -rohan Code Description ---- ----------- 300 Try Alternate 400 Bad Request 401 Unauthorized 420 Unknown Attribute 430 Stale Credentials 431 Integrity Check Failure 432 Missing Username 433 Use TLS 434 Missing Realm 435 Missing Nonce 436 Unknown Username 438 Stale Nonce 500 Server Error 600 Global Failure _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Dec 10 17:36:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtXFl-0005EQ-IS; Sun, 10 Dec 2006 17:34:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtXFk-0005EF-Nz for behave@ietf.org; Sun, 10 Dec 2006 17:34:36 -0500 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtXFj-0007qY-UF for behave@ietf.org; Sun, 10 Dec 2006 17:34:36 -0500 Received: by nf-out-0910.google.com with SMTP id h2so1780231nfe for ; Sun, 10 Dec 2006 14:34:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=A4Sl/J3N8YBmI1FFVASMC29JIQrr1RkaNHK1jKIuJZ+inRBVOGWDo2VH9ItiKDyriNUfGHPV94AYbMEjLzumxJfFku+s+89xM3selAlAdH8N0H/BIPD8Y/6DhML289/VT55xO65ufJWcjK12/UU3pKD1+bl+c69KPUXs3Ospoko= Received: by 10.48.216.8 with SMTP id o8mr3633938nfg.1165790074724; Sun, 10 Dec 2006 14:34:34 -0800 (PST) Received: by 10.49.28.8 with HTTP; Sun, 10 Dec 2006 14:34:34 -0800 (PST) Message-ID: Date: Sun, 10 Dec 2006 14:34:34 -0800 From: "Derek MacDonald" To: behave@ietf.org MIME-Version: 1.0 X-Google-Sender-Auth: 952344e70d0b54c3 X-Spam-Score: 0.3 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Subject: [BEHAVE] Comments on rfc3489bis-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0074789270==" Errors-To: behave-bounces@ietf.org --===============0074789270== Content-Type: multipart/alternative; boundary="----=_Part_95545_2842774.1165790074682" ------=_Part_95545_2842774.1165790074682 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I tried not to have too much overlap with other reviewers, but there will be some. General Comments I don't think the NONCE attribute should be optional. As every client implementation will need to support it, unless they only in deployment s where only short term credentials without a NONCE are used. Having NONCE be mandatory for short-lived and long-lived credentials would: 1. Simplify the implementation of clients that implement the full specification 2. Allow short-term credentials to be longer lived, as the NONCE would provide temporal scoping. For example, having a short-term credential could last a day or multiple days would greatly reduce the TLS load on the STUN server. Specific Substantive Comments 7.1 Retransmissions continue until a response is received, or a total of 7 requests have been sent. If no response is received by 1.6 seconds after the last request has been sent, the client SHOULD consider the transaction to have failed. I don't really understand the 1.6 second value; the retransmission interval is RTT based, shouldn't the time that a client waits after the last request also be RTT based? What is the motivation for 1.6 seconds? Similarly in: When running STUN over TCP, TCP is responsible for ensuring delivery. The STUN application SHOULD NOT retransmit STUN requests when running over TCP. If the client has not received a response after 7900ms, it considers the transaction to have timed out. where does the value of 7900ms for TCP come from? It may be correct, but it is not motivated. 8.3.2 Unknown optional attributes in a response (greater than 0x7FFF) MUST be ignored by the STUN client. Responses containing unknown mandatory attributions (less than or equal to 0x7FFF) MUST be discarded and considered immediately as a failed transaction. /s/attributions/attributes This paragraph contradicts the decision we made at the ietf to have servers which are implementing the Nat discovery usage always return OTHER-ADDRESS in a binding response. One solution is to add OTHER-ADDRESS as a known attribute to 3489bis. We could also move OTHER-ADDRESS into the optional attribute range, but this will break backwards compatibility with existing 3489 servers used for discovery(OTHER-ADDRESS is CHANGED-ADDRESS renamed, the value is still 0x0005). Editorial Comments 5. Some usages (such as the binding keepalive) require STUN messages to be sent on the same transport address as some application protocol, such as RTP or SIP. To facilitate the demultiplexing of the two, STUN defines a special field in the message called the magic cookie, which is a fixed 32 bit value that identifies STUN traffic. STUN requests also contain a fingerprint, which is a cryptographic hash of the message, that allow for validation that the message was a STUN request and not a data packet that happened to have the same 32 bit value in the right place in the message. The motivation of having both the fingerprint attribute and the magic cookie should be summarized; it is explained several times later on in the document(ex 8.3.1). Suggested paragraph: Some usages (such as the binding keepalive) require STUN messages to be sent on the same transport address as some application protocol, such as RTP or SIP. To facilitate the demultiplexing of the two, STUN defines a special field in the message called the magic cookie, which is a fixed 32 bit value that identifies STUN traffic. STUN also defines an optional fingerprint attribute, which can be used when application protocol messages may contain a binary value which is equal to the magic cookie. The fingerprint is a cryptographic hash of the message, that allow for validation that the message was a STUN request and not a data packet that happened to have the same 32 bit value in the right place in the message. 6. The sentence: Unless a request or indication is bit-wise identical to a previous request, and was sent to the same server from the same transport address, a client MUST choose a new transaction ID for it. could be reworded to: Unless a request is a retransmission a client MUST choose a new transaction ID for it. A different transaction id MUST be used for each indication. AFAIK, indications are never retransmitted, and retransmissions are the only reason to re-send a request with the same tid. 7.2 Indication failures should only be retried if it is appropriate for the usage; it would not be appropriate for the relay usage, which is the only usage that defines indications so far. Maybe the onus should be on a usage to define whether indications should be retransmitted to alternate servers? 8.3.1 When STUN is being multiplexed on the same transport address as application data, and there are valid application layer data packets which could be confused with STUN packets (because, for example, bits 32 through 63 can contain an arbitrary binary value which might be equal to 0x2112A442), the FINGERPRINT attribute MUST be present. Otherwise, its inclusion is RECOMMENDED. Contradicts section 10, specifically the sentence: If this probability is deemed sufficiently small for the application at hand (for example, it is considered adequate for Voice over IP applications), then any packet with this value in its second 32 bit word is processed as a STUN packet. Possibly reword to: the FINGERPRINT attribute MUST be present if one in 2^32 application protocol packets being interpreted as STUN is not acceptable. Otherwise, its inclusion is RECOMMENDED. 8.3.2 If the client receives a 432 (Missing Username) response, and the client had omitted the USERNAME from the request but included a MESSAGE-INTEGRITY, the client SHOULD retry the request and include both MESSAGE-INTEGRITY and USERNAME. If the client receives a 432 (Missing Username) but had included both MESSAGE-INTEGRITY and USERNAME in the request, there has been an unrecoverable error. This shouldn't ever happen, but if it does, the client SHOULD NOT retry the request. A client missing the username but including message is an implementation error in the client. We should not describe recovery behaviour for this situation, just state that the client is not to spec. I'm not sure if we need separate error codes for this type of implementation error, or just an illegal message error code where the text string describes the error, but I don't feel strongly about this. 11.7 Having a value which is always a quoted string seems odd as the quotes have no semantics. Don't really care. 11.10 This attribute MUST always be present in a Binding Response and may be used in other responses as well. Usages defining new requests and responses should specify if XOR-MAPPED-ADDRESS is applicable to their responses. This MUST only holds if the client supports 3489bis; other wise MAPPED-ADDRESS must be used. Maybe: This attribute MUST always be present in a Binding Response when the client supports this specification and may... 12.2.3 The server would know it is running the keepalive usage because of its implementation of configuration; inspection of its own uri to determine this is unlikely. I suggest removing 12.2.3 completely. 12.3.6. This usage defines the 433 error response. Only the MESSAGE- INTEGRITY, ERROR-CODE and SERVER attributes are applicable to this response. /s/the 433/the 433(UseTLS) -Derek ------=_Part_95545_2842774.1165790074682 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I tried not to have too much overlap with other reviewers, but there will be some.

General Comments

I don't think the NONCE attribute should be optional.  As every client implementation will need to support it, unless they only in deployment s where only short term credentials without a NONCE are used. Having  NONCE be mandatory for short-lived and long-lived credentials would:

1. Simplify the implementation of clients that implement the full specification
2. Allow short-term credentials to be longer lived, as the NONCE would provide temporal scoping. For example, having a short-term credential could last a day or multiple days would greatly reduce the TLS load on the STUN server.

Specific Substantive Comments

7.1

   Retransmissions continue until a response is received, or a total of
   7 requests have been sent.  If no response is received by 1.6 seconds
   after the last request has been sent, the client SHOULD consider the
   transaction to have failed.

I don't really understand the 1.6 second value; the retransmission interval is RTT based, shouldn't the time that a client waits after the last request also be RTT based?  What is the motivation for 1.6 seconds?

Similarly in:

   When running STUN over TCP, TCP is responsible for ensuring delivery.
   The STUN application SHOULD NOT retransmit STUN requests when running
   over TCP.  If the client has not received a response after 7900ms, it
   considers the transaction to have timed out.

where does the value of 7900ms  for TCP come from? It may be correct, but it is not motivated.

8.3.2

    Unknown optional attributes in a response (greater than 0x7FFF) MUST
    be ignored by the STUN client.  Responses containing unknown
    mandatory attributions (less than or equal to 0x7FFF) MUST be
    discarded and considered immediately as a failed transaction.

/s/attributions/attributes

This paragraph contradicts the decision we made at the ietf to have servers which are implementing the Nat discovery usage always return OTHER-ADDRESS in a binding response.  One solution is to add OTHER-ADDRESS as a known attribute to 3489bis.  We could also move OTHER-ADDRESS into the optional attribute range, but this will break backwards compatibility with existing 3489 servers used for discovery(OTHER-ADDRESS is CHANGED-ADDRESS renamed, the value is still 0x0005).

Editorial Comments

5.

   Some usages (such as the binding keepalive) require STUN messages to
   be sent on the same transport address as some application protocol,
   such as RTP or SIP.  To facilitate the demultiplexing of the two,
   STUN defines a special field in the message called the magic cookie,
   which is a fixed 32 bit value that identifies STUN traffic.  STUN
   requests also contain a fingerprint, which is a cryptographic hash of
   the message, that allow for validation that the message was a STUN
   request and not a data packet that happened to have the same 32 bit
   value in the right place in the message.

The motivation of having both the fingerprint attribute and the magic cookie should be summarized; it is explained several times later on in the document(ex 8.3.1). Suggested paragraph:

   Some usages (such as the binding keepalive) require STUN messages to
   be sent on the same transport address as some application protocol,
   such as RTP or SIP.  To facilitate the demultiplexing of the two,
   STUN defines a special field in the message called the magic cookie,
   which is a fixed 32 bit value that identifies STUN traffic.  STUN also defines an
   optional fingerprint attribute, which can be used when application protocol messages may contain a
   binary value which is equal to the magic cookie. The fingerprint is a cryptographic hash of
   the message, that allow for validation that the message was a STUN
   request and not a data packet that happened to have the same 32 bit
   value in the right place in the message.

6. The sentence:

   Unless a request or indication is bit-wise identical to a
   previous request, and was sent to the same server from the same
   transport address, a client MUST choose a new transaction ID for it.

could be reworded to:

  Unless a request is a retransmission a client MUST choose a new transaction ID for it. A different transaction id MUST be used for
  each indication.

AFAIK, indications are never retransmitted, and retransmissions are the only reason to re-send a request with the same tid.

7.2 Indication failures should only be retried if it is appropriate for the usage; it would not be appropriate for the relay usage, which is the only usage that defines indications so far.  Maybe the onus should be on a usage to define whether indications should be retransmitted to alternate servers?

8.3.1
   When STUN is being multiplexed on the same transport address as
   application data, and there are valid application layer data packets
   which could be confused with STUN packets (because, for example, bits
   32 through 63 can contain an arbitrary binary value which might be
   equal to 0x2112A442), the FINGERPRINT attribute MUST be present.
   Otherwise, its inclusion is RECOMMENDED.

Contradicts section 10, specifically the sentence:

   If this probability is deemed sufficiently small for the application at hand (for
   example, it is considered adequate for Voice over IP applications),
   then any packet with this value in its second 32 bit word is
   processed as a STUN packet.

Possibly reword to:
  the FINGERPRINT attribute MUST be present if one in 2^32 application protocol packets being interpreted as STUN is not acceptable.  
  Otherwise, its inclusion is RECOMMENDED.

8.3.2

   If the client receives a 432 (Missing Username) response, and the
   client had omitted the USERNAME from the request but included a
   MESSAGE-INTEGRITY, the client SHOULD retry the request and include
   both MESSAGE-INTEGRITY and USERNAME.  If the client receives a 432
   (Missing Username) but had included both MESSAGE-INTEGRITY and
   USERNAME in the request, there has been an unrecoverable error.  This
   shouldn't ever happen, but if it does, the client SHOULD NOT retry
   the request.

A client missing the username but including message is an implementation error in the client.  We should not describe recovery behaviour for this situation, just state that the client is not to spec.

I'm not sure if we need separate error codes for this type of implementation error, or just an illegal message error code where the text string describes the error, but I don't feel strongly about this.

11.7 Having a value which is always a quoted string seems odd as the quotes have no semantics.  Don't really care.

11.10

   This attribute MUST always be present in a Binding Response and may
   be used in other responses as well.  Usages defining new requests and
   responses should specify if XOR-MAPPED-ADDRESS is applicable to their
   responses.

This MUST only holds if the client supports 3489bis; other wise MAPPED-ADDRESS must be used. Maybe:

   This attribute MUST always be present in a Binding Response when the client supports this specification and may...

12.2.3

The server would know it is running the keepalive usage because of its implementation of configuration; inspection of its own uri to determine this is unlikely. I suggest removing 12.2.3 completely.

12.3.6.


   This usage defines the 433 error response.  Only the MESSAGE-
   INTEGRITY, ERROR-CODE and SERVER attributes are applicable to this
   response.

/s/the 433/the 433(UseTLS)

-Derek




------=_Part_95545_2842774.1165790074682-- --===============0074789270== 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 --===============0074789270==-- From behave-bounces@ietf.org Mon Dec 11 13:01:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtpST-000276-EO; Mon, 11 Dec 2006 13:00:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtpSS-00026w-DP for behave@ietf.org; Mon, 11 Dec 2006 13:00:56 -0500 Received: from buggy.corp.yahoo.com ([207.126.225.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtpSQ-0008Lr-2U for behave@ietf.org; Mon, 11 Dec 2006 13:00:56 -0500 Received: (from lloydh@localhost) by buggy.corp.yahoo.com (8.12.3/8.12.3) id kBBI0phD032470 for behave@ietf.org; Mon, 11 Dec 2006 10:00:51 -0800 (PST) (envelope-from lloydh) Date: Mon, 11 Dec 2006 10:00:51 -0800 From: Lloyd Hilaiel To: behave@ietf.org Message-ID: <20061211180051.GA31009@buggy.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [BEHAVE] TCP connection acceptance with TCP + STUN Relay 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 know drafts are in a state of flux at the moment, so I hope this question is relevant... in draft-ietf-behave-turn-02.txt: 13.1.1 TCP Processing If a server receives a TCP connection request on an allocated TCP transport address, it checks the permissions associated with that allocation. If the source IP address of the TCP SYN packet match one of the permissions, the TCP connection is accepted. Otherwise, it is rejected. What does rejected mean in this sense? I'm assuming that it means the SYN is dropped and NOT that a RST is sent? Meaning the peer will continue sending SYN packets until connection timeout is hit? The reason I assume this behavior is because there's no connection retry logic in draft-ietf-mmusic-ice-tcp-02.txt. And in the case where the offerer (and relay _client_) allocates relay addresses, the answerer (and relay _peer_) may initiate tcp connections toward these relay addresses before the offerer opens permissions via send indications. ? best, lloyd -- lloydh@yahoo-inc.com | serving to Internet http://docs.yahoo.com/info/values/ _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 12 04:35:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu42g-00024D-8e; Tue, 12 Dec 2006 04:35:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu42e-00023R-W5 for behave@ietf.org; Tue, 12 Dec 2006 04:35:16 -0500 Received: from smtp1.wanadoo.co.uk ([193.252.22.158] helo=smtp1.freeserve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu42a-00026l-E8 for behave@ietf.org; Tue, 12 Dec 2006 04:35:16 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3013.me.freeserve.com (SMTP Server) with ESMTP id 700E7B400089 for ; Tue, 12 Dec 2006 10:35:09 +0100 (CET) Received: from Codalogic (user-5445210e.lns4-c11.dsl.pol.co.uk [84.69.33.14]) by mwinf3013.me.freeserve.com (SMTP Server) with ESMTP id 1D42AB400087 for ; Tue, 12 Dec 2006 10:35:09 +0100 (CET) X-ME-UUID: 20061212093509119.1D42AB400087@mwinf3013.me.freeserve.com Message-ID: <003701c71dd0$d00e9c50$1c00a8c0@Codalogic> From: "Pete Cordell" To: Subject: Fw: [BEHAVE] STUN -> Session Traversal Underneath NAT Date: Tue, 12 Dec 2006 09:34:02 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.1 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a 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 Summarising back to the list... The final name selected by those that gave input is: Session Traversal Utilities for NAT Thanks to all those that contributed to the name. Pete. -- ----- Original Message ----- From: "Francois Audet" To: "Jonathan Rosenberg" Cc: "Pete Cordell" ; "Mayank Dev Sondhi" ; "Rodrig, Benny (Benny)" ; "Philip Matthews" Sent: Thursday, December 07, 2006 5:00 PM Subject: RE: [BEHAVE] STUN -> Session Traversal Underneath NAT Done deal. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Thursday, December 07, 2006 08:59 > To: Audet, Francois (SC100:3055) > Cc: Pete Cordell; Mayank Dev Sondhi; Rodrig, Benny (Benny); > Philip Matthews > Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT > > Its a tough call, but I have a slight preference for "Session > Traversal Utilities for NAT". I think its more or less saying > the same thing as "Set of Tools for Usage with NAT", but I do > like retaining "traversal". > So, if its OK, lets go with that. > > -Jonathan R. > > Francois Audet wrote: > > > I'll defer to Jonathan... > > > > I still think my definition was more "accurate" of what the > document > > does. > > > > > >>-----Original Message----- > >>From: Pete Cordell [mailto:pete@tech-know-ware.com] > >>Sent: Wednesday, December 06, 2006 01:22 > >>To: Mayank Dev Sondhi; Rodrig, Benny (Benny) > >>Cc: Audet, Francois (SC100:3055); Jonathan Rosenberg; > Philip Matthews > >>Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT > >> > >>Off list... > >> > >>Again, this is fine by me. I'm happy to leave it to Jonathan (or > >>Francois) to decide if they prefer this option. > >> > >>Pete. > >>-- > >>============================================= > >>Pete Cordell > >>Tech-Know-Ware Ltd > >>for XML to C++ data binding visit > >>http://www.tech-know-ware.com/lmx > >>(or http://www.xml2cpp.com) > >>============================================= > >> > >>----- Original Message ----- > >>From: "Mayank Dev Sondhi" > >>To: "Rodrig, Benny (Benny)" > >>Cc: "Pete Cordell" ; > >>"Francois Audet" > >>; "Jonathan Rosenberg" > ; "Philip > >>Matthews" ; > >> > >>Sent: Wednesday, December 06, 2006 7:13 AM > >>Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT > >> > >> > >> > >>>Nice, I spent quite a lot of time thinking of words > >> > >>beginning with "U" > >> > >>>until > >>>finally giving up. > >>> > >>>On 12/6/06, Rodrig, Benny (Benny) wrote: > >>> > >>>>How about "Session Traversal Utilities for NAT"? Similar > >> > >>to "set of > >> > >>>>tools" but still keeping the meaningful "traversal". > >>>> > >>>>-----Original Message----- > >>>>From: Pete Cordell [mailto:pete.cordell@tech-know-ware.com] > >>>>Sent: Friday, December 01, 2006 5:43 PM > >>>>To: Francois Audet; Jonathan Rosenberg > >>>>Cc: ietf-behave@list.sipfoundry.org > >>>>Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT > >>>> > >>>>Excellent. All sorted. > >>>> > >>>>Pete. > >>>>----- Original Message ----- > >>>>From: "Francois Audet" > >>>>To: "Jonathan Rosenberg" ; "Pete Cordell" > >>>> > >>>>Cc: "Philip Matthews" ; > >>>> > >>>>Sent: Friday, December 01, 2006 10:09 PM > >>>>Subject: RE: [BEHAVE] STUN -> Session Traversal Underneath NAT > >>>> > >>>> > >>>>Thanks. > >>>> > >>>>By the way, I got the idea by reading the Abstract which > >> > >>pretty much > >> > >>>>says exactly that. > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > >>>>>Sent: Friday, December 01, 2006 14:01 > >>>>>To: Pete Cordell > >>>>>Cc: Philip Matthews; Audet, Francois (SC100:3055); > >>>>>ietf-behave@list.sipfoundry.org > >>>>>Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT > >>>>> > >>>>>Ahhh. Nothing brings out opinions like a naming debate. > >>>>> > >>>>>I think Francois got it right. I'd prefer "STUN: Set of Tools > >>>>>Useful for NAT". I like semi-derogatory things like > >> > >>Uncorking and > >> > >>>>>Unblocking more for working group names (which is an > >> > >>IETF insider > >> > >>>>>thing) and not protocol names (which are read by everyone). > >>>> > >>>>-- > >>>>============================================= > >>>>Pete Cordell > >>>>Tech-Know-Ware Ltd > >>>>for XML to C++ data binding visit > >>>>http://www.tech-know-ware.com/lmx > >>>>(or http://www.xml2cpp.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 > >>>> > >>> > >> > >> > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 12 06:18:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu5eV-0002SB-AF; Tue, 12 Dec 2006 06:18:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu5eU-0002S5-Iu for behave@ietf.org; Tue, 12 Dec 2006 06:18:26 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu5eT-0006oU-3n for behave@ietf.org; Tue, 12 Dec 2006 06:18:26 -0500 Received: from frmail35.netfr.alcatel.fr (frmail35.netfr.alcatel.fr [155.132.251.35]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kBCBIJUj016682; Tue, 12 Dec 2006 12:18:19 +0100 Received: from [172.25.78.42] ([172.25.78.42]) by frmail35.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2006121212181319:7615 ; Tue, 12 Dec 2006 12:18:13 +0100 Message-ID: <457E8FF5.5020508@alcatel-lucent.fr> Date: Tue, 12 Dec 2006 12:18:13 +0100 From: Thomas LEVY User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en, fr-fr MIME-Version: 1.0 To: behave@ietf.org, jdrosen@cisco.com, rohan@ekabal.com, huitema@microsoft.com X-MIMETrack: Itemize by SMTP Server on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/12/2006 12:18:13, Serialize by Router on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/12/2006 12:18:14, Serialize complete at 12/12/2006 12:18:14 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [BEHAVE] STUN/TURN framing or RTP framing 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 all, I have a question related to the framing mechanism for stream-oriented transports defined in draft-ietf-behave-turn-02. I fully agree with the need for a framing mechanism when for instance STUN is over TCP. However, it seems that the defined mechanism provides framing in addition with protocol identification (with the use of the Type field). An other method for protocol identification (i.e: to distinguish STUN packets from others) is also defined in stun-bis with the use of the magic cookie. Furthermore, RTP already specified a framing mechanism in rfc4571 that could be applicable to STUN. Thus, i am just wondering if - when defining the framing for STUN - you considered using the framing defined in rfc4571? If so, what are the reasons for the definition of a new framing? On my opinion, i would be favorable to using the same framing for STUN and RTP. My main argument is the following: If you consider a RTP client that wants (or needs) to carry RTP over TCP. If the client sends its media directly to a peer, it must use the framing rfc4571 but if the client sends its media through a relay (TURN) it must use the framing defined in draft-ietf-behave-turn-02. I think it introduces a complexity to RTP that shouldn't be aware of it Furthermore, my "own personal developer experience" makes me think that it would be easier to functionally separate framing from protocol identification for the better design of a protocol stack. Thomas _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 12 11:14:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuAGW-0006zk-JT; Tue, 12 Dec 2006 11:14:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuAGV-0006yt-B8 for behave@ietf.org; Tue, 12 Dec 2006 11:13:59 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuAGS-00052f-Vd for behave@ietf.org; Tue, 12 Dec 2006 11:13:59 -0500 Received: from [131.161.248.89] (open-131-161-248-89.cliq.com [131.161.248.89]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id kBCGCK216895; Tue, 12 Dec 2006 08:12:20 -0800 In-Reply-To: <457E8FF5.5020508@alcatel-lucent.fr> References: <457E8FF5.5020508@alcatel-lucent.fr> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <381bea186305ebaca6aee2e51b2cd659@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Tue, 12 Dec 2006 08:12:32 -0800 To: Thomas LEVY X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Rohan Mahy , behave@ietf.org, huitema@microsoft.com Subject: [BEHAVE] Re: STUN/TURN framing or RTP framing 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 Thomas, The TCP framing is needed to provide the length of non-STUN data over TCP. The RTP framing over TCP was considered, but TURN needs a framing mechanism applicable to both RTP and non-RTP traffic. thanks, -rohan On Dec 12, 2006, at 3:18, Thomas LEVY wrote: > Hello all, > > I have a question related to the framing mechanism for stream-oriented > transports defined in draft-ietf-behave-turn-02. > I fully agree with the need for a framing mechanism when for instance > STUN is over TCP. > However, it seems that the defined mechanism provides framing in > addition with protocol identification (with the use of the Type > field). > An other method for protocol identification (i.e: to distinguish STUN > packets from others) is also defined in stun-bis with the use of the > magic cookie. > Furthermore, RTP already specified a framing mechanism in rfc4571 that > could be applicable to STUN. > Thus, i am just wondering if - when defining the framing for STUN - > you considered using the framing defined in rfc4571? > If so, what are the reasons for the definition of a new framing? > > On my opinion, i would be favorable to using the same framing for STUN > and RTP. > My main argument is the following: If you consider a RTP client that > wants (or needs) to carry RTP over TCP. If the client sends its media > directly to a peer, it must use the framing rfc4571 but if the client > sends its media through a relay (TURN) it must use the framing defined > in draft-ietf-behave-turn-02. I think it introduces a complexity to > RTP that shouldn't be aware of it > Furthermore, my "own personal developer experience" makes me think > that it would be easier to functionally separate framing from protocol > identification for the better design of a protocol stack. > > Thomas _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 12 11:50:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuApf-0005mB-3i; Tue, 12 Dec 2006 11:50:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuApd-0005m4-K9 for behave@ietf.org; Tue, 12 Dec 2006 11:50:17 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuApb-0003le-Ur for behave@ietf.org; Tue, 12 Dec 2006 11:50:17 -0500 Received: from frmail35.netfr.alcatel.fr (frmail35.netfr.alcatel.fr [155.132.251.35]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kBCGnHjV019771; Tue, 12 Dec 2006 17:49:17 +0100 Received: from [172.25.78.42] ([172.25.78.42]) by frmail35.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2006121217491017:12107 ; Tue, 12 Dec 2006 17:49:10 +0100 Message-ID: <457EDD85.8010504@alcatel-lucent.fr> Date: Tue, 12 Dec 2006 17:49:09 +0100 From: Thomas LEVY User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en, fr-fr MIME-Version: 1.0 To: Rohan Mahy References: <457E8FF5.5020508@alcatel-lucent.fr> <381bea186305ebaca6aee2e51b2cd659@ekabal.com> In-Reply-To: <381bea186305ebaca6aee2e51b2cd659@ekabal.com> X-MIMETrack: Itemize by SMTP Server on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/12/2006 17:49:10, Serialize by Router on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/12/2006 17:49:12 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: huitema@microsoft.com, behave@ietf.org Subject: [BEHAVE] Re: STUN/TURN framing or RTP framing 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 Rohan, The framing defined in rfc4571 (i.e: "having a 16-bit unsigned integer=20 LENGTH field" before the data) doesn't sound specific to me. I don't see why it couldn't be applied to STUN or any other traffic? Thomas Rohan Mahy a =E9crit : > Hi Thomas, > > The TCP framing is needed to provide the length of non-STUN data over=20 > TCP. > The RTP framing over TCP was considered, but TURN needs a framing=20 > mechanism applicable to both RTP and non-RTP traffic. > > thanks, > -rohan > > On Dec 12, 2006, at 3:18, Thomas LEVY wrote: > >> Hello all, >> >> I have a question related to the framing mechanism for=20 >> stream-oriented transports defined in draft-ietf-behave-turn-02. >> I fully agree with the need for a framing mechanism when for instance=20 >> STUN is over TCP. >> However, it seems that the defined mechanism provides framing in=20 >> addition with protocol identification (with the use of the Type field). >> An other method for protocol identification (i.e: to distinguish STUN=20 >> packets from others) is also defined in stun-bis with the use of the=20 >> magic cookie. >> Furthermore, RTP already specified a framing mechanism in rfc4571=20 >> that could be applicable to STUN. >> Thus, i am just wondering if - when defining the framing for STUN -=20 >> you considered using the framing defined in rfc4571? >> If so, what are the reasons for the definition of a new framing? >> >> On my opinion, i would be favorable to using the same framing for=20 >> STUN and RTP. >> My main argument is the following: If you consider a RTP client that=20 >> wants (or needs) to carry RTP over TCP. If the client sends its media=20 >> directly to a peer, it must use the framing rfc4571 but if the client=20 >> sends its media through a relay (TURN) it must use the framing=20 >> defined in draft-ietf-behave-turn-02. I think it introduces a=20 >> complexity to RTP that shouldn't be aware of it >> Furthermore, my "own personal developer experience" makes me think=20 >> that it would be easier to functionally separate framing from=20 >> protocol identification for the better design of a protocol stack. >> >> Thomas > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 12 19:16:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuHn9-0007lY-Cm; Tue, 12 Dec 2006 19:16:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuHn8-0007lS-42 for behave@ietf.org; Tue, 12 Dec 2006 19:16:10 -0500 Received: from wr-out-0506.google.com ([64.233.184.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuHn7-0002i2-O1 for behave@ietf.org; Tue, 12 Dec 2006 19:16:10 -0500 Received: by wr-out-0506.google.com with SMTP id i7so5614wra for ; Tue, 12 Dec 2006 16:16:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VPG+F/mKInb3uWG6eoNw0b1d9xBJcUwxrjwjVRm6zHxTutgmeQbvNyPb8t8nrAvHOX2Moydb43AOweBuyhNI9bsRnBKn3vK1vL4lSV1bfDAz7CuUFCI4NHKPWSr2glVQtjExLMrtuRWq6L7nMcJ+yXT8bWYgW4bj6BwkccxrDmk= Received: by 10.78.20.13 with SMTP id 13mr107123hut.1165968968577; Tue, 12 Dec 2006 16:16:08 -0800 (PST) Received: by 10.78.200.9 with HTTP; Tue, 12 Dec 2006 16:16:08 -0800 (PST) Message-ID: <953beacc0612121616x18235053gfe2aa3398103a3d2@mail.gmail.com> Date: Tue, 12 Dec 2006 16:16:08 -0800 From: "Rohan Mahy" To: "Thomas LEVY" Subject: Re: [BEHAVE] Re: STUN/TURN framing or RTP framing In-Reply-To: <457EDD85.8010504@alcatel-lucent.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <457E8FF5.5020508@alcatel-lucent.fr> <381bea186305ebaca6aee2e51b2cd659@ekabal.com> <457EDD85.8010504@alcatel-lucent.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: Rohan Mahy , behave@ietf.org, huitema@microsoft.com 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, Perhaps some use cases would help. All of these examples assume that the Active Destination is set to the peer: 1. RTP over UDP (no TURN) RTP header RTP payload 2. RTP over TCP (no TURN) Length=3D(length of RTP header+payload) RTP header RTP payload 3. TURN Allocation over TCP to a peer running RTP over UDP TURN TCP framing -- Type=3DData, Length=3D(length of RTP header+payload) RTP header RTP payload 4. TURN Allocation over TCP to a peer running STUN/ICE over UDP TURN TCP framing -- Type=3DData, Length=3D(length of peer-destined STUN mes= sage) STUN message 5. Control message about TURN Allocation over TCP TURN TCP framing -- Type=3DSTUN, Length=3D(length of STUN control message) STUN message 6. TURN Allocation over TCP to a peer running SIP over UDP TURN TCP framing -- Type=3DData, Length=3D(length of SIP message) SIP message 7. TURN Allocation over TCP to a peer running syslog over TCP TURN TCP framing -- Type=3DData, Length=3D(arbitrary length to the end of data segment) some syslog stream data 8. TURN Allocation over TCP to a peer running RTP over TCP TURN TCP framing -- Type=3DData, Length=3D(length of RTP header+payload + 2= ) RTP over TCP framing -- Length=3D(length of RTP header+payload) RTP header RTP payload A. Even if we decided to copy the same kind of framing used for RTP over TCP, we would still need to repeat the RTP over TCP framing when delivering to the peer (note the difference between #3 and #8). In other words, TURN relays arbitrary end-to-end data; it does not specially relay RTP from TCP to UDP. B. Since we need some framing only for consumption between the TURN client and the relay, it is a good idea for us to include the Type indicator so we can more easily distinguish between case #4 and #5. thanks, -rohan On 12/12/06, Thomas LEVY wrote: > Hi Rohan, > > The framing defined in rfc4571 (i.e: "having a 16-bit unsigned integer > LENGTH field" before the data) doesn't sound specific to me. > I don't see why it couldn't be applied to STUN or any other traffic? > > Thomas > > Rohan Mahy a =E9crit : > > > Hi Thomas, > > > > The TCP framing is needed to provide the length of non-STUN data over > > TCP. > > The RTP framing over TCP was considered, but TURN needs a framing > > mechanism applicable to both RTP and non-RTP traffic. > > > > thanks, > > -rohan > > > > On Dec 12, 2006, at 3:18, Thomas LEVY wrote: > > > >> Hello all, > >> > >> I have a question related to the framing mechanism for > >> stream-oriented transports defined in draft-ietf-behave-turn-02. > >> I fully agree with the need for a framing mechanism when for instance > >> STUN is over TCP. > >> However, it seems that the defined mechanism provides framing in > >> addition with protocol identification (with the use of the Type field)= . > >> An other method for protocol identification (i.e: to distinguish STUN > >> packets from others) is also defined in stun-bis with the use of the > >> magic cookie. > >> Furthermore, RTP already specified a framing mechanism in rfc4571 > >> that could be applicable to STUN. > >> Thus, i am just wondering if - when defining the framing for STUN - > >> you considered using the framing defined in rfc4571? > >> If so, what are the reasons for the definition of a new framing? > >> > >> On my opinion, i would be favorable to using the same framing for > >> STUN and RTP. > >> My main argument is the following: If you consider a RTP client that > >> wants (or needs) to carry RTP over TCP. If the client sends its media > >> directly to a peer, it must use the framing rfc4571 but if the client > >> sends its media through a relay (TURN) it must use the framing > >> defined in draft-ietf-behave-turn-02. I think it introduces a > >> complexity to RTP that shouldn't be aware of it > >> Furthermore, my "own personal developer experience" makes me think > >> that it would be easier to functionally separate framing from > >> protocol identification for the better design of a protocol stack. > >> > >> Thomas > > > > > > > _______________________________________________ > 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 Dec 12 23:15:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuLWr-0000v7-2A; Tue, 12 Dec 2006 23:15:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuLWp-0000us-Jm for behave@ietf.org; Tue, 12 Dec 2006 23:15:35 -0500 Received: from wr-out-0506.google.com ([64.233.184.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuLWp-0005Sz-1d for behave@ietf.org; Tue, 12 Dec 2006 23:15:35 -0500 Received: by wr-out-0506.google.com with SMTP id i7so20821wra for ; Tue, 12 Dec 2006 20:15:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=n8EGacxymFnohzZ3nrLMLyA2TrjbLcqudnCbSK1gf598ZXcURlzn8fQwDtYQ2UawuogwdIZk7zKv8d2b0Btn8uhUdpTVJA9BKbZ4mnwoxwkRaG9fZyRrY8fHtf9GSrsgON0t376JedJI17B/lFX0Uz/MdKqx56JeXdmU05DOv7E= Received: by 10.90.69.8 with SMTP id r8mr179274aga.1165983334750; Tue, 12 Dec 2006 20:15:34 -0800 (PST) Received: by 10.90.90.18 with HTTP; Tue, 12 Dec 2006 20:15:34 -0800 (PST) Message-ID: Date: Wed, 13 Dec 2006 09:45:34 +0530 From: "Mayank Dev Sondhi" To: "Rohan Mahy" Subject: Re: [BEHAVE] Re: STUN/TURN framing or RTP framing In-Reply-To: <953beacc0612121616x18235053gfe2aa3398103a3d2@mail.gmail.com> MIME-Version: 1.0 References: <457E8FF5.5020508@alcatel-lucent.fr> <381bea186305ebaca6aee2e51b2cd659@ekabal.com> <457EDD85.8010504@alcatel-lucent.fr> <953beacc0612121616x18235053gfe2aa3398103a3d2@mail.gmail.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 Cc: Rohan Mahy , behave@ietf.org, huitema@microsoft.com 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="===============1637215354==" Errors-To: behave-bounces@ietf.org --===============1637215354== Content-Type: multipart/alternative; boundary="----=_Part_11469_5149624.1165983334663" ------=_Part_11469_5149624.1165983334663 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Please excuse my discussion of an implementation specific scenario, but I believe it is pertinent. One of the advantages I can cite(having developed a particular implementation of the STUN/TURN relay) is that over TCP it is always advantageous to separate out control messages over normal data messages. We faced a problem wherein we had to implement some policing of the bandwidth, and we did this in the simplest and naive way by not doing recvs on our sockets if b/w was exceeded. Unfortunately control messages for cancellatio= n of the operation would also get queued up with the net effect that a user cancel operation would also get stuck on the recv queue of the socket. If there was a framing mechanism that allowed us to distinguish this we could very easily separate out signalling from transfer in our stack withou= t sacrificing on performance. I think this design helps us in that regard by including the type in the frame itself. Thanks Mayank On 12/13/06, Rohan Mahy wrote: > > Hi, > > Perhaps some use cases would help. All of these examples assume that > the Active Destination is set to the peer: > > 1. RTP over UDP (no TURN) > RTP header > RTP payload > > 2. RTP over TCP (no TURN) > Length=3D(length of RTP header+payload) > RTP header > RTP payload > > 3. TURN Allocation over TCP to a peer running RTP over UDP > TURN TCP framing -- Type=3DData, Length=3D(length of RTP header+payload) > RTP header > RTP payload > > 4. TURN Allocation over TCP to a peer running STUN/ICE over UDP > TURN TCP framing -- Type=3DData, Length=3D(length of peer-destined STUN > message) > STUN message > > 5. Control message about TURN Allocation over TCP > TURN TCP framing -- Type=3DSTUN, Length=3D(length of STUN control message= ) > STUN message > > 6. TURN Allocation over TCP to a peer running SIP over UDP > TURN TCP framing -- Type=3DData, Length=3D(length of SIP message) > SIP message > > 7. TURN Allocation over TCP to a peer running syslog over TCP > TURN TCP framing -- Type=3DData, Length=3D(arbitrary length to the end of > data segment) > some syslog stream data > > 8. TURN Allocation over TCP to a peer running RTP over TCP > TURN TCP framing -- Type=3DData, Length=3D(length of RTP header+payload += 2) > RTP over TCP framing -- Length=3D(length of RTP header+payload) > RTP header > RTP payload > > A. Even if we decided to copy the same kind of framing used for RTP > over TCP, we would still need to repeat the RTP over TCP framing when > delivering to the peer (note the difference between #3 and #8). In > other words, TURN relays arbitrary end-to-end data; it does not > specially relay RTP from TCP to UDP. > > B. Since we need some framing only for consumption between the TURN > client and the relay, it is a good idea for us to include the Type > indicator so we can more easily distinguish between case #4 and #5. > > thanks, > -rohan > > > > > On 12/12/06, Thomas LEVY wrote: > > Hi Rohan, > > > > The framing defined in rfc4571 (i.e: "having a 16-bit unsigned integer > > LENGTH field" before the data) doesn't sound specific to me. > > I don't see why it couldn't be applied to STUN or any other traffic? > > > > Thomas > > > > Rohan Mahy a =E9crit : > > > > > Hi Thomas, > > > > > > The TCP framing is needed to provide the length of non-STUN data over > > > TCP. > > > The RTP framing over TCP was considered, but TURN needs a framing > > > mechanism applicable to both RTP and non-RTP traffic. > > > > > > thanks, > > > -rohan > > > > > > On Dec 12, 2006, at 3:18, Thomas LEVY wrote: > > > > > >> Hello all, > > >> > > >> I have a question related to the framing mechanism for > > >> stream-oriented transports defined in draft-ietf-behave-turn-02. > > >> I fully agree with the need for a framing mechanism when for instanc= e > > >> STUN is over TCP. > > >> However, it seems that the defined mechanism provides framing in > > >> addition with protocol identification (with the use of the Type > field). > > >> An other method for protocol identification (i.e: to distinguish STU= N > > >> packets from others) is also defined in stun-bis with the use of th= e > > >> magic cookie. > > >> Furthermore, RTP already specified a framing mechanism in rfc4571 > > >> that could be applicable to STUN. > > >> Thus, i am just wondering if - when defining the framing for STUN - > > >> you considered using the framing defined in rfc4571? > > >> If so, what are the reasons for the definition of a new framing? > > >> > > >> On my opinion, i would be favorable to using the same framing for > > >> STUN and RTP. > > >> My main argument is the following: If you consider a RTP client that > > >> wants (or needs) to carry RTP over TCP. If the client sends its medi= a > > >> directly to a peer, it must use the framing rfc4571 but if the clien= t > > >> sends its media through a relay (TURN) it must use the framing > > >> defined in draft-ietf-behave-turn-02. I think it introduces a > > >> complexity to RTP that shouldn't be aware of it > > >> Furthermore, my "own personal developer experience" makes me think > > >> that it would be easier to functionally separate framing from > > >> protocol identification for the better design of a protocol stack. > > >> > > >> Thomas > > > > > > > > > > > > _______________________________________________ > > 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 > ------=_Part_11469_5149624.1165983334663 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Please excuse my discussion of an implementation specific scenario, bu= t I believe it is pertinent.
 
One of the advantages I can cite(having developed a particular impleme= ntation of the STUN/TURN relay) is that over TCP it is always advantageous = to separate out control messages over normal data messages. We faced a prob= lem wherein we had to implement some policing of the bandwidth, and we did = this in the simplest and naive way by not doing recvs on our sockets if b/w= was exceeded. Unfortunately control messages for cancellation of the opera= tion would also get queued up with the net effect that a user cancel operat= ion would also get stuck on the recv queue of the socket.

If there was a framing mechanism that allowed us to distinguish th= is we could very easily separate out signalling from transfer in our stack = without sacrificing on performance. I think this design helps us in that re= gard by including the type in the frame itself.
 
Thanks
Mayank
 
On 12/13/06, Rohan Mahy <rohan.mahy@gmai= l.com> wrote:
Hi,

Perhaps some use case= s would help.  All of these examples assume that
the Active De= stination is set to the peer:

1. RTP over UDP (no TURN)
RTP header
RTP payload

2. RT= P over TCP (no TURN)
Length=3D(length of RTP header+payload)
RTP head= er
RTP payload

3. TURN Allocation over TCP to a peer running RTP = over UDP
TURN TCP framing -- Type=3DData, Length=3D(length of RTP header+payload= )
RTP header
RTP payload

4. TURN Allocation over TCP to a peer= running STUN/ICE over UDP
TURN TCP framing -- Type=3DData, Length=3D(le= ngth of peer-destined STUN message)
STUN message

5. Control message about TURN Allocation over TCPTURN TCP framing -- Type=3DSTUN, Length=3D(length of STUN control message= )
STUN message

6. TURN Allocation over TCP to a peer running SIP = over UDP
TURN TCP framing -- Type=3DData, Length=3D(length of SIP message)
SI= P message

7. TURN Allocation over TCP to a peer running syslog over = TCP
TURN TCP framing -- Type=3DData, Length=3D(arbitrary length to the e= nd of
data segment)
some syslog stream data

8. TURN Allocation over= TCP to a peer running RTP over TCP
TURN TCP framing -- Type=3DData, Len= gth=3D(length of RTP header+payload + 2)
RTP over TCP framing -- Length= =3D(length of RTP header+payload)
RTP header
RTP payload

A. Even if we decided to copy the same= kind of framing used for RTP
over TCP, we would still need to repeat th= e RTP over TCP framing when
delivering to the peer (note the difference = between #3 and #8). In
other words, TURN relays arbitrary end-to-end data; it does not
spec= ially relay RTP from TCP to UDP.

B. Since we need some framing only = for consumption between the TURN
client and the relay, it is a good idea= for us to include the Type
indicator so we can more easily distinguish between case #4 and #5.
=
thanks,
-rohan




On 12/12/06, Thomas LEVY <thomas.levy@alcatel-lucent.fr > wrote:
> Hi Rohan,
>
> The framing defined in rf= c4571 (i.e: "having a 16-bit unsigned integer
> LENGTH field&quo= t; before the data) doesn't sound specific to me.
> I don't s= ee why it couldn't be applied to STUN or any other traffic?
>
> Thomas
>
> Rohan Mahy a =E9crit :
>
&= gt; > Hi Thomas,
> >
> > The TCP framing is needed to = provide the length of non-STUN data over
> > TCP.
> > The= RTP framing over TCP was considered, but TURN needs a framing
> > mechanism applicable to both RTP and non-RTP traffic.
>= >
> > thanks,
> > -rohan
> >
> > On= Dec 12, 2006, at 3:18, Thomas LEVY wrote:
> >
> >> He= llo all,
> >>
> >> I have a question related to the framing= mechanism for
> >> stream-oriented transports defined in draft= -ietf-behave-turn-02.
> >> I fully agree with the need for a fr= aming mechanism when for instance
> >> STUN is over TCP.
> >> However, it seems that= the defined mechanism provides framing in
> >> addition with p= rotocol identification (with the use of the Type field).
> >> A= n other method for protocol identification ( i.e: to distinguish STUN
> >> packets from others) is also defi= ned in stun-bis with the use of  the
> >> magic cooki= e.
> >> Furthermore, RTP already specified a framing mechanism = in rfc4571
> >> that could be applicable to STUN.
> >> Thus, = i am just wondering if  - when defining the framing for STUN -> >> you considered using the framing defined in rfc4571?
>= >> If so, what are the reasons for the definition of a new framing?
> >>
> >> On my opinion, i would be favorable to u= sing the same framing for
> >> STUN and RTP.
> >> M= y main argument is the following: If you consider a RTP client that
> >> wants (or needs) to carry RTP over TCP. If the client sends i= ts media
> >> directly to a peer, it must use the framing rfc45= 71 but if the client
> >> sends its media through a relay (TURN= ) it must use the framing
> >> defined in draft-ietf-behave-turn-02. I think it introduc= es a
> >> complexity to RTP that shouldn't be aware of it> >> Furthermore, my "own personal developer experience&quo= t; makes me think
> >> that it would be easier to functionally separate framing = from
> >> protocol identification for the better design of a pr= otocol stack.
> >>
> >> Thomas
> >
> >
>
>
> _________________________________________= ______
> 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
------=_Part_11469_5149624.1165983334663-- --===============1637215354== 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 --===============1637215354==-- From behave-bounces@ietf.org Thu Dec 14 03:40:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gum8a-00065y-9o; Thu, 14 Dec 2006 03:40:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gum8Y-00065g-QL for behave@ietf.org; Thu, 14 Dec 2006 03:40:18 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gum8X-0007H0-6A for behave@ietf.org; Thu, 14 Dec 2006 03:40:18 -0500 Received: from frmail35.netfr.alcatel.fr (frmail35.netfr.alcatel.fr [155.132.251.35]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kBE8eAb7010094; Thu, 14 Dec 2006 09:40:10 +0100 Received: from [172.25.78.42] ([172.25.78.42]) by frmail35.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2006121409400413:4683 ; Thu, 14 Dec 2006 09:40:04 +0100 Message-ID: <45810DE4.1060203@alcatel-lucent.fr> Date: Thu, 14 Dec 2006 09:40:04 +0100 From: Thomas LEVY User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en, fr-fr MIME-Version: 1.0 To: Mayank Dev Sondhi Subject: Re: [BEHAVE] Re: STUN/TURN framing or RTP framing References: <457E8FF5.5020508@alcatel-lucent.fr> <381bea186305ebaca6aee2e51b2cd659@ekabal.com> <457EDD85.8010504@alcatel-lucent.fr> <953beacc0612121616x18235053gfe2aa3398103a3d2@mail.gmail.com> In-Reply-To: X-MIMETrack: Itemize by SMTP Server on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/14/2006 09:40:04, Serialize by Router on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/14/2006 09:40:05 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: Rohan Mahy , behave@ietf.org, huitema@microsoft.com 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 Mayank Do you mean you would like to have the STUN traffic and the data traffic=20 sperated in order to do separate "socket recv"? I believe the only way to do this would be to have 2 sockets (one for=20 the traffic and one for the control) but this is not in line with the=20 logic of TURN. Thomas Mayank Dev Sondhi a =E9crit : > Please excuse my discussion of an implementation specific scenario,=20 > but I believe it is pertinent. > =20 > One of the advantages I can cite(having developed a particular=20 > implementation of the STUN/TURN relay) is that over TCP it is always=20 > advantageous to separate out control messages over normal data=20 > messages. We faced a problem wherein we had to implement some policing=20 > of the bandwidth, and we did this in the simplest and naive way by not=20 > doing recvs on our sockets if b/w was exceeded. Unfortunately control=20 > messages for cancellation of the operation would also get queued up=20 > with the net effect that a user cancel operation would also get stuck=20 > on the recv queue of the socket. > > If there was a framing mechanism that allowed us to distinguish this=20 > we could very easily separate out signalling from transfer in our=20 > stack without sacrificing on performance. I think this design helps us=20 > in that regard by including the type in the frame itself. > =20 > Thanks > Mayank > =20 > From behave-bounces@ietf.org Thu Dec 14 03:40:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gum8a-00065y-9o; Thu, 14 Dec 2006 03:40:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gum8Y-00065g-QL for behave@ietf.org; Thu, 14 Dec 2006 03:40:18 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gum8X-0007H0-6A for behave@ietf.org; Thu, 14 Dec 2006 03:40:18 -0500 Received: from frmail35.netfr.alcatel.fr (frmail35.netfr.alcatel.fr [155.132.251.35]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kBE8eAb7010094; Thu, 14 Dec 2006 09:40:10 +0100 Received: from [172.25.78.42] ([172.25.78.42]) by frmail35.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2006121409400413:4683 ; Thu, 14 Dec 2006 09:40:04 +0100 Message-ID: <45810DE4.1060203@alcatel-lucent.fr> Date: Thu, 14 Dec 2006 09:40:04 +0100 From: Thomas LEVY User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en, fr-fr MIME-Version: 1.0 To: Mayank Dev Sondhi Subject: Re: [BEHAVE] Re: STUN/TURN framing or RTP framing References: <457E8FF5.5020508@alcatel-lucent.fr> <381bea186305ebaca6aee2e51b2cd659@ekabal.com> <457EDD85.8010504@alcatel-lucent.fr> <953beacc0612121616x18235053gfe2aa3398103a3d2@mail.gmail.com> In-Reply-To: X-MIMETrack: Itemize by SMTP Server on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/14/2006 09:40:04, Serialize by Router on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/14/2006 09:40:05 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: Rohan Mahy , behave@ietf.org, huitema@microsoft.com 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 Mayank Do you mean you would like to have the STUN traffic and the data traffic=20 sperated in order to do separate "socket recv"? I believe the only way to do this would be to have 2 sockets (one for=20 the traffic and one for the control) but this is not in line with the=20 logic of TURN. Thomas Mayank Dev Sondhi a =E9crit : > Please excuse my discussion of an implementation specific scenario,=20 > but I believe it is pertinent. > =20 > One of the advantages I can cite(having developed a particular=20 > implementation of the STUN/TURN relay) is that over TCP it is always=20 > advantageous to separate out control messages over normal data=20 > messages. We faced a problem wherein we had to implement some policing=20 > of the bandwidth, and we did this in the simplest and naive way by not=20 > doing recvs on our sockets if b/w was exceeded. Unfortunately control=20 > messages for cancellation of the operation would also get queued up=20 > with the net effect that a user cancel operation would also get stuck=20 > on the recv queue of the socket. > > If there was a framing mechanism that allowed us to distinguish this=20 > we could very easily separate out signalling from transfer in our=20 > stack without sacrificing on performance. I think this design helps us=20 > in that regard by including the type in the frame itself. > =20 > Thanks > Mayank > =20 > On 12/13/06, *Rohan Mahy* > wrote: > > Hi, > > Perhaps some use cases would help. All of these examples assume that > the Active Destination is set to the peer: > > 1. RTP over UDP (no TURN) > RTP header > RTP payload > > 2. RTP over TCP (no TURN) > Length=3D(length of RTP header+payload) > RTP header > RTP payload > > 3. TURN Allocation over TCP to a peer running RTP over UDP > TURN TCP framing -- Type=3DData, Length=3D(length of RTP header+paylo= ad) > RTP header > RTP payload > > 4. TURN Allocation over TCP to a peer running STUN/ICE over UDP > TURN TCP framing -- Type=3DData, Length=3D(length of peer-destined > STUN message) > STUN message > > 5. Control message about TURN Allocation over TCP > TURN TCP framing -- Type=3DSTUN, Length=3D(length of STUN control mes= sage) > STUN message > > 6. TURN Allocation over TCP to a peer running SIP over UDP > TURN TCP framing -- Type=3DData, Length=3D(length of SIP message) > SIP message > > 7. TURN Allocation over TCP to a peer running syslog over TCP > TURN TCP framing -- Type=3DData, Length=3D(arbitrary length to the en= d of > data segment) > some syslog stream data > > 8. TURN Allocation over TCP to a peer running RTP over TCP > TURN TCP framing -- Type=3DData, Length=3D(length of RTP > header+payload + 2) > RTP over TCP framing -- Length=3D(length of RTP header+payload) > RTP header > RTP payload > > A. Even if we decided to copy the same kind of framing used for RTP > over TCP, we would still need to repeat the RTP over TCP framing when > delivering to the peer (note the difference between #3 and #8). In > other words, TURN relays arbitrary end-to-end data; it does not > specially relay RTP from TCP to UDP. > > B. Since we need some framing only for consumption between the TURN > client and the relay, it is a good idea for us to include the Type > indicator so we can more easily distinguish between case #4 and #5. > > thanks, > -rohan > > > > > On 12/12/06, Thomas LEVY > wrote: > > Hi Rohan, > > > > The framing defined in rfc4571 (i.e: "having a 16-bit unsigned > integer > > LENGTH field" before the data) doesn't sound specific to me. > > I don't see why it couldn't be applied to STUN or any other > traffic? > > > > Thomas > > > > Rohan Mahy a =E9crit : > > > > > Hi Thomas, > > > > > > The TCP framing is needed to provide the length of non-STUN > data over > > > TCP. > > > The RTP framing over TCP was considered, but TURN needs a framing > > > mechanism applicable to both RTP and non-RTP traffic. > > > > > > thanks, > > > -rohan > > > > > > On Dec 12, 2006, at 3:18, Thomas LEVY wrote: > > > > > >> Hello all, > > >> > > >> I have a question related to the framing mechanism for > > >> stream-oriented transports defined in draft-ietf-behave-turn-02. > > >> I fully agree with the need for a framing mechanism when for > instance > > >> STUN is over TCP. > > >> However, it seems that the defined mechanism provides framing in > > >> addition with protocol identification (with the use of the > Type field). > > >> An other method for protocol identification ( i.e: to > distinguish STUN > > >> packets from others) is also defined in stun-bis with the use > of the > > >> magic cookie. > > >> Furthermore, RTP already specified a framing mechanism in > rfc4571 > > >> that could be applicable to STUN. > > >> Thus, i am just wondering if - when defining the framing for > STUN - > > >> you considered using the framing defined in rfc4571? > > >> If so, what are the reasons for the definition of a new framing? > > >> > > >> On my opinion, i would be favorable to using the same framing forOn 12/13/06, *Rohan Mahy* > wrote: > > Hi, > > Perhaps some use cases would help. All of these examples assume that > the Active Destination is set to the peer: > > 1. RTP over UDP (no TURN) > RTP header > RTP payload > > 2. RTP over TCP (no TURN) > Length=3D(length of RTP header+payload) > RTP header > RTP payload > > 3. TURN Allocation over TCP to a peer running RTP over UDP > TURN TCP framing -- Type=3DData, Length=3D(length of RTP header+paylo= ad) > RTP header > RTP payload > > 4. TURN Allocation over TCP to a peer running STUN/ICE over UDP > TURN TCP framing -- Type=3DData, Length=3D(length of peer-destined > STUN message) > STUN message > > 5. Control message about TURN Allocation over TCP > TURN TCP framing -- Type=3DSTUN, Length=3D(length of STUN control mes= sage) > STUN message > > 6. TURN Allocation over TCP to a peer running SIP over UDP > TURN TCP framing -- Type=3DData, Length=3D(length of SIP message) > SIP message > > 7. TURN Allocation over TCP to a peer running syslog over TCP > TURN TCP framing -- Type=3DData, Length=3D(arbitrary length to the en= d of > data segment) > some syslog stream data > > 8. TURN Allocation over TCP to a peer running RTP over TCP > TURN TCP framing -- Type=3DData, Length=3D(length of RTP > header+payload + 2) > RTP over TCP framing -- Length=3D(length of RTP header+payload) > RTP header > RTP payload > > A. Even if we decided to copy the same kind of framing used for RTP > over TCP, we would still need to repeat the RTP over TCP framing when > delivering to the peer (note the difference between #3 and #8). In > other words, TURN relays arbitrary end-to-end data; it does not > specially relay RTP from TCP to UDP. > > B. Since we need some framing only for consumption between the TURN > client and the relay, it is a good idea for us to include the Type > indicator so we can more easily distinguish between case #4 and #5. > > thanks, > -rohan > > > > > On 12/12/06, Thomas LEVY > wrote: > > Hi Rohan, > > > > The framing defined in rfc4571 (i.e: "having a 16-bit unsigned > integer > > LENGTH field" before the data) doesn't sound specific to me. > > I don't see why it couldn't be applied to STUN or any other > traffic? > > > > Thomas > > > > Rohan Mahy a =E9crit : > > > > > Hi Thomas, > > > > > > The TCP framing is needed to provide the length of non-STUN > data over > > > TCP. > > > The RTP framing over TCP was considered, but TURN needs a framing > > > mechanism applicable to both RTP and non-RTP traffic. > > > > > > thanks, > > > -rohan > > > > > > On Dec 12, 2006, at 3:18, Thomas LEVY wrote: > > > > > >> Hello all, > > >> > > >> I have a question related to the framing mechanism for > > >> stream-oriented transports defined in draft-ietf-behave-turn-02. > > >> I fully agree with the need for a framing mechanism when for > instance > > >> STUN is over TCP. > > >> However, it seems that the defined mechanism provides framing in > > >> addition with protocol identification (with the use of the > Type field). > > >> An other method for protocol identification ( i.e: to > distinguish STUN > > >> packets from others) is also defined in stun-bis with the use > of the > > >> magic cookie. > > >> Furthermore, RTP already specified a framing mechanism in > rfc4571 > > >> that could be applicable to STUN. > > >> Thus, i am just wondering if - when defining the framing for > STUN - > > >> you considered using the framing defined in rfc4571? > > >> If so, what are the reasons for the definition of a new framing? > > >> > > >> On my opinion, i would be favorable to using the same framing for > > >> STUN and RTP. > > >> My main argument is the following: If you consider a RTP > client that > > >> wants (or needs) to carry RTP over TCP. If the client sends > its media > > >> directly to a peer, it must use the framing rfc4571 but if > the client > > >> sends its media through a relay (TURN) it must use the framing > > >> defined in draft-ietf-behave-turn-02. I think it introduces a > > >> complexity to RTP that shouldn't be aware of it > > >> Furthermore, my "own personal developer experience" makes me > think > > >> that it would be easier to functionally separate framing from > > >> protocol identification for the better design of a protocol > stack. > > >> > > >> Thomas > > > > > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > Behave mailing list > > Behave@ietf.org > > https://www1.ietf.org/mailman/listinfo/behave > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > 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 Dec 14 03:40:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gum8Y-00065i-S9; Thu, 14 Dec 2006 03:40:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gum8W-00065S-Ms for behave@ietf.org; Thu, 14 Dec 2006 03:40:16 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gum8T-0007Gb-Su for behave@ietf.org; Thu, 14 Dec 2006 03:40:16 -0500 Received: from frmail35.netfr.alcatel.fr (frmail35.netfr.alcatel.fr [155.132.251.35]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kBE8e1sx010022; Thu, 14 Dec 2006 09:40:01 +0100 Received: from [172.25.78.42] ([172.25.78.42]) by frmail35.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2006121409395476:4680 ; Thu, 14 Dec 2006 09:39:54 +0100 Message-ID: <45810DDA.1020802@alcatel-lucent.fr> Date: Thu, 14 Dec 2006 09:39:54 +0100 From: Thomas LEVY User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en, fr-fr MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [BEHAVE] Re: STUN/TURN framing or RTP framing References: <457E8FF5.5020508@alcatel-lucent.fr> <381bea186305ebaca6aee2e51b2cd659@ekabal.com> <457EDD85.8010504@alcatel-lucent.fr> <953beacc0612121616x18235053gfe2aa3398103a3d2@mail.gmail.com> In-Reply-To: <953beacc0612121616x18235053gfe2aa3398103a3d2@mail.gmail.com> X-MIMETrack: Itemize by SMTP Server on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/14/2006 09:39:54, Serialize by Router on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/14/2006 09:39:55 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: Rohan Mahy , behave@ietf.org, huitema@microsoft.com 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: , > >> STUN and RTP. > > >> My main argument is the following: If you consider a RTP > client that > > >> wants (or needs) to carry RTP over TCP. If the client sends > its media > > >> directly to a peer, it must use the framing rfc4571 but if > the client > > >> sends its media through a relay (TURN) it must use the framing > > >> defined in draft-ietf-behave-turn-02. I think it introduces a > > >> complexity to RTP that shouldn't be aware of it > > >> Furthermore, my "own personal developer experience" makes me > think > > >> that it would be easier to functionally separate framing from > > >> protocol identification for the better design of a protocol > stack. > > >> > > >> Thomas > > > > > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > Behave mailing list > > Behave@ietf.org > > https://www1.ietf.org/mailman/listinfo/behave > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > 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 Dec 14 03:40:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gum8Y-00065i-S9; Thu, 14 Dec 2006 03:40:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gum8W-00065S-Ms for behave@ietf.org; Thu, 14 Dec 2006 03:40:16 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gum8T-0007Gb-Su for behave@ietf.org; Thu, 14 Dec 2006 03:40:16 -0500 Received: from frmail35.netfr.alcatel.fr (frmail35.netfr.alcatel.fr [155.132.251.35]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kBE8e1sx010022; Thu, 14 Dec 2006 09:40:01 +0100 Received: from [172.25.78.42] ([172.25.78.42]) by frmail35.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2006121409395476:4680 ; Thu, 14 Dec 2006 09:39:54 +0100 Message-ID: <45810DDA.1020802@alcatel-lucent.fr> Date: Thu, 14 Dec 2006 09:39:54 +0100 From: Thomas LEVY User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en, fr-fr MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [BEHAVE] Re: STUN/TURN framing or RTP framing References: <457E8FF5.5020508@alcatel-lucent.fr> <381bea186305ebaca6aee2e51b2cd659@ekabal.com> <457EDD85.8010504@alcatel-lucent.fr> <953beacc0612121616x18235053gfe2aa3398103a3d2@mail.gmail.com> In-Reply-To: <953beacc0612121616x18235053gfe2aa3398103a3d2@mail.gmail.com> X-MIMETrack: Itemize by SMTP Server on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/14/2006 09:39:54, Serialize by Router on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/14/2006 09:39:55 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: Rohan Mahy , behave@ietf.org, huitema@microsoft.com 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 Rohan, You talk about the need to separate (for inst: at the STUN/TURN server=20 level) the data packets from the STUN/control packets. It is also what I called protocol identifiation in my first mail. This need is the same for UDP packets than for TCP packets. stun-bis specifies to use the magic cookie for that purpose. This is=20 true for UDP and for TCP. Why is there a need to add a new mechanism for TCP (such as: a specific=20 framing) instead of the existing mechanism in stun-bis? Thomas Rohan Mahy a =E9crit : > Hi, > > Perhaps some use cases would help. All of these examples assume that > the Active Destination is set to the peer: > > 1. RTP over UDP (no TURN) > RTP header > RTP payload > > 2. RTP over TCP (no TURN) > Length=3D(length of RTP header+payload) > RTP header > RTP payload > > 3. TURN Allocation over TCP to a peer running RTP over UDP > TURN TCP framing -- Type=3DData, Length=3D(length of RTP header+payload) > RTP header > RTP payload > > 4. TURN Allocation over TCP to a peer running STUN/ICE over UDP > TURN TCP framing -- Type=3DData, Length=3D(length of peer-destined STUN=20 > message) > STUN message > > 5. Control message about TURN Allocation over TCP > TURN TCP framing -- Type=3DSTUN, Length=3D(length of STUN control message) > STUN message > > 6. TURN Allocation over TCP to a peer running SIP over UDP > TURN TCP framing -- Type=3DData, Length=3D(length of SIP message) > SIP message > > 7. TURN Allocation over TCP to a peer running syslog over TCP > TURN TCP framing -- Type=3DData, Length=3D(arbitrary length to the end of > data segment) > some syslog stream data > > 8. TURN Allocation over TCP to a peer running RTP over TCP > TURN TCP framing -- Type=3DData, Length=3D(length of RTP header+payload += 2) > RTP over TCP framing -- Length=3D(length of RTP header+payload) > RTP header > RTP payload > > A. Even if we decided to copy the same kind of framing used for RTP > over TCP, we would still need to repeat the RTP over TCP framing when > delivering to the peer (note the difference between #3 and #8). In > other words, TURN relays arbitrary end-to-end data; it does not > specially relay RTP from TCP to UDP. > > B. Since we need some framing only for consumption between the TURN > client and the relay, it is a good idea for us to include the Type > indicator so we can more easily distinguish between case #4 and #5. > > thanks, > -rohan > > > > > On 12/12/06, Thomas LEVY wrote: > >> Hi Rohan, >> >> The framing defined in rfc4571 (i.e: "having a 16-bit unsigned integer >> LENGTH field" before the data) doesn't sound specific to me. >> I don't see why it couldn't be applied to STUN or any other traffic? >> >> Thomas >> >> Rohan Mahy a =E9crit : >> >> > Hi Thomas, >> > >> > The TCP framing is needed to provide the length of non-STUN data over >> > TCP. >> > The RTP framing over TCP was considered, but TURN needs a framing >> > mechanism applicable to both RTP and non-RTP traffic. >> > >> > thanks, >> > -rohan >> > >> > On Dec 12, 2006, at 3:18, Thomas LEVY wrote: >> > >> >> Hello all, >> >> >> >> I have a question related to the framing mechanism for >> >> stream-oriented transports defined in draft-ietf-behave-turn-02. >> >> I fully agree with the need for a framing mechanism when for instance >> >> STUN is over TCP. >> >> However, it seems that the defined mechanism provides framing in >> >> addition with protocol identification (with the use of the Type=20 >> field). >> >> An other method for protocol identification (i.e: to distinguish STUN >> >> packets from others) is also defined in stun-bis with the use of the >> >> magic cookie. >> >> Furthermore, RTP already specified a framing mechanism in rfc4571 >> >> that could be applicable to STUN. >> >> Thus, i am just wondering if - when defining the framing for STUN - >> >> you considered using the framing defined in rfc4571? >> >> If so, what are the reasons for the definition of a new framing? >> >> >> >> On my opinion, i would be favorable to using the same frt=subscribe> Errors-To: behave-bounces@ietf.org Hi Rohan, You talk about the need to separate (for inst: at the STUN/TURN server=20 level) the data packets from the STUN/control packets. It is also what I called protocol identifiation in my first mail. This need is the same for UDP packets than for TCP packets. stun-bis specifies to use the magic cookie for that purpose. This is=20 true for UDP and for TCP. Why is there a need to add a new mechanism for TCP (such as: a specific=20 framing) instead of the existing mechanism in stun-bis? Thomas Rohan Mahy a =E9crit : > Hi, > > Perhaps some use cases would help. All of these examples assume that > the Active Destination is set to the peer: > > 1. RTP over UDP (no TURN) > RTP header > RTP payload > > 2. RTP over TCP (no TURN) > Length=3D(length of RTP header+payload) > RTP header > RTP payload > > 3. TURN Allocation over TCP to a peer running RTP over UDP > TURN TCP framing -- Type=3DData, Length=3D(length of RTP header+payload) > RTP header > RTP payload > > 4. TURN Allocation over TCP to a peer running STUN/ICE over UDP > TURN TCP framing -- Type=3DData, Length=3D(length of peer-destined STUN=20 > message) > STUN message > > 5. Control message about TURN Allocation over TCP > TURN TCP framing -- Type=3DSTUN, Length=3D(length of STUN control message) > STUN message > > 6. TURN Allocation over TCP to a peer running SIP over UDP > TURN TCP framing -- Type=3DData, Length=3D(length of SIP message) > SIP message > > 7. TURN Allocation over TCP to a peer running syslog over TCP > TURN TCP framing -- Type=3DData, Length=3D(arbitrary length to the end of > data segment) > some syslog stream data > > 8. TURN Allocation over TCP to a peer running RTP over TCP > TURN TCP framing -- Type=3DData, Length=3D(length of RTP header+payload += 2) > RTP over TCP framing -- Length=3D(length of RTP header+payload) > RTP header > RTP payload > > A. Even if we decided to copy the same kind of framing used for RTP > over TCP, we would still need to repeat the RTP over TCP framing when > delivering to the peer (note the difference between #3 and #8). In > other words, TURN relays arbitrary end-to-end data; it does not > specially relay RTP from TCP to UDP. > > B. Since we need some framing only for consumption between the TURN > client and the relay, it is a good idea for us to include the Type > indicator so we can more easily distinguish between case #4 and #5. > > thanks, > -rohan > > > > > On 12/12/06, Thomas LEVY wrote: > >> Hi Rohan, >> >> The framing defined in rfc4571 (i.e: "having a 16-bit unsigned integer >> LENGTH field" before the data) doesn't sound specific to me. >> I don't see why it couldn't be applied to STUN or any other traffic? >> >> Thomas >> >> Rohan Mahy a =E9crit : >> >> > Hi Thomas, >> > >> > The TCP framing is needed to provide the length of non-STUN data over >> > TCP. >> > The RTP framing over TCP was considered, but TURN needs a framing >> > mechanism applicable to both RTP and non-RTP traffic. >> > >> > thanks, >> > -rohan >> > >> > On Dec 12, 2006, at 3:18, Thomas LEVY wrote: >> > >> >> Hello all, >> >> >> >> I have a question related to the framing mechanism for >> >> stream-oriented transports defined in draft-ietf-behave-turn-02. >> >> I fully agree with the need for a framing mechanism when for instance >> >> STUN is over TCP. >> >> However, it seems that the defined mechanism provides framing in >> >> addition with protocol identification (with the use of the Type=20 >> field). >> >> An other method for protocol identification (i.e: to distinguish STUN >> >> packets from others) is also defined in stun-bis with the use of the >> >> magic cookie. >> >> Furthermore, RTP already specified a framing mechanism in rfc4571 >> >> that could be applicable to STUN. >> >> Thus, i am just wondering if - when defining the framing for STUN - >> >> you considered using the framing defined in rfc4571? >> >> If so, what are the reasons for the definition of a new framing? >> >> >> >> On my opinion, i would be favorable to using the same framing for >> >> STUN and RTP. >> >> My main argument is the following: If you consider a RTP client that >> >> wants (or needs) to carry RTP over TCP. If the client sends its media >> >> directly to a peer, it must use the framing rfc4571 but if the client >> >> sends its media through a relay (TURN) it must use the framing >> >> defined in draft-ietf-behave-turn-02. I think it introduces a >> >> complexity to RTP that shouldn't be aware of it >> >> Furthermore, my "own personal developer experience" makes me think >> >> that it would be easier to functionally separate framing from >> >> protocol identification for the better design of a protocol stack. >> >> >> >> Thomas >> > >> > >> >> >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >> 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 aming for >> >> STUN and RTP. >> >> My main argument is the following: If you consider a RTP client that >> >> wants (or needs) to carry RTP over TCP. If the client sends its media >> >> directly to a peer, it must use the framing rfc4571 but if the client >> >> sends its media through a relay (TURN) it must use the framing >> >> defined in draft-ietf-behave-turn-02. I think it introduces a >> >> complexity to RTP that shouldn't be aware of it >> >> Furthermore, my "own personal developer experience" makes me think >> >> that it would be easier to functionally separate framing from >> >> protocol identification for the better design of a protocol stack. >> >> >> >> Thomas >> > >> > >> >> >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >> 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 Dec 14 10:28:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GusVH-0000uu-Bn; Thu, 14 Dec 2006 10:28:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GusVG-0000um-Ao for behave@ietf.org; Thu, 14 Dec 2006 10:28:10 -0500 Received: from lambda.sipfoundry.org ([72.232.205.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GusV9-000776-QV for behave@ietf.org; Thu, 14 Dec 2006 10:28:10 -0500 Received: from maildialog.com (maildialog.com [195.159.98.119]) by lambda.sipfoundry.org (8.13.8/8.13.8) with ESMTP id kBEFRwqO013861 for ; Thu, 14 Dec 2006 09:28:03 -0600 (CST) (envelope-from aeh@db.org) Received: from [82.196.214.14] (helo=[192.168.1.100]) by maildialog.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51-maildialog) id 1GusCr-0004Nf-Ch; Thu, 14 Dec 2006 15:09:09 +0000 Message-ID: <458168CC.6070206@db.org> Date: Thu, 14 Dec 2006 16:07:56 +0100 From: "Alfred E. Heggestad" User-Agent: Icedove 1.5.0.8 (X11/20061116) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4544712F.9060806@ericsson.com> In-Reply-To: <4544712F.9060806@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Oscar Novo , Dan Wing , BEHAVE WG Subject: [BEHAVE] Re: [Ietf-behave] IPv6 extension draft 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 is there any chance of having the REQUESTED-ADDRESS-TYPE attribute as part of the main TURN specification? I don't understand why a new draft is needed just for one additional attribute.. /alfred Gonzalo Camarillo wrote: > Folks, > > given that we do not need to discuss this draft in San Diego, we did not > revise it for the meeting. However, we did not notice in time that the > previous revision (00) has expired. We will be submitting a new revision > (01) right after San Diego. > > In any case, we have posted a working copy of the draft at: > http://users.piuha.net/gonzalo/temp/draft-ietf-behave-turn-ipv6-01.txt > > There are no known open issues. We are just keeping it aligned to the > STUN and STUN relay usage specs. > > Cheers, > > Gonzalo > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@list.sipfoundry.org > https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 14 13:14:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guv5j-0005pH-0z; Thu, 14 Dec 2006 13:13:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guv5g-0005pB-W4 for behave@ietf.org; Thu, 14 Dec 2006 13:13:56 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guv5e-0000UD-LT for behave@ietf.org; Thu, 14 Dec 2006 13:13:56 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 Dec 2006 19:13:55 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kBEIDrFu003728; Thu, 14 Dec 2006 19:13:53 +0100 Received: from [63.246.199.162] (ams3-vpn-dhcp4693.cisco.com [10.61.82.84]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBEIDmAr018850; Thu, 14 Dec 2006 19:13:49 +0100 (MET) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0E554980@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF0E554980@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0865361D-67E1-4928-A20E-68FCE38649E7@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] adopt draft-macdonald-behave-nat-behavior-discovery-00.txt Date: Thu, 14 Dec 2006 13:14:00 -0500 To: Francois Audet X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=939; t=1166120034; x=1166984034; c=relaxed/simple; s=amsdkim2001; 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]=20adopt=20draft-macdonald-behave-nat-behavio r-discovery-00.txt |Sender:=20; bh=sHXDY62jA1SqXpQYzDXH6rxUa423Kf9dE8X5GxKdJY8=; b=K6PPji9o8zF5Ih2MWMUHXPlijLIFxlhGvjvYQhtHL5DeJY7c8U7whebOWyEiQuVHPMJoT+8d gZBo4mLmkuw8C4h5Zy3p4LDMfIH6Q1LdKccyQfWOZ08mZFlEvjUOSV22; Authentication-Results: ams-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: behave@ietf.org, Dan Wing 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 Dec 7, 2006, at 5:39 PM, Francois Audet wrote: > I strongly favor adopting this document. > > I find it will be very useful. > +1 > >> -----Original Message----- >> From: Dan Wing [mailto:dwing@cisco.com] >> Sent: Thursday, December 07, 2006 08:02 >> To: behave@ietf.org >> Subject: [BEHAVE] adopt >> draft-macdonald-behave-nat-behavior-discovery-00.txt >> >> In San Diego, there was consensus to adopt >> draft-macdonald-behave-nat-behavior-discovery-00.txt as a >> working group document. If anyone has changed their mind, or >> wishes to express their opinion about this document, please speak up. >> >> -d >> >> _______________________________________________ >> 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 Thu Dec 14 19:34:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv11F-0004oW-Az; Thu, 14 Dec 2006 19:33:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv11D-0004oQ-FX for behave@ietf.org; Thu, 14 Dec 2006 19:33:43 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gv119-0005x1-6Y for behave@ietf.org; Thu, 14 Dec 2006 19:33:43 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 14 Dec 2006 16:33:38 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id kBF0Xcmm029878 for ; Thu, 14 Dec 2006 16:33:38 -0800 Received: from dwingwxp (dhcp-128-107-163-183.cisco.com [128.107.163.183]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kBF0XcST020814 for ; Thu, 14 Dec 2006 16:33:38 -0800 (PST) From: "Dan Wing" To: Date: Thu, 14 Dec 2006 16:33:37 -0800 Message-ID: <023b01c71fe0$a9843e20$b7a36b80@amer.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: Accf4KkfqJY9EGLzSIKFJ6iT/TQQoQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=377; t=1166142818; x=1167006818; c=relaxed/simple; s=sjdkim5002; 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:=20rfc3489bis=20status |Sender:=20; bh=1ADia0YHcRP2iXOkNPLtBVXQDS5DLqhdd8Sn65MnM1k=; b=m2n5h/cxodXF0jI4+eZ0lz6ZBcZ5MAHhpR90ODATTAosxgPTxGZRWLdQaCddXO8hAkEO3cbY 976n9J+nnWDHzuqWnvwj0qsi9nIPtxljSq7OSZRfv6UUmOCzLZQiLmaC; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [BEHAVE] rfc3489bis status X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Thank you for all of the comments on draft-ietf-behave-rfc3489bis-05. Jonathan will be integrating the comments into the next revision of the document and expects to be finished in mid-January. We will have a second working group last call on draft-ietf-behave-rfc3489bis-06 shortly after it is posted. http://www.employees.org/behave/document-status.html -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 15 05:40:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvAU7-00029s-11; Fri, 15 Dec 2006 05:40:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvAU5-00029n-Hu for behave@ietf.org; Fri, 15 Dec 2006 05:40:09 -0500 Received: from lambda.sipfoundry.org ([72.232.205.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvAU2-0004gI-2k for behave@ietf.org; Fri, 15 Dec 2006 05:40:09 -0500 Received: from kyoto.netlab.nec.de (kyoto.netlab.nec.de [195.37.70.21]) by lambda.sipfoundry.org (8.13.8/8.13.8) with ESMTP id kBFAe0ZI082334 for ; Fri, 15 Dec 2006 04:40:05 -0600 (CST) (envelope-from lars.eggert@netlab.nec.de) Received: from lars.local (p54AD0902.dip0.t-ipconnect.de [84.173.9.2]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 6CBF413CF82; Fri, 15 Dec 2006 11:44:57 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id 2D96F2B05EE; Fri, 15 Dec 2006 11:39:55 +0100 (CET) In-Reply-To: <953beacc0612041024y445955d9g31e4bdd8e538327b@mail.gmail.com> References: <45325E87.4060007@db.org> <953beacc0612041024y445955d9g31e4bdd8e538327b@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <15ED0013-A9F2-4F32-AEBB-EEBED2607CFE@netlab.nec.de> From: Lars Eggert Subject: Re: [BEHAVE] Re: [Ietf-behave] turn02 REQUESTED-TRANSPORT Date: Fri, 15 Dec 2006 11:39:48 +0100 To: Rohan Mahy X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 1.2 (+) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: ietf-behave@list.sipfoundry.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: , Content-Type: multipart/mixed; boundary="===============0296423587==" Errors-To: behave-bounces@ietf.org --===============0296423587== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-48-1040911928; protocol="application/pkcs7-signature" --Apple-Mail-48-1040911928 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Rohan, On Dec 4, 2006, at 19:24, Rohan Mahy wrote: > My concern about using the IANA protocol registry is that it implies > that any protocol in that registry is usable, which is certainly not > the case. Also, TURN would not establish a registry of these values, > since defining a new transport would require a significant body of > normative text that the community would be unlikely to overlook. the suggestion wasn't to allow the entire IANA registry here, it was that the numeric values of the allowed protocols should be the ones used in the IANA registry. > On 10/15/06, Lars Eggert wrote: >> On Oct 16, 2006, at 1:15, Alfred E. Heggestad wrote: >> > Instead of defining two new values for UDP/TCP transport can we >> reuse >> > e.g. the values defined in netinet/in.h: >> >> These are taken from the IANA registry for protocol numbers (http:// >> www.iana.org/assignments/protocol-numbers), and I agree that using >> those numbers would be better than creating a new registry. Lars --Apple-Mail-48-1040911928 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKZDCCAwEw ggJqoAMCAQICEBCR/semQl5bz/x3jtiU02YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgxNjA5MTU0NloXDTA3MDgxNjA5MTU0 NlowYDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAL/+LXyqufw8ApYnCU24cnZ/H9S7ro4zZYeCqcyFqhwJpTcM8/yX 6Ms+16d2EtIceQS8Bas3GAUR+xfq0QI5dt8uIKM1Uy4trk8AAO0dh23+QTLw7toloArVngGIhUhC OTpVRR1bYfJTwPVpSAY43mbGhSGhwiu5035yKdYJezNWOXmuIO+lvXcD36hc5cU6AzRJkj0LYaFd WHjbfwzGmT7MO60p/7hT+aTv5xvTl/mcwslvm+KhKmJjoMYfSOF99xvuJE/rB7Ho3g6wDoeB2Tip 44Qq8CPmOHtCXzh/tF/bYo+OHStkPTzgPfOuNDMxa0/gAPEyELNL0Eh1/hC2TeMCAwEAAaM2MDQw JAYDVR0RBB0wG4EZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAHdaTI5TM5wV+LG2WW+CMEmxEyNhaRu3oca9T31HjbfHzvhVJe2fzKt1xBSo +hhCg0qKVFuE7yKxDH975Csq9jVvJJj3oL29RQjPnc3CgQqlMFJKHdJgterPQ+ZiCp05S9rbMhRl 1zxB/x+GvnDFHsXu19gA2dlynrdWN/G1BVWJMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzCCBBgwggOBoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwgb8xCzAJBgNVBAYTAkRFMRww GgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQK Ew5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMT EmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZTAeFw0wNDA2MTgxMTUzMDhaFw0wOTA2MTcxMTUzMDhaMIG/MQswCQYDVQQGEwJERTEcMBoG A1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMO TkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJr b2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMu ZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALQ5DCwTzpGu3RmzQY4KxiaQak/BwIW9Wk6K Mg+/V0aiWvlrz7uFdICBGVTKhyWr3F+GxRPCVTWqS9VEPf9A59DI9TFCS3FtraSx+w8ApQei8idb J0Lqu8tTz2O1gYR2dELID5wQH9dxIANt3bP39crgDZzGYxCJilcimFhADEgHAgMBAAGjggEgMIIB HDAdBgNVHQ4EFgQU6Hsv16oYecCFsl07g9gtjPEJo00wgewGA1UdIwSB5DCB4YAU6Hsv16oYecCF sl07g9gtjPEJo02hgcWkgcIwgb8xCzAJBgNVBAYTAkRFMRwwGgYDVQQIFBNCYWRlbi1Xw3VlcnR0 ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQKEw5ORUMgRXVyb3BlIEx0ZDEdMBsG A1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMTEmtvYmUubmV0bGFiLm5lYy5kZTEo MCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYIBADAMBgNVHRMEBTADAQH/ MA0GCSqGSIb3DQEBBQUAA4GBAJfoil3cAX3cUPMFrDdlW9DPMK/+QY8EHPOsnefm77h5CmmY6J+G 5Ydl9vyHxL76Opyg8cZWOOU/k9oVv7AvQ1GmIFqVFyWKQPfEhj+EWjEnUAcI7QDN8XER+U7XRvj6 yYysFgm2Tl30QCGvmESCgYIztCKMG2cLBkEosj2kWBbXMYIDsjCCA64CAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBCR/semQl5bz/x3jtiU02YwCQYFKw4D AhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMjE1 MTAzOTQ5WjAjBgkqhkiG9w0BCQQxFgQUlI3IeMF3wR0BLbAFxfOOCRoUxewwgdYGCSsGAQQBgjcQ BDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzAR BgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3 b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsqhkiG9w0BCRACCzGByKCBxTCB vzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhl aWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9y YXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJz LmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUABIIBAGNqkcaNAVvw1iTRyVWH 4h+Ad3uaE+lkafjrpT9KoxVHxnjvuTCI24LwaomQcSW8qonRtfTVxNj8jwqJuOh0hJJcRkdEohMC 3EAC/5GvvDMAXXUBmnTTBE77wJNhSoRvplgpHbjX1BSYAdnCvC52utR25QYQjypKo2gVlenwnF/O md1rWPqT/fLrMFfyUi3PT7K1AGVnGW1fDwb9gyggyyfqSXmAXhXPLzD0+n8091zQPwMVWs2I5PPY u74pW5bPmF2BlESyyZXXUpXAGzrdm2GnW36s74qhUXKx3NzbBqaCBD6sS1IW0c7p9KkGv1QRZhT3 ZhxtFr06iUAHrRrZGrUAAAAAAAA= --Apple-Mail-48-1040911928-- --===============0296423587== 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 --===============0296423587==-- From behave-bounces@ietf.org Fri Dec 15 17:03:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvL9W-0002WY-Dq; Fri, 15 Dec 2006 17:03:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvL9V-0002WT-Qb for behave@ietf.org; Fri, 15 Dec 2006 17:03:37 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvL9U-0001wL-KZ for behave@ietf.org; Fri, 15 Dec 2006 17:03:37 -0500 Received: from metro-north.cs.columbia.edu (metro-north.cs.columbia.edu [128.59.19.61]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id kBFM3Xx1002571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 15 Dec 2006 17:03:33 -0500 (EST) Received: from metro-north.cs.columbia.edu (localhost [127.0.0.1]) by metro-north.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id kBFM3Xxn012378 for ; Fri, 15 Dec 2006 17:03:33 -0500 (EST) Received: (from lennox@localhost) by metro-north.cs.columbia.edu (8.12.10/8.12.10/Submit) id kBFM3Tkf012374; Fri, 15 Dec 2006 17:03:29 -0500 (EST) X-Authentication-Warning: metro-north.cs.columbia.edu: lennox set sender to lennox@cs.columbia.edu using -f From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17795.7089.382567.788208@metro-north.cs.columbia.edu> Date: Fri, 15 Dec 2006 17:03:29 -0500 To: X-Mailer: VM 7.19 under Emacs 20.7.1 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [BEHAVE] Two rfc3489bis-05 nits 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 reading over RFC 3489bis, so I thought I'd throw my two cents in: 1. Why does the REALM attribute include quotes, when the NONCE attribute does not? Both these attributes' corresponding RFC 3261 parameter values have the grammar quoted-string. If there's a good reason for this, it should be explained; if not, it should be changed. 2. It's somewhat annoying that the only place to find attributes' type values is in the IANA registration section. Could they also be mentioned in the descriptions of the attributes in section 11? -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 15 20:59:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvOpq-0004U7-Rz; Fri, 15 Dec 2006 20:59:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvOpp-0004Ti-AZ for behave@ietf.org; Fri, 15 Dec 2006 20:59:33 -0500 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvOpo-0003Yc-P8 for behave@ietf.org; Fri, 15 Dec 2006 20:59:33 -0500 Received: by ug-out-1314.google.com with SMTP id 72so842482ugd for ; Fri, 15 Dec 2006 17:59:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dadePJTZURK5tjmXgsy1odkGf3LyEbaO0CfoRMkYRrKZdY+omBbX9/ieD2h87umSYAZbNulRfMRTy10BMW0CM8tuYcvWUV1ZVas5EQcGh3cmwbbca/dpj4KVZQxlUHpA6extMYICykLrLBJFAFZ0rAyl0qW0jfy5fCBGGK8ultc= Received: by 10.78.181.13 with SMTP id d13mr583656huf.1166234371258; Fri, 15 Dec 2006 17:59:31 -0800 (PST) Received: by 10.78.200.9 with HTTP; Fri, 15 Dec 2006 17:59:30 -0800 (PST) Message-ID: <953beacc0612151759u32dbc10di4bc92c40dfba960b@mail.gmail.com> Date: Fri, 15 Dec 2006 17:59:30 -0800 From: "Rohan Mahy" To: "Thomas LEVY" Subject: Re: [BEHAVE] Re: STUN/TURN framing or RTP framing In-Reply-To: <45810DDA.1020802@alcatel-lucent.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <457E8FF5.5020508@alcatel-lucent.fr> <381bea186305ebaca6aee2e51b2cd659@ekabal.com> <457EDD85.8010504@alcatel-lucent.fr> <953beacc0612121616x18235053gfe2aa3398103a3d2@mail.gmail.com> <45810DDA.1020802@alcatel-lucent.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: Rohan Mahy , behave@ietf.org, huitema@microsoft.com 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 Thomas, For UDP there are STUN packets addressed to/from the TURN relay and STUN packets address to/from the peer. The STUN packets addressed to or from the peer need to be wrapped in Send or Data indications, even if the peer is the active destination. The TCP framing could use the same approach, but we chose not to require this extra step. By including a type, the distinction between end-to-end data to the active destination and other messages is clearer. We could have decided to add this same type header to UDP, but then MTU-sized datagrams to the active destination would be unnecessarily fragmented. I hope this thread has provided you with some of the design motivations used, even if you do not agree with the specific trade-offs. For now, we have consensus to use the framing in the current document and no technical reason to make a change. thanks, -rohan On 12/14/06, Thomas LEVY wrote: > Hi Rohan, > > You talk about the need to separate (for inst: at the STUN/TURN server > level) the data packets from the STUN/control packets. > It is also what I called protocol identifiation in my first mail. > This need is the same for UDP packets than for TCP packets. > stun-bis specifies to use the magic cookie for that purpose. This is > true for UDP and for TCP. > Why is there a need to add a new mechanism for TCP (such as: a specific > framing) instead of the existing mechanism in stun-bis? > > Thomas > > Rohan Mahy a =E9crit : > > > Hi, > > > > Perhaps some use cases would help. All of these examples assume that > > the Active Destination is set to the peer: > > > > 1. RTP over UDP (no TURN) > > RTP header > > RTP payload > > > > 2. RTP over TCP (no TURN) > > Length=3D(length of RTP header+payload) > > RTP header > > RTP payload > > > > 3. TURN Allocation over TCP to a peer running RTP over UDP > > TURN TCP framing -- Type=3DData, Length=3D(length of RTP header+payload= ) > > RTP header > > RTP payload > > > > 4. TURN Allocation over TCP to a peer running STUN/ICE over UDP > > TURN TCP framing -- Type=3DData, Length=3D(length of peer-destined STUN > > message) > > STUN message > > > > 5. Control message about TURN Allocation over TCP > > TURN TCP framing -- Type=3DSTUN, Length=3D(length of STUN control messa= ge) > > STUN message > > > > 6. TURN Allocation over TCP to a peer running SIP over UDP > > TURN TCP framing -- Type=3DData, Length=3D(length of SIP message) > > SIP message > > > > 7. TURN Allocation over TCP to a peer running syslog over TCP > > TURN TCP framing -- Type=3DData, Length=3D(arbitrary length to the end = of > > data segment) > > some syslog stream data > > > > 8. TURN Allocation over TCP to a peer running RTP over TCP > > TURN TCP framing -- Type=3DData, Length=3D(length of RTP header+payload= + 2) > > RTP over TCP framing -- Length=3D(length of RTP header+payload) > > RTP header > > RTP payload > > > > A. Even if we decided to copy the same kind of framing used for RTP > > over TCP, we would still need to repeat the RTP over TCP framing when > > delivering to the peer (note the difference between #3 and #8). In > > other words, TURN relays arbitrary end-to-end data; it does not > > specially relay RTP from TCP to UDP. > > > > B. Since we need some framing only for consumption between the TURN > > client and the relay, it is a good idea for us to include the Type > > indicator so we can more easily distinguish between case #4 and #5. > > > > thanks, > > -rohan > > > > > > > > > > On 12/12/06, Thomas LEVY wrote: > > > >> Hi Rohan, > >> > >> The framing defined in rfc4571 (i.e: "having a 16-bit unsigned integer > >> LENGTH field" before the data) doesn't sound specific to me. > >> I don't see why it couldn't be applied to STUN or any other traffic? > >> > >> Thomas > >> > >> Rohan Mahy a =E9crit : > >> > >> > Hi Thomas, > >> > > >> > The TCP framing is needed to provide the length of non-STUN data ove= r > >> > TCP. > >> > The RTP framing over TCP was considered, but TURN needs a framing > >> > mechanism applicable to both RTP and non-RTP traffic. > >> > > >> > thanks, > >> > -rohan > >> > > >> > On Dec 12, 2006, at 3:18, Thomas LEVY wrote: > >> > > >> >> Hello all, > >> >> > >> >> I have a question related to the framing mechanism for > >> >> stream-oriented transports defined in draft-ietf-behave-turn-02. > >> >> I fully agree with the need for a framing mechanism when for instan= ce > >> >> STUN is over TCP. > >> >> However, it seems that the defined mechanism provides framing in > >> >> addition with protocol identification (with the use of the Type > >> field). > >> >> An other method for protocol identification (i.e: to distinguish ST= UN > >> >> packets from others) is also defined in stun-bis with the use of t= he > >> >> magic cookie. > >> >> Furthermore, RTP already specified a framing mechanism in rfc4571 > >> >> that could be applicable to STUN. > >> >> Thus, i am just wondering if - when defining the framing for STUN = - > >> >> you considered using the framing defined in rfc4571? > >> >> If so, what are the reasons for the definition of a new framing? > >> >> > >> >> On my opinion, i would be favorable to using the same framing for > >> >> STUN and RTP. > >> >> My main argument is the following: If you consider a RTP client tha= t > >> >> wants (or needs) to carry RTP over TCP. If the client sends its med= ia > >> >> directly to a peer, it must use the framing rfc4571 but if the clie= nt > >> >> sends its media through a relay (TURN) it must use the framing > >> >> defined in draft-ietf-behave-turn-02. I think it introduces a > >> >> complexity to RTP that shouldn't be aware of it > >> >> Furthermore, my "own personal developer experience" makes me think > >> >> that it would be easier to functionally separate framing from > >> >> protocol identification for the better design of a protocol stack. > >> >> > >> >> Thomas > >> > > >> > > >> > >> > >> _______________________________________________ > >> 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 Dec 18 17:09:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwQfM-0000hv-ON; Mon, 18 Dec 2006 17:09:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwQfM-0000hp-BR for behave@ietf.org; Mon, 18 Dec 2006 17:09:00 -0500 Received: from celine.siteprotect.com ([64.26.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwQfI-0002di-3A for behave@ietf.org; Mon, 18 Dec 2006 17:09:00 -0500 Received: from cornfed (c-24-9-79-73.hsd1.co.comcast.net [24.9.79.73]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id kBIM8nt04543 for ; Mon, 18 Dec 2006 16:08:49 -0600 Message-Id: <200612182208.kBIM8nt04543@celine.siteprotect.com> From: "Frank W. Miller" To: Date: Mon, 18 Dec 2006 15:08:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <953beacc0612151759u32dbc10di4bc92c40dfba960b@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AccgtgX9baR119HaRFeQuivUZRCeZgCOvS2w X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [BEHAVE] Skype NAT traversal link 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 Interesting link... http://www.heise-security.co.uk/articles/82481 FM _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 19 01:56:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwYsP-00036K-5Y; Tue, 19 Dec 2006 01:55:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwYsN-00035t-Fj for behave@ietf.org; Tue, 19 Dec 2006 01:54:59 -0500 Received: from wx-out-0506.google.com ([66.249.82.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwYsM-0002Wt-OP for behave@ietf.org; Tue, 19 Dec 2006 01:54:59 -0500 Received: by wx-out-0506.google.com with SMTP id h27so1632347wxd for ; Mon, 18 Dec 2006 22:54:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=a7moowBpiC4EgAWvPd42AQCJvdLf6T37k6UxvKJFIsbMNtqqtnZtiZ+t54mnbSzWjTdUnr7Xnn5R74eZ0JDavCk37ik4Zow5yx/eZiMy246nGpe4PT3u85KYbstzaUtT3dwA3ichJ8FmkJCjki4aktiiPG9AAYcPuQZrQ6z+pvg= Received: by 10.90.118.12 with SMTP id q12mr4837582agc.1166511298192; Mon, 18 Dec 2006 22:54:58 -0800 (PST) Received: by 10.90.90.18 with HTTP; Mon, 18 Dec 2006 22:54:58 -0800 (PST) Message-ID: Date: Tue, 19 Dec 2006 12:24:58 +0530 From: "Mayank Dev Sondhi" To: "Thomas LEVY" Subject: Re: [BEHAVE] Re: STUN/TURN framing or RTP framing In-Reply-To: <45810DE4.1060203@alcatel-lucent.fr> MIME-Version: 1.0 References: <457E8FF5.5020508@alcatel-lucent.fr> <381bea186305ebaca6aee2e51b2cd659@ekabal.com> <457EDD85.8010504@alcatel-lucent.fr> <953beacc0612121616x18235053gfe2aa3398103a3d2@mail.gmail.com> <45810DE4.1060203@alcatel-lucent.fr> X-Spam-Score: 0.1 (/) X-Scan-Signature: e3ebaaff3b3539efaf29ef65eea2aded Cc: Rohan Mahy , behave@ietf.org, huitema@microsoft.com 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="===============0120491799==" Errors-To: behave-bounces@ietf.org --===============0120491799== Content-Type: multipart/alternative; boundary="----=_Part_2296_31103920.1166511298144" ------=_Part_2296_31103920.1166511298144 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline mmm, no not exactly. I was highlighting a particular implementation problem that we forced ourselves into where separating out STUN from normal DATA traffic would be advantageous. Most protocols tend to separate signalling from the actual transmission of data, and this is a good thing. However in certain trivial protocols, if implementers can live with extra packet processing, it is good to also include this bifurcation in a "relaying" protocol like STUN(or actually TURN). Thus my implementation if it so desires can and should be easily abl= e to support me able to differentiate between control and data packets. Of course packets in a TCP sense are somewhat meaningless because of the streaming nature of the protocol itself. I used the example to bolster the case for not having a "MAGIC COOKIE" scenario for TCP. I am in agreement with you that the current framing desig= n for TCP STUN messages is better. Regards Mayank PS: Bad time to be in Seattle, power outages had me stranded high and dry..well not so dry! On 12/14/06, Thomas LEVY wrote: > > Hello Mayank > > Do you mean you would like to have the STUN traffic and the data traffic > sperated in order to do separate "socket recv"? > I believe the only way to do this would be to have 2 sockets (one for > the traffic and one for the control) but this is not in line with the > logic of TURN. > > Thomas > > Mayank Dev Sondhi a =E9crit : > > > Please excuse my discussion of an implementation specific scenario, > > but I believe it is pertinent. > > > > One of the advantages I can cite(having developed a particular > > implementation of the STUN/TURN relay) is that over TCP it is always > > advantageous to separate out control messages over normal data > > messages. We faced a problem wherein we had to implement some policing > > of the bandwidth, and we did this in the simplest and naive way by not > > doing recvs on our sockets if b/w was exceeded. Unfortunately control > > messages for cancellation of the operation would also get queued up > > with the net effect that a user cancel operation would also get stuck > > on the recv queue of the socket. > > > > If there was a framing mechanism that allowed us to distinguish this > > we could very easily separate out signalling from transfer in our > > stack without sacrificing on performance. I think this design helps us > > in that regard by including the type in the frame itself. > > > > Thanks > > Mayank > > > > On 12/13/06, *Rohan Mahy* > > wrote: > > > > Hi, > > > > Perhaps some use cases would help. All of these examples assume > that > > the Active Destination is set to the peer: > > > > 1. RTP over UDP (no TURN) > > RTP header > > RTP payload > > > > 2. RTP over TCP (no TURN) > > Length=3D(length of RTP header+payload) > > RTP header > > RTP payload > > > > 3. TURN Allocation over TCP to a peer running RTP over UDP > > TURN TCP framing -- Type=3DData, Length=3D(length of RTP header+pay= load) > > RTP header > > RTP payload > > > > 4. TURN Allocation over TCP to a peer running STUN/ICE over UDP > > TURN TCP framing -- Type=3DData, Length=3D(length of peer-destined > > STUN message) > > STUN message > > > > 5. Control message about TURN Allocation over TCP > > TURN TCP framing -- Type=3DSTUN, Length=3D(length of STUN control > message) > > STUN message > > > > 6. TURN Allocation over TCP to a peer running SIP over UDP > > TURN TCP framing -- Type=3DData, Length=3D(length of SIP message) > > SIP message > > > > 7. TURN Allocation over TCP to a peer running syslog over TCP > > TURN TCP framing -- Type=3DData, Length=3D(arbitrary length to the = end > of > > data segment) > > some syslog stream data > > > > 8. TURN Allocation over TCP to a peer running RTP over TCP > > TURN TCP framing -- Type=3DData, Length=3D(length of RTP > > header+payload + 2) > > RTP over TCP framing -- Length=3D(length of RTP header+payload) > > RTP header > > RTP payload > > > > A. Even if we decided to copy the same kind of framing used for RTP > > over TCP, we would still need to repeat the RTP over TCP framing > when > > delivering to the peer (note the difference between #3 and #8). In > > other words, TURN relays arbitrary end-to-end data; it does not > > specially relay RTP from TCP to UDP. > > > > B. Since we need some framing only for consumption between the TURN > > client and the relay, it is a good idea for us to include the Type > > indicator so we can more easily distinguish between case #4 and #5. > > > > thanks, > > -rohan > > > > > > > > > > On 12/12/06, Thomas LEVY < thomas.levy@alcatel-lucent.fr > > > wrote: > > > Hi Rohan, > > > > > > The framing defined in rfc4571 ( i.e: "having a 16-bit unsigned > > integer > > > LENGTH field" before the data) doesn't sound specific to me. > > > I don't see why it couldn't be applied to STUN or any other > > traffic? > > > > > > Thomas > > > > > > Rohan Mahy a =E9crit : > > > > > > > Hi Thomas, > > > > > > > > The TCP framing is needed to provide the length of non-STUN > > data over > > > > TCP. > > > > The RTP framing over TCP was considered, but TURN needs a > framing > > > > mechanism applicable to both RTP and non-RTP traffic. > > > > > > > > thanks, > > > > -rohan > > > > > > > > On Dec 12, 2006, at 3:18, Thomas LEVY wrote: > > > > > > > >> Hello all, > > > >> > > > >> I have a question related to the framing mechanism for > > > >> stream-oriented transports defined in > draft-ietf-behave-turn-02. > > > >> I fully agree with the need for a framing mechanism when for > > instance > > > >> STUN is over TCP. > > > >> However, it seems that the defined mechanism provides framing > in > > > >> addition with protocol identification (with the use of the > > Type field). > > > >> An other method for protocol identification ( i.e: to > > distinguish STUN > > > >> packets from others) is also defined in stun-bis with the use > > of the > > > >> magic cookie. > > > >> Furthermore, RTP already specified a framing mechanism in > > rfc4571 > > > >> that could be applicable to STUN. > > > >> Thus, i am just wondering if - when defining the framing for > > STUN - > > > >> you considered using the framing defined in rfc4571? > > > >> If so, what are the reasons for the definition of a new > framing? > > > >> > > > >> On my opinion, i would be favorable to using the same framing > for > > > >> STUN and RTP. > > > >> My main argument is the following: If you consider a RTP > > client that > > > >> wants (or needs) to carry RTP over TCP. If the client sends > > its media > > > >> directly to a peer, it must use the framing rfc4571 but if > > the client > > > >> sends its media through a relay (TURN) it must use the framing > > > >> defined in draft-ietf-behave-turn-02. I think it introduces a > > > >> complexity to RTP that shouldn't be aware of it > > > >> Furthermore, my "own personal developer experience" makes me > > think > > > >> that it would be easier to functionally separate framing from > > > >> protocol identification for the better design of a protocol > > stack. > > > >> > > > >> Thomas > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > ------=_Part_2296_31103920.1166511298144 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
mmm, no not exactly. I was highlighting a particular implementation pr= oblem that we forced ourselves into where separating out STUN from normal D= ATA traffic would be advantageous.
 
Most protocols tend to separate signalling from the actual transmissio= n of data, and this is a good thing. However in certain trivial protoc= ols, if implementers can live with extra packet processing, it is good= to also include this bifurcation in a "relaying" protocol like&n= bsp;STUN(or actually TURN). Thus my implementation if it so desires can and= should be easily able to support me able to differentiate between con= trol and data packets. Of course packets in a TCP sense are somewhat meanin= gless because of the streaming nature of the protocol itself.
 
I used the example to bolster the case for not having a "MAGIC CO= OKIE" scenario for TCP. I am in agreement with you that the current fr= aming design for TCP STUN messages is better.
 
Regards
Mayank
 
PS: Bad time to be in Seattle, power outages had me stranded high and = dry..well not so dry!

 
On 12/14/06, Thomas LEVY <thoma= s.levy@alcatel-lucent.fr > wrote:=20
Hello Mayank

Do you mean = you would like to have the STUN traffic and the data traffic
sperated in= order to do separate "socket recv"?=20
I believe the only way to do this would be to have 2 sockets (one forthe traffic and one for the control) but this is not in line with the
= logic of TURN.

Thomas

Mayank Dev Sondhi a =E9crit :

> Please excuse my discussion of an implementation specific scenario,> but I believe it is pertinent.
>
> One of the advantages = I can cite(having developed a particular
> implementation of the STUN= /TURN relay) is that over TCP it is always=20
> advantageous to separate out control messages over normal data
= > messages. We faced a problem wherein we had to implement some policing=
> of the bandwidth, and we did this in the simplest and naive way by= not=20
> doing recvs on our sockets if b/w was exceeded. Unfortunately cont= rol
> messages for cancellation of the operation would also get queue= d up
> with the net effect that a user cancel operation would also ge= t stuck=20
> on the recv queue of the socket.
>
> If there was a fr= aming mechanism that allowed us to distinguish this
> we could very e= asily separate out signalling from transfer in our
> stack without sa= crificing on performance. I think this design helps us=20
> in that regard by including the type in the frame itself.
><= br>> Thanks
> Mayank
>
> On 12/13/06, *Rohan Mahy* <= ; rohan.mahy@gmail.com
> <mailto: rohan.mahy@gmail.com>> wrote:
>
> &n= bsp;   Hi,
>
>     Perhaps some use cases would help.&nbs= p; All of these examples assume that
>     t= he Active Destination is set to the peer:
>
>   = ;  1. RTP over UDP (no TURN)
>     RTP heade= r
>     RTP payload
>
>     2. RTP over TCP (no TURN)
>&= nbsp;    Length=3D(length of RTP header+payload)
>&nbs= p;    RTP header
>     RTP payload=
>
>     3. TURN Allocation over TCP to a = peer running RTP over UDP
>     TURN TCP framing -- Type=3DData, Length=3D= (length of RTP header+payload)
>     RTP header>     RTP payload
>
>   = ;  4. TURN Allocation over TCP to a peer running STUN/ICE over UDP >     TURN TCP framing -- Type=3DData, Length=3D(le= ngth of peer-destined
>     STUN message)
>   &nb= sp; STUN message
>
>     5. Control message= about TURN Allocation over TCP
>     TURN TCP fr= aming -- Type=3DSTUN, Length=3D(length of STUN control message)
>&nb= sp;    STUN message
>
>     6. TURN Allocation over TCP to a p= eer running SIP over UDP
>     TURN TCP framing -= - Type=3DData, Length=3D(length of SIP message)
>   &n= bsp; SIP message
>
>     7. TURN Allocation= over TCP to a peer running syslog over TCP=20
>     TURN TCP framing -- Type=3DData, Length=3D= (arbitrary length to the end of
>     data segmen= t)
>     some syslog stream data
>
>&= nbsp;    8. TURN Allocation over TCP to a peer running RTP o= ver TCP=20
>     TURN TCP framing -- Type=3DData, Length=3D= (length of RTP
>     header+payload + 2)
>&= nbsp;    RTP over TCP framing -- Length=3D(length of RTP hea= der+payload)
>     RTP header
>  =    RTP payload
>
>     A. Even if we decided to copy the same= kind of framing used for RTP
>     over TCP, we = would still need to repeat the RTP over TCP framing when
>  = ;   delivering to the peer (note the difference between #3 and #8= ). In=20
>     other words, TURN relays arbitrary end-to-= end data; it does not
>     specially relay RTP f= rom TCP to UDP.
>
>     B. Since we need so= me framing only for consumption between the TURN
>   &= nbsp; client and the relay, it is a good idea for us to include the Type=20
>     indicator so we can more easily distinguis= h between case #4 and #5.
>
>     thanks,>     -rohan
>
>
>
>
&g= t;     On 12/12/06, Thomas LEVY < thomas.levy@alcatel-lucent.fr
>     <mail= to:thomas.levy@alcatel-luc= ent.fr>> wrote:
>     > Hi Rohan,
>   &n= bsp; >
>     > The framing defined in rfc45= 71 ( i.e: "having a 16-bit unsigned
>     in= teger
>     > LENGTH field" before the da= ta) doesn't sound specific to me.
>     > I don't see why it couldn't b= e applied to STUN or any other
>     traffic?>     >
>     > Tho= mas
>     >
>     &g= t; Rohan Mahy a =E9crit :
>     >
>     > > Hi Thomas,
>   =   > >
>     > > The TCP framing = is needed to provide the length of non-STUN
>    = ; data over
>     > > TCP.
> &nb= sp;   > > The RTP framing over TCP was considered, but TURN= needs a framing
>     > > mechanism applicable to both RTP= and non-RTP traffic.
>     > >
>&nb= sp;    > > thanks,
>     >= ; > -rohan
>     > >
>  =    > > On Dec 12, 2006, at 3:18, Thomas LEVY wrote:
>     > >
>     = > >> Hello all,
>     > >>
= >     > >> I have a question related to the= framing mechanism for
>     > >> stream= -oriented transports defined in draft-ietf-behave-turn-02.
>     > >> I fully agree with the need = for a framing mechanism when for
>     instance<= br>>     > >> STUN is over TCP.
>&nbs= p;    > >> However, it seems that the defined mecha= nism provides framing in
>     > >> addition with protocol ident= ification (with the use of the
>     Type field)= .
>     > >> An other method for protoco= l identification ( i.e: to
>     distinguish STUN=
>     > >> packets from others) is also def= ined in stun-bis with the use
>     of &nbs= p;the
>     > >> magic cookie.
>&n= bsp;    > >> Furthermore, RTP already specified a f= raming mechanism in
>     rfc4571
>     &g= t; >> that could be applicable to STUN.
>   &nb= sp; > >> Thus, i am just wondering if  - when defining t= he framing for
>     STUN -
>  &n= bsp;  > >> you considered using the framing defined in rfc457= 1?
>     > >> If so, what are the reasons = for the definition of a new framing?
>     > = >>
>     > >> On my opinion, i wou= ld be favorable to using the same framing for
>   &nbs= p; > >> STUN and RTP.
>     > >> My main argument is the foll= owing: If you consider a RTP
>     client that>     > >> wants (or needs) to carry RTP = over TCP. If the client sends
>     its media
= >     > >> directly to a peer, it must use = the framing rfc4571 but if
>     the client
>    = > >> sends its media through a relay (TURN) it must use the frami= ng
>     > >> defined in draft-ietf-beha= ve-turn-02. I think it introduces a
>     > &g= t;> complexity to RTP that shouldn't be aware of it=20
>     > >> Furthermore, my "own pe= rsonal developer experience" makes me
>     = think
>     > >> that it would be easier= to functionally separate framing from
>     >= >> protocol identification for the better design of a protocol=20
>     stack.
>     >= ; >>
>     > >> Thomas
>&nbs= p;    > >
>     > >>     >
>     >
= >     > _________________________________________= ______=20
>     > Behave mailing list
> &nbs= p;   > Behave@ietf.org = <mailto: Behave@ietf.org>
>     > https://www1.ietf.org/mailman/l= istinfo/behave
>     >
>
>     _= ______________________________________________
>   &nb= sp; Behave mailing list
>     Behave@ietf.org <mailto:Behave@ie= tf.org>
>     https://www1.ietf.org/mailman/listinfo/behave
>
>


------=_Part_2296_31103920.1166511298144-- --===============0120491799== 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 --===============0120491799==-- From behave-bounces@ietf.org Tue Dec 19 06:18:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwczM-00021y-Vs; Tue, 19 Dec 2006 06:18:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwczL-00021S-Ib for behave@ietf.org; Tue, 19 Dec 2006 06:18:27 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwczK-0005fG-Ut for behave@ietf.org; Tue, 19 Dec 2006 06:18:27 -0500 Received: from frmail35.netfr.alcatel.fr (frmail35.netfr.alcatel.fr [155.132.251.35]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kBJBIIvB027660; Tue, 19 Dec 2006 12:18:18 +0100 Received: from [172.25.78.42] ([172.25.78.42]) by frmail35.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2006121912181185:8805 ; Tue, 19 Dec 2006 12:18:11 +0100 Message-ID: <4587CA74.9000003@alcatel-lucent.fr> Date: Tue, 19 Dec 2006 12:18:12 +0100 From: Thomas.Levy@alcatel-lucent.fr User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en, fr-fr MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [BEHAVE] Re: STUN/TURN framing or RTP framing References: <457E8FF5.5020508@alcatel-lucent.fr> <381bea186305ebaca6aee2e51b2cd659@ekabal.com> <457EDD85.8010504@alcatel-lucent.fr> <953beacc0612121616x18235053gfe2aa3398103a3d2@mail.gmail.com> <45810DDA.1020802@alcatel-lucent.fr> <953beacc0612151759u32dbc10di4bc92c40dfba960b@mail.gmail.com> In-Reply-To: <953beacc0612151759u32dbc10di4bc92c40dfba960b@mail.gmail.com> X-MIMETrack: Itemize by SMTP Server on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/19/2006 12:18:11, Serialize by Router on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/19/2006 12:18:13 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: Rohan Mahy , behave@ietf.org, huitema@microsoft.com 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 Rohan, Thanks for your explanations, I was still thinking about the=20 DESTINATION-ADDRESS attribute defined previously in turn that seemed to=20 avoid wrapping. I now understand better the motivation for the TCP framing. It introduces an optimization for TCP in comparision to UDP (to avoid=20 wrapping STUN packets in STUN packets). Thomas Rohan Mahy a =E9crit : > Hi Thomas, > > For UDP there are STUN packets addressed to/from the TURN relay and > STUN packets address to/from the peer. The STUN packets addressed to > or from the peer need to be wrapped in Send or Data indications, even > if the peer is the active destination. > > The TCP framing could use the same approach, but we chose not to > require this extra step. By including a type, the distinction between > end-to-end data to the active destination and other messages is > clearer. We could have decided to add this same type header to UDP, > but then MTU-sized datagrams to the active destination would be > unnecessarily fragmented. > > I hope this thread has provided you with some of the design > motivations used, even if you do not agree with the specific > trade-offs. For now, we have consensus to use the framing in the > current document and no technical reason to make a change. > > thanks, > -rohan > > > On 12/14/06, Thomas LEVY wrote: > >> Hi Rohan, >> >> You talk about the need to separate (for inst: at the STUN/TURN server >> level) the data packets from the STUN/control packets. >> It is also what I called protocol identifiation in my first mail. >> This need is the same for UDP packets than for TCP packets. >> stun-bis specifies to use the magic cookie for that purpose. This is >> true for UDP and for TCP. >> Why is there a need to add a new mechanism for TCP (such as: a specific >> framing) instead of the existing mechanism in stun-bis? >> >> Thomas >> >> Rohan Mahy a =E9crit : >> >> > Hi, >> > >> > Perhaps some use cases would help. All of these examples assume that >> > the Active Destination is set to the peer: >> > >> > 1. RTP over UDP (no TURN) >> > RTP header >> > RTP payload >> > >> > 2. RTP over TCP (no TURN) >> > Length=3D(length of RTP header+payload) >> > RTP header >> > RTP payload >> > >> > 3. TURN Allocation over TCP to a peer running RTP over UDP >> > TURN TCP framing -- Type=3DData, Length=3D(length of RTP header+payloa= d) >> > RTP header >> > RTP payload >> > >> > 4. TURN Allocation over TCP to a peer running STUN/ICE over UDP >> > TURN TCP framing -- Type=3DData, Length=3D(length of peer-destined STUN >> > message) >> > STUN message >> > >> > 5. Control message about TURN Allocation over TCP >> > TURN TCP framing -- Type=3DSTUN, Length=3D(length of STUN control mess= age) >> > STUN message >> > >> > 6. TURN Allocation over TCP to a peer running SIP over UDP >> > TURN TCP framing -- Type=3DData, Length=3D(length of SIP message) >> > SIP message >> > >> > 7. TURN Allocation over TCP to a peer running syslog over TCP >> > TURN TCP framing -- Type=3DData, Length=3D(arbitrary length to the end= of >> > data segment) >> > some syslog stream data >> > >> > 8. TURN Allocation over TCP to a peer running RTP over TCP >> > TURN TCP framing -- Type=3DData, Length=3D(length of RTP header+payloa= d=20 >> + 2) >> > RTP over TCP framing -- Length=3D(length of RTP header+payload) >> > RTP header >> > RTP payload >> > >> > A. Even if we decided to copy the same kind of framing used for RTP >> > over TCP, we would still need to repeat the RTP over TCP framing when >> > delivering to the peer (note the difference between #3 and #8). In >> > other words, TURN relays arbitrary end-to-end data; it does not >> > specially relay RTP from TCP to UDP. >> > >> > B. Since we need some framing only for consumption between the TURN >> > client and the relay, it is a good idea for us to include the Type >> > indicator so we can more easily distinguish between case #4 and #5. >> > >> > thanks, >> > -rohan >> > >> > >> > >> > >> > On 12/12/06, Thomas LEVY wrote: >> > >> >> Hi Rohan, >> >> >> >> The framing defined in rfc4571 (i.e: "having a 16-bit unsigned=20 >> integer >> >> LENGTH field" before the data) doesn't sound specific to me. >> >> I don't see why it couldn't be applied to STUN or any other traffic? >> >> >> >> Thomas >> >> >> >> Rohan Mahy a =E9crit : >> >> >> >> > Hi Thomas, >> >> > >> >> > The TCP framing is needed to provide the length of non-STUN data=20 >> over >> >> > TCP. >> >> > The RTP framing over TCP was considered, but TURN needs a framing >> >> > mechanism applicable to both RTP and non-RTP traffic. >> >> > >> >> > thanks, >> >> > -rohan >> >> > >> >> > On Dec 12, 2006, at 3:18, Thomas LEVY wrote: >> >> > >> >> >> Hello all, >> >> >> >> >> >> I have a question related to the framing mechanism for >> >> >> stream-oriented transports defined in draft-ietf-behave-turn-02. >> >> >> I fully agree with the need for a framing mechanism when for=20 >> instance >> >> >> STUN is over TCP. >> >> >> However, it seems that the defined mechanism provides framing in >> >> >> addition with protocol identification (with the use of the Type >> >> field). >> >> >> An other method for protocol identification (i.e: to=20 >> distinguish STUN >> >> >> packets from others) is also defined in stun-bis with the use=20 >> of the >> >> >> magic cookie. >> >> >> Furthermore, RTP already specified a framing mechanism in rfc4571 >> >> >> that could be applicable to STUN. >> >> >> Thus, i am just wondering if - when defining the framing for=20 >> STUN - >> >> >> you considered using the framing defined in rfc4571? >> >> >> If so, what are the reasons for the definition of a new framing? >> >> >> >> >> >> On my opinion, i would be favorable to using the same framing for >> >> >> STUN and RTP. >> >> >> My main argument is the following: If you consider a RTP client=20 >> that >> >> >> wants (or needs) to carry RTP over TCP. If the client sends its=20 >> media >> >> >> directly to a peer, it must use the framing rfc4571 but if the=20 >> client >> >> >> sends its media through a relay (TURN) it must use the framing >> >> >> defined in draft-ietf-behave-turn-02. I think it introduces a >> >> >> complexity to RTP that shouldn't be aware of it >> >> >> Furthermore, my "own personal developer experience" makes me think >> >> >> that it would be easier to functionally separate framing from >> >> >> protocol identification for the better design of a protocol stack. >> >> >> >> >> >> Thomas >> >> > >> >> > >> >> >> >> >> >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >> >> 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 Dec 19 12:27:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwijP-0006Ig-2U; Tue, 19 Dec 2006 12:26:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwijN-0006IZ-PE for behave@ietf.org; Tue, 19 Dec 2006 12:26:21 -0500 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwijI-0003wg-UL for behave@ietf.org; Tue, 19 Dec 2006 12:26:21 -0500 Received: by ug-out-1314.google.com with SMTP id 72so1731079ugd for ; Tue, 19 Dec 2006 09:26:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=hHbTI9fxH+qa3t9fxK3NdUHFH6xZrv1Z2b0X2/LMI1gtCzXykWHphfuceGjiqEXgX9JpaxgsiuLudgvf/84LI0a3aKUuFV4FO9FOwJnYS9Quf0EoLHP3EsNQo2CoLE/lGDlAblM7vQlN0TEW7EXVcEpwKj+yHKa9C4RpiMJb59Q= Received: by 10.66.232.11 with SMTP id e11mr8738293ugh.1166549175625; Tue, 19 Dec 2006 09:26:15 -0800 (PST) Received: by 10.67.19.15 with HTTP; Tue, 19 Dec 2006 09:26:15 -0800 (PST) Message-ID: Date: Tue, 19 Dec 2006 12:26:15 -0500 From: "Adam Fisk" To: "Pete Cordell" Subject: Re: Fw: [BEHAVE] STUN -> Session Traversal Underneath NAT In-Reply-To: <003701c71dd0$d00e9c50$1c00a8c0@Codalogic> MIME-Version: 1.0 References: <003701c71dd0$d00e9c50$1c00a8c0@Codalogic> X-Spam-Score: 0.1 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b 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: , Content-Type: multipart/mixed; boundary="===============1672320054==" Errors-To: behave-bounces@ietf.org --===============1672320054== Content-Type: multipart/alternative; boundary="----=_Part_12152_28023168.1166549175518" ------=_Part_12152_28023168.1166549175518 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I like the "STUN: Set of Tools Useful for NAT" too. The "traversal" in the name confused me forever before I finally got my hands dirty and read the darn thing. The fact that ICE does the heavy lifting on the traversal side just must confuse many other people out there too. I think a name change is a great idea! -Adam On 12/12/06, Pete Cordell wrote: > > Summarising back to the list... > > The final name selected by those that gave input is: > > Session Traversal Utilities for NAT > > Thanks to all those that contributed to the name. > > Pete. > -- > ----- Original Message ----- > From: "Francois Audet" > To: "Jonathan Rosenberg" > Cc: "Pete Cordell" ; "Mayank Dev Sondhi" > ; "Rodrig, Benny (Benny)" ; "Philip > Matthews" > Sent: Thursday, December 07, 2006 5:00 PM > Subject: RE: [BEHAVE] STUN -> Session Traversal Underneath NAT > > > Done deal. > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > Sent: Thursday, December 07, 2006 08:59 > > To: Audet, Francois (SC100:3055) > > Cc: Pete Cordell; Mayank Dev Sondhi; Rodrig, Benny (Benny); > > Philip Matthews > > Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT > > > > Its a tough call, but I have a slight preference for "Session > > Traversal Utilities for NAT". I think its more or less saying > > the same thing as "Set of Tools for Usage with NAT", but I do > > like retaining "traversal". > > So, if its OK, lets go with that. > > > > -Jonathan R. > > > > Francois Audet wrote: > > > > > I'll defer to Jonathan... > > > > > > I still think my definition was more "accurate" of what the > > document > > > does. > > > > > > > > >>-----Original Message----- > > >>From: Pete Cordell [mailto:pete@tech-know-ware.com] > > >>Sent: Wednesday, December 06, 2006 01:22 > > >>To: Mayank Dev Sondhi; Rodrig, Benny (Benny) > > >>Cc: Audet, Francois (SC100:3055); Jonathan Rosenberg; > > Philip Matthews > > >>Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT > > >> > > >>Off list... > > >> > > >>Again, this is fine by me. I'm happy to leave it to Jonathan (or > > >>Francois) to decide if they prefer this option. > > >> > > >>Pete. > > >>-- > > >>============================================= > > >>Pete Cordell > > >>Tech-Know-Ware Ltd > > >>for XML to C++ data binding visit > > >>http://www.tech-know-ware.com/lmx > > >>(or http://www.xml2cpp.com) > > >>============================================= > > >> > > >>----- Original Message ----- > > >>From: "Mayank Dev Sondhi" > > >>To: "Rodrig, Benny (Benny)" > > >>Cc: "Pete Cordell" ; > > >>"Francois Audet" > > >>; "Jonathan Rosenberg" > > ; "Philip > > >>Matthews" ; > > >> > > >>Sent: Wednesday, December 06, 2006 7:13 AM > > >>Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT > > >> > > >> > > >> > > >>>Nice, I spent quite a lot of time thinking of words > > >> > > >>beginning with "U" > > >> > > >>>until > > >>>finally giving up. > > >>> > > >>>On 12/6/06, Rodrig, Benny (Benny) wrote: > > >>> > > >>>>How about "Session Traversal Utilities for NAT"? Similar > > >> > > >>to "set of > > >> > > >>>>tools" but still keeping the meaningful "traversal". > > >>>> > > >>>>-----Original Message----- > > >>>>From: Pete Cordell [mailto:pete.cordell@tech-know-ware.com] > > >>>>Sent: Friday, December 01, 2006 5:43 PM > > >>>>To: Francois Audet; Jonathan Rosenberg > > >>>>Cc: ietf-behave@list.sipfoundry.org > > >>>>Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT > > >>>> > > >>>>Excellent. All sorted. > > >>>> > > >>>>Pete. > > >>>>----- Original Message ----- > > >>>>From: "Francois Audet" > > >>>>To: "Jonathan Rosenberg" ; "Pete Cordell" > > >>>> > > >>>>Cc: "Philip Matthews" ; > > >>>> > > >>>>Sent: Friday, December 01, 2006 10:09 PM > > >>>>Subject: RE: [BEHAVE] STUN -> Session Traversal Underneath NAT > > >>>> > > >>>> > > >>>>Thanks. > > >>>> > > >>>>By the way, I got the idea by reading the Abstract which > > >> > > >>pretty much > > >> > > >>>>says exactly that. > > >>>> > > >>>> > > >>>>>-----Original Message----- > > >>>>>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > >>>>>Sent: Friday, December 01, 2006 14:01 > > >>>>>To: Pete Cordell > > >>>>>Cc: Philip Matthews; Audet, Francois (SC100:3055); > > >>>>>ietf-behave@list.sipfoundry.org > > >>>>>Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT > > >>>>> > > >>>>>Ahhh. Nothing brings out opinions like a naming debate. > > >>>>> > > >>>>>I think Francois got it right. I'd prefer "STUN: Set of Tools > > >>>>>Useful for NAT". I like semi-derogatory things like > > >> > > >>Uncorking and > > >> > > >>>>>Unblocking more for working group names (which is an > > >> > > >>IETF insider > > >> > > >>>>>thing) and not protocol names (which are read by everyone). > > >>>> > > >>>>-- > > >>>>============================================= > > >>>>Pete Cordell > > >>>>Tech-Know-Ware Ltd > > >>>>for XML to C++ data binding visit > > >>>>http://www.tech-know-ware.com/lmx > > >>>>(or http://www.xml2cpp.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 > > >>>> > > >>> > > >> > > >> > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > ------=_Part_12152_28023168.1166549175518 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I like the "STUN: Set of Tools Useful for NAT" too.  The "traversal" in the name confused me forever before I finally got my hands dirty and read the darn thing.  The fact that ICE does the heavy lifting on the traversal side just must confuse many other people out there too. 

I think a name change is a great idea!

-Adam


On 12/12/06, Pete Cordell <pete.cordell@tech-know-ware.com > wrote:
Summarising back to the list...

The final name selected by those that gave input is:

    Session Traversal Utilities for NAT

Thanks to all those that contributed to the name.

Pete.
--
----- Original Message -----
From: "Francois Audet" < audet@nortel.com>
To: "Jonathan Rosenberg" <jdrosen@cisco.com>
Cc: "Pete Cordell" <pete@tech-know-ware.com >; "Mayank Dev Sondhi"
<msondhi@gmail.com>; "Rodrig, Benny (Benny)" <brodrig@avaya.com>; "Philip
Matthews" <philip_matthews@magma.ca>
Sent: Thursday, December 07, 2006 5:00 PM
Subject: RE: [BEHAVE] STUN -> Session Traversal Underneath NAT


Done deal.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]
> Sent: Thursday, December 07, 2006 08:59
> To: Audet, Francois (SC100:3055)
> Cc: Pete Cordell; Mayank Dev Sondhi; Rodrig, Benny (Benny);
> Philip Matthews
> Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT
>
> Its a tough call, but I have a slight preference for "Session
> Traversal Utilities for NAT". I think its more or less saying
> the same thing as "Set of Tools for Usage with NAT", but I do
> like retaining "traversal".
> So, if its OK, lets go with that.
>
> -Jonathan R.
>
> Francois Audet wrote:
>
> > I'll defer to Jonathan...
> >
> > I still think my definition was more "accurate" of what the
> document
> > does.
> >
> >
> >>-----Original Message-----
> >>From: Pete Cordell [mailto:pete@tech-know-ware.com]
> >>Sent: Wednesday, December 06, 2006 01:22
> >>To: Mayank Dev Sondhi; Rodrig, Benny (Benny)
> >>Cc: Audet, Francois (SC100:3055); Jonathan Rosenberg;
> Philip Matthews
> >>Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT
> >>
> >>Off list...
> >>
> >>Again, this is fine by me.  I'm happy to leave it to Jonathan (or
> >>Francois) to decide if they prefer this option.
> >>
> >>Pete.
> >>--
> >>=============================================
> >>Pete Cordell
> >>Tech-Know-Ware Ltd
> >>for XML to C++ data binding visit
> >>http://www.tech-know-ware.com/lmx
> >>(or http://www.xml2cpp.com)
> >>=============================================
> >>
> >>----- Original Message -----
> >>From: "Mayank Dev Sondhi" <msondhi@gmail.com>
> >>To: "Rodrig, Benny (Benny)" < brodrig@avaya.com>
> >>Cc: "Pete Cordell" <pete.cordell@tech-know-ware.com>;
> >>"Francois Audet"
> >><audet@nortel.com>; "Jonathan Rosenberg"
> <jdrosen@cisco.com>; "Philip
> >>Matthews" < philip_matthews@magma.ca>;
> >><ietf-behave@list.sipfoundry.org>
> >>Sent: Wednesday, December 06, 2006 7:13 AM
> >>Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT
> >>
> >>
> >>
> >>>Nice, I spent quite a lot of time thinking of words
> >>
> >>beginning with "U"
> >>
> >>>until
> >>>finally giving up.
> >>>
> >>>On 12/6/06, Rodrig, Benny (Benny) < brodrig@avaya.com> wrote:
> >>>
> >>>>How about "Session Traversal Utilities for NAT"? Similar
> >>
> >>to "set of
> >>
> >>>>tools" but still keeping the meaningful "traversal".
> >>>>
> >>>>-----Original Message-----
> >>>>From: Pete Cordell [mailto:pete.cordell@tech-know-ware.com]
> >>>>Sent: Friday, December 01, 2006 5:43 PM
> >>>>To: Francois Audet; Jonathan Rosenberg
> >>>>Cc: ietf-behave@list.sipfoundry.org
> >>>>Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT
> >>>>
> >>>>Excellent.  All sorted.
> >>>>
> >>>>Pete.
> >>>>----- Original Message -----
> >>>>From: "Francois Audet" < audet@nortel.com>
> >>>>To: "Jonathan Rosenberg" <jdrosen@cisco.com>; "Pete Cordell"
> >>>>< pete.cordell@tech-know-ware.com>
> >>>>Cc: "Philip Matthews" <philip_matthews@magma.ca>;
> >>>><ietf-behave@list.sipfoundry.org>
> >>>>Sent: Friday, December 01, 2006 10:09 PM
> >>>>Subject: RE: [BEHAVE] STUN -> Session Traversal Underneath NAT
> >>>>
> >>>>
> >>>>Thanks.
> >>>>
> >>>>By the way, I got the idea by reading the Abstract which
> >>
> >>pretty much
> >>
> >>>>says exactly that.
> >>>>
> >>>>
> >>>>>-----Original Message-----
> >>>>>From: Jonathan Rosenberg [mailto: jdrosen@cisco.com]
> >>>>>Sent: Friday, December 01, 2006 14:01
> >>>>>To: Pete Cordell
> >>>>>Cc: Philip Matthews; Audet, Francois (SC100:3055);
> >>>>>ietf-behave@list.sipfoundry.org
> >>>>>Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT
> >>>>>
> >>>>>Ahhh. Nothing brings out opinions like a naming debate.
> >>>>>
> >>>>>I think Francois got it right. I'd prefer "STUN: Set of Tools
> >>>>>Useful for NAT". I like semi-derogatory things like
> >>
> >>Uncorking and
> >>
> >>>>>Unblocking more for working group names (which is an
> >>
> >>IETF insider
> >>
> >>>>>thing) and not protocol names (which are read by everyone).
> >>>>
> >>>>--
> >>>>=============================================
> >>>>Pete Cordell
> >>>>Tech-Know-Ware Ltd
> >>>>for XML to C++ data binding visit
> >>>>http://www.tech-know-ware.com/lmx
> >>>>(or http://www.xml2cpp.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
> >>>>
> >>>
> >>
> >>
> >
>
> --
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   Parsippany, NJ
> 07054-2711
> Cisco Systems
> jdrosen@cisco.com                              FAX:   (973) 952-5050
> http://www.jdrosen.net                          PHONE: (973) 952-5000
> http://www.cisco.com
>



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

------=_Part_12152_28023168.1166549175518-- --===============1672320054== 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 --===============1672320054==-- From behave-bounces@ietf.org Tue Dec 19 17:36:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwnYe-0003Le-VO; Tue, 19 Dec 2006 17:35:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwnYe-0003LZ-30 for behave@ietf.org; Tue, 19 Dec 2006 17:35:36 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwnYd-0002J9-6r for behave@ietf.org; Tue, 19 Dec 2006 17:35:36 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kBJMZOL05297; Tue, 19 Dec 2006 17:35:25 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [BEHAVE] Re: STUN/TURN framing or RTP framing Date: Tue, 19 Dec 2006 16:35:23 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437111FC6EE4@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Re: STUN/TURN framing or RTP framing Thread-Index: AccjOwrVd/8IXah2THq4ddQfVRJ6dwAZtxBg From: "Brian Stucker" To: "Mayank Dev Sondhi" , "Thomas LEVY" X-Spam-Score: 0.1 (/) X-Scan-Signature: a5514bacad4d93d5535dfe9fdc83bbb7 Cc: Rohan Mahy , behave@ietf.org, huitema@microsoft.com 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="===============0572348417==" Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. --===============0572348417== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C723BD.F929335E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C723BD.F929335E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bifurcation of media and signaling, where both are handled by the same = network element causes a doubling (or more) of the number of ports = required to support a particular data flow. This doubles (or more) the = cost of deploying a TURN server into a network. =20 Also, given that TURN is being used to relay around NATs, and the recent = discussions around the benefits of multiplexing RTCP and RTP over the = same connection because of NAT complications, it seems like it would be = tricky to justify why it's 'a good thing' (tm) to multiplex the media = and the media signaling (RTCP+RTP) but not the media/media signaling and = the TURN signaling. =20 Regards, Brian ________________________________ From: Mayank Dev Sondhi [mailto:msondhi@gmail.com]=20 Sent: Tuesday, December 19, 2006 12:55 AM To: Thomas LEVY Cc: Rohan Mahy; behave@ietf.org; huitema@microsoft.com Subject: Re: [BEHAVE] Re: STUN/TURN framing or RTP framing =09 =09 mmm, no not exactly. I was highlighting a particular implementation = problem that we forced ourselves into where separating out STUN from = normal DATA traffic would be advantageous. =20 Most protocols tend to separate signalling from the actual transmission = of data, and this is a good thing. However in certain trivial protocols, = if implementers can live with extra packet processing, it is good to = also include this bifurcation in a "relaying" protocol like STUN(or = actually TURN). Thus my implementation if it so desires can and should = be easily able to support me able to differentiate between control and = data packets. Of course packets in a TCP sense are somewhat meaningless = because of the streaming nature of the protocol itself.=20 =20 I used the example to bolster the case for not having a "MAGIC COOKIE" = scenario for TCP. I am in agreement with you that the current framing = design for TCP STUN messages is better. =20 Regards Mayank =20 PS: Bad time to be in Seattle, power outages had me stranded high and = dry..well not so dry! =09 =20 On 12/14/06, Thomas LEVY wrote:=20 Hello Mayank =09 Do you mean you would like to have the STUN traffic and the data = traffic sperated in order to do separate "socket recv"?=20 I believe the only way to do this would be to have 2 sockets (one for the traffic and one for the control) but this is not in line with the logic of TURN. =09 Thomas =09 Mayank Dev Sondhi a =E9crit : =09 > Please excuse my discussion of an implementation specific scenario, > but I believe it is pertinent. > > One of the advantages I can cite(having developed a particular > implementation of the STUN/TURN relay) is that over TCP it is always = > advantageous to separate out control messages over normal data > messages. We faced a problem wherein we had to implement some = policing > of the bandwidth, and we did this in the simplest and naive way by = not=20 > doing recvs on our sockets if b/w was exceeded. Unfortunately = control > messages for cancellation of the operation would also get queued up > with the net effect that a user cancel operation would also get = stuck=20 > on the recv queue of the socket. > > If there was a framing mechanism that allowed us to distinguish this > we could very easily separate out signalling from transfer in our > stack without sacrificing on performance. I think this design helps = us=20 > in that regard by including the type in the frame itself. > > Thanks > Mayank > > On 12/13/06, *Rohan Mahy* < rohan.mahy@gmail.com = =20 > > wrote: > > Hi, > > Perhaps some use cases would help. All of these examples assume = that > the Active Destination is set to the peer:=20 > > 1. RTP over UDP (no TURN) > RTP header > RTP payload=20 > > 2. RTP over TCP (no TURN) > Length=3D(length of RTP header+payload) > RTP header > RTP payload=20 > > 3. TURN Allocation over TCP to a peer running RTP over UDP=20 > TURN TCP framing -- Type=3DData, Length=3D(length of RTP = header+payload) > RTP header > RTP payload > > 4. TURN Allocation over TCP to a peer running STUN/ICE over UDP=20 > TURN TCP framing -- Type=3DData, Length=3D(length of = peer-destined=20 > STUN message) > STUN message > > 5. Control message about TURN Allocation over TCP > TURN TCP framing -- Type=3DSTUN, Length=3D(length of STUN = control message)=20 > STUN message=20 > > 6. TURN Allocation over TCP to a peer running SIP over UDP > TURN TCP framing -- Type=3DData, Length=3D(length of SIP = message) > SIP message > > 7. TURN Allocation over TCP to a peer running syslog over TCP=20 > TURN TCP framing -- Type=3DData, Length=3D(arbitrary length to = the end of > data segment) > some syslog stream data > > 8. TURN Allocation over TCP to a peer running RTP over TCP=20 > TURN TCP framing -- Type=3DData, Length=3D(length of RTP > header+payload + 2) > RTP over TCP framing -- Length=3D(length of RTP header+payload) > RTP header > RTP payload > > A. Even if we decided to copy the same kind of framing used for = RTP > over TCP, we would still need to repeat the RTP over TCP framing = when > delivering to the peer (note the difference between #3 and #8). = In=20 > other words, TURN relays arbitrary end-to-end data; it does not > specially relay RTP from TCP to UDP. > > B. Since we need some framing only for consumption between the = TURN > client and the relay, it is a good idea for us to include the = Type=20 > indicator so we can more easily distinguish between case #4 and = #5. > > thanks, > -rohan > > > > > On 12/12/06, Thomas LEVY < thomas.levy@alcatel-lucent.fr = =20 > > wrote:=20 > > Hi Rohan, > > > > The framing defined in rfc4571 ( i.e: "having a 16-bit = unsigned > integer > > LENGTH field" before the data) doesn't sound specific to me.=20 > > I don't see why it couldn't be applied to STUN or any other=20 > traffic? > > > > Thomas > > > > Rohan Mahy a =E9crit : > > > > > Hi Thomas, > > > > > > The TCP framing is needed to provide the length of non-STUN=20 > data over > > > TCP. > > > The RTP framing over TCP was considered, but TURN needs a = framing=20 > > > mechanism applicable to both RTP and non-RTP traffic. > > >=20 > > > thanks, > > > -rohan > > > > > > On Dec 12, 2006, at 3:18, Thomas LEVY wrote:=20 > > > > > >> Hello all, > > >>=20 > > >> I have a question related to the framing mechanism for > > >> stream-oriented transports defined in = draft-ietf-behave-turn-02.=20 > > >> I fully agree with the need for a framing mechanism when = for=20 > instance > > >> STUN is over TCP. > > >> However, it seems that the defined mechanism provides = framing in=20 > > >> addition with protocol identification (with the use of the=20 > Type field). > > >> An other method for protocol identification ( i.e: to > distinguish STUN > > >> packets from others) is also defined in stun-bis with the = use=20 > of the > > >> magic cookie. > > >> Furthermore, RTP already specified a framing mechanism in=20 > rfc4571 > > >> that could be applicable to STUN.=20 > > >> Thus, i am just wondering if - when defining the framing = for > STUN - > > >> you considered using the framing defined in rfc4571?=20 > > >> If so, what are the reasons for the definition of a new = framing?=20 > > >> > > >> On my opinion, i would be favorable to using the same = framing for > > >> STUN and RTP.=20 > > >> My main argument is the following: If you consider a RTP=20 > client that > > >> wants (or needs) to carry RTP over TCP. If the client sends > its media > > >> directly to a peer, it must use the framing rfc4571 but if=20 > the client > > >> sends its media through a relay (TURN) it must use the = framing > > >> defined in draft-ietf-behave-turn-02. I think it introduces = a > > >> complexity to RTP that shouldn't be aware of it=20 > > >> Furthermore, my "own personal developer experience" makes = me > think > > >> that it would be easier to functionally separate framing = from > > >> protocol identification for the better design of a protocol = > stack. > > >> > > >> Thomas > > > > > > > > > > > > _______________________________________________=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 > > =09 =09 ------_=_NextPart_001_01C723BD.F929335E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Bifurcation of media and signaling, where both = are handled=20 by the same network element causes a doubling (or more) of the number of = ports=20 required to support a particular data flow. This doubles (or more) the = cost of=20 deploying a TURN server into a network.
 
Also, given that TURN is being used to relay = around NATs,=20 and the recent discussions around the benefits of multiplexing RTCP and = RTP over=20 the same connection because of NAT complications, it seems like it would = be=20 tricky to justify why it's 'a good thing' (tm) to multiplex the media = and the=20 media signaling (RTCP+RTP) but not the media/media = signaling and the=20 TURN signaling.
 
Regards,
Brian

From: Mayank Dev Sondhi=20 [mailto:msondhi@gmail.com]
Sent: Tuesday, December 19, 2006 = 12:55=20 AM
To: Thomas LEVY
Cc: Rohan Mahy; = behave@ietf.org;=20 huitema@microsoft.com
Subject: Re: [BEHAVE] Re: STUN/TURN = framing or=20 RTP framing

mmm, no not exactly. I was highlighting a particular = implementation=20 problem that we forced ourselves into where separating out STUN from = normal=20 DATA traffic would be advantageous.
 
Most protocols tend to separate signalling from the actual = transmission=20 of data, and this is a good thing. However in certain = trivial protocols,=20 if implementers can live with extra packet processing, it is good = to also=20 include this bifurcation in a "relaying" protocol like STUN(or = actually=20 TURN). Thus my implementation if it so desires can and should be = easily able=20 to support me able to differentiate between control and data = packets. Of=20 course packets in a TCP sense are somewhat meaningless because of = the=20 streaming nature of the protocol itself.
 
I used the example to bolster the case for not having a "MAGIC = COOKIE"=20 scenario for TCP. I am in agreement with you that the current framing = design=20 for TCP STUN messages is better.
 
Regards
Mayank
 
PS: Bad time to be in Seattle, power outages had me stranded high = and=20 dry..well not so dry!

 
On 12/14/06, Thomas=20 LEVY <thomas.levy@alcatel-lucent.fr > wrote:=20
Hello=20 Mayank

Do you mean you would like to have the STUN traffic = and the=20 data traffic
sperated in order to do separate "socket recv"? =
I=20 believe the only way to do this would be to have 2 sockets (one = for
the=20 traffic and one for the control) but this is not in line with = the
logic=20 of TURN.

Thomas

Mayank Dev Sondhi a =E9crit = :

> Please=20 excuse my discussion of an implementation specific scenario,
> = but I=20 believe it is pertinent.
>
> One of the advantages I can = cite(having developed a particular
> implementation of the = STUN/TURN=20 relay) is that over TCP it is always
> advantageous to = separate out=20 control messages over normal data
> messages. We faced a = problem=20 wherein we had to implement some policing
> of the bandwidth, = and we=20 did this in the simplest and naive way by not
> doing recvs = on our=20 sockets if b/w was exceeded. Unfortunately control
> messages = for=20 cancellation of the operation would also get queued up
> with = the net=20 effect that a user cancel operation would also get stuck
> on = the=20 recv queue of the socket.
>
> If there was a framing = mechanism=20 that allowed us to distinguish this
> we could very easily = separate=20 out signalling from transfer in our
> stack without = sacrificing on=20 performance. I think this design helps us
> in that regard by = including the type in the frame itself.
>
> = Thanks
>=20 Mayank
>
> On 12/13/06, *Rohan Mahy* <=20 rohan.mahy@gmail.com
> <mailto: rohan.mahy@gmail.com>>=20 wrote:
>
>    =20 Hi,
>
>     Perhaps some use cases = would=20 help.  All of these examples assume=20 that
>     the Active Destination is set = to the=20 peer:
>
>     1. RTP over UDP (no=20 TURN)
>     RTP=20 header
>     RTP payload=20
>
>     2. RTP over TCP (no=20 TURN)
>     Length=3D(length of RTP=20 header+payload)
>     RTP=20 header
>     RTP payload=20
>
>     3. TURN Allocation over TCP = to a=20 peer running RTP over UDP
>     TURN TCP = framing=20 -- Type=3DData, Length=3D(length of RTP=20 header+payload)
>     RTP=20 header
>     RTP=20 payload
>
>     4. TURN Allocation = over TCP=20 to a peer running STUN/ICE over UDP
>     = TURN=20 TCP framing -- Type=3DData, Length=3D(length of peer-destined=20
>     STUN=20 message)
>     STUN=20 message
>
>     5. Control message = about=20 TURN Allocation over TCP
>     TURN TCP = framing --=20 Type=3DSTUN, Length=3D(length of STUN control message)=20
>     STUN message=20
>
>     6. TURN Allocation over TCP = to a=20 peer running SIP over UDP
>     TURN TCP = framing=20 -- Type=3DData, Length=3D(length of SIP = message)
>    =20 SIP message
>
>     7. TURN = Allocation over=20 TCP to a peer running syslog over TCP =
>     TURN=20 TCP framing -- Type=3DData, Length=3D(arbitrary length to the end=20 of
>     data=20 segment)
>     some syslog stream=20 data
>
>     8. TURN Allocation over = TCP to=20 a peer running RTP over TCP
>     TURN = TCP=20 framing -- Type=3DData, Length=3D(length of = RTP
>    =20 header+payload + 2)
>     RTP over TCP = framing --=20 Length=3D(length of RTP = header+payload)
>     RTP=20 header
>     RTP=20 payload
>
>     A. Even if we = decided to=20 copy the same kind of framing used for = RTP
>    =20 over TCP, we would still need to repeat the RTP over TCP framing=20 when
>     delivering to the peer (note = the=20 difference between #3 and #8). In
>     = other=20 words, TURN relays arbitrary end-to-end data; it does=20 not
>     specially relay RTP from TCP to=20 UDP.
>
>     B. Since we need some = framing=20 only for consumption between the = TURN
>     client=20 and the relay, it is a good idea for us to include the Type=20
>     indicator so we can more easily = distinguish=20 between case #4 and #5.
>
>    =20 thanks,
>    =20 = -rohan
>
>
>
>
>     = On=20 12/12/06, Thomas LEVY <=20 thomas.levy@alcatel-lucent.fr
>    =20 <mailto:thomas.levy@alcatel-lucent.fr>> wrote:=20
>     > Hi=20 Rohan,
>     = >
>    =20 > The framing defined in rfc4571 ( i.e: "having a 16-bit=20 unsigned
>    =20 integer
>     > LENGTH field" before = the data)=20 doesn't sound specific to me.
>     > = I don't=20 see why it couldn't be applied to STUN or any other=20
>     = traffic?
>    =20 >
>     >=20 Thomas
>     = >
>    =20 > Rohan Mahy a =E9crit :
>    =20 >
>     > > Hi=20 Thomas,
>     >=20 >
>     > > The TCP framing is = needed to=20 provide the length of non-STUN
>     data = over
>     > >=20 TCP.
>     > > The RTP framing over = TCP was=20 considered, but TURN needs a framing =
>     >=20 > mechanism applicable to both RTP and non-RTP=20 traffic.
>     > >=20
>     > >=20 thanks,
>     > >=20 -rohan
>     >=20 >
>     > > On Dec 12, 2006, at = 3:18,=20 Thomas LEVY wrote:
>     >=20 >
>     > >> Hello=20 all,
>     > >>=20
>     > >> I have a question = related to=20 the framing mechanism for
>     > = >>=20 stream-oriented transports defined in draft-ietf-behave-turn-02.=20
>     > >> I fully agree with = the need=20 for a framing mechanism when for
>    =20 instance
>     > >> STUN is over=20 TCP.
>     > >> However, it seems = that=20 the defined mechanism provides framing in =
>    =20 > >> addition with protocol identification (with the use of = the=20
>     Type=20 field).
>     > >> An other = method for=20 protocol identification ( i.e: to
>    =20 distinguish STUN
>     > >> = packets from=20 others) is also defined in stun-bis with the use=20
>    =20 of  the
>     > >> = magic=20 cookie.
>     > >> Furthermore, = RTP=20 already specified a framing mechanism in =
>    =20 rfc4571
>     > >> that could be=20 applicable to STUN.
>     > >> = Thus, i=20 am just wondering if  - when defining the framing=20 for
>     STUN = -
>    =20 > >> you considered using the framing defined in rfc4571?=20
>     > >> If so, what are the = reasons=20 for the definition of a new framing? =
>     >=20 >>
>     > >> On my = opinion, i=20 would be favorable to using the same framing=20 for
>     > >> STUN and RTP.=20
>     > >> My main argument is = the=20 following: If you consider a RTP
>     = client=20 that
>     > >> wants (or needs) = to carry=20 RTP over TCP. If the client sends
>     = its=20 media
>     > >> directly to a = peer, it=20 must use the framing rfc4571 but if
>     = the=20 client
>     > >> sends its media = through=20 a relay (TURN) it must use the = framing
>     >=20 >> defined in draft-ietf-behave-turn-02. I think it introduces = a
>     > >> complexity to RTP = that=20 shouldn't be aware of it
>     > = >>=20 Furthermore, my "own personal developer experience" makes=20 me
>     = think
>    =20 > >> that it would be easier to functionally separate = framing=20 from
>     > >> protocol = identification=20 for the better design of a protocol
>     = stack.
>     >=20 >>
>     > >>=20 Thomas
>     >=20 >
>     >=20 >
>     = >
>    =20 >
>     >=20 _______________________________________________=20
>     > Behave mailing=20 list
>     > Behave@ietf.org=20 <mailto:=20 Behave@ietf.org>
>     > https://www1.ietf.org/mailman/listinfo/behave
>=     =20 >
>
>    =20 = _______________________________________________
>   =  =20 Behave mailing list
>     Behave@ietf.org=20 <mailto:Behave@ietf.org>
>     = https://www1.ietf.org/mailman/listinfo/behave
>=
>


------_=_NextPart_001_01C723BD.F929335E-- --===============0572348417== 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 --===============0572348417==-- From behave-bounces@ietf.org Tue Dec 19 17:46:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwniV-0001AC-I6; Tue, 19 Dec 2006 17:45:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwniU-0001A5-8K for behave@ietf.org; Tue, 19 Dec 2006 17:45:46 -0500 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GwniM-0003uU-Tl for behave@ietf.org; Tue, 19 Dec 2006 17:45:46 -0500 Received: from Quinthar ([67.169.180.240]) by quinthar.com for ; Tue, 19 Dec 2006 14:45:27 -0800 From: "David Barrett" To: "'Brian Stucker'" , "'Mayank Dev Sondhi'" , "'Thomas LEVY'" Subject: RE: [BEHAVE] Re: STUN/TURN framing or RTP framing Date: Tue, 19 Dec 2006 14:45:27 -0800 Message-ID: <01b101c723bf$614b77d0$f917fea9@Quinthar> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AccjOwrVd/8IXah2THq4ddQfVRJ6dwAZtxBgAAdDgcA= In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437111FC6EE4@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 52005c17383d4e3f609075a067e11971 Cc: 'Rohan Mahy' , behave@ietf.org, huitema@microsoft.com 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="===============1850348903==" Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. --===============1850348903== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B2_01C7237C.532837D0" This is a multi-part message in MIME format. ------=_NextPart_000_01B2_01C7237C.532837D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Brian. In my experience, it=92s vastly preferable to = multiplex everything over a single flow because in a NAT-traversing environment, establishing that flow is very expensive and difficult. =20 -david=20 =20 _____ =20 From: Brian Stucker [mailto:bstucker@nortel.com]=20 Sent: Tuesday, December 19, 2006 2:35 PM To: Mayank Dev Sondhi; Thomas LEVY Cc: Rohan Mahy; behave@ietf.org; huitema@microsoft.com Subject: RE: [BEHAVE] Re: STUN/TURN framing or RTP framing =20 Bifurcation of media and signaling, where both are handled by the same network element causes a doubling (or more) of the number of ports = required to support a particular data flow. This doubles (or more) the cost of deploying a TURN server into a network. =20 Also, given that TURN is being used to relay around NATs, and the recent discussions around the benefits of multiplexing RTCP and RTP over the = same connection because of NAT complications, it seems like it would be = tricky to justify why it's 'a good thing' (tm) to multiplex the media and the = media signaling (RTCP+RTP) but not the media/media signaling and the TURN signaling. =20 Regards, Brian =20 _____ =20 From: Mayank Dev Sondhi [mailto:msondhi@gmail.com]=20 Sent: Tuesday, December 19, 2006 12:55 AM To: Thomas LEVY Cc: Rohan Mahy; behave@ietf.org; huitema@microsoft.com Subject: Re: [BEHAVE] Re: STUN/TURN framing or RTP framing mmm, no not exactly. I was highlighting a particular implementation = problem that we forced ourselves into where separating out STUN from normal DATA traffic would be advantageous. =20 Most protocols tend to separate signalling from the actual transmission = of data, and this is a good thing. However in certain trivial protocols, if implementers can live with extra packet processing, it is good to also include this bifurcation in a "relaying" protocol like STUN(or actually TURN). Thus my implementation if it so desires can and should be easily = able to support me able to differentiate between control and data packets. Of course packets in a TCP sense are somewhat meaningless because of the streaming nature of the protocol itself.=20 =20 I used the example to bolster the case for not having a "MAGIC COOKIE" scenario for TCP. I am in agreement with you that the current framing = design for TCP STUN messages is better. =20 Regards Mayank =20 PS: Bad time to be in Seattle, power outages had me stranded high and dry..well not so dry! =20 On 12/14/06, Thomas LEVY > wrote:=20 Hello Mayank Do you mean you would like to have the STUN traffic and the data traffic sperated in order to do separate "socket recv"?=20 I believe the only way to do this would be to have 2 sockets (one for the traffic and one for the control) but this is not in line with the logic of TURN. Thomas Mayank Dev Sondhi a =E9crit : > Please excuse my discussion of an implementation specific scenario, > but I believe it is pertinent. > > One of the advantages I can cite(having developed a particular > implementation of the STUN/TURN relay) is that over TCP it is always=20 > advantageous to separate out control messages over normal data > messages. We faced a problem wherein we had to implement some policing > of the bandwidth, and we did this in the simplest and naive way by not = > doing recvs on our sockets if b/w was exceeded. Unfortunately control > messages for cancellation of the operation would also get queued up > with the net effect that a user cancel operation would also get stuck=20 > on the recv queue of the socket. > > If there was a framing mechanism that allowed us to distinguish this > we could very easily separate out signalling from transfer in our > stack without sacrificing on performance. I think this design helps us = > in that regard by including the type in the frame itself. > > Thanks > Mayank > > On 12/13/06, *Rohan Mahy* < rohan.mahy@gmail.com =20 > > wrote: > > Hi, > > Perhaps some use cases would help. All of these examples assume = that > the Active Destination is set to the peer:=20 > > 1. RTP over UDP (no TURN) > RTP header > RTP payload=20 > > 2. RTP over TCP (no TURN) > Length=3D(length of RTP header+payload) > RTP header > RTP payload=20 > > 3. TURN Allocation over TCP to a peer running RTP over UDP=20 > TURN TCP framing -- Type=3DData, Length=3D(length of RTP = header+payload) > RTP header > RTP payload > > 4. TURN Allocation over TCP to a peer running STUN/ICE over UDP=20 > TURN TCP framing -- Type=3DData, Length=3D(length of peer-destined = > STUN message) > STUN message > > 5. Control message about TURN Allocation over TCP > TURN TCP framing -- Type=3DSTUN, Length=3D(length of STUN control = message) > STUN message=20 > > 6. TURN Allocation over TCP to a peer running SIP over UDP > TURN TCP framing -- Type=3DData, Length=3D(length of SIP message) > SIP message > > 7. TURN Allocation over TCP to a peer running syslog over TCP=20 > TURN TCP framing -- Type=3DData, Length=3D(arbitrary length to the = end of > data segment) > some syslog stream data > > 8. TURN Allocation over TCP to a peer running RTP over TCP=20 > TURN TCP framing -- Type=3DData, Length=3D(length of RTP > header+payload + 2) > RTP over TCP framing -- Length=3D(length of RTP header+payload) > RTP header > RTP payload > > A. Even if we decided to copy the same kind of framing used for = RTP > over TCP, we would still need to repeat the RTP over TCP framing = when > delivering to the peer (note the difference between #3 and #8). In = > other words, TURN relays arbitrary end-to-end data; it does not > specially relay RTP from TCP to UDP. > > B. Since we need some framing only for consumption between the = TURN > client and the relay, it is a good idea for us to include the Type = > indicator so we can more easily distinguish between case #4 and = #5. > > thanks, > -rohan > > > > > On 12/12/06, Thomas LEVY < thomas.levy@alcatel-lucent.fr > > wrote:=20 > > Hi Rohan, > > > > The framing defined in rfc4571 ( i.e: "having a 16-bit unsigned > integer > > LENGTH field" before the data) doesn't sound specific to me.=20 > > I don't see why it couldn't be applied to STUN or any other=20 > traffic? > > > > Thomas > > > > Rohan Mahy a =E9crit : > > > > > Hi Thomas, > > > > > > The TCP framing is needed to provide the length of non-STUN=20 > data over > > > TCP. > > > The RTP framing over TCP was considered, but TURN needs a = framing=20 > > > mechanism applicable to both RTP and non-RTP traffic. > > >=20 > > > thanks, > > > -rohan > > > > > > On Dec 12, 2006, at 3:18, Thomas LEVY wrote:=20 > > > > > >> Hello all, > > >>=20 > > >> I have a question related to the framing mechanism for > > >> stream-oriented transports defined in = draft-ietf-behave-turn-02.=20 > > >> I fully agree with the need for a framing mechanism when for=20 > instance > > >> STUN is over TCP. > > >> However, it seems that the defined mechanism provides framing = in=20 > > >> addition with protocol identification (with the use of the=20 > Type field). > > >> An other method for protocol identification ( i.e: to > distinguish STUN > > >> packets from others) is also defined in stun-bis with the use = > of the > > >> magic cookie. > > >> Furthermore, RTP already specified a framing mechanism in=20 > rfc4571 > > >> that could be applicable to STUN.=20 > > >> Thus, i am just wondering if - when defining the framing for > STUN - > > >> you considered using the framing defined in rfc4571?=20 > > >> If so, what are the reasons for the definition of a new = framing?=20 > > >> > > >> On my opinion, i would be favorable to using the same framing = for > > >> STUN and RTP.=20 > > >> My main argument is the following: If you consider a RTP=20 > client that > > >> wants (or needs) to carry RTP over TCP. If the client sends > its media > > >> directly to a peer, it must use the framing rfc4571 but if=20 > the client > > >> sends its media through a relay (TURN) it must use the = framing > > >> defined in draft-ietf-behave-turn-02. I think it introduces a > > >> complexity to RTP that shouldn't be aware of it=20 > > >> Furthermore, my "own personal developer experience" makes me > think > > >> that it would be easier to functionally separate framing from > > >> protocol identification for the better design of a protocol=20 > stack. > > >> > > >> Thomas > > > > > > > > > > > > _______________________________________________=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 > > =20 ------=_NextPart_000_01B2_01C7237C.532837D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I agree with Brian.=A0 In my = experience, it’s vastly preferable to multiplex everything over a single flow because in = a NAT-traversing environment, establishing that flow is very expensive and = difficult.

 

-david =

 

From: Brian = Stucker [mailto:bstucker@nortel.com]
Sent: Tuesday, December = 19, 2006 2:35 PM
To: Mayank Dev Sondhi; = Thomas LEVY
Cc: Rohan Mahy; = behave@ietf.org; huitema@microsoft.com
Subject: RE: [BEHAVE] Re: STUN/TURN framing or RTP framing

 

Bifurcation of media and signaling, = where both are handled by the same network element causes a doubling (or more) = of the number of ports required to support a particular data flow. This doubles = (or more) the cost of deploying a TURN server into a = network.

 

Also, given that TURN is being used = to relay around NATs, and the recent discussions around the benefits of multiplexing RTCP and RTP over the same connection because of NAT complications, it seems like it would be tricky to justify why it's 'a = good thing' (tm) to multiplex the media and the media signaling = (RTCP+RTP) but not the media/media signaling and the TURN = signaling.

 

Regards,

Brian

 

From: Mayank Dev Sondhi [mailto:msondhi@gmail.com]
Sent: Tuesday, December = 19, 2006 12:55 AM
To: Thomas LEVY
Cc: Rohan Mahy; = behave@ietf.org; huitema@microsoft.com
Subject: Re: [BEHAVE] Re: STUN/TURN framing or RTP framing

mmm, no not exactly. I was highlighting a particular = implementation problem that we forced ourselves into where separating out STUN from = normal DATA traffic would be advantageous.

 

Most protocols tend to separate signalling from the actual = transmission of data, and this is a good thing. However in certain = trivial protocols, if implementers can live with extra packet processing, it is good = to also include this bifurcation in a "relaying" protocol = like STUN(or actually TURN). Thus my implementation if it so desires can and should = be easily able to support me able to differentiate between control and = data packets. Of course packets in a TCP sense are somewhat = meaningless because of the streaming nature of the protocol itself. =

 

I used the example to bolster the case for not having a = "MAGIC COOKIE" scenario for TCP. I am in agreement with you that the = current framing design for TCP STUN messages is better.

 

Regards

Mayank

 

PS: Bad time to be in Seattle, power outages had me stranded high and dry..well not so dry!

 

On 12/14/06, Thomas LEVY <thomas.levy@alcatel-lucent.fr > = wrote:

Hello = Mayank

Do you mean you would like to have the STUN traffic and the data = traffic
sperated in order to do separate "socket recv"?
I believe the only way to do this would be to have 2 sockets (one = for
the traffic and one for the control) but this is not in line with = the
logic of TURN.

Thomas

Mayank Dev Sondhi a =E9crit :

> Please excuse my discussion of an implementation specific = scenario,
> but I believe it is pertinent.
>
> One of the advantages I can cite(having developed a particular
> implementation of the STUN/TURN relay) is that over TCP it is = always
> advantageous to separate out control messages over normal data
> messages. We faced a problem wherein we had to implement some = policing
> of the bandwidth, and we did this in the simplest and naive way by = not
> doing recvs on our sockets if b/w was exceeded. Unfortunately = control
> messages for cancellation of the operation would also get queued = up
> with the net effect that a user cancel operation would also get = stuck
> on the recv queue of the socket.
>
> If there was a framing mechanism that allowed us to distinguish = this
> we could very easily separate out signalling from transfer in = our
> stack without sacrificing on performance. I think this design helps = us
> in that regard by including the type in the frame itself.
>
> Thanks
> Mayank
>
> On 12/13/06, *Rohan Mahy* < rohan.mahy@gmail.com
> <mailto: rohan.mahy@gmail.com>> wrote:
>
>     Hi,
>
>     Perhaps some use cases would = help.  All of these examples assume that
>     the Active Destination is set to the peer: =
>
>     1. RTP over UDP (no TURN)
>     RTP header
>     RTP payload
>
>     2. RTP over TCP (no TURN)
>     Length=3D(length of RTP header+payload)
>     RTP header
>     RTP payload
>
>     3. TURN Allocation over TCP to a peer = running RTP over UDP
>     TURN TCP framing -- Type=3DData, = Length=3D(length of RTP header+payload)
>     RTP header
>     RTP payload
>
>     4. TURN Allocation over TCP to a peer = running STUN/ICE over UDP
>     TURN TCP framing -- Type=3DData, = Length=3D(length of peer-destined
>     STUN message)
>     STUN message
>
>     5. Control message about TURN Allocation = over TCP
>     TURN TCP framing -- Type=3DSTUN, = Length=3D(length of STUN control message)
>     STUN message
>
>     6. TURN Allocation over TCP to a peer = running SIP over UDP
>     TURN TCP framing -- Type=3DData, = Length=3D(length of SIP message)
>     SIP message
>
>     7. TURN Allocation over TCP to a peer = running syslog over TCP
>     TURN TCP framing -- Type=3DData, = Length=3D(arbitrary length to the end of
>     data segment)
>     some syslog stream data
>
>     8. TURN Allocation over TCP to a peer = running RTP over TCP
>     TURN TCP framing -- Type=3DData, = Length=3D(length of RTP
>     header+payload + 2)
>     RTP over TCP framing -- Length=3D(length of = RTP header+payload)
>     RTP header
>     RTP payload
>
>     A. Even if we decided to copy the same kind = of framing used for RTP
>     over TCP, we would still need to repeat the = RTP over TCP framing when
>     delivering to the peer (note the difference between #3 and #8). In
>     other words, TURN relays arbitrary = end-to-end data; it does not
>     specially relay RTP from TCP to UDP.
>
>     B. Since we need some framing only for = consumption between the TURN
>     client and the relay, it is a good idea for = us to include the Type
>     indicator so we can more easily distinguish between case #4 and #5.
>
>     thanks,
>     -rohan
>
>
>
>
>     On 12/12/06, Thomas LEVY < thomas.levy@alcatel-lucent.fr
>     <mailto:thomas.levy@alcatel-lucent.fr>> wrote:
>     > Hi Rohan,
>     >
>     > The framing defined in rfc4571 ( i.e: "having a 16-bit unsigned
>     integer
>     > LENGTH field" before the data) = doesn't sound specific to me.
>     > I don't see why it couldn't be applied = to STUN or any other
>     traffic?
>     >
>     > Thomas
>     >
>     > Rohan Mahy a =E9crit :
>     >
>     > > Hi Thomas,
>     > >
>     > > The TCP framing is needed to = provide the length of non-STUN
>     data over
>     > > TCP.
>     > > The RTP framing over TCP was = considered, but TURN needs a framing
>     > > mechanism applicable to both RTP = and non-RTP traffic.
>     > >
>     > > thanks,
>     > > -rohan
>     > >
>     > > On Dec 12, 2006, at 3:18, Thomas = LEVY wrote:
>     > >
>     > >> Hello all,
>     > >>
>     > >> I have a question related to = the framing mechanism for
>     > >> stream-oriented transports = defined in draft-ietf-behave-turn-02.
>     > >> I fully agree with the need = for a framing mechanism when for
>     instance
>     > >> STUN is over TCP.
>     > >> However, it seems that the = defined mechanism provides framing in
>     > >> addition with protocol identification (with the use of the
>     Type field).
>     > >> An other method for protocol identification ( i.e: to
>     distinguish STUN
>     > >> packets from others) is also = defined in stun-bis with the use
>     of  the
>     > >> magic cookie.
>     > >> Furthermore, RTP already = specified a framing mechanism in
>     rfc4571
>     > >> that could be applicable to = STUN.
>     > >> Thus, i am just wondering if  - when defining the framing for
>     STUN -
>     > >> you considered using the = framing defined in rfc4571?
>     > >> If so, what are the reasons = for the definition of a new framing?
>     > >>
>     > >> On my opinion, i would be = favorable to using the same framing for
>     > >> STUN and RTP.
>     > >> My main argument is the = following: If you consider a RTP
>     client that
>     > >> wants (or needs) to carry RTP = over TCP. If the client sends
>     its media
>     > >> directly to a peer, it must = use the framing rfc4571 but if
>     the client
>     > >> sends its media through a = relay (TURN) it must use the framing
>     > >> defined in draft-ietf-behave-turn-02. I think it introduces a
>     > >> complexity to RTP that = shouldn't be aware of it
>     > >> Furthermore, my "own = personal developer experience" makes me
>     think
>     > >> that it would be easier to functionally separate framing from
>     > >> protocol identification for = the better design of a protocol
>     stack.
>     > >>
>     > >> Thomas
>     > >
>     > >
>     >
>     >
>     > _______________________________________________
>     > Behave mailing list
>     > Behave@ietf.org <mailto: Behave@ietf.org>
>     > https://www1.ietf.org/mailman/listinfo/behave
>     >
>
>     = _______________________________________________
>     Behave mailing list
>     Behave@ietf.org <mailto:Behave@ietf.org>
>     https://www1.ietf.org/mailman/listinfo/behave
>
>

 

------=_NextPart_000_01B2_01C7237C.532837D0-- --===============1850348903== 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 --===============1850348903==-- From behave-bounces@ietf.org Wed Dec 27 04:40:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzVFr-0002jN-OR; Wed, 27 Dec 2006 04:39:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzVFq-0002it-L9 for behave@ietf.org; Wed, 27 Dec 2006 04:39:22 -0500 Received: from rs384.securehostserver.com ([72.22.69.69]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GzVFc-0007ca-68 for behave@ietf.org; Wed, 27 Dec 2006 04:39:22 -0500 Received: (qmail 90667 invoked by uid 3521); 27 Dec 2006 09:34:35 -0000 Received: from 220.225.33.101 by rs384.securehostserver.com (envelope-from , uid 1002) with qmail-scanner-1.25st (clamdscan: 0.88/1245. spamassassin: 3.1.0. perlscan: 1.25st. Clear:RC:1(220.225.33.101):. Processed in 0.761751 secs); 27 Dec 2006 09:34:35 -0000 Received: from unknown (HELO vikram.codito.co.in) (220.225.33.101) by rs384.securehostserver.com with SMTP; 27 Dec 2006 09:34:34 -0000 From: Vikram Bhuskute To: behave@ietf.org In-Reply-To: <456BB0EA.7090300@acm.org> References: <456BB0EA.7090300@acm.org> Content-Type: text/plain Date: Wed, 27 Dec 2006 15:09:00 +0530 Message-Id: <1167212341.5238.6.camel@vikram> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [BEHAVE] RTCP with 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 Hi All, As RTP streaming is required at run time "Set Active destination" will be set for RTP IP/PORT. Then is it assumed that all the RTCP traffic will be inside "Send Indication" Only ? It it correct ? Another question how many allocation a client can ask for (I guess at least 2 is needed for RTP+RTCP) regards Vikram _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Dec 27 11:27:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzbcJ-0002JO-Ru; Wed, 27 Dec 2006 11:26:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzbcI-0002JD-T2 for behave@ietf.org; Wed, 27 Dec 2006 11:26:58 -0500 Received: from wx-out-0506.google.com ([66.249.82.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzbcH-0001en-Im for behave@ietf.org; Wed, 27 Dec 2006 11:26:58 -0500 Received: by wx-out-0506.google.com with SMTP id h27so4262938wxd for ; Wed, 27 Dec 2006 08:26:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=FJeF5CjHJHNJFAUnEVdtcbDuLSXxNiyCFRPbKQkxKsl12nyd1+PiPV5ABjhfsd4jEhDMWXiNJe66kKDBZIktuNhYlcj21DRXfDnAP8vJgaO2dZQvxa9F0okeukx1zie2ljXrSiFffN06FQbx8OvLZDBp0sAjyDhkQR9YHSCxai0= Received: by 10.90.55.19 with SMTP id d19mr9012202aga.1167236817337; Wed, 27 Dec 2006 08:26:57 -0800 (PST) Received: by 10.90.90.18 with HTTP; Wed, 27 Dec 2006 08:26:57 -0800 (PST) Message-ID: Date: Wed, 27 Dec 2006 21:56:57 +0530 From: "Mayank Dev Sondhi" To: "Vikram Bhuskute" Subject: Re: [BEHAVE] RTCP with TURN In-Reply-To: <1167212341.5238.6.camel@vikram> MIME-Version: 1.0 References: <456BB0EA.7090300@acm.org> <1167212341.5238.6.camel@vikram> X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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: , Content-Type: multipart/mixed; boundary="===============1787379706==" Errors-To: behave-bounces@ietf.org --===============1787379706== Content-Type: multipart/alternative; boundary="----=_Part_73706_29302214.1167236817247" ------=_Part_73706_29302214.1167236817247 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Since RTP and RTCP would be using 2 separate ports, I would hazard that Allocations would be separate. Since bindings are decided by the combination source IP address port and destination IP address and port(this would be different for RTP and RTCP) Set Active Destination can be applied for both the routes/channels. RTP->IP address X Port Y ->Allocation on STUN relay server->Destination IP :port->RTP RTCP->IP address X Port Y1 ->Allocation on STUN relay server->Destination IP :port->RTCP RTP->IP address X Port Y ->SAD on STUN server->Destination IP :port M->RTP RTCP->IP address X Port Y1 ->SAD on STUN server->Destination IP :port M1->RTCP Since Y and Y1 and presumably M and M1 are different(assuming no multiplexing of RTP and RTCP), the SADs would be on 2 separate channels in the STUN server. I hope this was clear, I omitted some details for brevity and would ask you to refer to the document for further clarification. Mayank On 12/27/06, Vikram Bhuskute wrote: > > > Hi All, > As RTP streaming is required at run time "Set Active destination" > will be set for RTP IP/PORT. Then is it assumed that all the RTCP > traffic will be inside "Send Indication" Only ? It it correct ? > > > Another question how many allocation a client can ask for > (I guess at least 2 is needed for RTP+RTCP) > > > regards > > Vikram > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > ------=_Part_73706_29302214.1167236817247 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Since RTP and RTCP would be using 2 separate ports, I would hazard that Allocations would be separate. Since bindings are decided by the combination source IP address port and destination IP address and port(this would be different for RTP and RTCP) Set Active Destination can be applied for both the routes/channels.
 
RTP->IP address X Port Y ->Allocation on STUN relay server->Destination IP :port->RTP
RTCP->IP address X Port Y1 ->Allocation on STUN relay server->Destination IP :port->RTCP
 
RTP->IP address X Port Y ->SAD on STUN server->Destination IP :port M->RTP
RTCP->IP address X Port Y1 ->SAD on STUN server->Destination IP :port M1->RTCP

Since Y and Y1 and presumably M and M1 are different(assuming no multiplexing of RTP and RTCP), the SADs would be on 2 separate channels in the STUN server.
 
I hope this was clear, I omitted some details for brevity and would ask you to refer to the document for further clarification.
 
Mayank
 
On 12/27/06, Vikram Bhuskute <vikram.bhuskute@celunite.com> wrote:

Hi All,
      As RTP streaming is required at run time "Set Active destination"
will be set for RTP IP/PORT. Then is it assumed that all the RTCP
traffic will be inside "Send Indication" Only ? It it correct ?


Another question how many allocation a client can ask for
(I guess at least 2 is needed for RTP+RTCP)


regards

Vikram


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

------=_Part_73706_29302214.1167236817247-- --===============1787379706== 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 --===============1787379706==--