From mom040267@gmail.com Thu Jan 9 17:51:12 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1D51ADF69 for ; Thu, 9 Jan 2014 17:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWEzRsDZGRl8 for ; Thu, 9 Jan 2014 17:51:10 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id AE1701ADF62 for ; Thu, 9 Jan 2014 17:51:10 -0800 (PST) Received: by mail-pa0-f50.google.com with SMTP id kp14so4073638pab.23 for ; Thu, 09 Jan 2014 17:51:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=PQ5nlgTP4l/rmmYgqVf/DICTX9S2Dn/lOt54YlevVSA=; b=LBXVheuJBlLO03vg5xgo9tDcjBZWpyEbNQLsQRYwYdUafKr+ETykwDBQChD9tJdMcY j2zSFAjPMgRK1NU++wasjV7ggBG1wV7SlrkGB9+MfsC8hXX3NVmXi+jiEb+ALoLfagKk mo/cpwAv5+59s1kFofq2v427PjhyYlV42TbUfHK3+t2iGB/jXBGy3qmyIwXw6xO+ZJWa b5Xdt1pZylt7Lrr5WsGkHXieVI8w3Wi3fGdQLls8o89I0XsOUHRqY9UheUOod+nNJV+A ptm476kbl1K50IWpw/qsXhoqnj3NRhJvfLwj6IuECl+XYk8+wmZH71QwOnb+lP4v5N5J A9/A== MIME-Version: 1.0 X-Received: by 10.68.170.66 with SMTP id ak2mr7493578pbc.5.1389318661096; Thu, 09 Jan 2014 17:51:01 -0800 (PST) Received: by 10.68.147.131 with HTTP; Thu, 9 Jan 2014 17:51:00 -0800 (PST) Date: Thu, 9 Jan 2014 17:51:00 -0800 Message-ID: From: Oleg Moskalenko To: "tram@ietf.org" , yoakum@avaya.com, justin@uberti.name, alan.b.johnston@gmail.com, kundan10@gmail.com Content-Type: multipart/alternative; boundary=047d7b86d55c464a7504ef93f52e Subject: [tram] draft-johnston-tram-stun-origin-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 01:51:13 -0000 --047d7b86d55c464a7504ef93f52e Content-Type: text/plain; charset=ISO-8859-1 Hi I've been reviewing the draft http://www.ietf.org/mail-archive/web/tram/current/maillist.html . The general idea definitely makes sense. Large TURN servers may indeed need separate realms for separate groups of users. It would make the administration more structured. Also, the TURN server may provide different level of services for different realms. For example, the "front" TURN server may just redirect with 300 error different origins to different backend servers with different configurations. One thing that I wish to be included into the draft would be the exact new STUN attribute value (section 2). Without that value, a test/proof of concept implementation cannot be done. I'd suggest a definition like: #define STUN_ATTRIBUTE_AGENT_ORIGIN (0x802F) The value 0x802F is in comprehensive-optional range, and it is not taken (yet). Thanks Oleg http://code.google.com/p/rfc5766-turn-server/ --047d7b86d55c464a7504ef93f52e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The general idea definitely makes sense.

<= /div>
Large TURN servers may indeed need separate realms for separate g= roups of users. It would make the administration more structured. Also, the= TURN server may provide different level of services for different realms. = For example, the "front" TURN server may just redirect with 300 e= rror different origins to different backend servers with different configur= ations.

One thing that I wish to be included into the draft would be= the exact new STUN attribute value (section 2). Without that value, a test= /proof of concept implementation cannot be done. I'd suggest a definiti= on like:

#define STUN_ATTRIBUTE_AGENT_ORIGIN (0x802F)

The valu= e 0x802F is in comprehensive-optional range, and it is not taken (yet).
=
--047d7b86d55c464a7504ef93f52e-- From alan.b.johnston@gmail.com Thu Jan 9 20:48:17 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA43A1AE06A for ; Thu, 9 Jan 2014 20:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K91QONaynYEv for ; Thu, 9 Jan 2014 20:48:15 -0800 (PST) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 99A3D1AE032 for ; Thu, 9 Jan 2014 20:48:15 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id k14so3634931wgh.22 for ; Thu, 09 Jan 2014 20:48:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4T/rVmQf+BApt8tWpZEsFJFICaTXqJazJrzs7Wutdck=; b=H1NCThF4vWtqX9L4Coj5nTHqiyr0RPWbH1p5lo8ODK3QxT9qhaelhsP47waIgVKX/E SZ70BrfpV80S2EeyL7EboNSb5tATd/652lmUbDACURXt55QEBxZ5wXNC7GTzdLlVRJcC Ozl56I2rBET9k1ONbG3TNGszVceCZFy64BHghmCPNiAvLStxiFATDtlqcRl/GMH098Wa yvecf5EvQmYW7tHECoUTCQjtIbJuiHw64lN3fvK9aldyxjQ/y4gdaik33T+Ez27luAm6 keiJcegR4NZFhX6TPCbFjW7IMOnBcV2zssJsBGzzYNBYzW0ifE7AUpfW/RYhyiOj3GwB 6dHg== MIME-Version: 1.0 X-Received: by 10.194.142.174 with SMTP id rx14mr6219805wjb.45.1389329285262; Thu, 09 Jan 2014 20:48:05 -0800 (PST) Received: by 10.216.152.2 with HTTP; Thu, 9 Jan 2014 20:48:05 -0800 (PST) In-Reply-To: References: Date: Thu, 9 Jan 2014 22:48:05 -0600 Message-ID: From: Alan Johnston To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=089e01176ee38633da04ef966eca X-Mailman-Approved-At: Thu, 09 Jan 2014 20:51:38 -0800 Cc: justin@uberti.name, "tram@ietf.org" , Kundan Singh , John Yoakum Subject: Re: [tram] draft-johnston-tram-stun-origin-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 04:48:18 -0000 --089e01176ee38633da04ef966eca Content-Type: text/plain; charset=ISO-8859-1 Oleg, Thanks for the review. Glad you think it makes sense. Hopefully an approach such as we have proposed will make it possible to have STUN and TURN servers that support multiple domains. I was thinking using that attribute value, but I held off putting it in the draft, hoping for 1) feedback from STUN/TURN experts, and 2) making sure there was interest in the approach. If others like the approach and think this value makes sense, then we will rev the draft adding the value. Having a browser and a server implement the extension would make for an excellent proof of concept. Note: I want to draw everyone's attention to the IPR declaration on the draft (https://datatracker.ietf.org/ipr/2293/). It is a standard free-if-you-re-not-suing-us license, so hopefully it will be OK. - Alan - On Thu, Jan 9, 2014 at 7:51 PM, Oleg Moskalenko wrote: > Hi > > I've been reviewing the draft > http://www.ietf.org/mail-archive/web/tram/current/maillist.html . > > The general idea definitely makes sense. > > Large TURN servers may indeed need separate realms for separate groups of > users. It would make the administration more structured. Also, the TURN > server may provide different level of services for different realms. For > example, the "front" TURN server may just redirect with 300 error different > origins to different backend servers with different configurations. > > One thing that I wish to be included into the draft would be the exact new > STUN attribute value (section 2). Without that value, a test/proof of > concept implementation cannot be done. I'd suggest a definition like: > > #define STUN_ATTRIBUTE_AGENT_ORIGIN (0x802F) > > The value 0x802F is in comprehensive-optional range, and it is not taken > (yet). > > Thanks > Oleg > http://code.google.com/p/rfc5766-turn-server/ > > --089e01176ee38633da04ef966eca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Oleg,

Thanks for the review. =A0Glad yo= u think it makes sense. =A0Hopefully an approach such as we have proposed w= ill make it possible to have STUN and TURN servers that support multiple do= mains.

I was thinking using that attribute value, but I held o= ff putting it in the draft, hoping for 1) feedback from STUN/TURN experts, = and 2) making sure there was interest in the approach. =A0If others like th= e approach and think this value makes sense, then we will rev the draft add= ing the value. =A0Having a browser and a server implement the extension wou= ld make for an excellent proof of concept.

Note: I want to draw everyone's attention to the IP= R declaration on the draft (https://datatracker.ietf.org/ipr/2293/). =A0It is a standard free-i= f-you-re-not-suing-us license, so hopefully it will be OK.

- Alan -


=
On Thu, Jan 9, 2014 at 7:51 PM, Oleg Moskalenko = <mom040267@gmail.com> wrote:
The general idea definitely makes sense.

<= /div>
Large TURN servers may indeed need separate realms for separate g= roups of users. It would make the administration more structured. Also, the= TURN server may provide different level of services for different realms. = For example, the "front" TURN server may just redirect with 300 e= rror different origins to different backend servers with different configur= ations.

One thing that I wish to be included into the draft would be= the exact new STUN attribute value (section 2). Without that value, a test= /proof of concept implementation cannot be done. I'd suggest a definiti= on like:

#define STUN_ATTRIBUTE_AGENT_ORIGIN (0x802F)

The valu= e 0x802F is in comprehensive-optional range, and it is not taken (yet).
=

--089e01176ee38633da04ef966eca-- From dwing@cisco.com Thu Jan 9 22:26:08 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7339F1ADBC9 for ; Thu, 9 Jan 2014 22:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.038 X-Spam-Level: X-Spam-Status: No, score=-15.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_hLHidGB0NP for ; Thu, 9 Jan 2014 22:26:06 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9F31AD8E2 for ; Thu, 9 Jan 2014 22:26:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4561; q=dns/txt; s=iport; t=1389335157; x=1390544757; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=Ay1kR1rT9KjcyqaaXMRY3H0I4nqNYFfNEMh+D3DTnxk=; b=BVVglZiOeSwNVLH2f0gmtavs8bHnTc8JSovP73Ub1BetPbJmdheayMWp Y8P81iGA116UQ+0DRx5Rn/PBNLE1N05uMjrB31Qo7g1gTgjeQs0V4cuKI aTx21iCQuBNeBkgQjgHIm/VjEmghm1wHFEr7IxqPzcz4h/4sUg9yIfu1n s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkHAPeRz1KrRDoG/2dsb2JhbABZgws4sUCIVYEHFnSCJQEBAQMBAQEBawsFCwsECjghBjAGEwmHZwMJBw69dA2FIReMcoFCAQFPB4MkgRMEiUOMaIFsgTCFFYYVhTuDThuBNQ X-IronPort-AV: E=Sophos;i="4.95,636,1384300800"; d="scan'208,217";a="102581918" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 10 Jan 2014 06:25:56 +0000 Received: from [10.21.72.241] ([10.21.72.241]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0A6Pu1l021126; Fri, 10 Jan 2014 06:25:56 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_C1847D19-86A3-4BC1-9E00-79026778E8B0" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dan Wing In-Reply-To: Date: Thu, 9 Jan 2014 20:57:13 -0800 Message-Id: <22B92FFE-4F7D-40DC-BE13-3C5ABCFB05D1@cisco.com> References: To: Oleg Moskalenko X-Mailer: Apple Mail (2.1510) Cc: justin@uberti.name, alan.b.johnston@gmail.com, "tram@ietf.org" , kundan10@gmail.com, yoakum@avaya.com Subject: Re: [tram] draft-johnston-tram-stun-origin-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 06:26:08 -0000 --Apple-Mail=_C1847D19-86A3-4BC1-9E00-79026778E8B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jan 9, 2014, at 5:51 PM, Oleg Moskalenko wrote: > Hi >=20 > I've been reviewing the draft = http://www.ietf.org/mail-archive/web/tram/current/maillist.html . >=20 > The general idea definitely makes sense. >=20 > Large TURN servers may indeed need separate realms for separate groups = of users. It would make the administration more structured. Also, the = TURN server may provide different level of services for different = realms. For example, the "front" TURN server may just redirect with 300 = error different origins to different backend servers with different = configurations. Couldn't that be achieved with separate hostnames like realm1.turn.example.com realm2.turn.example.com realm3.turn.example.com ... with each going to the same IP address or each to a different IP = address, as needed, without support in the protocol? -d > One thing that I wish to be included into the draft would be the exact = new STUN attribute value (section 2). Without that value, a test/proof = of concept implementation cannot be done. I'd suggest a definition like: >=20 > #define STUN_ATTRIBUTE_AGENT_ORIGIN (0x802F) >=20 > The value 0x802F is in comprehensive-optional range, and it is not = taken (yet). >=20 > Thanks > Oleg > http://code.google.com/p/rfc5766-turn-server/ >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram --Apple-Mail=_C1847D19-86A3-4BC1-9E00-79026778E8B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 mom040267@gmail.com> = wrote:

The general idea definitely makes = sense.

Large TURN servers may indeed = need separate realms for separate groups of users. It would make the = administration more structured. Also, the TURN server may provide = different level of services for different realms. For example, the = "front" TURN server may just redirect with 300 error different origins = to different backend servers with different = configurations.

Coul= dn't that be achieved with separate hostnames = like

<= div><= div><= /div>
  ...

with each going to the = same IP address or each to a different IP address, as needed, without = support in the = protocol?

-d


One thing that I wish to = be included into the draft would be the exact new STUN attribute value = (section 2). Without that value, a test/proof of concept implementation = cannot be done. I'd suggest a definition like:

#define STUN_ATTRIBUTE_AGENT_ORIGIN (0x802F)

The = value 0x802F is in comprehensive-optional range, and it is not taken = (yet).

_______________________________________________
tram mailing = list
tram@ietf.org
https://www.ietf.org/ma= ilman/listinfo/tram

= --Apple-Mail=_C1847D19-86A3-4BC1-9E00-79026778E8B0-- From alan.b.johnston@gmail.com Thu Jan 9 22:59:30 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615C51AD72A for ; Thu, 9 Jan 2014 22:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KX-Gh8_JDsE for ; Thu, 9 Jan 2014 22:59:28 -0800 (PST) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 937281A8028 for ; Thu, 9 Jan 2014 22:59:28 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id b13so3449895wgh.7 for ; Thu, 09 Jan 2014 22:59:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=egxv6YvLaFK+jLym8frESG4J70dzwSKPahlfdi5o37M=; b=D6m16HrOHTBFPRmkbhqh0Iceah9lVP6IG3Q8pIFGVn8g1KAFqJKza3poqOtAqaukjn k6OeAjQIjmMRwG55fS9a4R44URECPmC7BzbIrFC7y89ePATJvTqMfaNIM6hqpP/9T8Df 2r4XJnYRX8wHWjDav+caTXtOCRbOxOL4nHPGa0naxV2MaYdwtTuxHnyzF6p8wVKueXda O1HwIOboru0zG+ePeug9WWQHrPUryRJM9v5cvuaUBnQAO6uEOgcVIguXy4w776CVjVCy /Vk7LZEK+riPizu5DkM9BVr9rT3kuzEoNDPysI7pYw4BWQzHTErte3f0Gvvk80qpTmqA 0Q0A== MIME-Version: 1.0 X-Received: by 10.180.188.169 with SMTP id gb9mr989654wic.41.1389337158172; Thu, 09 Jan 2014 22:59:18 -0800 (PST) Received: by 10.216.152.2 with HTTP; Thu, 9 Jan 2014 22:59:18 -0800 (PST) In-Reply-To: <22B92FFE-4F7D-40DC-BE13-3C5ABCFB05D1@cisco.com> References: <22B92FFE-4F7D-40DC-BE13-3C5ABCFB05D1@cisco.com> Date: Fri, 10 Jan 2014 00:59:18 -0600 Message-ID: From: Alan Johnston To: Dan Wing Content-Type: multipart/alternative; boundary=001a11c26bb8c9479e04ef9843ee Cc: justin@uberti.name, Oleg Moskalenko , "tram@ietf.org" , Kundan Singh , John Yoakum Subject: Re: [tram] draft-johnston-tram-stun-origin-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 06:59:30 -0000 --001a11c26bb8c9479e04ef9843ee Content-Type: text/plain; charset=ISO-8859-1 Dan, Yes, that could be done, but would require a lot of provisioning in the TURN server and also in the ICE Servers URIs of the JavaScript. This isn't scalable, either, and could be mixed up by developers copying code. - Alan - On Thu, Jan 9, 2014 at 10:57 PM, Dan Wing wrote: > > On Jan 9, 2014, at 5:51 PM, Oleg Moskalenko wrote: > > Hi > > I've been reviewing the draft > http://www.ietf.org/mail-archive/web/tram/current/maillist.html . > > The general idea definitely makes sense. > > Large TURN servers may indeed need separate realms for separate groups of > users. It would make the administration more structured. Also, the TURN > server may provide different level of services for different realms. For > example, the "front" TURN server may just redirect with 300 error different > origins to different backend servers with different configurations. > > > Couldn't that be achieved with separate hostnames like > > realm1.turn.example.com > realm2.turn.example.com > realm3.turn.example.com > ... > > with each going to the same IP address or each to a different IP address, > as needed, without support in the protocol? > > -d > > > One thing that I wish to be included into the draft would be the exact new > STUN attribute value (section 2). Without that value, a test/proof of > concept implementation cannot be done. I'd suggest a definition like: > > #define STUN_ATTRIBUTE_AGENT_ORIGIN (0x802F) > > The value 0x802F is in comprehensive-optional range, and it is not taken > (yet). > > Thanks > Oleg > http://code.google.com/p/rfc5766-turn-server/ > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > --001a11c26bb8c9479e04ef9843ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dan,

Yes, that could be done, but would= require a lot of provisioning in the TURN server and also in the ICE Serve= rs URIs of the JavaScript. =A0This isn't scalable, either, and could be= mixed up by developers copying code.

- Alan -


=
On Thu, Jan 9, 2014 at 10:57 PM, Dan Wing <dwing@= cisco.com> wrote:

On Jan 9, 2014, at 5:51 PM, Oleg Moskalenko <mom040267@gmail.com> wrote:
The general idea definitely makes sense.

<= /div>
Large TURN servers may indeed need separate realms for separate g= roups of users. It would make the administration more structured. Also, the= TURN server may provide different level of services for different realms. = For example, the "front" TURN server may just redirect with 300 e= rror different origins to different backend servers with different configur= ations.

Couldn't that be ach= ieved with separate hostnames like


with each going to the same IP address or each to a dif= ferent IP address, as needed, without support in the protocol?
-d


One thing that I wish to be included into the draft would be the = exact new STUN attribute value (section 2). Without that value, a test/proo= f of concept implementation cannot be done. I'd suggest a definition li= ke:

#define STUN_ATTRIBUTE_AGENT_ORIGIN (0x802F)

The valu= e 0x802F is in comprehensive-optional range, and it is not taken (yet).
=
_______________________________________________
tram mailing list
tram@ietf.org
https://= www.ietf.org/mailman/listinfo/tram


--001a11c26bb8c9479e04ef9843ee-- From mom040267@gmail.com Fri Jan 10 00:10:49 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BD71ADF34 for ; Fri, 10 Jan 2014 00:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16FI51whAhr7 for ; Fri, 10 Jan 2014 00:10:48 -0800 (PST) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 935F01ADF28 for ; Fri, 10 Jan 2014 00:10:48 -0800 (PST) Received: by mail-pb0-f46.google.com with SMTP id md12so4126065pbc.19 for ; Fri, 10 Jan 2014 00:10:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=s/MTCbZqepMmpMcHROdN0dxGpe0wak8OTFSfx96aszw=; b=eMjKlnHrg6jkBVuscQcdWnFHD+WZhRTQXUlbMMPqnM4dVIjlIn5Kd1LzOTgNKG9R3m nomkO5WqcCCxdOOvcfT6/WYmIvsLVv606QpozUf0p0In9l6uOYyU4WLJpeX+zvuOp5go 0QF3sbh8n/51mrMGa1qI8+A6lsFpE05eky5acUoBdPDQIlae8/O8DnZTrpda0yt4G/Ww NjtYr3lqsf+2GY8lwfo0zp1/B4ne7Eebtl/XxAdFKKkiHf0XpgZ3WBRdxxJ6/ZlVviG+ 4uEg+c/mzIUtXb34LGQFqyesSoUhTW2Kgz8hboIiqHa3g/gOwO+q19E50QwXAbBfVjoW Fw7g== MIME-Version: 1.0 X-Received: by 10.68.170.66 with SMTP id ak2mr9511043pbc.5.1389341437767; Fri, 10 Jan 2014 00:10:37 -0800 (PST) Received: by 10.68.147.131 with HTTP; Fri, 10 Jan 2014 00:10:37 -0800 (PST) In-Reply-To: <22B92FFE-4F7D-40DC-BE13-3C5ABCFB05D1@cisco.com> References: <22B92FFE-4F7D-40DC-BE13-3C5ABCFB05D1@cisco.com> Date: Fri, 10 Jan 2014 00:10:37 -0800 Message-ID: From: Oleg Moskalenko To: Dan Wing Content-Type: multipart/alternative; boundary=047d7b86d55cdeb68a04ef99428e Cc: justin , "alan.b.johnston" , "tram@ietf.org" , kundan10 , yoakum Subject: Re: [tram] draft-johnston-tram-stun-origin-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 08:10:50 -0000 --047d7b86d55cdeb68a04ef99428e Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 9, 2014 at 8:57 PM, Dan Wing wrote: > > On Jan 9, 2014, at 5:51 PM, Oleg Moskalenko wrote: > > Hi > > I've been reviewing the draft > http://www.ietf.org/mail-archive/web/tram/current/maillist.html . > > The general idea definitely makes sense. > > Large TURN servers may indeed need separate realms for separate groups of > users. It would make the administration more structured. Also, the TURN > server may provide different level of services for different realms. For > example, the "front" TURN server may just redirect with 300 error different > origins to different backend servers with different configurations. > > > Couldn't that be achieved with separate hostnames like > > realm1.turn.example.com > realm2.turn.example.com > realm3.turn.example.com > ... > > with each going to the same IP address or each to a different IP address, > as needed, without support in the protocol? > > > Yes and no. What I like about the proposed solution is that it gives more control to the TURN server administrator and the overall admin structuring is better - less parts involved. All changes outside of the TURN server are "virtual" and "logical" - they all can be ignored and are 100% backward-compatible. Regards, Oleg --047d7b86d55cdeb68a04ef99428e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Jan 9, 2014 at 8:57 PM, Dan Wing <dwing@cisco.com> wrote:

On Jan 9, 2014, at 5:51 PM, Oleg Moskalenko <mom040267@gmail.com> wrote:


<= /div>
Large TURN servers may indeed need separate realms for separate g= roups of users. It would make the administration more structured. Also, the= TURN server may provide different level of services for different realms. = For example, the "front" TURN server may just redirect with 300 e= rror different origins to different backend servers with different configur= ations.

Couldn't that = be achieved with separate hostnames like


with each going to the same IP address or each to a dif= ferent IP address, as needed, without support in the protocol?


Yes and no. What I lik= e about the proposed solution is that it gives more control to the TURN ser= ver administrator and the overall admin structuring is better - less parts = involved. All changes outside of the TURN server are "virtual" an= d "logical" - they all can be ignored and are 100% backward-compa= tible.

Regards,
Oleg
--047d7b86d55cdeb68a04ef99428e-- From mom040267@gmail.com Fri Jan 10 00:19:00 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353911AD8E2 for ; Fri, 10 Jan 2014 00:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiu-kp_s4qcw for ; Fri, 10 Jan 2014 00:18:58 -0800 (PST) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C67621AC7F2 for ; Fri, 10 Jan 2014 00:18:58 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id r10so319829pdi.6 for ; Fri, 10 Jan 2014 00:18:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nkoaSlodooUyhri0L0qk065phOVc3rb8nVdRxSqxTZU=; b=GTbm7aEvK69Sy+BWsoumfqObQPhSdkMRlNGAHM7aw5tGsztkyGQ7ZDPVmK3VoxqPgq n/LnRY9ud++PTqu6zUD54SPnsH1haKKAu3IFd1j662uuoDbqk2rvgExGMI/jlg9bQaNO H8ekBmCEUuOYPi+AsNHSSWvxwVMFrw85Y5vH9Lt+tKakW/KAusApak4s91eHeOEyMcCf qZrSFcY6NswubVKUVgrNR/UNoOtL9awODIku1b//OEj+NaAMyVM3yfcfuRJJJDoSZ2E2 4ZvwDxy/VXpIGv4bpODUQ0JaVsfFwvUTZWHKeemRfbF4v+HUtT9jmKyIH+2GrD+nJSkt c4pQ== MIME-Version: 1.0 X-Received: by 10.66.142.233 with SMTP id rz9mr9633454pab.71.1389341929080; Fri, 10 Jan 2014 00:18:49 -0800 (PST) Received: by 10.68.147.131 with HTTP; Fri, 10 Jan 2014 00:18:49 -0800 (PST) In-Reply-To: References: Date: Fri, 10 Jan 2014 00:18:49 -0800 Message-ID: From: Oleg Moskalenko To: Alan Johnston Content-Type: multipart/alternative; boundary=001a1134480827903404ef9960a9 Cc: justin , "tram@ietf.org" , Kundan Singh , John Yoakum Subject: Re: [tram] draft-johnston-tram-stun-origin-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 08:19:00 -0000 --001a1134480827903404ef9960a9 Content-Type: text/plain; charset=ISO-8859-1 > > #define STUN_ATTRIBUTE_AGENT_ORIGIN (0x802F) > > > Note: I want to draw everyone's attention to the IPR declaration on the > draft (https://datatracker.ietf.org/ipr/2293/). It is a standard > free-if-you-re-not-suing-us license, so hopefully it will be OK. > >> Alan, I am not a lawyer and I am not sure how combining IETF draft/standard with a patent works. Some wording sounds disturbing: "If the standard is adopted, Avaya will not assert the above-identified patents against any party for making, using, selling, importing or offering for sale a product that implements the standard". But what about the period BEFORE the standard adoption ? Does that mean that if I add the draft's functionality to our TURN Server BEFORE the RFC adoption, then you will have the grounds to sue me - for this relatively common-sense approach ? Thanks Oleg --001a1134480827903404ef9960a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

=

#define STUN_ATT= RIBUTE_AGENT_ORIGIN (0x802F)


Note: I want to draw everyone's att= ention to the IPR declaration on the draft (https://datatracker.ietf.org/ipr/2293= /). =A0It is a standard free-if-you-re-not-suing-us license, so hopeful= ly it will be OK.
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
=A0
Alan, I am not a lawyer and I am not sure= how combining IETF draft/standard with a patent works. Some wording sounds= disturbing:

"If the standard is adopted, Avaya will not assert the above-ident= ified=20 patents against any party for making, using, selling, importing or=20 offering for sale a product that implements the standard".

But= what about the period BEFORE the standard adoption ? Does that mean that i= f I add the draft's functionality to our TURN Server BEFORE the RFC ado= ption, then you will have the grounds to sue me - for this relatively commo= n-sense approach ?

Thanks
Oleg




--001a1134480827903404ef9960a9-- From dwing@cisco.com Fri Jan 10 01:09:28 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDE91ACCFF for ; Fri, 10 Jan 2014 01:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.038 X-Spam-Level: X-Spam-Status: No, score=-15.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xqw_Q7rgo9Ur for ; Fri, 10 Jan 2014 01:09:26 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 680F81A1F5D for ; Fri, 10 Jan 2014 01:09:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4952; q=dns/txt; s=iport; t=1389344956; x=1390554556; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=eB1qSb5h15wYTcu3T3wVv4F05qUM8K8LVeCMp8EKjIw=; b=ZFVKiJh6wp1Qgnd6USvednKNNkNKlb92wnn3DIWVxDZiPKbQ+9si19Li DUlfFKAv0JVr/GAT/VKjZSbEkLIlfN676z7F+IQhXMrpS8e34MaxG2Xg3 8kKU1M2uF0BDle9F72KusajaVSyVlA1PQT5/jmrYJ6I1jnjqeprnzIlH7 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkHAGS4z1KrRDoH/2dsb2JhbABZgws4sUGIVYEHFnSCJQEBAQR5EAsECgouITYGEwkSh1UDEA6+BA2FIReMcoFCAQFPB4MkgRMEiUOMaIFsgTCFFYYVhTuDThuBNQ X-IronPort-AV: E=Sophos;i="4.95,637,1384300800"; d="scan'208,217";a="99381900" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 10 Jan 2014 09:09:16 +0000 Received: from [10.21.72.241] ([10.21.72.241]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0A99GOM008547; Fri, 10 Jan 2014 09:09:16 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_3EB83158-DB24-4643-AE00-1110A73A8EC7" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dan Wing In-Reply-To: Date: Fri, 10 Jan 2014 01:09:16 -0800 Message-Id: <5FCEA243-882B-49F8-AC66-6B69634CAE56@cisco.com> References: <22B92FFE-4F7D-40DC-BE13-3C5ABCFB05D1@cisco.com> To: Oleg Moskalenko X-Mailer: Apple Mail (2.1510) Cc: justin , "alan.b.johnston" , "tram@ietf.org" , kundan10 , yoakum Subject: Re: [tram] draft-johnston-tram-stun-origin-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 09:09:28 -0000 --Apple-Mail=_3EB83158-DB24-4643-AE00-1110A73A8EC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jan 10, 2014, at 12:10 AM, Oleg Moskalenko = wrote: >=20 >=20 >=20 > On Thu, Jan 9, 2014 at 8:57 PM, Dan Wing wrote: >=20 > On Jan 9, 2014, at 5:51 PM, Oleg Moskalenko = wrote: >=20 >> Hi >>=20 >> I've been reviewing the draft = http://www.ietf.org/mail-archive/web/tram/current/maillist.html . >>=20 >> The general idea definitely makes sense. >>=20 >> Large TURN servers may indeed need separate realms for separate = groups of users. It would make the administration more structured. Also, = the TURN server may provide different level of services for different = realms. For example, the "front" TURN server may just redirect with 300 = error different origins to different backend servers with different = configurations. >=20 > Couldn't that be achieved with separate hostnames like >=20 > realm1.turn.example.com > realm2.turn.example.com > realm3.turn.example.com > ... >=20 > with each going to the same IP address or each to a different IP = address, as needed, without support in the protocol? >=20 >=20 >=20 > Yes and no. What I like about the proposed solution is that it gives = more control to the TURN server administrator and the overall admin = structuring is better - less parts involved. All changes outside of the = TURN server are "virtual" and "logical" - they all can be ignored and = are 100% backward-compatible.=20 It might help for the I-D to discuss those advantages, to provide = motivation for the new STUN attribute. -d --Apple-Mail=_3EB83158-DB24-4643-AE00-1110A73A8EC7 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Jan 10, 2014, at 12:10 AM, Oleg Moskalenko <mom040267@gmail.com> wrote:




On Thu, Jan 9, 2014 at 8:57 PM, Dan Wing <dwing@cisco.com> wrote:

On Jan 9, 2014, at 5:51 PM, Oleg Moskalenko <mom040267@gmail.com> wrote:

The general idea definitely makes sense.

Large TURN servers may indeed need separate realms for separate groups of users. It would make the administration more structured. Also, the TURN server may provide different level of services for different realms. For example, the "front" TURN server may just redirect with 300 error different origins to different backend servers with different configurations.

Couldn't that be achieved with separate hostnames like

  ...

with each going to the same IP address or each to a different IP address, as needed, without support in the protocol?



Yes and no. What I like about the proposed solution is that it gives more control to the TURN server administrator and the overall admin structuring is better - less parts involved. All changes outside of the TURN server are "virtual" and "logical" - they all can be ignored and are 100% backward-compatible.

It might help for the I-D to discuss those advantages, to provide motivation for the new STUN attribute.

-d

--Apple-Mail=_3EB83158-DB24-4643-AE00-1110A73A8EC7-- From simon.perreault@viagenie.ca Fri Jan 10 06:23:47 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBBC1AE064 for ; Fri, 10 Jan 2014 06:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cr4-m1h65YRj for ; Fri, 10 Jan 2014 06:23:45 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9DB1AE046 for ; Fri, 10 Jan 2014 06:23:45 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:d03a:bf34:38d3:2115]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1984140397 for ; Fri, 10 Jan 2014 09:23:35 -0500 (EST) Message-ID: <52D00266.9020007@viagenie.ca> Date: Fri, 10 Jan 2014 09:23:34 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: tram@ietf.org References: <22B92FFE-4F7D-40DC-BE13-3C5ABCFB05D1@cisco.com> In-Reply-To: <22B92FFE-4F7D-40DC-BE13-3C5ABCFB05D1@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [tram] draft-johnston-tram-stun-origin-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 14:23:47 -0000 Le 2014-01-09 23:57, Dan Wing a écrit : > Couldn't that be achieved with separate hostnames like > > realm1.turn.example.com > realm2.turn.example.com > realm3.turn.example.com > ... > > with each going to the same IP address or each to a different IP > address, as needed, without support in the protocol? IMHO, no. The problem I'm considering is that of a TURN server that is shared by many tenants. Each tenant has its own WebRTC app and its own user DB. Using many domains with a single IP doesn't solve this problem: the server still doesn't know which realm to reply with. The only solution is using one IP address per tenant. And that sucks. And this draft solve that. So I like it. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Fri Jan 10 06:33:13 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB631AE061 for ; Fri, 10 Jan 2014 06:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GilsJXx-Yc8e for ; Fri, 10 Jan 2014 06:33:09 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E77381AE047 for ; Fri, 10 Jan 2014 06:33:08 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:d03a:bf34:38d3:2115]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D995240397 for ; Fri, 10 Jan 2014 09:32:58 -0500 (EST) Message-ID: <52D0049A.6090702@viagenie.ca> Date: Fri, 10 Jan 2014 09:32:58 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: tram@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [tram] draft-johnston-tram-stun-origin-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 14:33:13 -0000 Le 2014-01-09 20:51, Oleg Moskalenko a écrit : > One thing that I wish to be included into the draft would be the exact > new STUN attribute value (section 2). Without that value, a test/proof > of concept implementation cannot be done. I'd suggest a definition like: > > #define STUN_ATTRIBUTE_AGENT_ORIGIN (0x802F) > > The value 0x802F is in comprehensive-optional range, and it is not taken > (yet). The problem is that as soon as there's a value in the draft and it gets implemented, it becomes de-facto standard, and people complain if you try to change it later. Or if the draft gets abandoned, and a different draft needs a value, you may have trouble reallocating the value if it is "dirty", i.e. used in the wild (currently or in the past) without an official allocation. There are already a bunch of those dirty values in the STUN IANA registry, and that sucks. IMHO, wait until the draft is stable before picking a value, Or even better, follow the process in RFC 4020. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From alan.b.johnston@gmail.com Fri Jan 10 07:21:14 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05C31AE06F for ; Fri, 10 Jan 2014 07:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXRcPAwmv8-8 for ; Fri, 10 Jan 2014 07:21:11 -0800 (PST) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 371371AE09E for ; Fri, 10 Jan 2014 07:21:11 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id p61so4276394wes.31 for ; Fri, 10 Jan 2014 07:21:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nWbuNSFE/mbbM/OBAKVBzGQ/zuS1kAkm+YT7S71RQG4=; b=lubYYOvyOnyM2fcmEC4zpkpxiQ1/ZcO9rSzdV3LsZmu5tQqL1ZFGM7FgzlnGBFUOPV BfQG7TA/dQ37DQINzZsSEAC3QG1QFSTlrBFHGBohzK8g2rMtEn5WcWuVHH2v3XSjO4vn qNsELRxZxU6Ol0mINaKtivbf5hiScycWEbKKL1Axtvf7a0Ao4Gd4qd5rw+Bjx5ORAgKp TlwpN+n/DcMk0NKteMbpkkUBRCB5jED6ouaPD7IJvDqventcwIEyYIDr8s8ie2LGHozF iiOTu9aGkffkjOWLRy5q0PgAgpxnjieZN52mc+vgvazBX9IiNQj/Tmy8HJ16tF5Nz+0D A7Ew== MIME-Version: 1.0 X-Received: by 10.194.109.68 with SMTP id hq4mr9262775wjb.12.1389366802489; Fri, 10 Jan 2014 07:13:22 -0800 (PST) Received: by 10.216.152.2 with HTTP; Fri, 10 Jan 2014 07:13:22 -0800 (PST) In-Reply-To: References: Date: Fri, 10 Jan 2014 09:13:22 -0600 Message-ID: From: Alan Johnston To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=089e0102e6dab9a9dd04ef9f2acf Cc: justin , "tram@ietf.org" , Kundan Singh , John Yoakum Subject: Re: [tram] draft-johnston-tram-stun-origin-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 15:21:15 -0000 --089e0102e6dab9a9dd04ef9f2acf Content-Type: text/plain; charset=ISO-8859-1 Oleg, No, absolutely not! We wrote this draft because we see a need for it and we want implementations of it in browsers and servers and adoption of it as a standard. Gaining early experience is key to achieving that. I'm not a lawyer either, but unfortunately with today's insane patent situation, this type of defensive patent is unfortunately becoming more common. - Alan - On Fri, Jan 10, 2014 at 2:18 AM, Oleg Moskalenko wrote: > > >> #define STUN_ATTRIBUTE_AGENT_ORIGIN (0x802F) >> >> >> Note: I want to draw everyone's attention to the IPR declaration on the >> draft (https://datatracker.ietf.org/ipr/2293/). It is a standard >> free-if-you-re-not-suing-us license, so hopefully it will be OK. >> >>> > Alan, I am not a lawyer and I am not sure how combining IETF > draft/standard with a patent works. Some wording sounds disturbing: > > "If the standard is adopted, Avaya will not assert the above-identified > patents against any party for making, using, selling, importing or offering > for sale a product that implements the standard". > > But what about the period BEFORE the standard adoption ? Does that mean > that if I add the draft's functionality to our TURN Server BEFORE the RFC > adoption, then you will have the grounds to sue me - for this relatively > common-sense approach ? > > Thanks > Oleg > > > > > --089e0102e6dab9a9dd04ef9f2acf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Oleg,

No, absolutely not! =A0We wrote t= his draft because we see a need for it and we want implementations of it in= browsers and servers and adoption of it as a standard. =A0Gaining early ex= perience is key to achieving that.

I'm not a lawyer either, but unfortunately with tod= ay's insane patent situation, this type of defensive patent is unfortun= ately becoming more common.

- Alan -


On Fri, Jan 1= 0, 2014 at 2:18 AM, Oleg Moskalenko <mom040267@gmail.com> = wrote:


#define STUN_ATTRIBUTE_AGENT_ORIGIN (0x802F)


Note: I want to draw everyone's att= ention to the IPR declaration on the draft (https://datatracker.ietf.org/ipr/2293= /). =A0It is a standard free-if-you-re-not-suing-us license, so hopeful= ly it will be OK.
=A0
Alan, I am not a lawyer and I am not sure= how combining IETF draft/standard with a patent works. Some wording sounds= disturbing:

"If the standard is adopted, Avaya will not assert the above-ident= ified=20 patents against any party for making, using, selling, importing or=20 offering for sale a product that implements the standard".

But= what about the period BEFORE the standard adoption ? Does that mean that i= f I add the draft's functionality to our TURN Server BEFORE the RFC ado= ption, then you will have the grounds to sue me - for this relatively commo= n-sense approach ?

Thanks
Oleg
<= br>



--089e0102e6dab9a9dd04ef9f2acf-- From mom040267@gmail.com Fri Jan 10 10:30:50 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6959F1AE037 for ; Fri, 10 Jan 2014 10:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6qr5gxYL9Es for ; Fri, 10 Jan 2014 10:30:49 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id C003D1AE155 for ; Fri, 10 Jan 2014 10:30:44 -0800 (PST) Received: by mail-pa0-f41.google.com with SMTP id fb1so3517855pad.28 for ; Fri, 10 Jan 2014 10:30:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FgNUffAYi8f6qiZuEMiXz5u+5cQIr/q9h97spSvH4RM=; b=QSr4exHhorjgaKiGgsPkll5eIShJ2ZQ5VydViT7AhvDvGSF292ws+z5fFKpQ7+qlFT N+RrUAhfFnMcUphQF2t1Q0BTfPQqcDyNK62e0agCD2TscMTRe6rpRTjbqEZs/THmu8xz jdIoAcmvLQrn/PEZxRKBsq+nIfBSlIewR20N0mhdHS9a1jKSCNVynH/R9y1vg45Dcwmz HoZZgKP0JJR/7ATgbAeCe3+uzIpVD4E9xD2corEe4fn4xf8G9iuqVqnBBDxD2bxlioVq 9w2w2A55YVqa62n11qsLZiKOX4YRQ3n7PgdKn9ohnvbSLobGbO+pm1KV60PekGCXZMTL Eqkg== MIME-Version: 1.0 X-Received: by 10.66.228.37 with SMTP id sf5mr13339822pac.19.1389378634977; Fri, 10 Jan 2014 10:30:34 -0800 (PST) Received: by 10.68.147.131 with HTTP; Fri, 10 Jan 2014 10:30:34 -0800 (PST) In-Reply-To: References: Date: Fri, 10 Jan 2014 10:30:34 -0800 Message-ID: From: Oleg Moskalenko To: Alan Johnston Content-Type: multipart/alternative; boundary=047d7b111dd9ff1a9d04efa1eb38 Cc: justin , "tram@ietf.org" , Kundan Singh , John Yoakum Subject: Re: [tram] draft-johnston-tram-stun-origin-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 18:30:50 -0000 --047d7b111dd9ff1a9d04efa1eb38 Content-Type: text/plain; charset=ISO-8859-1 That's cool. When the value of the ORIGIN attribute is more-or-less determined (thru RFC 4020 process or else), I'll implement it in the TURN server. Regards, Oleg On Fri, Jan 10, 2014 at 7:13 AM, Alan Johnston wrote: > Oleg, > > No, absolutely not! We wrote this draft because we see a need for it and > we want implementations of it in browsers and servers and adoption of it as > a standard. Gaining early experience is key to achieving that. > > I'm not a lawyer either, but unfortunately with today's insane patent > situation, this type of defensive patent is unfortunately becoming more > common. > > - Alan - > > > On Fri, Jan 10, 2014 at 2:18 AM, Oleg Moskalenko wrote: > >> >> >>> #define STUN_ATTRIBUTE_AGENT_ORIGIN (0x802F) >>> >>> >>> Note: I want to draw everyone's attention to the IPR declaration on the >>> draft (https://datatracker.ietf.org/ipr/2293/). It is a standard >>> free-if-you-re-not-suing-us license, so hopefully it will be OK. >>> >>>> >> Alan, I am not a lawyer and I am not sure how combining IETF >> draft/standard with a patent works. Some wording sounds disturbing: >> >> "If the standard is adopted, Avaya will not assert the above-identified >> patents against any party for making, using, selling, importing or offering >> for sale a product that implements the standard". >> >> But what about the period BEFORE the standard adoption ? Does that mean >> that if I add the draft's functionality to our TURN Server BEFORE the RFC >> adoption, then you will have the grounds to sue me - for this relatively >> common-sense approach ? >> >> Thanks >> Oleg >> >> >> >> >> > --047d7b111dd9ff1a9d04efa1eb38 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
That's cool.

When the value of = the ORIGIN=20 attribute is more-or-less determined (thru RFC 4020 process or else),=20 I'll implement it in the TURN server.

Regards,
Oleg



On Fri, Jan 10, 2014 at 7:13 AM, Alan Johnston <<= a href=3D"mailto:alan.b.johnston@gmail.com" target=3D"_blank">alan.b.johnst= on@gmail.com> wrote:
Oleg,

No= , absolutely not! =A0We wrote this draft because we see a need for it and w= e want implementations of it in browsers and servers and adoption of it as = a standard. =A0Gaining early experience is key to achieving that.

I'm not a lawyer either, but unfortunately with tod= ay's insane patent situation, this type of defensive patent is unfortun= ately becoming more common.

- Alan -


On Fri, Jan 1= 0, 2014 at 2:18 AM, Oleg Moskalenko <mom040267@gmail.com> = wrote:


#define STUN_ATTRIBUTE_AGENT_ORIGIN (0x802F)


Note: I want to draw everyone's att= ention to the IPR declaration on the draft (https://datatracker.ietf.org/ipr/2293= /). =A0It is a standard free-if-you-re-not-suing-us license, so hopeful= ly it will be OK.
=A0
Alan, I am not a lawyer and I am not sure= how combining IETF draft/standard with a patent works. Some wording sounds= disturbing:

"If the standard is adopted, Avaya will not assert the above-ident= ified=20 patents against any party for making, using, selling, importing or=20 offering for sale a product that implements the standard".

But= what about the period BEFORE the standard adoption ? Does that mean that i= f I add the draft's functionality to our TURN Server BEFORE the RFC ado= ption, then you will have the grounds to sue me - for this relatively commo= n-sense approach ?

ThanksOleg



=


--047d7b111dd9ff1a9d04efa1eb38-- From tireddy@cisco.com Mon Jan 13 05:27:18 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3291AE156 for ; Mon, 13 Jan 2014 05:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZGMgaiGJrbR for ; Mon, 13 Jan 2014 05:27:16 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id E021D1ADFA2 for ; Mon, 13 Jan 2014 05:27:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15164; q=dns/txt; s=iport; t=1389619625; x=1390829225; h=from:to:subject:date:message-id:mime-version; bh=eZ0IzWvU7imlnhyblgzEJ+lVOPQpwd0/P/XYpvkawhs=; b=I+6EtyLUKWxV2fRkVqcEvpVhj28E8CqBA1Xo9GiaKv74Kme32qJfH6rj XD/o/yAE/oTYSkC5SdKJDtwhYYbC7odcIIYuxfL4LRC/X9FUuO0N6+iWm 0r6LbcF5m67SVkDeJQVdXX8moSLqksS2n/Z/TYjR8pJ2BglnV2SweBHOY 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmMHAPTo01KtJXHA/2dsb2JhbABagkdEOFaxGIhVgRAWdIIlAQEBBC1eAQgOAwQBAQsdKBEUCQkBBAESCAGHZwMRDb9CDYUqF4x0gUIBAR43gyWBEwSWK4MciyqFO4MtgXE5 X-IronPort-AV: E=Sophos;i="4.95,653,1384300800"; d="scan'208,217";a="12447296" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-7.cisco.com with ESMTP; 13 Jan 2014 13:27:04 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0DDR4gH006032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Jan 2014 13:27:04 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Mon, 13 Jan 2014 07:27:04 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko , "tram@ietf.org" , "yoakum@avaya.com" , "justin@uberti.name" , "alan.b.johnston@gmail.com" , "kundan10@gmail.com" Thread-Topic: [tram] draft-johnston-tram-stun-origin-00 Thread-Index: Ac8QYyKZSGCAMoTlSf2zz6wjmih74g== Date: Mon, 13 Jan 2014 13:27:03 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A24289ED3@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.67.100] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A24289ED3xmbrcdx10ciscoc_" MIME-Version: 1.0 Subject: Re: [tram] draft-johnston-tram-stun-origin-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 13:27:18 -0000 --_000_913383AAA69FF945B8F946018B75898A24289ED3xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I like the draft, it solves the multiple realm problem we were discussing i= n BEHAVE WG sometime back http://tools.ietf.org/html/draft-reddy-behave-tur= n-auth-04 5. Hosting multiple realms on a single IP address is challenging with TURN. When a TURN server needs to send the REALM attribute in response to an unauthenticated request, it has no useful information for determining which realm it should send, except the source transport address of the TURN request. Note this is a problem with multi-tenant scenarios only. This may not be a problem when TURN server is located in enterprise premises. My initial comments 1. Section Security Considerations Comment 1> On-path attacker can do much more damage like modifying the pay= load, dropping the packet etc. The more interesting scenario would be passi= ve attacker sniffing the on-wire packets and can thus determine the value i= n the ORIGIN header. Comment 2> DTLS could also solve the problem with the server_name extensio= n defined RFC6066. Is there need for ORIGIN STUN attribute if DTLS is used with server_name ex= tension ? Comment 3> ORIGN attribute would be typically used before long-term authen= tication has started. In what scenarios content of ORIGIN attribute will be= integrity protected ? 2. Section STUN usage Rouge Client can include any domain to which STUN binding response would be= received to defeat the purpose. The only way to solve the problem would be= to use STUN Auth. Though STUN Auth is typically not used with Public STUN = servers, but with STUN servers deployed in the Enterprise premises the situ= ation could change. http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases= -and-requirements-12#section-3.3.5 explains the use case of enterprise depl= oying STUN server. -Tiru. From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko Sent: Friday, January 10, 2014 7:21 AM To: tram@ietf.org; yoakum@avaya.com; justin@uberti.name; alan.b.johnston@gma= il.com; kundan10@gmail.com Subject: [tram] draft-johnston-tram-stun-origin-00 Hi I've been reviewing the draft http://www.ietf.org/mail-archive/web/tram/cur= rent/maillist.html . The general idea definitely makes sense. Large TURN servers may indeed need separate realms for separate groups of u= sers. It would make the administration more structured. Also, the TURN serv= er may provide different level of services for different realms. For exampl= e, the "front" TURN server may just redirect with 300 error different origi= ns to different backend servers with different configurations. One thing that I wish to be included into the draft would be the exact new = STUN attribute value (section 2). Without that value, a test/proof of conce= pt implementation cannot be done. I'd suggest a definition like: #define STUN_ATTRIBUTE_AGENT_ORIGIN (0x802F) The value 0x802F is in comprehensive-optional range, and it is not taken (y= et). Thanks Oleg http://code.google.com/p/rfc5766-turn-server/ --_000_913383AAA69FF945B8F946018B75898A24289ED3xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I like the draft, it solv= es the multiple realm problem we were discussing in BEHAVE WG sometime back http= ://tools.ietf.org/html/draft-reddy-behave-turn-auth-04

 

   5.  Hosting multiple realms on a single = IP address is challenging

       with TURN.  When= a TURN server needs to send the REALM attribute

       in response to an una= uthenticated request, it has no useful

       information for deter= mining which realm it should send, except

       the source transport = address of the TURN request.  Note this is a

       problem with multi-te= nant scenarios only.  This may not be a

       problem when TURN ser= ver is located in enterprise premises.

 <= /p>

My initial comments<= /o:p>

 <= /p>

1.  Section Security= Considerations

 <= /p>

Comment 1>  On-pa= th attacker can do much more damage like modifying the payload, dropping th= e packet etc. The more interesting scenario would be passive attacker sniffing the on-wire packets and can thus determine the value in the ORIGI= N header.

 <= /p>

Comment 2>  DTLS = could also solve the problem with the server_name extension defined RFC6066= .

Is there need for ORIGIN = STUN attribute if DTLS is used with server_name extension ?

 <= /p>

Comment 3>  ORIGN= attribute would be typically used before long-term authentication has star= ted. In what scenarios content of ORIGIN attribute will be integrity protected ?

 <= /p>

2.  Section STUN usa= ge

 <= /p>

Rouge Client can include = any domain to which STUN binding response would be received to defeat the p= urpose. The only way to solve the problem would be to use STUN Auth. Though STUN Auth is typically not used with Public STUN servers= , but with STUN servers deployed in the Enterprise premises the situation c= ould change.  http://tools.ietf.org/html/dra= ft-ietf-rtcweb-use-cases-and-requirements-12#section-3.3.5 explains the use case of enterprise deploying STUN server.

 <= /p>

-Tiru.<= /p>

From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko
Sent: Friday, January 10, 2014 7:21 AM
To: tram@ietf.org; yoakum@avaya.com; justin@uberti.n= ame; alan.b.johnston@gmail.com;= kundan10@gmail.com
Subject: [tram] draft-johnston-tram-stun-origin-00=

 

Hi

I've been reviewing t= he draft http://www.ietf.org/mail-archive/web/tram/current/maillist.html .<= /o:p>

The general idea definitely makes sense.<= /p>

 

Large TURN servers ma= y indeed need separate realms for separate groups of users. It would make t= he administration more structured. Also, the TURN server may provide differ= ent level of services for different realms. For example, the "front" TURN server may just redirect w= ith 300 error different origins to different backend servers with different= configurations.

One thing that I wish= to be included into the draft would be the exact new STUN attribute value = (section 2). Without that value, a test/proof of concept implementation can= not be done. I'd suggest a definition like:

#define STUN_ATTRIBUTE_AGENT_ORIGIN (0x802F)

The value 0x802F is i= n comprehensive-optional range, and it is not taken (yet).

--_000_913383AAA69FF945B8F946018B75898A24289ED3xmbrcdx10ciscoc_-- From simon.perreault@viagenie.ca Mon Jan 13 05:55:20 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955EA1AE15B for ; Mon, 13 Jan 2014 05:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWSSYxI3KUun for ; Mon, 13 Jan 2014 05:55:18 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 508C11AE177 for ; Mon, 13 Jan 2014 05:55:18 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 33CFC403E6 for ; Mon, 13 Jan 2014 08:55:07 -0500 (EST) Message-ID: <52D3F03A.6060201@viagenie.ca> Date: Mon, 13 Jan 2014 08:55:06 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "tram@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tram] BoF request posted X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 13:55:20 -0000 All, After discussing with our benevolent ADs we came to the conclusion that it would be better process-wise to hold a BoF in London, rather than try to form WG directly. Consequently, here's the formal BoF request: http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#TRAM Comments, suggestions, questions? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From alan.b.johnston@gmail.com Mon Jan 13 08:23:39 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34171AE185 for ; Mon, 13 Jan 2014 08:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHfndgOHMJ5E for ; Mon, 13 Jan 2014 08:23:31 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id E18461AE190 for ; Mon, 13 Jan 2014 08:23:26 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id q58so2443044wes.7 for ; Mon, 13 Jan 2014 08:23:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xCaTEkZrk5WsviL5ZOtu+lUXteHC2j9owKQPFmXjXbA=; b=Dk85x3VEokZxIKkHFBrl4boD5dtjDpE+3pfWlvS1U4jPeuRtHBnyIAhNvmY3Xswve9 LnD5w+pmt7EtSDDFB1I4NBtFrJykWouhxjpdTql4JCdLUJO2DspM/Y/vKQztmG5exrRO rWYd8ykkV6QQemH78Y09LdYEaq/w1kNXyw+6QYBDSzMkmRv1AktXAtvPNxrKz1phf/pO cc1sSVhSN0U4bsLTAC/yKaSy6PKfRSxt2t+V13RBJ4C/56w4ibq7V/eb9B9gvaKzxbYw KzBv26jgL7BoOhbhYIK38C6kQbpz17gQ/xFH8vWnuiehkmSja4SosDOYe0A5XkaqTCcb q9dQ== MIME-Version: 1.0 X-Received: by 10.194.59.164 with SMTP id a4mr14007wjr.95.1389630195332; Mon, 13 Jan 2014 08:23:15 -0800 (PST) Received: by 10.216.152.2 with HTTP; Mon, 13 Jan 2014 08:23:15 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A24289ED3@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A24289ED3@xmb-rcd-x10.cisco.com> Date: Mon, 13 Jan 2014 10:23:15 -0600 Message-ID: From: Alan Johnston To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=047d7ba981ae297a5a04efdc7e1a Cc: "justin@uberti.name" , Oleg Moskalenko , "tram@ietf.org" , "kundan10@gmail.com" , "yoakum@avaya.com" Subject: Re: [tram] draft-johnston-tram-stun-origin-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 16:23:40 -0000 --047d7ba981ae297a5a04efdc7e1a Content-Type: text/plain; charset=ISO-8859-1 Tiru, Thanks for your comments - I'm glad you like the draft. See below for a few comments and replies. - Alan - On Mon, Jan 13, 2014 at 7:27 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > I like the draft, it solves the multiple realm problem we were > discussing in BEHAVE WG sometime back > http://tools.ietf.org/html/draft-reddy-behave-turn-auth-04 > > > > 5. Hosting multiple realms on a single IP address is challenging > > with TURN. When a TURN server needs to send the REALM attribute > > in response to an unauthenticated request, it has no useful > > information for determining which realm it should send, except > > the source transport address of the TURN request. Note this is a > > problem with multi-tenant scenarios only. This may not be a > > problem when TURN server is located in enterprise premises. > > > > My initial comments > > > > 1. Section Security Considerations > > > > Comment 1> On-path attacker can do much more damage like modifying the > payload, dropping the packet etc. The more interesting scenario would be > passive attacker sniffing the on-wire packets and can thus determine the > value in the ORIGIN header. > That is true. A passive attacker sniffing a STUN packet would be able to determine the ORIGIN. The passive attacker might also be able to sniff DNS and HTTP traffic which would provide the same information, unless, as we point out in the draft, HTTPS and DNSSEC are both used. > > Comment 2> DTLS could also solve the problem with the server_name > extension defined RFC6066. > > Is there need for ORIGIN STUN attribute if DTLS is used with server_name > extension ? > I'll take a look at RFC 6066 and see if it solves the problem. Is RFC 6066 widely implemented and used? > > > Comment 3> ORIGN attribute would be typically used before long-term > authentication has started. In what scenarios content of ORIGIN attribute > will be integrity protected ? > The ORIGIN attribute will be present both before and after authentication, so after authentication it will be integrity protected by the MESSAGE-INTEGRITY attribute, right? > > > 2. Section STUN usage > > > > Rouge Client can include any domain to which STUN binding response would > be received to defeat the purpose. The only way to solve the problem would > be to use STUN Auth. Though STUN Auth is typically not used with Public > STUN servers, but with STUN servers deployed in the Enterprise premises the > situation could change. > http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-12#section-3.3.5explains the use case of enterprise deploying STUN server. > Yes, ORIGIN doesn't replace authentication. However, in the WebRTC case, it would require a rogue or hacked browser. I think this draft helps solve that use case for enterprise users who are out on the public Internet. An enterprise STUN server could use the attribute to determine which STUN requests from the public Internet it should respond to. > > > -Tiru. > > *From:* tram [mailto:tram-bounces@ietf.org ] *On > Behalf Of *Oleg Moskalenko > *Sent:* Friday, January 10, 2014 7:21 AM > *To:* tram@ietf.org; yoakum@avaya.com; justin@uberti.name; > alan.b.johnston@gmail.com; kundan10@gmail.com > *Subject:* [tram] draft-johnston-tram-stun-origin-00 > > > > Hi > > I've been reviewing the draft > http://www.ietf.org/mail-archive/web/tram/current/maillist.html . > > The general idea definitely makes sense. > > > > Large TURN servers may indeed need separate realms for separate groups of > users. It would make the administration more structured. Also, the TURN > server may provide different level of services for different realms. For > example, the "front" TURN server may just redirect with 300 error different > origins to different backend servers with different configurations. > > One thing that I wish to be included into the draft would be the exact new > STUN attribute value (section 2). Without that value, a test/proof of > concept implementation cannot be done. I'd suggest a definition like: > > #define STUN_ATTRIBUTE_AGENT_ORIGIN (0x802F) > > The value 0x802F is in comprehensive-optional range, and it is not taken > (yet). > > Thanks > Oleg > http://code.google.com/p/rfc5766-turn-server/ > --047d7ba981ae297a5a04efdc7e1a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Tiru,

Thanks for your comments - I'= m glad you like the draft. =A0See below for a few comments and replies.

- Alan -



On Mon, Jan 13, 2014 at 7:27 AM, Tirumal= eswar Reddy (tireddy) <tireddy@cisco.com> wrote:

I like the draft, it solv= es the multiple realm problem we were discussing in BEHAVE WG sometime back http://tools.ietf.org/html/draft-reddy-behave-turn-auth-04

=A0

=A0=A0 5.=A0 Hosting multiple realms on a single IP addres= s is challenging

=A0=A0=A0=A0=A0=A0 with TURN.=A0 When a TURN server needs = to send the REALM attribute

=A0=A0=A0=A0=A0=A0 in response to an unauthenticated reque= st, it has no useful

=A0=A0=A0=A0=A0=A0 information for determining which realm= it should send, except

=A0=A0=A0=A0=A0=A0 the source transport address of the TUR= N request.=A0 Note this is a

=A0=A0=A0=A0=A0=A0 problem with multi-tenant scenarios onl= y.=A0 This may not be a

=A0=A0=A0=A0=A0=A0 problem when TURN server is located in = enterprise premises.

=A0<= /p>

My initial comments

=A0<= /p>

1.=A0 Section Security Co= nsiderations

=A0<= /p>

Comment 1>=A0 On-path = attacker can do much more damage like modifying the payload, dropping the p= acket etc. The more interesting scenario would be passive attacker sniffing the on-wire packets and can thus determine the value in the ORIGI= N header.



=A0<= /p>

Comment 2>=A0 DTLS cou= ld also solve the problem with the server_name extension defined RFC6066.

Is there need for ORIGIN = STUN attribute if DTLS is used with server_name extension ?


I'll take a look at RFC 6066 and= see if it solves the problem. =A0Is RFC 6066 widely implemented and used?<= /div>
=A0

=A0<= /p>

Comment 3> =A0ORIGN at= tribute would be typically used before long-term authentication has started= . In what scenarios content of ORIGIN attribute will be integrity protected ?


The ORI= GIN attribute will be present both before and after authentication, so afte= r authentication it will be integrity protected by the MESSAGE-INTEGRITY at= tribute, right?
=A0

=A0

=A0<= /p>

-Tiru.

From: tram [mailto:tram-bounce= s@ietf.org] On Behalf Of Oleg Moskalenko
Sent: Friday, January 10, 2014 7:21 AM
To: tram@ietf.org= ; yoakum@avaya.com; justin@uberti.name; alan.b.johns= ton@gmail.com; kundan10@gmail.com
Subject: [tram] draft-johnston-tram-stun-origin-00

=A0

The general idea definitely makes sense.

=A0

Large TURN servers ma= y indeed need separate realms for separate groups of users. It would make t= he administration more structured. Also, the TURN server may provide differ= ent level of services for different realms. For example, the "front" TURN server may just redirect w= ith 300 error different origins to different backend servers with different= configurations.

One thing that I wish= to be included into the draft would be the exact new STUN attribute value = (section 2). Without that value, a test/proof of concept implementation can= not be done. I'd suggest a definition like:

#define STUN_ATTRIBUTE_AGENT_ORIGIN (0x802F)

The value 0x802F is i= n comprehensive-optional range, and it is not taken (yet).


--047d7ba981ae297a5a04efdc7e1a-- From mom040267@gmail.com Mon Jan 13 11:07:45 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FAF1ADF48 for ; Mon, 13 Jan 2014 11:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muab6vG_5QUa for ; Mon, 13 Jan 2014 11:07:43 -0800 (PST) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id D82051ADF30 for ; Mon, 13 Jan 2014 11:07:43 -0800 (PST) Received: by mail-pd0-f178.google.com with SMTP id v10so1264478pde.23 for ; Mon, 13 Jan 2014 11:07:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LdX1yX28/JyH36hrBXBsq9BIvpIIFqfeckMWNb0dkUY=; b=psIumK1z4zHGPsuBpvIWURdAEfWxZpZsNJxusB2l9PIZTDgqX8e7XtrZkzDuYsK2Q5 Dw5WyBJHLUmAyHEyCMi0lbx+LIsovnzMu4AkMbZfKsOU1P6oydJXfMpKLVMkFuICGRbN sQWsJm+weRynucn17oY0Urmr1UvVeVZNNkmxAbLhisl45ukcwv7aMnxRCtfDSAo5N0Rr s9NMmOevRzCwH4edfJ9DsGl/e9Ccv0Bw43JnY9BjFaCuusn686dTGmIiv8AWBDhWdv9O +SG7E0P1mnH1jxopas0IF7KVgimNczNXC4J2B/Enlvz9MoHrJomXlZwWNrwQ+zfD7464 D8VQ== MIME-Version: 1.0 X-Received: by 10.68.170.66 with SMTP id ak2mr31357896pbc.5.1389640052952; Mon, 13 Jan 2014 11:07:32 -0800 (PST) Received: by 10.68.147.131 with HTTP; Mon, 13 Jan 2014 11:07:32 -0800 (PST) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A24289ED3@xmb-rcd-x10.cisco.com> Date: Mon, 13 Jan 2014 11:07:32 -0800 Message-ID: From: Oleg Moskalenko To: Alan Johnston Content-Type: multipart/alternative; boundary=047d7b86d55cb8d68404efdec9b7 Cc: "justin@uberti.name" , "kundan10@gmail.com" , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" , "yoakum@avaya.com" Subject: Re: [tram] draft-johnston-tram-stun-origin-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 19:07:45 -0000 --047d7b86d55cb8d68404efdec9b7 Content-Type: text/plain; charset=ISO-8859-1 Hi Alan please see below: On Mon, Jan 13, 2014 at 8:23 AM, Alan Johnston wrote: > > >> >> >> Comment 3> ORIGN attribute would be typically used before long-term >> authentication has started. In what scenarios content of ORIGIN attribute >> will be integrity protected ? >> > > The ORIGIN attribute will be present both before and after authentication, > so after authentication it will be integrity protected by the > MESSAGE-INTEGRITY attribute, right? > > >> I can see the purpose of the ORIGIN in the original ALLOCATE request, BEFORE the authentication. The ORIGIN tells the server which realm to choose. So, implicitly, the ORIGIN afterwards (after the initial authentication and ALLOCATE dialog) is "implied" by the realm and by the session itself. So, why the ORIGIN has to be included into the messages after the initial authentication ? It increases the traffic; but more importantly, it is either redundant (if the ORIGIN value is the same as the "initial" ORIGIN) or malicious (if the ORIGIN is different from the "initial" ORIGIN). I'd suggest to limit the meaningful ORIGIN usage to the initial authentication messages. In all other messages, the ORIGIN may (must) be ignored and it can be used only for the logging purposes. That leaves the interesting case for re-authentication (when in the middle of the TURN session the credentials are expiring and we are requesting re-authentication. I suppose that a practical approach would be that the TURN server must store the "initial" ORIGIN for the whole length of the session and ignore any ORIGIN attributes during the subsequent negotiations. The value of the ORIGIN attribute is not secure (just a hint that is open to everybody listening) and it makes sense only as the initial hint. Thanks Oleg --047d7b86d55cb8d68404efdec9b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Alan

please see below:
<= div class=3D"gmail_extra">

On Mon, Jan 13= , 2014 at 8:23 AM, Alan Johnston <alan.b.johnston@gmail.com>= ; wrote:
=A0

=A0<= /p>

Comment 3> =A0ORIGN at= tribute would be typically used before long-term authentication has started= . In what scenarios content of ORIGIN attribute will be integrity protected ?


T= he ORIGIN attribute will be present both before and after authentication, s= o after authentication it will be integrity protected by the MESSAGE-INTEGR= ITY attribute, right?
=A0


I can s= ee the purpose of the ORIGIN in the original ALLOCATE request, BEFORE the a= uthentication. The ORIGIN tells the server which realm to choose. So, impli= citly, the ORIGIN afterwards (after the initial authentication and ALLOCATE= dialog) is "implied" by the realm and by the session itself. So,= why the ORIGIN has to be included into the messages after the initial auth= entication ? It increases the traffic; but more importantly, it is either r= edundant (if the ORIGIN value is the same as the "initial" ORIGIN= ) or malicious (if the ORIGIN is different from the "initial" ORI= GIN).

I'd suggest to limit the meaningful ORIGIN usage to the = initial authentication messages.=A0 In all other messages, the ORIGIN may (= must) be ignored and it can be used only for the logging purposes.

That leaves the interesting case for re-authentication = (when in the middle of the TURN session the credentials are expiring and we= are requesting re-authentication. I suppose that a practical approach woul= d be that the TURN server must store the "initial" ORIGIN for the= whole length of the session and ignore any ORIGIN attributes during the su= bsequent negotiations. The value of the ORIGIN attribute is not secure (jus= t a hint that is open to everybody listening) and it makes sense only as th= e initial hint.

Thanks
Oleg


--047d7b86d55cb8d68404efdec9b7-- From juberti@google.com Mon Jan 13 17:00:57 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6992D1AE01F for ; Mon, 13 Jan 2014 17:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6w966CEnE-MM for ; Mon, 13 Jan 2014 17:00:54 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id A0B691AE1C5 for ; Mon, 13 Jan 2014 17:00:54 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id at1so1317453iec.28 for ; Mon, 13 Jan 2014 17:00:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6dqnjUrqbrqAWcVjl0RvMauI7p67Z+kOiJstkhOzrok=; b=pg9r79yeZ7/9Nl4l6BURxMsMrd+4CLCiBTeujiXN/gulrsSz0RcKfueVN1oN2b5gy8 irADdXbMbDsaIr+NHBqd4szCGxHoma04FGJi+TXgDSXAtkaE0IFir4euc15KY5uy10xr qOfeaYrp4tdYiUH+qpbqdw2SAneZxiOM/XHrQKE6N+QGTjRF14khqqh+ghJ9gS45Weos AsoExHITplmNKzguOOzdWTEg1z9KnIsuyL0jniIOcNunI9StjZIvOOtN9o0qULeBBmBk Xnu2qxheJFOeYubZj9AScduUr4mMnHtuXqzeKInedmgPkuneSL9xlmllucDHFeJlfWhi JYlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=6dqnjUrqbrqAWcVjl0RvMauI7p67Z+kOiJstkhOzrok=; b=J/5T7LWDsfKqgp50bP4Xzin74JJfpvN+DBgjxk9SJ5YqejBi9V0Qqr5n0GDw+GxZEx OzvkPQOm7vHbFd0f20sD7V3idK2LZobUoU0aVw+IW1l4OSic9iOMvRkQNXJl7uo3uObT cE+pQKWW/t7ufffPWWTmE2YxKB/5XYV1xZc2kPn8mOfS3DcyqycQ8GijNV/e7CqGHDpL CipRxEAqGsG82uU2UqbFOU4bDiOENhcbvmFLv4GPE0BFqIsnNF9GSzEJWRL/1Btv7Tui GwEuRrRQohExVpeBno3S6WxtbcV/+Af+vLLU29xaSOutwbhqONIlNOvlLNu0y1dqbws4 YFYA== X-Gm-Message-State: ALoCoQlqQORmtCy/9S3BONQTx6WVBhT6paF83d4osQf5d8UCvOY/8qlmx+t5RXgFlBuBHq/xVVRXxmOOEmwdeE5frTVufJlciuFg27iyvZtFkW4nfpX5IX6j/5wwdLaVWMnGv15Afrwz5WE/j/D5MzhaG6y/tC6dOPCe4IY9RkmUo722G52sq+Zpd3c8NhRHuh+LI+RnZ3Qr X-Received: by 10.50.128.72 with SMTP id nm8mr21878392igb.10.1389661243344; Mon, 13 Jan 2014 17:00:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.35.67 with HTTP; Mon, 13 Jan 2014 17:00:23 -0800 (PST) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A24289ED3@xmb-rcd-x10.cisco.com> From: Justin Uberti Date: Mon, 13 Jan 2014 17:00:23 -0800 Message-ID: To: Alan Johnston Content-Type: multipart/alternative; boundary=089e013c5af0c4a49d04efe3b81b Cc: "justin@uberti.name" , Oleg Moskalenko , "tram@ietf.org" , "kundan10@gmail.com" , "Tirumaleswar Reddy \(tireddy\)" , "yoakum@avaya.com" Subject: Re: [tram] draft-johnston-tram-stun-origin-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 01:00:57 -0000 --089e013c5af0c4a49d04efe3b81b Content-Type: text/plain; charset=UTF-8 On Mon, Jan 13, 2014 at 8:23 AM, Alan Johnston wrote: > Tiru, > > Thanks for your comments - I'm glad you like the draft. See below for a > few comments and replies. > > - Alan - > > > > On Mon, Jan 13, 2014 at 7:27 AM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > >> I like the draft, it solves the multiple realm problem we were >> discussing in BEHAVE WG sometime back >> http://tools.ietf.org/html/draft-reddy-behave-turn-auth-04 >> >> >> >> 5. Hosting multiple realms on a single IP address is challenging >> >> with TURN. When a TURN server needs to send the REALM attribute >> >> in response to an unauthenticated request, it has no useful >> >> information for determining which realm it should send, except >> >> the source transport address of the TURN request. Note this is a >> >> problem with multi-tenant scenarios only. This may not be a >> >> problem when TURN server is located in enterprise premises. >> >> >> >> My initial comments >> >> >> >> 1. Section Security Considerations >> >> >> >> Comment 1> On-path attacker can do much more damage like modifying the >> payload, dropping the packet etc. The more interesting scenario would be >> passive attacker sniffing the on-wire packets and can thus determine the >> value in the ORIGIN header. >> > > That is true. A passive attacker sniffing a STUN packet would be able to > determine the ORIGIN. The passive attacker might also be able to sniff DNS > and HTTP traffic which would provide the same information, unless, as we > point out in the draft, HTTPS and DNSSEC are both used. > > >> >> Comment 2> DTLS could also solve the problem with the server_name >> extension defined RFC6066. >> >> Is there need for ORIGIN STUN attribute if DTLS is used with server_name >> extension ? >> > > I'll take a look at RFC 6066 and see if it solves the problem. Is RFC > 6066 widely implemented and used? > I am not sure if this works, since it has the same problem as REALM. IOW, the server doesn't know what name or REALM to use prior to the ORIGIN being sent by the client. > > >> >> >> Comment 3> ORIGN attribute would be typically used before long-term >> authentication has started. In what scenarios content of ORIGIN attribute >> will be integrity protected ? >> > > The ORIGIN attribute will be present both before and after authentication, > so after authentication it will be integrity protected by the > MESSAGE-INTEGRITY attribute, right? > True. One possible implication would be that the TURN server needs to wait for an authenticated message containing ORIGIN before making a decision, or perhaps, that ORIGIN should not be included in unauthenticated TURN messages. (This is all avoided when using DTLS though.) > > >> >> >> 2. Section STUN usage >> >> >> >> Rouge Client can include any domain to which STUN binding response would >> be received to defeat the purpose. The only way to solve the problem would >> be to use STUN Auth. Though STUN Auth is typically not used with Public >> STUN servers, but with STUN servers deployed in the Enterprise premises the >> situation could change. >> http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-12#section-3.3.5explains the use case of enterprise deploying STUN server. >> > > Yes, ORIGIN doesn't replace authentication. However, in the WebRTC case, > it would require a rogue or hacked browser. I think this draft helps solve > that use case for enterprise users who are out on the public Internet. An > enterprise STUN server could use the attribute to determine which STUN > requests from the public Internet it should respond to. > > >> >> >> -Tiru. >> >> *From:* tram [mailto:tram-bounces@ietf.org ] *On >> Behalf Of *Oleg Moskalenko >> *Sent:* Friday, January 10, 2014 7:21 AM >> *To:* tram@ietf.org; yoakum@avaya.com; justin@uberti.name; >> alan.b.johnston@gmail.com; kundan10@gmail.com >> *Subject:* [tram] draft-johnston-tram-stun-origin-00 >> >> >> >> Hi >> >> I've been reviewing the draft >> http://www.ietf.org/mail-archive/web/tram/current/maillist.html . >> >> The general idea definitely makes sense. >> >> >> >> Large TURN servers may indeed need separate realms for separate groups of >> users. It would make the administration more structured. Also, the TURN >> server may provide different level of services for different realms. For >> example, the "front" TURN server may just redirect with 300 error different >> origins to different backend servers with different configurations. >> >> One thing that I wish to be included into the draft would be the exact >> new STUN attribute value (section 2). Without that value, a test/proof of >> concept implementation cannot be done. I'd suggest a definition like: >> >> #define STUN_ATTRIBUTE_AGENT_ORIGIN (0x802F) >> >> The value 0x802F is in comprehensive-optional range, and it is not taken >> (yet). >> >> Thanks >> Oleg >> http://code.google.com/p/rfc5766-turn-server/ >> > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --089e013c5af0c4a49d04efe3b81b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Jan 13, 2014 at 8:23 AM, Alan Johnston &l= t;alan.b.joh= nston@gmail.com> wrote:
Tiru,

Th= anks for your comments - I'm glad you like the draft. =C2=A0See below f= or a few comments and replies.

- Alan -



On Mon, Jan 13, 2014 a= t 7:27 AM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> = wrote:

I like the draft, it solv= es the multiple realm problem we were discussing in BEHAVE WG sometime back http://tools.ietf.org/html/draft-reddy-behave-turn-auth-04

=C2=A0

=C2=A0=C2=A0 5.=C2=A0 Hosting multiple realms on a single = IP address is challenging

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 with TURN.=C2=A0 When= a TURN server needs to send the REALM attribute

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in response to an una= uthenticated request, it has no useful

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 information for deter= mining which realm it should send, except

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the source transport = address of the TURN request.=C2=A0 Note this is a

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 problem with multi-te= nant scenarios only.=C2=A0 This may not be a

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 problem when TURN ser= ver is located in enterprise premises.

=C2=A0

My initial comments

=C2=A0

1.=C2=A0 Section Security= Considerations

=C2=A0

Comment 1>=C2=A0 On-pa= th attacker can do much more damage like modifying the payload, dropping th= e packet etc. The more interesting scenario would be passive attacker sniffing the on-wire packets and can thus determine the value in the ORIGI= N header.



=C2=A0

Comment 2>=C2=A0 DTLS = could also solve the problem with the server_name extension defined RFC6066= .

Is there need for ORIGIN = STUN attribute if DTLS is used with server_name extension ?


I'll take a look at RFC 60= 66 and see if it solves the problem. =C2=A0Is RFC 6066 widely implemented a= nd used?

=
=C2=A0

=C2=A0

Comment 3> =C2=A0ORIGN= attribute would be typically used before long-term authentication has star= ted. In what scenarios content of ORIGIN attribute will be integrity protected ?


T= he ORIGIN attribute will be present both before and after authentication, s= o after authentication it will be integrity protected by the MESSAGE-INTEGR= ITY attribute, right?

True. One possible impli= cation would be that the TURN server needs to wait for an authenticated mes= sage containing ORIGIN before making a decision, or perhaps, that ORIGIN sh= ould not be included in unauthenticated TURN messages. (This is all avoided= when using DTLS though.)
=
=C2=A0

=C2=A0

=C2=A0

-Tiru.

=C2=A0

The general idea definitely makes sense.

=C2=A0

Large TURN servers ma= y indeed need separate realms for separate groups of users. It would make t= he administration more structured. Also, the TURN server may provide differ= ent level of services for different realms. For example, the "front" TURN server may just redirect w= ith 300 error different origins to different backend servers with different= configurations.

One thing that I wish= to be included into the draft would be the exact new STUN attribute value = (section 2). Without that value, a test/proof of concept implementation can= not be done. I'd suggest a definition like:

#define STUN_ATTRIBUTE_AGENT_ORIGIN (0x802F)

The value 0x802F is i= n comprehensive-optional range, and it is not taken (yet).



_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--089e013c5af0c4a49d04efe3b81b-- From mom040267@gmail.com Mon Jan 13 17:09:29 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2621A1ADFAE for ; Mon, 13 Jan 2014 17:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MH2en83M-lor for ; Mon, 13 Jan 2014 17:09:27 -0800 (PST) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id D986F1ADA5D for ; Mon, 13 Jan 2014 17:09:27 -0800 (PST) Received: by mail-pb0-f41.google.com with SMTP id jt11so8012894pbb.14 for ; Mon, 13 Jan 2014 17:09:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ymsCO+EgY5zQ73GTicK3PAVOhcWFyI+T+YOlxbnOKmg=; b=O2PDkI2uv7ePC5elWmP6gHPsR7eoznNVIfxva/vfgaeHUdpDh5CaIKWkxrIFkbbCx5 D/8jUmiFL5jKbTf9T6GmV4uIer6ddi2svvVHRy09sKh0ginDBM9VpY7ocXxKH/IsWZfK FS0JVV27ssjpKE/LPUW6VOvxCrBysDlJOzCW7+CUQrkXj6dbgcsDPiELfAgY1I+jip5e qyMjwE1jFPaB5DXILJdM80vHQX/nQcJjUVbARq5CwKewXaLvi4DHmTT4YAFFCRQ3qtAW TAp8g1JMXBbgxti+9rWTAsASgDRpdloSzh1+N24+0J703pkRO5T5IRNUQlbPaLzX3NE3 nYMQ== MIME-Version: 1.0 X-Received: by 10.66.160.2 with SMTP id xg2mr33022092pab.23.1389661756775; Mon, 13 Jan 2014 17:09:16 -0800 (PST) Received: by 10.68.147.131 with HTTP; Mon, 13 Jan 2014 17:09:16 -0800 (PST) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A24289ED3@xmb-rcd-x10.cisco.com> Date: Mon, 13 Jan 2014 17:09:16 -0800 Message-ID: From: Oleg Moskalenko To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7bacb47c5eeaf304efe3d7e2 Cc: "justin@uberti.name" , "tram@ietf.org" , "kundan10@gmail.com" , "Tirumaleswar Reddy \(tireddy\)" , "yoakum@avaya.com" , Alan Johnston Subject: Re: [tram] draft-johnston-tram-stun-origin-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 01:09:29 -0000 --047d7bacb47c5eeaf304efe3d7e2 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 13, 2014 at 5:00 PM, Justin Uberti wrote: > > > The ORIGIN attribute will be present both before and after authentication, >> so after authentication it will be integrity protected by the >> MESSAGE-INTEGRITY attribute, right? >> > > True. One possible implication would be that the TURN server needs to wait > for an authenticated message containing ORIGIN before making a decision, or > perhaps, that ORIGIN should not be included in unauthenticated TURN > messages. (This is all avoided when using DTLS though.) > Justin, that would not work that way. For authentication, we must know the realm - and so we need the ORIGIN value before any authentication can be done. That would be catch 22. To the contrary, I believe that ORIGIN must appear in unauthenticated messages only, to signal to the server which realm to choose. In the already authenticated messages, it has no sense, albeit for logging. The idea was to provide a hint to the TURN server which realm to choose. And that hint is totally optional, in comprehension-optional range. The TURN server may ignore it altogether, or it may use it for whatever realm choosing algorithm it implements. That new ORIGIN attribute must not carry any "hard" meaning, and it must not be scrutinized by the server. That is just a hint (but a valuable one). Regards, Oleg --047d7bacb47c5eeaf304efe3d7e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jan 13, 2014 at 5:00 PM, Justin Uberti &l= t;juberti@google.co= m> wrote:


The ORIGIN attribute will be present both before and after authentication,= so after authentication it will be integrity protected by the MESSAGE-INTE= GRITY attribute, right?

True. One possible= implication would be that the TURN server needs to wait for an authenticat= ed message containing ORIGIN before making a decision, or perhaps, that ORI= GIN should not be included in unauthenticated TURN messages. (This is all a= voided when using DTLS though.)


Justin, that would n= ot work that way. For authentication, we must know the realm - and so we ne= ed the ORIGIN value before any authentication can be done. That would be ca= tch 22.

To the contrary, I believe that ORIGIN must appear in unauth= enticated messages only, to signal to the server which realm to choose. In = the already authenticated messages, it has no sense, albeit for logging.
The idea was to provide a hint to the TURN server which realm to choose= . And that hint is totally optional, in comprehension-optional range. The T= URN server may ignore it altogether, or it may use it for whatever realm ch= oosing algorithm it implements.

That new ORIGIN attribute must not carry any "hard"= ; meaning, and it must not be scrutinized by the server. That is just a hin= t (but a valuable one).

Regards,
Oleg
=A0

--047d7bacb47c5eeaf304efe3d7e2-- From alan.b.johnston@gmail.com Mon Jan 13 18:34:20 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0E61ADFE4 for ; Mon, 13 Jan 2014 18:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdqb5xIxdpaL for ; Mon, 13 Jan 2014 18:34:18 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 739C41ACCE8 for ; Mon, 13 Jan 2014 18:34:18 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id hq4so137027wib.2 for ; Mon, 13 Jan 2014 18:34:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CiWVS2cQI399W7OfHZLQFhkMRLNx75xUGV8ZIxMeyMc=; b=uw+UNfQv9sQxA9VhVpvktMSK2ZHc2/FWi61fKSi7djNljDKK6BOCdlFc5ZrRGz/cXo 6hCYN3tvojqyxzwg/w3BmRtOL20q2WWkZuh9Tks99/AfUlPh6DBkaqAWNWD0O2IPd1uh jtP3uS9LcTlf4TyOYWDIbM6Mtn7pnCeqJesMiR6RAexUPHmc1YGUJ4VSyyiPYDsiTWWi ZtNfCPRRgIVJNvdHdBQueqQfBAM/eP8bPWlvg5lwS3lbIdR76o8BXtk84Ms9tQfB83/o EmTQwxzkcdyFgE4ELSw39QNNUkm2wJc9EUufhGZzFlUzv0NKdp5GHhq9JyCplRdoY9gU 9cmA== MIME-Version: 1.0 X-Received: by 10.180.11.34 with SMTP id n2mr18179641wib.40.1389666846777; Mon, 13 Jan 2014 18:34:06 -0800 (PST) Received: by 10.216.152.2 with HTTP; Mon, 13 Jan 2014 18:34:06 -0800 (PST) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A24289ED3@xmb-rcd-x10.cisco.com> Date: Mon, 13 Jan 2014 20:34:06 -0600 Message-ID: From: Alan Johnston To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=001a11c25c1ac2275904efe50640 Cc: "justin@uberti.name" , "tram@ietf.org" , Justin Uberti , "kundan10@gmail.com" , "Tirumaleswar Reddy \(tireddy\)" , "yoakum@avaya.com" Subject: Re: [tram] draft-johnston-tram-stun-origin-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 02:34:20 -0000 --001a11c25c1ac2275904efe50640 Content-Type: text/plain; charset=ISO-8859-1 I agree with Oleg. ORIGIN is useful for logging and also as a hint for realm selection. It is up to the server what to do with it. A common behavior is what he describes: before authentication, the TURN server may find it very useful. After authentication, less so, but it could still be logged. Also, remember that there isn't necessarily a 1:1 relation between origins and realms. So in cases where a realm is shared among a number of origins, logging the origin may still be useful for the server. I'm reluctant to define too strict usage of ORIGIN. I think it makes sense to say it should not be used where we can't come up with any use cases (such as the short-term authenticated ICE usage of STUN), but I think we should allow it for all other STUN uses, both before and after authentication. This is simpler and will cover the widest set of (current and future) use cases. The exception is where we can show that it somehow does real harm. - Alan - On Mon, Jan 13, 2014 at 7:09 PM, Oleg Moskalenko wrote: > > > > On Mon, Jan 13, 2014 at 5:00 PM, Justin Uberti wrote: > >> >> >> The ORIGIN attribute will be present both before and after >>> authentication, so after authentication it will be integrity protected by >>> the MESSAGE-INTEGRITY attribute, right? >>> >> >> True. One possible implication would be that the TURN server needs to >> wait for an authenticated message containing ORIGIN before making a >> decision, or perhaps, that ORIGIN should not be included in unauthenticated >> TURN messages. (This is all avoided when using DTLS though.) >> > > > Justin, that would not work that way. For authentication, we must know the > realm - and so we need the ORIGIN value before any authentication can be > done. That would be catch 22. > > To the contrary, I believe that ORIGIN must appear in unauthenticated > messages only, to signal to the server which realm to choose. In the > already authenticated messages, it has no sense, albeit for logging. > > The idea was to provide a hint to the TURN server which realm to choose. > And that hint is totally optional, in comprehension-optional range. The > TURN server may ignore it altogether, or it may use it for whatever realm > choosing algorithm it implements. > > That new ORIGIN attribute must not carry any "hard" meaning, and it must > not be scrutinized by the server. That is just a hint (but a valuable one). > > Regards, > Oleg > > > --001a11c25c1ac2275904efe50640 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree with Oleg.

ORIGIN is useful for= logging and also as a hint for realm selection. =A0It is up to the server = what to do with it. =A0A common behavior is what he describes: before authe= ntication, the TURN server may find it very useful. =A0After authentication= , less so, but it could still be logged. =A0Also, remember that there isn&#= 39;t necessarily a 1:1 relation between origins and realms. =A0So in cases = where a realm is shared among a number of origins, logging the origin may s= till be useful for the server.

I'm reluctant to define too strict usage of ORIGIN.= =A0I think it makes sense to say it should not be used where we can't = come up with any use cases (such as the short-term authenticated ICE usage = of STUN), but I think we should allow it for all other STUN uses, both befo= re and after authentication. =A0This is simpler and will cover the widest s= et of (current and future) use cases. =A0The exception is where we can show= that it somehow does real harm.

- Alan -


=
On Mon, Jan 13, 2014 at 7:09 PM, Oleg Moskalenko= <mom040267@gmail.com> wrote:



On Mon, Jan 13, 2014 at 5:00 PM, Jus= tin Uberti <juberti@google.com> wrote:


The ORIGIN attribute will be present both before and after authentication,= so after authentication it will be integrity protected by the MESSAGE-INTE= GRITY attribute, right?

True. One possible= implication would be that the TURN server needs to wait for an authenticat= ed message containing ORIGIN before making a decision, or perhaps, that ORI= GIN should not be included in unauthenticated TURN messages. (This is all a= voided when using DTLS though.)


Justin, that would n= ot work that way. For authentication, we must know the realm - and so we ne= ed the ORIGIN value before any authentication can be done. That would be ca= tch 22.

To the contrary, I believe that ORIGIN must appear in unauth= enticated messages only, to signal to the server which realm to choose. In = the already authenticated messages, it has no sense, albeit for logging.
The idea was to provide a hint to the TURN server which realm to choose= . And that hint is totally optional, in comprehension-optional range. The T= URN server may ignore it altogether, or it may use it for whatever realm ch= oosing algorithm it implements.

That new ORIGIN attribute must not carry any "hard"= ; meaning, and it must not be scrutinized by the server. That is just a hin= t (but a valuable one).

Regards,
Oleg
=A0


--001a11c25c1ac2275904efe50640-- From tireddy@cisco.com Mon Jan 13 20:35:38 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3D11AE1AB for ; Mon, 13 Jan 2014 20:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eulanHBOkTzk for ; Mon, 13 Jan 2014 20:35:36 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 56DD61ADE7C for ; Mon, 13 Jan 2014 20:35:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4873; q=dns/txt; s=iport; t=1389674125; x=1390883725; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=58GZ5jmrswWl2xWWz9xoYo0so/CAjY27m+PhCLbJJHA=; b=h+o5wkOWgrrk4ej9jxkQ+URMavuhWv+yQKuRvlTRuoJbuN6GvpaRmUu6 gDyagfgBRo+04hCW7hyndQuP3Xxmuq1yDwL86ZXe+ZsMxkBCMDkEud2ln 8hEwmiOh546mtIKyblvkf5qa0SCBvAzy1djQ7a8SQdWkX6k4gX860h9ka g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAES+1FKtJXG9/2dsb2JhbABagws4VroDgRcWdIIlAQEBBHkSAQgRBAEBCx0oERQJCQEEDgUIAYdnAxENwBANhR0XjHSBQgEBHg8iAguDHoETBIkLjSCDHIsqhTuDLYFxOQ X-IronPort-AV: E=Sophos;i="4.95,656,1384300800"; d="scan'208";a="12621918" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-2.cisco.com with ESMTP; 14 Jan 2014 04:35:24 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0E4ZOxo014145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Jan 2014 04:35:24 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Mon, 13 Jan 2014 22:35:24 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Alan Johnston Thread-Topic: [tram] draft-johnston-tram-stun-origin-00 Thread-Index: Ac8Q4gdXHlfzlqoYSOWbfPzyDua7mw== Date: Tue, 14 Jan 2014 04:35:24 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2428A843@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.36.11] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "justin@uberti.name" , Oleg Moskalenko , "tram@ietf.org" , "kundan10@gmail.com" , "yoakum@avaya.com" Subject: Re: [tram] draft-johnston-tram-stun-origin-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 04:35:38 -0000 Hi Alan, Please see inline [TR] From: Alan Johnston [mailto:alan.b.johnston@gmail.com]=20 Sent: Monday, January 13, 2014 9:53 PM To: Tirumaleswar Reddy (tireddy) Cc: Oleg Moskalenko; tram@ietf.org; yoakum@avaya.com; justin@uberti.name; k= undan10@gmail.com Subject: Re: [tram] draft-johnston-tram-stun-origin-00 Tiru, Thanks for your comments - I'm glad you like the draft. =A0See below for a = few comments and replies. - Alan - On Mon, Jan 13, 2014 at 7:27 AM, Tirumaleswar Reddy (tireddy) wrote: I like the draft, it solves the multiple realm problem we were discussing i= n BEHAVE WG sometime back http://tools.ietf.org/html/draft-reddy-behave-tur= n-auth-04 =A0 =A0=A0 5.=A0 Hosting multiple realms on a single IP address is challenging =A0=A0=A0=A0=A0=A0 with TURN.=A0 When a TURN server needs to send the REALM= attribute =A0=A0=A0=A0=A0=A0 in response to an unauthenticated request, it has no use= ful =A0=A0=A0=A0=A0=A0 information for determining which realm it should send, = except =A0=A0=A0=A0=A0=A0 the source transport address of the TURN request.=A0 Not= e this is a =A0=A0=A0=A0=A0=A0 problem with multi-tenant scenarios only.=A0 This may no= t be a =A0=A0=A0=A0=A0=A0 problem when TURN server is located in enterprise premis= es. =A0 My initial comments =A0 1.=A0 Section Security Considerations =A0 Comment 1>=A0 On-path attacker can do much more damage like modifying the p= ayload, dropping the packet etc. The more interesting scenario would be pas= sive attacker sniffing the on-wire packets and can thus determine the value= in the ORIGIN header. That is true. =A0A passive attacker sniffing a STUN packet would be able to= determine the ORIGIN. =A0The passive attacker might also be able to sniff = DNS and HTTP traffic which would provide the same information, unless, as w= e point out in the draft, HTTPS and DNSSEC are both used. =A0 Comment 2>=A0 DTLS could also solve the problem with the server_name extens= ion defined RFC6066. Is there need for ORIGIN STUN attribute if DTLS is used with server_name ex= tension ? I'll take a look at RFC 6066 and see if it solves the problem. =A0Is RFC 60= 66 widely implemented and used? [TR] Yes =A0 =A0 Comment 3> =A0ORIGN attribute would be typically used before long-term auth= entication has started. In what scenarios content of ORIGIN attribute will = be integrity protected ? The ORIGIN attribute will be present both before and after authentication, = so after authentication it will be integrity protected by the MESSAGE-INTEG= RITY attribute, right? [TR] After authentication I don't see a need for including ORIGIN attribute= . =A0 =A0 2.=A0 Section STUN usage =A0 Rouge Client can include any domain to which STUN binding response would be= received to defeat the purpose. The only way to solve the problem would be= to use STUN Auth. Though STUN Auth is typically not used with Public STUN = servers, but with STUN servers deployed in the Enterprise premises the situ= ation could change. =A0http://tools.ietf.org/html/draft-ietf-rtcweb-use-cas= es-and-requirements-12#section-3.3.5 explains the use case of enterprise de= ploying STUN server. Yes, ORIGIN doesn't replace authentication. =A0However, in the WebRTC case,= it would require a rogue or hacked browser. =A0I think this draft helps so= lve that use case for enterprise users who are out on the public Internet. = =A0An enterprise STUN server could use the attribute to determine which STU= N requests from the public Internet it should respond to. =A0 [TR] Ok =A0 -Tiru. From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko Sent: Friday, January 10, 2014 7:21 AM To: tram@ietf.org; yoakum@avaya.com; justin@uberti.name; alan.b.johnston@gm= ail.com; kundan10@gmail.com Subject: [tram] draft-johnston-tram-stun-origin-00 =A0 Hi I've been reviewing the draft http://www.ietf.org/mail-archive/web/tram/cur= rent/maillist.html . The general idea definitely makes sense. =A0 Large TURN servers may indeed need separate realms for separate groups of u= sers. It would make the administration more structured. Also, the TURN serv= er may provide different level of services for different realms. For exampl= e, the "front" TURN server may just redirect with 300 error different origi= ns to different backend servers with different configurations. One thing that I wish to be included into the draft would be the exact new = STUN attribute value (section 2). Without that value, a test/proof of conce= pt implementation cannot be done. I'd suggest a definition like: #define STUN_ATTRIBUTE_AGENT_ORIGIN (0x802F) The value 0x802F is in comprehensive-optional range, and it is not taken (y= et). Thanks Oleg http://code.google.com/p/rfc5766-turn-server/ From tireddy@cisco.com Mon Jan 13 20:38:24 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10CB01ADE7C for ; Mon, 13 Jan 2014 20:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.038 X-Spam-Level: X-Spam-Status: No, score=-15.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZNYFc7VUEh6 for ; Mon, 13 Jan 2014 20:38:22 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBC91ADDD2 for ; Mon, 13 Jan 2014 20:38:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9249; q=dns/txt; s=iport; t=1389674291; x=1390883891; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CtlvgyY6EOxFw6vlWLirdNTl6sbzoMNV2DL7bpu2Ypk=; b=OEbFHSXhpAn+INO3PIDHKOZo8BtFiHV/rTIQXowTCI0mOGPfct5o+9Bi in9Jcz4/8BqNrxGrFtJ+h3xqYrkmyN2/VfJ1lWttrnLia46NQMFLFVpJG Z7YyVTJrH3Op/6L41ZDLv1ngiLyIJtc9vm1Uz7az/k5jqHNrOX14ZnHYI o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsFAPm+1FKtJXG+/2dsb2JhbABagkdEOFa6A4EXFnSCJQEBAQQtTBACAQgOAwQBAQsdByERFAkIAgQBDQUIh2gDEcAdDYUdF4x0gTwmMQYBBoMegRMEliuORoU7gy2BaUE X-IronPort-AV: E=Sophos;i="4.95,656,1384300800"; d="scan'208,217";a="297087168" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 14 Jan 2014 04:38:05 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0E4c5Ff017030 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Jan 2014 04:38:05 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Mon, 13 Jan 2014 22:38:04 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko , Alan Johnston Thread-Topic: [tram] draft-johnston-tram-stun-origin-00 Thread-Index: AQHPEHvEFSLGVVMMqEWZyl5wn32FYpqDaQkAgAA6qfA= Date: Tue, 14 Jan 2014 04:38:04 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2428A857@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A24289ED3@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.36.11] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A2428A857xmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "justin@uberti.name" , "tram@ietf.org" , "kundan10@gmail.com" , "yoakum@avaya.com" Subject: Re: [tram] draft-johnston-tram-stun-origin-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 04:38:24 -0000 --_000_913383AAA69FF945B8F946018B75898A2428A857xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Oleg response. -Tiru. From: Oleg Moskalenko [mailto:mom040267@gmail.com] Sent: Tuesday, January 14, 2014 12:38 AM To: Alan Johnston Cc: Tirumaleswar Reddy (tireddy); tram@ietf.org; yoakum@avaya.com; justin@u= berti.name; kundan10@gmail.com Subject: Re: [tram] draft-johnston-tram-stun-origin-00 Hi Alan please see below: On Mon, Jan 13, 2014 at 8:23 AM, Alan Johnston > wrote: Comment 3> ORIGN attribute would be typically used before long-term authen= tication has started. In what scenarios content of ORIGIN attribute will be= integrity protected ? The ORIGIN attribute will be present both before and after authentication, = so after authentication it will be integrity protected by the MESSAGE-INTEG= RITY attribute, right? I can see the purpose of the ORIGIN in the original ALLOCATE request, BEFOR= E the authentication. The ORIGIN tells the server which realm to choose. So= , implicitly, the ORIGIN afterwards (after the initial authentication and A= LLOCATE dialog) is "implied" by the realm and by the session itself. So, wh= y the ORIGIN has to be included into the messages after the initial authent= ication ? It increases the traffic; but more importantly, it is either redu= ndant (if the ORIGIN value is the same as the "initial" ORIGIN) or maliciou= s (if the ORIGIN is different from the "initial" ORIGIN). I'd suggest to limit the meaningful ORIGIN usage to the initial authenticat= ion messages. In all other messages, the ORIGIN may (must) be ignored and = it can be used only for the logging purposes. That leaves the interesting case for re-authentication (when in the middle = of the TURN session the credentials are expiring and we are requesting re-a= uthentication. I suppose that a practical approach would be that the TURN s= erver must store the "initial" ORIGIN for the whole length of the session a= nd ignore any ORIGIN attributes during the subsequent negotiations. The val= ue of the ORIGIN attribute is not secure (just a hint that is open to every= body listening) and it makes sense only as the initial hint. Thanks Oleg --_000_913383AAA69FF945B8F946018B75898A2428A857xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with Oleg respons= e.

 <= /p>

-Tiru.<= /p>

From: Oleg Mos= kalenko [mailto:mom040267@gmail.com]
Sent: Tuesday, January 14, 2014 12:38 AM
To: Alan Johnston
Cc: Tirumaleswar Reddy (tireddy); tram@ietf.org; yoakum@avaya.com; j= ustin@uberti.name; kundan10@gmail.com
Subject: Re: [tram] draft-johnston-tram-stun-origin-00

 

Hi Alan

please see below:

 

On Mon, Jan 13, 2014 at 8:23 AM, Alan Johnston <<= a href=3D"mailto:alan.b.johnston@gmail.com" target=3D"_blank">alan.b.johnst= on@gmail.com> wrote:

 

 

Comment 3>  ORIGN attribute wou= ld be typically used before long-term authentication has started. In what scenarios content of ORIGIN attribute will be integrity protected = ?

 

The ORIGIN attribute will be present both before and= after authentication, so after authentication it will be integrity protect= ed by the MESSAGE-INTEGRITY attribute, right?

 

 

I can see the purpose= of the ORIGIN in the original ALLOCATE request, BEFORE the authentication.= The ORIGIN tells the server which realm to choose. So, implicitly, the ORI= GIN afterwards (after the initial authentication and ALLOCATE dialog) is "implied" by the realm and by the sessio= n itself. So, why the ORIGIN has to be included into the messages after the= initial authentication ? It increases the traffic; but more importantly, i= t is either redundant (if the ORIGIN value is the same as the "initial" ORIGIN) or malicious (if the ORIGIN= is different from the "initial" ORIGIN).

