From behave-bounces@ietf.org Mon Jan 01 12:19:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1QoF-00041J-Gj; Mon, 01 Jan 2007 12:18:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1QoE-00041E-Ri for behave@ietf.org; Mon, 01 Jan 2007 12:18:50 -0500 Received: from mailx.8x8.com ([192.84.19.237] helo=mailint.8x8.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1QoD-0008HS-Fa for behave@ietf.org; Mon, 01 Jan 2007 12:18:50 -0500 Received: from mailint.8x8.com (localhost.localdomain [127.0.0.1]) by mailint.8x8.com (8.13.1/8.13.1) with ESMTP id l01HIQqV026584; Mon, 1 Jan 2007 09:18:26 -0800 Received: from mailint.8x8.com (root@localhost) by mailint.8x8.com (8.13.1/8.13.1/Submit) with ESMTP id l01HIOa1026583; Mon, 1 Jan 2007 09:18:26 -0800 Received: from [10.0.2.15] (godzilla.8x8.com 192.168.84.42) by mailint.8x8.com (Scalix SMTP Relay 10.0.1.3) via ESMTP; Mon, 01 Jan 2007 09:18:23 -0800 (PST) Date: Mon, 1 Jan 2007 18:18:19 +0100 From: Marc Petit-Huguenin To: jdrosen@cisco.com Message-ID: <4599425B.8050805@acm.org> x-scalix-Hops: 1 User-Agent: Icedove 1.5.0.9 (X11/20061220) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: behave@ietf.org Subject: [BEHAVE] Review of draft-ietf-behave-rfc3489bis-05 [update] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 found an additional issue that I would like to add to my review of draft-ietf-behave-rfc3489bis-05: 9. Section 8.3.2, paragraph 17: "Any response response between 100 and 299 MUST result in the cessation of request retransmissions, but otherwise is discarded." The problem is that the "final" response that will be sent before the 7900ms timeout will not be retransmitted if it is lost. The request will eventually be retried on the next server, but it is still a problem if the usage does not use DNS, or if there is only one SRV RR. Here some suggestions to fix this: o The simplest way is to remove this sentence, but I think that there is a real need to have a way to stop the retransmissions until the response can be calculated. An example that comes to mind would be if the STUN server needs to contact a authentication server (e.g. RFC 4590) that will take more than 100ms to respond. o Another way would be to keep the sentence and do what was done with the 200/ACK for SIP INVITE. For STUN this would mean to add an ACK Indication, and retransmit the "final" response until an ACK Indication with the same transaction id is received. o Another way would be to remove the sentence, and add a new error response code 448 Response Delayed that will signal that the response will be sent later in a new Update request, but in the opposite direction. Here's an example for an Allocate request: UA TURN | Allocate request | 1 |------------------------------>| | Allocate Error Response 448 | 2 |<------------------------------| : : | Update Request | 3 |<------------------------------| | Update Response | 4 |------------------------------>| 1: An Allocate request is sent to the TURN server. 2: The TURN server needs more time to allocate the ports, and so responds with a 448 response that stops the retransmissions. 3: After some time the TURN server manages to allocate the ports and so sends an Update Request in the direction of the UA. It copies in the request all the attributes that it should have copied in the Allocate Response if it was able to do it. The request also contains an additional attribute containing the transaction id of the original transaction. It needs to send the request in the next 30 seconds after receiving the Allocate request to be sure that the UDP binding is still active in the NAT. 4: The UA responds with an Update Response to stop the retransmissions. The advantage of this last method is that it does not change the STUN transaction behavior. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 03 16:17:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2DTv-000400-LL; Wed, 03 Jan 2007 16:17:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2DTu-0003zk-Vn for behave@ietf.org; Wed, 03 Jan 2007 16:17:06 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2DTs-0001TL-EA for behave@ietf.org; Wed, 03 Jan 2007 16:17:06 -0500 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l03LH1A6003495 for ; Wed, 3 Jan 2007 14:17:01 -0700 (MST) Received: from srvxchg.cablelabs.com (10.5.0.20) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com); Wed, 3 Jan 2007 14:17:00 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Jan 2007 14:17:01 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: STUN FINGERPRINT Thread-Index: AccvfH/BzK5HCLFBQOSM+DLZ0d22Zw== From: "Kevin Johns" To: X-Approved: ondar X-Spam-Score: 0.4 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: [BEHAVE] STUN FINGERPRINT X-BeenThere: behave@ietf.org X-Mailman-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="===============0137728339==" Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. --===============0137728339== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C72F7C.82369834" This is a multi-part message in MIME format. ------_=_NextPart_001_01C72F7C.82369834 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 Per the text of the current STUN draft (-05), it states that the value is computed as the CRC-32 of the STUN message up to (but excluding) the FINGERPRINT attribute itself. =20 The question is on the length value used in the message length field of the STUN header. Is the FINGERPRINT calculated using the message length including the FINGERPRINT attribute or the message length minus the FINGERPRINT attribute? =20 I could not find this discussed anywhere in the draft and we need to know which way to implement. =20 Regards, Kevin Johns ------_=_NextPart_001_01C72F7C.82369834 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,
 
Per = the text of the=20 current STUN draft (-05), it states that the value is computed as the = CRC-32 of=20 the STUN message up to (but excluding) the FINGERPRINT attribute=20 itself.
 
The = question is on=20 the length value used in the message length field of the STUN header. Is = the=20 FINGERPRINT calculated using the message length including the = FINGERPRINT=20 attribute or the message length minus the FINGERPRINT=20 attribute?
 
I = could not find=20 this discussed anywhere in the draft and we need to know which way to=20 implement.
 
Regards,
Kevin=20 Johns
------_=_NextPart_001_01C72F7C.82369834-- --===============0137728339== 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 --===============0137728339==-- From behave-bounces@ietf.org Fri Jan 05 06:18:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2n5K-0006er-75; Fri, 05 Jan 2007 06:18:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2n5I-0006ee-K8 for behave@ietf.org; Fri, 05 Jan 2007 06:18: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 1H2n5G-0005KE-1i for behave@ietf.org; Fri, 05 Jan 2007 06:18:04 -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 l05BGgPu028884 for ; Fri, 5 Jan 2007 13:16:46 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 13:17:46 +0200 Received: from esebe104.NOE.Nokia.com ([172.21.143.44]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 13:17:46 +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: Fri, 5 Jan 2007 13:17:46 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-behave-rfc3489bis-05 comments Thread-Index: AccwuyBaxnr6AYClRFmLD4SyHLgIZg== From: To: X-OriginalArrivalTime: 05 Jan 2007 11:17:46.0929 (UTC) FILETIME=[20B7EA10:01C730BB] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070105131646-70654BB0-58AEFE1E/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Subject: [BEHAVE] draft-ietf-behave-rfc3489bis-05 comments X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, A bit late for the rfc3489bis-05 WGLC, but better late than never. This is a great spec, but there's still some issues to discuss. I tried not to repeat the already commented issues. Here's the comments: -6. (page 13): Requirement about selecting a new TID value is a bit iffy. It requires that the transaction ID's should be uniformly and randomly selected on the 0 to 2**96 - 1 scale, but then again, a client should not repeat previous TID's. These two requirements are conflicting with each other. A client really can not remember all of its used old TID's forever. Neither can it use an incrementing counter as a part of the TID to achieve the non-repeating characteristic due to the random selection requirement. AFAIK for basic STUN the requirement of uniform & random value selection is enough. If we really do need the "not repeating" part for something specific, it should be clearly stated here. -7.1 (page 14): The retry timeout value calculation with this new style might be a bit of an overkill. Is it really reasonable to specify such an adaptive algorithm just for retransmissions? Would't it just be enough that the implementations would be allowed to configure and/or the retry starting time value, and then double it (and so on like in previous rfc3489(-bis) versions)? I do understand that this mechanism is just a SHOULD level requirement, but still, do we have a need to make it so "dynamic and wise"? -8.1 (page 16): Service discovery (DNS SRV & port) specifications in rfc3489bis-05 are not backwards compatible with RFC3489 (as I stated earlier). Rohan Mahy had a nice solution to this (I'll second this): "I think we want to switch to _tls-tcp going forward and allow _tls for backwards compatibility." -8.1 (page 16): There is (still) no default port for the STUN over TLS (shared secret usage). I'd really like this specification to include one. I havent heard of any (good) reasons why not to do so. Here's a few reasons why to specify this default port definition also for STUN over (TCP) TLS: a) This enables (minimal) implementations not to include the DNS SRV query part in the implementation. Also, disabling the DNS SRV query part with settings (like by having just a direct STUN server address in settings) would be enabled. b) The TLS STUN services (if implemented) will be in some port anyway. Why not specify a default port so that the service providers could use a specific port by default, and not scatter the port selections to random ports? c) I'm not much of a security specialist, but would't this specification ... "For usages that require TLS, such as the short term password usage, lack of SRV records is equivalent to a failure of the transaction, since the request or indication MUST NOT be sent unless SRV records provided a transport address specifically for TLS." ... enable a potential down-negotiation weakness if the attacker can somehow block the DNS SRV queries the client makes? By this I mean of course possible fall-back to not using short term passwords, and continuing by assuming that the server supports STUN binding query without any shared secrets. -8.3.2 (page 19): Acceptance of response messages that unexpectedly include a MESSAGE-INTEGRITY attribute. How can a server include a MESSAGE-INTEGRITY attribute in a response if the client did not use one in the request? What's the point of accepting such response? -11.2 & 11.3 (pages 30 & 31): The attributes USERNAME & PASSWORD are not backwards compatible with RFC3489 due to the changed length and padding requirements. The new way is IMHO better, but shouldn't this be mentioned somewhere in the spec? -11.6: The error code 300 and usage of an alternate server attribute ALTERNATE-SERVER. There are already ways to select alternate servers (e.g. trying the next DNS SRV result). As stated earlier, this also causes a security threat. Also, since this is not much usable for plain STUN use cases, I'd not include this at least in this STUN RFC. -General mumble: TLS implementation: this short term secret usage requiring TLS implementation has obviously been seen as a cumbersome feature, and thus it is AFAIK not (at least yet) generally adopted in STUN implementations. Should we still reconcider options which would be lighter to implement, and thus would be easier to get widely adopted? The long term credentials is one option, but it has it's own weaknesses, like the two-part message sequence due to the challenges. I'm just concerned about the risk that this feature won't be implemented later on either due to the too high benefit/cost ratio. I do however like the general idea of having a secure way to do STUN without much of settings in either the client nor the server. -- Tomi Kohonen Nokia Corporation _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 05 15:50:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2w0v-0004u2-HR; Fri, 05 Jan 2007 15:50:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2w0o-0004pK-OG; Fri, 05 Jan 2007 15:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2w0o-0007qe-C5; Fri, 05 Jan 2007 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 52E713297A; Fri, 5 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H2w0o-0002MW-6k; Fri, 05 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 05 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: behave@ietf.org Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-tcp-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : NAT Behavioral Requirements for TCP Author(s) : S. Guha, et al. Filename : draft-ietf-behave-tcp-03.txt Pages : 20 Date : 2007-1-5 This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and on-line games, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-tcp-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-tcp-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-behave-tcp-03.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-1-5114322.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-tcp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-tcp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-5114322.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 Fri Jan 05 18:42:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2yhN-0002T1-8u; Fri, 05 Jan 2007 18:42:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2yhM-0002Sw-9y for behave@ietf.org; Fri, 05 Jan 2007 18:42:08 -0500 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2yhL-0007YH-1Y for behave@ietf.org; Fri, 05 Jan 2007 18:42:08 -0500 Received: from exchfe1.cs.cornell.edu ([128.84.97.33]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 18:42:02 -0500 Received: from [128.84.227.36] ([128.84.227.36]) by exchfe1.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 18:41:57 -0500 Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-tcp-03.txt From: Saikat Guha To: behave In-Reply-To: References: Date: Fri, 05 Jan 2007 18:41:57 -0500 Message-Id: <1168040517.3654.0.camel@sioux.systems.cs.cornell.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.9.4 (2.9.4-4.fc7) X-OriginalArrivalTime: 05 Jan 2007 23:41:57.0814 (UTC) FILETIME=[16B84560:01C73123] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: behave@ietf.org X-Mailman-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="===============0117450430==" Errors-To: behave-bounces@ietf.org --===============0117450430== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-kfFvOmwSCXwctPTrYaBi" --=-kfFvOmwSCXwctPTrYaBi Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2007-01-05 at 15:50 -0500, Internet-Drafts@ietf.org wrote: > Title : NAT Behavioral Requirements for TCP > Author(s) : S. Guha, et al. > Filename : draft-ietf-behave-tcp-03.txt > Pages : 20 > Date : 2007-1-5 > =09 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-behave-tcp-03.txt A diff of the changes from -02 is at http://tinyurl.com/ylbcep The intended status of this draft will be _BCP_; this is not reflected in the version linked above. The key change in -03 is a rewording of REQ-4 (6s delayed ICMP) to preserve the original intent and meaning but to also allow NATs that always silently drop the SYN due to security concerns (as allowed by the SHOULD) to stay "fully compliant" with the spec, not just "compliant". This was discussed at the last meeting. Other changes include explaining why port-range preservation for TCP is left unspecified and dropping the MUST in section 7.3 text, both per WG consensus in Nov. cheers and a happy new year to all, --=20 Saikat --=-kfFvOmwSCXwctPTrYaBi Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBFnuJFnFltqi691/oRAuwsAJwOL1lbahDHPBCSZnO8sFKOCkPi4QCfewRp 5fFb4GoOFfB0GtbmodA9eOE= =ge7A -----END PGP SIGNATURE----- --=-kfFvOmwSCXwctPTrYaBi-- --===============0117450430== 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 --===============0117450430==-- From behave-bounces@ietf.org Wed Jan 10 19:04:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4nPt-0003K9-Lt; Wed, 10 Jan 2007 19:03:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4nPt-0003K4-AG for behave@ietf.org; Wed, 10 Jan 2007 19:03:37 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4nPr-0004V8-Tu for behave@ietf.org; Wed, 10 Jan 2007 19:03:37 -0500 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l0B03YKp027696 for ; Wed, 10 Jan 2007 17:03:34 -0700 (MST) Received: from srvxchg.cablelabs.com (10.5.0.20) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com); Wed, 10 Jan 2007 17:03:34 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C73513.EF463A1A" Subject: FW: [BEHAVE] STUN FINGERPRINT Date: Wed, 10 Jan 2007 17:03:33 -0700 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] STUN FINGERPRINT Thread-Index: AccvfH/BzK5HCLFBQOSM+DLZ0d22ZwFlyAwQ From: "Kevin Johns" To: X-Approved: ondar X-Spam-Score: 0.4 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C73513.EF463A1A Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C73513.EF463A1A" ------_=_NextPart_002_01C73513.EF463A1A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 I sent this last week and did not see a response. Given the original postings close proximity to the new year, I suspect several folks were on vacation and thus missed it. =20 Please respond if you have any thoughts on this. =20 Regards, Kevin Johns _____ =20 From: Kevin Johns=20 Sent: Wednesday, January 03, 2007 2:17 PM To: behave@ietf.org Subject: [BEHAVE] STUN FINGERPRINT All, =20 Per the text of the current STUN draft (-05), it states that the value is computed as the CRC-32 of the STUN message up to (but excluding) the FINGERPRINT attribute itself. =20 The question is on the length value used in the message length field of the STUN header. Is the FINGERPRINT calculated using the message length including the FINGERPRINT attribute or the message length minus the FINGERPRINT attribute? =20 I could not find this discussed anywhere in the draft and we need to know which way to implement. =20 Regards, Kevin Johns ------_=_NextPart_002_01C73513.EF463A1A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,
 
I sent this last week and did not see a = response.=20 Given the original postings close proximity to the new year, I = suspect=20 several folks were on vacation and thus missed it.
 
Please respond if you have any thoughts on=20 this.
 
Regards,
Kevin Johns

From: Kevin Johns
Sent: = Wednesday,=20 January 03, 2007 2:17 PM
To: = behave@ietf.org
Subject:=20 [BEHAVE] STUN FINGERPRINT

All,
 
Per = the text of the=20 current STUN draft (-05), it states that the value is computed as the = CRC-32 of=20 the STUN message up to (but excluding) the FINGERPRINT attribute=20 itself.
 
The = question is on=20 the length value used in the message length field of the STUN header. Is = the=20 FINGERPRINT calculated using the message length including the = FINGERPRINT=20 attribute or the message length minus the FINGERPRINT=20 attribute?
 
I = could not find=20 this discussed anywhere in the draft and we need to know which way to=20 implement.
 
Regards,
Kevin=20 Johns
------_=_NextPart_002_01C73513.EF463A1A-- ------_=_NextPart_001_01C73513.EF463A1A Content-Type: text/plain; name="ATT139176.txt" Content-Transfer-Encoding: base64 Content-Description: ATT139176.txt Content-Disposition: inline; filename="ATT139176.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkJlaGF2ZSBt YWlsaW5nIGxpc3QNCkJlaGF2ZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vYmVoYXZlDQo= ------_=_NextPart_001_01C73513.EF463A1A 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_001_01C73513.EF463A1A-- From behave-bounces@ietf.org Thu Jan 11 12:57:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54Aj-0007U1-4X; Thu, 11 Jan 2007 12:57:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54Ai-0007Tw-Q9 for behave@ietf.org; Thu, 11 Jan 2007 12:57:04 -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 1H54Ah-0004MZ-0S for behave@ietf.org; Thu, 11 Jan 2007 12:57:04 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 11 Jan 2007 09:56:40 -0800 X-IronPort-AV: i="4.13,174,1167638400"; d="scan'208"; a="355773191:sNHT5843959702" 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 l0BHudin009170; Thu, 11 Jan 2007 09:56:39 -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 l0BHudDk014250; Thu, 11 Jan 2007 09:56:39 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 09:56:38 -0800 Received: from [10.32.241.158] ([10.32.241.158]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 09:56:38 -0800 Message-ID: <45A67A55.7060702@cisco.com> Date: Thu, 11 Jan 2007 12:56:37 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Johns Subject: Re: FW: [BEHAVE] STUN FINGERPRINT References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2007 17:56:38.0630 (UTC) FILETIME=[D79A3060:01C735A9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2234; t=1168538200; x=1169402200; 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=20FW=3A=20[BEHAVE]=20STUN=20FINGERPRINT |Sender:=20; bh=eFn6ETUXhugwdD0ZJLuJYGLJ701TZhpwJ135SWVM2Xs=; b=hYKrkMnQAtcwMDKmcnA3+dWiFCNv0HoKSozzN6KM74073QWx6syFpfw1cXg+ldwNf5FMXel+ mc160nQMXf6pm1npqs+KtVMO4OiEPNbfY7mb7uOvIbfRS4l94fqBfPvD; 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: 41c17b4b16d1eedaa8395c26e9a251c4 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 replying Kevin. This is a good question. I think it should be including the FINGERPRINT. THis way, when the fingerprint is verified, the recipient does not need to modify the message prior to verification. I'll clarify along the with the other gazillion fixes required from comments :( -Jonathan R. Kevin Johns wrote: > All, > > I sent this last week and did not see a response. Given the original > postings close proximity to the new year, I suspect several folks were > on vacation and thus missed it. > > Please respond if you have any thoughts on this. > > Regards, > Kevin Johns > > ------------------------------------------------------------------------ > *From:* Kevin Johns > *Sent:* Wednesday, January 03, 2007 2:17 PM > *To:* behave@ietf.org > *Subject:* [BEHAVE] STUN FINGERPRINT > > All, > > Per the text of the current STUN draft (-05), it states that the value > is computed as the CRC-32 of the STUN message up to (but excluding) the > FINGERPRINT attribute itself. > > The question is on the length value used in the message length field of > the STUN header. Is the FINGERPRINT calculated using the message length > including the FINGERPRINT attribute or the message length minus the > FINGERPRINT attribute? > > I could not find this discussed anywhere in the draft and we need to > know which way to implement. > > Regards, > Kevin Johns > > > ------------------------------------------------------------------------ > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > > > ------------------------------------------------------------------------ > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jan 11 13:16:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54Sw-0001F5-Ml; Thu, 11 Jan 2007 13:15:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54Sv-0001A6-NW for behave@ietf.org; Thu, 11 Jan 2007 13:15:53 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H54Su-00008t-32 for behave@ietf.org; Thu, 11 Jan 2007 13:15:53 -0500 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l0BIFmYZ009711; Thu, 11 Jan 2007 11:15:48 -0700 (MST) Received: from srvxchg.cablelabs.com (10.5.0.20) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com); Thu, 11 Jan 2007 11:15:47 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: [BEHAVE] STUN FINGERPRINT Date: Thu, 11 Jan 2007 11:15:47 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: [BEHAVE] STUN FINGERPRINT Thread-Index: Acc1qebqj1E3CdStSmCXqCCgqzcv3gAAnhdQ From: "Kevin Johns" To: "Jonathan Rosenberg" X-Approved: ondar X-Spam-Score: 0.4 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Jonathan, Thanks for the response. I assume the same would go for the Message Integrity as well? Kevin=20 -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 Sent: Thursday, January 11, 2007 10:57 AM To: Kevin Johns Cc: behave@ietf.org Subject: Re: FW: [BEHAVE] STUN FINGERPRINT Sorry for not replying Kevin. This is a good question. I think it should be including the FINGERPRINT. THis way, when the fingerprint is verified, the recipient does not need to modify the message prior to verification. I'll clarify along the with the other gazillion fixes required from comments :( -Jonathan R. Kevin Johns wrote: > All, > =20 > I sent this last week and did not see a response. Given the original=20 > postings close proximity to the new year, I suspect several folks were > on vacation and thus missed it. > =20 > Please respond if you have any thoughts on this. > =20 > Regards, > Kevin Johns >=20 > ---------------------------------------------------------------------- > -- > *From:* Kevin Johns > *Sent:* Wednesday, January 03, 2007 2:17 PM > *To:* behave@ietf.org > *Subject:* [BEHAVE] STUN FINGERPRINT >=20 > All, > =20 > Per the text of the current STUN draft (-05), it states that the value > is computed as the CRC-32 of the STUN message up to (but excluding)=20 > the FINGERPRINT attribute itself. > =20 > The question is on the length value used in the message length field=20 > of the STUN header. Is the FINGERPRINT calculated using the message=20 > length including the FINGERPRINT attribute or the message length minus > the FINGERPRINT attribute? > =20 > I could not find this discussed anywhere in the draft and we need to=20 > know which way to implement. > =20 > Regards, > Kevin Johns >=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 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jan 11 13:32:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54iU-00018G-Tw; Thu, 11 Jan 2007 13:31:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54iS-00016r-U4 for behave@ietf.org; Thu, 11 Jan 2007 13:31:56 -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 1H54iQ-0003s2-Hk for behave@ietf.org; Thu, 11 Jan 2007 13:31:56 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 11 Jan 2007 10:31:54 -0800 X-IronPort-AV: i="4.13,174,1167638400"; d="scan'208"; a="456725373:sNHT104710404" 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 l0BIVrEn030444; Thu, 11 Jan 2007 10:31:53 -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 l0BIVrUw009147; Thu, 11 Jan 2007 10:31:53 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 10:31:52 -0800 Received: from [10.32.241.158] ([10.32.241.158]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 10:31:52 -0800 Message-ID: <45A68296.7050300@cisco.com> Date: Thu, 11 Jan 2007 13:31:50 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Johns Subject: Re: FW: [BEHAVE] STUN FINGERPRINT References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2007 18:31:52.0385 (UTC) FILETIME=[C37F9B10:01C735AE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2696; t=1168540313; x=1169404313; 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=20FW=3A=20[BEHAVE]=20STUN=20FINGERPRINT |Sender:=20; bh=gQJx7UWZ0tayJJLi2CDAakdF+dCWuyf/5RVwrBHHubI=; b=WA+TMvBYFQsRx4YmspcaEMu55tc+RCVvntqxM/YFsWwW6CDgK85dJ/tNZcHSUdjhrPUC3AJz cNVufn6jSBsxpCgorhY5k7dd8R0mQt/uX7FenH4ahpkWyOM1xioc99hY; 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: 6e922792024732fb1bb6f346e63517e4 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Yes. -Jonathan R. Kevin Johns wrote: > Jonathan, > > Thanks for the response. I assume the same would go for the Message > Integrity as well? > > Kevin > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Thursday, January 11, 2007 10:57 AM > To: Kevin Johns > Cc: behave@ietf.org > Subject: Re: FW: [BEHAVE] STUN FINGERPRINT > > Sorry for not replying Kevin. This is a good question. I think it should > be including the FINGERPRINT. THis way, when the fingerprint is > verified, the recipient does not need to modify the message prior to > verification. > > I'll clarify along the with the other gazillion fixes required from > comments :( > > -Jonathan R. > > Kevin Johns wrote: > > >>All, >> >>I sent this last week and did not see a response. Given the original >>postings close proximity to the new year, I suspect several folks were > > >>on vacation and thus missed it. >> >>Please respond if you have any thoughts on this. >> >>Regards, >>Kevin Johns >> >>---------------------------------------------------------------------- >>-- >>*From:* Kevin Johns >>*Sent:* Wednesday, January 03, 2007 2:17 PM >>*To:* behave@ietf.org >>*Subject:* [BEHAVE] STUN FINGERPRINT >> >>All, >> >>Per the text of the current STUN draft (-05), it states that the value > > >>is computed as the CRC-32 of the STUN message up to (but excluding) >>the FINGERPRINT attribute itself. >> >>The question is on the length value used in the message length field >>of the STUN header. Is the FINGERPRINT calculated using the message >>length including the FINGERPRINT attribute or the message length minus > > >>the FINGERPRINT attribute? >> >>I could not find this discussed anywhere in the draft and we need to >>know which way to implement. >> >>Regards, >>Kevin Johns >> >> >>---------------------------------------------------------------------- >>-- >> >>_______________________________________________ >>Behave mailing list >>Behave@ietf.org >>https://www1.ietf.org/mailman/listinfo/behave >> >> >>---------------------------------------------------------------------- >>-- >> >>_______________________________________________ >>Behave mailing list >>Behave@ietf.org >>https://www1.ietf.org/mailman/listinfo/behave > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jan 11 19:55:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Ahl-0003ye-9c; Thu, 11 Jan 2007 19:55:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Ahk-0003yZ-Aw for behave@ietf.org; Thu, 11 Jan 2007 19:55:36 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Ahi-00057J-DP for behave@ietf.org; Thu, 11 Jan 2007 19:55:36 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 11 Jan 2007 16:55:33 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l0C0tXp5016130 for ; Thu, 11 Jan 2007 16:55:33 -0800 Received: from dwingwxp (dhcp-128-107-100-78.cisco.com [128.107.100.78]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0C0tXnF028498 for ; Thu, 11 Jan 2007 16:55:33 -0800 (PST) From: "Dan Wing" To: Date: Thu, 11 Jan 2007 16:55:33 -0800 Message-ID: <066e01c735e4$5d25c340$20a36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acc15FzX2D9RWovrS3m3VzaGRdcNMg== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=207; t=1168563333; x=1169427333; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20Call=20for=20BEHAVE=20agenda=20items |Sender:=20; bh=RVvwNnEAo+kOrvrR8xtV9eXauw1Hgo2qOZj01P28jqg=; b=qK5YRpOyP3cSAByF9eSBlbYp885hhinIpusZh5NntPzHcpJCvjlKoknzOyLTh2A3+qpPEwod gcPXtBuut++HJQW1DZ071SKl9hKp7QgD6qoERQ4QSUbF84W4nogYHvIt; Authentication-Results: sj-dkim-8; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [BEHAVE] Call for BEHAVE agenda items X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I am starting to build the agenda for BEHAVE. If you would like a slot on the BEHAVE agenda for IETF 68 in Prague, please email me the I-D and duration you'd like. We have a two-hour slot. Thanks, -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 12 12:37:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5QL3-00031a-34; Fri, 12 Jan 2007 12:37:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5QL1-000317-1J for behave@ietf.org; Fri, 12 Jan 2007 12:37:11 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5QKw-0003Dg-7N for behave@ietf.org; Fri, 12 Jan 2007 12:37:11 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 12 Jan 2007 09:37:04 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l0CHb3d7012246 for ; Fri, 12 Jan 2007 09:37:03 -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 l0CHaxnF025234 for ; Fri, 12 Jan 2007 09:37:03 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 09:36:58 -0800 Received: from [10.32.241.158] ([10.32.241.158]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 09:36:58 -0800 Message-ID: <45A7C739.9050805@cisco.com> Date: Fri, 12 Jan 2007 12:36:57 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Wing Subject: Re: [BEHAVE] STUN attributes References: <0a8701c7181b$d214a360$c2f0200a@amer.cisco.com> In-Reply-To: <0a8701c7181b$d214a360$c2f0200a@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jan 2007 17:36:58.0505 (UTC) FILETIME=[429B2790:01C73670] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=962; t=1168623423; x=1169487423; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20STUN=20attributes |Sender:=20; bh=tQKn97V/ePiwlCvnqn50qAbMtEADvFuEkJ+P0GxjW54=; b=noIqZyYPUXNVO8yR9dPhAvFHY05PDCrM2FMwzDgFws5L5mbO4JUDi9R0ftr+p7Cgcc5kJwnm pOJOJN6dV/HxfHOShz2WrniPe/sjCCfNHlln7895+CS7x64jgLa2KmNx; Authentication-Results: sj-dkim-5; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org We should add the two attributes defined in ICE: 0x0024 PRIORITY 0x0025 USE-CANDIDATE -Jonathan R. Dan Wing wrote: > In case this helps anyone else, I built a table showing all of the STUN > attributes and where they're defined, > http://www.employees.org/behave/stun-attributes.html. As IANA will only > maintain a registry after an RFC is published, we will probably maintain > this page to coordinate STUN attribute values amongst Internet Drafts. > > -d > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 12 13:10:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Qqh-0007DP-2o; Fri, 12 Jan 2007 13:09:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Qqf-0007A6-BA for behave@ietf.org; Fri, 12 Jan 2007 13:09:53 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Qqd-0002UA-0q for behave@ietf.org; Fri, 12 Jan 2007 13:09:53 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-6.cisco.com with ESMTP; 12 Jan 2007 10:09:50 -0800 X-IronPort-AV: i="4.13,179,1167638400"; d="scan'208"; a="100989524:sNHT57145797" 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 l0CI9o5P007343 for ; Fri, 12 Jan 2007 10:09:50 -0800 Received: from dwingwxp ([10.32.240.196]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0CI9nho021649 for ; Fri, 12 Jan 2007 10:09:49 -0800 (PST) From: "Dan Wing" To: Date: Fri, 12 Jan 2007 10:09:49 -0800 Message-ID: <000801c73674$d9b1e890$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acc2dNlIAMpZWzaoSjOmEcKyoc10AA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1360; t=1168625390; x=1169489390; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20NAT=20Control=20STUN=20Usage |Sender:=20; bh=FcI3q+5FZYEYWib9M7+Ru5yKOcB18KmGN6Sjwo0va4A=; b=kQZTWI4anuSSwb1wORjpTFlWRPvfIBdFXKskz7Ez6SchGvq2YY7JWwvHLEbqvOuhXPq7zflf 9wOqzD3zV3LGSnfuEkJyb6867JnMNHGQBWr8ea7wMjCJOnus0qUWSOZu; Authentication-Results: sj-dkim-6; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [BEHAVE] NAT Control STUN Usage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org (as individual contributor:) In San Diego, Jonathan presented our draft-wing-behave-nat-control-stun-usage document, , : Simple Traversal Underneath NAT (STUN) is a mechanism for traversing NATs. STUN requests are transmitted through a NAT to external STUN servers. While this works very well, its two primary drawbacks are the inability to modify the properties of a NAT binding and the need to query a public STUN server for every NAT binding. These drawbacks require frequent messages which present a load on servers (like SIP servers and STUN servers) and are bad for low speed access networks, such as cellular. This document proposes that the STUN server be embedded in the NAT itself, and describes how these STUN servers can be readily discovered and utilized to reduce queries to public STUN servers and to reduce NAT keepalive traffic. As Jonathan indicated at the meeting, Cisco claims IPR on this technique. Terms are here: http://www.ietf.org/ietf/IPR/cisco-ipr-draft-wing-behave-nat-control-stun-us age-00.txt At the San Diego meeting there were positive comments around this approach. Is there interest in moving this work forward? -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 12 14:31:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5S7N-0004E8-57; Fri, 12 Jan 2007 14:31:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5S7M-0004DV-Ed for behave@ietf.org; Fri, 12 Jan 2007 14:31:12 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5S7J-0004Zg-3R for behave@ietf.org; Fri, 12 Jan 2007 14:31:12 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 12 Jan 2007 11:31:08 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l0CJV81D022373; Fri, 12 Jan 2007 11:31:08 -0800 Received: from dwingwxp ([10.32.240.196]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0CJV7nF024282; Fri, 12 Jan 2007 11:31:08 -0800 (PST) From: "Dan Wing" To: "'Jonathan Rosenberg'" Subject: RE: [BEHAVE] STUN attributes Date: Fri, 12 Jan 2007 11:31:07 -0800 Keywords: direct-to-dwing Message-ID: <012301c73680$3537ed80$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acc2cEJOl5tLr9/MQLCAJigmgZbfQwAD/D2A In-Reply-To: <45A7C739.9050805@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1146; t=1168630268; x=1169494268; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20STUN=20attributes |Sender:=20; bh=yGewPLWXvki9S5/Qjyv94Rf4ZsfpmAWo3+BN0Wfxxos=; b=KQGZhIrOMqfjwJlTxWf1OxxF7guhNu1HM6PK/+83902pEZV7WASFvlBCVMdat/2XrrO55EK5 7/isj/uPPi4KNk5XtjwZUzUB9Nk3hsg8zM6HFIsd5YBgKg4/UfhiiXdV; Authentication-Results: sj-dkim-8; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 Added. Thanks. -d > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Friday, January 12, 2007 9:37 AM > To: Dan Wing > Cc: behave@ietf.org > Subject: Re: [BEHAVE] STUN attributes > > We should add the two attributes defined in ICE: > > 0x0024 PRIORITY > 0x0025 USE-CANDIDATE > > -Jonathan R. > > Dan Wing wrote: > > > In case this helps anyone else, I built a table showing all > of the STUN > > attributes and where they're defined, > > http://www.employees.org/behave/stun-attributes.html. As > IANA will only > > maintain a registry after an RFC is published, we will > probably maintain > > this page to coordinate STUN attribute values amongst > Internet Drafts. > > > > -d > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www1.ietf.org/mailman/listinfo/behave > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Jan 13 00:38:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5baG-0003Vi-B7; Sat, 13 Jan 2007 00:37:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5baF-0003Uf-BE for behave@ietf.org; Sat, 13 Jan 2007 00:37:39 -0500 Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5baD-0007BT-0R for behave@ietf.org; Sat, 13 Jan 2007 00:37:39 -0500 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 12 Jan 2007 21:37:34 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.685.24; Fri, 12 Jan 2007 21:37:33 -0800 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2825); Fri, 12 Jan 2007 21:37:33 -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] NAT Control STUN Usage Date: Fri, 12 Jan 2007 21:37:23 -0800 Message-ID: <70C6EFCDFC8AAD418EF7063CD132D064033D193C@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <000801c73674$d9b1e890$c4f0200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [BEHAVE] NAT Control STUN Usage thread-index: Acc2dNlIAMpZWzaoSjOmEcKyoc10AAAX9ClA References: <000801c73674$d9b1e890$c4f0200a@amer.cisco.com> From: Christian Huitema To: Dan Wing , X-OriginalArrivalTime: 13 Jan 2007 05:37:33.0780 (UTC) FILETIME=[ECD69140:01C736D4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 > In San Diego, Jonathan presented our > draft-wing-behave-nat-control-stun-usage document, > , > 00>: > Simple Traversal Underneath NAT (STUN) is a mechanism for traversing > NATs. STUN requests are transmitted through a NAT to external STUN > servers. While this works very well, its two primary drawbacks are > the inability to modify the properties of a NAT binding and the need > to query a public STUN server for every NAT binding. These > drawbacks > require frequent messages which present a load on servers (like SIP > servers and STUN servers) and are bad for low speed access networks, > such as cellular. This document proposes that the STUN server be > embedded in the NAT itself, and describes how these STUN servers can > be readily discovered and utilized to reduce queries to public STUN > servers and to reduce NAT keepalive traffic. >=20 > As Jonathan indicated at the meeting, Cisco claims IPR on this > technique. > Terms are here: > http://www.ietf.org/ietf/IPR/cisco-ipr-draft-wing-behave-nat-control- > stun-us > age-00.txt >=20 >=20 > At the San Diego meeting there were positive comments around this > approach. >=20 > Is there interest in moving this work forward? If you want to get mapping control between the client and the NAT, why not just use UPNP? The protocol has been used since 2001, there are many implementations... -- Christian Huitema _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Jan 14 17:48:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6E8c-0005fU-FX; Sun, 14 Jan 2007 17:47:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6E8b-0005fP-P2 for behave@ietf.org; Sun, 14 Jan 2007 17:47:41 -0500 Received: from celine.siteprotect.com ([64.26.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6E8Z-0006S5-Pv for behave@ietf.org; Sun, 14 Jan 2007 17:47:41 -0500 Received: from sipx.cornfed.com (c-24-9-79-73.hsd1.co.comcast.net [24.9.79.73]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id l0EMlQ720079; Sun, 14 Jan 2007 16:47:27 -0600 From: "Frank W. Miller" To: jdrosen@cisco.com, behave@ietf.org In-Reply-To: <4599425B.8050805@acm.org> References: <4599425B.8050805@acm.org> Content-Type: text/plain Date: Sun, 14 Jan 2007 15:47:22 -0700 Message-Id: <1168814842.5815.3.camel@sipx.cornfed.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [BEHAVE] Question on draft-ietf-behave-rfc3489bis-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I noticed in Section 15.2: 0x8023: FINGERPRINT 0x8023: ALTERNATE-SERVER Are these two attributes supposed to have the same value? My apologies if I overlooked something... Thanks, FM _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Jan 14 21:29:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Hb2-0003K3-D7; Sun, 14 Jan 2007 21:29:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Hb1-0003Jt-0M for behave@ietf.org; Sun, 14 Jan 2007 21:29:15 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6Haw-0003wq-O5 for behave@ietf.org; Sun, 14 Jan 2007 21:29:14 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 14 Jan 2007 18:29:08 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l0F2T77G024691; Sun, 14 Jan 2007 18:29:07 -0800 Received: from dwingwxp ([10.32.240.196]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0F2T7nF008724; Sun, 14 Jan 2007 18:29:07 -0800 (PST) From: "Dan Wing" To: "'Christian Huitema'" , Subject: RE: [BEHAVE] NAT Control STUN Usage Date: Sun, 14 Jan 2007 18:29:07 -0800 Keywords: direct-to-dwing Message-ID: <003001c7384c$ef445010$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D064033D193C@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acc2dNlIAMpZWzaoSjOmEcKyoc10AAAX9ClAAAFpFkA= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=773; t=1168828148; x=1169692148; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20NAT=20Control=20STUN=20Usage |Sender:=20; bh=fdMpTO+sScgatg3V0v+rEavBq42uOYSRrFkerEekvG4=; b=xaIItc78tSgbTokJYRG4jCuRdwXemN/nhNRrMGqcxo8JWhhkdNKFNi6m3N4TQHwWL8W22frD e7UJ74T/6Ax7/+oQ1LiaV2VpVUJjcv8KJMB9I6Lb+06sZHhNFPnLp3JQ; Authentication-Results: sj-dkim-8; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 > If you want to get mapping control between the client and the NAT, > why not just use UPNP? The protocol has been used since 2001, > there are many implementations... * UPnP Doesn't work with nested NATs (a NAT in my apartment (or dorm room) and another in the basement of my apartment/dorm building; or two NATs at home), * UPnP is said to be slow , * some NAT vendors don't implement UPnP, * UPnP doesn't work in a routed network. Such as an enterprise network. * To work in the above situations, endpoints need to implement STUN anyway. Designing an endpoint that only works in UPnP environments restricts the endpoint to only ever working in the presence of UPnP. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Jan 14 21:29:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Hba-0003bk-WA; Sun, 14 Jan 2007 21:29:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6HbZ-0003bb-Mx for behave@ietf.org; Sun, 14 Jan 2007 21:29:49 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6HbW-0004GE-Bd for behave@ietf.org; Sun, 14 Jan 2007 21:29:49 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 14 Jan 2007 18:29:45 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l0F2Tjd4020832; Sun, 14 Jan 2007 18:29:45 -0800 Received: from dwingwxp ([10.32.240.196]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0F2Taho029337; Sun, 14 Jan 2007 18:29:37 -0800 (PST) From: "Dan Wing" To: "'Frank W. Miller'" , , Subject: RE: [BEHAVE] Question on draft-ietf-behave-rfc3489bis-05 Date: Sun, 14 Jan 2007 18:29:37 -0800 Message-ID: <003101c7384d$05c1e960$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1168814842.5815.3.camel@sipx.cornfed.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acc4LmIray6RTydLRrWt8tlOXj2PUwAHBznw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1504; t=1168828185; x=1169692185; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20Question=20on=20draft-ietf-behave-rfc3489b is-05 |Sender:=20; bh=xIOt3CPIR0uojI4BH+AuzPqxGILaFsOXe/mLxTDkilc=; b=O6UQ9PxKxQn3lI47NSlJCSbMC+qh3rOvmgH6DvRVALJuYSy3TjnbIUdvdnhMa5gwUA172/YY ZtC/mcJXVTayz/+lJGLE/4YtFGQprtQG3DHyUntoSuo43FslGNRxjWyh; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > I noticed in Section 15.2: > > 0x8023: FINGERPRINT > 0x8023: ALTERNATE-SERVER > > Are these two attributes supposed to have the same value? My > apologies if I overlooked something... No, they're not supposed to have the same value. The double assignment problem was mentioned at http://www.employees.org/behave/stun-attributes.html but it's also interesting how ALTERNATE-SERVERs values have evolved: grep -i "0x.*alternate-server" draft*turn*.txt draft-rosenberg-midcom-turn-00.txt: 0x0007: ALTERNATE-SERVER draft-rosenberg-midcom-turn-01.txt: 0x000e: ALTERNATE-SERVER draft-rosenberg-midcom-turn-02.txt: 0x000e: ALTERNATE-SERVER draft-rosenberg-midcom-turn-03.txt: 0x000e: ALTERNATE-SERVER draft-rosenberg-midcom-turn-04.txt: 0x000e: ALTERNATE-SERVER draft-rosenberg-midcom-turn-05.txt: 0x000e: ALTERNATE-SERVER draft-rosenberg-midcom-turn-06.txt: 0x000e: ALTERNATE-SERVER draft-rosenberg-midcom-turn-07.txt: 0x000e: ALTERNATE-SERVER draft-rosenberg-midcom-turn-08.txt: 0x000e: ALTERNATE-SERVER grep -i "0x.*alternate-server" draft-ietf-behave-rfc3489bis*.txt draft-ietf-behave-rfc3489bis-03.txt: 0x000E: ALTERNATE-SERVER draft-ietf-behave-rfc3489bis-03.txt: 0x8023: ALTERNATE-SERVER draft-ietf-behave-rfc3489bis-04.txt: 0x8023: ALTERNATE-SERVER draft-ietf-behave-rfc3489bis-05.txt: 0x8023: ALTERNATE-SERVER I'm not sure if there are implementations that rely on those values. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 15 05:02:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Ofv-00049D-56; Mon, 15 Jan 2007 05:02:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Oft-00048w-3X for behave@ietf.org; Mon, 15 Jan 2007 05:02:45 -0500 Received: from wr-out-0506.google.com ([64.233.184.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6Ofr-0002Bh-RW for behave@ietf.org; Mon, 15 Jan 2007 05:02:45 -0500 Received: by wr-out-0506.google.com with SMTP id i4so1001383wra for ; Mon, 15 Jan 2007 02:02:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=q5HlCx9KSnizPSmZzXlL1Paloma1L2epMK8h/TSUly9soSUZQi6txa+mlCuzYPHJWlidj/l8jiQtCtSsdrupa96nvjPjEPDcv5L59pxlkwU+BWXgloRrzGirLss8x3FDzhJTHbqEcMFF34HADZVgUnwhOxRSYTiVqs7UXArKyRA= Received: by 10.90.73.3 with SMTP id v3mr2604190aga.1168855363509; Mon, 15 Jan 2007 02:02:43 -0800 (PST) Received: by 10.90.98.17 with HTTP; Mon, 15 Jan 2007 02:02:43 -0800 (PST) Message-ID: <458913680701150202l620dca50o1afcf0e57680adcf@mail.gmail.com> Date: Mon, 15 Jan 2007 11:02:43 +0100 From: "Xavier Marjou" To: behave@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Google-Sender-Auth: dd3eacc02298de27 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: avt@ietf.org Subject: [BEHAVE] Update of rtp-keepalive draft X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org To keep this topic alive, I plan to update the following individual draft: http://tools.ietf.org/wg/behave/draft-marjou-behave-app-rtp-keepalive-00.tx= t I am therefore interested of any feedback, especially on which mechanism(s) is best. Xavier > On 12/3/06, Dan Wing wrote: > Minutes of the last BEHAVE meeting have been posted to: > http://www3.ietf.org/proceedings/06nov/minutes/behave.html > > Application Keepalive for NATs, Xavier Marjou - > draft-marjou-behave-app-rtp-keepalive-00 > status: separate from ICE, or integrate into Application milestone docum= ent? > > JR =96 this is app design guidelines. How about if we charter to create > that document and put this text, along with other text around it in > STUN all in one document? > Xavier Marjou (speaker, XM) =96 take to list. > Chair =96 question of which mechanisms might be best asked in AVT FA =96 > good to ask AVT for sure. But we should discuss here Magnus =96 both > groups working on it Chair =96 consensus to fold this into application > document, per JR's proposal. > Will figure out what to do on list. > FA =96 support. Think it's a good idea. But do we have an editor for > that, will it get done? I don't want to send this to dev/null. > PM =96 in our BEHAVE app document are we the best place to have that > discussion? > chair - don't have a clear decision on what to do, will work to figure > out where this goes. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 15 10:01:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6TKd-0007YC-6F; Mon, 15 Jan 2007 10:01:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6TKb-0007WG-QZ for behave@ietf.org; Mon, 15 Jan 2007 10:01:05 -0500 Received: from bayc1-pasmtp05.bayc1.hotmail.com ([65.54.191.165] helo=bayc1-pasmtp05.hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6TKX-0001Ic-E0 for behave@ietf.org; Mon, 15 Jan 2007 10:01:05 -0500 X-Originating-IP: [216.13.42.68] X-Originating-Email: [eric_d_cooper@sympatico.ca] Received: from ronin ([216.13.42.68]) by bayc1-pasmtp05.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 07:01:00 -0800 Message-ID: <004f01c738b5$f5d10220$65500a0a@ronin> From: "Eric Cooper" To: "Dan Wing" , References: <000801c73674$d9b1e890$c4f0200a@amer.cisco.com> Subject: Re: [BEHAVE] NAT Control STUN Usage Date: Mon, 15 Jan 2007 09:57:57 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 15 Jan 2007 15:01:00.0294 (UTC) FILETIME=[F7EABA60:01C738B5] X-Spam-Score: 2.2 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1837164278==" Errors-To: behave-bounces@ietf.org --===============1837164278== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SSdtIGludGVyZXN0ZWQgaW4gc2VlaW5nIHRoaXMgbW92ZSBmb3J3YXJkLg0KDQpFcmljLg0KDQot LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRhbiBXaW5nIiA8ZHdpbmdAY2lz Y28uY29tPg0KVG86IDxiZWhhdmVAaWV0Zi5vcmc+DQpTZW50OiBGcmlkYXksIEphbnVhcnkgMTIs IDIwMDcgMTowOSBQTQ0KU3ViamVjdDogW0JFSEFWRV0gTkFUIENvbnRyb2wgU1RVTiBVc2FnZQ0K DQoNCj4gKGFzIGluZGl2aWR1YWwgY29udHJpYnV0b3I6KQ0KPiANCj4gSW4gU2FuIERpZWdvLCBK b25hdGhhbiBwcmVzZW50ZWQgb3VyDQo+IGRyYWZ0LXdpbmctYmVoYXZlLW5hdC1jb250cm9sLXN0 dW4tdXNhZ2UgZG9jdW1lbnQsDQo+IDxodHRwOi8vd3d3My5pZXRmLm9yZy9wcm9jZWVkaW5ncy8w Nm5vdi9zbGlkZXMvYmVoYXZlLTUvc2xkMS5odG0+LCANCj4gPGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXdpbmctYmVoYXZlLW5hdC1jb250cm9sLXN0dW4tdXNhZ2UtMDA+Og0KPiAg IFNpbXBsZSBUcmF2ZXJzYWwgVW5kZXJuZWF0aCBOQVQgKFNUVU4pIGlzIGEgbWVjaGFuaXNtIGZv ciB0cmF2ZXJzaW5nDQo+ICAgTkFUcy4gIFNUVU4gcmVxdWVzdHMgYXJlIHRyYW5zbWl0dGVkIHRo cm91Z2ggYSBOQVQgdG8gZXh0ZXJuYWwgU1RVTg0KPiAgIHNlcnZlcnMuICBXaGlsZSB0aGlzIHdv cmtzIHZlcnkgd2VsbCwgaXRzIHR3byBwcmltYXJ5IGRyYXdiYWNrcyBhcmUNCj4gICB0aGUgaW5h YmlsaXR5IHRvIG1vZGlmeSB0aGUgcHJvcGVydGllcyBvZiBhIE5BVCBiaW5kaW5nIGFuZCB0aGUg bmVlZA0KPiAgIHRvIHF1ZXJ5IGEgcHVibGljIFNUVU4gc2VydmVyIGZvciBldmVyeSBOQVQgYmlu ZGluZy4gIFRoZXNlIGRyYXdiYWNrcw0KPiAgIHJlcXVpcmUgZnJlcXVlbnQgbWVzc2FnZXMgd2hp Y2ggcHJlc2VudCBhIGxvYWQgb24gc2VydmVycyAobGlrZSBTSVANCj4gICBzZXJ2ZXJzIGFuZCBT VFVOIHNlcnZlcnMpIGFuZCBhcmUgYmFkIGZvciBsb3cgc3BlZWQgYWNjZXNzIG5ldHdvcmtzLA0K PiAgIHN1Y2ggYXMgY2VsbHVsYXIuICBUaGlzIGRvY3VtZW50IHByb3Bvc2VzIHRoYXQgdGhlIFNU VU4gc2VydmVyIGJlDQo+ICAgZW1iZWRkZWQgaW4gdGhlIE5BVCBpdHNlbGYsIGFuZCBkZXNjcmli ZXMgaG93IHRoZXNlIFNUVU4gc2VydmVycyBjYW4NCj4gICBiZSByZWFkaWx5IGRpc2NvdmVyZWQg YW5kIHV0aWxpemVkIHRvIHJlZHVjZSBxdWVyaWVzIHRvIHB1YmxpYyBTVFVODQo+ICAgc2VydmVy cyBhbmQgdG8gcmVkdWNlIE5BVCBrZWVwYWxpdmUgdHJhZmZpYy4NCj4gDQo+IEFzIEpvbmF0aGFu IGluZGljYXRlZCBhdCB0aGUgbWVldGluZywgQ2lzY28gY2xhaW1zIElQUiBvbiB0aGlzIHRlY2hu aXF1ZS4NCj4gVGVybXMgYXJlIGhlcmU6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi9JUFIv Y2lzY28taXByLWRyYWZ0LXdpbmctYmVoYXZlLW5hdC1jb250cm9sLXN0dW4tdXMNCj4gYWdlLTAw LnR4dA0KPiANCj4gDQo+IEF0IHRoZSBTYW4gRGllZ28gbWVldGluZyB0aGVyZSB3ZXJlIHBvc2l0 aXZlIGNvbW1lbnRzIGFyb3VuZCB0aGlzIGFwcHJvYWNoLg0KPiANCj4gSXMgdGhlcmUgaW50ZXJl c3QgaW4gbW92aW5nIHRoaXMgd29yayBmb3J3YXJkPw0KPiANCj4gLWQNCj4gDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEJlaGF2ZSBtYWlsaW5n IGxpc3QNCj4gQmVoYXZlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2JlaGF2ZQ0KPg== --===============1837164278== 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 --===============1837164278==-- From behave-bounces@ietf.org Mon Jan 15 11:48:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6V0Y-0004Ak-9f; Mon, 15 Jan 2007 11:48:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6V0V-0004AY-Q8 for behave@ietf.org; Mon, 15 Jan 2007 11:48:28 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6V0U-0000tw-FK for behave@ietf.org; Mon, 15 Jan 2007 11:48:27 -0500 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l0FGmPOX016381 for ; Mon, 15 Jan 2007 09:48:25 -0700 (MST) Received: from srvxchg.cablelabs.com (10.5.0.20) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com); Mon, 15 Jan 2007 09:48:25 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 15 Jan 2007 09:48:24 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: STUN Relay Thread-Index: Acc4xPg+TLX8dWzHT5W3goPqi1Rpyg== From: "Kevin Johns" To: X-Approved: ondar X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Subject: [BEHAVE] STUN Relay X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0326082176==" Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. --===============0326082176== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C738C4.F8DC9FD1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C738C4.F8DC9FD1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 One of the properties of STUN relay is that the STUN relay server handles both STUN messages and media on the same IP and Port. This makes policy control a bit difficult as the policy enforcement point has to be able to identify STUN messages over Media in order to enforce policy. Has there been any discussion around having a management only IP/Port and as part of the allocation process allocate a local transport address (the address and port the UA requesting the allocation sends and receives from) in addition to the currently allocated relayed transport address? =20 Such and approach would facilitate policy management as STUN Relay (and STUN for that matter) can be classified separately from the media traffic allowing for separate policy enforcement. =20 Regards, Kevin ------_=_NextPart_001_01C738C4.F8DC9FD1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
One of = the=20 properties of STUN relay is that the STUN relay server handles both STUN = messages and media on the same IP and Port. This makes policy control a = bit=20 difficult as the policy enforcement point has to be able to identify = STUN=20 messages over Media in order to enforce policy. Has there been any = discussion=20 around having a management only IP/Port and as part of the allocation = process=20 allocate a local transport address (the address and port the UA = requesting the=20 allocation sends and receives from) in addition to the currently = allocated=20 relayed transport address?
 
Such = and approach=20 would facilitate policy management as STUN Relay (and STUN for that = matter) can=20 be classified separately from the media traffic allowing for separate = policy=20 enforcement.
 
Regards,
Kevin
------_=_NextPart_001_01C738C4.F8DC9FD1-- --===============0326082176== 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 --===============0326082176==-- From behave-bounces@ietf.org Mon Jan 15 11:54:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6V64-0008QR-9L; Mon, 15 Jan 2007 11:54:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6V63-0008QD-Bx for behave@ietf.org; Mon, 15 Jan 2007 11:54:11 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6V62-0001oN-1O for behave@ietf.org; Mon, 15 Jan 2007 11:54:11 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l0FGs6C29370; Mon, 15 Jan 2007 11:54:06 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [BEHAVE] STUN Relay Date: Mon, 15 Jan 2007 10:54:05 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437112419AE2@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] STUN Relay Thread-index: Acc4xPg+TLX8dWzHT5W3goPqi1RpygAALIxQ From: "Brian Stucker" To: "Kevin Johns" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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: , Content-Type: multipart/mixed; boundary="===============0863824075==" Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. --===============0863824075== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C738C5.C4989775" This is a multi-part message in MIME format. ------_=_NextPart_001_01C738C5.C4989775 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What sort of policy management separation are you looking for? I am assuming that you are talking about gating behavior at the relay? =20 Regards, Brian ________________________________ From: Kevin Johns [mailto:K.Johns@CableLabs.com]=20 Sent: Monday, January 15, 2007 10:48 AM To: behave@ietf.org Subject: [BEHAVE] STUN Relay =09 =09 =20 One of the properties of STUN relay is that the STUN relay server handles both STUN messages and media on the same IP and Port. This makes policy control a bit difficult as the policy enforcement point has to be able to identify STUN messages over Media in order to enforce policy. Has there been any discussion around having a management only IP/Port and as part of the allocation process allocate a local transport address (the address and port the UA requesting the allocation sends and receives from) in addition to the currently allocated relayed transport address? =20 Such and approach would facilitate policy management as STUN Relay (and STUN for that matter) can be classified separately from the media traffic allowing for separate policy enforcement. =20 Regards, Kevin ------_=_NextPart_001_01C738C5.C4989775 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
What sort of policy management separation are = you looking=20 for? I am assuming that you are talking about gating behavior at the=20 relay?
 
Regards,
Brian

From: Kevin Johns=20 [mailto:K.Johns@CableLabs.com]
Sent: Monday, January 15, = 2007 10:48=20 AM
To: behave@ietf.org
Subject: [BEHAVE] STUN=20 Relay

 
One = of the=20 properties of STUN relay is that the STUN relay server handles both = STUN=20 messages and media on the same IP and Port. This makes policy control = a bit=20 difficult as the policy enforcement point has to be able to identify = STUN=20 messages over Media in order to enforce policy. Has there been any = discussion=20 around having a management only IP/Port and as part of the allocation = process=20 allocate a local transport address (the address and port the UA = requesting the=20 allocation sends and receives from) in addition to the currently = allocated=20 relayed transport address?
 
Such = and approach=20 would facilitate policy management as STUN Relay (and STUN for that = matter)=20 can be classified separately from the media traffic allowing for = separate=20 policy enforcement.
 
Regards,
Kevin
------_=_NextPart_001_01C738C5.C4989775-- --===============0863824075== 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 --===============0863824075==-- From behave-bounces@ietf.org Mon Jan 15 12:26:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6VbI-0000C8-J7; Mon, 15 Jan 2007 12:26:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6VbH-0000C3-DK for behave@ietf.org; Mon, 15 Jan 2007 12:26:27 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6VbE-0006em-RJ for behave@ietf.org; Mon, 15 Jan 2007 12:26:27 -0500 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l0FHQNuK004439; Mon, 15 Jan 2007 10:26:23 -0700 (MST) Received: from srvxchg.cablelabs.com (10.5.0.20) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com); Mon, 15 Jan 2007 10:26:23 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [BEHAVE] STUN Relay Date: Mon, 15 Jan 2007 10:26:22 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] STUN Relay Thread-Index: Acc4xPg+TLX8dWzHT5W3goPqi1RpygAALIxQAADG+kA= From: "Kevin Johns" To: "Brian Stucker" , X-Approved: ondar X-Spam-Score: 0.1 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 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: , Content-Type: multipart/mixed; boundary="===============1704327806==" Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. --===============1704327806== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C738CA.46A59D51" This is a multi-part message in MIME format. ------_=_NextPart_001_01C738CA.46A59D51 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Brian, =20 The concern is this, a UA needs to send a STUN message to a STUN Relay server to get an allocated address to put in its SDP. To allow this, the policy enforcement point (CMTS, GGSN, AP, etc.) needs to have a policy which allows the UA to send and receive messages from the STUN Relay. Given the UA needs to communicate with the STUN Relay prior to any session establishment, the policy needs to be static and apply to all UAs. Now you have effectively installed a policy which allows UAs to communicate freely via this static default policy. Now, this may not be a big issue if the network installs a dynamic policy once the session is established and the dynamic policy takes precedence over the static. However, if the network does not install a dynamic policy, the UA still has a free path to communicate with another UA. =20 So it would be nice to be able to install a default policy which only allows for STUN management traffic. Thus, if a UA requests a relay address allocation the relay would happen on a different address/port and thus block the UAs ability to relay media without a policy. =20 Kevin _____ =20 From: Brian Stucker [mailto:bstucker@nortel.com]=20 Sent: Monday, January 15, 2007 9:54 AM To: Kevin Johns; behave@ietf.org Subject: RE: [BEHAVE] STUN Relay What sort of policy management separation are you looking for? I am assuming that you are talking about gating behavior at the relay? =20 Regards, Brian _____ =20 From: Kevin Johns [mailto:K.Johns@CableLabs.com]=20 Sent: Monday, January 15, 2007 10:48 AM To: behave@ietf.org Subject: [BEHAVE] STUN Relay =09 =09 =20 One of the properties of STUN relay is that the STUN relay server handles both STUN messages and media on the same IP and Port. This makes policy control a bit difficult as the policy enforcement point has to be able to identify STUN messages over Media in order to enforce policy. Has there been any discussion around having a management only IP/Port and as part of the allocation process allocate a local transport address (the address and port the UA requesting the allocation sends and receives from) in addition to the currently allocated relayed transport address? =20 Such and approach would facilitate policy management as STUN Relay (and STUN for that matter) can be classified separately from the media traffic allowing for separate policy enforcement. =20 Regards, Kevin ------_=_NextPart_001_01C738CA.46A59D51 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Brian,
 
