From simon.perreault@viagenie.ca Fri Nov 15 10:56:04 2013 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543E811E8214 for ; Fri, 15 Nov 2013 10:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwNDSt3tVL1j for ; Fri, 15 Nov 2013 10:56:03 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3D31C11E812F for ; Fri, 15 Nov 2013 10:55:59 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EFD4F403CB for ; Fri, 15 Nov 2013 13:55:51 -0500 (EST) Message-ID: <52866E37.1030800@viagenie.ca> Date: Fri, 15 Nov 2013 13:55:51 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.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] First post X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 18:56:04 -0000 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 . 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 From mom040267@gmail.com Fri Nov 15 11:01:26 2013 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C5711E814F for ; Fri, 15 Nov 2013 11:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5rLdVicXx1w for ; Fri, 15 Nov 2013 11:01:25 -0800 (PST) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 08ECD11E8143 for ; Fri, 15 Nov 2013 11:01:24 -0800 (PST) Received: by mail-pd0-f174.google.com with SMTP id y10so3848832pdj.33 for ; Fri, 15 Nov 2013 11:01:24 -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=FJiqAI/CsxsihQBhVFZ2emXaOgOBexADzq9N8m55SMQ=; b=kTwYxEZ4fTprkmkIwiwognVLGQEcbNVpnu4Qj3xamxS1ZrQQdwTUzzQkHDAOM72s7I 8lda/sh0vy20+vh9F7VvKtNA26VF3b34epakNGAPH/qtxGl7nDqOAgF0q/s5Pgq2ISbQ SvBiYkSjogz0N83BMay6WNf7SJZciaF3F6GVyA7ldYE4DcbEoSpLWUgGXkutItTWVUKZ 8B50PAiK7uZbDm4ZNr5UVnrmwEnyffUMd2yQyqrz6BU5RVXgYH0oZhKzgKxT1JZP9GfT cvF4VOHHqFi8pgv9HKIfo8M+fcrmWxfNY3MUTR1hvFqF203vJolh1wCzBeXweXu3XId5 4Gxw== MIME-Version: 1.0 X-Received: by 10.68.130.72 with SMTP id oc8mr639980pbb.200.1384542084790; Fri, 15 Nov 2013 11:01:24 -0800 (PST) Received: by 10.68.147.131 with HTTP; Fri, 15 Nov 2013 11:01:24 -0800 (PST) In-Reply-To: <52866E37.1030800@viagenie.ca> References: <52866E37.1030800@viagenie.ca> Date: Fri, 15 Nov 2013 11:01:24 -0800 Message-ID: From: Oleg Moskalenko To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7b10d07d24221504eb3bd313 Cc: tram@ietf.org Subject: Re: [tram] First post X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 19:01:26 -0000 --047d7b10d07d24221504eb3bd313 Content-Type: text/plain; charset=ISO-8859-1 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 > --047d7b10d07d24221504eb3bd313 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
MMUSIC has an interesting draft on TURN mobility (MICE) th= at 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

--047d7b10d07d24221504eb3bd313-- From gsalguei@cisco.com Fri Nov 15 11:20:52 2013 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B672911E80F7 for ; Fri, 15 Nov 2013 11:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-Z6zyYQI7wS for ; Fri, 15 Nov 2013 11:20:48 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id EDCB111E8132 for ; Fri, 15 Nov 2013 11:20:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5736; q=dns/txt; s=iport; t=1384543248; x=1385752848; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8SVU86t0oNBE7N38YqPalJOqMXXt8vcpYFzsG/ik7Gc=; b=DgBvczE4kzu/Y0Np069h33s29HKJAdZKB56VNSjrv6L20YPehMepwhQI 50KvUAK1OTxhfZhiizWmO1CTwXRCS6ydE09iO77EtDuHmRfuO/tT2h0Xx KI6xtJ0uETZyngAojLTx9yemGC40ErUPPVdxiDqe5ipNmyahe5elfxl2T E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAPxyhlKtJXG9/2dsb2JhbABZgwc4U78qgSoWdIIlAQEBAwEBAQEkEzQLBQsCAQgkCQkQJwslAgQOBYd7Bg3BIY4ngQ8zBwqDFoERA5gQgS+QXoMogWhC X-IronPort-AV: E=Sophos;i="4.93,709,1378857600"; d="scan'208";a="285400218" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 15 Nov 2013 19:20:47 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAFJKljs013555 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Nov 2013 19:20:47 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.192]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Fri, 15 Nov 2013 13:20:46 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Simon Perreault Thread-Topic: [tram] First post Thread-Index: AQHO4jRfGh222cArp06+25jlq7HO/5onD74A Date: Fri, 15 Nov 2013 19:20:46 +0000 Message-ID: References: <52866E37.1030800@viagenie.ca> In-Reply-To: <52866E37.1030800@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.237.78] Content-Type: text/plain; charset="us-ascii" Content-ID: <7B349BD9DBA92645A682F8B902EF0E2D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tram@ietf.org" Subject: Re: [tram] First post X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 19:20:52 -0000 No objection.=20 My main concern is that we have some element of agility with this work. The= discussion over the past few days seem to indicate that we have a bunch of= work that is not at all contentious and viewed as valuable by all. This wo= rk would likely get us a (BOF-less) WG stood up quickly and we have work in= progress to address many of those milestones already. I just want to ensur= e we get all this work rolling along, rather than making WG formation depen= dent on issues known to be more contentious, requiring far more discussion = and having many more dependencies on many different groups (i.e., HTTP trav= ersal). To be clear, I'm not saying lets not discuss these thing. I absolu= tely think they are important problems that need solving, but I think those= discussions can happen in parallel and it would be highly inefficient to h= old up all this other work on account of those interminable discussions. Gonzalo On Nov 15, 2013, at 1:55 PM, Simon Perreault = wrote: > All, >=20 > Any objection against sending the following to rtcweb, pntaw, and behave?= Any other lists that should be included? >=20 > Simon >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > All, >=20 > 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 (Tu= rn Revised And Modernized) and discussion is happening in . > Subscribe link: >=20 > 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. >=20 > Simon (and many others!) >=20 >> Turn Revised And Modernized (tram) >> ---------------------------------- >>=20 >> Traversal Using Relays around NAT (TURN) was published as RFC 5766 in Ap= ril >> 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 (R= FC >> 5245). This inherent dependency on ICE combined with the fact that ICE = itself >> was slow to achieve widespread adoption because other alternative mechan= isms >> were historically used by the VoIP industry were the causes of the initi= al >> 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. >>=20 >> 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 evide= nced by >> the recent work updating the ICE framework, as well as standardizing the= URIs >> used to access a STUN [RFC7064] or TURN [RFC7065] server. >>=20 >> The goal of the TRAM Working Group is to consolidate the various initiat= ives >> 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 appropr= iate >> Working Groups, including RTCWEB, MMUSIC, and HTTPBIS. >>=20 >> The current list of deliverable is: >>=20 >> - DTLS transport for TURN >>=20 >> Candidate draft: draft-petithuguenin-tram-turn-dtls >>=20 >> TURN defines three transports: UDP, TCP, and TLS. A straightforward ext= ension >> of this set is DTLS, enabling secure datagram-oriented transport. >>=20 >> - New authentication mechanism for TURN >>=20 >> Problem analysis: draft-reddy-behave-turn-auth >> Candidate draft: draft-uberti-behave-turn-rest, OAuth has also been sug= gested >>=20 >> The current authentication mechanism for TURN, which is reused from STU= N, has >> been designed with a SIP account database in mind. The new RTCWEB usage= s, >> which are mostly based on web applications, do not fit that model. A ne= w >> authentication mechanism optimized for such web applications will be cr= eated. >>=20 >> - TURN server auto-discovery mechanism for enterprise and ISPs >>=20 >> Candidate draft: TBD >>=20 >> Current TURN server discovery is based on the presence of SRV and/or NA= PTR 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. >>=20 >> - STUN-bis >>=20 >> Candidate draft: TBD >>=20 >> A new revision of RFC 5389 will contain: >>=20 >> - Various bug fixes >> - STUN hash algorithm agility (currently only SHA-1 is allowed) >>=20 >> - TURN-bis >>=20 >> Candidate draft: TBD >>=20 >> A new revision of RFC 5766 will contain: >>=20 >> - Various bug fixes >> - Support for multi-tenant servers >> (Servers always send the same REALM attribute. No realm negotiation p= hase >> currently exists.) >>=20 >> Goals and Milestones: >>=20 >> [TBD] >=20 > --=20 > 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 pkyzivat@alum.mit.edu Fri Nov 15 11:44:55 2013 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6E911E810C for ; Fri, 15 Nov 2013 11:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.287 X-Spam-Level: X-Spam-Status: No, score=-0.287 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0e9l7wpfJSCt for ; Fri, 15 Nov 2013 11:44:51 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 1057D11E81D2 for ; Fri, 15 Nov 2013 11:44:33 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta15.westchester.pa.mail.comcast.net with comcast id pqdw1m0020ldTLk5FvkZ4N; Fri, 15 Nov 2013 19:44:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id pvkZ1m00L3ZTu2S01vkZWQ; Fri, 15 Nov 2013 19:44:33 +0000 Message-ID: <528679A1.2060104@alum.mit.edu> Date: Fri, 15 Nov 2013 11:44:33 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: tram@ietf.org References: <52866E37.1030800@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1384544673; bh=xGsL8T9i+iSxvuy7QgS0Z/dqWWMGGQ2gJs8/eP0igA4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=lFT1DtZd21uQTdHN2gmgcmoGkN64IuXxNMy//3D2rstSlNk2sqfirbTbK16E6vDMY E3oIORD2P2Y3HdTLETsYJNeh8iDU/q1x6fTiBqTq9R6HVqlqTrwiJBTmI2E0jnmsrH Br9f7nMYbFXnma5Z2zazuVIcLwQxFwwin4gf5kymzvT8vXh9QMe6aFnhznb1uockxH mbi2PrIer6Ip8XDCUcr8JZmaj3PAoeUcwT/O+RDu82WYUN4mOQ82mnUIRI5XJRjJ+l 5R86KploJUWXjNzbBbQ1js09vn5pc1WD+Q3L51YMJhA7jEyiC15PD6CbZzxztvWElm 6n/RvLreG9vcA== Subject: Re: [tram] First post X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 19:44:55 -0000 Gonzalo, On 11/15/13 11:20 AM, Gonzalo Salgueiro (gsalguei) wrote: > No objection. > > My main concern is that we have some element of agility with this work. The discussion over the past few days seem to indicate that we have a bunch of work that is not at all contentious and viewed as valuable by all. This work would likely get us a (BOF-less) WG stood up quickly and we have work in progress to address many of those milestones already. I just want to ensure we get all this work rolling along, rather than making WG formation dependent on issues known to be more contentious, requiring far more discussion and having many more dependencies on many different groups (i.e., HTTP traversal). To be clear, I'm not saying lets not discuss these thing. I absolutely think they are important problems that need solving, but I think those discussions can happen in parallel and it would be highly inefficient to hold up all this other work on account of those interminable discussions. I understand your concern. And it seems the controversial element has been removed from the charter/milestones. Are you suggesting that the TURN over websockets discussion happen on the TRAM list, but without a milestone? Or are you suggesting that the discussion needs to happen somewhere else? Thanks, Paul > Gonzalo > > On Nov 15, 2013, at 1:55 PM, Simon Perreault 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 . >> 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 > From juberti@google.com Fri Nov 15 12:19:06 2013 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197EC21F967A for ; Fri, 15 Nov 2013 12:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.311 X-Spam-Level: X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sVvJO5XHe3g for ; Fri, 15 Nov 2013 12:19:05 -0800 (PST) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id B869821F8495 for ; Fri, 15 Nov 2013 12:19:04 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id ik5so2128439vcb.9 for ; Fri, 15 Nov 2013 12:19:04 -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=oJos8PWJKQit+I2plFwzQjYuQljffy1lYEswN3SElgw=; b=fPYdPQ+tlKjxvI7WHqFL7MFklMJXoi7t4VUVlcHKF9MYJYPMoaaKvABFHTJ4Y2PKlc DHaJYfxuKXOQZGgOss6bOYdUy+i9OL3WjgLMFRclarsmxAqq4xXj1PGlXjhKr4hBgthF Rv4U5K5MYXa6OzlGzOIzpcxhL9LJO+It7ZjXxYyyPStfpqrsc6qfkRJITCY+HCqCz80V KfQ4aMGFN1MJ01lYTZgzhkLzOScnk6AUOYyMXb4YA2+XYp+Gf89g8lsnlpr8tYWIPnM1 wV9/Hs3CGQQINGWPdRztFbmi1jNJ959CQu2WBqWl6aJR+XfkK8/yeUfWqzirYrnw9ayO scgA== 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=oJos8PWJKQit+I2plFwzQjYuQljffy1lYEswN3SElgw=; b=L6aWeeMspxjLmJH5aQHIMga2Gejfe1ePbVh+MYhyn8Zk2A/Z2ppPWkHVPM0xpTZoU7 F9zLU9kc4jYrhhzDQH1W1reXox40pU4t6F10hb/1RnYE9XCjCg0VO8AvgO4D5dnuBruW nBEsoCnRIaofo/4r0ZH99r1rFkrdqQxTWnfIrRqRJvRp9z04G2TSVGe2JSV8QtYZ8PqO 5XGc0B0SC3oEcspUV+52C6/kpMalNeTuKSVwgDZCy65ZmUl40F5I5/xDOs1+1FvGE/5i Bjr2BUv+P35CTPiTLcfqlxJT8VtgDIm4FJNu6i9cLzUwuwhXQld3swSNdA+WZInb7HvZ 0x4A== X-Gm-Message-State: ALoCoQnJf9QfIJwpO+E/j52e443mh9isDXSSphgMkhm/D6F+pajvPJJztZc1pHuLFftqT1C2lKvSag1fqEAHh2s1eLSG7dY7JbcHOnf5En7wlcWAbHz2NeOKCfUS3cYbHnEBHPQKiAGcfYiHdclpnVAb+QtFQCD8X87BoVv4Fy2GRwvD58DN/rGldKToVGdl3uLSFjxJ4kha X-Received: by 10.221.41.67 with SMTP id tt3mr23675vcb.91.1384546743996; Fri, 15 Nov 2013 12:19:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.110.101 with HTTP; Fri, 15 Nov 2013 12:18:42 -0800 (PST) In-Reply-To: References: <52866E37.1030800@viagenie.ca> From: Justin Uberti Date: Fri, 15 Nov 2013 12:18:42 -0800 Message-ID: To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=001a11338a28d9e3df04eb3ce86d Cc: Simon Perreault , tram@ietf.org Subject: Re: [tram] First post X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 20:19:06 -0000 --001a11338a28d9e3df04eb3ce86d Content-Type: text/plain; charset=UTF-8 How does MICE impact TURN? On Fri, Nov 15, 2013 at 11:01 AM, Oleg Moskalenko wrote: > 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 > > --001a11338a28d9e3df04eb3ce86d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How does MICE impact TURN?


On Fri, Nov 15, 2013 at 11:01 AM, Oleg = Moskalenko <mom040267@gmail.com> wrote:
MMUSIC has an interesting d= raft 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 e= volution.


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. =C2=A0Until recently the protocol had only a rather limited deploymen= t. =C2=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). =C2=A0This 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. =C2=A0This 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. =C2=A0The 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

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

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

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

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

- TURN server auto-discovery mechanism for enterprise and ISPs

=C2=A0 Candidate draft: TBD

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

- STUN-bis

=C2=A0 Candidate draft: TBD

=C2=A0 A new revision of RFC 5389 will contain:

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

- TURN-bis

=C2=A0 Candidate draft: TBD

=C2=A0 A new revision of RFC 5766 will contain:

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

Goals and Milestones:

[TBD]

--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =C2=A0 =C2=A0 =C2=A0 =C2=A0--> http://ecdysis.viagenie.ca
STUN/TURN server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=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


--001a11338a28d9e3df04eb3ce86d-- From mom040267@gmail.com Fri Nov 15 12:22:14 2013 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4EC11E80E0 for ; Fri, 15 Nov 2013 12:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RE9gq8I8qT1A for ; Fri, 15 Nov 2013 12:22:12 -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 0632D21F9FBF for ; Fri, 15 Nov 2013 12:21:56 -0800 (PST) Received: by mail-pb0-f47.google.com with SMTP id rr4so2579915pbb.20 for ; Fri, 15 Nov 2013 12:21:56 -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=MLTei6HNMR0gkXHzZNJ77LK6AjJViQETz6gc/o8NQmQ=; b=nA5U2o0quN1OdLp+Vp2O7JwUZxst+gl8iniq2biaSB9BHqHVKW16mMUzn0bgVx2GEf kebUudCNlGhyP/qDt/aHMUKbTgUFoK9RgJm+OhShIe26pdrR1DeDGsJLgOVwZJSh+mIp 5xJruC72q9NPrErijwQK7Yv3kQL1X0f/YLkBKFhOCfV7RRp2N9jDALGqn0sZY2EtG35M eBa5ScSBRDP5frj1mSlWQg4+DSRL+NTbkZOyB2jwsg5Au707dK8oebDTbi8q2EDDJ3ys MCqnRX41Sl/BoPeG9ULSQmD7tldvJUzIa1OiqrhOBKI9QUXMmOQyZK3K8sdyZ9tQsblO XPJQ== MIME-Version: 1.0 X-Received: by 10.68.111.33 with SMTP id if1mr8231526pbb.31.1384546916509; Fri, 15 Nov 2013 12:21:56 -0800 (PST) Received: by 10.68.147.131 with HTTP; Fri, 15 Nov 2013 12:21:56 -0800 (PST) In-Reply-To: References: <52866E37.1030800@viagenie.ca> Date: Fri, 15 Nov 2013 12:21:56 -0800 Message-ID: From: Oleg Moskalenko To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7b6761882231e904eb3cf3ec Cc: Simon Perreault , tram@ietf.org Subject: Re: [tram] First post X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 20:22:14 -0000 --047d7b6761882231e904eb3cf3ec Content-Type: text/plain; charset=ISO-8859-1 MICE may be interesting for WebRTC on mobile devices. It allows a "mobile" TURN client: when a mobile device is moving from tower to tower, it may change its IP address; but it still wants to keep the same TURN session. They introduce some new behavior and 3 new TURN attributes to achieve that task. On Fri, Nov 15, 2013 at 12:18 PM, Justin Uberti wrote: > How does MICE impact TURN? > > > On Fri, Nov 15, 2013 at 11:01 AM, Oleg Moskalenko wrote: > >> 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 >> >> > --047d7b6761882231e904eb3cf3ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
MICE may be interesting for WebRTC on mobile devices. It a= llows a "mobile" TURN client: when a mobile device is moving from= tower to tower, it may change its IP address; but it still wants to keep t= he same TURN session. They introduce some new behavior and 3 new TURN attri= butes to achieve that task.


On Fri,= Nov 15, 2013 at 12:18 PM, Justin Uberti <juberti@google.com> wrote:
How does MICE impact TURN?<= /div>

On Fri, Nov 15, 2013 at 11:01 AM, Oleg Moskalenko <mom040267@gmail.com> wrote:
MMUSIC has an interesting d= raft 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 e= volution.


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



--047d7b6761882231e904eb3cf3ec-- From juberti@google.com Fri Nov 15 12:24:33 2013 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1824B11E80E4 for ; Fri, 15 Nov 2013 12:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.311 X-Spam-Level: X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YR7z800I8B8 for ; Fri, 15 Nov 2013 12:24:32 -0800 (PST) Received: from mail-vb0-x236.google.com (mail-vb0-x236.google.com [IPv6:2607:f8b0:400c:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 622D611E81CC for ; Fri, 15 Nov 2013 12:23:49 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id q4so3142640vbe.27 for ; Fri, 15 Nov 2013 12:23:48 -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=ObTD9bMqDSpc+Gz32Ji5r+dI5dz9f2NbyDr6iWjJYB4=; b=YvgiVOEIE0ctYgD7ime4+ae5r51H+Cop476/0MHBDcRmRG3fRmMOgGg1NT10sG4G4O KC4AgUz+3tnuyy1BF8Y4sMswc6lC5blHDuUzqbN7i6EQ80/9Bj5SYsKRqLQSzuJVpbZ3 cU1KfUqcRYq62SHHrYfcMdOXSNXDPq8Q/Y5dcqBd4uNiVV+G+S9QItVQRg3LYssDr4on z15C3zuuyJ6AdbdZJ1oD6lmsSURZbwqlEhu6cKV+MDEl0f1MvDaSbjFTYA+3xelNM2mD SaiKw1jI2JRVaghiJOXtnMGbILCuMG4gKhlOxkk/47kDuAbDtCrYqjXvG+yp/BsuPSGE Cn6w== 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=ObTD9bMqDSpc+Gz32Ji5r+dI5dz9f2NbyDr6iWjJYB4=; b=X8B6CobW74uHlbqLoY3Ky34x2cE1AclAdsHq4gKibFfO6SPMufD/gAbJPFwlRm1ebn fS62/gqE0pzxo6kAPKc4cwXZ88ga5KYRNl0JhWzab9AWHlCO/Juz5LE06rxfVWO7t7Fq 6hbL/J3K5gCkykPrmwHWswJdZmrG5jkePpq7anINFAWp/fK/ysjryqJeyoyMx4UBdYzN wpQ6ZPRrN4bsAzND1vbFKDb//y6CeBSsJKx9ul+SdsfL1EJiQGKzklq3S3MKazaJ5bwG 2NXa2KKljxYIuZIM44Z2diWCwwQVu7JlTxlmn4jLSWZ+vZ+XAkkiXk7Zdh/ZzQ1ZnccJ dJ5w== X-Gm-Message-State: ALoCoQmxigw4R/IAJvEIjl+RlMdmp9V7WsdJ8fwZ9qxBMS6o1mzTQt0/vhy9C8fk4lDt9SLw/m9aLKWqsOX4ufHNnrVV9DdZhqgQLbZB9CJrbfrrZ3ufrqaekZmsuftYeBwxMaUG+HKJqTSRmJLSq4XMEety4HUXT3X+tFWi0EGw9GtMvNZCbRO6OyM93xqoJ/sHpZNsdkGc X-Received: by 10.52.232.8 with SMTP id tk8mr38909vdc.76.1384547028714; Fri, 15 Nov 2013 12:23:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.110.101 with HTTP; Fri, 15 Nov 2013 12:23:27 -0800 (PST) In-Reply-To: References: <52866E37.1030800@viagenie.ca> From: Justin Uberti Date: Fri, 15 Nov 2013 12:23:27 -0800 Message-ID: To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=089e01183906d25f2b04eb3cf972 Cc: Simon Perreault , tram@ietf.org Subject: Re: [tram] First post X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 20:24:33 -0000 --089e01183906d25f2b04eb3cf972 Content-Type: text/plain; charset=UTF-8 ... since TURN binds the session to the 5-tuple. makes sense. On Fri, Nov 15, 2013 at 12:21 PM, Oleg Moskalenko wrote: > MICE may be interesting for WebRTC on mobile devices. It allows a "mobile" > TURN client: when a mobile device is moving from tower to tower, it may > change its IP address; but it still wants to keep the same TURN session. > They introduce some new behavior and 3 new TURN attributes to achieve that > task. > > > On Fri, Nov 15, 2013 at 12:18 PM, Justin Uberti wrote: > >> How does MICE impact TURN? >> >> >> On Fri, Nov 15, 2013 at 11:01 AM, Oleg Moskalenko wrote: >> >>> 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 >>> >>> >> > --089e01183906d25f2b04eb3cf972 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
... since TURN binds the session to the 5-tuple. makes sen= se.


On F= ri, Nov 15, 2013 at 12:21 PM, Oleg Moskalenko <mom040267@gmail.com&g= t; wrote:
MICE may be interesting for= WebRTC on mobile devices. It allows a "mobile" TURN client: when= a mobile device is moving from tower to tower, it may change its IP addres= s; but it still wants to keep the same TURN session. They introduce some ne= w behavior and 3 new TURN attributes to achieve that task.

On Fri, Nov 15, 2013 at 12:18 PM, Justin U= berti <juberti@google.com> wrote:
How does MICE impact TURN?<= /div>


On Fri, Nov 15, 2013 at 11:01 AM, Oleg Moskalenko <mom040267@gmail.com> wrote:
MMUSIC has an interesting d= raft 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 e= volution.


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. =C2=A0Until recently the protocol had only a rather limited deploymen= t. =C2=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). =C2=A0This 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. =C2=A0This 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. =C2=A0The 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

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

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

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

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

- TURN server auto-discovery mechanism for enterprise and ISPs

=C2=A0 Candidate draft: TBD

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

- STUN-bis

=C2=A0 Candidate draft: TBD

=C2=A0 A new revision of RFC 5389 will contain:

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

- TURN-bis

=C2=A0 Candidate draft: TBD

=C2=A0 A new revision of RFC 5766 will contain:

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

Goals and Milestones:

[TBD]

--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =C2=A0 =C2=A0 =C2=A0 =C2=A0--> http://ecdysis.viagenie.ca
STUN/TURN server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=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




--089e01183906d25f2b04eb3cf972-- From simon.perreault@viagenie.ca Fri Nov 15 12:27:12 2013 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C6711E8128; Fri, 15 Nov 2013 12:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkVm7tx7-ICS; Fri, 15 Nov 2013 12:27:11 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 50DDE11E80E0; Fri, 15 Nov 2013 12:27:08 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8A20B403CB; Fri, 15 Nov 2013 15:27:07 -0500 (EST) Message-ID: <5286839B.8050305@viagenie.ca> Date: Fri, 15 Nov 2013 15:27:07 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" , pntaw@ietf.org, "behave@ietf.org" , mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tram@ietf.org Subject: [tram] Turn Revised And Modernized (tram) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: tram@ietf.org 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, 15 Nov 2013 20:27:12 -0000 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 . 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 From mom040267@gmail.com Fri Nov 15 12:29:10 2013 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20AC811E8190 for ; Fri, 15 Nov 2013 12:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nt3AQVwlC32X for ; Fri, 15 Nov 2013 12:29:09 -0800 (PST) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 5341211E812F for ; Fri, 15 Nov 2013 12:28:58 -0800 (PST) Received: by mail-pd0-f173.google.com with SMTP id x10so3935596pdj.32 for ; Fri, 15 Nov 2013 12:28:57 -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=APCZOY1eIt6K60z+Phud5GEc+EHiyZ+ScH5M3SeH0fQ=; b=c3vNu6EwUbzZKfG+U4lRpHPCMW7RBFX+TBglvIA3exhr5aqI6gdDI7MwFDx4JoF6dp VoQ2jkkFh070Al+UFfvhP94LPWkmJv2rwLP4ugwJs36T7qceFw8ZnlG7C1+i7lWDLP9p 0DaVqJZIcF0EyG+SVR7eh57IPpdyMfRiIunJmINKx7055oOXpG0OlCZvxiDtUrZl0Vxw f7gI5X/5qkQocBlwPPbAX69IfA8CSMIJC1mjXvj3NFixwR40L7hISWZxcuSAXDTBsjRZ JhicodXwpM7kJa0DcZjCG+p+WNlBmdj/k3HxnIbFXNzPAz0IGn22+ZlwWOSYFFxhWwzK 9IPQ== MIME-Version: 1.0 X-Received: by 10.68.196.227 with SMTP id ip3mr974236pbc.163.1384547337706; Fri, 15 Nov 2013 12:28:57 -0800 (PST) Received: by 10.68.147.131 with HTTP; Fri, 15 Nov 2013 12:28:57 -0800 (PST) In-Reply-To: References: <52866E37.1030800@viagenie.ca> Date: Fri, 15 Nov 2013 12:28:57 -0800 Message-ID: From: Oleg Moskalenko To: Justin Uberti Content-Type: multipart/alternative; boundary=e89a8ff1c81e3d25d604eb3d0cf1 Cc: Simon Perreault , tram@ietf.org Subject: Re: [tram] First post X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 20:29:10 -0000 --e89a8ff1c81e3d25d604eb3d0cf1 Content-Type: text/plain; charset=ISO-8859-1 Yes, that would be an extension to the TURN that allows "session stealing". I went through their draft, it looks reasonable and implementable, and I am sure that it is useful for mobile devices. The security section of their draft sounds reasonable, too: http://tools.ietf.org/id/draft-wing-mmusic-ice-mobility-05.html On Fri, Nov 15, 2013 at 12:23 PM, Justin Uberti wrote: > ... since TURN binds the session to the 5-tuple. makes sense. > > > On Fri, Nov 15, 2013 at 12:21 PM, Oleg Moskalenko wrote: > >> MICE may be interesting for WebRTC on mobile devices. It allows a >> "mobile" TURN client: when a mobile device is moving from tower to tower, >> it may change its IP address; but it still wants to keep the same TURN >> session. They introduce some new behavior and 3 new TURN attributes to >> achieve that task. >> >> >> On Fri, Nov 15, 2013 at 12:18 PM, Justin Uberti wrote: >> >>> How does MICE impact TURN? >>> >>> >>> On Fri, Nov 15, 2013 at 11:01 AM, Oleg Moskalenko wrote: >>> >>>> 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 >>>> >>>> >>> >> > --e89a8ff1c81e3d25d604eb3d0cf1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, that would be an extension to the TURN that allows &q= uot;session stealing". I went through their draft, it looks reasonable= and implementable, and I am sure that it is useful for mobile devices. The= security section of their draft sounds reasonable, too:

http://tools.ietf.org/id/draft-wing-mmusic-ice-mobility-05.html



On Fri, Nov 15, 2013 at 12:23 PM, Justin Uberti <juberti@google.com&g= t; wrote:
... since TURN binds the session to the 5-tuple. makes sen= se.


On Fri, Nov 15, 2013 at 12:21 PM, Oleg = Moskalenko <mom040267@gmail.com> wrote:
MICE may be interesting for= WebRTC on mobile devices. It allows a "mobile" TURN client: when= a mobile device is moving from tower to tower, it may change its IP addres= s; but it still wants to keep the same TURN session. They introduce some ne= w behavior and 3 new TURN attributes to achieve that task.


On Fri, Nov 15, 2013 at 12:18 PM, Justin Uberti <juberti@google.com> wrote:
How does MICE impact TURN?<= /div>


On Fri, Nov 15, 2013 at 11:01 AM, Oleg Moskalenko <mom040267@gmail.com> wrote:
MMUSIC has an interesting d= raft 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 e= volution.


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





--e89a8ff1c81e3d25d604eb3d0cf1-- From dwing@cisco.com Fri Nov 15 12:33:14 2013 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C3C11E8208 for ; Fri, 15 Nov 2013 12:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.766 X-Spam-Level: X-Spam-Status: No, score=-109.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwG5KMc03KO2 for ; Fri, 15 Nov 2013 12:33:10 -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 DD1D811E8203 for ; Fri, 15 Nov 2013 12:33:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15409; q=dns/txt; s=iport; t=1384547590; x=1385757190; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=TS2k62U4ePweJfnEG5pU3xsvIk5UXsYm2ODrOLh2h6s=; b=Jz59VUg0oBu6yellksUlCPTtuy8fXoBfAG7JKGmDsyhnfiDJnt9Xlc2h grgJBWuHqH1+HwelgZqMiCRH78Iiy0w7QXgNVwBN+RRwFIZM6L9mTnVuy vlvNQFwK0VYvdxaBjmcWDyXUy7Zfa/7jDPiJIC9+NianR3iT6+0KMDooc c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsHANuDhlKrRDoJ/2dsb2JhbABZgwc4rVmJYIZkgWGBKhZ0giUBAQEDAQEBASRHCwULCw4KDAkZIQYwBhOHbwMJBQ63Rg2JSIxzgTSBPgQHCoMWgREDiUKMY4FrgS+LJoU4gT2CDBuBLA X-IronPort-AV: E=Sophos;i="4.93,709,1378857600"; d="scan'208,217";a="97679903" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 15 Nov 2013 20:33:08 +0000 Received: from sjc-vpn3-279.cisco.com (sjc-vpn3-279.cisco.com [10.21.65.23]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAFKX6KH000761; Fri, 15 Nov 2013 20:33:06 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_BB71B8FD-969C-45AB-B156-FE80B0FAEE30" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dan Wing In-Reply-To: Date: Fri, 15 Nov 2013 12:33:06 -0800 Message-Id: References: <52866E37.1030800@viagenie.ca> To: Oleg Moskalenko X-Mailer: Apple Mail (2.1510) Cc: Simon Perreault , tram@ietf.org, Justin Uberti Subject: Re: [tram] First post X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 20:33:14 -0000 --Apple-Mail=_BB71B8FD-969C-45AB-B156-FE80B0FAEE30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Nov 15, 2013, at 12:21 PM, Oleg Moskalenko = wrote: > MICE may be interesting for WebRTC on mobile devices. It allows a = "mobile" TURN client: when a mobile device is moving from tower to = tower, it may change its IP address; but it still wants to keep the same = TURN session. They introduce some new behavior and 3 new TURN attributes = to achieve that task.=20 (for others) Those new TURN attributes for MICE effectively do the same = as the HMAC in MPTCP's JOIN (RFC6824) and the similar function in SCTP = (RFC4895 / RFC5061). -d >=20 >=20 > On Fri, Nov 15, 2013 at 12:18 PM, Justin Uberti = wrote: > How does MICE impact TURN? >=20 >=20 > On Fri, Nov 15, 2013 at 11:01 AM, Oleg Moskalenko = wrote: > 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. >=20 >=20 > On Fri, Nov 15, 2013 at 10:55 AM, Simon Perreault = wrote: > All, >=20 > Any objection against sending the following to rtcweb, pntaw, and = behave? Any other lists that should be included? >=20 > Simon >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > All, >=20 > 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 = . > Subscribe link: >=20 > 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. >=20 > Simon (and many others!) >=20 > Turn Revised And Modernized (tram) > ---------------------------------- >=20 > 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. >=20 > 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. >=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 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. >=20 > The current list of deliverable is: >=20 > - DTLS transport for TURN >=20 > Candidate draft: draft-petithuguenin-tram-turn-dtls >=20 > TURN defines three transports: UDP, TCP, and TLS. A straightforward = extension > of this set is DTLS, enabling secure datagram-oriented transport. >=20 > - New authentication mechanism for TURN >=20 > Problem analysis: draft-reddy-behave-turn-auth > Candidate draft: draft-uberti-behave-turn-rest, OAuth has also been = suggested >=20 > 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. >=20 > - TURN server auto-discovery mechanism for enterprise and ISPs >=20 > Candidate draft: TBD >=20 > 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. >=20 > - STUN-bis >=20 > Candidate draft: TBD >=20 > A new revision of RFC 5389 will contain: >=20 > - Various bug fixes > - STUN hash algorithm agility (currently only SHA-1 is allowed) >=20 > - TURN-bis >=20 > Candidate draft: TBD >=20 > A new revision of RFC 5766 will contain: >=20 > - Various bug fixes > - Support for multi-tenant servers > (Servers always send the same REALM attribute. No realm = negotiation phase > currently exists.) >=20 > Goals and Milestones: >=20 > [TBD] >=20 > --=20 > 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 >=20 >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram >=20 >=20 >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram --Apple-Mail=_BB71B8FD-969C-45AB-B156-FE80B0FAEE30 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 mom040267@gmail.com> = wrote:
MICE may be interesting for = WebRTC on mobile devices. It allows a "mobile" TURN client: when a = mobile device is moving from tower to tower, it may change its IP = address; but it still wants to keep the same TURN session. They = introduce some new behavior and 3 new TURN attributes to achieve that = task.

(for others) =  Those new TURN attributes for MICE effectively do the same as the = HMAC in MPTCP's JOIN (RFC6824) and the similar function in SCTP (RFC4895 = / = RFC5061).

-d




On = Fri, Nov 15, 2013 at 12:18 PM, Justin Uberti <juberti@google.com> wrote:
How = does MICE impact TURN?


On Fri, Nov 15, 2013 at 11:01 AM, Oleg Moskalenko <mom040267@gmail.com> wrote:
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

=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 = 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: <https://www.ietf.org/mailman/listinfo/tram>= ;

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



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

= --Apple-Mail=_BB71B8FD-969C-45AB-B156-FE80B0FAEE30-- From gsalguei@cisco.com Fri Nov 15 13:43:33 2013 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7213911E8105 for ; Fri, 15 Nov 2013 13:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wm-za7G752qw for ; Fri, 15 Nov 2013 13:43:28 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id AD3BE21F9C00 for ; Fri, 15 Nov 2013 13:43:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7553; q=dns/txt; s=iport; t=1384551809; x=1385761409; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jQziG89oqLRUAL6c4BiCLvpnTjcJlwhNL9s9bGyi7W0=; b=Fz6E+FfppgMio5Cn5QvN2YGUcBWWEPx/SXDkSSHiTV8MHNbDCZ3UDnEu J/Fus0SsdCVl8cIloMQ3xvrpxo9pAw/aEgw+JdMo6XhOv5kanuj924hy9 KsjXDuBlZovhOn0i68s8R7ABMbLWFuVTl4Di+jwNBk+AeHXvYiy554qwg 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAISUhlKtJV2c/2dsb2JhbABZDoJ5OFO/LIEqFnSCJQEBAQMBAQEBJBM0CwULAgEIDgoMCQkQJwslAgQOBYd7Bg3BHo4nAYEOMwcKgxaBEQOMWYs3gS+GC4pTgmk/gWgBHyI X-IronPort-AV: E=Sophos;i="4.93,710,1378857600"; d="scan'208";a="282464721" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 15 Nov 2013 21:43:28 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rAFLhR5j018330 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Nov 2013 21:43:27 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.192]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Fri, 15 Nov 2013 15:43:27 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Paul Kyzivat Thread-Topic: [tram] First post Thread-Index: AQHO4jRfGh222cArp06+25jlq7HO/5onD74AgAAGpYCAACE3AA== Date: Fri, 15 Nov 2013 21:43:26 +0000 Message-ID: References: <52866E37.1030800@viagenie.ca> <528679A1.2060104@alum.mit.edu> In-Reply-To: <528679A1.2060104@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.237.78] Content-Type: text/plain; charset="us-ascii" Content-ID: <0B20C0E5C9F10349A5D15E6E94154C31@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tram@ietf.org" Subject: Re: [tram] First post X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 21:43:33 -0000 Hi Paul -=20 On Nov 15, 2013, at 2:44 PM, Paul Kyzivat wrote: > Gonzalo, >=20 > On 11/15/13 11:20 AM, Gonzalo Salgueiro (gsalguei) wrote: >> No objection. >>=20 >> My main concern is that we have some element of agility with this work. = The discussion over the past few days seem to indicate that we have a bunch= of work that is not at all contentious and viewed as valuable by all. This= work would likely get us a (BOF-less) WG stood up quickly and we have work= in progress to address many of those milestones already. I just want to en= sure we get all this work rolling along, rather than making WG formation de= pendent on issues known to be more contentious, requiring far more discussi= on and having many more dependencies on many different groups (i.e., HTTP t= raversal). To be clear, I'm not saying lets not discuss these thing. I abs= olutely think they are important problems that need solving, but I think th= ose discussions can happen in parallel and it would be highly inefficient t= o hold up all this other work on account of those interminable discussions. >=20 > I understand your concern. And it seems the controversial element has bee= n removed from the charter/milestones. First, let me admit that I didn't look to see if it was taken off the lates= t version of the charter proposal :-(=20 I (blindly) assumed that it was still on there based on the fact that I did= n't think we had reached consensus. I'm happy to see it settled as it is no= w. > Are you suggesting that the TURN over websockets discussion happen on the= TRAM list, but without a milestone? Or are you suggesting that the discuss= ion needs to happen somewhere else? I view the TRAM list strictly as a pre-WG list. For the sake of efficiency,= IMO we should aim to try and limit discussions to progressing the formatio= n of said WG. The technical discussions around TURNoWS are clearly lightnin= g rods, so I think it is distracting to have them on the TRAM list. That sa= id, I think it is fine to have discussions on the TRAM list related to find= ing a home for those technical discussions of TURNoWS to take place. Cheers, Gonzalo > Thanks, > Paul >=20 >> Gonzalo >>=20 >> On Nov 15, 2013, at 1:55 PM, Simon Perreault wrote: >>=20 >>> All, >>>=20 >>> Any objection against sending the following to rtcweb, pntaw, and behav= e? Any other lists that should be included? >>>=20 >>> Simon >>>=20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> All, >>>=20 >>> A few of us have been working on a proposal for a new working group tha= t would focus on enhancements to STUN and TURN. The proposed name is TRAM (= Turn Revised And Modernized) and discussion is happening in = . >>> Subscribe link: >>>=20 >>> Here is the charter we have been working on. If you would like to comme= nt and/or get involved, please do so on the TRAM mailing list. >>>=20 >>> Simon (and many others!) >>>=20 >>>> Turn Revised And Modernized (tram) >>>> ---------------------------------- >>>>=20 >>>> 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 travers= al >>>> methods of the Interactive Connectivity Establishment (ICE) framework = (RFC >>>> 5245). This inherent dependency on ICE combined with the fact that IC= E itself >>>> was slow to achieve widespread adoption because other alternative mech= anisms >>>> were historically used by the VoIP industry were the causes of the ini= tial >>>> lack of interest. This situation has changed drastically as ICE, and >>>> consequently TURN, are mandatory to implement in WebRTC, which is a se= t of >>>> technologies developed at the IETF and W3C aiming to enable Real Time >>>> Communication on the Web. >>>>=20 >>>> Because of the ubiquity of the Web and of the new opportunities create= d by the >>>> arrival of WebRTC, there is a renewed interest in TURN and ICE, as evi= denced by >>>> the recent work updating the ICE framework, as well as standardizing t= he URIs >>>> used to access a STUN [RFC7064] or TURN [RFC7065] server. >>>>=20 >>>> The goal of the TRAM Working Group is to consolidate the various initi= atives >>>> to update TURN and STUN, including the definition of new transport and >>>> authentication mechanisms that make STUN and TURN more suitable for th= e WebRTC >>>> environment. The Working Group will closely coordinate with the appro= priate >>>> Working Groups, including RTCWEB, MMUSIC, and HTTPBIS. >>>>=20 >>>> The current list of deliverable is: >>>>=20 >>>> - DTLS transport for TURN >>>>=20 >>>> Candidate draft: draft-petithuguenin-tram-turn-dtls >>>>=20 >>>> TURN defines three transports: UDP, TCP, and TLS. A straightforward e= xtension >>>> of this set is DTLS, enabling secure datagram-oriented transport. >>>>=20 >>>> - New authentication mechanism for TURN >>>>=20 >>>> Problem analysis: draft-reddy-behave-turn-auth >>>> Candidate draft: draft-uberti-behave-turn-rest, OAuth has also been s= uggested >>>>=20 >>>> The current authentication mechanism for TURN, which is reused from S= TUN, has >>>> been designed with a SIP account database in mind. The new RTCWEB usa= ges, >>>> which are mostly based on web applications, do not fit that model. A = new >>>> authentication mechanism optimized for such web applications will be = created. >>>>=20 >>>> - TURN server auto-discovery mechanism for enterprise and ISPs >>>>=20 >>>> Candidate draft: TBD >>>>=20 >>>> Current TURN server discovery is based on the presence of SRV and/or = NAPTR DNS >>>> records. These records are usually under the administrative control o= f the >>>> application or service provider, not the enterprise or the ISP on who= se >>>> network the client is situated. Enterprises or ISPs wishing to provid= e their >>>> own TURN server, in an attempt to reduce so-called "triangle routing"= , need a >>>> new auto-discovery mechanism. >>>>=20 >>>> - STUN-bis >>>>=20 >>>> Candidate draft: TBD >>>>=20 >>>> A new revision of RFC 5389 will contain: >>>>=20 >>>> - Various bug fixes >>>> - STUN hash algorithm agility (currently only SHA-1 is allowed) >>>>=20 >>>> - TURN-bis >>>>=20 >>>> Candidate draft: TBD >>>>=20 >>>> A new revision of RFC 5766 will contain: >>>>=20 >>>> - Various bug fixes >>>> - Support for multi-tenant servers >>>> (Servers always send the same REALM attribute. No realm negotiation= phase >>>> currently exists.) >>>>=20 >>>> Goals and Milestones: >>>>=20 >>>> [TBD] >>>=20 >>> -- >>> 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 >>=20 >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >>=20 >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From tireddy@cisco.com Fri Nov 15 19:20:37 2013 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB3111E816B for ; Fri, 15 Nov 2013 19:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWlKscGH0GHm for ; Fri, 15 Nov 2013 19:20:32 -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 AB8FB11E813A for ; Fri, 15 Nov 2013 19:20:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5340; q=dns/txt; s=iport; t=1384572032; x=1385781632; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=USlKYnbT/GUtMaO4H/1i4JCYKeZegzCAyrt2aVKcH58=; b=SDLy4msWhQ0yY5v6GwZmyc+GY9T5VEI+EZj0tHGUaIPlHCy17tCBK4F4 E9EisgH37ekodrItKplr00RP5UwbU7jC5G9RR3h+uReOJsJdYjEu8mYFT JH/dAbHZ2CiCd+TGnF1BnCpiYs28nSDScneQUnv5xdkFJANlbyagHXs1i U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAHvjhlKtJV2a/2dsb2JhbABZgwc4U78sgSsWdIIlAQEBBAEBASRHCxACAQgOAwMBAgsCCRkhBgsdCAIEDgUIh2cDDw23Hw2JUIxzgTSBDwIxBwqDFoERA4kKjRuDGosmhTiDKIFoQg X-IronPort-AV: E=Sophos;i="4.93,711,1378857600"; d="scan'208";a="992" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-2.cisco.com with ESMTP; 16 Nov 2013 03:20:31 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAG3KUWD024962 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 16 Nov 2013 03:20:31 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Fri, 15 Nov 2013 21:20:30 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko Thread-Topic: [tram] First post Thread-Index: AQHO4nrNOeLu8IlzsEisOVsWZS4tvA== Date: Sat, 16 Nov 2013 03:20:29 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A24264EF5@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.58.211] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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.12 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, 16 Nov 2013 03:20:37 -0000 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. =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 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 lack of interest. =A0This 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. =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 routing", = 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] --=20 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 https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram From mom040267@gmail.com Fri Nov 15 20:56:08 2013 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABA711E8175 for ; Fri, 15 Nov 2013 20:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBm1x5pNc1sX for ; Fri, 15 Nov 2013 20:56:05 -0800 (PST) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id E7A4F11E8168 for ; Fri, 15 Nov 2013 20:56:01 -0800 (PST) Received: by mail-pb0-f54.google.com with SMTP id ro12so4486698pbb.27 for ; Fri, 15 Nov 2013 20:56:01 -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=wE8cZ6DQrJ1cOoSHBDyD5s/zVyTLw1kqqqsdjHQKVGU=; b=g93ZVp3focASYflDUgP9i6+pz7n+LqxRK85mkXaPp0AQiBgmw/MyI0fp8ieaNAPz7S 55i28lRNjnOv4WTc4eX9YIVJyb7yhBUadOIt2jntOzdLJ38fD/k9PkOuCczBmgkdLCen JehT/+P5Q/8Nu1bC1/tP5Kvtm0VRPFOi9ZZwXNgXzGJ2g195vVy0y5A/AiCYelM6AGY/ H0UQTVTjzwXU1oeRvyds8WmgMSOfkK/bqA/6K/OS8NP9yqZD1Ewr++V1CBUUBHruvwgn 80VWHM3RCZb60aZslj4etxvltLOa4fF3ziYF4Mb64mkQOOsmHG0k3gMMYBgK+rlOby04 ncOw== MIME-Version: 1.0 X-Received: by 10.66.139.196 with SMTP id ra4mr10336785pab.103.1384577761610; Fri, 15 Nov 2013 20:56:01 -0800 (PST) Received: by 10.68.147.131 with HTTP; Fri, 15 Nov 2013 20:56:01 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A24264EF5@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A24264EF5@xmb-rcd-x10.cisco.com> Date: Fri, 15 Nov 2013 20:56:01 -0800 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=047d7b5dbaaca511bb04eb44216b Cc: Simon Perreault , "tram@ietf.org" , Justin Uberti Subject: Re: [tram] First post X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2013 04:56:08 -0000 --047d7b5dbaaca511bb04eb44216b Content-Type: text/plain; charset=ISO-8859-1 I reviewed the TURN part of the MICE and it looks promising. I am going to add it as an experimental extension to our TURN server implementation. The authorization work is very interesting, too. 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 > > --047d7b5dbaaca511bb04eb44216b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I reviewed the TURN part of the MICE and it look= s promising. I am going to add it as an experimental extension to our TURN server=20 implementation.

The authorization work is very interesting, t= oo.

Regards,
Oleg

<= br>
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


--047d7b5dbaaca511bb04eb44216b-- From mom040267@gmail.com Fri Nov 15 23:26:13 2013 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2450311E80FE for ; Fri, 15 Nov 2013 23:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFqyEf4E1fFc for ; Fri, 15 Nov 2013 23:26:11 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id A9BEB11E8177 for ; Fri, 15 Nov 2013 23:26:10 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id fb1so4639301pad.10 for ; Fri, 15 Nov 2013 23:26:09 -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=NlyocrV2tlbRlApPYRaiEOdZF1tUoq7RHOCLO3h5fzQ=; b=rjaih2RDcCX9bj0dfxigy36k7tJBPZe2Ef0MHafcAViob+3LbOIPS4wB1SJnKbXKxY o5mRfBEcwKReFISSZihB2yY+qVPPJFAzftwCh9Us4wHwT4b5a1BK1xpypdO96R+BqbWZ 6h//k8VN8H3GRaP6ae3XCf5psnArPh5gplSamtC5alLkScp5ZWsUgFq4RX46UY2RNT/Z CfUxV3ee3YZ47XceWlQFpaFP7/21rx5gdZZZQd6fkCDCW+tHyG0zN0zHhO9LqtOJBBAp kZVo+ZPZte/CmGzXTHC0sArI9bAWg0/o0pGQHLPN65RnzlFAywCbfEirrS81mwNWXrDP +R4g== MIME-Version: 1.0 X-Received: by 10.68.204.193 with SMTP id la1mr2963118pbc.159.1384586769314; Fri, 15 Nov 2013 23:26:09 -0800 (PST) Received: by 10.68.147.131 with HTTP; Fri, 15 Nov 2013 23:26:09 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A24264EF5@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A24264EF5@xmb-rcd-x10.cisco.com> Date: Fri, 15 Nov 2013 23:26:09 -0800 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=e89a8ffbae9b8bba4304eb463ab5 Cc: Simon Perreault , "tram@ietf.org" , Justin Uberti Subject: Re: [tram] First post X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2013 07:26:13 -0000 --e89a8ffbae9b8bba4304eb463ab5 Content-Type: text/plain; charset=ISO-8859-1 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 > > --e89a8ffbae9b8bba4304eb463ab5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Nov 15, 2013 at 7:20 PM, Tirumales= war 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


--e89a8ffbae9b8bba4304eb463ab5-- From tireddy@cisco.com Sun Nov 17 05:37:05 2013 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A7811E8D1F; Sun, 17 Nov 2013 05:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NEhWjvpDG94; Sun, 17 Nov 2013 05:37:00 -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 82DD611E8CFC; Sun, 17 Nov 2013 05:36:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19617; q=dns/txt; s=iport; t=1384695417; x=1385905017; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=u3CA3DqnfYjEGmlhjM+o5qeuUq6S1IfkNDn2t1CiZ3c=; b=L2Aou3+7Gqd2ZP4RAU+Llr35WSvnMSrm0IoAEbh3B6A2WepNdFNQUu44 zONluOy+KJ10fLTngEh3yzhWgFMWven5eja533+L0AWq35t5R4gQ2t0BN xjT9+ghE8BMguBUeAoc4WggBGF/i8Yn/+nczjJfSVmPm2qroop1+oZ5xi U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAHAFDGiFKtJXG+/2dsb2JhbABZgkNEOFOtBYlgiEWBEBZ0giUBAQEEAQEBJAZBCxACAQgOAwMBAQELAgkSByEGCxQJCAIEDgUIh2cDDw23QA2JOReMc4E0gREgDQQGAQkBgxaBEQOWJYMaiyaFOIMogWhC X-IronPort-AV: E=Sophos;i="4.93,718,1378857600"; d="scan'208,217";a="145559" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-1.cisco.com with ESMTP; 17 Nov 2013 13:36:42 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAHDagKp007235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 17 Nov 2013 13:36:42 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Sun, 17 Nov 2013 07:36:42 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko Thread-Topic: [tram] First post Thread-Index: AQHO4nrNOeLu8IlzsEisOVsWZS4tvJon2dyA//+cN3A= Date: Sun, 17 Nov 2013 13:36:41 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A24265484@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A24264EF5@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.44.182] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A24265484xmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: Simon Perreault , "pcp@ietf.org" , "tram@ietf.org" , Justin Uberti Subject: Re: [tram] First post X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 17 Nov 2013 13:37:05 -0000 --_000_913383AAA69FF945B8F946018B75898A24265484xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 the details and will have something concrete in coupl= e of weeks. Cheers, -Tiru. From: tram-bounces@ietf.org [mailto:tram-bounces@ietf.org] On Behalf Of Ole= g 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_913383AAA69FF945B8F946018B75898A24265484xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Oleg,

 

It has some similarities but is a lot different from PCP thi= rd 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 auth= orization.  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 characteristics allowed etc) which may not be = required with TURN authorization.  PCP-controlled Firewall will most l= ikely be in the same administrative domain as the endpoint but that may not= be true with TURN.

 

we are working on the the details and will have something co= ncrete in couple of weeks.

 

Cheers,

-Tiru.

From: tram-bou= nces@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 signi= ficant addition to the TURN server.

Regards,
Oleg

 

 

On Fri, Nov 15, 2013 at 7:20 PM, Tirumaleswar Reddy = (tireddy) <tiredd= y@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_913383AAA69FF945B8F946018B75898A24265484xmbrcdx10ciscoc_-- From mom040267@gmail.com Sun Nov 17 22:48:34 2013 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A6D11E857E; Sun, 17 Nov 2013 22:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id easf7LY-Y+4h; Sun, 17 Nov 2013 22:48:31 -0800 (PST) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED3811E8575; Sun, 17 Nov 2013 22:48:31 -0800 (PST) Received: by mail-pb0-f49.google.com with SMTP id jt11so1756683pbb.36 for ; Sun, 17 Nov 2013 22:48:31 -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=/5a2XX8OydSTp0y5EbnspA06CFSsFD94Z+/eF3Oq/ZY=; b=uSTxcn6AhQ8z1pVNi+YC1FfAGErUMVMzHAtsPWdS02/gtvgcY8tkx+OVDAd5DubB/N Ft4ydPxoBVnhntbWolyIQRfQhKraWG8M4AVwckeLOR0P45mqdWWOjIPCCyhUJa38Apga pT1yR1+verGGLEsEc2DOkui64ZCJT57uPRmEmwjPLL2VDTa9/iBm9+qrne7exW3yZoiL XFBxdZU+azV0SUG3Ak3QGpXdhm7oYJoS4UM/wGt0SgQtysioiijBTdHpcv3rWWcHSZhi leuybab4KybDPObO1LrsyZQ1XgurMJ6VCWPctjcT+/ra3YHiXNUoPOb++f7KJpKDld/1 V/EA== MIME-Version: 1.0 X-Received: by 10.66.8.66 with SMTP id p2mr1340233paa.129.1384757310969; Sun, 17 Nov 2013 22:48:30 -0800 (PST) Received: by 10.68.147.131 with HTTP; Sun, 17 Nov 2013 22:48:30 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A24265484@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A24264EF5@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A24265484@xmb-rcd-x10.cisco.com> Date: Sun, 17 Nov 2013 22:48:30 -0800 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=bcaec51f97b19edef604eb6defec Cc: Simon Perreault , "pcp@ietf.org" , "tram@ietf.org" , Justin Uberti Subject: Re: [tram] First post X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.12 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, 18 Nov 2013 06:48:34 -0000 --bcaec51f97b19edef604eb6defec Content-Type: text/plain; charset=ISO-8859-1 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. 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 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 > > > --bcaec51f97b19edef604eb6defec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dan and Tiru,

w= hile contemplating the MICE implementation, I stumbled upon a potential pro= blem in the MICE draft.

According to the section 5.2.2, the se= rver compares the encoded NONCE with the stored NONCE for the "old&quo= t; 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 simp= le sends 438 error (stale nonce) back to the client together with the new g= enerated NONCE value, and the client just re-calculates and re-sends the re= quest.

With wording in the section 5.2.2, that becomes rather complicate= d in the mobility case. I am not sure that I understand the exact action se= quence when 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 informa= tion in the ticket, like 5-tuple and NONCE. That's totally up to the se= rver. The server, for example, may just keep a hashtable with all that info= rmation 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 trans= ferred openly over the Internet, the ticket does not create any new level o= f defense. This is, basically, just a session ID - to match the "old&q= uot; session with the "new" session.

A similar approach is used in RFC 6062. They are solving a s= imilar logical task: they are matching a new client network endpoint with a= n existing TURN session. They also are using a ticket, but they do not enco= de any information in it - that is just an opaque unique string. For protec= tion, they also are validating the MESSAGE INTEGRITY. And they have no prob= lem with the NONCE expiration because there is no NONCE encoded in the tick= et.

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@cis= co.com> wrote:

Hi Oleg,

=A0<= /p>

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 auth= orization.=A0 There are various other differences like PCP server would nee= d to communicate with the Authorization Server to determine the token bound= authorization data =A0(like the number of mappings permitted, flow characteristics allowed etc) which may not be = required with TURN authorization.=A0 PCP-controlled Firewall will most like= ly be in the same administrative domain as the endpoint but that may not be= true with TURN.

=A0<= /p>

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

=A0<= /p>

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

=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 signi= ficant addition to the TURN server.

Regards,
Oleg

=A0

=A0

On Fri, Nov 15, 2013 at 7:20 PM, Tirumaleswar Reddy = (tireddy) <tiredd= y@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 <simon.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