I'd suggest to limit the meaningful ORIGIN usage to = the initial authentication messages.  In all other messages, the ORIGI= N may (must) be ignored and it can be used only for the logging purposes.

 

That leaves the inter= esting case for re-authentication (when in the middle of the TURN session t= he credentials are expiring and we are requesting re-authentication. I supp= ose that a practical approach would be that the TURN server must store the "initial" ORIGIN for the = whole length of the session and ignore any ORIGIN attributes during the sub= sequent negotiations. The value of the ORIGIN attribute is not secure (just= a hint that is open to everybody listening) and it makes sense only as the initial hint.

Thanks
Oleg

 

--_000_913383AAA69FF945B8F946018B75898A2428A857xmbrcdx10ciscoc_-- From juberti@google.com Tue Jan 14 09:52:59 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 283851AE15E for ; Tue, 14 Jan 2014 09:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMrOkVyA2v2b for ; Tue, 14 Jan 2014 09:52:57 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id CE2B31ADF28 for ; Tue, 14 Jan 2014 09:52:57 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id at1so811249iec.14 for ; Tue, 14 Jan 2014 09:52:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=l/GPj8f0erB0gwgiLZZhcEidtBzzjt/8ftNhrV/2alk=; b=XQiq8HQTGVeCww6SCa8LRBq0ryxOFV/aIeq1IDDGn1MrmNfbsZKS6lZcV8Zw1jewJm PxTOw4LPupCbWDzkkSAtbPgvqNU4NmBHKdqb7z4FciNLZ9WbXSZRSOqbfP4sNN1mYi13 QhfZa1LA5Is+n/tnCPz6k5J7B5Z3ANAUjY95QXnEx0LxyODYRiZhRR3rfYLc+ZbKCk5R ueU6iBtPltYA35UFayPwRciITzvjJnoTTb0SbRkvcT8HlQOh1oCmFVrYY2kzRcB5vJBB mYElZSUO3wC4hYEdRXmIUU/GbqErsl7SS2srE1mkSzuR+/DkjV+19Xx1fBYipxCcDL11 kTYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=l/GPj8f0erB0gwgiLZZhcEidtBzzjt/8ftNhrV/2alk=; b=Tn/L+62gHhdbvDFPMPFFys7GADQV9/gTebZJ8ywWsfCjdf7XgTN6OpMTQOWHbKb8cr D/MMpTtducqMmvbqXu/fyeKtnksg9gHveYw6oRaWJUKuRo0VPfCbOMK/jLF8oKyDFMgc LZLq9HoApevNY0r5j4ron9yyEEoVw7hk6bvfjCGUTiVSjJY7xAUIgmiOqOcaHFuvS8f0 ykICPJsPVnRn2+5aZURZTu/UrDnjLtjg/hIdcJuK5EUxSohHooD2gx+/oRH6teITlfdC IUHF1PxSfCBwXbEvu1wrG38rL49H6yqWOEQ8P8KPY4CCoEk+fXr/NXhOgC8SXYacMYbW JPBg== X-Gm-Message-State: ALoCoQlg8L/QmyY76Syq+uWpcmUA7z5mXFSAFC7Tq2fRn1od4ue3dBLDi7jBS7Dz9b7CJ1L6Sh9AhMkp4xHqS4Ss3pE+lTjHIAwbhm0zMiGqXx0y8euLHMqXbRtm6cTZbleQCfTTAENvGZMCyp2B3dQBfhY1qwFXtSxZuWBPClMe5tmhH5mgQ88vD6/wfHdTkZREm6G3BQDO X-Received: by 10.42.38.138 with SMTP id c10mr7645323ice.66.1389721966429; Tue, 14 Jan 2014 09:52:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.35.67 with HTTP; Tue, 14 Jan 2014 09:52:26 -0800 (PST) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A24289ED3@xmb-rcd-x10.cisco.com> From: Justin Uberti Date: Tue, 14 Jan 2014 09:52:26 -0800 Message-ID: To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=20cf30334ee5256cd104eff1dcd6 Cc: "justin@uberti.name" , "tram@ietf.org" , "kundan10@gmail.com" , "Tirumaleswar Reddy \(tireddy\)" , "yoakum@avaya.com" , Alan Johnston Subject: Re: [tram] draft-johnston-tram-stun-origin-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 17:52:59 -0000 --20cf30334ee5256cd104eff1dcd6 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 13, 2014 at 5:09 PM, Oleg Moskalenko wrote: > > > > On Mon, Jan 13, 2014 at 5:00 PM, Justin Uberti wrote: > >> >> >> The ORIGIN attribute will be present both before and after >>> authentication, so after authentication it will be integrity protected by >>> the MESSAGE-INTEGRITY attribute, right? >>> >> >> True. One possible implication would be that the TURN server needs to >> wait for an authenticated message containing ORIGIN before making a >> decision, or perhaps, that ORIGIN should not be included in unauthenticated >> TURN messages. (This is all avoided when using DTLS though.) >> > > > Justin, that would not work that way. For authentication, we must know the > realm - and so we need the ORIGIN value before any authentication can be > done. That would be catch 22. > Yes, the server needs to decide which REALM to use based on the initial, unauthenticated ORIGIN - I was suggesting that implementations could wait for the authenticated ORIGIN if they needed to make other decisions where the authentication is important. I agree it's probably best for servers not to do this though (see below). > > To the contrary, I believe that ORIGIN must appear in unauthenticated > messages only, to signal to the server which realm to choose. In the > already authenticated messages, it has no sense, albeit for logging. > > The idea was to provide a hint to the TURN server which realm to choose. > And that hint is totally optional, in comprehension-optional range. The > TURN server may ignore it altogether, or it may use it for whatever realm > choosing algorithm it implements. > > That new ORIGIN attribute must not carry any "hard" meaning, and it must > not be scrutinized by the server. That is just a hint (but a valuable one). > Agree it's best if we treat ORIGIN as a hint, essentially an identifier of the web application in use, similar to how SOFTWARE might be used to identify a native application. --20cf30334ee5256cd104eff1dcd6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Jan 13, 2014 at 5:09 PM, Oleg Moskalenko = <mom040267@gmai= l.com> wrote:



On Mon, Jan 13, 2014 at 5:00 PM, Justin Uberti <<= a href=3D"mailto:juberti@google.com" target=3D"_blank">juberti@google.com> wrote:


The ORIGIN attribute will be present both before and after authentication,= so after authentication it will be integrity protected by the MESSAGE-INTE= GRITY attribute, right?

True. One possible= implication would be that the TURN server needs to wait for an authenticat= ed message containing ORIGIN before making a decision, or perhaps, that ORI= GIN should not be included in unauthenticated TURN messages. (This is all a= voided when using DTLS though.)


Justin, that w= ould not work that way. For authentication, we must know the realm - and so= we need the ORIGIN value before any authentication can be done. That would= be catch 22.

Yes, the server ne= eds to decide which REALM to use based on the initial, unauthenticated ORIG= IN - I was suggesting that implementations could wait for the authenticated= ORIGIN if they needed to make other decisions where the authentication is = important.

I agree it's probably best for servers not to do th= is though (see below).

To the contrary, I believe that ORIGIN must appear in unauth= enticated messages only, to signal to the server which realm to choose. In = the already authenticated messages, it has no sense, albeit for logging.
The idea was to provide a hint to the TURN server which realm to choose= . And that hint is totally optional, in comprehension-optional range. The T= URN server may ignore it altogether, or it may use it for whatever realm ch= oosing algorithm it implements.

That new ORIGIN attribute must not carry any "hard"= ; meaning, and it must not be scrutinized by the server. That is just a hin= t (but a valuable one).

Agree it's best if we treat ORIGIN as a hint, essentiall= y an identifier of the web application in use, similar to how SOFTWARE migh= t be used to identify a native application.
--20cf30334ee5256cd104eff1dcd6-- From simon.perreault@viagenie.ca Thu Jan 23 07:31:35 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3BA1A001F for ; Thu, 23 Jan 2014 07:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdrxdOvLJgbR for ; Thu, 23 Jan 2014 07:31:34 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id ECA1F1A000E for ; Thu, 23 Jan 2014 07:31:33 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0C184400A8 for ; Thu, 23 Jan 2014 10:31:33 -0500 (EST) Message-ID: <52E135D4.6050907@viagenie.ca> Date: Thu, 23 Jan 2014 10:31:32 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "tram@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tram] BoF approved X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 15:31:36 -0000 All, FYI, the TRAM BoF has been approved. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From spencerdawkins.ietf@gmail.com Wed Jan 29 09:14:57 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25AF1A02DD; Wed, 29 Jan 2014 09:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1Kl-7v-4yP6; Wed, 29 Jan 2014 09:14:56 -0800 (PST) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E9FD01A021B; Wed, 29 Jan 2014 09:14:55 -0800 (PST) Received: by mail-oa0-f47.google.com with SMTP id m1so2364113oag.34 for ; Wed, 29 Jan 2014 09:14:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=ThtahEdWVCObr5Ew7vORPog7LsSlbu742Be0Us9gSUc=; b=NxfioF0elT2BHm39+Hn4JNeCXOOOnlBgNnHHT3amtqSRYuaorpoUWIQfPdPBdEer2H QwJwmMaDOaQZeuwEbAp//bvqeJeNeypMBjUUCrdJmdu70h49l8PqPsMYNN/qyPs82vPE +h/UdGS3xVze9PaJPZSELCEyL5I28QjIiFzQmuF37g8g1+8el0o2K719DPcKlKX85VeY 582rS4hPBixMg8dMYCkYXH1JJwigqDQQLcdgiHlzqMtRT5b7RveMY3tqV8VKURtf7gif Tdz2oEUIGdUH4ywzPwMBfV41rSPjnmxgrVAr0UN3cXTWWXcED6VSU8OIqsv6UL8w86bG zxFw== X-Received: by 10.182.246.39 with SMTP id xt7mr7358995obc.16.1391015692885; Wed, 29 Jan 2014 09:14:52 -0800 (PST) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id fn10sm4979775obb.12.2014.01.29.09.14.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Jan 2014 09:14:51 -0800 (PST) Message-ID: <52E93708.1030108@gmail.com> Date: Wed, 29 Jan 2014 11:14:48 -0600 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: tram@ietf.org References: <52E135D4.6050907@viagenie.ca> In-Reply-To: <52E135D4.6050907@viagenie.ca> Content-Type: multipart/alternative; boundary="------------040706070705060005060602" Cc: tsv-ads@ietf.org Subject: Re: [tram] BoF approved X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 17:14:58 -0000 This is a multi-part message in MIME format. --------------040706070705060005060602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear TRAMsters, On 01/23/2014 09:31 AM, Simon Perreault wrote: > FYI, the TRAM BoF has been approved. And, actually, more than that ... the guidance I got on the BOF coordination call (IESG + IAB) was that we didn't need to do a formal BOF for relatively minor extensions of an IETF standards-track protocol, so "propose a charter without a BOF". You will doubtless see future references to "TRAM BoF", because the normal practice at this point is to approve a BOF *slot* at the meeting, so there's a room request, conflict list, and such things in place for the agenda conflict review (which happens tomorrow), so that whether we finish chartering before IETF 89 or not, TRAM will be meeting. So, I'm starting to get questions from other ADs who are looking at the draft charter. Let me check with you on feedback I've gotten thus far. In this text: > The goal of the TRAM Working Group is to consolidate the various > initiatives to update TURN and STUN, including the definition of new > transport, authentication mechanisms, and extensions, that make STUN > and TURN more suitable for the WebRTC environment. what kind of "new transport" are we talking about? I think I know, but could someone give me an example? Thanks! Spencer --------------040706070705060005060602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear TRAMsters,

On 01/23/2014 09:31 AM, Simon Perreault wrote:
FYI, the TRAM BoF has been approved.

And, actually, more than that ... the guidance I got on the BOF coordination call (IESG + IAB) was that we didn't need to do a formal BOF for relatively minor extensions of an IETF standards-track protocol, so "propose a charter without a BOF".

You will doubtless see future references to "TRAM BoF", because the normal practice at this point is to approve a BOF *slot* at the meeting, so there's a room request, conflict list, and such things in place for the agenda conflict review (which happens tomorrow), so that whether we finish chartering before IETF 89 or not, TRAM will be meeting.

So, I'm starting to get questions from other ADs who are looking at the draft charter. Let me check with you on feedback I've gotten thus far.

In this text:

The goal of the TRAM Working Group is to consolidate the various initiatives to update TURN and STUN, including the definition of new transport, authentication mechanisms, and extensions, that make STUN and TURN more suitable for the WebRTC environment.

what kind of "new transport" are we talking about? I think I know, but could someone give me an example?

Thanks!

Spencer
--------------040706070705060005060602-- From mom040267@gmail.com Wed Jan 29 09:57:06 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2D81A0421; Wed, 29 Jan 2014 09:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-JC87nHMKqd; Wed, 29 Jan 2014 09:57:05 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id DFBB71A0427; Wed, 29 Jan 2014 09:57:04 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id hz1so2052967pad.22 for ; Wed, 29 Jan 2014 09:57:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+7MiG4kij/YeBCgKUoRI0pisZrwIuh0d+4TUr/Z3zLM=; b=h1lXliXrXeLgTtOCtrmTt5UoD2aiSaVOEonZSpVOFIKdnSSPZIqjPnf4brVHUXwLsh dbtkRsbPIOR+HDYjxhoxQKFIFVTFkaPXEwfK6uTr5UzlDeAdIz4Q16a2W8LkMgCRXW5a 6Tu2MugMExMxYYU1IEU/fyviEfvOmOsDtHGXS2QDZyAG3X83i7VlkQzgBKO67FK+cIOr Dcds/JI+1Sr+oQlyKb5B+WUKKhAucmMeaW0NtmpshPbXmI8lSP0hoxnKp8gGrRzN7oP3 dFEbP3N9BqHOKiG5FyfibeE/EA1HXRy0LkbVSelRPJheuWXVS0jStNZPAaamEL/98/qB OOyg== MIME-Version: 1.0 X-Received: by 10.66.160.2 with SMTP id xg2mr9340495pab.23.1391018222039; Wed, 29 Jan 2014 09:57:02 -0800 (PST) Received: by 10.68.147.131 with HTTP; Wed, 29 Jan 2014 09:57:01 -0800 (PST) In-Reply-To: <52E93708.1030108@gmail.com> References: <52E135D4.6050907@viagenie.ca> <52E93708.1030108@gmail.com> Date: Wed, 29 Jan 2014 09:57:01 -0800 Message-ID: From: Oleg Moskalenko To: Spencer Dawkins Content-Type: multipart/alternative; boundary=047d7bacb47c003ac104f11fabed Cc: "tram@ietf.org" , tsv-ads@ietf.org Subject: Re: [tram] BoF approved X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 17:57:06 -0000 --047d7bacb47c003ac104f11fabed Content-Type: text/plain; charset=ISO-8859-1 I am pretty much sure that the "new transport" in this particular case means "DTLS". That's a natural extension for the TURN. Oleg On Wed, Jan 29, 2014 at 9:14 AM, Spencer Dawkins < spencerdawkins.ietf@gmail.com> wrote: > Dear TRAMsters, > > > On 01/23/2014 09:31 AM, Simon Perreault wrote: > > FYI, the TRAM BoF has been approved. > > > And, actually, more than that ... the guidance I got on the BOF > coordination call (IESG + IAB) was that we didn't need to do a formal BOF > for relatively minor extensions of an IETF standards-track protocol, so > "propose a charter without a BOF". > > You will doubtless see future references to "TRAM BoF", because the normal > practice at this point is to approve a BOF *slot* at the meeting, so > there's a room request, conflict list, and such things in place for the > agenda conflict review (which happens tomorrow), so that whether we finish > chartering before IETF 89 or not, TRAM will be meeting. > > So, I'm starting to get questions from other ADs who are looking at the > draft charter. Let me check with you on feedback I've gotten thus far. > > In this text: > > The goal of the TRAM Working Group is to consolidate the various > initiatives to update TURN and STUN, including the definition of new > transport, authentication mechanisms, and extensions, that make STUN and > TURN more suitable for the WebRTC environment. > > > what kind of "new transport" are we talking about? I think I know, but > could someone give me an example? > > Thanks! > > Spencer > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --047d7bacb47c003ac104f11fabed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am pretty much sure that the "new transport&qu= ot; in this particular case means "DTLS". That's a natural ex= tension for the TURN.

Oleg


On Wed, Jan 29, 2014 at 9:14 AM, Spencer= Dawkins <spencerdawkins.ietf@gmail.com> wrote:<= br>
=20 =20 =20
Dear TRAMsters,


On 01/23/2014 09:31 AM, Simon Perreault wrote:
FYI, the TRAM BoF has been approved.

And, actually, more than that ... the guidance I got on the BOF coordination call (IESG + IAB) was that we didn't need to do a formal BOF for relatively minor extensions of an IETF standards-track protocol, so "propose a charter without a BOF"= ;.

You will doubtless see future references to "TRAM BoF", becau= se the normal practice at this point is to approve a BOF *slot* at the meeting, so there's a room request, conflict list, and such things in place for the agenda conflict review (which happens tomorrow), so that whether we finish chartering before IETF 89 or not, TRAM will be meeting.

So, I'm starting to get questions from other ADs who are looking at the draft charter. Let me check with you on feedback I've gotten thus far.

In this text:

=20 The goal of the TRAM Working Group is to consolidate the various initiatives to update TURN and STUN, including the definition of new transport, authentication mechanisms, and extensions, that make STUN and TURN more suitable for the WebRTC environment.

what kind of "new transport" are we talking about? I think I = know, but could someone give me an example?

Thanks!

Spencer

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--047d7bacb47c003ac104f11fabed-- From simon.perreault@viagenie.ca Wed Jan 29 10:36:01 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A81B1A0349 for ; Wed, 29 Jan 2014 10:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYdNHGYf9P_7 for ; Wed, 29 Jan 2014 10:35:57 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id DB84F1A02F2 for ; Wed, 29 Jan 2014 10:35:56 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id CEB7B40031 for ; Wed, 29 Jan 2014 13:35:53 -0500 (EST) Message-ID: <52E94A09.6060307@viagenie.ca> Date: Wed, 29 Jan 2014 13:35:53 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: tram@ietf.org References: <52E135D4.6050907@viagenie.ca> <52E93708.1030108@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [tram] BoF approved X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 18:36:01 -0000 Le 2014-01-29 12:57, Oleg Moskalenko a écrit : > I am pretty much sure that the "new transport" in this particular case > means "DTLS". That's a natural extension for the TURN. Correct. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From spencerdawkins.ietf@gmail.com Wed Jan 29 11:05:25 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B3B1A0355 for ; Wed, 29 Jan 2014 11:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrGCORdZqcon for ; Wed, 29 Jan 2014 11:05:24 -0800 (PST) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 62E041A02B6 for ; Wed, 29 Jan 2014 11:05:24 -0800 (PST) Received: by mail-ob0-f180.google.com with SMTP id wp4so2377859obc.25 for ; Wed, 29 Jan 2014 11:05:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=j6RKcJ9Tns0zsZXt40U19Vwz1HcdJLAmPtAR73hJlpg=; b=0g95enLHGNmVic+RZ8EvmtZ4uc5qPIO5W1zCS5k8zNYeONR6lYcCkMO6cQlKI4gu9v CM+461lFUYPmUQWElUOhbGvMXFfJLPYibjOdPPeevasOONsrZb7B2FcDFPF6/BgGMffi wM04X8pyg8LKlHZ/78EkPbnJr7NE1/Pet38Y6+YqZ+aKZjvdxSeroLujjfM9sDzgOMEv PZuYzXkWfGLEOzsBsvgtEblncq2RZ4HQDiB/QujnBTB7N53GMbZjeZhhsl3jBA5IoNSY f7h0wWM70/q8bbjl5bLfXZLsBQxQLOHuXafBR4QVzHWjDc1NLdR5Je2pFO1vt88s6DHb 9iaA== X-Received: by 10.60.59.162 with SMTP id a2mr7566066oer.17.1391022321280; Wed, 29 Jan 2014 11:05:21 -0800 (PST) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id nw5sm5510603obc.9.2014.01.29.11.05.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Jan 2014 11:05:20 -0800 (PST) Message-ID: <52E950EE.7050901@gmail.com> Date: Wed, 29 Jan 2014 13:05:18 -0600 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Simon Perreault , tram@ietf.org References: <52E135D4.6050907@viagenie.ca> <52E93708.1030108@gmail.com> <52E94A09.6060307@viagenie.ca> In-Reply-To: <52E94A09.6060307@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [tram] BoF approved X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 19:05:26 -0000 On 01/29/2014 12:35 PM, Simon Perreault wrote: > Le 2014-01-29 12:57, Oleg Moskalenko a écrit : >> I am pretty much sure that the "new transport" in this particular case >> means "DTLS". That's a natural extension for the TURN. > > Correct. > > Simon Thank you both for the quick response. I LOVE it when I guess right :-) Spencer From mom040267@gmail.com Fri Jan 31 00:44:06 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E657C1A0578 for ; Fri, 31 Jan 2014 00:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTTtYjfN2Qxq for ; Fri, 31 Jan 2014 00:44:05 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB2C1A0575 for ; Fri, 31 Jan 2014 00:44:05 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id kx10so4186760pab.35 for ; Fri, 31 Jan 2014 00:44:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T3KjYDRJJSxIo3Su51Ao0DQZdcvLvtt0yo2QBP536iU=; b=iG4ufW3BSLu8ZmydPoqOVzpC2hfZYEM+9qRC92roh0jeFxyefFFWrpvFUvc2d05I39 OOk694Aaeac9Awg7X7iWqAmVdYKvAzwMnc0Gkz6wL9NTNqxbFaJvZDS/bLsgzvNZFbbD z76mT5Su5eYBv+y2OBVhlAW0yEEndjNGE0XJbhPVvHaA+ZshTRi9L3lIdqvu4yRDQGWv rqyqaCvCIGirdxgiInjbdTwIGToCEMrnQtZlD0lYjVPw/k2j9RFqrpM7l28tR+YwL++x z+656Vo27mERBpVZ0uSNssEOaZHqNXbsFb0L6fpzr0Q7YNJW4gBvBl4iLBtN4dUIqXGO QObg== MIME-Version: 1.0 X-Received: by 10.68.89.162 with SMTP id bp2mr19263833pbb.151.1391157842242; Fri, 31 Jan 2014 00:44:02 -0800 (PST) Received: by 10.68.147.131 with HTTP; Fri, 31 Jan 2014 00:44:02 -0800 (PST) In-Reply-To: <52D3F03A.6060201@viagenie.ca> References: <52D3F03A.6060201@viagenie.ca> Date: Fri, 31 Jan 2014 00:44:02 -0800 Message-ID: From: Oleg Moskalenko To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7b675e3e03712004f1402d46 Cc: "tram@ietf.org" Subject: Re: [tram] BoF request posted X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 08:44:07 -0000 --047d7b675e3e03712004f1402d46 Content-Type: text/plain; charset=ISO-8859-1 Any chance of WebEx access to the meeting ? Oleg On Mon, Jan 13, 2014 at 5:55 AM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > All, > > After discussing with our benevolent ADs we came to the conclusion that it > would be better process-wise to hold a BoF in London, rather than try to > form WG directly. > > Consequently, here's the formal BoF request: > > http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#TRAM > > Comments, suggestions, questions? > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --047d7b675e3e03712004f1402d46 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Any chance of WebEx access to the meeting ?

Oleg


On Mon, Jan 13, 2014 at 5:55 AM, Simon Perreault <= ;simon.per= reault@viagenie.ca> wrote:
All,

After discussing with our benevolent ADs we came to the conclusion that it = would be better process-wise to hold a BoF in London, rather than try to fo= rm WG directly.

Consequently, here's the formal BoF request:

http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#TRAM<= /a>

Comments, suggestions, questions?

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca
_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--047d7b675e3e03712004f1402d46-- From lorenzo@meetecho.com Fri Jan 31 01:26:30 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0314C1A03F4 for ; Fri, 31 Jan 2014 01:26:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXA056o6J27n for ; Fri, 31 Jan 2014 01:26:28 -0800 (PST) Received: from smtpdg94.aruba.it (smtpdg96.aruba.it [62.149.158.96]) by ietfa.amsl.com (Postfix) with ESMTP id 964421A0388 for ; Fri, 31 Jan 2014 01:26:27 -0800 (PST) Received: from lminiero ([143.225.229.166]) by smtpcmd05.ad.aruba.it with bizsmtp id LZSL1n01G3c3Lvj01ZSMtN; Fri, 31 Jan 2014 10:26:22 +0100 Date: Fri, 31 Jan 2014 10:26:21 +0100 From: Lorenzo Miniero To: Oleg Moskalenko Message-ID: <20140131102621.67656d6c@lminiero> In-Reply-To: References: <52D3F03A.6060201@viagenie.ca> Organization: Meetecho X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] BoF request posted X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 09:26:30 -0000 Il giorno Fri, 31 Jan 2014 00:44:02 -0800 Oleg Moskalenko ha scritto: > Any chance of WebEx access to the meeting ? > > Oleg > Oleg, should our schedule allow it, and should the BoF chairs be interested, we can stream the session via Meetecho for remote attendees. Lorenzo > > On Mon, Jan 13, 2014 at 5:55 AM, Simon Perreault < > simon.perreault@viagenie.ca> wrote: > > > All, > > > > After discussing with our benevolent ADs we came to the conclusion > > that it would be better process-wise to hold a BoF in London, > > rather than try to form WG directly. > > > > Consequently, here's the formal BoF request: > > > > http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#TRAM > > > > Comments, suggestions, questions? > > > > Simon > > -- > > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > > STUN/TURN server --> http://numb.viagenie.ca > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > > From simon.perreault@viagenie.ca Fri Jan 31 06:05:30 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E9A1A01ED for ; Fri, 31 Jan 2014 06:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQJqjWZch4Ud for ; Fri, 31 Jan 2014 06:05:29 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9A01A0193 for ; Fri, 31 Jan 2014 06:05:29 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:8e70:5aff:fec5:72e4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 92BB14037D; Fri, 31 Jan 2014 09:05:25 -0500 (EST) Message-ID: <52EBADA5.3080004@viagenie.ca> Date: Fri, 31 Jan 2014 09:05:25 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Lorenzo Miniero , Oleg Moskalenko References: <52D3F03A.6060201@viagenie.ca> <20140131102621.67656d6c@lminiero> In-Reply-To: <20140131102621.67656d6c@lminiero> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "tram@ietf.org" Subject: Re: [tram] BoF request posted X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 14:05:30 -0000 Le 2014-01-31 04:26, Lorenzo Miniero a écrit : > should our schedule allow it, and should the BoF chairs be interested, > we can stream the session via Meetecho for remote attendees. Yes please! :) You guys do an awesome job. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From gsalguei@cisco.com Fri Jan 31 07:32:34 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04BFD1A02DA for ; Fri, 31 Jan 2014 07:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnWodBi5HxiI for ; Fri, 31 Jan 2014 07:32:32 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE381A020C for ; Fri, 31 Jan 2014 07:32:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2109; q=dns/txt; s=iport; t=1391182349; x=1392391949; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=gAFG2i4uWTVE3AauMpg4mswvcA7zGdiUHYY5GkSWC1A=; b=LPmdkfr5mOzkchwtUN9L3LM1WTySAp2c9WkN8jH1N2dX6YJecwo2LIXF OTx1X6twu7zlVY3KjJSiW0OBFSHe+JGk0yAY6YA5xkP3Y5rafhXbY7L/5 YCY8dbvh6QUN2ZU60nxzircl60Fu3J/Y40yVcEVayhts9dPLd2RVpYkUF s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAAHB61KtJV2Y/2dsb2JhbABZgww4V704gQoWdIIlAQEBAwEBAQE3NBsCAQg2ECcLJQIEEwmHdAgNzF4Xjk81BYMkgRQEmCqBMosvhUCDLYIq X-IronPort-AV: E=Sophos;i="4.95,758,1384300800"; d="scan'208";a="301046791" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 31 Jan 2014 15:32:27 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0VFWQ8J019786 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 31 Jan 2014 15:32:26 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.37]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Fri, 31 Jan 2014 09:32:26 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: "tram@ietf.org" Thread-Topic: I-D Action: draft-petithuguenin-tram-turn-dtls-00.txt Thread-Index: AQHPHpVFStx7a///J0KQP9Rnsl5L6JqfWrKA Date: Fri, 31 Jan 2014 15:32:25 +0000 Message-ID: <3610CA6C-3EAB-4418-AA3C-53BB0F80ABD6@cisco.com> References: <20140131150054.2907.33844.idtracker@ietfa.amsl.com> In-Reply-To: <20140131150054.2907.33844.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.132.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <822CC723D512B24A905599053BE0832F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tram] I-D Action: draft-petithuguenin-tram-turn-dtls-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 15:32:34 -0000 Folks -=20 As mentioned during the authoring of the charter, we have published a draft= to satisfy the milestone for "DTLS transport for TURN". Feedback/comments much appreciated. If time permits we will try and publis= h an -01 prior to the draft deadline. Thanks, Gonzalo On Jan 31, 2014, at 10:00 AM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : Datagram Transport Layer Security (DTLS) as Tran= sport for Traversal Using Relays around NAT (TURN) > Authors : Marc Petit-Huguenin > Gonzalo Salgueiro > Filename : draft-petithuguenin-tram-turn-dtls-00.txt > Pages : 9 > Date : 2014-01-31 >=20 > Abstract: > This document specifies the usage of Datagram Transport Layer > Security (DTLS) [RFC6347] as a transport protocol between a Traversal > Using Relays around NAT (TURN) [RFC5766] client and a TURN server. > It also specifies modifications to the TURN URIs [RFC7065] and to the > TURN resolution mechanism [RFC5928] to facilitate the resolution of > TURN URIs into the IP address and port of TURN servers supporting > DTLS as a transport protocol. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-petithuguenin-tram-turn-dtls/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-petithuguenin-tram-turn-dtls-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From mom040267@gmail.com Fri Jan 31 09:31:04 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF731A042F for ; Fri, 31 Jan 2014 09:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yhs71JjS7SoG for ; Fri, 31 Jan 2014 09:31:02 -0800 (PST) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id BBDC61A0367 for ; Fri, 31 Jan 2014 09:31:02 -0800 (PST) Received: by mail-pb0-f53.google.com with SMTP id md12so4637716pbc.12 for ; Fri, 31 Jan 2014 09:30:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uAKPIha10NMnO7tsJOaYcgCe9/B+nKFj9V6w8MstHuQ=; b=waqx8nRr9eipnZppt46FXU3A8n1FgLiuOJgc8itdKMpMsQYhjnccivb38aKrQgFQzU rhfoYdptA8DBWLwlVY/Je1zFSVFYskdv30L8dt9q8tOMi5gw6E4AIMowfRrEb6pfrwF2 ryiMb3/MPuKqrHPOTlZKIMwVkBoVOJ3FJZGIF6bBPFEKqZmZxI5DodHGsVlvGMIYXR21 oBYXqaeuwVGNX38naZ9jn5ayTdKeJrjLSiEEr0jgC1uJf27bCXJdxqB8rmeF/VHutGQK Uj81YbwQ+9fNrhnmTZxehXxo0sv58RkJ9hTOEx5N1woeEarKvd62cPMv70NYySTDh2VG 0Rew== MIME-Version: 1.0 X-Received: by 10.68.171.4 with SMTP id aq4mr641642pbc.150.1391189459206; Fri, 31 Jan 2014 09:30:59 -0800 (PST) Received: by 10.68.147.131 with HTTP; Fri, 31 Jan 2014 09:30:59 -0800 (PST) In-Reply-To: <3610CA6C-3EAB-4418-AA3C-53BB0F80ABD6@cisco.com> References: <20140131150054.2907.33844.idtracker@ietfa.amsl.com> <3610CA6C-3EAB-4418-AA3C-53BB0F80ABD6@cisco.com> Date: Fri, 31 Jan 2014 09:30:59 -0800 Message-ID: From: Oleg Moskalenko To: "Gonzalo Salgueiro (gsalguei)" Content-Type: multipart/alternative; boundary=047d7bacbb488808b004f14789a1 Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-petithuguenin-tram-turn-dtls-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 17:31:05 -0000 --047d7bacbb488808b004f14789a1 Content-Type: text/plain; charset=ISO-8859-1 I have a comment: section 6 "Implementation status": On the TURN server side, there is a number of open-source TURN servers that have been playing with DTLS protocol implementation idea, for years (and I know at least one private implementation). Our TURN server fully supports DTLS at the same level as TLS: http://code.google.com/p/rfc5766-turn-server/ Regards, Oleg On Fri, Jan 31, 2014 at 7:32 AM, Gonzalo Salgueiro (gsalguei) < gsalguei@cisco.com> wrote: > Folks - > > As mentioned during the authoring of the charter, we have published a > draft to satisfy the milestone for "DTLS transport for TURN". > > Feedback/comments much appreciated. If time permits we will try and > publish an -01 prior to the draft deadline. > > Thanks, > > Gonzalo > > > > > On Jan 31, 2014, at 10:00 AM, internet-drafts@ietf.org wrote: > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Datagram Transport Layer Security (DTLS) as > Transport for Traversal Using Relays around NAT (TURN) > > Authors : Marc Petit-Huguenin > > Gonzalo Salgueiro > > Filename : draft-petithuguenin-tram-turn-dtls-00.txt > > Pages : 9 > > Date : 2014-01-31 > > > > Abstract: > > This document specifies the usage of Datagram Transport Layer > > Security (DTLS) [RFC6347] as a transport protocol between a Traversal > > Using Relays around NAT (TURN) [RFC5766] client and a TURN server. > > It also specifies modifications to the TURN URIs [RFC7065] and to the > > TURN resolution mechanism [RFC5928] to facilitate the resolution of > > TURN URIs into the IP address and port of TURN servers supporting > > DTLS as a transport protocol. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-petithuguenin-tram-turn-dtls/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-petithuguenin-tram-turn-dtls-00 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --047d7bacbb488808b004f14789a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have a comment:

section 6 "I= mplementation status": On the TURN server side, there is a number of o= pen-source TURN servers that have been playing with DTLS protocol implement= ation idea, for years (and I know at least one private implementation). Our= TURN server fully supports DTLS at the same level as TLS:

http://code.g= oogle.com/p/rfc5766-turn-server/

Regards,
Oleg

<= /div>


On Fri, = Jan 31, 2014 at 7:32 AM, Gonzalo Salgueiro (gsalguei) <= ;gsalguei@cisco.com= > wrote:
Folks -

As mentioned during the authoring of the charter, we have published a draft= to satisfy the milestone for "DTLS transport for TURN".

Feedback/comments much appreciated. =A0If time permits we will try and publ= ish an -01 prior to the draft deadline.

Thanks,

Gonzalo