The concern is this, a UA needs to send a STUN = message to a=20 STUN Relay server to get an allocated address to put in its SDP. To = allow this,=20 the policy enforcement point (CMTS, GGSN, AP, etc.) needs to have a = policy which=20 allows the UA to send and receive messages from the STUN Relay. Given = the UA=20 needs to communicate with the STUN Relay prior to any session = establishment, the=20 policy needs to be static and apply to all UAs. Now you have effectively = installed a policy which allows UAs to communicate freely via this = static=20 default policy. Now, this may not be a big issue if the network installs = a=20 dynamic policy once the session is established and the dynamic policy = takes=20 precedence over the static. However, if the network does not install a = dynamic=20 policy, the UA still has a free path to communicate with another=20 UA.
 
So it=20 would be nice to be able to install a default policy which only allows = for STUN=20 management traffic. Thus, if a UA requests a relay address allocation = the relay=20 would happen on a different address/port and thus block the UAs ability = to relay=20 media without a policy.
 
Kevin

From: Brian Stucker = [mailto:bstucker@nortel.com]=20
Sent: Monday, January 15, 2007 9:54 AM
To: Kevin = Johns;=20 behave@ietf.org
Subject: RE: [BEHAVE] STUN = Relay

What sort of policy management separation are = you looking=20 for? I am assuming that you are talking about gating behavior at the=20 relay?
 