--bcaec51f97b19edef604eb6defec-- From pkyzivat@alum.mit.edu Mon Nov 18 07:05:00 2013 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45CBE11E827C for ; Mon, 18 Nov 2013 07:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.337 X-Spam-Level: X-Spam-Status: No, score=-0.337 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgTkxU8LoeBe for ; Mon, 18 Nov 2013 07:04:54 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 968E111E8470 for ; Mon, 18 Nov 2013 06:59:09 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta13.westchester.pa.mail.comcast.net with comcast id r0mv1m00716LCl05D2z83G; Mon, 18 Nov 2013 14:59:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id r2z81m00a3ZTu2S3S2z8re; Mon, 18 Nov 2013 14:59:08 +0000 Message-ID: <528A2B3C.4090307@alum.mit.edu> Date: Mon, 18 Nov 2013 06:59:08 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Gonzalo Salgueiro (gsalguei)" References: <52866E37.1030800@viagenie.ca> <528679A1.2060104@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1384786748; bh=czpgPap0m9wtd/LIrLSsrdicHnDC6L4B0SAMn2gKKEI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jFKN3o4KyBoqqlMFCvXefLzniaS9pNwhj/cU6eLGvyBcY4H9fpj5Qhxu2+dAkmur9 hV72twtI3lGQoZyLSRjijPORXU9R59a/vROsB+jL9Hyt7SRVwDOygB7MCbL80zPsbe wn82cYZi5HoFLg1FW7QqMGdweh98rE7CjQ+zAcw/WbpJ/faPuE3sk0ztVXJikKX/S9 kD/egA/73DLztQHJn5UMN0XpLcp6B3HAEw35i1FSTPEWfXl5GvMKO1aftUbs9FWoVb h/kyovvbIEidxoUvsClOU4YknJ0UCDvSfQCRuWze866uNesR94hE59X3c2q2dhAdJw TNBut4y6kfWtA== Cc: "tram@ietf.org" Subject: Re: [tram] First post X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.12 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, 18 Nov 2013 15:05:00 -0000 On 11/15/13 1:43 PM, Gonzalo Salgueiro (gsalguei) wrote: > Hi Paul - > > On Nov 15, 2013, at 2:44 PM, Paul Kyzivat wrote: > >> Gonzalo, >> >> On 11/15/13 11:20 AM, Gonzalo Salgueiro (gsalguei) wrote: >>> No objection. >>> >>> My main concern is that we have some element of agility with this work. The discussion over the past few days seem to indicate that we have a bunch of work that is not at all contentious and viewed as valuable by all. This work would likely get us a (BOF-less) WG stood up quickly and we have work in progress to address many of those milestones already. I just want to ensure we get all this work rolling along, rather than making WG formation dependent on issues known to be more contentious, requiring far more discussion and having many more dependencies on many different groups (i.e., HTTP traversal). To be clear, I'm not saying lets not discuss these thing. I absolutely think they are important problems that need solving, but I think those discussions can happen in parallel and it would be highly inefficient to hold up all this other work on account of those interminable discussions. >> >> I understand your concern. And it seems the controversial element has been removed from the charter/milestones. > > First, let me admit that I didn't look to see if it was taken off the latest version of the charter proposal :-( > I (blindly) assumed that it was still on there based on the fact that I didn't think we had reached consensus. I'm happy to see it settled as it is now. > >> Are you suggesting that the TURN over websockets discussion happen on the TRAM list, but without a milestone? Or are you suggesting that the discussion needs to happen somewhere else? > > I view the TRAM list strictly as a pre-WG list. For the sake of efficiency, IMO we should aim to try and limit discussions to progressing the formation of said WG. The technical discussions around TURNoWS are clearly lightning rods, so I think it is distracting to have them on the TRAM list. That said, I think it is fine to have discussions on the TRAM list related to finding a home for those technical discussions of TURNoWS to take place. I have repeatedly asked *where* we could have that discussion in a way that satisfies those who are concerned. If we can't have it on TRAM, then were else? Or are you suggesting that we should not have that discussion at all right now? (Rather wait for a WG to be chartered, and *then* have the discussion.) Thanks, Paul > Cheers, > > Gonzalo > >> Thanks, >> Paul >> >>> Gonzalo >>> >>> On Nov 15, 2013, at 1:55 PM, Simon Perreault 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 . >>>> 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 >>> >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram > > From simon.perreault@viagenie.ca Mon Nov 18 08:13:01 2013 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA0711E8122 for ; Mon, 18 Nov 2013 08:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTd1N3O+Upoj for ; Mon, 18 Nov 2013 08:13:01 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 121DB11E81D9 for ; Mon, 18 Nov 2013 08:09:31 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A5DD9403C5 for ; Mon, 18 Nov 2013 11:09:20 -0500 (EST) Message-ID: <528A3BB0.3040302@viagenie.ca> Date: Mon, 18 Nov 2013 11:09:20 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: tram@ietf.org References: <52866E37.1030800@viagenie.ca> <528679A1.2060104@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [tram] First post X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.12 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, 18 Nov 2013 16:13:02 -0000 Le 2013-11-15 16:43, Gonzalo Salgueiro (gsalguei) a écrit : > First, let me admit that I didn't look to see if it was taken off the latest version of the charter proposal :-( > I (blindly) assumed that it was still on there based on the fact that I didn't think we had reached consensus. I'm happy to see it settled as it is now. As a reminder, the latest version of the proposed charter is always available here: https://github.com/petithug/tram-charter/blob/master/charter.txt > I view the TRAM list strictly as a pre-WG list. For now, yes. But I hope it becomes a WG list soon! :) 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 Mon Nov 18 16:28:23 2013 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 3878D1AE73B for ; Mon, 18 Nov 2013 16:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.026 X-Spam-Level: X-Spam-Status: No, score=-10.026 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.525, 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 qS711UJgDMi6 for ; Mon, 18 Nov 2013 16:28:20 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 40C101AE722 for ; Mon, 18 Nov 2013 16:28:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8779; q=dns/txt; s=iport; t=1384820894; x=1386030494; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=MyYJcr2mv8/ZAL3RyB8L5lk5NvFsk4Z0ue8GWhVkaOc=; b=Q+hUeiydVXQ7DAdp1CHmUMVaH3qqNA+5oSkAuq1lr5MmXWOCCK94JB7k YMH2hd8hBHRTQW/B/OpStjHI50/0N2VsX34E15nJVlqycxp7mmmbIY4Wx i8+GxDLYnbppqmUvr9Q1hrsMRCMD26+nriDVXt6NSsWgqo0IX6VWjL8AA o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwFADmvilKtJXG+/2dsb2JhbABZDoJ5OFO/NYEdFnSCJQEBAQMBAQEBJAJFCwULAgECBg4KDAkZJwslAgQOBYd7Bg3CIReOJwGBDjMHCoMWgREDiQqDT4s3gS+GC4pTgmk/gWgBHyI X-IronPort-AV: E=Sophos;i="4.93,727,1378857600"; d="scan'208";a="493054" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-6.cisco.com with ESMTP; 19 Nov 2013 00:28:13 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAJ0SDSV030654 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Nov 2013 00:28:13 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.192]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Mon, 18 Nov 2013 18:28:12 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Paul Kyzivat Thread-Topic: [tram] First post Thread-Index: AQHO4jRfGh222cArp06+25jlq7HO/5onD74AgAAGpYCAACE3AIAERgkAgACe+gA= Importance: high X-Priority: 1 Date: Tue, 19 Nov 2013 00:28:12 +0000 Message-ID: References: <52866E37.1030800@viagenie.ca> <528679A1.2060104@alum.mit.edu> <528A2B3C.4090307@alum.mit.edu> In-Reply-To: <528A2B3C.4090307@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.116.101] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tram@ietf.org" 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: Tue, 19 Nov 2013 00:28:23 -0000 On Nov 18, 2013, at 6:59 AM, Paul Kyzivat wrote: > On 11/15/13 1:43 PM, Gonzalo Salgueiro (gsalguei) wrote: >> Hi Paul - >>=20 >> On Nov 15, 2013, at 2:44 PM, Paul Kyzivat wrote: >>=20 >>> Gonzalo, >>>=20 >>> On 11/15/13 11:20 AM, Gonzalo Salgueiro (gsalguei) wrote: >>>> No objection. >>>>=20 >>>> My main concern is that we have some element of agility with this work= . The discussion over the past few days seem to indicate that we have a bun= ch of work that is not at all contentious and viewed as valuable by all. Th= is work would likely get us a (BOF-less) WG stood up quickly and we have wo= rk in progress to address many of those milestones already. I just want to = ensure we get all this work rolling along, rather than making WG formation = dependent on issues known to be more contentious, requiring far more discus= sion and having many more dependencies on many different groups (i.e., HTTP= traversal). To be clear, I'm not saying lets not discuss these thing. I a= bsolutely think they are important problems that need solving, but I think = those discussions can happen in parallel and it would be highly inefficient= to hold up all this other work on account of those interminable discussion= s. >>>=20 >>> I understand your concern. And it seems the controversial element has b= een removed from the charter/milestones. >>=20 >> First, let me admit that I didn't look to see if it was taken off the la= test version of the charter proposal :-( >> I (blindly) assumed that it was still on there based on the fact that I = didn't think we had reached consensus. I'm happy to see it settled as it is= now. >>=20 >>> Are you suggesting that the TURN over websockets discussion happen on t= he TRAM list, but without a milestone? Or are you suggesting that the discu= ssion needs to happen somewhere else? >>=20 >> I view the TRAM list strictly as a pre-WG list. For the sake of efficien= cy, IMO we should aim to try and limit discussions to progressing the forma= tion of said WG. The technical discussions around TURNoWS are clearly light= ning rods, so I think it is distracting to have them on the TRAM list. That= said, I think it is fine to have discussions on the TRAM list related to f= inding a home for those technical discussions of TURNoWS to take place. >=20 > I have repeatedly asked *where* we could have that discussion in a way th= at satisfies those who are concerned. If we can't have it on TRAM, then wer= e else? I feel your pain and agree we need to figure out where. I simply think tha= t discussion would entirely consume and eventually fracture this group and = would consequently delay formation of a WG to do all this this other work. = I'm trying to be practical here and ensure *something* gets done in a timel= y fashion. >=20 > Or are you suggesting that we should not have that discussion at all righ= t now? (Rather wait for a WG to be chartered, and *then* have the discussio= n.) Yeah, this is where I'm going. Gonzalo >=20 > Thanks, > Paul >=20 >> Cheers, >>=20 >> Gonzalo >>=20 >>> Thanks, >>> Paul >>>=20 >>>> Gonzalo >>>>=20 >>>> On Nov 15, 2013, at 1:55 PM, Simon Perreault wrote: >>>>=20 >>>>> All, >>>>>=20 >>>>> Any objection against sending the following to rtcweb, pntaw, and beh= ave? Any other lists that should be included? >>>>>=20 >>>>> Simon >>>>>=20 >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>=20 >>>>> All, >>>>>=20 >>>>> A few of us have been working on a proposal for a new working group t= hat would focus on enhancements to STUN and TURN. The proposed name is TRAM= (Turn Revised And Modernized) and discussion is happening in . >>>>> Subscribe link: >>>>>=20 >>>>> Here is the charter we have been working on. If you would like to com= ment and/or get involved, please do so on the TRAM mailing list. >>>>>=20 >>>>> Simon (and many others!) >>>>>=20 >>>>>> Turn Revised And Modernized (tram) >>>>>> ---------------------------------- >>>>>>=20 >>>>>> Traversal Using Relays around NAT (TURN) was published as RFC 5766 i= n April >>>>>> 2010. Until recently the protocol had only a rather limited deploym= ent. This >>>>>> is primarily because its primary use case is as one of the NAT trave= rsal >>>>>> methods of the Interactive Connectivity Establishment (ICE) framewor= k (RFC >>>>>> 5245). This inherent dependency on ICE combined with the fact that = ICE itself >>>>>> was slow to achieve widespread adoption because other alternative me= chanisms >>>>>> were historically used by the VoIP industry were the causes of the i= nitial >>>>>> lack of interest. This situation has changed drastically as ICE, an= d >>>>>> consequently TURN, are mandatory to implement in WebRTC, which is a = set of >>>>>> technologies developed at the IETF and W3C aiming to enable Real Tim= e >>>>>> Communication on the Web. >>>>>>=20 >>>>>> Because of the ubiquity of the Web and of the new opportunities crea= ted by the >>>>>> arrival of WebRTC, there is a renewed interest in TURN and ICE, as e= videnced by >>>>>> the recent work updating the ICE framework, as well as standardizing= the URIs >>>>>> used to access a STUN [RFC7064] or TURN [RFC7065] server. >>>>>>=20 >>>>>> The goal of the TRAM Working Group is to consolidate the various ini= tiatives >>>>>> to update TURN and STUN, including the definition of new transport a= nd >>>>>> authentication mechanisms that make STUN and TURN more suitable for = the WebRTC >>>>>> environment. The Working Group will closely coordinate with the app= ropriate >>>>>> Working Groups, including RTCWEB, MMUSIC, and HTTPBIS. >>>>>>=20 >>>>>> The current list of deliverable is: >>>>>>=20 >>>>>> - DTLS transport for TURN >>>>>>=20 >>>>>> Candidate draft: draft-petithuguenin-tram-turn-dtls >>>>>>=20 >>>>>> TURN defines three transports: UDP, TCP, and TLS. A straightforward= extension >>>>>> of this set is DTLS, enabling secure datagram-oriented transport. >>>>>>=20 >>>>>> - New authentication mechanism for TURN >>>>>>=20 >>>>>> Problem analysis: draft-reddy-behave-turn-auth >>>>>> Candidate draft: draft-uberti-behave-turn-rest, OAuth has also been= suggested >>>>>>=20 >>>>>> The current authentication mechanism for TURN, which is reused from= STUN, has >>>>>> been designed with a SIP account database in mind. The new RTCWEB u= sages, >>>>>> which are mostly based on web applications, do not fit that model. = A new >>>>>> authentication mechanism optimized for such web applications will b= e created. >>>>>>=20 >>>>>> - TURN server auto-discovery mechanism for enterprise and ISPs >>>>>>=20 >>>>>> Candidate draft: TBD >>>>>>=20 >>>>>> Current TURN server discovery is based on the presence of SRV and/o= r NAPTR DNS >>>>>> records. These records are usually under the administrative control= of the >>>>>> application or service provider, not the enterprise or the ISP on w= hose >>>>>> network the client is situated. Enterprises or ISPs wishing to prov= ide their >>>>>> own TURN server, in an attempt to reduce so-called "triangle routin= g", need a >>>>>> new auto-discovery mechanism. >>>>>>=20 >>>>>> - STUN-bis >>>>>>=20 >>>>>> Candidate draft: TBD >>>>>>=20 >>>>>> A new revision of RFC 5389 will contain: >>>>>>=20 >>>>>> - Various bug fixes >>>>>> - STUN hash algorithm agility (currently only SHA-1 is allowed) >>>>>>=20 >>>>>> - TURN-bis >>>>>>=20 >>>>>> Candidate draft: TBD >>>>>>=20 >>>>>> A new revision of RFC 5766 will contain: >>>>>>=20 >>>>>> - Various bug fixes >>>>>> - Support for multi-tenant servers >>>>>> (Servers always send the same REALM attribute. No realm negotiati= on phase >>>>>> currently exists.) >>>>>>=20 >>>>>> Goals and Milestones: >>>>>>=20 >>>>>> [TBD] >>>>>=20 >>>>> -- >>>>> 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 >>>>=20 >>>> _______________________________________________ >>>> tram mailing list >>>> tram@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tram >>>>=20 >>>=20 >>> _______________________________________________ >>> tram mailing list >>> tram@ietf.org >>> https://www.ietf.org/mailman/listinfo/tram >>=20 >>=20 >=20 From tireddy@cisco.com Tue Nov 19 04:26:45 2013 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 A7C441ADF67 for ; Tue, 19 Nov 2013 04:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.026 X-Spam-Level: X-Spam-Status: No, score=-10.026 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.525, 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 GxvwNeQ2dInK for ; Tue, 19 Nov 2013 04:26:43 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id D5EAE1ADF72 for ; Tue, 19 Nov 2013 04:26:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9646; q=dns/txt; s=iport; t=1384863997; x=1386073597; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+YFUdkfTjddGBh4OmtFum4Rvtz17ImYn8pIOCx8M7yw=; b=OM3ggcFLfgWwwufRgX/0D4Bt6vxsBXbkOxxGwAl7ueS519z5rtGNZ0hC Mu2jeY3YyGBGGqI7+/LcdphcKzzmqhNIU9oBk05RoUsfTLBdrHPrALHc8 l3JSXn6iAP4JkxXmhZNieGxIWJxntM45a1I0pCyPFh73rOVikLv9khElx s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAO9Xi1KtJXHA/2dsb2JhbABZgwc4U78/gR8WdIIlAQEBBAEBASRHCxACAQgOAwMBAQELAgkSByEGCxQJCAIECgQFCIdnAw8NuH8NiTkXjGOBMhN+MQcGBIMWgRIDiQqNHYMaiyaFOIMogWgCHgYc X-IronPort-AV: E=Sophos;i="4.93,729,1378857600"; d="scan'208";a="577703" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-3.cisco.com with ESMTP; 19 Nov 2013 12:26:36 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rAJCQa39007973 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Nov 2013 12:26:36 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Tue, 19 Nov 2013 06:26:35 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko Thread-Topic: [tram] First post Thread-Index: AQHO4nrNOeLu8IlzsEisOVsWZS4tvJon2dyA//+cN3CAA33uAIABi2gQ Date: Tue, 19 Nov 2013 12:26:34 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A24267B37@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A24264EF5@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A24265484@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.68.20.108] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: Tue, 19 Nov 2013 12:26:45 -0000 Hi Oleg, Please see inline [TR] From: tram-bounces@ietf.org [mailto:tram-bounces@ietf.org] On Behalf Of Ole= g 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 =A0=20 On Sun, Nov 17, 2013 at 5:36 AM, Tirumaleswar Reddy (tireddy) 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.=20 =A0 we are working on the details and will have something concrete in couple of= weeks. =A0 Cheers, -Tiru. From: tram-bounces@ietf.org [mailto:tram-bounces@ietf.org] On Behalf Of Ole= g 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 =A0 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 =A0 =A0 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. =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 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 lack of interest. =A0This 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. =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 routing", = 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 https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =A0 From mom040267@gmail.com Tue Nov 19 10:16:00 2013 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 AAF7F1AE04D for ; Tue, 19 Nov 2013 10:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 u7hpdbW7rq_u for ; Tue, 19 Nov 2013 10:15:58 -0800 (PST) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 433E21AE042 for ; Tue, 19 Nov 2013 10:15:55 -0800 (PST) Received: by mail-yh0-f47.google.com with SMTP id 29so1321542yhl.6 for ; Tue, 19 Nov 2013 10:15:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=MVTNRnQ1I15CgkyX90Zs//ebNCJp1lolUCbIDVvGTYs=; b=E+ffZQB7kuuWwae8sus6Ke58vfLT2uEutt1HU6M7JpFsF/NLzMZ058ECVNS2w8MKtc XJKqlQBsQ4W5bvAtSHpn0dc8NjFQugevXErIlVmvqMJ0s2n/41ewzmzxoH+FRh54hYDJ GMTSPAdDXfiljZcVkxwHyprSc+T3mO6pTRro00qBs0idHQUJRX5/c5DnKYxzXcIcN3pN ctHf+5bcMYO06Q/9kbrA7wypuIZsqZRC7PRxbP8B4wFSXHxYt5ZsS6ip0V2QjLeryp/7 ymVsVzV+/+F2LoYFmD2Y/4xmg7sDlJolGsgfcUpMvfPLwIwjdPKECPpIuws9tSsgr0uu CTjA== X-Received: by 10.236.132.162 with SMTP id o22mr60662yhi.126.1384884948898; Tue, 19 Nov 2013 10:15:48 -0800 (PST) Received: from ?IPv6:2600:1010:b017:2454:2daa:e9f4:7417:6ce0? ([2600:1010:b017:2454:2daa:e9f4:7417:6ce0]) by mx.google.com with ESMTPSA id v45sm37061213yha.2.2013.11.19.10.15.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 10:15:47 -0800 (PST) References: <913383AAA69FF945B8F946018B75898A24264EF5@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A24265484@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A24267B37@xmb-rcd-x10.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <913383AAA69FF945B8F946018B75898A24267B37@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2A355926-A2D2-4994-9A92-FBA5D7BC3645@gmail.com> X-Mailer: iPhone Mail (10B350) From: Oleg Moskalenko Date: Tue, 19 Nov 2013 10:15:47 -0800 To: "Tirumaleswar Reddy (tireddy)" 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: Tue, 19 Nov 2013 18:16:00 -0000 That's great. I ll provide a sort of proof-of-concept reference impl soon. Thanks Oleg Sent from my iPhone On Nov 19, 2013, at 4:26 AM, "Tirumaleswar Reddy (tireddy)" wrote: > Hi Oleg, >=20 > Please see inline [TR] >=20 > From: tram-bounces@ietf.org [mailto:tram-bounces@ietf.org] On Behalf Of Ol= eg 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 >=20 > Dan and Tiru, > while contemplating the MICE implementation, I stumbled upon a potential p= roblem 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 enhan= ced security feature). In a non-mobility TURN implementation, that creates n= o problem: the server simple sends 438 error (stale nonce) back to the clien= t together with the new generated NONCE value, and the client just re-calcul= ates 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 when= the session NONCE expires with mobility feature. > I think that the problem can be fixed if the draft would not include wordi= ng 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 s= uggests how the ticket must be constructed and how it must be encoded. I thi= nk that this is unnecessary. Let's just say that the ticket is opaque and it= s 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 t= he 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 the= ticket may be just a random unique key in that table. As we are using messa= ge integrity authentication anyway, and the ticket is transferred openly ove= r 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" s= ession. >=20 > [TR] Agreed with your assessment will update the draft accordingly. >=20 > Thanks and Regards, > -Tiru. >=20 > 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 informati= on in it - that is just an opaque unique string. For protection, they also a= re validating the MESSAGE INTEGRITY. And they have no problem with the NONCE= expiration because there is no NONCE encoded in the ticket. >=20 > Let me know please what do you think about that. >=20 > Thanks > Oleg > =20 >=20 >=20 >=20 >=20 >=20 > On Sun, Nov 17, 2013 at 5:36 AM, Tirumaleswar Reddy (tireddy) wrote: > Hi Oleg, > =20 > It has some similarities but is a lot different from PCP third party autho= rization. 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 a= uthorization. There are various other differences like PCP server would nee= d to communicate with the Authorization Server to determine the token bound a= uthorization data (like the number of mappings permitted, flow characterist= ics allowed etc) which may not be required with TURN authorization. PCP-con= trolled Firewall will most likely be in the same administrative domain as th= e endpoint but that may not be true with TURN.=20 > =20 > we are working on the details and will have something concrete in couple o= f weeks. > =20 > Cheers, > -Tiru. > From: tram-bounces@ietf.org [mailto:tram-bounces@ietf.org] On Behalf Of Ol= eg Moskalenko > Sent: Saturday, November 16, 2013 12:56 PM > To: Tirumaleswar Reddy (tireddy) > Cc: Simon Perreault; tram@ietf.org; Justin Uberti >=20 > Subject: Re: [tram] First post > =20 > Tiru, I suppose that will be similar to this draft: >=20 > http://tools.ietf.org/html/draft-wing-pcp-third-party-authz-01 > That would be a significant addition to the TURN server. > Regards, > Oleg > =20 > =20 > On Fri, Nov 15, 2013 at 7:20 PM, Tirumaleswar Reddy (tireddy) wrote: > Hi Oleg, >=20 > 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 prob= lems discussed in above draft. >=20 > Cheers, > -Tiru. >=20 > From: Oleg Moskalenko > Subject: Re: [tram] First post > Date: November 15, 2013 11:01:24 AM PST > To: Simon Perreault > Cc: >=20 > 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 b= e interested in the TURN evolution. >=20 > On Fri, Nov 15, 2013 at 10:55 AM, Simon Perreault wrote: > All, >=20 > Any objection against sending the following to rtcweb, pntaw, and behave? A= ny other lists that should be included? >=20 > Simon >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > All, >=20 > A few of us have been working on a proposal for a new working group that w= ould focus on enhancements to STUN and TURN. The proposed name is TRAM (Turn= Revised And Modernized) and discussion is happening in . > Subscribe link: >=20 > 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. >=20 > Simon (and many others!) > Turn Revised And Modernized (tram) > ---------------------------------- >=20 > Traversal Using Relays around NAT (TURN) was published as RFC 5766 in Apri= l > 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 it= self > was slow to achieve widespread adoption because other alternative mechanis= ms > 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. >=20 > 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 evidenc= ed by > the recent work updating the ICE framework, as well as standardizing the U= RIs > used to access a STUN [RFC7064] or TURN [RFC7065] server. >=20 > The goal of the TRAM Working Group is to consolidate the various initiativ= es > to update TURN and STUN, including the definition of new transport and > authentication mechanisms that make STUN and TURN more suitable for the We= bRTC > environment. The Working Group will closely coordinate with the appropria= te > Working Groups, including RTCWEB, MMUSIC, and HTTPBIS. >=20 > The current list of deliverable is: >=20 > - DTLS transport for TURN >=20 > Candidate draft: draft-petithuguenin-tram-turn-dtls >=20 > TURN defines three transports: UDP, TCP, and TLS. A straightforward exte= nsion > of this set is DTLS, enabling secure datagram-oriented transport. >=20 > - New authentication mechanism for TURN >=20 > Problem analysis: draft-reddy-behave-turn-auth > Candidate draft: draft-uberti-behave-turn-rest, OAuth has also been sugg= ested >=20 > 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 cre= ated. >=20 > - TURN server auto-discovery mechanism for enterprise and ISPs >=20 > Candidate draft: TBD >=20 > Current TURN server discovery is based on the presence of SRV and/or NAP= TR DNS > records. These records are usually under the administrative control of t= he > application or service provider, not the enterprise or the ISP on whose > network the client is situated. Enterprises or ISPs wishing to provide t= heir > own TURN server, in an attempt to reduce so-called "triangle routing", n= eed a > new auto-discovery mechanism. >=20 > - STUN-bis >=20 > Candidate draft: TBD >=20 > A new revision of RFC 5389 will contain: >=20 > - Various bug fixes > - STUN hash algorithm agility (currently only SHA-1 is allowed) >=20 > - TURN-bis >=20 > Candidate draft: TBD >=20 > A new revision of RFC 5766 will contain: >=20 > - Various bug fixes > - Support for multi-tenant servers > (Servers always send the same REALM attribute. No realm negotiation ph= ase > currently exists.) >=20 > Goals and Milestones: >=20 > [TBD] >=20 > -- > 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 >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > =20 >=20 From andrew.hutton@unify.com Tue Nov 19 20:55:30 2013 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 AAC451AE2F9 for ; Tue, 19 Nov 2013 20:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] 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 X9XxuLxruiGD for ; Tue, 19 Nov 2013 20:55:21 -0800 (PST) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 480601AE171 for ; Tue, 19 Nov 2013 20:55:21 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id 578061EB865B; Wed, 20 Nov 2013 05:55:14 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.69]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Wed, 20 Nov 2013 05:55:13 +0100 From: "Hutton, Andrew" To: "Gonzalo Salgueiro (gsalguei)" , Paul Kyzivat Thread-Topic: TURN/RTP via HTTP Proxy (was: First post) Thread-Index: AQHO5ayyAAtV+iJtoES8KsvUZ3wxeg== Date: Wed, 20 Nov 2013 04:55:13 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17C4C173@MCHP04MSX.global-ad.net> References: <52866E37.1030800@viagenie.ca> <528679A1.2060104@alum.mit.edu> <528A2B3C.4090307@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tram@ietf.org" Subject: [tram] TURN/RTP via HTTP Proxy (was: 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: Wed, 20 Nov 2013 04:55:30 -0000 Changing the subject line. Gonzalo, I was confused by your responses below. On one hand you seem to be indicated that a discussion on TURNoWs, and pres= umable the other alternatives for handling TURN/RTP in the presence of HTTP= Proxies, should not take place on this list and on the other you seem to i= ndicate that the discussion could take place but has to wait until the WG h= as been chartered. I cannot see any reason for delaying a discussion that we need to have to s= ome future date so since it seem to have been decided to not have that disc= ussion on this list then let's use the PNTAW list which was created for tha= t purpose.=20 Regards Andy > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Gonzalo > Salgueiro (gsalguei) > Sent: 18 November 2013 16:28 > To: Paul Kyzivat > Cc: tram@ietf.org > Subject: Re: [tram] First post > Importance: High >=20 >=20 > On Nov 18, 2013, at 6:59 AM, Paul Kyzivat > wrote: >=20 > > On 11/15/13 1:43 PM, Gonzalo Salgueiro (gsalguei) wrote: > >> Hi Paul - > >> > >> On Nov 15, 2013, at 2:44 PM, Paul Kyzivat > wrote: > >> > >>> Gonzalo, > >>> > >>> On 11/15/13 11:20 AM, Gonzalo Salgueiro (gsalguei) wrote: > >>>> No objection. > >>>> > >>>> My main concern is that we have some element of agility with this > work. The discussion over the past few days seem to indicate that we > have a bunch of work that is not at all contentious and viewed as > valuable by all. This work would likely get us a (BOF-less) WG stood up > quickly and we have work in progress to address many of those > milestones already. I just want to ensure we get all this work rolling > along, rather than making WG formation dependent on issues known to be > more contentious, requiring far more discussion and having many more > dependencies on many different groups (i.e., HTTP traversal). To be > clear, I'm not saying lets not discuss these thing. I absolutely think > they are important problems that need solving, but I think those > discussions can happen in parallel and it would be highly inefficient > to hold up all this other work on account of those interminable > discussions. > >>> > >>> I understand your concern. And it seems the controversial element > has been removed from the charter/milestones. > >> > >> First, let me admit that I didn't look to see if it was taken off > the latest version of the charter proposal :-( > >> I (blindly) assumed that it was still on there based on the fact > that I didn't think we had reached consensus. I'm happy to see it > settled as it is now. > >> > >>> Are you suggesting that the TURN over websockets discussion happen > on the TRAM list, but without a milestone? Or are you suggesting that > the discussion needs to happen somewhere else? > >> > >> I view the TRAM list strictly as a pre-WG list. For the sake of > efficiency, IMO we should aim to try and limit discussions to > progressing the formation of said WG. The technical discussions around > TURNoWS are clearly lightning rods, so I think it is distracting to > have them on the TRAM list. That said, I think it is fine to have > discussions on the TRAM list related to finding a home for those > technical discussions of TURNoWS to take place. > > > > I have repeatedly asked *where* we could have that discussion in a > way that satisfies those who are concerned. If we can't have it on > TRAM, then were else? >=20 > I feel your pain and agree we need to figure out where. I simply think > that discussion would entirely consume and eventually fracture this > group and would consequently delay formation of a WG to do all this > this other work. I'm trying to be practical here and ensure *something* > gets done in a timely fashion. > > > > Or are you suggesting that we should not have that discussion at all > right now? (Rather wait for a WG to be chartered, and *then* have the > discussion.) >=20 > Yeah, this is where I'm going. >=20 > Gonzalo >=20 > > > > Thanks, > > Paul > > > >> Cheers, > >> > >> Gonzalo > >> > >>> Thanks, > >>> Paul > >>> > >>>> Gonzalo > >>>> > >>>> On Nov 15, 2013, at 1:55 PM, Simon Perreault > wrote: > >>>> > >>>>> All, > >>>>> > >>>>> Any objection against sending the following to rtcweb, pntaw, and > behave? Any 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 would 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 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 > >>>> > >>> > >>> _______________________________________________ > >>> tram mailing list > >>> tram@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tram > >> > >> > > >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From gsalguei@cisco.com Wed Nov 20 00:05:46 2013 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 BB7841AE38A for ; Wed, 20 Nov 2013 00:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.026 X-Spam-Level: X-Spam-Status: No, score=-15.026 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.525, 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 wFYhyCAkaoO5 for ; Wed, 20 Nov 2013 00:05:44 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id BF90A1AE37F for ; Wed, 20 Nov 2013 00:05:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11343; q=dns/txt; s=iport; t=1384934738; x=1386144338; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TAGWCLNVklAz1I9Ck4IPyTa2cmokcHYE1lQ9RmS4dI4=; b=F3sDAlYEGGS9lSwxnswYrhzYamPfhPbLQoG/JuQAVcGS9pzdWlSrZE9o ZPRyg6s0mdu0bco454ZzzXM0EXeRnt4uWpPNWmJim1/ZNRGLA6FPUo/Ip OUwyxcl0Om/+sLSky2zBBBGi+mhJ5tKUvISxpni88TxUcB5Sz8NTAxg2G 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAAlsjFKtJV2d/2dsb2JhbABZgwc4U750gRAWdIIlAQEBAwEBAQEkAhE0CwUHBAIBAgYRBAEBAQwJCQkHJwsUCQgCBA4Fh3sGDcAPF44VAYEOMwcGBIMWgRIDjFmLOYEvhguKU4MogWgBHwQe X-IronPort-AV: E=Sophos;i="4.93,735,1378857600"; d="scan'208";a="286268322" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 20 Nov 2013 08:05:37 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rAK85aLm027570 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Nov 2013 08:05:36 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.192]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Wed, 20 Nov 2013 02:05:36 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: "Hutton, Andrew" Thread-Topic: TURN/RTP via HTTP Proxy (was: First post) Thread-Index: AQHO5ay3NxT8bSvwx0unr+nL143L95ouJ9CA Importance: high X-Priority: 1 Date: Wed, 20 Nov 2013 08:05:36 +0000 Message-ID: <6E421502-1BB7-45FF-B836-AB3D8BA08968@cisco.com> References: <52866E37.1030800@viagenie.ca> <528679A1.2060104@alum.mit.edu> <528A2B3C.4090307@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF17C4C173@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17C4C173@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.146.126] Content-Type: text/plain; charset="us-ascii" Content-ID: <6B2559B430310340BED904A89B3EAB77@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tram@ietf.org" , Paul Kyzivat Subject: Re: [tram] TURN/RTP via HTTP Proxy (was: 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: Wed, 20 Nov 2013 08:05:46 -0000 Andy -=20 On Nov 19, 2013, at 8:55 PM, Hutton, Andrew wrote= : > Changing the subject line. >=20 > Gonzalo, I was confused by your responses below. >=20 > On one hand you seem to be indicated that a discussion on TURNoWs, and pr= esumable the other alternatives for handling TURN/RTP in the presence of HT= TP Proxies, should not take place on this list and on the other you seem to= indicate that the discussion could take place but has to wait until the WG= has been chartered. >=20 > I cannot see any reason for delaying a discussion that we need to have to= some future date so since it seem to have been decided to not have that di= scussion on this list then let's use the PNTAW list which was created for t= hat purpose.=20 We have clearly established that this discussion is controversial and there= have been explicit statements indicating that if this work is bundled with= the other (less contentious) work for this proposed WG, then formation of = said WG would be blocked. Thus, I think it is counterproductive to have th= ose discussions and hold up all this other work. I think we have the oppor= tunity to quickly set up a WG (perhaps even without a BoF) if we limit the = scope to the other proposed work items. I think the TURNoWS discussion MUST= take place, but not at the expense of this other work. I'm simply proposi= ng we focus the discussions on tram@ to getting this WG formed with these o= ther milestones and that it would be most efficient to temporarily limit th= e scope (on tram@) to finding the right place to have these much needed dis= cussions. Just my opinion... Gonzalo >=20 > Regards > Andy >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Gonzalo >> Salgueiro (gsalguei) >> Sent: 18 November 2013 16:28 >> To: Paul Kyzivat >> Cc: tram@ietf.org >> Subject: Re: [tram] First post >> Importance: High >>=20 >>=20 >> On Nov 18, 2013, at 6:59 AM, Paul Kyzivat >> wrote: >>=20 >>> On 11/15/13 1:43 PM, Gonzalo Salgueiro (gsalguei) wrote: >>>> Hi Paul - >>>>=20 >>>> On Nov 15, 2013, at 2:44 PM, Paul Kyzivat >> wrote: >>>>=20 >>>>> Gonzalo, >>>>>=20 >>>>> On 11/15/13 11:20 AM, Gonzalo Salgueiro (gsalguei) wrote: >>>>>> No objection. >>>>>>=20 >>>>>> My main concern is that we have some element of agility with this >> work. The discussion over the past few days seem to indicate that we >> have a bunch of work that is not at all contentious and viewed as >> valuable by all. This work would likely get us a (BOF-less) WG stood up >> quickly and we have work in progress to address many of those >> milestones already. I just want to ensure we get all this work rolling >> along, rather than making WG formation dependent on issues known to be >> more contentious, requiring far more discussion and having many more >> dependencies on many different groups (i.e., HTTP traversal). To be >> clear, I'm not saying lets not discuss these thing. I absolutely think >> they are important problems that need solving, but I think those >> discussions can happen in parallel and it would be highly inefficient >> to hold up all this other work on account of those interminable >> discussions. >>>>>=20 >>>>> I understand your concern. And it seems the controversial element >> has been removed from the charter/milestones. >>>>=20 >>>> First, let me admit that I didn't look to see if it was taken off >> the latest version of the charter proposal :-( >>>> I (blindly) assumed that it was still on there based on the fact >> that I didn't think we had reached consensus. I'm happy to see it >> settled as it is now. >>>>=20 >>>>> Are you suggesting that the TURN over websockets discussion happen >> on the TRAM list, but without a milestone? Or are you suggesting that >> the discussion needs to happen somewhere else? >>>>=20 >>>> I view the TRAM list strictly as a pre-WG list. For the sake of >> efficiency, IMO we should aim to try and limit discussions to >> progressing the formation of said WG. The technical discussions around >> TURNoWS are clearly lightning rods, so I think it is distracting to >> have them on the TRAM list. That said, I think it is fine to have >> discussions on the TRAM list related to finding a home for those >> technical discussions of TURNoWS to take place. >>>=20 >>> I have repeatedly asked *where* we could have that discussion in a >> way that satisfies those who are concerned. If we can't have it on >> TRAM, then were else? >>=20 >> I feel your pain and agree we need to figure out where. I simply think >> that discussion would entirely consume and eventually fracture this >> group and would consequently delay formation of a WG to do all this >> this other work. I'm trying to be practical here and ensure *something* >> gets done in a timely fashion. >>>=20 >>> Or are you suggesting that we should not have that discussion at all >> right now? (Rather wait for a WG to be chartered, and *then* have the >> discussion.) >>=20 >> Yeah, this is where I'm going. >>=20 >> Gonzalo >>=20 >>>=20 >>> Thanks, >>> Paul >>>=20 >>>> Cheers, >>>>=20 >>>> Gonzalo >>>>=20 >>>>> Thanks, >>>>> Paul >>>>>=20 >>>>>> Gonzalo >>>>>>=20 >>>>>> On Nov 15, 2013, at 1:55 PM, Simon Perreault >> wrote: >>>>>>=20 >>>>>>> All, >>>>>>>=20 >>>>>>> Any objection against sending the following to rtcweb, pntaw, and >> behave? Any other lists that should be included? >>>>>>>=20 >>>>>>> Simon >>>>>>>=20 >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>>=20 >>>>>>> All, >>>>>>>=20 >>>>>>> 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 . >>>>>>> Subscribe link: >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> Simon (and many others!) >>>>>>>=20 >>>>>>>> Turn Revised And Modernized (tram) >>>>>>>> ---------------------------------- >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=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 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. >>>>>>>>=20 >>>>>>>> The current list of deliverable is: >>>>>>>>=20 >>>>>>>> - DTLS transport for TURN >>>>>>>>=20 >>>>>>>> Candidate draft: draft-petithuguenin-tram-turn-dtls >>>>>>>>=20 >>>>>>>> TURN defines three transports: UDP, TCP, and TLS. A >> straightforward extension >>>>>>>> of this set is DTLS, enabling secure datagram-oriented >> transport. >>>>>>>>=20 >>>>>>>> - New authentication mechanism for TURN >>>>>>>>=20 >>>>>>>> Problem analysis: draft-reddy-behave-turn-auth >>>>>>>> Candidate draft: draft-uberti-behave-turn-rest, OAuth has also >> been suggested >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> - TURN server auto-discovery mechanism for enterprise and ISPs >>>>>>>>=20 >>>>>>>> Candidate draft: TBD >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> - STUN-bis >>>>>>>>=20 >>>>>>>> Candidate draft: TBD >>>>>>>>=20 >>>>>>>> A new revision of RFC 5389 will contain: >>>>>>>>=20 >>>>>>>> - Various bug fixes >>>>>>>> - STUN hash algorithm agility (currently only SHA-1 is allowed) >>>>>>>>=20 >>>>>>>> - TURN-bis >>>>>>>>=20 >>>>>>>> Candidate draft: TBD >>>>>>>>=20 >>>>>>>> A new revision of RFC 5766 will contain: >>>>>>>>=20 >>>>>>>> - Various bug fixes >>>>>>>> - Support for multi-tenant servers >>>>>>>> (Servers always send the same REALM attribute. No realm >> negotiation phase >>>>>>>> currently exists.) >>>>>>>>=20 >>>>>>>> Goals and Milestones: >>>>>>>>=20 >>>>>>>> [TBD] >>>>>>>=20 >>>>>>> -- >>>>>>> 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 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> tram mailing list >>>>>> tram@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/tram >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> tram mailing list >>>>> tram@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tram >>>>=20 >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram From pkyzivat@alum.mit.edu Wed Nov 20 16:36:04 2013 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 897721AE22D for ; Wed, 20 Nov 2013 16:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 6iyp39zRTSH1 for ; Wed, 20 Nov 2013 16:36:01 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 79A9B1AE20F for ; Wed, 20 Nov 2013 16:36:01 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta03.westchester.pa.mail.comcast.net with comcast id roq51m0020xGWP8530buFR; Thu, 21 Nov 2013 00:35:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id s0bu1m00P3ZTu2S3Y0bumx; Thu, 21 Nov 2013 00:35:54 +0000 Message-ID: <528D556A.4040403@alum.mit.edu> Date: Wed, 20 Nov 2013 16:35:54 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: tram@ietf.org References: <52866E37.1030800@viagenie.ca> <528679A1.2060104@alum.mit.edu> <528A2B3C.4090307@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF17C4C173@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17C4C173@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1384994154; bh=ohXf/nWEapWvw8C/z9G4IcMqwE32bL077JVh1bVJ0+M=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=N+G8h3hgtKqZ+hN+ACPWcvNJBynZXcCIpNyD2zL949g0X08+oWlJ0S2Gc8o7kprmP sQU0mSDEdo7k0Dd+j2q5D1rnkW0fqaIktrvGRO9j8Xei9Du923NYxSqjsQS2JygYMn 43B+ScH9Y/e7H/1UzD3m4XPZzLr5wbaDa/ZqGHDtp2I9qMQqrrJYS/HL1tfspUVVeH 134FQhCgfpPOSevfy2ddnPNDxOm1zeA9ETgzp/f4jI/35HGYFrCxVhWc/VjMP5aiqf 41sgWU/cpszhcMgetqEb7w5ZP3joUYaabp/WXLtoBIcEGwwZHttVDB96K1Wlp7w9db zhK2TFa6w2bEw== Subject: Re: [tram] TURN/RTP via HTTP Proxy 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, 21 Nov 2013 00:36:04 -0000 On 11/19/13 8:55 PM, Hutton, Andrew wrote: > Changing the subject line. > > Gonzalo, I was confused by your responses below. > > On one hand you seem to be indicated that a discussion on TURNoWs, and presumable the other alternatives for handling TURN/RTP in the presence of HTTP Proxies, should not take place on this list and on the other you seem to indicate that the discussion could take place but has to wait until the WG has been chartered. > > I cannot see any reason for delaying a discussion that we need to have to some future date so since it seem to have been decided to not have that discussion on this list then let's use the PNTAW list which was created for that purpose. There seems to be some threat or fear of violating political correctness or "that which shall not be spoken" going on here. (Or maybe I am being paranoid and it is really just a concern about rat-hole'ing.) I am just looking for some guidance on what forum to use for that discussion. I'm happy to have it on the the TRAM list, or the PNTAW list, or some other list. But when we have it, I don't want to later be told to start again because we chose the wrong list. I'd rather *not* have it on the RTCWEB list. Thanks, Paul > Regards > Andy > > > > >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Gonzalo >> Salgueiro (gsalguei) >> Sent: 18 November 2013 16:28 >> To: Paul Kyzivat >> Cc: tram@ietf.org >> Subject: Re: [tram] First post >> Importance: High >> >> >> On Nov 18, 2013, at 6:59 AM, Paul Kyzivat >> wrote: >> >>> On 11/15/13 1:43 PM, Gonzalo Salgueiro (gsalguei) wrote: >>>> Hi Paul - >>>> >>>> On Nov 15, 2013, at 2:44 PM, Paul Kyzivat >> wrote: >>>> >>>>> Gonzalo, >>>>> >>>>> On 11/15/13 11:20 AM, Gonzalo Salgueiro (gsalguei) wrote: >>>>>> No objection. >>>>>> >>>>>> My main concern is that we have some element of agility with this >> work. The discussion over the past few days seem to indicate that we >> have a bunch of work that is not at all contentious and viewed as >> valuable by all. This work would likely get us a (BOF-less) WG stood up >> quickly and we have work in progress to address many of those >> milestones already. I just want to ensure we get all this work rolling >> along, rather than making WG formation dependent on issues known to be >> more contentious, requiring far more discussion and having many more >> dependencies on many different groups (i.e., HTTP traversal). To be >> clear, I'm not saying lets not discuss these thing. I absolutely think >> they are important problems that need solving, but I think those >> discussions can happen in parallel and it would be highly inefficient >> to hold up all this other work on account of those interminable >> discussions. >>>>> >>>>> I understand your concern. And it seems the controversial element >> has been removed from the charter/milestones. >>>> >>>> First, let me admit that I didn't look to see if it was taken off >> the latest version of the charter proposal :-( >>>> I (blindly) assumed that it was still on there based on the fact >> that I didn't think we had reached consensus. I'm happy to see it >> settled as it is now. >>>> >>>>> Are you suggesting that the TURN over websockets discussion happen >> on the TRAM list, but without a milestone? Or are you suggesting that >> the discussion needs to happen somewhere else? >>>> >>>> I view the TRAM list strictly as a pre-WG list. For the sake of >> efficiency, IMO we should aim to try and limit discussions to >> progressing the formation of said WG. The technical discussions around >> TURNoWS are clearly lightning rods, so I think it is distracting to >> have them on the TRAM list. That said, I think it is fine to have >> discussions on the TRAM list related to finding a home for those >> technical discussions of TURNoWS to take place. >>> >>> I have repeatedly asked *where* we could have that discussion in a >> way that satisfies those who are concerned. If we can't have it on >> TRAM, then were else? >> >> I feel your pain and agree we need to figure out where. I simply think >> that discussion would entirely consume and eventually fracture this >> group and would consequently delay formation of a WG to do all this >> this other work. I'm trying to be practical here and ensure *something* >> gets done in a timely fashion. >>> >>> Or are you suggesting that we should not have that discussion at all >> right now? (Rather wait for a WG to be chartered, and *then* have the >> discussion.) >> >> Yeah, this is where I'm going. >> >> Gonzalo >> >>> >>> Thanks, >>> Paul >>> >>>> Cheers, >>>> >>>> Gonzalo >>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> Gonzalo >>>>>> >>>>>> On Nov 15, 2013, at 1:55 PM, Simon Perreault >> 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 . >>>>>>> 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 >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > From gsalguei@cisco.com Wed Nov 20 17:06:33 2013 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 3DFE61AC403 for ; Wed, 20 Nov 2013 17:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.026 X-Spam-Level: X-Spam-Status: No, score=-10.026 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.525, 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 fSye9VaCks58 for ; Wed, 20 Nov 2013 17:06:30 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 591BC1AC7F1 for ; Wed, 20 Nov 2013 17:06:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11987; q=dns/txt; s=iport; t=1384995984; x=1386205584; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6wTLdvagWR0Yv6xSlNpMLf9++HKGqqE+m4bEpOCaG54=; b=QDu4y35HV4G+1FgG7W1TjpKKOrdVYdJZGIbCfJ57k/XZQys0lL6CHIuH BPpy4EUUQZBtYRIdVflsq6oNgCmNwojHNd4dKNibX1qDWQjDHi+rFqorH sHniRIQEtICRaprsJ36yzW0p1keu95QhJDSPngyRn2UPesp/rr1MhAMtl Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAB9bjVKtJV2c/2dsb2JhbABZDoJ5OFO9ZYEeFnSCJQEBAQMBAQEBJBM0CwUHBAIBCA4DBAEBAQwJCQkHJwsUCQgCBA4Fh3sGDcBYF44pAYEOMwcGBIMWgRIDjFmLOYEvhguKU4JpP4FoAR8i X-IronPort-AV: E=Sophos;i="4.93,740,1378857600"; d="scan'208";a="1084908" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP; 21 Nov 2013 01:06:20 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rAL16Knu004878 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Nov 2013 01:06:20 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.192]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Wed, 20 Nov 2013 19:06:20 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Paul Kyzivat Thread-Topic: [tram] TURN/RTP via HTTP Proxy Thread-Index: AQHO5lGoiA5zqV6efEqquVPbB39ES5ovQ6iA Date: Thu, 21 Nov 2013 01:06:19 +0000 Message-ID: References: <52866E37.1030800@viagenie.ca> <528679A1.2060104@alum.mit.edu> <528A2B3C.4090307@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF17C4C173@MCHP04MSX.global-ad.net> <528D556A.4040403@alum.mit.edu> In-Reply-To: <528D556A.4040403@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.66.17] Content-Type: text/plain; charset="us-ascii" Content-ID: <7E9F135EB1B23D41BDBD8B8DBA73819D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tram@ietf.org" Subject: Re: [tram] TURN/RTP via HTTP Proxy 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, 21 Nov 2013 01:06:33 -0000 On Nov 20, 2013, at 4:35 PM, Paul Kyzivat wrote: > On 11/19/13 8:55 PM, Hutton, Andrew wrote: >> Changing the subject line. >>=20 >> Gonzalo, I was confused by your responses below. >>=20 >> On one hand you seem to be indicated that a discussion on TURNoWs, and p= resumable the other alternatives for handling TURN/RTP in the presence of H= TTP Proxies, should not take place on this list and on the other you seem t= o indicate that the discussion could take place but has to wait until the W= G has been chartered. >>=20 >> I cannot see any reason for delaying a discussion that we need to have t= o some future date so since it seem to have been decided to not have that d= iscussion on this list then let's use the PNTAW list which was created for = that purpose. >=20 > There seems to be some threat or fear of violating political correctness = or "that which shall not be spoken" going on here. (Or maybe I am being par= anoid and it is really just a concern about rat-hole'ing.) I'm gonna go with paranoid as I can assure you I have little care for polit= ical correctness. I'm simply trying to advance the work with some measure = of efficiency and avoid (for once) these toxic IETF delays. All the while = belaboring this point nine times further proves my point. >=20 > I am just looking for some guidance on what forum to use for that discuss= ion. I'm happy to have it on the the TRAM list, or the PNTAW list, or some = other list. But when we have it, I don't want to later be told to start aga= in because we chose the wrong list. I'd rather *not* have it on the RTCWEB = list. I hear ya....I said let's discuss where it should happen. Gonzalo >=20 > Thanks, > Paul >=20 >> Regards >> Andy >>=20 >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Gonzalo >>> Salgueiro (gsalguei) >>> Sent: 18 November 2013 16:28 >>> To: Paul Kyzivat >>> Cc: tram@ietf.org >>> Subject: Re: [tram] First post >>> Importance: High >>>=20 >>>=20 >>> On Nov 18, 2013, at 6:59 AM, Paul Kyzivat >>> wrote: >>>=20 >>>> On 11/15/13 1:43 PM, Gonzalo Salgueiro (gsalguei) wrote: >>>>> Hi Paul - >>>>>=20 >>>>> On Nov 15, 2013, at 2:44 PM, Paul Kyzivat >>> wrote: >>>>>=20 >>>>>> Gonzalo, >>>>>>=20 >>>>>> On 11/15/13 11:20 AM, Gonzalo Salgueiro (gsalguei) wrote: >>>>>>> No objection. >>>>>>>=20 >>>>>>> My main concern is that we have some element of agility with this >>> work. The discussion over the past few days seem to indicate that we >>> have a bunch of work that is not at all contentious and viewed as >>> valuable by all. This work would likely get us a (BOF-less) WG stood up >>> quickly and we have work in progress to address many of those >>> milestones already. I just want to ensure we get all this work rolling >>> along, rather than making WG formation dependent on issues known to be >>> more contentious, requiring far more discussion and having many more >>> dependencies on many different groups (i.e., HTTP traversal). To be >>> clear, I'm not saying lets not discuss these thing. I absolutely think >>> they are important problems that need solving, but I think those >>> discussions can happen in parallel and it would be highly inefficient >>> to hold up all this other work on account of those interminable >>> discussions. >>>>>>=20 >>>>>> I understand your concern. And it seems the controversial element >>> has been removed from the charter/milestones. >>>>>=20 >>>>> First, let me admit that I didn't look to see if it was taken off >>> the latest version of the charter proposal :-( >>>>> I (blindly) assumed that it was still on there based on the fact >>> that I didn't think we had reached consensus. I'm happy to see it >>> settled as it is now. >>>>>=20 >>>>>> Are you suggesting that the TURN over websockets discussion happen >>> on the TRAM list, but without a milestone? Or are you suggesting that >>> the discussion needs to happen somewhere else? >>>>>=20 >>>>> I view the TRAM list strictly as a pre-WG list. For the sake of >>> efficiency, IMO we should aim to try and limit discussions to >>> progressing the formation of said WG. The technical discussions around >>> TURNoWS are clearly lightning rods, so I think it is distracting to >>> have them on the TRAM list. That said, I think it is fine to have >>> discussions on the TRAM list related to finding a home for those >>> technical discussions of TURNoWS to take place. >>>>=20 >>>> I have repeatedly asked *where* we could have that discussion in a >>> way that satisfies those who are concerned. If we can't have it on >>> TRAM, then were else? >>>=20 >>> I feel your pain and agree we need to figure out where. I simply think >>> that discussion would entirely consume and eventually fracture this >>> group and would consequently delay formation of a WG to do all this >>> this other work. I'm trying to be practical here and ensure *something* >>> gets done in a timely fashion. >>>>=20 >>>> Or are you suggesting that we should not have that discussion at all >>> right now? (Rather wait for a WG to be chartered, and *then* have the >>> discussion.) >>>=20 >>> Yeah, this is where I'm going. >>>=20 >>> Gonzalo >>>=20 >>>>=20 >>>> Thanks, >>>> Paul >>>>=20 >>>>> Cheers, >>>>>=20 >>>>> Gonzalo >>>>>=20 >>>>>> Thanks, >>>>>> Paul >>>>>>=20 >>>>>>> Gonzalo >>>>>>>=20 >>>>>>> On Nov 15, 2013, at 1:55 PM, Simon Perreault >>> wrote: >>>>>>>=20 >>>>>>>> All, >>>>>>>>=20 >>>>>>>> Any objection against sending the following to rtcweb, pntaw, and >>> behave? Any other lists that should be included? >>>>>>>>=20 >>>>>>>> Simon >>>>>>>>=20 >>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>>>=20 >>>>>>>> All, >>>>>>>>=20 >>>>>>>> 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 . >>>>>>>> Subscribe link: >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> Simon (and many others!) >>>>>>>>=20 >>>>>>>>> Turn Revised And Modernized (tram) >>>>>>>>> ---------------------------------- >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=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 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. >>>>>>>>>=20 >>>>>>>>> The current list of deliverable is: >>>>>>>>>=20 >>>>>>>>> - DTLS transport for TURN >>>>>>>>>=20 >>>>>>>>> Candidate draft: draft-petithuguenin-tram-turn-dtls >>>>>>>>>=20 >>>>>>>>> TURN defines three transports: UDP, TCP, and TLS. A >>> straightforward extension >>>>>>>>> of this set is DTLS, enabling secure datagram-oriented >>> transport. >>>>>>>>>=20 >>>>>>>>> - New authentication mechanism for TURN >>>>>>>>>=20 >>>>>>>>> Problem analysis: draft-reddy-behave-turn-auth >>>>>>>>> Candidate draft: draft-uberti-behave-turn-rest, OAuth has also >>> been suggested >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>> - TURN server auto-discovery mechanism for enterprise and ISPs >>>>>>>>>=20 >>>>>>>>> Candidate draft: TBD >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>> - STUN-bis >>>>>>>>>=20 >>>>>>>>> Candidate draft: TBD >>>>>>>>>=20 >>>>>>>>> A new revision of RFC 5389 will contain: >>>>>>>>>=20 >>>>>>>>> - Various bug fixes >>>>>>>>> - STUN hash algorithm agility (currently only SHA-1 is allowed) >>>>>>>>>=20 >>>>>>>>> - TURN-bis >>>>>>>>>=20 >>>>>>>>> Candidate draft: TBD >>>>>>>>>=20 >>>>>>>>> A new revision of RFC 5766 will contain: >>>>>>>>>=20 >>>>>>>>> - Various bug fixes >>>>>>>>> - Support for multi-tenant servers >>>>>>>>> (Servers always send the same REALM attribute. No realm >>> negotiation phase >>>>>>>>> currently exists.) >>>>>>>>>=20 >>>>>>>>> Goals and Milestones: >>>>>>>>>=20 >>>>>>>>> [TBD] >>>>>>>>=20 >>>>>>>> -- >>>>>>>> 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 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> tram mailing list >>>>>>> tram@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/tram >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> tram mailing list >>>>>> tram@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/tram >>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> 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 >>=20 >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From pkyzivat@alum.mit.edu Wed Nov 20 21:10:57 2013 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 EECD21AE0A6 for ; Wed, 20 Nov 2013 21:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Y3rqiHc3UArR for ; Wed, 20 Nov 2013 21:10:54 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE231AE099 for ; Wed, 20 Nov 2013 21:10:53 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta01.westchester.pa.mail.comcast.net with comcast id s59J1m0031YDfWL515AlWN; Thu, 21 Nov 2013 05:10:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id s5Al1m00G3ZTu2S3g5Al1e; Thu, 21 Nov 2013 05:10:45 +0000 Message-ID: <528D95D5.7000403@alum.mit.edu> Date: Wed, 20 Nov 2013 21:10:45 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Gonzalo Salgueiro (gsalguei)" References: <52866E37.1030800@viagenie.ca> <528679A1.2060104@alum.mit.edu> <528A2B3C.4090307@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF17C4C173@MCHP04MSX.global-ad.net> <528D556A.4040403@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1385010645; bh=ekryvn1iVNN/4dprky5v4Xf2kur1PNq4ognjmoaa0VI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=l8ZoxD8UoPrYzBUW5FCkqLzJURM56HaPpm40aK43kUcOyinUbwB6Ti6rcnkQI5oLD /w9LeB1Otw/eEIOccTxwDkWX+S1ubM/JrI4IcKG54t2L42i9nvzQE+yK2JKtkB93as AkqHT0K4KGCuAi4dhdm/14DaRP/5Os0/BxPA8LdRzsHFWW1Of63U06G11qTVPgHtcd 3UugWJvl/dW0lsYH8p42rFOZuTc8V3S50R2NhwyYL5g8oNSnWpu5ulVujr0g9gJ2cU RJ1A/e0gDQ40qlja/3/jK7LpuzIPS9vQusZSBVhAaHWokT64iHQz3HEseRzM0VnZra 1B9B5XPMtI33A== Cc: "tram@ietf.org" Subject: Re: [tram] TURN/RTP via HTTP Proxy 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, 21 Nov 2013 05:10:57 -0000 On 11/20/13 5:06 PM, Gonzalo Salgueiro (gsalguei) wrote: > > On Nov 20, 2013, at 4:35 PM, Paul Kyzivat wrote: > >> On 11/19/13 8:55 PM, Hutton, Andrew wrote: >>> Changing the subject line. >>> >>> Gonzalo, I was confused by your responses below. >>> >>> On one hand you seem to be indicated that a discussion on TURNoWs, and presumable the other alternatives for handling TURN/RTP in the presence of HTTP Proxies, should not take place on this list and on the other you seem to indicate that the discussion could take place but has to wait until the WG has been chartered. >>> >>> I cannot see any reason for delaying a discussion that we need to have to some future date so since it seem to have been decided to not have that discussion on this list then let's use the PNTAW list which was created for that purpose. >> >> There seems to be some threat or fear of violating political correctness or "that which shall not be spoken" going on here. (Or maybe I am being paranoid and it is really just a concern about rat-hole'ing.) > > I'm gonna go with paranoid as I can assure you I have little care for political correctness. I'm simply trying to advance the work with some measure of efficiency and avoid (for once) these toxic IETF delays. All the while belaboring this point nine times further proves my point. I didn't really have you in mind. It's what you are reacting to. >> I am just looking for some guidance on what forum to use for that discussion. I'm happy to have it on the the TRAM list, or the PNTAW list, or some other list. But when we have it, I don't want to later be told to start again because we chose the wrong list. I'd rather *not* have it on the RTCWEB list. > > I hear ya....I said let's discuss where it should happen. > > Gonzalo > >> >> Thanks, >> Paul >> >>> Regards >>> Andy >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Gonzalo >>>> Salgueiro (gsalguei) >>>> Sent: 18 November 2013 16:28 >>>> To: Paul Kyzivat >>>> Cc: tram@ietf.org >>>> Subject: Re: [tram] First post >>>> Importance: High >>>> >>>> >>>> On Nov 18, 2013, at 6:59 AM, Paul Kyzivat >>>> wrote: >>>> >>>>> On 11/15/13 1:43 PM, Gonzalo Salgueiro (gsalguei) wrote: >>>>>> Hi Paul - >>>>>> >>>>>> On Nov 15, 2013, at 2:44 PM, Paul Kyzivat >>>> wrote: >>>>>> >>>>>>> Gonzalo, >>>>>>> >>>>>>> On 11/15/13 11:20 AM, Gonzalo Salgueiro (gsalguei) wrote: >>>>>>>> No objection. >>>>>>>> >>>>>>>> My main concern is that we have some element of agility with this >>>> work. The discussion over the past few days seem to indicate that we >>>> have a bunch of work that is not at all contentious and viewed as >>>> valuable by all. This work would likely get us a (BOF-less) WG stood up >>>> quickly and we have work in progress to address many of those >>>> milestones already. I just want to ensure we get all this work rolling >>>> along, rather than making WG formation dependent on issues known to be >>>> more contentious, requiring far more discussion and having many more >>>> dependencies on many different groups (i.e., HTTP traversal). To be >>>> clear, I'm not saying lets not discuss these thing. I absolutely think >>>> they are important problems that need solving, but I think those >>>> discussions can happen in parallel and it would be highly inefficient >>>> to hold up all this other work on account of those interminable >>>> discussions. >>>>>>> >>>>>>> I understand your concern. And it seems the controversial element >>>> has been removed from the charter/milestones. >>>>>> >>>>>> First, let me admit that I didn't look to see if it was taken off >>>> the latest version of the charter proposal :-( >>>>>> I (blindly) assumed that it was still on there based on the fact >>>> that I didn't think we had reached consensus. I'm happy to see it >>>> settled as it is now. >>>>>> >>>>>>> Are you suggesting that the TURN over websockets discussion happen >>>> on the TRAM list, but without a milestone? Or are you suggesting that >>>> the discussion needs to happen somewhere else? >>>>>> >>>>>> I view the TRAM list strictly as a pre-WG list. For the sake of >>>> efficiency, IMO we should aim to try and limit discussions to >>>> progressing the formation of said WG. The technical discussions around >>>> TURNoWS are clearly lightning rods, so I think it is distracting to >>>> have them on the TRAM list. That said, I think it is fine to have >>>> discussions on the TRAM list related to finding a home for those >>>> technical discussions of TURNoWS to take place. >>>>> >>>>> I have repeatedly asked *where* we could have that discussion in a >>>> way that satisfies those who are concerned. If we can't have it on >>>> TRAM, then were else? >>>> >>>> I feel your pain and agree we need to figure out where. I simply think >>>> that discussion would entirely consume and eventually fracture this >>>> group and would consequently delay formation of a WG to do all this >>>> this other work. I'm trying to be practical here and ensure *something* >>>> gets done in a timely fashion. >>>>> >>>>> Or are you suggesting that we should not have that discussion at all >>>> right now? (Rather wait for a WG to be chartered, and *then* have the >>>> discussion.) >>>> >>>> Yeah, this is where I'm going. >>>> >>>> Gonzalo >>>> >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> Cheers, >>>>>> >>>>>> Gonzalo >>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>>> Gonzalo >>>>>>>> >>>>>>>> On Nov 15, 2013, at 1:55 PM, Simon Perreault >>>> 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 . >>>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>> _______________________________________________ >>> 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 > > From mom040267@gmail.com Wed Nov 20 23:24:34 2013 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 7E8CA1AE10A for ; Wed, 20 Nov 2013 23:24:34 -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 BGr5fplJFyq7 for ; Wed, 20 Nov 2013 23:24:30 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id AD93D1AE107 for ; Wed, 20 Nov 2013 23:24:30 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id fa1so2260104pad.24 for ; Wed, 20 Nov 2013 23:24:24 -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:cc:content-type; bh=qBNWMd3gV/fJtBCxfOgeLtnNejkBwJ7m6LzPanbktFU=; b=edD+5LjbeoBYVjwnT7I3o37xDNAaHka4JVvyILuf07XNzoQxAynSeVOLYOTn7Vjumu dbjho7Mb76K5MJJLBEhk48ZjcJbqoCHiO5/yRuwnFOi2KEQ6rlnn/gaNjGBtQBQeeMx/ D6X2skIDZ/5s5kXg3jACjmIEbJLjtLMdKm5HxUqTmM+z/l0cBcLbOQf1I92Gu1ODK+d1 6WcLGdRo1BUYQ323HXwn4rGDBU9bPpFu4XGPi9kZbqORhyaobebR4IOcO8QsdymKNz/b jrVA4zd8QCXljb2UiEJwY0oaHmN45YV4Z94o2aRVHlIu7ZhTjstwqRejhwCalxl3EHV9 h4ZA== MIME-Version: 1.0 X-Received: by 10.67.21.226 with SMTP id hn2mr4850875pad.69.1385018664110; Wed, 20 Nov 2013 23:24:24 -0800 (PST) Received: by 10.68.147.131 with HTTP; Wed, 20 Nov 2013 23:24:24 -0800 (PST) Date: Wed, 20 Nov 2013 23:24:24 -0800 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=001a113330207b4dae04ebaac963 Cc: Simon Perreault , "tram@ietf.org" , Justin Uberti Subject: Re: [tram] TURN ICE Mobility Draft 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, 21 Nov 2013 07:24:34 -0000 --001a113330207b4dae04ebaac963 Content-Type: text/plain; charset=ISO-8859-1 Hi Tiru I found one more minor thing. In the section 5.1.2, a variant is absent when MOBILITY-TICKET attribute is included into ALLOCATE request, but it has a non-zero size. I'd suggest either 400 error code, or ignore the ticket size altogether in the ALLOCATE request. And also, the Mobility-Forbidden error code has to be defined, of course. Regards, Oleg On Tue, Nov 19, 2013 at 10:15 AM, Oleg Moskalenko wrote: > That's great. I ll provide a sort of proof-of-concept reference impl soon. > > Thanks > Oleg > > Sent from my iPhone > > On 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 > > > > > --001a113330207b4dae04ebaac963 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Tiru

I found one more minor thing. In the section 5.1.2, a = variant is absent when MOBILITY-TICKET attribute is included into ALLOCATE = request, but it has a non-zero size. I'd suggest either 400 error code,= or ignore the ticket size altogether in the ALLOCATE request.

And also, the Mobility-Forbidden error= code has to be defined, of course.

Regards,
Oleg

On Tue, Nov 19, 2013 at 10:15 AM, Oleg Moskalenko <mom040267@gmail.com> wrote:
That's great. I ll provide a sort of proof-of-concept reference impl so= on.

Thanks
Oleg

Sent from my iPhone

On Nov 19, 2013, at 4:26 AM, "Tirumaleswar Reddy (tireddy)" <<= a href=3D"mailto:tireddy@cisco.com">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 potenti= al 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 prob= lem is, a NONCE may expire. Its possible to have an expiration time for the= NONCE (an enhanced security feature). In a non-mobility TURN implementatio= n, 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 cl= ient 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 sequenc= e when the session NONCE expires with mobility feature.
> I think that the problem can be fixed if the draft would not include w= ording about the MOBILE-TICKET internal structure. In one place it is sayin= g that the ticket is opaque and implementation-dependent; but in other plac= es it suggests how the ticket must be constructed and how it must be encode= d. 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 ser= ver 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 informati= on 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 transferre= d openly over the Internet, the ticket does not create any new level of def= ense. 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 log= ical 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 inf= ormation in it - that is just an opaque unique string. For protection, they= also are validating the MESSAGE INTEGRITY. And they have no problem with t= he 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 a= uthorization. For example for TURN the Authorization Server will be providi= ng session key, MAC algorithm etc which is not required with the PCP third = party authorization. =A0There are various other differences like PCP server= would need to communicate with the Authorization Server to determine the t= oken bound authorization data =A0(like the number of mappings permitted, fl= ow characteristics allowed etc) which may not be required with TURN authori= zation. =A0PCP-controlled Firewall will most likely be in the same administ= rative domain as the endpoint but that may not be true with TURN.
>
> we are working on the details and will have something concrete in coup= le 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-part= y-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 Extens= ion for Third Party Authorization using OAuth which will address some of th= e problems discussed in above draft.
>
> Cheers,
> -Tiru.
>
> From: Oleg Moskalenko <mom04= 0267@gmail.com>
> Subject: Re: [tram] First post
> Date: November 15, 2013 11:01:24 AM PST
> To: Simon Perreault <simon.perreault@viagenie.ca>
> Cc: <tram@ietf.org>
>
> MMUSIC has an interesting draft on TURN mobility (MICE) that I am watc= hing 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 beha= ve? Any 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 th= at 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: <https://www.ietf.org/mailman/listinfo/tram> >
> Here is the charter we have been working on. If you would like to comm= ent 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. =A0Until recently the protocol had only a rather limited deploym= ent. =A0This
> is primarily because its primary use case is as one of the NAT travers= al
> methods of the Interactive Connectivity Establishment (ICE) framework = (RFC
> 5245). =A0This inherent dependency on ICE combined with the fact that = ICE itself
> was slow to achieve widespread adoption because other alternative mech= anisms
> were historically used by the VoIP industry were the causes of the ini= tial
> lack of interest. =A0This situation has changed drastically as ICE, an= d
> consequently TURN, are mandatory to implement in WebRTC, which is a se= t of
> technologies developed at the IETF and W3C aiming to enable Real Time<= br> > Communication on the Web.
>
> Because of the ubiquity of the Web and of the new opportunities create= d by the
> arrival of WebRTC, there is a renewed interest in TURN and ICE, as evi= denced by
> the recent work updating the ICE framework, as well as standardizing t= he URIs
> used to access a STUN [RFC7064] or TURN [RFC7065] server.
>
> The goal of the TRAM Working Group is to consolidate the various initi= atives
> to update TURN and STUN, including the definition of new transport and=
> authentication mechanisms that make STUN and TURN more suitable for th= e WebRTC
> environment. =A0The Working Group will closely coordinate with the app= ropriate
> 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 straightforwar= d extension
> =A0 of this set is DTLS, enabling secure datagram-oriented transport.<= br> >
> - New authentication mechanism for TURN
>
> =A0 Problem analysis: draft-reddy-behave-turn-auth
> =A0 Candidate draft: draft-uberti-behave-turn-rest, OAuth has also bee= n suggested
>
> =A0 The current authentication mechanism for TURN, which is reused fro= m STUN, has
> =A0 been designed with a SIP account database in mind. The new RTCWEB = usages,
> =A0 which are mostly based on web applications, do not fit that model.= A new
> =A0 authentication mechanism optimized for such web applications will = be created.
>
> - 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 NAPTR DNS
> =A0 records. These records are usually under the administrative contro= l 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 pro= vide their
> =A0 own TURN server, in an attempt to reduce so-called "triangle = routing", 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 negoti= ation 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
> https://www.ietf.org/mailman/listinfo/tram
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>
>

--001a113330207b4dae04ebaac963-- From praspati@cisco.com Fri Nov 22 01:17:04 2013 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 E39061A1F7E for ; Fri, 22 Nov 2013 01:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.511 X-Spam-Level: X-Spam-Status: No, score=-13.511 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.525, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514, 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 TQFE0zKbEJSa for ; Fri, 22 Nov 2013 01:17:01 -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 1B73A1A1F5E for ; Fri, 22 Nov 2013 01:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27841; q=dns/txt; s=iport; t=1385111814; x=1386321414; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=tVso47zDlPgtwh6/Xz9XVD8C3uXKQxuW+cEbQGNfJhQ=; b=kyuxXulBuCyiVYxQm2JbE69BZ3/rASW10DEWLPEeza6ApfDhX+XTn111 SUpudqETt4EIUstwJFLT0GRDmvzn25jkbjHLPUpdJpIDxWwSM1+vIEjP+ x+r4cn1LdlMSvcFfhIuM65qljNBsW6vsp/2UtUBxYOQ82wQ5NR6eR8JIu E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8GACsgj1KtJV2a/2dsb2JhbABZgkNEOFOpXIlliEyBHxZ0giUBAQEDAQEBARcNRwsFDQEIDgMDAQEBAQwJCwcoBgsUCQgCBAEJBAWHbwMJBg24bw2ILBeMcoE3EzQNBAcGAwGEKAOWKIFrgTCLKIU4gyiBaAIeBhw X-IronPort-AV: E=Sophos;i="4.93,751,1378857600"; d="scan'208,217";a="286776857" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 22 Nov 2013 09:16:53 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAM9GqL3022694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Nov 2013 09:16:52 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.169]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Fri, 22 Nov 2013 03:16:52 -0600 From: "Prashanth Patil (praspati)" To: Oleg Moskalenko , "Tirumaleswar Reddy (tireddy)" Thread-Topic: [tram] TURN ICE Mobility Draft Thread-Index: AQHO52OUl1Vq4ZVAs0KnK/fzS+kZhg== Date: Fri, 22 Nov 2013 09:16:51 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [173.39.66.11] Content-Type: multipart/alternative; boundary="_000_CEB51C6BE69Fpraspaticiscocom_" MIME-Version: 1.0 Cc: Simon Perreault , "tram@ietf.org" , Justin Uberti Subject: Re: [tram] TURN ICE Mobility Draft 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, 22 Nov 2013 09:17:05 -0000 --_000_CEB51C6BE69Fpraspaticiscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Oleg, Yes, the server should return a 400 Bad Request error. We'll update the dra= ft accordingly. Thanks, Prashanth From: Oleg Moskalenko > Date: Thursday, November 21, 2013 12:54 PM To: "Tirumaleswar Reddy (tireddy)" > Cc: Simon Perreault >, "tram@ietf.org" >, Justin Uberti > Subject: Re: [tram] TURN ICE Mobility Draft Hi Tiru I found one more minor thing. In the section 5.1.2, a variant is absent whe= n MOBILITY-TICKET attribute is included into ALLOCATE request, but it has a= non-zero size. I'd suggest either 400 error code, or ignore the ticket siz= e altogether in the ALLOCATE request. And also, the Mobility-Forbidden error code has to be defined, of course. Regards, Oleg On Tue, Nov 19, 2013 at 10:15 AM, Oleg Moskalenko > wrote: That's great. I ll provide a sort of proof-of-concept reference impl soon. Thanks Oleg Sent from my iPhone On Nov 19, 2013, at 4:26 AM, "Tirumaleswar Reddy (tireddy)" > wrote: > Hi Oleg, > > Please see inline [TR] > > From: tram-bounces@ietf.org [mailto:tram-bo= unces@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 wit= h the stored NONCE for the "old" 5-tuple session. But the problem is, a NON= CE may expire. Its possible to have an expiration time for the NONCE (an en= hanced security feature). In a non-mobility TURN implementation, that creat= es 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 w= hen the session NONCE expires with mobility feature. > I think that the problem can be fixed if the draft would not include word= ing about the MOBILE-TICKET internal structure. In one place it is saying t= hat 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 use= s 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 se= rver, 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 m= essage integrity authentication anyway, and the ticket is transferred openl= y over the Internet, the ticket does not create any new level of defense. T= his 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 logica= l task: they are matching a new client network endpoint with an existing TU= RN session. They also are using a ticket, but they do not encode any inform= ation in it - that is just an opaque unique string. For protection, they al= so 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) > wrote: > Hi Oleg, > > It has some similarities but is a lot different from PCP third party auth= orization. For example for TURN the Authorization Server will be providing = session key, MAC algorithm etc which is not required with the PCP third par= ty authorization. There are various other differences like PCP server woul= d need to communicate with the Authorization Server to determine the token = bound authorization data (like the number of mappings permitted, flow char= acteristics allowed etc) which may not be required with TURN authorization.= PCP-controlled Firewall will most likely be in the same administrative do= main 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-bo= unces@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 ar= e interested in TURN evolution. Justin and we are working on TURN Extension= for Third Party Authorization using OAuth which will address some of the p= roblems 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 watchin= g and I am going to implement. I wonder whether the authors of the draft ma= y 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?= Any 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 = would focus on enhancements to STUN and TURN. The proposed name is TRAM (Tu= rn 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= 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 Apr= il > 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 (RF= C > 5245). This inherent dependency on ICE combined with the fact that ICE i= tself > was slow to achieve widespread adoption because other alternative mechani= sms > were historically used by the VoIP industry were the causes of the initia= l > lack of interest. This situation has changed drastically as ICE, and > consequently TURN, are mandatory to implement in WebRTC, which is a set o= f > 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 b= y the > arrival of WebRTC, there is a renewed interest in TURN and ICE, as eviden= ced 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 initiati= ves > to update TURN and STUN, including the definition of new transport and > authentication mechanisms that make STUN and TURN more suitable for the W= ebRTC > environment. The 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 > > Candidate draft: draft-petithuguenin-tram-turn-dtls > > TURN defines three transports: UDP, TCP, and TLS. A straightforward ext= ension > 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 sug= gested > > The current authentication mechanism for TURN, which is reused from STU= N, has > been designed with a SIP account database in mind. The new RTCWEB usage= s, > which are mostly based on web applications, do not fit that model. A ne= w > authentication mechanism optimized for such web applications will be cr= eated. > > - 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 NA= PTR 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 p= hase > 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_CEB51C6BE69Fpraspaticiscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Oleg,
Yes, the server should return a 400 Bad Request error. We'll update th= e draft accordingly.

Thanks,
Prashanth

From: Oleg Moskalenko <mom040267@gmail.com>
Date: Thursday, November 21, 2013 1= 2:54 PM
To: "Tirumaleswar Reddy (tired= dy)" <tireddy@cisco.com>= ;
Cc: Simon Perreault <simon.perreault@viagenie.ca>, &q= uot;tram@ietf.org" <tram@ietf.org>, Justin Uberti <juberti@google.com>
Subject: Re: [tram] TURN ICE Mobili= ty Draft


Hi Tiru

I found one more minor thing. In the section 5.1= .2, a variant is absent when MOBILITY-TICKET attribute is included into ALL= OCATE request, but it has a non-zero size. I'd suggest either 400 error cod= e, or ignore the ticket size altogether in the ALLOCATE request.

And also, the Mobility-Forbidden error code has = to be defined, of course.

Regards,
Oleg

On Tue, Nov 19, 2013 at 10:15 AM, Oleg Moskalenk= o <mom040267@gmai= l.com> wrote:
That's great. I ll provide a sort of proof-of-concept reference impl soon.<= br>
Thanks
Oleg

Sent from my iPhone

On Nov 19, 2013, at 4:26 AM, "Tirumaleswar Reddy (tireddy)" <<= a href=3D"mailto:tireddy@cisco.com">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 potenti= al 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 prob= lem 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 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 mobility case. I am not sure that I understand the exact action sequenc= e when the session NONCE expires with mobility feature.
> I think that the problem can be fixed if the draft would not include w= ording about the MOBILE-TICKET internal structure. In one place it is sayin= g that the ticket is opaque and implementation-dependent; but in other plac= es it suggests how the ticket must be constructed and how it must be encoded. I think that this is unnecessar= y. Let's just say that the ticket is opaque and its structure has meaning o= nly 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 a= nd 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 sessi= on 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 log= ical 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 inf= ormation 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 a= uthorization. For example for TURN the Authorization Server will be providi= ng 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 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 administrati= ve domain as the endpoint but that may not be true with TURN.
>
> we are working on the details and will have something concrete in coup= le 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 Extens= ion for Third Party Authorization using OAuth which will address some of th= e problems discussed in above draft.
>
> Cheers,
> -Tiru.
>
> From: Oleg Moskalenko <mom04= 0267@gmail.com>
> Subject: Re: [tram] First post
> Date: November 15, 2013 11:01:24 AM PST
> To: Simon Perreault <simon.perreault@viagenie.ca>
> Cc: <tram@ietf.org>
>
> MMUSIC has an interesting draft on TURN mobility (MICE) that I am watc= hing 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 beha= ve? Any 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 th= at 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: <https://www.ietf.org/mailman/listinfo/tram> >
> Here is the charter we have been working on. If you would like to comm= ent 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 depl= oyment.  This
> is primarily because its primary use case is as one of the NAT travers= al
> methods of the Interactive Connectivity Establishment (ICE) framework = (RFC
> 5245).  This inherent dependency on ICE combined with the fact th= at ICE itself
> was slow to achieve widespread adoption because other alternative mech= anisms
> were historically used by the VoIP industry were the causes of the ini= tial
> lack of interest.  This situation has changed drastically as ICE,= and
> consequently TURN, are mandatory to implement in WebRTC, which is a se= t of
> technologies developed at the IETF and W3C aiming to enable Real Time<= br> > Communication on the Web.
>
> Because of the ubiquity of the Web and of the new opportunities create= d by the
> arrival of WebRTC, there is a renewed interest in TURN and ICE, as evi= denced by
> the recent work updating the ICE framework, as well as standardizing t= he URIs
> used to access a STUN [RFC7064] or TURN [RFC7065] server.
>
> The goal of the TRAM Working Group is to consolidate the various initi= atives
> to update TURN and STUN, including the definition of new transport and=
> authentication mechanisms that make STUN and TURN more suitable for th= e 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 straightfor= ward extension
>   of this set is DTLS, enabling secure datagram-oriented transpor= t.
>
> - 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 RTCW= EB usages,
>   which are mostly based on web applications, do not fit that mod= el. A new
>   authentication mechanism optimized for such web applications wi= ll 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 a= nd/or NAPTR DNS
>   records. These records are usually under the administrative con= trol 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 "triang= le 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               --&g= t; 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_CEB51C6BE69Fpraspaticiscocom_-- From simon.perreault@viagenie.ca Fri Nov 22 07:15:07 2013 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 B3BC91ADFB0 for ; Fri, 22 Nov 2013 07:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, 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 jhexU-hoIT3v for ; Fri, 22 Nov 2013 07:15:02 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D668C1ADF78 for ; Fri, 22 Nov 2013 07:15:02 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A2DDB4690B for ; Fri, 22 Nov 2013 10:14:55 -0500 (EST) Message-ID: <528F74EF.6030903@viagenie.ca> Date: Fri, 22 Nov 2013 10:14:55 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.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] About that charter... 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, 22 Nov 2013 15:15:07 -0000 Are we done discussing it? What are the next steps? As a reminder, the current version is here: https://github.com/petithug/tram-charter/blob/master/charter.txt 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 Nov 22 14:35:12 2013 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 B8E1A1AE33E; Fri, 22 Nov 2013 14:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.026 X-Spam-Level: X-Spam-Status: No, score=-10.026 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.525, 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 hapHW19bnCj0; Fri, 22 Nov 2013 14:35:11 -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 D592F1AE307; Fri, 22 Nov 2013 14:35:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2858; q=dns/txt; s=iport; t=1385159704; x=1386369304; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=F0VBGrCMKpW2W8DV69dFuf9qzwbN80vFvS6OvXtuGbo=; b=F+MlqRQ2GsPPsqgEu0Ap5dmARQ9eIdXz47UJmQ99nD0RHiJN/N/3L4r8 WjoYRHrlokXyeg6ubCjHhLDeafGuVEOfr+xauGBlcJ82i1vtqWkXTAMof 1K+o/gnLIEi4URRVzbKTrM0MOblCGFpHFyhufL06/8HZHruUfz3gVQcdW g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAPjaj1KtJXG9/2dsb2JhbAA/GoMHOFO8FYEfFnSCJQEBAQMBAQEBNxQgEAsCARkDAQINEhAnCgEbAggCBAESCQsHAgSHWgYNNsB4F440VQuDGoESA5gUgTCLI4U/gWqBPoFxOQ X-IronPort-AV: E=Sophos;i="4.93,754,1378857600"; d="scan'208";a="1632156" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-1.cisco.com with ESMTP; 22 Nov 2013 22:35:03 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAMMZ3bZ000320 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Nov 2013 22:35:03 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.192]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Fri, 22 Nov 2013 16:35:02 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: "rtcweb@ietf.org" , "public-webrtc@w3.org" , "pntaw@ietf.org" , "tram@ietf.org" Thread-Topic: [rfc-dist] RFC 7064 on URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol Thread-Index: AQHO57KYv93N3ug+fESuZUXbnGRBSA== Date: Fri, 22 Nov 2013 22:35:02 +0000 Message-ID: <09DDE5BA-2A28-4031-AB42-5083F3C6290A@cisco.com> References: <20131122183155.C61FD75E001@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.236.83] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [tram] Fwd: [rfc-dist] RFC 7064 on URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol 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, 22 Nov 2013 22:35:12 -0000 [Excuse the cross-post, but I think this is relevant and/or has normative d= ependence.] The STUN URI scheme has been published as RFC. Cheers, Gonzalo Begin forwarded message: > From: > Subject: [rfc-dist] RFC 7064 on URI Scheme for the Session Traversal Util= ities for NAT (STUN) Protocol > Date: November 22, 2013 at 12:31:55 PM CST > To: , > Cc: , >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 7064 >=20 > Title: URI Scheme for the Session=20 > Traversal Utilities for NAT (STUN) Protocol=20 > Author: S. Nandakumar, G. Salgueiro, > P. Jones, M. Petit-Huguenin > Status: Standards Track > Stream: IETF > Date: November 2013 > Mailbox: snandaku@cisco.com,=20 > gsalguei@cisco.com,=20 > paulej@packetizer.com, > petithug@acm.org > Pages: 9 > Characters: 15045 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-nandakumar-rtcweb-stun-uri-08.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc7064.txt >=20 > This document specifies the syntax and semantics of the Uniform > Resource Identifier (URI) scheme for the Session Traversal Utilities > for NAT (STUN) protocol. >=20 > This is now a Proposed Standard. >=20 > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and suggestio= ns > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see http://www.rfc-editor.org/search/rfc_se= arch.php > For downloading RFCs, see http://www.rfc-editor.org/rfc.html >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > rfc-dist mailing list > rfc-dist@rfc-editor.org > https://www.rfc-editor.org/mailman/listinfo/rfc-dist > http://www.rfc-editor.org From gsalguei@cisco.com Fri Nov 22 18:40:34 2013 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 1BCF11A1F72; Fri, 22 Nov 2013 18:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.025 X-Spam-Level: X-Spam-Status: No, score=-15.025 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.525, 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 zErRyc7NxCzx; Fri, 22 Nov 2013 18:40:31 -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 89D291AC3DD; Fri, 22 Nov 2013 18:40:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10366; q=dns/txt; s=iport; t=1385174424; x=1386384024; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=kfq1cGrEG1y7VQ6/pQ73aMNazONfXPuSqSMoZL/Ycz4=; b=I8rMe4tSSfyjdTSYdz53bbtLIe6sb7SkmCzR370RAaiKrAwddeWniWEC bG/gdbcCJwttXkoufBLkvp6rIjjOWVonz+Cs2i1yDItVXbI9MtVPG+o5P 1PJR6UVw61oLoowvtJs/HlOF8Q1M74EhKzPjL7qBIAQFeQ3ZDuxgO5R/c o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwGAFQVkFKtJXHB/2dsb2JhbAA/GoMHOLQdiEyBIBZ0giUBAQEEAQEBSyAbAgEZAwECDRsHJwoBFAcCCAIEARIJCwcCBIdgDTbAUReONEINCgEGgxqBEwOYFIEwiyOFP4FqgT6BcQ X-IronPort-AV: E=Sophos;i="4.93,756,1378857600"; d="scan'208,217";a="286966847" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 23 Nov 2013 02:40:19 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rAN2eJOT027615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 23 Nov 2013 02:40:19 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.192]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Fri, 22 Nov 2013 20:40:18 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: "rtcweb@ietf.org" , "pntaw@ietf.org" , "public-webrtc@w3.org" , "tram@ietf.org" Thread-Topic: [rfc-dist] RFC 7065 on Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers Thread-Index: AQHO5+pEXQhXjFTbG0WqzojKCtYKrZoyGt30 Date: Sat, 23 Nov 2013 02:40:18 +0000 Message-ID: References: <20131123011025.1B70275E001@rfc-editor.org> In-Reply-To: <20131123011025.1B70275E001@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_C0E6C8D2EDC64CCC98C56A942D1239FBciscocom_" MIME-Version: 1.0 Subject: [tram] Fwd: [rfc-dist] RFC 7065 on Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers 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, 23 Nov 2013 02:40:34 -0000 --_000_C0E6C8D2EDC64CCC98C56A942D1239FBciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Excuse the cross-post, but I think this is relevant and/or has normative d= ependence.] The TURN URI scheme has been published as an RFC. Regards, Gonzalo Begin forwarded message: From: > Date: November 22, 2013 at 8:10:25 PM EST To: >, > Cc: >, > Subject: [rfc-dist] RFC 7065 on Traversal Using Relays around NAT (TURN) Un= iform Resource Identifiers A new Request for Comments is now available in online RFC libraries. RFC 7065 Title: Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers Author: M. Petit-Huguenin, S. Nandakumar, G. Salgueiro, P. Jones Status: Standards Track Stream: IETF Date: November 2013 Mailbox: petithug@acm.org, snandaku@cisco.com, gsalguei@cisco.com, paulej@packetizer.com Pages: 9 Characters: 16143 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-petithuguenin-behave-turn-uris-08.txt URL: http://www.rfc-editor.org/rfc/rfc7065.txt This document specifies the syntax of Uniform Resource Identifier (URI) schemes for the Traversal Using Relays around NAT (TURN) protocol. It defines two URI schemes to provision the TURN Resolution Mechanism (RFC 5928). This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_sear= ch.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ rfc-dist mailing list rfc-dist@rfc-editor.org https://www.rfc-editor.org/mailman/listinfo/rfc-dist http://www.rfc-editor.org --_000_C0E6C8D2EDC64CCC98C56A942D1239FBciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
[Excuse the cross-post, but I think this is relevant an= d/or has normative dependence.]

The TURN URI scheme has been published as an RFC.

Regards,

Gonzalo


Begin forwarded message:

From: <rfc-edit= or@rfc-editor.org>
Date: November 22, 2013 at 8:10:25 PM EST
To: <ietf-announce@ietf= .org>, <rfc-dist@rfc-e= ditor.org>
Cc: <drafts-update-= ref@iana.org>, <rfc-= editor@rfc-editor.org>
Subject: [rfc-dist] RFC 7065 on Traversal Using Relays around NAT= (TURN) Uniform Resource Identifiers

A new Request for Comments is now available in online RFC librar= ies.


       RFC 7065

       Title:    &n= bsp; Traversal Using Relays around NAT
           &nb= sp;       (TURN) Uniform Resource Identi= fiers
       Author:    &= nbsp;M. Petit-Huguenin, S. Nandakumar,
           &nb= sp;       G. Salgueiro, P. Jones<= br>        Status:    &= nbsp;Standards Track
       Stream:    &= nbsp;IETF
       Date:    &nb= sp;  November 2013
       Mailbox:    = petithug@acm.org,
           &nb= sp;       snandaku@cisco.com,
           &nb= sp;       gsalguei@cisco.com,
           &nb= sp;       paulej@packetizer.com
       Pages:    &n= bsp; 9
       Characters: 16143        Updates/Obsoletes/SeeAlso: =   None

       I-D Tag:    = draft-petithuguenin-behave-turn-uris-08.txt

       URL:    &nbs= p;   h= ttp://www.rfc-editor.org/rfc/rfc7065.txt

This document specifies the syntax of Uniform Resource Identifier
(URI) schemes for the Traversal Using Relays around NAT (TURN)=
protocol.  It defines two URI schemes to provision the TURN
Resolution Mechanism (RFC 5928).

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet standards track<= /span>
protocol for the Internet community,and requests discussion and sugge= stions
for improvements.  Please refer to the current edition of the In= ternet
Official Protocol Standards (STD 1) for the standardization state and=
status of this protocol.  Distribution of this memo is unlimited= .

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
 = http://www.ietf.org/mailman/listinfo/ietf-announce
 http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
rfc-dist mailing list
rfc-dist@rfc-editor.org
http= s://www.rfc-editor.org/mailman/listinfo/rfc-dist
http://www.rfc-editor.org
--_000_C0E6C8D2EDC64CCC98C56A942D1239FBciscocom_-- From mom040267@gmail.com Mon Nov 25 09:35:26 2013 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 E931C1ADFB1 for ; Mon, 25 Nov 2013 09:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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, NORMAL_HTTP_TO_IP=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 2bhimf8xh5v6 for ; Mon, 25 Nov 2013 09:35:24 -0800 (PST) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 652B91ADFC2 for ; Mon, 25 Nov 2013 09:35:24 -0800 (PST) Received: by mail-pd0-f174.google.com with SMTP id y13so5890501pdi.5 for ; Mon, 25 Nov 2013 09:35:24 -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=LXm4L2SvqO5FUW15ZOeY1608m2yBL6zLmwyw57Gnx5g=; b=WJ/8sbNzDYFqmjI0dqpdDqNaOURQrdYEKT4LzhX7pjTyqr6ofx6EVepvmp0Qd62sL7 i2YDSnJY3n4ft+9lOqgChmybXgAQrNlE4tDwCyC2JHVMlpGnfBSsMUjufkvqzBtIv4Ru Oljs6syW/tK3JWHK7G+CkrRuQ1caqAUx58mx+T/G4xxcs39K2q01DbrU8/KGgV1i+T0a ByHxnr8W49HgCRfS2cNvLLvpohj7eKRgMDN8mXguRcmQvAWzuBYjsDMNif37GUKqpSb8 bJCJmecEaWCH/FaF7O+JZMZv2AZmeSi3Qy7rrrssXQKEBmUf4VxQUqCkZ5SgWNiDkw6E EqDg== MIME-Version: 1.0 X-Received: by 10.68.194.9 with SMTP id hs9mr19332489pbc.95.1385400924512; Mon, 25 Nov 2013 09:35:24 -0800 (PST) Received: by 10.68.147.131 with HTTP; Mon, 25 Nov 2013 09:35:24 -0800 (PST) In-Reply-To: References: Date: Mon, 25 Nov 2013 09:35:24 -0800 Message-ID: From: Oleg Moskalenko To: "Prashanth Patil (praspati)" Content-Type: multipart/alternative; boundary=047d7b15b14dfa2c3e04ec03c990 Cc: Simon Perreault , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" , Justin Uberti Subject: Re: [tram] TURN ICE Mobility Draft 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, 25 Nov 2013 17:35:27 -0000 --047d7b15b14dfa2c3e04ec03c990 Content-Type: text/plain; charset=ISO-8859-1 I added experimental Mobile ICE functionality support to our project, to version 3.0.1.2: http://code.google.com/p/rfc5766-turn-server/ You can test whether this is what you want to achieve in your specs. As the "mobility forbidden" error code is not defined yet, I simply used 403. Regards, Oleg On Fri, Nov 22, 2013 at 1:16 AM, Prashanth Patil (praspati) < praspati@cisco.com> wrote: > Hi Oleg, > Yes, the server should return a 400 Bad Request error. We'll update the > draft accordingly. > > Thanks, > Prashanth > > From: Oleg Moskalenko > Date: Thursday, November 21, 2013 12:54 PM > To: "Tirumaleswar Reddy (tireddy)" > Cc: Simon Perreault , "tram@ietf.org" < > tram@ietf.org>, Justin Uberti > Subject: Re: [tram] TURN ICE Mobility Draft > > > Hi Tiru > > I found one more minor thing. In the section 5.1.2, a variant is absent > when MOBILITY-TICKET attribute is included into ALLOCATE request, but it > has a non-zero size. I'd suggest either 400 error code, or ignore the > ticket size altogether in the ALLOCATE request. > > And also, the Mobility-Forbidden error code has to be defined, of course. > > Regards, > Oleg > > On Tue, Nov 19, 2013 at 10:15 AM, Oleg Moskalenko wrote: > >> That's great. I ll provide a sort of proof-of-concept reference impl soon. >> >> Thanks >> Oleg >> >> Sent from my iPhone >> >> On 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 >> > >> > >> > > --047d7b15b14dfa2c3e04ec03c990 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I added experimental Mobile ICE functionality su= pport to our project, to version 3.0.1.2:
http://code.= google.com/p/rfc5766-turn-server/

You can test whether this is what you want to achieve in you= r specs.

As the "mobility forbidden" erro= r code is not defined yet, I simply used 403.

Regards,
Oleg



On Fri, Nov 22, 2013 at 1:16 AM, Prashanth Patil (praspati) <p= raspati@cisco.com> wrote:
Hi Oleg,
Yes, the server should return a 400 Bad Request error. We'll updat= e the draft accordingly.

Thanks,
Prashanth

From: Oleg Moskalenko <mom040267@gmail.com&g= t;
Date: Thursday, November 21, 2013 1= 2:54 PM
To: "Tirumaleswar Reddy (tired= dy)" <tiredd= y@cisco.com>
Cc: Simon Perreault <simon.perreault@viage= nie.ca>, "tr= am@ietf.org" <tram@ietf.org>, Justin Uberti <juberti@google.com>
Subject: Re: [tram] TURN ICE Mobili= ty Draft


Hi Tiru

I found one more minor thing. In the section 5.1= .2, a variant is absent when MOBILITY-TICKET attribute is included into ALL= OCATE request, but it has a non-zero size. I'd suggest either 400 error= code, or ignore the ticket size altogether in the ALLOCATE request.

And also, the Mobility-Forbidden error code has = to be defined, of course.

Regards,
Oleg

On Tue, Nov 19, 2013 at 10:15 AM, Oleg Moskalenk= o <mom040267@gmai= l.com> wrote:
That's great. I ll provide a sort of proof-of-concept reference impl so= on.

Thanks
Oleg

Sent from my iPhone

On Nov 19, 2013, at 4:26 AM, "Tirumaleswar Reddy (tireddy)" <<= a href=3D"mailto:tireddy@cisco.com" target=3D"_blank">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 potenti= al 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 prob= lem 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 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 mobility case. I am not sure that I understand the exact action sequenc= e when the session NONCE expires with mobility feature.
> I think that the problem can be fixed if the draft would not include w= ording about the MOBILE-TICKET internal structure. In one place it is sayin= g that the ticket is opaque and implementation-dependent; but in other plac= es it suggests how the ticket must be constructed and how it must be encoded. I think that this is unnecessar= y. Let's just say that the ticket is opaque and its structure has meani= ng 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 informati= on 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 sessi= on 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 log= ical 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 inf= ormation 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 a= uthorization. For example for TURN the Authorization Server will be providi= ng session key, MAC algorithm etc which is not required with the PCP third = party authorization. =A0There are various other differences like PCP server would need to communicate with the Autho= rization Server to determine the token bound authorization data =A0(like th= e number of mappings permitted, flow characteristics allowed etc) which may= not be required with TURN authorization. =A0PCP-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 coup= le 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 Extens= ion for Third Party Authorization using OAuth which will address some of th= e problems 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 <simon.perreault@viagenie.ca>
> Cc: <tram@ietf.o= rg>
>
> MMUSIC has an interesting draft on TURN mobility (MICE) that I am watc= hing 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.c= a> wrote:
> All,
>
> Any objection against sending the following to rtcweb, pntaw, and beha= ve? Any 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 th= at 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: <https://www.ietf.org/mailman/listinfo/tram> >
> Here is the charter we have been working on. If you would like to comm= ent 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. =A0Until recently the protocol had only a rather limited deploym= ent. =A0This
> is primarily because its primary use case is as one of the NAT travers= al
> methods of the Interactive Connectivity Establishment (ICE) framework = (RFC
> 5245). =A0This inherent dependency on ICE combined with the fact that = ICE itself
> was slow to achieve widespread adoption because other alternative mech= anisms
> were historically used by the VoIP industry were the causes of the ini= tial
> lack of interest. =A0This situation has changed drastically as ICE, an= d
> consequently TURN, are mandatory to implement in WebRTC, which is a se= t of
> technologies developed at the IETF and W3C aiming to enable Real Time<= br> > Communication on the Web.
>
> Because of the ubiquity of the Web and of the new opportunities create= d by the
> arrival of WebRTC, there is a renewed interest in TURN and ICE, as evi= denced by
> the recent work updating the ICE framework, as well as standardizing t= he URIs
> used to access a STUN [RFC7064] or TURN [RFC7065] server.
>
> The goal of the TRAM Working Group is to consolidate the various initi= atives
> to update TURN and STUN, including the definition of new transport and=
> authentication mechanisms that make STUN and TURN more suitable for th= e WebRTC
> environment. =A0The Working Group will closely coordinate with the app= ropriate
> 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 straightforwar= d extension
> =A0 of this set is DTLS, enabling secure datagram-oriented transport.<= br> >
> - New authentication mechanism for TURN
>
> =A0 Problem analysis: draft-reddy-behave-turn-auth
> =A0 Candidate draft: draft-uberti-behave-turn-rest, OAuth has also bee= n suggested
>
> =A0 The current authentication mechanism for TURN, which is reused fro= m STUN, has
> =A0 been designed with a SIP account database in mind. The new RTCWEB = usages,
> =A0 which are mostly based on web applications, do not fit that model.= A new
> =A0 authentication mechanism optimized for such web applications will = be created.
>
> - 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 NAPTR DNS
> =A0 records. These records are usually under the administrative contro= l 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 pro= vide their
> =A0 own TURN server, in an attempt to reduce so-called "triangle = routing", 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 negoti= ation 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 > https://www.ietf.org/mailman/listinfo/tram
>
> _______________________________________________
> tram mailing list
> tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram
>
>

