From behave-bounces@ietf.org Sun Dec 02 14:56:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyuux-00057g-Ry; Sun, 02 Dec 2007 14:55:55 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Iyuuw-00057V-SR for behave-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 14:55:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyuuw-00057N-IK for behave@ietf.org; Sun, 02 Dec 2007 14:55:54 -0500 Received: from server.implementers.org ([69.55.225.91]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iyuuw-0006Uc-8K for behave@ietf.org; Sun, 02 Dec 2007 14:55:54 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id 3F655D9D403A; Sun, 2 Dec 2007 11:55:53 -0800 (PST) Received: from [192.168.1.3] (c-24-4-253-5.hsd1.ca.comcast.net [24.4.253.5]) by server.implementers.org (Postfix) with ESMTP id 97831D9D4038 for ; Sun, 2 Dec 2007 11:55:50 -0800 (PST) Message-ID: <47530DC6.6020000@acm.org> Date: Sun, 02 Dec 2007 11:55:50 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071008) MIME-Version: 1.0 To: behave@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [BEHAVE] TURN servers available for testing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marc Petit-Huguenin 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 accelerate the development of TURN clients compliant with draft-ietf-behave-05, 8x8 Inc. (provider of the Packet8 service) is sponsoring the deployment of TURN servers that can be freely used for testing. If you are interested in testing your TURN client with our servers, please send me an email at marc@8x8.com. I'll reply in the next days with the instructions to setup an account. Please do not CC the mailing-list when responding to this email. Thanks. -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 03 00:10:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz3ZH-0004Yh-Lq; Mon, 03 Dec 2007 00:10:07 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Iz3ZE-0004Bv-4z for behave-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 00:10:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz3ZD-0004A8-NB for behave@ietf.org; Mon, 03 Dec 2007 00:10:03 -0500 Received: from dhcp-11b6.ietf70.org ([130.129.17.182] helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iz3ZD-00025O-11 for behave@ietf.org; Mon, 03 Dec 2007 00:10:03 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id F1C4933C47 for ; Sun, 2 Dec 2007 21:04:44 -0800 (PST) Date: Sun, 02 Dec 2007 21:04:44 -0800 From: Eric Rescorla To: behave@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071203050444.F1C4933C47@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Subject: [BEHAVE] Comments on draft-ietf-behave-turn-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org $Id: draft-ietf-behave-turn-05-rev.txt,v 1.3 2007/12/03 05:00:28 ekr Exp $ General comments below. PORT-DEPENDENT FILTERING As I understand the functionality provided by this draft, it's acting like an address-restricted NAT. I.e., if I allocate address X:x and then send a packet to Y:y via this allocation, this creates a permission for Y:*, so that a packet from Y:z gets forwarded to the client. Do I have that right? This is different from what I understand to be the sort of address/port filtering behavior typically used by address-dependent filtered NATs and firewalls, namely that the pinhole opened is only X:x-Y:y, not X:x-Y:*. This is pretty clearly intended as a security feature (note that I'm not claiming it actually provides security) and bypassing it unnecessarily [0] seems like a move which is going to disincentivize TURN deployment. Note that you get this behavior *even if* you have a good NAT and ICE eventually settles on a non-relayed path. I'm assuming that the intent here is to allow TURN clients to easily talk to nodes behind NATs with address-dependent port mapping. If so, I think this is probably misguided. The purpose of TURN is to fix your own broken NAT, not other people's broken NATs. One could certainly argue that fixing other people's NATs is a positive side effect, but I don't think it is, at least in part since it totally screws up the incentive model: we want to reward people with good NATs, not force them to use TURN anyway. Note that this also means that you can't get early media if ICE is not being used, but of course that would also be true if you had a NAT with port-dependent filtering, so I don't think that's a disaster. So, I think it would be best to restrict the permissions being opened here to just those address/port which the client specifically addresses. COMPLEXITY If you abandon the notion that you can get datagrams from ports that you haven't explicitly specified, then it's possible to radically simplify the protocol by discarding both Send Indication and Data Indication. The basic protocol only has three components: - Allocate -- as described in S 6 - Bind -- open a permission for a specific 5-tuple - Data framing -- as described in S 4 So, the way this would work is as follows: Client Server Peer ------ ------ ---- ALLOCATE -> <- OK(addr = X:x) BIND(Channel=1, Remote=Y:y) -> <- OK <- Message1 (Y:y -> X:x) <- DATA(Channel=1, Message1) DATA(Channel=1,Message2) -> Message2 -> In the terminology of the current draft, BIND does two things: 1. Opens up a permission for X:x <-> Y:y 2. Assigns a channel # to the permission We can dispense with Data Indication because no packet can be sent from the Server to the Client until a permission is opened and the permission and the channel assignment come together. We can dispense with Send Indication because it's preceded by a channel assignment using BIND. The Server can simply discard any framed messages it receives prior to the receipt of the BIND. Now, one could argue that if you're using UDP from the Client to the TURN Server, then the BIND could get lost in which case the data will be dropped and that this is bad (note that this can't happen with TCP). I actually think this is just fine--in order for protocols to work well, the path from the Client to the TURN Server has to be pretty reliable, and since the Peer can't respond anyway until the BIND is received, this probably isn't a big deal. However, if this is really a concern you could keep Send Indication around, but without the channel establishment side effects. [0] Yes, I appreciate that the general function of TURN is to bypass middlebox policies, but that seems like something to minimize. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 03 13:40:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzGDR-0006xR-S2; Mon, 03 Dec 2007 13:40:25 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IzGDQ-0006x3-FM for behave-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 13:40:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzGDQ-0006wt-5n for behave@ietf.org; Mon, 03 Dec 2007 13:40:24 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzGDO-0000k9-Qq for behave@ietf.org; Mon, 03 Dec 2007 13:40:24 -0500 Received: from dhcp-17f5.ietf70.org ([130.129.23.245]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IzGDN-0000tc-2D; Mon, 03 Dec 2007 13:40:21 -0500 In-Reply-To: <04aa01c82c6e$746e4eb0$c4f0200a@cisco.com> References: <04aa01c82c6e$746e4eb0$c4f0200a@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <39B65A86-DB33-4FBA-BC2B-CC4C81021ED2@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] adopt STUN test vectors? Date: Mon, 3 Dec 2007 10:40:20 -0800 To: Dan Wing X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - dhcp-17f5.ietf70.org [130.129.23.245] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 support the idea of published STUN test vectors, either as a separate document, or as an appendix to 3489bis. - Philip On 21-Nov-07, at 10:43 , Dan Wing wrote: > We don't have a milestone for STUN test vectors and it probably > falls a bit > outside of the as-written charter, but before we try to change > those: is > there interest in adopting Remi's "Test vectors for RFC3489bis", > draft-denis-behave-rfc3489bis-test-vectors-02 as a working group > item for > BEHAVE? It's 6 pages, please skim it: > > http://www.ietf.org/internet-drafts/draft-denis-behave-rfc3489bis- > test-vectors > -02.txt > > Before adopting it, I will need to get approval from our ADs to add > another > milestone and adjust the charter accordingly. But I wanted to poll > first to > see if we should try doing that. > > Thanks, > -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 Mon Dec 03 16:33:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzIuW-00013S-Sz; Mon, 03 Dec 2007 16:33:04 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IzIuV-00013M-Kr for behave-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 16:33:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzIuV-00013E-BJ for behave@ietf.org; Mon, 03 Dec 2007 16:33:03 -0500 Received: from server.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzIuU-0005p8-FN for behave@ietf.org; Mon, 03 Dec 2007 16:33:03 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id B298FD9D403C; Mon, 3 Dec 2007 13:33:01 -0800 (PST) Received: from [192.168.1.3] (c-24-4-253-5.hsd1.ca.comcast.net [24.4.253.5]) by server.implementers.org (Postfix) with ESMTP id 4C8A3D9D403A; Mon, 3 Dec 2007 13:32:59 -0800 (PST) Message-ID: <4754760A.40000@acm.org> Date: Mon, 03 Dec 2007 13:32:58 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071008) MIME-Version: 1.0 To: Eric Rescorla Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-05 References: <20071203050444.F1C4933C47@delta.rtfm.com> In-Reply-To: <20071203050444.F1C4933C47@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi Eric, Eric Rescorla wrote: > $Id: draft-ietf-behave-turn-05-rev.txt,v 1.3 2007/12/03 05:00:28 ekr Exp $ > > General comments below. > > PORT-DEPENDENT FILTERING > As I understand the functionality provided by this draft, it's acting > like an address-restricted NAT. I.e., if I allocate address X:x and > then send a packet to Y:y via this allocation, this creates a > permission for Y:*, so that a packet from Y:z gets forwarded to the > client. Do I have that right? > > This is different from what I understand to be the sort of > address/port filtering behavior typically used by address-dependent > filtered NATs and firewalls, namely that the pinhole opened is only > X:x-Y:y, not X:x-Y:*. This is pretty clearly intended as a security > feature (note that I'm not claiming it actually provides security) and > bypassing it unnecessarily [0] seems like a move which is going to > disincentivize TURN deployment. Note that you get this behavior *even > if* you have a good NAT and ICE eventually settles on a non-relayed > path. > > I'm assuming that the intent here is to allow TURN clients to easily > talk to nodes behind NATs with address-dependent port mapping. If so, > I think this is probably misguided. The purpose of TURN is to fix your > own broken NAT, not other people's broken NATs. One could certainly > argue that fixing other people's NATs is a positive side effect, but I > don't think it is, at least in part since it totally screws up the > incentive model: we want to reward people with good NATs, not force > them to use TURN anyway. > > Note that this also means that you can't get early media if ICE > is not being used, but of course that would also be true if you > had a NAT with port-dependent filtering, so I don't think > that's a disaster. > > So, I think it would be best to restrict the permissions being opened > here to just those address/port which the client specifically > addresses. I think that you are assuming that TURN is used only with ICE, i.e. for the purpose of carrying RTP streams. But the first section of TURN-05 states that "TURN is designed to be a general-purpose relay mechanism for NAT traversal." One of my test client for TURN-05 is a TFTP client, because TFTP does not work behind a Port Dependent Filtering NAT. If the permissions are restricted to address/port, then a TURN-ified TFTP client will no longer work. In fact I would advocate the exact opposite - having a configuration option in the Allocate to choose if permissions are disabled, address only or address/port. > > > COMPLEXITY > If you abandon the notion that you can get datagrams from ports > that you haven't explicitly specified, then it's possible to > radically simplify the protocol by discarding both Send Indication > and Data Indication. The basic protocol only has three components: > > - Allocate -- as described in S 6 > - Bind -- open a permission for a specific 5-tuple > - Data framing -- as described in S 4 > > So, the way this would work is as follows: > > Client Server Peer > ------ ------ ---- > ALLOCATE -> > <- OK(addr = X:x) > > BIND(Channel=1, Remote=Y:y) -> > <- OK > > <- Message1 (Y:y -> X:x) > <- DATA(Channel=1, Message1) > > DATA(Channel=1,Message2) -> > Message2 -> > > In the terminology of the current draft, BIND does two things: > > 1. Opens up a permission for X:x <-> Y:y > 2. Assigns a channel # to the permission > > We can dispense with Data Indication because no packet can be sent > from the Server to the Client until a permission is opened and the > permission and the channel assignment come together. > > We can dispense with Send Indication because it's preceded by a > channel assignment using BIND. The Server can simply discard any > framed messages it receives prior to the receipt of the BIND. Now, one > could argue that if you're using UDP from the Client to the TURN > Server, then the BIND could get lost in which case the data will be > dropped and that this is bad (note that this can't happen with TCP). I > actually think this is just fine--in order for protocols to work well, > the path from the Client to the TURN Server has to be pretty reliable, > and since the Peer can't respond anyway until the BIND is received, > this probably isn't a big deal. However, if this is really a concern > you could keep Send Indication around, but without the channel > establishment side effects. > > > [0] Yes, I appreciate that the general function of TURN is to bypass > middlebox policies, but that seems like something to minimize. > > -Ekr -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 03 17:00:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJL2-0006cw-Vq; Mon, 03 Dec 2007 17:00:28 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IzJL1-0006be-7W for behave-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 17:00:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJL0-0006bV-Rj for behave@ietf.org; Mon, 03 Dec 2007 17:00:26 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzJL0-0000mD-4U for behave@ietf.org; Mon, 03 Dec 2007 17:00:26 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lB3M0HZu030956; Mon, 3 Dec 2007 16:00:32 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 23:59:46 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 23:59:45 +0200 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] Comments on draft-ietf-behave-turn-05 Date: Mon, 3 Dec 2007 23:59:43 +0200 Message-ID: <01F9057F4EC6BA4B86A05AAE8D472D2804CB2E1F@esebe105.NOE.Nokia.com> In-Reply-To: <4754760A.40000@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Comments on draft-ietf-behave-turn-05 Thread-Index: Acg19DHZmenQ9ZwxRXy9LkrMIUe9iwAAbmWw References: <20071203050444.F1C4933C47@delta.rtfm.com> <4754760A.40000@acm.org> From: To: , X-OriginalArrivalTime: 03 Dec 2007 21:59:45.0598 (UTC) FILETIME=[D0C75DE0:01C835F7] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 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'll second Marc's proposal. Hopefully we can agree on this change in tomorrow's session. Of course, now there remains the second problem with TURN which is probably a bit harder solve. I.e. how to make TURN to support e2e TLS/DTLS security association between TURN client and peer.=20 /Mikael=20 >-----Original Message----- >From: ext Marc Petit-Huguenin [mailto:petithug@acm.org]=20 >Sent: 03.12.2007 23:33 >To: Eric Rescorla >Cc: behave@ietf.org >Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-05 > >Hi Eric, > >Eric Rescorla wrote: >> $Id: draft-ietf-behave-turn-05-rev.txt,v 1.3 2007/12/03 05:00:28 ekr=20 >> Exp $ >>=20 >> General comments below. >>=20 >> PORT-DEPENDENT FILTERING >> As I understand the functionality provided by this draft,=20 >it's acting=20 >> like an address-restricted NAT. I.e., if I allocate address X:x and=20 >> then send a packet to Y:y via this allocation, this creates a=20 >> permission for Y:*, so that a packet from Y:z gets forwarded to the=20 >> client. Do I have that right? >>=20 >> This is different from what I understand to be the sort of=20 >> address/port filtering behavior typically used by address-dependent=20 >> filtered NATs and firewalls, namely that the pinhole opened is only=20 >> X:x-Y:y, not X:x-Y:*. This is pretty clearly intended as a security=20 >> feature (note that I'm not claiming it actually provides=20 >security) and=20 >> bypassing it unnecessarily [0] seems like a move which is going to=20 >> disincentivize TURN deployment. Note that you get this behavior *even >> if* you have a good NAT and ICE eventually settles on a non-relayed=20 >> path. >>=20 >> I'm assuming that the intent here is to allow TURN clients to easily=20 >> talk to nodes behind NATs with address-dependent port=20 >mapping. If so,=20 >> I think this is probably misguided. The purpose of TURN is=20 >to fix your=20 >> own broken NAT, not other people's broken NATs. One could certainly=20 >> argue that fixing other people's NATs is a positive side=20 >effect, but I=20 >> don't think it is, at least in part since it totally screws up the=20 >> incentive model: we want to reward people with good NATs, not force=20 >> them to use TURN anyway. >>=20 >> Note that this also means that you can't get early media if=20 >ICE is not=20 >> being used, but of course that would also be true if you had a NAT=20 >> with port-dependent filtering, so I don't think that's a disaster. >>=20 >> So, I think it would be best to restrict the permissions=20 >being opened=20 >> here to just those address/port which the client specifically=20 >> addresses. > >I think that you are assuming that TURN is used only with ICE,=20 >i.e. for the purpose of carrying RTP streams. But the first=20 >section of TURN-05 states that "TURN is designed to be a=20 >general-purpose relay mechanism for NAT traversal." > >One of my test client for TURN-05 is a TFTP client, because=20 >TFTP does not work behind a Port Dependent Filtering NAT. If=20 >the permissions are restricted to address/port, then a=20 >TURN-ified TFTP client will no longer work. > >In fact I would advocate the exact opposite - having a=20 >configuration option in the Allocate to choose if permissions=20 >are disabled, address only or address/port. > >>=20 >>=20 >> COMPLEXITY >> If you abandon the notion that you can get datagrams from ports that=20 >> you haven't explicitly specified, then it's possible to radically=20 >> simplify the protocol by discarding both Send Indication and Data=20 >> Indication. The basic protocol only has three components: >>=20 >> - Allocate -- as described in S 6 >> - Bind -- open a permission for a specific 5-tuple >> - Data framing -- as described in S 4 >>=20 >> So, the way this would work is as follows: >>=20 >> Client Server Peer >> ------ ------ ---- >> ALLOCATE -> >> <- OK(addr =3D X:x) >>=20 >> BIND(Channel=3D1, Remote=3DY:y) -> >> <- OK =20 >>=20 >> <- Message1 (Y:y -> X:x) >> <- DATA(Channel=3D1, Message1) >>=20 >> DATA(Channel=3D1,Message2) -> >> Message2 -> >>=20 >> In the terminology of the current draft, BIND does two things: >>=20 >> 1. Opens up a permission for X:x <-> Y:y 2. Assigns a=20 >channel # to the=20 >> permission >>=20 >> We can dispense with Data Indication because no packet can be sent=20 >> from the Server to the Client until a permission is opened and the=20 >> permission and the channel assignment come together. >>=20 >> We can dispense with Send Indication because it's preceded by a=20 >> channel assignment using BIND. The Server can simply discard any=20 >> framed messages it receives prior to the receipt of the=20 >BIND. Now, one=20 >> could argue that if you're using UDP from the Client to the TURN=20 >> Server, then the BIND could get lost in which case the data will be=20 >> dropped and that this is bad (note that this can't happen=20 >with TCP). I=20 >> actually think this is just fine--in order for protocols to=20 >work well,=20 >> the path from the Client to the TURN Server has to be pretty=20 >reliable,=20 >> and since the Peer can't respond anyway until the BIND is received,=20 >> this probably isn't a big deal. However, if this is really a concern=20 >> you could keep Send Indication around, but without the channel=20 >> establishment side effects. >>=20 >> =20 >> [0] Yes, I appreciate that the general function of TURN is to bypass=20 >> middlebox policies, but that seems like something to minimize. >>=20 >> -Ekr > >--=20 >Marc Petit-Huguenin [ ] >Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] >Work: marc@8x8.com [ ] >[ ] > > >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www1.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 03 17:08:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJSe-00046V-6U; Mon, 03 Dec 2007 17:08:20 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IzJSd-00046N-6T for behave-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 17:08:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJSc-00046C-SZ for behave@ietf.org; Mon, 03 Dec 2007 17:08:18 -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 1IzJSb-0007Er-8x for behave@ietf.org; Mon, 03 Dec 2007 17:08:18 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lB3M7nmG032260 for ; Tue, 4 Dec 2007 00:08:15 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 00:07:56 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 00:07:56 +0200 Received: from essapo-nirac253122.europe.nokia.com ([10.162.253.122]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 00:07:56 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-05 Date: Tue, 4 Dec 2007 00:07:53 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <20071203050444.F1C4933C47@delta.rtfm.com> <4754760A.40000@acm.org> <01F9057F4EC6BA4B86A05AAE8D472D2804CB2E1F@esebe105.NOE.Nokia.com> In-Reply-To: <01F9057F4EC6BA4B86A05AAE8D472D2804CB2E1F@esebe105.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200712040007.53727.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 03 Dec 2007 22:07:56.0739 (UTC) FILETIME=[F5858930:01C835F8] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 03 December 2007 23:59:43 ext behave-bounces@ietf.org, vous avez= =20 =E9crit=A0: > I'll second Marc's proposal. Hopefully we can agree on this change in > tomorrow's session. > > Of course, now there remains the second problem with TURN which is > probably a bit harder solve. I.e. how to make TURN to support e2e > TLS/DTLS security association between TURN client and peer. There is no such issue. TURN is application-layer protocol-agnostic; you ca= n=20 run TLS on top of a TURN-relayed TCP session, as you can run DTLS on top of= a=20 TURN-relayed UDP session. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 03 17:09:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJTz-0006UG-98; Mon, 03 Dec 2007 17:09:43 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IzJTy-0006Ow-8f for behave-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 17:09:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJTx-0006LX-QJ for behave@ietf.org; Mon, 03 Dec 2007 17:09:41 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzJTw-00018C-UC for behave@ietf.org; Mon, 03 Dec 2007 17:09:41 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 03 Dec 2007 14:09:40 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB3M9eOq013550; Mon, 3 Dec 2007 14:09:40 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lB3M9e1h026016; Mon, 3 Dec 2007 22:09:40 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 14:09:40 -0800 Received: from [10.21.92.116] ([10.21.92.116]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 14:09:40 -0800 Message-ID: <47547EC8.2010405@cisco.com> Date: Mon, 03 Dec 2007 17:10:16 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Eric Rescorla Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-05 References: <20071203050444.F1C4933C47@delta.rtfm.com> In-Reply-To: <20071203050444.F1C4933C47@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Dec 2007 22:09:40.0123 (UTC) FILETIME=[3324AEB0:01C835F9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5859; t=1196719780; x=1197583780; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20Comments=20on=20draft-ietf-behave-turn-05 |Sender:=20; bh=OWlUxKFb4077tI2aP8dD8ZKCuSLO/pAYuz46SKyLW5g=; b=NLQ912oldL6ugTwjcNO9MG3VR9Zj6uXth2+NMLTn8AWWWliC84EdywInYt9zDvoEAyPeKX7L HRvC+k9zvdKZTR3PfZZdWlvxc8Zhk/6UOQhLD2+KJ5GymYdlGsflFq4j; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 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 Eric, Interesting suggestion. I agree that what you propose would simplify the draft further, which is a good thing. But I disagree with your assessment that this behavior is odd. RFC 4787 on NAT UDP behavior requirements says: REQ-8: If application transparency is most important, it is RECOMMENDED that a NAT have an "Endpoint-Independent Filtering" behavior. If a more stringent filtering behavior is most important, it is RECOMMENDED that a NAT have an "Address-Dependent Filtering" behavior. AFAIK, this group found no additional security benefits from address and port dependent filtering. You are correct in your assessment that the current behavior is requied for TURN to work without TWO relays when the other side is behind address-depenent. This isn't a corner case; I think we expect this to be a common configuration. It also allows a single TURN server to be used when the other side is behind an address or address-and-port dependent mapping NAT, but its a residential nat with a single IP. This is a good case to support. So, I am opposed to making this change in TURN. -Jonathan R. Eric Rescorla wrote: > $Id: draft-ietf-behave-turn-05-rev.txt,v 1.3 2007/12/03 05:00:28 ekr Exp $ > > General comments below. > > PORT-DEPENDENT FILTERING > As I understand the functionality provided by this draft, it's acting > like an address-restricted NAT. I.e., if I allocate address X:x and > then send a packet to Y:y via this allocation, this creates a > permission for Y:*, so that a packet from Y:z gets forwarded to the > client. Do I have that right? > > This is different from what I understand to be the sort of > address/port filtering behavior typically used by address-dependent > filtered NATs and firewalls, namely that the pinhole opened is only > X:x-Y:y, not X:x-Y:*. This is pretty clearly intended as a security > feature (note that I'm not claiming it actually provides security) and > bypassing it unnecessarily [0] seems like a move which is going to > disincentivize TURN deployment. Note that you get this behavior *even > if* you have a good NAT and ICE eventually settles on a non-relayed > path. > > I'm assuming that the intent here is to allow TURN clients to easily > talk to nodes behind NATs with address-dependent port mapping. If so, > I think this is probably misguided. The purpose of TURN is to fix your > own broken NAT, not other people's broken NATs. One could certainly > argue that fixing other people's NATs is a positive side effect, but I > don't think it is, at least in part since it totally screws up the > incentive model: we want to reward people with good NATs, not force > them to use TURN anyway. > > Note that this also means that you can't get early media if ICE > is not being used, but of course that would also be true if you > had a NAT with port-dependent filtering, so I don't think > that's a disaster. > > So, I think it would be best to restrict the permissions being opened > here to just those address/port which the client specifically > addresses. > > > COMPLEXITY > If you abandon the notion that you can get datagrams from ports > that you haven't explicitly specified, then it's possible to > radically simplify the protocol by discarding both Send Indication > and Data Indication. The basic protocol only has three components: > > - Allocate -- as described in S 6 > - Bind -- open a permission for a specific 5-tuple > - Data framing -- as described in S 4 > > So, the way this would work is as follows: > > Client Server Peer > ------ ------ ---- > ALLOCATE -> > <- OK(addr = X:x) > > BIND(Channel=1, Remote=Y:y) -> > <- OK > > <- Message1 (Y:y -> X:x) > <- DATA(Channel=1, Message1) > > DATA(Channel=1,Message2) -> > Message2 -> > > In the terminology of the current draft, BIND does two things: > > 1. Opens up a permission for X:x <-> Y:y > 2. Assigns a channel # to the permission > > We can dispense with Data Indication because no packet can be sent > from the Server to the Client until a permission is opened and the > permission and the channel assignment come together. > > We can dispense with Send Indication because it's preceded by a > channel assignment using BIND. The Server can simply discard any > framed messages it receives prior to the receipt of the BIND. Now, one > could argue that if you're using UDP from the Client to the TURN > Server, then the BIND could get lost in which case the data will be > dropped and that this is bad (note that this can't happen with TCP). I > actually think this is just fine--in order for protocols to work well, > the path from the Client to the TURN Server has to be pretty reliable, > and since the Peer can't respond anyway until the BIND is received, > this probably isn't a big deal. However, if this is really a concern > you could keep Send Indication around, but without the channel > establishment side effects. > > > [0] Yes, I appreciate that the general function of TURN is to bypass > middlebox policies, but that seems like something to minimize. > > -Ekr > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 03 17:10:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJUf-0006F0-W4; Mon, 03 Dec 2007 17:10:26 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IzJUe-0005tA-4c for behave-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 17:10:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJUd-0005me-Cc for behave@ietf.org; Mon, 03 Dec 2007 17:10:23 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzJUd-00019w-1E for behave@ietf.org; Mon, 03 Dec 2007 17:10:23 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 03 Dec 2007 14:10:22 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB3MAMJu014907; Mon, 3 Dec 2007 14:10:22 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lB3M9tr1000455; Mon, 3 Dec 2007 22:10:22 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 14:10:18 -0800 Received: from [10.21.92.116] ([10.21.92.116]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 14:10:17 -0800 Message-ID: <47547EEE.4070307@cisco.com> Date: Mon, 03 Dec 2007 17:10:54 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Marc Petit-Huguenin Subject: Re: [BEHAVE] TURN servers available for testing References: <47530DC6.6020000@acm.org> In-Reply-To: <47530DC6.6020000@acm.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Dec 2007 22:10:17.0879 (UTC) FILETIME=[49A5CA70:01C835F9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=893; t=1196719822; x=1197583822; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20servers=20available=20for=20testing |Sender:=20; bh=/6MUZbuu9VzyxjtjF4Tg/ASqF5pzEQ4dsD2r3syghSY=; b=OYtGvXoboosUAg67q8BQAFqvHxx+AC/G9ak6LsYYyP97FjD5UnYEV2E1F2cddPe5yWomXFeC 8ZciwumFDn4mmWCpjih1VkPDar9RLN+nNswd0ID+0ejY/kF/HcDnKCjB; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Thank you Marc! I applaud you and 8x8 for doing this. Thanks, Jonathan R. Marc Petit-Huguenin wrote: > To accelerate the development of TURN clients compliant with > draft-ietf-behave-05, 8x8 Inc. (provider of the Packet8 service) is > sponsoring the deployment of TURN servers that can be freely used for > testing. > > If you are interested in testing your TURN client with our servers, > please send me an email at marc@8x8.com. I'll reply in the next days > with the instructions to setup an account. > > Please do not CC the mailing-list when responding to this email. > > Thanks. > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 03 17:24:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJhw-0003Zg-BB; Mon, 03 Dec 2007 17:24:08 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IzJhu-0003Yp-Ai for behave-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 17:24:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJhu-0003YV-0C for behave@ietf.org; Mon, 03 Dec 2007 17:24:06 -0500 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzJhq-0008Qq-5j for behave@ietf.org; Mon, 03 Dec 2007 17:24:05 -0500 Received: by wa-out-1112.google.com with SMTP id k40so7930761wah for ; Mon, 03 Dec 2007 14:24:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=i7CbR3ZPyWimnlqpSjai41VIrgtNSAexO9hk6uTKnj4=; b=hDmAnj5mzjUcfYsu7uWDCcDxEzfPaczSwgNrs83LKNyOTYzfI3RP1qj8mdL4fssNjRd8epvPDE73kWWKNsv1xCuBsXMhHGhg136AgorCn53FEzQ0h1N1WbrPsnweg46zo50ZpVQ2C7mNFb1t1j1SePlWzunL8Yb6VbSa2/pW0vM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=u5aM0konNnMdewoRGY9n8MS/2a+jvhfLNERyQApP4ZFEDniaW8WVoQS4pBnkabE9IolDvdE8umyw+XGwnmypJwYEawKyMnwJHClBMjDH80mihnyj7Qfy0kZRKcFBqjBgpl3m69hgub5+MKK2g9KsjZjZBcxBRtp2xnIu+J4+wE8= Received: by 10.142.127.10 with SMTP id z10mr794274wfc.1196720640541; Mon, 03 Dec 2007 14:24:00 -0800 (PST) Received: by 10.142.238.13 with HTTP; Mon, 3 Dec 2007 14:24:00 -0800 (PST) Message-ID: Date: Mon, 3 Dec 2007 14:24:00 -0800 From: "Derek MacDonald" To: "Jonathan Rosenberg" Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-05 In-Reply-To: <47547EC8.2010405@cisco.com> MIME-Version: 1.0 References: <20071203050444.F1C4933C47@delta.rtfm.com> <47547EC8.2010405@cisco.com> X-Google-Sender-Auth: 8fbc870318ffbad6 X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e 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="===============0824989776==" Errors-To: behave-bounces@ietf.org --===============0824989776== Content-Type: multipart/alternative; boundary="----=_Part_13509_19877747.1196720640508" ------=_Part_13509_19877747.1196720640508 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I second Jonathan on this. In a lot of cases both parties will be using the same SP and will consequently suffer the pain of both relays, and might not have any control over what NATs their customers buy. On Dec 3, 2007 2:10 PM, Jonathan Rosenberg wrote: > Eric, > > Interesting suggestion. I agree that what you propose would simplify the > draft further, which is a good thing. But I disagree with your > assessment that this behavior is odd. RFC 4787 on NAT UDP behavior > requirements says: > > REQ-8: If application transparency is most important, it is > RECOMMENDED that a NAT have an "Endpoint-Independent Filtering" > behavior. If a more stringent filtering behavior is most > important, it is RECOMMENDED that a NAT have an "Address-Dependent > Filtering" behavior. > > AFAIK, this group found no additional security benefits from address and > port dependent filtering. > > You are correct in your assessment that the current behavior is requied > for TURN to work without TWO relays when the other side is behind > address-depenent. This isn't a corner case; I think we expect this to be > a common configuration. > > It also allows a single TURN server to be used when the other side is > behind an address or address-and-port dependent mapping NAT, but its a > residential nat with a single IP. This is a good case to support. > > So, I am opposed to making this change in TURN. > > -Jonathan R. > > Eric Rescorla wrote: > > $Id: draft-ietf-behave-turn-05-rev.txt,v 1.3 2007/12/03 05:00:28 ekr Exp > $ > > > > General comments below. > > > > PORT-DEPENDENT FILTERING > > As I understand the functionality provided by this draft, it's acting > > like an address-restricted NAT. I.e., if I allocate address X:x and > > then send a packet to Y:y via this allocation, this creates a > > permission for Y:*, so that a packet from Y:z gets forwarded to the > > client. Do I have that right? > > > > This is different from what I understand to be the sort of > > address/port filtering behavior typically used by address-dependent > > filtered NATs and firewalls, namely that the pinhole opened is only > > X:x-Y:y, not X:x-Y:*. This is pretty clearly intended as a security > > feature (note that I'm not claiming it actually provides security) and > > bypassing it unnecessarily [0] seems like a move which is going to > > disincentivize TURN deployment. Note that you get this behavior *even > > if* you have a good NAT and ICE eventually settles on a non-relayed > > path. > > > > I'm assuming that the intent here is to allow TURN clients to easily > > talk to nodes behind NATs with address-dependent port mapping. If so, > > I think this is probably misguided. The purpose of TURN is to fix your > > own broken NAT, not other people's broken NATs. One could certainly > > argue that fixing other people's NATs is a positive side effect, but I > > don't think it is, at least in part since it totally screws up the > > incentive model: we want to reward people with good NATs, not force > > them to use TURN anyway. > > > > Note that this also means that you can't get early media if ICE > > is not being used, but of course that would also be true if you > > had a NAT with port-dependent filtering, so I don't think > > that's a disaster. > > > > So, I think it would be best to restrict the permissions being opened > > here to just those address/port which the client specifically > > addresses. > > > > > > COMPLEXITY > > If you abandon the notion that you can get datagrams from ports > > that you haven't explicitly specified, then it's possible to > > radically simplify the protocol by discarding both Send Indication > > and Data Indication. The basic protocol only has three components: > > > > - Allocate -- as described in S 6 > > - Bind -- open a permission for a specific 5-tuple > > - Data framing -- as described in S 4 > > > > So, the way this would work is as follows: > > > > Client Server Peer > > ------ ------ ---- > > ALLOCATE -> > > <- OK(addr = X:x) > > > > BIND(Channel=1, Remote=Y:y) -> > > <- OK > > > > <- Message1 (Y:y -> X:x) > > <- DATA(Channel=1, Message1) > > > > DATA(Channel=1,Message2) -> > > Message2 -> > > > > In the terminology of the current draft, BIND does two things: > > > > 1. Opens up a permission for X:x <-> Y:y > > 2. Assigns a channel # to the permission > > > > We can dispense with Data Indication because no packet can be sent > > from the Server to the Client until a permission is opened and the > > permission and the channel assignment come together. > > > > We can dispense with Send Indication because it's preceded by a > > channel assignment using BIND. The Server can simply discard any > > framed messages it receives prior to the receipt of the BIND. Now, one > > could argue that if you're using UDP from the Client to the TURN > > Server, then the BIND could get lost in which case the data will be > > dropped and that this is bad (note that this can't happen with TCP). I > > actually think this is just fine--in order for protocols to work well, > > the path from the Client to the TURN Server has to be pretty reliable, > > and since the Peer can't respond anyway until the BIND is received, > > this probably isn't a big deal. However, if this is really a concern > > you could keep Send Indication around, but without the channel > > establishment side effects. > > > > > > [0] Yes, I appreciate that the general function of TURN is to bypass > > middlebox policies, but that seems like something to minimize. > > > > -Ekr > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www1.ietf.org/mailman/listinfo/behave > > > > -- > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > ------=_Part_13509_19877747.1196720640508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I second Jonathan on this.  In a lot of cases both parties will be using the same SP and will consequently suffer the pain of both relays, and might not have any control over what NATs their customers buy.

On Dec 3, 2007 2:10 PM, Jonathan Rosenberg <jdrosen@cisco.com> wrote:
Eric,

Interesting suggestion. I agree that what you propose would simplify the
draft further, which is a good thing. But I disagree with your
assessment that this behavior is odd. RFC 4787 on NAT UDP behavior
requirements says:

  REQ-8:  If application transparency is most important, it is
      RECOMMENDED that a NAT have an "Endpoint-Independent Filtering"
      behavior.  If a more stringent filtering behavior is most
      important, it is RECOMMENDED that a NAT have an "Address-Dependent
      Filtering" behavior.

AFAIK, this group found no additional security benefits from address and
port dependent filtering.

You are correct in your assessment that the current behavior is requied
for TURN to work without TWO relays when the other side is behind
address-depenent. This isn't a corner case; I think we expect this to be
a common configuration.

It also allows a single TURN server to be used when the other side is
behind an address or address-and-port dependent mapping NAT, but its a
residential nat with a single IP. This is a good case to support.

So, I am opposed to making this change in TURN.

-Jonathan R.

Eric Rescorla wrote:
> $Id: draft-ietf-behave-turn-05-rev.txt,v 1.3 2007/12/03 05:00:28 ekr Exp $
>
> General comments below.
>
> PORT-DEPENDENT FILTERING
> As I understand the functionality provided by this draft, it's acting
> like an address-restricted NAT. I.e., if I allocate address X:x and
> then send a packet to Y:y via this allocation, this creates a
> permission for Y:*, so that a packet from Y:z gets forwarded to the
> client. Do I have that right?
>
> This is different from what I understand to be the sort of
> address/port filtering behavior typically used by address-dependent
> filtered NATs and firewalls, namely that the pinhole opened is only
> X:x-Y:y, not X:x-Y:*. This is pretty clearly intended as a security
> feature (note that I'm not claiming it actually provides security) and
> bypassing it unnecessarily [0] seems like a move which is going to
> disincentivize TURN deployment. Note that you get this behavior *even
> if* you have a good NAT and ICE eventually settles on a non-relayed
> path.
>
> I'm assuming that the intent here is to allow TURN clients to easily
> talk to nodes behind NATs with address-dependent port mapping.  If so,
> I think this is probably misguided. The purpose of TURN is to fix your
> own broken NAT, not other people's broken NATs.  One could certainly
> argue that fixing other people's NATs is a positive side effect, but I
> don't think it is, at least in part since it totally screws up the
> incentive model: we want to reward people with good NATs, not force
> them to use TURN anyway.
>
> Note that this also means that you can't get early media if ICE
> is not being used, but of course that would also be true if you
> had a NAT with port-dependent filtering, so I don't think
> that's a disaster.
>
> So, I think it would be best to restrict the permissions being opened
> here to just those address/port which the client specifically
> addresses.
>
>
> COMPLEXITY
> If you abandon the notion that you can get datagrams from ports
> that you haven't explicitly specified, then it's possible to
> radically simplify the protocol by discarding both Send Indication
> and Data Indication. The basic protocol only has three components:
>
> - Allocate     -- as described in S 6
> - Bind         -- open a permission for a specific 5-tuple
> - Data framing -- as described in S 4
>
> So, the way this would work is as follows:
>
> Client                     Server                     Peer
> ------                     ------                     ----
> ALLOCATE ->
>                 <- OK(addr = X:x)
>
> BIND(Channel=1, Remote=Y:y) ->
>                             <- OK
>
>                                   <- Message1 (Y:y -> X:x)
>      <- DATA(Channel=1, Message1)
>
> DATA(Channel=1,Message2) ->
>                            Message2 ->
>
> In the terminology of the current draft, BIND does two things:
>
> 1. Opens up a permission for X:x <-> Y:y
> 2. Assigns a channel # to the permission
>
> We can dispense with Data Indication because no packet can be sent
> from the Server to the Client until a permission is opened and the
> permission and the channel assignment come together.
>
> We can dispense with Send Indication because it's preceded by a
> channel assignment using BIND. The Server can simply discard any
> framed messages it receives prior to the receipt of the BIND. Now, one
> could argue that if you're using UDP from the Client to the TURN
> Server, then the BIND could get lost in which case the data will be
> dropped and that this is bad (note that this can't happen with TCP). I
> actually think this is just fine--in order for protocols to work well,
> the path from the Client to the TURN Server has to be pretty reliable,
> and since the Peer can't respond anyway until the BIND is received,
> this probably isn't a big deal. However, if this is really a concern
> you could keep Send Indication around, but without the channel
> establishment side effects.
>
>
> [0] Yes, I appreciate that the general function of TURN is to bypass
> middlebox policies, but that seems like something to minimize.
>
> -Ekr
>
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www1.ietf.org/mailman/listinfo/behave
>

--
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
jdrosen@cisco.com
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com


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

------=_Part_13509_19877747.1196720640508-- --===============0824989776== 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 --===============0824989776==-- From behave-bounces@ietf.org Mon Dec 03 17:43:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzK0v-0007sV-0S; Mon, 03 Dec 2007 17:43:45 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IzK0t-0007q3-F8 for behave-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 17:43:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzK0t-0007oI-3h for behave@ietf.org; Mon, 03 Dec 2007 17:43:43 -0500 Received: from dhcp-11b6.ietf70.org ([130.129.17.182] helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzK0s-0004MF-Mj for behave@ietf.org; Mon, 03 Dec 2007 17:43:43 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 6283E33CA0; Mon, 3 Dec 2007 14:38:24 -0800 (PST) Date: Mon, 03 Dec 2007 14:38:24 -0800 From: Eric Rescorla To: Jonathan Rosenberg Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-05 In-Reply-To: <47547EC8.2010405@cisco.com> References: <20071203050444.F1C4933C47@delta.rtfm.com> <47547EC8.2010405@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071203223824.6283E33CA0@delta.rtfm.com> X-Spam-Score: 0.1 (/) 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: , Errors-To: behave-bounces@ietf.org At Mon, 03 Dec 2007 17:10:16 -0500, Jonathan Rosenberg wrote: > > Eric, > > Interesting suggestion. I agree that what you propose would simplify the > draft further, which is a good thing. But I disagree with your > assessment that this behavior is odd. RFC 4787 on NAT UDP behavior > requirements says: > > REQ-8: If application transparency is most important, it is > RECOMMENDED that a NAT have an "Endpoint-Independent Filtering" > behavior. If a more stringent filtering behavior is most > important, it is RECOMMENDED that a NAT have an "Address-Dependent > Filtering" behavior. > > AFAIK, this group found no additional security benefits from address and > port dependent filtering. Well, as I said in my message, I'm not claiming that there are additional security benefits to having port-dependent filtering. I'm observing that it's a fairly common policy, especially for firewalls, and that bypassing that acts as a disincentive for people who have such firewalls to deploy. > You are correct in your assessment that the current behavior is requied > for TURN to work without TWO relays when the other side is behind > address-depenent. This isn't a corner case; I think we expect this to be > a common configuration. > > It also allows a single TURN server to be used when the other side is > behind an address or address-and-port dependent mapping NAT, but its a > residential nat with a single IP. This is a good case to support. Well, this is what I'm arguing gets the incentive match wrong. > So, I am opposed to making this change in TURN. I'd observe that one can still significantly simplify TURN even if one wants to preserve this behavior. The change is to preserve Data Indication but remove Send Indication. Channel assignment is done via Bind, as described in my original message. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 03 17:44:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzK1t-0002GZ-EP; Mon, 03 Dec 2007 17:44:45 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IzK1s-0002C7-0l for behave-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 17:44:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzK1r-0002Bf-N3 for behave@ietf.org; Mon, 03 Dec 2007 17:44:43 -0500 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzK1r-00027z-CC for behave@ietf.org; Mon, 03 Dec 2007 17:44:43 -0500 Received: by py-out-1112.google.com with SMTP id d32so12951682pye for ; Mon, 03 Dec 2007 14:44:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; bh=65d0b4F9FESbLSj7ibY9q8jhgLjHRtOdlMqyMvIm+5M=; b=RfAnHxRc3I6U64Z7lPzX6rPKEafapAb05CQiTsvLDN/qJrxIp/AZMFGXrMDxZ8S4/jqhT72GZjhbWQEUhhjlKUFx7DZ2Xm7oniN6BncNex67BBPpHwkrvd+GIuPCkwl37mYnf7ImxsQmi6CYV0sUKAETm2eTj44Z5YOZjsDp6Pg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=vN6zqsNTtwOojvIN4ZeelFa4YxDDAyVpwLMiy978bE1xs1cND/Y9icm5G1yYUOqFKwf+IFax92XZ1g79Xcgiiz3gJiTKq07RvH+AfVlNZ/+QVQ7YYcfx/LSky18jW/v7oenRLcMRe05rc0tO5jIQTze8P3JoK+eY0oCWbvjDJJg= Received: by 10.142.110.3 with SMTP id i3mr1868449wfc.1196721881734; Mon, 03 Dec 2007 14:44:41 -0800 (PST) Received: by 10.142.238.13 with HTTP; Mon, 3 Dec 2007 14:44:41 -0800 (PST) Message-ID: Date: Mon, 3 Dec 2007 14:44:41 -0800 From: "Derek MacDonald" To: "Behave WG" MIME-Version: 1.0 X-Google-Sender-Auth: b174dc379371406f X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [BEHAVE] More comments on turn-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2117815005==" Errors-To: behave-bounces@ietf.org --===============2117815005== Content-Type: multipart/alternative; boundary="----=_Part_13606_1814646.1196721881762" ------=_Part_13606_1814646.1196721881762 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline As a pre-amble, I like the direction turn-05 is going. I much prefer the ChannelConfirm approach over the older active destination approach. Some comments: 6.2.1.3 I think that if the client requests "Even port with hold on the next port higher" the server should fail the request if it can't honour it. We could add a suggested timer if we are worrying about running out of ports. As it stands, the client won't know if the second port request will succeed, which could require tearing down the original port and starting again. This seems inefficient. 6.2.1.4 The server SHOULD only allocate ports in the range 1024-65535. Why not MUST? Do we really want the capability to run well known services over TURN? Nits 7.2.2 o If one has not been assigned, the client assigns one of its own... /s/client/server -Derek ------=_Part_13606_1814646.1196721881762 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline As a pre-amble, I like the direction turn-05 is going.  I much prefer the ChannelConfirm approach over the older active destination approach. 
 
Some comments:

6.2.1.3

I think that if the client requests "Even port with hold on the next port higher" the server should fail the request if it can't honour it.  We could add a suggested timer if we are worrying about running out of ports.  As it stands, the client won't know if the second port request will succeed, which could require tearing down the original port and starting again. This seems inefficient.

6.2.1.4

   The server SHOULD only allocate ports in the range 1024-65535.    

Why not MUST? Do we really want the capability to run well known services over TURN?


Nits

7.2.2

   o  If one has not been assigned, the client assigns one of its own...  

/s/client/server

-Derek
------=_Part_13606_1814646.1196721881762-- --===============2117815005== 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 --===============2117815005==-- From behave-bounces@ietf.org Mon Dec 03 18:12:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzKT3-00020Z-KF; Mon, 03 Dec 2007 18:12:49 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IzKT2-0001z5-Tl for behave-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 18:12:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzKT2-0001xF-HN for behave@ietf.org; Mon, 03 Dec 2007 18:12:48 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzKT0-0004wy-V2 for behave@ietf.org; Mon, 03 Dec 2007 18:12:48 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lB3NCg2M005666; Tue, 4 Dec 2007 01:12:43 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 01:12:42 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 01:12:42 +0200 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] More comments on turn-05 Date: Tue, 4 Dec 2007 01:12:41 +0200 Message-ID: <01F9057F4EC6BA4B86A05AAE8D472D2804CB2E35@esebe105.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] More comments on turn-05 Thread-Index: Acg1/h1xmtAujl2pT6emvPjPjK5e9wAAgnRw References: From: To: , X-OriginalArrivalTime: 03 Dec 2007 23:12:42.0625 (UTC) FILETIME=[01B0AF10:01C83602] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 =20 What is the rationale for such a restriction? If this is a HW issue then it is just a matter of time when someone comes with a TURN server product which can do this at wire speed. If this is some operator mandated requirement then it should not put in the spec as some particular interest group should be not be in a position to narrow the functionality of a protocol to suit their particular interest. Rather the spec should state that the owner of a TURN server is free to configure the TURN server to reject Allocate request with "unpleasant" REQUESTED-PORT-PROPS values. Therefore no changes should be made to the original sentence below or alternatively it should be remove altogether from the spec. /Mikael > From: ext Derek MacDonald [mailto:derek@counterpath.com]=20 > > 6.2.1.4 >=09 > The server SHOULD only allocate ports in the range 1024-65535. =20 >=09 > Why not MUST? Do we really want the capability to run well known services over TURN? =09 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 03 18:37:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzKqK-0000Zb-8Q; Mon, 03 Dec 2007 18:36:52 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IzKqI-0000Yv-LI for behave-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 18:36:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzKqI-0000Yn-BV for behave@ietf.org; Mon, 03 Dec 2007 18:36:50 -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 1IzKqH-0007bp-K4 for behave@ietf.org; Mon, 03 Dec 2007 18:36:50 -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 lB3NaeTN004919; Tue, 4 Dec 2007 01:36:46 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 01:35:39 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 01:35:39 +0200 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 solution for home networks Date: Tue, 4 Dec 2007 01:35:37 +0200 Message-ID: In-Reply-To: <22cc01c8315f$63f45430$c5f0200a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] TURN solution for home networks Thread-Index: AcgxCh1+9URymT+cSTWhQT5klyzoAQAU693wASkB5EA= References: <326A98184EC61140A2569345DB3614C1068371EB@esebe105.NOE.Nokia.com> <22cc01c8315f$63f45430$c5f0200a@cisco.com> From: To: , , X-OriginalArrivalTime: 03 Dec 2007 23:35:39.0459 (UTC) FILETIME=[3658E130:01C83605] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, Mikael Latvala wrote: >1. "[Client] needs to request each permission explicitly and=20 >one at a time."=20 > >There are two problems with this restriction. > >A. Home owner cannot know beforehand from which IP address (external IP >address) s/he is going to access the home network. I don't think this is specific to home networks as such. The IP address specific filtering at the TURN relay will basically make it impossible to run any "generic" servers via TURN, since the server would need to have a priori knowledge of IP addresses of the clients that may want to talk to the server. For usages with something like ICE this is not a problem as the peer address is always signaled before traffic via TURN needs to flow.=20 Dan Wing wrote: > >I would like folks to comment on your other points; the design=20 >decisions were made on purpose but if others are finding TURN=20 >won't meet their needs, we may need to have two 'profiles' of=20 >TURN; one that has the restriction described in TURN and=20 >another that does not require configuring permissions in the=20 >TURN server. > It's clear that this is a deliberate design choise as stated already in the abstract of TURN draft: The extension purposefully restricts the ways in which the relayed address can be used. In particular, it prevents users from running general purpose servers on ports obtained from the TURN server. What I would like to understand is where the requirement for this restriction came from. Is it just that we do not want to standardize a protocol which would allow bypassing firewall policies in this manner? But is that going to help if people can use any similar proprietary solutions for the same thing anyway? And is it necessary to make the restriction normative for all usages of TURN, or could there be another "profile" (as Dan says) of TURN where the client could request what kind of filtering to the relay should apply?=20 I agree that circumventing firewall policies is not a good goal, but I think there are many NAT-only cases (such as home networks) where there would be a clear benefit in being able to run servers via TURN in such a way that any client can contact the server, and the server itself would perhaps authorize the client. Regards, Markus=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 03 20:56:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzN1I-0006GQ-OO; Mon, 03 Dec 2007 20:56:20 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IzN1H-0006GH-PY for behave-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 20:56:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzN1H-0006G5-Db for behave@ietf.org; Mon, 03 Dec 2007 20:56:19 -0500 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzN1G-0007cM-Q6 for behave@ietf.org; Mon, 03 Dec 2007 20:56:19 -0500 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id lB41uHBI027076 for ; Mon, 3 Dec 2007 20:56:18 -0500 (EST) Received: from [130.129.84.87] ([130.129.84.87]) (authenticated bits=0) (User authenticated as baford@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id lB40tuL1021808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 3 Dec 2007 19:55:57 -0500 (EST) Message-Id: <9EEA193F-1262-4B4E-9B71-799525796E81@mit.edu> From: Bryan Ford To: IETF BEHAVE WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 3 Dec 2007 16:55:55 -0800 X-Mailer: Apple Mail (2.915) X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: [BEHAVE] A simpler way to reduce keepalive traffic X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org In the "SAFE" BOF today it emerged that (a) there seems to be a clear consensus that the IETF needs to do something to reduce the "chattiness" of NAT traversal mechanisms due to the keepalive traffic they use to keep their (especially UDP) bindings open; and (b) there's definitely no consensus yet on the best approach to accomplish that. (At least that was my personal take-away from the BOF.) Although for various reasons I would love to see a decent "explicit NAT control" or "listener discovery" protocol get standardized and deployed widely, I wanted to suggest an alternative way the one small, specific problem of keepalive chattiness might be addressed without any such explicit protocol. The solution has two elements: 1. An amendment to BEHAVE-UDP, basically affecting only section 4.3 of RFC 4787 and in a backward-compatible way, recommending that NATs multiplicatively increase each mapping's timeout over the mapping's lifetime. For example, if the NAT initially uses a 2-minute timer for a brand-new mapping (the minimum allowed), then if the mapping is still alive after 2 minutes the NAT increases the timeout by (say) 2.5x to 5 minutes; then if the mapping is still alive after that 5 minutes the timeout is again increased by 2.5x to 12.5 minutes, and so on. This is the only change required to NATs. 2. Applications that wish to minimize their keepalive chattiness can now use the following technique. They initialize their keepalive transmission timer to something safely small for all "reasonable" NATs - e.g., on the order of 10 seconds - and then in the background initiate a binding lifetime discovery mechanism analogous (but not identical) to that described in section 4.5 of draft-ietf-behave-nat- behavior-discovery-02. In particular, instead of assuming the NAT's binding lifetime is fixed and doing a binary search for it as the draft suggests, the application just probes successively larger lifetimes in progression, increasing the probe by a multiplicative factor of (say) 1.5x each time. When the application has verified that the NAT seems to have a binding lifetime of "at least" x, the application sets its keepalive period for the "main" UDP session it's actually using to that value and continues on to probe larger values. Now, when the path contains one or more "legacy" NATs with a fixed binding lifetime, the above application behavior will find that lifetime and use a suitably-matched keepalive period on an ongoing basis - thus, even with no modifications to existing NATs, the application effectively minimizes its chattiness to whatever the NATs on the path will permit. On the other hand, when the path contains only NATs that behave as proposed in #1 above, as long as the application's starting period and multiplicative increase factor is less than the NAT's, then both periods will continue to increase indefinitely, resulting in O(log t) instead of O(t) keepalive traffic over a long-lived binding with a total actual lifetime of t. Once the application eventually terminates, the time it takes the NAT to notice this is now proportional to the amount of time the application's binding was actually active: so even though the NAT might take a while to garbage-collect a long-lived binding, any given binding can be in such a "dead" state for only a constant percentage of its total lifetime. Thus, the scheme guarantees both logarithmic keepalive chatter over a binding's lifetime, and an easily-computable "efficiency ratio" if you compare a binding's total lifetime against the amount of time the application actually uses that binding. Of course there are plenty of details to work out, such as what the multiplicative factors are, and whether the application should use a single UDP session for both application use and binding lifetime discovery probing as the behavior-discovery draft suggests, or a separate UDP session for each purpose. Using a single UDP session is obviously more efficient in terms of NAT state and absolute keepalive traffic load, but has the disadvantage of allowing the application's main UDP session to "go dead" for some period as the application's binding lifetime probe period exceeds the binding lifetime of some legacy NAT in the path, perhaps leaving the SIP client temporarily unreachable from the outside world for example. Cheers, Bryan _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 03 21:50:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzNre-0006Fp-1F; Mon, 03 Dec 2007 21:50:26 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IzNrc-0006FU-6h for behave-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 21:50:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzNrb-0006FK-Dq for behave@ietf.org; Mon, 03 Dec 2007 21:50:23 -0500 Received: from smtpauth02.csee.onr.siteprotect.com ([64.26.60.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzNra-0001rd-NZ for behave@ietf.org; Mon, 03 Dec 2007 21:50:23 -0500 Received: from cornfed (unknown [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth02.csee.onr.siteprotect.com (Postfix) with ESMTP id 3E609E38010; Mon, 3 Dec 2007 20:50:20 -0600 (CST) From: "Frank W. Miller" To: "'Bryan Ford'" , "'IETF BEHAVE WG'" Subject: RE: [BEHAVE] A simpler way to reduce keepalive traffic Date: Mon, 3 Dec 2007 19:50:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <9EEA193F-1262-4B4E-9B71-799525796E81@mit.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 thread-index: Acg2GPPzUIa7Hqb4TPOXIi+faVnxKQAByB3w Message-Id: <20071204025020.3E609E38010@smtpauth02.csee.onr.siteprotect.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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 Since I was not able to attend the BoF, could you provide a synopsis of why this consensus was arrived at? Specifically, can you describe any deployment scenarios that were quantitatively presented that have difficulty with the "chattiness" you are referring to? I will assume that the chattiness is primarily a problem for the STUN servers that are servicing the keepalives. What kind of data was presented to support this problem? Thanks, FM -----Original Message----- From: Bryan Ford [mailto:baford@MIT.EDU] Sent: Monday, December 03, 2007 5:56 PM To: IETF BEHAVE WG Subject: [BEHAVE] A simpler way to reduce keepalive traffic In the "SAFE" BOF today it emerged that (a) there seems to be a clear consensus that the IETF needs to do something to reduce the "chattiness" of NAT traversal mechanisms due to the keepalive traffic they use to keep their (especially UDP) bindings open; and (b) there's definitely no consensus yet on the best approach to accomplish that. (At least that was my personal take-away from the BOF.) Although for various reasons I would love to see a decent "explicit NAT control" or "listener discovery" protocol get standardized and deployed widely, I wanted to suggest an alternative way the one small, specific problem of keepalive chattiness might be addressed without any such explicit protocol. The solution has two elements: 1. An amendment to BEHAVE-UDP, basically affecting only section 4.3 of RFC 4787 and in a backward-compatible way, recommending that NATs multiplicatively increase each mapping's timeout over the mapping's lifetime. For example, if the NAT initially uses a 2-minute timer for a brand-new mapping (the minimum allowed), then if the mapping is still alive after 2 minutes the NAT increases the timeout by (say) 2.5x to 5 minutes; then if the mapping is still alive after that 5 minutes the timeout is again increased by 2.5x to 12.5 minutes, and so on. This is the only change required to NATs. 2. Applications that wish to minimize their keepalive chattiness can now use the following technique. They initialize their keepalive transmission timer to something safely small for all "reasonable" NATs - e.g., on the order of 10 seconds - and then in the background initiate a binding lifetime discovery mechanism analogous (but not identical) to that described in section 4.5 of draft-ietf-behave-nat- behavior-discovery-02. In particular, instead of assuming the NAT's binding lifetime is fixed and doing a binary search for it as the draft suggests, the application just probes successively larger lifetimes in progression, increasing the probe by a multiplicative factor of (say) 1.5x each time. When the application has verified that the NAT seems to have a binding lifetime of "at least" x, the application sets its keepalive period for the "main" UDP session it's actually using to that value and continues on to probe larger values. Now, when the path contains one or more "legacy" NATs with a fixed binding lifetime, the above application behavior will find that lifetime and use a suitably-matched keepalive period on an ongoing basis - thus, even with no modifications to existing NATs, the application effectively minimizes its chattiness to whatever the NATs on the path will permit. On the other hand, when the path contains only NATs that behave as proposed in #1 above, as long as the application's starting period and multiplicative increase factor is less than the NAT's, then both periods will continue to increase indefinitely, resulting in O(log t) instead of O(t) keepalive traffic over a long-lived binding with a total actual lifetime of t. Once the application eventually terminates, the time it takes the NAT to notice this is now proportional to the amount of time the application's binding was actually active: so even though the NAT might take a while to garbage-collect a long-lived binding, any given binding can be in such a "dead" state for only a constant percentage of its total lifetime. Thus, the scheme guarantees both logarithmic keepalive chatter over a binding's lifetime, and an easily-computable "efficiency ratio" if you compare a binding's total lifetime against the amount of time the application actually uses that binding. Of course there are plenty of details to work out, such as what the multiplicative factors are, and whether the application should use a single UDP session for both application use and binding lifetime discovery probing as the behavior-discovery draft suggests, or a separate UDP session for each purpose. Using a single UDP session is obviously more efficient in terms of NAT state and absolute keepalive traffic load, but has the disadvantage of allowing the application's main UDP session to "go dead" for some period as the application's binding lifetime probe period exceeds the binding lifetime of some legacy NAT in the path, perhaps leaving the SIP client temporarily unreachable from the outside world for example. Cheers, Bryan _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 03 22:18:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzOJ1-0002Xo-UH; Mon, 03 Dec 2007 22:18:43 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IzOJ0-0002Xa-Ne for behave-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 22:18:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzOJ0-0002XP-Cg for behave@ietf.org; Mon, 03 Dec 2007 22:18:42 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-08.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzOJ0-0006qT-0p for behave@ietf.org; Mon, 03 Dec 2007 22:18:42 -0500 Received: from dhcp-17f5.ietf70.org ([130.129.23.245]) by mail-08.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IzOIz-0002O0-0E; Mon, 03 Dec 2007 22:18:41 -0500 In-Reply-To: <20071203223824.6283E33CA0@delta.rtfm.com> References: <20071203050444.F1C4933C47@delta.rtfm.com> <47547EC8.2010405@cisco.com> <20071203223824.6283E33CA0@delta.rtfm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2CB8FB98-2DEF-4560-AF92-59A8F499198D@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-05 Date: Mon, 3 Dec 2007 19:18:41 -0800 To: Eric Rescorla X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - dhcp-17f5.ietf70.org [130.129.23.245] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 On 3-Dec-07, at 14:38 , Eric Rescorla wrote: > > > I'd observe that one can still significantly simplify TURN even > if one wants to preserve this behavior. The change is to preserve > Data Indication but remove Send Indication. Channel assignment > is done via Bind, as described in my original message. > If I understand the proposal, then I think there is a problem. What if the client has lots of data to send, but has not yet received the Bind Response from the server? What does it do? Consider the following example C T |------ Bind (channel=1, remote=Y:y)----> X | (lost!) |-------[1] Data packet #1 ------------------>| (dropped) |-------[1] Data packet #2 ------------------>| (dropped) |-------[1] Data packet #3 ------------------>| (dropped) |-------[1] Data packet #4 ------------------>| (dropped) |------ Bind (channel=1, remote=Y:y) -------->| (resend) |<----------- Bind Response (OK)--------------| Here the server drops all the data flowing on channel [1] until the client times out and retransmits the Bind Request. By contrast, the proposal in the document works as follows C T |---Send (channel=1, remote=Y:y, data=packet#1)----> X | (lost!) |---Send (channel=1, remote=Y:y, data=packet#2)------> | (accepted) |---Send (channel=1, remote=Y:y, data=packet#3)------> | (accepted) |<------------ ChannelConf (channel=1) --------------- | (confirm) |---[1] packet#4 -----------------------------------> | (accepted) With the existing proposal, the client can send multiple Send Indications containing the the remote destination and the corresponding channel number, until it receives a ChannelConfirmation Indication. The design group considered this idea back in September, but opted for the design currently in the document for the above reason. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 03 22:33:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzOXE-0003Ll-S6; Mon, 03 Dec 2007 22:33:24 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IzOXE-0003Lb-43 for behave-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 22:33:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzOXD-0003LS-Qm for behave@ietf.org; Mon, 03 Dec 2007 22:33:23 -0500 Received: from dhcp-11b6.ietf70.org ([130.129.17.182] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzOXD-0005bl-3n for behave@ietf.org; Mon, 03 Dec 2007 22:33:23 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 3F6DC33CA0; Mon, 3 Dec 2007 19:28:04 -0800 (PST) Date: Mon, 03 Dec 2007 19:28:03 -0800 From: Eric Rescorla To: Philip Matthews Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-05 In-Reply-To: <2CB8FB98-2DEF-4560-AF92-59A8F499198D@magma.ca> References: <20071203050444.F1C4933C47@delta.rtfm.com> <47547EC8.2010405@cisco.com> <20071203223824.6283E33CA0@delta.rtfm.com> <2CB8FB98-2DEF-4560-AF92-59A8F499198D@magma.ca> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071204032804.3F6DC33CA0@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Rohan Mahy , Dan Wing , behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org At Mon, 3 Dec 2007 19:18:41 -0800, Philip Matthews wrote: > > > On 3-Dec-07, at 14:38 , Eric Rescorla wrote: > > > > > > > I'd observe that one can still significantly simplify TURN even > > if one wants to preserve this behavior. The change is to preserve > > Data Indication but remove Send Indication. Channel assignment > > is done via Bind, as described in my original message. > > > > If I understand the proposal, then I think there is a problem. > What if the client has lots of data to send, but has not yet received > the Bind Response from the server? What does it do? It keeps transmitting and potentially escalates the retransmit of the Bind. > Consider the following example > > C T > |------ Bind (channel=1, remote=Y:y)----> X | (lost!) > |-------[1] Data packet #1 ------------------>| (dropped) > |-------[1] Data packet #2 ------------------>| (dropped) > |-------[1] Data packet #3 ------------------>| (dropped) > |-------[1] Data packet #4 ------------------>| (dropped) > |------ Bind (channel=1, remote=Y:y) -------->| (resend) > |<----------- Bind Response (OK)--------------| > Here the server drops all the data flowing on channel [1] > until the client times out and retransmits the Bind Request. Yes, as I said in my message: Now, one could argue that if you're using UDP from the Client to the TURN Server, then the BIND could get lost in which case the data will be dropped and that this is bad (note that this can't happen with TCP). I actually think this is just fine--in order for protocols to work well, the path from the Client to the TURN Server has to be pretty reliable, and since the Peer can't respond anyway until the BIND is received, this probably isn't a big deal. However, if this is really a concern you could keep Send Indication around, but without the channel establishment side effects. I can think of another approach too: do "fast retransmit" of the Bind, e.g., clocked at one every X data packets. Remember that if there's any significant packet loss, then you have a serious problem, so you don't need to see the ACK to do anything, just have high confidence that the Bind will get through. Moreover, if you have high packet loss for the Bind, then it's pretty hard to complain about loss in the data stream. > By contrast, the proposal in the document works as follows > C T > |---Send (channel=1, remote=Y:y, data=packet#1)----> X | (lost!) > |---Send (channel=1, remote=Y:y, data=packet#2)------> | (accepted) > |---Send (channel=1, remote=Y:y, data=packet#3)------> | (accepted) > |<------------ ChannelConf (channel=1) --------------- | (confirm) > |---[1] packet#4 -----------------------------------> | (accepted) > > With the existing proposal, the client can send multiple Send > Indications > containing the the remote destination and the corresponding channel > number, until it receives a ChannelConfirmation Indication. > > The design group considered this idea back in September, > but opted for the design currently in the document > for the above reason. Right. As I said above, I don't consider this advantage enough to justify the added complexity--in particularly the overloading of the SendIndication to both carry data and do the channel assignment. If it's really considered a showstopper to lose *any* data packets due to a loss of the Bind, then I think the protocol would be removed by separating Send Indication and Bind functionality. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 03 22:42:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzOg8-0007TQ-Qw; Mon, 03 Dec 2007 22:42:36 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IzOg7-0007TF-Va for behave-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 22:42:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzOg7-0007T4-Lh for behave@ietf.org; Mon, 03 Dec 2007 22:42:35 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzOg5-0006LI-U8 for behave@ietf.org; Mon, 03 Dec 2007 22:42:35 -0500 Received: from dhcp-17f5.ietf70.org ([130.129.23.245]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IzOg5-0004oG-0c; Mon, 03 Dec 2007 22:42:33 -0500 In-Reply-To: References: <326A98184EC61140A2569345DB3614C1068371EB@esebe105.NOE.Nokia.com> <22cc01c8315f$63f45430$c5f0200a@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <04035497-5751-4299-B997-33D249019D46@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN solution for home networks Date: Mon, 3 Dec 2007 19:42:33 -0800 To: Mikael.Latvala@nokia.com X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - dhcp-17f5.ietf70.org [130.129.23.245] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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 The model that the TURN spec follows is this: TURN is a media-relay (or data relay) protocol. It is not a signaling relay protocol. TURN relays arbitrary data without inspecting it and relies on the permission model to prevent various DoS attacks against the client. Note that this permission model is identical to the permission model used by many NATs and FWs. To work with such a permission model, the best thing is to use ICE. ICE can install the necessary permissions to work with TURN. However, ICE requires a separate signaling channel. This signaling channel can be implemented using a signaling relay. This signaling relay looks superficially like TURN, but uses a different permission model. In particular, this signaling relay understands the signaling protocol and can make a sensible determination on when it is appropriate to relay a signaling message. For example: The SIP signaling relay is known as a SIP proxy. The HIP group is looking at a signaling relay which relays only HIP messages and uses the properties of the HIP protocol to avoid DoS attacks. - Philip On 3-Dec-07, at 15:35 , wrote: > Hi, > > Mikael Latvala wrote: >> 1. "[Client] needs to request each permission explicitly and >> one at a time." >> >> There are two problems with this restriction. >> >> A. Home owner cannot know beforehand from which IP address >> (external IP >> address) s/he is going to access the home network. > > I don't think this is specific to home networks as such. The IP > address > specific filtering at the TURN relay will basically make it impossible > to run any "generic" servers via TURN, since the server would need to > have a priori knowledge of IP addresses of the clients that may > want to > talk to the server. For usages with something like ICE this is not a > problem as the peer address is always signaled before traffic via TURN > needs to flow. > > Dan Wing wrote: >> >> I would like folks to comment on your other points; the design >> decisions were made on purpose but if others are finding TURN >> won't meet their needs, we may need to have two 'profiles' of >> TURN; one that has the restriction described in TURN and >> another that does not require configuring permissions in the >> TURN server. >> > > It's clear that this is a deliberate design choise as stated > already in > the abstract of TURN draft: > > The extension purposefully restricts the ways in > which the relayed address can be used. In particular, it prevents > users from running general purpose servers on ports obtained > from the > TURN server. > > What I would like to understand is where the requirement for this > restriction came from. Is it just that we do not want to standardize a > protocol which would allow bypassing firewall policies in this manner? > But is that going to help if people can use any similar proprietary > solutions for the same thing anyway? And is it necessary to make the > restriction normative for all usages of TURN, or could there be > another > "profile" (as Dan says) of TURN where the client could request what > kind > of filtering to the relay should apply? > > I agree that circumventing firewall policies is not a good goal, but I > think there are many NAT-only cases (such as home networks) where > there > would be a clear benefit in being able to run servers via TURN in > such a > way that any client can contact the server, and the server itself > would > perhaps authorize the client. > > Regards, > Markus > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 03 23:01:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzOyV-0003Go-8i; Mon, 03 Dec 2007 23:01:35 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IzOyT-00039O-84 for behave-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 23:01:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzOyS-00039F-UJ for behave@ietf.org; Mon, 03 Dec 2007 23:01:32 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzOyR-0007qZ-5x for behave@ietf.org; Mon, 03 Dec 2007 23:01:32 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id lB440nU29130; Mon, 3 Dec 2007 20:00:49 -0800 In-Reply-To: <20071204032804.3F6DC33CA0@delta.rtfm.com> References: <20071203050444.F1C4933C47@delta.rtfm.com> <47547EC8.2010405@cisco.com> <20071203223824.6283E33CA0@delta.rtfm.com> <2CB8FB98-2DEF-4560-AF92-59A8F499198D@magma.ca> <20071204032804.3F6DC33CA0@delta.rtfm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <04047175-ED35-4A1A-8570-C22D893EF613@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-05 Date: Mon, 3 Dec 2007 20:00:50 -0800 To: Eric Rescorla X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: Rohan Mahy , Dan Wing , behave@ietf.org, Philip Matthews X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Dec 3, 2007, at 7:28 PM, Eric Rescorla wrote: > At Mon, 3 Dec 2007 19:18:41 -0800, > Philip Matthews wrote: >> >> >> On 3-Dec-07, at 14:38 , Eric Rescorla wrote: >> >>> >>> >>> I'd observe that one can still significantly simplify TURN even >>> if one wants to preserve this behavior. The change is to preserve >>> Data Indication but remove Send Indication. Channel assignment >>> is done via Bind, as described in my original message. >>> >> >> If I understand the proposal, then I think there is a problem. >> What if the client has lots of data to send, but has not yet received >> the Bind Response from the server? What does it do? > > It keeps transmitting and potentially escalates the retransmit > of the Bind. > > >> Consider the following example >> >> C T >> |------ Bind (channel=1, remote=Y:y)----> X | (lost!) >> |-------[1] Data packet #1 ------------------>| (dropped) >> |-------[1] Data packet #2 ------------------>| (dropped) >> |-------[1] Data packet #3 ------------------>| (dropped) >> |-------[1] Data packet #4 ------------------>| (dropped) >> |------ Bind (channel=1, remote=Y:y) -------->| (resend) >> |<----------- Bind Response (OK)--------------| >> Here the server drops all the data flowing on channel [1] >> until the client times out and retransmits the Bind Request. > > Yes, as I said in my message: > > Now, one could argue that if you're using UDP from the Client to > the TURN Server, then the BIND could get lost in which case the > data will be dropped and that this is bad (note that this can't > happen with TCP). Note that with TCP, no Channel Confirmation Indication is needed either. > I actually think this is just fine--in order for > protocols to work well, the path from the Client to the TURN Server > has to be pretty reliable, and since the Peer can't respond anyway > until the BIND is received, this probably isn't a big > deal. If there is 100ms of RTT time between the client and the TURN server and I need to send lots of packets to send the initial frame. Lets say I need to send 30 packets in a burst before I receive could possibly receive a response. That's 30 STUN transactions and several of their retransmits before I can send unencapsulated. > However, if this is really a concern you could keep Send > Indication around, but without the channel establishment side > effects. > > I can think of another approach too: do "fast retransmit" of the Bind, > e.g., clocked at one every X data packets. I don't think hammering the network with retransmissions of little value until you have a good idea of RTT is going to improve the likelihood that your traffic is going to arrive. Note that the *DATA* doesn't need to be retransmitted, just the channel binding. > Remember that if there's > any significant packet loss, then you have a serious problem, so you > don't need to see the ACK to do anything, just have high confidence > that the Bind will get through. Moreover, if you have high packet > loss for the Bind, then it's pretty hard to complain about loss > in the data stream. The problem I described has no packet loss thanks, -rohan > > >> By contrast, the proposal in the document works as follows >> C T >> |---Send (channel=1, remote=Y:y, data=packet#1)----> X | (lost!) >> |---Send (channel=1, remote=Y:y, data=packet#2)------> | (accepted) >> |---Send (channel=1, remote=Y:y, data=packet#3)------> | (accepted) >> |<------------ ChannelConf (channel=1) --------------- | (confirm) >> |---[1] packet#4 -----------------------------------> | (accepted) >> >> With the existing proposal, the client can send multiple Send >> Indications >> containing the the remote destination and the corresponding channel >> number, until it receives a ChannelConfirmation Indication. >> >> The design group considered this idea back in September, >> but opted for the design currently in the document >> for the above reason. > > Right. As I said above, I don't consider this advantage enough > to justify the added complexity--in particularly the overloading > of the SendIndication to both carry data and do the channel > assignment. If it's really considered a showstopper to lose > *any* data packets due to a loss of the Bind, then I think the > protocol would be removed by separating Send Indication and > Bind functionality. > > -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 04 00:23:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzQFC-0005NV-2N; Tue, 04 Dec 2007 00:22:54 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IzQFB-0005NM-Hw for behave-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 00:22:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzQFB-0005NB-73 for behave@ietf.org; Tue, 04 Dec 2007 00:22:53 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzQFA-0007QH-Mc for behave@ietf.org; Tue, 04 Dec 2007 00:22:53 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lB45Mk77013087 for ; Tue, 4 Dec 2007 07:22:50 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 07:22:38 +0200 Received: from essapo-nirac252122.europe.nokia.com ([10.162.252.122]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 07:22:35 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] TURN solution for home networks Date: Tue, 4 Dec 2007 07:22:28 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <326A98184EC61140A2569345DB3614C1068371EB@esebe105.NOE.Nokia.com> <04035497-5751-4299-B997-33D249019D46@magma.ca> In-Reply-To: <04035497-5751-4299-B997-33D249019D46@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200712040722.28300.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 04 Dec 2007 05:22:38.0546 (UTC) FILETIME=[AF7D7320:01C83635] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Le Tuesday 04 December 2007 05:42:33 ext Philip Matthews, vous avez =E9crit= =A0: > The model that the TURN spec follows is this: > TURN is a media-relay (or data relay) protocol. (...) > To work with such a permission model, the best thing is to use ICE. (...) > However, ICE requires a separate signaling channel. I believe it's quite irrelevant whether some protocol is "signaling"=20 or "media". Afterall, when it look at SIP/RTP, SIP is signaling and RTP is= =20 data. Yet when you look at DNS/SIP, DNS is signaling and SIP is the=20 payload/data :) However, it is very relevant in the more general sense that signaling is=20 always needed in some form. Independent of ICE and/or SIP, there must be so= me=20 way to learn the IP and port of the TURN allocation. Even if TURN is=20 modified/extended to relay unsolicited traffic, the need for signaling befo= re=20 TURN will not go away automagically. That is true even if you have a public= =20 unrestrained IP address, and don't (need to) use TURN. The only difference= =20 with TURN is: in addition to the IP address, the port number must also be=20 carried, as TURN cannot allow static ports (lest we have one single TURN=20 client per TURN server ;-) ) =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 04 01:14:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzR33-0000w3-8d; Tue, 04 Dec 2007 01:14:25 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IzR31-0000sL-Rv for behave-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 01:14:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzR2y-0000n4-Pc for behave@ietf.org; Tue, 04 Dec 2007 01:14:20 -0500 Received: from quinthar.com ([72.52.120.178]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IzR2v-0007Rn-Hf for behave@ietf.org; Tue, 04 Dec 2007 01:14:20 -0500 Received: from lappy ([98.207.96.5]) by quinthar.com for ; Mon, 3 Dec 2007 22:14:15 -0800 From: "David Barrett" To: "'Frank W. Miller'" , "'Bryan Ford'" , "'IETF BEHAVE WG'" Subject: RE: [BEHAVE] A simpler way to reduce keepalive traffic Date: Mon, 3 Dec 2007 22:14:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acg2GPPzUIa7Hqb4TPOXIi+faVnxKQAByB3wAAbcHKA= In-Reply-To: <20071204025020.3E609E38010@smtpauth02.csee.onr.siteprotect.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Message-Id: 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 Incidentally, we've been using the technique Bryan suggests for over a year now across several hundred thousand computers and it works great. Indeed, I can confirm there are NATs out there that already have this property, though they're not typical. The only thing annoying about it is it requires two separate ports: one to probe with (that you don't care if it loses its mapping), and one to actually use. If it's interesting to anybody, I could pull together some data on the distribution of real-world NAT timeouts. At the very least, that could help shed light on whether or not the chattiness is really a problem. (Off the cuff, I'd say that a 5M timeout window seems to be common, but I really don't know for sure.) -david > -----Original Message----- > From: Frank W. Miller [mailto:fwmiller@cornfed.com] > Sent: Monday, December 03, 2007 6:50 PM > To: 'Bryan Ford'; 'IETF BEHAVE WG' > Subject: RE: [BEHAVE] A simpler way to reduce keepalive traffic > > > Since I was not able to attend the BoF, could you provide a synopsis of > why > this consensus was arrived at? Specifically, can you describe any > deployment scenarios that were quantitatively presented that have > difficulty > with the "chattiness" you are referring to? I will assume that the > chattiness is primarily a problem for the STUN servers that are servicing > the keepalives. What kind of data was presented to support this problem? > > Thanks, > FM > > > > -----Original Message----- > From: Bryan Ford [mailto:baford@MIT.EDU] > Sent: Monday, December 03, 2007 5:56 PM > To: IETF BEHAVE WG > Subject: [BEHAVE] A simpler way to reduce keepalive traffic > > In the "SAFE" BOF today it emerged that (a) there seems to be a clear > consensus that the IETF needs to do something to reduce the > "chattiness" of NAT traversal mechanisms due to the keepalive traffic > they use to keep their (especially UDP) bindings open; and (b) there's > definitely no consensus yet on the best approach to accomplish that. > (At least that was my personal take-away from the BOF.) > > Although for various reasons I would love to see a decent "explicit > NAT control" or "listener discovery" protocol get standardized and > deployed widely, I wanted to suggest an alternative way the one small, > specific problem of keepalive chattiness might be addressed without > any such explicit protocol. The solution has two elements: > > 1. An amendment to BEHAVE-UDP, basically affecting only section 4.3 of > RFC 4787 and in a backward-compatible way, recommending that NATs > multiplicatively increase each mapping's timeout over the mapping's > lifetime. For example, if the NAT initially uses a 2-minute timer for > a brand-new mapping (the minimum allowed), then if the mapping is > still alive after 2 minutes the NAT increases the timeout by (say) > 2.5x to 5 minutes; then if the mapping is still alive after that 5 > minutes the timeout is again increased by 2.5x to 12.5 minutes, and so > on. This is the only change required to NATs. > > 2. Applications that wish to minimize their keepalive chattiness can > now use the following technique. They initialize their keepalive > transmission timer to something safely small for all "reasonable" NATs > - e.g., on the order of 10 seconds - and then in the background > initiate a binding lifetime discovery mechanism analogous (but not > identical) to that described in section 4.5 of draft-ietf-behave-nat- > behavior-discovery-02. In particular, instead of assuming the NAT's > binding lifetime is fixed and doing a binary search for it as the > draft suggests, the application just probes successively larger > lifetimes in progression, increasing the probe by a multiplicative > factor of (say) 1.5x each time. When the application has verified > that the NAT seems to have a binding lifetime of "at least" x, the > application sets its keepalive period for the "main" UDP session it's > actually using to that value and continues on to probe larger values. > > Now, when the path contains one or more "legacy" NATs with a fixed > binding lifetime, the above application behavior will find that > lifetime and use a suitably-matched keepalive period on an ongoing > basis - thus, even with no modifications to existing NATs, the > application effectively minimizes its chattiness to whatever the NATs > on the path will permit. On the other hand, when the path contains > only NATs that behave as proposed in #1 above, as long as the > application's starting period and multiplicative increase factor is > less than the NAT's, then both periods will continue to increase > indefinitely, resulting in O(log t) instead of O(t) keepalive traffic > over a long-lived binding with a total actual lifetime of t. Once the > application eventually terminates, the time it takes the NAT to notice > this is now proportional to the amount of time the application's > binding was actually active: so even though the NAT might take a while > to garbage-collect a long-lived binding, any given binding can be in > such a "dead" state for only a constant percentage of its total > lifetime. Thus, the scheme guarantees both logarithmic keepalive > chatter over a binding's lifetime, and an easily-computable > "efficiency ratio" if you compare a binding's total lifetime against > the amount of time the application actually uses that binding. > > Of course there are plenty of details to work out, such as what the > multiplicative factors are, and whether the application should use a > single UDP session for both application use and binding lifetime > discovery probing as the behavior-discovery draft suggests, or a > separate UDP session for each purpose. Using a single UDP session is > obviously more efficient in terms of NAT state and absolute keepalive > traffic load, but has the disadvantage of allowing the application's > main UDP session to "go dead" for some period as the application's > binding lifetime probe period exceeds the binding lifetime of some > legacy NAT in the path, perhaps leaving the SIP client temporarily > unreachable from the outside world for example. > > Cheers, > Bryan > > > > _______________________________________________ > 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 Dec 04 01:26:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzREN-0001Ed-1A; Tue, 04 Dec 2007 01:26:07 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IzREL-0001BW-Hv for behave-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 01:26:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzREK-0001BL-U5 for behave@ietf.org; Tue, 04 Dec 2007 01:26:04 -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 1IzREI-000860-Sr for behave@ietf.org; Tue, 04 Dec 2007 01:26:04 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lB46PKND004540; Tue, 4 Dec 2007 08:25:58 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 08:25:43 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 08:25:42 +0200 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 solution for home networks Date: Tue, 4 Dec 2007 08:25:33 +0200 Message-ID: <01F9057F4EC6BA4B86A05AAE8D472D2804CB2E86@esebe105.NOE.Nokia.com> In-Reply-To: <04035497-5751-4299-B997-33D249019D46@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] TURN solution for home networks Thread-Index: Acg2J+9RacAaeHddQ0Ol2eepUGfRpwAEs8GA References: <326A98184EC61140A2569345DB3614C1068371EB@esebe105.NOE.Nokia.com> <22cc01c8315f$63f45430$c5f0200a@cisco.com> <04035497-5751-4299-B997-33D249019D46@magma.ca> From: To: X-OriginalArrivalTime: 04 Dec 2007 06:25:42.0543 (UTC) FILETIME=[7EED91F0:01C8363E] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: behave@ietf.org, dwing@cisco.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Philip, Instead of imposing a particular permission model in TURN it would make more sense to specify a generic TURN "base class" protocol and then specify a particular instance of this TURN base class protocol in another spec like ICE or some other STUN usage spec. This way we would not mix protocol specific issues with the deployment issues, as is done currently in the TURN spec. I have not attended IETF meetings for some time so things may have changed since then but I clearly remember from the past that it was very much a no-no thing to put deployment specific restrictions in protocols. Dave Clark et.al. have even written a good paper about this, they call it a tussle space, in a different context but still applicable to this scenario as well. If the community working on the ICE spec wants to impose such restrictions on the use of TURN relays, that is their decision. However, this decision should have no bearing on other instances of STUN usage.=20 You say that ICE has its own permission model. If that is the case, why do we need to specify a particular permission in the current TURN spec? /Mikael =20 >-----Original Message----- >From: ext Philip Matthews [mailto:philip_matthews@magma.ca]=20 >Sent: 04.12.2007 05:43 >To: Latvala Mikael (Nokia-NRC/Helsinki) >Cc: Dan Wing; behave@ietf.org; Isomaki Markus (Nokia-SIR/Espoo) >Subject: Re: [BEHAVE] TURN solution for home networks > >The model that the TURN spec follows is this: > TURN is a media-relay (or data relay) protocol. It is not a=20 >signaling relay protocol. > TURN relays arbitrary data without inspecting it and relies=20 >on the permission model > to prevent various DoS attacks against the client. >Note that this permission model is identical to the permission=20 >model used by many NATs and FWs. > >To work with such a permission model, the best thing is to use ICE. >ICE can install the necessary permissions to work with TURN. > >However, ICE requires a separate signaling channel. >This signaling channel can be implemented using a signaling relay. >This signaling relay looks superficially like TURN, but uses a=20 >different permission model. >In particular, this signaling relay understands the signaling=20 >protocol and can make a sensible determination on when it is=20 >appropriate to relay a signaling message. > >For example: >The SIP signaling relay is known as a SIP proxy. >The HIP group is looking at a signaling relay which relays=20 >only HIP messages and uses the properties of the HIP protocol=20 >to avoid DoS attacks. > >- Philip > >On 3-Dec-07, at 15:35 , =20 > wrote: > >> Hi, >> >> Mikael Latvala wrote: >>> 1. "[Client] needs to request each permission explicitly=20 >and one at a=20 >>> time." >>> >>> There are two problems with this restriction. >>> >>> A. Home owner cannot know beforehand from which IP address=20 >(external=20 >>> IP >>> address) s/he is going to access the home network. >> >> I don't think this is specific to home networks as such. The IP=20 >> address specific filtering at the TURN relay will basically make it=20 >> impossible to run any "generic" servers via TURN, since the server=20 >> would need to have a priori knowledge of IP addresses of the clients=20 >> that may want to talk to the server. For usages with something like=20 >> ICE this is not a problem as the peer address is always signaled=20 >> before traffic via TURN needs to flow. >> >> Dan Wing wrote: >>> >>> I would like folks to comment on your other points; the design=20 >>> decisions were made on purpose but if others are finding TURN won't=20 >>> meet their needs, we may need to have two 'profiles' of TURN; one=20 >>> that has the restriction described in TURN and another that=20 >does not=20 >>> require configuring permissions in the TURN server. >>> >> >> It's clear that this is a deliberate design choise as stated already=20 >> in the abstract of TURN draft: >> >> The extension purposefully restricts the ways in >> which the relayed address can be used. In particular, it prevents >> users from running general purpose servers on ports obtained from=20 >> the >> TURN server. >> >> What I would like to understand is where the requirement for this=20 >> restriction came from. Is it just that we do not want to=20 >standardize a=20 >> protocol which would allow bypassing firewall policies in=20 >this manner? >> But is that going to help if people can use any similar proprietary=20 >> solutions for the same thing anyway? And is it necessary to make the=20 >> restriction normative for all usages of TURN, or could there be=20 >> another "profile" (as Dan says) of TURN where the client=20 >could request=20 >> what kind of filtering to the relay should apply? >> >> I agree that circumventing firewall policies is not a good=20 >goal, but I=20 >> think there are many NAT-only cases (such as home networks) where=20 >> there would be a clear benefit in being able to run servers via TURN=20 >> in such a way that any client can contact the server, and the server=20 >> itself would perhaps authorize the client. >> >> Regards, >> Markus >> >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave >> > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 04 10:46:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzZyz-0005Fm-Nx; Tue, 04 Dec 2007 10:46:49 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IzZyy-0005Df-70 for behave-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 10:46:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzZyx-0005DT-Tb for behave@ietf.org; Tue, 04 Dec 2007 10:46:47 -0500 Received: from dhcp-11b6.ietf70.org ([130.129.17.182] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzZyw-00086j-2T for behave@ietf.org; Tue, 04 Dec 2007 10:46:47 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 25CD033C47; Mon, 3 Dec 2007 22:25:35 -0800 (PST) Date: Mon, 03 Dec 2007 22:25:34 -0800 From: Eric Rescorla To: Rohan Mahy Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-05 In-Reply-To: <04047175-ED35-4A1A-8570-C22D893EF613@ekabal.com> References: <20071203050444.F1C4933C47@delta.rtfm.com> <47547EC8.2010405@cisco.com> <20071203223824.6283E33CA0@delta.rtfm.com> <2CB8FB98-2DEF-4560-AF92-59A8F499198D@magma.ca> <20071204032804.3F6DC33CA0@delta.rtfm.com> <04047175-ED35-4A1A-8570-C22D893EF613@ekabal.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071204062535.25CD033C47@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: Dan Wing , behave@ietf.org, Philip Matthews X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org At Mon, 3 Dec 2007 20:00:50 -0800, Rohan Mahy wrote: > > > On Dec 3, 2007, at 7:28 PM, Eric Rescorla wrote: > > At Mon, 3 Dec 2007 19:18:41 -0800, > > Philip Matthews wrote: > >> > >> > >> On 3-Dec-07, at 14:38 , Eric Rescorla wrote: > >> > >>> > >>> > >>> I'd observe that one can still significantly simplify TURN even > >>> if one wants to preserve this behavior. The change is to preserve > >>> Data Indication but remove Send Indication. Channel assignment > >>> is done via Bind, as described in my original message. > >>> > >> > >> If I understand the proposal, then I think there is a problem. > >> What if the client has lots of data to send, but has not yet received > >> the Bind Response from the server? What does it do? > > > > It keeps transmitting and potentially escalates the retransmit > > of the Bind. > > > > > >> Consider the following example > >> > >> C T > >> |------ Bind (channel=1, remote=Y:y)----> X | (lost!) > >> |-------[1] Data packet #1 ------------------>| (dropped) > >> |-------[1] Data packet #2 ------------------>| (dropped) > >> |-------[1] Data packet #3 ------------------>| (dropped) > >> |-------[1] Data packet #4 ------------------>| (dropped) > >> |------ Bind (channel=1, remote=Y:y) -------->| (resend) > >> |<----------- Bind Response (OK)--------------| > >> Here the server drops all the data flowing on channel [1] > >> until the client times out and retransmits the Bind Request. > > > > Yes, as I said in my message: > > > > Now, one could argue that if you're using UDP from the Client to > > the TURN Server, then the BIND could get lost in which case the > > data will be dropped and that this is bad (note that this can't > > happen with TCP). > > Note that with TCP, no Channel Confirmation Indication is needed either. Yes, but I'm not complaining about the channel confirmation as a form of chattiness but as a form of unclean protocol semantics. That's why I said that you should have a separate Bind even if you wanted to retain both Send and Data Indications. > > I actually think this is just fine--in order for > > protocols to work well, the path from the Client to the TURN Server > > has to be pretty reliable, and since the Peer can't respond anyway > > until the BIND is received, this probably isn't a big > > deal. > > If there is 100ms of RTT time between the client and the TURN server > and I need to send lots of packets to send the initial frame. Lets > say I need to send 30 packets in a burst before I receive could > possibly receive a response. That's 30 STUN transactions and several > of their retransmits before I can send unencapsulated. I'm unable to map what you're saying onto the mechanism I was describing, since I'm not proposing that you initiate a STUN request for each data packet you want to send. Rather, once you've sent a Bind, you simply use the channel you advertised and start sending packets with that channel immediately. In zero packet loss situations, this simply works. If there is packet loss and you're unlucky enough to lose the Bind, then the data packets get dropped until the retransmit of the Bind, hence the faster retransmit algorithm I suggested below. > > However, if this is really a concern you could keep Send > > Indication around, but without the channel establishment side > > effects. > > > > I can think of another approach too: do "fast retransmit" of the Bind, > > e.g., clocked at one every X data packets. > > I don't think hammering the network with retransmissions of little > value until you have a good idea of RTT is going to improve the > likelihood that your traffic is going to arrive. I didn't suggest "hammering" it. I suggested sending retransmits of the Bind at some fraction of the data rate. I don't have numbers on hand, but I would think 1/10-1/5 would be appropriate given reasonable assumptions about packet loss/reordering. > Note that the *DATA* > doesn't need to be retransmitted, just the channel binding. Nor did I suggest retransmitting the data, just the Bind request. > > Remember that if there's > > any significant packet loss, then you have a serious problem, so you > > don't need to see the ACK to do anything, just have high confidence > > that the Bind will get through. Moreover, if you have high packet > > loss for the Bind, then it's pretty hard to complain about loss > > in the data stream. > > The problem I described has no packet loss Then I apparently don't understand the problem you're describing. Please explain the sequence of events you're talking about in more detail. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 04 11:17:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzaSa-0004cs-Jm; Tue, 04 Dec 2007 11:17:24 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IzaSX-0004Fg-Lu for behave-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 11:17:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzaSX-00044v-1X for behave@ietf.org; Tue, 04 Dec 2007 11:17:21 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzaSW-0006am-1N for behave@ietf.org; Tue, 04 Dec 2007 11:17:20 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id lB4GH0U15575; Tue, 4 Dec 2007 08:17:01 -0800 In-Reply-To: <20071204062535.25CD033C47@delta.rtfm.com> References: <20071203050444.F1C4933C47@delta.rtfm.com> <47547EC8.2010405@cisco.com> <20071203223824.6283E33CA0@delta.rtfm.com> <2CB8FB98-2DEF-4560-AF92-59A8F499198D@magma.ca> <20071204032804.3F6DC33CA0@delta.rtfm.com> <04047175-ED35-4A1A-8570-C22D893EF613@ekabal.com> <20071204062535.25CD033C47@delta.rtfm.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: Rohan Mahy Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-05 Date: Tue, 4 Dec 2007 08:16:58 -0800 To: Eric Rescorla X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: Rohan Mahy , Dan Wing , behave@ietf.org, Philip Matthews X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, Modifying the retransmission rules of STUN in TURN does not seem like a big win. For one thing, this kind of rules change would make it more difficult to use/build an off-the-shelf STUN library. This seems like a pretty egregious change just to placate a philosophical/religious argument: "a form of unclean protocol semantics". Can you provide some concrete thing on the wire that actually does not work with the proposed mechanism in the draft? thanks, -rohan On Dec 3, 2007, at 10:25 PM, Eric Rescorla wrote: > At Mon, 3 Dec 2007 20:00:50 -0800, > Rohan Mahy wrote: >> >> >> On Dec 3, 2007, at 7:28 PM, Eric Rescorla wrote: >>> At Mon, 3 Dec 2007 19:18:41 -0800, >>> Philip Matthews wrote: >>>> >>>> >>>> On 3-Dec-07, at 14:38 , Eric Rescorla wrote: >>>> >>>>> >>>>> >>>>> I'd observe that one can still significantly simplify TURN even >>>>> if one wants to preserve this behavior. The change is to preserve >>>>> Data Indication but remove Send Indication. Channel assignment >>>>> is done via Bind, as described in my original message. >>>>> >>>> >>>> If I understand the proposal, then I think there is a problem. >>>> What if the client has lots of data to send, but has not yet >>>> received >>>> the Bind Response from the server? What does it do? >>> >>> It keeps transmitting and potentially escalates the retransmit >>> of the Bind. >>> >>> >>>> Consider the following example >>>> >>>> C T >>>> |------ Bind (channel=1, remote=Y:y)----> X | (lost!) >>>> |-------[1] Data packet #1 ------------------>| (dropped) >>>> |-------[1] Data packet #2 ------------------>| (dropped) >>>> |-------[1] Data packet #3 ------------------>| (dropped) >>>> |-------[1] Data packet #4 ------------------>| (dropped) >>>> |------ Bind (channel=1, remote=Y:y) -------->| (resend) >>>> |<----------- Bind Response (OK)--------------| >>>> Here the server drops all the data flowing on channel [1] >>>> until the client times out and retransmits the Bind Request. >>> >>> Yes, as I said in my message: >>> >>> Now, one could argue that if you're using UDP from the Client to >>> the TURN Server, then the BIND could get lost in which case the >>> data will be dropped and that this is bad (note that this can't >>> happen with TCP). >> >> Note that with TCP, no Channel Confirmation Indication is needed >> either. > > Yes, but I'm not complaining about the channel confirmation as > a form of chattiness but as a form of unclean protocol semantics. > That's why I said that you should have a separate Bind even if > you wanted to retain both Send and Data Indications. > > >>> I actually think this is just fine--in order for >>> protocols to work well, the path from the Client to the TURN >>> Server >>> has to be pretty reliable, and since the Peer can't respond >>> anyway >>> until the BIND is received, this probably isn't a big >>> deal. >> >> If there is 100ms of RTT time between the client and the TURN server >> and I need to send lots of packets to send the initial frame. Lets >> say I need to send 30 packets in a burst before I receive could >> possibly receive a response. That's 30 STUN transactions and several >> of their retransmits before I can send unencapsulated. > > I'm unable to map what you're saying onto the mechanism I was > describing, since I'm not proposing that you initiate a > STUN request for each data packet you want to send. Rather, > once you've sent a Bind, you simply use the channel you > advertised and start sending packets with that channel > immediately. In zero packet loss situations, this simply > works. If there is packet loss and you're unlucky enough > to lose the Bind, then the data packets get dropped until > the retransmit of the Bind, hence the faster retransmit > algorithm I suggested below. > > >>> However, if this is really a concern you could keep Send >>> Indication around, but without the channel establishment side >>> effects. >>> >>> I can think of another approach too: do "fast retransmit" of the >>> Bind, >>> e.g., clocked at one every X data packets. >> >> I don't think hammering the network with retransmissions of little >> value until you have a good idea of RTT is going to improve the >> likelihood that your traffic is going to arrive. > > I didn't suggest "hammering" it. I suggested sending retransmits > of the Bind at some fraction of the data rate. I don't have > numbers on hand, but I would think 1/10-1/5 would be appropriate > given reasonable assumptions about packet loss/reordering. > > >> Note that the *DATA* >> doesn't need to be retransmitted, just the channel binding. > > Nor did I suggest retransmitting the data, just the Bind request. > > >>> Remember that if there's >>> any significant packet loss, then you have a serious problem, so you >>> don't need to see the ACK to do anything, just have high confidence >>> that the Bind will get through. Moreover, if you have high packet >>> loss for the Bind, then it's pretty hard to complain about loss >>> in the data stream. >> >> The problem I described has no packet loss > > Then I apparently don't understand the problem you're describing. > Please explain the sequence of events you're talking about > in more detail. > > > -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 04 11:46:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izav1-00021x-MB; Tue, 04 Dec 2007 11:46:47 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Izav0-00021k-2A for behave-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 11:46:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izauz-00021b-On for behave@ietf.org; Tue, 04 Dec 2007 11:46:45 -0500 Received: from dhcp-11b6.ietf70.org ([130.129.17.182] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izauz-00057P-Ey for behave@ietf.org; Tue, 04 Dec 2007 11:46:45 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 7DABB33C61; Tue, 4 Dec 2007 08:41:26 -0800 (PST) Date: Tue, 04 Dec 2007 08:41:26 -0800 From: Eric Rescorla To: Rohan Mahy Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-05 In-Reply-To: References: <20071203050444.F1C4933C47@delta.rtfm.com> <47547EC8.2010405@cisco.com> <20071203223824.6283E33CA0@delta.rtfm.com> <2CB8FB98-2DEF-4560-AF92-59A8F499198D@magma.ca> <20071204032804.3F6DC33CA0@delta.rtfm.com> <04047175-ED35-4A1A-8570-C22D893EF613@ekabal.com> <20071204062535.25CD033C47@delta.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071204164126.7DABB33C61@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Dan Wing , behave@ietf.org, Philip Matthews X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org At Tue, 4 Dec 2007 08:16:58 -0800, Rohan Mahy wrote: > Modifying the retransmission rules of STUN in TURN does not seem like > a big win. For one thing, this kind of rules change would make it > more difficult to use/build an off-the-shelf STUN library. Well, I'm pretty familiar with STUN libraries and I don't think it would make it particularly hard. [0] In particular, I would note that STUN libraries MUST allow cancellation of transactions in order to support ICE, and also probably has to support retransmission limits, and so this functionality can be supported by cancelling the STUN transaction and starting a new one. > This seems like a pretty egregious change just to placate a > philosophical/religious argument: "a form of unclean protocol > semantics". Once again, as I noted, it's worth adding Bind *even* if you retain Data and Send Indications. > Can you provide some concrete thing on the wire that actually does > not work with the proposed mechanism in the draft? That's the standard I would apply to whether I want to fix a finished, deployed protocol, not to whether to consider architectural cleanliness in a new protocol design. -Ekr [0] And of course, one might ask why it's a fixed point that TURN needs to use STUN. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 04 12:57:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izc1A-0005uu-M7; Tue, 04 Dec 2007 12:57:12 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Izc19-0005r4-3H for behave-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 12:57:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izc18-0005pi-OL for behave@ietf.org; Tue, 04 Dec 2007 12:57:10 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izc17-0007t0-Cb for behave@ietf.org; Tue, 04 Dec 2007 12:57:10 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id lB4HujU19546; Tue, 4 Dec 2007 09:56:46 -0800 In-Reply-To: <20071204164126.7DABB33C61@delta.rtfm.com> References: <20071203050444.F1C4933C47@delta.rtfm.com> <47547EC8.2010405@cisco.com> <20071203223824.6283E33CA0@delta.rtfm.com> <2CB8FB98-2DEF-4560-AF92-59A8F499198D@magma.ca> <20071204032804.3F6DC33CA0@delta.rtfm.com> <04047175-ED35-4A1A-8570-C22D893EF613@ekabal.com> <20071204062535.25CD033C47@delta.rtfm.com> <20071204164126.7DABB33C61@delta.rtfm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1C2664B1-9F63-433C-8DA2-81C3B74CF675@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-05 Date: Tue, 4 Dec 2007 09:56:44 -0800 To: Eric Rescorla X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Rohan Mahy , Dan Wing , behave@ietf.org, Philip Matthews X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Eric, I think modifying the retransmission timers on a *per-request* basis is architecturally unclean. I have provided some concrete reasons why. You provided no algorithm or basis in theory for deciding how quickly to do a fast retransmit. If you retransmit too fast, you are sending useless data, if you retransmit too slowly, the receiver has to throw away data that it did not have to throw away in the proposal in the draft. Using the mechanism in the draft, all data that arrives can be used. Your proposal works less well than the one in the draft. Therefore I expect you to explain concretely what is so bad about the proposal in the draft, other than asserting that it is "unclean". thanks, -rohan On Dec 4, 2007, at 8:41 AM, Eric Rescorla wrote: > At Tue, 4 Dec 2007 08:16:58 -0800, > Rohan Mahy wrote: >> Modifying the retransmission rules of STUN in TURN does not seem like >> a big win. For one thing, this kind of rules change would make it >> more difficult to use/build an off-the-shelf STUN library. > > Well, I'm pretty familiar with STUN libraries and I don't think > it would make it particularly hard. [0] In particular, I would note > that STUN libraries MUST allow cancellation of transactions > in order to support ICE, and also probably has to support > retransmission limits, and so this functionality can > be supported by cancelling the STUN transaction and starting > a new one. > > >> This seems like a pretty egregious change just to placate a >> philosophical/religious argument: "a form of unclean protocol >> semantics". > > Once again, as I noted, it's worth adding Bind *even* if you > retain Data and Send Indications. > > >> Can you provide some concrete thing on the wire that actually does >> not work with the proposed mechanism in the draft? > > That's the standard I would apply to whether I want to fix a > finished, deployed protocol, not to whether to consider > architectural cleanliness in a new protocol design. > > -Ekr > > [0] And of course, one might ask why it's a fixed point that > TURN needs to use STUN. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 04 13:03:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izc73-0002Lq-B0; Tue, 04 Dec 2007 13:03:17 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Izc72-0002Lf-6w for behave-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 13:03:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izc71-0002LX-Ta for behave@ietf.org; Tue, 04 Dec 2007 13:03:15 -0500 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izc71-0004ZD-J4 for behave@ietf.org; Tue, 04 Dec 2007 13:03:15 -0500 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id lB4I3Cwv021006 for ; Tue, 4 Dec 2007 13:03:12 -0500 (EST) Received: from [192.168.0.182] (s209-121-68-66.bc.hsia.telus.net [209.121.68.66]) (authenticated bits=0) (User authenticated as baford@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id lB4I3AfO024414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 4 Dec 2007 13:03:12 -0500 (EST) Message-Id: <6F9ED451-5763-48BB-83EB-D6F1185D03AE@mit.edu> From: Bryan Ford To: behave@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v915) Date: Tue, 4 Dec 2007 10:03:09 -0800 References: X-Mailer: Apple Mail (2.915) X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [BEHAVE] RE: A simpler way to reduce keepalive traffic (Frank W. Miller) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 W. Miller wrote: > Since I was not able to attend the BoF, could you provide a synopsis > of why > this consensus was arrived at? Specifically, can you describe any > deployment scenarios that were quantitatively presented that have > difficulty > with the "chattiness" you are referring to? I will assume that the > chattiness is primarily a problem for the STUN servers that are > servicing > the keepalives. What kind of data was presented to support this > problem? The minutes don't appear to be on-line yet, but they should be soon, and the presentation slides (at least the version before the presentation - some modifications were made during it) are available on the "meeting materials" page at: https://datatracker.ietf.org/meeting/70/materials.html The biggest motivation seemed to be the drain on the battery power of wireless devices: someone offered the anecdote that he'd observed 50% of the power of some devices go to keepalive transmissions, although I don't remember any "hard" data presented to back this up. Maybe someone else on the list can point to some? Cheers, Bryan _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 04 13:16:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcJP-0007U9-9B; Tue, 04 Dec 2007 13:16:03 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IzcJO-0007ML-2T for behave-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 13:16:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcJN-0007Iw-L6 for behave@ietf.org; Tue, 04 Dec 2007 13:16:01 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzcJN-0001Ex-7a for behave@ietf.org; Tue, 04 Dec 2007 13:16:01 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 04 Dec 2007 10:16:00 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lB4IG03P011645; Tue, 4 Dec 2007 10:16:00 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lB4IFv1l022429; Tue, 4 Dec 2007 18:16:00 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 10:15:59 -0800 Received: from [10.21.122.122] ([10.21.122.122]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 10:15:59 -0800 Message-ID: <47559983.5040701@cisco.com> Date: Tue, 04 Dec 2007 13:16:35 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [BEHAVE] adopt STUN test vectors? References: <04aa01c82c6e$746e4eb0$c4f0200a@cisco.com> <39B65A86-DB33-4FBA-BC2B-CC4C81021ED2@magma.ca> In-Reply-To: <39B65A86-DB33-4FBA-BC2B-CC4C81021ED2@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Dec 2007 18:15:59.0147 (UTC) FILETIME=[B86747B0:01C836A1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1715; t=1196792160; x=1197656160; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20adopt=20STUN=20test=20vectors? |Sender:=20; bh=gBM/LYgfIa6/Bo75wwzk5DtAdW5Rdau8rqdV40Enahk=; b=HWHwcK0g151nOTaiXXKZ+jysPYsX5icvjo7rPTAJ3I8XowHfh7ZrBIZDMikLhWJXWwYhJofh HsKSYV6dNTHgR+Lr5XgDeOpjeSntdLP5oBDh4fgdIC6gLVZ0rQE6uTtaqDU0P/Px13JTuAjZfc XP6wrKj0TsoXOlhQBBNNXY3xA=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 Same here. In this particular case the vectors are small enough, its probably easier to include them as an appendix to rfc3489bis. If the ADs/wg chairs are Ok with that, I would propose to do that. -Jonathan R. Philip Matthews wrote: > I support the idea of published STUN test vectors, either as a separate > document, or as an appendix to 3489bis. > - Philip > > On 21-Nov-07, at 10:43 , Dan Wing wrote: > >> We don't have a milestone for STUN test vectors and it probably falls >> a bit >> outside of the as-written charter, but before we try to change those: is >> there interest in adopting Remi's "Test vectors for RFC3489bis", >> draft-denis-behave-rfc3489bis-test-vectors-02 as a working group item for >> BEHAVE? It's 6 pages, please skim it: >> >> http://www.ietf.org/internet-drafts/draft-denis-behave-rfc3489bis-test-vectors >> >> -02.txt >> >> Before adopting it, I will need to get approval from our ADs to add >> another >> milestone and adjust the charter accordingly. But I wanted to poll >> first to >> see if we should try doing that. >> >> Thanks, >> -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 > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 04 13:19:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcMt-00012w-Fk; Tue, 04 Dec 2007 13:19:39 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IzcMs-00011G-Hj for behave-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 13:19:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcMr-0000zW-Sb; Tue, 04 Dec 2007 13:19:37 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzcMq-0001bv-T8; Tue, 04 Dec 2007 13:19:37 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 04 Dec 2007 10:19:36 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB4IJaOn028877; Tue, 4 Dec 2007 10:19:36 -0800 Received: from dwingwxp01 (sjc-vpn6-1855.cisco.com [10.21.127.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lB4IJVqZ005888; Tue, 4 Dec 2007 18:19:31 GMT From: "Dan Wing" To: "'Bryan Ford'" , References: <6F9ED451-5763-48BB-83EB-D6F1185D03AE@mit.edu> Date: Tue, 4 Dec 2007 10:19:31 -0800 Message-ID: <161001c836a2$39ac1580$4e76150a@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: Acg2n/W0r9ybHby5QUeIQ1OQPE1GsgAAY/vw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <6F9ED451-5763-48BB-83EB-D6F1185D03AE@mit.edu> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3072; t=1196792376; x=1197656376; 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:=20keepalive=20battery=20consumption |Sender:=20; bh=UMappAapIDA4YLRiB0Ze3ngeCmhspJGyH1jIzlr55ZE=; b=h7cw6eqDFlbbYcyU6EYhEZDIGUdaweh7pjqOIyZtJed58Y4lXQT8muicLihsn84qEE9jyjma x3Ux/oT4KOmdy9z4VboLYmzNuOOC2ix+ONisHU7vyMfx+9qEGltnrxFg; 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: 0fa76816851382eb71b0a882ccdc29ac Cc: safe@ietf.org, Pasi.Eronen@nokia.com Subject: [BEHAVE] keepalive battery consumption X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org (I am CC'ing the SAFE mailing list, as the motivation for reducing keepalives came up during SAFE.) Citation: http://tinyurl.com/3c63ef [IEEE] "Energy Consumption of Always-On Applications in WCDMA Networks" Haverinen, H.; Siren, J.; Eronen, P. Vehicular Technology Conference, 2007. VTC2007-Spring. IEEE 65th Volume , Issue , 22-25 April 2007 Page(s):964 - 968 Digital Object Identifier 10.1109/VETECS.2007.207 Summary: Always-on applications, such as push email and voice-over-IP, are characterized by the need to be constantly reachable for incoming communications. In the presence of stateful firewalls or NATs, such applications require "keep-alive" messages to maintain up-to-date connection state in the firewall or NAT, and thus preserve reachability. In this paper, we analyze how these keep-alive messages influence battery lifetime in WCDMA networks. Using measurements in a 3G network, we show that the energy consumption is significantly influenced by the radio resource control (RRC) parameters and the frequency of keep-alive messages. The results suggest that especially UDP-based protocols, such as mobile IPv4 and IPsec NAT traversal mechanisms, require very frequent keep-alives that can lead to unacceptably short battery lifetimes." I expect we can find a way for the paper to be made available to non-IEEE members. Pasi? -d > -----Original Message----- > From: Bryan Ford [mailto:baford@MIT.EDU] > Sent: Tuesday, December 04, 2007 10:03 AM > To: behave@ietf.org > Subject: [BEHAVE] RE: A simpler way to reduce keepalive > traffic (Frank W.Miller) > > Frank W. Miller wrote: > > Since I was not able to attend the BoF, could you provide a > synopsis > > of why > > this consensus was arrived at? Specifically, can you describe any > > deployment scenarios that were quantitatively presented that have > > difficulty > > with the "chattiness" you are referring to? I will assume that the > > chattiness is primarily a problem for the STUN servers that are > > servicing > > the keepalives. What kind of data was presented to support this > > problem? > > The minutes don't appear to be on-line yet, but they should be soon, > and the presentation slides (at least the version before the > presentation - some modifications were made during it) are available > on the "meeting materials" page at: > https://datatracker.ietf.org/meeting/70/materials.html > > The biggest motivation seemed to be the drain on the battery > power of > wireless devices: someone offered the anecdote that he'd > observed 50% > of the power of some devices go to keepalive transmissions, > although I > don't remember any "hard" data presented to back this up. Maybe > someone else on the list can point to some? > > Cheers, > Bryan > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 04 13:38:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izced-0005mT-6I; Tue, 04 Dec 2007 13:37:59 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Izcec-0005lW-9U for behave-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 13:37:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izceb-0005lG-Up for behave@ietf.org; Tue, 04 Dec 2007 13:37:57 -0500 Received: from dhcp-11b6.ietf70.org ([130.129.17.182] helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izceb-0003H2-Gl for behave@ietf.org; Tue, 04 Dec 2007 13:37:57 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 428E033C61; Tue, 4 Dec 2007 10:32:38 -0800 (PST) Date: Tue, 04 Dec 2007 10:32:38 -0800 From: Eric Rescorla To: Rohan Mahy Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-05 In-Reply-To: <1C2664B1-9F63-433C-8DA2-81C3B74CF675@ekabal.com> References: <20071203050444.F1C4933C47@delta.rtfm.com> <47547EC8.2010405@cisco.com> <20071203223824.6283E33CA0@delta.rtfm.com> <2CB8FB98-2DEF-4560-AF92-59A8F499198D@magma.ca> <20071204032804.3F6DC33CA0@delta.rtfm.com> <04047175-ED35-4A1A-8570-C22D893EF613@ekabal.com> <20071204062535.25CD033C47@delta.rtfm.com> <20071204164126.7DABB33C61@delta.rtfm.com> <1C2664B1-9F63-433C-8DA2-81C3B74CF675@ekabal.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071204183238.428E033C61@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Dan Wing , behave@ietf.org, Philip Matthews X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org At Tue, 4 Dec 2007 09:56:44 -0800, Rohan Mahy wrote: > I think modifying the retransmission timers on a *per-request* basis > is architecturally unclean. I have provided some concrete reasons > why. You provided no algorithm or basis in theory for deciding how > quickly to do a fast retransmit. If you retransmit too fast, you are > sending useless data, if you retransmit too slowly, the receiver has > to throw away data that it did not have to throw away in the proposal > in the draft. Using the mechanism in the draft, all data that > arrives can be used. > > Your proposal works less well than the one in the draft. Therefore I > expect you to explain concretely what is so bad about the proposal in > the draft, other than asserting that it is "unclean". For the third time now, there are two separate issues: 1. Whether the Send Indication should as a side effect establish the channel. 2. Whether there should be a Send Indication to allow data to be transmitted prior to the establishment of a channel. I think that using Send Indication having as a side effect establishing the channel is pretty clearly architecturally unclean. There should be a separate Bind. Having a separate Bind *with a Send Indication* has exactly the same packet loss characteristics as the current design. This brings us to the second issue, namely, once there is a distinct Bind command, should there be a Send Indication at all. As I observed in my review, I think this is of fairly marginal value. If there is significant packet loss on the route to the TURN server, then the system isn't really going to work at all, and so the risk of losing media packets during the retransmit interval *if* the Bind is lost. I could be wrong about this, of course, but I'd be interested to understand what you think the network flow model it is that makes this feature important. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 04 14:43:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izdfm-0007Cq-DS; Tue, 04 Dec 2007 14:43:14 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Izdfl-0007CV-27 for behave-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 14:43:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izdfk-0007CK-NU for behave@ietf.org; Tue, 04 Dec 2007 14:43:12 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izdfj-0000k4-Qw for behave@ietf.org; Tue, 04 Dec 2007 14:43:12 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id lB4JfmU23785; Tue, 4 Dec 2007 11:41:49 -0800 In-Reply-To: <20071204183238.428E033C61@delta.rtfm.com> References: <20071203050444.F1C4933C47@delta.rtfm.com> <47547EC8.2010405@cisco.com> <20071203223824.6283E33CA0@delta.rtfm.com> <2CB8FB98-2DEF-4560-AF92-59A8F499198D@magma.ca> <20071204032804.3F6DC33CA0@delta.rtfm.com> <04047175-ED35-4A1A-8570-C22D893EF613@ekabal.com> <20071204062535.25CD033C47@delta.rtfm.com> <20071204164126.7DABB33C61@delta.rtfm.com> <1C2664B1-9F63-433C-8DA2-81C3B74CF675@ekabal.com> <20071204183238.428E033C61@delta.rtfm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <165B0E14-3FB1-4069-9D23-1B0E1AFE5430@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-05 Date: Tue, 4 Dec 2007 11:41:48 -0800 To: Eric Rescorla X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Rohan Mahy , Dan Wing , behave@ietf.org, Philip Matthews X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Eric, You have not addressed any of my questions. How do you pick the value of the retransmit timer? Without a good basis for the timer, the behavior under your proposal would be brittle. More comments inline. On Dec 4, 2007, at 10:32 AM, Eric Rescorla wrote: > At Tue, 4 Dec 2007 09:56:44 -0800, > Rohan Mahy wrote: >> I think modifying the retransmission timers on a *per-request* basis >> is architecturally unclean. I have provided some concrete reasons >> why. You provided no algorithm or basis in theory for deciding how >> quickly to do a fast retransmit. If you retransmit too fast, you are >> sending useless data, if you retransmit too slowly, the receiver has >> to throw away data that it did not have to throw away in the proposal >> in the draft. Using the mechanism in the draft, all data that >> arrives can be used. >> >> Your proposal works less well than the one in the draft. Therefore I >> expect you to explain concretely what is so bad about the proposal in >> the draft, other than asserting that it is "unclean". > > For the third time now, there are two separate issues: > > 1. Whether the Send Indication should as a side effect establish > the channel. > > 2. Whether there should be a Send Indication to allow data to be > transmitted prior to the establishment of a channel. > I think that using Send Indication having as a side effect > establishing > the channel is pretty clearly architecturally unclean. There should > be a separate Bind. What bad thing happens if we perform these two operations (sending data and establishing a channel) in one message? My analysis is that nothing bad happens. All other things being equal (if you had a proposal which worked as well), I would be inclined to agree with you. However, in the absence of such a proposal, your comment is pretty academic and not a compelling reason to change the document. > Having a separate Bind *with a Send Indication* > has exactly the same packet loss characteristics as the current > design. Please reread my previous mail and envision the case of the TURN client sending video to a non-ICE peer. Assume that the first packet containing a Bind is dropped. These don't have the same properties. > This brings us to the second issue, namely, once there is a distinct > Bind command, should there be a Send Indication at all. As I observed > in my review, I think this is of fairly marginal value. The WG strongly disagrees with you, and has on multiple occasions confirmed that decision. > If there > is significant packet loss on the route to the TURN server, then > the system isn't really going to work at all, and so the risk of > losing media packets during the retransmit interval *if* the > Bind is lost. I could be wrong about this, of course, but I'd > be interested to understand what you think the network flow model > it is that makes this feature important. The network flow model is making the TURN server look similar from a traffic delivery perspective to a NAT. Preventing a traffic from being delivered until a binding is established is a significant divergence from that fundamental principle. thanks, -rohan _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 04 14:54:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izdr0-0002PO-UH; Tue, 04 Dec 2007 14:54:50 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Izdr0-0002MP-0V for behave-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 14:54:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izdqz-0002M6-MA; Tue, 04 Dec 2007 14:54:49 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izdqz-0001bq-7f; Tue, 04 Dec 2007 14:54:49 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lB4JsFjI000908; Tue, 4 Dec 2007 21:54:27 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 21:53:56 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 21:53:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Dec 2007 21:53:55 +0200 Message-ID: In-Reply-To: <161001c836a2$39ac1580$4e76150a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: keepalive battery consumption Thread-Index: Acg2n/W0r9ybHby5QUeIQ1OQPE1GsgAAY/vwAANngoA= References: <6F9ED451-5763-48BB-83EB-D6F1185D03AE@mit.edu> <161001c836a2$39ac1580$4e76150a@cisco.com> From: To: , , X-OriginalArrivalTime: 04 Dec 2007 19:53:56.0094 (UTC) FILETIME=[675639E0:01C836AF] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: safe@ietf.org Subject: [BEHAVE] RE: keepalive battery consumption X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 expect we can find a way for the paper to be made available=20 > to non-IEEE members. Pasi? The PDF is also on my home page: http://www.iki.fi/pe/publications/ Best regards, Pasi=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 04 16:57:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izflc-0006px-GC; Tue, 04 Dec 2007 16:57:24 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Izfla-0006lx-NX for behave-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 16:57:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzflZ-0006kz-W4 for behave@ietf.org; Tue, 04 Dec 2007 16:57:21 -0500 Received: from dhcp-11b6.ietf70.org ([130.129.17.182] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzflX-00078Y-Jz for behave@ietf.org; Tue, 04 Dec 2007 16:57:21 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 5404033C47; Tue, 4 Dec 2007 13:51:58 -0800 (PST) Date: Tue, 04 Dec 2007 13:51:58 -0800 From: Eric Rescorla To: Rohan Mahy Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-05 In-Reply-To: <165B0E14-3FB1-4069-9D23-1B0E1AFE5430@ekabal.com> References: <20071203050444.F1C4933C47@delta.rtfm.com> <47547EC8.2010405@cisco.com> <20071203223824.6283E33CA0@delta.rtfm.com> <2CB8FB98-2DEF-4560-AF92-59A8F499198D@magma.ca> <20071204032804.3F6DC33CA0@delta.rtfm.com> <04047175-ED35-4A1A-8570-C22D893EF613@ekabal.com> <20071204062535.25CD033C47@delta.rtfm.com> <20071204164126.7DABB33C61@delta.rtfm.com> <1C2664B1-9F63-433C-8DA2-81C3B74CF675@ekabal.com> <20071204183238.428E033C61@delta.rtfm.com> <165B0E14-3FB1-4069-9D23-1B0E1AFE5430@ekabal.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071204215158.5404033C47@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: Dan Wing , behave@ietf.org, Philip Matthews X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org At Tue, 4 Dec 2007 11:41:48 -0800, Rohan Mahy wrote: > You have not addressed any of my questions. Well, I've been trying to, but it seems that we're talking past each other. > How do you pick the > value of the retransmit timer? I was suggesting basing it on the packet rate. I.e., every X packets you would abort the current STUN transaction (if any) and start a new one. Picking X would require some analysis of the maximum number of packets you were willing to lose compared to the probability of packet loss (see below for a very cursory analysis.) > On Dec 4, 2007, at 10:32 AM, Eric Rescorla wrote: > > At Tue, 4 Dec 2007 09:56:44 -0800, > > Rohan Mahy wrote: > >> I think modifying the retransmission timers on a *per-request* basis > >> is architecturally unclean. I have provided some concrete reasons > >> why. You provided no algorithm or basis in theory for deciding how > >> quickly to do a fast retransmit. If you retransmit too fast, you are > >> sending useless data, if you retransmit too slowly, the receiver has > >> to throw away data that it did not have to throw away in the proposal > >> in the draft. Using the mechanism in the draft, all data that > >> arrives can be used. > >> > >> Your proposal works less well than the one in the draft. Therefore I > >> expect you to explain concretely what is so bad about the proposal in > >> the draft, other than asserting that it is "unclean". > > > > For the third time now, there are two separate issues: > > > > 1. Whether the Send Indication should as a side effect establish > > the channel. > > > > 2. Whether there should be a Send Indication to allow data to be > > transmitted prior to the establishment of a channel. > > > I think that using Send Indication having as a side effect > > establishing > > the channel is pretty clearly architecturally unclean. There should > > be a separate Bind. > > What bad thing happens if we perform these two operations (sending > data and establishing a channel) in one message? My analysis is that > nothing bad happens. > > All other things being equal (if you had a proposal which worked as > well), I would be inclined to agree with you. However, in the absence > of such a proposal, your comment is pretty academic and not a > compelling reason to change the document. Actually, I think at least one of the variants I proposed *does* work as well. > > Having a separate Bind *with a Send Indication* > > has exactly the same packet loss characteristics as the current > > design. > > Please reread my previous mail and envision the case of the TURN > client sending video to a non-ICE peer. Assume that the first packet > containing a Bind is dropped. > > These don't have the same properties. Well, as I've been trying to explain, I suggested two separate things. For clarity, here's what I was proposing under (1). 1. The client sends data under Data Indications. 2. The server sends data under Send Indications. 3. At any time, the client can issue a Bind which requests that a given 5-tuple be a given channel. 4. On receipt of the Bind, the server can send unencapsulated. 5. On receipt of the OK from the Bind, the client can send unencapsulated. I.e., Client Server ------ ------ ALLOCATE -> <- OK <- Data Indication Send Indication -> Bind -> <- Unencapsulated Data <- OK Unencapsulated Data -> Do you agree that this has the same properties as the current draft? If not, can you please explain why in detail? Why do I think this is an improvement? Because it has explicit semantics for the transition between encapsulated an unencapsulated mode, which is architecturally cleaner. It also has the nice side effect that each 5-tuple only corresponds to one channel, but this is a minor convenience for implementors. Now, let's turn to my point (2) from my previous message, which suggested the same scheme as I just described with the removal of point (1). I.e., you would need to Bind before sending unencapsulated data. Yes, it's absolutely true that if you remove Data indication *and* the Bind is lost, some packets will be lost. It's quite straightforward to minimize this loss by adapting the rate at which you send Binds to match the rate at which you send packets. I.e., if you send Binds every R frames and your overall packet loss probability is L, then the mean number of lost packets is given by: inf ---- \ i > R * L / ---- i = 1 Using standard formulas, this sum gives R/(1-L). So, if, for instance, you have a packet loss rate of .1 (which is fairly severe) and you're willing to transmit a Bind for every 10 packets (10% overhead) then you will on average lose one packet, which seems pretty modest, especially when you consider that you will on average lose 10% of the data packets during the entire life of the connection. > > This brings us to the second issue, namely, once there is a distinct > > Bind command, should there be a Send Indication at all. As I observed > > in my review, I think this is of fairly marginal value. > > The WG strongly disagrees with you, and has on multiple occasions > confirmed that decision. Hmm... I don't recall these, but if you can point me to some of those occasions, I'll be happy to review the discussion. Best, -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 04 17:17:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izg4r-00016M-Vx; Tue, 04 Dec 2007 17:17:18 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Izg4q-00010d-7p for behave-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 17:17:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izg4p-0000xH-R9 for behave@ietf.org; Tue, 04 Dec 2007 17:17:15 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izg4o-0003za-Rf for behave@ietf.org; Tue, 04 Dec 2007 17:17:15 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id lB4MGuU29500; Tue, 4 Dec 2007 14:16:57 -0800 In-Reply-To: <20071204215158.5404033C47@delta.rtfm.com> References: <20071203050444.F1C4933C47@delta.rtfm.com> <47547EC8.2010405@cisco.com> <20071203223824.6283E33CA0@delta.rtfm.com> <2CB8FB98-2DEF-4560-AF92-59A8F499198D@magma.ca> <20071204032804.3F6DC33CA0@delta.rtfm.com> <04047175-ED35-4A1A-8570-C22D893EF613@ekabal.com> <20071204062535.25CD033C47@delta.rtfm.com> <20071204164126.7DABB33C61@delta.rtfm.com> <1C2664B1-9F63-433C-8DA2-81C3B74CF675@ekabal.com> <20071204183238.428E033C61@delta.rtfm.com> <165B0E14-3FB1-4069-9D23-1B0E1AFE5430@ekabal.com> <20071204215158.5404033C47@delta.rtfm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <43D5E4B5-3404-4022-B8DB-35A220876A1D@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-05 Date: Tue, 4 Dec 2007 14:16:56 -0800 To: Eric Rescorla X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: Rohan Mahy , Dan Wing , behave@ietf.org, Philip Matthews X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi Eric, I now realize that you intend the binding to be bidirectional. Currently the channel numbers are asymmetric. The reason is that the UAC can Sent to and create a binding for one target IP address and port, which creates a permission for the entire target IP address, and then receive data from a different port number (or numbers) than expected. The UAC needs to detect this and use different channel numbers for these. JDR has slide on this today. thanks, -rohan On Dec 4, 2007, at 1:51 PM, Eric Rescorla wrote: > At Tue, 4 Dec 2007 11:41:48 -0800, > Rohan Mahy wrote: >> You have not addressed any of my questions. > > Well, I've been trying to, but it seems that we're talking past each > other. > > >> How do you pick the >> value of the retransmit timer? > > I was suggesting basing it on the packet rate. I.e., every X packets > you would abort the current STUN transaction (if any) and start a new > one. Picking X would require some analysis of the maximum number of > packets you were willing to lose compared to the probability of packet > loss (see below for a very cursory analysis.) > > >> On Dec 4, 2007, at 10:32 AM, Eric Rescorla wrote: >>> At Tue, 4 Dec 2007 09:56:44 -0800, >>> Rohan Mahy wrote: >>>> I think modifying the retransmission timers on a *per-request* >>>> basis >>>> is architecturally unclean. I have provided some concrete reasons >>>> why. You provided no algorithm or basis in theory for deciding how >>>> quickly to do a fast retransmit. If you retransmit too fast, >>>> you are >>>> sending useless data, if you retransmit too slowly, the receiver >>>> has >>>> to throw away data that it did not have to throw away in the >>>> proposal >>>> in the draft. Using the mechanism in the draft, all data that >>>> arrives can be used. >>>> >>>> Your proposal works less well than the one in the draft. >>>> Therefore I >>>> expect you to explain concretely what is so bad about the >>>> proposal in >>>> the draft, other than asserting that it is "unclean". >>> >>> For the third time now, there are two separate issues: >>> >>> 1. Whether the Send Indication should as a side effect establish >>> the channel. >>> >>> 2. Whether there should be a Send Indication to allow data to be >>> transmitted prior to the establishment of a channel. >> >>> I think that using Send Indication having as a side effect >>> establishing >>> the channel is pretty clearly architecturally unclean. There should >>> be a separate Bind. >> >> What bad thing happens if we perform these two operations (sending >> data and establishing a channel) in one message? My analysis is that >> nothing bad happens. >> >> All other things being equal (if you had a proposal which worked as >> well), I would be inclined to agree with you. However, in the absence >> of such a proposal, your comment is pretty academic and not a >> compelling reason to change the document. > > Actually, I think at least one of the variants I proposed *does* > work as well. > > >>> Having a separate Bind *with a Send Indication* >>> has exactly the same packet loss characteristics as the current >>> design. >> >> Please reread my previous mail and envision the case of the TURN >> client sending video to a non-ICE peer. Assume that the first packet >> containing a Bind is dropped. >> >> These don't have the same properties. > > Well, as I've been trying to explain, I suggested two separate > things. > > For clarity, here's what I was proposing under (1). > > 1. The client sends data under Data Indications. > 2. The server sends data under Send Indications. > 3. At any time, the client can issue a Bind which requests that > a given 5-tuple be a given channel. > 4. On receipt of the Bind, the server can send unencapsulated. > 5. On receipt of the OK from the Bind, the client can send > unencapsulated. > > I.e., > > Client Server > ------ ------ > ALLOCATE -> > <- OK > <- Data Indication > Send Indication -> > Bind -> > <- Unencapsulated Data > <- OK > Unencapsulated Data -> > > > Do you agree that this has the same properties as > the current draft? If not, can you please explain why in > detail? > > Why do I think this is an improvement? Because it has explicit > semantics for the transition between encapsulated an unencapsulated > mode, which is architecturally cleaner. It also has the nice side > effect that each 5-tuple only corresponds to one channel, but this > is a minor convenience for implementors. > > > Now, let's turn to my point (2) from my previous message, which > suggested the same scheme as I just described with the removal of > point (1). I.e., you would need to Bind before sending unencapsulated > data. > > Yes, it's absolutely true that if you remove Data indication *and* the > Bind is lost, some packets will be lost. It's quite straightforward to > minimize this loss by adapting the rate at which you send Binds to > match the rate at which you send packets. I.e., if you send Binds > every R frames and your overall packet loss probability is L, then the > mean number of lost packets is given by: > > inf > ---- > \ i >> R * L > / > ---- > i = 1 > > > Using standard formulas, this sum gives R/(1-L). > > So, if, for instance, you have a packet loss rate of .1 (which is > fairly severe) and you're willing to transmit a Bind for every 10 > packets (10% overhead) then you will on average lose one packet, which > seems pretty modest, especially when you consider that you will on > average lose 10% of the data packets during the entire life of > the connection. > > >>> This brings us to the second issue, namely, once there is a distinct >>> Bind command, should there be a Send Indication at all. As I >>> observed >>> in my review, I think this is of fairly marginal value. >> >> The WG strongly disagrees with you, and has on multiple occasions >> confirmed that decision. > > Hmm... I don't recall these, but if you can point me to some of those > occasions, I'll be happy to review the discussion. > > Best, > -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 04 17:20:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izg7i-0004yW-Na; Tue, 04 Dec 2007 17:20:14 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Izg7i-0004yO-Ac for behave-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 17:20:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izg7i-0004yE-19 for behave@ietf.org; Tue, 04 Dec 2007 17:20:14 -0500 Received: from dhcp-11b6.ietf70.org ([130.129.17.182] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izg7h-0000ay-Oh for behave@ietf.org; Tue, 04 Dec 2007 17:20:14 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id C132D33C47; Tue, 4 Dec 2007 14:14:52 -0800 (PST) Date: Tue, 04 Dec 2007 14:14:52 -0800 From: Eric Rescorla To: Rohan Mahy Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-05 In-Reply-To: <43D5E4B5-3404-4022-B8DB-35A220876A1D@ekabal.com> References: <20071203050444.F1C4933C47@delta.rtfm.com> <47547EC8.2010405@cisco.com> <20071203223824.6283E33CA0@delta.rtfm.com> <2CB8FB98-2DEF-4560-AF92-59A8F499198D@magma.ca> <20071204032804.3F6DC33CA0@delta.rtfm.com> <04047175-ED35-4A1A-8570-C22D893EF613@ekabal.com> <20071204062535.25CD033C47@delta.rtfm.com> <20071204164126.7DABB33C61@delta.rtfm.com> <1C2664B1-9F63-433C-8DA2-81C3B74CF675@ekabal.com> <20071204183238.428E033C61@delta.rtfm.com> <165B0E14-3FB1-4069-9D23-1B0E1AFE5430@ekabal.com> <20071204215158.5404033C47@delta.rtfm.com> <43D5E4B5-3404-4022-B8DB-35A220876A1D@ekabal.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071204221452.C132D33C47@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Dan Wing , behave@ietf.org, Philip Matthews X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org At Tue, 4 Dec 2007 14:16:56 -0800, Rohan Mahy wrote: > I now realize that you intend the binding to be bidirectional. > Currently the channel numbers are asymmetric. The reason is that the > UAC can Sent to and create a binding for one target IP address and > port, which creates a permission for the entire target IP address, > and then receive data from a different port number (or numbers) than > expected. The UAC needs to detect this and use different channel > numbers for these. > > JDR has slide on this today. Ah. Well, now I see why were talking past each other. Thanks for the clarification. That said, I think that what I suggested would, with the appropriate rules, work in that situation, but I'll be happy to explain that when JDR shows his slides. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 04 19:04:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izhko-0000hK-2P; Tue, 04 Dec 2007 19:04:42 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Izhkn-0000h5-1F for behave-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 19:04:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izhkm-0000gx-MM for behave@ietf.org; Tue, 04 Dec 2007 19:04:40 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izhkm-0004wt-7z for behave@ietf.org; Tue, 04 Dec 2007 19:04:40 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 04 Dec 2007 16:04:39 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lB504ddg016892; Tue, 4 Dec 2007 16:04:39 -0800 Received: from [130.129.86.243] (sjc-vpn6-1261.cisco.com [10.21.124.237]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lB504d1f005956; Wed, 5 Dec 2007 00:04:39 GMT In-Reply-To: <47559983.5040701@cisco.com> References: <04aa01c82c6e$746e4eb0$c4f0200a@cisco.com> <39B65A86-DB33-4FBA-BC2B-CC4C81021ED2@magma.ca> <47559983.5040701@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8B9DC0A3-65DD-437A-B666-AA0965921793@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] adopt STUN test vectors? Date: Tue, 4 Dec 2007 16:04:31 -0800 To: Philip Matthews X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2092; t=1196813079; x=1197677079; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20adopt=20STUN=20test=20vectors? |Sender:=20; bh=V8k7nZumjurvGlEEFkIa79atnrCqXtaWqz+brYIRjm0=; b=oXWe0jGshMDrAgZLdStiw90H04wYjQwTuttUqtWr2wCCsAGRhOvlTLr8XgcbPoLxVGq5pa/T pifqyfrO1QMSu+byh5Waj/My90s4Hu0Lw250wcQb2DbkuszZVpujwmzA; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 Do we have (or can we get) independent verification they are correct? Cullen On Dec 4, 2007, at 10:16 AM, Jonathan Rosenberg wrote: > Same here. In this particular case the vectors are small enough, > its probably easier to include them as an appendix to rfc3489bis. > If the ADs/wg chairs are Ok with that, I would propose to do that. > > -Jonathan R. > > Philip Matthews wrote: >> I support the idea of published STUN test vectors, either as a >> separate document, or as an appendix to 3489bis. >> - Philip >> On 21-Nov-07, at 10:43 , Dan Wing wrote: >>> We don't have a milestone for STUN test vectors and it probably >>> falls a bit >>> outside of the as-written charter, but before we try to change >>> those: is >>> there interest in adopting Remi's "Test vectors for RFC3489bis", >>> draft-denis-behave-rfc3489bis-test-vectors-02 as a working group >>> item for >>> BEHAVE? It's 6 pages, please skim it: >>> >>> http://www.ietf.org/internet-drafts/draft-denis-behave-rfc3489bis- >>> test-vectors >>> -02.txt >>> >>> Before adopting it, I will need to get approval from our ADs to >>> add another >>> milestone and adjust the charter accordingly. But I wanted to >>> poll first to >>> see if we should try doing that. >>> >>> Thanks, >>> -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 > > -- > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 04 19:07:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izhnm-0003W5-Pn; Tue, 04 Dec 2007 19:07:46 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Izhnl-0003Sr-8l for behave-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 19:07:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izhnk-0003Sf-UW for behave@ietf.org; Tue, 04 Dec 2007 19:07:44 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izhnk-00057u-DC for behave@ietf.org; Tue, 04 Dec 2007 19:07:44 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lB507LZq028479; Wed, 5 Dec 2007 02:07:42 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 02:07:28 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 02:07:27 +0200 Received: from [10.241.58.77] (daec-linuxvpn05877.americas.nokia.com [10.241.58.77]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lB507PGv014533; Wed, 5 Dec 2007 02:07:26 +0200 Subject: Re: [BEHAVE] RE: A simpler way to reduce keepalive traffic (Frank W. Miller) From: Aki Niemi To: ext Bryan Ford In-Reply-To: <6F9ED451-5763-48BB-83EB-D6F1185D03AE@mit.edu> References: <6F9ED451-5763-48BB-83EB-D6F1185D03AE@mit.edu> Content-Type: text/plain Organization: Nokia-TP-MSW/Helsinki Date: Tue, 04 Dec 2007 16:08:04 -0800 Message-Id: <1196813284.30557.12.camel@scotty> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Dec 2007 00:07:27.0979 (UTC) FILETIME=[D253ABB0:01C836D2] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 ti, 2007-12-04 kello 10:03 -0800, ext Bryan Ford kirjoitti: > The biggest motivation seemed to be the drain on the battery power of > wireless devices: someone offered the anecdote that he'd observed 50% > of the power of some devices go to keepalive transmissions, although I > don't remember any "hard" data presented to back this up. Maybe > someone else on the list can point to some? The paper I was (mainly) referring to at the mike was this one from Henry Haverinen, Jonne Siren and Pasi Eronen: http://www.niksula.hut.fi/~peronen/publications/haverinen_siren_eronen_vtc2007.pdf Cheers, Aki _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 04 19:24:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izi3w-0007Hf-JE; Tue, 04 Dec 2007 19:24:28 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Izi3v-0007HM-7p for behave-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 19:24:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izi3u-0007HD-UR for behave@ietf.org; Tue, 04 Dec 2007 19:24:26 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izi3t-0002Ly-If for behave@ietf.org; Tue, 04 Dec 2007 19:24:26 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lB50OZC4025660 for ; Tue, 4 Dec 2007 18:24:38 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 02:24:20 +0200 Received: from essapo-nirac25314.europe.nokia.com ([10.162.253.14]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 02:24:20 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] adopt STUN test vectors? Date: Wed, 5 Dec 2007 02:24:18 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <04aa01c82c6e$746e4eb0$c4f0200a@cisco.com> <47559983.5040701@cisco.com> <8B9DC0A3-65DD-437A-B666-AA0965921793@cisco.com> In-Reply-To: <8B9DC0A3-65DD-437A-B666-AA0965921793@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200712050224.19093.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 05 Dec 2007 00:24:20.0468 (UTC) FILETIME=[2DD13B40:01C836D5] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Le Wednesday 05 December 2007 02:04:31 ext Cullen Jennings, vous avez =E9cr= it=A0: > Do we have (or can we get) independent verification they are correct? I did receive a few comments from other implementors that they work for=20 them... but but, I guess you're asking for them to post here by themselves. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 04 19:29:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izi8h-0006XF-Vz; Tue, 04 Dec 2007 19:29:23 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Izi8g-0006Ua-Vj for behave-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 19:29:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izi8g-0006Tf-Lo for behave@ietf.org; Tue, 04 Dec 2007 19:29:22 -0500 Received: from oe8.briank.com ([198.144.201.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izi8f-0002dk-Sw for behave@ietf.org; Tue, 04 Dec 2007 19:29:22 -0500 Received: from [192.168.255.18] (sol-ethernet.local.briank.com [192.168.255.18]) by oe8.briank.com (8.13.7/8.12.3) with ESMTP id lB50QOcV014048; Tue, 4 Dec 2007 16:26:24 -0800 (PST) (envelope-from briank@briank.com) In-Reply-To: <8B9DC0A3-65DD-437A-B666-AA0965921793@cisco.com> References: <04aa01c82c6e$746e4eb0$c4f0200a@cisco.com> <39B65A86-DB33-4FBA-BC2B-CC4C81021ED2@magma.ca> <47559983.5040701@cisco.com> <8B9DC0A3-65DD-437A-B666-AA0965921793@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <597BD775-C322-4C92-88C5-BB2B81EBCF2F@briank.com> Content-Transfer-Encoding: 7bit From: Brian Korver Subject: Re: [BEHAVE] adopt STUN test vectors? Date: Tue, 4 Dec 2007 16:26:01 -0800 To: Cullen Jennings X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Behave WG , Philip Matthews X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org They worked with my implementation. -brian briank@briank.com On Dec 4, 2007, at 4:04 PM, Cullen Jennings wrote: > > Do we have (or can we get) independent verification they are correct? > > Cullen > > On Dec 4, 2007, at 10:16 AM, Jonathan Rosenberg wrote: > >> Same here. In this particular case the vectors are small enough, >> its probably easier to include them as an appendix to rfc3489bis. >> If the ADs/wg chairs are Ok with that, I would propose to do that. >> >> -Jonathan R. >> >> Philip Matthews wrote: >>> I support the idea of published STUN test vectors, either as a >>> separate document, or as an appendix to 3489bis. >>> - Philip >>> On 21-Nov-07, at 10:43 , Dan Wing wrote: >>>> We don't have a milestone for STUN test vectors and it probably >>>> falls a bit >>>> outside of the as-written charter, but before we try to change >>>> those: is >>>> there interest in adopting Remi's "Test vectors for RFC3489bis", >>>> draft-denis-behave-rfc3489bis-test-vectors-02 as a working group >>>> item for >>>> BEHAVE? It's 6 pages, please skim it: >>>> >>>> http://www.ietf.org/internet-drafts/draft-denis-behave- >>>> rfc3489bis-test-vectors >>>> -02.txt >>>> >>>> Before adopting it, I will need to get approval from our ADs to >>>> add another >>>> milestone and adjust the charter accordingly. But I wanted to >>>> poll first to >>>> see if we should try doing that. >>>> >>>> Thanks, >>>> -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 >> >> -- >> Jonathan D. Rosenberg, Ph.D. 499 Thornall St. >> Cisco Fellow Edison, NJ 08837 >> Cisco, Voice Technology Group >> jdrosen@cisco.com >> http://www.jdrosen.net PHONE: (408) 902-3084 >> http://www.cisco.com >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 04 19:41:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IziKL-0004cW-8l; Tue, 04 Dec 2007 19:41:25 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1IziKK-0004cO-Ea for behave-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 19:41:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IziKK-0004cF-4Q for behave@ietf.org; Tue, 04 Dec 2007 19:41:24 -0500 Received: from submit01.sysedata.no ([195.159.29.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IziKJ-0006uu-Pw for behave@ietf.org; Tue, 04 Dec 2007 19:41:24 -0500 Received: from [84.215.127.238] (helo=[10.0.0.4]) by submit01.sysedata.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.62) (envelope-from ) id 1IziKF-0001uO-Qr; Wed, 05 Dec 2007 01:41:19 +0100 Message-ID: <4755F3AF.10704@db.org> Date: Wed, 05 Dec 2007 01:41:19 +0100 From: "Alfred E. Heggestad" User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [BEHAVE] adopt STUN test vectors? References: <04aa01c82c6e$746e4eb0$c4f0200a@cisco.com> <39B65A86-DB33-4FBA-BC2B-CC4C81021ED2@magma.ca> <47559983.5040701@cisco.com> <8B9DC0A3-65DD-437A-B666-AA0965921793@cisco.com> In-Reply-To: <8B9DC0A3-65DD-437A-B666-AA0965921793@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Behave WG , Philip Matthews X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Cullen Jennings wrote: > > Do we have (or can we get) independent verification they are correct? > I have implemented the test-vectors in regression tests, and they seem to work ok. /alfred _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 04 20:11:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izin4-00012b-LU; Tue, 04 Dec 2007 20:11:06 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Izin2-0000s5-GC for behave-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 20:11:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izin2-0000qq-3K for behave@ietf.org; Tue, 04 Dec 2007 20:11:04 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izin1-0000El-QF for behave@ietf.org; Tue, 04 Dec 2007 20:11:04 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 04 Dec 2007 17:11:01 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB51B1Hj017868; Tue, 4 Dec 2007 17:11:01 -0800 Received: from [130.129.86.243] ([10.21.70.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lB51B075020131; Wed, 5 Dec 2007 01:11:01 GMT In-Reply-To: <597BD775-C322-4C92-88C5-BB2B81EBCF2F@briank.com> References: <04aa01c82c6e$746e4eb0$c4f0200a@cisco.com> <39B65A86-DB33-4FBA-BC2B-CC4C81021ED2@magma.ca> <47559983.5040701@cisco.com> <8B9DC0A3-65DD-437A-B666-AA0965921793@cisco.com> <597BD775-C322-4C92-88C5-BB2B81EBCF2F@briank.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <09E5A9B5-29E9-40BE-96BB-B94C426405F7@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] adopt STUN test vectors? Date: Tue, 4 Dec 2007 17:10:52 -0800 To: "Brian Korver" X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=226; t=1196817061; x=1197681061; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20adopt=20STUN=20test=20vectors? |Sender:=20; bh=ihVCdqL1Y8mB6u4BvINnY6mnNkQ4/2EXqoESC+0ciO8=; b=R6R2QejkFibGToH6eSpJDx09HHKnsBOUKtfMxTESsv2N+LIw7lyEU6/xT+cnRSxd9z2GUcLE UDaV5IIhenGMv4uW2VMiuaIRSyi1uT6qouCJFjQNjmaU37UixGHCCoML; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Behave WG , Philip Matthews X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Awesome - if it works for Korver and Philip, then I am strongly in favor of these vectors. On Dec 4, 2007, at 4:26 PM, Brian Korver wrote: > They worked with my implementation. > > -brian > briank@briank.com > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Dec 05 12:18:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izxsl-0005p2-Jj; Wed, 05 Dec 2007 12:17:59 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Izxsk-0005or-6M for behave-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 12:17:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izxsj-0005oi-Sm for behave@ietf.org; Wed, 05 Dec 2007 12:17:57 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izxsj-0006cV-KX for behave@ietf.org; Wed, 05 Dec 2007 12:17:57 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 05 Dec 2007 09:17:57 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB5HHvev003125 for ; Wed, 5 Dec 2007 09:17:57 -0800 Received: from dwingwxp01 (sjc-vpn6-622.cisco.com [10.21.122.110]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lB5HHuqZ020636 for ; Wed, 5 Dec 2007 17:17:56 GMT From: "Dan Wing" To: Date: Wed, 5 Dec 2007 09:17:56 -0800 Message-ID: <031101c83762$c7491f80$6e7a150a@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: Acg3YscEO2EEJS8FQdi/ym/A30n3NQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=262; t=1196875077; x=1197739077; 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:=20TURN=20ad-hoc=20meeting |Sender:=20; bh=LNSMUDhVSzKAc7ueGzzamUM2AcFq8yGFj4TSDCT8rgs=; b=uf2aczkOjH4YwwtDDap+1C8AnNb+z4OYg3EyvJSj/b+7NZRzx3jO/AbJCIzncBAPzbPxMRJM Tq9N6lSpxZXiaCx2i9TxiRewD6BAu0Xpwbdc4D+3aqdQsNGz7HKawnlz; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [BEHAVE] TURN ad-hoc meeting X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 will be an ad-hoc TURN design meeting on Thursday, 10pm, in the Chehalis meeting room in the Westin hotel. Please join if you are interested in TURN. As you know we were unable to complete Jonathan's list of open issues in the BEHAVE meeting. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Dec 05 12:33:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izy7R-0007ew-U3; Wed, 05 Dec 2007 12:33:09 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Izy7R-0007ej-57 for behave-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 12:33:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izy7Q-0007eY-RM for behave@ietf.org; Wed, 05 Dec 2007 12:33:08 -0500 Received: from server.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izy7O-00084m-V4 for behave@ietf.org; Wed, 05 Dec 2007 12:33:08 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id 2A827D9D403C; Wed, 5 Dec 2007 09:33:06 -0800 (PST) Received: from [192.168.1.3] (c-24-4-253-5.hsd1.ca.comcast.net [24.4.253.5]) by server.implementers.org (Postfix) with ESMTP id E63F4D9D403A; Wed, 5 Dec 2007 09:33:03 -0800 (PST) Message-ID: <4756E0CF.8020800@acm.org> Date: Wed, 05 Dec 2007 09:33:03 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071008) MIME-Version: 1.0 To: Dan Wing Subject: Re: [BEHAVE] TURN ad-hoc meeting References: <031101c83762$c7491f80$6e7a150a@cisco.com> In-Reply-To: <031101c83762$c7491f80$6e7a150a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 Dan Wing wrote: > There will be an ad-hoc TURN design meeting on Thursday, 10pm, in the Chehalis > meeting room in the Westin hotel. > > Please join if you are interested in TURN. As you know we were unable to > complete Jonathan's list of open issues in the BEHAVE meeting. I guess that there will be no audio stream for this meeting, but is there any chance to have some notes after the meeting? Thanks. -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Dec 05 17:26:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02h4-0004lx-Eu; Wed, 05 Dec 2007 17:26:14 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J02h2-0004lN-6U for behave-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 17:26:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02h1-0004l7-PS for behave@ietf.org; Wed, 05 Dec 2007 17:26:11 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J02h0-0007LT-RN for behave@ietf.org; Wed, 05 Dec 2007 17:26:11 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lB5MPrhc009827; Thu, 6 Dec 2007 00:26:08 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 00:26:07 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 00:26:07 +0200 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] A simpler way to reduce keepalive traffic Date: Thu, 6 Dec 2007 00:26:06 +0200 Message-ID: In-Reply-To: <9EEA193F-1262-4B4E-9B71-799525796E81@mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] A simpler way to reduce keepalive traffic Thread-Index: Acg2IOkQJm46Y/75T8y1zncx6enpYQBahNVA References: <9EEA193F-1262-4B4E-9B71-799525796E81@mit.edu> From: To: , X-OriginalArrivalTime: 05 Dec 2007 22:26:07.0004 (UTC) FILETIME=[D43245C0:01C8378D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi Bryan, These are certainly interesting ideas. It would be great if we had a reliable way to determine what the minimum timeout on the path is and adjust the keepalive rate accordingly. I like the proposal about exponentially extending the timeout in NAT to support long-lived connectivity. It would be good to understand how reliably the timeout can be determined in real networks. There seem to be a lot of middleboxes who expire their states in very undeterministic ways. So, even if the measurement suggest the timeout is at least X, it might be less. For instance I'm aware of one particular firewall product, where state deletion is done by a background process, causing considerable variance across different flows. It depends on the application how critical possible short connectivity failures are. For your primary telephony app you want to be relatively conservative, but perhaps something like push e-mail can survive from occational loss without users becoming more mad than they become when their battery runs out in 8 hours. As we can't hope many middleboxes to allow explicit query or control of the timers in the near future, I think we should pursue the kind of things you propose, for both TCP and UDP. It is surely useful for the applications to know how often they need to send dummy traffic, and save device battery. Markus =20 >-----Original Message----- >From: ext Bryan Ford [mailto:baford@MIT.EDU]=20 >Sent: 04 December, 2007 02:56 >To: IETF BEHAVE WG >Subject: [BEHAVE] A simpler way to reduce keepalive traffic > >In the "SAFE" BOF today it emerged that (a) there seems to be=20 >a clear consensus that the IETF needs to do something to=20 >reduce the "chattiness" of NAT traversal mechanisms due to the=20 >keepalive traffic they use to keep their (especially UDP)=20 >bindings open; and (b) there's =20 >definitely no consensus yet on the best approach to accomplish that. =20 >(At least that was my personal take-away from the BOF.) > >Although for various reasons I would love to see a decent=20 >"explicit NAT control" or "listener discovery" protocol get=20 >standardized and deployed widely, I wanted to suggest an=20 >alternative way the one small, specific problem of keepalive=20 >chattiness might be addressed without any such explicit=20 >protocol. The solution has two elements: > >1. An amendment to BEHAVE-UDP, basically affecting only=20 >section 4.3 of RFC 4787 and in a backward-compatible way,=20 >recommending that NATs multiplicatively increase each=20 >mapping's timeout over the mapping's lifetime. For example,=20 >if the NAT initially uses a 2-minute timer for a brand-new=20 >mapping (the minimum allowed), then if the mapping is still=20 >alive after 2 minutes the NAT increases the timeout by (say)=20 >2.5x to 5 minutes; then if the mapping is still alive after=20 >that 5 minutes the timeout is again increased by 2.5x to 12.5=20 >minutes, and so on. This is the only change required to NATs. > >2. Applications that wish to minimize their keepalive=20 >chattiness can now use the following technique. They=20 >initialize their keepalive transmission timer to something=20 >safely small for all "reasonable" NATs >- e.g., on the order of 10 seconds - and then in the=20 >background initiate a binding lifetime discovery mechanism=20 >analogous (but not >identical) to that described in section 4.5 of=20 >draft-ietf-behave-nat- behavior-discovery-02. In particular,=20 >instead of assuming the NAT's binding lifetime is fixed and=20 >doing a binary search for it as the draft suggests, the=20 >application just probes successively larger lifetimes in=20 >progression, increasing the probe by a multiplicative factor=20 >of (say) 1.5x each time. When the application has verified=20 >that the NAT seems to have a binding lifetime of "at least" x,=20 >the application sets its keepalive period for the "main" UDP=20 >session it's actually using to that value and continues on to=20 >probe larger values. > >Now, when the path contains one or more "legacy" NATs with a=20 >fixed binding lifetime, the above application behavior will=20 >find that lifetime and use a suitably-matched keepalive period=20 >on an ongoing basis - thus, even with no modifications to=20 >existing NATs, the application effectively minimizes its=20 >chattiness to whatever the NATs on the path will permit. On=20 >the other hand, when the path contains only NATs that behave=20 >as proposed in #1 above, as long as the application's starting=20 >period and multiplicative increase factor is less than the=20 >NAT's, then both periods will continue to increase=20 >indefinitely, resulting in O(log t) instead of O(t) keepalive=20 >traffic over a long-lived binding with a total actual lifetime=20 >of t. Once the application eventually terminates, the time it=20 >takes the NAT to notice this is now proportional to the amount=20 >of time the application's binding was actually active: so even=20 >though the NAT might take a while to garbage-collect a=20 >long-lived binding, any given binding can be in such a "dead"=20 >state for only a constant percentage of its total lifetime. =20 >Thus, the scheme guarantees both logarithmic keepalive chatter=20 >over a binding's lifetime, and an easily-computable=20 >"efficiency ratio" if you compare a binding's total lifetime=20 >against the amount of time the application actually uses that binding. > >Of course there are plenty of details to work out, such as=20 >what the multiplicative factors are, and whether the=20 >application should use a single UDP session for both=20 >application use and binding lifetime discovery probing as the=20 >behavior-discovery draft suggests, or a separate UDP session=20 >for each purpose. Using a single UDP session is obviously=20 >more efficient in terms of NAT state and absolute keepalive=20 >traffic load, but has the disadvantage of allowing the=20 >application's main UDP session to "go dead" for some period as=20 >the application's binding lifetime probe period exceeds the=20 >binding lifetime of some legacy NAT in the path, perhaps=20 >leaving the SIP client temporarily unreachable from the=20 >outside world for example. > >Cheers, >Bryan > > > >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www1.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Dec 05 17:35:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02qC-0008F1-Lj; Wed, 05 Dec 2007 17:35:40 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J02qC-0008Ev-BB for behave-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 17:35:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02qB-0008Ej-Vv for behave@ietf.org; Wed, 05 Dec 2007 17:35:40 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J02qA-0000Bn-Pc for behave@ietf.org; Wed, 05 Dec 2007 17:35:39 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lB5MYsc8017359; Thu, 6 Dec 2007 00:35:31 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 00:35:22 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 00:35:21 +0200 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] A simpler way to reduce keepalive traffic Date: Thu, 6 Dec 2007 00:35:19 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] A simpler way to reduce keepalive traffic Thread-Index: Acg2GPPzUIa7Hqb4TPOXIi+faVnxKQAByB3wAAbcHKAAVJqUcA== References: <20071204025020.3E609E38010@smtpauth02.csee.onr.siteprotect.com> From: To: , , , X-OriginalArrivalTime: 05 Dec 2007 22:35:21.0861 (UTC) FILETIME=[1EEABB50:01C8378F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e 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 David, I would definitely be interested to know how reliable results you get by doing timeout determination. Currently chattiness is a real problem as keepalive rate has to be usually adjusted according to the lower end of the distribution. And for UDP even the center of the distribution seems also to be quite low, not suitable for maintaining connectivity over a long period of time with a battery-powered device, especially in certain type of radio networks.=20 There may be many ways to address this problem, hopefully some more simple than let's double the battery size, let's upgrade all WCDMA networks or let's upgrade all NATs. Markus =20 >-----Original Message----- >From: ext David Barrett [mailto:dbarrett@quinthar.com]=20 >Sent: 04 December, 2007 08:14 >To: 'Frank W. Miller'; 'Bryan Ford'; 'IETF BEHAVE WG' >Subject: RE: [BEHAVE] A simpler way to reduce keepalive traffic > >Incidentally, we've been using the technique Bryan suggests=20 >for over a year now across several hundred thousand computers=20 >and it works great. Indeed, I can confirm there are NATs out=20 >there that already have this property, though they're not typical. > >The only thing annoying about it is it requires two separate=20 >ports: one to probe with (that you don't care if it loses its=20 >mapping), and one to actually use. > >If it's interesting to anybody, I could pull together some=20 >data on the distribution of real-world NAT timeouts. At the=20 >very least, that could help shed light on whether or not the=20 >chattiness is really a problem. > >(Off the cuff, I'd say that a 5M timeout window seems to be=20 >common, but I really don't know for sure.) > >-david > >> -----Original Message----- >> From: Frank W. Miller [mailto:fwmiller@cornfed.com] >> Sent: Monday, December 03, 2007 6:50 PM >> To: 'Bryan Ford'; 'IETF BEHAVE WG' >> Subject: RE: [BEHAVE] A simpler way to reduce keepalive traffic >>=20 >>=20 >> Since I was not able to attend the BoF, could you provide a synopsis=20 >> of why this consensus was arrived at? Specifically, can you=20 >describe=20 >> any deployment scenarios that were quantitatively presented=20 >that have=20 >> difficulty with the "chattiness" you are referring to? I=20 >will assume=20 >> that the chattiness is primarily a problem for the STUN servers that=20 >> are servicing the keepalives. What kind of data was presented to=20 >> support this problem? >>=20 >> Thanks, >> FM >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Bryan Ford [mailto:baford@MIT.EDU] >> Sent: Monday, December 03, 2007 5:56 PM >> To: IETF BEHAVE WG >> Subject: [BEHAVE] A simpler way to reduce keepalive traffic >>=20 >> In the "SAFE" BOF today it emerged that (a) there seems to=20 >be a clear=20 >> consensus that the IETF needs to do something to reduce the=20 >> "chattiness" of NAT traversal mechanisms due to the=20 >keepalive traffic=20 >> they use to keep their (especially UDP) bindings open; and=20 >(b) there's=20 >> definitely no consensus yet on the best approach to accomplish that. >> (At least that was my personal take-away from the BOF.) >>=20 >> Although for various reasons I would love to see a decent "explicit=20 >> NAT control" or "listener discovery" protocol get standardized and=20 >> deployed widely, I wanted to suggest an alternative way the=20 >one small,=20 >> specific problem of keepalive chattiness might be addressed without=20 >> any such explicit protocol. The solution has two elements: >>=20 >> 1. An amendment to BEHAVE-UDP, basically affecting only=20 >section 4.3 of=20 >> RFC 4787 and in a backward-compatible way, recommending that NATs=20 >> multiplicatively increase each mapping's timeout over the mapping's=20 >> lifetime. For example, if the NAT initially uses a 2-minute=20 >timer for=20 >> a brand-new mapping (the minimum allowed), then if the mapping is=20 >> still alive after 2 minutes the NAT increases the timeout by (say)=20 >> 2.5x to 5 minutes; then if the mapping is still alive after that 5=20 >> minutes the timeout is again increased by 2.5x to 12.5=20 >minutes, and so=20 >> on. This is the only change required to NATs. >>=20 >> 2. Applications that wish to minimize their keepalive chattiness can=20 >> now use the following technique. They initialize their keepalive=20 >> transmission timer to something safely small for all=20 >"reasonable" NATs >> - e.g., on the order of 10 seconds - and then in the background=20 >> initiate a binding lifetime discovery mechanism analogous (but not >> identical) to that described in section 4.5 of=20 >draft-ietf-behave-nat-=20 >> behavior-discovery-02. In particular, instead of assuming the NAT's=20 >> binding lifetime is fixed and doing a binary search for it as the=20 >> draft suggests, the application just probes successively larger=20 >> lifetimes in progression, increasing the probe by a multiplicative=20 >> factor of (say) 1.5x each time. When the application has verified=20 >> that the NAT seems to have a binding lifetime of "at least" x, the=20 >> application sets its keepalive period for the "main" UDP=20 >session it's=20 >> actually using to that value and continues on to probe larger values. >>=20 >> Now, when the path contains one or more "legacy" NATs with a fixed=20 >> binding lifetime, the above application behavior will find that=20 >> lifetime and use a suitably-matched keepalive period on an ongoing=20 >> basis - thus, even with no modifications to existing NATs, the=20 >> application effectively minimizes its chattiness to whatever=20 >the NATs=20 >> on the path will permit. On the other hand, when the path contains=20 >> only NATs that behave as proposed in #1 above, as long as the=20 >> application's starting period and multiplicative increase factor is=20 >> less than the NAT's, then both periods will continue to increase=20 >> indefinitely, resulting in O(log t) instead of O(t)=20 >keepalive traffic=20 >> over a long-lived binding with a total actual lifetime of t.=20 > Once the=20 >> application eventually terminates, the time it takes the NAT=20 >to notice=20 >> this is now proportional to the amount of time the application's=20 >> binding was actually active: so even though the NAT might=20 >take a while=20 >> to garbage-collect a long-lived binding, any given binding can be in=20 >> such a "dead" state for only a constant percentage of its total=20 >> lifetime. Thus, the scheme guarantees both logarithmic keepalive=20 >> chatter over a binding's lifetime, and an easily-computable=20 >> "efficiency ratio" if you compare a binding's total lifetime against=20 >> the amount of time the application actually uses that binding. >>=20 >> Of course there are plenty of details to work out, such as what the=20 >> multiplicative factors are, and whether the application should use a=20 >> single UDP session for both application use and binding lifetime=20 >> discovery probing as the behavior-discovery draft suggests, or a=20 >> separate UDP session for each purpose. Using a single UDP=20 >session is=20 >> obviously more efficient in terms of NAT state and absolute=20 >keepalive=20 >> traffic load, but has the disadvantage of allowing the application's=20 >> main UDP session to "go dead" for some period as the application's=20 >> binding lifetime probe period exceeds the binding lifetime of some=20 >> legacy NAT in the path, perhaps leaving the SIP client temporarily=20 >> unreachable from the outside world for example. >>=20 >> Cheers, >> Bryan >>=20 >>=20 >>=20 >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave >>=20 >>=20 >>=20 >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave > > > >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www1.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Dec 05 18:26:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J03dH-0008TD-C1; Wed, 05 Dec 2007 18:26:23 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J03dG-0008T3-8y for behave-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 18:26:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J03dF-0008St-Uf for behave@ietf.org; Wed, 05 Dec 2007 18:26:21 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J03dF-0005dC-KH for behave@ietf.org; Wed, 05 Dec 2007 18:26:21 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 05 Dec 2007 15:26:21 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lB5NQLDN005622; Wed, 5 Dec 2007 15:26:21 -0800 Received: from [130.129.21.174] (sjc-vpn5-1599.cisco.com [10.21.94.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id lB5NQKgK012243; Wed, 5 Dec 2007 23:26:20 GMT In-Reply-To: <031101c83762$c7491f80$6e7a150a@cisco.com> References: <031101c83762$c7491f80$6e7a150a@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <705C464F-208A-44A2-9390-89EC3DA6C824@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: ROOM CHANGED Re: [BEHAVE] TURN ad-hoc meeting - Date: Wed, 5 Dec 2007 15:26:13 -0800 To: Behave WG X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=605; t=1196897181; x=1197761181; 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:=20ROOM=20CHANGED=20=20Re=3A=20[BEHAVE]=20TURN=20ad-hoc=20meetin g=20-=20 |Sender:=20; bh=G2tCqD0jylJb8DN9SoEgabs7ijiYJSLJ7pX4dDSo1Zo=; b=ImME+dHAkcgczpmrCJTjliw2Z4ZPXY1mds5QePmy81F8RnEyZcM1tn8ZoZTwuKbO45phJ8g7 KKhscpLb5MLXn/QaKcviIYbI6xe0L9Pe0iOlgSJ+tFQaqRyyqYrb0bU9; 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: 7655788c23eb79e336f5f8ba8bce7906 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 This meeting has been moved to the Oak room - same time. (it was moved to get a bigger room and streaming audio). On Dec 5, 2007, at 9:17 AM, Dan Wing wrote: > There will be an ad-hoc TURN design meeting on Thursday, 10pm, in > the Chehalis > meeting room in the Westin hotel. > > Please join if you are interested in TURN. As you know we were > unable to > complete Jonathan's list of open issues in the BEHAVE meeting. > > -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 Dec 05 18:28:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J03fi-0001Dc-AN; Wed, 05 Dec 2007 18:28:54 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J03fg-0001DE-P9 for behave-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 18:28:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J03fg-0001D0-Dt for behave@ietf.org; Wed, 05 Dec 2007 18:28:52 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J03fg-0005s6-2Z for behave@ietf.org; Wed, 05 Dec 2007 18:28:52 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 05 Dec 2007 15:28:49 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lB5NSpK8016981; Wed, 5 Dec 2007 15:28:51 -0800 Received: from dwingwxp01 (sjc-vpn2-1100.cisco.com [10.21.116.76]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lB5NSp75017007; Wed, 5 Dec 2007 23:28:51 GMT From: "Dan Wing" To: "'Marc Petit-Huguenin'" References: <031101c83762$c7491f80$6e7a150a@cisco.com> <4756E0CF.8020800@acm.org> Subject: RE: [BEHAVE] TURN ad-hoc meeting Date: Wed, 5 Dec 2007 15:28:50 -0800 Message-ID: <10d801c83796$975e2250$6e7a150a@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: Acg3ZOitfvvp7lNyRbyblrmjceM+3AAMYJLw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4756E0CF.8020800@acm.org> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1158; t=1196897331; x=1197761331; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20TURN=20ad-hoc=20meeting |Sender:=20; bh=vZIk2PLZzMr+Bzq829fZpdvlIu0gFgfatI4m327v1WU=; b=IW0q8KBo60h+v9ixoAbSU750dTViyvOKv67N2T+UXv8Vt/20x5opBp3M+ULCBv0wAcJgLVQC rM5UFQbC8GSAiu4FrzZ2E2QoKTRwo2Bb0RYShelAtoYnO4RnVFeZtFFv; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 With the room change (which Cullen just announced) we should have audio streamed and recorded, and also a microphone which will constrain discussion a bit and keep things more organized. -d > -----Original Message----- > From: Marc Petit-Huguenin [mailto:petithug@acm.org] > Sent: Wednesday, December 05, 2007 9:33 AM > To: Dan Wing > Cc: behave@ietf.org > Subject: Re: [BEHAVE] TURN ad-hoc meeting > > Dan Wing wrote: > > There will be an ad-hoc TURN design meeting on Thursday, > 10pm, in the Chehalis > > meeting room in the Westin hotel. > > > > Please join if you are interested in TURN. As you know we > were unable to > > complete Jonathan's list of open issues in the BEHAVE meeting. > > I guess that there will be no audio stream for this meeting, but is > there any chance to have some notes after the meeting? > > Thanks. > > -- > Marc Petit-Huguenin [ ] > Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] > Work: marc@8x8.com [ ] > [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 06 15:20:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0NCs-0002yo-L3; Thu, 06 Dec 2007 15:20:26 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J0NCr-0002ya-TA for behave-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 15:20:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0NCr-0002yQ-HM for behave@ietf.org; Thu, 06 Dec 2007 15:20:25 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0NCq-0003RE-LE for behave@ietf.org; Thu, 06 Dec 2007 15:20:25 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 887A228000352; Thu, 6 Dec 2007 21:20:23 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1MO88JjGkyc; Thu, 6 Dec 2007 21:20:23 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 6622828000302; Thu, 6 Dec 2007 21:20:13 +0100 (CET) Received: from [10.7.0.4] ([10.7.0.4]) by mx1.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Dec 2007 21:20:11 +0100 Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <89E9CBF7-4133-490B-B147-6BA33076F5D7@netlab.nec.de> To: behave@ietf.org From: Martin Stiemerling Date: Thu, 6 Dec 2007 21:19:56 +0100 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 06 Dec 2007 20:20:13.0390 (UTC) FILETIME=[684DFEE0:01C83845] X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Subject: [BEHAVE] Brief review of draft-soliman-firewall-control-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: , Content-Type: multipart/mixed; boundary="===============2118460960==" Errors-To: behave-bounces@ietf.org --===============2118460960== Content-Type: multipart/alternative; boundary=Apple-Mail-95--378135737 --Apple-Mail-95--378135737 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi all, I have had some remarks at the IETF#70 BEHAVE session about draft- soliman-firewall-control-00.txt. I promised to summarise them and here we go. Sorry for being at brief on protocol details, but I have concerns about the proposal that do not require to get even to the protocol itself. I like the idea of using CGA to identify clients in signal protocols, especially in environments where you do not have a pre-knowledge (e.g., certificates, etc). This part is worth investigating further! But when reading the draft and looking at the slides I have had the feeling that the authors had a great idea about security. However, they have tried to find a problem to fit their security ideas. When reading Section 3. "Protocol operation" it looks pretty much as the MIDCOM architecture (RFC3303). Finding the corresponding server that controls the firewall or the firewall itself is not an new idea and has been discussed back in the very beginning of MIDCOM (i.e., using a DHCP option for that). Other detection mechanisms have also been discussed. Then there is NSIS which can discover NSIS-enabled firewalls/NATs easily and deals good with nested firewalls. You mention NSIS NATFW NSLP in Section 2. "Introduction" and claim that " However, this approach assumes a form of pre-established trust." While is probably true for some possible deployments, it is just dead wrong in general. The NATFW NSLP, or NSIS in general, is open to other mechanisms that do not require pre-established trust and we have discussed some approaches to this in the past. For non-technical reasons, this has not made it in the working group drafts. Then you have mentioned SIMCO (RFC4540). You have claimed on your slides that your protocol proposal is better than SIMCO, because you are running binary. Damn, you should read RFC4540 and see how binary SIMCO is. It is binary only and there is no notion at all of ABNF. Using ICMPv6 as firewall/NAT (policy in general) transport protocol is for sure not the way of doing it. How about congestion control? I know where this idea comes from (MIP6) but it is an excellent approach at all to go down this road for firewall/NAT control purposes. I would claim you have neglected searching for existing and related work. Just my two cents, Martin stiemerling@netlab.nec.de NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-95--378135737 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi all,

I have = had some remarks at the IETF#70 BEHAVE session = about=A0draft-soliman-firewall-control-00.txt. =A0I promised to = summarise them and here we go. Sorry for being at brief on protocol = details, but I have concerns about the proposal that do not require to = get even to the protocol itself.=A0

I like the = idea of using CGA to identify clients in signal protocols, especially in = environments where =A0you do not have a pre-knowledge (e.g., = certificates, etc). This part is worth investigating = further!

But when reading the = draft and looking at the slides I have had the feeling that the authors = had a great idea about security. However, they have tried to find a = problem to fit their security ideas.=A0

When reading Section =A03. = =A0"Protocol operation" it looks pretty much as the MIDCOM architecture = (RFC3303). Finding the corresponding server that controls the firewall = or the firewall itself is not an new idea and has been discussed back in = the very beginning of MIDCOM (i.e., using a DHCP option for that). Other = detection mechanisms have also been discussed.=A0

Then there is NSIS which = can discover NSIS-enabled firewalls/NATs easily and deals good with = nested firewalls. You mention NSIS NATFW NSLP in Section 2. = "Introduction" and claim that "=A0However, this approach assumes a form = of=A0=A0 pre-established trust." While is probably true for some = possible deployments, it is just dead wrong in general. The NATFW NSLP, = or NSIS in general, is open to other mechanisms that do not require = pre-established trust and we have discussed some approaches to this in = the past. For non-technical reasons, this has not made it in the working = group drafts.=A0

Then you have mentioned = SIMCO (RFC4540). You have claimed on your slides that your protocol = proposal is better than SIMCO, because you are running binary. Damn, you = should read RFC4540 and see how binary SIMCO is. It is binary only and = there is no notion at all of ABNF.

Using ICMPv6 as = firewall/NAT (policy in general) transport protocol is for sure not the = way of doing it. How about congestion control? I know where this idea = comes from (MIP6) but it is an excellent approach at all to go down this = road for firewall/NAT control purposes.

I would claim you have = neglected searching for existing and related work.=A0

Just my two = cents,=A0

=A0Martin

=
stiemerling@netlab.nec.de

NEC Laboratories Europe - Network Research = Division

NEC = Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014
=

= --Apple-Mail-95--378135737-- --===============2118460960== 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 --===============2118460960==-- From behave-bounces@ietf.org Thu Dec 06 16:55:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Ogb-0002ir-S5; Thu, 06 Dec 2007 16:55:13 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J0Oga-0002h9-Kc for behave-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 16:55:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Oga-0002h1-5M for behave@ietf.org; Thu, 06 Dec 2007 16:55:12 -0500 Received: from exprod7og106.obsmtp.com ([64.18.2.165]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0OgZ-0003Zw-HM for behave@ietf.org; Thu, 06 Dec 2007 16:55:12 -0500 Received: from source ([66.129.224.36]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Thu, 06 Dec 2007 13:54:56 PST Received: from proton.jnpr.net ([10.10.2.37]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 13:54:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] Brief review of draft-soliman-firewall-control-00.txt Date: Thu, 6 Dec 2007 16:54:42 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280BD8EF1C@proton.jnpr.net> In-Reply-To: <89E9CBF7-4133-490B-B147-6BA33076F5D7@netlab.nec.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Brief review of draft-soliman-firewall-control-00.txt Thread-Index: Acg4RXXmKkn6BuwBT7+/OB/JHGm6GAADHjAA From: "Reinaldo Penno" To: "Martin Stiemerling" , X-OriginalArrivalTime: 06 Dec 2007 21:54:47.0728 (UTC) FILETIME=[9E794300:01C83852] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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 Hello, I was involved in MIDCOM, client enabled firewall, off-path firewall control, H.248v3 firewall/NAT control (Ia IMS interface), and other related efforts. After all this I'm wondering if the IETF shouldn't backtrack a little bit and try to standardize Firewall behavior (just like it is doing for NAT), before we try to put effort in yet another firewall control protocol.=20 =20 Thanks, Reinaldo ________________________________ From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de]=20 Sent: Thursday, December 06, 2007 12:20 PM To: behave@ietf.org Subject: [BEHAVE] Brief review of draft-soliman-firewall-control-00.txt =09 =09 Hi all,=20 I have had some remarks at the IETF#70 BEHAVE session about draft-soliman-firewall-control-00.txt. I promised to summarise them and here we go. Sorry for being at brief on protocol details, but I have concerns about the proposal that do not require to get even to the protocol itself.=20 I like the idea of using CGA to identify clients in signal protocols, especially in environments where you do not have a pre-knowledge (e.g., certificates, etc). This part is worth investigating further! But when reading the draft and looking at the slides I have had the feeling that the authors had a great idea about security. However, they have tried to find a problem to fit their security ideas.=20 When reading Section 3. "Protocol operation" it looks pretty much as the MIDCOM architecture (RFC3303). Finding the corresponding server that controls the firewall or the firewall itself is not an new idea and has been discussed back in the very beginning of MIDCOM (i.e., using a DHCP option for that). Other detection mechanisms have also been discussed.=20 Then there is NSIS which can discover NSIS-enabled firewalls/NATs easily and deals good with nested firewalls. You mention NSIS NATFW NSLP in Section 2. "Introduction" and claim that " However, this approach assumes a form of pre-established trust." While is probably true for some possible deployments, it is just dead wrong in general. The NATFW NSLP, or NSIS in general, is open to other mechanisms that do not require pre-established trust and we have discussed some approaches to this in the past. For non-technical reasons, this has not made it in the working group drafts.=20 Then you have mentioned SIMCO (RFC4540). You have claimed on your slides that your protocol proposal is better than SIMCO, because you are running binary. Damn, you should read RFC4540 and see how binary SIMCO is. It is binary only and there is no notion at all of ABNF. Using ICMPv6 as firewall/NAT (policy in general) transport protocol is for sure not the way of doing it. How about congestion control? I know where this idea comes from (MIP6) but it is an excellent approach at all to go down this road for firewall/NAT control purposes. I would claim you have neglected searching for existing and related work.=20 Just my two cents,=20 Martin =09 =09 stiemerling@netlab.nec.de NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 =09 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 06 17:01:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Omg-0005Gw-T5; Thu, 06 Dec 2007 17:01:30 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J0Omg-0005Go-HD for behave-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 17:01:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Omg-0005Gc-5Z for behave@ietf.org; Thu, 06 Dec 2007 17:01:30 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0Omf-00043s-PM for behave@ietf.org; Thu, 06 Dec 2007 17:01:30 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 06 Dec 2007 14:01:29 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB6M1Tas014367; Thu, 6 Dec 2007 14:01:29 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lB6M1Oqh029605; Thu, 6 Dec 2007 22:01:28 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 17:01:12 -0500 Received: from 10.86.115.68 ([10.86.115.68]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) with Microsoft Exchange Server HTTP-DAV ; Thu, 6 Dec 2007 22:01:12 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 06 Dec 2007 17:01:14 -0500 Subject: Re: [BEHAVE] Brief review of draft-soliman-firewall-control-00.txt From: Melinda Shore To: Reinaldo Penno , Martin Stiemerling , Message-ID: Thread-Topic: [BEHAVE] Brief review of draft-soliman-firewall-control-00.txt Thread-Index: Acg4RXXmKkn6BuwBT7+/OB/JHGm6GAADHjAAAABlg0I= In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280BD8EF1C@proton.jnpr.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 06 Dec 2007 22:01:12.0581 (UTC) FILETIME=[83DD2B50:01C83853] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1130; t=1196978489; x=1197842489; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshore@cisco.com; z=From:=20Melinda=20Shore=20 |Subject:=20Re=3A=20[BEHAVE]=20Brief=20review=20of=20draft-soliman-firewa ll-control-00.txt |Sender:=20; bh=lD9TnI368AjKMZLA933WJ/FQKfjjRjCIaS7akvJvjMk=; b=JMdLaM2PoVzpPNCvXrwJsrG0N/9WaiIytg9SMMiNHP5lRtR5t/2AaPJH7GX3ZrY3IZzF0EPy QhehiFYMNGnwFSbCz2i8OrB45G17tJoGfPDlqXsEIytiIY5uKTcwNuM8; Authentication-Results: sj-dkim-2; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 12/6/07 4:54 PM, "Reinaldo Penno" wrote: > I was involved in MIDCOM, client enabled firewall, off-path firewall > control, H.248v3 firewall/NAT control (Ia IMS interface), and other > related efforts. After all this I'm wondering if the IETF shouldn't > backtrack a little bit and try to standardize Firewall behavior (just > like it is doing for NAT), before we try to put effort in yet another > firewall control protocol. That would be a "no." The reason that BEHAVE is attempting to come up with recommendations for NAT behavior is because variations in behavior complicate STUN, or at least that was the original intention. That it's metastasized into something else is, I think, irrelevant to the question you raised. Personally, I'm unclear on why this draft got time on the agenda since it's redundant with a number of existing efforts and is off- topic to the group. And as I said a few weeks ago, the reasons that firewall "control" has not been successful are most certainly not because we lack a *protocol*, for heaven's sakes. We have a number of them. Melinda _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 06 17:07:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0OsL-00072y-S4; Thu, 06 Dec 2007 17:07:21 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J0OsK-00072r-9D for behave-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 17:07:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0OsJ-00072g-VW for behave@ietf.org; Thu, 06 Dec 2007 17:07:19 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J0OsJ-00065J-F2 for behave@ietf.org; Thu, 06 Dec 2007 17:07:19 -0500 Received: (qmail invoked by alias); 06 Dec 2007 22:07:18 -0000 Received: from dhcp-16c7.ietf70.org (EHLO [130.129.22.199]) [130.129.22.199] by mail.gmx.net (mp039) with SMTP; 06 Dec 2007 23:07:18 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/x92sZ7VPx/4mhARsT0bvZHkNxWMh4vPpaMlMgU2 /tp2q49JQeN3S9 Message-ID: <47587295.8060908@gmx.net> Date: Thu, 06 Dec 2007 23:07:17 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Melinda Shore Subject: Re: [BEHAVE] Brief review of draft-soliman-firewall-control-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I see the value of draft-soliman-firewall-control-00.txt only in the CGA approach. It is an academic value -- still interesting. This idea came up in the past already and can be added to other protocols in a fairly painless fashion ---- in case someone really needs this stuff. Ciao Hannes Melinda Shore wrote: > On 12/6/07 4:54 PM, "Reinaldo Penno" wrote: > >> I was involved in MIDCOM, client enabled firewall, off-path firewall >> control, H.248v3 firewall/NAT control (Ia IMS interface), and other >> related efforts. After all this I'm wondering if the IETF shouldn't >> backtrack a little bit and try to standardize Firewall behavior (just >> like it is doing for NAT), before we try to put effort in yet another >> firewall control protocol. >> > > That would be a "no." The reason that BEHAVE is attempting to > come up with recommendations for NAT behavior is because variations > in behavior complicate STUN, or at least that was the original > intention. That it's metastasized into something else is, I think, > irrelevant to the question you raised. > > Personally, I'm unclear on why this draft got time on the agenda > since it's redundant with a number of existing efforts and is off- > topic to the group. And as I said a few weeks ago, the reasons > that firewall "control" has not been successful are most certainly > not because we lack a *protocol*, for heaven's sakes. We have a > number of them. > > Melinda > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 06 17:13:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0OyV-0004GR-I2; Thu, 06 Dec 2007 17:13:43 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J0OyU-0004GK-Ep for behave-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 17:13:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0OyU-0004GB-4q for behave@ietf.org; Thu, 06 Dec 2007 17:13:42 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0OyT-0006Xd-QY for behave@ietf.org; Thu, 06 Dec 2007 17:13:42 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 06 Dec 2007 17:13:41 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB6MDfhS001903; Thu, 6 Dec 2007 17:13:41 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lB6MDRI8014356; Thu, 6 Dec 2007 22:13:36 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 17:13:26 -0500 Received: from 10.86.115.68 ([10.86.115.68]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) with Microsoft Exchange Server HTTP-DAV ; Thu, 6 Dec 2007 22:13:25 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 06 Dec 2007 17:13:28 -0500 Subject: Re: [BEHAVE] Brief review of draft-soliman-firewall-control-00.txt From: Melinda Shore To: Hannes Tschofenig Message-ID: Thread-Topic: [BEHAVE] Brief review of draft-soliman-firewall-control-00.txt Thread-Index: Acg4VTo1eJA28KRIEdyySgAKleNSdA== In-Reply-To: <47587295.8060908@gmx.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 06 Dec 2007 22:13:26.0542 (UTC) FILETIME=[3956BAE0:01C83855] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=570; t=1196979221; x=1197843221; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshore@cisco.com; z=From:=20Melinda=20Shore=20 |Subject:=20Re=3A=20[BEHAVE]=20Brief=20review=20of=20draft- soliman-firewall-control-00.txt |Sender:=20 |To:=20Hannes=20Tschofenig=20; bh=RwIAy5+t9KMsDI2uKlhz193DGqrON7k5f96WjaaPbXc=; b=e1gdQuT4Qc9zgknLfqvbcSFbFjDPVfMP35e/WUJK7QO+gaRS98XB7KMARQ pLYAQktx4Re/S9U88dE9zhUPWgNBXcenu+SdzGRuBnNsMVA2vvo0eDAxpIpw x7/WavJDno; Authentication-Results: rtp-dkim-2; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 12/6/07 5:07 PM, "Hannes Tschofenig" wrote: > I see the value of draft-soliman-firewall-control-00.txt only in the CGA > approach. It is an academic value -- still interesting. > This idea came up in the past already and can be added to other > protocols in a fairly painless fashion ---- in case someone really needs > this stuff. Absolutely, and I'll point out that we used group keys in NLS to achieve the same goals (securing relationships between unknown- in-advance pairs; providing rudimentary authorization). Melinda _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 06 17:22:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0P7T-0006Ee-Hy; Thu, 06 Dec 2007 17:22:59 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J0P7S-0006EN-KM for behave-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 17:22:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0P7S-0006Du-8k for behave@ietf.org; Thu, 06 Dec 2007 17:22:58 -0500 Received: from exprod7og105.obsmtp.com ([64.18.2.163]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0P7R-0005xS-Nx for behave@ietf.org; Thu, 06 Dec 2007 17:22:58 -0500 Received: from source ([66.129.224.36]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Thu, 06 Dec 2007 14:22:27 PST Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 14:22:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] Brief review of draft-soliman-firewall-control-00.txt Date: Thu, 6 Dec 2007 17:18:48 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280BD8EF38@proton.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Brief review of draft-soliman-firewall-control-00.txt Thread-Index: Acg4RXXmKkn6BuwBT7+/OB/JHGm6GAADHjAAAABlg0IAAF+EAA== From: "Reinaldo Penno" To: "Melinda Shore" , "Martin Stiemerling" , X-OriginalArrivalTime: 06 Dec 2007 22:22:11.0400 (UTC) FILETIME=[722DB480:01C83856] 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 I agree that firewall control was not successful not because of a lack of protocol. But I would say that as much as NAT variations cause problems for STUN, Firewall variations also cause problems for many protocols. For example, the way different firewalls implementations handle TCP ultimately impact application protocols that run over it. I think there is also something to be said about ICMP and others. =20 Regards, Reinaldo > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com]=20 > Sent: Thursday, December 06, 2007 2:01 PM > To: Reinaldo Penno; Martin Stiemerling; behave@ietf.org > Subject: Re: [BEHAVE] Brief review of=20 > draft-soliman-firewall-control-00.txt >=20 > On 12/6/07 4:54 PM, "Reinaldo Penno" wrote: > > I was involved in MIDCOM, client enabled firewall, off-path=20 > firewall=20 > > control, H.248v3 firewall/NAT control (Ia IMS interface), and other=20 > > related efforts. After all this I'm wondering if the IETF shouldn't=20 > > backtrack a little bit and try to standardize Firewall=20 > behavior (just=20 > > like it is doing for NAT), before we try to put effort in=20 > yet another=20 > > firewall control protocol. >=20 > That would be a "no." The reason that BEHAVE is attempting=20 > to come up with recommendations for NAT behavior is because=20 > variations in behavior complicate STUN, or at least that was=20 > the original intention. That it's metastasized into=20 > something else is, I think, irrelevant to the question you raised. >=20 > Personally, I'm unclear on why this draft got time on the=20 > agenda since it's redundant with a number of existing efforts=20 > and is off- topic to the group. And as I said a few weeks=20 > ago, the reasons that firewall "control" has not been=20 > successful are most certainly not because we lack a=20 > *protocol*, for heaven's sakes. We have a number of them. >=20 > Melinda > =20 >=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 06 17:45:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0PTX-0005Tr-Qz; Thu, 06 Dec 2007 17:45:47 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J0PTW-0005Q9-5k for behave-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 17:45:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0PTV-0005Q1-S6 for behave@ietf.org; Thu, 06 Dec 2007 17:45:45 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0PTU-00015M-H4 for behave@ietf.org; Thu, 06 Dec 2007 17:45:45 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lB6MjMfM000629 for ; Thu, 6 Dec 2007 16:45:59 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 00:45:35 +0200 Received: from essapo-nirac252140.europe.nokia.com ([10.162.252.140]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 00:45:35 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] Brief review of draft-soliman-firewall-control-00.txt Date: Fri, 7 Dec 2007 00:45:33 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200712070045.33837.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 06 Dec 2007 22:45:35.0465 (UTC) FILETIME=[B7110590:01C83859] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Le Friday 07 December 2007 00:01:14 ext Melinda Shore, vous avez =E9crit=A0: > Personally, I'm unclear on why this draft got time on the agenda > since it's redundant with a number of existing efforts and is off- > topic to the group. My understanding is that it was there because it looks similar to ALD, whic= h=20 was there in Chicago as add-on to the V6CPE document. > And as I said a few weeks ago, the reasons that firewall=20 > has not been successful are most certainly not because > we lack a *protocol*, for heaven's sakes. We have a=20 > number of them. Definitely. The reason is lack of vendor interests (hence the value of ALD = but=20 I'm going off-topic). =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 06 18:48:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0QSb-00043l-Fb; Thu, 06 Dec 2007 18:48:53 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J0QSZ-00043B-2s for behave-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 18:48:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0QSY-00042w-Oz for behave@ietf.org; Thu, 06 Dec 2007 18:48:50 -0500 Received: from rv-out-0910.google.com ([209.85.198.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0QSY-00060K-By for behave@ietf.org; Thu, 06 Dec 2007 18:48:50 -0500 Received: by rv-out-0910.google.com with SMTP id l15so435027rvb for ; Thu, 06 Dec 2007 15:48:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; bh=Fh9kgLZW8FLcAY1H2r7Fr89vLiIH3M2qOuUPBqPMFB8=; b=hCTv1z6i3aW5uYFaBnFUhEb/NHuBWr31Cnso/+BLLRYO8tc/dfgoXZgf0jz1A7/S21A0Ds8QGbqJ8Q8u17yGokv4/4WlNfnVL51khYOSqSN00NFsE9ODM3nMgXEqcFVSmBUZPmJLrG++KlnU3WXX3X67jy0j7K45QbtbNxwyFj8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=qGzOUvUaxne8RZ+X7QbPVS02K1iOnXlHI/AEdo+3hVO+OgAQD1iw/3tYOynifKd/zThA2jfVoeBhFmLKeNHrVBiICbOtHzzqklPuwJ3FUVqZ6rvvBdyXLxrtF1l8HmPZLqJwM1nVKV53Y3MGjFvRBnkneM6Lg6dUwExkKm1KWSE= Received: by 10.142.162.5 with SMTP id k5mr2015675wfe.1196984929366; Thu, 06 Dec 2007 15:48:49 -0800 (PST) Received: by 10.142.132.18 with HTTP; Thu, 6 Dec 2007 15:48:49 -0800 (PST) Message-ID: <20d2bdfb0712061548y7c7db947va54f4f01dcd8e002@mail.gmail.com> Date: Thu, 6 Dec 2007 15:48:49 -0800 From: "Bruce Lowekamp" To: behave@ietf.org, mmusic@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 8c8affd6170d7880 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Subject: [BEHAVE] ice: stun over tls or not? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 concerned about what may be a conflict or possibly just a significant point of confusion over the relationship between STUN and (D)TLS when used with ICE. Basically, do you run STUN over (D)TLS or is it run over the raw (UDP/TCP) transport before (D)TLS handshaking is begun. - 3489bis-13 7.2.2 for TLS/TCP requires that TLS be established before sending a stun message that is encoded on the TLS connection - ice-19 does not say anything about DTLS/UDP - ice-tcp-05 sec 2 and 5.1.1 say that when doing ICE for TLS/TCP or DTLS/TCP use 4571 to frame stun outside the (D)TLS connection. The 4571 shim is explicitly specified as being used regardless of whether the application is rtp media or something else entirely. I think there is some question as to whether these are in actual conflict or merely confusing, but my concerns are: - 3489bis shouldn't specify a MUST that is overridden by a stun usage - it makes no sense to require non-media/rtp applications to implement the 4571 shim I would like to propose the following: - change 3489bis 7.2.2 (and possibly at a higher level) to specify MUST "unless the particular STUN usage specifies a different layering" - change ice-tcp to specify that the 4571 shim MUST be used for media/rtp, and that other protocols MUST specify an equivalent method for demultiplexing or specify how the application is demultiplexed from STUN messages if no shim is required. - I don't see a strong motivation in other applications using ICE to require that stun be layered beside (D)TLS rather than on top of it. Maybe I'm missing something, but if you don't need that type of construct already (such as DTLS-SRTP over TCP needs it), it seems to add a lot of complexity. I would like applications to be able to specify that STUN is running on top of (D)TLS. I really wish that DTLS/UDP could be addressed somewhere, but I don't know if any of the current drafts are appropriate. If the material currently in draft-bryan-p2psip-reload-02 is going to be pulled out into a separate draft, maybe it could go there? Bruce _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 06 19:42:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0RIe-0001uy-Nh; Thu, 06 Dec 2007 19:42:40 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J0RId-0001uq-F0 for behave-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 19:42:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0RIc-0001uc-TO for behave@ietf.org; Thu, 06 Dec 2007 19:42:38 -0500 Received: from mail.globalsuite.net ([69.46.103.200]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J0RIb-0007xK-1O for behave@ietf.org; Thu, 06 Dec 2007 19:42:37 -0500 X-AuditID: c0a8013c-acf21bb000001e2e-e4-475896facf52 Received: from PC20005 (unknown [207.236.117.226]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id 7B5BA4DC010; Thu, 6 Dec 2007 17:42:33 -0700 (MST) From: "Hesham Soliman" To: "'Martin Stiemerling'" , Subject: RE: [BEHAVE] Brief review of draft-soliman-firewall-control-00.txt Date: Fri, 7 Dec 2007 11:42:16 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <89E9CBF7-4133-490B-B147-6BA33076F5D7@netlab.nec.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acg4RXeRkQzYfQqzRCeuOtgnTzb5BAAK1Jfg X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: gregdaley@ieee.org, 'Suresh Krishnan' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I have had some remarks at the IETF#70 BEHAVE session about draft-soliman-firewall-control-00.txt. I promised to summarise them and here we go. Sorry for being at brief on protocol details, but I have concerns about the proposal that do not require to get even to the protocol itself. I like the idea of using CGA to identify clients in signal protocols, especially in environments where you do not have a pre-knowledge (e.g., certificates, etc). This part is worth investigating further! But when reading the draft and looking at the slides I have had the feeling that the authors had a great idea about security. However, they have tried to find a problem to fit their security ideas. => Ok, can you at least substantiate that claim with some details? I happen to think that choosing the right authorisation mechanism is fundamental to any host-based firewall control protocol. But I don't see how you can go from that to concluding that we created a problem around CGAs. I think that's not true. When reading Section 3. "Protocol operation" it looks pretty much as the MIDCOM architecture (RFC3303). Finding the corresponding server that controls the firewall or the firewall itself is not an new idea and has been discussed back in the very beginning of MIDCOM (i.e., using a DHCP option for that). Other detection mechanisms have also been discussed. => That's good but what's the comment? Did the draft claim that no one ever thought about this? Please give us comments that can improve the draft if you can. All of the authors would appreciate any criticisms that can help improve the quality of the work. Then there is NSIS which can discover NSIS-enabled firewalls/NATs easily and deals good with nested firewalls. You mention NSIS NATFW NSLP in Section 2. "Introduction" and claim that " However, this approach assumes a form of pre-established trust." While is probably true for some possible deployments, it is just dead wrong in general. The NATFW NSLP, or NSIS in general, is open to other mechanisms that do not require pre-established trust and we have discussed some approaches to this in the past. For non-technical reasons, this has not made it in the working group drafts. => Hopefully something will make it to the draft because I think the current security model for the NSIS draft is not useful for many practical deployments. Then you have mentioned SIMCO (RFC4540). You have claimed on your slides that your protocol proposal is better than SIMCO, because you are running binary. Damn, you should read RFC4540 and see how binary SIMCO is. It is binary only and there is no notion at all of ABNF. => I'm not sure if you're the same person who made this comment in the meeting, but someone made that comment. I think I read an old SIMCO personal draft, I promise to read 4540. Using ICMPv6 as firewall/NAT (policy in general) transport protocol is for sure not the way of doing it. How about congestion control? => I think for very large deployments TCP is not a scalable way of doing this. In another life I worked on similar protocols for policy control and we found that for those large deployments, especially with managed networks, congestion control was a much lesser priority in the scheme of tradeoffs. I know where this idea comes from (MIP6) => ?? Really? Now I don't think you've done your homework on MIP6. Hesham _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 06 22:00:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0TS2-0001Dw-8h; Thu, 06 Dec 2007 22:00:30 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J0TS1-0001Dr-Bm for behave-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 22:00:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0TS1-0001Dj-2G for behave@ietf.org; Thu, 06 Dec 2007 22:00:29 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0TS0-0001Xk-OW for behave@ietf.org; Thu, 06 Dec 2007 22:00:29 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Dec 2007 19:00:28 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lB730S4d022975; Thu, 6 Dec 2007 19:00:28 -0800 Received: from dwingwxp01 (sjc-vpn2-1404.cisco.com [10.21.117.124]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lB730RxP023258; Fri, 7 Dec 2007 03:00:27 GMT From: "Dan Wing" To: References: <031101c83762$c7491f80$6e7a150a@cisco.com><4756E0CF.8020800@acm.org> <10d801c83796$975e2250$6e7a150a@cisco.com> Date: Thu, 6 Dec 2007 19:00:27 -0800 Message-ID: <084301c8387d$524dd880$be74150a@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.3198 In-Reply-To: <10d801c83796$975e2250$6e7a150a@cisco.com> Thread-Index: Acg3ZOitfvvp7lNyRbyblrmjceM+3AAMYJLwADezjFA= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=705; t=1196996428; x=1197860428; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20reminder=3A=20TURN=20ad-hoc=20meeting |Sender:=20; bh=no190OfoaxuhmCY9gccYNHJsJCCF4WCEt1pPC2X29/I=; b=crC1KEHoGSCYyILgJGKywK8WYDJNQMMEksUkY2eOUEDrccEQCdDf11e7CRSuVuDG0QyKQivk 6BIvlZtp1XMNChIBr6eRHX04whssfUtuutr7dJzPhXwJUX8z83UYrvUN; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: 'Philip Matthews' Subject: [BEHAVE] reminder: TURN ad-hoc meeting X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 a TURN ad-hoc meeting tonight at 10pm to midnight in the Oak conference room (upper floor in the Westin). There should be a microphone, projector, and audio streaming in the room. I suggest the following agenda: 10:00 TURN extension - Mikael Latvala (give presentation from BEHAVE meeting) 10:10 TURN - Jonathan Rosenberg (finish TURN presentation from the BEHAVE meeting) 10:30 TURN design discussion - all 00:00 finish I have a NOMCOM dinner meeting at 8pm, and I will make every effort to get to the room by 10pm. However, if I am not there please begin promptly without me. Philip has agreed to chair the meeting until I arrive. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 07 02:56:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Y4P-0001kp-P5; Fri, 07 Dec 2007 02:56:25 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J0Y4O-0001kk-V4 for behave-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 02:56:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Y4J-0001hr-Dj for behave@ietf.org; Fri, 07 Dec 2007 02:56:19 -0500 Received: from server.implementers.org ([69.55.225.91]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0Y4J-0005Te-2T for behave@ietf.org; Fri, 07 Dec 2007 02:56:19 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id 582B3D9D403A; Thu, 6 Dec 2007 23:56:16 -0800 (PST) Received: from [192.168.1.3] (c-24-4-253-5.hsd1.ca.comcast.net [24.4.253.5]) by server.implementers.org (Postfix) with ESMTP id B2B34D9D4038 for ; Thu, 6 Dec 2007 23:56:14 -0800 (PST) Message-ID: <4758FC9D.9040104@acm.org> Date: Thu, 06 Dec 2007 23:56:13 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071008) MIME-Version: 1.0 To: behave@ietf.org Subject: Re: [BEHAVE] reminder: TURN ad-hoc meeting References: <031101c83762$c7491f80$6e7a150a@cisco.com><4756E0CF.8020800@acm.org> <10d801c83796$975e2250$6e7a150a@cisco.com> <084301c8387d$524dd880$be74150a@cisco.com> In-Reply-To: <084301c8387d$524dd880$be74150a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 would like to personally thanks all the participants of this meeting who did everything they can to be sure that nobody listening to the audio stream can hear them. On the other hand I knew by this lack of respect that I was listening to the right stream. Dan Wing wrote: > We have a TURN ad-hoc meeting tonight at 10pm to midnight in the Oak > conference room (upper floor in the Westin). There should be a microphone, > projector, and audio streaming in the room. > > I suggest the following agenda: > > 10:00 TURN extension - Mikael Latvala > (give presentation from BEHAVE meeting) > > 10:10 TURN - Jonathan Rosenberg > (finish TURN presentation from the BEHAVE meeting) > > 10:30 TURN design discussion - all > > 00:00 finish > > I have a NOMCOM dinner meeting at 8pm, and I will make every effort to get to > the room by 10pm. However, if I am not there please begin promptly without > me. Philip has agreed to chair the meeting until I arrive. > > -d > -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 07 03:43:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Yo8-00063s-Iu; Fri, 07 Dec 2007 03:43:40 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J0Yo7-0005x9-6g for behave-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 03:43:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Yo6-0005wz-TL for behave@ietf.org; Fri, 07 Dec 2007 03:43:38 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0Yo5-0000Yi-Ic for behave@ietf.org; Fri, 07 Dec 2007 03:43:38 -0500 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id lB78hP2j010096; Fri, 7 Dec 2007 02:43:25 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 02:43:24 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] Brief review of draft-soliman-firewall-control-00.txt Date: Fri, 7 Dec 2007 03:42:39 -0500 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA542EE5@ecamlmw720.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Brief review of draft-soliman-firewall-control-00.txt Thread-Index: Acg4RXeRkQzYfQqzRCeuOtgnTzb5BAAK1JfgAA8ViU4= References: From: "Suresh Krishnan" To: "Hesham Soliman" , "Martin Stiemerling" , X-OriginalArrivalTime: 07 Dec 2007 08:43:24.0917 (UTC) FILETIME=[3AED0A50:01C838AD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: gregdaley@ieee.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi Martin, Thanks for your comments. I am sure there are other protocols which = did parts of what we do, and probably gigantic supersets of what we do. We = will take a closer look at all the references and try to see why they failed to get deployed. Meanwhile, if you can review the protocol itself like = you promised, it would be much more helpful for us to try to improve it. Thanks Suresh _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 07 08:34:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0dLM-0002dC-Q7; Fri, 07 Dec 2007 08:34:16 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J0dLM-0002d7-BK for behave-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 08:34:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0dLM-0002cz-1R for behave@ietf.org; Fri, 07 Dec 2007 08:34:16 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0dLL-0004JX-LP for behave@ietf.org; Fri, 07 Dec 2007 08:34:16 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 07 Dec 2007 05:34:15 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lB7DYFKC023754; Fri, 7 Dec 2007 05:34:15 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lB7DXxxn024618; Fri, 7 Dec 2007 13:34:10 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 08:34:03 -0500 Received: from 10.86.115.68 ([10.86.115.68]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) with Microsoft Exchange Server HTTP-DAV ; Fri, 7 Dec 2007 13:34:03 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 07 Dec 2007 08:34:04 -0500 Subject: Re: [BEHAVE] Brief review of draft-soliman-firewall-control-00.txt From: Melinda Shore To: Reinaldo Penno , Martin Stiemerling , Message-ID: Thread-Topic: [BEHAVE] Brief review of draft-soliman-firewall-control-00.txt Thread-Index: Acg4RXXmKkn6BuwBT7+/OB/JHGm6GAADHjAAAABlg0IAAF+EAAAgNKpT In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280BD8EF38@proton.jnpr.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Dec 2007 13:34:03.0721 (UTC) FILETIME=[D5435B90:01C838D5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1445; t=1197034455; x=1197898455; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshore@cisco.com; z=From:=20Melinda=20Shore=20 |Subject:=20Re=3A=20[BEHAVE]=20Brief=20review=20of=20draft-soliman-firewa ll-control-00.txt |Sender:=20; bh=tT72wQL3lJsZtQZc3o/qUc54fsfKUsDbaPxr6SaWfq8=; b=KRfrjHM0wAIUiPAty2bY8PhLajcd+Ewi2LevqmNzTZYYQEUzz05iN4FD5bAPGK35qxDqlcMX p+T4vjepLNnKL28gTJuU/4jFFHajqYW6SI7iw/pnxw2KNy/tN5UuBDke; Authentication-Results: sj-dkim-4; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 On 12/6/07 5:18 PM, "Reinaldo Penno" wrote: > But I would say that as much as NAT variations cause problems for STUN, > Firewall variations also cause problems for many protocols. For example, > the way different firewalls implementations handle TCP ultimately impact > application protocols that run over it. I think there is also something > to be said about ICMP and others. One of the major barriers to deployment has been that firewall vendors have substantial sunk costs in their existing technologies, and they tend to express those sunk costs as "competitive advantage," product differentiators," and so on. Virtually all of the people driving the traversal work early on, and I think even still, come from the application side - specifically voice/multimedia applications. We've failed to convince the firewall guys that a signaling approach has some advantages over their current proprietary approaches, and I think that it would be extremely difficult to interest them in recommendations for uniform treatment of various transports for similar reasons - it would wipe out what they see as market differentiation. Whether or not you buy that, I don't see any way to change that perception unless and until the traversal work is seen as more fundamental to networking and something of interest to those outside the voice community, frankly. It's a self-perpetuating problem. Melinda _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 07 13:38:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0i5q-0006Yf-2Y; Fri, 07 Dec 2007 13:38:34 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J0i5o-0006YF-Ew for behave-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 13:38:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0i5o-0006Xb-4c for behave@ietf.org; Fri, 07 Dec 2007 13:38:32 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0i5m-00011F-IB for behave@ietf.org; Fri, 07 Dec 2007 13:38:32 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 07 Dec 2007 10:38:29 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB7IcUur024326; Fri, 7 Dec 2007 10:38:30 -0800 Received: from dwingwxp01 ([10.21.118.143]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lB7IcSqa010936; Fri, 7 Dec 2007 18:38:29 GMT From: "Dan Wing" To: "'Marc Petit-Huguenin'" , References: <031101c83762$c7491f80$6e7a150a@cisco.com><4756E0CF.8020800@acm.org> <10d801c83796$975e2250$6e7a150a@cisco.com><084301c8387d$524dd880$be74150a@cisco.com> <4758FC9D.9040104@acm.org> Subject: RE: [BEHAVE] reminder: TURN ad-hoc meeting Date: Fri, 7 Dec 2007 10:38:26 -0800 Message-ID: <000101c83900$5c9bd980$8f76150a@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: Acg4prFGAwi0qU/hSUCrk1Sm8tCIMQAUQTwg In-Reply-To: <4758FC9D.9040104@acm.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2218; t=1197052710; x=1197916710; 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]=20reminder=3A=20TURN=20ad-hoc=20meeting |Sender:=20; bh=i/zb02qIZudssq2lz0VO7OrmK7UQFqKgiJJE/CuYarA=; b=KVaPlLCqgZ1SANIjEXDNvO/ABRZQqtEFoBbtb0LhiUK1SmKJwngIAzbMG2KH+5vy5fCSpapE CpDbO+D7x5cXBn1VKZ1HpU6Xs9cXCbUE2E/r3OZqUjkMcOZEnBFK8iDf; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 Yes, that was disrespectful. I apologize. We had only 12 people in the room and did not use a microphone for floor control. I had expected much more (which is why we switched to a larger room). The last hour was spent looking over message flow diagram on paper which compared EKR's proposal to a turn-05 flow. Jonathan is going to email each individual issue to the list, with message flows, on the design decisions reached. -d > -----Original Message----- > From: Marc Petit-Huguenin [mailto:petithug@acm.org] > Sent: Thursday, December 06, 2007 11:56 PM > To: behave@ietf.org > Subject: Re: [BEHAVE] reminder: TURN ad-hoc meeting > > I would like to personally thanks all the participants of this meeting > who did everything they can to be sure that nobody listening to the > audio stream can hear them. > > On the other hand I knew by this lack of respect that I was > listening to > the right stream. > > > Dan Wing wrote: > > We have a TURN ad-hoc meeting tonight at 10pm to midnight in the Oak > > conference room (upper floor in the Westin). There should > be a microphone, > > projector, and audio streaming in the room. > > > > I suggest the following agenda: > > > > 10:00 TURN extension - Mikael Latvala > > (give presentation from BEHAVE meeting) > > > > 10:10 TURN - Jonathan Rosenberg > > (finish TURN presentation from the BEHAVE meeting) > > > > 10:30 TURN design discussion - all > > > > 00:00 finish > > > > I have a NOMCOM dinner meeting at 8pm, and I will make > every effort to get to > > the room by 10pm. However, if I am not there please begin > promptly without > > me. Philip has agreed to chair the meeting until I arrive. > > > > -d > > > > -- > Marc Petit-Huguenin [ ] > Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] > Work: marc@8x8.com [ ] > [ ] > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 07 14:02:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0iSs-0004GH-Sl; Fri, 07 Dec 2007 14:02:22 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J0iSr-0004AG-LV for behave-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 14:02:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0iSr-00049p-BU for behave@ietf.org; Fri, 07 Dec 2007 14:02:21 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0iSp-0002jV-SP for behave@ietf.org; Fri, 07 Dec 2007 14:02:21 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 07 Dec 2007 11:02:09 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lB7J29MB001271 for ; Fri, 7 Dec 2007 11:02:09 -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 lB7J29vr022786 for ; Fri, 7 Dec 2007 19:02:09 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 11:02:09 -0800 Received: from [10.21.85.104] ([10.21.85.104]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 11:02:08 -0800 Message-ID: <475998D7.8010903@cisco.com> Date: Fri, 07 Dec 2007 14:02:47 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Dec 2007 19:02:08.0974 (UTC) FILETIME=[AA9696E0:01C83903] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=13954; t=1197054129; x=1197918129; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Alternative=20channel=20binding=20mechanism=20for=20TURN |Sender:=20; bh=LwvuRCJSixtQ2l1Uhw3+q6Hb1Ay4NYQFlOqSOTL52o8=; b=eyCHFwdX5l3Yh4RinB5djulhgqhTWMHHYMSO0Zl+Tjjn3eer02r40PSEn8jclkOTqEs00O/m Wua2eN6oqdUfxH4nhRFmqTadE9QcKYkb3mnHw9lOQyUbtWO5KUvsVWEQ4onLH7HOQG7gwU9hlx xjeb6Pvp/XME/9fSboj2liGMw=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Subject: [BEHAVE] Alternative channel binding mechanism for TURN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Several folks met last night at the TURN ad-hoc to discuss the various open issues. One of the biggest was whether we should change the channel binding mechanism from what is in the document (using Send along with a confirmation indication) to what ekr suggested. We wrote down what that alternate flow would look like and came up with pros and cons. Here is what we came up with. The mechanism that ekr is proposing basically looks like this: Client TURN Server Peer Peer2 | | | | | | | | | | | | |(1) [0]Allocate | | | |--------------->| | | | | | | | | | | |(2) [0]AllocOK | | | |<---------------| | | | | | | | | | | |Data to send | | | | | | | | | | | | | | | |(3) [0]ChannelBind(7) | | |--------------->| | | | | | | | | | | |(4) [0]Send | | | |--------------->| | | | | | | | | | | | |(5) UDP Packet | | | |--------------->| | | | | | | | | | |(6) [0]BindOK | | | |<---------------| | | | | | | | | | | |(7) [7]UDP Packet | | |--------------->| | | | | | | | | | | | |(8) UDP Packet | | | |--------------->| | | | | | | | | | | |(9) UDP Packet | | | |<---------------| | | | | | | | | | |(10) [7]UDP Packet | | |<---------------| | | | | | | | | | | | |(11) UDP Packet | | | |<--------------------------------| | | | | | | | | | |Permission Open | | | | | | | | | | | | | | |(12) [0]Data Ind. | | |<---------------| | | | | | | | | | | |(13) [0]ChannelBind(8) | | |--------------->| | | | | | | | | | | |(14) [0]BindOK | | | |<---------------| | | | | | | | | | | | |(15) UDP Packet | | | |<--------------------------------| | | | | | | | | |(16) [8]UDP Packet | | |<---------------| | | | | | | | | | | | | | | | | | | In terms of notation, the square brackets in front of a TURN message indicate what channel that message is on. The client does the Allocate as currently defined (messages 1,2). Shortly thereafter, the client has data to send. It knows that it will have a bunch of data, so it would like to create a channel for communications with the specific peer. One of the benefits of this proposed flow (noted further below), is that by separating data transmission from channel binding, we can make channel binding something a client can do at its discretion. In this case, it wants to bind a channel for this particular peer. So, it sends a ChannelBind transaction, on the turn channel (channel 0). The client requests channel 7 for communications to and from the peer. At this point, the client is prepared to receive data on channel 7. In ekr's proposed flow, there is a single channel number for traffic both to and from a particular peer. When the server receives the ChannelBind, it creates channel 7 and maps it to the peer. From this point forward, the server will relay traffic from that peer, towards the client, over channel 7. Furthermore, it will accept traffic from the client, on channel 7, and forward to the peer. Note that, even though the client has not received the response to the ChannelBind request, the server is guaranteed that the client is prepared to receive data on channel 7. However, the client doesn't want to wait for the ChannelBind response to send the data. Until it gets that response, it cannot send data over that channel. So, until then, it sends data encapsulated using the Send indication (message 4). When the server receives this, it relays the data to the peer (message 5) and opens a permission to the corresponding IP address (the folks in the room last night were unsure if ChannelBind also creates a permission, with opinion slightly in favor of no). Now, at some point the ChannelBind response is received by the client (message 6). After that point, the client can now send data to this peer unencapsulated, on the bound channel. So, it uses channel 7 (message 7) and the TURN server relays data to the peer (message 8). Now, the peer sends data towards the TURN server (message 9). In this particular case, a channel has already been bound to this peer on the TURN server. So, the TURN server sends the data to the client on the existing channel (message 10). Another peer (for example), with the same IP address but from a different port, now sends data to the TURN server (message 11). Since a permission is open for this IP address, the TURN server will relay the data to the client. However, there is no channel bound for this peer. As a consequence, the server encapsulates the data in a Data indication (message 12). Note that, the server itself does NOT try to bind a channel. Only the client can do that. Instead, the client, upon receiving the data, decides it would like a channel for this second peer. So, it sends a ChannelBind (message 13) for this new peer. This is received by the TURN server and it binds channel 8 to this peer, and sends the response (message 14). Now, when the next datagram arrives from this new peer (message 15), it is sent to the client unencapsulated on channel 8 (message 16). In comparing this technique (Ekrs Technique) with the one in draft-ietf-behave-turn-05 (Current Technique), we came up with the following pros and cons: Ekrs Technique -------------- PRO: Allows the client to decide, on a case by case basis, whether to pay the overhead (ChannelBind transaction) to bind a channel to a peer. For example, in ICE exchanges, the client could skip channel binding for the connectivity checks, and only do the binding if ICE selects the peer transport address. PRO: Related to the previous point, the current channel binding mechanism does not allow a client to remove or delete a channel binding. Thus, for an allocation which is very long lived, the client could eventually run out of channels and need to re-allocate to clear them all or get more channels. Since Ekrs Technique allows the client to selectively channel bind, when used with protocols like ICE where it is not needed to channel bind for all peers, the allocation will 'last longer' - that is, channel numbers get exhausted more slowly. Architecturally, this is because Ekrs Technique separates channel binding and data transmission, whereas the Current Technique combines them. CON: Under packet loss, it is possible that the ChannelBind request could be lost. If so, it will be retransmitted an RTO later. This means that, the amount of time between request and response is equal to RTT + 2^N * RTO, where N is the number of packet losses. The client cannot send unencapsulated data until the ChannelBind response is received. This duration is therefore equal to RTT+ 2^N*RTO, which is longer than the Current Technique. There was split opinions on whether this was a big deal or not, but it is a CON. PRO: Seems simpler to have a single channel number for messages in both directions PRO: If a channel binding is in place for a peer, the first data from that peer can be sent immediatley unencapsulated. With the Current Technique, since channel numbers are always different in each direction, the first packet (and indeed, the first RTT set of packets after the first) will be sent encapsulated. PRO: there is a documented security concern with the Current Technique in TURN-5. Since ChannelConfirm is an indication, it is unauthenticated. An attacker could, upon seeing a Send indication from a client, send a faked ChannelConfirm indication, and then cause the Send request to be discarded. As a consequence, the client will believe the channel is bound, when it is not. The client will, for the remaining duration of the allocation, send data on that channel, and it will be discarded by the TURN server. The client will not know that this happened. With Ekrs Technique, this attack is mitigated. PRO: Does not require the client to receive requests and send responses. There has been some debate on whether this is important. Note that this PRO is shared by both techniques. PRO: A client could, as a matter of local implementation choice, elect to not implement or use Send. Instead, it can wait for channels to be bound and send data unencapsulated. This does mean that clients would either drop data to be send prior to receiving the ChannelBind response, else delay sending to that time. Current Technique ----------------- CON: Each Send indication (and Data indication) causes a ChannelConfirm indication. If the client is sending a lot of data, say, at rate R, this will cause R*RTT number of ChannelConfirm messages to be sent. In essence, the server 'spams' the client will redundant ChannelConfirm messages, even when there was no packet loss. PRO: The amount of time until a client can sent unencapsulated data is equal to RTT + T*N, where N is the number of packet losses and T is the inter-arrival time between data from client to the peer. This number will typically be lower than Ekrs Technique under conditions of packet loss. Note that they are identical in conditions of no packet loss. PRO: In the case of TCP between client and server, the server can omit sending ChannelConfirm and the client can send data unencapsulated immediately. With Ekrs technique, the client can also send data unencapsulated immediately, but since ChannelBind is a transaction, a response is still required. PRO: Does not require the client to receive requests and send responses. There has been some debate on whether this is important. Note that this PRO is shared by both techniques. Of the folks present, most (including myself) were in favor of Ekrs Technique. Consequently, we'd like to confirm this decision, and see if there is rough consensus to go with Ekrs technique. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 07 14:15:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0ifZ-0000zo-HC; Fri, 07 Dec 2007 14:15:29 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J0ifY-0000zj-8j for behave-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 14:15:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0ifX-0000wv-AK for behave@ietf.org; Fri, 07 Dec 2007 14:15:27 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0ifW-000303-Rm for behave@ietf.org; Fri, 07 Dec 2007 14:15:27 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 07 Dec 2007 11:15:25 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lB7JFQuM029766 for ; Fri, 7 Dec 2007 11:15:26 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lB7JEaxt003243 for ; Fri, 7 Dec 2007 19:15:26 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 11:15:11 -0800 Received: from [10.21.85.104] ([10.21.85.104]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 11:15:11 -0800 Message-ID: <47599BE6.9090903@cisco.com> Date: Fri, 07 Dec 2007 14:15:50 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Dec 2007 19:15:11.0328 (UTC) FILETIME=[7CE85600:01C83905] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2129; t=1197054926; x=1197918926; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20TURN=20Issue=20#1=3A=20Bandwidth=20Param |Sender:=20; bh=NupJVgOkPXkdOJ+SyhMZRU5SYbvas5SYujFCYj7FToE=; b=s2OSzewcQHiQrGvQpQt/oYJxQSxZG9p6dk6dfNA5jx/kX37LeSRm5q0Vq8qe/mlf6Xj9zY2y +KiuInMymUcNtv9SZh4PWMZd4E5zBHujPeG9Xe8HgsTIVPNaThx8lQEuEbKhiDi5N9myK9BVir wWYsHZ12EBdTMeGEt06jEx7iM=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [BEHAVE] TURN Issue #1: Bandwidth Param X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Open issue #1 from my slides (discussed during the WG meeting and at the ad-hoc), is the Bandwidth param. The issue is, its ill-defined right now. If no one wants it, we should drop it. If someone wants it, we need to define it. During the WG meeting, folks spoke out in favor of it. Apparently there is currently deployed usage of this parameter. It is not being used for capacity planning. Rather, it is being used to rate limit consumers so a customer doesn't abuse the TURN server. Folks running that deployment strongly believed that the mechanism was needed. So, the proposal is to keep this parameter. I have reached out to folks involved in RSVP to help us reuse a precise definition of how to measure the bandwidth parameter, since this is not a new problem. The proposed semantics would be something like this: Client MAY include bandwidth in a request. If present, it is a request from the client that the server forward traffic to and from the client such that the total in each direction will not be excess of this value. Server MAY include a value in a response, even if there was not one in a request. The meaning of the value in the response, is that the server agrees to forward traffic to/from the client so long as it is below the bandwidth value. Any traffic above that value may be dropped by the server. If there is no value in the response, the server will relay traffic at best effort. Furthermore, there is never an absolute guarantee that the server will be able to relay data even if the usage is below the bandwidth parameter, and clients MUST be prepared for packet loss. Of course, there could be packet loss outside of the TURN server anyway. Please comment if you are happy (or not) with keeping bandwidth with these proposed semantics. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 07 14:21:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0ilF-0007P4-HS; Fri, 07 Dec 2007 14:21:21 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J0ilD-0007Ot-Km for behave-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 14:21:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0ilD-0007Ol-9y for behave@ietf.org; Fri, 07 Dec 2007 14:21:19 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0ilC-0003Pg-R3 for behave@ietf.org; Fri, 07 Dec 2007 14:21:19 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 07 Dec 2007 11:21:18 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lB7JLIcU009313 for ; Fri, 7 Dec 2007 11:21:18 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lB7JLDxT012049 for ; Fri, 7 Dec 2007 19:21:18 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 11:21:13 -0800 Received: from [10.21.85.104] ([10.21.85.104]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 11:21:13 -0800 Message-ID: <47599D4F.50102@cisco.com> Date: Fri, 07 Dec 2007 14:21:51 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Dec 2007 19:21:13.0442 (UTC) FILETIME=[54BE8C20:01C83906] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2274; t=1197055278; x=1197919278; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20TURN=20Issue=20#2=3A=20Stateful=20allocations |Sender:=20; bh=s0zAN2dul1mzRbdXkiIJ4Zf0Njukwc598PpUm17cFy8=; b=QcKrKPcQ0T6TjuJgeUkPoimNnPXgLhPgGM4Vk133EF6QD2RPFnL8vpmYpBvo5Qw0N4s+ZlJa vjBEMCv/izUXLfpZYF6lSRpXI2ju2RJcgjDxZTbRVYbIl1hrn4YB10ddWeZoJYAf7pJvPUBh/e 2T+BAhjH/Nr9YMp3nxP6YDDEA=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [BEHAVE] TURN Issue #2: Stateful allocations X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 did not get a chance to discuss this issue in the WG meeting. It was discussed briefly during the ad-hoc. The issue is that, as of TURN-05, refreshes are now done with an explicit Refresh request, not an Allocate request. A consequence of this is that, if a server receives an Allocate request for an existing allocation, it has to reject it with a 487. Of course, if a server receives a retransmit of an initial Allocate request, for which it had already send a successful response, it retransmits that successful response. This, in turn, means that a server would require different treatment for a retransmitted Allocate request and a new Allocate request. These would differ only by transaction ID. This, then, requires that a TURN server be transaction stateful, remembering transaction state for some duration (there is a value in rfc3489bis defined I believe). This differs from a STUN server, which can typically statelessly respond to requests without having transaction state. Note that my slides are in error, and incorrectly show the flow. The final message in the flow in the slides should be 200 and not 487. This caused some confusion during the ad-hoc. There was general agreement at the ad-hoc that this is a non-issue. TURN servers are already required to maintain state, in the form of allocations, permissions, channel bindings, and so on. Transaction state is not much more. Note that, rfc3489bis requires stun transactions (including extensions like TURN) to be idempotent. Note that, despite the different response codes for a retransmit and new transaction, TURN remains idempotent. Idempotency only requires that subsequent retries do not alter the state on the server; it does NOT require the same response. We went through this ad-nauseum on XCAP. The proposal is therefore to just document this fact, but otherwise not change anything. Please comment if you agree (or not) with this. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 07 14:38:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0j1V-00086R-3o; Fri, 07 Dec 2007 14:38:09 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J0j1T-0007xV-Lp for behave-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 14:38:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0j1T-0007vf-BV for behave@ietf.org; Fri, 07 Dec 2007 14:38:07 -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 1J0j1S-0004kU-Kn for behave@ietf.org; Fri, 07 Dec 2007 14:38:07 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 07 Dec 2007 11:38:07 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lB7Jc6eL026869 for ; Fri, 7 Dec 2007 11:38:06 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lB7Jbqxp001248 for ; Fri, 7 Dec 2007 19:38:06 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 11:37:57 -0800 Received: from [10.21.85.104] ([10.21.85.104]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 11:37:57 -0800 Message-ID: <4759A13C.8080106@cisco.com> Date: Fri, 07 Dec 2007 14:38:36 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Dec 2007 19:37:57.0496 (UTC) FILETIME=[AB350780:01C83908] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4531; t=1197056286; x=1197920286; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20TURN=20Issue=20#3=3A=20Address=20v.=20Address=20and=20Port=20 Restricted |Sender:=20; bh=jJGDGmFJhg711ktA3xF1CVp51seBJjwgNe4y3xMk+MU=; b=sgSdyAquehJps98+l2xxTvCpG/4ZVmHHnHd/E+3Dy84la1H+pf7gc+2BsgWLl8/sOU4/iPEn iZIDoeMPmeaMOev3vteK/W401VbgYhJQ9eKRn5GshwUxttbihqNEYvOS; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: [BEHAVE] TURN Issue #3: Address v. Address and Port Restricted X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 issue was not discussed at the WG meeting, but generated a bunch of discussion at the ad-hoc. The issue is this. Currently, a TURN server basically acts like a NAT whose filtering behavior is address-dependent [RFC4787]. RFC 4787 has this to say on this property: REQ-8: If application transparency is most important, it is RECOMMENDED that a NAT have an "Endpoint-Independent Filtering" behavior. If a more stringent filtering behavior is most important, it is RECOMMENDED that a NAT have an "Address-Dependent Filtering" behavior. Note that this is a SHOULD and not a MUST. One of the reasons for that, is that there is a belief that some firewall or NAT vendors or operators would believe (true or not) that address and port restricted NAT behavior is 'more secure'. A huge governing principle of TURN is that, firewall admins would not be afraid of TURN and would not block it, because it doesn't lessen the security properties of a firewall in any way; it merely transforms an address or address-and-port depending mapping NAT and an address-and-port dependent filtering NAT, into one that is endpoint independent mapping and address dependent filtering, which does not lessen security. The problem is, we may all believe that to be true, but firewall admins may not, and thus block TURN anyway. An alternative proposal, therefore, would be to make a TURN server address and port restricted filtering. If this is done, we would end up with several cases with ICE where two TURN servers get used. Also ICE would operate more slowly. In particular, if agents A and B are both behind an address-dependent mapping NAT, two TURN servers would be used. With the current design, its just one. Some of the folks in the ad-hoc proposed that, this was not actually a bug. The reason is that the current mechanism misplaces incentives. An address-dependent filtering behavior in the TURN server allows my TURN server to fix the problem of SOMEONE ELSES NAT. Thus, the worry was that provider X would deploy ICE but skip a TURN server, since it would just assume that other providers it was connecting to would deploy TURN, and if they did, provider X would not need a TURN server. If provider Y came to the same conclusion, neither would deploy TURN. Making TURN address-and-port dependent filtering would basically force each provider to deploy TURN to fix its own NAT problems. Others, myself included, did not agree with this analysis. I believe that providers will due what is needed to make their service work. Any provider that skips TURN since they are betting that other providers deploy it, will probably not be in business long. So I do not agree this is a problem. Another issue that came up is, forgetting inter-provider calls, moving to address-and-port restricted behavior in TURN servers will make things worse in a single domain deployment (which is 100% of the cases today). If you have regional TURN servers in different data centers, and a customer associated with one TURN server calls a customer associated with another, you'd incur the cost of two TURN servers. The most expensive part of that is the traffic in and out of the data center. The secondary cost would be the server capacity. The folks with an existing deployment were in the ad-hoc and confirmed that a multi-data center deployment was a concern and they were worried about this issue. We also recognized that user A could call user B, and both be on the *same* TURN server. The TURN server needs to hairpin. This is unrelated to this issue, but undocumented in the current TURN spec, and we need to document that a TURN server needs to be prepared for this. So, amongst the folks present in the ad-hoc, we agreed that the existing address-dependent filtering behavior was better and we'd like to stick with that. However, we need to get input from folks in the security area to get some feedback on whether this would pose a concern in deployments. Magnus agreed to help us reach out to sec-dir to get some of that input. If you agree (or not) with this conclusion, please speak up. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 07 15:41:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0k0K-0005m6-6T; Fri, 07 Dec 2007 15:41:00 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J0k0J-0005ej-1n for behave-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 15:40:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0k0I-0005dx-MY for behave@ietf.org; Fri, 07 Dec 2007 15:40:58 -0500 Received: from server.implementers.org ([69.55.225.91]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0k0I-0008Tl-46 for behave@ietf.org; Fri, 07 Dec 2007 15:40:58 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id 798B0D9D403C; Fri, 7 Dec 2007 12:40:57 -0800 (PST) Received: from [192.168.1.3] (c-24-4-253-5.hsd1.ca.comcast.net [24.4.253.5]) by server.implementers.org (Postfix) with ESMTP id 8C1D3D9D403A; Fri, 7 Dec 2007 12:40:54 -0800 (PST) Message-ID: <4759AFD5.7030200@acm.org> Date: Fri, 07 Dec 2007 12:40:53 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071008) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [BEHAVE] TURN Issue #1: Bandwidth Param References: <47599BE6.9090903@cisco.com> In-Reply-To: <47599BE6.9090903@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Jonathan Rosenberg wrote: > Open issue #1 from my slides (discussed during the WG meeting and at the > ad-hoc), is the Bandwidth param. The issue is, its ill-defined right > now. If no one wants it, we should drop it. If someone wants it, we need > to define it. > > During the WG meeting, folks spoke out in favor of it. Apparently there > is currently deployed usage of this parameter. It is not being used for > capacity planning. Rather, it is being used to rate limit consumers so a > customer doesn't abuse the TURN server. Folks running that deployment > strongly believed that the mechanism was needed. > > So, the proposal is to keep this parameter. I have reached out to folks > involved in RSVP to help us reuse a precise definition of how to measure > the bandwidth parameter, since this is not a new problem. The proposed > semantics would be something like this: > > Client MAY include bandwidth in a request. If present, it is a request > from the client that the server forward traffic to and from the client > such that the total in each direction will not be excess of this value. > Server MAY include a value in a response, even if there was not one in a > request. The meaning of the value in the response, is that the server > agrees to forward traffic to/from the client so long as it is below the > bandwidth value. Any traffic above that value may be dropped by the > server. If there is no value in the response, the server will relay > traffic at best effort. Furthermore, there is never an absolute > guarantee that the server will be able to relay data even if the usage > is below the bandwidth parameter, and clients MUST be prepared for > packet loss. Of course, there could be packet loss outside of the TURN > server anyway. > > Please comment if you are happy (or not) with keeping bandwidth with > these proposed semantics. > I am OK with keeping bandwidth, but I would like to add one thing. The problem with bandwidth is when TURN is used with ICE. A TURN allocation will be made but it will generally not be used excepted for connectivity checks (i.e. far less than the bandwidth that will be used for video). So most TURN servers used in an ICE environment will either oversubscribe or waste resources. Now if the TURN server knew the *intent* of an allocation, it could have used it and statistics collected from previous allocation's bandwidth usage to keep a good balance between oversubscription and resource wasting. So I am proposing to have an additional attribute sent by the client in the allocation that would tell the server if the allocation is meant for ICE, or for another usage of TURN. Thanks. -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 07 15:57:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0kGL-0007k3-5d; Fri, 07 Dec 2007 15:57:33 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J0kGK-0007jH-15 for behave-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 15:57:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0kGJ-0007j4-Nb for behave@ietf.org; Fri, 07 Dec 2007 15:57:31 -0500 Received: from server.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0kGI-0001UX-7t for behave@ietf.org; Fri, 07 Dec 2007 15:57:31 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id A0135D9D403C; Fri, 7 Dec 2007 12:57:29 -0800 (PST) Received: from [192.168.1.3] (c-24-4-253-5.hsd1.ca.comcast.net [24.4.253.5]) by server.implementers.org (Postfix) with ESMTP id 3A50CD9D403A; Fri, 7 Dec 2007 12:57:27 -0800 (PST) Message-ID: <4759B3B6.9000604@acm.org> Date: Fri, 07 Dec 2007 12:57:26 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071008) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [BEHAVE] Alternative channel binding mechanism for TURN References: <475998D7.8010903@cisco.com> In-Reply-To: <475998D7.8010903@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 Jonathan Rosenberg wrote: > Several folks met last night at the TURN ad-hoc to discuss the various > open issues. One of the biggest was whether we should change the channel > binding mechanism from what is in the document (using Send along with a > confirmation indication) to what ekr suggested. We wrote down what that > alternate flow would look like and came up with pros and cons. Here is > what we came up with. > I am in favor of the new technique, mostly because of the security issue it fixes. This said changing basic stuff like this each 4 months is way past annoying. Couldn't EKR be part of the design team? The first version of TURN was released November 14, 2001. 6 years after I still have nothing to deploy. -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 07 16:04:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0kNK-0001aP-Oo; Fri, 07 Dec 2007 16:04:46 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J0kNJ-0001a7-KF for behave-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 16:04:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0kNJ-0001Zz-9y for behave@ietf.org; Fri, 07 Dec 2007 16:04:45 -0500 Received: from server.implementers.org ([69.55.225.91]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0kNI-0002D5-Ub for behave@ietf.org; Fri, 07 Dec 2007 16:04:45 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id 98AA0D9D4038; Fri, 7 Dec 2007 13:04:44 -0800 (PST) Received: from [192.168.1.3] (c-24-4-253-5.hsd1.ca.comcast.net [24.4.253.5]) by server.implementers.org (Postfix) with ESMTP id 67423D9D403C; Fri, 7 Dec 2007 13:03:23 -0800 (PST) Message-ID: <4759B51B.7000207@acm.org> Date: Fri, 07 Dec 2007 13:03:23 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071008) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [BEHAVE] TURN servers available for testing References: <47530DC6.6020000@acm.org> <47547EEE.4070307@cisco.com> In-Reply-To: <47547EEE.4070307@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 Obviously with the last change on the basic mechanism of TURN, I have to withdraw this offer. I also had a TURN dissector for Wireshark ready that will have to go back to the workshop. Even if a new I-D is published soon, there will be no new implementation until after my vacations. Jonathan Rosenberg wrote: > Thank you Marc! I applaud you and 8x8 for doing this. > > Thanks, > Jonathan R. > > Marc Petit-Huguenin wrote: >> To accelerate the development of TURN clients compliant with >> draft-ietf-behave-05, 8x8 Inc. (provider of the Packet8 service) is >> sponsoring the deployment of TURN servers that can be freely used for >> testing. >> >> If you are interested in testing your TURN client with our servers, >> please send me an email at marc@8x8.com. I'll reply in the next days >> with the instructions to setup an account. >> >> Please do not CC the mailing-list when responding to this email. >> >> Thanks. >> > -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Dec 08 01:57:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0td1-0005fB-GI; Sat, 08 Dec 2007 01:57:35 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J0td0-0005f6-Rw for behave-confirm+ok@megatron.ietf.org; Sat, 08 Dec 2007 01:57:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0td0-0005ey-Ey for behave@ietf.org; Sat, 08 Dec 2007 01:57:34 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0tcz-0003f1-Tv for behave@ietf.org; Sat, 08 Dec 2007 01:57:34 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 07 Dec 2007 22:57:23 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lB86vNP7012546 for ; Fri, 7 Dec 2007 22:57:23 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lB86vI87011437 for ; Sat, 8 Dec 2007 06:57:23 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 22:57:18 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 22:57:17 -0800 Message-ID: <4759CC2B.9050206@cisco.com> Date: Fri, 07 Dec 2007 17:41:47 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Dec 2007 06:57:18.0031 (UTC) FILETIME=[926115F0:01C83967] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1852; t=1197097043; x=1197961043; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20TURN=20Issue=20#4=3A=20Port=20Adjacency |Sender:=20; bh=++7u87KP1DupOKD5avH0+SMpxBsCRyHen082h6lhggY=; b=tXP2SqZuqTi/WuJKgPrU1Kpm+ANGdIFF/1iNX682mqiDufjg2X2UaBLjgytI5SXvhpbHfhkZ GPmSpLBSN8v5Tfxhw6rrtTrK/Y2+BHjxXu23h9PmCzGf0Q47rfO6VEqs; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -2.1 (--) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [BEHAVE] TURN Issue #4: Port Adjacency X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 didn't get covered in the WG meeting but was discussed in the ad-hoc. TURN allows a client to request an even port, and along with it, ask the TURN server to allocate the odd port one higher. However, the spec currently has the following confusing words in it: As such, it is a request for the server to allocate an even port whose next higher port is also available, and furthermore, a request for the server to not allocate that one higher port to any other request except for one that asks for that port explicitly. The server can honor this request for adjacency at its discretion. The only constraint is that the allocated port has to be even. This would seem to imply that a server could respond with an OK response, allocate the even port, but not even bother with the odd port. Thus, when the client tries the odd port, it gets rejected. So the client has to try again. This non-deterministic behavior would complicate the client. The options were: 1. ditch the feature 2. make it so that the server MUST allocate the even port and the next higher odd port, and if it can't do both, reject the request. After allocating both, it holds onto the odd port, waiting for the client to request it, for: a. some fixed time, say 30s b. the duration of the allocation Folks still wanted this feature since it is used in practice. In the interests of avoiding another timer, there was agreement on 2b. Please comment if you agree (or if you don't) on this conclusion. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Dec 08 02:09:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0toP-0005Iy-Du; Sat, 08 Dec 2007 02:09:21 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J0toO-0005Ie-AC for behave-confirm+ok@megatron.ietf.org; Sat, 08 Dec 2007 02:09:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0toO-0005IW-0E for behave@ietf.org; Sat, 08 Dec 2007 02:09:20 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0toN-00046P-LZ for behave@ietf.org; Sat, 08 Dec 2007 02:09:19 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 07 Dec 2007 23:09:19 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lB879JkM012320 for ; Fri, 7 Dec 2007 23:09:19 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lB879IqZ018786 for ; Sat, 8 Dec 2007 07:09:18 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 23:09:18 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 23:09:18 -0800 Message-ID: <4759CD14.10208@cisco.com> Date: Fri, 07 Dec 2007 17:45:40 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Dec 2007 07:09:18.0734 (UTC) FILETIME=[3FF3A2E0:01C83969] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1072; t=1197097759; x=1197961759; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20TURN=20Issue=20#5=3A=20Port=20Range |Sender:=20; bh=e1xHKFUZ0yfqzuHDjiXyXI6g7WXv4R4UoRuHC2coiDg=; b=geDNh6puVqhj2tPZh30SKite3WRpl7Z0aB2bZ16+0G39tXjtNxZH1jwDV2K4ihKdwONBB26d hiRf65oWJnBlpCajFxmURKkaJEDzaaxMsaYMybmuvI3hxAdYLfmQ1TyZy+gxN6NFUc0sRsrf6i /ZjTuiBak2G/77K4c8sU3outI=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -2.1 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [BEHAVE] TURN Issue #5: Port Range X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 was not discussed in the WG meeting and had a brief discussion in the ad-hoc. TURN currently says that a TURN server SHOULD only utilize ports in the range 1024-65535, avoiding the well-known ports from 1-1023. There was a request from Derek to make this a MUST. Note, however, that it is not this restriction, but the server behavior around permissions, which makes it impossible to run a general purpose server on a specific port. Most everyone still felt SHOULD is fine. My litmus test for SHOULD vs. MUST is, would the protocol cease to interoperate, lose functionality, or otherwise not work if the SHOULD were not followed. That is clearly not the case here, so a SHOULD is appropriate. Please respond if you agree (or if you don't). Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Dec 08 02:09:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0toR-0005Kt-LA; Sat, 08 Dec 2007 02:09:23 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J0toQ-0005K5-AJ for behave-confirm+ok@megatron.ietf.org; Sat, 08 Dec 2007 02:09:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0toP-0005JH-UA for behave@ietf.org; Sat, 08 Dec 2007 02:09:21 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0toP-00046P-98 for behave@ietf.org; Sat, 08 Dec 2007 02:09:21 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 07 Dec 2007 23:09:21 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lB879LQ7030189 for ; Fri, 7 Dec 2007 23:09:21 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lB879KxP003056 for ; Sat, 8 Dec 2007 07:09:20 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 23:09:20 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 23:09:20 -0800 Message-ID: <4759D19B.50005@cisco.com> Date: Fri, 07 Dec 2007 18:04:59 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Dec 2007 07:09:20.0405 (UTC) FILETIME=[40F29C50:01C83969] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4829; t=1197097761; x=1197961761; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20TURN=20Issue=20#6=3A=20Framing=20header=20for=20actual=20TURN =20messages |Sender:=20; bh=dLu87SUzoT+nGRLRwZ67RtsDWbY4EH3i4n4gOITCLNw=; b=ats7Byst5Ht2fJQAIrZMZomXaXDP8A10h1efIRLjkGSffc4j6FK9fqD7jnukyuB8NYldfQnf 2R9U6iqzFPEULQnCnmOeoSzY7RKnQk5NxteJYgmvQwRV+Mvw87dzsHWn; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -2.1 (--) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Subject: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 issue was not in my slides. It was brought up at the mike in the WG, and was discussed there. It was not discussed further at the ad-hoc. As of turn-05, we introduced a framing mechanism, which is a 4 byte header consisting of 2 bytes channel and 2-bytes length. This framing header precedes ALL packets sent between a client and its TURN server, including both application data and TURN messages themselves, which are sent on channel zero. Ekr raised a question of why this header was needed for actual TURN messages. After all, he argued, we went through all this trouble to make STUN (and thus TURN) differentiatable from each other. Indeed, others noted that the framing header itself looks very similar to the top 4 bytes of the STUN message format anyway: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0| STUN Message Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Transaction ID (96 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and the proposed framing header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Channel | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ So an alternative design is to make the framing header look like: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Channel | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ So that there are 15 bits of channel instead of 16. Placing a 1 in that position makes the framing header always a non-match for STUN messages. Thus, it would not be even needed to do the more complex matching operations defined in STUN; a 1-bit check would do the job to separate out application data from STUN/TURN. The benefits of this change would be: 1. We would, once again, be able to run STUN and TURN on the same port on the server. As of turn-05 they MUST run on different ports because the framing header was unique to TURN. This could be a feature or a bug depending on your perspective: FEATURE: TURN and STUN are actually very different; using separate ports would allow a firewall to block one and not the other. BUG: practically speaking separate ports doesnt help since with DNS the ports can be dynamic anyway. In addition, its always good to use fewer ports on a server. Also its weird that an extension to a protocol would run on a different port; that kind of tells you its not an extension. 2. Reduces the size of TURN messages by 4 bytes. This is a minor benefit and the real one is having a single port. 3. it'd be a little clearer to explain to people that TURN is an extension to STUN, rather than saying, TURN is a STUN extension that is run over a new framing header The drawbacks of this change would be: 1. cuts the number of channels in half An alternative design would be to use the full 16 bits for channel numbers, and then rely on the full suite of STUN differentiation techniques to demux. However, my preference in general is to not do that when its not actually needed. It complicates message processing and I don't think its worth it. 32767 channels is also a LOT for our envisioned use cases. This was somewhat inconclusive at the microphone. I'm personally on the fence and don't feel that strongly. I probably midly prefer making this change. Please comment on whether you prefer this change or not. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Dec 08 02:09:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0toR-0005Lo-S2; Sat, 08 Dec 2007 02:09:23 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J0toR-0005KJ-3L for behave-confirm+ok@megatron.ietf.org; Sat, 08 Dec 2007 02:09:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0toQ-0005KA-Pc for behave@ietf.org; Sat, 08 Dec 2007 02:09:22 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0toQ-00046P-CL for behave@ietf.org; Sat, 08 Dec 2007 02:09:22 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 07 Dec 2007 23:09:22 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lB879MWX019140 for ; Fri, 7 Dec 2007 23:09:22 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lB879MqZ018799 for ; Sat, 8 Dec 2007 07:09:22 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 23:09:21 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 23:09:21 -0800 Message-ID: <4759D32F.8010304@cisco.com> Date: Fri, 07 Dec 2007 18:11:43 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Dec 2007 07:09:21.0788 (UTC) FILETIME=[41C5A3C0:01C83969] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1917; t=1197097762; x=1197961762; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20TURN=20Issue=20#7=3A=20Framing=20header=20length |Sender:=20; bh=o2gLXYFdjBBFu5SXudNybJkmCQLVW9j1+1jV12vI3Xk=; b=NQ6x4xS9bwUtlKR5+I/goFZVgZrh09Y+qPneKi69orVrNH7iNTjBHWxnUk6fK41Qd2nEeAK2 0d33HhxJ4kJKGjC8rrQtI1IALkMFhDsmX/h9xyDu0W8T6Uj9bq3Vzr+m; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -2.1 (--) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [BEHAVE] TURN Issue #7: Framing header length X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 was not in my slides. It was raised at the mike at the WG session, discussed briefly at the WG meeting and again briefly at the end of the ad-hoc. The current TURN framing header looks like: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Channel | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When TURN is running over UDP, the length header is redundant. The current spec says to set it to zero. The issue was raised that, it would be better to set it to to be the correct length, rather than zero. The drawback of setting it to the correct length, is it introduces an error condition. What happens if it doesn't match the actual UDP length? Do we truncate (assuming the actual UDP packet size is larger than the TURN header message length)? Or just discard? The point raised at the ad-hoc later, was that even if you set it to zero, you still have the error condition, what if its not zero. It was also pointed out, by setting the length we get the framing header consistent between UDP and TCP. So there was rough agreement at the ad-hoc, to change turn so that the message length is the actual message length, even over UDP. If it mismatches the actual UDP message length, then the packet MUST be discarded in error. Please comment as to whether you agree (or disagree) with this conclusion. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Dec 08 02:09:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0toU-0005S9-4O; Sat, 08 Dec 2007 02:09:26 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J0toS-0005Nu-S4 for behave-confirm+ok@megatron.ietf.org; Sat, 08 Dec 2007 02:09:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0toS-0005Nk-9Q for behave@ietf.org; Sat, 08 Dec 2007 02:09:24 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0toR-0005uY-Qk for behave@ietf.org; Sat, 08 Dec 2007 02:09:24 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 07 Dec 2007 23:09:23 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lB879NEa019152 for ; Fri, 7 Dec 2007 23:09:23 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lB879NxP003067 for ; Sat, 8 Dec 2007 07:09:23 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 23:09:22 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 23:09:22 -0800 Message-ID: <4759D5A4.4090304@cisco.com> Date: Fri, 07 Dec 2007 18:22:12 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Dec 2007 07:09:22.0913 (UTC) FILETIME=[42714D10:01C83969] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2195; t=1197097763; x=1197961763; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20TURN=20Issue=20#8=3A=20Managing=20permission=20lifetimes |Sender:=20; bh=QurDerzzNTex4xZEHRTd0JbltYrTjgIsAEBC7mhgcjs=; b=I3xzIE7jOAMk/JUP1QzZVBJe1VSb/vmssiWF+93UkcSOpSGPKEQW2TUkU53V1rDl9wTRRKY2 /+zzVbfbsngTu0C9lO4p/qTMOyiw+ugkBgcq9/5hHLG/JtNCFCyNOqT/; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 1.9 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [BEHAVE] TURN Issue #8: Managing permission lifetimes X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 issue was not in my slides. It was raised at the mike in the WG meeting, and was not discussed further at the ad-hoc. The issue is this. In TURN-05 (and for several versions prior), allocations have an expiration and are refreshed explicitly by TURN signaling. However, permissions are refreshed by data traffic, and there is NO way to explicitly ask for a longer permission. Ekr pointed out that, we had a SAFE BoF at this IETF which was trying to address the problem that we didn't have an explicit way to manage the binding lifetimes on the NAT. So, since a TURN server is basically a remote-controlled NAT, isn't it silly to design it outright in a way that is known to be broken? The counter-argument that was made, is that you need to send the data traffic anyway to refresh the bindings between the client and the NAT. However, if there are multiple peers connected through the allocation, it would be possible to send a single data keepalive just to keepalive the connection from client to TURN server, instead of sending data keepalives for each peer. This is true only if there are no NATs between the TURN server and the peers. It was pointed out that there are real use cases for that, including enterprise deployments and p2psip. It was further pointed out that, if SAFE moves forward, at that time we could add extensions to turn to manage the permission lifetimes. Indeed, if SAFE uses STUN, it might even be the case that we could re-use that very extension, but just send it to the TURN server instead of the NAT. That would be really neat. Consequently, my sense from the meeting was that there was rough agreement to leave this alone, and not try to add support in TURN for explicitly requesting longer permission lifetimes. I think this is the right thing. Please comment if you agree (or don't) with this. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Dec 08 18:48:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J19PS-00006E-LE; Sat, 08 Dec 2007 18:48:38 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J19PR-00005y-7F for behave-confirm+ok@megatron.ietf.org; Sat, 08 Dec 2007 18:48:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J19PQ-00005q-88 for behave@ietf.org; Sat, 08 Dec 2007 18:48:36 -0500 Received: from rv-out-0910.google.com ([209.85.198.186]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J19PP-00069T-El for behave@ietf.org; Sat, 08 Dec 2007 18:48:35 -0500 Received: by rv-out-0910.google.com with SMTP id l15so1090863rvb for ; Sat, 08 Dec 2007 15:48:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=0Te4TV/DLMyXm7G2uPASk8WwvrhgKW+6IK7GgCn5mH4=; b=TidBH0LolXSbcygN2ilifmNJV5sa6YCZ4L8pZb/iQMIj4hGURXr540oq12aRYYZ65E42zvxB0WO6Y3cJJGyRvo2TFdFRe5IX3LBwKXuikd+ZCpkSBwDEN2w62eZMKNI5o1Ybuq/W3YkOzZIO7fpD4po8r1y8NfHPRT7clTfr4p8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=B98W6WC2pUE8wk+imiYJqfZLQ12n7I/SdyN1p1IcL2aVEtAYfAPg9nKl1aYSaZY60xgXYCRWJPS4iyNVTJmwf9ZSp4GM1C8wImV1TXTuN5zdVAXxWc47hhvFZWv/Gosyt3GUZAtipcNfWNUURPW+R2cpgaeMOtuoPvu3R9Nc2MA= Received: by 10.142.135.9 with SMTP id i9mr1507558wfd.1197157714866; Sat, 08 Dec 2007 15:48:34 -0800 (PST) Received: by 10.142.52.6 with HTTP; Sat, 8 Dec 2007 15:48:34 -0800 (PST) Message-ID: Date: Sat, 8 Dec 2007 15:48:34 -0800 From: "Derek MacDonald" To: "Jonathan Rosenberg" Subject: Re: [BEHAVE] TURN Issue #5: Port Range In-Reply-To: <4759CD14.10208@cisco.com> MIME-Version: 1.0 References: <4759CD14.10208@cisco.com> X-Google-Sender-Auth: 8dcdad06fd1a7dd6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1538861860==" Errors-To: behave-bounces@ietf.org --===============1538861860== Content-Type: multipart/alternative; boundary="----=_Part_11983_10688162.1197157714867" ------=_Part_11983_10688162.1197157714867 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I'm ok w/ this result. I just thought a MUST was cleaner if we were trying to make non-threatening. I also don't think well known ports have much meaning any more. -Derek On Dec 7, 2007 2:45 PM, Jonathan Rosenberg wrote: > This was not discussed in the WG meeting and had a brief discussion in > the ad-hoc. > > TURN currently says that a TURN server SHOULD only utilize ports in the > range 1024-65535, avoiding the well-known ports from 1-1023. There was a > request from Derek to make this a MUST. Note, however, that it is not > this restriction, but the server behavior around permissions, which > makes it impossible to run a general purpose server on a specific port. > > Most everyone still felt SHOULD is fine. My litmus test for SHOULD vs. > MUST is, would the protocol cease to interoperate, lose functionality, > or otherwise not work if the SHOULD were not followed. That is clearly > not the case here, so a SHOULD is appropriate. > > Please respond if you agree (or if you don't). > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > ------=_Part_11983_10688162.1197157714867 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I'm ok w/ this result.  I just thought a MUST was cleaner if we were trying to make non-threatening.  I also don't think well known ports have much meaning any more.

-Derek

On Dec 7, 2007 2:45 PM, Jonathan Rosenberg < jdrosen@cisco.com> wrote:
This was not discussed in the WG meeting and had a brief discussion in
the ad-hoc.

TURN currently says that a TURN server SHOULD only utilize ports in the
range 1024-65535, avoiding the well-known ports from 1-1023. There was a
request from Derek to make this a MUST. Note, however, that it is not
this restriction, but the server behavior around permissions, which
makes it impossible to run a general purpose server on a specific port.

Most everyone still felt SHOULD is fine. My litmus test for SHOULD vs.
MUST is, would the protocol cease to interoperate, lose functionality,
or otherwise not work if the SHOULD were not followed. That is clearly
not the case here, so a SHOULD is appropriate.

Please respond if you agree (or if you don't).

Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
jdrosen@cisco.com
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com


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

------=_Part_11983_10688162.1197157714867-- --===============1538861860== 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 --===============1538861860==-- From behave-bounces@ietf.org Sun Dec 09 11:40:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1PCj-0006va-0Q; Sun, 09 Dec 2007 11:40:33 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J1PCi-0006vL-B8 for behave-confirm+ok@megatron.ietf.org; Sun, 09 Dec 2007 11:40:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1PCh-0006vB-W6 for behave@ietf.org; Sun, 09 Dec 2007 11:40:32 -0500 Received: from submit01.sysedata.no ([195.159.29.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1PCh-0002sn-GU for behave@ietf.org; Sun, 09 Dec 2007 11:40:31 -0500 Received: from [84.215.127.238] (helo=[10.0.0.4]) by submit01.sysedata.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.62) (envelope-from ) id 1J1PCd-0007cX-BT; Sun, 09 Dec 2007 17:40:27 +0100 Message-ID: <475C1A7A.7010604@db.org> Date: Sun, 09 Dec 2007 17:40:26 +0100 From: "Alfred E. Heggestad" User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: Derek MacDonald , lowekamp@sipeerior.com, 'Behave WG' Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: [BEHAVE] Comments on draft-ietf-behave-nat-behavior-discovery-02 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Comments on draft-ietf-behave-nat-behavior-discovery-02 by Alfred E. Heggestad 9. Dec 2007 > 2.2. Example Use with P2P Overlays > > behind NATs to avoid the cost of dedicated servers. A supernode > candidate requires that its NAT(s) offer(s) Address Independent > Filtering. ^^^^^^^^^^^^^^^^^^^ > ^^^^^^^^^ There is no such things as "Address Independent Filtering". See RFC 4787 for the definitions. What you probably mean here is "Endpoint Independent" filtering > 3.6. Detecting Generic ALGs > It should be noted wether this test is applicable to UDP, TCP, TLS over TCP. > 4.3. Determining NAT Filtering Behavior > > its alternate IP address and alternate port. If the client receives > a response the current behaviour of the NAT is Address Independent > Filtering. ^^^^^^^^^^^^^^^^^^^ > ^^^^^^^^^ There is no such things as "Address Independent Filtering". See RFC 4787 for the definitions. What you probably mean here is "Endpoint Independent" filtering _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Dec 09 19:36:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1WdL-0001CD-52; Sun, 09 Dec 2007 19:36:31 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J1WdJ-0001C7-Az for behave-confirm+ok@megatron.ietf.org; Sun, 09 Dec 2007 19:36:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1WdJ-0001Bw-0Q for behave@ietf.org; Sun, 09 Dec 2007 19:36:29 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-02.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1WdI-0001ta-If for behave@ietf.org; Sun, 09 Dec 2007 19:36:28 -0500 Received: from s01060018e70bfb18.wk.shawcable.net ([24.67.234.227] helo=[192.168.1.104]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J1WdG-0007iJ-1y for behave@ietf.org; Sun, 09 Dec 2007 19:36:27 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <9A9D2AC7-A4DA-48AD-9014-0F60EF7568EF@magma.ca> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: behave@ietf.org From: Philip Matthews Date: Sun, 9 Dec 2007 11:35:38 -0800 X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - s01060018e70bfb18.wk.shawcable.net ([192.168.1.104]) [24.67.234.227] X-Spam-Score: 1.4 (+) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [BEHAVE] Rough minutes from TURN ad-hoc X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 asked me to send my rough minutes from the TURN ad-hoc to the mailing list. They are very rough, but they might prove useful. Note that the conversation wandered around a number of topics, and I mostly only recorded decisions. - Philip Rough minutes from TURN ad-hoc Thursday evening, 6 Nov 2007 Decision: We are keeping the bandwidth parameter (because people are interested in it). Semantics: if no parameter in request, server may include one in response in which case the server may drop traffic in excess of that parameter; if server does not include, then server is saying that it will attempt to handle all traffic. Stateful alloc Decision: server must reply with same answer within 10 seconds. This is ok. Open issue #3 Address vs Address and Port Restriction Cullen argues that this means that there is no incentive for a service provider to install TURN. EKR argues that this turns a symmetric firewall into an address- restricted firewall, and most firewalls are port-restricted firewalls. Action: Rohan will write up a brief description of the problem and send it to Magnus. Open issue #4 Port adjacency Decision: Hold adjacent port reserved for the lifetime of the allocation Decision: We are going with EKR's proposed ChannelBind stuff. Decision: Length field is actual length, not zero. If mismatch between TURN length and UDP length, then drop packet. [Need to talk about partial write of a UDP datagram to the TCP socket when the server-to-client connection runs over TCP.] [Need to go through document and handle case where two clients (both behind symmetric NATs, connect to the same TURN server] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 10 00:09:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1atn-0007BH-Av; Mon, 10 Dec 2007 00:09:47 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J1atl-0007BA-Sn for behave-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 00:09:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1atl-0007Ar-3E for behave@ietf.org; Mon, 10 Dec 2007 00:09:45 -0500 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1atk-0006Z5-O8 for behave@ietf.org; Mon, 10 Dec 2007 00:09:45 -0500 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id lBA59eg4026545; Mon, 10 Dec 2007 00:09:40 -0500 (EST) Received: from [192.168.1.100] (pool-68-160-35-101.bos.east.verizon.net [68.160.35.101]) (authenticated bits=0) (User authenticated as baford@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id lBA59YoS001692 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 10 Dec 2007 00:09:35 -0500 (EST) Message-Id: <7B55F180-CCEF-447E-97EB-A0F584E5B12C@mit.edu> From: Bryan Ford To: rrs@cisco.com, tuexen@fh-muenster.de Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 10 Dec 2007 00:09:34 -0500 X-Mailer: Apple Mail (2.915) X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: IETF BEHAVE WG Subject: [BEHAVE] SCTP over NAT and (re-)fragmentation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 Randall and Michael, I liked the general approach you take toward NAT support for SCTP described in draft-stewart-behave-sctpnat-03.txt, as presented at IETF 70. While (like many) I'm skeptical that any substantial percentage of NATs are ever going to support anything but UDP and TCP, I do support standardizing NAT for SCTP if there are even a few NAT implementors who actually want to support it. While studying RFC 4960, I realized a minor point that isn't (yet) mentioned in your SCTP-NAT draft. An SCTP sender can't re-fragment data chunks that have already been fragmented and transmitted once (RFC 4960 section 6.9), so if the MTU of a path decreases dynamically due to a route change for example, the SCTP sender MUST rely on IP- level fragmentation in re-transmitting any already-fragmented chunks that are now too large for the new PMTU. And as we know many NATs currently don't handle IP fragmentation well. This simply means that a NAT that wants to support SCTP also needs to support IP-layer fragmentation and reassembly properly for SCTP packets. Shouldn't be too much to ask, since RFC 4787 already requires this functionality for UDP. But it's probably worth stating explicitly, since with a transport like SCTP that does its own fragmentation in the normal case, it may be easy for this issue to be overlooked in a NAT implementation for SCTP, leading to NAT bugs that might cause an SCTP association to get "stuck" in rare cases of dynamic path MTU reduction. Cheers, Bryan _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 10 03:53:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1eOM-0001r3-BK; Mon, 10 Dec 2007 03:53:34 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J1eOL-0001qs-D6 for behave-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 03:53:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1eOL-0001qj-3Q for behave@ietf.org; Mon, 10 Dec 2007 03:53:33 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1eOK-0002Mp-Mh for behave@ietf.org; Mon, 10 Dec 2007 03:53:33 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBA8qpjM021289; Mon, 10 Dec 2007 02:53:41 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 10:53:14 +0200 Received: from esdhcp04164.research.nokia.com ([172.21.41.64]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 10:53:14 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] TURN Issue #1: Bandwidth Param Date: Mon, 10 Dec 2007 10:53:16 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <47599BE6.9090903@cisco.com> In-Reply-To: <47599BE6.9090903@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200712101053.17425.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 10 Dec 2007 08:53:14.0249 (UTC) FILETIME=[196F3790:01C83B0A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Le Friday 07 December 2007 21:15:50 ext Jonathan Rosenberg, vous avez =E9cr= it=A0: > Server MAY include a value in a response, even if there was not one in a > request. The meaning of the value in the response, is that the server > agrees to forward traffic to/from the client so long as it is below the > bandwidth value. Hmm. I kinda doubt that a client which does not specify bandwidth would mak= e=20 any use of a returned bandwidth parameter. I would rather go for the "let the network fix it"/best-effort approach tha= t=20 was proposed, at least if the client did not specify bandwidth. In practice= ,=20 there are several reasons why bandwidth informations will often (if not=20 always) be unavailable to the TURN client stack: =2D file transfer or anything that wants to occur as fast as possible, =2D among the many layers of software code between the TURN client and the= =20 codecs, it is likely the bandwidth info will be lost, =2D ICE or other "RTP enhancements" may screw up the computation, =2D in SIP+ICE caller case, you need to make TURN the allocation before you= send=20 the INVITE, which is obviously before you receive the SIP answer, which is= =20 when you (usually) decide which codec/bandwidth you're actually going to=20 need. > Please comment if you are happy (or not) with keeping bandwidth with > these proposed semantics. I am fine with keeping the bandwidth attribute, but it definitely must be=20 optional. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 10 03:56:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1eRP-0004F7-Gn; Mon, 10 Dec 2007 03:56:43 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J1eRN-0004Ex-N8 for behave-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 03:56:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1eRN-0004Ek-DI for behave@ietf.org; Mon, 10 Dec 2007 03:56:41 -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 1J1eRL-0002Pf-Qv for behave@ietf.org; Mon, 10 Dec 2007 03:56:41 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lBA8u9rQ025300; Mon, 10 Dec 2007 10:56:31 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 10:56:29 +0200 Received: from esdhcp04164.research.nokia.com ([172.21.41.64]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 10:56:28 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] TURN Issue #2: Stateful allocations Date: Mon, 10 Dec 2007 10:56:32 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <47599D4F.50102@cisco.com> In-Reply-To: <47599D4F.50102@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200712101056.32140.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 10 Dec 2007 08:56:28.0932 (UTC) FILETIME=[8D797C40:01C83B0A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Le Friday 07 December 2007 21:21:51 ext Jonathan Rosenberg, vous avez =E9cr= it=A0: > There was general agreement at the ad-hoc that this is a non-issue. TURN > servers are already required to maintain state, in the form of > allocations, permissions, channel bindings, and so on. Transaction state > is not much more. > > Note that, rfc3489bis requires stun transactions (including extensions > like TURN) to be idempotent. Note that, despite the different response > codes for a retransmit and new transaction, TURN remains idempotent. > Idempotency only requires that subsequent retries do not alter the state > on the server; it does NOT require the same response. We went through > this ad-nauseum on XCAP. > > The proposal is therefore to just document this fact, but otherwise not > change anything. > > Please comment if you agree (or not) with this. If I understand correctly, this practically means the server must remember = the=20 ID of the STUN transaction that created the TURN allocation. When it receiv= es=20 an allocation, it returns a success response if it's the same ID or an erro= r=20 if it's not. Right? In that case, that seems right to me. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 10 04:08:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1ecM-0006Va-Dg; Mon, 10 Dec 2007 04:08:02 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J1ecL-0006UH-Co for behave-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 04:08:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1ecL-0006U8-2z for behave@ietf.org; Mon, 10 Dec 2007 04:08:01 -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 1J1ecK-0002n1-Ix for behave@ietf.org; Mon, 10 Dec 2007 04:08:01 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lBA97rrA003379; Mon, 10 Dec 2007 11:07:57 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 11:07:51 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 11:07:50 +0200 Received: from esdhcp04164.research.nokia.com ([172.21.41.64]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 11:07:50 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] TURN Issue #3: Address v. Address and Port Restricted Date: Mon, 10 Dec 2007 11:07:53 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <4759A13C.8080106@cisco.com> In-Reply-To: <4759A13C.8080106@cisco.com> MIME-Version: 1.0 Content-Disposition: inline X-UID: 452 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200712101107.53482.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 10 Dec 2007 09:07:50.0850 (UTC) FILETIME=[23EDEA20:01C83B0C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Le Friday 07 December 2007 21:38:36 ext Jonathan Rosenberg, vous avez =E9cr= it=A0: > Note that this is a SHOULD and not a MUST. One of the reasons for that, > is that there is a belief that some firewall or NAT vendors or operators > would believe (true or not) that address and port restricted NAT > behavior is 'more secure'. My person belief is that this would not *really* provide any extra security= =2E=20 But I do know that some people do claim (and probably think) it does. draft-ietf-v6ops-teredo-security-concerns-01 (=A7 4.2, 4.3) kind of hint at= =20 this. I have also heard of NATs that were purposedly made to be evil=20 symmetric NATs to hinder P2P applications - basically it is quite effective= =20 at preventing NAT-to-NAT communication. I am not all saying we should go for port-restricted behavior. However, if = we=20 do keep the current behavior, I think we need to put some explanatory=20 justification somewhere (SecCons?). =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 10 05:32:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1fw4-0004k6-R1; Mon, 10 Dec 2007 05:32:28 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J1fw4-0004jz-CQ for behave-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 05:32:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1fw4-0004jo-21 for behave@ietf.org; Mon, 10 Dec 2007 05:32:28 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1fw3-0007kZ-OD for behave@ietf.org; Mon, 10 Dec 2007 05:32:27 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBAAW9jt019187; Mon, 10 Dec 2007 04:32:44 -0600 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 12:32:11 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 12:32:11 +0200 Received: from esdhcp04164.research.nokia.com ([172.21.41.64]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 12:32:10 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages Date: Mon, 10 Dec 2007 12:32:13 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <4759D19B.50005@cisco.com> In-Reply-To: <4759D19B.50005@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200712101232.14041.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 10 Dec 2007 10:32:10.0955 (UTC) FILETIME=[EBFCA9B0:01C83B17] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Saturday 08 December 2007 01:04:59 ext Jonathan Rosenberg, vous avez=20 =E9crit=A0: > This was somewhat inconclusive at the microphone. I'm personally on the > fence and don't feel that strongly. I probably midly prefer making this > change. > > Please comment on whether you prefer this change or not. I am weakly supporting the change. I don't think reducing from 65535 to 32767 channels is a problem. I hope IE= SG=20 will agree that you have to recreate a new TURN allocation when you have=20 exhausted the channel ranges, regardless of the total number of channels (?= ). =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 10 05:35:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1fz8-000692-20; Mon, 10 Dec 2007 05:35:38 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J1fz7-00068n-KO for behave-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 05:35:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1fz7-00068Z-9l for behave@ietf.org; Mon, 10 Dec 2007 05:35:37 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1fz6-0007qJ-QL for behave@ietf.org; Mon, 10 Dec 2007 05:35:37 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBAAZINe011304; Mon, 10 Dec 2007 12:35:33 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 12:35:04 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 12:35:04 +0200 Received: from esdhcp04164.research.nokia.com ([172.21.41.64]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 12:35:03 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] TURN Issue #7: Framing header length Date: Mon, 10 Dec 2007 12:35:07 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <4759D32F.8010304@cisco.com> In-Reply-To: <4759D32F.8010304@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200712101235.07245.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 10 Dec 2007 10:35:03.0970 (UTC) FILETIME=[531CA820:01C83B18] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 Saturday 08 December 2007 01:11:43 ext Jonathan Rosenberg, vous avez=20 =E9crit=A0: > So there was rough agreement at the ad-hoc, to change turn so that the > message length is the actual message length, even over UDP. If it > mismatches the actual UDP message length, then the packet MUST be > discarded in error. > > Please comment as to whether you agree (or disagree) with this conclusion. I'd rather have the correct length all the time. I suspect the extra=20 three-liner error case will add less code than the UDP/TCP factorization wi= ll=20 add. In any case, the amount of programming involved is infinitesimal to a= =20 full TURN implementation. I note that if we change the framing as per issue #6, issue #7 becomes=20 irrelevant :) =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 10 09:31:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1jfn-0008Lr-02; Mon, 10 Dec 2007 09:31:55 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J1jfl-0008LT-Fq for behave-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 09:31:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1jfl-0008LL-5V for behave@ietf.org; Mon, 10 Dec 2007 09:31:53 -0500 Received: from drew.ipv6.franken.de ([2001:638:a02:a001:20e:cff:fe4a:feaa] helo=mail-n.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1jfi-00025y-RG for behave@ietf.org; Mon, 10 Dec 2007 09:31:53 -0500 Received: from [192.168.1.15] (p508FD4E1.dip.t-dialin.net [80.143.212.225]) by mail-n.franken.de (Postfix) with ESMTP id 210588006D9F; Mon, 10 Dec 2007 15:31:45 +0100 (CET) (KNF-authenticated sender: micmac) Message-Id: <36050A33-B215-497D-9671-67F62DAEE45F@lurchi.franken.de> From: Michael Tuexen To: Bryan Ford In-Reply-To: <7B55F180-CCEF-447E-97EB-A0F584E5B12C@mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 10 Dec 2007 15:31:43 +0100 References: <7B55F180-CCEF-447E-97EB-A0F584E5B12C@mit.edu> X-Mailer: Apple Mail (2.915) X-Spam-Score: 2.2 (++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: IETF BEHAVE WG Subject: [BEHAVE] Re: SCTP over NAT and (re-)fragmentation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 Bryan, see my comments in-line. Best regards Michael On Dec 10, 2007, at 6:09 AM, Bryan Ford wrote: > Hi Randall and Michael, > > I liked the general approach you take toward NAT support for SCTP > described in draft-stewart-behave-sctpnat-03.txt, as presented at > IETF 70. While (like many) I'm skeptical that any substantial > percentage of NATs are ever going to support anything but UDP and > TCP, I do support standardizing NAT for SCTP if there are even a few > NAT implementors who actually want to support it. > > While studying RFC 4960, I realized a minor point that isn't (yet) > mentioned in your SCTP-NAT draft. An SCTP sender can't re-fragment > data chunks that have already been fragmented and transmitted once > (RFC 4960 section 6.9), so if the MTU of a path decreases > dynamically due to a route change for example, the SCTP sender MUST > rely on IP-level fragmentation in re-transmitting any already- > fragmented chunks that are now too large for the new PMTU. And as > we know many NATs currently don't handle IP fragmentation well. > This simply means that a NAT that wants to support SCTP also needs > to support IP-layer fragmentation and reassembly properly for SCTP > packets. True. > Shouldn't be too much to ask, since RFC 4787 already requires this > functionality for UDP. But it's probably worth stating explicitly, > since with a transport like SCTP that does its own fragmentation in > the normal case, it may be easy for this issue to be overlooked in a > NAT implementation for SCTP, leading to NAT bugs that might cause an > SCTP association to get "stuck" in rare cases of dynamic path MTU > reduction. Good point! I'll add text in the next revision. Thank you very much for pointing this out. > > > Cheers, > Bryan > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 10 09:57:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1k47-0006H2-5l; Mon, 10 Dec 2007 09:57:03 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J1k46-0006Gn-U6 for behave-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 09:57:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1k46-0006Ge-Iy for behave@ietf.org; Mon, 10 Dec 2007 09:57:02 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1k46-0005pD-7G for behave@ietf.org; Mon, 10 Dec 2007 09:57:02 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 10 Dec 2007 06:57:01 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lBAEv15V029192; Mon, 10 Dec 2007 06:57:01 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lBAEuq8D006666; Mon, 10 Dec 2007 14:57:01 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 06:56:52 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 06:56:52 -0800 Message-ID: <475D53DC.3050607@cisco.com> Date: Mon, 10 Dec 2007 09:57:32 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages References: <4759D19B.50005@cisco.com> <200712101232.14041.remi.denis-courmont@nokia.com> In-Reply-To: <200712101232.14041.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 10 Dec 2007 14:56:52.0795 (UTC) FILETIME=[E64D20B0:01C83B3C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1017; t=1197298621; x=1198162621; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20Issue=20#6=3A=20Framing=20header=20 for=20actual=20TURN=20messages |Sender:=20; bh=MjGm1agD+kP0TWUiFWMxTbD3ilBOwwMLrTAIzker+nI=; b=l2QdBT/TedEg9+HYRJgVNNvloZM7xUBYJ/lj81uBCL0nF89kp0WvKB9cdHXUw5U8lHZu9DKu 7I7iUuK0YOdnlfOSlnFznrPW7J/QnVf2v2Im9Mcgi7z4AjdB5+7y3tTY; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 Rémi Denis-Courmont wrote: > Le Saturday 08 December 2007 01:04:59 ext Jonathan Rosenberg, vous avez > écrit : >> This was somewhat inconclusive at the microphone. I'm personally on the >> fence and don't feel that strongly. I probably midly prefer making this >> change. >> >> Please comment on whether you prefer this change or not. > > I am weakly supporting the change. > > I don't think reducing from 65535 to 32767 channels is a problem. I hope IESG > will agree that you have to recreate a new TURN allocation when you have > exhausted the channel ranges, regardless of the total number of channels (?). I don't see why IESG per se would have an opinion on it, but you never know... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 10 09:57:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1k4e-0006on-GZ; Mon, 10 Dec 2007 09:57:36 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J1k4e-0006oi-0R for behave-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 09:57:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1k4d-0006oa-Mx for behave@ietf.org; Mon, 10 Dec 2007 09:57:35 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1k4c-0002fA-6l for behave@ietf.org; Mon, 10 Dec 2007 09:57:35 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 10 Dec 2007 06:57:33 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lBAEvXLZ030056; Mon, 10 Dec 2007 06:57:33 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBAEvXqZ024781; Mon, 10 Dec 2007 14:57:33 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 06:57:33 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 06:57:30 -0800 Message-ID: <475D5401.7020205@cisco.com> Date: Mon, 10 Dec 2007 09:58:09 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= Subject: Re: [BEHAVE] TURN Issue #7: Framing header length References: <4759D32F.8010304@cisco.com> <200712101235.07245.remi.denis-courmont@nokia.com> In-Reply-To: <200712101235.07245.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 10 Dec 2007 14:57:30.0297 (UTC) FILETIME=[FCA77A90:01C83B3C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1189; t=1197298653; x=1198162653; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20Issue=20#7=3A=20Framing=20header=20 length |Sender:=20; bh=sU/Dfcv85PQAYJv+3Im6asIE9FZvm4SXe4cjHv0A5no=; b=HuBd+wfPPGeh+xyrkVynhj/moCtOyKWDXKj6+G5ccFYSBVlSeWbvqQlMVyrVlvWLHgHuGJJe usPjNY6MpEruOd1qLyOwR03yIKJXRgQeeByappf8dQRENyf3x/UTvQbY; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 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 inline: Rémi Denis-Courmont wrote: > Le Saturday 08 December 2007 01:11:43 ext Jonathan Rosenberg, vous avez > écrit : >> So there was rough agreement at the ad-hoc, to change turn so that the >> message length is the actual message length, even over UDP. If it >> mismatches the actual UDP message length, then the packet MUST be >> discarded in error. >> >> Please comment as to whether you agree (or disagree) with this conclusion. > > I'd rather have the correct length all the time. I suspect the extra > three-liner error case will add less code than the UDP/TCP factorization will > add. In any case, the amount of programming involved is infinitesimal to a > full TURN implementation. > > I note that if we change the framing as per issue #6, issue #7 becomes > irrelevant :) > Its irrelevant for TURN messages but still an issue for application data. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 10 09:58:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1k5f-0000Mf-98; Mon, 10 Dec 2007 09:58:39 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J1k5d-0000EJ-MO for behave-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 09:58:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1k5d-00008b-8Q for behave@ietf.org; Mon, 10 Dec 2007 09:58:37 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1k5c-0005rT-Ro for behave@ietf.org; Mon, 10 Dec 2007 09:58:37 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 10 Dec 2007 06:58:36 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBAEwaUt030230; Mon, 10 Dec 2007 06:58:36 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lBAEwa87008244; Mon, 10 Dec 2007 14:58:36 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 06:58:35 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 06:58:35 -0800 Message-ID: <475D5443.5050601@cisco.com> Date: Mon, 10 Dec 2007 09:59:15 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= Subject: Re: [BEHAVE] TURN Issue #2: Stateful allocations References: <47599D4F.50102@cisco.com> <200712101056.32140.remi.denis-courmont@nokia.com> In-Reply-To: <200712101056.32140.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 10 Dec 2007 14:58:35.0796 (UTC) FILETIME=[23B1D540:01C83B3D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1507; t=1197298716; x=1198162716; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20Issue=20#2=3A=20Stateful=20allocati ons |Sender:=20; bh=Cr2br/U9prUnDWUXe02oelY+XIWOweeOKGXTHzwHDqk=; b=OWQ52itczAdDtLT/sbZYWpCACYMOaPidQT/fhaAr5wJ8DtnKaHP5ThaWFDhCRvwStBJskQxe deVbJ7TMk3yCJHHyEjOiqtZx5mbibcc0iUoBWQNJALfnK4pGUrLFvdQCl5g5JvXvS2KYhWR7Nu Ol2esn+qzMBA3OXxqTufrZvYU=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org inline: Rémi Denis-Courmont wrote: > Le Friday 07 December 2007 21:21:51 ext Jonathan Rosenberg, vous avez écrit : >> There was general agreement at the ad-hoc that this is a non-issue. TURN >> servers are already required to maintain state, in the form of >> allocations, permissions, channel bindings, and so on. Transaction state >> is not much more. >> >> Note that, rfc3489bis requires stun transactions (including extensions >> like TURN) to be idempotent. Note that, despite the different response >> codes for a retransmit and new transaction, TURN remains idempotent. >> Idempotency only requires that subsequent retries do not alter the state >> on the server; it does NOT require the same response. We went through >> this ad-nauseum on XCAP. >> >> The proposal is therefore to just document this fact, but otherwise not >> change anything. >> >> Please comment if you agree (or not) with this. > > If I understand correctly, this practically means the server must remember the > ID of the STUN transaction that created the TURN allocation. When it receives > an allocation, it returns a success response if it's the same ID or an error > if it's not. Right? Yes. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 10 10:02:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1k9N-0005Vm-4F; Mon, 10 Dec 2007 10:02:29 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J1k9K-0005Ow-1y for behave-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 10:02:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1k9J-0005On-OQ for behave@ietf.org; Mon, 10 Dec 2007 10:02:25 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1k9I-0002lp-BL for behave@ietf.org; Mon, 10 Dec 2007 10:02:25 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 10 Dec 2007 07:02:23 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lBAF2N25016177; Mon, 10 Dec 2007 07:02:23 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBAF2NqZ029672; Mon, 10 Dec 2007 15:02:23 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 07:02:23 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 07:02:23 -0800 Message-ID: <475D5526.1030707@cisco.com> Date: Mon, 10 Dec 2007 10:03:02 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Marc Petit-Huguenin Subject: Re: [BEHAVE] Alternative channel binding mechanism for TURN References: <475998D7.8010903@cisco.com> <4759B3B6.9000604@acm.org> In-Reply-To: <4759B3B6.9000604@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Dec 2007 15:02:23.0252 (UTC) FILETIME=[AB44DD40:01C83B3D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1657; t=1197298943; x=1198162943; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20Alternative=20channel=20binding=20mechanis m=20for=20TURN |Sender:=20; bh=PfMWwQuab0Dp/vt989wbM8WRN1XDc/DlquaPL0plQCM=; b=d8v8b5HZoJwcs6pNUsZei+pwc7RjJ3E+ueXP8pbM6cjBRSY1CTDm21YguOZ4O0pNGYSxfLct eXzLsHROjkjLsMFW+aUBK+WL+Hdh8KI4dNrEI+IuCO/Ods5p2zRr8kmM; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Marc, I appreciate and share your frustration here. There are many factors that have contributed to the overly long lifetime on this draft (over 6 years as you say), including lack of a working group for a long time. Frankly, up until this point, it has never had the deep scrutiny it is now getting to turn it into a solid protocol (no pun intended). I and the rest of the design team and really committed to getting this DONE and not having another IETF discussion on it like the one we just had. Thanks for your patience and support, Jonathan R. Marc Petit-Huguenin wrote: > Jonathan Rosenberg wrote: >> Several folks met last night at the TURN ad-hoc to discuss the various >> open issues. One of the biggest was whether we should change the channel >> binding mechanism from what is in the document (using Send along with a >> confirmation indication) to what ekr suggested. We wrote down what that >> alternate flow would look like and came up with pros and cons. Here is >> what we came up with. >> > > I am in favor of the new technique, mostly because of the security issue > it fixes. > > This said changing basic stuff like this each 4 months is way past > annoying. Couldn't EKR be part of the design team? > > The first version of TURN was released November 14, 2001. 6 years after > I still have nothing to deploy. > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 10 10:06:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1kDi-0000ld-4l; Mon, 10 Dec 2007 10:06:58 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J1kDg-0000lM-P1 for behave-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 10:06:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1kDg-0000lE-FB for behave@ietf.org; Mon, 10 Dec 2007 10:06:56 -0500 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1kDg-0002rI-4g for behave@ietf.org; Mon, 10 Dec 2007 10:06:56 -0500 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id lBAF6dma026604; Mon, 10 Dec 2007 10:06:39 -0500 (EST) Received: from [192.168.1.100] (pool-68-160-35-101.bos.east.verizon.net [68.160.35.101]) (authenticated bits=0) (User authenticated as baford@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id lBAF6X7j028832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 10 Dec 2007 10:06:34 -0500 (EST) Message-Id: <54A85AEA-CEA3-49B6-AD48-3B848DD3D1BD@mit.edu> From: Bryan Ford To: Michael Tuexen In-Reply-To: <36050A33-B215-497D-9671-67F62DAEE45F@lurchi.franken.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 10 Dec 2007 10:06:33 -0500 References: <7B55F180-CCEF-447E-97EB-A0F584E5B12C@mit.edu> <36050A33-B215-497D-9671-67F62DAEE45F@lurchi.franken.de> X-Mailer: Apple Mail (2.915) X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: IETF BEHAVE WG Subject: [BEHAVE] SCTP over NAT and hole-punching? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Another, perhaps more substantial issue that occurred to me with draft- stewart-behave-sctpnat-03.txt is whether it's possible to provide any kind of peer-to-peer NAT traversal functionality - i.e., something analogous to UDP or TCP hole punching - with this approach, or will NATted SCTP always be strictly limited to client/server communication? The thing is, you seem to be effectively adding SCTP's VTAG to the "endpoint address tuple" used by SCTP to distinguish different streams - i.e., now it's "kinda, sorta" (IP, port, vtag) instead of just (IP, port). At least for the possible multiple SCTP associations that might emerge from a NAT's single public IP address and the same internal port, and outbound to the same server address and port, the VTAG provides the only way to distinguish those streams. But what if the server wants to be a rendezvous server of some kind and help clients establish a direct SCTP association somehow? Will there need to be a way for one client to open an outbound SCTP connection to another client's public IP address and port, specifying explicitly the VTAG the other client is using to talk to the rendezvous server? (Even without the "VTAG addressing" issue this would presumably need to be an extension to SCTP, since as far as I know SCTP has no simultanous open functionality like TCP does.) Which I guess brings up the higher-level issue, not yet addressed in "SCTP NAT Traversal Considerations" (draft-xie-behave-sctp-nat- cons-03), of whether a "NAT for SCTP" project should include peer-to- peer connectivity in its scope or stay strictly limited to client/ server? Cheers, Bryan _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 10 10:30:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1ka1-00074O-Jb; Mon, 10 Dec 2007 10:30:01 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J1ka0-000745-Ae for behave-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 10:30:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1ka0-00073x-0t for behave@ietf.org; Mon, 10 Dec 2007 10:30:00 -0500 Received: from py-out-1112.google.com ([64.233.166.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1kZz-0003Rv-MH for behave@ietf.org; Mon, 10 Dec 2007 10:30:00 -0500 Received: by py-out-1112.google.com with SMTP id d32so7426128pye for ; Mon, 10 Dec 2007 07:29:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:x-mailer:reply-to:x-priority:message-id:to:cc:subject:in-reply-to:references:mime-version:content-type:content-transfer-encoding; bh=HRip4k30XpyZZnbi2nRddCijhXxwhS/jOZzSK9HwM0g=; b=PEzJBbCfMTMqY3m1VaqcPPZ11gbGQn54qdyVh3Q7chzqsVXLVr1VB00PdgTW2sldfdoU8hvCxyjCR/6UJUjqe8qmA63aKIc5SkWfhFr2WOumJiiDEG9WDK3DMMDapfLNcU5JbeASXE8pOl9F2at7nvVgrzu7L/bpV3ak88ALUKE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:x-mailer:reply-to:x-priority:message-id:to:cc:subject:in-reply-to:references:mime-version:content-type:content-transfer-encoding; b=v9wkAmRgEKFIcetKrBHgWIRMeTP35fL1yUx84CJdlFmIap2PGUk5HHe17wwWtkj3PB5c4WZU2c+kOqfk/I0xlikQIIh7YYJJKkAKnvA9lEPGC5IdosICfUhhlcmQ+4823BD9FkKQjOGmurNsZCIYcgEQyw+WgQaIyQK0Qx44ZqE= Received: by 10.64.208.20 with SMTP id f20mr14247759qbg.1197300598043; Mon, 10 Dec 2007 07:29:58 -0800 (PST) Received: from kalien.office.bpsoft.com ( [207.180.138.110]) by mx.google.com with ESMTPS id f15sm3280850qba.2007.12.10.07.29.56 (version=SSLv3 cipher=OTHER); Mon, 10 Dec 2007 07:29:56 -0800 (PST) Date: Mon, 10 Dec 2007 10:29:58 -0500 From: Bob Andreasen X-Mailer: The Bat! (v3.99.29) Professional X-Priority: 3 (Normal) Message-ID: <1469047018.20071210102958@gmail.com> To: behave@ietf.org Subject: Re[2]: [BEHAVE] TURN Issue #1: Bandwidth Param In-Reply-To: <200712101053.17425.remi.denis-courmont@nokia.com> References: <47599BE6.9090903@cisco.com> <200712101053.17425.remi.denis-courmont@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bob Andreasen 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 Monday, December 10, 2007, 3:53:16 AM, R=E9mi Denis-Courmont wrote: > Le Friday 07 December 2007 21:15:50 ext Jonathan Rosenberg, vous avez =E9= crit : >> Server MAY include a value in a response, even if there was not one in a >> request. The meaning of the value in the response, is that the server >> agrees to forward traffic to/from the client so long as it is below the >> bandwidth value. > Hmm. I kinda doubt that a client which does not specify bandwidth would m= ake > any use of a returned bandwidth parameter. I agree that a client which does not request a bandwidth would probably not use it -- but it is still very valuable to know if/when a cap will be enforced. One could adjust their codecs and bandwidth given that information.=20 > I would rather go for the "let the network fix it"/best-effort approach t= hat > was proposed, at least if the client did not specify bandwidth. In practi= ce, > there are several reasons why bandwidth informations will often (if not > always) be unavailable to the TURN client stack: > - file transfer or anything that wants to occur as fast as possible, > - among the many layers of software code between the TURN client and the > codecs, it is likely the bandwidth info will be lost, > - ICE or other "RTP enhancements" may screw up the computation, > - in SIP+ICE caller case, you need to make TURN the allocation before you= send > the INVITE, which is obviously before you receive the SIP answer, which is > when you (usually) decide which codec/bandwidth you're actually going to > need. I believe your last point suggests adding the ability to adjust the bandwidth (likely downward) via an allocation refresh. Interesting, but not a requirement in my opinion. We are using bandwidth for rate limiting not capacity planning. >> Please comment if you are happy (or not) with keeping bandwidth with >> these proposed semantics. > I am fine with keeping the bandwidth attribute, but it definitely must be > optional. AOL (Bob Andreasen and Elena Furman) supports this. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 10 10:53:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1kx0-00022q-Qp; Mon, 10 Dec 2007 10:53:46 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J1kx0-0001y9-71 for behave-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 10:53:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1kwz-0001xm-SO for behave@ietf.org; Mon, 10 Dec 2007 10:53:45 -0500 Received: from py-out-1112.google.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1kwz-0004G1-FS for behave@ietf.org; Mon, 10 Dec 2007 10:53:45 -0500 Received: by py-out-1112.google.com with SMTP id d32so7469730pye for ; Mon, 10 Dec 2007 07:53:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:x-mailer:reply-to:x-priority:message-id:to:cc:subject:in-reply-to:references:mime-version:content-type:content-transfer-encoding; bh=4JWjpRgreK4rQE7cBTvLFZW1p2eS2IVoszIBgl01ROc=; b=yHOjhoxiXgvK08W3xOPuDBGFdHeXkOiCKGgHUszEh2aa/8YfYcX/o4YHbSfHPJVgAEWFnuCwObc3S/XdU9eGXO5fBH3Evx1r+oTsNxuG1mt/+PI0aLKNT1Eg2BHKy9hUYry32MrQ2ZL11T9DtfkJN/X/9VDJwxlTl7IpTGoO43o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:x-mailer:reply-to:x-priority:message-id:to:cc:subject:in-reply-to:references:mime-version:content-type:content-transfer-encoding; b=mmS+u5KhK+tJTKxvdjJHHG3Jvp3fRsifsRdL/vCi0F987EZ2/j/nld+bYmXdpUuQKReOLoh/xDiuVOFcQEWpVySws5dfTOrkszjajDiPFjpD0PrtDzLW5P2ZktIQrEUYRlensPXEPxGCL3xPp9gvyYKsOX4GmG2tVL53udYaOAY= Received: by 10.64.53.20 with SMTP id b20mr14348469qba.1197302022428; Mon, 10 Dec 2007 07:53:42 -0800 (PST) Received: from kalien.office.bpsoft.com ( [207.180.138.110]) by mx.google.com with ESMTPS id f15sm3298161qba.2007.12.10.07.53.39 (version=SSLv3 cipher=OTHER); Mon, 10 Dec 2007 07:53:40 -0800 (PST) Date: Mon, 10 Dec 2007 10:53:42 -0500 From: Bob Andreasen X-Mailer: The Bat! (v3.99.29) Professional X-Priority: 3 (Normal) Message-ID: <65740984.20071210105342@gmail.com> To: Jonathan Rosenberg Subject: Re: [BEHAVE] TURN Issue #3: Address v. Address and Port Restricted In-Reply-To: <4759A13C.8080106@cisco.com> References: <4759A13C.8080106@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bob Andreasen List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > Some of the folks in the ad-hoc proposed that, this was not actually a > bug. The reason is that the current mechanism misplaces incentives. An > address-dependent filtering behavior in the TURN server allows my TURN > server to fix the problem of SOMEONE ELSES NAT. Thus, the worry was that > provider X would deploy ICE but skip a TURN server, since it would just > assume that other providers it was connecting to would deploy TURN, and > if they did, provider X would not need a TURN server. If provider Y came > to the same conclusion, neither would deploy TURN. Making TURN > address-and-port dependent filtering would basically force each provider > to deploy TURN to fix its own NAT problems. > Others, myself included, did not agree with this analysis. I believe > that providers will due what is needed to make their service work. Any > provider that skips TURN since they are betting that other providers > deploy it, will probably not be in business long. So I do not agree this > is a problem. Our goal to make the service work -- regardless if the other party deploys a TURN server ... or if legacy clients within our domain are fielded without TURN support. > Another issue that came up is, forgetting inter-provider calls, moving > to address-and-port restricted behavior in TURN servers will make things > worse in a single domain deployment (which is 100% of the cases today). > If you have regional TURN servers in different data centers, and a > customer associated with one TURN server calls a customer associated > with another, you'd incur the cost of two TURN servers. The most > expensive part of that is the traffic in and out of the data center. The > secondary cost would be the server capacity. The folks with an existing > deployment were in the ad-hoc and confirmed that a multi-data center > deployment was a concern and they were worried about this issue. This is clearly a problem for large deployments. The odds of having the client land on the same server is small -- especially if you have regional deployments where clients are directed to the 'best' server. > If you agree (or not) with this conclusion, please speak up. AOL (Bob Andreasen and Elena Furman) support keeping the behavior as-is. Some comments below. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 10 12:16:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1mEu-0002Z8-9c; Mon, 10 Dec 2007 12:16:20 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J1mEt-0002SP-1p for behave-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 12:16:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1mEs-0002PX-MO for behave@ietf.org; Mon, 10 Dec 2007 12:16:18 -0500 Received: from drew.ipv6.franken.de ([2001:638:a02:a001:20e:cff:fe4a:feaa] helo=mail-n.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1mEq-0006IA-T7 for behave@ietf.org; Mon, 10 Dec 2007 12:16:18 -0500 Received: from [192.168.1.15] (p508FC521.dip.t-dialin.net [80.143.197.33]) by mail-n.franken.de (Postfix) with ESMTP id BAB518006D91; Mon, 10 Dec 2007 18:16:15 +0100 (CET) (KNF-authenticated sender: micmac) Message-Id: <2CAB9B0C-5CD3-4B38-835E-769D05031E71@lurchi.franken.de> From: Michael Tuexen To: Bryan Ford In-Reply-To: <54A85AEA-CEA3-49B6-AD48-3B848DD3D1BD@mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 10 Dec 2007 18:16:14 +0100 References: <7B55F180-CCEF-447E-97EB-A0F584E5B12C@mit.edu> <36050A33-B215-497D-9671-67F62DAEE45F@lurchi.franken.de> <54A85AEA-CEA3-49B6-AD48-3B848DD3D1BD@mit.edu> X-Mailer: Apple Mail (2.915) X-Spam-Score: 2.2 (++) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: IETF BEHAVE WG Subject: [BEHAVE] Re: SCTP over NAT and hole-punching? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 Bryan, see my comments in-line. Best regards Michael On Dec 10, 2007, at 4:06 PM, Bryan Ford wrote: > Another, perhaps more substantial issue that occurred to me with > draft-stewart-behave-sctpnat-03.txt is whether it's possible to > provide any kind of peer-to-peer NAT traversal functionality - i.e., > something analogous to UDP or TCP hole punching - with this > approach, or will NATted SCTP always be strictly limited to client/ > server communication? Yes, this will be possible. Both sides will send an INIT to the peer (getting a hole in the NAT) and the simultaneous setup works. I'm not sure if we have already enough description in the ID, but the next rev will have it. > > > The thing is, you seem to be effectively adding SCTP's VTAG to the > "endpoint address tuple" used by SCTP to distinguish different > streams - i.e., now it's "kinda, sorta" (IP, port, vtag) instead of > just (IP, port). At least for the possible multiple SCTP > associations that might emerge from a NAT's single public IP address > and the same internal port, and outbound to the same server address > and port, the VTAG provides the only way to distinguish those > streams. But what if the server wants to be a rendezvous server of > some kind and help clients establish a direct SCTP association > somehow? Will there need to be a way for one client to open an > outbound SCTP connection to another client's public IP address and > port, specifying explicitly the VTAG the other client is using to > talk to the rendezvous server? (Even without the "VTAG addressing" > issue this would presumably need to be an extension to SCTP, since > as far as I know SCTP has no simultanous open functionality like TCP > does.) Yes, using this kind of rendezvous is possible. We have been asked for it a couple of times after the presentation. It is possible, we just did not present it... And SCTP does support of the 'simultaneous open functionality', it is called INIT collision in RFC 4960. > > > Which I guess brings up the higher-level issue, not yet addressed in > "SCTP NAT Traversal Considerations" (draft-xie-behave-sctp-nat- > cons-03), of whether a "NAT for SCTP" project should include peer-to- > peer connectivity in its scope or stay strictly limited to client/ > server? No, it will be in the scope. And we will combine the two documents in one. To be clear: It will be possible to setup a peer to peer association if both ends know the addresses and ports used by the other. Both will start an association and the INIT collision handling of SCTP we make sure the only one association is established. > > > Cheers, > Bryan > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 10 12:52:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1mnq-00045X-7U; Mon, 10 Dec 2007 12:52:26 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J1mnp-0003yg-8y for behave-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 12:52:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1mno-0003wG-Sh for behave@ietf.org; Mon, 10 Dec 2007 12:52:24 -0500 Received: from py-out-1112.google.com ([64.233.166.176]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1mno-0002B4-EU for behave@ietf.org; Mon, 10 Dec 2007 12:52:24 -0500 Received: by py-out-1112.google.com with SMTP id d32so7702765pye for ; Mon, 10 Dec 2007 09:52:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:x-mailer:reply-to:x-priority:message-id:to:cc:subject:in-reply-to:references:mime-version:content-type:content-transfer-encoding; bh=PFEfOe0xf8999/tRQi/r6ux0RmAZrSPBdHvpbzHZt5M=; b=t/0otAHX2PHO7S/pXZVOGi0jvd8TAz6c1vHr/XXMGTF2mGrtzr4HCNdk/ZoBhqvXfhb1j5jPJWeh5A5RvWhQlMxfkmJ3zIt8YDFkSnGrwU9UqXt1nMfe8OhLzLctDFHUlVnEG9M+J7II8PMrZhlsIpC8wQ/fmUEOET1RHRvcQek= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:x-mailer:reply-to:x-priority:message-id:to:cc:subject:in-reply-to:references:mime-version:content-type:content-transfer-encoding; b=fyp/x3pNoxSg1ztlLfK5LxwQV5BL4W1+fOv+omPVWhKt7GygLbo/cfKZXw/RkG+jUF7NM62rmTaOjIKDP6iP+SDAqbx10BznnY+RHEqxxdQ70iziRuz4cvvEHXGaSNlgV6m9OH9StoNTjfypoD8bu5yOgC1O0+THUkAlZ0AA7tw= Received: by 10.65.180.9 with SMTP id h9mr14603286qbp.1197309141229; Mon, 10 Dec 2007 09:52:21 -0800 (PST) Received: from kalien.office.bpsoft.com ( [207.180.138.110]) by mx.google.com with ESMTPS id e19sm3076217qbe.2007.12.10.09.52.19 (version=SSLv3 cipher=OTHER); Mon, 10 Dec 2007 09:52:19 -0800 (PST) Date: Mon, 10 Dec 2007 12:52:21 -0500 From: Bob Andreasen X-Mailer: The Bat! (v3.99.29) Professional X-Priority: 3 (Normal) Message-ID: <1065122831.20071210125221@gmail.com> To: Jonathan Rosenberg Subject: Re: [BEHAVE] TURN Issue #4: Port Adjacency In-Reply-To: <4759CC2B.9050206@cisco.com> References: <4759CC2B.9050206@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bob Andreasen List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Any chance of taking options 1 and 2b -- by making REQUESTED_PORT_PROPS an optional attribute? I do understand that this is needed for many environments -- but it isn't need for all. Given that #1 was on the table (even if only for completeness), making it optional seems like a reasonable change. - Bob On Friday, December 7, 2007, 5:41:47 PM, Jonathan Rosenberg wrote: > This didn't get covered in the WG meeting but was discussed in the ad-hoc. > TURN allows a client to request an even port, and along with it, ask the > TURN server to allocate the odd port one higher. However, the spec > currently has the following confusing words in it: > As such, it is a request for the server to allocate an even > port whose next higher port is also available, and furthermore, a > request for the server to not allocate that one higher port to any > other request except for one that asks for that port explicitly. The > server can honor this request for adjacency at its discretion. The > only constraint is that the allocated port has to be even. > This would seem to imply that a server could respond with an OK > response, allocate the even port, but not even bother with the odd port. > Thus, when the client tries the odd port, it gets rejected. So the > client has to try again. This non-deterministic behavior would > complicate the client. > The options were: > 1. ditch the feature > 2. make it so that the server MUST allocate the even port and the next > higher odd port, and if it can't do both, reject the request. After > allocating both, it holds onto the odd port, waiting for the client to > request it, for: > a. some fixed time, say 30s > b. the duration of the allocation > Folks still wanted this feature since it is used in practice. In the > interests of avoiding another timer, there was agreement on 2b. > Please comment if you agree (or if you don't) on this conclusion. > -Jonathan R. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 10 13:29:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1nNN-0003VG-E8; Mon, 10 Dec 2007 13:29:09 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J1nNM-0003V6-AA for behave-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 13:29:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1nNM-0003Us-0A for behave@ietf.org; Mon, 10 Dec 2007 13:29:08 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1nNK-0008Ba-EQ for behave@ietf.org; Mon, 10 Dec 2007 13:29:07 -0500 Received: from s01060018e70bfb18.wk.shawcable.net ([24.67.234.227] helo=[192.168.1.104]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J1nNJ-0001cp-1X; Mon, 10 Dec 2007 13:29:06 -0500 In-Reply-To: <475D5443.5050601@cisco.com> References: <47599D4F.50102@cisco.com> <200712101056.32140.remi.denis-courmont@nokia.com> <475D5443.5050601@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: <4A3D1671-D40E-449E-ADC3-24D2E8D16B90@magma.ca> Content-Transfer-Encoding: quoted-printable From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #2: Stateful allocations Date: Mon, 10 Dec 2007 10:29:22 -0800 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - s01060018e70bfb18.wk.shawcable.net ([192.168.1.104]) [24.67.234.227] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 10-Dec-07, at 06:59 , Jonathan Rosenberg wrote: > inline: > > R=E9mi Denis-Courmont wrote: >> Le Friday 07 December 2007 21:21:51 ext Jonathan Rosenberg, vous =20 >> avez =E9crit : >>> There was general agreement at the ad-hoc that this is a non-=20 >>> issue. TURN >>> servers are already required to maintain state, in the form of >>> allocations, permissions, channel bindings, and so on. =20 >>> Transaction state >>> is not much more. >>> >>> Note that, rfc3489bis requires stun transactions (including =20 >>> extensions >>> like TURN) to be idempotent. Note that, despite the different =20 >>> response >>> codes for a retransmit and new transaction, TURN remains idempotent. >>> Idempotency only requires that subsequent retries do not alter =20 >>> the state >>> on the server; it does NOT require the same response. We went =20 >>> through >>> this ad-nauseum on XCAP. >>> >>> The proposal is therefore to just document this fact, but =20 >>> otherwise not >>> change anything. >>> >>> Please comment if you agree (or not) with this. >> If I understand correctly, this practically means the server must =20 >> remember the ID of the STUN transaction that created the TURN =20 >> allocation. When it receives an allocation, it returns a success =20 >> response if it's the same ID or an error if it's not. Right? > > Yes. To be consistent with 3489bis, you would also have to have a 10 =20 second timer. 3489bis says: If the request uses UDP transport and is a retransmission of a request for which the server has already generated a success =20 response within the last 10 seconds, the server MUST retransmit the same success response. One way for a server to do this is to remember =20= all transaction IDs received over UDP and their corresponding responses in the last 10 seconds. For short-lived TURN allocations, the 10-second timer is probably =20 pointless, even though 3489bis requires it. For long-lived =20 allocations (days or weeks or even months), the timer might become =20 important -- I haven't worked out the math. In either case, I think =20 the two documents should be consistent. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 10 17:09:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1qo8-000781-0F; Mon, 10 Dec 2007 17:09:00 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J1qo6-00070p-95 for behave-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 17:08:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1qo5-00070h-Vh for behave@ietf.org; Mon, 10 Dec 2007 17:08:57 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1qo3-0005di-Q4 for behave@ietf.org; Mon, 10 Dec 2007 17:08:57 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 10 Dec 2007 14:08:55 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBAM8tAb029611; Mon, 10 Dec 2007 14:08:55 -0800 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lBAM8m0i014749; Mon, 10 Dec 2007 22:08:49 GMT From: "Dan Wing" To: "'Michael Tuexen'" References: <7B55F180-CCEF-447E-97EB-A0F584E5B12C@mit.edu><36050A33-B215-497D-9671-67F62DAEE45F@lurchi.franken.de><54A85AEA-CEA3-49B6-AD48-3B848DD3D1BD@mit.edu> <2CAB9B0C-5CD3-4B38-835E-769D05031E71@lurchi.franken.de> Subject: RE: [BEHAVE] Re: SCTP over NAT and hole-punching? Date: Mon, 10 Dec 2007 14:08:47 -0800 Message-ID: <0dd501c83b79$40902810$8f76150a@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: Acg7UGutE+uAj2+fTPyCqZoO4ZKcxAAKIp/Q In-Reply-To: <2CAB9B0C-5CD3-4B38-835E-769D05031E71@lurchi.franken.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=690; t=1197324535; x=1198188535; 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]=20Re=3A=20SCTP=20over=20NAT=20 and=20hole-punching? |Sender:=20; bh=t1AyoiA6TNYlSTdB44pwavDgl66bBiE4uLeSn21n4O0=; b=hSNIl3cw5RlWSN2mSLBWENNRySJXBgeREZNmtLlmPHETKhCuwNyGaYW0RA XdJ9HburOFKA0ijOXm0vN0cT7COGA3hW0E3p7G/cmHDw9YEoA+ATCN6/kl4B J0jPkyCuVp8aIPCRAy8N/s7Tj472yCWw6aJGOOCP/V/3aPfNQFnvg=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: 'Bryan Ford' , 'IETF 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 > To be clear: It will be possible to setup a peer to peer association > if both ends know the addresses and ports used by the other. Won't you need to also communicate the VTAG? With UDP and TCP, where NAPT is often performed, the NAPT device ensures there is no port collision (by remapping port numbers). With your approach with SCTP, you don't want the NAT to change port numbers and only rely on the uniqueness of randomly-chosen port numbers to prevent a collision. It seems that when port numbers do collide, you'll want to provide the NAT with the VTAG so it can differentiate the various hosts behind the NAT that happened to choose the same port number. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 10 19:19:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1sqQ-0005Y0-QA; Mon, 10 Dec 2007 19:19:30 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J1sqO-0005XV-V7 for behave-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 19:19:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1sqO-0005XN-LQ for behave@ietf.org; Mon, 10 Dec 2007 19:19:28 -0500 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1sqO-0000YF-7P for behave@ietf.org; Mon, 10 Dec 2007 19:19:28 -0500 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id lBB0JOwE006825; Mon, 10 Dec 2007 19:19:24 -0500 (EST) Received: from [192.168.1.100] (pool-68-160-35-101.bos.east.verizon.net [68.160.35.101]) (authenticated bits=0) (User authenticated as baford@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id lBB0JHjh009722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 10 Dec 2007 19:19:18 -0500 (EST) Message-Id: From: Bryan Ford To: Michael Tuexen In-Reply-To: <2CAB9B0C-5CD3-4B38-835E-769D05031E71@lurchi.franken.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 10 Dec 2007 19:19:16 -0500 References: <7B55F180-CCEF-447E-97EB-A0F584E5B12C@mit.edu> <36050A33-B215-497D-9671-67F62DAEE45F@lurchi.franken.de> <54A85AEA-CEA3-49B6-AD48-3B848DD3D1BD@mit.edu> <2CAB9B0C-5CD3-4B38-835E-769D05031E71@lurchi.franken.de> X-Mailer: Apple Mail (2.915) X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: IETF BEHAVE WG Subject: [BEHAVE] Re: SCTP over NAT and hole-punching? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Ah - OK, that all sounds great; I wasn't aware of the INIT collision extension (i.e., didn't do my homework well enough I guess :) ). Thanks! Bryan On Dec 10, 2007, at 12:16 PM, Michael Tuexen wrote: > Hi Bryan, > > see my comments in-line. > > Best regards > Michael > > On Dec 10, 2007, at 4:06 PM, Bryan Ford wrote: > >> Another, perhaps more substantial issue that occurred to me with >> draft-stewart-behave-sctpnat-03.txt is whether it's possible to >> provide any kind of peer-to-peer NAT traversal functionality - >> i.e., something analogous to UDP or TCP hole punching - with this >> approach, or will NATted SCTP always be strictly limited to client/ >> server communication? > Yes, this will be possible. Both sides will send an INIT to the peer > (getting a hole in the NAT) and > the simultaneous setup works. I'm not sure if we have already enough > description in the ID, but > the next rev will have it. >> >> >> The thing is, you seem to be effectively adding SCTP's VTAG to the >> "endpoint address tuple" used by SCTP to distinguish different >> streams - i.e., now it's "kinda, sorta" (IP, port, vtag) instead of >> just (IP, port). At least for the possible multiple SCTP >> associations that might emerge from a NAT's single public IP >> address and the same internal port, and outbound to the same server >> address and port, the VTAG provides the only way to distinguish >> those streams. But what if the server wants to be a rendezvous >> server of some kind and help clients establish a direct SCTP >> association somehow? Will there need to be a way for one client to >> open an outbound SCTP connection to another client's public IP >> address and port, specifying explicitly the VTAG the other client >> is using to talk to the rendezvous server? (Even without the "VTAG >> addressing" issue this would presumably need to be an extension to >> SCTP, since as far as I know SCTP has no simultanous open >> functionality like TCP does.) > Yes, using this kind of rendezvous is possible. We have been asked > for it a couple of times > after the presentation. It is possible, we just did not present it... > > And SCTP does support of the 'simultaneous open functionality', it > is called INIT collision in RFC 4960. >> >> >> Which I guess brings up the higher-level issue, not yet addressed >> in "SCTP NAT Traversal Considerations" (draft-xie-behave-sctp-nat- >> cons-03), of whether a "NAT for SCTP" project should include peer- >> to-peer connectivity in its scope or stay strictly limited to >> client/server? > No, it will be in the scope. And we will combine the two documents > in one. > To be clear: It will be possible to setup a peer to peer association > if both ends know the > addresses and ports used by the other. Both will start an > association and the INIT collision > handling of SCTP we make sure the only one association is established. >> >> >> Cheers, >> Bryan >> >> > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 10 19:53:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1tND-0007I2-VS; Mon, 10 Dec 2007 19:53:23 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J1tNB-0007H5-Ta for behave-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 19:53:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1tNB-0007FQ-JD for behave@ietf.org; Mon, 10 Dec 2007 19:53:21 -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 1J1tNB-0001NU-7t for behave@ietf.org; Mon, 10 Dec 2007 19:53:21 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 10 Dec 2007 16:53:21 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBB0rKjj004833 for ; Mon, 10 Dec 2007 16:53:20 -0800 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBB0rK9N020136 for ; Tue, 11 Dec 2007 00:53:20 GMT From: "Dan Wing" To: "'IETF BEHAVE WG'" Date: Mon, 10 Dec 2007 16:53:20 -0800 Message-ID: <100301c83b90$397138f0$8f76150a@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: Acg7kDkb89uss+0KQyCP1RuIiLjg6A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=186; t=1197334400; x=1198198400; 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:=20draft=20minutes=20posted |Sender:=20; bh=y9reRRvCUWyDlPn1vayCVYXw6ikxd7nFvb5wBjIUBsg=; b=pU4SuUbNUC+XjTBPPPIaqZr151svXGs2ExbD3m+dI2EyEMgRIjIvGyJFR/ E2Rgb5VgrACbWMlS0etg7wZu306dUNNeYOKx3Sq6A++0Pz0gin2uYlWElcca C0TuXj6bjKkUZELdF3IOQFkojXfS+kklbBLSakyGjWuLg/aDVxIBs=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [BEHAVE] draft minutes posted X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Draft minutes are posted at: http://www3.ietf.org/proceedings/07dec/minutes/behave.txt Please send me any comments/updates. Thanks to Dan York for the meeting minutes! -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 10 21:37:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1uzf-0001Zj-ST; Mon, 10 Dec 2007 21:37:11 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J1uzf-0001Zd-BH for behave-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 21:37:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1uzf-0001ZV-1V for behave@ietf.org; Mon, 10 Dec 2007 21:37:11 -0500 Received: from nz-out-0506.google.com ([64.233.162.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1uzc-0003b0-Ok for behave@ietf.org; Mon, 10 Dec 2007 21:37:11 -0500 Received: by nz-out-0506.google.com with SMTP id n1so759716nzf for ; Mon, 10 Dec 2007 18:37:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=JN0Hk4vEif9UnURz7XKbi6qkZFwpPs6HsXQRaTEgdDo=; b=qeEKRufnmQgSaXoYPQlz9A/aLiyWo36af4fbby+mrSwvAz5in2YGq5wOLdFZ2mJAeo3FQ9hASFSRrfejREpkL+w2U/N5XpVVBb/XA5xhuEnqS/bNcoFGxhonwWlNHMfO4KbJazMTS8Nud/L+NKPTVrpi9k1NOJRtX0TVlBvQcyI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=oqPtbctiVe6hNDsJqB/Eqr4IWvonX+W6UqulwVhdcGlZ2TebGAD9tzii62AxmK8ezvEFCFOxebgUz7UeuMhNM6S20IAHu6jZfYHsK6HOupcNirF0/XVq1t6SDldNh3Sk0LS5jpjOgazkVbnalVJvgNIk/MBeLczL7DPPLSkgdLQ= Received: by 10.142.191.2 with SMTP id o2mr3418069wff.1197340627921; Mon, 10 Dec 2007 18:37:07 -0800 (PST) Received: by 10.142.52.6 with HTTP; Mon, 10 Dec 2007 18:37:07 -0800 (PST) Message-ID: Date: Mon, 10 Dec 2007 18:37:07 -0800 From: "Derek MacDonald" To: "Bob Andreasen" Subject: Re: [BEHAVE] TURN Issue #4: Port Adjacency In-Reply-To: <1065122831.20071210125221@gmail.com> MIME-Version: 1.0 References: <4759CC2B.9050206@cisco.com> <1065122831.20071210125221@gmail.com> X-Google-Sender-Auth: 24adae4f098356b2 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1940503426==" Errors-To: behave-bounces@ietf.org --===============1940503426== Content-Type: multipart/alternative; boundary="----=_Part_18466_446679.1197340627925" ------=_Part_18466_446679.1197340627925 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline My experience is that this is often needed in all deployments w/ heterogeneous endpoints. Of course, a counterargument is that an endpoint going through a NAT which does not tend to map ports adjacently has no way of guaranteeing this. The question is: is there a concern that turn will be used to dodge implementing 3605? I suspect that RTCP is generally failing in environments where the NAT is doing many concurrent allocations. So, a new turn open issue: Should adjacent port allocation be in scope for TURN? -Derek On Dec 10, 2007 9:52 AM, Bob Andreasen wrote: > > Any chance of taking options 1 and 2b -- by making > REQUESTED_PORT_PROPS an optional attribute? I do understand that this > is needed for many environments -- but it isn't need for all. Given > that #1 was on the table (even if only for completeness), making it > optional seems like a reasonable change. > > - > Bob > > On Friday, December 7, 2007, 5:41:47 PM, Jonathan Rosenberg wrote: > > > This didn't get covered in the WG meeting but was discussed in the > ad-hoc. > > > TURN allows a client to request an even port, and along with it, ask the > > TURN server to allocate the odd port one higher. However, the spec > > currently has the following confusing words in it: > > > As such, it is a request for the server to allocate an even > > port whose next higher port is also available, and furthermore, a > > request for the server to not allocate that one higher port to any > > other request except for one that asks for that port explicitly. > The > > server can honor this request for adjacency at its discretion. The > > only constraint is that the allocated port has to be even. > > > > This would seem to imply that a server could respond with an OK > > response, allocate the even port, but not even bother with the odd port. > > Thus, when the client tries the odd port, it gets rejected. So the > > client has to try again. This non-deterministic behavior would > > complicate the client. > > > The options were: > > > 1. ditch the feature > > 2. make it so that the server MUST allocate the even port and the next > > higher odd port, and if it can't do both, reject the request. After > > allocating both, it holds onto the odd port, waiting for the client to > > request it, for: > > a. some fixed time, say 30s > > b. the duration of the allocation > > > Folks still wanted this feature since it is used in practice. In the > > interests of avoiding another timer, there was agreement on 2b. > > > Please comment if you agree (or if you don't) on this conclusion. > > > -Jonathan R. > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > ------=_Part_18466_446679.1197340627925 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline My experience is that this is often needed in all deployments w/ heterogeneous endpoints.  Of course, a counterargument is that an endpoint going through a NAT which does not tend to map ports adjacently has no way of guaranteeing this.

The question is: is there a concern that turn will be used to dodge implementing 3605?  I suspect that RTCP is generally failing in environments where the NAT is doing many concurrent allocations.

So, a new turn open issue:

Should adjacent port allocation be in scope for TURN?

-Derek

On Dec 10, 2007 9:52 AM, Bob Andreasen <rjandreasen@gmail.com> wrote:

Any chance of taking options 1 and 2b -- by making
REQUESTED_PORT_PROPS an optional attribute?  I do understand that this
is needed for many environments -- but it isn't need for all.  Given
that #1 was on the table (even if only for completeness), making it
optional seems like a reasonable change.

-
Bob

On Friday, December 7, 2007, 5:41:47 PM, Jonathan Rosenberg wrote:

> This didn't get covered in the WG meeting but was discussed in the ad-hoc.

> TURN allows a client to request an even port, and along with it, ask the
> TURN server to allocate the odd port one higher. However, the spec
> currently has the following confusing words in it:

>     As such, it is a request for the server to allocate an even
>     port whose next higher port is also available, and furthermore, a
>     request for the server to not allocate that one higher port to any
>     other request except for one that asks for that port explicitly.  The
>     server can honor this request for adjacency at its discretion.  The
>     only constraint is that the allocated port has to be even.


> This would seem to imply that a server could respond with an OK
> response, allocate the even port, but not even bother with the odd port.
> Thus, when the client tries the odd port, it gets rejected. So the
> client has to try again. This non-deterministic behavior would
> complicate the client.

> The options were:

> 1. ditch the feature
> 2. make it so that the server MUST allocate the even port and the next
> higher odd port, and if it can't do both, reject the request. After
> allocating both, it holds onto the odd port, waiting for the client to
> request it, for:
>      a. some fixed time, say 30s
>      b. the duration of the allocation

> Folks still wanted this feature since it is used in practice. In the
> interests of avoiding another timer, there was agreement on 2b.

> Please comment if you agree (or if you don't) on this conclusion.

> -Jonathan R.



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

------=_Part_18466_446679.1197340627925-- --===============1940503426== 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 --===============1940503426==-- From behave-bounces@ietf.org Mon Dec 10 21:46:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1v8G-00030t-Jx; Mon, 10 Dec 2007 21:46:04 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J1v8E-00030f-Nx for behave-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 21:46:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1v8E-00030X-E9 for behave@ietf.org; Mon, 10 Dec 2007 21:46:02 -0500 Received: from nz-out-0506.google.com ([64.233.162.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1v8D-0003kk-4H for behave@ietf.org; Mon, 10 Dec 2007 21:46:02 -0500 Received: by nz-out-0506.google.com with SMTP id n1so760419nzf for ; Mon, 10 Dec 2007 18:46:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=B5zgWPepbMqnv0kN2MLhsH31dS1YqGtE4vhgQ9g0qy8=; b=G0GJ/YTtBwZ3luA5RaCUgBUz+FA+K7h7BrmkAYvKpetSvLzYtkHVuH/Esiv70889Ss+n3kXNF8qIUnPLjCiACk4K8ACOqI5WPS5+jNHjwvbF7KQBOCeP9XBPl77u0JyC92N2DsM/Plcd4jSnMKBQ4d0ZN46X+Bq1pSg5vRw97QY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=XVIRO5y1Sa1ZO/JvmuwkMJJt9Zl0V84vTQTE6GwyoZ53pl5dKlxxFzR3ff+VVCDSDNEJjG1gDjDEvdub1cas1zaGVj3zzWfvsWUr+L1wSVssuAdeXvApIA2U9uY7+R3ta2atFUuMJIADIBIRmvM1yZs8DOiwwxwezjNero20xhI= Received: by 10.142.255.14 with SMTP id c14mr1401960wfi.1197341160181; Mon, 10 Dec 2007 18:46:00 -0800 (PST) Received: by 10.142.52.6 with HTTP; Mon, 10 Dec 2007 18:46:00 -0800 (PST) Message-ID: Date: Mon, 10 Dec 2007 18:46:00 -0800 From: "Derek MacDonald" To: "Jonathan Rosenberg" Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages In-Reply-To: <4759D19B.50005@cisco.com> MIME-Version: 1.0 References: <4759D19B.50005@cisco.com> X-Google-Sender-Auth: 960d74362fb952b4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2050633673==" Errors-To: behave-bounces@ietf.org --===============2050633673== Content-Type: multipart/alternative; boundary="----=_Part_18483_26756060.1197341160163" ------=_Part_18483_26756060.1197341160163 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I like this change because it will simplify the implementation of a client that uses both ICE/TURN as two modes of TURN/ICE packet writing will no have to be supported. I do not believe the reduction in the total # of channels is relevant; 32767 channels is half of the available port space, which is much more than an endpoint would expect from a shared(enterprise) NAT. The TURN server will probably run out of tuples well before the client does. -Derek On Dec 7, 2007 3:04 PM, Jonathan Rosenberg wrote: > This issue was not in my slides. It was brought up at the mike in the > WG, and was discussed there. It was not discussed further at the ad-hoc. > > As of turn-05, we introduced a framing mechanism, which is a 4 byte > header consisting of 2 bytes channel and 2-bytes length. This framing > header precedes ALL packets sent between a client and its TURN server, > including both application data and TURN messages themselves, which are > sent on channel zero. > > Ekr raised a question of why this header was needed for actual TURN > messages. After all, he argued, we went through all this trouble to make > STUN (and thus TURN) differentiatable from each other. Indeed, others > noted that the framing header itself looks very similar to the top 4 > bytes of the STUN message format anyway: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0| STUN Message Type | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Magic Cookie | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Transaction ID (96 bits) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > and the proposed framing header: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Channel | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > So an alternative design is to make the framing header look like: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| Channel | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > So that there are 15 bits of channel instead of 16. Placing a 1 in that > position makes the framing header always a non-match for STUN messages. > Thus, it would not be even needed to do the more complex matching > operations defined in STUN; a 1-bit check would do the job to separate > out application data from STUN/TURN. > > The benefits of this change would be: > > 1. We would, once again, be able to run STUN and TURN on the same > port on the server. As of turn-05 they MUST run on different ports > because the framing header was unique to TURN. This could be a feature > or a bug depending on your perspective: > > FEATURE: TURN and STUN are actually very different; using > separate ports would allow a firewall to block one and not the other. > > BUG: practically speaking separate ports doesnt help since > with DNS the ports can be dynamic anyway. In addition, its always good > to use fewer ports on a server. Also its weird that an extension to a > protocol would run on a different port; that kind of tells you its not > an extension. > > 2. Reduces the size of TURN messages by 4 bytes. This is a minor > benefit and the real one is having a single port. > > 3. it'd be a little clearer to explain to people that TURN is an > extension to STUN, rather than saying, TURN is a STUN extension that is > run over a new framing header > > The drawbacks of this change would be: > > 1. cuts the number of channels in half > > > An alternative design would be to use the full 16 bits for channel > numbers, and then rely on the full suite of STUN differentiation > techniques to demux. However, my preference in general is to not do that > when its not actually needed. It complicates message processing and I > don't think its worth it. 32767 channels is also a LOT for our > envisioned use cases. > > This was somewhat inconclusive at the microphone. I'm personally on the > fence and don't feel that strongly. I probably midly prefer making this > change. > > Please comment on whether you prefer this change or not. > > Thanks, > Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > ------=_Part_18483_26756060.1197341160163 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I like this change because it will simplify the implementation of a client that uses both ICE/TURN as two modes of TURN/ICE packet writing will no have to be supported.

I do not believe the reduction in the total # of channels is relevant; 32767 channels is half of the available port space, which is much more than an endpoint would expect from a shared(enterprise) NAT.

The TURN server will probably run out of tuples well before the client does.

-Derek

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

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

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

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


and the proposed framing header:

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

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


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

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

The benefits of this change would be:

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

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

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

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

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

The drawbacks of this change would be:

  1. cuts the number of channels in half


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

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

Please comment on whether you prefer this change or not.

Thanks,
Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
jdrosen@cisco.com
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com


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

------=_Part_18483_26756060.1197341160163-- --===============2050633673== 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 --===============2050633673==-- From behave-bounces@ietf.org Mon Dec 10 22:35:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1vtx-0001t5-75; Mon, 10 Dec 2007 22:35:21 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J1vtv-0001sy-RD for behave-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 22:35:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1vtv-0001sn-G1 for behave@ietf.org; Mon, 10 Dec 2007 22:35:19 -0500 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1vts-0004id-Hf for behave@ietf.org; Mon, 10 Dec 2007 22:35:19 -0500 Received: by py-out-1112.google.com with SMTP id d32so8875916pye for ; Mon, 10 Dec 2007 19:35:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=7Rq0D2pa7iz4HEB4/IKDen9sLMCvAEmyTO2fIL5WQdQ=; b=fhwAAqnBxBcnhcf8BxUz/baTeJNKfNwu21IhYo/mxuQYK5DiPWLduG71vFDzkE62C/VeFoOo84zk2mDZRuPn88N0e/5l7ZcIHVoQY+bUQHKX+aLZSRexq2T2FR7fkfY7A8fcrye2ksCR1nYz7kHA9YApqe+diWbThXdPXHzuUh0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=g89S7pMLRtSZWjHpnjL7JH3LYXjJzAZX34ZxyHhRTZb1JrhDp0d8Oe7sJ0bkrhOKXLkl6VUFD6Byo+y46arlnDpOeD5dvpMub1Yj/wHI1/JT8GTX2RagUnBoAAB8Y3RM+GkdNzIIzHBRXh6ABJQJXZRzOiJGDss7RnsoV4S196k= Received: by 10.142.187.2 with SMTP id k2mr1934655wff.1197344115567; Mon, 10 Dec 2007 19:35:15 -0800 (PST) Received: by 10.142.52.6 with HTTP; Mon, 10 Dec 2007 19:35:15 -0800 (PST) Message-ID: Date: Mon, 10 Dec 2007 19:35:15 -0800 From: "Derek MacDonald" To: "Jonathan Rosenberg" Subject: Re: [BEHAVE] Alternative channel binding mechanism for TURN In-Reply-To: <475998D7.8010903@cisco.com> MIME-Version: 1.0 References: <475998D7.8010903@cisco.com> X-Google-Sender-Auth: cdc32e973fe9d2d5 X-Spam-Score: 0.0 (/) X-Scan-Signature: efb5d987e2484f3d9a304cc31a003441 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0145829978==" Errors-To: behave-bounces@ietf.org --===============0145829978== Content-Type: multipart/alternative; boundary="----=_Part_18621_22254323.1197344115569" ------=_Part_18621_22254323.1197344115569 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I am in favour of the new technique because it avoids the following issues(as well as the benefits described by Jonathan) * the packet rate is not double the media rate while the channel is established. This would only likely be an issue when a call forks to many endpoints, but might be more of an issue in a future application of turn. * With turn-05, there is a very weird edge case that could technically occur. If the server or the client runs out of channel numbers the allocation should be restarted. With turn-05, the client and the server must keep track of both client and server channel #'s, as this will not necessarily be symmetric. It will *likely* be, but it isn't guaranteed. Unfortunately, if the server runs out(or is low) of channels, there is no way to signal to the client that an new allocation needs to be created. In any case, suspect most client implementations would not track server channel #s...so if we can avoid it, we should. Another issue in turn-05 is tat there is no recovery mechanism for when an allocation runs out of channels in either mechanism. With ekr's mechanism, we can fall back to allocated data with a little more overhead and no loss of function. That said, there are a couple of edge cases we need to consider if we use the new mechanism, due to the lack of a 3-way handshake in the ChannelBind transaction. 1. should we treat encapsulated data as an imlicit ACK of the relevant ChannelBind? 2. what should the client behavior be when the ChannelBind fails? Personally, I think #1 is fine, but it should be an optional optimization for the client. The server has no way of knowing if a BindOK response was received by the client. For, #2 I want to define ChannelBind failure as: the client did not receive a ChannelBind response or(optionally) encapsulated data on the channel At the ad-hoc, we thought that the client should treat the allocation as dead. Dead is not particlarily well defined in this context, specifically: should the client assume that data sent on other channels is not being delivered? This could get quite complicated, so I propose the following client behavior in this case: If a ChannelBind transaction fails, the turn client should invalidate the allocation and apply the same application logic that would be used when a NAT reboot/rebind is detected. This maps back to the general architectural scope of turn as a NAT upgrade rather than a NAT replacement. -Derek On Dec 7, 2007 11:02 AM, Jonathan Rosenberg wrote: > Several folks met last night at the TURN ad-hoc to discuss the various > open issues. One of the biggest was whether we should change the channel > binding mechanism from what is in the document (using Send along with a > confirmation indication) to what ekr suggested. We wrote down what that > alternate flow would look like and came up with pros and cons. Here is > what we came up with. > > The mechanism that ekr is proposing basically looks like this: > > Client TURN Server Peer Peer2 > | | | | > | | | | > | | | | > |(1) [0]Allocate | | | > |--------------->| | | > | | | | > | | | | > |(2) [0]AllocOK | | | > |<---------------| | | > | | | | > | | | | > |Data to send | | | > | | | | > | | | | > | | | | > |(3) [0]ChannelBind(7) | | > |--------------->| | | > | | | | > | | | | > |(4) [0]Send | | | > |--------------->| | | > | | | | > | | | | > | |(5) UDP Packet | | > | |--------------->| | > | | | | > | | | | > |(6) [0]BindOK | | | > |<---------------| | | > | | | | > | | | | > |(7) [7]UDP Packet | | > |--------------->| | | > | | | | > | | | | > | |(8) UDP Packet | | > | |--------------->| | > | | | | > | | | | > | |(9) UDP Packet | | > | |<---------------| | > | | | | > | | | | > |(10) [7]UDP Packet | | > |<---------------| | | > | | | | > | | | | > | |(11) UDP Packet | | > | |<--------------------------------| > | | | | > | | | | > | |Permission Open | | > | | | | > | | | | > | | | | > |(12) [0]Data Ind. | | > |<---------------| | | > | | | | > | | | | > |(13) [0]ChannelBind(8) | | > |--------------->| | | > | | | | > | | | | > |(14) [0]BindOK | | | > |<---------------| | | > | | | | > | | | | > | |(15) UDP Packet | | > | |<--------------------------------| > | | | | > | | | | > |(16) [8]UDP Packet | | > |<---------------| | | > | | | | > | | | | > | | | | > | | | | > > In terms of notation, the square brackets in front of a TURN message > indicate what channel that message is on. > > The client does the Allocate as currently defined (messages 1,2). > Shortly thereafter, the client has data to send. It knows that it will > have a bunch of data, so it would like to create a channel for > communications with the specific peer. One of the benefits of this > proposed flow (noted further below), is that by separating data > transmission from channel binding, we can make channel binding something > a client can do at its discretion. In this case, it wants to bind a > channel for this particular peer. > > So, it sends a ChannelBind transaction, on the turn channel (channel 0). > The client requests channel 7 for communications to and from the peer. > At this point, the client is prepared to receive data on channel 7. In > ekr's proposed flow, there is a single channel number for traffic both > to and from a particular peer. When the server receives the ChannelBind, > it creates channel 7 and maps it to the peer. From this point forward, > the server will relay traffic from that peer, towards the client, over > channel 7. Furthermore, it will accept traffic from the client, on > channel 7, and forward to the peer. Note that, even though the client > has not received the response to the ChannelBind request, the server is > guaranteed that the client is prepared to receive data on channel 7. > > However, the client doesn't want to wait for the ChannelBind response to > send the data. Until it gets that response, it cannot send data over > that channel. So, until then, it sends data encapsulated using the Send > indication (message 4). When the server receives this, it relays the > data to the peer (message 5) and opens a permission to the corresponding > IP address (the folks in the room last night were unsure if ChannelBind > also creates a permission, with opinion slightly in favor of no). > > Now, at some point the ChannelBind response is received by the client > (message 6). After that point, the client can now send data to this peer > unencapsulated, on the bound channel. So, it uses channel 7 (message 7) > and the TURN server relays data to the peer (message 8). > > Now, the peer sends data towards the TURN server (message 9). In this > particular case, a channel has already been bound to this peer on the > TURN server. So, the TURN server sends the data to the client on the > existing channel (message 10). Another peer (for example), with the same > IP address but from a different port, now sends data to the TURN server > (message 11). Since a permission is open for this IP address, the TURN > server will relay the data to the client. However, there is no channel > bound for this peer. As a consequence, the server encapsulates the data > in a Data indication (message 12). Note that, the server itself does NOT > try to bind a channel. Only the client can do that. > > Instead, the client, upon receiving the data, decides it would like a > channel for this second peer. So, it sends a ChannelBind (message 13) > for this new peer. This is received by the TURN server and it binds > channel 8 to this peer, and sends the response (message 14). Now, when > the next datagram arrives from this new peer (message 15), it is sent to > the client unencapsulated on channel 8 (message 16). > > In comparing this technique (Ekrs Technique) with the one in > draft-ietf-behave-turn-05 (Current Technique), we came up with the > following pros and cons: > > Ekrs Technique > -------------- > > PRO: Allows the client to decide, on a case by case basis, whether to > pay the overhead (ChannelBind transaction) to bind a channel to a peer. > For example, in ICE exchanges, the client could skip channel binding for > the connectivity checks, and only do the binding if ICE selects the peer > transport address. > > PRO: Related to the previous point, the current channel binding > mechanism does not allow a client to remove or delete a channel binding. > Thus, for an allocation which is very long lived, the client could > eventually run out of channels and need to re-allocate to clear them all > or get more channels. Since Ekrs Technique allows the client to > selectively channel bind, when used with protocols like ICE where it is > not needed to channel bind for all peers, the allocation will 'last > longer' - that is, channel numbers get exhausted more slowly. > Architecturally, this is because Ekrs Technique separates channel > binding and data transmission, whereas the Current Technique combines > them. > > CON: Under packet loss, it is possible that the ChannelBind request > could be lost. If so, it will be retransmitted an RTO later. This means > that, the amount of time between request and response is equal to RTT + > 2^N * RTO, where N is the number of packet losses. The client cannot > send unencapsulated data until the ChannelBind response is received. > This duration is therefore equal to RTT+ 2^N*RTO, which is longer than > the Current Technique. There was split opinions on whether this was a > big deal or not, but it is a CON. > > PRO: Seems simpler to have a single channel number for messages in both > directions > > PRO: If a channel binding is in place for a peer, the first data from > that peer can be sent immediatley unencapsulated. With the Current > Technique, since channel numbers are always different in each direction, > the first packet (and indeed, the first RTT set of packets after the > first) will be sent encapsulated. > > PRO: there is a documented security concern with the Current Technique > in TURN-5. Since ChannelConfirm is an indication, it is unauthenticated. > An attacker could, upon seeing a Send indication from a client, send a > faked ChannelConfirm indication, and then cause the Send request to be > discarded. As a consequence, the client will believe the channel is > bound, when it is not. The client will, for the remaining duration of > the allocation, send data on that channel, and it will be discarded by > the TURN server. The client will not know that this happened. With Ekrs > Technique, this attack is mitigated. > > PRO: Does not require the client to receive requests and send responses. > There has been some debate on whether this is important. Note that this > PRO is shared by both techniques. > > PRO: A client could, as a matter of local implementation choice, elect > to not implement or use Send. Instead, it can wait for channels to be > bound and send data unencapsulated. This does mean that clients would > either drop data to be send prior to receiving the ChannelBind response, > else delay sending to that time. > > > > Current Technique > ----------------- > > CON: Each Send indication (and Data indication) causes a ChannelConfirm > indication. If the client is sending a lot of data, say, at rate R, this > will cause R*RTT number of ChannelConfirm messages to be sent. In > essence, the server 'spams' the client will redundant ChannelConfirm > messages, even when there was no packet loss. > > PRO: The amount of time until a client can sent unencapsulated data is > equal to RTT + T*N, where N is the number of packet losses and T is the > inter-arrival time between data from client to the peer. This number > will typically be lower than Ekrs Technique under conditions of packet > loss. Note that they are identical in conditions of no packet loss. > > PRO: In the case of TCP between client and server, the server can omit > sending ChannelConfirm and the client can send data unencapsulated > immediately. With Ekrs technique, the client can also send data > unencapsulated immediately, but since ChannelBind is a transaction, a > response is still required. > > PRO: Does not require the client to receive requests and send responses. > There has been some debate on whether this is important. Note that this > PRO is shared by both techniques. > > > > > Of the folks present, most (including myself) were in favor of Ekrs > Technique. Consequently, we'd like to confirm this decision, and see if > there is rough consensus to go with Ekrs technique. > > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > ------=_Part_18621_22254323.1197344115569 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I am in favour of the new technique because it avoids the following issues(as well as the benefits described by Jonathan)

* the packet rate is not double the media rate while the channel is established.  This would only likely be an issue when a call forks to many endpoints, but might be more of an issue in a future application of turn.
* With turn-05, there is a very weird edge case that could technically occur.  If the server or the client runs out of channel numbers the allocation should be restarted.  With turn-05, the client and the server must keep track of both client and server channel #'s, as this will not necessarily be symmetric.  It will *likely* be, but it isn't guaranteed.  Unfortunately, if the server runs out(or is low) of channels, there is no way to signal to the client that an new allocation needs to be created.

In any case, suspect most client implementations would not track server channel #s...so if we can avoid it, we should.  Another issue in turn-05 is tat there is no recovery mechanism for when an allocation runs out of channels in either mechanism.  With ekr's mechanism, we can fall back to allocated data with a little more overhead and no loss of function. 

That said, there are a couple of edge cases we need to consider if we use the new mechanism, due to the lack of a 3-way handshake in the ChannelBind transaction.

1. should we treat encapsulated data as an imlicit ACK of the relevant ChannelBind?
2. what should the client behavior be when the ChannelBind fails?

Personally, I think #1 is fine, but it should be an optional optimization for the client. The server has no way of knowing if a BindOK response was received by the client.

For, #2 I want to define ChannelBind failure as:  the client did not receive a ChannelBind response or(optionally) encapsulated data on the channel

At the ad-hoc, we thought that the client should treat the allocation as dead.  Dead is not particlarily well defined in this context, specifically:  should the client assume that data sent on other channels is not being delivered?

This could get quite complicated, so I propose the following client behavior in this case:

   If a ChannelBind transaction fails, the turn client should invalidate the allocation and apply the same application logic that would be used when a NAT reboot/rebind is detected.

This maps back to the general architectural scope of turn as a NAT upgrade rather than a NAT replacement.

-Derek

On Dec 7, 2007 11:02 AM, Jonathan Rosenberg < jdrosen@cisco.com> wrote:
Several folks met last night at the TURN ad-hoc to discuss the various
open issues. One of the biggest was whether we should change the channel
binding mechanism from what is in the document (using Send along with a
confirmation indication) to what ekr suggested. We wrote down what that
alternate flow would look like and came up with pros and cons. Here is
what we came up with.

The mechanism that ekr is proposing basically looks like this:

       Client         TURN Server         Peer             Peer2
          |                |                |                |
          |                |                |                |
          |                |                |                |
          |(1) [0]Allocate |                |                |
          |--------------->|                |                |
          |                |                |                |
          |                |                |                |
          |(2) [0]AllocOK  |                |                |
          |<---------------|                |                |
          |                |                |                |
          |                |                |                |
          |Data to send    |                |                |
          |                |                |                |
          |                |                |                |
          |                |                |                |
          |(3) [0]ChannelBind(7)            |                |
          |--------------->|                |                |
          |                |                |                |
          |                |                |                |
          |(4) [0]Send     |                |                |
          |--------------->|                |                |
          |                |                |                |
          |                |                |                |
          |                |(5) UDP Packet  |                |
          |                |--------------->|                |
          |                |                |                |
          |                |                |                |
          |(6) [0]BindOK   |                |                |
          |<---------------|                |                |
          |                |                |                |
          |                |                |                |
          |(7) [7]UDP Packet                |                |
          |--------------->|                |                |
          |                |                |                |
          |                |                |                |
          |                |(8) UDP Packet  |                |
          |                |--------------->|                |
          |                |                |                |
          |                |                |                |
          |                |(9) UDP Packet  |                |
          |                |<---------------|                |
          |                |                |                |
          |                |                |                |
          |(10) [7]UDP Packet               |                |
          |<---------------|                |                |
          |                |                |                |
          |                |                |                |
          |                |(11) UDP Packet |                |
          |                |<--------------------------------|
          |                |                |                |
          |                |                |                |
          |                |Permission Open |                |
          |                |                |                |
          |                |                |                |
          |                |                |                |
          |(12) [0]Data Ind.                |                |
          |<---------------|                |                |
          |                |                |                |
          |                |                |                |
          |(13) [0]ChannelBind(8)           |                |
          |--------------->|                |                |
          |                |                |                |
          |                |                |                |
          |(14) [0]BindOK  |                |                |
          |<---------------|                |                |
          |                |                |                |
          |                |                |                |
          |                |(15) UDP Packet |                |
          |                |<--------------------------------|
          |                |                |                |
          |                |                |                |
          |(16) [8]UDP Packet               |                |
          |<---------------|                |                |
          |                |                |                |
          |                |                |                |
          |                |                |                |
          |                |                |                |

In terms of notation, the square brackets in front of a TURN message
indicate what channel that message is on.

The client does the Allocate as currently defined (messages 1,2).
Shortly thereafter, the client has data to send. It knows that it will
have a bunch of data, so it would like to create a channel for
communications with the specific peer. One of the benefits of this
proposed flow (noted further below), is that by separating data
transmission from channel binding, we can make channel binding something
a client can do at its discretion. In this case, it wants to bind a
channel for this particular peer.

So, it sends a ChannelBind transaction, on the turn channel (channel 0).
The client requests channel 7 for communications to and from the peer.
At this point, the client is prepared to receive data on channel 7. In
ekr's proposed flow, there is a single channel number for traffic both
to and from a particular peer. When the server receives the ChannelBind,
it creates channel 7 and maps it to the peer. From this point forward,
the server will relay traffic from that peer, towards the client, over
channel 7. Furthermore, it will accept traffic from the client, on
channel 7, and forward to the peer. Note that, even though the client
has not received the response to the ChannelBind request, the server is
guaranteed that the client is prepared to receive data on channel 7.

However, the client doesn't want to wait for the ChannelBind response to
send the data. Until it gets that response, it cannot send data over
that channel. So, until then, it sends data encapsulated using the Send
indication (message 4). When the server receives this, it relays the
data to the peer (message 5) and opens a permission to the corresponding
IP address (the folks in the room last night were unsure if ChannelBind
also creates a permission, with opinion slightly in favor of no).

Now, at some point the ChannelBind response is received by the client
(message 6). After that point, the client can now send data to this peer
unencapsulated, on the bound channel. So, it uses channel 7 (message 7)
and the TURN server relays data to the peer (message 8).

Now, the peer sends data towards the TURN server (message 9). In this
particular case, a channel has already been bound to this peer on the
TURN server. So, the TURN server sends the data to the client on the
existing channel (message 10). Another peer (for example), with the same
IP address but from a different port, now sends data to the TURN server
(message 11). Since a permission is open for this IP address, the TURN
server will relay the data to the client. However, there is no channel
bound for this peer. As a consequence, the server encapsulates the data
in a Data indication (message 12). Note that, the server itself does NOT
try to bind a channel. Only the client can do that.

Instead, the client, upon receiving the data, decides it would like a
channel for this second peer. So, it sends a ChannelBind (message 13)
for this new peer. This is received by the TURN server and it binds
channel 8 to this peer, and sends the response (message 14). Now, when
the next datagram arrives from this new peer (message 15), it is sent to
the client unencapsulated on channel 8 (message 16).

In comparing this technique (Ekrs Technique) with the one in
draft-ietf-behave-turn-05 (Current Technique), we came up with the
following pros and cons:

Ekrs Technique
--------------

PRO: Allows the client to decide, on a case by case basis, whether to
pay the overhead (ChannelBind transaction) to bind a channel to a peer.
For example, in ICE exchanges, the client could skip channel binding for
the connectivity checks, and only do the binding if ICE selects the peer
 transport address.

PRO: Related to the previous point, the current channel binding
mechanism does not allow a client to remove or delete a channel binding.
Thus, for an allocation which is very long lived, the client could
eventually run out of channels and need to re-allocate to clear them all
or get more channels. Since Ekrs Technique allows the client to
selectively channel bind, when used with protocols like ICE where it is
not needed to channel bind for all peers, the allocation will 'last
longer' - that is, channel numbers get exhausted more slowly.
Architecturally, this is because Ekrs Technique separates channel
binding and data transmission, whereas the Current Technique combines them.

CON: Under packet loss, it is possible that the ChannelBind request
could be lost. If so, it will be retransmitted an RTO later. This means
that, the amount of time between request and response is equal to RTT +
2^N * RTO, where N is the number of packet losses. The client cannot
send unencapsulated data until the ChannelBind response is received.
This duration is therefore equal to RTT+ 2^N*RTO, which is longer than
the Current Technique. There was split opinions on whether this was a
big deal or not, but it is a CON.

PRO: Seems simpler to have a single channel number for messages in both
directions

PRO: If a channel binding is in place for a peer, the first data from
that peer can be sent immediatley unencapsulated. With the Current
Technique, since channel numbers are always different in each direction,
the first packet (and indeed, the first RTT set of packets after the
first) will be sent encapsulated.

PRO: there is a documented security concern with the Current Technique
in TURN-5. Since ChannelConfirm is an indication, it is unauthenticated.
An attacker could, upon seeing a Send indication from a client, send a
faked ChannelConfirm indication, and then cause the Send request to be
discarded. As a consequence, the client will believe the channel is
bound, when it is not. The client will, for the remaining duration of
the allocation, send data on that channel, and it will be discarded by
the TURN server. The client will not know that this happened. With Ekrs
Technique, this attack is mitigated.

PRO: Does not require the client to receive requests and send responses.
There has been some debate on whether this is important. Note that this
PRO is shared by both techniques.

PRO: A client could, as a matter of local implementation choice, elect
to not implement or use Send. Instead, it can wait for channels to be
bound and send data unencapsulated. This does mean that clients would
either drop data to be send prior to receiving the ChannelBind response,
else delay sending to that time.



Current Technique
-----------------

CON: Each Send indication (and Data indication) causes a ChannelConfirm
indication. If the client is sending a lot of data, say, at rate R, this
will cause R*RTT number of ChannelConfirm messages to be sent. In
essence, the server 'spams' the client will redundant ChannelConfirm
messages, even when there was no packet loss.

PRO: The amount of time until a client can sent unencapsulated data is
equal to RTT + T*N, where N is the number of packet losses and T is the
inter-arrival time between data from client to the peer. This number
will typically be lower than Ekrs Technique under conditions of packet
loss. Note that they are identical in conditions of no packet loss.

PRO: In the case of TCP between client and server, the server can omit
sending ChannelConfirm and the client can send data unencapsulated
immediately. With Ekrs technique, the client can also send data
unencapsulated immediately, but since ChannelBind is a transaction, a
response is still required.

PRO: Does not require the client to receive requests and send responses.
There has been some debate on whether this is important. Note that this
PRO is shared by both techniques.




Of the folks present, most (including myself) were in favor of Ekrs
Technique. Consequently, we'd like to confirm this decision, and see if
there is rough consensus to go with Ekrs technique.


Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
jdrosen@cisco.com
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com


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

------=_Part_18621_22254323.1197344115569-- --===============0145829978== 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 --===============0145829978==-- From behave-bounces@ietf.org Mon Dec 10 22:47:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1w5t-0004UG-LC; Mon, 10 Dec 2007 22:47:41 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J1w5s-0004UB-Aq for behave-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 22:47:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1w5s-0004U3-0T for behave@ietf.org; Mon, 10 Dec 2007 22:47:40 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1w5r-0000iU-Jd for behave@ietf.org; Mon, 10 Dec 2007 22:47:39 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 758AE33C53; Mon, 10 Dec 2007 19:42:15 -0800 (PST) Date: Mon, 10 Dec 2007 19:42:15 -0800 From: Eric Rescorla To: Jonathan Rosenberg Subject: Re: [BEHAVE] TURN Issue #7: Framing header length In-Reply-To: <4759D32F.8010304@cisco.com> References: <4759D32F.8010304@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071211034216.758AE33C53@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org At Fri, 07 Dec 2007 18:11:43 -0500, Jonathan Rosenberg wrote: > > This was not in my slides. It was raised at the mike at the WG session, > discussed briefly at the WG meeting and again briefly at the end of the > ad-hoc. > > The current TURN framing header looks like: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Channel | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > When TURN is running over UDP, the length header is redundant. The > current spec says to set it to zero. The issue was raised that, it would > be better to set it to to be the correct length, rather than zero. The > drawback of setting it to the correct length, is it introduces an error > condition. What happens if it doesn't match the actual UDP length? Do we > truncate (assuming the actual UDP packet size is larger than the TURN > header message length)? Or just discard? > > The point raised at the ad-hoc later, was that even if you set it to > zero, you still have the error condition, what if its not zero. It was > also pointed out, by setting the length we get the framing header > consistent between UDP and TCP. > > So there was rough agreement at the ad-hoc, to change turn so that the > message length is the actual message length, even over UDP. If it > mismatches the actual UDP message length, then the packet MUST be > discarded in error. > > Please comment as to whether you agree (or disagree) with this conclusion. I agree with this conclusion. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 10 22:48:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1w6k-0004jB-Fi; Mon, 10 Dec 2007 22:48:34 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J1w6j-0004j1-5G for behave-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 22:48:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1w6i-0004it-QY for behave@ietf.org; Mon, 10 Dec 2007 22:48:32 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1w6i-0000jp-67 for behave@ietf.org; Mon, 10 Dec 2007 22:48:32 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id BC2F933C61; Mon, 10 Dec 2007 19:43:09 -0800 (PST) Date: Mon, 10 Dec 2007 19:43:09 -0800 From: Eric Rescorla To: Jonathan Rosenberg Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages In-Reply-To: <4759D19B.50005@cisco.com> References: <4759D19B.50005@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071211034309.BC2F933C61@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org At Fri, 07 Dec 2007 18:04:59 -0500, Jonathan Rosenberg wrote: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0| STUN Message Type | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Magic Cookie | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Transaction ID (96 bits) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > and the proposed framing header: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Channel | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > So an alternative design is to make the framing header look like: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| Channel | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > So that there are 15 bits of channel instead of 16. Placing a 1 in that > position makes the framing header always a non-match for STUN messages. > Thus, it would not be even needed to do the more complex matching > operations defined in STUN; a 1-bit check would do the job to separate > out application data from STUN/TURN. > > The benefits of this change would be: > > 1. We would, once again, be able to run STUN and TURN on the same > port on the server. As of turn-05 they MUST run on different ports > because the framing header was unique to TURN. This could be a feature > or a bug depending on your perspective: > > FEATURE: TURN and STUN are actually very different; using > separate ports would allow a firewall to block one and not the other. > > BUG: practically speaking separate ports doesnt help since > with DNS the ports can be dynamic anyway. In addition, its always good > to use fewer ports on a server. Also its weird that an extension to a > protocol would run on a different port; that kind of tells you its not > an extension. > > 2. Reduces the size of TURN messages by 4 bytes. This is a minor > benefit and the real one is having a single port. > > 3. it'd be a little clearer to explain to people that TURN is an > extension to STUN, rather than saying, TURN is a STUN extension that is > run over a new framing header > > The drawbacks of this change would be: > > 1. cuts the number of channels in half > > > An alternative design would be to use the full 16 bits for channel > numbers, and then rely on the full suite of STUN differentiation > techniques to demux. However, my preference in general is to not do that > when its not actually needed. It complicates message processing and I > don't think its worth it. 32767 channels is also a LOT for our > envisioned use cases. > > This was somewhat inconclusive at the microphone. I'm personally on the > fence and don't feel that strongly. I probably midly prefer making this > change. > > Please comment on whether you prefer this change or not. I'm EKR and I approve of this change. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 10 22:49:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1w7H-0004pc-51; Mon, 10 Dec 2007 22:49:07 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J1w7F-0004pW-QG for behave-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 22:49:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1w7F-0004pO-GX for behave@ietf.org; Mon, 10 Dec 2007 22:49:05 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1w7E-0004xr-2S for behave@ietf.org; Mon, 10 Dec 2007 22:49:05 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id B5D8733C61; Mon, 10 Dec 2007 19:43:41 -0800 (PST) Date: Mon, 10 Dec 2007 19:43:41 -0800 From: Eric Rescorla To: Jonathan Rosenberg Subject: Re: [BEHAVE] TURN Issue #8: Managing permission lifetimes In-Reply-To: <4759D5A4.4090304@cisco.com> References: <4759D5A4.4090304@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071211034341.B5D8733C61@delta.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org At Fri, 07 Dec 2007 18:22:12 -0500, Jonathan Rosenberg wrote: > > This issue was not in my slides. It was raised at the mike in the WG > meeting, and was not discussed further at the ad-hoc. > > The issue is this. In TURN-05 (and for several versions prior), > allocations have an expiration and are refreshed explicitly by TURN > signaling. However, permissions are refreshed by data traffic, and there > is NO way to explicitly ask for a longer permission. Ekr pointed out > that, we had a SAFE BoF at this IETF which was trying to address the > problem that we didn't have an explicit way to manage the binding > lifetimes on the NAT. So, since a TURN server is basically a > remote-controlled NAT, isn't it silly to design it outright in a way > that is known to be broken? > > The counter-argument that was made, is that you need to send the data > traffic anyway to refresh the bindings between the client and the NAT. > However, if there are multiple peers connected through the allocation, > it would be possible to send a single data keepalive just to keepalive > the connection from client to TURN server, instead of sending data > keepalives for each peer. This is true only if there are no NATs between > the TURN server and the peers. It was pointed out that there are real > use cases for that, including enterprise deployments and p2psip. > > It was further pointed out that, if SAFE moves forward, at that time we > could add extensions to turn to manage the permission lifetimes. Indeed, > if SAFE uses STUN, it might even be the case that we could re-use that > very extension, but just send it to the TURN server instead of the NAT. > That would be really neat. > > Consequently, my sense from the meeting was that there was rough > agreement to leave this alone, and not try to add support in TURN for > explicitly requesting longer permission lifetimes. I think this is the > right thing. > > Please comment if you agree (or don't) with this. I'm fine with this. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 11 15:37:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2BrS-0005Ot-4T; Tue, 11 Dec 2007 15:37:50 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2BrR-0005Oo-Gi for behave-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 15:37:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2BrQ-0005Og-RB for behave@ietf.org; Tue, 11 Dec 2007 15:37:48 -0500 Received: from drew.ipv6.franken.de ([2001:638:a02:a001:20e:cff:fe4a:feaa] helo=mail-n.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2BrK-0001Hy-O7 for behave@ietf.org; Tue, 11 Dec 2007 15:37:48 -0500 Received: from [192.168.1.15] (p508FC41E.dip.t-dialin.net [80.143.196.30]) by mail-n.franken.de (Postfix) with ESMTP id 151728021904; Tue, 11 Dec 2007 21:37:40 +0100 (CET) (KNF-authenticated sender: micmac) Message-Id: <83813A31-FE27-4446-87C8-003739929A74@lurchi.franken.de> From: Michael Tuexen To: Dan Wing In-Reply-To: <0dd501c83b79$40902810$8f76150a@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [BEHAVE] Re: SCTP over NAT and hole-punching? Date: Tue, 11 Dec 2007 21:37:39 +0100 References: <7B55F180-CCEF-447E-97EB-A0F584E5B12C@mit.edu><36050A33-B215-497D-9671-67F62DAEE45F@lurchi.franken.de><54A85AEA-CEA3-49B6-AD48-3B848DD3D1BD@mit.edu> <2CAB9B0C-5CD3-4B38-835E-769D05031E71@lurchi.franken.de> <0dd501c83b79$40902810$8f76150a@cisco.com> X-Mailer: Apple Mail (2.915) X-Spam-Score: 2.2 (++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 'Bryan Ford' , 'IETF BEHAVE WG' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi Dan, negotiating the Vtag is not possible... It is randomly selected when sending the INIT or INIT-ACK. I would just make an entry (src IP, dst, IP, src port, dst port, 0) in the table and would match the INIT-ACK. This will not work, if two hosts between one NAT chose the same port number and want to talk to the same peer... So the case to consider is that you have N users behind a NAT wanting to talk to M users behind another NAT using the peer to peer setup. What would you expect for N and M? There is a probability that the port is already taken, but for small N or M it is small. I would just accept this. But it depends on N and M.... Best regards Michael On Dec 10, 2007, at 11:08 PM, Dan Wing wrote: >> To be clear: It will be possible to setup a peer to peer association >> if both ends know the addresses and ports used by the other. > > Won't you need to also communicate the VTAG? With UDP and TCP, > where NAPT is often performed, the NAPT device ensures there > is no port collision (by remapping port numbers). With your > approach with SCTP, you don't want the NAT to change port > numbers and only rely on the uniqueness of randomly-chosen > port numbers to prevent a collision. It seems that when port > numbers do collide, you'll want to provide the NAT with the > VTAG so it can differentiate the various hosts behind the NAT > that happened to choose the same port number. > > -d > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 11 16:18:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2CUm-0002qy-K9; Tue, 11 Dec 2007 16:18:28 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2CUl-0002qi-9t for behave-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 16:18:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2CUk-0002ov-Uj for behave@ietf.org; Tue, 11 Dec 2007 16:18:27 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2CUk-0000fp-HW for behave@ietf.org; Tue, 11 Dec 2007 16:18:26 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 11 Dec 2007 13:18:24 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBBLIO7j030467; Tue, 11 Dec 2007 13:18:24 -0800 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBBLIOCD029094; Tue, 11 Dec 2007 21:18:24 GMT From: "Dan Wing" To: "'Michael Tuexen'" References: <7B55F180-CCEF-447E-97EB-A0F584E5B12C@mit.edu><36050A33-B215-497D-9671-67F62DAEE45F@lurchi.franken.de><54A85AEA-CEA3-49B6-AD48-3B848DD3D1BD@mit.edu> <2CAB9B0C-5CD3-4B38-835E-769D05031E71@lurchi.franken.de> <0dd501c83b79$40902810$8f76150a@cisco.com> <83813A31-FE27-4446-87C8-003739929A74@lurchi.franken.de> Subject: RE: [BEHAVE] Re: SCTP over NAT and hole-punching? Date: Tue, 11 Dec 2007 13:18:23 -0800 Message-ID: <0caa01c83c3b$5d6498f0$c6f0200a@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: Acg8NbZUWUp6YcjBQuG2q4Vkzq0EkgABY/DA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <83813A31-FE27-4446-87C8-003739929A74@lurchi.franken.de> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1994; t=1197407904; x=1198271904; 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]=20Re=3A=20SCTP=20over=20NAT=20 and=20hole-punching? |Sender:=20; bh=WmET4D66hDlraI7gGtmKtNhfKfBxqLDyYyVR6WTIdFQ=; b=auCV0m+VLDMu3LxRWyKDfM0tuAuLIq/w3XbrwUQJFRTtPbHBy74ZVWVUgl AxpkLEcmM9rSOgsHAp38mLPDEy32xK5S9qru8YEP8wySZhunvsZu9yGhElpP s1FNQKUyXrX/NF60tMUyhF1at8BZThNmSggCSrbvVjpNzPjUera3M=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: 'Bryan Ford' , 'IETF 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 > -----Original Message----- > From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] > Sent: Tuesday, December 11, 2007 12:38 PM > To: Dan Wing > Cc: 'IETF BEHAVE WG'; 'Bryan Ford' > Subject: Re: [BEHAVE] Re: SCTP over NAT and hole-punching? > > Hi Dan, > > negotiating the Vtag is not possible... It is randomly selected when > sending > the INIT or INIT-ACK. > > I would just make an entry (src IP, dst, IP, src port, dst port, 0) > in the table and would match the INIT-ACK. > > This will not work, if two hosts between one NAT chose the same port > number and want to talk to the same peer... > > So the case to consider is that you have N users behind a NAT wanting > to talk to M users behind another NAT using the peer to peer setup. > What would you expect for N and M? There is a probability that the > port is already taken, but for small N or M it is small. I would just > accept this. But it depends on N and M.... So -- the question is how successful and widely-deployed will SCTP become where both endpoints are behind NATs? How successful do you want that scenario to become? -d > Best regards > Michael > > > > On Dec 10, 2007, at 11:08 PM, Dan Wing wrote: > > >> To be clear: It will be possible to setup a peer to peer > association > >> if both ends know the addresses and ports used by the other. > > > > Won't you need to also communicate the VTAG? With UDP and TCP, > > where NAPT is often performed, the NAPT device ensures there > > is no port collision (by remapping port numbers). With your > > approach with SCTP, you don't want the NAT to change port > > numbers and only rely on the uniqueness of randomly-chosen > > port numbers to prevent a collision. It seems that when port > > numbers do collide, you'll want to provide the NAT with the > > VTAG so it can differentiate the various hosts behind the NAT > > that happened to choose the same port number. > > > > -d > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 11 19:49:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Fn1-0004RS-1j; Tue, 11 Dec 2007 19:49:31 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2Fmz-0004QZ-Vi for behave-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 19:49:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Fmz-0004QR-M6 for behave@ietf.org; Tue, 11 Dec 2007 19:49:29 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Fmz-0007l2-39 for behave@ietf.org; Tue, 11 Dec 2007 19:49:29 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-2.cisco.com with ESMTP; 11 Dec 2007 16:49:28 -0800 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 lBC0nSTk025933; Tue, 11 Dec 2007 16:49:28 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id lBC0nRmu004838; Wed, 12 Dec 2007 00:49:28 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 16:49:27 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 16:49:27 -0800 Message-ID: <475F2FA3.8040800@cisco.com> Date: Tue, 11 Dec 2007 19:47:31 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bryan Ford References: <7B55F180-CCEF-447E-97EB-A0F584E5B12C@mit.edu> <36050A33-B215-497D-9671-67F62DAEE45F@lurchi.franken.de> <54A85AEA-CEA3-49B6-AD48-3B848DD3D1BD@mit.edu> <2CAB9B0C-5CD3-4B38-835E-769D05031E71@lurchi.franken.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Dec 2007 00:49:27.0299 (UTC) FILETIME=[D8D9A530:01C83C58] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=346; t=1197420568; x=1198284568; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20SCTP=20over=20NAT=20and=20hole-punching ? |Sender:=20; bh=ALHcSc704fTCvbQuav/mHcXLeRcp6gWxXj8jaa9BGIo=; b=B5k7DlmnaSbx25xwcckzORFHESv3OPzGb/E4o7yPDPTzGgOIrwrmmQh0d8 EZ02RIokmsBk+PJvqd8iWrGRMZDc3S2BxKpnQo5EkNjfBIS4cn0jYAf46GTf iLTXB8zKBD; Authentication-Results: sj-dkim-6; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Michael Tuexen , IETF BEHAVE WG Subject: [BEHAVE] Re: SCTP over NAT and hole-punching? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Bryan Ford wrote: > Ah - OK, that all sounds great; I wasn't aware of the INIT collision > extension (i.e., didn't do my homework well enough I guess :) ). > > Its not an extension.. check out chapter 5 (if I remember right) of RFC4960.. R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Dec 12 02:33:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2M5c-0004fv-WB; Wed, 12 Dec 2007 02:33:09 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2M5b-0004fp-87 for behave-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 02:33:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2M5a-0004fg-GN for behave@ietf.org; Wed, 12 Dec 2007 02:33:06 -0500 Received: from drew.ipv6.franken.de ([2001:638:a02:a001:20e:cff:fe4a:feaa] helo=mail-n.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2M5Z-0007tg-U0 for behave@ietf.org; Wed, 12 Dec 2007 02:33:06 -0500 Received: from [192.168.1.17] (p508FC41E.dip.t-dialin.net [80.143.196.30]) by mail-n.franken.de (Postfix) with ESMTP id 4E8B8801AC03; Wed, 12 Dec 2007 08:33:02 +0100 (CET) (KNF-authenticated sender: macmic) In-Reply-To: <0caa01c83c3b$5d6498f0$c6f0200a@cisco.com> References: <7B55F180-CCEF-447E-97EB-A0F584E5B12C@mit.edu><36050A33-B215-497D-9671-67F62DAEE45F@lurchi.franken.de><54A85AEA-CEA3-49B6-AD48-3B848DD3D1BD@mit.edu> <2CAB9B0C-5CD3-4B38-835E-769D05031E71@lurchi.franken.de> <0dd501c83b79$40902810$8f76150a@cisco.com> <83813A31-FE27-4446-87C8-003739929A74@lurchi.franken.de> <0caa01c83c3b$5d6498f0$c6f0200a@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [BEHAVE] Re: SCTP over NAT and hole-punching? Date: Wed, 12 Dec 2007 08:33:01 +0100 To: Dan Wing X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 2.2 (++) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: 'Bryan Ford' , 'IETF BEHAVE WG' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi Dan, what I forgot: After the peer to peer association has been established, the Vtags are known and the entry with the 0-Vtag is removed. So it it no problem to handle port number collisions. One is limited only during the period of time where the INIT is sent and the association is not set up. Let me think about what can be done if - multiple end-points which have chosen the same port number - want to talk to the same peer - and setup all association at about the same time Maybe the NAT can just delay the processing of the INITs which is not the first one... Best regards Michael On Dec 11, 2007, at 10:18 PM, Dan Wing wrote: > > >> -----Original Message----- >> From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] >> Sent: Tuesday, December 11, 2007 12:38 PM >> To: Dan Wing >> Cc: 'IETF BEHAVE WG'; 'Bryan Ford' >> Subject: Re: [BEHAVE] Re: SCTP over NAT and hole-punching? >> >> Hi Dan, >> >> negotiating the Vtag is not possible... It is randomly selected when >> sending >> the INIT or INIT-ACK. >> >> I would just make an entry (src IP, dst, IP, src port, dst port, 0) >> in the table and would match the INIT-ACK. >> >> This will not work, if two hosts between one NAT chose the same port >> number and want to talk to the same peer... >> >> So the case to consider is that you have N users behind a NAT wanting >> to talk to M users behind another NAT using the peer to peer setup. >> What would you expect for N and M? There is a probability that the >> port is already taken, but for small N or M it is small. I would just >> accept this. But it depends on N and M.... > > So -- the question is how successful and widely-deployed will SCTP > become where both endpoints are behind NATs? > > How successful do you want that scenario to become? > > -d > > >> Best regards >> Michael >> >> >> >> On Dec 10, 2007, at 11:08 PM, Dan Wing wrote: >> >>>> To be clear: It will be possible to setup a peer to peer >> association >>>> if both ends know the addresses and ports used by the other. >>> >>> Won't you need to also communicate the VTAG? With UDP and TCP, >>> where NAPT is often performed, the NAPT device ensures there >>> is no port collision (by remapping port numbers). With your >>> approach with SCTP, you don't want the NAT to change port >>> numbers and only rely on the uniqueness of randomly-chosen >>> port numbers to prevent a collision. It seems that when port >>> numbers do collide, you'll want to provide the NAT with the >>> VTAG so it can differentiate the various hosts behind the NAT >>> that happened to choose the same port number. >>> >>> -d >>> > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Dec 12 08:37:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2RmS-0001J0-AF; Wed, 12 Dec 2007 08:37:44 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2RmQ-0001It-S2 for behave-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 08:37:42 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2RmQ-0001Il-IZ for behave@ietf.org; Wed, 12 Dec 2007 08:37:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Rdl-00056c-Uj for behave@ietf.org; Wed, 12 Dec 2007 08:28:45 -0500 Received: from wa-out-1112.google.com ([209.85.146.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Rdk-0001h9-UD for behave@ietf.org; Wed, 12 Dec 2007 08:28:45 -0500 Received: by wa-out-1112.google.com with SMTP id k40so532056wah.25 for ; Wed, 12 Dec 2007 05:28:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=ex0Xi9/wsOm76AJenDiRmDxw/cGfkFBznqxtTT02FvE=; b=rRMLQ4rLDGZgcS3ZKMnkiOGYzIhFzamN5D3jfDNXO6cPyJ801KwnzUL01gBkLkQI0lFnz3VvYgtEDlqNrv/jnufw+Xb+NB3HtqBCe6wUtTAAJ+/byYANJ2AUWAqa7EB1mlOElBcFTXZk5C9QKV31pYVDGoG4w4lPIqPF106Mxoo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=EVtCgdXkzNc7HmzobwXTeaqe3SZhUVSjCKEoxghRztWuMuYD3uR3p1pFvz5R3uxVg2aUxldvufMtVCtMf3bUaWGqQgJFGCGqCEMDlgmI/QxGHmGbva9th9heffcxMoD6X2PhbGy0uizeNfRvg0TO7UgcwMJudbJ/8jvb+ma5ZLU= Received: by 10.114.184.7 with SMTP id h7mr788379waf.28.1197466124441; Wed, 12 Dec 2007 05:28:44 -0800 (PST) Received: by 10.114.177.20 with HTTP; Wed, 12 Dec 2007 05:28:44 -0800 (PST) Message-ID: Date: Wed, 12 Dec 2007 18:58:44 +0530 From: "Sourav Chakraborty" To: behave@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-TMDA-Confirmed: Wed, 12 Dec 2007 08:37:42 -0500 Subject: [BEHAVE] TURN draft queries X-BeenThere: behave@ietf.org X-Mailman-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="===============0789912253==" Errors-To: behave-bounces@ietf.org --===============0789912253== Content-Type: multipart/alternative; boundary="----=_Part_31310_17697717.1197466124418" ------=_Part_31310_17697717.1197466124418 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Everybody, Here are some queries that we have regarding TURN.Please clarify them at the earliest-- As far as our understanding goes(according to draft-ietf-behave-turn-03),there are 3 Timers to be implemented,alongwith the actions taken at server and client-- 1>Lifetime timer(turn-03: section 10.3) Server: Destroy allocation on expiry Client: Re send Allocate request on expiry of 3/4th of the time 2>Keepalive timer(turn-03: section 4.3) Client: What is the timer value? What message is sent on expiry? Server: No action 3>Permission inactivity timer(turn-03: section 10.3) Client: No action Server: Delete permission (How is the permission refreshed?) Also please clarify whether only STUN(not TURN) can be used as a solution for UDP media traffic transfer over SYMMETRIC NATs. --both endpoints behind symmetric NATs TURN will be required.Only STUN is not enough --one endpoint behind symmetric NAT,other endpoint in public domain Not sure.Please clarify?? Please let us know if our understanding is correct alongwith answers to the questions. Thanks in advance Regards Sourav ------=_Part_31310_17697717.1197466124418 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 
Hi Everybody,

Here are some queries that we have regarding TURN.Please clarify them at the
earliest--

As far as our understanding goes(according to
draft-ietf-behave-turn-03),there are 3 Timers to be implemented,alongwith

the actions taken at server and client--
1>Lifetime timer(turn-03: section 10.3)
            Server: Destroy allocation on expiry
            Client: Re send Allocate request on expiry of 3/4th of the time

2>Keepalive timer(turn-03: section 4.3)
            Client: What is the timer value? What message is sent on expiry?
            Server: No action
3>Permission inactivity timer(turn-03: section 10.3)

            Client: No action
            Server: Delete permission (How is the permission refreshed?)

Also please clarify whether only STUN(not TURN) can be used as a solution for UDP media traffic
transfer over SYMMETRIC NATs.

--both endpoints behind symmetric NATs                                TURN will be required.Only STUN is not enough
--one endpoint behind symmetric NAT,other endpoint in public domain   Not sure.Please clarify??


Please let us know if our understanding is correct alongwith answers to the
questions.
Thanks in advance
Regards
Sourav
------=_Part_31310_17697717.1197466124418-- --===============0789912253== 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 --===============0789912253==-- From behave-bounces@ietf.org Wed Dec 12 08:40:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2RpT-0003Am-6B; Wed, 12 Dec 2007 08:40:51 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2RpR-00033t-Mk for behave-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 08:40:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2RpR-000326-Bq for behave@ietf.org; Wed, 12 Dec 2007 08:40:49 -0500 Received: from wa-out-1112.google.com ([209.85.146.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2RpQ-0002Cg-SU for behave@ietf.org; Wed, 12 Dec 2007 08:40:49 -0500 Received: by wa-out-1112.google.com with SMTP id k40so539094wah.25 for ; Wed, 12 Dec 2007 05:40:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=4JBHd9vAaWyG7Yd1JoCXJhU0I9prbLfgdJIi2eHdfEk=; b=Gy/d447+ABaJ7t8K3OEMwJKQ826KVh1TD5nRdplsMJRVslfuHw2ULxHMH9WmPV4KnnhsfgEG7UPhMZrFHH/1XQMqp3GAG9KDrTSnJpPTKhvMAl5JXGCagHbh9g2LgVOXGMspsMlNfO+sHwSGuk8lUDYTfK0Yp/dm2oWv5UyqXmg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=pB/0uNNEbBJ+ObwFL7oiwF65Poy5AsJoOBxj26D5VxaK3VJBKTtuWqjkZQ8I2dufZYjzb62KxUQnIaZ5oPe3EIYVp57WsEFkX4JzaEhnh0SDeQFEcx3A98eiNqgILTa9fp2kFzycqzftYxxPtaqS/5UbzlTJApcJsl9aN6WI1jQ= Received: by 10.115.90.1 with SMTP id s1mr788645wal.50.1197466847838; Wed, 12 Dec 2007 05:40:47 -0800 (PST) Received: by 10.114.177.20 with HTTP; Wed, 12 Dec 2007 05:40:47 -0800 (PST) Message-ID: Date: Wed, 12 Dec 2007 19:10:47 +0530 From: "Sourav Chakraborty" To: behave@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [BEHAVE] TURN draft queries X-BeenThere: behave@ietf.org X-Mailman-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="===============0501098027==" Errors-To: behave-bounces@ietf.org --===============0501098027== Content-Type: multipart/alternative; boundary="----=_Part_31342_7782643.1197466847827" ------=_Part_31342_7782643.1197466847827 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Everybody, Here are some queries that we have regarding TURN.Please clarify them at the earliest-- As far as our understanding goes(according to draft-ietf-behave-turn-03),there are 3 Timers to be implemented,alongwith the actions taken at server and client-- 1>Lifetime timer(turn-03: section 10.3) Server: Destroy allocation on expiry Client: Re send Allocate request on expiry of 3/4th of the time 2>Keepalive timer(turn-03: section 4.3) Client: What is the timer value? What message is sent on expiry? Server: No action 3>Permission inactivity timer(turn-03: section 10.3) Client: No action Server: Delete permission (How is the permission refreshed?) Also please clarify whether only STUN(not TURN) can be used as a solution for UDP media traffic transfer over SYMMETRIC NATs. --both endpoints behind symmetric NATs TURN will be required.Only STUN is not enough --one endpoint behind symmetric NAT,other endpoint in public domain Not sure.Please clarify?? Please let us know if our understanding is correct alongwith answers to the questions. Thanks in advance Regards Sourav ------=_Part_31342_7782643.1197466847827 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 
Hi Everybody,

Here are some queries that we have regarding TURN.Please clarify them at the
earliest--

As far as our understanding goes(according to
draft-ietf-behave-turn-03),there are 3 Timers to be implemented,alongwith


the actions taken at server and client--
1>Lifetime timer(turn-03: section 10.3)
            Server: Destroy allocation on expiry
            Client: Re send Allocate request on expiry of 3/4th of the time


2>Keepalive timer(turn-03: section 4.3)
            Client: What is the timer value? What message is sent on expiry?
            Server: No action
3>Permission inactivity timer(turn-03: section 10.3
)

            Client: No action
            Server: Delete permission (How is the permission refreshed?)

Also please clarify whether only STUN(not TURN) can be used as a solution for UDP media traffic

transfer over SYMMETRIC NATs.

--both endpoints behind symmetric NATs                                TURN will be required.Only STUN is not enough
--one endpoint behind symmetric NAT,other endpoint in public domain   Not 
sure.Please clarify??


Please let us know if our understanding is correct alongwith answers to the
questions.
Thanks in advance
Regards
Sourav
------=_Part_31342_7782643.1197466847827-- --===============0501098027== 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 --===============0501098027==-- From behave-bounces@ietf.org Wed Dec 12 14:57:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Xhe-00051Y-M3; Wed, 12 Dec 2007 14:57:10 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2Xhc-00051R-Cy for behave-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 14:57:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Xhc-00051J-2J for behave@ietf.org; Wed, 12 Dec 2007 14:57:08 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-05.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Xha-0008UD-LF for behave@ietf.org; Wed, 12 Dec 2007 14:57:08 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J2Xgz-0003NW-1L; Wed, 12 Dec 2007 14:56:29 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2FFD3B70-6F76-48F1-BA9D-609AAE943880@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN draft queries Date: Wed, 12 Dec 2007 14:57:02 -0500 To: Sourav Chakraborty X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 Sourav: We are in the middle of a major redesign of TURN. TURN-04 is significantly different than TURN-03. This is not because we like to change TURN, but because we are trying to finalize it as soon as possible, while addressing some old concerns. However, the points you list below are mostly applicable to TURN-04 as well. - Philip On 12-Dec-07, at 08:28 , Sourav Chakraborty wrote: > Hi Everybody, > > Here are some queries that we have regarding TURN.Please clarify > them at the > earliest-- > > As far as our understanding goes(according to > draft-ietf-behave-turn-03),there are 3 Timers to be > implemented,alongwith > > the actions taken at server and client-- > 1>Lifetime timer(turn-03: section 10.3) > Server: Destroy allocation on expiry > Client: Re send Allocate request on expiry of 3/4th of > the time > > 2>Keepalive timer(turn-03: section 4.3) > Client: What is the timer value? What message is sent > on expiry? > Server: No action > 3>Permission inactivity timer(turn-03: section 10.3) > > Client: No action > Server: Delete permission (How is the permission > refreshed?) > > Also please clarify whether only STUN(not TURN) can be used as a > solution for UDP media traffic > transfer over SYMMETRIC NATs. > > --both endpoints behind symmetric > NATs TURN will be required.Only STUN > is not enough > --one endpoint behind symmetric NAT,other endpoint in public > domain Not sure.Please clarify?? > > > Please let us know if our understanding is correct alongwith > answers to the > questions. > Thanks in advance > Regards > Sourav > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Dec 12 23:01:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2fGH-0005O4-IC; Wed, 12 Dec 2007 23:01:25 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2fGG-0005M7-Ch for behave-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 23:01:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2fGF-0005JZ-JV for behave@ietf.org; Wed, 12 Dec 2007 23:01:23 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2fGF-0006uX-45 for behave@ietf.org; Wed, 12 Dec 2007 23:01:23 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 12 Dec 2007 20:01:12 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBD41CLP003900 for ; Wed, 12 Dec 2007 20:01:12 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBD40q9P015000 for ; Thu, 13 Dec 2007 04:01:12 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 20:00:56 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 20:00:56 -0800 Message-ID: <4760AE9F.9030409@cisco.com> Date: Wed, 12 Dec 2007 23:01:35 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Dec 2007 04:00:56.0208 (UTC) FILETIME=[C32FC900:01C83D3C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1664; t=1197518472; x=1198382472; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Plan=20forward=20on=20TURN |Sender:=20; bh=caS/JLx/w/JN3l3zYReIDPV3Tnx+ToPUrd3MmU94aVc=; b=AHfpMiTDwBCCcSjLdo2QSz5Ny47POrA74nVL8HND7TYcHfEH485T4Rp0eF D/7+mzlZ6C5DSqd45sAdtQGf8If/HlbyleQABAPCEf+P+8CESQkv1+w4YXTa 66Fu5K4PXQPzHmldDG1OnqyHAOf+6DLXG+jhJmDfp011JwkzLn+O4=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [BEHAVE] Plan forward on TURN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org It is really important that we make rapid progress on TURN. In particular, I do NOT want to have another IETF meeting where we even discuss the document, let alone go through a design change at the meeting like happened in Vancouver. To accomplish that, I'd like to propose the following path forward on TURN: 1. we complete discussion on the open issues I posted on by December 19 2. we schedule a call for on or around December 20. On that call, we summarize the agreements and if there weren't agreements, discuss what remains open and conclude it. I'll send information on that call shortly; anyone may attend of course. 3. revised TURN based on those changes comes out shortly after the new year (say, Jan 8). 4. At the very least, folks that have been active participants please read the document within the two weeks following release of the new draft, and come back with comments by Jan 22. Hopefully those are minor given they all should have more or less agreed by now. 5. Assuming minor comments, 1-2 weeks after that a revised TURN draft comes out, say Feb 5, which goes to a 2-week WGLC ending Feb 19. Assuming only trivial comments at that point, a revised draft is out Feb 26, which goes to IESG. This is very aggressive, but is needed if we want to have this document done before Philadelphia. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Dec 12 23:09:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2fNx-0006Vi-8t; Wed, 12 Dec 2007 23:09:21 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2fNv-0006Vb-9n for behave-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 23:09:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2fNu-0006VT-Ux for behave@ietf.org; Wed, 12 Dec 2007 23:09:19 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2fNu-00074f-H7 for behave@ietf.org; Wed, 12 Dec 2007 23:09:18 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 12 Dec 2007 20:09:18 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lBD49Ieo020665; Wed, 12 Dec 2007 20:09:18 -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 lBD49H0i009607; Thu, 13 Dec 2007 04:09:17 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 20:09:17 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 20:09:17 -0800 Message-ID: <4760B094.7040800@cisco.com> Date: Wed, 12 Dec 2007 23:09:56 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Sourav Chakraborty Subject: Re: [BEHAVE] TURN draft queries References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Dec 2007 04:09:17.0643 (UTC) FILETIME=[EE10B1B0:01C83D3D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2085; t=1197518958; x=1198382958; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20draft=20queries |Sender:=20; bh=iZ37NfcJbp+WTXIiVADGSPHpTEFQeymyUZXnF5QNDPI=; b=JOUP88aKVkMjOA9Cnp3n3SCEN9LOK32SuBvY4i53npLVae0RpoZBWKnxwr qQlnB+xj2mdrI+6+AJZ4VnYStYHLA2/gGfiwJJQtN49QkOeXYGLjq0khBzCV dZMA2NJk5R; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 responses inline, against TURN-04: Sourav Chakraborty wrote: > Hi Everybody, > > Here are some queries that we have regarding TURN.Please clarify them at the > earliest-- > > As far as our understanding goes(according to > draft-ietf-behave-turn-03),there are 3 Timers to be implemented,alongwith > > > the actions taken at server and client-- > 1>Lifetime timer(turn-03: section 10.3) > Server: Destroy allocation on expiry > Client: Re send Allocate request on expiry of 3/4th of the time This timer is in TURN-04, yes. > > > 2>Keepalive timer(turn-03: section 4.3) > Client: What is the timer value? What message is sent on expiry? > Server: No action This is referring to the bindings on intervening NAT. The permission inactivity timer adddresses that, in addition to the TURN permissions. > 3>Permission inactivity timer(turn-03: section 10.3 > ) > > Client: No action > Server: Delete permission (How is the permission refreshed?) No. Client needs to send data to each peer to keep permissions open to that peer. > > Also please clarify whether only STUN(not TURN) can be used as a solution for UDP media traffic > > transfer over SYMMETRIC NATs. > > --both endpoints behind symmetric NATs TURN will be required.Only STUN is not enough > --one endpoint behind symmetric NAT,other endpoint in public domain Not > sure.Please clarify?? > FIrstly, STUN and TURN both are meant to be used with ICE. WHen ICE is in use, if both endpoints are behind symmetric NAT, ICE will end up with a single TURN server. If only one endpoint is behind symmetric NAT, ICE will not use the TURN server for that call. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Dec 12 23:13:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2fSH-00042f-H8; Wed, 12 Dec 2007 23:13:49 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2fSF-0003v3-US for behave-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 23:13:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2fSF-0003sL-Jo for behave@ietf.org; Wed, 12 Dec 2007 23:13:47 -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 1J2fSE-0005Eb-JV for behave@ietf.org; Wed, 12 Dec 2007 23:13:47 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 12 Dec 2007 20:13:45 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBD4Dkcw013602; Wed, 12 Dec 2007 20:13:46 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lBD4Dk0i012084; Thu, 13 Dec 2007 04:13:46 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 20:13:46 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 20:13:45 -0800 Message-ID: <4760B1A0.6080807@cisco.com> Date: Wed, 12 Dec 2007 23:14:24 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Derek MacDonald Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages References: <4759D19B.50005@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Dec 2007 04:13:45.0496 (UTC) FILETIME=[8DB7D180:01C83D3E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7435; t=1197519226; x=1198383226; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20Issue=20#6=3A=20Frami ng=20header=20for=20actual=20TURN=20messages |Sender:=20; bh=tf7x81hp551v9YO6ucQASbKBPd4YcRbvk7Q8OejpTHY=; b=igipguyi3WvqXxNIbhNuoyGZ5fdDM4ZEfWOWlIpi5k+lDS+Rb8mH1pUlcR /sE7mR2bGV0FVpybNBXuo8l/6Y8IJ5p8KMeDc4n+9YA8xjFAUVPBkTb4qo0k 69aXiSm696; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 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 32767 vs. 65535 is irrelevant for any SIP use cases we have to date. Where this is a potential issue, is the following. Lets say you are a client and go to your TURN server and get an ip address and port. You basically want to hold on to that IP address and port for a really long time. Think of it like a nailed up VPN. Sufficiently long that the client might want to publish its IP/port in DNS or something (obviously requiring SRV records). Now, the client can't run a server, but presuming some rendezvous mechanism, for each corresponding peer, it opens a permission, communicates with them, and then its done. Next day, a different peer, new permission created, etc. In that use case, the client will eventually burn through all 32767 channels, and obviously will do so in half the time it would if all 65535 were there. Now, I personally don't see this use case as being real, but I just wanted to point it out. -Jonathan R. Derek MacDonald wrote: > I like this change because it will simplify the implementation of a > client that uses both ICE/TURN as two modes of TURN/ICE packet writing > will no have to be supported. > > I do not believe the reduction in the total # of channels is relevant; > 32767 channels is half of the available port space, which is much more > than an endpoint would expect from a shared(enterprise) NAT. > > The TURN server will probably run out of tuples well before the client does. > > -Derek > > > On Dec 7, 2007 3:04 PM, Jonathan Rosenberg > wrote: > > This issue was not in my slides. It was brought up at the mike in the > WG, and was discussed there. It was not discussed further at the ad-hoc. > > As of turn-05, we introduced a framing mechanism, which is a 4 byte > header consisting of 2 bytes channel and 2-bytes length. This framing > header precedes ALL packets sent between a client and its TURN server, > including both application data and TURN messages themselves, which are > sent on channel zero. > > Ekr raised a question of why this header was needed for actual TURN > messages. After all, he argued, we went through all this trouble to make > STUN (and thus TURN) differentiatable from each other. Indeed, others > noted that the framing header itself looks very similar to the top 4 > bytes of the STUN message format anyway: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0| STUN Message Type | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Magic Cookie > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Transaction ID (96 bits) > | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > and the proposed framing header: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Channel | Message Length > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > So an alternative design is to make the framing header look like: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| Channel | Message Length > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > So that there are 15 bits of channel instead of 16. Placing a 1 in that > position makes the framing header always a non-match for STUN messages. > Thus, it would not be even needed to do the more complex matching > operations defined in STUN; a 1-bit check would do the job to separate > out application data from STUN/TURN. > > The benefits of this change would be: > > 1. We would, once again, be able to run STUN and TURN on the same > port on the server. As of turn-05 they MUST run on different ports > because the framing header was unique to TURN. This could be a feature > or a bug depending on your perspective: > > FEATURE: TURN and STUN are actually very different; using > separate ports would allow a firewall to block one and not the other. > > BUG: practically speaking separate ports doesnt help since > with DNS the ports can be dynamic anyway. In addition, its always good > to use fewer ports on a server. Also its weird that an extension to a > protocol would run on a different port; that kind of tells you its not > an extension. > > 2. Reduces the size of TURN messages by 4 bytes. This is a minor > benefit and the real one is having a single port. > > 3. it'd be a little clearer to explain to people that TURN is an > extension to STUN, rather than saying, TURN is a STUN extension that is > run over a new framing header > > The drawbacks of this change would be: > > 1. cuts the number of channels in half > > > An alternative design would be to use the full 16 bits for channel > numbers, and then rely on the full suite of STUN differentiation > techniques to demux. However, my preference in general is to not do that > when its not actually needed. It complicates message processing and I > don't think its worth it. 32767 channels is also a LOT for our > envisioned use cases. > > This was somewhat inconclusive at the microphone. I'm personally on the > fence and don't feel that strongly. I probably midly prefer making this > change. > > Please comment on whether you prefer this change or not. > > Thanks, > Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Dec 12 23:18:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2fWV-0006Vo-RA; Wed, 12 Dec 2007 23:18:11 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2fWU-0006Vi-HJ for behave-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 23:18:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2fWU-0006Va-7R for behave@ietf.org; Wed, 12 Dec 2007 23:18:10 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2fWR-0005Jf-JZ for behave@ietf.org; Wed, 12 Dec 2007 23:18:10 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 12 Dec 2007 20:18:07 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBD4I77M016474; Wed, 12 Dec 2007 20:18:07 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBD4I7CD005108; Thu, 13 Dec 2007 04:18:07 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 20:18:06 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 20:18:06 -0800 Message-ID: <4760B2A5.1010709@cisco.com> Date: Wed, 12 Dec 2007 23:18:45 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Derek MacDonald Subject: Re: [BEHAVE] Alternative channel binding mechanism for TURN References: <475998D7.8010903@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Dec 2007 04:18:06.0265 (UTC) FILETIME=[29260290:01C83D3F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=19254; t=1197519487; x=1198383487; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20Alternative=20channel=20bind ing=20mechanism=20for=20TURN |Sender:=20; bh=TpxpCvn+qtuPNyFKaLDep/fYnyPIpZrvnpwn9ViaI0w=; b=U2Nglc9votQtBh487ffLx2fhFXK88oPDMUHBuDz58h3qQGDhaO16H5b5x2 ZkBcaFcjfrbv3tWRdF0B21okj27DEnFLR9fBxwpVZ2jqbZwnCm5CBoc+H5Ha TAn61BsXo7; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 4fc59e88b356924367ae169e6a06365d 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 Derek, Great point on the client not knowing when the server ran out of channels. I had not considered this, and it is another benefit of Ekrs proposal. To address your points below, I don't believe we should say anything about treating encapsulated data as an indication of receipt of ChannelBind. If an implementation wants to do this on its own thats fine, but I don't want to put anything in the protocol around it. In terms of, what happens if the CHannelBind times out, this is a more general issue. What happens if Refresh times out? Same problem. I think we need to add text, as you describe, that says in all such cases the client considers the allocation invalidated, and it has to grab a new one. -Jonathan R. Derek MacDonald wrote: > I am in favour of the new technique because it avoids the following > issues(as well as the benefits described by Jonathan) > > * the packet rate is not double the media rate while the channel is > established. This would only likely be an issue when a call forks to > many endpoints, but might be more of an issue in a future application of > turn. > * With turn-05, there is a very weird edge case that could technically > occur. If the server or the client runs out of channel numbers the > allocation should be restarted. With turn-05, the client and the server > must keep track of both client and server channel #'s, as this will not > necessarily be symmetric. It will *likely* be, but it isn't > guaranteed. Unfortunately, if the server runs out(or is low) of > channels, there is no way to signal to the client that an new allocation > needs to be created. > > In any case, suspect most client implementations would not track server > channel #s...so if we can avoid it, we should. Another issue in turn-05 > is tat there is no recovery mechanism for when an allocation runs out of > channels in either mechanism. With ekr's mechanism, we can fall back to > allocated data with a little more overhead and no loss of function. > > That said, there are a couple of edge cases we need to consider if we > use the new mechanism, due to the lack of a 3-way handshake in the > ChannelBind transaction. > > 1. should we treat encapsulated data as an imlicit ACK of the relevant > ChannelBind? > 2. what should the client behavior be when the ChannelBind fails? > > Personally, I think #1 is fine, but it should be an optional > optimization for the client. The server has no way of knowing if a > BindOK response was received by the client. > > For, #2 I want to define ChannelBind failure as: the client did not > receive a ChannelBind response or(optionally) encapsulated data on the > channel > > At the ad-hoc, we thought that the client should treat the allocation as > dead. Dead is not particlarily well defined in this context, > specifically: should the client assume that data sent on other channels > is not being delivered? > > This could get quite complicated, so I propose the following client > behavior in this case: > > If a ChannelBind transaction fails, the turn client should invalidate > the allocation and apply the same application logic that would be used > when a NAT reboot/rebind is detected. > > This maps back to the general architectural scope of turn as a NAT > upgrade rather than a NAT replacement. > > -Derek > > On Dec 7, 2007 11:02 AM, Jonathan Rosenberg < jdrosen@cisco.com > > wrote: > > Several folks met last night at the TURN ad-hoc to discuss the various > open issues. One of the biggest was whether we should change the channel > binding mechanism from what is in the document (using Send along with a > confirmation indication) to what ekr suggested. We wrote down what that > alternate flow would look like and came up with pros and cons. Here is > what we came up with. > > The mechanism that ekr is proposing basically looks like this: > > Client TURN Server Peer Peer2 > | | | | > | | | | > | | | | > |(1) [0]Allocate | | | > |--------------->| | | > | | | | > | | | | > |(2) [0]AllocOK | | | > |<---------------| | | > | | | | > | | | | > |Data to send | | | > | | | | > | | | | > | | | | > |(3) [0]ChannelBind(7) | | > |--------------->| | | > | | | | > | | | | > |(4) [0]Send | | | > |--------------->| | | > | | | | > | | | | > | |(5) UDP Packet | | > | |--------------->| | > | | | | > | | | | > |(6) [0]BindOK | | | > |<---------------| | | > | | | | > | | | | > |(7) [7]UDP Packet | | > |--------------->| | | > | | | | > | | | | > | |(8) UDP Packet | | > | |--------------->| | > | | | | > | | | | > | |(9) UDP Packet | | > | |<---------------| | > | | | | > | | | | > |(10) [7]UDP Packet | | > |<---------------| | | > | | | | > | | | | > | |(11) UDP Packet | | > | |<--------------------------------| > | | | | > | | | | > | |Permission Open | | > | | | | > | | | | > | | | | > |(12) [0]Data Ind. | | > |<---------------| | | > | | | | > | | | | > |(13) [0]ChannelBind(8) | | > |--------------->| | | > | | | | > | | | | > |(14) [0]BindOK | | | > |<---------------| | | > | | | | > | | | | > | |(15) UDP Packet | | > | |<--------------------------------| > | | | | > | | | | > |(16) [8]UDP Packet | | > |<---------------| | | > | | | | > | | | | > | | | | > | | | | > > In terms of notation, the square brackets in front of a TURN message > indicate what channel that message is on. > > The client does the Allocate as currently defined (messages 1,2). > Shortly thereafter, the client has data to send. It knows that it will > have a bunch of data, so it would like to create a channel for > communications with the specific peer. One of the benefits of this > proposed flow (noted further below), is that by separating data > transmission from channel binding, we can make channel binding something > a client can do at its discretion. In this case, it wants to bind a > channel for this particular peer. > > So, it sends a ChannelBind transaction, on the turn channel (channel > 0). > The client requests channel 7 for communications to and from the peer. > At this point, the client is prepared to receive data on channel 7. In > ekr's proposed flow, there is a single channel number for traffic both > to and from a particular peer. When the server receives the ChannelBind, > it creates channel 7 and maps it to the peer. From this point forward, > the server will relay traffic from that peer, towards the client, over > channel 7. Furthermore, it will accept traffic from the client, on > channel 7, and forward to the peer. Note that, even though the client > has not received the response to the ChannelBind request, the server is > guaranteed that the client is prepared to receive data on channel 7. > > However, the client doesn't want to wait for the ChannelBind response to > send the data. Until it gets that response, it cannot send data over > that channel. So, until then, it sends data encapsulated using the Send > indication (message 4). When the server receives this, it relays the > data to the peer (message 5) and opens a permission to the > corresponding > IP address (the folks in the room last night were unsure if ChannelBind > also creates a permission, with opinion slightly in favor of no). > > Now, at some point the ChannelBind response is received by the client > (message 6). After that point, the client can now send data to this peer > unencapsulated, on the bound channel. So, it uses channel 7 (message 7) > and the TURN server relays data to the peer (message 8). > > Now, the peer sends data towards the TURN server (message 9). In this > particular case, a channel has already been bound to this peer on the > TURN server. So, the TURN server sends the data to the client on the > existing channel (message 10). Another peer (for example), with the > same > IP address but from a different port, now sends data to the TURN server > (message 11). Since a permission is open for this IP address, the TURN > server will relay the data to the client. However, there is no channel > bound for this peer. As a consequence, the server encapsulates the data > in a Data indication (message 12). Note that, the server itself does NOT > try to bind a channel. Only the client can do that. > > Instead, the client, upon receiving the data, decides it would like a > channel for this second peer. So, it sends a ChannelBind (message 13) > for this new peer. This is received by the TURN server and it binds > channel 8 to this peer, and sends the response (message 14). Now, when > the next datagram arrives from this new peer (message 15), it is sent to > the client unencapsulated on channel 8 (message 16). > > In comparing this technique (Ekrs Technique) with the one in > draft-ietf-behave-turn-05 (Current Technique), we came up with the > following pros and cons: > > Ekrs Technique > -------------- > > PRO: Allows the client to decide, on a case by case basis, whether to > pay the overhead (ChannelBind transaction) to bind a channel to a peer. > For example, in ICE exchanges, the client could skip channel binding for > the connectivity checks, and only do the binding if ICE selects the peer > transport address. > > PRO: Related to the previous point, the current channel binding > mechanism does not allow a client to remove or delete a channel binding. > Thus, for an allocation which is very long lived, the client could > eventually run out of channels and need to re-allocate to clear them > all > or get more channels. Since Ekrs Technique allows the client to > selectively channel bind, when used with protocols like ICE where it is > not needed to channel bind for all peers, the allocation will 'last > longer' - that is, channel numbers get exhausted more slowly. > Architecturally, this is because Ekrs Technique separates channel > binding and data transmission, whereas the Current Technique > combines them. > > CON: Under packet loss, it is possible that the ChannelBind request > could be lost. If so, it will be retransmitted an RTO later. This means > that, the amount of time between request and response is equal to RTT + > 2^N * RTO, where N is the number of packet losses. The client cannot > send unencapsulated data until the ChannelBind response is received. > This duration is therefore equal to RTT+ 2^N*RTO, which is longer than > the Current Technique. There was split opinions on whether this was a > big deal or not, but it is a CON. > > PRO: Seems simpler to have a single channel number for messages in both > directions > > PRO: If a channel binding is in place for a peer, the first data from > that peer can be sent immediatley unencapsulated. With the Current > Technique, since channel numbers are always different in each direction, > the first packet (and indeed, the first RTT set of packets after the > first) will be sent encapsulated. > > PRO: there is a documented security concern with the Current Technique > in TURN-5. Since ChannelConfirm is an indication, it is unauthenticated. > An attacker could, upon seeing a Send indication from a client, send a > faked ChannelConfirm indication, and then cause the Send request to be > discarded. As a consequence, the client will believe the channel is > bound, when it is not. The client will, for the remaining duration of > the allocation, send data on that channel, and it will be discarded by > the TURN server. The client will not know that this happened. With Ekrs > Technique, this attack is mitigated. > > PRO: Does not require the client to receive requests and send responses. > There has been some debate on whether this is important. Note that this > PRO is shared by both techniques. > > PRO: A client could, as a matter of local implementation choice, elect > to not implement or use Send. Instead, it can wait for channels to be > bound and send data unencapsulated. This does mean that clients would > either drop data to be send prior to receiving the ChannelBind response, > else delay sending to that time. > > > > Current Technique > ----------------- > > CON: Each Send indication (and Data indication) causes a ChannelConfirm > indication. If the client is sending a lot of data, say, at rate R, this > will cause R*RTT number of ChannelConfirm messages to be sent. In > essence, the server 'spams' the client will redundant ChannelConfirm > messages, even when there was no packet loss. > > PRO: The amount of time until a client can sent unencapsulated data is > equal to RTT + T*N, where N is the number of packet losses and T is the > inter-arrival time between data from client to the peer. This number > will typically be lower than Ekrs Technique under conditions of packet > loss. Note that they are identical in conditions of no packet loss. > > PRO: In the case of TCP between client and server, the server can omit > sending ChannelConfirm and the client can send data unencapsulated > immediately. With Ekrs technique, the client can also send data > unencapsulated immediately, but since ChannelBind is a transaction, a > response is still required. > > PRO: Does not require the client to receive requests and send responses. > There has been some debate on whether this is important. Note that this > PRO is shared by both techniques. > > > > > Of the folks present, most (including myself) were in favor of Ekrs > Technique. Consequently, we'd like to confirm this decision, and see if > there is rough consensus to go with Ekrs technique. > > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net > PHONE: (408) 902-3084 > http://www.cisco.com > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Dec 12 23:20:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2fYm-0008IF-1i; Wed, 12 Dec 2007 23:20:32 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2fYk-0008AG-6a for behave-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 23:20:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2fYj-0008A7-T5 for behave@ietf.org; Wed, 12 Dec 2007 23:20:29 -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 1J2fYj-0005MD-EH for behave@ietf.org; Wed, 12 Dec 2007 23:20:29 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 12 Dec 2007 20:20:28 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lBD4KT7u028710; Wed, 12 Dec 2007 20:20:29 -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 lBD4KS0i016052; Thu, 13 Dec 2007 04:20:28 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 20:20:28 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 20:20:28 -0800 Message-ID: <4760B333.9060108@cisco.com> Date: Wed, 12 Dec 2007 23:21:07 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Bob Andreasen Subject: Re: [BEHAVE] TURN Issue #4: Port Adjacency References: <4759CC2B.9050206@cisco.com> <1065122831.20071210125221@gmail.com> In-Reply-To: <1065122831.20071210125221@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Dec 2007 04:20:28.0491 (UTC) FILETIME=[7DEBF9B0:01C83D3F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2717; t=1197519629; x=1198383629; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20Issue=20#4=3A=20Port= 20Adjacency |Sender:=20; bh=MuQnffVj/5/AYuOsoWGegAFsHw0Btx5evKgZvK1d6IA=; b=mFwa+VWdzmREiE02Ak1gybNWwgO6TXg8mWtNQGz6FXrdkYn+X4rNW/DsRz DJuS7qnKq17SlBoOc7O57nEyvM7WBEBsIviqOssnoXgfU+fk6WTE7rvvLmq0 lXY43EyhGD; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org The problem with doing both is that the client needs to discover if the server supports this option, and if it wanted it, have fallback logic to handle the case where the server doesn't support it. It is my preference to keep TURN simple by eliminating options, since options tend to complicate protocols. -Jonathan R. Bob Andreasen wrote: > Any chance of taking options 1 and 2b -- by making > REQUESTED_PORT_PROPS an optional attribute? I do understand that this > is needed for many environments -- but it isn't need for all. Given > that #1 was on the table (even if only for completeness), making it > optional seems like a reasonable change. > > - > Bob > > On Friday, December 7, 2007, 5:41:47 PM, Jonathan Rosenberg wrote: > >> This didn't get covered in the WG meeting but was discussed in the ad-hoc. > >> TURN allows a client to request an even port, and along with it, ask the >> TURN server to allocate the odd port one higher. However, the spec >> currently has the following confusing words in it: > >> As such, it is a request for the server to allocate an even >> port whose next higher port is also available, and furthermore, a >> request for the server to not allocate that one higher port to any >> other request except for one that asks for that port explicitly. The >> server can honor this request for adjacency at its discretion. The >> only constraint is that the allocated port has to be even. > > >> This would seem to imply that a server could respond with an OK >> response, allocate the even port, but not even bother with the odd port. >> Thus, when the client tries the odd port, it gets rejected. So the >> client has to try again. This non-deterministic behavior would >> complicate the client. > >> The options were: > >> 1. ditch the feature >> 2. make it so that the server MUST allocate the even port and the next >> higher odd port, and if it can't do both, reject the request. After >> allocating both, it holds onto the odd port, waiting for the client to >> request it, for: >> a. some fixed time, say 30s >> b. the duration of the allocation > >> Folks still wanted this feature since it is used in practice. In the >> interests of avoiding another timer, there was agreement on 2b. > >> Please comment if you agree (or if you don't) on this conclusion. > >> -Jonathan R. > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Dec 12 23:22:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2faQ-0004sh-15; Wed, 12 Dec 2007 23:22:14 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2faO-0004ld-Rw for behave-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 23:22:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2faO-0004j9-Eh for behave@ietf.org; Wed, 12 Dec 2007 23:22:12 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2faN-0007IF-Q1 for behave@ietf.org; Wed, 12 Dec 2007 23:22:12 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 12 Dec 2007 20:22:10 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBD4MBCn019883; Wed, 12 Dec 2007 20:22:11 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBD4MB9N027830; Thu, 13 Dec 2007 04:22:11 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 20:22:11 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 20:22:10 -0800 Message-ID: <4760B399.5020905@cisco.com> Date: Wed, 12 Dec 2007 23:22:49 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Derek MacDonald Subject: Re: [BEHAVE] TURN Issue #4: Port Adjacency References: <4759CC2B.9050206@cisco.com> <1065122831.20071210125221@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Dec 2007 04:22:10.0664 (UTC) FILETIME=[BAD25680:01C83D3F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3972; t=1197519731; x=1198383731; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20Issue=20#4=3A=20Port= 20Adjacency |Sender:=20; bh=QrVsRrm1l/+vZyc0dabWxeL1IRVEL2j5EsIyE4izFe4=; b=dbo283bkB8746KicRx3xe1kvH22gk3+a4diaBbT5eQLl2ZC5oqIVRg7XM+ XP0JX1mfP5/T5kyNj6QMFCxxXGVpVVD2ku3evcFltx3rmwlE0xGmXlV0Q4vB LxVVk1EoW7XWBK9z8A6Sjz9IerdNzbb5dzKXtVmDeGltXZFGZhIVg=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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 Well, the argument has always been that TURN is used in conjunction with ICE as the default candidate, and thus gets used when talking to non-ICE peers - the same ones that won't have 3605. I can't see folks using TURN as an excuse to avoid 3605, since it means you have to actually route all your media through the TURN server, and that is much worse than just implementing 3605. So my preference remains #2b. -Jonathan R. Derek MacDonald wrote: > My experience is that this is often needed in all deployments w/ > heterogeneous endpoints. Of course, a counterargument is that an > endpoint going through a NAT which does not tend to map ports adjacently > has no way of guaranteeing this. > > The question is: is there a concern that turn will be used to dodge > implementing 3605? I suspect that RTCP is generally failing in > environments where the NAT is doing many concurrent allocations. > > So, a new turn open issue: > > Should adjacent port allocation be in scope for TURN? > > -Derek > > On Dec 10, 2007 9:52 AM, Bob Andreasen > wrote: > > > Any chance of taking options 1 and 2b -- by making > REQUESTED_PORT_PROPS an optional attribute? I do understand that this > is needed for many environments -- but it isn't need for all. Given > that #1 was on the table (even if only for completeness), making it > optional seems like a reasonable change. > > - > Bob > > On Friday, December 7, 2007, 5:41:47 PM, Jonathan Rosenberg wrote: > > > This didn't get covered in the WG meeting but was discussed in > the ad-hoc. > > > TURN allows a client to request an even port, and along with it, > ask the > > TURN server to allocate the odd port one higher. However, the spec > > currently has the following confusing words in it: > > > As such, it is a request for the server to allocate an even > > port whose next higher port is also available, and > furthermore, a > > request for the server to not allocate that one higher port > to any > > other request except for one that asks for that port > explicitly. The > > server can honor this request for adjacency at its > discretion. The > > only constraint is that the allocated port has to be even. > > > > This would seem to imply that a server could respond with an OK > > response, allocate the even port, but not even bother with the > odd port. > > Thus, when the client tries the odd port, it gets rejected. So the > > client has to try again. This non-deterministic behavior would > > complicate the client. > > > The options were: > > > 1. ditch the feature > > 2. make it so that the server MUST allocate the even port and the > next > > higher odd port, and if it can't do both, reject the request. After > > allocating both, it holds onto the odd port, waiting for the > client to > > request it, for: > > a. some fixed time, say 30s > > b. the duration of the allocation > > > Folks still wanted this feature since it is used in practice. In the > > interests of avoiding another timer, there was agreement on 2b. > > > Please comment if you agree (or if you don't) on this conclusion. > > > -Jonathan R. > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Dec 12 23:24:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2fcT-0006K3-EO; Wed, 12 Dec 2007 23:24:21 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2fcR-0006Hp-Ux for behave-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 23:24:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2fcR-0006Hh-JW for behave@ietf.org; Wed, 12 Dec 2007 23:24:19 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2fcR-0007KB-3Y for behave@ietf.org; Wed, 12 Dec 2007 23:24:19 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 12 Dec 2007 20:24:19 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lBD4OIDt003554; Wed, 12 Dec 2007 20:24:18 -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 lBD4OD0i017903; Thu, 13 Dec 2007 04:24:13 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 20:24:13 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 20:24:12 -0800 Message-ID: <4760B414.3050703@cisco.com> Date: Wed, 12 Dec 2007 23:24:52 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #2: Stateful allocations References: <47599D4F.50102@cisco.com> <200712101056.32140.remi.denis-courmont@nokia.com> <475D5443.5050601@cisco.com> <4A3D1671-D40E-449E-ADC3-24D2E8D16B90@magma.ca> In-Reply-To: <4A3D1671-D40E-449E-ADC3-24D2E8D16B90@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 13 Dec 2007 04:24:12.0836 (UTC) FILETIME=[03A44E40:01C83D40] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2757; t=1197519858; x=1198383858; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20Issue=20#2=3A=20State ful=20allocations |Sender:=20; bh=x5LbBXmPjp4Hn6rFo5GWeB6VAArIF398GNZ+iWSqGkc=; b=TOy3wBhw2XDBBn8EJw2kC5u3o4x8mkD2QBPdqby2VsS5hepJ9vkSJo7oMk ijZHEkiG2MrGD3EGMxVaW8hOH0wqsE5RdB9nFjoYykS3igaMUHmBmN4slBOH RP5eSds/H/; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I don't see what the duration of the allocation has to do with the 10 second timer. Another way to think about the timer is that the server has to provide transaction state and retain it for 10 seconds after the end of the transaction. -Jonathan R. Philip Matthews wrote: > > On 10-Dec-07, at 06:59 , Jonathan Rosenberg wrote: > >> inline: >> >> Rémi Denis-Courmont wrote: >>> Le Friday 07 December 2007 21:21:51 ext Jonathan Rosenberg, vous avez >>> écrit : >>>> There was general agreement at the ad-hoc that this is a non-issue. >>>> TURN >>>> servers are already required to maintain state, in the form of >>>> allocations, permissions, channel bindings, and so on. Transaction >>>> state >>>> is not much more. >>>> >>>> Note that, rfc3489bis requires stun transactions (including extensions >>>> like TURN) to be idempotent. Note that, despite the different response >>>> codes for a retransmit and new transaction, TURN remains idempotent. >>>> Idempotency only requires that subsequent retries do not alter the >>>> state >>>> on the server; it does NOT require the same response. We went through >>>> this ad-nauseum on XCAP. >>>> >>>> The proposal is therefore to just document this fact, but otherwise not >>>> change anything. >>>> >>>> Please comment if you agree (or not) with this. >>> If I understand correctly, this practically means the server must >>> remember the ID of the STUN transaction that created the TURN >>> allocation. When it receives an allocation, it returns a success >>> response if it's the same ID or an error if it's not. Right? >> >> Yes. > > To be consistent with 3489bis, you would also have to have a 10 second > timer. 3489bis says: > If the request uses UDP transport and is a retransmission of a > request for which the server has already generated a success response > within the last 10 seconds, the server MUST retransmit the same > success response. One way for a server to do this is to remember all > transaction IDs received over UDP and their corresponding responses > in the last 10 seconds. > > For short-lived TURN allocations, the 10-second timer is probably > pointless, even though 3489bis requires it. For long-lived allocations > (days or weeks or even months), the timer might become important -- I > haven't worked out the math. In either case, I think the two documents > should be consistent. > > - Philip > > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Dec 12 23:29:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2fhX-0003k7-70; Wed, 12 Dec 2007 23:29:35 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2fhV-0003cu-Q4 for behave-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 23:29:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2fhV-0003ay-Fi for behave@ietf.org; Wed, 12 Dec 2007 23:29:33 -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 1J2fhU-0005Uy-UH for behave@ietf.org; Wed, 12 Dec 2007 23:29:33 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 12 Dec 2007 20:29:32 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lBD4TWDE007419; Wed, 12 Dec 2007 20:29:32 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lBD4TW0i020648; Thu, 13 Dec 2007 04:29:32 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 20:29:23 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 20:29:22 -0800 Message-ID: <4760B54A.1040508@cisco.com> Date: Wed, 12 Dec 2007 23:30:02 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Marc Petit-Huguenin Subject: Re: [BEHAVE] TURN Issue #1: Bandwidth Param References: <47599BE6.9090903@cisco.com> <4759AFD5.7030200@acm.org> In-Reply-To: <4759AFD5.7030200@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Dec 2007 04:29:22.0979 (UTC) FILETIME=[BC805F30:01C83D40] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3330; t=1197520172; x=1198384172; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20Issue=20#1=3A=20Bandw idth=20Param |Sender:=20; bh=GXv4TvBcwkYQRvsgGpmbFn3FSuDOrr54j7+/3RjxjwI=; b=YpvXOBYu9HKqlkOCvGTGoaLPPaDzBpHz4wKAWsRDwju9hEwneV22sbtuoC zAjYCrunPVRSpAmqAUcCFj0fXN+d5OJjaFg7blBWu8moGQordLKdm8AaWTbS jgPQHPUEgw; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org inline: Marc Petit-Huguenin wrote: > Jonathan Rosenberg wrote: >> Open issue #1 from my slides (discussed during the WG meeting and at the >> ad-hoc), is the Bandwidth param. The issue is, its ill-defined right >> now. If no one wants it, we should drop it. If someone wants it, we need >> to define it. >> >> During the WG meeting, folks spoke out in favor of it. Apparently there >> is currently deployed usage of this parameter. It is not being used for >> capacity planning. Rather, it is being used to rate limit consumers so a >> customer doesn't abuse the TURN server. Folks running that deployment >> strongly believed that the mechanism was needed. >> >> So, the proposal is to keep this parameter. I have reached out to folks >> involved in RSVP to help us reuse a precise definition of how to measure >> the bandwidth parameter, since this is not a new problem. The proposed >> semantics would be something like this: >> >> Client MAY include bandwidth in a request. If present, it is a request >> from the client that the server forward traffic to and from the client >> such that the total in each direction will not be excess of this value. >> Server MAY include a value in a response, even if there was not one in a >> request. The meaning of the value in the response, is that the server >> agrees to forward traffic to/from the client so long as it is below the >> bandwidth value. Any traffic above that value may be dropped by the >> server. If there is no value in the response, the server will relay >> traffic at best effort. Furthermore, there is never an absolute >> guarantee that the server will be able to relay data even if the usage >> is below the bandwidth parameter, and clients MUST be prepared for >> packet loss. Of course, there could be packet loss outside of the TURN >> server anyway. >> >> Please comment if you are happy (or not) with keeping bandwidth with >> these proposed semantics. >> > > I am OK with keeping bandwidth, but I would like to add one thing. The > problem with bandwidth is when TURN is used with ICE. A TURN allocation > will be made but it will generally not be used excepted for connectivity > checks (i.e. far less than the bandwidth that will be used for video). > So most TURN servers used in an ICE environment will either > oversubscribe or waste resources. That wouldn't be a problem, normally. So when a client uses ICE it would do the allocation and provide the bandwidth that would be used if TURN is selected. If TURN is not selected, the client will, after ICE completes, drop the allocation. Thus, at any point in time, the allocations on the server will be all of those that are actually using TURN, plus a small number (those that have just arrived and for which TURN has not yet completed) that are only so far doing ICE. Law of large numbers would argue that for any reasonable server capacity, the overall capacity is dominated by the in-use allocations and not the transient ones. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Dec 12 23:31:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2fjo-0005NA-Ef; Wed, 12 Dec 2007 23:31:56 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2fjn-0005Kk-2O for behave-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 23:31:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2fjm-0005Ka-N9 for behave@ietf.org; Wed, 12 Dec 2007 23:31:54 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2fjm-0007So-9g for behave@ietf.org; Wed, 12 Dec 2007 23:31:54 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 12 Dec 2007 20:31:54 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBD4Vrdo026936; Wed, 12 Dec 2007 20:31:53 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBD4Vr9N003398; Thu, 13 Dec 2007 04:31:53 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 20:31:53 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 20:31:53 -0800 Message-ID: <4760B5E0.2000704@cisco.com> Date: Wed, 12 Dec 2007 23:32:32 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Bob Andreasen Subject: Re: [BEHAVE] TURN Issue #1: Bandwidth Param References: <47599BE6.9090903@cisco.com> <200712101053.17425.remi.denis-courmont@nokia.com> <1469047018.20071210102958@gmail.com> In-Reply-To: <1469047018.20071210102958@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 13 Dec 2007 04:31:53.0324 (UTC) FILETIME=[161D32C0:01C83D41] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1582; t=1197520313; x=1198384313; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20Issue=20#1=3A=20Bandw idth=20Param |Sender:=20; bh=KfTZK+niD454GvQ8OKA0u3AzvetrWQd0f9V1a4UXNs4=; b=M5DJgdxVSzHmiYYuITOXcIU3u3OU6MokwmUcu9wF8IG3a1EPYZ9uzLi6qW TvRFOW4sHXszvHRLQ4z8hL5bju2e+8WJvkG0vQYIa2pH/t2Wpqce3Oim/fv3 LXKeO2OxDEec/tJSbXMG5kG7J3fupBqJhKKROQJOXz98EHSmFM+D4=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); 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 Bob Andreasen wrote: > On Monday, December 10, 2007, 3:53:16 AM, Rémi Denis-Courmont wrote: > >> Le Friday 07 December 2007 21:15:50 ext Jonathan Rosenberg, vous avez écrit : >>> Server MAY include a value in a response, even if there was not one in a >>> request. The meaning of the value in the response, is that the server >>> agrees to forward traffic to/from the client so long as it is below the >>> bandwidth value. > >> Hmm. I kinda doubt that a client which does not specify bandwidth would make >> any use of a returned bandwidth parameter. > > I agree that a client which does not request a bandwidth would > probably not use it -- but it is still very valuable to know if/when a > cap will be enforced. One could adjust their codecs and bandwidth > given that information. I think the main benefit in this case is really troubleshooting; if the client is seeing packet loss it can have a hint at whether the problem is that the traffic it is receiving is above its fair share, or because there is IP network packet loss. But the point is, if a server is not doing per-user rate limiting, it would simply omit the bandwidth parameter in the response (assuming there was none in the request) and then it works as you say - best effort. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Dec 12 23:45:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2fwX-0007zW-2K; Wed, 12 Dec 2007 23:45:05 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2fwW-0007zP-3W for behave-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 23:45:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2fwV-0007zG-DY for behave@ietf.org; Wed, 12 Dec 2007 23:45:03 -0500 Received: from quinthar.com ([72.52.120.178]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J2fwU-0007gR-S4 for behave@ietf.org; Wed, 12 Dec 2007 23:45:03 -0500 Received: from lappy ([98.207.96.5]) by quinthar.com for ; Wed, 12 Dec 2007 20:45:01 -0800 From: "David Barrett" To: "'Jonathan Rosenberg'" , "'Sourav Chakraborty'" Subject: RE: [BEHAVE] TURN draft queries Date: Wed, 12 Dec 2007 20:45:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4760B094.7040800@cisco.com> Thread-Index: Acg9PfFCve6qPSjYTSC9QO7ZHHubYAAAQRCA X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Message-Id: Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Subject: Re: [BEHAVE] TURN draft queries > > > Also please clarify whether only STUN(not TURN) can be used as a > solution for UDP media traffic > > > > transfer over SYMMETRIC NATs. > > > > --both endpoints behind symmetric NATs > TURN will be required.Only STUN is not enough > > --one endpoint behind symmetric NAT,other endpoint in public domain > Not > > sure.Please clarify?? > > FIrstly, STUN and TURN both are meant to be used with ICE. > WHen ICE is in use, if both endpoints are behind symmetric NAT, ICE will > end up with a single TURN server. > If only one endpoint is behind symmetric NAT, ICE will not use the TURN > server for that call. Actually, if one side is symmetric and the other side is restricted cone, won't TURN still be needed? In this scenario, both sides filter out packets that come from ports that aren't explicitly being sent to. This isn't a problem when doing CONE->CONE because both sides know where to send. But if one side is symmetric, then the cone side doesn't know where to send to: thus the symmetric side won't receive anything, and anything it sends will be filtered out by the restricted cone. Incidentally, my stats show something like 45% restricted cone (ie, port and endpoint dependent filtering) and 15% symmetric (port and endpoint dependent mapping). So right off the top it sounds like somewhere around 6% of calls will be symmetric/restricted combination, and another 2% will be symmetric/symmetric, suggesting at least 9% of all calls will need TURN relaying (and that assumes perfect penetration everywhere else, which is an incredibly optimistic assumption). Anyway, I don't think that's a dealbreaker, but it's probably good to keep in mind that 90% peer connectivity is likely the *upper* bound of ICE's capabilities. The lower bound is, of course, 0%, and we've very little data indicating where in between it'll actually be. -david _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 13 00:18:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2gSx-0007u6-Ot; Thu, 13 Dec 2007 00:18:35 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2gSw-0007u1-Ja for behave-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 00:18:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2gSw-0007tt-9e for behave@ietf.org; Thu, 13 Dec 2007 00:18:34 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2gSv-0006N1-PD for behave@ietf.org; Thu, 13 Dec 2007 00:18:34 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 12 Dec 2007 21:18:33 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBD5IXMO032181; Wed, 12 Dec 2007 21:18:33 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBD5IV9N002123; Thu, 13 Dec 2007 05:18:33 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 21:18:31 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 21:18:30 -0800 Message-ID: <4760C0CE.8090301@cisco.com> Date: Thu, 13 Dec 2007 00:19:10 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: David Barrett Subject: Re: [BEHAVE] TURN draft queries References: <6f6meo$446of@sj-inbound-d.cisco.com> In-Reply-To: <6f6meo$446of@sj-inbound-d.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Dec 2007 05:18:30.0842 (UTC) FILETIME=[999091A0:01C83D47] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2264; t=1197523113; x=1198387113; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20draft=20queries |Sender:=20; bh=7HhdK9dcYo8kXOCVddy8Y4GvSUk2amWhRDywDTHv2sk=; b=EgDJwo5x1KCGivzfv3phGrGcKfqga92Ao0JRyPDeQ0B0zRQEVcJ2VH0a/I Zp0wNFwnzwFyfzwqAtzh+0SoLAcWALxaTMGm0o2S362ntuwlmhICapMmLwYC Xgm/Rb7mmLIhIIBEYo2ULTLFrmcG8iiPCLqRIpfKmxGdCi4cq8SP4=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org inline: David Barrett wrote: >> If only one endpoint is behind symmetric NAT, ICE will not use the TURN >> server for that call. > > Actually, if one side is symmetric and the other side is restricted cone, > won't TURN still be needed? > > In this scenario, both sides filter out packets that come from ports that > aren't explicitly being sent to. This isn't a problem when doing CONE->CONE > because both sides know where to send. But if one side is symmetric, then > the cone side doesn't know where to send to: thus the symmetric side won't > receive anything, and anything it sends will be filtered out by the > restricted cone. If the other side is address restricted, it will still go direct as long the as the guy behind the symmetric NAT has a NAT with just a single external IP. If the other side is address and port restricted, you are correct a TURN server would be used. > > Incidentally, my stats show something like 45% restricted cone (ie, port and > endpoint dependent filtering) and 15% symmetric (port and endpoint dependent > mapping). So right off the top it sounds like somewhere around 6% of calls > will be symmetric/restricted combination, and another 2% will be > symmetric/symmetric, suggesting at least 9% of all calls will need TURN > relaying (and that assumes perfect penetration everywhere else, which is an > incredibly optimistic assumption). This number is pretty consistent with reports I've gotten from ICE deployments, which indicate a little less than 10% of calls are requiring TURN servers. > > Anyway, I don't think that's a dealbreaker, but it's probably good to keep > in mind that 90% peer connectivity is likely the *upper* bound of ICE's > capabilities. Until the deployment of behave-compliant NAT everywhere, yes. So the hope is that over time, turn usage with ICE drops from around 10% of calls eventually to zero. Then we can retire them. I hope. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 13 00:23:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2gXc-0007XV-3s; Thu, 13 Dec 2007 00:23:24 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2gXb-0007XQ-90 for behave-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 00:23:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2gXa-0007XH-Uy for behave@ietf.org; Thu, 13 Dec 2007 00:23:22 -0500 Received: from quinthar.com ([72.52.120.178]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J2gXa-0008Pe-I3 for behave@ietf.org; Thu, 13 Dec 2007 00:23:22 -0500 Received: from lappy ([98.207.96.5]) by quinthar.com for ; Wed, 12 Dec 2007 21:23:21 -0800 From: "David Barrett" To: "'Jonathan Rosenberg'" Subject: RE: [BEHAVE] TURN draft queries Date: Wed, 12 Dec 2007 21:23:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4760C0CE.8090301@cisco.com> Thread-Index: Acg9R5rZe8XxKL0VTHWdLxDIw5WBbAAAFqJw X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Message-Id: Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Subject: Re: [BEHAVE] TURN draft queries > > This number is pretty consistent with reports I've gotten from ICE > deployments, which indicate a little less than 10% of calls are > requiring TURN servers. Ah, cool! Can you share any of those numbers in more detail? > > Anyway, I don't think that's a dealbreaker, but it's probably good to > keep > > in mind that 90% peer connectivity is likely the *upper* bound of ICE's > > capabilities. > > Until the deployment of behave-compliant NAT everywhere, yes. So the > hope is that over time, turn usage with ICE drops from around 10% of > calls eventually to zero. Then we can retire them. I hope. Yes, that'll be a good day! -david _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 13 07:47:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2nTD-00039W-2w; Thu, 13 Dec 2007 07:47:19 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2nTC-00039R-3g for behave-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 07:47:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2nTB-00039I-MK for behave@ietf.org; Thu, 13 Dec 2007 07:47:17 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2nTB-0002Es-8f for behave@ietf.org; Thu, 13 Dec 2007 07:47:17 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBDCktN4030830; Thu, 13 Dec 2007 06:47:37 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 14:46:36 +0200 Received: from esdhcp034248.research.nokia.com ([172.21.34.248]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 14:46:36 +0200 Message-Id: From: Lars Eggert To: ext Jonathan Rosenberg In-Reply-To: <47599BE6.9090903@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [BEHAVE] TURN Issue #1: Bandwidth Param Date: Thu, 13 Dec 2007 14:46:36 +0200 References: <47599BE6.9090903@cisco.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 13 Dec 2007 12:46:36.0241 (UTC) FILETIME=[3282E410:01C83D86] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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-12-7, at 21:15, ext Jonathan Rosenberg wrote: > Client MAY include bandwidth in a request. What exactly is bandwidth defined as? This is not trivial; see draft- ietf-ippm-bw-capacity. We do need a crisp definition if this is to work. > If present, it is a request from the client that the server forward > traffic to and from the client such that the total in each direction > will not be excess of this value. Do I read this correctly as a "please rate-limit me to X" option? What incentive does a client have to send this? > Server MAY include a value in a response, even if there was not one > in a request. The meaning of the value in the response, is that the > server agrees to forward traffic to/from the client so long as it is > below the bandwidth value. Any traffic above that value may be > dropped by the server. But this doesn't tell the client all that much. Yes, if it stays below the limit, it can be sure that the server doesn't rate-limit it, but congestion on the path can happen before that rate is reached, i.e., the client can't depend on it. And because the server may forward traffic that exceeds this rate, the client has every incentive to see if it can send more than the signaled rate. > If there is no value in the response, the server will relay traffic > at best effort. Furthermore, there is never an absolute guarantee > that the server will be able to relay data even if the usage is > below the bandwidth parameter, and clients MUST be prepared for > packet loss. Of course, there could be packet loss outside of the > TURN server anyway. Right, this pretty much sums up my concerns. TURN isn't a QoS-signaling solution, so I'm all for removing this option. Lars (as an individual) _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 13 07:56:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2nbq-0006TE-Pr; Thu, 13 Dec 2007 07:56:14 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2nbq-0006Rw-8o for behave-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 07:56:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2nbp-0006LW-7F for behave@ietf.org; Thu, 13 Dec 2007 07:56:13 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2nbn-0000rb-RI for behave@ietf.org; Thu, 13 Dec 2007 07:56:13 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBDCtLQC006390; Thu, 13 Dec 2007 06:56:32 -0600 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 14:55:52 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 14:55:51 +0200 Received: from esdhcp034248.research.nokia.com ([172.21.34.248]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 14:55:51 +0200 Message-Id: From: Lars Eggert To: ext Jonathan Rosenberg In-Reply-To: <4759CC2B.9050206@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [BEHAVE] TURN Issue #4: Port Adjacency Date: Thu, 13 Dec 2007 14:55:51 +0200 References: <4759CC2B.9050206@cisco.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 13 Dec 2007 12:55:51.0597 (UTC) FILETIME=[7D877DD0:01C83D87] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 2007-12-8, at 0:41, ext Jonathan Rosenberg wrote: > TURN allows a client to request an even port, and along with it, ask > the TURN server to allocate the odd port one higher. Given that we're about to recommend that end hosts implement port randomization and most OSs do this already (draft-ietf-tsvwg-port- randomization), this seems to be an anachronism. So ditch it. (Or does anyone have a convincing use case?) Lars (as an individual) _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 13 08:03:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2nii-0007wG-Fg; Thu, 13 Dec 2007 08:03:20 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2nig-0007w4-Nk for behave-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 08:03:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2nig-0007tz-5R for behave@ietf.org; Thu, 13 Dec 2007 08:03:18 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2nif-00015c-S1 for behave@ietf.org; Thu, 13 Dec 2007 08:03:18 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBDD2RhB012261; Thu, 13 Dec 2007 07:02:58 -0600 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 15:02:27 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 15:02:27 +0200 Received: from esdhcp034248.research.nokia.com ([172.21.34.248]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 15:02:27 +0200 Message-Id: <152D0B93-6269-4B44-A313-1D90EE6E8E73@nokia.com> From: Lars Eggert To: ext Jonathan Rosenberg In-Reply-To: <4759CD14.10208@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [BEHAVE] TURN Issue #5: Port Range Date: Thu, 13 Dec 2007 15:02:27 +0200 References: <4759CD14.10208@cisco.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 13 Dec 2007 13:02:27.0191 (UTC) FILETIME=[69525870:01C83D88] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 2007-12-8, at 0:45, ext Jonathan Rosenberg wrote: > TURN currently says that a TURN server SHOULD only utilize ports in > the range 1024-65535, avoiding the well-known ports from 1-1023. Given that the registered port range extends from 1024-49151, TURN should limit itself to using the Private Ports from 49152-65535, in order to avoid using ports registered to other applications. Lars (as an individual) _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 13 09:15:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2oqP-0007Z5-IT; Thu, 13 Dec 2007 09:15:21 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2oqO-0007Z0-RQ for behave-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 09:15:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2oqO-0007Yr-5F for behave@ietf.org; Thu, 13 Dec 2007 09:15:20 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-05.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2oqN-0004eZ-48 for behave@ietf.org; Thu, 13 Dec 2007 09:15:20 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J2opX-00006n-23; Thu, 13 Dec 2007 09:14:27 -0500 In-Reply-To: <4760B1A0.6080807@cisco.com> References: <4759D19B.50005@cisco.com> <4760B1A0.6080807@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9B05C6FD-FF8A-4472-966E-D13C8573A9BF@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages Date: Thu, 13 Dec 2007 09:15:03 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I think this use-case might be real (well, not the put it in DNS part...). I think that TURN clients might well want to do a single allocation and use it for a long period of time. So I am somewhat opposed to making this change at all. I don't think that any of the three advantages are strong, and I am worried about cutting the number of channels in half. - Philip On 12-Dec-07, at 23:14 , Jonathan Rosenberg wrote: > 32767 vs. 65535 is irrelevant for any SIP use cases we have to date. > > Where this is a potential issue, is the following. Lets say you are > a client and go to your TURN server and get an ip address and port. > You basically want to hold on to that IP address and port for a > really long time. Think of it like a nailed up VPN. Sufficiently > long that the client might want to publish its IP/port in DNS or > something (obviously requiring SRV records). > > Now, the client can't run a server, but presuming some rendezvous > mechanism, for each corresponding peer, it opens a permission, > communicates with them, and then its done. Next day, a different > peer, new permission created, etc. > > In that use case, the client will eventually burn through all 32767 > channels, and obviously will do so in half the time it would if all > 65535 were there. > > Now, I personally don't see this use case as being real, but I just > wanted to point it out. > > -Jonathan R. > > Derek MacDonald wrote: >> I like this change because it will simplify the implementation of >> a client that uses both ICE/TURN as two modes of TURN/ICE packet >> writing will no have to be supported. >> I do not believe the reduction in the total # of channels is >> relevant; 32767 channels is half of the available port space, >> which is much more than an endpoint would expect from a shared >> (enterprise) NAT. >> The TURN server will probably run out of tuples well before the >> client does. >> -Derek >> On Dec 7, 2007 3:04 PM, Jonathan Rosenberg > > wrote: >> This issue was not in my slides. It was brought up at the mike >> in the >> WG, and was discussed there. It was not discussed further at >> the ad-hoc. >> As of turn-05, we introduced a framing mechanism, which is a 4 >> byte >> header consisting of 2 bytes channel and 2-bytes length. This >> framing >> header precedes ALL packets sent between a client and its TURN >> server, >> including both application data and TURN messages themselves, >> which are >> sent on channel zero. >> Ekr raised a question of why this header was needed for actual >> TURN >> messages. After all, he argued, we went through all this >> trouble to make >> STUN (and thus TURN) differentiatable from each other. Indeed, >> others >> noted that the framing header itself looks very similar to the >> top 4 >> bytes of the STUN message format anyway: >> 0 1 >> 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 >> 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+-+-+-+-+ >> |0 0| STUN Message Type | Message >> Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+-+-+ >> | Magic >> Cookie | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+-+-+ >> >> | | >> | Transaction ID (96 >> bits) | >> >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+-+-+ >> and the proposed framing header: >> 0 1 >> 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 >> 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+-+-+ >> | Channel | Message >> Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+-+-+ >> So an alternative design is to make the framing header look like: >> 0 1 >> 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 >> 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+-+-+ >> |1| Channel | Message >> Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+-+-+ >> So that there are 15 bits of channel instead of 16. Placing a >> 1 in that >> position makes the framing header always a non-match for STUN >> messages. >> Thus, it would not be even needed to do the more complex matching >> operations defined in STUN; a 1-bit check would do the job to >> separate >> out application data from STUN/TURN. >> The benefits of this change would be: >> 1. We would, once again, be able to run STUN and TURN on the >> same >> port on the server. As of turn-05 they MUST run on different >> ports >> because the framing header was unique to TURN. This could be a >> feature >> or a bug depending on your perspective: >> FEATURE: TURN and STUN are actually very different; >> using >> separate ports would allow a firewall to block one and not the >> other. >> BUG: practically speaking separate ports doesnt help >> since >> with DNS the ports can be dynamic anyway. In addition, its >> always good >> to use fewer ports on a server. Also its weird that an >> extension to a >> protocol would run on a different port; that kind of tells you >> its not >> an extension. >> 2. Reduces the size of TURN messages by 4 bytes. This is a >> minor >> benefit and the real one is having a single port. >> 3. it'd be a little clearer to explain to people that TURN >> is an >> extension to STUN, rather than saying, TURN is a STUN >> extension that is >> run over a new framing header >> The drawbacks of this change would be: >> 1. cuts the number of channels in half >> An alternative design would be to use the full 16 bits for >> channel >> numbers, and then rely on the full suite of STUN differentiation >> techniques to demux. However, my preference in general is to >> not do that >> when its not actually needed. It complicates message >> processing and I >> don't think its worth it. 32767 channels is also a LOT for our >> envisioned use cases. >> This was somewhat inconclusive at the microphone. I'm >> personally on the >> fence and don't feel that strongly. I probably midly prefer >> making this >> change. >> Please comment on whether you prefer this change or not. >> Thanks, >> Jonathan R. >> -- >> Jonathan D. Rosenberg, Ph.D. 499 Thornall St. >> Cisco Fellow Edison, NJ 08837 >> Cisco, Voice Technology Group >> jdrosen@cisco.com >> http://www.jdrosen.net PHONE: (408) >> 902-3084 >> http://www.cisco.com >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave > > -- > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 13 09:16:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2orH-0007vl-Nm; Thu, 13 Dec 2007 09:16:15 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2orG-0007vf-9Z for behave-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 09:16:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2orF-0007vX-W7 for behave@ietf.org; Thu, 13 Dec 2007 09:16:13 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2orB-0003OU-G0 for behave@ietf.org; Thu, 13 Dec 2007 09:16:13 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J2orB-0005P9-0R; Thu, 13 Dec 2007 09:16:09 -0500 In-Reply-To: <4759D5A4.4090304@cisco.com> References: <4759D5A4.4090304@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #8: Managing permission lifetimes Date: Thu, 13 Dec 2007 09:16:08 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I support leaving this alone and waiting for the SAFE work to progress. - Philip On 7-Dec-07, at 18:22 , Jonathan Rosenberg wrote: > This issue was not in my slides. It was raised at the mike in the > WG meeting, and was not discussed further at the ad-hoc. > > The issue is this. In TURN-05 (and for several versions prior), > allocations have an expiration and are refreshed explicitly by TURN > signaling. However, permissions are refreshed by data traffic, and > there is NO way to explicitly ask for a longer permission. Ekr > pointed out that, we had a SAFE BoF at this IETF which was trying > to address the problem that we didn't have an explicit way to > manage the binding lifetimes on the NAT. So, since a TURN server is > basically a remote-controlled NAT, isn't it silly to design it > outright in a way that is known to be broken? > > The counter-argument that was made, is that you need to send the > data traffic anyway to refresh the bindings between the client and > the NAT. However, if there are multiple peers connected through the > allocation, it would be possible to send a single data keepalive > just to keepalive the connection from client to TURN server, > instead of sending data keepalives for each peer. This is true only > if there are no NATs between the TURN server and the peers. It was > pointed out that there are real use cases for that, including > enterprise deployments and p2psip. > > It was further pointed out that, if SAFE moves forward, at that > time we could add extensions to turn to manage the permission > lifetimes. Indeed, if SAFE uses STUN, it might even be the case > that we could re-use that very extension, but just send it to the > TURN server instead of the NAT. That would be really neat. > > Consequently, my sense from the meeting was that there was rough > agreement to leave this alone, and not try to add support in TURN > for explicitly requesting longer permission lifetimes. I think this > is the right thing. > > Please comment if you agree (or don't) with this. > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 13 10:00:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2pYC-00071H-N3; Thu, 13 Dec 2007 10:00:36 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2pYC-00071A-2u for behave-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 10:00:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2pYB-00070z-PQ for behave@ietf.org; Thu, 13 Dec 2007 10:00:35 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-09.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2pYB-0005gs-6w for behave@ietf.org; Thu, 13 Dec 2007 10:00:35 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J2pYA-0008CW-3C; Thu, 13 Dec 2007 10:00:35 -0500 In-Reply-To: <4760B414.3050703@cisco.com> References: <47599D4F.50102@cisco.com> <200712101056.32140.remi.denis-courmont@nokia.com> <475D5443.5050601@cisco.com> <4A3D1671-D40E-449E-ADC3-24D2E8D16B90@magma.ca> <4760B414.3050703@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #2: Stateful allocations Date: Thu, 13 Dec 2007 10:00:33 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I see a very small inconsistency between this and 3489bis. Let's assume the server uses Remi's suggested implementation =20 technique. And lets say a client does an Allocate transaction with =20 the server, then immediately deletes the allocation, and then does a =20 second Allocation that happens to use the same transaction id as the =20 first, but which the server cannot accept for some reason. Say all =20 this happens within 10 seconds. Then the server needs to response =20 with an error response, but 3489bis says that is should respond with =20 a success response. The problem is simply that the language in 3489bis is too strong for =20 the TURN case. We could fix this either by changing the language in =20 3489bis, or by specifying Remi's proposed implementation technique =20 and saying that this overrides the text in 3489bis about the 10 =20 second stuff. - Philip On 12-Dec-07, at 23:24 , Jonathan Rosenberg wrote: > I don't see what the duration of the allocation has to do with the =20 > 10 second timer. Another way to think about the timer is that the =20 > server has to provide transaction state and retain it for 10 =20 > seconds after the end of the transaction. > > -Jonathan R. > > Philip Matthews wrote: >> On 10-Dec-07, at 06:59 , Jonathan Rosenberg wrote: >>> inline: >>> >>> R=E9mi Denis-Courmont wrote: >>>> Le Friday 07 December 2007 21:21:51 ext Jonathan Rosenberg, vous =20= >>>> avez =E9crit : >>>>> There was general agreement at the ad-hoc that this is a non-=20 >>>>> issue. TURN >>>>> servers are already required to maintain state, in the form of >>>>> allocations, permissions, channel bindings, and so on. =20 >>>>> Transaction state >>>>> is not much more. >>>>> >>>>> Note that, rfc3489bis requires stun transactions (including =20 >>>>> extensions >>>>> like TURN) to be idempotent. Note that, despite the different =20 >>>>> response >>>>> codes for a retransmit and new transaction, TURN remains =20 >>>>> idempotent. >>>>> Idempotency only requires that subsequent retries do not alter =20 >>>>> the state >>>>> on the server; it does NOT require the same response. We went =20 >>>>> through >>>>> this ad-nauseum on XCAP. >>>>> >>>>> The proposal is therefore to just document this fact, but =20 >>>>> otherwise not >>>>> change anything. >>>>> >>>>> Please comment if you agree (or not) with this. >>>> If I understand correctly, this practically means the server =20 >>>> must remember the ID of the STUN transaction that created the =20 >>>> TURN allocation. When it receives an allocation, it returns a =20 >>>> success response if it's the same ID or an error if it's not. =20 >>>> Right? >>> >>> Yes. >> To be consistent with 3489bis, you would also have to have a 10 =20 >> second timer. 3489bis says: >> If the request uses UDP transport and is a retransmission of a >> request for which the server has already generated a success =20 >> response >> within the last 10 seconds, the server MUST retransmit the same >> success response. One way for a server to do this is to =20 >> remember all >> transaction IDs received over UDP and their corresponding =20 >> responses >> in the last 10 seconds. >> For short-lived TURN allocations, the 10-second timer is probably =20 >> pointless, even though 3489bis requires it. For long-lived =20 >> allocations (days or weeks or even months), the timer might become =20= >> important -- I haven't worked out the math. In either case, I =20 >> think the two documents should be consistent. >> - Philip > > --=20 > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 13 10:38:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2q8Y-0006OC-KH; Thu, 13 Dec 2007 10:38:10 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2q8Y-0006O6-2M for behave-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 10:38:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2q8X-0006Ny-Of for behave@ietf.org; Thu, 13 Dec 2007 10:38:09 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2q8W-00073c-4C for behave@ietf.org; Thu, 13 Dec 2007 10:38:09 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBDFbqT8024621 for ; Thu, 13 Dec 2007 17:38:06 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 17:38:03 +0200 Received: from esdhcp04083.research.nokia.com ([172.21.40.83]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 17:38:02 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] TURN Issue #4: Port Adjacency Date: Thu, 13 Dec 2007 17:38:05 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <4759CC2B.9050206@cisco.com> In-Reply-To: <4759CC2B.9050206@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200712131738.05970.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 13 Dec 2007 15:38:02.0869 (UTC) FILETIME=[25D1C250:01C83D9E] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Le Saturday 08 December 2007 00:41:47 ext Jonathan Rosenberg, vous avez=20 =E9crit=A0: > TURN allows a client to request an even port, and along with it, ask the > TURN server to allocate the odd port one higher. However, the spec > currently has the following confusing words in it: > > As such, it is a request for the server to allocate an even > port whose next higher port is also available, and furthermore, a > request for the server to not allocate that one higher port to any > other request except for one that asks for that port explicitly. The > server can honor this request for adjacency at its discretion. The > only constraint is that the allocated port has to be even. To restate my preference, I'd rather ditch the feature completely. =46irst, it puts an extra incentive for people to use TURN as the default=20 candidate, which is not necessarily such a great idea. Second, it conflicts with the way the traditional sockets API allocates por= t=20 number on the server side: it allows you to request "any" available port, o= r=20 one specific port, but "any" available even port. That practically means an= y=20 TURN server implementation would have to reinvent a port allocation schema= =20 bypassing the OS one, which sounds bad. Futhermore, this is bound to=20 introduce problems if the TURN server runs any other service using dynamic= =20 port numbers as well (FTP data, SOCKS, ...). Not a show-stopper, but an annoyance anyway. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 13 10:59:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2qSw-0008RP-Lp; Thu, 13 Dec 2007 10:59:14 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2qSv-0008RK-Ir for behave-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 10:59:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2qSv-0008RC-8z for behave@ietf.org; Thu, 13 Dec 2007 10:59:13 -0500 Received: from server.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2qSt-0007bH-Oy for behave@ietf.org; Thu, 13 Dec 2007 10:59:13 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id 1D651D9D403A; Thu, 13 Dec 2007 07:59:11 -0800 (PST) Received: from [192.168.1.3] (c-24-4-253-5.hsd1.ca.comcast.net [24.4.253.5]) by server.implementers.org (Postfix) with ESMTP id CE350D9D4038; Thu, 13 Dec 2007 07:59:08 -0800 (PST) Message-ID: <476156CC.2040902@acm.org> Date: Thu, 13 Dec 2007 07:59:08 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071008) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [BEHAVE] TURN Issue #1: Bandwidth Param References: <47599BE6.9090903@cisco.com> <4759AFD5.7030200@acm.org> <4760B54A.1040508@cisco.com> In-Reply-To: <4760B54A.1040508@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Jonathan Rosenberg wrote: > inline: > > Marc Petit-Huguenin wrote: >> Jonathan Rosenberg wrote: >>> >>> Please comment if you are happy (or not) with keeping bandwidth with >>> these proposed semantics. >>> >> >> I am OK with keeping bandwidth, but I would like to add one thing. The >> problem with bandwidth is when TURN is used with ICE. A TURN allocation >> will be made but it will generally not be used excepted for connectivity >> checks (i.e. far less than the bandwidth that will be used for video). >> So most TURN servers used in an ICE environment will either >> oversubscribe or waste resources. > > That wouldn't be a problem, normally. > > So when a client uses ICE it would do the allocation and provide the > bandwidth that would be used if TURN is selected. If TURN is not > selected, the client will, after ICE completes, drop the allocation. > Thus, at any point in time, the allocations on the server will be all of > those that are actually using TURN, plus a small number (those that have > just arrived and for which TURN has not yet completed) that are only so > far doing ICE. Law of large numbers would argue that for any reasonable > server capacity, the overall capacity is dominated by the in-use > allocations and not the transient ones. > Yes, but it works only if the client drops the allocation and we do not have the deployment experience to know how the ICE endpoints will implement this. This can be added as an extension later if needed or a TURN server can collect statistics and guess the intent by inspecting the application data forwarded. -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 13 14:42:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2tws-0005ya-Ir; Thu, 13 Dec 2007 14:42:22 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2twr-0005yQ-A7 for behave-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 14:42:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2twq-0005yG-WF for behave@ietf.org; Thu, 13 Dec 2007 14:42:21 -0500 Received: from nz-out-0506.google.com ([64.233.162.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2twp-00077v-50 for behave@ietf.org; Thu, 13 Dec 2007 14:42:20 -0500 Received: by nz-out-0506.google.com with SMTP id n1so454488nzf.4 for ; Thu, 13 Dec 2007 11:42:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=5PcsRb1QwxCG9mE2d96++ezPncPc54dgF15fLTAtqVo=; b=sEZgH/y73GVIx3zAknpRyQ37Heyyotacct+vjV+QxUsU4cRGuOrpa1ApU4UHKh8v5sY50HjIuyw9FbbViI21BHUaTO9nX7JvqUgfrwHfFDKNgIPeN0Q7cmb0KLvDIU/FTNWx/zG4EUDNdQ2SjSGRNJOKI78dj+BZ9nd+SZb87Uo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=mVvkJaNwrnAVavWQHOVzzPVf54miZ65MAeECInY+b/yPI6zxOpOdR6xuAXbC054lYzcPUonFt4j5rzZyt48W3UVxVXUoMTLUv9F+gU9ftmUV7G8yqyX7ZHoiy3KNzZFc+wqwIgpmMk3s7nIfX8EXCLjA5WrN71eNzssTdmhpTXA= Received: by 10.142.148.7 with SMTP id v7mr1100561wfd.218.1197574937944; Thu, 13 Dec 2007 11:42:17 -0800 (PST) Received: by 10.142.52.6 with HTTP; Thu, 13 Dec 2007 11:42:17 -0800 (PST) Message-ID: Date: Thu, 13 Dec 2007 11:42:17 -0800 From: "Derek MacDonald" To: "Philip Matthews" Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages In-Reply-To: <9B05C6FD-FF8A-4472-966E-D13C8573A9BF@magma.ca> MIME-Version: 1.0 References: <4759D19B.50005@cisco.com> <4760B1A0.6080807@cisco.com> <9B05C6FD-FF8A-4472-966E-D13C8573A9BF@magma.ca> X-Google-Sender-Auth: 874a5e2fe1a15694 X-Spam-Score: 0.0 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1336352559==" Errors-To: behave-bounces@ietf.org --===============1336352559== Content-Type: multipart/alternative; boundary="----=_Part_30879_4055816.1197574937931" ------=_Part_30879_4055816.1197574937931 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Is the concern the # of channels that can be used over the lifetime of an allocation or the # of concurrent channels used in an allocation? I think that channel re-use is easier w/ ekr's proposal....let the client re-use the channel after no keep-alive traffic has been sent for twice the keepalive interval...don't know if we need this, but it could be done. If its # of concurrent channels...there are lots of state issues w/ 64 active channels in an allocation. >From an implementation perspective, the new framing approach is far superior. It doesn't require different encoding mechanisms of STUN packets..which would be *very* annoying. If we really have a use case for long-lived allocations, we need to solve it, not just make the pain twice as slow. -Derek On Dec 13, 2007 6:15 AM, Philip Matthews wrote: > I think this use-case might be real (well, not the put it in DNS > part...). I think that TURN clients might well want to do a single > allocation and use it for a long period of time. > > So I am somewhat opposed to making this change at all. I don't think > that any of the three advantages are strong, and I am worried about > cutting the number of channels in half. > > - Philip > > > On 12-Dec-07, at 23:14 , Jonathan Rosenberg wrote: > > > 32767 vs. 65535 is irrelevant for any SIP use cases we have to date. > > > > Where this is a potential issue, is the following. Lets say you are > > a client and go to your TURN server and get an ip address and port. > > You basically want to hold on to that IP address and port for a > > really long time. Think of it like a nailed up VPN. Sufficiently > > long that the client might want to publish its IP/port in DNS or > > something (obviously requiring SRV records). > > > > Now, the client can't run a server, but presuming some rendezvous > > mechanism, for each corresponding peer, it opens a permission, > > communicates with them, and then its done. Next day, a different > > peer, new permission created, etc. > > > > In that use case, the client will eventually burn through all 32767 > > channels, and obviously will do so in half the time it would if all > > 65535 were there. > > > > Now, I personally don't see this use case as being real, but I just > > wanted to point it out. > > > > -Jonathan R. > > > > Derek MacDonald wrote: > >> I like this change because it will simplify the implementation of > >> a client that uses both ICE/TURN as two modes of TURN/ICE packet > >> writing will no have to be supported. > >> I do not believe the reduction in the total # of channels is > >> relevant; 32767 channels is half of the available port space, > >> which is much more than an endpoint would expect from a shared > >> (enterprise) NAT. > >> The TURN server will probably run out of tuples well before the > >> client does. > >> -Derek > >> On Dec 7, 2007 3:04 PM, Jonathan Rosenberg >> > wrote: > >> This issue was not in my slides. It was brought up at the mike > >> in the > >> WG, and was discussed there. It was not discussed further at > >> the ad-hoc. > >> As of turn-05, we introduced a framing mechanism, which is a 4 > >> byte > >> header consisting of 2 bytes channel and 2-bytes length. This > >> framing > >> header precedes ALL packets sent between a client and its TURN > >> server, > >> including both application data and TURN messages themselves, > >> which are > >> sent on channel zero. > >> Ekr raised a question of why this header was needed for actual > >> TURN > >> messages. After all, he argued, we went through all this > >> trouble to make > >> STUN (and thus TURN) differentiatable from each other. Indeed, > >> others > >> noted that the framing header itself looks very similar to the > >> top 4 > >> bytes of the STUN message format anyway: > >> 0 1 > >> 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > >> 7 8 9 0 1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> +-+-+-+-+-+-+ > >> |0 0| STUN Message Type | Message > >> Length | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> +-+-+-+-+ > >> | Magic > >> Cookie | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> +-+-+-+-+ > >> > >> | | > >> | Transaction ID (96 > >> bits) | > >> > >> | | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> +-+-+-+-+ > >> and the proposed framing header: > >> 0 1 > >> 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > >> 7 8 9 0 1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> +-+-+-+-+ > >> | Channel | Message > >> Length | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> +-+-+-+-+ > >> So an alternative design is to make the framing header look like: > >> 0 1 > >> 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > >> 7 8 9 0 1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> +-+-+-+-+ > >> |1| Channel | Message > >> Length | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> +-+-+-+-+ > >> So that there are 15 bits of channel instead of 16. Placing a > >> 1 in that > >> position makes the framing header always a non-match for STUN > >> messages. > >> Thus, it would not be even needed to do the more complex matching > >> operations defined in STUN; a 1-bit check would do the job to > >> separate > >> out application data from STUN/TURN. > >> The benefits of this change would be: > >> 1. We would, once again, be able to run STUN and TURN on the > >> same > >> port on the server. As of turn-05 they MUST run on different > >> ports > >> because the framing header was unique to TURN. This could be a > >> feature > >> or a bug depending on your perspective: > >> FEATURE: TURN and STUN are actually very different; > >> using > >> separate ports would allow a firewall to block one and not the > >> other. > >> BUG: practically speaking separate ports doesnt help > >> since > >> with DNS the ports can be dynamic anyway. In addition, its > >> always good > >> to use fewer ports on a server. Also its weird that an > >> extension to a > >> protocol would run on a different port; that kind of tells you > >> its not > >> an extension. > >> 2. Reduces the size of TURN messages by 4 bytes. This is a > >> minor > >> benefit and the real one is having a single port. > >> 3. it'd be a little clearer to explain to people that TURN > >> is an > >> extension to STUN, rather than saying, TURN is a STUN > >> extension that is > >> run over a new framing header > >> The drawbacks of this change would be: > >> 1. cuts the number of channels in half > >> An alternative design would be to use the full 16 bits for > >> channel > >> numbers, and then rely on the full suite of STUN differentiation > >> techniques to demux. However, my preference in general is to > >> not do that > >> when its not actually needed. It complicates message > >> processing and I > >> don't think its worth it. 32767 channels is also a LOT for our > >> envisioned use cases. > >> This was somewhat inconclusive at the microphone. I'm > >> personally on the > >> fence and don't feel that strongly. I probably midly prefer > >> making this > >> change. > >> Please comment on whether you prefer this change or not. > >> Thanks, > >> Jonathan R. > >> -- > >> Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > >> Cisco Fellow Edison, NJ 08837 > >> Cisco, Voice Technology Group > >> jdrosen@cisco.com > >> http://www.jdrosen.net PHONE: (408) > >> 902-3084 > >> http://www.cisco.com > >> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www1.ietf.org/mailman/listinfo/behave > > > > -- > > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > > Cisco Fellow Edison, NJ 08837 > > Cisco, Voice Technology Group > > jdrosen@cisco.com > > http://www.jdrosen.net PHONE: (408) 902-3084 > > http://www.cisco.com > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www1.ietf.org/mailman/listinfo/behave > > > > ------=_Part_30879_4055816.1197574937931 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Is the concern the # of channels that can be used over the lifetime of an allocation or the # of concurrent channels used in an allocation?

I think that channel re-use is easier w/ ekr's proposal....let the client re-use the channel after no keep-alive traffic has been sent for twice the keepalive interval...don't know if we need this, but it could be done.  If its # of concurrent channels...there are lots of state issues w/ 64 active channels in an allocation.

From an implementation perspective, the new framing approach is far superior.  It doesn't require different encoding mechanisms of STUN packets..which would be *very* annoying. 

If we really have a use case for long-lived allocations, we need to solve it, not just make the pain twice as slow.

-Derek


On Dec 13, 2007 6:15 AM, Philip Matthews <philip_matthews@magma.ca> wrote:
I think this use-case might be real (well, not the put it in DNS
part...). I think that TURN clients might well want to do a single
allocation and use it for a long period of time.

So I am somewhat opposed to making this change at all. I don't think
that any of the three advantages are strong, and I am worried about
cutting the number of channels in half.

- Philip


On 12-Dec-07, at 23:14 , Jonathan Rosenberg wrote:

> 32767 vs. 65535 is irrelevant for any SIP use cases we have to date.
>
> Where this is a potential issue, is the following. Lets say you are
> a client and go to your TURN server and get an ip address and port.
> You basically want to hold on to that IP address and port for a
> really long time. Think of it like a nailed up VPN. Sufficiently
> long that the client might want to publish its IP/port in DNS or
> something (obviously requiring SRV records).
>
> Now, the client can't run a server, but presuming some rendezvous
> mechanism, for each corresponding peer, it opens a permission,
> communicates with them, and then its done. Next day, a different
> peer, new permission created, etc.
>
> In that use case, the client will eventually burn through all 32767
> channels, and obviously will do so in half the time it would if all
> 65535 were there.
>
> Now, I personally don't see this use case as being real, but I just
> wanted to point it out.
>
> -Jonathan R.
>
> Derek MacDonald wrote:
>> I like this change because it will simplify the implementation of
>> a client that uses both ICE/TURN as two modes of TURN/ICE packet
>> writing will no have to be supported.
>> I do not believe the reduction in the total # of channels is
>> relevant; 32767 channels is half of the available port space,
>> which is much more than an endpoint would expect from a shared
>> (enterprise) NAT.
>> The TURN server will probably run out of tuples well before the
>> client does.
>> -Derek
>>  On Dec 7, 2007 3:04 PM, Jonathan Rosenberg <jdrosen@cisco.com
>> <mailto:jdrosen@cisco.com>> wrote:
>>     This issue was not in my slides. It was brought up at the mike
>> in the
>>     WG, and was discussed there. It was not discussed further at
>> the ad-hoc.
>>     As of turn-05, we introduced a framing mechanism, which is a 4
>> byte
>>     header consisting of 2 bytes channel and 2-bytes length. This
>> framing
>>     header precedes ALL packets sent between a client and its TURN
>> server,
>>     including both application data and TURN messages themselves,
>> which are
>>     sent on channel zero.
>>     Ekr raised a question of why this header was needed for actual
>> TURN
>>     messages. After all, he argued, we went through all this
>> trouble to make
>>     STUN (and thus TURN) differentiatable from each other. Indeed,
>> others
>>     noted that the framing header itself looks very similar to the
>> top 4
>>     bytes of the STUN message format anyway:
>>             0                   1
>> 2                   3
>>             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
>> 7 8 9 0 1
>>               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>> +-+-+-+-+-+-+
>>            |0 0|     STUN Message Type     |         Message
>> Length        |
>>            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>> +-+-+-+-+
>>            |                         Magic
>> Cookie                             |
>>            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>> +-+-+-+-+
>>
>> |                                                               |
>>            |                     Transaction ID (96
>> bits)                     |
>>
>> |                                                               |
>>            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>> +-+-+-+-+
>>     and the proposed framing header:
>>             0                   1
>> 2                   3
>>             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
>> 7 8 9 0 1
>>            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>> +-+-+-+-+
>>            |        Channel                |         Message
>> Length           |
>>            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>> +-+-+-+-+
>>     So an alternative design is to make the framing header look like:
>>             0                   1
>> 2                   3
>>             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
>> 7 8 9 0 1
>>            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>> +-+-+-+-+
>>            |1|      Channel                |         Message
>> Length           |
>>            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>> +-+-+-+-+
>>     So that there are 15 bits of channel instead of 16. Placing a
>> 1 in that
>>     position makes the framing header always a non-match for STUN
>> messages.
>>     Thus, it would not be even needed to do the more complex matching
>>     operations defined in STUN; a 1-bit check would do the job to
>> separate
>>     out application data from STUN/TURN.
>>     The benefits of this change would be:
>>       1. We would, once again, be able to run STUN and TURN on the
>> same
>>     port on the server. As of turn-05 they MUST run on different
>> ports
>>     because the framing header was unique to TURN. This could be a
>> feature
>>     or a bug depending on your perspective:
>>              FEATURE: TURN and STUN are actually very different;
>> using
>>     separate ports would allow a firewall to block one and not the
>> other.
>>              BUG: practically speaking separate ports doesnt help
>> since
>>     with DNS the ports can be dynamic anyway. In addition, its
>> always good
>>     to use fewer ports on a server. Also its weird that an
>> extension to a
>>     protocol would run on a different port; that kind of tells you
>> its not
>>     an extension.
>>       2. Reduces the size of TURN messages by 4 bytes. This is a
>> minor
>>     benefit and the real one is having a single port.
>>       3. it'd be a little clearer to explain to people that TURN
>> is an
>>     extension to STUN, rather than saying, TURN is a STUN
>> extension that is
>>     run over a new framing header
>>     The drawbacks of this change would be:
>>       1. cuts the number of channels in half
>>     An alternative design would be to use the full 16 bits for
>> channel
>>     numbers, and then rely on the full suite of STUN differentiation
>>     techniques to demux. However, my preference in general is to
>> not do that
>>     when its not actually needed. It complicates message
>> processing and I
>>     don't think its worth it. 32767 channels is also a LOT for our
>>     envisioned use cases.
>>     This was somewhat inconclusive at the microphone. I'm
>> personally on the
>>     fence and don't feel that strongly. I probably midly prefer
>> making this
>>     change.
>>     Please comment on whether you prefer this change or not.
>>     Thanks,
>>     Jonathan R.
>>     --
>>     Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
>>     Cisco Fellow                                   Edison, NJ 08837
>>     Cisco, Voice Technology Group
>>     jdrosen@cisco.com <mailto:jdrosen@cisco.com>
>>     http://www.jdrosen.net                         PHONE: (408)
>> 902-3084
>>     http://www.cisco.com
>>     _______________________________________________
>>     Behave mailing list
>>     Behave@ietf.org <mailto:Behave@ietf.org>
>>     https://www1.ietf.org/mailman/listinfo/behave
>
> --
> Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
> Cisco Fellow                                   Edison, NJ 08837
> Cisco, Voice Technology Group
> jdrosen@cisco.com
> http://www.jdrosen.net                         PHONE: (408) 902-3084
> http://www.cisco.com
>
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org

------=_Part_30879_4055816.1197574937931-- --===============1336352559== 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 --===============1336352559==-- From behave-bounces@ietf.org Thu Dec 13 16:07:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2vGp-0004lO-9J; Thu, 13 Dec 2007 16:07:03 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2vGm-0004kp-QA for behave-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 16:07:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2vGm-0004kh-Fy for behave@ietf.org; Thu, 13 Dec 2007 16:07:00 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2vGj-0001cH-Ta for behave@ietf.org; Thu, 13 Dec 2007 16:07:00 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J2vGi-0000JA-2c; Thu, 13 Dec 2007 16:06:57 -0500 In-Reply-To: References: <4759D19B.50005@cisco.com> <4760B1A0.6080807@cisco.com> <9B05C6FD-FF8A-4472-966E-D13C8573A9BF@magma.ca> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <5D6A5A89-18B3-49A3-B852-EF0982730E35@magma.ca> From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages Date: Thu, 13 Dec 2007 16:06:54 -0500 To: "Derek MacDonald" X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: d094b18a574860cb9e2fe5fedfbcc179 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0412172601==" Errors-To: behave-bounces@ietf.org --===============0412172601== Content-Type: multipart/alternative; boundary=Apple-Mail-7-229482780 --Apple-Mail-7-229482780 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 13-Dec-07, at 14:42 , Derek MacDonald wrote: > Is the concern the # of channels that can be used over the lifetime > of an allocation or the # of concurrent channels used in an > allocation? The former (= # over total lifetime). I think it would be very hard for a client to keep even 32000 channels alive simultaneously. The design team working on NAT traversal for HIP, for example, is thinking about doing an allocation and essentially keep it alive forever as the node connected to various peers. A SIP node could do the same thing. > > > I think that channel re-use is easier w/ ekr's proposal....let the > client re-use the channel after no keep-alive traffic has been sent > for twice the keepalive interval...don't know if we need this, but > it could be done. If its # of concurrent channels...there are lots > of state issues w/ 64 active channels in an allocation. > > From an implementation perspective, the new framing approach is far > superior. It doesn't require different encoding mechanisms of STUN > packets..which would be *very* annoying. I guess I don't see this. Everything comes inside a channel, so you strip off the channel header and then direct the packet as appropriate. > > > If we really have a use case for long-lived allocations, we need to > solve it, not just make the pain twice as slow. Is solving it correctly worth the extra complexity? Right now, I am thinking that just making it a rare occurrence is good enough. > > > -Derek > > > On Dec 13, 2007 6:15 AM, Philip Matthews > wrote: > I think this use-case might be real (well, not the put it in DNS > part...). I think that TURN clients might well want to do a single > allocation and use it for a long period of time. > > So I am somewhat opposed to making this change at all. I don't think > that any of the three advantages are strong, and I am worried about > cutting the number of channels in half. > > - Philip > > > On 12-Dec-07, at 23:14 , Jonathan Rosenberg wrote: > > > 32767 vs. 65535 is irrelevant for any SIP use cases we have to date. > > > > Where this is a potential issue, is the following. Lets say you are > > a client and go to your TURN server and get an ip address and port. > > You basically want to hold on to that IP address and port for a > > really long time. Think of it like a nailed up VPN. Sufficiently > > long that the client might want to publish its IP/port in DNS or > > something (obviously requiring SRV records). > > > > Now, the client can't run a server, but presuming some rendezvous > > mechanism, for each corresponding peer, it opens a permission, > > communicates with them, and then its done. Next day, a different > > peer, new permission created, etc. > > > > In that use case, the client will eventually burn through all 32767 > > channels, and obviously will do so in half the time it would if all > > 65535 were there. > > > > Now, I personally don't see this use case as being real, but I just > > wanted to point it out. > > > > -Jonathan R. > > > > Derek MacDonald wrote: > >> I like this change because it will simplify the implementation of > >> a client that uses both ICE/TURN as two modes of TURN/ICE packet > >> writing will no have to be supported. > >> I do not believe the reduction in the total # of channels is > >> relevant; 32767 channels is half of the available port space, > >> which is much more than an endpoint would expect from a shared > >> (enterprise) NAT. > >> The TURN server will probably run out of tuples well before the > >> client does. > >> -Derek > >> On Dec 7, 2007 3:04 PM, Jonathan Rosenberg >> > wrote: > >> This issue was not in my slides. It was brought up at the mike > >> in the > >> WG, and was discussed there. It was not discussed further at > >> the ad-hoc. > >> As of turn-05, we introduced a framing mechanism, which is a 4 > >> byte > >> header consisting of 2 bytes channel and 2-bytes length. This > >> framing > >> header precedes ALL packets sent between a client and its TURN > >> server, > >> including both application data and TURN messages themselves, > >> which are > >> sent on channel zero. > >> Ekr raised a question of why this header was needed for actual > >> TURN > >> messages. After all, he argued, we went through all this > >> trouble to make > >> STUN (and thus TURN) differentiatable from each other. Indeed, > >> others > >> noted that the framing header itself looks very similar to the > >> top 4 > >> bytes of the STUN message format anyway: > >> 0 1 > >> 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > >> 7 8 9 0 1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> +-+-+-+-+-+-+ > >> |0 0| STUN Message Type | Message > >> Length | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> +-+-+-+-+ > >> | Magic > >> Cookie | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> +-+-+-+-+ > >> > >> | | > >> | Transaction ID (96 > >> bits) | > >> > >> | | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> +-+-+-+-+ > >> and the proposed framing header: > >> 0 1 > >> 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > >> 7 8 9 0 1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> +-+-+-+-+ > >> | Channel | Message > >> Length | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> +-+-+-+-+ > >> So an alternative design is to make the framing header look > like: > >> 0 1 > >> 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > >> 7 8 9 0 1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> +-+-+-+-+ > >> |1| Channel | Message > >> Length | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> +-+-+-+-+ > >> So that there are 15 bits of channel instead of 16. Placing a > >> 1 in that > >> position makes the framing header always a non-match for STUN > >> messages. > >> Thus, it would not be even needed to do the more complex > matching > >> operations defined in STUN; a 1-bit check would do the job to > >> separate > >> out application data from STUN/TURN. > >> The benefits of this change would be: > >> 1. We would, once again, be able to run STUN and TURN on the > >> same > >> port on the server. As of turn-05 they MUST run on different > >> ports > >> because the framing header was unique to TURN. This could be a > >> feature > >> or a bug depending on your perspective: > >> FEATURE: TURN and STUN are actually very different; > >> using > >> separate ports would allow a firewall to block one and not the > >> other. > >> BUG: practically speaking separate ports doesnt help > >> since > >> with DNS the ports can be dynamic anyway. In addition, its > >> always good > >> to use fewer ports on a server. Also its weird that an > >> extension to a > >> protocol would run on a different port; that kind of tells you > >> its not > >> an extension. > >> 2. Reduces the size of TURN messages by 4 bytes. This is a > >> minor > >> benefit and the real one is having a single port. > >> 3. it'd be a little clearer to explain to people that TURN > >> is an > >> extension to STUN, rather than saying, TURN is a STUN > >> extension that is > >> run over a new framing header > >> The drawbacks of this change would be: > >> 1. cuts the number of channels in half > >> An alternative design would be to use the full 16 bits for > >> channel > >> numbers, and then rely on the full suite of STUN > differentiation > >> techniques to demux. However, my preference in general is to > >> not do that > >> when its not actually needed. It complicates message > >> processing and I > >> don't think its worth it. 32767 channels is also a LOT for our > >> envisioned use cases. > >> This was somewhat inconclusive at the microphone. I'm > >> personally on the > >> fence and don't feel that strongly. I probably midly prefer > >> making this > >> change. > >> Please comment on whether you prefer this change or not. > >> Thanks, > >> Jonathan R. > >> -- > >> Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > >> Cisco Fellow Edison, NJ 08837 > >> Cisco, Voice Technology Group > >> jdrosen@cisco.com > >> http://www.jdrosen.net PHONE: (408) > >> 902-3084 > >> http://www.cisco.com > >> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www1.ietf.org/mailman/listinfo/behave > > > > -- > > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > > Cisco Fellow Edison, NJ 08837 > > Cisco, Voice Technology Group > > jdrosen@cisco.com > > http://www.jdrosen.net PHONE: (408) 902-3084 > > http://www.cisco.com > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www1.ietf.org/mailman/listinfo/behave > > > > --Apple-Mail-7-229482780 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On 13-Dec-07, at = 14:42 , Derek MacDonald wrote:

Is the = concern the # of channels that can be used over the lifetime of an = allocation or the # of concurrent channels used in an = allocation?

The former (=3D # over total = lifetime). I think it would be very hard for a client to keep even 32000 = channels alive simultaneously.

The design team working on = NAT traversal for HIP, for example, is thinking about doing an = allocation and essentially keep it alive forever as the node connected = to various peers. A SIP node could do the same = thing.=A0



I think that = channel re-use is easier w/ ekr's proposal....let the client re-use the = channel after no keep-alive traffic has been sent for twice the = keepalive interval...don't know if we need this, but it could be done.=A0 = If its # of concurrent channels...there are lots of state issues w/ 64 = active channels in an allocation.

=46rom an implementation = perspective, the new framing approach is far superior.=A0 It doesn't = require different encoding mechanisms of STUN packets..which would be = *very* annoying.=A0

I guess I don't see this. = Everything comes inside a channel, so you strip off the channel header = and then direct the packet as appropriate.



If we really have a use case for long-lived = allocations, we need to solve it, not just make the pain twice as slow. =

Is solving it correctly worth the extra = complexity?
Right now, I am thinking that just making it a = rare occurrence is good enough.



-Derek


On = Dec 13, 2007 6:15 AM, Philip Matthews <philip_matthews@magma.ca> = wrote:
I think this use-case might be real (well, not the put it in = DNS
part...). I think that TURN clients might well want to do a = single
allocation and use it for a long period of time.

So I = am somewhat opposed to making this change at all. I don't think
that = any of the three advantages are strong, and I am worried = about
cutting the number of channels in half.

- Philip


On 12-Dec-07, at 23:14 , Jonathan Rosenberg = wrote:

> 32767 vs. 65535 is irrelevant for any SIP use cases = we have to date.
>
> Where this is a potential issue, is the = following. Lets say you are
> a client and go to your TURN server = and get an ip address and port.
> You basically want to hold on = to that IP address and port for a
> really long time. Think of it = like a nailed up VPN. Sufficiently
> long that the client might = want to publish its IP/port in DNS or
> something (obviously = requiring SRV records).
>
> Now, the client can't run a = server, but presuming some rendezvous
> mechanism, for each = corresponding peer, it opens a permission,
> communicates with = them, and then its done. Next day, a different
> peer, new = permission created, etc.
>
> In that use case, the client = will eventually burn through all 32767
> channels, and obviously = will do so in half the time it would if all
> 65535 were there. =
>
> Now, I personally don't see this use case as being = real, but I just
> wanted to point it out.
>
> = -Jonathan R.
>
> Derek MacDonald wrote:
>> I like = this change because it will simplify the implementation of
>> = a client that uses both ICE/TURN as two modes of TURN/ICE = packet
>> writing will no have to be supported.
>> I = do not believe the reduction in the total # of channels is
>> = relevant; 32767 channels is half of the available port space, =
>> which is much more than an endpoint would expect from a = shared
>> (enterprise) NAT.
>> The TURN server will = probably run out of tuples well before the
>> client = does.
>> -Derek
>> =A0On Dec 7, 2007 3:04 PM, = Jonathan Rosenberg <jdrosen@cisco.com
>> = <mailto:jdrosen@cisco.com>> = wrote:
>> =A0 =A0 This issue was not in my slides. It was = brought up at the mike
>> in the
>> =A0 =A0 WG, and = was discussed there. It was not discussed further at
>> the = ad-hoc.
>> =A0 =A0 As of turn-05, we introduced a framing = mechanism, which is a 4
>> byte
>> =A0 =A0 header = consisting of 2 bytes channel and 2-bytes length. This
>> = framing
>> =A0 =A0 header precedes ALL packets sent between a = client and its TURN
>> server,
>> =A0 =A0 including = both application data and TURN messages themselves,
>> which = are
>> =A0 =A0 sent on channel zero.
>> =A0 =A0 Ekr = raised a question of why this header was needed for actual
>> = TURN
>> =A0 =A0 messages. After all, he argued, we went through = all this
>> trouble to make
>> =A0 =A0 STUN (and thus = TURN) differentiatable from each other. Indeed,
>> = others
>> =A0 =A0 noted that the framing header itself looks = very similar to the
>> top 4
>> =A0 =A0 bytes of the = STUN message format anyway:
>> =A0 =A0 =A0 =A0 =A0 =A0 0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 1
>> 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 3
>> =A0 =A0 =A0 =A0 =A0 =A0 0 1 2 3 4 5 6 7 8 9 0 1 2 = 3 4 5 6 7 8 9 0 1 2 3 4 5 6
>> 7 8 9 0 1
>> =A0 =A0 =A0 = =A0 =A0 =A0 =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- =
>> +-+-+-+-+-+-+
>> =A0 =A0 =A0 =A0 =A0 =A0|0 0| =A0 = =A0 STUN Message Type =A0 =A0 | =A0 =A0 =A0 =A0 Message
>> = Length =A0 =A0 =A0 =A0|
>> =A0 =A0 =A0 =A0 =A0 = =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>> = +-+-+-+-+
>> =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 Magic
>> Cookie =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>> =A0 =A0 =A0 =A0 =A0 = =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>> = +-+-+-+-+
>>
>> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 |
>> =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 Transaction ID (96
>> bits) =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 |
>>
>> | =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>> =A0 =A0 =A0 =A0 =A0 = =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>> = +-+-+-+-+
>> =A0 =A0 and the proposed framing = header:
>> =A0 =A0 =A0 =A0 =A0 =A0 0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 1
>> 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3 =
>> =A0 =A0 =A0 =A0 =A0 =A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 = 8 9 0 1 2 3 4 5 6
>> 7 8 9 0 1
>> =A0 =A0 =A0 =A0 =A0 = =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>> = +-+-+-+-+
>> =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0Channel =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 Message
>> Length = =A0 =A0 =A0 =A0 =A0 |
>> =A0 =A0 =A0 =A0 =A0 = =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>> = +-+-+-+-+
>> =A0 =A0 So an alternative design is to make the = framing header look like:
>> =A0 =A0 =A0 =A0 =A0 =A0 0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 1
>> 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 3
>> =A0 =A0 =A0 =A0 =A0 =A0 0 1 2 3 4 5 6 7 8 9 0 1 2 = 3 4 5 6 7 8 9 0 1 2 3 4 5 6
>> 7 8 9 0 1
>> =A0 =A0 =A0 = =A0 =A0 = =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>> = +-+-+-+-+
>> =A0 =A0 =A0 =A0 =A0 =A0|1| =A0 =A0 =A0Channel =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 Message
>> Length = =A0 =A0 =A0 =A0 =A0 |
>> =A0 =A0 =A0 =A0 =A0 = =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>> = +-+-+-+-+
>> =A0 =A0 So that there are 15 bits of channel = instead of 16. Placing a
>> 1 in that
>> =A0 =A0 = position makes the framing header always a non-match for = STUN
>> messages.
>> =A0 =A0 Thus, it would not be = even needed to do the more complex matching
>> =A0 =A0 = operations defined in STUN; a 1-bit check would do the job to =
>> separate
>> =A0 =A0 out application data from = STUN/TURN.
>> =A0 =A0 The benefits of this change would = be:
>> =A0 =A0 =A0 1. We would, once again, be able to run STUN = and TURN on the
>> same
>> =A0 =A0 port on the = server. As of turn-05 they MUST run on different
>> = ports
>> =A0 =A0 because the framing header was unique to TURN. = This could be a
>> feature
>> =A0 =A0 or a bug = depending on your perspective:
>> =A0 =A0 =A0 =A0 =A0 =A0 = =A0FEATURE: TURN and STUN are actually very different;
>> = using
>> =A0 =A0 separate ports would allow a firewall to block = one and not the
>> other.
>> =A0 =A0 =A0 =A0 =A0 =A0 = =A0BUG: practically speaking separate ports doesnt help
>> = since
>> =A0 =A0 with DNS the ports can be dynamic anyway. In = addition, its
>> always good
>> =A0 =A0 to use fewer = ports on a server. Also its weird that an
>> extension to = a
>> =A0 =A0 protocol would run on a different port; that kind = of tells you
>> its not
>> =A0 =A0 an = extension.
>> =A0 =A0 =A0 2. Reduces the size of TURN messages = by 4 bytes. This is a
>> minor
>> =A0 =A0 benefit and = the real one is having a single port.
>> =A0 =A0 =A0 3. it'd be = a little clearer to explain to people that TURN
>> is = an
>> =A0 =A0 extension to STUN, rather than saying, TURN is a = STUN
>> extension that is
>> =A0 =A0 run over a new = framing header
>> =A0 =A0 The drawbacks of this change would = be:
>> =A0 =A0 =A0 1. cuts the number of channels in = half
>> =A0 =A0 An alternative design would be to use the full = 16 bits for
>> channel
>> =A0 =A0 numbers, and then = rely on the full suite of STUN differentiation
>> =A0 =A0 = techniques to demux. However, my preference in general is to
>> = not do that
>> =A0 =A0 when its not actually needed. It = complicates message
>> processing and I
>> =A0 =A0 = don't think its worth it. 32767 channels is also a LOT for our =
>> =A0 =A0 envisioned use cases.
>> =A0 =A0 This was = somewhat inconclusive at the microphone. I'm
>> personally on = the
>> =A0 =A0 fence and don't feel that strongly. I probably = midly prefer
>> making this
>> =A0 =A0 = change.
>> =A0 =A0 Please comment on whether you prefer this = change or not.
>> =A0 =A0 Thanks,
>> =A0 =A0 Jonathan = R.
>> =A0 =A0 --
>> =A0 =A0 Jonathan D. Rosenberg, = Ph.D. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 499 Thornall St.
>> =A0= =A0 Cisco Fellow =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 Edison, NJ 08837
>> =A0 =A0 Cisco, Voice Technology = Group
>> =A0 =A0 jdrosen@cisco.com <mailto:jdrosen@cisco.com>
>> = =A0 =A0 http://www.jdrosen.net =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 PHONE: (408)
>> 902-3084
>> =A0 =A0= http://www.cisco.com
>> =A0 =A0 = _______________________________________________
>> =A0 =A0 = Behave mailing list
>> =A0 =A0 Behave@ietf.org <mailto:Behave@ietf.org>
>> =A0 = =A0 https://www1.ietf.org/mailman/listinfo/behave =
>
> --
> Jonathan D. Rosenberg, Ph.D. =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 499 Thornall St.
> Cisco Fellow =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Edison, NJ = 08837
> Cisco, Voice Technology Group
> jdrosen@cisco.com
> http://www.jdrosen.net =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 PHONE: (408) 902-3084
> http://www.cisco.com =
>
>
> = _______________________________________________
> Behave mailing = list
> Behave@ietf.org
> https://www1.ietf.org/mailman/listinfo/behave
>= ;



= = --Apple-Mail-7-229482780-- --===============0412172601== 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 --===============0412172601==-- From behave-bounces@ietf.org Thu Dec 13 16:40:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2vmr-0008EK-34; Thu, 13 Dec 2007 16:40:09 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2vmp-00085b-HC for behave-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 16:40:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2vmp-00085T-68 for behave@ietf.org; Thu, 13 Dec 2007 16:40:07 -0500 Received: from wr-out-0506.google.com ([64.233.184.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2vmn-0002iR-6B for behave@ietf.org; Thu, 13 Dec 2007 16:40:07 -0500 Received: by wr-out-0506.google.com with SMTP id 68so581943wra.13 for ; Thu, 13 Dec 2007 13:40:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=/yGHJPnD2NYoZeAZ4NQIAKmaPx0sa5idJPvCjW7Owcs=; b=OpqAYLBVWvq8DONKjH/GpjXENBUNDr6Lxa5YQg0bSA6eRarv0lh0afiaVIwH3pV1hZYX7FlaIetjX5lYKmfu0U6NgGu1rLkSzDS/BkUT+oTq40rLnRWddcfX1ybiw3TNPGLo0HqxmorqXKkFCnthQOtiDxfUGihOvIrbUVMLXRY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=lojBkgrsGxIaz/1gNCOi5FxNmBLkOSeGI5DdqjzdPfPv8R7Mv3hIckKPiRsvXAf/SOXIvGe8sV/X+9CXoMJrcOZgZUP6n+jUH2V8ICmeGG4+OIvexUy2Czb+OAEWl0aMHhZScAjNLjkqai0jLLx/ZvcNe61N4uLxzFFQ3yaVDic= Received: by 10.142.140.14 with SMTP id n14mr1201151wfd.192.1197582003414; Thu, 13 Dec 2007 13:40:03 -0800 (PST) Received: by 10.142.52.6 with HTTP; Thu, 13 Dec 2007 13:40:03 -0800 (PST) Message-ID: Date: Thu, 13 Dec 2007 13:40:03 -0800 From: "Derek MacDonald" To: "Philip Matthews" Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages In-Reply-To: <5D6A5A89-18B3-49A3-B852-EF0982730E35@magma.ca> MIME-Version: 1.0 References: <4759D19B.50005@cisco.com> <4760B1A0.6080807@cisco.com> <9B05C6FD-FF8A-4472-966E-D13C8573A9BF@magma.ca> <5D6A5A89-18B3-49A3-B852-EF0982730E35@magma.ca> X-Google-Sender-Auth: f73e105e7bc66418 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0989214461==" Errors-To: behave-bounces@ietf.org --===============0989214461== Content-Type: multipart/alternative; boundary="----=_Part_31248_23905090.1197582003425" ------=_Part_31248_23905090.1197582003425 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Inline. On Dec 13, 2007 1:06 PM, Philip Matthews wrote: > > On 13-Dec-07, at 14:42 , Derek MacDonald wrote: > > Is the concern the # of channels that can be used over the lifetime of an > allocation or the # of concurrent channels used in an allocation? > > > The former (= # over total lifetime). I think it would be very hard for a > client to keep even 32000 channels alive simultaneously. > > The design team working on NAT traversal for HIP, for example, is thinking > about doing an allocation and essentially keep it alive forever as the node > connected to various peers. A SIP node could do the same thing. > > > > I think that channel re-use is easier w/ ekr's proposal....let the client > re-use the channel after no keep-alive traffic has been sent for twice the > keepalive interval...don't know if we need this, but it could be done. If > its # of concurrent channels...there are lots of state issues w/ 64 active > channels in an allocation. > > From an implementation perspective, the new framing approach is far > superior. It doesn't require different encoding mechanisms of STUN > packets..which would be *very* annoying. > > > I guess I don't see this. Everything comes inside a channel, so you strip > off the channel header and then direct the packet as appropriate. > The pain is in the encoding side, not as mch for decoding. > > > > If we really have a use case for long-lived allocations, we need to solve > it, not just make the pain twice as slow. > > > Is solving it correctly worth the extra complexity? > Right now, I am thinking that just making it a rare occurrence is good > enough. > If it's going to be common enough to worry about, 1/2*common is not rare.... -Derek > > > > -Derek > > > On Dec 13, 2007 6:15 AM, Philip Matthews wrote: > > > I think this use-case might be real (well, not the put it in DNS > > part...). I think that TURN clients might well want to do a single > > allocation and use it for a long period of time. > > > > So I am somewhat opposed to making this change at all. I don't think > > that any of the three advantages are strong, and I am worried about > > cutting the number of channels in half. > > > > - Philip > > > > > > On 12-Dec-07, at 23:14 , Jonathan Rosenberg wrote: > > > > > 32767 vs. 65535 is irrelevant for any SIP use cases we have to date. > > > > > > Where this is a potential issue, is the following. Lets say you are > > > a client and go to your TURN server and get an ip address and port. > > > You basically want to hold on to that IP address and port for a > > > really long time. Think of it like a nailed up VPN. Sufficiently > > > long that the client might want to publish its IP/port in DNS or > > > something (obviously requiring SRV records). > > > > > > Now, the client can't run a server, but presuming some rendezvous > > > mechanism, for each corresponding peer, it opens a permission, > > > communicates with them, and then its done. Next day, a different > > > peer, new permission created, etc. > > > > > > In that use case, the client will eventually burn through all 32767 > > > channels, and obviously will do so in half the time it would if all > > > 65535 were there. > > > > > > Now, I personally don't see this use case as being real, but I just > > > wanted to point it out. > > > > > > -Jonathan R. > > > > > > Derek MacDonald wrote: > > >> I like this change because it will simplify the implementation of > > >> a client that uses both ICE/TURN as two modes of TURN/ICE packet > > >> writing will no have to be supported. > > >> I do not believe the reduction in the total # of channels is > > >> relevant; 32767 channels is half of the available port space, > > >> which is much more than an endpoint would expect from a shared > > >> (enterprise) NAT. > > >> The TURN server will probably run out of tuples well before the > > >> client does. > > >> -Derek > > >> On Dec 7, 2007 3:04 PM, Jonathan Rosenberg > >> > wrote: > > >> This issue was not in my slides. It was brought up at the mike > > >> in the > > >> WG, and was discussed there. It was not discussed further at > > >> the ad-hoc. > > >> As of turn-05, we introduced a framing mechanism, which is a 4 > > >> byte > > >> header consisting of 2 bytes channel and 2-bytes length. This > > >> framing > > >> header precedes ALL packets sent between a client and its TURN > > >> server, > > >> including both application data and TURN messages themselves, > > >> which are > > >> sent on channel zero. > > >> Ekr raised a question of why this header was needed for actual > > >> TURN > > >> messages. After all, he argued, we went through all this > > >> trouble to make > > >> STUN (and thus TURN) differentiatable from each other. Indeed, > > >> others > > >> noted that the framing header itself looks very similar to the > > >> top 4 > > >> bytes of the STUN message format anyway: > > >> 0 1 > > >> 2 3 > > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > > >> 7 8 9 0 1 > > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > >> +-+-+-+-+-+-+ > > >> |0 0| STUN Message Type | Message > > >> Length | > > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > >> +-+-+-+-+ > > >> | Magic > > >> Cookie | > > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > >> +-+-+-+-+ > > >> > > >> | | > > >> | Transaction ID (96 > > >> bits) | > > >> > > >> | | > > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > >> +-+-+-+-+ > > >> and the proposed framing header: > > >> 0 1 > > >> 2 3 > > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > > >> 7 8 9 0 1 > > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > >> +-+-+-+-+ > > >> | Channel | Message > > >> Length | > > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > >> +-+-+-+-+ > > >> So an alternative design is to make the framing header look like: > > >> 0 1 > > >> 2 3 > > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > > >> 7 8 9 0 1 > > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > >> +-+-+-+-+ > > >> |1| Channel | Message > > >> Length | > > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > >> +-+-+-+-+ > > >> So that there are 15 bits of channel instead of 16. Placing a > > >> 1 in that > > >> position makes the framing header always a non-match for STUN > > >> messages. > > >> Thus, it would not be even needed to do the more complex matching > > >> operations defined in STUN; a 1-bit check would do the job to > > >> separate > > >> out application data from STUN/TURN. > > >> The benefits of this change would be: > > >> 1. We would, once again, be able to run STUN and TURN on the > > >> same > > >> port on the server. As of turn-05 they MUST run on different > > >> ports > > >> because the framing header was unique to TURN. This could be a > > >> feature > > >> or a bug depending on your perspective: > > >> FEATURE: TURN and STUN are actually very different; > > >> using > > >> separate ports would allow a firewall to block one and not the > > >> other. > > >> BUG: practically speaking separate ports doesnt help > > >> since > > >> with DNS the ports can be dynamic anyway. In addition, its > > >> always good > > >> to use fewer ports on a server. Also its weird that an > > >> extension to a > > >> protocol would run on a different port; that kind of tells you > > >> its not > > >> an extension. > > >> 2. Reduces the size of TURN messages by 4 bytes. This is a > > >> minor > > >> benefit and the real one is having a single port. > > >> 3. it'd be a little clearer to explain to people that TURN > > >> is an > > >> extension to STUN, rather than saying, TURN is a STUN > > >> extension that is > > >> run over a new framing header > > >> The drawbacks of this change would be: > > >> 1. cuts the number of channels in half > > >> An alternative design would be to use the full 16 bits for > > >> channel > > >> numbers, and then rely on the full suite of STUN differentiation > > >> techniques to demux. However, my preference in general is to > > >> not do that > > >> when its not actually needed. It complicates message > > >> processing and I > > >> don't think its worth it. 32767 channels is also a LOT for our > > >> envisioned use cases. > > >> This was somewhat inconclusive at the microphone. I'm > > >> personally on the > > >> fence and don't feel that strongly. I probably midly prefer > > >> making this > > >> change. > > >> Please comment on whether you prefer this change or not. > > >> Thanks, > > >> Jonathan R. > > >> -- > > >> Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > > >> Cisco Fellow Edison, NJ 08837 > > >> Cisco, Voice Technology Group > > >> jdrosen@cisco.com > > >> http://www.jdrosen.net PHONE: (408) > > >> 902-3084 > > >> http://www.cisco.com > > >> _______________________________________________ > > >> Behave mailing list > > >> Behave@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/behave > > > > > > -- > > > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > > > Cisco Fellow Edison, NJ 08837 > > > Cisco, Voice Technology Group > > > jdrosen@cisco.com > > > http://www.jdrosen.net PHONE: (408) 902-3084 > > > http://www.cisco.com > > > > > > > > > _______________________________________________ > > > Behave mailing list > > > Behave@ietf.org > > > https://www1.ietf.org/mailman/listinfo/behave > > > > > > > > > ------=_Part_31248_23905090.1197582003425 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Inline.

On Dec 13, 2007 1:06 PM, Philip Matthews <philip_matthews@magma.ca> wrote:

On 13-Dec-07, at 14:42 , Derek MacDonald wrote:

Is the concern the # of channels that can be used over the lifetime of an allocation or the # of concurrent channels used in an allocation?

The former (= # over total lifetime). I think it would be very hard for a client to keep even 32000 channels alive simultaneously.

The design team working on NAT traversal for HIP, for example, is thinking about doing an allocation and essentially keep it alive forever as the node connected to various peers. A SIP node could do the same thing. 



I think that channel re-use is easier w/ ekr's proposal....let the client re-use the channel after no keep-alive traffic has been sent for twice the keepalive interval...don't know if we need this, but it could be done.  If its # of concurrent channels...there are lots of state issues w/ 64 active channels in an allocation.

From an implementation perspective, the new framing approach is far superior.  It doesn't require different encoding mechanisms of STUN packets..which would be *very* annoying. 

I guess I don't see this. Everything comes inside a channel, so you strip off the channel header and then direct the packet as appropriate.

The pain is in the encoding side, not as mch for decoding.



If we really have a use case for long-lived allocations, we need to solve it, not just make the pain twice as slow.

Is solving it correctly worth the extra complexity?
Right now, I am thinking that just making it a rare occurrence is good enough.

If it's going to be common enough to worry about, 1/2*common is not rare....

-Derek



-Derek


On Dec 13, 2007 6:15 AM, Philip Matthews < philip_matthews@magma.ca> wrote:
I think this use-case might be real (well, not the put it in DNS
part...). I think that TURN clients might well want to do a single
allocation and use it for a long period of time.

So I am somewhat opposed to making this change at all. I don't think
that any of the three advantages are strong, and I am worried about
cutting the number of channels in half.

- Philip


On 12-Dec-07, at 23:14 , Jonathan Rosenberg wrote:

> 32767 vs. 65535 is irrelevant for any SIP use cases we have to date.
>
> Where this is a potential issue, is the following. Lets say you are
> a client and go to your TURN server and get an ip address and port.
> You basically want to hold on to that IP address and port for a
> really long time. Think of it like a nailed up VPN. Sufficiently
> long that the client might want to publish its IP/port in DNS or
> something (obviously requiring SRV records).
>
> Now, the client can't run a server, but presuming some rendezvous
> mechanism, for each corresponding peer, it opens a permission,
> communicates with them, and then its done. Next day, a different
> peer, new permission created, etc.
>
> In that use case, the client will eventually burn through all 32767
> channels, and obviously will do so in half the time it would if all
> 65535 were there.
>
> Now, I personally don't see this use case as being real, but I just
> wanted to point it out.
>
> -Jonathan R.
>
> Derek MacDonald wrote:
>> I like this change because it will simplify the implementation of
>> a client that uses both ICE/TURN as two modes of TURN/ICE packet
>> writing will no have to be supported.
>> I do not believe the reduction in the total # of channels is
>> relevant; 32767 channels is half of the available port space,
>> which is much more than an endpoint would expect from a shared
>> (enterprise) NAT.
>> The TURN server will probably run out of tuples well before the
>> client does.
>> -Derek
>>  On Dec 7, 2007 3:04 PM, Jonathan Rosenberg < jdrosen@cisco.com
>> <mailto:jdrosen@cisco.com>> wrote:
>>     This issue was not in my slides. It was brought up at the mike
>> in the
>>     WG, and was discussed there. It was not discussed further at
>> the ad-hoc.
>>     As of turn-05, we introduced a framing mechanism, which is a 4
>> byte
>>     header consisting of 2 bytes channel and 2-bytes length. This
>> framing
>>     header precedes ALL packets sent between a client and its TURN
>> server,
>>     including both application data and TURN messages themselves,
>> which are
>>     sent on channel zero.
>>     Ekr raised a question of why this header was needed for actual
>> TURN
>>     messages. After all, he argued, we went through all this
>> trouble to make
>>     STUN (and thus TURN) differentiatable from each other. Indeed,
>> others
>>     noted that the framing header itself looks very similar to the
>> top 4
>>     bytes of the STUN message format anyway:
>>             0                   1
>> 2                   3
>>             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
>> 7 8 9 0 1
>>               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>> +-+-+-+-+-+-+
>>            |0 0|     STUN Message Type     |         Message
>> Length        |
>>            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>> +-+-+-+-+
>>            |                         Magic
>> Cookie                             |
>>            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>> +-+-+-+-+
>>
>> |                                                               |
>>            |                     Transaction ID (96
>> bits)                     |
>>
>> |                                                               |
>>            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>> +-+-+-+-+
>>     and the proposed framing header:
>>             0                   1
>> 2                   3
>>             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
>> 7 8 9 0 1
>>            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>> +-+-+-+-+
>>            |        Channel                |         Message
>> Length           |
>>            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>> +-+-+-+-+
>>     So an alternative design is to make the framing header look like:
>>             0                   1
>> 2                   3
>>             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
>> 7 8 9 0 1
>>            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>> +-+-+-+-+
>>            |1|      Channel                |         Message
>> Length           |
>>            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>> +-+-+-+-+
>>     So that there are 15 bits of channel instead of 16. Placing a
>> 1 in that
>>     position makes the framing header always a non-match for STUN
>> messages.
>>     Thus, it would not be even needed to do the more complex matching
>>     operations defined in STUN; a 1-bit check would do the job to
>> separate
>>     out application data from STUN/TURN.
>>     The benefits of this change would be:
>>       1. We would, once again, be able to run STUN and TURN on the
>> same
>>     port on the server. As of turn-05 they MUST run on different
>> ports
>>     because the framing header was unique to TURN. This could be a
>> feature
>>     or a bug depending on your perspective:
>>              FEATURE: TURN and STUN are actually very different;
>> using
>>     separate ports would allow a firewall to block one and not the
>> other.
>>              BUG: practically speaking separate ports doesnt help
>> since
>>     with DNS the ports can be dynamic anyway. In addition, its
>> always good
>>     to use fewer ports on a server. Also its weird that an
>> extension to a
>>     protocol would run on a different port; that kind of tells you
>> its not
>>     an extension.
>>       2. Reduces the size of TURN messages by 4 bytes. This is a
>> minor
>>     benefit and the real one is having a single port.
>>       3. it'd be a little clearer to explain to people that TURN
>> is an
>>     extension to STUN, rather than saying, TURN is a STUN
>> extension that is
>>     run over a new framing header
>>     The drawbacks of this change would be:
>>       1. cuts the number of channels in half
>>     An alternative design would be to use the full 16 bits for
>> channel
>>     numbers, and then rely on the full suite of STUN differentiation
>>     techniques to demux. However, my preference in general is to
>> not do that
>>     when its not actually needed. It complicates message
>> processing and I
>>     don't think its worth it. 32767 channels is also a LOT for our
>>     envisioned use cases.
>>     This was somewhat inconclusive at the microphone. I'm
>> personally on the
>>     fence and don't feel that strongly. I probably midly prefer
>> making this
>>     change.
>>     Please comment on whether you prefer this change or not.
>>     Thanks,
>>     Jonathan R.
>>     --
>>     Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
>>     Cisco Fellow                                   Edison, NJ 08837
>>     Cisco, Voice Technology Group
>>     jdrosen@cisco.com <mailto:jdrosen@cisco.com>
>>     http://www.jdrosen.net                         PHONE: (408)
>> 902-3084
>>     http://www.cisco.com
>>     _______________________________________________
>>     Behave mailing list
>>     Behave@ietf.org <mailto:Behave@ietf.org>
>>     https://www1.ietf.org/mailman/listinfo/behave
>
> --
> Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
> Cisco Fellow                                   Edison, NJ 08837
> Cisco, Voice Technology Group
> jdrosen@cisco.com
> http://www.jdrosen.net                         PHONE: (408) 902-3084
> http://www.cisco.com
>
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org



------=_Part_31248_23905090.1197582003425-- --===============0989214461== 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 --===============0989214461==-- From behave-bounces@ietf.org Thu Dec 13 17:29:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2wYM-0001yo-0O; Thu, 13 Dec 2007 17:29:14 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J2wYK-0001yc-5G for behave-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 17:29:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2wYJ-0001yQ-Rf for behave@ietf.org; Thu, 13 Dec 2007 17:29:11 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-08.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2wYI-0004KC-KU for behave@ietf.org; Thu, 13 Dec 2007 17:29:11 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-08.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J2wYI-0004Fk-1E; Thu, 13 Dec 2007 17:29:10 -0500 In-Reply-To: References: <4759D19B.50005@cisco.com> <4760B1A0.6080807@cisco.com> <9B05C6FD-FF8A-4472-966E-D13C8573A9BF@magma.ca> <5D6A5A89-18B3-49A3-B852-EF0982730E35@magma.ca> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages Date: Thu, 13 Dec 2007 17:29:09 -0500 To: "Derek MacDonald" X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I still don't really see the argument for this approach, but I will note that if we change the approach to use "11" as the initial two bits, then we are only throwing away 16535 channels, rather than 32767. Given this, perhaps it is worthwhile finding a way to reuse old channel numbers. - Philip On 13-Dec-07, at 16:40 , Derek MacDonald wrote: > Inline. > > On Dec 13, 2007 1:06 PM, Philip Matthews > wrote: > > On 13-Dec-07, at 14:42 , Derek MacDonald wrote: > >> Is the concern the # of channels that can be used over the >> lifetime of an allocation or the # of concurrent channels used in >> an allocation? > > The former (= # over total lifetime). I think it would be very hard > for a client to keep even 32000 channels alive simultaneously. > > The design team working on NAT traversal for HIP, for example, is > thinking about doing an allocation and essentially keep it alive > forever as the node connected to various peers. A SIP node could do > the same thing. > >> >> >> I think that channel re-use is easier w/ ekr's proposal....let the >> client re-use the channel after no keep-alive traffic has been >> sent for twice the keepalive interval...don't know if we need >> this, but it could be done. If its # of concurrent >> channels...there are lots of state issues w/ 64 active channels in >> an allocation. >> >> From an implementation perspective, the new framing approach is >> far superior. It doesn't require different encoding mechanisms of >> STUN packets..which would be *very* annoying. > > I guess I don't see this. Everything comes inside a channel, so you > strip off the channel header and then direct the packet as > appropriate. > > The pain is in the encoding side, not as mch for decoding. > >> >> >> If we really have a use case for long-lived allocations, we need >> to solve it, not just make the pain twice as slow. > > Is solving it correctly worth the extra complexity? > Right now, I am thinking that just making it a rare occurrence is > good enough. > > If it's going to be common enough to worry about, 1/2*common is not > rare.... > > -Derek > >> >> >> -Derek >> >> >> On Dec 13, 2007 6:15 AM, Philip Matthews < >> philip_matthews@magma.ca> wrote: >> I think this use-case might be real (well, not the put it in DNS >> part...). I think that TURN clients might well want to do a single >> allocation and use it for a long period of time. >> >> So I am somewhat opposed to making this change at all. I don't think >> that any of the three advantages are strong, and I am worried about >> cutting the number of channels in half. >> >> - Philip >> >> >> On 12-Dec-07, at 23:14 , Jonathan Rosenberg wrote: >> >> > 32767 vs. 65535 is irrelevant for any SIP use cases we have to >> date. >> > >> > Where this is a potential issue, is the following. Lets say you are >> > a client and go to your TURN server and get an ip address and port. >> > You basically want to hold on to that IP address and port for a >> > really long time. Think of it like a nailed up VPN. Sufficiently >> > long that the client might want to publish its IP/port in DNS or >> > something (obviously requiring SRV records). >> > >> > Now, the client can't run a server, but presuming some rendezvous >> > mechanism, for each corresponding peer, it opens a permission, >> > communicates with them, and then its done. Next day, a different >> > peer, new permission created, etc. >> > >> > In that use case, the client will eventually burn through all 32767 >> > channels, and obviously will do so in half the time it would if all >> > 65535 were there. >> > >> > Now, I personally don't see this use case as being real, but I just >> > wanted to point it out. >> > >> > -Jonathan R. >> > >> > Derek MacDonald wrote: >> >> I like this change because it will simplify the implementation of >> >> a client that uses both ICE/TURN as two modes of TURN/ICE packet >> >> writing will no have to be supported. >> >> I do not believe the reduction in the total # of channels is >> >> relevant; 32767 channels is half of the available port space, >> >> which is much more than an endpoint would expect from a shared >> >> (enterprise) NAT. >> >> The TURN server will probably run out of tuples well before the >> >> client does. >> >> -Derek >> >> On Dec 7, 2007 3:04 PM, Jonathan Rosenberg < jdrosen@cisco.com >> >> > wrote: >> >> This issue was not in my slides. It was brought up at the mike >> >> in the >> >> WG, and was discussed there. It was not discussed further at >> >> the ad-hoc. >> >> As of turn-05, we introduced a framing mechanism, which is a 4 >> >> byte >> >> header consisting of 2 bytes channel and 2-bytes length. This >> >> framing >> >> header precedes ALL packets sent between a client and its TURN >> >> server, >> >> including both application data and TURN messages themselves, >> >> which are >> >> sent on channel zero. >> >> Ekr raised a question of why this header was needed for actual >> >> TURN >> >> messages. After all, he argued, we went through all this >> >> trouble to make >> >> STUN (and thus TURN) differentiatable from each other. Indeed, >> >> others >> >> noted that the framing header itself looks very similar to the >> >> top 4 >> >> bytes of the STUN message format anyway: >> >> 0 1 >> >> 2 3 >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 >> >> 7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> >> +-+-+-+-+-+-+ >> >> |0 0| STUN Message Type | Message >> >> Length | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+- >> >> +-+-+-+-+ >> >> | Magic >> >> Cookie | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+- >> >> +-+-+-+-+ >> >> >> >> | | >> >> | Transaction ID (96 >> >> bits) | >> >> >> >> | | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+- >> >> +-+-+-+-+ >> >> and the proposed framing header: >> >> 0 1 >> >> 2 3 >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 >> >> 7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+- >> >> +-+-+-+-+ >> >> | Channel | Message >> >> Length | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+- >> >> +-+-+-+-+ >> >> So an alternative design is to make the framing header look >> like: >> >> 0 1 >> >> 2 3 >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 >> >> 7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+- >> >> +-+-+-+-+ >> >> |1| Channel | Message >> >> Length | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+- >> >> +-+-+-+-+ >> >> So that there are 15 bits of channel instead of 16. Placing a >> >> 1 in that >> >> position makes the framing header always a non-match for STUN >> >> messages. >> >> Thus, it would not be even needed to do the more complex >> matching >> >> operations defined in STUN; a 1-bit check would do the job to >> >> separate >> >> out application data from STUN/TURN. >> >> The benefits of this change would be: >> >> 1. We would, once again, be able to run STUN and TURN on the >> >> same >> >> port on the server. As of turn-05 they MUST run on different >> >> ports >> >> because the framing header was unique to TURN. This could be a >> >> feature >> >> or a bug depending on your perspective: >> >> FEATURE: TURN and STUN are actually very different; >> >> using >> >> separate ports would allow a firewall to block one and not the >> >> other. >> >> BUG: practically speaking separate ports doesnt help >> >> since >> >> with DNS the ports can be dynamic anyway. In addition, its >> >> always good >> >> to use fewer ports on a server. Also its weird that an >> >> extension to a >> >> protocol would run on a different port; that kind of tells you >> >> its not >> >> an extension. >> >> 2. Reduces the size of TURN messages by 4 bytes. This is a >> >> minor >> >> benefit and the real one is having a single port. >> >> 3. it'd be a little clearer to explain to people that TURN >> >> is an >> >> extension to STUN, rather than saying, TURN is a STUN >> >> extension that is >> >> run over a new framing header >> >> The drawbacks of this change would be: >> >> 1. cuts the number of channels in half >> >> An alternative design would be to use the full 16 bits for >> >> channel >> >> numbers, and then rely on the full suite of STUN >> differentiation >> >> techniques to demux. However, my preference in general is to >> >> not do that >> >> when its not actually needed. It complicates message >> >> processing and I >> >> don't think its worth it. 32767 channels is also a LOT for our >> >> envisioned use cases. >> >> This was somewhat inconclusive at the microphone. I'm >> >> personally on the >> >> fence and don't feel that strongly. I probably midly prefer >> >> making this >> >> change. >> >> Please comment on whether you prefer this change or not. >> >> Thanks, >> >> Jonathan R. >> >> -- >> >> Jonathan D. Rosenberg, Ph.D. 499 Thornall >> St. >> >> Cisco Fellow Edison, NJ >> 08837 >> >> Cisco, Voice Technology Group >> >> jdrosen@cisco.com >> >> http://www.jdrosen.net PHONE: (408) >> >> 902-3084 >> >> http://www.cisco.com >> >> _______________________________________________ >> >> Behave mailing list >> >> Behave@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/behave >> > >> > -- >> > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. >> > Cisco Fellow Edison, NJ 08837 >> > Cisco, Voice Technology Group >> > jdrosen@cisco.com >> > http://www.jdrosen.net PHONE: (408) >> 902-3084 >> > http://www.cisco.com >> > >> > >> > _______________________________________________ >> > Behave mailing list >> > Behave@ietf.org >> > https://www1.ietf.org/mailman/listinfo/behave >> > >> >> > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 13 23:40:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J32M0-0007ns-OS; Thu, 13 Dec 2007 23:40:52 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J32Ly-0007m7-WA for behave-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 23:40:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J32Ly-0007lw-KW for behave@ietf.org; Thu, 13 Dec 2007 23:40:50 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J32Ly-0003M7-90 for behave@ietf.org; Thu, 13 Dec 2007 23:40:50 -0500 X-IronPort-AV: E=Sophos;i="4.24,164,1196636400"; d="scan'208";a="861515" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 14 Dec 2007 05:40:49 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBE4entH021264 for ; Fri, 14 Dec 2007 05:40:49 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBE4enmc009882 for ; Fri, 14 Dec 2007 04:40:49 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 05:40:48 +0100 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 05:40:48 +0100 Message-ID: <47620977.8030006@cisco.com> Date: Thu, 13 Dec 2007 23:41:27 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Dec 2007 04:40:48.0730 (UTC) FILETIME=[7FA76BA0:01C83E0B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=788; t=1197607249; x=1198471249; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20TURN=20Call=20Scheduled |Sender:=20; bh=q+vh2tNZV/8mv6yaLlt/4lh5PBFy1afgopxB5B/mMoE=; b=UejwjRUxwFztFHsRX2BZ+AIx6L/TGjqaJ/Zj4/lIyPl7LcTD0wBXQJ67KS XPMqiqOgPGkMjYC+yA2i4+vKpRSDqhTytHlqgcVf8vJC2X2LNRoOHg9iJKNf wsy3yeF0Jr; Authentication-Results: ams-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [BEHAVE] TURN Call Scheduled X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org The TURN open issues resolution call has been scheduled. It is: Thursday, December 20, 4-5pm EST Dial in: +1 408-902-3084 ID: 220394728 Web share: meetings.cisco.com Please let me know if you plan on attending. On this call we will go through each of the open issues and summarize the conclusion else try to resolve it on the call if it is still open. As always, all results will be posted to the mailer, so please only dial in if you plan on actively participating. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 13 23:55:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J32Zv-0005GA-1z; Thu, 13 Dec 2007 23:55:15 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J32Zu-0005G5-0s for behave-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 23:55:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J32Zt-0005Fx-NP for behave@ietf.org; Thu, 13 Dec 2007 23:55:13 -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 1J32Zr-00036Y-GY for behave@ietf.org; Thu, 13 Dec 2007 23:55:13 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-1.cisco.com with ESMTP; 13 Dec 2007 20:55:11 -0800 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 lBE4tAT6032067; Thu, 13 Dec 2007 20:55:10 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id lBE4tAms015728; Fri, 14 Dec 2007 04:55:10 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 20:55:10 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 20:55:09 -0800 Message-ID: <47620CD5.3010304@cisco.com> Date: Thu, 13 Dec 2007 23:55:49 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages References: <4759D19B.50005@cisco.com> <4760B1A0.6080807@cisco.com> <9B05C6FD-FF8A-4472-966E-D13C8573A9BF@magma.ca> <5D6A5A89-18B3-49A3-B852-EF0982730E35@magma.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Dec 2007 04:55:09.0999 (UTC) FILETIME=[8102A3F0:01C83E0D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2829; t=1197608110; x=1198472110; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20Issue=20#6=3A=20Frami ng=20header=20for=20actual=20TURN=20messages |Sender:=20; bh=lsv7pEAeDeTpN33fWwMfqTu6wWHWTm604oifLI+1RVk=; b=ihZsV5YqFWpjwanGElNAjOYTJn1NWj87F3kMTYy5SF6sDS8zOoAEexhxFV +uCJtvJIlsBZqyYb3dV4oB2uytCIGAF+F3B6/Eq8WEfWlHIMJ1jXHcCLJjA8 OTy/dVv2JH; Authentication-Results: sj-dkim-8; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Philip Matthews wrote: > I still don't really see the argument for this approach, but I will note > that if we change the approach to use "11" as the initial two bits, then > we are only throwing away 16535 channels, rather than 32767. How is that? I must be missing something. This would throw even more away since it leaves only 14 bits for channel ID. > > Given this, perhaps it is worthwhile finding a way to reuse old channel > numbers. I remain unconvinced in this use case really. THe main reason is that you STILL need some kind of rendezvous protocol before you can use the allocation with a new peer, and this rendezvous can provide the allocated IP and port anyway, so what is the big deal about using a new one for new peers when you run out of channels? Even in the HIP case, you are exchanging the allocated IP/port so I don't see the problem. I have thought about reuse of channel and it is possible. Fortunately the framing header allows us to get rid of the timing and race conditions that plagued set active destination. We'd steal a bit from the channel space and make this the 'flip' bit. For any new channel binding this value is zero in ChannelBind and zero in the framing header. At some point later the client can change the binding. To do that, it sends a new CHannelBind request for the same channel, but a different peer IP/port. It also flips the value of the flip bit (from zero to one). Once the client gets a response, it can begin sending on the new channel, but does so with the value of the flip bit changed (now a 1) in the framing header. When the server gets data on the channel, it knows to send to the old peer while the flip bit is zero, and the new peer when its one. Similarly, when the server sends to the client, it sends with the flip bit of zero prior to receipt of the new CHannelBind, and then afterwards, with a value of 1. Data from the old peer after the flip gets sent encapsulated. The client knows that data packets with flip bit zero mean the old peer, and a one mean new peer. The client would be limited in that it could not flip again for some duration (say one minute), to make sure any old packets in the network clear out. After a minute both client and server forget about the old remote peer. So, even though this is possible there is some complexity and I don't see the value. I do see the value in having a single port however and I think this makes the protocol simpler. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 13 23:59:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J32dt-0001Nn-Hy; Thu, 13 Dec 2007 23:59:21 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J32dr-0001Mu-S3 for behave-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 23:59:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J32dr-0001K7-ED for behave@ietf.org; Thu, 13 Dec 2007 23:59:19 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J32dp-00039d-5f for behave@ietf.org; Thu, 13 Dec 2007 23:59:19 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-2.cisco.com with ESMTP; 13 Dec 2007 20:59:15 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id lBE4xENB031457; Thu, 13 Dec 2007 20:59:14 -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 lBE4xAqP025011; Fri, 14 Dec 2007 04:59:10 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 20:59:10 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 20:59:09 -0800 Message-ID: <47620DC5.3070501@cisco.com> Date: Thu, 13 Dec 2007 23:59:49 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Marc Petit-Huguenin Subject: Re: [BEHAVE] TURN Issue #1: Bandwidth Param References: <47599BE6.9090903@cisco.com> <4759AFD5.7030200@acm.org> <4760B54A.1040508@cisco.com> <476156CC.2040902@acm.org> In-Reply-To: <476156CC.2040902@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Dec 2007 04:59:10.0015 (UTC) FILETIME=[10122CF0:01C83E0E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2370; t=1197608354; x=1198472354; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20Issue=20#1=3A=20Bandw idth=20Param |Sender:=20; bh=r+LpOgGsSvKzonUuREYUHEojJNbUv0O6Dh+jHBcRSu4=; b=NMj78ql5DZEGnBEhlCuksNKC/YS04AeqtV/vw3D0I4NWj+BfNMh7FlnyB6 M+8noPt60BjGryBOCkC/w4oHu+VwgvGhIOL1TMHrwbK5BeNFyRQMGDBvz1uS /XvOCYxCIr; Authentication-Results: sj-dkim-7; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Right - I was assuming that the client drops the allocation if it doesn't use it. If you want to assume non-cooperative clients (ones that don't drop their allocations when they don't use them), bandwidth anyway won't be useful. Clients might decide to just not use the 'this is actually ice' flag, since they have no incentive to do so, and you're right back in the same boat. -JOnathan R. Marc Petit-Huguenin wrote: > Jonathan Rosenberg wrote: >> inline: >> >> Marc Petit-Huguenin wrote: >>> Jonathan Rosenberg wrote: >>>> Please comment if you are happy (or not) with keeping bandwidth with >>>> these proposed semantics. >>>> >>> I am OK with keeping bandwidth, but I would like to add one thing. The >>> problem with bandwidth is when TURN is used with ICE. A TURN allocation >>> will be made but it will generally not be used excepted for connectivity >>> checks (i.e. far less than the bandwidth that will be used for video). >>> So most TURN servers used in an ICE environment will either >>> oversubscribe or waste resources. >> That wouldn't be a problem, normally. >> >> So when a client uses ICE it would do the allocation and provide the >> bandwidth that would be used if TURN is selected. If TURN is not >> selected, the client will, after ICE completes, drop the allocation. >> Thus, at any point in time, the allocations on the server will be all of >> those that are actually using TURN, plus a small number (those that have >> just arrived and for which TURN has not yet completed) that are only so >> far doing ICE. Law of large numbers would argue that for any reasonable >> server capacity, the overall capacity is dominated by the in-use >> allocations and not the transient ones. >> > > Yes, but it works only if the client drops the allocation and we do not > have the deployment experience to know how the ICE endpoints will > implement this. This can be added as an extension later if needed or a > TURN server can collect statistics and guess the intent by inspecting > the application data forwarded. > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 14 00:05:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J32jc-00085W-FU; Fri, 14 Dec 2007 00:05:16 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J32jb-0007x6-6Y for behave-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 00:05:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J32ja-0007wx-Sv for behave@ietf.org; Fri, 14 Dec 2007 00:05:14 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J32ja-0003Fs-Cz for behave@ietf.org; Fri, 14 Dec 2007 00:05:14 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 13 Dec 2007 21:05:13 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBE55Db7032544; Thu, 13 Dec 2007 21:05:13 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBE558CD024228; Fri, 14 Dec 2007 05:05:13 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 21:05:08 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 21:05:07 -0800 Message-ID: <47620F2B.4060200@cisco.com> Date: Fri, 14 Dec 2007 00:05:47 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Lars Eggert Subject: Re: [BEHAVE] TURN Issue #1: Bandwidth Param References: <47599BE6.9090903@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Dec 2007 05:05:08.0082 (UTC) FILETIME=[E57EDD20:01C83E0E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2959; t=1197608713; x=1198472713; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20Issue=20#1=3A=20Bandw idth=20Param |Sender:=20; bh=cdeJiSvlWbUnP0oTSPKPczHfYrrI4OJVjb6FnXAAXcg=; b=ZR+qEBwEaaHG7SUbrxutIywYAQF1YFD3Tpb6q0kVy5/SD55uTkJ7EmupFv tJgcxHLhuS0Qx4Rv+OIenKiV94ZSnXZU/ohSa0ppUrYehVon1MzNvkFvt3GE cJ+5dZMNrTSrrvOY0ZY7W659BBGG5kp84mNLApKcGI6PGS8kRzwY8=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Lars Eggert wrote: > On 2007-12-7, at 21:15, ext Jonathan Rosenberg wrote: >> Client MAY include bandwidth in a request. > > What exactly is bandwidth defined as? This is not trivial; see > draft-ietf-ippm-bw-capacity. We do need a crisp definition if this is to > work. Right - the plan was to take a leaky bucket definition from RSVP. > >> If present, it is a request from the client that the server forward >> traffic to and from the client such that the total in each direction >> will not be excess of this value. > > Do I read this correctly as a "please rate-limit me to X" option? What > incentive does a client have to send this? The presumption is that the server has a relationship with the client and is there to support a particular application (say, voip). And so, if the client includes the value the server is likely to honor it and not drop data below that rate. If the client includes nothing the server might choose to rate limit at a value that is below what the client actually needs. So the client is incented to include it. > >> Server MAY include a value in a response, even if there was not one in >> a request. The meaning of the value in the response, is that the >> server agrees to forward traffic to/from the client so long as it is >> below the bandwidth value. Any traffic above that value may be dropped >> by the server. > > But this doesn't tell the client all that much. Yes, if it stays below > the limit, it can be sure that the server doesn't rate-limit it, but > congestion on the path can happen before that rate is reached, i.e., the > client can't depend on it. And because the server may forward traffic > that exceeds this rate, the client has every incentive to see if it can > send more than the signaled rate. This parameter is really only primarily useful for fixed rate applications for voip. For variable rate I agree its largely useless. > >> If there is no value in the response, the server will relay traffic at >> best effort. Furthermore, there is never an absolute guarantee that >> the server will be able to relay data even if the usage is below the >> bandwidth parameter, and clients MUST be prepared for packet loss. Of >> course, there could be packet loss outside of the TURN server anyway. > > Right, this pretty much sums up my concerns. > > TURN isn't a QoS-signaling solution, so I'm all for removing this option. No, but TURN servers do provide a service (media relay of traffic) and it seems sensible for clients to ask for a particular level of service and be told if they get it or not. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 14 00:07:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J32lR-0004g3-HL; Fri, 14 Dec 2007 00:07:09 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J32lP-0004fu-Ma for behave-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 00:07:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J32lP-0004fm-9M for behave@ietf.org; Fri, 14 Dec 2007 00:07:07 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J32lO-0003lo-TL for behave@ietf.org; Fri, 14 Dec 2007 00:07:07 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 13 Dec 2007 21:07:06 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBE576Zu032264; Thu, 13 Dec 2007 21:07:06 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBE56hCZ025109; Fri, 14 Dec 2007 05:07:06 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 21:06:48 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 21:06:47 -0800 Message-ID: <47620F8F.2060606@cisco.com> Date: Fri, 14 Dec 2007 00:07:27 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Lars Eggert Subject: Re: [BEHAVE] TURN Issue #4: Port Adjacency References: <4759CC2B.9050206@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Dec 2007 05:06:47.0693 (UTC) FILETIME=[20DE4BD0:01C83E0F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1277; t=1197608826; x=1198472826; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20Issue=20#4=3A=20Port= 20Adjacency |Sender:=20; bh=2+k3XV1hPFvHHad3U5nH0taKoConGt+pMI9S96xJW0U=; b=KgTU9XrK7P3kKA9fPadbhD6+w8JqqLNotS9o0m0KwKjq3uYBNmctlXXcNl gKPYRGmRv5vY9AkyOZwlCEh/P64dkeZ+87d6q1GUxPZdaDYfTePYKgD2wM5R +uoGWPFsCI; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org The use case is communicating between an ICE agent and a non-ICE traditional Voip client, like a PSTN gateway. Those endpoints frequently implement the old original 1889 and do RTP and RTCP on adjacent ports. Since ICE recommends TURN as the default candidate, when communicating with these peers, we'd be able to get RTCP. WIthout this feature, RTCP will not work. There are still a LOT of endpoints in real deployment that assume RTP/RTCP port adjacency. -Jonathan R. Lars Eggert wrote: > On 2007-12-8, at 0:41, ext Jonathan Rosenberg wrote: >> TURN allows a client to request an even port, and along with it, ask >> the TURN server to allocate the odd port one higher. > > Given that we're about to recommend that end hosts implement port > randomization and most OSs do this already > (draft-ietf-tsvwg-port-randomization), this seems to be an anachronism. > So ditch it. > > (Or does anyone have a convincing use case?) > > Lars (as an individual) > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 14 00:10:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J32oI-0008QH-8H; Fri, 14 Dec 2007 00:10:06 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J32oG-0008HQ-1K for behave-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 00:10:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J32oF-0008Au-Ex for behave@ietf.org; Fri, 14 Dec 2007 00:10:03 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J32oE-0003pi-VO for behave@ietf.org; Fri, 14 Dec 2007 00:10:03 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 13 Dec 2007 21:10:02 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lBE5A2CR023706; Thu, 13 Dec 2007 21:10:02 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBE5A29N012432; Fri, 14 Dec 2007 05:10:02 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 21:10:02 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 21:10:01 -0800 Message-ID: <47621051.3020302@cisco.com> Date: Fri, 14 Dec 2007 00:10:41 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= Subject: Re: [BEHAVE] TURN Issue #4: Port Adjacency References: <4759CC2B.9050206@cisco.com> <200712131738.05970.remi.denis-courmont@nokia.com> In-Reply-To: <200712131738.05970.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 14 Dec 2007 05:10:02.0083 (UTC) FILETIME=[94BBDB30:01C83E0F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2566; t=1197609002; x=1198473002; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20Issue=20#4=3A=20Port= 20Adjacency |Sender:=20; bh=aVt16LQ4DXPrnhkot1VnrCYy6P6UZhA8DNOS8xw1ftE=; b=Zg5P0sP0FX6ZYCdxtN5d54FEUGvDUUXLYyeQBT+YHLIwpFeIg3/htM3JdW 9RjQnWnDnZbpO/0L+knR/c4c3roDkj+F8QZjDxFelYkxG3ZK+LO2PMbQDf/5 alNKO/EYWG; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org inline: Rémi Denis-Courmont wrote: > Le Saturday 08 December 2007 00:41:47 ext Jonathan Rosenberg, vous avez > écrit : >> TURN allows a client to request an even port, and along with it, ask the >> TURN server to allocate the odd port one higher. However, the spec >> currently has the following confusing words in it: >> >> As such, it is a request for the server to allocate an even >> port whose next higher port is also available, and furthermore, a >> request for the server to not allocate that one higher port to any >> other request except for one that asks for that port explicitly. The >> server can honor this request for adjacency at its discretion. The >> only constraint is that the allocated port has to be even. > > To restate my preference, I'd rather ditch the feature completely. > > First, it puts an extra incentive for people to use TURN as the default > candidate, which is not necessarily such a great idea. Well, hang on, ICE recommends it. I know folks want to use STUN when possible but ICE is built on the model that reliability is job #1, and using a STUN default candidate is not going to be as reliable as TURN. > > Second, it conflicts with the way the traditional sockets API allocates port > number on the server side: it allows you to request "any" available port, or > one specific port, but "any" available even port. That practically means any > TURN server implementation would have to reinvent a port allocation schema > bypassing the OS one, which sounds bad. Futhermore, this is bound to > introduce problems if the TURN server runs any other service using dynamic > port numbers as well (FTP data, SOCKS, ...). > Not a show-stopper, but an annoyance anyway. > RTP/RTCP port adjacency has been implemented all over the place ontop of existing socket APIs. Some implementations do their own port allocation. Others basically allocate an arbitrary port till they get an even one, and then ask for the next higher one. If that fails, start over. Ugly but it works. I personally implemented an RTP stack that way back a long time ago. What is your comment on the argument that this is needed to make RTCP work with legacy endpoints? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 14 00:12:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J32ps-00032v-SG; Fri, 14 Dec 2007 00:11:44 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J32pq-00032p-Rm for behave-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 00:11:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J32pq-00032H-G7 for behave@ietf.org; Fri, 14 Dec 2007 00:11:42 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J32pp-0003rD-Q8 for behave@ietf.org; Fri, 14 Dec 2007 00:11:42 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 13 Dec 2007 21:11:41 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lBE5BfHY024946; Thu, 13 Dec 2007 21:11:41 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBE5Bf9N013428; Fri, 14 Dec 2007 05:11:41 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 21:11:40 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 21:11:40 -0800 Message-ID: <476210B3.4000603@cisco.com> Date: Fri, 14 Dec 2007 00:12:19 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #2: Stateful allocations References: <47599D4F.50102@cisco.com> <200712101056.32140.remi.denis-courmont@nokia.com> <475D5443.5050601@cisco.com> <4A3D1671-D40E-449E-ADC3-24D2E8D16B90@magma.ca> <4760B414.3050703@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 14 Dec 2007 05:11:40.0525 (UTC) FILETIME=[CF68E9D0:01C83E0F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4327; t=1197609101; x=1198473101; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20Issue=20#2=3A=20State ful=20allocations |Sender:=20; bh=LoI1ZYyF6VaH3hVF4b+VR0QNWpC9+B2FQB7mt9Jddxs=; b=F/BFMPC15LmXd8D6/wdzZL53SF6Zo6vOvELvh6tXiQR3gV8RIWRZz3AjlK ZD2nVzV7UYrTvC/yj9ESq4ttVyxhLJBhusb72tqEJNdJ3Mt/LZn7rdfwz5l3 vuqyLY8vZ4; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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 Ah, OK. I think this is an esoteric case but I agree this is an inconsistency. I'd suggest a minor word smithing in rfc3489bis to fix this. -Jonathan R. Philip Matthews wrote: > I see a very small inconsistency between this and 3489bis. > > Let's assume the server uses Remi's suggested implementation technique. > And lets say a client does an Allocate transaction with the server, then > immediately deletes the allocation, and then does a second Allocation > that happens to use the same transaction id as the first, but which the > server cannot accept for some reason. Say all this happens within 10 > seconds. Then the server needs to response with an error response, but > 3489bis says that is should respond with a success response. > > > The problem is simply that the language in 3489bis is too strong for the > TURN case. We could fix this either by changing the language in 3489bis, > or by specifying Remi's proposed implementation technique and saying > that this overrides the text in 3489bis about the 10 second stuff. > > - Philip > > On 12-Dec-07, at 23:24 , Jonathan Rosenberg wrote: > >> I don't see what the duration of the allocation has to do with the 10 >> second timer. Another way to think about the timer is that the server >> has to provide transaction state and retain it for 10 seconds after >> the end of the transaction. >> >> -Jonathan R. >> >> Philip Matthews wrote: >>> On 10-Dec-07, at 06:59 , Jonathan Rosenberg wrote: >>>> inline: >>>> >>>> Rémi Denis-Courmont wrote: >>>>> Le Friday 07 December 2007 21:21:51 ext Jonathan Rosenberg, vous >>>>> avez écrit : >>>>>> There was general agreement at the ad-hoc that this is a >>>>>> non-issue. TURN >>>>>> servers are already required to maintain state, in the form of >>>>>> allocations, permissions, channel bindings, and so on. Transaction >>>>>> state >>>>>> is not much more. >>>>>> >>>>>> Note that, rfc3489bis requires stun transactions (including >>>>>> extensions >>>>>> like TURN) to be idempotent. Note that, despite the different >>>>>> response >>>>>> codes for a retransmit and new transaction, TURN remains idempotent. >>>>>> Idempotency only requires that subsequent retries do not alter the >>>>>> state >>>>>> on the server; it does NOT require the same response. We went through >>>>>> this ad-nauseum on XCAP. >>>>>> >>>>>> The proposal is therefore to just document this fact, but >>>>>> otherwise not >>>>>> change anything. >>>>>> >>>>>> Please comment if you agree (or not) with this. >>>>> If I understand correctly, this practically means the server must >>>>> remember the ID of the STUN transaction that created the TURN >>>>> allocation. When it receives an allocation, it returns a success >>>>> response if it's the same ID or an error if it's not. Right? >>>> >>>> Yes. >>> To be consistent with 3489bis, you would also have to have a 10 >>> second timer. 3489bis says: >>> If the request uses UDP transport and is a retransmission of a >>> request for which the server has already generated a success response >>> within the last 10 seconds, the server MUST retransmit the same >>> success response. One way for a server to do this is to remember all >>> transaction IDs received over UDP and their corresponding responses >>> in the last 10 seconds. >>> For short-lived TURN allocations, the 10-second timer is probably >>> pointless, even though 3489bis requires it. For long-lived >>> allocations (days or weeks or even months), the timer might become >>> important -- I haven't worked out the math. In either case, I think >>> the two documents should be consistent. >>> - Philip >> >> -- >> Jonathan D. Rosenberg, Ph.D. 499 Thornall St. >> Cisco Fellow Edison, NJ 08837 >> Cisco, Voice Technology Group >> jdrosen@cisco.com >> http://www.jdrosen.net PHONE: (408) 902-3084 >> http://www.cisco.com >> > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 14 00:14:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J32sr-0004ob-L6; Fri, 14 Dec 2007 00:14:49 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J32so-0004oT-PH for behave-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 00:14:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J32so-0004mJ-DZ for behave@ietf.org; Fri, 14 Dec 2007 00:14:46 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J32so-0003w6-1e for behave@ietf.org; Fri, 14 Dec 2007 00:14:46 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 13 Dec 2007 21:14:45 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBE5Ej5o007454; Thu, 13 Dec 2007 21:14:45 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lBE5Ej0i015430; Fri, 14 Dec 2007 05:14:45 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 21:14:45 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 21:14:44 -0800 Message-ID: <4762116C.3080106@cisco.com> Date: Fri, 14 Dec 2007 00:15:24 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Lars Eggert Subject: Re: [BEHAVE] TURN Issue #5: Port Range References: <4759CD14.10208@cisco.com> <152D0B93-6269-4B44-A313-1D90EE6E8E73@nokia.com> In-Reply-To: <152D0B93-6269-4B44-A313-1D90EE6E8E73@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Dec 2007 05:14:44.0965 (UTC) FILETIME=[3D583950:01C83E10] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1153; t=1197609285; x=1198473285; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20Issue=20#5=3A=20Port= 20Range |Sender:=20; bh=bgUVgZFdjxr14/n5ikDPECTQ5g7zk2eOJifuZa11sVU=; b=UeYmN3YEOfoEHsJeiDXW7MudrlpVyiRwidL3/jexe0MSB21YDYC6nphCVy LiBntXIYaf9ChxiWIHAqT07EVxvpPngFAdhpB/C2QtJIC/OWh1p8Bglu/YdQ /IsRZVpxy/tNb9GSuVyTPGyKL3Af+ATUtwwKowIj0xYZkRdy3Ixjw=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 This would put a serious dent in the capacity of a TURN server. As far as I know there is nothing that actually breaks by reusing the registered ports for a dynamic allocation. Since TURN can't be used to run traditional servers, and the IP and port must be exchanged with peers through a rendezvous protocol, the typical issue of port conflict doesn't come up. What am I missing? -Jonathan R. Lars Eggert wrote: > On 2007-12-8, at 0:45, ext Jonathan Rosenberg wrote: >> TURN currently says that a TURN server SHOULD only utilize ports in >> the range 1024-65535, avoiding the well-known ports from 1-1023. > > Given that the registered port range extends from 1024-49151, TURN > should limit itself to using the Private Ports from 49152-65535, in > order to avoid using ports registered to other applications. > > Lars (as an individual) > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 14 04:10:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J36Z1-0007pe-EO; Fri, 14 Dec 2007 04:10:35 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J36Z0-0007pX-A1 for behave-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 04:10:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J36Z0-0007pP-0K for behave@ietf.org; Fri, 14 Dec 2007 04:10:34 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J36Yz-0008Be-DT for behave@ietf.org; Fri, 14 Dec 2007 04:10:33 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBE99h6p015792; Fri, 14 Dec 2007 11:09:49 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 11:09:48 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 11:09:48 +0200 Received: from [172.17.26.108] ([10.162.253.40]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 11:09:48 +0200 Message-Id: <0B26C595-C3F5-4546-87DB-1732460BD75C@nokia.com> From: Lars Eggert To: ext Jonathan Rosenberg In-Reply-To: <4762116C.3080106@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [BEHAVE] TURN Issue #5: Port Range Date: Fri, 14 Dec 2007 11:09:47 +0200 References: <4759CD14.10208@cisco.com> <152D0B93-6269-4B44-A313-1D90EE6E8E73@nokia.com> <4762116C.3080106@cisco.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 14 Dec 2007 09:09:48.0127 (UTC) FILETIME=[137BF6F0:01C83E31] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 2007-12-14, at 7:15, ext Jonathan Rosenberg wrote: > This would put a serious dent in the capacity of a TURN server. As > far as I know there is nothing that actually breaks by reusing the > registered ports for a dynamic allocation. If TURN grabs a port that my app has registered, I can't run my app on the TRUN server. Preventing this is exactly why port registries exist. (A minor related issue is that if TURN uses a port registered to my app, and there are firewalls that have rules for my app based on that port, the TURN traffic will get that treatment.) > Since TURN can't be used to run traditional servers, and the IP and > port must be exchanged with peers through a rendezvous protocol, the > typical issue of port conflict doesn't come up. What am I missing? I think you assume that the TURN server will be the only thing running on an IP address. That's not a safe assumption. Lars _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 14 08:36:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Aid-0005L0-NK; Fri, 14 Dec 2007 08:36:47 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J3Aib-0005Kq-ND for behave-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 08:36:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Aib-0005Kh-CQ; Fri, 14 Dec 2007 08:36:45 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3AiX-0005WA-GY; Fri, 14 Dec 2007 08:36:45 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBEDZCSr030141; Fri, 14 Dec 2007 15:36:30 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 15:36:04 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 15:36:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Dec 2007 15:36:03 +0200 Message-ID: In-Reply-To: <10d801c83796$975e2250$6e7a150a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft summary and minutes of SAFE BOF Thread-Index: Acg3ZOitfvvp7lNyRbyblrmjceM+3AAMYJLwAa+cMjA= References: <031101c83762$c7491f80$6e7a150a@cisco.com><4756E0CF.8020800@acm.org> <10d801c83796$975e2250$6e7a150a@cisco.com> From: To: , X-OriginalArrivalTime: 14 Dec 2007 13:36:04.0147 (UTC) FILETIME=[45EF2830:01C83E56] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ff67cea9f7df2d77f61a364cea0926e8 Cc: csp@csperkins.org Subject: [BEHAVE] Draft summary and minutes of SAFE BOF X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org (Distribution: SAFE, BEHAVE lists.) Hi,=20 Here are the preliminary summary and more detailed minutes of the SAFE = BOF held at IETF 70. Please let the chairs know if you have any comments = or corrections. Regards, Markus=20 SAFE summary ------------ SAFE BOF Dec 3, 2007, 0900 - 1130 Chairs: Colin Perkins (csp@csperkins.org), Markus Isom=E4ki = (markus.isomaki@nokia.com)=20 Summary by Markus Isom=E4ki BOF proposal is available at: = http://www3.ietf.org/proceedings/07dec/agenda/safe.txt The purpose of SAFE BOF was to discuss two things: 1. Is there interest in the IETF to work on solutions to reduce = keep-alive traffic for NAT and firewall traversal.=20 2. Is the newly-proposed technique for using STUN to discover, query and = control firewalls and NATs, a reasonable approach to pursue in this = space. The intent of the BOF was not to form a new WG at this point, but to = give guidance how to continue work on this area. Scope/properties of STUN control currently is that it works for = UDP-only, supports nested NATs and firewalls, detects non-supporting = NATs and fails safely with them, and operates on one binding/pinhole at = a time using transport source address for authorization. It's main = purpose is to query and adjust the refresh period for the = binding/pinhole. The main discussion topics that were raised during the BOF were: - Is there a problem with keepalives: It was commented that 20-30 sec = keepalive for UDP will dramatically affect battery lifetime e.g. in a = device with WCDMA radio. Reference to a paper was later sent to SAFE and = BEHAVE lists. - Generality: The initial scope is only UDP. Should this work also for = TCP? TCP got a lot of support as it also has unpredictable timeouts in = middleboxes. On the other hand UDP-only solution would be simpler and = easier to deploy. IPv4/IPv6 translators were also brought into = discussion, but declared out of scope. - Future path: If we adopt this protocol now, is there a path to the = future problems we want to solve? Arguments for incremental deployment = vs. generic solution. - Which applications benefit from STUN/UDP solution: SIP/UDP, real-time = media, IPSec/UDP, Teredo, Mobile IP. Some of these don't use STUN. Some, = like SIP could run over TCP as well. In general the benefit is biggest = for "push" type of applications that need to maintain connectivity over = long periods with little actual traffic to send/receive.=20 - Security model: In STUN-control the middlebox is controlled in-band = with the application traffic and the transport source addresss is used = for authorization. No bulk provisioning of mappings/pinholes is = possible. This simplifies the security properties compared to = third-party/out-of-band control models. - Scope and difference to existing mechanisms: There was a presentation = on survey for existing mechanisms. This caused a lot of clarifying = questions on how the existing protocols were classified.=20 - What is the incentive for the vendors to implement this: None of the = previous control protocols have been deployed. STUN-control has some = simplicity and incremental deployment benefits, at least for those = applications that already use STUN.=20 - Problem with overlapping address spaces and nested NATs: Can = STUN-control deal with this? A couple of proposals exist, but are = complicated. This is a generic problem with NATs, should it be solved = regardless of STUN-control. In the end of the session several polls were taken: - Question: "Are some functional requirements (for avoiding frequent = keepalive) or deployment considerations left unsatisfied by existing = protocols?" Yes/No Result: Majority agrees, but a substantial minority disagrees - Question: "Should the IETF try to solve the problem?" Yes/No Result: Clear majority support. - Question: "Is the NAT control STUN usage a reasonable approach to NAT = control, addressing the above requirements?" Yes/Maybe/No (At this point many people commented that this is not a clear = question, as some people would also want to support TCP etc.) Result: Seems to be weighted toward "yes" and "maybe", "no" slightly = quieter. - Question: "Given that we have a number of proposals in this space, has = our understanding of this problem space changed enough that we can build = something that people actually will deploy?" Yes/No Result: Response judged 1/3 "yes", 2/3 "no". SAFE minutes ------------ Notes, SAFE Dec 3 2007 0900 recorded by Dean Willis Chaired by Colin Perkins, Markus Isomaki --- Topic: Agenda Bash slides presented by chairs Agenda accepted as proposed by chairs. "Note Well" statement and IPR notice reviewed. Chairs present slides. NOTE: THIS IS NOT A "WORKING GROUP FORMING BOF" -- we are attempting to = decide whether there is a need for work in this area. We are not = discussing charters or any formative process issues in this meeting. --- Topic: Problem Statement and Scope led by Dan Wing Slides presented Problem: current NAT traversal approaches require keepalives. This = produces traffic and power consumption issues, especially for wireless = battery powered devices. Scope: Create a NAT control technique that solves keepalive and nesting, = detects and fails safely with non-upgraded NATs, and uses source = transport address for authorization. Discussion follows . .. . Question: Need to clarify relationship between determining and = adjusting of a NAT keepalive interval. Do we need to do both, or will a = system do just one? Concluded that the critical piece is determination. = We would also like to be able to do adjustment of the timing. Question: It seems that constraining the solutions space to use source = transport address might be excessive. Do we want to constrain to this = level up front? Are there other possible techniques that should be used? = Response by JDR: The idea here is to emulate what NATs already do, which = is 5-tuple address based , which we understand well. Things that do = protocol inspection or out-of-path controls raise lots of security and = deployability issues. Suggestion: Rephrase as requirements, to 1) easy to deploy, 2) confirm = that signaling for NAT control is authenticated to at least level of = normal TCP as being from the endpoint involved. Question (Philip Matthews): Are we focusing only on UDP? This problem = may not exist for TCP. Does it affect anything else? Henning noted that = his current hotel seems to time out on IMAP in about a minute, breaking = IMAP.=20 Suggestion: Requirement: needs to work on large deployments. Conclusion: Will focus on UDP initially. IPSEC support uses the IPSEC = NAT traversal mode using UDP. native IPSEC appears to be out of scope Suggestion: It would be good if the result can be extended to support = TCP, but the measure of success is to succeed well enough to get = deployed. Comment: Key difference is that TCP has an explicit teardown that can be = seen by NATs. Perhaps we could state the scope as protocols that do not = have explicit teardowns. --- Topic: Survey of Existing Protocols led by Mary Barnes Slides presented Slide: Categorization of Protocols Question: What is the difference between two-party and multiparty? The = distinction is based on whether there's an intermediary relay node apart = from the NAT itself. Noted that this may not be a useful distinction for = some people. Slides: Protocol Summaries Question: Diameter Gq' , Rx+, Gx+: These are DIAMETER based approaches = primarily from 3GPP.=20 Comment: There is also an Megaco-based H.348 protocol. Question: Where is ICE? It probably needs to be included in this = summary. Question: What does "Supports Incremental Deployment" mean? We think = this means whether the protocol is needed in every middle box on a path = or only some. An alternative: Can someone who is interested in deploying = a VoIP service make this stuff work by putting the protocol into just = the small part of the network they control, or does it require putting = boxes into parts they don't control. For example, enterprise IT people = generally won't put MIDCOM in their firewall just so end users can = access outside applications. This seems to be a very controversial = characteristic. Noted that one of the primary goals of SAFE is getting = incremental deployability, so we need to understand this better. Slides on Protocol Comparison Noted that NAT-PMP requires direction interaction with the middlebox. Slide on topology/environments: Much discussion over the "Topology Aware" column of the slide. = Conclusion that this needs some re-thinking. Perhaps column should be = labeled "Topology Unaware". Suggestion for 4th column on this slide: Identify where "end-to-end" = breaks if you use each protocol, i.e. UNSAFE considerations. =20 Discussion of the "Nested NATS" column: Suggested that the = MIDCOM/SIMCO/DIAMETER series may not really support nested NATs. Discussion of "diverse endpoints" column: Can you give an example of yes = and no by function? JDR: For example, UPnP is designed as a residential = protocol, lacking nesting, authentication, etc. So this is a consequence = of other properties. Perhaps this could be better phrased as discrete = function layers than as the broad categorization being attempted. Summary (2) slide: Comment from Keith Moore: It seems like many of the = problems with NAT protocols stem from assumption that interactions with = the middle box are bad, so don't start with this assumption. Question from Henning Schulzrine: We seem to have a long-term goal in = mind. There's a danger that we're always incrementally fixing something. = For anything of these things to be truly useful, avoiding the probing = problem seems to require some interaction with NATs. Should we look = further ahead and start mapping out the things that we're going to want? = Response from Colin: The current intent here is to explore a = tightly-focused solution to the immediate problem. Suggested by Henning = that we at least track the problems we aren't solving, and occasionally = consider whether there are other intermediate steps that we should be = taking. Counterargument from Philip Matthews: The big problem in = getting past solutions to deploy is that the complexity isn't worth the = return to the NAT vendors. We need something tightly focused that can = get deployed quickly and easily. Comment from=20 Comment from Lars: Questions for this BOF to answer: There are lots of = solutions in this area. Do we need something else? Is STUN Control a = reasonable thing to do? Is the IETF the right place to do this? --- Topic: NAT Control STUN Usage "STUN Control" led by Dan Wing Slides presented Slide: Tagging procedure with firewalls Question: This seems to indicate that the firewall wants to be seen. = What happens when they don't? Ans: They don't tag and remain invisible. Qestion: Is there an assumption that the tagging firewall is the closest = middlebox? Ans: No, they can be stacked, or there may be other layers. Slide: Communicate to NAT's embedded STUN server Question: How is signaling directed to the STUN server in the NAT? Ans: = The source 3-tuple is reused along with the new destination address of = the STUN server in the NAT. The stun server in the NAT correlates based = on the source 3-tuple, establishing a binding on the whole 5-tuple. Slide set, nested NATs Comment: There are a lot of arrows here. Is there a way that a P2P app = might use one command to open a lot of bindings? Ans: no. Comment: Is there a way to do the overlap bindings in parallel. Noted = that since this binding adjustment can be done after the media flow = starts, then there's no real setup delay. Slideset: Overlapping address spaces Question: It seems likely that overlapping addresses will occur = everytime someone stacks up generic same-brand NAT boxes. Perhaps we = should look at a fix instead of a detection. JDR notes that he proposed = something on the list last night relating to stacked DHCP-obtained = addresses so that routers can detect the conflict and re-request IP = addresses to prevent conflict. Much groaning ensued in the audience. = Noted that this is a real issue and we need to think about it some more. Comment from Philip Matthews: We don't ned a perfect solution, just = something in STUN control that suggests address randomization. That is, = new boxes that support this would randomize in net 10 instead of using = 192.168.0.0/24 for their private-side addresses. Suggestion from Keith Moore: We need to find a way to detect this sort = of brokenness and report it to the end user(or somebody else who can do = something) so that they can do something about it. Discussion about issues of randomization in address exhaustion continued = with no clear conclusion. --- General Discussion:=20 Comment: We initially saw a lot of wrongness with NAT implementations = that included ALGs. How does this not happen here? Ans: The protocol = suggested does not do any transparent functions. It only does things by = explicit interaction. Of course, there can always be bugs. Question (Aki Niemi): Have we enumerated the applications that would use = this? Ans: Any UDP applications that have long periods of no data = transmission. Re-discussion of power-management keepalive issue = followed. Noted that the suggested approach requires changes to existing = end points to gain the advantages of the suggested approach. For = applications that aren't currently using STUN, adding STUN support is = not an incremental change, even if adding STUN control afterwards would = be. Noted that there is a larger question. This sort of keepalive problem = applies not only to STUN-enabled NATs, but to stateful firewalls and = other things. Do we want to solve this problem once or many times? Comment from Keith Moore; These partial solutions for specific = applications may actually hurt deployability. It would be nice to have a = more general solution. Open question: Should we split discovery protocol from control protocol? = Noted by Hannes Tschofenig that there are people looking at STUN for = other protocols that need NAT traversal. Discussion from Cullen: I think of generality in terms of which = transport protocols it works with. There are things, like firewalls, = where we need to manage something besides UDP. Keith Moore Comment: Two approaches: One is how to fix up the infrastructure so that = works. The second is how to establish application layer protocols that = work on an existing infrastructure. We seem to be focused on making = applications work with existing IPV4 static-addressed NATs. Perhaps we = should be looking at the infrastructure instead. Comment: We may need to take v4-v6 protocol translators into account as = well. Perhaps we can define them to be better up-front, as they have = identical issues to NATs and firewalls. Some respondents think that = anything that really solves v4-v4 aps will be directly applicable even = without considering v6 up front. Directive from Lars: Would like to suggest v4-v6 is out of scope for = this discussion. Ongoing discussion ensued as to merits of narrow targeted solutions vs. = broadly applicable solutions. (All known arguments repeated several = times). Key discussion is incentive to equipment providers. Noted that = the UDP applications being discussed here tend to drive equipment = recommendation and purchase. Question: Is it reasonable to solve the problem in-the-small in one = group and in-the-large elsewhere?=20 Concern from Aki: This proposal seems to be targeted to SIP Outbound. = It's much easier to fix SIP Outbound using TCP.=20 Comment from Keith: There seems to be an assumption that a general = solution would be expensive. This may no be valid. We need to move = towards explicit guidance on where and what to upgrade. Noted that in addition to SIP and RTP, P2PSIP control connections and = HIP are candidates for the proposed STUN control solution. Comment from JDR: The market breeds complexity and incremental = single-issue solutions on its own. This is as general a solution as we = might ever get deployed. --- Topic: Future Directions Is there a a problem that needs to be solved? Are some functional = requirements or deployment considerations left unsatisfied by existing = protocols? Noted that there are studies that show existing UDP keepalive = reduces battery life by about 50%. Answers range from clearly yes to clearly no, with at least one "can not = be determined from this BOF". Discussion by JDR: The real problem is the "push" class problems. = Solutions like SIP Outbound convert these to client-server problems, but = at significant cost.=20 Keith notes that this sort of transformation creates barriers to = deployment of many midrange protocols that can't pay for the massive = rendezvous servers needed to use the current approaches.=20 Aki reiterated arguments that fixing NAT keepalive intervals will not = occur in the timeframe needed to make W-CDMA work, and that the only = reasonable solution is to move to TCP for SIP immediately. --- Poll from chairs: For are requirements left unsatisfied (this question): = Profound majority believes there are unsatisfied requirements? Poll question rephrased as "Are some functional requirements (for = avoiding frequent keepalive) or deployment considerations left = unsatisfied by existing protocols? And: Majority agrees, but a = substantial minority disagrees Question: Is there agreement that that the IETF should consider = developing a new NAT control mechanism to address these requirements? = Discussion on whether this should be a new solution, a fix to an = existing solution, be protocol agnostic (aka work for TCP), etc. Suggested that word "new" be deleted from question. Poll: Should the IETF try to solve the above problem? Result: Clear = majority support. Question: Is the NAT control STUN usage a reasonable approach to NAT = control, addressing the above requirements? Derek and others suggested that it would be reasonable if it includes = TCP support. Francois argues that this question is premature. Keith = believes this a a reasonable protocol, but that it would be nice to not = have a separate protocol for every nob that might be tweaked on a NAT or = a firewall. Philip suggest that the approach would be to bring it in as = an individual contribution and follow the usual process. Remi and Aki = re-suggest that the approach needs to solve TCP and UDP, but that we = should clearly focus on keepalive and not tweaking NAT knobs. It seems that we are trying to control the answer by controlling the = question here. Poll: Is the NAT control STUN usage a reasonable approach to NAT = control, addressing the above requirements? Yes: No: Maybe: Seems to be weighted toward yes and maybe, no slightly quieter. Poll: Given that we have a number of proposals in this space, has our = understanding of this problem space changed enough that we can build = something that people actually will deploy? Response judged 1/3 yes, 2/3 no. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 14 08:46:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3AsU-0006ji-Kn; Fri, 14 Dec 2007 08:46:58 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J3AsT-0006fO-F4 for behave-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 08:46:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3AsS-0006fF-SK for behave@ietf.org; Fri, 14 Dec 2007 08:46:56 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-09.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3AsR-0005jH-7H for behave@ietf.org; Fri, 14 Dec 2007 08:46:56 -0500 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J3AsL-0006AU-16; Fri, 14 Dec 2007 08:46:55 -0500 In-Reply-To: <476210B3.4000603@cisco.com> References: <47599D4F.50102@cisco.com> <200712101056.32140.remi.denis-courmont@nokia.com> <475D5443.5050601@cisco.com> <4A3D1671-D40E-449E-ADC3-24D2E8D16B90@magma.ca> <4760B414.3050703@cisco.com> <476210B3.4000603@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <7116202E-9599-4D08-B982-BFC9394D7ACD@magma.ca> Content-Transfer-Encoding: quoted-printable From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #2: Stateful allocations Date: Fri, 14 Dec 2007 08:46:47 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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 That is fine with me. - Philip On 14-Dec-07, at 00:12 , Jonathan Rosenberg wrote: > Ah, OK. I think this is an esoteric case but I agree this is an =20 > inconsistency. I'd suggest a minor word smithing in rfc3489bis to =20 > fix this. > > -Jonathan R. > > Philip Matthews wrote: >> I see a very small inconsistency between this and 3489bis. >> Let's assume the server uses Remi's suggested implementation =20 >> technique. And lets say a client does an Allocate transaction with =20= >> the server, then immediately deletes the allocation, and then does =20= >> a second Allocation that happens to use the same transaction id as =20= >> the first, but which the server cannot accept for some reason. Say =20= >> all this happens within 10 seconds. Then the server needs to =20 >> response with an error response, but 3489bis says that is should =20 >> respond with a success response. >> The problem is simply that the language in 3489bis is too strong =20 >> for the TURN case. We could fix this either by changing the =20 >> language in 3489bis, or by specifying Remi's proposed =20 >> implementation technique and saying that this overrides the text =20 >> in 3489bis about the 10 second stuff. >> - Philip >> On 12-Dec-07, at 23:24 , Jonathan Rosenberg wrote: >>> I don't see what the duration of the allocation has to do with =20 >>> the 10 second timer. Another way to think about the timer is that =20= >>> the server has to provide transaction state and retain it for 10 =20 >>> seconds after the end of the transaction. >>> >>> -Jonathan R. >>> >>> Philip Matthews wrote: >>>> On 10-Dec-07, at 06:59 , Jonathan Rosenberg wrote: >>>>> inline: >>>>> >>>>> R=E9mi Denis-Courmont wrote: >>>>>> Le Friday 07 December 2007 21:21:51 ext Jonathan Rosenberg, =20 >>>>>> vous avez =E9crit : >>>>>>> There was general agreement at the ad-hoc that this is a non-=20 >>>>>>> issue. TURN >>>>>>> servers are already required to maintain state, in the form of >>>>>>> allocations, permissions, channel bindings, and so on. =20 >>>>>>> Transaction state >>>>>>> is not much more. >>>>>>> >>>>>>> Note that, rfc3489bis requires stun transactions (including =20 >>>>>>> extensions >>>>>>> like TURN) to be idempotent. Note that, despite the different =20= >>>>>>> response >>>>>>> codes for a retransmit and new transaction, TURN remains =20 >>>>>>> idempotent. >>>>>>> Idempotency only requires that subsequent retries do not =20 >>>>>>> alter the state >>>>>>> on the server; it does NOT require the same response. We went =20= >>>>>>> through >>>>>>> this ad-nauseum on XCAP. >>>>>>> >>>>>>> The proposal is therefore to just document this fact, but =20 >>>>>>> otherwise not >>>>>>> change anything. >>>>>>> >>>>>>> Please comment if you agree (or not) with this. >>>>>> If I understand correctly, this practically means the server =20 >>>>>> must remember the ID of the STUN transaction that created the =20 >>>>>> TURN allocation. When it receives an allocation, it returns a =20 >>>>>> success response if it's the same ID or an error if it's not. =20 >>>>>> Right? >>>>> >>>>> Yes. >>>> To be consistent with 3489bis, you would also have to have a 10 =20 >>>> second timer. 3489bis says: >>>> If the request uses UDP transport and is a retransmission of a >>>> request for which the server has already generated a success =20 >>>> response >>>> within the last 10 seconds, the server MUST retransmit the same >>>> success response. One way for a server to do this is to =20 >>>> remember all >>>> transaction IDs received over UDP and their corresponding =20 >>>> responses >>>> in the last 10 seconds. >>>> For short-lived TURN allocations, the 10-second timer is =20 >>>> probably pointless, even though 3489bis requires it. For long-=20 >>>> lived allocations (days or weeks or even months), the timer =20 >>>> might become important -- I haven't worked out the math. In =20 >>>> either case, I think the two documents should be consistent. >>>> - Philip >>> >>> --=20 >>> Jonathan D. Rosenberg, Ph.D. 499 Thornall St. >>> Cisco Fellow Edison, NJ 08837 >>> Cisco, Voice Technology Group >>> jdrosen@cisco.com >>> http://www.jdrosen.net PHONE: (408) 902-3084 >>> http://www.cisco.com >>> > > --=20 > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 14 10:03:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3C4i-0000fp-QR; Fri, 14 Dec 2007 10:03:40 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J3C4i-0000f3-3J for behave-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 10:03:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3C4h-0000et-PI for behave@ietf.org; Fri, 14 Dec 2007 10:03:39 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3C4f-0007Xu-BP for behave@ietf.org; Fri, 14 Dec 2007 10:03:39 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBEF2Faa030511; Fri, 14 Dec 2007 17:03:28 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 17:02:09 +0200 Received: from esdhcp03981.research.nokia.com ([172.21.39.81]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 17:02:09 +0200 Message-Id: From: Lars Eggert To: ext Jonathan Rosenberg In-Reply-To: <47620F2B.4060200@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [BEHAVE] TURN Issue #1: Bandwidth Param Date: Fri, 14 Dec 2007 17:02:09 +0200 References: <47599BE6.9090903@cisco.com> <47620F2B.4060200@cisco.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 14 Dec 2007 15:02:09.0502 (UTC) FILETIME=[4CB9C7E0:01C83E62] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, On 2007-12-14, at 7:05, ext Jonathan Rosenberg wrote: > The presumption is that the server has a relationship with the > client and is there to support a particular application (say, voip). > And so, if the client includes the value the server is likely to > honor it and not drop data below that rate. If the client includes > nothing the server might choose to rate limit at a value that is > below what the client actually needs. So the client is incented to > include it. I think my disconnect has been that I don't view the TURN server as an entity that enforces any sort of transmission behavior or capacity use. A TURN server should be a packet relay, plain and simple. It's basically a router that routes between a bunch of virtual TCP- or UDP- encapsulation interfaces and the Internet. TURN provides management for these virtual interfaces as well as data encapsulation. Nothing more, nothing less. If specific deployment cases require a QoS enforcement point on such a router, we have a number of existing protocols that should be used to control this function, instead incorporating this functionality into TURN. >> But this doesn't tell the client all that much. Yes, if it stays >> below the limit, it can be sure that the server doesn't rate-limit >> it, but congestion on the path can happen before that rate is >> reached, i.e., the client can't depend on it. And because the >> server may forward traffic that exceeds this rate, the client has >> every incentive to see if it can send more than the signaled rate. > > This parameter is really only primarily useful for fixed rate > applications for voip. For variable rate I agree its largely useless. But even for CBR it doesn't provide any guarantees, because congestion can happen before the signaled capacity is reached. (Unless TURN ties in with a "real" QoS mechanism, in which case why isn't that protocol used to manage QoS instead of TURN?) >> TURN isn't a QoS-signaling solution, so I'm all for removing this >> option. > > No, but TURN servers do provide a service (media relay of traffic) > and it seems sensible for clients to ask for a particular level of > service and be told if they get it or not. TURN relays IP packets. Nothing in IP lets clients ask for a particular level of service. TURN can only be used to turn some knobs on the TURN server, which are unlikely to have much effect for the end- to-end path that the client flow is traversing. Lars _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 14 17:59:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3JVS-0005mx-1a; Fri, 14 Dec 2007 17:59:46 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J3JVQ-0005jZ-Jd for behave-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 17:59:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3JVQ-0005hL-8z for behave@ietf.org; Fri, 14 Dec 2007 17:59:44 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3JVO-0003Rd-2E for behave@ietf.org; Fri, 14 Dec 2007 17:59:44 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 14 Dec 2007 14:59:41 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lBEMxfc3012630; Fri, 14 Dec 2007 14:59:41 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lBEMxa0s003740; Fri, 14 Dec 2007 22:59:41 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 14:59:39 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 14:59:39 -0800 Message-ID: <47630B03.3050708@cisco.com> Date: Fri, 14 Dec 2007 18:00:19 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Lars Eggert Subject: Re: [BEHAVE] TURN Issue #5: Port Range References: <4759CD14.10208@cisco.com> <152D0B93-6269-4B44-A313-1D90EE6E8E73@nokia.com> <4762116C.3080106@cisco.com> <0B26C595-C3F5-4546-87DB-1732460BD75C@nokia.com> In-Reply-To: <0B26C595-C3F5-4546-87DB-1732460BD75C@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Dec 2007 22:59:39.0618 (UTC) FILETIME=[01868C20:01C83EA5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2297; t=1197673181; x=1198537181; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20Issue=20#5=3A=20Port= 20Range |Sender:=20; bh=JBin5Lwt0TwoL6Z5oW5e0uxwWHG0R4GsVKx0g5ZgQx4=; b=hHl0j9S1iARSvM5tWesTfCZCWOM3Q9saoBaD1yXqX38O14UGpbhpkVbFXu lcaSRG7mkCgvgJt2CntvaQ+MTlGl2SmoQvTZ2pTglqUyACd7bO7+qKwDz/T2 t9K4ABDQW9; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Lars Eggert wrote: > On 2007-12-14, at 7:15, ext Jonathan Rosenberg wrote: >> This would put a serious dent in the capacity of a TURN server. As far >> as I know there is nothing that actually breaks by reusing the >> registered ports for a dynamic allocation. > > If TURN grabs a port that my app has registered, I can't run my app on > the TRUN server. Preventing this is exactly why port registries exist. As you state below, my assumption is that TURN is the only thing running. Or, if there are things, they are known and probably up and running before the TURN process starts (like SNMP). > > (A minor related issue is that if TURN uses a port registered to my app, > and there are firewalls that have rules for my app based on that port, > the TURN traffic will get that treatment.) Well, we can have a conversation on the efficacy of port-based treatment of traffic in a firewall. But I do agree firewalls do block specific ports. > >> Since TURN can't be used to run traditional servers, and the IP and >> port must be exchanged with peers through a rendezvous protocol, the >> typical issue of port conflict doesn't come up. What am I missing? > > I think you assume that the TURN server will be the only thing running > on an IP address. That's not a safe assumption. Right. OK, so how about this. The spec says SHOULD be limited to the dynamic range as you suggest. However, as with other SHOULDs, it gives conditions under which you can violate this should. Then it talks about cases where no other applications run on the server, and where firewalls aren't blocking ports, and if you know these aren't problems it is OK to grab other ports. This would allow vendors of standalone TURN servers to use the full range since both of these conditions exist there. However, if TURN is run in an endpoint like a p2psip peer, it would use the more limited range, which is fine anyway for that use case. Sound OK? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 14 18:03:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3JYf-0005KU-3j; Fri, 14 Dec 2007 18:03:05 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J3JYd-0005Hz-5C for behave-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 18:03:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3JY4-00045M-99 for behave@ietf.org; Fri, 14 Dec 2007 18:02:28 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3JY3-0003Vf-Rn for behave@ietf.org; Fri, 14 Dec 2007 18:02:28 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 14 Dec 2007 15:02:25 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lBEN2Pkw002153; Fri, 14 Dec 2007 15:02:25 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBEN2P9N021077; Fri, 14 Dec 2007 23:02:25 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 15:02:25 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 15:02:25 -0800 Message-ID: <47630BA8.80706@cisco.com> Date: Fri, 14 Dec 2007 18:03:04 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Marc Petit-Huguenin Subject: Re: [BEHAVE] Port allocation in TURN References: <474E2A10.6010003@acm.org> In-Reply-To: <474E2A10.6010003@acm.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Dec 2007 23:02:25.0156 (UTC) FILETIME=[6431A440:01C83EA5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2236; t=1197673345; x=1198537345; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20Port=20allocation=20in=20TUR N |Sender:=20; bh=3X9DHanKqE/UpahjCNqT05Cr201k58wUkZajgNGjozU=; b=DieLcpyBhYetT01IUFWxAO2/J5PIB0EZZvXd0mR9Ghn0VZI8q91eo+qBG9 mO1kdnFRqQ2g8YoLaTsifXEjJUU70BAw423IWHHRxTUopHiMxnMWFk0m2Knl 3ZXa0rufck; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Sorry for not responding on this. Generally, I like to separate things that are orthogonal. These are all orthogonal. Indeed, we want one of them (requested address type) to be an extension anyway (I hate to require all TURN servers to act as v4 to v6 relays). I don't think it really simplifies the spec to combine them, and since the same information is ultimately being conveyed and processed, I don't see how it saves much on implementation. So, I'd rather not make this change. -Jonathan R. Marc Petit-Huguenin wrote: > Between turn-05 and turn-ipv6-03, there is 3 different attributes used > to allocate a port: REQUESTED-PORT-PROPS, REQUESTED-IP and > REQUESTED-ADDRESS-TYPE. > > My proposal is to simplify by merging the 3 attributes into one: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 0 0 0| A | Family | Specific Port Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Address (32 bits or 128 bits) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The six first bits are reserved and must be set to zero. > The two bits labeled A have the same meaning than the A bits in > REQUESTED-PORT-PROPS. > The Family field has the same meaning than the field of same name in > REQUESTED-ADDRESS-TYPE. > The Specific Port Number field has the same meaning than the field of > same name in REQUESTED-PORT-PROPS. > The Address field has the same meaning than the field of same name in > REQUESTED-IP, excepted that a value of all zero means that the server is > free to choose the IP address > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 14 18:07:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Jci-000152-0J; Fri, 14 Dec 2007 18:07:16 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J3Jcg-00014k-UN for behave-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 18:07:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Jcg-00014c-Ib for behave@ietf.org; Fri, 14 Dec 2007 18:07:14 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3Jcf-0005im-VY for behave@ietf.org; Fri, 14 Dec 2007 18:07:14 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 14 Dec 2007 15:07:13 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lBEN7Djt020763; Fri, 14 Dec 2007 15:07:13 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBEN6vCP017427; Fri, 14 Dec 2007 23:07:13 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 15:07:12 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 15:07:11 -0800 Message-ID: <47630CC7.10103@cisco.com> Date: Fri, 14 Dec 2007 18:07:51 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Marc Petit-Huguenin Subject: Re: [BEHAVE] Transport of ICMP errors in TURN References: <4748913B.8090806@acm.org> In-Reply-To: <4748913B.8090806@acm.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Dec 2007 23:07:11.0934 (UTC) FILETIME=[0F207DE0:01C83EA6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3787; t=1197673633; x=1198537633; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20Transport=20of=20ICMP=20erro rs=20in=20TURN |Sender:=20; bh=Oo3DGjyewEUdx+jPm3Imx6b0F8cjfd9S8R18FAp/jV0=; b=dIGZbTKMlGDy3nEgSWxLJUwoER3e+qR6WeMIi5xK6DToK04ZmUrccoubC1 cfUqBmPAzP8+QylP5dMw3ekE8xKNZSjRVm0mKm2oFHYMZKSar5D03yZzXrwy nsdldrahRX; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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 Presumably this requires the TURN server to parse the ICMP to find the specific allocation, and thus client, to which the indication is sent, right? Given that ICMP are frequently blocked by NAT and firewall anyway, I don't know how much this would get used. Also this would really primarily be an optimization, since ICE works without getting the ICMP error. Indeed if you are getting ICMP errors on your TURN connectivity checks, ICE is likely to fail completely anyway in this case. Generally I am in favor of keeping TURN as minimal as we can, and I don't see a compelling use case for this, so I'm inclined to say that we shouldn't do this. Can you give some example use cases where this would really improve things? Thanks, Jonathan R. Marc Petit-Huguenin wrote: > draft-ietf-mmusic-ice-17 section 7.1.2.1 says that "[a]gents MAY support > receipt of ICMP errors for connectivity check." Unfortunately there is > no way to receive a ICMP error when the connectivity check is carried > over TURN. Here's an example: > > +------ Client -----+ > ICE Turn client Turn Server Peer > | Binding Req | | | > |------------>| 0 Send(123, peer, Binding Req) | | > | |--------------------------------->| Binding Req | > | | 0 Channel Confirmation Ind(123) |-------------->| > | |<---------------------------------| ICMP 3 | > | | |<--------------| > | Binding Req | | | > |------------>| 123 Binding Req | | > | |--------------------------------->| Binding Req | > | | |-------------->| > | | | ICMP 3 | > | | |<--------------| > : : : : > > > I suggest to add a new indication that will carry the ICMP content to > the TURN client so the Binding transaction can fail earlier: > > +------ Client -----+ > ICE Turn client Turn Server Peer > | Binding Req | | | > |------------>| 0 Send(123, peer, Binding Req) | | > | |--------------------------------->| Binding Req | > | | 0 Channel Confirmation Ind(123) |-------------->| > | |<---------------------------------| ICMP 3 | > | | 0 Icmp Ind(source, data) |<--------------| > | ICMP 3 |<---------------------------------| | > |<------------| | | > > > The new indication contains a PEER-ADDRESS attribute that contain the > source IP address/port of the ICMP packet, some other attributes to > carry the ICMP values (type, code and next-hop MTU) and a DATA attribute > that contain the data copied from the original UDP packet. The ICMP > spec mandates to copy only the IP header and 8 additional bytes, i.e. > the UDP header, which should be enough to match the Binding transaction > if there is only one pending. Some IP implementations returns even more > data, so the STUN transaction Id could be available to find the transaction. > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 14 20:08:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3LWF-000324-WD; Fri, 14 Dec 2007 20:08:44 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J3LWE-00031y-P0 for behave-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 20:08:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3LWE-00031p-Dd for behave@ietf.org; Fri, 14 Dec 2007 20:08:42 -0500 Received: from server.implementers.org ([69.55.225.91]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3LWD-0008Ua-Tq for behave@ietf.org; Fri, 14 Dec 2007 20:08:42 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id D4020D9D403A; Fri, 14 Dec 2007 17:08:40 -0800 (PST) Received: from [192.168.1.3] (c-24-4-253-5.hsd1.ca.comcast.net [24.4.253.5]) by server.implementers.org (Postfix) with ESMTP id 44268D9D4038; Fri, 14 Dec 2007 17:08:38 -0800 (PST) Message-ID: <47632913.3050606@acm.org> Date: Fri, 14 Dec 2007 17:08:35 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071008) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [BEHAVE] Port allocation in TURN References: <474E2A10.6010003@acm.org> <47630BA8.80706@cisco.com> In-Reply-To: <47630BA8.80706@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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: > Sorry for not responding on this. > > Generally, I like to separate things that are orthogonal. These are all > orthogonal. Indeed, we want one of them (requested address type) to be > an extension anyway (I hate to require all TURN servers to act as v4 to > v6 relays). > > I don't think it really simplifies the spec to combine them, and since > the same information is ultimately being conveyed and processed, I don't > see how it saves much on implementation. > > So, I'd rather not make this change. OK > > -Jonathan R. > > Marc Petit-Huguenin wrote: >> Between turn-05 and turn-ipv6-03, there is 3 different attributes used >> to allocate a port: REQUESTED-PORT-PROPS, REQUESTED-IP and >> REQUESTED-ADDRESS-TYPE. >> >> My proposal is to simplify by merging the 3 attributes into one: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0 0 0 0 0 0| A | Family | Specific Port Number | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> | Address (32 bits or 128 bits) | >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> The six first bits are reserved and must be set to zero. >> The two bits labeled A have the same meaning than the A bits in >> REQUESTED-PORT-PROPS. >> The Family field has the same meaning than the field of same name in >> REQUESTED-ADDRESS-TYPE. >> The Specific Port Number field has the same meaning than the field of >> same name in REQUESTED-PORT-PROPS. >> The Address field has the same meaning than the field of same name in >> REQUESTED-IP, excepted that a value of all zero means that the server is >> free to choose the IP address >> > -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 14 20:42:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3M2m-0003iC-1O; Fri, 14 Dec 2007 20:42:20 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J3M2l-0003gE-Ed for behave-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 20:42:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3M2l-0003dA-2S for behave@ietf.org; Fri, 14 Dec 2007 20:42:19 -0500 Received: from server.implementers.org ([69.55.225.91]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3M2k-0000fR-E6 for behave@ietf.org; Fri, 14 Dec 2007 20:42:18 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id 17AE2D9D403A; Fri, 14 Dec 2007 17:42:18 -0800 (PST) Received: from [192.168.1.3] (c-24-4-253-5.hsd1.ca.comcast.net [24.4.253.5]) by server.implementers.org (Postfix) with ESMTP id 07105D9D4038; Fri, 14 Dec 2007 17:42:14 -0800 (PST) Message-ID: <476330F6.3020604@acm.org> Date: Fri, 14 Dec 2007 17:42:14 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071008) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [BEHAVE] Transport of ICMP errors in TURN References: <4748913B.8090806@acm.org> <47630CC7.10103@cisco.com> In-Reply-To: <47630CC7.10103@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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: > Presumably this requires the TURN server to parse the ICMP to find the > specific allocation, and thus client, to which the indication is sent, > right? Yes, one way to implement this is to use connected datagram sockets with the SO_REUSEADDR socket option. This is how I implemented it. > > Given that ICMP are frequently blocked by NAT and firewall anyway, I > don't know how much this would get used. > > Also this would really primarily be an optimization, since ICE works > without getting the ICMP error. Indeed if you are getting ICMP errors on > your TURN connectivity checks, ICE is likely to fail completely anyway > in this case. > > Generally I am in favor of keeping TURN as minimal as we can, and I > don't see a compelling use case for this, so I'm inclined to say that we > shouldn't do this. Can you give some example use cases where this would > really improve things? The main use case is the one described below, to accelerate the failure of an ICE connectivity check (100ms instead of 7900ms). Note that this proposal would be consistent with RFC 4787 section 9. If there is too much resistance to thi schange, then it can be done as a future extension of TURN, so clients interested in the ICMP packets can request this feature from the TURN server. Perhaps some text should be added in the TURN I-D to explain what to do when receiving a ICMP errors from the peer (ignore them). > > Thanks, > Jonathan R. > > Marc Petit-Huguenin wrote: >> draft-ietf-mmusic-ice-17 section 7.1.2.1 says that "[a]gents MAY support >> receipt of ICMP errors for connectivity check." Unfortunately there is >> no way to receive a ICMP error when the connectivity check is carried >> over TURN. Here's an example: >> >> +------ Client -----+ >> ICE Turn client Turn Server Peer >> | Binding Req | | | >> |------------>| 0 Send(123, peer, Binding Req) | | >> | |--------------------------------->| Binding Req | >> | | 0 Channel Confirmation Ind(123) |-------------->| >> | |<---------------------------------| ICMP 3 | >> | | |<--------------| >> | Binding Req | | | >> |------------>| 123 Binding Req | | >> | |--------------------------------->| Binding Req | >> | | |-------------->| >> | | | ICMP 3 | >> | | |<--------------| >> : : : : >> >> >> I suggest to add a new indication that will carry the ICMP content to >> the TURN client so the Binding transaction can fail earlier: >> >> +------ Client -----+ >> ICE Turn client Turn Server Peer >> | Binding Req | | | >> |------------>| 0 Send(123, peer, Binding Req) | | >> | |--------------------------------->| Binding Req | >> | | 0 Channel Confirmation Ind(123) |-------------->| >> | |<---------------------------------| ICMP 3 | >> | | 0 Icmp Ind(source, data) |<--------------| >> | ICMP 3 |<---------------------------------| | >> |<------------| | | >> >> >> The new indication contains a PEER-ADDRESS attribute that contain the >> source IP address/port of the ICMP packet, some other attributes to >> carry the ICMP values (type, code and next-hop MTU) and a DATA attribute >> that contain the data copied from the original UDP packet. The ICMP >> spec mandates to copy only the IP header and 8 additional bytes, i.e. >> the UDP header, which should be enough to match the Binding transaction >> if there is only one pending. Some IP implementations returns even more >> data, so the STUN transaction Id could be available to find the >> transaction. >> > -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 14 20:47:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3M7p-0000WC-Bg; Fri, 14 Dec 2007 20:47:33 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J3M7n-0000W0-NQ for behave-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 20:47:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3M7n-0000Vs-CS for behave@ietf.org; Fri, 14 Dec 2007 20:47:31 -0500 Received: from server.implementers.org ([69.55.225.91]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3M7m-0000lu-Rt for behave@ietf.org; Fri, 14 Dec 2007 20:47:31 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id 83865D9D403A; Fri, 14 Dec 2007 17:47:30 -0800 (PST) Received: from [192.168.1.3] (c-24-4-253-5.hsd1.ca.comcast.net [24.4.253.5]) by server.implementers.org (Postfix) with ESMTP id 25664D9D4038; Fri, 14 Dec 2007 17:47:28 -0800 (PST) Message-ID: <4763322F.5080108@acm.org> Date: Fri, 14 Dec 2007 17:47:27 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071008) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [BEHAVE] TURN Issue #1: Bandwidth Param References: <47599BE6.9090903@cisco.com> <4759AFD5.7030200@acm.org> <4760B54A.1040508@cisco.com> <476156CC.2040902@acm.org> <47620DC5.3070501@cisco.com> In-Reply-To: <47620DC5.3070501@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Jonathan Rosenberg wrote: > Right - I was assuming that the client drops the allocation if it > doesn't use it. > > If you want to assume non-cooperative clients (ones that don't drop > their allocations when they don't use them), bandwidth anyway won't be > useful. Clients might decide to just not use the 'this is actually ice' > flag, since they have no incentive to do so, and you're right back in > the same boat. You are right. > > -JOnathan R. > > Marc Petit-Huguenin wrote: >> Jonathan Rosenberg wrote: >>> inline: >>> >>> Marc Petit-Huguenin wrote: >>>> Jonathan Rosenberg wrote: >>>>> Please comment if you are happy (or not) with keeping bandwidth with >>>>> these proposed semantics. >>>>> >>>> I am OK with keeping bandwidth, but I would like to add one thing. The >>>> problem with bandwidth is when TURN is used with ICE. A TURN >>>> allocation >>>> will be made but it will generally not be used excepted for >>>> connectivity >>>> checks (i.e. far less than the bandwidth that will be used for video). >>>> So most TURN servers used in an ICE environment will either >>>> oversubscribe or waste resources. >>> That wouldn't be a problem, normally. >>> >>> So when a client uses ICE it would do the allocation and provide the >>> bandwidth that would be used if TURN is selected. If TURN is not >>> selected, the client will, after ICE completes, drop the allocation. >>> Thus, at any point in time, the allocations on the server will be all of >>> those that are actually using TURN, plus a small number (those that have >>> just arrived and for which TURN has not yet completed) that are only so >>> far doing ICE. Law of large numbers would argue that for any reasonable >>> server capacity, the overall capacity is dominated by the in-use >>> allocations and not the transient ones. >>> >> >> Yes, but it works only if the client drops the allocation and we do not >> have the deployment experience to know how the ICE endpoints will >> implement this. This can be added as an extension later if needed or a >> TURN server can collect statistics and guess the intent by inspecting >> the application data forwarded. >> > -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Dec 15 03:01:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Rxh-0007uW-FO; Sat, 15 Dec 2007 03:01:29 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J3Rxg-0007uP-3I for behave-confirm+ok@megatron.ietf.org; Sat, 15 Dec 2007 03:01:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Rxa-0007se-95 for behave@ietf.org; Sat, 15 Dec 2007 03:01:22 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3RxX-0006b8-Tu for behave@ietf.org; Sat, 15 Dec 2007 03:01:22 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBF81EHe006702; Sat, 15 Dec 2007 10:01:15 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Dec 2007 10:01:14 +0200 Received: from [192.168.255.2] ([10.162.253.123]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Dec 2007 10:01:14 +0200 Message-Id: <8BB50A79-8FC7-4158-9684-2BBBF7740036@nokia.com> From: Lars Eggert To: ext Jonathan Rosenberg In-Reply-To: <47630B03.3050708@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [BEHAVE] TURN Issue #5: Port Range Date: Sat, 15 Dec 2007 10:01:14 +0200 References: <4759CD14.10208@cisco.com> <152D0B93-6269-4B44-A313-1D90EE6E8E73@nokia.com> <4762116C.3080106@cisco.com> <0B26C595-C3F5-4546-87DB-1732460BD75C@nokia.com> <47630B03.3050708@cisco.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 15 Dec 2007 08:01:14.0102 (UTC) FILETIME=[A9BF5160:01C83EF0] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 2007-12-15, at 1:00, ext Jonathan Rosenberg wrote: > The spec says SHOULD be limited to the dynamic range as you suggest. > However, as with other SHOULDs, it gives conditions under which you > can violate this should. Then it talks about cases where no other > applications run on the server, and where firewalls aren't blocking > ports, and if you know these aren't problems it is OK to grab other > ports. This would allow vendors of standalone TURN servers to use > the full range since both of these conditions exist there. However, > if TURN is run in an endpoint like a p2psip peer, it would use the > more limited range, which is fine anyway for that use case. > > Sound OK? Yes, this is a good resolution. Thanks, Lars _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Dec 15 08:35:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3XBC-0000bI-23; Sat, 15 Dec 2007 08:35:46 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J3XBB-0000bD-Av for behave-confirm+ok@megatron.ietf.org; Sat, 15 Dec 2007 08:35:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3XBA-0000b4-UI for behave@ietf.org; Sat, 15 Dec 2007 08:35:44 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3XBA-00027h-I4 for behave@ietf.org; Sat, 15 Dec 2007 08:35:44 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 15 Dec 2007 05:35:44 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lBFDZibq017158; Sat, 15 Dec 2007 05:35:44 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBFDZh9N001624; Sat, 15 Dec 2007 13:35:44 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Dec 2007 05:35:44 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Dec 2007 05:35:43 -0800 Message-ID: <4763D856.2070204@cisco.com> Date: Sat, 15 Dec 2007 08:36:22 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Marc Petit-Huguenin Subject: Re: [BEHAVE] Transport of ICMP errors in TURN References: <4748913B.8090806@acm.org> <47630CC7.10103@cisco.com> <476330F6.3020604@acm.org> In-Reply-To: <476330F6.3020604@acm.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Dec 2007 13:35:43.0645 (UTC) FILETIME=[64208CD0:01C83F1F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1132; t=1197725744; x=1198589744; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20Transport=20of=20ICMP=20erro rs=20in=20TURN |Sender:=20; bh=C7y8y4ph3q9SGBoqgKbOrL2qMe9UWvHQUiF5t2CoP7I=; b=jEO/tE0aV/bqFZ48NLvJQUBJnmSH2H1l786v7Ng9pHaBBoZhYALM2pqllh LV2FCVuZ4SY4OMv22EO+VHARg0nmHsGj3MswLIxcsHp9a5Qy0/hrh+EsiOUb jmxvnfNEpi; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Marc Petit-Huguenin wrote: >> Generally I am in favor of keeping TURN as minimal as we can, and I >> don't see a compelling use case for this, so I'm inclined to say that we >> shouldn't do this. Can you give some example use cases where this would >> really improve things? > > The main use case is the one described below, to accelerate the failure > of an ICE connectivity check (100ms instead of 7900ms). My point is that, connectivity checks through TURN servers are not likely to fail; such checks are usually the last resort anyway. What I was asking for was a network topology and use case where this would allow ICE to succeed overall, and do so faster. Also keep in mind that subsequent checks may succeed before a previous one times out, and so you wouldn't normally go the entire 7900ms anyway. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Dec 15 15:00:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3dBu-0004wM-2X; Sat, 15 Dec 2007 15:00:54 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J3dBt-0004wE-83 for behave-confirm+ok@megatron.ietf.org; Sat, 15 Dec 2007 15:00:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3dBs-0004w5-TX for behave@ietf.org; Sat, 15 Dec 2007 15:00:52 -0500 Received: from server.implementers.org ([69.55.225.91]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3dBs-0000bk-GX for behave@ietf.org; Sat, 15 Dec 2007 15:00:52 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id AAE41D9D403A; Sat, 15 Dec 2007 12:00:51 -0800 (PST) Received: from [192.168.1.3] (c-24-4-253-5.hsd1.ca.comcast.net [24.4.253.5]) by server.implementers.org (Postfix) with ESMTP id 07E46D9D4038; Sat, 15 Dec 2007 12:00:49 -0800 (PST) Message-ID: <47643270.10006@acm.org> Date: Sat, 15 Dec 2007 12:00:48 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071008) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [BEHAVE] Transport of ICMP errors in TURN References: <4748913B.8090806@acm.org> <47630CC7.10103@cisco.com> <476330F6.3020604@acm.org> <4763D856.2070204@cisco.com> In-Reply-To: <4763D856.2070204@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Jonathan Rosenberg wrote: > > > Marc Petit-Huguenin wrote: > >>> Generally I am in favor of keeping TURN as minimal as we can, and I >>> don't see a compelling use case for this, so I'm inclined to say that we >>> shouldn't do this. Can you give some example use cases where this would >>> really improve things? >> >> The main use case is the one described below, to accelerate the failure >> of an ICE connectivity check (100ms instead of 7900ms). > > My point is that, connectivity checks through TURN servers are not > likely to fail; such checks are usually the last resort anyway. What I > was asking for was a network topology and use case where this would > allow ICE to succeed overall, and do so faster. Also keep in mind that > subsequent checks may succeed before a previous one times out, and so > you wouldn't normally go the entire 7900ms anyway. No, I do not have such use case. -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 17 11:15:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Icm-0001go-0g; Mon, 17 Dec 2007 11:15:24 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J3Fsy-0001xG-0x for behave-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 14:07:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Fsx-0001x8-LF for behave@ietf.org; Fri, 14 Dec 2007 14:07:47 -0500 Received: from mail7.exchange.microsoft.com ([131.107.1.27] helo=mail.exchange.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3Fsx-0006MC-0o for behave@ietf.org; Fri, 14 Dec 2007 14:07:47 -0500 Received: from df-bhd-01.exchange.corp.microsoft.com (157.54.54.216) by DF-GWY-07.exchange.corp.microsoft.com (157.54.63.164) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 14 Dec 2007 11:07:56 -0800 Received: from DF-GRTDANE-MSG.exchange.corp.microsoft.com ([157.54.62.10]) by df-bhd-01.exchange.corp.microsoft.com ([157.54.54.216]) with mapi; Fri, 14 Dec 2007 11:07:56 -0800 From: Tim Moore To: Lars Eggert , ext Jonathan Rosenberg Date: Fri, 14 Dec 2007 11:07:43 -0800 Subject: RE: [BEHAVE] TURN Issue #1: Bandwidth Param Thread-Topic: [BEHAVE] TURN Issue #1: Bandwidth Param Thread-Index: Acg+Yp+1UTKreoP7R4iqCiGZmCrLVwAHKlIA Message-ID: <1E0553FC0611394BB2B8C38A0E99AA9BCBA2F62A01@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <47599BE6.9090903@cisco.com> <47620F2B.4060200@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be X-Mailman-Approved-At: Mon, 17 Dec 2007 11:15:22 -0500 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 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com] > Sent: Friday, December 14, 2007 7:02 AM > To: ext Jonathan Rosenberg > Cc: Behave WG > Subject: Re: [BEHAVE] TURN Issue #1: Bandwidth Param > > Hi, > > On 2007-12-14, at 7:05, ext Jonathan Rosenberg wrote: > > The presumption is that the server has a relationship with the > > client and is there to support a particular application (say, voip). > > And so, if the client includes the value the server is likely to > > honor it and not drop data below that rate. If the client includes > > nothing the server might choose to rate limit at a value that is > > below what the client actually needs. So the client is incented to > > include it. > > I think my disconnect has been that I don't view the TURN server as an > entity that enforces any sort of transmission behavior or capacity > use. A TURN server should be a packet relay, plain and simple. It's > basically a router that routes between a bunch of virtual TCP- or UDP- > encapsulation interfaces and the Internet. TURN provides management > for these virtual interfaces as well as data encapsulation. Nothing > more, nothing less. > > If specific deployment cases require a QoS enforcement point on such a > router, we have a number of existing protocols that should be used to > control this function, instead incorporating this functionality into > TURN. > > >> But this doesn't tell the client all that much. Yes, if it stays > >> below the limit, it can be sure that the server doesn't rate-limit > >> it, but congestion on the path can happen before that rate is > >> reached, i.e., the client can't depend on it. And because the > >> server may forward traffic that exceeds this rate, the client has > >> every incentive to see if it can send more than the signaled rate. > > > > This parameter is really only primarily useful for fixed rate > > applications for voip. For variable rate I agree its largely useless. > > But even for CBR it doesn't provide any guarantees, because congestion > can happen before the signaled capacity is reached. (Unless TURN ties > in with a "real" QoS mechanism, in which case why isn't that protocol > used to manage QoS instead of TURN?) It doesn't provide guarantees but its still useful. The server bandwidth is= not used as a "guarantee" of the rate that the server will support but its= used as an upper limit that the server may support. Admins can decide that= they are willing to reduce the quality of calls via the TURN server to inc= rease the number of users a TURN server can support. The client wants to lo= ok at the server bandwidth number so its congestion algorithm can optimize = the quality for this case. An example would be a client that can send video at up to 2Mbps, a TURN ser= ver if it supports 1Gbps line rate only supports 500 connections at this sp= eed, if you want to support more the server will need to rate limit the tra= ffic. The server can do this without telling the client since the client wi= ll have congestion control to handle losses. However, if the client doesn't= know about the server limit then it will want to try to increase its throu= ghput to 2Mbps to provide the best quality. Every time it hits the server r= ate limit it will cause a packet lost which causes a quality drop. If it kn= ows about the limit it can stay under the limit. It will still need to hand= le other congestion issues but the number of packet losses will be lower if= the TURN server is the main bottleneck. This will mean the quality will be= higher since the client can now stay closer to the server limit without ca= using the server to drop packets. > > >> TURN isn't a QoS-signaling solution, so I'm all for removing this > >> option. > > > > No, but TURN servers do provide a service (media relay of traffic) > > and it seems sensible for clients to ask for a particular level of > > service and be told if they get it or not. > > TURN relays IP packets. Nothing in IP lets clients ask for a > particular level of service. TURN can only be used to turn some knobs > on the TURN server, which are unlikely to have much effect for the end- > to-end path that the client flow is traversing. > > Lars > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 17 19:46:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Qbg-0002a5-QT; Mon, 17 Dec 2007 19:46:48 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J4Qbg-0002X8-7n for behave-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 19:46:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Qbf-0002Wz-U4 for behave@ietf.org; Mon, 17 Dec 2007 19:46:47 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4Qbf-0005r2-Ez for behave@ietf.org; Mon, 17 Dec 2007 19:46:47 -0500 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J4Qbf-0001py-03; Mon, 17 Dec 2007 19:46:47 -0500 In-Reply-To: <8BB50A79-8FC7-4158-9684-2BBBF7740036@nokia.com> References: <4759CD14.10208@cisco.com> <152D0B93-6269-4B44-A313-1D90EE6E8E73@nokia.com> <4762116C.3080106@cisco.com> <0B26C595-C3F5-4546-87DB-1732460BD75C@nokia.com> <47630B03.3050708@cisco.com> <8BB50A79-8FC7-4158-9684-2BBBF7740036@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #5: Port Range Date: Mon, 17 Dec 2007 19:45:55 -0500 To: Lars Eggert X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I like this resolution as well. - Philip On 15-Dec-07, at 03:01 , Lars Eggert wrote: > On 2007-12-15, at 1:00, ext Jonathan Rosenberg wrote: >> The spec says SHOULD be limited to the dynamic range as you >> suggest. However, as with other SHOULDs, it gives conditions under >> which you can violate this should. Then it talks about cases where >> no other applications run on the server, and where firewalls >> aren't blocking ports, and if you know these aren't problems it is >> OK to grab other ports. This would allow vendors of standalone >> TURN servers to use the full range since both of these conditions >> exist there. However, if TURN is run in an endpoint like a p2psip >> peer, it would use the more limited range, which is fine anyway >> for that use case. >> >> Sound OK? > > Yes, this is a good resolution. > > Thanks, > Lars > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 17 20:13:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4R1Y-00076w-Tf; Mon, 17 Dec 2007 20:13:32 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J4R1X-00076r-OK for behave-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 20:13:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4R1X-00076h-Cj for behave@ietf.org; Mon, 17 Dec 2007 20:13:31 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4R1W-0007Lh-SI for behave@ietf.org; Mon, 17 Dec 2007 20:13:31 -0500 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J4R1W-0006gF-1o; Mon, 17 Dec 2007 20:13:30 -0500 In-Reply-To: <4763322F.5080108@acm.org> References: <47599BE6.9090903@cisco.com> <4759AFD5.7030200@acm.org> <4760B54A.1040508@cisco.com> <476156CC.2040902@acm.org> <47620DC5.3070501@cisco.com> <4763322F.5080108@acm.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <24F3D2CE-F81F-4551-AB80-D54DF8E14D03@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #1: Bandwidth Param Date: Mon, 17 Dec 2007 20:13:21 -0500 To: Marc Petit-Huguenin , Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I am thinking that it might be cleaner to move the BANDWIDTH attribute from the Allocate transaction to the ChannelBind transaction (assuming EKR's channel allocation proposal). This would have the following benefits: * The client can wait to specify the bandwidth until after the Offer/ Answer exchange, when it knows the codec and also knows how many peers it will have. * The client can specify the bandwidth to each peer separately, which is especially helpful under the long-lived allocation model. * Marc's concern could be addressed by allocating some small amount of bandwidth to peers which have not yet been assigned a channel number, enough to do ICE connectivity checks. Comments? - Philip On 14-Dec-07, at 20:47 , Marc Petit-Huguenin wrote: > Jonathan Rosenberg wrote: >> Right - I was assuming that the client drops the allocation if it >> doesn't use it. >> >> If you want to assume non-cooperative clients (ones that don't drop >> their allocations when they don't use them), bandwidth anyway >> won't be >> useful. Clients might decide to just not use the 'this is actually >> ice' >> flag, since they have no incentive to do so, and you're right back in >> the same boat. > > You are right. > >> >> -JOnathan R. >> >> Marc Petit-Huguenin wrote: >>> Jonathan Rosenberg wrote: >>>> inline: >>>> >>>> Marc Petit-Huguenin wrote: >>>>> Jonathan Rosenberg wrote: >>>>>> Please comment if you are happy (or not) with keeping >>>>>> bandwidth with >>>>>> these proposed semantics. >>>>>> >>>>> I am OK with keeping bandwidth, but I would like to add one >>>>> thing. The >>>>> problem with bandwidth is when TURN is used with ICE. A TURN >>>>> allocation >>>>> will be made but it will generally not be used excepted for >>>>> connectivity >>>>> checks (i.e. far less than the bandwidth that will be used for >>>>> video). >>>>> So most TURN servers used in an ICE environment will either >>>>> oversubscribe or waste resources. >>>> That wouldn't be a problem, normally. >>>> >>>> So when a client uses ICE it would do the allocation and provide >>>> the >>>> bandwidth that would be used if TURN is selected. If TURN is not >>>> selected, the client will, after ICE completes, drop the >>>> allocation. >>>> Thus, at any point in time, the allocations on the server will >>>> be all of >>>> those that are actually using TURN, plus a small number (those >>>> that have >>>> just arrived and for which TURN has not yet completed) that are >>>> only so >>>> far doing ICE. Law of large numbers would argue that for any >>>> reasonable >>>> server capacity, the overall capacity is dominated by the in-use >>>> allocations and not the transient ones. >>>> >>> >>> Yes, but it works only if the client drops the allocation and we >>> do not >>> have the deployment experience to know how the ICE endpoints will >>> implement this. This can be added as an extension later if >>> needed or a >>> TURN server can collect statistics and guess the intent by >>> inspecting >>> the application data forwarded. >>> >> > > > -- > Marc Petit-Huguenin [ ] > Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] > Work: marc@8x8.com [ ] > [ ] > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Dec 17 23:04:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4ThN-0000Gz-KB; Mon, 17 Dec 2007 23:04:53 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J4ThL-0000Fj-Rq for behave-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 23:04:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4ThL-0000Et-FG for behave@ietf.org; Mon, 17 Dec 2007 23:04:51 -0500 Received: from mxout-03.mxes.net ([216.86.168.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4ThK-0002uF-RF for behave@ietf.org; Mon, 17 Dec 2007 23:04:51 -0500 Received: from [172.26.30.134] (unknown [202.152.240.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id B757623E4A0 for ; Mon, 17 Dec 2007 23:04:24 -0500 (EST) Message-ID: <47674574.8070501@pjsip.org> Date: Tue, 18 Dec 2007 03:58:44 +0000 From: Benny Prijono User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Subject: [BEHAVE] TURN: Long lived allocation case X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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, From what I've heard from the discussion so far, it sounded like folks doesn't consider long lived allocation as the expected use case for TURN. Are there any specific reasons for this? Because I think long live allocation is a good idea, and that's what I plan to do with TURN client (on SIP+ICE scenario). For SIP+ICE+TURN client use case, the scenario for using the ICE media transport would be: allocate the sockets, get STUN candidate, do Allocate request to get relayed candidate, and keep these ICE media transports alive until the application is shutdown. The same ICE media transport will be reused for subsequent calls. Yes there are pros and cons with long lived allocations: PROS: - it mimics what we do with the SIP transport (i.e. create socket, find the STUN mapped address, perform registration, and keep this binding open all the time), so we have some sort of experience with using this approach. - it simplifies call's state machine, as the media transport will always be available when it's needed. No need to wait for media transport asynchronously, as would happen if we have to create the media transport before the call. - it speeds up call's dial delay (no need to wait for STUN and TURN resolutions). CONS: - client need to know how many ICE transports to pre-allocate, but this is application and not protocol issue. - if clients preallocate TURN transports, and if clients support multiple calls in the application, this will create significant- ly more TURN allocations in the TURN servers. This problem could be mitigated with allowing BANDWIDTH=0 in TURN. - need to do keep alive, which raises some concerns with power consumption. But we need to keep-alive the SIP socket anyway, so this problem is not specific to STUN/TURN. - need to handle address change scenario (i.e. NAT is restarted) - there is a window of failure when NAT is restarted between the keep-alive interval, and a call occurs at this time. In this case, the client will (wrongly) advertise the old mapping in the SDP. But again, this problem is not specific to TURN, as it could happen with SIP as well. So because of the benefits above, I think long lived allocation is a good idea, and some folks will use this approach anyway, so TURN should be made to support this use case. This use case relates to few issues being discussed: - BANDWIDTH. With clients pre-allocate TURN candidates, server will see more bandwidth being requested even though most clients are idle. If we allow BANDWIDTH=0 then client can be made more cooperative, by requesting BANDWIDTH=0 when the TURN transport is idle. - Channel number space. Since client reuses the same TURN allocation for subsequent calls, it will require slightly more channels, as previous channels (allocated for the previous calls) don't get released immediately after call is released. This is not a major problem for this use case, and 32767 is more than sufficient, but perhaps we could make the situation better by creating ChannelUnBind mechanism to immediately release the channel number? Comments? -- 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 Dec 17 23:10:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Tmg-0006Qr-LA; Mon, 17 Dec 2007 23:10:22 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J4Tmf-0006Qm-0X for behave-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 23:10:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Tme-0006Qe-NB for behave@ietf.org; Mon, 17 Dec 2007 23:10:20 -0500 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4Tmc-0002I4-In for behave@ietf.org; Mon, 17 Dec 2007 23:10:20 -0500 Received: from [172.26.30.134] (unknown [202.152.240.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 63AE223E4A0; Mon, 17 Dec 2007 23:10:05 -0500 (EST) Message-ID: <47674804.9090605@pjsip.org> Date: Tue, 18 Dec 2007 04:09:40 +0000 From: Benny Prijono User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #1: Bandwidth Param References: <47599BE6.9090903@cisco.com> <4759AFD5.7030200@acm.org> <4760B54A.1040508@cisco.com> <476156CC.2040902@acm.org> <47620DC5.3070501@cisco.com> <4763322F.5080108@acm.org> <24F3D2CE-F81F-4551-AB80-D54DF8E14D03@magma.ca> In-Reply-To: <24F3D2CE-F81F-4551-AB80-D54DF8E14D03@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 (-) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Philip Matthews wrote: > I am thinking that it might be cleaner to move the BANDWIDTH attribute > from the Allocate transaction to the ChannelBind transaction (assuming > EKR's channel allocation proposal). This would have the following benefits: > * The client can wait to specify the bandwidth until after the > Offer/Answer exchange, when it knows the codec and also knows how many > peers it will have. > * The client can specify the bandwidth to each peer separately, which is > especially helpful under the long-lived allocation model. The same can be achieved with Allocate/Refresh model as well. For long-lived allocation, client can send Refresh with maximum bandwidth before sending offer, then updating BANDWIDTH with the actual bandwidth after offer/answer, and then setting BANDWIDTH to minimum when the call has been cleared. The benefit of this approach over ChannelBind with BANDWIDTH are: - bandwidth can be updated at any time. Currently we don't have ChannelUnBind and mechanism to refreshing ChannelBind, so with ChannelBind model, once bandwidth is requested it cannot be changed. - it works for peers that have not been assigned channel number - it requires less transaction to update the bandwidth (one for the whole media session, not one for each channel) > * Marc's concern could be addressed by allocating some small amount of > bandwidth to peers which have not yet been assigned a channel number, > enough to do ICE connectivity checks. How could you do that if you don't want to assign channel number for the peer? By the way, an open issue: should BANDWIDTH=0 be allowed? Allowing BANDWIDTH=0 could help with long lived allocation (client sends BANDWIDTH=0 when the call is idle). It looks like the spec currently doesn't disallow it, so perhaps this could be allowed explicitly. There should be no special semantic for BANDWIDTH=0, i.e. it does not change both the allocation, permission, and channel timers. cheers, -benny > Comments? > - Philip > > On 14-Dec-07, at 20:47 , Marc Petit-Huguenin wrote: > >> Jonathan Rosenberg wrote: >>> Right - I was assuming that the client drops the allocation if it >>> doesn't use it. >>> >>> If you want to assume non-cooperative clients (ones that don't drop >>> their allocations when they don't use them), bandwidth anyway won't be >>> useful. Clients might decide to just not use the 'this is actually ice' >>> flag, since they have no incentive to do so, and you're right back in >>> the same boat. >> >> You are right. >> _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 18 01:26:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4VuB-0001w3-Sh; Tue, 18 Dec 2007 01:26:15 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J4Vu9-0001vy-SQ for behave-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 01:26:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Vu8-0001vo-24 for behave@ietf.org; Tue, 18 Dec 2007 01:26:13 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4Vu7-00059b-Bc for behave@ietf.org; Tue, 18 Dec 2007 01:26:11 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 17 Dec 2007 22:26:08 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBI6Q869019567; Mon, 17 Dec 2007 22:26:08 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id lBI6Q7LF012192; Tue, 18 Dec 2007 06:26:07 GMT In-Reply-To: <47620CD5.3010304@cisco.com> References: <4759D19B.50005@cisco.com> <4760B1A0.6080807@cisco.com> <9B05C6FD-FF8A-4472-966E-D13C8573A9BF@magma.ca> <5D6A5A89-18B3-49A3-B852-EF0982730E35@magma.ca> <47620CD5.3010304@cisco.com> Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4ECA60E2-558A-4EA8-8D08-53DCFE34C661@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages Date: Mon, 17 Dec 2007 22:25:22 -0800 To: Philip Matthews X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3948; t=1197959168; x=1198823168; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20Issue=20#6=3A=20Frami ng=20header=20for=20actual=20TURN=20messages |Sender:=20; bh=3nYIES6D7jp/hClLHNI+hrSXUWhse8/yHLQH/9pPxqE=; b=kgAw3qOZy2GeCcV0C+wt3S48n/RRKRgKPeXYn2y+AMLb/gHjIsK6kUBF8V HsN6J6qol4E2r0iHXZYO7UCgmO5oiRekcbpEG0znxTDfH60p0plphe/6wmtu n5p8/kaOib; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I'm not following the use case for a large number of channels. If the issues is number of simultaneous channels, you just just form another connection form client to TURN server and you have a fresh set of channels (assuming the TURN server has enough ports). If the issues if you want a certain port to be long term stable, then TURN does not look like a good protocol to use because if you loose the port, there is no way to get a specific port back. And this limitation seems to be a positive design features of protocol. I'm not making an argument here one way or the other but could you clarify what might be a use case for the more than say a few hundred channels? Thanks, Cullen On Dec 13, 2007, at 8:55 PM, Jonathan Rosenberg wrote: > > > Philip Matthews wrote: >> I still don't really see the argument for this approach, but I >> will note that if we change the approach to use "11" as the >> initial two bits, then we are only throwing away 16535 channels, >> rather than 32767. > > How is that? I must be missing something. This would throw even > more away since it leaves only 14 bits for channel ID. > >> Given this, perhaps it is worthwhile finding a way to reuse old >> channel numbers. > > I remain unconvinced in this use case really. THe main reason is > that you STILL need some kind of rendezvous protocol before you can > use the allocation with a new peer, and this rendezvous can provide > the allocated IP and port anyway, so what is the big deal about > using a new one for new peers when you run out of channels? Even in > the HIP case, you are exchanging the allocated IP/port so I don't > see the problem. > > I have thought about reuse of channel and it is possible. > Fortunately the framing header allows us to get rid of the timing > and race conditions that plagued set active destination. > > We'd steal a bit from the channel space and make this the 'flip' > bit. For any new channel binding this value is zero in ChannelBind > and zero in the framing header. > > At some point later the client can change the binding. To do that, > it sends a new CHannelBind request for the same channel, but a > different peer IP/port. It also flips the value of the flip bit > (from zero to one). Once the client gets a response, it can begin > sending on the new channel, but does so with the value of the flip > bit changed (now a 1) in the framing header. When the server gets > data on the channel, it knows to send to the old peer while the > flip bit is zero, and the new peer when its one. Similarly, when > the server sends to the client, it sends with the flip bit of zero > prior to receipt of the new CHannelBind, and then afterwards, with > a value of 1. Data from the old peer after the flip gets sent > encapsulated. The client knows that data packets with flip bit zero > mean the old peer, and a one mean new peer. > > The client would be limited in that it could not flip again for > some duration (say one minute), to make sure any old packets in the > network clear out. After a minute both client and server forget > about the old remote peer. > > So, even though this is possible there is some complexity and I > don't see the value. > > I do see the value in having a single port however and I think this > makes the protocol simpler. > > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 18 02:07:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4WXp-0006F1-SY; Tue, 18 Dec 2007 02:07:13 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J4WXo-0006Ew-Lr for behave-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 02:07:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4WXo-0006Eo-4h for behave@ietf.org; Tue, 18 Dec 2007 02:07:12 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-05.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4WXm-0004e0-Jn for behave@ietf.org; Tue, 18 Dec 2007 02:07:12 -0500 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J4WX9-000672-09; Tue, 18 Dec 2007 02:06:31 -0500 In-Reply-To: <47674804.9090605@pjsip.org> References: <47599BE6.9090903@cisco.com> <4759AFD5.7030200@acm.org> <4760B54A.1040508@cisco.com> <476156CC.2040902@acm.org> <47620DC5.3070501@cisco.com> <4763322F.5080108@acm.org> <24F3D2CE-F81F-4551-AB80-D54DF8E14D03@magma.ca> <47674804.9090605@pjsip.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <41978A35-BBA9-4C1C-9601-58171D3C7BD2@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #1: Bandwidth Param Date: Tue, 18 Dec 2007 02:07:02 -0500 To: Benny Prijono X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 17-Dec-07, at 23:09 , Benny Prijono wrote: > Philip Matthews wrote: >> I am thinking that it might be cleaner to move the BANDWIDTH >> attribute from the Allocate transaction to the ChannelBind >> transaction (assuming EKR's channel allocation proposal). This >> would have the following benefits: >> * The client can wait to specify the bandwidth until after the >> Offer/Answer exchange, when it knows the codec and also knows how >> many peers it will have. >> * The client can specify the bandwidth to each peer separately, >> which is especially helpful under the long-lived allocation model. > > The same can be achieved with Allocate/Refresh model as well. For > long-lived allocation, client can send Refresh with maximum > bandwidth before sending offer, then updating BANDWIDTH with the > actual bandwidth after offer/answer, and then setting BANDWIDTH to > minimum when the call has been cleared. > > The benefit of this approach over ChannelBind with BANDWIDTH are: > - bandwidth can be updated at any time. Currently we don't have > ChannelUnBind and mechanism to refreshing ChannelBind, so with > ChannelBind model, once bandwidth is requested it cannot be > changed. Good point. > - it works for peers that have not been assigned channel number Err.. If it hasn't been assigned a channel number, then that presumably means it is not important. > - it requires less transaction to update the bandwidth (one for > the whole media session, not one for each channel) But presumably one updates the bandwidth every time a peer gets added, so I don't really see this. > > >> * Marc's concern could be addressed by allocating some small >> amount of bandwidth to peers which have not yet been assigned a >> channel number, enough to do ICE connectivity checks. > > How could you do that if you don't want to assign channel number for > the peer? The idea is that, if it is not worthwhile assigning a peer a channel number, then that peer is not (yet) important and doesn't deserve much bandwidth. With ICE, it only becomes important once it gets selected to carry the media stream. At that point, it gets assigned a channel and a bandwidth. Never-the-less, I think the point about no way to update the bandwidth on a channel is a good one. I think this would have to be fixed to go with my idea. > > By the way, an open issue: should BANDWIDTH=0 be allowed? > Allowing BANDWIDTH=0 could help with long lived allocation (client > sends BANDWIDTH=0 when the call is idle). It looks like the spec > currently doesn't disallow it, so perhaps this could be allowed > explicitly. There should be no special semantic for BANDWIDTH=0, > i.e. it does not change both the allocation, permission, and channel > timers. Don't see why is should not be allowed. On a different issue, I am trying to understand how to work with applications that do not have an obvious bandwidth value. A file transfer or a control channel, for example. I can see how TURN servers that work with streaming media might require and enforce the BANDWIDTH parameter, and other TURN servers that work as relays for non-streaming-media might just ignore the BANDWIDTH parameter, but it there a reasonable way to mix the two types of traffic on the same TURN server? I am still struggling with that one... - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 18 02:30:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Wtv-00058Z-5L; Tue, 18 Dec 2007 02:30:03 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J4Wtu-00058Q-PE for behave-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 02:30:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Wtu-00058I-Dp; Tue, 18 Dec 2007 02:30:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4Wtu-00051q-2L; Tue, 18 Dec 2007 02:30:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id DBA2926E86; Tue, 18 Dec 2007 07:30:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J4Wtt-0000Kd-Q8; Tue, 18 Dec 2007 02:30:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 18 Dec 2007 02:30:01 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-stun-test-vectors-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 : Test vectors for STUN Author(s) : R. Denis-Courmont Filename : draft-ietf-behave-stun-test-vectors-00.txt Pages : 8 Date : 2007-12-17 This document includes test vectors for the MESSAGE-INTEGRITY and FINGERPRINT attributes of the STUN protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-stun-test-vectors-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-stun-test-vectors-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-stun-test-vectors-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-12-18022501.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-stun-test-vectors-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-stun-test-vectors-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-18022501.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 Dec 18 05:12:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4ZQe-00053r-Hp; Tue, 18 Dec 2007 05:12:00 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J4ZQd-0004zy-63 for behave-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 05:11:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4ZQc-0004x2-L9 for behave@ietf.org; Tue, 18 Dec 2007 05:11:58 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4ZQc-0004d1-0w for behave@ietf.org; Tue, 18 Dec 2007 05:11:58 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBIABbd9003010; Tue, 18 Dec 2007 12:11:55 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 12:11:50 +0200 Received: from esdhcp04323.research.nokia.com ([172.21.43.23]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 12:11:50 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] TURN: Long lived allocation case Date: Tue, 18 Dec 2007 12:12:01 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <47674574.8070501@pjsip.org> In-Reply-To: <47674574.8070501@pjsip.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200712181212.01928.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 18 Dec 2007 10:11:50.0230 (UTC) FILETIME=[67AECF60:01C8415E] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Le Tuesday 18 December 2007 05:58:44 ext Benny Prijono, vous avez =E9crit= =A0: > From what I've heard from the discussion so far, it sounded like > folks doesn't consider long lived allocation as the expected use > case for TURN. Are there any specific reasons for this? Because I > think long live allocation is a good idea, and that's what I plan to > do with TURN client (on SIP+ICE scenario). There is long-lived and very long-lived. With the huge number of channels that there is, you can always reallocate a= =20 new TURN allocation when you run out of channel numbers, if ever. I think=20 most SIP UA will eventually be restarted before this happens, but anyway. I expect the cost of handling running out of channel be no worse than that = of=20 handling channel reallocation (which is intricate due to UDP race condition= =20 issues). > For SIP+ICE+TURN client use case, the scenario for using the ICE > media transport would be: allocate the sockets, get STUN candidate, > do Allocate request to get relayed candidate, and keep these ICE > media transports alive until the application is shutdown. The same > ICE media transport will be reused for subsequent calls. > Yes there are pros and cons with long lived allocations: > > PROS: > - it mimics what we do with the SIP transport (i.e. create socket, > find the STUN mapped address, perform registration, and keep > this binding open all the time), so we have some sort of > experience with using this approach. Broken. You'd need SIP outbound to handle this correctly. > - it simplifies call's state machine, as the media transport will > always be available when it's needed. No need to wait for > media transport asynchronously, as would happen if we have to > create the media transport before the call. Won't work. > - it speeds up call's dial delay (no need to wait for STUN and > TURN resolutions). Won't work. You could "cache" the TURN allocation, but caching the reflexiv= e=20 address STUN harms reliability. You would start betting against so-called=20 second and third order behavior of NATs. Sorry, but quite many NATs do look= =20 like they are nice over a short time interval, but are turn into nasty=20 symmetric ones over extended period of time. (...) > Comments? Since I think your use case is a bad idea from a technical perspective, I h= ave=20 not much sympathy for dealing with it inside TURN. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 18 08:41:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4ch2-00006u-Sf; Tue, 18 Dec 2007 08:41:08 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J4ch1-00006p-5k for behave-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 08:41:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4ch0-00006h-Rz for behave@ietf.org; Tue, 18 Dec 2007 08:41:06 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-07.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4ch0-0006ap-Cs for behave@ietf.org; Tue, 18 Dec 2007 08:41:06 -0500 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J4cgv-0000MU-1V; Tue, 18 Dec 2007 08:41:01 -0500 In-Reply-To: <4ECA60E2-558A-4EA8-8D08-53DCFE34C661@cisco.com> References: <4759D19B.50005@cisco.com> <4760B1A0.6080807@cisco.com> <9B05C6FD-FF8A-4472-966E-D13C8573A9BF@magma.ca> <5D6A5A89-18B3-49A3-B852-EF0982730E35@magma.ca> <47620CD5.3010304@cisco.com> <4ECA60E2-558A-4EA8-8D08-53DCFE34C661@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <30C5AFE6-C9FC-40FE-8A74-80B568FBD554@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages Date: Tue, 18 Dec 2007 08:40:57 -0500 To: Cullen Jennings X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Consider the following scenario. Node X is behind a "bad" NAT. Node X might be a peer in a p2psip overlay wanting to form peer protocol connections with other peers, or it might be a node running HIP that wants to communicate with other nodes. Node X allocates a relay address then signals that address to other nodes. _IF_ there was a way to de-allocate channels, and _IF_ TURN supported a sufficiently large number of channels, then node X could get away with just the one allocation. When it wanted to talk to a new node, it would signal with the one relay address it got from the allocation, rather than getting a new allocation. The point is that the code could be written to just deal with a single allocation. On 18-Dec-07, at 01:25 , Cullen Jennings wrote: > > > I'm not following the use case for a large number of channels. If > the issues is number of simultaneous channels, you just just form > another connection form client to TURN server and you have a fresh > set of channels (assuming the TURN server has enough ports). For most nodes, 65535 is plenty of channels. Most nodes will never need more than this number of simultaneous channels. > If the issues if you want a certain port to be long term stable, > then TURN does not look like a good protocol to use because if you > loose the port, there is no way to get a specific port back. And > this limitation seems to be a positive design features of protocol. The applications mentioned above do not care which port number they get. > > I'm not making an argument here one way or the other but could you > clarify what might be a use case for the more than say a few > hundred channels? If we are writing general-purpose code that has a hard limit of no more than N channels simultaneously, then it would be nice to pick N so that we are confident we will never need to exceed that number. Perhaps I have missed something, but at least in the HIP case, 65535 is large enough for most uses. As I see it, it is insufficient in precisely those cases where 65535 ports per IP address is insufficient -- for example, for a node acting as a web server with lots and lots of web clients. Arguing that fewer channels is sufficient is just like arguing that a node with a public IP address only needs fewer port numbers -- it works in most cases, but there are cases where that is not enough ports. So what I am saying is that, if we had a way to deallocate channels and we had 65535 channels available, then most nodes could get away with just one allocation, in the same way that most nodes not using TURN can get away with just 65535 ports and one IP address. Does this make any sense? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 18 11:36:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4fQc-0004Zh-DH; Tue, 18 Dec 2007 11:36:22 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J4fQb-0004Zb-3s for behave-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 11:36:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4fQa-0004ZT-Ow for behave@ietf.org; Tue, 18 Dec 2007 11:36:20 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-08.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4fQY-0003AS-Gf for behave@ietf.org; Tue, 18 Dec 2007 11:36:20 -0500 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-08.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J4fQY-0005e0-0h; Tue, 18 Dec 2007 11:36:18 -0500 In-Reply-To: <200712181212.01928.remi.denis-courmont@nokia.com> References: <47674574.8070501@pjsip.org> <200712181212.01928.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <71869172-AD6D-492C-A79F-0A28BF56590D@magma.ca> Content-Transfer-Encoding: quoted-printable From: Philip Matthews Subject: Re: [BEHAVE] TURN: Long lived allocation case Date: Tue, 18 Dec 2007 11:35:29 -0500 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= , Benny Prijono X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Replies to both Benny's original message and Remi's response. Benny Prijono wrote: > - need to do keep alive, which raises some concerns with power > consumption. But we need to keep-alive the SIP socket anyway, > so this problem is not specific to STUN/TURN. In some applications, for example peer protocol connections in =20 P2PSIP, a node would likely always have at least one connection =20 active at any time so this is not a drawback. R=E9mi wrote: > >> - it speeds up call's dial delay (no need to wait for STUN and >> TURN resolutions). > > Won't work. You could "cache" the TURN allocation, but caching the =20 > reflexive > address STUN harms reliability. You would start betting against so-=20 > called > second and third order behavior of NATs. Sorry, but quite many NATs =20= > do look > like they are nice over a short time interval, but are turn into nasty > symmetric ones over extended period of time. I not seeing what the problem is here. If the client learns its =20 server-reflexive address from the TURN Allocate request, then it can =20 use a single keep-alive to keep both the server-reflexive and the =20 relay transport addresses alive. If the client advertises them both =20 in the ICE Offer/Answer exchange, then won't ICE handle whatever =20 behavior the NAT is currently exhibiting? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 18 11:49:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4fd2-0007uq-VR; Tue, 18 Dec 2007 11:49:12 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J4fd1-0007rW-Rj for behave-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 11:49:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4fd1-0007r9-Hn for behave@ietf.org; Tue, 18 Dec 2007 11:49:11 -0500 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4fcw-0004DO-8b for behave@ietf.org; Tue, 18 Dec 2007 11:49:11 -0500 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (8.13.8/8.13.8) with ESMTP id lBIGmXAY091343; Tue, 18 Dec 2007 08:48:33 -0800 (PST) (envelope-from ekr@networkresonance.com) Message-Id: <200712181648.lBIGmXAY091343@romeo.rtfm.com> Date: Tue, 18 Dec 2007 08:48:33 -0800 From: Eric Rescorla To: Jonathan Rosenberg Subject: Re: [BEHAVE] TURN Call Scheduled In-Reply-To: <47620977.8030006@cisco.com> References: <47620977.8030006@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org At Thu, 13 Dec 2007 23:41:27 -0500, Jonathan Rosenberg wrote: > > The TURN open issues resolution call has been scheduled. It is: > > Thursday, December 20, 4-5pm EST > Dial in: +1 408-902-3084 Is there a tool free #? > ID: 220394728 > > Web share: meetings.cisco.com > > Please let me know if you plan on attending. On this call we will go > through each of the open issues and summarize the conclusion else try to > resolve it on the call if it is still open. As always, all results will > be posted to the mailer, so please only dial in if you plan on actively > participating. I plan to attend. -Ekr _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 18 12:03:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4fqS-0001DT-HI; Tue, 18 Dec 2007 12:03:04 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J4fqR-0001Cw-35 for behave-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 12:03:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4fqQ-0001Ch-Ny for behave@ietf.org; Tue, 18 Dec 2007 12:03:02 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4fqP-0003Dr-FZ for behave@ietf.org; Tue, 18 Dec 2007 12:03:02 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 18 Dec 2007 08:51:13 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBIGpCjn005684 for ; Tue, 18 Dec 2007 08:51:12 -0800 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBIGpCLE006463 for ; Tue, 18 Dec 2007 16:51:12 GMT From: "Dan Wing" To: References: Subject: RE: [BEHAVE] I-D Action:draft-ietf-behave-stun-test-vectors-00.txt Date: Tue, 18 Dec 2007 08:51:12 -0800 Message-ID: <11d401c84196$3256d370$c6f0200a@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: AchBR9MWlu22YwEtT8ONPerqYqdb2wATcnDg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2735; t=1197996672; x=1198860672; 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]=20I-D=20Action=3Adraft-ietf-be have-stun-test-vectors-00.txt=20 |Sender:=20; bh=LZ8sOsuNlfPlN7QB00R0TFRhIxswh9w1SRDygFw3GQ0=; b=Mvdhq4+Z/aNLH/XPnJRYBnajwyKPrxaI1w6PZN6QWPBWUzUTnR+DUPR5ON pTKrNOn6WO+/F99uuZp/g/PPI3dwYh7+S87W2kp7C5MJVYWi6z2Wz3Hosqha tGNaWnA/8Q; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 was draft-denis-behave-rfc3489bis-test-vectors-02, and will be published as a separate document. The intended status of the document is Informational. -d > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Monday, December 17, 2007 11:30 PM > To: i-d-announce@ietf.org > Cc: behave@ietf.org > Subject: [BEHAVE] I-D > Action:draft-ietf-behave-stun-test-vectors-00.txt > > 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 : Test vectors for STUN > Author(s) : R. Denis-Courmont > Filename : draft-ietf-behave-stun-test-vectors-00.txt > Pages : 8 > Date : 2007-12-17 > > This document includes test vectors for the MESSAGE-INTEGRITY and > FINGERPRINT attributes of the STUN protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-stun-tes t-vectors-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-stun-test-vectors-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-stun-test-vectors-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. > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 18 12:05:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4fss-00058c-Mg; Tue, 18 Dec 2007 12:05:34 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J4fsq-000571-TJ for behave-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 12:05:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4fsq-00056q-JF for behave@ietf.org; Tue, 18 Dec 2007 12:05:32 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4fso-0004xJ-6P for behave@ietf.org; Tue, 18 Dec 2007 12:05:32 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 18 Dec 2007 09:02:06 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBIH26ro022297; Tue, 18 Dec 2007 09:02:06 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id lBIH2612020173; Tue, 18 Dec 2007 17:02:06 GMT In-Reply-To: <30C5AFE6-C9FC-40FE-8A74-80B568FBD554@magma.ca> References: <4759D19B.50005@cisco.com> <4760B1A0.6080807@cisco.com> <9B05C6FD-FF8A-4472-966E-D13C8573A9BF@magma.ca> <5D6A5A89-18B3-49A3-B852-EF0982730E35@magma.ca> <47620CD5.3010304@cisco.com> <4ECA60E2-558A-4EA8-8D08-53DCFE34C661@cisco.com> <30C5AFE6-C9FC-40FE-8A74-80B568FBD554@magma.ca> Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1C97A587-D403-48D0-B086-584F7975FC31@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages Date: Tue, 18 Dec 2007 09:01:18 -0800 To: Philip Matthews X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3245; t=1197997326; x=1198861326; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20Issue=20#6=3A=20Frami ng=20header=20for=20actual=20TURN=20messages |Sender:=20; bh=//keJuyjZDFjx4uJ+ZXC6tuQWD8Lzys5MmGY2XPc8i8=; b=qUOU4VZFGRHLvg9N5ZkZOCM8oDerT0ZyEKGhVAMLUlISe88qxDANdA9RBk s9uc3kb31d18GSBkcpu475bJwbfsIKp8IEi0Fq/pDiXF2wXPg3slsCYzn/pZ H1S3/eWqYag/pcmYJ4J4suapzkN6ztNVJtng1U/o872JWD1h60aro=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I'm assuming we will probably add a way to deallocate or close a channel for the error generation reasons I mentioned before but ignoring that ... I'm still not understanding the use case. Let's say we had 200 channels. After every 200 binding requests, you would have to do an single alloc request. Is this a problem? On Dec 18, 2007, at 5:40 AM, Philip Matthews wrote: > Consider the following scenario. Node X is behind a "bad" NAT. Node X > might be a peer in a p2psip overlay wanting to form peer protocol > connections with other peers, or it might be a node running HIP that > wants to communicate with other nodes. Node X allocates a relay > address then signals that address to other nodes. > > _IF_ there was a way to de-allocate channels, and _IF_ TURN supported > a sufficiently large number of channels, then node X could get away > with just the one allocation. When it wanted to talk to a new node, > it would signal with the one relay address it got from the > allocation, rather than getting a new allocation. > > The point is that the code could be written to just deal with a > single allocation. > > On 18-Dec-07, at 01:25 , Cullen Jennings wrote: > > > > > > > I'm not following the use case for a large number of channels. If > > the issues is number of simultaneous channels, you just just form > > another connection form client to TURN server and you have a fresh > > set of channels (assuming the TURN server has enough ports). > > For most nodes, 65535 is plenty of channels. Most nodes will never > need more than this number of simultaneous channels. > > > If the issues if you want a certain port to be long term stable, > > then TURN does not look like a good protocol to use because if you > > loose the port, there is no way to get a specific port back. And > > this limitation seems to be a positive design features of protocol. > > The applications mentioned above do not care which port number they > get. > > > > > I'm not making an argument here one way or the other but could you > > clarify what might be a use case for the more than say a few > > hundred channels? > > If we are writing general-purpose code that has a hard limit of no > more than N channels simultaneously, then it would be nice to pick N > so that we are confident we will never need to exceed that number. > > Perhaps I have missed something, but at least in the HIP case, 65535 > is large enough for most uses. As I see it, it is insufficient in > precisely those cases where 65535 ports per IP address is > insufficient -- for example, for a node acting as a web server with > lots and lots of web clients. Arguing that fewer channels is > sufficient is just like arguing that a node with a public IP address > only needs fewer port numbers -- it works in most cases, but there > are cases where that is not enough ports. > > So what I am saying is that, if we had a way to deallocate channels > and we had 65535 channels available, then most nodes could get away > with just one allocation, in the same way that most nodes not using > TURN can get away with just 65535 ports and one IP address. > > > Does this make any sense? > > - Philip > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 18 13:44:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4hQ8-00058R-Hy; Tue, 18 Dec 2007 13:44:00 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J4hQ7-00058J-A4 for behave-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 13:43:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4hQ6-00058B-VM for behave@ietf.org; Tue, 18 Dec 2007 13:43:59 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-08.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4hQ6-0006nn-JC for behave@ietf.org; Tue, 18 Dec 2007 13:43:58 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-08.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J4hQ5-00021T-1v; Tue, 18 Dec 2007 13:43:57 -0500 In-Reply-To: <1C97A587-D403-48D0-B086-584F7975FC31@cisco.com> References: <4759D19B.50005@cisco.com> <4760B1A0.6080807@cisco.com> <9B05C6FD-FF8A-4472-966E-D13C8573A9BF@magma.ca> <5D6A5A89-18B3-49A3-B852-EF0982730E35@magma.ca> <47620CD5.3010304@cisco.com> <4ECA60E2-558A-4EA8-8D08-53DCFE34C661@cisco.com> <30C5AFE6-C9FC-40FE-8A74-80B568FBD554@magma.ca> <1C97A587-D403-48D0-B086-584F7975FC31@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3E8D0268-A6CF-460B-827C-7358367FC961@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages Date: Tue, 18 Dec 2007 13:43:53 -0500 To: Cullen Jennings X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 18-Dec-07, at 12:01 , Cullen Jennings wrote: > > I'm assuming we will probably add a way to deallocate or close a > channel for the error generation reasons I mentioned before but > ignoring that ... > > I'm still not understanding the use case. Let's say we had 200 > channels. After every 200 binding requests, you would have to do an > single alloc request. Is this a problem? It is a problem only in that I now have to keep a list of allocations, rather than just one. It makes the code a bit more complex. If there is any possibility of forking or equivalent, then I should get a new allocation once my last allocation down to say 10 channels left, in case the number of peers I get back is more than 10. It probably makes debugging from traces more complex, since a node now has multiple relay addresses and thus multiple sockets. It raises the question of which server-reflexive address to use (e.g., the one from the latest allocation, or the one from the first allocation?). None of these are big problems. Jonathan's argument is that the complexity of adding channel deallocation will trump them, and I suspect he might be right, especially if long-lived allocations are a rare use. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 18 18:42:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4m4d-0002mP-3q; Tue, 18 Dec 2007 18:42:07 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J4m4b-0002Qk-AY for behave-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 18:42:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4m4a-0002PD-Un for behave@ietf.org; Tue, 18 Dec 2007 18:42:04 -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 1J4m4a-00030I-Fy for behave@ietf.org; Tue, 18 Dec 2007 18:42:04 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 18 Dec 2007 15:42:04 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBINg3DK006761; Tue, 18 Dec 2007 15:42:03 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBINg3LE004017; Tue, 18 Dec 2007 23:42:03 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 15:42:03 -0800 Received: from [64.101.76.25] ([64.101.76.25]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 15:42:03 -0800 Message-ID: <47685AF4.9030909@cisco.com> Date: Tue, 18 Dec 2007 18:42:44 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages References: <4759D19B.50005@cisco.com> <4760B1A0.6080807@cisco.com> <9B05C6FD-FF8A-4472-966E-D13C8573A9BF@magma.ca> <5D6A5A89-18B3-49A3-B852-EF0982730E35@magma.ca> <47620CD5.3010304@cisco.com> <4ECA60E2-558A-4EA8-8D08-53DCFE34C661@cisco.com> <30C5AFE6-C9FC-40FE-8A74-80B568FBD554@magma.ca> <1C97A587-D403-48D0-B086-584F7975FC31@cisco.com> <3E8D0268-A6CF-460B-827C-7358367FC961@magma.ca> In-Reply-To: <3E8D0268-A6CF-460B-827C-7358367FC961@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Dec 2007 23:42:03.0472 (UTC) FILETIME=[976EDD00:01C841CF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2323; t=1198021323; x=1198885323; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20Issue=20#6=3A=20Frami ng=20header=20for=20actual=20TURN=20messages |Sender:=20; bh=Sg8QjrrM7STCP0yswvu9a1yf2Q7FtKakwOtTvrWY5ck=; b=opVSqUQRhiJV5Oy71E4D5niZQ3zXByRkheWiRysviaKPGuF3yxfM5FxjsT 6A4WuoNXI7DlpIqmCgsPsJGcTNXd6ZPHvCU8/qpJft42TkNi5ToGeuyQh55M XUrZprCr8E; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org inline. Philip Matthews wrote: > > On 18-Dec-07, at 12:01 , Cullen Jennings wrote: > >> >> I'm assuming we will probably add a way to deallocate or close a >> channel for the error generation reasons I mentioned before but >> ignoring that ... >> >> I'm still not understanding the use case. Let's say we had 200 >> channels. After every 200 binding requests, you would have to do an >> single alloc request. Is this a problem? > > It is a problem only in that I now have to keep a list of allocations, > rather than just one. You are already having to maintain a list of channels, so I don't see why including the allocation in the list makes this harder. You are already needing the code to obtain an allocation, and you need the code to include it in the rendezvous protocol. Thus, I do not see where the savings is. > It makes the code a bit more complex. If there is > any possibility of forking or equivalent, then I should get a new > allocation once my last allocation down to say 10 channels left, in case > the number of peers I get back is more than 10. It probably makes > debugging from traces more complex, since a node now has multiple relay > addresses and thus multiple sockets. Why does that make debugging more complex? Also, lets take this p2psip case. With 32767 channels, given the number of connections to other peers that an p2psip client needs, how long will it take before this 32767 is exhausted? I bet its WAY longer than the amount of time the client would even be up. > It raises the question of which > server-reflexive address to use (e.g., the one from the latest > allocation, or the one from the first allocation?). The client should be redoing the server reflexive prior to each ice exchange. I think someone else commented, that there are cases where this can change over time. The ICE philosophy is not to assume anything. So don't assume that your old server reflexive candidate remains valid forever. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 18 18:55:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4mHl-0003yb-Cv; Tue, 18 Dec 2007 18:55:41 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J4mHk-0003yW-Qa for behave-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 18:55:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4mHk-0003xz-EW for behave@ietf.org; Tue, 18 Dec 2007 18:55:40 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4mHj-0003hb-JY for behave@ietf.org; Tue, 18 Dec 2007 18:55:40 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 18 Dec 2007 15:55:39 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBINtcaV024367; Tue, 18 Dec 2007 15:55:39 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBINtaLG015340; Tue, 18 Dec 2007 23:55:39 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 15:55:37 -0800 Received: from [64.101.76.25] ([64.101.76.25]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 15:55:37 -0800 Message-ID: <47685E22.205@cisco.com> Date: Tue, 18 Dec 2007 18:56:18 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Benny Prijono Subject: Re: [BEHAVE] TURN: Long lived allocation case References: <47674574.8070501@pjsip.org> In-Reply-To: <47674574.8070501@pjsip.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Dec 2007 23:55:37.0470 (UTC) FILETIME=[7C9D19E0:01C841D1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4882; t=1198022139; x=1198886139; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=3A=20Long=20lived=20all ocation=20case |Sender:=20; bh=o5Ey1aJzsWbZ5NnZ16LOXmMuR440ocjwOpdmJrMCOuQ=; b=jTz1ax8kHGAdNAKR3v3dHGcpyTl4ZnO+QpB1VMuiYYyX8nvHzO/54qfiL8 cOlm4TWxL4f7HTwQJ4VAMjl/PTVeU85zXiaU1T9egVMZiuqQZZOhc+jZptjg r9D9w7veGN; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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 Some comments inline: Benny Prijono wrote: > All, > > From what I've heard from the discussion so far, it sounded like folks > doesn't consider long lived allocation as the expected use case for > TURN. Are there any specific reasons for this? Because I think long live > allocation is a good idea, and that's what I plan to do with TURN client > (on SIP+ICE scenario). I think the point is not that a client will be forbidden from this, but that we will not provide a channel deallocation feature. I don't think its needed at all for the use case you are describing. > > For SIP+ICE+TURN client use case, the scenario for using the ICE media > transport would be: allocate the sockets, get STUN candidate, do > Allocate request to get relayed candidate, and keep these ICE media > transports alive until the application is shutdown. The same ICE media > transport will be reused for subsequent calls. > > Yes there are pros and cons with long lived allocations: > > PROS: > - it mimics what we do with the SIP transport (i.e. create socket, > find the STUN mapped address, perform registration, and keep > this binding open all the time), so we have some sort of > experience with using this approach. I'm not sure what it means to 'have some experience'. What is the technical or operational benefit? > - it simplifies call's state machine, as the media transport will > always be available when it's needed. No need to wait for > media transport asynchronously, as would happen if we have to > create the media transport before the call. Whether this is simpler or not, YMMV - since it trades off some things (no need to grab turn allocations ahead of time) for others (complicates interaction with turn server). > - it speeds up call's dial delay (no need to wait for STUN and > TURN resolutions). Well, you'd probably want to redo STUN to make sure the server reflexive candidate hasn't changed. Since you can do server reflexive and relayed together anyway, if you do the server reflexive at call setup time, then you gain no improvement in call setup delay by pre-allocating TURN. > > CONS: > - client need to know how many ICE transports to pre-allocate, > but this is application and not protocol issue. > - if clients preallocate TURN transports, and if clients support > multiple calls in the application, this will create significant- > ly more TURN allocations in the TURN servers. This problem could > be mitigated with allowing BANDWIDTH=0 in TURN. How does that help? All it means is now the client needs to signal to its TURN server, before call setup, that it is changing bandwidth from zero to non-zero. In that case, you have not saved any messaging to the TURN server, but you have complicated capacity management in the turn server, and added a lot of keepalives. > - need to do keep alive, which raises some concerns with power > consumption. But we need to keep-alive the SIP socket anyway, > so this problem is not specific to STUN/TURN. No, but we have effectively doubled the amount of keepalive traffic. Also the number of ports that are available on the NAT get halved or worse; each client now needs, permanently, 2 (and as many as 5 - RTP/RTCP for audio and RTP/RTCP for video and one for signaling). This puts a serious dent in the number of clients that can be supported behind a NAT with a single IP. That is a major issue. > - need to handle address change scenario (i.e. NAT is restarted) > - there is a window of failure when NAT is restarted between > the keep-alive interval, and a call occurs at this time. In > this case, the client will (wrongly) advertise the old mapping > in the SDP. But again, this problem is not specific to TURN, > as it could happen with SIP as well. No, but this window is increased with the long-lived allocations. In my mind the drawbacks far outweigh the benefits. That said, a client can go ahead and do all of this if it wants. I just don't want to add support for a channel re-bind. Instead, the client can just grab a new allocation when it runs out of channels. Anyway it'll likely reboot before then. Lets take an example. A client makes 10 calls a day (which is a lot). Each of these fork to two endpoints. This means 20 channels a day get used. With 32767 channels, thats 1638 days or 4.4 YEARS before running out of channels. The odds of a reboot of a client over 4.4 years are pretty much 100%. -Jonathan R. > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 18 18:59:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4mLK-00074q-8I; Tue, 18 Dec 2007 18:59:22 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J4mLI-0006zB-UR for behave-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 18:59:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4mLI-0006z3-Ke for behave@ietf.org; Tue, 18 Dec 2007 18:59:20 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4mLH-0003Hk-U9 for behave@ietf.org; Tue, 18 Dec 2007 18:59:20 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 18 Dec 2007 15:59:19 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBINxJ0G028968; Tue, 18 Dec 2007 15:59:19 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id lBINxAlQ029979; Tue, 18 Dec 2007 23:59:18 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 15:59:18 -0800 Received: from [64.101.76.25] ([64.101.76.25]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 15:59:18 -0800 Message-ID: <47685EFE.7080409@cisco.com> Date: Tue, 18 Dec 2007 18:59:58 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [BEHAVE] TURN Issue #1: Bandwidth Param References: <47599BE6.9090903@cisco.com> <4759AFD5.7030200@acm.org> <4760B54A.1040508@cisco.com> <476156CC.2040902@acm.org> <47620DC5.3070501@cisco.com> <4763322F.5080108@acm.org> <24F3D2CE-F81F-4551-AB80-D54DF8E14D03@magma.ca> <47674804.9090605@pjsip.org> <41978A35-BBA9-4C1C-9601-58171D3C7BD2@magma.ca> In-Reply-To: <41978A35-BBA9-4C1C-9601-58171D3C7BD2@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Dec 2007 23:59:18.0206 (UTC) FILETIME=[002EBDE0:01C841D2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4220; t=1198022359; x=1198886359; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20Issue=20#1=3A=20Bandw idth=20Param |Sender:=20; bh=N0p9BQrUDAf/h8JeI05I+ujSZFuMCYT/qbX08Oob1pw=; b=tpYuoFgwQhmOQMvKKtEsjbw83TIE9s9xbld+h55Ne18eET6t3FiHFdp5Wa n75Qv8QU1P171r2v9pr9zWzi8WlnrUSwAHp1VPbD9BNdXuSvH6p1ZZAeHvLI 0x9uUPKKU6; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Philip, I really don't see the point in starting another redesign on things to accommodate this long-lived allocation model. The use cases for this have been dubious at best, and the existing model supports them fine enough anyway. I just don't see why we should optimize or try to improve things significantly for these cases. -Jonathan R. Philip Matthews wrote: > > On 17-Dec-07, at 23:09 , Benny Prijono wrote: > >> Philip Matthews wrote: >>> I am thinking that it might be cleaner to move the BANDWIDTH >>> attribute from the Allocate transaction to the ChannelBind >>> transaction (assuming EKR's channel allocation proposal). This would >>> have the following benefits: >>> * The client can wait to specify the bandwidth until after the >>> Offer/Answer exchange, when it knows the codec and also knows how >>> many peers it will have. >>> * The client can specify the bandwidth to each peer separately, which >>> is especially helpful under the long-lived allocation model. >> >> The same can be achieved with Allocate/Refresh model as well. For >> long-lived allocation, client can send Refresh with maximum >> bandwidth before sending offer, then updating BANDWIDTH with the >> actual bandwidth after offer/answer, and then setting BANDWIDTH to >> minimum when the call has been cleared. >> >> The benefit of this approach over ChannelBind with BANDWIDTH are: >> - bandwidth can be updated at any time. Currently we don't have >> ChannelUnBind and mechanism to refreshing ChannelBind, so with >> ChannelBind model, once bandwidth is requested it cannot be >> changed. > > Good point. > >> - it works for peers that have not been assigned channel number > > Err.. If it hasn't been assigned a channel number, then that presumably > means it is not important. > >> - it requires less transaction to update the bandwidth (one for >> the whole media session, not one for each channel) > > But presumably one updates the bandwidth every time a peer gets added, > so I don't really see this. > > >> >> >>> * Marc's concern could be addressed by allocating some small amount >>> of bandwidth to peers which have not yet been assigned a channel >>> number, enough to do ICE connectivity checks. >> >> How could you do that if you don't want to assign channel number for >> the peer? > > The idea is that, if it is not worthwhile assigning a peer a channel > number, then that peer is not (yet) important and doesn't deserve much > bandwidth. With ICE, it only becomes important once it gets selected to > carry the media stream. At that point, it gets assigned a channel and a > bandwidth. > > > Never-the-less, I think the point about no way to update the bandwidth > on a channel is a good one. I think this would have to be fixed to go > with my idea. > >> >> By the way, an open issue: should BANDWIDTH=0 be allowed? >> Allowing BANDWIDTH=0 could help with long lived allocation (client >> sends BANDWIDTH=0 when the call is idle). It looks like the spec >> currently doesn't disallow it, so perhaps this could be allowed >> explicitly. There should be no special semantic for BANDWIDTH=0, >> i.e. it does not change both the allocation, permission, and channel >> timers. > > Don't see why is should not be allowed. > > > On a different issue, I am trying to understand how to work with > applications that do not have an obvious bandwidth value. A file > transfer or a control channel, for example. I can see how TURN servers > that work with streaming media might require and enforce the BANDWIDTH > parameter, and other TURN servers that work as relays for > non-streaming-media might just ignore the BANDWIDTH parameter, but it > there a reasonable way to mix the two types of traffic on the same TURN > server? I am still struggling with that one... > > - Philip > > > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Dec 18 20:04:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4nM8-00059X-Qz; Tue, 18 Dec 2007 20:04:16 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J4nM7-00059R-Ae for behave-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 20:04:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4nM7-00059J-01 for behave@ietf.org; Tue, 18 Dec 2007 20:04:15 -0500 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4nM6-0004wz-IP for behave@ietf.org; Tue, 18 Dec 2007 20:04:14 -0500 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.222.3; Tue, 18 Dec 2007 17:04:13 -0800 Received: from TK5-EXMLT-W604.wingroup.windeploy.ntdev.microsoft.com (157.54.18.7) by tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) with Microsoft SMTP Server id 8.1.222.3; Tue, 18 Dec 2007 17:02:01 -0800 Received: from NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.196]) by TK5-EXMLT-W604.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.7]) with mapi; Tue, 18 Dec 2007 17:02:01 -0800 From: Christian Huitema To: Jonathan Rosenberg , David Barrett Date: Tue, 18 Dec 2007 17:01:48 -0800 Subject: RE: [BEHAVE] TURN draft queries Thread-Topic: [BEHAVE] TURN draft queries Thread-Index: Acg9R6PD3ct0EwZzTyK5TWAkfNL02QEkiv6Q Message-ID: References: <6f6meo$446of@sj-inbound-d.cisco.com> <4760C0CE.8090301@cisco.com> In-Reply-To: <4760C0CE.8090301@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: "behave@ietf.org" X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > > Actually, if one side is symmetric and the other side is restricted > cone, > > won't TURN still be needed? > ... > > If the other side is address restricted, it will still go direct as > long > the as the guy behind the symmetric NAT has a NAT with just a single > external IP. If the other side is address and port restricted, you are > correct a TURN server would be used. Actually, that is not necessary. Suppose that the host behind the symmetric= NAT opens 256 sockets, with 256 different port numbers, and sends on each = socket a "bubble" towards the IP+Port of the port-restricted NAT. Suppose t= hen that the host behind the restricted NAT picks 256 random port numbers, = and sends 256 bubbles to the IP address of the symmetric NAT, each with a d= ifferent random port number. The birthday paradox tells that there is a 63%= chance that at least one bubble will pass through. If you are willing to o= pen more sockets, say 640, and send 640 bubbles, the chances increase to we= ll over 99%. -- Christian Huitema _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Dec 19 02:33:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4tQc-00032W-Ou; Wed, 19 Dec 2007 02:33:18 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J4tQb-0002vN-OP for behave-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 02:33:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4tQb-0002tw-3H for behave@ietf.org; Wed, 19 Dec 2007 02:33:17 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4tQa-0007k3-NO for behave@ietf.org; Wed, 19 Dec 2007 02:33:17 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBJ7XLus007189; Wed, 19 Dec 2007 01:33:43 -0600 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 09:32:49 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 09:32:49 +0200 Received: from esdhcp04323.research.nokia.com ([172.21.43.23]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 09:32:49 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Philip Matthews" Subject: Re: [BEHAVE] TURN: Long lived allocation case Date: Wed, 19 Dec 2007 09:33:01 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <47674574.8070501@pjsip.org> <200712181212.01928.remi.denis-courmont@nokia.com> <71869172-AD6D-492C-A79F-0A28BF56590D@magma.ca> In-Reply-To: <71869172-AD6D-492C-A79F-0A28BF56590D@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200712190933.02362.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 19 Dec 2007 07:32:49.0502 (UTC) FILETIME=[5B60FFE0:01C84211] X-Nokia-AV: Clean 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 Le Tuesday 18 December 2007 18:35:29 ext Philip Matthews, vous avez =E9crit= =A0: > R=E9mi wrote: > >> - it speeds up call's dial delay (no need to wait for STUN and > >> TURN resolutions). > > > > Won't work. You could "cache" the TURN allocation, but caching the > > reflexive > > address STUN harms reliability. You would start betting against so- > > called > > second and third order behavior of NATs. Sorry, but quite many NATs > > do look > > like they are nice over a short time interval, but are turn into nasty > > symmetric ones over extended period of time. > > I not seeing what the problem is here. If the client learns its > server-reflexive address from the TURN Allocate request, then it can > use a single keep-alive to keep both the server-reflexive and the > relay transport addresses alive. That only works for a "compliant" NAT. The probability that a NAT behave li= ke=20 a compliant one decreases over the lifetime of a binding. That's the whole point for using ICE instead of behavior discovery. Now, you may be assuming that all NATs are BEHAVE-compliant, but then why=20 would you need TURN at all anyway? > If the client advertises them both in the ICE Offer/Answer exchange, > then won't ICE handle whatever behavior the NAT is currently exhibiting? Yes, but that will increase the chance that the reflexive address candidate= =20 fails, and that the TURN server has to be used. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Dec 19 02:43:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4tab-00080r-0t; Wed, 19 Dec 2007 02:43:37 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J4taZ-00080m-Qa for behave-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 02:43:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4taZ-00080e-Gp for behave@ietf.org; Wed, 19 Dec 2007 02:43:35 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4taX-0004zg-UA for behave@ietf.org; Wed, 19 Dec 2007 02:43:35 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBJ7hPDd004367 for ; Wed, 19 Dec 2007 09:43:32 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 09:43:30 +0200 Received: from esdhcp04323.research.nokia.com ([172.21.43.23]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 09:43:30 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] TURN draft queries Date: Wed, 19 Dec 2007 09:43:43 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <6f6meo$446of@sj-inbound-d.cisco.com> <4760C0CE.8090301@cisco.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200712190943.43907.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 19 Dec 2007 07:43:30.0600 (UTC) FILETIME=[D980CA80:01C84212] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Le Wednesday 19 December 2007 03:01:48 ext Christian Huitema, vous avez=20 =E9crit=A0: > > If the other side is address restricted, it will still go direct as > > long the as the guy behind the symmetric NAT has a NAT with just a > > single external IP. If the other side is address and port restricted, > > you are correct a TURN server would be used. > > Actually, that is not necessary. Suppose that the host behind the symmetr= ic > NAT opens 256 sockets, with 256 different port numbers, and sends on each > socket a "bubble" towards the IP+Port of the port-restricted NAT. Suppose > then that the host behind the restricted NAT picks 256 random port number= s, > and sends 256 bubbles to the IP address of the symmetric NAT, each with a > different random port number. The birthday paradox tells that there is a > 63% chance that at least one bubble will pass through. If you are willing > to open more sockets, say 640, and send 640 bubbles, the chances increase > to well over 99%. Assuming that the NAT devices preserve the randomness of the internal port= =20 number (and I suspect many NATs allocate bindings in a linear fashion). =46urther assuming that sending 256 packets over a short period of time won= 't=20 yield nasty congestion problems. That reminds me of the ICE-TCP port prediction controversy at the last=20 meeting. Yeah sure, port prediction works better than ICE, but how many=20 minutes must I wait before the connection gets eventually established? In=20 many scenarios, the maximum is 5 to 10 seconds. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Dec 19 03:02:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4ttK-000434-T9; Wed, 19 Dec 2007 03:02:58 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J4ttJ-00042z-5Y for behave-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 03:02:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4ttI-00042r-Qm for behave@ietf.org; Wed, 19 Dec 2007 03:02:56 -0500 Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4ttI-0008MG-FH for behave@ietf.org; Wed, 19 Dec 2007 03:02:56 -0500 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.222.3; Wed, 19 Dec 2007 00:02:55 -0800 Received: from TK5-EXMLT-W603.wingroup.windeploy.ntdev.microsoft.com (157.54.18.6) by tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) with Microsoft SMTP Server id 8.1.222.3; Wed, 19 Dec 2007 00:02:55 -0800 Received: from NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.196]) by TK5-EXMLT-W603.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.6]) with mapi; Wed, 19 Dec 2007 00:02:55 -0800 From: Christian Huitema To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , "behave@ietf.org" Date: Wed, 19 Dec 2007 00:02:52 -0800 Subject: RE: [BEHAVE] TURN draft queries Thread-Topic: [BEHAVE] TURN draft queries Thread-Index: AchCEuKvM06QShDGSEuIfu9NOfuNgQAAmvzQ Message-ID: References: <6f6meo$446of@sj-inbound-d.cisco.com> <4760C0CE.8090301@cisco.com> <200712190943.43907.remi.denis-courmont@nokia.com> In-Reply-To: <200712190943.43907.remi.denis-courmont@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -108.0 (---------------------------------------------------) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 > > Actually, that is not necessary. Suppose that the host behind the > symmetric > > NAT opens 256 sockets, with 256 different port numbers, and sends on > each > > socket a "bubble" towards the IP+Port of the port-restricted NAT. > Suppose > > then that the host behind the restricted NAT picks 256 random port > numbers, > > and sends 256 bubbles to the IP address of the symmetric NAT, each > with a > > different random port number. The birthday paradox tells that there is > a > > 63% chance that at least one bubble will pass through. If you are > willing > > to open more sockets, say 640, and send 640 bubbles, the chances > increase > > to well over 99%. > > Assuming that the NAT devices preserve the randomness of the internal > port > number (and I suspect many NATs allocate bindings in a linear fashion). Sure, but if the NAT does not behave in a random fashion, then it is predic= table, and you can use various tricks to establish contact with much less t= han 256 packets. -- Christian Huitema _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Dec 19 09:29:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4zvf-0001fF-C9; Wed, 19 Dec 2007 09:29:47 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J4zve-0001f8-0X for behave-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 09:29:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4zvd-0001ex-2Z for behave@ietf.org; Wed, 19 Dec 2007 09:29:45 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-08.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4zvc-0003IM-Ml for behave@ietf.org; Wed, 19 Dec 2007 09:29:44 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-08.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J4zvb-0001KW-2c; Wed, 19 Dec 2007 09:29:43 -0500 In-Reply-To: <47685E22.205@cisco.com> References: <47674574.8070501@pjsip.org> <47685E22.205@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <03A03AEA-7CC1-4553-9EDE-F96C22C494F4@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN: Long lived allocation case Date: Wed, 19 Dec 2007 09:29:42 -0500 To: Jonathan Rosenberg , =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 18-Dec-07, at 18:56 , Jonathan Rosenberg wrote: > >> - it speeds up call's dial delay (no need to wait for STUN and >> TURN resolutions). > > Well, you'd probably want to redo STUN to make sure the server > reflexive candidate hasn't changed. Since you can do server > reflexive and relayed together anyway, if you do the server > reflexive at call setup time, then you gain no improvement in call > setup delay by pre-allocating TURN. I want to understand why you think we need to get the server- reflexive address at call time, rather than at the time we allocate the TURN relay address? As I see it, the TURN server returns a mapped address in the Allocate Response, and in addition stores this mapped address as part of the 5- tuple associated with the allocation. At every Refresh transaction, the 5-tuple must be the same, since the 5-tuple is used to identify the allocation. Thus the receipt of the successful Refresh response indicates to the client that its server-reflexive address has not changed. Furthermore, with a long-term allocation, the client can be pretty certain that it is refreshing fast enough to keep the NAT bindings alive, otherwise the Refresh transaction would fail. By contrast, it doesn't seem to necessarily know this if it just allocates a call setup time. Am I missing something? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Dec 19 09:47:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J50Ct-0000va-4n; Wed, 19 Dec 2007 09:47:35 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J50Cs-0000vV-Aa for behave-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 09:47:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J50Cs-0000vN-0u for behave@ietf.org; Wed, 19 Dec 2007 09:47:34 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J50Cq-0007Np-I4 for behave@ietf.org; Wed, 19 Dec 2007 09:47:33 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBJElY8o010853; Wed, 19 Dec 2007 08:47:56 -0600 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 16:46:56 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 16:46:55 +0200 Received: from esdhcp04323.research.nokia.com ([172.21.43.23]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 16:46:55 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Philip Matthews" Subject: Re: [BEHAVE] TURN: Long lived allocation case Date: Wed, 19 Dec 2007 16:47:08 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <47674574.8070501@pjsip.org> <47685E22.205@cisco.com> <03A03AEA-7CC1-4553-9EDE-F96C22C494F4@magma.ca> In-Reply-To: <03A03AEA-7CC1-4553-9EDE-F96C22C494F4@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200712191647.08637.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 19 Dec 2007 14:46:55.0492 (UTC) FILETIME=[FFFFAC40:01C8424D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Le Wednesday 19 December 2007 16:29:42 ext Philip Matthews, vous avez =E9cr= it=A0: > On 18-Dec-07, at 18:56 , Jonathan Rosenberg wrote: > >> - it speeds up call's dial delay (no need to wait for STUN and > >> TURN resolutions). > > > > Well, you'd probably want to redo STUN to make sure the server > > reflexive candidate hasn't changed. Since you can do server > > reflexive and relayed together anyway, if you do the server > > reflexive at call setup time, then you gain no improvement in call > > setup delay by pre-allocating TURN. > > I want to understand why you think we need to get the server- > reflexive address at call time, rather than at the time we allocate > the TURN relay address? > Furthermore, with a long-term allocation, the client can be pretty > certain that it is refreshing fast enough to keep the NAT bindings > alive, otherwise the Refresh transaction would fail. By contrast, it > doesn't seem to necessarily know this if it just allocates a call > setup time. > > Am I missing something? The client can be pretty sure that it is refreshing the binding TOWARD THE= =20 TURN SERVER. Quite many NAT implementations look like well-behaved restrict= ed=20 port Dr.Jekyll NATs over a short period of time, and transform into monster= s=20 Mr.Hyde symmetric NATs if you use the binding for a long period of time. In other word, if you have a binding with your TURN server, the chance that= =20 you will get the same external NAT port (=E0 la BEHAVE) is very high within= the=20 few seconds after the binding got created. Then it decreases over time,=20 because the NAT is not really BEHAVE compliant and start messing up things = as=20 it allocates new bindings (for other hosts behind the same NAT or for other= =20 applications on the same host), or it has some time-dependent port=20 allocation. So then, if you start sending data to anything except the TURN server, you= =20 will get a different port mapping, and voil=E0, your server-reflexive candi= date=20 won't work. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Dec 19 10:14:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J50cX-0000dl-Oi; Wed, 19 Dec 2007 10:14:05 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J50cW-0000df-IS for behave-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 10:14:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J50cW-0000dU-8D for behave@ietf.org; Wed, 19 Dec 2007 10:14:04 -0500 Received: from server.implementers.org ([69.55.225.91]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J50cV-0004Ok-Rf for behave@ietf.org; Wed, 19 Dec 2007 10:14:04 -0500 Received: by server.implementers.org (Postfix, from userid 1001) id 19DF0D9D4046; Wed, 19 Dec 2007 07:14:03 -0800 (PST) Received: from [192.168.1.3] (c-24-4-253-5.hsd1.ca.comcast.net [24.4.253.5]) by server.implementers.org (Postfix) with ESMTP id 86906D9D4048; Wed, 19 Dec 2007 07:14:00 -0800 (PST) Message-ID: <47693538.6050500@acm.org> Date: Wed, 19 Dec 2007 07:14:00 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071008) MIME-Version: 1.0 To: Jonathan Rosenberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Behave WG Subject: [BEHAVE] TURN extensions X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 Jonathan, I think that there is currently too much focus on the ICE use cases in this effort to finish TURN as quickly as possible. TURN can and will be used outside of ICE. OTOH, I certainly agree that we waited long enough to have a stable specification, so I think that we should work to have a specification that is good enough for ICE but that permit to add any extensions in the future. My proposals for ICMP, NAPTR and choosing the type of permission used certainly fall in the extension category. This said, I sent some basic comments/questions about TURN-05 that still does not have answers. I copied below the most important. Thanks. 7. Section 6.2.1.4 paragraph 6: There is no error code defined to reject a LIFETIME attribute with a too short value (as the REFRESH must be sent at 3/4 of the lifetime, and the total retransmission duration for a transaction is 7900ms, it does not make sense to accept a lifetime lower than 32 seconds). 18. Section 6.2.1.4 paragraph 6: "Note that the LIFETIME attribute an Allocate request can be zero, though this is effectively a no-op." Why authorizing this, if it effectively does nothing? See also my comment #7 above. 19. Section 6.2.2 paragraph 2: "First, the request MUST be authenticated using the same shared secret as the one associated with the allocation." What happen if the user password is changed during an allocation? 20. Section 6.2.2 There is no explanation on what can be done after an allocation expires. Is it possible to create a new one from the same source IP and port? With the same username/realm/password? -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 20 01:22:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5EnK-000855-Vr; Thu, 20 Dec 2007 01:22:10 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J5EnI-00084o-OG for behave-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 01:22:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5EnH-00084f-LF for behave@ietf.org; Thu, 20 Dec 2007 01:22:07 -0500 Received: from mxout-04.mxes.net ([216.86.168.179]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5EnG-0001Mn-Ml for behave@ietf.org; Thu, 20 Dec 2007 01:22:07 -0500 Received: from [192.168.0.12] (unknown [81.178.58.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 6683CD05A2; Thu, 20 Dec 2007 01:22:05 -0500 (EST) Message-ID: <476A09F8.5060901@pjsip.org> Date: Thu, 20 Dec 2007 06:21:44 +0000 From: Benny Prijono User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [BEHAVE] TURN: Long lived allocation case References: <47674574.8070501@pjsip.org> <47685E22.205@cisco.com> In-Reply-To: <47685E22.205@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 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 Jonathan Rosenberg wrote: > Some comments inline: > > Benny Prijono wrote: >> All, >> >> From what I've heard from the discussion so far, it sounded like >> folks doesn't consider long lived allocation as the expected use case >> for TURN. Are there any specific reasons for this? Because I think >> long live allocation is a good idea, and that's what I plan to do with >> TURN client (on SIP+ICE scenario). > > I think the point is not that a client will be forbidden from this, but > that we will not provide a channel deallocation feature. I don't think > its needed at all for the use case you are describing. I get your point, and indeed there's nothing needs to be changed for this use case to work. But the more basic question is, is this a good use case for TURN (for the benefits and drawbacks that we're discussing)? That's what I'm trying to find out. >> >> For SIP+ICE+TURN client use case, the scenario for using the ICE media >> transport would be: allocate the sockets, get STUN candidate, do >> Allocate request to get relayed candidate, and keep these ICE media >> transports alive until the application is shutdown. The same ICE media >> transport will be reused for subsequent calls. >> >> Yes there are pros and cons with long lived allocations: >> >> PROS: >> - it mimics what we do with the SIP transport (i.e. create socket, >> find the STUN mapped address, perform registration, and keep >> this binding open all the time), so we have some sort of >> experience with using this approach. > > I'm not sure what it means to 'have some experience'. What is the > technical or operational benefit? What I meant was we (implementers) have some sort of experience with using long-lived socket approach, with the SIP socket. >> - it simplifies call's state machine, as the media transport will >> always be available when it's needed. No need to wait for >> media transport asynchronously, as would happen if we have to >> create the media transport before the call. > > Whether this is simpler or not, YMMV - since it trades off some things > (no need to grab turn allocations ahead of time) for others (complicates > interaction with turn server). > >> - it speeds up call's dial delay (no need to wait for STUN and >> TURN resolutions). > > Well, you'd probably want to redo STUN to make sure the server reflexive > candidate hasn't changed. Since you can do server reflexive and relayed > together anyway, if you do the server reflexive at call setup time, then > you gain no improvement in call setup delay by pre-allocating TURN. > Both the STUN and TURN candidates are kept alive with periodic refresh, thus no need to find out the srflx candidate before the call. >> >> CONS: >> - client need to know how many ICE transports to pre-allocate, >> but this is application and not protocol issue. >> - if clients preallocate TURN transports, and if clients support >> multiple calls in the application, this will create significant- >> ly more TURN allocations in the TURN servers. This problem could >> be mitigated with allowing BANDWIDTH=0 in TURN. > > How does that help? All it means is now the client needs to signal to > its TURN server, before call setup, that it is changing bandwidth from > zero to non-zero. In that case, you have not saved any messaging to the > TURN server, but you have complicated capacity management in the turn > server, and added a lot of keepalives. The benefit is client does not need to wait for the Refresh (with non-zero bandwidth) response before making the call. If the Refresh fails, client can either cancel the call or do nothing as ICE will detect the failure. This works under the optimistic assumption that Refresh most likely will succeed of course. But true, capacity is major issue with this approach, as one TURN server now can only handle a maximum of 65535 online users, compared to 65535 active calls. And assuming that only 10% of the calls need to use TURN and client drops the allocation once ICE negotiation completes and TURN is not selected, the capacity difference will be much greater. (the 65535 number is theoretical number based on available ports. The actual number will be less of course). >> - need to do keep alive, which raises some concerns with power >> consumption. But we need to keep-alive the SIP socket anyway, >> so this problem is not specific to STUN/TURN. > > No, but we have effectively doubled the amount of keepalive traffic. Yes, although I don't think bandwidth is an issue here. Not sure what it does to power consumption though. > Also the number of ports that are available on the NAT get halved or > worse; each client now needs, permanently, 2 (and as many as 5 - > RTP/RTCP for audio and RTP/RTCP for video and one for signaling). This > puts a serious dent in the number of clients that can be supported > behind a NAT with a single IP. That is a major issue. I guess it depends on the deployment use case. For deployments where the users are home users, I don't think this is a major issue. >> - need to handle address change scenario (i.e. NAT is restarted) >> - there is a window of failure when NAT is restarted between >> the keep-alive interval, and a call occurs at this time. In >> this case, the client will (wrongly) advertise the old mapping >> in the SDP. But again, this problem is not specific to TURN, >> as it could happen with SIP as well. > > No, but this window is increased with the long-lived allocations. > > In my mind the drawbacks far outweigh the benefits. I now tend to think the same. Thanks for bearing with me. > That said, a client can go ahead and do all of this if it wants. I just > don't want to add support for a channel re-bind. Instead, the client can > just grab a new allocation when it runs out of channels. Anyway it'll > likely reboot before then. Lets take an example. A client makes 10 calls > a day (which is a lot). Each of these fork to two endpoints. This means > 20 channels a day get used. With 32767 channels, thats 1638 days or 4.4 > YEARS before running out of channels. The odds of a reboot of a client > over 4.4 years are pretty much 100%. Wait a second, so does this mean a client cannot reuse a channel number, even after it is expired (for example when the client intentionally does not send any data to refresh the permission). thanks, -benny > -Jonathan R. >> -- 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 Dec 20 13:32:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5QBh-0003fC-If; Thu, 20 Dec 2007 13:32:05 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J5QBf-0003f7-Uj for behave-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 13:32:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5QBf-0003ey-KO for behave@ietf.org; Thu, 20 Dec 2007 13:32:03 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5QBf-0007Mg-1y for behave@ietf.org; Thu, 20 Dec 2007 13:32:03 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 20 Dec 2007 10:32:02 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBKIW21E014554; Thu, 20 Dec 2007 10:32:02 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id lBKIVfXL015165; Thu, 20 Dec 2007 18:32:02 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Dec 2007 10:31:41 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Dec 2007 10:31:41 -0800 Message-ID: <476AB536.7030008@cisco.com> Date: Thu, 20 Dec 2007 13:32:22 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Benny Prijono Subject: Re: [BEHAVE] TURN: Long lived allocation case References: <47674574.8070501@pjsip.org> <47685E22.205@cisco.com> <476A09F8.5060901@pjsip.org> In-Reply-To: <476A09F8.5060901@pjsip.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Dec 2007 18:31:41.0519 (UTC) FILETIME=[90B5D5F0:01C84336] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2352; t=1198175522; x=1199039522; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=3A=20Long=20lived=20all ocation=20case |Sender:=20; bh=rfxl6iRB/UcynRwrQwcrqnH4rgzk9Pbmb/p05xB0HX8=; b=rBvB0Huu2gN5nrbJeTbVxgTx5ra+xHw10F7ZIVER8k/svMwmu76tTSxfzB fysBrRirCg7XkNLNtRNP38oRxDkatz3TI4tmO8l4xMxb1Bn+sc58XpY5yjma vfnZWQjutW; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org inline: Benny Prijono wrote: >>> - it speeds up call's dial delay (no need to wait for STUN and >>> TURN resolutions). >> >> Well, you'd probably want to redo STUN to make sure the server >> reflexive candidate hasn't changed. Since you can do server reflexive >> and relayed together anyway, if you do the server reflexive at call >> setup time, then you gain no improvement in call setup delay by >> pre-allocating TURN. >> > > Both the STUN and TURN candidates are kept alive with periodic refresh, > thus no need to find out the srflx candidate before the call. The issue isn't keepalive. I think someone else noted that a very long lived udp binding on a nat could potentially switch from restricted to symmetric; so while the binding won't change, its properties will change and you'll end up using turn when you wouldn't have otherwise. Now, that said, I have no idea what the frequency of such NAT behavior is; whether its just a few older products or more commonplace. >> That said, a client can go ahead and do all of this if it wants. I >> just don't want to add support for a channel re-bind. Instead, the >> client can just grab a new allocation when it runs out of channels. >> Anyway it'll likely reboot before then. Lets take an example. A client >> makes 10 calls a day (which is a lot). Each of these fork to two >> endpoints. This means 20 channels a day get used. With 32767 channels, >> thats 1638 days or 4.4 YEARS before running out of channels. The odds >> of a reboot of a client over 4.4 years are pretty much 100%. > > Wait a second, so does this mean a client cannot reuse a channel number, > even after it is expired (for example when the client intentionally does > not send any data to refresh the permission). Correct - it cannot reuse. Channels persist even if the permission towards the peer has expired. There is a race condition here, identical to set active destination, unless you add explicit support (per my other note) for reusing channels. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 20 15:14:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5RnE-00010C-39; Thu, 20 Dec 2007 15:14:56 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J5RnD-0000zv-C9 for behave-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 15:14:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5RnD-0000za-0I for behave@ietf.org; Thu, 20 Dec 2007 15:14:55 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-06.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5RnC-0006x6-7R for behave@ietf.org; Thu, 20 Dec 2007 15:14:54 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J5RnA-0004ft-2q; Thu, 20 Dec 2007 15:14:52 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Thu, 20 Dec 2007 15:14:52 -0500 To: Behave WG , Lars Eggert X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [BEHAVE] TURN issue: Exceeding PMTU size X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Using TURN increases the size of an application's data packet by either 4 bytes (when using the channel number header) or by approximately 36 bytes (when using Send or Data Indication) on the path between the client and the server. This extra overhead has the potential of bumping the size of an application's data packet to a value above the PMTU on the path between the client and the server, thus resulting in IP fragmentation. And IP fragmentation is known to cause problems with some NATs. The question is: Does TURN need to handle this problem, or do we just say that it is the application's problem? In my opinion, this is the application's problem. According draft- ietf-tsvwg-udp-guidelines, applications that use UDP should either use Path MTU Discovery, or restrict themselves to packets of size 576 bytes or less (over IPv4). Applications that do the former will discover the true Path MTU (including the TURN overhead), while applications doing the latter will be safe in most cases, since most Path MTUs are much larger than 576. Comments? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 20 15:49:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5SKo-0007Of-8l; Thu, 20 Dec 2007 15:49:38 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J5SKn-0007Ky-Cz for behave-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 15:49:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5SKm-0007Id-Vd for behave@ietf.org; Thu, 20 Dec 2007 15:49:37 -0500 Received: from amailer.gwdg.de ([134.76.10.18]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5SKm-0002RT-61 for behave@ietf.org; Thu, 20 Dec 2007 15:49:36 -0500 Received: from p5b03cc6f.dip0.t-ipconnect.de ([91.3.204.111] helo=[192.168.0.183]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1J5SKk-0008LW-KH for behave@ietf.org; Thu, 20 Dec 2007 21:49:34 +0100 Message-ID: <476AD55F.9070208@cs.uni-goettingen.de> Date: Thu, 20 Dec 2007 21:49:35 +0100 From: Xiaoming Fu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: behave@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:xfu X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Subject: [BEHAVE] CFP: IEEE Network Special Issue on Implications and Control of Middleboxes in the Internet X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org ... sending this CFP after Chair's approval. Xiaoming -------------------------------------------------------- Call for Papers IEEE Network Magazine Special Issue on Implications and Control of Middleboxes in the Internet Important Data ============== Manuscript Submission Due: March 1, 2008 Acceptance Notification: June 1, 2008 Final Manuscript Due: July 15, 2008 Special Issue Publication Date: September/October 2008 Call for Papers =============== Network Address Translators (NAT) and IP firewalls have been introduced to the Internet some time ago, and over the time become an integral part of the Internet architecture. Moreover, there are also other types of middleboxes, such as Virtual Private Network (VPN) gateways, Application Layer Gateways (ALG), Performance Enhancing Proxies (PEP) and web proxies. These intermediary boxes perform functions different from normal IP packet treatment, which can even change the content of packets or do rerouting of IP packets. There have been diverse views on the value of middleboxes. Some believe that middleboxes introduce problems for network applications as well as challenges to the traditional end-to-end Internet architecture. These issues range, for instance, but not limited to, from naming and addressing of nodes behind NATs, directionality of communication establishment, and performance impairments. On the other hand, many administrators and operators see the middleboxes represent an important part for their network operations. For example, firewalls are widely deployed with the intention of securing enterprise, campus and home networks, so as to block attacks to nodes or keep nodes from sending malicious traffic. The Internet community has acknowledged the emergence of the middleboxes and developed middlebox control and coordination protocols that allow end hosts (or application proxies) to learn about the presence of middleboxes and communicate their needs (i.e. required packet treatment) to those devices. A number of middlebox control protocols, such as UPnP, MIDCOM and STUN, have been developed over the years and are partially used in current deployments. The papers in this special issue will focus on the state-of-the-art research in various aspects of middleboxes and middlebox control mechanisms, which help to understand their impact to the Internet architecture and network operations, and how they can be further integrated, or leveraged for different purposes, such as load balancing and mobile network environments, among the others. Specifically, within the aforementioned context in Internet middleboxes and their control mechanisms, the special issue will present tutorials, surveys and original research articles (written in a tutorial manner readable by non-specialists) that cover the following subjects, but not limited to: * Middlebox-supported network architectures vs. other Internet evolution alternatives (e.g., IPv6) * Design and/or performance evaluation of middlebox software architectures * Control and coordination across middleboxes and their traversal mechanisms * Security, including authentication, authorization and accounting issues with middlebox control/traversal mechanisms * Scalability and performance studies of middlebox control/traversal mechanisms * Deployment scenarios and case studies (corporate, ISP, content providers, mobile environments etc.) based on middleboxes * Interaction and implications with other network protocols and components * Interaction and implications with end-to-end applications and services * Related standardization efforts Manuscript Submission ===================== With regard to both the content and formatting style of the submissions, prospective contributors must follow the IEEE Network guidelines for authors that can be found at http://www.comsoc.org/pubs/net/ntwrk/authors.html. Submitted papers must be original and must not be under current consideration for publication in other venues. Authors should submit a PDF format of their complete papers via http://www.edas.info/newPaper.php?c=6198. Guest Editors ============= Prof. Xiaoming Fu Institute for Computer Science University of Goettingen Goettingen Germany Email: fu@cs.uni-goettingen.de Martin Stiemerling NEC Europe Laboratories Network Research Division Heidelberg Germany Email: stiemerling@netlab.nec.de Prof. Henning Schulzrinne Department of Computer Science Columbia University New York, NY USA Email: hgs@cs.columbia.edu _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 20 16:01:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5SWO-0007L1-RV; Thu, 20 Dec 2007 16:01:36 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J5SWN-0007Ev-4m for behave-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 16:01:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5SWM-0007El-Aj for behave@ietf.org; Thu, 20 Dec 2007 16:01:34 -0500 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5SWL-0002py-VQ for behave@ietf.org; Thu, 20 Dec 2007 16:01:34 -0500 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id ABF735081A; Thu, 20 Dec 2007 13:01:10 -0800 (PST) Date: Thu, 20 Dec 2007 13:01:10 -0800 From: Eric Rescorla To: Jonathan Rosenberg Subject: Re: [BEHAVE] TURN Call Scheduled In-Reply-To: <200712181648.lBIGmXAY091343@romeo.rtfm.com> References: <47620977.8030006@cisco.com> <200712181648.lBIGmXAY091343@romeo.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071220210110.ABF735081A@romeo.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 This Dialin appears to be JDR's phone #. -Ekr At Tue, 18 Dec 2007 08:48:33 -0800, Eric Rescorla wrote: > > At Thu, 13 Dec 2007 23:41:27 -0500, > Jonathan Rosenberg wrote: > > > > The TURN open issues resolution call has been scheduled. It is: > > > > Thursday, December 20, 4-5pm EST > > Dial in: +1 408-902-3084 > > Is there a tool free #? > > > > ID: 220394728 > > > > Web share: meetings.cisco.com > > > > Please let me know if you plan on attending. On this call we will go > > through each of the open issues and summarize the conclusion else try to > > resolve it on the call if it is still open. As always, all results will > > be posted to the mailer, so please only dial in if you plan on actively > > participating. > > I plan to attend. > > -Ekr > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 20 16:02:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5SXR-0000xz-JG; Thu, 20 Dec 2007 16:02:41 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J5SXQ-0000wl-6X for behave-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 16:02:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5SXP-0000wd-Sv for behave@ietf.org; Thu, 20 Dec 2007 16:02:39 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5SXP-0003bP-Hf for behave@ietf.org; Thu, 20 Dec 2007 16:02:39 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 20 Dec 2007 13:02:39 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lBKL2cZF015278 for ; Thu, 20 Dec 2007 13:02:38 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id lBKL2cvL013698 for ; Thu, 20 Dec 2007 21:02:38 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Dec 2007 13:02:38 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Dec 2007 13:02:38 -0800 Message-ID: <476AD897.3090809@cisco.com> Date: Thu, 20 Dec 2007 16:03:19 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Behave WG Subject: Re: [BEHAVE] TURN Call Scheduled References: <47620977.8030006@cisco.com> In-Reply-To: <47620977.8030006@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Dec 2007 21:02:38.0378 (UTC) FILETIME=[A704D8A0:01C8434B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=948; t=1198184558; x=1199048558; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20TURN=20Call=20Scheduled |Sender:=20; bh=H1rjxquRXSzxjgNjWy5jICSccR4KtilnpT/5+eJ3tyY=; b=EeIIms3uv0o0VaLeKNm9L21PPOwc7RtZGRfirLlfAkvTfbyjcEuXqIShfj 28akjtTJubLCBvgll5Dzl7iX8zcYYMvjgBkFwSlIWyhTgLeRv1pryLqNZYC1 8tuLu0kl+k; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Big oops - the number below is actually my direct line. The dial in should be (408) 902-3019. Jonathan Rosenberg wrote: > The TURN open issues resolution call has been scheduled. It is: > > Thursday, December 20, 4-5pm EST > Dial in: +1 408-902-3084 > ID: 220394728 > > Web share: meetings.cisco.com > > Please let me know if you plan on attending. On this call we will go > through each of the open issues and summarize the conclusion else try to > resolve it on the call if it is still open. As always, all results will > be posted to the mailer, so please only dial in if you plan on actively > participating. > > Thanks, > Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 20 16:02:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5SXj-0001Z3-Ee; Thu, 20 Dec 2007 16:02:59 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J5SXi-0001XS-HT for behave-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 16:02:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5SXi-0001Up-6E for behave@ietf.org; Thu, 20 Dec 2007 16:02:58 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-09.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5SXh-0002sh-RM for behave@ietf.org; Thu, 20 Dec 2007 16:02:58 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J5SXh-0005Is-28; Thu, 20 Dec 2007 16:02:57 -0500 In-Reply-To: <20071220210110.ABF735081A@romeo.rtfm.com> References: <47620977.8030006@cisco.com> <200712181648.lBIGmXAY091343@romeo.rtfm.com> <20071220210110.ABF735081A@romeo.rtfm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <176F4AFA-954E-48C7-929A-EF00CE0775C4@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN Call Scheduled Date: Thu, 20 Dec 2007 16:02:56 -0500 To: Eric Rescorla X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Yup. He is sending out the right one in a minute On 20-Dec-07, at 16:01 , Eric Rescorla wrote: > This Dialin appears to be JDR's phone #. > > -Ekr > > At Tue, 18 Dec 2007 08:48:33 -0800, > Eric Rescorla wrote: >> >> At Thu, 13 Dec 2007 23:41:27 -0500, >> Jonathan Rosenberg wrote: >>> >>> The TURN open issues resolution call has been scheduled. It is: >>> >>> Thursday, December 20, 4-5pm EST >>> Dial in: +1 408-902-3084 >> >> Is there a tool free #? >> >> >>> ID: 220394728 >>> >>> Web share: meetings.cisco.com >>> >>> Please let me know if you plan on attending. On this call we will go >>> through each of the open issues and summarize the conclusion else >>> try to >>> resolve it on the call if it is still open. As always, all >>> results will >>> be posted to the mailer, so please only dial in if you plan on >>> actively >>> participating. >> >> I plan to attend. >> >> -Ekr >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 20 18:43:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5V35-0007v7-Gm; Thu, 20 Dec 2007 18:43:31 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J5V34-0007v1-Bi for behave-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 18:43:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5V33-0007ut-Vm for behave@ietf.org; Thu, 20 Dec 2007 18:43:29 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5V33-0007xl-5k for behave@ietf.org; Thu, 20 Dec 2007 18:43:29 -0500 X-IronPort-AV: E=Sophos;i="4.24,191,1196668800"; d="scan'208";a="23449045" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 20 Dec 2007 15:43:24 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBKNhOSe015799; Thu, 20 Dec 2007 15:43:24 -0800 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lBKNhN32003885; Thu, 20 Dec 2007 23:43:24 GMT From: "Dan Wing" To: "'Philip Matthews'" , "'Behave WG'" , "'Lars Eggert'" References: Subject: RE: [BEHAVE] TURN issue: Exceeding PMTU size Date: Thu, 20 Dec 2007 15:43:24 -0800 Message-ID: <39cb01c84362$1ce36620$c6f0200a@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.3198 In-Reply-To: Thread-Index: AchDRQZyLjL/Bk5RTz2cJlGQWYlMFQAFuokA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4706; t=1198194204; x=1199058204; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20TURN=20issue=3A=20Exceeding= 20PMTU=20size |Sender:=20; bh=4gv8Ekng8S1jAfPAkjAgWBdrTnCmjbqhecD2Hbvmyjg=; b=EFFNBGuJs4YCkjshcwLJKI5pmhk5oVafwPal/W32uTuJycJ3mkvQdZUCLg r3iGXNMJY7Lyzt13LE1XfYZwAjyjIcTq9LGsRDDBRzD09z5ifdTdsU3BklQi BOD70QRokn; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f 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: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: Thursday, December 20, 2007 12:15 PM > To: Behave WG; Lars Eggert > Subject: [BEHAVE] TURN issue: Exceeding PMTU size > > Using TURN increases the size of an application's data packet by > either 4 bytes (when using the channel number header) or by > approximately 36 bytes (when using Send or Data Indication) on the > path between the client and the server. This extra overhead has the > potential of bumping the size of an application's data packet to a > value above the PMTU on the path between the client and the server, > thus resulting in IP fragmentation. And IP fragmentation is known to > cause problems with some NATs. > > The question is: Does TURN need to handle this problem, or do > we just > say that it is the application's problem? > > In my opinion, this is the application's problem. According draft- > ietf-tsvwg-udp-guidelines, applications that use UDP should either > use Path MTU Discovery, or restrict themselves to packets of > size 576 > bytes or less (over IPv4). Applications that do the former will > discover the true Path MTU (including the TURN overhead), while > applications doing the latter will be safe in most cases, since most > Path MTUs are much larger than 576. > > Comments? I have some comments as an individual: 1. Imagine a situation where where endpoint-a is using its TURN server, and endpoint-b is not using a TURN server. This would occur if endpoint-b is behind a BEHAVE-compliant NAT, or if endpoint-b isn't behind a NAT, or endpoint-b doesn't support ICE. Here is a digram: +------+ | TURN +<-------------------+ +---+--+ | | | V | +--+--+ | | NAT | | +--+--+ | | | V | +-----+------+ +-----+------+ | endpoint-a | + endpoint-b | +------------+ +------------+ Let's imagine both endpoint-a and endpoint-b are able to do UDP path MTU discovery. endpoint-b will learn the MTU between itself and the TURN server. Both the TURN server and endpoint-a are aware of the TURN shim (4 bytes or 36 bytes) between them, and can reduce their MTU accordingly. However, what is missing is that the TURN server needs to inform endpoint-a of this TURN shim (4 bytes / 36 bytes). If the TURN server receives a UDP packet that is too large, it would need to respond with an ICMP 'too big' error to endpoint-b, so that endpoint-b has an opportunity to reduce its path MTU to the TURN server. 2. Worse is when the path between the TURN server and endpoint-a has a small MTU. Let's assume for a moment that it is really small, like 576 bytes, and the MTU between endpoint-b and the TURN server is a gigabit ethernet network with a 9000 byte MTU. If you don't like 9000 or don't like gigabit ethernet, please substitute the value 1500; the problem is the same. +------+ | TURN +<-------------------+ +---+--+ | | | | MTU=576 | MTU=9000 | | V | +-----+------+ +-----+------+ | endpoint-a | + endpoint-b | +------------+ +------------+ In this case, following my suggestion above, when the TURN server receives a 9000-byte packet, it will respond with an ICMP 'too big' message suggesting the MTU is 9000-36=8964 bytes. However, that is clearly not correct: the TURN server needs to continue refusing large datagrams until endpoint-b sends 576-byte datagrams (or smaller). To do this, the TURN server needs to learn the path MTU with endpoint-a, so that the TURN server can intelligently accept only 576-byte (or smaller) datagrams from endpoint-b. 3. are there any applications that perform UDP Path MTU Discovery? I am not aware of any, but there must be some because we talk about it a lot in the IETF. I checked RFC3530 (NFSv4) and all of draft-ietf-nfsv4*, but nothing mentions "MTU". A pointer to such a protocol would be helpful. 3a. When I read Section 10.3 and Section 5.2 of RFC4821, it seems doing RFC4821 with RTP would be difficult-to-impossible. Some additional discussion of this -- outside of the context of TURN -- might be useful. This is not a problem with TURN, per se, but rather a problem of how we would use those techniques with RTP. Perhaps something to bring up in AVT? -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Dec 20 22:08:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5YF6-0005bQ-Rb; Thu, 20 Dec 2007 22:08:08 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J5YF5-0005bJ-3T for behave-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 22:08:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5YF4-0005bB-OA for behave@ietf.org; Thu, 20 Dec 2007 22:08:06 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5YF2-0002pH-E4 for behave@ietf.org; Thu, 20 Dec 2007 22:08:06 -0500 X-IronPort-AV: E=Sophos;i="4.24,192,1196668800"; d="scan'208";a="5349498" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 20 Dec 2007 19:08:03 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBL383gO012187 for ; Thu, 20 Dec 2007 19:08:03 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id lBL383vJ016532 for ; Fri, 21 Dec 2007 03:08:03 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Dec 2007 19:08:03 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Dec 2007 19:08:03 -0800 Message-ID: <476B2E3C.90601@cisco.com> Date: Thu, 20 Dec 2007 22:08:44 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 21 Dec 2007 03:08:03.0291 (UTC) FILETIME=[B34912B0:01C8437E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4814; t=1198206483; x=1199070483; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Summary=20of=20TURN=20call=20this=20afternoon |Sender:=20; bh=Pi3c2fJsfV7UZB9cIhTsFs89/fkpswapHARzeGeRZTc=; b=yLHYuRtFHkYNKEoXiyac5pDzsJv1N+6VjxXF20L/h5LOjOYga+V4BUc/sC hNUszLXz9wrMz3MQ6hNb5nif7U/hYU0jy7p8l0b/3JvEcpHfU9XAexieuGWT 4ny9CINBIQ; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Subject: [BEHAVE] Summary of TURN call this afternoon X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org TURN Open Issues call December 20, 2007 Attendees: Jonathan Rosenberg Dan Wing Philip Matthews Eric Rescorla Derek MacDonald Kevin Johns Rémi Denis-Courmont Summary: First, we reviewed the open issues which appeared to be closed based on list discussion. There were no disagreements on the fact that these were closed, and on their resolution. They were: Ekr Mechanism: Agreement on using this Issue #2: This is requiring TURN server to be stateful Resolution: text in rfc3489bis to clarify rule on sending same response in 10sec interval Issue #3: address+port vs. address restricted Resolution: keep address restricted, though need to discuss issues in v6ops doc Issue #5: Port Range Resolution: SHOULD be in 49152-65535 range, discuss criteria for violating SHOULD Issue #7: Framing Header Length value Resolution: agreed that length value is there for UDP and matches UDP length, mismatch causes packet discard Issue #8: Managing permission lifetime Conclusion: do not address at this time Next, we discussed the primary meta-issue - long lived allocations. The main issue came up that, since TURN certainly allows allocations to live for a long time, we were going to need to provide some way for a turn server to clean up old channel numbers that aren't in use, otherwise it will leak memory. The server needs to be able to reclaim the memory and table entries allocated to holding the channel information. Thus, regardless of whether one ever thinks there will be a need to reclaim channel numbers, we need a mechanism to time them out, and once you do that, you can just re-bind to it, and thus the mechanism will exist. We spent some time discussing how to do this. If we have the server time out channels, we need a way to deal with cases where the client thinks the channel is up, and the server doesn't. Otherwise, the client will send data on some channel and the server doesn't know the channel and then discards the data silently. The client has no way to know this. A similar problem happens if the TURN server reboots mid-allocation, or the NAT reboots. In all cases unencapsulated data is discarded. We need a way to alert the client. We discussed sending an indication back to the client when the server receives an unecnapsulated packet on an unknown channel. One issue is that indications aren't authenticated, so does this open up a DoS attack, whereby an attacker can send faked indication? This is similar to the problem we have with indications in the currently documented Confirmation mechanism. ANother choice is a reverse transaction from server to client. There was no agreement on a mechanism; folks needed to go off and come up with one rather than try to design on the fly on the call. Ekr took an action item to think about it. Given that direction, we next moved to the open issue around framing, and whether turn packets are framed or not. THe primary drawback of this had been that it reduces the number of channels to 32767. However, given that we will now have a way to reuse timed-out ones, this limitation seems a non-issue. Thus folks on the call agreed that it was OK to go ahead and not use the framing header for TURN messages. We discussed next the open issue around bandwidth. There was some agreement that this mechanism was really about admission control for constant rate streams. Thus, it was meaningless to include it in requests for elastic flows, or include it in responses for those flows. There was a concern that we'd need more than just 'bandwidth' as a value, we'd need packet sizes too so that a proper job of cac can be done. Note that, there was agreement we were talking STRICTLY about admission and rate limiting on the TURN server, not in the network. We discussed also the idea of using RSVP for this, but we didn't get far in that and it was non-obvious how this would work. The conclusion is that more discussion is needed. Next steps: * the remaining issues (bandwidth and port adjacency) remain contentious. However, these affect relatively little text in the document. Thus will we continue with the originally proposed plan for a revised document on Jan 8, including what has been agreed so far. * In the meantime we can continue to debate these issues. We'll schedule another call to make progress after the new year, and continue to do that until the issues are closed. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 21 03:30:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5dH2-0000do-7K; Fri, 21 Dec 2007 03:30:28 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J5dH1-0000dj-PM for behave-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 03:30:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5dGv-0000IY-3m for behave@ietf.org; Fri, 21 Dec 2007 03:30:21 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5dGt-0001J8-HC for behave@ietf.org; Fri, 21 Dec 2007 03:30:21 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBL8UHAj001293 for ; Fri, 21 Dec 2007 10:30:17 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Dec 2007 10:30:13 +0200 Received: from esdhcp04076.research.nokia.com ([172.21.40.76]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Dec 2007 10:30:13 +0200 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] TURN issue: Exceeding PMTU size Date: Fri, 21 Dec 2007 10:30:29 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200712211030.29646.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 21 Dec 2007 08:30:13.0664 (UTC) FILETIME=[B515EA00:01C843AB] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Le Thursday 20 December 2007 22:14:52 ext Philip Matthews, vous avez =E9cri= t=A0: > Using TURN increases the size of an application's data packet by > either 4 bytes (when using the channel number header) or by > approximately 36 bytes (when using Send or Data Indication) on the > path between the client and the server. This extra overhead has the > potential of bumping the size of an application's data packet to a > value above the PMTU on the path between the client and the server, > thus resulting in IP fragmentation. And IP fragmentation is known to > cause problems with some NATs. > > The question is: Does TURN need to handle this problem, or do we just > say that it is the application's problem? =46YI, SOCKS UDP uses some *application-layer* fragmentation to handle this. I am not advocating this - just pointing it out. > In my opinion, this is the application's problem. According draft- > ietf-tsvwg-udp-guidelines, applications that use UDP should either > use Path MTU Discovery, or restrict themselves to packets of size 576 > bytes or less (over IPv4). Applications that do the former will > discover the true Path MTU (including the TURN overhead), while > applications doing the latter will be safe in most cases, since most > Path MTUs are much larger than 576. Agreed. What if the path MTU is yet smaller beyond the TURN server than it is betwe= en=20 the TURN server and the TURN client? TURN does not relay ICMP... even then= =20 PTMU through NAT is fairly unreliable. To me this sounds like any application that would have practical problems w= ith=20 this is *broken*. If you need to send dangerously large messages, use TCP. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 21 07:53:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5hNX-0003SW-VA; Fri, 21 Dec 2007 07:53:27 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J5hNV-0003SR-Vq for behave-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 07:53:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5hNV-0003SJ-Lw for behave@ietf.org; Fri, 21 Dec 2007 07:53:25 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-05.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5hNV-0006u2-EH for behave@ietf.org; Fri, 21 Dec 2007 07:53:25 -0500 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J5hMs-0008IL-0N; Fri, 21 Dec 2007 07:52:46 -0500 In-Reply-To: <476B2E3C.90601@cisco.com> References: <476B2E3C.90601@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4E7615A1-A576-48BB-92E0-F2F3C13B896A@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] Summary of TURN call this afternoon Date: Fri, 21 Dec 2007 07:53:26 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Behave WG X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 20-Dec-07, at 22:08 , Jonathan Rosenberg wrote: > > Issue #3: address+port vs. address restricted > Resolution: keep address restricted, though need to discuss issues > in v6ops doc Which v6ops doc is this? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 21 08:31:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5hy1-0001C8-2R; Fri, 21 Dec 2007 08:31:09 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J5hy0-0001Bn-1X for behave-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 08:31:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5hxz-0001BX-M3 for behave@ietf.org; Fri, 21 Dec 2007 08:31:07 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-02.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5hxy-0001Ur-V5 for behave@ietf.org; Fri, 21 Dec 2007 08:31:07 -0500 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J5hxx-00019D-2L; Fri, 21 Dec 2007 08:31:06 -0500 In-Reply-To: <39cb01c84362$1ce36620$c6f0200a@cisco.com> References: <39cb01c84362$1ce36620$c6f0200a@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN issue: Exceeding PMTU size Date: Fri, 21 Dec 2007 08:31:06 -0500 To: Dan Wing X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 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 First, to be clear, by "Path MTU Discovery" I was assuming "Packetization Layer Path MTU Discovery" (RFC 4821), and not classic Path MTU Discovery which relies on ICMP. This was because TURN currently does not relay ICMP messages. Your message seems to assume that endpoints would do Path MTU Discovery to the TURN server. I was assuming that endpoints would do Path MTU Discovery to each other. That is, they would send progressively larger probe packets to each other to determine the MTU of the entire path between the TURN client and the remote peer. However, your question about which applications actually do this is a good one. I don't know of any. - Philip On 20-Dec-07, at 18:43 , Dan Wing wrote: > > >> -----Original Message----- >> From: Philip Matthews [mailto:philip_matthews@magma.ca] >> Sent: Thursday, December 20, 2007 12:15 PM >> To: Behave WG; Lars Eggert >> Subject: [BEHAVE] TURN issue: Exceeding PMTU size >> >> Using TURN increases the size of an application's data packet by >> either 4 bytes (when using the channel number header) or by >> approximately 36 bytes (when using Send or Data Indication) on the >> path between the client and the server. This extra overhead has the >> potential of bumping the size of an application's data packet to a >> value above the PMTU on the path between the client and the server, >> thus resulting in IP fragmentation. And IP fragmentation is known to >> cause problems with some NATs. >> >> The question is: Does TURN need to handle this problem, or do >> we just >> say that it is the application's problem? >> >> In my opinion, this is the application's problem. According draft- >> ietf-tsvwg-udp-guidelines, applications that use UDP should either >> use Path MTU Discovery, or restrict themselves to packets of >> size 576 >> bytes or less (over IPv4). Applications that do the former will >> discover the true Path MTU (including the TURN overhead), while >> applications doing the latter will be safe in most cases, since most >> Path MTUs are much larger than 576. >> >> Comments? > > I have some comments as an individual: > > 1. Imagine a situation where where endpoint-a is using its TURN > server, and > endpoint-b is not using a TURN server. This would occur if > endpoint-b is > behind a BEHAVE-compliant NAT, or if endpoint-b isn't behind a NAT, or > endpoint-b doesn't support ICE. > > Here is a digram: > > +------+ > | TURN +<-------------------+ > +---+--+ | > | | > V | > +--+--+ | > | NAT | | > +--+--+ | > | | > V | > +-----+------+ +-----+------+ > | endpoint-a | + endpoint-b | > +------------+ +------------+ > > Let's imagine both endpoint-a and endpoint-b are able to do UDP > path MTU > discovery. endpoint-b will learn the MTU between itself and the > TURN server. > Both the TURN server and endpoint-a are aware of the TURN shim (4 > bytes or 36 > bytes) between them, and can reduce their MTU accordingly. > > However, what is missing is that the TURN server needs to inform > endpoint-a of > this TURN shim (4 bytes / 36 bytes). If the TURN server receives a > UDP packet > that is too large, it would need to respond with an ICMP 'too big' > error to > endpoint-b, so that endpoint-b has an opportunity to reduce its > path MTU to > the TURN server. > > > 2. Worse is when the path between the TURN server and endpoint-a > has a small > MTU. Let's assume for a moment that it is really small, like 576 > bytes, and > the MTU between endpoint-b and the TURN server is a gigabit > ethernet network > with a 9000 byte MTU. If you don't like 9000 or don't like gigabit > ethernet, > please substitute the value 1500; the problem is the same. > > +------+ > | TURN +<-------------------+ > +---+--+ | > | | > | MTU=576 | MTU=9000 > | | > V | > +-----+------+ +-----+------+ > | endpoint-a | + endpoint-b | > +------------+ +------------+ > > In this case, following my suggestion above, when the TURN server > receives a > 9000-byte packet, it will respond with an ICMP 'too big' message > suggesting > the MTU is 9000-36=8964 bytes. However, that is clearly not > correct: the > TURN server needs to continue refusing large datagrams until > endpoint-b sends > 576-byte datagrams (or smaller). > > To do this, the TURN server needs to learn the path MTU with > endpoint-a, so > that the TURN server can intelligently accept only 576-byte (or > smaller) > datagrams from endpoint-b. > > > 3. are there any applications that perform UDP Path MTU Discovery? > I am not > aware of any, but there must be some because we talk about it a lot > in the > IETF. I checked RFC3530 (NFSv4) and all of draft-ietf-nfsv4*, but > nothing > mentions "MTU". A pointer to such a protocol would be helpful. > > 3a. When I read Section 10.3 and Section 5.2 of RFC4821, it seems > doing > RFC4821 with RTP would be difficult-to-impossible. Some additional > discussion > of this -- outside of the context of TURN -- might be useful. This > is not a > problem with TURN, per se, but rather a problem of how we would use > those > techniques with RTP. Perhaps something to bring up in AVT? > > -d > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 21 10:27:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5jmn-0005lW-UG; Fri, 21 Dec 2007 10:27:41 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J5jmm-0005hv-F0 for behave-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 10:27:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5jmm-0005hn-3c for behave@ietf.org; Fri, 21 Dec 2007 10:27:40 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5jml-0001AJ-GT for behave@ietf.org; Fri, 21 Dec 2007 10:27:40 -0500 X-IronPort-AV: E=Sophos;i="4.24,194,1196668800"; d="scan'208";a="23885857" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 21 Dec 2007 07:27:39 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lBLFRc3G013024; Fri, 21 Dec 2007 07:27:38 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lBLFRS36025118; Fri, 21 Dec 2007 15:27:38 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Dec 2007 07:27:28 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Dec 2007 07:27:28 -0800 Message-ID: <476BDB89.1030705@cisco.com> Date: Fri, 21 Dec 2007 10:28:09 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [BEHAVE] Summary of TURN call this afternoon References: <476B2E3C.90601@cisco.com> <4E7615A1-A576-48BB-92E0-F2F3C13B896A@magma.ca> In-Reply-To: <4E7615A1-A576-48BB-92E0-F2F3C13B896A@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Dec 2007 15:27:28.0616 (UTC) FILETIME=[FF146E80:01C843E5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=644; t=1198250859; x=1199114859; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20Summary=20of=20TURN=20call=2 0this=20afternoon |Sender:=20; bh=swk9VcxpPK6y+7GpPGzqxM4cys3B/ue9DbSoJt2RRi8=; b=TjzTpJOGUgdqEKbtM1cTAMMM7XnSl1Al6C3sZqGT9Hm4LLGpAi3IO71Zig y07NwhJo03LEUiSbXfGElzuSg4rx5J5PVCHoq1l8jyH7c/dvC7zIpET/t0Vp 94Bk813H3a; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 http://www.ietf.org/internet-drafts/draft-ietf-v6ops-teredo-security-concerns-01.txt Philip Matthews wrote: > > On 20-Dec-07, at 22:08 , Jonathan Rosenberg wrote: >> >> Issue #3: address+port vs. address restricted >> Resolution: keep address restricted, though need to discuss issues in >> v6ops doc > > Which v6ops doc is this? > > - Philip > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 21 14:23:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5nSV-0000IF-MR; Fri, 21 Dec 2007 14:22:59 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J5nST-0000I8-Lr for behave-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 14:22:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5nST-0000I0-BT for behave@ietf.org; Fri, 21 Dec 2007 14:22:57 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5nSS-0007A4-BC for behave@ietf.org; Fri, 21 Dec 2007 14:22:57 -0500 X-IronPort-AV: E=Sophos;i="4.24,196,1196668800"; d="scan'208";a="24009891" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 21 Dec 2007 11:22:55 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lBLJMtl1024630; Fri, 21 Dec 2007 11:22:55 -0800 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lBLJMs32009999; Fri, 21 Dec 2007 19:22:54 GMT From: "Dan Wing" To: "'Philip Matthews'" References: <39cb01c84362$1ce36620$c6f0200a@cisco.com> Subject: RE: [BEHAVE] TURN issue: Exceeding PMTU size Date: Fri, 21 Dec 2007 11:22:54 -0800 Message-ID: <00b401c84406$e3468000$c6f0200a@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.3198 Thread-Index: AchD1cMTVQA5s3VLSou7r5sCkQ8roAAJ6NJQ DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6816; t=1198264975; x=1199128975; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20TURN=20issue=3A=20Exceeding= 20PMTU=20size |Sender:=20; bh=28DzUxZgUgAzgqsa8xX32qL7gAKDgRLBUtgYn5j23EQ=; b=pzx3YWIR1gv/a/EFK/TtFY4Hqox4obd7l1d2LDV0g1JQWx+7okVtQPjFQi a/fdr2wG1vpcWXT3t5BPsloC8zprtoQ+oaos7qTVQPTd5NPpltZON914/zbF T3zD8ATJZ4; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd 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 > First, to be clear, by "Path MTU Discovery" I was assuming > "Packetization Layer Path MTU Discovery" (RFC 4821), and not classic > Path MTU Discovery which relies on ICMP. This was because TURN > currently does not relay ICMP messages. ietf-tsvwg-udp-guidelines refers to both styles. > Your message seems to assume that endpoints would do Path MTU > Discovery to the TURN server. I was assuming that endpoints would do > Path MTU Discovery to each other. But they communicate through the TURN server. For RFC4821-style PMTUD to be effective, the TURN server needs to do something (see below for what I think it needs to do). > That is, they would send > progressively larger probe packets to each other to determine > the MTU > of the entire path between the TURN client and the remote peer. So, you are expecting the clients to perform RFC4821-style UDP PMTUD. That would need to be clarified in the TURN specification because you can't rely on ietf-tsvwg-udp-guidelines for that clarification. Additionally, for RFC4821 to work across the TURN server, the TURN server would need to preserve the DF bit from the incoming packet. > However, your question about which applications actually do > this is a good one. I don't know of any. In another message I was told that Cisco's L2TP does UDP PMTUD. Here is a brief discussion, http://www.cisco.com/warp/public/471/l2tp_mtu_tuning.html#automatic -d > - Philip > > On 20-Dec-07, at 18:43 , Dan Wing wrote: > > > > > > >> -----Original Message----- > >> From: Philip Matthews [mailto:philip_matthews@magma.ca] > >> Sent: Thursday, December 20, 2007 12:15 PM > >> To: Behave WG; Lars Eggert > >> Subject: [BEHAVE] TURN issue: Exceeding PMTU size > >> > >> Using TURN increases the size of an application's data packet by > >> either 4 bytes (when using the channel number header) or by > >> approximately 36 bytes (when using Send or Data Indication) on the > >> path between the client and the server. This extra overhead has the > >> potential of bumping the size of an application's data packet to a > >> value above the PMTU on the path between the client and the server, > >> thus resulting in IP fragmentation. And IP fragmentation > is known to > >> cause problems with some NATs. > >> > >> The question is: Does TURN need to handle this problem, or do > >> we just > >> say that it is the application's problem? > >> > >> In my opinion, this is the application's problem. According draft- > >> ietf-tsvwg-udp-guidelines, applications that use UDP should either > >> use Path MTU Discovery, or restrict themselves to packets of > >> size 576 > >> bytes or less (over IPv4). Applications that do the former will > >> discover the true Path MTU (including the TURN overhead), while > >> applications doing the latter will be safe in most cases, > since most > >> Path MTUs are much larger than 576. > >> > >> Comments? > > > > I have some comments as an individual: > > > > 1. Imagine a situation where where endpoint-a is using its TURN > > server, and > > endpoint-b is not using a TURN server. This would occur if > > endpoint-b is > > behind a BEHAVE-compliant NAT, or if endpoint-b isn't > behind a NAT, or > > endpoint-b doesn't support ICE. > > > > Here is a digram: > > > > +------+ > > | TURN +<-------------------+ > > +---+--+ | > > | | > > V | > > +--+--+ | > > | NAT | | > > +--+--+ | > > | | > > V | > > +-----+------+ +-----+------+ > > | endpoint-a | + endpoint-b | > > +------------+ +------------+ > > > > Let's imagine both endpoint-a and endpoint-b are able to do UDP > > path MTU > > discovery. endpoint-b will learn the MTU between itself and the > > TURN server. > > Both the TURN server and endpoint-a are aware of the TURN shim (4 > > bytes or 36 > > bytes) between them, and can reduce their MTU accordingly. > > > > However, what is missing is that the TURN server needs to inform > > endpoint-a of > > this TURN shim (4 bytes / 36 bytes). If the TURN server > receives a > > UDP packet > > that is too large, it would need to respond with an ICMP 'too big' > > error to > > endpoint-b, so that endpoint-b has an opportunity to reduce its > > path MTU to > > the TURN server. > > > > > > 2. Worse is when the path between the TURN server and endpoint-a > > has a small > > MTU. Let's assume for a moment that it is really small, like 576 > > bytes, and > > the MTU between endpoint-b and the TURN server is a gigabit > > ethernet network > > with a 9000 byte MTU. If you don't like 9000 or don't like > gigabit > > ethernet, > > please substitute the value 1500; the problem is the same. > > > > +------+ > > | TURN +<-------------------+ > > +---+--+ | > > | | > > | MTU=576 | MTU=9000 > > | | > > V | > > +-----+------+ +-----+------+ > > | endpoint-a | + endpoint-b | > > +------------+ +------------+ > > > > In this case, following my suggestion above, when the TURN server > > receives a > > 9000-byte packet, it will respond with an ICMP 'too big' message > > suggesting > > the MTU is 9000-36=8964 bytes. However, that is clearly not > > correct: the > > TURN server needs to continue refusing large datagrams until > > endpoint-b sends > > 576-byte datagrams (or smaller). > > > > To do this, the TURN server needs to learn the path MTU with > > endpoint-a, so > > that the TURN server can intelligently accept only 576-byte (or > > smaller) > > datagrams from endpoint-b. > > > > > > 3. are there any applications that perform UDP Path MTU > Discovery? > > I am not > > aware of any, but there must be some because we talk about > it a lot > > in the > > IETF. I checked RFC3530 (NFSv4) and all of draft-ietf-nfsv4*, but > > nothing > > mentions "MTU". A pointer to such a protocol would be helpful. > > > > 3a. When I read Section 10.3 and Section 5.2 of RFC4821, it seems > > doing > > RFC4821 with RTP would be difficult-to-impossible. Some > additional > > discussion > > of this -- outside of the context of TURN -- might be > useful. This > > is not a > > problem with TURN, per se, but rather a problem of how we > would use > > those > > techniques with RTP. Perhaps something to bring up in AVT? > > > > -d > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 21 16:01:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5ozT-0000ee-FJ; Fri, 21 Dec 2007 16:01:07 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J5ozR-0000RE-ER for behave-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 16:01:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5ozQ-0000J8-Mk for behave@ietf.org; Fri, 21 Dec 2007 16:01:04 -0500 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5ozQ-0005ao-AZ for behave@ietf.org; Fri, 21 Dec 2007 16:01:04 -0500 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.222.3; Fri, 21 Dec 2007 13:01:03 -0800 Received: from TK5-EXMLT-W603.wingroup.windeploy.ntdev.microsoft.com (157.54.18.6) by tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) with Microsoft SMTP Server id 8.1.222.3; Fri, 21 Dec 2007 13:01:03 -0800 Received: from NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.196]) by TK5-EXMLT-W603.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.6]) with mapi; Fri, 21 Dec 2007 13:01:03 -0800 From: Christian Huitema To: Jonathan Rosenberg , Philip Matthews Date: Fri, 21 Dec 2007 13:01:00 -0800 Subject: RE: [BEHAVE] Summary of TURN call this afternoon Thread-Topic: [BEHAVE] Summary of TURN call this afternoon Thread-Index: AchD5g9hEBJb4xw6QdekwEKVQRnqYQALjsAQ Message-ID: References: <476B2E3C.90601@cisco.com> <4E7615A1-A576-48BB-92E0-F2F3C13B896A@magma.ca> <476BDB89.1030705@cisco.com> In-Reply-To: <476BDB89.1030705@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -100.0 (---------------------------------------------------) 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 That doc is very much a work in progress. Most of its discussion applies to= enterprise firewalls rather than unmanaged NAT. If you care, I put out an = opinion piece on the Symantec analysis of Teredo at http://blogs.technet.co= m/ipv6/. > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-teredo-security- > concerns-01.txt > > Philip Matthews wrote: > > > > On 20-Dec-07, at 22:08 , Jonathan Rosenberg wrote: > >> > >> Issue #3: address+port vs. address restricted > >> Resolution: keep address restricted, though need to discuss issues in > >> v6ops doc > > > > Which v6ops doc is this? > > > > - Philip > > > > -- > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 21 17:08:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5q2Q-0001gZ-DY; Fri, 21 Dec 2007 17:08:14 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J5q2O-0001gQ-Hc for behave-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 17:08:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5q2N-0001g4-FM for behave@ietf.org; Fri, 21 Dec 2007 17:08:11 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-05.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5q2K-0003Af-VU for behave@ietf.org; Fri, 21 Dec 2007 17:08:11 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J5q1h-0003F1-1o; Fri, 21 Dec 2007 17:07:29 -0500 In-Reply-To: <00b401c84406$e3468000$c6f0200a@cisco.com> References: <39cb01c84362$1ce36620$c6f0200a@cisco.com> <00b401c84406$e3468000$c6f0200a@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] TURN issue: Exceeding PMTU size Date: Fri, 21 Dec 2007 17:08:09 -0500 To: Dan Wing X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 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 So my modified proposal is: It is the application's job to ensure that its data packets with not exceed the Path MTU (including the MTU on portion of the path between the client and the TURN server). This can be done by either (a) implementing "Packetization Layer Path MTU Discovery" (RFC 4821), or (b) by restricting themselves to packets of size 576 or less (over IPv4). To support RFC 4821, a TURN server must either set or preserve the DF bit when relaying packets. - Philip On 21-Dec-07, at 14:22 , Dan Wing wrote: >> First, to be clear, by "Path MTU Discovery" I was assuming >> "Packetization Layer Path MTU Discovery" (RFC 4821), and not classic >> Path MTU Discovery which relies on ICMP. This was because TURN >> currently does not relay ICMP messages. > > ietf-tsvwg-udp-guidelines refers to both styles. > >> Your message seems to assume that endpoints would do Path MTU >> Discovery to the TURN server. I was assuming that endpoints would do >> Path MTU Discovery to each other. > > But they communicate through the TURN server. For RFC4821-style > PMTUD to be effective, the TURN server needs to do something > (see below for what I think it needs to do). > >> That is, they would send >> progressively larger probe packets to each other to determine >> the MTU >> of the entire path between the TURN client and the remote peer. > > So, you are expecting the clients to perform RFC4821-style UDP > PMTUD. That would need to be clarified in the TURN specification > because you can't rely on ietf-tsvwg-udp-guidelines for that > clarification. > > Additionally, for RFC4821 to work across the TURN server, the > TURN server would need to preserve the DF bit from the > incoming packet. > >> However, your question about which applications actually do >> this is a good one. I don't know of any. > > In another message I was told that Cisco's L2TP does UDP PMTUD. > Here is a brief discussion, > http://www.cisco.com/warp/public/471/l2tp_mtu_tuning.html#automatic > > -d > >> - Philip >> >> On 20-Dec-07, at 18:43 , Dan Wing wrote: >> >>> >>> >>>> -----Original Message----- >>>> From: Philip Matthews [mailto:philip_matthews@magma.ca] >>>> Sent: Thursday, December 20, 2007 12:15 PM >>>> To: Behave WG; Lars Eggert >>>> Subject: [BEHAVE] TURN issue: Exceeding PMTU size >>>> >>>> Using TURN increases the size of an application's data packet by >>>> either 4 bytes (when using the channel number header) or by >>>> approximately 36 bytes (when using Send or Data Indication) on the >>>> path between the client and the server. This extra overhead has the >>>> potential of bumping the size of an application's data packet to a >>>> value above the PMTU on the path between the client and the server, >>>> thus resulting in IP fragmentation. And IP fragmentation >> is known to >>>> cause problems with some NATs. >>>> >>>> The question is: Does TURN need to handle this problem, or do >>>> we just >>>> say that it is the application's problem? >>>> >>>> In my opinion, this is the application's problem. According draft- >>>> ietf-tsvwg-udp-guidelines, applications that use UDP should either >>>> use Path MTU Discovery, or restrict themselves to packets of >>>> size 576 >>>> bytes or less (over IPv4). Applications that do the former will >>>> discover the true Path MTU (including the TURN overhead), while >>>> applications doing the latter will be safe in most cases, >> since most >>>> Path MTUs are much larger than 576. >>>> >>>> Comments? >>> >>> I have some comments as an individual: >>> >>> 1. Imagine a situation where where endpoint-a is using its TURN >>> server, and >>> endpoint-b is not using a TURN server. This would occur if >>> endpoint-b is >>> behind a BEHAVE-compliant NAT, or if endpoint-b isn't >> behind a NAT, or >>> endpoint-b doesn't support ICE. >>> >>> Here is a digram: >>> >>> +------+ >>> | TURN +<-------------------+ >>> +---+--+ | >>> | | >>> V | >>> +--+--+ | >>> | NAT | | >>> +--+--+ | >>> | | >>> V | >>> +-----+------+ +-----+------+ >>> | endpoint-a | + endpoint-b | >>> +------------+ +------------+ >>> >>> Let's imagine both endpoint-a and endpoint-b are able to do UDP >>> path MTU >>> discovery. endpoint-b will learn the MTU between itself and the >>> TURN server. >>> Both the TURN server and endpoint-a are aware of the TURN shim (4 >>> bytes or 36 >>> bytes) between them, and can reduce their MTU accordingly. >>> >>> However, what is missing is that the TURN server needs to inform >>> endpoint-a of >>> this TURN shim (4 bytes / 36 bytes). If the TURN server >> receives a >>> UDP packet >>> that is too large, it would need to respond with an ICMP 'too big' >>> error to >>> endpoint-b, so that endpoint-b has an opportunity to reduce its >>> path MTU to >>> the TURN server. >>> >>> >>> 2. Worse is when the path between the TURN server and endpoint-a >>> has a small >>> MTU. Let's assume for a moment that it is really small, like 576 >>> bytes, and >>> the MTU between endpoint-b and the TURN server is a gigabit >>> ethernet network >>> with a 9000 byte MTU. If you don't like 9000 or don't like >> gigabit >>> ethernet, >>> please substitute the value 1500; the problem is the same. >>> >>> +------+ >>> | TURN +<-------------------+ >>> +---+--+ | >>> | | >>> | MTU=576 | MTU=9000 >>> | | >>> V | >>> +-----+------+ +-----+------+ >>> | endpoint-a | + endpoint-b | >>> +------------+ +------------+ >>> >>> In this case, following my suggestion above, when the TURN server >>> receives a >>> 9000-byte packet, it will respond with an ICMP 'too big' message >>> suggesting >>> the MTU is 9000-36=8964 bytes. However, that is clearly not >>> correct: the >>> TURN server needs to continue refusing large datagrams until >>> endpoint-b sends >>> 576-byte datagrams (or smaller). >>> >>> To do this, the TURN server needs to learn the path MTU with >>> endpoint-a, so >>> that the TURN server can intelligently accept only 576-byte (or >>> smaller) >>> datagrams from endpoint-b. >>> >>> >>> 3. are there any applications that perform UDP Path MTU >> Discovery? >>> I am not >>> aware of any, but there must be some because we talk about >> it a lot >>> in the >>> IETF. I checked RFC3530 (NFSv4) and all of draft-ietf-nfsv4*, but >>> nothing >>> mentions "MTU". A pointer to such a protocol would be helpful. >>> >>> 3a. When I read Section 10.3 and Section 5.2 of RFC4821, it seems >>> doing >>> RFC4821 with RTP would be difficult-to-impossible. Some >> additional >>> discussion >>> of this -- outside of the context of TURN -- might be >> useful. This >>> is not a >>> problem with TURN, per se, but rather a problem of how we >> would use >>> those >>> techniques with RTP. Perhaps something to bring up in AVT? >>> >>> -d >>> > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Dec 21 17:16:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5qA4-00023h-Uz; Fri, 21 Dec 2007 17:16:08 -0500 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1J5qA4-00023c-G6 for behave-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 17:16:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5qA4-00023U-6Y for behave@ietf.org; Fri, 21 Dec 2007 17:16:08 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-07.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5qA4-0003Jt-0d for behave@ietf.org; Fri, 21 Dec 2007 17:16:08 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J5q9r-0005GR-2t; Fri, 21 Dec 2007 17:15:56 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Fri, 21 Dec 2007 17:15:59 -0500 To: Behave WG X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Rohan Mahy Subject: [BEHAVE] TURN Issue: Preserving bits in the IP header X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org The thread on exceeding the MTU size has raised another issue about TURN: what bits (if any) in the IP header should be preserved across a TURN relay? My proposal is: A TURN server MUST preserve the Don't Fragment (DF) and TOS (= ECN and DiffServ) bits in the IP header when relaying IPv4 packets. Comments? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave