From behave-bounces@ietf.org Thu Feb 01 03:35:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCXOj-0007IQ-90; Thu, 01 Feb 2007 03:34:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCXOi-0007II-4d for behave@ietf.org; Thu, 01 Feb 2007 03:34:24 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCXOf-0001gr-KW for behave@ietf.org; Thu, 01 Feb 2007 03:34:24 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l118WBjr007526 for ; Thu, 1 Feb 2007 10:32:19 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 10:33:49 +0200 Received: from esdhcp042186.research.nokia.com ([172.21.42.186]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 1 Feb 2007 10:34:04 +0200 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia-NRC Helsinki To: behave@ietf.org Date: Thu, 1 Feb 2007 10:34:55 +0200 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200702011034.56329.Remi.Denis-Courmont@nokia.com> X-OriginalArrivalTime: 01 Feb 2007 08:34:04.0147 (UTC) FILETIME=[BB099430:01C745DB] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070201103219-1D222BB0-5509313C/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Subject: [BEHAVE] Simplifying TURN/UDP destination handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hello, Currently, TURN requires a time-dependant state machine to handle Set Activ= e=20 Destination (SAD). =46irst, some of the requirements there do not seem to be really required: = e.g.,=20 why forbid the client from sending multile different SAD within the 5 secon= ds=20 delay? Any sane TURN client implementation will not send multiple confilcti= ng=20 SAD if it risks wreaking havoc to its allocation, and any insane=20 implementation has dozens of ways to screw itself up whatever we do. But in fact, it seems to me that this can never be fully sorted out anyhow,= =20 because there will always be corner-case packet loss issues. So the question is, do we really need to send SAD at all? I would expect=20 TURN-enabled applications to integrate in a way that is similar to the BSD= =20 socket API. Also, looking at typical UDP protocols, I do not see much use f= or=20 SAD. Scenarios I can realistically think of: 1/ Server or otherwise one-to-all That would cover ICE in the probing phase, or TEREDO, or any server-typeof= =20 protocol. TURN currently forbids this use case anyway. I can understand some people do not want this to happen: =2D because of policy constraints, and/or =2D to protect last-mile link fro being flooded It would still be interesting to conditionnaly allow this because: =2D it saves the server the need to maintain the access list if the client= =20 wishes not to use it, and policy does not mandate it either, =2D it improves support for ICE-type-of things if the "other side" does not= =20 support TURN, and runs behind a symmetric NAT: by allowing this, the TURN=20 allocation would mimic a full-cone NAT; symmetric-to-full-cone traversal=20 works, while symmetric-to-restricted traversal does not. This scenario is equivalent to socket/bind/sendto/recvfrom/close in socket = API=20 terms. Because the destination will keep changing, SAD is unusable anyway a= nd=20 Send Indication must always be used instead. 2/ One-to-many Like 1, but TURN still maintain the access list based on Send Indication. T= his=20 will be used instead of 1 when the access list is required for whatever=20 reasons. 3/ Client-to-server or otherwise one-to-one That covers SIP and RTSP (and DNS but you don't want to do DNS on TURN)=20 clients. This is socket/bind/connect/send/recv/close in socket API terms. It is also possible to go from scenarios 1or2 to scenario 3 through a ONE-T= IME=20 Set Destination, which could probably be merged with Connect. Once this is= =20 done, traffic from other peers is dropped and server can stop putting the=20 remote address in data messages. =2D-=20 R=C3=A9mi Denis-Courmont Research Engineer _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Feb 01 12:22:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCfd6-0005kz-GH; Thu, 01 Feb 2007 12:21:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCfd5-0005kA-16 for behave@ietf.org; Thu, 01 Feb 2007 12:21:47 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCfcx-00019d-Dh for behave@ietf.org; Thu, 01 Feb 2007 12:21:47 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 01 Feb 2007 09:21:38 -0800 X-IronPort-AV: i="4.13,268,1167638400"; d="scan'208"; a="36629685:sNHT51825195" 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 l11HLcIT017284; Thu, 1 Feb 2007 09:21:38 -0800 Received: from dwingwxp ([10.32.240.194]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l11HLbnF005559; Thu, 1 Feb 2007 09:21:38 -0800 (PST) From: "Dan Wing" To: "'Alfred E. Heggestad'" Subject: RE: [BEHAVE] Difference between STUN Binding Discovery and NAT Keepalive Date: Thu, 1 Feb 2007 09:21:34 -0800 Message-ID: <00f001c74625$6cef60f0$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <45C11A4D.5010208@db.org> Thread-Index: AcdFiFZaWiKd5iUPT2yU/ush4/pI9gAmm2zg DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5915; t=1170350498; x=1171214498; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20Difference=20between=20STUN=20Binding=20Di scovery=20and=20NAT=20Keepalive |Sender:=20; bh=qPGUCd60f5m3+eKmuP4+3ynQ3gMW9vLLC1O8gtmq0Bc=; b=OBKMn25zgTCmyUEu2AsvlFUf6woCPpL4zzdo08buv5SH2W/LkLaGHWC283uB6SbTsKBv+sBZ STEDUxiM7i9AqehDVnS6Zw/7t1hS8rPUvKsGQErV+MCv6CvFQSfVO4eV; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 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 nuance with NAT Keepalive is that in the most recent version > > of ICE (draft-ietf-mmusic-ice-13.txt), the NAT keepalive used > > in ICE was changed from a Binding Discovery / Binding Response > > exchange to an Indication. The Indication is a unidirectional > > STUN message, which has no response. > > > > draft-ietf-behave-rfc3489bis has not yet been updated to align > > with this change to draft-ietf-mmusic-ice-13. > > > > ah, ok. is unidirectional STUN indication (sent from UA) guaranteed > to work with all types of NAT boxes ? is it not so that certain > NATs assume bidirectional traffic to keep the flow open? Traffic from inside->outside is sufficient to keep the binding active. This means that if two ICE-aware endpoints are behind their own respective NATs, they'll both need to transmit STUN Indication keepalives to keep their own respective NAT bindings open (or, of course, send RTP or RTCP packets). > will STUN Binding Indication be a new STUN message in rfc3489bis-06 ? (They're just called "Indications", not "Binding Indications") Indications are mentioned in the existing -05 specification, but it says that only TURN uses Indications (because rfc3489bis hasn't been updated to reflect ICE-13's new use of Indication for ICE's keepalive): http://tools.ietf.org/html/draft-ietf-behave-rfc3489bis-05#section-7.2 ... > I am not concerned about the message integrity, I am mainly > trying to understand why Binding Discover and NAT Keepalive > usage cant be just one usage (i.e. the same) instead of two > usages that are protocol-wise very similar .. It's an attempt to reduce confusion. In sip-outbound, the STUN protocol is not used to discover your initial binding; the STUN protocol is only used to keep an existing binding alive and to detect when a re-Register is needed (that is, when your initial binding changed). I'd say sip-outbound's usage of the STUN protocol does a little of both; it doesn't fit cleanly into 'keepalive' nor 'binding discovery'. The usages, as separated in rfc3489bis, are intended to ease implementation of a STUN client and server so that you know which STUN message types to support (Binding Request/Response, Indications, etc.), and which STUN attributes you need to support. Perhaps they're failing at their intended purpose; I don't see a better way to split things up but I'm open to suggestions. > >> From rfc3489-bis05: > >> > >> > >> 12.2.7. Client Procedures > >> > >> If the STUN Response indicates the client's mapped address has > >> changed from the client's expected mapped address, the > >> client SHOULD > >> inform other applications of its new mapped address. For > >> example, a > >> SIP client could use the binding discovery usage to > obtain a new > >> mapped address, and then register it using SIP registration > >> procedures. > >> > >> > >> This scenario will not work for symmetrical NATs. > > > > It will work if the STUN Binding Request is sent to the same > > port as all SIP traffic (UDP/5060), and demultiplexed by the > > SIP proxy. > > > > yes. so the new section in rfc3489-bis05 12.2 NAT Keepalives is > mainly a tool for outbound, and should go to UDP/5060 ? Yes. Outbound should reference this section of rfc3489bis explicitly (that is, by section number). > but section 12.2.7 says "...SIP client could use the *binding > discovery* usage to obtain..." Yeah, that's wrong, as outbound doesn't do that. I believe in some earlier version of outbound we did think it might be useful to first do a STUN Binding Request in order to populate the Contact header correctly, but that was deemed unnecessary and isn't in the last few versions of outbound (it may have never made it into the text and was just a hallway conversation, I don't recall exactly now). > - why recommend that the client has to send a > new STUN Binding Request, when the client at the same to > has just got the new publicly mapped address:port from > the current NAT Keepalive Binding Response ? According to outbound, the first packet you send to UDP/5060 is a SIP Register, though, right? It's only to keep the binding alive (and to learn of a new NAT binding) do you occasionally send a STUN Binding Request packet to UDP/5060 every NNN seconds. > >> Typically in my UA one usage will be enough, periodically > >> sending STUN > >> Binding Request messages to the SIP server, to get the > >> publicly mapped > >> address:port AND keep the flow alive. > > > > I just searched draft-ietf-sip-outbound-07, and can't find where > > it is necessary for the SIP UA to learn its public IP address and > > UDP port. That is, other than learning that it *changed* (which > > it can learn via the periodic keepalives), it seems that > > draft-ietf-sip-outbound-07 doesn't say the SIP UA needs to > > learn its public transport address using STUN. It's not > > necessary, anyway -- the SIP proxy knows the transport address > > of an incoming UDP packet when the SIP proxy receives the packet. > > ok, it was my assumption that the publicly mapped address from > the STUN Binding Response was used to updated the Via: and Contact: > headers of the SIP UA. But you are right; the SIP proxy knows > where the SIP message came from. > > should we ask the outbound people if this could be clarified? Absolutely. > so can we conclude with the following statement (simplified): > > port 3478: STUN Binding Discovery > port 5060: SIP and STUN Keepalive If you're only thinking of SIP-Outbound, there isn't a need at all for a STUN server listening on UDP/3478. It's only needed for ICE. -d > > > many thanks for your clarifications, I think things are bit > clearer now .. > > /alfred > > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Feb 01 17:24:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCkL4-0004Vx-09; Thu, 01 Feb 2007 17:23:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCkL2-0004Vh-HU for behave@ietf.org; Thu, 01 Feb 2007 17:23:28 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCkL0-0005NY-5L for behave@ietf.org; Thu, 01 Feb 2007 17:23:28 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 01 Feb 2007 14:23:25 -0800 X-IronPort-AV: i="4.13,269,1167638400"; d="scan'208"; a="36737512:sNHT45768330" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l11MNPAn016522 for ; Thu, 1 Feb 2007 14:23:25 -0800 Received: from dwingwxp ([10.32.240.194]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l11MNOho015423 for ; Thu, 1 Feb 2007 14:23:24 -0800 (PST) From: "Dan Wing" To: Date: Thu, 1 Feb 2007 14:23:24 -0800 Message-ID: <038701c7464f$971e6220$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdFp2M60KshxoulSiCoMbhYuqT93wAp/lUw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3429; t=1170368605; x=1171232605; c=relaxed/simple; s=sjdkim6002; 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:=20RFC=204787=20on=20Network=20Address=20Translation=20(NAT)=20B ehavioral=20Requirements=20for=20Unicast=20UDP |Sender:=20; bh=NXITADt42yqJPU47JavLGJsOR/p3TZqswkub6mV2WEg=; b=fan7MTEVpCDJas+KHKpbizGEYQxDFxvcnvoi1t+0vJrhOX3LhM/+5Nr/u2QS3z5cPkD6W4Dn ABM2URP1Zj/kin5DakCb03ZYka5X1sqwCEmvOTqNc8nGZMbriw3FVOlA; Authentication-Results: sj-dkim-6; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Subject: [BEHAVE] RFC 4787 on Network Address Translation (NAT) Behavioral Requirements for Unicast UDP X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 to everyones efforts, BEHAVE has published its first document! -d > -----Original Message----- > From: rfc-editor@rfc-editor.org [mailto:rfc-editor@rfc-editor.org] > Sent: Wednesday, January 31, 2007 6:18 PM > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: behave@ietf.org; rfc-editor@rfc-editor.org > Subject: [BEHAVE] BCP 127 RFC 4787 on Network Address > Translation (NAT)Behavioral Requirements for Unicast UDP > > > A new Request for Comments is now available in online RFC libraries. > > BCP 127 > RFC 4787 > > Title: Network Address Translation (NAT) Behavioral > Requirements for Unicast UDP > Author: F. Audet, Ed., > C. Jennings > Status: Best Current Practice > Date: January 2007 > Mailbox: audet@nortel.com, > fluffy@cisco.com > Pages: 29 > Characters: 68693 > Updates: > See-Also: BCP0127 > > I-D Tag: draft-ietf-behave-nat-udp-08.txt > > URL: http://www.rfc-editor.org/rfc/rfc4787.txt > > This document defines basic terminology for describing different > types of Network Address Translation (NAT) behavior when handling > Unicast UDP and also defines a set of requirements that would allow > many applications, such as multimedia communications or online > gaming, to work consistently. Developing NATs that meet this set of > requirements will greatly increase the likelihood that these > applications will function properly. This document specifies > an Internet > Best Current Practices for the Internet Community, and requests > discussion and suggestions for improvements. > > This document is a product of the Behavior Engineering for Hindrance > Avoidance Working Group of the IETF. > > BEST CURRENT PRACTICE: > This document specifies an Internet Best Current Practices for the > Internet Community, and requests discussion and suggestions for > improvements. Distribution of this memo is unlimited. > > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > > help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to > RFC-Manager@RFC-EDITOR.ORG. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > Submissions for Requests for Comments should be sent to > RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, > Instructions to RFC > Authors, for further information. > > > The RFC Editor Team > USC/Information Sciences Institute > > ... > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > 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 Feb 01 18:06:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCl03-0004jN-2p; Thu, 01 Feb 2007 18:05:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCl01-0004ib-Sy for behave@ietf.org; Thu, 01 Feb 2007 18:05:49 -0500 Received: from celine.siteprotect.com ([64.26.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCl00-0005zh-L3 for behave@ietf.org; Thu, 01 Feb 2007 18:05:49 -0500 Received: from [192.168.1.102] (c-24-9-79-73.hsd1.co.comcast.net [24.9.79.73]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id l11N5jP32604 for ; Thu, 1 Feb 2007 17:05:45 -0600 Message-ID: <45C27246.2050109@cornfed.com> Date: Thu, 01 Feb 2007 16:05:42 -0700 From: "Frank W. Miller" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [BEHAVE] Outbound and SPI X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 ran into an interesting problem today while testing with a user. While multiplexing STUN over the SIP port, it became apparent that the Stateful Packet Inspection (SPI) in a very popular widely sold NAT/Firewall router that shall remain nameless was blocking the SIP responses. Won't such behaviour be a problem for the outbound draft that calls for this multiplexing too. Has anyone else seen this behavior? It appears that the router wants STUN on the STUN port and SIP on the SIP port. What do we do about this wrt multiplexing? Thanks, FM _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Feb 01 18:29:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HClM5-0007a3-8X; Thu, 01 Feb 2007 18:28:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HClM3-0007RU-Cs; Thu, 01 Feb 2007 18:28:35 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HClM0-0003h2-VC; Thu, 01 Feb 2007 18:28:35 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 01 Feb 2007 15:28:32 -0800 X-IronPort-AV: i="4.13,269,1167638400"; d="scan'208"; a="36745994:sNHT47889855" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l11NSWcs009630; Thu, 1 Feb 2007 15:28:32 -0800 Received: from dwingwxp ([10.32.240.194]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l11NSRho008785; Thu, 1 Feb 2007 15:28:27 -0800 (PST) From: "Dan Wing" To: "'Frank W. Miller'" , Subject: RE: [BEHAVE] Outbound and SPI Date: Thu, 1 Feb 2007 15:28:27 -0800 Message-ID: <045c01c74658$af9c9750$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <45C27246.2050109@cornfed.com> Thread-Index: AcdGVd5aD8sZ7j4cQSaaxDvECW+EUQAAYaaw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1939; t=1170372512; x=1171236512; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20Outbound=20and=20SPI |Sender:=20; bh=gTVVDlc66K6mVaXKwo5BC8igVep17ZqbPJ1BqLUqGno=; b=JbU4Ig3eQIchlUTriK3nN7Ul/S7sU3SMc4GgDUl06+0D8Af3kL303JYWigpHurAy0BreEKPs H9ymoF03oaucopNCPXcIcwzKQQ6hP54EWyM3cmgzm3wiWcP1oZJrTM2m; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: sip@ietf.org, 'Rohan Mahy' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org (CC'ing sip and the authors of sip-outbound) That couldn't have been an enjoyable way to have spent a few hours of your day. That NAT isn't compliant with BEHAVE, of course, which requires that such application awareness be turned off for UDP protocols. For exactly this reason! In order to deal with such a NAT with its application layer gateway (SPI) turned on, it might be prudent for sip-outbound to discuss verifying such a middlebox isn't dropping STUN packets on UDP/5060. For example, sip-outbound could encourage a SIP UA to revert to a less appealing keepalive mechanism if the initial STUN Binding Request messages don't result in STUN Binding Response messages. I expect that same SPI would have dropped the PING method, so it might not be useful to choose the PING method as the less-appealing keepalive mechanism. I expect you're stuck with "." or frequent re-Register to get around such a NAT, but I'll leave that for others to decide. -d > -----Original Message----- > From: Frank W. Miller [mailto:fwmiller@cornfed.com] > Sent: Thursday, February 01, 2007 3:06 PM > To: behave@ietf.org > Subject: [BEHAVE] Outbound and SPI > > > I ran into an interesting problem today while testing with a user. > While multiplexing STUN over the SIP port, it became apparent > that the > Stateful Packet Inspection (SPI) in a very popular widely sold > NAT/Firewall router that shall remain nameless was blocking the SIP > responses. Won't such behaviour be a problem for the outbound draft > that calls for this multiplexing too. Has anyone else seen this > behavior? It appears that the router wants STUN on the STUN port and > SIP on the SIP port. What do we do about this wrt multiplexing? > > Thanks, > FM > > > _______________________________________________ > 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 Feb 01 18:46:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HClch-0000x6-Ei; Thu, 01 Feb 2007 18:45:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HClcf-0000x0-Vj for behave@ietf.org; Thu, 01 Feb 2007 18:45:45 -0500 Received: from celine.siteprotect.com ([64.26.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HClce-0006cT-LE for behave@ietf.org; Thu, 01 Feb 2007 18:45:45 -0500 Received: from [192.168.1.102] (c-24-9-79-73.hsd1.co.comcast.net [24.9.79.73]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id l11NjgV04203; Thu, 1 Feb 2007 17:45:42 -0600 Message-ID: <45C27BA4.6000008@cornfed.com> Date: Thu, 01 Feb 2007 16:45:40 -0700 From: "Frank W. Miller" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Dan Wing Subject: Re: [Sip] RE: [BEHAVE] Outbound and SPI References: <045c01c74658$af9c9750$c2f0200a@amer.cisco.com> In-Reply-To: <045c01c74658$af9c9750$c2f0200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: 'Rohan Mahy' , 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'm interested in the responses from others. I will say this quickly. I suggested just turning it off but the user I was working with has a static IP address and therefore considers SPI very important as a mechanism to deny DoS attacks. I am wondering whether disallowing SPI for UDP is going to be realistic? Again, this is a very widely available NAT router that come with SPI turned on by default it appears. I also checked whether the router was tested in the draft you mentioned and its not best as I read the draft. I'll cc you personally with the specific router equipment if you're interested. I just don't think its fair to name equipment makers on the public list. Thanks, FM Dan Wing wrote: > (CC'ing sip and the authors of sip-outbound) > > That couldn't have been an enjoyable way to have spent a few hours of your > day. That NAT isn't compliant with BEHAVE, of course, which requires that > such application awareness be turned off for UDP protocols. For exactly > this reason! > > In order to deal with such a NAT with its application layer gateway (SPI) > turned on, it might be prudent for sip-outbound to discuss verifying such a > middlebox isn't dropping STUN packets on UDP/5060. For example, > sip-outbound could encourage a SIP UA to revert to a less appealing > keepalive mechanism if the initial STUN Binding Request messages don't > result in STUN Binding Response messages. > > I expect that same SPI would have dropped the PING method, so it might not > be useful to choose the PING method as the less-appealing keepalive > mechanism. I expect you're stuck with "." or frequent re-Register > to get around such a NAT, but I'll leave that for others to decide. > > -d > > > >> -----Original Message----- >> From: Frank W. Miller [mailto:fwmiller@cornfed.com] >> Sent: Thursday, February 01, 2007 3:06 PM >> To: behave@ietf.org >> Subject: [BEHAVE] Outbound and SPI >> >> >> I ran into an interesting problem today while testing with a user. >> While multiplexing STUN over the SIP port, it became apparent >> that the >> Stateful Packet Inspection (SPI) in a very popular widely sold >> NAT/Firewall router that shall remain nameless was blocking the SIP >> responses. Won't such behaviour be a problem for the outbound draft >> that calls for this multiplexing too. Has anyone else seen this >> behavior? It appears that the router wants STUN on the STUN port and >> SIP on the SIP port. What do we do about this wrt multiplexing? >> >> Thanks, >> FM >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 02 08:33:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCyX6-0005mq-KH; Fri, 02 Feb 2007 08:32:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCyX5-0005mO-Lc for behave@ietf.org; Fri, 02 Feb 2007 08:32:51 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCyX3-0000zz-7A for behave@ietf.org; Fri, 02 Feb 2007 08:32:51 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l12DTfVo012941 for ; Fri, 2 Feb 2007 15:29:54 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 15:32:23 +0200 Received: from esdhcp043137.research.nokia.com ([172.21.43.137]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 2 Feb 2007 15:32:22 +0200 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia-TP-MSW Helsinki To: behave@ietf.org Date: Fri, 2 Feb 2007 15:33:54 +0200 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200702021533.54820.Remi.Denis-Courmont@nokia.com> X-OriginalArrivalTime: 02 Feb 2007 13:32:22.0526 (UTC) FILETIME=[91B739E0:01C746CE] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070202152954-32845BB0-22D47EB1/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [BEHAVE] draft-wing-behave-nat-control-stun-usage legacy interaction X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hello, As far as I understand draft-wing-behave-nat-control-stun-usage-00, it is=20 proposed that STUN clients could try to probe the NAT by sending a STUN=20 request to the NAT external IP address as learnt from the STUN server=20 response. Interesting idea. However, while I certainly hope it does not actually happen, as anyone chec= ked=20 that this does not trigger non-deterministic behaviors in legacy NATs, whic= h=20 could then make the NAT traversal more difficult in the end? Note: I have not observed this behavior myself (but then again I did not te= st=20 it at all ;) ). =2D-=20 R=C3=A9mi Denis-Courmont Research Engineer _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 02 10:46:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD0bd-0006I6-BP; Fri, 02 Feb 2007 10:45:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD0bc-0006Ev-T4 for behave@ietf.org; Fri, 02 Feb 2007 10:45:40 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD0bb-0002Qh-E8 for behave@ietf.org; Fri, 02 Feb 2007 10:45:40 -0500 Received: from [131.161.248.91] (open-131-161-248-91.cliq.com [131.161.248.91]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l12FiI203970; Fri, 2 Feb 2007 07:44:18 -0800 In-Reply-To: <45C27BA4.6000008@cornfed.com> References: <045c01c74658$af9c9750$c2f0200a@amer.cisco.com> <45C27BA4.6000008@cornfed.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5868c34c015879e03151ac5c3ad8b889@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] RE: [BEHAVE] Outbound and SPI Date: Fri, 2 Feb 2007 07:44:23 -0800 To: "Frank W. Miller" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Rohan Mahy , behave@ietf.org, Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Frank, I'm curious if this product interferes with SIP over TCP traffic. Did you try this out by any chance? thanks, -rohan On Feb 1, 2007, at 15:45, Frank W. Miller wrote: > I'm interested in the responses from others. I will say this quickly. > I suggested just turning it off but the user I was working with has a > static IP address and therefore considers SPI very important as a > mechanism to deny DoS attacks. I am wondering whether disallowing SPI > for UDP is going to be realistic? > > Again, this is a very widely available NAT router that come with SPI > turned on by default it appears. I also checked whether the router > was tested in the draft you mentioned and its not best as I read the > draft. I'll cc you personally with the specific router equipment if > you're interested. I just don't think its fair to name equipment > makers on the public list. > > Thanks, > FM > > > Dan Wing wrote: >> (CC'ing sip and the authors of sip-outbound) >> >> That couldn't have been an enjoyable way to have spent a few hours of >> your >> day. That NAT isn't compliant with BEHAVE, of course, which requires >> that >> such application awareness be turned off for UDP protocols. For >> exactly >> this reason! >> >> In order to deal with such a NAT with its application layer gateway >> (SPI) >> turned on, it might be prudent for sip-outbound to discuss verifying >> such a >> middlebox isn't dropping STUN packets on UDP/5060. For example, >> sip-outbound could encourage a SIP UA to revert to a less appealing >> keepalive mechanism if the initial STUN Binding Request messages don't >> result in STUN Binding Response messages. >> >> I expect that same SPI would have dropped the PING method, so it >> might not >> be useful to choose the PING method as the less-appealing keepalive >> mechanism. I expect you're stuck with "." or frequent >> re-Register >> to get around such a NAT, but I'll leave that for others to decide. >> >> -d >> >> >> >>> -----Original Message----- >>> From: Frank W. Miller [mailto:fwmiller@cornfed.com] Sent: Thursday, >>> February 01, 2007 3:06 PM >>> To: behave@ietf.org >>> Subject: [BEHAVE] Outbound and SPI >>> >>> >>> I ran into an interesting problem today while testing with a user. >>> While multiplexing STUN over the SIP port, it became apparent that >>> the Stateful Packet Inspection (SPI) in a very popular widely sold >>> NAT/Firewall router that shall remain nameless was blocking the SIP >>> responses. Won't such behaviour be a problem for the outbound draft >>> that calls for this multiplexing too. Has anyone else seen this >>> behavior? It appears that the router wants STUN on the STUN port >>> and SIP on the SIP port. What do we do about this wrt multiplexing? >>> >>> Thanks, >>> FM >>> >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www1.ietf.org/mailman/listinfo/behave >>> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> >> _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 02 10:55:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD0l5-0005QZ-0d; Fri, 02 Feb 2007 10:55:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD0l4-0005QO-2v for behave@ietf.org; Fri, 02 Feb 2007 10:55:26 -0500 Received: from celine.siteprotect.com ([64.26.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD0l0-0003xu-9t for behave@ietf.org; Fri, 02 Feb 2007 10:55:26 -0500 Received: from [192.168.1.102] (c-24-9-79-73.hsd1.co.comcast.net [24.9.79.73]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id l12FsFC11781; Fri, 2 Feb 2007 09:54:15 -0600 Message-ID: <45C35EA5.9030309@cornfed.com> Date: Fri, 02 Feb 2007 08:54:13 -0700 From: "Frank W. Miller" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Sip] RE: [BEHAVE] Outbound and SPI References: <045c01c74658$af9c9750$c2f0200a@amer.cisco.com> <45C27BA4.6000008@cornfed.com> <5868c34c015879e03151ac5c3ad8b889@ekabal.com> In-Reply-To: <5868c34c015879e03151ac5c3ad8b889@ekabal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: behave@ietf.org, Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Uh, new client, don't have TCP transport in yet. Fortunately, the user is someone I know so I'll be able to test it once its in. FM Rohan Mahy wrote: > Frank, > > I'm curious if this product interferes with SIP over TCP traffic. Did > you try this out by any chance? > > thanks, > -rohan > > On Feb 1, 2007, at 15:45, Frank W. Miller wrote: >> I'm interested in the responses from others. I will say this >> quickly. I suggested just turning it off but the user I was working >> with has a static IP address and therefore considers SPI very >> important as a mechanism to deny DoS attacks. I am wondering whether >> disallowing SPI for UDP is going to be realistic? >> >> Again, this is a very widely available NAT router that come with SPI >> turned on by default it appears. I also checked whether the router >> was tested in the draft you mentioned and its not best as I read the >> draft. I'll cc you personally with the specific router equipment if >> you're interested. I just don't think its fair to name equipment >> makers on the public list. >> >> Thanks, >> FM >> >> >> Dan Wing wrote: >>> (CC'ing sip and the authors of sip-outbound) >>> >>> That couldn't have been an enjoyable way to have spent a few hours >>> of your >>> day. That NAT isn't compliant with BEHAVE, of course, which >>> requires that >>> such application awareness be turned off for UDP protocols. For >>> exactly >>> this reason! >>> >>> In order to deal with such a NAT with its application layer gateway >>> (SPI) >>> turned on, it might be prudent for sip-outbound to discuss verifying >>> such a >>> middlebox isn't dropping STUN packets on UDP/5060. For example, >>> sip-outbound could encourage a SIP UA to revert to a less appealing >>> keepalive mechanism if the initial STUN Binding Request messages don't >>> result in STUN Binding Response messages. >>> >>> I expect that same SPI would have dropped the PING method, so it >>> might not >>> be useful to choose the PING method as the less-appealing keepalive >>> mechanism. I expect you're stuck with "." or frequent >>> re-Register >>> to get around such a NAT, but I'll leave that for others to decide. >>> >>> -d >>> >>> >>> >>>> -----Original Message----- >>>> From: Frank W. Miller [mailto:fwmiller@cornfed.com] Sent: Thursday, >>>> February 01, 2007 3:06 PM >>>> To: behave@ietf.org >>>> Subject: [BEHAVE] Outbound and SPI >>>> >>>> >>>> I ran into an interesting problem today while testing with a user. >>>> While multiplexing STUN over the SIP port, it became apparent that >>>> the Stateful Packet Inspection (SPI) in a very popular widely sold >>>> NAT/Firewall router that shall remain nameless was blocking the SIP >>>> responses. Won't such behaviour be a problem for the outbound >>>> draft that calls for this multiplexing too. Has anyone else seen >>>> this behavior? It appears that the router wants STUN on the STUN >>>> port and SIP on the SIP port. What do we do about this wrt >>>> multiplexing? >>>> >>>> Thanks, >>>> FM >>>> >>>> >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/behave >>>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >>> > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 02 17:07:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD6YU-0006pM-HC; Fri, 02 Feb 2007 17:06:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD6YU-0006nN-3u for behave@ietf.org; Fri, 02 Feb 2007 17:06:50 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD6YS-0007mS-LQ for behave@ietf.org; Fri, 02 Feb 2007 17:06:50 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 02 Feb 2007 14:06:48 -0800 X-IronPort-AV: i="4.13,274,1167638400"; d="scan'208"; a="385264894:sNHT52309000" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l12M6irE015541; Fri, 2 Feb 2007 14:06:44 -0800 Received: from dwingwxp (dhcp-128-107-163-186.cisco.com [128.107.163.186]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l12M6knF002201; Fri, 2 Feb 2007 14:06:46 -0800 (PST) From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Denis-Courmont'?=" , Subject: RE: [BEHAVE] draft-wing-behave-nat-control-stun-usage legacy interaction Date: Fri, 2 Feb 2007 14:06:47 -0800 Message-ID: <079501c74716$6eb644c0$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <200702021533.54820.Remi.Denis-Courmont@nokia.com> Thread-Index: AcdGztTB7hllI+q6T3qz3cSzXDJs8gARjy9w DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4203; t=1170454004; x=1171318004; c=relaxed/simple; s=sjdkim6002; 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]=20draft-wing-behave-nat-control-stun-usage=2 0legacy=20interaction |Sender:=20; bh=GHXw3jnJTLDoR8Te61meI1NGxZVjB+oe+r72I0xDI0c=; b=JfYIYADVMjLHuM/QTeL5P/mcsvz9/V9+j6UiBHxNL/yJ4ThbUGVeiuMbSK80jgvomviV6JyV Xj2oD3krbCFR5wLnB9iys6223PfvYy+tcIWnt70npHg74ryYp0d9PLcw; Authentication-Results: sj-dkim-6; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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 A good question. However, in order to thwart the attack described in http://tools.ietf.org/html/draft-wing-behave-nat-control-stun-usage-00#se= cti on-6.3 of the current document, the STUN client needs to first = communicate with its outer-most NAT using TLS to obtain a STUN shared secret. The attack is this (from the link above): As described in Section 4, a STUN client can learn its outer-most NAT runs an embedded STUN server. Without the STUN client's knowledge, the outer-most NAT may acquire a new IP address (after moving to a new mobile network or DHCP lease expiration). When it acquires a new IP address, the STUN client will send a STUN Binding Request to the NAT's prior public IP address. If an attacker acquires that public IP address and installs a rogue STUN server, the attacker has effectively acheived the attack "Compromise a Legitimate STUN Server" (section 12.2.1 of [RFC3489]). The attacker will send STUN Binding Responses indicating his IP address, which will be indistingushable, to the STUN client, from the behavior of the legitimate STUN server. To defend against this attack, the STUN client and STUN server need to obtain a short-term password as described in [I-D.ietf-behave-rfc3489bis]. Perhaps that attack isn't bothersome to most people; I don't know. = Feedback on this would be useful. Many small NATs have TLS support for their = HTTPS management interface, so TLS isn't onerous. =20 Another idea I have had to thwart this specific attack is to have the = NAT to return a random number that is static for the duration of the NAT's operation (that is, it changes when the NAT crashes). So, you would = learn your NAT's public IP address, then send it a binding request (without = first doing a shared secret request). The NAT would return a binding = response, the XOR-INTERNAL-ADDRESS, and also return a new attribute with a random number in it. You could then use your NAT's built-in STUN server = forever more, so long as it returned that same attribute with that same random number. When that random number changed, you would talk to your STUN = server on the public Internet. This is more lightweight than TLS and TCP, but = I haven't convinced myself it completely protects against someone else acquiring the NAT's public IP address (through DHCP lease expiration or through Mobile IP address reassignment, for example). But with the current functionality as described in -00, because you need = to talk to your NAT's public IP address using TCP first, the NAT Control = STUN Usage should be very unlikely to trigger unexpected NAT behavior. I am adjusting the next version of the document so the necessary steps = are clear. I see that in -00's Overview of Operation section, the need to = first get a shared secret isn't spelled out. The client procedure (section = 3.6) does describe it, though. That was an oversight on my part, my = apologies. -d =20 > -----Original Message----- > From: R=E9mi Denis-Courmont [mailto:Remi.Denis-Courmont@nokia.com]=20 > Sent: Friday, February 02, 2007 5:34 AM > To: behave@ietf.org > Subject: [BEHAVE] draft-wing-behave-nat-control-stun-usage=20 > legacy interaction >=20 > Hello, >=20 > As far as I understand=20 > draft-wing-behave-nat-control-stun-usage-00, it is=20 > proposed that STUN clients could try to probe the NAT by=20 > sending a STUN=20 > request to the NAT external IP address as learnt from the STUN server=20 > response. Interesting idea. >=20 > However, while I certainly hope it does not actually happen,=20 > as anyone checked=20 > that this does not trigger non-deterministic behaviors in=20 > legacy NATs, which=20 > could then make the NAT traversal more difficult in the end? >=20 > Note: I have not observed this behavior myself (but then=20 > again I did not test=20 > it at all ;) ). >=20 > --=20 > R=E9mi Denis-Courmont > Research Engineer >=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 Sun Feb 04 19:26:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDrg7-00072p-1U; Sun, 04 Feb 2007 19:25:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDrg6-00072j-50 for behave@ietf.org; Sun, 04 Feb 2007 19:25:50 -0500 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDrg2-0005H4-RM for behave@ietf.org; Sun, 04 Feb 2007 19:25:50 -0500 Date: Sun, 4 Feb 2007 19:25:44 -0500 Message-Id: <10702041925.AA24043@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "Patrick Timmons" To: behave@ietf.org X-Mailer: Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [BEHAVE] automated response X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Reply-To: ptimmons@acmepacket.com List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org IMPORTANT NOTE: if you are receiving this auto responder after accessing Acme Packet's web portal or sending an email to a mailing list, rest assured that your message has been received and will be acted upon by the appropriate personnel. I am taking Friday, February 2 through Tuesday, February 6 off and will be mostly unavailable during this time. I will not have access to a computer, but will be reachable via my cell phone in the event of emergencies. For support issues, please contact support@acmepacket.com. For non-support issues, please contact Erin Medeiros, Vice President of Professional Services, at emedeiros@acmepacket.com. Thank you, Patrick Timmons Vice President, Systems Engineering Acme Packet, Inc. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Feb 04 19:26:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDrfY-0006w6-Ir; Sun, 04 Feb 2007 19:25:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDrfX-0006vs-3d for behave@ietf.org; Sun, 04 Feb 2007 19:25:15 -0500 Received: from wx-out-0506.google.com ([66.249.82.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDrfW-000518-Hy for behave@ietf.org; Sun, 04 Feb 2007 19:25:15 -0500 Received: by wx-out-0506.google.com with SMTP id h31so1451719wxd for ; Sun, 04 Feb 2007 16:25:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=XaGh8eoulnb0g09BZD/lx5JLqhIwb2RySyoe1IrCNWp4Qrgx9cP8S7m6l0xjkE+CRHnh7fm/yUlSdnhIDu1qTb8r35DMJavfxmMm2z76eXCBiEzLl/it50mBdAA6MKoW5znNG6I2AMSYjHQLX7PHmLGN44203xsPj+ibuZkr69c= Received: by 10.70.57.2 with SMTP id f2mr11144322wxa.1170635113668; Sun, 04 Feb 2007 16:25:13 -0800 (PST) Received: by 10.70.131.16 with HTTP; Sun, 4 Feb 2007 16:25:13 -0800 (PST) Message-ID: <953beacc0702041625q1d1f600bwbb64dc40ff1a3cf@mail.gmail.com> Date: Sun, 4 Feb 2007 16:25:13 -0800 From: "Rohan Mahy" To: behave@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: Rohan Mahy Subject: [BEHAVE] READ and COMMENT: Re: TURN major issues and proFrom behave-bounces@ietf.org Sun Feb 04 19:26:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDrg7-00072p-1U; Sun, 04 Feb 2007 19:25:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDrg6-00072j-50 for behave@ietf.org; Sun, 04 Feb 2007 19:25:50 -0500 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDrg2-0005H4-RM for behave@ietf.org; Sun, 04 Feb 2007 19:25:50 -0500 Date: Sun, 4 Feb 2007 19:25:44 -0500 Message-Id: <10702041925.AA24043@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "Patrick Timmons" To: behave@ietf.org X-Mailer: Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [BEHAVE] automated response X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Reply-To: ptimmons@acmepacket.com List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org IMPORTANT NOTE: if you are receiving this auto responder after accessing Acme Packet's web portal or sending an email to a mailing list, rest assured that your message has been received and will be acted upon by the appropriate personnel. I am taking Friday, February 2 through Tuesday, February 6 off and will be mostly unavailable during this time. I will not have access to a computer, but will be reachable via my cell phone in the event of emergencies. For support issues, please contact support@acmepacket.com. For non-support issues, please contact Erin Medeiros, Vice President of Professional Services, at emedeiros@acmepacket.com. Thank you, Patrick Timmons Vice President, Systems Engineering Acme Packet, Inc. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Feb 04 19:26:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDrfY-0006w6-Ir; Sun, 04 Feb 2007 19:25:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDrfX-0006vs-3d for behave@ietf.org; Sun, 04 Feb 2007 19:25:15 -0500 Received: from wx-out-0506.google.com ([66.249.82.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDrfW-000518-Hy for behave@ietf.org; Sun, 04 Feb 2007 19:25:15 -0500 Received: by wx-out-0506.google.com with SMTP id h31so1451719wxd for ; Sun, 04 Feb 2007 16:25:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=XaGh8eoulnb0g09BZD/lx5JLqhIwb2RySyoe1IrCNWp4Qrgx9cP8S7m6l0xjkE+CRHnh7fm/yUlSdnhIDu1qTb8r35DMJavfxmMm2z76eXCBiEzLl/it50mBdAA6MKoW5znNG6I2AMSYjHQLX7PHmLGN44203xsPj+ibuZkr69c= Received: by 10.70.57.2 with SMTP id f2mr11144322wxa.1170635113668; Sun, 04 Feb 2007 16:25:13 -0800 (PST) Received: by 10.70.131.16 with HTTP; Sun, 4 Feb 2007 16:25:13 -0800 (PST) Message-ID: <953beacc0702041625q1d1f600bwbb64dc40ff1a3cf@mail.gmail.com> Date: Sun, 4 Feb 2007 16:25:13 -0800 From: "Rohan Mahy" To: behave@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: Rohan Mahy Subject: [BEHAVE] READ and COMMENT: Re: TURN major issues and proposed fixes X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 Folks, To date, I have only received two comments on the proposals in this email. There a bunch of inconsistencies in TURN which I cannot resolve until we come to a consensus about some of the fundamentals I discuss in this email. Please read and send your comments. thanks, -rohan On 1/19/07, Rohan Mahy wrote: > Hi Folks, > > The following issues have all come up from implementors of TURN and > are big enough issues that I wanted to get some list feedback before > incorporating these in a new rev. > > 1. Allocations, Bindings, Permissions, Timeouts, and the Active Destination. > > The current text is still a bit fuzzy and inconsistent about what is a > difference between permission and a binding and what keeps bindings > open. Also, many implementors have expressed confusion between the > behavior of an ordinary NAT binding and a "STUN Relay binding", so I > am proposing we skip the binding terminology in favor of "permission". > Much of the following came from consensus at one of the meetings. I've > come up with the following proposal which fills out a consistent set > of rules: > - Remove the terminology "binding" altogether inside the TURN server. > Only use "binding" when talking about a "real" NAT (ex: between the > TURN client and the TURN server) > - All requests and indications except for initial Allocation requests > are sent in the context of a matching valid allocation, otherwise they > are rejected (requests) or discarded silently (Indications). > - Allocations are explicitly refreshed via subsequent allocation > requests. Allocation timeout values are on the order of minutes. Send > and Data indications do not refresh Allocations. Allocation timers are > based on the LIFETIME attribute. > - Each allocation can have zero or more permissions > - When allocations are destroyed all related permissions are deleted. > - Permissions are only created by Send Indications over UDP and > Connect Requests over TCP. > - Data sent to a peer (via send Indications and unencapsulated data > sent to the active destination) by the TURN client refresh the > relevant permission. Data to one permission does not refresh other > permissions associated with the same binding. > - The expected timeout interval for all permissions for an allocation > is conveyed from the server to the client using the REFRESH-INTERVAL > attribute in an initial successful Allocate Response. > - The active destination is changed only with the Set Active > Destination Request for an allocation. The active destination is > completely independent of any permissions. > > 2. SetActiveDestination should not be limited to existing permissions > Current text in some places says that the active destination needs to > be an existing permission. This is actually unnecessary however, and > loosening this restriction is useful. > Take the case where the TURN client receives a SIP INVITE with an > offer, and the TURN client wishes to accept the offer. The TURN client > should be able to set the active destination immediately before > issuing its first Send request (to this destination). Using this order > of operations insures that the TURN client receives all data traffic > unencapsulated. This provides for more consistent bandwidth usage in > this case. > > The proposal is to change the current text to completely decouple the > active destination from any permissions. A permission controls > whether traffic flows. The active destination controls whether > traffic flowing over a binposed fixes X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 Folks, To date, I have only received two comments on the proposals in this email. There a bunch of inconsistencies in TURN which I cannot resolve until we come to a consensus about some of the fundamentals I discuss in this email. Please read and send your comments. thanks, -rohan On 1/19/07, Rohan Mahy wrote: > Hi Folks, > > The following issues have all come up from implementors of TURN and > are big enough issues that I wanted to get some list feedback before > incorporating these in a new rev. > > 1. Allocations, Bindings, Permissions, Timeouts, and the Active Destination. > > The current text is still a bit fuzzy and inconsistent about what is a > difference between permission and a binding and what keeps bindings > open. Also, many implementors have expressed confusion between the > behavior of an ordinary NAT binding and a "STUN Relay binding", so I > am proposing we skip the binding terminology in favor of "permission". > Much of the following came from consensus at one of the meetings. I've > come up with the following proposal which fills out a consistent set > of rules: > - Remove the terminology "binding" altogether inside the TURN server. > Only use "binding" when talking about a "real" NAT (ex: between the > TURN client and the TURN server) > - All requests and indications except for initial Allocation requests > are sent in the context of a matching valid allocation, otherwise they > are rejected (requests) or discarded silently (Indications). > - Allocations are explicitly refreshed via subsequent allocation > requests. Allocation timeout values are on the order of minutes. Send > and Data indications do not refresh Allocations. Allocation timers are > based on the LIFETIME attribute. > - Each allocation can have zero or more permissions > - When allocations are destroyed all related permissions are deleted. > - Permissions are only created by Send Indications over UDP and > Connect Requests over TCP. > - Data sent to a peer (via send Indications and unencapsulated data > sent to the active destination) by the TURN client refresh the > relevant permission. Data to one permission does not refresh other > permissions associated with the same binding. > - The expected timeout interval for all permissions for an allocation > is conveyed from the server to the client using the REFRESH-INTERVAL > attribute in an initial successful Allocate Response. > - The active destination is changed only with the Set Active > Destination Request for an allocation. The active destination is > completely independent of any permissions. > > 2. SetActiveDestination should not be limited to existing permissions > Current text in some places says that the active destination needs to > be an existing permission. This is actually unnecessary however, and > loosening this restriction is useful. > Take the case where the TURN client receives a SIP INVITE with an > offer, and the TURN client wishes to accept the offer. The TURN client > should be able to set the active destination immediately before > issuing its first Send request (to this destination). Using this order > of operations insures that the TURN client receives all data traffic > unencapsulated. This provides for more consistent bandwidth usage in > this case. > > The proposal is to change the current text to completely decouple the > active destination from any permissions. A permission controls > whether traffic flows. The active destination controls whether > traffic flowing over a binding is encapsulated of not. > > An alternative to this proposal is to create a new permission if no > permission for the active destination exists. The problem is that > this does not result in sending any data to the peer (as described in > the applicability statement and UNSAF considerations), it is > completely implicit behavior, and the opposite operation (clearing the > active destination) does not delete permissions. > > 3. SetActiveDestination changing destinations > > Currently there are several pages of text devoted to a timer based > state machine that needs to be implemented on both the server and the > client to handle the case of switching the active destination from one > address to another. The problem is that over UDP, the client cannot > tell which unencapsulated data is from the old active destination vs. > the new active destination. > > However, requiring timers and a state machine on the server is a > significant implementation burden which provides no benefit for the > TURN server or its administrative domain. > > The proposal is to put this problem completely into the hands of the > client. Some clients may never wish to change the active destination > for example and will have no need to implement anything special. > Those clients that want to change the active destination over UDP are > required to clear the active destination, wait for an appropriate > interval (5 seconds is suggested), then set the active destination to > the new address. > > Specific proposed text for items 2 and 3 and also delete the TIMER-VAL > attribute: > >
>
> > The Set Active Destination address allows the client to create an > optimized relay function between it and the server. When the server > receives packets from a particular preferred external client, the > server will forward those packets towards the client without > encapsulating them in a Data Indication. Similarly, the client can > send non-STUN packets to the server without encapsulation, and these > are forwarded to the external client. Sending and receiving data in > unencapsulated form is critical for efficiency purposes. One of the > primary use cases for the STUN relay usage is in support of Voice over > IP (VoIP), which uses very small UDP packets to begin with. The extra > overhead of an additional layer of encapsulation is considered > unacceptable. > > The Set Active Destination request is used by the client to provide > the identity of this preferred external client. The Set Active > Destination address MAY contain a REMOTE-ADDRESS attribute. This > attribute, when present, provides the address of the preferred > external client to the server. When absent, it clears the value of the > preferred external client. This address has no effect on the existence > of any permissions. > > The client MUST NOT send a Set Active Destination request with a > REMOTE-ADDRESS attribute over an unreliable link (ex: UDP) if an > active destination is already set for that allocation. If the client > wishes to set a new active destination, it MUST wait until 5 seconds > after a successful response is received to a Set Destination Request > removing the active destination. Failure to wait could cause the > client to receive and attribute late data forwarded by the STUN relay > server to the wrong peer. > > Consider the case where the active destination is set, and > the server is relaying packets towards the client. The client knows > the IP address and port where the packets came from - the current > value of the active destination. The client issues a Set Active > Destination Request to change the active destination, and receives a > response. A moment later, a data packet is received, not encapsulated > in a STUN Data Indication. What is the source if this packet? Is it > the active destination that existed prior to the Set Active > Destination request, or the one after? If the transport between the > client and the STUN server is not reliable, ding is encapsulated of not. > > An alternative to this proposal is to create a new permission if no > permission for the active destination exists. The problem is that > this does not result in sending any data to the peer (as described in > the applicability statement and UNSAF considerations), it is > completely implicit behavior, and the opposite operation (clearing the > active destination) does not delete permissions. > > 3. SetActiveDestination changing destinations > > Currently there are several pages of text devoted to a timer based > state machine that needs to be implemented on both the server and the > client to handle the case of switching the active destination from one > address to another. The problem is that over UDP, the client cannot > tell which unencapsulated data is from the old active destination vs. > the new active destination. > > However, requiring timers and a state machine on the server is a > significant implementation burden which provides no benefit for the > TURN server or its administrative domain. > > The proposal is to put this problem completely into the hands of the > client. Some clients may never wish to change the active destination > for example and will have no need to implement anything special. > Those clients that want to change the active destination over UDP are > required to clear the active destination, wait for an appropriate > interval (5 seconds is suggested), then set the active destination to > the new address. > > Specific proposed text for items 2 and 3 and also delete the TIMER-VAL > attribute: > >
>
> > The Set Active Destination address allows the client to create an > optimized relay function between it and the server. When the server > receives packets from a particular preferred external client, the > server will forward those packets towards the client without > encapsulating them in a Data Indication. Similarly, the client can > send non-STUN packets to the server without encapsulation, and these > are forwarded to the external client. Sending and receiving data in > unencapsulated form is critical for efficiency purposes. One of the > primary use cases for the STUN relay usage is in support of Voice over > IP (VoIP), which uses very small UDP packets to begin with. The extra > overhead of an additional layer of encapsulation is considered > unacceptable. > > The Set Active Destination request is used by the client to provide > the identity of this preferred external client. The Set Active > Destination address MAY contain a REMOTE-ADDRESS attribute. This > attribute, when present, provides the address of the preferred > external client to the server. When absent, it clears the value of the > preferred external client. This address has no effect on the existence > of any permissions. > > The client MUST NOT send a Set Active Destination request with a > REMOTE-ADDRESS attribute over an unreliable link (ex: UDP) if an > active destination is already set for that allocation. If the client > wishes to set a new active destination, it MUST wait until 5 seconds > after a successful response is received to a Set Destination Request > removing the active destination. Failure to wait could cause the > client to receive and attribute late data forwarded by the STUN relay > server to the wrong peer. > > Consider the case where the active destination is set, and > the server is relaying packets towards the client. The client knows > the IP address and port where the packets came from - the current > value of the active destination. The client issues a Set Active > Destination Request to change the active destination, and receives a > response. A moment later, a data packet is received, not encapsulated > in a STUN Data Indication. What is the source if this packet? Is it > the active destination that existed prior to the Set Active > Destination request, or the one after? If the transport between the > client and the STUN server is not reliable, there is no way to > know. > >
> >
> > The Set Active Destination Request is used by a client to set the > forwarding destination of all data that is not encapsulated in STUN > Send Indications. In addition, when a matching permission is present, > all data received from that external client will be forwarded to the > STUN client without being encapsulated in a Data Indication. This > request does not modify any permissions. > > The request MUST be authenticated using the same shared secret as the > one associated with the allocation, or be authenticated using a short > term password derived from that shared secret. If the request was > authenticated but not with such a matching credential, the server MUST > generate an error response with a 441 response code. > > If the Set Active Destination request does not contain a > REMOTE-ADDRESS attribute, the value of the active destination is > cleared. If the Set Active Destination request contains a > REMOTE-ADDRESS attribute, and the active destination is not set, the > active destination is set to that IP address and port. If an active > destination is already set, and the request was received over a > reliable transport, the active destination is changed to the new > value. If the active destination is already set and the request was > received over UDP, the Set Active Destination request is rejected with > a 439 Active Destination Already Set error response. This prevents > the race condition described in the previous section. > >
>
> > 4. Opening TCP permissions > > Currently TCP to TCP traffic between TURN servers requires the TURN > servers to implement simultaneous open. > > SYN -> > <- SYN > SYN-ACK -> > <- ACK > > Option A is to leave this as is and to clarify this non-obvious > implication to implementors (you cannot receive an incoming connection > unless you first try to open one with the Connect request. Option B > is to include an explicit Open Permission Request to create a specific > permission for the TURN server to receive a TCP SYN from one specific > IP address and port number. > > I will implement Option A unless there is strong desire on the list to > do something else. > > thanks, > -rohan > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave there is no way to > know. > >
> >
> > The Set Active Destination Request is used by a client to set the > forwarding destination of all data that is not encapsulated in STUN > Send Indications. In addition, when a matching permission is present, > all data received from that external client will be forwarded to the > STUN client without being encapsulated in a Data Indication. This > request does not modify any permissions. > > The request MUST be authenticated using the same shared secret as the > one associated with the allocation, or be authenticated using a short > term password derived from that shared secret. If the request was > authenticated but not with such a matching credential, the server MUST > generate an error response with a 441 response code. > > If the Set Active Destination request does not contain a > REMOTE-ADDRESS attribute, the value of the active destination is > cleared. If the Set Active Destination request contains a > REMOTE-ADDRESS attribute, and the active destination is not set, the > active destination is set to that IP address and port. If an active > destination is already set, and the request was received over a > reliable transport, the active destination is changed to the new > value. If the active destination is already set and the request was > received over UDP, the Set Active Destination request is rejected with > a 439 Active Destination Already Set error response. This prevents > the race condition described in the previous section. > >
>
> > 4. Opening TCP permissions > > Currently TCP to TCP traffic between TURN servers requires the TURN > servers to implement simultaneous open. > > SYN -> > <- SYN > SYN-ACK -> > <- ACK > > Option A is to leave this as is and to clarify this non-obvious > implication to implementors (you cannot receive an incoming connection > unless you first try to open one with the Connect request. Option B > is to include an explicit Open Permission Request to create a specific > permission for the TURN server to receive a TCP SYN from one specific > IP address and port number. > > I will implement Option A unless there is strong desire on the list to > do something else. > > thanks, > -rohan > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 05 00:38:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDwXg-0004ak-V5; Mon, 05 Feb 2007 00:37:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDwXg-0004Zf-63 for behave@ietf.org; Mon, 05 Feb 2007 00:37:28 -0500 Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDwXc-0004AM-SU for behave@ietf.org; Mon, 05 Feb 2007 00:37:28 -0500 Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Sun, 4 Feb 2007 21:37:24 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) with Microsoft SMTP Server id 8.0.685.24; Sun, 4 Feb 2007 21:37:23 -0800 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Sun, 4 Feb 2007 21:37:21 -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: [Sip] RE: [BEHAVE] Outbound and SPI Date: Sun, 4 Feb 2007 21:36:20 -0800 Message-ID: <70C6EFCDFC8AAD418EF7063CD132D064037B663F@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <45C35EA5.9030309@cornfed.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: [BEHAVE] Outbound and SPI thread-index: AcdG4rxPUkZGZpcfRJqJiecuGb7lfgCA3IFA References: <045c01c74658$af9c9750$c2f0200a@amer.cisco.com><45C27BA4.6000008@cornfed.com><5868c34c015879e03151ac5c3ad8b889@ekabal.com> <45C35EA5.9030309@cornfed.com> From: Christian Huitema To: "Frank W. Miller" , Rohan Mahy X-OriginalArrivalTime: 05 Feb 2007 05:37:21.0495 (UTC) FILETIME=[B5044670:01C748E7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: behave@ietf.org, Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > >>>> I ran into an interesting problem today while testing with a user. > >>>> While multiplexing STUN over the SIP port, it became apparent that > >>>> the Stateful Packet Inspection (SPI) in a very popular widely sold > >>>> NAT/Firewall router that shall remain nameless was blocking the > SIP > >>>> responses. Won't such behaviour be a problem for the outbound > >>>> draft that calls for this multiplexing too. Has anyone else seen > >>>> this behavior? It appears that the router wants STUN on the STUN > >>>> port and SIP on the SIP port. What do we do about this wrt > >>>> multiplexing? Well, this is exactly the kind of behavior that drove inclusion of an obfuscation mechanism in the STUN response. Some NAT tend to be hyperactive. The proper solution is probably to obfuscate the entire SIP traffic. Running SIP over TLS does it nicely, but if we insist on UDP, we may need to ask the SIP group to define an encrypted transport. By the way, SPI may or may not improve the security of your network. SPI requires that the router parse a lot of different packets, in order to find possible attacks and protocol violation. Parsing code is a notorious source of bugs. There are multiple examples of maliciously crafted packets triggering a buffer overflow in a speedily written parser. There is also some evidence that the quality of code in many of these small routers is not great -- otherwise, we would not need to reboot them so often. SPI on a small router brings the combination of "lots of parsing code" with "questionable quality assurance". Turning on SPI in the router may well be building a bright target for hackers just at the doorstep of your network... -- Christian Huitema _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 05 02:47:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDyYw-00012O-Cm; Mon, 05 Feb 2007 02:46:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDyYu-00011N-7L for behave@ietf.org; Mon, 05 Feb 2007 02:46:52 -0500 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HDyYs-0004V1-OA for behave@ietf.org; Mon, 05 Feb 2007 02:46:52 -0500 Received: from Quinthar ([75.39.69.61]) by quinthar.com for ; Sun, 4 Feb 2007 23:46:45 -0800 From: "David Barrett" To: "'Christian Huitema'" , "'Frank W. Miller'" , "'Rohan Mahy'" Subject: RE: [Sip] RE: [BEHAVE] Outbound and SPI Date: Sun, 4 Feb 2007 23:46:45 -0800 Message-ID: <003401c748f9$c945f450$b100a8c0@Quinthar> 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.3028 In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D064037B663F@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> thread-index: AcdG4rxPUkZGZpcfRJqJiecuGb7lfgCA3IFAAATcjDA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: behave@ietf.org, 'Dan Wing' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Do you have any data or estimate on how common this type of NAT is? -david > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Sunday, February 04, 2007 9:36 PM > To: Frank W. Miller; Rohan Mahy > Cc: behave@ietf.org; Dan Wing > Subject: RE: [Sip] RE: [BEHAVE] Outbound and SPI > > > >>>> I ran into an interesting problem today while testing with a > user. > > >>>> While multiplexing STUN over the SIP port, it became apparent > that > > >>>> the Stateful Packet Inspection (SPI) in a very popular widely > sold > > >>>> NAT/Firewall router that shall remain nameless was blocking the > > SIP > > >>>> responses. Won't such behaviour be a problem for the outbound > > >>>> draft that calls for this multiplexing too. Has anyone else seen > > >>>> this behavior? It appears that the router wants STUN on the STUN > > >>>> port and SIP on the SIP port. What do we do about this wrt > > >>>> multiplexing? > > Well, this is exactly the kind of behavior that drove inclusion of an > obfuscation mechanism in the STUN response. Some NAT tend to be > hyperactive. The proper solution is probably to obfuscate the entire SIP > traffic. Running SIP over TLS does it nicely, but if we insist on UDP, > we may need to ask the SIP group to define an encrypted transport. > > By the way, SPI may or may not improve the security of your network. SPI > requires that the router parse a lot of different packets, in order to > find possible attacks and protocol violation. Parsing code is a > notorious source of bugs. There are multiple examples of maliciously > crafted packets triggering a buffer overflow in a speedily written > parser. There is also some evidence that the quality of code in many of > these small routers is not great -- otherwise, we would not need to > reboot them so often. SPI on a small router brings the combination of > "lots of parsing code" with "questionable quality assurance". Turning on > SPI in the router may well be building a bright target for hackers just > at the doorstep of your network... > > -- Christian Huitema > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 05 12:26:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7bb-0006jz-1E; Mon, 05 Feb 2007 12:26:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7ba-0006jA-Az for behave@ietf.org; Mon, 05 Feb 2007 12:26:14 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE7bZ-0005fB-26 for behave@ietf.org; Mon, 05 Feb 2007 12:26:14 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 05 Feb 2007 09:26:05 -0800 X-IronPort-AV: i="4.13,284,1167638400"; d="scan'208"; a="37282915:sNHT1032132699" 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 l15HQ5DE011230; Mon, 5 Feb 2007 09:26:05 -0800 Received: from dwingwxp ([10.32.240.194]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l15HPsnF028108; Mon, 5 Feb 2007 09:25:54 -0800 (PST) From: "Dan Wing" To: "'Christian Huitema'" , "'Frank W. Miller'" , "'Rohan Mahy'" Subject: RE: [Sip] RE: [BEHAVE] Outbound and SPI Date: Mon, 5 Feb 2007 09:25:57 -0800 Message-ID: <01d701c7494a$b8afe050$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcdG4rxPUkZGZpcfRJqJiecuGb7lfgCA3IFAABjjplA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D064037B663F@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1412; t=1170696365; x=1171560365; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20RE=3A=20[BEHAVE]=20Outbound=20and=20SPI |Sender:=20; bh=Us8QgFJBVZJg+fqWsBM/YwO8fc2R01ZVQAK6nDUEa8w=; b=zS6E2j/RQR7KVw1P9pT3NI8J5t/p+1r48bPPGvMYeZ4XjLnKlfaHvrfigpL72GhEv9ew52f3 P5L7QmXtIJ7t7QX6fWxZckBgAtvmAsIJ+xHB2BildVrH/YBvpWCDj/ot; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 Christian Huitema wrote: ... > Well, this is exactly the kind of behavior that drove inclusion of > an obfuscation mechanism in the STUN response. Some NAT tend to be > hyperactive. The proper solution is probably to obfuscate the > entire SIP traffic. Running SIP over TLS does it nicely, but if we > insist on UDP, we may need to ask the SIP group to define an > encrypted transport. There is SIP-over-DTLS, draft-jennings-sip-dtls-02.txt (which has expired). Of course, continuing to run SIP over UDP only encourages the problems discussed in draft-heffner-frag-harmful-04.txt. > By the way, SPI may or may not improve the security of your network. > SPI requires that the router parse a lot of different packets, in > order to find possible attacks and protocol violation. Parsing code > is a notorious source of bugs. There are multiple examples of > maliciously crafted packets triggering a buffer overflow in a > speedily written parser. There is also some evidence that the > quality of code in many of these small routers is not great -- > otherwise, we would not need to reboot them so often. SPI on a > small router brings the combination of "lots of parsing code" with > "questionable quality assurance". Turning on SPI in the router may > well be building a bright target for hackers just at the doorstep of > your network... I couldn't agree more. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 05 13:34:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE8fF-0000h0-BA; Mon, 05 Feb 2007 13:34:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE8fD-0000gv-B7 for behave@ietf.org; Mon, 05 Feb 2007 13:34:03 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE8fC-000261-3J for behave@ietf.org; Mon, 05 Feb 2007 13:34:03 -0500 Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JD000H4J66NTD@usaga04-in.huawei.com> for behave@ietf.org; Mon, 05 Feb 2007 12:32:47 -0600 (CST) Received: from s73602 (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JD0005FV66KB0@usaga04-in.huawei.com> for behave@ietf.org; Mon, 05 Feb 2007 12:32:47 -0600 (CST) Date: Mon, 05 Feb 2007 09:12:25 -0600 From: Spencer Dawkins Subject: Re: [Sip] RE: [BEHAVE] Outbound and SPI To: behave@ietf.org Message-id: <000001c74954$07d8fcd0$ad600240@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <045c01c74658$af9c9750$c2f0200a@amer.cisco.com> <45C27BA4.6000008@cornfed.com> <5868c34c015879e03151ac5c3ad8b889@ekabal.com> <45C35EA5.9030309@cornfed.com> <70C6EFCDFC8AAD418EF7063CD132D064037B663F@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Just curious... From: "Christian Huitema" "Well, this is exactly the kind of behavior that drove inclusion of an obfuscation mechanism in the STUN response. Some NAT tend to be hyperactive. The proper solution is probably to obfuscate the entire SIP traffic. Running SIP over TLS does it nicely, but if we insist on UDP, we may need to ask the SIP group to define an encrypted transport." Christian is not the first person I've heard asserting that encrypting transport solved problems with "hyperactive NATs" (great term - is it in common use?). Do we have a BCP underway anywhere that says "NATs SHOULD/MUST pass encrypted transport packets", with whatever qualifiers are appropriate? If not, I'm concerned that next-generation NATs may close this "security hole" ("my gosh, someone is sending packets through my NAT and I don't know what they're doing"), leaving us at the next stage of the unending arms race with a really damaged network. This may still happen, but at least we're not silent until it happens. "By the way, SPI may or may not improve the security of your network. SPI requires that the router parse a lot of different packets, in order to find possible attacks and protocol violation. Parsing code is a notorious source of bugs. There are multiple examples of maliciously crafted packets triggering a buffer overflow in a speedily written parser. There is also some evidence that the quality of code in many of these small routers is not great -- otherwise, we would not need to reboot them so often. SPI on a small router brings the combination of "lots of parsing code" with "questionable quality assurance". Turning on SPI in the router may well be building a bright target for hackers just at the doorstep of your network..." How could I disagree? It would be lovely if these "security" measures didn't make you LESS secure - sometimes "breaking even" is an improvement. Thanks, Spencer _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 05 14:02:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE96K-0007XT-DQ; Mon, 05 Feb 2007 14:02:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE96I-0007XN-N5 for behave@ietf.org; Mon, 05 Feb 2007 14:02:02 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE96H-000056-C3 for behave@ietf.org; Mon, 05 Feb 2007 14:02:02 -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 l15J1uZ12730; Mon, 5 Feb 2007 14:01:56 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: [BEHAVE] Outbound and SPI Date: Mon, 5 Feb 2007 13:01:55 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0F08257D@zrc2hxm0.corp.nortel.com> In-Reply-To: <000001c74954$07d8fcd0$ad600240@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: [BEHAVE] Outbound and SPI Thread-Index: AcdJVHT9mesQixv7TVKaKSG6flD5vQAA2EJA From: "Francois Audet" To: "Spencer Dawkins" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I think we went through this already as part of ICE discussion (therefore probably in MMUSIC). Indeed the conclusion was that encryption was the solution (as=20 opposed to obfuscating every single protocol element where one can potentially screw-up). > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org]=20 > Sent: Monday, February 05, 2007 07:12 > To: behave@ietf.org > Subject: Re: [Sip] RE: [BEHAVE] Outbound and SPI >=20 > Just curious... >=20 > From: "Christian Huitema" >=20 > "Well, this is exactly the kind of behavior that drove=20 > inclusion of an obfuscation mechanism in the STUN response.=20 > Some NAT tend to be hyperactive. The proper solution is=20 > probably to obfuscate the entire SIP traffic. Running SIP=20 > over TLS does it nicely, but if we insist on UDP, we may need=20 > to ask the SIP group to define an encrypted transport." >=20 > Christian is not the first person I've heard asserting that=20 > encrypting transport solved problems with "hyperactive NATs"=20 > (great term - is it in common use?). >=20 > Do we have a BCP underway anywhere that says "NATs=20 > SHOULD/MUST pass encrypted transport packets", with whatever=20 > qualifiers are appropriate? >=20 > If not, I'm concerned that next-generation NATs may close=20 > this "security hole" ("my gosh, someone is sending packets=20 > through my NAT and I don't know what they're doing"), leaving=20 > us at the next stage of the unending arms race with a really=20 > damaged network. >=20 > This may still happen, but at least we're not silent until it happens. >=20 > "By the way, SPI may or may not improve the security of your=20 > network. SPI requires that the router parse a lot of=20 > different packets, in order to find possible attacks and=20 > protocol violation. Parsing code is a notorious source of=20 > bugs. There are multiple examples of maliciously crafted=20 > packets triggering a buffer overflow in a speedily written=20 > parser. There is also some evidence that the quality of code=20 > in many of these small routers is not great -- otherwise, we=20 > would not need to reboot them so often. SPI on a small router=20 > brings the combination of "lots of parsing code" with=20 > "questionable quality assurance". Turning on SPI in the=20 > router may well be building a bright target for hackers just=20 > at the doorstep of your network..." >=20 > How could I disagree? It would be lovely if these "security"=20 > measures didn't make you LESS secure - sometimes "breaking=20 > even" is an improvement. >=20 > Thanks, >=20 > Spencer=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 Mon Feb 05 14:33:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE9aW-0007qU-80; Mon, 05 Feb 2007 14:33:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE9aV-0007q6-AB for behave@ietf.org; Mon, 05 Feb 2007 14:33:15 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE9aS-0006in-2j for behave@ietf.org; Mon, 05 Feb 2007 14:33:15 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 05 Feb 2007 11:32:42 -0800 X-IronPort-AV: i="4.13,284,1167638400"; d="scan'208"; a="385917710:sNHT1498277944" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l15JWfDc008934; Mon, 5 Feb 2007 11:32:41 -0800 Received: from dwingwxp ([10.32.240.194]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l15JWfnF010804; Mon, 5 Feb 2007 11:32:41 -0800 (PST) From: "Dan Wing" To: "'Spencer Dawkins'" , Subject: RE: [Sip] RE: [BEHAVE] Outbound and SPI Date: Mon, 5 Feb 2007 11:32:43 -0800 Message-ID: <027001c7495c$68661d50$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcdJVHmg33rk1GyxSzyIUUccVuHbbwAAC/AA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <000001c74954$07d8fcd0$ad600240@china.huawei.com> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3354; t=1170703961; x=1171567961; c=relaxed/simple; s=sjdkim6002; 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[Sip]=20RE=3A=20[BEHAVE]=20Outbound=20and=20SPI |Sender:=20; bh=M15krAyjASzXS3ZsMCD3E+f64sQGM6r1qJOXauQypd0=; b=UJyzohcUNCh1Q8hZTTV8eWkLp1WMY8w55ro3RSifk7V/ZJgoGBBUxzz0N/v0DrYqurHSvF6X HhW7l+nSxJ2qA2Ilc5yOuCL5WsvsDZmH8a4WtiDzSeRUqEhzADSUFJ8i; Authentication-Results: sj-dkim-6; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] > Sent: Monday, February 05, 2007 7:12 AM > To: behave@ietf.org > Subject: Re: [Sip] RE: [BEHAVE] Outbound and SPI > > Just curious... > > From: "Christian Huitema" > > "Well, this is exactly the kind of behavior that drove inclusion of an > obfuscation mechanism in the STUN response. Some NAT tend to be > hyperactive. The proper solution is probably to obfuscate the > entire SIP > traffic. Running SIP over TLS does it nicely, but if we insist on UDP, > we may need to ask the SIP group to define an encrypted transport." > > Christian is not the first person I've heard asserting that > encrypting transport solved problems with "hyperactive NATs" > (great term - is it in common use?). > > Do we have a BCP underway anywhere that says "NATs SHOULD/MUST pass > encrypted transport packets", with whatever qualifiers are > appropriate? No, we don't. But it isn't necessary -- such a NAT wouldn't work with your bank, stockbroker, HTTPS-based webmail, and so on, which default to port 443. It wouldn't work with STARTTLS-encrypted email submission. It wouldn't work with Skype. It wouldn't work with other things it "thinks" are encrypted (which are just new things it doesn't understand). Such a product would be a failure in the market. > If not, I'm concerned that next-generation NATs may close this > "security hole" ("my gosh, someone is sending packets through my NAT > and I don't know what they're doing"), leaving us at the next stage > of the unending arms race with a really damaged network. > > This may still happen, but at least we're not silent until it happens. I'm not sure what we could say. Afterall, there are legitimate security policies (enforced with equipment available today) that allows companies to provide content filtering of email, web, and ftp traffic. This is done to discourage employees from using the comapny's network and computer resources for personal use and to decrease the company's exposure to lawsuits. But that stuff is beyond BEHAVE's scope, and I expect beyond IETF's scope. -d > "By the way, SPI may or may not improve the security of your > network. SPI > requires that the router parse a lot of different packets, in order to > find possible attacks and protocol violation. Parsing code is a > notorious source of bugs. There are multiple examples of maliciously > crafted packets triggering a buffer overflow in a speedily written > parser. There is also some evidence that the quality of code > in many of > these small routers is not great -- otherwise, we would not need to > reboot them so often. SPI on a small router brings the combination of > "lots of parsing code" with "questionable quality assurance". > Turning on > SPI in the router may well be building a bright target for > hackers just > at the doorstep of your network..." > > How could I disagree? It would be lovely if these "security" > measures didn't > make you LESS secure - sometimes "breaking even" is an improvement. > > Thanks, > > Spencer > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 05 16:44:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEBdH-0003GT-45; Mon, 05 Feb 2007 16:44:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEBdG-0003GM-7q for Behave@ietf.org; Mon, 05 Feb 2007 16:44:14 -0500 Received: from flpvm23.prodigy.net ([207.115.20.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEBdE-0000Vf-TX for Behave@ietf.org; Mon, 05 Feb 2007 16:44:14 -0500 X-ORBL: [71.131.192.23] Received: from [10.0.0.26] (adsl-71-131-192-23.dsl.sntc01.pacbell.net [71.131.192.23]) by flpvm23.prodigy.net (8.13.8 out.dk.spool/8.13.8) with ESMTP id l15LiLHb030251 for ; Mon, 5 Feb 2007 13:44:21 -0800 Message-ID: <45C7A56B.5020705@pjsip.org> Date: Mon, 05 Feb 2007 13:45:15 -0800 From: Benny Prijono User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) 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: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: [BEHAVE] STUN/TURN message type bits X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org All, I think I need a way to distinguish STUN message classes (i.e. request, response, or indication), and reading section 6 of the rfc3489bis I think this is what I conclude for the formula, in traditional C: #define IS_REQUEST(msg_type) (((msg_type) & 0x0FF0) == 0x0000) #define IS_RESPONSE(msg_type) (((msg_type) & 0x0FF0) == 0x0100) #define IS_ERR_RESPONSE(msg_type) (((msg_type) & 0x0FF0) == 0x0110) #define IS_INDICATION(msg_type) (((msg_type) & 0x0FF0) == 0x0010) Is that right (or wrong)? If that is right, then I have a question regarding the values for TURN indications, which currently (as turn-02) are: 0x0004 : Send Indication 0x0115 : Data Indication 0x0118 : Connect Status Indication Somehow I feel that there is no consistency in the value assignment (Send Indication looks like a request, while the others look like error responses). So what's the rule here? Any help on this will be great. thanks, -benny -- Benny Prijono http://www.pjsip.org _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Feb 06 09:58:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HERlu-0000qh-GX; Tue, 06 Feb 2007 09:58:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HERls-0000qY-Gp for behave@ietf.org; Tue, 06 Feb 2007 09:58:12 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HERlp-0002r3-P9 for behave@ietf.org; Tue, 06 Feb 2007 09:58:12 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l16Espn1023321; Tue, 6 Feb 2007 16:55:03 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 16:57:37 +0200 Received: from esdhcp042186.research.nokia.com ([172.21.42.186]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 6 Feb 2007 16:57:37 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia-TP-MSW Helsinki To: behave@ietf.org Subject: Re: [BEHAVE] READ and COMMENT: Re: TURN major issues and proposed fixes Date: Tue, 6 Feb 2007 16:59:15 +0200 User-Agent: KMail/1.9.5 References: <953beacc0702041625q1d1f600bwbb64dc40ff1a3cf@mail.gmail.com> In-Reply-To: <953beacc0702041625q1d1f600bwbb64dc40ff1a3cf@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200702061659.15983.Remi.Denis-Courmont@nokia.com> X-OriginalArrivalTime: 06 Feb 2007 14:57:37.0095 (UTC) FILETIME=[23E38570:01C749FF] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070206165503-5AE7ABB0-2CBAC9BC/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Le Monday 05 February 2007 02:25, ext Rohan Mahy a =E9crit=A0: > > 1. Allocations, Bindings, Permissions, Timeouts, and the Active > > Destination. (...) > > - Remove the terminology "binding" altogether inside the TURN server. > > Only use "binding" when talking about a "real" NAT (ex: between the > > TURN client and the TURN server) Yep, sticking to allocation and permission is more clear. > > - All requests and indications except for initial Allocation requests > > are sent in the context of a matching valid allocation, otherwise they > > are rejected (requests) or discarded silently (Indications). (...) > > - Each allocation can have zero or more permissions I don't recall any notes that TURN server may put a limit on the number of= =20 permissions per allocation. In practice, like it or not, it will be that wa= y,=20 what should a server do if the limit is reached? What is the minimum limit = a=20 server must accept? > > - When allocations are destroyed all related permissions are deleted. Yeah, this is obvious :) > > - Permissions are only created by Send Indications over UDP and > > Connect Requests over TCP. What if you do want to add a UDP permission without sending anything? This= =20 actually makes a lot of sense of the other side is running behind a symmetr= ic=20 NAT and without TURN: waiting for the other side to send allows avoiding th= e=20 ICMP errors issue that is found in many non-behave-compliant NATs. Send Indications without payload attribute maybe? (...) > > - The active destination is changed only with the Set Active > > Destination Request for an allocation. The active destination is > > completely independent of any permissions. Yes, this simplifies a tiny bit. > > 2. SetActiveDestination should not be limited to existing permissions > > Current text in some places says that the active destination needs to > > be an existing permission. This is actually unnecessary however, and > > loosening this restriction is useful. Yes. But that seems to contradict the previous paragraph!? > > Take the case where the TURN client receives a SIP INVITE with an > > offer, and the TURN client wishes to accept the offer. The TURN client > > should be able to set the active destination immediately before > > issuing its first Send request (to this destination). Using this order > > of operations insures that the TURN client receives all data traffic > > unencapsulated. This provides for more consistent bandwidth usage in > > this case. No. Because of UDP packet loss or reordering, the client will still need to= =20 use Send Request after Set Active Destination (which makes me wonder if it= =20 would not be better to always use send and drop set active altogether). > > The proposal is to change the current text to completely decouple the > > active destination from any permissions. A permission controls > > whether traffic flows. The active destination controls whether > > traffic flowing over a binding is encapsulated of not. As noted above, there should be a way to add permission without sending=20 anything. It does not necessarily need to be through Set Active Destination= =20 though. > > 3. SetActiveDestination changing destinations > > Currently there are several pages of text devoted to a timer based > > state machine that needs to be implemented on both the server and the > > client to handle the case of switching the active destination from one > > address to another. The problem is that over UDP, the client cannot > > tell which unencapsulated data is from the old active destination vs. > > the new active destination. > > > > However, requiring timers and a state machine on the server is a > > significant implementation burden which provides no benefit for the > > TURN server or its administrative domain. Agreed. > > The proposal is to put this problem completely into the hands of the > > client. Some clients may never wish to change the active destination > > for example and will have no need to implement anything special. > > Those clients that want to change the active destination over UDP are > > required to clear the active destination, wait for an appropriate > > interval (5 seconds is suggested), then set the active destination to > > the new address. Ack. > > Specific proposed text for items 2 and 3 and also delete the TIMER-VAL > > attribute: > > > >
> >
> > > > The Set Active Destination address allows the client to create an > > optimized relay function between it and the server. When the server > > receives packets from a particular preferred external client, the > > server will forward those packets towards the client without > > encapsulating them in a Data Indication. Similarly, the client can > > send non-STUN packets to the server without encapsulation, and these > > are forwarded to the external client. Sending and receiving data in > > unencapsulated form is critical for efficiency purposes. One of the > > primary use cases for the STUN relay usage is in support of Voice over > > IP (VoIP), which uses very small UDP packets to begin with. The extra > > overhead of an additional layer of encapsulation is considered > > unacceptable. > > > > The Set Active Destination request is used by the client to provide > > the identity of this preferred external client. The Set Active > > Destination address MAY contain a REMOTE-ADDRESS attribute. This > > attribute, when present, provides the address of the preferred > > external client to the server. When absent, it clears the value of the > > preferred external client. This address has no effect on the existence > > of any permissions. > > > > The client MUST NOT send a Set Active Destination request with a > > REMOTE-ADDRESS attribute over an unreliable link (ex: UDP) if an > > active destination is already set for that allocation. If the client > > wishes to set a new active destination, it MUST wait until 5 seconds > > after a successful response is received to a Set Destination Request > > removing the active destination. Failure to wait could cause the > > client to receive and attribute late data forwarded by the STUN relay > > server to the wrong peer. > > > > Consider the case where the active destination is set, and > > the server is relaying packets towards the client. The client knows > > the IP address and port where the packets came from - the current > > value of the active destination. The client issues a Set Active > > Destination Request to change the active destination, and receives a > > response. A moment later, a data packet is received, not encapsulated > > in a STUN Data Indication. What is the source if this packet? Is it > > the active destination that existed prior to the Set Active > > Destination request, or the one after? If the transport between the > > client and the STUN server is not reliable, there is no way to > > know. > > > >
The same 5 seconds interval might perhaps be applied to retransmit if the S= et=20 Active Destination has not been acked (packet loss). > >
> > > > The Set Active Destination Request is used by a client to set the > > forwarding destination of all data that is not encapsulated in STUN > > Send Indications. In addition, when a matching permission is present, > > all data received from that external client will be forwarded to the > > STUN client without being encapsulated in a Data Indication. This > > request does not modify any permissions. > > > > The request MUST be authenticated using the same shared secret as the > > one associated with the allocation, or be authenticated using a short > > term password derived from that shared secret. If the request was > > authenticated but not with such a matching credential, the server MUST > > generate an error response with a 441 response code. > > > > If the Set Active Destination request does not contain a > > REMOTE-ADDRESS attribute, the value of the active destination is > > cleared. If the Set Active Destination request contains a > > REMOTE-ADDRESS attribute, and the active destination is not set, the > > active destination is set to that IP address and port. If an active > > destination is already set, and the request was received over a > > reliable transport, the active destination is changed to the new > > value. If the active destination is already set and the request was > > received over UDP, the Set Active Destination request is rejected with > > a 439 Active Destination Already Set error response. This prevents > > the race condition described in the previous section. > > > >
> >
To handle retransmission sanely, the server will still need to accept and a= ck=20 Set Active Destination where REMOTE-ADDRESS matches current active dst,=20 perhaps? =2D-=20 R=E9mi Denis-Courmont Research Engineer _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Feb 06 11:25:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HET7s-0001pn-HA; Tue, 06 Feb 2007 11:25:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HET7q-0001ph-VN for behave@ietf.org; Tue, 06 Feb 2007 11:24:58 -0500 Received: from maildialog.com ([195.159.98.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HET7l-00033d-QJ for behave@ietf.org; Tue, 06 Feb 2007 11:24:58 -0500 Received: from [82.196.214.14] (helo=[192.168.1.100]) by maildialog.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51-maildialog) id 1HET7e-0004fB-Hr; Tue, 06 Feb 2007 16:24:47 +0000 Message-ID: <45C8ABCB.3040106@db.org> Date: Tue, 06 Feb 2007 17:24:43 +0100 From: "Alfred E. Heggestad" User-Agent: Icedove 1.5.0.9 (X11/20061220) MIME-Version: 1.0 To: Jonathan Rosenberg Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: behave@ietf.org Subject: [BEHAVE] rfc3489bis: clarification on magic cookie, XOR-MAPPED-ADDRESS and byte order X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 in rfc3489-bis05 there seem to be some confusion regarding the byte order of magic cookie and XOR-MAPPED-ADDRESS. could I ask that we include some info about the byte order in rfc3489-bis06 ? my assumption is the following (please correct me if wrong): > Section 6: > > 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 the magic cookie value is in host byte order, and will be encoded to network byte order on the wire. correct? > Section 11.10 > > For example, using the "^" character to indicate exclusive or, if the > IP address is 192.168.1.1 (0xc0a80101) and the port is 5555 (0x15B3), > the X-Port would be 0x15B3 ^ 0x2112 = 0x34A1, and the X-Address would > be 0xc0a80101 ^ 0x2112A442 = 0xe1baa543. the X-port value 0x34A1 above is in host byte order and will be converted to network byte order on the wire. correct? the X-Address value 0xe1baa543 above is in host byte order and will be converted to network byte order on the wire. correct? this stuff should be quite simple to implement, but I know from implementors that this is interpreted differently, so we need to make sure that the spec does not leave anything open for mis-interpretation. my apologies if this has been covered already.. thanks /alfred _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 09 16:23:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFdCA-0007L2-Kw; Fri, 09 Feb 2007 16:22:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFdC9-0007Ku-5d; Fri, 09 Feb 2007 16:22:13 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFdC7-0002Ba-HN; Fri, 09 Feb 2007 16:22:13 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 09 Feb 2007 13:22:10 -0800 X-IronPort-AV: i="4.13,308,1167638400"; d="scan'208"; a="387569367:sNHT63232630" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l19LMAYB029818; Fri, 9 Feb 2007 13:22:10 -0800 Received: from dwingwxp ([10.32.240.194]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l19LM8ho003638; Fri, 9 Feb 2007 13:22:09 -0800 (PST) From: "Dan Wing" To: , Date: Fri, 9 Feb 2007 13:22:08 -0800 Message-ID: <015d01c74c90$5b79a990$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: Acc/7+pIYyPyXe++QkyaABxXjX3fXAMoDzcw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7638; t=1171056130; x=1171920130; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20WGLC=20draft-ietf-behave-tcp-04=20completed |Sender:=20; bh=EqmZd2UjtCAWT8Li4D2QctAWh09jlHRzaz43ES2eI8s=; b=IQmZ4TLI7U7hdGQ6amXXG63Ky7R00pbTD+dp9FdtGZ/hmxkhOP8+h8yeUQhOGV+7PtUeufDf gKHAA8ywxnGVFrPPCqh5cM2KsRVdMVb+9rlsu66jsjevhE9JpnuU3isP; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: Subject: [BEHAVE] WGLC draft-ietf-behave-tcp-04 completed X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org The WGLC of draft-ietf-behave-tcp-04 has completed, with no comments received. The document will be sent to IESG for their review. PROTO writeup is below. -d ----- PROTO (draft-ietf-proto-wgchair-doc-shepherding-09) writeup for: "NAT Behavioral Requirements for TCP", http://www.ietf.org/internet-drafts/draft-ietf-behave-tcp-04.txt (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Dan Wing The document has been reviewed and is ready for forwarding to IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? During its development, the document has received input from members of the TCPM working group (especially Joe Touch and Fernando Gont), and that input was integrated into this document. The document had a two-week WGLC in both TCPM and BEHAVE working groups. There were no comments during this last call. The Document Shepherd has no concerns about the depth or breadth of the reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? Additional review is not necessary. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. There have been a little concern that the TCP document normatively references the UDP document (draft-ietf-behave-nat-udp, soon to be published as RFC4787), because this requires reading both documents. WG consensus was to normatively reference UDP, as is done in the document. There is no IPR on this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has strong WG consensus. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) None indicated. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The document hsa pre-Feb-2007 copyright, per idnits 1.124: - This document has ISOC Copyright according to RFC 3978, instead of the newer IETF Trust Copyright according to RFC 4748. You should consider updating it; the new Copyright statement will be required from February 1st, 2007 - This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. You should consider updating it; the new disclaimer will be required from February 1st, 2007 (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes, the document has split its references. There are two I-Ds cited as normative: * draft-ietf-behave-nat-icmp, which is not yet ready for advancement (it has not been WGLC'd). It is expected to be WGLC'd later this year. * draft-ietf-behave-nat-udp is in the RFC Editor's queue. There are no downward references. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? There are no IANA considerations for this specification; the document does not describe an Expert Review process. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? This document does not contain any such formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and on-line games, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. Working Group Summary This document was a product of the BEHAVE working group. Document Quality This document describes recommended practices for NATs. Most existing NATs already conform to these requirements. Personnel Dan Wing is the Document Shepherd, and Magnus Westerlund is the Responsible Area Director. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Feb 10 02:28:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFmeK-0000sF-QK; Sat, 10 Feb 2007 02:27:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFmeJ-0000s6-Ey for behave@ietf.org; Sat, 10 Feb 2007 02:27:55 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFmeI-0000Ib-SL for behave@ietf.org; Sat, 10 Feb 2007 02:27:55 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l1A7JoD14358; Sat, 10 Feb 2007 02:19:51 -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] TURN major issues and proposed fixes Date: Sat, 10 Feb 2007 01:24:08 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43715DFAB9@zrc2hxm2.corp.nortel.com> In-Reply-To: <2be65072dd926b19cee30b39c2f75d45@ekabal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] TURN major issues and proposed fixes Thread-index: Acc/C7LZ0V8UR8seReORPgyIWwIKaANqEY/w From: "Brian Stucker" To: "Rohan Mahy" X-Spam-Score: 0.0 (/) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 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 Comments inline.=20 > -----Original Message----- > From: Rohan Mahy [mailto:rohan@ekabal.com]=20 > Sent: Wednesday, January 24, 2007 1:25 AM > To: Stucker, Brian (RICH1:AR00) > Cc: behave@ietf.org; Rohan Mahy; Rohan Mahy > Subject: Re: [BEHAVE] TURN major issues and proposed fixes >=20 > Hi Brian, >=20 > Thanks for your comments. My responses are inline. >=20 > On Jan 22, 2007, at 16:21, Brian Stucker wrote: > >> -----Original Message----- > >> From: Rohan Mahy [mailto:rohan.mahy@gmail.com] > >> Sent: Friday, January 19, 2007 10:03 PM > >> To: behave@ietf.org > >> Cc: Rohan Mahy > >> Subject: [BEHAVE] TURN major issues and proposed fixes > >> > >> Hi Folks, > >> > >> The following issues have all come up from implementors of=20 > TURN and=20 > >> are big enough issues that I wanted to get some list=20 > feedback before=20 > >> incorporating these in a new rev. > >> > >> 1. Allocations, Bindings, Permissions, Timeouts, and the Active=20 > >> Destination. > >> > >> The current text is still a bit fuzzy and inconsistent=20 > about what is=20 > >> a difference between permission and a binding and what=20 > keeps bindings=20 > >> open. Also, many implementors have expressed confusion between the=20 > >> behavior of an ordinary NAT binding and a "STUN Relay=20 > binding", so I=20 > >> am proposing we skip the binding terminology in favor of=20 > >> "permission". > >> Much of the following came from consensus at one of the meetings.=20 > >> I've come up with the following proposal which fills out a=20 > consistent=20 > >> set of rules: > >> - Remove the terminology "binding" altogether inside the=20 > TURN server. > >> Only use "binding" when talking about a "real" NAT (ex: > >> between the TURN client and the TURN server) > > > > Sounds good. > > > >> - All requests and indications except for initial=20 > Allocation requests=20 > >> are sent in the context of a matching valid allocation, otherwise=20 > >> they are rejected (requests) or discarded silently (Indications). > > > > Sounds good. > > > >> - Allocations are explicitly refreshed via subsequent allocation=20 > >> requests. Allocation timeout values are on the order of minutes.=20 > >> Send and Data indications do not refresh Allocations. Allocation=20 > >> timers are based on the LIFETIME attribute. > > > > I'm confused. What's the relation between LIFETIME and=20 > > REFRESH-INTERVAL below? If the allocation expires, then the=20 > > permissions go with it because the permissions were created=20 > in the context of an allocation. >=20 > I expect that the LIFETIME might be on the order of 15=20 > minutes, and the REFRESH-INTERVAL for a UDP permission might=20 > be on the order of 30 seconds. >=20 > Under the proposal here, you need to send data to the target=20 > of each permission at least every 30 seconds to keep the=20 > permission alive. I assume this also is likely to have the=20 > side effect of keeping NAT bindings alive as well. You=20 > separately need to send a (re)Allocate Request to the TURN=20 > server at least every 15 minutes to refresh the allocation. =20 > As you pointed out, if you don't do this, the whole=20 > allocation goes away and all the related permissions with it. Hmm... I still don't see the value of sending a (re)Allocate Request to the TURN server if there are active permissions for that allocation. Why should a TURN client have to tell the TURN server twice (effectively) that it wants a particular permission to remain active: once by remembering to send data to it every so often, and again by refreshing the allocation that allows the permission to exist. Just seems like extra overhead without a clear purpose. What is the problem you're trying to solve here?=20 >=20 > >> - Each allocation can have zero or more permissions > >> - When allocations are destroyed all related permissions=20 > are deleted. > >> - Permissions are only created by Send Indications over UDP and=20 > >> Connect Requests over TCP. > > > > This means that an offerer would have to generate RTP traffic to an=20 > > answerer to get RTP traffic sent back to it. What if I want=20 > to setup a=20 > > one-way stream to me in which it's inappropriate to=20 > generate traffic=20 > > in the other direction, only to make the TURN server happy? Why not=20 > > let Set Active Destination also create a permission? >=20 > This would be a change from the Applicability, Introduction,=20 > and UNSAF considerations as I read them. There is a lot of=20 > text in those sections about how we only create a permission=20 > when we have sent data to that target. Yes, but is it the wrong thing to do? Is there a technical reason to not allow people to setup one-way (receive-only) RTP sessions that don't require them to "cheat" and send something to get their data. >=20 > >> - Data sent to a peer (via send Indications and=20 > unencapsulated data=20 > >> sent to the active destination) by the TURN client refresh the=20 > >> relevant permission. Data to one permission does not refresh other=20 > >> permissions associated with the same binding. > > > > Sounds good. > > > >> - The expected timeout interval for all permissions for an=20 > allocation=20 > >> is conveyed from the server to the client using the=20 > REFRESH-INTERVAL=20 > >> attribute in an initial successful Allocate Response. > > > > How does this relate to LIFETIME (see above)? > > > >> - The active destination is changed only with the Set Active=20 > >> Destination Request for an allocation. The active destination is=20 > >> completely independent of any permissions. > > > > There's some text about the Set Active Destination Request=20 > creating a=20 > > permission in section 9.2 that's been floating about on the list as=20 > > being used to allow an originator to tell the TURN server to allow=20 > > traffic from that destination. This would make it possible for a=20 > > permission to be created without requiring the originator=20 > to generate=20 > > traffic to the actual intended destination. I think this should be=20 > > allowed. Are you proposing changing this? >=20 > can you paste that into this thread please? Here you go: http://www1.ietf.org/mail-archive/web/behave/current/msg01896.html >=20 > >> 2. SetActiveDestination should not be limited to existing=20 > permissions=20 > >> Current text in some places says that the active=20 > destination needs to=20 > >> be an existing permission. This is actually unnecessary=20 > however, and=20 > >> loosening this restriction is useful. > >> Take the case where the TURN client receives a SIP INVITE with an=20 > >> offer, and the TURN client wishes to accept the offer. The TURN=20 > >> client should be able to set the active destination immediately=20 > >> before issuing its first Send request (to this destination). Using=20 > >> this order of operations insures that the TURN client receives all=20 > >> data traffic unencapsulated. This provides for more consistent=20 > >> bandwidth usage in this case. > > > > This does not (to me) appear to mesh with some of the points you've=20 > > made above. >=20 > Can you be more specific about that? > This proposed change makes the active destination used by the=20 > TURN server only for deciding when to send unwrapped data and=20 > to decide how to process unwrapped data it receives. > You can set the active destination to anything you'd like. =20 > IIF traffic is received and there is a permission (because=20 > you sent traffic there) it gets wrapped in a Data indication=20 > unless it was received from the active destination. >=20 > Also, if you set the active destination, there may be no need=20 > to wrap your first bit of outgoing data in a Send request. Ah. Now I understand your point. I thought your statement contradicted the notion of letting Set Active Destination create a permission to receive data from a peer without having to first send data to it through the TURN server. >=20 >=20 > > I thought paragraph 5 on page 19 of the draft made the > > expectation pretty clear: > > > > If the Set Active Destination request contains a REMOTE-ADDRESS > > attribute, the IP address contained within it is added to the > > permissions for this allocation, if it was not already present. >=20 > This paragraph is later contradicted a few paragraphs later. We need=20 > to change one of the paragraphs. Agree. >=20 > >> The proposal is to change the current text to completely > >> decouple the active destination from any permissions. A > >> permission controls whether traffic flows. The active > >> destination controls whether traffic flowing over a binding > >> is encapsulated of not. > >> > >> An alternative to this proposal is to create a new permission > >> if no permission for the active destination exists. The > >> problem is that this does not result in sending any data to > >> the peer (as described in the applicability statement and > >> UNSAF considerations), it is completely implicit behavior, > >> and the opposite operation (clearing the active destination) > >> does not delete permissions. > > > > Why not add an operation to explicitly clear the active destination > > then? >=20 > We can clear the active destination just fine now, its just that that=20 > has no effect on permissions. >=20 > What we don't have is a way to explicitly delete a permission. I=20 > proposed a Close Binding Request verb back in Montreal and there was=20 > pretty overwhelming reaction to get rid of it. So, it seems that there's two separate mechanisms at work here: encapsulation and permission. It would be best if we could control encapsulation and permissions separately (because the two really have nothing to do with one another). If permissions were created through an explicit TURN request (and could be explicitly deleted as well, although I'm not sure that we really need this unless the REFRESH-INTERVAL is pretty long) *OR* by sending data to the peer that would make me happy. Set Active Destination would be used strictly for encapsulation control. My only concern with this is the number of round-trips involved to receive data from a peer if the TURN client has nothing to send but wants to get data. Perhaps a permissions attribute could be created that could be piggybacked on the Set Active Destination or Allocation Requests to define the expected permission behavior by the TURN client.=20 I'm not trying to turn the TURN server into a general relay, but there are issues in networks that have relatively slow best-effort signaling paths during call setup that I want to make sure we're addressing.=20 >=20 > >> 3. SetActiveDestination changing destinations >=20 > Do you have any comments on proposals 3 or 4? >=20 > thanks, > -rohan >=20 > >> Currently there are several pages of text devoted to a timer > >> based state machine that needs to be implemented on both the > >> server and the client to handle the case of switching the > >> active destination from one address to another. The problem > >> is that over UDP, the client cannot tell which > >> unencapsulated data is from the old active destination vs. > >> the new active destination. > >> > >> However, requiring timers and a state machine on the server > >> is a significant implementation burden which provides no > >> benefit for the TURN server or its administrative domain. > >> > >> The proposal is to put this problem completely into the hands > >> of the client. Some clients may never wish to change the > >> active destination for example and will have no need to > >> implement anything special. > >> Those clients that want to change the active destination over > >> UDP are required to clear the active destination, wait for an > >> appropriate interval (5 seconds is suggested), then set the > >> active destination to the new address. > >> > >> Specific proposed text for items 2 and 3 and also delete=20 > the TIMER-VAL > >> attribute: > >> > >> [snip proposed text] Sounds good. The client is really in the best position to know when it's likely to be 'safe' to set a new Active Destination anyhow. The TURN server has no idea what the expected rate of arrival of data is for a particular application at any given time so leaving it in the hands of the client to figure out seems appropriate. Wonder what applications that get a 439 to a SAD request do today? Close the connection, or just ignore it and get encapsulated data from that point onward (which could really screw up their rendering as the QoS settings they probably setup the session with wouldn't account for continuously encapsulated data). > >> 4. Opening TCP permissions > >> > >> Currently TCP to TCP traffic between TURN servers requires > >> the TURN servers to implement simultaneous open. > >> > >> SYN -> > >> <- SYN > >> SYN-ACK -> > >> <- ACK > >> > >> Option A is to leave this as is and to clarify this > >> non-obvious implication to implementors (you cannot receive > >> an incoming connection unless you first try to open one with > >> the Connect request. Option B is to include an explicit Open > >> Permission Request to create a specific permission for the > >> TURN server to receive a TCP SYN from one specific IP address > >> and port number. > >> > >> I will implement Option A unless there is strong desire on > >> the list to do something else. How prevalent is support for simultaneous open in other settings? _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 12 16:09:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGiQU-0002h7-Fw; Mon, 12 Feb 2007 16:09:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGiQS-0002ed-FO; Mon, 12 Feb 2007 16:09:28 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGiQL-0003qu-V2; Mon, 12 Feb 2007 16:09:28 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 717A2204F8; Mon, 12 Feb 2007 22:09:19 +0100 (CET) X-AuditID: c1b4fb3e-afed3bb0000007e1-1d-45d0d77fa27e Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 54D71200DB; Mon, 12 Feb 2007 22:09:19 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 22:09:19 +0100 Received: from [138.85.12.13] ([138.85.12.13]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 22:09:18 +0100 Message-ID: <45D0D77F.8030705@ericsson.com> Date: Mon, 12 Feb 2007 22:09:19 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: IETF AVT WG , behave@ietf.org Content-Type: multipart/mixed; boundary="------------020108020609070503020100" X-OriginalArrivalTime: 12 Feb 2007 21:09:18.0823 (UTC) FILETIME=[0F3BA770:01C74EEA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: Subject: [BEHAVE] [Fwd: Last Call: draft-wing-behave-symmetric-rtprtcp (Common Local Transmit and Receive Ports (Symmetric RTP)) to Informational RFC] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. --------------020108020609070503020100 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, This document has been raised before in both AVT and BEHAVE WG. I have chosen to AD sponsor this document for publication as informational status because it seems to be of general interest. You have 4 weeks to provide any comments on the document. 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 ---------------------------------------------------------------------- --------------020108020609070503020100 Content-Type: message/rfc822; name*0="Last Call: draft-wing-behave-symmetric-rtprtcp (Common Local Tr"; name*1="ansmit and Receive Ports (Symmetric RTP)) to Informational RFC" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="Last Call: draft-wing-behave-symmetric-rtprtcp (Common Local"; filename*1=" Transmit and Receive Ports (Symmetric RTP)) to Information"; filename*2="al RFC" Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw103.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 21:49:27 +0100 Received: from mailgw1.ericsson.se ([193.180.251.45]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 21:49:27 +0100 Received: from mailgw1.ericsson.se (unknown [127.0.0.1]) by mailgw1.ericsson.se (Symantec Mail Security) with ESMTP id 50A0C402E5; Mon, 12 Feb 2007 21:49:27 +0100 (CET) X-AuditID: c1b4fb2d-b05a6bb000003506-68-45d0d2d68629 Received: from megatron.ietf.org (lists.ietf.ORG [156.154.16.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgw1.ericsson.se (Symantec Mail Security) with ESMTP id CD9914033F; Mon, 12 Feb 2007 21:49:26 +0100 (CET) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGi39-00057P-Ug; Mon, 12 Feb 2007 15:45:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGi38-00057D-6Q for ietf-announce@ietf.org; Mon, 12 Feb 2007 15:45:22 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HGi37-0001WH-UO for ietf-announce@ietf.org; Mon, 12 Feb 2007 15:45:22 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id DD1AB2AD13 for ; Mon, 12 Feb 2007 20:44:51 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HGi2d-0006lu-Lc for ietf-announce@ietf.org; Mon, 12 Feb 2007 15:44:51 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 12 Feb 2007 15:44:51 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: Last Call: draft-wing-behave-symmetric-rtprtcp (Common Local Transmit and Receive Ports (Symmetric RTP)) to Informational RFC X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: ietf-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-announce-bounces@ietf.org X-Brightmail-Tracker: AAAAAA== Return-Path: ietf-announce-bounces@ietf.org X-OriginalArrivalTime: 12 Feb 2007 20:49:27.0392 (UTC) FILETIME=[4915B600:01C74EE7] The IESG has received a request from an individual submitter to consider the following document: - 'Common Local Transmit and Receive Ports (Symmetric RTP) ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-03-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-wing-behave-symmetric-rtprtcp-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13165&rfc_flag=0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --------------020108020609070503020100 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 --------------020108020609070503020100-- From behave-bounces@ietf.org Mon Feb 12 16:28:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGiia-0006K6-K4; Mon, 12 Feb 2007 16:28:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGiiY-0006Jx-MS; Mon, 12 Feb 2007 16:28:10 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGiiX-0007FW-Di; Mon, 12 Feb 2007 16:28:10 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l1CLK6Z11821; Mon, 12 Feb 2007 16:20:06 -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] [Fwd: Last Call: draft-wing-behave-symmetric-rtprtcp (Common Local Transmit and Receive Ports (Symmetric RTP)) to Informational RFC] Date: Mon, 12 Feb 2007 15:27:55 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0F21D703@zrc2hxm0.corp.nortel.com> In-Reply-To: <45D0D77F.8030705@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] [Fwd: Last Call: draft-wing-behave-symmetric-rtprtcp (Common Local Transmit and Receive Ports (Symmetric RTP)) to Informational RFC] Thread-Index: AcdO6l3gxbbx0BwMRx2CLZguomeVFQAAZFCg From: "Francois Audet" To: "Magnus Westerlund" , "IETF AVT WG" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Thanks for doing this Magnus. I have one comment. I think we should add as a last statement at the end of=20 section 3 "Recommended usage" that says something like: "It is therefore RECOMMENDED that symmetric RTP and symmetric RTCP always=20 be used for bi-directional RTP media streams." Otherwise, the draft doesn't specifically recommend anything. > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: Monday, February 12, 2007 13:09 > To: IETF AVT WG; behave@ietf.org > Subject: [BEHAVE] [Fwd: Last Call:=20 > draft-wing-behave-symmetric-rtprtcp (Common Local Transmit=20 > and Receive Ports (Symmetric RTP)) to Informational RFC] >=20 > Hi, >=20 > This document has been raised before in both AVT and BEHAVE=20 > WG. I have chosen to AD sponsor this document for publication=20 > as informational status because it seems to be of general=20 > interest. You have 4 weeks to provide any comments on the document. >=20 > Magnus Westerlund >=20 > 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 > ---------------------------------------------------------------------- >=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 12 16:44:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGiyV-0007Nv-MM; Mon, 12 Feb 2007 16:44:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGiyU-0007Nq-Vz for behave@ietf.org; Mon, 12 Feb 2007 16:44:38 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGiyT-00034W-O5 for behave@ietf.org; Mon, 12 Feb 2007 16:44:38 -0500 Received: from MA0034AVEXU1.global.avaya.com (h135-35-75-7.avaya.com [135.35.75.7]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l1CLiboA005227 for ; Mon, 12 Feb 2007 16:44:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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] [Fwd: Last Call: draft-wing-behave-symmetric-rtprtcp (Common Local Transmit and Receive Ports (Symmetric RTP)) to Informational RFC] Date: Mon, 12 Feb 2007 16:44:36 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] [Fwd: Last Call: draft-wing-behave-symmetric-rtprtcp (Common Local Transmit and Receive Ports (Symmetric RTP)) to Informational RFC] Thread-Index: AcdO6muYS7+//tfJRoGGddlUZmIMGgAAwPQQ References: <45D0D77F.8030705@ericsson.com> From: "Rodrig, Benny \(Benny\)" To: "Dan Wing" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org It would probably be desired to update the language about types of NATs in section 3 from using the terms of RFC 3489 and referencing it to using BEHAVE terminology and referencing RFC 4787.=20 Benny -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Monday, February 12, 2007 4:09 PM To: IETF AVT WG; behave@ietf.org Subject: [BEHAVE] [Fwd: Last Call: draft-wing-behave-symmetric-rtprtcp (Common Local Transmit and Receive Ports (Symmetric RTP)) to Informational RFC] Hi, This document has been raised before in both AVT and BEHAVE WG. I have chosen to AD sponsor this document for publication as informational status because it seems to be of general interest. You have 4 weeks to provide any comments on the document. 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 Mon Feb 12 23:21:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGpAX-0007c5-GR; Mon, 12 Feb 2007 23:21:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGpAW-0007bz-Mg for behave@ietf.org; Mon, 12 Feb 2007 23:21:28 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGpAV-0005t8-E8 for behave@ietf.org; Mon, 12 Feb 2007 23:21:28 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 12 Feb 2007 20:21:26 -0800 X-IronPort-AV: i="4.14,161,1170662400"; d="scan'208"; a="388411135:sNHT42703732" 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 l1D4LQWT007327 for ; Mon, 12 Feb 2007 20:21:26 -0800 Received: from dwingwxp ([10.32.240.194]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1D4LQnF001875 for ; Mon, 12 Feb 2007 20:21:26 -0800 (PST) From: "Dan Wing" To: "BEHAVE Working Group" Date: Mon, 12 Feb 2007 20:21:25 -0800 Message-ID: <063d01c74f26$6d4f17c0$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdPJmzwKD4393x3QgS1ncYUhlhdVg== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=954; t=1171340486; x=1172204486; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20protocol=20design=20techniques,=20draft-ford-behave-app |Sender:=20; bh=P5mRpKKyk49aQzuObCYmiIhk7lPT0QInYPGePnny0as=; b=FhpBnP+Xb1aHBy55VjAfG41eiYJNjmIvt+zTARTLDh1d+rKh9jZY2w+IqMSPk5La33cKJqHZ 0H9wsqXK2eneKX6vY7bN0KFcSYOHNf+RVT8mUap+kNwQ0OdMcfMhv5ZK; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [BEHAVE] protocol design techniques, draft-ford-behave-app X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 have the following milestone on our charter: Submit a BCP that discusses protocol design techniques for using the existing set of NAT traversal approaches to IESG In essence: describe how to do something like ICE. The document draft-ford-behave-app appears to meet this milestone. At the last IETF meeting, there was some discussion around adopting draft-ford-behave-app. Several people had concerns that the authors would not be able to incorporate feedback from meetings if the authors were not present at the meetings (physically or via audio + Jabber). This situation hasn't changed, but I nonetheless suggest that we adopt this document as a WG document. I am also soliciting a volunteer to present the document in Prague so that working group feedback can be brought back to the authors for incorporation into the next version. Please reply to me or the list with any comments or suggestions. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Feb 13 00:20:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGq5Q-0001Ib-PC; Tue, 13 Feb 2007 00:20:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGq5P-0001IC-IO for behave@ietf.org; Tue, 13 Feb 2007 00:20:15 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGq5O-0001wI-90 for behave@ietf.org; Tue, 13 Feb 2007 00:20:15 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 12 Feb 2007 21:19:50 -0800 X-IronPort-AV: i="4.14,161,1170662400"; d="scan'208"; a="39030412:sNHT83659447224" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l1D5Jnil030140; Mon, 12 Feb 2007 21:19:49 -0800 Received: from dwingwxp ([10.32.240.194]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1D5Jcho025155; Mon, 12 Feb 2007 21:19:38 -0800 (PST) From: "Dan Wing" To: "'Rodrig, Benny \(Benny\)'" Subject: RE: [BEHAVE] [Fwd: Last Call: draft-wing-behave-symmetric-rtprtcp (Common Local Transmit and Receive Ports (Symmetric RTP)) to Informational RFC] Date: Mon, 12 Feb 2007 21:19:38 -0800 Message-ID: <065a01c74f2e$94d69810$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcdO6muYS7+//tfJRoGGddlUZmIMGgAAwPQQABA9JeA= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1915; t=1171343989; x=1172207989; c=relaxed/simple; s=sjdkim8002; 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]=20[Fwd=3A=20Last=20Call=3A=20draft-wing-beha ve-symmetric-rtprtcp=20(Common=20Local=20Transmit=20and=20Receive=20Ports= 20(Symmetric=20RTP))=20to=20Informational=20RFC] |Sender:=20; bh=VNGTFTIowGlNsFUjAODEr0p9P7S7DQ82AOglwiJalcI=; b=B06k/oHuNl4MKEPvaGgKpxDye0KO7Q+seJkPmSI+5Ju5d5kNP0YuRidAj3hqS9gvpvmVcd4j uwECryJ9ymuinNBOA4a332nTulRGHBtqExNo7/B6mdOU7KsmNpVlSJKa; Authentication-Results: sj-dkim-8; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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, I will make that change. My document was submitted to the RFC editor long before draft-ietf-behave-nat-udp made it to RFC and waiting for publication while progress has marched on. -d > -----Original Message----- > From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] > Sent: Monday, February 12, 2007 1:45 PM > To: Dan Wing > Cc: behave@ietf.org; Magnus Westerlund > Subject: RE: [BEHAVE] [Fwd: Last Call: > draft-wing-behave-symmetric-rtprtcp (Common Local Transmit > and Receive Ports (Symmetric RTP)) to Informational RFC] > > It would probably be desired to update the language about > types of NATs > in section 3 from using the terms of RFC 3489 and referencing it to > using BEHAVE terminology and referencing RFC 4787. > > Benny > > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Monday, February 12, 2007 4:09 PM > To: IETF AVT WG; behave@ietf.org > Subject: [BEHAVE] [Fwd: Last Call: draft-wing-behave-symmetric-rtprtcp > (Common Local Transmit and Receive Ports (Symmetric RTP)) to > Informational RFC] > > Hi, > > This document has been raised before in both AVT and BEHAVE WG. I have > chosen to AD sponsor this document for publication as informational > status because it seems to be of general interest. You have 4 weeks to > provide any comments on the document. > > 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 Tue Feb 13 15:18:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH45j-00053D-8k; Tue, 13 Feb 2007 15:17:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH45h-000530-7R; Tue, 13 Feb 2007 15:17:29 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH45Y-0003Pu-Go; Tue, 13 Feb 2007 15:17:29 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id ACBF820415; Tue, 13 Feb 2007 21:17:11 +0100 (CET) X-AuditID: c1b4fb3c-aefc6bb0000007de-56-45d21cc753c9 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8C96720414; Tue, 13 Feb 2007 21:17:11 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Feb 2007 21:17:10 +0100 Received: from [138.85.12.222] ([138.85.12.222]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Feb 2007 21:17:10 +0100 Message-ID: <45D21CC4.10909@ericsson.com> Date: Tue, 13 Feb 2007 21:17:08 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [BEHAVE] [Fwd: Last Call: draft-wing-behave-symmetric-rtprtcp (Common Local Transmit and Receive Ports (Symmetric RTP)) to Informational RFC] References: <45D0D77F.8030705@ericsson.com> In-Reply-To: <45D0D77F.8030705@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-OriginalArrivalTime: 13 Feb 2007 20:17:10.0388 (UTC) FILETIME=[F0F41B40:01C74FAB] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: behave@ietf.org, IETF AVT WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org There has been raised a comment that this document should contain a=20 normative recommendation on using symmetric ports. However to make this=20 happen the document would need to be a BCP. I am willing to consider=20 this but would like to have AVT and Behave WG participant's view on=20 doing this before progressing down that road and updating the IETF last=20 call. So please provide comments by Tuesday 20th of Feb on this issue. Best Regards Magnus Magnus Westerlund skrev: > Hi, >=20 > This document has been raised before in both AVT and BEHAVE WG. I have=20 > chosen to AD sponsor this document for publication as informational=20 > status because it seems to be of general interest. You have 4 weeks to=20 > provide any comments on the document. >=20 > Magnus Westerlund >=20 > 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 > ---------------------------------------------------------------------- >=20 > -----------------------------------------------------------------------= - >=20 > =C3=84mne: > Last Call: draft-wing-behave-symmetric-rtprtcp (Common Local Transmit=20 > and Receive Ports (Symmetric RTP)) to Informational RFC > Fr=C3=A5n: > The IESG > Datum: > Mon, 12 Feb 2007 15:44:51 -0500 > Till: > IETF-Announce >=20 > Till: > IETF-Announce >=20 >=20 > The IESG has received a request from an individual submitter to conside= r > the following document: >=20 > - 'Common Local Transmit and Receive Ports (Symmetric RTP) ' > as an Informational RFC >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2007-03-12. Exceptionally,=20 > comments may be sent to iesg@ietf.org instead. In either case, please=20 > retain the beginning of the Subject line to allow automated sorting. >=20 > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-wing-behave-symmetric-rtprtcp= -01.txt >=20 >=20 > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dT= ag=3D13165&rfc_flag=3D0 >=20 >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave --=20 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 Tue Feb 13 15:44:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH4Vc-00022m-QI; Tue, 13 Feb 2007 15:44:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH4Va-00021F-Bk; Tue, 13 Feb 2007 15:44:14 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH4VY-0006Uk-Si; Tue, 13 Feb 2007 15:44:14 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 13 Feb 2007 12:44:10 -0800 X-IronPort-AV: i="4.14,164,1170662400"; d="scan'208"; a="388748234:sNHT2246296632" 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 l1DKi8Q8006695; Tue, 13 Feb 2007 12:44:08 -0800 Received: from dwingwxp ([10.32.240.194]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1DKi8nF017281; Tue, 13 Feb 2007 12:44:08 -0800 (PST) From: "Dan Wing" To: "'Magnus Westerlund'" Subject: RE: [BEHAVE] [Fwd: Last Call: draft-wing-behave-symmetric-rtprtcp(Common Local Transmit and Receive Ports (Symmetric RTP)) toInformational RFC] Date: Tue, 13 Feb 2007 12:44:07 -0800 Message-ID: <083301c74faf$b570fb20$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <45D21CC4.10909@ericsson.com> Thread-Index: AcdPrEX0YWQ8YVSgQSOznluD8gQH6wAAUhWg DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4713; t=1171399448; x=1172263448; 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]=20[Fwd=3A=20Last=20Call=3A=20draft-wing-beha ve-symmetric-rtprtcp(Common=20Local=20Transmit=20and=20Receive=20Ports=20( Symmetric=20RTP))=20toInformational=20RFC] |Sender:=20; bh=tZd7LPX57cS/LVqivnXV2fL3WlekF1a2avh0JfXJREw=; b=H807YU3/c5ffdpDvSXMZ+zQZ/sXg/h+hMQP+88SO2stAG96AflsfvVWAMFrWpVAE5KlJr2Mx l2xKg/9V2nkEqkn7gLKgj9ZSEfkIkhgiYJzLj7eaTd8FhwfVagMLVhAE; 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: 93e7fb8fef2e780414389440f367c879 Cc: behave@ietf.org, 'IETF AVT WG' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Per Francois's suggestion, the following new text would be placed at the = end of section 3 of draft-wing-behave-symmetric-rtprtcp: "For these reasons it is RECOMMENDED that symmetric RTP and=20 symmetric RTCP always be used for bi-directional RTP media=20 streams."=20 -d > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: Tuesday, February 13, 2007 12:17 PM > To: Magnus Westerlund > Cc: behave@ietf.org; IETF AVT WG > Subject: Re: [BEHAVE] [Fwd: Last Call:=20 > draft-wing-behave-symmetric-rtprtcp(Common Local Transmit and=20 > Receive Ports (Symmetric RTP)) toInformational RFC] >=20 > There has been raised a comment that this document should contain a=20 > normative recommendation on using symmetric ports. However to=20 > make this=20 > happen the document would need to be a BCP. I am willing to consider=20 > this but would like to have AVT and Behave WG participant's view on=20 > doing this before progressing down that road and updating the=20 > IETF last=20 > call. So please provide comments by Tuesday 20th of Feb on this issue. >=20 > Best Regards >=20 > Magnus >=20 > Magnus Westerlund skrev: > > Hi, > >=20 > > This document has been raised before in both AVT and BEHAVE=20 > WG. I have=20 > > chosen to AD sponsor this document for publication as informational=20 > > status because it seems to be of general interest. You have=20 > 4 weeks to=20 > > provide any comments on the document. > >=20 > > Magnus Westerlund > >=20 > > IETF Transport Area Director & TSVWG Chair > >=20 > ---------------------------------------------------------------------- > > Multimedia Technologies, Ericsson Research EAB/TVA/A > >=20 > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 8 4048287 > > Torshamsgatan 23 | Fax +46 8 7575550 > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > >=20 > ---------------------------------------------------------------------- > >=20 > >=20 > -------------------------------------------------------------- > ---------- > >=20 > > =C4mne: > > Last Call: draft-wing-behave-symmetric-rtprtcp (Common=20 > Local Transmit=20 > > and Receive Ports (Symmetric RTP)) to Informational RFC > > Fr=E5n: > > The IESG > > Datum: > > Mon, 12 Feb 2007 15:44:51 -0500 > > Till: > > IETF-Announce > >=20 > > Till: > > IETF-Announce > >=20 > >=20 > > The IESG has received a request from an individual=20 > submitter to consider > > the following document: > >=20 > > - 'Common Local Transmit and Receive Ports (Symmetric RTP) ' > > as an=20 > Informational RFC > >=20 > > The IESG plans to make a decision in the next few weeks,=20 > and solicits > > final comments on this action. Please send substantive=20 > comments to the > > ietf@ietf.org mailing lists by 2007-03-12. Exceptionally,=20 > > comments may be sent to iesg@ietf.org instead. In either=20 > case, please=20 > > retain the beginning of the Subject line to allow automated sorting. > >=20 > > The file can be obtained via > >=20 > http://www.ietf.org/internet-drafts/draft-wing-behave-symmetri > c-rtprtcp-01.txt > >=20 > >=20 > > IESG discussion can be tracked via > >=20 > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dvie > w_id&dTag=3D13165&rfc_flag=3D0 > >=20 > >=20 > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf-announce > >=20 > >=20 > >=20 > >=20 > -------------------------------------------------------------- > ---------- > >=20 > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www1.ietf.org/mailman/listinfo/behave >=20 >=20 > --=20 >=20 > Magnus Westerlund >=20 > 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 > ---------------------------------------------------------------------- >=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 Tue Feb 13 15:50:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH4bG-00081i-9n; Tue, 13 Feb 2007 15:50:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH4bD-0007yu-4b; Tue, 13 Feb 2007 15:50:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH4bC-0007IQ-Lf; Tue, 13 Feb 2007 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 8495726EFB; Tue, 13 Feb 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HH4bC-0002wR-8m; Tue, 13 Feb 2007 15:50:02 -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, 13 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: behave@ietf.org Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-p2p-state-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 : State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs) Author(s) : P. Srisuresh, et al. Filename : draft-ietf-behave-p2p-state-01.txt Pages : 34 Date : 2007-2-13 This memo documents the various methods known to be in use by peer-to-peer (P2P) applications for communication in the presence of Network Address Translators (NATs) at the current time. This memo covers NAT traversal approaches used by both TCP and UDP based applications. This memo is not an endorsement of the methods described, but merely an attempt to capture them in a document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-p2p-state-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-p2p-state-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-p2p-state-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: <2007-2-13124701.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-p2p-state-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-p2p-state-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-13124701.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 Feb 13 15:55:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH4gS-0006K2-Ga; Tue, 13 Feb 2007 15:55:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH4gQ-0006JD-MV for behave@ietf.org; Tue, 13 Feb 2007 15:55:26 -0500 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HH4fw-000068-II for behave@ietf.org; Tue, 13 Feb 2007 15:55:26 -0500 Received: from Quinthar ([67.169.180.240]) by quinthar.com for ; Tue, 13 Feb 2007 12:54:42 -0800 From: "David Barrett" To: "'Dan Wing'" , "'Magnus Westerlund'" Subject: RE: [BEHAVE] [Fwd: Last Call:draft-wing-behave-symmetric-rtprtcp(Common Local Transmit andReceive Ports (Symmetric RTP)) toInformational RFC] Date: Tue, 13 Feb 2007 12:54:40 -0800 Message-ID: <07fa01c74fb1$2fc20a80$6b02a8c0@Quinthar> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <083301c74faf$b570fb20$c2f0200a@amer.cisco.com> Thread-Index: AcdPrEX0YWQ8YVSgQSOznluD8gQH6wAAUhWgAAC0ykA= X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: behave@ietf.org, 'IETF AVT WG' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Though I think it's still a good recommendation, one thing I found when working on iGlance was the case where two users were each behind a = different TURN relay server. With symmetric RTP (if I understand correctly), for me to send a packet = to you I need to send it up to my TURN server, which forwards it to your = TURN server, which sends it to you. Ideally I'd send it to your TURN server direct, and cut out one relay. The problem with this is it means our RTP isn't strictly symmetric -- I receive from one place (my TURN server), but send to another (your TURN server). Am I misunderstanding how symmetric RTP works? Perhaps this is too = minor a point to discuss here, however. -david > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Tuesday, February 13, 2007 12:44 PM > To: 'Magnus Westerlund' > Cc: behave@ietf.org; 'IETF AVT WG' > Subject: RE: [BEHAVE] [Fwd: Last Call:draft-wing-behave-symmetric- > rtprtcp(Common Local Transmit andReceive Ports (Symmetric RTP)) > toInformational RFC] >=20 > Per Francois's suggestion, the following new text would be placed at = the > end > of section 3 of draft-wing-behave-symmetric-rtprtcp: >=20 > "For these reasons it is RECOMMENDED that symmetric RTP and > symmetric RTCP always be used for bi-directional RTP media > streams." >=20 > -d >=20 > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Tuesday, February 13, 2007 12:17 PM > > To: Magnus Westerlund > > Cc: behave@ietf.org; IETF AVT WG > > Subject: Re: [BEHAVE] [Fwd: Last Call: > > draft-wing-behave-symmetric-rtprtcp(Common Local Transmit and > > Receive Ports (Symmetric RTP)) toInformational RFC] > > > > There has been raised a comment that this document should contain a > > normative recommendation on using symmetric ports. However to > > make this > > happen the document would need to be a BCP. I am willing to consider > > this but would like to have AVT and Behave WG participant's view on > > doing this before progressing down that road and updating the > > IETF last > > call. So please provide comments by Tuesday 20th of Feb on this = issue. > > > > Best Regards > > > > Magnus > > > > Magnus Westerlund skrev: > > > Hi, > > > > > > This document has been raised before in both AVT and BEHAVE > > WG. I have > > > chosen to AD sponsor this document for publication as = informational > > > status because it seems to be of general interest. You have > > 4 weeks to > > > provide any comments on the document. > > > > > > 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 > > > > > = ---------------------------------------------------------------------- > > > > > > > > -------------------------------------------------------------- > > ---------- > > > > > > =C4mne: > > > Last Call: draft-wing-behave-symmetric-rtprtcp (Common > > Local Transmit > > > and Receive Ports (Symmetric RTP)) to Informational RFC > > > Fr=E5n: > > > The IESG > > > Datum: > > > Mon, 12 Feb 2007 15:44:51 -0500 > > > Till: > > > IETF-Announce > > > > > > Till: > > > IETF-Announce > > > > > > > > > The IESG has received a request from an individual > > submitter to consider > > > the following document: > > > > > > - 'Common Local Transmit and Receive Ports (Symmetric RTP) ' > > > as an > > Informational RFC > > > > > > The IESG plans to make a decision in the next few weeks, > > and solicits > > > final comments on this action. Please send substantive > > comments to the > > > ietf@ietf.org mailing lists by 2007-03-12. Exceptionally, > > > comments may be sent to iesg@ietf.org instead. In either > > case, please > > > retain the beginning of the Subject line to allow automated = sorting. > > > > > > The file can be obtained via > > > > > http://www.ietf.org/internet-drafts/draft-wing-behave-symmetri > > c-rtprtcp-01.txt > > > > > > > > > IESG discussion can be tracked via > > > > > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dvie > > w_id&dTag=3D13165&rfc_flag=3D0 > > > > > > > > > _______________________________________________ > > > IETF-Announce mailing list > > > IETF-Announce@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ietf-announce > > > > > > > > > > > > > > -------------------------------------------------------------- > > ---------- > > > > > > _______________________________________________ > > > Behave mailing list > > > Behave@ietf.org > > > https://www1.ietf.org/mailman/listinfo/behave > > > > > > -- > > > > 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 >=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 Tue Feb 13 16:24:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH57u-0004XX-Cc; Tue, 13 Feb 2007 16:23:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH4sl-0008Be-Ap; Tue, 13 Feb 2007 16:08:11 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH4sK-0002Nz-Uk; Tue, 13 Feb 2007 16:08:10 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1DL4AA6020347; Tue, 13 Feb 2007 23:04:18 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Feb 2007 23:07:00 +0200 Received: from esebe108.NOE.Nokia.com ([172.21.138.114]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Feb 2007 23:07:28 +0200 Received: from 172.21.143.123 ([172.21.143.123]) by esebe108.NOE.Nokia.com ([172.21.138.114]) with Microsoft Exchange Server HTTP-DAV ; Tue, 13 Feb 2007 21:07:27 +0000 From: "Denis-Courmont Remi \(Nokia-TP-MSW/Helsinki\)" To: "ext David Barrett" , "'Dan Wing'" , "'Magnus Westerlund'" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] [Fwd: LastCall:draft-wing-behave-symmetric-rtprtcp(Co mmon Local TransmitandReceive Ports (Symmetric RTP)) toInformational RFC] Date: Tue, 13 Feb 2007 21:07:24 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Thread-Topic: [BEHAVE] [Fwd: LastCall:draft-wing-behave-symmetric-rtprtcp(Co mmon Local TransmitandReceive Ports (Symmetric RTP)) toInformational RFC] Thread-Index: AcdPrEX0YWQ8YVSgQSOznluD8gQH6wAAUhWgAAC0ykAAAKFKQw== Message-ID: <1a6401c74fb2$e69b1860$7b8f15ac@NOE.Nokia.com> X-Mailer: EAS Version 1.00 MIME-Version: 1.0 Content-Language: i-default X-OriginalArrivalTime: 13 Feb 2007 21:07:28.0571 (UTC) FILETIME=[F7EE48B0:01C74FB2] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070213230418-4EC45BB0-2E3A68A2/1541828286-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 3.1 (+++) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Cc: behave@ietf.org, 'IETF AVT WG' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hmm... Bypassing TURN relays might be tempting but IMHO you should stick = to whatever ICE yield. If only one TURN relay is needed, ICE ought to = find it out. Otherwise, it could that policy mandates TURN or whatever = requires relays on both sides... R=C3=A9mi Denis-Courmont --- message original --- De : "ext David Barrett" Objet : RE: [BEHAVE] [Fwd: = LastCall:draft-wing-behave-symmetric-rtprtcp(Common Local = TransmitandReceive Ports (Symmetric RTP)) toInformational RFC] Date : 13 f=C3=A9vrier 2007 Heure : 22:56:18 Though I think it's still a good recommendation, one thing I found when working on iGlance was the case where two users were each behind a = different TURN relay server. With symmetric RTP (if I understand correctly), for me to send a packet = to you I need to send it up to my TURN server, which forwards it to your = TURN server, which sends it to you. Ideally I'd send it to your TURN server direct, and cut out one relay. The problem with this is it means our RTP isn't strictly symmetric -- I receive from one place (my TURN server), but send to another (your TURN server). Am I misunderstanding how symmetric RTP works? Perhaps this is too = minor a point to discuss here, however. -david > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Tuesday, February 13, 2007 12:44 PM > To: 'Magnus Westerlund' > Cc: behave@ietf.org; 'IETF AVT WG' > Subject: RE: [BEHAVE] [Fwd: Last Call:draft-wing-behave-symmetric- > rtprtcp(Common Local Transmit andReceive Ports (Symmetric RTP)) > toInformational RFC] >=20 > Per Francois's suggestion, the following new text would be placed at = the > end > of section 3 of draft-wing-behave-symmetric-rtprtcp: >=20 > "For these reasons it is RECOMMENDED that symmetric RTP and > symmetric RTCP always be used for bi-directional RTP media > streams." >=20 > -d >=20 > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Tuesday, February 13, 2007 12:17 PM > > To: Magnus Westerlund > > Cc: behave@ietf.org; IETF AVT WG > > Subject: Re: [BEHAVE] [Fwd: Last Call: > > draft-wing-behave-symmetric-rtprtcp(Common Local Transmit and > > Receive Ports (Symmetric RTP)) toInformational RFC] > > > > There has been raised a comment that this document should contain a > > normative recommendation on using symmetric ports. However to > > make this > > happen the document would need to be a BCP. I am willing to consider > > this but would like to have AVT and Behave WG participant's view on > > doing this before progressing down that road and updating the > > IETF last > > call. So please provide comments by Tuesday 20th of Feb on this = issue. > > > > Best Regards > > > > Magnus > > > > Magnus Westerlund skrev: > > > Hi, > > > > > > This document has been raised before in both AVT and BEHAVE > > WG. I have > > > chosen to AD sponsor this document for publication as = informational > > > status because it seems to be of general interest. You have > > 4 weeks to > > > provide any comments on the document. > > > > > > 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 > > > > > = ---------------------------------------------------------------------- > > > > > > > > -------------------------------------------------------------- > > ---------- > > > > > > =C3=84mne: > > > Last Call: draft-wing-behave-symmetric-rtprtcp (Common > > Local Transmit > > > and Receive Ports (Symmetric RTP)) to Informational RFC > > > Fr=C3=A5n: > > > The IESG > > > Datum: > > > Mon, 12 Feb 2007 15:44:51 -0500 > > > Till: > > > IETF-Announce > > > > > > Till: > > > IETF-Announce > > > > > > > > > The IESG has received a request from an individual > > submitter to consider > > > the following document: > > > > > > - 'Common Local Transmit and Receive Ports (Symmetric RTP) ' > > > as an > > Informational RFC > > > > > > The IESG plans to make a decision in the next few weeks, > > and solicits > > > final comments on this action. Please send substantive > > comments to the > > > ietf@ietf.org mailing lists by 2007-03-12. Exceptionally, > > > comments may be sent to iesg@ietf.org instead. In either > > case, please > > > retain the beginning of the Subject line to allow automated = sorting. > > > > > > The file can be obtained via > > > > > http://www.ietf.org/internet-drafts/draft-wing-behave-symmetri > > c-rtprtcp-01.txt > > > > > > > > > IESG discussion can be tracked via > > > > > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dvie > > w_id&dTag=3D13165&rfc_flag=3D0 > > > > > > > > > _______________________________________________ > > > IETF-Announce mailing list > > > IETF-Announce@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ietf-announce > > > > > > > > > > > > > > -------------------------------------------------------------- > > ---------- > > > > > > _______________________________________________ > > > Behave mailing list > > > Behave@ietf.org > > > https://www1.ietf.org/mailman/listinfo/behave > > > > > > -- > > > > 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 >=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 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Feb 13 16:26:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH5Ad-0005UK-0K; Tue, 13 Feb 2007 16:26:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH5Aa-0005Tj-FQ; Tue, 13 Feb 2007 16:26:36 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH5AU-0006gF-QD; Tue, 13 Feb 2007 16:26:36 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 13 Feb 2007 13:26:30 -0800 X-IronPort-AV: i="4.14,164,1170662400"; d="scan'208"; a="39283429:sNHT147035007" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l1DLQUWP022987; Tue, 13 Feb 2007 13:26:30 -0800 Received: from dwingwxp ([10.32.240.194]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1DLQNho000703; Tue, 13 Feb 2007 13:26:23 -0800 (PST) From: "Dan Wing" To: "'David Barrett'" , "'Magnus Westerlund'" Subject: RE: [BEHAVE] [Fwd: Last Call:draft-wing-behave-symmetric-rtprtcp(Common Local Transmit andReceive Ports (Symmetric RTP)) toInformational RFC] Date: Tue, 13 Feb 2007 13:26:22 -0800 Message-ID: <0a3401c74fb5$a01f9e10$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <07fa01c74fb1$2fc20a80$6b02a8c0@Quinthar> Thread-Index: AcdPrEX0YWQ8YVSgQSOznluD8gQH6wAAUhWgAAC0ykAAASKhMA== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7399; t=1171401990; x=1172265990; c=relaxed/simple; s=sjdkim8002; 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]=20[Fwd=3A=20Last=20Call=3Adraft-wing-behave- symmetric-rtprtcp(Common=20Local=20Transmit=20andReceive=20Ports=20(Symmet ric=20RTP))=20toInformational=20RFC] |Sender:=20; bh=zMaMynsO7amXjWUWyjBctdM3QIryeiiK3V6jH3HU1es=; b=Yo5B1ddiyOpS6nBUkjtjkh3UUEF6fdC3RANFlgmQdP35Aja6SjB6goE0oVmSicb2ZcLdfEnC FcTjTwv7uD2A07KcKYbdnI+IibHVfuLc14t1TkE1pJUUt89Tl76ilRxh; Authentication-Results: sj-dkim-8; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: behave@ietf.org, 'IETF AVT WG' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Some NATs will close down NAT bindings after some number of seconds if = there is only outside->inside traffic and no inside->outside traffic on that = same 5-tuple. If you were to encounter such a NAT with the optimization you describe below, the RTP traffic from the TURN server would stop after awhile. I suppose you could work around that NAT behavior, and still do this optimization technique, if you were to send some sort of outgoing traffic (inside->outside) to your own TURN server. -d =20 > -----Original Message----- > From: David Barrett [mailto:dbarrett@quinthar.com]=20 > Sent: Tuesday, February 13, 2007 12:55 PM > To: 'Dan Wing'; 'Magnus Westerlund' > Cc: behave@ietf.org; 'IETF AVT WG' > Subject: RE: [BEHAVE] [Fwd: Last=20 > Call:draft-wing-behave-symmetric-rtprtcp(Common Local=20 > Transmit andReceive Ports (Symmetric RTP)) toInformational RFC] >=20 > Though I think it's still a good recommendation, one thing I=20 > found when > working on iGlance was the case where two users were each=20 > behind a different > TURN relay server. >=20 > With symmetric RTP (if I understand correctly), for me to=20 > send a packet to > you I need to send it up to my TURN server, which forwards it=20 > to your TURN > server, which sends it to you. Ideally I'd send it to your=20 > TURN server > direct, and cut out one relay. >=20 > The problem with this is it means our RTP isn't strictly=20 > symmetric -- I > receive from one place (my TURN server), but send to another=20 > (your TURN > server). >=20 > Am I misunderstanding how symmetric RTP works? Perhaps this=20 > is too minor a > point to discuss here, however. >=20 > -david >=20 > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: Tuesday, February 13, 2007 12:44 PM > > To: 'Magnus Westerlund' > > Cc: behave@ietf.org; 'IETF AVT WG' > > Subject: RE: [BEHAVE] [Fwd: Last Call:draft-wing-behave-symmetric- > > rtprtcp(Common Local Transmit andReceive Ports (Symmetric RTP)) > > toInformational RFC] > >=20 > > Per Francois's suggestion, the following new text would be=20 > placed at the > > end > > of section 3 of draft-wing-behave-symmetric-rtprtcp: > >=20 > > "For these reasons it is RECOMMENDED that symmetric RTP and > > symmetric RTCP always be used for bi-directional RTP media > > streams." > >=20 > > -d > >=20 > > > -----Original Message----- > > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > > Sent: Tuesday, February 13, 2007 12:17 PM > > > To: Magnus Westerlund > > > Cc: behave@ietf.org; IETF AVT WG > > > Subject: Re: [BEHAVE] [Fwd: Last Call: > > > draft-wing-behave-symmetric-rtprtcp(Common Local Transmit and > > > Receive Ports (Symmetric RTP)) toInformational RFC] > > > > > > There has been raised a comment that this document should=20 > contain a > > > normative recommendation on using symmetric ports. However to > > > make this > > > happen the document would need to be a BCP. I am willing=20 > to consider > > > this but would like to have AVT and Behave WG=20 > participant's view on > > > doing this before progressing down that road and updating the > > > IETF last > > > call. So please provide comments by Tuesday 20th of Feb=20 > on this issue. > > > > > > Best Regards > > > > > > Magnus > > > > > > Magnus Westerlund skrev: > > > > Hi, > > > > > > > > This document has been raised before in both AVT and BEHAVE > > > WG. I have > > > > chosen to AD sponsor this document for publication as=20 > informational > > > > status because it seems to be of general interest. You have > > > 4 weeks to > > > > provide any comments on the document. > > > > > > > > Magnus Westerlund > > > > > > > > IETF Transport Area Director & TSVWG Chair > > > > > > >=20 > ---------------------------------------------------------------------- > > > > Multimedia Technologies, Ericsson Research EAB/TVA/A > > > > > > >=20 > ---------------------------------------------------------------------- > > > > Ericsson AB | Phone +46 8 4048287 > > > > Torshamsgatan 23 | Fax +46 8 7575550 > > > > S-164 80 Stockholm, Sweden | mailto:=20 > magnus.westerlund@ericsson.com > > > > > > >=20 > ---------------------------------------------------------------------- > > > > > > > > > > > -------------------------------------------------------------- > > > ---------- > > > > > > > > =C4mne: > > > > Last Call: draft-wing-behave-symmetric-rtprtcp (Common > > > Local Transmit > > > > and Receive Ports (Symmetric RTP)) to Informational RFC > > > > Fr=E5n: > > > > The IESG > > > > Datum: > > > > Mon, 12 Feb 2007 15:44:51 -0500 > > > > Till: > > > > IETF-Announce > > > > > > > > Till: > > > > IETF-Announce > > > > > > > > > > > > The IESG has received a request from an individual > > > submitter to consider > > > > the following document: > > > > > > > > - 'Common Local Transmit and Receive Ports (Symmetric RTP) ' > > > > as an > > > Informational RFC > > > > > > > > The IESG plans to make a decision in the next few weeks, > > > and solicits > > > > final comments on this action. Please send substantive > > > comments to the > > > > ietf@ietf.org mailing lists by 2007-03-12. Exceptionally, > > > > comments may be sent to iesg@ietf.org instead. In either > > > case, please > > > > retain the beginning of the Subject line to allow=20 > automated sorting. > > > > > > > > The file can be obtained via > > > > > > > http://www.ietf.org/internet-drafts/draft-wing-behave-symmetri > > > c-rtprtcp-01.txt > > > > > > > > > > > > IESG discussion can be tracked via > > > > > > > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dvie > > > w_id&dTag=3D13165&rfc_flag=3D0 > > > > > > > > > > > > _______________________________________________ > > > > IETF-Announce mailing list > > > > IETF-Announce@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ietf-announce > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > ---------- > > > > > > > > _______________________________________________ > > > > Behave mailing list > > > > Behave@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/behave > > > > > > > > > -- > > > > > > Magnus Westerlund > > > > > > IETF Transport Area Director & TSVWG Chair > > >=20 > ---------------------------------------------------------------------- > > > Multimedia Technologies, Ericsson Research EAB/TVA/A > > >=20 > ---------------------------------------------------------------------- > > > Ericsson AB | Phone +46 8 4048287 > > > Torshamsgatan 23 | Fax +46 8 7575550 > > > S-164 80 Stockholm, Sweden | mailto:=20 > magnus.westerlund@ericsson.com > > >=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 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Feb 13 17:37:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH6Go-0005sz-KM; Tue, 13 Feb 2007 17:37:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH6Gm-0005oh-Ca; Tue, 13 Feb 2007 17:37:04 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH6Gk-0007x7-Q7; Tue, 13 Feb 2007 17:37:04 -0500 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:63347 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1HH6Gj-0003c1-MR; Tue, 13 Feb 2007 22:37:02 +0000 In-Reply-To: <083301c74faf$b570fb20$c2f0200a@amer.cisco.com> References: <083301c74faf$b570fb20$c2f0200a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <5937EACD-F25C-442E-B407-5564D7955AF0@csperkins.org> Content-Transfer-Encoding: quoted-printable From: Colin Perkins Subject: Re: [AVT] RE: [BEHAVE] [Fwd: Last Call: draft-wing-behave-symmetric-rtprtcp(Common Local Transmit and Receive Ports (Symmetric RTP)) toInformational RFC] Date: Tue, 13 Feb 2007 22:37:09 +0000 To: Magnus Westerlund , Dan Wing X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: behave@ietf.org, IETF AVT WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Magnus, Dan, The draft is good, and adding this text will improve it. Go ahead any =20= publish it... Colin On 13 Feb 2007, at 20:44, Dan Wing wrote: > Per Francois's suggestion, the following new text would be placed =20 > at the end > of section 3 of draft-wing-behave-symmetric-rtprtcp: > > "For these reasons it is RECOMMENDED that symmetric RTP and > symmetric RTCP always be used for bi-directional RTP media > streams." > > -d > >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Tuesday, February 13, 2007 12:17 PM >> To: Magnus Westerlund >> Cc: behave@ietf.org; IETF AVT WG >> Subject: Re: [BEHAVE] [Fwd: Last Call: >> draft-wing-behave-symmetric-rtprtcp(Common Local Transmit and >> Receive Ports (Symmetric RTP)) toInformational RFC] >> >> There has been raised a comment that this document should contain a >> normative recommendation on using symmetric ports. However to >> make this >> happen the document would need to be a BCP. I am willing to consider >> this but would like to have AVT and Behave WG participant's view on >> doing this before progressing down that road and updating the >> IETF last >> call. So please provide comments by Tuesday 20th of Feb on this =20 >> issue. >> >> Best Regards >> >> Magnus >> >> Magnus Westerlund skrev: >>> Hi, >>> >>> This document has been raised before in both AVT and BEHAVE >> WG. I have >>> chosen to AD sponsor this document for publication as informational >>> status because it seems to be of general interest. You have >> 4 weeks to >>> provide any comments on the document. >>> >>> Magnus Westerlund >>> >>> IETF Transport Area Director & TSVWG Chair >>> >> ---------------------------------------------------------------------=20= >> - >>> Multimedia Technologies, Ericsson Research EAB/TVA/A >>> >> ---------------------------------------------------------------------=20= >> - >>> Ericsson AB | Phone +46 8 4048287 >>> Torshamsgatan 23 | Fax +46 8 7575550 >>> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>> >> ---------------------------------------------------------------------=20= >> - >>> >>> >> -------------------------------------------------------------- >> ---------- >>> >>> =C4mne: >>> Last Call: draft-wing-behave-symmetric-rtprtcp (Common >> Local Transmit >>> and Receive Ports (Symmetric RTP)) to Informational RFC >>> Fr=E5n: >>> The IESG >>> Datum: >>> Mon, 12 Feb 2007 15:44:51 -0500 >>> Till: >>> IETF-Announce >>> >>> Till: >>> IETF-Announce >>> >>> >>> The IESG has received a request from an individual >> submitter to consider >>> the following document: >>> >>> - 'Common Local Transmit and Receive Ports (Symmetric RTP) ' >>> as an >> Informational RFC >>> >>> The IESG plans to make a decision in the next few weeks, >> and solicits >>> final comments on this action. Please send substantive >> comments to the >>> ietf@ietf.org mailing lists by 2007-03-12. Exceptionally, >>> comments may be sent to iesg@ietf.org instead. In either >> case, please >>> retain the beginning of the Subject line to allow automated sorting. >>> >>> The file can be obtained via >>> >> http://www.ietf.org/internet-drafts/draft-wing-behave-symmetri >> c-rtprtcp-01.txt >>> >>> >>> IESG discussion can be tracked via >>> >> https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dvie >> w_id&dTag=3D13165&rfc_flag=3D0 >>> >>> >>> _______________________________________________ >>> IETF-Announce mailing list >>> IETF-Announce@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ietf-announce >>> >>> >>> >>> >> -------------------------------------------------------------- >> ---------- >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www1.ietf.org/mailman/listinfo/behave >> >> >> --=20 >> >> Magnus Westerlund >> >> IETF Transport Area Director & TSVWG Chair >> ---------------------------------------------------------------------=20= >> - >> Multimedia Technologies, Ericsson Research EAB/TVA/A >> ---------------------------------------------------------------------=20= >> - >> Ericsson AB | Phone +46 8 4048287 >> Torshamsgatan 23 | Fax +46 8 7575550 >> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------=20= >> - >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 14 11:30:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHN1M-0005w8-Lk; Wed, 14 Feb 2007 11:30:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHN1M-0005vX-2R for behave@ietf.org; Wed, 14 Feb 2007 11:30:16 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHN1K-0002uT-NW for behave@ietf.org; Wed, 14 Feb 2007 11:30:16 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 14 Feb 2007 08:30:14 -0800 X-IronPort-AV: i="4.14,169,1170662400"; d="scan'208"; a="389056538:sNHT47984132" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l1EGUEtv009679; Wed, 14 Feb 2007 08:30:14 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1EGU3iQ008713; Wed, 14 Feb 2007 08:30:13 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 08:30:03 -0800 Received: from [10.32.241.151] ([10.32.241.151]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 08:30:02 -0800 Message-ID: <45D33904.9050008@cisco.com> Date: Wed, 14 Feb 2007 11:29:56 -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: "Alfred E. Heggestad" References: <45C8ABCB.3040106@db.org> In-Reply-To: <45C8ABCB.3040106@db.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Feb 2007 16:30:02.0588 (UTC) FILETIME=[609099C0:01C75055] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2152; t=1171470614; x=1172334614; 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=20rfc3489bis=3A=20clarification=20on=20magic=20cookie, = 20XOR-MAPPED-ADDRESS=0A=20and=20byte=20order |Sender:=20; bh=yf4918V2sOFdBzm+9gnqJOHzM6ktc0Mb4FvUFnWtl6I=; b=lHCMRil3Bd3tvVW7mMk6gzcrC8YhzE+xPz96xFNdQXxug0vegZcykZ/kMN9hFlq9jTaQaVEm wkI95dSfsO6r92ZGUdGhUc33/LJ4nKSH9vvTepzpAWhxga59WqhDE2DZ; 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: 52f7a77164458f8c7b36b66787c853da Cc: behave@ietf.org Subject: [BEHAVE] Re: rfc3489bis: clarification on magic cookie, XOR-MAPPED-ADDRESS and byte order X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org To answer your question - everything is represented in network byte order on the wire. This is generally true in ietf protocols, but I'll restate it. -Jonathan R. Alfred E. Heggestad wrote: > hi > > in rfc3489-bis05 there seem to be some confusion regarding the byte order > of magic cookie and XOR-MAPPED-ADDRESS. could I ask that we include some > info about the byte order in rfc3489-bis06 ? > > my assumption is the following (please correct me if wrong): > > > Section 6: > > > > 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 > > > the magic cookie value is in host byte order, and will be encoded to > network byte order on the wire. correct? > > > > Section 11.10 > > > > For example, using the "^" character to indicate exclusive or, if the > > IP address is 192.168.1.1 (0xc0a80101) and the port is 5555 (0x15B3), > > the X-Port would be 0x15B3 ^ 0x2112 = 0x34A1, and the X-Address would > > be 0xc0a80101 ^ 0x2112A442 = 0xe1baa543. > > the X-port value 0x34A1 above is in host byte order and will be > converted to > network byte order on the wire. correct? > > the X-Address value 0xe1baa543 above is in host byte order and will be > converted to > network byte order on the wire. correct? > > > this stuff should be quite simple to implement, but I know from > implementors that > this is interpreted differently, so we need to make sure that the spec > does not > leave anything open for mis-interpretation. my apologies if this has > been covered > already.. > > thanks > > > /alfred > -- 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 Feb 14 11:39:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHN9t-0002ED-GH; Wed, 14 Feb 2007 11:39:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHN9s-0002Dy-Jj for Behave@ietf.org; Wed, 14 Feb 2007 11:39:04 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHN9p-0004Np-7f for Behave@ietf.org; Wed, 14 Feb 2007 11:39:04 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 14 Feb 2007 08:39:00 -0800 X-IronPort-AV: i="4.14,169,1170662400"; d="scan'208"; a="39460969:sNHT46106523" 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 l1EGd0jA015166; Wed, 14 Feb 2007 08:39:00 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1EGcwnF010181; Wed, 14 Feb 2007 08:39:00 -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); Wed, 14 Feb 2007 08:38:58 -0800 Received: from [10.32.241.151] ([10.32.241.151]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 08:38:57 -0800 Message-ID: <45D33B1C.8020603@cisco.com> Date: Wed, 14 Feb 2007 11:38:52 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benny Prijono Subject: Re: [BEHAVE] STUN/TURN message type bits References: <45C7A56B.5020705@pjsip.org> In-Reply-To: <45C7A56B.5020705@pjsip.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Feb 2007 16:38:57.0763 (UTC) FILETIME=[9F8DD330:01C75056] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2025; t=1171471140; x=1172335140; 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]=20STUN/TURN=20message=20type=20bits |Sender:=20; bh=bsk+oWteOjgQ5jmUu/IU1VTfHueuIUV9gdH2gMOegfs=; b=dhCJuvKRhf0qf8kpipuXdel3bOk5Mc0oh8g/c68AhAfJoNITyPzqOuEsqm8YGxST9k6rgTSD Rj0/g+RnEAi2IavgfvhWW3hP0eh39ApHWKgTCoPWzw+EaVf8LzRnoa7C; 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: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Benny Prijono wrote: > All, > > I think I need a way to distinguish STUN message classes (i.e. request, > response, or indication), and reading section 6 of the rfc3489bis I > think this is what I conclude for the formula, in traditional C: > > #define IS_REQUEST(msg_type) (((msg_type) & 0x0FF0) == 0x0000) > #define IS_RESPONSE(msg_type) (((msg_type) & 0x0FF0) == 0x0100) > #define IS_ERR_RESPONSE(msg_type) (((msg_type) & 0x0FF0) == 0x0110) > #define IS_INDICATION(msg_type) (((msg_type) & 0x0FF0) == 0x0010) > > Is that right (or wrong)? I think its wrong. The reason is that the class is only two of the 12 bits. So I think its: #define IS_REQUEST(msg_type) (((msg_type) & 0x0110) == 0x0000) #define IS_INDICATION(msg_type) (((msg_type) & 0x0110) == 0x0010) #define IS_SUCCESS_RESP(msg_type) (((msg_type) & 0x0110) == 0x0100) #define IS_ERR_RESP(msg_type) (((msg_type) & 0x0110) == 0x0110) > > If that is right, then I have a question regarding the values for TURN > indications, which currently (as turn-02) are: > > 0x0004 : Send Indication > 0x0115 : Data Indication > 0x0118 : Connect Status Indication > > Somehow I feel that there is no consistency in the value assignment > (Send Indication looks like a request, while the others look like error > responses). So what's the rule here? Yes, the TURN values are wrong. I discussed this at the IETF meeting, that the proposed bitfield approach worked well for existing STUN attributes but would be wrong for the new indications that were recently added to TURN. Those need to be changed in the revision of TURN. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 14 15:08:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHQQN-0007Wf-Iv; Wed, 14 Feb 2007 15:08:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHQQM-0007WS-PT for behave@ietf.org; Wed, 14 Feb 2007 15:08:18 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHQQJ-00054G-DP for behave@ietf.org; Wed, 14 Feb 2007 15:08:18 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 14 Feb 2007 12:07:56 -0800 X-IronPort-AV: i="4.14,170,1170662400"; d="scan'208"; a="389129437:sNHT47249707548" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l1EK7uS6030729 for ; Wed, 14 Feb 2007 12:07:56 -0800 Received: from dwingwxp ([10.32.240.194]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1EK7tnF019727 for ; Wed, 14 Feb 2007 12:07:55 -0800 (PST) From: "Dan Wing" To: Date: Wed, 14 Feb 2007 12:07:54 -0800 Message-ID: <0d9001c75073$d0799ac0$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdQVK8woXBWZuwqS7aJLcqsvh8zpwAHtmiw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1077; t=1171483676; x=1172347676; c=relaxed/simple; s=sjdkim6002; 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:=20FW=3A=2068th=20IETF=20-=20Cutoff=20Dates=20Reminder=20 |Sender:=20; bh=q0s7aixl2/eUtnYMlexCyAJTToZoU5nlqRBIZdYtEwc=; b=Yii2FOHqYkpeiP7MAMqoS6LwG1WgWKE/eAN4MjxpuWnfAVjEeeKz6zqsGB5HtqOjH08X97u3 FMOJxF0hqLgvtcKwY0NJOIoXdGQjl1cQaDM8WdEazW5fI/pqQKYIc5I4; Authentication-Results: sj-dkim-6; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [BEHAVE] FW: 68th IETF - Cutoff Dates Reminder X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: IETF Secretariat [mailto:ietf-secretariat@ietf.org] > Sent: Wednesday, February 14, 2007 8:24 AM > To: IETF Announcement list > Cc: irsg@isi.edu; wgchairs@ietf.org > Subject: 68th IETF - Cutoff Dates Reminder > > Registration Cutoff Dates: > March 9, Friday - Early-Bird registration and payment cut-off at 12:00 > noon ET (17:00 UTC/GMT) > > March 17, Saturday - Final Pre-Registration and Pre-Payment cut-off at > 17:00 ET (21:00 UTC/GMT) > > You can register for the IETF meeting and social event at: > http://www3.ietf.org/meetings/68-IETF.html > > Internet Draft Cutoff Dates: > February 19, Monday - Working Group Chair approval for > initial document > (Version -00) submissions appreciated by 09:00 ET (14:00 UTC/GMT) > > February 26, Monday - Internet Draft Cut-off for initial > document (-00) > submission by 09:00 ET (14:00 UTC/GMT) > > March 5, Monday - Internet Draft final submission cut-off by 09:00 ET > (14:00 UTC/GMT) > > Only 32 days left until the Prague IETF Meeting! > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 14 18:06:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHTCR-0007BK-JJ; Wed, 14 Feb 2007 18:06:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHTCQ-0007BD-Jh for Behave@ietf.org; Wed, 14 Feb 2007 18:06:06 -0500 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHTCN-0002C0-9D for Behave@ietf.org; Wed, 14 Feb 2007 18:06:06 -0500 Received: from [192.168.0.66] (unknown [81.178.58.134]) by smtp.mxes.net (Postfix) with ESMTP id 215F651977; Wed, 14 Feb 2007 18:06:01 -0500 (EST) Message-ID: <45D395D6.2060008@pjsip.org> Date: Wed, 14 Feb 2007 23:05:58 +0000 From: Benny Prijono User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [BEHAVE] STUN/TURN message type bits References: <45C7A56B.5020705@pjsip.org> <45D33B1C.8020603@cisco.com> In-Reply-To: <45D33B1C.8020603@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 Jonathan Rosenberg wrote: > I think its wrong. The reason is that the class is only two of the 12 > bits. So I think its: > > #define IS_REQUEST(msg_type) (((msg_type) & 0x0110) == 0x0000) > #define IS_INDICATION(msg_type) (((msg_type) & 0x0110) == 0x0010) > #define IS_SUCCESS_RESP(msg_type) (((msg_type) & 0x0110) == 0x0100) > #define IS_ERR_RESP(msg_type) (((msg_type) & 0x0110) == 0x0110) thanks for answering my questions, Jonathan, and you're right with the bit-fields. Using 0x0110 mask rather than 0x0FF0 gives us possibility to have more than 16 STUN methods. >> 0x0004 : Send Indication >> 0x0115 : Data Indication >> 0x0118 : Connect Status Indication > > Yes, the TURN values are wrong. I discussed this at the IETF meeting, > that the proposed bitfield approach worked well for existing STUN > attributes but would be wrong for the new indications that were recently > added to TURN. Those need to be changed in the revision of TURN. So until the new revision is released, I think we can assume that these are the values (?): 0x0014 : Send Indication 0x0015 : Data Indication 0x0018 : Connect Status Indication thanks -benny -- Benny Prijono http://www.pjsip.org _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Feb 15 21:33:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHstX-0002gM-1y; Thu, 15 Feb 2007 21:32:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHstV-0002gH-SO for behave@ietf.org; Thu, 15 Feb 2007 21:32:17 -0500 Received: from mx2-7.spamtrap.magma.ca ([209.217.78.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHstU-0002Vp-Aq for behave@ietf.org; Thu, 15 Feb 2007 21:32:17 -0500 Received: from mail1.magma.ca (mail1.internal.magma.ca [10.0.10.11]) by mx2-7.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l1G2VCNl005697; Thu, 15 Feb 2007 21:31:12 -0500 Received: from [64.26.165.15] (ottawa-dial-64-26-165-15.d-ip.magma.ca [64.26.165.15]) (authenticated bits=0) by mail1.magma.ca (Magma's Mail Server) with ESMTP id l1G2V1RI019200 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 15 Feb 2007 21:31:07 -0500 In-Reply-To: <953beacc0701192002w611d6f9dh9e11dde80a87fe09@mail.gmail.com> References: <953beacc0701192002w611d6f9dh9e11dde80a87fe09@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <15442609-9182-47CB-94E5-7974E22161D2@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN major issues and proposed fixes Date: Thu, 15 Feb 2007 17:39:56 -0500 To: Rohan Mahy 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: d9238570526f12788af3d33c67f37625 Cc: Rohan Mahy , 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 Why not have allocation behavior correspond to the way NATs typically work? That is traffic sent in the "outbound" direction refresh the permission for that destination, and also refresh the corresponding allocation. However, it does not refresh any other permissions. Other things sounds ok. For TCP, I prefer option A. - Philip On 19-Jan-07, at 23:02 , Rohan Mahy wrote: > Hi Folks, > > The following issues have all come up from implementors of TURN and > are big enough issues that I wanted to get some list feedback before > incorporating these in a new rev. > > 1. Allocations, Bindings, Permissions, Timeouts, and the Active > Destination. > > The current text is still a bit fuzzy and inconsistent about what is a > difference between permission and a binding and what keeps bindings > open. Also, many implementors have expressed confusion between the > behavior of an ordinary NAT binding and a "STUN Relay binding", so I > am proposing we skip the binding terminology in favor of "permission". > Much of the following came from consensus at one of the meetings. I've > come up with the following proposal which fills out a consistent set > of rules: > - Remove the terminology "binding" altogether inside the TURN server. > Only use "binding" when talking about a "real" NAT (ex: between the > TURN client and the TURN server) > - All requests and indications except for initial Allocation requests > are sent in the context of a matching valid allocation, otherwise they > are rejected (requests) or discarded silently (Indications). > - Allocations are explicitly refreshed via subsequent allocation > requests. Allocation timeout values are on the order of minutes. Send > and Data indications do not refresh Allocations. Allocation timers are > based on the LIFETIME attribute. > - Each allocation can have zero or more permissions > - When allocations are destroyed all related permissions are deleted. > - Permissions are only created by Send Indications over UDP and > Connect Requests over TCP. > - Data sent to a peer (via send Indications and unencapsulated data > sent to the active destination) by the TURN client refresh the > relevant permission. Data to one permission does not refresh other > permissions associated with the same binding. > - The expected timeout interval for all permissions for an allocation > is conveyed from the server to the client using the REFRESH-INTERVAL > attribute in an initial successful Allocate Response. > - The active destination is changed only with the Set Active > Destination Request for an allocation. The active destination is > completely independent of any permissions. > > 2. SetActiveDestination should not be limited to existing permissions > Current text in some places says that the active destination needs to > be an existing permission. This is actually unnecessary however, and > loosening this restriction is useful. > Take the case where the TURN client receives a SIP INVITE with an > offer, and the TURN client wishes to accept the offer. The TURN client > should be able to set the active destination immediately before > issuing its first Send request (to this destination). Using this order > of operations insures that the TURN client receives all data traffic > unencapsulated. This provides for more consistent bandwidth usage in > this case. > > The proposal is to change the current text to completely decouple the > active destination from any permissions. A permission controls > whether traffic flows. The active destination controls whether > traffic flowing over a binding is encapsulated of not. > > An alternative to this proposal is to create a new permission if no > permission for the active destination exists. The problem is that > this does not result in sending any data to the peer (as described in > the applicability statement and UNSAF considerations), it is > completely implicit behavior, and the opposite operation (clearing the > active destination) does not delete permissions. > > 3. SetActiveDestination changing destinations > > Currently there are several pages of text devoted to a timer based > state machine that needs to be implemented on both the server and the > client to handle the case of switching the active destination from one > address to another. The problem is that over UDP, the client cannot > tell which unencapsulated data is from the old active destination vs. > the new active destination. > > However, requiring timers and a state machine on the server is a > significant implementation burden which provides no benefit for the > TURN server or its administrative domain. > > The proposal is to put this problem completely into the hands of the > client. Some clients may never wish to change the active destination > for example and will have no need to implement anything special. > Those clients that want to change the active destination over UDP are > required to clear the active destination, wait for an appropriate > interval (5 seconds is suggested), then set the active destination to > the new address. > > Specific proposed text for items 2 and 3 and also delete the TIMER-VAL > attribute: > >
>
> > The Set Active Destination address allows the client to create an > optimized relay function between it and the server. When the server > receives packets from a particular preferred external client, the > server will forward those packets towards the client without > encapsulating them in a Data Indication. Similarly, the client can > send non-STUN packets to the server without encapsulation, and these > are forwarded to the external client. Sending and receiving data in > unencapsulated form is critical for efficiency purposes. One of the > primary use cases for the STUN relay usage is in support of Voice over > IP (VoIP), which uses very small UDP packets to begin with. The extra > overhead of an additional layer of encapsulation is considered > unacceptable. > > The Set Active Destination request is used by the client to provide > the identity of this preferred external client. The Set Active > Destination address MAY contain a REMOTE-ADDRESS attribute. This > attribute, when present, provides the address of the preferred > external client to the server. When absent, it clears the value of the > preferred external client. This address has no effect on the existence > of any permissions. > > The client MUST NOT send a Set Active Destination request with a > REMOTE-ADDRESS attribute over an unreliable link (ex: UDP) if an > active destination is already set for that allocation. If the client > wishes to set a new active destination, it MUST wait until 5 seconds > after a successful response is received to a Set Destination Request > removing the active destination. Failure to wait could cause the > client to receive and attribute late data forwarded by the STUN relay > server to the wrong peer. > > Consider the case where the active destination is set, and > the server is relaying packets towards the client. The client knows > the IP address and port where the packets came from - the current > value of the active destination. The client issues a Set Active > Destination Request to change the active destination, and receives a > response. A moment later, a data packet is received, not encapsulated > in a STUN Data Indication. What is the source if this packet? Is it > the active destination that existed prior to the Set Active > Destination request, or the one after? If the transport between the > client and the STUN server is not reliable, there is no way to > know. > >
> >
> > The Set Active Destination Request is used by a client to set the > forwarding destination of all data that is not encapsulated in STUN > Send Indications. In addition, when a matching permission is present, > all data received from that external client will be forwarded to the > STUN client without being encapsulated in a Data Indication. This > request does not modify any permissions. > > The request MUST be authenticated using the same shared secret as the > one associated with the allocation, or be authenticated using a short > term password derived from that shared secret. If the request was > authenticated but not with such a matching credential, the server MUST > generate an error response with a 441 response code. > > If the Set Active Destination request does not contain a > REMOTE-ADDRESS attribute, the value of the active destination is > cleared. If the Set Active Destination request contains a > REMOTE-ADDRESS attribute, and the active destination is not set, the > active destination is set to that IP address and port. If an active > destination is already set, and the request was received over a > reliable transport, the active destination is changed to the new > value. If the active destination is already set and the request was > received over UDP, the Set Active Destination request is rejected with > a 439 Active Destination Already Set error response. This prevents > the race condition described in the previous section. > >
>
> > 4. Opening TCP permissions > > Currently TCP to TCP traffic between TURN servers requires the TURN > servers to implement simultaneous open. > > SYN -> > <- SYN > SYN-ACK -> > <- ACK > > Option A is to leave this as is and to clarify this non-obvious > implication to implementors (you cannot receive an incoming connection > unless you first try to open one with the Connect request. Option B > is to include an explicit Open Permission Request to create a specific > permission for the TURN server to receive a TCP SYN from one specific > IP address and port number. > > I will implement Option A unless there is strong desire on the list to > do something else. > > thanks, > -rohan > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 16 17:40:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIBkI-0002A8-Bt; Fri, 16 Feb 2007 17:40:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIBkH-00029t-01 for behave@ietf.org; Fri, 16 Feb 2007 17:40:01 -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 1HIBkG-00040W-7I for behave@ietf.org; Fri, 16 Feb 2007 17:40:00 -0500 Received: from [172.17.1.57] ([172.17.1.57]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id l1GMd6wG001686 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 16 Feb 2007 16:39:06 -0600 (CST) (envelope-from brian@estacado.net) In-Reply-To: <953beacc0701192002w611d6f9dh9e11dde80a87fe09@mail.gmail.com> References: <953beacc0701192002w611d6f9dh9e11dde80a87fe09@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <45AB07C9-0690-4F85-B2E0-FB6CDDF8A570@estacado.net> Content-Transfer-Encoding: 7bit From: Brian Hibbard Subject: Re: [BEHAVE] TURN major issues and proposed fixes Date: Fri, 16 Feb 2007 16:38:59 -0600 To: Rohan Mahy X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Cc: Rohan Mahy , 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 Hello Rohan, My sincere apologies for not posting earlier. Comments are inline. On Jan 19, 2007, at 10:02 PM, Rohan Mahy wrote: > Hi Folks, > > The following issues have all come up from implementors of TURN and > are big enough issues that I wanted to get some list feedback before > incorporating these in a new rev. > > 1. Allocations, Bindings, Permissions, Timeouts, and the Active > Destination. > > The current text is still a bit fuzzy and inconsistent about what is a > difference between permission and a binding and what keeps bindings > open. Also, many implementors have expressed confusion between the > behavior of an ordinary NAT binding and a "STUN Relay binding", so I > am proposing we skip the binding terminology in favor of "permission". > Much of the following came from consensus at one of the meetings. I've > come up with the following proposal which fills out a consistent set > of rules: > - Remove the terminology "binding" altogether inside the TURN server. > Only use "binding" when talking about a "real" NAT (ex: between the > TURN client and the TURN server) That will be nice. > - All requests and indications except for initial Allocation requests > are sent in the context of a matching valid allocation, otherwise they > are rejected (requests) or discarded silently (Indications). > - Allocations are explicitly refreshed via subsequent allocation > requests. Allocation timeout values are on the order of minutes. Send > and Data indications do not refresh Allocations. Allocation timers are > based on the LIFETIME attribute. > - Each allocation can have zero or more permissions > - When allocations are destroyed all related permissions are deleted. > - Permissions are only created by Send Indications over UDP and > Connect Requests over TCP. > - Data sent to a peer (via send Indications and unencapsulated data > sent to the active destination) by the TURN client refresh the > relevant permission. Data to one permission does not refresh other > permissions associated with the same binding. > - The expected timeout interval for all permissions for an allocation > is conveyed from the server to the client using the REFRESH-INTERVAL > attribute in an initial successful Allocate Response. > - The active destination is changed only with the Set Active > Destination Request for an allocation. The active destination is > completely independent of any permissions. > I like the idea that a TURN client explicitly refreshes its allocation. Since it ought to be a lot more work to provide an allocation than a permission, I think it is right to give allocations a lifetime that is distinct from the permissions. Is the purpose of the permission timers to avert the proliferation of permissions for an allocation? Is it worthwhile for the TURN server to bother maintaining permission timers for some other reason? The client can always send packets to refresh NAT bindings without the TURN server having to maintain state. > 2. SetActiveDestination should not be limited to existing permissions > Current text in some places says that the active destination needs to > be an existing permission. This is actually unnecessary however, and > loosening this restriction is useful. > Take the case where the TURN client receives a SIP INVITE with an > offer, and the TURN client wishes to accept the offer. The TURN client > should be able to set the active destination immediately before > issuing its first Send request (to this destination). Using this order > of operations insures that the TURN client receives all data traffic > unencapsulated. This provides for more consistent bandwidth usage in > this case. > > The proposal is to change the current text to completely decouple the > active destination from any permissions. A permission controls > whether traffic flows. The active destination controls whether > traffic flowing over a binding is encapsulated of not. > > An alternative to this proposal is to create a new permission if no > permission for the active destination exists. The problem is that > this does not result in sending any data to the peer (as described in > the applicability statement and UNSAF considerations), it is > completely implicit behavior, and the opposite operation (clearing the > active destination) does not delete permissions. > If it's OK for Set Active Destination to create a new permission implicitly without sending data, it would make sense to have an Open Binding^h^h^h^h^h^h^h Permission message that allows a client to set permissions explicitly without sending data. I missed the argument as to why the explicit control of permissions was considered undesirable, but it doesn't sound like a major issue if you continue to omit such messages if they are a problem. Would you consider including a paragraph that explains "why not", for posterity? > 3. SetActiveDestination changing destinations > > Currently there are several pages of text devoted to a timer based > state machine that needs to be implemented on both the server and the > client to handle the case of switching the active destination from one > address to another. The problem is that over UDP, the client cannot > tell which unencapsulated data is from the old active destination vs. > the new active destination. > > However, requiring timers and a state machine on the server is a > significant implementation burden which provides no benefit for the > TURN server or its administrative domain. > > The proposal is to put this problem completely into the hands of the > client. Some clients may never wish to change the active destination > for example and will have no need to implement anything special. > Those clients that want to change the active destination over UDP are > required to clear the active destination, wait for an appropriate > interval (5 seconds is suggested), then set the active destination to > the new address. > > Specific proposed text for items 2 and 3 and also delete the TIMER-VAL > attribute: > >
>
> > The Set Active Destination address allows the client to create an > optimized relay function between it and the server. When the server > receives packets from a particular preferred external client, the > server will forward those packets towards the client without > encapsulating them in a Data Indication. Similarly, the client can > send non-STUN packets to the server without encapsulation, and these > are forwarded to the external client. Sending and receiving data in > unencapsulated form is critical for efficiency purposes. One of the > primary use cases for the STUN relay usage is in support of Voice over > IP (VoIP), which uses very small UDP packets to begin with. The extra > overhead of an additional layer of encapsulation is considered > unacceptable. > > The Set Active Destination request is used by the client to provide > the identity of this preferred external client. The Set Active > Destination address MAY contain a REMOTE-ADDRESS attribute. This > attribute, when present, provides the address of the preferred > external client to the server. When absent, it clears the value of the > preferred external client. This address has no effect on the existence > of any permissions. > > The client MUST NOT send a Set Active Destination request with a > REMOTE-ADDRESS attribute over an unreliable link (ex: UDP) if an > active destination is already set for that allocation. If the client > wishes to set a new active destination, it MUST wait until 5 seconds > after a successful response is received to a Set Destination Request > removing the active destination. Failure to wait could cause the > client to receive and attribute late data forwarded by the STUN relay > server to the wrong peer. > > Consider the case where the active destination is set, and > the server is relaying packets towards the client. The client knows > the IP address and port where the packets came from - the current > value of the active destination. The client issues a Set Active > Destination Request to change the active destination, and receives a > response. A moment later, a data packet is received, not encapsulated > in a STUN Data Indication. What is the source if this packet? Is it > the active destination that existed prior to the Set Active > Destination request, or the one after? If the transport between the > client and the STUN server is not reliable, there is no way to > know. > >
> >
> > The Set Active Destination Request is used by a client to set the > forwarding destination of all data that is not encapsulated in STUN > Send Indications. In addition, when a matching permission is present, > all data received from that external client will be forwarded to the > STUN client without being encapsulated in a Data Indication. This > request does not modify any permissions. > > The request MUST be authenticated using the same shared secret as the > one associated with the allocation, or be authenticated using a short > term password derived from that shared secret. If the request was > authenticated but not with such a matching credential, the server MUST > generate an error response with a 441 response code. > > If the Set Active Destination request does not contain a > REMOTE-ADDRESS attribute, the value of the active destination is > cleared. If the Set Active Destination request contains a > REMOTE-ADDRESS attribute, and the active destination is not set, the > active destination is set to that IP address and port. If an active > destination is already set, and the request was received over a > reliable transport, the active destination is changed to the new > value. If the active destination is already set and the request was > received over UDP, the Set Active Destination request is rejected with > a 439 Active Destination Already Set error response. This prevents > the race condition described in the previous section. > >
>
> This sounds great. That should be worlds better than having timer- driven state machines on both client and server. As an aside, would it be worthwhile to specify what a client should do if it receives encapsulated data what it believes is its current Active Destination? > 4. Opening TCP permissions > > Currently TCP to TCP traffic between TURN servers requires the TURN > servers to implement simultaneous open. > > SYN -> > <- SYN > SYN-ACK -> > <- ACK > > Option A is to leave this as is and to clarify this non-obvious > implication to implementors (you cannot receive an incoming connection > unless you first try to open one with the Connect request. Option B > is to include an explicit Open Permission Request to create a specific > permission for the TURN server to receive a TCP SYN from one specific > IP address and port number. > > I will implement Option A unless there is strong desire on the list to > do something else. > Simultaneous open is an unusual enough scenario that option A makes me want to test my TCP stacks on all our platforms to verify that they actually do that correctly. Option B seems simpler to understand, implement and test. Therefore, I am in favor of B, but certainly not with a passion. > thanks, > -rohan > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 19 06:03:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ6IW-00038T-EJ; Mon, 19 Feb 2007 06:03:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ6IV-00038O-Fy for behave@ietf.org; Mon, 19 Feb 2007 06:03:07 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJ6IT-00023C-Bu for behave@ietf.org; Mon, 19 Feb 2007 06:03:06 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1JAxEUf008446; Mon, 19 Feb 2007 12:59:20 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Feb 2007 13:02:55 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Feb 2007 13:02:55 +0200 Received: from esdhcp04165.research.nokia.com (esdhcp04165.research.nokia.com [172.21.41.65]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1JAxOwo021478; Mon, 19 Feb 2007 12:59:24 +0200 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia-TP-MSW Helsinki To: "ext Dan Wing" , behave@ietf.org Date: Mon, 19 Feb 2007 13:04:23 +0200 User-Agent: KMail/1.9.5 References: <0ee701c7507d$0464afb0$c2f0200a@amer.cisco.com> In-Reply-To: <0ee701c7507d$0464afb0$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200702191304.23341.Remi.Denis-Courmont@nokia.com> X-OriginalArrivalTime: 19 Feb 2007 11:02:55.0377 (UTC) FILETIME=[81E6A010:01C75415] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070219125920-202E0BB0-42ED6504/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.9 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Subject: [BEHAVE] TLS in draft-wing-behave-nat-control-stun-usage-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 Hello, I have been looking at the new -01 revision... Now it came to my mind that,= =20 hmm, using STUN+TLS was a bit problematic. =46irst, I would expect some NATs implementors to not want to bother puttin= g a=20 TLS stack. But I cannot really comment on that, not being a NAT implementor= =2E=20 Second, the I-D really ought to specify how the TLS session is to be=20 authenticated. x509 seems very impractical, because: =2D admins will not want to pay a certification per NAT box, =2D NATs are supposed to be easy to deploy, and provisioning an x509 cert i= s not=20 at all easy as in plug-and-play-easy; moreover, getting a cert takes time, =2D NATs usually do not have a good fixed CN to use, which means no cert. This means TLS_RSA_WITH_AES_128_CBC_SHA cannot realistically be relied upon= ,=20 and the client cannot rely on certificate check, even though this=20 unfortunately contradicts draft-ietf-behave-rfc3489bis-05 (=C2=A7 8.3.1). OpenPGP resp shared secret auth are even worst, since you would basically n= eed=20 to configure both the clients and the NAT with the keyring resp shared=20 secret. On top of that, they are not supported by all the common TLS stacks. So I am afraid we are left with either anonymous TLS "authentication" (if i= t=20 can be called authentication...) or not using TLS at all. At least in the=20 first case, protection against passive eavesdroppers is retained, if there = is=20 any point in having it. =2D-=20 R=C3=A9mi Denis-Courmont Research Engineer _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 19 13:33:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJDJT-0005Nx-9I; Mon, 19 Feb 2007 13:32:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJDJR-0005Nr-OY for behave@ietf.org; Mon, 19 Feb 2007 13:32:33 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJDJQ-0006DF-51 for behave@ietf.org; Mon, 19 Feb 2007 13:32:33 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 19 Feb 2007 10:32:31 -0800 X-IronPort-AV: i="4.14,191,1170662400"; d="scan'208"; a="114247639:sNHT50434542" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l1JIWVXS003912; Mon, 19 Feb 2007 10:32:31 -0800 Received: from dwingwxp ([10.32.240.194]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1JIWUDk003324; Mon, 19 Feb 2007 10:32:31 -0800 (PST) From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Denis-Courmont'?=" , Date: Mon, 19 Feb 2007 10:32:27 -0800 Message-ID: <00d801c75454$4ef69f40$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200702191304.23341.Remi.Denis-Courmont@nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdUFYqdVzCKgUQPR/mOROVfnKXwxQAO793w DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5511; t=1171909951; x=1172773951; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20TLS=20in=20draft-wing-behave-nat-control-stun-usage-0 1=20?! |Sender:=20; bh=9EbGsiYE3bo8jgvBa7utWZNEm2Y5G83py95cglblx8g=; b=XZ+buQHDMW/g/JxCDHvJnxcO0ir0c8M3A/QilcA5hqsg0TRgn3eu/CWx1EPstJfTjKNd/vaA orgk5X4CIRQTVpvErqOURcA7HXtX87IX7P4rZjMKgqpxAkFnUEJmfY68; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.9 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: Subject: [BEHAVE] RE: TLS in draft-wing-behave-nat-control-stun-usage-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 > Hello, >=20 > I have been looking at the new -01 revision... Now it came to=20 > my mind that, hmm, using STUN+TLS was a bit problematic. >=20 > First, I would expect some NATs implementors to not want to=20 > bother putting a TLS stack.=20 Agreed. The counter-argument is that many NATs already include=20 HTTPS for their own administration. > But I cannot really comment on that, not being a=20 > NAT implementor.=20 > Second, the I-D really ought to specify how the TLS session is to be=20 > authenticated. Establishing a TLS connection with your outer-most NAT only protects=20 against one specific attack described in section 8.3, http://tools.ietf.org/html/draft-wing-behave-nat-control-stun-usage-01#se= cti on-8.3: > > 8.3. Rogue STUN Server > > As described in Section 6, a STUN client can learn its > outer-most NAT runs an embedded STUN server. However, > without the STUN client's knowledge, the outer-most NAT > may acquire a new IP address. This could occur when > the NAT moves to a new mobile network or its DHCP lease > expires. When the NAT acquires a new IP address, the > STUN client will send a STUN Binding Request to the > NAT's prior public IP address, which will be routed to > the NAT's previous address. > > If an attacker runs a rogue STUN server on that > address, the attacker has effectively compromised the > STUN server (the attacked described in section 12.2.1 > of [RFC3489]). The attacker will send STUN Binding > Responses indicating his IP address, which will be > indistinguishable, to the STUN client, from the > behavior of the legitimate STUN server. > > To defend against this attack, the STUN client and STUN > server obtain a short-term password as described in > section Section 5.6. > To protect against this attack, it isn't necessary to authenticate the STUN server embedded in the outer-most NAT; the only time an attacker could take advantage of the lack of authentication is if the attacker acquired your outer-most NAT's IP address between the time you learned it and the time you made a TLS connection to it. Specifically, the=20 attacker would have to acquire that IP address between steps 6 and 7=20 of Figure 2 in section 4: > > STUN Client NAT STUN Server > | | | > 1. |-----TLS/TCP----------------------------->| } > 2. |-----Shared Secret Request (TLS)--------->| } > 3. |<----Shared Secret Response (TLS)---------| } normal STUN > 4. |-----TCP connection closed--------------->| } behavior > 5. |-----Binding Request (UDP)--------------->| } > 6. |<----Binding Response (UDP)---------------| } > | | | > 7. |-----TLS/TCP------------------>| | } > 8. |--Shared Secret Request (TLS)->| | } > 9. |<-Shared Secret Response (TLS)-| | } NAT Control > 10. |--TCP connection closed------->| | } STUN Usage > 11. |--Binding Request (UDP)------->| | } > 12. |<-Binding Response (UDP)-------| | } > | | | > > x509 seems very impractical, because: > - admins will not want to pay a certification per NAT box, > - NATs are supposed to be easy to deploy, and provisioning an=20 > x509 cert is not=20 > at all easy as in plug-and-play-easy; moreover, getting a=20 > cert takes time, > - NATs usually do not have a good fixed CN to use, which=20 > means no cert. >=20 > This means TLS_RSA_WITH_AES_128_CBC_SHA cannot realistically=20 > be relied upon, and the client cannot rely on certificate=20 > check, even though this unfortunately contradicts=20 > draft-ietf-behave-rfc3489bis-05 (=A7 8.3.1). >=20 > OpenPGP resp shared secret auth are even worst, since you=20 > would basically need to configure both the clients and the=20 > NAT with the keyring resp shared secret. On top of that,=20 > they are not supported by all the common TLS stacks. >=20 > So I am afraid we are left with either anonymous TLS=20 > "authentication" (if it can be called authentication...) or=20 > not using TLS at all. At least in the first case, protection=20 > against passive eavesdroppers is retained, if there is any=20 > point in having it. I am on the fence, myself, if the attack described in section 8.3 is sufficiently 'real' to bother with TLS. If you're going to use encrypted an transport for your data (SRTP, for example), the attacker will only be able to collect IP addresses or interfere with the session (delay/drop packets); the attacker cannot listen to the session. There are other ways to accomplish similar protection, without using TLS. One technique is to have the NAT's embedded STUN server return a NONCE in each response. That NONCE would be a random value that persists until the NAT's embedded STUN server re-initializes (such as when it reboots). The STUN client could simply verify that all subsequent communications with the NAT's embedded STUN server has the same NONCE. This would provide identical protection against the attack described in section 8.3 as TLS. I can write that up if you think it would be useful. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 19 18:50:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJIGC-0000zY-1u; Mon, 19 Feb 2007 18:49:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJIGB-0000zT-5a for behave@ietf.org; Mon, 19 Feb 2007 18:49:31 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJIG8-0004bd-UZ for behave@ietf.org; Mon, 19 Feb 2007 18:49:31 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by rtp-iport-1.cisco.com with ESMTP; 19 Feb 2007 18:49:28 -0500 X-IronPort-AV: i="4.14,192,1170651600"; d="scan'208"; a="53364339:sNHT44410268" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1JNnRTs008724; Mon, 19 Feb 2007 15:49:27 -0800 Received: from dwingwxp ([10.32.240.194]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l1JNnMUw008115; Mon, 19 Feb 2007 15:49:22 -0800 (PST) From: "Dan Wing" To: "'Brian Hibbard'" , "'Rohan Mahy'" Subject: RE: [BEHAVE] TURN major issues and proposed fixes Date: Mon, 19 Feb 2007 15:49:22 -0800 Message-ID: <019501c75480$97719960$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <45AB07C9-0690-4F85-B2E0-FB6CDDF8A570@estacado.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdSG7npp60tIPOrRIGFAd/94b7nBwCYreBg DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1252; t=1171928967; x=1172792967; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20TURN=20major=20issues=20and=20proposed=20f ixes |Sender:=20; bh=iWTiQN6Vpha2QpBOIBUYDzMeP93cmB7jwo3yiz4nepc=; b=LiLyeL8ybYNt1z4GNollbql8UBkHn5mbNNFQApql5fgWxZBRk2NrDPxjEOvnefy9DOXcL8MG omuLhHAvQuZxTOU4rqEIkAMWNWTR46kyM7pFu9dSg/1aA/htcwKfWoBi; 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: 52e1467c2184c31006318542db5614d5 Cc: 'Rohan Mahy' , 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 > > 4. Opening TCP permissions > > > > Currently TCP to TCP traffic between TURN servers requires the TURN > > servers to implement simultaneous open. > > > > SYN -> > > <- SYN > > SYN-ACK -> > > <- ACK > > > > Option A is to leave this as is and to clarify this non-obvious > > implication to implementors (you cannot receive an incoming > > connection > > unless you first try to open one with the Connect request. Option B > > is to include an explicit Open Permission Request to create > > a specific > > permission for the TURN server to receive a TCP SYN from > > one specific IP address and port number. > > > > I will implement Option A unless there is strong desire on > > the list to do something else. > > Simultaneous open is an unusual enough scenario that option A makes > me want to test my TCP stacks on all our platforms to verify that > they actually do that correctly. TCP simultaneous-open was first documented in RFC793's figure 8, and was also in RFC793's apparent precursor, RFC761. > Option B seems simpler to > understand, implement and test. Therefore, I am in favor of B, but > certainly not with a passion. B seems to align with how the UDP permissions work, too. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Feb 20 15:50:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJbwR-00051t-99; Tue, 20 Feb 2007 15:50:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJbw3-0004oy-U3; Tue, 20 Feb 2007 15:50:03 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJbw3-00008u-DN; Tue, 20 Feb 2007 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 42ED4329C3; Tue, 20 Feb 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HJbw3-0007QL-4J; Tue, 20 Feb 2007 15:50:03 -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, 20 Feb 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: behave@ietf.org Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-p2p-state-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs) Author(s) : P. Srisuresh, et al. Filename : draft-ietf-behave-p2p-state-02.txt Pages : 34 Date : 2007-2-20 This memo documents the various methods known to be in use by peer-to-peer (P2P) applications for communication in the presence of Network Address Translators (NATs) at the current time. This memo covers NAT traversal approaches used by both TCP and UDP based applications. This memo is not an endorsement of the methods described, but merely an attempt to capture them in a document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-p2p-state-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-p2p-state-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-behave-p2p-state-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-20121237.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-p2p-state-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-p2p-state-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-20121237.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 Feb 20 15:51:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJbxI-0006iz-AP; Tue, 20 Feb 2007 15:51:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJbx1-0006Ez-So; Tue, 20 Feb 2007 15:51:03 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HJbx1-000375-DS; Tue, 20 Feb 2007 15:51:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 677EC17654; Tue, 20 Feb 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HJbw3-0007QO-5B; Tue, 20 Feb 2007 15:50:03 -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, 20 Feb 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: behave@ietf.org Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-nat-icmp-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : NAT Behavioral Requirements for ICMP protocol Author(s) : P. Srisuresh, et al. Filename : draft-ietf-behave-nat-icmp-02.txt Pages : 23 Date : 2007-2-20 This document specifies the behavioral properties required of the Network Address Translator (NAT) devices in conjunction with the ICMP protocol. The objective of this memo is to make NAT devices more predictable and compatible with diverse application protocols that traverse the devices. Companion documents provide behavioral recommendations specific to TCP, UDP and other protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-icmp-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-nat-icmp-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-behave-nat-icmp-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-20121438.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-nat-icmp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-nat-icmp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-20121438.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 Feb 20 16:57:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJczA-0005lD-VY; Tue, 20 Feb 2007 16:57:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJcz9-0005eY-Q9 for behave@ietf.org; Tue, 20 Feb 2007 16:57:19 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJcz6-0001fX-Jo for behave@ietf.org; Tue, 20 Feb 2007 16:57:19 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 20 Feb 2007 13:57:12 -0800 X-IronPort-AV: i="4.14,197,1170662400"; d="scan'208"; a="391365274:sNHT46012252" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1KLv9fO024781; Tue, 20 Feb 2007 13:57:09 -0800 Received: from dwingwxp ([10.32.240.194]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l1KLv0Uw027941; Tue, 20 Feb 2007 13:57:00 -0800 (PST) From: "Dan Wing" To: Date: Tue, 20 Feb 2007 13:57:00 -0800 Message-ID: <053301c7553a$11912ee0$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdVOgwKEkq84pVDQuSi3ILO1fEZ0g== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=690; t=1172008629; x=1172872629; 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:=20WGLC=20for=20behave-p2pstate-02=20starts=20now |Sender:=20; bh=+7PgZ8SMZYzpwmuZTfLMJxthErfDz3VKFuJIvsxVwi0=; b=ASEyktWzcrbddC9mfEzKuUSvKpGM5fiW+KavsWsgdLskGlT1b5scTx47vpaPZHDjZFnHDf5h NxR4lt4joFEdTu9ga7XswYn2KDYDipVGEwuRK7sZwx5mpO8pEXA2CUt+; 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: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: 'Dan Kegel' Subject: [BEHAVE] WGLC for behave-p2pstate-02 starts now X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org The working group last call for behave-p2p-state-02 starts now. URL for this document is http://www.ietf.org/internet-drafts/draft-ietf-behave-p2p-state-02.txt Abstract: This memo documents the various methods known to be in use by peer-to-peer (P2P) applications for communication in the presence of Network Address Translators (NATs) at the current time. This memo covers NAT traversal approaches used by both TCP and UDP based applications. This memo is not an endorsement of the methods described, but merely an attempt to capture them in a document. WGLC ends in two weeks on Tuesday, March 6. Please send comments to behave@ietf.org. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Feb 20 17:12:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJdDw-0002rF-D4; Tue, 20 Feb 2007 17:12:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJdDv-0002np-GK for behave@ietf.org; Tue, 20 Feb 2007 17:12:35 -0500 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HJdDs-0004yz-3H for behave@ietf.org; Tue, 20 Feb 2007 17:12:35 -0500 Received: from Quinthar ([67.169.180.240]) by quinthar.com for ; Tue, 20 Feb 2007 14:12:26 -0800 From: "David Barrett" To: "'Dan Wing'" , Subject: RE: [BEHAVE] WGLC for behave-p2pstate-02 starts now Date: Tue, 20 Feb 2007 14:12:23 -0800 Message-ID: <012001c7553c$32b35240$0402a8c0@Quinthar> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcdVOgwKEkq84pVDQuSi3ILO1fEZ0gAAfkIA In-Reply-To: <053301c7553a$11912ee0$c2f0200a@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: 'Dan Kegel' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Great doc! I like how you include the latest statistics and success rates throughout. I think it's ready for the presses. -david > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Tuesday, February 20, 2007 1:57 PM > To: behave@ietf.org > Cc: 'Dan Kegel' > Subject: [BEHAVE] WGLC for behave-p2pstate-02 starts now > > The working group last call for behave-p2p-state-02 starts now. URL for > this document is > http://www.ietf.org/internet-drafts/draft-ietf-behave-p2p-state-02.txt > > Abstract: > This memo documents the various methods known to be in use by > peer-to-peer (P2P) applications for communication in the presence > of Network Address Translators (NATs) at the current time. This > memo covers NAT traversal approaches used by both TCP and UDP > based applications. This memo is not an endorsement of the methods > described, but merely an attempt to capture them in a document. > > > WGLC ends in two weeks on Tuesday, March 6. > > Please send comments to behave@ietf.org. > > -d > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Feb 20 19:29:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJfM5-0000eg-7L; Tue, 20 Feb 2007 19:29:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJfM4-0000eb-AO for behave@ietf.org; Tue, 20 Feb 2007 19:29:08 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJfM2-0001aX-0X for behave@ietf.org; Tue, 20 Feb 2007 19:29:08 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l1L0SwN03366; Tue, 20 Feb 2007 19:28:58 -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 behave-p2pstate-02 starts now Date: Tue, 20 Feb 2007 18:28:42 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0F480E98@zrc2hxm0.corp.nortel.com> In-Reply-To: <053301c7553a$11912ee0$c2f0200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] WGLC for behave-p2pstate-02 starts now Thread-Index: AcdVOgwKEkq84pVDQuSi3ILO1fEZ0gAEo1bA From: "Francois Audet" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Dan Wing , Dan Kegel X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Document is in very good shape. Very readable.=20 I have the following comments: - Section 2.4 introduces the term "Endpoint-Dependent Mapping" to cover two terms defined in RFC 4787 "Address-Dependent Mapping" and "Address and Port-Dependent Mapping". I'm not convinced that we gain anything by defining this new term. Personally, I'd rather we not introduce this new term. If we do decide to keep it (because it makes the text later in=20 the document less cumbersome for example), then we need to address the problem of consistency with section 2.6 (see below). - Section 2.6 introduces the term "Endpoint-Dependent Filtering". However, unlike 2.4 which has Endpoint-Dependent =3D Address-Dependent | = Address and Port-Dependent, in this section it means Endpoint-Dependent =3D = Address and=20 Port-Dependent (only). Address-Dependent Filtering is not even mentioned. This makes 2.4 and 2.6 inconsistent, and is related to a long discussion we had on this previously (and for which the conclusion was, "yes, there are NATs with Address-Dependent Filtering behavior out there"). My preference would be NOT to introduce the term "Endpoint-Dependent Filtering" and stick to the RFC 4787-defined ones only (as mentioned above). Alternatively, if we can not avoid defining a new term because we think it improves the=20 readability of the document, it should also cover both "Address and Port-Dependent Filtering" and "Address-Dependent Filtering". - Section 2.10: Instead of using the term "hairping", we should use the=20 term "hairpinning" for consistency with RFC 4787. > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: Tuesday, February 20, 2007 13:57 > To: behave@ietf.org > Cc: 'Dan Kegel' > Subject: [BEHAVE] WGLC for behave-p2pstate-02 starts now >=20 > The working group last call for behave-p2p-state-02 starts=20 > now. URL for this document is=20 > http://www.ietf.org/internet-drafts/draft-ietf-behave-p2p-state-02.txt >=20 > Abstract: > This memo documents the various methods known to be in use by > peer-to-peer (P2P) applications for communication in the presence > of Network Address Translators (NATs) at the current time. This > memo covers NAT traversal approaches used by both TCP and UDP > based applications. This memo is not an endorsement of the methods=20 > described, but merely an attempt to capture them in a document. =20 >=20 >=20 > WGLC ends in two weeks on Tuesday, March 6. >=20 > Please send comments to behave@ietf.org. >=20 > -d >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave >=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 21 05:13:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJoTM-0007AB-24; Wed, 21 Feb 2007 05:13:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJoTK-00079p-4o for behave@ietf.org; Wed, 21 Feb 2007 05:13:14 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJoTI-0007Cm-MP for behave@ietf.org; Wed, 21 Feb 2007 05:13:14 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1LA9h6J017695; Wed, 21 Feb 2007 12:09:46 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Feb 2007 12:12:36 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Feb 2007 12:12:36 +0200 Received: from [10.140.224.6] (essapo-nirac252168.europe.nokia.com [10.162.252.168]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1LA84El009630; Wed, 21 Feb 2007 12:08:57 +0200 In-Reply-To: <000801c73674$d9b1e890$c4f0200a@amer.cisco.com> References: <000801c73674$d9b1e890$c4f0200a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Subject: Re: [BEHAVE] NAT Control STUN Usage Date: Wed, 21 Feb 2007 10:05:11 +0200 To: ext Dan Wing X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 21 Feb 2007 10:12:36.0089 (UTC) FILETIME=[CF175690:01C755A0] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070221120946-44B5DBB0-2C22ADF2/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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="===============0421993909==" Errors-To: behave-bounces@ietf.org --===============0421993909== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-42-464383849; protocol="application/pkcs7-signature" --Apple-Mail-42-464383849 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On 2007-1-12, at 20:09, ext Dan Wing wrote: > At the San Diego meeting there were positive comments around this > approach. > Is there interest in moving this work forward? this document takes STUN in a whole new direction (middlebox control) that would probably require a recharter. Also, the draft says: > Unlike some other > techniques (e.g., UPnP [UPnP], MIDCOM [RFC3303], Bonjour > [Bonjour]), > STUN does not interact directly with the NAT. Because STUN doesn't > interact directly with the NAT, STUN cannot request additional > services from the NAT such as longer lifetimes (which would reduce > keepalive messages). > > This paper describes a mechanism for the STUN client to interact > directly with the NAT and request additional services, by using the > STUN protocol itself. For a convincing rechartering argument, it'd be very useful to see a discussion on why adding this to STUN is significantly better than the myriad of exiting approaches to control middleboxes. In addition to the ones mentioned in the draft, at least NSIS and SIMCO also exist. Lars --Apple-Mail-42-464383849 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAyMjEwODA1MTJaMCMGCSqGSIb3DQEJBDEWBBRLXqJdKtbA34jd QwuWw6HdsboyUTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAjdRlPpPIJl1Kk4+1vbuLt+2ioqoN78f+54wTY/GslT+d3ym/2dYE J9LP5KBNu4Td1l5JUE4Jc9b+xGJNMQMvuM4gH8pChhQ8MnNxOtqJcgw7549RFZgdyKhKX67qHcsQ fGscDeh78bQdLjs58GfO2tQsssmF+UqG/sGHsYo62Wshj6Koi3t6mmKs2aqI17wo424VOY02G048 xozVoPF5rFUnzR1hlERQ8kgwqkQH40C7KrHI1BZYGtR3SVndXQjoqL8LwL7EI1s0Y0U/gmWvxcD1 rPgiu+jXr5R/kNfh7k8OH4N6NKoy4ipZeCvTQjqCAwyRh4RfvwkzBPa47ql1vQAAAAAAAA== --Apple-Mail-42-464383849-- --===============0421993909== 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 --===============0421993909==-- From behave-bounces@ietf.org Wed Feb 21 07:47:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJqsO-0000dB-EJ; Wed, 21 Feb 2007 07:47:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJqsM-0000d5-V4 for behave@ietf.org; Wed, 21 Feb 2007 07:47:14 -0500 Received: from web33304.mail.mud.yahoo.com ([68.142.206.119]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HJqsJ-0006fx-IF for behave@ietf.org; Wed, 21 Feb 2007 07:47:14 -0500 Received: (qmail 23214 invoked by uid 60001); 21 Feb 2007 12:47:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Xj0ORNVKJpznceX27cH0ZsqTI2nPsUFCwYlYcvij5Obgda40FyxAUfk5OEUK7SiPZ58Jh5mG1yNnE86gcFDz99Yuvo/z48c6rTg1TQcRdEgTUDHExO3tcHdzKzWI7S9SAgZQ+fvmPJLT5aPLVnpNzcaP0cejcGxwxejtWvFN3fw=; X-YMail-OSG: TQdGgAgVM1mkveNSxVThLlyI.TQIBGFATWIwGT0TuqalHxD.1hQDsvWjVgi1YX1uogNCothUjJxlTQnFqli2LTgZWXoqD2_Ftm8.TN0ecN.RI.f5DaXA1BXzx.u_E0TkzoeZzgQlmjU- Received: from [69.236.102.196] by web33304.mail.mud.yahoo.com via HTTP; Wed, 21 Feb 2007 04:47:10 PST Date: Wed, 21 Feb 2007 04:47:10 -0800 (PST) From: Pyda Srisuresh Subject: RE: [BEHAVE] WGLC for behave-p2pstate-02 starts now To: David Barrett , 'Dan Wing' , behave@ietf.org In-Reply-To: <012001c7553c$32b35240$0402a8c0@Quinthar> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <967919.21261.qm@web33304.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: 'Dan Kegel' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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, David. Glad you like it. regards, suresh --- David Barrett wrote: > Great doc! I like how you include the latest statistics and success rates > throughout. I think it's ready for the presses. > > -david > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: Tuesday, February 20, 2007 1:57 PM > > To: behave@ietf.org > > Cc: 'Dan Kegel' > > Subject: [BEHAVE] WGLC for behave-p2pstate-02 starts now > > > > The working group last call for behave-p2p-state-02 starts now. URL for > > this document is > > http://www.ietf.org/internet-drafts/draft-ietf-behave-p2p-state-02.txt > > > > Abstract: > > This memo documents the various methods known to be in use by > > peer-to-peer (P2P) applications for communication in the presence > > of Network Address Translators (NATs) at the current time. This > > memo covers NAT traversal approaches used by both TCP and UDP > > based applications. This memo is not an endorsement of the methods > > described, but merely an attempt to capture them in a document. > > > > > > WGLC ends in two weeks on Tuesday, March 6. > > > > Please send comments to behave@ietf.org. > > > > -d > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www1.ietf.org/mailman/listinfo/behave > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 21 07:50:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJqvF-0001Ws-RW; Wed, 21 Feb 2007 07:50:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJqvE-0001U8-4f for behave@ietf.org; Wed, 21 Feb 2007 07:50:12 -0500 Received: from web33306.mail.mud.yahoo.com ([68.142.206.121]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HJqvB-0007G1-Nl for behave@ietf.org; Wed, 21 Feb 2007 07:50:12 -0500 Received: (qmail 37792 invoked by uid 60001); 21 Feb 2007 12:50:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=ZjLcnIZMIQh0vxU356imyrz2mhVDyKDIraFuUXGbgl6kuOP+83pl5ZdCyHa6xPZvOR3NX1FSrbxh/QEo1BxBfO/m3NHVhOHfyko3MOox/r5lWF1vVetnTi/qIYuUIfTySVPtC9nvG1gyzL+vhSxjA/nt1vo7nu8R4bBV8xYcPD0=; X-YMail-OSG: wuI_M9cVM1n3t1OSUuydWil1F2VvMTpS432UwWiy.zHEs6rdmTTx3MH3IOVJwOJKjwQYbdQ2xFg4bBfUdBM6FywuHsh_tMcxOwDIrrFlqP.Lm3Clp_Mq_6EEQ1cM6Kf3Z0T8dC4GWSk- Received: from [69.236.102.196] by web33306.mail.mud.yahoo.com via HTTP; Wed, 21 Feb 2007 04:50:09 PST Date: Wed, 21 Feb 2007 04:50:09 -0800 (PST) From: Pyda Srisuresh Subject: RE: [BEHAVE] WGLC for behave-p2pstate-02 starts now To: Francois Audet , behave@ietf.org In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0F480E98@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <101203.37321.qm@web33306.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: Dan Wing , Dan Kegel X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Francois, Please see my responses below inline. regards, suresh --- Francois Audet wrote: > Document is in very good shape. Very readable. > [suresh] Thanks. > I have the following comments: > > - Section 2.4 introduces the term "Endpoint-Dependent Mapping" to cover > two terms defined in RFC 4787 "Address-Dependent Mapping" and "Address > and Port-Dependent Mapping". I'm not convinced that we gain anything > by defining this new term. Personally, I'd rather we not introduce > this > new term. If we do decide to keep it (because it makes the text later > in > the document less cumbersome for example), then we need to address the > problem of consistency with section 2.6 (see below). > > - Section 2.6 introduces the term "Endpoint-Dependent Filtering". > However, > unlike 2.4 which has Endpoint-Dependent = Address-Dependent | Address > and > Port-Dependent, in this section it means Endpoint-Dependent = Address > and > Port-Dependent (only). Address-Dependent Filtering is not even > mentioned. This > makes 2.4 and 2.6 inconsistent, and is related to a long discussion > we had on this previously (and for which the conclusion was, "yes, > there > are NATs with Address-Dependent Filtering behavior out there"). My > preference > would be NOT to introduce the term "Endpoint-Dependent Filtering" and > stick > to the RFC 4787-defined ones only (as mentioned above). Alternatively, > if > we can not avoid defining a new term because we think it improves the > readability of the document, it should also cover both "Address and > Port-Dependent Filtering" and "Address-Dependent Filtering". > [suresh] As you said, the terms "Endpoint-Dependent Mapping" and "Endpoint-Dependent Filtering" were introduced to make the document easy to read. Unlike RFC4787, this document does not require fine granular definitions. As for section 2.6 missing reference to "Address Dependent Filtering", I will add that. Not a problem. Thanks for pointing out. > - Section 2.10: Instead of using the term "hairping", we should use the > term "hairpinning" for consistency with RFC 4787. > [suresh] Sure, I will fix that. regards, suresh > > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: Tuesday, February 20, 2007 13:57 > > To: behave@ietf.org > > Cc: 'Dan Kegel' > > Subject: [BEHAVE] WGLC for behave-p2pstate-02 starts now > > > > The working group last call for behave-p2p-state-02 starts > > now. URL for this document is > > http://www.ietf.org/internet-drafts/draft-ietf-behave-p2p-state-02.txt > > > > Abstract: > > This memo documents the various methods known to be in use by > > peer-to-peer (P2P) applications for communication in the presence > > of Network Address Translators (NATs) at the current time. This > > memo covers NAT traversal approaches used by both TCP and UDP > > based applications. This memo is not an endorsement of the methods > > described, but merely an attempt to capture them in a document. > > > > > > WGLC ends in two weeks on Tuesday, March 6. > > > > Please send comments to behave@ietf.org. > > > > -d > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www1.ietf.org/mailman/listinfo/behave > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 21 11:29:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJuL1-0008Ds-Sc; Wed, 21 Feb 2007 11:29:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJtup-0004vf-6F for behave@ietf.org; Wed, 21 Feb 2007 11:01:59 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJtul-00087i-SP for behave@ietf.org; Wed, 21 Feb 2007 11:01:59 -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 l1LFq5Z07716; Wed, 21 Feb 2007 10:52:06 -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 behave-p2pstate-02 starts now Date: Wed, 21 Feb 2007 09:51:20 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0F4812D7@zrc2hxm0.corp.nortel.com> In-Reply-To: <101203.37321.qm@web33306.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] WGLC for behave-p2pstate-02 starts now Thread-Index: AcdVttSyn9qA5RhTRuiGbKc6cM1IOwAGUbeg From: "Francois Audet" To: "Pyda Srisuresh" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: Dan Wing , Dan Kegel X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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. That will address my comments.=20 > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh@yahoo.com]=20 > Sent: Wednesday, February 21, 2007 04:50 > To: Audet, Francois (SC100:3055); behave@ietf.org > Cc: Dan Wing; Dan Kegel > Subject: RE: [BEHAVE] WGLC for behave-p2pstate-02 starts now >=20 > Francois, >=20 > Please see my responses below inline. >=20 > regards, > suresh >=20 > --- Francois Audet wrote: >=20 > > Document is in very good shape. Very readable.=20 > >=20 >=20 > [suresh] Thanks. >=20 > > I have the following comments: > >=20 > > - Section 2.4 introduces the term "Endpoint-Dependent=20 > Mapping" to cover > > two terms defined in RFC 4787 "Address-Dependent Mapping"=20 > and "Address > > and Port-Dependent Mapping". I'm not convinced that we=20 > gain anything > > by defining this new term. Personally, I'd rather we not=20 > introduce=20 > > this > > new term. If we do decide to keep it (because it makes the text=20 > > later in > > the document less cumbersome for example), then we need=20 > to address the > > problem of consistency with section 2.6 (see below). > >=20 > > - Section 2.6 introduces the term "Endpoint-Dependent Filtering". > > However, > > unlike 2.4 which has Endpoint-Dependent =3D Address-Dependent |=20 > > Address and > > Port-Dependent, in this section it means Endpoint-Dependent =3D=20 > > Address and > > Port-Dependent (only). Address-Dependent Filtering is not even=20 > > mentioned. This > > makes 2.4 and 2.6 inconsistent, and is related to a long=20 > discussion > > we had on this previously (and for which the conclusion=20 > was, "yes,=20 > > there > > are NATs with Address-Dependent Filtering behavior out=20 > there"). My=20 > > preference > > would be NOT to introduce the term "Endpoint-Dependent Filtering"=20 > > and stick > > to the RFC 4787-defined ones only (as mentioned above).=20 > > Alternatively, if > > we can not avoid defining a new term because we think it=20 > improves the=20 > > readability of the document, it should also cover both=20 > "Address and > > Port-Dependent Filtering" and "Address-Dependent Filtering". > >=20 >=20 > [suresh] As you said, the terms "Endpoint-Dependent Mapping"=20 > and "Endpoint-Dependent Filtering" were introduced to make=20 > the document easy to read. Unlike RFC4787, this document does=20 > not require fine granular definitions. > As for section 2.6 missing reference to "Address Dependent=20 > Filtering", I will add that. Not a problem. Thanks for pointing out. >=20 > > - Section 2.10: Instead of using the term "hairping", we=20 > should use the=20 > > term "hairpinning" for consistency with RFC 4787. > >=20 >=20 > [suresh] Sure, I will fix that. >=20 > regards, > suresh >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Dan Wing [mailto:dwing@cisco.com] > > > Sent: Tuesday, February 20, 2007 13:57 > > > To: behave@ietf.org > > > Cc: 'Dan Kegel' > > > Subject: [BEHAVE] WGLC for behave-p2pstate-02 starts now > > >=20 > > > The working group last call for behave-p2p-state-02=20 > starts now. URL=20 > > > for this document is=20 > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-behave-p2p-state-02.t > > > xt > > >=20 > > > Abstract: > > > This memo documents the various methods known to be in use by > > > peer-to-peer (P2P) applications for communication in=20 > the presence > > > of Network Address Translators (NATs) at the current time. This > > > memo covers NAT traversal approaches used by both TCP and UDP > > > based applications. This memo is not an endorsement of=20 > the methods=20 > > > described, but merely an attempt to capture them in a=20 > document. =20 > > >=20 > > >=20 > > > WGLC ends in two weeks on Tuesday, March 6. > > >=20 > > > Please send comments to behave@ietf.org. > > >=20 > > > -d > > >=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 >=20 >=20 >=20 >=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 21 12:08:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJuwm-0008Ep-Qa; Wed, 21 Feb 2007 12:08:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJuwl-0008EM-En for behave@ietf.org; Wed, 21 Feb 2007 12:08:03 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJuwf-0000MH-0U for behave@ietf.org; Wed, 21 Feb 2007 12:08:03 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 77DB821003; Wed, 21 Feb 2007 18:07:54 +0100 (CET) X-AuditID: c1b4fb3e-ae6d0bb0000007e1-6b-45dc7c6a99aa Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5EEF520157; Wed, 21 Feb 2007 18:07:54 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Feb 2007 18:07:54 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Feb 2007 18:07:53 +0100 Message-ID: <45DC7C69.2020908@ericsson.com> Date: Wed, 21 Feb 2007 18:07:53 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: behave@ietf.org, saikat@cs.cornell.edu, "Kaushik Biswas (kbiswas)" , Bryan Ford , Senthil Sivakumar , Pyda Srisuresh Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Feb 2007 17:07:53.0906 (UTC) FILETIME=[D3447920:01C755DA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: [BEHAVE] AD-review of draft-ietf-behave-tcp-udp-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 Hi I did my AD-review of the TCP draft. It looks good but I have one question and on thing that needs to be fixed. 1. In the last sentence of section 2: " This document defines requirements that ensure that TCP NAT traversal approaches are not forced to use data relays, while preserving the functionality and privacy provided by NATs." What type of privacy is the above sentence referring to? There are two normative references to informative documents, RFC2663 and RFC 3022. This is not possible in a standards track and BCP document. Looking on how they are used in this document they can be reclassified to informative references. I am expecting an updated draft. 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 Wed Feb 21 15:03:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJxgW-0000TM-AO; Wed, 21 Feb 2007 15:03:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJxgV-0000TH-6E for behave@ietf.org; Wed, 21 Feb 2007 15:03:27 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJxgS-0000ce-Sm for behave@ietf.org; Wed, 21 Feb 2007 15:03:27 -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 l1LK3GZ08333; Wed, 21 Feb 2007 15:03:17 -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] AD-review of draft-ietf-behave-tcp-udp-04 Date: Wed, 21 Feb 2007 14:03:05 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0F4818AC@zrc2hxm0.corp.nortel.com> In-Reply-To: <45DC7C69.2020908@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] AD-review of draft-ietf-behave-tcp-udp-04 Thread-Index: AcdV2xaX8NnUlieySVW+YQY6AtVcTQAGArdw From: "Francois Audet" To: "Magnus Westerlund" , , , "Kaushik Biswas \(kbiswas\)" , "Bryan Ford" , "Senthil Sivakumar" , "Pyda Srisuresh" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 seems to me that the whole ", while preserving the functionality and privacy functionality and privacy provided by NATs" phrase could be deleted. > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: Wednesday, February 21, 2007 09:08 > To: behave@ietf.org; saikat@cs.cornell.edu; Kaushik Biswas=20 > (kbiswas); Bryan Ford; Senthil Sivakumar; Pyda Srisuresh > Subject: [BEHAVE] AD-review of draft-ietf-behave-tcp-udp-04 >=20 > Hi >=20 > I did my AD-review of the TCP draft. It looks good but I have=20 > one question and on thing that needs to be fixed. >=20 > 1. In the last sentence of section 2: > " This > document defines requirements that ensure that TCP NAT traversal > approaches are not forced to use data relays, while preserving the > functionality and privacy provided by NATs." >=20 > What type of privacy is the above sentence referring to? >=20 >=20 > There are two normative references to informative documents,=20 > RFC2663 and RFC 3022. This is not possible in a standards=20 > track and BCP document.=20 > Looking on how they are used in this document they can be=20 > reclassified to informative references. >=20 > I am expecting an updated draft. >=20 > Cheers >=20 > Magnus Westerlund >=20 > 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 > ---------------------------------------------------------------------- >=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 Feb 21 17:01:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJzWE-00063f-BP; Wed, 21 Feb 2007 17:00:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJzWD-00062P-2T for behave@ietf.org; Wed, 21 Feb 2007 17:00:57 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJzWB-0002iI-PC for behave@ietf.org; Wed, 21 Feb 2007 17:00:57 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 21 Feb 2007 14:00:55 -0800 X-IronPort-AV: i="4.14,203,1170662400"; d="scan'208"; a="466146789:sNHT131802076" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1LM0t1R012244; Wed, 21 Feb 2007 14:00:55 -0800 Received: from dwingwxp ([10.32.240.194]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1LM0rGk008205; Wed, 21 Feb 2007 14:00:53 -0800 (PST) From: "Dan Wing" To: "'Lars Eggert'" Subject: RE: [BEHAVE] NAT Control STUN Usage Date: Wed, 21 Feb 2007 14:00:53 -0800 Message-ID: <08f201c75603$c1cebab0$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdVoObhyCHh1ZbsT5K2sM8B7+YaZQAVEArw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1691; t=1172095255; x=1172959255; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20NAT=20Control=20STUN=20Usage |Sender:=20; bh=RlABcIMQ8G4Q/11aWkoCSJ5MERFJ4srN9F4XHu6XrOA=; b=IOHpxywEgtQhhrjuEfeyDEzMGNYJkV44bHH0UdMM66HFhG+r/H5lnmP7vujluCRZwzarOAv8 qHMxlcyRLORfJtdm/ZnV4fLuejwEpBPuBobUQjUxL64RvgctNkORMADH7FlD3CSIZ40wKlynv3 L9MKhiqXds/QETFmUlPAwu9Us=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 2007-1-12, at 20:09, ext Dan Wing wrote: > > At the San Diego meeting there were positive comments around this > > approach. > > Is there interest in moving this work forward? > > this document takes STUN in a whole new direction (middlebox > control) that would probably require a recharter. I asked Magnus that question offline, and he concurs it doesn't fit within BEHAVE's existing charter. > > Also, the draft says: > > Unlike some other > > techniques (e.g., UPnP [UPnP], MIDCOM [RFC3303], Bonjour > > [Bonjour]), > > STUN does not interact directly with the NAT. Because > > STUN doesn't > > interact directly with the NAT, STUN cannot request additional > > services from the NAT such as longer lifetimes (which > > would reduce keepalive messages). > > > > This paper describes a mechanism for the STUN client to interact > > directly with the NAT and request additional services, > > by using the > > STUN protocol itself. > > For a convincing rechartering argument, it'd be very useful to see a > discussion on why adding this to STUN is significantly better than > the myriad of exiting approaches to control middleboxes. In addition > to the ones mentioned in the draft, at least NSIS and SIMCO > also exist. -01 added a little more information showing advantages of the NAT Control STUN Usage. We can add a point-by-point comparison of this approach versus NSIS, SIMCO (an implementation of MIDCOM), UPnP, and Bonjour, and ask the community again if there seems to be sufficient merit to this approach versus the other protocols for NAT traversal and NAT control. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 23 16:26:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKhv2-0003Ec-PY; Fri, 23 Feb 2007 16:25:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKhv1-0003EP-NU for behave@ietf.org; Fri, 23 Feb 2007 16:25:31 -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 1HKhv0-0005E0-9N for behave@ietf.org; Fri, 23 Feb 2007 16:25:31 -0500 Received: from [172.17.1.57] ([172.17.1.57]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id l1NLPR0w036022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 23 Feb 2007 15:25:27 -0600 (CST) (envelope-from brian@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <685F7EF5-0A33-4E37-A6A4-56A0F0EE03DD@estacado.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: behave@ietf.org From: Brian Hibbard Date: Fri, 23 Feb 2007 15:25:21 -0600 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [BEHAVE] TURN security issue X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Should the STUN Relay Usage specify that NONCE is required for all Allocate Requests, regardless of whether they are "signed" with short- term credentials or long-term credentials? I brought this to the BEHAVE list a while ago as an issue to possibly be addressed in the draft 3489bis, but Jonathan pointed out that NOT using NONCE with short-term credentials is not necessarily a vulnerability in every usage. One consequence of not using a NONCE where short-term credentials are used is that a patient attacker could replay valid Allocate Requests for the lifetime of the short- term secret that was used to "sign" the replayed request. This mode of attack could continue for as long as the client requests new credentials and subsequently sends new Allocate Requests. For convenience, this the relevant text from sec 9.1.1 (page 25) of draft-rfc3489bis-05: When an error response is to be generated by the server as a consequence of authentication problems (error codes 401, 432, 434, 435, 430 and 436, and the REALM is present in the response (signifying the usage of a long term credential), the server MUST include a NONCE attribute in the response. The nonce includes a random value that the server wishes the client to reflect back in a subsequent request (and therefore include in the message integrity computation). When the REALM is absent in the response, the server MAY include a NONCE in the response if it wishes to use nonces along with short-term shared secrets (with the exception of 435, where NONCE is mandatory even for short term credentials). However, there is little reason to do so, since the short-term password is, by definition, short-term, and thus additional temporal scoping through the nonce is not needed. For STUN Relay Usage, the "... MAY include a NONCE ..." should probably be "... SHOULD ..." or "...MUST..." ---at least for Allocate Requests. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 23 16:47:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKiGM-0001Fx-2z; Fri, 23 Feb 2007 16:47:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKiGL-0001Fl-FC for behave@ietf.org; Fri, 23 Feb 2007 16:47:33 -0500 Received: from an-out-0708.google.com ([209.85.132.248]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKiGK-0002m2-8d for behave@ietf.org; Fri, 23 Feb 2007 16:47:33 -0500 Received: by an-out-0708.google.com with SMTP id d30so513624and for ; Fri, 23 Feb 2007 13:47:31 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=KymLXXRFMsC/K1Anvklq9nmWgdfakVWZusg/rnyMkuzT6lkIMx1zjrforoqXeK5v2u8tP9tAWK8ZKHDyRuuwjLjJSQoGIud3YMHY1FHhS4EcVaQ0klm4zZ7faUYXvk3D8lEkjzI64GdJaKac1rAZl/nsAAV90kDUQs0Z/HGsFtg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=meaRAV8TR4umtZpqjCStqFrPoG9qT2TNZdWPO3k81B6q0g6ww/FeFJR6T0PIujftiz1KyFdu0V7J9g1m29Icvz82Se7F5uyKczfYVIqNmSK5UVQEDYp5EjAgepr2hYGErLuFDJk1wI660JhKTclDUvOhdzOS7OO7EGphE90Lr+w= Received: by 10.114.93.1 with SMTP id q1mr1243845wab.1172267251142; Fri, 23 Feb 2007 13:47:31 -0800 (PST) Received: by 10.115.88.9 with HTTP; Fri, 23 Feb 2007 13:47:31 -0800 (PST) Message-ID: <20d2bdfb0702231347u1fab6fbel20d06dc9a78a0a93@mail.gmail.com> Date: Fri, 23 Feb 2007 16:47:31 -0500 From: "Bruce Lowekamp" To: behave@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 59373fb57a540cf4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [BEHAVE] draft-ietf-behave-nat-behavior-discovery-00 submitted X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Derek and I have submitted draft-ietf-behave-nat-behavior-discovery-00 to internet-drafts. Until it appears in the repository, I've posted temporary copies at: http://www.sipeerior.com/tmp/draft-ietf-behave-nat-behavior-discovery-00.html http://www.sipeerior.com/tmp/draft-ietf-behave-nat-behavior-discovery-00.txt Changes from draft-macdonald-behave-nat-behavior-discovery-00: * Only OTHER-ADDRESS, CHANGE-ADDRESS, RESPONSE-ADDRESS and XOR-RESPONSE-ADDRESS support is optional; support for PADDING and SOURCE-ADDRESS is now mandatory * PADDING is now a mandatory attribute * OTHER-ADDRESS is returned in all binding responses if the server has a second IP address The changes made in this revision depend on 3489bis being changed to allow OTHER-ADDRESS and SOURCE-ADDRESS for backwards compatibility with 3489. Bruce _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Feb 23 17:22:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKioB-0008T6-EQ; Fri, 23 Feb 2007 17:22:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKioA-0008Sv-7o for behave@ietf.org; Fri, 23 Feb 2007 17:22:30 -0500 Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKio8-0007a8-FC for behave@ietf.org; Fri, 23 Feb 2007 17:22:30 -0500 Received: by nf-out-0910.google.com with SMTP id l36so1108817nfa for ; Fri, 23 Feb 2007 14:22:27 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; b=pJq3PM9lIKMTv8hbXXO9aWuVkbX+0p5cPdDL2XMaiDYKGVdhdHZNiwBXpPSIKieYLZpomXIYpUS9ApOJ5e3vcQXbMbkDcP/2y4G+c22UnvDjOURek+TGBVBNQPMqtyIbukTdPR1H/MtKVcd21Hdvihl1WTbD/4eyZKz0hv9wx3A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; b=D2F9CnBih802w6y6DOEArIdZMwkCRxPsd85z0IS7aXBVoBZ8lxtLcZ6/m5yRXkJtL6yWwAG+H9raEmhL5OJ0vhFd3u6ylTuvtIvHiOPMmm19AzxnnM748Bd/zLPhvVmdTAL55PXUyx5EbxEpBmgMDOMJY42H1CAn3s4w97ynqDk= Received: by 10.48.48.1 with SMTP id v1mr6988443nfv.1172269346548; Fri, 23 Feb 2007 14:22:26 -0800 (PST) Received: by 10.49.28.8 with HTTP; Fri, 23 Feb 2007 14:22:26 -0800 (PST) Message-ID: Date: Fri, 23 Feb 2007 14:22:26 -0800 From: "Derek MacDonald" To: "Bruce Lowekamp" , behave@ietf.org Subject: Re: [BEHAVE] draft-ietf-behave-nat-behavior-discovery-00 MIME-Version: 1.0 X-Google-Sender-Auth: 5124564bdd7fa2bb X-Spam-Score: 1.2 (+) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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: , Content-Type: multipart/mixed; boundary="===============1472180993==" Errors-To: behave-bounces@ietf.org --===============1472180993== Content-Type: multipart/alternative; boundary="----=_Part_61348_17558907.1172269346519" ------=_Part_61348_17558907.1172269346519 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Dan Wing and I were talking about the issue of having to define mandatory attributes in 3489bis that are returned in responses by behaviour-discovery server draft, and for backwards compatibility with old 3489 servers. It seemed wrong that we had to define attributes in one draft solely for use in another draft. We propose removing: Responses containing unknown mandatory attributions (less than or equal to 0x7FFF) MUST be discarded and considered immediately as a failed transaction. >From section 8.3.2 of 3489bis. This would not change the behavior for requests with unknown mandatory attributes. -Derek On 2/23/07, Bruce Lowekamp wrote: > > Derek and I have submitted draft-ietf-behave-nat-behavior-discovery-00 > to internet-drafts. Until it appears in the repository, I've posted > temporary copies at: > > > http://www.sipeerior.com/tmp/draft-ietf-behave-nat-behavior-discovery-00.html > > http://www.sipeerior.com/tmp/draft-ietf-behave-nat-behavior-discovery-00.txt > > Changes from draft-macdonald-behave-nat-behavior-discovery-00: > > * Only OTHER-ADDRESS, CHANGE-ADDRESS, RESPONSE-ADDRESS and > XOR-RESPONSE-ADDRESS support is optional; support for PADDING and > SOURCE-ADDRESS is now mandatory > * PADDING is now a mandatory attribute > * OTHER-ADDRESS is returned in all binding responses if the server > has a second IP address > > The changes made in this revision depend on 3489bis being changed to > allow OTHER-ADDRESS and SOURCE-ADDRESS for backwards compatibility > with 3489. > > > Bruce > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > ------=_Part_61348_17558907.1172269346519 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dan Wing and I were talking about the issue of having to define mandatory attributes in 3489bis that are returned in responses by behaviour-discovery server draft, and for backwards compatibility with old 3489 servers. It seemed wrong that we had to define attributes in one draft solely for use in another draft.

We propose removing:

   Responses containing unknown mandatory attributions (less than or equal to 0x7FFF) MUST be
   discarded and considered immediately as a failed transaction.

From section 8.3.2 of 3489bis.  This would not change the behavior for requests with unknown mandatory attributes.

-Derek

On 2/23/07, Bruce Lowekamp < lowekamp@sipeerior.com> wrote:
Derek and I have submitted draft-ietf-behave-nat-behavior-discovery-00
to internet-drafts.  Until it appears in the repository, I've posted
temporary copies at:

http://www.sipeerior.com/tmp/draft-ietf-behave-nat-behavior-discovery-00.html
http://www.sipeerior.com/tmp/draft-ietf-behave-nat-behavior-discovery-00.txt

Changes from draft-macdonald-behave-nat-behavior-discovery-00:

    * Only OTHER-ADDRESS, CHANGE-ADDRESS, RESPONSE-ADDRESS and
XOR-RESPONSE-ADDRESS support is optional; support for PADDING and
SOURCE-ADDRESS is now mandatory
    * PADDING is now a mandatory attribute
    * OTHER-ADDRESS is returned in all binding responses if the server
has a second IP address

The changes made in this revision depend on 3489bis being changed to
allow OTHER-ADDRESS and SOURCE-ADDRESS for backwards compatibility
with 3489.


Bruce

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

------=_Part_61348_17558907.1172269346519-- --===============1472180993== 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 --===============1472180993==-- From behave-bounces@ietf.org Fri Feb 23 18:58:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKkJ9-000128-W9; Fri, 23 Feb 2007 18:58:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKkJ7-0000xJ-7B for behave@ietf.org; Fri, 23 Feb 2007 18:58:33 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKkIj-0006gd-6e for behave@ietf.org; Fri, 23 Feb 2007 18:58:33 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l1NNw6319769; Fri, 23 Feb 2007 18:58:06 -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] draft-ietf-behave-nat-behavior-discovery-00 submitted Date: Fri, 23 Feb 2007 17:58:05 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0F522994@zrc2hxm0.corp.nortel.com> In-Reply-To: <20d2bdfb0702231347u1fab6fbel20d06dc9a78a0a93@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] draft-ietf-behave-nat-behavior-discovery-00 submitted Thread-Index: AcdXlKkyZqV8i7aYRFOhXERTiss1OgAESxRA From: "Francois Audet" To: "Bruce Lowekamp" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 Bruce/Derek, excellent draft. Minor comments: - make sure you replace Reference [3] with RFC 4787. - I think there needs to be an Operation for "Determining presence of NAT". Even before you 3.1 operation. > -----Original Message----- > From: Bruce Lowekamp [mailto:lowekamp@sipeerior.com]=20 > Sent: Friday, February 23, 2007 13:48 > To: behave@ietf.org > Subject: [BEHAVE] draft-ietf-behave-nat-behavior-discovery-00=20 > submitted >=20 > Derek and I have submitted draft-ietf-behave-nat-behavior-discovery-00 > to internet-drafts. Until it appears in the repository, I've=20 > posted temporary copies at: >=20 > http://www.sipeerior.com/tmp/draft-ietf-behave-nat-behavior-di > scovery-00.html > http://www.sipeerior.com/tmp/draft-ietf-behave-nat-behavior-di > scovery-00.txt >=20 > Changes from draft-macdonald-behave-nat-behavior-discovery-00: >=20 > * Only OTHER-ADDRESS, CHANGE-ADDRESS, RESPONSE-ADDRESS=20 > and XOR-RESPONSE-ADDRESS support is optional; support for=20 > PADDING and SOURCE-ADDRESS is now mandatory > * PADDING is now a mandatory attribute > * OTHER-ADDRESS is returned in all binding responses if=20 > the server has a second IP address >=20 > The changes made in this revision depend on 3489bis being=20 > changed to allow OTHER-ADDRESS and SOURCE-ADDRESS for=20 > backwards compatibility with 3489. >=20 >=20 > Bruce >=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 Sun Feb 25 11:52:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLMaL-0008HM-PL; Sun, 25 Feb 2007 11:50:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLMaJ-0008Gd-Rc for behave@ietf.org; Sun, 25 Feb 2007 11:50:51 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLMaI-00083L-H3 for behave@ietf.org; Sun, 25 Feb 2007 11:50:51 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 25 Feb 2007 08:50:50 -0800 X-IronPort-AV: i="4.14,216,1170662400"; d="scan'208"; a="393246530:sNHT45578052" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l1PGon5w012352; Sun, 25 Feb 2007 08:50:49 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id l1PGomhp004676; Sun, 25 Feb 2007 08:50:48 -0800 (PST) In-Reply-To: <053301c7553a$11912ee0$c2f0200a@amer.cisco.com> References: <053301c7553a$11912ee0$c2f0200a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8EC5870A-5D67-4713-8232-604725E65481@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] WGLC for behave-p2pstate-02 starts now Date: Sun, 25 Feb 2007 08:50:29 -0800 To: Behave WG X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1770; t=1172422249; x=1173286249; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20WGLC=20for=20behave-p2pstate-02=20starts=2 0now |Sender:=20; bh=EZitTWCNp2aQVoaowUfhdgAWSxTLEd+qve1yeUfdwpU=; b=VMtPa8BfBBjdSTCjdRWIc8AaQPC32cMAUJgdDMjd1O9Tzb7TCthTMo6B8KpzVoaXS0PLhXvS qk95FMeQuGKywKjaVn2jSH8WESv+VsGMfxjZ7PdATTo7XlNxKbZaMfGw; Authentication-Results: sj-dkim-6; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 There is lots of really good stuff in here but this draft looks like it needs more work before it is ready for WGLC. A few things that I am afraid other reviewers might not bring up .... It has lots of confusing terminology - I suggest it stop using all the terminology that the document does not need - for example "symmetric" I don't think it should be duplicating explaining terms that are defined elsewhere. I think the term "P2P Friendly" is a major marketing mistake and highly likely to ensure vendors don't want to do this. I would use "Behave Compliant" and define that as a nat compliant with the UDP and TCP documents. I would move away from P2P - it has meaning to most people beyond what you mean hear and perhaps talk more about end to end which is what you are actually trying to achieve here. On Feb 20, 2007, at 1:57 PM, Dan Wing wrote: > The working group last call for behave-p2p-state-02 starts now. > URL for > this document is > http://www.ietf.org/internet-drafts/draft-ietf-behave-p2p-state-02.txt > > Abstract: > This memo documents the various methods known to be in use by > peer-to-peer (P2P) applications for communication in the presence > of Network Address Translators (NATs) at the current time. This > memo covers NAT traversal approaches used by both TCP and UDP > based applications. This memo is not an endorsement of the methods > described, but merely an attempt to capture them in a document. > > > WGLC ends in two weeks on Tuesday, March 6. > > Please send comments to behave@ietf.org. > > -d > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Feb 25 19:56:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLU9P-0004yx-1y; Sun, 25 Feb 2007 19:55:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLU9N-0004yn-De for behave@ietf.org; Sun, 25 Feb 2007 19:55:33 -0500 Received: from web33313.mail.mud.yahoo.com ([68.142.206.128]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HLU9L-0001cq-UM for behave@ietf.org; Sun, 25 Feb 2007 19:55:33 -0500 Received: (qmail 15595 invoked by uid 60001); 26 Feb 2007 00:55:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=bTL4bJJzngCIczuWAW7+I6E1wgzq/INi7qQ0cQf/e+t52hW5oEiGPkLKj38g2RKwVLdfj9oev+avzMmQRZOgdA3bhdXi/Szn95Z6m0dB/aBjj3jNubolxGPnRtWB+8/lh7HVaE8XZvAsnU+AA75RNWNr86KZV+X/eEccWE2JFRw=; X-YMail-OSG: O6jgaoYVM1n7A8KtWfJz9fBMcYGpBdgboc6hxhe21F_bC7nOhGqMYSq6QwnE82pgsKYil3UIHVOx4ayrlata5S_sUjlM1iSlhSLfPcrHvmL2LVO6_dgyDDx5mf12uQZXfnM0tjSoKrM- Received: from [69.236.102.196] by web33313.mail.mud.yahoo.com via HTTP; Sun, 25 Feb 2007 16:55:31 PST Date: Sun, 25 Feb 2007 16:55:31 -0800 (PST) From: Pyda Srisuresh Subject: Re: [BEHAVE] WGLC for behave-p2pstate-02 starts now To: Cullen Jennings , Behave WG In-Reply-To: <8EC5870A-5D67-4713-8232-604725E65481@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <417381.14931.qm@web33313.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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 My responses inline. --- Cullen Jennings wrote: > > There is lots of really good stuff in here but this draft looks like > it needs more work before it is ready for WGLC. > > A few things that I am afraid other reviewers might not bring up .... > [suresh] I dont understand what you mean here. Why are you afraid that others wont bring up, but you alone can? Is this something you alone would know or should I and others have known as well? I certainly do not know and am at a loss with your comment. Please explain. > It has lots of confusing terminology - I suggest it stop using all > the terminology that the document does not need - for example > "symmetric" > [suresh] The document uses the terms defined in section 2. There is exactly one mention of "Symmetric NAT" in section 2.4 under "Endpoint-Dependent Mapping" as follows. Symmetric NAT devices ([STUN]) are a good example of NAT devices performing Endpoint-Dependent Mapping. This is a perfectly valid usage and is hardly confusing. I am wondering if you read the draft that was called for WGLC or some older rev. I did notice, the TOC lists section 5.2 as "Symmteric NATs are not P2P friedly". This is a typo. I will fix this. The actual section 5.2 is titled, "NATs Employing Endpoint-Dependent Mapping are not P2P friendly". > I don't think it should be duplicating explaining terms that are > defined elsewhere. > [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. Why is this a problem? > I think the term "P2P Friendly" is a major marketing mistake and > highly likely to ensure vendors don't want to do this. [suresh] I cannot parse your sentence. I certainly donot understand what you are trying to say. Why is the term "P2P friendly" a marketing mistake? Even if so, Why should I care in this draft? And, What does "highly likely to ensure vendors don't want to do this" mean? Please explain. > I would use > "Behave Compliant" and define that as a nat compliant with the UDP > and TCP documents. [suresh] The title of this draft is "State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs)". This is independent of the BEHAVE compliance. The document is not about making recommendations. I dont see any point in using "BEHAVE compliant" term. Oh, by the way, you missed mentioning ICMP BEHAVE document for "behave compliant" definition. Was that a mistake (or) you do not think the ICMP document needs mention? > I would move away from P2P - it has meaning to > most people beyond what you mean hear and perhaps talk more about end > to end which is what you are actually trying to achieve here. [suresh] I dont know what you have in mind for this document. But, AFAIK, the focus of the document, from its very inception has been cocerning P2P. In case you are attributing different meanings, please note, the document defines a P2P application in section 2.7 as follows. A P2P application is an application that uses the same endpoint to initiate outgoing sessions to peering hosts as well as accept incoming sessions from peering hosts. regards, suresh > > > On Feb 20, 2007, at 1:57 PM, Dan Wing wrote: > > > The working group last call for behave-p2p-state-02 starts now. > > URL for > > this document is > > http://www.ietf.org/internet-drafts/draft-ietf-behave-p2p-state-02.txt > > > > Abstract: > > This memo documents the various methods known to be in use by > > peer-to-peer (P2P) applications for communication in the presence > > of Network Address Translators (NATs) at the current time. This > > memo covers NAT traversal approaches used by both TCP and UDP > > based applications. This memo is not an endorsement of the methods > > described, but merely an attempt to capture them in a document. > > > > > > WGLC ends in two weeks on Tuesday, March 6. > > > > Please send comments to behave@ietf.org. > > > > -d > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www1.ietf.org/mailman/listinfo/behave > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Feb 25 21:28:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLVaE-0008Ha-12; Sun, 25 Feb 2007 21:27:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLVaC-0008HP-IA for behave@ietf.org; Sun, 25 Feb 2007 21:27:20 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLVaB-0005B3-9q for behave@ietf.org; Sun, 25 Feb 2007 21:27:20 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 25 Feb 2007 18:27:18 -0800 X-IronPort-AV: i="4.14,217,1170662400"; d="scan'208"; a="42405882:sNHT54054018" 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/8.12.11) with ESMTP id l1Q2RIXJ017654; Sun, 25 Feb 2007 18:27:18 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l1Q2RInG029673; Sun, 25 Feb 2007 18:27:18 -0800 (PST) In-Reply-To: <417381.14931.qm@web33313.mail.mud.yahoo.com> References: <417381.14931.qm@web33313.mail.mud.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] WGLC for behave-p2pstate-02 starts now Date: Sun, 25 Feb 2007 18:26:59 -0800 To: Pyda Srisuresh X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=590; t=1172456838; x=1173320838; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20WGLC=20for=20behave-p2pstate-02=20starts=2 0now |Sender:=20; bh=5oxqI6eo+kwzAuO/2AESYMbB1og0unOPZPiDNZiblb8=; b=exRFF0dNHX3pHtsfeVRXxxqGIhOVuQSax24aUj9ULqPCeE0ENbE7Pu5vQ53Zib79xjckkbBA gIe+05dsw/zVMoYRL1zPkEA0SsS0WxkpBVpZlNuZEpitYVVrh9g6dBUE; Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Behave WG , Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Feb 25, 2007, at 4:55 PM, Pyda Srisuresh wrote: > Symmetric NAT devices ([STUN]) are a good example of NAT devices > performing Endpoint-Dependent Mapping. > > This is a perfectly valid usage and is hardly confusing. I am > wondering if you > read the draft that was called for WGLC or some older rev. We agreed not to use this terminology and moved to new terminology because this term was under-specified and the way [STUN] used the work symmetric was in direct conflict with how all firewall vendors used the word and how most NAT vendors use the word. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 26 10:10:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLhUC-0005KL-9z; Mon, 26 Feb 2007 10:09:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLhUA-0005KG-SU for behave@ietf.org; Mon, 26 Feb 2007 10:09:54 -0500 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLhU7-000616-Hq for behave@ietf.org; Mon, 26 Feb 2007 10:09:54 -0500 Received: from [192.168.0.65] (unknown [81.178.58.134]) by smtp.mxes.net (Postfix) with ESMTP id 1723E51948 for ; Mon, 26 Feb 2007 10:09:49 -0500 (EST) Message-ID: <45E2F845.5070304@pjsip.org> Date: Mon, 26 Feb 2007 15:09:57 +0000 From: Benny Prijono User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) 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: 2409bba43e9c8d580670fda8b695204a Subject: [BEHAVE] STUN: switching credential from long term to short term X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org All, we know that the presence of REALM attribute in the STUN message indicates the signal to use long term credential. Now, what should the server do when it receives STUN request with REALM attribute on it, but the server wants to use short term credential instead? At best now, server can reject with 435 (Unknown Username), but with this client can mistakenly think that its long term credential is rejected. One way to support this is for the server to send 401 (Unauthorized) error code without REALM attribute. A wording change would be needed in both server and client processing to support this, but at least on the client side, this change should be backward compatible with the old behavior (clients which comply to bis-05 will not retry the request, while clients which comply to this would retry the request as wanted). cheers, -benny -- Benny Prijono http://www.pjsip.org _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 26 10:11:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLhVp-0006Ay-CD; Mon, 26 Feb 2007 10:11:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLhVo-00068a-9R; Mon, 26 Feb 2007 10:11:36 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLhVm-0006Az-VA; Mon, 26 Feb 2007 10:11:36 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 80CD020880; Mon, 26 Feb 2007 16:10:25 +0100 (CET) X-AuditID: c1b4fb3c-ae7c5bb0000007de-ba-45e2f861f8fd Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 70F6220549; Mon, 26 Feb 2007 16:10:25 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 16:10:25 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 16:10:24 +0100 Message-ID: <45E2F860.1000407@ericsson.com> Date: Mon, 26 Feb 2007 16:10:24 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [BEHAVE] [Fwd: Last Call: draft-wing-behave-symmetric-rtprtcp (Common Local Transmit and Receive Ports (Symmetric RTP)) to Informational RFC] References: <45D0D77F.8030705@ericsson.com> <45D21CC4.10909@ericsson.com> In-Reply-To: <45D21CC4.10909@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2007 15:10:24.0898 (UTC) FILETIME=[3DCBF620:01C759B8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: behave@ietf.org, IETF AVT WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Magnus Westerlund skrev: > There has been raised a comment that this document should contain a > normative recommendation on using symmetric ports. However to make this > happen the document would need to be a BCP. I am willing to consider > this but would like to have AVT and Behave WG participant's view on > doing this before progressing down that road and updating the IETF last > call. So please provide comments by Tuesday 20th of Feb on this issue. > There has been no objections against making this into a BCP. Dan can you please update your draft with the proposed requirement text. 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 Mon Feb 26 10:26:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLhjg-00027y-IV; Mon, 26 Feb 2007 10:25:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLhjf-00027t-FH for behave@ietf.org; Mon, 26 Feb 2007 10:25:55 -0500 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HLhjY-0003gV-12 for behave@ietf.org; Mon, 26 Feb 2007 10:25:55 -0500 Received: by mail.iptel.org (Postfix, from userid 103) id DB26120A30C; Mon, 26 Feb 2007 16:25:33 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on rat.iptel.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from hoth.office.iptelorg.de (unknown [217.9.54.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "nils", Issuer "iptel.org" (not verified)) by mail.iptel.org (Postfix) with ESMTP id 01BB420A6C7; Mon, 26 Feb 2007 16:25:30 +0100 (CET) From: Nils Ohlmeier Organization: iptelorg To: behave@ietf.org Subject: Re: [BEHAVE] draft-ietf-behave-nat-behavior-discovery-00 submitted Date: Mon, 26 Feb 2007 16:25:20 +0100 User-Agent: KMail/1.9.6 References: <20d2bdfb0702231347u1fab6fbel20d06dc9a78a0a93@mail.gmail.com> In-Reply-To: <20d2bdfb0702231347u1fab6fbel20d06dc9a78a0a93@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200702261625.21089.nils@iptel.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Bruce and Derek, just a minor comment: in section 4.1 you conclude "that it is not capable of UDP connectivity" but you do not specify which transports is to be used for this test. The headline of section 4.1 makes it more less obvious, but to be safe I would suggest to explicitly mention in the first sentense of 4.1 that UDP has to be used for this test. Greetings Nils On Friday 23 February 2007 22:47:31 Bruce Lowekamp wrote: > Derek and I have submitted draft-ietf-behave-nat-behavior-discovery-00 > to internet-drafts. Until it appears in the repository, I've posted > temporary copies at: > > http://www.sipeerior.com/tmp/draft-ietf-behave-nat-behavior-discovery-00.ht >ml > http://www.sipeerior.com/tmp/draft-ietf-behave-nat-behavior-discovery-00.tx >t > > Changes from draft-macdonald-behave-nat-behavior-discovery-00: > > * Only OTHER-ADDRESS, CHANGE-ADDRESS, RESPONSE-ADDRESS and > XOR-RESPONSE-ADDRESS support is optional; support for PADDING and > SOURCE-ADDRESS is now mandatory > * PADDING is now a mandatory attribute > * OTHER-ADDRESS is returned in all binding responses if the server > has a second IP address > > The changes made in this revision depend on 3489bis being changed to > allow OTHER-ADDRESS and SOURCE-ADDRESS for backwards compatibility > with 3489. > > > Bruce > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 26 13:31:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLkd7-0000Cf-Vm; Mon, 26 Feb 2007 13:31:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLkd6-0000CO-TW for behave@ietf.org; Mon, 26 Feb 2007 13:31:20 -0500 Received: from web33304.mail.mud.yahoo.com ([68.142.206.119]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HLkd3-0006LW-FE for behave@ietf.org; Mon, 26 Feb 2007 13:31:20 -0500 Received: (qmail 34694 invoked by uid 60001); 26 Feb 2007 18:31:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Cf85wjsZn+d94XyjL6phpP82ZaoZorjCj0ofM7B9was3KLySqMB8kbK0YqcT1hUr4/KNDY5k9RxTVn087hHk34EH8HVnWHE0/FX7ioyxo4Pa40KwQWJMwouIVvsnqsuP2yS3iG8oK94wCU0EfLBdx+Apcxy3xbH2hfhzu8knEW8=; X-YMail-OSG: BTRObZcVM1mwd.wo1DvNIqR6jRgmITNHtw0Gb9koDeWdzm1dHWTb6w8jZ50I5yBVsrgO2l5.O44h2u4LDoTtuwUlJ3JY8Tea1.fEdzfncFYGG4qCif0KRNHsSFOBbnSr0yaJjNjD2F4- Received: from [209.172.74.45] by web33304.mail.mud.yahoo.com via HTTP; Mon, 26 Feb 2007 10:31:16 PST Date: Mon, 26 Feb 2007 10:31:16 -0800 (PST) From: Pyda Srisuresh Subject: Re: [BEHAVE] WGLC for behave-p2pstate-02 starts now To: Cullen Jennings In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <673973.31745.qm@web33304.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Behave WG , 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 --- Cullen Jennings wrote: > > On Feb 25, 2007, at 4:55 PM, Pyda Srisuresh wrote: > > > Symmetric NAT devices ([STUN]) are a good example of NAT devices > > performing Endpoint-Dependent Mapping. > > > > This is a perfectly valid usage and is hardly confusing. I am > > wondering if you > > read the draft that was called for WGLC or some older rev. > > We agreed not to use this terminology and moved to new terminology > because this term was under-specified and the way [STUN] used the > work symmetric was in direct conflict with how all firewall vendors > used the word and how most NAT vendors use the word. > [suresh] Cullen - You responded back to just this one comment. Am I to understand this is your only remaining comment on the draft for WGLC? What other comments do you have outstanding for WGLC on the draft? regards, suresh _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 26 13:39:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLkkj-0006VD-EK; Mon, 26 Feb 2007 13:39:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLkki-0006Uq-H6 for behave@ietf.org; Mon, 26 Feb 2007 13:39:12 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLkkQ-00080O-Nn for behave@ietf.org; Mon, 26 Feb 2007 13:39:12 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 26 Feb 2007 10:38:54 -0800 X-IronPort-AV: i="4.14,221,1170662400"; d="scan'208"; a="764543106:sNHT52573880" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l1QIcsYh008587; Mon, 26 Feb 2007 10:38:54 -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 l1QIccVK008831; Mon, 26 Feb 2007 10:38:54 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 10:38:51 -0800 Received: from [128.107.30.221] ([10.21.144.207]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 10:38:50 -0800 In-Reply-To: <673973.31745.qm@web33304.mail.mud.yahoo.com> References: <673973.31745.qm@web33304.mail.mud.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <65531CB7-ED7E-48C8-B9FB-F8319C782EDE@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] WGLC for behave-p2pstate-02 starts now Date: Mon, 26 Feb 2007 10:38:48 -0800 To: Pyda Srisuresh X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Feb 2007 18:38:50.0844 (UTC) FILETIME=[5BEBE1C0:01C759D5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1128; t=1172515134; x=1173379134; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20WGLC=20for=20behave-p2pstate-02=20starts=2 0now |Sender:=20; bh=T9Sq+xBoU2H11E0/9JElWmexMV7hOr46ryT3ylMwoQw=; b=AlKHjZw8+LivnFPDPzoudJYEa+jyIfngjWlGxj3TEpb45F5EgD70bRZlgiZZnHC70VI7FhNx M5hiJ8G4wrL/KxCGij7OA5kUkghvqH9yF1mmSoolkTo9iKVBzJhYZvgL; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Behave WG , Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Feb 26, 2007, at 10:31 AM, Pyda Srisuresh wrote: > > --- Cullen Jennings wrote: > >> >> On Feb 25, 2007, at 4:55 PM, Pyda Srisuresh wrote: >> >>> Symmetric NAT devices ([STUN]) are a good example of NAT devices >>> performing Endpoint-Dependent Mapping. >>> >>> This is a perfectly valid usage and is hardly confusing. I am >>> wondering if you >>> read the draft that was called for WGLC or some older rev. >> >> We agreed not to use this terminology and moved to new terminology >> because this term was under-specified and the way [STUN] used the >> work symmetric was in direct conflict with how all firewall vendors >> used the word and how most NAT vendors use the word. >> > [suresh] Cullen - You responded back to just this one comment. Am I to > understand this is your only remaining comment on the draft for WGLC? that would be an incorrect understanding. > What > other comments do you have outstanding for WGLC on the draft? I don't think this document is ready or WGLC - I sent some examples of why in my previous email. > > regards, > suresh _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 26 14:19:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLlNZ-0000o9-Lw; Mon, 26 Feb 2007 14:19:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLlNY-0000nq-5w for behave@ietf.org; Mon, 26 Feb 2007 14:19:20 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLlNW-0008IX-Sp for behave@ietf.org; Mon, 26 Feb 2007 14:19:20 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-6.cisco.com with ESMTP; 26 Feb 2007 11:19:18 -0800 X-IronPort-AV: i="4.14,221,1170662400"; d="scan'208"; a="116264669:sNHT56971305" 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 l1QJJIsZ004243; Mon, 26 Feb 2007 11:19:18 -0800 Received: from dwingwxp ([128.107.114.231]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1QJJDnI005362; Mon, 26 Feb 2007 11:19:18 -0800 (PST) From: "Dan Wing" To: "'Pyda Srisuresh'" , "'Cullen Jennings'" , "'Behave WG'" Subject: RE: [BEHAVE] WGLC for behave-p2pstate-02 starts now Date: Mon, 26 Feb 2007 11:19:13 -0800 Message-ID: <003401c759db$029f9070$e7726b80@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.3028 Thread-Index: AcdZQNIK3Tzo+lKqT1WrVD/D0pHzuAADkhNg In-Reply-To: <417381.14931.qm@web33313.mail.mud.yahoo.com> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1489; t=1172517558; x=1173381558; 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]=20WGLC=20for=20behave-p2pstate-02=20starts=2 0now |Sender:=20; bh=Fe6mqGbEKq2YuwgMJEWC4vSbplC4uVGf/6g/rM5ZLV8=; b=cC/lE4U2cXpmGisr8AX+aQHX1+ORMA0DTSvejvDH4XBU+gaHXY1fIQ7kzKNeHqmGJW32Wzvi ZrcroHGv6N2yMuKZe5NdQjB3e0uZ81RtDTOHXygfZbviysR0oQTtINk3; 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: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > > I think the term "P2P Friendly" is a major marketing mistake and > > highly likely to ensure vendors don't want to do this. > > [suresh] I cannot parse your sentence. I certainly donot > understand what you are trying to say. Why is the term "P2P > friendly" a marketing mistake? Even if so, Why should I care > in this draft? And, What does "highly likely to ensure > vendors don't want to do this" mean? Please explain. Almost immediately after the advent of the first popular peer- to-peer file sharing networks (Kazza and Gnutella), the term "peer-to-peer" has implied illicit sharing of copyrighted content. Thus, "peer-to-peer friendly" implies friendliness towards the same. Unfortunately, the fact that other protocols operate in a peer-to-peer fashion is lost on most people (for example, networked games, SIP, Microsoft's NetMeeting, etc.). I believe Cullen's concern is that using the unqualified term "peer-to-peer" brings to mind illicit file sharing, and nobody wants their company to be associated with illicit activities. Such an association is always a business risk and typically an unnecessary business risk. Our milestone for this item is: Mar 2007 Submit informational that discusses current NAT traversal techniques used by applications So, perhaps downplaying the use of the term "peer to peer" is what Cullen was referring to. Or perhaps eliminating it entirely. I'm not entirely sure. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 26 14:24:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLlSw-0002MO-Cr; Mon, 26 Feb 2007 14:24:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLlSu-0002M8-9i; Mon, 26 Feb 2007 14:24:52 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLlSo-0000iF-LJ; Mon, 26 Feb 2007 14:24:52 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-6.cisco.com with ESMTP; 26 Feb 2007 11:24:46 -0800 X-IronPort-AV: i="4.14,221,1170662400"; d="scan'208"; a="116265847:sNHT50773662" 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 l1QJOjBK013457; Mon, 26 Feb 2007 11:24:45 -0800 Received: from dwingwxp ([128.107.114.231]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1QJOjnF011388; Mon, 26 Feb 2007 11:24:45 -0800 (PST) From: "Dan Wing" To: "'Magnus Westerlund'" Subject: RE: [BEHAVE] [Fwd: Last Call: draft-wing-behave-symmetric-rtprtcp(Common Local Transmit and Receive Ports (Symmetric RTP)) toInformational RFC] Date: Mon, 26 Feb 2007 11:24:45 -0800 Message-ID: <00bb01c759db$c5e81660$e7726b80@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.3028 Thread-Index: AcdZuIX6vyomh2jUQFuV62AG9Ty1ugAItgLw In-Reply-To: <45E2F860.1000407@ericsson.com> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2032; t=1172517885; x=1173381885; 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]=20[Fwd=3A=20Last=20Call=3A=20draft-wing-beha ve-symmetric-rtprtcp(Common=20Local=20Transmit=20and=20Receive=20Ports=20( Symmetric=20RTP))=20toInformational=20RFC] |Sender:=20; bh=Hwkz3VnXINXMi7U/FRCUorB8BXK2BF2gNqo0Zjsc+RU=; b=VBvZ+9L2KW4MmfAwFGk+VLpjHRxqJ554gEBRz/AypH6/gcwqtW8w4IFDFbFny3N3zDE5Cy/I PGK8whNtgoObGrn+H3FQTXuuSgN5kAvDWg/Lk4sFROPzX5fdhBu+q0eZ; 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: behave@ietf.org, 'IETF AVT WG' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Submitted. In the meantime, it is available here: http://svn.resiprocate.org/rep/ietf-drafts/dwing/draft-wing-behave-symmetric -rtprtcp-02.html http://svn.resiprocate.org/rep/ietf-drafts/dwing/draft-wing-behave-symmetric -rtprtcp-02.txt Rfcdiff between -02 and -01 is: http://tinyurl.com/33a3d8 -d > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Monday, February 26, 2007 7:10 AM > To: Magnus Westerlund > Cc: behave@ietf.org; IETF AVT WG > Subject: Re: [BEHAVE] [Fwd: Last Call: > draft-wing-behave-symmetric-rtprtcp(Common Local Transmit and > Receive Ports (Symmetric RTP)) toInformational RFC] > > Magnus Westerlund skrev: > > There has been raised a comment that this document should contain a > > normative recommendation on using symmetric ports. However > to make this > > happen the document would need to be a BCP. I am willing to > consider > > this but would like to have AVT and Behave WG participant's view on > > doing this before progressing down that road and updating > the IETF last > > call. So please provide comments by Tuesday 20th of Feb on > this issue. > > > > There has been no objections against making this into a BCP. > > Dan can you please update your draft with the proposed > requirement text. > > 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 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 26 14:33:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLlad-0002Ys-Ve; Mon, 26 Feb 2007 14:32:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLlaX-0002Iz-GK for behave@ietf.org; Mon, 26 Feb 2007 14:32:45 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLlXt-0001Kh-Nf for behave@ietf.org; Mon, 26 Feb 2007 14:30:04 -0500 Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 1015A1CC29; Mon, 26 Feb 2007 11:27:32 -0800 (PST) To: "Dan Wing" Subject: Re: [BEHAVE] WGLC for behave-p2pstate-02 starts now In-reply-to: Your message of "Mon, 26 Feb 2007 11:19:13 PST." <003401c759db$029f9070$e7726b80@amer.cisco.com> X-Mailer: MH-E 7.4.2; nmh 1.2; XEmacs 21.4 (patch 20) Date: Mon, 26 Feb 2007 11:27:31 -0800 From: EKR Message-Id: <20070226192732.1015A1CC29@delta.rtfm.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: 'Behave WG' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Dan Wing wrote: > > > > I think the term "P2P Friendly" is a major marketing mistake and > > > highly likely to ensure vendors don't want to do this. > > > > [suresh] I cannot parse your sentence. I certainly donot > > understand what you are trying to say. Why is the term "P2P > > friendly" a marketing mistake? Even if so, Why should I care > > in this draft? And, What does "highly likely to ensure > > vendors don't want to do this" mean? Please explain. > > Almost immediately after the advent of the first popular peer- > to-peer file sharing networks (Kazza and Gnutella), the term > "peer-to-peer" has implied illicit sharing of copyrighted > content. Thus, "peer-to-peer friendly" implies friendliness > towards the same. > > Unfortunately, the fact that other protocols operate in a > peer-to-peer fashion is lost on most people (for example, > networked games, SIP, Microsoft's NetMeeting, etc.). > > I believe Cullen's concern is that using the unqualified > term "peer-to-peer" brings to mind illicit file sharing, > and nobody wants their company to be associated with illicit > activities. Such an association is always a business risk > and typically an unnecessary business risk. If this is Cullen's concern, I share it. Whatever we would like P2P to mean, as a practical matter it mostly means filesharing applications, so I think it would be appropriate to rewrite the draft to use a different term. Cullen had suggested Behave Compliant, which seems to me to be fairly appropriate. Suresh, can you elaborate on what you don't like about this term. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Feb 26 15:51:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmnq-0004IA-EQ; Mon, 26 Feb 2007 15:50:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmna-0003xj-Qw; Mon, 26 Feb 2007 15:50:18 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLmnL-0005u0-ER; Mon, 26 Feb 2007 15:50:18 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 155D626EE4; Mon, 26 Feb 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HLmnK-0004yu-Js; Mon, 26 Feb 2007 15:50:02 -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: Mon, 26 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: behave@ietf.org Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-nat-behavior-discovery-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : NAT Behavior Discovery Using STUN Author(s) : D. MacDonald, B. Lowekamp Filename : draft-ietf-behave-nat-behavior-discovery-00.txt Pages : 26 Date : 2007-2-26 This specification defines a usage of the Simple Traversal Underneath Network Address Translators (NAT) (STUN) Protocol that allows applications to discover the presence and current behaviour of NATs and firewalls between them and the STUN server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-behavior-discovery-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-nat-behavior-discovery-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-behave-nat-behavior-discovery-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-26112854.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-nat-behavior-discovery-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-nat-behavior-discovery-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-26112854.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 Feb 27 04:29:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLydj-00013n-HP; Tue, 27 Feb 2007 04:28:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLydh-0000yt-V0 for behave@ietf.org; Tue, 27 Feb 2007 04:28:53 -0500 Received: from maildialog.com ([195.159.98.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLydd-0007Fa-G5 for behave@ietf.org; Tue, 27 Feb 2007 04:28:53 -0500 Received: from [82.196.214.14] (helo=[192.168.1.100]) by maildialog.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51-maildialog) id 1HLydX-0005tJ-Fb; Tue, 27 Feb 2007 09:28:43 +0000 Message-ID: <45E3F9C9.9090000@db.org> Date: Tue, 27 Feb 2007 10:28:41 +0100 From: "Alfred E. Heggestad" User-Agent: Icedove 1.5.0.9 (X11/20061220) MIME-Version: 1.0 To: Bruce Lowekamp Subject: Re: [BEHAVE] draft-ietf-behave-nat-behavior-discovery-00 submitted References: <20d2bdfb0702231347u1fab6fbel20d06dc9a78a0a93@mail.gmail.com> In-Reply-To: <20d2bdfb0702231347u1fab6fbel20d06dc9a78a0a93@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Bruce Lowekamp wrote: > Derek and I have submitted draft-ietf-behave-nat-behavior-discovery-00 > to internet-drafts. Until it appears in the repository, I've posted > temporary copies at: > > http://www.sipeerior.com/tmp/draft-ietf-behave-nat-behavior-discovery-00.html > > http://www.sipeerior.com/tmp/draft-ietf-behave-nat-behavior-discovery-00.txt > I would just like to point out that the attribute values defined in section 7 and section 9 differ. Section 7: 0x8026: PADDING 0x8027: CACHE-TIMEOUT Section 9: 0x0026: PADDING 0x8026: CACHE-TIMEOUT The value 0x0026 is in conflict with XOR-INTERNAL-ADDRESS from NAT Control (http://www.employees.org/behave/stun-attributes.html) could I ask that we assign new and unique values, and update the page above? /alfred _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Feb 27 15:07:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM8bf-0007h5-U6; Tue, 27 Feb 2007 15:07:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM8bf-0007cW-6F for behave@ietf.org; Tue, 27 Feb 2007 15:07:27 -0500 Received: from bay0-omc1-s33.bay0.hotmail.com ([65.54.246.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM8bd-0001uc-Pi for behave@ietf.org; Tue, 27 Feb 2007 15:07:27 -0500 Received: from bayc1-pasmtp02.bayc1.hotmail.com ([65.54.191.162]) by bay0-omc1-s33.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 27 Feb 2007 12:07:25 -0800 X-Originating-IP: [216.13.42.68] X-Originating-Email: [eric_d_cooper@sympatico.ca] Received: from ronin ([216.13.42.68]) by bayc1-pasmtp02.bayc1.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 12:07:24 -0800 Message-ID: <057d01c75aaa$e2081870$65500a0a@ronin> From: "Eric Cooper" To: "Dan Wing" , "'Lars Eggert'" References: <08f201c75603$c1cebab0$c2f0200a@amer.cisco.com> Subject: Re: [BEHAVE] NAT Control STUN Usage Date: Tue, 27 Feb 2007 15:04:14 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 27 Feb 2007 20:07:24.0497 (UTC) FILETIME=[E584BC10:01C75AAA] X-Spam-Score: 2.2 (++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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="===============1948787023==" Errors-To: behave-bounces@ietf.org --===============1948787023== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SSB0aGluayB0aGVyZSdzIGEgbG90IG9mIHZhbHVlIGluIHRoaXMgZHJhZnQgc2ltcGx5IGJlY2F1 c2UgaXQgYWxsb3dzIGRpc2NvdmVyeSBvZiBtdWx0aXBsZSBsZXZlbHMgb2YgTkFUcy4gIA0KDQpJ J20gc3BlY2lmaWNhbGx5IGludGVyZXN0ZWQgaW4ga25vd2luZyB0aGUgJ3B1YmxpYycgSVAgYWRk cmVzc2VzIGFuZCBrZWVwLWFsaXZlIHRpbWVzIGFzc29jaWF0ZWQgd2l0aCBlYWNoIE5BVC4gIEkg dGhpbmsgdGhhdCBjb3VsZCBiZSBhY2NvbXBsaXNoZWQgd2l0aG91dCBhdHRlbXB0aW5nIHRvIGNv bnRyb2wgdGhlIGtlZXAtYWxpdmUgdGltZXMgaW4gdGhlIE5BVHMuDQoNClNvLCBpdCBtaWdodCBi ZSBwb3NzaWJsZSB0byBza2lydCBjaGFydGVyIGlzc3VlcyBieSBsaW1pdGluZyB0aGlzIGRyYWZ0 IHRvICdkaXNjb3ZlcnknIGZ1bmN0aW9ucyBhbmQgbm90IGluY2x1ZGluZyAnY29udHJvbCcgZnVu Y3Rpb25zLg0KDQpCZXN0IFJlZ2FyZHMsDQoNCkVyaWMuDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0gDQpGcm9tOiAiRGFuIFdpbmciIDxkd2luZ0BjaXNjby5jb20+DQpUbzogIidMYXJz IEVnZ2VydCciIDxsYXJzLmVnZ2VydEBub2tpYS5jb20+DQpDYzogPGJlaGF2ZUBpZXRmLm9yZz4N ClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjEsIDIwMDcgNTowMCBQTQ0KU3ViamVjdDogUkU6 IFtCRUhBVkVdIE5BVCBDb250cm9sIFNUVU4gVXNhZ2UNCg0KDQo+PiBPbiAyMDA3LTEtMTIsIGF0 IDIwOjA5LCBleHQgRGFuIFdpbmcgd3JvdGU6DQo+PiA+IEF0IHRoZSBTYW4gRGllZ28gbWVldGlu ZyB0aGVyZSB3ZXJlIHBvc2l0aXZlIGNvbW1lbnRzIGFyb3VuZCB0aGlzICANCj4+ID4gYXBwcm9h Y2guDQo+PiA+IElzIHRoZXJlIGludGVyZXN0IGluIG1vdmluZyB0aGlzIHdvcmsgZm9yd2FyZD8N Cj4+IA0KPj4gdGhpcyBkb2N1bWVudCB0YWtlcyBTVFVOIGluIGEgd2hvbGUgbmV3IGRpcmVjdGlv biAobWlkZGxlYm94IA0KPj4gY29udHJvbCkgdGhhdCB3b3VsZCBwcm9iYWJseSByZXF1aXJlIGEg cmVjaGFydGVyLg0KPiANCj4gSSBhc2tlZCBNYWdudXMgdGhhdCBxdWVzdGlvbiBvZmZsaW5lLCBh bmQgaGUgY29uY3VycyBpdCBkb2Vzbid0DQo+IGZpdCB3aXRoaW4gQkVIQVZFJ3MgZXhpc3Rpbmcg Y2hhcnRlci4gIA0KPiANCj4+ID4gICAgQWxzbywgdGhlIGRyYWZ0IHNheXM6DQo+PiA+ICAgIFVu bGlrZSBzb21lIG90aGVyDQo+PiA+ICAgIHRlY2huaXF1ZXMgKGUuZy4sIFVQblAgW1VQblBdLCBN SURDT00gW1JGQzMzMDNdLCBCb25qb3VyICANCj4+ID4gICAgW0JvbmpvdXJdKSwNCj4+ID4gICAg U1RVTiBkb2VzIG5vdCBpbnRlcmFjdCBkaXJlY3RseSB3aXRoIHRoZSBOQVQuICBCZWNhdXNlIA0K Pj4gPiAgICBTVFVOIGRvZXNuJ3QNCj4+ID4gICAgaW50ZXJhY3QgZGlyZWN0bHkgd2l0aCB0aGUg TkFULCBTVFVOIGNhbm5vdCByZXF1ZXN0IGFkZGl0aW9uYWwNCj4+ID4gICAgc2VydmljZXMgZnJv bSB0aGUgTkFUIHN1Y2ggYXMgbG9uZ2VyIGxpZmV0aW1lcyAod2hpY2ggDQo+PiA+ICAgIHdvdWxk IHJlZHVjZSBrZWVwYWxpdmUgbWVzc2FnZXMpLg0KPj4gPg0KPj4gPiAgICBUaGlzIHBhcGVyIGRl c2NyaWJlcyBhIG1lY2hhbmlzbSBmb3IgdGhlIFNUVU4gY2xpZW50IHRvIGludGVyYWN0DQo+PiA+ ICAgIGRpcmVjdGx5IHdpdGggdGhlIE5BVCBhbmQgcmVxdWVzdCBhZGRpdGlvbmFsIHNlcnZpY2Vz LCANCj4+ID4gICAgYnkgdXNpbmcgdGhlDQo+PiA+ICAgIFNUVU4gcHJvdG9jb2wgaXRzZWxmLg0K Pj4gDQo+PiBGb3IgYSBjb252aW5jaW5nIHJlY2hhcnRlcmluZyBhcmd1bWVudCwgaXQnZCBiZSB2 ZXJ5IHVzZWZ1bCB0byBzZWUgYSAgDQo+PiBkaXNjdXNzaW9uIG9uIHdoeSBhZGRpbmcgdGhpcyB0 byBTVFVOIGlzIHNpZ25pZmljYW50bHkgYmV0dGVyIHRoYW4gIA0KPj4gdGhlIG15cmlhZCBvZiBl eGl0aW5nIGFwcHJvYWNoZXMgdG8gY29udHJvbCBtaWRkbGVib3hlcy4gSW4gYWRkaXRpb24gIA0K Pj4gdG8gdGhlIG9uZXMgbWVudGlvbmVkIGluIHRoZSBkcmFmdCwgYXQgbGVhc3QgTlNJUyBhbmQg U0lNQ08gDQo+PiBhbHNvIGV4aXN0Lg0KPiANCj4gLTAxIGFkZGVkIGEgbGl0dGxlIG1vcmUgaW5m b3JtYXRpb24gc2hvd2luZyBhZHZhbnRhZ2VzIG9mIHRoZSBOQVQNCj4gQ29udHJvbCBTVFVOIFVz YWdlLiAgV2UgY2FuIGFkZCBhIHBvaW50LWJ5LXBvaW50IGNvbXBhcmlzb24gb2YgdGhpcw0KPiBh cHByb2FjaCB2ZXJzdXMgTlNJUywgU0lNQ08gKGFuIGltcGxlbWVudGF0aW9uIG9mIE1JRENPTSks IFVQblAsDQo+IGFuZCBCb25qb3VyLCBhbmQgYXNrIHRoZSBjb21tdW5pdHkgYWdhaW4gaWYgdGhl cmUgc2VlbXMgdG8gYmUgDQo+IHN1ZmZpY2llbnQgbWVyaXQgdG8gdGhpcyBhcHByb2FjaCB2ZXJz dXMgdGhlIG90aGVyIHByb3RvY29scyBmb3INCj4gTkFUIHRyYXZlcnNhbCBhbmQgTkFUIGNvbnRy b2wuDQo+IA0KPiAtZA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gQmVoYXZlIG1haWxpbmcgbGlzdA0KPiBCZWhhdmVAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmVoYXZlDQo+ --===============1948787023== 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 --===============1948787023==-- From behave-bounces@ietf.org Tue Feb 27 17:00:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMAMU-0005Jb-Az; Tue, 27 Feb 2007 16:59:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMAMS-0005JW-Vf for behave@ietf.org; Tue, 27 Feb 2007 16:59:52 -0500 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HMAMQ-0007KD-Dz for behave@ietf.org; Tue, 27 Feb 2007 16:59:52 -0500 Received: from Quinthar ([67.169.180.240]) by quinthar.com for ; Tue, 27 Feb 2007 13:59:37 -0800 From: "David Barrett" To: "'Eric Cooper'" , "'Dan Wing'" , "'Lars Eggert'" Subject: RE: [BEHAVE] NAT Control STUN Usage Date: Tue, 27 Feb 2007 13:59:32 -0800 Message-ID: <0e0801c75aba$9089b7f0$5600a8c0@Quinthar> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acdaqwv3f27zRXwwRjGO0Ry1ubxXzQADxRFQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <057d01c75aaa$e2081870$65500a0a@ronin> X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I agree this would be great. I just think it's not what BEHAVE is doing. BEHAVE is (largely) just specifying what the default configuration should be for NATs as they come "out of the box". This is much different than mandating all NAT vendors build in support for a new control interface. Despite my massive reservations with UPnP, that seems like a much more appropriate place to add control functionality (because it already has it), rather than reinventing an incompatible subset of UPnP under a different name. -david > -----Original Message----- > From: Eric Cooper [mailto:eric_d_cooper@sympatico.ca] > Sent: Tuesday, February 27, 2007 12:04 PM > To: Dan Wing; 'Lars Eggert' > Cc: behave@ietf.org > Subject: Re: [BEHAVE] NAT Control STUN Usage > > I think there's a lot of value in this draft simply because it allows > discovery of multiple levels of NATs. > > I'm specifically interested in knowing the 'public' IP addresses and keep- > alive times associated with each NAT. I think that could be accomplished > without attempting to control the keep-alive times in the NATs. > > So, it might be possible to skirt charter issues by limiting this draft to > 'discovery' functions and not including 'control' functions. > > Best Regards, > > Eric. > > ----- Original Message ----- > From: "Dan Wing" > To: "'Lars Eggert'" > Cc: > Sent: Wednesday, February 21, 2007 5:00 PM > Subject: RE: [BEHAVE] NAT Control STUN Usage > > > >> On 2007-1-12, at 20:09, ext Dan Wing wrote: > >> > At the San Diego meeting there were positive comments around this > >> > approach. > >> > Is there interest in moving this work forward? > >> > >> this document takes STUN in a whole new direction (middlebox > >> control) that would probably require a recharter. > > > > I asked Magnus that question offline, and he concurs it doesn't > > fit within BEHAVE's existing charter. > > > >> > Also, the draft says: > >> > Unlike some other > >> > techniques (e.g., UPnP [UPnP], MIDCOM [RFC3303], Bonjour > >> > [Bonjour]), > >> > STUN does not interact directly with the NAT. Because > >> > STUN doesn't > >> > interact directly with the NAT, STUN cannot request additional > >> > services from the NAT such as longer lifetimes (which > >> > would reduce keepalive messages). > >> > > >> > This paper describes a mechanism for the STUN client to interact > >> > directly with the NAT and request additional services, > >> > by using the > >> > STUN protocol itself. > >> > >> For a convincing rechartering argument, it'd be very useful to see a > >> discussion on why adding this to STUN is significantly better than > >> the myriad of exiting approaches to control middleboxes. In addition > >> to the ones mentioned in the draft, at least NSIS and SIMCO > >> also exist. > > > > -01 added a little more information showing advantages of the NAT > > Control STUN Usage. We can add a point-by-point comparison of this > > approach versus NSIS, SIMCO (an implementation of MIDCOM), UPnP, > > and Bonjour, and ask the community again if there seems to be > > sufficient merit to this approach versus the other protocols for > > NAT traversal and NAT control. > > > > -d > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www1.ietf.org/mailman/listinfo/behave > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 28 10:47:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMR0k-0006Ya-58; Wed, 28 Feb 2007 10:46:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMR0i-0006XI-7M for behave@ietf.org; Wed, 28 Feb 2007 10:46:32 -0500 Received: from web33306.mail.mud.yahoo.com ([68.142.206.121]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HMR0g-00062E-ON for behave@ietf.org; Wed, 28 Feb 2007 10:46:32 -0500 Received: (qmail 52204 invoked by uid 60001); 28 Feb 2007 15:46:30 -0000 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=km2qrKqJq+h+k1wEEFjH6oPNijL8Qw5e9LcUN1xwUt/F6f8s91CCyodEsuCO4MrIr9r7juuBVAKGxrCSZmrtEFzIJfqOn0MiIWtOBz5LnhuP6UIXoStjn86bzR1cQwTe/UtbB9BYvH43FhWXZOB3TfyjF0KL1ThcEzebZCZcJ8I=; X-YMail-OSG: QHogJ28VM1lYrGk7pIvNq.SQYDupP4B8i6ejeyYzjdM1B2JCRaeGATQCFofC42E.iSkST13NTE9659aT1yQKBqobPS5xpHhmIntucWBDPGSJTQnGN.mrKUZj_DCNYPqh1BcBp1xxqkk- Received: from [69.236.102.196] by web33306.mail.mud.yahoo.com via HTTP; Wed, 28 Feb 2007 07:46:30 PST Date: Wed, 28 Feb 2007 07:46:30 -0800 (PST) From: Pyda Srisuresh Subject: RE: [BEHAVE] WGLC for behave-p2pstate-02 starts now To: Dan Wing , 'Cullen Jennings' , 'Behave WG' In-Reply-To: <003401c759db$029f9070$e7726b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <102306.51912.qm@web33306.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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 --- Dan Wing wrote: > > > > I think the term "P2P Friendly" is a major marketing mistake and > > > highly likely to ensure vendors don't want to do this. > > > > [suresh] I cannot parse your sentence. I certainly donot > > understand what you are trying to say. Why is the term "P2P > > friendly" a marketing mistake? Even if so, Why should I care > > in this draft? And, What does "highly likely to ensure > > vendors don't want to do this" mean? Please explain. > > Almost immediately after the advent of the first popular peer- > to-peer file sharing networks (Kazza and Gnutella), the term > "peer-to-peer" has implied illicit sharing of copyrighted > content. Thus, "peer-to-peer friendly" implies friendliness > towards the same. > > Unfortunately, the fact that other protocols operate in a > peer-to-peer fashion is lost on most people (for example, > networked games, SIP, Microsoft's NetMeeting, etc.). > > I believe Cullen's concern is that using the unqualified > term "peer-to-peer" brings to mind illicit file sharing, > and nobody wants their company to be associated with illicit > activities. Such an association is always a business risk > and typically an unnecessary business risk. > [suresh] Dan - Thank you for the clarification. Now, I understand the context better. The term "Peer-to-peer" has been used widely throughout in BEHAVE drafts. There were 7 references to the term in the recently publiched RFC 4787 alone. "Peer-to-peer" applications have been the focus on this mailing list when discussing BEHAVE compliance from day one. Besides, The p2p-state draft qualifies the term "peer-to-peer" (or P2P, for short) with the following defintion, so there is no confusion on what the term means. A P2P application is an application that uses the same endpoint to initiate outgoing sessions to peering hosts as well as accept incoming sessions from peering hosts. So, given that the draft is making a qualified use of the term and the term is also used in other BEHAVE RFCs and drafts, I believe, is is appropriate to use the term in the draft. > Our milestone for this item is: > > Mar 2007 Submit informational that discusses current > NAT traversal techniques used by applications > [suresh] Dan - The milestone was created to permit adapting the p2p-state draft as WG item. So, I did not pay attention to the exact wording of the milestone. The draft has throuhgout been about the traversal of peer-to-peer applications. > So, perhaps downplaying the use of the term "peer to peer" > is what Cullen was referring to. Or perhaps eliminating > it entirely. I'm not entirely sure. > [suresh] Perhaps, Cullen's concern is not much to do with the term "Peer-to-peer" per se. But, more to do with the term "P2P-friendly NAT". I have two terms defined in the document - "P2P friendly NAT" and "NAT friendly P2P Application". This document is about the state of P2P application traversal through NATs. I cannot say that all P2P friendly NAT devices out there are BEHAVE compliant. There are many that are not. I needed a generic term that describes the state of NATs out there without tieing it down to BEHAVE documents. I could rename this as "End-to-end friendly NAT", if that would work. Note, this is different from "Behave Compliant NAT". If you like, I could add a line that BEHAVE complaint NAT devices are good examples of "P2P friendly NAT" devices. I already state that NAT devices employing Address-Independent Mapping are examples of P2P-friendly NAT devices in the document. As for the term "NAT friendly P2P application", Once again, there are several types of P2P applications out there that are NAT friendly. I picked a term that would not tie it down to BEHAVE complaince. Would the above work for you? Thanks. regards, suresh > -d > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 28 11:44:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMRup-0006za-CI; Wed, 28 Feb 2007 11:44:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMRuo-0006zU-65 for behave@ietf.org; Wed, 28 Feb 2007 11:44:30 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMRul-0003s6-Tk for behave@ietf.org; Wed, 28 Feb 2007 11:44:30 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-3.cisco.com with ESMTP; 28 Feb 2007 08:44:28 -0800 X-IronPort-AV: i="4.14,231,1170662400"; d="scan'208"; a="467595689:sNHT42759052" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l1SGiRcL009236; Wed, 28 Feb 2007 08:44:27 -0800 Received: from [10.150.154.224] (sjc-vpn-hwcore-153.cisco.com [10.21.152.153]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1SGiQnF010180; Wed, 28 Feb 2007 08:44:27 -0800 (PST) In-Reply-To: <102306.51912.qm@web33306.mail.mud.yahoo.com> References: <102306.51912.qm@web33306.mail.mud.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] WGLC for behave-p2pstate-02 starts now Date: Wed, 28 Feb 2007 08:44:19 -0800 To: Pyda Srisuresh X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=474; t=1172681067; x=1173545067; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20WGLC=20for=20behave-p2pstate-02=20starts=2 0now |Sender:=20; bh=we+D55jBCOgIkTdCoQexMQRM7JDsBNOicJbQrkIl6ss=; b=Q/8GtLJZJmpua4wYPPs3zawCilm8s6tfQVJSVybxx6AGjF/bI+WXyb4fVlnNbtThKSfLZodX 6y81rtA4PtOiQDcHLKDWmei3hwobG+YI1HR9ep5SGnVO2AeFu1u3wyGX; Authentication-Results: sj-dkim-6; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: 'Behave WG' , Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Feb 28, 2007, at 7:46 AM, Pyda Srisuresh wrote: > Note, this is different from "Behave Compliant NAT". If you like, I > could add a line that BEHAVE complaint NAT devices are good > examples of "P2P > friendly NAT" devices. Help me understand the difference between the two? If this is an effort to define P2P Friendly NATs to be the things that the WG disagreed with you about when doing the existing drafts, I doubt that represents WG consensus. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Feb 28 18:52:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMYaJ-0003Pr-Lh; Wed, 28 Feb 2007 18:51:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMYZi-0002DY-3F; Wed, 28 Feb 2007 18:51:11 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HMYZd-0008Kk-4p; Wed, 28 Feb 2007 18:51:10 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id EDC612AD3C; Wed, 28 Feb 2007 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HMYYc-00044D-Mn; Wed, 28 Feb 2007 18:50:02 -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: Wed, 28 Feb 2007 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: behave@ietf.org Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-tcp-05.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : NAT Behavioral Requirements for TCP Author(s) : S. Guha, et al. Filename : draft-ietf-behave-tcp-05.txt Pages : 20 Date : 2007-2-28 This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and on-line games, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-tcp-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-tcp-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-behave-tcp-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-28155429.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-tcp-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-tcp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-28155429.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--