--047d7b15b14dfa2c3e04ec03c990-- From palmarti@cisco.com Tue Nov 26 01:03:17 2013 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 025491AE125 for ; Tue, 26 Nov 2013 01:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 q4x4mEAWl5aR for ; Tue, 26 Nov 2013 01:03:15 -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 708601AE101 for ; Tue, 26 Nov 2013 01:03:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1262; q=dns/txt; s=iport; t=1385456595; x=1386666195; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qis0NnTroi3qzs4V2HosooofxJbzsmCZxg3i+RLou8Y=; b=H625+8BYhyiTDxci2hcSmg9W+U1t77AnQ5g/pClBf9QwaqM60IhK0Qc7 g3baCBzTgv7mDBDks79rrDzNEWWsPzLaJqmoxExX+uOrmXPiC5JjcQXML U8JSeZrPO1aEhZP1dvhOF2GBGM6PJ909qoWoxksxFdV2fACZcLSAwbDXU o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFABljlFKtJXG8/2dsb2JhbABZgwc4U7wVgSkWdIIlAQEBAwEBAQEkRwsFCwIBCEYnCyUCBA4Fh3sGDb5/F45DMweDIIETA5gUgTCQYYMogio X-IronPort-AV: E=Sophos;i="4.93,773,1378857600"; d="scan'208";a="287505824" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 26 Nov 2013 09:03:15 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rAQ93FOX025154 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Nov 2013 09:03:15 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.147]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Tue, 26 Nov 2013 03:03:14 -0600 From: "Pal Martinsen (palmarti)" To: Simon Perreault Thread-Topic: [tram] About that charter... Thread-Index: AQHO55WgEKEIDrQAvkeUSXFwnXBAX5o3ohIA Date: Tue, 26 Nov 2013 09:03:14 +0000 Message-ID: <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> References: <528F74EF.6030903@viagenie.ca> In-Reply-To: <528F74EF.6030903@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.203.106] Content-Type: text/plain; charset="Windows-1252" Content-ID: <6CF28AB6C887C14D9F97BDED7C04B3EF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tram@ietf.org" Subject: Re: [tram] About that charter... 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, 26 Nov 2013 09:03:17 -0000 Hi, On 22 Nov 2013, at 16:14 pm, Simon Perreault = wrote: > Are we done discussing it? What are the next steps? >=20 > As a reminder, the current version is here: > https://github.com/petithug/tram-charter/blob/master/charter.txt >=20 I think the charter looks good. Being a new-bee regarding charters I have a few questions and comments. The first section is rather long and describes the background in length. Is= the text in the first section at all necessary in a charter? Can we add something around cloud in section three? For example: =93 =97 that make STUN and TURN more suitable for WebRTC and Cloud like environments.=94 TRAM would also benefit more traditional enterprise deployments. By using t= he word =93cloud=94 the charter can get some attention from that camp as we= ll. Consider these comments as nits.=20 .-. P=E5l-Erik > Simon > --=20 > 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 hangzhou.chenxin@huawei.com Tue Nov 26 01:08:27 2013 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 131591AE117 for ; Tue, 26 Nov 2013 01:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 N5nAxHWZigJ2 for ; Tue, 26 Nov 2013 01:08:25 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 217CD1AE101 for ; Tue, 26 Nov 2013 01:08:24 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAS27802; Tue, 26 Nov 2013 09:08:24 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 26 Nov 2013 09:07:58 +0000 Received: from SZXEMA409-HUB.china.huawei.com (10.82.72.41) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 26 Nov 2013 09:08:23 +0000 Received: from SZXEMA504-MBX.china.huawei.com ([169.254.7.191]) by SZXEMA409-HUB.china.huawei.com ([10.82.72.41]) with mapi id 14.03.0158.001; Tue, 26 Nov 2013 17:08:17 +0800 From: "Chenxin (Xin)" To: "Pal Martinsen (palmarti)" , Simon Perreault Thread-Topic: [tram] About that charter... Thread-Index: AQHO55Wh74zJw+mQ5k2tNDsxhBfq3Jo2t2UAgACGhdA= Date: Tue, 26 Nov 2013 09:08:16 +0000 Message-ID: <9E34D50A21D1D1489134B4D770CE0397680A17E1@SZXEMA504-MBX.china.huawei.com> References: <528F74EF.6030903@viagenie.ca> <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> In-Reply-To: <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.41.125] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "tram@ietf.org" Subject: Re: [tram] About that charter... 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, 26 Nov 2013 09:08:27 -0000 Hi Pal, >-----Original Message----- >From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Pal Martinsen >(palmarti) >Sent: Tuesday, November 26, 2013 5:03 PM >To: Simon Perreault >Cc: tram@ietf.org >Subject: Re: [tram] About that charter... > >Hi, > >On 22 Nov 2013, at 16:14 pm, Simon Perreault >wrote: > >> Are we done discussing it? What are the next steps? >> >> As a reminder, the current version is here: >> https://github.com/petithug/tram-charter/blob/master/charter.txt >> >I think the charter looks good. > >Being a new-bee regarding charters I have a few questions and comments. > >The first section is rather long and describes the background in length. I= s the >text in the first section at all necessary in a charter? > >Can we add something around cloud in section three? For example: >" - that make STUN and TURN more suitable for WebRTC and Cloud like >environments." > >TRAM would also benefit more traditional enterprise deployments. By using = the >word "cloud" the charter can get some attention from that camp as well. > >Consider these comments as nits. Could you give some detailed requirements and considerations about the "cl= oud"?that will be more helpful. It will be better this could be get benefit= from or affect the deliverables. =20 Best Regards, Xin=20 > >.-. >P=E5l-Erik > > >> 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 > >_______________________________________________ >tram mailing list >tram@ietf.org >https://www.ietf.org/mailman/listinfo/tram From mom040267@gmail.com Tue Nov 26 01:20:39 2013 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 CE8291AE125 for ; Tue, 26 Nov 2013 01:20:39 -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 ksXyc9S3ImdM for ; Tue, 26 Nov 2013 01:20:38 -0800 (PST) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 10B9E1AE117 for ; Tue, 26 Nov 2013 01:20:37 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id p61so4967602wes.22 for ; Tue, 26 Nov 2013 01:20: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=yZzIA6pUP+azOLOcAFsIPXicRvMK5YcaUMn6ENLqrvE=; b=eOWTkH2GB0iLLnu3a9MXVglTLIByrNb4+7OhSjaxogrRqmddkaSH5kd37o2LMAaahh x4QSpe5+KSn3yApoOT3iD1QJ4/jxZt2KcJszTO+P60SYEZr0LYod6ed3SA2adqigv/wQ /y/PNgIZFMQ052gITz2JtbLRaF0xyQ7pTSwmeHL7AlLvWXgYPZv9fOTn7Vw22smwqMrw J5EJvl08PJigSdlvEQQOcVow605+R1Hkthgr5o5qv7/vtivVFZG2rmu62Z4iuV+DKxoK NZ9fQjuilO9abbK3V0tw8qD3I20lShsae5Ub+T21oa8Ra382EgA9imR2P2v7gFsXCwRT WdnQ== MIME-Version: 1.0 X-Received: by 10.194.21.131 with SMTP id v3mr5587550wje.44.1385457637497; Tue, 26 Nov 2013 01:20:37 -0800 (PST) Received: by 10.194.108.65 with HTTP; Tue, 26 Nov 2013 01:20:37 -0800 (PST) In-Reply-To: <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> References: <528F74EF.6030903@viagenie.ca> <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> Date: Tue, 26 Nov 2013 01:20:37 -0800 Message-ID: From: Oleg Moskalenko To: "Pal Martinsen (palmarti)" Content-Type: multipart/alternative; boundary=047d7b5d64f2559fff04ec10fe5e Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] About that charter... 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, 26 Nov 2013 09:20:40 -0000 --047d7b5d64f2559fff04ec10fe5e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable If we add word "porn" it will attract even more attention. For many engineers, "cloud" is a non-technical term, for managers only. But this is supposed to be a very technical list. On Tue, Nov 26, 2013 at 1:03 AM, Pal Martinsen (palmarti) < palmarti@cisco.com> wrote: > Hi, > > On 22 Nov 2013, at 16:14 pm, Simon Perreault > wrote: > > > Are we done discussing it? What are the next steps? > > > > As a reminder, the current version is here: > > https://github.com/petithug/tram-charter/blob/master/charter.txt > > > I think the charter looks good. > > Being a new-bee regarding charters I have a few questions and comments. > > The first section is rather long and describes the background in length. > Is the text in the first section at all necessary in a charter? > > Can we add something around cloud in section three? For example: > =93 =97 that make STUN and TURN more suitable for WebRTC and Cloud like > environments.=94 > > TRAM would also benefit more traditional enterprise deployments. By using > the word =93cloud=94 the charter can get some attention from that camp as= well. > > Consider these comments as nits. > > .-. > P=E5l-Erik > > > > 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 > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --047d7b5d64f2559fff04ec10fe5e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
If we add word "porn" it will attract even = more attention.

For many engineers, "cloud" is a non= -technical term, for managers only. But this is supposed to be a very techn= ical list.


On Tue,= Nov 26, 2013 at 1:03 AM, Pal Martinsen (palmarti) <palmarti@cisco.com> wrote:
Hi,

On 22 Nov 2013, at 16:14 pm, Simon Perreault <simon.perreault@viagenie.ca> wrote:

> Are we done discussing it? What are the next steps?
>
> As a reminder, the current version is here:
> https://github.com/petithug/tram-charter/blob/mast= er/charter.txt
>
I think the charter looks good.

Being a new-bee regarding charters I have a few questions and comments.

The first section is rather long and describes the background in length. Is= the text in the first section at all necessary in a charter?

Can we add something around cloud in section three? For example:
=93 =97 that make STUN and TURN more suitable for WebRTC and Cloud like
environments.=94

TRAM would also benefit more traditional enterprise deployments. By using t= he word =93cloud=94 the charter can get some attention from that camp as we= ll.

Consider these comments as nits.

.-.
P=E5l-Erik


> 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
> https://www.ietf.org/mailman/listinfo/tram

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

--047d7b5d64f2559fff04ec10fe5e-- From palmarti@cisco.com Tue Nov 26 01:27:14 2013 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 485ED1ACCD9 for ; Tue, 26 Nov 2013 01:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 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.001, 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 ne-2N5LvHFfF for ; Tue, 26 Nov 2013 01:27:12 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA3A1AC4A3 for ; Tue, 26 Nov 2013 01:27:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3067; q=dns/txt; s=iport; t=1385458032; x=1386667632; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XEnL8GZlmYot5XdVNAteQUNDKMOKTJQ88Ivsf7938KQ=; b=BVaTPLzIXnptwMsDZp2DdcdkkiLBwPB4l3jmmRItrPjB/aq0GSTT8eVy bSsNx61k2sftfdQhxKWvH+iB/Lp5txkOhW3x/VYGSbzDCeFQ5BFuBJk9x fOVMEWn5kCFpvyqw5VTluKCbnxkNES16YhCHIbS1jt55nJL3Evk3SiEuF w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFADRplFKtJV2b/2dsb2JhbABZgwc4U7wVgSkWdIIlAQEBAwEBAQEkRwsFBwQCAQgRBAEBAScHJwsUCQgCBA4Fh3sGDb8XF45DMwcGgxqBEwOYFIEwkGGDKIIq X-IronPort-AV: E=Sophos;i="4.93,773,1378857600"; d="scan'208";a="2280077" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 26 Nov 2013 09:27:12 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAQ9RBjq022360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Nov 2013 09:27:11 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.147]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Tue, 26 Nov 2013 03:27:11 -0600 From: "Pal Martinsen (palmarti)" To: "Chenxin (Xin)" Thread-Topic: [tram] About that charter... Thread-Index: AQHO55WgEKEIDrQAvkeUSXFwnXBAX5o3ohIAgAABbQCAAAVKAA== Date: Tue, 26 Nov 2013 09:27:11 +0000 Message-ID: <0B33EFFA-CBED-4041-9D2C-6625C5CC67C0@cisco.com> References: <528F74EF.6030903@viagenie.ca> <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> <9E34D50A21D1D1489134B4D770CE0397680A17E1@SZXEMA504-MBX.china.huawei.com> In-Reply-To: <9E34D50A21D1D1489134B4D770CE0397680A17E1@SZXEMA504-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.203.106] Content-Type: text/plain; charset="Windows-1252" Content-ID: <12A5813693144140B32EA7E35E082DF9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] About that charter... 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, 26 Nov 2013 09:27:14 -0000 On 26 Nov 2013, at 10:08 am, Chenxin (Xin) wr= ote: > Hi Pal, >=20 >=20 >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Pal Martinsen >> (palmarti) >> Sent: Tuesday, November 26, 2013 5:03 PM >> To: Simon Perreault >> Cc: tram@ietf.org >> Subject: Re: [tram] About that charter... >>=20 >> Hi, >>=20 >> On 22 Nov 2013, at 16:14 pm, Simon Perreault >> wrote: >>=20 >>> Are we done discussing it? What are the next steps? >>>=20 >>> As a reminder, the current version is here: >>> https://github.com/petithug/tram-charter/blob/master/charter.txt >>>=20 >> I think the charter looks good. >>=20 >> Being a new-bee regarding charters I have a few questions and comments. >>=20 >> The first section is rather long and describes the background in length.= Is the >> text in the first section at all necessary in a charter? >>=20 >> Can we add something around cloud in section three? For example: >> " - that make STUN and TURN more suitable for WebRTC and Cloud like >> environments." >>=20 >> TRAM would also benefit more traditional enterprise deployments. By usin= g the >> word "cloud" the charter can get some attention from that camp as well. >>=20 >> Consider these comments as nits. >=20 > Could you give some detailed requirements and considerations about the "c= loud"?that will be more helpful. It will be better this could be get benefi= t from or affect the deliverables. >=20 You are right about cloud being a bit fuzzy, and it might not bee a good id= ea to add buzzwords to the charter.=20 My goal was to add a word or short sentence getting the attention of the mo= re traditional enterprise folks. As the charter describes in the first sect= ion ICE and TURN was slow to be adopted. Adding security, authentication, m= anageability, mobility ,QoS ++ extensions to TURN will hopefully lead to m= ore enterprises deploying TURN. Getting more =93feature=94 parity between e= nterprise and RTCWEB deployment would benefit all. Having some wording stat= ing that this is also intended for enterprise might help. This is just word smithing to avoid enterprise folks that just see a red fl= ag whenever RTCWEB is mentioned to be more happy.=20 .-. P=E5l-Erik > Best Regards, > Xin=20 >=20 >>=20 >> .-. >> P=E5l-Erik >>=20 >>=20 >>> 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 >>=20 >> _______________________________________________ >> 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 From palmarti@cisco.com Tue Nov 26 01:33:37 2013 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 D3C2B1AD939 for ; Tue, 26 Nov 2013 01:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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.001, 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 7J1BTYo4zwGs for ; Tue, 26 Nov 2013 01:33:36 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C7F1F1ACCE5 for ; Tue, 26 Nov 2013 01:33:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6786; q=dns/txt; s=iport; t=1385458416; x=1386668016; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=X+bkOyJ8EUrJhMM9eWOBQPbT5O7xFM5JTR5ltzjrIiY=; b=GrPXpTEpvRKXnJm/w55RptQ0tdabwY01Yuk5gRed9XgJ7Seab0yeZlhj yKKl0b5HppPF8+hh0RMxhQlCR2s0srYed0QQpra1BKtgcY+XDZRBbTP3I TF11LQW3QsZAD825RGE2IlFNslb74EpEzeBq4TLPwuVqBX3vIWKJDHRUv w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwHAGZqlFKtJV2c/2dsb2JhbABZgwc4U6lbiWuIT4EpFnSCJQEBAQMBAQEBJEcLBQsCAQgOMQchBgsUEQIEDgWHbwMJBg23BQ2IBxeMZ4ILBAcJgxeBEwOWKYFrgTCLKYU4gyiCKg X-IronPort-AV: E=Sophos;i="4.93,773,1378857600"; d="scan'208,217";a="287534265" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 26 Nov 2013 09:33:35 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rAQ9XZA3009055 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Nov 2013 09:33:35 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.147]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Tue, 26 Nov 2013 03:33:35 -0600 From: "Pal Martinsen (palmarti)" To: Oleg Moskalenko Thread-Topic: [tram] About that charter... Thread-Index: AQHO55WgEKEIDrQAvkeUSXFwnXBAX5o3ohIAgAAE4ICAAAOeAA== Date: Tue, 26 Nov 2013 09:33:34 +0000 Message-ID: <2A412C79-7200-4730-837F-F44A2618E8F1@cisco.com> References: <528F74EF.6030903@viagenie.ca> <4EF14367-E435-43D6-B330-0F16FB832013@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.61.203.106] Content-Type: multipart/alternative; boundary="_000_2A412C7972004730837FF44A2618E8F1ciscocom_" MIME-Version: 1.0 Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] About that charter... 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, 26 Nov 2013 09:33:38 -0000 --_000_2A412C7972004730837FF44A2618E8F1ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 26 Nov 2013, at 10:20 am, Oleg Moskalenko > wrote: If we add word "porn" it will attract even more attention. :-) More attention or deployments? For many engineers, "cloud" is a non-technical term, for managers only. But= this is supposed to be a very technical list. Agree. But it still be nice with some wording to get the more traditional e= nterprise folks onboard. .-. P=E5l-Erik On Tue, Nov 26, 2013 at 1:03 AM, Pal Martinsen (palmarti) > wrote: Hi, On 22 Nov 2013, at 16:14 pm, Simon Perreault > wrote: > Are we done discussing it? What are the next steps? > > As a reminder, the current version is here: > https://github.com/petithug/tram-charter/blob/master/charter.txt > I think the charter looks good. Being a new-bee regarding charters I have a few questions and comments. The first section is rather long and describes the background in length. Is= the text in the first section at all necessary in a charter? Can we add something around cloud in section three? For example: =93 =97 that make STUN and TURN more suitable for WebRTC and Cloud like environments.=94 TRAM would also benefit more traditional enterprise deployments. By using t= he word =93cloud=94 the charter can get some attention from that camp as we= ll. Consider these comments as nits. .-. P=E5l-Erik > 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 _______________________________________________ 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_2A412C7972004730837FF44A2618E8F1ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7766BE7E299B6A47A233995BC0BFD0AA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 26 Nov 2013, at 10:20 am, Oleg Moskalenko <mom040267@gmail.com> wrote:

If we add word "porn" it will attract even more attention.

:-) 
More attention or deployments?

For many engineers, "cloud" is a non-technical term, for managers= only. But this is supposed to be a very technical list.

Agree. But it still be nice with some wording to get the more traditio= nal enterprise folks onboard.

.-.
P=E5l-Erik


On Tue, Nov 26, 2013 at 1:03 AM, Pal Martinsen (= palmarti) <palmarti@cisco.com> wrote:
Hi,

On 22 Nov 2013, at 16:14 pm, Simon Perreault <simon.perreault@viagenie.ca> wrote:

> Are we done discussing it? What are the next steps?
>
> As a reminder, the current version is here:
> https://github.com/petithug/tram-charter/blob/master/charter.txt
>
I think the charter looks good.

Being a new-bee regarding charters I have a few questions and comments.

The first section is rather long and describes the background in length. Is= the text in the first section at all necessary in a charter?

Can we add something around cloud in section three? For example:
=93 =97 that make STUN and TURN more suitable for WebRTC and Cloud like
environments.=94

TRAM would also benefit more traditional enterprise deployments. By using t= he word =93cloud=94 the charter can get some attention from that camp as we= ll.

Consider these comments as nits.

.-.
P=E5l-Erik


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

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

_______________________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

--_000_2A412C7972004730837FF44A2618E8F1ciscocom_-- From mom040267@gmail.com Tue Nov 26 01:35:07 2013 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 70F161A1F55 for ; Tue, 26 Nov 2013 01:35:07 -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 GRJ39W9FMGEK for ; Tue, 26 Nov 2013 01:35:05 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 0655C1ACCE5 for ; Tue, 26 Nov 2013 01:35:04 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id ca18so6761242wib.11 for ; Tue, 26 Nov 2013 01:35:04 -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=7PsL4dfwWP0JmjlkQHnXhYAI5jYNBF4okFk37dJeFz4=; b=Q3izLpGkKQuaZPfA+wuEKZNrClgPLfiBrcvlB7fzMg0eagc95NPrFcMPFfob+a1d8c uUcQ+cIC1oZhDm6G5L0emlIjU8uOkmlMX09nsE4PVJT8NxDTEzuRTiCpPmkmSc50O3wU +0Zkr56IyrA8w1ucUkO3o/8LOhei5S5fqq0Mr7E29IRie+AyyeqQHNL+PJmcJRRJZnZh NDS+HWx9d1MGEE6jAgn9hhHFovHPWrFJfYBNL+gNt0ZguMNB4e7RHX+qef2BVRXcjUon kROS/JriaaEIyxRWw1KLxgLaX/4Hg9sgwPq0qtmDieGjuL8svHhNEnWLERTSB6/oUIz4 qWIg== MIME-Version: 1.0 X-Received: by 10.180.10.138 with SMTP id i10mr5807032wib.44.1385458504526; Tue, 26 Nov 2013 01:35:04 -0800 (PST) Received: by 10.194.108.65 with HTTP; Tue, 26 Nov 2013 01:35:04 -0800 (PST) In-Reply-To: <0B33EFFA-CBED-4041-9D2C-6625C5CC67C0@cisco.com> References: <528F74EF.6030903@viagenie.ca> <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> <9E34D50A21D1D1489134B4D770CE0397680A17E1@SZXEMA504-MBX.china.huawei.com> <0B33EFFA-CBED-4041-9D2C-6625C5CC67C0@cisco.com> Date: Tue, 26 Nov 2013 01:35:04 -0800 Message-ID: From: Oleg Moskalenko To: "Pal Martinsen (palmarti)" Content-Type: multipart/alternative; boundary=001a11c218ae036f4d04ec113219 Cc: Simon Perreault , "tram@ietf.org" , "Chenxin \(Xin\)" Subject: Re: [tram] About that charter... 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, 26 Nov 2013 09:35:07 -0000 --001a11c218ae036f4d04ec113219 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I am not sure that we want here anybody for whom WebRTC is a red flag. I am not sure that we can have a healthy discussion here, then. I think that WebRTC behind all this TURN evolution. We are not going to sneak TURN into the enterprise; the enterprise will adopt WebRTC - and this is how TURN will be included into the enterprise infrastructure. I believe that this is the only realistic scenario of TURN inclusion into the enterprise. On Tue, Nov 26, 2013 at 1:27 AM, Pal Martinsen (palmarti) < palmarti@cisco.com> wrote: > > On 26 Nov 2013, at 10:08 am, Chenxin (Xin) > wrote: > > > Hi Pal, > > > > > >> -----Original Message----- > >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Pal Martinsen > >> (palmarti) > >> Sent: Tuesday, November 26, 2013 5:03 PM > >> To: Simon Perreault > >> Cc: tram@ietf.org > >> Subject: Re: [tram] About that charter... > >> > >> Hi, > >> > >> On 22 Nov 2013, at 16:14 pm, Simon Perreault < > simon.perreault@viagenie.ca> > >> wrote: > >> > >>> Are we done discussing it? What are the next steps? > >>> > >>> As a reminder, the current version is here: > >>> https://github.com/petithug/tram-charter/blob/master/charter.txt > >>> > >> I think the charter looks good. > >> > >> Being a new-bee regarding charters I have a few questions and comments= . > >> > >> The first section is rather long and describes the background in > length. Is the > >> text in the first section at all necessary in a charter? > >> > >> Can we add something around cloud in section three? For example: > >> " - that make STUN and TURN more suitable for WebRTC and Cloud like > >> environments." > >> > >> TRAM would also benefit more traditional enterprise deployments. By > using the > >> word "cloud" the charter can get some attention from that camp as well= . > >> > >> Consider these comments as nits. > > > > Could you give some detailed requirements and considerations about the > "cloud"?that will be more helpful. It will be better this could be get > benefit from or affect the deliverables. > > > You are right about cloud being a bit fuzzy, and it might not bee a good > idea to add buzzwords to the charter. > > My goal was to add a word or short sentence getting the attention of the > more traditional enterprise folks. As the charter describes in the first > section ICE and TURN was slow to be adopted. Adding security, > authentication, manageability, mobility ,QoS ++ extensions to TURN will > hopefully lead to more enterprises deploying TURN. Getting more =93featur= e=94 > parity between enterprise and RTCWEB deployment would benefit all. Having > some wording stating that this is also intended for enterprise might help= . > > This is just word smithing to avoid enterprise folks that just see a red > flag whenever RTCWEB is mentioned to be more happy. > > .-. > P=E5l-Erik > > > Best Regards, > > Xin > > > >> > >> .-. > >> P=E5l-Erik > >> > >> > >>> 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 > >> > >> _______________________________________________ > >> 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 > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --001a11c218ae036f4d04ec113219 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I am not sure that we want here anybody for whom WebR= TC is a red flag. I am not sure that we can have a healthy discussion here,= then.

I think that WebRTC behind all this TURN evolution. We = are not going to sneak TURN into the enterprise; the enterprise will adopt = WebRTC - and this is how TURN will be included into the enterprise infrastr= ucture. I believe that this is the only realistic scenario of TURN inclusio= n into the enterprise.



On = Tue, Nov 26, 2013 at 1:27 AM, Pal Martinsen (palmarti) &l= t;palmarti@cisco.co= m> wrote:

On 26 Nov 2013, at 10:08 am, Chenxin (Xin) <hangzhou.chenxin@huawei.com> wrote:

> Hi Pal,
>
>
>> -----Original Message-----
>> From: tram [mailto:tram-b= ounces@ietf.org] On Behalf Of Pal Martinsen
>> (palmarti)
>> Sent: Tuesday, November 26, 2013 5:03 PM
>> To: Simon Perreault
>> Cc: tram@ietf.org
>> Subject: Re: [tram] About that charter...
>>
>> Hi,
>>
>> On 22 Nov 2013, at 16:14 pm, Simon Perreault <simon.perreault@viagenie.ca>
>> wrote:
>>
>>> Are we done discussing it? What are the next steps?
>>>
>>> As a reminder, the current version is here:
>>> https://github.com/petithug/tram-charter/b= lob/master/charter.txt
>>>
>> I think the charter looks good.
>>
>> Being a new-bee regarding charters I have a few questions and comm= ents.
>>
>> The first section is rather long and describes the background in l= ength. Is the
>> text in the first section at all necessary in a charter?
>>
>> Can we add something around cloud in section three? For example: >> " - that make STUN and TURN more suitable for WebRTC and Clou= d like
>> environments."
>>
>> TRAM would also benefit more traditional enterprise deployments. B= y using the
>> word "cloud" the charter can get some attention from tha= t camp as well.
>>
>> Consider these comments as nits.
>
> Could you give some detailed requirements and considerations about the= "cloud"?that will be more helpful. It will be better this could = be get benefit from or affect the deliverables.
>
You are right about cloud being a bit fuzzy, and it might not b= ee a good idea to add buzzwords to the charter.

My goal was to add a word or short sentence getting the attention of the mo= re traditional enterprise folks. As the charter describes in the first sect= ion ICE and TURN was slow to be adopted. Adding security, authentication, m= anageability, mobility ,QoS =A0++ extensions to TURN will hopefully lead to= more enterprises deploying TURN. Getting more =93feature=94 parity between= enterprise and RTCWEB deployment would benefit all. Having some wording st= ating that this is also intended for enterprise might help.

This is just word smithing to avoid enterprise folks that just see a red fl= ag whenever RTCWEB is mentioned to be more happy.

.-.
P=E5l-Erik

> Best Regards,
> =A0 =A0 Xin
>
>>
>> .-.
>> P=E5l-Erik
>>
>>
>>> 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
>>> https://www.ietf.org/mailman/listinfo/tram
>>
>> _______________________________________________
>> 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

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

--001a11c218ae036f4d04ec113219-- From mom040267@gmail.com Tue Nov 26 01:39:10 2013 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 4A2CE1AD939 for ; Tue, 26 Nov 2013 01:39:10 -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 W7jv-ZMhAIUG for ; Tue, 26 Nov 2013 01:39:09 -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 75C161A1F55 for ; Tue, 26 Nov 2013 01:39:09 -0800 (PST) Received: by mail-pb0-f41.google.com with SMTP id jt11so7725809pbb.0 for ; Tue, 26 Nov 2013 01:39:09 -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=pu22oVqNEcSm9LDGqH8DtKSlgSHc8vEBgZo3efKvmGg=; b=hatE/kEg+TTVnc2Zl2GxHZ2UMGhDGZLiL0qFGP0k6UQnxHkfW62YeA3Qo/7u9pWp7W 3rPfXVqDlCoduPTk2PQjp937dQbjtZECjADQIMCAebaeBWADTkHKyK4lsUUjP4PlLjhQ V/1LOTrdvn2YqMU32RuUUDb4l85kolIL6doSRoJ8Auuj/3+Dbk5uqRDdZN8EEdhKSHm6 J8weuHMRxhREbY6LkHxp1o0FwLrlqASPwFo/+bR0N8R/9B2yVy/aknIJe7he4viXfYHR rf+Sjmiw0kRzEfplVYcKIs6hu1eKuKDx/YMBrLFoCYRDQenOZFgbF1+2wzDiUpyGgvZ7 1fpg== MIME-Version: 1.0 X-Received: by 10.66.26.106 with SMTP id k10mr8540550pag.136.1385458749077; Tue, 26 Nov 2013 01:39:09 -0800 (PST) Received: by 10.68.147.131 with HTTP; Tue, 26 Nov 2013 01:39:08 -0800 (PST) In-Reply-To: <2A412C79-7200-4730-837F-F44A2618E8F1@cisco.com> References: <528F74EF.6030903@viagenie.ca> <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> <2A412C79-7200-4730-837F-F44A2618E8F1@cisco.com> Date: Tue, 26 Nov 2013 01:39:08 -0800 Message-ID: From: Oleg Moskalenko To: "Pal Martinsen (palmarti)" Content-Type: multipart/alternative; boundary=bcaec520f2e396feec04ec114058 Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] About that charter... 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, 26 Nov 2013 09:39:10 -0000 --bcaec520f2e396feec04ec114058 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 26, 2013 at 1:33 AM, Pal Martinsen (palmarti) < palmarti@cisco.com> wrote: > > > > For many engineers, "cloud" is a non-technical term, for managers only. > But this is supposed to be a very technical list. > > Agree. But it still be nice with some wording to get the more > traditional enterprise folks onboard. > That's fine, unless it sounds like "cloud-ready hard disks" or similar. --bcaec520f2e396feec04ec114058 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Nov 26, 2013 at 1:33 AM, Pal Martinsen (palmarti) <palmar= ti@cisco.com> wrote:



For many engineers, "cloud" is a non-technical term, for managers= only. But this is supposed to be a very technical list.

Agree. But it still be nice with some wording to get the more tr= aditional enterprise folks onboard.

=
That's fine, unless it sounds like "cloud-ready har= d disks" or similar.
=A0

--bcaec520f2e396feec04ec114058-- From andrew.hutton@unify.com Tue Nov 26 06:13:48 2013 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 D21881ADAEA for ; Tue, 26 Nov 2013 06:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 WKFyev36DNNq for ; Tue, 26 Nov 2013 06:13:47 -0800 (PST) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF9B1ADA74 for ; Tue, 26 Nov 2013 06:13:47 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id 238EB1EB85A8; Tue, 26 Nov 2013 15:13:46 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.69]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Tue, 26 Nov 2013 15:13:45 +0100 From: "Hutton, Andrew" To: "Pal Martinsen (palmarti)" , "Chenxin (Xin)" Thread-Topic: [tram] About that charter... Thread-Index: AQHO55WfTd9RE1BeuEK0ppIp9j/Hi5o3LL4AgAABaACAAAVJgIAAW5Zw Date: Tue, 26 Nov 2013 14:13:45 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17C55B08@MCHP04MSX.global-ad.net> References: <528F74EF.6030903@viagenie.ca> <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> <9E34D50A21D1D1489134B4D770CE0397680A17E1@SZXEMA504-MBX.china.huawei.com> <0B33EFFA-CBED-4041-9D2C-6625C5CC67C0@cisco.com> In-Reply-To: <0B33EFFA-CBED-4041-9D2C-6625C5CC67C0@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] About that charter... 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, 26 Nov 2013 14:13:49 -0000 On: 26 November 2013 09:27 Pal Martinsen Wrote: >=20 > My goal was to add a word or short sentence getting the attention of > the more traditional enterprise folks.=20 Not sure what is meant by "more traditional enterprise folks" but I think t= he group will get the attention it needs. > As the charter describes in the > first section ICE and TURN was slow to be adopted. Adding security, > authentication, manageability, mobility ,QoS ++ extensions to TURN > will hopefully lead to more enterprises deploying TURN.=20 > Many of the items mentioned here are actually not in the charter (i.e. mana= geability, mobility, QoS) and I also heard one the "traditional enterprise = folks" talking about bandwidth management which is also not currently in th= e charter. So maybe we need some more work on the charter or maybe what we= need is to put together a requirements document and make that the first mi= lestone. > Getting more > "feature" parity between enterprise and RTCWEB deployment would benefit > all. Having some wording stating that this is also intended for > enterprise might help. > I don't know what is meant by "feature parity between enterprise and RTCWEB= " but I would support a statement in the charter indicating that the work o= f the group will include adding functionality to TURN to allow the TURN ser= ver to enforce policy on WebRTC traffic such as those typically required in= an enterprise deployment. >=20 > This is just word smithing to avoid enterprise folks that just see a > red flag whenever RTCWEB is mentioned to be more happy. >=20 Such folks should be and deserve to be ignored ;-). Regards Andy From simon.perreault@viagenie.ca Tue Nov 26 06:18:22 2013 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 5EB771AE1F7 for ; Tue, 26 Nov 2013 06:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 HMm-BCwBqM5O for ; Tue, 26 Nov 2013 06:18:20 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A07691ADBC7 for ; Tue, 26 Nov 2013 06:18:20 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:8c9f:4cb8:2f97:3aa9]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0788E403C8; Tue, 26 Nov 2013 09:18:19 -0500 (EST) Message-ID: <5294ADAB.9030402@viagenie.ca> Date: Tue, 26 Nov 2013 09:18:19 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Hutton, Andrew" , "Pal Martinsen (palmarti)" , "Chenxin (Xin)" References: <528F74EF.6030903@viagenie.ca> <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> <9E34D50A21D1D1489134B4D770CE0397680A17E1@SZXEMA504-MBX.china.huawei.com> <0B33EFFA-CBED-4041-9D2C-6625C5CC67C0@cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF17C55B08@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17C55B08@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "tram@ietf.org" Subject: Re: [tram] About that charter... 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, 26 Nov 2013 14:18:22 -0000 Le 2013-11-26 09:13, Hutton, Andrew a écrit : >> As the charter describes in the first section ICE and TURN was slow >> to be adopted. Adding security, authentication, manageability, >> mobility ,QoS ++ extensions to TURN will hopefully lead to more >> enterprises deploying TURN. > > Many of the items mentioned here are actually not in the charter > (i.e. manageability, mobility, QoS) and I also heard one the > "traditional enterprise folks" talking about bandwidth management > which is also not currently in the charter. So maybe we need some > more work on the charter or maybe what we need is to put together a > requirements document and make that the first milestone. Creating a working group is not a PR stunt. We have people here who want to work on real problems. So we write a charter about those problems and the work that needs to be done. It's as simple as that. If/when new people come to this group with "enterprise" problems, solution proposals, and the energy to work on it, I'll be happy to propose a recharter to include the new stuff. Any charter should always be about stuff we know we can and will fix. 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 andrew.hutton@unify.com Tue Nov 26 06:34:01 2013 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 8D9D21AE211 for ; Tue, 26 Nov 2013 06:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 gsrH8ZVJ62X8 for ; Tue, 26 Nov 2013 06:34:00 -0800 (PST) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4874C1AD958 for ; Tue, 26 Nov 2013 06:33:57 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id E305F1EB8593; Tue, 26 Nov 2013 15:33:56 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.69]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Tue, 26 Nov 2013 15:33:56 +0100 From: "Hutton, Andrew" To: Simon Perreault , "Pal Martinsen (palmarti)" , "Chenxin (Xin)" Thread-Topic: [tram] About that charter... Thread-Index: AQHO55WfTd9RE1BeuEK0ppIp9j/Hi5o3LL4AgAABaACAAAVJgIAAW5Zw///1wYCAABG8IA== Date: Tue, 26 Nov 2013 14:33:56 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17C55B90@MCHP04MSX.global-ad.net> References: <528F74EF.6030903@viagenie.ca> <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> <9E34D50A21D1D1489134B4D770CE0397680A17E1@SZXEMA504-MBX.china.huawei.com> <0B33EFFA-CBED-4041-9D2C-6625C5CC67C0@cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF17C55B08@MCHP04MSX.global-ad.net> <5294ADAB.9030402@viagenie.ca> In-Reply-To: <5294ADAB.9030402@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tram@ietf.org" Subject: Re: [tram] About that charter... 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, 26 Nov 2013 14:34:01 -0000 Hi Simon, I was simply pointing out that many of the items Pal seemed to assume the g= roup would cover are not in the charter. However creating a charter is never that simple and we are already aware of= work that people want to do in this group which is not explicitly mentione= d in the charter. =20 So when somebody comes to the group with a draft on adding some kind of ban= dwidth parameter to TURN then I would be preferable for this to be a matter= of adding a new milestone rather than rewriting the charter. The charter s= hould not be so closed that it can be used to argue against other ideas bei= ng put forward otherwise we will end up with a TRAM2 and a TRAM3 working gr= oup. Regards Andy > -----Original Message----- > From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > Sent: 26 November 2013 14:18 > To: Hutton, Andrew; Pal Martinsen (palmarti); Chenxin (Xin) > Cc: tram@ietf.org > Subject: Re: [tram] About that charter... >=20 > Le 2013-11-26 09:13, Hutton, Andrew a =E9crit : > >> As the charter describes in the first section ICE and TURN was slow > >> to be adopted. Adding security, authentication, manageability, > >> mobility ,QoS ++ extensions to TURN will hopefully lead to more > >> enterprises deploying TURN. > > > > Many of the items mentioned here are actually not in the charter > > (i.e. manageability, mobility, QoS) and I also heard one the > > "traditional enterprise folks" talking about bandwidth management > > which is also not currently in the charter. So maybe we need some > > more work on the charter or maybe what we need is to put together a > > requirements document and make that the first milestone. >=20 > Creating a working group is not a PR stunt. We have people here who > want > to work on real problems. So we write a charter about those problems > and > the work that needs to be done. It's as simple as that. >=20 > If/when new people come to this group with "enterprise" problems, > solution proposals, and the energy to work on it, I'll be happy to > propose a recharter to include the new stuff. >=20 > Any charter should always be about stuff we know we can and will fix. >=20 > 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 michael.hammer@yaanatech.com Tue Nov 26 06:48:55 2013 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 A4C831ADD9A for ; Tue, 26 Nov 2013 06:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 zWotOnnXoBiQ for ; Tue, 26 Nov 2013 06:48:53 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 5559C1AD8F0 for ; Tue, 26 Nov 2013 06:48:53 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 26 Nov 2013 06:48:53 -0800 From: Michael Hammer To: "mom040267@gmail.com" , "palmarti@cisco.com" Thread-Topic: [tram] About that charter... Thread-Index: AQHO55WfbffrtT7yeUuLIaJ6fGUSpZo3w54AgAAE24CAAAOeAIAAAY8A///PV9A= Date: Tue, 26 Nov 2013 14:48:52 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBEFDF59@sc9-ex2k10mb1.corp.yaanatech.com> References: <528F74EF.6030903@viagenie.ca> <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> <2A412C79-7200-4730-837F-F44A2618E8F1@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.244] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0024_01CEEA8C.B62BAE00" MIME-Version: 1.0 Cc: "simon.perreault@viagenie.ca" , "tram@ietf.org" Subject: Re: [tram] About that charter... 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, 26 Nov 2013 14:48:55 -0000 ------=_NextPart_000_0024_01CEEA8C.B62BAE00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0025_01CEEA8C.B62BAE00" ------=_NextPart_001_0025_01CEEA8C.B62BAE00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Could you clarify whether the "cloud" elements are part of the problem (apps in cloud will find themselves behind restrictive NATs) or part of the solution (TURN servers hosted in the cloud) or an innocent bystander collateral damage (cloud users or suppliers need to do something)? Mike From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko Sent: Tuesday, November 26, 2013 4:39 AM To: Pal Martinsen (palmarti) Cc: Simon Perreault; tram@ietf.org Subject: Re: [tram] About that charter... On Tue, Nov 26, 2013 at 1:33 AM, Pal Martinsen (palmarti) wrote: For many engineers, "cloud" is a non-technical term, for managers only. But this is supposed to be a very technical list. Agree. But it still be nice with some wording to get the more traditional enterprise folks onboard. That's fine, unless it sounds like "cloud-ready hard disks" or similar. ------=_NextPart_001_0025_01CEEA8C.B62BAE00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Could you clarify whether the “cloud” elements are =

part of the problem (apps in cloud will find themselves behind = restrictive NATs) or

part of the solution (TURN servers hosted in the cloud) or =

an innocent bystander collateral damage (cloud users or suppliers = need to do something)?

 

Mike

 

 

From:= = tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg = Moskalenko
Sent: Tuesday, November 26, 2013 4:39 = AM
To: Pal Martinsen (palmarti)
Cc: Simon Perreault; = tram@ietf.org
Subject: Re: [tram] About that = charter...

 

 

 

On Tue, Nov 26, 2013 at 1:33 AM, Pal Martinsen = (palmarti) <palmarti@cisco.com> = wrote:

 



 

For = many engineers, "cloud" is a non-technical term, for managers = only. But this is supposed to be a very technical = list.

 

Agree. But it still be nice with some wording to get = the more traditional enterprise folks = onboard.

 

That's fine, unless it sounds like "cloud-ready = hard disks" or similar.

 

 

------=_NextPart_001_0025_01CEEA8C.B62BAE00-- ------=_NextPart_000_0024_01CEEA8C.B62BAE00 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTEy NjE0NDg1MVowIwYJKoZIhvcNAQkEMRYEFGYGCW5SzeE7hzlXgSISz5CSxtP8MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEALz85bTAmtUqZzGM6tjkE7Pb2Sxx3waCmyAZi3KPO WL5yyh1u+5igY0DnnyD0PXLSXDjv61G7HKKNPIi57Cc0oBRIDc4FyJMP7TRLQXoBgghLnFVcrnmq q0emgWqk4wNzKmluqP1DTBXmMisBc11AfOHlHDoY794Ak4NNZLvgI175ZxGGDnNtqS1BVEp+DlK2 xbbnhDlrSBPxcaqFrT5jjS7rAOMgPHLe2Kqp4oZuDjO0G30/6EZ6cDjDGi46m0pzWl2yAVN8CjY/ HSkbSgLUNR504wZb81UbN8dpzW6qmmTJlWGHpEgGrhabawX5o6/G4njRyRSmySsqLAxYBUhPTgAA AAAAAA== ------=_NextPart_000_0024_01CEEA8C.B62BAE00-- From melinda.shore@gmail.com Tue Nov 26 06:59:34 2013 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 D81B81AC85E for ; Tue, 26 Nov 2013 06:59:34 -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 rP0tgDxccZlB for ; Tue, 26 Nov 2013 06:59:33 -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 A6BA11AC4C1 for ; Tue, 26 Nov 2013 06:59:33 -0800 (PST) Received: by mail-pd0-f172.google.com with SMTP id g10so7814898pdj.31 for ; Tue, 26 Nov 2013 06:59:33 -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=5bHsOc4ajUQHbYV2fQ/iTGtP1I+cTlK/ku1T/X5yBWk=; b=CofHP2FbZ+rnV8CfWlL5LjNiEI9Ivjjwz6XcmXf2TYD3hZKF34MGhhqGEDYcSB3pYx 9vj64I54v9s2BMKQCq8yYsGy+l7eIWVIdq78zBENfQGIkDtweUBQmAYF2ANFJCkklqcT hvqAEJYELvC91nzTbqQW3bHikDn5rXtKGp0PaejmbXe+Jf+SWgCSxVRzrcOErWiGTWAp 1d2Oncbh1TSpqaW91wOCXU9urounn+s4B2C5jMmyjk7Jfhx+JuuP6KhuB5FCnVW2eSu5 ba6DZywCq13N8WS8AzJirtTI12E0pqVcaW2g4/uRIU85gAoNFjpMxT2gWuhaUbjaLq87 eFtA== X-Received: by 10.66.7.68 with SMTP id h4mr36581121paa.0.1385477970083; Tue, 26 Nov 2013 06:59:30 -0800 (PST) Received: from spandex.local (216-67-62-197-rb3.nwc.dsl.dynamic.acsalaska.net. [216.67.62.197]) by mx.google.com with ESMTPSA id ki1sm81241874pbd.1.2013.11.26.06.59.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Nov 2013 06:59:29 -0800 (PST) Message-ID: <5294B74E.9060107@gmail.com> Date: Tue, 26 Nov 2013 05:59:26 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: tram@ietf.org References: <528F74EF.6030903@viagenie.ca> <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> In-Reply-To: <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [tram] About that charter... 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, 26 Nov 2013 14:59:35 -0000 On 11/26/13 12:03 AM, Pal Martinsen (palmarti) wrote: > TRAM would also benefit more traditional enterprise deployments. By > using the word “cloud” the charter can get some attention from that > camp as well. I think that if there's interest in enterprise deployments it's probably a good idea, in terms of getting the charter through the process, to spell out explicitly which features would be needed, distinct from a CPE deployment. I tend to think that targeting enterprises *right now* would be a mistake, since they're the ones who tend to have the most rigid policies around network boundary traversal and those policies are often driven out of the corporate auditor's department. I'd let webrtc lead the deployment and have network administrators discover that they've got a problem. Melinda From gsalguei@cisco.com Tue Nov 26 07:59:40 2013 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 D01401AD9AD for ; Tue, 26 Nov 2013 07:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 6MyR_kNPFt1x for ; Tue, 26 Nov 2013 07:59:39 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 712091AD8F3 for ; Tue, 26 Nov 2013 07:59:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1099; q=dns/txt; s=iport; t=1385481579; x=1386691179; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=B0deabkC1S06NxlOqbAp686EWgC97k/LtWVGz9T/DGg=; b=jev8Y/TlYAUnO1PVwIqai7oTUjJofPF1gMi9y4+tsHBYZyevsFZu04O/ VV0FD3KpSe4dp9zvCaXfaLdTFh1757KFaLA+qVXYjeAReW95WSMq7F8Ys dNUANBYoYJJLcg6BUBhk4ZBZdyfQJmojxjTFmh1NJoMs4o/F3AJPo0pbX g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFACXElFKtJXG9/2dsb2JhbABZgwc4U7pngSsWdIIlAQEBAwEBAQFrCwULAgEIGC4hBgslAgQOBYdvAwkGDbdBDYdwEwSMbIIQB4MggRMDlimBa4xahTiDKIIq X-IronPort-AV: E=Sophos;i="4.93,775,1378857600"; d="scan'208";a="287637791" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 26 Nov 2013 15:59:39 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAQFxd9S024635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Nov 2013 15:59:39 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.232]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 26 Nov 2013 09:59:38 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Melinda Shore Thread-Topic: [tram] About that charter... Thread-Index: AQHO55WgRfpIk1mRGE+o3lF1R10UuZo3ohcAgABjhQCAABDSAA== Date: Tue, 26 Nov 2013 15:59:38 +0000 Message-ID: <5673F4ED-61CD-4C3E-A6A4-C51DB96C40AE@cisco.com> References: <528F74EF.6030903@viagenie.ca> <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> <5294B74E.9060107@gmail.com> In-Reply-To: <5294B74E.9060107@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.132.52] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tram@ietf.org" Subject: Re: [tram] About that charter... 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, 26 Nov 2013 15:59:41 -0000 I agree. Gonzalo On Nov 26, 2013, at 9:59 AM, Melinda Shore wrote: > On 11/26/13 12:03 AM, Pal Martinsen (palmarti) wrote: >> TRAM would also benefit more traditional enterprise deployments. By >> using the word =93cloud=94 the charter can get some attention from that >> camp as well. >=20 > I think that if there's interest in enterprise deployments it's > probably a good idea, in terms of getting the charter through > the process, to spell out explicitly which features would > be needed, distinct from a CPE deployment. I tend to think > that targeting enterprises *right now* would be a mistake, > since they're the ones who tend to have the most rigid policies > around network boundary traversal and those policies are > often driven out of the corporate auditor's department. > I'd let webrtc lead the deployment and have network administrators > discover that they've got a problem. >=20 > Melinda > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From andrew.hutton@unify.com Tue Nov 26 08:20:16 2013 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 673461ADDBF for ; Tue, 26 Nov 2013 08:20:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 2Kpws8DzMbRf for ; Tue, 26 Nov 2013 08:20:14 -0800 (PST) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 015AF1AD8F1 for ; Tue, 26 Nov 2013 08:20:13 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id 198981EB85D0; Tue, 26 Nov 2013 17:20:13 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.69]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Tue, 26 Nov 2013 17:20:12 +0100 From: "Hutton, Andrew" To: Melinda Shore , "tram@ietf.org" Thread-Topic: [tram] About that charter... Thread-Index: AQHO55WfTd9RE1BeuEK0ppIp9j/Hi5o3LL4AgABjhQCAACPMAA== Date: Tue, 26 Nov 2013 16:20:11 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17C56055@MCHP04MSX.global-ad.net> References: <528F74EF.6030903@viagenie.ca> <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> <5294B74E.9060107@gmail.com> In-Reply-To: <5294B74E.9060107@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tram] About that charter... 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, 26 Nov 2013 16:20:16 -0000 On: 26 November 2013 14:59 Melinda Shore Wrote: >=20 > I think that if there's interest in enterprise deployments it's > probably a good idea, in terms of getting the charter through > the process, to spell out explicitly which features would > be needed, distinct from a CPE deployment. I tend to think > that targeting enterprises *right now* would be a mistake, > since they're the ones who tend to have the most rigid policies > around network boundary traversal and those policies are > often driven out of the corporate auditor's department. > I'd let webrtc lead the deployment and have network administrators > discover that they've got a problem. >=20 What do you mean by "let webrtc lead the deployment"? WebRTC specifically includes deployments where the webrtc client is behind = firewalls this is explicit in the charter and http://tools.ietf.org/html/dr= aft-ietf-rtcweb-use-cases-and-requirements-12 which also explicitly mention= s restricted enterprise deployments.=20 Personally I would like to start developing the tools and provide informati= on to help network administrators before they discover they have a problem = with webrtc. Andy From melinda.shore@gmail.com Tue Nov 26 08:28:23 2013 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 709071ACC91 for ; Tue, 26 Nov 2013 08:28:23 -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 MbgJo2IdHFvu for ; Tue, 26 Nov 2013 08:28:22 -0800 (PST) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3921A1AC85E for ; Tue, 26 Nov 2013 08:28:22 -0800 (PST) Received: by mail-pd0-f177.google.com with SMTP id q10so7959079pdj.22 for ; Tue, 26 Nov 2013 08:28:22 -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:content-transfer-encoding; bh=bMvysO3HL+4AO3rsM23anRsN6RCuQJmCEx4JGKayigo=; b=G6TFfSbX5nJ25kao1uJU9hPxVjcntPtkjU7lDojmUF+q84/iKhTEp2D18FExOM+Gq6 O565Tx59J1YDkT4XjdhOvbI7aDPmkjyRAybKRkl7RfFEx+3heIEZsdYlk3saTTKjzwBy BKKmcJNxkqJDQTtZ67ziKnj7w/6ncYSZ6cH7DelC7Ow/OK+yI5NNipIuneiwDaPdhjOo OjMXpsYB45/PL1CL2NGEAqVHwhwQcoFPblDImrNO27DcjJIDo4ieHKk3kLYlUmSiYV8g D/ZceN5fo4qBua7QaCM7WqYs0JvIdofEoRgSJk1aX1A7IQrks44CS3T2gJIw7mtJhNep wgqw== X-Received: by 10.66.142.170 with SMTP id rx10mr16935317pab.117.1385483302156; Tue, 26 Nov 2013 08:28:22 -0800 (PST) Received: from spandex.local (216-67-62-197-rb3.nwc.dsl.dynamic.acsalaska.net. [216.67.62.197]) by mx.google.com with ESMTPSA id ik1sm54898209pbc.9.2013.11.26.08.28.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Nov 2013 08:28:21 -0800 (PST) Message-ID: <5294CC22.90703@gmail.com> Date: Tue, 26 Nov 2013 07:28:18 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Hutton, Andrew" References: <528F74EF.6030903@viagenie.ca> <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> <5294B74E.9060107@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17C56055@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17C56055@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tram@ietf.org" Subject: Re: [tram] About that charter... 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, 26 Nov 2013 16:28:23 -0000 On 11/26/13 7:20 AM, Hutton, Andrew wrote: > Personally I would like to start developing the tools and provide > information to help network administrators before they discover they > have a problem with webrtc. Do you need specific reference to enterprise deployments to do that? I didn't think so. In the meantime, if you go out there and tell people who are dealing with corporate policies driven out of the auditor's office that you're going to poke holes in their firewalls using a mechanism that's not managed under enterprise security policy, you're going to hit resistance before you even start. As you may have noticed. I'd leave any reference to enterprise networks out of the charter. Melinda From andrew.hutton@unify.com Tue Nov 26 08:47:47 2013 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 79F661AD8F0 for ; Tue, 26 Nov 2013 08:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 5fXL6EZf5FVP for ; Tue, 26 Nov 2013 08:47:46 -0800 (PST) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE271A1F55 for ; Tue, 26 Nov 2013 08:47:46 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id E92371EB8505; Tue, 26 Nov 2013 17:47:45 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.69]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Tue, 26 Nov 2013 17:47:45 +0100 From: "Hutton, Andrew" To: Melinda Shore Thread-Topic: [tram] About that charter... Thread-Index: AQHO55WfTd9RE1BeuEK0ppIp9j/Hi5o3LL4AgABjhQCAACPMAP//9QkAgAASqCA= Date: Tue, 26 Nov 2013 16:47:44 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17C5612D@MCHP04MSX.global-ad.net> References: <528F74EF.6030903@viagenie.ca> <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> <5294B74E.9060107@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17C56055@MCHP04MSX.global-ad.net> <5294CC22.90703@gmail.com> In-Reply-To: <5294CC22.90703@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tram@ietf.org" Subject: Re: [tram] About that charter... 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, 26 Nov 2013 16:47:47 -0000 On: 26 November 2013 16:28 Melinda Shore Wrote: >=20 > On 11/26/13 7:20 AM, Hutton, Andrew wrote: > > Personally I would like to start developing the tools and provide > > information to help network administrators before they discover they > > have a problem with webrtc. >=20 > Do you need specific reference to enterprise deployments > to do that? I didn't think so. =20 I agree but we need the charter to broad enough to include putting some pol= icy control in to the TURN server and to be clear I am not talking about fi= rewall policy here. Just some things that have previously been mentioned li= ke bandwidth, QoS, Mobility, and some things we might not have thought of y= et. > In the meantime, if > you go out there and tell people who are dealing with > corporate policies driven out of the auditor's office that > you're going to poke holes in their firewalls using a > mechanism that's not managed under enterprise security > policy, you're going to hit resistance before you even > start. As you may have noticed. Also agree this is not about poking holes in firewalls and the work to defi= ne how webrtc works properly within an enterprise security policy will evid= ently not take place in this working group, we still need a home for that. >=20 > I'd leave any reference to enterprise networks out of the > charter. >=20 I am ok with that. From simon.perreault@viagenie.ca Tue Nov 26 08:50:04 2013 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 512821ADEBB for ; Tue, 26 Nov 2013 08:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 VC52Ll3Wt0lP for ; Tue, 26 Nov 2013 08:50:03 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id DEFE51A1F55 for ; Tue, 26 Nov 2013 08:50:02 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:8c9f:4cb8:2f97:3aa9]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8DA7E403BA for ; Tue, 26 Nov 2013 11:50:02 -0500 (EST) Message-ID: <5294D13A.8050508@viagenie.ca> Date: Tue, 26 Nov 2013 11:50:02 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: tram@ietf.org References: <528F74EF.6030903@viagenie.ca> <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> <5294B74E.9060107@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17C56055@MCHP04MSX.global-ad.net> <5294CC22.90703@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17C5612D@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17C5612D@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [tram] About that charter... 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, 26 Nov 2013 16:50:04 -0000 Le 2013-11-26 11:47, Hutton, Andrew a écrit : > I agree but we need the charter to broad enough to include putting some policy control in to the TURN server and to be clear I am not talking about firewall policy here. Just some things that have previously been mentioned like bandwidth, QoS, Mobility, and some things we might not have thought of yet. Please propose actual text changes. The current charter is at https://github.com/petithug/tram-charter/blob/master/charter.txt Just say exactly how you would like to see it changed. The RFC Editor notation "OLD:... NEW:..." would be fine. Thanks, 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 Tue Nov 26 09:02:27 2013 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 7AE9F1ADF23 for ; Tue, 26 Nov 2013 09:02:27 -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 OmFK_lFtaXeO for ; Tue, 26 Nov 2013 09:02:25 -0800 (PST) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id EBAE01ADEAE for ; Tue, 26 Nov 2013 09:02:24 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id er20so4369348lab.8 for ; Tue, 26 Nov 2013 09:02:24 -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=cMBl3RkFkFYuyElEvA3eO/ETcPcqn25aTGMPZR1rSyQ=; b=adsyLRL5DQ3cPvp9mDtYLIQBI1nhzGUTFdrbXyG2yYyk5J/gh/SdCQouKXlUxka7pM tIy6VmRuaph4fNx+ZZQBVcgWO9xD42/3GIt6nQv3oyFYnykb2TeF8n91hPTf/mzPVvet G5alRG8+Vxh2yJM44bT9X17OrYp7kxCxAYyglFrNCuTyOrqXC1Upk7JCoEcNgVOYKbgm RZ7CDYUTVzqfNx58787v0me/nj9yXoI5eGIXSccIB5aI2DewmYthQaXeE5kMzNjoWDqh Cdi8RB9Je9BKhEmoWeW6Ql3GkvxcJm/Q/rWL0I4jt8jOpGC2GHRUAjj9cPINe6lle4Za Eryw== MIME-Version: 1.0 X-Received: by 10.112.146.135 with SMTP id tc7mr76167lbb.63.1385485344016; Tue, 26 Nov 2013 09:02:24 -0800 (PST) Received: by 10.152.180.1 with HTTP; Tue, 26 Nov 2013 09:02:23 -0800 (PST) In-Reply-To: References: <528F74EF.6030903@viagenie.ca> <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> Date: Tue, 26 Nov 2013 11:02:23 -0600 Message-ID: From: Spencer Dawkins at IETF To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=047d7b343642c58f3b04ec17713d Cc: Simon Perreault , "Pal Martinsen \(palmarti\)" , "tram@ietf.org" Subject: Re: [tram] About that charter... 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, 26 Nov 2013 17:02:27 -0000 --047d7b343642c58f3b04ec17713d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm not speaking as an AD, but I am speaking as a retired IAB member who was watching a year-long effort to charter something (well, really, anything) in the cloud space. My suggestion would be to figure out specifically what part of "cloud" is relevant to what you're proposing, and point to something more specific. For example, the data center parts of "cloud" started getting more traction when they were called out specifically. The IESG (at that time) wasn't opposed to doing something that would be helpful for clouds, but they weren't getting proposals for specific protocol work, and that's pretty much what the IETF does ... Spencer On Tuesday, November 26, 2013, Oleg Moskalenko wrote: > If we add word "porn" it will attract even more attention. > > For many engineers, "cloud" is a non-technical term, for managers only. > But this is supposed to be a very technical list. > > > On Tue, Nov 26, 2013 at 1:03 AM, Pal Martinsen (palmarti) < > palmarti@cisco.com >wro= te: > >> Hi, >> >> On 22 Nov 2013, at 16:14 pm, Simon Perreault > >> wrote: >> >> > Are we done discussing it? What are the next steps? >> > >> > As a reminder, the current version is here: >> > https://github.com/petithug/tram-charter/blob/master/charter.txt >> > >> I think the charter looks good. >> >> Being a new-bee regarding charters I have a few questions and comments. >> >> The first section is rather long and describes the background in length. >> Is the text in the first section at all necessary in a charter? >> >> Can we add something around cloud in section three? For example: >> =93 =97 that make STUN and TURN more suitable for WebRTC and Cloud like >> environments.=94 >> >> TRAM would also benefit more traditional enterprise deployments. By usin= g >> the word =93cloud=94 the charter can get some attention from that camp a= s well. >> >> Consider these comments as nits. >> >> .-. >> P=E5l-Erik >> >> >> > 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 >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> > > --047d7b343642c58f3b04ec17713d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm not speaking as an AD, but I am speaking as a retired IAB member wh= o was watching=A0a year-long effort to charter something (well, really, any= thing) in the cloud space.

My suggestion would be to fig= ure out specifically what part of "cloud" is relevant to what you= 're proposing, and point to something more specific. For example, the d= ata center parts of "cloud" started getting more traction when th= ey were called out specifically.

The IESG (at that time) wasn't opposed to doing som= ething that would be helpful for clouds, but they weren't getting propo= sals for specific protocol work, and that's pretty much=A0what=A0the IE= TF does=A0...

Spencer

On Tuesday, November 26, 2013, Oleg Mosk= alenko wrote:
If w= e add word "porn" it will attract even more attention.

For many engineers, "cloud" is a non-technical term, fo= r managers only. But this is supposed to be a very technical list.


On Tue,= Nov 26, 2013 at 1:03 AM, Pal Martinsen (palmarti) <palmarti@cisco.com> wrote:
Hi,

On 22 Nov 2013, at 16:14 pm, Simon Perreault <simon.perreault@viagenie.ca> wrote:

> Are we done discussing it? What are the next steps?
>
> As a reminder, the current version is here:
> https://github.com/petithug/tram-charter/blob/mast= er/charter.txt
>
I think the charter looks good.

Being a new-bee regarding charters I have a few questions and comments.

The first section is rather long and describes the background in length. Is= the text in the first section at all necessary in a charter?

Can we add something around cloud in section three? For example:
=93 =97 that make STUN and TURN more suitable for WebRTC and Cloud like
environments.=94

TRAM would also benefit more traditional enterprise deployments. By using t= he word =93cloud=94 the charter can get some attention from that camp as we= ll.

Consider these comments as nits.

.-.
P=E5l-Erik


> 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
> https://www.ietf.org/mailman/listinfo/tram

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

