From behave-bounces@ietf.org Thu Nov 09 02:17:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi4A2-0005fT-2z; Thu, 09 Nov 2006 02:17:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi4A0-0005eO-Ah for behave@ietf.org; Thu, 09 Nov 2006 02:17:16 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi49y-0003C8-Ow for behave@ietf.org; Thu, 09 Nov 2006 02:17:16 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 08 Nov 2006 23:17:14 -0800 X-IronPort-AV: i="4.09,402,1157353200"; d="scan'208"; a="1863030061:sNHT45497298" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA97HE6b021843 for ; Wed, 8 Nov 2006 23:17:14 -0800 Received: from dwingwxp (sjc-vpn-hwcore-962.cisco.com [10.21.155.194]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kA97GROV024583 for ; Wed, 8 Nov 2006 23:17:03 -0800 (PST) From: "Dan Wing" To: "BEHAVE" Date: Wed, 8 Nov 2006 23:16:15 -0800 Message-ID: <0eaf01c703cf$1244a270$f891150a@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: AccDzvHTPLeCUrvMQryZjvbUGw8SCA== DKIM-Signature: a=rsa-sha1; q=dns; l=1032; t=1163056634; x=1163920634; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:behave=20list=20moved; X=v=3Dcisco.com=3B=20h=3DNKgYLqpXBHxIt6GDErgnwhF0cIU=3D; b=xSxMbsjvyPCeJRQ4dze4gtRdY+Tn8tpuGWPSCKuIt9lpYUM7yTsBLeIvVjUqaYy9t9tGzwwI mW1nBaoDNBbzvNyP0VQK3ojqFnTQjyboJE/9DKFP2bqJmLIN1RRGSIrr; Authentication-Results: sj-dkim-8.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [BEHAVE] behave list moved X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org (This message was sent to the new BEHAVE list, behave@ietf.org) We have moved the BEHAVE mailing list from sipfoundry.org to ietf.org. All old subscribers have been automatically subscribed to the new list. You should receive two copies of this message -- one from the old list and one from the new list. Posts to the old list on sipfoundry.org will be rejected with a message pointing to the new list on ietf.org. BEHAVE's archives will be moved to IETF's servers in the next few weeks. Please send email to dwing@cisco.com if you have any questions or difficulties related to this move. Digest subscribers: During the move I was unable to retain your digest settings. This affects about 10% of the mailing list subscribers. If you wish to restore digest settings, you can send mail or use the web interface to restore your digest setting. Send mail to behave-request@ietf.org with "set digest mime" in the message body (without quotes, of course). -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Nov 09 10:24:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiBkw-0006gz-AD; Thu, 09 Nov 2006 10:23:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiBku-0006gr-Cy for behave@ietf.org; Thu, 09 Nov 2006 10:23:52 -0500 Received: from web33303.mail.mud.yahoo.com ([68.142.206.118]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GiBko-0005xD-Dx for behave@ietf.org; Thu, 09 Nov 2006 10:23:52 -0500 Received: (qmail 28382 invoked by uid 60001); 9 Nov 2006 15:23:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=eedgiGt8T2n+YlgDZzUQr0rNnAuALugiGNq1vUI2ofVjcf3NYtN/j1mnlImGlv/mUVuMnpcJiCO06CnYeJJi18Qh+FF9HXgDLMTSSUVxPcfLrSfy8Me63cvamZ3Yolb+dQ7GNCshOO1gWdrZXPHubWeVFU2sOKjV4tv3Hik6giQ= ; Message-ID: <20061109152345.28380.qmail@web33303.mail.mud.yahoo.com> Received: from [69.236.72.190] by web33303.mail.mud.yahoo.com via HTTP; Thu, 09 Nov 2006 07:23:45 PST Date: Thu, 9 Nov 2006 07:23:45 -0800 (PST) From: Pyda Srisuresh To: philip_matthews@magma.ca In-Reply-To: <7.0.1.0.0.20061108124343.07dcbb48@gont.com.ar> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e Cc: behave@ietf.org Subject: [BEHAVE] Re: [Ietf-behave] Comments on draft-ietf-behave-nat-icmp-01 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Philip, Sorry, I missed your e-mail when it was posted. For some reason, I did not see this in my inbox until a kind soul refered me to it. Anyways, sorry for the delay. Please see my responses below inline. regards, suresh > >X-ClientAddr: 72.232.205.74 > >From: Philip Matthews > >Date: Tue, 31 Oct 2006 16:25:03 -0500 > >To: Bryan Ford , Senthil Sivakumar , > > Saikat Guha , > > Pyda Srisuresh > >X-Mailer: Apple Mail (2.752.2) > >X-magma-MailScanner-Information: Magma Mailscanner Service > >X-magma-MailScanner: Clean > >X-Spam-Status: > >Cc: Dan Wing , Behave WG > >Subject: [Ietf-behave] Comments on draft-ietf-behave-nat-icmp-01 > >X-BeenThere: ietf-behave@list.sipfoundry.org > >X-Mailman-Version: 2.1.9 > >List-Id: IETF Behave WG > >List-Unsubscribe: > , > > > > >List-Archive: > >List-Post: > >List-Help: > >List-Subscribe: , > > > >Sender: ietf-behave-bounces@list.sipfoundry.org > >X-Greylist: IP, sender and recipient auto-whitelisted, not delayed > >by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Tue, > >31 Oct 2006 18:28:48 -0300 (ART) > > > >Dan Wing asked me to review draft-ietf-behave-nat-icmp-01. > >Below are my comments. > > > >- Philip > > [suresh] Thank you for reviewing. > >Major comments > >============== > > > >* (Section 3.2) > > Is the query session freed up when the query response is received > >by the NAT, > > or does it stay active for the duration of the timer? If the former, > > then the case for having having the mapping of the query identifier > > be endpoint-independent seems weakened. > > [suresh] ICMP query request/response sequence is similar to the UDP datagram request/response sequence. As such, the ICMP query session idle timeout is similar to the UDP session idle timeout. > >* In section 4.2.2, the document contains the following paragraph > > "In the outer header, the destination IP address will remain > > unchanged, as the IP addresses for Host-x is already in > > the external > > domain. If the ICMP error message is generated by Host-y, the > NAT > > a NAPT device must simply use the NAT Session to translate the > > source IP address Host-y to Host-y'. However, if the ICMP error > > message is originated by the intermediate node Router-y, and the > > NAT device is a Basic NAT ([NAT-TRAD]), and it has active > mapping > > for the IP address that sent the ICMP error, the NAT device MUST > > translate the source IP address of the ICMP error packet with > the > > public IP address in the mapping. Otherwise, the NAT device MUST > > simply use its own IP address in the external domain to > translate > > the source IP address." > > It took me a few re-reads to understand what this paragraph was > >getting at. > > If I understand correctly, it is talking about the address that > >should be > > used as the public IP address in the ICMP Error packet in the case > >where the > > NAT has more than one public address. > > If the ICMP packet comes from the host, then the paragraph says that > > the choice is easy: use the public IP address in the mapping for the > > TCP or UDP session that caused the error. > > The problem is when the ICMP error packet comes from an intermediate > > router behind the NAT. In this case, the above paragraph talks > > about an "active mapping for the IP address that sent the ICMP > >error". > > The question is: What sort of mapping? [suresh] Unlike NAPT, a Basic NAT has a pool of public IP addresses and maps a public IP address from the pool when a private host initiates a new session via the NAT. Unlike NAPT, which perfroms endpoint mapping, a Basic NAT performs address mapping. Subsequent to an address mapping, while the mapping is active on the Basic NAT, the NAT reuses the mapping for all new sessions from the private host. I will reword the text to make this clearer. Thanks. > > Does a mapping for a UDP > > or TCP session count? And what if the NAT does not support the > > Address Pooling behavior of Paired (which is just a SHOULD in the > > BEHAVE-UDP document) -- in this case, which address is used? [suresh] Please see my comment above. With a Basic NAT, both TCP and UDP sessions use the same address mapping. Ports are unchanged from private endpoint to public endpoint. > > > >* Section 6 talks about outbound flows that are rejected by the NAT > > and says that the NAT SHOULD send an ICMP message back to the > >internal > > host when this happens. > > However, some NAT designers may say "We never reject an outbound > >flow; > > if we get close, we just steal the entry from an existing flow". > > By doing this, they may claim to conform to REQ-8, while violating > > the spirit of the requirement. > > I would like to see the document discuss this issue, and perhaps make > > a recommendation discouraging this potential practice. [suresh] OK. > > > >* Should this document mandate support for draft-bonica-internet-icmp? > > Note that an early version of this work has been widely > >implemented in routers > > (since about 2000). > > [suresh] I havent read the draft. DO any of the existing requirements change by mandating the support for this? Are there new fields that a NAT has to modify? Or, are the extensions completely transparent to a NAT device? > > > > > >Minor and editorial comments > >============================ > >* Section 1 states: > > "Even though ICMP is a transport protocol on top of IP, ICMP > message > > processing is often considered an integral of IP and is independent > > of other transport protocols. As such, many of the ICMP behavioral > > requirements discussed in this document apply to all IP protocols." > > Three comments on this: > > a) ICMP is not a transport protocol, but a network control protocol. > > b) "an integral of IP" --> "an integral part of IP" > > c) I don't understand what you are trying to say with this paragraph. > > When I review the requirements for ICMP, they seem pretty ICMP- > >specific, > > and not applicable to UDP or TCP or some other protocol running > >on top > > of IP. > > [suresh] Fernando made a similar comment on this text. Would the followrded text work for you? Thanks. ICMP is a signaling protocol for IP. ICMP message processing is often considered an integral of IP and is independent of other IP protocols. As such, many of the ICMP behavioral requirements discussed in this document apply to all IP protocols. > > > >* In section 3.2 > > "an ICMP query transiting a NAT device" > > Not sure about "transiting". Suggest replacing with > > "an ICMP query that transits a NAT device" > > [suresh] OK. > > > >* In section 4.2 > > "Section 4.3 of the RFC 3022 describes the various fields within > > an ICMP error message a NAT device translates." > > Two comments: > > a) Missing a "that" after message. > > b) Everywhere else, the document say just "RFC XXXX", not "the RTC > >XXXX". > > [suresh] OK. s/message a NAT/message that a NAT/ s/the RFC 3022/RFC 3022/ > > > >* Also in section 4.2: > > "domains. Whereas, the subnets in the private network ..." > > Suggest either changing the "." to a ",", or changing "Whereas" to > >"By contrast". > > [suresh] OK. s/Whereas/By contrast/ > >* And more in section 4.2: > > "... to Host-x, let us say that the NAT device assigned a mapping > of > > Host-y' to associate with Host-y in the external network." > > This implies that the mapping is just an IP address to IP address > >mapping, > > but in some cases it also involved the Information field. > > [suresh] Would the following rewording work for you? "... to Host-x, let us say that the NAT device mapped the endpoint on Host-y to an endpoint on Host-y'. " > >* In section 4.2.2: > > "If the ICMP error message is generated by Host-y, the NAT > > a NAPT device must simply use the NAT Session to translate the ..." > > Delete "a NAPT". > > [suresh] Yup. Thanks. > >* In section 4.3 > > "By not effecting the NAT Sessions, the NAT > > device is able to retain them, even as someone spoofs ICMP error > > messages pertaining to the NAT Sessions." > > Here "effecting" should be "affecting", but I really suggest > > rewording this entire sentence to: > > "This ensures that the NAT Session will not be modified > > if someone is able to spoof ICMP error messages > > for the session." > > [suresh] OK. > >* In section 5 > > "REQ-7: NAT devices enforcing Basic NAT ([NAT-TRAD]) MUST support > the > > traversal of hairpinned ICMP query sessions. All NAT devices (i.e, > > Basic NAT as well as NAPT devices) MUST support the traversal of > > hairpinned ICMP error messages." > > I suggest replacing this with just > > "REQ-7: NAT devices MUST support the hairpin traversal of ICMP > >messages." > > The proceeding discussion mentions why this is a bit more difficult > > for Basic NAT devices, but I suggest that the requirement itself > >be stated > > as cleanly and simply as possible. [suresh] The requirement as stated refers to supporting hairpinning for both ICMP queries and ICMP messages explicitly. The requirement is also explicit that hairpinnig support for ICMP queries is is required only for Basic NAT. Your revised text is not explicit on either of these. > > > >"If the DF bit is not set and the MTU on the forwarding interface > > of the NAT device mandates fragmentation, the NAT device must > > simply send this fragmented, just as any router does [RFC1812]." > > Suggest rewording this as > > "If the DF bit is not set and the MTU on the forwarding interface > > of the NAT device mandates fragmentation, the NAT device MUST > > fragment the packet and forward the fragments [RFC1812]." > > [suresh] OK. Thanks. regards, suresh > >* In section 7.1.1: > > "If the DF bit is not set and the MTU on the forwarding interface > > of the NAT device mandates fragmentation, the NAT device must > > simply send this fragmented, just as any router does [RFC1812]." > > Suggest rewording this as > > "If the DF bit is not set and the MTU on the forwarding interface > > of the NAT device mandates fragmentation, the NAT device MUST > > fragment the packet and forward the fragments [RFC1812]." > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Nov 09 13:04:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiEGH-00083B-HV; Thu, 09 Nov 2006 13:04:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiEGG-00081e-Qm for behave@ietf.org; Thu, 09 Nov 2006 13:04:24 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiEGE-0007SS-V0 for behave@ietf.org; Thu, 09 Nov 2006 13:04:24 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 09 Nov 2006 10:04:22 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kA9I4MDk021209 for ; Thu, 9 Nov 2006 10:04:22 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA9I4Hit003234 for ; Thu, 9 Nov 2006 10:04:22 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 10:04:18 -0800 Received: from [130.129.71.4] ([10.21.81.158]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 10:04:18 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <45AD9D70-019D-4870-9F45-19E37F12D260@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: behave@ietf.org From: Cullen Jennings Date: Thu, 9 Nov 2006 09:15:06 -0800 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 09 Nov 2006 18:04:18.0308 (UTC) FILETIME=[79913C40:01C70429] DKIM-Signature: a=rsa-sha1; q=dns; l=23; t=1163095462; x=1163959462; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:test=20new |Sender:; X=v=3Dcisco.com=3B=20h=3DWft1QavZhu5jrGQgXTVQDY+9RaU=3D; b=aKd6NdMvENqesiP+QomNVx0516aHD+4N6we9jYiiewelahV+qJSyTXLryKRMwR098HmPFrSB KT9aT1qh9xody+n5oDtO1DDDNAq/6O1SwNFDOO3kQJCLiGr7Kgyfjypb; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Subject: [BEHAVE] test new 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 new 1 - please ignore _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Nov 09 13:04:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiEGX-0008Bm-UQ; Thu, 09 Nov 2006 13:04:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiEGX-0008Bh-2E for behave@ietf.org; Thu, 09 Nov 2006 13:04:41 -0500 Received: from lambda.sipfoundry.org ([72.232.205.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiEGV-0007U4-PZ for behave@ietf.org; Thu, 09 Nov 2006 13:04:41 -0500 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by lambda.sipfoundry.org (8.13.8/8.13.6) with ESMTP id kA9I4YV1073075 for ; Thu, 9 Nov 2006 12:04:39 -0600 (CST) (envelope-from fluffy@cisco.com) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 09 Nov 2006 10:04:29 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kA9I4Tee021339 for ; Thu, 9 Nov 2006 10:04:29 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA9I4Kix003257 for ; Thu, 9 Nov 2006 10:04:26 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 10:04:21 -0800 Received: from [130.129.71.4] ([10.21.81.158]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 10:04:18 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <55DED6EB-96B1-48B8-BC7D-8ACC5C41AE18@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Behave WG From: Cullen Jennings Date: Thu, 9 Nov 2006 09:16:19 -0800 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 09 Nov 2006 18:04:18.0558 (UTC) FILETIME=[79B761E0:01C70429] DKIM-Signature: a=rsa-sha1; q=dns; l=25; t=1163095469; x=1163959469; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:test=20old=20 |Sender:; X=v=3Dcisco.com=3B=20h=3DgshJtUxCWKypFhsse9Hv7uajhPA=3D; b=edAs2WSKN64dQ2BoPIcYaV54kjIPnBhNV3Imv5dHG0kyP9DjswT9tEYBnnhUXs7+V4v7DbmT 2QZ6jj20D2wkWn5Sif3Pdk1Mc0vgsCcO/iK3DnyUff6hCpwH8i3UMqZS; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Cc: Subject: [BEHAVE] test old 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 old 1 - please ignore _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Nov 09 13:04:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiEGH-00083B-HV; Thu, 09 Nov 2006 13:04:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiEGG-00081e-Qm for behave@ietf.org; Thu, 09 Nov 2006 13:04:24 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiEGE-0007SS-V0 for behave@ietf.org; Thu, 09 Nov 2006 13:04:24 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 09 Nov 2006 10:04:22 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kA9I4MDk021209 for ; Thu, 9 Nov 2006 10:04:22 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA9I4Hit003234 for ; Thu, 9 Nov 2006 10:04:22 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 10:04:18 -0800 Received: from [130.129.71.4] ([10.21.81.158]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 10:04:18 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <45AD9D70-019D-4870-9F45-19E37F12D260@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: behave@ietf.org From: Cullen Jennings Date: Thu, 9 Nov 2006 09:15:06 -0800 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 09 Nov 2006 18:04:18.0308 (UTC) FILETIME=[79913C40:01C70429] DKIM-Signature: a=rsa-sha1; q=dns; l=23; t=1163095462; x=1163959462; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:test=20new |Sender:; X=v=3Dcisco.com=3B=20h=3DWft1QavZhu5jrGQgXTVQDY+9RaU=3D; b=aKd6NdMvENqesiP+QomNVx0516aHD+4N6we9jYiiewelahV+qJSyTXLryKRMwR098HmPFrSB KT9aT1qh9xody+n5oDtO1DDDNAq/6O1SwNFDOO3kQJCLiGr7Kgyfjypb; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Subject: [BEHAVE] test new 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 new 1 - please ignore _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Nov 09 13:04:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiEGX-0008Bm-UQ; Thu, 09 Nov 2006 13:04:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiEGX-0008Bh-2E for behave@ietf.org; Thu, 09 Nov 2006 13:04:41 -0500 Received: from lambda.sipfoundry.org ([72.232.205.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiEGV-0007U4-PZ for behave@ietf.org; Thu, 09 Nov 2006 13:04:41 -0500 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by lambda.sipfoundry.org (8.13.8/8.13.6) with ESMTP id kA9I4YV1073075 for ; Thu, 9 Nov 2006 12:04:39 -0600 (CST) (envelope-from fluffy@cisco.com) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 09 Nov 2006 10:04:29 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kA9I4Tee021339 for ; Thu, 9 Nov 2006 10:04:29 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA9I4Kix003257 for ; Thu, 9 Nov 2006 10:04:26 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 10:04:21 -0800 Received: from [130.129.71.4] ([10.21.81.158]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 10:04:18 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <55DED6EB-96B1-48B8-BC7D-8ACC5C41AE18@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Behave WG From: Cullen Jennings Date: Thu, 9 Nov 2006 09:16:19 -0800 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 09 Nov 2006 18:04:18.0558 (UTC) FILETIME=[79B761E0:01C70429] DKIM-Signature: a=rsa-sha1; q=dns; l=25; t=1163095469; x=1163959469; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:test=20old=20 |Sender:; X=v=3Dcisco.com=3B=20h=3DgshJtUxCWKypFhsse9Hv7uajhPA=3D; b=edAs2WSKN64dQ2BoPIcYaV54kjIPnBhNV3Imv5dHG0kyP9DjswT9tEYBnnhUXs7+V4v7DbmT 2QZ6jj20D2wkWn5Sif3Pdk1Mc0vgsCcO/iK3DnyUff6hCpwH8i3UMqZS; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Cc: Subject: [BEHAVE] test old 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 old 1 - please ignore _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Nov 13 21:08:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjnib-0006Qt-UO; Mon, 13 Nov 2006 21:08:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjnhb-00060N-8Z for behave@ietf.org; Mon, 13 Nov 2006 21:07:07 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjnTy-0007KC-Hm for behave@ietf.org; Mon, 13 Nov 2006 20:53:03 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 13 Nov 2006 17:53:02 -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 kAE1r1lA032592 for ; Mon, 13 Nov 2006 17:53:01 -0800 Received: from dwingwxp ([10.32.240.198]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kAE1r1OV021591 for ; Mon, 13 Nov 2006 17:53:01 -0800 (PST) From: "Dan Wing" To: "BEHAVE" Date: Mon, 13 Nov 2006 17:53:00 -0800 Message-ID: <04cc01c7078f$9dcffd80$c6f0200a@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: AccHj51UA+gJ/31GRd+WedHrWighCg== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=325; t=1163469182; x=1164333182; 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:=20WGLC=20for=20draft-ietf-behave-rfc3489bis-05=20starts=20now |Sender:=20; bh=gpK+/CyvUMejnAnaWuG3E0CKM4oC5MCKNRb/iLFtln8=; b=enykQG0sTZGbrkZxXvFD+6XcLosAlb6yW+20YIKRHYmhBQNPjT8ILQ8Pt0NwsV7WxDEqrC5u pijQ/vuTKRaZGmXw64OsRBukRyyGoVOHHdQlhxKZcg+gExCzjubcbuMd; 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: 08e48e05374109708c00c6208b534009 Subject: [BEHAVE] WGLC for draft-ietf-behave-rfc3489bis-05 starts now X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: behave@ietf.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org As agreed at IETF67 in San Diego, the working group last call for STUNbis, http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-05.txt begins now and runs for three weeks, ending at 5pm Pacific Time on Monday, December 4th. Please submit your comments to the BEHAVE mailing list, behave@ietf.org. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Nov 14 04:51:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjux1-0008EM-A6; Tue, 14 Nov 2006 04:51:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjux0-0008DX-3e for behave@ietf.org; Tue, 14 Nov 2006 04:51:30 -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 1Gjuwx-00081d-Ll for behave@ietf.org; Tue, 14 Nov 2006 04:51:30 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3011.me.freeserve.com (SMTP Server) with ESMTP id 169E31C00086; Tue, 14 Nov 2006 10:51:27 +0100 (CET) Received: from Codalogic (user-5445210e.lns4-c11.dsl.pol.co.uk [84.69.33.14]) by mwinf3011.me.freeserve.com (SMTP Server) with ESMTP id CEC001C00083; Tue, 14 Nov 2006 10:51:26 +0100 (CET) X-ME-UUID: 20061114095126847.CEC001C00083@mwinf3011.me.freeserve.com Message-ID: <03cc01c707d2$737ae930$4500a8c0@Codalogic> From: "Pete Cordell" To: "Jonathan Rosenberg" Date: Tue, 14 Nov 2006 09:51:18 -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: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: behave@ietf.org Subject: [BEHAVE] Re: [Ietf-behave] review of rfc3489bis-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org If you're going to the trouble of changing the message ids, would it be sensible to change the attribute ids at the same time so that you can readily tell what is a TURN attribute and what is a base STUN attribute? i.e. starting the TURN attribute numbering at 0x0100. e.g., something like: 0x010D: LIFETIME 0x0110: BANDWIDTH 0x0112: REMOTE-ADDRESS 0x0113: DATA 0x0116: RELAY-ADDRESS 0x0118: REQUESTED-PORT-PROPS 0x0119: REQUESTED-TRANSPORT 0x0122: REQUESTED-IP 0x0121: TIMER-VAL Pete. ----- Original Message ----- From: "Jonathan Rosenberg" To: "Bruce Lowekamp" >> - It would be much easier to implement a stack-level for STUN if >> specific bits indicated whether a message is a request, response, >> error response, or indication. In several spots the draft refers to >> response and error response types as 0x100 and 0x110 higher, which I >> assume is intended to indicate bits to be set, but I don't think it >> technically reads that way. However, no way of determining whether >> a type is an indication is mentioned in the draft. Providing for >> future message types to be identified without recompiling the code >> with a new list of types for a new usage would be very helpful. > > I think this is a good idea, almost a necessity based on the layering > that is now introduced. You are correct that currently nothing indicates > that a message is an indication, and it should. Unfortunately the > currently allocated values for the TURN indications (which is the only > place they are being used) doesn't allow an easy way to identify them. > > However I think we are better off changing the turn message values to > fix this. > > I have now made this explicit by using two bits from the message type > header field to indicate the "class" of the message (request, success > response, error response, indication), and the remaining 12 bits are the > method. This formalizes the message type structure which has been there > till now. Unfortunately this will require a change in the message type > values for the indications in TURN, but I think its worth it. > -- ============================================= 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 Tue Nov 14 16:18:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk5ez-0005HJ-Ji; Tue, 14 Nov 2006 16:17:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk5ey-0005Fy-CE; Tue, 14 Nov 2006 16:17:36 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk5ex-0006wX-2K; Tue, 14 Nov 2006 16:17:36 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 14 Nov 2006 13:17:34 -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 kAELHYlu021028; Tue, 14 Nov 2006 13:17:34 -0800 Received: from dwingwxp (dhcp-171-69-137-73.cisco.com [171.69.137.73]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kAELHYOV017000; Tue, 14 Nov 2006 13:17:34 -0800 (PST) From: "Dan Wing" To: "'Jean-Francois Mule'" Date: Tue, 14 Nov 2006 13:17:34 -0800 Keywords: direct-to-dwing Message-ID: <0cde01c70832$4d79bf80$c6f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccICyh4+P0qMQwDStuqAtLDA24P3gAGIPDgAAIZDgAAAVQNcA== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1464; t=1163539054; x=1164403054; 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:=20RE=3A=20[MMUSIC]=20some=20comments=20on=20ice-12, =20part=20on e |Sender:=20; bh=KhziEH+N1plQ7No7XCXx7fJP8t+1zvEsPI4c8uoYSpY=; b=nDQqmLrHYg4OgJzUJ1IPFVE3JUrTWVuJy6XLG2YRno/ycnNDMre49cOBuvpNCZvJFB+xqBWH gJGMxzj8TfoApaw/cHFo0P9H70Ep20N9eQkKqqAB/oddIIjgNFWAYdvY; 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: 52e1467c2184c31006318542db5614d5 Cc: BEHAVE , mmusic@ietf.org Subject: [BEHAVE] RE: [MMUSIC] some comments on ice-12, part one 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 (Adding BEHAVE to this discussion.) > Dan Wing wrote: > > It is anticipated that BEHAVE's "application" milestone > > will describe how ICE's techniques can be used by non-SDP > > applications. As of now, draft-ford-behave-app-04.txt is > > the most likely candidate document to meet > > BEHAVE's "application" milestone, but it hasn't yet been > > adopted as a working group document. > > I was not aware of this work item, thanks, this works for me. > Just a minor note: > - Scanning through draft-ford-behave-app-04.txt, it takes > the following approach: "if you build an app, here are the > things you should be aware of and some techniques that can > be used." That is an accurate summary. > - My comment was targeted more specifically at protocol > designers: if you build a protocol that intends to use ICE, > here are some of the properties the protocol should have > and here is the vocabulary that should be added to convey > the ICE semantics. This sounds different from a 'design rationale', which is what I thought you were asking about. (For everyone else's reference, we're all referring to http://www1.ietf.org/mail-archive/web/mmusic/current/msg04935.html) I wonder if such a document is necessary. For example, from what I have seen of XMPP/Jingle's adoption of ICE maybe they did everything right, and even in a way that can allow signaling-only box to do SIP/XMPP interworking. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Nov 14 18:24:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk7cu-0007rF-FM; Tue, 14 Nov 2006 18:23:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk7ct-0007rA-P2 for behave@ietf.org; Tue, 14 Nov 2006 18:23:35 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk7cs-0002mE-G4 for behave@ietf.org; Tue, 14 Nov 2006 18:23:35 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 14 Nov 2006 15:23:33 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kAENNXPs025236 for ; Tue, 14 Nov 2006 15:23:33 -0800 Received: from dwingwxp (sjc-vpn5-599.cisco.com [10.21.90.87]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAENNVio009983 for ; Tue, 14 Nov 2006 15:23:32 -0800 (PST) From: "Dan Wing" To: "BEHAVE" Date: Tue, 14 Nov 2006 15:23:25 -0800 Message-ID: <10ba01c70843$e6d1ab00$c6f0200a@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: AccIQimIzkHgbz0sQIKttXDFLqAuoA== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=187; t=1163546613; x=1164410613; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20document=20status |Sender:=20; bh=qnVTK2ADSXo4aFGVgygYBiSkZWjOLFfWvjXoJzyQn7o=; b=WKmDrYWnI7lz8TxgQ1xzcMG/rhl49luO+Jgv99C4E09GpIFdftUF8GTQYGamXNxQK0FUVGqh 5hT727mM0GY1DImfGnZzck4C9HSivF2eB/nONvsth9ezS17yJD/6MZLM; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [BEHAVE] document status X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I started maintaining a document status page at: http://www.employees.org/behave/document-status.html Please let me know if there are any adjustments that need to be made. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Nov 15 13:35:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkPat-0003uK-2C; Wed, 15 Nov 2006 13:34:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkPar-0003rd-HQ for behave@ietf.org; Wed, 15 Nov 2006 13:34:41 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkPaq-0005hC-0k for behave@ietf.org; Wed, 15 Nov 2006 13:34:41 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id kAFIYcfZ004651 for ; Wed, 15 Nov 2006 11:34:39 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 15 Nov 2006 11:34:38 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review of rfc3489bis-05 Thread-Index: AccI5LIXtiTSUkwYSq6j7k03W5EkaA== From: "Kevin Johns" To: X-Approved: ondar X-Spam-Score: 0.1 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Subject: [BEHAVE] review of 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="===============1896345202==" Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. --===============1896345202== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C708E4.B5064FEB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C708E4.B5064FEB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I have been reviewing rfc3489bis-05 and have two technical concerns with the transaction ID requirements. =20 First, for the indication message. Per the text in section 6 indication messages include a transaction id within the same number space as requests with a requirement that the transaction ID be unique for each unique indication. =20 The concern here is the potential for collisions with requests and responses. If a Client is generating an indication, it is rather straightforward to ensure that the transaction ID is unique for all requests generated by that client. However, when a server is generating an indication, it is much harder for the server to ensure the transaction ID is unique as it must now store all transaction IDs for each client it has received a STUN request from to avoid collisions with previously sent responses. =20 Given that indication messages are unreliable and are not re-transmitted I do not see the need in providing a unique transaction ID. Rather I would like to suggest that the transaction ID for all indications be 0 and that the number space for requests be changed from 0 - 2**96-1 to 1-2**96-1. =20 Second, managing transaction IDs in general. Given a server will be receiving requests from many clients the possibility for a transaction ID collision is likely (how likely depends on a number of factors). There does not appear to be any good method for the server to manage this and thus will have a difficult time in determining if a request is a re-transmission or simply a transaction ID collision. Unfortunately a STUN request does not have any mandatory attributes which can be used in conjunction with the transaction ID by the server to create a unique tuple. The only way I currently see to resolve this is to require the server to not only remember the transaction ID but also the source of the request (source IP and Port) so that it can disambiguate between a re-transmission (same transaction ID from a previous source) and a transaction ID collision (same transaction ID but different source). =20 Regards, Kevin =20 ~~~~~~~~~~~~~~~~~~~~~~ Kevin C. Johns Project Director - PacketCable Communications Protocols CableLabs(r) 858 Coal Creek Circle Louisville, CO 80027-9750 Phone: 303.661.9100 Direct: 303.661.3303 HTTP://www.CableLabs.com =20 =20 ------_=_NextPart_001_01C708E4.B5064FEB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I have = been=20 reviewing rfc3489bis-05 and have two technical concerns with the=20 transaction ID requirements.
 
First, for the=20 indication message. Per the text in section 6 indication messages = include a=20 transaction id within the same number space as requests with=20 a requirement that the transaction ID be unique for each unique=20 indication.
 
The = concern here is=20 the potential for collisions with requests and responses. If a Client is = generating an indication, it is rather straightforward to ensure that = the=20 transaction ID is unique for all requests generated by that client. = However,=20 when a server is generating an indication, it is much harder for the = server to=20 ensure the transaction ID is unique as it must now store all transaction = IDs for=20 each client it has received a STUN request from to avoid collisions with = previously sent responses.
 
Given = that=20 indication messages are unreliable and are not re-transmitted I do not = see the=20 need in providing a unique transaction ID. Rather I would like to = suggest that=20 the transaction ID for all indications be 0 and that the number space = for=20 requests be changed from 0 - 2**96-1 to 1-2**96-1.
 
Second, managing=20 transaction IDs in general. Given a server will be receiving requests = from many=20 clients the possibility for a transaction ID collision is likely (how = likely=20 depends on a number of factors). There does not appear to be any good = method for=20 the server to manage this and thus will have a difficult time in = determining if=20 a request is a re-transmission or simply a transaction ID collision.=20 Unfortunately a STUN request does not have any mandatory attributes = which can be=20 used in conjunction with the transaction ID by the server to create a = unique=20 tuple. The only way I currently see to resolve this is to require the = server to=20 not only remember the transaction ID but also the source of the request = (source=20 IP and Port) so that it can disambiguate between a re-transmission (same = transaction ID from a previous source) and a transaction ID collision = (same=20 transaction ID but different source).
 
Regards,
Kevin
 

~~~~~~~~~~~~~~~~~~~~~~
Kevin C.=20 Johns
Project Director - PacketCable Communications=20 Protocols
CableLabs®
858 Coal Creek Circle
Louisville, CO=20 80027-9750
Phone:  303.661.9100
Direct: = 303.661.3303
HTTP://www.CableLabs.com =

 
------_=_NextPart_001_01C708E4.B5064FEB-- --===============1896345202== 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 --===============1896345202==-- From behave-bounces@ietf.org Wed Nov 15 14:44:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkQfu-0001Ft-Ju; Wed, 15 Nov 2006 14:43:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkQft-0001F6-Ga for behave@ietf.org; Wed, 15 Nov 2006 14:43:57 -0500 Received: from wr-out-0506.google.com ([64.233.184.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkQfr-0007Ms-5a for behave@ietf.org; Wed, 15 Nov 2006 14:43:57 -0500 Received: by wr-out-0506.google.com with SMTP id i30so100417wra for ; Wed, 15 Nov 2006 11:43:54 -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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ras/m0T+5jIAi0NOdlJwojbPf8KTl00Uq/OGsa/pGzEIw0Kc2GyN/HXxthvERmvKQ/o+VnF/HeBGhbswhMXq964H4kaGqfARMdcZJVBuRJ/BAVdiS7dmlLw0qVl2L6kf8KfcWWx2fq7YiFXSvBzfsAKKFfD6j+WS7pycnlEw1W8= Received: by 10.65.159.3 with SMTP id l3mr4029848qbo.1163619834036; Wed, 15 Nov 2006 11:43:54 -0800 (PST) Received: by 10.65.123.19 with HTTP; Wed, 15 Nov 2006 11:43:53 -0800 (PST) Message-ID: <20d2bdfb0611151143v452d2241lb7926dc491c3bb93@mail.gmail.com> Date: Wed, 15 Nov 2006 14:43:53 -0500 From: "Bruce Lowekamp" To: "Kevin Johns" Subject: Re: [BEHAVE] review of rfc3489bis-05 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: X-Google-Sender-Auth: 41906fe52ce042d9 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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 thoughts inline On 11/15/06, Kevin Johns wrote: > > > Hi, > > I have been reviewing rfc3489bis-05 and have two technical concerns with the > transaction ID requirements. > > First, for the indication message. Per the text in section 6 indication > messages include a transaction id within the same number space as requests > with a requirement that the transaction ID be unique for each unique > indication. > > The concern here is the potential for collisions with requests and > responses. If a Client is generating an indication, it is rather > straightforward to ensure that the transaction ID is unique for all requests > generated by that client. However, when a server is generating an > indication, it is much harder for the server to ensure the transaction ID is > unique as it must now store all transaction IDs for each client it has > received a STUN request from to avoid collisions with previously sent > responses. I don't read the text the same way. I don't see any implication that the IDs must be unique between each side of the connection, the text just says that each ID that the client generates must be unique among IDs generated by the client and that each ID the server generates must be unique among IDs generated by the server. Practically speaking, I can't imagine that most implementations would do anything other than generate a random number, maybe compare it with outstanding transactions, and then send it. > > Given that indication messages are unreliable and are not re-transmitted I > do not see the need in providing a unique transaction ID. Rather I would > like to suggest that the transaction ID for all indications be 0 and that > the number space for requests be changed from 0 - 2**96-1 to 1-2**96-1. > You have to assume that indications are idempotent. Of course, you're right that since indications are unreliable, whatever is generating them would have to implement its own duplicate detection and retransmission anyway, but in general I would rather make it easy for an implementation to drop a duplicated indication. Perhaps a good solution to the issue here is to explicitly require less state by requiring the IDs not to be repeated over some interval, rather than forever. > Second, managing transaction IDs in general. Given a server will be > receiving requests from many clients the possibility for a transaction ID > collision is likely (how likely depends on a number of factors). There does > not appear to be any good method for the server to manage this and thus will > have a difficult time in determining if a request is a re-transmission or > simply a transaction ID collision. Unfortunately a STUN request does not > have any mandatory attributes which can be used in conjunction with the > transaction ID by the server to create a unique tuple. The only way I > currently see to resolve this is to require the server to not only remember > the transaction ID but also the source of the request (source IP and Port) > so that it can disambiguate between a re-transmission (same transaction ID > from a previous source) and a transaction ID collision (same transaction ID > but different source). Given that the ID space is 96 bits, even for a server handling thousands of clients the odds of a collision occuring seems to be sufficiently small as to be negligible. If a server really wants to do this, though, it could use a NONCE to identify which client it's dealing with. I guess right now NONCEs can only be used when using integrity, but that seems like it's going to be the common case for a stand-alone STUN server, which is the only scenario that occurs offhand where this might be a problem. Bruce > Regards, > Kevin > > > ~~~~~~~~~~~~~~~~~~~~~~ > Kevin C. Johns > Project Director - PacketCable Communications Protocols > CableLabs(r) > 858 Coal Creek Circle > Louisville, CO 80027-9750 > Phone: 303.661.9100 > Direct: 303.661.3303 > HTTP://www.CableLabs.com > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Nov 16 17:36:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkpp4-00033E-IP; Thu, 16 Nov 2006 17:35:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkpp2-00032r-Qa for behave@ietf.org; Thu, 16 Nov 2006 17:35:04 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkpp1-000530-BF for behave@ietf.org; Thu, 16 Nov 2006 17:35:04 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id kAGMZ2tb009883 for ; Thu, 16 Nov 2006 15:35:02 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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 Date: Thu, 16 Nov 2006 15:35:01 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] review of rfc3489bis-05 Thread-Index: AccI7mL2prhgmUZUTaGSQ4rxxnoIzAA39BDg From: "Kevin Johns" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 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 Bruce, Thanks for the response. If folks are ok with the idea that the transaction ID number space is sufficiently large that collisions are not an issue, then I guess I can go along with that given that they are suppose to be random. As for indications, I might be missing something here but given their definition I do not see why a transaction ID is needed. There is nothing to correlate the indication with and there is no way to have a duplicate or re-transmission per the text. This seems to be adding additional complexity with no usage by the protocol. Kevin -----Original Message----- From: Bruce Lowekamp [mailto:lowekamp@sipeerior.com]=20 Sent: Wednesday, November 15, 2006 12:44 PM To: Kevin Johns Cc: behave@ietf.org Subject: Re: [BEHAVE] review of rfc3489bis-05 thoughts inline On 11/15/06, Kevin Johns wrote: > > > Hi, > > I have been reviewing rfc3489bis-05 and have two technical concerns=20 > with the transaction ID requirements. > > First, for the indication message. Per the text in section 6=20 > indication messages include a transaction id within the same number=20 > space as requests with a requirement that the transaction ID be unique > for each unique indication. > > The concern here is the potential for collisions with requests and=20 > responses. If a Client is generating an indication, it is rather=20 > straightforward to ensure that the transaction ID is unique for all=20 > requests generated by that client. However, when a server is=20 > generating an indication, it is much harder for the server to ensure=20 > the transaction ID is unique as it must now store all transaction IDs=20 > for each client it has received a STUN request from to avoid=20 > collisions with previously sent responses. I don't read the text the same way. I don't see any implication that the IDs must be unique between each side of the connection, the text just says that each ID that the client generates must be unique among IDs generated by the client and that each ID the server generates must be unique among IDs generated by the server. Practically speaking, I can't imagine that most implementations would do anything other than generate a random number, maybe compare it with outstanding transactions, and then send it. > > Given that indication messages are unreliable and are not=20 > re-transmitted I do not see the need in providing a unique transaction > ID. Rather I would like to suggest that the transaction ID for all=20 > indications be 0 and that the number space for requests be changed from 0 - 2**96-1 to 1-2**96-1. > You have to assume that indications are idempotent. Of course, you're right that since indications are unreliable, whatever is generating them would have to implement its own duplicate detection and retransmission anyway, but in general I would rather make it easy for an implementation to drop a duplicated indication. Perhaps a good solution to the issue here is to explicitly require less state by requiring the IDs not to be repeated over some interval, rather than forever. > Second, managing transaction IDs in general. Given a server will be=20 > receiving requests from many clients the possibility for a transaction > ID collision is likely (how likely depends on a number of factors).=20 > There does not appear to be any good method for the server to manage=20 > this and thus will have a difficult time in determining if a request=20 > is a re-transmission or simply a transaction ID collision.=20 > Unfortunately a STUN request does not have any mandatory attributes=20 > which can be used in conjunction with the transaction ID by the server > to create a unique tuple. The only way I currently see to resolve this > is to require the server to not only remember the transaction ID but=20 > also the source of the request (source IP and Port) so that it can=20 > disambiguate between a re-transmission (same transaction ID from a=20 > previous source) and a transaction ID collision (same transaction ID but different source). Given that the ID space is 96 bits, even for a server handling thousands of clients the odds of a collision occuring seems to be sufficiently small as to be negligible. If a server really wants to do this, though, it could use a NONCE to identify which client it's dealing with. I guess right now NONCEs can only be used when using integrity, but that seems like it's going to be the common case for a stand-alone STUN server, which is the only scenario that occurs offhand where this might be a problem. Bruce > Regards, > Kevin > > > ~~~~~~~~~~~~~~~~~~~~~~ > Kevin C. Johns > Project Director - PacketCable Communications Protocols > CableLabs(r) > 858 Coal Creek Circle > Louisville, CO 80027-9750 > Phone: 303.661.9100 > Direct: 303.661.3303 > HTTP://www.CableLabs.com > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Nov 16 18:53:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkr2h-0000xf-Sd; Thu, 16 Nov 2006 18:53:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkr2f-0000xT-Nm for behave@ietf.org; Thu, 16 Nov 2006 18:53:13 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkr2e-0000YQ-7C for behave@ietf.org; Thu, 16 Nov 2006 18:53:13 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id kAGNrBoR006971 for ; Thu, 16 Nov 2006 16:53:11 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 16 Nov 2006 16:53:10 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review of rfc3489bis-05 - upto section 8 Thread-Index: AccJ2loOP92Wwj5aTTmkVzoF1BrMRQ== From: "Kevin Johns" To: X-Approved: ondar X-Spam-Score: 0.1 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b Subject: [BEHAVE] review of rfc3489bis-05 - upto section 8 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="===============0501214793==" Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. --===============0501214793== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C709DA.5ECAF1EC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C709DA.5ECAF1EC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I have been reviewing rfc3489bis-05 and have some comments on the text upto section 8. These are mostly focused on suggested additions of normative statements to the existing text as well as a few editorial comments. Where suggesting text be made normative I have tried to verify that related normative statements do not appear later in the document. =20 Kevin =20 Section 2 (Introduction), second to last para: I found this a bit confusing as it seems to be saying that online games and Voice over IP are proprietary protocols, when I think it is trying to say that proprietary version of these protocols have been developed to address NATs? =20 Section 5 (Overview of Operation), first para: This paragraph indicates that normative behavior is defined in sections 8 and 9. This should also indicate that sections 6 and 7 provide normative behavior as well. =20 Section 6 (STUN Message Structure), first para: There seems to be duplicate information in the first few sentence of the opening paragraph. Suggest striking the second, third and fourth sentences. =20 Section 6 (STUN Message Structure), fifth para: Consider making this a normative statement - All STUN messages MUST consist of a 20 byte header as defined below: =20 Section 6 (STUN Message Structure), first para after figure 2 (format of STUN Message Header) consider adding normative statements: The most significant two bits of every STUN message MUST be zeros. =20 Section 6 (STUN Message Structure), second para after figure 2 (format of STUN Message Header) should read: The STUN message... =20 Section 6 (STUN Message Structure), second para after figure 3 (format of STUN Message Type Field) consider making normative and clarify with field: The message length field MUST contain the size, in bytes, ... =20 Section 6 (STUN Message Structure), third para after figure 3 (format of STUN Message Type Field) consider making normative and clarify with field: The magic cookie field MUST contain the fixed value of... =20 Section 6 (STUN Message Structure), first para before figure 4 (format of STUN Attributes) consider making normative: After the STUN header are zero or more attributes. Each attribute MUST be TLV encoded, with a 16 bit type, 16 bit length, and variable value. Each STUN attribute MUST end on a 32 bit boundary. =20 Section 6 (STUN Message Structure), first para after figure 4 (format of STUN Attributes) consider making normative: The value in the Length field MUST contain the length of the Value part of the attribute prior to padding... =20 Section 7.1 (Request/Response Transactions), fourth para, consider making the last sentence normative: If the client has not received a response after 7900ms, it MUST consider the transaction to have timed out. =20 ~~~~~~~~~~~~~~~~~~~~~~ Kevin C. Johns Project Director - PacketCable Communications Protocols CableLabs(r) 858 Coal Creek Circle Louisville, CO 80027-9750 Phone: 303.661.9100 Direct: 303.661.3303 HTTP://www.CableLabs.com =20 =20 ------_=_NextPart_001_01C709DA.5ECAF1EC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I have = been=20 reviewing rfc3489bis-05 and have some comments on the text upto section = 8. These=20 are mostly focused on suggested additions of normative statements = to the=20 existing text as well as a few editorial comments. Where suggesting text = be made=20 normative I have tried to verify that related normative statements do = not appear=20 later in the document.
 
Kevin
 

Section 2 (Introduction), second to last para: I found this a = bit=20 confusing as it seems to be saying that online games and Voice over IP = are=20 proprietary protocols, when I think it is trying to say that proprietary = version=20 of these protocols have been developed to address NATs?

 

Section 5 (Overview of Operation), first para: This paragraph = indicates=20 that normative behavior is defined in sections 8 and 9. This should also = indicate that sections 6 and 7 provide normative behavior as = well.

 

Section 6 (STUN Message Structure), first para: There seems to = be=20 duplicate information in the first few sentence of the opening = paragraph.=20 Suggest striking the second, = third and=20 fourth sentences.

 

Section 6 (STUN Message Structure), fifth para: Consider making = this a=20 normative statement – All STUN messages MUST consist of a 20 byte = header as=20 defined below:

 

Section 6 (STUN Message Structure), first para after figure 2 = (format of=20 STUN Message Header) consider adding normative statements: The most = significant=20 two bits of every STUN message MUST be zeros.

 

Section 6 (STUN Message Structure), second para after figure 2 = (format of=20 STUN Message Header) should read: The STUN message…

 

Section 6 (STUN Message Structure), second para after figure 3 = (format of=20 STUN Message Type Field) consider making normative and clarify with = field: The=20 message length field MUST contain the size, in bytes, …

 

Section 6 (STUN Message Structure), third para after figure 3 = (format of=20 STUN Message Type Field) consider making normative and clarify with = field: The=20 magic cookie field MUST contain the fixed value of…

 

Section 6 (STUN Message Structure), first para before figure 4 = (format of=20 STUN Attributes) consider making normative: After the STUN header are = zero or=20 more attributes. Each attribute MUST be TLV encoded, with a 16 bit type, = 16 bit=20 length, and variable value. Each STUN attribute MUST end on a 32 bit=20 boundary.

 

Section 6 (STUN Message Structure), first para after figure 4 = (format of=20 STUN Attributes) consider making normative: The value in the Length = field MUST=20 contain the length of the Value part of the attribute prior to=20 padding…

 

Section 7.1 (Request/Response Transactions), fourth para, = consider making=20 the last sentence normative: If the client has not received a response = after=20 7900ms, it MUST consider the transaction to have timed=20 out.

 

~~~~~~~~~~~~~~~~~~~~~~
Kevin C.=20 Johns
Project Director - PacketCable Communications=20 Protocols
CableLabs®
858 Coal Creek Circle
Louisville, CO=20 80027-9750
Phone:  303.661.9100
Direct: = 303.661.3303
HTTP://www.CableLabs.com =

 
------_=_NextPart_001_01C709DA.5ECAF1EC-- --===============0501214793== 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 --===============0501214793==-- From behave-bounces@ietf.org Thu Nov 16 19:02:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkrBj-0002j5-EQ; Thu, 16 Nov 2006 19:02:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkrBi-0002iz-Qa for behave@ietf.org; Thu, 16 Nov 2006 19:02:34 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkrBh-0001vr-GN for behave@ietf.org; Thu, 16 Nov 2006 19:02:34 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id kAH02WYn009419 for ; Thu, 16 Nov 2006 17:02:32 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 16 Nov 2006 17:02:31 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: STUN message type field Thread-Index: AccJ26iYz45F8fE8TxWNUf4qPO7DeA== From: "Kevin Johns" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Subject: [BEHAVE] STUN message type field 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="===============2098651491==" Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. --===============2098651491== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C709DB.AD4E2158" This is a multi-part message in MIME format. ------_=_NextPart_001_01C709DB.AD4E2158 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 In looking at the STUN header, I am a bit confused by the STUN message type field. There are two M2 entries (should one be a M1?) and there is a C0 and C1 intermixed. I was wondering why the field is formatted this way, it seems one would want to group common field together (i.e. C0 and C1 would be next to each other) rather then spread them about? =20 Thanks Kevin =20 ~~~~~~~~~~~~~~~~~~~~~~ Kevin C. Johns Project Director - PacketCable Communications Protocols CableLabs(r) 858 Coal Creek Circle Louisville, CO 80027-9750 Phone: 303.661.9100 Direct: 303.661.3303 HTTP://www.CableLabs.com =20 =20 ------_=_NextPart_001_01C709DB.AD4E2158 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
In = looking at the=20 STUN header, I am a bit confused by the STUN message type field. There = are two=20 M2 entries (should one be a M1?) and there is a C0 and C1 intermixed. I = was=20 wondering why the field is formatted this way, it seems one would want = to group=20 common field together (i.e. C0 and C1 would be next to each other) = rather then=20 spread them about?
 
Thanks
Kevin
 

~~~~~~~~~~~~~~~~~~~~~~
Kevin C.=20 Johns
Project Director - PacketCable Communications=20 Protocols
CableLabs®
858 Coal Creek Circle
Louisville, CO=20 80027-9750
Phone:  303.661.9100
Direct: = 303.661.3303
HTTP://www.CableLabs.com =

 
------_=_NextPart_001_01C709DB.AD4E2158-- --===============2098651491== 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 --===============2098651491==-- From behave-bounces@ietf.org Thu Nov 16 20:11:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GksFg-0003KN-Fr; Thu, 16 Nov 2006 20:10:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GksFd-0003K5-Gc for behave@ietf.org; Thu, 16 Nov 2006 20:10:42 -0500 Received: from mailx.8x8.com ([192.84.19.237] helo=mailint.8x8.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GksFc-0002v7-5D for behave@ietf.org; Thu, 16 Nov 2006 20:10:41 -0500 Received: from mailint.8x8.com (localhost.localdomain [127.0.0.1]) by mailint.8x8.com (8.13.1/8.13.1) with ESMTP id kAH1A7pa021512; Thu, 16 Nov 2006 17:10:08 -0800 Received: from mailint.8x8.com (root@localhost) by mailint.8x8.com (8.13.1/8.13.1/Submit) with ESMTP id kAH1A7VQ021511; Thu, 16 Nov 2006 17:10:07 -0800 Received: from [10.0.2.15] (godzilla.8x8.com 192.168.84.42) by mailint.8x8.com (Scalix SMTP Relay 10.0.1.3) via ESMTP; Thu, 16 Nov 2006 17:10:07 -0800 (PST) Date: Thu, 16 Nov 2006 17:10:08 -0800 From: Marc Petit-Huguenin To: Kevin Johns Message-ID: <455D0BF0.5000206@acm.org> In-Reply-To: References: Subject: Re: [BEHAVE] STUN message type field x-scalix-Hops: 1 User-Agent: Icedove 1.5.0.7 (X11/20061013) MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 Kevin Johns wrote: > > Hi, > > In looking at the STUN header, I am a bit confused by the STUN message > type field. There are two M2 entries (should one be a M1?) and there is > a C0 and C1 intermixed. I was wondering why the field is formatted this > way, it seems one would want to group common field together (i.e. C0 and > C1 would be next to each other) rather then spread them about? This is for compability with RFC 3489. If I remember well, it was decided in the BEHAVE session to add some text to explain that. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Nov 17 17:16:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlC0B-000795-87; Fri, 17 Nov 2006 17:16:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlC09-00078y-Rb for behave@ietf.org; Fri, 17 Nov 2006 17:16:01 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlC07-00018x-C2 for behave@ietf.org; Fri, 17 Nov 2006 17:16:01 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id kAHMFwAd001796 for ; Fri, 17 Nov 2006 15:15:58 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 17 Nov 2006 15:15:57 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review of rfc3489bis-05 - section 8 onward... Thread-Index: AccKlfJfphXRfyPgT2222m207Ge2Zg== From: "Kevin Johns" To: X-Approved: ondar X-Spam-Score: 0.1 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Subject: [BEHAVE] review of rfc3489bis-05 - 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: , Content-Type: multipart/mixed; boundary="===============1232952518==" Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. --===============1232952518== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70A95.F48FCF3E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70A95.F48FCF3E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Here are my comments which follow-up those sent earlier in the week. =20 Kevin =20 Section 8.3.1 (formulating the request message) Suggest making the first sentence normative. The client MUST follow the syntax rules... =20 Section 8.3.2 (processing responses) In the first paragraph it discusses discarding further responses for the same request. There is no guidance on how long the client should continue to discard responses. Given this is based on the transaction ID, would it make sense to add a requirement that the client MUST not repeat a transaction ID for some period of time? Later on it state the server must remember the response to a given transaction ID for 10 seconds. =20 Section 9.1.1 (receive request message) The ninth paragraph (discusses error codes 430 and 436). Consider adding normative statements to match the other paragraphs in this section, (i.e. If the USERNAME as previously valid but has expired, the server MUST generate and error response. The error response MUST include an ERROR-CODE attribute with a response code of 430 (state credentials). The same suggestion applies to error response 436 later in the same paragraph. =20 Section 9.1.1 (receive request message) Last paragraph; When the server sends a 420 response code, should it not also be required to include a UNKNOWN-ATTRIBUTE attribute in the response? =20 Section 9.1.2 (constructing responses) First sentence; suggest this be made normative and add a reference to section 7 as well. =20 Section 9.1.3 (sending the response) Suggest making the two sentences in this section normative. =20 Section 11.1 (mapped-address) I would suggest adding a few normative statements to line up with the other attribute definitions. In particular: If the address family is IPv4, the address MUST be 32 bits, in network byte order. If the address family is IPv6, the address MUST be 128 bits, in network bye order. =20 Section 11.11 (server) If found the first sentence a bit confusing: The alternate server represents an alternate transport address for a different STUN server to try. =20 Consider revising to: The alternate server represents an alternate transport address identifying a different STUN server which the STUN client should try. =20 Section 12 (STUN usages): Would it be possible to add a STUN attributes table for each STUN usage? I see that the section on short-term password has such a table, it would be nice to have a similar table for the binding usage? =20 Section 12.2 (NAT keepalives) I noticed that no where in this section was the method type mentioned. Given the spec only defines two methods (bindings and shared secret) it is obvious that the binding method is applicable, but it might not hurt to state the obvious? =20 ------_=_NextPart_001_01C70A95.F48FCF3E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Here are my comments which follow-up those = sent earlier=20 in the week.
 
Kevin
 

Section 8.3.1 = (formulating the=20 request message)

Suggest making the = first sentence=20 normative. The client MUST follow the syntax rules…

 

Section 8.3.2 = (processing=20 responses)

In the first = paragraph it=20 discusses discarding further responses for the same request. There is no = guidance on how long the client should continue to discard responses. = Given this=20 is based on the transaction ID, would it make sense to add a requirement = that=20 the client MUST not repeat a transaction ID for some period of time? = Later on it=20 state the server must remember the response to a given transaction ID = for 10=20 seconds.

 

Section 9.1.1 = (receive request=20 message)

The ninth paragraph = (discusses=20 error codes 430 and 436). Consider adding normative statements to match = the=20 other paragraphs in this section, (i.e. If the USERNAME as previously = valid but=20 has expired, the server MUST generate and error response. The error = response=20 MUST include an ERROR-CODE attribute with a response code of 430 (state=20 credentials). The same suggestion applies to error response 436 later in = the=20 same paragraph.

 

Section 9.1.1 = (receive request=20 message)

Last paragraph; When = the server=20 sends a 420 response code, should it not also be required to include a=20 UNKNOWN-ATTRIBUTE attribute in the response?

 

Section 9.1.2 = (constructing=20 responses)

First sentence; = suggest this be=20 made normative and add a reference to section 7 as well.

 

Section 9.1.3 = (sending the=20 response)

Suggest making the = two sentences=20 in this section normative.

 

Section 11.1 = (mapped-address)

I would suggest = adding a few=20 normative statements to line up with the other attribute definitions. In = particular:

If the address family = is IPv4,=20 the address MUST be 32 bits, in network byte order. If the address = family is=20 IPv6, the address MUST be 128 bits, in network bye order.

 

Section 11.11 = (server)

If found the first = sentence a bit=20 confusing:

The alternate server = represents=20 an alternate transport address for a different STUN server to try.

 

Consider revising = to:

The alternate server = represents=20 an alternate transport address identifying a different STUN server which = the=20 STUN client should try.

 

Section 12 (STUN = usages):

Would it be possible = to add a=20 STUN attributes table for each STUN usage? I see that the section on = short-term=20 password has such a table, it would be nice to have a similar table for = the=20 binding usage?

 

Section 12.2 (NAT = keepalives)

I noticed that no = where in this=20 section was the method type mentioned. Given the spec only defines two = methods=20 (bindings and shared secret) it is obvious that the binding method is=20 applicable, but it might not hurt to state the obvious?

 
------_=_NextPart_001_01C70A95.F48FCF3E-- --===============1232952518== 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 --===============1232952518==-- From behave-bounces@ietf.org Fri Nov 17 17:24:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlC8F-0002tB-9A; Fri, 17 Nov 2006 17:24:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlC8E-0002t4-5g for behave@ietf.org; Fri, 17 Nov 2006 17:24:22 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlC8C-0004yj-Qu for behave@ietf.org; Fri, 17 Nov 2006 17:24:22 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id kAHMOI0Z004815; Fri, 17 Nov 2006 15:24:18 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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 message type field Date: Fri, 17 Nov 2006 15:24:17 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] STUN message type field Thread-Index: AccJ5SWVnXAGZuvYRnWmOg02Qvn10wAsapBw From: "Kevin Johns" To: "Marc Petit-Huguenin" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Ok, I can see that now looking at RFC 3489, a bit of text explaining this might be helpful, but not necessary. I still think the two occurrences of M2 is an error and it should actually be M1 and M2: 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| | | | | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^^ Kevin=20 -----Original Message----- From: Marc Petit-Huguenin [mailto:petithug@acm.org]=20 Sent: Thursday, November 16, 2006 6:10 PM To: Kevin Johns Cc: behave@ietf.org Subject: Re: [BEHAVE] STUN message type field Kevin Johns wrote: >=20 > Hi, > =20 > In looking at the STUN header, I am a bit confused by the STUN message > type field. There are two M2 entries (should one be a M1?) and there=20 > is a C0 and C1 intermixed. I was wondering why the field is formatted=20 > this way, it seems one would want to group common field together (i.e. > C0 and > C1 would be next to each other) rather then spread them about? This is for compability with RFC 3489. If I remember well, it was decided in the BEHAVE session to add some text to explain that. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Nov 18 14:08:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlVXB-0001On-W0; Sat, 18 Nov 2006 14:07:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlVXB-0001NU-6g for behave@ietf.org; Sat, 18 Nov 2006 14:07:25 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlVX8-00070K-Qt for behave@ietf.org; Sat, 18 Nov 2006 14:07:25 -0500 Received: from [192.168.0.4] (cpe-76-183-190-193.tx.res.rr.com [76.183.190.193]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id kAIJ7FHu027513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 18 Nov 2006 13:07:20 -0600 (CST) (envelope-from brian@estacado.net) Message-ID: <455F59E5.5000308@estacado.net> Date: Sat, 18 Nov 2006 13:07:17 -0600 From: Brian Hibbard User-Agent: Thunderbird 1.5.0.7 (X11/20060922) MIME-Version: 1.0 To: behave@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [BEHAVE] use of NONCE in 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 Use of NONCE is mandatory with long-term credentials, but not with short-term credentials, where it's use is optional. From sec 9.1.1 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). Unless I'm missing something, it seems to me it would be better if the server SHOULD or MUST use NONCE for short-term secrets as well. If I understand properly, the reasoning behind not using NONCE with short-term secrets is that their validity is already constrained temporally by being short-term and this provides adequate protection from password cracking. However, I don't see how that would stop an attacker who is capable of mounting a replay attack using requests (especially STUN Relay Allocate Requests) that are authenticated with a short-term secret. MESSAGE-INTEGRITY doesn't include any fields from IP, TCP, or UDP. Also, there is verbage discussing how the short-term secret might be formulated in the server that suggests using the sender's IP, but there is nothing that suggests that the server validate the username/password using that same mechanism (which would be cumbersome) for all subsequent messages authenticated with that credential. Even considering that the credential expires after some time, the attacker could still wait for the victim to acquire a new secret and send new messages with it, which the attacker could also replay. There are things a server could do outside what the draft discusses to protect against replay attacks against short-term secrets, but requiring NONCE would probably be simplest. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Nov 20 13:41:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmE4o-0005jx-9X; Mon, 20 Nov 2006 13:41:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmE4n-0005jp-Gd; Mon, 20 Nov 2006 13:41:05 -0500 Received: from mx4-8.spamtrap.magma.ca ([209.217.78.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmE4m-0000Px-7C; Mon, 20 Nov 2006 13:41:05 -0500 Received: from mail2.magma.ca (mail2.internal.magma.ca [10.0.10.12]) by mx4-8.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id kAKIf3vt005325; Mon, 20 Nov 2006 13:41:03 -0500 Received: from [192.168.1.137] ([216.13.42.66]) (authenticated bits=0) by mail2.magma.ca (Magma's Mail Server) with ESMTP id kAKIf1ha026533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 Nov 2006 13:41:03 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <10912104-8C43-479F-BE6A-8EC2BD7C414E@magma.ca> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: behave@ietf.org, IETF MMUSIC WG From: Philip Matthews Date: Mon, 20 Nov 2006 13:41:14 -0500 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: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Subject: [BEHAVE] Looking for core reviewers for the ICE-related specifications X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Folks: There is a major effort on right now to get all the ICE-related documents to RFC status. We are planning to issue WGLCs for most of these documents over the next few weeks, with the hope of getting them all submitted to the IESG by mid-January. There are 6 document which we are classifying as ICE-related: 1. draft-ietf-behave-3489bis (STUN) 2. draft-ietf-behave-turn (TURN) (depends on 1) 3. draft-ietf-mmusic-ice (ICE) (depends on 1 and 2 and 5) 4. draft-ietf-mmusic-ice-passive?(ICE-PASSIVE - new document) (depends on 3) 5. draft-ietf-sip-ice-option-tag (ICE-OPTION-TAG - new document) (depends on 3) 6. draft-ietf-mmusic-ice-tcp (ICE-TCP) (depends on 3) As you may be aware, STUN is currently in WGLC, and the other documents will enter WGLC shortly in their respective working groups. I am currently looking for people who are willing to be on what I am calling the "core review team" -- that is, people willing to review all 6 documents. These people would comment not only on the individual documents, but also on their interrelationships. Right now, the core review team consists of the following people: Bruce Lowecamp Derek MacDonald Rohan Mahy Philip Matthews Dan Wing If you are interested in being on this team, or would like more information, please let me know. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Nov 20 15:03:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmFMC-0005Jb-TG; Mon, 20 Nov 2006 15:03:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmFMB-0005JV-Hn for behave@ietf.org; Mon, 20 Nov 2006 15:03:07 -0500 Received: from mx2-2.spamtrap.magma.ca ([209.217.78.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmFMA-0002xs-8h for behave@ietf.org; Mon, 20 Nov 2006 15:03:07 -0500 Received: from mail2.magma.ca (mail2.internal.magma.ca [10.0.10.12]) by mx2-2.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id kAKK35RR027832 for ; Mon, 20 Nov 2006 15:03:05 -0500 Received: from [192.168.1.137] ([216.13.42.66]) (authenticated bits=0) by mail2.magma.ca (Magma's Mail Server) with ESMTP id kAKK34dU008461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 20 Nov 2006 15:03:05 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: behave@ietf.org From: Philip Matthews Date: Mon, 20 Nov 2006 15:03:15 -0500 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: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [BEHAVE] STUNbis WGLC comments - expect delays X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Folks: Jonathan is (hopefully!) very busy trying to make a deadline of next Monday on producing some other ICE-related documents, Dan is away right now, and others of us are busy reviewing the document, so don't be surprised if your posts on STUNbis don't elicit any immediate response. Just be patent and keep those comments coming! If issues come up, then there are plans to have a open conference call to discuss the document near the end of the WGLC period. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Nov 21 15:33:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmcIU-00017H-9v; Tue, 21 Nov 2006 15:32:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmcIT-000177-BZ for behave@ietf.org; Tue, 21 Nov 2006 15:32:49 -0500 Received: from mx5-6.spamtrap.magma.ca ([209.217.78.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmcIS-0001Wu-3Q for behave@ietf.org; Tue, 21 Nov 2006 15:32:49 -0500 Received: from mail4.magma.ca (mail4.internal.magma.ca [10.0.10.14]) by mx5-6.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id kALKWhUF012916; Tue, 21 Nov 2006 15:32:43 -0500 Received: from [64.26.165.164] (ottawa-dial-64-26-165-164.d-ip.magma.ca [64.26.165.164]) (authenticated bits=0) by mail4.magma.ca (Magma's Mail Server) with ESMTP id kALKWbLJ024867 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 21 Nov 2006 15:32:41 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <35534658-1E14-42DD-B99F-C85997285FE6@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Tue, 21 Nov 2006 15:32:51 -0500 To: Saikat Guha 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: 4adaf050708fb13be3316a9eee889caa Cc: behave@ietf.org Subject: [BEHAVE] Question on behave-tcp-02 and its implications for STUNbis 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 Section 4.1 of behave-tcp-02 talks about the definition of "endpoint independent mapping" in the case of TCP. The document says: Consider an internal IP address and TCP port (X:x) that initiates a TCP connection to an external (Y1:y1) tuple. Let the mapping allocated by the NAT for this connection be (X1':x1'). Shortly thereafter, the endpoint initiates a connection from the same (X:x) to an external address (Y2:y2) and gets the mapping (X2':x2') on the NAT. As per [BEHAVE-UDP], if (X1':x1') equals (X2':x2') for all values of (Y2:y2) then the NAT is defined to have "Endpoint Independent Mapping" behavior. Say (X:x) closes the first connection [to (Y1:y1)] before opening the second connection [to (Y2:y2)]? How long must the NAT remember the binding allocated to the first (now closed) connection in order to be considered to have "Endpoint Independent Mapping" when (X:x) opens the second connection? Or must (X;x) open the second connection before it closes the first connection? What do existing NATs do today? This question arose when I was considering the operation of STUNbis over TCP. STUNbis currently says: 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. If a client opens a TCP connection to a STUN server, sends a Binding Request and receives a response, can it close the connection immediately, or does it need to keep the connection open until it finishes establishing at least one TCP connection with a peer that uses the obtained mapped address? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Nov 21 15:50:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmcZH-0002C5-ST; Tue, 21 Nov 2006 15:50:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmcZ8-0002AC-0N; Tue, 21 Nov 2006 15:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmcZ7-0005pJ-LQ; Tue, 21 Nov 2006 15:50:01 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 9AC86328A7; Tue, 21 Nov 2006 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GmcZ7-0006U6-FQ; Tue, 21 Nov 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 21 Nov 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: behave@ietf.org Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Extension to the Simple Traversal Underneath NAT (STUN) Relay Usage for IPv4/IPv6 Transition Author(s) : G. Camarillo, O. Novo Filename : draft-ietf-behave-turn-ipv6-01.txt Pages : 9 Date : 2006-11-21 This document defines the REQUESTED-ADDRESS-TYPE attribute for the Simple Traversal Underneath NAT (STUN) Relay Usage, which allows a client to explicitly request the address type the STUN relay server will allocate (e.g., an IPv4-only node may request the STUN relay server to allocate an IPv6 address). Additionally, this document also defines a new error response code with the value 440 (Address Family not Supported). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-ipv6-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-turn-ipv6-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-behave-turn-ipv6-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-11-21104912.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-turn-ipv6-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-turn-ipv6-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-21104912.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Tue Nov 21 15:59:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmci7-0004ht-H8; Tue, 21 Nov 2006 15:59:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmci6-0004fB-5Z for behave@ietf.org; Tue, 21 Nov 2006 15:59:18 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gmchs-00045K-4u for behave@ietf.org; Tue, 21 Nov 2006 15:59:18 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 21 Nov 2006 12:57:11 -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 kALKvBl4031912; Tue, 21 Nov 2006 12:57:11 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kALKuxOb020963; Tue, 21 Nov 2006 12:57:11 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 12:57:08 -0800 Received: from [10.32.241.152] ([10.32.241.152]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 12:57:07 -0800 Message-ID: <45636822.8010103@cisco.com> Date: Tue, 21 Nov 2006 15:57:06 -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: Kevin Johns Subject: Re: [BEHAVE] review of rfc3489bis-05 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Nov 2006 20:57:07.0960 (UTC) FILETIME=[9B518F80:01C70DAF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1541; t=1164142631; x=1165006631; c=relaxed/simple; s=sjdkim5002; 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]=20review=20of=20rfc3489bis-05 |Sender:=20; bh=bpldQa+WLgroaMsxiM6/Z98XWrilk8LnImzvINYJK74=; b=FykQBff/w0zs0XvLf6nNwIczkdX7MzhO5X9e1cqQROrtQIus+ZT46MPBYgM7cBmcmDe60xlu 4zLEypZ5lvRM7j36B0SYgINxVGULpvoCuyma6lxhTzFgzM1JvCA7BYzH; Authentication-Results: sj-dkim-5; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 inline. Kevin Johns wrote: > Bruce, > > Thanks for the response. > > If folks are ok with the idea that the transaction ID number space is > sufficiently large that collisions are not an issue, then I guess I can > go along with that given that they are suppose to be random. That was the intent. This is just like how, for example, the call-id works in SIP. With 96 bits of transaction ID, if you assume that a server handles 10,000 transactions per second, and worries about collision within a window of 20 seconds, the probability of collision is roughly 2^-61, which is more than good enough. > > As for indications, I might be missing something here but given their > definition I do not see why a transaction ID is needed. There is nothing > to correlate the indication with and there is no way to have a duplicate > or re-transmission per the text. This seems to be adding additional > complexity with no usage by the protocol. Its probably not needed for functional purposes. But its useful for diagnostics and logs for sure, and it also allows for uniform message formats for transactions and indications, which I like. Certainly, it does no harm. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Nov 21 15:59:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmcif-00052n-0i; Tue, 21 Nov 2006 15:59:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmcie-00052c-Dj for behave@ietf.org; Tue, 21 Nov 2006 15:59:52 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmcib-0000pC-Fa for behave@ietf.org; Tue, 21 Nov 2006 15:59:52 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 21 Nov 2006 12:59:49 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id kALKxmT7019835; Tue, 21 Nov 2006 12:59:48 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kALKxeiv017880; Tue, 21 Nov 2006 12:59:48 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 12:59:45 -0800 Received: from [10.32.241.152] ([10.32.241.152]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 12:59:44 -0800 Message-ID: <456368BF.2070003@cisco.com> Date: Tue, 21 Nov 2006 15:59:43 -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: Kevin Johns Subject: Re: [BEHAVE] STUN message type field References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Nov 2006 20:59:44.0853 (UTC) FILETIME=[F8D58850:01C70DAF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2208; t=1164142788; x=1165006788; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20STUN=20message=20type=20field |Sender:=20; bh=hmg2/QDzMJ8SajjgEY7Hm0vpDolCCwunHGLZTJwsMAM=; b=mrBo00dAjoiaAxLZPCVJOsDQ3lDjJ6qdNO2Nf6CbwKhwb45hL6GFHtEHcgRHBv28sq7wnl5Z vggKcJDrwHffBY30dT9C8FnXTlXrrBm/nOzaEkjGvzTDgasEHGTjY1rF; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 Yes, the duplicate M2 is a bug and will be fixed in the revision. The reason for the odd formatting is for backwards compatibility with RFC3489 values, and we did agree that I'd add some text to that effect. -Jonathan R. Kevin Johns wrote: > Ok, I can see that now looking at RFC 3489, a bit of text explaining > this might be helpful, but not necessary. > > I still think the two occurrences of M2 is an error and it should > actually be M1 and M2: > > 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| | | | | | | | | | | | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ^^ > > Kevin > > -----Original Message----- > From: Marc Petit-Huguenin [mailto:petithug@acm.org] > Sent: Thursday, November 16, 2006 6:10 PM > To: Kevin Johns > Cc: behave@ietf.org > Subject: Re: [BEHAVE] STUN message type field > > Kevin Johns wrote: > >>Hi, >> >>In looking at the STUN header, I am a bit confused by the STUN message > > >>type field. There are two M2 entries (should one be a M1?) and there >>is a C0 and C1 intermixed. I was wondering why the field is formatted >>this way, it seems one would want to group common field together (i.e. > > >>C0 and >>C1 would be next to each other) rather then spread them about? > > > This is for compability with RFC 3489. If I remember well, it was > decided in the BEHAVE session to add some text to explain that. > > > > _______________________________________________ > 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 Nov 21 16:30:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmdCE-0006QC-P4; Tue, 21 Nov 2006 16:30:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmcht-0003Hk-HE for behave@ietf.org; Tue, 21 Nov 2006 15:59:05 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmccy-0007B4-O6 for behave@ietf.org; Tue, 21 Nov 2006 15:54:08 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 21 Nov 2006 12:54:00 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kALKs0Qf002595; Tue, 21 Nov 2006 12:54:00 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kALKs0W4024131; Tue, 21 Nov 2006 12:54:00 -0800 (PST) Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 12:53:59 -0800 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] Question on behave-tcp-02 and its implications for STUNbis Date: Tue, 21 Nov 2006 12:53:58 -0800 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB02A2E1DD@xmb-sjc-236.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Question on behave-tcp-02 and its implications for STUNbis Thread-Index: AccNrG/nJev0cxChQ8GVO9tAMeTINQAAbuDA From: "Senthil Sivakumar \(ssenthil\)" To: "Philip Matthews" , "Saikat Guha" X-OriginalArrivalTime: 21 Nov 2006 20:53:59.0747 (UTC) FILETIME=[2B228930:01C70DAF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2878; t=1164142440; x=1165006440; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ssenthil@cisco.com; z=From:=20=22Senthil=20Sivakumar=20\(ssenthil\)=22=20 |Subject:=20RE=3A=20[BEHAVE]=20Question=20on=20behave-tcp-02=20and=20its= 20implications=20for=20STUNbis |Sender:=20; bh=DSH9g7wicAoTxC1uE7ZUVwRrFHw2pLjERLNBUTpNxQ0=; b=WO/pxW8M4olDrR+aoLFWr/vAfk2lDSp1hAVHHh1PIQKb1teMAtnYsTlD44amyOPUOKDwWmPI xYqe+7T+T7dlx93J5DH9/yNlL5H00Owgrf4FVCEPJiANI4jHCOVAH1lf; Authentication-Results: sj-dkim-3; header.From=ssenthil@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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 =20 > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 > Sent: Tuesday, November 21, 2006 3:33 PM > To: Saikat Guha > Cc: behave@ietf.org > Subject: [BEHAVE] Question on behave-tcp-02 and its=20 > implications for STUNbis >=20 > Section 4.1 of behave-tcp-02 talks about the definition of=20 > "endpoint independent mapping" in the case of TCP. > The document says: > Consider an internal IP address and TCP port (X:x)=20 > that initiates a > TCP connection to an external (Y1:y1) tuple. Let the mapping > allocated by the NAT for this connection be (X1':x1'). Shortly > thereafter, the endpoint initiates a connection from the same > (X:x) > to an external address (Y2:y2) and gets the mapping=20 > (X2':x2') on the > NAT. As per [BEHAVE-UDP], if (X1':x1') equals=20 > (X2':x2') for all > values of (Y2:y2) then the NAT is defined to have "Endpoint > Independent Mapping" behavior. >=20 > Say (X:x) closes the first connection [to (Y1:y1)] before=20 > opening the second connection [to (Y2:y2)]? > How long must the NAT remember the binding allocated to the=20 > first (now closed) connection in order to be considered to=20 > have "Endpoint Independent Mapping" > when (X:x) opens the second connection? > Or must (X;x) open the second connection before it closes the=20 > first connection? > What do existing NATs do today? The endpoint independent mapping applies only when you have an active connection from the same address & port. The time that a NAT should remember the mapping info is not defined, as far as I recall. But in case of TCP, I would think the FIN/RST would cause the mapping to be removed, probably immediately. Existing NATs that I know of remove the binding immediately or after a configured timeout to wait after a fin/rst. >=20 > This question arose when I was considering the operation of=20 > STUNbis over TCP. > STUNbis currently says: > When using TCP or TLS over TCP, the client SHOULD > close the connection as soon as it has received the=20 > STUN Response, if > it has no plans to send further requests. > If a client opens a TCP connection to a STUN server, sends a=20 > Binding Request and receives a response, can it close the=20 > connection immediately, or does it need to keep the=20 > connection open until it finishes establishing at least one=20 > TCP connection with a peer that uses the obtained mapped address? >=20 If you want an endpoint independent mapping behavior, you would have to open the new connection and remove the existing connection. Senthil > - Philip >=20 >=20 >=20 >=20 >=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 Tue Nov 21 17:18:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmdwV-0003Vp-Ox; Tue, 21 Nov 2006 17:18:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmdwU-0003Sc-80 for behave@ietf.org; Tue, 21 Nov 2006 17:18:14 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmdwR-0000NQ-Qg for behave@ietf.org; Tue, 21 Nov 2006 17:18:14 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 21 Nov 2006 14:18:10 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kALMIAG7002912; Tue, 21 Nov 2006 14:18:10 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kALMIAin015019; Tue, 21 Nov 2006 14:18:10 -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); Tue, 21 Nov 2006 14:18:10 -0800 Received: from [10.32.241.152] ([10.32.241.152]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 14:18:09 -0800 Message-ID: <45637B1F.4000101@cisco.com> Date: Tue, 21 Nov 2006 17:18:07 -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: Brian Hibbard Subject: Re: [BEHAVE] use of NONCE in draft-ietf-behave-rfc3489bis-05 References: <455F59E5.5000308@estacado.net> In-Reply-To: <455F59E5.5000308@estacado.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Nov 2006 22:18:09.0784 (UTC) FILETIME=[ED310780:01C70DBA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3204; t=1164147490; x=1165011490; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20use=20of=20NONCE=20in=20draft-ietf-behave- rfc3489bis-05 |Sender:=20; bh=0SogSMmlvF37TE6i+kgW7vkHzjysjUpIuIS8oxa8kWs=; b=ihdoTSCJBW3GxsLI2oczMbTBxO6zUm5yqX1dc24GLWvPi2gEgq5LMrWInfc6CuEkuA/VhwlK 36NKHudAYRR0iGvQGR2TDQdE90vN9Ue4ngNT1f/DuczGOFlHc9Rkaz69; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 We can't require nonces, since this would basically kill the primary usage of short term credentials these days - ICE itself. Running a challenge response on every ICE connectivity check would double the network traffic for it and double the ICE setup delays. In the case of ICE in particular, the challenge won't add any security benefits. The security considerations section walks through this. Replay attacks don't work because of the reverse connectivity check that takes place. Since the transaction ID changes, the attacker could not respond to the reverse connectivity check without the shared secret, and thus any IP address suggested by the attacker will fail validation. So, I think it is still MAY, but perhaps a few more words are needed to clarify that usages should carefully consider replay attacks if not using a nonce. -Jonathan R. Brian Hibbard wrote: > Use of NONCE is mandatory with long-term credentials, but not with > short-term credentials, where it's use is optional. From sec 9.1.1 > > 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). > > Unless I'm missing something, it seems to me it would be better if the > server SHOULD or MUST use NONCE for short-term secrets as well. > > If I understand properly, the reasoning behind not using NONCE with > short-term secrets is that their validity is already constrained > temporally by being short-term and this provides adequate protection > from password cracking. > > However, I don't see how that would stop an attacker who is capable of > mounting a replay attack using requests (especially STUN Relay Allocate > Requests) that are authenticated with a short-term secret. > MESSAGE-INTEGRITY doesn't include any fields from IP, TCP, or UDP. > Also, there is verbage discussing how the short-term secret might be > formulated in the server that suggests using the sender's IP, but there > is nothing that suggests that the server validate the username/password > using that same mechanism (which would be cumbersome) for all subsequent > messages authenticated with that credential. Even considering that the > credential expires after some time, the attacker could still wait for > the victim to acquire a new secret and send new messages with it, which > the attacker could also replay. > > There are things a server could do outside what the draft discusses to > protect against replay attacks against short-term secrets, but requiring > NONCE would probably be simplest. > > > _______________________________________________ > 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 Nov 21 17:23:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gme17-0007Hj-SE; Tue, 21 Nov 2006 17:23:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gme16-0007HV-1u for behave@ietf.org; Tue, 21 Nov 2006 17:23:00 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gme0r-00021Y-5T for behave@ietf.org; Tue, 21 Nov 2006 17:23:00 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 21 Nov 2006 14:22:44 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kALMMiuw011621; Tue, 21 Nov 2006 14:22:44 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kALMMiio029684; Tue, 21 Nov 2006 14:22:44 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 14:22:44 -0800 Received: from [10.32.241.152] ([10.32.241.152]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 14:22:43 -0800 Message-ID: <45637C31.6090203@cisco.com> Date: Tue, 21 Nov 2006 17:22:41 -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: "Senthil Sivakumar (ssenthil)" Subject: Re: [BEHAVE] Question on behave-tcp-02 and its implications for STUNbis References: <85B2F271FDF6B949B3672BA5A7BB62FB02A2E1DD@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB02A2E1DD@xmb-sjc-236.amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Nov 2006 22:22:43.0561 (UTC) FILETIME=[90601590:01C70DBB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3726; t=1164147764; x=1165011764; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20Question=20on=20behave-tcp-02=20and=20its= 20implications=20for=09STUNbis |Sender:=20; bh=xROEfU8kvuVwpYi0P7e79VVWTWsgjtXsF+yhw4z+9as=; b=az8/4ehQ2kqXZ+LJGiO0LM7KApp0gMjeO6tZTWqoYFEhu5sy+mzvEqgWi0KUE/xSMntrJh4o 34gZ2JlpqmPUiwTXHJhLeDdPiAyVlzSEwbvf29zdtpICbCoFvLtnDXdZ; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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 Thanks for the clarification, Senthil. I think this does indicate that there is a bug in ice-tcp, which Philip has found. This is very subtle - good catch, Philip. I'll fix this in the next revision of ICE-tcp to say that the agent keeps the connections open until the ICE checks complete (keeps it simpler). -Jonathan R. Senthil Sivakumar (ssenthil) wrote: > > > >>-----Original Message----- >>From: Philip Matthews [mailto:philip_matthews@magma.ca] >>Sent: Tuesday, November 21, 2006 3:33 PM >>To: Saikat Guha >>Cc: behave@ietf.org >>Subject: [BEHAVE] Question on behave-tcp-02 and its >>implications for STUNbis >> >>Section 4.1 of behave-tcp-02 talks about the definition of >>"endpoint independent mapping" in the case of TCP. >>The document says: >> Consider an internal IP address and TCP port (X:x) >>that initiates a >> TCP connection to an external (Y1:y1) tuple. Let the mapping >> allocated by the NAT for this connection be (X1':x1'). Shortly >> thereafter, the endpoint initiates a connection from the same >>(X:x) >> to an external address (Y2:y2) and gets the mapping >>(X2':x2') on the >> NAT. As per [BEHAVE-UDP], if (X1':x1') equals >>(X2':x2') for all >> values of (Y2:y2) then the NAT is defined to have "Endpoint >> Independent Mapping" behavior. >> >>Say (X:x) closes the first connection [to (Y1:y1)] before >>opening the second connection [to (Y2:y2)]? >>How long must the NAT remember the binding allocated to the >>first (now closed) connection in order to be considered to >>have "Endpoint Independent Mapping" >>when (X:x) opens the second connection? >>Or must (X;x) open the second connection before it closes the >>first connection? >>What do existing NATs do today? > > > The endpoint independent mapping applies only when you have an active > connection from the same address & port. The time that a NAT should > remember the mapping info is not defined, as far as I recall. But in > case of TCP, I would think the FIN/RST would cause the mapping to be > removed, probably immediately. Existing NATs that I know of remove the > binding immediately or after a configured timeout to wait after a > fin/rst. > > >>This question arose when I was considering the operation of >>STUNbis over TCP. >>STUNbis currently says: >> 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. >>If a client opens a TCP connection to a STUN server, sends a >>Binding Request and receives a response, can it close the >>connection immediately, or does it need to keep the >>connection open until it finishes establishing at least one >>TCP connection with a peer that uses the obtained mapped address? >> > > > If you want an endpoint independent mapping behavior, you would have to > open the new connection and remove the existing connection. > > Senthil > >>- Philip >> >> >> >> >> >>_______________________________________________ >>Behave mailing list >>Behave@ietf.org >>https://www1.ietf.org/mailman/listinfo/behave >> > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > -- Jonathan D. Rosenberg, Ph.D. 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 Nov 21 17:40:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmeHO-0007mz-TY; Tue, 21 Nov 2006 17:39:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmeHN-0007l4-MB for behave@ietf.org; Tue, 21 Nov 2006 17:39:49 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmeHM-00060G-29 for behave@ietf.org; Tue, 21 Nov 2006 17:39:49 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 21 Nov 2006 14:39:46 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kALMdk87025198 for ; Tue, 21 Nov 2006 14:39:46 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kALMdjW4005145 for ; Tue, 21 Nov 2006 14:39:46 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 14:39:45 -0800 Received: from [10.32.241.152] ([10.32.241.152]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 14:39:45 -0800 Message-ID: <45638030.6080103@cisco.com> Date: Tue, 21 Nov 2006 17:39:44 -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: Jonathan Rosenberg Subject: Re: [BEHAVE] Question on behave-tcp-02 and its implications for STUNbis References: <85B2F271FDF6B949B3672BA5A7BB62FB02A2E1DD@xmb-sjc-236.amer.cisco.com> <45637C31.6090203@cisco.com> In-Reply-To: <45637C31.6090203@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Nov 2006 22:39:45.0574 (UTC) FILETIME=[F18AE460:01C70DBD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4771; t=1164148786; x=1165012786; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20Question=20on=20behave-tcp-02=20and=20its= 20implications=09for=09STUNbis |Sender:=20; bh=aKWjHnwijxyhUSXwdjU437jMuYF2dv2sevb4aiKGMxM=; b=alFMDAetX5EHgqH8wwKVu1Rikg6TzxmW4NuNH5PC0WqTPPdH2J4y0TzNDV0GguH0bZUJPHF1 3fNS3yDzslshG5UDMMCTTI5XZjpH1tpp2XIpx/NE8H/kgNoQzxhEkNgC; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 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 Sorry - this is not a bug in ICE-tcp but rfc3489bis. Indeed, the two contradict each other at the moment. ICE-tcp says to keep them open for a while, whereas its rfc3489bis that says to close them. I'd suggest the following words in RFC3489bis: 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 keep the connection open until it has no further requests to send, and has no plans to use any resources (such as a mapped address or relayed address ) learned though STUN requests sent over that connection. These words also account for relayed addresses; you cna't close the TCP connection if you are using the relayed address learned from the turn server, even if you never plan on sending another turn message. -Jonathan R. Jonathan Rosenberg wrote: > Thanks for the clarification, Senthil. I think this does indicate that > there is a bug in ice-tcp, which Philip has found. This is very subtle - > good catch, Philip. > > I'll fix this in the next revision of ICE-tcp to say that the agent > keeps the connections open until the ICE checks complete (keeps it > simpler). > > -Jonathan R. > > Senthil Sivakumar (ssenthil) wrote: > >> >> >> >>> -----Original Message----- >>> From: Philip Matthews [mailto:philip_matthews@magma.ca] Sent: >>> Tuesday, November 21, 2006 3:33 PM >>> To: Saikat Guha >>> Cc: behave@ietf.org >>> Subject: [BEHAVE] Question on behave-tcp-02 and its implications for >>> STUNbis >>> >>> Section 4.1 of behave-tcp-02 talks about the definition of "endpoint >>> independent mapping" in the case of TCP. >>> The document says: >>> Consider an internal IP address and TCP port (X:x) that >>> initiates a >>> TCP connection to an external (Y1:y1) tuple. Let the mapping >>> allocated by the NAT for this connection be (X1':x1'). Shortly >>> thereafter, the endpoint initiates a connection from the same >>> (X:x) >>> to an external address (Y2:y2) and gets the mapping (X2':x2') >>> on the >>> NAT. As per [BEHAVE-UDP], if (X1':x1') equals (X2':x2') for all >>> values of (Y2:y2) then the NAT is defined to have "Endpoint >>> Independent Mapping" behavior. >>> >>> Say (X:x) closes the first connection [to (Y1:y1)] before opening the >>> second connection [to (Y2:y2)]? >>> How long must the NAT remember the binding allocated to the first >>> (now closed) connection in order to be considered to have "Endpoint >>> Independent Mapping" >>> when (X:x) opens the second connection? >>> Or must (X;x) open the second connection before it closes the first >>> connection? >>> What do existing NATs do today? >> >> >> >> The endpoint independent mapping applies only when you have an active >> connection from the same address & port. The time that a NAT should >> remember the mapping info is not defined, as far as I recall. But in >> case of TCP, I would think the FIN/RST would cause the mapping to be >> removed, probably immediately. Existing NATs that I know of remove the >> binding immediately or after a configured timeout to wait after a >> fin/rst. >> >> >>> This question arose when I was considering the operation of STUNbis >>> over TCP. >>> STUNbis currently says: >>> 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. >>> If a client opens a TCP connection to a STUN server, sends a Binding >>> Request and receives a response, can it close the connection >>> immediately, or does it need to keep the connection open until it >>> finishes establishing at least one TCP connection with a peer that >>> uses the obtained mapped address? >>> >> >> >> If you want an endpoint independent mapping behavior, you would have to >> open the new connection and remove the existing connection. >> >> Senthil >> >>> - Philip >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www1.ietf.org/mailman/listinfo/behave >>> >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave >> > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Nov 22 17:49:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn0tP-0002L7-WB; Wed, 22 Nov 2006 17:48:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn0tO-0002L2-6v for behave@ietf.org; Wed, 22 Nov 2006 17:48:34 -0500 Received: from mx1-4.spamtrap.magma.ca ([209.217.78.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn0tM-0005En-UY for behave@ietf.org; Wed, 22 Nov 2006 17:48:34 -0500 Received: from mail4.magma.ca (mail4.internal.magma.ca [10.0.10.14]) by mx1-4.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id kAMMmN2Q008210; Wed, 22 Nov 2006 17:48:23 -0500 Received: from [206.191.1.12] (ottawa-dial-206-191-1-12.d-ip.magma.ca [206.191.1.12]) (authenticated bits=0) by mail4.magma.ca (Magma's Mail Server) with ESMTP id kAMMmAwx013184 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 22 Nov 2006 17:48:21 -0500 In-Reply-To: <45637C31.6090203@cisco.com> References: <85B2F271FDF6B949B3672BA5A7BB62FB02A2E1DD@xmb-sjc-236.amer.cisco.com> <45637C31.6090203@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] Question on behave-tcp-02 and its implications for STUNbis Date: Wed, 22 Nov 2006 14:42:17 -0500 To: Jonathan Rosenberg 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: 93238566e09e6e262849b4f805833007 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 21-Nov-06, at 17:22 , Jonathan Rosenberg wrote: > Thanks for the clarification, Senthil. I think this does indicate > that there is a bug in ice-tcp, which Philip has found. This is > very subtle - good catch, Philip. > > I'll fix this in the next revision of ICE-tcp to say that the agent > keeps the connections open until the ICE checks complete (keeps it > simpler). For STUN and ICE purposes, I agree that the best approach is to assume that the NAT forgets about the mapping as soon as the last connection using it is closed. There are a couple of sentences in STUNbis that should be updated to mention this too -- I will note these in my review comments. From behave-tcp purposes, we need to decide if a BEHAVE-compliant NAT should remember the mapping for some time after the last connection is closed. Personally, I don't see any good reason for a NAT to do this -- does anyone think this is necessary? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Nov 22 18:39:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn1fu-0007vp-Av; Wed, 22 Nov 2006 18:38:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn1ft-0007vj-6f for behave@ietf.org; Wed, 22 Nov 2006 18:38:41 -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 1Gn1fr-00028K-UX for behave@ietf.org; Wed, 22 Nov 2006 18:38:41 -0500 Received: from exchfe2.cs.cornell.edu ([128.84.97.28]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 18:38:34 -0500 Received: from [128.84.227.36] ([128.84.227.36]) by exchfe2.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 18:38:29 -0500 Subject: Re: [BEHAVE] Question on behave-tcp-02 and its implications for STUNbis From: Saikat Guha To: Philip Matthews In-Reply-To: References: <85B2F271FDF6B949B3672BA5A7BB62FB02A2E1DD@xmb-sjc-236.amer.cisco.com> <45637C31.6090203@cisco.com> Date: Wed, 22 Nov 2006 18:38:29 -0500 Message-Id: <1164238709.8592.12.camel@sioux.systems.cs.cornell.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.9.2 (2.9.2-2.fc7) X-OriginalArrivalTime: 22 Nov 2006 23:38:29.0972 (UTC) FILETIME=[50A91940:01C70E8F] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2090937998==" Errors-To: behave-bounces@ietf.org --===============2090937998== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-0htQY4fX5+UvkOO7kX74" --=-0htQY4fX5+UvkOO7kX74 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, 2006-11-22 at 14:42 -0500, Philip Matthews wrote: > From behave-tcp purposes, we need to decide if a BEHAVE-compliant =20 > NAT should remember the mapping for some time after the last =20 > connection is closed. Personally, I don't see any good reason for a =20 > NAT to do this -- does anyone think this is necessary? A NAT may wish to keep the connection state around after the connection is closed (and in TIMED_WAIT) for a number of reasons, which are elaborated in the section 5. Based on the test results (nutss.net/stunt-results.php column TIMED_WAIT), however, only about 50% of the NATs preserve the entry during TIMED_WAIT. We could clarify in section 4.1, that whether a NAT retains state after the connection is closed depends on the NAT's TIMED_WAIT behavior which is left unspecified as per current WG consensus. Thoughts? --=20 Saikat --=-0htQY4fX5+UvkOO7kX74 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) iD8DBQBFZN91nFltqi691/oRAgSTAJ4ozk2hwgx2/bYmpnchBI/ymxS8pwCeJ4C3 xDLGbimV2GNfE9reullpusI= =zpcG -----END PGP SIGNATURE----- --=-0htQY4fX5+UvkOO7kX74-- --===============2090937998== 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 --===============2090937998==-- From behave-bounces@ietf.org Wed Nov 22 23:24:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn68F-0001Q0-Pj; Wed, 22 Nov 2006 23:24:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn68E-0001Pp-GX for behave@ietf.org; Wed, 22 Nov 2006 23:24:14 -0500 Received: from mx2-3.spamtrap.magma.ca ([209.217.78.162]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn68D-0003cN-8r for behave@ietf.org; Wed, 22 Nov 2006 23:24:14 -0500 Received: from mail4.magma.ca (mail4.internal.magma.ca [10.0.10.14]) by mx2-3.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id kAN4OAjT028859; Wed, 22 Nov 2006 23:24:10 -0500 Received: from [206.191.1.3] (ottawa-dial-206-191-1-3.d-ip.magma.ca [206.191.1.3]) (authenticated bits=0) by mail4.magma.ca (Magma's Mail Server) with ESMTP id kAN4O0un028370 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 22 Nov 2006 23:24:08 -0500 In-Reply-To: <45636822.8010103@cisco.com> References: <45636822.8010103@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <25F15335-0DE0-4D07-828D-2D1909C569F1@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] review of rfc3489bis-05 Date: Wed, 22 Nov 2006 19:16:18 -0500 To: Jonathan Rosenberg 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: bb8f917bb6b8da28fc948aeffb74aa17 Cc: behave@ietf.org, Kevin Johns X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 21-Nov-06, at 15:57 , Jonathan Rosenberg wrote: > > Kevin Johns wrote: > >> As for indications, I might be missing something here but given their >> definition I do not see why a transaction ID is needed. There is >> nothing >> to correlate the indication with and there is no way to have a >> duplicate >> or re-transmission per the text. This seems to be adding additional >> complexity with no usage by the protocol. > > Its probably not needed for functional purposes. But its useful for > diagnostics and logs for sure, and it also allows for uniform > message formats for transactions and indications, which I like. > Certainly, it does no harm. > I was under the impression that the 96-bit transaction id is also used to prevent replay attacks when STUN was run over UDP. Am I mistaken? The document is rather vague about this. (Though how practical this is is a good question, since it requires an endpoint to remember all previously used transaction ids). If this is not true, and the only functional purpose is to help a client correlate a response with the request that generated it, then surely we could get away with a much smaller transaction id? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Nov 24 07:55:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnaZY-0005Sd-FH; Fri, 24 Nov 2006 07:54:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnaZX-0005SS-1d for behave@ietf.org; Fri, 24 Nov 2006 07:54:27 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnaZJ-0005sZ-Np for behave@ietf.org; Fri, 24 Nov 2006 07:54:27 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DF775C76; Fri, 24 Nov 2006 13:54:10 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Nov 2006 13:54:10 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Nov 2006 13:54:10 +0100 Message-ID: <4566EB72.2080004@ericsson.com> Date: Fri, 24 Nov 2006 13:54:10 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: behave@ietf.org, Jonathan Rosenberg Subject: Re: [BEHAVE] WGLC for draft-ietf-behave-rfc3489bis-05 starts now References: <04cc01c7078f$9dcffd80$c6f0200a@amer.cisco.com> In-Reply-To: <04cc01c7078f$9dcffd80$c6f0200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Nov 2006 12:54:10.0506 (UTC) FILETIME=[A2A63AA0:01C70FC7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 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 Hi, I have made a WGLC review of the document as an early AD review. I have found some 23 issues that needs to be straighten out. There are also some minor nits at the end of the message. 1. It is unclear what this document does to RFC 3489. I assume the purpose is to obsolete that document. If that is correct please do the following. Otherwise you will get comments from the IESG: A. add "Obsoletes: RFC 3489 (if approved)" to the header B. Add "This document obsoletes RFC 3489" to the abstract. C. In the introduction please tell that it obsoletes RFC 3489 and some high level points about the interoperability with old RFC 3489 implementations. D. Update the first sentence of section 16. 2. Section 2, first paragraph, page 6: "ALGs have serious limitations, including scalability, reliability, and speed of deploying new applications." I would include "security" in the above list. 3. Section 4, Transport Address definition: "Transport Address: The combination of an IP address and (UDP or TCP) port." As I see it STUN could be extended in the future to be used over DCCP and SCTP for some usages. Based on that I would like to change the definition to the following: Transport Address: The combination of an IP address and Transport protocol (UDP or TCP) port. 4. Section 5, Page 10: 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. I think the above description of what the server does is not "binding keepalive usage". To me it is in fact another usage of STUN that isn't really covered in the document. Even if one can use STUN for this particular method of achieving NAT-traversal, it is simply an alternative to inband signalling of the received information in binding discovery response. Thus I would like to have it in at least a separate paragraph. One should also discuss this security implications of doing this. To my knowledge it will be substantially less secure, as an attacker only need to spoof the source-address to achieve an attack on anyone. The topological restraints that having the binding discovery reply go back to the initiator and then having them signal the application server on where to send is more secure. 5. Section 6, page 13, Third paragraph: "Each STUN attribute ends on a 32 bit boundary:" I think there should be a SHALL here to make it clear that the alignment question is not up for discussion. "Each STUN attribute SHALL end on a 32 bit boundary:" 6. Section 8.3.2, Second paragraph: Then the client SHOULD check the response for a MESSAGE-INTEGRITY attribute. If not present, and the client placed a MESSAGE-INTEGRITY attribute into the associated request, it MUST discard the response. This processing has some implication on how a client can react to a particular kind of error message. Errors where the client included the message integrity but failed to include information that makes it possible for the server to include its own message integrity attribute. These will be dropped on the floor, and I think correctly so based on the security implications of doing otherwise. Fortunately I think the errors that will occur of this kind is implementation related rather than usage dependent. However I think there should be a warning about this in the text. Because the client will perform its 7 retransmission and then timeout due to this issue. 7. Section 9. How is the server allowed to handle the TCP connections and when may it close it down? I think there needs to be some rules here. Otherwise we will see different behavior from different servers. 8. Section 9.1.2, third paragraph: This maybe solved by a better introduction explaining what RFC 3489 implementations that are supported by server/clients according to this spec. However I think there is need to explain why the server should perform this check. 9. Section 10 and 12.2. Demultiplexing STUN and application data over TCP: I think there is to little written about how you use STUN over TCP. Especially about the issues with multiplexing STUN and application data in the keep-alive usage. As the STUN messages would need to be sent framed together with the application data in such a way that the STUN messages can be detected this is somewhat problematic and result in limited applicability. The usage over UDP or other packet based transport is much simpler. Therefore I think the applicability of STUN over TCP for the different usages needs to be expanded. In addition section 10 should be updated to discuss the specific TCP issues. Also the usage of "STUN packet" should be investigated. Because over TCP there are no way of ensuring that STUN is sent in a single STUN packet. 10. Section 11.1: The bits marked as "x" in Figure 6: These are either reserved or padding bits. Why not use normative language to indicate what they actually should be used. I am a great fan of using: "x: Reserved bits SHALL be set to 0 and SHALL be ignored on reception." The reason I like mandate this is that if one ever for some reasons like to use them then it would work to define all values except 0 to mean something. 11, Section 11.4, and 13.1 are the only two places the word "elements" are used to describe either server or clients and it is not defined in either place. I think this should be replaced with "server or client" 12. Section 11.6, 11.12: No where where I can find is it specified if the 300 response is required or not to contain an ALTERNATE-SERVER. I think this should be defined. And if it is allowed to not contain one, then the procedure on what to do should be defined. 13. Section 11.8: A. Are there any limitation on the length of the NONCE? It might be good to recommend and provide some limits to the size of the NONCE. B. I think the pointer into RFC 2617 should be a bit more specific. Point at least to the relevant sections. People shouldn't need to read the whole document to find the relevant parts. C. I also think the explanation on why the NONCE exist is quite thin. The best text in the whole document seems to be in section 9.1.1. Maybe add something about this in the overview section. 14. Section 11.10: This attribute MUST always be present in a Binding Response and may be used in other responses as well. This MUST is in contradiction with the backwards compatibility rules present in section 9.1.2 that allows RFC 3489 clients to get the response. I think the MUST can be removed here and the exception noted. 15. Section 11.10: "X-Port is the mapped port, exclusive or'd with most significant 16 bits of the magic cookie." Are there a reason why the most significant bits where chosen? Using the least significant would have saved a shift or using another constant in the XOR operation. 16. Section 12.2.7: " The client SHOULD NOT include a MESSAGE-INTEGRITY attribute unless prompted for one by the server, since authentication is not generally used with this STUN usage." I think the SHOULD NOT needs some qualifications. There should be some explanation when it is reasonable to break this SHOULD NOT. 17. Section 12.2.9: "Such a re-registration would not use the transport address obtained from the Binding Response. " I think there needs to be some explanation why this shouldn't be done. To me it seems obvious that some applications will use this short cut in performing the application layer update to get things working again. Thus opening the security vulnerability to spoofed requests. Thus I think more explanation on this and maybe even normative language at least RECOMMENDING against using the mapped address present in the request the server receives. 18. Section 12.3.1 " To thwart some on-path attacks described in Section 13, it is necessary for the STUN client and STUN server to integrity protect the information they exchange over UDP." "exchanges over UDP." Is this only a inconsistency that should be changed to "exchanged in STUN"? Or is it actually limited to UDP? 19. Section 12.3.7, second paragraph: Processing of the Shared Secret response follows that of any other STUN response. Note that clients MUST be prepared to be challenged for a long-term credential. And if challenged for long-term credential, what should it do. At least some hint on what it should do. I think this is covered in earlier section, but I think some reference to the correct procedure would be appropriate here. 20. Section 13. There I think is missing an important vulnerability in the description. The usage of response code 13 and ALTERNATE-SERVER attribute do open up for some nasty DDoS attack, either on any host or especially an STUN server. The attack can be done in at least two ways. First is to gain access over one or more STUN servers and then start redirecting some or all the users to the target of the attack. This can also be done by having the attacker deploy its own STUN server performing the redirect and get the DNS for some domain to point at them. This attack doesn't have a massive amplification factor, but some. For a non stun server being the target it will receive at least 7 packets per binding discovery redirected. If in addition the STUN client redirects all its request for a particular domain to the new server the attack will become stronger by the number of streams the client attempts to bind. I think the more interesting attack is the one that targets some other domains STUN servers. With this redirect attack one can clear load a STUN server beyond the point it can cope with. That way one can deny service for the applications that rely on the STUN server. Also by doing redirect of a small percentage of users from several other servers will result in them getting some service and not becoming to obvious that they take part in an attack. They may also get some service from the overloaded node. 21. Section 13.3: " Thirdly, to prevent the DNS attack of Section 13.2.2, Section 8.2 recommends that the client verify the credentials provided by the server with the name used in the DNS lookup." What about using DNS-SEC? 22. Section 13.4: What about identity leakage based on long term user names when using STUN. Maybe one of these issues that needs to pointed out. 23. Section 15: I think the port registration should be moved from you Jonathan personally to this document. NITS: A. Page 9, last paragraph: "... client wants to receive Real Time Transport Protocol (RTP [17]) traffic." Please use "-" between Real and Time B. Page 13, second paragraph: Missing space "... 2**967 - 1.AS with ..." C. Page 25, last line: ERROR-CORE -> ERROR-CODE D. Section 12.1: "The previous version of this specification, RFC3489 [15], described only this binding discovery usage." Didn't RFC 3489 describe a testing usage that is being deprecated? Maybe reformulate the sentence? E. Section 13.3, sixth paragraph: "The above three techniques ..." I can count to four things, but maybe not all can be counted as techniques. Still somewhat confusing. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Nov 26 14:45:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoPwM-0004So-BH; Sun, 26 Nov 2006 14:45:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoPwI-0004B3-W3 for behave@ietf.org; Sun, 26 Nov 2006 14:45:22 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoPwG-000886-5G for behave@ietf.org; Sun, 26 Nov 2006 14:45:22 -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 kAQJj8q18936; Sun, 26 Nov 2006 14:45:08 -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] WGLC for draft-ietf-behave-rfc3489bis-05 starts now Date: Sun, 26 Nov 2006 13:45:07 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E1EDB46@zrc2hxm0.corp.nortel.com> In-Reply-To: <4566EB72.2080004@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] WGLC for draft-ietf-behave-rfc3489bis-05 starts now thread-index: AccPyAZOqtVY4e8fTXyAMPh7LOl/HABv38bg From: "Francois Audet" To: , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Cc: 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 Jonathan, I have finished my review of draft-ietf-behave-3489bis-05. I have found no major issues. My comments are mostly minor or editorial. In the interest of time, since the comments are minor, I don't need you to=20 debate/discuss the points, unless there is a good reason. Feel free to ignore the=20 comments you don't agree with. - Title page Add "Obsoletes: RFC 3489", and "Category: Standards Track". As a side note, I find the title "Simple Traversal Underneath Network Address Translators (NAT)" kind of ridiculous. I know the intent is to match the acronymn STUN, but I'd rather have a more descriptive title, and keep the STUN name even if it doesn't match the title. 1. Applicability Statement This section is very difficult to read as the first section of this document. If legal, it would help the readability of the document if the Introduction was placed before the Applicability Statement. 4. Definitions Use "send STUN indications" for both the definition of STUN Client and STUN Server for consistency. In the description of "Reflexive Transport Address", change "binding allocated" to "mapped address allocated". Also, the definitions of "Reflexive Transport Address" and "Mapped Transport Address" are not very clear on what is the difference between those 2 terms. I'm not sure I understand why we need two terms for those as they appear to be the same thing. In Long Term credentials, replace "enrolles" with "enrolls". 5. Overview of Operation p. 8, end of second paragraph under Figure 1: add "Further indications may be defined in future specifications." p. 9, last paragraph: I'm not sure the phrase "and run by the service provider offering the application service (such as a SIP service provider)," is=20 useful or necessary. I would delete it. p. 10, first paragraph: STUN is really for the SDP, not for SIP. You could add "with an SDP Offer or Answer [19]" right after "200 OK response". p. 10, end of second paragraph: replace "SIP outbound" with "Client initiated Connections in SIP". 6. STUN Message Structure First sentence: remove "encoded using big endian (network ordered) binary" since it is redundant with the 3rd sentence. Figure 3: Second bit from the right should say "M1" instead of "M2". Paragraph under Figure 3: Instead of "0", "1", "2", "3", I would use "0b00", "0b01", "0b10", "0b11" respectively. Also, instead of "M11 through M0" and "C1 through C0", I would use "M11-M0" and "C1-C0". p. 13, first paragraph: change to "...as is done for example in [13] for=20 RTP and [18] for SIP." p. 13, second paragraph: change "1.As" to "1. As". p. 13, last paragraph: there is no indication of what the padding should be. All zeros? Does it matter? Please clarify. 8.1 Discovery p. 16, 4th paragraph: remove the following phrase as it is not necessary "as long as ports are not needed to differentiate the usage". 8.3.1 Formulating the Request Message 2nd paragraph: need to justify the "SHOULD add a MESSAGE-INTEGRITY and USERNAME". Why is it a SHOULD instead of a MUST? 8.3.2 Processing Responses 4th paragraph: I assume that 400 should not trigger a retry. Please clarify. p. 21, last paragraph. When 600 is received, how long does the client MUST NOT=20 retry? Forever? Probably not. Until reboot? A timer? I think we need some sort of rule for predictability. 9.1.2 Constructing the Response p.27, 3rd paragraph: explain why "its inclusion is RECOMMENDED" (as opposed to MUST). Perhaps a pointer to section 10 will be sufficient. I think this section needs to say that if a STUN server wants to deny STUN=20 requests, it uses 600. This is useful if a server does not wish to respond to=20 STUN (for example, for a SIP server to tell a client to stop sending STUN requests). The use of 600 is implied in section 11.6, but it would be good to spell it out in the procedural section. 10. Demultiplexing of STUN and Application Traffic 3rd paragraph: is there really cases where the 2 bits set to zero suffice??? If not, should we look at the magic cookie all the time (as a minimal=20 check)? I'm a little worried that people will use the current wording as justification for not looking at the magic cookie. 11.1 MAPPED-ADDRESS Last paragraph: clarify what is meant by "Clients MUST be prepared for this case.". I think what it needs to say is that if the client is dual-stack (i.e., support both IPv4 and IPv6), then it must be prepared to use IP addresses of whatever version. However, (and this is the important point), if it is NOT dual stack, it must be=20 prepared to process the response anyways. It probably needs to interpret an IP=20 address of a version it doesn't support as a failed STUN request (for the Binding usage), as it will not be able to use the address. 11.5, 11.10 and perhaps other places Make sure you are consistent with the use of the term XOR, x-ored, or'ed,=20 exclusively or'ed, X-Address and so forth. I'd recommend using XOR and XOR'ed everywhere. 11.6 ERROR-CODE p. 32, 2nd paragraph under the binary message description: explain what the padding is (e.g., all zeroes). 11.10 XOR-MAPPED-ADDRESS Last-paragraph: same comment as for 11.1 applies. 12.2.1 Applicability First paragraph implies that STUN can only be used for TCP and UDP. Alter the wording so that it is clear that other protocols might use STUN. Second paragraph: change "very-long lived" to "very long-lived". 12.2.3 Server Determination of Usage The second sentence is only true for SIP: other mechanism than a URI could be used for other protocols. I'd suggest removing the sentence altogether as it it belongs in sip-outbound instead. 12.3.9 Security Considerations for Short-Term Password p.44, second-to-last paragraph: change "memory or disk to store" to "storage". 13.1.1 Attack I: DDoS Against a Target p.46, first line: remove "or H.323". We have outgrown the habit of pointing to H.323, and if we did leave it in, then we'd have to add it to the Reference section anyways. Other possible attack for section 13: =09 Is there a risk that the ALTERNATE-SERVER may be used for a DDos attack? You cover the case where a legitimate STUN server is compromised (where this could happen), but there is the case of a non-legitimate STUN server that redirects improperly? This could happen if an evil STUN server was configured. (For example, what if larry.gloo.net got annoyed at everybody using it, and decided to redirect elsewhere?). 13.2.5 Approach V: Response Injection Plus DoS First line: replace "MitM" with "man-in-the-middle". 14.5 Issues with Existing NAPT Boxes Title: replace "NAPT" with "NAT" for consistency. 18.1 Normative References Replace [5] with rFC 4346 (i.e., TLS 1.1 instead of 1.0). 18.2 Informational References Update [18] to outbound-05. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Nov 27 08:51:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogsR-0005gt-62; Mon, 27 Nov 2006 08:50:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogsP-0005eR-T8 for behave@ietf.org; Mon, 27 Nov 2006 08:50:29 -0500 Received: from lambda.sipfoundry.org ([72.232.205.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GogsO-0001xH-Bd for behave@ietf.org; Mon, 27 Nov 2006 08:50:29 -0500 Received: from web33309.mail.mud.yahoo.com (web33309.mail.mud.yahoo.com [68.142.206.124]) by lambda.sipfoundry.org (8.13.8/8.13.8) with SMTP id kARDoOOr082874 for ; Mon, 27 Nov 2006 07:50:28 -0600 (CST) (envelope-from srisuresh@yahoo.com) Received: (qmail 12873 invoked by uid 60001); 27 Nov 2006 13:50:18 -0000 Message-ID: <20061127135018.12871.qmail@web33309.mail.mud.yahoo.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=APu3oUk5zDQr64QSAHNgOPAY9gI2cw/+ByHpfSk8K4ShQLbNTRNWRe80JUnIgTsl9OPo2/6Gb7PpUgfA3mzYQ6EcF2ekC/4IHskJ1KZu2Iwc2FMjwgvvfRj9maz62Q59oYVk/7VtVVwmmYrAJ3mJpTwdYQpB6zpoRTUsvE9y+Y4=; X-YMail-OSG: _t7UR_0VM1lUkzl3Ef8biHJrJBip0jwgxVKjfMrpkjNzB.Jn2I_eiqgD_dsyDWswlnKWuYBTEDj6yD0k5dNM9Xdhugw5Ni9NBuNCzfGfHcH5.0g5mWSEF_lmifDWB4mFUr_bqMLHYjE- Received: from [69.236.72.190] by web33309.mail.mud.yahoo.com via HTTP; Mon, 27 Nov 2006 05:50:18 PST Date: Mon, 27 Nov 2006 05:50:18 -0800 (PST) From: Pyda Srisuresh To: Jonathan Rosenberg , Behave In-Reply-To: <45503E18.3090705@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: Subject: [BEHAVE] Re: [Ietf-behave] comments on draft-ietf-behave-p2p-state X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Jonathan, Thank you for reviewing the document. Please find my responses inline. regards, suresh --- Jonathan Rosenberg wrote: > A high level comment - the document needs some additional context to > explain the role of the "server" in each of the different approaches, > there to facilitate rendezvous. > [suresh] Can you provide specifc examples of where the context is not adequate. Thanks. > Also, it would be great to include references or discussions of what > existing p2p applications are actually using each technique. > [suresh] Section 4 was meant precisely for that. If you are refering to specific things missing, do let us know. Thanks. > I'm glad to see the document use the new terms from the behave-udp > document. However I don't see why the document needs to restate and > re-explain those definitions in section 2. > [suresh] For the purposes of this document, we did not need all the granular definitions in the udp document. SO, we explain the terms used and state how they relate to the UDP terms. The explantions do not hurt the understanding. > The table of contents is missing page numbers. > > Section 3.2, you say that connection reversal only works if one side is > public and the other is behind a p2p-friendly nat. I don't see why the > latter is required; you are not relying on the Nat to allocate the same > ip address and port for this to work. > [suresh] You are right. However, if the NAT is not p2p-friendly, the server is unable to notify the public node which endpoint to expect the connection from for node-A. I will fix the text accordingly. > > the load on the initial introduction server S. The application does > > not need to attempt to detect the kind of NAT device it is behind, > > if any [STUN], since the procedure above will establish peer-to-peer > > I think you mean, "as in [STUN]" > [suresh]Right. I will fix that. > > by themselves, as well as their addresses as observed by S. The > > clients then simultaneously start sending packets to each other at > > each of the alternative addresses they know about, and use the first > > address that leads to successful communication. If the two clients > > are behind the same NAT, then the packets directed to their private > > addresses are likely to arrive first, resulting in a direct > > communication channel not involving the NAT. > > That need not be the case; packet loss and other things can make this > ordering reversed. > > Is "first come first served" really what is being used? > [suresh]Right. > > Dependent Mapping. For all of these reasons, it is NOT recommended > > that new applications implement this trick. This technique is > > mentioned here only for historical and informational purposes. > > I agree with the sentiment; but if this is an informational document, > making recommendations on techniques to use (or not) seems out of scope. > [suresh] Agreed. I will excise the recommendation text. Thank you for your comments. regards, suresh > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > _______________________________________________ > 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 Nov 27 09:29:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GohTk-0000F4-AI; Mon, 27 Nov 2006 09:29:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GohTX-00005R-7o for behave@ietf.org; Mon, 27 Nov 2006 09:28:51 -0500 Received: from mx1-4.spamtrap.magma.ca ([209.217.78.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GohQB-0006hI-MH for behave@ietf.org; Mon, 27 Nov 2006 09:25:24 -0500 Received: from mail1.magma.ca (mail1.internal.magma.ca [10.0.10.11]) by mx1-4.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id kAREPL1X021120; Mon, 27 Nov 2006 09:25:21 -0500 Received: from [192.168.1.65] ([216.13.42.66]) (authenticated bits=0) by mail1.magma.ca (Magma's Mail Server) with ESMTP id kAREOxZg010580 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 27 Nov 2006 09:25:21 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Philip Matthews Date: Mon, 27 Nov 2006 09:25:48 -0500 To: Jonathan Rosenberg 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: dd530fb5c702ad6eef32cae6dcb86145 Cc: behave@ietf.org Subject: [BEHAVE] Minor comments on draft-ietf-behave-3489bis-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 Jonathan: This e-mail contains comments on draft-ietf-behave-3489bis-05 which are quite minor in nature. Most of them can be considered to be editorial. I have placed my more interesting comments in a separate e-mail. To help you figure out what a comment refers to, I have inserted section headers to break up the comments. I also frequently quote from the text of the document. - Philip General Suggest adding a note that the discussion of TCP transport also pertains to TLS/TCP transport, except where explicitly noted. Title "Simple Traversal Underneath Network Address Translators (NAT) =20 (STUN)" The "(NAT) (STUN)" looks a bit awkward. Perhaps remove the "(NAT)"? Abstract "Simple Traversal Underneath NATs (STUN) is a lightweight protocol that serves as a tool for application protocols in dealing with NAT traversal. " Perhaps reword to something like: "Simple Traversal Underneath NATs (STUN) is a lightweight protocol which can be used by application protocols as one part of a NAT =20 traversal scheme." 1. Applicability Statement "In particular, the STUN binding usage by itself does not enable incoming UDP packets through NATs whose mapping property is address dependent or address and port dependent[14]. 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. Nor will it work when the STUN server is not in a common shared address realm ." First sentence, do you mean =93filtering=94 and not =93mapping=94? It = is =20 not clear to me exactly what message exchange you are envisioning. Second sentence: Depending on exactly what yoo mean, it WILL work if =20 the NAT supports hairpinning. General comment: I don=92t think that anyone not already intimately =20 familiar with NATs is going to really understand the problems you =20 describe here without pictures and more text than you are providing. =20 So it might be better to just state the big picture, and not go into =20 the details. This text, coming as it does right at the beginning of =20 the document, is rather intimidating to someone who is just getting =20 into NATs. Also, not stated in all the text here is that what doesn't =20= work is communication with a peer, as opposed to communication with =20 the STUN server. 4. Definitions Under "mapped address", suggest stating that this is an example of a =20 reflexive address. "... enrolles in a service and persists ..." s/enrolles/enrolls/ Add "RTO" and "RTT" to this section? 5. Overview of Operation "in which client" s/client/the client/ "There are no indications defined by this specification." Add "(but see [TURN])"? "...mapped address created by the NAT closest to the server. =20 The STUN server copies that source transport address into a STUN Binding Response and sends it back to the source transport address of the STUN request. Every type of NAT will route that response so =20 that it Middle sentence: Add =93and sends the binding response back to the =20 client=94? Also, use the term =93reflexive transport address" around here somewhere to help people understand this term? Under the discussion of the binding discover usage, suggest rewording the text to be a bit more general. For example: "The client can convey these transport addresses to a remote =20 application to allow that remote application to send messages to the client" and then "For example, these messages can be conveyed in the SDP body of a =20= SIP message ..." Similarly, the binding keepalive usage does not have to be as complex as you describe. It can simply be used by an endpoint to keep one or =20 more NAT bindings alive so that nodes on the public side of the NAT can use =20 it, either now or in the future. The details given here are a "for instance", =20 but do not define the usage. Also: is it really important to give so many SIP =20 details, since this is a general mechanism? "The STUN binding responses also inform the client that the server is still responsive[PM2] , and also inform the =20= client if its transport address towards the server have changed (its =20 reflexive transport address), Too many =93also=94s in this sentence? As noted in the new NAT discovery document, there are advantages if =20= the keepalives do not go all the way to the server. So reword to make =20= this part a =93may=94? "These two usages all utilize the same Binding Request message, and all require the same basic processing on the server." Remove =93all=94 (both occurrences)? "Some usages (such as the binding keepalive) require STUN =20 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 =20 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. " There is also a two-bit field of zeros at the start of the message. Need to be consistent in number throughout the last sentence. 6. STUN Message Structure "STUN messages are TLV (type-length-value) encoded using big endian (network ordered) binary. STUN messages are encoded using binary fields. All integer fields are carried in network byte order, that is, most significant byte (octet) first. This byte order is =20 commonly known as big-endian. The transmission order is described in =20 detail ..." These four sentences are somewhat repetitive. "All STUN messages consist of a 20 byte header:" s/consist/start/ "The most significant two bits of every STUN message are both =20 zeroes. This, combined with the magic cookie and the fingerprint attribute, aid[PM1] in differentiating STUN packets from other protocols =20 when STUN is multiplexed with other protocols on the same port." [PM1] s/aid/aids/ (since it needs to agree with "this") +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |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| | | | | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]The numbering here is the reverse of the standard IETF bit numbering, which increases from left to right (e.g., figure 2). In addition, M2 =20= is repeated twice. Also, I believe there was already an agreement to add an explanation =20 of why the C bits were located where they are. "The magic cookie additionally indicates the STUN client is =20 compliant with this specification." As opposed to the previous version of the specification. "A reponse to the STUN request, s/reponse/response/ "... 0 and 2**96 - 1.As with requests, ..." Need two spaces after the period. "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." Just to be clear, say padded at the end? 7.1. Request/Response Transactions "STUN clients are allowed to pipeline STUN requests. That is, a =20 STUN client MAY have multiple outstanding STUN requests with different transaction IDs and not wait for completion of a STUN request/ response exchange before sending another STUN request. Just to be clear, state that this multiple outstanding requests to =20 the same server. "When running STUN over UDP it is possible that the STUN request or its response might be dropped by the network." This statement is true for TCP as well. Suggest that what you want to =20= say is that, when running over UDP, STUN itself is responsible for handling retransmissions (or handling lost packets). Perhaps explain the difference between RTO and RTT? "Regardless of whether TCP or UDP was used for the transaction, if a failure occurs and the client has other servers it can reach (as a consequence of an SRV query which provides a multiplicity of STUN servers Section 8.1, for example), the client SHOULD create a new request, which is identical to the previous, but has a different transaction ID (and consequently a different MESSAGE INTEGRITY =20 and/or FINGERPRINT attribute." The last sentence seems to end too soon - what should the client do with this new request? Also, this discussion doesn't apply to the connectivity-check usage or the nat-keepalive usage (depending on how you define "server" in these cases). "Regardless of whether TCP or UDP was used for the indication, if a failure occurs (due to a fatal ICMP error or TCP error), and the client has other servers it can reach (as a consequence of an SRV query which provides a multiplicity of STUN servers Section 8.1, for example), the client SHOULD create a new indication, which is identical to the previous, but has a different transaction ID (and consequently a different MESSAGE INTEGRITY and/or FINGERPRINT attribute). Same comment as above about the last sentence. More generally, what usage does this make sense for? Surely we don't want to do this for a data-indication or send-indication? 8.1. Discovery "The mechanism for configuring the STUN client with the domain =20 name to look up is not in scope of this document." s/scope/the scope/ When talking about discovering STUN servers, it says "Different ports SHOULD be used for TCP and TCP/TLS, so that the server can determine =20 whether the first message it will receive after the TCP connection is =20= set up is a STUN message or a TLS message." Cannot this determination be made using the two zero bits and the =20 magic cookie? Isn't the real reason the fact that TLS is often built into the OS =20 layer, while STUN runs on top? And isn't this whole discussion really an =20 implementation detail so the "SHOULD" is not appropriate? Perhaps reword along the lines of "A server may wish to run TCP and TLS/TCP on different =20 ports, especially if TLS support is built into the OS layer while STUN is =20 implemented as a user application, because the OS layer will be confused if it receives STUN =20 messages when it is expecting the TLS handshake messages". 8.3.1. Formulating the Request Message "The client follows the syntax rules defined in Section 6 and the transmission rules of Section 7. The message class MUST be a request. The client creates a STUN message following the STUN message structure described in Section 6. The client SHOULD add a MESSAGE- INTEGRITY and USERNAME attribute to the Request message if the usage employs authentication. The specific credentials to use are ..." It is perhaps obvious, but the client often needs to add other =20 attributes beyond the authentication-related attributes. Suggest mentioning what other =20 attributes need to be added. 8.3.2. Processing Responses "...response to an oustanding request" s/oustanding/outstanding/ "... or it had included the NONCE but received a 438, it is a =20 request .." Add "(Stale Nonce)" since this has not been explained recently? "Responses containing unknown mandatory attributions ..." s/attributions/attributes/ (this typo is rather amusing!) "...the same server, identified by transport address Insert "as"? 8.4. Indication Transactions "This section applies to client and server behavior[PM1] for =20 sending an Indication message." Suggest rewording as "This section describes client behavior for sending an =20 indication message." since server behavior is described later. [This rewording assumes you are not making other changes that I have =20 suggested elsewhere.] 9. Server Behavior "As with clients, server behavior depends on whether it is a =20 request/ response transaction or indication." s/indication/indication transaction/ (for consistency). "If the request is a retransmission of a request for which the =20 server has already generated a response within the last 10 seconds, the server MUST retransmit the response. A server can do this =20 either by remembering the response it transmitted, or by re-processing the request and computing the response. The latter technique can =20 only be applied to requests which are idempotent and would result in =20 the same response for the same request. This is the case for the Binding Request, but not for the Shared Secret Request. Extensions to =20= STUN SHOULD state whether their request types have this property or =20= not." Doesn't this paragraph only apply to requests sent over UDP? And what does a server do if the request was received more than 10 =20 seconds ago? Ignore? Reply with a 600? Perhaps this should be covered as part of the enhanced description of =20= transaction id processing? "... consequence of authentication problems (error codes 401, =20 432, 434, 435, 430 and 436, and the REALM is present in the response ..." Missing=94)=94. "includes an ERROR-CORE attribute" s/CORE/CODE/ 9.1.2. Constructing the Response "The server MUST copy the transaction ID from the request to =20 the response." If you don't take my suggestion (made elsewhere) to move the backward =20= compatibility discussion into the usage to which it applies, then you need to note that an =20 "old-style" transaction id is 32 bits longer than the new, so this statement needs to be qualified. 10. Demultiplexing of STUN and Application Traffic "All STUN messages have the value 0x2112A442 as the second =20 32 bit word." Is it worthwhile inserting "consistent with this specification" after =20= "messages"? (Perhaps this is too cryptic and/or not helpful?) ".... If this probability is deemed sufficiently small for the application at hand =20 (for example, it is considered adequate for Voice over IP =20 applications) then any packet with this value in its second 32 bit word is processed as a STUN packet. Why the reference to VoIP? I thought that STUN did not collide with =20 RTP and SIP, so FINGERPRINT is not needed for demuxing in these cases? "Thus, if a packet appears to be a STUN message because it has =20= a value of 0x2112A442 in its second 32 bit word, a client or server =20 then assumes the message is a STUN message, and computes the value =20= for the fingerprint. It then looks for the FINGERPRINT attribute=20 [PM1] in the message, and ... " Actually, the order needs to be reversed. You have to look for the =20 FINGERPRINT attribute first, since the fingerprint is only over the message up to the FINGERPRINT =20 attribute. 11.1. MAPPED-ADDRESS "The port is a network byte ordered representation of the port =20= the request arrived from." Would it be clearer to state "the source port in the TCP or UDP =20 header of the message when it arrived."? "The first 8 bits of the MAPPED-ADDRESS are ignored for the =20 purposes of aligning parameters on natural 32 bit boundaries." Suggest rewording as "The first 8 bits of the MAPPED-ADDRESS are ignored when =20 received. They are present only for the purpose of aligning the attribute on a natural =20 32 bit boundary." "It is possible for an IPv4 host to receive a MAPPED-ADDRESS containing an IPv6 address, or for an IPv6 host to receive a =20= MAPPED- ADDRESS containing an IPv4 address. Clients MUST be =20 prepared for this case." Perhaps briefly explain why this can happen, and/or say a bit more? For example =93if the client doesn=92t like this, it should try a =20 different server=94? (This paragraph also appears in section 11.11, but perhaps you only need to say this once?) 11.3. PASSWORD "Note that, as described above, if the USERNAME is not a multiple of four bytes it is padded for encoding into the STUN message, s/USERNAME/PASSWORD/ 11.4. MESSAGE-INTEGRITY "With the exception of the FINGERPRINT attribute, which appears =20= after MESSAGE-INTEGRITY, elements MUST ignore all other attributes that follow MESSAGE-INTEGRITY." s/elements/endpoints/ ? Or however you are handling the client/=20 server terminology question. 11.5 FINGERPRINT "When present, the FINGERPRINT attribute MUST be the last attribute in the message." What error code is returned if there are attributes after the =20 FINGERPRINT attribute? Or are the attributes just ignored a la MESSAGE-INTEGRITY? 11.7. REALM Mention that this may be padded to a 32 bit boundary (like a USERNAME =20= or PASSWORD)? 11.10. XOR-MAPPED-ADDRESS "It provides the same information that would present in the MAPPED- ADDRESS attribute but because[PM1] the NAT's public IP address =20= is ..." Need a comma here. "This attribute MUST always be present in a Binding Response and =20= may be used in other responses as well." Section 9.1.2 implies that a server inserts just one of MAPPED-=20 ADDRESS or XOR-MAPPED-ADDRESS. 11.13. REFRESH-INTERVAL "...interval measured in millseconds." s/millseconds/milliseconds (if this section is not just removed) 12. STUN Usages "New STUN usages MUST describe their applicability, client discovery of the STUN server, how the server determines the usage, new =20 message types (requests or indications), new message attributes, new error response codes, and new client and server procedures." The wording here suggests that new STUN must define new message =20 attributes, when I think you mean that they must simply describe any new message =20 attributes they invent. 12.1. Binding Discovery "The previous version of this specification, RFC3489 [15], =20 described only this binding discovery usage." It also defined the short-term credentials usage. 12.1.1. Applicability "Binding discovery is used to learn reflexive addresses from =20 servers on the network, generally the public Internet." The last part of this sentence doesn't quite read right. "That is, it is used by a client to determine its dynamically-bound 'public' UDP =20 transport address that is assigned by a NAT between a STUN client and a =20 STUN server." Or TCP. More general comment. We know that the simplistic approach described in this section (i.e., determine a reflexive transport address and then =20 use it as your contact address) often doesn't work. So I suggest rewriting this =20= section to say that the Binding-Discovery usage is just used to determine one =20= or more reflexive transport addresses, which the application can then use in =20 whatever way it wishes (e.g., for ICE). I suggest mentioning that it can be =20 used to discover multiple reflexive transport addresses. I believe there are other documents that describe the problems with =20 the simplistic approach, if you feel you want to reference them. 12.1.2. Client Discovery of Server "Clients SHOULD be configured with a domain name for a STUN =20 server to use." s/for/of/ ? 12.1.7. Client Procedures As mentioned above, suggest rewriting this section to that the usage =20 is simply about getting one or more reflexive transport addresses. "...obtained is then using [PM1] in Binding Request messages." s/using/used/ 12.1.8. Server Procedures "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." Except if the binding request is set over TLS/TCP? 12.2. NAT Keepalives 12.2.1. Applicability This section is written with the viewpoint that a client is connected =20= to a server, and just the client sends keepalives. But ICE doesn't work this way. "Since the connection between the client and server is very long =20= lived..." In the previous paragraph, it was just "long-lived". "The client will periodically send a Binding Request ..." How often? Or is this left outside of the specification? Of course, it differs between TCP and UDP, and perhaps various other =20 factors. If you don't want to specify, then suggest at least saying that. "... server using the magic cookie and possibly FINGERPRINT." And the two initial zero bits. (Perhaps just reference the demux =20 section?). 12.2.3. Server Determination of Usage Suggest rewording this section to say that the two endpoints agree on =20= this usage using some mechanism outside this specification. For example, there =20 may be some application-layer messaging whereby they agree to use this =20 mechanism (e.g., sip-outbound or ICE). 12.2.7. Client Procedures "... the client SHOULD inform other applications" s/other/the remote/ ? Other might refer to applications on the =20 other host. 12.3. Short-Term Password 12.3.8. Server Procedures "Extremely high probability means that the likelihood of collision SHOULD be better than 1 in 2**64." s/better/ess than/ 12.3.9. Security Considerations for Short-Term Password "To prevent being swamped with traffic, a STUN server SHOULD =20 limit the number of simultaneous TLS connections it will hold open by =20 dropping an existing connection when a new connection request arrives (based on an Least Recently Used (LRU) policy, for example)." If the connection is also being used for binding requests, then this =20 will cause difficulties for the client, because the clients wants to keep these connections open until it can =20= use the learned reflexive transport address. Regarding the mechanism to construct the username and password. Is it worthwhile explaining why this works and how to check things? Not sure why you round the time to 20 minutes =96 it seems simpler to =20= use the exact time. That way, the server can refuse the username once 30 minutes has =20 expired. 13.1.3. Attack III: Assuming the Identity of a Client "the attacker themself." s/themself/itself/ 16. Changes Since RFC 3489 "...in this document" s/this/that/ (or perhaps just say "RFC 3489"). 18.2. Informational References Isn't Rohan now a co-author of the TURN document? _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Nov 27 09:29:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GohTk-0000FE-J5; Mon, 27 Nov 2006 09:29:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GohTX-00007q-Om for behave@ietf.org; Mon, 27 Nov 2006 09:28:51 -0500 Received: from mx2-3.spamtrap.magma.ca ([209.217.78.162]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GohPu-0006d9-He for behave@ietf.org; Mon, 27 Nov 2006 09:25:07 -0500 Received: from mail1.magma.ca (mail1.internal.magma.ca [10.0.10.11]) by mx2-3.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id kAREP1e3016090; Mon, 27 Nov 2006 09:25:01 -0500 Received: from [192.168.1.65] ([216.13.42.66]) (authenticated bits=0) by mail1.magma.ca (Magma's Mail Server) with ESMTP id kAREOxZf010580 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 27 Nov 2006 09:25:01 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Philip Matthews Date: Mon, 27 Nov 2006 09:25:26 -0500 To: Jonathan Rosenberg 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: d8921dd2ebcb07edebf7bfaf4808c2ad Cc: behave@ietf.org Subject: [BEHAVE] Comments on draft-ietf-behave-3489bis-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 Jonathan: Here are some comments on draft-ietf-behave-3489bis-05. Overall, I found this to be a very clear and well-written document. With a few exceptions (as noted below), I found everything to be very understandable. Below are a few comments that might be of general interest to the working group. These are a bit more significant that the more minor and editorial comments which I have placed in a separate e-mail. None of my comments, however, are particularly earth-shattering -- a reflection probably of how well-written and mature the document is. - Philip 1) Much of the document is written with the viewpoint that one =20 endpoint is always the client and sends requests and indications, and =20 the other endpoint is always the server and sends responses; furthermore, =20= the client is behind a NAT while the server typically is not (cf. =20 figure 2). However, it seems to me that the real protocol has evolved =20 beyond this view. Both ends can now send and receive requests and indications (e.g., ICE with the keepalive usage and connectivity-check usage, and TURN with the relay usage), and both ends can be behind NATs (ICE again). So perhaps the document should either: a) Drop the terms "client" and "server" and just talk about =20 "endpoints", OR b) Use the terms "client" and "server" only with respect to a particular transaction. If (b) is selected, then I suggest being careful to distinguish =20= this usage from the concept of "using DNS to find a STUN server". 2) Much of sections 8 "Client Behavior" and 9 "Server Behavior" =20 deals with authentication. There is very little discussion of the basic processing of a =20 received STUN message, and what little there is is scattered throughout the document. =20 In particular, there is very little discussion about checking the message =20 type, checking the magic cookie, the proper processing of transaction IDs, checking for =20 mandatory-to-include attributes (other than those associated with authentication, which is well =20= covered!), and how to handle situations like repeated attributes. 3) The document is split into client behavior in section 8 and server behavior in section 9. However, given that at least two usages require an endpoint to both send and receive requests and =20 indications, I suggest that a better organization might be: a) Sending a request b) Sending an indication c) Receiving a message which, after some common initial =20 processing, leads to: i) Receiving a request and sending a response ii) Receiving a response iii) Receiving an indication d) Locating a STUN endpoint using DNS This organization is much closer to the way an implementation =20 of STUN needs to be organized these days. It would also provide a =20 logical spot to discuss all the points mentioned in (2). 4) Given the recent discussion on the mailing list, I suggest it =20 would be especially good if the document said a bit more about choosing transaction ids, =20= and when they are required to be unique. For example, what determines a unique transaction: can one =20 simultaneously send a binding request to two different servers using the same =20 transaction id? (I think not, but the text is not clear). 6) It seems to me that the figure 5, which shows which attributes =20 appear in which message types, really needs to depend on the usage. Perhaps there should be a =20= separate table for each usage? For example, for the connectivity-check usage, the ALTERNATE-SERVER attribute makes no sense, and Binding Requests =20= must contain the PRIORITY attribute (as described in ICE). 7) It might be helpful if the document was a bit clearer on the =20 distinction in usage for "mandatory" and "optional" when discussing "mandatory/optional-to-=20 comprehend-when-received" vs. discussing "mandatory/optional-to-include-when-sending". For example, MESSAGE-INTEGRITY is always "mandatory-to-=20 comprehend-when-received", but is "optional-to-include-when-sending" in some usages. 8) As currently written, the document seems to suggest that the =20 backwards compatibility rules apply to all usages; specifically the rules for including the MAPPED-=20= ADDRESS attribute. However, I believe these rules only make sense for the binding-discovery usage. Perhaps a better organization would be to move all the =20 backward compatibility discussion out of the main text and place it under the usage where it applies? 9) I think it would be helpful if the introduction provided a high-=20 level description of the various authentication schemes and how they work. Not being familiar with these =20 schemes, I found the details in later sections very confusing, especially wrt. long-term authentication. 10) In section 5 and section 12.2, the document assumes that in the =20 NAT keepalive usage, the "server" learns a transport address of a "client" from =20 the source transport address of a application protocol message sent by the "client". This =20= is one way to do it, but ICE (for example) uses a different scheme. =20 Suggest generalizing the discussion. 11) "The value for RTO SHOULD be cached by an agent after the completion of the transaction, and used as the starting value for RTO =20 for the next transaction to the same host (based on equality of IP =20 address)." Could this give a problem with ICE? For example, say X and Y are =20= endpoints that both use the same (large) service provider, and that service provider =20 has a NAT N in front of its entire network. Then X and Y may appear to have the same IP =20 address to remote endpoint Z. Say Z first calls X and say some of the links between X and N are =20= slow. Then Z will learn and remember a large RTO to N's address. Shortly afterwards, Z calls =20 Y. Z will now use the large RTO, and this may have an affect on the set-up time for this second call. Could say that we don't care about this case. Alternatively, =20 could say that Z remembers the RTO or a transport address, not just an IP address. 12) What are the retransmission timers for TCP and how do they =20 compare with those STUN uses for UDP? Am I correct in saying that the STUN UDP =20 retransmissions intervals are shorter than those that TCP uses? 13) Are we going to get push-back from the security folk because we =20 are specifying MD5 for authentication? I have heard that the security folk want the IETF to =20 transition away from MD5 to more secure algorithms, due to recent cryptographic attacks on MD5. 14) The document states that usage of the FINGERPRINT attribute is =20 RECOMMENDED even when the initial two zero bits and the magic cookie are =20 sufficient for demultiplexing. Why is it RECOMMENDED? Why not just make this a MAY? (This =20 is repeated in various sections) 15) "When using TCP or TLS over TCP, the client SHOULD close the connection as soon as it has received the STUN =20= Response, if it has no plans to send further requests." As discussed on a different thread, I think the client =20 should keep this connection open until it has set up at least one other TCP connection that uses =20 this mapping. Otherwise, the mapping might be discarded immediately by the NAT. (Section 8.3.1 =20 and 8.4) 16) In section 8.3.2 Processing Responses, it says "Once the client has received a response to its request =20= that it did not discard, it MUST discard any further responses for =20= the same request." This could be read to imply that a client must remember all =20= the transaction ids it has ever used so that it can discard duplicate responses. Is this really =20 what is meant? 17) Section 8.3.2. says "For a 420 (Unknown Attribute) response code, the client SHOULD retry the request, this time omitting any =20 attributes listed in the UNKNOWN-ATTRIBUTES attribute of the response." and a bit later says "If the client receives a 432 (Missing Username) =20 response, and the client had omitted the USERNAME from the request but =20 included a MESSAGE-INTEGRITY, the client SHOULD retry the request =20= and include both MESSAGE-INTEGRITY and USERNAME." and later says "If the client receives a 433 (Use TLS) response, and =20 the request was a Shared Secret request which was not sent over TLS, =20 the client SHOULD retry the request, and MUST send it using TLS." How can any of these situations occur with properly =20 functioning clients and servers? The actions that lead to these errors all seem to violate =20 this specification. 18) Section 8.3.2 also says: "If the response is an Error Response, the client checks =20 the response code from the ERROR-CODE attribute of the response. For =20= a 400 (Bad Request) response code, the client SHOULD display the =20 reason phrase to the user. Why is this a "SHOULD"? Though it may be good advice, it =20 don't see how it is needed for interoperability. 19) Section 8.4 says "Indication messages cannot be challenged or rejected. =20= Consequently, they cannot be authenticated using long term =20 credentials." I don=92t understand this. If a client knows the USERNAME, =20 REALM, and password, why can=92t the long term credentials be used? (I suspect that I =20= don't understand how long-term credentials work). 20) Section 9.1.1 says "Any attributes that are known, but are not supposed to be present in a message (MAPPED-ADDRESS in a =20 request, for example) MUST be ignored." This is interesting. Unknown mandatory attributes cause an =20 error, but known but unexpected attributes are ignored. Shouldn't it be that =20 mandatory attributes must be expected, but optional attributes can be unexpected? 21) Section 9.1.2 says "Insertion of either XOR-MAPPED-ADDRESS or MAPPED-ADDRESS happens =20 regardless of the transport protocol used for the request." Why?? 3489 only ran over UDP. 22) UNKNOWN-ATTRIBUTES is the only attribute that doesn't use =20 padding, but rather says to repeat an attribute to pad to a 32 bit boundary. Could we =20 change this to be consistent? (Bruce Lowecamp already mentioned this, so I am seconding his =20 request). I don't think there are any backward compatibility concerns =20 with this, since properly implemented 3489 clients should never receive =20 this attribute, since a 3489bis server will always recognize all the =20 attributes they include. 23) As much as I like the proposal in draft-wing-behave-nat-control-=20 stun-usage, I'd like to suggest that the REFRESH-INTERVAL attribute NOT =20 be defined in this document, but be defined in draft-wing-.... There is no real =20 motivation in 3489bis for why this attribute exists, and I am concerned that =20 people will read this document and either be very confused or use this attribute in unexpected ways. 24) The section on the Binding Discovery usage says that the lookup =20 of the STUN server should be done using the DNS lookup procedure. This is =20 certainly one way to find a server, but I can think of others. Do you consider the DNS lookup =20 procedure to be an integral part of this usage, or is it still the Binding Discovery usage if =20= I use a different method to find the STUN server? (For example, a P2PSIP lookup mechanism that =20 finds peers willing to act as STUN servers). My suggestion is to remove the finding of the server from the =20= usage, and simply say that DNS lookup is one way to find a server. 25) Should we make provisions for private and experimental extensions =20= to STUN, as is often done with other protocols? This seems to be especially =20 important to do for attributes, since inventing new attributes seems to be fairly common. One possibility, based on what I have seen done for other =20 IETF protocols, is to allocate say 0x7fc0 =96 0x7fff for private mandatory attributes and =20 0xffc0 =96 0xffff for private optional attributes. This reserves 64 attributes for private use. To prevent =20 possible collisions, the first three bytes of an attribute in these ranges MUST contain an OUI. For messages, state that message type of the form =20 0b1111c11xcxxxx, where =93x=94 is 0 or 1, and =93c=94 is a class bit, are a private messages. Again, to =20= prevent collision, define a new attribute that holds an OUI, and state that this MUST be the first =20 attribute of a message whose type is in this range. This reserves 32 messages of each class for =20 private use. 26) Perhaps state that message type 0x000 and attribute type 0x0000 are reserved for an extension mechanism if ever required? 27) Section 16 states that this specification "updates" 3489. But don't we want this specification to "replace" or =20 "obsolete" 3489? "Updates" implies that someone needs to read both =20 specifications to implement the protocol. Is there something in 3489 that an an implementor still needs =20= to know? Can we not add a few extra sentences to make this document a =20 complete specification? _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Nov 27 17:44:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GopCQ-0007AK-7M; Mon, 27 Nov 2006 17:43:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GopCO-0007A9-Q6 for behave@ietf.org; Mon, 27 Nov 2006 17:43:40 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GopCM-0007Z6-En for behave@ietf.org; Mon, 27 Nov 2006 17:43:40 -0500 Received: from [192.168.0.4] (cpe-76-183-190-193.tx.res.rr.com [76.183.190.193]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id kARMhVha096721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Nov 2006 16:43:35 -0600 (CST) (envelope-from brian@estacado.net) Message-ID: <456B6A1A.2050401@estacado.net> Date: Mon, 27 Nov 2006 16:43:38 -0600 From: Brian Hibbard User-Agent: Thunderbird 1.5.0.7 (X11/20060922) MIME-Version: 1.0 To: behave@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [BEHAVE] Connection Status Indication content draft-ietf-behave-turn-02 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 From Section 9.4 Connection Status of the draft: 9.4 Connection Status Indication TODO: Expand this text. When the STUN relay to peer leg is TCP, the STUN relay client needs to be aware of the status of these TCP connections. The STUN relay extension defines application states for a TCP connection as follows: LISTEN, ESTABLISHED, CLOSED. Consequently, the STUN relay server sends a ConnectionState Indication for a binding whenever the relay connection status changes for one of the client's bindings except when the status changes due to a STUN relay client request (ex: an explicit binding close or deallocation). Some of the "Expand this text" needs to clarify the bits in the message. I can guess that it ought to contain a REMOTE-ADDRESS attribute, but how do we convey "LISTEN, ESTABLISHED, CLOSED"? Is this to be in a new attribute omitted in the current draft, or is there something that I missed that will serve that purpose? _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Nov 27 22:46:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gotuz-0000jY-AK; Mon, 27 Nov 2006 22:46:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gotux-0000jS-Qn for behave@ietf.org; Mon, 27 Nov 2006 22:45:59 -0500 Received: from www.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gotuw-00024p-H4 for behave@ietf.org; Mon, 27 Nov 2006 22:45:59 -0500 Received: by www.implementers.org (Postfix, from userid 1006) id D94363A02158; Mon, 27 Nov 2006 19:45:51 -0800 (PST) Received: from [10.1.28.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id 8A5DE3A02157; Mon, 27 Nov 2006 19:45:48 -0800 (PST) Message-ID: <456BB0EA.7090300@acm.org> Date: Mon, 27 Nov 2006 19:45:46 -0800 From: Marc Petit-Huguenin User-Agent: Icedove 1.5.0.8 (X11/20061124) MIME-Version: 1.0 To: jdrosen@cisco.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: behave@ietf.org Subject: [BEHAVE] Review of 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 In this review I tried to do not repeat what was already said in this previous reviews: http://www1.ietf.org/mail-archive/web/behave/current/msg01786.html http://www1.ietf.org/mail-archive/web/behave/current/msg01787.html http://www1.ietf.org/mail-archive/web/behave/current/msg01789.html http://www1.ietf.org/mail-archive/web/behave/current/msg01790.html 1. Section 5, paragraph 9: "...where it indicates where the client wants to receive Real Time Transport Protocol (RTP [17]) traffic." It cannot be a bad thing to add RTCP here. 2. Section 6, paragraph 11: The first and fifth sentences are identical. 3. Section 7.1, paragraph 4: "Retransmissions continue until a response is received..." I think it should be: "Retransmissions continue until a response is received and is not discarded..." 4. Section 7.2, paragraph 2: I am not sure if this is implementable with UDP, as the fatal ICMP error will only be received on the next system call. As indications are not retransmitted by STUN itself, the ICMP packet will never be received, and so the next server in the SRV RR will never be used. At least something should be said that this can work only if the indication is retransmitted at an higher level. 5. Section 8.1, paragraph 3: "The protocol is always "tls" for TLS over TCP." This seems redundant with the previous sentences. 6. Section 8.3.3: "If the STUN transaction times out without receipt of a response..." Should be: "If the STUN transaction times out without receipt of a non-discarded response..." 7. Section 9.1.1, paragraph 2: In my opinion, the text should clearly state that the server is always stateful if the request is not idempotent, and stateful or stateless at the choice of the implementor if the request is idempotent. 8. Section 12.1.1 paragraph 6 Section 12.1.7: "PDU" should be defined somewhere or replaced by another something else. -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [ RFC1855-compliant space for rent] Work: marc@8x8.com [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Nov 27 23:35:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gougy-0005Hl-WC; Mon, 27 Nov 2006 23:35:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gougy-0005Hd-F7 for behave@ietf.org; Mon, 27 Nov 2006 23:35:36 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gougx-0006QP-SB for behave@ietf.org; Mon, 27 Nov 2006 23:35:36 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAS4ZL320080; Mon, 27 Nov 2006 23:35:21 -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: Mon, 27 Nov 2006 22:35:21 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437111A4A4A7@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of rfc3489bis-05 up to section 8 Thread-Index: AccSpp0MczxJebBYSMWBXJW3IkSkog== From: "Brian Stucker" To: "Jonathan Rosenberg" , "Dan Wing" , X-Spam-Score: 2.1 (++) X-Scan-Signature: 1a2f5df4c6f30e0d5df43748fb095119 Cc: behave@ietf.org Subject: [BEHAVE] Review of rfc3489bis-05 up to section 8 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 guys, Mirroring Kevin's format for WGLC review comments, here's what I have up to section 8. I will make a very broad disclaimer that the comments may seem extensive (especially sections 6 and 7.1), but most of them are intended to be editorial. Now that the functionality has been settled, I have been going back through the document as a designer having an interoperability debate with another vendor. With that in mind, my comments are generally trying to make the text as easy to follow (it's already better than most specs I have read) and get rid of any points of future debate for the folks having to write code to the spec. Rather than give change bars on the larger chunks, I've offered replacement text. I didn't know of a more expedient way of doing this that was easily understandable, sorry for the length (hoping cut & paste into the draft will work here). A lot of it is simply moving existing text around to improve the flow. Unless otherwise noted ahead of the change offered, the edits are intended to be editorial in nature, and not to change the intent of the mechanism. I'll be working on getting through the rest of the document tomorrow. Sorry I couldn't get these to you earlier. Cheers, Brian --- General nit: Aren't the document references supposed to be of the format [RFC2988] instead of [8] now? Page 9, third paragraph:=20 NIT: "sent over TLS [5] over TCP." May wish to change to "sent via TLS[5] over TCP." NIT: capitalization of "Shared secret requests" inconsistient within the paragraph. Page 9, fourth paragraph:=20 NIT: Second sentence seems awkward, consider revising first two sentences to read: --- Begin replacement text --- There are many ways in which the basic mechanisms within the STUN protocol can be combined to accomplish a specific task. Such combinations of STUN protocol elements are known as a 'usage' within the protocol. --- End replacement text --- Page 10, first & second paragraph: The text in this paragraph seems to muddle SIP outbound concepts with STUN too heavily. The result is that the STUN mechanism being described is not as clearly called out as it could be. Consider clarifying to better call out the STUN mechanism being described: --- Begin replacement text --- The binding keep-alive usage also utilizes the STUN binding request message, but for a different purpose. Bindings allocated by a NAT typically expire if left dorment. When this happens, the client behind the NAT is no longer reachable by the server on the other side of the NAT. As a result, the client must generate periodic traffic to refresh the existing NAT binding. Rather than use potentially expensive application layer messages, a STUN binding request is sent by the client to the server. This binding request is sent to the exact same transport address used by the server for the application protocol (in the case of SIP, this would typically port 5060 or 5061). In addition to keeping the binding on the NAT alive, the STUN binding responses have additional effects: they inform the client that the server is still responsive, and if the client's transport address towards the server has changed (its reflexive transport address). If the client's transport address has changed, it may need additional application layer protocol messaging to update its transport address as seen by the server (i.e. the binding keep-alive usage has used by the SIP outbound mechanism [18]).=20 The binding discovery and keep-alive usages both utilize the same Binding Request message, and 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. --- End replacement text --- Page 10, last paragraph: NIT: Change "the magic cookie" to "a magic cookie". Page 11-13, Start of section 6 to first paragraph on page 13: This section seemed to jump around a lot and have duplicate information. I took the liberty to reorder the material and clarify the text in this section of the document to make it flow better, and be more easily understood by the reader. I modeled the flow of the text around the format of the message. Essentially, I got rid of any material that was repeated, and tried to lay out the material in the order in which it would appear in a STUN header such that if someone were looking at a STUN packet in a debugger, they could follow along in the text as they looked at the binary itself. Also reorganized some of the parenthetical information to help more clearly separate informative text from normative text. I've given my suggested updated text below. This would replace from the start of Section 6 down to the second paragraph on page 13 where we start talking about STUN attributes. --- Begin replacement text --- STUN messages are encoded using a TLV (type-length-value) format with network ordered binary fields (most significant byte or octet first, also commonly known as big-endian). The transmission order is described in detail in Appendix B of RFC791 [2]. Unless otherwise noted, numeric constants are given in decimal (base 10). [[ New Subsection: 6.1 STUN Message Header Format ]] All STUN messages start with a single, 20 byte, STUN header followed by a STUN payload. The STUN header contains a STUN message type, magic cookie, transaction ID, and total payload length.=20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0| STUN Message Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Transaction ID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Format of STUN Message Header The most significant two bits of every STUN message are both zeroes to aid in distinguishing STUN traffic from other protocols that may be multiplexed on the same port. The message type defines the message class (request, success response, failure response, or indication) and the message method (the primary function) of the STUN message. Although there are four message classes, there are only 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 message). Response classes are differentiated to aid in quickly processing the STUN message. 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|1|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. A number of mechanisms are provided to aid in differentiating STUN packets from other protocols that STUN may be multiplexed with on the same port. The magic cookie is a fixed value, 0x2112A442. In the previous version of this specification [15] this field was part of the transaction ID. This fixed value is used as part of the identification of a STUN message when STUN is multiplexed with other protocols on the same port, as is done for example in [13] and [18]. The magic cookie additionally indicates the STUN client is compliant with this specification. The magic cookie is present in all STUN messages -- requests, success responses, error responses and indications. In addition to the magic cookie and the leading zeroes in the STUN packet, there is also a fingerprint attribute that further aids in identifying the packet as a STUN packet. The transaction ID is a unique 96-bit identifier that is used for identify STUN transactions. =20 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. STUN Requests are sent reliably, and can run over UDP, TCP or TCP/TLS. When run over UDP, STUN requests are retransmitted in order to achieve reliability. Indication messages can be sent either from the client to the server, or from the server to the client using TCP or UDP. STUN itself does not provide reliability for these messages, though they will be delivered reliably when sent over TCP. The message length is the size, in bytes, of the message not including the 20 byte STUN header. [[ New subsection: 6.2 STUN Message Payload/Attributes ]] --- End replacement text --- 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? Assume it's the former and rephrased the text accordingly. Tried to make the timeout behavior more specific, giving exact formulas for the behavior and calling out the difference between STUN retransmission/timeout behavior and the familiar SIP retransmission/timeout behavior. Question: Is there a linger timer at the server during which time it is expected to cache the response to a particular request? For example, if a request is retransmitted via UDP, and the first response is dropped by the network, does the STUN server recalculate it's response or repeat the last response it sent to the earlier request (as in SIP)? The NAT binding could conceivably have changed between retransmissions due the NAT losing state (reboot, admin action) so that the reflexive transport address in the response is stale if the response is cached at the server to the earlier request.=20 Seems like caching of the STUN response at the server is safe; the binding could always be lost at the NAT regardless of the timing of STUN messages. Since detection of caching at the server would be undetectable to the client, and should be left as optional, nothing needs to be said in the text, does it? Fifth paragraph was unclear in original text. If STUN should not be retransmitted over TCP, then why wait until 7900ms, 1.6 seconds after the last retransmission, to timeout? I'm assuming you're waiting for TCP to timeout, but TCP may be using a different RTO value because it was calculated at a different point in time as the STUN RTO value. Assuming that we don't care about late responses due to TCP/STUN RTO value mismatch, right? We only care about the STUN application timer.=20 Result of this was to take a stab at rearranging the text a bit and making it a bit more explicit: --- Begin replacement text --- STUN clients MAY have multiple outstanding STUN requests with different transaction IDs and not wait for completion of a STUN request/response exchange before sending another STUN request to the same STUN server. [[ New section: 7.1.1 Reliability of STUN Requests ]] STUN uses the TCP retransmission timeout (RTO) value, described in RFC 2988 [8], for timing internal events regardless of the transport protocol used to send the request. This value is used as an input to the algorithms used to achieve reliability of STUN requests regardless of the transport protocol used. =20 Clients SHOULD use RFC 2988 [8] to compute an RTO value as an estimate of the round-trip-time, but with two exceptions. First, the initial value for RTO SHOULD be configurable (rather than the 3s recommended in RFC 2988). In fixed-line access links, an RTO value of 100ms is RECOMMENDED. Secondly, the RTO value MUST NOT be rounded up to the nearest second. Rather, a 1ms accuracy MUST be maintained. As with TCP, the usage of Karn's algorithm is RECOMMENDED. When Karn's algorithm is applied to STUN, this means that RTT estimates SHOULD NOT be computed from STUN transactions which result in the retransmission of a request. This value is used for both TCP and UDP operation. The RTO value SHOULD be cached by an agent after the completion of the transaction and SHOULD be used as the starting RTO value for the next transaction to the same host (based on equality of IP address). The value SHOULD be considered stale for new transactions and discarded after 10 minutes. [[ New section: 7.1.2 Sending STUN requests via UDP ]] When running STUN over UDP, it is possible that the STUN request or its response might be dropped by the network. Therefore, reliability of a STUN request sent over UDP is accomplished via explicit retransmissions of the request by the STUN application. Clients SHOULD retransmit the request up to 6 times. Each retransmission is sent, relative to the time the original request was sent, and is given by: Time to send next retransmission =3D t + (RTO * ((2 ^ n) - 1)) Where t is the time the original request was sent, n is the current retransmission counter value and RTO is given in milliseconds. Retransmissions continue until a response is received, or a total of 7 requests have been sent. =20 For example, if the STUN request was sent at time t, the retransmissions would be sent at: t + 100ms, t + 300ms, t + 700ms, t + 1500ms, t + 3100ms, and t + 6300ms.=20 This differs from retransmission timings for other protocols such as SIP where the interval between retransmissions is relative to the time the last retransmission was sent, not the original request. [[ New section: 7.1.3 Sending STUN requests via TCP ]] When running STUN over TCP, the STUN application SHOULD NOT retransmit STUN requests; TCP itself is responsible for ensuring reliable delivery. [[ New section: 7.1.4 STUN Transaction Timeout ]] The STUN application does not consider the transport protocol used to send a STUN request when calculating when a STUN transaction will timeout. The transaction timeout value is given by: Timeout of STUN transaction =3D t + ((2 ^ 6) -1) * RTO + 1600ms Where t is the time the original request was sent, and RTO is expressed in milliseconds, the client SHOULD consider the transaction to have failed regardless of the transport protocol used to send the STUN request. A STUN transaction over UDP is also considered failed if there has been a transport failure of some sort, such as a fatal ICMP error. Using our earlier example (with an RTO value of 100ms) gives an overall transaction timeout value of 7900ms after the original request was sent. The STUN client would consider the transaction to have timed out if no response had been received by that time if either UDP or TCP was used. Regardless of whether TCP or UDP was used for the transaction, if a failure occurs and the client has other servers it can reach (as a consequence of an SRV query which provides a multiplicity of STUN servers Section 8.1, for example), the client SHOULD create a new request, which is identical to the previous, but has a different transaction ID (and consequently a different MESSAGE INTEGRITY and/or FINGERPRINT attribute). --- End replacement text --- =3D=3D=3D _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Nov 28 12:11:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp6Tw-00074S-EC; Tue, 28 Nov 2006 12:10:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp6Tu-00073p-KB for behave@ietf.org; Tue, 28 Nov 2006 12:10:54 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp6Tr-0003pP-Ts for behave@ietf.org; Tue, 28 Nov 2006 12:10:54 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kASHAW929862; Tue, 28 Nov 2006 12:10:32 -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: Tue, 28 Nov 2006 11:10:30 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437111A4AA1F@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437111A4A4A7@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Review of rfc3489bis-05 up to section 8 Thread-Index: AccSpp0MczxJebBYSMWBXJW3IkSkogAaXIhg From: "Brian Stucker" To: "Jonathan Rosenberg" , "Dan Wing" , X-Spam-Score: 2.1 (++) X-Scan-Signature: 354d6627469d0be959806e15912c47f1 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 One other thought on section 7.1... The current text states that transport failures (ICMP errors) for UDP should be considered failures. What about other transport failures? Does a TCP connection reset constitute a failure of the STUN transaction? Regards, Brian=20 > -----Original Message----- > From: Stucker, Brian (RICH1:AR00)=20 > Sent: Monday, November 27, 2006 10:35 PM > To: Jonathan Rosenberg; Dan Wing; rohan@ekabal.com > Cc: behave@ietf.org > Subject: [BEHAVE] Review of rfc3489bis-05 up to section 8 >=20 > Hi guys, >=20 > Mirroring Kevin's format for WGLC review comments, here's=20 > what I have up to section 8. >=20 > I will make a very broad disclaimer that the comments may=20 > seem extensive (especially sections 6 and 7.1), but most of=20 > them are intended to be editorial. Now that the functionality=20 > has been settled, I have been going back through the document=20 > as a designer having an interoperability debate with another=20 > vendor. With that in mind, my comments are generally trying=20 > to make the text as easy to follow (it's already better than=20 > most specs I have read) and get rid of any points of future=20 > debate for the folks having to write code to the spec. >=20 > Rather than give change bars on the larger chunks, I've=20 > offered replacement text. I didn't know of a more expedient=20 > way of doing this that was easily understandable, sorry for=20 > the length (hoping cut & paste into the draft will work=20 > here). A lot of it is simply moving existing text around to=20 > improve the flow. Unless otherwise noted ahead of the change=20 > offered, the edits are intended to be editorial in nature,=20 > and not to change the intent of the mechanism. I'll be=20 > working on getting through the rest of the document tomorrow.=20 > Sorry I couldn't get these to you earlier. >=20 > Cheers, > Brian >=20 > --- >=20 > General nit: Aren't the document references supposed to be of=20 > the format [RFC2988] instead of [8] now? >=20 >=20 > Page 9, third paragraph:=20 > NIT: "sent over TLS [5] over TCP." May wish to=20 > change to "sent via TLS[5] over TCP." >=20 > NIT: capitalization of "Shared secret requests" > inconsistient within the paragraph. >=20 >=20 > Page 9, fourth paragraph:=20 > NIT: Second sentence seems awkward, consider=20 > revising first two sentences to read: >=20 > --- Begin replacement text --- >=20 > There are many ways in which the basic=20 > mechanisms within the STUN protocol can be combined to=20 > accomplish a specific task. Such combinations of STUN=20 > protocol elements are known as a 'usage' within the protocol. >=20 > --- End replacement text --- >=20 >=20 >=20 > Page 10, first & second paragraph: > The text in this paragraph seems to muddle SIP=20 > outbound concepts with STUN too heavily. The result is that=20 > the STUN mechanism being described is not as clearly called=20 > out as it could be. Consider clarifying to better call out=20 > the STUN mechanism being described: >=20 > --- Begin replacement text --- >=20 > The binding keep-alive usage also utilizes=20 > the STUN binding request message, but for a different=20 > purpose. Bindings allocated by a NAT typically expire if left=20 > dorment. When this happens, the client behind the NAT is no=20 > longer reachable by the server on the other side of the NAT.=20 > As a result, the client must generate periodic traffic to=20 > refresh the existing NAT binding. Rather than use potentially=20 > expensive application layer messages, a STUN binding request=20 > is sent by the client to the server. This binding request is=20 > sent to the exact same transport address used by the server=20 > for the application protocol (in the case of SIP, this would=20 > typically port 5060 or 5061). In addition to keeping the=20 > binding on the NAT alive, the STUN binding responses have additional > effects: they inform the client that the server is still=20 > responsive, and if the client's transport address towards the=20 > server has changed (its reflexive transport address). If the=20 > client's transport address has changed, it may need=20 > additional application layer protocol messaging to update its=20 > transport address as seen by the server (i.e. the binding=20 > keep-alive usage has used by the SIP outbound mechanism [18]).=20 >=20 > The binding discovery and keep-alive usages=20 > both utilize the same Binding Request message, and require=20 > the same basic processing on the server. They differ only in=20 > where the server is (a standalone server in the network, or=20 > embedded in an application layer server), when the Binding=20 > Request is used and what the client does with the mapped=20 > address that is returned. >=20 > --- End replacement text --- >=20 >=20 >=20 > Page 10, last paragraph: > NIT: Change "the magic cookie" to "a magic cookie". >=20 >=20 >=20 >=20 > Page 11-13, Start of section 6 to first paragraph on page 13: >=20 > This section seemed to jump around a lot and=20 > have duplicate information. I took the liberty to reorder the=20 > material and clarify the text in this section of the document=20 > to make it flow better, and be more easily understood by the=20 > reader. I modeled the flow of the text around the format of=20 > the message. >=20 > Essentially, I got rid of any material that was=20 > repeated, and tried to lay out the material in the order in=20 > which it would appear in a STUN header such that if someone=20 > were looking at a STUN packet in a debugger, they could=20 > follow along in the text as they looked at the binary itself. >=20 > Also reorganized some of the parenthetical=20 > information to help more clearly separate informative text=20 > from normative text. >=20 > I've given my suggested updated text below.=20 > This would replace from the start of Section 6 down to the=20 > second paragraph on page > 13 where we start talking about STUN attributes. >=20 > --- Begin replacement text --- >=20 > STUN messages are encoded using a TLV (type-length-value)=20 > format with network ordered binary fields (most significant=20 > byte or octet first, also commonly known as big-endian). The=20 > transmission order is described in detail in Appendix B of=20 > RFC791 [2]. Unless otherwise noted, numeric constants are=20 > given in decimal (base 10). >=20 > [[ New Subsection: 6.1 STUN Message Header Format ]] >=20 > All STUN messages start with a single, 20 byte, STUN header=20 > followed by a STUN payload. The STUN header contains a STUN=20 > message type, magic cookie, transaction ID, and total payload length.=20 >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0| STUN Message Type | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Magic Cookie | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Transaction ID > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Figure 2: Format of STUN Message Header >=20 > The most significant two bits of every STUN=20 > message are both zeroes to aid in distinguishing STUN traffic=20 > from other protocols that may be multiplexed on the same port. >=20 > The message type defines the message class=20 > (request, success response, failure response, or indication)=20 > and the message method (the primary function) of the STUN=20 > message. Although there are four message classes, there are=20 > only two types of transactions in STUN: > request/response transactions (which utilize a request=20 > message and a response message), and indication transactions=20 > (which utilizes a single indication message). Response=20 > classes are differentiated to aid in quickly processing the=20 > STUN message. >=20 > The message type field is decomposed further=20 > into the following structure: >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |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|1|0| > |1|0| | | | | | | | | | | | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Figure 3: Format of STUN Message Type Field >=20 > M11 through M0 represent a 12-bit encoding of the method. C1=20 > through C0 represent a 2 bit encoding of the class. A class=20 > of 0 is a Request, a class of 1 is an indication, a class of=20 > 2 is a success response, and a class of 3 is an error=20 > response. This specification defines two > methods: Binding and Shared Secret. Their method values are=20 > enumerated in Section 15. >=20 > A number of mechanisms are provided to aid in differentiating=20 > STUN packets from other protocols that STUN may be=20 > multiplexed with on the same port. The magic cookie is a=20 > fixed value, 0x2112A442. In the previous version of this=20 > specification [15] this field was part of the transaction ID.=20 > This fixed value is used as part of the identification of a=20 > STUN message when STUN is multiplexed with other protocols on=20 > the same port, as is done for example in [13] and [18]. The=20 > magic cookie additionally indicates the STUN client is=20 > compliant with this specification. The magic cookie is=20 > present in all STUN messages -- requests, success responses,=20 > error responses and indications. In addition to the magic=20 > cookie and the leading zeroes in the STUN packet, there is=20 > also a fingerprint attribute that further aids in identifying=20 > the packet as a STUN packet. >=20 > The transaction ID is a unique 96-bit identifier that is used=20 > for identify STUN transactions. =20 >=20 > For request/response transactions, the transaction ID is=20 > chosen by the STUN client and MUST be unique for each new=20 > STUN transaction generated by that STUN client. The=20 > transaction ID MUST be uniformly and randomly distributed=20 > between 0 and 2**96 - 1. The large range is needed because=20 > the transaction ID serves as a form of randomization, helping=20 > to prevent replays of previously signed responses from the=20 > server. A reponse to the STUN request, whether it be a=20 > success or error response, carries the same transaction ID as=20 > the request. >=20 > Indications are also identified by their transaction ID. The=20 > transaction ID there MUST also be uniformly and randomly=20 > distributed between 0 and 2**96 - 1.As with requests, the=20 > value is chosen by the server and MUST be unique for each=20 > unique indication generated by the server. Unless a request=20 > or indication is bit-wise identical to a previous request,=20 > and was sent to the same server from the same transport=20 > address, a client MUST choose a new transaction ID for it. >=20 > STUN Requests are sent reliably, and can run over UDP, TCP or TCP/TLS. > When run over UDP, STUN requests are retransmitted in order=20 > to achieve reliability. Indication messages can be sent=20 > either from the client to the server, or from the server to=20 > the client using TCP or UDP. STUN itself does not provide=20 > reliability for these messages, though they will be delivered=20 > reliably when sent over TCP. >=20 > The message length is the size, in bytes, of the message not=20 > including the 20 byte STUN header. >=20 > [[ New subsection: 6.2 STUN Message Payload/Attributes ]] >=20 > --- End replacement text --- >=20 >=20 >=20 >=20 > Section 7.1: >=20 > Question: Is it allowable to have multiple transactions=20 > outstanding between the same two endpoints, or is it intended=20 > that a given server will only have one transaction=20 > outstanding from any given client? Assume it's the former and=20 > rephrased the text accordingly. >=20 > Tried to make the timeout behavior more specific, giving=20 > exact formulas for the behavior and calling out the=20 > difference between STUN retransmission/timeout behavior and=20 > the familiar SIP retransmission/timeout behavior. >=20 > Question: Is there a linger timer at the server during which=20 > time it is expected to cache the response to a particular=20 > request? For example, if a request is retransmitted via UDP,=20 > and the first response is dropped by the network, does the=20 > STUN server recalculate it's response or repeat the last=20 > response it sent to the earlier request (as in SIP)? The NAT=20 > binding could conceivably have changed between=20 > retransmissions due the NAT losing state (reboot, admin=20 > action) so that the reflexive transport address in the=20 > response is stale if the response is cached at the server to=20 > the earlier request.=20 >=20 > Seems like caching of the STUN response at the server is=20 > safe; the binding could always be lost at the NAT regardless=20 > of the timing of STUN messages. Since detection of caching at=20 > the server would be undetectable to the client, and should be=20 > left as optional, nothing needs to be said in the text, does it? >=20 > Fifth paragraph was unclear in original text. If STUN should=20 > not be retransmitted over TCP, then why wait until 7900ms,=20 > 1.6 seconds after the last retransmission, to timeout? I'm=20 > assuming you're waiting for TCP to timeout, but TCP may be=20 > using a different RTO value because it was calculated at a=20 > different point in time as the STUN RTO value. Assuming that=20 > we don't care about late responses due to TCP/STUN RTO value=20 > mismatch, right? We only care about the STUN application timer.=20 >=20 > Result of this was to take a stab at rearranging the text a=20 > bit and making it a bit more explicit: >=20 > --- Begin replacement text --- >=20 > STUN clients MAY have multiple outstanding STUN requests with=20 > different transaction IDs and not wait for completion of a=20 > STUN request/response exchange before sending another STUN=20 > request to the same STUN server. >=20 > [[ New section: 7.1.1 Reliability of STUN Requests ]] >=20 > STUN uses the TCP retransmission timeout (RTO) value, described in RFC > 2988 [8], for timing internal events regardless of the=20 > transport protocol used to send the request. This value is=20 > used as an input to the algorithms used to achieve=20 > reliability of STUN requests regardless of the transport=20 > protocol used. > =20 > Clients SHOULD use RFC 2988 [8] to compute an RTO value as an=20 > estimate of the round-trip-time, but with two exceptions. =20 > First, the initial value for RTO SHOULD be configurable=20 > (rather than the 3s recommended in RFC 2988). In fixed-line=20 > access links, an RTO value of 100ms is RECOMMENDED. =20 > Secondly, the RTO value MUST NOT be rounded up to the nearest=20 > second. Rather, a 1ms accuracy MUST be maintained. As with=20 > TCP, the usage of Karn's algorithm is RECOMMENDED. When=20 > Karn's algorithm is applied to STUN, this means that RTT=20 > estimates SHOULD NOT be computed from STUN transactions which=20 > result in the retransmission of a request. This value is used=20 > for both TCP and UDP operation. >=20 > The RTO value SHOULD be cached by an agent after the=20 > completion of the transaction and SHOULD be used as the=20 > starting RTO value for the next transaction to the same host=20 > (based on equality of IP address). The value SHOULD be=20 > considered stale for new transactions and discarded after 10 minutes. >=20 > [[ New section: 7.1.2 Sending STUN requests via UDP ]] >=20 > When running STUN over UDP, it is possible that the STUN=20 > request or its response might be dropped by the network.=20 > Therefore, reliability of a STUN request sent over UDP is=20 > accomplished via explicit retransmissions of the request by=20 > the STUN application. Clients SHOULD retransmit the request=20 > up to 6 times. Each retransmission is sent, relative to the=20 > time the original request was sent, and is given by: >=20 > Time to send next retransmission =3D t + (RTO * ((2 ^ n) - 1)) >=20 > Where t is the time the original request was sent, n is the=20 > current retransmission counter value and RTO is given in milliseconds. > Retransmissions continue until a response is received, or a=20 > total of 7 requests have been sent. > =20 > For example, if the STUN request was sent at time t, the=20 > retransmissions would be sent at: t + 100ms, t + 300ms, t +=20 > 700ms, t + 1500ms, t + 3100ms, and t + 6300ms.=20 >=20 > This differs from retransmission timings for other protocols=20 > such as SIP where the interval between retransmissions is=20 > relative to the time the last retransmission was sent, not=20 > the original request. >=20 > [[ New section: 7.1.3 Sending STUN requests via TCP ]] >=20 > When running STUN over TCP, the STUN application SHOULD NOT=20 > retransmit STUN requests; TCP itself is responsible for=20 > ensuring reliable delivery. >=20 > [[ New section: 7.1.4 STUN Transaction Timeout ]] >=20 > The STUN application does not consider the transport protocol=20 > used to send a STUN request when calculating when a STUN=20 > transaction will timeout. The transaction timeout value is given by: >=20 > Timeout of STUN transaction =3D t + ((2 ^ 6) -1) * RTO + 1600ms >=20 > Where t is the time the original request was sent, and RTO is=20 > expressed in milliseconds, the client SHOULD consider the=20 > transaction to have failed regardless of the transport=20 > protocol used to send the STUN request. A STUN transaction=20 > over UDP is also considered failed if there has been a=20 > transport failure of some sort, such as a fatal ICMP error. > Using our earlier example (with an RTO value of 100ms) gives=20 > an overall transaction timeout value of 7900ms after the=20 > original request was sent. > The STUN client would consider the transaction to have timed=20 > out if no response had been received by that time if either=20 > UDP or TCP was used. >=20 > Regardless of whether TCP or UDP was used for the=20 > transaction, if a failure occurs and the client has other=20 > servers it can reach (as a consequence of an SRV query which=20 > provides a multiplicity of STUN servers Section 8.1, for=20 > example), the client SHOULD create a new request, which is=20 > identical to the previous, but has a different transaction ID=20 > (and consequently a different MESSAGE INTEGRITY and/or=20 > FINGERPRINT attribute). >=20 > --- End replacement text --- >=20 >=20 >=20 > =3D=3D=3D >=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 Tue Nov 28 12:54:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp79G-0001qb-R7; Tue, 28 Nov 2006 12:53:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp79E-0001n0-Vr for behave@ietf.org; Tue, 28 Nov 2006 12:53:36 -0500 Received: from smtp2.wanadoo.co.uk ([193.252.22.157] helo=smtp2.freeserve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp799-0002oT-LB for behave@ietf.org; Tue, 28 Nov 2006 12:53:36 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3107.me.freeserve.com (SMTP Server) with ESMTP id 1FC114800089 for ; Tue, 28 Nov 2006 18:53:31 +0100 (CET) Received: from Codalogic (user-5445210e.lns4-c11.dsl.pol.co.uk [84.69.33.14]) by mwinf3107.me.freeserve.com (SMTP Server) with ESMTP id 987EB4800084 for ; Tue, 28 Nov 2006 18:53:30 +0100 (CET) X-ME-UUID: 20061128175330624.987EB4800084@mwinf3107.me.freeserve.com Message-ID: <004e01c71316$1de5b4b0$1c00a8c0@Codalogic> From: "Pete Cordell" To: Date: Tue, 28 Nov 2006 17:53:24 -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: 1.9 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [BEHAVE] STUN -> Session Traversal Underneath NAT 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 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 From behave-bounces@ietf.org Wed Nov 29 15:36:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpW9Z-00061U-7a; Wed, 29 Nov 2006 15:35:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpW9X-00061L-MV for behave@ietf.org; Wed, 29 Nov 2006 15:35:35 -0500 Received: from mx5-1.spamtrap.magma.ca ([209.217.78.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpW9W-0008UF-AP for behave@ietf.org; Wed, 29 Nov 2006 15:35:35 -0500 Received: from mail4.magma.ca (mail4.internal.magma.ca [10.0.10.14]) by mx5-1.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id kATKZV4x022008; Wed, 29 Nov 2006 15:35:32 -0500 Received: from [192.168.1.71] ([216.13.42.66]) (authenticated bits=0) by mail4.magma.ca (Magma's Mail Server) with ESMTP id kATKZUlp024288 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 29 Nov 2006 15:35:31 -0500 In-Reply-To: <004e01c71316$1de5b4b0$1c00a8c0@Codalogic> References: <004e01c71316$1de5b4b0$1c00a8c0@Codalogic> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT Date: Wed, 29 Nov 2006 15:36:01 -0500 To: Pete Cordell 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: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 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 From behave-bounces@ietf.org Wed Nov 29 15:42:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpWGN-0007hT-NJ; Wed, 29 Nov 2006 15:42:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpWGM-0007hO-Jo for behave@ietf.org; Wed, 29 Nov 2006 15:42:38 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpWGL-00028v-0F for behave@ietf.org; Wed, 29 Nov 2006 15:42:38 -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 kATKgU614484; Wed, 29 Nov 2006 15:42:30 -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: Wed, 29 Nov 2006 14:42:23 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437111AA821D@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] STUN -> Session Traversal Underneath NAT Thread-Index: AccT9noVaudM0wEBTc2BpNWaomu7cgAACSdg From: "Brian Stucker" To: "Philip Matthews" , "Pete Cordell" X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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 Oh! So that's what that little light on the bottom of my home NAT/router is there for. :) I was beginning to think I had been holding that picture of the OSI model upside down all these years. Regards, Brian=20 > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 > Sent: Wednesday, November 29, 2006 2:36 PM > To: Pete Cordell > Cc: behave@ietf.org > Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT >=20 > If we are going to do this, then I would prefer "Session=20 > Traversal through NAT". > I don't see how "underneath" is really appropriate either. > No one talks about sending a packet or a media session=20 > "underneath" a NAT. >=20 > - Philip >=20 > On 28-Nov-06, at 12:53 , Pete Cordell wrote: >=20 > > I jested before, but the more I think about it, the more I find the=20 > > 'simple' in the STUN name irksome. > > > > STUN now is really (potentially) STUN + TURN of old. I=20 > don't see how=20 > > that combination can be called simple. Granted, it's not hugely=20 > > complex, but it is not HTTP 0.9 either! Between the two of=20 > them there=20 > > are 14 different types of message and 24 different attributes. > > > > Further, STUN on it's own isn't much good. In reality the=20 > STUN base=20 > > specs are just the message definitions, whereas ICE is how to use=20 > > those messages. Together there is 185 pages of=20 > documentation, which I=20 > > don't consider to be simple. (SIP is 269 pages and I don't=20 > think we=20 > > can argue that is simple. Thus STUN + usage is of comparable=20 > > complexity; to document at least.) > > > > But the thing I hate most about it though is the marketing=20 > spin feel=20 > > of it! Use this and your teeth will be whiter than white=20 > and it won't=20 > > cost you a penny! > > > > Actually, I think the word 'simple' should be avoided in=20 > all acronyms=20 > > as a matter of policy. Even if something starts out=20 > simple, if it's=20 > > useful it gets added to and evolves into something that is=20 > no longer=20 > > 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 ... =20 > > protocol" be removed from the spec. (Just use "STUN is a ... =20 > > protocol"). > > > > Pete. > > -- > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Pete Cordell > > 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 >=20 >=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 Wed Nov 29 20:08:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpaPD-0008IB-Jt; Wed, 29 Nov 2006 20:08:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpaPC-0008I5-PW for behave@ietf.org; Wed, 29 Nov 2006 20:08:02 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpaPB-0006x2-SC for behave@ietf.org; Wed, 29 Nov 2006 20:08:02 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 29 Nov 2006 17:08:01 -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 kAU181GT016164; Wed, 29 Nov 2006 17:08:01 -0800 Received: from dwingwxp ([10.32.240.198]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kAU17oOV024002; Wed, 29 Nov 2006 17:07:51 -0800 (PST) From: "Dan Wing" To: "'Brian Stucker'" , "'Jonathan Rosenberg'" , Subject: RE: [BEHAVE] Review of rfc3489bis-05 up to section 8 Date: Wed, 29 Nov 2006 17:07:50 -0800 Keywords: direct-to-dwing Message-ID: <1ca301c7141b$fa66ebb0$c6f0200a@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: AccSpp0MczxJebBYSMWBXJW3IkSkogAaXIhgAELaNZA= In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437111A4AA1F@zrc2hxm2.corp.nortel.com> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=19999; t=1164848881; x=1165712881; 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:=20RE=3A=20[BEHAVE]=20Review=20of=20rfc3489bis-05=20up=20to=20se ction=208 |Sender:=20; bh=IW8GWxQe/FGGdAGN6efV5ZY0ZAITuasyvrNa0kmbwPw=; b=LtUbWPVXp3iOe18QEs+6l+VymnzeBqyDRXUrbFgMhs09akCMCT2fJwtzzDioOVdNxtmDTITn ClNvhVjR9kFduW1OBtzSOLQOs1VjVOClc7zjtWPxAh/1UHlBkAwzwNiQ; Authentication-Results: sj-dkim-7; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 2.1 (++) X-Scan-Signature: 8aa7cbc518894eb04182283f0682f662 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 expect that would interact poorly with TCP simultaneous-open. Saikat, any thoughts? -d > -----Original Message----- > From: Brian Stucker [mailto:bstucker@nortel.com] > Sent: Tuesday, November 28, 2006 9:11 AM > To: Jonathan Rosenberg; Dan Wing; rohan@ekabal.com > Cc: behave@ietf.org > Subject: RE: [BEHAVE] Review of rfc3489bis-05 up to section 8 > > One other thought on section 7.1... The current text states that > transport failures (ICMP errors) for UDP should be considered > failures. > What about other transport failures? Does a TCP connection reset > constitute a failure of the STUN transaction? > > Regards, > Brian > > > -----Original Message----- > > From: Stucker, Brian (RICH1:AR00) > > Sent: Monday, November 27, 2006 10:35 PM > > To: Jonathan Rosenberg; Dan Wing; rohan@ekabal.com > > Cc: behave@ietf.org > > Subject: [BEHAVE] Review of rfc3489bis-05 up to section 8 > > > > Hi guys, > > > > Mirroring Kevin's format for WGLC review comments, here's > > what I have up to section 8. > > > > I will make a very broad disclaimer that the comments may > > seem extensive (especially sections 6 and 7.1), but most of > > them are intended to be editorial. Now that the functionality > > has been settled, I have been going back through the document > > as a designer having an interoperability debate with another > > vendor. With that in mind, my comments are generally trying > > to make the text as easy to follow (it's already better than > > most specs I have read) and get rid of any points of future > > debate for the folks having to write code to the spec. > > > > Rather than give change bars on the larger chunks, I've > > offered replacement text. I didn't know of a more expedient > > way of doing this that was easily understandable, sorry for > > the length (hoping cut & paste into the draft will work > > here). A lot of it is simply moving existing text around to > > improve the flow. Unless otherwise noted ahead of the change > > offered, the edits are intended to be editorial in nature, > > and not to change the intent of the mechanism. I'll be > > working on getting through the rest of the document tomorrow. > > Sorry I couldn't get these to you earlier. > > > > Cheers, > > Brian > > > > --- > > > > General nit: Aren't the document references supposed to be of > > the format [RFC2988] instead of [8] now? > > > > > > Page 9, third paragraph: > > NIT: "sent over TLS [5] over TCP." May wish to > > change to "sent via TLS[5] over TCP." > > > > NIT: capitalization of "Shared secret requests" > > inconsistient within the paragraph. > > > > > > Page 9, fourth paragraph: > > NIT: Second sentence seems awkward, consider > > revising first two sentences to read: > > > > --- Begin replacement text --- > > > > There are many ways in which the basic > > mechanisms within the STUN protocol can be combined to > > accomplish a specific task. Such combinations of STUN > > protocol elements are known as a 'usage' within the protocol. > > > > --- End replacement text --- > > > > > > > > Page 10, first & second paragraph: > > The text in this paragraph seems to muddle SIP > > outbound concepts with STUN too heavily. The result is that > > the STUN mechanism being described is not as clearly called > > out as it could be. Consider clarifying to better call out > > the STUN mechanism being described: > > > > --- Begin replacement text --- > > > > The binding keep-alive usage also utilizes > > the STUN binding request message, but for a different > > purpose. Bindings allocated by a NAT typically expire if left > > dorment. When this happens, the client behind the NAT is no > > longer reachable by the server on the other side of the NAT. > > As a result, the client must generate periodic traffic to > > refresh the existing NAT binding. Rather than use potentially > > expensive application layer messages, a STUN binding request > > is sent by the client to the server. This binding request is > > sent to the exact same transport address used by the server > > for the application protocol (in the case of SIP, this would > > typically port 5060 or 5061). In addition to keeping the > > binding on the NAT alive, the STUN binding responses have additional > > effects: they inform the client that the server is still > > responsive, and if the client's transport address towards the > > server has changed (its reflexive transport address). If the > > client's transport address has changed, it may need > > additional application layer protocol messaging to update its > > transport address as seen by the server (i.e. the binding > > keep-alive usage has used by the SIP outbound mechanism [18]). > > > > The binding discovery and keep-alive usages > > both utilize the same Binding Request message, and 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. > > > > --- End replacement text --- > > > > > > > > Page 10, last paragraph: > > NIT: Change "the magic cookie" to "a magic cookie". > > > > > > > > > > Page 11-13, Start of section 6 to first paragraph on page 13: > > > > This section seemed to jump around a lot and > > have duplicate information. I took the liberty to reorder the > > material and clarify the text in this section of the document > > to make it flow better, and be more easily understood by the > > reader. I modeled the flow of the text around the format of > > the message. > > > > Essentially, I got rid of any material that was > > repeated, and tried to lay out the material in the order in > > which it would appear in a STUN header such that if someone > > were looking at a STUN packet in a debugger, they could > > follow along in the text as they looked at the binary itself. > > > > Also reorganized some of the parenthetical > > information to help more clearly separate informative text > > from normative text. > > > > I've given my suggested updated text below. > > This would replace from the start of Section 6 down to the > > second paragraph on page > > 13 where we start talking about STUN attributes. > > > > --- Begin replacement text --- > > > > STUN messages are encoded using a TLV (type-length-value) > > format with network ordered binary fields (most significant > > byte or octet first, also commonly known as big-endian). The > > transmission order is described in detail in Appendix B of > > RFC791 [2]. Unless otherwise noted, numeric constants are > > given in decimal (base 10). > > > > [[ New Subsection: 6.1 STUN Message Header Format ]] > > > > All STUN messages start with a single, 20 byte, STUN header > > followed by a STUN payload. The STUN header contains a STUN > > message type, magic cookie, transaction ID, and total > payload length. > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0 0| STUN Message Type | Message Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Magic Cookie | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Transaction ID > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 2: Format of STUN Message Header > > > > The most significant two bits of every STUN > > message are both zeroes to aid in distinguishing STUN traffic > > from other protocols that may be multiplexed on the same port. > > > > The message type defines the message class > > (request, success response, failure response, or indication) > > and the message method (the primary function) of the STUN > > message. Although there are four message classes, there are > > only 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 message). Response > > classes are differentiated to aid in quickly processing the > > STUN message. > > > > 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|1|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. > > > > A number of mechanisms are provided to aid in differentiating > > STUN packets from other protocols that STUN may be > > multiplexed with on the same port. The magic cookie is a > > fixed value, 0x2112A442. In the previous version of this > > specification [15] this field was part of the transaction ID. > > This fixed value is used as part of the identification of a > > STUN message when STUN is multiplexed with other protocols on > > the same port, as is done for example in [13] and [18]. The > > magic cookie additionally indicates the STUN client is > > compliant with this specification. The magic cookie is > > present in all STUN messages -- requests, success responses, > > error responses and indications. In addition to the magic > > cookie and the leading zeroes in the STUN packet, there is > > also a fingerprint attribute that further aids in identifying > > the packet as a STUN packet. > > > > The transaction ID is a unique 96-bit identifier that is used > > for identify STUN transactions. > > > > 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. > > > > STUN Requests are sent reliably, and can run over UDP, TCP > or TCP/TLS. > > When run over UDP, STUN requests are retransmitted in order > > to achieve reliability. Indication messages can be sent > > either from the client to the server, or from the server to > > the client using TCP or UDP. STUN itself does not provide > > reliability for these messages, though they will be delivered > > reliably when sent over TCP. > > > > The message length is the size, in bytes, of the message not > > including the 20 byte STUN header. > > > > [[ New subsection: 6.2 STUN Message Payload/Attributes ]] > > > > --- End replacement text --- > > > > > > > > > > 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? Assume it's the former and > > rephrased the text accordingly. > > > > Tried to make the timeout behavior more specific, giving > > exact formulas for the behavior and calling out the > > difference between STUN retransmission/timeout behavior and > > the familiar SIP retransmission/timeout behavior. > > > > Question: Is there a linger timer at the server during which > > time it is expected to cache the response to a particular > > request? For example, if a request is retransmitted via UDP, > > and the first response is dropped by the network, does the > > STUN server recalculate it's response or repeat the last > > response it sent to the earlier request (as in SIP)? The NAT > > binding could conceivably have changed between > > retransmissions due the NAT losing state (reboot, admin > > action) so that the reflexive transport address in the > > response is stale if the response is cached at the server to > > the earlier request. > > > > Seems like caching of the STUN response at the server is > > safe; the binding could always be lost at the NAT regardless > > of the timing of STUN messages. Since detection of caching at > > the server would be undetectable to the client, and should be > > left as optional, nothing needs to be said in the text, does it? > > > > Fifth paragraph was unclear in original text. If STUN should > > not be retransmitted over TCP, then why wait until 7900ms, > > 1.6 seconds after the last retransmission, to timeout? I'm > > assuming you're waiting for TCP to timeout, but TCP may be > > using a different RTO value because it was calculated at a > > different point in time as the STUN RTO value. Assuming that > > we don't care about late responses due to TCP/STUN RTO value > > mismatch, right? We only care about the STUN application timer. > > > > Result of this was to take a stab at rearranging the text a > > bit and making it a bit more explicit: > > > > --- Begin replacement text --- > > > > STUN clients MAY have multiple outstanding STUN requests with > > different transaction IDs and not wait for completion of a > > STUN request/response exchange before sending another STUN > > request to the same STUN server. > > > > [[ New section: 7.1.1 Reliability of STUN Requests ]] > > > > STUN uses the TCP retransmission timeout (RTO) value, > described in RFC > > 2988 [8], for timing internal events regardless of the > > transport protocol used to send the request. This value is > > used as an input to the algorithms used to achieve > > reliability of STUN requests regardless of the transport > > protocol used. > > > > Clients SHOULD use RFC 2988 [8] to compute an RTO value as an > > estimate of the round-trip-time, but with two exceptions. > > First, the initial value for RTO SHOULD be configurable > > (rather than the 3s recommended in RFC 2988). In fixed-line > > access links, an RTO value of 100ms is RECOMMENDED. > > Secondly, the RTO value MUST NOT be rounded up to the nearest > > second. Rather, a 1ms accuracy MUST be maintained. As with > > TCP, the usage of Karn's algorithm is RECOMMENDED. When > > Karn's algorithm is applied to STUN, this means that RTT > > estimates SHOULD NOT be computed from STUN transactions which > > result in the retransmission of a request. This value is used > > for both TCP and UDP operation. > > > > The RTO value SHOULD be cached by an agent after the > > completion of the transaction and SHOULD be used as the > > starting RTO value for the next transaction to the same host > > (based on equality of IP address). The value SHOULD be > > considered stale for new transactions and discarded after > 10 minutes. > > > > [[ New section: 7.1.2 Sending STUN requests via UDP ]] > > > > When running STUN over UDP, it is possible that the STUN > > request or its response might be dropped by the network. > > Therefore, reliability of a STUN request sent over UDP is > > accomplished via explicit retransmissions of the request by > > the STUN application. Clients SHOULD retransmit the request > > up to 6 times. Each retransmission is sent, relative to the > > time the original request was sent, and is given by: > > > > Time to send next retransmission = t + (RTO * ((2 ^ n) - 1)) > > > > Where t is the time the original request was sent, n is the > > current retransmission counter value and RTO is given in > milliseconds. > > Retransmissions continue until a response is received, or a > > total of 7 requests have been sent. > > > > For example, if the STUN request was sent at time t, the > > retransmissions would be sent at: t + 100ms, t + 300ms, t + > > 700ms, t + 1500ms, t + 3100ms, and t + 6300ms. > > > > This differs from retransmission timings for other protocols > > such as SIP where the interval between retransmissions is > > relative to the time the last retransmission was sent, not > > the original request. > > > > [[ New section: 7.1.3 Sending STUN requests via TCP ]] > > > > When running STUN over TCP, the STUN application SHOULD NOT > > retransmit STUN requests; TCP itself is responsible for > > ensuring reliable delivery. > > > > [[ New section: 7.1.4 STUN Transaction Timeout ]] > > > > The STUN application does not consider the transport protocol > > used to send a STUN request when calculating when a STUN > > transaction will timeout. The transaction timeout value is given by: > > > > Timeout of STUN transaction = t + ((2 ^ 6) -1) * RTO + 1600ms > > > > Where t is the time the original request was sent, and RTO is > > expressed in milliseconds, the client SHOULD consider the > > transaction to have failed regardless of the transport > > protocol used to send the STUN request. A STUN transaction > > over UDP is also considered failed if there has been a > > transport failure of some sort, such as a fatal ICMP error. > > Using our earlier example (with an RTO value of 100ms) gives > > an overall transaction timeout value of 7900ms after the > > original request was sent. > > The STUN client would consider the transaction to have timed > > out if no response had been received by that time if either > > UDP or TCP was used. > > > > Regardless of whether TCP or UDP was used for the > > transaction, if a failure occurs and the client has other > > servers it can reach (as a consequence of an SRV query which > > provides a multiplicity of STUN servers Section 8.1, for > > example), the client SHOULD create a new request, which is > > identical to the previous, but has a different transaction ID > > (and consequently a different MESSAGE INTEGRITY and/or > > FINGERPRINT attribute). > > > > --- End replacement text --- > > > > > > > > === > > > > _______________________________________________ > > 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 Nov 29 21:27:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpbdG-0000bH-K6; Wed, 29 Nov 2006 21:26:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpbdF-0000b2-HQ for behave@ietf.org; Wed, 29 Nov 2006 21:26: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 1GpbdE-0006ce-8p for behave@ietf.org; Wed, 29 Nov 2006 21:26:37 -0500 Received: from exchfe2.cs.cornell.edu ([128.84.97.28]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 21:26:30 -0500 Received: from [128.84.227.36] ([128.84.227.36]) by exchfe2.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 21:26:25 -0500 Subject: RE: [BEHAVE] Review of rfc3489bis-05 up to section 8 From: Saikat Guha To: Dan Wing In-Reply-To: <1ca301c7141b$fa66ebb0$c6f0200a@amer.cisco.com> References: <1ca301c7141b$fa66ebb0$c6f0200a@amer.cisco.com> Date: Wed, 29 Nov 2006 21:26:25 -0500 Message-Id: <1164853585.21947.31.camel@sioux.systems.cs.cornell.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.9.2 (2.9.2-3) X-OriginalArrivalTime: 30 Nov 2006 02:26:25.0950 (UTC) FILETIME=[EF4D93E0:01C71426] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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: , Content-Type: multipart/mixed; boundary="===============0927462105==" Errors-To: behave-bounces@ietf.org --===============0927462105== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-cPu9Mtnsl4kUNxKzoMp+" --=-cPu9Mtnsl4kUNxKzoMp+ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, 2006-11-29 at 17:07 -0800, Dan Wing wrote: > I expect that would interact poorly with TCP simultaneous-open. Saikat, = any > thoughts? > > > -----Original Message----- > > From: Brian Stucker [mailto:bstucker@nortel.com]=20 > >=20 > > One other thought on section 7.1... The current text states that > > transport failures (ICMP errors) for UDP should be considered=20 > > failures. > > What about other transport failures? Does a TCP connection reset > > constitute a failure of the STUN transaction? If an app is trying TCP S-O and *only* TCP S-O, then RSTs can be annoying, but apps should be doing both regular connections and S-O in parallel as per ICE. If an endpoint gets an RST while trying to STUN the other end, then packets must be getting through to the other end (BEHAVE compliant NATs are not supposed to RST new connections). In those cases, the regular connection should work (i.e. local LAN or already-punched NAT). --=20 Saikat --=-cPu9Mtnsl4kUNxKzoMp+ 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) iD8DBQBFbkFRnFltqi691/oRAvKaAJwNRST33gkO6RplBcN9xXu+HLsxIQCeNfqn 4Tbbd5qZyB9rmzpZJqG5nec= =rJWB -----END PGP SIGNATURE----- --=-cPu9Mtnsl4kUNxKzoMp+-- --===============0927462105== 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 --===============0927462105==-- From behave-bounces@ietf.org Thu Nov 30 05:24:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpj59-0006ps-3j; Thu, 30 Nov 2006 05:23:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpj58-0006nA-IC for behave@ietf.org; Thu, 30 Nov 2006 05:23:54 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpj56-0004MH-Eb for behave@ietf.org; Thu, 30 Nov 2006 05:23:54 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id E2BB71944F6 for ; Thu, 30 Nov 2006 11:23:40 +0100 (CET) Received: from [192.168.1.49] ([192.168.1.49]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 11:23:23 +0100 In-Reply-To: References: <004e01c71316$1de5b4b0$1c00a8c0@Codalogic> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT Date: Thu, 30 Nov 2006 11:23:11 +0100 To: Philip Matthews X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 30 Nov 2006 10:23:23.0452 (UTC) FILETIME=[90A9D7C0:01C71469] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 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 From behave-bounces@ietf.org Thu Nov 30 06:59:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpkZm-00070T-84; Thu, 30 Nov 2006 06:59:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpkZk-00070N-V5 for behave@ietf.org; Thu, 30 Nov 2006 06:59:37 -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 1GpkZj-000726-GI for behave@ietf.org; Thu, 30 Nov 2006 06:59:36 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3007.me.freeserve.com (SMTP Server) with ESMTP id 73F7E1C00088; Thu, 30 Nov 2006 12:59:28 +0100 (CET) Received: from Codalogic (user-5445210e.lns4-c11.dsl.pol.co.uk [84.69.33.14]) by mwinf3007.me.freeserve.com (SMTP Server) with ESMTP id 2D3271C00085; Thu, 30 Nov 2006 12:59:28 +0100 (CET) X-ME-UUID: 20061130115928185.2D3271C00085@mwinf3007.me.freeserve.com Message-ID: <004701c71476$fd079ee0$1c00a8c0@Codalogic> From: "Pete Cordell" To: "Hisham Khartabil" , "Philip Matthews" References: <004e01c71316$1de5b4b0$1c00a8c0@Codalogic> Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT Date: Thu, 30 Nov 2006 11:59:26 -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: 0.1 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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 agree it needs to be a U word. I went through my dictionary and came up with the following (in rough order of preference): Session Traversal Unblocking NAT Session Traversal Understanding NAT Session Traversal Using NAT Session Traversal Uniting NAT Session Traversal Untangling NAT I would also be OK with Underneath. Not great, but kinda works! If you feel like going with the Session Traversal through ??? NATs route, there are various derogatory terms that start with U, such as: Session Traversal through Unholy NATs! Pete. -- ----- Original Message ----- From: "Hisham Khartabil" To: "Philip Matthews" Cc: "Pete Cordell" ; Sent: Thursday, November 30, 2006 10:23 AM Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT > 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 From behave-bounces@ietf.org Thu Nov 30 13:49:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpqxw-0008Kw-Jv; Thu, 30 Nov 2006 13:49:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpqxr-0008HB-IF for behave@ietf.org; Thu, 30 Nov 2006 13:48:55 -0500 Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpqtJ-0003p7-NP for behave@ietf.org; Thu, 30 Nov 2006 13:44:20 -0500 Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.20; Thu, 30 Nov 2006 10:44:13 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) with Microsoft SMTP Server id 8.0.685.23; Thu, 30 Nov 2006 10:44:12 -0800 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Thu, 30 Nov 2006 10:44:12 -0800 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: Thu, 30 Nov 2006 10:44:09 -0800 Message-ID: <70C6EFCDFC8AAD418EF7063CD132D06402DBB0AD@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <004701c71476$fd079ee0$1c00a8c0@Codalogic> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] STUN -> Session Traversal Underneath NAT Thread-Index: AccUd1QdcjNmozp2QJWn30usZDPv2QAOCfvw References: <004e01c71316$1de5b4b0$1c00a8c0@Codalogic> <004701c71476$fd079ee0$1c00a8c0@Codalogic> From: Christian Huitema To: Pete Cordell , Hisham Khartabil , Philip Matthews X-OriginalArrivalTime: 30 Nov 2006 18:44:12.0873 (UTC) FILETIME=[87839B90:01C714AF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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 "Session Traversal Uncorking NAT"... > -----Original Message----- > From: Pete Cordell [mailto:pete.cordell@tech-know-ware.com] > Sent: Thursday, November 30, 2006 3:59 AM > To: Hisham Khartabil; Philip Matthews > Cc: behave@ietf.org > Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT >=20 > I agree it needs to be a U word. I went through my dictionary and came > up > with the following (in rough order of preference): >=20 > Session Traversal Unblocking NAT > Session Traversal Understanding NAT > Session Traversal Using NAT > Session Traversal Uniting NAT > Session Traversal Untangling NAT >=20 > I would also be OK with Underneath. Not great, but kinda works! >=20 > If you feel like going with the Session Traversal through ??? NATs > route, > there are various derogatory terms that start with U, such as: Session > Traversal through Unholy NATs! >=20 > Pete. > -- > ----- Original Message ----- > From: "Hisham Khartabil" > To: "Philip Matthews" > Cc: "Pete Cordell" ; > Sent: Thursday, November 30, 2006 10:23 AM > Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT >=20 >=20 > > 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. > >>> -- > >>> = =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 > >> > > > > >=20 >=20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Nov 30 13:58:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpr6u-00051b-PC; Thu, 30 Nov 2006 13:58:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpr6u-00051V-7J for behave@ietf.org; Thu, 30 Nov 2006 13:58:16 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpr6s-0005in-P1 for behave@ietf.org; Thu, 30 Nov 2006 13:58:16 -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 kAUIwCR22905 for ; Thu, 30 Nov 2006 13:58:12 -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: Thu, 30 Nov 2006 12:58:00 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E379D21@zrc2hxm0.corp.nortel.com> In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D06402DBB0AD@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] STUN -> Session Traversal Underneath NAT thread-index: AccUd1QdcjNmozp2QJWn30usZDPv2QAOCfvwAABcVzA= From: "Francois Audet" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 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 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. > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com]=20 > Sent: Thursday, November 30, 2006 10:44 > To: Pete Cordell; Hisham Khartabil; Philip Matthews > Cc: behave@ietf.org > Subject: RE: [BEHAVE] STUN -> Session Traversal Underneath NAT >=20 > "Session Traversal Uncorking NAT"... >=20 > > -----Original Message----- > > From: Pete Cordell [mailto:pete.cordell@tech-know-ware.com] > > Sent: Thursday, November 30, 2006 3:59 AM > > To: Hisham Khartabil; Philip Matthews > > Cc: behave@ietf.org > > Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT > >=20 > > I agree it needs to be a U word. I went through my dictionary and > came > > up > > with the following (in rough order of preference): > >=20 > > Session Traversal Unblocking NAT > > Session Traversal Understanding NAT > > Session Traversal Using NAT > > Session Traversal Uniting NAT > > Session Traversal Untangling NAT > >=20 > > I would also be OK with Underneath. Not great, but kinda works! > >=20 > > If you feel like going with the Session Traversal through ??? NATs=20 > > route, there are various derogatory terms that start with=20 > U, such as:=20 > > Session Traversal through Unholy NATs! > >=20 > > Pete. > > -- > > ----- Original Message ----- > > From: "Hisham Khartabil" > > To: "Philip Matthews" > > Cc: "Pete Cordell" ; > > > Sent: Thursday, November 30, 2006 10:23 AM > > Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT > >=20 > >=20 > > > 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=20 > Traversal=20 > > >> through NAT". > > >> I don't see how "underneath" is really appropriate either. > > >> No one talks about sending a packet or a media session=20 > "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=20 > don't see > > how > > >>> that combination can be called simple. Granted, it's=20 > not hugely=20 > > >>> 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=20 > 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=20 > think we can > > argue > > >>> that is simple. Thus STUN + usage is of comparable=20 > complexity; to=20 > > >>> 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=20 > 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=20 > 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=20 > simple ... > > >>> protocol" be removed from the spec. (Just use "STUN is a ... > > >>> protocol"). > > >>> > > >>> Pete. > > >>> -- > > >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >>> Pete Cordell > > >>> 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 > > >> > > > > > > > >=20 > >=20 > >=20 > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www1.ietf.org/mailman/listinfo/behave >=20 >=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 Nov 30 14:19:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GprQu-0005mQ-Qs; Thu, 30 Nov 2006 14:18:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GprQt-0005jt-SV for behave@ietf.org; Thu, 30 Nov 2006 14:18:55 -0500 Received: from lambda.sipfoundry.org ([72.232.205.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GprQr-0007yt-JU for behave@ietf.org; Thu, 30 Nov 2006 14:18:55 -0500 Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.192.83]) by lambda.sipfoundry.org (8.13.8/8.13.8) with ESMTP id kAUJInPm069075 for ; Thu, 30 Nov 2006 13:18:53 -0600 (CST) (envelope-from spencer@mcsr-labs.org) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com[72.190.0.23]) by comcast.net (rwcrmhc13) with SMTP id <20061130191843m1300blfi1e>; Thu, 30 Nov 2006 19:18:43 +0000 Message-ID: <06c001c714b3$ee020600$6b01a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <1ECE0EB50388174790F9694F77522CCF0E379D21@zrc2hxm0.corp.nortel.com> Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT Date: Thu, 30 Nov 2006 13:15:42 -0600 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.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 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. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Nov 30 15:03:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gps7q-0008JK-RB; Thu, 30 Nov 2006 15:03:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gps7p-0008En-Gp for behave@ietf.org; Thu, 30 Nov 2006 15:03:17 -0500 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gps7n-00059k-9J for behave@ietf.org; Thu, 30 Nov 2006 15:03:17 -0500 Received: from 71-10-183-137.dhcp.stls.mo.charter.com ([71.10.183.137] helo=[192.168.0.40]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1Gps7m-0009SV-GC for behave@ietf.org; Thu, 30 Nov 2006 15:03:14 -0500 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.10.183.137 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: digitalari Message-ID: <456F3901.2080309@sipstation.com> Date: Thu, 30 Nov 2006 14:03:13 -0600 From: Alan Johnston User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: behave@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [BEHAVE] Question on TURN lockdown 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 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 From behave-bounces@ietf.org Thu Nov 30 16:13:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GptDZ-00043o-G3; Thu, 30 Nov 2006 16:13:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GptDB-0003M1-4f for behave@ietf.org; Thu, 30 Nov 2006 16:12:53 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpt3R-0004iw-Dr for behave@ietf.org; Thu, 30 Nov 2006 16:02:53 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 30 Nov 2006 13:02:49 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAUL2jC7024761; Thu, 30 Nov 2006 13:02:48 -0800 Received: from dwingwxp (sjc-vpn2-64.cisco.com [10.21.112.64]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAUL2iio017278; Thu, 30 Nov 2006 13:02:45 -0800 (PST) From: "Dan Wing" To: "'Alan Johnston'" , Subject: RE: [BEHAVE] Question on TURN lockdown Date: Thu, 30 Nov 2006 13:02:39 -0800 Message-ID: <089e01c714c2$e27be5d0$fe78150a@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: AccUutopggb3G86bRbaiGxhroRlt5QAB3etA In-Reply-To: <456F3901.2080309@sipstation.com> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3193; t=1164920568; x=1165784568; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20Question=20on=20TURN=20lockdown |Sender:=20; bh=natBarsHg0CPRcOm0bOBrdC0yUUnCeCEXPlmxF5LUgo=; b=IIX2RSZokN7zCyARxosprgciCiJXewc2JaXXeWe7VF4hOo9/K0SqqmJ5jYfT93NmF15tiqWZ wQdLKES5ecGNd04m9XD3tJ//W6U7JmmrOFYJYQcVzlqquQx8ovYnurVG; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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 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 From behave-bounces@ietf.org Thu Nov 30 17:39:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpuZ4-0003iC-6t; Thu, 30 Nov 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 1GpuZ3-0003hh-9N for behave@ietf.org; Thu, 30 Nov 2006 17:39:33 -0500 Received: from lambda.sipfoundry.org ([72.232.205.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpuZ0-0005Tn-81 for behave@ietf.org; Thu, 30 Nov 2006 17:39:33 -0500 Received: from mx5-1.spamtrap.magma.ca (mx5-1.spamtrap.magma.ca [209.217.78.136]) by lambda.sipfoundry.org (8.13.8/8.13.8) with ESMTP id kAUMdPq2080020 for ; Thu, 30 Nov 2006 16:39:29 -0600 (CST) (envelope-from philip_matthews@magma.ca) Received: from mail2.magma.ca (mail2.internal.magma.ca [10.0.10.12]) by mx5-1.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id kAUMcDwu006642; Thu, 30 Nov 2006 17:38:18 -0500 Received: from [206.191.1.146] (ottawa-dial-206-191-1-146.d-ip.magma.ca [206.191.1.146]) (authenticated bits=0) by mail2.magma.ca (Magma's Mail Server) with ESMTP id kAUMbjAD002124 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 Nov 2006 17:37:56 -0500 In-Reply-To: <06c001c714b3$ee020600$6b01a8c0@china.huawei.com> References: <1ECE0EB50388174790F9694F77522CCF0E379D21@zrc2hxm0.corp.nortel.com> <06c001c714b3$ee020600$6b01a8c0@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT Date: Thu, 30 Nov 2006 17:37:02 -0500 To: Spencer Dawkins , Francois Audet , Pete Cordell 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: 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 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. > > > _______________________________________________ > 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 Nov 30 17:49:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpuiF-0003Eu-Ba; Thu, 30 Nov 2006 17:49:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpuiE-0003E4-4x for behave@ietf.org; Thu, 30 Nov 2006 17:49:02 -0500 Received: from lambda.sipfoundry.org ([72.232.205.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpuhR-0006yF-Jo for behave@ietf.org; Thu, 30 Nov 2006 17:48:14 -0500 Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by lambda.sipfoundry.org (8.13.8/8.13.8) with ESMTP id kAUMm0FV080426 for ; Thu, 30 Nov 2006 16:48:04 -0600 (CST) (envelope-from AUDET@nortel.com) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAUMlhL26576; Thu, 30 Nov 2006 17:47:49 -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: Thu, 30 Nov 2006 16:47:26 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E37A1C5@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] STUN -> Session Traversal Underneath NAT thread-index: AccU0IG0NWUpQZtQSSqBuI2vODklbgAAG7Aw From: "Francois Audet" To: "Philip Matthews" , "Spencer Dawkins" , "Pete Cordell" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 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]=20 > 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 >=20 > I also agree with Francois and Spencer. > Though I will suggest that > "Set of Tools Useful for NAT traversal (STUN)" would be more accurate. >=20 > And there is a history of not always having the acronym=20 > correspond directly to the first letter of each work.=20 > Consider, for example, RSVP (Resource Reservation Protocol). > I am sure folks can come up with other examples. >=20 > - Philip >=20 >=20 > On 30-Nov-06, at 14:15 , Spencer Dawkins wrote: >=20 > > Agree with Francois here. This would be a lot less confusing than=20 > > having two specs come out for NAT traversal at the same time... > > > > Spencer > > > > ----- Original Message ----- From: "Francois Audet"=20 > > > 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=20 > anymore (that=20 > > would be ICE). > > > > It's more a set of generic tools for NAT support. > > > > STUN: Set of Tools Useful for NAT > > ^ ^ ^ ^ > > > > Cheers. > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www1.ietf.org/mailman/listinfo/behave >=20 >=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Nov 30 21:33:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpyCZ-0005ly-N1; Thu, 30 Nov 2006 21:32:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpyCY-0005kM-FR for behave@ietf.org; Thu, 30 Nov 2006 21:32:34 -0500 Received: from lambda.sipfoundry.org ([72.232.205.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpyCW-0007ik-Lu for behave@ietf.org; Thu, 30 Nov 2006 21:32:34 -0500 Received: from mx4-1.spamtrap.magma.ca (mx4-1.spamtrap.magma.ca [209.217.78.176]) by lambda.sipfoundry.org (8.13.8/8.13.8) with ESMTP id kB12WRxh091392 for ; Thu, 30 Nov 2006 20:32:32 -0600 (CST) (envelope-from philip_matthews@magma.ca) Received: from mail1.magma.ca (mail1.internal.magma.ca [10.0.10.11]) by mx4-1.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id kB12WMPW016016; Thu, 30 Nov 2006 21:32:22 -0500 Received: from [206.191.1.159] (ottawa-dial-206-191-1-159.d-ip.magma.ca [206.191.1.159]) (authenticated bits=0) by mail1.magma.ca (Magma's Mail Server) with ESMTP id kB12WG23018343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 30 Nov 2006 21:32:20 -0500 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0E37A1C5@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF0E37A1C5@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT Date: Thu, 30 Nov 2006 21:32:03 -0500 To: "Francois Audet" 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: f60d0f7806b0c40781eee6b9cd0b2135 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 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. >>> >>> >>> _______________________________________________ >>> 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