On Jan 31, 2014, at 10:00 AM, i= nternet-drafts@ietf.org wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>
>
> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Datagram Transport Layer Se= curity (DTLS) as Transport for Traversal Using Relays around NAT (TURN)
> =A0 =A0 =A0 =A0Authors =A0 =A0 =A0 =A0 : Marc Petit-Huguenin
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Gonzalo Salgueiro > =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-petithuguenin-tram-turn-dt= ls-00.txt
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 9
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-01-31
>
> Abstract:
> =A0 This document specifies the usage of Datagram Transport Layer
> =A0 Security (DTLS) [RFC6347] as a transport protocol between a Traver= sal
> =A0 Using Relays around NAT (TURN) [RFC5766] client and a TURN server.=
> =A0 It also specifies modifications to the TURN URIs [RFC7065] and to = the
> =A0 TURN resolution mechanism [RFC5928] to facilitate the resolution o= f
> =A0 TURN URIs into the IP address and port of TURN servers supporting<= br> > =A0 DTLS as a transport protocol.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-petithu= guenin-tram-turn-dtls/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-petithuguenin-tra= m-turn-dtls-00
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--047d7bacbb488808b004f14789a1-- From petithug@acm.org Fri Jan 31 09:45:25 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBD81A1F7C for ; Fri, 31 Jan 2014 09:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Usife5VGMUTW for ; Fri, 31 Jan 2014 09:45:23 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8481A1F7B for ; Fri, 31 Jan 2014 09:45:19 -0800 (PST) Received: from [IPv6:2001:5c0:1101:2d00:906:b90a:bd5f:a1a2] (unknown [IPv6:2001:5c0:1101:2d00:906:b90a:bd5f:a1a2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id F385320F11; Fri, 31 Jan 2014 18:45:14 +0100 (CET) Message-ID: <52EBE128.6080909@acm.org> Date: Fri, 31 Jan 2014 10:45:12 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: Oleg Moskalenko , "Gonzalo Salgueiro (gsalguei)" References: <20140131150054.2907.33844.idtracker@ietfa.amsl.com> <3610CA6C-3EAB-4418-AA3C-53BB0F80ABD6@cisco.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-petithuguenin-tram-turn-dtls-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 17:45:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/31/2014 10:30 AM, Oleg Moskalenko wrote: > I have a comment: > > section 6 "Implementation status": On the TURN server side, there is a > number of open-source TURN servers that have been playing with DTLS > protocol implementation idea, for years (and I know at least one private > implementation). Our TURN server fully supports DTLS at the same level as > TLS: > > http://code.google.com/p/rfc5766-turn-server/ > Please send me the RFC6982 template filled, and I'll add it to the next revision. Thanks. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJS6+EkAAoJECnERZXWan7Eq9oQANiFb7cERiXUYrEgmqnNNAXi sMmmiLNngIkYvai2TY4ccVIU0b3STHMJ5DE5hYpUDA9TA+VKPppnlaZG+yyzlyaE c6/+gJn+qxR8daoR99oRmeY4Nox/LXwGVj6Ih/agQtsK1Cro6w14B6eeS28zcfw1 79EfFzQ7j0nsMh6EJi8LLXrZvOXA2AqKvClj5483Br/ZoiqSOpc677WNbHJHLEle WnjID6jdzVgtKWzzi35jkXUwmVYWjg4KK9eOLUKkH0Sp35ZWw/H9mLZrsoO5lmhs bam5fWO4UPoLlUZtdaP2tv+5+ossDNyogL22K4PbAwHPMqLOhDcx2UoMiNrGsZ26 8sYSk1OtEYeESWU9k7ypxMa5ImctTezGQDASUuUTeL5V+dhtbqmFimOz8F65u928 6HixHoYbcu11tzppcVzb9g5r9ME+v0XOUIR+eNZqzIjQjxkwGeTYQRiZYFIGarWv LEfTUTnKFbs9Nv4u9SjYDFhV5BBvRKd8WCfF49AvmZmmTm80ckIfbYb0j96Bd5an JeN7lm4QdV8niIByLdtn1T9IhZ1Ytj8KAphGgDu/I0EmyNfxVn5d/GA9U/HhAwq+ HXCjzRcbd5Tg5Jycm147R00AN/FPCeWMnZLWeuRhz7qpChrDgK+7SrtZYITJRjaw YKtSfWYtOLIN/hOgflXN =+as2 -----END PGP SIGNATURE----- From mom040267@gmail.com Fri Jan 31 10:35:13 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC931AC441 for ; Fri, 31 Jan 2014 10:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhR8yIE3bdx4 for ; Fri, 31 Jan 2014 10:35:08 -0800 (PST) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id CFDF21A046F for ; Fri, 31 Jan 2014 10:35:08 -0800 (PST) Received: by mail-pd0-f172.google.com with SMTP id p10so4596365pdj.3 for ; Fri, 31 Jan 2014 10:35:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cS8ugub0Lz2QJ4+38DVRYp/lMMO7oqPdcZuxpa2cI/w=; b=qqtjbAbi7/LYDqiI5/TaGS1Z29v3EgaMYwpfe4z4NDGrVfr7XXaLxe19Co648PzTxv c6F08Q7dMOgKJOBj5ct3zCD25dlfZRs2FET2DOJsihtGpt5MTqRlMc/P6np1B/v0aaRI Hy2bm/lXjmrnGFr0/FEVN13R+NtZJnk0//KZYGsrF5knc3GBTFQbwFFZlJTKZOZAbvjW 5VBWca3ox+s/HlzuoZ3KpIm+OfAjMZzr2HqMZhwVS7GSvPsU9nLDR2e9elYS6xa0WPeJ KV6N0mDC32r3ReItkuwYODfwgUM8A53rzMmZMepCAgvoOinbrBm8d/o4IdsHOtrjnXeE Xj5w== MIME-Version: 1.0 X-Received: by 10.67.14.231 with SMTP id fj7mr21843952pad.115.1391193297521; Fri, 31 Jan 2014 10:34:57 -0800 (PST) Received: by 10.68.147.131 with HTTP; Fri, 31 Jan 2014 10:34:57 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A24267B37@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A24264EF5@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A24265484@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A24267B37@xmb-rcd-x10.cisco.com> Date: Fri, 31 Jan 2014 10:34:57 -0800 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=001a113453ec50161204f1486e06 Cc: Simon Perreault , "tram@ietf.org" , Justin Uberti Subject: Re: [tram] First post X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 18:35:13 -0000 --001a113453ec50161204f1486e06 Content-Type: text/plain; charset=ISO-8859-1 Hi Tiru in regard to Mobile ICE, I filled the RFC 6982 template - you can add it as "implementation status" section to the draft, please see below. Thanks Oleg ============================== o The organization responsible for the implementation, if any. This is a public project, the full list of authors and contributors here: http://turnserver.open-sys.org/downloads/AUTHORS o The implementation's name and/or a link to a web page describing the implementation. http://code.google.com/p/rfc5766-turn-server/ o A brief general description. A mature open-source TURN server specs implementation (RFC 5766, RFC 6062, RFC 6156, etc) designed for high-performance applications, especially geared for WebRTC. o The implementation's level of maturity: research, prototype, alpha, beta, production, widely used, etc. widely used (the TURN server itself). The Mobile ICE feature implementation can be qualified as "production" - it is well tested and fully implemented, but not widely used, yet. o Coverage: which parts of the protocol specification are implemented and which versions of the Internet-Draft were implemented. Fully implements MICE with TURN protocol o Licensing: the terms under which the implementation can be used. For example: proprietary, royalty licensing, freely distributable with acknowledgement (BSD style), freely distributable with requirement to redistribute source (General Public License (GPL) style), and other (specify). BSD: http://turnserver.open-sys.org/downloads/LICENSE o Implementation experience: any useful information the implementers want to share with the community. MICE implementation is somewhat challenging for a multi-threaded performance-oriented application (because the mobile ticket information must be shared between the threads) but it is doable. ======================================================================== On Tue, Nov 19, 2013 at 4:26 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Hi Oleg, > > Please see inline [TR] > > From: tram-bounces@ietf.org [mailto:tram-bounces@ietf.org] On Behalf Of > Oleg Moskalenko > Sent: Monday, November 18, 2013 12:19 PM > To: Tirumaleswar Reddy (tireddy) > Cc: Simon Perreault; pcp@ietf.org; tram@ietf.org; Justin Uberti > Subject: Re: [tram] First post > > Dan and Tiru, > while contemplating the MICE implementation, I stumbled upon a potential > problem in the MICE draft. > According to the section 5.2.2, the server compares the encoded NONCE with > the stored NONCE for the "old" 5-tuple session. But the problem is, a NONCE > may expire. Its possible to have an expiration time for the NONCE (an > enhanced security feature). In a non-mobility TURN implementation, that > creates no problem: the server simple sends 438 error (stale nonce) back to > the client together with the new generated NONCE value, and the client just > re-calculates and re-sends the request. > With wording in the section 5.2.2, that becomes rather complicated in the > mobility case. I am not sure that I understand the exact action sequence > when the session NONCE expires with mobility feature. > I think that the problem can be fixed if the draft would not include > wording about the MOBILE-TICKET internal structure. In one place it is > saying that the ticket is opaque and implementation-dependent; but in other > places it suggests how the ticket must be constructed and how it must be > encoded. I think that this is unnecessary. Let's just say that the ticket > is opaque and its structure has meaning only for the server - and that the > server uses it as a unique identifier. > I see no reason why the server must encode any meaningful information in > the ticket, like 5-tuple and NONCE. That's totally up to the server. The > server, for example, may just keep a hashtable with all that information > and the ticket may be just a random unique key in that table. As we are > using message integrity authentication anyway, and the ticket is > transferred openly over the Internet, the ticket does not create any new > level of defense. This is, basically, just a session ID - to match the > "old" session with the "new" session. > > [TR] Agreed with your assessment will update the draft accordingly. > > Thanks and Regards, > -Tiru. > > A similar approach is used in RFC 6062. They are solving a similar logical > task: they are matching a new client network endpoint with an existing TURN > session. They also are using a ticket, but they do not encode any > information in it - that is just an opaque unique string. For protection, > they also are validating the MESSAGE INTEGRITY. And they have no problem > with the NONCE expiration because there is no NONCE encoded in the ticket. > > Let me know please what do you think about that. > > Thanks > Oleg > > > > > > > On Sun, Nov 17, 2013 at 5:36 AM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > Hi Oleg, > > It has some similarities but is a lot different from PCP third party > authorization. For example for TURN the Authorization Server will be > providing session key, MAC algorithm etc which is not required with the PCP > third party authorization. There are various other differences like PCP > server would need to communicate with the Authorization Server to determine > the token bound authorization data (like the number of mappings permitted, > flow characteristics allowed etc) which may not be required with TURN > authorization. PCP-controlled Firewall will most likely be in the same > administrative domain as the endpoint but that may not be true with TURN. > > we are working on the details and will have something concrete in couple > of weeks. > > Cheers, > -Tiru. > From: tram-bounces@ietf.org [mailto:tram-bounces@ietf.org] On Behalf Of > Oleg Moskalenko > Sent: Saturday, November 16, 2013 12:56 PM > To: Tirumaleswar Reddy (tireddy) > Cc: Simon Perreault; tram@ietf.org; Justin Uberti > > Subject: Re: [tram] First post > > Tiru, I suppose that will be similar to this draft: > > http://tools.ietf.org/html/draft-wing-pcp-third-party-authz-01 > That would be a significant addition to the TURN server. > Regards, > Oleg > > > On Fri, Nov 15, 2013 at 7:20 PM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > Hi Oleg, > > I am co-author of the MICE, draft-reddy-behave-turn-auth drafts and we are > interested in TURN evolution. Justin and we are working on TURN Extension > for Third Party Authorization using OAuth which will address some of the > problems discussed in above draft. > > Cheers, > -Tiru. > > From: Oleg Moskalenko > Subject: Re: [tram] First post > Date: November 15, 2013 11:01:24 AM PST > To: Simon Perreault > Cc: > > MMUSIC has an interesting draft on TURN mobility (MICE) that I am watching > and I am going to implement. I wonder whether the authors of the draft may > be interested in the TURN evolution. > > On Fri, Nov 15, 2013 at 10:55 AM, Simon Perreault < > simon.perreault@viagenie.ca> wrote: > All, > > Any objection against sending the following to rtcweb, pntaw, and behave? > Any other lists that should be included? > > Simon > > ==================== > > All, > > A few of us have been working on a proposal for a new working group that > would focus on enhancements to STUN and TURN. The proposed name is TRAM > (Turn Revised And Modernized) and discussion is happening in < > tram@ietf.org>. > Subscribe link: > > Here is the charter we have been working on. If you would like to comment > and/or get involved, please do so on the TRAM mailing list. > > Simon (and many others!) > Turn Revised And Modernized (tram) > ---------------------------------- > > Traversal Using Relays around NAT (TURN) was published as RFC 5766 in April > 2010. Until recently the protocol had only a rather limited deployment. > This > is primarily because its primary use case is as one of the NAT traversal > methods of the Interactive Connectivity Establishment (ICE) framework (RFC > 5245). This inherent dependency on ICE combined with the fact that ICE > itself > was slow to achieve widespread adoption because other alternative > mechanisms > were historically used by the VoIP industry were the causes of the initial > lack of interest. This situation has changed drastically as ICE, and > consequently TURN, are mandatory to implement in WebRTC, which is a set of > technologies developed at the IETF and W3C aiming to enable Real Time > Communication on the Web. > > Because of the ubiquity of the Web and of the new opportunities created by > the > arrival of WebRTC, there is a renewed interest in TURN and ICE, as > evidenced by > the recent work updating the ICE framework, as well as standardizing the > URIs > used to access a STUN [RFC7064] or TURN [RFC7065] server. > > The goal of the TRAM Working Group is to consolidate the various > initiatives > to update TURN and STUN, including the definition of new transport and > authentication mechanisms that make STUN and TURN more suitable for the > WebRTC > environment. The Working Group will closely coordinate with the > appropriate > Working Groups, including RTCWEB, MMUSIC, and HTTPBIS. > > The current list of deliverable is: > > - DTLS transport for TURN > > Candidate draft: draft-petithuguenin-tram-turn-dtls > > TURN defines three transports: UDP, TCP, and TLS. A straightforward > extension > of this set is DTLS, enabling secure datagram-oriented transport. > > - New authentication mechanism for TURN > > Problem analysis: draft-reddy-behave-turn-auth > Candidate draft: draft-uberti-behave-turn-rest, OAuth has also been > suggested > > The current authentication mechanism for TURN, which is reused from > STUN, has > been designed with a SIP account database in mind. The new RTCWEB usages, > which are mostly based on web applications, do not fit that model. A new > authentication mechanism optimized for such web applications will be > created. > > - TURN server auto-discovery mechanism for enterprise and ISPs > > Candidate draft: TBD > > Current TURN server discovery is based on the presence of SRV and/or > NAPTR DNS > records. These records are usually under the administrative control of > the > application or service provider, not the enterprise or the ISP on whose > network the client is situated. Enterprises or ISPs wishing to provide > their > own TURN server, in an attempt to reduce so-called "triangle routing", > need a > new auto-discovery mechanism. > > - STUN-bis > > Candidate draft: TBD > > A new revision of RFC 5389 will contain: > > - Various bug fixes > - STUN hash algorithm agility (currently only SHA-1 is allowed) > > - TURN-bis > > Candidate draft: TBD > > A new revision of RFC 5766 will contain: > > - Various bug fixes > - Support for multi-tenant servers > (Servers always send the same REALM attribute. No realm negotiation > phase > currently exists.) > > Goals and Milestones: > > [TBD] > > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > --001a113453ec50161204f1486e06 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Tiru

in regard to Mobile ICE, I fille= d the RFC 6982 template - you can add it as "implementation status&quo= t; section to the draft, please see below.

Thanks
Oleg=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
   o  The organization responsible for t=
he implementation, if any.


This is a public project, the full list of authors and contr=
ibutors here: 
http://turnserver.open-sys.org/downloads/AUTHORS<=
br>


  =A0o  The implementation's name and/or a link to a web page =
describing
      the implementation.

http://code.google.com/p/rfc57=
66-turn-server/

  =A0o  A brief general description.


A mature open-source TURN server specs implementation (RFC 5=
766, RFC 6062, RFC 6156, etc) 
designed for high-performance application=
s, especially geared for WebRTC.

  =A0o  The implementati=
on's level of maturity: research, prototype,
      alpha, beta, production, widely used, etc.

widely u=
sed (the TURN server itself).
The Mobile ICE feature implementatio= n can be qualified as "production" - it is well tested and fully = implemented, but not widely used, yet.

  =A0o  Coverage: which parts of the protocol specification are
      implemented and which versions of the Internet-Draft were
      implemented.

Fully implements MICE with TURN protocol


   o  Licensing: the terms under which the implementation can be used.
      For example: proprietary, royalty licensing, freely distributable
      with acknowledgement (BSD style), freely distributable with
      requirement to redistribute source (General Public License (GPL)
      style), and other (specify).

BSD:

http://turnserver=
.open-sys.org/downloads/LICENSE

=A0o  Implementation experience:=
 any useful information the implementers
      want to share with the community.

MICE implementation is somewhat challenging for a multi-thre=
aded 
performance-oriented application (because the mobile ticket inform=
ation 
must be shared between the threads) but it is doable.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D



On Tue, Nov 19, 2013 at 4:26 AM, Tirumaleswar Reddy (tireddy)= <tireddy@cisco.com> wrote:
Hi Oleg,

Please see inline [TR]

From: tram-bounces@ietf.org [m= ailto:tram-bounces@ietf.org] O= n Behalf Of Oleg Moskalenko
Sent: Monday, November 18, 2013 12:19 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Simon Perreault; pcp@ietf.org; tram@ietf.org; Justin Uberti
Subject: Re: [tram] First post

Dan and Tiru,
while contemplating the MICE implementation, I stumbled upon a potential pr= oblem in the MICE draft.
According to the section 5.2.2, the server compares the encoded NONCE with = the stored NONCE for the "old" 5-tuple session. But the problem i= s, a NONCE may expire. Its possible to have an expiration time for the NONC= E (an enhanced security feature). In a non-mobility TURN implementation, th= at creates no problem: the server simple sends 438 error (stale nonce) back= to the client together with the new generated NONCE value, and the client = just re-calculates and re-sends the request.
With wording in the section 5.2.2, that becomes rather complicated in the m= obility case. I am not sure that I understand the exact action sequence whe= n the session NONCE expires with mobility feature.
I think that the problem can be fixed if the draft would not include wordin= g about the MOBILE-TICKET internal structure. In one place it is saying tha= t the ticket is opaque and implementation-dependent; but in other places it= suggests how the ticket must be constructed and how it must be encoded. I = think that this is unnecessary. Let's just say that the ticket is opaqu= e and its structure has meaning only for the server - and that the server u= ses it as a unique identifier.
I see no reason why the server must encode any meaningful information in th= e ticket, like 5-tuple and NONCE. That's totally up to the server. The = server, for example, may just keep a hashtable with all that information an= d the ticket may be just a random unique key in that table. As we are using= message integrity authentication anyway, and the ticket is transferred ope= nly over the Internet, the ticket does not create any new level of defense.= This is, basically, just a session ID - to match the "old" sessi= on with the "new" session.

[TR] Agreed with your assessment will update the draft accordingly.
Thanks and Regards,
-Tiru.

A similar approach is used in RFC 6062. They are solving a similar logical = task: they are matching a new client network endpoint with an existing TURN= session. They also are using a ticket, but they do not encode any informat= ion in it - that is just an opaque unique string. For protection, they also= are validating the MESSAGE INTEGRITY. And they have no problem with the NO= NCE expiration because there is no NONCE encoded in the ticket.

Let me know please what do you think about that.

Thanks
Oleg
=A0





On Sun, Nov 17, 2013 at 5:36 AM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:
Hi Oleg,
=A0
It has some similarities but is a lot different from PCP third party author= ization. For example for TURN the Authorization Server will be providing se= ssion key, MAC algorithm etc which is not required with the PCP third party= authorization.=A0 There are various other differences like PCP server woul= d need to communicate with the Authorization Server to determine the token = bound authorization data =A0(like the number of mappings permitted, flow ch= aracteristics allowed etc) which may not be required with TURN authorizatio= n.=A0 PCP-controlled Firewall will most likely be in the same administrativ= e domain as the endpoint but that may not be true with TURN.
=A0
we are working on the details and will have something concrete in cou= ple of weeks.
=A0
Cheers,
-Tiru.
From: tram-bounces@ietf.org [m= ailto:tram-bounces@ietf.org] O= n Behalf Of Oleg Moskalenko
Sent: Saturday, November 16, 2013 12:56 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Simon Perreault; tram@ietf.org; Ju= stin Uberti

Subject: Re: [tram] First post
=A0
Tiru, I suppose that will be similar to this draft:

http://tools.ietf.org/html/draft-wing-pcp-third-party-aut= hz-01
That would be a significant addition to the TURN server.
Regards,
Oleg
=A0
=A0
On Fri, Nov 15, 2013 at 7:20 PM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:
Hi Oleg,

I am co-author of the MICE, draft-reddy-behave-turn-auth drafts and we are = interested in TURN evolution. Justin and we are working on TURN Extension f= or Third Party Authorization using OAuth which will address some of the pro= blems discussed in above draft.

Cheers,
-Tiru.

From: Oleg Moskalenko <mom040267@= gmail.com>
Subject: Re: [tram] First post
Date: November 15, 2013 11:01:24 AM PST
To: Simon Perreault <simo= n.perreault@viagenie.ca>
Cc: <tram@ietf.org>

MMUSIC has an interesting draft on TURN mobility (MICE) that I am watching = and I am going to implement. I wonder whether the authors of the draft may = be interested in the TURN evolution.

On Fri, Nov 15, 2013 at 10:55 AM, Simon Perreault <simon.perreault@viagenie.ca> wrote:
All,

Any objection against sending the following to rtcweb, pntaw, and behave? A= ny other lists that should be included?

Simon

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

All,

A few of us have been working on a proposal for a new working group that wo= uld focus on enhancements to STUN and TURN. The proposed name is TRAM (Turn= Revised And Modernized) and discussion is happening in <tram@ietf.org>.
Subscribe link: <https://www.ietf.org/mailman/listinfo/tram>

Here is the charter we have been working on. If you would like to comment a= nd/or get involved, please do so on the TRAM mailing list.

Simon (and many others!)
Turn Revised And Modernized (tram)
----------------------------------

Traversal Using Relays around NAT (TURN) was published as RFC 5766 in April=
2010. =A0Until recently the protocol had only a rather limited deployment. = =A0This
is primarily because its primary use case is as one of the NAT traversal methods of the Interactive Connectivity Establishment (ICE) framework (RFC<= br> 5245). =A0This inherent dependency on ICE combined with the fact that ICE i= tself
was slow to achieve widespread adoption because other alternative mechanism= s
were historically used by the VoIP industry were the causes of the initial<= br> lack of interest. =A0This situation has changed drastically as ICE, and
consequently TURN, are mandatory to implement in WebRTC, which is a set of<= br> technologies developed at the IETF and W3C aiming to enable Real Time
Communication on the Web.

Because of the ubiquity of the Web and of the new opportunities created by = the
arrival of WebRTC, there is a renewed interest in TURN and ICE, as evidence= d by
the recent work updating the ICE framework, as well as standardizing the UR= Is
used to access a STUN [RFC7064] or TURN [RFC7065] server.

The goal of the TRAM Working Group is to consolidate the various initiative= s
to update TURN and STUN, including the definition of new transport and
authentication mechanisms that make STUN and TURN more suitable for the Web= RTC
environment. =A0The Working Group will closely coordinate with the appropri= ate
Working Groups, including RTCWEB, MMUSIC, and HTTPBIS.

The current list of deliverable is:

- DTLS transport for TURN

=A0 Candidate draft: draft-petithuguenin-tram-turn-dtls

=A0 TURN defines three transports: UDP, TCP, and TLS. A straightforward ext= ension
=A0 of this set is DTLS, enabling secure datagram-oriented transport.

- New authentication mechanism for TURN

=A0 Problem analysis: draft-reddy-behave-turn-auth
=A0 Candidate draft: draft-uberti-behave-turn-rest, OAuth has also been sug= gested

=A0 The current authentication mechanism for TURN, which is reused from STU= N, has
=A0 been designed with a SIP account database in mind. The new RTCWEB usage= s,
=A0 which are mostly based on web applications, do not fit that model. A ne= w
=A0 authentication mechanism optimized for such web applications will be cr= eated.

- TURN server auto-discovery mechanism for enterprise and ISPs

=A0 Candidate draft: TBD

=A0 Current TURN server discovery is based on the presence of SRV and/or NA= PTR DNS
=A0 records. These records are usually under the administrative control of = the
=A0 application or service provider, not the enterprise or the ISP on whose=
=A0 network the client is situated. Enterprises or ISPs wishing to provide = their
=A0 own TURN server, in an attempt to reduce so-called "triangle routi= ng", need a
=A0 new auto-discovery mechanism.

- STUN-bis

=A0 Candidate draft: TBD

=A0 A new revision of RFC 5389 will contain:

=A0 - Various bug fixes
=A0 - STUN hash algorithm agility (currently only SHA-1 is allowed)

- TURN-bis

=A0 Candidate draft: TBD

=A0 A new revision of RFC 5766 will contain:

=A0 - Various bug fixes
=A0 - Support for multi-tenant servers
=A0 =A0 (Servers always send the same REALM attribute. No realm negotiation= phase
=A0 =A0 =A0currently exists.)

Goals and Milestones:

[TBD]

--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca
_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram
=A0


--001a113453ec50161204f1486e06-- From mom040267@gmail.com Fri Jan 31 12:38:59 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285181A03CC for ; Fri, 31 Jan 2014 12:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LS4tMVje-Knb for ; Fri, 31 Jan 2014 12:38:57 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E26451A03F5 for ; Fri, 31 Jan 2014 12:38:56 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id rd3so4817783pab.5 for ; Fri, 31 Jan 2014 12:38:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VKp1ySdMoVmW7i+rjl5zuKzo5MbxnsXMEws/CZHR+a4=; b=dh8MMNm0Bcj/c/XFOq4lshITVjqyuothRVPeY0q9HV41LKJYqBpMclvowJV3cy64Zd uFep6k38latwRzTvveoyU2mkdSuZ6LFqrRdy6bHdC8rwF1vfsKmsEAtBNavpMFfaFWHn +iTLgy1VFTcPpGmQhT3gleCchmRFz/CI2v5ENV2Vn/6eD8SZTLh8Xpp1+/AXwaLxemkm kbwpsPK8wbJfO3x3WZiml6M+9uBAXtiuYFzJcV2GHzpXJKvL1d/5qnQ0GcNKyoJqZbnb m3ywNQ4Ad9gUM4sAaxOk47ysmw+ZfHPilQQhdotvQKr9lQvzJLZyIArb5ahlHW+TH6qa YL7Q== MIME-Version: 1.0 X-Received: by 10.68.170.66 with SMTP id ak2mr22797541pbc.5.1391200733272; Fri, 31 Jan 2014 12:38:53 -0800 (PST) Received: by 10.68.147.131 with HTTP; Fri, 31 Jan 2014 12:38:53 -0800 (PST) In-Reply-To: <3610CA6C-3EAB-4418-AA3C-53BB0F80ABD6@cisco.com> References: <20140131150054.2907.33844.idtracker@ietfa.amsl.com> <3610CA6C-3EAB-4418-AA3C-53BB0F80ABD6@cisco.com> Date: Fri, 31 Jan 2014 12:38:53 -0800 Message-ID: From: Oleg Moskalenko To: "Gonzalo Salgueiro (gsalguei)" Content-Type: multipart/alternative; boundary=047d7b86d55c84a00d04f14a29fe Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-petithuguenin-tram-turn-dtls-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 20:38:59 -0000 --047d7b86d55c84a00d04f14a29fe Content-Type: text/plain; charset=ISO-8859-1 As we are using TURN mostly for WebRTC these days, may be it is worth mentioning how the TURN DTLS relates to DTLS-SRTP used as TURN payload in WebRTC. In the WebRTC TURN use case, we have DTLS-inside-DTLS tunneled, in a sense; and probably it makes sense to mention that those are two independent DTLS sessions: one is a DTLS session between the client and the TURN server, and the second session is a client-to-client session tunneled inside the first session, with "use_srtp" DTLS extension. The TURN DTLS does not need and does not support "use_srtp" extension. I do not think that there must be a recommendation on avoiding double-DTLS. My opinion is that avoiding double-DTLS has low priority and may not be achieved easily; it may have some importance only from the MTU point of view (two DTLS overheads with a video RTP traffic may present a problem when near-MTU payload is used). On Fri, Jan 31, 2014 at 7:32 AM, Gonzalo Salgueiro (gsalguei) < gsalguei@cisco.com> wrote: > Folks - > > As mentioned during the authoring of the charter, we have published a > draft to satisfy the milestone for "DTLS transport for TURN". > > Feedback/comments much appreciated. If time permits we will try and > publish an -01 prior to the draft deadline. > > Thanks, > > Gonzalo > > > > > On Jan 31, 2014, at 10:00 AM, internet-drafts@ietf.org wrote: > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Datagram Transport Layer Security (DTLS) as > Transport for Traversal Using Relays around NAT (TURN) > > Authors : Marc Petit-Huguenin > > Gonzalo Salgueiro > > Filename : draft-petithuguenin-tram-turn-dtls-00.txt > > Pages : 9 > > Date : 2014-01-31 > > > > Abstract: > > This document specifies the usage of Datagram Transport Layer > > Security (DTLS) [RFC6347] as a transport protocol between a Traversal > > Using Relays around NAT (TURN) [RFC5766] client and a TURN server. > > It also specifies modifications to the TURN URIs [RFC7065] and to the > > TURN resolution mechanism [RFC5928] to facilitate the resolution of > > TURN URIs into the IP address and port of TURN servers supporting > > DTLS as a transport protocol. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-petithuguenin-tram-turn-dtls/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-petithuguenin-tram-turn-dtls-00 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --047d7b86d55c84a00d04f14a29fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As we are using TURN mostly for WebRTC these days, ma= y be it is worth mentioning how the TURN DTLS relates to DTLS-SRTP used as = TURN payload in WebRTC. In the WebRTC TURN use case, we have DTLS-inside-DT= LS tunneled, in a sense; and probably it makes sense to mention that those = are two independent DTLS sessions: one is a DTLS session between the client= and the TURN server, and the second session is a client-to-client session = tunneled inside the first session, with "use_srtp" DTLS extension= . The TURN DTLS does not need and does not support "use_srtp" ext= ension.

I do not think that there must be a recommendatio= n on avoiding double-DTLS. My opinion is that avoiding double-DTLS has low = priority and may not be achieved easily; it may have some importance only f= rom the MTU point of view (two DTLS overheads with a video RTP traffic may = present a problem when near-MTU payload is used).




On Fri, Jan 31, 2014 at 7:32 AM, Gonzalo Salgueiro (gsalg= uei) <gsalguei@cisco.com> wrote:
Folks -

As mentioned during the authoring of the charter, we have published a draft= to satisfy the milestone for "DTLS transport for TURN".

Feedback/comments much appreciated. =A0If time permits we will try and publ= ish an -01 prior to the draft deadline.

Thanks,

Gonzalo




On Jan 31, 2014, at 10:00 AM, i= nternet-drafts@ietf.org wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>
>
> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Datagram Transport Layer Se= curity (DTLS) as Transport for Traversal Using Relays around NAT (TURN)
> =A0 =A0 =A0 =A0Authors =A0 =A0 =A0 =A0 : Marc Petit-Huguenin
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Gonzalo Salgueiro > =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-petithuguenin-tram-turn-dt= ls-00.txt
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 9
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-01-31
>
> Abstract:
> =A0 This document specifies the usage of Datagram Transport Layer
> =A0 Security (DTLS) [RFC6347] as a transport protocol between a Traver= sal
> =A0 Using Relays around NAT (TURN) [RFC5766] client and a TURN server.=
> =A0 It also specifies modifications to the TURN URIs [RFC7065] and to = the
> =A0 TURN resolution mechanism [RFC5928] to facilitate the resolution o= f
> =A0 TURN URIs into the IP address and port of TURN servers supporting<= br> > =A0 DTLS as a transport protocol.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-petithu= guenin-tram-turn-dtls/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-petithuguenin-tra= m-turn-dtls-00
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--047d7b86d55c84a00d04f14a29fe-- From alan.b.johnston@gmail.com Fri Jan 31 14:22:20 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023C51A0574 for ; Fri, 31 Jan 2014 14:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdApUW8SBrFN for ; Fri, 31 Jan 2014 14:22:16 -0800 (PST) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D16CC1A04E8 for ; Fri, 31 Jan 2014 14:22:16 -0800 (PST) Received: by mail-pb0-f47.google.com with SMTP id rp16so4934508pbb.34 for ; Fri, 31 Jan 2014 14:22:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LTMlx6rGTYqKBkEYehNlzH1lkmTd4ANDYhUtrdhsCoo=; b=S6RaaVs2Zxx71Iykh6pMfrcxzQuiPfSW1Jj/6BmM9BUGoQxKuH/zeCSESKIZvaEaK2 XMuNHQDFtsgjBKFe+0eP6xyhQ0ACr40V7zY5IpzjO7bkYX7fJJYPg8PdPPsm8sv22jwS EliLBcG23jnlhvdUmu5Zbtm6uG887cdbyVH9kxPGPfWnu5gzWWyn5jyZ7umWkeJuZx6t rkJZM87HPxYRtsPViMR2vDvVzVkNKw68I2XzQ5a+/w1FBH4osV+C9zEdG4W25UYa2SWp qVbKX/2cL2G9ITZm0/JbVlxNHo65O/aSbaAEMpKfhucbH8fgMQ/L7xQE/6GNDWPYCiIS yUBg== MIME-Version: 1.0 X-Received: by 10.66.156.137 with SMTP id we9mr23521917pab.30.1391206933249; Fri, 31 Jan 2014 14:22:13 -0800 (PST) Received: by 10.68.168.132 with HTTP; Fri, 31 Jan 2014 14:22:13 -0800 (PST) In-Reply-To: <3610CA6C-3EAB-4418-AA3C-53BB0F80ABD6@cisco.com> References: <20140131150054.2907.33844.idtracker@ietfa.amsl.com> <3610CA6C-3EAB-4418-AA3C-53BB0F80ABD6@cisco.com> Date: Fri, 31 Jan 2014 16:22:13 -0600 Message-ID: From: Alan Johnston To: "Gonzalo Salgueiro (gsalguei)" Content-Type: multipart/alternative; boundary=047d7b5d8cc710c15e04f14b9b93 Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-petithuguenin-tram-turn-dtls-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 22:22:20 -0000 --047d7b5d8cc710c15e04f14b9b93 Content-Type: text/plain; charset=ISO-8859-1 Marc & Gonzalo, This draft looks good - no major issues. Here's a few comments for things to consider. Section 1 explains why we don't want to use TURN over TLS. Might be good to say why we want to use TURN over DTLS. Such as: confidentiality between TURN client and server which can protect against the limitations of the long term auth method, and privacy for TURN attributes. Also, this draft talks exclusively about TURN over DTLS. What about STUN over DTLS? I was thinking about DTLS for STUN for gathering reflexive candidates for setting up a data channel-only Peer Connection. Having DTLS between the STUN client and server could provide confidentiality for STUN attributes. Does this make sense? if not, are we sure there are no other STUN use cases? In the last paragraph of Section 3 mentions the application name of "udp". I think this correct as it refers to the SRV RR syntax, but I wanted to be sure this was correct and not a typo. Section 7 could use some text describing the security benefits of TURN over DTLS to help motivate why we all want this extension. - Alan - On Fri, Jan 31, 2014 at 9:32 AM, Gonzalo Salgueiro (gsalguei) < gsalguei@cisco.com> wrote: > Folks - > > As mentioned during the authoring of the charter, we have published a > draft to satisfy the milestone for "DTLS transport for TURN". > > Feedback/comments much appreciated. If time permits we will try and > publish an -01 prior to the draft deadline. > > Thanks, > > Gonzalo > > > > > On Jan 31, 2014, at 10:00 AM, internet-drafts@ietf.org wrote: > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Datagram Transport Layer Security (DTLS) as > Transport for Traversal Using Relays around NAT (TURN) > > Authors : Marc Petit-Huguenin > > Gonzalo Salgueiro > > Filename : draft-petithuguenin-tram-turn-dtls-00.txt > > Pages : 9 > > Date : 2014-01-31 > > > > Abstract: > > This document specifies the usage of Datagram Transport Layer > > Security (DTLS) [RFC6347] as a transport protocol between a Traversal > > Using Relays around NAT (TURN) [RFC5766] client and a TURN server. > > It also specifies modifications to the TURN URIs [RFC7065] and to the > > TURN resolution mechanism [RFC5928] to facilitate the resolution of > > TURN URIs into the IP address and port of TURN servers supporting > > DTLS as a transport protocol. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-petithuguenin-tram-turn-dtls/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-petithuguenin-tram-turn-dtls-00 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --047d7b5d8cc710c15e04f14b9b93 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Marc & Gonzalo,

This draft looks go= od - no major issues. =A0Here's a few comments for things to consider.<= /div>

Section 1 explains why we don't want to u= se TURN over TLS. =A0Might be good to say why we want to use TURN over DTLS= . =A0Such as: confidentiality between TURN client and server which can prot= ect against the limitations of the long term auth method, and privacy for T= URN attributes.

Also, this draft talks exclusively about TURN over DTLS= . =A0What about STUN over DTLS? =A0I was thinking about DTLS for STUN for g= athering reflexive candidates for setting up a data channel-only Peer Conne= ction. =A0Having DTLS between the STUN client and server could =A0provide c= onfidentiality for STUN attributes. =A0Does this make sense? =A0if not, are= we sure there are no other STUN use cases?

In the last paragraph of Section 3 mentions the applica= tion name of "udp". =A0I think this correct as it refers to the S= RV RR syntax, but I wanted to be sure this was correct and not a typo.

Section 7 could use some text describing the security b= enefits of TURN over DTLS to help motivate why we all want this extension.<= /div>

- Alan -


On Fri, Jan 31, 2014 at 9:32 AM, Gonzalo= Salgueiro (gsalguei) <gsalguei@cisco.com> wrote:
Folks -

As mentioned during the authoring of the charter, we have published a draft= to satisfy the milestone for "DTLS transport for TURN".

Feedback/comments much appreciated. =A0If time permits we will try and publ= ish an -01 prior to the draft deadline.

Thanks,

Gonzalo




On Jan 31, 2014, at 10:00 AM, i= nternet-drafts@ietf.org wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>
>
> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Datagram Transport Layer Se= curity (DTLS) as Transport for Traversal Using Relays around NAT (TURN)
> =A0 =A0 =A0 =A0Authors =A0 =A0 =A0 =A0 : Marc Petit-Huguenin
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Gonzalo Salgueiro > =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-petithuguenin-tram-turn-dt= ls-00.txt
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 9
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-01-31
>
> Abstract:
> =A0 This document specifies the usage of Datagram Transport Layer
> =A0 Security (DTLS) [RFC6347] as a transport protocol between a Traver= sal
> =A0 Using Relays around NAT (TURN) [RFC5766] client and a TURN server.=
> =A0 It also specifies modifications to the TURN URIs [RFC7065] and to = the
> =A0 TURN resolution mechanism [RFC5928] to facilitate the resolution o= f
> =A0 TURN URIs into the IP address and port of TURN servers supporting<= br> > =A0 DTLS as a transport protocol.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-petithu= guenin-tram-turn-dtls/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-petithuguenin-tra= m-turn-dtls-00
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--047d7b5d8cc710c15e04f14b9b93-- From mom040267@gmail.com Fri Jan 31 14:48:08 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103461A04EF for ; Fri, 31 Jan 2014 14:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kwDVL-SPuNC for ; Fri, 31 Jan 2014 14:48:06 -0800 (PST) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4539B1A04E8 for ; Fri, 31 Jan 2014 14:48:06 -0800 (PST) Received: by mail-pd0-f171.google.com with SMTP id g10so4797543pdj.30 for ; Fri, 31 Jan 2014 14:48:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TzlffoWnI9hVp6egeEDowgv5ADBT673s6kAVU00qH0o=; b=I9Ta+7dEQsMpd4dgW3Bo9bMvr68RuScaA70aC8Y0WRyHrRuqaNyLIcRICSiFXpDQHr 3iVKDxc5NjhNGYJ5ZAAaHoloohofQ8Hn9qya6qfAp4lkAwZqonPb+H2+l4ir+c26fQJs rzKSceXKhRx7Aa+fY79U7P9JyVHsDfjhnBLzYCoHxYrm6W9vR2Jh/XIGBaR09saFb2A+ AVq4MgKjd04iuUqUI2jwl+xOTstlsEKzA8BNqYcLKurDxj8IAHosM+vxhss3zZRbskLX Wenl1jXM82wLkz6Sqphc+dTVIGCbD50zm2W2CijOlsdGxUpGnlRNVpuiVhTUyICsSNbK pZcA== MIME-Version: 1.0 X-Received: by 10.68.237.133 with SMTP id vc5mr23422323pbc.92.1391208482634; Fri, 31 Jan 2014 14:48:02 -0800 (PST) Received: by 10.68.147.131 with HTTP; Fri, 31 Jan 2014 14:48:02 -0800 (PST) In-Reply-To: References: <20140131150054.2907.33844.idtracker@ietfa.amsl.com> <3610CA6C-3EAB-4418-AA3C-53BB0F80ABD6@cisco.com> Date: Fri, 31 Jan 2014 14:48:02 -0800 Message-ID: From: Oleg Moskalenko To: Alan Johnston Content-Type: multipart/alternative; boundary=047d7b338f1d6a833f04f14bf76b Cc: "Gonzalo Salgueiro \(gsalguei\)" , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-petithuguenin-tram-turn-dtls-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 22:48:08 -0000 --047d7b338f1d6a833f04f14bf76b Content-Type: text/plain; charset=ISO-8859-1 Hi Alan I'll add my opinion... please see below in the text: On Fri, Jan 31, 2014 at 2:22 PM, Alan Johnston wrote: > Marc & Gonzalo, > > This draft looks good - no major issues. Here's a few comments for things > to consider. > > Section 1 explains why we don't want to use TURN over TLS. Might be good > to say why we want to use TURN over DTLS. > It is saying that: TLS-over-UDP (referred to as DTLS [RFC6347 ]) offers the same security advantages as TLS-over-TCP, but without the undesirable latency concerns. and I suppose that this is accurate enough explanation. This is exactly what we want, for media traffic - TLS without TCP. Such as: confidentiality between TURN client and server which can protect > against the limitations of the long term auth method, and privacy for TURN > attributes. > well, all that plus confidentiality of the payload. > > Also, this draft talks exclusively about TURN over DTLS. What about STUN > over DTLS? I was thinking about DTLS for STUN for gathering reflexive > candidates for setting up a data channel-only Peer Connection. Having DTLS > between the STUN client and server could provide confidentiality for STUN > attributes. Does this make sense? if not, are we sure there are no other > STUN use cases? > I am not sure that STUN over DTLS makes sense. While we do support it in our project, I do not see what information to be protected in STUN requests. It can be mentioned, done and implemented, but I fail to see the point. There is no secure non-public information in the STUN Binding request and response. > > In the last paragraph of Section 3 mentions the application name of "udp". > I think this correct as it refers to the SRV RR syntax, but I wanted to be > sure this was correct and not a typo. > > Section 7 could use some text describing the security benefits of TURN > over DTLS to help motivate why we all want this extension. > I suppose that the desire to have encrypted UDP for media traffic is all that matters and it provides all (or almost all) motivation for TURN-over-DTLS. Regards, Oleg > > > --047d7b338f1d6a833f04f14bf76b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Alan

I'll add my opinion... pleas= e see below in the text:


On Fri, Jan 31, 2014 at 2:22 PM, Alan Johnston <alan.b.johnston@gmail.com> wrote:
Marc &am= p; Gonzalo,

This draft looks good - no major issues. =A0= Here's a few comments for things to consider.

Section 1 explains why we don't want to use TU= RN over TLS. =A0Might be good to say why we want to use TURN over DTLS. =A0=

It is saying that:
TLS-over-UDP (referred to as DTLS [RFC6347]) offers the same security advantages as TLS-over-TCP, but without the undesirable latency concerns.
=A0and I suppose that this is accurate enough = explanation. This is exactly what we want, for media traffic - TLS without = TCP.

Such as: confidentiality between TURN client and= server which can protect against the limitations of the long term auth met= hod, and privacy for TURN attributes.

well, all that plus confidentiality of the payload.
=A0

Also, this draft talks exclusively about TURN over DTLS= . =A0What about STUN over DTLS? =A0I was thinking about DTLS for STUN for g= athering reflexive candidates for setting up a data channel-only Peer Conne= ction. =A0Having DTLS between the STUN client and server could =A0provide c= onfidentiality for STUN attributes. =A0Does this make sense? =A0if not, are= we sure there are no other STUN use cases?

I am not sure that STUN over D= TLS makes sense. While we do support it in our project, I do not see what i= nformation to be protected in STUN requests. It can be mentioned, done and = implemented, but I fail to see the point. There is no secure non-public inf= ormation in the STUN Binding request and response.
=A0

In the last paragraph of Section 3 mentions the applica= tion name of "udp". =A0I think this correct as it refers to the S= RV RR syntax, but I wanted to be sure this was correct and not a typo.

Section 7 could use some text describing the security b= enefits of TURN over DTLS to help motivate why we all want this extension.<= /div>

I suppose that the desire= to have encrypted UDP for media traffic is all that matters and it provide= s all (or almost all) motivation for TURN-over-DTLS.

Regards,
Oleg
=A0



--047d7b338f1d6a833f04f14bf76b-- From tireddy@cisco.com Fri Jan 31 19:20:46 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D841A0508 for ; Fri, 31 Jan 2014 19:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sC-SHWPAXOmk for ; Fri, 31 Jan 2014 19:20:41 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4511A04D6 for ; Fri, 31 Jan 2014 19:20:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34052; q=dns/txt; s=iport; t=1391224837; x=1392434437; h=from:to:cc:subject:date:message-id:mime-version; bh=3gCsyztccBmY58Y++uqGSNx+PhergwgR6/XRdkCNaj8=; b=SwhNP9Egs8CpqLtLOPWrlWkG0wcWaSmK1budvX4f8qR6wSJ00tua0qT/ WYAz5bUB0yzJKOPwEeJ4tmCWRGPI43ON8bP3lZla9wKJ02YtwpVSmr4oz Erwv7ybSwFGaLeHcRMUMjou803QqIyUm0F8QPiuSLwGQ+RnbYLcWg6+Ni s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgHAGZn7FKtJXG//2dsb2JhbABZgkhEOFeqQ4pAiFaBChZ0giUBAQEEAQEBFw0GQQsSAQgOAwMBAQELAgkLBygGCxQJCQEECgQFCAyHXQMRDcQFDYkxF4xsgT4TFCANBAYHAwGDGoEUBJY+gx6LLIVDgy2BaAIeBhw X-IronPort-AV: E=Sophos;i="4.95,760,1384300800"; d="scan'208,217";a="17132170" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-1.cisco.com with ESMTP; 01 Feb 2014 03:20:35 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s113KZWu014546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 1 Feb 2014 03:20:35 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Fri, 31 Jan 2014 21:20:35 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko Thread-Topic: [tram] First post Thread-Index: Ac8e/I22FvNhqIOzRkeRAwPVMGrm7g== Date: Sat, 1 Feb 2014 03:20:34 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A24297693@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.43.151] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A24297693xmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: Simon Perreault , "tram@ietf.org" , Justin Uberti Subject: Re: [tram] First post X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 03:20:46 -0000 --_000_913383AAA69FF945B8F946018B75898A24297693xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Oleg, I will add the details in next revision. Thanks, -Tiru. From: Oleg Moskalenko [mailto:mom040267@gmail.com] Sent: Saturday, February 01, 2014 12:05 AM To: Tirumaleswar Reddy (tireddy) Cc: Simon Perreault; tram@ietf.org; Justin Uberti Subject: Re: [tram] First post Hi Tiru in regard to Mobile ICE, I filled the RFC 6982 template - you can add it as= "implementation status" section to the draft, please see below. Thanks Oleg =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D o The organization responsible for the implementation, if any. This is a public project, the full list of authors and contributors here: http://turnserver.open-sys.org/downloads/AUTHORS o The implementation's name and/or a link to a web page describing the implementation. http://code.google.com/p/rfc5766-turn-server/ o A brief general description. A mature open-source TURN server specs implementation (RFC 5766, RFC 6062, = RFC 6156, etc) designed for high-performance applications, especially geared for WebRTC. o The implementation's level of maturity: research, prototype, alpha, beta, production, widely used, etc. widely used (the TURN server itself). The Mobile ICE feature implementation can be qualified as "production" - it= is well tested and fully implemented, but not widely used, yet. o Coverage: which parts of the protocol specification are implemented and which versions of the Internet-Draft were implemented. Fully implements MICE with TURN protocol o Licensing: the terms under which the implementation can be used. For example: proprietary, royalty licensing, freely distributable with acknowledgement (BSD style), freely distributable with requirement to redistribute source (General Public License (GPL) style), and other (specify). BSD: http://turnserver.open-sys.org/downloads/LICENSE o Implementation experience: any useful information the implementers want to share with the community. MICE implementation is somewhat challenging for a multi-threaded performance-oriented application (because the mobile ticket information must be shared between the threads) but it is doable. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Tue, Nov 19, 2013 at 4:26 AM, Tirumaleswar Reddy (tireddy) > wrote: Hi Oleg, Please see inline [TR] From: tram-bounces@ietf.org [mailto:tram-boun= ces@ietf.org] On Behalf Of Oleg Moskalenko Sent: Monday, November 18, 2013 12:19 PM To: Tirumaleswar Reddy (tireddy) Cc: Simon Perreault; pcp@ietf.org; tram@ietf.org; Justin Uberti Subject: Re: [tram] First post Dan and Tiru, while contemplating the MICE implementation, I stumbled upon a potential pr= oblem in the MICE draft. According to the section 5.2.2, the server compares the encoded NONCE with = the stored NONCE for the "old" 5-tuple session. But the problem is, a NONCE= may expire. Its possible to have an expiration time for the NONCE (an enha= nced security feature). In a non-mobility TURN implementation, that creates= no problem: the server simple sends 438 error (stale nonce) back to the cl= ient together with the new generated NONCE value, and the client just re-ca= lculates and re-sends the request. With wording in the section 5.2.2, that becomes rather complicated in the m= obility case. I am not sure that I understand the exact action sequence whe= n the session NONCE expires with mobility feature. I think that the problem can be fixed if the draft would not include wordin= g about the MOBILE-TICKET internal structure. In one place it is saying tha= t the ticket is opaque and implementation-dependent; but in other places it= suggests how the ticket must be constructed and how it must be encoded. I = think that this is unnecessary. Let's just say that the ticket is opaque an= d its structure has meaning only for the server - and that the server uses = it as a unique identifier. I see no reason why the server must encode any meaningful information in th= e ticket, like 5-tuple and NONCE. That's totally up to the server. The serv= er, for example, may just keep a hashtable with all that information and th= e ticket may be just a random unique key in that table. As we are using mes= sage integrity authentication anyway, and the ticket is transferred openly = over the Internet, the ticket does not create any new level of defense. Thi= s is, basically, just a session ID - to match the "old" session with the "n= ew" session. [TR] Agreed with your assessment will update the draft accordingly. Thanks and Regards, -Tiru. A similar approach is used in RFC 6062. They are solving a similar logical = task: they are matching a new client network endpoint with an existing TURN= session. They also are using a ticket, but they do not encode any informat= ion in it - that is just an opaque unique string. For protection, they also= are validating the MESSAGE INTEGRITY. And they have no problem with the NO= NCE expiration because there is no NONCE encoded in the ticket. Let me know please what do you think about that. Thanks Oleg On Sun, Nov 17, 2013 at 5:36 AM, Tirumaleswar Reddy (tireddy) > wrote: Hi Oleg, It has some similarities but is a lot different from PCP third party author= ization. For example for TURN the Authorization Server will be providing se= ssion key, MAC algorithm etc which is not required with the PCP third party= authorization. There are various other differences like PCP server would = need to communicate with the Authorization Server to determine the token bo= und authorization data (like the number of mappings permitted, flow charac= teristics allowed etc) which may not be required with TURN authorization. = PCP-controlled Firewall will most likely be in the same administrative doma= in as the endpoint but that may not be true with TURN. we are working on the details and will have something concrete in couple of= weeks. Cheers, -Tiru. From: tram-bounces@ietf.org [mailto:tram-boun= ces@ietf.org] On Behalf Of Oleg Moskalenko Sent: Saturday, November 16, 2013 12:56 PM To: Tirumaleswar Reddy (tireddy) Cc: Simon Perreault; tram@ietf.org; Justin Uberti Subject: Re: [tram] First post Tiru, I suppose that will be similar to this draft: http://tools.ietf.org/html/draft-wing-pcp-third-party-authz-01 That would be a significant addition to the TURN server. Regards, Oleg On Fri, Nov 15, 2013 at 7:20 PM, Tirumaleswar Reddy (tireddy) > wrote: Hi Oleg, I am co-author of the MICE, draft-reddy-behave-turn-auth drafts and we are = interested in TURN evolution. Justin and we are working on TURN Extension f= or Third Party Authorization using OAuth which will address some of the pro= blems discussed in above draft. Cheers, -Tiru. From: Oleg Moskalenko > Subject: Re: [tram] First post Date: November 15, 2013 11:01:24 AM PST To: Simon Perreault > Cc: > MMUSIC has an interesting draft on TURN mobility (MICE) that I am watching = and I am going to implement. I wonder whether the authors of the draft may = be interested in the TURN evolution. On Fri, Nov 15, 2013 at 10:55 AM, Simon Perreault > wrote: All, Any objection against sending the following to rtcweb, pntaw, and behave? A= ny other lists that should be included? Simon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D All, A few of us have been working on a proposal for a new working group that wo= uld focus on enhancements to STUN and TURN. The proposed name is TRAM (Turn= Revised And Modernized) and discussion is happening in >. Subscribe link: Here is the charter we have been working on. If you would like to comment a= nd/or get involved, please do so on the TRAM mailing list. Simon (and many others!) Turn Revised And Modernized (tram) ---------------------------------- Traversal Using Relays around NAT (TURN) was published as RFC 5766 in April 2010. Until recently the protocol had only a rather limited deployment. T= his is primarily because its primary use case is as one of the NAT traversal methods of the Interactive Connectivity Establishment (ICE) framework (RFC 5245). This inherent dependency on ICE combined with the fact that ICE its= elf was slow to achieve widespread adoption because other alternative mechanism= s were historically used by the VoIP industry were the causes of the initial lack of interest. This situation has changed drastically as ICE, and consequently TURN, are mandatory to implement in WebRTC, which is a set of technologies developed at the IETF and W3C aiming to enable Real Time Communication on the Web. Because of the ubiquity of the Web and of the new opportunities created by = the arrival of WebRTC, there is a renewed interest in TURN and ICE, as evidence= d by the recent work updating the ICE framework, as well as standardizing the UR= Is used to access a STUN [RFC7064] or TURN [RFC7065] server. The goal of the TRAM Working Group is to consolidate the various initiative= s to update TURN and STUN, including the definition of new transport and authentication mechanisms that make STUN and TURN more suitable for the Web= RTC environment. The Working Group will closely coordinate with the appropriat= e Working Groups, including RTCWEB, MMUSIC, and HTTPBIS. The current list of deliverable is: - DTLS transport for TURN Candidate draft: draft-petithuguenin-tram-turn-dtls TURN defines three transports: UDP, TCP, and TLS. A straightforward exten= sion of this set is DTLS, enabling secure datagram-oriented transport. - New authentication mechanism for TURN Problem analysis: draft-reddy-behave-turn-auth Candidate draft: draft-uberti-behave-turn-rest, OAuth has also been sugge= sted The current authentication mechanism for TURN, which is reused from STUN,= has been designed with a SIP account database in mind. The new RTCWEB usages, which are mostly based on web applications, do not fit that model. A new authentication mechanism optimized for such web applications will be crea= ted. - TURN server auto-discovery mechanism for enterprise and ISPs Candidate draft: TBD Current TURN server discovery is based on the presence of SRV and/or NAPT= R DNS records. These records are usually under the administrative control of th= e application or service provider, not the enterprise or the ISP on whose network the client is situated. Enterprises or ISPs wishing to provide th= eir own TURN server, in an attempt to reduce so-called "triangle routing", ne= ed a new auto-discovery mechanism. - STUN-bis Candidate draft: TBD A new revision of RFC 5389 will contain: - Various bug fixes - STUN hash algorithm agility (currently only SHA-1 is allowed) - TURN-bis Candidate draft: TBD A new revision of RFC 5766 will contain: - Various bug fixes - Support for multi-tenant servers (Servers always send the same REALM attribute. No realm negotiation pha= se currently exists.) Goals and Milestones: [TBD] -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram --_000_913383AAA69FF945B8F946018B75898A24297693xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Oleg,

 <= /p>

I will add the details in= next revision.

 <= /p>

Thanks,=

-Tiru.<= /p>

 

Hi Tiru

in regard to Mobile I= CE, I filled the RFC 6982 template - you can add it as "implementation= status" section to the draft, please see below.

Thanks
Oleg

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

   o  The organization responsible for the implementati=
on, if any.

 
This is a public project, the full list of authors and contributors he=
re: 
http://turnserver.open-sys.org/downloads/AUTHORS


   o  The implementation's name and/or a link to a =
web page describing
      the impl=
ementation.
http://code.google.com/p/rfc5766-turn-server/

   o  A brief general description.

 
A mature open-source TURN server specs implementation (RFC 5766, RFC 6=
062, RFC 6156, etc) 
designed for high-performance applications, especia=
lly geared for WebRTC.

   o  The implementation's level of maturity: resea=
rch, prototype,
      alpha, b=
eta, production, widely used, etc.
widely used (the TURN server itself).

The Mobile ICE feature implementation can be qualifi= ed as "production" - it is well tested and fully implemented, but= not widely used, yet.


   o  Coverage: which parts of the protocol specifi=
cation are
      implemented and which versions of the I=
nternet-Draft were
      implemented.
 
Fully implements MICE with TURN protocol


   o  Licensing: the terms under which the implementati=
on can be used.
      For example: proprietary, royalty licen=
sing, freely distributable
      with acknowledgement (BSD style), freel=
y distributable with
      requirement to redistribute source (Gen=
eral Public License (GPL)
      style), and other (specify).

BSD=
:

http://turnserver.open-sys.org/downloads/LICENSE

&n=
bsp;o  Implementation experience: any useful information the implement=
ers
      want to share with the community.<=
/o:p>
 
MICE implementation is somewhat challenging for a multi-threaded 
p=
erformance-oriented application (because the mobile ticket information 
=
must be shared between the threads) but it is doable.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

 

On Tue, Nov 19, 2013 at 4:26 AM, Tirumaleswar Reddy = (tireddy) <tiredd= y@cisco.com> wrote:

Hi Oleg,

Please see inline [TR]


From: tram-bounces@ietf.org [m= ailto:tram-bounces@ietf.org] O= n Behalf Of Oleg Moskalenko

Sent: Monday, November 18, 2013 12:19 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Simon Perreault; pcp@ietf.org; tram@ietf.org; Justin Uberti

Subject: Re: [tram] F= irst post

Dan and Tiru,
while contemplating the MICE implementation, I stumbled upon a potential pr= oblem in the MICE draft.
According to the section 5.2.2, the server compares the encoded NONCE with = the stored NONCE for the "old" 5-tuple session. But the problem i= s, a NONCE may expire. Its possible to have an expiration time for the NONC= E (an enhanced security feature). In a non-mobility TURN implementation, that creates no problem: the server simple sends 438 = error (stale nonce) back to the client together with the new generated NONC= E value, and the client just re-calculates and re-sends the request.
With wording in the section 5.2.2, that becomes rather complicated in the m= obility case. I am not sure that I understand the exact action sequence whe= n the session NONCE expires with mobility feature.
I think that the problem can be fixed if the draft would not include wordin= g about the MOBILE-TICKET internal structure. In one place it is saying tha= t the ticket is opaque and implementation-dependent; but in other places it= suggests how the ticket must be constructed and how it must be encoded. I think that this is unnecessary. = Let's just say that the ticket is opaque and its structure has meaning only= for the server - and that the server uses it as a unique identifier.
I see no reason why the server must encode any meaningful information in th= e ticket, like 5-tuple and NONCE. That's totally up to the server. The serv= er, for example, may just keep a hashtable with all that information and th= e ticket may be just a random unique key in that table. As we are using message integrity authentication anyway= , and the ticket is transferred openly over the Internet, the ticket does n= ot create any new level of defense. This is, basically, just a session ID -= to match the "old" session with the "new" session.

[TR] Agreed with your assessment will update the dra= ft accordingly.

Thanks and Regards,
-Tiru.


A similar approach is used in RFC 6062. They are solving a similar logical = task: they are matching a new client network endpoint with an existing TURN= session. They also are using a ticket, but they do not encode any informat= ion in it - that is just an opaque unique string. For protection, they also are validating the MESSAGE INTEGR= ITY. And they have no problem with the NONCE expiration because there is no= NONCE encoded in the ticket.

Let me know please what do you think about that.

Thanks
Oleg
 





On Sun, Nov 17, 2013 at 5:36 AM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:
Hi Oleg,
 
It has some similarities but is a lot different from PCP third party author= ization. For example for TURN the Authorization Server will be providing se= ssion key, MAC algorithm etc which is not required with the PCP third party= authorization.  There are various other differences like PCP server would need to communicate with the Autho= rization Server to determine the token bound authorization data  (like= the number of mappings permitted, flow characteristics allowed etc) which = may not be required with TURN authorization.  PCP-controlled Firewall will most likely be in the same administrative dom= ain as the endpoint but that may not be true with TURN.
 

we are working on the details and will have somethin= g concrete in couple of weeks.

 
Cheers,
-Tiru.
From: tram-bounces@ietf.org [m= ailto:tram-bounces@ietf.org] O= n Behalf Of Oleg Moskalenko
Sent: Saturday, November 16, 2013 12:56 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Simon Perreault; tram@ietf.org; Ju= stin Uberti

Subject: Re: [tram] First post
 
Tiru, I suppose that will be similar to this draft:

http://tools.ietf.org/html/draft-wing-pcp-third-party-aut= hz-01
That would be a significant addition to the TURN server.
Regards,
Oleg
 
 
On Fri, Nov 15, 2013 at 7:20 PM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:
Hi Oleg,

I am co-author of the MICE, draft-reddy-behave-turn-auth drafts and we are = interested in TURN evolution. Justin and we are working on TURN Extension f= or Third Party Authorization using OAuth which will address some of the pro= blems discussed in above draft.

Cheers,
-Tiru.

From: Oleg Moskalenko <mom040267@= gmail.com>
Subject: Re: [tram] First post
Date: November 15, 2013 11:01:24 AM PST
To: Simon Perreault <simo= n.perreault@viagenie.ca>
Cc: <tram@ietf.org>

MMUSIC has an interesting draft on TURN mobility (MICE) that I am watching = and I am going to implement. I wonder whether the authors of the draft may = be interested in the TURN evolution.

On Fri, Nov 15, 2013 at 10:55 AM, Simon Perreault <simon.perreault@viagenie.ca> wrote:
All,

Any objection against sending the following to rtcweb, pntaw, and behave? A= ny other lists that should be included?

Simon

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

All,

A few of us have been working on a proposal for a new working group that wo= uld focus on enhancements to STUN and TURN. The proposed name is TRAM (Turn= Revised And Modernized) and discussion is happening in <tram@ietf.org>.
Subscribe link: <https://www.ietf.org/mailman/listinfo/tram>

Here is the charter we have been working on. If you would like to comment a= nd/or get involved, please do so on the TRAM mailing list.

Simon (and many others!)
Turn Revised And Modernized (tram)
----------------------------------

Traversal Using Relays around NAT (TURN) was published as RFC 5766 in April=
2010.  Until recently the protocol had only a rather limited deploymen= t.  This
is primarily because its primary use case is as one of the NAT traversal methods of the Interactive Connectivity Establishment (ICE) framework (RFC<= br> 5245).  This inherent dependency on ICE combined with the fact that IC= E itself
was slow to achieve widespread adoption because other alternative mechanism= s
were historically used by the VoIP industry were the causes of the initial<= br> lack of interest.  This situation has changed drastically as ICE, and<= br> consequently TURN, are mandatory to implement in WebRTC, which is a set of<= br> technologies developed at the IETF and W3C aiming to enable Real Time
Communication on the Web.

Because of the ubiquity of the Web and of the new opportunities created by = the
arrival of WebRTC, there is a renewed interest in TURN and ICE, as evidence= d by
the recent work updating the ICE framework, as well as standardizing the UR= Is
used to access a STUN [RFC7064] or TURN [RFC7065] server.

The goal of the TRAM Working Group is to consolidate the various initiative= s
to update TURN and STUN, including the definition of new transport and
authentication mechanisms that make STUN and TURN more suitable for the Web= RTC
environment.  The Working Group will closely coordinate with the appro= priate
Working Groups, including RTCWEB, MMUSIC, and HTTPBIS.

The current list of deliverable is:

- DTLS transport for TURN

  Candidate draft: draft-petithuguenin-tram-turn-dtls

  TURN defines three transports: UDP, TCP, and TLS. A straightforward = extension
  of this set is DTLS, enabling secure datagram-oriented transport.
- New authentication mechanism for TURN

  Problem analysis: draft-reddy-behave-turn-auth
  Candidate draft: draft-uberti-behave-turn-rest, OAuth has also been = suggested

  The current authentication mechanism for TURN, which is reused from = STUN, has
  been designed with a SIP account database in mind. The new RTCWEB us= ages,
  which are mostly based on web applications, do not fit that model. A= new
  authentication mechanism optimized for such web applications will be= created.

- TURN server auto-discovery mechanism for enterprise and ISPs

  Candidate draft: TBD

  Current TURN server discovery is based on the presence of SRV and/or= NAPTR DNS
  records. These records are usually under the administrative control = of the
  application or service provider, not the enterprise or the ISP on wh= ose
  network the client is situated. Enterprises or ISPs wishing to provi= de their
  own TURN server, in an attempt to reduce so-called "triangle ro= uting", need a
  new auto-discovery mechanism.

- STUN-bis

  Candidate draft: TBD

  A new revision of RFC 5389 will contain:

  - Various bug fixes
  - STUN hash algorithm agility (currently only SHA-1 is allowed)

- TURN-bis

  Candidate draft: TBD

  A new revision of RFC 5766 will contain:

  - Various bug fixes
  - Support for multi-tenant servers
    (Servers always send the same REALM attribute. No realm negot= iation phase
     currently exists.)

Goals and Milestones:

[TBD]

--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca
_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram
 

 

--_000_913383AAA69FF945B8F946018B75898A24297693xmbrcdx10ciscoc_--