--047d7b343642c58f3b04ec17713d-- From pkyzivat@alum.mit.edu Tue Nov 26 09:16:06 2013 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 CED6C1ADF26 for ; Tue, 26 Nov 2013 09:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 McEsOlQsen1M for ; Tue, 26 Nov 2013 09:16:05 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEDC1ADDDA for ; Tue, 26 Nov 2013 09:16:05 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta08.westchester.pa.mail.comcast.net with comcast id uEtj1m01T0Fqzac58HG4gn; Tue, 26 Nov 2013 17:16:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id uHG41m00g3ZTu2S3UHG4W1; Tue, 26 Nov 2013 17:16:04 +0000 Message-ID: <5294D754.4020305@alum.mit.edu> Date: Tue, 26 Nov 2013 09:16:04 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: tram@ietf.org References: <528F74EF.6030903@viagenie.ca> <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> <5294B74E.9060107@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17C56055@MCHP04MSX.global-ad.net> <5294CC22.90703@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17C5612D@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17C5612D@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1385486164; bh=fWL5at3zaYf1hMIu6phJ/MEAwtViZHQKWaUh3BgxCOs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=CbqDwxntox5hrbnTchJNxgwPhlVsf9m3XvSjQ2bTpvkBEX+T+r1xPdnXDDRhoF+3U ISaonV7o1fMHJEtc3HEAZ6NRaUiP/1ZfgfcF4AYNkdr33dYhIrORGUBXuuHv449GTO ABa41iJhNUinKnKMDa68wMFQStSfAbDj3dCNCG6GNWPMZ2FnjArZ0jKIHyuq4vOQjv NDB59uvDMwejq5AE8H1/Tp10l9b0zLpcAA4/933jpAxKFbPf0aZvSsrTmAwhxONM6F jIOgCkONaUqYw9WMoUsCxhQmzMkyc84NoGmn8KFn4gbz4rP1UP/W+NCOWqkyuMyI6a FGm9BSBcXFtgQ== Subject: Re: [tram] About that charter... 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, 26 Nov 2013 17:16:07 -0000 On 11/26/13 8:47 AM, Hutton, Andrew wrote: > On: 26 November 2013 16:28 Melinda Shore Wrote: >> >> On 11/26/13 7:20 AM, Hutton, Andrew wrote: >>> Personally I would like to start developing the tools and provide >>> information to help network administrators before they discover they >>> have a problem with webrtc. >> >> Do you need specific reference to enterprise deployments >> to do that? I didn't think so. > > I agree but we need the charter to broad enough to include putting some policy control in to the TURN server and to be clear I am not talking about firewall policy here. Just some things that have previously been mentioned like bandwidth, QoS, Mobility, and some things we might not have thought of yet. > >> In the meantime, if >> you go out there and tell people who are dealing with >> corporate policies driven out of the auditor's office that >> you're going to poke holes in their firewalls using a >> mechanism that's not managed under enterprise security >> policy, you're going to hit resistance before you even >> start. As you may have noticed. > > Also agree this is not about poking holes in firewalls and the work to define how webrtc works properly within an enterprise security policy will evidently not take place in this working group, we still need a home for that. I'm still trying to understand if we can reasonably expect to find a home for that discussion, or if we are being told "the IETF doesn't talk about that". In any case, I don't especially care to have a discussion of anybody's security policies. But we might talk about things that will be affected by, and provide input to, the application of security policies. Thanks, Paul >> I'd leave any reference to enterprise networks out of the >> charter. >> > > I am ok with that. > > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > From andrew.hutton@unify.com Tue Nov 26 09:25:13 2013 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 EE2801ADF59 for ; Tue, 26 Nov 2013 09:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 o2NeZ0WNzJ7S for ; Tue, 26 Nov 2013 09:25:10 -0800 (PST) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6D31ADF5E for ; Tue, 26 Nov 2013 09:25:07 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id E3F5323F0543; Tue, 26 Nov 2013 18:25:06 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.69]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Tue, 26 Nov 2013 18:25:06 +0100 From: "Hutton, Andrew" To: Simon Perreault , "tram@ietf.org" Thread-Topic: [tram] About that charter... Thread-Index: AQHO55WfTd9RE1BeuEK0ppIp9j/Hi5o3LL4AgABjhQCAACPMAP//9QkAgAASqCD///NqAIAAFX0g Date: Tue, 26 Nov 2013 17:25:05 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17C56299@MCHP04MSX.global-ad.net> References: <528F74EF.6030903@viagenie.ca> <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> <5294B74E.9060107@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17C56055@MCHP04MSX.global-ad.net> <5294CC22.90703@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17C5612D@MCHP04MSX.global-ad.net> <5294D13A.8050508@viagenie.ca> In-Reply-To: <5294D13A.8050508@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tram] About that charter... 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, 26 Nov 2013 17:25:13 -0000 Actually I was reasonably happy with the charter as it was until it was sta= ted that the current list of deliverables was part of the charter rather th= an being draft milestones and therefore adding to the list would need a cha= rter update. As I am often told that adding milestones is a whole lot easie= r than updating the charter text. Is it the case that the list of deliverables is proposed to be part of the = charter or are they just draft milestones? I assumed they were draft milestones as mentioning drafts in the charter is= something I don't think I have seen before. If I were to propose any change to the actual charter text then maybe I wou= ld modify the paragraph below to indicate that the work may also includes o= ther extensions to TURN. So change the following: "The goal of the TRAM Working Group is to consolidate the various initiativ= es 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". =20 To "The goal of the TRAM Working Group is to consolidate the various initiativ= es to update TURN and STUN, including the definition of new transport,=20 authentication mechanisms, and extensions, that make STUN and TURN more sui= table for the WebRTC environment". =20 Regards Andy > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault > Sent: 26 November 2013 16:50 > To: tram@ietf.org > Subject: Re: [tram] About that charter... >=20 > Le 2013-11-26 11:47, Hutton, Andrew a =E9crit : > > I agree but we need the charter to broad enough to include putting > some policy control in to the TURN server and to be clear I am not > talking about firewall policy here. Just some things that have > previously been mentioned like bandwidth, QoS, Mobility, and some > things we might not have thought of yet. >=20 > Please propose actual text changes. The current charter is at >=20 > https://github.com/petithug/tram-charter/blob/master/charter.txt >=20 > Just say exactly how you would like to see it changed. The RFC Editor > notation "OLD:... NEW:..." would be fine. >=20 > Thanks, > 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 pkyzivat@alum.mit.edu Tue Nov 26 09:51:53 2013 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 EE1521ADFA2 for ; Tue, 26 Nov 2013 09:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 kjcPRs8E9Bsm for ; Tue, 26 Nov 2013 09:51:52 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 507D51ACCFF for ; Tue, 26 Nov 2013 09:51:51 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta09.westchester.pa.mail.comcast.net with comcast id uH7A1m00B1ap0As59HrrRW; Tue, 26 Nov 2013 17:51:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id uHrq1m00P3ZTu2S3iHrq91; Tue, 26 Nov 2013 17:51:51 +0000 Message-ID: <5294DFB6.4040108@alum.mit.edu> Date: Tue, 26 Nov 2013 09:51:50 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: tram@ietf.org References: <528F74EF.6030903@viagenie.ca> <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> <5294B74E.9060107@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17C56055@MCHP04MSX.global-ad.net> <5294CC22.90703@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17C5612D@MCHP04MSX.global-ad.net> <5294D13A.8050508@viagenie.ca> <9F33F40F6F2CD847824537F3C4E37DDF17C56299@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17C56299@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1385488311; bh=24kGrJ6zOgjb6f7NcHqWrlgYLuq5nioYEGcrlGBhCJc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ttPJZM6S19e54gN6UNG6bPcyxXc3kieSff0ouXDzziK8TTMHquV//Q1KfmTieWsqi ieBAUCgeXDhYarLNV5+7F2Jl+4OgGT2oCQvePkgHhHd3qM5Iw947Qz5iUFu0pNVny0 DDneTLbJNNelDatP6Egi9+vX54N0Bv0yZnF64TxD8xFKu3vKVhvMbYzVfz3iE/+aDA bHz84DbyCzygAX69XLsL0/MAF5Qp1o6oqsQrE6JkkVz5WT+KBnkplIengIouKWqGqO BWB3fJUEEQFDb3G6KyaFR7h5cMc2V5wawgl5+OZJFexhiwCKtU3471061TTrL30CJK pABfFT6uofBLQ== Subject: Re: [tram] About that charter... 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, 26 Nov 2013 17:51:53 -0000 +1 On 11/26/13 9:25 AM, Hutton, Andrew wrote: > Actually I was reasonably happy with the charter as it was until it was stated that the current list of deliverables was part of the charter rather than being draft milestones and therefore adding to the list would need a charter update. As I am often told that adding milestones is a whole lot easier than updating the charter text. > > Is it the case that the list of deliverables is proposed to be part of the charter or are they just draft milestones? > > I assumed they were draft milestones as mentioning drafts in the charter is something I don't think I have seen before. > > If I were to propose any change to the actual charter text then maybe I would modify the paragraph below to indicate that the work may also includes other extensions to TURN. > > So change the following: > > "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". > > > To > > "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". > > Regards > Andy > > > >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault >> Sent: 26 November 2013 16:50 >> To: tram@ietf.org >> Subject: Re: [tram] About that charter... >> >> Le 2013-11-26 11:47, Hutton, Andrew a écrit : >>> I agree but we need the charter to broad enough to include putting >> some policy control in to the TURN server and to be clear I am not >> talking about firewall policy here. Just some things that have >> previously been mentioned like bandwidth, QoS, Mobility, and some >> things we might not have thought of yet. >> >> Please propose actual text changes. The current charter is at >> >> https://github.com/petithug/tram-charter/blob/master/charter.txt >> >> Just say exactly how you would like to see it changed. The RFC Editor >> notation "OLD:... NEW:..." would be fine. >> >> Thanks, >> 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 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > From gsalguei@cisco.com Tue Nov 26 09:58:48 2013 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 497601ADF61 for ; Tue, 26 Nov 2013 09:58:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 nlgYZ2eE_Que for ; Tue, 26 Nov 2013 09:58:46 -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 860691ADF46 for ; Tue, 26 Nov 2013 09:58:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3219; q=dns/txt; s=iport; t=1385488726; x=1386698326; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2/BJGb6G+hfEsSihFIGOWjebTghOI9Q5kC/TVSHz70c=; b=gdVyjEoJH+l5M6vEMhGKPWFYvhRVi8590y2sV2bFYOPK0lwYqmqXoOCE s+3lUeV4rC8CMIaM1CV1bjSKwnm8LVHX1T4MVxy/0LnEhFEb0fmkC66xH Sa+oBVX2VfigwszcDy7iYuWB2pXFsNwS4KG9bO1yyRcLI1PGuHpW/NMBR 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFALrglFKtJV2Z/2dsb2JhbABZDoJ5OFO6aoEtFnSCJQEBAQQBAQEkRwsMBAIBCA4DBAEBAScHJwsUCQgCBA4FiAENvzsXjkkzBwaDGoETA4kKjwqBMJBigmk/gio X-IronPort-AV: E=Sophos;i="4.93,776,1378857600"; d="scan'208";a="287619341" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 26 Nov 2013 17:58:46 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAQHwjtu012022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Nov 2013 17:58:46 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.232]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Tue, 26 Nov 2013 11:58:45 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Paul Kyzivat Thread-Topic: [tram] About that charter... Thread-Index: AQHO55WfRfpIk1mRGE+o3lF1R10UuZo3LL4AgABjhQCAACPMAIAAamEAgAAFbgCAAAClAIAACcuAgAAHeQCAAAHsgA== Date: Tue, 26 Nov 2013 17:58:45 +0000 Message-ID: References: <528F74EF.6030903@viagenie.ca> <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> <5294B74E.9060107@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17C56055@MCHP04MSX.global-ad.net> <5294CC22.90703@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17C5612D@MCHP04MSX.global-ad.net> <5294D13A.8050508@viagenie.ca> <9F33F40F6F2CD847824537F3C4E37DDF17C56299@MCHP04MSX.global-ad.net> <5294DFB6.4040108@alum.mit.edu> In-Reply-To: <5294DFB6.4040108@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.132.52] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Gonzalo Salgueiro \(gsalguei\)" , "tram@ietf.org" Subject: Re: [tram] About that charter... 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, 26 Nov 2013 17:58:48 -0000 +1=20 That's a reasonable addition. Gonzalo On Nov 26, 2013, at 12:51 PM, Paul Kyzivat wrote: > +1 >=20 > On 11/26/13 9:25 AM, Hutton, Andrew wrote: >> Actually I was reasonably happy with the charter as it was until it was = stated that the current list of deliverables was part of the charter rather= than being draft milestones and therefore adding to the list would need a = charter update. As I am often told that adding milestones is a whole lot ea= sier than updating the charter text. >>=20 >> Is it the case that the list of deliverables is proposed to be part of t= he charter or are they just draft milestones? >>=20 >> I assumed they were draft milestones as mentioning drafts in the charter= is something I don't think I have seen before. >>=20 >> If I were to propose any change to the actual charter text then maybe I = would modify the paragraph below to indicate that the work may also include= s other extensions to TURN. >>=20 >> So change the following: >>=20 >> "The goal of the TRAM Working Group is to consolidate the various initia= tives >> 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". >>=20 >>=20 >> To >>=20 >> "The goal of the TRAM Working Group is to consolidate the various initia= tives >> 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". >>=20 >> Regards >> Andy >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault >>> Sent: 26 November 2013 16:50 >>> To: tram@ietf.org >>> Subject: Re: [tram] About that charter... >>>=20 >>> Le 2013-11-26 11:47, Hutton, Andrew a =E9crit : >>>> I agree but we need the charter to broad enough to include putting >>> some policy control in to the TURN server and to be clear I am not >>> talking about firewall policy here. Just some things that have >>> previously been mentioned like bandwidth, QoS, Mobility, and some >>> things we might not have thought of yet. >>>=20 >>> Please propose actual text changes. The current charter is at >>>=20 >>> https://github.com/petithug/tram-charter/blob/master/charter.txt >>>=20 >>> Just say exactly how you would like to see it changed. The RFC Editor >>> notation "OLD:... NEW:..." would be fine. >>>=20 >>> Thanks, >>> 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 >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >>=20 >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From simon.perreault@viagenie.ca Tue Nov 26 10:28:28 2013 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 787D91AD72A for ; Tue, 26 Nov 2013 10:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 wIPgOXPWJCvY for ; Tue, 26 Nov 2013 10:28:26 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D23541ADF70 for ; Tue, 26 Nov 2013 10:28:26 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:8c9f:4cb8:2f97:3aa9]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6E42B403BA for ; Tue, 26 Nov 2013 13:28:26 -0500 (EST) Message-ID: <5294E84A.5040301@viagenie.ca> Date: Tue, 26 Nov 2013 13:28:26 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: tram@ietf.org References: <528F74EF.6030903@viagenie.ca> <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> <5294B74E.9060107@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17C56055@MCHP04MSX.global-ad.net> <5294CC22.90703@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17C5612D@MCHP04MSX.global-ad.net> <5294D13A.8050508@viagenie.ca> <9F33F40F6F2CD847824537F3C4E37DDF17C56299@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17C56299@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [tram] About that charter... 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, 26 Nov 2013 18:28:28 -0000 Le 2013-11-26 12:25, Hutton, Andrew a écrit : > So change the following: > > "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". > > > To > > "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". Makes sense. Pull request sent to Marc. 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 andrew.hutton@unify.com Tue Nov 26 11:01:14 2013 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 D9AD61ADF84 for ; Tue, 26 Nov 2013 11:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 nI5oyP_cUxPb for ; Tue, 26 Nov 2013 11:01:13 -0800 (PST) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 533FB1ADF6D for ; Tue, 26 Nov 2013 11:01:13 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id BBEBA23F0423; Tue, 26 Nov 2013 20:01:12 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.69]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Tue, 26 Nov 2013 20:01:12 +0100 From: "Hutton, Andrew" To: Simon Perreault Thread-Topic: [tram] About that charter... Thread-Index: AQHO55WfTd9RE1BeuEK0ppIp9j/Hi5o3LL4AgABjhQCAACPMAP//9QkAgAASqCD///NqAIAAFX0ggAAGAQCAABnspQ== Date: Tue, 26 Nov 2013 19:01:12 +0000 Message-ID: <556F8311-6669-4F9B-AADE-154AB3D7DC91@siemens-enterprise.com> References: <528F74EF.6030903@viagenie.ca> <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> <5294B74E.9060107@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17C56055@MCHP04MSX.global-ad.net> <5294CC22.90703@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17C5612D@MCHP04MSX.global-ad.net> <5294D13A.8050508@viagenie.ca> <9F33F40F6F2CD847824537F3C4E37DDF17C56299@MCHP04MSX.global-ad.net>, <5294E84A.5040301@viagenie.ca> In-Reply-To: <5294E84A.5040301@viagenie.ca> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tram@ietf.org" Subject: Re: [tram] About that charter... 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, 26 Nov 2013 19:01:15 -0000 Can someone confirm that the deliverables=20 On 26 Nov 2013, at 18:28, "Simon Perreault" w= rote: > Le 2013-11-26 12:25, Hutton, Andrew a =E9crit : >> So change the following: >>=20 >> "The goal of the TRAM Working Group is to consolidate the various initia= tives >> 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". >>=20 >>=20 >> To >>=20 >> "The goal of the TRAM Working Group is to consolidate the various initia= tives >> 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". >=20 > Makes sense. Pull request sent to Marc. >=20 > Simon > --=20 > 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 andrew.hutton@unify.com Tue Nov 26 11:03:40 2013 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 4325F1ADFD5 for ; Tue, 26 Nov 2013 11:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 tEJkZMkoEJcC for ; Tue, 26 Nov 2013 11:03:38 -0800 (PST) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 80FC11ADFAB for ; Tue, 26 Nov 2013 11:03:38 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id BB7A61EB8598; Tue, 26 Nov 2013 20:03:37 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.69]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Tue, 26 Nov 2013 20:03:37 +0100 From: "Hutton, Andrew" To: "Hutton, Andrew" Thread-Topic: [tram] About that charter... Thread-Index: AQHO55WfTd9RE1BeuEK0ppIp9j/Hi5o3LL4AgABjhQCAACPMAP//9QkAgAASqCD///NqAIAAFX0ggAAGAQCAABnspYAAAKvI Date: Tue, 26 Nov 2013 19:03:35 +0000 Message-ID: <42DE432D-E042-4EE4-A2D1-409342263515@siemens-enterprise.com> References: <528F74EF.6030903@viagenie.ca> <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> <5294B74E.9060107@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17C56055@MCHP04MSX.global-ad.net> <5294CC22.90703@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17C5612D@MCHP04MSX.global-ad.net> <5294D13A.8050508@viagenie.ca> <9F33F40F6F2CD847824537F3C4E37DDF17C56299@MCHP04MSX.global-ad.net>, <5294E84A.5040301@viagenie.ca>, <556F8311-6669-4F9B-AADE-154AB3D7DC91@siemens-enterprise.com> In-Reply-To: <556F8311-6669-4F9B-AADE-154AB3D7DC91@siemens-enterprise.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] About that charter... 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, 26 Nov 2013 19:03:40 -0000 So can someone confirm that the deliverables mentioned in the draft charter= are actually draft milestones and not part of the charter text itself? Sorry about last message. Andy On 26 Nov 2013, at 19:01, "Hutton, Andrew" wrote: > Can someone confirm that the deliverables=20 >=20 > On 26 Nov 2013, at 18:28, "Simon Perreault" = wrote: >=20 >> Le 2013-11-26 12:25, Hutton, Andrew a =E9crit : >>> So change the following: >>>=20 >>> "The goal of the TRAM Working Group is to consolidate the various initi= atives >>> 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". >>>=20 >>>=20 >>> To >>>=20 >>> "The goal of the TRAM Working Group is to consolidate the various initi= atives >>> 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". >>=20 >> Makes sense. Pull request sent to Marc. >>=20 >> Simon >> --=20 >> 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 From simon.perreault@viagenie.ca Tue Nov 26 11:05:19 2013 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 68E561ADFA9 for ; Tue, 26 Nov 2013 11:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 FBQQHrHbiplK for ; Tue, 26 Nov 2013 11:05:17 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E803C1ADFA3 for ; Tue, 26 Nov 2013 11:05:16 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:8c9f:4cb8:2f97:3aa9]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 978CF403BA; Tue, 26 Nov 2013 14:05:16 -0500 (EST) Message-ID: <5294F0EC.9060203@viagenie.ca> Date: Tue, 26 Nov 2013 14:05:16 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Hutton, Andrew" References: <528F74EF.6030903@viagenie.ca> <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> <5294B74E.9060107@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17C56055@MCHP04MSX.global-ad.net> <5294CC22.90703@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17C5612D@MCHP04MSX.global-ad.net> <5294D13A.8050508@viagenie.ca> <9F33F40F6F2CD847824537F3C4E37DDF17C56299@MCHP04MSX.global-ad.net>, <5294E84A.5040301@viagenie.ca>, <556F8311-6669-4F9B-AADE-154AB3D7DC91@siemens-enterprise.com> <42DE432D-E042-4EE4-A2D1-409342263515@siemens-enterprise.com> In-Reply-To: <42DE432D-E042-4EE4-A2D1-409342263515@siemens-enterprise.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "tram@ietf.org" Subject: Re: [tram] About that charter... 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, 26 Nov 2013 19:05:19 -0000 Le 2013-11-26 14:03, Hutton, Andrew a écrit : > So can someone confirm that the deliverables mentioned in the draft charter are actually draft milestones and not part of the charter text itself? That's the intent, at least for me. 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 Tue Nov 26 11:51:06 2013 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 1EE151ADF93 for ; Tue, 26 Nov 2013 11:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 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.001, 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 K0VZy514ZniD for ; Tue, 26 Nov 2013 11:51:04 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 81B581ADFF6 for ; Tue, 26 Nov 2013 11:51:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2079; q=dns/txt; s=iport; t=1385495464; x=1386705064; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tfpyZHu2xsjoD/WK1r2Xk+/egzwrNJUdU/Do+0v8+s4=; b=nCpVo0IuE1W37uluYpSLkqOc3nMqqankYpf8sEZlA9di4AgyQNtzPD16 bjlOmqqUgWNn+9x+FXA89jbIkkPz/MOkYbA9EJH4TUe0HXp0D1VQaVOcl Oue6rRCZQYfVEuk5OcB2vYXZz5YyVjlh3S7GXh/lhv8MgOun+wxiN6Fn/ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAHX7lFKtJV2d/2dsb2JhbABZgwc4U7pqgS4WdIIlAQEBAwEBAQEkRwsFCwIBCBguJwslAgQOBYd7Bg2/RReOSTMHgyCBEwOJCo8KgTCQYoMogio X-IronPort-AV: E=Sophos;i="4.93,776,1378857600"; d="scan'208";a="2431227" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP; 26 Nov 2013 19:51:03 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rAQJp3i4028682 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Nov 2013 19:51:03 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.232]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Tue, 26 Nov 2013 13:51:03 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: "Hutton, Andrew" Thread-Topic: [tram] About that charter... Thread-Index: AQHO55WfRfpIk1mRGE+o3lF1R10UuZo3LL4AgABjhQCAACPMAP//9QkAgAASqCD///NqAIAAFX0ggAAGAQCAABnspYAAZT+AgAANQgA= Date: Tue, 26 Nov 2013 19:51:02 +0000 Message-ID: <026D637A-F8BA-4F10-B975-2092D04FC343@cisco.com> References: <528F74EF.6030903@viagenie.ca> <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> <5294B74E.9060107@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17C56055@MCHP04MSX.global-ad.net> <5294CC22.90703@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17C5612D@MCHP04MSX.global-ad.net> <5294D13A.8050508@viagenie.ca> <9F33F40F6F2CD847824537F3C4E37DDF17C56299@MCHP04MSX.global-ad.net>, <5294E84A.5040301@viagenie.ca>, <556F8311-6669-4F9B-AADE-154AB3D7DC91@siemens-enterprise.com> <42DE432D-E042-4EE4-A2D1-409342263515@siemens-enterprise.com> In-Reply-To: <42DE432D-E042-4EE4-A2D1-409342263515@siemens-enterprise.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.53.101] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <21F72CE05EB72849AE97822353D45DF5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simon Perreault , "Gonzalo Salgueiro \(gsalguei\)" , "tram@ietf.org" Subject: Re: [tram] About that charter... 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, 26 Nov 2013 19:51:06 -0000 They are milestones. I suspect that before the charter is finalized we'll = simply list the milestones and drop their individual summary text. Gonzalo On Nov 26, 2013, at 2:03 PM, Hutton, Andrew wrote= : > So can someone confirm that the deliverables mentioned in the draft chart= er are actually draft milestones and not part of the charter text itself? >=20 > Sorry about last message. >=20 > Andy >=20 > On 26 Nov 2013, at 19:01, "Hutton, Andrew" wrot= e: >=20 >> Can someone confirm that the deliverables=20 >>=20 >> On 26 Nov 2013, at 18:28, "Simon Perreault" wrote: >>=20 >>> Le 2013-11-26 12:25, Hutton, Andrew a =E9crit : >>>> So change the following: >>>>=20 >>>> "The goal of the TRAM Working Group is to consolidate the various init= iatives >>>> to update TURN and STUN, including the definition of new transport and >>>> authentication mechanisms that make STUN and TURN more suitable for th= e WebRTC >>>> environment". >>>>=20 >>>>=20 >>>> To >>>>=20 >>>> "The goal of the TRAM Working Group is to consolidate the various init= iatives >>>> to update TURN and STUN, including the definition of new transport, >>>> authentication mechanisms, and extensions, that make STUN and TURN mor= e suitable for the WebRTC >>>> environment". >>>=20 >>> Makes sense. Pull request sent to Marc. >>>=20 >>> Simon >>> --=20 >>> 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 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From mom040267@gmail.com Tue Nov 26 19:11:48 2013 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 60F7A1AE0D8 for ; Tue, 26 Nov 2013 19:11:48 -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 8WVmrpKnJpZv for ; Tue, 26 Nov 2013 19:11:46 -0800 (PST) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7541A8034 for ; Tue, 26 Nov 2013 19:11:45 -0800 (PST) Received: by mail-pd0-f180.google.com with SMTP id q10so8970874pdj.39 for ; Tue, 26 Nov 2013 19:11:45 -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=vMsN6RV7LtmQfh/9686FsakSVoroSvpD0CU2k2hK+xE=; b=u7Lw4UPTSWlLQkwIgn6++xnHdSg4ej05VDM9KwxbulTIn9q4LBBz92WPNo07uk2rX6 /ZN2+3THEUd0EIOc9461bAnyOGjPOuJBcpPcPU+qVmt9AxROx31ukvjRb0q1eKxOfzE/ TuK+VzpN3DHUEdFblmSR5g5SgEv/hYMOUtAzXQKUchNH/0/ejRheScowpr+jiKx8AMHg 2iHXgFEz8UyLoMf1lB1C5TSdqVk3wwGWWgZRlBLcJ/OanlSxZwVMrhcIu6/W8yfpLwYw ptlro6GspQv3rIIMHYQkoFyuujD8Zk71W1vKY68ZlGooAXZqcrrnUR9naJucMna+stxJ ZCvQ== MIME-Version: 1.0 X-Received: by 10.68.197.104 with SMTP id it8mr2754208pbc.17.1385521905461; Tue, 26 Nov 2013 19:11:45 -0800 (PST) Received: by 10.68.147.131 with HTTP; Tue, 26 Nov 2013 19:11:45 -0800 (PST) In-Reply-To: References: <528F74EF.6030903@viagenie.ca> <4EF14367-E435-43D6-B330-0F16FB832013@cisco.com> Date: Tue, 26 Nov 2013 19:11:45 -0800 Message-ID: From: Oleg Moskalenko To: Spencer Dawkins at IETF Content-Type: multipart/alternative; boundary=e89a8ff1c9a200f45304ec1ff57b Cc: Simon Perreault , "Pal Martinsen \(palmarti\)" , "tram@ietf.org" Subject: Re: [tram] About that charter... 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, 27 Nov 2013 03:11:48 -0000 --e89a8ff1c9a200f45304ec1ff57b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Spencer, this is how I view it, too. If we specify a particular part of the "cloud" and if we define well what we are going to do about that, then it will be fine. But then we even do not need the word "cloud". I think that we already have a good-enough defined charter. On Tue, Nov 26, 2013 at 9:02 AM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > I'm not speaking as an AD, but I am speaking as a retired IAB member who > was watching a year-long effort to charter something (well, really, > anything) in the cloud space. > > My suggestion would be to figure out specifically what part of "cloud" is > relevant to what you're proposing, and point to something more specific. > For example, the data center parts of "cloud" started getting more tracti= on > when they were called out specifically. > > The IESG (at that time) wasn't opposed to doing something that would be > helpful for clouds, but they weren't getting proposals for specific > protocol work, and that's pretty much what the IETF does ... > > Spencer > > > On Tuesday, November 26, 2013, Oleg Moskalenko wrote: > >> If we add word "porn" it will attract even more attention. >> >> For many engineers, "cloud" is a non-technical term, for managers only. >> But this is supposed to be a very technical list. >> >> >> On Tue, Nov 26, 2013 at 1:03 AM, Pal Martinsen (palmarti) < >> palmarti@cisco.com> wrote: >> >>> Hi, >>> >>> On 22 Nov 2013, at 16:14 pm, Simon Perreault < >>> simon.perreault@viagenie.ca> wrote: >>> >>> > Are we done discussing it? What are the next steps? >>> > >>> > As a reminder, the current version is here: >>> > https://github.com/petithug/tram-charter/blob/master/charter.txt >>> > >>> I think the charter looks good. >>> >>> Being a new-bee regarding charters I have a few questions and comments. >>> >>> The first section is rather long and describes the background in length= . >>> Is the text in the first section at all necessary in a charter? >>> >>> Can we add something around cloud in section three? For example: >>> =93 =97 that make STUN and TURN more suitable for WebRTC and Cloud like >>> environments.=94 >>> >>> TRAM would also benefit more traditional enterprise deployments. By >>> using the word =93cloud=94 the charter can get some attention from that= camp as >>> well. >>> >>> Consider these comments as nits. >>> >>> .-. >>> P=E5l-Erik >>> >>> >>> > 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 >>> >>> _______________________________________________ >>> tram mailing list >>> tram@ietf.org >>> https://www.ietf.org/mailman/listinfo/tram >>> >> >> --e89a8ff1c9a200f45304ec1ff57b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Spencer, this is how I view it, too. If we specify a parti= cular part of the "cloud" and if we define well what we are going= to do about that, then it will be fine. But then we even do not need the w= ord "cloud". I think that we already have a good-enough defined c= harter.


On Tue,= Nov 26, 2013 at 9:02 AM, Spencer Dawkins at IETF <spencerdawk= ins.ietf@gmail.com> wrote:
I'm not speaking as an AD, but I am spea= king as a retired IAB member who was watching=A0a year-long effort to chart= er something (well, really, anything) in the cloud space.

My suggestion would be to figure out specifically what part = of "cloud" is relevant to what you're proposing, and point to= something more specific. For example, the data center parts of "cloud= " started getting more traction when they were called out specifically= .

The IESG (at that time) wasn't opposed to doing som= ething that would be helpful for clouds, but they weren't getting propo= sals for specific protocol work, and that's pretty much=A0what=A0the IE= TF does=A0...

Spencer


On Tuesday, Novem= ber 26, 2013, Oleg Moskalenko wrote:
If we add word "porn" it will attract even = more attention.

For many engineers, "cloud" is a non-technical term, fo= r managers only. But this is supposed to be a very technical list.


On Tue,= Nov 26, 2013 at 1:03 AM, Pal Martinsen (palmarti) <palmarti@cisco.com> wrote:
Hi,

On 22 Nov 2013, at 16:14 pm, Simon Perreault <simon.perreault@viageni= e.ca> wrote:

> Are we done discussing it? What are the next steps?
>
> As a reminder, the current version is here:
> https://github.com/petithug/tram-charter/blob/mast= er/charter.txt
>
I think the charter looks good.

Being a new-bee regarding charters I have a few questions and comments.

The first section is rather long and describes the background in length. Is= the text in the first section at all necessary in a charter?

Can we add something around cloud in section three? For example:
=93 =97 that make STUN and TURN more suitable for WebRTC and Cloud like
environments.=94

TRAM would also benefit more traditional enterprise deployments. By using t= he word =93cloud=94 the charter can get some attention from that camp as we= ll.

Consider these comments as nits.

.-.
P=E5l-Erik


> 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
> https://www.ietf.org/mailman/listinfo/tram

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


--e89a8ff1c9a200f45304ec1ff57b--