Regards,
Brian

From: Kevin Johns=20 [mailto:K.Johns@CableLabs.com]
Sent: Monday, January 15, = 2007 10:48=20 AM
To: behave@ietf.org
Subject: [BEHAVE] STUN=20 Relay

 
One = of the=20 properties of STUN relay is that the STUN relay server handles both = STUN=20 messages and media on the same IP and Port. This makes policy control = a bit=20 difficult as the policy enforcement point has to be able to identify = STUN=20 messages over Media in order to enforce policy. Has there been any = discussion=20 around having a management only IP/Port and as part of the allocation = process=20 allocate a local transport address (the address and port the UA = requesting the=20 allocation sends and receives from) in addition to the currently = allocated=20 relayed transport address?
 
Such = and approach=20 would facilitate policy management as STUN Relay (and STUN for that = matter)=20 can be classified separately from the media traffic allowing for = separate=20 policy enforcement.
 
Regards,
Kevin
------_=_NextPart_001_01C738CA.46A59D51-- --===============1704327806== 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 --===============1704327806==-- From behave-bounces@ietf.org Mon Jan 15 14:33:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6XZo-0008Ok-1y; Mon, 15 Jan 2007 14:33:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6XZm-0008Od-Ej for behave@ietf.org; Mon, 15 Jan 2007 14:33:02 -0500 Received: from mx4-3.spamtrap.magma.ca ([209.217.78.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6XZk-0006P5-2b for behave@ietf.org; Mon, 15 Jan 2007 14:33:02 -0500 Received: from mail2.magma.ca (mail2.internal.magma.ca [10.0.10.12]) by mx4-3.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l0FJWwdo000355; Mon, 15 Jan 2007 14:32:58 -0500 Received: from [192.168.1.75] ([216.13.42.66]) (authenticated bits=0) by mail2.magma.ca (Magma's Mail Server) with ESMTP id l0FJWuvd012365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Jan 2007 14:32:58 -0500 In-Reply-To: <000801c73674$d9b1e890$c4f0200a@amer.cisco.com> References: <000801c73674$d9b1e890$c4f0200a@amer.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] NAT Control STUN Usage Date: Mon, 15 Jan 2007 14:33:17 -0500 To: Dan Wing X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 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 I would like to see BEHAVE take on work in this area. I think that a solution to this problem is of interest. May I suggest that the work begin by writing a problem statement, so that we can agree on exactly what we are trying to achieve? This could be just a section or two at the beginning of the existing document (i.e., I am NOT suggesting a separate requirements document). - Philip On 12-Jan-07, at 13:09 , Dan Wing wrote: > (as individual contributor:) > > In San Diego, Jonathan presented our > draft-wing-behave-nat-control-stun-usage document, > , > usage-00>: > Simple Traversal Underneath NAT (STUN) is a mechanism for > traversing > NATs. STUN requests are transmitted through a NAT to external STUN > servers. While this works very well, its two primary drawbacks are > the inability to modify the properties of a NAT binding and the > need > to query a public STUN server for every NAT binding. These > drawbacks > require frequent messages which present a load on servers (like SIP > servers and STUN servers) and are bad for low speed access > networks, > such as cellular. This document proposes that the STUN server be > embedded in the NAT itself, and describes how these STUN servers > can > be readily discovered and utilized to reduce queries to public STUN > servers and to reduce NAT keepalive traffic. > > As Jonathan indicated at the meeting, Cisco claims IPR on this > technique. > Terms are here: > http://www.ietf.org/ietf/IPR/cisco-ipr-draft-wing-behave-nat- > control-stun-us > age-00.txt > > > At the San Diego meeting there were positive comments around this > approach. > > Is there interest in moving this work forward? > > -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 Jan 15 17:28:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6aJH-0003Jm-2H; Mon, 15 Jan 2007 17:28:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6aJF-0003Jh-Ax for behave@ietf.org; Mon, 15 Jan 2007 17:28:09 -0500 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6aJC-0006eA-OW for behave@ietf.org; Mon, 15 Jan 2007 17:28:09 -0500 Received: by ug-out-1314.google.com with SMTP id 72so1340997ugd for ; Mon, 15 Jan 2007 14:28:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=CoaUyeGzD+cLKg0u5D/5BzJ7jXNR6jGduISVZeJ637yhKXDJuyTBbkbTbFpkouGnnDFsmIjGV0yeA61FY0MGr+aI2Wsx4BuV9NEoROM5Gj9gm4K7w2Ae9C8coDzF0I9kIVw49C9QsmjN7mitNcp2zlxue3n4Wn9H6OsLqK3FKfo= Received: by 10.66.221.6 with SMTP id t6mr6155809ugg.1168900085036; Mon, 15 Jan 2007 14:28:05 -0800 (PST) Received: by 10.66.237.5 with HTTP; Mon, 15 Jan 2007 14:28:04 -0800 (PST) Message-ID: Date: Mon, 15 Jan 2007 14:28:04 -0800 From: "Neil Deason" To: behave@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [BEHAVE] STUN relay server replay attacks X-BeenThere: behave@ietf.org X-Mailman-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="===============1443929612==" Errors-To: behave-bounces@ietf.org --===============1443929612== Content-Type: multipart/alternative; boundary="----=_Part_93323_18975244.1168900084883" ------=_Part_93323_18975244.1168900084883 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello Folks. The use of long term credentials to authenticate STUN requests within relay sessions opens a number of replay type attacks. For example: - DoS on server by using up ports through replaying Allocate requests - DoS on clients by replaying Send requests - Session hijacking by replaying SetActiveDestination requests Possible options to address this: a) Add a sequence number in STUN messages This could be a new extension attribute or possibly the transaction ID could be used. The transaction ID could be used by reserving the last 4 bytes to be sequence number or alternatively within a relay session only the first Allocate request uses a randomly chosen transaction ID and then subsequent requests in the session increment it. b) Add a nonce count for STUN messages authenticated with long term creds Add an nonce-count attribute to record the number of times a nonce has been used within requests. Client will need to include this count in every request that carries the nonce, i.e. the first request sent carries a nonce-count of 1, the next 2 etc. Servers then need to maintain their own copy of this count and if the same value is seen twice it is a potential replay. ------=_Part_93323_18975244.1168900084883 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello Folks.
 
The use of long term credentials to authenticate STUN requests within relay sessions opens a number of replay type attacks. For example:
 
- DoS on server by using up ports through replaying Allocate requests
- DoS on clients by replaying Send requests
- Session hijacking by replaying SetActiveDestination requests
 
Possible options to address this:
 
a) Add a sequence number in STUN messages
 
This could be a new extension attribute or possibly the transaction ID could be used. The transaction ID could be used by reserving the last 4 bytes to be sequence number or alternatively within a relay session only the first Allocate request uses a randomly chosen transaction ID and then subsequent requests in the session increment it.
 
b) Add a nonce count for STUN messages authenticated with long term creds
 
Add an nonce-count attribute to record the number of times a nonce has been used within requests. Client will need to include this count in every request that carries the nonce, i.e. the first request sent carries a nonce-count of 1, the next 2 etc. Servers then need to maintain their own copy of this count and if the same value is seen twice it is a potential replay.
------=_Part_93323_18975244.1168900084883-- --===============1443929612== 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 --===============1443929612==-- From behave-bounces@ietf.org Tue Jan 16 00:02:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6gSU-00012A-UP; Tue, 16 Jan 2007 00:02:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6gST-0000xE-EZ for behave@ietf.org; Tue, 16 Jan 2007 00:02:05 -0500 Received: from celine.siteprotect.com ([64.26.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6gSR-0008Ci-Hf for behave@ietf.org; Tue, 16 Jan 2007 00:02:04 -0500 Received: from sipx.cornfed.com (c-24-9-79-73.hsd1.co.comcast.net [24.9.79.73]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id l0G51sM29249 for ; Mon, 15 Jan 2007 23:01:54 -0600 From: "Frank W. Miller" To: behave@ietf.org In-Reply-To: <003101c7384d$05c1e960$c4f0200a@amer.cisco.com> References: <003101c7384d$05c1e960$c4f0200a@amer.cisco.com> Content-Type: text/plain Date: Mon, 15 Jan 2007 22:01:51 -0700 Message-Id: <1168923711.5341.1.camel@sipx.cornfed.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [BEHAVE] Another question on draft-ietf-behave-rfc3489bis-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Is the magic cookie field treated as a 32-bit value, i.e. do you apply htonl() on it before sending or is it a byte array like the transaction ID? Thanks, FM _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 16 01:27:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6hnI-0000Zu-0N; Tue, 16 Jan 2007 01:27:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6hnG-0000UQ-2T for behave@ietf.org; Tue, 16 Jan 2007 01:27:38 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6hnE-000343-Mv for behave@ietf.org; Tue, 16 Jan 2007 01:27:38 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 15 Jan 2007 22:27:35 -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 l0G6RaCi012199; Mon, 15 Jan 2007 22:27:36 -0800 Received: from dwingwxp ([10.32.240.196]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0G6RZnF005085; Mon, 15 Jan 2007 22:27:35 -0800 (PST) From: "Dan Wing" To: "'Kevin Johns'" , "'Brian Stucker'" , Subject: RE: [BEHAVE] STUN Relay Date: Mon, 15 Jan 2007 22:27:34 -0800 Message-ID: <020301c73937$6973a6c0$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acc4xPg+TLX8dWzHT5W3goPqi1RpygAALIxQAADG+kAAG37PcA== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3365; t=1168928856; x=1169792856; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20STUN=20Relay |Sender:=20; bh=jg76SBQQYbSeGMcEollcFbQ12eSwRmpwVkLR3nKUHFk=; b=D2tYAHhCMYw8XzejW6+aiQDucURxFiD2qpURMCv8JNN1r58j7srQBksubz0euR+4bB0cfekd AX2I3SBVMjBSEG3fmjjN4M/+VfmOZ3shQuGsxlCwc3cp/el5YJRwkydl; Authentication-Results: sj-dkim-7; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org You need a bit more than STUN management traffic -- the endpoint needs to also be able to send ICE connectivity checks through the TURN server. Otherwise, the endpoint will never know that the path through the TURN server is a viable path. Implementing additional functionality in the TURN server, akin to what I described in draft-wing-session-auth-00, should provide the hooks necessary to block or detect attempts to use a TURN server without first signaling via SIP. -d > -----Original Message----- > From: Kevin Johns [mailto:K.Johns@CableLabs.com] > Sent: Monday, January 15, 2007 9:26 AM > To: Brian Stucker; behave@ietf.org > Subject: RE: [BEHAVE] STUN Relay > > Brian, > > The concern is this, a UA needs to send a STUN message to a > STUN Relay server to get an allocated address to put in its > SDP. To allow this, the policy enforcement point (CMTS, GGSN, > AP, etc.) needs to have a policy which allows the UA to send > and receive messages from the STUN Relay. Given the UA needs > to communicate with the STUN Relay prior to any session > establishment, the policy needs to be static and apply to all > UAs. Now you have effectively installed a policy which allows > UAs to communicate freely via this static default policy. > Now, this may not be a big issue if the network installs a > dynamic policy once the session is established and the > dynamic policy takes precedence over the static. However, if > the network does not install a dynamic policy, the UA still > has a free path to communicate with another UA. > > So it would be nice to be able to install a default policy > which only allows for STUN management traffic. Thus, if a UA > requests a relay address allocation the relay would happen on > a different address/port and thus block the UAs ability to > relay media without a policy. > > Kevin > > ________________________________ > > From: Brian Stucker [mailto:bstucker@nortel.com] > Sent: Monday, January 15, 2007 9:54 AM > To: Kevin Johns; behave@ietf.org > Subject: RE: [BEHAVE] STUN Relay > > > What sort of policy management separation are you looking > for? I am assuming that you are talking about gating behavior > at the relay? > > Regards, > Brian > > > ________________________________ > > From: Kevin Johns [mailto:K.Johns@CableLabs.com] > Sent: Monday, January 15, 2007 10:48 AM > To: behave@ietf.org > Subject: [BEHAVE] STUN Relay > > > > One of the properties of STUN relay is that the STUN > relay server handles both STUN messages and media on the same > IP and Port. This makes policy control a bit difficult as the > policy enforcement point has to be able to identify STUN > messages over Media in order to enforce policy. Has there > been any discussion around having a management only IP/Port > and as part of the allocation process allocate a local > transport address (the address and port the UA requesting the > allocation sends and receives from) in addition to the > currently allocated relayed transport address? > > Such and approach would facilitate policy management as > STUN Relay (and STUN for that matter) can be classified > separately from the media traffic allowing for separate > policy enforcement. > > Regards, > Kevin > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 16 02:12:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6iUm-0001E8-Sw; Tue, 16 Jan 2007 02:12:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6iUl-0001E3-HY for behave@ietf.org; Tue, 16 Jan 2007 02:12:35 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6iUk-0008K1-3b for behave@ietf.org; Tue, 16 Jan 2007 02:12:35 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0G79ps2006467 for ; Tue, 16 Jan 2007 09:10:23 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 09:12:29 +0200 Received: from esdhcp042186.research.nokia.com ([172.21.42.186]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 16 Jan 2007 09:12:29 +0200 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia-NRC Helsinki To: behave@ietf.org Subject: Re: [BEHAVE] Another question on draft-ietf-behave-rfc3489bis-05 Date: Tue, 16 Jan 2007 09:13:22 +0200 User-Agent: KMail/1.9.5 References: <003101c7384d$05c1e960$c4f0200a@amer.cisco.com> <1168923711.5341.1.camel@sipx.cornfed.com> In-Reply-To: <1168923711.5341.1.camel@sipx.cornfed.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200701160913.22384.Remi.Denis-Courmont@nokia.com> X-OriginalArrivalTime: 16 Jan 2007 07:12:29.0050 (UTC) FILETIME=[AEB90DA0:01C7393D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 16 January 2007 07:01, ext Frank W. Miller a =C3=A9crit=C2=A0: > Is the magic cookie field treated as a 32-bit value, i.e. do you apply > htonl() on it before sending or is it a byte array like the transaction > ID? How you read/write the cookie is an implementation detail. Of course, the=20 cookie value in the specification is in network byte order. =2D-=20 R=C3=A9mi Denis-Courmont Research Engineer _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 16 02:36:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6irc-0008Kz-T9; Tue, 16 Jan 2007 02:36:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6X7r-0005VE-JZ; Mon, 15 Jan 2007 14:04:11 -0500 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6X7q-00031j-8s; Mon, 15 Jan 2007 14:04:11 -0500 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id DC7992005D; Mon, 15 Jan 2007 14:04:09 -0500 (EST) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31208-05; Mon, 15 Jan 2007 14:04:09 -0500 (EST) Received: from ottpop01.software.mitel.com (ottpop01.mitel.com [134.199.30.50]) by smtp.mitel.com (Postfix) with ESMTP id 3D16320063; Mon, 15 Jan 2007 14:04:09 -0500 (EST) Received: from [10.39.164.100] ([10.39.164.100]) by ottpop01.software.mitel.com (8.12.10/8.12.10) with ESMTP id l0FJ47WW022121; Mon, 15 Jan 2007 14:04:07 -0500 (EST) Message-ID: <45ABD028.4090804@mitel.com> Date: Mon, 15 Jan 2007 14:04:08 -0500 From: Lee Dilkie User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Xavier Marjou References: <458913680701150202l620dca50o1afcf0e57680adcf@mail.gmail.com> In-Reply-To: <458913680701150202l620dca50o1afcf0e57680adcf@mail.gmail.com> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=windows-1252 X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-Mailman-Approved-At: Tue, 16 Jan 2007 02:36:11 -0500 Cc: behave@ietf.org, avt@ietf.org Subject: [BEHAVE] Re: [AVT] Update of rtp-keepalive draft X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I'd vote for 4.1 first, followed by 4.5 (which sounds a lot like 4.7 to me only it's defined). reasons: sending a 0-byte udp packet is solving a network issue, not an RTP issue and shouldn't pretend to be RTP. the cons specified: - udp specific, well yes but this isn't an issue with tcp anyway. - rx-ing party might not handle this. Perhaps, but since these are intended to be used for NAT traversal I would assume the rx-ing party would be most probably aware since the address:port of the received udp needs to be communicated to the tx-ing party anyway, and they generally need to share the same socket(or at least appear to). Otherwise I'd pick an unused RTP payload type value and define it as reserved for NAT keepalive usage. I guess this most closely maps to 4.5. Regards, Lee Dilkie (we implemented the 0-byte udp in our solution, FWIW, although we choose 30 second intervals). Xavier Marjou wrote: > To keep this topic alive, I plan to update the following individual > draft: > http://tools.ietf.org/wg/behave/draft-marjou-behave-app-rtp-keepalive-0= 0.txt > > > I am therefore interested of any feedback, especially on which > mechanism(s) is best. > > Xavier > >> On 12/3/06, Dan Wing wrote: >> Minutes of the last BEHAVE meeting have been posted to: >> http://www3.ietf.org/proceedings/06nov/minutes/behave.html >> >> Application Keepalive for NATs, Xavier Marjou - >> draft-marjou-behave-app-rtp-keepalive-00 >> status: separate from ICE, or integrate into Application milestone >> document? >> >> JR =96 this is app design guidelines. How about if we charter to creat= e >> that document and put this text, along with other text around it in >> STUN all in one document? >> Xavier Marjou (speaker, XM) =96 take to list. >> Chair =96 question of which mechanisms might be best asked in AVT FA =96 >> good to ask AVT for sure. But we should discuss here Magnus =96 both >> groups working on it Chair =96 consensus to fold this into application >> document, per JR's proposal. >> Will figure out what to do on list. >> FA =96 support. Think it's a good idea. But do we have an editor for >> that, will it get done? I don't want to send this to dev/null. >> PM =96 in our BEHAVE app document are we the best place to have that >> discussion? >> chair - don't have a clear decision on what to do, will work to figure >> out where this goes. > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 16 11:59:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6reG-0006lg-9a; Tue, 16 Jan 2007 11:59:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6reF-0006lN-8L; Tue, 16 Jan 2007 11:58:59 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6reD-0006WV-Oh; Tue, 16 Jan 2007 11:58:59 -0500 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:60646) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1H6reD-0007vo-6U; Tue, 16 Jan 2007 16:58:57 +0000 In-Reply-To: <45ABD028.4090804@mitel.com> References: <458913680701150202l620dca50o1afcf0e57680adcf@mail.gmail.com> <45ABD028.4090804@mitel.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <509E65FC-40C6-474A-840D-EF3D105AAE92@csperkins.org> Content-Transfer-Encoding: quoted-printable From: Colin Perkins Date: Tue, 16 Jan 2007 16:58:55 +0000 To: Lee Dilkie X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: behave@ietf.org, Xavier Marjou , avt@ietf.org Subject: [BEHAVE] Re: [AVT] Update of rtp-keepalive draft X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Do we need to mandate an alternative? All of the alternatives =20 specified will work, and RTP implementations have to be robust to =20 receiving all seven types of packet anyway (otherwise, there is a =20 trivial denial-of-service attack on the application). As long as =20 something is sent at an appropriate interval, the NAT will be happy, =20 and the application can use whatever mechanism is appropriate for it. Colin On 15 Jan 2007, at 19:04, Lee Dilkie wrote: > I'd vote for 4.1 first, followed by 4.5 (which sounds a lot like =20 > 4.7 to > me only it's defined). > > reasons: > > sending a 0-byte udp packet is solving a network issue, not an RTP =20 > issue > and shouldn't pretend to be RTP. > > the cons specified: > - udp specific, well yes but this isn't an issue with tcp anyway. > - rx-ing party might not handle this. Perhaps, but since these are > intended to be used for NAT traversal I would assume the rx-ing party > would be most probably aware since the address:port of the received =20= > udp > needs to be communicated to the tx-ing party anyway, and they =20 > generally > need to share the same socket(or at least appear to). > > Otherwise I'd pick an unused RTP payload type value and define it as > reserved for NAT keepalive usage. I guess this most closely maps to =20= > 4.5. > > Regards, > > Lee Dilkie > > (we implemented the 0-byte udp in our solution, FWIW, although we =20 > choose > 30 second intervals). > > Xavier Marjou wrote: >> To keep this topic alive, I plan to update the following individual >> draft: >> http://tools.ietf.org/wg/behave/draft-marjou-behave-app-rtp-=20 >> keepalive-00.txt >> >> >> I am therefore interested of any feedback, especially on which >> mechanism(s) is best. >> >> Xavier >> >>> On 12/3/06, Dan Wing wrote: >>> Minutes of the last BEHAVE meeting have been posted to: >>> http://www3.ietf.org/proceedings/06nov/minutes/behave.html >>> >>> Application Keepalive for NATs, Xavier Marjou - >>> draft-marjou-behave-app-rtp-keepalive-00 >>> status: separate from ICE, or integrate into Application milestone >>> document? >>> >>> JR =96 this is app design guidelines. How about if we charter to =20 >>> create >>> that document and put this text, along with other text around it in >>> STUN all in one document? >>> Xavier Marjou (speaker, XM) =96 take to list. >>> Chair =96 question of which mechanisms might be best asked in AVT FA = =96 >>> good to ask AVT for sure. But we should discuss here Magnus =96 both >>> groups working on it Chair =96 consensus to fold this into = application >>> document, per JR's proposal. >>> Will figure out what to do on list. >>> FA =96 support. Think it's a good idea. But do we have an editor for >>> that, will it get done? I don't want to send this to dev/null. >>> PM =96 in our BEHAVE app document are we the best place to have that >>> discussion? >>> chair - don't have a clear decision on what to do, will work to =20 >>> figure >>> out where this goes. >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www1.ietf.org/mailman/listinfo/avt > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 16 12:33:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6sBk-0000hH-VB; Tue, 16 Jan 2007 12:33:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6sBk-0000hC-0w for behave@ietf.org; Tue, 16 Jan 2007 12:33:36 -0500 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6sBi-00053Q-O2 for behave@ietf.org; Tue, 16 Jan 2007 12:33:36 -0500 Received: by ug-out-1314.google.com with SMTP id 72so1575530ugd for ; Tue, 16 Jan 2007 09:33:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=ss5X1D9snBhMJazh/3HXXbXQ6Pipf0YaZc+Ealjjy5ze0MImqEEMm12FckNCsg3l+X1YoaIEtkibPIzTLmrDBDuuelg0s15rteFJ+mSo7Jc/pgZSQyizPctwRHekDPTfzj73X+6L++xtysAjQqzsA8qa41g9zT49Qr7N0W0lwzE= Received: by 10.67.117.18 with SMTP id u18mr7890854ugm.1168968813052; Tue, 16 Jan 2007 09:33:33 -0800 (PST) Received: by 10.66.243.7 with HTTP; Tue, 16 Jan 2007 09:33:32 -0800 (PST) Message-ID: <876aa5be0701160933q1cba0f45n2d34a247e168d484@mail.gmail.com> Date: Tue, 16 Jan 2007 17:33:32 +0000 From: Vikas To: behave@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.8 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [BEHAVE] running two application on same port X-BeenThere: behave@ietf.org X-Mailman-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="===============1707778444==" Errors-To: behave-bounces@ietf.org --===============1707778444== Content-Type: multipart/alternative; boundary="----=_Part_120529_23552813.1168968812798" ------=_Part_120529_23552813.1168968812798 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline For STUN client to determine the NAT type we may have to run it on the port over which the needy application is already running. How can we achieve this functionality as now we have to run stun client using the same port and same protocol as our application is using? Regards, Vikas ------=_Part_120529_23552813.1168968812798 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
For STUN client to determine the NAT type we may have to run it on the port over which the needy application is already running.
  How can we achieve this functionality as now we have to run stun client using the same port  and same protocol as our application is using?

Regards,
Vikas ------=_Part_120529_23552813.1168968812798-- --===============1707778444== 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 --===============1707778444==-- From behave-bounces@ietf.org Tue Jan 16 12:35:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6sDB-0002JD-JM; Tue, 16 Jan 2007 12:35:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6sD9-0002GU-Fx for behave@ietf.org; Tue, 16 Jan 2007 12:35:03 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6sD5-0005Uf-Bj for behave@ietf.org; Tue, 16 Jan 2007 12:35:03 -0500 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l0GHYvBq025708; Tue, 16 Jan 2007 10:34:57 -0700 (MST) Received: from srvxchg.cablelabs.com (10.5.0.20) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com); Tue, 16 Jan 2007 10:34:57 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] STUN Relay Date: Tue, 16 Jan 2007 10:34:56 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] STUN Relay Thread-Index: Acc4xPg+TLX8dWzHT5W3goPqi1RpygAALIxQAADG+kAAG37PcAAXGupQ From: "Kevin Johns" To: "Dan Wing" , "Brian Stucker" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Dan, I took a quick look at your draft. The main drawback I see is that it requires the firewall to implement it. Given the vast number of consumer NAT/Firewall devices this seems to have limited applicability. Having not thought through all the details, I was expecting that the UA could send a STUN allocate request and upon getting a response, send a binding request to the IP/Port assigned to the UA to associate the STUN Relay with the UAs address and to open the NAT/Firewall binding. This would then allow the ICE connectivity checks. Alternatively, the UA could wait till it gets the SDP answer with the remote UAs address info then send the connectivity checks which would open the NAT bindings as well. The drawback to this is that the remote UA might start connectivity checks as soon as they send the answer. These would fail (no response) as the local UAs NAT will not have any bindings to allow the connectivity checks through (although this is currently the case and the receipt of the connectivity check cases a trigger check to cut down on the delay of waiting for a timer to fire). Kevin -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com]=20 Sent: Monday, January 15, 2007 11:28 PM To: Kevin Johns; 'Brian Stucker'; behave@ietf.org Subject: RE: [BEHAVE] STUN Relay You need a bit more than STUN management traffic -- the endpoint needs to also be able to send ICE connectivity checks through the TURN server. Otherwise, the endpoint will never know that the path through the TURN server is a viable path. Implementing additional functionality in the TURN server, akin to what I described in draft-wing-session-auth-00, should provide the hooks necessary to block or detect attempts to use a TURN server without first signaling via SIP. -d > -----Original Message----- > From: Kevin Johns [mailto:K.Johns@CableLabs.com] > Sent: Monday, January 15, 2007 9:26 AM > To: Brian Stucker; behave@ietf.org > Subject: RE: [BEHAVE] STUN Relay >=20 > Brian, > =20 > The concern is this, a UA needs to send a STUN message to a STUN Relay > server to get an allocated address to put in its SDP. To allow this,=20 > the policy enforcement point (CMTS, GGSN, AP, etc.) needs to have a=20 > policy which allows the UA to send and receive messages from the STUN=20 > Relay. Given the UA needs to communicate with the STUN Relay prior to=20 > any session establishment, the policy needs to be static and apply to=20 > all UAs. Now you have effectively installed a policy which allows UAs=20 > to communicate freely via this static default policy. > Now, this may not be a big issue if the network installs a dynamic=20 > policy once the session is established and the dynamic policy takes=20 > precedence over the static. However, if the network does not install a > dynamic policy, the UA still has a free path to communicate with=20 > another UA. > =20 > So it would be nice to be able to install a default policy which only=20 > allows for STUN management traffic. Thus, if a UA requests a relay=20 > address allocation the relay would happen on a different address/port=20 > and thus block the UAs ability to relay media without a policy. > =20 > Kevin >=20 > ________________________________ >=20 > From: Brian Stucker [mailto:bstucker@nortel.com] > Sent: Monday, January 15, 2007 9:54 AM > To: Kevin Johns; behave@ietf.org > Subject: RE: [BEHAVE] STUN Relay >=20 >=20 > What sort of policy management separation are you looking for? I am=20 > assuming that you are talking about gating behavior at the relay? > =20 > Regards, > Brian >=20 >=20 > ________________________________ >=20 > From: Kevin Johns [mailto:K.Johns@CableLabs.com]=20 > Sent: Monday, January 15, 2007 10:48 AM > To: behave@ietf.org > Subject: [BEHAVE] STUN Relay > =09 > =09 > =20 > One of the properties of STUN relay is that the STUN relay server=20 > handles both STUN messages and media on the same IP and Port. This=20 > makes policy control a bit difficult as the policy enforcement point=20 > has to be able to identify STUN messages over Media in order to=20 > enforce policy. Has there been any discussion around having a=20 > management only IP/Port and as part of the allocation process allocate > a local transport address (the address and port the UA requesting the=20 > allocation sends and receives from) in addition to the currently=20 > allocated relayed transport address? > =20 > Such and approach would facilitate policy management as STUN Relay=20 > (and STUN for that matter) can be classified separately from the media > traffic allowing for separate policy enforcement. > =20 > Regards, > Kevin >=20 >=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 16 13:19:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6sth-0001vo-Nl; Tue, 16 Jan 2007 13:19:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6stg-0001vh-Kh for behave@ietf.org; Tue, 16 Jan 2007 13:19:00 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6stf-0004jT-0U for behave@ietf.org; Tue, 16 Jan 2007 13:19:00 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 16 Jan 2007 10:18:57 -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 l0GIIvQp019172; Tue, 16 Jan 2007 10:18:57 -0800 Received: from dwingwxp ([10.32.240.196]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0GIIuho004241; Tue, 16 Jan 2007 10:18:57 -0800 (PST) From: "Dan Wing" To: "'Kevin Johns'" , "'Brian Stucker'" , Subject: RE: [BEHAVE] STUN Relay Date: Tue, 16 Jan 2007 10:18:56 -0800 Keywords: direct-to-dwing Message-ID: <030401c7399a$c9addcf0$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acc4xPg+TLX8dWzHT5W3goPqi1RpygAALIxQAADG+kAAG37PcAAXGupQAAG5rIA= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5605; t=1168971537; x=1169835537; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20STUN=20Relay |Sender:=20; bh=SIbGmYwCrgFWfCrxBfinb3apwRPrhUYP3lXCJrQreUw=; b=zY597pdUJAlFtxHRlkM8VRaDAMWwAk2B5Mu4RkNQne7MaJlBfR2g06Ff2CK2yk4vZpovD8oD WJZlmNLCiFsnJbGm34Imwgiw16ErceXk/hP8JsF2j3zPBvIaViFI07m6; Authentication-Results: sj-dkim-8; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba 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 took a quick look at your draft. The main drawback I see is that it > requires the firewall to implement it. I realize my draft talks about firewalls. However, that same function (of deciding when to open/close a pinhole) can be implemented by a TURN server. > Given the vast number of consumer > NAT/Firewall devices this seems to have limited applicability. That isn't what I suggested. > Having not thought through all the details, I was expecting > that the UA > could send a STUN allocate request and upon getting a response, send a > binding request to the IP/Port assigned to the UA to > associate the STUN > Relay with the UAs address and to open the NAT/Firewall binding. This > would then allow the ICE connectivity checks. > > Alternatively, the UA could wait till it gets the SDP answer with the > remote UAs address info For TURN's connectivity checks to work, the offering UA needs to wait for the answer anyway. This is because TURN purposefully does not allow receiving packets from any IP address: the transport address assigned by the TURN server will only allow packets from IP addresses specified by the STUN client in a Set Active Destination request. See the top of http://tools.ietf.org/html/draft-ietf-behave-turn-02#section-9.2 > then send the connectivity checks which would > open the NAT bindings as well. The drawback to this is that the remote > UA might start connectivity checks as soon as they send the answer. That's fine -- they are retransmitted by that remote UA until they're successful. -d > These would fail (no response) as the local UAs NAT will not have any > bindings to allow the connectivity checks through (although this is > currently the case and the receipt of the connectivity check cases a > trigger check to cut down on the delay of waiting for a timer > to fire). > > Kevin > > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Monday, January 15, 2007 11:28 PM > To: Kevin Johns; 'Brian Stucker'; behave@ietf.org > Subject: RE: [BEHAVE] STUN Relay > > You need a bit more than STUN management traffic -- the endpoint needs > to also be able to send ICE connectivity checks through the > TURN server. > Otherwise, the endpoint will never know that the path through the TURN > server is a viable path. > > Implementing additional functionality in the TURN server, > akin to what I > described in draft-wing-session-auth-00, should provide the hooks > necessary to block or detect attempts to use a TURN server > without first > signaling via SIP. > > -d > > > > -----Original Message----- > > From: Kevin Johns [mailto:K.Johns@CableLabs.com] > > Sent: Monday, January 15, 2007 9:26 AM > > To: Brian Stucker; behave@ietf.org > > Subject: RE: [BEHAVE] STUN Relay > > > > Brian, > > > > The concern is this, a UA needs to send a STUN message to a > STUN Relay > > > server to get an allocated address to put in its SDP. To > allow this, > > the policy enforcement point (CMTS, GGSN, AP, etc.) needs to have a > > policy which allows the UA to send and receive messages > from the STUN > > Relay. Given the UA needs to communicate with the STUN > Relay prior to > > any session establishment, the policy needs to be static > and apply to > > all UAs. Now you have effectively installed a policy which > allows UAs > > to communicate freely via this static default policy. > > Now, this may not be a big issue if the network installs a dynamic > > policy once the session is established and the dynamic policy takes > > precedence over the static. However, if the network does > not install a > > > dynamic policy, the UA still has a free path to communicate with > > another UA. > > > > So it would be nice to be able to install a default policy > which only > > allows for STUN management traffic. Thus, if a UA requests a relay > > address allocation the relay would happen on a different > address/port > > and thus block the UAs ability to relay media without a policy. > > > > Kevin > > > > ________________________________ > > > > From: Brian Stucker [mailto:bstucker@nortel.com] > > Sent: Monday, January 15, 2007 9:54 AM > > To: Kevin Johns; behave@ietf.org > > Subject: RE: [BEHAVE] STUN Relay > > > > > > What sort of policy management separation are you looking for? I am > > assuming that you are talking about gating behavior at the relay? > > > > Regards, > > Brian > > > > > > ________________________________ > > > > From: Kevin Johns [mailto:K.Johns@CableLabs.com] > > Sent: Monday, January 15, 2007 10:48 AM > > To: behave@ietf.org > > Subject: [BEHAVE] STUN Relay > > > > > > > > One of the properties of STUN relay is that the STUN relay > server > > handles both STUN messages and media on the same IP and Port. This > > makes policy control a bit difficult as the policy > enforcement point > > has to be able to identify STUN messages over Media in order to > > enforce policy. Has there been any discussion around having a > > management only IP/Port and as part of the allocation > process allocate > > > a local transport address (the address and port the UA > requesting the > > allocation sends and receives from) in addition to the currently > > allocated relayed transport address? > > > > Such and approach would facilitate policy management as STUN > Relay > > (and STUN for that matter) can be classified separately > from the media > > > traffic allowing for separate policy enforcement. > > > > Regards, > > Kevin > > > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 16 13:28:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6t2Y-0008K0-0M; Tue, 16 Jan 2007 13:28:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6t2W-0008Jn-H9 for behave@ietf.org; Tue, 16 Jan 2007 13:28:08 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6t2U-0006Fz-5W for behave@ietf.org; Tue, 16 Jan 2007 13:28:08 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 16 Jan 2007 10:28:05 -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 l0GIS5kN025833; Tue, 16 Jan 2007 10:28:05 -0800 Received: from dwingwxp ([10.32.240.196]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0GIS4nF021631; Tue, 16 Jan 2007 10:28:04 -0800 (PST) From: "Dan Wing" To: "'Vikas'" , Subject: RE: [BEHAVE] running two application on same port Date: Tue, 16 Jan 2007 10:28:04 -0800 Message-ID: <031901c7399c$1011ec80$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <876aa5be0701160933q1cba0f45n2d34a247e168d484@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acc5lJH0EVfYVdiZSjSCVPHfAiw2AwABohUQ DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1663; t=1168972085; x=1169836085; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20running=20two=20application=20on=20same=20 port |Sender:=20; bh=2UNBXGtvkDL8mgOblatDDaCn57wRlrquCktdX2HXKlw=; b=X3bR5kLv0l0r8K6pzTHJWw4cG06WWXLBCSHEH5qJtRFKUOJ0kF5w8buY0wezhHD/g5Cs9Rr/ 7x9aEndGIwpjWCm0zP1zXhdme55cpBUBv7OBuYRSuUwf/ZYBygtmLTYl; Authentication-Results: sj-dkim-7; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 > For STUN client to determine the NAT type we may have to run > it on the port over which the needy application is already running. RFC3489 recommended determining the NAT type. However, in practice, this has been found to not work well because some NATs change their behavior after a several round-trips of UDP messages (becoming full cone, for example), and others change their behavior to "symmetric" if multiple hosts behind the NAT use the same source UDP port. Because of this, it is now considered 'state of the art' to _not_ probe to determine the kind of NAT you're behind. > How can we achieve this functionality as now we have to run > stun client using the same port and same protocol as our > application is using? You have to multiplex STUN with your application protocol. Some application protocols, such as RTP (RFC3550) are easily multiplexed with STUN because the first few bits of a STUN packet and of an RTP packet are different. DTLS happens to demultiplex well, too (see table in http://tools.ietf.org/html/draft-mcgrew-tls-srtp-00#section-3.6.2). If your application protocol doesn't demultiplex as easily, you may find it useful to rely on STUN's MAGIC-COOKIE attribute and FINGERPRINT attributes to demultiplex STUN and your application protocol. You could, of course, prefix all of your application protocol messages with an 8-bit value that doesn't overlap with STUN's first 8 bits, but that shouldn't be necessary considering STUN's MAGIC-COOKIE and FINGERPRINT attributes, which were designed to make it possible to demultiplex STUN with arbitrary application protocols. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 16 14:06:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6tdD-0005Nq-97; Tue, 16 Jan 2007 14:06:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6tdA-0005NO-KT for behave@ietf.org; Tue, 16 Jan 2007 14:06:01 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6tdA-0004K6-6G for behave@ietf.org; Tue, 16 Jan 2007 14:06:00 -0500 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l0GJ5wfE003570; Tue, 16 Jan 2007 12:05:58 -0700 (MST) Received: from srvxchg.cablelabs.com (10.5.0.20) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com); Tue, 16 Jan 2007 12:05:57 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] STUN Relay Date: Tue, 16 Jan 2007 12:05:57 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] STUN Relay Thread-Index: Acc4xPg+TLX8dWzHT5W3goPqi1RpygAALIxQAADG+kAAG37PcAAXGupQAAG5rIAAAcQxkA== From: "Kevin Johns" To: "Dan Wing" , "Brian Stucker" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Dan, Thanks for the clarification on your draft. I will re-read with that in mind. Kevin=20 -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com]=20 Sent: Tuesday, January 16, 2007 11:19 AM To: Kevin Johns; 'Brian Stucker'; behave@ietf.org Subject: RE: [BEHAVE] STUN Relay > I took a quick look at your draft. The main drawback I see is that it=20 > requires the firewall to implement it. I realize my draft talks about firewalls. However, that same function (of deciding when to open/close a pinhole) can be implemented by a TURN server.=20 > Given the vast number of consumer > NAT/Firewall devices this seems to have limited applicability. That isn't what I suggested. > Having not thought through all the details, I was expecting that the=20 > UA could send a STUN allocate request and upon getting a response,=20 > send a binding request to the IP/Port assigned to the UA to associate=20 > the STUN Relay with the UAs address and to open the NAT/Firewall=20 > binding. This would then allow the ICE connectivity checks. >=20 > Alternatively, the UA could wait till it gets the SDP answer with the=20 > remote UAs address info For TURN's connectivity checks to work, the offering UA needs to wait for the answer anyway. This is because TURN purposefully does not allow receiving packets from any IP address: the transport address assigned by the TURN server will only allow packets from IP addresses specified by the STUN client in a Set Active Destination request. See the top of http://tools.ietf.org/html/draft-ietf-behave-turn-02#section-9.2 > then send the connectivity checks which would open the NAT bindings as > well. The drawback to this is that the remote UA might start=20 > connectivity checks as soon as they send the answer. That's fine -- they are retransmitted by that remote UA until they're successful. -d > These would fail (no response) as the local UAs NAT will not have any=20 > bindings to allow the connectivity checks through (although this is=20 > currently the case and the receipt of the connectivity check cases a=20 > trigger check to cut down on the delay of waiting for a timer to=20 > fire). >=20 > Kevin >=20 > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Monday, January 15, 2007 11:28 PM > To: Kevin Johns; 'Brian Stucker'; behave@ietf.org > Subject: RE: [BEHAVE] STUN Relay >=20 > You need a bit more than STUN management traffic -- the endpoint needs > to also be able to send ICE connectivity checks through the TURN=20 > server. > Otherwise, the endpoint will never know that the path through the TURN > server is a viable path. >=20 > Implementing additional functionality in the TURN server, akin to what > I described in draft-wing-session-auth-00, should provide the hooks=20 > necessary to block or detect attempts to use a TURN server without=20 > first signaling via SIP. >=20 > -d >=20 >=20 > > -----Original Message----- > > From: Kevin Johns [mailto:K.Johns@CableLabs.com] > > Sent: Monday, January 15, 2007 9:26 AM > > To: Brian Stucker; behave@ietf.org > > Subject: RE: [BEHAVE] STUN Relay > >=20 > > Brian, > > =20 > > The concern is this, a UA needs to send a STUN message to a > STUN Relay >=20 > > server to get an allocated address to put in its SDP. To > allow this, > > the policy enforcement point (CMTS, GGSN, AP, etc.) needs to have a=20 > > policy which allows the UA to send and receive messages > from the STUN > > Relay. Given the UA needs to communicate with the STUN > Relay prior to > > any session establishment, the policy needs to be static > and apply to > > all UAs. Now you have effectively installed a policy which > allows UAs > > to communicate freely via this static default policy. > > Now, this may not be a big issue if the network installs a dynamic=20 > > policy once the session is established and the dynamic policy takes=20 > > precedence over the static. However, if the network does > not install a >=20 > > dynamic policy, the UA still has a free path to communicate with=20 > > another UA. > > =20 > > So it would be nice to be able to install a default policy > which only > > allows for STUN management traffic. Thus, if a UA requests a relay=20 > > address allocation the relay would happen on a different > address/port > > and thus block the UAs ability to relay media without a policy. > > =20 > > Kevin > >=20 > > ________________________________ > >=20 > > From: Brian Stucker [mailto:bstucker@nortel.com] > > Sent: Monday, January 15, 2007 9:54 AM > > To: Kevin Johns; behave@ietf.org > > Subject: RE: [BEHAVE] STUN Relay > >=20 > >=20 > > What sort of policy management separation are you looking for? I am=20 > > assuming that you are talking about gating behavior at the relay? > > =20 > > Regards, > > Brian > >=20 > >=20 > > ________________________________ > >=20 > > From: Kevin Johns [mailto:K.Johns@CableLabs.com]=20 > > Sent: Monday, January 15, 2007 10:48 AM > > To: behave@ietf.org > > Subject: [BEHAVE] STUN Relay > > =09 > > =09 > > =20 > > One of the properties of STUN relay is that the STUN relay > server > > handles both STUN messages and media on the same IP and Port. This=20 > > makes policy control a bit difficult as the policy > enforcement point > > has to be able to identify STUN messages over Media in order to=20 > > enforce policy. Has there been any discussion around having a=20 > > management only IP/Port and as part of the allocation > process allocate >=20 > > a local transport address (the address and port the UA > requesting the > > allocation sends and receives from) in addition to the currently=20 > > allocated relayed transport address? > > =20 > > Such and approach would facilitate policy management as STUN > Relay > > (and STUN for that matter) can be classified separately > from the media >=20 > > traffic allowing for separate policy enforcement. > > =20 > > Regards, > > Kevin > >=20 > >=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 16 16:09:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6vYa-0002Fx-MI; Tue, 16 Jan 2007 16:09:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6vYZ-0002Fb-GZ for behave@ietf.org; Tue, 16 Jan 2007 16:09:23 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6vYX-0007Ct-UY for behave@ietf.org; Tue, 16 Jan 2007 16:09:23 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 16 Jan 2007 13:09:21 -0800 X-IronPort-AV: i="4.13,197,1167638400"; d="scan'208"; a="102222350:sNHT53801505" 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 l0GL9LfB013776; Tue, 16 Jan 2007 13:09:21 -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 l0GL95E6029868; Tue, 16 Jan 2007 13:09:16 -0800 (PST) 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, 16 Jan 2007 13:09:06 -0800 Received: from [10.32.241.158] ([10.32.241.158]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 13:09:05 -0800 Message-ID: <45AD3EF0.2090708@cisco.com> Date: Tue, 16 Jan 2007 16:09:04 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Johns Subject: Re: [BEHAVE] STUN Relay References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2007 21:09:05.0981 (UTC) FILETIME=[8E6CDED0:01C739B2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6538; t=1168981761; x=1169845761; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20STUN=20Relay |Sender:=20; bh=u1AXit+EEVQFCnXSEQfS7he1WIFs47+aFcbeg4yjMBw=; b=Bj3a0h/Vrb4Sd2T/1X5dV8tPLqEP2Kh5hskyeY0iC6ka/pWrv02KSu36JD5vMPX1mypgrhwP aYVZITTUmUv8EVw/ZSXXAjBD+XR1724BX+kcgoHkOJ5kjn2S6udZwkC5; 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: 848ed35f2a4fc0638fa89629cb640f48 Cc: behave@ietf.org, Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I understand why you are asking for this capability, but it is a tremendous change to the spec at this late hour, and I think there are other ways to achieve your goal. I'll also point out that the approach you describe is hard to make work securely. It introduces an attack whereby an observer can watch the allocate message, learn the allocated port and associated cookie/token used to correlate the requests, and inject a faked request from their own port. This attack would require something akin to a shared secret request over TLS for each call. It also adds a lot of machinery to the spec. We considered an approach like this waaaayyyy back in the early days of TURN. The easiest thing, IMHO, is for the firewall to just discard anything which is not a STUN message until authorization, and require the UA to set an active destination within a few seconds of the allocate request (the latter would be enforced on the stun relay). The authorization that gets installed then would be to allow non-stun messages. This requires the firewall function to peer a bit deeper than ports, but stun was designed to be easily recognizable by intermediate boxes. Thanks, Jonathan R. Kevin Johns wrote: > Dan, > > I took a quick look at your draft. The main drawback I see is that it > requires the firewall to implement it. Given the vast number of consumer > NAT/Firewall devices this seems to have limited applicability. > > Having not thought through all the details, I was expecting that the UA > could send a STUN allocate request and upon getting a response, send a > binding request to the IP/Port assigned to the UA to associate the STUN > Relay with the UAs address and to open the NAT/Firewall binding. This > would then allow the ICE connectivity checks. > > Alternatively, the UA could wait till it gets the SDP answer with the > remote UAs address info then send the connectivity checks which would > open the NAT bindings as well. The drawback to this is that the remote > UA might start connectivity checks as soon as they send the answer. > These would fail (no response) as the local UAs NAT will not have any > bindings to allow the connectivity checks through (although this is > currently the case and the receipt of the connectivity check cases a > trigger check to cut down on the delay of waiting for a timer to fire). > > Kevin > > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Monday, January 15, 2007 11:28 PM > To: Kevin Johns; 'Brian Stucker'; behave@ietf.org > Subject: RE: [BEHAVE] STUN Relay > > You need a bit more than STUN management traffic -- the endpoint needs > to also be able to send ICE connectivity checks through the TURN server. > Otherwise, the endpoint will never know that the path through the TURN > server is a viable path. > > Implementing additional functionality in the TURN server, akin to what I > described in draft-wing-session-auth-00, should provide the hooks > necessary to block or detect attempts to use a TURN server without first > signaling via SIP. > > -d > > > >>-----Original Message----- >>From: Kevin Johns [mailto:K.Johns@CableLabs.com] >>Sent: Monday, January 15, 2007 9:26 AM >>To: Brian Stucker; behave@ietf.org >>Subject: RE: [BEHAVE] STUN Relay >> >>Brian, >> >>The concern is this, a UA needs to send a STUN message to a STUN Relay > > >>server to get an allocated address to put in its SDP. To allow this, >>the policy enforcement point (CMTS, GGSN, AP, etc.) needs to have a >>policy which allows the UA to send and receive messages from the STUN >>Relay. Given the UA needs to communicate with the STUN Relay prior to >>any session establishment, the policy needs to be static and apply to >>all UAs. Now you have effectively installed a policy which allows UAs >>to communicate freely via this static default policy. >>Now, this may not be a big issue if the network installs a dynamic >>policy once the session is established and the dynamic policy takes >>precedence over the static. However, if the network does not install a > > >>dynamic policy, the UA still has a free path to communicate with >>another UA. >> >>So it would be nice to be able to install a default policy which only >>allows for STUN management traffic. Thus, if a UA requests a relay >>address allocation the relay would happen on a different address/port >>and thus block the UAs ability to relay media without a policy. >> >>Kevin >> >>________________________________ >> >>From: Brian Stucker [mailto:bstucker@nortel.com] >>Sent: Monday, January 15, 2007 9:54 AM >>To: Kevin Johns; behave@ietf.org >>Subject: RE: [BEHAVE] STUN Relay >> >> >>What sort of policy management separation are you looking for? I am >>assuming that you are talking about gating behavior at the relay? >> >>Regards, >>Brian >> >> >>________________________________ >> >> From: Kevin Johns [mailto:K.Johns@CableLabs.com] >> Sent: Monday, January 15, 2007 10:48 AM >> To: behave@ietf.org >> Subject: [BEHAVE] STUN Relay >> >> >> >> One of the properties of STUN relay is that the STUN relay > > server > >>handles both STUN messages and media on the same IP and Port. This >>makes policy control a bit difficult as the policy enforcement point >>has to be able to identify STUN messages over Media in order to >>enforce policy. Has there been any discussion around having a >>management only IP/Port and as part of the allocation process allocate > > >>a local transport address (the address and port the UA requesting the >>allocation sends and receives from) in addition to the currently >>allocated relayed transport address? >> >> Such and approach would facilitate policy management as STUN > > Relay > >>(and STUN for that matter) can be classified separately from the media > > >>traffic allowing for separate policy enforcement. >> >> Regards, >> Kevin >> >> > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 16 17:43:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6x1K-0005dG-8q; Tue, 16 Jan 2007 17:43:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6x1J-0005dA-VM for behave@ietf.org; Tue, 16 Jan 2007 17:43:09 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6x1F-0007fu-Ba for behave@ietf.org; Tue, 16 Jan 2007 17:43:09 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l0GMgt910394; Tue, 16 Jan 2007 17:42:55 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] STUN Relay Date: Tue, 16 Jan 2007 16:42:54 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371124811C6@zrc2hxm2.corp.nortel.com> In-Reply-To: <45AD3EF0.2090708@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] STUN Relay Thread-index: Acc5ssJz54ec5e2IQ1eFaCodnscETgACZbpA From: "Brian Stucker" To: "Jonathan Rosenberg" , "Kevin Johns" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 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 This approach has a side effect... If you rely on the client sending a SAD request to the TURN server 'within a few seconds of the allocate request' then you're very likely going to clip the first few seconds of any early media going back to the client using the existing mechanism. If a gate is set by a component in the SIP signaling path, the clipping can still occur, but should be the minimum interval possible given that a gate exists in the network at all. I'm not suggesting changes to TURN in regards to handling clipping other than to point out that we're essentially requiring the originator to send packets (STUN or otherwise) on the media path in order to get any media back from far ends, even if that far end is a trusted network entity. Should we perhaps state that the relay client should be prepared to receive media from the relay server in the absence of any permissions that the client may have created on the allocation via SAD/SI messages? That would allow local network policy to stream early media to the relay client without waiting for the client to interact with the relay server outside of requesting the allocation (presumably as part of a candidate address gathering exercise). Regards, Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Tuesday, January 16, 2007 3:09 PM > To: Kevin Johns > Cc: Dan Wing; Stucker, Brian (RICH1:AR00); behave@ietf.org > Subject: Re: [BEHAVE] STUN Relay >=20 > I understand why you are asking for this capability, but it=20 > is a tremendous change to the spec at this late hour, and I=20 > think there are other ways to achieve your goal. >=20 > I'll also point out that the approach you describe is hard to=20 > make work securely. It introduces an attack whereby an=20 > observer can watch the allocate message, learn the allocated=20 > port and associated cookie/token used to correlate the=20 > requests, and inject a faked request from their own port.=20 > This attack would require something akin to a shared secret=20 > request over TLS for each call. It also adds a lot of=20 > machinery to the spec. We considered an approach like this=20 > waaaayyyy back in the early days of TURN. >=20 > The easiest thing, IMHO, is for the firewall to just discard=20 > anything which is not a STUN message until authorization, and=20 > require the UA to set an active destination within a few=20 > seconds of the allocate request (the latter would be enforced=20 > on the stun relay). The authorization that gets installed=20 > then would be to allow non-stun messages. This requires the=20 > firewall function to peer a bit deeper than ports, but stun=20 > was designed to be easily recognizable by intermediate boxes. >=20 > Thanks, > Jonathan R. >=20 >=20 > Kevin Johns wrote: >=20 > > Dan, > >=20 > > I took a quick look at your draft. The main drawback I see=20 > is that it=20 > > requires the firewall to implement it. Given the vast number of=20 > > consumer NAT/Firewall devices this seems to have limited=20 > applicability. > >=20 > > Having not thought through all the details, I was expecting=20 > that the=20 > > UA could send a STUN allocate request and upon getting a response,=20 > > send a binding request to the IP/Port assigned to the UA to=20 > associate=20 > > the STUN Relay with the UAs address and to open the NAT/Firewall=20 > > binding. This would then allow the ICE connectivity checks. > >=20 > > Alternatively, the UA could wait till it gets the SDP=20 > answer with the=20 > > remote UAs address info then send the connectivity checks=20 > which would=20 > > open the NAT bindings as well. The drawback to this is that=20 > the remote=20 > > UA might start connectivity checks as soon as they send the answer. > > These would fail (no response) as the local UAs NAT will=20 > not have any=20 > > bindings to allow the connectivity checks through (although this is=20 > > currently the case and the receipt of the connectivity=20 > check cases a=20 > > trigger check to cut down on the delay of waiting for a=20 > timer to fire). > >=20 > > Kevin > >=20 > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: Monday, January 15, 2007 11:28 PM > > To: Kevin Johns; 'Brian Stucker'; behave@ietf.org > > Subject: RE: [BEHAVE] STUN Relay > >=20 > > You need a bit more than STUN management traffic -- the=20 > endpoint needs=20 > > to also be able to send ICE connectivity checks through the=20 > TURN server. > > Otherwise, the endpoint will never know that the path=20 > through the TURN=20 > > server is a viable path. > >=20 > > Implementing additional functionality in the TURN server,=20 > akin to what=20 > > I described in draft-wing-session-auth-00, should provide the hooks=20 > > necessary to block or detect attempts to use a TURN server without=20 > > first signaling via SIP. > >=20 > > -d > >=20 > >=20 > >=20 > >>-----Original Message----- > >>From: Kevin Johns [mailto:K.Johns@CableLabs.com] > >>Sent: Monday, January 15, 2007 9:26 AM > >>To: Brian Stucker; behave@ietf.org > >>Subject: RE: [BEHAVE] STUN Relay > >> > >>Brian, > >>=20 > >>The concern is this, a UA needs to send a STUN message to a=20 > STUN Relay > >=20 > >=20 > >>server to get an allocated address to put in its SDP. To=20 > allow this,=20 > >>the policy enforcement point (CMTS, GGSN, AP, etc.) needs to have a=20 > >>policy which allows the UA to send and receive messages=20 > from the STUN=20 > >>Relay. Given the UA needs to communicate with the STUN=20 > Relay prior to=20 > >>any session establishment, the policy needs to be static=20 > and apply to=20 > >>all UAs. Now you have effectively installed a policy which=20 > allows UAs=20 > >>to communicate freely via this static default policy. > >>Now, this may not be a big issue if the network installs a dynamic=20 > >>policy once the session is established and the dynamic policy takes=20 > >>precedence over the static. However, if the network does=20 > not install a > >=20 > >=20 > >>dynamic policy, the UA still has a free path to communicate with=20 > >>another UA. > >>=20 > >>So it would be nice to be able to install a default policy=20 > which only=20 > >>allows for STUN management traffic. Thus, if a UA requests a relay=20 > >>address allocation the relay would happen on a different=20 > address/port=20 > >>and thus block the UAs ability to relay media without a policy. > >>=20 > >>Kevin > >> > >>________________________________ > >> > >>From: Brian Stucker [mailto:bstucker@nortel.com] > >>Sent: Monday, January 15, 2007 9:54 AM > >>To: Kevin Johns; behave@ietf.org > >>Subject: RE: [BEHAVE] STUN Relay > >> > >> > >>What sort of policy management separation are you looking for? I am=20 > >>assuming that you are talking about gating behavior at the relay? > >>=20 > >>Regards, > >>Brian > >> > >> > >>________________________________ > >> > >> From: Kevin Johns [mailto:K.Johns@CableLabs.com]=20 > >> Sent: Monday, January 15, 2007 10:48 AM > >> To: behave@ietf.org > >> Subject: [BEHAVE] STUN Relay > >>=09 > >>=09 > >> =20 > >> One of the properties of STUN relay is that the STUN relay > >=20 > > server > >=20 > >>handles both STUN messages and media on the same IP and Port. This=20 > >>makes policy control a bit difficult as the policy=20 > enforcement point=20 > >>has to be able to identify STUN messages over Media in order to=20 > >>enforce policy. Has there been any discussion around having a=20 > >>management only IP/Port and as part of the allocation=20 > process allocate > >=20 > >=20 > >>a local transport address (the address and port the UA=20 > requesting the=20 > >>allocation sends and receives from) in addition to the currently=20 > >>allocated relayed transport address? > >> =20 > >> Such and approach would facilitate policy management as STUN > >=20 > > Relay > >=20 > >>(and STUN for that matter) can be classified separately=20 > from the media > >=20 > >=20 > >>traffic allowing for separate policy enforcement. > >> =20 > >> Regards, > >> Kevin > >> > >> > >=20 > >=20 > >=20 > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www1.ietf.org/mailman/listinfo/behave > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 16 18:00:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6xHs-0003IZ-Nl; Tue, 16 Jan 2007 18:00:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6xHr-0003IT-BC for behave@ietf.org; Tue, 16 Jan 2007 18:00:15 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6xHo-0002cJ-LL for behave@ietf.org; Tue, 16 Jan 2007 18:00:15 -0500 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l0GN0ATa004443; Tue, 16 Jan 2007 16:00:10 -0700 (MST) Received: from srvxchg.cablelabs.com (10.5.0.20) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com); Tue, 16 Jan 2007 16:00:09 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] STUN Relay Date: Tue, 16 Jan 2007 16:00:08 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] STUN Relay Thread-Index: Acc5sphApR8oL+N0QkiquQ5wQPF3bgADmD2Q From: "Kevin Johns" To: "Jonathan Rosenberg" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e 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 Thanks for the history. If this was considered in the past and rejected I am ok with that, was just wondering if it was considered and if so why it was not done. Your suggested approach seems to be along the same lines as Dans. I'll plan on taking a more detailed review of his draft to better understand the architecture and potential implications of such an approach. Kevin -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 Sent: Tuesday, January 16, 2007 2:09 PM To: Kevin Johns Cc: Dan Wing; Brian Stucker; behave@ietf.org Subject: Re: [BEHAVE] STUN Relay I understand why you are asking for this capability, but it is a tremendous change to the spec at this late hour, and I think there are other ways to achieve your goal. I'll also point out that the approach you describe is hard to make work securely. It introduces an attack whereby an observer can watch the allocate message, learn the allocated port and associated cookie/token used to correlate the requests, and inject a faked request from their own port. This attack would require something akin to a shared secret request over TLS for each call. It also adds a lot of machinery to the spec. We considered an approach like this waaaayyyy back in the early days of TURN. The easiest thing, IMHO, is for the firewall to just discard anything which is not a STUN message until authorization, and require the UA to set an active destination within a few seconds of the allocate request (the latter would be enforced on the stun relay). The authorization that gets installed then would be to allow non-stun messages. This requires the firewall function to peer a bit deeper than ports, but stun was designed to be easily recognizable by intermediate boxes. Thanks, Jonathan R. Kevin Johns wrote: > Dan, >=20 > I took a quick look at your draft. The main drawback I see is that it=20 > requires the firewall to implement it. Given the vast number of=20 > consumer NAT/Firewall devices this seems to have limited applicability. >=20 > Having not thought through all the details, I was expecting that the=20 > UA could send a STUN allocate request and upon getting a response,=20 > send a binding request to the IP/Port assigned to the UA to associate=20 > the STUN Relay with the UAs address and to open the NAT/Firewall=20 > binding. This would then allow the ICE connectivity checks. >=20 > Alternatively, the UA could wait till it gets the SDP answer with the=20 > remote UAs address info then send the connectivity checks which would=20 > open the NAT bindings as well. The drawback to this is that the remote > UA might start connectivity checks as soon as they send the answer. > These would fail (no response) as the local UAs NAT will not have any=20 > bindings to allow the connectivity checks through (although this is=20 > currently the case and the receipt of the connectivity check cases a=20 > trigger check to cut down on the delay of waiting for a timer to fire). >=20 > Kevin >=20 > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Monday, January 15, 2007 11:28 PM > To: Kevin Johns; 'Brian Stucker'; behave@ietf.org > Subject: RE: [BEHAVE] STUN Relay >=20 > You need a bit more than STUN management traffic -- the endpoint needs > to also be able to send ICE connectivity checks through the TURN server. > Otherwise, the endpoint will never know that the path through the TURN > server is a viable path. >=20 > Implementing additional functionality in the TURN server, akin to what > I described in draft-wing-session-auth-00, should provide the hooks=20 > necessary to block or detect attempts to use a TURN server without=20 > first signaling via SIP. >=20 > -d >=20 >=20 >=20 >>-----Original Message----- >>From: Kevin Johns [mailto:K.Johns@CableLabs.com] >>Sent: Monday, January 15, 2007 9:26 AM >>To: Brian Stucker; behave@ietf.org >>Subject: RE: [BEHAVE] STUN Relay >> >>Brian, >>=20 >>The concern is this, a UA needs to send a STUN message to a STUN Relay >=20 >=20 >>server to get an allocated address to put in its SDP. To allow this,=20 >>the policy enforcement point (CMTS, GGSN, AP, etc.) needs to have a=20 >>policy which allows the UA to send and receive messages from the STUN=20 >>Relay. Given the UA needs to communicate with the STUN Relay prior to=20 >>any session establishment, the policy needs to be static and apply to=20 >>all UAs. Now you have effectively installed a policy which allows UAs=20 >>to communicate freely via this static default policy. >>Now, this may not be a big issue if the network installs a dynamic=20 >>policy once the session is established and the dynamic policy takes=20 >>precedence over the static. However, if the network does not install a >=20 >=20 >>dynamic policy, the UA still has a free path to communicate with=20 >>another UA. >>=20 >>So it would be nice to be able to install a default policy which only=20 >>allows for STUN management traffic. Thus, if a UA requests a relay=20 >>address allocation the relay would happen on a different address/port=20 >>and thus block the UAs ability to relay media without a policy. >>=20 >>Kevin >> >>________________________________ >> >>From: Brian Stucker [mailto:bstucker@nortel.com] >>Sent: Monday, January 15, 2007 9:54 AM >>To: Kevin Johns; behave@ietf.org >>Subject: RE: [BEHAVE] STUN Relay >> >> >>What sort of policy management separation are you looking for? I am=20 >>assuming that you are talking about gating behavior at the relay? >>=20 >>Regards, >>Brian >> >> >>________________________________ >> >> From: Kevin Johns [mailto:K.Johns@CableLabs.com]=20 >> Sent: Monday, January 15, 2007 10:48 AM >> To: behave@ietf.org >> Subject: [BEHAVE] STUN Relay >>=09 >>=09 >> =20 >> One of the properties of STUN relay is that the STUN relay >=20 > server >=20 >>handles both STUN messages and media on the same IP and Port. This=20 >>makes policy control a bit difficult as the policy enforcement point=20 >>has to be able to identify STUN messages over Media in order to=20 >>enforce policy. Has there been any discussion around having a=20 >>management only IP/Port and as part of the allocation process allocate >=20 >=20 >>a local transport address (the address and port the UA requesting the=20 >>allocation sends and receives from) in addition to the currently=20 >>allocated relayed transport address? >> =20 >> Such and approach would facilitate policy management as STUN >=20 > Relay >=20 >>(and STUN for that matter) can be classified separately from the media >=20 >=20 >>traffic allowing for separate policy enforcement. >> =20 >> Regards, >> Kevin >> >> >=20 >=20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 16 18:10:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6xRi-00080I-Fb; Tue, 16 Jan 2007 18:10:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6xRg-0007yY-IS for behave@ietf.org; Tue, 16 Jan 2007 18:10:24 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6xRf-0003xp-Tq for behave@ietf.org; Tue, 16 Jan 2007 18:10:24 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 16 Jan 2007 15:10:23 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l0GNAN0r002604; Tue, 16 Jan 2007 15:10:23 -0800 Received: from dwingwxp ([10.32.240.196]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0GNAHnF019642; Tue, 16 Jan 2007 15:10:18 -0800 (PST) From: "Dan Wing" To: "'Brian Stucker'" , "'Jonathan Rosenberg'" , "'Kevin Johns'" Subject: RE: [BEHAVE] STUN Relay Date: Tue, 16 Jan 2007 15:10:17 -0800 Keywords: direct-to-dwing Message-ID: <049201c739c3$7fb2aad0$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371124811C6@zrc2hxm2.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acc5ssJz54ec5e2IQ1eFaCodnscETgACZbpAAAG/lVA= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9640; t=1168989023; x=1169853023; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20STUN=20Relay |Sender:=20; bh=ImN9tDn/C+5NLtWrTmUXlITZK1Itb/Wk258hKW8BOGs=; b=eHRb5G2+l/4p/vBH6ZCn+Sy72nBj9SsV4ELoy6k7EZnqJNR9RwedmlLxrbEsxSaMv9ZgBDH6 SZMzrdtRqukM1nNnRiXsBAaqw9UMLEHFg3kBothBRqEsY7+6RFfRyXqZ; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 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 (Assuming I understood your proposal correctly:) One of TURN's design goals was to _not_ allow TURN to be used to create a server on the 'far' side of a firewall. If we allow a TURN server to relay IP packets from arbitrary hosts on the Internet to the STUN client, it seems to break that design goal. -d > -----Original Message----- > From: Brian Stucker [mailto:bstucker@nortel.com] > Sent: Tuesday, January 16, 2007 2:43 PM > To: Jonathan Rosenberg; Kevin Johns > Cc: Dan Wing; behave@ietf.org > Subject: RE: [BEHAVE] STUN Relay > > This approach has a side effect... > > If you rely on the client sending a SAD request to the TURN server > 'within a few seconds of the allocate request' then you're very likely > going to clip the first few seconds of any early media going > back to the > client using the existing mechanism. > > If a gate is set by a component in the SIP signaling path, > the clipping > can still occur, but should be the minimum interval possible > given that > a gate exists in the network at all. I'm not suggesting > changes to TURN > in regards to handling clipping other than to point out that we're > essentially requiring the originator to send packets (STUN or > otherwise) > on the media path in order to get any media back from far > ends, even if > that far end is a trusted network entity. > > Should we perhaps state that the relay client should be prepared to > receive media from the relay server in the absence of any permissions > that the client may have created on the allocation via SAD/SI > messages? > That would allow local network policy to stream early media > to the relay > client without waiting for the client to interact with the > relay server > outside of requesting the allocation (presumably as part of a > candidate > address gathering exercise). > > Regards, > Brian > > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > Sent: Tuesday, January 16, 2007 3:09 PM > > To: Kevin Johns > > Cc: Dan Wing; Stucker, Brian (RICH1:AR00); behave@ietf.org > > Subject: Re: [BEHAVE] STUN Relay > > > > I understand why you are asking for this capability, but it > > is a tremendous change to the spec at this late hour, and I > > think there are other ways to achieve your goal. > > > > I'll also point out that the approach you describe is hard to > > make work securely. It introduces an attack whereby an > > observer can watch the allocate message, learn the allocated > > port and associated cookie/token used to correlate the > > requests, and inject a faked request from their own port. > > This attack would require something akin to a shared secret > > request over TLS for each call. It also adds a lot of > > machinery to the spec. We considered an approach like this > > waaaayyyy back in the early days of TURN. > > > > The easiest thing, IMHO, is for the firewall to just discard > > anything which is not a STUN message until authorization, and > > require the UA to set an active destination within a few > > seconds of the allocate request (the latter would be enforced > > on the stun relay). The authorization that gets installed > > then would be to allow non-stun messages. This requires the > > firewall function to peer a bit deeper than ports, but stun > > was designed to be easily recognizable by intermediate boxes. > > > > Thanks, > > Jonathan R. > > > > > > Kevin Johns wrote: > > > > > Dan, > > > > > > I took a quick look at your draft. The main drawback I see > > is that it > > > requires the firewall to implement it. Given the vast number of > > > consumer NAT/Firewall devices this seems to have limited > > applicability. > > > > > > Having not thought through all the details, I was expecting > > that the > > > UA could send a STUN allocate request and upon getting a > response, > > > send a binding request to the IP/Port assigned to the UA to > > associate > > > the STUN Relay with the UAs address and to open the NAT/Firewall > > > binding. This would then allow the ICE connectivity checks. > > > > > > Alternatively, the UA could wait till it gets the SDP > > answer with the > > > remote UAs address info then send the connectivity checks > > which would > > > open the NAT bindings as well. The drawback to this is that > > the remote > > > UA might start connectivity checks as soon as they send > the answer. > > > These would fail (no response) as the local UAs NAT will > > not have any > > > bindings to allow the connectivity checks through > (although this is > > > currently the case and the receipt of the connectivity > > check cases a > > > trigger check to cut down on the delay of waiting for a > > timer to fire). > > > > > > Kevin > > > > > > -----Original Message----- > > > From: Dan Wing [mailto:dwing@cisco.com] > > > Sent: Monday, January 15, 2007 11:28 PM > > > To: Kevin Johns; 'Brian Stucker'; behave@ietf.org > > > Subject: RE: [BEHAVE] STUN Relay > > > > > > You need a bit more than STUN management traffic -- the > > endpoint needs > > > to also be able to send ICE connectivity checks through the > > TURN server. > > > Otherwise, the endpoint will never know that the path > > through the TURN > > > server is a viable path. > > > > > > Implementing additional functionality in the TURN server, > > akin to what > > > I described in draft-wing-session-auth-00, should provide > the hooks > > > necessary to block or detect attempts to use a TURN > server without > > > first signaling via SIP. > > > > > > -d > > > > > > > > > > > >>-----Original Message----- > > >>From: Kevin Johns [mailto:K.Johns@CableLabs.com] > > >>Sent: Monday, January 15, 2007 9:26 AM > > >>To: Brian Stucker; behave@ietf.org > > >>Subject: RE: [BEHAVE] STUN Relay > > >> > > >>Brian, > > >> > > >>The concern is this, a UA needs to send a STUN message to a > > STUN Relay > > > > > > > > >>server to get an allocated address to put in its SDP. To > > allow this, > > >>the policy enforcement point (CMTS, GGSN, AP, etc.) needs > to have a > > >>policy which allows the UA to send and receive messages > > from the STUN > > >>Relay. Given the UA needs to communicate with the STUN > > Relay prior to > > >>any session establishment, the policy needs to be static > > and apply to > > >>all UAs. Now you have effectively installed a policy which > > allows UAs > > >>to communicate freely via this static default policy. > > >>Now, this may not be a big issue if the network installs > a dynamic > > >>policy once the session is established and the dynamic > policy takes > > >>precedence over the static. However, if the network does > > not install a > > > > > > > > >>dynamic policy, the UA still has a free path to communicate with > > >>another UA. > > >> > > >>So it would be nice to be able to install a default policy > > which only > > >>allows for STUN management traffic. Thus, if a UA > requests a relay > > >>address allocation the relay would happen on a different > > address/port > > >>and thus block the UAs ability to relay media without a policy. > > >> > > >>Kevin > > >> > > >>________________________________ > > >> > > >>From: Brian Stucker [mailto:bstucker@nortel.com] > > >>Sent: Monday, January 15, 2007 9:54 AM > > >>To: Kevin Johns; behave@ietf.org > > >>Subject: RE: [BEHAVE] STUN Relay > > >> > > >> > > >>What sort of policy management separation are you looking > for? I am > > >>assuming that you are talking about gating behavior at the relay? > > >> > > >>Regards, > > >>Brian > > >> > > >> > > >>________________________________ > > >> > > >> From: Kevin Johns [mailto:K.Johns@CableLabs.com] > > >> Sent: Monday, January 15, 2007 10:48 AM > > >> To: behave@ietf.org > > >> Subject: [BEHAVE] STUN Relay > > >> > > >> > > >> > > >> One of the properties of STUN relay is that the STUN relay > > > > > > server > > > > > >>handles both STUN messages and media on the same IP and > Port. This > > >>makes policy control a bit difficult as the policy > > enforcement point > > >>has to be able to identify STUN messages over Media in order to > > >>enforce policy. Has there been any discussion around having a > > >>management only IP/Port and as part of the allocation > > process allocate > > > > > > > > >>a local transport address (the address and port the UA > > requesting the > > >>allocation sends and receives from) in addition to the currently > > >>allocated relayed transport address? > > >> > > >> Such and approach would facilitate policy management as STUN > > > > > > Relay > > > > > >>(and STUN for that matter) can be classified separately > > from the media > > > > > > > > >>traffic allowing for separate policy enforcement. > > >> > > >> Regards, > > >> Kevin > > >> > > >> > > > > > > > > > > > > _______________________________________________ > > > Behave mailing list > > > Behave@ietf.org > > > https://www1.ietf.org/mailman/listinfo/behave > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 17 01:45:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H74XA-0004xW-F7; Wed, 17 Jan 2007 01:44:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6usn-0008FW-O4; Tue, 16 Jan 2007 15:26:13 -0500 Received: from mail5.audiocodes.com ([212.25.125.21] helo=imss.audiocodes.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6usl-0000PA-Nv; Tue, 16 Jan 2007 15:26:13 -0500 Received: from aclmsg.corp.audiocodes.com ([10.1.0.8]) by imss with InterScan Messaging Security Suite; Tue, 16 Jan 2007 22:27:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 16 Jan 2007 22:25:22 +0200 Message-ID: <79B4F738DDD4EF4F85A4641A0FE5EFD6017A82BD@aclmsg.corp.audiocodes.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Update of rtp-keepalive draft Thread-Index: Acc5j7qyGGZwgvlyTjqYKn2SvzTP7wAGkGGc References: <458913680701150202l620dca50o1afcf0e57680adcf@mail.gmail.com><45ABD028.4090804@mitel.com> <509E65FC-40C6-474A-840D-EF3D105AAE92@csperkins.org> From: "Yuval Nissan" To: "Colin Perkins" , "Lee Dilkie" X-Spam-Score: 0.1 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 X-Mailman-Approved-At: Wed, 17 Jan 2007 01:44:31 -0500 Cc: Xavier Marjou , behave@ietf.org, avt@ietf.org Subject: [BEHAVE] RE: [AVT] Update of rtp-keepalive draft X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1464739005==" Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. --===============1464739005== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C739AC.727E2550" This is a multi-part message in MIME format. ------_=_NextPart_001_01C739AC.727E2550 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable The issue of keepalive is also related to the RTP endpoint - If the = remote side stops the voice connection because of some problem during = silence, there is no certain way to discover it. =20 So I think the recommended alternative should solve both issues (4.5 = does the job) =20 Regards, Yuval ________________________________ =EE=E0=FA: Colin Perkins [mailto:csp@csperkins.org] =F0=F9=EC=E7: =E2 16/01/2007 18:58 =E0=EC: Lee Dilkie =F2=E5=FA=F7 =EC=E9=E3=E9=F2=E4: behave@ietf.org; Xavier Marjou; = avt@ietf.org =F0=E5=F9=E0: Re: [AVT] Update of rtp-keepalive draft Do we need to mandate an alternative? All of the alternatives=20 specified will work, and RTP implementations have to be robust to=20 receiving all seven types of packet anyway (otherwise, there is a=20 trivial denial-of-service attack on the application). As long as=20 something is sent at an appropriate interval, the NAT will be happy,=20 and the application can use whatever mechanism is appropriate for it. Colin On 15 Jan 2007, at 19:04, Lee Dilkie wrote: > I'd vote for 4.1 first, followed by 4.5 (which sounds a lot like=20 > 4.7 to > me only it's defined). > > reasons: > > sending a 0-byte udp packet is solving a network issue, not an RTP=20 > issue > and shouldn't pretend to be RTP. > > the cons specified: > - udp specific, well yes but this isn't an issue with tcp anyway. > - rx-ing party might not handle this. Perhaps, but since these are > intended to be used for NAT traversal I would assume the rx-ing party > would be most probably aware since the address:port of the received=20 > udp > needs to be communicated to the tx-ing party anyway, and they=20 > generally > need to share the same socket(or at least appear to). > > Otherwise I'd pick an unused RTP payload type value and define it as > reserved for NAT keepalive usage. I guess this most closely maps to=20 > 4.5. > > Regards, > > Lee Dilkie > > (we implemented the 0-byte udp in our solution, FWIW, although we=20 > choose > 30 second intervals). > > Xavier Marjou wrote: >> To keep this topic alive, I plan to update the following individual >> draft: >> http://tools.ietf.org/wg/behave/draft-marjou-behave-app-rtp- >> keepalive-00.txt >> >> >> I am therefore interested of any feedback, especially on which >> mechanism(s) is best. >> >> Xavier >> >>> On 12/3/06, Dan Wing wrote: >>> Minutes of the last BEHAVE meeting have been posted to: >>> http://www3.ietf.org/proceedings/06nov/minutes/behave.html >>> >>> Application Keepalive for NATs, Xavier Marjou - >>> draft-marjou-behave-app-rtp-keepalive-00 >>> status: separate from ICE, or integrate into Application milestone >>> document? >>> >>> JR =96 this is app design guidelines. How about if we charter to=20 >>> create >>> that document and put this text, along with other text around it in >>> STUN all in one document? >>> Xavier Marjou (speaker, XM) =96 take to list. >>> Chair =96 question of which mechanisms might be best asked in AVT FA = =96 >>> good to ask AVT for sure. But we should discuss here Magnus =96 both >>> groups working on it Chair =96 consensus to fold this into = application >>> document, per JR's proposal. >>> Will figure out what to do on list. >>> FA =96 support. Think it's a good idea. But do we have an editor for >>> that, will it get done? I don't want to send this to dev/null. >>> PM =96 in our BEHAVE app document are we the best place to have that >>> discussion? >>> chair - don't have a clear decision on what to do, will work to=20 >>> figure >>> out where this goes. >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www1.ietf.org/mailman/listinfo/avt > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt ------_=_NextPart_001_01C739AC.727E2550 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [AVT] Update of rtp-keepalive draft=0A= =0A= =0A=
The issue of = keepalive is =0A= also related to the RTP endpoint - If the remote side stops the = voice =0A= connection because of some problem during silence, there is no certain = way to =0A= discover it.
=0A=
 
=0A=
So I think = the recommended =0A= alternative should solve both issues (4.5 does the job)
=0A=
 
=0A=
Regards,
=0A=
Yuval
=0A=

=0A=
=0A=
=0A=
=0A=
=EE=E0=FA: Colin = Perkins =0A= [mailto:csp@csperkins.org]
=F0=F9=EC=E7: =E2 16/01/2007 = 18:58
=E0=EC: Lee =0A= Dilkie
=F2=E5=FA=F7 =EC=E9=E3=E9=F2=E4: behave@ietf.org; = Xavier Marjou; =0A= avt@ietf.org
=F0=E5=F9=E0: Re: [AVT] Update of rtp-keepalive =0A= draft

=0A=

Do we need to mandate an alternative? All of = the =0A= alternatives 
specified will work, and RTP implementations have = to be =0A= robust to 
receiving all seven types of packet anyway = (otherwise, there =0A= is a 
trivial denial-of-service attack on the application). As = long =0A= as 
something is sent at an appropriate interval, the NAT will = be =0A= happy, 
and the application can use whatever mechanism is = appropriate =0A= for it.

Colin





On 15 Jan 2007, at 19:04, = Lee Dilkie =0A= wrote:
> I'd vote for 4.1 first, followed by 4.5 (which sounds a = lot =0A= like 
> 4.7 to
> me only it's defined).
>
> =0A= reasons:
>
> sending a 0-byte udp packet is solving a = network issue, =0A= not an RTP 
> issue
> and shouldn't pretend to be =0A= RTP.
>
> the cons specified:
>  - udp specific, = well yes =0A= but this isn't an issue with tcp anyway.
>  - rx-ing party = might not =0A= handle this. Perhaps, but since these are
> intended to be used = for NAT =0A= traversal I would assume the rx-ing party
> would be most probably = aware =0A= since the address:port of the received 
> udp
> needs = to be =0A= communicated to the tx-ing party anyway, and they 
> =0A= generally
> need to share the same socket(or at least appear =0A= to).
>
> Otherwise I'd pick an unused RTP payload type value = and =0A= define it as
> reserved for NAT keepalive usage. I guess this most = closely =0A= maps to 
> 4.5.
>
> Regards,
>
> Lee =0A= Dilkie
>
> (we implemented the 0-byte udp in our solution, = FWIW, =0A= although we 
> choose
> 30 second = intervals).
>
> =0A= Xavier Marjou wrote:
>> To keep this topic alive, I plan to = update the =0A= following individual
>> draft:
>> htt= p://tools.ietf.org/wg/behave/draft-marjou-behave-app-rtp-
>>= =0A= keepalive-00.txt
>>
>>
>> I am therefore = interested =0A= of any feedback, especially on which
>> mechanism(s) is =0A= best.
>>
>> Xavier
>>
>>> On = 12/3/06, Dan =0A= Wing <dwing@cisco.com> wrote:
>>> Minutes of the last = BEHAVE =0A= meeting have been posted to:
>>> http:= //www3.ietf.org/proceedings/06nov/minutes/behave.html
>>>=
>>> =0A= Application Keepalive for NATs, Xavier Marjou -
>>> =0A= draft-marjou-behave-app-rtp-keepalive-00
>>> status:  = separate =0A= from ICE, or integrate into Application milestone
>>> =0A= document?
>>>
>>> JR =96 this is app design = guidelines. =0A= How about if we charter to 
>>> create
>>> = that =0A= document and put this text, along with other text around it = in
>>> =0A= STUN all in one document?
>>> Xavier Marjou (speaker, XM) = =96 take to =0A= list.
>>> Chair =96 question of which mechanisms might be = best asked =0A= in AVT FA =96
>>> good to ask AVT for sure. But we should = discuss here =0A= Magnus =96 both
>>> groups working on it Chair =96 consensus = to fold =0A= this into application
>>> document, per JR's =0A= proposal.
>>> Will figure out what to do on = list.
>>> FA =0A= =96 support. Think it's a good idea. But do we have an editor = for
>>> =0A= that, will it get done? I don't want to send this to = dev/null.
>>> =0A= PM =96 in our BEHAVE app document are we the best place to have =0A= that
>>> discussion?
>>> chair - don't have a = clear =0A= decision on what to do, will work to 
>>> =0A= figure
>>> out where this goes.
>>
>> =0A= _______________________________________________
>> Audio/Video =0A= Transport Working Group
>> avt@ietf.org
>> https://www1.ietf.org= /mailman/listinfo/avt
>
> =0A= _______________________________________________
> Audio/Video = Transport =0A= Working Group
> avt@ietf.org
> https://www1.ietf.org= /mailman/listinfo/avt

--
Colin =0A= Perkins
http://csperkins.org/



<= BR>_______________________________________________
Audio/Video =0A= Transport Working Group
avt@ietf.org
https://www1.ietf.org= /mailman/listinfo/avt

=0A= =0A= =0A= ------_=_NextPart_001_01C739AC.727E2550-- --===============1464739005== 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 --===============1464739005==-- From behave-bounces@ietf.org Wed Jan 17 03:11:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H75sW-0002Rr-8P; Wed, 17 Jan 2007 03:10:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H75sU-0002RR-3C; Wed, 17 Jan 2007 03:10:38 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H75sP-0005Y1-Il; Wed, 17 Jan 2007 03:10:38 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id ACBDD197; Wed, 17 Jan 2007 09:10:24 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jan 2007 09:10:24 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jan 2007 09:10:24 +0100 Message-ID: <45ADD9F0.2010201@ericsson.com> Date: Wed, 17 Jan 2007 09:10:24 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Yuval Nissan Subject: Re: [BEHAVE] RE: [AVT] Update of rtp-keepalive draft References: <458913680701150202l620dca50o1afcf0e57680adcf@mail.gmail.com><45ABD028.4090804@mitel.com> <509E65FC-40C6-474A-840D-EF3D105AAE92@csperkins.org> <79B4F738DDD4EF4F85A4641A0FE5EFD6017A82BD@aclmsg.corp.audiocodes.com> In-Reply-To: <79B4F738DDD4EF4F85A4641A0FE5EFD6017A82BD@aclmsg.corp.audiocodes.com> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jan 2007 08:10:24.0118 (UTC) FILETIME=[F0701960:01C73A0E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: behave@ietf.org, Xavier Marjou , avt@ietf.org, Lee Dilkie X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Yuval Nissan skrev: > The issue of keepalive is also related to the RTP endpoint - If the remote side stops the voice connection because of some problem during silence, there is no certain way to discover it. The solution to that is called RTCP. It is there, it also provides other features. Use it instead of inventing new mechanisms. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 17 04:12:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H76qI-0008LN-Ja; Wed, 17 Jan 2007 04:12:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H76qH-0008JS-32; Wed, 17 Jan 2007 04:12:25 -0500 Received: from mail5.audiocodes.com ([212.25.125.21] helo=imss.audiocodes.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H76qF-0002aE-Fj; Wed, 17 Jan 2007 04:12:25 -0500 Received: from aclmsg.corp.audiocodes.com ([10.1.0.8]) by imss with InterScan Messaging Security Suite; Wed, 17 Jan 2007 11:14: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] RE: [AVT] Update of rtp-keepalive draft Date: Wed, 17 Jan 2007 11:12:10 +0200 Message-ID: <79B4F738DDD4EF4F85A4641A0FE5EFD602CA8B1D@aclmsg.corp.audiocodes.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] RE: [AVT] Update of rtp-keepalive draft Thread-Index: Acc6DvkS14DD5nFoS+uCzTjGAkHHXgAAl0iw From: "Yuval Nissan" To: "Magnus Westerlund" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: behave@ietf.org, Xavier Marjou , avt@ietf.org, Lee Dilkie X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org RTCP is the right solution. However in practice not all devices support RTCP, and using mechanism like the No-Op (that puts limit on the maximum time of no data in the connection) can help in these cases. Regards, Yuval=20 -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Wednesday, January 17, 2007 10:10 AM To: Yuval Nissan Cc: Colin Perkins; Lee Dilkie; Xavier Marjou; behave@ietf.org; avt@ietf.org Subject: Re: [BEHAVE] RE: [AVT] Update of rtp-keepalive draft Yuval Nissan skrev: > The issue of keepalive is also related to the RTP endpoint - If the remote side stops the voice connection because of some problem during silence, there is no certain way to discover it. The solution to that is called RTCP. It is there, it also provides other features. Use it instead of inventing new mechanisms. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 17 04:19:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H76xW-0003ps-Oy; Wed, 17 Jan 2007 04:19:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H76xV-0003pf-V2; Wed, 17 Jan 2007 04:19:53 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H76xU-0004Ni-Kr; Wed, 17 Jan 2007 04:19:53 -0500 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:64021 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1H76xS-0002Z4-HL; Wed, 17 Jan 2007 09:19:50 +0000 In-Reply-To: <79B4F738DDD4EF4F85A4641A0FE5EFD602CA8B1D@aclmsg.corp.audiocodes.com> References: <79B4F738DDD4EF4F85A4641A0FE5EFD602CA8B1D@aclmsg.corp.audiocodes.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2EB1317C-B746-460A-BAE4-B107429E807A@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [BEHAVE] RE: [AVT] Update of rtp-keepalive draft Date: Wed, 17 Jan 2007 09:19:47 +0000 To: Yuval Nissan X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Xavier Marjou , Lee Dilkie , behave@ietf.org, avt@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 Or you could just implement RTCP. It's not like it's difficult to do a minimal implementation... Colin On 17 Jan 2007, at 09:12, Yuval Nissan wrote: > RTCP is the right solution. However in practice not all devices > support > RTCP, and using mechanism like the No-Op (that puts limit on the > maximum > time of no data in the connection) can help in these cases. > > Regards, > Yuval > > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Wednesday, January 17, 2007 10:10 AM > To: Yuval Nissan > Cc: Colin Perkins; Lee Dilkie; Xavier Marjou; behave@ietf.org; > avt@ietf.org > Subject: Re: [BEHAVE] RE: [AVT] Update of rtp-keepalive draft > > Yuval Nissan skrev: >> The issue of keepalive is also related to the RTP endpoint - If the > remote side stops the voice connection because of some problem during > silence, there is no certain way to discover it. > > The solution to that is called RTCP. It is there, it also provides > other > > features. Use it instead of inventing new mechanisms. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- -- Colin Perkins http://csperkins.org/ _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 17 09:58:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7CFR-0000bP-FL; Wed, 17 Jan 2007 09:58:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7CFO-0000Zd-V4; Wed, 17 Jan 2007 09:58:42 -0500 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7CFL-0008CS-Lf; Wed, 17 Jan 2007 09:58:42 -0500 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 5621F20097; Wed, 17 Jan 2007 09:58:39 -0500 (EST) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05717-02; Wed, 17 Jan 2007 09:58:38 -0500 (EST) Received: from ottpop01.software.mitel.com (ottpop01.mitel.com [134.199.30.50]) by smtp.mitel.com (Postfix) with ESMTP id 5FA7A200C1; Wed, 17 Jan 2007 09:58:37 -0500 (EST) Received: from [10.39.164.100] ([10.39.164.100]) by ottpop01.software.mitel.com (8.12.10/8.12.10) with ESMTP id l0HEwYWW016778; Wed, 17 Jan 2007 09:58:34 -0500 (EST) Message-ID: <45AE399D.80902@mitel.com> Date: Wed, 17 Jan 2007 09:58:37 -0500 From: Lee Dilkie User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Colin Perkins Subject: Re: [BEHAVE] RE: [AVT] Update of rtp-keepalive draft References: <79B4F738DDD4EF4F85A4641A0FE5EFD602CA8B1D@aclmsg.corp.audiocodes.com> <2EB1317C-B746-460A-BAE4-B107429E807A@csperkins.org> In-Reply-To: <2EB1317C-B746-460A-BAE4-B107429E807A@csperkins.org> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Yuval Nissan , Xavier Marjou , avt@ietf.org, behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org It's been a while since I read the specs but doesn't RTCP use different (+1) ports than RTP? If so then it isn't a solution. -lee Colin Perkins wrote: > Or you could just implement RTCP. It's not like it's difficult to do a > minimal implementation... > > Colin > > > On 17 Jan 2007, at 09:12, Yuval Nissan wrote: >> RTCP is the right solution. However in practice not all devices support >> RTCP, and using mechanism like the No-Op (that puts limit on the maximum >> time of no data in the connection) can help in these cases. >> >> Regards, >> Yuval >> >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Wednesday, January 17, 2007 10:10 AM >> To: Yuval Nissan >> Cc: Colin Perkins; Lee Dilkie; Xavier Marjou; behave@ietf.org; >> avt@ietf.org >> Subject: Re: [BEHAVE] RE: [AVT] Update of rtp-keepalive draft >> >> Yuval Nissan skrev: >>> The issue of keepalive is also related to the RTP endpoint - If the >> remote side stops the voice connection because of some problem during >> silence, there is no certain way to discover it. >> >> The solution to that is called RTCP. It is there, it also provides other >> >> features. Use it instead of inventing new mechanisms. >> >> Cheers >> >> Magnus Westerlund >> >> IETF Transport Area Director & TSVWG Chair >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVA/A >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 8 4048287 >> Torshamsgatan 23 | Fax +46 8 7575550 >> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- > > --Colin Perkins > http://csperkins.org/ > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 17 10:07:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7CNt-0008AQ-SO; Wed, 17 Jan 2007 10:07:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7CNs-0008AF-4A; Wed, 17 Jan 2007 10:07:28 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7CNo-0001QA-MG; Wed, 17 Jan 2007 10:07:28 -0500 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:62399) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1H7CNm-0006le-9v; Wed, 17 Jan 2007 15:07:22 +0000 In-Reply-To: <45AE399D.80902@mitel.com> References: <79B4F738DDD4EF4F85A4641A0FE5EFD602CA8B1D@aclmsg.corp.audiocodes.com> <2EB1317C-B746-460A-BAE4-B107429E807A@csperkins.org> <45AE399D.80902@mitel.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1A231877-70A9-4303-8983-644D7CFC23A5@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [BEHAVE] RE: [AVT] Update of rtp-keepalive draft Date: Wed, 17 Jan 2007 15:07:16 +0000 To: Lee Dilkie X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Yuval Nissan , Xavier Marjou , avt@ietf.org, behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Yes, but there is a proposal to allow RTCP on the RTP port for this reason. See draft-ietf-avt-rtp-and-rtcp-mux-03.txt. Colin On 17 Jan 2007, at 14:58, Lee Dilkie wrote: > It's been a while since I read the specs but doesn't RTCP use > different > (+1) ports than RTP? If so then it isn't a solution. > > -lee > > > Colin Perkins wrote: >> Or you could just implement RTCP. It's not like it's difficult to >> do a >> minimal implementation... >> >> Colin >> >> >> On 17 Jan 2007, at 09:12, Yuval Nissan wrote: >>> RTCP is the right solution. However in practice not all devices >>> support >>> RTCP, and using mechanism like the No-Op (that puts limit on the >>> maximum >>> time of no data in the connection) can help in these cases. >>> >>> Regards, >>> Yuval >>> >>> -----Original Message----- >>> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >>> Sent: Wednesday, January 17, 2007 10:10 AM >>> To: Yuval Nissan >>> Cc: Colin Perkins; Lee Dilkie; Xavier Marjou; behave@ietf.org; >>> avt@ietf.org >>> Subject: Re: [BEHAVE] RE: [AVT] Update of rtp-keepalive draft >>> >>> Yuval Nissan skrev: >>>> The issue of keepalive is also related to the RTP endpoint - If the >>> remote side stops the voice connection because of some problem >>> during >>> silence, there is no certain way to discover it. >>> >>> The solution to that is called RTCP. It is there, it also >>> provides other >>> >>> features. Use it instead of inventing new mechanisms. >>> >>> Cheers >>> >>> Magnus Westerlund >>> >>> IETF Transport Area Director & TSVWG Chair >>> -------------------------------------------------------------------- >>> -- >>> Multimedia Technologies, Ericsson Research EAB/TVA/A >>> -------------------------------------------------------------------- >>> -- >>> Ericsson AB | Phone +46 8 4048287 >>> Torshamsgatan 23 | Fax +46 8 7575550 >>> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>> -------------------------------------------------------------------- >>> -- >> >> --Colin Perkins >> http://csperkins.org/ >> >> -- Colin Perkins http://csperkins.org/ _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 17 11:38:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7DnU-0007QR-Bt; Wed, 17 Jan 2007 11:38:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7DnS-0007QD-Fr; Wed, 17 Jan 2007 11:37:58 -0500 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7DnR-0002vR-4K; Wed, 17 Jan 2007 11:37:58 -0500 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id B3B7220092; Wed, 17 Jan 2007 11:37:56 -0500 (EST) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27335-05; Wed, 17 Jan 2007 11:37:55 -0500 (EST) Received: from ottpop01.software.mitel.com (ottpop01.mitel.com [134.199.30.50]) by smtp.mitel.com (Postfix) with ESMTP id 26EA820093; Wed, 17 Jan 2007 11:37:55 -0500 (EST) Received: from [10.39.164.100] ([10.39.164.100]) by ottpop01.software.mitel.com (8.12.10/8.12.10) with ESMTP id l0HGbrWW018301; Wed, 17 Jan 2007 11:37:53 -0500 (EST) Message-ID: <45AE50E2.5070600@mitel.com> Date: Wed, 17 Jan 2007 11:37:54 -0500 From: Lee Dilkie User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Colin Perkins Subject: Re: [BEHAVE] RE: [AVT] Update of rtp-keepalive draft References: <79B4F738DDD4EF4F85A4641A0FE5EFD602CA8B1D@aclmsg.corp.audiocodes.com> <2EB1317C-B746-460A-BAE4-B107429E807A@csperkins.org> <45AE399D.80902@mitel.com> <1A231877-70A9-4303-8983-644D7CFC23A5@csperkins.org> In-Reply-To: <1A231877-70A9-4303-8983-644D7CFC23A5@csperkins.org> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: Yuval Nissan , Xavier Marjou , avt@ietf.org, 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 Seems a little heavyweight to solve what is essentially a network layer problem. I'm not a fan of trying to guess at protocols in realtime based on what's put in front of me, I worry about the security implications. For that reason I like the 0-byte udp approach, it cannot be confused with anything else (RTP or RTCP). As well, the 0-byte technique can be used for other protocols, like RTCP, to aid them in traversing NAT. It would be nice if we could use a time machine to go baaaack in order to fix the future (wasn't that a movie?) but we have what we have I guess. -lee Colin Perkins wrote: > Yes, but there is a proposal to allow RTCP on the RTP port for this > reason. See draft-ietf-avt-rtp-and-rtcp-mux-03.txt. > > Colin > > > > On 17 Jan 2007, at 14:58, Lee Dilkie wrote: >> It's been a while since I read the specs but doesn't RTCP use different >> (+1) ports than RTP? If so then it isn't a solution. >> >> -lee >> >> >> Colin Perkins wrote: >>> Or you could just implement RTCP. It's not like it's difficult to do a >>> minimal implementation... >>> >>> Colin >>> >>> >>> On 17 Jan 2007, at 09:12, Yuval Nissan wrote: >>>> RTCP is the right solution. However in practice not all devices >>>> support >>>> RTCP, and using mechanism like the No-Op (that puts limit on the >>>> maximum >>>> time of no data in the connection) can help in these cases. >>>> >>>> Regards, >>>> Yuval >>>> >>>> -----Original Message----- >>>> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >>>> Sent: Wednesday, January 17, 2007 10:10 AM >>>> To: Yuval Nissan >>>> Cc: Colin Perkins; Lee Dilkie; Xavier Marjou; behave@ietf.org; >>>> avt@ietf.org >>>> Subject: Re: [BEHAVE] RE: [AVT] Update of rtp-keepalive draft >>>> >>>> Yuval Nissan skrev: >>>>> The issue of keepalive is also related to the RTP endpoint - If the >>>> remote side stops the voice connection because of some problem during >>>> silence, there is no certain way to discover it. >>>> >>>> The solution to that is called RTCP. It is there, it also provides >>>> other >>>> >>>> features. Use it instead of inventing new mechanisms. >>>> >>>> Cheers >>>> >>>> Magnus Westerlund >>>> >>>> IETF Transport Area Director & TSVWG Chair >>>> ---------------------------------------------------------------------- >>>> Multimedia Technologies, Ericsson Research EAB/TVA/A >>>> ---------------------------------------------------------------------- >>>> Ericsson AB | Phone +46 8 4048287 >>>> Torshamsgatan 23 | Fax +46 8 7575550 >>>> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>>> ---------------------------------------------------------------------- >>> >>> --Colin Perkins >>> http://csperkins.org/ >>> >>> > > --Colin Perkins > http://csperkins.org/ > > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 17 15:50:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7HjY-0004uY-Qf; Wed, 17 Jan 2007 15:50:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7HjO-0004sw-Qm; Wed, 17 Jan 2007 15:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7HjO-0002op-FM; Wed, 17 Jan 2007 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 59207329FA; Wed, 17 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H7HjO-0004HF-7H; Wed, 17 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 17 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: behave@ietf.org Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-tcp-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : NAT Behavioral Requirements for TCP Author(s) : S. Guha, et al. Filename : draft-ietf-behave-tcp-04.txt Pages : 20 Date : 2007-1-17 This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and on-line games, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-tcp-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-tcp-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-behave-tcp-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-17143004.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-tcp-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-tcp-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-17143004.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Thu Jan 18 11:10:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ZqL-00052H-73; Thu, 18 Jan 2007 11:10:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ZqJ-000526-UH for behave@ietf.org; Thu, 18 Jan 2007 11:10:23 -0500 Received: from wr-out-0506.google.com ([64.233.184.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7ZqI-0000U7-F1 for behave@ietf.org; Thu, 18 Jan 2007 11:10:23 -0500 Received: by wr-out-0506.google.com with SMTP id i22so200896wra for ; Thu, 18 Jan 2007 08:10:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=cdF7udJfcPFx4AU8q6NyNYLYNQL8Rfu2iGYVmnR6y3NcFikc1aZRN1Wt+T7c+d10XmmEBhwUQHSEbhqXGNt8op8JvmZZd/YBN5FzGaCFJ52RfheYgUa01sZdv4QZOTk+piGxUJxX1cJHsoZ6L0VdZP6dZsfX/oJBX2s/9SiT0BQ= Received: by 10.90.34.3 with SMTP id h3mr1471680agh.1169136621674; Thu, 18 Jan 2007 08:10:21 -0800 (PST) Received: by 10.90.98.17 with HTTP; Thu, 18 Jan 2007 08:10:21 -0800 (PST) Message-ID: <458913680701180810n60f278d2ja5690ff2ee667afe@mail.gmail.com> Date: Thu, 18 Jan 2007 17:10:21 +0100 From: "Xavier Marjou" To: "Colin Perkins" Subject: Re: [BEHAVE] Re: [AVT] Update of rtp-keepalive draft In-Reply-To: <509E65FC-40C6-474A-840D-EF3D105AAE92@csperkins.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <458913680701150202l620dca50o1afcf0e57680adcf@mail.gmail.com> <45ABD028.4090804@mitel.com> <509E65FC-40C6-474A-840D-EF3D105AAE92@csperkins.org> X-Google-Sender-Auth: 870c6b4759e4d435 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: behave@ietf.org, Lee Dilkie , avt@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 > Do we need to mandate an alternative? Personally, I would really prefer to only have one alternative recommended when STUN is not yet available. When too many alternatives exist for one same thing, this results in additional complexity in interoperability and also in future specifications that would rely on that thing. Xavier _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 19 23:03:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H87RV-0007cw-Ot; Fri, 19 Jan 2007 23:03:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H87RU-0007cU-PK for behave@ietf.org; Fri, 19 Jan 2007 23:03:00 -0500 Received: from wx-out-0506.google.com ([66.249.82.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H87RU-0001yY-CQ for behave@ietf.org; Fri, 19 Jan 2007 23:03:00 -0500 Received: by wx-out-0506.google.com with SMTP id h31so692127wxd for ; Fri, 19 Jan 2007 20:03:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=Ia241oboYrPWona7/6T0t5gzqg1ZXZUB1+j78a/KJJsMgiNEp94LPR0nbaGgfLv6p9agOUSDEUbv+A4hSpUFZnwzqIKmRneSyFcjY8OcEEZHmZP9Rte74gvD0A4J1EKHKzQO59onHvHO2CZqyseg/kZ5qyn9l4eX3OqUGFc7Sdw= Received: by 10.70.48.11 with SMTP id v11mr5322771wxv.1169265779605; Fri, 19 Jan 2007 20:02:59 -0800 (PST) Received: by 10.70.30.14 with HTTP; Fri, 19 Jan 2007 20:02:59 -0800 (PST) Message-ID: <953beacc0701192002w611d6f9dh9e11dde80a87fe09@mail.gmail.com> Date: Fri, 19 Jan 2007 20:02:59 -0800 From: "Rohan Mahy" To: behave@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: Rohan Mahy Subject: [BEHAVE] TURN major issues and proposed fixes X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi Folks, The following issues have all come up from implementors of TURN and are big enough issues that I wanted to get some list feedback before incorporating these in a new rev. 1. Allocations, Bindings, Permissions, Timeouts, and the Active Destination. The current text is still a bit fuzzy and inconsistent about what is a difference between permission and a binding and what keeps bindings open. Also, many implementors have expressed confusion between the behavior of an ordinary NAT binding and a "STUN Relay binding", so I am proposing we skip the binding terminology in favor of "permission". Much of the following came from consensus at one of the meetings. I've come up with the following proposal which fills out a consistent set of rules: - Remove the terminology "binding" altogether inside the TURN server. Only use "binding" when talking about a "real" NAT (ex: between the TURN client and the TURN server) - All requests and indications except for initial Allocation requests are sent in the context of a matching valid allocation, otherwise they are rejected (requests) or discarded silently (Indications). - Allocations are explicitly refreshed via subsequent allocation requests. Allocation timeout values are on the order of minutes. Send and Data indications do not refresh Allocations. Allocation timers are based on the LIFETIME attribute. - Each allocation can have zero or more permissions - When allocations are destroyed all related permissions are deleted. - Permissions are only created by Send Indications over UDP and Connect Requests over TCP. - Data sent to a peer (via send Indications and unencapsulated data sent to the active destination) by the TURN client refresh the relevant permission. Data to one permission does not refresh other permissions associated with the same binding. - The expected timeout interval for all permissions for an allocation is conveyed from the server to the client using the REFRESH-INTERVAL attribute in an initial successful Allocate Response. - The active destination is changed only with the Set Active Destination Request for an allocation. The active destination is completely independent of any permissions. 2. SetActiveDestination should not be limited to existing permissions Current text in some places says that the active destination needs to be an existing permission. This is actually unnecessary however, and loosening this restriction is useful. Take the case where the TURN client receives a SIP INVITE with an offer, and the TURN client wishes to accept the offer. The TURN client should be able to set the active destination immediately before issuing its first Send request (to this destination). Using this order of operations insures that the TURN client receives all data traffic unencapsulated. This provides for more consistent bandwidth usage in this case. The proposal is to change the current text to completely decouple the active destination from any permissions. A permission controls whether traffic flows. The active destination controls whether traffic flowing over a binding is encapsulated of not. An alternative to this proposal is to create a new permission if no permission for the active destination exists. The problem is that this does not result in sending any data to the peer (as described in the applicability statement and UNSAF considerations), it is completely implicit behavior, and the opposite operation (clearing the active destination) does not delete permissions. 3. SetActiveDestination changing destinations Currently there are several pages of text devoted to a timer based state machine that needs to be implemented on both the server and the client to handle the case of switching the active destination from one address to another. The problem is that over UDP, the client cannot tell which unencapsulated data is from the old active destination vs. the new active destination. However, requiring timers and a state machine on the server is a significant implementation burden which provides no benefit for the TURN server or its administrative domain. The proposal is to put this problem completely into the hands of the client. Some clients may never wish to change the active destination for example and will have no need to implement anything special. Those clients that want to change the active destination over UDP are required to clear the active destination, wait for an appropriate interval (5 seconds is suggested), then set the active destination to the new address. Specific proposed text for items 2 and 3 and also delete the TIMER-VAL attribute:
The Set Active Destination address allows the client to create an optimized relay function between it and the server. When the server receives packets from a particular preferred external client, the server will forward those packets towards the client without encapsulating them in a Data Indication. Similarly, the client can send non-STUN packets to the server without encapsulation, and these are forwarded to the external client. Sending and receiving data in unencapsulated form is critical for efficiency purposes. One of the primary use cases for the STUN relay usage is in support of Voice over IP (VoIP), which uses very small UDP packets to begin with. The extra overhead of an additional layer of encapsulation is considered unacceptable. The Set Active Destination request is used by the client to provide the identity of this preferred external client. The Set Active Destination address MAY contain a REMOTE-ADDRESS attribute. This attribute, when present, provides the address of the preferred external client to the server. When absent, it clears the value of the preferred external client. This address has no effect on the existence of any permissions. The client MUST NOT send a Set Active Destination request with a REMOTE-ADDRESS attribute over an unreliable link (ex: UDP) if an active destination is already set for that allocation. If the client wishes to set a new active destination, it MUST wait until 5 seconds after a successful response is received to a Set Destination Request removing the active destination. Failure to wait could cause the client to receive and attribute late data forwarded by the STUN relay server to the wrong peer. Consider the case where the active destination is set, and the server is relaying packets towards the client. The client knows the IP address and port where the packets came from - the current value of the active destination. The client issues a Set Active Destination Request to change the active destination, and receives a response. A moment later, a data packet is received, not encapsulated in a STUN Data Indication. What is the source if this packet? Is it the active destination that existed prior to the Set Active Destination request, or the one after? If the transport between the client and the STUN server is not reliable, there is no way to know.
The Set Active Destination Request is used by a client to set the forwarding destination of all data that is not encapsulated in STUN Send Indications. In addition, when a matching permission is present, all data received from that external client will be forwarded to the STUN client without being encapsulated in a Data Indication. This request does not modify any permissions. The request MUST be authenticated using the same shared secret as the one associated with the allocation, or be authenticated using a short term password derived from that shared secret. If the request was authenticated but not with such a matching credential, the server MUST generate an error response with a 441 response code. If the Set Active Destination request does not contain a REMOTE-ADDRESS attribute, the value of the active destination is cleared. If the Set Active Destination request contains a REMOTE-ADDRESS attribute, and the active destination is not set, the active destination is set to that IP address and port. If an active destination is already set, and the request was received over a reliable transport, the active destination is changed to the new value. If the active destination is already set and the request was received over UDP, the Set Active Destination request is rejected with a 439 Active Destination Already Set error response. This prevents the race condition described in the previous section.
4. Opening TCP permissions Currently TCP to TCP traffic between TURN servers requires the TURN servers to implement simultaneous open. SYN -> <- SYN SYN-ACK -> <- ACK Option A is to leave this as is and to clarify this non-obvious implication to implementors (you cannot receive an incoming connection unless you first try to open one with the Connect request. Option B is to include an explicit Open Permission Request to create a specific permission for the TURN server to receive a TCP SYN from one specific IP address and port number. I will implement Option A unless there is strong desire on the list to do something else. thanks, -rohan _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 22 19:21:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H99PP-0002vl-Lp; Mon, 22 Jan 2007 19:21:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H99PN-0002uh-MD for behave@ietf.org; Mon, 22 Jan 2007 19:21:05 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H99PM-0007oE-5i for behave@ietf.org; Mon, 22 Jan 2007 19:21:05 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l0N0L1V00134; Mon, 22 Jan 2007 19:21:01 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] TURN major issues and proposed fixes Date: Mon, 22 Jan 2007 18:21:00 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371125DE5DB@zrc2hxm2.corp.nortel.com> In-Reply-To: <953beacc0701192002w611d6f9dh9e11dde80a87fe09@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] TURN major issues and proposed fixes Thread-index: Acc8SCfLyk7urfbTQsG2yOJZC7nm9gCOnIYQ From: "Brian Stucker" To: "Rohan Mahy" , X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: Rohan Mahy X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org =20 > -----Original Message----- > From: Rohan Mahy [mailto:rohan.mahy@gmail.com]=20 > Sent: Friday, January 19, 2007 10:03 PM > To: behave@ietf.org > Cc: Rohan Mahy > Subject: [BEHAVE] TURN major issues and proposed fixes >=20 > Hi Folks, >=20 > The following issues have all come up from implementors of=20 > TURN and are big enough issues that I wanted to get some list=20 > feedback before incorporating these in a new rev. >=20 > 1. Allocations, Bindings, Permissions, Timeouts, and the=20 > Active Destination. >=20 > The current text is still a bit fuzzy and inconsistent about=20 > what is a difference between permission and a binding and=20 > what keeps bindings open. Also, many implementors have=20 > expressed confusion between the behavior of an ordinary NAT=20 > binding and a "STUN Relay binding", so I am proposing we skip=20 > the binding terminology in favor of "permission". > Much of the following came from consensus at one of the=20 > meetings. I've come up with the following proposal which=20 > fills out a consistent set of rules: > - Remove the terminology "binding" altogether inside the TURN server. > Only use "binding" when talking about a "real" NAT (ex:=20 > between the TURN client and the TURN server) Sounds good. > - All requests and indications except for initial Allocation=20 > requests are sent in the context of a matching valid=20 > allocation, otherwise they are rejected (requests) or=20 > discarded silently (Indications). Sounds good. > - Allocations are explicitly refreshed via subsequent=20 > allocation requests. Allocation timeout values are on the=20 > order of minutes. Send and Data indications do not refresh=20 > Allocations. Allocation timers are based on the LIFETIME attribute. I'm confused. What's the relation between LIFETIME and REFRESH-INTERVAL below? If the allocation expires, then the permissions go with it because the permissions were created in the context of an allocation. > - Each allocation can have zero or more permissions > - When allocations are destroyed all related permissions are deleted. > - Permissions are only created by Send Indications over UDP=20 > and Connect Requests over TCP. This means that an offerer would have to generate RTP traffic to an answerer to get RTP traffic sent back to it. What if I want to setup a one-way stream to me in which it's inappropriate to generate traffic in the other direction, only to make the TURN server happy? Why not let Set Active Destination also create a permission? > - Data sent to a peer (via send Indications and=20 > unencapsulated data sent to the active destination) by the=20 > TURN client refresh the relevant permission. Data to one=20 > permission does not refresh other permissions associated with=20 > the same binding. Sounds good. > - The expected timeout interval for all permissions for an=20 > allocation is conveyed from the server to the client using=20 > the REFRESH-INTERVAL attribute in an initial successful=20 > Allocate Response. How does this relate to LIFETIME (see above)? > - The active destination is changed only with the Set Active=20 > Destination Request for an allocation. The active destination=20 > is completely independent of any permissions. There's some text about the Set Active Destination Request creating a permission in section 9.2 that's been floating about on the list as being used to allow an originator to tell the TURN server to allow traffic from that destination. This would make it possible for a permission to be created without requiring the originator to generate traffic to the actual intended destination. I think this should be allowed. Are you proposing changing this? >=20 > 2. SetActiveDestination should not be limited to existing=20 > permissions Current text in some places says that the active=20 > destination needs to be an existing permission. This is=20 > actually unnecessary however, and loosening this restriction=20 > is useful. > Take the case where the TURN client receives a SIP INVITE=20 > with an offer, and the TURN client wishes to accept the=20 > offer. The TURN client should be able to set the active=20 > destination immediately before issuing its first Send request=20 > (to this destination). Using this order of operations insures=20 > that the TURN client receives all data traffic=20 > unencapsulated. This provides for more consistent bandwidth=20 > usage in this case. This does not (to me) appear to mesh with some of the points you've made above. I thought paragraph 5 on page 19 of the draft made the expectation pretty clear: If the Set Active Destination request contains a REMOTE-ADDRESS attribute, the IP address contained within it is added to the permissions for this allocation, if it was not already present. >=20 > The proposal is to change the current text to completely=20 > decouple the active destination from any permissions. A=20 > permission controls whether traffic flows. The active=20 > destination controls whether traffic flowing over a binding=20 > is encapsulated of not. >=20 > An alternative to this proposal is to create a new permission=20 > if no permission for the active destination exists. The=20 > problem is that this does not result in sending any data to=20 > the peer (as described in the applicability statement and=20 > UNSAF considerations), it is completely implicit behavior,=20 > and the opposite operation (clearing the active destination)=20 > does not delete permissions. Why not add an operation to explicitly clear the active destination then? >=20 > 3. SetActiveDestination changing destinations >=20 > Currently there are several pages of text devoted to a timer=20 > based state machine that needs to be implemented on both the=20 > server and the client to handle the case of switching the=20 > active destination from one address to another. The problem=20 > is that over UDP, the client cannot tell which=20 > unencapsulated data is from the old active destination vs. > the new active destination. >=20 > However, requiring timers and a state machine on the server=20 > is a significant implementation burden which provides no=20 > benefit for the TURN server or its administrative domain. >=20 > The proposal is to put this problem completely into the hands=20 > of the client. Some clients may never wish to change the=20 > active destination for example and will have no need to=20 > implement anything special. > Those clients that want to change the active destination over=20 > UDP are required to clear the active destination, wait for an=20 > appropriate interval (5 seconds is suggested), then set the=20 > active destination to the new address. >=20 > Specific proposed text for items 2 and 3 and also delete the TIMER-VAL > attribute: >=20 >
title=3D"Client Behavior"> The Set Active Destination=20 > address allows the client to create an optimized relay=20 > function between it and the server. When the server receives=20 > packets from a particular preferred external client, the=20 > server will forward those packets towards the client without=20 > encapsulating them in a Data Indication. Similarly, the=20 > client can send non-STUN packets to the server without=20 > encapsulation, and these are forwarded to the external=20 > client. Sending and receiving data in unencapsulated form is=20 > critical for efficiency purposes. One of the primary use=20 > cases for the STUN relay usage is in support of Voice over IP=20 > (VoIP), which uses very small UDP packets to begin with. The=20 > extra overhead of an additional layer of encapsulation is=20 > considered unacceptable. > > The Set Active Destination request is used by the client to=20 > provide the identity of this preferred external client. The=20 > Set Active Destination address MAY contain a REMOTE-ADDRESS=20 > attribute. This attribute, when present, provides the address=20 > of the preferred external client to the server. When absent,=20 > it clears the value of the preferred external client. This=20 > address has no effect on the existence of any permissions. > > The client MUST NOT send a Set Active Destination request=20 > with a REMOTE-ADDRESS attribute over an unreliable link (ex:=20 > UDP) if an active destination is already set for that=20 > allocation. If the client wishes to set a new active=20 > destination, it MUST wait until 5 seconds after a successful=20 > response is received to a Set Destination Request removing=20 > the active destination. Failure to wait could cause the=20 > client to receive and attribute late data forwarded by the=20 > STUN relay server to the wrong peer. > > Consider the case where the active destination is=20 > set, and the server is relaying packets towards the client.=20 > The client knows the IP address and port where the packets=20 > came from - the current value of the active destination. The=20 > client issues a Set Active Destination Request to change the=20 > active destination, and receives a response. A moment later,=20 > a data packet is received, not encapsulated in a STUN Data=20 > Indication. What is the source if this packet? Is it the=20 > active destination that existed prior to the Set Active=20 > Destination request, or the one after? If the transport=20 > between the client and the STUN server is not reliable, there=20 > is no way to know.
>=20 >
> > The Set Active Destination Request is used by a client to set=20 > the forwarding destination of all data that is not=20 > encapsulated in STUN Send Indications. In addition, when a=20 > matching permission is present, all data received from that=20 > external client will be forwarded to the STUN client without=20 > being encapsulated in a Data Indication. This request does=20 > not modify any permissions. > > The request MUST be authenticated using the same shared=20 > secret as the one associated with the allocation, or be=20 > authenticated using a short term password derived from that=20 > shared secret. If the request was authenticated but not with=20 > such a matching credential, the server MUST generate an error=20 > response with a 441 response code. > > If the Set Active Destination request does not contain a=20 > REMOTE-ADDRESS attribute, the value of the active destination=20 > is cleared. If the Set Active Destination request contains a=20 > REMOTE-ADDRESS attribute, and the active destination is not=20 > set, the active destination is set to that IP address and=20 > port. If an active destination is already set, and the=20 > request was received over a reliable transport, the active=20 > destination is changed to the new value. If the active=20 > destination is already set and the request was received over=20 > UDP, the Set Active Destination request is rejected with a=20 > 439 Active Destination Already Set error response. This=20 > prevents the race condition described in the previous section. > >
> >=20 > 4. Opening TCP permissions >=20 > Currently TCP to TCP traffic between TURN servers requires=20 > the TURN servers to implement simultaneous open. >=20 > SYN -> > <- SYN > SYN-ACK -> > <- ACK >=20 > Option A is to leave this as is and to clarify this=20 > non-obvious implication to implementors (you cannot receive=20 > an incoming connection unless you first try to open one with=20 > the Connect request. Option B is to include an explicit Open=20 > Permission Request to create a specific permission for the=20 > TURN server to receive a TCP SYN from one specific IP address=20 > and port number. >=20 > I will implement Option A unless there is strong desire on=20 > the list to do something else. >=20 > thanks, > -rohan >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave >=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 23 11:25:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9OSA-0001xr-Rm; Tue, 23 Jan 2007 11:24:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9OS9-0001xg-TF for behave@ietf.org; Tue, 23 Jan 2007 11:24:57 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9OS9-0002Lq-38 for behave@ietf.org; Tue, 23 Jan 2007 11:24:57 -0500 Received: from [131.161.248.88] (open-131-161-248-88.cliq.com [131.161.248.88]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l0NGOi223259; Tue, 23 Jan 2007 08:24:44 -0800 In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371125DE5DB@zrc2hxm2.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA4371125DE5DB@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2be65072dd926b19cee30b39c2f75d45@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [BEHAVE] TURN major issues and proposed fixes Date: Tue, 23 Jan 2007 08:24:40 -0800 To: "Brian Stucker" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b Cc: Rohan Mahy , behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi Brian, Thanks for your comments. My responses are inline. On Jan 22, 2007, at 16:21, Brian Stucker wrote: >> -----Original Message----- >> From: Rohan Mahy [mailto:rohan.mahy@gmail.com] >> Sent: Friday, January 19, 2007 10:03 PM >> To: behave@ietf.org >> Cc: Rohan Mahy >> Subject: [BEHAVE] TURN major issues and proposed fixes >> >> Hi Folks, >> >> The following issues have all come up from implementors of >> TURN and are big enough issues that I wanted to get some list >> feedback before incorporating these in a new rev. >> >> 1. Allocations, Bindings, Permissions, Timeouts, and the >> Active Destination. >> >> The current text is still a bit fuzzy and inconsistent about >> what is a difference between permission and a binding and >> what keeps bindings open. Also, many implementors have >> expressed confusion between the behavior of an ordinary NAT >> binding and a "STUN Relay binding", so I am proposing we skip >> the binding terminology in favor of "permission". >> Much of the following came from consensus at one of the >> meetings. I've come up with the following proposal which >> fills out a consistent set of rules: >> - Remove the terminology "binding" altogether inside the TURN server. >> Only use "binding" when talking about a "real" NAT (ex: >> between the TURN client and the TURN server) > > Sounds good. > >> - All requests and indications except for initial Allocation >> requests are sent in the context of a matching valid >> allocation, otherwise they are rejected (requests) or >> discarded silently (Indications). > > Sounds good. > >> - Allocations are explicitly refreshed via subsequent >> allocation requests. Allocation timeout values are on the >> order of minutes. Send and Data indications do not refresh >> Allocations. Allocation timers are based on the LIFETIME attribute. > > I'm confused. What's the relation between LIFETIME and REFRESH-INTERVAL > below? If the allocation expires, then the permissions go with it > because the permissions were created in the context of an allocation. I expect that the LIFETIME might be on the order of 15 minutes, and the REFRESH-INTERVAL for a UDP permission might be on the order of 30 seconds. Under the proposal here, you need to send data to the target of each permission at least every 30 seconds to keep the permission alive. I assume this also is likely to have the side effect of keeping NAT bindings alive as well. You separately need to send a (re)Allocate Request to the TURN server at least every 15 minutes to refresh the allocation. As you pointed out, if you don't do this, the whole allocation goes away and all the related permissions with it. >> - Each allocation can have zero or more permissions >> - When allocations are destroyed all related permissions are deleted. >> - Permissions are only created by Send Indications over UDP >> and Connect Requests over TCP. > > This means that an offerer would have to generate RTP traffic to an > answerer to get RTP traffic sent back to it. What if I want to setup a > one-way stream to me in which it's inappropriate to generate traffic in > the other direction, only to make the TURN server happy? Why not let > Set > Active Destination also create a permission? This would be a change from the Applicability, Introduction, and UNSAF considerations as I read them. There is a lot of text in those sections about how we only create a permission when we have sent data to that target. >> - Data sent to a peer (via send Indications and >> unencapsulated data sent to the active destination) by the >> TURN client refresh the relevant permission. Data to one >> permission does not refresh other permissions associated with >> the same binding. > > Sounds good. > >> - The expected timeout interval for all permissions for an >> allocation is conveyed from the server to the client using >> the REFRESH-INTERVAL attribute in an initial successful >> Allocate Response. > > How does this relate to LIFETIME (see above)? > >> - The active destination is changed only with the Set Active >> Destination Request for an allocation. The active destination >> is completely independent of any permissions. > > There's some text about the Set Active Destination Request creating a > permission in section 9.2 that's been floating about on the list as > being used to allow an originator to tell the TURN server to allow > traffic from that destination. This would make it possible for a > permission to be created without requiring the originator to generate > traffic to the actual intended destination. I think this should be > allowed. Are you proposing changing this? can you paste that into this thread please? >> 2. SetActiveDestination should not be limited to existing >> permissions Current text in some places says that the active >> destination needs to be an existing permission. This is >> actually unnecessary however, and loosening this restriction >> is useful. >> Take the case where the TURN client receives a SIP INVITE >> with an offer, and the TURN client wishes to accept the >> offer. The TURN client should be able to set the active >> destination immediately before issuing its first Send request >> (to this destination). Using this order of operations insures >> that the TURN client receives all data traffic >> unencapsulated. This provides for more consistent bandwidth >> usage in this case. > > This does not (to me) appear to mesh with some of the points you've > made > above. Can you be more specific about that? This proposed change makes the active destination used by the TURN server only for deciding when to send unwrapped data and to decide how to process unwrapped data it receives. You can set the active destination to anything you'd like. IIF traffic is received and there is a permission (because you sent traffic there) it gets wrapped in a Data indication unless it was received from the active destination. Also, if you set the active destination, there may be no need to wrap your first bit of outgoing data in a Send request. > I thought paragraph 5 on page 19 of the draft made the > expectation pretty clear: > > If the Set Active Destination request contains a REMOTE-ADDRESS > attribute, the IP address contained within it is added to the > permissions for this allocation, if it was not already present. This paragraph is later contradicted a few paragraphs later. We need to change one of the paragraphs. >> The proposal is to change the current text to completely >> decouple the active destination from any permissions. A >> permission controls whether traffic flows. The active >> destination controls whether traffic flowing over a binding >> is encapsulated of not. >> >> An alternative to this proposal is to create a new permission >> if no permission for the active destination exists. The >> problem is that this does not result in sending any data to >> the peer (as described in the applicability statement and >> UNSAF considerations), it is completely implicit behavior, >> and the opposite operation (clearing the active destination) >> does not delete permissions. > > Why not add an operation to explicitly clear the active destination > then? We can clear the active destination just fine now, its just that that has no effect on permissions. What we don't have is a way to explicitly delete a permission. I proposed a Close Binding Request verb back in Montreal and there was pretty overwhelming reaction to get rid of it. >> 3. SetActiveDestination changing destinations Do you have any comments on proposals 3 or 4? thanks, -rohan >> Currently there are several pages of text devoted to a timer >> based state machine that needs to be implemented on both the >> server and the client to handle the case of switching the >> active destination from one address to another. The problem >> is that over UDP, the client cannot tell which >> unencapsulated data is from the old active destination vs. >> the new active destination. >> >> However, requiring timers and a state machine on the server >> is a significant implementation burden which provides no >> benefit for the TURN server or its administrative domain. >> >> The proposal is to put this problem completely into the hands >> of the client. Some clients may never wish to change the >> active destination for example and will have no need to >> implement anything special. >> Those clients that want to change the active destination over >> UDP are required to clear the active destination, wait for an >> appropriate interval (5 seconds is suggested), then set the >> active destination to the new address. >> >> Specific proposed text for items 2 and 3 and also delete the TIMER-VAL >> attribute: >> >>
> title="Client Behavior"> The Set Active Destination >> address allows the client to create an optimized relay >> function between it and the server. When the server receives >> packets from a particular preferred external client, the >> server will forward those packets towards the client without >> encapsulating them in a Data Indication. Similarly, the >> client can send non-STUN packets to the server without >> encapsulation, and these are forwarded to the external >> client. Sending and receiving data in unencapsulated form is >> critical for efficiency purposes. One of the primary use >> cases for the STUN relay usage is in support of Voice over IP >> (VoIP), which uses very small UDP packets to begin with. The >> extra overhead of an additional layer of encapsulation is >> considered unacceptable. >> >> The Set Active Destination request is used by the client to >> provide the identity of this preferred external client. The >> Set Active Destination address MAY contain a REMOTE-ADDRESS >> attribute. This attribute, when present, provides the address >> of the preferred external client to the server. When absent, >> it clears the value of the preferred external client. This >> address has no effect on the existence of any permissions. >> >> The client MUST NOT send a Set Active Destination request >> with a REMOTE-ADDRESS attribute over an unreliable link (ex: >> UDP) if an active destination is already set for that >> allocation. If the client wishes to set a new active >> destination, it MUST wait until 5 seconds after a successful >> response is received to a Set Destination Request removing >> the active destination. Failure to wait could cause the >> client to receive and attribute late data forwarded by the >> STUN relay server to the wrong peer. >> >> Consider the case where the active destination is >> set, and the server is relaying packets towards the client. >> The client knows the IP address and port where the packets >> came from - the current value of the active destination. The >> client issues a Set Active Destination Request to change the >> active destination, and receives a response. A moment later, >> a data packet is received, not encapsulated in a STUN Data >> Indication. What is the source if this packet? Is it the >> active destination that existed prior to the Set Active >> Destination request, or the one after? If the transport >> between the client and the STUN server is not reliable, there >> is no way to know.
>> >>
>> >> The Set Active Destination Request is used by a client to set >> the forwarding destination of all data that is not >> encapsulated in STUN Send Indications. In addition, when a >> matching permission is present, all data received from that >> external client will be forwarded to the STUN client without >> being encapsulated in a Data Indication. This request does >> not modify any permissions. >> >> The request MUST be authenticated using the same shared >> secret as the one associated with the allocation, or be >> authenticated using a short term password derived from that >> shared secret. If the request was authenticated but not with >> such a matching credential, the server MUST generate an error >> response with a 441 response code. >> >> If the Set Active Destination request does not contain a >> REMOTE-ADDRESS attribute, the value of the active destination >> is cleared. If the Set Active Destination request contains a >> REMOTE-ADDRESS attribute, and the active destination is not >> set, the active destination is set to that IP address and >> port. If an active destination is already set, and the >> request was received over a reliable transport, the active >> destination is changed to the new value. If the active >> destination is already set and the request was received over >> UDP, the Set Active Destination request is rejected with a >> 439 Active Destination Already Set error response. This >> prevents the race condition described in the previous section. >> >>
>>
>> >> 4. Opening TCP permissions >> >> Currently TCP to TCP traffic between TURN servers requires >> the TURN servers to implement simultaneous open. >> >> SYN -> >> <- SYN >> SYN-ACK -> >> <- ACK >> >> Option A is to leave this as is and to clarify this >> non-obvious implication to implementors (you cannot receive >> an incoming connection unless you first try to open one with >> the Connect request. Option B is to include an explicit Open >> Permission Request to create a specific permission for the >> TURN server to receive a TCP SYN from one specific IP address >> and port number. >> >> I will implement Option A unless there is strong desire on >> the list to do something else. >> >> thanks, >> -rohan >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave >> _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 23 12:41:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9PYo-00059d-3V; Tue, 23 Jan 2007 12:35:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9PYk-00056z-Fn for behave@ietf.org; Tue, 23 Jan 2007 12:35:50 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9PXy-0002yi-Jd for behave@ietf.org; Tue, 23 Jan 2007 12:35:03 -0500 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l0NHY2Yl015252; Tue, 23 Jan 2007 10:34:02 -0700 (MST) Received: from srvxchg.cablelabs.com (10.5.0.20) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com); Tue, 23 Jan 2007 10:34:01 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] TURN major issues and proposed fixes Date: Tue, 23 Jan 2007 10:34:01 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] TURN major issues and proposed fixes Thread-Index: Acc8SCPIsU2Oz1BHTEaMkXoOwBOGEwCygTJg From: "Kevin Johns" To: "Rohan Mahy" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: Rohan Mahy X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Rohan, Two questions on your proposed changes: I do have some concern on requiring the client to refresh the allocation. What is the driver for having the client refresh the allocation even in the presence of relayed data? The new text implies that only a single active destination is allowed. Is my read correct or can the client set multiple active destinations? Kevin -----Original Message----- From: Rohan Mahy [mailto:rohan.mahy@gmail.com]=20 Sent: Friday, January 19, 2007 9:03 PM To: behave@ietf.org Cc: Rohan Mahy Subject: [BEHAVE] TURN major issues and proposed fixes Hi Folks, The following issues have all come up from implementors of TURN and are big enough issues that I wanted to get some list feedback before incorporating these in a new rev. 1. Allocations, Bindings, Permissions, Timeouts, and the Active Destination. The current text is still a bit fuzzy and inconsistent about what is a difference between permission and a binding and what keeps bindings open. Also, many implementors have expressed confusion between the behavior of an ordinary NAT binding and a "STUN Relay binding", so I am proposing we skip the binding terminology in favor of "permission". Much of the following came from consensus at one of the meetings. I've come up with the following proposal which fills out a consistent set of rules: - Remove the terminology "binding" altogether inside the TURN server. Only use "binding" when talking about a "real" NAT (ex: between the TURN client and the TURN server) - All requests and indications except for initial Allocation requests are sent in the context of a matching valid allocation, otherwise they are rejected (requests) or discarded silently (Indications). - Allocations are explicitly refreshed via subsequent allocation requests. Allocation timeout values are on the order of minutes. Send and Data indications do not refresh Allocations. Allocation timers are based on the LIFETIME attribute. - Each allocation can have zero or more permissions - When allocations are destroyed all related permissions are deleted. - Permissions are only created by Send Indications over UDP and Connect Requests over TCP. - Data sent to a peer (via send Indications and unencapsulated data sent to the active destination) by the TURN client refresh the relevant permission. Data to one permission does not refresh other permissions associated with the same binding. - The expected timeout interval for all permissions for an allocation is conveyed from the server to the client using the REFRESH-INTERVAL attribute in an initial successful Allocate Response. - The active destination is changed only with the Set Active Destination Request for an allocation. The active destination is completely independent of any permissions. 2. SetActiveDestination should not be limited to existing permissions Current text in some places says that the active destination needs to be an existing permission. This is actually unnecessary however, and loosening this restriction is useful. Take the case where the TURN client receives a SIP INVITE with an offer, and the TURN client wishes to accept the offer. The TURN client should be able to set the active destination immediately before issuing its first Send request (to this destination). Using this order of operations insures that the TURN client receives all data traffic unencapsulated. This provides for more consistent bandwidth usage in this case. The proposal is to change the current text to completely decouple the active destination from any permissions. A permission controls whether traffic flows. The active destination controls whether traffic flowing over a binding is encapsulated of not. An alternative to this proposal is to create a new permission if no permission for the active destination exists. The problem is that this does not result in sending any data to the peer (as described in the applicability statement and UNSAF considerations), it is completely implicit behavior, and the opposite operation (clearing the active destination) does not delete permissions. 3. SetActiveDestination changing destinations Currently there are several pages of text devoted to a timer based state machine that needs to be implemented on both the server and the client to handle the case of switching the active destination from one address to another. The problem is that over UDP, the client cannot tell which unencapsulated data is from the old active destination vs. the new active destination. However, requiring timers and a state machine on the server is a significant implementation burden which provides no benefit for the TURN server or its administrative domain. The proposal is to put this problem completely into the hands of the client. Some clients may never wish to change the active destination for example and will have no need to implement anything special. Those clients that want to change the active destination over UDP are required to clear the active destination, wait for an appropriate interval (5 seconds is suggested), then set the active destination to the new address. Specific proposed text for items 2 and 3 and also delete the TIMER-VAL attribute:
The Set Active Destination address allows the client to create an optimized relay function between it and the server. When the server receives packets from a particular preferred external client, the server will forward those packets towards the client without encapsulating them in a Data Indication. Similarly, the client can send non-STUN packets to the server without encapsulation, and these are forwarded to the external client. Sending and receiving data in unencapsulated form is critical for efficiency purposes. One of the primary use cases for the STUN relay usage is in support of Voice over IP (VoIP), which uses very small UDP packets to begin with. The extra overhead of an additional layer of encapsulation is considered unacceptable. The Set Active Destination request is used by the client to provide the identity of this preferred external client. The Set Active Destination address MAY contain a REMOTE-ADDRESS attribute. This attribute, when present, provides the address of the preferred external client to the server. When absent, it clears the value of the preferred external client. This address has no effect on the existence of any permissions. The client MUST NOT send a Set Active Destination request with a REMOTE-ADDRESS attribute over an unreliable link (ex: UDP) if an active destination is already set for that allocation. If the client wishes to set a new active destination, it MUST wait until 5 seconds after a successful response is received to a Set Destination Request removing the active destination. Failure to wait could cause the client to receive and attribute late data forwarded by the STUN relay server to the wrong peer. Consider the case where the active destination is set, and the server is relaying packets towards the client. The client knows the IP address and port where the packets came from - the current value of the active destination. The client issues a Set Active Destination Request to change the active destination, and receives a response. A moment later, a data packet is received, not encapsulated in a STUN Data Indication. What is the source if this packet? Is it the active destination that existed prior to the Set Active Destination request, or the one after? If the transport between the client and the STUN server is not reliable, there is no way to know.
The Set Active Destination Request is used by a client to set the forwarding destination of all data that is not encapsulated in STUN Send Indications. In addition, when a matching permission is present, all data received from that external client will be forwarded to the STUN client without being encapsulated in a Data Indication. This request does not modify any permissions. The request MUST be authenticated using the same shared secret as the one associated with the allocation, or be authenticated using a short term password derived from that shared secret. If the request was authenticated but not with such a matching credential, the server MUST generate an error response with a 441 response code. If the Set Active Destination request does not contain a REMOTE-ADDRESS attribute, the value of the active destination is cleared. If the Set Active Destination request contains a REMOTE-ADDRESS attribute, and the active destination is not set, the active destination is set to that IP address and port. If an active destination is already set, and the request was received over a reliable transport, the active destination is changed to the new value. If the active destination is already set and the request was received over UDP, the Set Active Destination request is rejected with a 439 Active Destination Already Set error response. This prevents the race condition described in the previous section.
4. Opening TCP permissions Currently TCP to TCP traffic between TURN servers requires the TURN servers to implement simultaneous open. SYN -> <- SYN SYN-ACK -> <- ACK Option A is to leave this as is and to clarify this non-obvious implication to implementors (you cannot receive an incoming connection unless you first try to open one with the Connect request. Option B is to include an explicit Open Permission Request to create a specific permission for the TURN server to receive a TCP SYN from one specific IP address and port number. I will implement Option A unless there is strong desire on the list to do something else. thanks, -rohan _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 24 00:12:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9aQq-00077r-8f; Wed, 24 Jan 2007 00:12:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9aQo-00077i-BR for behave@ietf.org; Wed, 24 Jan 2007 00:12:22 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9aQm-00061H-5l for behave@ietf.org; Wed, 24 Jan 2007 00:12:20 -0500 Received: from [131.161.248.88] (open-131-161-248-88.cliq.com [131.161.248.88]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l0O5CB231861; Tue, 23 Jan 2007 21:12:11 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8df63378a5e5df8063b85a6cdcd864d5@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [BEHAVE] TURN major issues and proposed fixes Date: Tue, 23 Jan 2007 21:12:00 -0800 To: "Kevin Johns" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: Rohan Mahy , behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi Kevin, On Jan 23, 2007, at 9:34, Kevin Johns wrote: > Rohan, > > Two questions on your proposed changes: > > I do have some concern on requiring the client to refresh the > allocation. What is the driver for having the client refresh the > allocation even in the presence of relayed data? A few come to mind: 1. The WG came to consensus on general principal that an explicit reallocation mechanism was preferable to an implicit one. 2. Keeping timers for permissions and allocations conjoined is messy. What happens after all the permissions time out? That MUST NOT cause the allocation to suddenly expire. To get sane behavior, the TURN server would need to start the allocation timer after all the permissions went away. This seems overly complicated on the server side. 3. If a TURN client has an open allocation, and there is no explicit reallocation required, another host that spoofs the client's source IP address can send traffic through the TURN server toward an established peer indefinitely. If reallocation is required, the attacker would be limited to a fixed period of time unless the attacker had the client's TURN credentials. > The new text implies that only a single active destination is allowed. > Is my read correct or can the client set multiple active destinations? By definition, there can only be one active destination. Note that the active destination does not mean it is the only destination for which traffic can be flowing. The active destination means the only host for which end-to-end data is not wrapped in Send and Data indications. thanks, -rohan > Kevin > > -----Original Message----- > From: Rohan Mahy [mailto:rohan.mahy@gmail.com] > Sent: Friday, January 19, 2007 9:03 PM > To: behave@ietf.org > Cc: Rohan Mahy > Subject: [BEHAVE] TURN major issues and proposed fixes > > Hi Folks, > > The following issues have all come up from implementors of TURN and > are big enough issues that I wanted to get some list feedback before > incorporating these in a new rev. > > 1. Allocations, Bindings, Permissions, Timeouts, and the Active > Destination. > > The current text is still a bit fuzzy and inconsistent about what is a > difference between permission and a binding and what keeps bindings > open. Also, many implementors have expressed confusion between the > behavior of an ordinary NAT binding and a "STUN Relay binding", so I > am proposing we skip the binding terminology in favor of "permission". > Much of the following came from consensus at one of the meetings. I've > come up with the following proposal which fills out a consistent set > of rules: > - Remove the terminology "binding" altogether inside the TURN server. > Only use "binding" when talking about a "real" NAT (ex: between the > TURN client and the TURN server) > - All requests and indications except for initial Allocation requests > are sent in the context of a matching valid allocation, otherwise they > are rejected (requests) or discarded silently (Indications). > - Allocations are explicitly refreshed via subsequent allocation > requests. Allocation timeout values are on the order of minutes. Send > and Data indications do not refresh Allocations. Allocation timers are > based on the LIFETIME attribute. > - Each allocation can have zero or more permissions > - When allocations are destroyed all related permissions are deleted. > - Permissions are only created by Send Indications over UDP and > Connect Requests over TCP. > - Data sent to a peer (via send Indications and unencapsulated data > sent to the active destination) by the TURN client refresh the > relevant permission. Data to one permission does not refresh other > permissions associated with the same binding. > - The expected timeout interval for all permissions for an allocation > is conveyed from the server to the client using the REFRESH-INTERVAL > attribute in an initial successful Allocate Response. > - The active destination is changed only with the Set Active > Destination Request for an allocation. The active destination is > completely independent of any permissions. > > 2. SetActiveDestination should not be limited to existing permissions > Current text in some places says that the active destination needs to > be an existing permission. This is actually unnecessary however, and > loosening this restriction is useful. > Take the case where the TURN client receives a SIP INVITE with an > offer, and the TURN client wishes to accept the offer. The TURN client > should be able to set the active destination immediately before > issuing its first Send request (to this destination). Using this order > of operations insures that the TURN client receives all data traffic > unencapsulated. This provides for more consistent bandwidth usage in > this case. > > The proposal is to change the current text to completely decouple the > active destination from any permissions. A permission controls > whether traffic flows. The active destination controls whether > traffic flowing over a binding is encapsulated of not. > > An alternative to this proposal is to create a new permission if no > permission for the active destination exists. The problem is that > this does not result in sending any data to the peer (as described in > the applicability statement and UNSAF considerations), it is > completely implicit behavior, and the opposite operation (clearing the > active destination) does not delete permissions. > > 3. SetActiveDestination changing destinations > > Currently there are several pages of text devoted to a timer based > state machine that needs to be implemented on both the server and the > client to handle the case of switching the active destination from one > address to another. The problem is that over UDP, the client cannot > tell which unencapsulated data is from the old active destination vs. > the new active destination. > > However, requiring timers and a state machine on the server is a > significant implementation burden which provides no benefit for the > TURN server or its administrative domain. > > The proposal is to put this problem completely into the hands of the > client. Some clients may never wish to change the active destination > for example and will have no need to implement anything special. > Those clients that want to change the active destination over UDP are > required to clear the active destination, wait for an appropriate > interval (5 seconds is suggested), then set the active destination to > the new address. > > Specific proposed text for items 2 and 3 and also delete the TIMER-VAL > attribute: > >
>
> > The Set Active Destination address allows the client to create an > optimized relay function between it and the server. When the server > receives packets from a particular preferred external client, the > server will forward those packets towards the client without > encapsulating them in a Data Indication. Similarly, the client can > send non-STUN packets to the server without encapsulation, and these > are forwarded to the external client. Sending and receiving data in > unencapsulated form is critical for efficiency purposes. One of the > primary use cases for the STUN relay usage is in support of Voice over > IP (VoIP), which uses very small UDP packets to begin with. The extra > overhead of an additional layer of encapsulation is considered > unacceptable. > > The Set Active Destination request is used by the client to provide > the identity of this preferred external client. The Set Active > Destination address MAY contain a REMOTE-ADDRESS attribute. This > attribute, when present, provides the address of the preferred > external client to the server. When absent, it clears the value of the > preferred external client. This address has no effect on the existence > of any permissions. > > The client MUST NOT send a Set Active Destination request with a > REMOTE-ADDRESS attribute over an unreliable link (ex: UDP) if an > active destination is already set for that allocation. If the client > wishes to set a new active destination, it MUST wait until 5 seconds > after a successful response is received to a Set Destination Request > removing the active destination. Failure to wait could cause the > client to receive and attribute late data forwarded by the STUN relay > server to the wrong peer. > > Consider the case where the active destination is set, and > the server is relaying packets towards the client. The client knows > the IP address and port where the packets came from - the current > value of the active destination. The client issues a Set Active > Destination Request to change the active destination, and receives a > response. A moment later, a data packet is received, not encapsulated > in a STUN Data Indication. What is the source if this packet? Is it > the active destination that existed prior to the Set Active > Destination request, or the one after? If the transport between the > client and the STUN server is not reliable, there is no way to > know. > >
> >
> > The Set Active Destination Request is used by a client to set the > forwarding destination of all data that is not encapsulated in STUN > Send Indications. In addition, when a matching permission is present, > all data received from that external client will be forwarded to the > STUN client without being encapsulated in a Data Indication. This > request does not modify any permissions. > > The request MUST be authenticated using the same shared secret as the > one associated with the allocation, or be authenticated using a short > term password derived from that shared secret. If the request was > authenticated but not with such a matching credential, the server MUST > generate an error response with a 441 response code. > > If the Set Active Destination request does not contain a > REMOTE-ADDRESS attribute, the value of the active destination is > cleared. If the Set Active Destination request contains a > REMOTE-ADDRESS attribute, and the active destination is not set, the > active destination is set to that IP address and port. If an active > destination is already set, and the request was received over a > reliable transport, the active destination is changed to the new > value. If the active destination is already set and the request was > received over UDP, the Set Active Destination request is rejected with > a 439 Active Destination Already Set error response. This prevents > the race condition described in the previous section. > >
>
> > 4. Opening TCP permissions > > Currently TCP to TCP traffic between TURN servers requires the TURN > servers to implement simultaneous open. > > SYN -> > <- SYN > SYN-ACK -> > <- ACK > > Option A is to leave this as is and to clarify this non-obvious > implication to implementors (you cannot receive an incoming connection > unless you first try to open one with the Connect request. Option B > is to include an explicit Open Permission Request to create a specific > permission for the TURN server to receive a TCP SYN from one specific > IP address and port number. > > I will implement Option A unless there is strong desire on the list to > do something else. > > thanks, > -rohan > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 24 14:48:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9o6e-0000ql-Tj; Wed, 24 Jan 2007 14:48:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9o6d-0000pU-JQ; Wed, 24 Jan 2007 14:48:27 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9o1y-0001Vh-MV; Wed, 24 Jan 2007 14:43:40 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 24 Jan 2007 11:43:38 -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 l0OJhcim026812; Wed, 24 Jan 2007 11:43:38 -0800 Received: from dwingwxp (rtp-vpn3-272.cisco.com [10.82.217.18]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0OJhVho004424; Wed, 24 Jan 2007 11:43:32 -0800 (PST) From: "Dan Wing" To: , Date: Wed, 24 Jan 2007 11:43:26 -0800 Message-ID: <015201c73fef$f0fc7900$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acc/7+pIYyPyXe++QkyaABxXjX3fXA== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=845; t=1169667818; x=1170531818; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20WGLC=20draft-ietf-behave-tcp-04=20starts=20now |Sender:=20; bh=uwMh9klO1ZkA7wz3W0XfgMv4QZ0CyNsYOzx1wnWI66M=; b=AUvU22KAKNOkqr7xKyqZNUgHCB2hVWUQeo1OFO3fDmhZ7MWvtn6ZkHaKLmQA7XIEBnTue3X9 C8RLwC1Xo/wq7Fskq9aep23Q1a/VDLFA7jgdKCIAk5axh1PcVFlego2z; Authentication-Results: sj-dkim-6; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [BEHAVE] WGLC draft-ietf-behave-tcp-04 starts now X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org BEHAVE, TCPM: We are starting a two-week working group last call in the BEHAVE working group for a TCP-related document, draft-ietf-behave-tcp-04, which describes how to NAT TCP traffic. This document is expected to become a BCP. http://www.ietf.org/internet-drafts/draft-ietf-behave-tcp-04.txt Abstract: This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and on-line games, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. Please send comments to the authors (CC'd) or behave@ietf.org. WGLC on this document ends on Wednesday, 7-Feb-2007. -Dan Wing chair, BEHAVE working group _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Jan 28 07:18:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HB8yk-0003MD-5H; Sun, 28 Jan 2007 07:17:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HB8yi-0003M7-EX for behave@ietf.org; Sun, 28 Jan 2007 07:17:48 -0500 Received: from maildialog.com ([195.159.98.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HB8yc-0005mx-UD for behave@ietf.org; Sun, 28 Jan 2007 07:17:48 -0500 Received: from [84.209.226.67] (helo=[10.0.0.4]) by maildialog.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51-maildialog) id 1HB8yX-0007rM-3t for behave@ietf.org; Sun, 28 Jan 2007 12:17:37 +0000 Message-ID: <45BC93CC.30909@db.org> Date: Sun, 28 Jan 2007 13:15:08 +0100 From: "Alfred E. Heggestad" User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: behave@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: [BEHAVE] Difference between STUN Binding Discovery and NAT Keepalive X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi I am trying to understand the difference between the two STUN usages defined in rfc3489-bis05, in sections 12.1 and 12.2, Binding Discovery and NAT Keepalive. My current understanding of the two is as follows: * Binding Discovery: - Used to get publicly mapped address:port - Used for both SIP and RTP/RTCP - Backwards compatible with RFC3489 - authentication and message integrity is RECOMMENDED - requests SHOULD be challenged * NAT Keepalive - periodic keepalive on same flow - detection of flow failure - multiplexed sockets with application - client SHOULD NOT use message integrity - server SHOULD not authenticate - used by outbound draft for flow keepalive this leads to the following question: How can a STUN server providing both usages differentiate between the two usages, when both send a STUN Binding Request? If we assume that for a particular deployed domain, there are two STUN servers, one multiplexed with SIP on port 5060 and one standalone STUN server on port 3478. In this case the two servers know which usage they implement and can respond accordingly. However, the information from the Binding Discovery STUN server on port 3478 is totally useless if the UA is behind symmetrical NAT.. For a UA behind NAT to retrieve its publicly mapped address, with respect to the SIP server, the SIP and STUN traffic must follow exactly the same flow from UA via NAT to SIP/STUN server. From rfc3489-bis05: 12.2.7. Client Procedures If the STUN Response indicates the client's mapped address has changed from the client's expected mapped address, the client SHOULD inform other applications of its new mapped address. For example, a SIP client could use the binding discovery usage to obtain a new mapped address, and then register it using SIP registration procedures. This scenario will not work for symmetrical NATs. Typically in my UA one usage will be enough, periodically sending STUN Binding Request messages to the SIP server, to get the publicly mapped address:port AND keep the flow alive. If the SIP server I am currently talking to does not have the "sip-stun" option tag, I could always locate the STUN server for that domain using DNS SRV, but that will not help if my UA is behind symmetrical NAT.. hopefully all my questions made sense.. /alfred _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 30 08:13:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBsnF-0007wH-8E; Tue, 30 Jan 2007 08:13:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBsnE-0007w3-3c for behave@ietf.org; Tue, 30 Jan 2007 08:13:00 -0500 Received: from nf-out-0910.google.com ([64.233.182.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBsnB-0007vO-Dy for behave@ietf.org; Tue, 30 Jan 2007 08:13:00 -0500 Received: by nf-out-0910.google.com with SMTP id l36so197992nfa for ; Tue, 30 Jan 2007 05:12:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Xu7XR2x1Jve+ufQGweRTSDsLp1IMj8I9CKIu8EUA+yQ0drk0wbWjlhqhnOfQXP+LtnroOf8dfa7Ery6FYCWUs9nxnuGs1Ig2O3RUregJUUHKLSS63GB+lA3IpTqBvPceswHsCbxS3SM+oQptrX5awrL7uUjibwq4JFxVEcjXpbw= Received: by 10.49.10.3 with SMTP id n3mr714753nfi.1170162771896; Tue, 30 Jan 2007 05:12:51 -0800 (PST) Received: by 10.66.243.7 with HTTP; Tue, 30 Jan 2007 05:12:51 -0800 (PST) Message-ID: <876aa5be0701300512k16298d44nb0b01d283d850a59@mail.gmail.com> Date: Tue, 30 Jan 2007 13:12:51 +0000 From: Vikas To: "Alfred E. Heggestad" Subject: Re: [BEHAVE] Difference between STUN Binding Discovery and NAT Keepalive In-Reply-To: <45BC93CC.30909@db.org> MIME-Version: 1.0 References: <45BC93CC.30909@db.org> X-Spam-Score: 1.0 (+) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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="===============2021185805==" Errors-To: behave-bounces@ietf.org --===============2021185805== Content-Type: multipart/alternative; boundary="----=_Part_114425_17542560.1170162771834" ------=_Part_114425_17542560.1170162771834 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 28/01/07, Alfred E. Heggestad wrote: > > Hi > > > I am trying to understand the difference between the two STUN usages > defined in rfc3489-bis05, in sections 12.1 and 12.2, Binding Discovery > and NAT Keepalive. My current understanding of the two is as follows: > > > * Binding Discovery: > - Used to get publicly mapped address:port > - Used for both SIP and RTP/RTCP > - Backwards compatible with RFC3489 > - authentication and message integrity is RECOMMENDED > - requests SHOULD be challenged > > * NAT Keepalive > - periodic keepalive on same flow > - detection of flow failure > - multiplexed sockets with application > - client SHOULD NOT use message integrity > - server SHOULD not authenticate > - used by outbound draft for flow keepalive > > > this leads to the following question: > > How can a STUN server providing both usages differentiate between the > two usages, when both send a STUN Binding Request? >>>>Before authentication it can see the request type and can challenge if it is a binding request(see section 6 - A class of 0 is a Request, a class of 1 is an indication, a class of 2 is a success response, and a class of 3 is an error response). If we assume that for a particular deployed domain, there are two STUN > servers, one multiplexed with SIP on port 5060 and one standalone STUN > server on port 3478. In this case the two servers know which usage they > implement and can respond accordingly. However, the information from the > Binding Discovery STUN server on port 3478 is totally useless if the UA > is behind symmetrical NAT.. For a UA behind NAT to retrieve its publicly > mapped address, with respect to the SIP server, the SIP and STUN traffic > must follow exactly the same flow from UA via NAT to SIP/STUN server. > > > From rfc3489-bis05: > > > 12.2.7. Client Procedures > > If the STUN Response indicates the client's mapped address has > changed from the client's expected mapped address, the client SHOULD > inform other applications of its new mapped address. For example, a > SIP client could use the binding discovery usage to obtain a new > mapped address, and then register it using SIP registration > procedures. > > > This scenario will not work for symmetrical NATs. > > >>>>>>This functionality can't be achieved only by these two STUN usage.You may have to implement ICE for that.(see section 1- It will allow incoming UDP > packets through NAT, but only through a subset of existing NAT types. > In particular, the STUN binding usage by itself does not enable > incoming UDP packets through NATs whose mapping property is address > dependent or address and port dependent [14]) > > > > Typically in my UA one usage will be enough, periodically sending STUN > Binding Request messages to the SIP server, to get the publicly mapped > address:port AND keep the flow alive. If the SIP server I am currently > talking to does not have the "sip-stun" option tag, I could always > locate the STUN server for that domain using DNS SRV, but that will not > help if my UA is behind symmetrical NAT.. > > > hopefully all my questions made sense.. > > > > /alfred > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > ------=_Part_114425_17542560.1170162771834 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 28/01/07, Alfred E. Heggestad <aeh@db.org> wrote:
Hi


I am trying to understand the difference between the two STUN usages
defined in rfc3489-bis05, in sections 12.1 and 12.2, Binding Discovery
and NAT Keepalive. My current understanding of the two is as follows:


* Binding Discovery:
   - Used to get publicly mapped address:port
   - Used for both SIP and RTP/RTCP
   - Backwards compatible with RFC3489
   - authentication and message integrity is RECOMMENDED
   - requests SHOULD be challenged

* NAT Keepalive
   - periodic keepalive on same flow
   - detection of flow failure
   - multiplexed sockets with application
   - client SHOULD NOT use message integrity
   - server SHOULD not authenticate
   - used by outbound draft for flow keepalive


this leads to the following question:

   How can a STUN server providing both usages differentiate between the
   two usages, when both send a STUN Binding Request?

>>>>Before authentication it can see the request type and can challenge if it is a binding request(see section 6 - A class of 0 is a

   Request, a class of 1 is an indication, a class of 2 is a success response, and a class of 3 is an error response).
 

If we assume that for a particular deployed domain, there are two STUN
servers, one multiplexed with SIP on port 5060 and one standalone STUN
server on port 3478. In this case the two servers know which usage they
implement and can respond accordingly. However, the information from the
Binding Discovery STUN server on port 3478 is totally useless if the UA
is behind symmetrical NAT.. For a UA behind NAT to retrieve its publicly
mapped address, with respect to the SIP server, the SIP and STUN traffic
must follow exactly the same flow from UA via NAT to SIP/STUN server.


From rfc3489-bis05:


12.2.7.  Client Procedures

    If the STUN Response indicates the client's mapped address has
    changed from the client's expected mapped address, the client SHOULD
    inform other applications of its new mapped address.  For example, a
    SIP client could use the binding discovery usage to obtain a new
    mapped address, and then register it using SIP registration
    procedures.


This scenario will not work for symmetrical NATs.
>>>>>>This functionality can't be achieved only by these two STUN usage.You may have to implement ICE for that.(see section 1- It will allow incoming UDP

   packets through NAT, but only through a subset of existing NAT types.
   In particular, the STUN binding usage by itself does not enable
   incoming UDP packets through NATs whose mapping property is address

   dependent or address and port dependent [14])


Typically in my UA one usage will be enough, periodically sending STUN
Binding Request messages to the SIP server, to get the publicly mapped
address:port AND keep the flow alive. If the SIP server I am currently
talking to does not have the "sip-stun" option tag, I could always
locate the STUN server for that domain using DNS SRV, but that will not
help if my UA is behind symmetrical NAT..


hopefully all my questions made sense..



/alfred

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

------=_Part_114425_17542560.1170162771834-- --===============2021185805== 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 --===============2021185805==-- From behave-bounces@ietf.org Tue Jan 30 13:52:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBy5a-0004gx-DH; Tue, 30 Jan 2007 13:52:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBy5Y-0004ga-B1 for behave@ietf.org; Tue, 30 Jan 2007 13:52:16 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBy5V-0000a9-Rn for behave@ietf.org; Tue, 30 Jan 2007 13:52:16 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 30 Jan 2007 10:52:13 -0800 X-IronPort-AV: i="4.13,258,1167638400"; d="scan'208"; a="107072322:sNHT169770816" 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 l0UIqCBM028350; Tue, 30 Jan 2007 10:52:12 -0800 Received: from dwingwxp ([10.32.240.194]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l0UIq2Uw019372; Tue, 30 Jan 2007 10:52:11 -0800 (PST) From: "Dan Wing" To: "'Alfred E. Heggestad'" , Subject: RE: [BEHAVE] Difference between STUN Binding Discovery and NAT Keepalive Date: Tue, 30 Jan 2007 10:52:02 -0800 Message-ID: <059201c7449f$c03276d0$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdC2K+c6FOOIQRzR0WSNqendBPdjABwij8Q In-Reply-To: <45BC93CC.30909@db.org> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4705; t=1170183133; x=1171047133; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20Difference=20between=20STUN=20Binding=20Di scovery=20and=20NAT=20Keepalive |Sender:=20; bh=CkWn9lnr1P2i4v0DOTi1E82L7+JD9+llHtdFdKddP8U=; b=HtaLl9KHMWKiMdYt1mlbEIJBr9SeoaX4TvGrmssT/az7YWHesZCX14Dq6UeTqt+Fu6wfAzu3 XN6HQcwncAFcxiR8ARiW44xBv/RhUoc2FhU4AOgrv+ivh15Z6U8etjzg; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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 am trying to understand the difference between the two STUN usages > defined in rfc3489-bis05, in sections 12.1 and 12.2, Binding Discovery > and NAT Keepalive. My current understanding of the two is as follows: > > > * Binding Discovery: > - Used to get publicly mapped address:port > - Used for both SIP and RTP/RTCP > - Backwards compatible with RFC3489 > - authentication and message integrity is RECOMMENDED > - requests SHOULD be challenged The last two bullets provide protection against an attacker that is on the path between your STUN client and your STUN server. > * NAT Keepalive > - periodic keepalive on same flow > - detection of flow failure > - multiplexed sockets with application > - client SHOULD NOT use message integrity > - server SHOULD not authenticate > - used by outbound draft for flow keepalive One nuance with NAT Keepalive is that in the most recent version of ICE (draft-ietf-mmusic-ice-13.txt), the NAT keepalive used in ICE was changed from a Binding Discovery / Binding Response exchange to an Indication. The Indication is a unidirectional STUN message, which has no response. draft-ietf-behave-rfc3489bis has not yet been updated to align with this change to draft-ietf-mmusic-ice-13. > this leads to the following question: > > How can a STUN server providing both usages differentiate > between the two usages, when both send a STUN Binding Request? The STUN server listening on UDP/5060 will only receive STUN messages for the Keepalive Usage. > If we assume that for a particular deployed domain, there are two > STUN servers, one multiplexed with SIP on port 5060 and one > standalone STUN server on port 3478. In this case the two servers > know which usage they implement and can respond accordingly. > However, the information from the Binding Discovery STUN server on > port 3478 is totally useless if the UA is behind symmetrical NAT.. It's not totally useless -- even if you're behind a symmetric NAT you can still establish bi-directional UDP communication with another endpoint if that other endpoint knows its transport address. However, if that other endpoint is _also_ behind a symmetric NAT, you a media relay (TURN server or SBC) is necessary. ICE describes the procedures to do this. > For a UA behind NAT to retrieve its publicly mapped address, with > respect to the SIP server, the SIP and STUN traffic must follow > exactly the same flow from UA via NAT to SIP/STUN server. A SIP client, which wants to learn its public transport address for SIP traffic, doesn't need to talk to the STUN server listening on UDP/3478 -- it only needs to talk to the STUN server embedded with its SIP proxy on UDP/5060. Are you concerned about the different SHOULDs around message integrity for the Binding Discovery usage? > From rfc3489-bis05: > > > 12.2.7. Client Procedures > > If the STUN Response indicates the client's mapped address has > changed from the client's expected mapped address, the > client SHOULD > inform other applications of its new mapped address. For > example, a > SIP client could use the binding discovery usage to obtain a new > mapped address, and then register it using SIP registration > procedures. > > > This scenario will not work for symmetrical NATs. It will work if the STUN Binding Request is sent to the same port as all SIP traffic (UDP/5060), and demultiplexed by the SIP proxy. > Typically in my UA one usage will be enough, periodically sending STUN > Binding Request messages to the SIP server, to get the publicly mapped > address:port AND keep the flow alive. I just searched draft-ietf-sip-outbound-07, and can't find where it is necessary for the SIP UA to learn its public IP address and UDP port. That is, other than learning that it *changed* (which it can learn via the periodic keepalives), it seems that draft-ietf-sip-outbound-07 doesn't say the SIP UA needs to learn its public transport address using STUN. It's not necessary, anyway -- the SIP proxy knows the transport address of an incoming UDP packet when the SIP proxy receives the packet. > If the SIP server I am currently > talking to does not have the "sip-stun" option tag, I could always > locate the STUN server for that domain using DNS SRV, but > that will not help if my UA is behind symmetrical NAT.. -d > hopefully all my questions made sense.. > > > > /alfred > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 31 17:40:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCO7C-0004W8-8q; Wed, 31 Jan 2007 17:39:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCO7A-0004RD-2t for behave@ietf.org; Wed, 31 Jan 2007 17:39:40 -0500 Received: from maildialog.com ([195.159.98.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCO4Y-0006rZ-1f for behave@ietf.org; Wed, 31 Jan 2007 17:37:04 -0500 Received: from [84.209.225.83] (helo=[192.168.1.131]) by maildialog.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51-maildialog) id 1HCO4S-0000qY-Cr; Wed, 31 Jan 2007 22:36:52 +0000 Message-ID: <45C11A4D.5010208@db.org> Date: Wed, 31 Jan 2007 23:38:05 +0100 From: "Alfred E. Heggestad" User-Agent: Icedove 1.5.0.9 (X11/20061220) MIME-Version: 1.0 To: Dan Wing Subject: Re: [BEHAVE] Difference between STUN Binding Discovery and NAT Keepalive References: <059201c7449f$c03276d0$c2f0200a@amer.cisco.com> In-Reply-To: <059201c7449f$c03276d0$c2f0200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d 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 Dan, thanks for your reply, see inline. Dan Wing wrote: >> I am trying to understand the difference between the two STUN usages >> defined in rfc3489-bis05, in sections 12.1 and 12.2, Binding Discovery >> and NAT Keepalive. My current understanding of the two is as follows: >> >> >> * Binding Discovery: >> - Used to get publicly mapped address:port >> - Used for both SIP and RTP/RTCP >> - Backwards compatible with RFC3489 >> - authentication and message integrity is RECOMMENDED >> - requests SHOULD be challenged > > The last two bullets provide protection against an attacker that > is on the path between your STUN client and your STUN server. > >> * NAT Keepalive >> - periodic keepalive on same flow >> - detection of flow failure >> - multiplexed sockets with application >> - client SHOULD NOT use message integrity >> - server SHOULD not authenticate >> - used by outbound draft for flow keepalive > > One nuance with NAT Keepalive is that in the most recent version > of ICE (draft-ietf-mmusic-ice-13.txt), the NAT keepalive used > in ICE was changed from a Binding Discovery / Binding Response > exchange to an Indication. The Indication is a unidirectional > STUN message, which has no response. > > draft-ietf-behave-rfc3489bis has not yet been updated to align > with this change to draft-ietf-mmusic-ice-13. > ah, ok. is unidirectional STUN indication (sent from UA) guaranteed to work with all types of NAT boxes ? is it not so that certain NATs assume bidirectional traffic to keep the flow open? will STUN Binding Indication be a new STUN message in rfc3489bis-06 ? >> this leads to the following question: >> >> How can a STUN server providing both usages differentiate >> between the two usages, when both send a STUN Binding Request? > > The STUN server listening on UDP/5060 will only receive STUN > messages for the Keepalive Usage. > ok fair enough. >> If we assume that for a particular deployed domain, there are two >> STUN servers, one multiplexed with SIP on port 5060 and one >> standalone STUN server on port 3478. In this case the two servers >> know which usage they implement and can respond accordingly. >> However, the information from the Binding Discovery STUN server on >> port 3478 is totally useless if the UA is behind symmetrical NAT.. > > It's not totally useless -- even if you're behind a symmetric NAT > you can still establish bi-directional UDP communication with > another endpoint if that other endpoint knows its transport > address. > > However, if that other endpoint is _also_ behind a symmetric NAT, > you a media relay (TURN server or SBC) is necessary. > > ICE describes the procedures to do this. > OK maybe my question was a bit vague. I am aware of ICE/TURN and how the media/NAT can be solved by that. I was mainly asking STUN-related questions, with a view from the outbound draft ;) >> For a UA behind NAT to retrieve its publicly mapped address, with >> respect to the SIP server, the SIP and STUN traffic must follow >> exactly the same flow from UA via NAT to SIP/STUN server. > > A SIP client, which wants to learn its public transport address > for SIP traffic, doesn't need to talk to the STUN server > listening on UDP/3478 -- it only needs to talk to the STUN > server embedded with its SIP proxy on UDP/5060. > > Are you concerned about the different SHOULDs around > message integrity for the Binding Discovery usage? > Yes, agreed. To get my public SIP address I only need to send a STUN Binding Request to my SIP Proxy at UDP/5060. I am not concerned about the message integrity, I am mainly trying to understand why Binding Discover and NAT Keepalive usage cant be just one usage (i.e. the same) instead of two usages that are protocol-wise very similar .. >> From rfc3489-bis05: >> >> >> 12.2.7. Client Procedures >> >> If the STUN Response indicates the client's mapped address has >> changed from the client's expected mapped address, the >> client SHOULD >> inform other applications of its new mapped address. For >> example, a >> SIP client could use the binding discovery usage to obtain a new >> mapped address, and then register it using SIP registration >> procedures. >> >> >> This scenario will not work for symmetrical NATs. > > It will work if the STUN Binding Request is sent to the same > port as all SIP traffic (UDP/5060), and demultiplexed by the > SIP proxy. > yes. so the new section in rfc3489-bis05 12.2 NAT Keepalives is mainly a tool for outbound, and should go to UDP/5060 ? but section 12.2.7 says "...SIP client could use the *binding discovery* usage to obtain..." - why recommend that the client has to send a new STUN Binding Request, when the client at the same to has just got the new publicly mapped address:port from the current NAT Keepalive Binding Response ? >> Typically in my UA one usage will be enough, periodically sending STUN >> Binding Request messages to the SIP server, to get the publicly mapped >> address:port AND keep the flow alive. > > I just searched draft-ietf-sip-outbound-07, and can't find where > it is necessary for the SIP UA to learn its public IP address and > UDP port. That is, other than learning that it *changed* (which > it can learn via the periodic keepalives), it seems that > draft-ietf-sip-outbound-07 doesn't say the SIP UA needs to > learn its public transport address using STUN. It's not > necessary, anyway -- the SIP proxy knows the transport address > of an incoming UDP packet when the SIP proxy receives the packet. > ok, it was my assumption that the publicly mapped address from the STUN Binding Response was used to updated the Via: and Contact: headers of the SIP UA. But you are right; the SIP proxy knows where the SIP message came from. should we ask the outbound people if this could be clarified? so can we conclude with the following statement (simplified): port 3478: STUN Binding Discovery port 5060: SIP and STUN Keepalive many thanks for your clarifications, I think things are bit clearer now .. /alfred _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 31 21:18:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCRWH-00010L-Mt; Wed, 31 Jan 2007 21:17:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCRWE-0000za-Dc; Wed, 31 Jan 2007 21:17:46 -0500 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCRWD-0001Vq-12; Wed, 31 Jan 2007 21:17:46 -0500 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id l112HiGd011867; Wed, 31 Jan 2007 18:17:44 -0800 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id l112Hifj011866; Wed, 31 Jan 2007 18:17:44 -0800 Date: Wed, 31 Jan 2007 18:17:44 -0800 Message-Id: <200702010217.l112Hifj011866@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: behave@ietf.org, rfc-editor@rfc-editor.org Subject: [BEHAVE] BCP 127 RFC 4787 on Network Address Translation (NAT) Behavioral Requirements for Unicast UDP X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. BCP 127 RFC 4787 Title: Network Address Translation (NAT) Behavioral Requirements for Unicast UDP Author: F. Audet, Ed., C. Jennings Status: Best Current Practice Date: January 2007 Mailbox: audet@nortel.com, fluffy@cisco.com Pages: 29 Characters: 68693 Updates: See-Also: BCP0127 I-D Tag: draft-ietf-behave-nat-udp-08.txt URL: http://www.rfc-editor.org/rfc/rfc4787.txt This document defines basic terminology for describing different types of Network Address Translation (NAT) behavior when handling Unicast UDP and also defines a set of requirements that would allow many applications, such as multimedia communications or online gaming, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document is a product of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. BEST CURRENT PRACTICE: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave